Automated Quantitative Attributes Prediction from Architectural
Description Language
Imen Derbel
1
, Lamia Labed Jilani
1
and Ali Mili
2
1
Institut Superieur de Gestion, Bardo, Tunisia
2
New Jersey Institute of Technology, Newark NJ 07102-1982, U.S.A.
Keywords:
Software Architecture, Non Functional Attributes, Architectural Description Language, Acme, Bottleneck
Analysis, Quality Attributes, Performance, Reliability, Maintainability, Availability.
Abstract:
Software architecture has become an increasingly important research topic in recent years. Concurrently much
more attention has been paid to methods of evaluating non functional attributes of these architectures. How-
ever, in current architectural description languages (ADLs) based on a formal and abstract model of system
behavior, there is a notable lack of support for representing and reasoning about non functional attributes. In
this paper, we propose ACME+ ADL as an extension of ACME ADL and discuss our quantitative model for
formal analysis of software architectures. This paper gives an overview of our formal approach for describ-
ing software architectures and analyzing their performance, reliability, maintainability and availability. The
proposed model is supported by an automated tool that transforms an architecture described in ACME+ into
a set of inequalities characterizing system non functional attributes. These inequalities are then solved using
Mathematica in order to obtain system properties as function of its components and connectors properties.
1 INTRODUCTION
Software systems are characterized by both their
functional requirements (what the system does) and
by their non functional requirements (how the system
behaves with respect to some observable attributes
like performance, reusability, reliability, etc.). Spec-
ification of non-functional properties at the architec-
tural level of a software system can be used to de-
scribe a system, analyze it, or direct decisions to make
refinements. Therefore, the representation and analy-
sis of non-functional attributes are taken into account
early in the software life cycle allowing not only early
problems detection and cost benefits but also assuring
that the chosen architecture will meet both functional
and non-functional quality requirements.
In current practice, very few of the non-functional
requirements are automatically checked. This man-
ual checking activity is prone to errors and time-
consuming due to the complex designs, as a result
of a high number of components, connectors and the
interconnections between them, as well as the possi-
ble architectural decisions. Therefore, an automated
verification, validation and testing of the quality at-
tributes of a software architecture is becoming more
needed for practitioners. Also, there is a notable lack
of support for non-functional attributes in existing
Architecture Description Languages(ADLs). Acme
(Garlan et al., 1997), Aesop (Garlan et al., 1994),
Weaves (Gorlick and Razouk, 1991) and others allow
the specification of arbitrary component properties,
but, none of them interprets such properties nor do
they make direct use of them (Medvidovic and Tay-
lor, 2000).
In this work, we propose an ADL based formal
method for representing and reasoning about sys-
tem non-functionalattributes at the architectural level.
We are interested in performance attributes (response
time and throughput), reliability (failure probability),
maintainability and availability. We aim to translate
an architectural description into a set of inequalities
that characterize non functional attributes of software
architectures. These inequalities are then optimized
using Mathematica (
c
Wolfram Research) in order
to obtain system properties as function of compo-
nents and connector properties. The architect can an-
alyze a software system by varying all the architec-
ture constituents (e.g., components, connectors) and
their non-functional attributes, test and compare it by
obtaining the system non-functional attributes output
given by that set. The architect can then compare the
obtained results and inform the practitioner on what
87
Derbel I., Labed Jilani L. and Mili A..
Automated Quantitative Attributes Prediction from Architectural Description Language.
DOI: 10.5220/0005003700870094
In Proceedings of the 9th International Conference on Software Paradigm Trends (ICSOFT-PT-2014), pages 87-94
ISBN: 978-989-758-037-6
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
solution is the most reliable, efficient, available, etc.
switch its attempts and preferences.
This paper is organized as follows. In section 2,
we discuss requirements of our analysis model. In
section 3, we present the main syntactic features that
we have added to Acme. In section 4, we present the
Mathematica inequalities produced using an inductive
reasoning. In section 5, we discuss bottleneck analy-
sis; in section 6, we show how we generate the pro-
posed analysis tool. We give an illustrative example
in section7. The paper concludes in section 8.
2 MODEL REQUIREMENTS
We submit the following requirements as a long term
goals for our model:
If we give the values of the non-functional prop-
erties of components and connectors, we want to
derive the corresponding values for the whole ar-
chitecture.
If we are given a system architecture, and
given components and connectors quantitative
non functional attributes, we want the model to
help us propagate inductively the requirements
from components and connectors to the whole
system.
If we are given values of the non functional at-
tributes of the components and connectors of an
architecture, we want to determine the sensitiv-
ity of the system attributes with respect to com-
ponent and connector attributes. In other words,
if we want to enhance a given system attribute,
which component or connector should we alter?
or, which component or connector is the bottle-
neck to the current attribute value?
For the purposes of this paper, we content ourselves
with the first and second goals. In order to enable
us to represent and reason about non functional prop-
erties of software architectures, we need an architec-
tural model characterized by:
The ability to represent the architecture of com-
ponents, their ports and connectors, their roles.
The ability to represent quantitative non func-
tional properties of components and connectors.
The ability to represent operational properties of
the architecture, in addition to its topological
properties. For example, if we have two com-
ponents A and B connected in parallel between
a shared source and a shared sink, we want to de-
termine whether they play complementary roles
(in which both are needed for normal operation)
or alternative roles (if any one is operational, the
system is operational). While these two config-
urations have the same topology, they represent
radically different architectures, with different op-
erational properties values. Thus, at a minimum,
we must be able to identify, among ports of a com-
ponent (and roles of a connector) which ports are
used for input and which ports are used for output.
Furthermore, if we have more than one input port
or more than one output port, we need to represent
the relation between the ports: are they mutually
synchronous or asynchronous? Do they carry du-
plicate information? or disjoint/ complementary
information? or overlapping information?
The ability to represent for each component (con-
nector) more than one relation between input ports
(source roles) and output ports (destination roles).
The reason we need this provision is that often the
same component (or connector) may be involved
in more than one operation, where each operation
involves a different configuration of ports (roles),
and have different values for its non functional at-
tributes.
The availability of automated support.
None of the existing ADLs meets all the requirements
defined above. However, the Acme ADL is the most
suitable for our purposes but after including some ex-
tensions. Acme ADL was chosen for many reasons.
First, unlike many ADLs(e.g. Darwin and Rapide),
it provides accurate textual notations to describe soft-
ware architectures, distinguishing between the differ-
ent architectural elements: components, connectors,
and configuration. Second, it is supported by AcmeS-
tudio, a modeling, parsing and code generation tool.
Furthermore, Acme is a pivot language that allows to
switch from one ADL to another to benefit from the
complementary capabilities of ADLs. Hence, to cater
to the ve requirements we have presented above,
we adopt Acme’s basic syntax and ontology of ar-
chitecture description, and add to it the concept of
Functional Dependency
. We refer to the extended
Acme ADL as ACME+.
3 ACME+ SYNTAX
In order to represent and reason about non func-
tional attributes at the architectural level, we pro-
pose the extension of Acme ADL with a new con-
cept of
Functional Dependency
. The new con-
struct of Functional Dependency defined in a com-
ponent (connector) description aims to represent re-
lations between component ports (connector roles)
ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends
88
and specifies its quantitative non functional prop-
erties. Each component (connector) has only one
Functional Dependency
construct described by one
or many dependency relations. Each relation ex-
presses that the component (connector) needs input
data received by its input ports (source roles) to pro-
ceed and produce data to its output ports (destina-
tion roles). This process is characterized by a set
of non-functional attributes. Consequently, each re-
lation description connects input ports (source roles)
and output ports (destination roles) and is character-
ized by specific non functional attributes values. A
Functional Dependency
description is written at the
end of a componentspecification, after the declaration
of all the ports, or at the end of a connector descrip-
tion, after the declaration of all the roles. A declara-
tion of a
Functional Dependency
consists of:
A name, to identify the dependency relation,
A declaration of the input relation (how input
ports or source roles are coordinated),
A declaration of the output relation (how output
ports or destination roles are coordinated),
A declaration of relevant properties (e.g. process-
ing time for components, transmission time for
connectors, etc).
As an example, let’s take a
Functional Dependency
construct that includes only one dependency relation.
We may write:
fundep {Relation Name //name of the dependency relation
input (Input Ports relations),
output(Output Ports relations),
properties(ProcTime=0.02 s, Thruput = 45 trans/s,
FailProb =0.001, MTTR= 120 h , MTBF= 2300 h)}
Identification of Input and Output ports:
At a minimum, the dependency must specify which
ports are used for input and which ones are used for
output. If a component has, say five ports, P1, P2, P3,
P4, P5 and we wish to record that P1, P2, P3 are the
input ports and P4,P5 are the output ports, we write:
input(P1,P2,P3),
output(P4,P5).
Relations between Input ports:
For input ports, we must specify whether they provide
alternative/duplicateinformation (the componentmay
proceed with data from any one of the ports) or com-
plementary information (component needs data from
all input ports before it proceeds); also, there are cases
where we may need a majority of input ports to pro-
ceed. We write respectively:
input(AnyOf(P1,P2,P3)),
input(AllOf(P1,P2,P3)),
input(MostOf(P1,P2,P3)).
In the latter two cases, we must also specify
whether the input ports must deliver their inputs syn-
chronously or asynchronously. Hence we could say,
for example:
input(AllOf(asynch(P1,P2,P3)),
input(MostOf(synchro(P1,P2,P3)).
Relations between Output ports: As for output
ports, in case we have more than one for a given com-
ponent, we may represent two aspects: the degree of
overlap between the data on the various ports (Dupli-
cate, Exclusive, Overlap), and the synchronizationbe-
tween the output ports (Simultaneous, Asavailable).
Pursuing the example discussed above, if P4 and P5
are output ports, then we can write, depending on the
situation:
output(Overlap(Asavailable(P4,P5)),
output(Exclusive(Simultaneous(P4,P5)),
output(Exclusive(Asavailable(P4,P5)).
4 ACME+ SEMANTIC
We want to map ACME+ source code onto a set
of Mathematica inequalities that characterize the non
functional attributes of the architecture of interest. To
this effect, we assume that: (1) all ports of compo-
nents are labeled for
input
or for
output
; all roles
of connectors are labeled as
fromRole
or as
toRole
;
(2) each port of each component and each role of each
connector has an attribute for each property of interest
labeled RT (response time), TP (throughput),FP (fail-
ure probability), MTTR and MTBF; (3) there is a sin-
gle component without input port and a single output
port, called the
source
; there is a single component
without output port and with a single input port, called
the
sink
; we assume that the
source
and
sink
com-
ponents are both dummy components, that are used
solely for the purposes of our model. The system non
functional properties are computed from the proper-
ties attached to the components and connectors (Proc-
Time, TransTime, Thruput, FailProb, MTTR, MTBF)
and represent attributes associated to the input port of
the
sink
component, namely:
System.ResponseTime = sink.input.RT,
System.Throughput = sink.input.TP,
System.FailureProbability = sink.input.FP,
System.MTTR = sink.input.MTTR,
System.Availability= sink.input.MTBF /
(sink.input.MTBF + sink.input.MTTR)
In order to obtain the values of these attributes, we
decide to maximize or minimize attribute values at-
tached to the input port of the
sink
component tak-
ing into account inequalities generated inductively.
AutomatedQuantitativeAttributesPredictionfromArchitecturalDescriptionLanguage
89
These inequalities are obtained by propagating at-
tributes from the
source
componentto the
sink
com-
ponent in a stepwise manner. They are written as
for the maximum problem and for the mini-
mum problem. Thus, as we want to maximize system
throughput and MTBF, we write inequalities and
try to maximize sink.input.TP, sink.input.MTBF,
subject to the corresponding inequalities. Also, as we
aim to minimize system response time, failure prob-
ability and maintainability, we write inequalities
and try to minimize sink.input.RT, sink.input.FP,
sink.input.MTTR, subject to the corresponding in-
equalities.
4.1 Basis of Induction
The output port of the source component has trivial
values for all the attributes, namely:
source.output.RT >= 0,
source.output.FP >= 0,
source.output.MTTR >= 0,
source.output.TP <= infinity,
source.output.MTBF <= infinity.
4.2 Inductives Rules between
Components and Connectors
Whenever a port is attached to a role, the attribute val-
ues are passed forward from the output port to the
source role. As an example, we present inequalities
generated for Response time and throughput quality
attributes:
C.output to N.originRole
We write:
C.output.TP = N.originRole.TP
C.output.RT = N.originRole.RT
4.3 Inductive Rules within Components
We present inequalities of the components and leave
it to the reader to see how the inequalities of the con-
nectors can be derived by analogy.
4.3.1 Single Input/ Single Output
Given a component C, we write an inequality that
links the attributes of the input port(input), the at-
tributes of the output port(output), and the properties
of the component. We write the inequalities:
C.output.RT >= C.input.RT + C.ProcTime.
C.output.FP >= 1-(1-C.input.FP)(1-C.failProb).
C.output.MTTR >= C.input.MTTR + C.MTTR.
C.output.TP <= Min(C.input.TP;C.thruPut).
C.output.MTBF <= (C.input.MTBF x C.MTBF)/
(C.input.MTBF + C.MTBF).
4.3.2 Multiple Inputs and Outputs
These equations depend on the nature of the func-
tional dependency relations. Let C designate a com-
ponent, whose input ports are called input1;...;inputn
and output ports are called output1;...;outputk. We
suppose that these input and output ports are related
with a functional dependency relation R expressed as
follows:
R(
Input(InSelection(InSynchronisation
(input1; ..; inputn)));
Output(OutSelection(OutSynchronisation
(output1; ..; outputk)));
Properties(procTime=0.7;thruPut=0.2;failProb=0.2)
)
We review in turn the five attributes of interest.
Response Time
For each output port outputi expressed in the relation
R, inequalities depend on the construct InSelection,
expressing the nature of the relation between input
ports.
If
InSelection
is AllOf, then C needs all informa-
tion from its input ports to proceed and generate an
output. We write:
C.outputi.RT>=Max(C.input1.RT;..;C.inputn.RT)
+ C.R.procTime.
If
InSelection
is AnyOf, then the receipt of the first
input information from any input port, triggers C run-
ning. We write:
C.outputi.RT>=Min(C.input1.RT;..;C.inputn.RT)
+ C.R.procTime.
Throughput
For each output port outputi of the component C ex-
pressed in the relation R, we write an inequality re-
lating the component’s throughput and inputiP. This
rule depends on whether all of inputs are needed, or
any one of them.
Consequently if
InSelection
is AllOf, and since the
slowest channel will impose its throughput, keeping
all others waiting, we write:
C.outputi.TP<=Min(C.R.thruPut;(C.input1.TP+..+
C.inputn.TP)).
Alternatively, if
InSelection
is AnyOf, since the
fastest channel will impose its throughput, we write:
C.outputi.TP<=Max(Min[C.R.thruPut;C.input1.TP];..;
Min[C.R.thruPut; C.inputn.TP]).
Failure Probability
For each output port outputi of the component C ex-
pressed in the relation R, we write an equation relating
component’s failure probability and input ports fail-
ure probability. This rule depends on whether all of
ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends
90
inputs are needed, or any one of them. We first con-
sider that inputi provide complementary information
(
InSelection
is AllOf). A computation initiated at
C.outputi will succeed if the component C succeeds,
and all the computations initiated at the input ports
of C succeed. Assuming statistical independence, the
probability of these simultaneous events is the prod-
uct of probabilities. Whence we write:
C.outputi.FP>=1-(1-C.input1.FPx..xC.inputn.FP)
(1 - C.R.FailProb).
Second we consider that inputi provide inter-
changeable information (
InSelection
is AnyOf). A
computation initiated at C.outputPi will succeed if
component C succeeds, and one of the computations
initiated at input portsC.inputi succeeds. Whence we
write:
C.outputi.FP >= 1-(1-C.input1.FP)x..x
(1 - C.inputn.FP)(1- C.R.FailProb).
Maintainability
For each output port outputPi expressed in the
relation R, inequalities depend on the construct
InSelection
, expressing the nature of the relation
between input ports.
If
InSelection
is AllOf, then C needs all informa-
tion from its input ports to proceed and generate an
output. Let’s recall that the maintainability of the sys-
tem is expressed in terms of MTTR quality attribute.
Hence we propagate MTTR through the architecture
and write:
C.outputi.MTTR>=C.R.MTTR+C.input1.MTTR+..+
C.inputn.MTTR.
If
InSelection
is AnyOf, then the receipt of the
first input information from any input port, triggers C
running. We write:
C.outputi.MTTR>=C.R.MTTR+(C.input1.MTTRx..x
C.inputn.MTTR)/
(C.input1.MTTR+..+C.inputn.MTTR)
Availability
For each output port outputi expressed in the
relation R, inequalities depend on the construct
InSelection
, expressing the nature of the relation
between input ports. The system availability is ex-
pressed in terms of system MTTR and system MTBF
as explained in section 3. MTTR inductive inequali-
ties have been already discussed. Hence, we present
MTBF related inequalities.
If
InSelection
is AllOf, then C needs all informa-
tion from its input ports to proceed and generate an
output, we write:
C.outputi.MTBF<=(C.R.MTBFxC.input1.MTBFx...x
C.inputn.MTBF)x
(C.R.MTBF+C.input1.MTBF+...+C.inputn.MTBF)
If
InSelection
is AnyOf, then the receipt of the first
input information from any input port, triggers C run-
ning. We write:
C.outputi.MTBF<=(C.R.MTBFxC.input1.MTBF x...x
C.inputn.MTBF)/
(C.R.MTBF+C.input1.MTBFx...xC.inputn.MTBF)
5 BOTTLENECK ANALYSIS
Bottleneck analysis forms the core of system perfor-
mance analysis. In our tool we have decided to apply
bottleneck analysis laws of queueing networks. In the
following we present these laws. A more detailed ex-
planation can be found in (Denning, 2008): The uti-
lization of the i
th
device(component or connector) is
defined by:
U
i
= X × D
i
(1)
where X is the system throughput and D
i
is the total
service demand on the i
th
device for all visits V
i
of
a task with processing time S
i
. D
i
is defined by the
following law:
D
i
= V
i
× S
i
(2)
where V
i
= X
i
/X, X
i
is the i
th
device throughput.
Since utilization U
i
cannot exceed 1, then X ×D
i
1.
Consequently, for each device i, the system through-
put X checks the following law:
X
1
D
i
(3)
Therefore, the component or connector with largest
D
i
limits the system throughput and is the bottle-
neck. In other words, we must compute D
i
for each
device in the system. Let us assume that D
j
=
Max{D
1
,D
2
,...,D
j
,...,D
n
}; device j is the bottle-
neck. In order to make these results into practice, our
tool, automatically computes the demand property of
each component and connector defined by the con-
stituents properties:
D =
(C.ThruPut ×C.ProcTime)
System.Throughput
(4)
Then it picks up the device having the maximum
value of D. There are several ways to deal with a bot-
tleneck component: speed it up or reduce its demand
in the system. After applying one of these options,
we can re-compute the new quality attributes of the
software and compare the improvements that will re-
sult. The main advantage of quality attributes analysis
at architectural level is to detect such problems at an
early stage. Since considering such changes at a late
stage can be expense, difficult or even unfeasible.
AutomatedQuantitativeAttributesPredictionfromArchitecturalDescriptionLanguage
91
6 AUTOMATED TOOL FOR
SOFTWARE ANALYSIS
In order to put the proposed model into practice, we
have resolved to proceed as follows:
We adopt ACME+ as the architectural description
language on which we attach our analysis model.
ACME+ is based on Acme’s ontology to which
we add
functional dependency
construct. The
new construct expresses operational information
and represents components and connectors non
functional properties.
We define an attribute grammar on top of ACME+
syntax, which assigns attributes such as response
time, throughput, failure probability, etc to all
the ports and all the roles of the architecture.
This attribute grammar can in principle be used
as a synthesized grammar, propagating actual at-
tributesup the syntax tree, or as an inherited gram-
mar, propagating required / hypothetical attributes
down the syntax tree.
We define semantic rules in the form of inequali-
ties that involve these attributes, and attach them
to various reductions of ACME+ BNF. The rules
in question are nothing but the inductive inequal-
ities we have discussed in the previous section,
along with associated operations (symbol table
operations).
We use compiler generation technology to gen-
erate a compiler for the augmented ACME+ lan-
guage. The purpose of this compiler is to generate
inequalities that involve the attributes associated
to the ports and roles of the architecture.
To compute the system wide properties of the
architecture (such as response time, through-
out, failure probability, etc), all we have to do
is solve the inequalities derived by the com-
piler. The resolution is achieved by Math-
ematica (
c
Wolfram Research) by maximizing
(sink.input.TP, sink.input.MTBF) and minimizing
(sink.input.RT, sink.input.FP, sink.input.MTTR).
Mathematica can solve the inequalities either
symbolically (by keeping component properties
and connector properties unspecified, and pro-
ducing an expression of the overall system at-
tributes as a function of the component and con-
nector properties) or numerically (by assigning
actual values to component properties and con-
nector properties and producing numerical values
for the overall system).
In order to facilitate the use of the compiler for an-
alyzing system architecture, we have developed a
graphical user interface (GUI). In its current version,
the compiler generates inequalities pertaining to re-
sponse time, throughput, failure probability, main-
tainability and availability; each of these attributes
corresponds to a tab in the GUI. Once we select a tab,
we can perform the following operations:
Compute the system level attribute as a function
of component level properties. The GUI does so
by merely solving the system of inequalities for
the unknown
sink.inpPort.AT, for attribute AT (where AT is the
attribute identified by the selected tab). When a
tab is selected, the GUI posts this value automati-
cally.
The GUI allows the user to update the value of
a property of a component or connector, and will
re-compute and post the updated value of the se-
lected system level attribute.
Once a tab is selected, the GUI also generates,
and posts in a special purpose window, the sym-
bolic expression of the corresponding attribute as
a function of relevant properties of components
and connectors.
To enable a user to assess the sensitivity of the
system level attribute with respect to component
level properties, the GUI shows a curve that plots
the system level attribute on the Y axis and the
component level property on the X axis.
Finally, for some attributes, the GUI can also
identify the component or connector that is the
bottleneck of system performance for the selected
attribute. Once the bottleneck of the architecture
is identified, the user can change the value of its
relevant property and check for the new (possibly
distinct) bottleneck.
Space limitations preclude us from illustrating our
analysis model with examples of system analysis. A
demo of the tool that we developed, which includes
the compiler and the user interface, is available on-
line at: http://web.njit.edu/ mili/granada.exe. In this
demo, we present the use of the analysis tool in order
to analyze Aegis Weapons System (Allen and Garlan,
1996).
7 EXAMPLE
7.1 System Description
Let’s consider a system consisting of three interact-
ing components: a web server(S), a web client(C),
and a database(DB). We assume that the client makes
ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends
92
requests to the server and receives corresponding re-
sponses. The server makes a request of the database in
the process of filling the client’s request. For the sake
of brevity, we content ourselves with giving ACME+
descriptions of only server componentand we analyze
performance (response time, throughput) and reliabil-
ity (failure probability) quality attributes.
We have noted that the server does two different pro-
cesses, each process is described by a dependency re-
lation which links an output port to an input port and
is characterized by a different quality attribute values:
Following the receipt of the customer’s request by
its input port
input
, the server generates a re-
quest to the database by its output port
output
.
This process requires a service time equal to 20
ms. We refer to the dependency relation describ-
ing this process as
Request
.
Once the server receives a response from the
database by its input port
input1
, it sends a re-
sponse to the client by its output port
output
.
This process requires a service time equal to 20
ms. We refer to the dependency relation describ-
ing this process as
Response
.
Server’s ACME+ Description is given by:
component S ={port input,port output,
port input1,port output1,
FunDep = {
Requete (Input( input);
Output(output) ;
Properties_values( ProcTime=20 ms,
Thruput= 600 tr/s,
FailProb=0.0002))
Reponse (Input( input1);
Output(output1) ;
Properties_values (ProcTime=20 ms,
Thruput= 700 tr/s,
FailProb=0.0002))};
Several questions concerning the overall quality at-
tributes the system should be answered, such as:
What are system quality attributes: response time,
throughput, failure probability, etc.?
Which component is the bottleneck? Should it be
upgraded or replicated?
7.2 Quality Attributes Analysis
In the following, we present the basis of induction and
inequalities generated relatively to the server(S).
Basis of Induction. We write:
Datasource.output.RT >= 0,
Datasource.output.FP >= 0,
Datasource.output.TP <= infinity,
Inequalities between Ports of S and Roles of Con-
nectors. Let’s take the example of the link between S
and the connector Cn1:
S.input.RT >= Cn1.toRole.RT
S.input.FP >= Cn1.toRole.FP
S.input.TP <= Cn1.toRole.TP
Inequalities within Connectors. Let’s take the ex-
ample of the connector Cn1 connecting C to S.
Cn1.toRole.RT >= Cn1.fromRole.RT+Cn1.transTime
Cn1.toRole.FP >= 1-(1-Cn1.fromRole.FP)x
(1-Cn1.transTime)
Cn1.toRole.TP <= Min(Cn1.fromRole.TP;Cn1.transTime)
Inequalities within S. With respect to the two depen-
dency relations, we write:
S.output.RT >= S.input.RT+S.Request.ProcTime
S.output1.RT >= S.input1.RT+S.Response.ProcTime
S.output.FP >= 1-(1- S.input.FP)x
(1-S.Request.FailProb)
S.output1.FP >= 1-(1-S.input1.FP)x
(1-S.Response.FailProb)
S.output.TP<= Min(S.input.TP;S.Request.thruput)
S.output1.TP<=Min(S.input1.TP;S.Response.thruput)
After using Mathematica to solve the inequalities, we
find the system attributes presented in table 1:
Table 1: Values of systems properties.
System
Attribute
Response
Time (s)
Throughput
(tr/sec)
Failure
Probab
exp-
Datasink.
outputP.RT
Datasink.
outputP.TP
Datasink.
outputP.FP
ression
value 265 300 0.001
7.3 Bottleneck Analysis
We propose to apply bottleneck analysis to deter-
mine the component that limits system performance.
For each component: client, server and database, we
calculate the
request
D
Cp
=
(Cp.thruPut×Cp.procTime)
System.Throughput
,
then we select the componenthaving the largest value.
Client and server components are described by two re-
lations of functional dependency (
Request
(Req)and
Response
(Resp)). Therefore, for each component,
we compute two
demand
values with respect to each
dependency relation (Table 2). For example, for the
server component, we compute two values D
S
Requete
and D
S
Reponse
respectively to the relations Request and
Response. They are defined by:
D
S
Request
=
(S.Requete.thruPut×S.Requete.procTime)
System.Throughput
;
D
S
Response
=
(S.Reponse.thruPut×S.Reponse.procTime)
System.T hroughput
Table 2: Components demand values.
Client Server Database
Demand D
C
Req
= 40 D
S
Req
= 30 D
DB
Process
=
values D
C
Resp
= 62.5
D
S
Resp
= 35
77.25
AutomatedQuantitativeAttributesPredictionfromArchitecturalDescriptionLanguage
93
D
DB
is the maximum value, therefore the database
component is the bottleneck of the system. To man-
age the problem of the bottleneck component, the de-
signer can proceed in two ways:
either replace the base data component by another
component with better performance.
or duplicate this component to distribute the
workload to several other components.
In the following, we will discuss these two solutions
assuming that the rest of the system remains un-
changed and we will compare the new non-functional
properties obtained for each solution.
First Solution: Component Substitution
We assume that the database component is substituted
by a single instance with improved performance: a
service time of 90 s, a throughputof 350trans/s. Sys-
tem ACME+ Description remains unchanged and the
new values of system properties will be modified as
shown in Table 3.
Table 3: Case of substitution: System properties.
System
Attribute
Response
Time (ms)
Throughput
(tr/sec)
Failure
Probab
exp-
Datasink.
outputP.RT
Datasink.
outputP.TP
Datasink.
outputP.FP
ression
value 252 350 0.0002
Second Solution: Component Duplication
We assume that the database component is replaced
by two identical instances of databases: DB1 and
DB2, each of which is characterized by a time ser-
vice 103 s and a throughput 300 trans/s.
Suppose that the server S sends requests to DB1 and
DB2 respectively via connectors Ca1, Ca2 and re-
ceives responses from databases by connectors Cb1
Cb2. We find the system attributes represented in the
table 4.
Table 4: Case of duplication: System properties.
System
Attribute
Response
Time (ms)
Throughput
(tr/sec)
Failure
Probab
expression
Datasink.
outputP.RT
Datasink.
outputP.TP
Datasink.
outputP.FP
value 265 500 0.0002
After comparing the results in tables 3 and 4, we
note that the substitution of the database component
by another component with better performance de-
creases the response time of the system, increases
its throughput and decreases its probability of fail-
ure. However replication leads to an unchanged value
of the response time of the system, increases the val-
ues of system throughput and reduces the probability
of failure. The choice of the best solution between
these two cases depends on customer preferences be-
tween getting a faster system or a system with the
same response time and higher throughput. Other fac-
tors such as cost modifications can also be taken into
account in the final decision.
8 CONCLUSION
In this paper, we have proposed ACME+ as an exten-
sion of Acme ADL, on which we attach our analysis
model and discussed the development and operation
of a compiler that compiles architectures written in
this language to generate inequalities that character-
ize non functional attributes of software architectures.
The tool that we have developedincludes the compiler
and the user interface, it permits the experimentation
of ACME+ and its proof of concept. In case of interest
it may be demonstrated at the conference.We are cur-
rently trying to compare the results obtained for some
system non functional attributes with those supported
by other ADLs based on a formal, abstract model of
system behavior. The perspectives of our work are
to add other quantitative non functional attributes and
to investigate more profoundly architecture styles and
dynamic architectures.
REFERENCES
Allen, R. and Garlan, D. (1996). A case study in architec-
tural modeling: The aegis system. In In Proceedings
of the 8th International Workshop on Software Speci-
fication and Design, pages 6–15.
Denning, P. (2008). Throughput. Wiley Encyclopedia of
Computer Science and Engineering.
Garlan, D., Allen, R., and Ockerbloom, J. (December
1994). Exploiting style in architectural design envi-
ronments. In Proceedings of SIGSOFT’94: Founda-
tions of Software Engineering, pages 175–188.
Garlan, D., Monroe, R., and Wile, D. (November 1997).
Acme: An architecture description interchange lan-
guage. CASCON’97. Toronto, Ontario, page 169183.
Gorlick, M. and Razouk, R. (1991). Using weaves for soft-
ware construction and analysis. In ICSE, pages 23–34.
Medvidovic, N. and Taylor, R. (2000). A classification
and comparison framework for software architecture
description languages. IEEE Trans. Software Eng.,
26(1):70–93.
ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends
94