Systemic approach towards model definition

Irina Rychkova. 9/2006 1

Systemic approach towards model definition

Model transformation semantics


Motivation 2 ways of model representation:

Action centric (UML activity diagrams, BPMN ..) Data centric (UML class diagrams)

Our observation: Data structure and behavior are loosely-coupled Model of data structure is not related to the model of behavior Model of behavior implicitly related with the model of data structure via

constraints Semantic of model transformation is not clear Example: Within one model of the workflow information about objects is

hidden inside the actions…

Systemic approach System thinking puts emphasis to the integration of 2 aspects within one

model Definition of behavior as a state change Re-definition of property explicitly affects behavior Re-definition of behavior explicitly affects property


Solution

Part I Relation semantics

Behavior-Property relations Property-Property relations

Semantics of Model transformation Refinement Composition

Part II Types vs. instances:

Instance information embedded to relations AsmL operational semantics

Automated model translation to AsmL Simulation

On-going: Automated model verification using asmlt


Cinema WebSite Example

Cinema X develops a web site to provide clients with new services:

A Booking tickets service enables tickets reservation via internet.

To book tickets a client has to log in on the web site. If logged in, the client can add reservations for a movie of his/her choice to a virtual cart.

The movie can be chosen from an agenda - the movie list.The web site has to control a number of places (seats)

available for every movie. Booking tickets finishes when the client commits and logs out.


“Rectangular” vs. “Circular” community

nMovies: Integer

Agenda

nClients: Integer

ClientAccountList

Action - c

entric

view

BookingTicketsH H

Customer

BookingTickets

WebSite

nMovies = 10

agenda: Agenda

nClients = 54

cList:ClientAccountList

Data - centric

view

Irina Rychkova. 9/2006 6nMovies = 10

agenda: Agenda

nClients = 54

cList:ClientAccountList

nMovies: Integer

Agenda

nClients: Integer

ClientAccountList

BookingTicketsH H

Customer

BookingTickets

WebSite

WebSite

BookingTickets

LifeCycle

Agenda PreS:1|agenda

ClientAccountList

NMovies{int}

NClients{int}

PreS:1|cList

H H

nMovies nClients

Environment

Systemic approach 1/3Integration of structural and behavioral aspects within a model


WebSite

BookingTickets

LifeCycle


ClientAccountList

NMovies{int}

NClients{int}

PreS:1|cList

H H

nMovies nClients

Environment

Systemic approach 2/3

1. Environment and Boundary

2. Context

3. Behavior-Property* relations

4. Stateless and Statefull properties

1

2

3

4

*Here we use the term “property” to reason about information objects presented in the system rather then a commonly used term “structure”. The latter can be used to define both “data structure” and “structure of behavior” and need to be specified.


Systemic approach 3/3

Boundary: A border between the system (a “Hollon”) and its environment.

Environment (of an object): The part of the model which is not the part of that object. [RM-ODP]

Context (modeling context): A scope of interests for a given model. Model elements (properties, behaviors, relations) can be specified as relevant or irrelevant to a given context. LifeCycle context is a global context for any system. Context can be defined by the hollon and its behavior of interest.


Property

Statefull property: a property who’s instance state can be directly obtained and interpreted as a value of one of the standard operational types*.

Stateless property: a property who’s instance state is not defined and can be expressed only indirectly, via states of related properties (attributes).

* Standard operational type: here, Integer, String, Char, Long, Double, Boolean.

Agenda

NMovies{int}

nMovies

10

valueState

State

nMovies = 10

agenda: Agenda

PreS:1|agenda


Part I:

Semantic definition for relations


Relating Behavior to Data Structure

UML: OCL constraints SEAM:

Property-Property relations; Behavior-Property relations; Action-Action relations


Property-Property relations Exhibit relation: relation between a

stateless property (the owner) seen as atomic and its attribute (in general also can be a stateless property) that characterizes the property at a given abstraction level.

Composition relation Association relation:

Agenda

NMovies{int}

nMovies

Agenda

MovieSeat

{0..250}

1..10|mList[1]..mList[10]

1|seats

M_ID{String}

1|id

Movie ReservationList0..n|rList[1]..rList[n]

Movie ReservationList

0..1| rList[1]

0..1| rList[n]

0..1| rList[2]

<cardinality>|<instance_name>


Behavior- Property relations

Behavior-property relation: 1. A model element that expresses a semantic relation between action and property; specifies behavior effect in terms of state change 2. The way to define a) a precondition, b) an emergent property or c) a postcondition for an action.


Behavior- Property relations: Precondition

System preconditions (PreS) define predicates in terms of system variables obtained as a result of a previous system activity.

Environment preconditions (PreEnv) define predicates in terms of parameters, provided by the environment via events.

BookingTickets


H H

BookingTicketsH H

ClientID{String}

PreEnv: 1|userID

E1[userID:ClientID, idList:ReservationBag]


Behavior- Property relations: Emergent property

A predicate that specifies the action termination. (true-false, ok-error, etc). Based on the Emergent property, action effect can be chosen. In general case an emergent property might have more then 2 values. H LogIn

ClientID{String}

PreEnv: 0..1|userID

ValidID{Boolean}

Emergent 1|validUser exists cL in cList.cL where cL.id.valueRef eq userID.valueRef

M0: LoggingIn [userID: ClientID]


<expression>


Behavior- Property relations: Postcondition

System postcondition (PostS) specifies the action effect hidden from the environment.

Environment postcondition (PostEnv) specifies the action effect and the way to make it visible and/or accessible for the environment (events declaration etc).

ClientAccount

BookingTickets

ID{String}

ReservationListreservationList

id

1|thisPostEnv [true]

This = the cL | cL in cList.cL where cL.id == userID;

This.reservationList.nRes:=This.reservationList.nRes + idList.nID

ClientAccountList

0..*|cL[1]..cL[*]

NReservations{int}

1|nRes


[<condition>] This = <subject_identification_expression>

<subject_modification_expression>


Action-Action relations

UML BPMN


Model transformation

Semantics for model transformations: Refinement Composition


Refinement 1/3

nMovies: Integer

Agenda

nClients: Integer

ClientAccountList

nMovies: Integer

Agenda

ClientAccountList

ID: String

ClientAccount

nReservations: Integer

ReservationList

*

1

BookingTicketsH H

OCL expressions:...

BookingTicketsH H?

Class redefinition:

ClientAccountList

How it affects the definition of BookingTicket action?


Refinement 2/3

ClientAccountList redefined→ BookingTickets must :

1. choose the ONE client out of the list

2. modify the reservation list of this client

3. Accept corresponding parameters from environment

BookingTickets

ClientAccountList

NClients{int}

PreS:1|cList

H H

nClients

ClientAccount

BookingTicketsH H

ID{String}


id

PreEnv: 1|idList




ClientAccountList

0..*|cL[1]..cL[*]

ReservationBag

ClientID{String}

PreEnv: 1|userID



Refinement 3/3

BookingTicketsH H

PreEnv: 1|idList

ReservationBag

NMovieID{int}nID

ClientID{String}

PreEnv: 1|userID


H LogIn ManageReservation LogOut

BookingTickets

HM1: [idList:

Reservation] M2: ExitM0: LoggingIn

[userID: ClientID]

PreEnv: 1|idList

ReservationBag

NMovieID{int}nID

ClientID{String}

PreEnv: 1|userID

ValidID{Boolean}

Emergent 1|validUser exists cL in cList.cL where cL.id.valueRef eq userID.valueRef

PreS: 1|validUservalidUser==true

BookingTickets redefined →1. Relations to properties must be

redistributed between component actions

2. Emergent property required3. Communication with

environment needs revision


Semantically safe transformations

Binding expressions:

cList.nClients = cList’.size()

BookingTickets

ClientAccountList

NClients{int}

PreS:1|cList

H H

nClients ClientAccount

BookingTicketsH H

ID{String}


id

PreEnv: 1|idList




ClientAccountList

0..*|cL[1]..cL[*]

ReservationBag

ClientID{String}

PreEnv: 1|userID



Benefits

Semantically rich models Explicit Behavior-changes-state

notation Simulation possible


Part II

Application


Types vs. Instances

Instance information is embedded into the model: Property-Property relation links instances

(ordered sets of instances in case of * cardinality)

Behavior-Property relation defines an operation via instances

Binding using instance names Values:

For every statefull property its initial state predefined


SEAM – AsmL translator

AsmL – abstract model specification language with environment for simulation and testing


Tool for automated code generation

SEAM_Model

Name: StringDescription: StringOrgL: IntFuncL: intID: StringparentHollon:Hollon

SEAM_Element

0..*

systemOfInterest

Type: String

Event

0..*

invokes

0..1

parameter

LocalizedContext

1

context

1

1

*

property

DestinationRole: RoleDestinationCardinality: StringSourceRole: RoleSourceCardinality: StringDirected: booleanCollectionType: Stringexpression: ExpressionSpec: String

PPConstraint

source

1destination

Spec: String

AAConstraint

PAssociation

Type: String

Boundary

0..*

Event

Stereotype: StringInclusive: boolean

PDependency

Transition

TransitionBoundary

TransitionFork

TransitionMerge

ANDSplit

1

1

1

*

*

1

0..1

boundary

TransitionEventBased

0..1

event

PropertyRole: RolePropertyCardinality: StringStereotype: StringCondition: Condition expression:ExpressionSpec: String

BPRelation

BPContextAssociation

BPContextComposition

1property

*

sends

0..*

source destination sourcedestination

source destination

1

holdsPPConstraint

1

*

1

1

HGroupComposition

1

*

componentholds

* component

Next org level

EntityType: String

Hollon

ActivityNode

JointAction

LocalizedtAction

generates

0..1partOf

*

Activity

holdsAction

1

*

Start

End

InstanceType: StringstateSpaceType: String

Property

ValueType: StringValue: java.Object

State

atCreation

0..1stateSpace[]

*0..1

State

isMultiple: BooleanexitCondition: Condition

Action

Type: String

ControlAction

WorkingObject<as a whole>

WorkingObject<as a composite>

JointContext

partOf

Behavior

1

LocalizedtActivity

JointActivity0..1

asAction

asActivity

1

context

asCompositeasWhole

1

asWhole

asComposite

1

*component

Context

Type: String

Message

1

1asWhole

asComposite

Action

Activity

*

component

Context

0..*holdsBehavior

HComposition

*

hollon

BPGroupRelation*holdsProperty

*

relationToProperty

behavior

CBGroupRelation

CBRelation*

relationToBehavior1

behavior

CPGroupRelation

*relationToProperty

holdsProperty

CPRelation

*

PGroupReference

holds

*

property

PPGroupConstraint

component

*

ActivityActionRelation

1

relationToAction

ActivityActionGroupRelation

* action

holdsAAConstraint

parentHollon:HollonOrgL: IntFuncL: intID: String

Constraint

1

asHollon

1

asHollon

1

asBehavior

asBehavior

1

AAGroupConstraint

*

component

1 activity

1

context

1

asContext

1

asContext

DestinationCardinality: StringCollectionType:String

PComposition

PExhibit

DestinationRole: RoleExpression: Expression

PReference

1 1

owner

One Property can be statefull or stateless at 2 different level

Activity.holdsAction.relationToAction.

action = Activity.asContext.holdsBehavior.

relationToBehavior.behavior.asAction

Action.asComposite = Action.asBehavior.asActivity

Activity.asWhole = Activity.asBehavior.asAction

1

asActivity

default

XORSplitEB

ANDJoin

ORJoin

*

event

IFExpression

Expr:String

Condition

Condition 0..1

ifInstruction

ElseInstruction

Expression:StringSubjectExpression: String

Expression

name:String

Role

0..*

operand

1

0..*

1

context

Name: StringisNullAllowed: Boolean

AnyAsmlType

AnyAsmlREFminValue: java.ObjectmaxValue: java.ObjectstdValueType: String

AnyAsmlVAL

*

Name:StringasCollection: String

AnyAsmlVAR

attribute

1

ofType

11

stdValueType = STRING, BOOLEAN, INT, FLOAT, DOUBLE, CHAR

Name:String

AnyAsmlMethod

Main

typeOfControl: String

ControlAction

emergentPropName: String[]

PlainAction

Activity

printCallLine():String

inputPar: Parameter[]

Constructor


SystemOut

1

controlledActivity

IFExpression

1

1

Expr:String

Condition

Condition 0..1

ifInstruction

ElseInstruction

*

preSystem

*

postEnv


inputPar: Parameter[]

SeamMethod

AsmLMethod

*

transition

Spec: String

AnyAsmLTransition

destination

source

1

Action

source

**

11

1

1

Name: StringType: StringText: StringTrigger: String

AsmLEvent

isEnabled: Boolean

AsmLBoundary

Event

1

*

Name: StringFuncLevel: IntOrgLevel: IntBehavior: String

Asml_Model

name: String

NameSpace

1

namespace

0..1

mainMethod

*

AnyAsmLType

globalType

Name:StringasCollection: String

AnyAsmlVAR

*

globalVar

*

globalEvent

Type: String

AsmLBoundary

*

globalBoundaryMainSystemOut

* systemOut

SeamMethod

*

method

targetMethod

Constructor*

constructor

Print(): String

Id: String

AnyAsmlElement

*

expression

Expression

Expression:StringSubjectExpression: String

Expression

Name: StringType: String

Parameter

Transition

TransitionBoundary

TransitionFork

TransitionMerge

ANDSplit

boundary

TransitionEventBased

sourcedestination

source destination

default

XORSplitEB

ANDJoin

ORJoinevent

1

*

event

postSystem

*

*

emergent

name:String

Role

0..1

operand

1

parentActivity

Name: StringType: StringText: StringTrigger: String

AsmLEvent

ClientAccount

BookingTicketsH H

ID{String}


id

PreEnv: 1|idList




ClientAccountList

0..*|cL[1]..cL[*]

ReservationBag

ClientID{String}

PreEnv: 1|userID


AsmL model(Code asml)

SEAM meta-model

ASML meta-model

SEAM model

TranslatorJavaTransformation


Translation/Transformation

Transformation 1: From Graphical SEAM (XML) to SEAM abstract syntax

tree (AST). Specification of the Model_Of_Interest

Hollon Behavior of Interest Level of Details

Transformation 2: From SEAM AST to AsmL AST

Printing out AsmL AST to the file, executable by AsmL tool.


Benefits

Verification of refinement “on the fly” Correct by construction models


Future work

Refinement verification using Asmlt. Expressions in SEAM likely to be written in some

platform-neutral language (currently written in AsmL) with the possibility to parse and translate to many platforms (asml, ocl, java, scala..) for further verification and/or simulation

Semantic bindings for model refinement are detected by the translation tool however cannot be defined automatically Automated analysis of Expression refinement together

with Property ans Behavior refinement is required QVT?


Presentation structure Theoretical problem:

There are 2 ways to look at the world – rectangular and circular. In modeling 2 semantics exist:

Actions within activity and processes Objects within data structure

Structure and Behavior are loosely-coupled. Practical problem:

Within one model of the workflow information about objects is hidden inside the actions…

Theoretical Solution: System thinking puts emphasis to the integration of these 2 aspects within one

model. If both aspects are visible on the same model ->

Definition of behavior as a state change Re-definition of property explicitly affects behavior Re-definition of behavior explicitly affects property

Practical solution: Semantic relations between behavior and structure.

Impact: Semantic of model transformation Verification

Systemic approach towards model definition

Documents

Transcript of Systemic approach towards model definition