software design modelling and analysis in uml
play

Software Design, Modelling and Analysis in UML ...shall be usable... - PowerPoint PPT Presentation

Contents & Goals Last Lecture: Behavioural Features State Machines Variation Points Software Design, Modelling and Analysis in UML ...shall be usable... for UML Inheritance in UML: concrete syntax Liskov Substitution


  1. Contents & Goals Last Lecture: • Behavioural Features • State Machines Variation Points Software Design, Modelling and Analysis in UML “...shall be usable...” for UML • Inheritance in UML: concrete syntax • Liskov Substitution Principle — desired semantics Lecture 21: Inheritance II This Lecture: • Educational Objectives: Capabilities for following tasks/questions. • What’s the Liskov Substitution Principle? • What is late/early binding? 2014-02-05 • What is the subset, what the uplink semantics of inheritance? • What’s the effect of inheritance on LSCs, State Machines, System States? – 21 – 2014-02-05 – Sprelim – • What’s the idea of Meta-Modelling? – 21 – 2014-02-05 – main – – 21 – 2014-02-05 – main – Prof. Dr. Andreas Podelski, Dr. Bernd Westphal • Content: Albert-Ludwigs-Universit¨ at Freiburg, Germany • Two approaches to obtain desired semantics • The UML Meta Model 2 /74 3 /74 Easy: Static Typing Static Typing Cont’d C 1 C 2 itsC1 x : Int x : Int � � signal � � E f ( Int ) : Int f ( Int ) : Int C C 1 C 2 x : Int x : Int D 1 D 2 � � signal � � E itsD1 Given : f ( Int ) : Int f ( Int ) : Int x : Bool � � signal � � F f ( Float ) : Int Excursus: Late Binding of Behavioural Features D 1 D 2 Wanted : x : Bool � � signal � � F f ( Float ) : Int • x > 0 also well-typed for D 1 Notions (from category theory): • assignment itsC1 := itsD1 being well-typed • invariance , • itsC1 .x = 0 , itsC1 .f (0) , itsC1 ! F • covariance , being well-typed (and doing the right thing). • contravariance . Approach : We could call, e.g. a method, sub-type preserving , if and only if it • Simply define it as being well-typed, – 21 – 2014-02-05 – Sstatic – – 21 – 2014-02-05 – Sstatic – – 21 – 2014-02-05 – main – adjust system state definition to do the right thing. • accepts more general types as input ( contravariant ), • provides a more specialised type as output ( covariant ). This is a notion used by many programming languages — and easily type-checked. 4 /74 5 /74 6 /74

  2. Late Binding Late Binding in the Standard and Programming Lang. What transformer applies in what situation? (Early (compile time) binding.) • In the standard , Section 11.3.10, “CallOperationAction”: f overridden in D f not overridden in D “ Semantic Variation Points C value C The mechanism for determining the method to be invoked as a of m e C s o f () : Int Back to the Main Track: “...tell the difference...” for UML f () : Int someC/ result of a call operation is unspecified.” [OMG, 2007b, 247] C 0 someD someD D D • In C ++ , f () : Int someC -> f () C :: f () C :: f () u 1 • methods are by default “(early) compile time binding”, • can be declared to be “late binding” by keyword “ virtual ”, someD -> f () C :: f () D :: f () u 2 • the declaration applies to all inheriting classes. someC -> f () C :: f () D :: f () u 2 • In Java , What one could want is something different: (Late binding.) • methods are “late binding”; u 1 someC -> f () C :: f () C :: f () • there are patterns to imitate the effect of “early binding” – 21 – 2014-02-05 – Slatebind – – 21 – 2014-02-05 – Slatebind – someD -> f () D :: f () D :: f () u 2 – 21 – 2014-02-05 – main – Exercise : What could have driven the designers of C ++ to take that approach? someC -> f () C :: f () C :: f () u 2 Note : late binding typically applies only to methods , not to attributes . (But: getter/setter methods have been invented recently.) 7 /74 8 /74 9 /74 With Only Early Binding... Difficult: Dynamic Subtyping Sub-Typing Principles Cont’d C • In the standard, Section 7.3.36, “ Operation ”: f ( Int ) : Int • ...we’re done (if we realise it correctly in the framework). “ Semantic Variation Points • Then [...] When operations are redefined in a specialization, rules regarding D invariance , covariance , or contravariance of types and preconditions • if we’re calling method f of an object u , • C :: f and D :: f are type compatible , determine whether the specialized classifier is substitutable for its more • which is an instance of D with C � D but D is not necessarily a sub-type of C . f ( Int ) : Int general parent. Such rules constitute semantic variation points with respect to redefinition of operations.” [OMG, 2007a, 106] • via a C -link, • Examples : (C ++ ) • then we (by definition) only see and change the C -part. • So, better: call a method sub-type preserving , if and only if it • We cannot tell whether u is a C or an D instance. (i) accepts more input values ( contravariant ), int C::f(int) { int D::f(int) { (ii) on the old values , has fewer behaviour ( covariant ). So we immediately also have behavioural/dynamic subtyping. vs. return 0; return 1; Note : This (ii) is no longer a matter of simple type-checking! } ; } ; • And not necessarily the end of the story: • One could, e.g. want to consider execution time. – 21 – 2014-02-05 – Ssubtyping – – 21 – 2014-02-05 – Ssubtyping – – 21 – 2014-02-05 – Ssubtyping – • Or, like [Fischer and Wehrheim, 2000], relax to “fewer observable int C::f(int) { int D::f(int x) { behaviour”, thus admitting the sub-type to do more work on inputs. return (rand() % 2); vs. return (x % 2); } ; } ; Note : “testing” differences depends on the granularity of the semantics. • Related : “has a weaker pre-condition,” ( contravariant ), “has a stronger post-condition.” ( covariant ). 10 /74 11 /74 12 /74

  3. � Ensuring Sub-Typing for State Machines Towards System States C Wanted : a formal representation of “if C � D then D ‘ is a ’ C ”, that is, • In the CASE tool we consider, multiple classes (i) D has the same attributes and behavioural features as C , and in an inheritance hierarchy can have state machines. D (ii) D objects (identities) can replace C objects. • But the state machine of a sub-class cannot be drawn from scratch. Domain Inclusion Semantics We’ll discuss two approaches to semantics: • Instead, the state machine of a sub-class can only be obtained by • Domain-inclusion Semantics (more theoretical ) applying actions from a restricted set to a copy of the original one. Roughly (cf. User Guide, p. 760, for details), • add things into (hierarchical) states, • add more states, • attach a transition to a different target (limited). • They ensure , that the sub-class is a behavioural sub-type of the super • Uplink Semantics (more technical ) – 21 – 2014-02-05 – Ssubtyping – – 21 – 2014-02-05 – Ssubtyping – class. (But method implementations can still destroy that property.) – 21 – 2014-02-05 – main – • Technically, the idea is that (by late binding) only the state machine of the most specialised classes are running. By knowledge of the framework, the (code for) state machines of super-classes is still accessible — but using it is hardly a good idea... 13 /74 14 /74 15 /74 S = ( T , C , V, atr , E , F, mth , ⊳ ) be a signature. S wrt. D is a type-consistent mapping A Domain Inclusion Structure Domain Inclusion System States D ( C ) � → ( D ( T ) ∪ D ( C 0 , 1 ) ∪ D ( C ∗ ))) Preliminaries: Expression Normalisation v : Int D D ( C ) , Recall : Now : a system state of Let C • we want to allow, e.g., “context D inv : v < 0 ”. D ( τ ) if v : τ , τ ∈ T or τ ∈ { C ∗ , C 0 , 1 } . 0 , 1 v : Int σ : → ( V n Now a structure • we assume fully qualified names , e.g. C :: v . • [ as before ] maps types, classes, associations to domains, that is, for all u ∈ dom( σ ) ∩ Intuitively, v shall denote the “ most special more general ” C :: v according to ⊳ . D • [ for completeness ] methods to transformers, • [ as before ] σ ( u )( v ) ∈ • [ as before ] indentities of instances of classes not (transitively) related by To keep this out of typing rules, we assume that the following normalisation • [ changed ] dom( σ ( u )) = � C : D ( C ) � D ( D ) . C 0 � C atr ( C 0 ) , generalisation are disjoint, has been applied to all OCL expressions and all actions. Example : • [ changed ] the indentities of a super-class comprise all identities of • Given expression v (or f ) in context of class D , as determined by, e.g. C sub-classes, i.e. • by the (type of the) navigation expression prefix, or 0 , 1 � x : Int ∀ C ∈ n • by the class, the state-machine where the action occcurs belongs to, C ⊳ D • similar for method bodies, – 21 – 2014-02-05 – Sdomincl – – 21 – 2014-02-05 – Sdomincl – – 21 – 2014-02-05 – Sdomincl – • normalise v to ( = replace by) C :: v , D x : Int • where C is the greatest class wrt. “ � ” such that y : Int • C � D and C :: v ∈ atr ( C ) . Note : the old setting coincides with the special case ⊳ = ∅ . If no (unique) such class exists, the model is considered not well-formed ; the Note : the old setting still coincides with the special case ⊳ = ∅ . expression is ambiguous. Then: explicitly provide the qualified name . 16 /74 17 /74 18 /74

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend