TY - GEN
T1 - System evolution by migration coordination
AU - Andova, S.
AU - Groenewegen, L.P.J.
AU - Vink, de, E.P.
PY - 2008
Y1 - 2008
N2 - Collaborations between components can bemodeled in the coordination language Paradigm[3]. A collaboration solution is specified by loosely coupling component dynamics to a protocol via their roles. Not only regular, foreseen collaboration can be specified, originally unforeseen collaboration can be modeled too [4]. To explain how, we first look very briefly at Paradigm’s regular coordination specification.
Component dynamics are expressed by state-transition diagrams (STDs), see Figure
1(a) for a mock-up STD MU in UML style. MU contributes to a collaboration via
a role MU(R). Figure 1(b) specifies MU(R) through a different STD, whose states are
so-called phases of MU: temporarily valid, dynamic constraints imposed on MU. The
figure mentions four such phases, Clock, Anti, Inter and Small. Figure 1(c) couplesMU
and MU(R). It specifies each phase as part of MU, additionally decorated with one or
more polygons grouping some states of a phase. Polygons visualize so-called traps: a
trap, once entered, cannot be left as long as the phase remains the valid constraint. A
trap having been entered, serves as a guard for a phase change. Therefore, traps label
transitions in a role STD, cf. Figure 1(b).
Single steps from different roles, are synchronized into one protocol step. A protocol
step can be coupled to one detailed step of a so-called manager component, driving
the protocol. Meanwhile, local variables can be updated. It is through a consistency
rule, Paradigm specifies a protocol step: (i) at the left-hand side of a ?? the one, driving
manager step is given, if relevant; (ii) the right-hand side lists the role steps being synchronized;
(iii) optionally, a change clause [2] can be given updating variables, e.g. one
containing the current set of consistency rules. For example, a consistency rule without
change clause,
MU2:A!B ?? MU1(R):Clock triv
! Anti, MU3(R): Inter toSmall
! Small
where a manager step ofMU2 is coupled to the swapping ofMU1 from circling clockwise
to anti-clock-wise and swapping MU3 from intermediate inspection into circling
on a smaller scale.
AB - Collaborations between components can bemodeled in the coordination language Paradigm[3]. A collaboration solution is specified by loosely coupling component dynamics to a protocol via their roles. Not only regular, foreseen collaboration can be specified, originally unforeseen collaboration can be modeled too [4]. To explain how, we first look very briefly at Paradigm’s regular coordination specification.
Component dynamics are expressed by state-transition diagrams (STDs), see Figure
1(a) for a mock-up STD MU in UML style. MU contributes to a collaboration via
a role MU(R). Figure 1(b) specifies MU(R) through a different STD, whose states are
so-called phases of MU: temporarily valid, dynamic constraints imposed on MU. The
figure mentions four such phases, Clock, Anti, Inter and Small. Figure 1(c) couplesMU
and MU(R). It specifies each phase as part of MU, additionally decorated with one or
more polygons grouping some states of a phase. Polygons visualize so-called traps: a
trap, once entered, cannot be left as long as the phase remains the valid constraint. A
trap having been entered, serves as a guard for a phase change. Therefore, traps label
transitions in a role STD, cf. Figure 1(b).
Single steps from different roles, are synchronized into one protocol step. A protocol
step can be coupled to one detailed step of a so-called manager component, driving
the protocol. Meanwhile, local variables can be updated. It is through a consistency
rule, Paradigm specifies a protocol step: (i) at the left-hand side of a ?? the one, driving
manager step is given, if relevant; (ii) the right-hand side lists the role steps being synchronized;
(iii) optionally, a change clause [2] can be given updating variables, e.g. one
containing the current set of consistency rules. For example, a consistency rule without
change clause,
MU2:A!B ?? MU1(R):Clock triv
! Anti, MU3(R): Inter toSmall
! Small
where a manager step ofMU2 is coupled to the swapping ofMU1 from circling clockwise
to anti-clock-wise and swapping MU3 from intermediate inspection into circling
on a smaller scale.
M3 - Conference contribution
T3 - Computer Science Reports
SP - 18
EP - 22
BT - 7th Belgian-Netherlands Software Evolution Workshop (Benevol 2008, Eindhoven, The Netherlands, December 11-12, 2008, Informal pre-proceedings)
A2 - Serebrenik, A.
PB - Technische Universiteit Eindhoven
CY - Serebrenik
ER -