January 2011 Edition
Computer Science Department, University of Cape Town
| MIT Notes Home | Edition Home |
| MSc-IT Study Material January 2011 Edition Computer Science Department, University of Cape Town | MIT Notes Home | Edition Home | |
The diagram below shows the UML symbol for a class formally (left) and as an example (right). The formal detail looks quite daunting, but you will see that most of the information is optional, and in practice a class symbol is quite straightforward.
The class symbol has three compartments. The top compartment shows the name of the class, any tags it has, and any stereotype it has. The stereotype of a class is a higher-level category to which it belongs. Stereotypes are used to provide additional structure to a model, and to make it easier to follow. Common stereotypes include «use case» and «actor». Most classes, in practice, will not need stereotypes. The designer is at liberty to create new stereotypes to organise the work, if required. The only tag that we will consider in this module is {abstract}, which will be discussed later.
The middle compartment contains the class's attributes. Each attribute can specify a name, a type and a default value. Only the name is compulsory.
The bottom compartment contains the class's operations. These can be specified in full, with parameter lists and return values, but very often only the name is given. To distinguish operation names from attribute names, it is conventional to write an operation name with pair of brackets after it, like this: push(). If the operation has a parameter list, then it can be written in the brackets, but, again, this is not compulsory.
The example shows a possible class diagram for a “Button” class. By button we mean a little rectangle that appears on the screen, and responds to mouse clicks, as with a computer GUI rather than a physical button. In this example, the button has the stereotype «user interface elements». It is intended that this stereotype be applied to all classes that represent user interface elements, like list boxes, menus, windows, and so on. Again, this is not compulsory, but it helps structure the model. There are no tags associated with this class, so none are shown.
The “Button” class has a foreground colour and a border colour, and these can be changed. So we have defined two attributes to store the colours. These attributes have type “colour”. Most programming languages do not have an inbuilt “colour” data type, and at some point the programmer will have to translate this type name into something that the programming language will understand. This is not an issue for the early stage of design. It is clear what “colour” means, and this is the important factor.
The operations of the class are “push()”, meaning simulate what happens when a button is pushed (probably the screen appearance will change), and two operations to change the colours. Why can another class simply not change the attributes to change the colour? It is vital to understand that a class should be, as far as possible, self-contained. It is up to the class to decide whether its colours can be changed or not, and by which other objects. The operations to change that colour will probably change the values of the colour attributes, but it is up to the implementer of the class to decide how this will happen. Another class does not need to know the internal operation of the “Button” class.
The operations that set the colour each have a parameter list with one parameter: the colour to be used.
You will see that the example class is very much simpler than the formal specification. In practice, it is common for classes to start of with very little detail (no parameters, no types), and to be “filled in” as design progresses.
The class diagrams were created using a commercial package, Select SSADM. Various software packages may support the UML notation to a greater or lesser degree, and so diagrams made using different packages will differ from one another.
The UML makes certain recommendations about how names of things are to be written, with varying degrees of force. We recommend that you follow the UML naming conventions as if they were all compulsory, because most professional designers do, and you will want your work to be understandable by your colleagues. The naming conventions are also in line with the Java naming conventions, and should be familiar.
Names of classes are written with an initial capital letter (like this: Button, not like this: button) and have no spaces. To show where a space would be, the next letter is capitalised (like this: BarcodeReader, not like this: Barcode Reader).
Class names are singular, not plural. It is incorrect to name a class “Books”. Although there may be many book objects, there is only one book class.
Names of attributes and operations start with a lower-case letter, but may have capital letters to indicate where the spaces would be, if the name would normally have spaces.
Names of operations are followed by brackets () to distinguish them from names of attributes
The prohibition against spaces arises because most programming languages do not allow spaces in their naming convention, and it is modern practice for the final model diagrams to be as close to a program as possible. Some, but not all, CASE packages will enforce these conventions.
