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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

Practical Object-Oriented Design with UML 2e Slide 1/23 ©The McGraw-Hill Companies, 2004 Types of Association model Graph class Vertex operations newTarget() end associationclass Edge between Vertex[*] role source Vertex[*] role target end associationclass Face between Edge[*] role edge1 Edge[*] role edge2 Edge[*] role edge3 end

Practical Object-Oriented Design with UML 2e Slide 1/24 ©The McGraw-Hill Companies, 2004 Types of Association

Practical Object-Oriented Design with UML 2e Slide 1/25 ©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

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

Practical Object-Oriented Design with UML 2e Slide 1/27 ©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

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

Practical Object-Oriented Design with UML 2e Slide 1/29 ©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

Practical Object-Oriented Design with UML 2e Slide 1/30 ©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

Practical Object-Oriented Design with UML 2e Slide 1/31 ©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

Practical Object-Oriented Design with UML 2e Slide 1/32 ©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

Practical Object-Oriented Design with UML 2e Slide 1/33 ©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

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

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

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

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

Practical Object-Oriented Design with UML 2e Slide 1/38 ©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

Practical Object-Oriented Design with UML 2e Slide 1/39 ©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

Practical Object-Oriented Design with UML 2e Slide 1/40 ©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 part end whole end

Practical Object-Oriented Design with UML 2e Slide 1/41 ©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! –The aggregation does not make sense in the case

Practical Object-Oriented Design with UML 2e Slide 1/42 ©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.

Practical Object-Oriented Design with UML 2e Slide 1/43 ©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

Practical Object-Oriented Design with UML 2e Slide 1/44 ©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?

Practical Object-Oriented Design with UML 2e Slide 1/45 ©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

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

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

Practical Object-Oriented Design with UML 2e Slide 1/48 ©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

Practical Object-Oriented Design with UML 2e Slide 1/49 ©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

Practical Object-Oriented Design with UML 2e Slide 1/50 ©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

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

Practical Object-Oriented Design with UML 2e Slide 1/52 ©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

Practical Object-Oriented Design with UML 2e Slide 1/53 ©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

Practical Object-Oriented Design with UML 2e Slide 1/54 ©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

Practical Object-Oriented Design with UML 2e Slide 1/55 ©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

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

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

Practical Object-Oriented Design with UML 2e Slide 1/58 ©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

Practical Object-Oriented Design with UML 2e Slide 1/59 ©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

Practical Object-Oriented Design with UML 2e Slide 1/60 ©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

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

Practical Object-Oriented Design with UML 2e Slide 1/62 ©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++)

Practical Object-Oriented Design with UML 2e Slide 1/63 ©The McGraw-Hill Companies, 2004 Associations (Summary) ●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.

Practical Object-Oriented Design with UML 2e Slide 1/64 ©The McGraw-Hill Companies, 2004 Associations: names (Summary) ●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.

Practical Object-Oriented Design with UML 2e Slide 1/65 ©The McGraw-Hill Companies, 2004 Associations: roles (Summary) ●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.

Practical Object-Oriented Design with UML 2e Slide 1/66 ©The McGraw-Hill Companies, 2004 Associations: multiplicity (Summary) ●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..*, Why use them? We need to know the degree of the association..

Practical Object-Oriented Design with UML 2e Slide 1/67 ©The McGraw-Hill Companies, 2004 Associations: Navigation (Summary) ●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.

Practical Object-Oriented Design with UML 2e Slide 1/68 ©The McGraw-Hill Companies, 2004 Associations: multiplicity (Summary) ●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.

Practical Object-Oriented Design with UML 2e Slide 1/69 ©The McGraw-Hill Companies, 2004 Association (Summary) ●Basic purpose : In the UML the relationships between classes is represented 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. ●Annotations: Associations can be annotated using notes, association names, name directions, role names, multiplicities, direction arrows. ●What can they represent: They can represent composition, aggregation, derived associations, qualified associations and navigation.

Practical Object-Oriented Design with UML 2e Slide 1/70 ©The McGraw-Hill Companies, 2004 Association (Summary) RepresentationSome Uses NameTo clarify the nature of the association Role NameGives the analyst a view from the perspective of a single class and a single association (focus is in only one direction). MultiplicityAllows the analyst to represent the degree of the association. Which is frequently required in analysis. NavigationAllow analyst to access attributes of remote objects. As class diagrams become complex, we need to check for loops.

Practical Object-Oriented Design with UML 2e Slide 1/71 ©The McGraw-Hill Companies, 2004 Association (Summary) ●Name: The UML allows you to name an association by placing the name in the middle of the association line. Association names are often 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 e.g. ConsistsOf. The UML uses a black triangular arrow 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. Sometimes two perspectives needed:The action is viewed in relation to the thing effected (active voice). Representing the subject as an object of the action (passive voice).(e.g. The doctor Heads the team (or) The team is Headed by the doctor). Why use them? To clarify the nature of the association.

Practical Object-Oriented Design with UML 2e Slide 1/72 ©The McGraw-Hill Companies, 2004 Association (Summary) ●Role: 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 considering object design, we are not usually concerned with considering all the possible links between two classes/objects. Instead, we tend to take on the perspective of one class/object. We are interested in the role that objects play for each other. For example, in Appendix A, one role that a Doctor plays for a Patient has been named treatedBy and is placed at the Doctor end of the Treats association. The default role name is usually the associated class name in lower case. Why use them? Allows us to focus on a single association. ●Multiplicities: 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..*, One doctor treats many patients. Why use them? We need to know the degree of the associations.

Practical Object-Oriented Design with UML 2e Slide 1/73 ©The McGraw-Hill Companies, 2004 Association (Summary) ●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 move (or navigate) from one object to another. We 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. 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. Example Why use them? As class diagrams become complex, we need to check for loops. OCL allows the mixing of attributes that reference other objects and roles names, this can cause confusion. Further this ‘feature’ requires that both navigation mechanisms are harmonized by using constraints.

Practical Object-Oriented Design with UML 2e Slide 1/74 ©The McGraw-Hill Companies, 2004 Association (Summary) ●Whole-Part relationship: WP relationships frequently occur in application domains. The UML provides a two ways to record the nature of a WP relationship. ●Aggregation: We can describe a 'whole–part' relationship where the part is not mandatory. For example the whole could be an invoice which is made up from the invoice lines (the parts). It would be possible to add, remove or replace one of the ‘parts’ and still have a meaningful relationship: an invoice would still be an aggregation of invoice lines if another invoice line were to be added. For aggregation, you simply add an open diamond to the end of the association to indicate the class that is to act as the whole. ●Composition: We can describe a 'whole–part' relationship where the part is mandatory. For example the association that holds between a chess-board and the squares on it. If you were to remove (or add) a square you would no longer have a recognizable chess-board. A chess-board and its squares are much more intimately related than an invoice and its invoice lines because a chess board cannot exist unless it has 64 squares. The chess-board and square association is a particular kind of aggregation known as a composition. Composition, as a stronger form of aggregation, is shown as a solid black diamond.