Download - Module 3 Uml Class Diagrams
-
8/8/2019 Module 3 Uml Class Diagrams
1/72
NM3.1 B. Henderson-Sellers 1999-2003
Module M3
UML Class Diagrams
NM3.2 B. Henderson-Sellers 1999-2003
Example UML Class diagram
DriverCar
Sports Car
Door
-
8/8/2019 Module 3 Uml Class Diagrams
2/72
NM3.3 B. Henderson-Sellers 1999-2003
Static metamodel [Core]
Association
Class
Classifier
Class Interface DataType
Association
Association
End
(aggregation)
Attribute
Structural
Feature
Operation Method
Behavioural
Feature
Feature(visibility)
1 *
Generalizable
Element
Node Component
Invariant
PostconditionPrecondition
Namespace
Artifact
stereotypeof constraint
stereotype
of constraint
NM3.4 B. Henderson-Sellers 1999-2003
UML Notation useful for ClassDiagrams
A notation is used to document the results
of the analysis and design
In this module, well concentrate most onmodelling the static structure of systems
-
8/8/2019 Module 3 Uml Class Diagrams
3/72
-
8/8/2019 Module 3 Uml Class Diagrams
4/72
NM3.7 B. Henderson-Sellers 1999-2003
Attributes
represents an objects state
UML doesnt differentiate between physical
and logical attributes - UML Attributes
model both. Remember Principle of
Uniform Reference
at most abstract, just a name is used
NM3.8 B. Henderson-Sellers 1999-2003
Attributes can also have
visibility
type
scope
multiplicity
initial value
changeability
ordering
-
8/8/2019 Module 3 Uml Class Diagrams
5/72
NM3.9 B. Henderson-Sellers 1999-2003
Visibility markers+ = public
# = protected - visible to descendants
- = private - only visible to classifier itself
Can be suppressed, but must be assigned even
if not shown
Applies to Operations as well as Attributes
NM3.10 B. Henderson-Sellers 1999-2003
Example
Car
+licenceNumber:String
#dateOfManufacture:Integer
owner
speed
bodyDamage
-
8/8/2019 Module 3 Uml Class Diagrams
6/72
NM3.11 B. Henderson-Sellers 1999-2003
Derived attributes
Can be calculated from other attributes e.g.
age from dateOfBirth and currentDate
Person
/age: Year
NM3.12 B. Henderson-Sellers 1999-2003
Class with operations
Car
+moveForward()
+turnRight()
+turnLeft()
-burnPetrol()
-
8/8/2019 Module 3 Uml Class Diagrams
7/72
-
8/8/2019 Module 3 Uml Class Diagrams
8/72
NM3.15 B. Henderson-Sellers 1999-2003
Operations (continued)
name + return type + parameters is called
the operations signature
is implemented by a method (may be
several options)
where visibility is specified the same as forattributes
NM3.16 B. Henderson-Sellers 1999-2003
Example
Car
+moveForward(speed:Integer)
+turnRight(angularSpeed:Integer;
angle:Degree)
-burnPetrol()
-
8/8/2019 Module 3 Uml Class Diagrams
9/72
NM3.17 B. Henderson-Sellers 1999-2003 copyright OMG, 1999
Window
Window
size: Area
visibility: Boolean
display()hide()
Window
+size: Area=(100,100)
#visibility: Boolean=invisible
+default-size: Rectangle
#maximum-size:Rectangle
-xptr: XWindow*
+display()
+hide()
+create()-attachXWindow(xwin:Xwindow*)
{abstract,author=Joe,
status=tested}
suppressed
analysis level
implementation level
+ optional names for lists
Various Forms
NM3.18 B. Henderson-Sellers 1999-2003
UML style recommendations
Class name: bold, centred
Class name for abstract class: bold and italic, centred
Stereotype name: plain font in guillemets above class
name, centred
Class names begin with upper case
Attributes and operations left justified, plain font
unless abstract when italic. Lowercase initial letter
-
8/8/2019 Module 3 Uml Class Diagrams
10/72
NM3.19 B. Henderson-Sellers 1999-2003
UML Interfaces
show some or all of the operations in a class
(some here means that a class can have
several interfaces as in Java)
specify a service
each interface represents a role that object
plays (Booch et al., 1999, p161)
operations shown are all visible outside class
may be realized by a class or a component
define a contract [different definition to OPEN]
NM3.20 B. Henderson-Sellers 1999-2003
Interfaces (continued)
has no attributes, associations (i.e. no state)
or methods (i.e. no internal structure)
has no direct instances
programming focussed, not useful for
specification (Cheesman and Daniels, 2001)
interface
Moveable
move()
-
8/8/2019 Module 3 Uml Class Diagrams
11/72
NM3.21 B. Henderson-Sellers 1999-2003
Interface is formally equivalent to an abstract
class with no attributes and methods and
only abstract operations
(OMG, 2001, p3-51)
NM3.22 B. Henderson-Sellers 1999-2003
A class realizes an interface
ClassName
operation list of
Class
Moveable
interface
Set
addElement(Object)
etc.
ClassName
operation list of
Class
or
-
8/8/2019 Module 3 Uml Class Diagrams
12/72
NM3.23 B. Henderson-Sellers 1999-2003
In the metamodel
*
*
Class Interface
Classifier
Realization relationship for instancesKEY
NM3.24 B. Henderson-Sellers 1999-2003
Note:
Booch et al. (1999) state (p163) that type
and interface are effectively interchangeable
Oestereich (1999) states (p202) that
interface classes are abstract types, defining
exclusively abstract operations
In the metamodel, type and interface aredistinct - also see next slide
-
8/8/2019 Module 3 Uml Class Diagrams
13/72
-
8/8/2019 Module 3 Uml Class Diagrams
14/72
NM3.27 B. Henderson-Sellers 1999-2003
What is a stereotype?
Think of as another implicit (rather thanexplicit) subtype in the (M2) metamodel.
For example, a stereotyped class Bird
instanceOf
Control
Class
Class
M2
M1controlBird
hasFeathers
laysEggs
attributesoperations
[more on stereotypes later]
NM3.28 B. Henderson-Sellers 1999-2003
Roles (an overview - also see later)
Interface represents a role being played e.g.
interface
Employee
getEmploymentRecord()getLeaveRecord()
Person
-
8/8/2019 Module 3 Uml Class Diagrams
15/72
NM3.29 B. Henderson-Sellers 1999-2003
An alternative notation, often
used (but discouraged for OPENusers) is
interface
Employee
getEmploymentRecord()
getLeaveRecord()
Person Company1..*
employee
*
NM3.30 B. Henderson-Sellers 1999-2003
Modelling data types (pure values)such as built-in
primitive types e.g.
Integer
Character
String
or definable enumeration types e.g. Boolean
Use type and enumeration as class
stereotypes. Specify any value range with
constraints.
Data
Type
EnumerationPrimitive
-
8/8/2019 Module 3 Uml Class Diagrams
16/72
NM3.31 B. Henderson-Sellers 1999-2003
type
Int
e.g.
{values range from
0 to 10}
enumeration
Boolean
falsetrue
NM3.32 B. Henderson-Sellers 1999-2003
Responsibilities in UML
Class
attributes
operations()
responsibility
Responsibilities
listed here
-
8/8/2019 Module 3 Uml Class Diagrams
17/72
NM3.33 B. Henderson-Sellers 1999-2003
Class
Name
attributes
operations()
responsibilities
or
NM3.34 B. Henderson-Sellers 1999-2003
ClassifierFeature
1
11..*
1..*
Responsibility
has
is
implemented
by
Required
metamodelfragment
(not 1.4)
-
8/8/2019 Module 3 Uml Class Diagrams
18/72
NM3.35 B. Henderson-Sellers 1999-2003
UML Class diagram
Vehicle{abstract}
Car
Door
Engine
Wheel
DriverOwner
Person{abstract}
1..*
1
0..4
1
NM3.36 B. Henderson-Sellers 1999-2003
Components
A component is a kind of Classifier, yet negates the
link to Features
A component is known by its interface(s). It is a
physical and replaceable part of the system that
conforms to and realizes a set of interfaces.
A grouping mechanism - physical cf. the conceptual
grouping offered by a Package (see later in this
module)
-
8/8/2019 Module 3 Uml Class Diagrams
19/72
NM3.37 B. Henderson-Sellers 1999-2003
Notation
Component Interface Component Interface
Either or
interface
Name
operations
Often iconified
NM3.38 B. Henderson-Sellers 1999-2003
A grouping only. Packages can contain:
other packages
classes
components
Conversely, classes may indicate to which
package they belong as
PackageName :: ClassName
Packages
-
8/8/2019 Module 3 Uml Class Diagrams
20/72
NM3.39 B. Henderson-Sellers 1999-2003
Visibility is granted by making public and using
import Dependency
Editor
Nameimport
NM3.40 B. Henderson-Sellers 1999-2003
PackageClassifier
ModelSubsystem
isInstantiable:Boolean
Metamodel fragment
-
8/8/2019 Module 3 Uml Class Diagrams
21/72
NM3.41 B. Henderson-Sellers 1999-2003
Subsystem subsystem - an independent part of system
being modelled
is a kind of package
can have some features, especially
operations and associations
has interface(s)
contents are either specification elements
(e.g. operations on the subsystem, use cases,
state machines) or realization elements
NM3.42 B. Henderson-Sellers 1999-2003
Subsystem notation (new in 1.4)
Specification
elements
Realization
elements
[more detail later in Module 8]
-
8/8/2019 Module 3 Uml Class Diagrams
22/72
NM3.43 B. Henderson-Sellers 1999-2003
Notes
An adornment.
Used for a comment with no semantic effect e.g.
simple text, embedded URL, link to a document.
Notation is dog-eared card
Facilitates communication
Model
Element
Free text
here
NM3.44 B. Henderson-Sellers 1999-2003
The major relationships:
1) Association (and Aggregation)
2) Generalization
3) Dependency (and Usage)
-
8/8/2019 Module 3 Uml Class Diagrams
23/72
-
8/8/2019 Module 3 Uml Class Diagrams
24/72
NM3.47 B. Henderson-Sellers 1999-2003
Named Association
If association is named, suggest add black
triangles to indicate direction to read name
e.g.
Use verbs for association names
Can be named in both directions at same time
drivesCar Person
NM3.48 B. Henderson-Sellers 1999-2003
Multiplicity
How many objects can be present e.g.
Range of values 1..4
Many *
0 implies optionality
3,4,6Car Wheel
1
-
8/8/2019 Module 3 Uml Class Diagrams
25/72
NM3.49 B. Henderson-Sellers 1999-2003
Ordering label
Links (instances of associations) may have
an implicit order
Label them as such
Default is unordered
{ordered}Student ClassList
NM3.50 B. Henderson-Sellers 1999-2003
Qualifiers
An attribute or list of attributes of the
association whose values partition the set of
instances associated with an instance across an
association
A form of ternary association
-
8/8/2019 Module 3 Uml Class Diagrams
26/72
-
8/8/2019 Module 3 Uml Class Diagrams
27/72
NM3.53 B. Henderson-Sellers 1999-2003
UML Presentation options:
1. Show all arrows -- no arrow implies no
navigation (OML opts for this)
2. Suppress all arrows
3. Suppress two way (UML preference)
(label)
Class A Class B
NM3.54 B. Henderson-Sellers 1999-2003
Role Names(discouraged in OPEN since frequently eithertautological or redundant)
A theA B
A pseudo attribute of the source classifier
(here class B)
-
8/8/2019 Module 3 Uml Class Diagrams
28/72
NM3.55 B. Henderson-Sellers 1999-2003
Role names:
are optional
specify context
are part of the associations, not the classes
Objects of class may play different roles in
different associations
NM3.56 B. Henderson-Sellers 1999-2003
Potential link to attributes
Company employer Person
Company
employee:
list[Person]
Person
employee
becomes
employer:
Company
-
8/8/2019 Module 3 Uml Class Diagrams
29/72
-
8/8/2019 Module 3 Uml Class Diagrams
30/72
NM3.59 B. Henderson-Sellers 1999-2003
Also possible to have an Association Class
which inherits from Class and Association
Association Class
(Discouraged for OPEN users)
Association Class
NOTE. The Association Class is the Association
NM3.60 B. Henderson-Sellers 1999-2003
However, note that
association names are verbs
and
association class names are nouns
yet
association and association class are one
and the same thing and must therefore have
the same name.Therefore we have a naming paradox (Stevens
and Pooley, 2000, p84/5)
-
8/8/2019 Module 3 Uml Class Diagrams
31/72
NM3.61 B. Henderson-Sellers 1999-2003
Association class adds features (attributes
and operations) to the association itself e.g.
Employment
startDate
rank
Person University* 0..1
employer
Note. Only one association class instance between two
participating objects. In this case, we may want >1 so diagram
not accurate
NM3.62 B. Henderson-Sellers 1999-2003
Instead (as is often the case), replace association class
by regular class
Note multiplicities
Employment
startDate
rank
Person University*0..1
/employer
1 1
* 0..1
-
8/8/2019 Module 3 Uml Class Diagrams
32/72
NM3.63 B. Henderson-Sellers 1999-2003
or association
{xor} holder
Company
Person*
1
Account
This is often suggestive of a missing class
here AccountHolder
owns
is owned by
1..*
1..*
Account
Holder Account
Person
Company
Oestereich says use sparingly
NM3.64 B. Henderson-Sellers 1999-2003
Since Association inherits from
GeneralizableElement, we can have
Person Committee
member-of
chair-of
This is an example of a Constraint
1 *
-
8/8/2019 Module 3 Uml Class Diagrams
33/72
NM3.65 B. Henderson-Sellers 1999-2003
which can alternatively (as in OML) be written as
Person Committee
Chair
role
1
*
NM3.66 B. Henderson-Sellers 1999-2003
Derived Associations
One in which links can be derived from
other links
Notation: prefix the name by a solidus
Lecturer StudentSubject
/teaches student
takesteaches
course
-
8/8/2019 Module 3 Uml Class Diagrams
34/72
NM3.67 B. Henderson-Sellers 1999-2003
All these accomplished in terms of AssociationEnd
metaclass
AssociationEnd
isNavigable: Boolean
aggregation: AggregationKind
multiplicity: Multiplicity
ordering: OrderingKind
targetScope:ScopeKind
changeability:ChangeabilityKind
visibility:VisibilityKind
Finally, the aggregation indicator attribute .
NM3.68 B. Henderson-Sellers 1999-2003
Aggregations
UML. No metatype. Attribute of aggregation:
AggregationKind on AssociationEnd metatype
where AggregationKind is{none, aggregate,
composite}.
Composite (black diamond) implies component
only part of one composite/aggregate.
Aggregate implies component can be part of more
than one aggregate (a.k.a. shared aggregation) -
white diamond.
But detaileddefinitions are Contradictory.
-
8/8/2019 Module 3 Uml Class Diagrams
35/72
NM3.69 B. Henderson-Sellers 1999-2003
Composition intended to represent close connection
Shared aggregation loosely defined to pick up the rest
Called Shared aggregation
NM3.70 B. Henderson-Sellers 1999-2003
is-composed-of
NOTE. Component parts may well NOT be partof the interface of the aggregate.
What were trying to model, to a first approximation, is
1..*111
Hull Keel
Yacht
Rudder Mast
is-composed-of-parts
-
8/8/2019 Module 3 Uml Class Diagrams
36/72
NM3.71 B. Henderson-Sellers 1999-2003
or can be shown in UML as a nested set of icons
Yacht
hull
keel
rudder
mast
1
1
1
1..*
NM3.72 B. Henderson-Sellers 1999-2003
For the present, take great care in using
UMLs black and white diamonds. State
yoursemantics clearly.
-
8/8/2019 Module 3 Uml Class Diagrams
37/72
NM3.73 B. Henderson-Sellers 1999-2003
2) Generalization
A child class is a special kind of its parent
class. Subtyping means substitutability. Single
or multiple inheritance is allowed
Bank
Account
Savings
Account
Streamline
Account
Chequing
Account
NM3.74 B. Henderson-Sellers 1999-2003
Can read as A Savings Account is a Bank Account
BUT BE CAREFUL - the English language isnotoriously ambiguous e.g. A labrador is a breed (of
dog).
The test is to insert every
Every Savings Account is a Bank Account. Yes
Every labrador is a Breed Nonsense
[error is because a labrador initially
should have been the collective noun
labrador]
-
8/8/2019 Module 3 Uml Class Diagrams
38/72
NM3.75 B. Henderson-Sellers 1999-2003
Four constraints available:
1) complete
2) incomplete
3) disjoint (default semantics)
4) overlapping
NM3.76 B. Henderson-Sellers 1999-2003
Complete means
every instance of parent must be an instanceof one child class i.e. parent is abstract class(for simple case of single discriminator)
no new child class anticipated
Incomplete is complement ofComplete
-
8/8/2019 Module 3 Uml Class Diagrams
39/72
NM3.77 B. Henderson-Sellers 1999-2003
Disjoint (default)
No overlap between subtypes
An object is an instance of one and only one
subtype
NM3.78 B. Henderson-Sellers 1999-2003
Vehicle
Saloon
CarDiesel-
powered
Vehicle
Example of overlapping subtypes
-
8/8/2019 Module 3 Uml Class Diagrams
40/72
NM3.79 B. Henderson-Sellers 1999-2003
Subclass Subclass
Class
discriminator discriminator
Instead of overlapping, we could use an explicit
discriminator
The total of all subclasses created by one discriminator
is called a partition
NM3.80 B. Henderson-Sellers 1999-2003
Implementation Inheritance
Inheritance for implementation only
Thwarts substitutability
Private inheritance usually used only for
programming implementation purposes
(OMG, 2001, p2-40)
Dangerous!
-
8/8/2019 Module 3 Uml Class Diagrams
41/72
NM3.81 B. Henderson-Sellers 1999-2003
A sloppy model might say
List
Address
Bookbecause we happen to have a List class in our
class library
NM3.82 B. Henderson-Sellers 1999-2003
A better model
AddressBook
addresses: List
-
8/8/2019 Module 3 Uml Class Diagrams
42/72
NM3.83 B. Henderson-Sellers 1999-2003
The error is in using generalization, when we
are inheriting only for implementation e.g. if I
sent a message to a List and got an Address
Book, I might be unhappy. If you mustuse
implementation inheritance, flag it with the
implementation stereotype
NM3.84 B. Henderson-Sellers 1999-2003
3) Dependency (and Usage)
A term of convenience for a Relationship
other than Association, Generalization,
Flow or metarelationship (such as the
relationship between a Classifier and one of
its Instances (OMG, 2001, p2-33)
[Note this definition should also includeInclude and Extend]
-
8/8/2019 Module 3 Uml Class Diagrams
43/72
NM3.85 B. Henderson-Sellers 1999-2003
A using relationship that states that a
change in specification of one thing may
affect another thing that uses it, but not
necessarily the reverse (Booch et al., 1999,
p63)
Typical use (according to Booch) is when a
class is used as an argument in the signature
of an operation
NM3.86 B. Henderson-Sellers 1999-2003
Channel
FilmClip
name
playOn(c:Channel)
start()
stop()
reset()
Booch et al. (1999)
-
8/8/2019 Module 3 Uml Class Diagrams
44/72
NM3.87 B. Henderson-Sellers 1999-2003
There are 4 kinds of Dependency
Abstraction 2 stereotypes only discussed
Binding not discussed here
Permission not discussed here
Usage
+ various predefined stereotypes of these four
The most useful is Usage
NM3.88 B. Henderson-Sellers 1999-2003
Realization- a stereotyped Abstraction
One classifier specifies a contract that another
classifier guarantees to carry out
Realization is a stereotype of Abstraction which, in
turn, is a subtype of Dependency. Logically, the
notation should therefore be as a stereotyped
Dependency
realize
-
8/8/2019 Module 3 Uml Class Diagrams
45/72
NM3.89 B. Henderson-Sellers 1999-2003
Said to be, semantically, a cross between dependency
and generalization; hence special notation, which
overrides the generic notation (Rumbaugh, p.c.,
16/2/02):
Used in context of (a) interfaces and (b)
collaborations
NM3.90 B. Henderson-Sellers 1999-2003
Typical usage
interface
ClassName
operations
Class
Validate
user
Validation
interface
collaboration
that realizesuse case
class thatrealizes
interface
use case
-
8/8/2019 Module 3 Uml Class Diagrams
46/72
NM3.91 B. Henderson-Sellers 1999-2003
Realization occurs between dissimilar
modelling elements
In contrast, Refinement is always between
similar modelling elements
Realization often confused with Refinement
(e.g. Oestereich, 1999, p249), particularly
because in earlier versions of UML
was the notation for refinement not (ascurrently) realization
NM3.92 B. Henderson-Sellers 1999-2003
Refinement
- a stereotyped Abstraction
A second classifier adds a fuller specification
to an already specified classifier viz. two
different levels of abstraction.
Useful for
relation between design and analysis models
relation between optimized (but difficult/untidy)and clean implementation
relation between different abstract levels
(differently-grained elements)
-
8/8/2019 Module 3 Uml Class Diagrams
47/72
-
8/8/2019 Module 3 Uml Class Diagrams
48/72
-
8/8/2019 Module 3 Uml Class Diagrams
49/72
NM3.97 B. Henderson-Sellers 1999-2003
The major relationships
in UML class diagram (summary)
inheritance
shared aggregation
composite aggregation
association [bi-directional]
dependency
realization
NM3.98 B. Henderson-Sellers 1999-2003
Constructing Class diagrams OPEN Techniques:
Abstract class identification
Class naming
CRC card modelling
Generalization and inheritance identification
Relationship modelling
Responsibility identification Service identification
Textual analysis
-
8/8/2019 Module 3 Uml Class Diagrams
50/72
NM3.99 B. Henderson-Sellers 1999-2003
Mainstay of OOAD
Shows classes, interfaces, collaborations,
relationships
Use to model the vocabulary of a system
NM3.100 B. Henderson-Sellers 1999-2003
Use technique to identify concepts (classes,
interfaces)
Identify responsibilities and services (UML
features)
Look at how these classifiers collaborate -
viz. introduce relationships
-
8/8/2019 Module 3 Uml Class Diagrams
51/72
-
8/8/2019 Module 3 Uml Class Diagrams
52/72
NM3.103 B. Henderson-Sellers 1999-2003
wastewater
TreatmentPlantA
filter1:Filter filter2:Filter filter3:Filter
capacity = 200 capacity = 100 capacity = 100
NM3.104 B. Henderson-Sellers 1999-2003
Very often, object diagrams are anonymous e.g.
:Author :Bookwrites
-
8/8/2019 Module 3 Uml Class Diagrams
53/72
NM3.105 B. Henderson-Sellers 1999-2003
Specific OPEN ModellingTasks and Techniques for
using UML
[using the UML requires knowledge of appropriate
Tasks and Techniques set in the context of a
process or methodology here OPEN]
NM3.106 B. Henderson-Sellers 1999-2003
Task: Identify CIRTs
CIRT (in OPEN) = Class or Instance or
Role or Type
Abstraction to represent things in business
(problem) domain and solution domain
In UML, Classifiers have
instances
behaviour
state
-
8/8/2019 Module 3 Uml Class Diagrams
54/72
NM3.107 B. Henderson-Sellers 1999-2003
Technique: Textual analysis
Underlining the nouns. Roughly speaking
Nouns = objects/classes
Verbs = services (esp. operations)
Adjectives = attributes
NM3.108 B. Henderson-Sellers 1999-2003
Technique: Class naming
Concise and unambiguous
Aim for comprehension
Be consistent in organization
Use initial caps or underscorefor compound names
Create and adopt standards
-
8/8/2019 Module 3 Uml Class Diagrams
55/72
NM3.109 B. Henderson-Sellers 1999-2003
Automobile
Gas-powered
Automobile
Diesel-powered
Automobile
Automobile
Gas/Petrol Diesel
NM3.110 B. Henderson-Sellers 1999-2003
Book
Book
AllowanceBorrower
DonorAdult
BorrowerChild
Borrower
Library
Librarian
Book
Catalogue
Book
Collection
Administrator
Possible first draft
of a library system
Customer
-
8/8/2019 Module 3 Uml Class Diagrams
56/72
NM3.111 B. Henderson-Sellers 1999-2003
Technique: Abstraction
utilization
Different levels of granularity as contrasting
foci
Focus shifts to and fro between levels
during development
NM3.112 B. Henderson-Sellers 1999-2003
Technique: Abstract class identification
move()
Automobile
no code to
implement
this feature
code is
here
Vehicle
move()
Vehicle
{abstract}
Alternative
notation
-
8/8/2019 Module 3 Uml Class Diagrams
57/72
NM3.113 B. Henderson-Sellers 1999-2003
Class 1
{abstract}
Class 2 Class 3
Class 4Class 5
{abstract}
WRONG
NM3.114 B. Henderson-Sellers 1999-2003
Technique: Responsibility identification
LibraryCatalogue
catalogue(aBook)
What books arein stock
Possible responsibilities for the LibraryCatalogue class
responsibility
for doing
responsibility
for knowing
-
8/8/2019 Module 3 Uml Class Diagrams
58/72
NM3.115 B. Henderson-Sellers 1999-2003
Two possible notations in UML
Class Name
attributes
operations()
responsibility
Responsibilities
listed here
Class
Name
attributes
operations()
responsibilities
NM3.116 B. Henderson-Sellers 1999-2003
Manual CASE tool
Use interactively in roleplay situation
Identify Classes, their Responsibilities and the
Collaborations of the classes
In OPEN used at level of
class
package
role
Technique: CRC card modelling
-
8/8/2019 Module 3 Uml Class Diagrams
59/72
-
8/8/2019 Module 3 Uml Class Diagrams
60/72
-
8/8/2019 Module 3 Uml Class Diagrams
61/72
NM3.121 B. Henderson-Sellers 1999-2003
Placement of services
Teller
deposit()
Account
(a)
Teller
Account(b)
deposit()
NM3.122 B. Henderson-Sellers 1999-2003
Properties
Properties = adjectives (approx)
Properties = services that return information
Information may be a value e.g. INTEGER
or an object e.g. ENGINE, WING
Properties DO NOT imply stored data
-
8/8/2019 Module 3 Uml Class Diagrams
62/72
NM3.123 B. Henderson-Sellers 1999-2003
Book
+getAuthor()
+getISBN()+getTitle()
Book
Publication
details
responsibility
for knowing
Book
author
ISBN
title
Three possible representations for class Book
NM3.124 B. Henderson-Sellers 1999-2003
Technique: Relationship
modellingAssociations/mappings
named relationship
-
8/8/2019 Module 3 Uml Class Diagrams
63/72
NM3.125 B. Henderson-Sellers 1999-2003
Customer
Car
drives
uses financialservices of
Association relationships(example)
Bank
NM3.126 B. Henderson-Sellers 1999-2003
Associations needs to be unidirectional (OPEN).
These are in fact mappings (Odell)
Strictly mappings are between power types
A B
A knows about B; but that knowledge remains
encapsulated within A
-
8/8/2019 Module 3 Uml Class Diagrams
64/72
NM3.127 B. Henderson-Sellers 1999-2003
BUT Some connections are indeed sufficiently
interesting and important that they become objecttypes.
THIS IS NOT THE SAME as promoting ALLrelationships to first class object types asrecommended in OMT and by Papurt, Tanzer,Ayre et al. and others.
In the general case, relationships are objecttypes. However, in OO implementation theyshould not be implemented as first class objecttypes UNLESS they have their own specializedproperties.
NM3.128 B. Henderson-Sellers 1999-2003
PersonalProfile
Customer Bank
has a
uses financialservices of
CustomerBank
uses financialservices of
personalProfile
nameaddresscreditRating
Remember arrow
options in UML?
Associations and attributes are often interchangeable
-
8/8/2019 Module 3 Uml Class Diagrams
65/72
NM3.129 B. Henderson-Sellers 1999-2003
Technique: Usage
One object uses the services of
another.
Current debate on need for usage
as well as association
In UML, stereotype of
Dependency
use
NM3.130 B. Henderson-Sellers 1999-2003
Technique: Robustness analysis
Analyze use cases in terms of first guess set of
classes
Classify these as
boundary, control or entity classes
-
8/8/2019 Module 3 Uml Class Diagrams
66/72
NM3.131 B. Henderson-Sellers 1999-2003
HomePage Display
LoginPage
PasswordDatabase
Arrows are logical associations and do not represent message passing
e.g.
NM3.132 B. Henderson-Sellers 1999-2003
Iterate between use case and robustness
diagram until all classes discovered and
overall design verified
Stepping stone to class diagram and
sequence diagrams
-
8/8/2019 Module 3 Uml Class Diagrams
67/72
NM3.133 B. Henderson-Sellers 1999-2003
Technique: Contract specification
Software analogy to
business contract
Two participants, each willing to
undertake some obligation to geta benefit
NM3.134 B. Henderson-Sellers 1999-2003
CONTRACTING MATRIX
Attend examon June 14th
Receiveresults onJuly 1st
Mark examby July 1st
Sufficienttime in whichto mark exam
Client(Student)
Supplier(Instructor)
Obligations Benefits
If client breaks obligation, no need
for supplier to take any action at all
-
8/8/2019 Module 3 Uml Class Diagrams
68/72
NM3.135 B. Henderson-Sellers 1999-2003
c) Meyer (1988) focusses at theservice level, which thentranslates easily intopre and post conditions
Different authors view contracts at different levels
a) Wirfs-Brock et al (1990, p117)Contract = cohesive set of responsibilitiesResponsibility = some service performed
b) Bielak and McKim (1993) tighten this up in
terms of views
cardiovascularStatus
takeMedicine
age
name
strokeFurfeed
Vet
PetOwner
Cat
NM3.136 B. Henderson-Sellers 1999-2003
CONTRACT TABLE
class Class Name subsystem: Subsystem Name
operation_name- - comments
Preconditions
Postcondition- - Boolean Expression or English Text
- - Boolean Expression or English Text
-
8/8/2019 Module 3 Uml Class Diagrams
69/72
NM3.137 B. Henderson-Sellers 1999-2003
deferred class Asset subsystem: Accountant
depreciation- - comments
Preconditions
Postcondition
historicCost.value.isValid andhistoricCost.valueReal > 0.0
residualValue.isValid andresidualValue.valueReal >= 0.0
usefulLife.valueReal > 0.0historicCost >= residualValue
Result = .....- - insert here technical details of constraint
Example
NM3.138 B. Henderson-Sellers 1999-2003
Subcontracting
If A accepts contract from B,
then B does not care how A
fulfils this contract.
Hence A can do job itself orSUBCONTRACT
-
8/8/2019 Module 3 Uml Class Diagrams
70/72
NM3.139 B. Henderson-Sellers 1999-2003
Laws of Software Contracting
First Law of Contracting: Only two ways aroutine call may terminate -- contract isfulfilled; or contract is not fulfilled.
Second Law of Contracting: If routine failsto fulfil its contract, then current executionof its caller also fails to fulfil its owncontract
(Meyer, 1988, pp395-396)
NM3.140 B. Henderson-Sellers 1999-2003
Also: Invariant Specification
derived from
ranges specified in URS
STDs
Viewed as a postcondition on all
operations
In UML, a stereotype of Constraint
-
8/8/2019 Module 3 Uml Class Diagrams
71/72
NM3.141 B. Henderson-Sellers 1999-2003
HeatedSwimmingPool
temperature:Integer
{ self.temperature > 20 }
NM3.142 B. Henderson-Sellers 1999-2003
Some overall hints onrelationship modelling
Focus initially on Associations
Dont fight over Aggregations
Dont overuse Inheritance (single and
especially multiple)
Temporary inheritance suggests use of
roles
-
8/8/2019 Module 3 Uml Class Diagrams
72/72
NM3.143 B. Henderson-Sellers 1999-2003
Summary
Needed to document work products leads to
use of a graphical notation
UML is OMG standard but still has some
problems e.g. poor support for
responsibilities, aggregation, stereotypes