You are on page 1of 72

Module M3

UML Class Diagrams

© B. Henderson-Sellers 1999-2003 NM3.1

Example UML Class diagram

Car
Driver

Door

Sports Car

© B. Henderson-Sellers 1999-2003 NM3.2

Static metamodel [Core]
Namespace
Generalizable stereotype
of constraint
Element Feature
(visibility)
Invariant

Classifier
Structural Behavioural
Feature Feature

Class Interface DataType Node Component Artifact

1* Method
Operation
Attribute
Association
End
(aggregation) Precondition Postcondition
Association
Association Class
stereotype
of constraint
© B. Henderson-Sellers 1999-2003 NM3.3

UML Notation useful for Class
Diagrams

A notation is used to document the results
of the analysis and design

In this module, we’ll concentrate most on
modelling the static structure of systems

© B. Henderson-Sellers 1999-2003 NM3.4

Classes, Interfaces and Objects: UML
[UML focussed on attributes and operations]

Interface1
Classname
Objectname «instanceOf»
Attributes
Attributes Operations
Interface2

Extra boxes can be added
or existing ones omitted

copyright OMG, 1997

© B. Henderson-Sellers 1999-2003 NM3.5

Class with Attributes

Car

licenceNumber
dateOfManufacture
owner
speed

Typically, each instance of class Car will have
specific values for each attribute

© B. Henderson-Sellers 1999-2003 NM3.6

just a name is used © B.8 .UML Attributes model both. Henderson-Sellers 1999-2003 NM3. Attributes • represents an object’s state • UML doesn’t differentiate between physical and logical attributes .7 Attributes can also have • visibility • type • scope • multiplicity • initial value • changeability • ordering © B. Remember Principle of Uniform Reference • at most abstract. Henderson-Sellers 1999-2003 NM3.

only visible to classifier itself Can be suppressed. Henderson-Sellers 1999-2003 NM3.= private .9 Example Car +licenceNumber:String #dateOfManufacture:Integer owner speed bodyDamage © B.10 . Visibility markers + = public # = protected .visible to descendants . Henderson-Sellers 1999-2003 NM3. but must be assigned even if not shown Applies to Operations as well as Attributes © B.

g. Henderson-Sellers 1999-2003 NM3. age from dateOfBirth and currentDate Person /age: Year © B. Henderson-Sellers 1999-2003 NM3. Derived attributes • Can be calculated from other attributes e.11 Class with operations Car +moveForward() +turnRight() +turnLeft () -burnPetrol() © B.12 .

just a name is used © B.14 . Henderson-Sellers 1999-2003 NM3. Operations • represent an object’s behaviour or the services it offers • invoked by the sending of a message by another object (or internally) • at most abstract. Henderson-Sellers 1999-2003 NM3.13 Operations can also have • isQuery (attribute) • visibility • scope • parameters • return type • concurrency semantics • other properties © B.

Henderson-Sellers 1999-2003 NM3.16 . angle:Degree) -burnPetrol() © B. Operations (continued) • name + return type + parameters is called the operation’s signature • is implemented by a method (may be several options) where visibility is specified the same as for attributes © B. Henderson-Sellers 1999-2003 NM3.15 Example Car +moveForward(speed:Integer) +turnRight(angularSpeed:Integer.

Window status=tested} +size: Area=(100. 1999 NM3.18 . Henderson-Sellers 1999-2003 NM3. centred • Class names begin with upper case • Attributes and operations left justified. Lowercase initial letter © B. centred • Class name for abstract class: bold and italic. Henderson-Sellers 1999-2003 copyright OMG. centred • Stereotype name: plain font in guillemets above class name. plain font unless abstract when italic.17 UML style recommendations • Class name: bold.100) analysis level #visibility: Boolean=invisible +default-size: Rectangle Window #maximum-size:Rectangle -xptr: XWindow* size: Area visibility: Boolean +display() +hide() display() +create() hide() -attachXWindow(xwin:Xwindow*) + optional names for lists © B. author=Joe. implementation level Various Forms suppressed Window {abstract.

no internal structure) • has no direct instances • programming focussed. not useful for specification (Cheesman and Daniels.. no state) or methods (i.e.19 Interfaces (continued) • has no attributes.e. associations (i. 2001) «interface» Moveable move() © B. Henderson-Sellers 1999-2003 NM3. p161) • operations shown are all visible outside class • may be realized by a class or a component • define a contract [different definition to OPEN] © B. 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. Henderson-Sellers 1999-2003 NM3.20 . 1999.

Henderson-Sellers 1999-2003 NM3. 2001. p3-51) © B. Henderson-Sellers 1999-2003 NM3. Class or ClassName Moveable operation list of Class © B. Interface is formally equivalent to an abstract class with no attributes and methods and only abstract operations (OMG.21 A class realizes an interface «interface» ClassName Set addElement(Object) operation list of etc.22 .

In the metamodel * Classifier * Class Interface KEY Realization relationship for instances © B.also see next slide © B. Henderson-Sellers 1999-2003 NM3. (1999) state (p163) that type and interface are effectively interchangeable • Oestereich (1999) states (p202) that interface classes are abstract types. type and interface are distinct .24 .23 Note: • Booch et al. defining exclusively abstract operations • In the metamodel. Henderson-Sellers 1999-2003 NM3.

structure etc. In V1. Implementation stereotypes Type this is ambiguously named Class either «implementation» or of Class «implementationClass» KEY Realization relationship applicable only to M1 only © B. Henderson-Sellers 1999-2003 NM3. (attributes and associations) © B.4.25 UML Classes can be stereotyped as Types or Implementation class «type» «implementation class» Set HashTableSet elements:Collection elements:Collection addElement(Object) inheritance of addElement(Object) operations. * Type. Interface and Classifier Implementation Class need stereotype.26 . Henderson-Sellers 1999-2003 NM3. not etc. * not is-a-kind-of since Type negates some of Class’ features Class Interface Two NOTE. Classifier and Class have basic rectangle.

g. Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3. What is a stereotype? • Think of as another implicit (rather than explicit) subtype in the (M2) metamodel.27 Roles (an overview .28 . «interface» Employee Person getEmploymentRecord() getLeaveRecord() © B. • For example. a stereotyped class Bird Control Class Class attributes operations M2 « instanceOf» «control» M1 Bird hasFeathers laysEggs [more on stereotypes later] © B.also see later) Interface represents a role being played e.

g.. Specify any value range with constraints. Henderson-Sellers 1999-2003 NM3.g. often used (but discouraged for OPEN users) is «interface» Employee 1.29 Modelling data types (pure values) such as built-in Data Type primitive types e.30 . Henderson-Sellers 1999-2003 NM3. Boolean Use «type» and «enumeration» as class stereotypes. © B. • Integer • Character Primitive Enumeration • String • or definable enumeration types e. An alternative notation.* * Person Company employee getEmploymentRecord() getLeaveRecord() © B.

31 Responsibilities in UML «responsibility» Responsibilities listed here Class attributes operations() © B. «type» Int {values range from 0 to 10} «enumeration» Boolean false true © B. Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3.32 .g. e.

* is implemented has by 1. Henderson-Sellers 1999-2003 NM3..4) 1 1.* 1 Feature Classifier © B. or Class Name attributes operations() responsibilities © B..34 .33 Required metamodel Responsibility fragment (not 1. Henderson-Sellers 1999-2003 NM3.

. Henderson-Sellers 1999-2003 NM3. It is a physical and replaceable part of the system that conforms to and realizes a set of interfaces.* Car 1 Driver Owner 1 Engine 0. the conceptual grouping offered by a Package (see later in this module) © B.physical cf.36 .. UML Class diagram Vehicle {abstract} Person {abstract} Door 1. yet negates the link to Features • A component is known by its interface(s). Henderson-Sellers 1999-2003 NM3. • A grouping mechanism .35 Components • A component is a kind of Classifier.4 Wheel © B.

38 . classes may indicate to which package they belong as PackageName :: ClassName © B.37 Packages A grouping only. Packages can contain: • other packages • classes • components Conversely. Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3. Notation Either or Component Interface Component Interface «interface» Name operations Often iconified © B.

39 Metamodel fragment Classifier Package Subsystem Model isInstantiable:Boolean © B. Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3.40 . Visibility is granted by making public and using «import» Dependency Editor «import» Name © B.

g.4) Realization elements Specification elements [more detail later in Module 8] © B. state machines) or realization elements © B. Henderson-Sellers 1999-2003 NM3. use cases.42 .41 Subsystem notation (new in 1. Subsystem • subsystem . Henderson-Sellers 1999-2003 NM3.an independent part of system being modelled • is a kind of package • can have some features. operations on the subsystem. especially operations and associations • has interface(s) • contents are either specification elements (e.

g. • Notation is “dog-eared card” • Facilitates communication Free text here Model Element © B. • Used for a comment with no semantic effect e.43 The major relationships: 1) Association (and “Aggregation”) 2) Generalization 3) Dependency (and Usage) © B. link to a document.44 . Henderson-Sellers 1999-2003 NM3. Notes • An adornment. Henderson-Sellers 1999-2003 NM3. embedded URL. simple text.

1) Association (and “Aggregation”)
A structural relationship. Instances of
association are a set of tuples relating instances
of the classifiers
Can have name

* name 1..*

© B. Henderson-Sellers 1999-2003 NM3.45

Association ends important
Can have multiplicity, ordering label,
qualifier, navigability (arrowheads), visibility,
rolename, interface specifier, changeability,
aggregation indicator
Note: ternary associations permitted [but not
recommended for OPEN users]

© B. Henderson-Sellers 1999-2003 NM3.46

Named Association
If association is named, suggest add black
triangles to indicate direction to read name
e.g.

drives
Car Person

Use verbs for association names
Can be named in both directions at same time
© B. Henderson-Sellers 1999-2003 NM3.47

Multiplicity
• How many objects can be present e.g.

1 3,4,6
Car Wheel

Range of values 1..4
Many *
0 implies optionality

© B. Henderson-Sellers 1999-2003 NM3.48

Ordering label
• Links (instances of associations) may have
an implicit order
• Label them as such

{ordered}
Student ClassList

• Default is unordered

© B. Henderson-Sellers 1999-2003 NM3.49

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

© B. Henderson-Sellers 1999-2003 NM3.50

They provide an “index on the travel of an association” ChessBoard instance + rank = 3 and file = 2 uniquely determines Square instance As unqualified association Chess 1 64 Square Board rank:Rank file:File © B.. Chess rank:{1.8} Here rank and file are attributes of the association. e. Henderson-Sellers 1999-2003 NM3.8} 1 1 Square Board file:{1.g.52 ..51 Navigability • The direction in which traversal is easy and straightforward A B • A will contain direct reference(s) to B • B will not contain direct reference(s) to A • A navigable association is a prerequisite for the exchange of messages © B. Henderson-Sellers 1999-2003 NM3.

Suppress all arrows 3.53 Role Names (discouraged in OPEN since frequently either tautological or redundant) A theA B A pseudo attribute of the source classifier (here class B) © B.54 . Show all arrows -. Henderson-Sellers 1999-2003 NM3. Suppress two way (UML preference) (label) Class A Class B © B. Henderson-Sellers 1999-2003 NM3.no arrow implies no navigation (OML opts for this) 2. UML Presentation options: 1.

not the classes Objects of class may play different roles in different associations © B.56 . Henderson-Sellers 1999-2003 NM3. Role names: • are optional • specify context • are part of the associations.55 Potential link to attributes Company employer Person employee becomes Company Person employee: employer: list[Person] Company © B. Henderson-Sellers 1999-2003 NM3.

Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3. a subset (e. Roles also used more powerfully in Collaboration diagrams and OPEN Technique: Role modelling (see later – Module 8) © B.57 Interface specifier • For a class with many interfaces.g. one) may be required as part of operation Person Car driver:IDriver role name interface name Use of rolename and specifier equivalent to creating a small collaboration © B.58 .

59 However. Therefore we have a naming paradox (Stevens and Pooley.60 . The Association Class is the Association © B. Association Class Also possible to have an Association Class which inherits from Class and Association (Discouraged for OPEN users) Association Class NOTE. Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3. p84/5) © B. 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. 2000.

. In this case. Henderson-Sellers 1999-2003 NM3. Only one association class instance between two participating objects.1 Employment * 1 Person University startDate rank Note multiplicities © B..1 1 0.g..1 Person University Employment startDate rank Note.62 . Association class adds features (attributes and operations) to the association itself e. we may want >1 so diagram not accurate © B.61 Instead (as is often the case). replace association class by regular class /employer * 0. employer * 0. Henderson-Sellers 1999-2003 NM3.

* © B..“or” association Oestereich says “use sparingly” * Person Account {xor} holder 1 Company This is often suggestive of a missing class — here “AccountHolder” Person 1. Henderson-Sellers 1999-2003 NM3.64 .63 Since Association inherits from GeneralizableElement..* Account owns Account Holder is owned by Company 1. we can have member-of Person Committee 1 chair-of * This is an example of a Constraint © B. Henderson-Sellers 1999-2003 NM3.

66 . which can alternatively (as in OML) be written as Person ε Committee * role Chair 1 © B.65 Derived Associations • One in which links can be derived from other links • Notation: prefix the name by a solidus teaches takes Lecturer Subject Student course /teaches student © B. Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3.

All these accomplished in terms of AssociationEnd metaclass AssociationEnd isNavigable : Boolean aggregation: AggregationKind multiplicity: Multiplicity ordering: OrderingKind targetScope:ScopeKind changeability:ChangeabilityKind visibility:VisibilityKind Finally. Composite (black diamond) implies component only part of one composite/aggregate. © B. © B. composite}.a.67 Aggregations UML. But detailed definitions are Contradictory. No metatype. shared aggregation) - white diamond. Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3. the aggregation indicator attribute …. Aggregate implies component can be part of more than one aggregate (a.68 .k. Attribute of aggregation: AggregationKind on AssociationEnd metatype where AggregationKind is{none. aggregate.

is is-composed-of Yacht is-composed-of-parts 1 1 1 1. © B. to a first approximation. Component parts may well NOT be part of the interface of the aggregate.70 .. Henderson-Sellers 1999-2003 NM3.* Hull Keel Rudder Mast NOTE. Composition intended to represent close connection Shared aggregation loosely defined to “pick up the rest” Called Shared aggregation © B. Henderson-Sellers 1999-2003 NM3.69 What we’re trying to model.

* mast © B. State your semantics clearly.. Henderson-Sellers 1999-2003 NM3. © B. take great care in using UML’s black and white diamonds. Henderson-Sellers 1999-2003 NM3.71 • For the present. or can be shown in UML as a nested set of icons Yacht 1 hull 1 keel 1 rudder 1.72 .

Henderson-Sellers 1999-2003 NM3.g.73 Can read as “A Savings Account is a Bank Account” BUT BE CAREFUL . The test is to insert “every” “Every Savings Account is a Bank Account”.74 . 2) Generalization A “child” class is a special kind of its “parent” class. Henderson-Sellers 1999-2003 NM3. “A labrador is a breed (of dog)”. Yes “Every labrador is a Breed” Nonsense [error is because “a labrador” initially should have been the collective noun “labrador”] © B. Subtyping means substitutability. Single or multiple inheritance is allowed Bank Account Savings Chequing Account Account Streamline Account © B.the English language is notoriously ambiguous e.

e.75 Complete means • every instance of parent must be an instance of one child class i. Henderson-Sellers 1999-2003 NM3. Four constraints available: 1) complete 2) incomplete 3) disjoint (default semantics) 4) overlapping © B. parent is abstract class (for simple case of single discriminator) • no new child class anticipated Incomplete is complement of Complete © B.76 . Henderson-Sellers 1999-2003 NM3.

Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3. Disjoint (default) • No overlap between subtypes • An object is an instance of one and only one subtype © B.78 .77 Example of overlapping subtypes Vehicle Saloon Diesel- Car powered Vehicle © B.

Henderson-Sellers 1999-2003 NM3. p2-40) • Dangerous! © B. Instead of overlapping. we could use an explicit discriminator Class discriminator discriminator Subclass Subclass The total of all subclasses created by one discriminator is called a partition © B.79 Implementation Inheritance • Inheritance for implementation only • Thwarts substitutability • “Private inheritance usually used only for programming implementation purposes” (OMG. 2001.80 . Henderson-Sellers 1999-2003 NM3.

Henderson-Sellers 1999-2003 NM3.82 . A sloppy model might say List Address Book because we happen to have a List class in our class library © B.81 A better model AddressBook addresses: List © B. Henderson-Sellers 1999-2003 NM3.

If you must use implementation inheritance.83 3) Dependency (and Usage) • “A term of convenience for a Relationship other than Association. I might be unhappy. Henderson-Sellers 1999-2003 NM3.84 . p2-33) [Note this definition should also include Include and Extend] © B. flag it with the «implementation» stereotype © B. The “error” is in using generalization. Flow or metarelationship (such as the relationship between a Classifier and one of its Instances” (OMG. if I sent a message to a List and got an Address Book. Generalization. Henderson-Sellers 1999-2003 NM3. when we are inheriting only for implementation e.g. 2001.

85 FilmClip name Channel playOn(c:Channel) start() stop() reset() © Booch et al. • “A using relationship that states that a change in specification of one thing may affect another thing that uses it. Henderson-Sellers 1999-2003 NM3. p63) • Typical use (according to Booch) is when a class is used as an argument in the signature of an operation © B..86 . (1999) © B. Henderson-Sellers 1999-2003 NM3. but not necessarily the reverse” (Booch et al. 1999.

the notation should therefore be as a stereotyped Dependency «realize» © B. is a subtype of Dependency. Logically. in turn. Henderson-Sellers 1999-2003 NM3.a stereotyped Abstraction “One classifier specifies a contract that another classifier guarantees to carry out” Realization is a stereotype of Abstraction which. 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 © B. Henderson-Sellers 1999-2003 NM3.88 .87 Realization .

89 Typical usage «interface» interface Validate use case ClassName user operations collaboration class that that realizes realizes Class Validation use case interface © B..c. Henderson-Sellers 1999-2003 NM3. 16/2/02): Used in context of (a) interfaces and (b) collaborations © B. which overrides the generic notation (Rumbaugh. Henderson-Sellers 1999-2003 NM3. semantically. hence special notation.90 . Said to be. a cross between dependency and generalization. p.

• 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) © B. two different levels of abstraction.91 Refinement . Oestereich. particularly because in earlier versions of UML was the notation for refinement not (as currently) realization © B. • Realization occurs between dissimilar modelling elements • In contrast. Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3. Refinement is always between similar modelling elements • Realization often confused with Refinement (e.92 .a stereotyped Abstraction • A second classifier adds a fuller specification to an already specified classifier viz. 1999.g. p249).

) © B. e. Analysis Model «refine» Design Model Notation is a stereotyped Abstraction (a kind of Dependency (q.g. – class calling operation on a second class – method having argument of another class – method instantiating another class • four predefined stereotypes but list is said to be open-ended © B.v. Henderson-Sellers 1999-2003 NM3.94 . Henderson-Sellers 1999-2003 NM3.g.93 Usage («use») • one element requires another element or set of elements for its full implementation or operation • e.

96 . the the remainder are all kinds of Dependency. (1999. Henderson-Sellers 1999-2003 NM3. are kinds of dependencies. Henderson-Sellers 1999-2003 NM3. Note that this model was first proposed by Henderson-Sellers (1998) but is NOT the one supported in the OMG metamodel. p140) state that all relationships.95 Also • «instanceOf» said to be notation for an (undefined!) Instance Relationship where «instanceOf» source object is instance of target classifier © B. Model these three kinds first. association and realization. including generalization. Note. Booch et al. © B.

The major relationships in UML class diagram (summary) association [bi-directional] shared aggregation composite aggregation inheritance dependency realization © B.98 . Henderson-Sellers 1999-2003 NM3.97 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 © B. Henderson-Sellers 1999-2003 NM3.

interfaces) • Identify responsibilities and services (UML features) • Look at how these classifiers collaborate - viz. introduce relationships © B. • Mainstay of OOAD • Shows classes. relationships • Use to model the vocabulary of a system © B. Henderson-Sellers 1999-2003 NM3. interfaces. Henderson-Sellers 1999-2003 NM3. collaborations.100 .99 • Use technique to identify concepts (classes.

• Keep consistent level of abstraction • Lay out graphical elements to minimize crossing lines and keep related concepts together • Add notes and possibly colour • Use sensible names .don’t truncate or elide © B.101 Object diagrams • Shows objects and relationships (links) at a point in time • Use to model object structures when relevant (example on next slide) © B. Henderson-Sellers 1999-2003 NM3.102 . Henderson-Sellers 1999-2003 NM3.

object diagrams are anonymous e. writes :Author :Book © B. Henderson-Sellers 1999-2003 NM3.103 Very often.104 .g. wastewater TreatmentPlantA filter1:Filter filter2:Filter filter3:Filter capacity = 200 capacity = 100 capacity = 100 © B. Henderson-Sellers 1999-2003 NM3.

106 . Classifiers have – instances – behaviour – state © B. Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3.105 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. Specific OPEN Modelling Tasks 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] © B.

Technique: Textual analysis “Underlining the nouns”. Henderson-Sellers 1999-2003 NM3.108 . Henderson-Sellers 1999-2003 NM3.107 Technique: Class naming Concise and unambiguous Aim for comprehension Use initial caps or underscore for compound names Be consistent in organization Create and adopt standards © B. Roughly speaking • Nouns = objects/classes • Verbs = services (esp. operations) • Adjectives = attributes © B.

Automobile Automobile Gas-powered Diesel-powered Gas/Petrol Diesel Automobile Automobile © B. Henderson-Sellers 1999-2003 NM3.109 Possible first draft of a library system Librarian Administrator Book Library Customer Book Book Allowance Catalogue Borrower Adult Child Book Donor Borrower Borrower Collection © B.110 . Henderson-Sellers 1999-2003 NM3.

Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3.112 . Technique: Abstraction utilization • Different levels of granularity as contrasting foci • Focus shifts to and fro between levels during development © B.111 Technique: Abstract class identification Vehicle no code to Alternative move() implement notation this feature Vehicle {abstract} Automobile code is move() here © B.

Class 1 {abstract} Class 2 Class 3 WRONG Class 5 Class 4 {abstract} © B.113 Technique: Responsibility identification Possible responsibilities for the LibraryCatalogue class responsibility LibraryCatalogue for doing catalogue(aBook) What books are in stock responsibility for knowing © B. Henderson-Sellers 1999-2003 NM3.114 . Henderson-Sellers 1999-2003 NM3.

Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3. their Responsibilities and the Collaborations of the classes • In OPEN used at level of – class – package – role © B.116 . Two possible notations in UML «responsibility» Class Responsibilities Name listed here Class Name attributes attributes operations() operations() responsibilities © B.115 Technique: CRC card modelling • “Manual CASE tool” • Use interactively in roleplay situation • Identify Classes.

117 Identifies collaborations such as Librarian Book Library © B. CRC Card Class Name Responsibility1 Collaborator(s) for Responsibility1 Responsibility2 Collaborator(s) for Responsibility2 etc. Henderson-Sellers 1999-2003 NM3. © B. Henderson-Sellers 1999-2003 NM3. etc.118 .

Henderson-Sellers 1999-2003 NM3. Technique: Service identification Ability of CIRT (~Classifier) to respond to request for action. PLUS Create.120 . Henderson-Sellers 1999-2003 NM3. Principle of uniform reference but CIRT Name for modelling may wish to property - discriminate between properties and name(arg:Class):Class operations.119 Operations Operations = verbs (approx) Represent functionality Queries and commands One operation = one job Anthropomorphism .“can I suffer this operation?” © B. Update and Delete © B. Read. operation - name(arg:Class) Keep to idea of ADT + “need to know” principle + associated contracts.

122 .g. WING Properties DO NOT imply stored data © B.121 Properties Properties = adjectives (approx) Properties = services that return information Information may be a value e. Placement of services (a) Teller deposit() Account (b) Account deposit() Teller © B. Henderson-Sellers 1999-2003 NM3. ENGINE. Henderson-Sellers 1999-2003 NM3. INTEGER or an object e.g.

Henderson-Sellers 1999-2003 NM3. Book author ISBN title Book responsibility for knowing Publication details Book +getAuthor() +getISBN() +getTitle() Three possible representations for class Book © B.123 Technique: Relationship modelling Associations/mappings named relationship © B. Henderson-Sellers 1999-2003 NM3.124 .

but that knowledge remains encapsulated within A • Strictly mappings are between power types © B. Henderson-Sellers 1999-2003 NM3.125 • Associations needs to be unidirectional (OPEN). • These are in fact mappings (Odell) A B A “knows about” B.126 . Henderson-Sellers 1999-2003 NM3. Association relationships (example) uses financial Customer services of Bank drives Car © B.

BUT • Some connections are indeed sufficiently interesting and important that they become object types. and others. Henderson-Sellers 1999-2003 NM3. © B. However. Tanzer. in OO implementation they should not be implemented as first class object types UNLESS they have their own specialized properties.127 Associations and attributes are often interchangeable Customer uses financial services of Bank personalProfile uses financial services of Customer Bank has a PersonalProfile Remember arrow name address creditRating options in UML? © B. Henderson-Sellers 1999-2003 NM3. Ayre et al. • THIS IS NOT THE SAME as promoting ALL relationships to first class object types as recommended in OMT and by Papurt. relationships are object types.128 . • In the general case.

control or entity classes © B. Henderson-Sellers 1999-2003 NM3. • Current debate on need for usage as well as association • In UML. Henderson-Sellers 1999-2003 NM3. Technique: Usage • One object uses the services of another.130 .129 Technique: Robustness analysis • Analyze use cases in terms of “first guess” set of classes • Classify these as boundary. stereotype of Dependency «use» © B.

HomePage Display LoginPage PasswordDatabase Arrows are logical associations and do not represent message passing © B. Henderson-Sellers 1999-2003 NM3.g. e. Henderson-Sellers 1999-2003 NM3.132 .131 • Iterate between use case and robustness diagram until all classes discovered and overall design verified • Stepping stone to class diagram and sequence diagrams © B.

134 . Technique: Contract specification Software analogy to business contract Two participants.133 CONTRACTING MATRIX Obligations Benefits Receive Attend exam results on on June 14th July 1st Client (Student) Supplier (Instructor) Mark exam Sufficient by July 1st time in which to mark exam If client breaks obligation. Henderson-Sellers 1999-2003 NM3. Henderson-Sellers 1999-2003 NM3. each willing to undertake some obligation to get a benefit © B. no need for supplier to take any action at all © B.

.Boolean Expression or English Text © B. Henderson-Sellers 1999-2003 NM3.135 CONTRACT TABLE class Class Name subsystem: Subsystem Name operation_name .. p117) Contract = cohesive set of responsibilities Responsibility = some service performed b) Bielak and McKim (1993) tighten this up in terms of “views” Vet Cat cardiovascular Status takeMedicine age PetOwner name strokeFur feed c) Meyer (1988) focusses at the service level.Boolean Expression or English Text Postcondition . Henderson-Sellers 1999-2003 NM3. which then translates easily into pre and post conditions © B.136 .. Different authors view contracts at different levels a) Wirfs-Brock et al (1990.comments Preconditions .

..comments Preconditions historicCost.isValid and residualValue.value.0 residualValue.. Henderson-Sellers 1999-2003 NM3.valueReal >= 0.138 . Example deferred class Asset subsystem: Accountant depreciation ..137 Subcontracting If A accepts contract from B.isValid and historicCost.insert here technical details of constraint © B. then B does not care how A fulfils this contract.valueReal > 0. Hence A can do job itself or SUBCONTRACT © B. .valueReal > 0.0 usefulLife..0 historicCost >= residualValue Postcondition Result = .. Henderson-Sellers 1999-2003 NM3.

then current execution of its caller also fails to fulfil its own contract (Meyer. pp395-396) © B. or contract is not fulfilled. Henderson-Sellers 1999-2003 NM3.139 Also: Invariant Specification derived from ranges specified in URS STDs Viewed as a postcondition on all operations In UML.contract is fulfilled. Henderson-Sellers 1999-2003 NM3. 1988.140 . Second Law of Contracting: If routine fails to fulfil its contract. a stereotype of Constraint © B. Laws of Software Contracting First Law of Contracting: Only two ways a routine call may terminate -.

142 . Henderson-Sellers 1999-2003 NM3.temperature > 20 } © B. Henderson-Sellers 1999-2003 NM3.141 Some overall hints on relationship modelling • Focus initially on Associations • Don’t fight over Aggregations • Don’t overuse Inheritance (single and especially multiple) • Temporary “inheritance” suggests use of roles © B. HeatedSwimmingPool temperature:Integer { self.

143 .g. aggregation. stereotypes © B. poor support for responsibilities. Summary Needed to document work products leads to use of a graphical notation UML is OMG standard but still has some problems e. Henderson-Sellers 1999-2003 NM3.