a framework for verifying uml behavioral models (caise doctoral consortium 2009)

Doctoral ConsortiumCAiSE’09

10th June 2009 Amsterdam

A Framework forVerifying UML Behavioral Models

Elena [email protected]

Open University of Catalonia

A Framework for Verifying UML Behavioral Models

• Introduction

• Thesis Proposal

• Related Work

• Conclusions

Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam

Index

1

Life cycle of software

IntroductionIntroductionThesis Proposal

Related WorkConclusions

> ContextContext> Motivation

specification design implementation testing

CodeModel Driven

Development

before

UML Model

Structural model

Behavioral model

now

thesis proposal

A Framework for Verifying UML Behavioral Models Doctoral Consortium CAiSE’09 – 10th June 2009, Amsterdam 2

Code

Code Generation

UML Behavioral

Model

We need define UML model in sufficient detail and precision

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

> Context> MotivationMotivation




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*


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

NOT SYNTACTICALLY CORRECT


Example




Person


Department

name : String

WorksIn1*


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

NOT EXECUTABLE


Example




Person


Department

name : String

WorksIn1*

NOT COMPLETE


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


Provide a verification framework to help the designers to verify the correctness of their behavioral models (based in Actions)

Goal

Action-basedbehavior

specificationSyntactic

Correctness Completeness Redundancy

input

STATIC MODEL VERIFIER feedback

translationWeak

Executability

MODEL CHECKING

ACTION SEMANTICS VERIFICATION FRAMEWORK

Executability

> GoalsGoals> Framework description> Important issues

IntroductionThesis ProposalThesis Proposal



Sub-Goals

Identify and describe correctness properties: - Syntactic correctness - Executability - Completeness - Redundancy

1




input


translationWeak

Executability

MODEL CHECKING






Sub-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




input


translationWeak

Executability

MODEL CHECKING






Sub-Goals

Integrate the previous static techniques with other existing verification approaches (Model Checking)

3




input


translationWeak

Executability

MODEL CHECKING


Executability





Sub-Goals

Provide useful feedback to the designer4




input


translationWeak

Executability

MODEL CHECKING






Input

UML Class DiagramUML Class Diagram

OperationsActivity DiagramsInteraction DiagramsState Machines

Behavioral Behavioral Specification Specification

(Action Semantics)(Action Semantics)

> Goals> Framework description: InputFramework description: Input> Important issues




Verification techniques used

> Goals> Framework description: Techniques Framework description: Techniques > Important issues

Static techniquesStatic techniquesStatic analysis

Output: Corrective feedback

First correctness analysis

Model CheckingModel CheckingTranslation:

State Explosion Problem

LTL properties

Output: Error trace

More detailed analysis

UML Model

MClanguage


specification design implementation testing



Syntactic Correctness

A behavioral specification described using actions is syntactically correct when all the actions included in it satisfy the WFR

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

> Goals> Framework description: PropertiesFramework description: Properties> Important issues




Syntactic Correctness: Example

WFR: The classifier cannot be abstract

context CreateObject inv: not (self.classifier.isAbstract = #true)

obj2 := CreateObject(ConcreteClass);

AbstractClass

ConcreteClass

obj1 := CreateObject(AbstractClass);





Executability

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 behaviorStrong Executability all successful executions of the behavior





Executability: Example

Person


Department

name : String

WorksIn1*




notexecutable



FEEDBACK: Add a CreateLink

Executability: Example

Person


Department

name : String

WorksIn1*



context Person::addPerson 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);}

executable



FEEDBACK: Add a CreateLink

Completeness

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





Completeness: ExamplePerson


Department

name : String

WorksIn1*



not completecontext Person::addPerson 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);}



FEEDBACK: Add actions to create/destroy departments…

Redundancy

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





Redundancy: Example


context Person::changeNamechangeName(name1:String, name2:String) { AddStructuralFeature(self,name,name1); AddStructuralFeature(self,name,name2); }


Redundancy: The second update overwrites the first one

redundant action



FEEDBACK: Remove the first update

Important issues

> Goals> Framework description: Properties> Important issuesImportant issues

scope Action based UML behavioral specifications

extension Aplicable to BPM diagrams


limitations Our static verification do not check conditions



Related work

UML Model

Behavioral model

Most of related works:

• Use Model Checking techniques

• Ignore the actions included

• Verify LTL properties

• Not meaningful feedback


IntroductionThesis ProposalRelated WorkRelated Work

Conclusions

Conclusions

Framework for the verification of the correctnes of

UML behavioral models

Extensible to other kinds of behavioral specifications

Focused on Actions

Valuable feedback

▪

▪

▪

▪


IntroductionThesis Proposal

Related WorkConclusionsConclusions

Doctoral ConsortiumCAiSE’09

10th June 2009Amsterdam

Thanks for your attention!

Elena [email protected]

A Framewrok for Verifying UML Behavioral Models

a framework for verifying uml behavioral models (caise doctoral consortium 2009)

Technology