/50 5/50 2/50 3/50 6/50. UML-Notationsübersicht. Teil 1/4. Figure Examples of navigable ends. enda. endb main

Transcription

1 a c e g i b d f h j * * Software Design, Modelling and Analysis in UML Lecture 07: Class Diagrams II Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universität Freiburg, Germany UML Class Diagram Syntax [?] ndiagramm Abstrakte «Stereotyp, Stereotyp2» Paket:: attribut operation() «Stereotyp» attribut = wert Syntax für Attribute: Sichtbarkeit Attributname : Paket::Typ [ Ordnung] = Initialwert {Eigenschaftswerte} Eigenschaftswerte: {readonly}, {ordered}, {composite} Syntax für Operationen: Sichtbarkeit Operationsname (Parameterliste):Rückgabetyp {Eigenschaftswerte} Sichtbarkeit: Parameterliste: Richtung Name : Typ = Standardwert + public element Eigenschaftswerte: {query} # protected element Richtung: in, out, inout private element ~ package element Entity Control Boundary Aktive Parametrisierte <Parameter> i:element Parametrisierbare Objektdiagramm Objekt : Aktives Objekt Objekt: attribut = wert Objekt Vererbung Attributierte sklasse gerichtete qualifizierte Qualifizierer 2 Realisierung Abhängige Abhängigkeit Unabhängige 3 2 "Stecker" bereitgestellte genutzte "Buchse" -A -A operation() operation2() Notiz 2006 by oose.de GmbH Aktuelle Fassung, Info und Download: UML-Notationsübersicht /4 4/ Sprelim Contents & Goals Last Lectures: VL 05: class diagram except for associations VL 06: semantics of 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? 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? UML Class Diagram Syntax [?] Vererbung Attributierte sklasse gerichtete qualifizierte Qualifizierer 2 Realisierung Abhängige Abhängigkeit Unabhängige 3 2 "Stecker" bereitgestellte genutzte "Buchse" -A -A operation() operation2() Notiz 2006 by oose.de GmbH Aktuelle Fassung, Info und Download: UML-Notationsübersicht /4 2/50 5/50 Associations: Syntax 3/50 UML Class Diagram Syntax [?, 6;43] enda endb BinaryAssociationAB Figure Graphic notation indicating exactly one association end owned by the association E F G H I J Figure Examples of navigable ends Figure Combining line path graphics 6/50

2 What Do We (Have to) Cover? An association has a name, a reading direction, and gerichtete qualifizierte Qualifizierer 2 at least two ends. Each end has a role name, a multiplicity, a set of properties, such as unique, ordered, etc. a qualifier, a visibility, a navigability, an ownership, Attributierte sklasse 3 and possibly a diamond. Wanted: places in the signature to represent the information from the picture. 2 (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. Formally: we only call (Ì,, V,atr) a signature (extended for associations) if atr : 2 {v V v:τ,τ Ì }. 7/50 9/50 (Temporarily) Extend Signature: Associations Only for the course of Lectures 07/08 we assume that each attribute in V either is v : τ, ξ,expr 0, Pv with τ Ì (as before), or is an association of the form r : role : C, µ, P, ξ, ν, o, where n 2 (at least two ends), r, rolei are just names, Ci, i n, the multiplicity µi is an expression of the form µ ::= N N..M N.. µ, µ (N, M N) Pi is a set of properties (as before), ξ {+,, #, } (as before), νi {,, >} is the navigability, oi B is the ownership. 8/50 From Association Lines to Extended Signatures C r C2... Cn maps to r : role : C, µ, P, ξ, ν, o Pi ξi rolei Ci µi, if Ci oi = 0, if Ci, if Ci νi =, if Ci >, if Ci 0/50 (Temporarily) Extend Signature: Associations Only for the course of Lectures 07/08 we assume that each attribute in V either is v : τ, ξ,expr 0, Pv with τ Ì (as before), or is an association of the form r : role : C, µ, P, ξ, ν, o, Alternative syntax for multiplicities: µ ::= N..M N.. µ, µ (N, M N { }) and define and N as abbreviations. where Note: n N 2 (at could least abbreviate two ends), 0..N,..N, or N..N. We use last one. r, rolei are just names, Ci, i n, the multiplicity µi is an expression of the form µ ::= N N..M N.. µ, µ (N, M N) Pi is a set of properties (as before), ξ {+,, #, } (as before), νi {,, >} is the navigability, oi B is the ownership. Association Example C c r +n D x : Int Signature: Ë = ({Int}, {C, D},{x : Int, r : c : D,, {unique},,, 0, n : C,, {unique}, +, >, }, {C, D {x}}) 8/50 /50

3 What If Things Are Missing? Most components of associations or association end may be omitted. For instance [?, 7], Section 6.4.2, proposes the following rules: Name: Use if the name is missing. A C Cn Example: A for Reading Direction: no default. Role Name: use the class name at that end in lower-case letters Example: c d for Other convention: (used e.g. by modelling tool Rhapsody) itsc itsd for Association Semantics 2/50 5/ Sassocover What If Things Are Missing? Multiplicity: In my opinion, it s safer to assume 0.. or if there are no fixed, written, agreed conventions ( expect the worst ). Properties: Visibility: public Navigability and Ownership: not so easy. [?, 43] 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. 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. 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 Pv = {unique}. Properties (in general) and ownership: later. 3/50 6/50 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? 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. Association Semantics: The System State Aspect 4/50 7/50

4 Sassocsem Associations in General Recall: We consider associations of the following form: r : role : C, µ, P, ξ, ν, o,..., Only these parts are relevant for extended system states: r : role : C,, P,,,,..., rolen : Cn,, Pn,,, (recall: we assume P = Pn = {unique}). The UML standard thinks of associations as n-ary relations which live on their own in a system state. 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). 8/ Sassocsem Sassocsem Links in System States r : role : C,, P,,,,..., rolen : Cn,, Pn,,, Only for the course of lectures 07/08 we change the definition of system states: 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 : C,..., rolen : Cn V a relation λ(r) (C) (C) (i.e. a set of type-consistent n-tuples of identities). Extended System States and Object Diagrams Legitimate question: how do we represent system states such as σ = {C, 3D {x }, 7D {x 2}} λ = {A {(C, 3D), (C, 7D)}} as object diagram? 9/50 2/ Sassocsem Association/Link Example C n D x : Int Signature: Ë = ({Int}, {C, D},{x : Int, A : c : D,, {unique},, 0, {C, D {x}}) n : C,, {unique}, >, }, A system state of Ë (some reasonable ) is (σ, λ) with: σ = {C, 3D {x }, 7D {x 2}} λ = {A {(C, 3D), (C, 7D)}} Associations and OCL 20/50 22/50

5 Sassococl OCL and Associations: Syntax Recall: OCL syntax as introduced in Lecture 03, interesting part: expr ::=... r(expr ) : τc τd r : D0, atr(c) r2(expr ) : τc Set(τD) r2 : D atr(c) Now becomes expr ::=... role(expr ) : τc τd µ = 0.. or µ = role(expr ) : τc Set(τD) otherwise if r :..., role : D, µ,,,,,..., role : C,,,,,,... V or r :..., role : C,,,,,,..., role : D, µ,,,,,... V,role role. Note: Association name as such doesn t occur in OCL syntax, role names do. expr has to denote an object of a class which participates in the association. 23/50 References 49/50 50/50