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

Chair of Softw are Engineering S ft Software Architecture A hit t 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 � Relationships between these abstractions shi s b t th s bst ti s 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 Problem P bl P Problem bl Design Model Model Reverse Reverse Implementation Implementation engineering Program 4

The Unified Modeling Language, UML � Modeling language = language for d l l l f 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 Authors: The Three Amigos h h h Grady Booch James Rumbaugh Ivar Jacobson Importance � Recommended OMG (Object Management Group) standard notation � De facto standard in industrial software � 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 f h l d b 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? � Programming language l � 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) � CASE tool specification C E l ifi i � 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 Name -attributes with common attributes and operations +operations() � Interface – a set of operations (a service), Interface provided by a class or component � Actor – an external entity that interacts � Actor an external entity that interacts with the system � Use case – a description of a set of scenarios (sequences of events and scenarios (sequences of events and Actor Actor actions) that produce a result, significant Use case for some actor � Component – physically replaceable Component artifact that provides a certain set of interfaces interfaces Node Node � Node – a hardware resource 10

Entities in UML � Behavioral � State – a period in an object lifecycle, during which the object is satisfying State some property, performing an activity some property, performing an activity or waiting for an event � Activity – a state, in which the object is doing some work (instead of just is doing some work (instead of just Activity Activity passively waiting for an event) � Grouping � Package – a group of model elements P k f d l l t (maybe including other packages) Package � Annotating 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 dependent independent influence the dependent one � Association – entities are entity1 entity2 directly connected (e.g. aggregation) aggregation) � Generalization – an entity is a special case of another descendant descendant ancestor ancestor entity, they satisfy the i h i f h substitution principle � Implementation – an � Implementation an entity is an implementation implementation interface of another entity (e.g. a class and an interface) l ss nd n int f ) 13

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 • Sequence diagram (message passing, ordered in S di ( i d d i 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 � Functional: What does the system do? s th s st m d ? � 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 g y q 16

Use case diagrams � Entities: � Entities: Search entries � actors � use cases <<include>> <<include>> � Relations: � association between an List entries actor and a use case actor and a use case Reader � generalization between actors Log in L i � generalization between <<extend>> use cases Refuse Log in � dependencies between � dependencies between use cases Submitter � Comments: OpenID Log in � system boundaries b d i 17

Reusing use cases Withdraw Withdraw <<include>> <<include>> Load Load <<include>> <<include>> Authenticate Cash Card Client Client <<include>> Transfer <<include>> stereotype to include use cases: reusing common functionality, no duplicates usin mm n fun ti n lit n dupli t s 18

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

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

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

Associations � Most widely used relation on class diagrams d l d l l d � 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 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 Cl i i h f 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