REFINEMENT PROPAGATION

Towards Automated Construction of Visual Speciﬁcations

Irina Rychkova and Alain Wegmann

School of Communication and Computer Science,

Ecole Polytechnique F

erale de Lausanne (EPFL)

CH-1015 Lausanne, Switzerland

Keywords:

Visual speciﬁcation, model transformation, stepwise reﬁnement, reﬁnement calculus, reﬁnement propagation.

Abstract:

Creation and transformation of visual speciﬁcations is driven by modeler’s design decisions. After a design

decision has been made, the modeler needs to adjust the speciﬁcation to maintain its correctness. The number

of adjustments might make the design process tedious for large speciﬁcations. We are interested in techniques

that will reduce the modeler’s obligation to control speciﬁcation correctness.

Every single transformation of the visual speciﬁcation can be captured by the notion of reﬁnement used in

formal methods. In this work we present the technique that supports a stepwise reﬁnement of visual speciﬁca-

tions based on calculations. We use reﬁnement calculus as a logic for reasoning about reﬁnement correctness.

When a design decision is made by the modeler, the necessary adjustments are calculated based on rules of

reﬁnement propagation. Reﬁnement propagation can automate the speciﬁcation 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 reﬁnement, and reﬁnement veriﬁcation of vi-

sual models is of particular interest.

Stepwise reﬁnement 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 reﬁnement steps starting from an abstract

speciﬁcation.

In contrast to techniques where a reﬁnement is

ﬁrst proposed and then proved to be correct, some

techniques allow calculation of reﬁnement step based

on the reﬁnement laws (Morgan and Gardiner, 1990).

The reﬁnement calculus is an underlying theory. This

calculation assures reﬁnement correctness ’by con-

struction’, and enables the reduction of proof obliga-

tions. We believe that reﬁnement by calculation can

be beneﬁcial for the practical application in the con-

text of visual modeling.

In this work we introduce a formal semantics for

SEAM visual speciﬁcations (Wegmann, 2003) using

higher-order logic and Reﬁnement Calculus (Back

and von Wright, 1998). Based on this semantics, we

deﬁne a reﬁnement propagation technique that sup-

ports a stepwise reﬁnement of visual speciﬁcations.

We constrained our discussion to the deterministic

speciﬁcations. The reﬁnement propagation technique

is grounded on the following observation: An arbi-

trary reﬁnement may cause a conﬂict between model

elements. To resolve such a conﬂict and maintain cor-

rectness, model adjustment (also considered as a re-

ﬁnement) is usually required. When the initial reﬁne-

ment can be identiﬁed with a design decision that is

proposed by a modeler, the adjustment of the entire

speciﬁcation can be calculated based on rules of re-

ﬁnement propagation. Propagation means a sequen-

tial application of these rules until saturation. We

show that sufﬁcient 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-

ﬁnements accepted by this language. In Section 3

196

Rychkova I. and Wegmann A. (2007).

REFINEMENT PROPAGATION - Towards Automated Construction of Visual Speciﬁcations.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - ISAS, pages 196-204

DOI: 10.5220/0002394401960204

 SciTePress

we deﬁne a formal semantics for SEAM using higher-

order logic and reﬁnement calculus. This formaliza-

tion allows for reasoning about visual speciﬁcations

with mathematical precision. In Section 4 we intro-

duce the reﬁnement propagation technique. This tech-

nique is formulated as eight rules of reﬁnement 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) speciﬁcation. Based on this

standard, the main modeling concepts such as object,

state, action are deﬁned (Wegmann and Naumenko,

2001). Figure 1 illustrates the SEAM visual notation.

P1 P2

a b

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 deﬁne its state

space. The behavior is represented by a set of

actions

a,b organized within

activity

AC.

We focus on the reﬁnement of a black box system

speciﬁcation.

Reﬁnement of the state space: ( see also data

reﬁnement (B

orger, 2003; Woodcock and Davies,

1996; Back, 1989) or data structure reﬁnement (Broy,

1993)) deals with the transformation of system data

structure. We recognize the following ways to reﬁne

a state space:

• Extension: new property is introduced into the

system.

• Reduction: some property is eliminated.

Other reﬁnements 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 difﬁcult to show that these reﬁnements

can be represented by a combination of extensions

and reductions. Reﬁnement 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

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]}

1|fn

1|ln

Rule2: refinement of

event E

Rules 3-4: syntactic and

semantic refinement of

AddClient

Refinement step

Figure 2: Propagation of reﬁnement of the system

state space. Design decision: to substitute Name with

{FName,LName}. Required adjustments made by reﬁne-

ment propagation. A correct SpecA1 is calculated as a re-

sult of the reﬁnement step.

Reﬁnement of the behavior:

• Syntactic Reﬁnement: a number of action’s in-

put and output parameters and their types are

changed

• Semantic Reﬁnement: 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 reﬁnements specify the basis re-

ﬁnement types for SEAM visual speciﬁcations. Any

This version of behavioral reﬁnement is also called re-

ﬁnement of a syntactic interface (Broy, 1993).

REFINEMENT PROPAGATION - Towards Automated Construction of Visual Specifications

197

AddClient

GetFName

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

{Pre1, U1, Post1}

U: Add(new Client (new_fn, new _ln))

User decision

required

Adjustments :

Figure 3: Propagation of behavior distribution reﬁnement.

SpecA2 reﬁnes SpecA1 (Figure 2) providing a realization

of action AddClient.

arbitrary reﬁnement can be represented as a combina-

tion of the basis reﬁnement types. Reﬁnement of the

state space and reﬁnement of the behavior can appear

together in a speciﬁcation. Also the former can imply

the latter or vice versa. This effect we call a reﬁne-

ment propagation.

3 FORMAL SEMANTICS FOR

’SEAM’

To reason about reﬁnement with mathematical preci-

sion, we formalize SEAM modeling concepts using

a higher-order logic and reﬁnement 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,

reﬁnement calculus is used for the formalization of

object-oriented program development.

We ﬁnd it necessary to introduce some concepts

of reﬁnement calculus in this section.

3.1 Introduction of Reﬁnement

Calculus

In this paper we restrict our study to deterministic

speciﬁcations. Nondeterminism will be addressed in

our future work.

A program state in reﬁnement calculus is modeled

as a tuple of values of all program components. A pro-

gram state space (a type) Σ is deﬁned as a cartesian

product Σ = Σ

× Σ

× ...× Σ

where Σ

,Σ

,...,Σ

are state spaces of all program components.

A predicate over a state space Σ is a boolean func-

tion. The set of all predicates deﬁned 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 deﬁnition:

Σ ↔ Γ ˆ= (Σ×Γ) → {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 σ, deﬁned 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 reﬁnement calculus are

identiﬁed 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 reﬁnement ordering on the predicate transform-

ers is deﬁned as follows. For S,T : Σ 7→ Γ:

S ⊑ T ˆ= (∀q :

P Γ • S.q ⊆ T.q) (6)

For reﬁnement ordering the following holds:

⊑ S

′

∧ S

⊑ S

′

⇒ (S

× S

) ⊑ (S

′

× S

′

) (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 speciﬁcation;

- Working object as a composite WO

composite

- a

white box system speciﬁcation.

In this paper, we focus on the black box speciﬁca-

tions.

Working object as a whole describes the system by a

number of properties P

...P

that specify data types,

and a behavior

B .

We declare the working object WO

whole

as follows:

whole

ˆ=

,..p

: P

...,

,..p

: P

(9)

where p

,..p

are instances of a property P

Working objects may interact with the environment

by receiving inputs I

,..,I

and sending outputs

,..O

, 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 deﬁned by a set of

component prop-

erties

and

references

to properties using property-

property relations.

Example 1.

SpecA in Figure 2 speciﬁes 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 uniﬁes a

declarative speciﬁcation style:

”..client is identiﬁed 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

deﬁned by the states of its components and references.

A tuple of property instances p

..p

, inputs i

..i

outputs o

..o

and their corresponding states deﬁnes

a system state σ ∈ Σ.

Σ speciﬁes a system state space - a set of all pos-

sible states of the working object:

Σ ˆ= Σ

× Σ

Out

where

= (Σ

× . .. × Σ

{z }

) × ... × (Σ

× . .. × Σ

{z }

)

= (Σ

× . .. × Σ

{z }

) × ... × (Σ

× . .. × Σ

{z }

)

Out

= (Σ

× . .. × Σ

{z }

) × ... × (Σ

× . .. × Σ

{z }

)

,Σ

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 }

×Σ

⇒

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 deﬁned by a three-tuple {Pre,U, Post}.

Pre-condition Pre and post-condition Post deﬁne the

states of the system σ, σ

′

∈ Σ before and after the ac-

tion respectively. An update U speciﬁes a transition

from pre- state to post- state.

If this action describes a communication with the

environment, the input and output events E

Out

also make part of the action speciﬁcation

A ˆ= (10)

,..,I

), E

Out

,..,O

Pre :

P (Σ

× Σ

U : (Σ

× Σ

) → (Σ

× Σ

Out

)

Post : P (Σ

× Σ

Out

For the deterministic speciﬁcations, we consider a

functional update hUi : Σ 7→ Σ. U is a function that

calculates a post-state from the pre-state. Using the

deﬁnition 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 deﬁnes an action -

AddClient:

AddClient =

(Name),

Pre = ∃ new

n : Name ∧ ∀ cl • cl.n 6= new n

U : Σ

Client

→ Σ

Client

= Add(newClient(new

n))

Post = ∃ cl | cl.n = new

Pre states that there exists an input parameter new

and that there is no client with the attribute n = new

presented in the system. U denotes that a new in-

stance of client newClient(new

n) is added into the

system. The postcondition Post speciﬁes the fact that

after AddClient is carried out, the client with the at-

tribute n = new

n does exist in the system. E

(Name)

speciﬁes the input event E, that transmits a parameter

new n. 

Activity Ac can be considered as a detailed speciﬁca-

tion of action A: it describes how the transition from

pre- state to post- state is performed. Ac deﬁnes a set

of component actions and the way they are composed

to carry out the transition:

Ac ˆ= A

 A

 ...  A

(13)

where  stands for component action ordering, de-

ﬁned by a corresponding action-action relation.

Precondition Pre, update U, and postcondition

Post of A are related to those of component actions:

Pre

= ρ

pre

(Pre

,..Pre

);

= ρ

,... U

);

Post

= ρ

post

(Post

,...,Post

);

(14)

pre

,ρ

post

are deﬁned by the component action or-

dering ().

Broy (1993) deﬁnes 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 deﬁned as a

semantic interface of this view.

REFINEMENT PROPAGATION - Towards Automated Construction of Visual Specifications

199

Input and output events E

Out

of the activity

Ac, are related to the input and output events of com-

ponent actions A

,..A

In/Out

⊆ Σ

In/Out

× ... × Σ

In/Out

(15)

Example 4.

SpecA2 in Figure 3 deﬁnes an activ-

ity AddClient that speciﬁes the realization of the ac-

tion AddClient from SpecA1, Figure 2. Parameters of

an input event E are distributed between input evens

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 Σ

≡ (Σ

FName

× Σ

LName

) 

4 REFINEMENT PROPAGATION

In this section we introduce the reﬁnement propa-

gation technique for visual speciﬁcations. Explor-

ing the basis reﬁnement types, speciﬁed in sec-

tion 2, we found relations between them in the

form ”reﬁnementX implies reﬁnementY” . This im-

plication we call a propagation of reﬁnement.

4.1 Deﬁnition of Reﬁnement for Visual

Speciﬁcations

Reﬁnement calculus speciﬁes the correct reﬁnement

between program statements as a reﬁnement ordering

on the predicate transformers. The program statement

S is said to be correctly reﬁned by the program state-

ment T, iff T satisﬁes any speciﬁcation statement sat-

isﬁed by S, (6).

The speciﬁcation statement expresses require-

ments program has to meet in a given state. Deﬁni-

tion of reﬁnement for the programm statements (or

programs) can be generalized for visual speciﬁcation

statements (or visual speciﬁcations) as follows:

Deﬁnition 1.

Speciﬁcation

(abstract) is correctly

reﬁned by speciﬁcation

′

(concrete)

WO ⊑ WO

′

satisﬁes any requirement satisﬁed by

4.2 Propagation Rules

In reﬁnement calculus, reﬁnement ordering is mono-

tonic with respect to the sequential statement con-

struction. It means that if S is a statement and S

oc-

curs as a substatement, S = S(S

) then

⊑ S

′

⇒ S(S

) ⊑ S(S

′

) (16)

We can write WO

whole

as a compound statement:

whole

,..,P

,..,I

,..,O

B ) (17)

For the substatements, the following can be written:

= P

(..,P

,..), I

= I

(..,I

,..),O

= (..,O

,..)

where P

may be compound properties; and:

B = A(E

Out

,Pre,U,Post) | Ac(A

,..,A

= E

(..,I

,..),E

Out

= E

Out

(..,O

,..), (18)

Pre = Pre(..,I

,..,P

,..), Post = Post(.., P

,..,O

,..)

U = U(..,I

,..,P

,..,O

,..)

Properties, events, actions, and activities are related

within speciﬁcation. Thereby a basis reﬁnement of an

arbitrary substatement X from (17), (18) may cause a

conﬂict between certain elements, such that

X ⊑ X

′

∧ WO

whole

(X) 6⊑ WO

whole

′

)

To resolve this conﬂict, and to preserve monotonicity,

reﬁnement X

′

of some other substatement X

is usu-

ally required. This assertion formalizes our deﬁnition

of reﬁnement propagation. Within a ﬁnal number of

steps, reﬁnement propagation either results in correct

reﬁnement of speciﬁcation WO

whole

(X ⊑ X

′

) ⇒ (X

⊑ X

′

) ... ⇒ (X

⊑ X

′

) ⇒

whole

(X, X

,..,X

) ⊑ WO

whole

′

,..,X

′

)

or indicates such a reﬁnement impossible.

Resolving Conﬂicts between Properties

We distinguish between compound and primitive

properties. The elimination of a compound prop-

erty may cause ’free-ﬂoating’ properties and make the

speciﬁcation confusing.

RULE 1: If P

,..,P

k+1

,..,P

) is a compound

property with components P

..P

and references on

properties P

k+1

..P

, and, by reduction of the state

space, P

is eliminated, then its component properties

,..,P

have to be also eliminated. Reduction of the

state space must be correct.

whole

(..,P

i−1

,..,P

i+1

,..) ⊑

−P

whole

(..,P

i−1

k+1

,..,P

i+1

,..) (19)

We formulate the correctness of reﬁnement of the

state space:

Deﬁnition 2.

Let

whole

be a system speciﬁcation

as deﬁned in

(9)

;

′

whole

is its reﬁnement, where

some properties have been introduced, eliminated, or

substituted; and

is an abstraction relation connect-

ing ’old’ and ’new’ states:

r : Σ

′

↔ Σ

The reﬁnement of the state space is correct with re-

spect to

, if any state of the abstract speciﬁcation has

a corresponding state (or group of states) of the con-

crete speciﬁcation (i.e.

is a total surjective function).

The notion of r can be generalized. Considering

R as a relation between predicates of the abstract and

concrete speciﬁcations, we can write:

R : Σ

′

7→ Σ

(20)

WO ⊑

′

ˆ= WO ⊑ WO

′

ICEIS 2007 - International Conference on Enterprise Information Systems

200

Example 5.

SpecA in Figure 2 is reﬁned by SpecA1

where the property Name is substituted with two other

properties FName and LName. To maintain the reﬁne-

ment correctness, we have to deﬁne an abstraction re-

lation between ’old’ and ’new’ data types as a total

surjective function:

r : Σ

Client

′

→ Σ

Client

⇔ (Σ

FName

× Σ

LName

) → Σ

Name

for example:

n := substr(fn + ln, 30)

n := ln //n in ’old’ = ln in ’new’ spec

3. . . .

considering the second expression for n, we deﬁne:

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 reﬁnement step causes a conﬂict between re-

ﬁned property Client’ and the input event E where

the ’eliminated’ property Name occurs as a parame-

ter. Thus the event speciﬁcation has to be adjusted

(reﬁned):

Client ⊑ Client

′

⇒ E ⊑ E

′

We generalize this observation as a propagation rule.

Resolving Conﬂicts Between Properties and

Events

RULE 2: If P

′

is a reﬁnement of a property P, and

E(..,P,..) ˆ=E(P) is an event, where P occurs as a pa-

rameter type, i.e. Σ

⊆ Σ

, then the following holds:

P ⊑ P

′

⇒ E

In/Out

(P) ⊑ E

In/Out

′

)

Example 5 (continue):

The following elaboration of

speciﬁcation SpecA1 is deducible:

Client ⊑ Client

′

, where

Client

= Σ

Name

, Σ

Client

′

= Σ

FName

× Σ

LName

, Σ

Name

⊆ Σ

⇓

E(Name) ⊑ E

(FName,LName) 

Resolving Conﬂicts Between Events and Actions:

Syntactic Reﬁnement

RULE 3: If E is an input (output) event of an action

A, then a reﬁnement of E is a syntactic reﬁnement of

the action A (by deﬁnition of syntactic reﬁnement).

Syntactic reﬁnement must be correct.

E ⊑ E

′

⇔ A(E) ⊑

syn

A(E

′

)

Deﬁnition 3. Let A

′

be a syntactic reﬁnement of an

action A, and r

and r

Out

are abstraction relations

for connecting ’old’ input and output parameters with

the ’new’ ones:

In/Out

: Σ

′

→ Σ

In/Out

where Σ

′

is a state space of the reﬁned working ob-

ject. R

Out

are the corresponding predicate trans-

formers:

: (Σ

′

→ Σ

) → {true, false} = Σ

′

7→ Σ

Out

: (Σ

′

→ Σ

Out

) → {true, false} = Σ

′

7→ Σ

Out

A is correctly reﬁned by A

′

with respect to R

Out

A ⊑

Out

′

ˆ= R

;A ⊑ A

′

Out

(21)

and R

Out

are total and surjective.

For the propagation Rule 3 we write:

⊑ E

′

⇔ R

;A(E) ⊑ A(E

′

) (22)

Out

⊑ E

′

Out

⇔ A(E) ⊑ A(E

′

);R

Out

(23)

Example 6.

For the action AddClient in Figure 2,

syntactic reﬁnement is correct if predicate trans-

former R

is deﬁned:

: Σ

SpecA1

7→ Σ

Client

= (Σ

FName

× Σ

LName

) 7→ Σ

Name

The deﬁnition of R

is a modeler’s choice. Here we

take R

≡ R, as it was speciﬁed in Example 5.

E(Name) ⊑ E1(FName,LName) ⇒

;AddClient(E(Name)) ⊑ AddClient(E1(FName, LName))



Resolving Conﬂicts Between Events and Actions:

Semantic Reﬁnement

RULE 4: If E is an input (output) event of an action

A, and E or some of its parameters I

) occurs in

Pre, U, or Post of A, then a reﬁnement of E implies a

semantic reﬁnement of the action A. Semantic reﬁne-

ment must be correct.

A | Pre(E) ∨ U(E) ∨ Post(E) ⇒

E ⊑ E

′

⇒ A ⊑

sem

′

Deﬁnition 4. Let A be an action, deﬁned by the tu-

ple {E,Pre,U,Post} ; A

′

: {E

′

,Pre

′

,Post

′

} is its

semantic reﬁnement, where Pre

′

, Post

′

are new pre-

and postconditions, and U

′

is a new update. A is cor-

rectly reﬁned 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 (Deﬁnition 2), and using

action speciﬁcation from (12), A is said to be correctly

reﬁned by A

′

with respect to R if

R.Pre

′

⊆ hUi

−1

.Post

and

Pre ⊆ (hU

′

−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 reﬁne-

ment of the action AddClient, speciﬁed in Example 3:

AddClient

′

(FName, LName),

Pre

= ∃ new

fn : FName, new ln : LName ∧

∀ cl • (cl. fn 6= new

fn ∨ cl.ln 6= new ln)

: Σ

Client

→ Σ

Client

= Add(newClient(new

fn,new ln))

Post

= ∃ cl | (cl. fn = new

fn ∧ cl.ln = new ln)

New precondition Pre

and postcondition Post

have

been calculated by propagation:

E(Name) ⊑ E

(FName,LName) ⇒ (rule 4)

AddClient(E) ⊑

sem

AddClient(E

)

Pre = Pre(Name), Post = Post(Name) ⇒ (rule 5)

AddClient(Pre,Post) ⊑

sem

AddClient(Pre

,Post

), and

Pre

= ∃ new

fn : FName, new ln : LName ∧

∀ cl • (cl. fn 6= new f n ∨ cl.ln 6= new ln)

Post

= ∃ cl | (cl. f n = new f n ∧ cl.ln = new ln)

This reﬁnement is correct by Deﬁnition 4. For the

sake of brevity, the proof of correctness is omitted.

The speciﬁcation adjustment is ﬁnished and the re-

ﬁnement propagation is complete.

(Client ⊑ Client

′

) ⇒ (E ⊑ E

) ⇒ (AddCl.. ⊑ AddCl..

′

) ⇒

SpecA(Name, E,AddClient) ⊑

SpecA1({FName,LName},E

,AddClient

′

) 

Resolving Conﬂicts Between Properties and

Actions: Semantic Reﬁnement

RULE 5: If property P occurs in Pre, U, or Post of

action A, then a reﬁnement of P implies a semantic

reﬁnement of A. Semantic reﬁnement must be correct.

A | Pre(P) ∨ U(P) ∨ Post(P) ⇒

P ⊑ P

′

⇒ A ⊑

sem

′

By deﬁnition of correct semantic reﬁnement (Deﬁni-

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 Conﬂicts 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,..) ⇒

whole

⊑

′

whole

∧ Σ

′

= Σ

× Σ

(27)

Note: If Σ

′

⊆ Σ

(a reduction) - there is no conﬂict

with the system state space.

Resolving Conﬂicts Between Pre-,

Post-conditions, and Updates

A semantic reﬁnement 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

ﬁnal state that satisﬁes 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.

Conﬂicts between pre-, post-conditions, and up-

dates indicate that semantic reﬁnement is incorrect.

Correctness of semantic reﬁnement is formulated in

Deﬁnition 4.

Resolving Conﬂicts between an Activity and its

Component Actions

Behavior distribution reﬁnement stands for an activity

deﬁnition (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

reﬁnement of an action A, and A

,..A

- are compo-

nent actions, see (13), then:

1. Events E

and E

Out

of component actions are de-

ﬁned based on the modeler’s decision, providing (15)

holds;

2. Preconditions Pre

of component actions are de-

ﬁned either by propagation or based on modeler’s de-

cision, providing ρ

pre

for the given action ordering

(14) is deﬁned;

3. Updates U

and/or postconditions Post

are deﬁned

based on modelers decision, providing ρ

,ρ

post

for

the given invocation order (14) are deﬁned, and (12)

holds for each component action;

Example 8.

Figure 3 illustrates the propagation of a

behavior distribution reﬁnement. Component actions

GetFName, GetLName, and SaveData, their ordering,

and set of input events are provided by a modeler. By

reﬁnement propagation, we deﬁne the preconditions

for AddFName and AddLName component actions.

Speciﬁcation of the postcondition is the modeler’s de-

cision (here SaveData). 

Without loss of generality, any action in SEAM

speciﬁcation can be seen as a component action of

some abstract activity Ac

parent

Thus, the reﬁnement

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

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

speciﬁes the propagation of these reﬁnements.

Both extension and reduction of the system’s be-

havior have to preserve the semantics of the rest of the

speciﬁcation. 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 Deﬁni-

tion 1.

Incorrectness

RULE 8: Reﬁnement propagation is impossible if the

correctness of initial reﬁnement is not provable.

Summary

In this section we provide deﬁnitions for the reﬁne-

ment correctness and formulate eight rules of reﬁne-

ment propagation. Reﬁnement steps often represent

combinations of reﬁnements. For such a combination

(7) and (8) hold.

We demonstrate that a signiﬁcant part of speciﬁ-

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 reﬁnement 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 speciﬁcations and reﬁnement tech-

niques for program constructions. Woodcock and

Davies (1996) present the method of software speciﬁ-

cation development called Z. B

orger and St

ark (2003)

introduce the Abstract State Machine method of ab-

stract reﬁnable system speciﬁcations. Reﬁnement for-

malization for object-oriented programs using reﬁne-

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 reﬁnement diagrams.

Here reﬁnement calculus is used as a logic for reason-

ing about software systems and their evolution.

In the domain of visual languages, evolutionary

speciﬁcations of ADORA are provided with reﬁne-

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 reﬁnement 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 veriﬁcation of obligation and constraint

rules using relation partition algebra. In contrast to

these approaches, reﬁnement propagation technique

for SEAM black box speciﬁcations focuses on preser-

vation of semantic correctness for visual speciﬁca-

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 speciﬁc form of re-

ﬁnement. We believe that the reﬁnement propagation

technique can be equally used to support automated

refactoring of SEAM speciﬁcations. In our work, ac-

tion constraints in SEAM (pre-, post- conditions, and

updates) are speciﬁed 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 reﬁne-

ment. Object-Z is an underlying theory for reﬁne-

ment veriﬁcation. The authors discuss the reﬁnement

patterns and formulate the reﬁnement conditions for

these patterns in OCL language(OCL, 2003). Simi-

larly, our technique considers several standard reﬁne-

ment types that can be identiﬁed with patterns. In ad-

dition, we deﬁne conﬂict situations, caused by these

reﬁnement types and explore the idea of reﬁnement

propagation.

6 CONCLUSION

In this work we formalize the notion of reﬁnement

and its correctness for visual speciﬁcations using

reﬁnement calculus (Back and von Wright, 1998).

Based on this formalization, we deﬁne the reﬁnement

propagation technique for semiautomated speciﬁca-

tion construction. Initiated by modeler’s design de-

cision, correct reﬁnement of the visual speciﬁcation

can be:

• automatically calculated, based on reﬁnement

propagation,

• calculated based on supplementary information

from the modeler,

• recognized as impossible to calculate.

Eight rules of reﬁnement propagation address pos-

sible conﬂicts between SEAM speciﬁcation elements,

caused by reﬁnements. Figure 4 summaries the appli-

cability of our technique. The leftmost column enu-

merates the reﬁnements. Each row denotes conﬂicts

between elements, caused by the respective reﬁne-

ment, and solutions for these conﬂicts. For example,

REFINEMENT PROPAGATION - Towards Automated Construction of Visual Specifications

203

Property

Pre- U Post-E in/out

Action A

Activity

Property

R5 R5 R5

R7 R7R7R7

R7 – D1

parent

Activity Ac

Behavior

5 distribution

1 introduction

2 elimination

6 introduction

7 elimination

? ?

- no conflict between elements

- relations have to be considered

Eve

nt E

R3 – D3

) R4 (E

out

) R4

3 syntactic ref.

D4 D4

4 semantic ref.

Pre-

Post-

- rule

- definition

R1 – D2

Figure 4: Reﬁnement propagation rules. Summary.

an introduction of a property (row 1) causes no con-

ﬂict with action preconditions (column 3), whereas

property elimination (row 2) may cause such a con-

ﬂict (column 3). This conﬂict can be resolved apply-

ing a propagation rule 5.

Reﬁnements may cause conﬂicts by breaking

property-property and action-action relations in

SEAM (Figure 1). Formalization, reﬁnement, and re-

ﬁnement 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 reﬁnement propagation technique

as an efﬁcient step towards computer-aided construc-

tion of visual speciﬁcations. 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 Reﬁnement 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-

ﬁnement calculus. In 22nd Hawaii International Con-

ference on System Sciences, pages 231–242. IEEE.

Back, R.-J. (2005). Incremental software construction with

reﬁnement 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 reﬁnement as semantics of correct object substi-

tutability. Formal Aspects of Computing, 12(1):18–40.

Back, R.-J. and von Wright, J. (1998). Reﬁnement Calculus:

A Systematic Introduction. Springer-Verlag. Graduate

Texts in Computer Science.

orger, E. (2003). The asm reﬁnement method. Formal

aspects of computing.

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 reﬁnement—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 reﬁnement

and interface reﬁnement 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 reﬁnement

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 Speciﬁcation. OMG.

Pons, C. (2006). Heuristics on the deﬁnition of UML re-

ﬁnement 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). Uniﬁed 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 reﬁne-

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 speciﬁca-

tion. apsec, 00:18–27.

ICEIS 2007 - International Conference on Enterprise Information Systems

204