1. 1 Kyung Hee University Class Diagrams Spring 2001

2. 2 Kyung Hee University Class Diagrams  Object diagrams model the data held in a system at a given instant. Instances of classes, showing what objects exist. Data stored as attributes in objects. Information stored structurally as links between objects.  Object diagrams can represent both legal and illegal states of a system:

3. 3 Kyung Hee University Class Diagrams  We need to be able to specify which object diagrams represent legal states of the system: it won’t be practicable to simply list them.  UML uses class diagrams to specify the static structure of a system.  It acts as a kind of specifications for a system.

4. 4 Kyung Hee University Datatypes  Primitive data is represented in UML as data values belonging to suitable data types, of the following kinds: Predefined types UML defines a number of primitive types, including Boolean, Integer and String.

5. 5 Kyung Hee University Datatypes User-defined types These are enumerations, and can be represented graphically: Language types Defined by type expressions borrowed from the target programming language.

6. 6 Kyung Hee University Multiplicity  Multiplicity in UML is a way of specifying a number, or cardinality. In general, a UML multiplicty is a comma-separated list of number ranges, such as: 2,4,6..10 0..3,5..* ( * represents “infinity”)  A set of integer values  Representing one possibility for the number of occurrences of the entity being specified  Example, suppose that a given entity is optional but that if it is present there must be at least three of them.

7. 7 Kyung Hee University Instances of classes  UML makes a basic distinction between descriptors and instances. Descriptors – such as classes – describe, or specify, the properties of their instances – such as objects.  The relationship between a class and its instances is known as instantiation. It can be represented in UML using a dependency labelled with the stereotype “instantiates”.

8. 8 Kyung Hee University Class Multiplicity  It is very rare that there is a need to show this explicitly. A multiplicity in a class specifies the number of instances of that class that can exist simultaneously. The default is “zero or more”. A common use is to specify that a class can only have one instance.

9. 9 Kyung Hee University Attributes  Classes have attributes, which specify the data that can be held in instances of that class.  Normally every instance has its own copy of an attribute, and can store different data.  Attributes with class scope are shared by all instances of the class: only one copy of the attribute is stored.

10. 10 Kyung Hee University Attributes  Attributes with class scope are underlined in a class icon. They are similar to static data members in programming languages.  Attribute syntax: types are optional; optional multiplicity between the name and the colon.

11. 11 Kyung Hee University Operations  Classes also have operations, whcih specify ways of accessing or manipulating the data stored in objects. As operations are the same for every instance of a class, they are not normally shown on object icons.

12. 12 Kyung Hee University Operations  Normal operations can be applied to individual objects. Operations with class scope are applied to the class (and can be thought of as only accessing class scope attributes).  The commonest use for operations with class scope in UML is to model class constructors.  Operation syntax: types are optional.

13. 13 Kyung Hee University Object Identity  Two objects of a class can have identical values for their attributes, while still being distinct objects.  Unlike data values: objects have an identity which is distinct from the data they hold, and which serves to distinguish objects. (An object’s identity is often implemented as its address in memory.)

14. 14 Kyung Hee University Object Identity  There is therefore no need to add special identifying attributes to classes, though if one exists in the problem domain it can be added:  Here the id attribute is quite distinct from the identity of the instances of the class.

15. 15 Kyung Hee University Associations and Links  Two objects can only be linked if there is a corresponding association between their classes.  Both an association and its two ends can be labelled. These labels can also be applied to the relevant links if necessary.

16. 16 Kyung Hee University Associations and Links  An association name is often a verb. The arrowhead indicates which direction to read it in. This association shows people working for companies, not companies working for people (which is a perfectly sensible, but different, association).  Role names are often nouns, describing the role an object plays in the relationship.

17. 17 Kyung Hee University Self associations  Associations are normally binary, connecting two classes. UML does provide a notation for associations that connect more than two classes, but it is rarely used.  The two classes need not be distinct: an association that connects a class to itself is called a self-association.

18. 18 Kyung Hee University Multiplicity of associations  Multiplicities on associations specify properties of the number of links that can exist between instances of the associated classes.  This asserts that an instance of Person can be linked to only one company, but an instance of Company can be linked to many people. In other words, a company has many employees, each of whom only works for one company.

19. 19 Kyung Hee University Multiplicity of associations  Given this class diagram, the following object diagram represents an illegal situation, as it show a person working for two companies.

20. 20 Kyung Hee University Labelling associations  In general: 1. Multiplicity annotations must be shown on associations. 2. Labels and role names are optional; the designer can choose the level of detail necessary to make the diagram easily comprehensible.  In a few cases, some form of labelling must be used. 1. To distinguish between different associations between the same pair of classes.

21. 21 Kyung Hee University Labelling associations 2. To distinguish between the two ends of a self-association

22. 22 Kyung Hee University Semantics of links  Unlike objects, links don’t have identity. This means that you cannot have two instances of the same association connecting the same pair of objects.  The links are identified by the pair of objects that they link, and therefore cannot be distinguished.  In order to model a situation where a person is employed twice by the same company, it would be necessary to introduce a suitable intermediate class.

23. 23 Kyung Hee University Semantics of links

24. 24 Kyung Hee University The Need for Generalization  In many modelling situations, a number of classes share some of the same properties. These might be attributes, operations or the way in which they are associated with other classes (or a combination of all three).  For example, a bank might offer its customers a range of different types of account, and a customer could hold any number of accounts, which could be of different types.

25. 25 Kyung Hee University The Need for Generalization  This is a clumsy model: From a customer’s point of view, there is logically one relation, of holding an account. It shouldn’t have to be modelled by three separate associations. The account classes will likely share a range of properties, which shouldn’t have to be defined in three separate places.

26. 26 Kyung Hee University Generalization  These problems can be addressed by introducing a common superclass which represents what the three types of account have in common (namely, that they are accounts).

27. 27 Kyung Hee University Generalization  This relationship between superclasses and subclasses in UML is known as generalization. The term for the inverse relation that subclasses have to superclasses is specialization.  Generalization relationships are quite different from associations: Generalizations do not specifiy any type of link or relationship between objects. Therefore, it makes no sense to put multiplicity symbols on generalization relationships.

28. 28 Kyung Hee University Generalization hierarchies  Generalization hierarchies can be formed. Omitted classes can be shown with an ellipsis. 

29. 29 Kyung Hee University Generalization hierarchies  Generalization is sometimes referred to as the is–a relationship. The diagram above shows that a current account is an account, a personal account is a current account and so on.  Alternatively, specialized classes can be viewed as classifying the instances of the superclass: an account can either be a current account or a deposit account; a current account can either be a personal account or a business account, and so on.

30. 30 Kyung Hee University Substitutability  Generalization relationships in UML imply a notion of substitutability. For example, consider a single relationship of holding an account”.  This would normally imply that instances of the customer class could be linked to instances of the account class. Because of generalization, however, customers can be linked to accounts from any subclass.

31. 31 Kyung Hee University Substitutability  In other words, an instance of a subclass can be substituted wherever an instance of a superclass is specified or expected (in links, or operation parameters for example).

32. 32 Kyung Hee University Abstract Classes  Superclasses are introduced into a model to define the general features of a number of related classes. Often it does not make sense to create instances of these superclasses.  For example, the model of the banking system might never create simple Account classes, but only instances of one of the subclasses. In other words, every account must be either a current account, or a deposit account, or....

33. 33 Kyung Hee University Abstract Classes  In the case, Account would be modelled as an abstract class. This can be shown typographically by writing the class name in a slanted font:

34. 34 Kyung Hee University Inheritance  Attributes and operations are inherited by subclasses in a generalization relationship.  New attributes and operations can be added to support the specialized requirements of subclasses.

35. 35 Kyung Hee University Inheritance  The set of attributes and operations of the deposit account class, for example, includes both those defined in the class itself and those inherited from the account class.

36. 36 Kyung Hee University Overriding operations  Sometimes the basic functionality provided by an operation defined in a superclass is not appropriate for a specialized subclass.  In this case the operation can be overridden, or redefined, in the subclass.

37. 37 Kyung Hee University Overriding operations   The appearance of the inherited operation withdraw in the high interest account class indicates that it is redefined there, perhaps to impose a surcharge on the withdrawal of money from accounts of that type.

38. 38 Kyung Hee University Polymorphism and Multiplicity  Suppose we wanted to enforce a constraint that customers could hold at most one account of each type. The following diagram is too restrictive:  We might try to define the required multiplicity constraint by means of additional associations.

39. 39 Kyung Hee University Polymorphism and Multiplicity  This is wrong, because it defines an additional association (illegally given the same name as the original) which would permit a customer to optionally hold a current account in addition to all the account they already held.

40. 40 Kyung Hee University Association Generalization  What is required is to indicate that the new association is a specialization of the original: The “superassociation” states that a customer can hold many accounts. As the account class is abstract, these links must actually be to instances of subclasses. The multiplicity of the “subassociation” constrains these links to a maximum of one of each kind of account.  The semantics of this are rather obscure. The “superassociation” should be thought of as being abstract, although it is not clear if UML defines this possibility.

41. 41 Kyung Hee University Parallel hierarchies  Association generalization is occasionally used to relate parallel generalization hierarchies. The following diagram enforces the constraint that individuals should hold current accounts, and companies business accounts.

42. 42 Kyung Hee University Parallel hierarchies  Without the association generalizations, it would permit any type of customer to hold any type of account.  As this example shows, the notation for association generalization is visually rather complex and it should be used sparingly. The situations in which it applies are common, however, and the constraints imposed important.

43. 43 Kyung Hee University Aggregation  Aggregation is a special form of assocition which represents the part-whole relationship between classes.

44. 44 Kyung Hee University Aggregation  This diagram states that a message consists of one header, one body and zero or more attachments. Each header and body is part of exactly one message, but attachments can be part of many message. Further, headers and bodies cannot exist independently of messages, unlike attachments.  In uses like this, aggregation has virtually no formal properties other than to suggest an informal notion of “parts”. It imposes no constraints on a model in addition to those implied by a simple association.  It is tempting to overuse this form of aggregation, but as it is effectively meaningless, a better rule is “if in doubt, leave it out”.

45. 45 Kyung Hee University Instance hierarchies  In the bill of materials example, hierarchical component structures were modelled, where a component could either be a part, or an assembly containing a number of (sub)components. There was nothing in the model to prevent the following sort of structures, however:

46. 46 Kyung Hee University Instance hierarchies  This sort of recursive object structure is ruled out by the formal properties of aggregation.  Antisymmetry prevents an object being linked to itself.  Transitivity extends the association to “chains” of links, and in conjunction with antisymmetry rules out cycles in the object graph.

47. 47 Kyung Hee University Composition  Composition is a stronger form of aggregation. In a composite, the lifetime of the “part” objects is dependent on that of the “whole” objects: they cannot exist after the “whole” has been deleted.  For example, the header and the body of a mail message are deleted when the message is deleted, but the attachments are not:

48. 48 Kyung Hee University Links with data  Suppose we have a many-to-many association recording students’ registrations on modules.

49. 49 Kyung Hee University Links with data  Now suppose that in addition we wish to record the mark that each student got for the modules they took. If we store the marks in the student objects, we have the problem of recording which mark corresponds to which module. If we store the marks in the module objects, we have the problem of recording which mark correspond to which student.  A mark is more naturally associated with the link rather than either object: it’s the mark the student got for a particular module.

50. 50 Kyung Hee University Association Classes  In UML this situation can be handled by defining an association class. An association class is “an association that is also a class”, and so can contain data.

51. 51 Kyung Hee University Association Classes  An association class is represented as an association and a class, joined by a dashed line. Notice that there are not two distinct model elements here: in this diagram the name of the association is Result, and it is shown in the class icon belonging to the association class.  Association classes can also participate themselves in further associations.

52. 52 Kyung Hee University Reifying Associations  A common alternative approach to this problem is to replace the many-to-many association with a class and two further associations.  Exercise: Draw this alternative diagram Unlike the model using the association class, this mode allows two different marks to be recorded for the same student/module combination. (This might be useful if, for example, a student could retake a module after failing it.) This cannot be done with the association class because two distinct links cannot exist between the same pair of objects.

53. 53 Kyung Hee University Indexes  In Unix, the relationship between files and directories is a many- to-many relationship. Each time a file is “linked” into a directory, an identifying name is given to it.  This model does not reflect the important fact that within a directory, file names must be unique. This model would permit two different files to be linked to the same directory under the same name.

54. 54 Kyung Hee University Indexes  Because filenames within a directory must be unique, it is natural to think of the directory as implementing an index, or look-up table, of names and the location of the corresponding files.  These situations are modelled in UML by using a qualifier.

55. 55 Kyung Hee University Qualifiers  A qualifier is really an attribute of an association class, but because of its role as a “key” in identifying objects at one end of the association it is written as an attribute attached to the side of the class that, conceptually, holds the index of qualifer values.

56. 56 Kyung Hee University Qualifiers  This diagram states that: The diagram does not assert that a directory can only contain zero or one file. It means that for a given directory, each possible file name may optional be used as the name of a linked file. As there are many possible names, each directory can contain many files. As before, files can be linked in many directories, with a name specified for each link.

57. 57 Kyung Hee University Qualifiers and Identifiers  Qualifiers are often used in connection with attributes which serve to identify objects in the real world. Consider:

58. 58 Kyung Hee University Qualifiers and Identifiers  This does not make it clear that, within the context of the university, every student is expected to have a unique ID number to distinguish them from all other students.  The situation can be more accurately modelled using a qualifier.