S ft Software Architecture A hit t Bertrand Meyer (Nadia - - PowerPoint PPT Presentation

Chair of Softw are Engineering

S ft A hit t Software Architecture

Bertrand Meyer (Nadia Polikarpova) ETH Zurich, February‐May 2009

Lecture 11: UML for Software f f Architectures

Outline

What is UML? What is UML?

UML diagrams Modeling process Modeling process

2

What is modeling?

Building an abstraction of reality

Abstractions from things, people, and processes R l ti

shi s b t th s bst ti s

Relationships between these abstractions

Abstractions are simplifications Abstractions are simplifications

They ignore irrelevant details They represent only the relevant details

y p y

What is relevant or irrelevant depends on the

purpose of the model

3

Architecture vs. Software Engineering

P bl P bl Problem Design Problem Model Implementation Model Reverse Implementation Reverse engineering Program

4

The Unified Modeling Language, UML

d l l l f Modeling language = language for describing models (mostly models of software) f ) Model in UML = graph

vertices = entities edges = relations

Models can be represented in different formats (e g graphical xmi) formats (e.g. graphical, xmi) Diagrams are graphical representation of parts of a model p

5

The Unified Modeling Language, UML

h h h Authors: The Three Amigos Importance Grady Booch James Rumbaugh Ivar Jacobson

Recommended OMG (Object Management Group)

standard notation

De facto standard in industrial software

6

De facto standard in industrial software

development

A bit of history (or why “unified”?)

7

Uses of UML

f h l d b Specification: the language is supposed to be simple enough to be understood by the clients Visualization: models can be represented Visualization: models can be represented graphically plain text < text with pictures < comics Design: the language is supposed to be precise enough to make code generation possible Documentation: the language is supposed to be Documentation: the language is supposed to be widespread enough to make your models understandable by other developers

8

What UML is not about?

l Programming language

this would bound the language to a specific

computing architecture computing architecture

however code generation is encouraged

Software development process p p

however the authors had their own process in

mind: RUP (Rational Unified Process) C E l ifi i CASE tool specification

however tools do exist: Sun, IBM Rose,

Microsoft Visio Borland Together e t c Microsoft Visio, Borland Together e.t.c

9

Entities in UML

Structural Structural

Class – a description of a set of object

with common attributes and operations

+operations()

• attributes

Name

Interface – a set of operations (a service),

provided by a class or component

Actor – an external entity that interacts

Interface

Actor

an external entity that interacts with the system

Use case – a description of a set of

scenarios (sequences of events and

Actor

scenarios (sequences of events and actions) that produce a result, significant for some actor

Actor

Use case

Component – physically replaceable

artifact that provides a certain set of interfaces

Component

Node

10

interfaces

Node – a hardware resource

Node

Entities in UML

Behavioral

State – a period in an object lifecycle,

during which the object is satisfying some property, performing an activity

State

some property, performing an activity

• r waiting for an event

Activity – a state, in which the object

is doing some work (instead of just

Activity

is doing some work (instead of just passively waiting for an event)

Grouping

P k f d l l t

Activity

Package – a group of model elements

(maybe including other packages)

Annotating

Package

g

Note – arbitrary text comment

attached to a model

Note

11

Notation changes in UML 2.0

One notation for all structural entities - rectangle g with a stereotype: Special notation for provided and required p p q interfaces:

12

Relations in UML

Dependency – changing Dependency – changing the independent entity may influence the dependent one

dependent independent

Association – entities are directly connected (e.g. aggregation)

entity1 entity2

aggregation) Generalization – an entity is a special case of another i h i f h

descendant ancestor

entity, they satisfy the substitution principle Implementation – an

descendant ancestor

Implementation an entity is an implementation

• f another entity (e.g. a

l ss nd n int f )

implementation interface

13

class and an interface)

Canonical diagrams in UML 2.0

Functional Functional

Use case diagram (requirements, client’s point of view)

Static structure

Class diagram (classes and relationship between them) Object diagram (relationship between objects at an

interesting point in runtime) g p m )

Composite structure diagram (internal structure of a

class)

Package diagram (packages and relationship between Package diagram (packages and relationship between

them)

Implementation diagrams

• Component diagram (physical components and

Component diagram (physical components and relationship between them)

• Deployment diagram (assigning components to nodes)

14

Canonical diagrams in UML 2.0

Behavioral

State diagram (object lifecycle) Activity diagram (= flowchart algorithm Activity diagram (= flowchart, algorithm

description)

Interaction diagrams

S di ( i d d i

• Sequence diagram (message passing, ordered in

time)

• Communication diagram (message passing)

g g p g

• Interaction overview diagram (= activity diagram

with interaction diagrams in nodes)

• Timing diagram (focus on timing constraints)

Timing diagram (focus on timing constraints)

15

The three views

Functi n l: Wh t d

s th s st m d ?

Functional: What does the system do?

Interaction between the system and external

entities

Diagrams: use case

Structural: What does the system consist of?

Parts (modules) of the system and relationship

between them

Static (no notion of time) Static (no notion of time) Diagrams: class, component, deployment

Behavioral: How does the system work? Behavioral: How does the system work?

Notion of time or sequence of events/actions Diagrams: state, activity, sequence, communication

16

g y q

Use case diagrams

Entities: Entities:

actors use cases

Search entries <<include>>

Relations:

association between an

actor and a use case

List entries <<include>>

actor and a use case

generalization between

actors

Reader

L i

generalization between

use cases

dependencies between

Log in Refuse Log in <<extend>>

dependencies between

use cases Comments: b d i

Submitter

OpenID Log in

17

system boundaries

Reusing use cases

Withdraw <<include>> Withdraw Load <<include>> <<include>> Client Load Cash Card Authenticate <<include>> Client Transfer <<include>>

<<include>> stereotype to include use cases: usin mm n fun ti n lit n dupli t s

18

reusing common functionality, no duplicates

Separating variant behavior

R f xt d>> <<initiates>> Withdraw Client Refuse Withdrawal <<extend>> Not enough money Host <<participates>>

<<extend>> stereotype to provide special case Normal case specifies point at which the behavior may diverge (extension point)

19

diverge (extension point)

Class diagrams

Entities:

IChief ISubordinate

Entities:

classes (and

interfaces)

IChief send_petition ISubordinate report Report <<instantiate>>

Relations:

association between

classes

Position

• ccupy

free Department Report

classes

generalization

between classes l

free request_report send_petition Department <<call>>

implementation

between a class and an interface

IPosition

• ccupy

free

dependencies

between classes

free Manager

20

UML 2.0: “Chupa-chups” notation

Entities:

IChief ISubordinate

Entities:

classes (and

interfaces)

Report <<instantiate>> IChief ISubordinate <<realize>> <<realize>>

Relations:

association between

classes

Position

• ccupy

free Department Report

classes

generalization

between classes l

free request_report send_petition Department

implementation

between a class and an interface

<<realize>>

dependencies

between classes

Manager IPosition

21

Associations

d l d l l d Most widely used relation on class diagrams In general means that classes know about each other - their objects can send each other messages (call their objects can send each other messages (call

• perations, read attributes)

Special cases:

Class A has an attribute of type B Class A creates instances of B

Cl i i h f B

Class A receives a message with argument of type B

Mostly are binary, but can be N-ary Can have different adornments that express additional Can have different adornments that express additional information

22

Association adornments (1)

( bl h d ) Name (possibly with direction)

Person Company works for

Multiplicity of an end – how many objects of the class

Person Company

Multiplicity of an end how many objects of the class take part in the relation

1-to-1

1 1 is capital of

1-to-many

City Country 1 1 is capital of P l P 3 *

many-to-many

Polygon Point 3.. P works for * *

23

Person Company w f

Association adornments (2)

f l b b Aggregation – part-of relation between objects

an object can be part of multiple objects part can be created and destroyed independently of part can be created and destroyed independently of

the aggregate

* Curriculum Course *

Composition – strong aggregation

an object can only be part of a single object

i t l t th ith th t

exists only together with the aggregate

Ti k tM hi Z B tt 3

24

TicketMachine ZoneButton

Association adornments (3)

l f d f Role of an end: name + interface

subordination P i i * 0..1 chief: IChief Position subordinate: ISubordinate

Navigability of an end – whether the objects at this end can be accessed through this association

Password Hashcode 1 1

25

Association adornments (4)

d f d h h h b h d Ordering of an end – whether the objects at this end are ordered Changeability of an end – whether the set of objects at Changeability of an end whether the set of objects at this end can be changed after creation Qualifier of an end – is an attribute that allows retrieving one object from the set at this end

Polygon Point 3..* { d d} {f d d} number 0..1 {ordered} {frozen, ordered}

26

Component diagrams

Entities: Entities:

components

• programs

<<component>>

• documents
• files
• libraries

DataBase

<<realize>>

• DB tables

interfaces classes

ODBC

classes

• bjects

Relations:

<<component>>

dependency association

(composition)

<<component>> Business

27

(composition)

implementation

Deployment diagrams

Entities: Entities: + nodes Relations:

<<component>> <<component>>

+ association between nodes + placement of a

<<component>> DataBase

li

p <<document>> Help

+ placement of a component on a node

ODBC <<realize>>

1 1..* LAN <<component>> Business <<component>> GUI Workstation Server

28

State diagrams

Entities: Entities:

states: name, activity, entry/exit action

Relations:

transitions between states: event, condition, action

State 1

do / activity /

State 2

do / activity / event (arg) [ condition ] / action entry / action exit / action entry / action exit / action

29

State diagrams: example 1

Copy Book Copy 1..* Book borrow return borrow return

On loan On shelf

return( )

Copy On loan

entry / book.borrow( )

On shelf

entry / book.return( )

borrow( ) ( ) return( )

Book Not borrowable Borrowable

return( ) borrow( ) [ last copy ]

30

borrow( ) [ not last copy ]

State diagrams: example 2 (composite state)

TrafficLight

Off On Blinkin TurnOn

TrafficLight

Off Working Blinking SwitchOn SwitchOff Red Yellow TurnOff after 3 sec after 30 sec Red Green Yellow Green after 45 sec after 5 sec

31

Activity diagrams

Entities:

Customer Sales Stockroom

Entities:

activities

Relations:

Request service

transitions

between activities activities Sugar

decisions

Pay Take order Fill order

forks swimlanes

Deliver order Collect order

32

Sequence diagrams

Entities: Entities:

• bjects (including

instances of actors)

:Client :Terminal insertCard( )

Relations: message passing Sugar:

insertCard( )

Sugar: lifelines activations

insertPIN( )

creations destructions f

Time

frames

33

Nested messages

T i l Cli tD t Di l :Client :Terminal insertCard( ) :ClientData check( data ) :Display

• k / nok

displayMessage( text )

Th s f i di t s th ti ti hi h s t The source of an arrow indicates the activation which sent the message An activation is as long as all nested activations

34

g

Creation and destruction

:Terminal ( ) :Session start( ) log( ) g( ) close( )

Creation is denoted by a message arrow pointing to the

• bject

In garbage collection environments, destruction can be used to denote the end of the useful life of an object

35

used to denote the end of the useful life of an object

Interaction frames

:Item :Container :Processor process()

loop [for each item] l

increase()

alt [value < 100]

decrease()

[else]

36

Communication diagrams

Entities: Entities:

• bjects

Relations:

message passing

:Client :Terminal :ClientData

• 1. insertCard( )

1.1 check(data) :Client :Terminal :ClientData 1.2 displayMessage(text) :Display

37

Modeling process

Modeling usage Functional view Structural view Behavioral view Modeling Modeling Structural view Behavioral view Modeling structure Modeling behavior

38

Example: modeling the ATM

M d lin us : us c s di r m Modeling usage: use case diagram

Withdraw <<include>> Refuse Withdrawal <<extend>> Load <<include>> <<include>> Client Load Cash Card Authenticate <<include>> Client Transfer <<include>>

39

Use case example: Withdraw

l Initiating actor: Client Entry condition Entry condition

Client has opened a bank account with the bank and Client has received a bank card and PIN Client has received a bank card and PIN

Exit condition

Client has the requested cash or Client receives an explanation from the ATM about

h th h ld t b di d why the cash could not be dispensed

40

Use case example: Withdraw event flow

Actor steps

1 Authenticate

System Steps

• 1. Authenticate
• 3. Client selects “Withdraw CHF”
• 2. ATM displays options
• 4. ATM queries amount
• 5. Client enters amount

q

• 6. ATM returns bank card

7 ATM outputs specified amount

• 7. ATM outputs specified amount

in CHF D t il f th ti ti Anything missing? Details of authentication

41

Exceptional cases

Withdraw event flow revisited

Referring to included use case

Actor steps

• 1. Authenticate

(use case Authenticate)

System Steps

• 2. ATM displays options
• 3. Client selects “Withdraw CHF”

5 Client enters amount p y p

• 4. ATM queries amount
• 5. Client enters amount
• 6. ATM returns bank card
• 7. ATM outputs specified amount in

CHF CHF (ext. point: Refuse Withdrawal) Listed as extension

42

point

From use cases to sequence diagrams

:Account :Client :Terminal select initWithdraw :Display (withdraw CHF) :Withdrawal initWithdraw (cur) queryAmount( ) queryAmount( ) select (option) withdraw (amount) check(amount cur) (option) (amount) withdraw (amount, cur) displ C nfim ti n( ) check(amount, cur)

• kay

displayConfimation( ) ejectCard( ) taken dispense(amount, cur)

43

... and futher to class diagrams

Add l f h bj t th di Add a class for each object on the diagram For each object that receives an event add a public

• peration in the associated class

p

:Account A t check (amount, cur) withdraw (amount, cur)

• kay

Account check (int, Currency): boolean withdraw (int, Currency)

d f dd l l ( f Identify additional classes (e.g. for message arguments, messages with no receivers) Problem text analysis may help (nouns may correspond to

44

m y m y p ( m y p classes, verbs – to operations)

Practical tips

d d l d l f Create component and deployment diagrams only for large, distributed systems Create state diagrams only for classes with complex Create state diagrams only for classes with complex, interesting behavior (usually classes representing entities from the problem domain or performing control) Create activity diagrams for complex algorithms and business processes (not for every operation) Create sequence and communication diagrams for Create sequence and communication diagrams for nontrivial collaborations and protocols (not for every scenario) Don’t put too much information on a diagram Choose the level of abstraction and maintain it

45