Lightweight Verification of Executable Models
•Transferir como PPS, PDF•
1 gostou•793 visualizações
Presented on 30th International Conference on Conceptual Modeling (ER 2011). Brussels, Belgium.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Lightweight Verification of Executable Models
Semelhante a Lightweight Verification of Executable Models (20)
Mais de Elena Planas
Mais de Elena Planas (6)
Último
Último (20)
Lightweight Verification of Executable Models
- 1. Lightweight Verification of Executable Models Elena Planas Jordi Cabot Cristina Gómez Universitat Oberta de Catalunya (Spain) École des Mines de Nantes – INRIA (France) Universitat Politècnica de Catalunya (Spain) 3 0th International Conference on Conceptual Modeling November 3rd, 2011 - Brussels, Belgium
- 2. What is an Executable Model ? 1/19
- 3. What is an Executable Model ? is a model described in sufficient detail so that it can be (semi)automatically implemented/executed in the production environment 1/19
- 4. MDD : M odel- D riven D evelopment approach In MDD the quality of the final system implementation depends on the quality of the initial specification The existence of methods to verify the correctness of executable models is becoming crucial 2/19 Hight level Model Software system
- 5. Propose a verification method for Executable Models Lightweight (efficient) verification method Feedback suggesting possible corrections Action -based operations S trong E xecutability (SE) 3/19 our goal method features focus property
- 6. An operation is Strongly Executable if it is always successfully executed , that is, the operation’s execution generates a state consistent with all structural integrity constraints Not strongly executable 4/19 context Product inv productPrimaryKey: Product.allInstances() isUnique(code) context Product inv symmetricAssociation: self.p2.p2 includes(self) Product code: Integer price: Real CanBeSubstitutedBy * * p1 p2 STRUCTURAL MODEL activity newProduct (in _code: String, in _price: Real, in _substitutedProducts: Products[0..*]) { Product p = new Product(); p.code = _code; p.price = _price; for (i in 1.._substitutedProducts size()) CanBeSubstitutedBy.createLink(p1=>self,p2=>_substitutedProducts[i]); } } BEHAVIOURAL MODEL After executing newProduct , several constraints may become violated!
- 7. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s To determine if an operation is Strongly Executable we propose a three-step verification method 5/19
- 8. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s 6/19
- 9. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s An execution path is a consecutive sequence of actions that may be followed during the execution of an operation 6/19
- 10. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s An execution path is a consecutive sequence of actions that may be followed during the execution of an operation 6/19
- 11. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s An execution path activity newProduct (in _code: String, in _price: Real, in _substitutedProducts: Products[0..*]) { Product p = new Product(); p.code = _code; p.price = _price; for (i in 1.._substitutedProducts size()) CanBeSubstitutedBy.createLink(p1=>self,p2=>_substitutedProducts[i]); } } INPUT EXECUTION PATHS CanBeSubstitutedBy.createLink (p1=>self, p2=>_substitutedProducts[i]) p.price = _price p.code = _code p = new Product() for 7/19
- 12. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s 1st path An execution path activity newProduct (in _code: String, in _price: Real, in _substitutedProducts: Products[0..*]) { Product p = new Product(); p.code = _code; p.price = _price; for (i in 1.._substitutedProducts size()) CanBeSubstitutedBy.createLink(p1=>self,p2=>_substitutedProducts[i]); } } INPUT EXECUTION PATHS CanBeSubstitutedBy.createLink (p1=>self, p2=>_substitutedProducts[i]) p.price = _price p.code = _code p = new Product() for 7/19
- 13. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s An execution path activity newProduct (in _code: String, in _price: Real, in _substitutedProducts: Products[0..*]) { Product p = new Product(); p.code = _code; p.price = _price; for (i in 1.._substitutedProducts size()) CanBeSubstitutedBy.createLink(p1=>self,p2=>_substitutedProducts[i]); } } INPUT 2nd path CanBeSubstitutedBy.createLink (p1=>self, p2=>_substitutedProducts[i]) p.price = _price p.code = _code p = new Product() for 7/19 EXECUTION PATHS
- 14. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s 8/19 An operation is Strongly Executable ( SE ) iff all its execution paths are SE
- 15. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s 9/19
- 16. A P otentially V iolating A ction is an action that its effect can change the system state in a way that some integrity constraint becomes violated INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s 9/19 A path has no PVA s A path has some PVA s is SE may be not SE
- 17. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s A P otentially V iolating A ction 10/19 A path has no PVA s A path has some PVA s is SE may be not SE 2nd path EXECUTION PATHS CanBeSubstitutedBy.createLink (p1=>self, p2=>_substitutedProducts[i]) p.price = _price p.code = _code p = new Product() for
- 18. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s PVA A P otentially V iolating A ction 10/19 A path has no PVA s A path has some PVA s is SE may be not SE 2nd path EXECUTION PATHS CanBeSubstitutedBy.createLink (p1=>self, p2=>_substitutedProducts[i]) p.price = _price p.code = _code p = new Product() for
- 19. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s PVA PVA A P otentially V iolating A ction 10/19 A path has no PVA s A path has some PVA s is SE may be not SE 2nd path EXECUTION PATHS CanBeSubstitutedBy.createLink (p1=>self, p2=>_substitutedProducts[i]) p.price = _price p.code = _code p = new Product() for
- 20. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s PVA PVA PVA A P otentially V iolating A ction 10/19 A path has no PVA s A path has some PVA s is SE may be not SE 2nd path EXECUTION PATHS CanBeSubstitutedBy.createLink (p1=>self, p2=>_substitutedProducts[i]) p.price = _price p.code = _code p = new Product() for
- 21. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s MAY BE NOT STRONGLY EXECUTABLE PVA PVA PVA A P otentially V iolating A ction 10/19 A path has no PVA s A path has some PVA s is SE may be not SE 2nd path EXECUTION PATHS CanBeSubstitutedBy.createLink (p1=>self, p2=>_substitutedProducts[i]) p.price = _price p.code = _code p = new Product() for
- 22. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s 11/19
- 23. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s When a P VA may be discarded ? 11/19 A … 0..1 if ( A.allInstances() size()=0 ){ A a = new A(); } … Safe context … A a = new A(); … Critical context way 1 The path contains a guard that ensures the PVA will only be executed in a safe context
- 24. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s When a P VA may be discarded ? The path contains a guard that ensures the PVA will only be executed in a safe context The path contains another action which counters or complements the effect of the PVA in order to maintain the integrity of the system way 1 way 2 11/19 … a.destroy(); a = new A(); … Safe context … A a = new A(); … Critical context A … 0..1
- 25. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s When a P VA may be discarded ? The path contains a guard that ensures the PVA will only be executed in a safe context The path contains another action which counters or complements the effect of the PVA in order to maintain the integrity of the system way 1 way 2 11/19 All PVA s discarded NOT all PVA s discarded is SE is not SE
- 26. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s When a P VA may be discarded ? PVA discarded 12/19 All PVA s discarded NOT all PVA s discarded is SE is not SE PVA 2nd path EXECUTION PATHS CanBeSubstitutedBy.createLink (p1=>self, p2=>_substitutedProducts[i]) p.price = _price p.code = _code p = new Product() for PVA PVA
- 27. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s When a P VA may be discarded ? is NOT STRONGLY EXECUTABLE 12/19 All PVA s discarded NOT all PVA s discarded is SE is not SE PVA 2nd path EXECUTION PATHS CanBeSubstitutedBy.createLink (p1=>self, p2=>_substitutedProducts[i]) p.price = _price p.code = _code p = new Product() for PVA PVA discarded
- 28. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s Our method provides feedback to help designers identifying and repairing the detected errors 13/19
- 29. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s Our method provides feedback activity newProduct (in _code: String, in _price: Real, in _substitutedProducts: Products[0..*]) { if ( not Product.allInstances() exists(p|p.code=_code)) { Product p = new Product(); p.code = _code; p.price = _price; for (i in 1.._substitutedProducts size()) CanBeSubstitutedBy.createLink(p1=>self,p2=>_substitutedProducts[i]); CanBeSubstitutedBy.createLink(p1=>_substitutedProducts[i],p2=>self); } } } } OUTPUT 14/19 context Product inv productPrimaryKey : Product.allInstances() isUnique(code) avoids violating… when action is executed p.code = _code
- 30. INPUT OUTPUT Computing execution paths Analyzing PVA s Discarding PVA s Our method provides feedback activity newProduct (in _code: String, in _price: Real, in _substitutedProducts: Products[0..*]) { if ( not Product.allInstances() exists(p|p.code=_code)) { Product p = new Product(); p.code = _code; p.price = _price; for (i in 1.._substitutedProducts size()) CanBeSubstitutedBy.createLink(p1=>self,p2=>_substitutedProducts[i]); CanBeSubstitutedBy.createLink(p1=>_substitutedProducts[i],p2=>self); } } } } OUTPUT 14/19 context Product inv symmetricAssociation : self.p2.p2 includes(self) avoids violating… when action is executed CanBeSubstitutedBy.createLink (p1=>self, p2=>_substitutedProducts[i])
- 31. For concluding this presentation… relevant conclusions further work related work 15/19
- 32. related work 16/19 Work Behavioural Model Include Actions? Integrity Constraints supported? Checked Properties Technique Repairing Feedback? G. Gray et al. Transformation and Verification of Executable UML Models. Activity Diagram, Sequence Diagram, Statechart Diagram Yes None Consistency Model Checking No I. Abdelhalim et at. Formal Verification of Tokeneer Behaviours Modelled in fUML using CSP Activity Diagram Yes None Deadlocks Model Checking No D Latella et al. Automatic Verification of a Behavioural Subset UML Statechart Diagrams Using the SPIN Model Checker Statechart Diagram No None Safety Liveness Model Checking No J. Lilius et at. vUML: A Tool for Verifying UML Models Statechart Diagram No Associated to states Deadlocks Livelocks Model Checking No J. Cabot et al. Verifying UML/OCL Operation Contracts Declarative operations No All Strong Executability Constraint Pgoramming No A. Queralt et al. Reasoning on UML Conceptual Schemas with Operations Declarative operations No Subset Weak Executability Query Containment No Our work Imperative operations Yes Subset Strong Executability Static Analysis Yes
- 33. related work 16/19 Work Behavioural Model Include Actions? Integrity Constraints supported? Checked Properties Technique Repairing Feedback? G. Gray et al. Transformation and Verification of Executable UML Models. Activity Diagram, Sequence Diagram, Statechart Diagram Yes None Consistency Model Checking No I. Abdelhalim et at. Formal Verification of Tokeneer Behaviours Modelled in fUML using CSP Activity Diagram Yes None Deadlocks Model Checking No D Latella et al. Automatic Verification of a Behavioural Subset UML Statechart Diagrams Using the SPIN Model Checker Statechart Diagram No None Safety Liveness Model Checking No J. Lilius et at. vUML: A Tool for Verifying UML Models Statechart Diagram No Associated to states Deadlocks Livelocks Model Checking No J. Cabot et al. Verifying UML/OCL Operation Contracts Declarative operations No All Strong Executability Constraint Pgoramming No A. Queralt et al. Reasoning on UML Conceptual Schemas with Operations Declarative operations No Subset Weak Executability Query Containment No Our work Imperative operations Yes Subset Strong Executability Static Analysis Yes
- 34. related work 16/19 Work Behavioural Model Include Actions? Integrity Constraints supported? Checked Properties Technique Repairing Feedback? G. Gray et al. Transformation and Verification of Executable UML Models. Activity Diagram, Sequence Diagram, Statechart Diagram Yes None Consistency Model Checking No I. Abdelhalim et at. Formal Verification of Tokeneer Behaviours Modelled in fUML using CSP Activity Diagram Yes None Deadlocks Model Checking No D Latella et al. Automatic Verification of a Behavioural Subset UML Statechart Diagrams Using the SPIN Model Checker Statechart Diagram No None Safety Liveness Model Checking No J. Lilius et at. vUML: A Tool for Verifying UML Models Statechart Diagram No Associated to states Deadlocks Livelocks Model Checking No J. Cabot et al. Verifying UML/OCL Operation Contracts Declarative operations No All Strong Executability Constraint Pgoramming No A. Queralt et al. Reasoning on UML Conceptual Schemas with Operations Declarative operations No Subset Weak Executability Query Containment No Our work Imperative operations Yes Subset Strong Executability Static Analysis Yes
- 35. related work 16/19 Work Behavioural Model Include Actions? Integrity Constraints supported? Checked Properties Technique Repairing Feedback? G. Gray et al. Transformation and Verification of Executable UML Models. Activity Diagram, Sequence Diagram, Statechart Diagram Yes None Consistency Model Checking No I. Abdelhalim et at. Formal Verification of Tokeneer Behaviours Modelled in fUML using CSP Activity Diagram Yes None Deadlocks Model Checking No D Latella et al. Automatic Verification of a Behavioural Subset UML Statechart Diagrams Using the SPIN Model Checker Statechart Diagram No None Safety Liveness Model Checking No J. Lilius et at. vUML: A Tool for Verifying UML Models Statechart Diagram No Associated to states Deadlocks Livelocks Model Checking No J. Cabot et al. Verifying UML/OCL Operation Contracts Declarative operations No All Strong Executability Constraint Pgoramming No A. Queralt et al. Reasoning on UML Conceptual Schemas with Operations Declarative operations No Subset Weak Executability Query Containment No Our work Imperative operations Yes Subset Strong Executability Static Analysis Yes
- 36. relevant conclusions We have proposed a lightweight method for assisting the designer during the specification of Executable Models . Checking Strong Executability of action-based operations. Method features: efficiency and feedback . 17/19
- 37. further work Implement our method (we are working on it!) . Study the executability of operations when they are combined with other UML behavioural diagrams. Integrate our method in a more complete verification framework. 18/19
- 38. Elena Planas [email_address] Thanks for your attention!
Notas do Editor
- Good morning everybody. My name is Elena Planas and I will present a lightweight method for verifying UML Executable Models.
- Well, let me begin by explaining what an executable model is …
- An executable model is a model described in sufficient detail so that it can be automatically or semi automatically implemented or executed in the production environment.
- Executable models play a key role in the Model-Driven Development approach, in which models must be fine-grained specified in order to achieve an executable version of the system. In Model-Driven Development the quality of the final system implementation depends on the quality of the initial specification, so the existence of methods to verify the correctness of Executable Models is becoming crucial.
- On this direction, the GOAL of our work is to propose a verification method for Executable Models. Two outstanding FEATURES of our method are: Firstly, it is a lightweight method : That is, in order to improve its efficiency, our method performs an static analysis without any need to execute the model. And, secondly, it returns meaningful feedback : If the checked property is not satisfied, the method returns feedback suggesting possible corrections to repair the detected errors. The presented work is only FOCUSED on UML action-based operations specified in Alf Action Language, which is a beta standard Action Language published recently by the OMG. On this work, we focus on a fundamental correctness property that we call Strong Executability.
- So, what does this property mean? We consider that an operation is Strongly Executable if it is always successfully executed, that is, the operation’s execution generates a state consistent with all structural integrity constraints. We consider this is one of the most fundamental correctness properties for behavioural models. When we know that all operations are Strongly Executable, we can avoid checking at the end of each operation execution if all constraints are satisfied which improves the efficiency of the system. As an example , consider the following Executable Model: In the left we show the structural model , which contains information about products. Each product has a code and a price and may have several substituted products. Additional constraints are expressed in OCL language: first constraint expresses the attribute code is primary key of the product. And the second constraint expresses the recursive association can be substituted by is symmetric. - In the right we show the behavioural model , which consists on a single operation for creating a new product on the system. This operation is specified by means of Alf Action Language, which is a language comparable to any traditional programming language but at a higher abstraction level. The operation contains several actions: first action declares and creates a new product in the system. second and third actions initialize its attributes code and price. and the last action , which will only be executed when the new product has some substituted products, creates a link between the created product and its substituted products. As we will see later, after executing this operation, several constraints of the structural model may become violated. For instance, before executing the operation, there may already exist other product with the same code. Therefore, this operation is not strongly executable.
- In order to determine if an operation is Strongly Executable we proceed by applying a three-step verification method . Let’s see how this method works step by step using as example the operation “new product”.
- FIRST STEP of our method consists in computing the execution paths for the input operation we want to verify.
- An execution path of an operation is a consecutive sequence of actions that may be followed during its execution in a given execution scenario. For trivial operations, with neither conditional or loop structures, there is a single execution path but, in general, several ones will exist.
- In order to compute the execution paths, we propose to represent each operation as a directed graph . Then, execution paths are all paths in the graph that start at the initial vertex, end at the final vertex and does not include repeated arcs.
- As an example, this figure shows the directed graph of the operation “new product”. Two execution paths may be derived from this graph:
- the first path , executed when the new product has no substituted products (that is, when the loop is not executed).
- and the second path , executed otherwise.
- Given that an operation is strongly executable if and only if all its execution paths are strongly executable, the rest of the method is applied on each path.
- SECOND STEP of our method consists on analyze individually each action in the path to see if it may violate some integrity constraint of the structural model.
- There are actions that its effect can change the system state in a way that some integrity constraint of the structural model becomes violated. These actions are declared as Potentially Violating Actions ( abbreviated PVA ). If the path has no PVAs, it is Strongly Executable. Otherwise, it may be not Strongly Executable so we need to continue the analysis with the next step.
- As an example, consider the second path of our operation “new product” (first path is a subset of this one).
- First action in the path may violate two integrity constraints. In particular, the structural model determines that the attributes code and price must have at least one value. So, we may violate this constraints when, after creating the new product, we do not assign any value to these attributes.
- Second action in the path may violate an integrity constraint. In particular, there is an OCL constraint which determines that the code of a product is primary key of class Product. So, we may violate this constraint when we assign to the new product the same code of another existing product.
- Last action in the path also may violate an integrity constraint. In particular, there is an OCL constraint which determines that the association Can Be Substituted By is symmetric. So, we may violate this constraint when we do not create the symmetric link, that is, when we relate a product with another product but we do not relate the second product with the first one.
- Given that our path contains three Potentially Violating Actions, our method determines that this path may be not Strongly Executable. But it may happen that the context in which a Potentially Violating Action is executed within the path guarantees that its effect is never going to actually violate any integrity constraint of the structural model.
- LAST STEP of our method performs a contextual analysis of each Potentially Violating Action returned by the previous step and tries to discard them.
- So, when a PVA may be discarded ? Roughly, there are two ways to discard a PVA: First way is when the path contains a guard (that is, a conditional structure) that ensures the Potentially Violating Action will only be executed in a safe context . For instance, suppose a class A that may only have at most one instance. Suppose an action that creates a new instance of A. This is a critical context given that after executing this action we may violate the maximum cardinality of the class A. Now suppose the same action executed after checking there are no instances of class A. This is a safe context given that the conditional structure ensures that the action will only be executed when the constraint will not be violated.
- Second way is when the path contains another action which counters or complements the effect of the Potentially Violating Action in order to maintain the integrity of the system. For instance, consider the same class as before. As we have seen, the left scenario is critical, since we may violate the maximum cardinality of the class A. Now suppose the same action executed after destroying another instance of the class A. This context is a safe context given that the previous destroying complements the effect of the creation in order to maintain the required number of instances.
- If all Potentially Violating Actions can be discarded, the path is classified as Strongly Executable. If not, the path (and consequently the operation) is marked as non-Strongly Executable and the corresponding corrective feedback is provided.
- Taking back our example, remember the integrity constraints that may be violated by the first Potentially Violating Action: In the context of this path, we may guarantee that both constraints will never become violated given that the path contains several actions (in particular the second and third actions on the path) to counter the effect of the Potentially Violating Action. Therefore, the first Potentially Violating Action may be discarded.
- Given that two Potentially Violating Actions may not be discarded, our method determines that this path (and consequently this operation) is not Strongly Executable.
- As a result , our method provides corrective feedback to help designer identifying and repairing the detected inconsistencies.
- Here we show the repaired operation new product once the feedback provided by our method has been integrated . The conditional structure avoids violating the primary key of Product when the code of a product is initialized.
- Otherwise, the new creation of a link avoids violating the symmetric constraint when a link of the symmetric association is created.
- For concluding this presentation, I will summarize a brief related work , the relevant points of our work and further research lines .
- This table classifies the most representative works related with verification of UML behavioural models and positions our method ( at the bottom) with respect to them. I will not explain each work, only comment some relevant points:
- First, we can see that only few works allow inclusion of actions on their diagrams, which is precisely the focus of our method.
- Besides, all works simulate the behaviour using methods as Model Checking, compromising the efficiency of the method.
- Finally, most of the related works do not provide a valuable feedback but just provide a binary response and, at most some provide example execution traces that do not satisfy the checked property. None clearly identify the source of the problems nor assist the designer to repair them.
- As remarkable conclusions … We have proposed a lightweight method for assisting the designer during the specification of Executable Models. In particular, our method verifies the Strong Executability of action-based UML operations with respect to the integrity constraints imposed by the structural model. The main characteristics of our method are its efficiency (since it performs an static analysis without any need to simulate the behaviour of the model) and its feedback (for non-executable operations, it is able to identify the source of the inconsistency and suggest possible corrections). For these reasons, our method is easy to integrate in existing CASE tools .
- As a further work … We are implementing our method as an Eclipse plug-in. We also plan to study the executability of operations when they are combined with other UML behavioural diagrams . And, finally, we also plan to integrate our method in a more complete verification framework that could help designers choose the most appropriate verification technique for the model they have defined, depending on the target property and the verification trade-offs they are ready to accept (for instance, the efficiency of the method, and so on).
- So, that’s concludes my presentation. Thank you very much for your attention!