Software Design, Modelling and Analysis in UML

Transcription

1 Software Design, Modelling and Analysis in UML Lecture 08: Class Diagrams II main Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universität Freiburg, Germany

2 Contents & Goals Last Lectures: class diagram except for associations; visibility within OCL type system This Lecture: Educational Objectives: Capabilities for following tasks/questions. Please explain this class diagram with associations. Which annotations of an association arrow are semantically relevant? What s a role name? What s it good for? What s multiplicity? How did we treat them semantically? What is reading direction, navigability, ownership,...? What s the difference between aggregation and composition? Sprelim Content: Study concrete syntax for associations. (Temporarily) extend signature, define mapping from diagram to signature. Study effect on OCL. Where do we put OCL constraints? 2/50

3 Associations: Syntax 3/ main

4 UML Class Diagram Syntax [Oestereich, 2006] Klassendiagramm Klasse Sichtbarkeit: + public element # protected element private element ~ package element Abstrakte Klasse «Stereotyp1, Stereotyp2» Paket::Klasse attribut operation() «Stereotyp1» attribut = wert Syntax für Attribute: Sichtbarkeit Attributname : Paket::Typ [Multiplizität Ordnung] = Initialwert {Eigenschaftswerte} Eigenschaftswerte: {readonly}, {ordered}, {composite} Syntax für Operationen: Sichtbarkeit Operationsname (Parameterliste):Rückgabetyp {Eigenschaftswerte} Parameterliste: Richtung Name : Typ = Standardwert Eigenschaftswerte: {query} Richtung: in, out, inout Entity Control Boundary Aktive Klasse Parametrisierte Klasse<Parameter> i:element Parametrisierbare Klasse Objektdiagramm Objekt Aktives Objekt Objekt:Klasse attribut = wert :Klasse Objekt Vererbung Attributierte Assoziation Assoziation Assoziationsklasse gerichtete Assoziation qualifizierte Assoziation Qualifizierer Realisierung Ganzes Aggregation Komposition Mehrgliedrige Assoziation Teil Existenzabhängiges Teil Sassocsyn Abhängige Klasse Anbieter "Stecker" bereitgestellte Schnittstelle genutzte Schnittstelle "Buchse" Schnittstelle Abhängigkeit Klasse Unabhängige Klasse Nutzer Anbieter Nutzer 2006 by oose.de GmbH Aktuelle Fassung, Info und Download: «interface» Schnittstelle-A «interface» Schnittstelle-A 1 Multiplizität Leserichtung «Stereotyp» Beziehungsname * {ordered} rolle Klasse3 «interface» Schnittstelle operation1() operation2() Sichtbarkeit rolle Notiz UML-Notationsübersicht Teil 1/4 4/50

5 UML Class Diagram Syntax [Oestereich, 2006] Vererbung Attributierte Assoziation Assoziation Assoziationsklasse gerichtete Assoziation qualifizierte Assoziation Qualifizierer Realisierung Ganzes Aggregation Komposition Mehrgliedrige Assoziation Teil Existenzabhängiges Teil Sassocsyn Abhängige Klasse Anbieter "Stecker" bereitgestellte Schnittstelle genutzte Schnittstelle "Buchse" Schnittstelle Abhängigkeit Klasse Unabhängige Klasse Nutzer Anbieter Nutzer 2006 by oose.de GmbH Aktuelle Fassung, Info und Download: «interface» Schnittstelle-A «interface» Schnittstelle-A 1 Multiplizität Leserichtung «Stereotyp» Beziehungsname * {ordered} rolle Klasse3 «interface» Schnittstelle operation1() operation2() Sichtbarkeit rolle Notiz UML-Notationsübersicht Teil 1/4 5/50

6 UML Class Diagram Syntax [OMG, 2007b, 61;43] A enda endb * BinaryAssociationAB * B A a 1..4 b 2..5 B Figure Graphic notation indicating exactly one association end owned by the association C c 1..4 d 2..5 D E e 1..4 f 2..5 F G g 1..4 h 2..5 H A B Sassocsyn i j I J Figure Examples of navigable ends A Figure Combining line path graphics B 6/50

7 What Do We (Have to) Cover? Assoziation An association has gerichtete Assoziation a name, a reading direction, and qualifizierte Assoziation Qualifizierer at least two ends. Each end has Attributierte Assoziation a role name, a multiplicity, Assoziationsklasse Sassocsyn a set of properties, such as unique, ordered, etc. a qualifier, a visibility, a navigability, an ownership, and possibly a diamond. Wanted: places in the signature to represent the information from the picture. Ganzes 1 Multiplizität Leserichtung «Stereotyp» Beziehungsname * {ordered} rolle Aggregation Komposition Mehrgliedrige Assoziation Klasse3 Teil Existenzabhängiges Teil Sichtbarkeit rolle 7/50

8 (Temporarily) Extend Signature: Associations Only for the course of Lectures 08/09 we assume that each attribute in V either is v : τ, ξ,expr 0, P v with τ Ì (as before), Sassocsyn or is an association of the form where n 2 (at least two ends), r : role 1 : C 1, µ 1, P 1, ξ 1, ν 1, o 1,. role n : C n, µ n, P n, ξ n, ν n, o n r, role i are just names, C i, 1 i n, the multiplicity µ i is an expression of the form µ ::= N N..M N.. µ, µ (N,M N) P i is a set of properties (as before), ξ {+,, #, } (as before), ν i {,, >} is the navigability, o i B is the ownership. 8/50

9 Sassocsyn (Temporarily) Extend Signature: Associations Only for the course of Lectures 08/09 we assume that each attribute in V either is v : τ, ξ,expr 0, P v Ì with τ (as before), or is an association of the form r : role 1 : C 1, µ 1, P 1, ξ 1, ν 1, o 1, Alternative syntax for multiplicities:. µ ::= N..M N.. µ, µ (N, M N { }) role n : C n, n, P n, ξ n, ν n, o n and define and N as abbreviations. where Note: n N2 (at could leastabbreviate two ends), 0..N, 1..N, or N..N. We use last one. r, role i are just names, C i, 1 i n, the multiplicity µ i is an expression of the form µ ::= N N..M N.. µ, µ (N,M N) P i is a set of properties (as before), ξ {+,, #, } (as before), ν i {,, >} is the navigability, o i B is the ownership. 8/50

10 (Temporarily) Extend Signature: Basic Type Attributes Also only for the course of this lecture we only consider basic type attributes to belong to a class (to appear in atr(c)), associations are not owned by a particular class (do not appear in atr(c)), but live on their own Sassocsyn Formally: we only call (Ì,, V,atr) a signature (extended for associations) if atr : 2 {v V }. v:τ,τ Ì 9/50

11 From Association Lines to Extended Signatures C 1 r C 2. C n r : role 1 : C 1, µ 1, P 1, ξ 1, ν 1, o 1 maps to. P i role n : C n, µ n, P n, ξ n, ν n, o n ξ i role i C i µ i Sassocsyn o i = 1, if C i ν i = 0, if C i, if C i, if C i >, if C i 10/50

12 Association Example C c 0.. r +n 0.. x : Int D Signature: = ({Int}, {C, D},{x : Int, Ë r : c : D, 0.., {unique},,, 0, n : C, 0.., {unique}, +, >, 1 }, {C, D {x}}) Sassocsyn 11/50

13 What If Things Are Missing? Most components of associations or association end may be omitted. For instance [OMG, 2007b, 17], Section 6.4.2, proposes the following rules: Name: Use if the name is missing. A C 1 C n Example: C A C D D for C D Sassocsyn Reading Direction: no default. Role Name: use the class name at that end in lower-case letters Example: c d C D for C D Other convention: (used e.g. by modelling tool Rhapsody) itsc itsd C D for C D 12/50

14 What If Things Are Missing? Multiplicity: 1 In my opinion, it s safer to assume 0..1 or if there are no fixed, written, agreed conventions ( expect the worst ). Properties: Visibility: public Navigability and Ownership: not so easy. [OMG, 2007b, 43] Sassocsyn Various options may be chosen for showing navigation arrows on a diagram. In practice, it is often convenient to suppress some of the arrows and crosses and just show exceptional situations: Show all arrows and x s. Navigation and its absence are made completely explicit. Suppress all arrows and x s. No inference can be drawn about navigation. This is similar to any situation in which information is suppressed from a view. Suppress arrows for associations with navigability in both directions, and show arrows only for associations with one- way navigability. In this case, the two-way navigability cannot be distinguished from situations where there is no navigation at all; however, the latter case occurs rarely in practice. 13/50

15 Wait, If Omitting Things......is causing so much trouble (e.g. leading to misunderstanding), why does the standard say In practice, it is often convenient...? Is it a good idea to trade convenience for precision/unambiguity? Sassocsyn It depends. Convenience as such is a legitimate goal. In UML-As-Sketch mode, precision doesn t matter, so convenience (for writer) can even be a primary goal. In UML-As-Blueprint mode, precision is the primary goal. And misunderstandings are in most cases annoying. But: (even in UML-As-Blueprint mode) If all associations in your model have multiplicity, then it s probably a good idea not to write all these s. So: tell the reader about it and leave out the s. 14/50

16

17 Association Semantics 15/ main

18 Overview What s left? Named association with at least two typed ends, each having a role name, a multiplicity, a set of properties, a visibility, a navigability, and an ownership Sassocover The Plan: Extend system states, introduce so-called links as instances of associations depends on name and on type and number of ends. Integrate role name and multiplicity into OCL syntax/semantics. Extend typing rules to care for visibility and navigability Consider multiplicity also as part of the constraints set Inv(CD). Properties: for now assume P v = {unique}. Properties (in general) and ownership: later. 16/50

19 Association Semantics: The System State Aspect main 17/50

20 Associations in General Recall: We consider associations of the following form: r : role 1 : C 1, µ 1, P 1, ξ 1, ν 1, o 1,..., role n : C n, µ n, P n, ξ n, ν n, o n Only these parts are relevant for extended system states: r : role 1 : C 1,, P 1,,,,..., role n : C n,, P n,,, (recall: we assume P 1 = P n = {unique}). The UML standard thinks of associations as n-ary relations which live on their own in a system state Sassocsem That is, links (= association instances) do not belong (in general) to certain objects (in contrast to pointers, e.g.) are first-class citizens next to objects, are (in general) not directed (in contrast to pointers). 18/50

21 Links in System States r : role 1 : C 1,, P 1,,,,..., role n : C n,, P n,,, Only for the course of lectures 07/08 we change the definition of system states: Sassocsem Definition. Let be a structure of the (extended) signature = (Ì,, V,atr). Ë A system state Ë of wrt. is a pair (σ, λ) consisting of a type-consistent mapping σ : ( ) (atr( ) (Ì )), a mapping λ which assigns each association r : role 1 : C 1,..., role n : C n V a relation λ(r) (C 1 ) (C n ) (i.e. a set of type-consistent n-tuples of identities). 19/50

22

23 Association/Link Example C n 0.. x : Int D Signature: = ({Int}, {C, D},{x : Int, Ë A C D : c : C, 0.., +, {unique},, 1, n : D, 0.., +, {unique}, >, 0 }, {C, D {x}}) Sassocsem A system state of Ë (some reasonable ) is (σ, λ) with: σ = {1 C, 3 D {x 1}, 7 D {x 2}} λ = {A C D {(1 C, 3 D ), (1 C, 7 D )}} 20/50

24 Extended System States and Object Diagrams Legitimate question: how do we represent system states such as σ = {1 C, 3 D {x 1}, 7 D {x 2}} λ = {A C D {(1 C, 3 D ), (1 C, 7 D )}} as object diagram? Sassocsem 21/50

25 References 49/ main

26 References [Oestereich, 2006] Oestereich, B. (2006). Analyse und Design mit UML 2.1, 8. Auflage. Oldenbourg, 8. edition. [OMG, 2007a] OMG (2007a). Unified modeling language: Infrastructure, version Technical Report formal/ [OMG, 2007b] OMG (2007b). Unified modeling language: Superstructure, version Technical Report formal/ main 50/50