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


Example UML Class diagram

DriverCar

Sports Car

Door


2/72


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


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


3/72


4/72


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


Attributes can also have

visibility

type

scope

multiplicity

initial value

changeability

ordering


5/72


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


Example

Car

+licenceNumber:String

#dateOfManufacture:Integer

owner

speed

bodyDamage


6/72


Derived attributes

Can be calculated from other attributes e.g.

age from dateOfBirth and currentDate

Person

/age: Year


Class with operations

Car

+moveForward()

+turnRight()

+turnLeft()

-burnPetrol()


7/72


8/72


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


Example

Car

+moveForward(speed:Integer)

+turnRight(angularSpeed:Integer;

angle:Degree)

-burnPetrol()


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


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


10/72


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]


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()


11/72


Interface is formally equivalent to an abstract

class with no attributes and methods and

only abstract operations

(OMG, 2001, p3-51)


A class realizes an interface

ClassName

operation list of

Class

Moveable

interface

Set

addElement(Object)

etc.

ClassName

operation list of

Class

or


12/72


In the metamodel

*

*

Class Interface

Classifier

Realization relationship for instancesKEY


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


13/72


14/72


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]


Roles (an overview - also see later)

Interface represents a role being played e.g.

interface

Employee

getEmploymentRecord()getLeaveRecord()

Person


15/72


An alternative notation, often

used (but discouraged for OPENusers) is

interface

Employee

getEmploymentRecord()

getLeaveRecord()

Person Company1..*

employee

*


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


16/72


type

Int

e.g.

{values range from

0 to 10}

enumeration

Boolean

falsetrue


Responsibilities in UML

Class

attributes

operations()

responsibility

Responsibilities

listed here


17/72


Class

Name

attributes

operations()

responsibilities

or


ClassifierFeature

1

11..*

1..*

Responsibility

has

is

implemented

by

Required

metamodelfragment

(not 1.4)


18/72


UML Class diagram

Vehicle{abstract}

Car

Door

Engine

Wheel

DriverOwner

Person{abstract}

1..*

1

0..4

1


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)


19/72


Notation

Component Interface Component Interface

Either or

interface

Name

operations

Often iconified


A grouping only. Packages can contain:

other packages

classes

components

Conversely, classes may indicate to which

package they belong as

PackageName :: ClassName

Packages


20/72


Visibility is granted by making public and using

import Dependency

Editor

Nameimport


PackageClassifier

ModelSubsystem

isInstantiable:Boolean

Metamodel fragment


21/72


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


Subsystem notation (new in 1.4)

Specification

elements

Realization

elements

[more detail later in Module 8]


22/72


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


The major relationships:

1) Association (and Aggregation)

2) Generalization

3) Dependency (and Usage)


23/72


24/72


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


Multiplicity

How many objects can be present e.g.

Range of values 1..4

Many *

0 implies optionality

3,4,6Car Wheel

1


25/72


Ordering label

Links (instances of associations) may have

an implicit order

Label them as such

Default is unordered

{ordered}Student ClassList


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


26/72


27/72


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


Role Names(discouraged in OPEN since frequently eithertautological or redundant)

A theA B

A pseudo attribute of the source classifier

(here class B)


28/72


Role names:

are optional

specify context

are part of the associations, not the classes

Objects of class may play different roles in

different associations


Potential link to attributes

Company employer Person

Company

employee:

list[Person]

Person

employee

becomes

employer:

Company


29/72


30/72


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


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)


31/72


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


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


32/72


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


Since Association inherits from

GeneralizableElement, we can have

Person Committee

member-of

chair-of

This is an example of a Constraint

1 *


33/72


which can alternatively (as in OML) be written as

Person Committee

Chair

role

1

*


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


34/72


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 .


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.


35/72


Composition intended to represent close connection

Shared aggregation loosely defined to pick up the rest

Called Shared aggregation


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


36/72


or can be shown in UML as a nested set of icons

Yacht

hull

keel

rudder

mast

1

1

1

1..*


For the present, take great care in using

UMLs black and white diamonds. State

yoursemantics clearly.


37/72


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


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]


38/72


Four constraints available:

1) complete

2) incomplete

3) disjoint (default semantics)

4) overlapping


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


39/72


Disjoint (default)

No overlap between subtypes

An object is an instance of one and only one

subtype


Vehicle

Saloon

CarDiesel-

powered

Vehicle

Example of overlapping subtypes


40/72


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


Implementation Inheritance

Inheritance for implementation only

Thwarts substitutability

Private inheritance usually used only for

programming implementation purposes

(OMG, 2001, p2-40)

Dangerous!


41/72


A sloppy model might say

List

Address

Bookbecause we happen to have a List class in our

class library


A better model

AddressBook

addresses: List


42/72


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


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]


43/72


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


Channel

FilmClip

name

playOn(c:Channel)

start()

stop()

reset()

Booch et al. (1999)


44/72


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


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


45/72


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


Typical usage

interface

ClassName

operations

Class

Validate

user

Validation

interface

collaboration

that realizesuse case

class thatrealizes

interface

use case


46/72


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


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)


47/72


48/72


49/72


The major relationships

in UML class diagram (summary)

inheritance

shared aggregation

composite aggregation

association [bi-directional]

dependency

realization


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


50/72


Mainstay of OOAD

Shows classes, interfaces, collaborations,

relationships

Use to model the vocabulary of a system


Use technique to identify concepts (classes,

interfaces)

Identify responsibilities and services (UML

features)

Look at how these classifiers collaborate -

viz. introduce relationships


51/72


52/72


wastewater

TreatmentPlantA

filter1:Filter filter2:Filter filter3:Filter

capacity = 200 capacity = 100 capacity = 100


Very often, object diagrams are anonymous e.g.

:Author :Bookwrites


53/72


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]


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


54/72


Technique: Textual analysis

Underlining the nouns. Roughly speaking

Nouns = objects/classes

Verbs = services (esp. operations)

Adjectives = attributes


Technique: Class naming

Concise and unambiguous

Aim for comprehension

Be consistent in organization

Use initial caps or underscorefor compound names

Create and adopt standards


55/72


Automobile

Gas-powered

Automobile

Diesel-powered

Automobile

Automobile

Gas/Petrol Diesel


Book

Book

AllowanceBorrower

DonorAdult

BorrowerChild

Borrower

Library

Librarian

Book

Catalogue

Book

Collection

Administrator

Possible first draft

of a library system

Customer


56/72


Technique: Abstraction

utilization

Different levels of granularity as contrasting

foci

Focus shifts to and fro between levels

during development


Technique: Abstract class identification

move()

Automobile

no code to

implement

this feature

code is

here

Vehicle

move()

Vehicle

{abstract}

Alternative

notation


57/72


Class 1

{abstract}

Class 2 Class 3

Class 4Class 5

{abstract}

WRONG


Technique: Responsibility identification

LibraryCatalogue

catalogue(aBook)

What books arein stock

Possible responsibilities for the LibraryCatalogue class

responsibility

for doing

responsibility

for knowing


58/72


Two possible notations in UML

Class Name

attributes

operations()

responsibility

Responsibilities

listed here

Class

Name

attributes

operations()

responsibilities


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


59/72


60/72


61/72


Placement of services

Teller

deposit()

Account

(a)

Teller

Account(b)

deposit()


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


62/72


Book

+getAuthor()

+getISBN()+getTitle()

Book

Publication

details

responsibility

for knowing

Book

author

ISBN

title

Three possible representations for class Book


Technique: Relationship

modellingAssociations/mappings

named relationship


63/72


Customer

Car

drives

uses financialservices of

Association relationships(example)

Bank


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


64/72


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.


PersonalProfile

Customer Bank

has a


CustomerBank


personalProfile

nameaddresscreditRating

Remember arrow

options in UML?

Associations and attributes are often interchangeable


65/72


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


Technique: Robustness analysis

Analyze use cases in terms of first guess set of

classes

Classify these as

boundary, control or entity classes


66/72


HomePage Display

LoginPage

PasswordDatabase

Arrows are logical associations and do not represent message passing

e.g.


Iterate between use case and robustness

diagram until all classes discovered and

overall design verified

Stepping stone to class diagram and

sequence diagrams


67/72


Technique: Contract specification

Software analogy to

business contract

Two participants, each willing to

undertake some obligation to geta benefit


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


68/72


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


CONTRACT TABLE

class Class Name subsystem: Subsystem Name

operation_name- - comments

Preconditions

Postcondition- - Boolean Expression or English Text

- - Boolean Expression or English Text


69/72


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


Subcontracting

If A accepts contract from B,

then B does not care how A

fulfils this contract.

Hence A can do job itself orSUBCONTRACT


70/72


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)


Also: Invariant Specification

derived from

ranges specified in URS

STDs

Viewed as a postcondition on all

operations

In UML, a stereotype of Constraint


71/72


HeatedSwimmingPool

temperature:Integer

{ self.temperature > 20 }


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


72/72


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

module 3 uml class diagrams

Documents