Software Design, Modelling and Analysis in UML Lecture 20: Inheritance 2016-02-04 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal – 20 – 2016-02-04 – main – Albert-Ludwigs-Universit¨ at Freiburg, Germany
Contents & Goals Last Lecture: • Firedset, Cut • Automaton construction • Transition annotations This Lecture: • Educational Objectives: Capabilities for following tasks/questions. • What’s the Liskov Substitution Principle? • What is late/early binding? • What is the subset / uplink semantics of inheritance? • What’s the effect of inheritance on LSCs, State Machines, System States? • Content: – 20 – 2016-02-04 – Sprelim – • Inheritance in UML: concrete syntax • Liskov Substitution Principle — desired semantics • Two approaches to obtain desired semantics 2 /30
Inheritance: Syntax – 20 – 2016-02-04 – main – 3 /30
Abstract Syntax A signature with inheritance is a tuple S = ( T , C , V, atr , E , F, mth , ⊳ ) where • ( T , C , V, atr , E ) is a signature with signals and behavioural features ( F/ mth are methods, analogous to V/ atr attributes), and • ⊳ ⊆ ( C × C ) ∪ ( E × E ) is an acyclic generalisation relation, i.e. C ⊳ + C for no C ∈ C . In the following (for simplicity), we assume that all attribute (method) names are of the form C :: v and C :: f for some C ∈ C ∪ E (“ fully qualified names ”). Read C ⊳ D as. . . • D inherits from C , – 20 – 2016-02-04 – Ssyntax – • C is a generalisation of D , • D is a specialisation of C , • C is a super-class of D , • D is a sub-class of C , • . . . 4 /30
Helper Notions Definition. (i) For classes C 0 , C 1 , D ∈ C , we say D inherits from C 0 via C 1 if 0 , . . . C n 1 , . . . C m and only if there are C 1 0 , C 1 1 ∈ C , n, m ≥ 0 , s.t. C 0 ⊳ C 1 0 ⊳ . . . C n 0 ⊳ C 1 ⊳ C 1 1 ⊳ . . . C m 1 ⊳ D. (ii) We use ⊳ ∗ to denote the reflexive, transitive closure of ⊳ . – 20 – 2016-02-04 – Ssyntax – 5 /30
Inheritance: Concrete Syntax Common graphical representations (of ⊳ = { ( C, D 1 ) , ( C, D 2 ) } ): C C C D 1 D 2 D 1 D 2 D 1 D 2 Mapping Concrete to Abstract Syntax by Example: C 0 x : Int D – 20 – 2016-02-04 – Ssyntax – x : Int C 1 C 2 Note : we can have multiple inheritance . 6 /30
Inheritance: Desired Semantics – 20 – 2016-02-04 – main – 7 /30
Desired Semantics of Specialisation: Subtyping There is a classical description of what one expects from sub-types , which is closely related to inheritance in object-oriented approaches: The principle of type substitutability Liskov (1988); Liskov and Wing (1994) ( Liskov Substitution Principle (LSP)). “If for each object o 1 of type S there is an object o 2 of type T such that for all programs P defined in terms of T the behavior of P is unchanged when o 1 is substituted for o 2 then S is a subtype of T .” In other words: Fischer and Wehrheim (2000) “An instance of the sub-type shall be usable whenever an instance of the supertype was expected, without a client being able to tell the difference .” – 20 – 2016-02-04 – Slsp – 8 /30
s Student Subtyping: Example 0 , 1 att : Int Teacher t 0 , 1 GenStWorker workload : Int Genius Polite Clown SM Teacher • • s 1 /t ! Silence s 1 : Student SM Student s : Teacher GoodAns / [ s. att > 0] /s ! Q Q/ att = 3 t /t ! GoodAns s 2 s 2 /t ! WrongAns • s 1 WrongAns / SM Genius s : Teacher : Genius Q/ t /t ! GoodAns s 2 • /t ! Silence s 1 SM Polite s : Teacher : Polite Q/ t /t ! GoodAns s 2 • s 1 SM Clown s : Teacher : Clown Q/ – 20 – 2016-02-04 – Slsp – t /t ! StupidJoke s 2 • • SM GenStWorker • s 1 s : Teacher : GenStWorker s 3 Q/ t /t ! GoodAns Task / s 2 9 /30
Domain Inclusion Semantics – 20 – 2016-02-04 – main – 10 /30
Domain Inclusion Structure A domain inclusion structure D for signature S = ( T , C , V, atr , E , F, mth , ⊳ ) • [ as before ] maps types, classes, associations to domains, • [ for completeness ] maps methods to transformers, • [ as before ] has infinitely many object identities per class in D ( D ) , • [ changed ] the indentities of a super-class comprise all identities of sub-classes, i.e. ∀ C ⊳ D ∈ C : D ( D ) � D ( C ) and indentities of instances of classes not (transitively) related by generalisation are disjoint, i.e. C � ⊳ + D and D � ⊳ + C implies D ( C ) ∩ D ( D ) = ∅ . Note : the old setting coincides with the special case ⊳ = ∅ . – 20 – 2016-02-04 – Sdiocl – 11 /30
� Domain Inclusion System States A system state of S wrt. (domain inclusion structure) D is a type-consistent mapping σ : D ( C ) � → ( V → ( D ( T ) ∪ D ( C 0 , 1 ) ∪ D ( C ∗ ))) that is, for all u ∈ dom( σ ) ∩ D ( C ) , • [ as before ] σ ( u )( v ) ∈ D ( T ) if v : T , • [ changed ] σ ( u ) , u ∈ D ( C ) , has values for all attributes of C and all of its superclasses, i.e. � dom( σ ( u )) = atr ( C 0 ) . C 0 ⊳ ∗ C C 0 , 1 Example : x : Int n – 20 – 2016-02-04 – Sdiocl – D x : Int y : Int Note : the old setting still coincides with the special case ⊳ = ∅ . 12 /30
OCL Syntax and Typing • Recall (part of the) OCL syntax and typing ( C, D ∈ C , v, r ∈ V ) expr ::= v ( expr 1 ) : τ C → T ( v ) , if v : T ∈ atr ( C ) , T ∈ T | r ( expr 1 ) : τ C → τ D , if r : D 0 , 1 ∈ atr ( C ) | r ( expr 1 ) : τ C → Set ( τ D ) , if r : D ∗ ∈ atr ( C ) The syntax basically stays the same: expr ::= C :: v ( expr 1 ) : τ C → T ( v ) , if C :: v : T ∈ atr ( C ) , T ∈ T | . . . | v ( expr 1 ) : τ C → T ( v ) , | r ( expr 1 ) : τ C → τ D , | r ( expr 1 ) : τ C → Set ( τ D ) , but typing rules change : we require a unique biggest superclass C 0 ⊳ ∗ C ∈ C with, e.g., v ∈ atr ( C 0 ) and for this v we have v : T . C 0 , 1 x : Int – 20 – 2016-02-04 – Sdiocl – Example : z : Int n D x : Int y : Int Note : the old setting still coincides with the special case ⊳ = ∅ . 13 /30
Visibility and Inheritance Example : C − v 1 : Int # v 2 : Int v 1 < 0 v 2 < 0 v 3 < 0 + v 3 : Int context C inv : context D inv : D n.v 1 < 0 n.v 2 < 0 n.v 3 < 0 n 0 , 1 context B inv : B E.g. v ( . . . ( self ) . . . ) is well-typed • if v is public, or – 20 – 2016-02-04 – Sdiocl – • if v is private, and self : τ C and v ∈ atr ( C ) , or • if v is protected, and self : τ C and D ⊳ ∗ C (unique, biggest) and v ∈ atr ( D ) . 14 /30
Satisfying OCL Constraints (Domain Inclusion) I DI � expr � ( σ ) := I � Normalise ( expr ) � ( σ ) using the same textual definition of I that we have. – 20 – 2016-02-04 – Sdiocl – 15 /30
Expression Normalisation Normalise : • Given expression v ( . . . ( w ) . . . ) with w : τ D , • normalise v to ( = replace by) C :: v , • where C is the unique most special more general class with C :: v ∈ atr ( C ) , i.e. ∀ C ⊳ ∗ C 0 ⊳ ∗ D • C 0 = C. Note : existence of such an C is guaranteed by (the new) OCL well-typedness. Example : A • context D inv : x < 0 x : Int • context C inv : x < 0 – 20 – 2016-02-04 – Sdiocl – C 0 , 1 • context A inv : x < 0 x : Int n • context D inv : n < 0 • context C inv : n < 0 D • context D inv : A :: x < 0 16 /30
OCL Example A A :: x : Int σ : u 2 : C u 3 : D D :: n u 1 : A A :: x = 1 A :: x = 2 C A :: x = 0 0 , 1 C :: x = 27 C :: x = 13 C :: x : Int D :: n D • I � context D inv : A :: x < 0 � ( σ, { self �→ u 1 } ) • I � context D inv : x < 0 � ( σ, { self �→ u 3 } ) – 20 – 2016-02-04 – Sdiocl – � , if u 1 ∈ dom( σ ) σ ( u 1 )( v ) I � v ( expr 1 ) � ( σ, β ) := ⊥ , otherwise 17 /30
Excursus: Late Binding of Behavioural Features – 20 – 2016-02-04 – main – 18 /30
Late Binding What transformer applies in what situation? (Early (compile time) binding.) f overridden in D f not overridden in D value C C of C e m o s f () : Int f () : Int someC/ C 0 someD D someD D f () : Int someC -> f () C :: f () C :: f () u 1 someD -> f () C :: f () D :: f () u 2 someC -> f () C :: f () D :: f () u 2 What one could want is something different: (Late binding.) – 20 – 2016-02-04 – Slatebind – u 1 someC -> f () C :: f () C :: f () someD -> f () D :: f () D :: f () u 2 someC -> f () C :: f () C :: f () u 2 19 /30
Late Binding in the Standard and Programming Languages • In the standard , Section 11.3.10, “CallOperationAction”: “ Semantic Variation Points The mechanism for determining the method to be invoked as a result of a call operation is unspecified.” (OMG, 2007, 247) • In C ++ , • methods are by default “ (early) compile time binding ”, • can be declared to be “ late binding ” by keyword “ virtual ”, • the declaration applies to all inheriting classes. • In Java , • methods are “ late binding ”; – 20 – 2016-02-04 – Slatebind – • there are patterns to imitate the effect of “ early binding ” Note : late binding typically applies only to methods , not to attributes . (But: getter/setter methods have been invented recently.) 20 /30
Behaviour (Inclusion Semantics) – 20 – 2016-02-04 – main – 21 /30
Semantics of Method Calls • Non late-binding : by normalisation. • Late-binding : Construct a method call transformer, which looks up the method transformer corresponding to the class we are an instance of. – 20 – 2016-02-04 – Sdistm – 22 /30
Recommend
More recommend
