model-based software engineering (02341) · what are good process models (2) whatever happend in...

Model-based Software Engineering

(02341, spring 2017)

Ekkart Kindler

Ekkart Kindler Lecture 8: Overview (cntd.)

Some hints for the implementation

Auxiliary datatypes and functions

Helpful ePNK functions

Marking algorithm (OR-join: potentially arriving tokens)

Hints on writing (Project Definiton / Final Report)

DSL discussion revisited

2 MBSE (02341 f17), L09

Hints on writing

Ekkart Kindler

Inductive writing:

Explain concepts by examples first

Then extract concepts and explain in more detail

Fill in more detailed concepts and explanations later

”Spiral form writing”:

Identify most important concepts (3-5):

explain them first (on high level of abstraction)

Idendify next most important concepts:

explain first and next important concepts (in more

detail), ...

4 MBSE (02341 f17), L09

DSL discussion continued

Ekkart Kindler Steps of defining a DSL

1. Define language concepts (abstract syntax):

2. Define graphical representation (concrete syntax):

6 MBSE (02341 f17), L09

Place Transition

1 source

1 target

Arc

*

PetriNet

Token *

Node

Object

Place

Transition

Arc

Token

Ekkart Kindler Steps of defining a DSL

3. Define semantics (its meaning or behaviour):

a) Define runtime concepts

b) Define presentation of runtime concepts

c) Define logic for behaviour

7 MBSE (02341 f17), L09

Ekkart Kindler Project example

YAWL concepts and representation:

8 MBSE (02341 f17), L09

Ekkart Kindler Project example

YAWL Simulator: Runtime concepts

9 MBSE (02341 f17), L09

Status and Recapitulation:

How far did we come?

Ekkart Kindler

11 MBSE (02341 f17), L09

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) {



return getObject();

}

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






Bundle-ClassPath: .










org.eclipse.jface,

org.eclipse.ui.ide,






















super();

}



}




}

return object;

}





}


}




return getObject();

}


Ekkart Kindler

12 MBSE (02341 f17), L09

Programming vs. SE

Ekkart Kindler

13 MBSE (02341 f17), L09

Vision

Place Transition

1 source

1 target

Arc

*

PetriNet

Token

*

Node

Object






Bundle-ClassPath: .










org.eclipse.jface,

org.eclipse.ui.ide,






















super();

}



}




}

return object;

}





}


}




return getObject();

}







Bundle-ClassPath: .










org.eclipse.jface,

org.eclipse.ui.ide,






















super();

}



}




}

return object;

}





}


}




return getObject();

}


Domain model from which some code

can be generated

Some code needs to be implemented

manually

Ekkart Kindler How concise 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)

14 MBSE (02341 f17), L09

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

15 MBSE (02341 f17), L09

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)

16 MBSE (02341 f17), L09

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

17 MBSE (02341 f17), L09

Ekkart Kindler MBSE

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

but, to do things on the adequate level of abstraction

and in a clear and consise way

For some things, programming is an adequate and

consise way of doing 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

18 MBSE (02341 f17), L09

Architecture by Example:

ePNK Applications

Ekkart Kindler

20 MBSE (02341 f17), L09

Ekkart Kindler YAWL Simulator annotations

21 MBSE (02341 f17), L09

Ekkart Kindler Blackboard Discussion

Based on object diagram from slide 9

(and using some classes from slide 10):

Scenario for starting the YAWL simulator BB

Scenario for firing a YAWL transition BB

22 MBSE (02341 f17), L09

Modelling Behaviour

Ekkart Kindler Overview

Modelling behaviour on domain level

Business process modelling

YAWL models

Activity diagrams ( UML)

UML diagrams from modelling behaviour: overview

xUML (Executable UML): short overview

Other notations

Story Patterns: by example

The Event Coordination Notation (ECNO): by example 24 MBSE (02341 f17), L09

Ekkart Kindler 1. BPM / YAWL

25 MBSE (02341 f17), L09

Ekkart Kindler What are good process models (1)

Have a goal (litmus test: name / description)

Have a start and an end

Tasks have a good name: verb object

e.g. register customer, pay bill, cancel appointment,

...

Possible order of execution of tasks makes sense

from the domain point of view

26 MBSE (02341 f17), L09

Ekkart Kindler What are good process models (2)

Whatever happend in the process, it is always

possible to finish the process

When the process is finished, nothing is left in the

process anymore and no task can be executed

anymore

27 MBSE (02341 f17), L09

Ekkart Kindler

28 MBSE (02341 f17), L09

2. 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)

Ekkart Kindler

29 MBSE (02341 f17), L09

Activity diagrams

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

November 2007, p. 331

Ekkart Kindler

30 MBSE (02341 f17), L09

Activity diagrams



Ekkart Kindler

31 MBSE (02341 f17), L09

Activity diagrams



Ekkart Kindler

32 MBSE (02341 f17), L09

turn key

“Sequence Diagram”

rain

sensor

ignition

switch wiper wiper

control

on

rain

on

off

Ekkart Kindler

33 MBSE (02341 f17), L09

”Communication Diagram”

ignition

switch

rain

sensor

wiper

wiper

control

1: on 2: off

3: rain

4: on

Ekkart Kindler

34 MBSE (02341 f17), L09

Sequence diagram (details)

o:Order item 1 item 2 product 1 product 2 :Customer

getPrice() getPrice()

getPrice()

amount()

sum1


amount()

sum2

getCustomerDiscount()

discount

Lifeline

Message

Events Events

total

Ekkart Kindler

35 MBSE (02341 f17), L09

Sequence diagram (details)

o:Order item 1 item 2 product 1 product 2 :Customer


getPrice()

amount()

sum1


amount()

sum2

getCustomerDiscount()

discount

Call (synchronous)

return

Self-

call

total Activation

Ekkart Kindler

36 MBSE (02341 f17), 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

Ekkart Kindler

37 MBSE (02341 f17), L09

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

Ekkart Kindler

38 MBSE (02341 f17), L09

“State machines”

wiper

control

engine

off

wiper

off

i.on/w.off

i.off/w.off

rd.ra

in/w

.on

rd.d

ry/w

.off

i

rd

w

wiper

on

Complex

state

Ekkart Kindler

39 MBSE (02341 f17), L09

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)

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.

40 MBSE (02341 f17), L09

Ekkart Kindler 3. xUML

Restricted versions of UML

”Domain diagram” (package diagram)

Class diagrams for each ”domain”

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

41 MBSE (02341 f17), L09

Ekkart Kindler

TBC (to be continued)

42 MBSE (02341 f17), L09

model-based software engineering (02341) · what are good process models (2) whatever happend in...

Documents