behaviour -preserving model transformation

Behaviour-Preserving Model TransformationArend Rensink, University of TwenteIPA Spring Days, 18 April 2012

Models in Science

218 April 2012Behaviour Preserving Model Transformation

Physical world Mathematical model

explanation

prediction

description

3

Models in computer science


Software

Verification TransforationModelling

4

physicalelement

tester

local signaller

operate levelcrossing

cancel route

manipulatelockable device

operate localshunting area

manipulatederailers

manipulatemoveableelements

manipulatephysical point

manipulate localshunting area

panel

manipulateline block

operatetracks

operatelockable device

set route

operateline block

manipulatelevel crossing

operatekey-locked

point

operatederailers

occupytracks

operatemoveableelements

operatesignals

operatepoints

manipulatephysical derailer

manipulatephysical signal

manipulatephysical level

crossing

manipulatesignals

manipulatetracks

manipulatepoints

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

Use case diagram

operate pointsDescription

Interlocking System«system»

Physical elements«field»

move point <c> move pointalt alt

detected left{10}

<dv> detected leftreported left <s> point left

else alt

detected right

{10}

<dv> detected rightreported right <s> point right

end alt

move occupied point <c> move occupied pointmove trailed point <c> move trailed pointset route blocking <c> set route blockingcancel route blocking <c> remove route blocking

Sequence diagram

LCL

TVP in path

route direction-/subroute_monitoring_ok+/onward_signals_fine-/sequentially_occupied+/preceeding_tracks_free+/previous_sequentially_occupied-

TVP in main route

/change_in_occupation+/DOS_route_occupation+

TVP in shuntroute

TVP in overlap

Route locker in path

/is_main_route_locked+/is_shunt_route_locked+/is_overlap_locked+/is_locked+/is_route_body_locked+/element_correct_for_route#

Track element in path

/route_precondition_ok+/monitoring_condition_ok+locking_type+

Signal in path

/manually_replaced+/element_set_up+/path_initiated+

Flank locker in path

/is_flank_locked+/element_correct_for_flank+/is_dependency_locking+/is_dependency_locked+/dependency_active+

Signal flanking route

Lockable point in path

/point_to_move-

Point in main route

Point in shunt routePoint in overlap

Subroute signal in path

/advance_subroutes_at_proceed-

Entry signal

/reclearing+/berth_occupied+

TVP in route

not_permitted_occupied-destination_tvp-occupied_for_DOS-/TVP_marked+/moveable_element_in_DT+

Reserved path

/available+/monitoring+/immediately_cancellable+/initiated+

Track section in path

/occupied_physically+

Point in path

route position-LSA active-/point_marked+

Point flanking LSA

Signal flanking LSA

Exit signal

Point inapproach

Track in path

Flank zone

safe_direction-

Track in approach

/valid_approach_occupation+

Route

/signalling_conditions+/residual_releaseable+/cancel_with_delay+/disrupted+/train_in_route+/all_train_in_DT-/destination_release-route_type-overlap_release_timer-signal_cleared-direction-DOS_route-DOS_permitted-opposing_permitted-

Point in LSA

/is_locally_released+/local_release_suspended+

Signal in LSA

/is_cancelled+/is_cancellable+

Lockable device in path

Point flanking route

Logical line block

Opposing signal

/train_turned_back+turnback-

*

1 route

signals in path*

1rp from track elements

track elements in path

0..1 0..1routeline block for route

*

1

route from opposing signals

opposing signals

0..1 0..1

releasing

providing

1

1route from exit

exit signal

1

1route from entry

entry signal

*

1

track in activation zone

protecting point

1*assoc tvp subroute signal

*

1 route

TVPs in path

1

* provider

releaser

0..1 0..1prev next

*

1route from overlap

TVPs in overlap

1

1..*main route tvp

route from main tvps

*1

associated tvp

moveable element in route

* 1route from approach

approach track

1

0..1

device in path track from device

*

1

route

points in path

Class diagram

activebarriers

opening

closedEntry/out(type, 'id', '<s> level crossing closed');Exit/send 'physical'.'<pe> open lx';

openEntry/out(type, 'id', '<s> level crossing open');out(type, 'id', '<s> level crossing not blinking');

closingEntry/send 'physical'.'<pe> close lx';(if 'physical'.'lights_ok' then out(type, 'id', '<s> level crossing blinking'));

devicedisabledenabled

statussecured

out of useidle

detectedactivatednot activated

timer

idle running exceededEntry/say 'activation limit exceeded';

active

all tracknot activated

Entry/'all_track_activation' := #false;

activatedEntry/'all_track_activation' := #true;say 'all track activation request';

failure

non-criticalcriticaloverride

failedEntry/out(type, 'id', '<s> level crossing failed');Exit/out(type, 'id', '<s> level crossing not failed'); 'failure_overridden' := #false;not failed

Level crossing

after( 'max_activation_t ime' )/

when( in_s tate(#'active'. 'barriers '. 'open') )/

<c> failure override[not 'failure_overridden']/'failure_overridden' := #true;

when( in_state(#'active'. 'barriers '. 'opening') )/

<dv> c ross ing not failed/

/

/when( not (in_state(#'active'. 'barriers '. 'open')) )/

<c> enable level c ross ing/

/ <dv> c ross ing open/

<c> ac tivate for all tracks /

<c> deac tivate for all tracks /

/

<dv> c rossing failed c ritical/

<dv> c rossing secured/

/

<dv> c ross ing open//

/

<dv> c ross ing failed non-c ritical/

<dv> c ross ing open/

when( '/c los ing ' )/

<dv> c ross ing c losed/

<dv> cross ing out of use/

<dv> cross ing ac tivated/

<c> disable level crossing[ '/no_activation_request ']/

when( '/no_ac tivation_reques t ' )/

Level crossing/'max_activation_time' := pMaxTimer;'/crossing_enabled' := (in_state(#'active'.'device'.'enabled'));'/crossing_secured' := (in_state(#'active'.'status'.'secured'));'/vehicle_activation' := (exists 'zone from crossing' is_true ('/valid_zone_activation'));'/individual_track_request' := (exists 'activation track' is_true ('/track_activation_requested'));'/activated' := (in_state(#'active'.'detected'.'activated'));'/no_activation_request' := (not ('/individual_track_request ' or 'all_track_activation' or '/vehicle_activation' or '/train_left_zone'));'/deactivation_command_possible' := (not ('/vehicle_activation' or 'all_track_activation' or '/individual_track_request '));'/element_monitoring' := (in_state(#'active'.'status'.'out of use') or (not (in_state(#'active'.'failure'.'failed'.'critical')) and not '/activated') or (('/activated' or in_state(#'active'.'status'.'secured')) and not (in_state(#'active'.'failure'.'failed'.'critical'))));'/train_left_zone' := (exists 'level crossing in path'.'AZ from LX in path' is_true ('/train_traversed_activation_zone'));'/closing' := ('/crossing_enabled' and ('all_track_activation' or '/individual_track_request ' or '/vehicle_activation' or (exists 'level crossing in path' is_true (in_state(#'delaying'))) or exists 'zone from crossing' is_true '/activation_without_route'));

'/no_activation_request' or('/train_left_zone' and not ...

This does not take account of a disabled LX when an activation zone is occupied

Statechart

Models for software requirements and design


Behaviour Preserving Model Transformation 5

Models for software implementation

18 April 2012

Is this a model?

Is this a model?

Claim: Textual and graphical models only differ in concrete syntax Compilation is a special case of model transformation

while (x >= y) x = x – y;

x = x-yx >= y ?yes

no

6

Definition of modelling language

Definition of model transformation

Definition of language semantics

Syntax Modelling Language

Aspects of models in software development


Semanticdomain

Modelling Language

Semantics

Transfor-mation

Modelling Language

Modelling Language

7

Transfor-mation

Syntax

Semantics

Require-ments

Design

Semanticdomain

Transfor-mation Program

Semantics

Syntax Syntax

The role of models in software development



Structure of this presentation

18 April 2012

Models in Software Engineering Syntax, semantics, transformation

Graph Transformation Provides uniform framework

Behaviour preservation Observational equivalence

Examples Graph-based syntax and semantics Triple graph-based model transformation

Conclusion What you should take home

9

Graph Transformation

Formalism to capture dynamics of graph-like structures Transformation rules embody predefined changes to graphs

Aim: Provide a universal modelling framework All elements in previous slides can be formalised:

Syntax: Syntax graphs + graph grammar Transformation: Syntax graphs + transformation rules Semantics: States + operational semantics

Why graph transformation? Very powerful, widely applicable paradigm Graphs are natural for the software modelling domain

Capture the essentials of (many) discrete structures Direct capabilities for visualisation



Graphs as models

Example state graph Nodes represents objects Edges represent fields or relations between objects

Here: Circular buffer Objects inserted at the tail (last element) Objects removed from the head (first element)


Type graphs as metamodels

Compare with (UML) class diagrams Nodes stand for object types

Also supported: Node inheritance Edges stand for field/relation types

Also supported: Multiplicities


Relation between instance and type graphs

Typing is a (weak) structuring mechanism Limits node and edge labels and their interconnection May enforce presence of edges through multiplicities

State graph Type graph


Graph rewrite rules

A rule embodies a particular change to a graph Left Hand Side (LHS): should be matched in the host (source) graph Difference of Right Hand Side (RHS) and LHS defines change Negative Application Condition (NAC): should not occur in host graph

Compare to string rewriting Graph rewrite rules are context sensitive

Graph Production System: Set of rewrite rules

LHSRHS

NAC

Putting an element into a circular buffer:


Single-graph representation

blue = eraser:LHS, not RHS

to be matched and deleted

green = creator:RHS, not LHSto be added

black = reader:LHS and RHS

to be matched and preserved

red = embargo:NAC, not LHS

forbidden


forbidden

Graph productions

Rewrite rule

source graph

matching

Graph transition(labelled by rule and underlying morphism

graph morphism target graph

pushout

NACNACNACs

LHS RHSrule morphism


Example production

LHSRHS

NAC

1

1

2

3

3

2

4

4

1

3

2


Graph Transition Systems

put put

putput

getget

getget

Isomorphic state graphsare collapsed together



18 April 2012







Behaviour preservation

18 April 2012

Behaviour captured by labelled transition systems Transitions correspond to visible and invisible atomic steps Labels specify the observable changes This enables modular description: composition by product

Semantics as a mapping from modelling language to LTSs Function for language

Behaviour is preserved when LTSs are equivalent Many existing notions of equivalence Prominent: trace equivalence, simulation, bisimilarity

Model transformation as a function Correctness: is the required equivalence

20

Transfor-mation

Syntax

Semantics

Require-ments

Design

Semanticdomain

Transfor-mation Program

Semantics

Syntax Syntax

Behaviour preservation needs semantics




18 April 2012







Two laughably simple languages: Syntax

18 April 2012

Language A: Featherweight flow graphs Statements and next-arrows

Language B: Featherweight activity diagrams Actions and connectors

Type Instance

Syntax Modelling Language


Language semantics

18 April 2012

Language A: Thread-based execution

Language B: Token-based executionstart next

start next-offer next-take

Semanticdomain

Modelling Language

Semantics


Once more: Behaviour preservation

18 April 2012

Initial thought: use rule names as transition labels Does not work: rule names chosen for understandability Names for comparable activities may differ between languages For instance: A’s next does not correspond to B’s next-* actions

Refinement: allow relabelling between semantics Map actions of one language onto that of the other In LTS: make (sequences of) transitions unobservable or atomic

In this example: two possibilities Rename one of B’s next-* to next and make the other invisible Combine next-offer + next-take into single atomic action


Model transformation

18 April 2012

In general, transformation occurs between different languages In-place (endogenous) or side-by-side (exogenous) For traceability, exogenous is to be preferred

Triple graph: composition of Syntax graph of language A Syntax graph of language B Glue graph: connects A-elements with B-elements (tracing)

Triple graph grammar: builds A- and B-models + glue simultaneously Each triple graph can be projected onto source and target graph

Transfor-mation

Modelling Language

Modelling Language

A-graph B-graphGlue graph


Laughably simple triple graph grammar

18 April 2012

AB-init

AB-new-state

AB-new-next

A-graphs Glue B-graphs


Finally: Behaviour preservation

18 April 2012

For every combined graph produced by the triple graph grammar …

… if we project to the A- and B-models …

… and compute the corresponding LTS using the semantic rules …

… and apply action relabelling …

… then the LTSs are weakly bisimilar

(Full Semantics Preservation in Model Transformation –A Comparison of Proof Techniques, IFM 2010)

Semantics

Semanticdomain

Semantics

A-graph B-graphGlue graph

A-graph B-graph

𝐿𝑇 𝑆𝐴 𝐿𝑇 𝑆𝐵

𝐿𝑇 𝑆𝐴′ 𝐿𝑇 𝑆𝐵

′≈



18 April 2012







Conclusions

18 April 2012

Modelling is the new programming We should take our models more seriously

Compilation is a special case of model transformation Distinction between textual and graphical languages is artificial Learn (more) lessons from compiler construction

Behaviour preservation is a tough proof obligation Universally quantified over all models in a language Requires semantics of modelling languages Alternative: run-time verification


What you should take home

Triple graph

grammar

Graph grammar

Graph-based semantics

Require-ments

Design

Graph Transition Systems

Triple graph

grammarProgram

Graph-based semantics

Graph grammar

Graph grammar

behaviour -preserving model transformation

Documents

model transformation10graphs

model transformation8models

model transformation4models

model transformation918

model transformation12relation

model transformation7structure

model transformation5is

software development18