Chair of Software Engineering Software Architecture Bertrand Meyer

Chair of Software Engineering Software Architecture Bertrand Meyer (Nadia Polikarpova) ETH Zurich, February-May 2009 Lecture 11: UML for Software Architectures

Outline Ø What is UML? Ø UML diagrams Ø Modeling process 2

What is modeling? Building an abstraction of reality Ø Abstractions from things, people, and processes Ø Relationships between these abstractions Abstractions are simplifications Ø They ignore irrelevant details Ø They represent only the relevant details Ø What is relevant or irrelevant depends on the purpose of the model 3

Architecture vs. Software Engineering Problem Design Problem Model Reverse engineering Implementation Program 4

The Unified Modeling Language, UML Ø Modeling language = language for describing models (mostly models of software) Ø Model in UML = graph Ø vertices = entities Ø edges = relations ØModels can be represented in different formats (e. g. graphical, xmi) ØDiagrams are graphical representation of parts of a model 5

The Unified Modeling Language, UML Authors: The Three Amigos Grady Booch James Rumbaugh Ivar Jacobson Importance Ø Recommended OMG (Object Management Group) standard notation Ø De facto standard in industrial software development 6

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

Uses of UML Ø Specification: the language is supposed to be simple enough to be understood by the clients Ø 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 widespread enough to make your models understandable by other developers 8

What UML is not about? Ø Programming language Ø this would bound the language to a specific computing architecture Ø however code generation is encouraged ØSoftware development process Ø however the authors had their own process in mind: RUP (Rational Unified Process) ØCASE tool specification Ø however tools do exist: Sun, IBM Rose, Microsoft Visio, Borland Together e. t. c 9

Entities in UML Ø Structural Ø Class – a description of a set of object with common attributes and operations Ø Interface – a set of operations (a service), provided by a class or component Ø Actor – an external entity that interacts with the system Ø Use case – a description of a set of scenarios (sequences of events and actions) that produce a result, significant for some actor Ø Component – physically replaceable artifact that provides a certain set of interfaces Ø Node – a hardware resource 10

Entities in UML Ø Behavioral State – a period in an object lifecycle, during which the object is satisfying some property, performing an activity or waiting for an event Ø Activity – a state, in which the object is doing some work (instead of just passively waiting for an event) Ø Ø Grouping Ø Package – a group of model elements (maybe including other packages) ØAnnotating Ø Note – arbitrary text comment attached to a model 11

Notation changes in UML 2. 0 Ø One notation for all structural entities - rectangle with a stereotype: Ø Special notation for provided and required interfaces: 12

Relations in UML Ø Dependency – changing the independent entity may dependent influence the dependent one ØAssociation – entities are entity 1 directly connected (e. g. aggregation) Ø Generalization – an entity is a special case of another descendant entity, they satisfy the substitution principle Ø Implementation – an entity is an implementation of another entity (e. g. a class and an interface) independent entity 2 ancestor interface 13

Canonical diagrams in UML 2. 0 Ø 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) Ø Composite structure diagram (internal structure of a class) Ø Package diagram (packages and relationship between them) Ø Implementation diagrams • 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 description) Ø Interaction diagrams • Sequence diagram (message passing, ordered in time) • Communication diagram (message passing) • Interaction overview diagram (= activity diagram with interaction diagrams in nodes) • Timing diagram (focus on timing constraints) Ø Ø 15

The three views Ø 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) Ø Diagrams: class, component, deployment Ø Behavioral: How does the system work? Ø Notion of time or sequence of events/actions Ø Diagrams: state, activity, sequence, communication Ø 16

Use case diagrams Ø Entities: Ø actors Ø use cases Ø Relations: Ø association between an actor and a use case Reader Ø generalization between actors Ø generalization between use cases Ø dependencies between use cases Submitter Ø Comments: Ø system boundaries Search entries <<include>> List entries Log in <<extend>> Refuse Log in Open. ID Log in 17

Reusing use cases Withdraw Load Cash Card <<include>> Authenticate Client Transfer <<include>> stereotype to include use cases: reusing common functionality, no duplicates 18

Separating variant behavior <<initiates>> Withdraw Client <<extend>> Refuse Not enough Withdrawal money <<participates>> Host <<extend>> stereotype to provide special case Normal case specifies point at which the behavior may diverge (extension point) 19

Class diagrams IChief ISubordinate Ø Entities: send_petition report Ø classes (and <<instantiate>> interfaces) Report Ø Relations: Position Ø association between occupy Department free classes request_report Ø generalization send_petition <<call>> between classes Ø implementation IPosition between a class and occupy an interface free Ø dependencies between classes Manager 20

UML 2. 0: “Chupa-chups” notation IChief ISubordinate Ø Entities: Ø classes (and <<instantiate>> <<realize>> interfaces) <<realize>> Report Ø Relations: Position Ø association between occupy Department free classes request_report Ø generalization send_petition between classes Ø implementation <<realize>> between a class and an interface IPosition Ø dependencies between classes Manager 21

Associations Ø Most widely used relation on class diagrams Ø In general means that classes know about each other their objects can send each other messages (call operations, read attributes) Ø Special cases: Ø Class A has an attribute of type B Ø Class A creates instances of 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 information 22

Association adornments (1) Ø Name (possibly with direction) works for Person Company Ø Multiplicity of an end – how many objects of the class take part in the relation Ø 1 -to-1 City Ø 1 is capital of 1 -to-many 3. . * Polygon Ø many-to-many Person 1 * works for * Country Point Company 23

Association adornments (2) Ø Aggregation – part-of relation between objects Ø an object can be part of multiple objects Ø 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 Ø exists only together with the aggregate Ticket. Machine 3 Zone. Button 24

Association adornments (3) Ø Role of an end: name + interface subordination chief: IChief 0. . 1 Position * subordinate: ISubordinate ØNavigability of an end – whether the objects at this end can be accessed through this association Password 1 1 Hashcode 25

Association adornments (4) Ø Ordering of an end – whether the objects at this end are ordered Ø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 3. . * number {frozen, {ordered} 0. . 1 Point 26

Component diagrams Ø Entities: Ø components • programs • documents • files • libraries • DB tables Ø interfaces Ø classes Ø objects Ø Relations: Ø dependency Ø association (composition) Ø implementation <<component>> Data. Base <<realize>> ODBC <<component>> Business 27

Deployment diagrams Ø Entities: + nodes Ø Relations: + association between nodes + placement of a component on a node <<component>> <<document>> Help <<component>> Data. Base LAN 1. . * 1 <<realize>> ODBC <<component>> GUI <<component>> Workstation Server Business 28

State diagrams Ø Entities: Ø states: name, activity, entry/exit action Ø Relations: Ø transitions between states: event, condition, action State 1 do / activity entry / action exit / action State 2 event (arg) [ condition ] / action do / activity entry / action exit / action 29

State diagrams: example 1 Copy borrow return 1. . * Book borrow return Copy On loan entry / book. borrow( ) return( ) borrow( ) On shelf entry / book. return( ) Book Not borrowable return( ) borrow( ) [ last copy ] Borrowable borrow( ) [ not last copy ] 30

State diagrams: example 2 (composite state) Traffic. Light Off On Turn. On Working Turn. Off after 30 sec Blinking Switch. Off Switch. On Red Yellow Red after 5 sec after 3 sec Green Yellow Green after 45 sec 31

Activity diagrams Ø Entities: Ø activities Ø Relations: Ø transitions between activities Ø Sugar Ø decisions Ø forks Ø swimlanes Customer Sales Stockroom Request service Take order Pay Fill order Deliver order Collect order 32

Sequence diagrams Ø Entities: Ø objects (including instances of actors) Ø Relations: Ø message passing Ø Sugar: Ø lifelines Ø activations Ø creations Ø destructions Ø frames : Client : Terminal insert. Card( ) insert. PIN( ) Time 33

Nested messages : Client : Terminal insert. Card( ) : Client. Data : Display check( data ) ok / nok display. Message( text ) The source of an arrow indicates the activation which sent the message An activation is as long as all nested activations 34

Creation and destruction : Terminal start( ) : Session log( ) close( ) Creation is denoted by a message arrow pointing to the object In garbage collection environments, destruction can be used to denote the end of the useful life of an object 35

Interaction frames : Container loop [for each item] : Processor : Item process() alt [value < 100] [else] increase() decrease() 36

Communication diagrams Ø Entities: Ø objects Ø Relations: Ø message passing 1. insert. Card( ) : Client : Terminal 1. 1 check(data) : Client. Data 1. 2 display. Message(text) : Display 37

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

Example: modeling the ATM Ø Modeling usage: use case diagram Refuse Withdrawal <<extend>> Withdraw Load Cash Card <<include>> Authenticate Client Transfer <<include>> 39

Use case example: Withdraw Initiating actor: Client Entry condition Ø Client has opened a bank account with the bank and Ø Client has received a bank card and PIN Exit condition Ø Client has the requested cash or Ø Client receives an explanation from the ATM about why the cash could not be dispensed 40

Use case example: Withdraw event flow Actor steps 1. Authenticate 3. Client selects “Withdraw CHF” 5. Client enters amount System Steps 2. ATM displays options 4. ATM queries amount 6. ATM returns bank card 7. ATM outputs specified amount in CHF Details of authentication Anything missing? Exceptional cases 41

Withdraw event flow revisited Referring to included use case Actor steps System Steps 1. Authenticate (use case Authenticate) 3. Client selects “Withdraw CHF” 2. ATM displays options 5. Client enters amount 4. ATM queries amount 6. ATM returns bank card 7. ATM outputs specified amount in CHF (ext. point: Refuse Withdrawal) Listed as extension point 42

From use cases to sequence diagrams : Terminal : Client select (withdraw CHF) : Display : Account init. Withdraw (cur) : Withdrawal query. Amount( ) select (option) withdraw (amount) check(amount, cur) okay withdraw (amount, cur) eject. Card( ) taken display. Confimation( ) dispense(amount, cur) 43

. . . and futher to class diagrams Ø Add a class for each object on the diagram Ø For each object that receives an event add a public operation in the associated class : Account check (amount, cur) okay withdraw (amount, cur) Account check (int, Currency): boolean withdraw (int, Currency) ØIdentify additional classes (e. g. for message arguments, messages with no receivers) Ø Problem text analysis may help (nouns may correspond to classes, verbs – to operations) 44

Practical tips Ø Create component and deployment diagrams only for large, distributed systems Ø 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 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