software engineering section: status, vision, and strategy · mapping of instances to xml syntax...

Coordinating Interactions

The Event Coordination Notation

Ekkart Kindler

Ekkart Kindler

2 Coordinating Interactions: ECNO

1. Motivation

Ekkart Kindler


MBSE: Today

Place Transition

1 source

1 target

Arc

*

PetriNet

Token

*

Node

Object

Analysis

Design

Implementation

Coding

Manifest-Version: 1.0

Bundle-ManifestVersion: 2

Bundle-Name: %pluginName

Bundle-SymbolicName: APetriNetEditorIn15Minutes.diagr

Bundle-Version: 1.0.0.qualifier

Bundle-ClassPath: .

Bundle-Activator: PetriNets.diagram.part.PetriNetDiagr

Bundle-Vendor: %providerName

Bundle-Localization: plugin

Export-Package: PetriNets.diagram.edit.parts,

PetriNets.diagram.part,

PetriNets.diagram.providers

Require-Bundle: org.eclipse.core.runtime,

org.eclipse.core.resources,

org.eclipse.core.expressions,

org.eclipse.jface,

org.eclipse.ui.ide,

org.eclipse.ui.views,

org.eclipse.ui.navigator,

org.eclipse.ui.navigator.resources,

org.eclipse.emf.ecore,

org.eclipse.emf.ecore.xmi,

org.eclipse.emf.edit.ui,

org.eclipse.gmf.runtime.emf.core,

org.eclipse.gmf.runtime.emf.commands.core,

org.eclipse.gmf.runtime.emf.ui.properties,

org.eclipse.gmf.runtime.diagram.ui,

org.eclipse.gmf.runtime.diagram.ui.properties,

org.eclipse.gmf.runtime.diagram.ui.providers,

org.eclipse.gmf.runtime.diagram.ui.providers.ide,

org.eclipse.gmf.runtime.diagram.ui.render,

org.eclipse.gmf.runtime.diagram.ui.resources.ed

org.eclipse.gmf.runtime.diagram.ui.resources.e

APetriNetEditorIn15Minutes;visibility:=reexpor

package PetriNets.impl;

public class PetriNetImpl extends EObjectImpl implements PetriNet {

protected EList<PetriNets.Object> object;

protected PetriNetImpl() {

super();

}

protected EClass eStaticClass() {

return PetriNetsPackage.Literals.PETRI_NET;

}

public EList<PetriNets.Object> getObject() {

if (object == null) {

object = new EObjectContainmentEList<PetriNets.Object>(Petri

}

return object;

}

public NotificationChain eInverseRemove(InternalEObject otherEnd, int

switch (featureID) {

case PetriNetsPackage.PETRI_NET__OBJECT:

return ((InternalEList<?>)getObject()).basicRemove(otherEn

}

return super.eInverseRemove(otherEnd, featureID, msgs);

}

public Object eGet(int featureID, boolean resolve, boolean coreType) {



return getObject();

}

return super.eGet(featureID, resolve, coreType);

Manifest-Version: 1.0

Bundle-ManifestVersion: 2

Bundle-Name: %pluginName

Bundle-SymbolicName: APetriNetEditorIn15Minutes.diagr

Bundle-Version: 1.0.0.qualifier

Bundle-ClassPath: .

Bundle-Activator: PetriNets.diagram.part.PetriNetDiagr

Bundle-Vendor: %providerName

Bundle-Localization: plugin

Export-Package: PetriNets.diagram.edit.parts,

PetriNets.diagram.part,

PetriNets.diagram.providers

Require-Bundle: org.eclipse.core.runtime,

org.eclipse.core.resources,

org.eclipse.core.expressions,

org.eclipse.jface,

org.eclipse.ui.ide,

org.eclipse.ui.views,

org.eclipse.ui.navigator,

org.eclipse.ui.navigator.resources,

org.eclipse.emf.ecore,

org.eclipse.emf.ecore.xmi,

org.eclipse.emf.edit.ui,

org.eclipse.gmf.runtime.emf.core,

org.eclipse.gmf.runtime.emf.commands.core,

org.eclipse.gmf.runtime.emf.ui.properties,

org.eclipse.gmf.runtime.diagram.ui,

org.eclipse.gmf.runtime.diagram.ui.properties,

org.eclipse.gmf.runtime.diagram.ui.providers,

org.eclipse.gmf.runtime.diagram.ui.providers.ide,

org.eclipse.gmf.runtime.diagram.ui.render,

org.eclipse.gmf.runtime.diagram.ui.resources.ed

org.eclipse.gmf.runtime.diagram.ui.resources.e

APetriNetEditorIn15Minutes;visibility:=reexpor

package PetriNets.impl;

public class PetriNetImpl extends EObjectImpl implements PetriNet {

protected EList<PetriNets.Object> object;

protected PetriNetImpl() {

super();

}

protected EClass eStaticClass() {

return PetriNetsPackage.Literals.PETRI_NET;

}

public EList<PetriNets.Object> getObject() {

if (object == null) {

object = new EObjectContainmentEList<PetriNets.Object>(Petri

}

return object;

}

public NotificationChain eInverseRemove(InternalEObject otherEnd, int



return ((InternalEList<?>)getObject()).basicRemove(otherEn

}

return super.eInverseRemove(otherEnd, featureID, msgs);

}

public Object eGet(int featureID, boolean resolve, boolean coreType) {



return getObject();

}

return super.eGet(featureID, resolve, coreType);

Ekkart Kindler


Modelling on domain level

Ekkart Kindler


“Meta model” for Petri nets (as a UML class diagram + OCL)

Domain model of PN

Petri net model

Place Transition

1 source

1 target

Arc

*

PetriNet

context Arc inv: ( self.source.oclIsKindOf(Place) and self.target.oclIsKindOf(Transition) ) or ( self.source.oclIsKindOf(Transition) and self.target.oclIsKindOf(Place) )

Token *

Object

Node name: String

Ekkart Kindler


Syntax (abstract and concrete)

:Place

:Transition

:Arc

:Transition

:Place

:Arc

:Arc

source

target source

target

target source

:Arc source target

:Petrinet

:Token

graphical / concrete syntax

abstract syntax (as an object diagram)

Ekkart Kindler


Graphical Syntax/Editor?

:Place

:Transition

:Arc

:Transition

:Place

:Arc

:Arc

source

target source

target

target source

:Arc source target

:Petrinet

:Token

Place Transition

1 source

1 target

Arc

*

PetriNet

Token *

Node

Object

model

meta model

is instance of

concrete syntax abstract syntax

Place

Transition

Arc

Token

generate an editor

Ekkart Kindler The Result


Ekkart Kindler


In the large: ePNK

Ekkart Kindler


Define a Petri Net Type

( self.source.oclIsKindOf(pnmlcoremodel::PlaceNode) and

self.target.oclIsKindOf(pnmlcoremodel::TransitionNode) )

or

( self.source.oclIsKindOf(pnmlcoremodel::TransitionNode) and

self.target.oclIsKindOf(pnmlcoremodel::PlaceNode) and

not ( self.type.text = ArcTypes::inhibit ) )

Ekkart Kindler


Program Graphics

public class InhibitornetsArcFigure extends ArcFigure {

[...]

private void setGraphics() {

RotatableDecoration targetDecorator = null;

RotatableDecoration sourceDecorator = null;

if (type.equals(ArcTypes.NORMAL)) {

targetDecorator = new ReisigsArrowHeadDecoration();

} else if (type.equals(ArcTypes.INHIBIT)) {

CircleDecoration circleDecoration =

new CircleDecoration();

circleDecoration.setLineWidth(this.getLineWidth());

targetDecorator = circleDecoration;

} else if (type.equals(ArcTypes.READ)) {

targetDecorator = new ReisigsArrowHeadDecoration();

sourceDecorator = new ReisigsArrowHeadDecoration();

[...]

Ekkart Kindler


Benefits of Modelling

Better understanding

Mapping of instances to XML syntax (XMI) (canonical exchange format for instances)

Automatic code generation for API for creating, deleting and modifying model

Methods for loading and saving models (in XMI)

Standard mechanisms for keeping track of changes (observers)

Transactional changes (ACI)

Database access / persistence (D)

Graphical editors

Ekkart Kindler e.g. a Petri net simulator?


Ekkart Kindler


Challenges

There are no notations

for modelling behaviour!

Ekkart Kindler


Challenges

Adequate modelling methodologies

Coarse grain behaviour

Fine grain behaviour

Mechanism for integrating and coordinating behaviour beyond invocation (calls of procedure, function, method, or service)

Integration with

existing software (legacy, manually created, generated)

other models (structural & behavioural)

Change mentality (change culture)

Stuck with thread- and invocation-based thinking

Software engineering is programming thinking ( model interpretation vs. code generation)

Ekkart Kindler 2. The Event Coordination Notation

Motivation

Given some object oriented software with (or without)

explicit domain model

Model the behaviour on top of it – and make these models

executable

Model behaviour on a high level of

abstraction (domain level): coordination of behaviour

Integrate behaviour models with structural models

Integrate different structural models and manually written

code (or code generated by different technologies)


Ekkart Kindler


2.1 Example: Vending machine

Slot

Panel

Control

Coffee

Brewer

Output

*

*

*

*

*

*

Safe

Coin

Tea

1

Ekkart Kindler


Instance: Object Diagram

: Slot

:Panel

:Control

:Coffee

:Output

: Safe

:Coin

:Tea

:Coffee

:Coin

:Coin

Ekkart Kindler


Coordination Diagram

Slot

insert

return_

pass

reset

Panel GUI

coffee GUI

tea GUI

cancel GUI

Coffee

Output GUI

cup_in GUI

cup_out GUI

*

cup_in: 1

coffee: 1

tea: 1

reset: ALL

coffee: 1

tea: 1

cancel: ALL

reset: ALL

pass: 1

pass: 1

*

*

*

*

insert: 1

*

return_: ALL

pass: 1

Safe

pass

GUI Coin

insert GUI

pass

return_

Tea

Brewer

coffee

tea

reset

cup_in

1

Control

coffee

tea

cancel

pass

reset

Ekkart Kindler


... + Event declaration

Slot

insert

return_

pass

reset

Panel GUI

coffee GUI

tea GUI

cancel GUI

Control

coffee

tea

cancel

pass

reset Coffee

Output GUI

cup_in GUI

cup_out GUI

*

cup_in: 1

coffee: 1

tea: 1

reset: ALL

coffee: 1

tea: 1

cancel: ALL

reset: ALL

pass: 1

pass: 1

*

*

*

*

insert: 1

*

return_: ALL

pass: 1

Safe

pass

GUI Coin

insert GUI

pass

return_

Tea

insert(Coin coin, Slot slot) coffee() pass(Coin coin, Slot slot) tea() return(Slot slot) cancel() reset_() cup_in() cup_out()

Brewer

coffee

tea

reset

cup_in

1

Ekkart Kindler


Interactions

: Slot

:Panel

:Control

:Coffee

:Output

: Safe

:Coin

:Tea

:Coffee

:Coin

:Coin

coffee

coffee

coffee

pass pass pass

pass

coffee: 1

pass: 1

pass: 1

coffee: 1

coffee: 1

pass: 1

Ekkart Kindler


Interactions

: Slot

:Panel

:Control

:Coffee

:Output

: Safe

:Coin

:Tea

:Coffee

:Coin

:Coin

coffee

coffee

coffee

pass pass pass

pass

coffee: 1

pass: 1

pass: 1 coffee: 1

pass: 1

Ekkart Kindler


Another Interaction

: Slot

:Panel

:Control

:Coffee

:Output

: Safe

:Coin

:Tea

:Coffee

:Coin

:Coin

cancel reset

reset

reset reset

return

return

cancel

reset return

reset: ALL cancel: ALL

reset: ALL

reset: ALL reset: ALL

return: ALL

return: ALL

Ekkart Kindler


Local behaviour: Coffee

Ekkart Kindler


Local behaviour: Coin

Ekkart Kindler


Local behaviour: Control

reset

cancel

coffee

pass

Ekkart Kindler


Local behaviour: Slot

reset

return

Ekkart Kindler


Interactions

: Slot

:Panel

:Control

:Coffee

:Output

: Safe

:Coin

:Tea

:Coffee

:Coin

:Coin

cancel reset

reset

reset reset

return

return

cancel

reset return

reset: ALL cancel: ALL

reset: ALL

reset: ALL reset: ALL

return: ALL

return: ALL

Ekkart Kindler 2.2 ECNO: Basic Concepts

ElementTypes (Classes)

EventTypes with

parameters

Global Behaviour: Coordination annotations for references

Event type

Quantification (1 or ALL)

Local behaviour (life-cycle): ECNO nets (or something else)

Event binding (with parameter assignment)

Condition

Action


insert(Coin coin, Slot slot)

Control

coffee

tea

cancel

pass

reset

Brewer

coffee tea

reset

cup_in

coffee: 1

tea: 1

reset: ALL

Ekkart Kindler 2.3 Extensions (cntd.)

ECNO with its basic concepts has some limitations,

which makes modelling things in an adequate way

a bit painful.

Sometimes, we want to extend event types later


Ekkart Kindler Behaviour inheritance


Ekkart Kindler Event Inheritance


Question: Would we like to have multiple inheritance

on event types?

Problems:

We could never be sure

that two event types that

were meant to be different

are different!

We would not know which

event type an instance of

subtype would represent!

Ekkart Kindler Event Extension


tea

tea_blend tea_temp

Ekkart Kindler 2.4 Example2: Petri nets


Fire Transition t:

for ALL incoming Arcs a:

for ONE source Place p of Arc a:

find a token and remove it

for ALL outgoing arcs a:

for ONE target Place p of Arc a:

add a new Token

Transition t enabled:



find a token

t

remove add

fire

Ekkart Kindler Petri net: Abstract Syntax


Ekkart Kindler Example2: Petri nets


Fire Transition t:



find a token and remove it

for ALL outgoing arcs a:

for ONE target Place p of Arc a:

add a new Token

Transition t enabled:



find a token

t

remove add

fire

Ekkart Kindler ECNO Semantics of PN


Ekkart Kindler Result


t1

t2 t3

t4

Ekkart Kindler Petri net simulator


Ekkart Kindler 3. ECNO: Semantics

Can be formalized in mathematics

(done for core concepts ECNO Technical Report)


s : Slot

:Panel

:Control

:Coffee

:Output

: Safe

:Coin

:Tea

:Coffee

:Coin

:Coin

cancel reset

reset

reset reset

return

return

cancel

reset return

reset: ALL

cancel: ALL reset: ALL

reset: ALL

reset: ALL

return: ALL

return: ALL

slot = s

Ekkart Kindler ”Meta ECNO”

The semantics of ECNO could, probably,

be expressed in ECNO itself!


Ekkart Kindler 4. Conclusion


Ekkart Kindler Next Steps


Ekkart Kindler Next Steps (cntd.)

Documentation

Database integration (e.g. Hibernate/Teneo)

GUI modelling (DSL for GUI for ECNO applications)

Better IDE support & debugger

Case studies

Efficiency / distributed execution

Standard adapters for other technologies

Methodology & education


software engineering section: status, vision, and strategy · mapping of instances to xml syntax...

Documents