LJP : A specification language for rapid prototyping of concurrent systems

Dan Regep Fabrice Kordon LIP6-SRC, Universitk P.&M. Curie

4 place Jussieu 75252 Paris Cedex 05,, France

PhD. student CS TELECOM 28, rue de la Redoute, BP 74

92263 Fontenay-aux-Roses Cedex, France & E-mail: Dan.Regepelip6. fr

Abstract : We present Lfp : a spec$cation Language for rapid Prototyping of embedded concurrent systems. LfP is a graphical coordination language providing facilities of an Architecture Description Language (ADL). LJT can be linked to an UML-based methodology. It aims to provide a UML description with structured information enabling for- mal ver$ication and automatic generation of distributed programs. To do so, we inspired L p f r o m principles stated in ODP (computational, engineering and technological viewpoints). Keywords: Modelling of embedded distributed systems, Formal verification, Automatic distributed program gene- ration, U M L extensions, ODP.

1. Introduction Design and implementation of industrial systems is get-

ting more and more complex [9]. This is a problem for em- bedded distributed systems requiring to be certified.

Methodologies have been elaborated to solve this prob- lem. UML [16] can be considered as a first important issue: the definition of a standardized formalism to describe a so- lution. However, UML remain at an early stage of applica- tion design and implementation. Actual code generation from UML is not satisfactory if we consider its deployment on a specific target architecture.

UML specifications are difficult to verify due to its semi-formal semantics (dynamic aspects are not fomially- defined). A typical illustration is the interaction between components of a system. This information is dispatched into several diagrams: interaction, sequence and state. Links between these diagrams cannot be checked automat- ically.

Formal methods may be of interest to verify a system but they also lack several requirements to be used in industry [13]. Among them, we can cite: they are difficult to exploit by engineers because of the required mathematical back- ground, and current systems are too complex to enable a proper use of these methods (combinatorial explosion).

Compared to existing Architecture Description Lan- guages (ADL), UML seems not to be adapted to describe software architectures 1151. However, the choice of the best ADL remains an open issue; there is no synergy on the use of a unified ADL notation.

We think UML is a good formalism for early design of embedded distributed systems but it should be enriched to enable proper code generation and formal verification.

The objective of this paper is to present LjP (Language for Prototyping): a formalism dedicated to evolutionary prototyping of embedded distributed systems. Lfl can be considered as an enriched UML notation providing an ap-

E-mail: Fabrice.Kordon@lip6. f r

propriate structure for both efficient code generation and formal verification.

Code generation for embedded systems must enable the plugging of generated programs into an execution environ- ment (e.g. middleware or execution runtime).

Formal verification techniques should be applicable to subsets of the system in order to reduce the effects of com- binatorial explosion. They should also rely on concepts dedicated to the application domain.

Section 2. present our methodological approach and connects it to the state of the art. Then, Section 3. details the LjP structure. We briefly sketch issues for both code gen- eration and formal models synthesis in Section 4. before a conclusion.

2. Methodological aspects The use of CASE tools for Rapid Prototyping becomes

a well accepted technique in software engineering. Com- pared to textual notations, graphical formalisms seem to be more abstract, better structured, and more user-friendly. As mentioned in [MI, design of concurrent systems should fol- low this type of procedure: system specification, system de- sign or modeling, model checking and validation, program or code generation, prototype testing and application de- ployment.

Each of these steps can be refined. The development process can be incremental and then, assumptions made at a development step should remain valid when moving to later ones. Otherwise valid models and specifications may lead to erroneous implementations. Each development step may rely on an adapted language such as:

UML [16] for system specification and modelling, Petri-Nets [ll] for model checking and validation, an ADL [15] for the description of the software archi-

tecture, a coordination language [12] for the description of syn- chronization constraints. Such languages are well suited according to their goal.

However, none of them is suitable for the complete devel- opment life cycle. Moreover, their approaches are not or- thogonal to each other and are hard to be harmonized.

L p proposes to be a glue specification language for concurrent systems. It integrates capabilities defined in the state of the art and most often dedicated to a given develop- ment phase. LjP goals are:

to extend UML in order to make i t both an ADL and a

to enable formal verification using associated, semantic graphical coordination language;

equivalent Petri-Net models;

1074-6005/01$10.00 0 2001 IEEE 90

to provide constructors for automated code generation of distributed applications.

2.1. Premises

cording to the following axes: Current work on similar goals may be dispatched ac-

Formal veriJication of UML models and ADL studies focus on their verification capabilities. SofnYare Architecture Description related papers pro-

pose ADL or UML extensions to make it an ADL. Program code generation issues explore code genera-

tion using a flexible and reusable transformation engine as well as interaction between the specification and the execution environment (language, middleware, etc.)

2.1.1. Formal verification of UML and ADL UML is the current standard to specify and model Object

oriented (00) software systems. However, UML is a semi- formal language because its dynamic semantics are defined informally [16]. Moreover, UML does not provide any mo- del checking nor validation capabilities. Thus, to be valida- ted, UML models have be converted to equivalent formal specifications.

It is possible to validate UML using model checking techniques such as SPIN [2,10] or the JACK environment [4] that integrates various specification and verification to- ols. These works emphasize that translation of UML mo- dels to equivalent formal specifications should be automatic. However, these approaches are usually based on assumptions and constraints limiting verification capabili- ties to a subset of UML.

Petri-Nets can be used to validate ADL specifications. Mechanisms have been defined for communicating proces- ses [SI or CORBA based systems [l]. SADT is also used as an ADL associated on the Colored Peri-Nets semantics [3]. Petri-Nets enable the computation of structural properties (such as bounds or deadlocks) as well as model checking. However, despite good verification capabilities, Petri-Nets cannot be directly used for large scale systems but may be associated with an higher level notation having structuring capabilities (e.g. objet oriented or component based).

The use of formal verification methods requires special training and, thus is hard to be handled by software pro- grammers. To cope with this problem they should be encap- sulated by services of a CASE tool [13].

In our approach, existing UML models can be reused. Formal verification and model checking are achieved indi- rectly via equivalent Petri-Net representations. The verifi- cation step represents an external issue and may rely on various verification techniques.

2.1.2. Software Architecture description

UML is not an ADL because it is not adapted to software architecture description [15]. However, UML is extensible using dedicated UML profiles. There are examples on how to extend UML using dedicated stereotypes in order to pro- vide ADL capabilities [7, 201. Our approach proposes a standalone ADL formalism completing UML. Reuse of ex- isting UML models is achieved using a semi-automatic translation: L p is a reformulated description of the system integrating information that cannot be expressed in UML.

Specific ADL have been defined or compared [15]. We

identify various aspects we group in three axes : software architecture issues. Large-scale concurrent systems are difficult to imple-

ment. The use of a multi view approach breaking the system design into orthogonal aspects facilitates the design [SI.

Architectures designed to solve a given problem are usu- ally not reusable. To avoid this, the ODP framework offers an open standard approach to the design of distributed ap- plications. Our multi-view approach to software architec- ture description is inspired from ODP.

component model. Most ADL are component oriented. A component repre-

sents a concurrent (active) execution unit [22]. However, concurrent systems may also contain passive components (e.g. library units). So, component deployment constraints have to be coherent with execution aspects (process, thread or passive resource) otherwise good models may lead to er- roneous implementations. Our approach provides both pas- sive and active types of components.

Software components participating to various collabora- tions may play discrete roles (alternative behavior aspects) [16]. The specification of a component behavior using roles provides better prototyping capabilities [22]. Our approach follows this behavior decomposition schema and also pro- vide hierarchical behavior refinement [MI.

interaction and communication protocol model. ADL usually rely on typed binding points or communi-

cation ports [23] to specify component access points. Bind- ing points specify a binding contract that controls the component interaction semantics.

Most ADL (and UML) mainly offer synchronous bidi- rectional invocations or asynchronous unidirectional mes- sage passing. Our approach provides these interaction models and also supports the definition of asynchronous bi- directional invocations like in MPI [14] as well as synchro- nous unidirectional transactions.

Simple basic communication models (e.g. pipes, stacks, data bags etc.) may be defined using dedicated components. We base our approach on ODP-like Binding Objects [6] . Specialized communication patterns (e.g. multicast) are obtained by combining and parameterizing these basic communication components into larger structures [17]. 2.1.3. Code generation issues

We already used Metascribe [ll], a transformation en- gine generator to prototype an UML to C++/Ada95/Java code generator [19]. Our experience revealed good rapid prototyping and reuse capabilities. We will thus use it to implement LjP code generators.

LjP uses a multi-view approach inspired from the ODP standard [6]. It proposes two orthogonal views of a distrib- uted software system: functional and implementation. Code generation from Lfp relies on both views.

One problem in code generation is the interaction be- tween the produced application and its execution environ- ment. Similarly to Quarterware [21], a customizable framework for the construction of middleware platforms, we have defined a neutral, abstract, simple yet complete communication model. Code generation is thus indepen- dent from the targeted execution environment and should be easily adapted to various middlewares (e.g. CORBA, RMI or MPI).

91

2.2. The Proposed Methodology The main idea beyond LjP is to prototype concurrent ap-

plications using combined approaches: sofrware architec- ture description, formal verification of proposed models and application deployment on a target architecture.

Our approach is inspired from the ODP framework, cur- rent state of the art on ADL, UML and formal verification methods like Petri-Nets.

LfP use two orthogonal views : the functional view (implemented as a diagram), the implementation view (implemented as textual anota- tions). The LjP functional diagram explains how the system

components (software objects) behave and interact. This di- agram also describes the system software architecture. A graphical notation inspired from coordination languages with ADL capabilities is used to define a functional dia- gram.

Functional diagrams reuse concepts from the ODP com- putational and engineering viewpoints (e.g. LjP classes and class instances are similar to ODP computational objects and ODP basic engineering objects).

The LfP implementation view defines the system imple- mentation topology (how the system components are de- ployed) and their implementation constraints (e.g. target OS, implementation programming language etc...).

The implementation view is inspired from the ODP en- gineering and technological viewpoints.

Our approach is divided in five steps, as shown in Figure 1:

step 1: existing UML models are transformed into cor- respondent LjP skeleton representations. Equivalences between UML and LfP are presented in Section 3.1. This step should be automatic. step 2: the LjP skeleton has to be enriched in order to

properly express interactions between components. For example, informations stored in various UML diagrams (collaboration and sequence) should be consolidated in order to enable automatic processing. step 3: formal specifications, such as Petri nets, are

automatically derived from LfP functional diagrams in order to enable proof of the system. step 4: another enrichment is required before applica-

tion deployment. Designers have to specify the imple- mentation view by means of annotations attached to the LfP functional diagram. step 5: the two LjP views are input to the code generator to synthesize the corresponding distributed application.

...*.**... . .

- Figure I : The context of Lpformalism.

3. The LJP formalism 3.1. The Lfp structure

The LfP functional diagram contains: a declarative part defining management information

(e.g. model name, author, version number, comments and the associated UML model if any) and formal decla- rations: types or constants. Elementary types are : inte- ger range, ordered enumerations (bounded list of elements) or the opaque type. The opaque type denotes variables which only support the affectation operation and, thus, cannot influence the execution workflow.

A LjP class corresponds to a complete UML instancia- ble class. Thus, abstract or virtual UML classes have no correspondence in Lfl.

A media is used to connect classes. It specifies both in- teraction contract and communication semantics. A media corresponds to an UML association, aggregation or compo- sition.

a list of entities: classes and media.

DatabaseServer Cllent 0 1 "+" edd(lnt key. opaque data)

,"+"opaque nsd(int key) "+* de/ete(int key opaque dete) "+"mod~(int key opaque data)

Figure 2 : The UML Class Diagram of a simple database system Let us consider the UML Class Diagram of a simple con-

current database (Figure 2). The system has one or more servers instances supporting four operations : add, read, modify or delete (on a database item).

LjP main diagram : model-name := '&are example'; author := ' L h Regep': verslon := 0.90: comments := ";

C o n s t MAX-SERVERS := 10; UML-model := 'example.md1':

type index Isinteger range 1.. lOOOoO@,

Figure 3 : Example of a Lfp main diagram. The corresponding LjP diagram is presented in

Figure 3.The declarative part defines a constant represent- ing the maximal number of concurrent Databaseserver instances and a new type. The first two icons correspond to the Client and Databaseserver classes. RE-stub and RPCBroxy icons represent the client and server side of a composed communication media (to connect clients and servers). RPC-stub and RPCDroxy are bounded together and correspond to the UML association of Figure 2. The role of these two media is to enable transparent communi- cation between clients and database servers (clients are not of server address) and to provide load balancing (database servers are selected upon availability). The Database me- dia abstracts the database itself which is a shared passive re- source (the Databaseserver class has to enable coherent access to this entity).

3.2. Lfp entities As mentioned in Section 3.1., LjP diagrams contain

classes and media. Their description strongly rely on LfP- FSM (Finite State Machine) supporting various elements of a class or media specification. Therefore, we present the LjP-FSM structure prior to classes and media.

92

3.2.1. Le-FSM

Symbol name Icon

State

Protector

Binder

Constructor

0

variableJock -c-- protector name (4) * protector cardinality

binder name recel RPC-media.receiver

)., I reference to a binder

target 4 Serverclass - class name

QBEGIN FINAL

I LOOP transition name <i <= 3 > + ................. guardcondition

i++; * action [ i > 01 safety condition

Transition

S-Transition 1 U ~ o o p f-- transition name alias

H-Trans1 tion 1 u a d d - d a t a * sub-net name

Barrier barrier name

LjP-FSM to increase readability. Sub-LjP-FSM have to have one initial state and one terminal state. These are binded to the predecessor and succesor of the H-Transi- tion. Barriers are special shared Transitions corresponding

to a synchronization point between all running concur- rent instances of a LjP-FSM. Protectors are shared locks (multi-level semaphores or groups of semaphores) used to provide restricted access to a shared resource. They are used to define critical sec- tions between instances of a LjP-FSM. A protector can be standalone or associated to one variable or group of variables. The protector cardinality specifies how many concurrent LjP-FSM instances may get into the critical section simultaneously. Binders are access points to media. LjP-FSM commu- nicate through binders by means of typed messages. A message consist of three fields : 1) message discrimina- tor that can be modified by the media, 2) message name that are known by the media, 3) message arguments that must be opaque for the media. Binders are defined in media and are only referenced in classes. Constructors are special media used to create new

class instances. Constructors must specify an initializa- tion context. Table 2 present connection links that may be used within

Arcs connect States to Transitions, S-Transitions, H- Transitions or Barriers and express the execution sequence. Protector Links connect Protector to Transitions or S- Transitions and vice versa to define critical sections. Media Links are used to connect Binders or Construc- tors with Transitions or S-Transitions. Media Links specify the connection direction (in, out or inout). A Media Link specifies the binding contract between local context variables and message arguments (the message discriminant, its name and the message arguments).

Arc I Protector link 1 Medialink

a LjP-FSM:

- - - 1 --* 1 - Table 2: Graphical representation of Lfp-FSM connectors

3.2.2. LjP Classes

class and expresses some functional aspects of a system: A LjP Class corresponds to an UML implementation

a declarative part specifying: 1 ) the class identifier, 2) for each binder, potential messages and their argument (some of these messages correspond to public methods), 3) a list of private methods and their arguments, 4) the list of computational procedures with their parameters. a list of FSM defining : 1) the execution contract (main FSM), 2) class roles (optional), 3) methods. Definition of the main FSM is mandatory. It represents

the execution workflow of a class instance. Transitions in the main FSM may be references to class roles (if any) or class methods.

Roles correspond to alternative class behaviors; their definition is optional. Each role is described using a LjP- FSM. Transitions in a role may represent references to methods.

93

Methods are also described by means of a LjP-FSM de- fining their execution workflow (i.e. the method execution contract).

Figure 4 shows the description of the Databaseserver class (example presented in Figure 2). The declarative part specifies a connection to the <<RPCqroxy. receiver,, binder. Four messages can be accepted : add, modify, de- lete and read, corresponding to public class methods. <<in>> arguments are inputs and ccout,, arguments are out- puts. Message arguments are typed. This class has no pri- vate methods nor computational procedures. The Main FSM and the four method icons are links to LjP-FSM de- scriptions. Our example contains no role.

Lfp Class : DatabascSavcr

messages from RPC-proxy r e c e i v e r : in add (in i n d e x k e y . in opaque d a t a ) : in modify [in i n d e x k e y . in opaque d a t a l : in d e l e t e Iin index key): in r e a d [in i n d e x k e y . out opaque d a t a ) :

internal methods : procedures ; [odd1 F l I .i-I T I M O - M O - M O - M O -

Figure 4 : Example ofa main LfP diagram. The execution contract of the Databaseserver has the

add, read, modify and delete methods are mutualex- clusive in the sense of [12]. This does not restrict the number of concurrent instances of the same method. add, modify and delete operations are unary selfexclu- sive in the sense of [12]. Thus there cannot be more than one instances of the same method.

following constraints :

0 a E w LP-FSM : main FSM

walit-fa-all

delet-data

local da ta is opaque: read-data modv-data oontext :

local key is i n d e x : local H I D 10 Integer range 1 . . MPX-SERVERS: shared active-writers := 0 1s integer range 0 . . 1 ; shared a c t i v e - r e a d e r s := 0 i s integer range O..MAX-SERVERS;

Figure 5 : The main FSM of the Databaseserver class. Figure 5 presents the main LjP-FSM defining this exe-

cution contract. The instance context of a server is com- posed of three local variables (data, key and HID) and two shared ones (active-readers and activewriters). data is opaque and represent a data within the database (execution is not affected by its value). key is an access in- dex within the database. data and key variables are used to characterize database elements. HID contains the class ins- tance identifier. active-readers and active-writers respectively contain the number of concurrent readers and writers accessing to the database.

Before accepting any request all server instances must reach the wait-for-all barrier. No final state is modeled because the server behaves like a daemon

To increase readability, the execution contract is hierar- chically structured in four sub-LfP-FSM. They share the execution context definded in the main FSM.

Figure 6 shows the add-data sub-LjP-FSM, which spe- cifies execution constraints to be satisfied to trigger the add method. When receiving a add message (condition asso- ciated to the media link relating the binder and the first tran- sition), an exclusive access to activewriters is requested by means of the lock protector . A critical sec-

tion is defined between . Invocation of add can be completed when no reader is using the database (condi- tion associated to the middle transition). When leaving the critical section , a null return value is send back via the binding point

and

(synchronization with a client). sub-LfP-FSM : add-data

data := msg.va1u.s :

Figure 6 : The structure ofthe 'add-data'sub-net FSM Figure 7 shows the LjP-FSM defining the add method.

It consists of one action that set an element in the Database media. The element is overwriten when it already exists.

0 ~ d i w - w r i t w s . l o e k

LP-FSM : add BEGIN Dalabaseh

msg = 'set' FINAL msg#l =key;

msg#2 = data,

Figure 7 : The FSM of the 'add'method from our example.

3.2.3. LJP Media Media connect instances of LjP Classes. It is possible to

use them as basic components or to assemble them into more sophisticated communication patterns. Media con- necting two or more LjP classes correspond to a UML as- sociations, aggregation or composition. Media can also be used to implement shared resources (e.g. a list, a file etc...).

A media specifies binding constraints and semantics and communication protocol. We base our approach on the ODP contract definition [6]. A media consists of:

a declarative part defining : 1) media variables which are similar to class variables, 2) the interaction contract consisting of several binding constraints. the main FSM representing the communication contract (communication protocol semantics). The binding constraints specify: 1 ) a reference to the

connected binding point, 2) the communication mode (synchronous or asynchronous), 3 ) the accepted mes- sages and their arguments. 4) the binding multiplicity (one, any or all). One multiplicity means that the binder is con- nected to only one class or media instance. ~ n y multiplicity leave this unspecified. ~ 1 1 multiplicity specifies that the binder is shared by all the connected classes instances.

A media cannot play various roles, has no methods nor associated constructors. Media are activated by classes.

Let us consider the RPCSroxy media from our case study (Figure 3 ) . It has three communication constraints:

clients and servers should not be aware of their number, availability and identity. clients request should be routed upon server availabil- ity. interaction is unbuffered, synchronous and should not

disturb other concurrent connections. Figure 8 shows the RPCSroxy main FSM. It behaves as

follow : all the RPCjroxy media inputs are bounded to- gether with the RPC-stub outputs . When a RPC-stub is- sues a request the first available =_proxy will match it

and communication arguments are saved into local va- riables. Then, the request is passed to the connected server

94

through the receiver binder attached R X - S t u b when the service is completed .

. Answer is sent back to the

LP-FSM : WC-proxy serdeiia boundedto RPC_slub,mwer: r&'eFier:

~ C h r m o u r ; rynchmnous ; mutipiicity:= ail; + Q @ mutipliciiy.: t ; messages : messago: : context:

locaic"mtlD is -qua ; In add(in index key, in O p l p l e data); iOcal msQ-namei'oplW; in modily(in indexkey, in W w e datal; local m!La~ ' r *~s ; Indeldelinindex hey); outdelete (in Index he9;

bindcn : in read (hndex key, aut opaque data);

Outadd (in Index key, in opapre dala); outmodtfy (inindm key, in o p w c data);

outread (in Index hey, out opaqus dala).

a smaer receiver

c l t e r K = msgdscnmiralor source10 m s g n m e =msg msg = m s g ~ l a n e .

msg-arg = msg arpmer ls n msg arpmer ts = m s L a r g , a m d a r

m s g n m e =msg @ msg argumerls = msg_arg,

m d a r

m s g n m e =msg

Figure 8 : The main FSM of RPCjroxy

4. Formal verification of LJP models and automatic code generation

This section defines the principles of verification and code generation. These operations are implemented using Metascribe a transformation engine generator that has pro- ved good prototyping capabilities [19].

4.1. Formal verification Formal verification of LfP models is performed on auto-

matically generated Petri-Net models. Our approach fol- lows a bottom-up compositional schema and relies on the following rules:

each LfP basic element corresponds to various Petri-Net representations. Each one is adapted to the verification of a given property. each connection arcs or media binder corresponds to

various compositional rules to connect elementary Petri- Net descriptions derived from basic elements. Formal verification and model checking are performed

on the resulting Petri-Net model. This is outside the scope of this paper but can be achieved through external verifica- tion tools such as CPN-AMI [ll].

4.2. Automatic code generation Code generation is independent from the system specifi-

cation phase. The LjF' implementation view consist of se- veral textual annotations (tag values) defining deployment and implementation constraints. It defines:

the application partition and execution entry points, the target implementation language and execution envi- ronment. Thus, for each LjP class, a system designer has to provi-

execution model : active execution units (process or thread) or passive (library units). target programming language and execution environ-

ment. class partition membership (package name if any). For each LfP media we specify the following attributes : execution model (active or passive).

target communication architecture : pipe, socket, software bus (e.g. CORBA) or other communication system (e.g. ADA-DSA, MPI etc...).

de the following information:

Alternative configuration (implementation) schemas may be defined for experimentation.

5. Conclusion This paper presents LfP, a formalism dedicated to the

modelling, formal verification and code generation of dis- tributed embedded systems. LfP aims to serve as a basis for an evolutionary prototyping approach where detailed de- sign, development and maintenance of a system is per- formed at a "model" level.

We consider LfP as a natural extension to UML. Their association provides similar formalisms able to support the entire software life cycle: UML supports early design phase and serves for documentation, LfP helps for formal verifi- cation, implementation (code generation and deployment) as well as maintenance.

Future work aims to provide a prototype of CASE envi- ronment supporting a prototyping methodlogy based on UML and LjP. This CASE prototype will be experimented in an industrial context.

6. References [ l ] R. Bastide, 0. Sy, P. Palanque : "Formal Support for the Enginee- ring of CORBA-based Distributed Object Systems", in Proc. of the Inter- national Symposium on Distributed Objects and Applications, September, 1999. <http://dlib.computer.org/conferen/doa/Ol82/pdf/O I820264.pdf> [2] P. Bose : "Automated Translation of UML Models of Architectures for Verification and Simulation Using SPIN''. in Proc. of the 14th IEEE International Conference on Automated Software Engineering, October, 1999. <http://dlib.computer,org/conferen/ase/W 1 S/pdf/04 I SO 1 OZ.pdf> [3] C. K. Chang, S. Kim : "I 3 : A Petri-net based Specification Method for Architectural Components", in Proc. of the Twenty-Third Annual International Computer Software and Applications Conference, October, 1999. <http://dli b.computer.org/conferen/compsac/0368/pdf/ 03680396.pdf> [4] S. Gnesi, D. Latella, M. Massink : "Model Checking UML Sta- techart Diagrams using JACK", in Proc. of the 4th IEEE International Symposium on High-Assurance Systems Engineering, November, 1999. <http://dlib.computer.org/conferen/hase/04 1 8/pdf/04 180046.pdf> [5] V. Issamy, T. Saridakis and A. Zarra : "Multi-view Description of Software Architectures", in Proceedings of the 3rd ACM SIGSOm Inter- national Software Architecture Workshop, pages 8 184, November 1998, http: //www.irisa.fr/solidor/doc/../doc/ps98/isaw98.ps.gz [6] ITU-T : "Open Distributed Processing", X.901, X.902, X.903 and X.904 standards, <http://www.itu.int/itudoc/itu-t/rec/x/xSOOup> [7] M. M. Kandt, A. Strohmeier, "Towards a UML Profile for Software Architecture Descriptions", in proceedings of UML2000 - The Unified Modeling Language: Advancing the Standard, October 2-6, 2000. [SI E Kordon, W.EI Kaim, "H-COSTAM : a Hierarchical Communica- ting State-machine Model for Generic Prototyping", in Proc. of the 6th International Workshop on Rapid System Prototyping, june 1995. <http:// www-src.lip6.fr/homepageslFabrice.Kordo~ransparents/T-RSP94.pdf~ [9] N. Leveson, "Software Engineering: Stretching the Limits of Com- plexity", Communications of the ACM, Vol 40(2), pp 129-131, February 1997. [lo] J. Lilius, 1. Pones Paltor :" vUML: a Tool for Verifying UML Models", in Proceedings of the 14th IEEE International Conference on Automated Software Engineering, October, 1999. <http://dlib.compu- ter,org/conferedase/04 15/pdf/04 150255.pdf> [ll] the LIP6-SRC team, the Mars project homepage, <http://www- src.lip6.fr/logiciels/mars/> [12] C. Viedeira Lopes, G . Kiczdes "D : A Language for Distributed Programming", Technical report SPL-010, P97 10047 XEROX Palo Alto Research Center, February 1997.

95

[13] Luqi & J. Goguen : "Formal Methods: Promises and Problems", IEEE Software, Vol 14, N"1, pp 75-85, January 1997. [14] Message Passing Interface Forum. "MPI: A message-passing inter- face standard", lntemational Joumal of Supercomputer Applications, 8(3/ 4), 1994. Special issue on MPI [15] N. Medvidovic, Richard N. Taylor : "A Classification and Compari- son Framework for Software Architecture Description Languages", IEEE Transactions on Software Engineering, vol. 26, no. 1, january 2000. chttp://dlib.computer.org/ts/books/ts2OOO/pdf/eOO70.pdf~ [16] OMG, "OMG Unified Modeling Language Specifiacation", version I .3, June 1999, chttp://www.omg.org/cgi-bin/doc?ad/99-06-09.zip~ [I71 N. Pryce, N. Dulay : "Dynamic Architectures and Architectural Sty- les for Distributed Programs", in Proceedings of the The Seventh IEEE Workshop on Future Trends of Distributed Computing Systems, 1998. chttp://dlib.computer.org/conferen/ftdcs/0468/pdf/04680089.pdf> [18] D.A.C. Quartel, M.J. van Sinderen, L. Ferreira Pires : "A model- based approach to service creation", in Proceedings of the Seventh IEEE Computer Society Workshop on Future Trends of Distributed Computing Systems, pages 102- 110. IEEE Computer Society, 1999. chttp:// wwwhome.cs.utwente.n~-quartel/publications/Ftdcs99.pdf~ [19] D. Regep, F. Kordon, "Using Metascribe to prototype an UML to C++/Ada95 code generator", in proceedings of the I Ith IEEE Intematio- nal Workshop on Rapid System Prototyping, Paris, June 2000. '[20] B. Rumpe, M. Schoenmakers A. Radermacher, A. Schiirr : "UML + ROOM as a Standard ADL?", in Proceedings of the 5th Intemational Conference on Engineering of Complex Computer Systems, October, 1999. chttp://dlib.computer.org/conferen/iceccs/0434/pdf/O4~4~3.pdf~ [21] A. Singhai, A. Sane R.H. Campbell : "Quarterware for Mid- dleware", In Proceedings of ICDCS'98, May 1998. [22] D. Theotokis, G.-D. Kapos, C. Vassilakis, A. Sotiropoulou and G. Gyftodimos : "Distributed Information Systems Tailorability: A Compo- nent Approach", in Proceedings of the The Seventh IEEE Workshop on Future Trends of Distributed Computing Systems, December, 1999. ~http://dlib.computer.org/confere~ftdcs/0468/pdf/04680095.pdf~ [23] G. Wang, L. Ungar, D. Klawitter : "A Framework Supporting Com- ponent Assembly for Distributed Systems", in Proc. of the 2nd Intema- tional Enterprise Distributed Object Computing Workshop (EDOC'98).

96