Transcript PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e

Practical Object-Oriented Design with UML 2e
PRACTICAL
OBJECT-ORIENTED
DESIGN WITH UML
2e
Chapter 8:
Class and Object Diagrams
Class and Object Diagrams
©The McGraw-Hill Companies, 2004
Slide 1/1
Practical Object-Oriented Design with UML 2e
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:
©The McGraw-Hill Companies, 2004
Slide 1/2
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/3
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/4
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/5
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/6
Practical Object-Oriented Design with UML 2e
Classes
● A class describes a set of similar objects
– eg that share data and operations
● The objects are the instances of the class
©The McGraw-Hill Companies, 2004
Slide 1/7
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/8
Practical Object-Oriented Design with UML 2e
Attributes
● Attributes describe data fields
– in a class, attributes can have a type
– which defines the values that an object can hold
©The McGraw-Hill Companies, 2004
Slide 1/9
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/10
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/11
Practical Object-Oriented Design with UML 2e
Operations
● Operations define behaviour provided by
every instance of the class
– defined in optional lower section of class icon
– parameters and return types optional
©The McGraw-Hill Companies, 2004
Slide 1/12
Practical Object-Oriented Design with UML 2e
Operation Scope
● Operations can have instance or class scope
– static functions and constructors shown with
class scope
©The McGraw-Hill Companies, 2004
Slide 1/13
Practical Object-Oriented Design with UML 2e
Object Identity
● Object identities are implicit
– not the same as an attribute
– objects can share all attribute values and still be
distinct
©The McGraw-Hill Companies, 2004
Slide 1/14
Practical Object-Oriented Design with UML 2e
Object Identifiers
● Many classes will have attributes with unique
values
– corresponding to real-world identifiers
– UML notation does not specify uniqueness
©The McGraw-Hill Companies, 2004
Slide 1/15
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/16
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/17
Practical Object-Oriented Design with UML 2e
Links
● Links can be shown connecting instances of
related classes
©The McGraw-Hill Companies, 2004
Slide 1/18
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/19
Practical Object-Oriented Design with UML 2e
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:
©The McGraw-Hill Companies, 2004
Slide 1/20
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/21
Practical Object-Oriented Design with UML 2e
Types of Association
● Most associations are binary
● Some associations relate objects of the same
class
– these can be shown as self-associations
©The McGraw-Hill Companies, 2004
Slide 1/22
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/23
Practical Object-Oriented Design with UML 2e
Use of Role Names
● Role names are often used to distinguish the
ends of a self-association
©The McGraw-Hill Companies, 2004
Slide 1/24
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/25
Practical Object-Oriented Design with UML 2e
Reifying Associations
● Introduce a ‘linking’ class to deal with
repeated links
©The McGraw-Hill Companies, 2004
Slide 1/26
Practical Object-Oriented Design with UML 2e
Shared Properties
● Often groups of classes share properties
– they have the same attributes and operations
– they share associations with other classes
©The McGraw-Hill Companies, 2004
Slide 1/27
Practical Object-Oriented Design with UML 2e
Generalization
● Models this relationship between classes
– define a superclass representing the general
shared properties of accounts
– other account types are specialized subclasses
©The McGraw-Hill Companies, 2004
Slide 1/28
Practical Object-Oriented Design with UML 2e
The Meaning of Generalization
● The superclass defines the properties shared
by all the specialized classes
– eg customers can hold accounts of any sort
©The McGraw-Hill Companies, 2004
Slide 1/29
Practical Object-Oriented Design with UML 2e
Substitutability
● This model connects customers to accounts
– but an instance of any subclass can be
substituted for an account object
– these links demonstrate polymorphism
©The McGraw-Hill Companies, 2004
Slide 1/30
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/31
Practical Object-Oriented Design with UML 2e
Generalization Hierarchies
● Generalization can be carried out at more
than one level
©The McGraw-Hill Companies, 2004
Slide 1/32
Practical Object-Oriented Design with UML 2e
Inheritance
● Inherited features also belong to subclasses
©The McGraw-Hill Companies, 2004
Slide 1/33
Practical Object-Oriented Design with UML 2e
Modifying Subclasses
• Subclasses can:
– add features to
model special
properties
– override operations
to implement
specialized
behaviour
©The McGraw-Hill Companies, 2004
Slide 1/34
Practical Object-Oriented Design with UML 2e
Abstract Operations
● Some operations cannot be implemented in
abstract classes
– define them as abstract and override them
©The McGraw-Hill Companies, 2004
Slide 1/35
Practical Object-Oriented Design with UML 2e
Aggregation
● Informal ‘whole-part’ relationships can be
modelled using aggregation
– a specialized form of an association
– can have standard annotations on ends
©The McGraw-Hill Companies, 2004
Slide 1/36
Practical Object-Oriented Design with UML 2e
Cyclic Object Structures
● Aggregation is useful for ruling out invalid
cyclic object structures
– eg where an assembly contains itself, directly or
indirectly
©The McGraw-Hill Companies, 2004
Slide 1/37
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/38
Practical Object-Oriented Design with UML 2e
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 McGraw-Hill Companies, 2004
Slide 1/39
Practical Object-Oriented Design with UML 2e
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.
©The McGraw-Hill Companies, 2004
Slide 1/40
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/41
Practical Object-Oriented Design with UML 2e
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?
©The McGraw-Hill Companies, 2004
Slide 1/42
Practical Object-Oriented Design with UML 2e
Component Relationships
● Component parts can be related even if they
don’t belong to the same composite
– sometimes this is not what is needed
©The McGraw-Hill Companies, 2004
Slide 1/43
Practical Object-Oriented Design with UML 2e
Associations and Composites
● An alternative notation allows associations to
be defined inside composites
©The McGraw-Hill Companies, 2004
Slide 1/44
Practical Object-Oriented Design with UML 2e
Composite Boundaries
● Associations can cross the boundary to link
objects in different composites
©The McGraw-Hill Companies, 2004
Slide 1/45
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/46
Practical Object-Oriented Design with UML 2e
Association Classes
● Association classes share the properties of
associations and classes
– they can define links between objects
– they allow attribute values to be stored
©The McGraw-Hill Companies, 2004
Slide 1/47
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/48
Practical Object-Oriented Design with UML 2e
Association Class Properties
● Association classes are classes and so can
participate in associations
©The McGraw-Hill Companies, 2004
Slide 1/49
Practical Object-Oriented Design with UML 2e
N-ary Associations
● Associations can connect more than two
classes
– A 3-way association could be used to store
marks
©The McGraw-Hill Companies, 2004
Slide 1/50
Practical Object-Oriented Design with UML 2e
Modelling Unix Files
● Unix files can appear in many directories,
under different names
● This could be modelled with an association
class
©The McGraw-Hill Companies, 2004
Slide 1/51
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/52
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/53
Practical Object-Oriented Design with UML 2e
Qualified links
● Here is a typical structure of objects linked
with qualifiers
©The McGraw-Hill Companies, 2004
Slide 1/54
Practical Object-Oriented Design with UML 2e
Qualifiers and Identifiers
● Use a qualifier to model an identifying
attribute that is unique within some context
©The McGraw-Hill Companies, 2004
Slide 1/55
Practical Object-Oriented Design with UML 2e
Interfaces
● An interface in UML is a named set of
operations
– shown as a stereotyped class
● Generalization can be defined between
interfaces
©The McGraw-Hill Companies, 2004
Slide 1/56
Practical Object-Oriented Design with UML 2e
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
©The McGraw-Hill Companies, 2004
Slide 1/57
Practical Object-Oriented Design with UML 2e
Interface Dependency
● A class can be dependent on an interface
– this means that it only makes use of the
operations defined in that interface
©The McGraw-Hill Companies, 2004
Slide 1/58
Practical Object-Oriented Design with UML 2e
Interface Specifiers
● This dependency can also be shown using
an interface specifier on an association
©The McGraw-Hill Companies, 2004
Slide 1/59
Practical Object-Oriented Design with UML 2e
Templates
● Parameterized model elements can be
shown as templates
– these are commonly used to show generic or
template classes and operations (as in C++)
©The McGraw-Hill Companies, 2004
Slide 1/60
Practical Object-Oriented Design with UML 2e
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.
©The McGraw-Hill Companies, 2004
Slide 1/61
Practical Object-Oriented Design with UML 2e
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.
©The McGraw-Hill Companies, 2004
Slide 1/62
Practical Object-Oriented Design with UML 2e
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.
©The McGraw-Hill Companies, 2004
Slide 1/63
Practical Object-Oriented Design with UML 2e
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..
©The McGraw-Hill Companies, 2004
Slide 1/64
Practical Object-Oriented Design with UML 2e
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.
©The McGraw-Hill Companies, 2004
Slide 1/65
Practical Object-Oriented Design with UML 2e
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.
©The McGraw-Hill Companies, 2004
Slide 1/66