Study on Application of a Quantitative Evaluation Approach for Software

Architecture Adaptability

Xia Liu12, Qing Wang1

1
Institute of Software, Chinese Academy of Sciences, P.O. Box 8718, Beijing 100080,China
2
Graduate School of the Chinese Academy of Sciences, Beijing 100039
[email protected] , [email protected]

Abstract we first give a definition of adaptability and a metric at

the architecture level, and then propose a quantitative
Due to the rapid changes of business environment and evaluation approach for the architecture based on the
changing technologies, adaptability and measurement of scenario profile and impact analysis. It is demonstrated, in
the degree to which software is adaptable are critical this paper, the quantitative evaluation can be performed to
factors for survival of software systems. Software are support the architecture improvement through identifying
often claimed to be adaptable, however there is no the weakness of the architecture, and to support the
explicit and concrete definition of architecture choosing among the architecture candidates based on
adaptability. This paper first gives a definition of their adaptability.
architecture adaptability, and then presents a metric and
a quantitative evaluation approach to evaluate the 2. Related Work
architecture adaptability based on adaptability scenario
profile and impact analysis. The purpose of this study is Due to the rapid changes of environment and
to provide a structural adaptability evaluation method to requirement, adaptability has become one of the key
support architecture improving and decision making for features of the software system and attracts the
choosing among candidate architectures. concentration of both academe and industry. There are
many methods and techniques to handle the system
1. Introduction adaptability, we classified these into four classes:1)
architecture-based techniques[5][6], 2)component-based
Due to the rapid changes of technology, environment techniques [7][8], 3)Code-based techniques[9], 4)Genetic
and user requirements, adaptability has become an algorithm Techniques[10]ˈbesides these, some operating
important factor for survival and success of software systems provide the mechanism to support changing at
system, and more and more research has focused on how runtime, for example, dynamic linking library. And many
to achieve system’s adaptability, how to measure and programming languages provide the capability for
analyze the degree to which a software is adaptable to evolving at runtime and dynamically checking.
such changes. It is generally accepted that the quality There is few evaluation works for adaptability. Some
requirements for the final software are usually determined architecture evaluation methods including ATAM [11],
at the architecture level [1][2]. And measurement of ALRRA [12] and ALMA [13] analyze the reliability
adaptability can occur at different phases in the lifecycle /availability/modifiability etc. using different
of a software system, evaluating the adaptability at the measurement techniques, however they don’t deal with
architecture level to identify the weakness of architecture the adaptability analysis. In [4] Alex C. Meng proposed a
and further to improve architectures or choose among descriptive method for analyzing self-adaptive software,
architecture candidates based on adaptability are of a which figured that a self-adaptive software should include
critical concern for software practitioners. at least two components—the deliberative component and
There is few evaluation works for adaptability because the reactive component based on feedback control and
adaptability has got the attention in recent years. And feedforward control theory. This method does not give
there is no concrete definition for adaptability. [3] [4] the definition of adaptability and does not analyze the
present the methods for adaptability evaluation, but both adaptability deeply, and it is only a coarse qualitative
lack of the quantitative metrics, and they are too coarse or analysis method. In [3] L.Chung presented a process-
depends too much on the expert expertise. In this paper, oriented metric for software architecture adaptability,

Proceedings of the Fifth International Conference on Quality Software (QSIC’05)

1550-6002/05 $20.00 © 2005 IEEE
 which analyzed the degree of adaptability through the adaptable content. For example, from the point view of
intuitive decomposition of goals and the intuitive scoring end-user, adaptability means that new functions can be
for the goal satisfying level of software architecture. The added and deployed to the system, however, for the
method can find some defaults in the architecture, but it architects, adaptability may mean that the system can
depends too much on the intuition and the expert adapt different OS. Adaptability is only meaningful in
expertise, which leads to much uncertainty. specified context, i.e. architecture is adaptable to
specified changes requirements that ChangeReq refers to.
3. Definitions of Architecture Adaptability One change requirement that impacts on the system we
and Metric call a dimension of the adaptability, for example “users
require that the quality record is changeable” is one
dimension of the system adaptability. ChangeReq is
3.1. Definition of Architecture Adaptability
abbreviated as CR.
In an adaptable architecture, the elements
Adaptability has been defined variously by different
(components and connectors) of SA need to make
sources [14][5][15]: in [14] adaptability has been defined
reactions in order to satisfy change requirements. We call
as the “capability of the software product to be adapted
these actions as SAAction that are related to domain of
for different specified environments without applying
system. Fig.1 depicts the relationships of elements in
actions or means other than those provided for this
definition 1.
purpose for the software considered”, in [5] adaptability
To satisfy the external change requirements, the
is defined as the system can “adjust its behavior
software architecture needs to make certain reaction
according to changing of the environments” while in [15]
including the change of SA, which may includes adding
it is defined as “easy changeability of programs”.
new components/connector, modifying or deleting
Although these different notions, there is no explicit or
existing components/connector. Specifically, if
concrete definition of architecture adaptability, here based
architecture is designed to accommodate those change
on analyzing the impact on software architecture of the
requirements, then those change requirements have no
changes in critical customer objectives, we propose a
impact on the architecture in those dimensions. If some
definition of software architecture adaptability and the
architecture elements that must be changed don’t have
metric for making quantitative as well as qualitative
much impact on the architecture or the downstream
measurement and analysis.
implementation, then architecture also has adaptability in
The quality attribute of software is meaningful only in
such dimensions, because the architecture is independent
the specified context. Such statements as “the system
of, or not sensitive to these change requirements. We
should have adaptability” or “system adapts to the user’s
measure and analyze the adaptability degree through the
requirement” are not enough for measurement and
impact results, the more is the impact, the lower is the
evaluation. For example, “a system is modifiable” means
adaptability degree.
some of its classes or functions are modifiable,
performance is meaningless without some associated Stakeholder
resources. For adaptability, it is meaningful when stated
as adapting to the specified changes. These changes are
external to the system, including such as environment Has
Refer to
changes, user needs changes and so on. In this paper such Adaptability dimension ChangeReq
external changes are represented as the change
requirement in the stakeholders’ objectives. So we present Trigger

the architecture adaptability definition in Definition 1.

Definition 1. The Software architecture (SA)
Context SAAction domain
adaptability is the degree to which software architecture is
adaptable to the change requirement in stakeholders’ Figure 1. Architecture adaptability definition
objectives measured in terms of impact on software We believe that the definition of architecture
architecture elements. Adaptability ˙ <Context, adaptability is broad enough to encompass other similar
Stakeholder, ChangeReq, SAActions> concepts as extensibility, changeability, modifiability,
Based on this definition, SA adaptability is related to flexibility and so on.
the goals of Stakeholders and the SA attributes. Typical We have known that such statements as “the system
stakeholders are customers, architects and architectural should have adaptability” can’t be used for measurement
evolution strategists of the organization. Different and evaluation directly, so the decomposition of the
stakeholder has different viewpoints and demand different adaptability is necessary. Driven by point view of

Proceedings of the Fifth International Conference on Quality Software (QSIC’05)

1550-6002/05 $20.00 © 2005 IEEE
 different stakeholders, the adaptability goal of system is Based on definitions 1 and 2, this paper presents two
decomposed based on definition1. After decomposition, it metrics IOSA (Impact On the Software Architecture) and
forms a tree whose root node is “adaptability” and leaf ADSA (Adaptability Degree of Software Architecture) o
nodes are the change requirements. The nodes in the tree measure the impact on the architecture, and then further
have the hierarchy relationship of “AND” or “OR”. to evaluate the degree of adaptability. The result of the
In the project “Key Technologies Research on impact analysis process is the impact analyses, denoted
Product Lifecycle-oriented Quality Management and as IA .
Development of Integration Quality Information System” Different from the software product, the architecture is
that supported by National High Technology Research in a higher abstract level, and often described as design
and Development Plan of China, the itechs lab of documents that can’t be executed directly. So we could
IOS(Institute of Software) developed a Total not get the measurement data and answers to certain
Management System (TQM) based on ISO9000. Here we questions through execution of the product, and further to
take TQM as an example to illustrate our approach. TQM get the answer of whether the architecture goal is
is developed for manufacturing organizations. The achieved. Scenario is an effective technique in
product, workflow and management process of such requirement elicitation and architecture analysis. There is
organizations need to evolve in order to satisfy the market. one or several adaptability scenarios (see Sect.4.1)
TQM need to adapt such changes. corresponding to each change requirement in adaptability,
The adaptability decomposition of TQM, which belong here we perform the impact analysis through analyzing
to the domain of quality management, is depicted in the incorporation of the adaptability scenarios. The IOSA
figure 2. The leaf nodes of figure 2 depict the can be calculated by summing up the impact analyses in
stakeholders and the CR, SAAction will be showed in each adaptability scenario.
Table 1. |CR | |S |
IOSA ¦ PCR k u IA( SA )
k 1
¦ PS
k 1
k u IA ( SA )
TQMˉAdaptability |S |
OR (1)
AND
¦ PS
k 1
k u IA (C  T )
Production Use’s responsibility Usersÿ query |S |
process updates
updates requirement changed ¦ PS u IAC   IAT 
k 1
k Sk Sk

where | CR | is the number of change requirements, | S |

Engineering Dep. Quality Dep. Reengineer Administrator Administrator
CR1: modifying CR2: changing or CR3: adding is the number of the adaptability scenario. | PCRk | and
existing or adding CR4: changing CR5: changing or
adding format of format of report
new producing flow quality record templates user’s authority adding query mode | PS k | is the probability of change requirement CRk and
adaptability scenario S k respectively. IA is the impact
Figure2. Adaptability of TQM analysis result of whole architecture or architecture
Conflict may occur between sub-goals of adaptability. elements under change requirement or adaptability
The priority, and whether all the goals must be satisfied
scenario. C sk and Tsk are the set of impacted components
are all the factors considered in conflict resolution,
however, the final decision depends on the negotiation and connectors S k respectively.
among stakeholders. The application of the IOSA is that the degree of the
adaptability has inverse relation to the value of IOSA .
3.2. Metric for Architecture Adaptability We define ADSA as equation 2.
ADSA N  IOSA N>1 (2)
For analysis convenience, we describe the software we measure IOSA in terms of size of the impacted
architecture definition as below. component and connectors (see detail in sect.4), from the
Definition 2. Software Architecture (SA), SA=<C, T>. equation 1, we know that the range of IOSA is [0,Ğ],so
C is the set of components. C ={ c1 , c2 … ci … cn }, where the range of ADSA is [1,0], 1 means that the architecture
ci is a data unit or a computation unit in software system is totally adaptable in all dimensions, and 0 means that
(any unit implementing some certain function can be seen architecture can not adaptable to any change requirement.
as a component). T is the set of connectors, In order to make the value of ADSA spread in the range
T={ t i  j | ci , c j  C}, where t i  j connects the component equally, the value of N must be close to 1, after some
ci and c j , and implements the information exchange and experiments we use FP (function point) to measure the
size of the components/connectors, and define N=1.1,
behavior relations between components.
detailed measurement procedure is shown in sect. 4.

Proceedings of the Fifth International Conference on Quality Software (QSIC’05)

1550-6002/05 $20.00 © 2005 IEEE
 SAAction is triggered by Event, and connected with
4. Evaluation Approach for Architecture Event through “Generate” and “Trigger”. Agent is the
entity that interacts with the system actively through the
Adaptability “Capability "and “Perform” relationship. The instances of
Agent generally include user, system equipment, software
Based on the adaptability definition and metrics, this systems that interact with the system and automaton part
section discusses an approach to quantitatively measure internal to the system. When the adaptability goal and the
and evaluate software architecture adaptability through change requirement are available, we can get the
developing adaptability scenario profile and impact interactions between the agent and the system under the
analysis. The approach is driven by stakeholders’ change requirements, i.e. adaptability scenario.
adaptability goal, supporting architecture improving and
ChangeReq relationship
architecture candidates choosing. The approach is defined IsA
by following steps: Response to
1) Developing adaptability scenario profile for each Output
candidate architecture based on the adaptability goal SAAction Input SA-Element
of system; Generate
2) Performing impact analysis under scenario profile; Trigger

3) Appling the metric and calculating the value of Event Agent

Capability
adaptability degree; Perform
4) Analyzing the results of adaptability evaluation.

4.1. Developing Adaptability Scenario Profile Figure 3. Adaptability scenario

Adaptability scenario profile is a set of related
adaptability scenario. Once the adaptability scenarios are
Scenario is one of the effective techniques in
available, we assign a value between 0 and 1(maybe 0 or
architecture analysis [16]. An adaptability scenario covers
1) to each scenario to denote its probability PS .
a typical use for the system related to adaptability, system
behavior for abnormal conditions and potential future Here we take TQM as the example. We developed two
changes to the system. In our definition, the change architectures for the TQM system, SA1 and SA2, see in
requirements lead in adaptability goal to a set of figure 4 and fig.5. Same or similar granularity is needed,
interactions between the agent and the elements of or choosing of candidate architectures will be
architecture, which form the adaptability scenarios. meaningless. The number beside each component shows
Following is its definition: that it is component ci , for example, “Authority
Definition 3. Adaptability scenario is the description of Definition” in Fig.4 is component c 4 .
the system behavior driven by the change requirement, SA1 uses an ADT (Abstract Data Type) where each
including the usage for the system, the reaction to the module hides and protects its internal data representation,
change requirement and potential future changes, which providing access function as the only way to store and
are all related to adaptability. An adaptability scenario retrieve data. In figure.4 each ADT such as “process
includes the action and events in system and the change assets” has its own functions for storing and retrieve data
requirement which triggers these actions, so we define the that are depicted as “DAC (Data Access Controller)”. In
adaptability scenario as S=<ChangeReq, SA-Element, this architecture, we assume each ADT constitutes a
Agent, SAAction, Event>, showed in figure 3. component and each of the other modules is a component.
ChangeReq is the same as that in definition 1. SA2 is based on a shared memory solution (see Fig.5.)
SAAction is the status transition among the software where communications between modules are achieved
architecture elements (SA-Elements). The SAAction gets through global storage such as “process assets” in Fig.5,
the input from the SA-Element, after the status transition which also is seen as a component.
generates the output to the SA-Elements. The SAAction
reflects the system reaction to the change requirement.

Proceedings of the Fifth International Conference on Quality Software (QSIC’05)

1550-6002/05 $20.00 © 2005 IEEE
 O rd e r
3
DAC

15
4 In p u t
5 Q u ery
O rd e r
6
P ro c e ss P ro c e ss
DAC
A s s e ts C u s to m iz e 1 A u th o rity
D e fin itio n
13
R e p o rt R e p o rt
DAC
6 C u s to m iz e T em p.
7 DAC 14
P ro c e ss P ro c e ss 2
DAC
D a ta Im p le . O u tp u t
U s e r /A u th o
R e p o rt
rity in fo . 12

Q u a lity 10
8 R e c o rd
C o lle c t D a ta
C u s to m iz e
ADT C o n n e c to r:
C o n tro l L in k

O th e r C o n n e c to r: DAC 11 DAC
C om ponent D a ta L in k 9
Q u a lity Q u a lity
R e c o rd A s s e ts D a ta

Figure4. TQM architecture- SA1

3
O rd e r

In p u t 4
O rd e r
5 13
6
P ro c e ss P ro c e ss Q u e ry
A s s e ts C u s to m iz e A u th o rity 1
D e fin itio n
12
2 11
U s e r /A u th o O u tp u t R e p o rt
rity in fo . R e p o rt T em p.
P ro c e ss P ro c e ss
d a ta Im p le .
7 8
9
C o lle c t D a ta

C o m p o n e n t: S h a re d D a ta
10 Q u a lity
C o m p o n e n t: M o d u le C o n n e c to r D a ta
Figure5. TQM architecture- SA2
analyze the impact of the changes in architecture to its
Taking SA1 as the example, under the condition of downstream implement.
CR1 (Modifying existing or adding new producing flow, C sk and Tsk are the sets of impacted components and
see Fig. 1.), the engineer customizes the new process in connectors in scenario S k respectively. We classify the
c 6 , and c 6 sends the related information to c5 , the states
impacted components into: 1) adding new component,
of c 6 and c5 changed. Above operations constitute an 2)deleting components 3) modifying existing component,
adaptability scenario of SA1. The scenario profile of denoted as c add , c del , c mdi , i.e. C sk = { c add } ‰ { c del }
TQM is shown in table 1. ‰ { c mdi }. Other changes in component can be described
by these three classes of changes, such as the components
4.2. Impact Analysis under Scenario Profile replacing by deleting an existing component and adding a
new one. Also, the impacted connectors can be classified
Once the adaptability scenario profile is available, we into three classes: 1) adding new connector, 2) deleting
can perform impact analysis, i.e. analyze whether the connector 3) modifying existing connector, so,
architecture and the action of the architecture satisfy the Tsk ={ t add } ‰ { t del } ‰ { t mdi }. The changes in architecture
change requirements in the adaptability goal, if not,
can be composed of component changes and connector
analyze the changes to the architecture and its elements
changes.
that required to incorporate the adaptability scenarios, and

Proceedings of the Fifth International Conference on Quality Software (QSIC’05)

1550-6002/05 $20.00 © 2005 IEEE
 Table1. Adaptability scenario profile
CR S i for SA1 PSi in Si for SA2 PSi in
SA1 SA2
CR1 S1 : Engineer customizes new process 0.15 S1 : Engineer customizes new process in 0.15
in c6 which sends info. to c5 . c6 which sends info. to c5 .
CR2 S 2 : Engineer adds new format of 0.15 S 2 : System for SA2 has no reaction to 0.3
quality record in c8 which sends info. CR2
to c9
S 3 : Engineer changes format of quality 0.15
record in c8 which sends info. to c9
CR3 S 4 : Engineer adds new report temp. 0.2 S 3 : System for SA2 has no reaction to 0.2
c13 ,which sends info. to c14 , report CR3
display using new temp.
CR4 S 5 : Administrator changes user’s 0.3 S 4 : Administrator changes user’s 0.3
authority in c1 which sends info. to c2 authority in c1 which sends info. to c2
CR5 S 6 : System for SA1 has no reaction to 0.05 S 5 : System for SA2 has no reaction to 0.05
CR5 CR5
Under the scenario S 2 of SA1, in order to satisfy the web service architecture that supports the service
change requirement of “Changing or adding format of automatically discovering and composition, adding
quality record”, new components c14 (Quality Record new functions has no impact on the architecture.
From the results of impact analysis, we can identify
Customize) and c15 (Quality Record Assets) need to be which component or connector does more frequently
added), c13 (Query) needed to be modified, and change. It is a sign of change prone areas, which may
accordingly connectors t 214 , t149 , t1415 need to be added. require more development resources. And the results
Impact Results of other scenarios can be seen in table 2. could also indicate the weakness of architecture, for
instance, many connectors that need to be modified may
Choose ci , t j  k at random, ci  C sk , t j  k  Tsk ,
mean that the communication mechanism needs to be
although ci , t j  k are both impacted by scenario S k , if simplified or re-examined. If many changes point to the
they have no impact on architecture and architecture same source (e.g., requirement gathering or design), this
downstream implementation, i.e. the architecture is information may support the improvement process.
independent of ci , t j  k or not sensitive to them, then,
4.3. Application of Metric
IA ( ci )=0, IA ( t j  k )=0; Commonly, changes below have
no impact on the implementation of the architecture: The result of impact analysis of IOSA can be
1) The new added component is reusable, or is a COTS calculated by size of the impacted components and
component. (The connector related to the component connectors. The estimation of LOC (Lines of Codes) and
may have impact on the architecture.) FP (Function Points) can be used to measure SOC (size of
2) The component required to be deleted is not used by components and connects). Because the architecture is in
others, or does not provide any information output to a higher abstract level, it is more uncertain to estimate the
others, i.e. the external coupling of the component is size using LOC, so we use FP to measure the size of the
0, which means it has no impact on others architecture elements, which is used in size estimation in
component. (It may have impact on the architecture requirement and design. So,
structure) |S |

3) Once the component in 2) is deleted, the connector, IOSA ¦ PS k u IA C Sk   IA T Sk 

which connect it with other components can be k 1
|S |
deleted. (3)
4) When adding new components, the system provides ¦ PS
k 1
k u SOC C ' Sk   SOC T ' Sk 
the mechanism for automatically searching and |S |

deploying new components. For example, in some ¦ PS

k 1
k u FP C ' Sk   FP T ' Sk 

Proceedings of the Fifth International Conference on Quality Software (QSIC’05)

1550-6002/05 $20.00 © 2005 IEEE
 Table2. Results of impact analysis
S i for IA S i for SA2 IA
SA1
S1 0 (SA1 incorporates S1) S1 0 (SA2 incorporates S1)
S2 0(SA1 incorporates S2 ) S2 { cadd }={ c14 (“Quality Record Customizeā)ˈ
c15 (Quality Record Assets”)};
{ cmdi }={ c13 }.{ t add }={ t 214 , t149 , t1415 }˗
IA =46.5FP
S3 0(SA1 incorporates S3 ) S3 { cadd }={ c16 (“Report Customizeā)};
{ cmdi }={ c12 } IA({ cmdi })=0
{ t add }={ t 216 , t1612 }˗
{ t mdi }={ t1211 , t1213 , t1012 }˗
IA =31.59FP
S4 0(SA1 incorporates S4) S4 0 (SA2 incorporates S4 )
S5 0(SA1 incorporates S5) S5 { cadd }={ c17 (“Query Generatorā), c18 = {“Query
modes”}};{ cmdi }={ c13 };
{ t add }={ t 217 ˈ t1718 ˈ t1317 }
IA =48.79 FP
S6 { c add }={ c16 (“Query Generatorŷ),
c17 (“Query modes”)};
{ t add }={ t 216 ⧎ t1617 ⧎ t1516 }
IA=39.69
where C ' Sk {ci | ci  C Sk and IA(ci ) z 0} , and Using the results obtained from applying our approach,
the analyst can:
T ' Sk {t j k | t j k  TSk , and IA(t jk ) z 0} .
1) Decide which architecture is more adaptable to
Based on the components and connectors classification stakeholders’ adaptability goal. In Sect.5.4, we can
in impact analysis in 4.2, the equation (3) evolved to see that the values of adaptability degree of SA1 and
|S |
SA2 are 0.828 and 0.115, from the definition of
IOSA ¦PS u FPC'
k Sk   FPT 'Sk 
adaptability in sect.3, we know that SA1 is much
k 1 (4)
more adaptable than SA2 to these change
|S |
§ FPc' add   FPc'del   FPc'mdi   ·
¦
k 1
PSk u ¨¨ ¸¸
© FPt 'add   FPt 'del   FPt ' mdi  ¹
requirements.
2) Decide in which dimension the architecture is
where C ' Sk {c'add } ‰ {c' del } ‰ {c'mdi } adaptable. From Table.3, we can see the impact
T ' Sk {t ' add } ‰ {t ' del } ‰ {t ' mdi } analysis results of SA1 are all zero under S1 ~ S 5 ,
Table 2 shows the summation of impacted components which indicates that SA1 incorporates these scenarios,
and connectors under each scenario. For example, under and is adaptable in the dimension of CR1-CR4. The
scenario S k of SA2, the impacted size summation is impact analysis results of SA2 are zero under
IA =46.5FP. We use the equation (3) and (4) to calculate scenario S1 and S 4 , which indicates that SA1
the value of the IOSA as below: incorporates these two scenarios, SA1 is adaptable in
IOSASA1 =1.985, IOSASA2 =22.708 the dimension of CR1 and CR4.
Then the equation (2) can be used to calculate the 3) Identify the weakness of architecture to support
value of the adaptability degree. architecture improvement. For example, that many
connectors need to be modified in order to achieve
ADSASA1 =0.828, ADSASA2 =0.115
the adaptability goal may mean that the
communication mechanism needs to be simplified or
4.3. Results Analysis re-examination. In this case, in scenario S 3 for SA2,
the change of c12 leads to the modification of all the

Proceedings of the Fifth International Conference on Quality Software (QSIC’05)

1550-6002/05 $20.00 © 2005 IEEE
 connectors linking with it, while it is not this case in [3] L.Chung, N.Subramanian, "Process-Oriented Metrics for
SA1. The reason for this is that in SA2 c12 is a Software Architecture Adaptability," Proceedings of the
shared data, so that changes in it will impact many of International Symposium on Requirement Engineering
the connectors linking with it. However in SA1, the (ISRE`01), IEEE Computer Press, Aug-Sep, 2001, pp.310-311.
data and its operation are encapsulated, the data is [4] A.C.Meng. “On Evaluating Self-Adaptive Software, Self-
accessed through uniform interface, changes in one Adaptive Software”, First International Workshop, IWSAS 2000,
component at most impact the DAC and have no
Oxford, UK, pp.67-73, April 17-19, 2000.
impact on the others. So we can know that the
[5] P.Oreizy, M.M.Gorlick etc. “An Architecture-Based
communication mechanism and the data storage are
the improvement area for SA2. Approach to Self-Adaptive Software”, IEEE Intelligent System,
This approach also has some limitations. Vol.14, No.3, pp.54-62, May/June 1999.
1) When using the approach for comparing adaptability [6] J.Sztipanovits, G.Karsai, T.Bapty. “Self-Adaptive
degree, the architecture should be designed for same Software for Signal Processing”. Communications of ACM,
system, or the value of ADSA is meaningless. Vol.41, No.5, May 1998, pp.66-73.
2) The more detailed is the description of architecture, [7] R.Keller, and U.Holzle. “Binary Component Adaptation”,
the more accurate of its size estimation, and so the Lecture Notes in Computer Science 1445, Spinger-Verlag,
more accurate of the ADSA . Berlin Heidelberg, 1998, pp.307-329.
3) Different granularity of the architecture description [8] J.Bosch. “Superimposition: A Component Adaptation
may leads to incorrect results.
Technique”, Information and Software Technology, Vol.41,
Iss(5), March 1999, pp.257-273.
5. Conclusion [9] R.B.Ayed, J.Desharnais, M.Frappier and A.Mili. “A
Calculus of Program Adaptation and its Appliances”, Science of
Based on analyzing the sensitivity of architecture to
changes in stakeholders’ goals, and analyzing the impact Computer Programming, Vol.38, Iss1-3, August 2000, pp.73-
on architecture of the changes in critical customer 123
objectives, this paper presents the adaptability definition, [10] J.Yu “The Evolutionary Component-Based Software
metric and a quantitative evaluation approach of software Reuse Approach”, Institute of Software, Chinese Academy of
architecture. Using this approach we can perform Sciences, 2003, P.H.D thesis. [Chinese]
architecture adaptability evaluation through adaptability [11] R Kazman, M.Klein, et al. “ATAMSM: Method for
scenario profile and impact analysis. This approach can Architecture Evaluation”. CMU Software Engineering Institute,
be used to decide the adaptability degree of architecture,
Tech Rep: CMU/SEI-2000-TR-004 ESC-TR-2000-004, 2000
to decide weakness of architecture, and then to support
[12] S.M.Yacoub, H.H.Ammar. “A Methodology for
the choosing of architecture candidates based on
adaptability and support the architecture improvement. Architecture-Level Reliability Risk Analysis”, IEEE
This is our initial work on architecture adaptability, Transactions on Software Engineering, 2002, Vol.28, No.6,
in the Future, we will collect more data to verify this pp.529-547
approach and optimize the adaptability metric. [13] P.Bengtsson, N.Lassing, et al. “Architecture-level
modifiability analysis (ALMA)”, Journal of System and
Acknowledgements Software, 2004, Vol. 69, No.1-2, pp.129-147
[14] ISO/IEC9126-1: 2001 Software engineering---Product
This work is supported by the National Natural Science quality—Part1: Quality model
Foundation of China (No. 60273026) and the National [15] Report on the Workshop on Adaptable &Adaptive
High Technology Research and Development Plan of Software, 10th Annual Conference on Objected-Oriented
China (No.2001AA113080 and No.2002AA413520).
Programming Systems, Languages and Applications, Oct.1995,
Austin, Texas.
References [16] M.A Babar, I.Gorton. “Comparison of Scenario-Based
Software Architecture Evaluation Methods”, 11th Asia-Pacific
[1] L.Bass, B.E.John. “Supporting Usability Though Software
Software Engineering Conference (APSEC'04), November 2004,
Architecture”, IEEE Computer, October 2001. pp.113-115.
pp. 600-607
[2] B.Nuseiben “Weaving Together Requirement and
Architecture”, IEEE Computer, Vol.34, Issue 3 March 2001,
pp.115-117.

Proceedings of the Fifth International Conference on Quality Software (QSIC’05)

1550-6002/05 $20.00 © 2005 IEEE