1. Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 Class and Object Diagrams PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 8: Class and Object Diagrams

2. Practical Object-Oriented Design with UML 2e Slide 1/2 ©The McGraw-Hill Companies, 2004 Static Models ●Static models describe a system’s data ●Object diagrams show a ‘snapshot’ of the data at a given moment ●They can show both valid and invalid states:

3. Practical Object-Oriented Design with UML 2e Slide 1/3 ©The McGraw-Hill Companies, 2004 Class diagrams ●Class diagrams specify a system’s data structures, including: –what objects can exist –what data they encapsulate –how they can be related ●Valid object diagrams are ‘instances’ of a class diagram –eg the class diagram would specify that only students can take modules

4. Practical Object-Oriented Design with UML 2e Slide 1/4 ©The McGraw-Hill Companies, 2004 UML Data Types ●UML defines familiar primitive data types –data values are instances of data types –unlike objects, values have no identity ●Data types are represented as classes: ●The values of these types are left implicit

5. Practical Object-Oriented Design with UML 2e Slide 1/5 ©The McGraw-Hill Companies, 2004 Enumerations ●New enumerations can be defined –values are enumeration literals –specified in lower section of icon ●Programming language types can also be used in UML models

6. Practical Object-Oriented Design with UML 2e Slide 1/6 ©The McGraw-Hill Companies, 2004 Multiplicity ●Multiplicities specify how often an entity can occur in some context –a general notion used throughout UML ●Represented by ranges –a range has lower and upper bounds, eg 0..9 –* represents an unbounded multiplicity, eg 1..* –0..* (‘zero or more’) is often abbreviated as * –0..1 represents an optional entity –1..1 is abbreviated to simply 1

7. Practical Object-Oriented Design with UML 2e Slide 1/7 ©The McGraw-Hill Companies, 2004 Classes ●A class describes a set of similar objects –eg that share data and operations ●The objects are the instances of the class

8. Practical Object-Oriented Design with UML 2e Slide 1/8 ©The McGraw-Hill Companies, 2004 Class multiplicity ●Class multiplicity specifies the number of instances a class can have ●The default is ‘0..*’, ie there is no limit placed on the number of instances ●Sometimes it is useful to specify a singleton class that can only have one instance

9. Practical Object-Oriented Design with UML 2e Slide 1/9 ©The McGraw-Hill Companies, 2004 Attributes ●Attributes describe data fields –in a class, attributes can have a type –which defines the values that an object can hold

10. Practical Object-Oriented Design with UML 2e Slide 1/10 ©The McGraw-Hill Companies, 2004 Attribute scope ●By default attributes have instance scope –each instance can have a different value ●An attribute with class scope has one value –shared by all instances of the class (‘static’) –attributes with class scope are underlined

11. Practical Object-Oriented Design with UML 2e Slide 1/11 ©The McGraw-Hill Companies, 2004 Attribute Multiplicity ●Attribute multiplicity defines how many values an object stores for a attribute –default is ‘exactly 1’ –‘optional’ multiplicity shows possible null values –arrays modelled by ‘many’ multiplicity

12. Practical Object-Oriented Design with UML 2e Slide 1/12 ©The McGraw-Hill Companies, 2004 Operations ●Operations define behaviour provided by every instance of the class –defined in optional lower section of class icon –parameters and return types optional

13. Practical Object-Oriented Design with UML 2e Slide 1/13 ©The McGraw-Hill Companies, 2004 Operation Scope ●Operations can have instance or class scope –static functions and constructors shown with class scope

14. Practical Object-Oriented Design with UML 2e Slide 1/14 ©The McGraw-Hill Companies, 2004 Object Identity ●Object identities are implicit –not the same as an attribute –objects can share all attribute values and still be distinct

15. Practical Object-Oriented Design with UML 2e Slide 1/15 ©The McGraw-Hill Companies, 2004 Object Identifiers ●Many classes will have attributes with unique values –corresponding to real-world identifiers –UML notation does not specify uniqueness

16. Practical Object-Oriented Design with UML 2e Slide 1/16 ©The McGraw-Hill Companies, 2004 Visibility of Class Features ●Attributes and operations can have a visibility –parallel to Java/C++ access levels ●UML defines four levels of visibility: –public (+): visible to all objects –package (~): visible to objects in same package –protected (#): visible to instances of subclasses –private (-): visible only in same object

17. Practical Object-Oriented Design with UML 2e Slide 1/17 ©The McGraw-Hill Companies, 2004 Associations ●Relationships between objects are modelled by links ●These relationships are specified by an association between the relevant classes –eg a Person can work for a Company

18. Practical Object-Oriented Design with UML 2e Slide 1/18 ©The McGraw-Hill Companies, 2004 Links ●Links can be shown connecting instances of related classes

19. Practical Object-Oriented Design with UML 2e Slide 1/19 ©The McGraw-Hill Companies, 2004 Association Ends ●Association ends can annotated with –a label, describing the role played the class at that end in the relationship –multiplicity, showing how many instances an object at the other end can be linked to

20. Practical Object-Oriented Design with UML 2e Slide 1/20 ©The McGraw-Hill Companies, 2004 Association Multiplicity ●This association states that: –a Person works for exactly 1 Company –a Company has zero or more Persons working for it ●This rules out situations like this:

21. Practical Object-Oriented Design with UML 2e Slide 1/21 ©The McGraw-Hill Companies, 2004 Navigability ●By default, associations can be navigated in either direction –ie given an object at one end you can access a linked object at the other, and vice versa ●Navigability can be restricted –sometimes we only need access in one direction

22. Practical Object-Oriented Design with UML 2e Slide 1/22 ©The McGraw-Hill Companies, 2004 Types of Association ●Most associations are binary ●Some associations relate objects of the same class –these can be shown as self-associations

23. Practical Object-Oriented Design with UML 2e Slide 1/23 ©The McGraw-Hill Companies, 2004 Labelling Associations ●All association labels are optional ●Multiplicity information is usually shown ●Labels are used where necessary ●Some labelling is required to distinguish associations between the same classes

24. Practical Object-Oriented Design with UML 2e Slide 1/24 ©The McGraw-Hill Companies, 2004 Use of Role Names ●Role names are often used to distinguish the ends of a self-association

25. Practical Object-Oriented Design with UML 2e Slide 1/25 ©The McGraw-Hill Companies, 2004 Semantics of Associations ●There can only be one instance of an association linking a given pair of objects –for example, a person might have two contracts with a given company –the model below is wrong, however

26. Practical Object-Oriented Design with UML 2e Slide 1/26 ©The McGraw-Hill Companies, 2004 Reifying Associations ●Introduce a ‘linking’ class to deal with repeated links

27. Practical Object-Oriented Design with UML 2e Slide 1/27 ©The McGraw-Hill Companies, 2004 Shared Properties ●Often groups of classes share properties –they have the same attributes and operations –they share associations with other classes

28. Practical Object-Oriented Design with UML 2e Slide 1/28 ©The McGraw-Hill Companies, 2004 Generalization ●Models this relationship between classes –define a superclass representing the general shared properties of accounts –other account types are specialized subclasses

29. Practical Object-Oriented Design with UML 2e Slide 1/29 ©The McGraw-Hill Companies, 2004 The Meaning of Generalization ●The superclass defines the properties shared by all the specialized classes –eg customers can hold accounts of any sort

30. Practical Object-Oriented Design with UML 2e Slide 1/30 ©The McGraw-Hill Companies, 2004 Substitutability ●This model connects customers to accounts –but an instance of any subclass can be substituted for an account object – these links demonstrate polymorphism

31. Practical Object-Oriented Design with UML 2e Slide 1/31 ©The McGraw-Hill Companies, 2004 Abstract Classes ●Superclasses are often defined solely to group together shared features –it may not make sense to have an instance of a superclass –in this case, define the class as abstract

32. Practical Object-Oriented Design with UML 2e Slide 1/32 ©The McGraw-Hill Companies, 2004 Generalization Hierarchies ●Generalization can be carried out at more than one level

33. Practical Object-Oriented Design with UML 2e Slide 1/33 ©The McGraw-Hill Companies, 2004 Inheritance ●Inherited features also belong to subclasses

34. Practical Object-Oriented Design with UML 2e Slide 1/34 ©The McGraw-Hill Companies, 2004 Modifying Subclasses Subclasses can: – add features to model special properties – override operations to implement specialized behaviour

35. Practical Object-Oriented Design with UML 2e Slide 1/35 ©The McGraw-Hill Companies, 2004 Abstract Operations ●Some operations cannot be implemented in abstract classes –define them as abstract and override them

36. Practical Object-Oriented Design with UML 2e Slide 1/36 ©The McGraw-Hill Companies, 2004 Aggregation ●Informal ‘whole-part’ relationships can be modelled using aggregation –a specialized form of an association –can have standard annotations on ends

37. Practical Object-Oriented Design with UML 2e Slide 1/37 ©The McGraw-Hill Companies, 2004 Cyclic Object Structures ●Aggregation is useful for ruling out invalid cyclic object structures –eg where an assembly contains itself, directly or indirectly

38. Practical Object-Oriented Design with UML 2e Slide 1/38 ©The McGraw-Hill Companies, 2004 Properties of Aggregation ●Aggregation rules this out because it is –antisymmetric: an object can’t link to itself –transitive: if a links to b and b to c, a links to c

39. Practical Object-Oriented Design with UML 2e Slide 1/39 ©The McGraw-Hill Companies, 2004 Meaning of Aggregation ●Sometimes there is a conflict ●E.g. people cannot be their own ancestors –this can be specified using aggregation –but a person’s ancestors are not parts of them!

40. Practical Object-Oriented Design with UML 2e Slide 1/40 ©The McGraw-Hill Companies, 2004 Meaning of Aggregation ●A hand may be considered as part of a person and a person may be considered as part of an orchestra, but we would not consider hand as part of an orchestra. ●Heuristic: If the part moves, can one deduce that the whole moves with it in normal circumstances.

41. Practical Object-Oriented Design with UML 2e Slide 1/41 ©The McGraw-Hill Companies, 2004 Composition ●Composition is a strong form of aggregation –parts can only belong to one composite at a time –parts are destroyed when a composite is

42. Practical Object-Oriented Design with UML 2e Slide 1/42 ©The McGraw-Hill Companies, 2004 Types of Composition ●These types of composition from Odell are not mutually exclusive. They are based on three decisions: ●Configurational: does the composition represent a structural relationship? ●Homeometric: are the parts the same type as the whole? ●Invariant: can parts be detached from the whole?

43. Practical Object-Oriented Design with UML 2e Slide 1/43 ©The McGraw-Hill Companies, 2004 Component Relationships ●Component parts can be related even if they don’t belong to the same composite –sometimes this is not what is needed

44. Practical Object-Oriented Design with UML 2e Slide 1/44 ©The McGraw-Hill Companies, 2004 Associations and Composites ●An alternative notation allows associations to be defined inside composites

45. Practical Object-Oriented Design with UML 2e Slide 1/45 ©The McGraw-Hill Companies, 2004 Composite Boundaries ●Associations can cross the boundary to link objects in different composites

46. Practical Object-Oriented Design with UML 2e Slide 1/46 ©The McGraw-Hill Companies, 2004 Properties of Links ●Sometimes data belongs to a link –a student takes a module and gets a mark for it –the mark only makes sense if we know the student and the module –so it’s not simply an attribute of either class

47. Practical Object-Oriented Design with UML 2e Slide 1/47 ©The McGraw-Hill Companies, 2004 Association Classes ●Association classes share the properties of associations and classes –they can define links between objects –they allow attribute values to be stored

48. Practical Object-Oriented Design with UML 2e Slide 1/48 ©The McGraw-Hill Companies, 2004 Reification ●Students’ marks could alternatively be stored in an intermediate class: –this has the property of allowing students to take a module more than once

49. Practical Object-Oriented Design with UML 2e Slide 1/49 ©The McGraw-Hill Companies, 2004 Association Class Properties ●Association classes are classes and so can participate in associations

50. Practical Object-Oriented Design with UML 2e Slide 1/50 ©The McGraw-Hill Companies, 2004 N-ary Associations ●Associations can connect more than two classes –A 3-way association could be used to store marks

51. Practical Object-Oriented Design with UML 2e Slide 1/51 ©The McGraw-Hill Companies, 2004 Modelling Unix Files ●Unix files can appear in many directories, under different names ●This could be modelled with an association class

52. Practical Object-Oriented Design with UML 2e Slide 1/52 ©The McGraw-Hill Companies, 2004 Qualified Associations ●There are two problems with this: –it doesn’t allow the same file to appear twice in a directory (under different names) –it doesn’t specify that names can only be used once in each directory ●Using a qualified association solves these

53. Practical Object-Oriented Design with UML 2e Slide 1/53 ©The McGraw-Hill Companies, 2004 Qualifiers ●The ‘name’ attribute is known as a qualifier ●It acts like a ‘key’: within a directory, each name maps to zero or one file –this guarantees that names are unique within directories ●Files are linked to names within directories, so multiple occurrences within a directory are possible

54. Practical Object-Oriented Design with UML 2e Slide 1/54 ©The McGraw-Hill Companies, 2004 Qualified links ●Here is a typical structure of objects linked with qualifiers

55. Practical Object-Oriented Design with UML 2e Slide 1/55 ©The McGraw-Hill Companies, 2004 Qualifiers and Identifiers ●Use a qualifier to model an identifying attribute that is unique within some context

56. Practical Object-Oriented Design with UML 2e Slide 1/56 ©The McGraw-Hill Companies, 2004 Interfaces ●An interface in UML is a named set of operations –shown as a stereotyped class ●Generalization can be defined between interfaces

57. Practical Object-Oriented Design with UML 2e Slide 1/57 ©The McGraw-Hill Companies, 2004 Realizing an Interface ●A class realizes an interface if it provides implementations of all the operations ●UML provides two equivalent ways of showing this relationship

58. Practical Object-Oriented Design with UML 2e Slide 1/58 ©The McGraw-Hill Companies, 2004 Interface Dependency ●A class can be dependent on an interface –this means that it only makes use of the operations defined in that interface

59. Practical Object-Oriented Design with UML 2e Slide 1/59 ©The McGraw-Hill Companies, 2004 Interface Specifiers ●This dependency can also be shown using an interface specifier on an association

60. Practical Object-Oriented Design with UML 2e Slide 1/60 ©The McGraw-Hill Companies, 2004 Templates ●Parameterized model elements can be shown as templates –these are commonly used to show generic or template classes and operations (as in C++)

61. Practical Object-Oriented Design with UML 2e Slide 1/61 ©The McGraw-Hill Companies, 2004 Associations ●In the UML we represent the relationships between classes by associations. An association represents the fact that an instance of one class is linked with a set of instances of another class. The UML formally defines an association to be a semantic relationship between two classifiers that involves the connections among their instances. In the case of class diagrams, the classifiers are classes and their instances are objects. Associations can be annotated using notes, names, roles, multiplicities, direction arrows. They can represent composition, aggregation, derived data, qualified associations and navigation.

62. Practical Object-Oriented Design with UML 2e Slide 1/62 ©The McGraw-Hill Companies, 2004 Associations: names ●The UML allows you to name an association by placing the name in the middle of the association line. Association names are usually verbs. They represent the use that objects at one end of the association make of the objects at the other end of the association. A potential difficulty with a verb is that one does not know which way to read it. Does an Employee work for a Company? Or does a Company work for an Employee? Both make sense in different models. The UML allows a little black triangular arrow to be added to the association name to indicate which way to read it. The arrows show which direction of reading makes sense of the association name. Often you need to be able to read the association in both directions, so you really need two different association names. Unfortunately, the UML only allows one per association. One is usually the passive form of the other. Why use them? To clarify the nature of the association.

63. Practical Object-Oriented Design with UML 2e Slide 1/63 ©The McGraw-Hill Companies, 2004 Associations: roles ●Naming associations with verbs is useful, but it does not really fit in with the object perspective. A role name for the role of an object is placed at the opposite end of an association to the object for which it plays that role. When you are discussing an object design, you are not usually concerned with considering all the possible links between two classes/objects. Instead, you tend to take on the perspective of one class/object. You are interested in the role that objects play for each other. The default role name is usually the associated class name in lower case. Why use them? Allows us to focus on a single association.

64. Practical Object-Oriented Design with UML 2e Slide 1/64 ©The McGraw-Hill Companies, 2004 Associations: multiplicity ●You can specify a multiplicity for each end of an association. By stating a multiplicity, you are saying how many instances (objects) of one class can be linked with a single instance (object) of a class at the other end of the association. Like roles they are written at the other end of the association. They are written 0..*, 1..*, 1..6. Why use them? We need to know the degree of the association..

65. Practical Object-Oriented Design with UML 2e Slide 1/65 ©The McGraw-Hill Companies, 2004 Associations: Navigation ●A navigational expression is used to refer to notations in which you name an object or object attribute by starting at another object and hop from one object to another. You use role names to identify the next object and attribute names to identify which attribute of the object is of interest. We must be clear about the direction of potential messages between instances of one class and instances of another where there is an association between the two of them.

66. Practical Object-Oriented Design with UML 2e Slide 1/66 ©The McGraw-Hill Companies, 2004 Associations: multiplicity ●In the UML, you can put an open arrowhead at one or both ends of an association to indicate that it is possible to reach one class from another following the direction of the arrow. In doing so, you are restricting access to instances of the class at end of the association where you placed the arrowhead. Navigational expressions are only about naming remote attributes. They are not directly related to the sending of messages. Contrast with the Law of Demeter, which offers guidelines on the use of objects reachable only by following chains of role names. Why use them? As class diagrams become complex, we need to check for loops.