1
Formal Definition and Proofs for the MechatronicUML
Allocation Specification Language
–
Technical Report
–
tr-ri-17-353
Marcus Hüwe∗ , Uwe Pohlmann†
Fraunhofer IEM
Zukunftsmeile 1, 33102 Paderborn, Germany
∗ marcus.huewe@iem.fraunhofer.de
† uwe.pohlmann@iem.fraunhofer.de
1
I NTRODUCTION
This technical report formally defines the M ECHATRONIC UML allocation specification language, specifies a transformation to an ILP, and proves the correctness of this transformation. The allocation specification language was introduced
in [1] and is implemented within the M ECHATRONIC UML Tool Suite [2] (www.
mechatronicuml.org).
2
F ORMAL P RELIMINARIES
In the following, we provide the formal preliminaries that are needed to define
the Allocation Specification Language formally.
Let M be the object model [3] that is represented by the class diagram in
Figure 1. Moreover, let σ = (σCLASS , σAT T , σASSOC ) be a system state for the
object model M . Basically, such a system state corresponds to an object diagram
(intuitively, σCLASS =
b objects, σAT T =
b attribute values, σASSOC =
b links between
objects) that is typed over the class diagram in Figure 1. Let OCL be the set of
all syntactically correct (in the context of the class OCLContext) OCL expressions.
To evaluate an OCL expression Ψ ∈ OCL, a so-called evaluation environment
is required. We assume that evalσ (Ψ) denotes the evaluation result of the OCL
expression Ψ ∈ OCL and that the evaluation environment’s system state is σ . We
usually omit the σ and simply write eval(Ψ).
Let COM P = σCLASS (ComponentInstance) be a set of M ECHATRONIC UML
component instances. Analogously, let
ECU = σCLASS (StructuredResourceInstance) be a set of M ECHATRONIC UML
[0..1]WhardwarePlatform
InstanceConfiguration
OCLContext
[0..1]Wcomponent
InstanceConfiguration
ComponentInstanceConfiguration
HWPlatformInstanceConfiguration
[1..1]WembeddedHPIC
[1..1]WparentHPIC
[0..*]W
[0..1]W
[0..*]W
[0..*]Wresources
networkingConnector hwplatform
parentHWPlatform
Instances
Instance
Instances
Networking
Structured
HWPlatformInstance
ResourceInstance
ConnectorInstance
Fig. 1. OCLContext Meta-Model
[0..*]W
portConnector
Instances
[1..1]WparentCIC
[0..*]W
component
Instances
PortConnector
Instance
ComponentInstance
/topLevel :
EBoolean = true
[1..1]WembeddedCIC
[0..1]W
parentStructured
ComponentInstance
Structured
ComponentInstance
2
ECUs. A mapping f ∈ ECU COM P := {f : COM P → ECU } is called an allocation.
Let c ∈ COM P and e ∈ ECU . Then, f (c) = e means that the component instance
c is allocated to the ECU e.
In OCL, a tuple consists of several named parts, which are used to access its
elements [3]. Listing 1 demonstrates how to create and access a tuple in OCL. The
first line defines the variable t of the type Tuple(comp : ComponentInstance, ecu :
StructuredResourceInstance). That is, the variable t is a tuple with the named parts
comp and ecu. The second line constructs a new tuple object and binds the object e
to the named part ecu and the object c to the named part comp. We assume that e
has the type StructuredResourceInstance and c has the type ComponentInstance and
both variables are available in the expression’s scope. The third line is used to
access the element that was bound to the named part comp. Thus, the whole OCL
expression in Listing 1 evaluates to the object c.
let t : Tuple(comp : ComponentInstance, ecu : StructuredResourceInstance)
= Tuple{ecu = e, comp = c}
in t.comp
Listing 1. Creating and Accessing a Tuple in OCL
Unlike a mathemetical tuple, an OCL tuple has no order. In order to interpret
an OCL tuple as a mathematical tuple, the implicit order of the named parts
from the tuple’s type definition is used. Hence, the OCL tuple t in Listing 1
corresponds to the mathematical tuple (c, e). More generally, an OCL tuple of
the type T uple(n1 : T1 , ..., nk : Tk ), where Ti is a type, is interpreted as the
mathematical tuple (n1 , ..., nk ). Furthermore, an OCL set s of the type Set(T ),
where T is a type, is considered as a mathematical set. For instance, to select an
arbitrary element e from the set s the notation e ∈ s is used.
Next, we briefly introduce the so-called 0-1-ILP problem. The 0-1-ILP problem
is defined as follows:
Given b ∈ Rm , c ∈ Rn and A ∈ Rm×n , determine x ∈ {0, 1}n such that
A·x≤b
(1)
cT · x = max{cT · x0 |A · x0 ≤ b and x0 ∈ {0, 1}n }
(2)
The m inequalities that are induced by Inequality (1) are called constraints. For
convenience, we abstract from the matrix notation and write the individual constraints as plain inequalities. Also, if an equality is needed, we directly express it
as an equality constraint instead of two inequality constraints.
3
A LLOCATION C ONSTRAINT S ATISFACTION P ROBLEM
In this section, we present how an allocation can be encoded by a 0-1-ILP. Such
an encoding is crucial for the transformation that is presented in the subsequent
section.
For each pair (c, e) ∈ COMP × ECU we introduce a binary decision variable
xc,e ∈ {0, 1}. These binary decision variables are meant to represent an allocation.
That is, xc,e = 1 indicates that component instance c is allocated to ECU e. In order
to make sure that each component instance is allocated to exactly one ECU, we
add the following constraint:
X
xc,e = 1
(3)
e∈ECU
3
for all c ∈ COM P . Let f ⊆ COMP × ECU be a binary relation such that (c, e) ∈
def.
f ⇐⇒ xc,e = 1 for c ∈ COMP and e ∈ ECU. Since the binary decision variables
should represent an allocation, we have to show that the relation f corresponds
to a mapping. For this, we show that f is left-total and right-unique.
Lemma 1. If Equation (3) holds for all c ∈ COM P , then f is left-total and right-unique.
Proof: To show that f is left-total, we have to verify the property: ∀c ∈
COMP ∃e ∈ ECU : (c, e) ∈ f . Let c ∈ COMP. Since Equation (3) holds for c, there
exists an e ∈ ECU such that xc,e = 1. Thus, (c, e) ∈ f . Consequently, f is left-total.
Next, we show that f is right-unique. That is, we have to verify the property:
∀(c, e), (c, e0 ) ∈ f : e = e0 . Let (c, e), (c, e0 ) ∈ f . Hence, xc,e = 1 and xc,e0 = 1. Due to
the fact that Equation (3) holds for c and xc,e , xc,e0 ∈ {0, 1}, it follows that e = e0 .
Consequently, f is right-unique.
From now on, if Equation (3) holds for all c ∈ COMP, then for c ∈ COMP
f (c) denotes the unique e ∈ ECU such that (c, e) ∈ f holds. That is, we treat the
relation f as a mapping from the set COM P to the set ECU and sometimes also
write f ∈ ECU COM P . Strictly speaking, the latter notation is incorrect, but it is
justified since the set of left-total and right-unique relations on COM P × ECU is
isomorphic to the set ECU COM P (isomorphic in the set-theoretic sense).
In order to transform language elements like the requiredLocation constraint,
which will be defined later, we have to express more advanced dependencies
such as component instance c1 is allocated to ECU e1 and component instance c2 is
allocated to ECU e2 . To support this, we introduce new binary decision variables
and inequalities, which are based on concepts that are presented in [4, p. 81]. Let
c1 , . . . , cl ∈ COMP, e1 , . . . , el ∈ ECU (l ≥ 2). To express that c1 is allocated to
e1 and . . . and cl is allocated to el , we introduce a new binary decision variable
xc1 ,e1 ,...,cl ,el ∈ {0, 1}. The idea is that this variable takes the value 1 if and only
if c1 is allocated to e1 and . . . and cl is allocated to el . To achieve this, we have
to couple it with the previously introduced binary decision variables. Hence, we
add the following inequalities
∀i = 1, . . . , l : xc1 ,e1 ,...,cl ,el ≤ xci ,ei
l
X
xci ,ei ≤ l − 1 + xc1 ,e1 ,...,cl ,el
(4)
(5)
i=1
The following lemma guarantees that the newly added binary decision variable exhibits the desired semantics.
Lemma 2. Let l ≥ 2 and c1 , . . . , cl ∈ COMP and e1 , . . . , el ∈ ECU. If Inequality (4)
and Inequality (5) hold then,
xc1 ,e1 ,...cl ,el = 1 ⇐⇒ ∀i = 1, . . . , l : (ci , ei ) ∈ f
Proof: xc1 ,e1 ,...,cl ,el = 1 implies xci ,ei = 1 for i = 1, . . . , l (due to Inequality (4)). By definition of f , we have (ci , ei ) ∈ f for i = 1, . . . , l.
Conversely, assume ∀i = 1, . . . , l : (ci , ei ) ∈ f . By definition ofPf , we have
xci ,ei = 1 for i = 1, . . . , l. Since Inequality (5) holds, we have l = li=1 xci ,ei ≤
l − 1 + xc1 ,e1 ,...,cl ,el ⇐⇒ 1 ≤ xc1 ,e1 ,...,cl ,el . Consequently, xc1 ,e1 ,...,cl ,el = 1.
The following corollary is a direct consequence of Lemma 1 and Lemma 2.
4
Corollary 1. Let l ≥ 2 and c1 , . . . , cl ∈ COMP and e1 , . . . , cl ∈ ECU. If Inequality (4)
and Inequality (5) hold and ∀c ∈ COMP : Equation (3) holds, then
xc1 ,e1 ,...cl ,el = 1 ⇐⇒ ∀i = 1, . . . , l : f (ci ) = ei
4
A LLOCATION C ONSTRAINTS
AND THEIR
T RANSFORMATION
TO AN
ILP
Next, we define the notion of a M ECHATRONIC UML allocation specification language constraint. Formally, a constraint Φ is represented by a 3-tuple
(Φkind , ΦOCLT , ΦOCLE ). The first element Φkind ∈ {collocation, separateLocation,
requiredLocation, requiredResource} represents the kind of the constraint. The
second element ΦOCLT represents an OCL type. The third element ΦOCLE ∈ OCL
represents an OCL expression, whose OCL type conforms to ΦOCLT .
In the following, we define the formal semantics of the individual constraint
kinds and describe their transformation to integer linear program constraints.
Moreover, we prove the correctness of these transformations. Note that the semantics of the constraint kinds do not depend on the transformations to an ILP.
From now on, we assume that Equation (3) holds for all c ∈ COMP and for
all binary decision variables of the form xc1 ,e1 ,...,cl ,el (l ≥ 2) the corresponding
Inequalities (4), (5) hold. Hence, the premises for Corollary 1 are satisfied.
4.1
Collocation Constraint
The collocation constraint Φ is defined as
•
•
•
Φkind = collocation
ΦOCLT = Set(T uple(c1 : ComponentInstance, c2 : ComponentInstance))
ΦOCLE ∈ OCL
The set of feasible allocations FΦ ⊆ ECU COM P is defined as:
def.
fˆ ∈ FΦ ⇐⇒ ∀(c1 , c2 ) ∈ eval(ΦOCLE ) : fˆ(c1 ) = fˆ(c2 )
Proposition 1. Let Φ be a collocation constraint.
X
xc1 ,e,c2 ,e = 1) ⇐⇒ f ∈ FΦ
(∀(c1 , c2 ) ∈ eval(ΦOCLE ) :
e∈ECU
Proof:
∀(c1 , c2 ) ∈eval(ΦOCLE ) :
X
xc1 ,e,c2 ,e = 1
e∈ECU
⇐⇒ ∀(c1 , c2 ) ∈ eval(ΦOCLE ) ∃!e ∈ ECU : xc1 ,e,c2 ,e = 1
Corollary 1
⇐⇒
∀(c1 , c2 ) ∈ eval(ΦOCLE )∃!e ∈ ECU : f (c1 ) = e and f (c2 ) = e
⇐⇒ f ∈ FΦ
5
4.2
Separate Location Constraint
The separateLocation constraint Φ is defined as
•
•
•
Φkind = separateLocation
ΦOCLT = Set(T uple(c1 : ComponentInstance, c2 : ComponentInstance))
ΦOCLE ∈ OCL
The set of feasible allocations FΦ ⊆ ECU COM P is defined as:
def.
fˆ ∈ FΦ ⇐⇒ ∀(c1 , c2 ) ∈ eval(ΦOCLE ) : fˆ(c1 ) 6= fˆ(c2 )
Proposition 2. Let Φ be separateLocation constraint.
X
(∀(c1 , c2 ) ∈ eval(ΦOCLE ) :
xc1 ,e,c2 ,e = 0) ⇐⇒ f ∈ FΦ
e∈ECU
Proof:
∀(c1 , c2 ) ∈eval(ΦOCLE ) :
X
xc1 ,e,c2 ,e = 0
e∈ECU
⇐⇒ ∀(c1 , c2 ) ∈ eval(ΦOCLE ) ∀e ∈ ECU : xc1 ,e,c2 ,e2 = 0
Equation (3)
⇐⇒
∀(c1 , c2 ) ∈ eval(ΦOCLE ) ∃!e1 , e2 ∈ ECU, e1 6= e2 :
xc1 ,e1 ,c2 ,e2 = 1
Corollary 1
⇐⇒
∀(c1 , c2 ) ∈ eval(ΦOCLE ) ∃!e1 , e2 ∈ ECU, e1 6= e2 :
f (c1 ) = e1 and f (c2 ) = e2
⇐⇒ ∀(c1 , c2 ) ∈ eval(ΦOCLE ) : f (c1 ) 6= f (c2 )
⇐⇒ f ∈ FΦ
4.3
Required Location Constraint
The requiredLocation constraint Φ is defined as
•
•
•
Φkind = requiredLocation
ΦOCLT = Set(T uple(c1 : ComponentInstance,
e1 : StructuredResourceInstance, . . . , cn : ComponentInstance,
en : StructuredResourceInstance))
ΦOCLE ∈ OCL
Let ∼ be a binary relation on the set eval(ΦOCLE ) such that
(c1 , e1 , c2 , e2 , . . . , cn , en ) ∼(c01 , e01 , c02 , e02 , . . . c0n , e0n )
def.
⇐⇒ {c1 , c2 , . . . , cn } = {c01 , c02 , . . . , c0n }
Obviously, ∼ is an equivalence relation. The set Q := eval(ΦOCLE ) /∼ denotes the
quotient set, which is the set of equivalence classes. The set of feasible allocations
FΦ ⊆ ECU COM P is defined as:
def.
fˆ ∈ FΦ ⇐⇒ ∀x ∈ Q :
_
(c1 ,e1 ,...,cn ,en )∈x
fˆ(c1 ) = e1 ∧ fˆ(c2 ) = e2 ∧ . . . ∧ fˆ(cn ) = en
6
Proposition 3. Let Φ be a requiredLocation constraint.
X
(∀x ∈ Q :
xc1 ,e1 ,...,cn ,en ≥ 1) ⇐⇒ f ∈ FΦ
(c1 ,e1 ,...,cn ,en )∈x
Proof: Let x ∈ Q.
X
xc1 ,e1 ,...,cn ,en ≥ 1
(c1 ,e1 ,...,cn ,en )∈x
⇐⇒ ∃(c1 , e1 , . . . , cn , en ) ∈ x : xc1 ,e1 ,...,cn ,en = 1
Corollary 1
⇐⇒
⇐⇒
∃(c1 , e1 , . . . , cn , en ) ∈ x : f (c1 ) = e1 ∧ . . . ∧ f (cn ) = en
_
f (c1 ) = e1 ∧ f (c2 ) = e2 ∧ . . . ∧ f (cn ) = en
(c1 ,e1 ,...,cn ,en )∈x
Since x ∈ Q was arbitrary, the proposition follows.
4.4
Required Resource Constraint
The requiredResource constraint Φ is defined as
•
•
•
Φkind = requiredResource
ΦOCLT = Set(T uple(r : Real, w : Set(T uple(
c1 : ComponentInstance,
e1 : StructuredResourceInstance, . . . ,
cn : ComponentInstance,
en : StructuredResourceInstance, w0 : Real))))
ΦOCLE ∈ OCL
The set of feasible allocations FΦ ⊆ ECU COM P is defined as:
def.
fˆ ∈ FΦ ⇐⇒ ∀(r, w) ∈ eval(ΦOCLE ) :
X
w0 x(fˆ, c1 , e1 , . . . , cn , en ) ≤ r
(c1 ,e1 ,...,cn ,en ,w0 )∈w
, where
(
x(fˆ, c1 , e1 , . . . , cn , en ) :=
1
0
if fˆ(c1 ) = e1 ∧ . . . ∧ fˆ(cn ) = en
else
Proposition 4. Let Φ be a requiredResource constraint.
X
(∀(r, w) ∈ eval(ΦOCLE ) :
w0 · xc1 ,e1 ,...,cn ,en ≤ r) ⇐⇒ f ∈ FΦ
(c1 ,e1 ,...,cn ,en ,w0 )∈w
Proof: Let (r, w) ∈ eval(ΦOCLE ).
X
w0 · xc1 ,e1 ,...,cn ,en ≤ r
(c1 ,e1 ,...,cn ,en ,w0 )∈w
Corollary 1
⇐⇒
X
w0 · x(f, c1 , e1 , . . . , cn , en ) ≤ r
(c1 ,e1 ,...,cn ,en ,w0 )∈w
Since (r, w) ∈ eval(ΦOCLE ) was arbitrary, the proposition follows.
(6)
7
4.5
Multiple Constraints
Let C be a set of constraints of the previously defined
kinds. The set of feasible
T
allocations FC ⊆ ECU COM P is defined as FC := Φ∈C FΦ . It is straightforward
to see that a set of constraints can be transformed to an ILP by transforming each
individual constraint as described in the previous paragraphs. This results in the
following proposition.
Proposition 5. Let C be a set of constraints. f ∈ FC if and only if
•
•
•
•
•
5
AN
each collocation constraint in C is transformed according to Proposition 1
each separateLocation constraint in C is transformed according to Proposition 2
each requiredLocation constraint in C is transformed according to Proposition 3
each requiredResource constraint in C is transformed according to Proposition 4
and all equalities and inequalities hold
A LLOCATION O PTIMIZATION C RITERIA
ILP
AND ITS
T RANSFORMATION
TO
In this section, we discuss an extension of the language that takes optimization
into account. In essence, we present how to specify a single objective function
that is to be minimized or maximized (depending on the optimization goal).
In the following, this single objective function is called the measure function.
The measure function itself is composed of several services. A service can be
understood as a certain entity of the software system to which several component
instances belong. For instance, the communication between a set of component
instances can be viewed as a service. Each service consists of arbitrary many socalled quality of service dimensions (QoS dimensions), which rate service specific
quality goals. QoS dimensions for a communication service are, for instance,
reliability and latency.
In the remainder, we formally define the notion of a measure function, service,
and QoS dimension.
5.1
QoS Dimension
A QoS dimension q is represented by a 2-tuple (qOCLT , qOCLE ):
•
•
qOCLT = Set(T uple(
c1 : ComponentInstance, e2 : StructuredResourceInstance, . . . ,
cn : ComponentInstance, en : StructuredResourceInstance, w : Real))
qOCLE ∈ OCL
Let fˆ ∈ ECU COM P and q be a QoS dimension. Next, we define
X
sum(fˆ, q) :=
wx(fˆ, c1 , e1 , . . . , cn , en )
(c1 ,e1 ,...,cn ,en ,w)∈eval(qOCLE )
, where x is defined as in Equation (6).
5.2
Service
A service S is defined as a set of QoS dimensions.
8
5.3
Measure Function
ˆ
Let f ∈ ECU COM P and SERVICES be a set of services. The measure function m is
defined as follows:
X
X
m(fˆ) :=
sum(fˆ, q)
S∈SERVICES q∈S
The measure function can be directly transformed to a linear objective function
of an ILP as follows:
X
X
X
(7)
w · xc1 ,e1 ,...,cnq ,enq
S∈SERVICES q∈S (c1 ,e1 ,...,cnq ,enq ,w)∈eval(qOCLE )
6
A LLOCATION S PECIFICATION
An allocation specification is used to describe all constraints, the measure function, and the optimization goal. Formally, an allocation specification α is a 3-tuple
(Cα , mα , θα ), where
•
•
•
6.1
Cα is a set of constraints
mα is a measure function
θα ∈ {≤, ≥} is a comparison operator and represents the optimization goal.
That is if θα =≤, then
mα is minimized, else mα is maximized.
Feasible and Optimal Allocation Specification
Finally, we define a set that consists of feasible and optimal, with regard to an
allocation specification, allocations. Let α be an allocation specification. The set
OP Tα := {fˆ ∈ FCα | ∀f 0 ∈ FCα : mα (fˆ) θα mα (f 0 )}
is the set of feasible, with regard to the constraints in Cα , and optimal, with regard
to the measure function mα , allocations.
Proposition 6. Let α be an allocation specification. f ∈ OP Tα if and only if all constraints are transformed according to Proposition 5, the measure function is transformed
as in (7), and, all equalities and inequalities hold.
R EFERENCES
[1] U. Pohlmann and M. Hüwe, “Model-driven allocation engineering (t),” in Automated Software
Engineering (ASE), 2015 30th IEEE/ACM International Conference on, Nov 2015, pp. 374–384.
[2] S. Dziwok, C. Gerking, S. Becker, S. Thiele, C. Heinzemann, and U. Pohlmann, “A tool suite
for the model-driven software engineering of cyber-physical systems,” in Proceedings of the 22Nd
ACM SIGSOFT International Symposium on Foundations of Software Engineering, ser. FSE ’14. New
York, USA: ACM, 2014, pp. 715–718.
[3] OMG OCL, Object Constraint Language (OCL), 2014. [Online]. Available: http://www.omg.org/
spec/OCL/2.4/PDF/
[4] S. Malek, N. Medvidovic, and M. Mikic-Rakic, “An extensible framework for improving a
distributed software system’s deployment architecture,” Software Engineering, IEEE Transactions
on, vol. 38, no. 1, pp. 73–100, Jan 2012.