ns
u c
Constraint language
ent
ons
deci
elop
me
of t
its associated tool.
 2009 Elsevier Inc. All rights reserved.
relativ
into
h thes
m that
Nowadays, at analysis/design time, one can describe software
architectures using an architecture description languages (ADLs).
After that, she/he can produce straightforwardly component
implementations (Szyperski, 2002) using an existing industrial
technology, like OMG’s CORBA component model (CCM Object
Management Group, 2002), Sun’s Enterprise JavaBeans (EJB Sun-
Microsystems, 2003) or Microsoft’s COM+ (Microsoft, 2005). For a
2005; Jansen and Bosch, 2005; Krutchen, 2004). Building this neces-
sary knowledge is a big time-consuming task because most models
do not capture it. In fact, at certain stages of the development pro-
cess there is nomean allowing to document that knowledge. Even if
it exists, often developers have to deal with a variety of languages
that make the task complex and cumbersome. Under cost and sche-
dule constraints, they generally choose to not use them. Without
any documentation of architectural decisions any evolution of the
systembecomes risky. Indeed, the evolutionmaybe in contradiction
with some previously taken decisions, which lead the system to
loose some of its quality attributes (maintainability, portability,
* Corresponding author.
E-mail addresses: Chouki.Tibermacine@lirmm.fr (C. Tibermacine), Fleurquin@
The Journal of Systems and Software 83 (2010) 815–831
Contents lists availab
te
w.irisa.fr (R. Fleurquin), Salah.Sadou@univ-ubs.fr (S. Sadou).position of its pieces. Documenting software architectures pro-
duces major benefit such as early analysis, system visibility and
complexity management, design discipline and global conceptual
integrity management. It received in the last two decades a lot of
attention by the software engineering community. With the ever
more widespread use of components, these high-level models have
now a central role in all the stages of most software development
processes. This led to the emergence of development processes
driven by architectures supported by numerous languages, tools
and methods (Kruchten et al., 2006; Shaw and Clements, 2006).
fore applying changes, we must gain a deep knowledge of the ratio-
nale behind the design decisions upon which the model was
created. This can help, for instance, in understanding the reasons
of the choice of a particular architectural style (Shaw and Garlan,
1996) or design pattern (Gamma et al., 1995). Usually, this knowl-
edge takes the form of a set of what we call architecture decisions.
An architectural decision identifies, at least, some of the key struc-
tural elements in the system and their externally visible related
properties (their rationale). But, properly documenting and using
decisions may involve many other fields (Tyree and Akerman,ADL
Software component
MOF
OCL
Constraint transformation
1. Introduction
Software architectures deal, at a
with the decomposition of a system
the mechanisms and rules by whic
and the global properties of the syste0164-1212/$ - see front matter  2009 Elsevier Inc. A
doi:10.1016/j.jss.2009.11.736ely coarse granularity,
its major components,
e components interact
emerge from the com-
smooth transition, she/he can first shift to a UML 2 component
model (Object Management Group, 2007) and then to one of its
profiles for the technologies previously cited (UML profile for EJB
(Rational Software Corporation, 2001) or UML profile for CCM
(Object Management Group, 2004)).
Any time we need to evolve a given architecture model, and be-Keywords:
Architecture constraint
language, which is shared with the other profiles, and a MOF architecture metamodel. In addition to this
family of languages, this paper introduces a transformation-based interpretation method of profiles andA family of languages for architecture co
Chouki Tibermacine a, Régis Fleurquin b,c, Salah Sado
a LIRMM, CNRS and Montpellier-II University, France
b INRIA, Centre Rennes – Bretagne Atlantique, France
cVALORIA, University of South Brittany, Tohannic, 56000 Vannes, France
a r t i c l e i n f o
Article history:
Received 18 July 2007
Received in revised form 24 November 2009
Accepted 24 November 2009
Available online 2 December 2009
a b s t r a c t
During software developm
guaranteed by these decisi
part of these architectural
stage to another in the dev
languages, called ACL. Each
decisions at a given stage
The Journal of Sys
journal homepage: wwll rights reserved.traint specification
,*
, architecture decisions should be documented so that quality attributes
and required in the software specification could be persisted. An important
sions is often formalized using constraint languages which differ from one
ment process. In this paper, we present a family of architectural constraint
mber of this family, called a profile, can be used to formalize architectural
he development process. An ACL profile is composed of a core constraint
le at ScienceDirect
ms and Software
elsevier .com/locate / jss

described by ACL. The dedicated tool using this method is pre-
sented in
choices d
ing the pe
the relate
ystems and Software 83 (2010) 815–831performance, etc.). When a problem appears, a rework is needed. It
is a sequence of iterations, that undoubtedly increases the costs.
There are some approaches that help the practitioners to auto-
matically gather some parts of design knowledge (using for in-
stance pattern detection) and present them in a manner that
highlights relevant information (Karahasanovic et al., 2007). But
these approaches cannot find all important knowledge behind
the design. Even if we identify a particular pattern, it is not obvious
to know its rationale. So, an explicit documentation remain the
best way in order to preserve the link between the choices made
by the designer and their rationale. For this aim, we propose an ap-
proach which encourages the documentation of the taken deci-
sions directly in the models and throughout the development
process. This requires to provide developers with a complete set
of dedicated languages covering all the software process. These
languages must be both simple to learn and powerful enough to
automate some tasks of a high value added (such as, the detection
of the violation of some properties during evolution, the detection
of the lost of consistency between the documentation and the
architecture designs/code, the decreasing of the costs of regression
testing, etc.). This is vital for ensuring a sufficient return on invest-
ment to motivate developers to adopt them.
In this paper, we present a family of languages designed to help
for an important and time-consuming part of the decision docu-
mentation process: the description of the structural elements of
a model related to a given decision. We call this part of a decision
an architectural choice (Tibermacine et al., 2005). This includes the
description of coarse-grained structures (such as styles or patterns)
or more fine-grained ones (such as design rules ). In this paper, we
do not deal with the other parts of an architectural decision such as
the documentation of the context and assumptions. In fact, there is
no standard recommending what to document and especially how
to document (ISO/IEC, 2007). Our approach can be used, as it is or
with extensions, in order to document any specific architectural
decisions. In Tibermacine et al. (2005, 2006), we provided an
example of the use of this family of languages to document certain
kind of architecture decisions for the purpose of software evolution
assistance. In these languages, an architectural choice is expressed
defining an invariant condition that must hold for the system being
modeled over elements described in a model. In these languages,
an architectural choice is expressed using invariant conditions on
elements describing the model. The formal aspect of theses lan-
guages makes it possible to provide a tool which automatically
analyze and/or evaluate the invariants. It can be used throughout
the development process to check if the architectural decisions re-
main preserved.
In order to reduce their learning cost, all these languages use
the same core constraint-level description language (CCL) based
on the well-known UML object constraint language (OCL). The
choice of OCL is based on the fact that traditional formal languages
are useable by persons with a strong mathematical background,
but difficult to use by average business or system modelers. OCL
has been developed to fill this gap. OCL is a formal language, which
remains easy to learn, read and write, so is CCL (our constraint-)
language. The variable part of each language is encapsulated in a
meta-object facility (MOF Object Management Group, 2003) mod-
el. These (meta-)models encapsulate the concepts issued from the
modeling domain of the concerned process stage. Thus, an expert
of the domain uses the same concepts when she/he specifies archi-
tectural choices in the same way as when she/he defines architec-
ture/component descriptions.
The outline of the remaining of the paper is as follows. In the
next section we illustrate the problem that is dealt with in this pa-
816 C. Tibermacine et al. / The Journal of Sper in more depth by using an example. In Section 3, we present
ACL, the family of languages introduced above to solve this prob-
lem. Section 4 details a method for the evaluation of constraints2. Problem situation by an example
To better situate the problem, let us consider a fictional exam-
ple illustrating the development of a simplified access control sys-
tem (ACS). The different parts of Fig. 1 provide an overview of its
architecture, which is organized as a pipeline (Shaw and Garlan,
1996) of four components. This system receives as input the neces-
sary data for user authentication (Authenticator component). After
identification, the data is sent to the AccessController component
which checks whether the user is authorized to enter into the con-
trolled area or not. If the access is granted, the Logger component
adds to the data the entrance date and hour, and stores it locally
(for the controlled area). It then sends these logs to the Transmitter
component, which adds information about the controlled area and
transmits all this data for a global storage.
The development of such an application may follow a classical
process in three stages: architectural design, component design
and component implementation. Transiting from one stage to an-
other can be done manually or automatically by using model trans-
formation techniques. Indeed, the choice of the means to transform
from one model to another has no effect on our approach. Below
we briefly present the development process of ACS in order to de-
scribe the raised problems.
2.1. Architectural design stage
Suppose at this stage that the architecture of the system was
described using xAcme (2001).1 The architecture designer chooses
a pipeline style aiming at a high-level of maintainability. To make
the evolution of the model easier, this important decision should
be documented. The need for this documentation is represented in
Fig. 1 by the label AD1 (AD1 stands for Architectural Decisions spe-
cific to the stage 1).
In this stage, it is possible to precisely document an important
part of this decision: its associated architectural choice (the com-
pliance with the pipeline style). One can use a dedicated language:
the Armani language (Monroe, 2001). This language provides con-
structs for capturing architectural design expertise such as design
rules and architectural styles. Moreover, this is a formal language.
Thus, one can expect to benefit from an automated design rule
checking engine, embedded in the used modeling tool, such as
the AcmeStudio environment.
Using graph theory, we enumerate the structural properties
that guarantee this architectural style. These properties are defined
using the Armani language as follows2:
(1) The first constraint introduces the definition of vertices and
arcs, such that each arc must be connected to two vertices:
(a) A vertex is a component with input or output ports (rep-
resented by the keywords inputT and outputT):
invariant forall comp: Component
in self.Components |
forall p: Port in comp.Ports |
satisfiesType(p,inputT)
or satisfiesType(p,outputT)
1 xAcme is the XML representation of Acme ADL (Garlan et al., 2000).
2 Concret
elements. F
originally inSection 5. It allows the preservation of architectural
uring a model evolution. Before concluding and highlight-
rspectives in the last section, we make a state of the art of
d work in Section 6.ely in xAcme constraint descriptions are decomposed into many XML
or the sake of brevity, we present the constraints as they are described
the Armani Language.