1 uml and petri nets for test case generation from fondue to co-opn: (my) first iteration

1

UML and Petri Nets for Test Case Generation

From Fondue to CO-OPN:

(my) first iteration

September 16, 2004 Luis Pedro 2

Outline

User’s viewpoint: the 4 steps for test generation The Model - Fondue approach Deriving test cases and applying criteria Implementation testing Test results

Developers viewpoint - OO Petri Nets to enable state space exploration The Intermediate format Steps to Transformation ….

Current work Next chapters…

3

User’s viewpoint: the 4 steps in the test generation

Step 1: The Model


Step 1: The model UML (Fondue specification)

Software development process for reactive systems Purpose is to produce description of

the problem domain The functional requirements of the system

What it provides Concept Model: Defines the static structure of the information in the system Behavior Model: Defines the Input and Output communication of the system

Uses UML for notation (parts of different UML diagrams) e.g Specification (models)

Concept Model Class Diagram Environment Model Collaboration Diagram Protocol Model State Diagram Operation Model (OCL)


Step 1: The Model (cont.)

Fondue (cont.) Describes operations by operation schemas which specify

operations by pre- and post conditions using OCL Effect of the operation on an abstract state representation of the

system and by events sent to the outside world The change of state resulting from an operation's execution is

described in terms of objects, attributes and association links, which conform to the constraints imposed by the analysis class model of the respective system. Restricted form of state diagrams is used to describe sequencing of system operations.

The Fondue process can be outlined by a UML class diagram showing usage dependencies between the models



Fondue - ebanking example Environment Model (messages from the user)

<<system>>eBanking

User

loginUserNameloginPasswd

loginChallengecreatePayment

giveDetailsBeneficiarymodifyPaimentdeletePayment



Fondue - ebanking example Environment Model (messages from the system)

<<system>>eBanking

UsersendChallengeNumber

errorUserNameerrorPasswd

errorChallengeerrorUserBlocked

errorPaymentCreationerrorPaymentModification



Fondue - ebanking example Concept Model

<<system>>

eBanking

User

userName : StringPasswd : PasswdName : StringloginTentativeNumber : IntuserState: bool

eUser

id : CardIdexpirationDate: Date

ChallengeCard

position : ChallengeId anserPosition: String

ChallengeCardElement

position1

table

0.. 1

1

0.. *0.. 1

<<Id>>

HasSessionId


The full picture

Tests

Model

Criteria

DriverMapping

ImplementationInterface

OracleAssumptions

TestResults

<T>

Observation

Map

pin

g ru

les

Application

Pro

du

ction

10

Developers viewpoint - OO Petri Nets to enable state space exploration

Steps to transformation and the Internal format


Steps to Transformation

Goal: from Fondue to CO-OPNOCL translation

Fondue Operational ModelTransformation (represents OO

formalisms) Object states and attributes; Management of object creation and destruction Typing references polymorphism DataTypes: generators and operators


Step 1: Read/Load Fondue Model

Export Fondue Model to XMI Using Together Fondue export tool Generates XMI Fondue Model

Load Fondue Model Fondue Metal Model described in terms of MOF

MOF = M3 level -> Meta-MetaModel Use of MDR

Implementation of MOF Can be managed programmatically using JMI

Parse it with JMI Java Metadata Interface Rules for generating metamodel-specific Java API Defines a set of reflective interfaces that can be used similarly to the

metamodel-specific Java API without prior knowledge of the metamodel


Step 1: Read/Load Fondue Model

XMI

[FondueMM]

FondueModel

FondueMMMOF desc

Load byMDR

Parse Using JMI

IntermediateFormat

?…?…


Step 2: The Environment model

Environment model 1 CO-OPN Context Operations methods of the context Output messages Gates

input

output


Step 3: Concept model

1 Class 1 CO-OPN Class Name Name Attributes Places Access methods: put, get, read

Method put_a(x):: a y -> a x; Gate get_a(x):: a x -> a x; Gate read_a(x)::a x:: -> a x;

Associations as classesWith source and target values Instatioation of AADT BagFor each class

put put

get


Step 3: Concept model 1 Class 1 CO-OPN Class

Name Name Attributes Places Access methods: put, get, read

Method put_a(x):: a y -> a x; Gate get_a(x):: a x -> a x; Gate read_a(x)::a x:: -> a x;

read put

get

!• Why don’t we have a Method get?• Only Gates with get/read functions • How can we see the difference between Gates and Methods

Questions regarding this diagram


Step 4: Operation model

Transform Fondue pre and post-conditions using OCL Operation Schemas (synchronization rules,

algebraic equations) … … … Not fully understood :-(

Further investigation needed


Current work

What’s done: Fondue exportation

XMI [FondueMM] Read/Load Fondue Module

Using a particular MDR implementation and

Fondue MOF description Parse

Using JMI Environment model Concept model


Next chapters

Finish the application simulated eBanking application

Understand OCL and in particular Fondue Operation Schemas

Prepare a first iteration for the translation process To understand the full

picture regarding relation between Fondue internal structure and CO-OPN


The end

Questions... Comments

1 uml and petri nets for test case generation from fondue to co-opn: (my) first iteration

Documents

model cont

fondue cont

providesconcept model

systembehavior model

fondue process

analysis class model

state space explorationsteps

uml class diagram