Class diagrams

From SoftwarePractice.org

This is a page about class diagrams. Feel free to add useful stuff!

Contents 1 Useful links 2 Tutorial

Useful links

• Courseware module on class diagrams

Tutorial

(This tutorial is based on a tutorial by Lian Loke and Lizveth Robles, developed for 48024 Object-Oriented Design, for the University of Technology, Sydney.)

In this tutorial, you will be working with your system description and the requirements artifacts that you have already developed for your project, to make a start on the static structure (class diagrams) of your program. You are not, of course, going to complete anything in this short amount of time, but your goal is to make sure that you have made a solid start and understand how to continue with the development of your class diagrams.

In overview, the tutorial asks you to generate a set of CRC (class-responsibility-collaborator) cards by analysing the information that you currently have available about the program. This includes your original program description, your usage scenarios, and your use cases. Based on the results of your CRC work, you will then create an initial class diagram for your program.

Important note: Don't assume that you understand even the basics of class diagrams unless you have obtained feedback from the tutor. Time and time again I see students make terrible mistakes, but not realize because they haven't obtained feedback on what they have done!

1. Team formation. Form into your teams. If you have any team members missing, or persistently not showing up at your meetings, you may wish to raise this with the tutor.
2. Brainstorm classes. Role-play the scenarios and use cases that you wrote last time. In other words, "play-act" them out, all the while talking about what the user and the program are doing. As you go, the team identifies "things" and concepts that could be classes. For each, write the name of it on a separate index card.
3. Identify responsibilities. Lay the cards out on the table. For each class, try and identify its responsibilities. Some will be obvious from the name of the class -- the "position display", for example, will display the position. Revisit scenarios involving that class to see what other responsibilities you can find. Remember that responsibilities are "something the class (object) knows" or "something the class (object) does."
4. Identify collaborators. For each class, identify a short list of collaborators -- other classes that this class needs in order to get its job done. If you get stuck with this, you can go down the list of responsibilities and for each, ask whether the class is able to fulfil that responsibility all by itself, or whether it needs help from other classes.
5. Iterate. Lay the cards out on the table, and work through your scenarios and use cases again. This time, you already have responsibilities and collaborators written down, by you are checking for missing or unnecessary ones. You may find that you need to create additional classes, or move responsibilities around. This is fine, and you should keep doing this until satisfied that your set of CRC cards is a reasonable model of the program.
6. Draw classes. On a larger sheet of paper, draw a box for each of the classes you have identified. Write the class name, and for each, divide responsibilities into attributes and operations. Since this is early design work, be brief!
7. Identify relationships. Identify relationships between the classes. To start with, you should look for generalization (inheritance). Then, look for associations ("uses"). For each, draw the relationship between the relevant classes. You should also discuss, in the team, the name of associations and their multiplicity.
8. Seek feedback. Seek feedback from the instructor. You have most likely misunderstood many of the concepts dicsussed in the lecture. Even if you think you know it, ask for feedback anyway.
9. Follow-up. Continue to refine your class diagram with your team over the next few weeks. You may also find that you wish to revise your scenarios and use cases, as this more detailed look at them has probably shown inadequacies in them as descriptions of your program's functionality.