Modeling the Engineering Viewpoint of ODP systems with MODERN
Hai-Quan NGUYEN

Université des Sciences et Technologies de Lille (USTL), 59655-Villeneuve d'Ascq Cedex,France
E-mail: Quan.NguyenHai@lifl.fr.

Abstract
Difficulties in software architecture design come fromthe lack of analysis tools to assist the architect in detecting
system errors. Current approaches in architecture design
such as Architectural Description Languages (ADLs) areoften limited by the way they tackle quality issues separately
and only in one viewpoint. None of them addresses analysis
and verification of distributed architecture with a global
approach from functional design (i.e. liveliness or safety
properties) to its deployment in distributed environments(i.e. the environment provides containers and servers tohost functional components), and their non-functional
qualities (i.e. performance, reliability).
This paper presents our new language for Modeling theEngineering Viewpoint of ODP systems (MODERN)
supporting the integrated analysis for different quality
properties of RM-ODP systems. Those qualities range fromstructural and behavioral properties (such as the assembly
correctness and the liveness properties) to the quality ofservices properties (ex. performance).

1. INTRODUCTION
RM-ODP (Reference Model for Open Distributed
Processing) [1,2] is an International Organization forStandardization (ISO) ‘s standard for modeling distributed
systems based on separation of concerns of stakeholders.
Although RM-ODP provides rich concepts for modeling
distributed systems, it does not provide tools and methods
for analysis and verification of software quality properties.
In this reference model, ODP provides five viewpoints
where each one represents one concern. The Enterprise
viewpoint describes client needs and organization policy,
the Information viewpoint describes system data, theComputational viewpoint describes business functionality,
the Engineering viewpoint describes mechanism supporting
distributed communication and Technology viewpoint
describes technology utilization. However, although thisreference model provides rich concepts for modeling
distributed systems in accordance with the different
viewpoints, it does not provide languages and tools formodeling and analyzing software qualities.

This work presents our new language MODERN to
specify the technical architecture of ODP system, which is
specified in the Engineering viewpoint. Actually, theEngineering viewpoint is one of the most important
viewpoints in ODP system. In this viewpoint, concerns suchas the distribution, the technical concern should be specified
in this level. Quality assurance is important in this phrase,
which helps to detect conception faults before theimplementation choices.
The MODERN language is expected to provide anumber of advantages by supporting the integrated analysis.
Firstly, analysis tools can be integrated in the same analysis
environment. Secondly, the specifications of different
analysis concerns are consistent between them. Third, one
unique language is used to address the different analysis
concerns.
The paper will be organised as following: in the Section
2, we introduce the motivation of our work. After, we
present the MODERN language, which support the
integrated analysis capacity in the Section 3. Later, we will
illustrate our approach with case study and present quickly
our prototype in the Section 4. Afterward, we will compare
our work to related work in the architectural modeling.
Finally, we conclude and give some perspectives of ourwork.

2. Motivation & Problems
2.1 Why a
viewpoint?

newlanguageforEngineering

The engineering viewpoint focuses on mechanisms andfunctions required to support distributed interactions
between components in the system. This viewpoint isimportant because it addresses the problems of component
interactions: how the infrastructure and communication
mechanisms support distributed interaction.
In RM-ODP reference model, no languages or tools aredefined. The architects are free to choose their own
methods. In fact, we can use the languages like UML[9], orthe architectural description languages (ADLs)[8] to specify
the Engineering viewpoint. However, as we will see in thefollowing, those languages fail to model the different
aspects of the ODP’s Engineering viewpoint. Moreover,they do not provide sufficient capacity of analysis for the
distributed system architecture.
The first choice is highly used in the industry whereas
the second choice is studied much in the research field. The
UML language, in their latest version 2.0, provides graphic
notations for modeling systems. We can access to its
dynamic diagrams such as interaction diagram or state chart
diagram. However, analysis tools are not supported for
UML diagrams. Moreover, concerns such as quality ofservice assurance are not considered when using thislanguage.
The architectural description languages, in other hand,
can provide effective analysis tool. Wright provides
analysis tools such as type checking analysis [10], assembly
correctness and behavioral verification. However, it does
not address the quality of service analysis. Rapide provides
simulation capacity but does not provide also this kind ofanalysis. AADL (The SAE Avionics Architecture
Description Language) [31] is a powerful language thatprovides also a range of the quality analysis such as thedependability properties such as performance or security.
However, no means is provided to take into account the new
quality property analysis.

2.2 Why do we need integrated analysis ?
We define integrated analysis is the capacity ofsatisfying a well range of quality properties of the systemarchitecture. It is composed of four analysis aspects: thestructural aspect analysis, the behavior aspect analysis, thedeployment aspect analysis and the quality of service aspect
analysis of the component architecture.
The integrated analysis is required when we specify theEngineering viewpoint because it will help us to identify
globally the different kinds of potential conception errors of
the system. When dealing with distributed system, thearchitects interest not only in the functionality of the systembut also to the mechanism of deployment of the system inthe distributed environment.
The integrated analysis can bring many advantages forthe architects. The integrated analysis approach has thefollowing qualities:• Integrated: number of quality properties can beanalyzed in the same and unique environment.
• Consistence: specification of the architecture isconsistence in accordance to Engineering concepts.
Different concepts in the language are verified toassure the consistence between them.
• Unified: One unique language is used to support
different analysis aspect of the architecture. The

architects reduce their effort in learning different
notions when dealing with analysis problems.

2.3 The integrated analysis problems
In our research, we have identified the following analysis
problems needed take into account when specifying theEngineering viewpoint:• Concerning the structural aspect: in this aspect, oneof the concerns of the architect is how to assure tointeraction between components?
• Concerning the behavioral aspect: we interest inverifying the temporal properties of the architecture.
The assurance of those properties validates thefunctionality of the architecture.
• Concerning the deployment aspect: when deploying
the component to the distributed environment, thedifficult is to assure the execution of the components
in the run-time.
• Concerning the quality of service aspect: the mostchallenge problem is the integration of new qualityof service tool to analyze the technical architecture.
The approach is required to be open with new kindof analysis.
MODERN, our modeling language for ODP’s
Engineering viewpoint, addresses those problems above byintroducing not only the concepts supporting thespecification of the distributed concerns, but also provide
powerful integrated analysis concepts.

3. MODERN: the language for intergrated
analysis of the engineering viewpoint
3.1 Overview of the language
The language provides basic concepts for specifying theEngineering viewpoint. Moreover, it provides extraconcepts that support the integrated analysis criterion.
The basic concept of our MODERN language is thecomponent (class Component Type). It has the hierarchy
structure and is composed of ports (class Port), which
represent functionality of the component. In the distributed
environment (class Distributed Environment), thecomponent is deployed to an encapsulation unit called
Capsule (class Capsule), which has component’s life cycle
management mechanism thanks to its manager (class
Capsule Manager).

+C ontains

C hannel

Distributed environment

1..n+C ontains
1..n
Node

QoSProperty
C onnects to

1+Specified by
1..n
QoSValue

1

1

+Has

QoSDimension

Policy +Has

+Belongs To

1+Valued of

0..n
0..n

C apsule Manager

1+Managed by

1+Contained in
1+Deployed 1to
+Has
0..1

1..n
+C ontains

+Has

0..n

0..n

C omponent Type+Has

C orresponds toAssembly

1..n

0..n
+Has

+Conforms to
0..1

0..n
Assembly C ontract

Behaviour

Link

Operation Signature
1+C onditions+Used byAbstract Capsule+Manages1

0..nAttribute+C ontaines

C apsule

0..n

1

1

1
+C ontains
1..n
Port

C ontains

AssemblyLink

C orresponds toC ompositionLink
1

LinkBehaviour

PortBehaviour

1

0..1
composition

composition

RequiredCompositionLink

ProvidedC ompositionLink

0..nProvided Port
0..n
1..n

0..1

1..n

1..n

Required Port
1..n

0..n

Dependence

1..n

0..n

Synchronisation
1..n

1..n

Figure 1: the MODERN meta-model
Besides the basics concepts, the MODERN
language provides others concepts in order to archive
the integrated analysis. Firstly, we use assembly
contract notion helping semantics assembly. Secondly,
we provide component’s life cycle management toaddress the deployment analysis. Last but not least, the
QoS property is used to integrate new non-functional
quality which is the object for the quality analysis.

3.2 Basic concepts
3.2.1 Component
Our architecture is specified with components. The
concept of component used in this architecture is basedon the following definition from Szyperski[29]: “Asoftware component is a unit of composition with
contractually specified interfaces and explicit context
dependencies only. A software component can be
deployed independently and is subject to compositionby third parties."
The elements needed to describe our component
model and the relations between them are taken into
account in the MODERN’s meta-model represented in
Figure 1.
Our approach handles component as component
type. Components may have attributes that represent

their state. Moreover, they are described by provided
and required interfaces. A component communicateswith other components through its interfaces. In ourmodel, an interface is represented by a port that is
associated with a single service. A service is specified
by its signature, which is composed of a name and of
ingoing and outgoing parameters.
3.2.2 Components Assembly
The model does not include explicit connectors
between components. Nonetheless, if an architectneeds one, he can model it in a component.
Communications between components or more
precisely between their ports are specified by anassembly link. The semantics of a link corresponds to asynchronous call from the required port to theprovided port. The choice regarding a port structure
involves that a required port can only be bound to a
provided port whereas a provided port can be bound toseveral required ports.
3.2.3 Components Composition
In order to build a complex architecture, we use
composite components. They are differentiated fromprimitive components because they containsubcomponents which may be primitive components
and also composite components hence a recursive
definition of a component. The ports of a composite
component are called delegated ports. Indeed a call toa provided port of a composite component isforwarded to a provided port of one of its
subcomponents. Moreover, a call from a required portof a composite component results from the forwardingof a call from a required port from one of its
subcomponents.
3.2.4 Component Distribution
In the ODP’s Engineering viewpoint, the mostimportant concern is the mechanisms supporting the
distribution. Our language, as the result, uses thefollowing concepts to model the deployment of the
distributed architecture.
CapsuleIn our model, we consider component type entity of
deployment. When component types are deployed, we
use the capsule concept to encapsulate thosecomponents. We manage those components with
deployment policy where we specify the managementof life cycle’s component. We apply the same politic
for component in the same capsule.
Node
A node is one of the most important concepts in our
meta-model. It is an abstract concept that represents anaddressable machine in the reality. The node describes
the place where the component types are deployedfollowing the architect choice. The nodes interact
between them via communication network. As we
consider the node is a special case of the capsule, acapsule manager manages it. Moreover, it can containother capsules.
ChannelA
communication
channelrepresentsacommunication way between two nodes in deployment
environment. Between two nodes, there is only one
channel.
This concept is derived from ODP specification.
We consider specify the links but not show how tomake possible the binding like in ODP’s specification.
As opposed to channel concept in ODP, ours does nottake into account the binding because thecommunication and interaction problem have been
considered in assembly model.

The deployment environment composes of nodes
and channels. It is where the application is deployed
and execute. Normally, this environment is distributed.

3.3 MODERN’s Integrated Analysis concepts
In our approach, we determine three categories of
the integrated analysis. The first category of integrated
analysis concept contains the functionality contract
concept supporting structural and behavioral analysis.
The second category contains component management
policy supporting deployment analysis. The last
category contains concepts for modeling the quality ofservice properties and means to integrate them to thecomponents.
3.3.1 Functionality Contracts
The conditions of validity of a component assembly
are improved by associating an assembly contract
composed of a pre-condition and a post-condition toeach port. These conditions focus on the attributes of
the component and on the parameters of the signature.
Thus in addition to the verification of the signaturecompatibility between two linked ports, there is ananalysis that checks respectively the compatibility ofthe pre-condition and pos-condition of a port with theprecondition and post-condition of the linked port.
Furthermore, behavioral contracts are added to thecomponents. These contracts describe the expectedbehavior of a component and are used to generate thebehavior of the components assembly. An appropriate
tool has been developed to check some properties on it.
3.3.2 Component Management Policy
Capsule Manager
The components deployed in the distributed
environment are controlled by the capsule manager. In
fact, the policy which manages the component’s life
cycle can modify the level of quality of the application.
For example, the passivation of the instances ofcomponent during it does not have there a request ofthese customers can make the resources available forother components.
Another example is theinstantiation of new instance of component or thereactivation of the existing instances for requests theseof the customers.
Then we find that it is necessary to specify the
management of life cycle of the components deployedin the environment of reception. This specification
enables us to check the policy of management ofcomponents which influences the level of quality of
the application.

Deployment environment
Component’s Life Cycle Management Policy

For a component type deployed in a capsule, we
specify following information for managing thecomponent’s life cycle:• the maximum number of instances of thecomponent type which the capsule manager can
instantiate.
• the maximum number of simultaneous requests
treated by the component.
• the policy specification of the component’s life
cycle. This specification must make it possible
to specify activation, passivation, and thetermination of the cycle of life of the instancesof component.

physics. It manages the exchange of values between
the codes. The assembly model is describedgraphically in the figure 4. Two scientific code
components Tree and Support communicate between
them via the coupler. We need also to analyze globallythe qualities properties of the system.
CouplerPlusAdaptaters
Coupler
GestApproximation

Tree

4. Case study
In the following section, we illustrate how to use
the MODERN language to model technical concerns inEngineering viewpoint. We will show how integrated
analysis is supported by our MODERN language. The
language supports integrated analysis. Those analyses
are composed of the structural aspect analysis, thebehavioral aspect analysis, the deployment and thequality of service analysis.
The most significant example verified by ourverification is an existing application from theindustrial case [30]. The following figure gives an ideaof the complexity of the architecture. Required andprovided ports are symbolized respectively by - and +.
The example represents the use of a generic coupler ofscientific code[30]. This coupler is used to study theinteractions between codes of different domains in

GestCorresp

Coordinator
GestVariables3.3.3 Quality of Service Property
We define the concepts for analysis the quality
properties. Three concepts have been proposed: the
QoSProperty (QoSProperty), the analysis parameters(QoSDimension) and its values (QoSValue) associatedwith component descriptions.
QoS Property
The QoS property represent the quality property
which one want to analyze.
QoS Dimension
In order to analyze a quality property, we need tohave analysis parameters concerned with this property.
For example, to analyze the performance property, weneed to provide the arrival rate and the service rate of
the service center. Other parameters include thenumber of server and the server capacity.
QoS Value
QoSValue represent the value in a given time of the
QoS Dimension. For example, the dimension service
rate has the value of 1000 messages/second.

TreeToSupport

SupportSupportToTree
GestValues

Figure 2: the Coupler application – the assemblyview
The following specification using MODERN
describes partly the component Tree. It has three ports:
two provided port and one required port. In thespecification of the Position port, we describe theassembly contract with the pre and post description. In
the pre condition of the contract, we specify that theposition of x must be superior of 0 and inferior of 100
and the position of y must be in the range of 0 and 100
also.
<Component_Type Component_Name="Tree"><Attribute attribute_name="att_position_x" type="float"/><Attribute attribute_name="att_position_y" type="float"/>…
<Provided_Port port_name="Position"><Signature name="void Position(OUT float position_arbre_x,
OUT float position_arbre_y)"/><Assembly_Contract><Pre
expression="position_x<=100&&position_x>0&&position_y>0&&position_y<=100"/><Post
expression="position_arbre_x==position_x&&position_arbre_y==position_y"/></Assembly_Contract></Provided_Port>……
</Component_Type>

Figure 3: the Position provided port specification
The links between the components are specified in
the figure 4. We show that the Tree component
requires the Force port of the Coupler component for
its execution whereas the Coupler requires the Speedand the Position port.
<Assembly_Link><Required_Port Component_Name="Tree" Port_Name="Force"/><Provided_Port Component_Name="Coupler" Port_Name="Force"/></Assembly_Link><Assembly_Link><Required_Port Component_Name="Coupler" Port_Name="Speed"/><Provided_Port Component_Name="Tree" Port_Name="Speed"/></Assembly_Link><Assembly_Link><Required_Port Component_Name="Coupler" Port_Name="Position"/><Provided_Port Component_Name="Tree" Port_Name="Position"/></Assembly_Link>

Figure 4: the assembly links between thecomponents
The figure 5 shows the graphic representation of theapplication in the distributed environment. The Tree
component is deployed into the node NodeA, theSupport component into the node NodeB and the
Coupler into the node NodeC.
NodeA

Max_Connections=3
Max_Instances=3
Tree
Service_Rate=1000msg/s
Arrival_Rate=200msg/s

Service_Rate=5000msg/s
Arrival_Rate=500msg/s

NodeC
Max_Connections=3
Max_Instances=5

Coupler

Max_Connections=3

NodeB

Service_Rate=1000
Support
Max_Instances=2
Arrival_Rate=200m

Figure 5: the Coupler application - the quality ofservice analysis viewAs we interest in the performance quality analysis,
the following section describes the analysis
information for the performance quality. Using
MODERN, we describe this quality by fourparameters:• The customer service time distribution(Service)• The customer inter-arrival time distribution(Arrival_Rate)• The number of independent component
instances (Max_Instances)• The queue capacity (Max_Connections)
The figure 6 describes the technical architecture
containing three nodes A, B and C. In the node A, thecomponent Tree is specified with the following
performance parameters: the service rate equals to
500msg/second; the arrival rate equals to
100msg/second). The component Support is deployedin the node B with the following performanceparameters: the service rate equals to 1000msg/second;
the arrival rate equals to 200msg/seconde). The
component Coupler is deployed in the C with theservice rate equals to 5000msg/second and the arrival
rate equals to 500msg/seconde).
<Node NodeName= "NodeA"><Capsule CapsuleName= "CapsuleTree"><Contains_Component Component_Name="Tree"><QoSProperty QoSProperty_Name="Performance"><QoSDimension Dimension_Name="Service_Rate" Value="500"/><QoSDimension Dimension_Name="Arrival_Rate" Value="100"/></QoSProperty><Contains_Component/><CapsuleManager Manager_Name="Tree_Manager"><Policy><MaxInstances Component_Name="Tree" Value="3"/><MaxConnections Component_Name="Tree" Value="5"/></Policy></CapsuleManager></Capsule></Node><Node NodeName= "NodeB"><Capsule CapsuleName= "CapsuleSupport"><Contains_Component Component_Name="Support"><QoSProperty QoSProperty_Name="Performance"><QoSDimension Dimension_Name="Service_Rate" Value="1000"/><QoSDimension Dimension_Name="Arrival_Rate" Value="200"/></QoSProperty><Contains_Component/><CapsuleManager Manager_Name="Support_Manager"><Policy><MaxInstances Component_Name="Support" Value="2"/><MaxConnections Component_Name="Support" Value="2"/></Policy></CapsuleManager></Capsule></Node><Node NodeName= "NodeC"><Capsule CapsuleName= "CapsuleCoupler"><Contains_Component Component_Name="Coupler"><QoSProperty QoSProperty_Name="Performance"><QoSDimension Dimension_Name="Service_Rate" Value="5000"/><QoSDimension Dimension_Name="Arrival_Rate" Value="500"/></QoSProperty><Contains_Component/><CapsuleManager Manager_Name="Coupler_Manager"><Policy><MaxInstances Component_Name="Coupler" Value="3"/><MaxConnections Component_Name="Coupler" Value="7"/></Policy></CapsuleManager></Capsule></Node><Channel Channel_Name="ChannelAB"/><Channel Channel_Name="ChannelBC"/><Channel Channel_Name="ChannelAC"/><Distributed_Environement><Connects_To
Node_Name=”NodeA”
Node_Name=”NodeB”
Channel=“ChannelAB”/><Connects_To Node_Name=”NodeB” Node_Name=”NodeC” Channel= “ChannelBC”/><Connects_To Node_Name=”NodeC” Node_Name=”NodeA” Channel= “ChannelCA”/></Distributed_Environement>

Figure 6: Engineering specification
Behavioral analysis
In order to analyze on the behavior of a component
model, we transform the behavioral elements into FSP(Finite State Process)[25] processes. We operate thistranslation first by generating a behavior formed of the
behaviors of the composition and assembly links andthe dependences and then by making a composition of
it with the synchronizations.
The analysis uses a verification tool for concurrent
systems, named LTSA (Labelled Transition System
Analyser) [26], which supports FSP and a LTL (Linear
Temporal Logic) checker to check safety and livenessproperties such as deadlocks or absence ofreachability.
Deployment analysis
The deployment analysis contains two tests: thevalidity of the deployment and the component’s life
cycle management analysis. The first analysis ensuresthat the components, which are assembled on theassembly, can communicate between them after the
deployment process using mechanism provided by theenvironment. The second analysis verifies theexecution correctness of the component in the runtime.
We define this validity a correspondence between
technical architecture to be deployed and the
distributed environment. As we explain above, wemust ensure the correspondence between components
to be deployed and the distributed environment.
Quality of service Analysis

In order to analyze the performance, we transfer thedescription of performance quality to queuing networkmodel. The following section describes the results
obtained from the analysis phase. In fact, the result isobtained by using the MCQueue tool.

5. Related work
In the following section, we discuss approaches inmodeling the architecture of systems and its analysis
methods.

methods are considered difficult to apply in company
environment. They do not provide enough notions andtools to associate with the architecture notion. Besides,
there is a lack of methodology and software tools. To
overcome this drawback, some ADLs language use
formal method as tool for analyzing properties. Wrightuse CSP for analyzing behavioral properties such as
deadlock. Darwin use pi-calculus and later use FSP to
analyze the liveness and safety property.

5.3 Quality of service analysis
5.1 ODP’s related work
There are some efforts to define the language of
specification from the Enterprise viewpoint with the
UML [3]. In this proposal, it describes the concepts inthe viewpoint of Enterprise like the policy, the roles,
the community. In other work [4], OCL is used todescribe the obligations of objects of company.
Romero et al.[5] proposes the use of Maude, a logicallanguage of achievable rewriting (executable rewriting
logic), to specify the Computation viewpoint. The
rewriting logic is the logic of change which can workwith the state and calculations non-determinist. Maude
is used to specify the concepts from the Computational
viewpoint like the object, the interface, the behavior,
the constrained ones of environment.[6] This work
aims at formalizing the Computational viewpoint of byproposing the concept action template and the causality
control.
In spite of the interesting proposals, we find thatthese approaches are limited to the languages for theEnterprise viewpoint of and the Computational
viewpoint. Other viewpoint such as that Engineering
is not treated for this moment.

In [11], Issarny and al, interest in dependability
analysis from architectural viewpoint. Their work isbased on work in ABAS[12] for dependability system.
This work is closed to our problem. However, as there
is no separation between functional and distribution
concern, it is more difficult to determine where thefaults come from. The functional architecture uses theconnector which differentiates from our approach
which considers it is only a specific component.
Moreover, the approach does not provide iterating
steps to construct technical architecture as ours.
Other quality analysis method such as queuing
network for performance analysis [13,14,15,16,17] orblock diagram[18,19] for reliability analysis provide
efficient means to analyze qualities. Those approaches
need to be integrated into architectural level tofacilitate the design and analysis of those nonfunctional qualities.Some efforts have been made in
the field such as the integration of performancetechnique with the ADL [20,21]. However, those
approaches treat only one aspect and only one nonfunctional quality.

6. Conclusion
5.2 Architecture Description Languages
Specifying software architecture requires anarchitectural language to define all static and dynamic
aspects of architecture. These languages define theformalism in terms of component, connector, andconfiguration.
This clear separation between components,
connectors and configuration is a basic concept sharedby all ADLs. However, despite a large popularity
among the research community, no ADLs have yetreached common practice in companies. However,
several ADLs have been introduced like ACME,ArchJava, Aesop, C2, Darwin, Meta-H, Olan, Rapide,
SADL, UniCon, Weaves, Wright, or xADL.
Medvidovic and Taylor [7] provide a generalframework to classify and compare them.
One of the advantages of ADLs is the way the
associate with formal techniques. Traditionally, thoseIn this paper, we present our new language
MODERN to specify the Engineering viewpoint of
RM-ODP systems. The language provides a higheffective manner to satisfy the quality properties of
distributed software architecture.
The language has a number of original points:• It provides rich concepts for specifying
Engineering viewpoints of distributed system.
Those concepts, which conform to RM-ODP
standard, help to model the different concerns
such as the functionality and the deployment of
the system.
• It supports the global approach for analyzing
quality properties. Those qualities contain thefunctionality
properties(structural
andbehavioral
properties
ofcomponents
assembly), the deployment correctness and thequality of service property.

•

It is provided with a modeling and analyses
environment. Number of properties can bevalidated thanks to our integrated environment.

In our further work, we are studying a new
methodology for automatic transformation from theComputational viewpoint. We are working on the newtransformation language that uses the architectural
figure concept [22, 23, 24] to generate the Engineering
viewpoint
fromacomputational
viewpoint
specification.
ACKNOWLEDGEMENTS
This research has been originally supported byElectricité de France. The author thank to Professor
Laurence Duchien of LIFL, Mr Philippe Bedu, Mr
Jean Perrin of EDF, Professor. Duong Vu of
Eurocontrol and Professor. Thuc Nguyen Dinh of
HCM university for the previous discussions and thecomments.
REFERENCES[1]

ISO/IEC. Open Distributed Processing Reference Model - parts
1,2,3,4, 1995. ISO 10746-1,2,3,4 or ITU-T X.901,2,3,4.
[2] J-R. Putman, Architecting with RM-ODP, Prentice-Hal, 2001.
[3] X. Blanc, M.-P. Gervais, R. Le-Delliou, Using the UML
Language to Express the ODP Enterprise Concepts, LIP6
1999/024: Technical Research, LIP6, 1999.
[4] J.Putman, Model for Fault Tolerance and Policy from RM-ODP
Expressed in UML/OCL, Third IEEE International Symposiumon Object-Oriented Real-Time Distributed Computing, 2000.
[5] R.Romero, A.Vallecillo, Formalizing ODP Behavioural
Viewpoint Specification in Maude, EDOC, 2004.
[6] R.Romero, A.Vallecillo, Action Templates and Causalities in
the ODP Behavioural Viewpoint, Workshop on ODP forEnterprise Computing (WODPEC 2004), 2004.
[7] C. J. Kaufman, Rocky Mountain Research Lab., Boulder, CO,private communication, May 1995.
[8] N.Medvidovic, R.N.Taylor, A Classification and Comparison
Framework for Software Architecture Description Languages,
IEEE Transactions on Software Engineering, January 2000.
[9] [OMG/UML] OMG, OMG Unified Modeling Language
Specification,version2.0,
http://www.omg.org/cgibin/doc?ptc/2004-10-02 , 2004.
[10] R. Allen, A Formal Approach to Software Architecture, PhD
thesis, School of Computer Science Carnegie Mellon
University,Pittsburgh, Mai 1997.
[11] V.Issarny, C.Kloukinas, and A. Zarras, Systematic aid fordeveloping middleware Architectures, Communication of
ACM, Vol 45, Num 6, June 2002.
[12] M. H. Klein, R. Kazman, L. Bass, J. Carriere, M. Barbacci, H.
Lipson, Attribute-based architecture styles, Proceedings of theFirst Working IFIP Conference on Software Architecture(WICSA1), 1999, 225-243.
[13] K.S. Trivedi, Probability and statistics with reliability,
queueuing, and computer science applications, John Wiley &Sons, 2001.
[14] H.G. Perros, Queuing networks with blocking, Oxford
University Press, 1994.
[15] K. Kant, Introduction to computer system performance
evaluation, McGrawHill, 1992.
[16] L. Kleinrock, Queuing systems, Wiley, 1975.
[17] S.S. Lavenberg, Computer performance modelling handbook,
Academic Press, 1983.
[18] G. Myers, Software reliability - principles and practices, John
Wiley and Sons, 1976.
[19] NASA, Reliability block diagrams and reliability modelling,
Technical report, NASA Glenn Research Center, May 1995.
[20] H.Garavel,H.Hermanns, On combining functional verificaitionand performance evaluation using CADP, INRIA researchrapport, 2002.
[21] S.Balsamo,M.Bernardo,M. Simeoni, Performance evaluation at
the software architecture level, SFM (School on Formal
Methods), LNCS 2804, 2003.
[22] H.Q Nguyen, P.Bedu, L.Duchien, J.Perrin, H.M.Tran,
Architectural Figure – a Reuse Pattern for Analysis andTransformation of ODP Based-Systems, IEEE International
Conference on Information Reuse and Integration (IEEE IRI2005), Las Vegas, Nevada, USA.
[23] H.M.Tran, H.Q Nguyen, P.Bedu, L.Duchien, J.Perrin, Figuresde Transformation pour des Architectures Logicielles, LMO,
2005.
[24] H.Q Nguyen, L.Duchien, P.Bedu , J.Perrin, Achieving
technical architecture with architectural figures, Proceedings ofthe
IASTED International Conference on Software
Engineering and Applications, Cambridge, USA, 2002.
[25] J. Maggee and J. Kramer. Concurrency - State Models andJava Program. John Wiley & Sons, 1999.
[26] J. Maggee, J. Kramer, and D. Giannakopoulou. Behaviour
analysis of software architectures. In Proceedings of the 1st
Working IFIP Conference on Software Architecture(WICSA1), 1999.
[27] F. Bueno, D. Cabeza, M. Carro, M. Hermenegildo, P. Lopez,
and G. Puebla. The ciao prolog system: A next generation logic
programming environment. Technical Report 3/97.1, CLIP,
April 2004.
[28] G. Leavens and Y. Cheon. Design by contract with jml. Draft
paper, March 2004.
[29] C. Szyperski, Component Software - Beyond Object-Oriented
Programming, Addison-Wesley, 2002, ISBN 0-201-74572-0.
[30] C. Caremoli and J.-Y. Berthou. CALCIUM V2: Guide
d'utilisation.
[31] Feiler, P.; Lewis, B.; & Vestal, S. "The SAE Avionics
Architecture Description Language (AADL) Standard: A Basisfor Model-Based Architecture-Driven Embedded Systems
Engineering. " RTAS 2003 Workshop on Model-Driven
Embedded Systems, May 2003.
[32] Java
API
for
XML
Processing(JAXP),
http://java.sun.com/xml/jaxp[33] MCQueue tool, http://staff.feweb.vu.nl/tijms/