[PDF] - The Unified Modelling Language Perdita Stevens PDF Document

SLIDE 1

The Unified Modelling Language

Perdita Stevens

(Perdita.Stevens@dcs.ed.ac.uk, http://www.dcs.ed.ac.uk/home/pxs/) Division of Informatics University of Edinburgh

Slide 1

Objectives

A t the end

f

to da y:

y
u

will kno w what UML is for and its history in brief;

y
u

will ha v e seen examples

f

all the main features

f

UML (though not some

f

the more esoteric bits)

y
u

will b e able to read and write simple UML mo dels

w

e will all understand more ab

ut

the researc h agenda around UML. Do ask questions and commen t... Slide 2 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 1

SLIDE 2

What is a modelling language?

A language for describing mo dels

f

systems. A mo del describ es an asp e ct

f

the system at a c ertain level

f

abstr action : for example, the class mo del describ es the classes and their (static) relationships, without b eing concerned with requiremen ts. Mo delling languages are usually diagramm atic, b ecause p eople seem to nd this natural. Soft w are engineers are used to the idea that programming languages ha v e formally denable syn tax and seman tics: a program ma y b e legal

r

not and has a (fairly) certain meaning. Mo delling languages are no dieren t ! Slide 3

Why do we model systems?

Tw

main

reasons:

T
help

talk ab

ut,

think ab

ut

and w

rk

with them b efore and as w e build them: in this case the mo del is an abstraction

f

a larger amoun t

f

kno wledge ab

ut

the system;

In
rder

to b e able to use them; in this case w e w an t to b e able to use the abstraction(s) without needing to kno w more. The purp

ses

are related esp ecially in CBD:

ne

design criterion for a go

d

comp

nen

t is that p eople can understand ho w to use it. Must a v

id

dev eloping mo dels that are not useful! Slide 4 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 2

SLIDE 3

What is a good modelling language?

It should b e: 1. Expressiv e enough: that is, w e can express imp

rtan

t asp ects

f

the design, and w e can meaningfully reect c hanges in the design whic h w e mak e during analysis and design as c hanges in the mo dels 2. Easy enough to use, so that it aids clear though t rather than getting in the w a y 3. Widely used? 4. Supp

rted

b y suitable to

ls?

5. Unam biguous Slide 5

Models of a system

W e will w an t to distinguish mo dels

n

sev eral axes. F

r

example:

A

static mo del describ es the elemen ts

f

the system and their relationships

A

dynamic mo del describ es the b eha viour

f

the system

v

er time Again, w e ma y tak e a

lo

gic al view: whic h parts notionally b elong together?

physic

al view: whic h parts will run

n

the same computer? W e probably w

n't

need to ll in all the squares... Slide 6 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 3

SLIDE 4

4+1

Philipp e Kruc h ten

logical

view: ho w do es the system satisfy the functional requiremen ts?

pro

cess view: what are the threads

f

con trol?

dev

elopmen t view: ho w can the system sensibly b e built?

ph

ysical view: ho w will the soft w are b e deplo y ed

n

hardw are? plus the use case view: what should the system ac hiev e? Slide 7

History of UML

1990s: man y dieren t OO dev elopmen t metho ds eac h with their

wn

mo delling language, including

Bo
c

h's OOD

Rum

baugh's OMT

Jacobson's

OOSE and Ob jectory 1994 Rum baugh joined Bo

c

h's compan y Rational 1995 Jacobson joined Rational: announcemen t

f

Unied Metho d, so

n

replaced b y Unied Mo deling Language. UML1.1 adopted b y OMG No v em b er 1997, follo w ed b y UML 1.3 in June 1999. Man y a ws, but

b

viously going to dominate. Slide 8 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 4

SLIDE 5

By the way...

Notice signicance

f

ha ving UML instead

f

Unied Metho d: UML tells y

u

nothing ab

ut

ho w to dev elop a system. UML is not a dev elopmen t metho d. In the same sense, C++ tells y

u

nothing ab

ut

ho w to write programs. Certain strings

f

sym b

ls

are legal C++ programs; a certain C++ program has a (fairly) certain meaning; but the language do es not tell y

u

ho w to write the program. Nev ertheless there is a discipline

f

C++ programming. Some asp ects are con tro v ersial,

thers

more

r

less agreed. Same with UML: w e could discuss some agreed asp ects, and some approac hes to more con tro v ersial asp ects... Slide 9

Present and future of UML

As

f

11/2/00, the UML Revision T ask F

rce

page lists 3316 issues, ranging from trivial misprin ts to fundamen tal a ws. Around 50

utstanding.

Curren t v ersion

f

UML is 1.3 (June 1999). Tw

revision

pro cesses

ngoing:
Minor

revision, 1.4

Ma

jor revision, 2.0 (Bew are: Bo

c

h Jacobson and Rum baugh's UML User Guide sa ys it's up to date with resp ect to 1.3 { this is based

n

a mistak en an ticipation

f

when that w

uld

app ear!) Slide 10 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 5

SLIDE 6

Books and other resources

V ast range. Extremes:

Using

UML: textb

k

aimed at studen ts, ev en inexp erienced

nes
The
cial

sp ecication, whic h mak es no concessions. There are also h uge n um b ers

f

b

ks

aimed at professionals. Tw

deserv

e sp ecial men tion:

Bo
c

h Jacobson Rum baugh UML User Guide, Reference, and Pro cess b

k.
F
wler

UML Distilled W eb sites: v arious, including OMG, Rational, UML R TF. See m y b

k

page (www.dcs.ed.ac.uk/home/p xs/Bo

k/)

for links. Slide 11

What is an object?

Something y

u

can do things to. An

b

ject has state, b eha viour and iden tit y . State can aect b eha viour. Beha viour can aect state. Ob jects comm unicate b y sending messages: the b eha viour

f

an

b

ject

n

receipt

f

a message is \up to the

b

ject". A class denes the structure and b eha viour

f

similar

b

jects. (That is, their implementation, not just the interfac es they pro vide.) Slide 12 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 6

SLIDE 7

A class

Book

A class as design en tit y is an example

f

a mo del elemen t: the rectangle and text form an example

f

a corresp

nding

presen tati

n

elemen t. UML explicitly separates concerns

f

actual sym b

ls

used vs meaning. Slide 13

An object

jo : Customer

This pattern generalises: alw a ys sho w an instance

f

a classier using the same sym b

l

as for the classier, lab elled instanceName : classierName . Slide 14 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 7

SLIDE 8

Classifiers and instances

An asp ect

f

the UML metamo del (more anon) that it's helpful to understand up fron t. An instance is to a classier as an

b

ject is to a class: instance and classier are more general terms. (In the metamo del, Class inherits from Classier, Ob ject inherits from Instance.) W e'll see man y

ther

examples

f

classiers. Slide 15

Showing attributes and operations

Book title : String copiesOnShelf() : Integer borrow(c:Copy)

Notice ho w argumen t t yp es and return t yp es are sho wn (can b e adapted for dieren t programming languages.) They ma y b e

mitted

(together) {

ddly

though, the formal parameter name is compulsory when the argumen t list is giv en. Slide 16 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 8

SLIDE 9

Visibility Book + title : String

copiesOnShelf() : Integer

# borrow(c:Copy)

Can sho w whether an attribute

r
p

eration is

public

(visible from ev erywhere) with +

priv

ate (visible

nly

from inside

b

jects

f

this class) with

(Or

protected, with hash,

r
ther

language dep enden t visibilit y .) Can sho w abstr act

p

eration

r

class using italics for the name. Can add further lab elled compartmen ts for

ther

purp

ses

(e.g. resp

nsibilities.)

Slide 17

Association between classes

Book Copy is a copy of

This generalises: asso ciation b et w een classiers is alw a ys sho wn using a plain line. An instance

f

an asso ciation connects

b

jects (e.g. Cop y 3

f

W ar and P eace with W ar and P eace). An

b

ject diagram con tains

b

jects and links:

ccasionally

useful. (Ho w ev er in the metamo del an asso ciation is not a classier...) Slide 18 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 9

SLIDE 10

Rolenames on associations

Director of Studies Student directee DoS

Can sho w the role that

ne
b

ject pla ys to the

ther.

Useful when do cumen ting the class: e.g. a class invariant for DirectorOfStudies could refer to the asso ciated Studen t

b

jects as self.directee (a set, if there can b e more than

ne).

Slide 19

Multiplicity of association

LibraryMember MemberOfStaff Book Copy Journal 1 1..* 1 0..* 1 0..* borrows/returns borrows/returns borrows/returns 1 0..* is a copy of

Commas for ranges, two dots for ranges, * for unkno wn n um b er. E.g. eac h Cop y is a cop y

f

exactly

ne

Bo

k;

there m ust b e at least

ne

Cop y

f

ev ery Bo

k.

Slide 20 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 10

SLIDE 11

Generalisation

LibraryMember MemberOfStaff

This generalises: generalisation b et w een classiers is alw a ys sho wn using this arro w. Slide 21

Appropriate inheritance

P

w

erful reuse mec hanism but v ery dangerous b ecause

f

tigh t coupling. cf the fr agile b ase class pr

blem

: altering the base class aects all its sub classes. \Implemen tation inheritance" where a class inherits from another not b ecause they are related b y a conceptual generalisation relation but just for co de reuse, is usual ly a bad idea. Ov eruse

f

inheritance is probably the single ma jor problem encoun tered b y new OO dev elop ers. Slide 22 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 11

SLIDE 12

Overusing generalisation

Supp

se

I'm dev eloping a p ersonal

rganiser

application, and I w an t to implemen t an app

in

tmen ts diary using the class Link edList. I should not mak e the relationship b et w een App

in

tmen tsDiary and Link edList b e a generalisation! Wh y not? Because this isn't conceptually a generalisation relationship: it isn't true that an app

in

tmen ts diary is a kind

f

link ed list. It's tempting, and I'v e succum b ed, b ecause it sa v es writing

ne-line

wrapp er metho ds for things lik e add and next { but when I'v e done this kind

f

thing I'v e alw a ys regretted it. One

f

the problems is that y

u

ha v e no

ption

but to exp

se

the whole

f

the link ed list in terface, ev en if (sa y) y

u

didn't w an t to allo w things in the system to access the n um b er

f

app

in

tmen ts. This kind

f

additional dep endency can mak e it hard to alter the implem en tation later. Slide 23

Liskov substitutivity

It is surprisingly dicult to come up with a precise denition

f

when sub classing is safe. Lisk

v

substitutivit y is a p

pular

attempt. Supp

se

some program exp ects to in teract with an

b

ject

f

class C, and that instead it is giv en an

b

ject s

f

class S, a sub class

f

C. If Lisk

v

substitutivit y holds, there is some

b

ject c

f

class C whic h could b e used instead

f

s without altering an ything ab

ut

the b eha viour

f

the program. Exercise: pla y with this idea. Slide 24 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 12

SLIDE 13

Interfaces

In UML an in terface is just a collection

f
p

erations.

prints Stringifiable <<interface>> Stringifiable stringify() : String Module stringify() : String Printer ... <<uses>> ...

Slide 25

Designed relationships between classes

So far w e'v e dealt with what F

wler

calls the c

nc

eptual mo del. W e'v e iden tied the k ey domain abstractions and the conceptual relationships b et w een them. Here w e lo

k

at more adv anced features

f

class mo dels, esp ecially at ho w to record information p ertaining to the design. Slide 26 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 13

SLIDE 14

Dependencies

T

mak

e the system main tainable w e w an t to minimi se the dep endencies b et w een parts

f

the system. Not all \real w

rld"

connections are reected in the system. A is dep enden t

n

B if a c hange to B ma y force a c hange to A. What coun ts as a c hange is con text-dep enden t. Aim to a v

id

complex dep endencies esp ecially circular

nes.

Slide 27

Dependencies in UML

Dep endencies are sho wn using a dotted arro w:

A B

W e'v e seen them b et w een use cases and b et w een a class and an in terface: used generally for \relationship not

therwise

sp ecied". Note that some dep endencies are implied, and need not b e rep eated: for example an y class dep ends

n

its sup erclasses. Slide 28 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 14

SLIDE 15

Navigability

Student Module is taking 1..* 6

When should the na vigabilit y

f

an asso ciation b e decided? Some exp erts b eliev e v ehemen tly that y

u

should nev er iden tify an asso ciation without deciding its na vigabilit y . Others disagree. \As early as p

ssible,

but no earlier." Slide 29

An aggregation relationship

HonoursCourse Module 1..* 6..*

Non-exclusiv e part relationship. A common fault is iden tifying to

man

y aggregations. If in doubt use plain asso ciation. Slide 30 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 15

SLIDE 16

An composition relationship

Board Square 9 1

Exclusiv e part relationship. Slide 31

A qualified association

Board row:{1,2,3} column:{1,2,3} Square 1 1

Giv en a Board and a ro w and a column, can iden tify a Square. Slide 32 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 16

SLIDE 17

A derived association

Student Module is taking Lecturer teaches course /teaches student

Record the asso ciation, but also that it's not indep enden t. Slide 33

An association class

Student Module is taking is taking mark : int 1..* 6

as

pp
sed

to Slide 34 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 17

SLIDE 18

Student Module is taking mark : int Mark 1 1 6 1..* 6 1..*

Slide 35

A parameterised class

T List add(t:T, pos:int) get(i:int) : T List<Game> StudentList <<bind>>(Student)

Slide 36 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 18

SLIDE 19

Interlude...

Slide 37

Use cases

do cumen t the b eha viour

f

the system fr

m

the users' p

ints
f

view. They help with three

f

the most dicult asp ects

f

dev elopmen t:

capturing

requiremen ts

planning

iterations

f

dev elopmen t whic h are go

d

for users

meaningful

system testing They w ere rst in tro duced b y Iv ar Jacobson (early 90s), dev eloping from sc enarios . They are indep enden t

f

OO { strength

r

w eakness?? Simple use case diagrams are easy to understand: can b e useful for comm unicatio n b et w een customers and dev elop ers. Slide 38 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 19

SLIDE 20

A simple use case diagram

Browser Librarian JournalBorrower BookBorrower Reserve book Borrow copy of book Return copy of book Extend loan Borrow journal Update catalogue Browse Return journal

Slide 39

Actors

An actor is sho wn in a use case diagram as a stic k gure. An actor can b e:

a

h uman user

f

the system in a p articular r^

le
an

external system, whic h in some r^

le

in teracts with the system. Or more sp ecically , a particular kind

f

user. F

r

example, the bank has man y customers, but w e

nly

sho w

ne

Customer actor

n

the use case diagram. The same h uman user

r

external system ma y in teract with the system in more than

ne

r^

le:

he/she/it will b e (partly) represen ted b y more than

ne

actor. (e.g., an bank teller ma y happ en also to b e a customer

f

the bank). Slide 40 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 20

SLIDE 21

What is a use case?

A use case is sho wn

n

a use case diagram as a named

v

al. The name describ es some coheren t w

rk

unit

f

the system whic h has v alue for an actor, e.g. Borrow copy

f

book. The use case includes a (textual) description

f

the (a?) sequence

f

messages exc hanged b et w een the system and an y actors, and actions p erformed b y the system, in

rder

to realise the functionalit y . It ma y include logic to handle un usual

r

alternativ e courses, e.g. \if the BookBorrower has the maxim um n um b er

f

b

ks
n

loan already , refuse this loan" even though these may r esult in the actor b eing unsatise d. A use case ma y b e asso ciated with

ther

UML mo dels whic h sho w ho w it is realised. Slide 41

Requirements capture

Use cases can help with requiremen ts capture b y pro viding a structured w a y to go ab

ut

it: 1. iden tify the actors 2. for eac h actor, nd

ut
what

they need from the system

an

y

ther

in teractions they exp ect to ha v e with the system

whic

h use cases ha v e what priorit y for them There ma y b e asp ects

f

system b eha viour that don't sho w easily sho w up as use cases for actors. Slide 42 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 21

SLIDE 22

Politics

If w e capture requiremen ts in terms

f

use cases, w e should understand what is imp

rtant

to whom. Mak e sure system deliv ers added v alue:

so
n
to

all the p eople who migh t scupp er it

in

ev ery iteration Result: the pro ject isn't cancelled. Supp

sedly

... Slide 43

Analysis vs design

Some actors are part

f

the requiremen ts: usually the

nes

who deriv e b enet from a use case. Others are part

f

the (business pro cess) design: the

nes

who in teract with the computer system to pro vide the b enet. F

r

example, consider a FindBook use case

f

a library , in whic h the user en ters details

f

a b

k

and w an ts to end up with a cop y

f

it. Ma yb e the system will giv e the user directions to where the b

k

is

n

the shelf. Ma yb e it will alert a librarian to go and fetc h it. In the latter case, should the librarian b e sho wn as actor? In some sense, the c hoice is a design decision. Slide 44 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 22

SLIDE 23

Using use cases in development

Use cases are a go

d

source

f

system tests: requiremen ts do cumen ted as desired in teractions, whic h translate easily in to tests. Earlier, they can help to v alidate a design. Y

u

can w alk through ho w a design realises a use case, c hec king that the set

f

classes pro vides the needed functionalit y and that the in teractions are as exp ected. Use cases are not limited to do cumen ting the whole system: they ma y also describ e, e.g.

subsystems
classes
COMPONENTS.

Slide 45

What use cases are not

Use cases do cumen t the requiremen ts

f

a system: not the whole business pro cess in to whic h the system ts. F

r

example, UML do es not p ermit asso ciations b et w een actors: y

u

cannot legally use a use case diagram to sho w an in teraction b et w een t w

h

umans follo w ed b y

ne
f

them using a system. (E.g. can't legally sho w librarian and library mem b er as separate actors in Borro w Bo

k,

if

nly

the librarian in teracts directly with the system.) There are prop

sed

extensions to UML to allo w business pro cess mo delling, not considered here. Slide 46 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 23

SLIDE 24

CBD at the very beginning

W e'v e seen simple use cases. But ho w can w e record whic h use cases ha v e b eha viour in common,

r

sho w reuse

f

comp

nen

ts? Note:

UML's

notation for relationships b et w een use cases has recen tly c hanged.

Ev

en no w there are blac k holes: the formal distinction b et w een the t w

mec

hanisms w e're ab

ut

to co v er is far from clear.

Using

this extra notation mak es use case diagrams less immediately understandable. Slide 47

Use cases as collections of scenarios

Recall that a use case ma y include qualitativ ely dieren t scenarios, e.g. including reaction to error conditions. Eac h scenario is view ed as a sequence

f

actions whic h are comm unications b et w een the system and the actors. (Ho w ev er, b ey

nd

that lev el UML's denition gets informal, ev en v ague...) Slide 48 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 24

SLIDE 25

Use case reuse:

include

<<include>>

<<include>> Extend loan Check for reservation BookBorrower Borrow copy

f book

Purp

se:

to demonstrate commonali t y b et w een use cases,

r

the use

f

an existing comp

nen

t. A scenario in the base use case (e.g. Extend loan) gets to a certain p

in

t, then follo ws a scenario in the included use case, then returns to the

riginal

p

in

t and con tin ues with the base use case scenario. Slide 49 extend

BookBorrower

<<extend>> Refuse loan Borrow copy of book

Purp

se:

to sho w sp ecial case b eha viour. Note direction

f

dep endency arro w: the extending use case ma y dep end

n

the main use case but not the

ther

w a y round. Slide 50 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 25

SLIDE 26 extend

BookBorrower

<<extend>> Refuse loan Borrow copy of book extension points too many books

Optionally , w e can do cumen t the decision p

in

t. Slide 51

Generalisation of actors

BookBorrower JournalBorrower

Slide 52 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 26

SLIDE 27

Use case driven development?

use case-driv en In the con text

f

the soft w are dev elopmen t life cycle, a pro cess in whic h use cases are used as a primary artefact for establishing the desired b eha viour

f

the system, for v erifying and v alidating the system's arc hitecture, for testing, and for comm unicating among the stak eholders

f

the pro ject. from Bo

c

h Jacobson Rum baugh UML User Guide T raceabilit y is men tioned in passing under R UP , but is a ma jor b enet

f

this approac h. Ho w ev er, the use case mo del m ust b e used in conjunction with the class mo del: cannot iden tify reuse from use case diagram alone! Slide 53

Shortcomings

1. Danger

f

losing OO: plan fo cus

n

use cases ma y encourage a top-do wn functional view

f

the system 2. Danger

f

mistaking design for requiremen ts 3. Danger

f

missing requiremen ts Use use cases to guide a disciplined OO dev elopmen t { don't let them b e the dev elopmen t. Slide 54 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 27

SLIDE 28

Extensibility of UML: stereotypes

W e'v e no w seen

ne

mec hanism b y whic h UML is extensible: stereot yp es. include and extend are predened parts

f

UML, but y

u

can dene y

ur
wn

to

.

A stereot yp e mak es the mo del elemen t to whic h it is attac hed more sp ecic in a user dened w a y . F

r

example, if y

u

decide y

u'd

lik e to distinguish b et w een actors who are b eneciaries and

thers,

y

u

could in v en t a stereot yp e b eneciary

f

actor. Can dene new graphical icons for the stereot yp ed mo del elemen t. Slide 55

Comments and constraints

Used to add to a UML mo del information not (easily) expressible in UML.

Copy is a copy of Book Journal is a copy of {or} 0..1 0..1 1..* 1..* each volume separately

W rite the constrain t

r

commen t in whatev er language (natural

r

formal) is appropriate. Slide 56 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 28

SLIDE 29

Constraints in a UML model

Constrain ts allo w y

u

to giv e more information ab

ut

what will b e considered a correct implemen tation

f

a system describ ed in UML. Sp ecically , they constrain

ne
r

more mo del elemen ts, b y giving conditions whic h they m ust satisfy . They are written in an appropriate language, enclosed in set brac k ets and attac hed to the mo del in some visually clear w a y . W e'll consider OCL later. Slide 57

CRC cards

Class, Resp

nsibilities,

Collab

rations

Originally in tro duced b y Ken t Bec k and W ard Cunningham as an aid to getting non-OO programmers to \think

b

jects". Also useful for v alidating the class mo del against the use case mo del. W e'll see ho w to record m uc h

f

the information pro duced using CR C cards in UML inter action diagr ams . CR C cards are an aid to clear though t, not a formal part

f

the design pro cess { though UML do es p ermit y

u

to record the information from them in the class mo del, if y

u

wish. Slide 58 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 29

SLIDE 30

Examples

LibraryMember Resp

nsibil

it i es Collab

rators

Main tain data ab

ut

copies curren tly b

rro

w ed Meet requests to b

rro

w and return copies Copy Copy Resp

nsibil

it i es Collab

rators

Main tain data ab

ut

a particular cop y

f

a b

k

Inform corresp

nding

Book when b

rro

w ed and returned Book Book Resp

nsibil

it i es Collab

rators

Main tain data ab

ut
ne

b

k

Kno w whether there are b

rro

w able copies Slide 59

Interaction diagrams

describ e the dynamic in teractions b et w een

b

jects in the system, i.e. the pattern

f

message-passing. They let y

u

record ho w y

u

w a v e CR C cards around! Tw

main

uses:

Sho

wing ho w the system realises [part

f

] a use case

Sho

wing ho w an

b

ject reacts to some message P articularly useful where the

w
f

con trol is complicated, since this can't b e deduced from the class mo del, whic h is static. UML has t w

sorts,

se quenc e and c

l

lab

r

ation diagrams { the dierences are syn tactic. Slide 60 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 30

SLIDE 31

Developing an interaction diagram

1. Decide exactly what b eha viour to mo del. 2. Chec k that y

u

kno w ho w the system pro vides the b eha viour: are all the necessary classes and relationships in the class mo del? 3. Name the

b

jects whic h are in v

lv

ed. 4. Iden tify the sequence

f

messages whic h the

b

jects send to

ne

another. 5. Record this in the syn tax

f

a sequence

r

collab

ration

diagram. Slide 61

A collaboration

LibraryMember Copy theBook : Book theCopy : theLibraryMember : aMember : BookBorrower

Slide 62 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 31

SLIDE 32

An interaction on a collaboration

LibraryMember Copy theBook : Book theCopy : theLibraryMember : aMember : BookBorrower borrow(theCopy) 1: okToBorrow 2 :borrow 2.1: borrowed

Slide 63

Sequence diagram of same interaction

LibraryMember theLibraryMember : Copy theCopy : theBook : Book borrow(theCopy) 1: okToBorrow 2: borrow 2.1: borrowed aMember : BookBorrower

Slide 64 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 32

SLIDE 33

Showing more detail

borrow(theCopy)

2: borrow 2.1: borrowed :LibraryMember :Copy : Book 1: okToBorrow aMember : BookBorrower

Slide 65

Creation/deletion of objects in sequence diagram

:Lecturer :DirectorOfStudies :UTO 1: n := getName() 2: new DirectorOfStudies (n) 3:destroy()

Slide 66 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 33

SLIDE 34

Creation/deletion of objects in collaboration diagram :Lecturer :UTO 1: n := getName() {destroyed} :DirectorOfStudies {new} 3:destroy() 2: new DirectorOfStudies (n)

Slide 67

Designing interactions

EverythingController getJC(j:Job) : JobController 1 JobController 1 Job 1 0..* 0..* 0..*

Problems? Slide 68 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 34

SLIDE 35

Law of Demeter

in resp

nse

to a message m, an

b

ject O should send messages

nly

to the follo wing

b

jects: 1. O itself 2.

b

jects whic h are sen t as argumen ts to the message m 3.

b

jects whic h O creates as part

f

its reaction to m 4.

b

jects whic h are dir e ctly accessible from O , that is, using v alues

f

attributes

f

O . Slide 69

Collaboration diagram or sequence diagram?

An in teraction can b e sho wn

n

a collab

ration

diagram

r
n

a sequence diagram. They sho w almost the same information.

Collab
ration

diagrams are b etter at sho wing the links b et w een the

b

jects.

Sequence

diagrams are b etter for seeing the

rdered

sequence

f

messages that passes. W e ha v en't (y et) talk ed ab

ut

generic in teraction diagrams whic h allo w y

u

to sho w man y p

ssibilities
n
ne

diagram: sequence diagrams supp

rt

these m uc h b etter than collab

ration

diagrams. Slide 70 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 35

SLIDE 36

Showing timing constraints

LibraryMember theLibraryMember : Copy theCopy : theBook : Book borrow(theCopy) 1: okToBorrow 2: borrow 2.1: borrowed {C - A < 5 sec} aMember : BookBorrower C A {borrowed’ - borrowed < 1 sec}

Slide 71

Conditional message send

[i = 0] foo() [i = 1] bar() m : Mung [i = 0] foo() [i = 1] bar() m : Mung

Slide 72 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 36

SLIDE 37

Parallel universes

m : Mung f : Froboz 7.1:[i = 0] foo() 7.2:[i = 1] bar()

Slide 73

Iteration

3.1:*[i := 1..2] a() :Foo :Bar :Baz 3.1.1:b() 3.1:*[i := 1..2] a() 3.1.1:*[i := 1..2] b() :Foo :Bar :Baz

Slide 74 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 37

SLIDE 38

Asynchronous messages

Ada Lovelace : CS4Student

Dr. J. Bloggs : CS4DirectorOfStudies

:DirectorOfStudies email confirmChoice(m1,...,m6,self) chooseModules(m1,...m6) :Student

Slide 75

Interlude...

Slide 76 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 38

SLIDE 39

Effects of interactions on objects

So far w e'v e seen ho w to mo del:

the

requiremen ts

f

the system with use cases

the

structure

f

the system with a class mo del

the

in teractions b et w een

b

jects with in teraction diagrams In teractions describ e ho w an

b

ject reacts to an ev en t that forms part

f

that particular in teraction. (\What happ ens next?") But what determines this? In particular, the same

b

ject ma y react to the same ev en t in dieren t w a ys, dep ending

n

its in ternal state. W e mo del this using state diagrams. Slide 77

State diagrams

Useful for sho wing the w a y that an

b

ject

f

a giv en class c hanges state, if it has qualitativ ely dieren t in ternal states. Ma y include:

states
ev

en ts that cause transitions b et w een states

guards

that m ust b e true for a transition to tak e place

actions

that are caused b y a giv en transition

activities

that tak e place when in a certain state

start

and end mark ers States ma y b e nested, but most classes will not need statec harts dra wn for them. Slide 78 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 39

SLIDE 40

A simple state diagram

return() borrow()

n loan
n the shelf

Slide 79

State diagrams as abstractions

If w e could dra w innite a diagrams, w e could represen t eac h set

f

v alues for an

b

ject's attributes and links as a separate state and sho w exactly what happ ens when the

b

ject receiv es eac h message. W e could include as m uc h detail as the co de. In practice, a state represen ts an equiv alence class

f

attribute (and link) v alues:

b

jects whic h b eha v e qualitativ ely the same w a y are in the same state. That is, a real state diagram represen ts an abstraction

f

the \ideal" (and useless!) state diagram. a OK, computers are nite... Slide 80 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 40

SLIDE 41

So which abstraction?

F

rmally

, could classify

b

jects in dieren t w a ys, getting dieren t state diagrams for the same class. That is, w e could c ho

se

dieren t abstractions. As alw a ys the righ t

ne

is the

ne

that answ ers the questions

f

someone using the diagram. This migh t b e:

the

p erson who m ust co de the class

a

clien t, writing co de that will in teract with the class Dierences in what they need to kno w? Slide 81

State diagram showing actions

n loan
n the shelf

return()/^book.returned(self) borrow()/^book.borrowed(self)

Slide 82 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 41

SLIDE 42

Transitions in more detail

When an

b

ject passes from

ne

state to another it do es so as a result

f

an ev en t, e.g. receiving a message. In addition to c hanging state, the

b

ject ma y react in some w a y e.g. b y sending a message. Suc h (re)actions are sho wn after the slash: ev en t/action. Sometimes an ev en t causes a state c hange

nly

if a guard is satised. The guard is sho wn: ev en t[guard] / action. An ev en t is something done to the

b

ject: an action is something the

b

ject do es. Slide 83

State diagram for Book, with guards

not borrowable borrowable returned() borrowed()[ last copy] returned() borrowed()[not last copy]

Slide 84 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 42

SLIDE 43

State diagram showing entry actions

return() borrow()

n loan
n the shelf

entry/book.borrowed(self) entry/book.returned(self)

Slide 85

Activity diagrams

Useful as an alternativ e to in teraction (sequence

r

collab

ration)

diagrams for:

detailing

a use case

explaining

an an

b

ject's reaction to a message Also useful for sho wing the dep endencies b et w een use cases: e.g. workow

f

an

rganisation.

Main adv an tage: can sho w parallel activities, so mak e dep endencies and non-dep endencies explicit. Main disadv an tage: corresp

ndence

with

b

jects in the system ma y not automatically b e clear. (Swimlanes, whic h for reasons

f

time w e lea v e

ut,

can help.) Slide 86 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 43

SLIDE 44

Activity diagram

prepare for next member find book on shelf wait in queue borrowing record record return put book back

n shelf

[borrower] [returner] [returning] [borrowing] member librarian

Slide 87

The development view

Recall the 4+1 view mo del:

logical

view: ho w do es the system satisfy the functional requiremen ts?

pro

cess view: what are the threads

f

con trol?

dev

elopmen t view: ho w can the system sensibly b e built?

ph

ysical view: ho w will the soft w are b e deplo y ed

n

hardw are? plus the use case view: what should the system ac hiev e? So far w e'v e really

nly

considered 2+1. Slide 88 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 44

SLIDE 45

Component diagrams

sho w dep endencies b et w een soft w are comp

nen

ts. A comp

nen

t ma y b e

source

co de (some sensible implemen tatio n unit

f

it, e.g. the co de for a giv en class,

r

p erhaps a start-up shell script)

binary

co de (e.g. a class library)

an

executable (e.g. a b

ugh

t-in spreadsheet). W e'll

nly

consider compilation dep endencies (so nothing will dep end

n

an executable, unless it's a compiler!). Slide 89

A component diagram

streams.o library>> << MyApp <<executable>> MyIO <<link>> <<compile>>

Slide 90 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 45

SLIDE 46

Implementing components

T

build

a comp

nen

t y

u

need to sp ecify and design it, and y

u

w an t to ha v e a clear b

undary

b et w een this comp

nen

t and an y

ther.

UML pac k ages giv e separate namespaces for this purp

se.

A UML subsystem is a kind

f

pac k age whic h can ha v e instances: it's particularly useful for mo delling comp

nen

ts. Slide 91

Packages

P Q A foo:?? B C R D E S

P ac k ages can app ear

n

(almost) an y diagram if con v enien t, and can enclose an y \sensible" collection

f

mo del elemen ts. Slide 92 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 46

SLIDE 47

Physical view

It's to

easy

to forget that soft w are runs

n

hardw are! Somewhere early in the pro cess y

u

m ust ha v e considered, for example, the pro cessors needed and the net w

rk:

ac hieving decen t p erformance is

therwise

imp

ssible.

This is

utside

the scop e

f

the course, ho w ev er: here w e just glance at the UML facilities for recording suc h things. Slide 93

Deployment diagram

The deplo ymen t diagram sho ws the relationships b et w een ph ysical mac hines and pro cesses, e.g. what runs where. Bo xes represen t run-time pro cessing elemen ts, usually computers. Lines b et w een b

xes

(asso ciations) represen t ph ysical comm unication links. Comp

nen

ts that ha v e a run-time existence (i.e. that don't get compiled a w a y) can b e sho wn in the no des. Slide 94 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 47

SLIDE 48

Deployment diagram: hardware only

<<LAN>> ether C

craro : PC shillay : Workstation

Slide 95

Deployment diagram showing software

P2:PllayerInterface

OXO:GameEngine

P1:PlayerInterface

shillay : Workstation craro : PC <<LAN>> ether C

Slide 96 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 48

SLIDE 49

A Rose-style deployment diagram

server

Scheduler MeetingsDB PersonalPlanner

dumb terminal workstation

PersonalPlanner

Slide 97

Summary of elements of UML

Use

case diagram

Class

diagram

Beha

viour diagrams: { In teraction diagrams:

sequence

diagram

collab
ration

diagram { state diagram { activit y diagram

Implemen

tation diagrams: { comp

nen

t diagram { deplo ymen t diagram Slide 98 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 49

SLIDE 50

Summary

The industry standard mo delling language UML pro vides a language in whic h to talk ab

ut

designs. It do esn't sa y an ything ab

ut

ho w to get the designs. (Compare English: it do esn't tell y

u

what to sa y , but y

u

do kno w whether a sen tence is English

r

not, with some tolerance.) If w e'd had a w eek rather than a da y w e'd also ha v e talk ed more ab

ut

v arious asp ects

f

the dev elopmen t pro cess, whic h is concerned with ho w w e get designs and programs:

arc

hitecture-cen tric comp

nen

t based dev elopmen t

example

Metho dology: Ob jectory , Catalysis

use

case analysis

CR

C cards

design

patterns Slide 99

ac

hieving reuse Slide 100 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 50

SLIDE 51

Interlude...

Slide 101

Research and UML

What is the researc h agenda concerning UML? Ob viously it dep ends whom y

u

ask. But as I'm in c harge here:

UML

pro vides an imp

rtan

t

pp
rtunit

y for TCS to sho w its w

rth.

A t last w e ha v e a language whic h is { formal enough to pro vide ground to stand

n;

{ v ery widely used: mak es eort sp en t

n

language-sp ecic issues w

rth

while

But

there are signican t dangers

f

blo wing it. E.g. b y: { trying to sell formalism for formalism ' s sak e; { failing to appreciate that certain decisions ha v e already b een made whether w e lik e them

r

not; { not doing things whic h are exciting enough; { doing things that w

n't

ev er help actual soft w are engineering practice. Slide 102 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 51

SLIDE 52 F amiliarit y with the standard is prerequisite so let's start there. Slide 103

How UML is defined

Tw

main

do cumen ts:

Notation

Guide : informal explanation

f

notation (concrete syn tax) and its connection to abstract syn tax.

Seman

tics : semi-formal sp ecication

f

abstract syn tax, plus further explanation

f

seman tics. Seman tics tak es precedence

v

er Notation Guide in cases

f

conict { theoretically . Plus: denition

f

the Ob ject Constrain t Language (OCL). Slide 104 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 52

SLIDE 53

Reading the UML semantics document 1

The abstract syn tax describ es (in UML!) the relationships b et w een kinds

f

UML mo del elemen ts (the metamo del ). F

r

example, use cases, actors and classes are all said to b e examples

f

classiers:

Classifier Class Actor UseCase

Slide 105

Reading the UML semantics document 2

W ell-formedness rules put further restrictions

n

what it means to b e a correct UML mo del. F

r

example, a constrain t

n

a Generalization states: self.subtype.oclType = self.supertype.o clTyp e This expresses concisely that ev en though a Generalization can exist b et w een classes

r

b et w een actors, a class cannot b e a generalization

f

an actor, etc.. (self refers to the Generalization; the abstract syn tax denes that an y Generalization is asso ciated with t w

GeneralizableElemen

ts referred to as subt yp e and sup ert yp e; the

clT

yp e

f

an y class is Class, etc.) The section Seman tics con tains a v ariet y

f

further explanation, in English. Slide 106 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 53

SLIDE 54

Object Constraint Language

The w ell-formedness rules are giv en in a language called OCL. Unfortunately

n

a formal lev el, OCL w as dev elop ed (from a previously existing sp ecication language) sim ultaneously with UML, and it to

has

unresolv ed problems! OCL do es not (y et) ha v e a formal seman tics. Th us though y

u

will hear it describ ed as a formal sp ecication language, this is at b est dubious. Issues:

do

es a giv en design mo del a giv en OCL statemen t?

what

are the pro

f

rules for OCL?

what

is the t yp e system for OCL? and do they ha v e the appropriate prop erties? ... Slide 107

Semantics for UML(?)

V ery con tro v ersial:

do

es UML need a formal seman tics at all?

if

so,

f

what kind?

WHA

T F OR? There is a lot

f

w

rk

in the area. NB need to read the seman tics do cumen t! But let's not get carried a w a y: seman tics for UML is

nly
ne

p

ssible

researc h area... Slide 108 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 54

SLIDE 55

Supporting Software Design

Presen t-da y CASE to

ls

are v ery limited. Ma jor issues

f

the momen t include usabilit y , b eing up to date with the standard, p erformance, price. More in teresting to us p erhaps: p

w

er. Ho w can the practice

f

mainstream soft w are design can b e w ell supp

rted

b y formal tec hniques? Tw

p
ssible

approac hes: 1. \Money no

b

ject": ho w can formalit y help raise the ceiling, increase the maxim um dep endabilit y

f

systems? \F

rmal

metho ds" 2. Ho w can formalit y help without raising cost

r

requiring soft w are engineers to b e more mathematical ly

rien

ted than they are no w? I'm p ersonally most in terested in 2. Slide 109

Some open questions

1. Ho w can what-if exp erimen ts b e made easier? T

what

exten t could a to

l

suggest scenarios whic h should b e explored, pro vide supp

rt

in exploring the dynamic implications

f

earlier decisions, etc.? 2. Ho w can design b y con tract b e supp

rted?
Languages

for appropriate con tracts, whic h a to

l

can treat as formal statemen ts, without requiring the designer to learn a formal language?

Unnished

design? T

l

m ust supp

rt

the iden tication

f

(in)dep enden t elemen ts, and m ust not simply giv e up in the case

f

a p

ssibly

violated con tract. 3. Ho w can w e ease the use and dev elopmen t

f

comp

nen

ts and

ther

c h unks

f

designs, suc h as pro duct-line arc hitectures (PLAs) and framew

rks?
complex

in terfaces (not just single

p

erations)

restrictions
n

ho w c hoices are resolv ed (e.g. who c ho

ses?)

Slide 110 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 55

SLIDE 56

exploring,

and p erhaps c hanging

r

making explicit, the assumptions made ab

ut

the en vironmen t. Slide 111

Current state and progress

Some things it's clear to

ls

could do no w, without further theoretical progress:

more

am bitious sanit y c hec king

f

mo dels

pro

vided can a v

id

am biguities in seman tics e.g. what asso ciations mean...

animation
in

practice, ho w useful is this?

an

y amoun t

f

mo del c hec king, pro vided the user agrees with y

ur

in terpretation

f

the seman tics

more

co de generation

but

it's easier to write co de than UML mo dels so ma yb e demand for this is limited Challenge: do something useful enough. I'm exploring ho w games ma y help in exploration

f

consequences

f

design decisions... w atc h this space. F

r

no w, let's fo cus close to home

n

design b y con tract using OCL. Slide 112 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 56

SLIDE 57

Design by Contract

The k ey is to a v

id

am biguous situations in whic h something go es wrong but there are sev eral views ab

ut

whose faults it is. By making explicit the con tract b et w een supplier

f

a service and the clien t, D b y C

con

tributes to a v

iding

misunderstandings and hard-to-trac k bugs;

supp
rts

clear do cumen tation

f

a mo dule { clien ts should not feel the need to read the co de!

supp
rts

defensiv e programmi ng;

allo

ws a v

idance
f

double testing. Slide 113

Example: class invariants

A class in v arian t restricts the legal

b

jects b y sp ecifying a relationship b et w een the attributes and/or the attributes

f

asso ciated classes. Simple example: the class in v arian t fname is no longer than 32 c haractersg could b e applied to a class Studen t whic h has an attribute name : String to forbid certain v alues

f

that attribute. Implemen tors

f

the class m ust ensure that the in v arian t is satised (when?) Clien ts

f

the class ma y assume it. Slide 114 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 57

SLIDE 58

Less simple example

Supp

se
ur

class Studen t is asso ciated with classes DirectorOfStudies and also with Lecturer b y tutor { a studen t has a DoS and a tutor. Supp

se

it is forbidden for the studen t's DoS and tutor to b e the same p erson. W e can represen t this b y a class in v arian t

n

Studen t, sa y f studen t's tutor and DoS are dieren t g (Is this sucien tly unam biguous?) Slide 115

Constraining implementations of operations

W e can constrain the b eha viour

f
p

erations using pre and p

st

conditions. A pre condition m ust b e true b efore the

p

eration is in v

k

ed { it is the clien t's resp

nsibilit

y to ensure this. A p

st

condition m ust b e true after the

p

eration has b een carried

ut

{ it is the class's implem en tor's resp

nsibilit

y to ensure this. E.g. Mo dule::register(s : Studen t) pre : s is not registered for the mo dule p

st

: the set

f

studen ts registered for the mo dule is whatev er it w as b efore plus studen t s. Slide 116 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 58

SLIDE 59

Subcontracting

When a sub class reimplemen ts an

p

eration it m ust fulll the con tract en tered in to b y its base class { for substitutivit y . A clien t m ust not get a nast y surprise b ecause in fact a sub class did the job. Rule

f

sub con tracting: Demand no more: promise no less It's OK for a sub class to w eak en the precondition, i.e. to w

rk

correctly in more situations... but not OK for it to strengthen it. It's OK for a sub class to strengthen the p

stcondition,

i.e. to promise more stringen t conditions... but not OK for it to w eak en it. Slide 117

Languages for contracts

W riting con tracts in English can b e

am

biguous

long-winded
hard

to supp

rt

with to

ls

Sometimes it's desirable to use a mathematicall y-based language { but suc h languages can b e hard to learn. OCL aims to b e b

th

formal and simple. Slide 118 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 59

SLIDE 60

OCL basic types

Bo
lean
String
In

teger

Real

With all the

p

erations y

u'd

exp ect. In teger is considered a subt yp e

f

Real. (Remark: OCL uses the terms class and t yp e in terc hangeably , whic h is just ab

ut

OK in this con text, though normally a big mistak e.) Slide 119

Example: pre and post conditions

Stove::open()

pre

: status = #off post : status = #off and isOpen ElectricStove::open( )

pre

: temperature <= 100 post : isOpen Do y

u

ha v e to re-sp ecify the inherited precondition? Y es { not to do so is just to

confusing.

So instead include the status = #off ev erywhere. Slide 120 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 60

SLIDE 61

OCL collection types

Collection
Set
Bag
Sequence

with the usual

p

erations (size, includes, isEmpt y , ...) Things that w

uld

b e collections

f

collections are \automatically attened" { OCL cannot talk ab

ut

a sequence

f

sets, etc.!! Slide 121

Navigation

An OCL expression in the con text

f
ne

class A ma y refer to an asso ciated class B.

Director of Studies Student directee DoS

Single (?

1)

asso ciation: straigh tforw ard, since an y

b

ject

f

class A determines just

ne
b

ject

f

class B:

If

there's a rolename use it, e.g. self.DoS.name

If

not ma y just use classname, e.g. self.directorOfS tudie s.nam e Slide 122 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 61

SLIDE 62

More navigation

What if the asso ciation is not (?

1)?

E.g. consider the same asso ciation from the p

in

t

f

view

f

the DirectorOfStudies { a DoS ma y direct man y Studen ts. F

r

eac h DirectorOfStudies the rolename directee refers to a set

f

Studen ts. Use OCL collection

p

erations, e.g.

self.directee->for

All (regNo <= 200000)

self.directee->not

Empty (If y

u

use a collection

p

eration

n

something that isn't a collection it gets in terpreted as a set con taining

ne

elemen t!) Slide 123

The plot thickens

What happ ens if w e tak e more than

ne

\hop" round the class diagram? e.g. what is self.studen t.mo dule? It should b e a set

f

sets, but OCL do esn't ha v e them! So it's a bag. T empting to regard this as a bug, but it's v ery con v enien t in practice; what is the righ t compromise? Slide 124 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 62

SLIDE 63

Using operations in OCL

Consider an

p

eration register(s:Student )

f

Module. Should w e b e able to refer to this

p

eration in an OCL expression? Problem: it do es something { alters the state

f

the Mo dule. When should this happ en, if at all? Only go

d

w a y round this is to allo w in OCL

nly
p

erations that guaran tee not to alter the state

f

an y

b

ject. Suc h

p

erations are kno wn as queries { in UML an

p

eration (in fact an y Beha vioralF eature) has an attribute isQuery whic h m ust b e true for the

p

eration to b e legal in OCL. (UML do esn't curren tly sp ecify that suc h

p

erations should guaran tee to terminate, but presumably it should. Is there a problem with inheritance?) Slide 125

Beyond OCL

Curren t activit y in the UML R TF is fo cusing

n

dealing with OCL issues

ne

at a time. P ersonally I think something more radical is required, ma yb e in UML2.0... As w ell as a b etter OCL, what more migh t b e useful for design b y con tract? Languages for expressing more than

ne

can in OCL... with temp

ral

features? with indep endence? Challenge: k eep these usable b y dev elop ers and supp

rtable

b y to

ls.

Slide 126 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 63

SLIDE 64

Conclusion

No w:

y
u

kno w what UML is for and its history in brief;

y
u

ha v e seen examples

f

all the main features

f

UML (though not some

f

the more esoteric bits)

y
u

can read and write simple UML mo dels

w

e all understand more ab

ut

the researc h agenda around UML! Thank y

u

for participating. Slide 127 c

P

erdita Stev ens 2000 ET APS2000 UML T utorial 64