Model-based Software Engineering

(1)

Model-based Software Engineering

(02341, spring 2016)

Ekkart Kindler

(2)

Status and Recapitulation:

How far did we come?

(3)

Ekkart Kindler

Vision

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) { switch (featureID) {

return getObject();

}

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

}

return object;

}

(4)

Ekkart Kindler

4 MBSE (02341 f16), L09

Programming vs. SE

(5)

Ekkart Kindler

Vision

Place Transition

1 source 1 target

Arc

* PetriNet

Token

* Node

Object

}

return object;

}

return object;

}

 Domain model (or model close to

domain model L10) from which some code can be generated

 Some code needs to be implemented

manually

(6)

Ekkart Kindler

How conside are models

 With class diagrams (EMF/Ecore diagrams), some subtle aspects of some domains cannot be

appropriately modelled

 Additional constraints (OCL or programmed in Java) allow us to express these subtle aspects (more or less adequately)

6 MBSE (02341 f16), L09

(7)

Ekkart Kindler

Automatical code generation

 structural parts of the software (API)

 infrastructure (objects are notifiers) for saving and loading object structures to files (in a default format defined by the model: XMI)

 default tree editors for editing object structures

 factories for creating objects

 ...

With additional models for graphics

 Fully functioning graphical editor

(8)

Ekkart Kindler

Framework

Existing infrastructure

 adapters, observer, notifications,

 command framework, undo and redo mechanism, command framework

 MVC, many patterns behind the scene (we just scratched the surface yet)

8 MBSE (02341 f16), L09

(9)

Ekkart Kindler

Manually programming

 Some specific graphics for ePNK programmed manually  YAWL graphics

 Some technical classes (factory for specific

graphics) needed to be programmed manually

 Some constraints programmed manually

 Code for real functionality (editor is ”standard- functionality”)

 YAWL select actions

 firing YAWL transition

(10)

Ekkart Kindler

MBSE

 The goal is not to get rid of programming as such;

but, to do things an the adequate level of abstraction and in a clear and consise way

 For some things, programming is an adequate and consise way to do things (classical algorithms,

graphical appearance)

 For other things, programming is not adequate and just used for technical reasons: We want to get rid of technical artifacts

10 MBSE (02341 f16), L09

(11)

Ekkart Kindler

MBSE: Topics

 How to model behaviour (so that code can be generated)

 What is behind the scenes:

 Meta-modelling and meta-meta-modelling ( MOF)

 Domain specific languages (DSL): Methodology

 Code generation technologies

 Model-transformation

 Infrastructure (EMF and Eclipse behind the scenes)

(12)

Modelling Behaviour

(13)

Ekkart Kindler

Overview

 UML diagrams from modelling behaviour: overview

 xUML (Executable UML): short overview

 Other notations

 Story Patterns: by example

 The Event Coordination Notation (ECNO): by example

(14)

Ekkart Kindler

14 MBSE (02341 f16), L09

1. Behaviour in UML

In UML, there are different concepts and diagrams that concern behaviour modelling

 Use case diagrams

 Activity diagrams

 Interaction diagrams

 Sequence diagrams

 Communication diagrams

 State machine diagrams (State Charts)

 Methods of classes (MOF: Operation)

(in combination with OCL, the input/output relation

of a method can be specified)

(15)

Ekkart Kindler

Activity diagrams

From: OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2,

November 2007, p. 331

(16)

Ekkart Kindler

16 MBSE (02341 f16), L09

turn key

“Sequence Diagram”

rain sensor ignition

switch

wiper wiper

control

on

rain

on

off

(17)

Ekkart Kindler

”Communication Diagram”

ignition switch

rain sensor

wiper wiper

control

1: on

2: off

3: rain

4: on

(18)

Ekkart Kindler

18 MBSE (02341 f16), L09

Sequence diagram (details)

^o:Order ^{item 1} ^{product 1} ^{item 2} ^{product 2} ^:Customer

getPrice()

amount() sum1

getPrice()

amount() sum2

getCustomerDiscount() discount

Lifeline

Message

Events Events

total

(19)

Ekkart Kindler

Sequence diagram (details)

^o:Order ^{item 1} ^{product 1} ^{item 2} ^{product 2} ^:Customer

getPrice()

amount() sum1

getPrice()

amount() sum2

getCustomerDiscount() discount

Call (synchronous)

return

Self- call

total Activation

(20)

Ekkart Kindler

20 MBSE (02341 f16), L09

“State machines”

wiper control

engine off

wiper off

rd.rain/w.on rd.dry/w.off

i

rd

w Message

wiper on

on

Initial state

off

rain on

off

(21)

Ekkart Kindler

Use of state machines

ignition switch

rain sensor

wiper wiper

control

wiper

One automaton for each component

(plus structure) defines the complete

behaviour of our “wiper system”.

(22)

Ekkart Kindler

22 MBSE (02341 f16), L09

“State machines”

wiper control

engine off

wiper off i.on/w.off

i.off/w.off

rd .rain/w .on

rd .dry/ w .of f

i

rd

w

wiper on

Complex

state

(23)

Ekkart Kindler

Behaviour in UML

 Use case diagrams

 Activity diagrams

 Interaction diagrams

 Sequence diagrams

 Communication diagrams

 State machine diagrams (State Charts)

 Methods of classes

(in combination with OCL, the input/output relation

of a method can be specified)

(24)

Ekkart Kindler

Behaviour in UML

 In general, UML behaviour models are used to analyse, design, and document a system

 It is hard to generate code from that automatically.

24 MBSE (02341 f16), L09

(25)

Ekkart Kindler

2. xUML

Restricted versions of UML

 ”Domain diagram” (package diagram)

 Class diagrams for each ”domains”

 Use Case diagrams

 Sequence diagrams

 State machines (signals triggering transitions)

 Signals

 UML Action Language (ASL) for defining actions/operations on an abstract level and independent from a programming language

25 MBSE (02341 f16), L09

(26)

Ekkart Kindler

26 MBSE (02341 f16), L09

2. Other behaviour models

Just to give a rough idea of the many concepts and notations out there

 Story Pattern (”Programming in Pictures”)

 ECNO (just one idea)

 Petri nets

 Workflow languages (e.g. YAWL, BPMN)

 BPEL, WSDL

(27)

Ekkart Kindler

3. Other notations

3.1 Story diagrams

(28)

Ekkart Kindler

28 MBSE (02341 f16), L09

Example: Material Flow System

Robot

Track Shuttle

Simple Gate

Good

at occupied

1 0..1 0..1 0..1

pred

succ

(29)

Ekkart Kindler

An Instance

t1:Simple s:Shuttle

pred

occ

t2:Simple succ

at :Simple

pred succ

pred

:Simple

succ

(30)

Ekkart Kindler

30 MBSE (02341 f16), L09

Behaviour

t1:Simple s:Shuttle

pred

occ

t2:Simple succ

at

occ :Simple

pred succ

pred

:Simple succ

before

after

(31)

Ekkart Kindler

Story Pattern

t1:Simple s:Shuttle

pred

occ

t2:Simple succ

at

occ

<<delete>>

s:Shuttle occ

at

(32)

Ekkart Kindler

3.2. Event Coordination Notation

Motivation

 Given some object oriented software with (or without) explicit domain model

 Model behaviour on top of it – and make these models executable

 Model behaviour on a high level of abstraction (domain level)

 Integrate behaviour models with structural models

 Integrate different structural models (even from different technologies and without underlying models)

32 MBSE (02341 f16), L09

(33)

Ekkart Kindler

5.1 Example

Vending machine

Slot

Panel

Control

Coffee

Brewer

Output

*

Safe Coin

Tea

1

(34)

Ekkart Kindler

34 MBSE (02341 f16), L09

Instance: object diagram

: Slot

:Panel

:Control

:Coffee

:Output : Safe

:Coin

:Tea

:Coffee

:Coin

(35)

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

Coin GUI

insert ^GUI pass return_

Tea Brewer

coffee tea reset cup_in

1 Control

coffee

tea

cancel

pass

reset

(36)

Ekkart Kindler

36 MBSE (02341 f16), L09

... + 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

Coin GUI

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

(37)

Ekkart Kindler

Interactions

: Slot

:Panel

:Control

:Coffee

:Output : Safe

:Coin

:Tea :Coffee :Coin

:Coin

coffee

coffee pass

pass pass

pass

coffee: 1 pass: 1

pass: 1

coffee: 1

pass: 1

(38)

Ekkart Kindler

38 MBSE (02341 f16), L09

Interactions

: Slot

:Panel

:Control

:Coffee

:Output : Safe

:Coin

:Tea :Coffee :Coin

:Coin

coffee

coffee pass

pass pass

pass

coffee: 1 pass: 1

pass: 1

coffee: 1

pass: 1

(39)

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

(40)

Ekkart Kindler

40 MBSE (02341 f16), L09

Local behaviour: Coffee

(41)

Ekkart Kindler

Local behaviour: Coin

(42)

Ekkart Kindler

42 MBSE (02341 f16), L09

Local behaviour: Control

reset cancel coffee

pass

(43)

Ekkart Kindler

Local behaviour: Slot

reset

return

(44)

Ekkart Kindler

44 MBSE (02341 f16), L09

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

(45)

Ekkart Kindler

5.2 ECNO: Basic Concepts

 ElementTypes (Classes)

 EventTypes with

 parameters

 Global Behaviour: Coordination annotations for references

 Event type

 Quantification (1 or ALL)

 Local behaviour: ECNO nets

 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

(46)

Ekkart Kindler

ECNO: Basic Concepts

 ElementTypes (Classes)

 EventTypes with

 parameters

 Global Behaviour: Coordination annotations for references

 Event type

 Quantification (1 or ALL)

 Local behaviour: Or something else

 Event binding (with parameter assignment)

 Condition

 Action

46 MBSE (02341 f16), L09

(47)

Ekkart Kindler

Another example: 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:

for ALL incoming Arcs a:

for ONE source Place p of Arc a:

find a token

t

remove add

(48)

Ekkart Kindler

Petri net: Class Diagram

48 MBSE (02341 f16), L09

(49)

Ekkart Kindler

ECNO Semantics of PN

(50)

Ekkart Kindler

50 MBSE (02341 f16), L09

t1

t3 t2

t4

(51)

Ekkart Kindler

Conclusion

 There are many ways to model behaviour

 You need to choose the adequate way

 There are differnt ways for modelling behaviour so

that the software can be generated from it or that

models are exectued ”enacted” directly: But, this is

not ”mainstream” yet.