A Multi-View Architectural Model and Its Description and Construction
Chang-ai Sun
School of Information Engineering
University of Science and Technology Beijing, Beijing 100083, China
casun@ustb.edu.cn
Abstract
Software architecture is one of key factors to the
success of modern large-scale software-intensive
systems development. Among the existing architectural
models, some important aspects are ignored while
should be addressed. To overcome this, we propose a
multi-view architectural model, which is an extension
to the “4+1” view architectural model proposed by
Kruchten, and discuss the description and construction
techniques for the extended architectural views. We
employed the proposed architecture model and
relevant description and construction techniques to
develop a component based software testing platform.
The experience and lessons with application of the
proposed architectural model are reported. Results of
the case study show that the proposed multi-view
architectural model and relevant techniques are useful
to the development of large-scale software-intensive
systems.
1. Introduction
Increasingly modern large-scale software-intensive
systems are built from components. Software
architecture (SA) depicts components, interconnection
and interaction between components, configuration and
constraints of the system under development [1]. SA is
a blueprint for implementation of the system and hence
is one of key factors to the successful development of
large-scale systems. Often, the SA of large-scale
systems is complex, and thus should be described from
different views. The Unified Modeling Language
(UML) [2] is widely used to describe the architecture
of systems from different views. Based on the UML,
Kruchten proposed a “4+1” view architectural model
[3]. The model consists of logical view, process view,
physical view, development view and scenarios.
Although the model intends to depict a system’s
architecture from different aspects, some limitations
remain, such as:
978-1-4244-5392-4/10/$26.00 ©2010 IEEE
• Data processing is not explicitly specified. For
data-centric systems or database applications, data
information is the most important aspect.
• The multi-layer abstraction is not well supported.
• Instantiation from architecture specifications to
implementation is not supported.
• Organizational structure with respect to the
development of components is not touched.
To overcome the above-mentioned limitations [4],
we propose a multi-view architectural model which is
an extension to the “4+1” view architectural model.
We also discuss the description and construction of the
extended views. This makes up the SA-based
development process framework [5] proposed by Bass
and Kazman in which the “4+1” view model is
employed while the construction of each view is not
touched.
With the proposed architectural model and its
description and construction techniques, we developed
a component based software testing platform prototype.
The experience and lessons with this case study are
reported, and the results of this case study validate the
effectiveness of the multi-view architectural model and
relevant techniques presented in the paper.
The rest of the paper is organized as follows.
Section 2 presents a multi-view architectural model,
and its description and construction are discussed in
Sections 3 and 4, respectively. Section 5 describes a
case study with the proposed architectural model and
relevant techniques. Section 6 concludes the paper.
2. A multi-view architectural model
The proposed architectural model is illustrated in Fig.
1. The model describes the system under development
from the aspects of function, framework, logic,
behavior, data, integration, and organization. These
aspects together address the four basic concerns in
architecture design, namely what is the architectural
design goal, why select such an architecture, how to
derive the architecture, and who is responsible for the
implementation of the architecture [6]. In more details,
• Function View (FuV) defines the goal of the
system from the perspective of end-users, including
the mandatory functional and non-functional
requirements.
• Framework View (FrV) describes the coarse-
granularity structure of the system at the higher
level of abstraction, and often adopts some
architectural styles or patterns. It guides the
subsequent refinements.
• Logical View (LoV) describes the static
compositions of components, and it is the
refinement of the FrV.
• Behavior View (BeV) describes the behavior
structure of the architecture, and it is concerned
with interactions, collaborations and
communications among components or connectors.
It is often derived from functional scenarios and
follows the constraints of the FrV.
• Data View (DaV) describes the data aspect of the
architecture from the perspective of data production
and consumption. DaV is in nature an instantiation
of LoV with respect to data, and at the same time it
connects and entangles BeV.
• Integration View (InV) expresses the assembly
and deployment process following the constraints
of the FrV. The InV integrates and deploys the
artifacts of LoV, BeV and DaV to build an
executable system. Components in the InV are
classified into computational components, data
components and connectors.
Architecture
style
Software
Architect
FrV (why)
FuV (what)
• Development View (DeV) indicates organizational
structure of development tasks. The DeV involves
the relationships between developers and
components, and the ones between components and
functionalities.
FrV, LoV, BeV and DaV provides the primary
architectural solution. Among them, FrV describes
coarse-granularity and high-level structure, while LoV,
BeV and DaV describes fine-granularity and low-level
structure from the perspective of static compositions,
dynamic behavior and data, respectively.
The architectural model illustrated in Fig.1 involves
several roles. Users and Analysts are responsible for
developing functional and non-functional requirements,
and representing these requirements by scenarios.
Software Architects are responsible for several tasks
such as (1) transforming functional scenarios to the
function view (FuV) and requesting the confirmation
from users, (2) making decisions on the framework
view (FrV) based on their architectural knowledge,
available architectural styles and constraints of
application domains, (3) refining the FrV to LoV, BeV
and DaV, (4) developing the integration view (InV)
and development view (DeV) based on the primary
architectural views. Developers implement
components following the constraints of LoV, BeV and
DaV. Managers are responsible for allocating
development tasks to developers using the DeV.
3. Describing the multi-view architectural
model by extending the UML
The SA model is an abstraction of the system under
development which is useful for controlling
complexity, and for stakeholders to understand the
system. Architectural Description Language (ADL) is a
tool for representing architectural model. An ADL
usually consists of a set of notations and rules for
organizing notations [7]. The existing architectural

DeV ( who)

description standard suggests that architectural model

DaV
BeV
LoV

should be described in terms of viewpoints, a kind of

Manager specification for creation and use of architectural views,
User including goals, users, techniques for creation and
analysis [8]. Table 1 lists out the description
InV (how) techniques of the multi-view architectural model. The
proposed description follows the basic principle of
Refinement viewpoints.
Scenarios UML is the de facto visual modeling language
Component Impact
Library standard which supports multi-aspects and multi-layer
Reference
modeling of the architecture. Although UML does not
Follow directly support the representation of the proposed
Association multi-view architectural model, while it provides the
Analyst Developer Integrator powerful extension mechanism including stereotypes,
Fig. 1 An illustration of the multi-view tagged values and constraints. Naturally, we turn to the
architectural model extension infrastructure for representing the extended
architectural views. The following guidelines should
apply. First, one should decide the base class of the
stereotype for extension. Those meta-model constructs
that have a similar semantics with architectural views
to be represented should be selected as candidates.
Second, the constraints or tagged values should be
added to the selected stereotypes according to the
During the second process, we employ a scenario-
driven iterative process to construct LoV, BeV and
DaV. The reason behind this is that LoV, BeV and
DaV is the refinement of the FrV, and at the same time
these architectural views must address the fulfill of
functionalities. Each functionality can be specified as
scenarios which in nature describe how stakeholders

Table 1 Viewpoints of the multi-view Architectural Model

Viewpoint Name Goal User Notation
Requirement FuV Describes functional and non- functional User, Extended Package Diagrams or
requirements of the system under Manager Use Case Diagrams
development in terms of users, focusing on Tester
the interaction with users Developer
Design FrV Describes coarse-granularity high-level Developer Extended Class Diagrams or
structure Tester Package Diagrams
LoV Describes static compositions of Developer Extended Class Diagrams
components (primary structure） Integrator
BeV Describes behavior of systems, focusing on Developer Extended Sequence Diagrams
collaborations, interactions and Integrator or Collaboration Diagrams
communications among instantiated
components (primary structure)
DaV Describes data production and consumption Developer Extended Class Diagrams or
of systems (primary structure) Integrator Package Diagrams
Process InV Describes the integration and deployment Integrator Extended Activity Diagrams
of systems
Organization DeV Describes organizational structure of Manager Extended Use Case Diagrams
development Tester or Component Diagrams
Developer
semantics of architectural views under consideration. are expected to operate the system under development
As a consequence, a UML profile for the multi-view [6]. The process consists of the following steps (more
architectural model can be created. The “Notation” details about constructing each architectural view are
column in Table 1 provides such an extension solution. provided in [4]):
The extension is partially illustrated by applying it to 1. Select a functional scenario FSi with the highest
model the architecture of graph-based distributed priority from unprocessed scenarios (requirements),
systems [9]. Interested readers can refer to [4] for the and create the mapping between FSi and the
fully detailed extensions. subsystem Si in the FrV.
2. Refine the subsystem Si in terms of LoV, BeV and
4. A process of constructing the multi-view DaV. The refinement should put an emphasis on
architectural model the following concerns,
We propose a process framework of constructing the a) Which sets of computation components
multi-view architectural model, as illustrated in Fig. 2. (ComSeti), connectors (ConSeti) and data
The framework consists of two processes. The first one components (DatSeti) should be required to
is a pattern-driven process for constructing the FrV. constitute Si.
The second one is a scenario-driven iterative process b) How the functionality should be assigned to the
for constructing low-level primary architectural views. involved components or connectors.
We further explain them below. c) How components or connectors deliver the
During the first process, software architects select assigned functionalities (i.e. interface design).
an architectural style from a library of architectural d) How the configuration of components and
styles based on requirements of system under connectors can ensure the satisfaction of non-
development and legacy artifacts. In our previous study, functional requirements (i.e. non-functional
a pattern-driven SA construction process is reported in requirement impacts the refinement decision).
[10]. The process can be employed to construct the 3. For each functional scenario FSi, one can derive its
framework view. logical view LoVi, behavior view BeVi, and data
view DaVi. We further merge LoVi and the
 Requirements Legacy
Architectural style
Pattern-Driven SA Construction FrV
Scenarios
FS1.. FSn
{Subsystem S1..Sn}
Select the function scenario FSi with the
highest priority, and create the mapping
between FSi and the subsystem Si in the FrV
FSi Refine the subsystem Si
{ConSeti} {ComSeti} {DatSeti}
Construct and merge low-
LoV BeV DaV
level primary architectural
views based on FSi
{LoVi} {BeVi} {DaVi}
Fig. 2 An illustration of the construction
process of primary architectural views
previously derived logical views, and merge DaVi
and the previously derived data views. This is due
to the following observations: (a) separate behavior
views benefit comprehension of behavior of the
system under development because people are
accustomed to comprehend system’s behavior
according to scenario segments; (b) merging of
logical views and data views is beneficial to derive
interfaces and configurations of components and
connectors; (c) merging of logical views and data
views also benefits the application and validation of
architecture patterns.
4. Repeat the above steps until all major functional
scenarios are processed. In this way, we can derive
low-level primary architectural views, including a
complete logical view LoV, behavior views
{BeV1,…, BeVn}, and a complete data view DaV.
5. Case study
In this section, we present a case study which describes
how the proposed architectural model and relevant
techniques are adopted to develop a component-based
software testing platform, and report experience and
lessons with this case study.
5.1 Applying the multi-view architectural
model to the Safepro platform
Safepro C/C++/Java developed by Beihang University
are a series of white-box software testing tools for C,
C++, and Java programs [11-13]. The author has been
involved in the development of this series of tools. The
previous versions of Safepro have some shortages,
such as lack of reuse among tools, lack of explicit
architecture modeling, and long cycle of
customizations.
To overcome these shortages, we decided to employ
software product lines (SPL) techniques to develop a
component-based software testing platform which
supports white-box testing of C, C++, and Java
programs. The key task is to develop a well-designed
architectural model from which testing tools for the
specific program can be efficiently derived. During the
SA design, we focus on issues such as the framework
of the platform, representation and sharing of testing
data among different tools, reuse of functional
components among different tools, and reconfiguration.
The key points are as follows:
(1) Function View was derived from the requirements
of previous versions. The platform supports
several types of white-box testing for different
languages of programs.
(2) A domain model of white-box testing tools was
abstracted by analyzing the commonality of
Safepro for C, C++, and Java programs. With the
domain model, we designed a C/S style of
Framework View for the platform.
(3) Using the scenario-driven iterative process, we
derived the Logical View, Behavior View and
Data View for the platform. Among them, the
BeV consists of a number of interaction diagrams
with respect to functional scenarios. For the
current version of the platform, we developed 12
coarse-granularity functional scenarios, 49 logical
components (including computation components
and connectors) and 21 data components (XML
schema). All components and scenarios are
described according to the templates. Explicit
mappings between scenarios and components are
specified. That is, for each scenario, we specify
components and connectors that are required to
collaborate to fulfill it.
(4) The platform in nature is a software product line.
The instantiation of testing tools can be derived at
compilation time or at runtime. The key is to
develop a configuration table that specifies
components and connectors required for the target
tool. Such a configuration table constitutes the
Integration View of the platform.
(5) The Development View of the platform involves
38 functional items, 14 developer and 70
components (three types of above-mentioned
components) and their associations.
5.2 Experience and lessons
Using the multi-view architectural model and its
description and construct techniques, we have
developed a component-based software testing
platform. The platform is implemented based on the
proposed architectural model and JavaBeans
technologies. The limitations with previous versions
are effectively alleviated. We report some lessons
learned when we developed the platform prototype
with the multi-view architectural model and its
description and construction techniques.
• Organizations must pay much attention to the
construction of SA during the development. Any
design decisions must follow the constraints of SA.
For those controversial architectural decisions, they
must be discussed adequately and come to a
consensus.
• For the development of similar applications,
software product lines should be adopted. For those
common components among different applications,
they must be carefully designed and should be
reusable across applications.
• SA should be well documented and its description
should follow some standards, such as component
templates, scenario templates, and notations for
extended architectural views.
• SA construction has to undergo continuous
refinements, modifications and optimizations, thus
is a long-term iterative process. Conformance of
SA description to implementation should be
carefully maintained.
6. Conclusions
We have presented a multi-view architectural model
and discussed relevant description and construction
techniques. The proposed architectural model is an
extension to the “4+1” view architectural model which
is widely adopted in practice.
Such an extension adequately addresses the four
basic concerns that have to be addressed during the
architectural design, and makes up the limitations of
existing architectural models. Firstly, it adds data
aspect modeling by the data view which is especially
important for data-centric systems, such as the white-
box testing tools reported in the paper. Secondly,
multi-layer abstraction is well supported. The proposed
architectural model provides the high-level coarse-
granularity modeling by the framework view and the
low-level fine granularity modeling by the logical view,
behavior view and data view. The refinement from
high-level architectural view to the low-level
architectural view is also supported. Thirdly, the
extension provides the integration view to address the
integration and deployment aspect, which effectively
aids the instantiation from architectural model to
implementation. As illustrated in the software testing
platform, individual testing tools can be easily derived
with the configuration table of integration view.
Finally, organizational aspect of SA is supported by
the development view.
Acknowledgements
We thank Professor M. Jin and C. Liu for their
constructive discussions, and other colleagues from
Beihang University for their collaborations during the
implementation of the software testing platform
presented in the paper. The work is supported by the
National Natural Science Foundation of China (Grant
No. 60903003), the Research Fund for the Doctoral
Program of Higher Education of China (Grant
No.2008000401051), and the Scientific Research
Foundation for the Returned Overseas Chinese
Scholars, State Education Ministry, China (Grant No.
2008[890]).
References
[1]C. Sun, M. Jin, C. Liu. “A Survey on Software
Architecture Research”, Chinese Journal of Software, 2002,
13(7):1228-1237.
[2]G. Booch, J. Rumbaugh, I. Jacobson. “The Unified
Modeling Language User Guide”, Addison-Wesley
Longman Inc, 1998.
[3]P.B. Kruchten. “The 4+1 View Model of Architecture”,
IEEE Software, 1995, 12(6):42-50.
[4]C. Sun. “Contributions to Software Architecture
Construction, Description and Reconstruction”, [PhD
Thesis], Beihang University, 2002.
[5]L. Bass, R. Kazman. “Architecture-based Development”,
Technical Report, CMU/SEI-99-TR- 007, 1999.
[6]L. Bass, P. Clements, R. Kazman. “Software Architecture
in Practice”, Addison Wesley, 1998.
[7]C. Sun, M. Jin. “Overview on Software Architecture
Description”, Computer Science, 2003, 30(2): 136-140.
[8]IEEE-SA Standards Board, “IEEE’s Recommended
Practice for Architectural Description”, IEEE P1471-
2000, 2000.
[9]C. Sun, J. Cao, M. Jin, C. Liu, M.R. Lyu. “Extendable and
Interchangeable Architecture Description of Distributed
Systems Using UML and XML”. LNCS 2834, Springer,
2003, pp.536-545.
[10]C. Sun, M. Jin, C. Liu, “Constructing Software
Architecture Based on Architectural Pattern”,
Proceedings of NASAC 2002, pp.41-49.
[11]C. Sun, C. Liu, M. Jin, M. Zhang. “Architecture
framework for software test tool”, Proceedings of
TOOLS 2000, IEEE Computer Society, 2000, pp.40-47.
[12]C. Sun, J. Zhou, J. Cao, M. Jin, C. Liu. “ReArchJBs: a
Tool for Automated Software Architecture Recovery of
JavaBeans-based Applications”, Proceedings of ASWEC
2005, IEEE Computer Society, 2005, pp.270-280.
[13]C. Sun. “Architectural solution for Software Testing
platform”, [Technical Report], BUAA/SEI-TR-2002-001,
Beihang University, April 2002.