EVALUATION AND COMPARISON OF ADL BASED APPROACHES
FOR THE DESCRIPTION OF DYNAMIC OF SOFTWARE
ARCHITECTURES
Mohamed Hadj Kacem, Mohamed Jmaiel, Ahmed Hadj Kacem
University of Sfax, laboratory LARIS-FSEGS
B.P. 1088 Sfax, Tunisia
Khalil Drira
LAAS-CNRS
7 Avenue du Colonel Roche 31077 Toulouse, France
Keywords:
ADL, dynamic configuration of architectures, behaviour of applications, component, configuration.
Abstract:
This paper presents an evaluation study of Architecture Description Languages (ADL) which allows to com-
pare the expressive power of these languages for specifying the dynamicity of software architectures. Our in-
vestigation enabled us to release two categories of ADLs: configuration languages and description languages.
Here, we address both categories, and we focus on two aspects: the behaviour of software components and the
evolution of the architecture during execution. In addition, we explain how each ADL handles these aspects
and demonstrate that they are generally not or not enough dealt with by most of the ADLs. This motivates
future extensions to be undertaken in this domain. Throughout this paper, we illustrate the comparison of these
two aspects by describing an example of a distributed application for collaborative authoring support.
1 INTRODUCTION
Software applications are more and more distributed,
large and complex. Such applications are made up
of a generally significant number of software entities,
scattered on the network, which cooperate in order
to provide services to their users. This complexity is
related to the great geographical and structural disper-
sion of the entities constituting the application, to the
material and software heterogeneity, and the abundant
interaction between them. Moreover, these applica-
tions must usually undergo various modifications dur-
ing their life cycle in order to face new requirements
of the users and / or the new technologies.
In our study, we mainly deal with distributed col-
laborative applications, such as the collaborative au-
thoring of research papers. This kind of applications
is characterized by a dynamic architecture which may
evolve during system execution. The evolution of an
architecture is generally expressed in terms of recon-
figuration operations which correspond to the addi-
tion/removal of a component or a connection between
components. In addition, a reconfiguration can be in-
duced by an internal (component) event or by an ex-
ternal (user) event. Accordingly, many reconfigura-
tions can not be known in advance and many others
may depend on the behaviour of some components.
Hence, the design of such systems becomes an in-
tricate task requiring rigourous approaches. Accord-
ingly, it is necessary to have a specification language
which support the description of dynamic software ar-
chitectures allowing reconfigurations induced by in-
ternal and external events. In our approach, we made
recourse to ADLs and we tried to select the most suit-
able ADL for the specification of our applications.
The investigation of most existing ADLs enabled us
to evaluate them with respect to the above mentioned
aspects. This paper presents the main results of this
comparative study.
In our study of ADLs, we focus on specifying the
dynamic of architectures as well as the behaviour of
components. Indeed, we measure for each language
its expressive power according to these two aspects.
It should be stressed that few works considered these
aspects while evaluating ADLs. The majority of them
were interested rather in classifying ADLs with re-
spect to static aspects. The most outstanding one is
the work of Medvidovic and Taylor (Medvidovic and
Taylor, 2000) that tried to classify existing ADLs.
This work identifies the main characteristics which
have to be present in an ADL. Riveill and Senart
(Riveill and Senart, 2002) and Barais (Barais, 2002)
essentially sought to classify ADLs in two classes:
configuration languages and description languages.
They evaluate the ability of these languages to de-
scribe reconfiguration. Finally, other works like the
189
Hadj Kacem M., Jmaiel M., Hadj Kacem A. and Drira K. (2005).
EVALUATION AND COMPARISON OF ADL BASED APPROACHES FOR THE DESCRIPTION OF DYNAMIC OF SOFTWARE ARCHITECTURES.
In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 189-195
DOI: 10.5220/0002524701890195
Copyright
c
SciTePress
one of Allen and al. (Allen et al., 1998) consist in
extending Wright so that it supports the run-time re-
configuration.
Our study has enabled us to identify several weak
points in ADLs. These weak points are in several or-
ders. Indeed, the dynamic of architectures is not well
supported by ADLs although there are some propos-
als which are interesting (Darwin (Dulay et al., 1993)
and Olan (Bellissard et al., 1996)). Moreover, the dy-
namic of software architecture is not much expressed.
ADLs are interested only in the systems having a fixed
number of configurations which have to be known in
advance (Wright (Allen et al., 1998)). Thus, it is not
possible to perform arbitrary reconfiguration opera-
tions and particularly those which are external dur-
ing the application execution. Finally, the behavioural
aspect is almost absent in the majority of ADLs ex-
cept for some such as Rapide (Rapide, 1997) which
allows to describe the behaviour using process alge-
bra. However, the behaviour description expresses
only communicating events and does not consider re-
configuration operations.
This article is organized as follows. Section 2 de-
fines basic ADLs concepts. In Section 3 we introduce
our case study: an application for collaborative au-
thoring support. Sections 4 and 5 present the ADLs
studied and evaluate their ability of describing the dy-
namic of an architecture and the behaviour of compo-
nents. Finally, in Section 6, we present a synthesis of
the obtained results.
2 WHAT IS AN ADL?
An ADL (Accord, 2002), (Medvidovic and Taylor,
2000) is defined as a textual or graphic notation, for-
mal or semi-formal. It allows to specify software ar-
chitectures and it is generally accompanied with spe-
cific tools. In our study, we noted a large variety of
notations offered by ADLs. Nevertheless, the three
concepts of component, connector and configuration
are considered essential.
A component represents the basic unit of a system.
We find among them clients, servers, data bases, ob-
jects, modules, etc.
A connector is an architectural entity which models
the interactions between components. Components
and connectors are generally accessible only through
interfaces (which we often call ports for the compo-
nent and roles for the connector).
A configuration or architecture is an arrangement,
a topology, or a graph of components and connectors
which describes how the components are connected
to each others.
Based on the ability of an ADL to describe the evo-
lution of an architecture at run-time, we distinguish
Figure 1: Configuration of an application
two classes of ADLs: configuration languages and
description languages. Contrary to description lan-
guages, configuration languages permit to specify op-
erations like adding a new component/connector or
removing a component/connector.
3 CASE STUDY:
COLLABORATIVE
AUTHORING
We consider in this paper an applicative example: the
collaborative authoring (Pinheiro et al., 2002). It is
a cooperative application enabling a set of authors to
cooperate in order to draft a common document.
Figure 2: The collaborative authoring configuration in ADL
This illustration allows, to compare the similari-
ties and the differences between these ADLs. This
application illustrates an example of a system which
owns a dynamic architecture. During execution a new
component: reader or writer may be connected to the
application without disturbing its functioning. This
modification in the architecture is controlled by the
rules stating that two writers must never access simul-
taneously to the same fragment. Adding a new writer
component it is induced by an external (user) event. In
addition, we may consider internal events which may
also change the architecture at the run-time. For ex-
ample, a writer component may be disconnected from
the application when the time allocated for him is ex-
pired.
4 CONFIGURATION
LANGUAGES
The configuration languages (Accord, 2002), (Riveill
and Senart, 2002) provide a model of notation to spec-
ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
190
ify the application configuration. In these languages,
a component is considered as an instantiate entity.
Several instances of the component can be created and
can coexist during the execution. Configuration lan-
guages allow to describe an application with the aim
of its deployment and of its execution. They belong
to a family of languages which are accompanied with
tools of modelling, parsers and code generators.
We present in the following sections the main prop-
erties of the languages Darwin, ArchJava and Olan
and measure for each one its ability of describing the
dynamic of architectures and the behavioural of com-
ponents.
4.1 The Darwin language
Darwin (Dulay et al., 1993) uses the three basic con-
cepts i.e. the component, the connector and the con-
figuration but only the component is explicitly ex-
pressed. It allows a partial specification of the dy-
namic of architecture in terms of component creation
during the execution of an application.
Darwin provides two mechanisms to specify the
component instantiation: lazy and dynamic instanti-
ation. Thanks to these two mechanisms, the archi-
tecture of an application is not considered any more
as a set of components fixed at the design phase. It is,
then, possible to specify when and where the dynamic
creation of software components can take place.
Lazy instantiation: Lazy instantiation (Accord,
2002) enables to declare components which will not
be immediately instantiated. These components will
be indeed created when the service which they pro-
vide is requested. This type of mechanism enables
to instantiate only one component by interconnec-
tion and allows describing structures whose number
of components can be determined only dynamically.
component Edition {
inst
writer : Writer;
fragment : dyn Fragment;
bind
writer.reserve -- fragment.protect;
}
Figure 3: Lazy instantiation in Darwin
Contrary to traditional components which will be
created at the application installation, the component
fragment: dyn Fragment is not instantiated as
long as the user does not reach the service provides
by the component. In this example, the component
fragment will be instantiated and protected with the
first call of the fragment.protect. Lazy instan-
tiation enables to instantiate only one component by
interconnection clause (Barais, 2002) and this cannot
always be used. So, Darwin proposes the dynamic
instantiation concept.
Dynamic instantiation: Unlike lazy instantiation,
multiple instances can be dynamically created from
only one interconnection clause. Dynamic instantia-
tion (Riveill and Senart, 2002) allows to specify the
connection for a component type rather than for an
instance of this type. So, it enables multiple instan-
tiations through only one clause of interconnection.
The declaration of this instantiation dyn Fragment
is achieved in the interconnection clause bind (Fig-
ure 4).
component Edition {
inst
writer : Writer;
bind
writer.reserve -- dyn Fragment ;
writer.update -- Fragment.protect;
}
Figure 4: Dynamic instantiation in Darwin
The difference between this example and the pre-
vious one is that the component Fragment is instanti-
ated writer.reserve -- dyn Fragment; in the
interconnection clause bind. So, the user can create
several instances of the component Fragment in only
one interconnection clause.
To conclude, we can deduce that the description of
the dynamic of an architecture using Darwin is lim-
ited. Indeed, Darwin does not allow expressing differ-
ent reconfiguration actions usually desired by the ap-
plication administrator. In addition, it is not possible,
for example, to remove nor to designate dynamically
created components. Thus, a primitive component
cannot communicate with dynamically created com-
ponents (Barais, 2002). Furthermore, Darwin does
not offer the basis for analysing application behav-
iour, because its model does not enable to describe
the features of a component and of its services (Allen,
1997). Indeed, a component is considered as a black
box.
4.2 The ArchJava language
ArchJava (Aldrich et al., 2001) aims to improve the
programs comprehension, to guarantee and to allow a
better evolution of the application architecture.
In order to create and connect dynamically some
components, ArchJava offers functions to create, de-
stroy and connect new components. The dynamic
component creation is done using the operator new.
A component can be connected using the operator
connect with a port instance. The component de-
struction is not managed explicitly. When a compo-
nent is neither referred nor connected to other com-
ponents, its memory will be released by the garbage
EVALUATION AND COMPARISON OF ADL BASED APPROACHES FOR THE DESCRIPTION OF DYNAMIC OF
SOFTWARE ARCHITECTURES
191
collector. It may be necessary, in some applications,
to connect several components to the same port with-
out knowing their number in advance. ArchJava, then,
enables to define a port interface. A new port instance
will then be created with each connection (Barais,
2002).
We return to our example and we suppose that a
writer can reserve several fragments at the same time.
Figure 5: Fragment reservation in ArchJava
At the architectural level (Figure 5), when a request
arrives (for example a request for fragment reserva-
tion), the component writer asks for a new connec-
tion. The component Edition creates, then, a new
component Fragment using the operator new and con-
nects it to the component writer thanks to the opera-
tor connect. Then, the writer communicates with the
component Fragment via its port reserve.
According to our experimentation with ArchJava
we can conclude that this language is an easy ADL
thanks to its syntax similar to java. It allows to
describe the dynamic of architectures in terms of
creation, connection and destruction of components.
However, this description is very limited since exter-
nal (user) events are not taken into account. More-
over, ArchJava does not allow to specify the behav-
iour of components. Like in Darwin, in ArchJava a
component is considered as a black box.
4.3 The Olan language
Olan (Bellissard et al., 1996) aims principally to pro-
vide a complete environment for construction, con-
figuration and deployment of distributed applications
built on the assembly of heterogeneous components.
Basically, Olan is a formalism which does not sup-
port the update of architectures at runtime. This lan-
guage has been augmented with an OCL (Object Con-
straint Language) enabling then to describe opera-
tions changing the architecture. The obtained lan-
guage is based on a set of rules of the form (Event,
Condition, Action). Like Darwin, Olan offers lazy and
dynamic instantiation. However, Olan provides a new
schema of dynamic instantiation called collection.
Collection: The collection concept (Accord, 2002;
Riveill and Senart, 2002) has been introduced to fa-
cilitate the use of multiple components with the same
type. When it is created, a collection does not con-
tain any component. A collection has two operators
new and delete allowing to create or destroy dynam-
ically a component instance.
The clause fragment = Collection [0..n]
of Fragment; defines a collection of fragments in a
document. The component designation can take two
forms. First, the collection members can be dynami-
cally identified through some properties related to its
attributes. In this case, components are managed im-
plicitly. It is the designation mode by association. The
second designation form is rather explicit. It consid-
ers a component as a member of the collection and it
is designated with its index in the collection.
Writer.reserve(request,idf) => fragment.update(request)
where fragment.idf = idf using authority;
Figure 6: Component designation from a collection
This example considers designation by association.
In the clause below, Writer indicates a fragment (iden-
tified by its idf) from a collection in order to modify
it. It cannot modify the fragment only if it is autho-
rized. Thus, the main advantage is to create sets of
components having the same functions but with vari-
able number of components.
Accordingly, we can say that Olan architectural
model is similar to the Darwin’s one extended with
the concept of collection. Thanks to this concept,
Olan allows to express the dynamic of architectures
with more precision than Darwin. Indeed, Olan en-
ables to describe a component by separating interface
description from its implementation and its configura-
tion. Thus, when one of the parts evolves, the others
are not modified. In addition, Olan offers a kind of
adaptation form, since it is possible to modify the sys-
tem in reaction to some events. However, events taken
into account in the model are not external. The mod-
ification types allowed are too limited. Like Darwin,
Olan does not offer the basis for analysing component
behaviours.
5 DESCRIPTION LANGUAGES
Description languages (Accord, 2002) allow to de-
scribe the application evolution and to specify modifi-
cations which are to be carried out on the initial archi-
tecture. They offer the possibility to validate architec-
ture by checking specific constraints or by simulation.
They belong to language families which are accompa-
nied with tools for modelling, code generation, code
execution or simulation.
We present in the following sections the mecha-
nisms offered by the languages Rapide, Wright and
Acme to describe the dynamic of architectures and
behaviour of components.
ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
192
5.1 The Rapide language
Rapide, (Rapide, 1997) aims to check validity of soft-
ware architectures by simulation. Rapide provides
tools for dynamically updating the software architec-
ture of an application. We demonstrate this, on the
collaborative authoring application:
We suppose that the interface types of Writer, Con-
trolCentre, and Msg are already defined. The inter-
face for Writer, for example, defines all functions al-
lowing to create, reserve, and modify a Fragment.
The interface for EditionCenter declares two actions
called in and out to allow an EditionCenter to accept
or reject Writer. The ArchEdition architecture (an ar-
chitecture generator) defines the communications be-
tween the interfaces of Writers and ControlCenter us-
ing connection rules. For example, the first connec-
tion links a component Writer whenever an accepted
event with that Writer is received.
Example Edition
type Writer is ... type Fragment is ... type Msg is ...
W : Writer; ?F : Fragment; ?d : Data;
type EditionCenter is interface
action in Accept(X: Writer);
out Hnadoff(X: Writer);
behaviour
Start Send (d);
(?d in Data) Replay (?d) where Authority update(?d);
end EditionCenter;
architecture ArchEdition return EditionCenter is
SFO: ControlCenter; ...
connections
Accept(?W) link(?W);
?W.Update(?d) where ?W.Authority(SFO) k > SFO.Receive(?d);
Handoff(?W) unlink(?W);
constraint
observe from W.Send, SFO.Receive
match ((?d in data)
(W.Send(?d) (SFO.Receive(?d) or Empty)))(
*);
End; end ArchEdition;
Figure 7: Dynamic architecture in Rapide
The rule states that if a Writer (a match for ?W)
sends a request containing a message ?d, then ?W is
bound to the Writer and ?d to the message. The con-
nection is made only when the Writer is accepted. If
the ArchEdition refuses a Writer, then it unlinks from
it. From now, no communications from the Writer
are received. This is a dynamic interface connec-
tion architecture. It defines communication between
a variable numbers of Writers components. The sec-
ond connection rule defines a conditional broadcast
between all Writers and the ControlCenter.
Accordingly, Rapide allows to describe the dy-
namic of architectures in terms of components cre-
ation, dynamic nomination of participants and essen-
tially a fan-in connection. It describes the behaviour
of components in the behaviour clause. However, this
description expresses only communicating events and
does not consider reconfiguration operations.
5.2 The Wright language
Wright (Allen, 1997) is focused on the architecture
specification. It is mainly interested in rigourous rea-
soning about protocols. For this purpose it uses the
CSP language.
The first version of this language (Allen, 1997) al-
lows the description of static architecture only. en-
abled to describe only static architectures. In 1998,
Wright was extended to support the dynamic archi-
tectures description: configuration program. To il-
lustrate this, we return to our example and we con-
sider a configuration in which a server is composed
of two components managing the access in reading
and writing documents. The system is composed of
a client and a server (Primary: FlakyServer) inter-
connected via a connector. This server can frequently
run out. The idea consists in enabling the system to
change configuration by replacing the primary server
with (Secondary: SlowServer) until the latter is ready
to function again.
Configurator Edition
new.U : User
new.Primary : FlakyServer
new.Secondary : SlowServer
new.L : FaultTolerantLink
attach.U.p.to.L.u
attach.Primary.p.to.L.s WaitForDown
where
WaitForDown = Primary.control.serverDown detach.Primary.p.from.L.s
attach.Secondary.p.to.L.s WaitForUP
§
WaitForUp = Primary.control.serverUp detach.Secondary.p.from.L.s
attach.Primary.p.to.L.s WaitForDown
§
Figure 8: Dynamic Wright specification
In this configuration program, the initial sequence
of actions (new and attach) builds the initial con-
figuration. Then WaitForDown describes two situa-
tions: the system can run and successfully terminate
(§) or a fault can occur. If the primary server goes
down, the secondary server is in state on and the link
connector is reconfigurable, the primary server is de-
tached and is replaced by the secondary server. The
new configuration then resumes its execution until it
terminates or the primary server comes up. Wait-
ForUp specifies when the secondary server is off and
the connector is reconfigured. In this case, the sec-
ondary server is detached and is replaced with the pri-
mary server.
In order to dynamically manage the changes of an
architecture, Wright uses the configuration program.
This makes the correspondence between the submit-
ted events and the reconfigurations to be performed
(Riveill and Senart, 2002). Hence, Wright allows to
specify, in an abstract and formal way, the dynamic
aspect: creation, connection, and remove of compo-
nents. However, in Wright, the specification of recon-
EVALUATION AND COMPARISON OF ADL BASED APPROACHES FOR THE DESCRIPTION OF DYNAMIC OF
SOFTWARE ARCHITECTURES
193
figurations is limited. Indeed, Wright allows to spec-
ify only configurations which are known in advance.
5.3 The Acme language
Acme (Garlan et al., 1997) is a simple, generic soft-
ware architecture description language, provides in
part, a common interchange format between other
ADLs. The concepts offered by Acme (component,
connector, system, etc.) are sufficient to describe the
architecture structure but are insufficient to specify
precise information such as the dynamic of architec-
ture or the behaviour of components.
We consider again the collaborative editing ex-
ample. Here, we consider two components (Writer
and Fragment) bound by Rpc connector. The
Writer sends its requests via the reserve port and
the Fragment receives its requests via the protect
port. The Rpc connector has two roles callee
and caller. For to describe the dynamic of ar-
chitecture, Acme allows the translation of a com-
pletely static language toward a more dynamic lan-
guage such as Darwin and Rapide. In this exam-
ple (Figure 9), some properties were added. For
example, the property Aesop-style:style-id =
client-Server; shows that the writer in Acme is
defined as a style in Aesop (Aesop is an ADL).
System Edition = {
Component writer = {
Port reserve;
Properties {
Aesop-style : style-id = client-Server;
source-code : external = "writer.c";
}} ... }}
Connector rpc = {
Roles {caller, callee}
Properties { ... }}
Attachments {
writer.reserve to rpc.caller ;
fragment.protect to rpc.callee
}}
Figure 9: Architecture with properties consideration
To summarize, we can say that Acme does not pro-
pose any new concept for describing the dynamic as-
pect. Acme allows to describe only the static aspect.
In addition, the concepts offered by Acme are insuffi-
cient to specify the behaviour of components.
6 EVALUATION RESULTS
ADLs can be divided into two classes. The configura-
tion languages and the description languages. Every
ADL has a particularity. Darwin and Olan emphasize
the dynamic aspect whereas Wright and Rapide em-
phasize the behavioural aspect.
With regard to the configuration languages, we can
say that: Darwin’s lazy instantiation does not respond
to all of dynamic architecture needs. Whereas the dy-
namic instantiation has a major drawback: it is im-
possible to call dynamically created instances. The
collection concept offered by Olan allows to add and
delete components during execution. ArchJava en-
ables component creation, connection and destruction
but it does not allow to specify the behaviour of com-
ponents.
With regard to the description languages, we can
mention that: Rapide allows to describe the behav-
iour of components. However, this description ex-
presses only communicating events and does not con-
sider reconfiguration operations. In Wright, the archi-
tectural changes are managed inside the configuration
program. But these changes must be known in ad-
vance.
Finally, we can say that the dynamic aspect is not
well supported by ADLs. In spite of the great num-
ber of interesting proposals, these solutions are not
enough thorough. The majority of ADLs, are able to
manage only systems having a finite number of con-
figurations and known in advance. Then, it is impos-
sible to arbitrarily execute reconfiguration operations
during run-time. Concerning the behavioural aspect,
we noted that even if the behaviour is described, this
emphasizes only the communication between compo-
nents and does not consider the events causing recon-
figurations.
7 CONCLUSION
In this paper, we have presented an overview of differ-
ent architecture description languages and their prop-
erties. We classified them according to configuration
and description languages, and we focused in partic-
ular on their support for specifying the dynamic of
architectures and the behaviour of components. We
have noted that the majority of ADLs are concentrated
on the static description of architectures but the dy-
namic of architecture and the behaviour of component
are not enough expressed. Generally, the choice of the
appropriate ADL is difficult and crucial. Such a lan-
guage must at the same time be intuitive and formal.
Many approaches based on the formal specifications
have also been used to describe the distributed sys-
tem behaviours. However, although they facilitate the
description of communications, they do not allow to
describe the components and their attributes.
UML2.0 is a promising notation to describe the
architecture of application. Moreover, it is a stan-
dard which includes various diagrams and notations
mastered through the majority of software architects.
Rather than building a new ADL, an interesting re-
ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
194
search project consists to develop a generic environ-
ment around UML2.0 allowing to specify and design
a complete system. It allows to describe the static and
the dynamic aspect of architecture and the behaviour
of components.
REFERENCES
Accord (2002). Assemblage de composants par contrats en
environnement ouvert et r
´
eparti, etat de l’art sur les
langages de description d’architecture (adls). Projet
ACCORD, Technical Report Livrable 1.1-2, RNTL,
France.
Aldrich, J., Chambers, C., and Notkin, D. (2001). Archi-
tectural reasoning in archjava. In Proceedings of the
OOPSLA ’01 Workshop on Specification and Verifica-
tion of Component-Based Systems, pages 33–48, Sin-
gapore.
Allen, R. (1997). A Formal Approach to Software Archi-
tecture. PhD thesis, School of Computer Science,
Carnegie Mellon University.
Allen, R., Douence, R., and Garlan, D. (1998). Speci-
fying and analysing dynamic software architectures.
Journal of Fundamental Approaches to Software En-
gineering, 11(6):21–37.
Barais, O. (2002). Approche statique, dynamique et
globale de l’architecture d’applications r
´
eparties.
Master report, Ecole Mine de Douai, Laboratoire
d’Informatique fondamentale de LILLe.
Bellissard, L., Atallah, S. B., Boyer, F., and Riveill, M.
(1996). Component-based programming and applica-
tion management with olan. In Proceedings of Work-
shop on Distributed Computing Systems, pages 579–
595.
Dulay, J., Kramer, N., and Magee, J. (1993). Structuring
parallel and distributed programs. IEEE Software En-
gineering Journal, 8(2):73–82.
Garlan, D., Monroe, R., and Wile, D. (1997). Acme: An
architecture description interchange language. In Pro-
ceedings of CASCON’97, pages 169–183.
Medvidovic, N. and Taylor, R. (2000). A classification and
comparison framework for software architecture de-
scription languages. IEEE Transactions on Software
Engineering, 26(1):70–93.
Rapide (1997). Guide to the rapide 1.0 language reference
manuals. Technical report, Group Computer Systems
Lab Stanford University.
Riveill, M. and Senart, A. (2002). Aspects dynamiques
des langages de description d’architecture logicielle.
L’Objet RTSI - L’objet. Coop
´
eration et syst
`
emes
`
a ob-
jets, 8(3).
EVALUATION AND COMPARISON OF ADL BASED APPROACHES FOR THE DESCRIPTION OF DYNAMIC OF
SOFTWARE ARCHITECTURES
195