Overview of an Approach Describing Multi-views/ Multi-abstraction
Levels Software Architecture
Ahmad Kheir
1,2
, Hala Naja
1
, Mourad Oussalah
2
and Kifah Tout
1
1
LaMA Laboratory, Lebanese University, Tripoli, Lebanon
2
LINA Laboratory, Nantes University, Nantes, France
Keywords:
Software Architecture, Viewpoints, Views, Abstraction Levels, Dependency, Consistency Rules.
Abstract:
Views and abstraction levels are two major concepts introduced in the software engineering domain in order to
enhance the architectural organization of complex systems’ requirements. Despite numerous and substantial
works that built and refined those concepts, they still less secure and less standardized to be part of a rough
software architecture.
This paper begins with a survey of evolution of the role and usage of those concepts in software architecture,
and ends with an overview of an approach integrating the views and abstraction levels concepts within a single
rough multi-views/multi-abstraction levels software architecture and respecting their usage in an evolutionary
architectural specification analysis.
The main benefits of this contribution was to allow system architects to solve more efficiently the complexity
problems; and allow them to build a complex, organized and coherent architecture; and nally enhance the
communication and harmony among different stakeholders.
1 INTRODUCTION
In large scale and complex systems, always different
people are involved in the system development pro-
cess and having for each of them different interests
knowledge backgrounds and tools. Thus, these peo-
ple, usually known as stakeholders, have their own
look to the designed system, or their own viewpoints.
Unfortunately, these stakeholders’ viewpoints
could be often complex and hard to be understood by
the architect, which will be reflected as extra com-
plexity in the systems architecture and difficulty to
cover the entire system’s domain. As mentioned in
(Rozanski and Woods, 2011), ”a widely used ap-
proach is to attack the problem from different direc-
tions simultaneously. In this approach, the architec-
tural description is partitioned into a number of sepa-
rate views, each of which describes a separate aspect
of the architecture. Informally, a view is an archi-
tectural design of a stakeholders viewpoint that cov-
ers delicately all its interests and required function-
alities, and represents them formally in a structured
architecture. An abstraction level represents a level
of details defined in order to treat the extra complexi-
ties retained after decomposing our system into mul-
tiple viewpoints, by relegating some viewpoints’ de-
tails which appear to be irrelevant in the first stages of
the modeling process to lower abstraction levels, so
we can zoom into a specific viewpoint to the desired
level of details.
In this paper, a survey is presented dealing with
the evolution of role and usage of two major concepts
in software engineering, which are the views and ab-
straction levels. Also an overview of our architectural
modeling approach called MoVAL (Model, View and
abstraction level) is suggested. In MoVal, both views
and abstraction levels concepts are integrated allow-
ing the architect to build robustly a multi-views and
multi-granularities software architectures.
This paper is further structured as follows: In
sections 2 and 3, studies and proposed solutions re-
lated to the views and abstraction levels fields are
presented. Section 5 and 6 presents our comparative
analysis and the deducted limitations of current so-
lutions, respectively, in order to motivate the contri-
bution of our approach presented in section 4, where
we will suggest the beginning of theory and practice
of views and abstraction levels suitable for software
system architectures. Finally section 7 concludes the
paper.
140
Kheir A., Naja H., Oussalah M. and Tout K..
Overview of an Approach Describing Multi-views/ Multi-abstraction Levels Software Architecture.
DOI: 10.5220/0004421001400148
In Proceedings of the 8th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE-2013), pages 140-148
ISBN: 978-989-8565-62-4
Copyright
c
2013 SCITEPRESS (Science and Technology Publications, Lda.)
2 HISTORY OF VIEWS
Viewpoints are the perspectives of different people or
stakeholders towards an information system (Finkel-
stein and Sommerville, 1996). Consequently, a view,
which is a formal representation of an associated
viewpoint, is an abstraction of the whole system’s ar-
chitecture suppressing some out-of-focus details.
Actually, this notion have been introduced in four
different fields of the software engineering domain,
which are: requirements engineering field, software
systems modeling field, software architecture con-
struction field and software systems implementation
field.
2.1 Views in Requirements Engineering
One of the first and leading researchers that worked
with viewpoint concept in requirements specification
was A. Finkelstein in (Finkelstein and Fuks, 1989),
where he and Fuks proposed a formal model aim-
ing to construct system’s specifications through a di-
alog in which the viewpoint negotiate. Robinson also
worked on the requirements specification through di-
alog (Robinson, 1990), in 1990’s and presented his
tool, Oz, but he focused more on the representation of
conflicting viewpoints and an automated way to pro-
duce resolutions.
Meanwhile, H. Delugash (Delugach, 1990) was
working on the representation of each viewpoint’s re-
quirements in a conceptual graph in order to merge
them by analyzing those conceptual graphs and per-
forming a join so that we obtain a single coherent set
of requirements for the target system.
In 1994, B. Nuseibeh et al. have introduced in
(Nuseibeh et al., 1994), the relationships that could
exist between viewpoints (overlapping, complemen-
tary, contradiction) in requirements specification and
have proposed a framework to describe those relation-
ships.
Finally, in 1997, Sommerville have contributed in
this domain in (Sommerville and Sawyer, 1997) by
proposing, Preview, a model for requirements discov-
ery, analysis and negotiation.
2.2 Views in Software Systems
Modelling
Prior to the incomparable commonness of UML in
software systems modeling field, Mullery has devel-
oped a method, called CORE, for requirements spec-
ification and design in 1979 (Mullery, 1979). CORE
is a modeling approach supported by diagrammatic
notation which decompose the modeling process to
many steps, and define for each of them a defini-
tion level and a set of viewpoints for which they will
model their requirements and establish, in an iterative
way, the consistency among them.
In the early 1990s, Booch et al. have developed
the Unified Modeling Language (UML), which was
adopted by the OMG in 1997. In the current version
of UML, 13 types of diagrams, where each diagram
type has an implicit viewpoint. Several researchers
have worked to extend UML model in order to add
the concept of dynamic views and viewpoints like in
(da Rocha, 2007; Nassar, 2003).
In 2003, a view-based UML extension, VUML
(Nassar, 2003), have been introduced to offer a UML
modeling tool in which the multiple viewpoints of the
system are taken into account in the modeling phase,
so they offered a methodology to construct multiple
class models one for each viewpoint and merge them
to obtain a single VUML model describing all the
viewpoints. Then in 2009 (Nassar et al., 2009), they
proposed a code generation tool that generates object
code of the corresponding VUML model. Finally,
they worked on the automation of the composition
process of VUML model (Anwar et al., 2010; An-
war et al., 2011) and included the attributed graphs in
order to reach this goal.
Also one of the important works done in this field
was (Dijkman et al., 2008) where they presented a
framework allowing the architect to model a system
from different perspectives or viewpoints by defining
a collection of basic concepts common to all view-
points and defining for each viewpoint its associated
level of abstraction for its basic concepts. In this work
they focused on the definition of consistency relation-
ships between the views.
2.3 Views in Software Architecture
In Software Architecture, various models have been
proposed of how to create a documentation (i.e. an ar-
chitectural description) by the separation of concerns.
Each model describes a set of viewpoints and identi-
fies the set of concerns that each of them address. The
different models cover the same software architecture
domain, including the associated structural, organiza-
tional, business and technological environment. The
concept of Views appears in one of the earliest pa-
pers, Perry and Wolfs classic (Perry and Wolf, 1992)
on Software Architecture in the early 1990s. In (Sowa
and Zachman, 1992), the approach presents an exten-
sive set of constructs called columns which is very
similar to views. In 1995, Philippe Krichten pro-
posed four different Views (Kruchten, 1995) of a sys-
tem and the use of a set of scenarios (use cases) to
OverviewofanApproachDescribingMulti-views/Multi-abstractionLevelsSoftwareArchitecture
141
check their correctness. In (Hilliard, 1999), the au-
thor proposes a Architecture Description Framework
(ADF) in which views are first-class entities governed
by type-like entities called viewpoints characterized
in terms of a set of properties pertaining to their ap-
plication, a viewpoint language. This study was the
basis of the IEEE Standard 1471 (Group, 2000) which
has formalized concepts used in Software Architec-
ture and brought some standardization of terminol-
ogy used in this field. It recognized the importance
of Views in architectural description and adopted the
Viewpoint concept defined earlier in (Hilliard, 1999).
Definitions of Terms Views and Viewpoints as given in
the Standard are at follows:
View: is a representation of a whole system from
the perspective of a related set of concerns.
Viewpoint: is a specification of the conventions
for constructing and using a view. A pattern or
template from which to develop individual views
by establishing the purposes and audience for a
view and the techniques for its creation and anal-
ysis. A viewpoint is a realization of the concerns
of one or more stakeholders.
Here, it is useful to review some of the approaches,
which are based on the above definitions of Views and
Viewpoints, for their salient characteristics:
In (Rozanski and Woods, 2011), the authors pro-
pose a Viewpoint Catalogue for Information Sys-
tems, extending the 4+1 set of viewpoints identi-
fied by Kruchten (Kruchten, 1995) comprising 6
core viewpoints including: the Functional, Infor-
mation, Concurrency Development, Deployment
and Operational.
In (Clements et al., 2002), 3 viewpoints, called
viewtypes, are identified which are: Module,
Component-and-Connector and Allocation. Also,
the author defines a three-step procedure for
choosing the relevant views for a system based
on stakeholder concerns. Also, this approach uses
the concept of combined views and prioritization
to bring the view set into manageable size for real-
world projects.
the valuable surveydone in (May, 2005) compares
between several view-based models and tries to
find out the correspondencies between the differ-
ent views proposed and the divergence between
them. It proposes an optimum framework cover-
age encompassing a viewpoint set selected from
different models with the greatest coverage of the
framework concepts. The limitation of this ap-
proach is that despite the selected views are not
independent, no connections or relationships are
defined between views.
2.4 Views in Software Development
In Software Development field, the Aspect-oriented
development techniques consider that a number of
software development concerns could not be han-
dled using the modularization boundaries inherent in
object-oriented languages and propose new artifacts
(beyond method, class or package) to separate new
kinds of concerns that tend to be amalgamated in
object-oriented paradigms (Mili et al., 2006). In this
area, several methods are proposed:
the Subject-Oriented Programming (SOP) (Os-
sher and al., 1995) technique addresses the func-
tional requirements. It views object oriented ap-
plications as the composition of several applica-
tion slices representing separate functional do-
mains. Each slice called subject consists of a self-
contained, object-oriented program, with its own
class hierarchy. Then, a composition language is
defined allowing the composition of class hierar-
chies (subjects).
the Aspect-Oriented programming (AOP) tech-
nique, such in (Kiczales et al., 1997) and (Ma-
jumdar and Swapan, 2010), addresses the non-
functional requirements, including architectural
aspects, error handling, security, distribution, per-
sistence, etc. It defines aspect as an implementa-
tion of a concern that pertain to several objects in
a collaboration. An aspect is a code module ad-
dressing specific concern and that cross-cut vari-
ous components in an application.
the View-Oriented programming technique (Mili
and al, 1999) considers each object of an applica-
tion as a set of core functionalities available, di-
rectly or indirectly, to all users of the object, and
a set of interfaces specific to particular uses, and
which can be added or removed during run-time.
Hence, we found that also in software development,
researchers always try to apply this concept of views
decomposition, presented in many forms (subjects,
aspects and views) in order to benefit from its orga-
nization and complexity resolution advantages.
3 HISTORY OF ABSTRACTION
LEVELS
Abstraction levels is a core concept in software engi-
neering, it is a way to deal with software systems’
complexities giving the architect or the analyst the
ability to examine different topics of the system at dif-
ferent levels of details (i.e. abstraction levels) accord-
ing to the purpose.
ENASE2013-8thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering
142
The abstraction levels was defined by Jeff Kramer
in (Kramer, ) as ”a cognitive means according to
which, in order to overcome complexity at a specific
stage of a problem solving situation, we concentrate
on the essential features of our subject of thought, and
ignore irrelevant details.
Actually there were not so many researches in this
domain as it was the case in viewpoints domain, but
among the valuable works done in this field (Regnell
et al., 1996) could be considered, where the authors
have proposed a hierarchical modeling approach that
consists of three static distinct abstraction levels:
The environment level, which could be seen simi-
lar to the scenario view of UML.
The structural level, in which they decomposed
each use case of the precedent level to multiple
units named episodes.
The event level, in which episodes are described
in further details through a Message Sequence
Chat annotation.
In (Medvidovic et al., 1996), authors have proposed
a software architecture’s modeling process of compo-
nent based architectures, composed of four modeling
process abstraction levels or, actually, four modeling
layers, which are: architectural components specifica-
tion, components’ interfaces definition, architectural
description and architectural styles rules. Actually,
they used in their work the pipe-and-filter and the C2
architectural styles as illustrations.
In (Monperrus et al., ), authors have proposed a
decomposition approach of meta-model to multiple
abstraction levels. In this approach they defined a
lower abstraction level as a specialization of the up-
per abstraction level and proposed splitting rules that
are based on the inheritance and specialization rela-
tionships of the meta-model.
4 MoVAL APPROACH
MoVAL (Model, View, Abstraction level) is an archi-
tectural modeling approach that comply to the IEEE
recommended practice for architectural descriptions
(Group, 2000) with some additions in order to as-
sist the system’s architect solving some types of com-
plexities that was not been treated in the existing ap-
proaches, and give him additional flexibility in the
development process comparing to those approaches.
So, MoVAL was designed in order to contribute in
complex systems architectural modeling and develop-
ment process independently of the adopted develop-
ment technology. Thus, the viewpoints concept was
involved in order to reduce the system’s complexities
Figure 1: Matrix representation of the MoVAL model.
by splitting vertically its requirements. In addition,
the abstraction levels concept was involved in order
to allow the system architect to also split horizontally
the system’s requirements into many abstraction lev-
els, and to allow other participants in the development
process to move between those abstraction levels ac-
cording to the purpose of the current task.
Hence, the main benefits of MoVAL is to allow
system architects to solve more efficiently the com-
plexity problems; and allow them to build a complex,
organized and coherent architecture coordinated in a
set of models related one to the other via links hold-
ing the coherence constraints; and finally enhance the
communication and harmony among different stake-
holders by giving each of them the appropriate tools
to express his interests.
Actually, a MoVAL model could be represented,
as shown in figure 1, by a matrix defining its views
and abstraction levels, and illustrating for each view
either it’s represented or not in each abstraction level.
Also, this matrix illustrates, where exists, the link be-
tween two view’s representations, either belonging to
two different views and the same abstraction level
(inter-views link), or belonging to the same view and
different abstraction levels (intra-view link). Those
links actually will hold the consistency rules that will
be defined later in our approach, and that will ensure
the consistency of the resulting software architectural
description.
Each column of the matrix represents a distinct
view of the model, and each line represents an ab-
straction level defined for this model. In reality, a
view of the model does not have necessarily repre-
sentations in all of the defined abstraction levels due
to the absence of the isomorphism between model’s
views. So, each view could have one or more rep-
resentations respectively in one or more abstraction
OverviewofanApproachDescribingMulti-views/Multi-abstractionLevelsSoftwareArchitecture
143
levels defined by the architect, depending on the sys-
tem’s requirements.
Note that the system decomposition to views and
abstraction levels should be done, for now, manually
based on the architects’ expertise in the system’s ap-
plication domain, and there is no defined mechanisms
offered in MoVAL helping architects to determine the
architectural views and abstraction levels.
4.1 Views in MoVAL
A view is a representation of the entire target system
considering a specific sub-set of the system’s con-
cerns that are directly related to the view’s associ-
ated viewpoint. This viewpoint could be considered
as a specification of the conventions for construct-
ing and using the view or a pattern or template from
which to develop this view. Consequently, a view in a
MoVAL architecture represents the vision of its asso-
ciated stakeholders and its associated requirements or
concerns. Those concerns, as defined by Sommerville
in (Sommerville, 2007), as the statements of services
the system should provide, how the system should re-
act to particular inputs and how the system should
behave in particular situations.
Actually, even though each viewpoint (conse-
quently a view) is often related to a specific category
of stakeholders, but always it’s up to the architect to
select the appropriate viewpoints and views to be con-
sidered in the architecture, and it’s up to him also to
decide if those viewpoints will be indirectly related to
different stakeholders.
Thus, a MoVAL architectural description always
contains a set of views that are connected one to the
other from certain points via well-defined connectors,
the links.
For example, for a stock management system, we
can identify the merchants’ viewpoint and some of its
concerns:
A merchant shall be able to monitor his stock at
any time.
A merchant shall be able to refill his stock by
making orders from the stock of his associated
sub-distributor.
A merchant shall be able to make sale operations
on items of his own stock.
We can identify also the web developers viewpoint
and some of its concerns that could overlap some of
the merchants’ concerns:
A merchant shall be able to make sale operations
on items of his own stock.
Merchant’s sale operation shall be done in a se-
cured way using the https protocol.
4.2 Abstraction Levels in MoVAL
An abstraction level represents a level of details de-
fined by the system architect and included in the
MoVAL architecture in order to reduce the complex-
ity of the problem and to relegate some details, which
appear to be irrelevant in the first stages of the model-
ing process, to lower abstraction levels. For now, this
definition should be done in MoVAL manually by de-
scribing for each abstraction level its level of details
or what to be included in the views at this abstraction
level, and what to be relegated to other abstraction
levels.
For example, for the stock management system in-
troduced above, we could identify three levels of de-
tails for this model, which are:
The global data, presenting only the definition of
the main entities of the related view.
The stock data, presenting the stock elements in
the vision of the concerned actors.
The transaction data, in which we define also the
supported transactions of each view point imple-
menting this abstraction level.
From another side, an abstraction level is meant to
accept some specific formalisms, specifying the as-
sociated modeling languages and tools (UML, MDA,
AGM, etc ...), in which some participants in the de-
velopment process might define its associated rep-
resentations. Note that a formalism could be de-
pendent to a specific technology, called in this case
concrete formalism, like the class model formalism
of UML which is dependent to the object oriented
programming technology. Also, a formalism could
be independent of any technology like the use case
model formalism of UML, in which we can represent
a set of requirements formally and independently of
the adopted technology, in this case the formalism is
called abstract formalism.
Normally, an abstraction level can be eventually
consistent with a subset of the architecture’s defined
views but not necessarily all the views, what gives
birth to a set of architectural representations associ-
ated each to a specific abstraction level and aggregat-
ing together the views of MoVAL architecture.
4.3 Architectural Representations in
MoVAL
An architectural representation is a view and abstrac-
tion level dependent. It is a group of models repre-
senting a specific architectural view in a specific ab-
straction level. This architectural representation could
be considered by itself as a sub-system that could be
ENASE2013-8thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering
144
described and modeled, separately of all the architec-
tural description process, by a set of models. Archi-
tectural representations are illustrated in figure 1 by a
black point inside the model’s matrix.
In general, the views of a MoVAL architecture
do not have an isomorphism among them, so each
of them could have architectural representations as-
sociated to a subset of the architecture’s defined ab-
straction levels, not necessarily all of those abstrac-
tion levels, by the mean that each architectural view
could have a different number of architectural repre-
sentations, and each abstraction level would not be
necessarily associated to all of the defined architec-
tural views.
4.4 Links in MoVAL
In MoVAL approach, relations between architectural
representations are defined. They connect the archi-
tectural views among them. Those relations are rep-
resented via the Links. A link is a simple architectural
connector having some properties, like the source and
destination architectural representations, a semantic
role and a semantic link. It holds the dependency,
dominance and consistency rules that might be orga-
nized and described in the architectural description.
In MoVAL,two distinct categories of links are dis-
tinguished:
The Intra-View links, having the source and des-
tination architectural representations belonging to
the same architectural view.
The Inter-Views links, having the source and des-
tination architectural representations belonging to
two different architectural views.
4.5 MoVAL Meta-model
Actually, MoVAL meta-model extends the IEEE stan-
dard 1471-2000. Thus we have kept some definitions
like the definition of a system, architecture, architec-
tural description, stakeholder, viewpoint, view, con-
cern and model, and we have equally added some
other definitions like the definition of an abstraction
level, architectural representation, formalism, and
link.
A System, as it was defined in the IEEE standard
1471-2000, is not limited to individual applications
but it encompasses them to cover also the subsys-
tems, systems of systems and all kind of software in-
terests’ aggregations. A system always has different
categories of Stakeholders, which are the participants
in every phase of his life cycle. They could be indi-
viduals, teams or even organizations interested in this
system, like the system architects, developers, ana-
lysts, experts contributing in the system development,
users, etc. ...
Each of those stakeholders focuses on a specific
part of the system requirements saturating his inter-
ests. Hence, those interests of different stakeholders
are defined as different sets of Concerns overlapping
in certain cases and contradicting in other cases.
In order to be constructed, a system might be de-
composed to a set of Models representing each, for-
mally, a part of that system. This set of models and
the way they are related is called the system’s Archi-
tecture, described and documented in an Architectural
Description (AD) in order to allow different stake-
holders to understand the structure of the system.
Each AD comprises different Views (Section 4.1),
and each of these views conformsto a Viewpoint spec-
ifying the set of concerns that might be considered in
the view’s definition, and specifying also the candi-
date Formalisms that could be used in the model defi-
nition.
Normally, the viewpoint is not the only factor re-
stricting the candidate formalisms that could be used
in the model definition but also the abstraction level
(Section 4.2) for which this model belongs should ac-
cept the selected formalism.
In addition, to illustrate the multi-hierarchy, or the
multi-abstraction levels aspect of an architectural de-
scription in MoVAL, the hierarchy or the decomposi-
tion of an architectural view to different Architectural
Representations was defined, and those architectural
representations were associated to different abstrac-
tion levels and related one to the other via the Inta-
view Links, if the architectural representations belong
to the same view, and via the Inter-views Links, if the
architectural representations belong to two different
views (Section 4.4).
Figure 2 represents the proposed meta-model.
5 ANALYSIS
Table 1 presents an elicitation of ve main character-
istics of several approaches sharing similar purposes
with MoVALs approach.
The inter-views relations support column gives
idea about the considered approach, if it repre-
sents the relations that exist between the views,
and what types of relations it represents.
The stakeholder roles column defines the consid-
ered set of stakeholders for each approach.
The Fixed/Not Fixed views column indicates ei-
ther if the number of considered views in each ap-
OverviewofanApproachDescribingMulti-views/Multi-abstractionLevelsSoftwareArchitecture
145
Figure 2: Conceptual model of MoVAL
proach is fixed or not.
The hierarchy support column tells if each ap-
proach represents multiple levels of details/ ab-
straction levels/ hierarchy levels and gives a hint
about its support if exists.
Finally the methodology support column indi-
cates for each approach either it offers, or not, a
methodology or process to be applied on a real
case in order to obtain the resulting model or ar-
chitecture.
Actually, this table illustrates the fact that some
approaches do not represent the relations that may
exist between different viewpoints, marked as Not
Available (NA) in the table, and some other ap-
proaches admit the existence of some kind of relations
(overlapping relations in (Sommerville and Sawyer,
1997; Mullery, 1979) and consistency relations in
(Hilliard, 1999; Group, 2000; Rozanski and Woods,
2011)) but also do not represent them formally. Other
approaches represent special kinds of relations be-
tween views as in (Delugach, 1990), where they rep-
resent formally the dependency and overlapping rela-
tions between different views.
In addition, the hierarchy support column indi-
cates, for each approach, if it has support for hier-
archy levels, but unfortunately, as mentioned in table
1, all of those approaches do not give a definition for
such levels, except for (Dijkman et al., 2008) in which
authors have associated, for each viewpoint, a single
and specific abstraction level, and in (Mullery, 1979)
in which author have defined the steps in his approach
which hold in reality some kind of levels of details.
6 RELATED WORKS
LIMITATIONS
As mentioned in (Rozanski and Woods, 2011), us-
ing views and viewpoints to describe the architecture
of a system benefits the architecture definition pro-
cess in a number of ways that are: Separation of con-
cerns, Communication with stakeholder groups, Man-
agement of complexity and Improved developer focus.
However, some limitations remain when using exist-
ing view-based approaches. We can summarize some
of these limitations, which were solved in MoVAL, as
follows:
Needs to Move between Different Abstraction Lev-
els. Despite software architecture is defined as the
high-levelsystem structure, we assume that a soft-
ware architect should define views at different lev-
els of details. In fact, some stakeholders may set-
tle for an overview information, while others re-
quire detailed information and those whose needs
are between (i.e. require some details). So, the
software architect needs to think in terms of differ-
ent abstraction levels and to be capable to move
between abstraction levels. Actually, in all the
studied related works, an architect cannot specify
a view or one of its models in multiple abstraction
levels, however in MoVAL he could identify for
each view as many abstraction levels as he needs,
like the example mentioned in section 4.2.
Lack of an Architectural Description Process.
In almost all the studied approaches, except in
(Clements et al., 2002), it is unclear what the soft-
ware architect has to do to define the suitable ar-
chitectural description. This task is based mainly
ENASE2013-8thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering
146
Table 1: Existing works and their main characteristics.
Inter-Views
Relations
Support
Stakeholder
Roles
Fixed/Not Fixed
Views
Hierarchy
Support
Methodology
Support
(Finkelstein and
Fuks, 1989;
Robinson, 1990)
NA End user Not fixed NA Yes
(Delugach, 1990;
Nuseibeh et al.,
1994)
Dependency,
Overlapping
Development
participants, End
user
Not fixed NA Yes
(Sommerville
and Sawyer,
1997)
Admits
overlapping
Development
participants, End
user
Not fixed NA Yes
(Mullery, 1979) Admits
overlapping
Analyst, End user Not fixed Steps Yes
(Nassar, 2003) NA End user not fixed NA Yes
(Dijkman et al.,
2008)
Refinement,
Overlapping
Development
participants, End
user
Not fixed Single
abstraction level
per viewpoint
Yes
(Sowa and
Zachman, 1992)
NA Planner, Owner,
Designer, Builder
and
Subcontractor
Fixed (Data,
Function,
Network, People,
Time and
Motivation)
NA No
(Kruchten, 1995) NA Development
participants
Fixed (Scenario,
Logical,
Development,
Process and
Physical)
NA No
(Hilliard, 1999;
Group, 2000;
Rozanski and
Woods, 2011)
Admits
consistency
relationships
existence
Development
participants, End
user
Not fixed NA No
MoVAL Formal
consistency
relationships
Development
participants,
End user
Not fixed Multiple
abstraction
levels per
viewpoint
Yes
on his (her) experience and skills. So, MoVAL ap-
proach aims at defining an Architectural Descrip-
tion Process (ADP) which guides the software ar-
chitect while defining the software architectural
description. The ADP should be flexible, non-
constraining and iterative. Actually, MoVALs
ADP is out of this paper’s focus and won’t be pre-
sented.
Views Inconsistency. Using a number of Views to
describe a system inevitably brings inconsisten-
cies problems. So we need to achieve a cross-
view consistency within an architectural descrip-
tion, which is not offered by the majority of the
studied related works, but MoVAL has defined the
links (section 4.4) which hold the needed coher-
ence rules in order to solve those inconsistencies
problems.
7 CONCLUSIONS
This paper has presented a preliminary approach for
documenting intensive software systems architecture
based on views and abstraction levels. This approach
complies with the view-based approach of IEEE-1471
and aims at extending it in three different ways that
are: (1) providing the software architect means to de-
fine views at different levels of detail and to move be-
tween them; (2) defining relationships that solve the
inconsistencies between the architectural views; (3)
the specification of an architectural description pro-
cess which guides the architect while selecting perti-
nent views, documenting them and refining them at
different abstraction levels.
Actually, we are validating MoVALs methodol-
ogy or development process that will allow system
OverviewofanApproachDescribingMulti-views/Multi-abstractionLevelsSoftwareArchitecture
147
architects to build a rough and coherent multi-
views/multi-abstraction levels software architecture.
REFERENCES
Anwar, A., Dkaki, T., Ebersold, S., Coulette, B., and Nas-
sar, M. (2011). A formal approach to model compo-
sition applied to VUML. In Engineering of Complex
Computer Systems (ICECCS), 2011 16th IEEE Inter-
national Conference on, page 188197.
Anwar, A., Ebersold, S., Coulette, B., Nassar, M., and Kri-
ouile, A. (2010). A rule-driven approach for com-
posing viewpoint-oriented models. Journal of Object
Technology, 9(2):89114.
Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J.,
Little, R., Nord, R., and Stafford, J. (2002). A practi-
cal method for documenting software architectures.
da Rocha, E. S. Guidelines for business modeling elabora-
tion based on views from domain information.
Delugach, H. S. (1990). Using conceptual graphs to analyze
multiple views of software requirements.
Dijkman, R. M., Quartel, D. A. C., and van Sinderen, M. J.
(2008). Consistency in multi-viewpoint design of en-
terprise information systems. Information and Soft-
ware Technology, 50(7):737752.
Finkelstein, A. and Fuks, H. (1989). Multiparty specifica-
tion. In ACM SIGSOFT Software Engineering Notes,
volume 14, page 185195.
Finkelstein, A. and Sommerville, I. (1996). The view-
points FAQ. BCS/IEE Software Engineering Journal,
11(1):24.
Group, I. A. W. (September 2000). Ieee recommended prac-
tice for architectural description of software-intensive
systems. Technical report, Institute of Electrical and
Electronics Engineers, NY, USA.
Hilliard, R. (1999). Views and viewpoints in software sys-
tems architecture. In First Working IFIP Conference
on Software Architecture,WICSA, pages 13–24.
Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C.,
Lopes, C., Loingtier, J., and Irwin, J. (1997).
Aspect-oriented programming. In ECOOP’97Object-
Oriented Programming, pages 220–242.
Kramer, J. Abstraction in computer science $0 software
engineering: A pedagogical perspective.
Kruchten, P. (1995). The 4+ 1 view model of architecture.
Software, IEEE, 12(6):42–50.
Majumdar, D. and Swapan, B. (2010). Aspect Oriented Re-
quirement Engineering: A Theme Based Vector Ori-
entation Model. Journal of Computer Science, Info-
Comp, ?(?).
May, N. (2005). A survey of software architecture view-
point models. In Proceedings of the Sixth Aus-
tralasian Workshop on Software and System Architec-
tures, pages 13–24. Citeseer.
Medvidovic, N., Taylor, R. N., and Whitehead Jr, E. J.
(1996). Formal modeling of software architectures at
multiple levels of abstraction. ejw, 714:8242776.
Mili, H. and al (1999). View programming : Towards a
framework for decentralized development and execu-
tion of oo programs. In Proc. of TOOLS USA 99,
pages 211–221. Prentice Hall.
Mili, H., Sahraoui, H., Lounis, H., Mcheick, H., and Elkhar-
raz, A. (2006). Concerned about separation. Fun-
damental Approaches to Software Engineering, pages
247–261.
Monperrus, M., Beugnard, A., and Champeau, J. A defini-
tion of ”abstraction level” for metamodels.
Mullery, G. P. (1979). CORE-a method for controlled re-
quirement specification. In Proceedings of the 4th in-
ternational conference on Software engineering, page
126135.
Nassar, M. (2003). VUML: a viewpoint oriented UML ex-
tension. In Automated Software Engineering, 2003.
Proceedings. 18th IEEE International Conference on,
page 373376.
Nassar, M., Anwar, A., Ebersold, S., Elasri, B., Coulette,
B., and Kriouile, A. (2009). Code generation in
VUML profile: A model driven approach. In Com-
puter Systems and Applications, 2009. AICCSA 2009.
IEEE/ACS International Conference on, page 412419.
Nuseibeh, B., Kramer, J., and Finkelstein, A. (1994). A
framework for expressing the relationships between
multiple views in requirements specification. Software
Engineering, IEEE Transactions on, 20(10):760773.
Ossher, H. and al. (1995). Subject-oriented composition
rules. In OOPSLAS’95, pages 235–250.
Perry, D. and Wolf, A. (1992). Foundations for the study of
software architecture. ACM SIGSOFT Software Engi-
neering Notes, 17(4):40–52.
Regnell, B., Andersson, M., and Bergstrand, J. (1996). A
hierarchical use case model with graphical represen-
tation. In Engineering of Computer-Based Systems,
1996. Proceedings., IEEE Symposium and Workshop
on, page 270?277.
Robinson, W. N. (1990). Negotiation behavior during re-
quirement specification. In Software Engineering,
1990. Proceedings., 12th International Conference
on, page 268276.
Rozanski, N. and Woods, E. (2011). Software Systems Ar-
chitecture: Working with Stakeholders Using View-
points and Perspectives. Addison-Wesley.
Sommerville, I. (2007). Software Engineering. Interna-
tional Computer Science Series. Addison-Wesley.
Sommerville, I. and Sawyer, P. (1997). Viewpoints: prin-
ciples, problems and a practical approach to require-
ments engineering. Annals of Software Engineering,
3(1):101130.
Sowa, J. and Zachman, J. (1992). Extending and formal-
izing the framework for information systems architec-
ture. IBM systems journal, 31(3):590–616.
ENASE2013-8thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering
148