See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/2819945

Interpreting Syntropy in Larch

Article · June 1999

Source: CiteSeer

CITATIONS READS

8 290

2 authors:

Ali Hamie John Howse

University of Brighton University of Brighton
38 PUBLICATIONS   216 CITATIONS    129 PUBLICATIONS   1,811 CITATIONS   

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Ali Hamie on 09 June 2015.

The user has requested enhancement of the downloaded file.

 Interpreting Syntropy in Larch

Ali Hamie, John Howse

School of Computing and Mathematical Sciences,
University of Brighton,
Brighton BN2 4GJ, UK.
A.A.Hamie@brighton.ac.uk
John.Howse@brighton.ac.uk
March 18, 1997

Abstract Other approaches to system specication and design in-

clude many object-oriented techniques [2] [4] [13] [14].
This paper presents a formal axiomatic semantics for the These approaches employ intuitive graphical notations
essential model notations of Syntropy, where an essen- for expressing system requirements and design. While
tial model provides a step towards the specication of
an object-oriented system. Syntropy like other object-
oriented development methods uses intuitive and easy to
understand graphical notations for expressing the static
and dynamic aspects of the model. However, Syntropy
diers from other methods by the use of mathematical
notations to annotate the graphical notations and by
the use of event broadcasting to abstract from message
passing between objects. The lack of complete formality
in Syntropy prevents the evaluation of completeness and
consistency of its models.
these techniques provide useful organizational tools, the
graphical notations used with these methods lack the
precision that may result in diagrams that are easily mis-
interpreted. The object-oriented development method
Syntropy [6] diers from these approaches by incorpor-
ating some mathematical notations within the graphical
notations.
Syntropy
Syntropy is an object-oriented analysis and design
The semantics is expressed in the specication lan-
guage the Larch Shared Language. The formalisation of
the essential model contributes to a mathematical basis
for reasoning using the tools provided by Larch, and
is a valuable aid for developing support tools for the
method that employs graphical notations similar to the
Object Modelling Technique (OMT) [14] to express the
static and dynamic aspects of the problem domain or
situation. In addition, Syntropy uses some mathemat-
ical notations to precisely specify some aspects of the
method. The formalisation can be extended quite easily data models using the specication language Z [12].
to provide a semantics for the modelling language UML. The main features that distinguish Syntropy from other
object-oriented methods is the incorporation of mathem-
Keywords: formal semantics, formal methods, atical notations and the use of event broadcasting as a
Syntropy, algebraic specication, object modelling, means of abstracting from message passing, to eect ob-
Larch ject communication and collaboration. Three separate
models are used in Syntropy, these are

1 Introduction  essential model

 specication model
Formal approaches to software development employ
formal languages to express the requirements and design  implementation model
of the software. These approaches are characterized by
a formal specication language and a set of rules that The essential model captures the facts about the prob-
can be used for the manipulation of expressions in that lem domain of the application. Its main purpose is to
language. The advantages of using these approaches in- provide a clear understanding of the particular situation
clude the use of precise and veriable notations, and the being modelled, and a clear separation between the soft-
possibility of automated processing. ware and its environment. The essential model might be

1
regarded as a rst step towards specifying the software. of the same sort, separated by \==". If one term of
The specication model captures in an abstract way the an equation is \true" then the equation can be abbre-
requirements of the software. It uses event broadcast- viated to just the other term. The implies section is
ing rather than message passing between objects as a optional and includes some derived consequences of the
means of communications between objects. While the specication axioms, together with assertions about the
implementation model gives detailed description of the completeness of the operators denitions. These can be
software, where objects communicate through sending mechanically checked and veried using available tools
messages to each other. Each model has a type view such as the larch theorem prover (LP) which supports
and state view. Type views consist of type diagrams typed rst-order predicate logic with equality [8].
that depict the structure of object types and their inter- This paper provides the semantics for the diagrammatic
relationships. Objects can only have attributes of value language as used by the Syntropy method. A particular
or non-object types refered to in Syntropy as value prop-
erties. Properties of objects which are other objects are
called associations. Associations between object types
are depicted by lines connecting the types with various
annotations expressing constraints on such associations.
State views on the other hand, depict object states and
complement type views by describing valid changes to
model is formalized as a formal specication that can be
used to reason about the completeness and consistency
of the model, and facilitates the development of tools. In
addition, it may provide a rigorous way to prove that ob-
ject diagrams 1 are consistent with type and state views
by formalizing the former as algebras. Our semantics
can be adapted quite easily to provide the semantics of
system states and indicate the conditions under which a the Unied Modelling Language (UML) [13]. We shall
state change may occur. State views notations are based concentrate mainly on the essential model of Syntropy.
on Harel's statechart formalism [11] that extends nite
state machines by providing modularity and depth. The main reason for using LSL as the target specication
language is the simplicity of its syntax and semantics
and the availability of a number of tools that can aid in
The Larch Shared Language constructing correct and consistent specications. These
include a syntax checker, the larch theorem prover (LP),
The Larch Shared Language (LSL) [9] is an algebraic and a graphical browser and development environment.
specication language based on typed or multi-sorted In addition, LSL facilitates re-use by providing a rich
rst-order predicate logic with equality. It is mainly library of specications (the Larch Handbook), that in-
suitable for the specication of abstract data types and cludes traits for most of the commonly used mathem-
the encapsulation of various mathematical properties atical and data structures and their properties. For in-
that are shared by several data types. The basic spe- stance, the basic axiomatization of boolean algebra is
cication unit in LSL is called a trait. Traits provide a built into the language, and is assumed to be part of
structuring mechanism for specications and are presen- every trait.
ted in the following form:
SPECNAME(parameters ) : trait A
includes
used specication modules are listed here f:T
introduces g : T1 -> T2
operation signatures are listed here
asserts
axioms are listed here
implies Figure 1: Type view with one object type.
consequences of the axioms are listed here

SPECNAME is the name of the specication module or

trait. Following the name, is the list of sorts that form
the parameters of the trait. The includes section lists 2 The Semantics of Object Types
other traits on which the specication is built. The in-
troduces section lists a set of operators (function identi-
ers) together with their signatures (the sorts of their do-
main and ranges). All operators used in a trait must be
declared so that terms can be sort-checked in the same
way as function calls are type-checked in programming
languages. The asserts section lists the axioms that con-
Objects types are depicted in type views as rectangu-
lar diagrams. That is, each rectangle in a type view
denotes or represents an object type. The name of the
object type appears at the top of the rectangle, separ-
ated from the rest of the contents by a horizontal line.
The remainder of the rectangle is used to hold value-
strain the operators expressed in rst-order predicate
logic with equality. An equation consists of two terms 1 instance diagrams in OMT

2
typed properties. For example, Figure 1 depicts a type A trait that species the sort  can be introduced as
view consisting of single object type named A with two follows:
properties f of type T and g that takes a value of type T1
and returns a value of type T2 . We interpret such type STATE : trait
A as a sort denoted also by A that contains the potential introduces
identities of objects conforming to type A. Hence, some 0 : ! 
: !
object identities of sort A may not refer to any exist-
0

earlier : ;  ! Bool
ing objects in a particular system state. In addition we asserts
sort  generated by 0 ;
assume that the identity of an object is unique.
0

8;1 ; 2 : 
0 6=  0

In order to model the dynamic aspects of the essential 1 = 2 ) 1 = 2 0 0

model we introduce a basic sort  that represents the earlier(;  )0

 6= 0 ) earlier(0 ; )
system states where the characteristics of objects can be :earlier(; ) % irre exive
observed. The states in the sort  form a chain starting % antisymmetric
earlier(1 ; 2 ) ^ earlier(2 ; 1 ) ) (1 = 2 )
from an initial state 0 and with a successor function 0 % transitive
introduced as follows: earlier(; 1 ) ^ earlier(1 ; 2 ) ) earlier(; 2 )

0 : !  Objects can have properties that have undened values

0 : ! which are referred to in Syntropy as optional properties.
In order to model such properties, for value sort T we
that is, 0 is introduced as a constant of the sort . dene a sort T? that contains an error value or undened
The initial state represents the initial conguration of value denoted by ? (pronounced bottom) as follows:
an object-oriented system. The state 0 denotes the suc-
cessor of the state . The symbol \ " in the function ? : ! T?
name is a marker that indicates the syntactical position
of each argument. inj : T ! T?
The initial state 0 has no successor which we formally intuitively, ? is a nullary constructor, and inj is a func-
express as follows: tion that constructs a value of sort T? from a value of
sort T . The function inj is to satisfy the following ax-
8 :  0 6= 0 iom:
8x; y : T  inj(x) = inj(y) ) x = y
The function 0 is to satisfy the following axiom: In addition we introduce a function proj that extracts
the injected value:
81 ; 2 :   1 = 2 ) 10 = 20
proj : T? ! T
that is, the successor of a given state is unique.
In addition we introduce a predicate (boolean function) which satises the following axiom:
earlier as follows: 8x : T  proj(inj(x)) == x
earlier : ;  ! Bool
where earlier(1 ; 2) simply asserts that state 1 comes The reason for choosing this way to introduce undened
before or earlier than state 2. It is required that the values is to avoid specifying the eects of the operations
ordering relation earlier be irre exive, antisymmetric of the type T on ?.
and transitive. A trait that species the sort T? can be presented as
The axiom relating the functions 0 and earlier is ex- follows:
pressed as follows:
ADDBOTTOM(T , T ) : trait
introduces
?

8 :    6= 0 ) earlier(0 ; ) ?: ! T
inj : T ! T
?

proj : T ! T
?

8 :   earlier(; 0 ) asserts
?

Intuitively, the rst axiom simply asserts that 0 is 8x;y : T

proj (inj (x)) == x
earlier than any other state, while the second axiom as- inj (x) = inj (y) ) x = y
serts that  is earlier than its successor 0 .

3
The basic assumption of the formalisation is that the sort
A contains all potential identities of objects conforming
to type A. Therefore, an object identity in the sort
A may not yet refer to an object of type A in some
state. For this we introduce the function exists with the
following signature:
exists : A;  ! Bool
intuitively exists(a; ) asserts that the object identity a
refers to an existing object of type A. In addition we
assume that the identity of an object is unique.
Attributes of objects are formalised or modelled as func-
tions with values that vary from state to state. For ex-
intuitively, this asserts that the value of f is unchanged
for any two distinct states, i.e. the state is irrelevant.
In this case we can formalise a constant attribute f as
a function with the following signature:
f : A ! T?
An attributes f which is not constrained to be optional
(don't take ? as value) has the following additional con-
straint:
8a : A;  :  exists(a; ) ) f(a; ) 6= ?
ample the attributes f and g of A (Figure 1) are mod- Object types will be specied by using Larch traits.
elled as functions denoted also by f and g with the fol- Trait names for object types will be prexed by
lowing signatures: OBJECT-TYPE followed by the name of the type.
Traits that specify object types must include all the
f : A;  ! T? traits that specify the types of their object attributes.
For example, the specication of the type A in the type
g : A; T1;  ! T2 ? view of Figure 1 depends on the specications of the
where T? is the range sort constructed from the sort T value types T, T1 , and T2 . A trait that species the
by including an error value. Similarly for the range sort type A can be presented as follows:
T2 .
?

These attribute functions are constrained to satisfy the OBJECT-TYPE-A : trait

includes
following axioms (strictness ): SPEC1(T), ADDBOTTOM(T, T ), ?
SPEC2(T1 ), ADDBOTTOM(T1 , T1 ),
SPEC3(T2 ), ADDBOTTOM(T2 , T2 ),
?

8a : A;  :   :(exists(a; )) ) f(a; ) = ? STATE

?

introduces
8a : A; x : T1 ;  :   :(exists(a; )) ) exists : A;  ! Bool
f : A;  ! T
g : A; T1 ;  ! T2
?

g(a; x; ) = ? asserts
?

Intuitively, this asserts that in any system state nothing 8 : ; a : A; x : T1

:(exists(a;)) ) f (a; ) = ?
can be observed about non-existing objects. No further :(exists(a;)) ) g(a; x; ) = ?
exists(a;) ) f (a; ) 6= ?
constraints are imposed since the results of the functions exists(a;) ) g(a; x; ) 6= ?
will vary from state to state.
Invariants which relate and constrain individual attrib- where SPEC1(T ), SPEC2(T1 ), SPEC3(T2 ), and STATE
utes of objects are easily expressed. For example, if the are the traits specifying the value sorts T, T1 , T2 , and 
attribute f is specied to be unique then we have the respectively. The trait ADDBOTTOM(T , T? ) provides
following axiom:
8a1; a2 : A;  :   (exists(a1 ; ) ^ exists(a2 ; )
^(a1 6= a2 )) ) f(a1 ; ) 6= f(a2 ; )
that is, for dierent existing objects of type A in the
model, the attribute function f yields dierent values in
any given state .
the specication of the sort T? given the specication of
sort T.
3 The Semantics of Associations
In this section we extend the object type semantics given
Constant attributes are those which maintain a xed in the previous section to include binary associations
value during the life time of the owning object. For between types. In type views, associations are depicted
example if the attribute f is specied to be a constant
attribute then we have the following axiom:
8a : A; 1; 2 :   (exists(a; 1 ) ^ exists(a; 2 ))
) f(a; 1 ) = f(a; 2 )
4
as lines between rectangles. Associations between types
are basically relations which mathematically can be rep-
resented as sets of ordered pairs. Since we are basing
our approach on Larch we represent binary associations
between types as predicates with the appropriate signa-
ture. Predicates here refer to functions with Bool as
their range sort. For instance, Figure 2 depicts the most
general binary association known as many-to-many as-
sociation. This can be formalised by introducing a pre-
dicate R with the following signature:
R : A; B;  ! Bool
where R(a; b; ) is true when object a is associated with
object b in a state .
where  refers to the name of the type view.
The implication of representing an association as a pre-
dicate is that navigation expressions from an object
through association lines will always yield a set. This
set is obtained by the image of R to the relevant object.
Constraints(R,A,B) =
(a) A R B true

A B R Constraints(R,A,B) =
R (b) A B functional(R,A,B)

Figure 2: A many-many association. (c) A R B Constraints(R,A,B) =

functional(R,A,B) /\
total(R,A,B)

The function R is constrained to satisfy the following

axioms: (d) A R B Constraints(R,A,B) =
injective(R,A,B) /\

8a : A; b : B;  :   (exists(a; ) ^ R(a; b; ))

surjective(R,A,B)

) exists(b; )
Constraints(R,A,B) =
(e) A R B injective(R,A,B) /\
surjective(R,A,B) /\

8a : A; b : B;  : (exists(b; ) ^ R(a; b; ))

functional(R,A,B)

) exists(a; )
Constraints(R,A,B) =
(f) A R B injective(R,A,B) /\
intuitively, these axioms assert that an existing object surjective(R,A,B) /\

of a given type can only be associated via R with an

total(R,A,B) /\
functional(R,A,B)
existing object of another type.
Constraints(R,A,B) =
A R B
Trait names for traits that specify associations will be (g) injective(R,A,B)
prexed by ASSOCIATION followed by the name of the
association. In order to specify the association of Figure A R B Constraints(R,A,B) =
2 we need to include the specications of the object types (h) injective(R,A,B) /\
A and B, that is: functional(R,A,B)

Constraints(R,A,B) =
ASSOCIATION-R : trait (i) A R B injective(R,A,B) /\
includes total(R,A,B) /\
OBJECT-TYPE-A, functional(R,A,B)
OBJECT-TYPE-B
introduces
R : A; B;  ! Bool Figure 3: Associations with various multiplicities.
asserts
8 : ; a : A; b : B
(exists(a;) ^ R(a; b; )) ) exists(b;)
(exists(b;) ^ R(a; b; )) ) exists(a;)
3.1 Multiplicity Constraints
where the traits OBJECT-TYPE-A and Multiplicity constraints on an association between two
OBJECT-TYPE-B specify the object types A and types place a limit on the number of objects from one
B respectively. type that can be associated with a given object from
A trait that species the type view of Figure 2 can now another type. For instance, a black blob within an as-
be presented as follows: sociation (as in Figure 2) indicates the absence of size
limitations. That is an object from one end can be as-
sociated with a nite set of objects from the other end.
TYPE-VIEW- : trait Other annotations include a white blob in one end to
includes
OBJECT-TYPE-A, % type A
indicate multiplicity of zero or one, while a straight line
OBJECT-TYPE-B, % type B indicates a multiplicity of exactly one. Using these an-
ASSOCIATION-R % Association R notations we obtain nine combinations in total, and these
are shown in Figure 3.

5
In order to express the multiplicity constraints of an
association it is convenient to introduce a second or- ASSOCIATION-R : trait
der logical predicate for each relational property such as includes
OBJECT-TYPE-A,
totality, injectivity, surjectivity and functionality. For OBJECT-TYPE-B,
example we introduce the predicate functional, where functional(R,A,B)
introduces
functional(R; A; B) is dened to be the rst order as-
sertion expressing that R is a functional relation between
A and B as follows:
functional(R; A; B) =def (8a : A; b1; b2 : B;  :  
(exists(a; ) ^ R(a; b1; ) ^ R(a; b2; )) ) b1 = b2 )
The predicate total(R; A; B) asserting that R is a total
R : A; B;  ! Bool
asserts
8 : ; a : A; b : B
(exists(a;) ^ R(a; b; )) ) exists(b;)
(exists(b;) ^ R(a; b; )) ) exists(a;)
Figure 3 shows nine associations together with their mul-
tiplicity constraints expressed in terms of the four rela-
tional properties namely injectivity, surjectivity, func-
relation from A to B is dened as follows:
total(R; A; B) =def
(8a : A;  :   (9b : B)R(a; b; ))
tionality and totality. However, The constraints of some
of the associations shown in Figure 3 can be derived from
others. For example, the constraints of the type model
shown in Figure 3.c can be derived from that in Figure
3.d using inverse associations. The inverse relation R,1
The predicate injective(R; A; B) asserting that R is an of R is dened as follows:
injective relation from A to B is dened as follows: R,1 : B; A;  ! Bool
injective(R; A; B) =def (8a1 ; a2 : A; b : B;  :   and satises the following axiom:
(exists(b; ) ^ R(a1; b; ) ^ R(a2 ; b; )) ) a1 = a2 ) 8a : A; b : B;  :   R,1(b; a; ) == R(a; b; )

The predicate surjective(R; A; B) asserting that R is a that is R(a; b; ) holds if and only if R,1(b; a; ) holds.
surjective relation from A to B is dened as follows:
surjective(R; A; B) =def
(8b : B;  :   (9a : A)R(a; b; ))
It is easy to show that if R,1 is injective and surjective
then it follows that R is functional and total respectively.
By using these results we can obtain the constraints of
R from the constraints of its inverse R,1.
In addition, the constraints of the association in Figure
These second order predicates t well in Larch since they 3.b (referred to as model ) can be derived from the
can be included as parametrised specications (traits). constraints of the associations of some models in Figure
For instance, the functional predicate is converted to the 3 as follows. The idea is to decompose the model in
following trait: Figure 3.b into the models of Figure 3.c (referred to as
model 1 )and Figure 3.e (referred to as model 2 ). The
constraints of the associations in models 1 and 2 are
functional(R,A,B) : trait given as follows:
introduces
R : A; B;  ! Bool Constraints1 (R; A; B) = functional(R; A; B)^
exists : A;  ! Bool
exists : B;  ! Bool
asserts total(R; A; B)
8 : ; a : A; b1 ; b2 : B
exists(a;) ^ R(a; b1 ; ) ^ R(a; b2 ; ) ) b1 = b2 Constraints2 (R; A; B) = functional(R; A; B)^
injective(R; A; B) ^ surjective(R; A; B)
Traits for the other relational predicates can be specied
in a similar way.
The association depicted in Figure 3.b is interpreted as
follows. Each object of type A is associated with at
most one object of B, which is indicated by the white
blob, and each object of B is associated with zero or
The type view 1 on the B-end of the association has
a more constraining endpoint than does type view ,
and the same holds for the A-end of association R
in 2 . Composing the models 1 and 2 by select-
ing the least constraining of the corresponding end
points, we obtain the model . That means, we re-
more objects of type A. That is the association R is quire to construct the most constraining specication
functional. A trait that species this association and its that is no stronger than either of the specications
constraints can be presented as follows: given by 1 and 2 . The simplest way to compute the

6
required specication is to let Constraints (R; A; B) INVR : B;  ! Set[A]
be the conjunctive expression whose conjuncts consist where the sorts Set[A] and Set[B] are the power sorts
of those common to both Constraints1 (R; A; B) and of A and B respectively.
Constraints2 (R; A; B). Hence, we obtain the following
multiplicity constraint for association R of type view : These functions are related to R by the following axioms:
Constraints (R; A; B) = functional(R; A; B) 8a : A; b : B;  :
R(a; b; ) == (b 2 IMGR (a; ))
8a : A; b : B;  :  
A B
R >=1

R(a; b; ) == (a 2 INVR (b; ))

Figure 4: Association with annotation where 2 is the set membership function.
Now we can express the multiplicity constraints of the
Some associations can be total without being functional. association shown in Figure 5 as follows:
Syntropy does not have a special notation for this, but
such associations can be depicted as a black blob an- 8a : A;  :  exists(a; ) )
notated with cardinality constraint of  1 as shown in
Figure 4. This can be specied as being total but not cardinality(IMGR (a; )) = n
necessarily functional.
where the function cardinality returns the number of
elements in its set argument.
A B
R n

A B
m R n
Figure 5: A many-n association.
Figure 6: A m-n association.
In fact the type views in Figure 3.c, 3.e and 3.f can
form a basis from which the multiplicity constraints of
associations of other type views can be derived. When The multiplicity constraints of associations with xed
dealing with associations with xed multiplicities it is multiplicity at both ends can now be specied quite eas-
not straightforward to express these multiplicities us- ily. For instance the constraints of the association shown
ing only the four relational properties mentioned before. in Figure 6 are specied as follows:
However, any association with xed multiplicity at one
end can be decomposed into associations that have sim- 8a : A; b : B;  :
ilar forms to those in Figure 3. For example, association
R of the view shown in Figure 5 can be decomposed (exists(a; ) ) cardinality(IMGR (a; )) = n)
(partitioned) into n many-one associations R1 ; : : :; Rn.
The specication of the multiplicity constraints of R is
given as the conjunction of the constraints of each Ri :
Constraints(R; A; B) = Constraints(R1 ; A; B) ^ : : : ^
Constraints(Rn ; A; B)
where the multiplicity constraints of each Ri can be ob-
tained directly from the base models. An alternative and
^ (exists(b; ) ) cardinality(INVR (b; )) = m)
An alternative way to compute these constraints is to de-
compose the type views of Figure 6 into the type views
shown in Figures 5 and 7. If we compose the type type
views in Figures 5 and 7 in such a way that the most
constraining of the corresponding end points is selected,
we obtain the view in Figure 6. That means, we need
direct way to express these constraints is achieved by to construct the most constraining specication that is
dening two functions IMGR (image of R) and INVR stronger than both of the specications given by the type
(inverse image of R) that return the image and inverse views in Figures 5 and 7. The simplest way to compute
image of an object under the relation R with the follow- the required specication is to let Constraints(R; A; B)
ing signatures: of Figure 6 be the conjunctive expression whose con-
juncts consist of those conjuncts from the specications
IMGR : A;  ! Set[B] of the associations in Figures 5 and 7.

7
 where the function members returns true if its rst ar-
A
R
B gument is a member of its second argument (which is a
m
sequence).
A trait that species the sort of sequences Seq[T ] with
Figure 7: A m-many association. elements of sort T can be presented as follows:

SEQUENCE (T) : trait

Other annotations used to express multiplicity con- includes
straints on associations can now be expressed quite eas- Natural(N)
introduces
ily. Consequently, all multiplicity constraints of any bin- empty : ! Seq[T ]
ary association can be expressed by using the relational insert : T; Seq[T ] ! Seq[T ]
head : Seq[T ] ! T
properties namely functional, injective, surjective tail : Seq[T ] ! Seq[T ]
and total, and the functions IMGR and INVR . In fact isEmpty : Seq[T ] ! Bool
members : T; Seq[T ] ! Bool
all multiplicity constraints can be expressed by only us- length : Seq[T ] ! N
ing the two functions IMGR and INVR , however, the index : N; Seq[T ] ! T
asserts
advantage of using the relational properties is that it sort Seq[T ] generated by empty; insert
gives a better modular structure. sort Seq[T ] partitioned by head; tail; isEmpty
8x : T; s : Seq[T ]
head(insert(x;s)) == x
tail(insert(x;s)) == s
3.2 Order Constraints isEmpty(empty) == true
:(isEmpty(insert(x;s))) == true
:(members (y; empty)) == true
members (y; insert(x;s)) ==
Order constraints specify the order of objects yielded if (x = y) then true else members (y; s)
by the association. For instance, an association with a length(empty) == 0
length(insert(x;s)) == 1 + length(s)
black blob yields a set which is unordered and can not index(0;insert(x;s)) == x
have duplicates. To indicate that an association yields (n  0) ^ (n  length(s)) )
index(n;insert(x;s)) = index(n , 1; s)
a sequence instead of a set the annotation [seq] is used.
Other container structures such as bags can also be yiel-
ded by an association. For example, Figure 8 depicts an where the included trait Natural(N) species the sort of
association annotated with [seq], which is interpreted natural numbers.
as saying each object of type A is associated with a
sequence of objects of type B which may contain du- If an association R is annotated with [bag] then its
plicates. constraints can be specied by dening a function
IMGBAGR with the following signature:
A B IMGBAGR : A;  ! Bag[B]
R [seq]
where Bag[B] is the sort of bags with items of type B.
Intuitively, the function IMGBAGR returns a bag of
Figure 8: Sequence constraints. objects of type B which is associated with an object of
type A.
In order to express the constraints of the association of The function IMGBAGR is related to the relation R by
Figure 8 we introduce a function IMGSEQR with the the following axiom:
following signature:
8a : A;  :  
IMGSEQR : A;  ! Seq[B]
R(a; b; ) == memberb (b; IMGBAGR (a; ))
where Seq[B] is the sort of sequences with items of type
B. Intuitively, the function IMGSEQR returns the se-
quence of objects of type B which is associated with an
object of type A.
The function IMGSEQR is related to the relation R by
the following axiom:
8a : A;  :  
R(a; b; ) == members (b; IMGSEQR (a; ))
where the function memberb returns true if its rst ar-
gument is a member of its second argument (which is a
bag).
3.3 Constraints between Associations
Constraints may also exist between associations. In
Syntropy, such constraints are shown as dashed arrows

8
 A R B v:T
[subset of] A B
(a)
R
R’
C
Figure 9: Subset constraint. A B
(b)
R
between the association lines, with annotations describ- (c) A q:T B
ing the nature of the constraint enclosed by square
brackets. For example, Figure 9 shows two associations R
R and R0 between two object types A and B, and a
subset constraint indicated by [subset of]. Informally, Figure 10: Association property, Association type, qual-
it means that the set of objects of type B yielded by R0 ied association.
for an object of type A is a subset of the set of objects
yielded by R for the same object. Formally, we have
We model the association property v as a function with
8a : A; b : B; 
:   (exists(a; ) the following signature:
^ R0(a; b; )) ) R(a; b; ) v : A; B;  ! T?
If the association R is one-to-many as in the case of The function v is to satisfy the following axiom:
Figure 9 then the following is easily derivable:
8a : A; b : B;  :   (exists(a; )
8a1; a2 : A; b : B;  :   (exists(b; ) ^R(a; b; )) ) v(a; b; ) 6= ?
^R(a1 ; b; ) ^ R0(a2 ; b; )) ) a1 = a2 A trait that species an association with a property as
The subset constraint is directional, i.e. from A to in Figure 10.a, may be introduced as follows:
B. In addition, membership constraints, indicated by
[member of], is a special case where an object of type ASSOCIATION-R : trait
A is associated via R0 with at most one object of type includes
B. Other association constraints can be expressed in a OBJECT-TYPE-A,
OBJECT-TYPE-B,
similar fashion. SPEC(T),
ADDBOTTOM(T, T )
A trait that species the association with subset con- introduces
?

straints as shown in Figure 9 can be presented as fol- R : A; B;  ! Bool

v : A; B;  ! T
lows: asserts
?

8 : ; a : A; b : B
(exists(a;) ^ R(a; b; )) ) exists(b;)
(exists(b;) ^ R(a; b; )) ) exists(a;)
ASSOCIATION-RR : trait
0
% axiom for the function v
includes exists(a;) ^ R(a; b; ) ) v(a; b; ) 6= ?
ASSOCIATION-R,
ASSOCIATION-R 0

asserts
8a : A; b : B;  :  In principle an association may have more than one
(exists(a;) ^ R (a; b; )) ) R(a; b; )
0

property, in which case we model each one separately.

3.4 Association Properties
Associations between types can have their own proper-
However, when an association has several properties it
is useful to create a type and attach it to the association
as shown in Figure 10.b. This can be modelled by a
function that returns an object of type C instead of a
value of type T? together with constraining axioms.
ties. For example, Figure 10.a shows an association R A qualied association is obtained from a multiple as-
between types A and B with a property v of value type sociation by adding a qualier. The reason for adding
T . That means, if an object a of type A is associated a qualier is to be more specic about a multiple as-
with object b of type B then there is always a value v of sociation by showing how a source object distinguishes
type T associated with both objects. between the destination objects. For example Figure

9
10.c shows a qualied association R with a qualier q
of type T. Informally, given an object of type A and A B
a value of type T we get an object of type B. Hence, R
the qualier q can be represented as a function with the
following signature: Figure 11: Aggregation
q : A; T;  ! B
which satises the following axiom: Hence a diamond on the association constrains the life-
8a : A; b : B;  :  (exists(a; ) times of the associated objects, which can be interpreted
independently of multiplicities.
^ R(a; b; )) ) (9v : T )(q(a; v; ) = b) For example, Figure 11 shows an aggregation between
If the qualier results in a set, then we have: two types A and B. The semantics of this notation is
that each object of type B must be associated with a
q : A; T;  ! Set[B] single object of type A (because there is no blob on the
line at that end) and it must remain associated with that
with the following axiom: object throughout its life-time. Objects of type B can be
8a : A; b : B;  :  (exists(a; ) created and destroyed during the life-time of an object
of type A but an object of type B cannot be associated
^ R(a; b; )) ) (9v : T )(b 2 q(a; v; )) with one object at one time and another at dierent time.
If an object of type A is destroyed so are its associated
Note that the case when a qualier yields a single object objects.
is subsumed in the general case where the qualier yields
a singleton set. Informally, it species that an object of type A can only
exist if it is associated with a set of objects of type B and
The trait specifying a qualied association is obtained this set must remain constant throughout the life-time
easily by adding the signature of q and its axiom to the of the object of type A. Formally, we have:
trait that species that association. That is:
8a : A; 1; 2 :   (exists(a; 1 ) ^ exists(a; 2 ))
ASSOCIATION-R : trait
includes ) ((8b : B)(exists(b; 1 ) ^ exists(b; 2 )
OBJECT-TYPE-A,
OBJECT-TYPE-B,
SPEC(T)
introduces ) R(a; b; 1) = R(a; b; 2))
R : A; B;  ! Bool
q : A; T;  ! B
asserts intuitively, if the object a exists in the states 1 and 2
8 : ; a : A; b : B then any object b of type B related to a in the state 1
(exists(a;) ^ R(a; b; )) ) exists(b;)
(exists(b;) ^ R(a; b; )) ) exists(a;) must also be related to a in the state 2 unless of course
exists(a;) ^ R(a; b; ) ) (9v : T )(q(a; v; ) = b) b does not exist in 2.
The life-time dependency of the associated objects is spe-
cied by the following axiom:
3.5 Aggregation Associations
8a : A; b : B;  :  (R(a; b; ) ^ exists(a; ))
An aggregation is a special kind of association and is
often referred to as a \whole-part" relationship, where ) (81 : )(earlier(; 1 ) )
an object, the aggregate, is made up of its parts. The
notation used for aggregations is to place a diamond on (exists(b; 1 ) ) exists(a; 1 )))
the association line adjacent to the type whose objects
are the aggregates. In Syntropy the meaning of an ag- which asserts that if a is associated with b in the state ,
gregation association is related to the life-times of the then if a is destroyed in subsequent states so is b. That
associated objects. That is the life-times of the \parts" is the life-times of the parts are contained in the life-time
are contained within the life-time of the \whole". The of the aggregate.
\parts" are permanently associated with the \whole",
and cannot be removed from it without being destroyed. A trait that species the aggregation shown in Figure 11
Conversely, destroying the \whole" destroys the \parts". can be presented as follows:

10
 ASSOCIATION-R : trait
includes A
OBJECT-TYPE-A,
OBJECT-TYPE-B
introduces
R : A; B;  ! Bool
asserts
8; 1 ; 2 : ; a1 ; a2 : A; b : B
(exists(a;) ^ R(a; b; )) ) exists(b;)
(exists(b;) ^ R(a1 ; b; )) ) exists(a1; )
% aggregation axioms B
exists(a1; 1 ) ^ exists(a1; 2 ) )
((8b : B)(exists(b;1 ) ^ exists(b;2 )
R(a1 ; b; 1 ) = R(a1 ; b; 2 ))
R(a1 ; b) ^ exists(a;1 ) )
(81 : )(earlier(; 1 ) ) Figure 12: Subtyping
(exists(b;1 ) ) exists(a;1 )
% R is injective
exists(b;1 ) ^ R(a1 ; b) ^ R(a2 ; b) ) a1 = a2
support a notion of subsorting, we use a function that
map between the corresponding sorts. That is, we intro-
4 Subtyping duce a function simulates with the following signature:
simulates : B ! A
Subtyping is a special relationship between two types,
known as the is-a relationship. This concept facilitates intuitively, the role of simulates is to map an object
the classication of objects in a conceptual hierarchy. (identity) of type B to the corresponding object in A
An assertion that type B is a subtype of type A implies that behaves like it. There are several constraints that
that objects that conform to type B \inherit" all the
attributes and associations of the supertype A, and can
be used in contexts where objects of type A are expec-
ted. The use of the word \inherit" here is related to
but should not be confused with class inheritance found
must be satised by the function simulates. The rst
constraint is that an existing object of type A must sim-
ulate an existing object of type B. Formally, we have:
8b : B  exists(b; ) == exists(simulates(b); )
in object-oriented programming. Subtyping is dened
to imply type conformance in the sense that an object Another constraint of simulates is that every object of
conforming to B always conforms to supertype A. type B is simulated by some object of type A. That
In [6], dierent notions of subtyping are dened for is simulates must be a total function. However, this
the essential, specication, and implementation models. property is ensured by the semantics of Larch which is
These are distinguished by using three concepts: struc- based on total algebras, so all specied functions are
tural conformance, behavioural conformance, and inher- assumed to be total.
itance. Structural conformance requires that the sub- It is useful to introduce a membership function
type must conform to the structure of the supertype as memberB that returns true if an object of type A is
dened by the type view. That involves only the attrib- in B and false otherwise:
utes and associations and not the dynamic behaviour of
objects. On the other hand behavioural conformance re- memberB : A;  ! Bool
quires that the behaviour of the subtype conforms to the
supertype as dened by the type's statechart. Subtyp- which satises the following axiom:
ing by inheritance allows the description of the subtype
to inherit some or all of the description of the super-
type, possibly with additions and modications. In the 8a : A;  :  exists(a; ) ) (memeberB (a; ) ()
essential model, subtyping is only structural, while for (9b : B)(exists(b; ) ^ simulates(b) = a))
the specication and implementation models subtyping
is both structural and behavioural. Since we are only The substitution property is the most important aspect
concerned with the semantics of type views, we deal with
structural subtyping in this section.
The notation used to assert that type B is a subtype of
A is shown in Figure 12. The notion of subtyping can be
formalized by requiring that the subtype is represented
by a sort which is a subsort (subset) of the sort repres-
enting the supertype. However, because Larch does not
11
of subtyping. It asserts that for any operation dened
on the supertype A, objects of type B can be substituted
where objects of type A are expected with the behaviour
of the operation preserved. The operation simulates
provides the tool to ensure the consistency of the inher-
ited operations and constraints of the subtype with those
of the supertype.
Attributes are among those inherited by subtypes. For In order to ensure that the constraints are also inherited
instance, if A has an attribute f of (value) type T, then we require the function simulates to be injective:
every subtype B of A must also have the same attribute.
That is the following signature is added to the specic- 8b1 ; b2 : B  simulates(b1 ) = simulates(b2 ) )
ation of B:
f : B;  ! T? b1 = b2
The possible mappings that f may dene are constrained The trait that species an association involving subtypes
by the simulates mapping, as follows: as in Figure 13 can be presented as follows:
8b : B;  :  f(b; ) == f(simulates(b); ) ASSOCIATION-R : trait
includes
A trait that species the subtype B shown in Figure 12 OBJECT-TYPE-A,
OBJECT-TYPE-B,
can be presented as follows: OBJECT-TYPE-C
introduces
R : A; C;  ! Bool
OBJECT-TYPE-B : trait R : B; C;  ! Bool
includes asserts
OBJECT-TYPE-A 8 : ; a : A; b : B; c : C
introduces (exists(a;) ^ R(a; c; )) ) exists(c;)
exists : B;  ! Bool (exists(c;) ^ R(a; c; )) ) exists(a;)
simulates : B ! A (exists(b;) ^ R(b; c; )) ) exists(c;)
f : B;  ! T (exists(c;) ^ R(b; c; )) ) exists(b;)
asserts
?
% axiom for the original and inherited associations
8 : ; a : A; b : B R(b; c; ) == R(simulates(b);c; )
exists(b;) == exists(simulates(b);)
% axiom relating the attributes of A and B
f (b; ) == f (simulates(b);)

where f : A;  ! T? is dened in OBJECT-TYPE-A. 4.1 State Types

The state of an object is determined by the values of its
A R C attributes and provides a summary of the condition of
the object. State types, depicted by boxes with a diag-
onal line in their top left hand corner, represent varying
subsets of the objects of the supertype where an indi-
vidual object can move between the subtypes. Each
B state type in the type view will correspond to a state in
Figure 13: Subtyping with inherited association.
Subtypes also inherit the associations and their con-
straints of the supertypes. For example in Figure 13
the association R is inherited in the subtype B. For
each association involving a type A, we introduce the
same association on subtype B, with B substituted for
A. That is if R denotes an association between A and
C, with the following signature:
R : A; C;  ! Bool
then we introduce another predicate R with the following
signature:
R : B; C;  ! Bool
The relationship between the two predicates is formally
expressed as follows:
8b : B; c : C;  :   R(b; c; ) == R(simulates(b); c; )
12
the statechart of the supertype which denes the trans-
itions that take objects from one state type to another.
The main purpose of state types is to eliminate optinal
attributes and associations.
A
f :T
B1 B2
Figure 14: State types
For example, Figure 14 depicts a type with two state
subtypes B1 and B2 . The state subtype B1 can be form-
alised as a subsort of sort A as in the previous section
with the diagonal line indicating that we do not require
that existence of the simulated object in A implies the
existence of the object that simulates it, formally we the statecharts formalism has been applied to specify the
have: dynamic behaviour of object-oriented systems [6] [14].
8b : B1 ;  :  
exists(b; ) ) exists(simulates(b); )
but we don't require that the following should always
hold:
8b : B1 ;  :   exists(simulates(b); ) ) exists(b; )
Consequently, the membership function memberB1 may
change its value depending on the state .
For Figure 14 we also have the follwoing axiom:
8a : A;  :   (memberB1 (a; ) _ memberB2 (a; ))
^: (memberB1 (a; ) ^ memberB2 (a; ))
that is, an object of type A can only be in B1 or B2 but
In such systems the behaviour of an object is specied
by a statechart that can be associated with its type or
class. The basic elements of a statechart that can be
associated with a type consist of a set of states, a list of
events, and a set of transitions.
As we mentioned before the state of an object is determ-
ined by the values of its attributes. The state space of
an object may be partitioned into equivalence classes
of states that exhibit qualitatively identical behaviour.
In this sense, a state is not a single combination of an
object's attribute values, but rather a set of such com-
binations that account for qualitatively identical beha-
viour and distinguishes the possible ordering of events.
In fact, statecharts in Syntropy depict the state space of
an object, partitioned according to \those states which
distinguish the possible ordering of events" ([6], p. 91).
Statecharts have dierent interpretations at the three
not in both.
5 The Semantics of Type Views
So far we have considered the semantics of object types,
associations between types,and subtyping in a type view.
The formal semantics of a type view can be easily ob-
tained from the semantics of object types and their as-
sociations in such type view. That is, the formal spe-
modelling levels (essential, specication and implement-
ation). Each such state in a statechart is depicted as a
round rectangle (state box) box.
Transitions in a statechart are triggered by events that
cause an object to move from one state to another.
These are indicated by arrows labeled with the trigger-
ing event. Events are broadcast within the system which
means that an event can be detected and responded to
simultaneously by a set of objects of a given type. The
general syntax of events is of the form \e(p[f])", where
e is the name of the event, p is a list of objects or value
cication of a type view  consists of a single trait that parameters and f (lter) is a boolean expression that
includes the traits of all the object types and associations is used by the receivers objects to decide whether to re-
derived from . spond to the event or not. This has the eect of targeting
The informal semantics of a type view (say ) of Syn- an event to a particular set of objects, namely those that
tropy can be dened as the set of object diagrams that satisfy the lter of the event. In most cases, however, an
are consistent with this type view. By applying the form- event will only aect one object of the type whose stat-
alisation that has been described so far, a type view echart is being dened. In such case the event takes the
is reduced to a formal specication expressed in the form e(b; x1; : : :; xn) where the identity of the object,
Larch Shared Language. It is well known that these b here, is passed as a parameter and the default lter
specications have algebras (sets of objects and func- (b = self) is used to indicate that only object b responds
tions between these sets) as their semantics [10]. By to the event. The additional parameters x1; : : :; xn are
formalising object diagrams as mathematical structures non-object parameters. The identier self denotes the
namely algebras it is possible to prove in a rigorous way current object.
that object diagrams are consistent with type views. The conditions under which an event may occur is spe-
cied by a precondition which can be expressed inform-
ally using natural language or formally as a logical ex-
6 The Semantics of Statecharts pression expressed in a formal language such as Z [12]
or V DM [7]. The eects caused by an occurrence of an
The statechart formalism is a graphical notation that is
used to specify the operational behaviour of a system,
in particular real-time systems. This formalism is an
extension of state transition diagrams and is often de-
scribed as incorporating state-diagrams, depth, ortho-
gonality, and broadcast-communication [11]. Recently,
13
event is similarly specied by a postcondition which is
a predicate involving two system states, the state before
the transition and the state after the transition. In the
essential model the notation e[pre]=[post] indicates that
the event e can only occur if its precondition pre holds,
and its postcondition post must hold between the state
before and after the transition it triggers. While in the value s1 ; : : :; sn . That is the induction axiom provides a
specication model, an event can still occur if its precon- way to reason about the values of type A-States.
dition does not hold, where the result of the transition From the induction axiom we can easily derive the fol-
is undened. Another dierence between the two mod- lowing:
els is that in the essential model, objects merely react
or respond to events by possibly changing their states. 8s : A-States  (s = s1 ) _ : : : _ (s = sn )
While, in the specication model, the mechanism util-
ized to eect object communication and collaboration is
the generation and detection (sensing) of events. That
is objects can also generate events and broadcast them
within the system. When an event is detected and accep-
ted by several objects, the generated events get queued
on a system queue. Thereafter, when the objects reach
a stable situation, the system resumes its process of ap-
plying the events from the queue one by one. Since in
this paper we are dealing with the essential model we
will not consider event generations.
Interpreting States
States in a statechart of an object type A can be rep-
resented as boolean functions (predicates) or as values
of an enumerated sort. We shall adopt the latter rep-
resentation of object states since it greatly reduces the
number of predicates required especially when the num-
ber of states is large. Hence, for each statechart associ-
ated with a given type A, we introduce an enumerated
sort A-States that characterises the set of possible states
represented in the statechart. Let s1 ; s2 ; : : :; sn be the
object states in a statechart associated with a given type
which intuitively asserts that A-States contains only the
states s1 ; s2; : : :; sn and nothing else.
In the Larch Shared Language the induction axiom is
expressed as follows:
sort A-States generated by s1 ; s2; : : :; sn
intuitively, this asserts that the only elements that be-
long to the sort are those listed after the generated by
clause and nothing else.
In order to maintain the state of an object, we introduce
a state function $ that returns the state an object is in.
Formally, we have:
$ : A;  ! A-States
for each object type A. Note that the state of an ob-
ject as represented by the sort A-States is basically a
summary of the condition of the object.
A
A, then each si , for 1  i  n, is specied as follows:
si : ! A-States
Each object state si is a nullary function that takes no
input (of arity 0); therefore, it is considered as a con-
stant. The object states for a type A must be distinct
elements of the sort A-States. This is expressed by the
following assertions:
si 6= sj ; for 1  i; j  n and i 6= j
these inequality axioms are needed to establish the
uniqueness
,
among object states. In general, for n object
states n2 (n choose 2) axioms are needed to establish
the uniqueness of each state.
Furthermore, it is required that the sort A-States be
e1
s1 s2
e2
e1(p[f1])[pre1]/[post1]
e2(p[f2])[pre2]/[post2]
Figure 15: Statechart for type A.
Figure 15 shows a statechart of a type A. This state-
chart contains two states s1 and s2 , two events e1 and
e2, and two transitions. The events are listed in the
textual part of the statechart with further informations
including their parameters. The arrows with a black
blob indicates that the state s1 to be the initial state for
objects of this type, entered upon the creation of an ob-
completely dened by the states s1 ; s2; : : :; sn. This can
be expressed as an induction axiom as follows:
F(s1 ) ^ : : : ^ F (sn ) ) (8s : A-States)F (s)
where F is a logical formula involving variables of type
A-States. Intuitively, the induction axiom asserts that
ject. Transitions are indicated by arrows labeled with
the triggering event. The transition from s1 to s2 is
triggered by event e1 and takes an object from state s1
to s2 . In the essential model of Syntropy, an event can
only occur if it can trigger a transition. Consequently,
e1 can not occur when the object is in state s2 , and
similarly, e2 can not occur when the object is in state
to prove a property about an arbitrary value of A-States s1 . The sort A-States can be specied by the following
it is needed to prove that the property holds for each trait:

14
 A-STATES : trait where pree (a; a1; x; ) denotes a predicate that may in-
introduces volve the parameters of the event e (a1 and x) and the
s1 : A-States object a in the state . And poste (a; a1; x; ) denotes a
s2 : A-States
asserts predicate that may involve the attributes of object a in
sort A-States generated by s1 ; s2 the states  and 0 , and the parameters of the event.
s1 6= s2
Assuming that the events e1 and e2 of Figure 15 take
The Larch Shared Language provides a shorthand nota- two parameters one of type A and the other of type T ,
tion for enumerated sorts. For instance, using the short- then we introduce a trait A-EV ENTS that species the
hand notation, the sort A-States is specied as follows: events that are listed in the statechart of A as follows:
A-States enumeration of s1 ; s2 A-EVENTS : trait
includes
SPEC(T),
This is useful when there are a large number of states. OBJECT-TYPE-A
INTERVAL
If the state subtypes B1 and B2 of Figure 14 correspond introduces
e1 : A; A; T;  ! Bool
to the states s1 and s2 of Figure 15 respectively, then the e2 : A; A; T;  ! Bool
relationship between the state subtypes and the object filtere1 : A; A; T;  ! Bool
pree1 : A; A; T;  ! Bool
states is given by the following axioms: poste1 : A; A; T;  ! Bool
filtere2 : A; A; T;  ! Bool
pree2 : A; A; T;  ! Bool
8a : A;  :  memberB1 (a; ) == $(a; ) = s1 poste2 : A; A; T;  ! Bool
asserts
8a;a1 : A; x : T; i : 
8a : A;  :  memberB2 (a; ) == $(a; ) = s2 filtere1 (a; a1 ; x; ) == f1
pree1 (a; a1 ; x; ) == pre1
poste1 (a; a1 ; x; ) == post1
filtere2 (a; a1 ; x; ) == f2
Interpreting Events pree2 (a; a1 ; x; ) == pre2
poste2 (a; a1 ; x; ) == post2
The events of the system can be modelled as boolean where traits SPEC(T) and OBJECT-TYPE-A specify
functions with the appropriate signatures. For example, the type T and the object type A respectively. The
if an event e is listed in the statechart of a type A and precondition and postcondition of event e1 (Figure 15)
has only two parameters a of object type A and x of are pre1 and post1 respectively.
value type T, then e can be moddeled as the following
function: The creation operation of an object type can be mod-
e : A; T;  ! Bool elled as a boolean function with the appropriate signa-
ture. For example, if an object type A has attributes of
where e(a; x; ) asserts that the event occurs in the state value types T1 ; : : :; Tn then its creation operation can be
 with parameters a and x. The parameter a must sat- modelled as a function with the following signature:
isfy the predicate exists for the event to occur. Formally
we have: create : A; T1; : : :; Tn ;  ! Bool
8a : A;  :   e(a; x; ) ) exists(a; ) The function create is to satisfy the following
intialisation axiom:
A function filtere that extracts the lter of an event e
can be introduced as follows: 8a : A; x1 : T1 ; : : :; xn : Tn ;  : 
filtere : A; A; T;  ! Bool create(a; x1; : : :; xn; ) )
where filtere (a; a1; x; ) denotes a predicate involving (exists(a; 0 ) ^ : exists(a; ) ^
the attributes of the object a and the parameters of the
event in the state . Actually, the object a represents v(a; 0 ) = (x1 ; : : :; xn))
the self object. where v(a; 0 ) denotes the value of the newly created
Preconditions and postconditions can also be modelled object with identity a in the state 0 . This can be dened
as boolean functions with the following signatures: as follows:
pree : A; A;  ! Bool v(a; 0 ) =def (att1 (a; 0); : : :; attn(a; 0))
poste : A; A;  ! Bool where att1; : : :; attn are the attributes of the object a.

15
The assertion create(a; x1; : : :; xn; ) denotes that the
creation operation executes in the state . The initial-
isation axiom asserts that invoking the creation opera-
tion in a state  will create an object of identity a with
initial attribute values x1; : : :; xn in the state 0 . The
constraint on the creation operation is that a does not
refer to an existing object in the state .
In the essential model, an event cannot occur unless its
precondition is true and the existing objects are in the
source state of the transition it labels. For example, for
Figure 15, the absence of a transition from s2 labelled by
e1 means that e1 cannot occur when the receiver objects
8a1 : A;  :   e1 (a1 ; x; ) )
(8a 2 A())(:filtere1 (a; a1; x; ) )
v(a; ) = v(a; 0 ) ^ $(a; ) = $(a; 0 ))
where v(a; ) and v(a; 0 ) denote the values of the object
a before and after the transition respectively.
When an event is not listed in statechart, we require
the event to go undetected by the object (rather than
blocked). This can be ensured by interpreting unlisted
are in state s2 . Formally, we have (ignoring the lter)
the following axiom (permission axiom):
8a1 : A;  : ; x : T  e1 (a1 ; x; ) )
(8a 2 A())($(a; ) = s1 ^ pree1 (a; a1; x; ))
Intuitively, the permission axiom asserts that e1 can only
occur if all existing objects of type A are in state s1 and
the precondition pre1 holds for each object. This implies
that some objects which may not satisfy the precondition
or are not in the state s1 (i.e. objects in state s2 ) can
prevent the event from occurring. The way to avoid this
events as having a lter of false.
We can introduce a locality axiom which asserts that
objects of type A can only change their states as a result
of an event listed in A's statechart occurring. Formally
we have:
8a1 ; a2 : A; x : T;  :  
:(e1(a1 ; x; ) _ e2 (a2 ; x; )) )
(8a 2 A())(v(a; ) = v(a; 0 ) ^ $(a; ) = $(a; 0))
where e1 and e2 are the only events listed in the state-
chart of A.
problem, is to use lters which lter out those objects A trait that species the statechart shown in Figure 15
interested in the event. For instance, taking the lter can be presented as follows:
of e1 into account, the precondition has only to hold
for those objects which pass the lter. The permission A-STATE-CHART : trait
includes
axiom can now be stated as follows: OBJECT-TYPE-A, A-STATES,
A-EVENTS, SET[A]
introduces
8a1 : A;  : ; x : T  e1 (a1 ; x; ) ) A :  ! Set[A]
$ : A;  ! A-States
create : A; T1 ; : : : ; Tn ;  ! Bool
(8a 2 A())(filtere1 (a; a1; x; ) ) asserts
8a1; a2 ; a : A; x; y : T;  : ;
$(a; ) = s1 ^ pree1 (a; a1; x; )) x1 : T1; : : : ; xn : Tn
a 2 A() == exists(a;)
create(a;x1 ; : : : ; xn ; ) )
The state transition axiom of event e1 for Figure 15 can exists(a; ) ^ : exists(a;) ^
0

be stated as follows: v(a;  ) = (x1 ; : : : ; xn )

0

e1 (a1 ; x; ) )
(8a 2 A())(filtere1 (a; a1 ; x; ) )
$(a; ) = s1 ^ pree1 (a; a1 ; x; ))
8a1 : A;  : ; x : T  e1 (a1 ; x; ) ) e2 (a1 ; x; ) )
(8a 2 A())(filtere2 (a; a1 ; x; )
(8a 2 A())((filtere1 (a; a1; x; ) ^ $(a; ) = s1 ^ ) $(a; ) = s2 ^ pree (a; a1 ; x; ))
e1 (a1 ; x; ) ) % transition2 axiom for e1
(8a 2 A())(filtere1 (a; a1 ; x; ) ^ $(a; ) = s1 ^
pree1 (a; a1; x; )) pree1 (a; a1 ; x; )
) $(a;  ) = s2 ^ poste1 (a; a1 ; x; ))
) $(a; 0 ) = s2 ^ poste1 (a; a1; x; ))
0

e2 (a1 ; x; ) )
(8a 2 A())(filtere2 (a; a1 ; x; ) ^ $(a; ) = s2 ^
pree2 (a; a1 ; x; )
A similar axiom holds for the event e2 . ) $(a;  ) = s1 ^ poste (a; a1 ; x; ))
0

:(e1 (a1 ; x; ) _ e2 (a2 ; y; ))2 )

The above axiom expresses the eects of the transition (8a 2 A())(v(a; ) = v(a;  ) ^ $(a; ) = $(a;  ))
0 0

on existing objects that pass the lter. Those objects

that do not satisfy the lter of an event ignore it. As- where the traits OBJECT-TYPE-A, A-STATES specify
suming that the same event cannot occur with dierent the sort A, A-States respectively. The trait A-EVENTS
parameters simultaneously, then these objects undergo species the events that are listed in the statechart of A,
an idle step. Formally, we have: while the trait SET[A] species the power sort of A.

16
 Allowed Events
A
Allowed events are those that are accepted in any state;
s1
e[g]
s2 sometimes they will cause a transition, otherwise they
will be ignored. Allowing an event is equivalent to
e(a:A)[pre]
(quoted from [6]):

 including an unguarded self-transition for the event

Figure 16: Statechart with guard. for every state without an existing transition for the
event; and
Guards  including a guarded self-transition for all states
with one or more existing guarded transitions for
Transitions in a statechart may have guards that de- the event, with the guard set to be the logical "not"
termine the target state of an object. Guards are logical of the logical "or" of the existing guards.
predicates that must be true when the event occurs if
the transition is to be taken. A guard g of an event can
be modelled as a boolean function with the following
signature (assuming that the event takes one parameter A
of type A): e[g]/[post]
s1 s2
ge : A; A;  ! Bool
e(a:A)[pre] allow: e
For example, Figure 16 shows a guarded transition with
guard g triggered by event e. In this case, for e to occur
the guard g must be true. The permission axiom for e Figure 17: Allowed events.
can be stated as follows:
8a1: A;  :   e(a1 ; ) ) For instance the statechart in Figure 17 includes an al-
lowed event e indicated by the keyword allow. Since the
(8a 2 A())($(a; ) = s ^ pree (a; a1; ) ^ ge (a; a1; )) precondition for e is given in the event list, we have the
If the transition originates from states s1 ; : : :; sn with following permission axiom:
guards g1 ; : : :; gn respectively, then the permission ax-
iom is stated as follows: 8a1 : A;  :   e(a1 ; ) )

8a1 : A;  :   e(a1 ; ) ) (8a 2 A())pree (a; a1; )

(8a 2 A())(($(a; ) = s1 ^ pree (a; a1; ) ^ g1(a; a1 ; ))
this means that allowed events cannot bypass precondi-
_::: tions specied in the event list. There are three trans-
_ ($(a; ) = sn ^ pree (a; a1; ) ^ gn(a; a1; ))) ition axioms for e. The rst transition axiom corres-
We also require that distinct transitions for the same ob- ponds to the case where the existing objects are in state
ject cannot occur in the same state (disjoint transitions s1 and the guard g is true when the event occurs:
axiom):
8a1; a2 : A;  :   :(e1(a1 ; ) ^ e2 (a2 ; )) 8a1 : A;  :   e(a1 ; ) )
The initialization axiom for the statechart in Figure 15 (8a 2 A())(((a in s1 )i ^ pree (a; a1; ) ^
(and Figure 16) is stated as follows:
8a : A;  :   create(a; ) ) ge(a; a1; )) ) (a in s2 ) ^ poste (a; a1; ))
0

(exists(a; 0 ) ^ :(exists(a; )) ^ $(a; 0 ) = s1 ) where the postcondition poste (a; a1 ; ) is post with a is
intuitively, this asserts that a newly created object substituted for self.
of type A enters the designated initial state s1 of its The second axiom corresponds to the case where the
statechart. Any identied postcondition of create is also existing objects are in state s1 and the guard g is false
added to the consequent of these axioms. when the event occurs (self transitions):

17
 applies to both states s1 and s2 , thus reducing the num-
ber of transitions. The nested state s is designated as
8a1 : A;  :   e(a1 ; ) ) a default state in the statechart, indicated by the arrow
with a black blob. This means, a newly created object of
(8a 2 A())(((a in s1 )i ^ pree (a; a1; )^ type A will initially enter the state s. The default state
:ge (a; a1; )) ) (a in s1 ) ) within the nested state s is s1 . In order to deal with
the nested case, we introduce the functions default and
0

The third axiom corresponds to the case where the ob- sub that dene for each state its default substate and its
jects are in state s2 when the event occurs (self trans- immediate substates respectively. Formally, we have:
itions):
8a1 : A;  :   e(a1 ; ) ) default : A-States ! A-States
(8a 2 A())((a in s2 )i ^ pree (a; a1; ) sub : A-States ! Set[A-States]
) (a in s2 ) ) 0
Intuitively, given a state s the function default returns
In the last two axioms the postcondition of the event is the default substate of s and the function sub returns a
not required to hold since the objects are unaected by set that contains its substates. The sort Set[T ] is the
the transitions. power sort for any sort T.
The relationship between the functions default and sub
A is given by the following axiom:
s
8s : A-States  default(s) 2 sub(s)
e
s3 which simply asserts that the state default(s) is a sub-
s1 s2
state of s.
e(a:A[f])
The function sub is to satisfy the following axiom:
8s : A-States  s 2= sub(s)
Figure 18: Statechart with nested states
which intuitively asserts that a given state s is not a
member of the set containing its substates. A state is
basic (not nested) if it has no substates, hence we intro-
6.1 Nested States duce the following predicate basic as follows:
basic : A-States ! Bool
States in a statechart can be nested, where a state can
be decomposed into substates. The concept of nesting
states was introduced to reduce the number of trans-
itions in a statechart. Nested states can be OR-states
or AND-states. OR-states are related to their substates
by exclusive or, which means that if an object is in an
OR-state then it must be in only one of its substates.
On the other hand, AND-states are related to their sub-
states by and, which means that if an object is in an
AND-state then it must be in every one of its substates.
AND-states give rise to orthogonal state machines (see
which satises the following axiom:
8s : A-States  basic(s) == (sub(s) = fg)
where fg denotes the empty set.
It is also convenient to introduce the root state root as
a constant of the sort A-States:
root : ! A-States
section 5.2).
OR-States
The statechart in Figure 18 contains two states s and s3 ,
where s is a nested state with substates s1 and s2 . The
interpretation of this statechart is as follows. An object
of type A can only be in either s or s3 but not in both. If
an object is in state s, then it must be in either s1 or s2
and not in both. The transition labelled by the event e
18
which satises the following axiom:
8s : A-States  root 2= sub(s)
that is, the root state is not a substate of any other state.
The root state can be regarded as the state representing
the whole statechart, i.e. state of existence.
Since objects can now have more than one state, we
introduce a function in with the following signature:
in : A; A-States;  ! Bool
we shall abbreviate in(a; s; ) by (a in s)i which asserts A-STATES : trait
that the object a is in state s (for state ). Before we includes
introduce the axioms of the function in we introduce a SET[A-States]
introduces
function issuper as follows: root : A-States
s : A-States
s1 : A-States
issuper : A-States; A-States ! Bool s2 : A-States
s3 : A-States
sub : A-States ! Set[A-States]
basic : A-States ! Bool
which satises the following axiom: default : A-States ! A-States
issuper : A-States;A-States ! Bool
asserts
8s1 ; s2 : A-States  issuper(s1 ; s2 ) == s2 2 sub(s1 ) sort A-States generated by root; s; s1; s2 ; s3
8ss;ss1 : A-States
ss 2= sub(ss)
root 2= sub(ss)
intuitively, issuper(s1 ; s2) asserts that s1 is a par- basic(ss) == (sub(ss) = fg)
issuper(ss;ss1 ) == ss1 2 sub(ss)
ent state of s2 . From this, it follows easily that root 6= s; root 6= s1 ; root 6= s2
:issuper(s; root) holds for any state s. root 6= s3 ; s 6= s1
s 6= s2 ; s 6= s3
The function in is to satisfy the following axioms: s1 6= s2; s1 6= s3 ; s2 6= s3
sub(root) = fs; s3 g
sub(s) = fs1 ; s2 g
sub(s1) = fg
sub(s2) = fg
8a : A;  :   exists(a; ) ) (a in root)i sub(s3) = fg
default(root) = s
default(s) = s1

8a : A;  : ; s1 : A-States  (a in s1 )i By using the shorthand notation for enumerated sorts

the above trait can be simplied.
^: basic(s1 ) ) (9!s2 2 sub(s1 ))(a in s2 )i
A

8s1 ; s2 : A-States  (a in s2 )i ^ issuper(s1 ; s2 ) s

t
e
s2

) (a in s1 )i t1
s1
e
The rst axiom asserts that any existing object a of type
A will always be in the root state. The second axiom
is the nesting axiom which asserts that if an object is
in a nested state then it must also be in one and only
one of its substates. The third axiom asserts that if an
object is in a state then it must also be in its parent
state. The expression (9!s2 2 sub(s1 ))F (s2 ) expresses
the existence of a unique substate s2 of state s1 such
that F(s2 ) holds, and is an abbreviation of the following
assertion:
(9s2 : A-States)(s2 2 sub(s1 ) ^ F(s2 ))^
(8s1 ; s2 : A-States)
icting Transitions
icting transitions. For ex-
(s1 2 sub(s) ^ F (s1 ) ^ s2 2 sub(s) ^ F (s2 ) ) s1 = s2 )
e(a:A[f])
Figure 19: Overriding transitions
Transitions from a nested state s are treated as trans-
itions from each substate of s, while transitions into s
are regarded as transitions into a designated initial state
(default substate) of s. That is, each state transition ax-
iom for a transition on an object a targeted on s will
actually assert (a in default(s)) in its consequent.
0
Con
An event can trigger con
ample, an event can trigger two transitions leading to
two dierent states, one from a superstate, while the
A trait that species the sortA-States of Figure 18 can other from one of its substates. In such a case, the pri-
be presented as follows: ority is given to the transition from the substate. As an

19
example, consider the statechart depicted in Figure 19.
This statechart contains a transition from s to t, and a
transition from s1 to t1 , both triggered by the event e.
The state s1 now has two transitions leaving it for the
event e, one direct and the other by virtue of the nesting.
Giving a priority to the direct transition is equivalent to
introducing the guard : (a in s1 ) for the transition from
the superstate. Formally, the state transition axioms can
from the left-hand machine and one state from the right-
hand machine.
For each state machine in the statechart, we introduce
a sort that contains its states. Let A-States1 and
A-States2 be the state sorts for the left-hand and right-
hand machines respectively. The sort A-States1 con-
tains the states s1 and s2 , while the sort A-States2 con-
tains the states s2 and s4 . Using Larch notation, these
be expressed as follows: sorts can be specied as follows:
8a1 : A;  :   e(a1 ; ) )
A-States1 enumeration of s1 ; s2
(8a 2 A())(filtere (a; a1; ) ^ (a in s)i ^ : (a in s1 )i
A-States2 enumeration of s3 ; s4
^ pree (a; a1; ) ) (a in t) ^ poste (a; a1 ; ))
In order to maintain the states of an object, we introduce
0

and two functions $1 and $2 with the following signatures:

8a1 : A;  :   e(a1 ; ) )
(8a 2 A())(filtere (a; a1; ) ^ (a in s1 )i $1 : A;  ! A-States1
^ pree (a; a1; )) ) (a in t1) ^ poste (a; a1; ))
$2 : A;  ! A-States2
0

In these axioms we assumed that the two transitions

have the same postconditions which may not always be So an existing object a of type A can have two states
the case. However, when the event triggers two trans- denoted by $1 (a; ) and $2(a; ) in the state . The com-
itions with dierent postconditions, the axioms can be bined states can be represented as pairs of states with
modied easily.
In Syntropy, it is not allowed to have more than one
transition for an event at the same level of nesting un-
less they were guarded. This is necessary to make the
simulation deterministic. However, with an appropriate
priority scheme such transitions may be allowed.
rst components belonging to A-States1 and second
components belonging to A-States2 . Let A-States be
the product sort of these sorts, then we introduce a func-
tion in with the following signature:
in : A; A-States;  ! Bool
which satises the following axiom:
A
8a : A; s : A-States;  : 
s1 s3
e1 e2 (a in s)i == ($1 (a; ) = fst(s)) ^ ($2 (a; ) = snd(s))
s2 s4 where the functions fst (rst) and snd (second) extract
e1(a:A[f1])
e2(a:A[f2])
Figure 20: Orthogonal state machines
6.2 Orthogonal State Machines
The idea of orthogonal state machines was introduced
to reduce the number of states in complex models. For
example, Figure 20 shows a statechart with two ortho-
gonal state machines separated by a dashed line. The
left-hand machine contains two states s1 and s2 , while
the right-hand machine contains two states s3 and s4 .
An object of type A must, at all times, be in one state
20
the rst and second components of a pair respectively.
The axioms for each event and transition can be stated
as before. For instance, the permission axiom of event
e1 can be stated as follows:
8a1 : A;  :   e1 (a1 ; ) )
(8a 2 A())(filtere1 (a; a1; ) ) $1 (a; ) = s1 )
similarly for event e2 .
The state transition axioms for each event can also be
stated separately as before.
If the states in the orthogonal components don't over-
lap then it is sucient to only introduce one state sort
A-States that contains all the states in the orthogonal
machines together with the function in.

A stated as follows:
e1
s1 s3 s5
e1
e2
s2 s4
e1(a:A[f1]) e1(a:A[f1])
e2(a:A[f2])
Figure 21: Statechart with separate event lists.
The list of events in the statechart of Figure 20 apply
to both state machines. If an event labels a transition
in each machine, then the event can occur by triggering
at least one transition in any machine. If it is required
that an event can only occur if it triggers two transitions
one in each machine then the notation can be extended
by providing a separate event list for each machine. For
example, Figure 21 shows two orthogonal state machines
with separate event lists. In this case, each state machine
is regarded as a separate unit in the statechart. The
event e1 can only occur if it triggers two transitions,
one in each separate machine. The axiomatization of
such a statechart consists of providing the axioms of each
machine separately. For instance, the permission axioms
for the event e1 in Figure 20 can be stated as follows:
8a1 : A;  :   e1 (a1; ) )
(8a 2 A())(filtere1 (a; a1; ) ) $1 (a; ) = s1 )
8a1 : A;  :   e1 (a1; ) )
(8a 2 A())(filtere1 (a; a1; ) ) $2 (a; ) = s3 )
These two axioms are equivalent to the following:
8a1
in either machine. The permission axiom in this case is
8a1 : A;  :   e1 (a1 ; ) )
(8a 2 A())(filtere1 (a; a1; ) )
($1 (a; ) = s1 _ $2 (a; ) = s3 )
The state transition axioms for event e1 are stated as
follows:
8a1 : A;  :   e1 (a1 ; ) )
(8a 2 A())(filtere1 (a; a1; ) ^ $1(a; ) = s1
) $1(a; 0 ) = s2 )
8a1 : A;  :   e1 (a1 ; ) )
(8a 2 A())(filtere1 (a; a1; ) ^ $2(a; ) = s3
) $2(a; 0 ) = s5 )
This approach of dealing with orthogonal state machines
can be easily generalized to the case where there are
more than two orthogonal machines each containing nes-
ted (OR-states) states.
7 Subtyping of Statecharts
In this section we deal with subtyping of statecharts.
In Syntropy there are a number of transformations on
statecharts which are intended to represent subtyping of
the corresponding object types. We consider some of
these in the following sections.
7.1 Inheritance of Statecharts
The simplest case is where the subtype inherits the su-
: A;  :   e1 (a1; ) ) pertype chart without any modications. In the absence
of any dened extensions in the subtype, the chart of
(8a 2 A())(filtere1 (a; a1; ) ) (a in (s1 ; s3 ))i ) the subtype consists of supertype chart or in the case of
The state transition axiom for e1 can be stated as fol- multiple inheritance, an orthogonal combinations of the
lows: supertypes charts. Assuming we have single inheritance,
then the sort of states B-States consists of exactly the
8a1 : A;  :   e1 (a1; ) )
same states as A-States. The function in is also inher-
ited in the subtype theory:
(8a 2 A())(filtere1 (a; a1; ) ^ (a in (s1 ; s3 ))i
) (a in (s2 ; s5 )) ) 0
in : B; A-States;  ! Bool
intuitively, if event e1 occurs when the object a is in s1 which satises the following axiom:
and s3 then after the transition, the object a will be in
states s2 and s5 . If on the other hand the two state ma- 8b : B; s : A-States;  :
chines share the same event list (not independent), then
event e1 can occur by triggering at least one transition (b in s)i = (simulates(b) in s)i

21
The axioms that holds for type A also holds for subtype transition axiom in the subtype theory can be stated
B. For instance, if in the theory of A we have: as follows:
8a : A; b : B;  :  
8a : A; s : A-States;  :  
e(a; ) ^ (simulates(b) = a) ^ (b in s1 )i
(a in s)i = (a in s1 )i _ (a in s2 )i
) (b in s2 )
where s is a nested state with substates s1 and s2 , then
0

it easy to show that this also holds for objects of type this axiom can be easily derived from the axiom in the
B, because of the axiom relating the two in functions. supertype theory. Hence, the state transition axioms of
If we assume that b is an object of type B then we have an inherited event remains valid for the subtype B and
simulates(b) is an object of type A. By instantiating therefore there is no need for them to be stated again.
the universal quantication we get the following:
(simulates(b) in s)i =
(simulates(b) in s1 )i _ (simulates(b) in s2 )i
by using the axiom relating the two functions in and
simulates and universal generalization we obtain:
8b : B; s : A-States;  :  
(b in s)i = (b in s1 )i _ (b in s2 )i
The axioms for the new events introduced for the sub-
type B can be expressed in the normal way.
The other simple case is where the statechart of the su-
pertype is inherited, and a new separate chart for the
subtype is introduced. The states in the subtype chart
have distinct names from those of the supertype, thus
forming a disjoint set with that of the supertype chart
but may share some transitions. In this case the res-
ulting sort of states RB-States contains the combined
states an object of type B might have. Formally, we
Alternatively, we could introduce a sort B-States for the
subtype B together with a mapping smap that maps a
state in B-States to the corresponding state in A-States.
In this case the inherited function in will have the fol-
lowing signature:
in : B; B-States;  ! Bool
dene RB-States to be the cartesian product of the sorts
A-States (inherited states), and the sort B-states (new
states) containing the newly introduced states. For this
we introduce the following functions as follows:
in : B; B-States;  ! Bool
in : B; A-States;  ! Bool
and satises the following axiom:
in : B; RB-States;  ! Bool
8b : B; s : B-States;  :  
which satisfy the following axiom:
(b in s)i = (simulates(b) in smap(s))i
8b : B; s : RB-States;  :
where the function smap has the following signature:
smap : B-States ! A-States (b in s)i = (b in fst(s))i ^ (b in snd(s))i
We also assume that the initializations of the two types
Events are also inherited from the supertype. The oc- are synchronised in the sense that creating a object of
currence of an event in the supertype A will also aect type B automatically creates an object of type A. Form-
objects of the subtype B. For instance if event e occurs ally, we have:
on an object a of type A which simulates an object b of
type B, then b is also aected by the event. In addition createB (b; ) ) createA (simulates(b); )
the state transition axioms for event e on b can be de- where createA and createB are the creation operations
rived from those axioms of e on a. To illustrate this we of A and B respectively:
assume that event e has the following transition axiom
on object a with default lter [self = a]: createA : A;  ! Bool
8a : A;  :  
createB : B;  ! Bool
e(a; ) ^ (a in s1 )i ) (a in s2 )
0
The axioms of the inherited transitions still hold for the
The objects of B which are interested in the event e subtype B, and the axioms for newly introduced trans-
must satisfy the lter expressed as [simulates(self) = itions can be expressed as in previous sections. Shared
a]. That means only one object b for which transitions can be treated as in the case with orthogonal
simulates(a) = b is interested in the event, and the machines.

22
7.2 Expanding a State The axioms of the new states introduced in the subtype
can be stated easily.
States in the supertype chart can be modied or rened
in several ways. First, a basic (atomic) state can be de-
composed into several disjoint substates (OR-states) or
into orthogonal components (AND-states). States can
also be extended by adding substates to an OR-state
and by adding orthogonal components to an AND-state.
The decomposition of a basic state into nested states will
yield a theory extension since the introduction of new
substates does not aect existing axioms, and merely
introduces new axioms for each new substate. The sort
B-States will contain the states an object of subtype
B might have. These states include all the states of su-
pertype A plus the newly introduced substates of the ex-
tended states. We can establish the relationship between
State transition axioms to the extended state are
strengthened as a result, because they are now redir-
ected to the designated initial (default) substate of this
state.
7.3 Weakening Transition Guards and
Preconditions
The transformation of weakening the guards and pre-
conditions of transitions does yield a theory extension
in the absence of permission axioms. However, once
we admit these axioms in our theory, it clearly does
the two sorts B-States and A-States by dening a map- not yield a theory extension. The main reason behind
ping smap with the following signature: the permission axioms is to formalise the assertion that
events cannot occur unless they trigger some transitions
smap : B-States ! A-States in the statechart. This is basically the essential model
interpretation of a statechart according to [6]. However,
The states that are not rened or extended are mapped the specication and implementation models appear to
in a one-to-one fashion to the corresponding states, with interpret guards as preconditions in the usual sense of
the structure of the states preserved. The extended VDM [7], that is, if the precondition fails to hold then
states together with their substates are mapped to the the event concerned can still occur, but the response of
original extended basic states. the software is not dened.
Before formally expressing the axioms of the function For instance if the event e triggers a transition guarded
smap, we introduce the function ext with the following by g1 in the supertype chart, then we have the permis-
signature: sion axiom:
ext : A-States ! Bool
intuitively, ext(s) asserts that the state s is extended. 8a1 : A;  :   e(a1 ; ) )

The function smap is to satisfy the following axioms:
8b : B; s : B-States  :ext(smap(s))
) (b in s)i = (simulates(b) in smap(s))i
this axiom ensures that the axioms for the inherited
states hold for the subtype. In addition we may re-
quire additional axioms to preserve the structure of the
mapped states. For instance we may introduce the fol-
lowing axiom:
8s : B-States  :ext(smap(s))
) basic(s) = basic(smap(s))
The other axioms for the function in can be presented
as follows:
8b : B; s : B-States  ext(smap(s)) ^ :basic(s)
) (b in s)i = (simulates(b) in smap(s))i
8b : B; s : B-States  ext(smap(s)) ^ basic(s)
(8a 2 A())(filtere (a; a1; ) ) g1(a; a1; ))
if the guard g1 is replaced in the subtype by a weaker
guard g2, then we have the following permission axiom
for the subtype:
8a1 : A;  :   e(a1 ; ) )
(8b 2 B())(filtere (simulates(b); a1 ; ) )
g2 (simulates(b); a1 ; ))
since g1 ) g2 this axiom is weakened, hence the super-
type permission axiom is not guaranteed to hold.
7.4 Splitting and Re-targeting Trans-
itions
As for transitions new ones can be added to the sub-
type's statechart, and certain modications are allowed
in the original inherited ones. One such modication
) (b in s)i ) (simulates(b) in smap(s))i is to change the target state (called re-targeting) t of

23
an inherited transition to a substate ti of t in the new
model. The state t must be unstructured in the original
model, i.e. we re-target the transition triggered by e in e[g]/act

combination with dividing t into new substates. That s t

is necessary to achieve theory extension because other-

wise the transition could be re-directed to a substate of
t disjoint from its original target, namely the designated
initial substate of t. Re-targeting results in a stronger
theory for the new model, because the consequent of the
state transition axiom for e will become stronger.

e e[g]/act, act1
s1
s t e[g]/act, act2 t
s2
e[g]/act, act3
s3

Figure 23: Source splitting

and postconditions must be repeated on each of the new

transitions, and these can additionally dene new gen-
t
erations and postconditions for particular cases. The
guards cannot be changed. Every substate of s must
e
t1
s
become a source for a split case of the transition, other-
t2
wise we do not have theory extension.
The permission axioms for e are preserved by a source-
Figure 22: Re-targeting splitting (an indeed, this is the case even if not every
substate of the source state is maintained as a source
of a split transition). State transition axioms for e are
Figure 22 shows a simple example of re-targeting a strengthened because (a in s) implies that (a in si ) for
transition triggered by event e to state t1 which is a sub- some substate; but then the new model implies that e
state of the original state t. In this case the transition from si establishes all the generations and postcondi-
axiom in the subtype theory is stated in the following tions that e from s did in the previous model. Source
way: splitting is useful for generating dierent events in ad-
dition to the generations of the original transition and
8a1 : A;  :   e(a1 ; ) ) is only meaningful in the specication model, because
in the essential model there is no concept of generating
(8b 2 B())(filtere (simulates(b); a1 ; ) ^ (b in s)i events.
) (b in t1 ) ) 0 A (non-initial) transition e can be split at its target state
t by breaking the original guard into several (disjoint
on the other hand the original axiom for the super- and exhaustive) cases, assigning these to new transitions
type still hold for the subtype since (b in t1 ) implies 0
for the same event, and giving these targets within or at
(b in t) .0 the original target. New generations and postconditions
can be added to each case. Again t must be unstructured
If the re-targeted state of a transition is not substate of in the original model. For example Figure 24 shows an
the original target then clearly we do not have a theory example of a target splitting of a transition triggered
extension because this would violate the state transition by event e with guard g. The transition is split into
axiom for the transition concerned. two transitions guarded by g1 and g2 respectively. The
A transition can be modied by splitting either its source axioms for these transitions in the subtype theory are
or its target. Figure 23 shows a simple example of states as follows:
a source splitting of a transition triggered by event e.
In a source splitting, the original guards, generations 8a1 : A;  :   e(a1 ; ) )

24
 9 Related Work
e[g]
s t Bicarregui and Lano [1] give a high level formaliza-
tion of the essential model of Syntropy expressed in
the Object Calculus [5] which is a formalism based on
structured rst order theories composed by morphisms
between them. While this approach provides an eleg-
ant and structured formalisation it can be dicult to
understand by non-specialists. On the other hand the
reason for basing our approach on Larch is that Larch
has a simple syntax and semantics and provides tools
that helps in developing specications such as a syntax
t
checker and a theorem prover. In fact, once the theor-
ems of a specication are formally stated in Larch, their
e[g1]
t1
s
e[g2] proofs are almost mechanical -a matter of manipulating
t2
symbols- and could be done with the assistance of the
Larch Prover (LP).
Figure 24: Target splitting Bourdeau and Cheng [3] give a Larch formalisation of
OMT object models diagrams. Their formalisation deals
with the static aspects of the model and relies heavily
on formalising instance diagrams as algebras to form-
(8b 2 B())((filtere (simulates(b); a1 ; )^ alise the OMT semantics that relate objects models to
(b in s)i ^ g1(simulates(b); a1 ; )) ) (b in t1)i ) instance diagrams.
8a1 : A;  :   e(a1 ; ) )
(8b 2 B())((filtere (simulates(b); a1 ; )^ 10 Conclusions and Future Work
(b in s)i ^ g2(simulates(b); a1 ; )) ) (b in t)i )
In this paper we have used the Larch Shared Language
these two axioms guarantee that the axiom for the trans- to provide a precise semantics for most of the model-
ition in the supertype theory still hold in the subtype ling notation of the development method Syntropy. The
theory, namely: type and state views of the model were given precise
semantics. The semantics enables the type view dia-
8a1 : A;  :   e(a1 ; ) ) grams and the statecharts to be treated as formal spe-
cications, and therefore overcomes many of the ana-
(8b 2 B())((filtere (simulates(b); a1 ; )^ lytical limitations caused by using graphical notations
(b in s)i ^ g) ) (b in t)i )
that is because we have g = (g1 _ g2 ) and the fact that
(b in t1)i implies (b in t)i .
8 The Semantics of State Views
A state view of a model consists of all the statecharts
of the object types in that model. Having demonstrated
how a statechart of an object type can be reduced to
for system specications. In addition, with a suitable
representation of instance diagrams, the semantics can
be used to prove the consistency of instance diagrams
with type and state views, as well as providing a basis
for developing tools for the method. Following Syntropy
we have interpreted preconditions and guards as block-
ing guards. However, if this interpretation is taken then
the transformation proposed by Syntropy as subtyping
does not lead to a valid theory extension. In addition it
is not clear in Syntropy whether a nested state is par-
titioned by its substates, however, we assumed this to
simplify the formalisation. In this case the transforma-
a formal specication, it remains only to describe how tion of adding a substate to a nested state does not lead
these can be combined to form a specication of the to a theory extension.
whole state view of the model. Simply the algebraic The semantics presented here allow other modelling
specication of a state view is a single trait, whose name notations such as UML to be specied.
is STATE-VIEW-M, and which is simply the inclusion
of all statechart traits of object types derived from the Future work will extend the semantics to the specic-
state view. ation and implementation models, and investigate the

25
 formal relationships between the essential, specication [12] Spivey, J. M. The Z Notation: A Reference Manual.
and implementation models in particular the transform- Prentice Hall, 1992.
ation of one model into another.
[13] Rational Software Corpora-
tion The Unied Method, at
Acknowledgement <http://www.rational.com/ot/uml.html>.
[14] Rumbaugh, J., Blaha, M., Premerali, W., Eddy, F.,
The research described in this paper is supported by an and Lorensen, W. Object-Oriented Modelling and
EPSRC-funded project, grant number GR/K67304, UK. Design. Prentice Hall, 1991.
The authors thank the members of the BIRO Research
Group at Brighton University for providing useful and
detailed comments.

References
[1] Bicarregui, J., and Lano, K. Interpreting Syntropy
in the Object Calculus. Personal communications,
1996.
[2] Booch, G. Object-Oriented Analysis and Design
with Applications. Benjamin/Cummings, 2nd edi-
tion, 1994.
[3] Bourdeau, H., and Cheng, B. A Formal Semantics
for Object Model Diagrams. IEEE Transactions on
Software Engineering, 1995.
[4] Coleman, D., Arnold, P., Bodo, S., Dollin, C.,
Gilchrist, H., Hayes, F., and Jeremaes, P. Object-
Oriented Development: The Fusion Method. Object-
Oriented Series, Prentice Hall, 1993.
[5] Fiadeiro, J. and Maibaum, T. Temporal Theories
and Modularisation Units for Concurrent System
Specication in Formal Aspects of Computing, Vol.
4, No. 3, pp. 239-272, 1992. Springer Verlag.
[6] Cook, S., Daniels, J. Designing Object Systems,
Prentice Hall Object-Oriented Series, 1994.
[7] Jones, C. B. Systematic Software Construction using
VDM (2nd edition). Prentice Hall, 1990.
[8] Garland, S. and Guttag, J. \A guide to LP, the
larch prover", Technical Report TR 82, DEC SRC,
December 1991.
[9] Guttag, J. V. and Horning, J. J. Larch: Languages
and Tools for Formal Specications. Springer-Verlag,
1993.
[10] Loeckx, J., Ehrich, H., Wolf, M. : Specication of
Abstract Data Types. Wiley Teubner (1996)
[11] Harel, D., Pneuli, A., Schmidt, J. P., and Sherman,
R. On the Semantics of Statecharts, in Proceedings
of the 2nd IEEE Symposium on Logic in Computer
Science, pp. 54-64, 1987.

26

View publication stats