Class diagrams are used as document to illustrate the static structure of the system, that is, what classes there are and how they are related but not how they interact. They also show the relationships between classes and the operations and attributes of the classes and the degree of the relationship.
The first stage is to identify the classes that are required. This is one of the key skills required in the development of object orientation. It is crucial for building genuinely extensible software with reuse. One technique is to use nouns to help identify real world objects from the statement of requirements. Underline nouns and this will provide a list of candidates, which can then be whittled down and modified to get an initial class list for the system.
Next we discard those which are “obviously” not good candidates for any one of a variety of reasons.
· Redundant, where the same class is given more than one more name. It is, however, important to remember that similar objects are not always entirely identical: Whether things are different enough to merit another class is up to you to decide. Perhaps consider loan and short term loan: they are different, but probably only in the value of attributes. Choose a name from the class that encompasses all the descriptions you mean to include.
· Vague, where you can’t tell unambiguously what is meant by a noun. Obviously you have to clear up the ambiguity before you can tell whether the noun represents a class.
· An event or operation, where the noun refers to something that is to be done by or in the system. Sometimes such a thing is well modelled by a class, but this is not the usual case.
· Meta language, this is where the noun is used as part of our language of modelling, rather than to represent objects in the problem objects such as system and requirements.
· Outside the scope, where the noun is relevant to describing how the system works but does not refer to something inside the system. Also names of the users can often be discarded by this rule.
· Attribute, where it is clear that a noun refers to something that is part of another class i.e. doors can be seen as a class but if linked to cars it is part of a car. Therefore it could be seen as an attribute of the class car.
So what types of things are classes?
A class describes a set of objects with an equivalent role or roles in the system. Booch describes these as
· Tangible or ‘real world’ things: Ships, cards
· Roles: member
· Events: arrival, leaving
· Interaction: meeting
To begin to structure the classes we need to identify the characteristics and the state of the characteristics of the class. The characteristics are known as attributes. Attributes will describe the data contained within a class. In the above example memberName is an attribute that will hold the name of a member.
Operations or behaviours define how objects of a class can interact. When one object sends a message to another, it is asking the receiver to perform an operation. The receiver will invoke a method to perform the operation; the sender does not know which method will be invoked as there are many methods implementing the same operation at different levels of the inheritance hierarchy.
Classes are depicted as rectangle boxes broken into three sections. The top section contains the name of the, the second section contains the attributes (characteristics) of the class and the bottom box lists its behaviour. The behaviour section depicts the methods that will provide the behaviour requested.
Class diagram for the class Flight
Instances of classes are called objects and instances of association are objects that have a relationship with an object of another class.
Class A and class B are associated if
· An object of class A sends a message to an object of Class B
· An object of class A creates an object of Class B
· An Object of class A has an attribute whoa values are objects of class B or collections of objects of class B.
· An object of class A receives a message with an object of class B as an argument
In short if some object of class A has to known about some object of Class B then there is a link. Each link, each instance of the association, relates an object of class A and an object of class B. For example, the association called borrows/returns between librarymember and copy might have the following links
· Jo Bloggs borrows/returns copy 17 of harry potter
· Marcus Smith borrows/returns copy 1 of famous five
· Jo Bloggs borrows/returns copy 4 of software reuse
Each relationship between classes is named for example class “copy” is associated with Class “Book”. The relationship can name “is a copy of” suggesting the book that a copy of a particular book has been load. The naming of a relation is important and should suggest the type of relationship.
Next we identify and name important real-world relationships or associations between our classes. This will help to clarify our understanding of the domain and how our objects will work together. Multiplicities show the degree of the relationship between the classes, how many objects one class are associated with an instance of another class. If we look at library system where we have a class copy and a class book . If we say 1..* at the copy end of the relationship we are expressing that the number of copies can be anything between 1 and infinity. If we put 6..* this express that at least 6 instances will have a relationship with the class book to infinity. If we put just one this means one instance of copy can have relationship with book. We can also specify a list of multiplicities separated by a number 2, 13, 24 etc. The multiplicity is place next to each class.
They can be specified as:
An exact number simply by writing it
A range of numbers using two dots between a pair of numbers
An arbitrary , unspecified number using *
Aggregation and Composition
Bi-directional (standard) association
An association is a linkage between two classes. Associations are always assumed to be bi-directional; this means that both classes are aware of each other and their relationship, unless you qualify the association as some other type. Going back to our Flight example, the figure shows a standard kind of association between the Flight class and the Plane class.
In a uni-directional association, two classes are related, but only one class knows that the relationship exists. The figure shows an example of an overdrawn accounts report with a uni-directional association.
A very important concept in object-oriented design, inheritance, refers to the ability of one class (child class) to inherit the identical functionality of another class (super class), and then add new functionality of its own. To model inheritance on a class diagram, a solid line is drawn from the child class (the class inheriting the behaviour) with a closed, unfilled arrowhead (or triangle) pointing to the super class. Consider types of bank accounts: The figure below shows how both CheckingAccount and SavingsAccount classes inherit from the BankAccount class.
Aggregation and compositions are kinds of association: instead of just showing that two classes are associated we can show what type of association they have. Aggregation and composition are both ways of recording that an object of one class is part of an object of another.
For example a module Class can have association with an HonoursCourse Class. The nature of the relationship can be shown as module as a part of honoursCourse by placing an open diamond at the whole part which in this case is the HonoursCoure. This denotes an aggregation. Multiplicities can still be show as normal. The name of the relationship would reflect this association.
Composition is a more specific form of aggregation that places even more restricts upon the classes. In this case if the whole upon which the part is linked is copied or deleted the part will also be copied and deleted. The multiplicity of a whole in a composition must be one. Consider tic tac toe with a class board and a class square. The class square depends wholly upon the board class. Composition is denoted with a diamond that is shown as coloured black at the whole part.
Inevitably, if you are modelling a large system or a large area of a business, there will be many different classifiers in your model. Managing all the classes can be a daunting task; therefore, UML provides an organizing element called a package. Packages enable modellers to organize the model's classifiers into namespaces, which is sort of like folders in a filing system. Dividing a system into multiple packages makes the system easier to understand, especially if each package represents a specific part of the system.
There are two ways of drawing packages on diagrams. There is no rule for determining which notation to use, except to use your personal judgement regarding which is easiest to read for the class diagram you are drawing. Both ways begin with a large rectangle with a smaller rectangle (tab) above its upper left corner, as seen in the top figure below. But the modeller must decide how the package's membership is to be shown, as follows:
An example package element that shows its members inside the package's rectangle boundaries