practical object-oriented design with uml 2e slide 1/1 ©the mcgraw-hill companies, 2004 class and...

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



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:



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



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



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



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



Classes

● A class describes a set of similar objects– eg that share data and operations

● The objects are the instances of the class



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



Attributes

● Attributes describe data fields– in a class, attributes can have a type– which defines the values that an object can hold


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


Slide 1/11


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


Slide 1/12


Operations

● Operations define behaviour provided by every instance of the class– defined in optional lower section of class icon– parameters and return types optional


Slide 1/13


Operation Scope

● Operations can have instance or class scope– static functions and constructors shown with

class scope


Slide 1/14


Object Identity

● Object identities are implicit– not the same as an attribute– objects can share all attribute values and still be

distinct


Slide 1/15


Object Identifiers

● Many classes will have attributes with unique values– corresponding to real-world identifiers– UML notation does not specify uniqueness


Slide 1/16


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


Slide 1/17


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


Slide 1/18


Links

● Links can be shown connecting instances of related classes


Slide 1/19


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


Slide 1/20


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:


Slide 1/21


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


Slide 1/22


Types of Association

● Most associations are binary● Some associations relate objects of the same

class– these can be shown as self-associations


Slide 1/23


Types of Associationmodel Graph

class Vertexoperations newTarget()end

associationclass Edge between Vertex[*] role source Vertex[*] role targetend

associationclass Facebetween Edge[*] role edge1 Edge[*] role edge2 Edge[*] role edge3end


Slide 1/24


Types of Association


Slide 1/25


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


Slide 1/26


Use of Role Names

● Role names are often used to distinguish the ends of a self-association


Slide 1/27


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


Slide 1/28


Reifying Associations

● Introduce a ‘linking’ class to deal with repeated links


Slide 1/29


Shared Properties

● Often groups of classes share properties– they have the same attributes and operations– they share associations with other classes


Slide 1/30


Generalization

● Models this relationship between classes– define a superclass representing the general

shared properties of accounts– other account types are specialized subclasses


Slide 1/31


The Meaning of Generalization

● The superclass defines the properties shared by all the specialized classes– eg customers can hold accounts of any sort


Slide 1/32


Substitutability

● This model connects customers to accounts– but an instance of any subclass can be

substituted for an account object– these links demonstrate polymorphism


Slide 1/33


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


Slide 1/34


Generalization Hierarchies

● Generalization can be carried out at more than one level


Slide 1/35


Inheritance● Inherited features also belong to subclasses


Slide 1/36


Modifying Subclasses

• Subclasses can:– add features to

model special properties

– override operations to implement specialized behaviour


Slide 1/37


Abstract Operations

● Some operations cannot be implemented in abstract classes– define them as abstract and override them


Slide 1/38


Aggregation

● Informal ‘whole-part’ relationships can be modelled using aggregation– a specialized form of an association– can have standard annotations on ends


Slide 1/39


Cyclic Object Structures

● Aggregation is useful for ruling out invalid cyclic object structures– eg where an assembly contains itself, directly or

indirectly


Slide 1/40


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


Slide 1/41


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


Slide 1/42


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.


Slide 1/43


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


Slide 1/44


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?


Slide 1/45


Component Relationships

● Component parts can be related even if they don’t belong to the same composite– sometimes this is not what is needed


Slide 1/46


Associations and Composites

● An alternative notation allows associations to be defined inside composites


Slide 1/47


Composite Boundaries

● Associations can cross the boundary to link objects in different composites


Slide 1/48


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


Slide 1/49


Association Classes

● Association classes share the properties of associations and classes– they can define links between objects– they allow attribute values to be stored


Slide 1/50


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


Slide 1/51


Association Class Properties

● Association classes are classes and so can participate in associations


Slide 1/52


N-ary Associations

● Associations can connect more than two classes– A 3-way association could be used to store

marks


Slide 1/53


Modelling Unix Files

● Unix files can appear in many directories, under different names

● This could be modelled with an association class


Slide 1/54


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


Slide 1/55


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


Slide 1/56


Qualified links

● Here is a typical structure of objects linked with qualifiers


Slide 1/57


Qualifiers and Identifiers

● Use a qualifier to model an identifying attribute that is unique within some context


Slide 1/58


Interfaces

● An interface in UML is a named set of operations– shown as a stereotyped class

● Generalization can be defined between interfaces


Slide 1/59


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


Slide 1/60


Interface Dependency

● A class can be dependent on an interface– this means that it only makes use of the

operations defined in that interface


Slide 1/61


Interface Specifiers

● This dependency can also be shown using an interface specifier on an association


Slide 1/62


Templates

● Parameterized model elements can be shown as templates– these are commonly used to show generic or

template classes and operations (as in C++)


Slide 1/63


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.


Slide 1/64


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.


Slide 1/65


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.


Slide 1/66


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..*, 1..6. Why use them? We need to know the degree of the association..


Slide 1/67


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.


Slide 1/68


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.


Slide 1/69


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.


Slide 1/70


Association (Summary)

Representation Some Uses

Name To clarify the nature of the association

Role Name Gives the analyst a view from the perspective of a single class and a single association (focus is in only one direction).

Multiplicity Allows the analyst to represent the degree of the association. Which is frequently required in analysis.

Navigation Allow analyst to access attributes of remote objects.

As class diagrams become complex, we need to check for loops.


Slide 1/71


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.


Slide 1/72


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..*, 1..6. One doctor treats many patients. Why use them? We need to know the degree of the associations.


Slide 1/73


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.


Slide 1/74


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.

practical object-oriented design with uml 2e slide 1/1 ©the mcgraw-hill companies, 2004 class and...

Documents