model transformation units – towards a unified logistics ...padberg/workshops/gratr… · the...

Graph Transformation Day +++ 10 February 2017 +++ Hamburg

Model Transformation Units – Towards a Unified

Logistics Modeling Language Hans-Jörg Kreowski

in close cooperation with Sabine Kuske and Caro von Totth

logistic aspects in cooperation within the Bremen Research Cluster for Dynamics in Logistics


Mobile Phone Standards

Mobile Data Transfer

Networking Technology

Transponder Technology

Terminal Technology

Positioning Systems

Handling Technology

Loading and Transit Equipment

Transportation Technology

Machine Learning

Telematics Interoperability

Network Security

the World of Logistics


Delivery Production Distribution

process runs information flow material flow organisational structure layout structure carriers

requirements simulation design optimization realization verification

i* KAOS AMLP EPC BPMN BPEL CMSD UML

logistic system

views

levels of concern

modeling methods


Modeling Problem of Logistics

logistic systems may combine many processes and further components employing various technologies and various modeling methods and languages

How can one descibe heterogeneous logistic models combining many components of different types specified by means of different modeling techniques?

How can one deal with them in a systematic way?



In the domain of production many communication technology oriented efforts are under way towards networked production like Industry 4.0, Internet of Things or Cyber-Physical Systems

analogous efforts are lacking in process-oriented modeling of such systems

Seiger et al. define six requirements for process-oriented modeling concepts: dynamics, heterogeneity, complexity, parallelism, evolution, and distribution



The goal is to create an analogue to the

Unified Modeling Language (UML) in combination with the Object Constraint Language (OCL) and the Query/View/Transformation concept (QVT), which serves as a quasi-standard in software engineering and subsumes several modeling techniques

This analogue is called LogisticsML


Levels of Concern

The language should allow one to model dynamic logistic systems on various levels of concern including at least the requirement definition and the design.

Moreover, means should be provided to assure the compatibility of the models of a system on different levels.

design

requirements

compatibility

analogously for intermediate levels and the realization

1st Objective for LogisticsML


producer BPMN

trader BPMN

consumer BPMN

2nd Objective for LogisticsML Composition and Interoperability

The language should allow for modeling a logistic system in a structured and modular way such that the components can be composed to interoperate properly with each other even if their specifications employ different modeling methods.

In particular, the language should comprise a spectrum of modeling methods.


Composition and Interoperability



producer BPMN

trader BPMN

consumer BPMN

pool

2nd Objective for LogisticsML


Composition and Interoperability



producer BPMN

trader Petri Net

consumer UML

???

2nd Objective for LogisticsML


UML/OCL

SQL

Logistics ML

Petri Nets OWL

EDIFACT

WSD

BPMN

abstract models

conceptual models

executable models

general modeling and

meta-modeling

domain- specific

modeling

application- specific

modeling

Multiagents Systems Verification

Engine

Simulation

AMPL

UML Profile

Web Services

OSGi

EPC

Graph Transform-ation


Domain-specific Views The language should make it possible to look at a logistic system from different domain-specific points of view in such a way that the further development of a specific view is properly reflected in the overall system.

information flow material flow

logistic system

organisation ...

3rd Objective for LogisticsML


Model Transformation

The language should provide means of model transformation between different levels of concern, between models on the same level of abstraction, but specified by different modeling methods, and from the whole system to domain-specific views.

design

requirements

compatibility

component 1 method 1


???

view 2 view 1

logistic system

...

4th Objective for LogisticsML


Model Transformation The language should provide means of model transformation between different levels of concern, between models on the same level of abstraction, but specified by different modeling methods, and from the whole system to domain-specific views.

design

requirements component 1 method 1


view 2 view 1

logistic system

... m

transform 1

transform 2

model transformation

method with composition

4th Objective for LogisticsML

+


initialization

action application due to control condition

terminalization

terminal? NO

YES

input model

initial working model

working model

working model

terminal working model

output model

transformation

schema of a model transformation

modeling method 1

modeling method 2

modeling method coupling 1 and 2


(heteogeneous) logistic models Let L be a collection of modeling methods and languages

and let D be a collection of data domains (data types).

Then a logistic model mod of type T is

! mod ∈L for some L ∈ L with type(mod) = L,

! mod ∈D for some D ∈ D with type(mod) = D,

! a tuple mod=(mod1, ... ,modk) for some k ∈ℕ with type(mod) = T1 × ... × Tk if modi of type Ti, i=1, ... ,k

The set of all models of type T is denoted by M(T).

note: all models are tuples if we set mod = (mod)


constraint types T with x is a constraint type if T is a type and x is a property (constraint) for models of type T.

M(T with x) denotes the models of type T with property x

constraints can be Boolean expressions or tests and predicates in some logic and

they can be combined by Boolean operators

M(T) =M(T with true)


model transformation units

a model transformation unit is a system

mtu=(ITD,OTD,WT,A,C) where

• WT = T1 ×…. × Tk is the working type, • A is a set of actions on WT, • C is a control condition, • ITD is the input type declaration • OTD is the output type declaration


model transformation units (cont`d) each action has the form a=(op1, ….,opk) with z where

opi ∈OPTi for i=1, ….,k and z is a constraint, assuming operations OPT for each type T

a control condition regulates the application of actions

the input type declaration ITD consists of an input type IT=I1 × …. × Im with x and an initialization initial associating Ti with some Ij or with a fixed model of type Ti,

the output type declaration OTD consists of an output type OT=O1 × …. × On with y and a terminalization terminal associating each Oj with some Ti.


… for example

Petri net

BPMNlight

BPMNlight-to-PN

Petri Nets


… for example

Petri Net

BPMNlight

BPMNlight-to-PN

add

for each flow object f

add

for each sequence flow f f´

multiply

tf pf tf

tf tf´ pf

tf t xor/end

Petri Nets


BPMNlight -to-PN

input: BPMNlight working: BPMNlight × PN initial: BPMNlight ➼ BPMNlight & PN ➼∅ actions: act(f) = (mark(f), add(f)) act(f ➔ f‘) = (mark(f ➔ f‘), add(f ➔ f‘) for f, f‘∈ID control: act(f) > act (f ➔ f‘) & act (f’) > act(f ➔ f‘) & as long as possible output: PN terminal: PN ➼ PN


The model transformation specified by mtu is a relation SEM(mtu) : M( I1×⋯×Im with x ) ⟶ M( O1×⋯×On with y )

defined by M( I1×⋯×Im with x )

initial

M(T1×⋯×Tk) ⟹ M(T1×⋯×Tk)

terminal

M( O1×⋯×On with y ) output constraint must be obeyed

Model Transformation Unit Semantics

* A,C


24

SAT3-2-INDEP

(X,F) with X∈set(ID) & F∈set(3-set(X+neg(X)) & finite X, F

((gr(X,F)=(V(X,F),E(X,F)),#F) with V(X,F)= …..

models are tuples with components being strings, sets, symbols, numbers, tuples, …. …. and graphs, the tuples are restricted by constraints,

their transformations are constructions on the components, computations are required,

input types may be different from output types, transformation may need intermediate working types.


25

SAT3-2-INDEP

(X,F) ∈ CNF3 = set(ID)×set(3-set(X+neg(X))

with finite X, F

Gundir(ID) × ℕ

input:

output:

working type: (X,F,G,k) ∈ input × output initialize: 1 ⟶ 1 & 2 ⟶ 2 & 3: G=empty graph & 4:k=0 actions: clause = (―, rem({x,y,z},F),addclause,succ(k)) contradict = (―, ―, addcontradiction,―) control: clause! ; contradict! terminalize: 3 ⟶ 1 & 4 ⟶ 2


26

Correctness of Model Transformation Units

SAT3-2-INDEP

CNF3

Gundir(ID) × ℕ choose&check

assign&eval

BOOL =

requires interaction of some units


Conclusion first steps towards a comprehensive approach to the modeling and model transformation of heterogeneous logistic models

vision of a common wideranging logistic modeling and transformation language like the successful UML and QVT in software engineering (avoiding their drawbacks)

first draft of LogisticsML to be released soon (hopefully!)


thank you

model transformation units – towards a unified logistics ...padberg/workshops/gratr… · the...

Documents