Connectors for Mobile Programs.
AbstractSoftware Architecture has put forward the concept of connector to express complex relationships between system components, thus facilitating the separation of coordination from computation. This separation is especially important in mobile computing due to the dynamic nature of the interactions among participating processes. In this paper, we present connector patterns, inspired in Mobile UNITY, that describe three basic kinds of transient interactions: action inhibition, action synchronization, and message passing. The connectors are given in COMMUNITY, a UNITY-like program design language which has a semantics in Category Theory. We show how the categorical framework can be used for applying the proposed connectors to specific components and how the resulting architecture can be visualized by a diagram showing the components and the connectors.
Introduction
As the complexity of software systems grows, the role of Software Architecture is increasingly seen as the unifying
infrastructural concept/model on which to analyse and validate the overall system structure in various phases of the
software life cycle. In consequence, the study of Software Architecture has emerged, in recent years, as an autonomous
discipline which requires its own concepts, formalisms, methods, and tools [1], [2]. The concept of connector has been put
forward to express complex relationships between system components, thus facilitating the separation of coordination
from computation. This is especially important in mobile computing due to the transient nature of the interconnections
that may exist between system components. In this paper we propose an architectural approach to mobility that
encapsulates this dynamic nature of interaction in well-defined connectors.
More precisely, we present connector patterns for three fundamental kinds of transient interaction: action inhibition,
action synchronization, and message passing. Each pattern is parameterized by the condition that expresses the transient
nature of the interaction. The overall architecture is then obtained by applying the instantiated connectors to the mobile
system components. To illustrate our proposal, components and connectors will be written in COMMUNITY [3], [4], a
program design language based on UNITY [5] and IP [6].
The nature of the connectors proposed in the paper was motivated and inspired by Mobile UNITY [9], [10], an extension
of UNITY that allows transient interactions among programs. However, our approaches are somewhat different. Mobile
UNITY suggests the use of an interaction section to define coordination within a system of components. We advocate
an approach based on explicitly identified connectors, in order to make the architecture of the system more explicit and
promote interactions to first-class entities (like programs). Moreover, while we base our approach on the modification of
the superposition relation between programs, Mobile UNITY introduces new special programming constructs, leading
to profound changes in UNITY's syntax and computational model. However, we should point out that some of these
syntactic and semantic modifications (like naming of program actions and locality of variables) were already included
in COMMUNITY.
To make it easier for interested readers to compare our approach with Mobile UNITY we use the same example as
in [9]: a luggage distribution system. It consists of carts moving on a closed track transporting bags from loaders to
unloaders that are along the track. Due to space limitations we have omitted many details which, while making the
example more realistic, are not necessary to illustrate the main ideas.
In this paper we follow the approach proposed in [7] and give the semantics of connectors in a categorical framework.
In this approach, programs are objects of a category in which the morphisms show how programs can be superposed.
Because in Category Theory [8] objects are not characterized by their internal structure but by their morphisms (i.e.,
relationships) to other objects, by changing the definition of the morphisms we can obtain different kinds of relationships
between the programs, without having to change the syntax or semantics of the programming language. In fact, the
core of the work to be presented in the remainder of this paper is an illustration of that principle: by changing program
morphisms in a small way such that actions can be "ramified", transient action synchronization becomes possible.
This work was partially supported by JNICT through contract PRAXIS XXI 2/2.1/MAT/46/94 (ESCOLA) and by project ARTS under
contract to EQUITEL SA.
Michel Wermelinger is with the Departamento de Inform'atica, Universidade Nova de Lisboa, 2825 Monte da Caparica, Portugal. E-mail:
mw@di.fct.unl.pt.
Jos'e Luiz Fiadeiro is with the Departamento de Inform'atica, Faculdade de Ci-encias, Universidade de Lisboa, Campo Grande, 1700 Lisboa,
II. Mobile Community
The framework to be used consists of programs and their morphisms. This section introduces just the necessary
definitions. For a more thorough formal treatment, the interested reader should consult [4].
A COMMUNITY program is basically a set of named, guarded actions. Action names act as rendez-vous points for
program synchronization. At each step, one or more actions whose guards are true execute in parallel. Each action
consists of one or more assignments to execute simultaneously. Each attribute used by a program is either external-its
value is provided by the environment and may change at any time-or local-its value is initialized by the program
and modified only by its actions. Attributes are typed by a fixed algebraic data type specification
a set of sort
symbols,\Omega is an S   \Theta S-indexed family of function symbols, and \Phi is a set of first-order axioms defining
the properties of the operations. We do not present the specification of the sorts and predefined functions used in this
paper.
A COMMUNITY program has the following structure
program P is
read R
init I
do []
a := F (g; a)]
where
ffl V is the set of local attributes, i.e., the program "variables";
ffl R is the set of external attributes used by the program, i.e., read-only attributes that are to be instantiated with local
attributes of other components in the environment;
ffl each attribute is typed by a data sort in
ffl I is the initialisation condition, a proposition on the local attributes;
is the set of action names, each one having an associated statement (see below);
ffl for every action g 2 \Gamma, the guard B(g) is a proposition on the attributes stating the necessary conditions to execute
ffl for every action g 2 \Gamma, its domain D(g) is the set of local attributes that g can change;
ffl for every action local attribute a 2 D(g), F (g; a) is a term denoting the value to be assigned to a each time
g is executed.
Formally, the signature of a program defines its vocabulary (i.e., its attributes and action names).
program signature is a tuple hV; R; \Gammai where
is a set of local attributes ;
R s is a set of external attributes ;
is a set of actions.
The sets V s , R s and \Gamma d are finite and mutually disjoint. The domain of an action is the set d ' V such that
Notation. The program attributes are A = S
The sort of attribute a will be denoted
by s a . The domain of action g is denoted by D(g). Inversely, for each a 2 V the set of actions that can change a is
A program's body defines the initial values of its local attributes and also when and how the actions modify them.
For that purpose the body uses propositions and terms built from the program's attributes and the predefined function
symbols.
program is a pair h'; \Deltai where is a program signature and is a program
body where
ffl I is a proposition over
F assigns to every and to every a 2 D(g) a term of sort s a ;
assigns to every proposition over A.
Notation. If D(g) is empty, then F will be denoted by skip. 2
Locations are an important aspect of mobility [11]. We take the same approach as Mobile UNITY and represent
location by a distinguished attribute. However, our framework allows us to handle locations in a more flexible way.
We can distinguish whether the program controls its own motion or if it is moved by the environment by declaring the
location attribute as local or external, respectively.
The formal treatment of locations is the same as for any attribute because they have no special properties at the
abstract level we are working at. However, any implementation of COMMUNITY will have to handle them in a special
way, because a change in the system's location implies a change in the value of the location attribute and vice-versa.
We assume therefore some special syntactic convention for location attributes such that a compiler can distinguish them
from other attributes. Following the notation proposed by Mobile UNITY, in this paper location attributes start with
-.
To give an example of a COMMUNITY program, we present the specification of a cart. Like bags and (un)loaders,
carts have unique identifiers, which are represented by external integer attributes, so that a cart cannot change its own
identity. A cart can transport at most one bag at a time from a source loader to a destination unloader. Initially, the
cart's destination is the loader from which it should fetch its first bag. The unloader at which a bag must be delivered
depends on the bag's identifier. After delivering a bag, or if a loader is empty, the cart proceeds to the next loader.
Absence of a bag will be denoted by the identifier zero.
The track is divided into segments, each further divided into ten units. The location of a cart is therefore given by
an integer. Carts can move at two different speeds: slow (one length unit per time unit) and fast (two length units). A
cart stops when it reaches its destination. The action to be performed at the destination depends on whether the cart
is empty or full.
program Cart is
dest : int;
read id, nbag : int;
do slow: [-6= dest ! -+ 1]
[] fast: [-6= dest ! -+ 2]
[] load: [-= dest nbag k dest := Dest(nbag, dest)]
[] unload: [-= dest - bag dest := Next(dest)]
We now turn to program morphisms, the categorical notion that expresses relationships between (certain) pairs of
programs. In the previous definitions of COMMUNITY [4], [7], a morphism between two programs P and P 0 is just a
mapping from P 's attributes and actions to those of P 0 , stating in which way P is a component of P 0 . It is therefore
called a superposition morphism, since it captures the notion of superposition of [5], P being the underlying program
and P 0 the transformed one.
In this paper we keep the basic intuition but introduce a small although fundamental change. In a mobile setting,
a program may synchronize each of its actions with different actions from different programs at different times. To
allow this, a program morphism may associate an action g of the base program P with a set of actions fg of
the superposed program P 0 . The intuition is that those actions correspond to the behaviour of g when synchronizing
with other actions of other components of P 0 . Each action g i must preserve the basic functionality of g, adding the
functionality of the action that has been synchronized with g. The morphism is quite general: the set fg may
be empty. In that case, action g has been effectively removed from P 0 . Put in other words, it has been permanently
inhibited, as if the guard had been made false. Due to technical reasons the mapping between actions of P and sets of
actions of P 0 is formalised as a partial function from P 0 to P . However, in examples and informal discussions we use
the "set version" of the action mapping.
Morphisms must preserve the types, the locality, and the domain of attributes. Preserving locality means that local
attributes are mapped to local attributes, and preserving domains means that new actions of the system are not allowed
to change local attributes of the components.
Definition 3 Given program signatures consists of
a total function oe ff : A ! A 0 and a partial function oe
Notation. In the following, the indices ff and fl are omitted. We denote the pre-image of oe fl by oe / . Also, if x is a
term (or proposition) of ', then oe(x) is the term (resp. proposition) of ' 0 obtained by replacing each attribute a of x by
Notice that through the choice of an appropriate morphism, it is possible to state whether a given component and a
given system are co-located (i.e., whenever one moves, so does the other) or if the component can move independently
within the system. This can be modeled by a morphism that maps (or not) the location attribute of the component to
the location attribute of the system.
Our first result is that signatures and their morphisms constitute a category. This basically asserts that morphisms
can be composed. In other words, the "component-of" relation is transitive (and reflexive, of course).
Proposition 1 Program signatures and signature morphisms constitute a category SIG.
Superposition of a program P 0 on a base program P is captured by a morphism between their signatures that obeys
the following conditions:
ffl the initialization condition is not weakened;
ffl the assignments are equivalent;
ffl the guards are not weakened.
where means validity in first-order sense.
The category of signatures extends to programs.
Proposition 2 Programs and superposition morphisms constitute a category PROG.
To give an example of a program morphism, consider the need to prevent carts from colliding at intersections. We
achieve that goal in two steps, the second of which to be presented in subsection IV-B. When two carts enter two
segments that intersect, due to the semantics of COMMUNITY allowing only one cart to move at each step, one of the
carts will be further away from the intersection. The first step to avoid collisions is to force that cart to move slowly.
In other words, its fast action is inhibited. Notice that in this case the inhibition depends on the presence of another
cart, and therefore a second (external) location attribute - 2 is needed. The Cart program is thus transformed into an
InhibitedCart as given by the diagram
program Cart is
dest : int;
read id, nbag : int;
do slow: [-6= dest ! -+1]
[] fast: [-6= dest ! -+2]
[] load: [-=dest - bag=0
[] unload: [-=dest - bag 6= 0
program InhibitedCart is
dest : int;
read id, nbag,
do slow: [-6= dest ! -+1]
[] fast: [-6= dest - :I ! -+2]
[] load: [-=dest - bag=0
[-=dest - bag6= 0
where the inhibition condition is I DistanceToCrossing(-). The
morphism is an injection: - 7! -, fast 7! fast, etc. The next section shows how the InhibitedCart program can be
obtained by composition of two components.
III. The Architecture
The configuration of a system is described by a diagram of components and channels. The components are programs,
and the channels are given by signatures that specify how the programs are interconnected. Given programs P and P 0 ,
the signature S is constructed as follows: for each pair of attributes (or actions) a 2 P and a that are to be shared
(resp. synchronized), the signature contains one attribute (resp. action) b; the morphism from S to P maps b to a and
the morphism from S to P 0 maps b to a 0 . We have morphisms only between signatures or only between programs, but
a signature can be seen as a program F(') with an "empty" body [7]. In categorical terms, the operator
F is a functor (i.e., a morphism between objects of different categories).
As a simple example consider the following diagram, which connects (through a channel that represents attribute
sharing) the generic cart program with a program that initializes an integer attribute with the value 2.
program Init 2 is
signature Share is
program Cart is
var .
init .
do .
The program that describes the whole system is given by the colimit of the diagram, which can be obtained by
computing the pushouts of pairs of components with a common channel. The program P resulting from the pushout of
obtained as follows. The initialization condition is the conjunction of the initialization conditions of the
components, and the attributes of P are the union of the attributes of P 1 and P 2 , renaming them such that only those
that are to be shared will have the same name. An attribute of P is local only if it is local in at least one component.
For the above example, the resulting pushout will represent the cart with identifier 2.
program Cart 2 is
var bag, -, dest, id : int
read nbag : int
do .
As for the actions of P , they are basically a subset of all pairs of actions Only
those pairs such that g 1 and g 2 are mapped to the same action of the channel may appear in P . If an action of P 1 (or
not mapped to any action of the channel-i.e., it is not synchronized with any action of P 2 (resp. P 1 )-then it
appears "unpaired" in P . Synchronizing two actions g 1 and g 2 (i.e., joining them into a single one g 1 taking
the union of their domains, the conjunction of their guards, and the parallel composition of their assignments. If the
actions have a common attribute a then the resulting assignment is a := F (g 1 ; a) and the guard is strengthened by
a). If the actions are "incompatible" (i.e., the terms denote different values for a) then the equality is
false and therefore the synchronized action will never execute, as expected.
As an illustration, the pushout of the diagram
program Cart is
var bag, -, dest : int
read id, nbag : int
do slow: [-6= dest ! -+1]
[] fast: [-6= dest ! -+2]
[] load: [-=dest - bag=0
[] unload: [-=dest - bag 6= 0
signature S is
do i
i7!fast
program Inhibitor is
read -: int
do i: [:I ! skip]
is program InhibitedCart shown in the previous section: actions fast and i were paired together, joining their guards
and assignments. Notice that attribute - of the Inhibitor program has been renamed to - 0 because names are local.
The next result states that every finite diagram has a colimit.
Proposition 3 Category PROG is finitely cocomplete.
Channels (i.e., signatures) only allow us to express simple static connections between programs. To express more
complex or transient interactions, we use connectors, a basic concept of Software Architecture [2]. A connector consists
of a glue linked to one or more roles through channels. The roles constrain what objects the connector can be applied to.
In a categorical framework, the connectors (and therefore the architectures) that can be built depend on the categories
used to represent glues, roles, and channels, and on the relationships between those categories. It is possible to use three
different categories for the three parts of a connector (e.g., [7] proposes roles to be specifications written in temporal
logic) but for simplicity we assume that roles and glues are members of the same category. We therefore adopt only the
basic definitions of [7].
connection is a tuple hC; G; R; fl; aei where
is the channel ;
is the glue;
is the role;
are morphisms in PROG.
A connector is a finite set of connections with the same glue.
The semantics of a connector is given by the colimit of the connections diagram. By definition, there are superposition
morphisms from each object in the diagram to the colimit. Therefore superposition becomes in a sense "symmetric", a
necessary property to capture interaction [10].
A connector can be applied only to programs which are instantiations of the roles. In categorical terms, there must
exist morphisms from the roles to the programs.
Definition 6 A correct instantiation of a connector fhC i ; G; R is a set of morphisms
PROG. The resulting system is the colimit of the diagram formed by morphisms
As an illustration, an instantiated connector with two roles has the diagram
IV. Interactions
An interaction between two programs involves conditions and computations. Therefore it cannot be specified just by
a signature; we must use a connector, where the programs are instances of the roles, the interaction is the glue, and
each channel states exactly what is the part of each program in the interaction.
A distributed system may consist of many components, but usually it can be classified into a relatively small set of
different types. Since interaction patterns normally do not depend on the individual components but on their types, it is
only necessary to define connectors for the existing component types. To obtain the resulting system, the connectors will
be instantiated with the actual components. Therefore, in the following we only consider the programs that correspond
to component types. In the luggage distribution example there are only three different program types: carts, loaders,
and unloaders. The programs for the individual components only differ in the initialization condition for the identifier
attribute.
In a mobile setting one of the important aspects of interactions is their temporary nature. This is represented by
conditions: an interaction takes place only while some proposition is true. Usually that proposition is based on the
location of the interacting parties. We consider three kinds of interactions:
inhibition An action may not execute. 1
synchronization Two actions are executed simultaneously.
communication The values of some local attributes of one program are passed to corresponding external attributes of
the other program.
For each kind of interaction we develop a connector template which is parameterized by the interaction conditions.
This means that, given the interacting programs (i.e., the roles) and the conditions under which they interact, the
appropriate connector can be instantiated.
Given the set of components that will form the overall system, the possible interactions are specified as follows:
ffl An inhibition interaction states that an action g of some program P will not be executed whenever the interaction
condition I is true.
ffl A synchronization interaction states that action g of program P will execute simultaneously with action g 0 of program
I is true.
ffl A communication interaction states that the value of the local attributes M (the "message") of program P can be
written into the external attributes M 0 of program P 0 if I is true. The sets M and M 0 must be compatible. Moreover,
each program must indicate which action is immediately executed after sending (resp. receiving) the message.
Definition 7 Given a set P of programs, a transient interaction is either one of the following:
ffl a transient inhibition hg;
ffl a transient synchronization hg;
ffl a transient communication hg; M;P;
where
there is a bijection
ffl I is a proposition over attributes of P .
The following subsections present the connector patterns corresponding to the above interactions. The glue of a
connector only needs to include the attributes that occur in the interaction condition. However, to make the formal
definitions easier, the glue patterns will include all the attributes of all the roles. Due to the locality of names, attributes
from different roles must be put together with the disjoint union operator (written ]) to avoid name clashes.
For further simplication, we assume that the interaction condition only uses attributes from the interacting programs
thus only those roles are presented in the patterns. If this is not the case, the instantiated connector
must have further roles that provide the remaining attributes. The next subsection provides an example.
A. Inhibition
Inhibition is easy and elegant to express: if an action is not to be executed while I is true, then it can be executed
only while :I is true.
Definition 8 The inhibition connector pattern corresponding to inhibition interaction hg;
1 In this case the interaction is between the program and its environment.
program P is
read R
init .
do g: [B(g) ! . ]
[] .
signature Target is
do g
program Inhibitor is
init true
do g: [:I ! skip]
For illustration, the action inhibition example of Sections II and III can be achieved through the following connector.
signature Context is
read -: int
program InhibitCrossing is
read
init true
do fast: [:I ! skip]
signature Target is
read -: int
do fast
fast7!fast
program Cart is. program Cart is.
Again, the inhibition condition is I
Notice that the connector has two roles, one for the cart whose action is to be temporarily inhibited, the other for the
cart that provides the context for the inhibition to occur.
An application of this connector and the resulting colimit will be presented in the next subsection.
B. Synchronization
Synchronizing two actions g and g 0 of two different components can be seen as merging them into a single action gg 0 of
the system, the only difference between the static and the mobile case being that in the latter the merging is only done
while some condition is true. When gg 0 executes, it corresponds to the simultaneous execution of g and g 0 . Therefore,
if g would be executed by a component, the system will in fact execute gg 0 which means that it is also executing g 0 , and
vice-versa. To sum it up, when two actions synchronize either both execute simultaneously or none is executed.
This contrasts with the approach taken by Mobile UNITY which allows two kinds of synchronization: coexecution
and coselection [10]. The former corresponds to the notion exposed above, while the latter forces the two actions to be
selected simultaneously but if one of them is inhibited or its guard is false then only the other action executes. This
extends the basic semantics of UNITY where only one action can be selected at a time. Since COMMUNITY already
allows (but does not impose) simultaneous selection of multiple actions, and because we believe that the intuitive notion
of synchronization corresponds to coexecution, we will not handle coselection.
The key to represent synchronization of two actions subject to condition I is to ramify each action in two, one
corresponding to its execution when I is false and the other one when I is true. Put in other words, each action has two
"sub-actions", one for the normal execution and the other for synchronized execution. As the normal sub-action can only
execute when the condition is false, it is inhibited when I is true, and the opposite happens with the synchronization
sub-action. Therefore we can use the same technique as for inhibition. Since there are two actions to be synchronized,
and the synchronization sub-action must be shared by both, there will we three (instead of four) sub-actions. To facilitate
understanding, the name of a sub-action will be the set of the names of the actions it is part of.
Definition 9 The synchronization connector pattern corresponding to synchronization interaction hg;
signature C is
do g
program Synchroniser is
read
init true
do g: [:I ! skip]
signature C 0 is
read
do
program P is
read R
init .
do g: [B(g) ! . ]
[] .
program P 0 is
read R 0
init .
do
[] .
In the colimit, the action gg 0 will have the guards and the assignments of g and g 0 . Therefore, if either B(g) or B(g 0 )
is false, or if the assignments are incompatible, then gg 0 will not get executed.
This connector describes what is called "non-exclusive coexecution" in [10]: outside the interaction period the actions
execute as normal. It is also possible to simulate exclusive coexecution which means that the actions are only executed
(synchronously) when the interaction condition is true. To that end, simply eliminate actions g and g 0 from the inhibition
connector shown above, just keeping the synchronized action gg 0 .
Continuing with the example, the second step to avoid collisions at crossings is to force the nearest cart to move fast
whenever the most distant one moves. Since the latter can only move slowly, the nearest cart is guaranteed to pass the
crossing first. Using the same interaction condition as in the previous section one gets the diagram
signature C 1 is
read -: int
do fast
program SynchCrossing is
read
init true
do fast: [:I ! skip]
signature C 2 is
read -: int
do slow
slow7!fslow;fastslowg
program Cart is. program Cart is.
To prevent collisions between Cart 1 and Cart 2 (obtained as shown in Section III) one must consider two symmetrical
cases, depending on which cart is nearer to the intersection. Let us assume that Cart 1 is nearer. Thus we must block
the fast action of Cart 2 with the inhibitor shown in the previous section and synchronize its slow action with the fast
action of Cart 1 using the connector above. The diagram is
Cart
Context
InhibitCrossing Target
// Cart
Cart
OO
SynchCrossing C 2
// Cart
with the following colimit (where i ranges over 1 and 2 to abbreviate code duplication)
program System is
read nbag
dest
do slow dest
dest
dest
fast 1 slow dest dest
dest
dest dest i := Dest(nbag i , dest i )]
dest dest i := Next(dest i )]
To see that synchronization is transitive, consider the following example where action g 0 is synchronized with two
other actions g and g 00 whenever I 1 and I 2 are true, respectively. The resulting system must provide actions for all four
combinations of the truth values of the interaction conditions. For example, if I 1 - I 2 is true then all actions must occur
simultaneously, but if I 1 -I 2 is false, then any subset of the actions can occur. This happens indeed because the pushout
of two morphisms
m g is basically given by the pairs fg 1 g 0
with morphism oe(g i
g. Putting into words: if an action g "ramifies" into
actions g, it means that whenever g would be executed, any subset of oe(g) executes in the superposed
program, and vice-versa, the execution of any g i implies that g is executed in the base program. Therefore, if g can be
ramified in two distinct ways, in the pushout any combination of the sub-actions can occur whenever g executes. The
pushout morphisms just state to which combinations each sub-action belongs.
do
do
ssh
do
do
do
ssg
gggggggggggggggggggg
do
As one can see, for all combinations of I 1 and I 2 the correct actions are executed. The colimit includes the combination
of all actions that share the name actions g 0 and gg 0 of the left middle pushout are synchronized with g 0 and g 0 g 00 on
the right in the four possible ways.
C. Communication
In Mobile UNITY communication is achieved through variable sharing. The interaction x - y when C engage I
disengage F x k F y states the sharing condition C, the (shared) initial value I of both variables, and the final value F x
and F y of each variable. The operational semantics states that whenever a program changes x, y gets the same value,
and vice-versa. This approach violates the locality principle. Furthermore, as pointed out in [10], several restrictions
have to be imposed in order to avoid problems like, e.g., simultaneous assignments of different values to shared variables.
We also feel that communication is a more appropriate concept than sharing for the setting we are considering, namely
mobile agents that engage into transient interactions over some kind of network. In the framework of COMMUNITY
programs, communication can be seen as some kind of sharing of local and external attributes, which keeps the locality
principle. We say "some kind" because we cannot use the same mechanism as in the static case, in which sharing meant
to map two different attributes of the components into a single one of the system obtained by the colimit. In the mobile
case the same local attribute may be shared with different external attributes at different times, and vice-versa. If we
were to apply the usual construction, all those attributes would become a single one in the resulting system, which is
clearly unintended.
We therefore will obtain the same effect as transient sharing using a communication perspective. To be more precise,
we assume program P wants to send a message M , which is a set of local attributes. If P 0 wants to receive the message,
it must provide external attributes M 0 which correspond in number and type to those of M . Program P produces the
values, stores them in M , and waits for the message to be read by P 0 . Since COMMUNITY programs are not sequential,
"waiting" has to be understood in a restricted sense. We only assume that P will not produce another message before
the previous one has been read (i.e., messages are not lost); it may however be executing other unrelated actions. To
put it in another way, after producing M , program P is expecting an acknowledge to produce the new values for the
attributes in M . For that purpose, we assume P has an action g which must be executed before the new message is
produced. Similarly, program P 0 must be informed when a new message has arrived, so that it may start processing it.
For that purpose we assume that P 0 has a single action g 0 which is the first action to be executed upon the receipt of a
new message 2 . That action may simply start using M 0 directly or it may copy it to local attributes of P 0 .
To sum up, communication is established via one single action for each program 3 : the action g of P is waiting for M
to be read, the action g 0 of P 0 reads M (i.e., starts using the values in M 0 ). As expected, it is up for the glue of the
interaction connector to transfer the values from M to M 0 and to notify the programs.
The solution is to explicitly model the message transmission as the parallel assignment of the message attributes,
which we abbreviate as M 0 := M . For this to be possible, the local attributes M of P must be external attributes of the
glue, and the external attributes M 0 of P 0 must be local attributes of the glue. The assignment can be done in parallel
with the notification of P . Moreover, the programs may only communicate when proposition I is true. Therefore the
glue contains an action wait : [I !M 0 := M ] to be synchronized with the "waiting" action g of P . The "reading" action
g 0 of P 0 can only be executed after the message has been transmitted. The solution is to have another action read in
the glue that is synchronized with g 0 . To make sure that read is executed after wait we use a boolean attribute. Thus
0 is inhibited while no new values have been transferred to M 0 . Again, this is like a blocking read primitive, except
2 It is always possible to write P 0 in such a way.
3 This is similar to pointed processes in the -calculus, or to ports in distributed systems.
that P 0 may execute actions unrelated to M 0 .
Since a receiver may get messages from different senders different times or not), there will be several
possible assignments M 0 := M i . Due to the locality principle, all assignments to an attribute must be in a single
program. Therefore for each message type a receiver might get, there will be a single glue connecting it to all possible
senders. On the other hand, a message might be sent to different receivers m. Therefore there will be several
possible assignments M 0
associated with the same wait action of the sender of message M . So there must be a
single glue to connect a sender with all its possible recipients. To sum up, for each message type there will be a single
glue acting like a "demultiplexer": it synchronizes sender i with receiver j when interaction condition I ij is true. This
assumes that the possible communication patterns are known in advance.
The communication connector pattern corresponding to communication interactions
m) is
signature Sender i is
read
do wait i
program Communicator is
read
init :new j
do
signature Receiver j is
read M 0
do read j
program P i is
read R i
init .
do
[] .
program
j is
read M 0
init .
do read
[] .
Notice that several actions wait ij may occur simultaneously, in particular for the same receiver j if the messages sent
have the same value. To distinguish messages sent by different senders, even if their content is the same, one can add
a local integer attribute s to the glue and add the assignment s := i to each action wait ij . This prevents two different
senders from sending their messages simultaneously.
In the luggage delivery example, communication takes place when a cart arrives at a station (i.e., a loader or an
unloader), the bag being the exchanged message. Loaders are senders, unloaders are receivers, and carts have both
roles. The bags held by a station will be stored in an attribute of type queue of integers. Although the locations
of stations are fixed they must be represented explicitly in order to represent the communication condition, namely
that cart and station are co-located. Since it is up for the connector to describe the interaction, the programs for
the stations just describe the basic computations: loaders remove bags from their queues, unloaders put bags on their
queues. The loader program must have separate actions to produce the message (i.e., the computation of the value of
the bag attribute) and to send the message (i.e., the bag has been loaded onto the cart).
The c carts are connected to the l loaders through a connector with c identical roles (each one being the Cart program
of Section I) and l identical roles, each being the Loader program. We only show the roles and respective morphisms
for the i-the loader (sender) and the j-th cart (receiver).
signature Sender is
read
do load
load7!fwait i1 ;:::;wait ic g
program Load is
init :new j
do
nbag
new j :=true]
new j :=false]
signature Receiver is
read -, nbag : int
do load
load7!read j
program Loader is
loaded
init loaded -= InitLoc(id)
do newbag: [q loaded
loaded:=false]
loaded
[] load: [:loaded
loaded:=true]
program Cart is
var -, dest, bag : int
read id, nbag : int
-=InitLoc(id)
do slow: [-6= dest ! -+1]
[] fast: [-6= dest ! -+2]
[] load: [-=dest - bag=0
bag:=nbag
[-=dest - bag6=0
Similarly, there is a connector with u roles for the unloaders and c roles for the carts. The i-the cart (sender) is
connected to the j-th unloader (receiver) as follows.
signature Sender is
read
do load
load7!fwait i1 ;:::;wait iu g
program Unload is
read
init :new j
do
signature Receiver j is
read
do unload
program Cart is
var -, dest, bag : int
read id, nbag : int
-=InitLoc(id)
do slow: [-6= dest ! -+1]
[] fast: [-6= dest ! -+2]
[] load: [-=dest - bag=0
bag:=nbag
[-=dest - bag6=0
program Unloader is
read
do unload: [true
be the program obtained by the pushout of programs Init i (of Section III) and X . Then the program
corresponding to a system consisting of two carts, one loader, and one unloader is obtained by computing the colimit of
the following diagram, which only shows the role instantiation morphisms between the connectors (which have the same
name as their glues) and the components.
SynchCrossing slow
fast
InhibitCrossing
fast
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Loader 3 Load
O
O
O
O
O
O
O
O
O
O
O
O Unload
ggO O O O O O O O O O O O
Unloader 4
SynchCrossing
fast
slow
InhibitCrossing
fast
__ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
Notice that the binary connectors dealing with crossings are not symmetric; they distinguish which cart is supposed
to be nearer to the crossing. Therefore one must apply those connectors twice to each pair of carts.
V. Concluding Remarks
We have shown how some fundamental kinds of transient interactions, inspired by Mobile UNITY [9], [10], can be
represented using architectural connectors. The semantics has been given within a categorical framework, and the
approach has been illustrated with a UNITY-like program design language [3], [4].
As argued in [3], [12], the general benefits of working within a categorical framework are:
ffl mechanisms for interconnecting components into complex systems can be formalized through universal constructs
(e.g., colimits);
ffl extra-logical design principles are internalized through properties of universal constructs (e.g., the locality of names);
ffl different levels of design (e.g., signatures and programs) can be related through functors.
For this work in particular, the synergy between Software Architecture and Category Theory resulted in several conceptual
and practical advantages.
First, systems are constructed in a principled way: for each interaction kind there is a connector template to be
instantiated with the actual interaction conditions; the instantiated connectors are applied to the interacting programs
thus forming the system architecture, which can be visualized by a diagram; the program corresponding to the overall
system is obtained by "compiling" (i.e., computing the colimit of) the diagram.
Second, separation between computation and coordination, which is already supported by Software Architecture, has
been reinforced by two facts. On the one hand, the glue of a connector uses only the signatures of the interacting
programs, not their bodies. On the other hand, the superposition morphisms impose the locality principle.
Third, to capture transient interactions, only the morphism between program actions had to be changed; the syntax
and semantics of the language remained the same.
There are two ways of dealing with architectures of mobile components. In a system with limited mobility or with
a limited number of different component types, all possible interaction patterns can be foreseen, and thus a static
architecture with all possible interconnections can represent such a system. To cope with systems having a greater
degree of mobility, one must have evolving architectures, where components and connectors can be added and removed
unpredictably. This paper, being inspired by Mobile UNITY, follows the first approach. Our future work will address
the second approach.
One of the ideas we wish to explore is to remove the interaction condition from the glue's actions and instead associate
it to the application of the whole connector. The diagram of the system architecture thus becomes dynamic, at each
moment including only the connectors whose conditions are true. Another possibility is to apply graph rewriting
techniques to the system diagrams. A third venue is to change (again) the definition of morphism to represent the
notion of "changes-to" instead of "component-of". In other words, a morphism form P to P 0 indicates that P may
become . For the moment, these are just some of our ideas to capture software architecture evolution in a categorical
setting. Their suitability and validity must be investigated.

Acknowledgements

We would like to thank Ant'onia Lopes for many fruitful discussions and the anonymous referees for suggestions on
how to improve the presentation.



--R

"Special issue on software architecture,"
Perspectives on an Emerging Discipline


Parallel Program Design-A Foundation

"Semantics of architectural connectors,"
Basic Category Theory for Computer Scientists
"Mobile UNITY: Reasoning and specification in mobile computing,"
"Mobile UNITY: A language and logic for concurrent mobile systems,"
"Towards a general location service for mobile environments,"

--TR

--CTR
Michel Wermelinger , Cristvo Oliveira, The community workbench, Proceedings of the 24th International Conference on Software Engineering, May 19-25, 2002, Orlando, Florida
Performance evaluation of mobility-based software architectures, Proceedings of the 2nd international workshop on Software and performance, p.44-46, September 2000, Ottawa, Ontario, Canada
Michel Wermelinger , Antnia Lopes , Jos Luiz Fiadeiro, Superposing Connectors, Proceedings of the 10th International Workshop on Software Specification and Design, p.87, November 05-07, 2000
Antonio Brogi , Carlos Canal , Ernesto Pimentel, On the semantics of software adaptation, Science of Computer Programming, v.61 n.2, p.136-151, July 2006
Antnia Lopes , Jos Luiz Fiadeiro , Michel Wermelinger, Architectural primitives for distribution and mobility, Proceedings of the 10th ACM SIGSOFT symposium on Foundations of software engineering, November 18-22, 2002, Charleston, South Carolina, USA
Antnia Lopes , Jos Luiz Fiadeiro , Michel Wermelinger, Architectural primitives for distribution and mobility, ACM SIGSOFT Software Engineering Notes, v.27 n.6, November 2002
Andrea Bracciali , Antonio Brogi , Carlos Canal, A formal approach to component adaptation, Journal of Systems and Software, v.74 n.1, p.45-54, January 2005
Lus Filipe Andrade , Jos Luiz Fiadeiro, Agility through coordination, Information Systems, v.27 n.6, p.411-424, September 2002
Marco Antonio Barbosa , Lus Soares Barbosa, An Orchestrator for Dynamic Interconnection of Software Components, Electronic Notes in Theoretical Computer Science (ENTCS), 181, p.49-61, June, 2007
Michel Wermelinger , Jos Luiz Fiadeiro, A graph transformation approach to software architecture reconfiguration, Science of Computer Programming, v.44 n.2, p.133-155, August 2002
Michel Wermelinger , Jos Luiz Fiadeiro, Algebraic software architecture reconfiguration, ACM SIGSOFT Software Engineering Notes, v.24 n.6, p.393-409, Nov. 1999
Antnia Lopes , Jos Luiz Fiadeiro, Adding mobility to software architectures, Science of Computer Programming, v.61 n.2, p.114-135, July 2006
Dianxiang Xu , Jianwen Yin , Yi Deng , Junhua Ding, A Formal Architectural Model for Logical Agent Mobility, IEEE Transactions on Software Engineering, v.29 n.1, p.31-45, January
transient interactions;connectors;UNITY;software architecture