REFINEMENT PROPAGATION
Towards Automated Construction of Visual Specifications
Irina Rychkova and Alain Wegmann
School of Communication and Computer Science,
´
Ecole Polytechnique F
´
ed
´
erale de Lausanne (EPFL)
CH-1015 Lausanne, Switzerland
Keywords:
Visual specification, model transformation, stepwise refinement, refinement calculus, refinement propagation.
Abstract:
Creation and transformation of visual specifications is driven by modeler’s design decisions. After a design
decision has been made, the modeler needs to adjust the specification to maintain its correctness. The number
of adjustments might make the design process tedious for large specifications. We are interested in techniques
that will reduce the modeler’s obligation to control specification correctness.
Every single transformation of the visual specification can be captured by the notion of refinement used in
formal methods. In this work we present the technique that supports a stepwise refinement of visual specifica-
tions based on calculations. We use refinement calculus as a logic for reasoning about refinement correctness.
When a design decision is made by the modeler, the necessary adjustments are calculated based on rules of
refinement propagation. Refinement propagation can automate the specification adjustment and enforce its
correctness.
1 INTRODUCTION
It is well accepted by now that visual models play
an important role in the information system develop-
ment. With the growth of system complexity, auto-
mated refinement, and refinement verification of vi-
sual models is of particular interest.
Stepwise refinement is a well-known paradigm for
semantic program constructions originally proposed
by Dijkstra (1971) and Wirth (1971). It is based on
the idea that a program can be developed through a
sequence of refinement steps starting from an abstract
specification.
In contrast to techniques where a refinement is
first proposed and then proved to be correct, some
techniques allow calculation of refinement step based
on the refinement laws (Morgan and Gardiner, 1990).
The refinement calculus is an underlying theory. This
calculation assures refinement correctness ’by con-
struction’, and enables the reduction of proof obliga-
tions. We believe that refinement by calculation can
be beneficial for the practical application in the con-
text of visual modeling.
In this work we introduce a formal semantics for
SEAM visual specifications (Wegmann, 2003) using
higher-order logic and Refinement Calculus (Back
and von Wright, 1998). Based on this semantics, we
define a refinement propagation technique that sup-
ports a stepwise refinement of visual specifications.
We constrained our discussion to the deterministic
specifications. The refinement propagation technique
is grounded on the following observation: An arbi-
trary refinement may cause a conflict between model
elements. To resolve such a conflict and maintain cor-
rectness, model adjustment (also considered as a re-
finement) is usually required. When the initial refine-
ment can be identified with a design decision that is
proposed by a modeler, the adjustment of the entire
specification can be calculated based on rules of re-
finement propagation. Propagation means a sequen-
tial application of these rules until saturation. We
show that sufficient part of calculations can be done
without modeler’s involvement. We also specify the
situations when modeler’s decision is required to ac-
complish the calculation.
This paper is organized as follows. In Section 2
we present SEAM visual language and classify re-
finements accepted by this language. In Section 3
196
Rychkova I. and Wegmann A. (2007).
REFINEMENT PROPAGATION - Towards Automated Construction of Visual Specifications.
In Proceedings of the Ninth International Conference on Enterprise Information Systems - ISAS, pages 196-204
DOI: 10.5220/0002394401960204
Copyright
c
SciTePress
we define a formal semantics for SEAM using higher-
order logic and refinement calculus. This formaliza-
tion allows for reasoning about visual specifications
with mathematical precision. In Section 4 we intro-
duce the refinement propagation technique. This tech-
nique is formulated as eight rules of refinement prop-
agation. In Section 5 we discuss related works. Sec-
tion 6 presents our conclusions.
2 REFINEMENT IN ’SEAM’
VISUAL MODELING
LANGUAGE
SEAM (Systemic Enterprise Architecture Methodol-
ogy)(Wegmann, 2003) is an approach for modeling
general systems, including information systems and
enterprises. SEAM epistemological principles are
based on General System Thinking (GST) (Weinberg,
1975) and Living Systems Theory (LST) (Miller,
1995). SEAM ontology is grounded on the second
part of RM-ODP (1995) specification. Based on this
standard, the main modeling concepts such as object,
state, action are defined (Wegmann and Naumenko,
2001). Figure 1 illustrates the SEAM visual notation.
S
S2
S1
P1 P2
a b
H
AC
Property
Activity
Action
System
(Working Object)
Event
Pre:<expr >
U:<expr> Post:<expr>
Data
Structure
Behavior
Figure 1: SEAM visual notation.
Any system or system component in SEAM is mod-
eled as a working object. The working object may
communicate with an environment by events. Work-
ing object S is modeled as a collaboration of two
components S1 and S2 (also considered as working
objects). S1 is described by its
observable proper-
ties
P1,P2, and a
behavior
. Properties constitute the
data structure of working object S1 and define its state
space. The behavior is represented by a set of
actions
a,b organized within
activity
AC.
We focus on the refinement of a black box system
specification.
Refinement of the state space: ( see also data
refinement (B
¨
orger, 2003; Woodcock and Davies,
1996; Back, 1989) or data structure refinement (Broy,
1993)) deals with the transformation of system data
structure. We recognize the following ways to refine
a state space:
Extension: new property is introduced into the
system.
Reduction: some property is eliminated.
Other refinements are used in visual modeling (e.g.
substitution of one property (or group of properties)
by another property (or group), property renaming,
etc.). It is not difficult to show that these refinements
can be represented by a combination of extensions
and reductions. Refinement of the system state space
is illustrated in Figure 2.
Client
0..m|cl[1]..cl[m]
SpecA
AddClientH H
Post:
Exist s i | cl[i].n = new_n,
Pre :
new_n
null,
forAll i cl[i].n
new_n
U:
Add(n ew Client(new_n))
Name
{String[30]}
1|n
FName
{String[15]}
LName
{String[20]}
Design decisio n:
E1 [new_fn:FName;
new_ln:LName]
Adjustments:
Pre1:
new_fn
null , new _ln null,
forAll i (cl[i].fn
new _fn or cl[i].ln new_ln )
Post1:
Exists i | (cl[i].fn = new_fn and cl[i].ln = new_ln)
U1: Add(new Client (new_fn , new_ln))
E [new_n:Name]
1|fn
1|ln
Client
...
SpecA1
AddClientH H
{Pre1, U1, Post1}
FName
{String[15]}
LName
{String[20]}
E1
1|fn
1|ln
Rule2: refinement of
event E
Rules 3-4: syntactic and
semantic refinement of
AddClient
Refinement step
Figure 2: Propagation of refinement of the system
state space. Design decision: to substitute Name with
{FName,LName}. Required adjustments made by refine-
ment propagation. A correct SpecA1 is calculated as a re-
sult of the refinement step.
Refinement of the behavior:
Syntactic Refinement: a number of action’s in-
put and output parameters and their types are
changed
1
.
Semantic Refinement: a precondition, an update
statement, and/or a postcondition of an action are
changed.
Extension: new behavior (action or activity) is in-
troduced into the system.
Reduction: some behavior (action or activity) is
eliminated.
Behavior distribution: transition from an action
view to an activity (Figure 3).
Aforementioned refinements specify the basis re-
finement types for SEAM visual specifications. Any
1
This version of behavioral refinement is also called re-
finement of a syntactic interface (Broy, 1993).
REFINEMENT PROPAGATION - Towards Automated Construction of Visual Specifications
197
AddClient
GetFName
H
H
E2.1 [new_fn: FName]
GetLName SaveData
Pre:
new_ln
null
Client
SpecA2
Pre:
new_ fn
null
FName
{String[15]}
LName
{String[20]}
m|cl[1]..cl[m]
1|fn
1|ln
Po st:
Exists i | (cl[i]. fn = new_fn
an d cl[i ].ln = new_ln)
Pre :
forA ll i (cl[i].fn
new_fn o r
cl[i].ln
new _ln)
E2.2 [new _ln: LName]
Design decision:
AddClientH H
E1
{Pre1, U1, Post1}
U: Add(new Client (new_fn, new _ln))
User decision
required
Adjustments :
Figure 3: Propagation of behavior distribution refinement.
SpecA2 refines SpecA1 (Figure 2) providing a realization
of action AddClient.
arbitrary refinement can be represented as a combina-
tion of the basis refinement types. Refinement of the
state space and refinement of the behavior can appear
together in a specification. Also the former can imply
the latter or vice versa. This effect we call a refine-
ment propagation.
3 FORMAL SEMANTICS FOR
’SEAM’
To reason about refinement with mathematical preci-
sion, we formalize SEAM modeling concepts using
a higher-order logic and refinement calculus (Back,
1978; Back and von Wright, 1998).
In our work, we were inspired by the ideas pre-
sented by Mikhajlova and Sekerinski (1997), Back et
al. (2000), and Michajlova (1998). In these works,
refinement calculus is used for the formalization of
object-oriented program development.
We find it necessary to introduce some concepts
of refinement calculus in this section.
3.1 Introduction of Refinement
Calculus
In this paper we restrict our study to deterministic
specifications. Nondeterminism will be addressed in
our future work.
A program state in refinement calculus is modeled
as a tuple of values of all program components. A pro-
gram state space (a type) Σ is defined as a cartesian
product Σ = Σ
1
× Σ
2
× ...× Σ
n
where Σ
1
,Σ
2
,...,Σ
n
are state spaces of all program components.
A predicate over a state space Σ is a boolean func-
tion. The set of all predicates defined over the state
space Σ is denoted by
P Σ ˆ= Σ {true, false} (1)
A relation between two state spaces Σ and Γ is a
function that maps each state in Σ into a predicate in
Γ. The set of all relations from Σ to Γ is denoted by
Σ Γ ˆ= Σ
P Γ (2)
It is equivalent to another, more familiar definition:
Σ Γ ˆ= (Σ×Γ) {true, false}
A predicate transformer from Σ to Γ is a function
that maps each predicate in Σ into a predicate in Γ.
The set of all predicate transformers from Σ to Γ is
denoted by
Σ 7→ Γ ˆ=
P Σ P Γ (3)
Predicate transformer h fi is called a functional
update. It applies the function f to a state σ to yield a
new state f.σ. For all states σ, defined by the precon-
dition p, the functional update will produce the state
f σ, for which the postcondition q holds:
σ Σ | p h fi.q.σ ˆ= q ( f σ) (4)
Program statements in refinement calculus are
identified with predicate transformers.
For a sequential composition of statements S, T,
and predicates p,q,r:
p {|S;T|} q ( r p {|S|} r r {|T|} q (5)
A refinement ordering on the predicate transform-
ers is defined as follows. For S,T : Σ 7→ Γ:
S T ˆ= (q :
P Γ S.q T.q) (6)
For refinement ordering the following holds:
S
1
S
1
S
2
S
2
(S
1
× S
2
) (S
1
× S
2
) (7)
S S
S
′′
S S
′′
(8)
3.2 Formalization of Seam Modeling
Concepts
We distinguish between the following views of
working objects in SEAM:
- Working object as a whole WO
whole
- a black box
system specification;
- Working object as a composite WO
composite
- a
white box system specification.
In this paper, we focus on the black box specifica-
tions.
Working object as a whole describes the system by a
number of properties P
1
...P
m
that specify data types,
and a behavior
B .
We declare the working object WO
whole
as follows:
WO
whole
ˆ=
p
1
1
,..p
n
1
: P
1
,
...,
p
1
m
,..p
n
m
: P
m
,
B
(9)
where p
1
i
,..p
n
i
are instances of a property P
i
.
Working objects may interact with the environment
by receiving inputs I
1
,..,I
k
and sending outputs
O
1
,..O
l
, also modeled as a part of the system.
ICEIS 2007 - International Conference on Enterprise Information Systems
198
We distinguish between primitive and compound
properties. The former can be considered as an alias
for an operational data type (e.g. Int, String, Boolean,
etc.); the latter is defined by a set of
component prop-
erties
and
references
to properties using property-
property relations.
Example 1.
SpecA in Figure 2 specifies a work-
ing object SpecA
whole
with its properties Client and
Name. Property Client is compound, it has a com-
ponent property Name. Name is primitive - an alias
for strings of length 30. This representation unifies a
declarative specification style:
..client is identified by his/her name (30 symbols)..
and an imperative style, intrinsic to programming:
class Client {
name: String[30]; } // String of length 30
m: Int; // number of clients
cl: Array(m) of Client;// list of clients
A state of the primitive property denotes a
value of the corresponding operational type (e.g.
1,ABC,true); a state of the compound property is
defined by the states of its components and references.
A tuple of property instances p
1
1
..p
n
m
, inputs i
1
1
..i
n
k
,
outputs o
1
1
..o
n
l
and their corresponding states defines
a system state σ Σ.
Σ specifies a system state space - a set of all pos-
sible states of the working object:
Σ ˆ= Σ
P
× Σ
In
× Σ
Out
where
Σ
P
= (Σ
P
1
× . .. × Σ
P
1
|
{z }
n
1
) × ... × (Σ
P
m
× . .. × Σ
P
m
|
{z }
n
m
)
Σ
In
= (Σ
I
1
× . .. × Σ
I
1
|
{z }
ni
1
) × ... × (Σ
I
k
× . .. × Σ
I
k
|
{z }
ni
k
)
Σ
Out
= (Σ
O
1
× . .. × Σ
O
1
|
{z }
no
1
) × ... × (Σ
O
l
× . .. × Σ
O
l
|
{z }
no
l
)
Σ
P
,Σ
In
,Σ
Out
denote state spaces of system proper-
ties, inputs, and outputs respectively.
Example 2.
State space of the working object SpecA1
in Figure 2:
Σ
SpecA1
= Σ
Client
× . .. × Σ
Client
|
{z }
m
×Σ
In
Σ
SpecA1
= (String[15] × String[20]) × ... × (..)
|
{z }
m+1
Behavior
B of a working object can be seen as an ac-
tion or as an activity.
Action A is defined by a three-tuple {Pre,U, Post}.
Pre-condition Pre and post-condition Post define the
states of the system σ, σ
Σ before and after the ac-
tion respectively. An update U specifies a transition
from pre- state to post- state.
If this action describes a communication with the
environment, the input and output events E
In
,E
Out
also make part of the action specification
2
.
A ˆ= (10)
E
In
(I
1
,..,I
k
), E
Out
(O
1
,..,O
l
),
Pre :
P (Σ
P
× Σ
In
),
U : (Σ
P
× Σ
In
) (Σ
P
× Σ
Out
)
Post : P (Σ
P
× Σ
Out
),
For the deterministic specifications, we consider a
functional update hUi : Σ 7→ Σ. U is a function that
calculates a post-state from the pre-state. Using the
definition of functional update from (4), we can write:
σ Σ | Pre hUi.Post.σ ˆ= Post (U σ) (11)
We specify action A with its precondition Pre, func-
tional update hUi and postcondition Post as follows:
Pre {|A|} Post ˆ=
Pre {|hUi|} Post Pre hUi
1
.Post (12)
Example 3.
SpecA in Figure 2 defines an action -
AddClient:
AddClient =
E
In
(Name),
Pre = new
n : Name cl cl.n 6= new n
U : Σ
Client
Σ
Client
= Add(newClient(new
n))
Post = cl | cl.n = new
n
Pre states that there exists an input parameter new
n
and that there is no client with the attribute n = new
n
presented in the system. U denotes that a new in-
stance of client newClient(new
n) is added into the
system. The postcondition Post specifies the fact that
after AddClient is carried out, the client with the at-
tribute n = new
n does exist in the system. E
In
(Name)
specifies the input event E, that transmits a parameter
new n.
Activity Ac can be considered as a detailed specifica-
tion of action A: it describes how the transition from
pre- state to post- state is performed. Ac defines a set
of component actions and the way they are composed
to carry out the transition:
Ac ˆ= A
1
A
2
... A
t
(13)
where stands for component action ordering, de-
fined by a corresponding action-action relation.
Precondition Pre, update U, and postcondition
Post of A are related to those of component actions:
Pre
A
= ρ
pre
(Pre
A
1
,..Pre
A
t
);
U
A
= ρ
u
(U
1
,... U
t
);
Post
A
= ρ
post
(Post
A
1
,...,Post
A
t
);
(14)
ρ
pre
,ρ
u
,ρ
post
are defined by the component action or-
dering ().
2
Broy (1993) defines input and output channels and the
sort of messages for each channel as a syntactic interface
of the black box system view. The causal relationship be-
tween input messages and output messages is defined as a
semantic interface of this view.
REFINEMENT PROPAGATION - Towards Automated Construction of Visual Specifications
199
Input and output events E
In
,E
Out
of the activity
Ac, are related to the input and output events of com-
ponent actions A
1
,..A
t
:
Σ
In/Out
Σ
In/Out
1
× ... × Σ
In/Out
t
(15)
Example 4.
SpecA2 in Figure 3 defines an activ-
ity AddClient that specifies the realization of the ac-
tion AddClient from SpecA1, Figure 2. Parameters of
an input event E are distributed between input evens
E
2.1
and E
2.2
of component actions GetFName and -
GetLName such that:
E(FName,LName) {E
2.1
(FName), E
2.2
(LName)}
and Σ
In
(Σ
FName
× Σ
LName
)
4 REFINEMENT PROPAGATION
In this section we introduce the refinement propa-
gation technique for visual specifications. Explor-
ing the basis refinement types, specified in sec-
tion 2, we found relations between them in the
form ”refinementX implies refinementY” . This im-
plication we call a propagation of refinement.
4.1 Definition of Refinement for Visual
Specifications
Refinement calculus specifies the correct refinement
between program statements as a refinement ordering
on the predicate transformers. The program statement
S is said to be correctly refined by the program state-
ment T, iff T satisfies any specification statement sat-
isfied by S, (6).
The specification statement expresses require-
ments program has to meet in a given state. Defini-
tion of refinement for the programm statements (or
programs) can be generalized for visual specification
statements (or visual specifications) as follows:
Definition 1.
Specification
WO
(abstract) is correctly
refined by specification
WO
(concrete)
WO WO
,
if
WO
satisfies any requirement satisfied by
WO
.
4.2 Propagation Rules
In refinement calculus, refinement ordering is mono-
tonic with respect to the sequential statement con-
struction. It means that if S is a statement and S
1
oc-
curs as a substatement, S = S(S
1
) then
S
1
S
1
S(S
1
) S(S
1
) (16)
We can write WO
whole
as a compound statement:
WO
whole
(P
1
,..,P
m
,I
1
,..,I
k
,O
1
,..,O
l
,
B ) (17)
For the substatements, the following can be written:
P
i
= P
i
(..,P
j
,..), I
i
= I
i
(..,I
j
,..),O
i
= (..,O
j
,..)
where P
i
,I
i
,O
i
may be compound properties; and:
B = A(E
In
,E
Out
,Pre,U,Post) | Ac(A
1
,..,A
t
),
E
In
= E
In
(..,I
i
,..),E
Out
= E
Out
(..,O
i
,..), (18)
Pre = Pre(..,I
i
,..,P
j
,..), Post = Post(.., P
i
,..,O
j
,..)
U = U(..,I
i
,..,P
j
,..,O
k
,..)
Properties, events, actions, and activities are related
within specification. Thereby a basis refinement of an
arbitrary substatement X from (17), (18) may cause a
conflict between certain elements, such that
X X
WO
whole
(X) 6⊑ WO
whole
(X
)
To resolve this conflict, and to preserve monotonicity,
refinement X
1
of some other substatement X
1
is usu-
ally required. This assertion formalizes our definition
of refinement propagation. Within a final number of
steps, refinement propagation either results in correct
refinement of specification WO
whole
:
(X X
) (X
1
X
1
) ... (X
n
X
n
)
WO
whole
(X, X
1
,..,X
n
) WO
whole
(X
,X
1
,..,X
n
)
or indicates such a refinement impossible.
Resolving Conflicts between Properties
We distinguish between compound and primitive
properties. The elimination of a compound prop-
erty may cause ’free-floating’ properties and make the
specification confusing.
RULE 1: If P
i
(P
i
1
,..,P
i
k
,P
i
k+1
,..,P
i
l
) is a compound
property with components P
i
1
..P
i
k
and references on
properties P
i
k+1
..P
i
l
, and, by reduction of the state
space, P
i
is eliminated, then its component properties
P
i
1
,..,P
i
k
have to be also eliminated. Reduction of the
state space must be correct.
WO
whole
(..,P
i1
,P
i
,P
i
1
,..,P
i
l
,P
i+1
,..)
P
i
WO
whole
(..,P
i1
,P
i
k+1
,..,P
i
l
P
i+1
,..) (19)
We formulate the correctness of refinement of the
state space:
Definition 2.
Let
WO
whole
be a system specification
as defined in
(9)
;
WO
whole
is its refinement, where
some properties have been introduced, eliminated, or
substituted; and
r
is an abstraction relation connect-
ing ’old’ and ’new’ states:
r : Σ
wo
Σ
wo
The refinement of the state space is correct with re-
spect to
r
, if any state of the abstract specification has
a corresponding state (or group of states) of the con-
crete specification (i.e.
r
is a total surjective function).
The notion of r can be generalized. Considering
R as a relation between predicates of the abstract and
concrete specifications, we can write:
R : Σ
wo
7→ Σ
wo
(20)
WO
R
WO
ˆ= WO WO
;R
ICEIS 2007 - International Conference on Enterprise Information Systems
200
Example 5.
SpecA in Figure 2 is refined by SpecA1
where the property Name is substituted with two other
properties FName and LName. To maintain the refine-
ment correctness, we have to define an abstraction re-
lation between ’old’ and ’new’ data types as a total
surjective function:
r : Σ
Client
Σ
Client
(Σ
FName
× Σ
LName
) Σ
Name
for example:
1.
n := substr(fn + ln, 30)
2.
n := ln //n in ’old’ = ln in ’new’ spec
3. . . .
considering the second expression for n, we define:
Client_old = {n:Name};
Client_new = {fn:FName, ln:LName};
r(x:FName, y:LName):Name = (Name)y;
This relation can be generalized as a predicate trans-
former:
R : (Σ
Client
{true, false}) (Σ
Client
{true, false})
(Σ
FName
× Σ
LName
) 7→ Σ
Name
pred_old(x:Name): Boolean;
pred_new(x:FName, y:LName): Boolean;
R(pred_new(x,y)) = pred_old(r(x,y));
This refinement step causes a conflict between re-
fined property Client’ and the input event E where
the ’eliminated’ property Name occurs as a parame-
ter. Thus the event specification has to be adjusted
(refined):
Client Client
E E
We generalize this observation as a propagation rule.
Resolving Conflicts Between Properties and
Events
RULE 2: If P
is a refinement of a property P, and
E(..,P,..) ˆ=E(P) is an event, where P occurs as a pa-
rameter type, i.e. Σ
P
Σ
E
, then the following holds:
P P
E
In/Out
(P) E
In/Out
(P
)
Example 5 (continue):
The following elaboration of
specification SpecA1 is deducible:
Client Client
, where
Σ
Client
= Σ
Name
, Σ
Client
= Σ
FName
× Σ
LName
, Σ
Name
Σ
In
E(Name) E
1
(FName,LName)
Resolving Conflicts Between Events and Actions:
Syntactic Refinement
RULE 3: If E is an input (output) event of an action
A, then a refinement of E is a syntactic refinement of
the action A (by definition of syntactic refinement).
Syntactic refinement must be correct.
E E
A(E)
syn
E
A(E
)
Definition 3. Let A
be a syntactic refinement of an
action A, and r
In
and r
Out
are abstraction relations
for connecting ’old’ input and output parameters with
the ’new’ ones:
r
In/Out
: Σ
wo
Σ
In/Out
where Σ
wo
is a state space of the refined working ob-
ject. R
In
,R
Out
are the corresponding predicate trans-
formers:
R
In
: (Σ
wo
Σ
In
) {true, false} = Σ
wo
7→ Σ
In
R
Out
: (Σ
wo
Σ
Out
) {true, false} = Σ
wo
7→ Σ
Out
A is correctly refined by A
with respect to R
In
,R
Out
if
A
R
In
,R
Out
A
ˆ= R
In
;A A
;R
Out
(21)
R
In
and R
Out
are total and surjective.
For the propagation Rule 3 we write:
E
In
E
In
R
In
;A(E) A(E
) (22)
E
Out
E
Out
A(E) A(E
);R
Out
(23)
Example 6.
For the action AddClient in Figure 2,
syntactic refinement is correct if predicate trans-
former R
In
is defined:
R
In
: Σ
SpecA1
7→ Σ
Client
= (Σ
FName
× Σ
LName
) 7→ Σ
Name
The definition of R
In
is a modeler’s choice. Here we
take R
In
R, as it was specified in Example 5.
E(Name) E1(FName,LName)
R
In
;AddClient(E(Name)) AddClient(E1(FName, LName))
Resolving Conflicts Between Events and Actions:
Semantic Refinement
RULE 4: If E is an input (output) event of an action
A, and E or some of its parameters I
i
(O
i
) occurs in
Pre, U, or Post of A, then a refinement of E implies a
semantic refinement of the action A. Semantic refine-
ment must be correct.
A | Pre(E) U(E) Post(E)
E E
A
sem
E
A
Definition 4. Let A be an action, defined by the tu-
ple {E,Pre,U,Post} ; A
: {E
,Pre
,U
,Post
} is its
semantic refinement, where Pre
, Post
are new pre-
and postconditions, and U
is a new update. A is cor-
rectly refined by A
if:
- A
is applicable at least on every state where A is ap-
plicable;
- starting at the corresponding initial states, A
and A
produce equivalent results.
Providing abstraction relation R, which relates
’old’ and ’new’ predicates (Definition 2), and using
action specification from (12), A is said to be correctly
refined by A
with respect to R if
R.Pre
hUi
1
.Post
and
Pre (hU
i
1
;R).Post
(24)
REFINEMENT PROPAGATION - Towards Automated Construction of Visual Specifications
201
For the propagation Rule 4 we write:
E E
R;A (E
/E)A;R (25)
where (E
/E)A stands for a substitution of each oc-
currence of E or one of its parameters by E
, or its
corresponding parameter.
Example 7.
SpecA1 illustrates the semantic refine-
ment of the action AddClient, specified in Example 3:
AddClient
=
E
1
(FName, LName),
Pre
1
= new
fn : FName, new ln : LName
cl (cl. fn 6= new
fn cl.ln 6= new ln)
U
1
: Σ
Client
Σ
Client
= Add(newClient(new
fn,new ln))
Post
1
= cl | (cl. fn = new
fn cl.ln = new ln)
New precondition Pre
1
and postcondition Post
1
have
been calculated by propagation:
E(Name) E
1
(FName,LName) (rule 4)
AddClient(E)
sem
E
AddClient(E
1
)
Pre = Pre(Name), Post = Post(Name) (rule 5)
AddClient(Pre,Post)
sem
E
AddClient(Pre
1
,Post
1
), and
Pre
1
= new
fn : FName, new ln : LName
cl (cl. fn 6= new f n cl.ln 6= new ln)
Post
1
= cl | (cl. f n = new f n cl.ln = new ln)
This refinement is correct by Definition 4. For the
sake of brevity, the proof of correctness is omitted.
The specification adjustment is finished and the re-
finement propagation is complete.
(Client Client
) (E E
1
) (AddCl.. AddCl..
)
SpecA(Name, E,AddClient)
SpecA1({FName,LName},E
1
,AddClient
)
Resolving Conflicts Between Properties and
Actions: Semantic Refinement
RULE 5: If property P occurs in Pre, U, or Post of
action A, then a refinement of P implies a semantic
refinement of A. Semantic refinement must be correct.
A | Pre(P) U(P) Post(P)
P P
A
sem
P
A
By definition of correct semantic refinement (Defini-
tion 4), we write:
P P
R;A (P
/P)A;R (26)
where (P
/P)A stands for a substitution of each
occurrence of P by P
in the statements of A, and R is
an abstraction relation.
Resolving Conflicts between Events and the Sys-
tem State Space
RULE 6: If E is an input (output) event of working
object WO
whole
then an extension of E by some pa-
rameter of type T implies an extension of the system
state space by introduction of a property T.
E(..) E(.., T,..)
WO
whole
+
WO
whole
Σ
wo
= Σ
wo
× Σ
T
(27)
Note: If Σ
E
Σ
E
(a reduction) - there is no conflict
with the system state space.
Resolving Conflicts Between Pre-,
Post-conditions, and Updates
A semantic refinement takes place when pre-, post-
condition, or update statement of an action is
changed. The equation (12) relates pre-, post-
condition, and update. Precondition Pre can be calcu-
lated as a weakest precondition wp(A, Post) that guar-
antees termination of any execution of A (hUi) in the
final state that satisfies Post. Postcondition Post can
be calculated as a strongest postcondition sp(A,Pre)
respectively. An update U cannot be resolved by cal-
culation and requires a modeler’s decision.
Conflicts between pre-, post-conditions, and up-
dates indicate that semantic refinement is incorrect.
Correctness of semantic refinement is formulated in
Definition 4.
Resolving Conflicts between an Activity and its
Component Actions
Behavior distribution refinement stands for an activity
definition (Figure 3). This requires a set of compo-
nent actions and action ordering provided by modeler.
RULE 7: If an activity Ac is a behavioral distribution
refinement of an action A, and A
1
,..A
t
- are compo-
nent actions, see (13), then:
1. Events E
In
i
and E
Out
i
of component actions are de-
fined based on the modeler’s decision, providing (15)
holds;
2. Preconditions Pre
i
of component actions are de-
fined either by propagation or based on modeler’s de-
cision, providing ρ
pre
for the given action ordering
(14) is defined;
3. Updates U
i
and/or postconditions Post
i
are defined
based on modelers decision, providing ρ
u
,ρ
post
for
the given invocation order (14) are defined, and (12)
holds for each component action;
Example 8.
Figure 3 illustrates the propagation of a
behavior distribution refinement. Component actions
GetFName, GetLName, and SaveData, their ordering,
and set of input events are provided by a modeler. By
refinement propagation, we define the preconditions
for AddFName and AddLName component actions.
Specification of the postcondition is the modeler’s de-
cision (here SaveData).
Without loss of generality, any action in SEAM
specification can be seen as a component action of
some abstract activity Ac
parent
.
3
Thus, the refinement
of the behavior by an extension is considered as an
introduction a new component to this abstract activity,
whereas a reduction stands for elimination of some
3
System life cycle is the most abstract activity system
performs from the moment of putting in operation (startup)
till the end of functioning (shutdown). Any action or activ-
ity is a part of the life cycle.
ICEIS 2007 - International Conference on Enterprise Information Systems
202
component from it. Rule 6, applied for the Ac
parent
,
specifies the propagation of these refinements.
Both extension and reduction of the system’s be-
havior have to preserve the semantics of the rest of the
specification. Put it in other terms, modeler needs to
guarantee that the system will work ’at least as well as
before’ in presence of new actions/activities or after
removing any of them. This follows from the Defini-
tion 1.
Incorrectness
RULE 8: Refinement propagation is impossible if the
correctness of initial refinement is not provable.
Summary
In this section we provide definitions for the refine-
ment correctness and formulate eight rules of refine-
ment propagation. Refinement steps often represent
combinations of refinements. For such a combination
(7) and (8) hold.
We demonstrate that a significant part of specifi-
cation elaboration can be done by calculation. We
also specify the situations, when intervention of the
modeler is necessary. Formal proof of soundness and
completeness of the refinement propagation technique
is an important issue. This makes a topic of our cur-
rent research.
For the sake of brevity, some technical details have
been omitted. For more explanations, please, contact
the authors.
5 RELATED WORK
The foundations in mathematical logic are extensively
used to formalize specifications and refinement tech-
niques for program constructions. Woodcock and
Davies (1996) present the method of software specifi-
cation development called Z. B
¨
orger and St
¨
ark (2003)
introduce the Abstract State Machine method of ab-
stract refinable system specifications. Refinement for-
malization for object-oriented programs using refine-
ment calculus is presented by Mikhajlova and Sek-
erinski (1997), Back et al. (2000), and Michajlova
(1998). Back(2005) proposes a method of incremen-
tal software construction using refinement diagrams.
Here refinement calculus is used as a logic for reason-
ing about software systems and their evolution.
In the domain of visual languages, evolutionary
specifications of ADORA are provided with refine-
ment calculus semantic (Xia and Glinz, 2004). The
transition between model views requires a represen-
tation consistency that is guaranteed by the applica-
tion of refinement calculus. Muskens, in (Muskens
et al., 2005), focuses on the problem of consistency
checking between software views, expressed as UML
diagrams. The approach in (Muskens et al., 2005)
is based on verification of obligation and constraint
rules using relation partition algebra. In contrast to
these approaches, refinement propagation technique
for SEAM black box specifications focuses on preser-
vation of semantic correctness for visual specifica-
tions.
Baar and Marcovi
´
c (2006) introduce a proof tech-
nique for the semantic preservation of refactoring
rules for UML class diagrams and OCL constraints.
Refactoring can be considered as a specific form of re-
finement. We believe that the refinement propagation
technique can be equally used to support automated
refactoring of SEAM specifications. In our work, ac-
tion constraints in SEAM (pre-, post- conditions, and
updates) are specified using some meta-language. Al-
ternatively, they can be expressed in OCL.
Pons (2006) presents the OCL-based technique
and a tool support for UML and OCL model refine-
ment. Object-Z is an underlying theory for refine-
ment verification. The authors discuss the refinement
patterns and formulate the refinement conditions for
these patterns in OCL language(OCL, 2003). Simi-
larly, our technique considers several standard refine-
ment types that can be identified with patterns. In ad-
dition, we define conflict situations, caused by these
refinement types and explore the idea of refinement
propagation.
6 CONCLUSION
In this work we formalize the notion of refinement
and its correctness for visual specifications using
refinement calculus (Back and von Wright, 1998).
Based on this formalization, we define the refinement
propagation technique for semiautomated specifica-
tion construction. Initiated by modeler’s design de-
cision, correct refinement of the visual specification
can be:
automatically calculated, based on refinement
propagation,
calculated based on supplementary information
from the modeler,
recognized as impossible to calculate.
Eight rules of refinement propagation address pos-
sible conflicts between SEAM specification elements,
caused by refinements. Figure 4 summaries the appli-
cability of our technique. The leftmost column enu-
merates the refinements. Each row denotes conflicts
between elements, caused by the respective refine-
ment, and solutions for these conflicts. For example,
REFINEMENT PROPAGATION - Towards Automated Construction of Visual Specifications
203
Property
Pre- U Post-E in/out
Action A
Activity
Ac
Property
R5 R5 R5
R2
R7 R7R7R7
R7 – D1
R7 – D1
Ac
parent
Ac
parent
Activity Ac
Behavior
B
5 distribution
1 introduction
2 elimination
6 introduction
7 elimination
? ?
- no conflict between elements
?
- relations have to be considered
Eve
nt E
R6
R3 – D3
(E
in
) R4 (E
out
) R4
3 syntactic ref.
+
-
R4
D4
D4 D4
D4
4 semantic ref.
Pre-
U
Post-
??
??
?
A
i
?
R
- rule
D
- definition
R1 – D2
Figure 4: Refinement propagation rules. Summary.
an introduction of a property (row 1) causes no con-
flict with action preconditions (column 3), whereas
property elimination (row 2) may cause such a con-
flict (column 3). This conflict can be resolved apply-
ing a propagation rule 5.
Refinements may cause conflicts by breaking
property-property and action-action relations in
SEAM (Figure 1). Formalization, refinement, and re-
finement propagation for these relations is out of the
scope of this paper. We put a question mark in the
summary table to specify these cases.
We consider the refinement propagation technique
as an efficient step towards computer-aided construc-
tion of visual specifications. Application of this tech-
nique in the form of a modeling tool is one of our
on-going projects.
REFERENCES
Baar, T. and Markovi
´
c, S. (2006). A graphical approach to
prove the semantic preservation of UML/OCL refac-
toring rules. In Ershov Memorial Conference, Lecture
Notes in Computer Science.
Back, R.-J. (1978). On the Correctness of Refinement Steps
in Program Development. PhD thesis, bo Akademi,
Department of Computer Science, Helsinki, Finland.
Report A–1978–4.
Back, R.-J. (1989). Changing data representation in the re-
finement calculus. In 22nd Hawaii International Con-
ference on System Sciences, pages 231–242. IEEE.
Back, R.-J. (2005). Incremental software construction with
refinement diagrams. In Broy, Gunbauer, H. and
Hoare, editors, Engineering Theories of Software In-
tensive Systems, NATO Science Series II: Mathemat-
ics, Physics and Chemistry, pages 3–46. Springer,
Marktoberdorf, Germany.
Back, R.-J., Mikhajlova, A., and von Wright, J. (2000).
Class refinement as semantics of correct object substi-
tutability. Formal Aspects of Computing, 12(1):18–40.
Back, R.-J. and von Wright, J. (1998). Refinement Calculus:
A Systematic Introduction. Springer-Verlag. Graduate
Texts in Computer Science.
B
¨
orger, E. (2003). The asm refinement method. Formal
aspects of computing.
B
¨
orger, E. and St
¨
ark, R. (2003). Abstract State Machines:
A Method for High-Level System Design and Analysis.
Springer-Verlag.
Broy, M. (1993). Interaction refinement—the easy way.
In Program Design Calculi: Proceedings of the
1992 Marktoberdorf International Summer School.
Springer-Verlag.
Dijkstra, E. W. (1971). Notes on structured programming.
In Structured Programming. Academic Press.
Mikhajlova, A. (1998). Consistent extension of compo-
nents in presence of explicit invariants. In Workshop
on Component-Oriented Programming (WCOP’98),
ECOOP’98. TUCS General Publication Series.
Mikhajlova, A. and Sekerinski, E. (1997). Class refinement
and interface refinement in object-oriented programs.
In FME ’97: Industrial Applications and Stengthened
Foundations of Formal Metohds, volume 1313, pages
82–101. Springer.
Miller, J. (1995). Living Systems. University of Colorado
Press.
Morgan, C. and Gardiner, P. H. B. (1990). Data refinement
by calculation. Acta Informatica, 27(6):481–503.
Muskens, J., Bril, R. J., and Chaudron, M. R. V. (2005).
Generalizing consistency checking between software
views. In WICSA, pages 169–180.
OCL (2003). OCL 2.0 Final Adopted Specification. OMG.
Pons, C. (2006). Heuristics on the definition of UML re-
finement patterns. In SOFSEM, pages 461–470.
RM-ODP (1995). Reference model of open distributed pro-
cessing part 1. Draft International Standard (DIS).
Helsinki, Finland.
UML (2007). Unified Modeling Language (UML), version
2.1.1. OMG, www.omg.org.
Wegmann, A. (2003). On the systemic enterprise architec-
ture methodology (seam). In International Conference
on Enterprise Information Systems (ICEIS).
Wegmann, A. and Naumenko, A. (2001). Conceptual mod-
eling of complex systems using an rm-odp based on-
tology. In EDOC, pages 200–211.
Weinberg, G. M. (1975). An Introduction to General Sys-
tems Thinking. New York: Wiley & Sons.
Wirth, N. (1971). Program development by stepwise refine-
ment. Communications of the ACM, 14:221–227.
Woodcock, J. and Davies, J. (1996). Using Z. Prentice Hall.
Xia, Y. and Glinz, M. (2004). Extending a graphic modeling
language to support partial and evolutionary specifica-
tion. apsec, 00:18–27.
ICEIS 2007 - International Conference on Enterprise Information Systems
204