ion from the physical distribution of the different system functions, into a system design that identifies a certain number of distributed components. The temporal constraints of the global requirements on the execution of the different activities imply certain coordination messages between the different system components. The paper presents a transformation algorithm that derives, from a given global behavior, the local behaviors for each of the system components including the exchange of coordination messages for the global synchronization of the activities. In contrast to earlier work, strong and weak sequencing is distinguished and the primitive sub-activities included in the global behavior descriptions may be collaborations involving several components.
Various kinds of system models can be used during the system development process. In this paper, we are concerned with the transformation from a global requirements model, which describes the functional behavior of a distributed system in an abstract manner, to a distributed system design where the different system components are identified and their behavior must be determined such that their interactions give rise to a behavior satisfying the global requirements model. At the design level, the behavior of the different system components are often modeled using communicating state machines or modeling languages such as SDL or UML State Diagrams. The translation from these models into implementation code can be largely automated.
We consider in this paper distributed applications, for instance systems providing communication services, workflow management systems, e-commerce applications, etc. Various notations have been proposed for defining the global requirement models for such system. We mention in particular UML Activity Diagrams, Use Case Maps (UCM), the Process Definition Language (XPDL) of the Workflow Management Coalition, the Business Process Execution Language (BPEL), and the Web Services Choreography Description Language (WS-CDL) developed by W3C. These different notations contain many common concepts, but also show important differences. They all have in common that the overall workflow behavior can be decomposed into several sub-activities, and further into sub-sub-activities. Most of these notations assume that the basic (primitive) activities in this behavior decomposition are activities that are allocated to a single system component within the architectural design of the system. However, for many of these applications, the basic building blocks of the behavior are activities that are actually collaborations between several system components, for instance a service operation between a client and a server. Therefore we have proposed to use the UML Collaborations as the basic building blocks for constructing global requirement models [1]. Our approach was to use the sequencing operations of UML Activity Diagrams and use Collaborations as the basic activities; the temporal order among these collaborations is then defined by the flow relations of the Activity Diagrams (an example is discussed in Section 2).
Before the transformation into a design model, it is important to define the architectural design and to identify the different system components that are involved in providing the different functions of the system. For each of the primitive collaboration activities identified in the global requirements model, one has to determine which system component will implement each of the collaboration roles involved. This goes hand in hand with the allocation of system resources and is very important for obtaining the desired system performance characteristics. This question of what is the best architectural design, resource allocation and allocation of collaboration roles to different system components is not further developed in this paper. Instead, we concentrate here on the subsequent question: What should be the dynamic behavior of each of the system components in order to coordinate the activities in such a manner that the sequencing rules of the global requirements model will be satisfied.
We note that the same kind of question has been addressed by many papers during
the last 10 years in a context where the global requirements are defined in terms of
Message Sequence Charts (MSCs) or UML Sequence Diagrams. In this context, one
usually wants to describe the behavior of each system component in the form of a
state machine. This approach encountered many difficulties; a review of these issues
is included in [1]. In many cases, a given MSC execution scenario may only be
realizable by the given set of components if at the same time other so-called implied
scenarios would also be realized [
These difficulties are increased by the use of weak sequencing operators in the description of the global system behavior. We note that strong sequencing between two activities A1 and A2 means that all sub-activities of A1 must be completed before any sub-activity of A2 may start. In contrast, weak sequencing between A1 and A2 means that each system component locally applies sequencing to the local subactivities of A1 and A2, that is, a component may start with sub-activities that belong to A2 as soon as it has completed all its local sub-activities that are part of A1. Strong sequencing implies weak sequencing, but not inversely. We note that weak sequencing was introduced in High-Level MSCs (HMSCs) as the normal sequencing operator between different sequence charts. It is also supported in UML Sequence and Interaction Overview diagrams.
We think that weak sequencing is an important concept for modeling abstract requirements of distributed systems, because it requires less synchronization messages than strong sequencing. Therefore we consider in this paper weak and strong sequencing. We use a number of temporal ordering operators, similar to those found in Activity Diagrams, XPDL and BPEL, to build the global requirements model for a system. In this paper, we show how such an abstract model, together with the allocation of collaboration roles to the system components identified by the architectural design, can be automatically transformed into a set of component behavior models. These component models are correct by construction, that is, they will give rise to a global system behavior that satisfies the global requirements model.
The transformation algorithm presented in this paper is inspired by some of our
early work under the title “Deriving protocol specifications from service
specifications” in the 1980ies [
The paper is structured as follows. In Section 2, we consider the temporal ordering of activities in a global requirements model, present the ordering operators that we assume in this paper and introduce a simple example. The main body of the paper is Section 3. After a review of past work on the transformation from global requirements to component behaviors, we describe in Section 3.1 the principles of our automatic transformation approach. One important question, not addressed by the earlier work mentioned above, is the following: In the case of choices, it is not evident how a component involved in some specific sub-activity may determine when this subactivity is completed and the next sub-activity (in weak sequence) may be started ? – This problem is solved by the so-called choice indication messages. Then in Section 3.2, we present an algorithm that does this transformation automatically. The application of this algorithm to the example of Section 2 is discussed in Section 4. Finally, Section 5 provides our conclusions.
As mentioned above, various notations have been proposed for describing global requirements for distributed applications, workflows, or communication services. We consider here in particular UML Activity Diagrams (AD). They include the following concepts for defining the order of execution of activities: sequential execution, alternative choice, concurrency, as well as loops and partial-order dependencies. In addition, they support interruptible regions of activities which are useful for modeling exception handling and external priority interrupts. ADs also support the explicit modeling of dataflow relationships between different activities and the specification of the type of data exchanged (using UML Class Diagrams). XPDL and BPEL have similar constructs for describing the control flow of applications. All these notations support hierarchical decomposition where an activity shown at one level of abstraction as a basic, non-divisible activity can be described at a more detailed level to be composed out of a number of smaller units with a specific control structure defining the order of execution of these more basic activities. It is our intention to support these same concepts for describing the control structure using the notation introduced below.
We note that most of these notations assume that the basic (primitive) activities in this behavior decomposition are activities that are allocated to a single system component within the architectural design of the system. This is also the case for Message Sequence Charts (MSCs) or UML Sequence Diagrams, where the primitive actions are the sending or reception of messages by specific system components. In contrast, as mentioned in the Introduction, we assume that the basic activities in the description of the overall behavior may be collaborations involving several components.
One may ask the question whether different notations are required for describing the dynamic behavior of the global requirements model, on the one hand, and the behavior of the different system components, on the other hand. In this paper, we use essentially the same behavior expressions to describe both of these behaviors. However, the distinction between weak and strong sequencing disappears when one deals with the behavior of a single component. The operators used for describing the temporal properties of these behavioral models are listed in Table 1. They are closely related to the sequencing operators of UML Activity Diagrams and High-Level MSCs. We distinguish between strong and weak sequence. Following the spirit of “Structured Programming”, we restrict ourselves to flow control constructs that have a single entry point and a single exit point.
We write “<name>(R) = C” to indicate that the behavior of a collaboration, called <name>, which involves the set of roles R, is given by the expression C. The expression is composed out of primitive actions, the invocation of collaborations and certain sequencing operators as shown in Table 1. We refer to the sub-expressions C1, C2, and C3 in the table as sub-collaborations of the collaboration C. We note that our notation does not include the equivalent of the Join and Merge operators used in Activity Diagrams. However, the presence of a Merge node is implied at the end of a choice expression, and a Join node is implied at the end of the concurrency construct.
It is possible to invoke a collaboration that has no explicitly defined behavior; in this case, its behavior may be defined by some other formalism, such as a sequence diagram or an implementation in some programming language.
As an example we consider the telemedicine consultation service described in [1]. A patient is being treated over an extended period of time for an illness that requires frequent tests and consultations with a doctor at the hospital to set the right doses of medicine. Since the patient may stay at home and the hospital is a considerable distance away from the patient’s home, the patient has been equipped with the necessary testing equipment at home. The patient will call the hospital on a regular basis to have remote tests done and consult with a doctor. A consultation may proceed as follows: The patient calls the telemedicine reception desk to ask for a consultation session with one of the doctors. The receptionist will register the information needed, and then see if the doctor is available (collaboration <registr> below). If the doctor is available, the patient will be assigned to the doctor and the consultation can start. Otherwise, the patient is put on hold, possibly listening to music, until a doctor is available (collaboration <w> below). If the patient does not want to wait any longer, he/she may hang up (action <h-up> below) and call back later.
Table 1: Operators used in behavior expressions
Construct Notation Explanation of the semantics
primitive <action>(r) Execution of a local action with name <action>
activity performed by role r
invocation <subcol>(R) Execution of a collaboration with name <subcol>
of sub-col. involving the set R of participating roles
strong C1 ;s C2 C2 is executed after C1 in strong sequence, that is, all
sequence actions of C1 are completed before C2 can start
weak C1 ;w C2 C2 is executed after C1 in weak sequence, that is, only
sequence local order is enforced by each participating role
choice C1 [] C2 Either C1 or C2 is executed; this may be a local choice
(that is, the choice is performed by a single role /
component) or competing initiatives from several roles;
for a more detailed discussion, see [
This behavior can be described using the operators defined in Table 1 as follows: <telemed> = <registr>{P, R} ;w ( <w>{P, R} |> <h-up>{P} else <act>{P, R, D} ) where <w>{P, R} = <wait>{P, R} *w İ and
<act>{P, R, D} = <assign>{R, D} ;w <consult>{P, D}
The roles involved in each activity are indicated by the upper indices (P stands for
patient, R for receptionist, and D for doctor). This definition of the <telemed>
workflow indicates that the registration of the patient is followed by a waiting period
<w> that may be empty (İ ); this waiting period may be interrupted when the patient
hangs up the telephone. The waiting period, if not interrupted, is followed by the
<act> sub-collaboration which consists of the weak sequential execution of the
assignment of the patient to the doctor followed by the consultation. We note that the
detailed interactions involved in each of these activities (or collaborations) are not
specified, and we do not need to know them for what we discuss in this paper. The
behavior can also be represented by the UML Activity Diagrams shown in Figure 1.
Our early work in this area [
In the above references, it was assumed that a choice between different branches of
execution is always made by a single component. This is called a "local choice". In
the case of a "non-local choice" where several components are involved [
During the last 10 years, much research was concerned with weak sequencing and
related race conditions. Most of this work was in the context were the system
behavior is defined in terms of MSCs or Sequence Diagrams; and it was pointed out
that one sequence diagram, when implemented by a set of components, may
necessarily give rise to other so-called “implied sequences” [
In the area of Web Services and workflow management, several approaches have
been described for deriving distributed execution environments for
services/workflows that are specified in a global (centralized) view. For instance, the
decentralized execution of composite Web Services specified in BPEL has been
proposed in [
The derivation method described here uses the following ideas described previously:
(a) coordination messages for strong sequencing [
The main ideas underlying the proposed derivation method, specifically for dealing with weak sequencing, can be summarized as follows: 1. Each role knows which sub-collaborations are currently active. Message reordering at reception is used to accept only those messages that relate to active collaborations. 2. It is assumed that sub-collaborations that may be concurrently active have disjoint sets of messages that can be received by a given role; or simply, that their message sets are disjoint. 3. At a given role, each sub-collaboration is in one of the following phases: (1) inactive (messages for this sub-activity are not accepted), (2) enabled (the role is not a starting role, the messages of this sub-activity are accepted), (3) active (local activities for this sub-activity have started, messages are accepted). We say that a sub-collaboration ends when the role knows that no further actions pertaining to this sub-collaboration are required. When a subcollaboration ends, it goes back into the inactive phase. 4. The transition from inactive to enabled occurs when the "previous" subcollaboration ends. If the role is a starting role, it may immediately go into the active state. A non-starting role enters the active state when it receives (and accepts) the first message pertaining to this sub-collaboration. When the sub-collaboration ends, the "following" sub-activity goes into the enabled or active state. 5. It is therefore important that each role knows when an active collaboration ends. This happens when the final action (for this role) is performed. If the role is participating, it should know when all actions pertaining to this subcollaboration have been performed (termination decision). If it is not participating, there is no point in doing anything. 6. If the sub-collaboration contains no choice, then each role knows what actions must be locally performed. The termination decision is easy: the subcollaboration ends when all these actions have been performed. If the subcollaboration consists of a choice C1 [] C2, there are the following cases: o The role participates in both alternatives: choice propagation is assured by the disjointness of the message sets of the two alternatives. The participating role will know which alternative is performed and will therefore know which actions must be performed. o The role does not participate in any alternative: there is no participation at all. o The role participates in C1 but not in C2 (or inversely): If C1 is chosen, there is no problem. If C2 is chosen, we have to introduce a special kind of coordination message sent to this role by a role participating in C2 which indicates that C2 was chosen. We call this message a choice indication message. On the reception of this message, the given role can consider that the choice has ended.
The above discussion indicates that we have to identify for each collaboration or sub-collaboration the following items which are defined based on the partial order between the actions that compose the collaboration: • Special kinds of actions of a collaboration o Initial action(s): An action of a collaboration is initial if there is no other action in that collaboration that precedes it. o Final action(s): An action of a collaboration is final if there is no other action in that collaboration that succeeds it. o Last action(s) of a given role: During the execution of a collaboration, an action is a last action for a given role if the action is performed by that role and there is no other action in that collaboration that must be performed by that role after the given action. • Different roles involved in a collaboration o Starting role: this is a role that performs an initial action of the collaboration or an initial action of an initial sub-collaboration. o Terminating role: this is a role that performs a final action of the collaboration or a final action of a final sub-collaboration. C1 || C2 PR(C1) U PR(C2) C1 |> PR(C1) U PR(C2) U else C3 PR(C3)
Before we can derive the behavior of the distributed system components that should implement the actions defined by the collaboration behavior, we have to determine how the different roles defined in the behavior of the collaboration are allocated to the different system components. In general, each system component should have some role to play, but several behavior roles may be allocated to the same system component. We assume in the following that a function Alloc() defines for each role the system component to which it is allocated.
After having calculated the starting (SR), terminating (TR) and participating (PR) roles for the collaboration and each of its sub-collaborations, we then can derive the behavior for each system component as follows. Basically, the control flow of the behavior of each system component follows the control flow of the collaboration behavior; it is obtained from the global behavior specification of the collaboration "by projection" onto the particular component. This means that actions not local to the component in question are dropped. Therefore any sub-collaboration for which no participating role is allocated to the component in question will also be dropped.
In addition, the following coordination messages between different system
components are introduced (for details, see Table 3):
− Flow message for coordinating strong sequencing, abbreviated fm(x) or fim(x, i);
each message includes a parameter x which indicates to which strong sequencing
construct the message belongs within the syntactical structure of the overall
collaboration behavior, as originally proposed in [
In the following, we define an algorithm that realizes the derivation method explained in Section 3.1. We assume that the overall workflow is defined by a maincollaboration and several sub-collaborations, identified by their name, which are invoked by the main-collaboration or some activated sub-collaboration. Each of these collaborations is defined by a behavior expressions C which is formed by primitive actions, sub-collaboration invocations and the operators introduced in Table 1. For each of the components c that implements the roles of these collaborations, we define in the following a translation functions Tc that translates the behavior expressions of the collaborations into local behavior expressions to be performed by the component in question. These local behavior expressions will include those primitive actions of the collaborations that are performed by the component in question, in addition to the sending and receiving of coordination messages as required by the behavior expressions. Overall, the syntactic structure of the resulting behavior expressions for all these components resembles the syntactic structure of the original expression of the global collaboration behavior.
In the following we make the assumption that all choices are local. We note that
certain standard approaches to solving non-local choices could be easily integrated
with our derivation algorithm. However, as explained in [
Table 3 contains the definition of the translation function Tc (C) that defines for a given global behavior expression C the behavior of the system component c. It is defined recursively by the rules in the table. The resulting component behavior expression is constructed using the same sequencing operators as for describing the global behavior, however, since the behavior is performed locally by a given component, there is no point in making a distinction between weak and strong sequencing. We simply use the operator “;” to denote sequential execution.
The text defining the translation function in the table uses a notation similar to Java Server Pages, namely a mixture of text that represents the generated specification of the component behavior, and of text that represents actions and decisions to be performed during the translation. The latter is written in italics. We also include some comments (written between “(*” and “*)” ) and notes for making the definition of the translation more readable.
As mentioned at the beginning of Section 3.1, the parameters of the coordination messages and the buffering of received messages before their consumption are important elements for the correct operation of the distribution system derived by the algorithm of Table 3. We make the following assumptions: 1. Each coordination message contains the following parameters: (a) source role, (b) destination role, (c) name of sub-collaboration it belongs to, (d) the particular sequencing operator instance it refers to within the global behavior
expression of the given sub-collaboration – these are the parameters named x,
y, and z in Table 3. As noted earlier, the parameters (c) and (d) above are
important for non-ambiguous choice propagation (see also [
The reception of coordination messages proceeds in two steps: When a message is received by a component, it is first placed into a buffer pool, called receive-buffer. It will be “consumed” from the receive-buffer only when the behavior expression generated for the component according to Table 3 foresees the execution of a receive statement for a message of the specific type and parameter values. The message parameters mentioned above, and the additional parameter mentioned under point 4 below are used to determine whether a message in the receive-buffer is “receivable”. If no receivable message is in the receive-buffer, the execution of the local behavior will wait until such a message arrives.
The flow messages used within an interrupt construct, abbreviated fim(x, i), have an additional Boolean parameter i that indicates whether an interrupt was successful.
The execution of a weak while loop, say C1*w C2 , within the distributed
environment may lead to situations where the component deciding the looping
conditions, say c1 , may already have performed several iterations of C1 while
another component c2 may have only started the first iteration (as shown in
Figure 9(c) of [1]). When c2 receives a flow message indicating the beginning
of C2 , it is important that c2 can determine whether C2 should be started or
whether more executions of C1 should first be performed. Therefore we
include an additional parameter, say n, in all flow messages that are part of the
coordination within C2 , which contains the number of times that C1 has been
executed. For more details, see [
C = invoke <subcol>(R) C = C1 ;s C2 C = C1 ;w C2 Tc (C) = Tc (C1) “;“ SFM(C1 , C2) “;“ RFM(C1 , C2) “;“ Tc (C2) where SFM(C1 , C2) = if c in Alloc(TR(C1)) then
“send fm(x) to all c’ in (Alloc(SR(C2)) – {c})” and RFM(C1 , C2) = if c in Alloc(SR(C2)) then
“receive fm(x) from all c’ in (Alloc(TR(C1)) – {c} ” Note: The term “– {c}” avoids that flow messages are sent to the component itself.
Tc (C) = Tc (C1) “;“ Tc (C2) C = C1 [] C2 C = C1 * s C2 C = C1 * w C2 C = C1 || C2 C = C1 |> C2 else C3 Tc(C) = DOcimc(C1, C2) [] DOcimc(C2, C1) where DOcimc(C1, C2) = if c in Alloc(PR(C1)) then “( Tc (C1)” if c is responsible for cim then “|| send cim(y) to all c’ in (Alloc(PR(C2)) - Alloc(PR(C1))) )” ; else if c in (Alloc(PR(C2) - Alloc(PR(C1))) then “receive cim(y)“ Note: The function DOcimc(C1, C2) generates code for performing C1, and looks after the transfer of choice indication messages from some component participating in C1 to those components not participating in C1, but in C2.
We assume Alloc(SR(C1)) = {r}, and Alloc(SR(C2)) = {r} or C2 = İ .
Tc(C) =“(“ Tc(C1 ) “;“ SFM(C1 , C1) “;“ RFM(C1 , C1) “)* ; ( “ Tc(C2) if c=r then “|| send cim(y) to all c’ in PR“ if c in PR then “|| receive cim(y) from r“ “)” where PR = Alloc(PR(C1)) - Alloc(PR(C2)) – {r} As above, except that the SFM and RFM constructs are absent Tc (C) = Tc (C1) || Tc (C2) We assume that C2 has the form “ <action>(r) ;s C2’ “.
Tc (C) = NormalBeh ||* InterruptBeh . (see note below) These two parts communicate within each component using the following boolean local variables which are initially false:
Interr : an interrupt occured (but it may have occurred too late)
Interrupted : the normal behavior has been interrupted In addition, a local variable I-Enabled is used by the InterruptBeh part. The action “wait(x)”waits until the expression x becomes true.
NormalBeh = if c in Alloc(PR(C1)) then “( Tc (C1) |> (wait(Interr);
Interrupted := true; ) else İ );” if c in Alloc(TR(C1)) then “send fim(x, Interrupted) to all c’ in SR” if c in SR then “(for all c’ in (Alloc(TR(C1))–{c}) do (receive fim(x, i) from c’; if i then Interrupted := true;); if not Interrupted then DOcimc (C3, C’2); ) ||* (wait(Interrupted); DOcimc (C’2, C3) ) ) “ else “ (DOcimc (C’2, C3) [] DOcimc (C3, C’2) ); “ where SR = (Alloc(SR(C’2)) U Alloc(SR(C3))) –{c} InterruptBeh = if c = r then ( if c in (Alloc(SR(C1)) then “I-Enabled := true; “ else “for all c’ in
(Alloc(SR(C1))–{c}) do (receive iem(z); I-Enabled := true) || ( wait(I-Enabled); <action> (* this may never happen *) ;
Interr := true; send im(z) to all c’ in (Alloc(PR(C1)) - r) ; ) “ else (* c not equal r *) ( if c in Alloc(SR(C1)) then “send iem(z) to r; “ if c in Alloc(PR(C1)) then
”(receive im(z) from r (*may not happen *); Interr := true; )”
The expression “C1 ||* C2” has the meaning that the two sub-expressions C1 and C2 are executed in parallel, but the whole construct terminates as soon as C1 terminates.
Referring to the example discussed in Section 2, let us assume that the roles P (patient), R (receptionist) and D (doctor) are to be implemented on three different components, also called P, R and D, respectively. In the following we explain how the algorithm described in Section 3 can be used to derive the behavior of these components such that they realize the correct coordination of activities among these three components.
We assume that the starting and terminating roles of the basic activities are as follows: SR(<registration>) = TR(<registration>) = {P}; SR(<wait>) = {R}; TR(<wait>) = {P}; SR(<h-up>) = TR(<h-up>) = {P}; SR(<assign>) = TR(<assign>) = {R}; SR(<consult>) = {D}; TR(<consult>) = {P, D}. Using Table 2, this leads to the starting and terminating roles of the sub-activities <w> and <act> as follows: SR(<w>) = TR(<w>) = {R}; SR(<act>) = {R}; TR(<act>) = {P, D, R};
Let us first determine the behavior for the sub-activities <w> and <act> at each of the three components:
TP (<w>) = TP (<wait>) * ; receive cim(y) from R TP (<act>) = TP (<consult>) (* P is not involved in <assign> *) TR (<w>) = TR (<wait>) * ; send cim(y) to P TR (<act>) = TR (<assign>) (* R is not involved in <consult> *) TD (<w>) = İ
TD (<act>) = TD (<assign>) ; TD (<consult>)
Now let us determine the behaviors of the three components for the <telemed> activity. Applying the rules of Table 3, we obtain the following behaviors for all components c = P, R or D:
Tc (<telemed>) = Tc (<registr>) ; Tc (<w> |> <h-up>; İ else <act> ) = Tc (<registr>) ; ( NormalBeh c | | InterruptBeh c ) where TD (<registr>) = İ and the behaviors NormalBeh c and InterruptBeh c are defined as follows:
NormalBeh P = (TP (<w>) |> ( wait(Interr); Interrupted := true;) else İ ); ( receive cim(y) from R [] TP (<act>) ) InterruptBeh P = receive iem(z) from R; <h-up>; Interr := true; send im(z) to R NormalBeh R = (TR (<w>) |> ( wait(Interr); Interrupted := true;) else İ ); ( receive fim(x, i) from P; if i then Interrupted := true; if not Interrupted then TR (<act>) ) | | (wait(Interrupted); send cim(y) to D and P ) InterruptBeh R = send iem(z) to P; receive im(z) from P; Interr := true NormalBeh D = TD (<act>) [] receive cim(y) from R
InterruptBeh D = İ
By substituting the behaviors of the sub-activities <w> and <act> given above, we
obtain three behavior expressions for the three system components P, R and D. These
expressions include the local behaviors of the primitive collaborations <wait>,
<assign> and <consult> and are independent of their particular nature; the expressions
only depend of the sets of starting, terminating and participating roles given above.
We note that these behaviors can also be represented by UML Activity Diagrams.
Further details are given in [
We assume that the system design for a distributed system consisting of several separate components can be developed in the following steps: 1. Construction of a requirements model including the specification of the global behavior of the system in terms of basic activities and their temporal ordering. 2. Through architectural and non-functional requirements, a certain number of separate system components are identified; each of the activities identified at the requirements level is either allocated to one of these components, or performed as a collaboration among several components. 3. Based on the global behavior of the requirements, the identified components and a more detailed description of the basic activities, the distributed system design is developed which defines the behavior of each of the system components including the messages required for realizing the collaborations and for ensuring the global coordination of all activities among the different system components.
We have shown in this paper how the third step can be automated, assuming that
the global behavior is given in a suitable modeling language. The modeling language
supported by our design derivation algorithm described in Section 3 supports most of
the concepts found in UML Activity Diagrams. This includes stepwise refinement
where the behavior of a given activity is further detailed in terms of sub-activities and
their ordering constraints, described as a separate activity diagram. In addition, a
distinction between weak and strong sequencing can be made in the requirements
model. We plan to prove the correctness of the algorithm, as discussed in [
We believe that this approach to the automatic derivation of distributed system designs is useful in many fields of application, including distributed workflow management systems, service composition for communication services, e-commerce applications, or Web Services.
We plan to work on the implementation of the here proposed derivation algorithm in a tool environment and on the extension of the algorithm to support more general order relationships including data flow.
Acknowledgements: I would like to thank Rolv Braek and Humberto Nicolás Castejón for many interesting discussions on the problems and issues related to this paper, and Fedwa Laamarti and Toqeer Israr for suggesting improvements to an earlier version of this paper. [1] H. Castejón , G.v. Bochmann, R. Braek, Using Collaborations in the Development of
Distributed Services, submitted for publication.