A Framework for Verifying UML Behavioral Models (CAiSE Doctoral Consortium 2009)

426 views

Published on

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
426
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • The index of this presentation is the following: - First, by way of introduction we will see the context and the motivation of the problem that we address. - Then, I will present an overview the framework proposed in this thesis proposal. - Finally, we will see some related works and the conclusions.
  • Let me begin by explaining the context where this thesis proposal is locate. The life cycle of software system has several phases with its particular artifacts. For example, in specification and design phases, the artifacts obtained are models (that represent both structural and behavioral part of the system), while in implementation phase, the artifact obtained is executable code of the system. Some years ago, the focus of software verification was on code but now, giving the increasingly acceptance of MDD (Model Driven Development) and MDA (Model Driven Architecture) approaches, where models are the primary artifact of the development process, the verification has been focused each time on a higher level (more close to models than to code). Models, specifically behavioral models, are also the focus of this thesis proposal.
  • As we have seen, one of the goals of Model Driven Development ( MDD ) approach is to generate executable code from a model specification. To achieve this goal, we must to represent the semantic of models in sufficient detail and precision . Particularly, in UML behavioral models, we must to represent the behavior of the system in sufficient accuracy. In order to achieve this purpose, UML include Action Semantics , which is the fundamental unit of behavior specifications. Actions are the basis for defining the fine-grained behavior of behavioral models (operations, activity diagrams, interaction diagrams and state machines). Actions enable to modify the system state through basic modifications (insert/update/delete) on the system elements (classes, associations and so on). Here, we show the main modification actions included in UML ( CreateObject , DestroyObject , AddStructuralFeature , CreateLink , DestroyLink , ReclassifyObject and CallOperation ). These actions can be accompanied with several read actions (e.g. to access the values of attributes and links of the objects) and can be structured to coordinate basic actions in action sequences, conditional blocks or loops to completely define the effect of behavioral specifications. These actions may be part of simple behavioral specifications (as operations attached into classes) or part of more complex specifications (as activity diagrams, interaction diagrams and state machines). For the sake of simplicity, in this presentation we only show actions as part of operations. For example…
  • Consider this class diagram that describes the objects within a system (people and departments) and their relationships (person works in a department). The system behavior is defined by means of two operations specified with Action Semantics. First operation ( changeAddress ) is incorrect, since it tries to update an attribute ( address ) which does not even exist in the class diagram. Second operation ( addPerson ) is also incorrect, since it can never be successfully executed because every time we try to execute the operation, the new system state violates the minimum ‘1’ cardinality constraint of the department role in WorksIn , given that the created person instance p is not linked to any department. If these errors are not fixed before continuing with the code-generation phase, the resulting system implementation will be totally useless.
  • Consider this class diagram that describes the objects within a system (people and departments) and their relationships (person works in a department). The system behavior is defined by means of two operations specified with Action Semantics. First operation ( changeAddress ) is incorrect, since it tries to update an attribute ( address ) which does not even exist in the class diagram. Second operation ( addPerson ) is also incorrect, since it can never be successfully executed because every time we try to execute the operation, the new system state violates the minimum ‘1’ cardinality constraint of the department role in WorksIn , given that the created person instance p is not linked to any department. If these errors are not fixed before continuing with the code-generation phase, the resulting system implementation will be totally useless.
  • Consider this class diagram that describes the objects within a system (people and departments) and their relationships (person works in a department). The system behavior is defined by means of two operations specified with Action Semantics. First operation ( changeAddress ) is incorrect, since it tries to update an attribute ( address ) which does not even exist in the class diagram. Second operation ( addPerson ) is also incorrect, since it can never be successfully executed because every time we try to execute the operation, the new system state violates the minimum ‘1’ cardinality constraint of the department role in WorksIn , given that the created person instance p is not linked to any department. If these errors are not fixed before continuing with the code-generation phase, the resulting system implementation will be totally useless.
  • Consider this class diagram that describes the objects within a system (people and departments) and their relationships (person works in a department). The system behavior is defined by means of two operations specified with Action Semantics. First operation ( changeAddress ) is incorrect, since it tries to update an attribute ( address ) which does not even exist in the class diagram. Second operation ( addPerson ) is also incorrect, since it can never be successfully executed because every time we try to execute the operation, the new system state violates the minimum ‘1’ cardinality constraint of the department role in WorksIn , given that the created person instance p is not linked to any department. If these errors are not fixed before continuing with the code-generation phase, the resulting system implementation will be totally useless.
  • Let's now move to the description of the framework that we purpose. The main goal of this PhD is to provide a verification framework to help the designers to verify the correctness of their behavioral models , mainly focused on the analysis of the modification actions included in the specification of those models and on how this analysis can complement other existing verification approaches. The following figure shows the overview of the framework that we propose: - Given an input behavioral model provided by the designer, first, several correctness properties can be checked by a static model verifier . In case of an error, the verifier returns a meaningful feedback that helps repairing the possible inconsistencies. This first correctness analysis is basic to ensure a fundamental quality level in action specifications. - After this initial analysis, some properties may be also deal adapting current verifying approaches as Model Checking . This later analysis is more detailed but returns less useful feedback. The framework presented in this thesis proposal can be outline in the following sub-goals…
  • Identify and describe several fundamental correctness properties of action-based behavioral specifications: Syntactic Correctness, Executability, Completeness and Redundancy.
  • Develop a static model verifier composed by a set of efficient techniques to verify the previous properties. Each of our techniques is focused on the verification of a particular correctness property. This set of techniques works at model level and performs a static analysis (do not require a simulation of the model). These techniques must take into account the interactions between actions and the rest of the elements of the diagram where they are included (state machines, activity diagrams or interaction diagrams).
  • Integrate our static techniques with other existing verification approaches as MC. As we have seen, our static techniques may be complemented with existing verification approaches, for instance, those based on Model Checking. In particular, model checking techniques could be useful to get a more fine-grained analysis once our first static analysis has determined that the specification is minimally correct.
  • Provide useful feedback to the designer. The success of the application of formal techniques lies in providing the user with an understandable feedback (e.g. the feedback must be expressed in the same language used to model the behavior).
  • The input of our verification techniques is an action-based behavioral specification that may include several UML actions and the corresponding Class Diagram. We plan to deal with actions included in several behavioral specifications, from basic operations to complex diagrams as activity diagrams, interaction diagrams and state machines.
  • As we have seen, the framework proposed uses two types of verification techniques: 1. Static techniques These techniques are characterized for doing a static analysis, that is, do not require a simulation of the model. Another characteristic is the meaningful feedback that they provide, that helps repairing the possible inconsistencies. These techniques are useful to do a basic correctness analysis fundamental to ensure an elemental quality level in action specifications. 2. Model Checking These static techniques may be complemented with existing verification approaches as Model Checking. A Model Checking analysis of an action-based behavioral specification requires translating this specification into an input language that can be understood by current Model Checking techniques. Roughly, model checkers work by generating and analyzing all the potential executions at run-time and evaluating if, for each (or some) execution, a given property is satisfied. Model Checking techniques, unlike the static techniques, suffer from the state-explosion problem (i.e. the number of potential executions to analyze grows exponentially in terms of the size of the model, the domains of the parameters,…) even though a number of optimizations are available. Model checking techniques aims to verify only properties expressed in LTL (Linear Temporal Logic formula). Some of our properties, for example the syntactic correctness, cannot be represented as LTL formula. A significant difference between model checking techniques and the static techniques that we propose is its output. Model checking based proposals provide example execution traces that do (not) satisfy the checked property. On the other side, our static techniques suggest how to change the operation specification in order to repair the detected inconsistency. Given its characteristics, model checking techniques could be useful to get a more fine-grained analysis once the first static analysis has determined that the specification is minimally correct.
  • In the next slides, I'm going to give a brief overview of the correctness properties that we address: The first property that we plan to verify is the Syntactic Correctness. Concerning UML models, syntactical correctness ensures that a specification conforms to the abstract syntax specified by the UML metamodel (similar to the grammar of programming languages). Syntactical consistency conditions are expressed in UML metamodel using a set of constraints expressed in OCL language, called Well-Formedness Rules. The WFRs restrict the possible set of valid UML models and help to prevent syntactic errors in action specifications. We say that an action-based behavior specification is syntactically correct when all actions conform to these WFR.
  • For instance, suppose an abstract class and an action that creates a new object instance of this class. This action is not syntactically correct due to, as specify this WFR, we cannot create an instance of an abstract class. However, the second action is syntactically correct, due to we can create an instance of a concrete class.
  • The second property that we plan to verify is the Executability. We consider that an action-based behavior specification is (weakly) executable when there is a chance that a user may successfully execute the behavior, that is, when there is at least an initial system state for which the execution of the actions included in the behavior evolves this state to a new system state that satisfies all integrity constraints of the model. Otherwise, the behavior is completely useless. We define our executability property as weak executability since we do not require all executions of the behavior to be successful, which could be defined as strong executability.
  • I'll take an example to illustrate this property. Suppose the previous class diagram and the operation dismiss, that deletes the WorksIn link between a person and his/her department. This operation is not-weakly-executable since, every time we try to execute it, the new system state violates the minimum ‘1’ cardinality constraint of the department role in WorksIn , because the person instance p is not linked to any department. In order to repair the operation, we need – for example - assign a new department to the person within the same operation execution.
  • I'll take an example to illustrate this property. Suppose the previous class diagram and the operation dismiss, that deletes the WorksIn link between a person and his/her department. This operation is not-weakly-executable since, every time we try to execute it, the new system state violates the minimum ‘1’ cardinality constraint of the department role in WorksIn , because the person instance p is not linked to any department. In order to repair the operation, we need – for example - assign a new department to the person within the same operation execution.
  • The third property that we address is the Completeness. We consider that a set of action-based behavior specifications is complete when all possible changes on all parts of the system state can be performed through the execution of this set of behaviors. Otherwise, there will be parts of the system that users will not be able to modify since no available behavior specifications address their modification.
  • For instance, in the operations context, consider this class diagram and the set composed by three operations is not complete, since through these operations users cannot modify all elements of the class diagram, for instance, it is not possible to create/destroy departments.
  • The last property that we define is the Redundancy. We consider that an action (or set of actions) in an action-based behavior specification is redundant if its effect on the system state is subsumed by the effect of later actions in the same action-based behavior specification, that is, the final system state when executing the behavior would be exactly the same with or without the redundant action.
  • For instance, in the following operation ( addPerson ), that creates a new Person in the system, we can see that the first action is redundant, since the second update overrides the first one.
  • For concluding the description of the framework proposed I’d like to remark some important points. About the limitations of static verification, in this type of analysis we do not check conditions of conditional structures or loops and, in general, we do not address the possible values of arguments in its executions. Regarding the scope, we are focused on actions included mainly in UML behavioral specifications, but the idea may be applied in other contexts as BPM diagrams.
  • Now I will explain briefly the related work with this thesis proposal. Regarding the verification of UML behavioral models, most of relevant works have common characteristics: Most of them ignore the actions included in behavioral models, which is exactly the focus of our approach. Most of them use model checking techniques for performing the verification. Most of them address very basic properties expressed as LTL. The feedback provided by model checking techniques does not help the designer to repair his models.
  • For concluding this presentation, I will summarize the relevant points of my thesis proposal: Our goal is develop a framework for the verification of correctness properties of UML behavioral models, extensible to other kinds of behavioral specifications (BPM). Our framework is focused on action semantics verification. A relevant characteristic of our framework is that provides a meaningful feedback to the user.
  • A Framework for Verifying UML Behavioral Models (CAiSE Doctoral Consortium 2009)

    1. 1. Doctoral Consortium CAiSE’09 10th June 2009 Amsterdam A Framework for V erifying UML B ehavioral M odels Elena Planas [email_address] Open University of Catalonia
    2. 2. A Framework for Verifying UML Behavioral Models <ul><li>Introduction </li></ul><ul><li>Thesis Proposal </li></ul><ul><li>Related Work </li></ul><ul><li>Conclusions </li></ul>Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam I ndex 1
    3. 3. Life cycle of software Introduction Thesis Proposal Related Work Conclusions > Context > Motivation Model Driven Development A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 2 specification design implementation testing Code before UML Model Structural model Behavioral model now thesis proposal
    4. 4. Code Generation > Context > Motivation Introduction Thesis Proposal Related Work Conclusions A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 3 Code UML Behavioral Model We need define UML model in sufficient detail and precision subset of UML Actions CreateObject DestroyObject AddStructuralFeature CreateLink DestroyLink ReclassifyObject CallOperation UML Structured Actions if… then… else… endif while... do… endwhile do… while… enddo A ction S emantics Action = fundamental unit of behavior specification Basis for defining the behavior in a fine granularity
    5. 5. E xample > Context > Motivation Introduction Thesis Proposal Related Work Conclusions A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 4 Person name : String email : String Department name : String WorksIn 1 * context Person:: addPerson (n:String, e:String) { p: Person; p := CreateObject(Person); AddStructuralFeature(p,name,n); AddStructuralFeature(p,email,e); } context Person:: changeAddress (a:String) { AddStructuralFeature(self,address,a); }
    6. 6. E xample > Context > Motivation Introduction Thesis Proposal Related Work Conclusions A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 4 Person name : String email : String Department name : String WorksIn 1 * context Person:: addPerson (n:String, e:String) { p: Person; p := CreateObject(Person); AddStructuralFeature(p,name,n); AddStructuralFeature(p,email,e); } context Person:: changeAddress (a:String) { AddStructuralFeature(self,address,a); } NOT SYNTACTICALLY CORRECT
    7. 7. E xample > Context > Motivation Introduction Thesis Proposal Related Work Conclusions A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 4 Person name : String email : String Department name : String WorksIn 1 * context Person:: changeAddress (a:String) { AddStructuralFeature(self,adress,a); } NOT EXECUTABLE context Person:: addPerson (n:String, e:String) { p: Person; p := CreateObject(Person); AddStructuralFeature(p,name,n); AddStructuralFeature(p,email,e); }
    8. 8. E xample > Context > Motivation Introduction Thesis Proposal Related Work Conclusions NOT COMPLETE A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 4 Person name : String email : String Department name : String WorksIn 1 * context Person:: addPerson (n:String, e:String) { p: Person; p := CreateObject(Person); AddStructuralFeature(p,name,n); AddStructuralFeature(p,email,e); } context Person:: changeAddress (a:String) { AddStructuralFeature(self,adress,a); }
    9. 9. Provide a verification framework to help the designers to verify the correctness of their behavioral models (based in Actions) G oal > Goals > Framework description > Important issues Introduction Thesis Proposal Related Work Conclusions A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 5
    10. 10. S ub-Goals Identify and describe correctness properties: - Syntactic correctness - Executability - Completeness - Redundancy 1 > Goals > Framework description > Important issues Introduction Thesis Proposal Related Work Conclusions A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 6
    11. 11. S ub-Goals Develop a static (do not require simulation of the model) model verifier composed by a set of efficient techniques to verify the previous properties 2 > Goals > Framework description > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 7 Introduction Thesis Proposal Related Work Conclusions
    12. 12. S ub-Goals Integrate the previous static techniques with other existing verification approaches (Model Checking) 3 > Goals > Framework description > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 8 Introduction Thesis Proposal Related Work Conclusions
    13. 13. S ub-Goals Provide useful feedback to the designer 4 > Goals > Framework description > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 9 Introduction Thesis Proposal Related Work Conclusions
    14. 14. I nput UML Class Diagram Operations Activity Diagrams Interaction Diagrams State Machines Behavioral Specification (Action Semantics) > Goals > Framework description: Input > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 10 Introduction Thesis Proposal Related Work Conclusions
    15. 15. V erification techniques used > Goals > Framework description: Techniques > Important issues Static techniques Static analysis Output: Corrective feedback First correctness analysis A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 11 specification design implementation testing Introduction Thesis Proposal Related Work Conclusions Model Checking Translation: State Explosion Problem LTL properties Output: Error trace More detailed analysis UML Model MC language
    16. 16. S yntactic Correctness A behavioral specification described using actions is syntactically correct when all the actions included in it satisfy the WFR WFR ( W ell F ormedness R ule) = Constraint that restrict the possible set of valid UML models. > Goals > Framework description: Properties > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 12 Introduction Thesis Proposal Related Work Conclusions
    17. 17. S yntactic Correctness: Example WFR: The classifier cannot be abstract context CreateObject inv: not (self.classifier.isAbstract = #true) obj2 := CreateObject(ConcreteClass); obj1 := CreateObject(AbstractClass); > Goals > Framework description: Properties > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 13 Introduction Thesis Proposal Related Work Conclusions AbstractClass ConcreteClass
    18. 18. E xecutability A behavioral specification described using actions is executable when there is a chance that a user may successfully execute it Weak Executability  at least one sucessful execution of the behavior Strong Executability  all successful executions of the behavior > Goals > Framework description: Properties > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 14 Introduction Thesis Proposal Related Work Conclusions
    19. 19. E xecutability: Example context Person:: addPerson (n:String, e:String) { p: Person; p := CreateObject(Person); AddStructuralFeature(p,name,n); AddStructuralFeature(p,email,e); } > Goals > Framework description: Properties > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 15 Introduction Thesis Proposal Related Work Conclusions FEEDBACK : Add a CreateLink Person name : String email : String Department name : String WorksIn 1 * not executable
    20. 20. E xecutability: Example > Goals > Framework description: Properties > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 15 context Person:: addPerson (n:String, e:String, d:Department ) { p: Person; p := CreateObject(Person); AddStructuralFeature(p,name,n); AddStructuralFeature(p,email,e); CreateLink(WorksIn, person, self, department, d); } Introduction Thesis Proposal Related Work Conclusions FEEDBACK : Add a CreateLink Person name : String email : String Department name : String WorksIn 1 * executable
    21. 21. C ompleteness A set of behavioral specifications described using actions is complete when all possible changes (inserts/updates/deletes) on all parts of the system state can be performed throught the execution of this set of behaviors > Goals > Framework description: Properties > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 16 Introduction Thesis Proposal Related Work Conclusions
    22. 22. C ompleteness: Example > Goals > Framework description: Properties > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 17 context Person:: addPerson (n:String, e:String, d:Department) { p: Person; p := CreateObject(Person); AddStructuralFeature(p,name,n); AddStructuralFeature(p,email,e); CreateLink(WorksIn, person, self, department, d); } Introduction Thesis Proposal Related Work Conclusions FEEDBACK : Add actions to create/destroy departments … Person name : String email : String Department name : String WorksIn 1 * not complete
    23. 23. R edundancy An action (or set of actions) in an behavioral specification is redundant if its effect on the system state is subsumed by the effect of later actions in the same behavioral specification > Goals > Framework description: Properties > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 18 Introduction Thesis Proposal Related Work Conclusions
    24. 24. R edundancy: Example > Goals > Framework description: Properties > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 19 Introduction Thesis Proposal Related Work Conclusions FEEDBACK : Remove the first update context Person:: changeName (name1:String, name2:String) { AddStructuralFeature(self,name,name1); AddStructuralFeature(self,name,name2); } Redundancy : The second update overwrites the first one redundant action
    25. 25. I mportant issues > Goals > Framework description: Properties > Important issues A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 20 Introduction Thesis Proposal Related Work Conclusions scope Action based UML behavioral specifications extension Aplicable to BPM diagrams limitations Our static verification do not check conditions
    26. 26. R elated work UML Model Behavioral model <ul><li>Most of related works: </li></ul><ul><li>Use Model Checking techniques </li></ul><ul><li>Ignore the actions included </li></ul><ul><li>Verify LTL properties </li></ul><ul><li>Not meaningful feedback </li></ul>A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 21 Introduction Thesis Proposal Related Work Conclusions
    27. 27. C onclusions Framework for the verification of the correctnes of UML behavioral models Extensible to other kinds of behavioral specifications Focused on Actions Valuable feedback ▪ ▪ ▪ ▪ A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 22 Introduction Thesis Proposal Related Work Conclusions
    28. 28. Doctoral Consortium CAiSE’09 10th June 2009 Amsterdam T hanks for your attention! Elena Planas [email_address] A Framewrok for Verifying UML Behavioral Models

    ×