verifying action semantics specifications in uml behavioral models (caise 2009)

The 21st International Conference onAdvanced Information Systems

CAiSE’0912nd June 2009 Amsterdam

Verifying Action Semantics Specifications in UML Behavioral Models

Elena Planas 1

Jordi Cabot 1

Cristina Gómez 2

1 Open University of Catalonia2 Technical University of Catalonia


• Introduction

• Our method

• Related Work

• Conclusions and Further Work

Index

1CAiSE’09 – 8-12 June 2009, Amsterdam

IntroductionIntroductionOur method

Related WorkConclusions

> ContextContext> Motivation> Goal

specification design implementation testing

Life cycle of software systems

CodeModel Driven

Development

before

UML Model

Structural model

Behavioral model

now

our work

Verifying Action Semantics Specifications in UML Behavioral Models 2CAiSE’09 – 8-12 June 2009, Amsterdam



> Context> MotivationMotivation> Goal

Example

Person

name : String email : String

Department

name : String

WorksIn1*

context Person::addPerson addPerson (n:String, e:String) { p: Person; p := CreateObject(Person); AddStructuralFeature(p,name,n); AddStructuralFeature(p,email,e);}

context Person::changeAddresschangeAddress(a:String) { AddStructuralFeature(self,address,a);}





Example

Person


Department

name : String

WorksIn1*



NOT SYNTACTICALLY CORRECT





Example

Person


Department

name : String

WorksIn1*



NOT EXECUTABLE





Example

Person


Department

name : String

WorksIn1*

NOT COMPLETE






> Context> Motivation> GoalGoal

Provide a set of lightweight techniques for the verification of correctness properties of Action Semantics specifications at design time

Goal


specification design implementation testing

Syntactic Correctness

Completenessinput

OUR METHOD feedback

WeakExecutabilityUML Model

Execution Paths

IntroductionOur methodOur methodRelated Work

Conclusions

> OverviewOverview> Input> Properties

Characterisitics:

- Focused on imperative operations

- Performs a static analysis (do not require simulation)

Our method



Completenessinput

OUR METHOD feedback


Execution Paths


Conclusions

> Overview> InputInput> Properties

Input



Completenessinput

OUR METHOD feedback


Execution Paths


Conclusions


Class DiagramClass Diagram

*

Operation

UML Action

OperationsOperations

Input

subset of UML Actionssubset of UML Actions CreateObject DestroyObject AddStructuralFeature CreateLink DestroyLink ReclassifyObject CallOperation

UML Structured ActionsUML Structured Actions if… then… else… endif while... do… endwhile do… while… enddo

Action SemanticsAction = fundamental unit of behavior specification

Basis for defining the behavior in a fine granularity



Conclusions


Action Semantics Example

context Paper::endOfReviewendOfReview(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::dismissdismiss() { DestroyLink(WorksIn, person, self, department, self.department);}


Person name : String { readOnly } email : String

Paper title : String

Rejected comments : String

Accepted accepDate : Date

Under Review

IsAuthorOf author

1..* *

WorksIn 1 * {disjoint,complete}

Department name : String


Conclusions

> Overview> Input> PropertiesProperties

Correctness Properties



Completenessinput

OUR METHOD feedback


Execution Paths


Conclusions

> Overview> Input> Properties: Syntactic CorrectnessProperties: Syntactic Correctness




Completenessinput

OUR METHOD feedback


Execution Paths


Conclusions


An operation is syntactically correct when all the actions included in its specification satisfy the WFR.


WFR (Well Formedness Rule) = Constraint that restrict the possible set of valid UML models.



Conclusions


New WFR proposed

context WriteStructuralFeatureAction inv: self.value.type = self.structuralFeature.type

…r := CreateObject(Rejected);

WriteStructuralFeature(r,name,17);WriteStructuralFeature(r,name,”Peter”);

Person


Department

name : String

WorksIn1*



Conclusions


Execution Paths

Computing the execution paths is necessary to check the next correctness properties (executability and completeness).



Completenessinput

OUR METHOD feedback


Execution Paths


Conclusions


Execution 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).



Conclusions


Execution Paths: endOfReview operationcontext Paper::endOfReviewendOfReview(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 }



Conclusions


Execution Paths: endOfReview operation

ReclassifyObject(self,[Rejected],[ ])

ReclassifyObject(self,[Accepted],[ ])

AddStructuralFeature(self,comments,com)

AddStructuralFeature(self,accepDate,d)


Action

Vertex



Conclusions



if





if


Conditional node

Branch



Conclusions



if





if


Ordered sequence of actions

Arc



Conclusions



if





if


Initial Node

Final Node



Conclusions



if





if

p1 = { }



Conclusions



if





if

p1 = { }

p2 = { ReclassifyObject(self,[Rejected],[]), AddStructuralFeature(self,comments,com) }



Conclusions



if





if

p1 = { }

p2 = { ReclassifyObject(self,[Rejected],[]), AddStructuralFeature(self,comments,com) }

p3 = { ReclassifyObject(self,[Accepted],[]), AddStructuralFeature(self,accepDate,d) }



Conclusions

> Overview> Input> Properties: Weak ExecutabilityProperties: Weak Executability

Weak Executability



Completenessinput

OUR METHOD feedback


Execution Paths


Conclusions


What 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 integrityconstraints.



Conclusions


What is Executability?Person

name : String { readOnly } email : String




Under Review

IsAuthorOf author

1..* *



context Person::dismissdismiss() { DestroyLink(WorksIn, person, self, department, self.department); }

context Department::addDepartmentaddDepartment(dpt_name: String): Department { Department dpt := CreateObject(Department); AddStructuralFeature(dpt,name,dpt_name); return dpt; }

context Paper::removeAuthorremoveAuthor(author: Person) { DestroyLink(isAuthorOf,paper,self,person,author); }



Conclusions







Under Review

IsAuthorOf author

1..* *






ALWAYS EXECUTABLE



Conclusions







Under Review

IsAuthorOf author

1..* *






SOMETIMESEXECUTABLE

ALWAYS EXECUTABLE



Conclusions







Under Review

IsAuthorOf author

1..* *






SOMETIMESEXECUTABLE

NEVEREXECUTABLE

ALWAYS EXECUTABLE



Conclusions


What is Weak Executability?




SOMETIMESEXECUTABLE

NEVEREXECUTABLE

ALWAYS EXECUTABLE

WEAK EXECUTABLE

NOT WEAKEXECUTABLE

Our method


An operation is weakly executable if there is a chance that a user may successfully execute it.


Conclusions


Weak Executability of an operation

Some actions require the presence of other actions in order to leave the system in a consistent state DEPENDENCY

A dependency from an action A1 to an action A2 (A1 A2) express that A2 must be included in all execution paths where A1 appers to avoid violating the constraints of the class diagram.

For checking the Weak Executability, we just take into account:- Minimum cardinality constraints- Disjoint/Complete constraint


An operation is weakly executable if at least one of its execution paths is weak executable.


Conclusions


Weak Executability Algorithm

Executability Algorithm1 Computing the Dependencies

2 Mapping the Dependencies

p is not weakly executable+ FEEDBACK

Execution Path (p)

p is weakly executable



Conclusions


Weak Executability Algorithm: Example






Under Review

IsAuthorOf author

1..* *



DestroyLink(assoc,p1,p2) CreateLink(assoc,p1,p3) OR DestroyObject(p1)DEPENDENCY:



Conclusions









Under Review

IsAuthorOf author

1..* *




context Person::dismissdismiss(newDpt: Department) { DestroyLink(WorksIn, person, self, department, self.department); CreateLink(WorksIn, person, self, department, newDpt); }

Solution 1


Conclusions








Under Review

IsAuthorOf author

1..* *




context Person::dismissdismiss() { DestroyLink(WorksIn, person, self, department, self.department); DestroyObject(self);}

Solution 2



Conclusions



Executability Algorithm1 Computing the Dependencies

2 Mapping the Dependencies

the path is not weakly executable

FEEDBACK:1. Add CreateLink action2. Add DestroyObject action

dismiss path



Conclusions

> Overview> Input> Properties: CompletenessProperties: Completeness

Completeness



Completenessinput

OUR METHOD feedback


Execution Paths


Conclusions


Completeness

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.

Class Diagram

Operations Set

Person


Department

name : String

WorksIn1*

context Person::dismissdismiss(newDpt: Department) { DestroyLink(WorksIn, person, self, department, self.department); CreateLink(WorksIn, person, self, department, newDpt);}

NOT COMPLETE



Conclusions


Completeness Algorithm

Completeness Algorithm1 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 ≠ ø



Conclusions


Completeness Algorithm (Example)

Person


Department

name : String

WorksIn1*


Inpu

t



Conclusions



Person


Department

name : String

WorksIn1*


Inpu

t

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



Conclusions



Person


Department

name : String

WorksIn1*

context Person::dismissdismiss(newDpt: Department){ DestroyLink(WorksIn, person, self, department, self.department); CreateLink(WorksIn, person, self, department, newDpt);}

Inpu

t

DestroyLink(WorksIn,p,d)CreateLink(WorksIn,p,d)

Existing Actions


Required Actions



Conclusions



Person


Department

name : String

WorksIn1*

context Person::dismissdismiss(newDpt: Department { DestroyLink(WorksIn, person, self, department, self.department); CreateLink(WorksIn, person, self, department, newDpt);}

Inpu

t

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


Required Actions


IntroductionOur method

Related WorkRelated WorkConclusions

ComparisonModel Checking based methodsOur method

Dynamic analysisanalysis Static analysis

More detailed analysisdepth Basic correctness analysis

General LTL propertiespropertiesSyntactic correctness,

Executability, Completeness

Error traceoutput Valuable feedback

Finite set of valuesscope Not take into account possible values for the arguments

UML behavioral diagramsfocus Actions


IntroductionOur method

Related WorkConclusionsConclusions

> Conclusions and Further WorkConclusions and Further Work

ConclusionsLightweight method for the verification of the correctnes properties of imperative operationsExtensible to other kinds of behavioral specificationsStatic analysis (do not require simulation)Valuable feedback

▪

▪▪▪

Complement our techniques with MC approachesImplement and integrate our tehcniques in a CASE toolValidate our techniques with a complex case studyEvaluate empirically the computational cost of our techniques

Further Work▪

▪▪▪


The 21st International Conference onAdvanced Information Systems

CAiSE’0912nd June 2009 Amsterdam

Thanks for your attention!

Elena [email protected]


verifying action semantics specifications in uml behavioral models (caise 2009)

Technology