An Approach to Software Architecture Evaluation with the 4+1 View Model of
Architecture
Heeseok Choi, Keunhyuk Yeom
Department of Computer Engineering, Pusan National University
30 Changjeon Dong, Keumjeong Ku, Pusan, 609-735, Korea
{choihs, yeom}@pusan.ac.kr
Abstract
Architectural evaluation to determine a software
architecture’s fitness with respect to its desired quality
attributes is one of the most important issues in
architecture-based software development. However, the
existing techniques have too many limitations for a wide-
spread application, such as, the inappropriate
representation of an architecture and ambiguities in the
evaluation process. Therefore, this paper presents an
approach to evaluate software architecture with a 4+1
view model in UML. Our approach is divided into three
main areas of activities: the work involved in preparation,
execution, and completion of the evaluation. Through
performing these activities, architecture evaluation can
be explicitly described and its result can be systematically
organized based on the 4+1 view model. In addition, we
show the practical applicability and features of our
approach via an ATM example.
Keywords: software architecture evaluation,
architecture-level evaluation, 4+1 view model
1. Introduction
Quality attributes of large software systems are
principally determined by the system’s software
architecture, which represents a common high-level
abstraction of the system[1,2]. Furthermore, it is always
more cost-effective to evaluate software quality as early
as possible in the life cycle of the system. The obvious
risk is that potentially large amounts of resources will
have been put into building a system which does not
fulfill its quality requirements[3]. For this reason, it is
important to evaluate and determine whether a system is
destined to satisfy its desired qualities or not before it is
built[2,4].
Although methods for evaluating software architecture
with respect to software quality attributes exist (e.g.
[1],[3],[5],[6]), these evaluation techniques have too
many limitations for wide-spread applications. A typical
limitation for some techniques is that they require
1
Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02)
0-7695-1850-8/02 $17.00 © 2002 IEEE
considerable efforts from the software engineer for
creating specifications and making predictions[3,5,6].
Other techniques often require information about the
system under development that is not available during
architectural design, because of the ambition for accurate
results to guarantee the functionality or quality required
of a system[3,6]. Finally, more recently developed
techniques using scenarios have a number of uncertainties
associated with the steps such as scenario elicitation[1,2].
To address these problems, this paper introduces our
approach to software architecture evaluation with the 4+1
view model in Unified Modeling Language(UML)[7].
Our approach allows software architects to assess an
architecture qualitatively. It is more effective than
quantitative assessment or theoretical assessment[3]. This
paper is organized as follows: in the next section, the
related work is discussed, then an overview of our
approach and an example are introduced in sections 3 and
4, respectively, and lastly section 5 concludes this paper
with a summary.
2. Related work
The work presented in this paper is related to a number
of research activities. In fact, several research groups
have developed techniques for assessing their particular
quality requirements. Therefore, we first discuss previous
research on architecture evaluation, and then we briefly
discuss both software architecture and the requirements
from our approach’s perspective.
2.1. Software architecture evaluation
Several research communities have developed
techniques to perform architectural evaluation. In this
section, the characteristics and limitations of some
representative approaches are briefly illustrated.
2.1.1. Techniques evaluating a specific quality
attribute. Several research groups have developed
techniques used for the specification and assessment of
their particular quality requirements. Of those techniques,
 some techniques[8,9] have adopted statistical models, e.g.,
Markov Chain Model and Queuing models. On the other
hand, the ADL(Architecture Description Language)
research communities have developed various kinds of
languages to represent architectural information relevant
to their specific quality attributes, and they have analyzed
architecture using them[10]. But these approaches tend to
require considerable efforts from the software engineer
for creating specifications and making predictions. In
addition, the applicability of a particular model or an
ADL is restricted by the power of its representation.
2.1.2. Techniques using simulations or prototypes.
These techniques require that the main components of the
architecture are implemented and other components are
simulated resulting in an executable system[3]. But, these
techniques require information about the system under
development that is not available during the architectural
design. Additionally, creating a detailed simulation or
prototype for the purpose of evaluation is typically
expensive[6].
2.1.3. Scenario-based evaluation techniques. A
scenario-based technique is used to attempt to reduce the
problematic nature of evaluating a high-level design with
respect to software quality attributes[3]. To assess a
particular quality attribute, a set of scenarios has to be
developed to make concrete the actual meaning of the
quality requirements. The technique focuses on
architectural features, which will reveal design biases and
flaws early in the life cycle of the system. In these
techniques, however, there are a number of uncertainties
such as the granularity of representation and how
representative the scenarios are in respects to their
evaluation steps[11]. In [1,2,3,12], scenario-based
techniques have been introduced.
2.2. Architectural documentation
Having good architectural documentation is crucial to
the success of any architectural evaluation method[13].
The large variance of a quality assessment based on
architectural analysis is associated with the granularity of
the system description necessary to perform an evaluation.
The goals of architecture documentation are to record the
architects’ decisions and to communicate the architecture.
To meet these goals, the documentation must be complete
and unambiguous. For these reasons, different views can
be used to enhance the understandability of the
architecture and to focus separately on particular concerns,
as Kruchten pointed out[14]. In this respect, the 4+1 view
model[14] of architecture is one solution to obtain good
architectural documentation. The 4+1 view model
organizes a description of software architecture using five
concurrent views, each of which addresses a specific set
2
Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02)
0-7695-1850-8/02 $17.00 © 2002 IEEE
of concerns. Architects capture their design decisions in
four views and use the fifth view to illustrate and validate
them. Also, this use of multiple views allows for handling
separately the functional and non-functional requirements.
2.3. Software requirements
Software requirements are statements of need intended
to convey the understanding about a desired result. They
can be defined as consisting of functional requirements
and non-functional requirements (also referred to as
quality requirements)[15]. Functional requirements
capture the functionality of a system, and non-functional
requirements constrain the solutions that might be
considered. In general, non-functional requirements tend
to be related to one or more functional requirements. In
addition, non-functional requirements fall under two main
categories of quality: qualities such as availability,
performance, flexibility, integrity, and reliability from a
user’s point of view and qualities such as maintainability,
portability, and reusability from a developer and
maintainer’s point of view.
3. Our approach to software architecture
evaluation
Our approach is divided into three main areas of
activities: preparing the evaluation, executing the
evaluation, and completing the evaluation. More
specifically, they are activities that make data useful for
actual evaluation, activities for finding design decisions
and reasoning about them, and activities that organize
evaluation results, respectively. Figure 1 shows the
overall steps of the proposed approach.
Phase1.Prepare Step1. Define the template for requirements
Step2. Generate an evaluation contract
the evaluation
Step3. Define the template for architecture
Phase2.Execute Step4. Identify the architectural subdesigns
the evaluation using functional requirements
Step5. Determine the set of architectural
design decisions
Step6. Determine the rationale for each of the
architectural design decisions
Step7. Identify the relationships among the
decisions
Step8. Group the set of decisions
Phase3.Complete
the evaluation Step9. Generate the prediction data
Figure 1: Evaluation steps of our approach
Phase1. Prepare the evaluation
In this phase, we plan the goals and scope of our
architectural evaluation and document the architecture as
well. Our approach uses the features of a 4+1 view model
 of architecture with UML, and handles the functional and
non-functional requirements separately.
Step1. Define the template for requirements: The first
step in our approach is to separate functional
requirements from non-functional requirements. It serves
two main purposes:
ƒ It supports the generation of an evaluation contract.
ƒ It helps find architectural decisions afterwards.
As a result, we have an associated template, which is a
form for documenting functionality and non-functionality
separately as shown in Figure 2. In the template, each
non-function is related to one or more functions.
Functional Req. (FR) Non-Functional Req. (NFR)
FR1: - - - - - - - - - - - NFR1: - - - - - - - - - -
FR2: - - - - - - - - - - - NFR2: - - - - - - - - - -
FR3: - - - - - - - - - - - .....
FR4: - - - - - - - - - - -
.....
Figure 2: The template for requirements
Functional requirements are used to determine interesting
designs, and non-functional requirements are used to
identify quality attributes. Also, the relations between
functional and non-functional requirements are used to
co-relate information such as quality attributes, rationale,
design decisions, and subdesigns.
Step2. Generate an evaluation contract: Generating an
evaluation contract determines how many requirements
will be handled and the kinds of qualities that will be
dealt with. It is essential to clarify the scope and goals of
an evaluation because an architecture evaluation will be
derived from them. During this step, an evaluation
contract, which tells the scope and goals of an evaluation
and the relevant quality attributes, is defined. To produce
such a contract, the following activities need to be
performed:
ƒ To rank and clarify the scope of the functional
requirements.
ƒ To determine the set of non-functional requirements.
ƒ To identify the required qualities and their relationships.
As an aftereffect, expectations from the evaluation can be
concluded and negotiated.
Step3. Define the template for architecture: The next
step is to represent the candidate architectures in the 4+1
view model using UML. That is, the template for
architecture is defined as the 4+1 view model. Through
this work, good architectural documentation can be
acquired. In our 4+1 view model, architectural
information is summarized as shown in Table 1. For
instance, component concurrency and their
synchronization can be described in process view, and
3
Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02)
0-7695-1850-8/02 $17.00 © 2002 IEEE
components and their interconnection can be described in
deployment view. Also, architectural style or pattern can
be described in each view. Due to this consensus of
architecture-level information, more explicit evaluation is
possible.
Table 1: Architectural information in 4+1 view model
Views Architectural information
Use case -an abstraction of important requirements
-the principal purposes of system
Logical -a set of abstractions and their relationships
-logical inter-connection mechanism
Development -the organization of the actual software
elements (i.e., components or subsystems)
-the components’ interfaces
Process -the concurrency and synchronization
Deployment -physical distribution of software
components
Phase2. Execute the evaluation
When we have completed the previous steps, we are in
a position to perform an actual architectural evaluation.
During this phase, we determine what is useful data such
as subdesigns, architectural design decisions, and their
rationale, which are all helpful in selecting or improving
architecture. We illustrate the steps for this phase in the
following.
Step4. Identify the architectural subdesigns using
functional requirements: Once the functional
requirements have been defined and an architectural
documentation has been proposed, we can find the
subdesigns comprising the architectural model with
respects to each functional requirement within the scope
of the evaluation. To find them, we perform the following
activities.
ƒ Identify use cases describing the primary purposes of
the system.
ƒ Determine views from quality attributes related to the
functional requirements.
ƒ Identify subdesigns using the sequence of actions of
each use case.
The result of this step is the set of subdesigns, on which
the evaluation is focused.
Step5. Determine the set of architectural design
decisions: Architectural design decisions are defined as
the selection of solutions to design problems faced during
architectural design. According to this definition, step5
contains two subsequent activities that determine the
architectural decisions. They are as follows:
ƒ Determine the decision variables, which denote design
problems. For functional requirements within an
evaluation contract, one or more design issues are
determined from their actual designs.
 ƒ Determine decision values, which denote the selected
solution to each problem. These values are reasoned
about and compared with other architectural alternatives.
During this step, the design decisions are determined by
both the decision variable and its value.
Step6. Determine the rationale for each of the
architectural design decisions: Once the architectural
design decisions have been found, the rationale for each
of them must be analyzed in isolation. As shown in Table
2, each rationale contains rationale-id, architectural
design decision, candidate alternative, and consequences.
To complete these contents, each decision has to be
reasoned through.
Table 2: The contents of the rationale
Rationale ID rationale identity
Architectural design the selection of solutions to design
decisions problems during architectural design
Candidate the possible solutions to design
alternatives problem
Consequences effects on quality attributes
When we reason through the decisions, we may use the
various design theories[16], or refer to other alternatives
from competing architectures. So, we elicit statements
about the design decisions’ effects on particular quality
attributes.
Step7. Identify the relationships among the decisions:
Here, the dependencies among the decisions are
determined. That is, a decision is identified in how it will
affect quality attributes in relation to other decisions. It
helps in determining the tradeoffs among quality
attributes.
Phase3. Complete the evaluation
In this phase the previous results are finally
incorporated into a structured form. It allows us to predict
the quality attributes of software architecture or helps us
improve it in order to meet its quality requirements.
Step8. Group the set of decisions: In fact, we are very
interested in seeing design decisions’ effects on particular
qualities. Therefore, we discriminate positive variables
from negative ones based on the decisions’ effects on
each quality attribute. It is useful to determine the
priorities for architecture improvement, and to understand
the effects made by changing architecture design.
Step9. Generate the prediction data: Finally, we
explicitly organize some useful materials which have so
far been elicited as shown in Figure 3. To do this, we
define four kinds of layers and relations among them.
4
Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02)
0-7695-1850-8/02 $17.00 © 2002 IEEE
Qualities
Rationale
Architectural design decisions
Subdesigns
Figure 3: The structure of prediction data
The end result of this step is not only helpful in
identifying areas of risk in a design, but also useful in
understanding an architecture’s fitness with respect to its
quality attributes. In addition, it can support gradual
evaluation and control the complexity by extending the
scope of the evaluation.
So far, we have briefly introduced our approach to
software architecture evaluation. In summary,
architecture evaluation is prepared, executed, and
completed systematically through three phases based on
the 4+1 view model.
4. An example
To address the practical applicability and features of
our approach, we have chosen an example that has
already been extensively applied in the research literature,
that of the automatic teller machine system (discussed in
[17] and elsewhere). In this example, particularly, we
describe ATM system’s architecture based on
architectural information summarized in Table 1. We
focus on the applicability and understanding of our
approach in the real world. In addition, the point here is
to show that the process of performing an evaluation on
the ATM system produces useful bits of information to
assess its quality attributes systematically.
4.1. System Description
The ATM (Automatic Teller Machine) system exists to
support a computerized banking network including both
human cashiers and ATMs to be shared by a consortium
of banks[17]. Each bank has its own computer to
maintain its own accounts and process transactions
against accounts. ATMs communicate with a central
computer of the consortium which clears transactions
with the appropriate banks. An ATM accepts a cash card,
interacts with the user, communicates with the central
computer to process transactions, dispenses cash, and
prints receipts. The system requires appropriate record
keeping and security provisions. The system must handle
concurrent accesses to the same account correctly. The
banks will provide their own software for their own
computers.
4.2. Evaluating the architecture of ATM system
 Phase1. Prepare the evaluation system as use cases, which are an abstraction of the most
Step1. Define the template for requirements: Firstly, important requirements.
the functional and non-functional requirements are
summarized in isolation as described in Figure 4. This is
System Startup
just the subset of ATM system requirements. <<extend>>
Invalid PIN Extension
Functional requirements <<extend>>
Operator
The ATM system must be able to provide the following
Cash Withdrawal Transaction
services to the customer.
<<extend>>
-A customer must be able to make a cash withdrawal from
any suitable account linked to the card.
<<include>> Deposit Transaction
-A customer must be able to make a deposit to any account Customer
<<extend>>

linked to the card.

<<include >>
-A customer must be able to make a transfer of money
between any two accounts linked to the card. Transfer Transaction
<<include>>
-A customer must be able to make a balance inquiry of any
account linked to the card. <<include>>
Session
Balance Inquiry Transaction
Non-functional requirements (NR) <<e xtend>>
-NR1: The ATM system should manage the presence of
heterogeneous system.
-NR2: The system must handle concurrent accesses to the Failed Transaction Extens ion

same account correctly. Figure 5: Use case view

-NR3: The security mechanisms be located, in the ATMs or a
central network controller. Figure 6(a) shows a set of key abstractions of the ATM
-NR4: customer services should be available 999/1000
system and their logical relationships: association, usage,
requests.
-NR5: customer services should have a fast response time.
and composition. Figure 6(a) also represents the location
of security mechanisms per layer with respect to the ATM
Figure 4: Template for requirements
system’s security. Figure 6(b) shows inter-communication
mechanisms between two heterogeneous banking systems
Step2. Generate an evaluation contract: Next, we
using a forwarder-receiver pattern[16]. Using forwarders
determined the scope of the evaluation equal to the set of
and receivers decouples two banking systems with a peer-
items shown in Figure 4. We also identified quality
to-peer interaction model from the underlying
attributes such as concurrency, heterogeneity, security,
communication mechanisms. This allows for managing
availability, and performance from non-functional
the presence of a heterogeneous system.
requirements within the scope of the evaluation.
Session ATM
Step3. Define the template for architecture: There was {security=authentication} Entry Station

dispenseCash()
no architectural description of an ATM system, so we had cardNumber()
PIN()
ejectCard() entered on
retainCard() Transaction
to create one. In building the architectural models of the doInvalidPI NExtension() getMenuChoice()
issueReceipt() sendToBank()
ATM system, we determined various architectural design <<security=conf identiality>> getTransaction()
Cashier <<security=conf identiality>> finis hTransaction()
factors in each view as can be seen in Table 3. Station +performed

Table 3: The principal designs in views

Qualities Architectural designs Views owns Cash Withdrawal Deposit Transaction Transfer Transaction Balance Inquiry
Transaction Transact ion
Heterogeneity -communication mechanism Logical sendToBank() sendToBank()
getTransaction()
between two banks sendToBank()
getTransaction() finishTransaction()
getTransaction()
finishTransaction()
sendToBank()
getTransaction()
Concurrency -states of Account component Process finishTransaction() finishTransaction()

-concurrent access to Account

owns Bank
Security -location of security Logical bank_code Account
{security=authorization}
mechanisms per layer Consortium
chooseAccountType() balance
CCustome r
name
doTransfer() credit_limit_type
Availability -replication & synchronization Process consists of initiateWithdrawal() holds * address

Development finishWithdrawal()
initiateDeposit()
getBalance()
setBalance() *
Performance -distributed transaction model Process finishDepos it( )
Cash Card
bank_code
Deployment card_code
serial_number

Here, we will discuss only the meaningful parts of ATM (a) the abstractions of ATM system and their relationships
system’s architecture related to the contents of Table 3.
Figure 5 shows us the primary purposes of an ATM

5
Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02)
0-7695-1850-8/02 $17.00 © 2002 IEEE
 P1:Bank Forw1:Forwarder Recv1:Receiver Recv2:Receiver Forw2:Forwarder P2:Bank ATMUser:Customer :ATM :Account :Bank CardAgency:Customer

insert_card demand payment(account,amount)

receiverMsg request_password
sendMsg
marshal verify account

deliver enter_password
lock
IPC msg
grant
receive

unmarshal verify_card_with_bank
bank_account_OK

receiveMsg reques t amount

enter amount serve payment
update
sendMsg

m arshal
demand payment(account, amount)
deliver lock
IPC msg
not grant
receive
unlock
unmarshal

unlock
lock-X

(b) inter-communication mechanism between two banks

Figure 6: Logical view Available lock-S Checking lock-X Updating

unlock
Subsequently, Figure 7 shows the system description as timed out
aspects of a process view. In Figure 7(a), dynamic
behaviors for replication and synchronization of an timed out
account while performing transactions are shown. Figure
(c) concurrent accesses and the states of Account
7(b) shows the transaction model used in performing
Figure 7: Process view
transactions. Moreover, Figure 7(c) shows the situation of
concurrent access to the Account component and the
Finally, the components’ composition and their
internal states of it. These handle the quality attributes
deployment are shown in Figure 8. An ATM system
such as concurrency, availability, and performance, which
contains the four major components, which are deployed
can be addressed in the process view of architecture.
ATM Transaction AccountDB AccountBackupDB
according to client-server structure.
server: BankServer
request_transaction
request_info
<<DB>> <<BackupDB>>
re ply_info Account BAccount

process_transaction <<BackupDB>>
BAccount
Transactions
update_account <<DB>>
reply_transaction update_account Account Update

Transactions
Update
(a) dynamic behaviors for replication client: ATMKiosk
ATM Transaction Account

ATM-GUI
request_transaction BEGIN
ATM-GUI
QUERY
getBalance()
COMMIT
reply_transaction

request_transaction
BEGIN (a) development view (b) deployment view
QUERY
setBalance()
Figure 8: Development view and deployment view
COMMIT
reply_transaction
Phase2. Execute the evaluation

Step4. Identify the architectural subdesigns using

(b) per-operation transaction model[18] functional requirements: In this example, Figure 5, 6, 7,

6
Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02)
0-7695-1850-8/02 $17.00 © 2002 IEEE
 and 8 show subdesigns in relation to functional
requirements within the scope of the evaluation shown in Table 6: Group of decisions per quality
Figure 4. Quality Group Variables
Heterogeneity positive Dp2pCommunication
Step5. Determine the set of architectural design Concurrency positive DstateOfaccount
decisions: In our example, some decisions have been negative DmodelOftransaction
identified. Table 4 briefly illustrates decision variables Security positive DlocationOfsecurity
and their meaning. Their decision values can be found Availability positive DreplicationOfdb
positive DmodelOftransaction
from each of the views shown in Figure 6, 7, and 8.
Performance DlocationOfsecurity,
Table 4: Decision variables and their meaning negative
DreplicationOfdb
Decision variables Meaning
Dp2pCommunication peer-to-peer communication
DstateOfaccount State of account Step9. Generate the prediction data: Finally, Figure 10
DlocationOfsecurity Location of security mechanism shows the structured form of the evaluation result. This
DreplicationOfdb Replication unit and synchronization structure illustrates the upward relations from identified
DmodelOftransaction Transaction model in DB operations subdesigns to qualities. Thus, it helps us understand the
fitness of architecture with respect to its quality attributes
Step6. Determine the rationale for each of the or improve it to meet those quality attributes.
architectural design decisions: As an example, a Heterogeneity Concurrency Security Availability Performance

rationale is introduced in Figure 9. In the case of the

decision for Dp2pCommunication, it effectively supports R-id1 R-id2 R-id3 R-id4 R-id5
heterogeneous environments[16].
Rationale: R-id1
Architectural design decisions: Dp2p. Dstate. Dlocation. Dreplication. Dmodel.
Dp2pCommunication := value1;
Candidate alternatives:
concern: to support heterogeneous environment Fig 6(b) Fig 7(c) Fig 6(a) Fig 7(a) Fig 8(a) Fig 7(b) Fig 8(b)

value1 = forward-receiver pattern;

value2 = sockets;
Consequences:
effect: efficient inter-process communication(+)
encapsulation of IPC facilities(+)
Figure 9: Contents of Dp2pCommunication
Step7. Identify the relationships among the decisions:
As a whole, the relationships among the decisions have
been summarized using decision variables as shown in
Table 5. In other words, Table 5 tells us that base
decisions affect other decisions with respect to particular
quality attributes.
Table 5: Co-effect relations between decisions
Base decisions Affected decisions Related
qualities
DlocationOfsecurity DmodelOftransaction Performance(-)
DreplicationOfdb DmodelOftransaction Performance(-)
DmodelOftransaction DstateOfaccount Concurrency(-)
Phase3. Complete the evaluation
Step8. Group the set of decisions: In this step, the above
decisions are divided into negative or positive groups
with respect to the qualities required in our example. The
result is also represented using decision variables as
shown in Table 6.
Figure 10: Prediction data as evaluation result
4.3. Architectural problems of the ATM system
The results that we acquired by evaluating the
architecture of the ATM system revealed some potential
problems. For example, the decisions for improving
security or availability negatively affect the performance,
which is also one element of the system’s quality goals.
In particular, the decision for performance (i.e., the use of
per-operation transaction model) is risky since there is no
mechanism for handling collisions with other clients,
which can potentially access the account at the same
time[18]. Thus, these problems need to be reconsidered
carefully. As shown above, architectural evaluation can
contribute in revealing design biases and flaws or in
identifying areas of risk in a design.
5. Conclusions and future work
Since software architecture is a high-level abstraction
of a system, architectural evaluation has inherently some
ambiguities, for example, when the evaluation is
performed and what is evaluated has not been clearly
defined. Nevertheless, the success and expectations of
architectural evaluation largely depends on these two
factors. On the other hand, it needs to be noted that the
ambiguities relevant to software architecture evaluation

7
Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02)
0-7695-1850-8/02 $17.00 © 2002 IEEE
 are close to the ambiguities in the architectures
themselves and thus these ambiguities can be reduced by
determining the set of architectural information in the
architecture. In our approach, therefore, we proposed
using the 4+1 view model in UML to reduce the
ambiguities in the architectures studied, and presented
steps for evaluating an architecture explicitly based on the
proposed model. Compared with related works described
in Section 2, the features of our approach can be
summarized as follows:
ƒ Quality attributes is widely covered. In our approach,
various quality attributes to be addressed in the 4+1 view
model, e.g., performance, maintainability, availability,
security, reliability, and interoperability, can be evaluated.
ƒ Granularity level of system description is appropriate.
In our approach, an architecture includes the information
determined by the 4+1 view model using UML. Thus, the
architecture can be described in the appropriate level of
abstraction for wide-spread application.
ƒ Evaluation process is well defined. In our approach,
architectural evaluation can be explicitly performed based
on the 4+1 view model without the difficulties presented
by other techniques such as ADL techniques, simulation
and prototype techniques, and scenario-based techniques.
In conclusion, we presented an approach to software
architecture evaluation with the 4+1 view model of
architecture. In addition, we applied the proposed
approach to an automatic teller machine(ATM) system to
illuminate the approach.
In the future, we will refine our approach and show its
substantiality through lots of experimental results. Also,
we will discuss some interesting issues, such as handling
ambiguities in software requirements and dealing with
bad architectural decisions.
6. References
[1] Kazman, R., et al., “The Architecture Tradeoff Analysis
Method”, The 4th IEEE International Conference on
Engineering of Complex Computer Systems, August 1998,
pp.68-78.
[2] Bass, L., Clements, P., and Kazman, R., Software
Architecture in Practice, Addison-Wesley, 1998.
8
Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02)
0-7695-1850-8/02 $17.00 © 2002 IEEE
[3] Bosch, J., Design and Use of Software Architectures,
Addison-Wesley, 2000.
[4]Clements, P., Kazman, R., and Klein, M., Evaluating
Software Architectures, Addison-Wesley, 2002.
[5] Allen, R., “A Formal Approach to Software Architectures”,
CMU-CS-97-144, Carnegie Mellon University, May 1997.
[6] Abowd, G., et al., “Recommended Best Industrial Practice
for Software Architecture Evaluation”, CMU/SEI-96-TR-025,
Canegie Mellon University, January 1997.
[7] Eriksson, H. and Penker, M., UML Toolkit, Addison-Wesley,
1998.
[8]Klein, M. and Kazman, R., “Attribute-Based Architectural
Styles”, CMU/SEI-99-TR-022, Carnegie Mellon University,
October 1999.
[9]Inverardi, P., Mangano, C., Russo, F., and Balsamo, S.,
“Performance Evaluation of a Software Architecture: A Case
Study”, Proceedings of the 9th International Workshop on
Software Specification and Design, April 1998, pp.116-125.
[10] Medvidovic, N., “A Classification and Comparison
Framework for Software Architecture Description Languages”,
UCI-ICS-97-02, University of California, Irvine, February 1996.
[11] Clements, P., Bass, L., Kazman, R., and Abowd, G.,
"Predicting Software Quality by Architecture-Level Evaluation”,
Proceeding of the 5th International Conference on Software
Quality, October 1995, pp.485-498.
[12]Dobrica, L. and Niemela, E., “A Survey on Software
Architecture Analysis Methods”, IEEE Transactions on
Software Engineering, IEEE Computer Society, Vol. 28, No. 7,
July 2002, pp.638-653.
[13] Kazman, R., et al., “Experience with Performing
Architecture Tradeoff Analysis”, Proceedings of the 21st
International Conference on Software Engineering, May 1999,
pp.54-63.
[14]Kruchten, P., “The 4+1 View Model of Software
Architecture”, IEEE Software, Vol. 12, No. 6, November 1995,
pp.42-50.
[15]Kotonya, G. and Sommerville, I., “Requirements
Engineering with Viewpoints”, Software Engineering Journal,
January 1996, pp.5-18.
[16]Buschmann, F., et al., Pattern-Oriented Software
Architecture – A System of Patterns, John & Sons, 2000.
[17]Composable Systems Group at Carnegie Mellon,
http://www-2.cs.cmu.edu/People/ModProb/.
[18]Slama, D., Grabis, J., and Russel, P., Enterprise CORBA,
Prentice Hall PTR, 1999.