The document discusses a method for verifying correctness properties of action semantics specifications in UML behavioral models. The method performs a static analysis to check for syntactic correctness, executability, and completeness. Syntactic correctness ensures actions conform to well-formedness rules. Executability checks if operations can be successfully executed to evolve system states. Completeness determines if all possible execution paths are specified.

1. The 21st International Conference on Advanced Information Systems CAiSE’09 12nd June 2009 Amsterdam Verifying A ction S emantics Specifications in UML Behavioral Models Elena Planas 1 Jordi Cabot 1 Cristina Gómez 2 1 Open University of Catalonia 2 Technical University of Catalonia

3. Introduction Our method Related Work Conclusions > Context > Motivation > Goal Life cycle of software systems Model Driven Development Verifying Action Semantics Specifications in UML Behavioral Models 2 CAiSE’09 – 8-12 June 2009, Amsterdam specification design implementation testing Code before UML Model Structural model Behavioral model now our work

4. Introduction Our method Related Work Conclusions > Context > Motivation > Goal E xample Verifying Action Semantics Specifications in UML Behavioral Models 3 CAiSE’09 – 8-12 June 2009, Amsterdam 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); }

5. Introduction Our method Related Work Conclusions > Context > Motivation > Goal E xample Verifying Action Semantics Specifications in UML Behavioral Models 3 CAiSE’09 – 8-12 June 2009, Amsterdam 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

6. Introduction Our method Related Work Conclusions > Context > Motivation > Goal E xample Verifying Action Semantics Specifications in UML Behavioral Models 3 CAiSE’09 – 8-12 June 2009, Amsterdam Person name : String email : String Department name : String WorksIn 1 * context Person:: changeAddress (a:String) { AddStructuralFeature(self,address,a); } context Person:: addPerson (n:String, e:String) { p: Person; p := CreateObject(Person); AddStructuralFeature(p,name,n); AddStructuralFeature(p,email,e); } NOT EXECUTABLE

7. Introduction Our method Related Work Conclusions > Context > Motivation > Goal E xample NOT COMPLETE Verifying Action Semantics Specifications in UML Behavioral Models 3 CAiSE’09 – 8-12 June 2009, Amsterdam 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); }

8. Introduction Our method Related Work Conclusions > Context > Motivation > Goal Provide a set of lightweight techniques for the verification of correctness properties of Action Semantics specifications at design time G oal Verifying Action Semantics Specifications in UML Behavioral Models 4 CAiSE’09 – 8-12 June 2009, Amsterdam specification design implementation testing

10. Introduction Our method Related Work Conclusions > Overview > Input > Properties I nput Verifying Action Semantics Specifications in UML Behavioral Models 6 CAiSE’09 – 8-12 June 2009, Amsterdam

11. Introduction Our method Related Work Conclusions > Overview > Input > Properties Class Diagram Operations I nput Verifying Action Semantics Specifications in UML Behavioral Models 7 CAiSE’09 – 8-12 June 2009, Amsterdam * Operation UML Action 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

12. Introduction Our method Related Work Conclusions > Overview > Input > Properties A ction Semantics Example context Paper:: endOfReview (com:String,d:Date, evaluation:String) { if self.oclIsTypeOf(UnderReview) then if evaluation = ’reject’ then ReclassifyObject(self,[Rejected],[ ]); AddStructuralFeature(self,comments,com); else ReclassifyObject(self,[Accepted],[ ]); AddStructuralFeature(self,accepDate,d); endif endif } context Person:: dismiss () { DestroyLink(WorksIn, person, self, department, self.department); } Verifying Action Semantics Specifications in UML Behavioral Models 8 CAiSE’09 – 8-12 June 2009, Amsterdam Person name : String { readOnly } email : String Paper title : String Rejected comments : String Accepted accepDate : D ate Under Review IsAuthorOf author 1..* * WorksIn 1 * {disjoint,complete} Department name : String

13. Introduction Our method Related Work Conclusions > Overview > Input > Properties C orrectness Properties Verifying Action Semantics Specifications in UML Behavioral Models 9 CAiSE’09 – 8-12 June 2009, Amsterdam

14. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Syntactic Correctness S yntactic Correctness Verifying Action Semantics Specifications in UML Behavioral Models 10 CAiSE’09 – 8-12 June 2009, Amsterdam

15. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Syntactic Correctness An operation is syntactically correct when all the actions included in its specification satisfy the WFR . S yntactic Correctness WFR ( W ell F ormedness R ule) = Constraint that restrict the possible set of valid UML models. Verifying Action Semantics Specifications in UML Behavioral Models 11 CAiSE’09 – 8-12 June 2009, Amsterdam

16. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Syntactic Correctness N ew WFR proposed context WriteStructuralFeatureAction inv: self.value.type = self.structuralFeature.type … r := CreateObject(Rejected); Verifying Action Semantics Specifications in UML Behavioral Models 12 CAiSE’09 – 8-12 June 2009, Amsterdam WriteStructuralFeature(r,name, 17 ); WriteStructuralFeature(r,name, ”Peter” ); Person name : String email : String Department name : String WorksIn 1 *

17. Introduction Our method Related Work Conclusions > Overview > Input > Properties E xecution Paths Computing the execution paths is necessary to check the next correctness properties (executability and completeness). Verifying Action Semantics Specifications in UML Behavioral Models 13 CAiSE’09 – 8-12 June 2009, Amsterdam

18. Introduction Our method Related Work Conclusions > Overview > Input > Properties E xecution Paths An execution path is a sequence of actions that may be followed during an operation execution. In general, an operation have several execution paths (one for each conditional or loop case). Verifying Action Semantics Specifications in UML Behavioral Models 14 CAiSE’09 – 8-12 June 2009, Amsterdam

19. Introduction Our method Related Work Conclusions > Overview > Input > Properties E xecution Paths: endOfReview operation context Paper:: endOfReview (com:String,d:Date, evaluation:String) { if self.oclIsTypeOf(UnderReview) then if evaluation = ’reject’ then ReclassifyObject(self,[Rejected],[ ]); AddStructuralFeature(self,comments,com); else ReclassifyObject(self,[Accepted],[ ]); AddStructuralFeature(self,accepDate,d); endif endif } Verifying Action Semantics Specifications in UML Behavioral Models 15 CAiSE’09 – 8-12 June 2009, Amsterdam

20. Introduction Our method Related Work Conclusions > Overview > Input > Properties E xecution Paths: endOfReview operation ReclassifyObject (self,[Rejected],[ ]) ReclassifyObject (self,[Accepted],[ ]) AddStructuralFeature (self,comments,com) AddStructuralFeature (self,accepDate,d) context Paper:: endOfReview (com:String,d:Date, evaluation:String) { if self.oclIsTypeOf(UnderReview) then if evaluation = ’reject’ then ReclassifyObject(self,[Rejected],[ ]); AddStructuralFeature(self,comments,com); else ReclassifyObject(self,[Accepted],[ ]); AddStructuralFeature(self,accepDate,d); endif endif } Action Vertex Verifying Action Semantics Specifications in UML Behavioral Models 15 CAiSE’09 – 8-12 June 2009, Amsterdam

21. Introduction Our method Related Work Conclusions > Overview > Input > Properties E xecution Paths: endOfReview operation if ReclassifyObject (self,[Rejected],[ ]) ReclassifyObject (self,[Accepted],[ ]) AddStructuralFeature (self,comments,com) AddStructuralFeature (self,accepDate,d) if context Paper:: endOfReview (com:String,d:Date, evaluation:String) { if self.oclIsTypeOf(UnderReview) then if evaluation = ’reject’ then ReclassifyObject(self,[Rejected],[ ]); AddStructuralFeature(self,comments,com); else ReclassifyObject(self,[Accepted],[ ]); AddStructuralFeature(self,accepDate,d); endif endif } Conditional node Branch Verifying Action Semantics Specifications in UML Behavioral Models 15 CAiSE’09 – 8-12 June 2009, Amsterdam

22. Introduction Our method Related Work Conclusions > Overview > Input > Properties E xecution Paths: endOfReview operation if ReclassifyObject (self,[Rejected],[ ]) ReclassifyObject (self,[Accepted],[ ]) AddStructuralFeature (self,comments,com) AddStructuralFeature (self,accepDate,d) if context Paper:: endOfReview (com:String,d:Date, evaluation:String) { if self.oclIsTypeOf(UnderReview) then if evaluation = ’reject’ then ReclassifyObject(self,[Rejected],[ ]); AddStructuralFeature(self,comments,com); else ReclassifyObject(self,[Accepted],[ ]); AddStructuralFeature(self,accepDate,d); endif endif } Ordered sequence of actions Arc Verifying Action Semantics Specifications in UML Behavioral Models 15 CAiSE’09 – 8-12 June 2009, Amsterdam

23. Introduction Our method Related Work Conclusions > Overview > Input > Properties E xecution Paths: endOfReview operation context Paper:: endOfReview (com:String,d:Date, evaluation:String) { if self.oclIsTypeOf(UnderReview) then if evaluation = ’reject’ then ReclassifyObject(self,[Rejected],[ ]); AddStructuralFeature(self,comments,com); else ReclassifyObject(self,[Accepted],[ ]); AddStructuralFeature(self,accepDate,d); endif endif } Initial Node Final Node Verifying Action Semantics Specifications in UML Behavioral Models 15 CAiSE’09 – 8-12 June 2009, Amsterdam if ReclassifyObject (self,[Rejected],[ ]) ReclassifyObject (self,[Accepted],[ ]) AddStructuralFeature (self,comments,com) AddStructuralFeature (self,accepDate,d) if

24. Introduction Our method Related Work Conclusions > Overview > Input > Properties E xecution Paths: endOfReview operation p 1 = { } Verifying Action Semantics Specifications in UML Behavioral Models 15 CAiSE’09 – 8-12 June 2009, Amsterdam if ReclassifyObject (self,[Rejected],[ ]) ReclassifyObject (self,[Accepted],[ ]) AddStructuralFeature (self,comments,com) AddStructuralFeature (self,accepDate,d) if

25. Introduction Our method Related Work Conclusions > Overview > Input > Properties E xecution Paths: endOfReview operation p 1 = { } p 2 = { ReclassifyObject(self,[Rejected],[]), AddStructuralFeature(self,comments,com) } Verifying Action Semantics Specifications in UML Behavioral Models 15 CAiSE’09 – 8-12 June 2009, Amsterdam if ReclassifyObject (self,[Rejected],[ ]) ReclassifyObject (self,[Accepted],[ ]) AddStructuralFeature (self,comments,com) AddStructuralFeature (self,accepDate,d) if

26. Introduction Our method Related Work Conclusions > Overview > Input > Properties E xecution Paths: endOfReview operation p 1 = { } p 2 = { ReclassifyObject(self,[Rejected],[]), AddStructuralFeature(self,comments,com) } p 3 = { ReclassifyObject(self,[Accepted],[]), AddStructuralFeature(self,accepDate,d) } Verifying Action Semantics Specifications in UML Behavioral Models 15 CAiSE’09 – 8-12 June 2009, Amsterdam if ReclassifyObject (self,[Rejected],[ ]) ReclassifyObject (self,[Accepted],[ ]) AddStructuralFeature (self,comments,com) AddStructuralFeature (self,accepDate,d) if

27. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Weak Executability W eak Executability Verifying Action Semantics Specifications in UML Behavioral Models 16 CAiSE’09 – 8-12 June 2009, Amsterdam

28. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Weak Executability W hat is Executability? An operation is executable when it may be successfully executed. The execution of the actions included in the operation evolves the initial state of the system to a new system state that satisfies all integrity constraints. Verifying Action Semantics Specifications in UML Behavioral Models 17 CAiSE’09 – 8-12 June 2009, Amsterdam

29. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Weak Executability W hat is Executability? Verifying Action Semantics Specifications in UML Behavioral Models 18 CAiSE’09 – 8-12 June 2009, Amsterdam Person name : String { readOnly } email : String Paper title : String Rejected comments : String Accepted accepDate : D ate Under Review IsAuthorOf author 1..* * WorksIn 1 * {disjoint,complete} Department name : String context Person:: dismiss () { DestroyLink(WorksIn, person, self, department, self.department); } context Department:: addDepartment (dpt_name: String): Department { Department dpt := CreateObject(Department); AddStructuralFeature(dpt,name,dpt_name); return dpt; } context Paper:: removeAuthor (author: Person) { DestroyLink(isAuthorOf,paper,self,person,author); }

30. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Weak Executability W hat is Executability? Verifying Action Semantics Specifications in UML Behavioral Models 18 CAiSE’09 – 8-12 June 2009, Amsterdam Person name : String { readOnly } email : String Paper title : String Rejected comments : String Accepted accepDate : D ate Under Review IsAuthorOf author 1..* * WorksIn 1 * {disjoint,complete} Department name : String context Person:: dismiss () { DestroyLink(WorksIn, person, self, department, self.department); } context Department:: addDepartment (dpt_name: String): Department { Department dpt := CreateObject(Department); AddStructuralFeature(dpt,name,dpt_name); return dpt; } context Paper:: removeAuthor (author: Person) { DestroyLink(isAuthorOf,paper,self,person,author); } ALWAYS EXECUTABLE

31. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Weak Executability W hat is Executability? Verifying Action Semantics Specifications in UML Behavioral Models 18 CAiSE’09 – 8-12 June 2009, Amsterdam Person name : String { readOnly } email : String Paper title : String Rejected comments : String Accepted accepDate : D ate Under Review IsAuthorOf author 1..* * WorksIn 1 * {disjoint,complete} Department name : String context Person:: dismiss () { DestroyLink(WorksIn, person, self, department, self.department); } context Department:: addDepartment (dpt_name: String): Department { Department dpt := CreateObject(Department); AddStructuralFeature(dpt,name,dpt_name); return dpt; } context Paper:: removeAuthor (author: Person) { DestroyLink(isAuthorOf,paper,self,person,author); } SOMETIMES EXECUTABLE ALWAYS EXECUTABLE

32. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Weak Executability W hat is Executability? Verifying Action Semantics Specifications in UML Behavioral Models 18 CAiSE’09 – 8-12 June 2009, Amsterdam Person name : String { readOnly } email : String Paper title : String Rejected comments : String Accepted accepDate : D ate Under Review IsAuthorOf author 1..* * WorksIn 1 * {disjoint,complete} Department name : String context Person:: dismiss () { DestroyLink(WorksIn, person, self, department, self.department); } context Department:: addDepartment (dpt_name: String): Department { Department dpt := CreateObject(Department); AddStructuralFeature(dpt,name,dpt_name); return dpt; } context Paper:: removeAuthor (author: Person) { DestroyLink(isAuthorOf,paper,self,person,author); } SOMETIMES EXECUTABLE NEVER EXECUTABLE ALWAYS EXECUTABLE

33. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Weak Executability W hat is Weak Executability? WEAK EXECUTABLE Our method Verifying Action Semantics Specifications in UML Behavioral Models 18 CAiSE’09 – 8-12 June 2009, Amsterdam An operation is weakly executable if there is a chance that a user may successfully execute it. context Person:: dismiss () { DestroyLink(WorksIn, person, self, department, self.department); } context Department:: addDepartment (dpt_name: String): Department { Department dpt := CreateObject(Department); AddStructuralFeature(dpt,name,dpt_name); return dpt; } context Paper:: removeAuthor (author: Person) { DestroyLink(isAuthorOf,paper,self,person,author); } SOMETIMES EXECUTABLE NEVER EXECUTABLE ALWAYS EXECUTABLE NOT WEAK EXECUTABLE

35. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Weak Executability W eak Executability Algorithm Verifying Action Semantics Specifications in UML Behavioral Models 20 CAiSE’09 – 8-12 June 2009, Amsterdam Executability Algorithm 1 Computing the Dependencies 2 Mapping the Dependencies p is not weakly executable + FEEDBACK Execution Path (p) p is weakly executable

36. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Weak Executability W eak Executability Algorithm: Example Verifying Action Semantics Specifications in UML Behavioral Models 21 CAiSE’09 – 8-12 June 2009, Amsterdam context Person:: dismiss () { DestroyLink(WorksIn, person, self, department, self.department); } Person name : String { readOnly } email : String Paper title : String Rejected comments : String Accepted accepDate : D ate Under Review IsAuthorOf author 1..* * WorksIn 1 * {disjoint,complete} Department name : String DestroyLink(assoc,p 1 ,p 2 )  CreateLink(assoc,p 1 ,p 3 ) OR DestroyObject(p 1 ) DEPENDENCY:

37. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Weak Executability W eak Executability Algorithm: Example context Person:: dismiss () { DestroyLink(WorksIn, person, self, department, self.department); } Verifying Action Semantics Specifications in UML Behavioral Models 21 CAiSE’09 – 8-12 June 2009, Amsterdam DestroyLink(assoc,p 1 ,p 2 )  CreateLink(assoc,p 1 ,p 3 ) OR DestroyObject(p 1 ) DEPENDENCY: context Person:: dismiss ( newDpt: Department ) { DestroyLink(WorksIn, person, self, department, self.department); CreateLink(WorksIn, person, self, department, newDpt ); } Solution 1 Person name : String { readOnly } email : String Paper title : String Rejected comments : String Accepted accepDate : D ate Under Review IsAuthorOf author 1..* * WorksIn 1 * {disjoint,complete} Department name : String

38. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Weak Executability W eak Executability Algorithm: Example Verifying Action Semantics Specifications in UML Behavioral Models 21 CAiSE’09 – 8-12 June 2009, Amsterdam DestroyLink(assoc,p 1 ,p 2 )  CreateLink(assoc,p 1 ,p 3 ) OR DestroyObject(p 1 ) DEPENDENCY: context Person:: dismiss () { DestroyLink(WorksIn, person, self, department, self.department); DestroyObject(self); } Solution 2 context Person:: dismiss () { DestroyLink(WorksIn, person, self, department, self.department); } Person name : String { readOnly } email : String Paper title : String Rejected comments : String Accepted accepDate : D ate Under Review IsAuthorOf author 1..* * WorksIn 1 * {disjoint,complete} Department name : String

39. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Weak Executability W eak Executability Algorithm: Example the path is not weakly executable FEEDBACK: 1. Add CreateLink action 2. Add DestroyObject action Verifying Action Semantics Specifications in UML Behavioral Models 22 CAiSE’09 – 8-12 June 2009, Amsterdam Executability Algorithm 1 Computing the Dependencies 2 Mapping the Dependencies dismiss path

40. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Completeness C ompleteness Verifying Action Semantics Specifications in UML Behavioral Models 23 CAiSE’09 – 8-12 June 2009, Amsterdam

41. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Completeness C ompleteness A set of operations is complete when all possible changes (inserts/updates/deletes) on all parts of the system state can be performed throught the execution of the actions included in it. Verifying Action Semantics Specifications in UML Behavioral Models 24 CAiSE’09 – 8-12 June 2009, Amsterdam C lass Diagram O perations Set Person name : String email : String Department name : String WorksIn 1 * context Person:: dismiss (newDpt: Department) { DestroyLink(WorksIn, person, self, department, self.department); CreateLink(WorksIn, person, self, department, newDpt); } NOT COMPLETE

42. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Completeness C ompleteness Algorithm Verifying Action Semantics Specifications in UML Behavioral Models 25 CAiSE’09 – 8-12 June 2009, Amsterdam Completeness Algorithm 1 Computing Required Actions ( RA ) 2 Computing Existing Actions ( EA ) 3 Computing Missing Actions ( MA ) MA = RA - EA Set of operations MA = ø the set is complete the set is not complete + FEEDBACK MA ≠ ø

43. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Completeness C ompleteness Algorithm (Example) context Person:: dismiss (newDpt: Department) { DestroyLink(WorksIn, person, self, department, self.department); CreateLink(WorksIn, person, self, department, newDpt); } I nput Verifying Action Semantics Specifications in UML Behavioral Models 26 CAiSE’09 – 8-12 June 2009, Amsterdam Person name : String email : String Department name : String WorksIn 1 *

44. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Completeness C ompleteness Algorithm (Example) context Person:: dismiss (newDpt: Department) { DestroyLink(WorksIn, person, self, department, self.department); CreateLink(WorksIn, person, self, department, newDpt); } I nput p:=CreateObject(Person) d:=CreateObject(Department) DestroyObject(p) DestroyObject(d) AddStructuralFeature(p,name,v) AddStructuralFeature(p,email,v) AddStructuralFeature(d,name,v) DestroyLink(WorksIn,p,d) CreateLink(WorksIn,p,d) Required Actions Verifying Action Semantics Specifications in UML Behavioral Models 26 CAiSE’09 – 8-12 June 2009, Amsterdam Person name : String email : String Department name : String WorksIn 1 *

45. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Completeness C ompleteness Algorithm (Example) context Person:: dismiss (newDpt: Department){ DestroyLink(WorksIn, person, self, department, self.department); CreateLink(WorksIn, person, self, department, newDpt); } I nput DestroyLink(WorksIn,p,d) CreateLink(WorksIn,p,d) Existing Actions p:=CreateObject(Person) d:=CreateObject(Department) DestroyObject(p) DestroyObject(d) AddStructuralFeature(p,name,v) AddStructuralFeature(p,email,v) AddStructuralFeature(d,name,v) DestroyLink(WorksIn,p,d) CreateLink(WorksIn,p,d) Required Actions Verifying Action Semantics Specifications in UML Behavioral Models 26 CAiSE’09 – 8-12 June 2009, Amsterdam Person name : String email : String Department name : String WorksIn 1 *

46. Introduction Our method Related Work Conclusions > Overview > Input > Properties: Completeness C ompleteness Algorithm (Example) context Person:: dismiss (newDpt: Department { DestroyLink(WorksIn, person, self, department, self.department); CreateLink(WorksIn, person, self, department, newDpt); } I nput p:=CreateObject(Person) d:=CreateObject(Department) DestroyObject(p) DestroyObject(d) AddStructuralFeature(p,name,v) AddStructuralFeature(p,email,v) AddStructuralFeature(d,name,v) FEEDBACK (Missing Actions) - = DestroyLink(WorksIn,p,d) CreateLink(WorksIn,p,d) Existing Actions p:=CreateObject(Person) d:=CreateObject(Department) DestroyObject(p) DestroyObject(d) AddStructuralFeature(p,name,v) AddStructuralFeature(p,email,v) AddStructuralFeature(d,name,v) DestroyLink(WorksIn,p,d) CreateLink(WorksIn,p,d) Required Actions Verifying Action Semantics Specifications in UML Behavioral Models 26 CAiSE’09 – 8-12 June 2009, Amsterdam Person name : String email : String Department name : String WorksIn 1 *

47. Introduction Our method Related Work Conclusions C omparison Verifying Action Semantics Specifications in UML Behavioral Models 27 CAiSE’09 – 8-12 June 2009, Amsterdam Model Checking based methods Our method Dynamic analysis analysis Static analysis More detailed analysis depth Basic correctness analysis General LTL properties properties Syntactic correctness, Executability, Completeness Error trace output Valuable feedback Finite set of values scope Not take into account possible values for the arguments UML behavioral diagrams focus Actions

48. Introduction Our method Related Work Conclusions > Conclusions and Further Work C onclusions Lightweight method for the verification of the correctnes properties of imperative operations Extensible to other kinds of behavioral specifications Static analysis (do not require simulation) Valuable feedback ▪ ▪ ▪ ▪ Verifying Action Semantics Specifications in UML Behavioral Models 28 CAiSE’09 – 8-12 June 2009, Amsterdam Complement our techniques with MC approaches Implement and integrate our tehcniques in a CASE tool Validate our techniques with a complex case study Evaluate empirically the computational cost of our techniques F urther Work ▪ ▪ ▪ ▪

49. The 21st International Conference on Advanced Information Systems CAiSE’09 12nd June 2009 Amsterdam T hanks for your attention! Elena Planas [email_address] Verifying Action Semantics Specifications in UML Behavioral Models