1
play

1 Architecture vs. Software Engineering Problem Problem Design - PDF document

Jun 26, 2023 •250 likes •406 views

Chair of Softw are 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

  1. Chair of Softw are 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 ignore irrelevant details � They represent only the relevant details � What is relevant or irrelevant depends on the purpose of the model 3 1

  2. Architecture vs. Software Engineering Problem Problem Design Model Reverse Implementation engineering 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 2

  3. 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 h t k d ti ibl � 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 3

  4. Entities in UML � 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 with the system � Use case – a description of a set of scenarios (sequences of events and Actor actions) that produce a result, significant Use case for some actor � Component – physically replaceable Component artifact that provides a certain set of interfaces 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 or waiting for an event � Activity – a state, in which the object is doing some work (instead of just Activity passively waiting for an event) � Grouping � Package – a group of model elements (maybe including other packages) Package � Annotating � Note – arbitrary text comment attached to a model Note 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 4

  5. Relations in UML � Dependency – changing the independent entity may dependent independent influence the dependent one � Association – entities are entity1 entity2 directly connected (e.g. aggregation) � Generalization – an entity y is a special case of another descendant ancestor entity, they satisfy the substitution principle � Implementation – an entity is an implementation implementation interface of another entity (e.g. a class and an 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) l ) � 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) time) • Communication diagram (message passing) • Interaction overview diagram (= activity diagram with interaction diagrams in nodes) • Timing diagram (focus on timing constraints) 15 5

  6. 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 b t th � 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: Search entries � actors � use cases <<include>> � Relations: � association between an List entries actor and a use case Reader � generalization between � generalization between actors Log in � generalization between <<extend>> use cases Refuse Log in � dependencies between use cases Submitter � Comments: OpenID Log in � system boundaries 17 Reusing use cases Withdraw <<include>> Load <<include>> Authenticate Cash Card Client <<include>> Transfer <<include>> stereotype to include use cases: reusing common functionality, no duplicates 18 6

  7. Separating variant behavior <<initiates>> <<extend>> Refuse Withdraw Not enough Withdrawal Client money <<participates>> Host <<extend>> stereotype to provide special case Normal case specifies point at which the behavior may diverge ( extension point ) 19 Class diagrams � Entities: IChief ISubordinate send_petition report � classes (and <<instantiate>> interfaces) Report � Relations: Position � association between occupy classes Department free request_report � generalization g send petition send_petition between classes <<call>> � implementation between a class and IPosition 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 classes free Department request_report � generalization g send petition send_petition between classes � implementation <<realize>> between a class and an interface IPosition � dependencies between classes Manager 21 7

  8. 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 1 is capital of 1 City Country � 1-to-many 3..* Polygon Point � many-to-many * works for * Person 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 3 TicketMachine ZoneButton 24 8

  9. 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 1 1 Password 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 3..* 0..1 Polygon number Point {frozen, ordered} {ordered} 26 Component diagrams � Entities: � components <<component>> • programs • documents DataBase • files • libraries <<realize>> • DB tables � interfaces i t f ODBC ODBC � classes � objects � Relations: <<component>> � dependency Business � association (composition) � implementation 27 9

Recommend

More recommend