Ahmad Kheir
email: ahmad.elkheir@univ-nantes.fr

Hala Naja
email: hala.naja@ul.com.lb

Mourad Oussalah
email: mourad.oussalah@univ-nantes.fr

Kifah Tout
email: kifah.tout@ul.com.lb

Overview of an Approach Describing Multi-Views/Multi-Abstraction Levels Software Architecture

Keywords: Software Architecture, Viewpoints, Views, Abstraction Levels, Dependency, Consistency Rules

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 finally enhance the communication and harmony among different stakeholders.

INTRODUCTION

In large scale and complex systems, always different people are involved in the system development process and having for each of them different interests knowledge backgrounds and tools. Thus, these people, 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 complexity in the system's architecture and difficulty to cover the entire system's domain. As mentioned in [START_REF] Rozanski | Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives[END_REF], "a widely used approach is to attack the problem from different directions simultaneously. In this approach, the architectural description is partitioned into a number of separate views, each of which describes a separate aspect of the architecture." Informally, a view is an architectural design of a stakeholder's viewpoint that covers delicately all its interests and required functionalities, and represents them formally in a structured architecture. An abstraction level represents a level of details defined in order to treat the extra complexities retained after decomposing our system into multiple viewpoints, by relegating some viewpoints' details 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 abstraction 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 allowing 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 related to the views and abstraction levels fields are presented. Section 5 and 6 presents our comparative analysis and the deducted limitations of current solutions, respectively, in order to motivate the contribution 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.

Viewpoints are the perspectives of different people or stakeholders towards an information system [START_REF] Finkelstein | The viewpoints FAQ[END_REF]. Consequently, a view, which is a formal representation of an associated viewpoint, is an abstraction of the whole system's architecture 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 construction field and software systems implementation field.

Views in Requirements Engineering

One of the first and leading researchers that worked with viewpoint concept in requirements specification was A. Finkelstein in [START_REF] Finkelstein | Multiparty specification[END_REF], where he and Fuks proposed a formal model aiming to construct system's specifications through a dialog in which the viewpoint negotiate. Robinson also worked on the requirements specification through dialog [START_REF] Robinson | Negotiation behavior during requirement specification[END_REF], in 1990's and presented his tool, Oz, but he focused more on the representation of conflicting viewpoints and an automated way to produce resolutions. Meanwhile, H. Delugash [START_REF] Delugach | Using conceptual graphs to analyze multiple views of software requirements[END_REF]) was working on the representation of each viewpoint's requirements in a conceptual graph in order to merge them by analyzing those conceptual graphs and performing 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, complementary, contradiction) in requirements specification and have proposed a framework to describe those relationships. Finally, in 1997, Sommerville have contributed in this domain in [START_REF] Sommerville | Viewpoints: principles, problems and a practical approach to requirements engineering[END_REF]) by proposing, Preview, a model for requirements discovery, analysis and negotiation.

Views in Software Systems Modelling

Prior to the incomparable commonness of UML in software systems modeling field, Mullery has developed a method, called CORE, for requirements specification and design in 1979 [START_REF] Mullery | CORE-a method for controlled requirement specification[END_REF]. CORE is a modeling approach supported by diagrammatic notation which decompose the modeling process to many steps, and define for each of them a definition 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, ;[START_REF] Nassar | VUML: a viewpoint oriented UML extension[END_REF]. [START_REF] Nassar | VUML: a viewpoint oriented UML extension[END_REF], 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 [START_REF] Nassar | Code generation in VUML profile: A model driven approach[END_REF], 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 [START_REF] Anwar | A rule-driven approach for composing viewpoint-oriented models[END_REF][START_REF] Anwar | A formal approach to model composition applied to VUML[END_REF] and included the attributed graphs in order to reach this goal. Also one of the important works done in this field was [START_REF] Dijkman | Consistency in multi-viewpoint design of enterprise information systems[END_REF] 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 viewpoints and defining for each viewpoint its associated level of abstraction for its basic concepts. In this work they focused on the definition of consistency relationships between the views.

Views in Software Architecture

In Software Architecture, various models have been proposed of how to create a documentation (i.e. an architectural description) by the separation of concerns. Each model describes a set of viewpoints and identifies the set of concerns that each of them address. The different models cover the same software architecture domain, including the associated structural, organizational, business and technological environment. The concept of Views appears in one of the earliest papers, Perry and Wolf's classic [START_REF] Perry | Foundations for the study of software architecture[END_REF] on Software Architecture in the early 1990s. In [START_REF] Sowa | Extending and formalizing the framework for information systems architecture[END_REF], the approach presents an extensive set of constructs called columns which is very similar to views. In 1995, Philippe Krichten proposed four different Views [START_REF] Kruchten | The 4+ 1 view model of architecture[END_REF] of a system and the use of a set of scenarios (use cases) to check their correctness. In [START_REF] Hilliard | Views and viewpoints in software systems architecture[END_REF], the author 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 application, a viewpoint language. This study was the basis of the IEEE Standard 1471 [START_REF] Group | Ieee recommended practice for architectural description of software-intensive systems[END_REF] which has formalized concepts used in Software Architecture and brought some standardization of terminology used in this field. It recognized the importance of Views in architectural description and adopted the Viewpoint concept defined earlier in [START_REF] Hilliard | Views and viewpoints in software systems architecture[END_REF]. 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 analysis. 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 [START_REF] Rozanski | Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives[END_REF], the authors propose a Viewpoint Catalogue for Information Systems, extending the 4+1 set of viewpoints identified by Kruchten [START_REF] Kruchten | The 4+ 1 view model of architecture[END_REF] comprising 6 core viewpoints including : the Functional, Information, Concurrency Development, Deployment and Operational. • In [START_REF] Clements | Guidelines for business modeling elaboration based on views from domain information[END_REF], 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 realworld projects. • the valuable survey done in [START_REF] May | A survey of software architecture viewpoint models[END_REF] compares between several view-based models and tries to find out the correspondencies between the different views proposed and the divergence between them. It proposes an optimum framework coverage encompassing a viewpoint set selected from different models with the greatest coverage of the framework concepts. The limitation of this approach is that despite the selected views are not independent, no connections or relationships are defined between views.

Views in Software Development

In Software Development field, the Aspect-oriented development techniques consider that a number of software development concerns could not be handled 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 [START_REF] Mili | Concerned about separation. Fundamental Approaches to Software Engineering[END_REF]. In this area, several methods are proposed :

• the Subject-Oriented Programming (SOP) [START_REF] Ossher | Subject-oriented composition rules[END_REF] technique addresses the functional requirements. It views object oriented applications as the composition of several application slices representing separate functional domains. Each slice called subject consists of a selfcontained, object-oriented program, with its own class hierarchy. Then, a composition language is defined allowing the composition of class hierarchies (subjects). • the Aspect-Oriented programming (AOP) technique, such in [START_REF] Kiczales | Aspect-oriented programming[END_REF] and (Majumdar and Swapan, 2010), addresses the nonfunctional requirements, including architectural aspects, error handling, security, distribution, persistence, etc. It defines aspect as an implementation of a concern that pertain to several objects in a collaboration. An aspect is a code module addressing specific concern and that cross-cut various components in an application. • the View-Oriented programming technique [START_REF] Mili | View programming : Towards a framework for decentralized development and execution of oo programs[END_REF] considers each object of an application as a set of core functionalities available, directly 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 organization and complexity resolution advantages.

HISTORY OF ABSTRACTION LEVELS

Abstraction levels is a core concept in software engineering, 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 different levels of details (i.e. abstraction levels) according to the purpose.

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 [START_REF] Regnell | A hierarchical use case model with graphical representation[END_REF] 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 similar 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 [START_REF] Medvidovic | Formal modeling of software architectures at multiple levels of abstraction[END_REF], authors have proposed a software architecture's modeling process of component based architectures, composed of four modeling process abstraction levels or, actually, four modeling layers, which are: architectural components specification, 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 upper abstraction level and proposed splitting rules that are based on the inheritance and specialization relationships of the meta-model.

MoVAL APPROACH

MoVAL (Model, View, Abstraction level) is an architectural modeling approach that comply to the IEEE recommended practice for architectural descriptions [START_REF] Group | Ieee recommended practice for architectural description of software-intensive systems[END_REF] with some additions in order to assist the system's architect solving some types of complexities that was not been treated in the existing approaches, 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 development process independently of the adopted development technology. Thus, the viewpoints concept was involved in order to reduce the system's complexities 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 levels, and to allow other participants in the development process to move between those abstraction levels according to the purpose of the current task. Hence, the main benefits of MoVAL is to allow system architects to solve more efficiently the complexity 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 holding the coherence constraints; and finally enhance the communication and harmony among different stakeholders 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 between two view's representations, either belonging to two different views and the same abstraction level (interviews 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 abstraction level defined for this model. In reality, a view of the model does not have necessarily representations 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 levels defined by the architect, depending on the system'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 application domain, and there is no defined mechanisms offered in MoVAL helping architects to determine the architectural views and abstraction levels.

Views in MoVAL

A view is a representation of the entire target system considering a specific sub-set of the system's concerns that are directly related to the view's associated viewpoint. This viewpoint could be considered as a specification of the conventions for constructing 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 associated stakeholders and its associated requirements or concerns. Those concerns, as defined by Sommerville in [START_REF] Sommerville | Software Engineering[END_REF], as the statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Actually, even though each viewpoint (consequently 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 considered 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 developer's 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 secured way using the https protocol.

Abstraction Levels in MoVAL

An abstraction level represents a level of details defined by the system architect and included in the MoVAL architecture in order to reduce the complexity of the problem and to relegate some details, which appear to be irrelevant in the first stages of the modeling process, to lower abstraction levels. For now, this definition should be done in MoVAL manually by describing 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 introduced above, we could identify three levels of details 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 implementing this abstraction level.

From another side, an abstraction level is meant to accept some specific formalisms, specifying the associated modeling languages and tools (UML, MDA, AGM, etc ...), in which some participants in the development process might define its associated representations. Note that a formalism could be dependent 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 associated each to a specific abstraction level and aggregating together the views of MoVAL architecture.

Architectural Representations in MoVAL

An architectural representation is a view and abstraction level dependent. It is a group of models repre-senting a specific architectural view in a specific abstraction level. This architectural representation could be considered by itself as a sub-system that could be described and modeled, separately of all the architectural description process, by a set of models. Architectural 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 associated to a subset of the architecture's defined abstraction levels, not necessarily all of those abstraction levels, by the mean that each architectural view could have a different number of architectural representations, and each abstraction level would not be necessarily associated to all of the defined architectural views.

Links in MoVAL

In MoVAL approach, relations between architectural representations are defined. They connect the architectural views among them. Those relations are represented 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 organized and described in the architectural description.

In MoVAL, two distinct categories of links are distinguished:

• The Intra-View links, having the source and destination architectural representations belonging to the same architectural view.

• The Inter-Views links, having the source and destination architectural representations belonging to two different architectural views.

MoVAL Meta-model

Actually, MoVAL meta-model extends the IEEE standard 1471-2000. Thus we have kept some definitions like the definition of a system, architecture, architectural description, stakeholder, viewpoint, view, concern 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 subsystems, systems of systems and all kind of software interests' aggregations. A system always has different categories of Stakeholders, which are the participants in every phase of his life cycle. They could be individuals, teams or even organizations interested in this system, like the system architects, developers, analysts, experts contributing in the system development, users, etc. ... Each of those stakeholders focuses on a specific part of the system requirements saturating his interests. 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 decomposed to a set of Models representing each, formally, a part of that system. This set of models and the way they are related is called the system's Architecture, described and documented in an Architectural Description (AD) in order to allow different stakeholders to understand the structure of the system. Each AD comprises different Views (Section 4.1), and each of these views conforms to a Viewpoint specifying the set of concerns that might be considered in the view's definition, and specifying also the candidate Formalisms that could be used in the model definition.

Normally, the viewpoint is not the only factor restricting 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 accept the selected formalism.

In addition, to illustrate the multi-hierarchy, or the multi-abstraction levels aspect of an architectural description in MoVAL, the hierarchy or the decomposition of an architectural view to different Architectural Representations was defined, and those architectural representations were associated to different abstraction levels and related one to the other via the Intaview 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.

ANALYSIS

Table 1 presents an elicitation of five main characteristics of several approaches sharing similar purposes with MoVAL's approach.

• The inter-views relations support column gives idea about the considered approach, if it represents the relations that exist between the views, and what types of relations it represents.

• The stakeholder roles column defines the considered set of stakeholders for each approach. • The Fixed/Not Fixed views column indicates either if the number of considered views in each approach is fixed or not.

• The hierarchy support column tells if each approach represents multiple levels of details/ abstraction levels/ hierarchy levels and gives a hint about its support if exists.

• Finally the methodology support column indicates 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 architecture.

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 approaches admit the existence of some kind of relations (overlapping relations in [START_REF] Sommerville | Viewpoints: principles, problems and a practical approach to requirements engineering[END_REF][START_REF] Mullery | CORE-a method for controlled requirement specification[END_REF] and consistency relations in [START_REF] Hilliard | Views and viewpoints in software systems architecture[END_REF][START_REF] Group | Ieee recommended practice for architectural description of software-intensive systems[END_REF][START_REF] Rozanski | Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives[END_REF]) but also do not represent them formally. Other approaches represent special kinds of relations between views as in [START_REF] Delugach | Using conceptual graphs to analyze multiple views of software requirements[END_REF], where they represent formally the dependency and overlapping relations between different views. In addition, the hierarchy support column indicates, for each approach, if it has support for hierarchy levels, but unfortunately, as mentioned in table 1, all of those approaches do not give a definition for such levels, except for [START_REF] Dijkman | Consistency in multi-viewpoint design of enterprise information systems[END_REF] in which authors have associated, for each viewpoint, a single and specific abstraction level, and in [START_REF] Mullery | CORE-a method for controlled requirement specification[END_REF] in which author have defined the steps in his approach which hold in reality some kind of levels of details.

RELATED WORKS LIMITATIONS

As mentioned in [START_REF] Rozanski | Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives[END_REF], using views and viewpoints to describe the architecture of a system benefits the architecture definition process in a number of ways that are : Separation of concerns, Communication with stakeholder groups, Management of complexity and Improved developer focus. However, some limitations remain when using existing view-based approaches. We can summarize some of these limitations, which were solved in MoVAL, as follows:

• Needs to move between different abstraction levels : Despite software architecture is defined as the high-level system structure, we assume that a software architect should define views at different levels of details. In fact, some stakeholders may settle for an overview information, while others require detailed information and those whose needs are between (i.e. require some details). So, the software architect needs to think in terms of different 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 [START_REF] Clements | Guidelines for business modeling elaboration based on views from domain information[END_REF], it is unclear what the software architect has to do to define the suitable architectural description. This task is based mainly • Views Inconsistency: Using a number of Views to describe a system inevitably brings inconsistencies problems. So we need to achieve a crossview consistency within an architectural description, 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.

CONCLUSION

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 define views at different levels of detail and to move between them;

(2) defining relationships that solve the inconsistencies between the architectural views; (3) the specification of an architectural description process which guides the architect while selecting pertinent views, documenting them and refining them at different abstraction levels. Actually, we are validating MoVAL's methodology or development process that will allow system architects to build a rough and coherent multi-views/multiabstraction levels software architecture.

Figure 1 :

 1 Figure 1: Matrix of the MoVAL model

Figure 2 :

 2 Figure 2: Conceptual model of MoVAL

Table 1 :

 1 Existing works and their main characteristics. her) experience and skills. So, MoVAL approach aims at defining an Architectural Description Process (ADP) which guides the software architect while defining the software architectural description. The ADP should be flexible, nonconstraining and iterative. Actually, MoVAL's ADP is out of this paper's focus and won't be presented.

		Inter-Views	Stakeholder	Fixed/Not Fixed	Hierarchy	Methodology
		Relations	Roles	Views	Support	Support
		Support
	(Finkelstein and	NA	End user	Not fixed	NA	Yes
	Fuks, 1989;
	Robinson, 1990)
	(Delugach, 1990;	Dependency,	Development	Not fixed	NA	Yes
	Nuseibeh et al.,	Overlapping	participants, End
	1994)		user
	(Sommerville	Admits	Development	Not fixed	NA	Yes
	and Sawyer,	overlapping	participants, End
	1997)		user
	(Mullery, 1979)	Admits	Analyst, End user	Not fixed	Steps	Yes
		overlapping
	(Nassar, 2003)	NA	End user	not fixed	NA	Yes
	(Dijkman et al.,	Refinement,	Development	Not fixed	Single	Yes
	2008)	Overlapping	participants, End		abstraction level
			user		per viewpoint
	(Sowa and	NA	Planner, Owner,	Fixed (Data,	NA	No
	Zachman, 1992)		Designer, Builder	Function,
			and	Network, People,
			Subcontractor	Time and
				Motivation)
	(Kruchten, 1995)	NA	Development	Fixed (Scenario,	NA	No
			participants	Logical,
				Development,
				Process and
				Physical)
	(Hilliard, 1999;	Admits	Development	Not fixed	NA	No
	Group, 2000;	consistency	participants, End
	Rozanski and	relationships	user
	Woods, 2011)	existence
	MoVAL	Formal	Development	Not fixed	Multiple	Yes
		consistency	participants,		abstraction
		relationships	End user		levels per
					viewpoint
	on his (


Ahmad Kheir
email: ahmad.elkheir@univ-nantes.fr

Mourad Oussalah
email: mourad.oussalah@univ-nantes.fr

Hala Naja
email: hala.naja@ul.edu.lb

Hierarchical Multi-Views Software Architecture

Keywords: Software architecture, Views, Hierarchy levels, Consistency I

Software design and development hold so many inconsistencies when it comes to build composable and scalable structures. However, software architectures could be an efficient solution if considered with additional features like the composition of such architectures by linking different hierarchized views formally together. Thus, this paper presents a new contribution of a multi-views/multi-hierarchy software architecture that is consistent with the ISO/IEC/IEEE 42010 standard, and that presents a way for defining formally the consistencies between its different views and hierarchy levels.

INTRODUCTION

Software architectures have contributed effectively in complex and distributed software systems development. Normally, there are two principles, which have made the software architectures' contribution obvious and indispensable. First, it allows the architect to model the structure and the behavior of the system simultaneously. Second, it offers the architect the base to build multihierarchy based models.

In fact, coherent and well organized software architecture would enhance some crucial system properties like the reliability, consistency, and scalability. However, the lack of such architectures may limit those systems' adaptability, evolution, and consequently their life cycle, due to the incapability of modifying or expanding the stakeholders' requirements.

This paper presents a Model, View and Abstraction Level based software architecture (MoVAL), a multi-views and multi-hierarchy software architecture, which complies with the IEEE standard 42010-2011 [START_REF]Systems and software engineering --Architecture description[END_REF] and is based on the construction of multi-views models having for each of their views a hierarchy of levels.

Actually, the concept of viewpoint was present in many fields of software engineering domain. Indeed, it was introduced in requirements engineering by A. Finkelstein [START_REF] Finkelstein | Multiparty specification[END_REF] in 1989 opening the way for other valuable works in this field like in [START_REF] Nuseibeh | A framework for expressing the relationships between multiple views in requirements specification[END_REF] and in [START_REF] Sommerville | Viewpoints: principles, problems and a practical approach to requirements engineering[END_REF]. Also, the viewpoint concept was existing in software modeling, implicitly in some cases like in the unified modeling language (UML), where each diagram type has an implicit viewpoint, and explicitly in other studies like in the View-based UML extension (VUML) [START_REF] Nassar | VUML: a Viewpoint oriented UML Extension[END_REF], where an explicit representation of different viewpoints in a single multi-views class diagram is proposed. Also, the software implementation field recognized the utility of viewpoint concept. Indeed, different development paradigms encapsulate the viewpoint concept, like the aspect oriented [START_REF] Majumdar | Aspect Oriented Requirements Engineering: A Theme Based Vector-Orientation Model[END_REF], subject oriented development paradigms [START_REF] Ossher | Subject-oriented composition rules[END_REF] and the view-based programming technique [START_REF] Mili | View programming for decentralized development of OO programs[END_REF], which define explicitly different views in a single model. In addition, most of the related works done in the field of software architecture like the 4+1 View Model [START_REF] Kruchten | The 4+ 1 view model of architecture[END_REF] and the Views and Beyond [START_REF] Clements | A practical method for documenting software architectures[END_REF] approaches, have defined multi-views software architecture. However they did not provided any type of hierarchy for their views in order to reduce their complexities, nor they defined formally some consistency rules between different views of an architecture in order to conserve the robustness of that architecture and its ability to evolve while the stakeholders' requirements evolve. A complete survey on related works and a fruitful analysis of their limitations was presented in a previous study [START_REF] Kheir | Overview of an Approach Describing Multi-Views/Multi-Abstraction Levels Software Architecture[END_REF], but we can summarize those limitations in three main points: the views inconsistencies, the need to move between different abstraction levels, and the lack of a complete architectural description process.

In light of the related works study, MoVAL's motivations and goals were made clear. Actually, there are two main goals that were intended in this approach. The first goal is to propose a multi-views software architecture defining for each view a multi-levels hierarchy aiming to minimize software systems complexity per modeling entity. The second goal addressed in this approach, is to define formally the relationships that may exist between different views of a model, and also between different hierarchy levels inside a given view.

This paper is organized as follows: Section II presents in details our contribution. Then, the proposed approach is illustrated by a case study in Section III. Finally, Section IV concludes the paper.

II. MOVAL

In MoVAL, a model is conceptualized via a matrix as illustrated in Figure 1. The columns of the matrix represent the views of the model, while the lines represent its abstraction levels, which are the first level of the views' hierarchy detailed further in this paper. Hence, the lines and columns of the matrix illustrate two distinct structuring types defined in MoVAL. The columns illustrate the vertical structuring referring to different views of the same model, and the lines illustrate the horizontal structuring referring to the hierarchy levels defined in the model and associated to its views.

Note that model's matrix, in some trivial cases where the architect decides to create only one view for the model, and decide to represent this unique view in a single abstraction level, could be reduced to a single element.

A. Model View

A model view in MoVAL, or simply a view, is a representation of this model considering, from one side, a set of the development process' aspects, and from another side certain problems associated to a specific category of stakeholders or a group of categories of stakeholders. Those development aspects and problems are grouped in a separate entity, named viewpoints. In general, every stakeholder needs to express his interests via some appropriate semantics, syntax, and tools, called formalisms. For example, a database administrator needs to use the entityrelationship diagrams (ERDs) and the appropriate tools in order to model his database in a given phase. Thus, a viewpoint also defines the formalisms that shall be used afterwards to model the inherent views. Hence, each view must be associated to a specific viewpoint, which should be either predefined like the physical, structural, and behavioral viewpoints, or customized based on the application domain like the thermic view in an automobile construction system.

B. View's Hiearachy Level

MoVAL approach has defined a hierarchy of levels for each view, in order to describe it formally and appropriately in each step of the development process.

1) Abstraction Level

An abstraction level is a representation of a view considered at a specific stage of the system lifecycle. Eventually, several abstraction levels could be considered on the same view, and then linked together by higher/lower relationships. In fact, for the same view, an abstraction level AL1 is higher than another abstraction level AL2 (resp. AL2 is lower than AL1) if AL1 defines relevant requirements in a given stage of the system lifecycle leaving out some other requirements and relegating them to AL2 in a more advanced stage.

For a given view, an abstraction level must use appropriate formalisms that are implied by the associated viewpoint.

In general, a view could have more than one abstraction level having the same inherent requirements as long as they have different formalisms. Actually, in this case the transition from one abstraction level of a view to another abstraction level in the same view conserving the same inherent requirements and changing the formalism, could indicate the transition from a stage of the software lifecycle to another more advanced stage.

Note that it is not mandatory to have always an isomorphism between different views of a model, by the fact that it is not mandatory to have each abstraction level associated to all the views of the model, as illustrated in Figure 1.

2

) Description Level

The second type of hierarchy levels of a view is the description level. This type of hierarchy levels allows the architect to describe the same abstraction level of a specific view and the same inherent requirements while providing multiple descriptions having different granularity levels.

Here also, the description levels of the same abstraction level are linked together by higher/lower relationships. So, a description level DL1 is higher than another description level DL2 (resp. DL2 is lower than DL1) if DL1 lies on the same requirements as DL2 but adds more details in order to make easier the understanding of DL2's requirements. In other words, DL1 is at a higher granularity level than DL2.

Actually, the difference between this type of hierarchy levels and the abstraction levels, resides in the fact that a lower abstraction level allows the architect to go straightforward into more advanced stages of the system lifecycle relatively to the higher abstraction level, in general, by providing more requirements. However, a lower description level does not allow the architect to provide additional requirements of a specific view, but it allows him to describe more clearly its previous description level by providing more description details.

C. Link

The links are structural elements defined in MoVAL in order to express formally the relations between different hierarchy levels and conserve model's consistency. Those links are grouped in four categories:  Inter-views link, defining the relation among a couple of distinct hierarchy levels belonging to two different views.  Inter-levels link, defining a similar relation to that defined by the inter-views link, except that the hierarchy levels here belong to the same view.  Intra-level link, defining an internal relation between elements of the same hierarchy level.  User links; this category of links is a special category.

A user link always inherits from one of the three previous categories, then defines some additional structural or semantic properties and attributes (see the case study in Section IV). Actually, the purpose of this category of links was to enhance the modularity and reusability of software architecture's structural elements.

In order to formalize the links, MoVAL has attributed four main properties to define them:  Source: based on the semantic role of a link, its source could be either an abstraction or a description level of a view.  Destination: similarly, the type of the destination of a link depends on its semantic role. Note that always the source and destination of a link must have the same type.  Semantic role: the semantic role of a link defines the nature or the purpose behind the relation between the source and destination hierarchy levels. It is firmly related to the category of the link and the type of its source and destination hierarchy levels. Hence, MoVAL has defined three main semantic roles: o Connection, specifying some consistency rules between elements of the same hierarchy levels. Note that this semantic role could be used only for intra-level links. o Composition, specifying the composition of elements of the source level in the destination level, which is in this case the lower level. This role could be used in case of inter-levels or inter-views links.

o Expansion, representing the description of elements of the source level in the destination level, which is in this case the lower level, respecting the abstraction levels of the source and destination. Actually, this semantic role is dedicated for the representation of relations between abstraction levels only and could be used in both cases of inter-levels or inter-views links. Normally, composition and expansion roles are adequate when the architect adopts a Top-Down development strategy. However, when the Bottom-Up strategy is adopted, composition and expansion could be replaced by other roles having inverse semantics, which are respectively the aggregation and compression semantic roles.  Semantic link, which includes a set of semantic attributes aiming to implement the desired semantics, chosen in advance by architect via the semantic role: o Dependence, declaring that the destination hierarchy level depends for its existence on the source hierarchy level. o Predominance, which declares semantics symmetric to those declared by the dependence attribute. o Coherence, specifying that some consistency rules should be considered and respected in the destination hierarchy level based on the source level parameters, in order to conserve the coherence of the model. Those consistency rules could be expressed via a given constraint language like OCL.

D. MoVAL Meta-Model

MoVAL meta-model is consistent with the ISO/IEC/IEEE 42010 standard. Thus, some elements have kept their definitions presented in the IEEE standard, like the definition of a system, architecture, architectural description, stakeholder, viewpoint, view, and concern. However, some other elements were given new definitions like the model, and others have been introduced like the abstraction and description level, formalism, and link. Figure 3 presents the proposed meta-model.

A System, as it was defined in the IEEE standard, is not limited to individual applications but it encompasses them to cover also the subsystems, systems of systems and all kind of software interests' aggregations. A system always has different categories of Stakeholders, which are the participants in every phase of his life cycle. They could be individuals, teams or even organizations interested in this system, like the system architects, developers, analysts, experts contributing in the system development, users, etc.

Each of those stakeholders focuses on a specific part of the system requirements saturating his interests. Hence, those interests of different stakeholders are defined as different sets of Concerns overlapping in certain cases and contradicting in other cases. Simultaneously, a system is associated to an Architecture, documented and described via an Architectural Description (AD). An AD is composed of a set of Views governed by a set of Viewpoints specifying and grouping the inherent concerns and formalisms that should be used for the development of the views. Those views are represented in a hierarchy of Abstraction and Description Levels. Also, each viewpoint and each abstraction level of a model offers a set of Formalisms that could be used afterward to model the associated view at each of its abstraction levels. Those formalisms define actually the lexical and syntax elements that could be used.

III. CASE STUDY

In order to clarify MoVAL concepts and confirm its contribution and utility in software engineering and complex systems development field, a case study will be represented in this section.

This case study consists on an eCommerce WebApp, in which multiple stores would be registered and given virtual spaces to expose their products for sale.

In this context, only three viewpoints are considered (due to space limitation issue):  Physical viewpoint, which represents the view of the system deployer. Thus, it manipulates the hardware and software resources used for the deployment of such systems. Actually, this viewpoint is predefined in  Site administrator viewpoint, representing the system as seen by the system administrator and considering his requirements. Three formalisms could be associated to this viewpoint, which are the use case, sequence, and class diagrams of UML. In addition, the associated view could be defined in two abstraction levels illustrated in figures 6 and 7, respectively.  Store administrator viewpoint, representing the system as seen by the registered store administrator. This viewpoint will be associated to the same formalisms associated to the previous viewpoint, also the associated view will be defined in two abstraction levels illustrated in figures 8 and 9. In general, in order to improve the models' consistency, the system architect must create different links between different views and hierarchy levels of this model. For this reason, the abstraction levels of the Site Administrator view could be associated to the abstraction levels of the Store Administrator view, as they share the same level of details. Thus, for the remaining of this section, the higher and lower abstraction levels, associated to this couple of views, will be referred by the First Functional Level and the Second Functional Level, respectively. Now, three links, among others, could be derived for this case study:  Inter-levels link having the First Functional Level of the Site Administrator view as source hierarchy level, and the Second Functional Level of the same view as destination. This link is a composition link expressing in his coherence semantic attribute the composition of the Accounting Service in the source by the Site Accounting Service and the Store Accounting Service in the destination.  Inter-levels link having the First Functional Level of the Site Administrator view as source and the Second Functional Level of the same view as destination. This link is an expansion link expressing in his coherence semantic attribute the expansion of the Internal Services of the source level to the Log Service and the Backup Service in the destination.  User link, named Reuse Link, created by the architect as an inter-views link defining the reusability of a component of the source level in the destination level. Hence, a Reuse link could be defined having the Second Functional Level of the Site Administrator view as source and the Second Functional Level of the Store Administrator view as destination. This link expresses the reusability of the Reporting Service in both of the source and destination levels.

IV. CONCLUSION

This paper has presented a new contribution of multiviews and multi-hierarchy software architecture, named MoVAL, defining and modeling independently, for each stakeholder, its inherent concerns in a separate multi-levels view and providing the necessary definitions to combine and link all those views and hierarchy levels in order to guaranty a complete consistency between different parts of the resulting architecture.

In fact, MoVAL has given every stakeholder the space to model his interests and the tools to represent the possible interferences that may exist with other interests of other stakeholders, what should decrease significantly the number of unexpected executions or the number of bugs of the system, and increase consequently the system's reliability.

From another side, MoVAL has given the software architect the tools to link different semantically related views or abstraction levels via the architectural links, what would enhance the model coherence because of the representation of every constraint that may exist between different views or abstraction levels. Simultaneously, this organization and coherence make the addition of other user requirements much simpler, and consequently increase model's scalability.

Actually, MoVAL is in the prototyping phase. A specific framework encapsulating the all the tools and features needed to apply MoVAL's concepts will be implemented and validated.

ACKNOWLEDGMENT

This material is based upon work supported by the Lebanese association for scientific research (LASeR), the Lebanese council for scientific research (CNRS), the French association CAPACITES, the University of Nantes, and finally the Lebanese University.

Figure 1 .

 1 Figure 1. Conceptual Matrix of a MoVAL model.

Figure 2 .

 2 Figure 2. Views and hierarchy levels.

Figure 2

 2 Figure2represents this hierarchy, which consists of two types of levels, the abstraction levels, which are represented in the figure via ovals. Also, under each abstraction level several description levels are represented via correlated rectangles.1) Abstraction LevelAn abstraction level is a representation of a view considered at a specific stage of the system lifecycle. Eventually, several abstraction levels could be considered on the same view, and then linked together by higher/lower relationships. In fact, for the same view, an abstraction level AL1 is higher than another abstraction level AL2 (resp. AL2 is lower than AL1) if AL1 defines relevant requirements in a given stage of the system lifecycle leaving out some other requirements and relegating them to AL2 in a more advanced stage.For a given view, an abstraction level must use appropriate formalisms that are implied by the associated viewpoint.In general, a view could have more than one abstraction level having the same inherent requirements as long as they have different formalisms. Actually, in this case the transition from one abstraction level of a view to another abstraction level in the same view conserving the same inherent requirements and changing the formalism, could indicate the transition from a stage of the software lifecycle to another more advanced stage.Note that it is not mandatory to have always an isomorphism between different views of a model, by the fact that it is not mandatory to have each abstraction level associated to all the views of the model, as illustrated in Figure1.2) Description LevelThe second type of hierarchy levels of a view is the description level. This type of hierarchy levels allows the architect to describe the same abstraction level of a specific view and the same inherent requirements while providing multiple descriptions having different granularity levels.Here also, the description levels of the same abstraction level are linked together by higher/lower relationships. So, a description level DL1 is higher than another description level DL2 (resp. DL2 is lower than DL1) if DL1 lies on the same

Figure 3 .

 3 Figure 3. Conceptual model of MoVAL

  MoVAL and considered associated to a single formalism, which is the deployment diagram of UML. The associated view could be represented in a hierarchy of one abstraction level and one description level mentioned respectively in figures 4 and 5.

Figure 4 .

 4 Figure 4. Physical view abstraction level.

Figure 5 .

 5 Figure 5. Physical view description level

Figure 6 .

 6 Figure 6. First abstraction level of the Site admin view.

Figure 7 .

 7 Figure 7. Second abstraction level of the Site admin view.

Figure 8 .

 8 Figure 8. First abstraction level of the Store admin view.

Figure 9 .

 9 Figure 9. Second abstraction level of the Store admin view.

Figure 10 .

 10 Figure 10. Conceptual matrix of the eCommerce model.

Figure 10

 10 Figure 10 represents the conceptual matrix of the eCommerce case study.

Copyright (c) IARIA, 2013. ISBN: 978-1-61208-304-9

Copyright (c) IARIA, 2013. ISBN: 978-1-61208-304-9 ICSEA 2013 : The Eighth International Conference on Software Engineering Advances


Ahmad Kheir
email: ahmad.elkheir@univ-nantes.fr

Hala Naja
email: hala.naja@ul.edu.lb

Mourad Oussalah
email: mourad.oussalah@univ-nantes.fr

Kifah Tout
email: kifah.tout@ul.edu.lb

From Viewpoints and Abstraction Levels in Software Engineering Towards Multi-Viewpoints/Multi-Hierarchy in Software Architecture

Keywords: Software Architecture, Viewpoints, Views, Abstraction Levels, Dependency, Consistency Rules

Viewpoints concept could be considered one of the major concepts introduced in the software engineering domain in order to enhance the architectural organization of complex systems by separating its concerns. Despite his ultimate importance, this concept must be evolved and hierarchized in order to allow the jump of software architectures field from its current range of complexity coverage and resolution to a new range more secure, more standardized and more appropriate with the current industrial needs. This paper begins with a survey of the role and usage of the viewpoints, and the hierarchy definition by abstraction levels concepts. Then presents a small but complete analysis of the related works and their limitations, in order to conclude with a proposition of current work on a multi-viewpoints and multi-abstraction levels software architecture.

INTRODUCTION

Complex systems always include a large amount of requirements, associated to different categories of stakeholders that must be managed in coherent software architecture. Furthermore, each stakeholder adopts his own look to the system, represented via a specific viewpoint that is in most cases complex and hard to be covered entirely in the system architecture. Informally, a view is an architectural design of a stakeholder's viewpoint that covers delicately all its interests and required functionalities, and represents them formally in a structured architecture. An abstraction level represents a level of details defined in order to treat the extra complexities retained after decomposing a system into multiple viewpoints, by relegating some viewpoints' details which appear to be irrelevant in the first stages of the modeling process to lower abstraction levels, so the architect could zoom into a specific viewpoint to the desired level of details. This paper presents, in sections 2 and 3, a survey

The work described in this paper is partially supported by a grant from National Council for Scientific Research (Lebanon).

dealing with the evolution of role and usage of two major concepts in software engineering, which are respectively the views and abstraction levels. Then an overview of an architectural modeling approach called MoVAL is suggested in section 4. In MoVal, both views and abstraction levels concepts are integrated allowing the architect to build robustly a multiviews and multi-granularities software architectures. Section 5 and 6 presents a comparative analysis and the deducted limitations of current solutions. Section 7 concludes.

HISTORY OF VIEWS

A view is a formal representation of a stakeholder or a group of stakeholders' viewpoint. This notion has been introduced in four main fields of the software engineering domain, which are: requirements engineering, systems modeling, software architecture and software development.

Views in Requirements Engineering

One of the first and leading researchers that worked with viewpoint concept in requirements specification was A. Finkelstein in [START_REF] Finkelstein | Multiparty specification[END_REF], where he and Fuks proposed a formal model aiming to construct system's specifications through a dialog in which the viewpoint negotiate. Robinson also worked on the requirements specification through dialog [START_REF] Robinson | Negotiation behavior during requirement specification[END_REF], in 1990's and presented his tool, Oz, but he focused more on the representation of conflicting viewpoints and an automated way to produce resolutions. Meanwhile, H. Delugach [START_REF] Delugach | Using conceptual graphs to analyze multiple views of software requirements[END_REF] was working on the representation of each viewpoint's requirements in a conceptual graph in order to merge them by analyzing those conceptual graphs and performing 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, complementary, contradiction) in requirements specification and have proposed a framework to describe those relationships. Finally, in 1997, Sommerville has contributed in this domain in [START_REF] Sommerville | Viewpoints: principles, problems and a practical approach to requirements engineering[END_REF]) by proposing, Preview, a model for requirements discovery, analysis and negotiation.

Views in Software Systems Modelling

Prior to the incomparable commonness of UML in software systems modeling field, Mullery has developed a method, called CORE, for requirements specification and design in 1979 [START_REF] Mullery | CORE-a method for controlled requirement specification[END_REF]. CORE is a modeling approach supported by diagrammatic notation which decomposes the modeling process to many steps, and defines for each of them a definition 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 [START_REF] Ladeira | Guidelines for business modeling elaboration based on views from domain information[END_REF][START_REF] Nassar | VUML: a viewpoint oriented UML extension[END_REF].

In 2003, a view-based UML extension, VUML [START_REF] Nassar | VUML: a viewpoint oriented UML extension[END_REF], 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 they proposed a code generation [START_REF] Nassar | Code generation in VUML profile: A model driven approach[END_REF] and automated composition (An-war et al., 2011) tools. Also one of the important works done in this field was [START_REF] Dijkman | Consistency in multi-viewpoint design of enterprise information systems[END_REF] where they presented a framework allowing the architect to model a system from different viewpoints by defining a collection of basic concepts common to all viewpoints and defining for each of them its associated level of abstraction. In this work they focused on the definition of consistency relationships between the views.

Views in Software Architecture

Software architecture consists on the definition of a structured solution that meets all the system requirements, and represents a complete organization of the entire software system and its inherent software and hardware components. Various models have been proposed of how to create a documentation of those architectures (i.e. an architectural description) by the separation of concerns. Each model describes a set of viewpoints and identifies the set of concerns that each of them address. The concept of Views appears in one of the earliest papers, Perry and Wolf's classic [START_REF] Perry | Foundations for the study of software architecture[END_REF] on Software Architecture in the early 1990s. In [START_REF] Sowa | Extending and formalizing the framework for information systems architecture[END_REF], the approach presents an extensive set of constructs called columns which is very similar to views. In 1995, Philippe Kruchten proposed four different Views [START_REF] Kruchten | The 4+ 1 view model of architecture[END_REF] of a system and the use of a set of scenarios (use cases) to check their correctness. In [START_REF] Hilliard | Views and viewpoints in software systems architecture[END_REF], the author proposed an 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 application, a viewpoint language. This study was the basis of the ISO/IEC/IEEE 42010 Standard (ISO/IEC/IEEE, 2011) which has formalized concepts used in Software Architecture and brought some standardization of terminology used in this field. It recognized the importance of Views in architectural description and adopted the Viewpoint concept defined earlier in [START_REF] Hilliard | Views and viewpoints in software systems architecture[END_REF]. In [START_REF] Clements | A practical method for documenting software architectures[END_REF], 3 viewpoints, called viewtypes, were identified which are: Module, Component-and-Connector and Allocation. In this approach, the author has defined a three-step procedure for choosing the relevant views for a system based on stakeholder concerns. Next, in 2005, a valuable survey [START_REF] May | A survey of software architecture viewpoint models[END_REF] compared between several view-based models and tried to find out the correspondencies between the different views proposed and the divergence between them.

Then it has proposed an optimum framework coverage encompassing a viewpoint set selected from dif-ferent models with the greatest coverage of the framework concepts. In [START_REF] Rozanski | Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives[END_REF], the authors proposed a Viewpoint Catalogue for Information Systems, extending the 4+1 set of viewpoints identified by Kruchten [START_REF] Kruchten | The 4+ 1 view model of architecture[END_REF] comprising 6 core viewpoints including : the Functional, Information, Concurrency Development, Deployment and Operational.

Views in Software Development

In Software Development field, many techniques consider that a number of software development concerns could not be handled 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 [START_REF] Mili | Concerned about separation. Fundamental Approaches to Software Engineering[END_REF]. In this area, several methods are proposed:

• The Subject-Oriented Programming (SOP) [START_REF] Ossher | Subject-oriented composition rules[END_REF] technique addresses the functional requirements. It views object oriented applications as the composition of several application slices representing separate functional domains called subjects. • The Aspect-Oriented programming (AOP) technique, such in [START_REF] Majumdar | Aspect Oriented Requirement Engineering: A Theme Based Vector Orientation Model[END_REF], addresses the non-functional requirements. It defines aspect as an implementation of a concern that pertain to several objects in a collaboration. • The View-Oriented programming technique [START_REF] Mili | View programming : Towards a framework for decentralized development and execution of oo programs[END_REF] considers each object of an application as a set of core functionalities available, directly or indirectly, to all users of the object, and a set of interfaces specific to particular users.

HISTORY OF ABSTRACTION LEVELS

Abstraction level is a core concept in software engineering; 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 different levels of details (i.e. abstraction levels) according to the purpose. 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 [START_REF] Regnell | A hierarchical use case model with graphical representation[END_REF] could be considered, where authors have proposed a hierarchical modeling approach that consists of three static distinct abstraction levels, which In [START_REF] Medvidovic | Formal modeling of software architectures at multiple levels of abstraction[END_REF], authors have proposed a software architecture's modeling process of component based architectures, composed of four modeling process abstraction levels or, actually, four modeling layers, which are: architectural components specification, components' interfaces definition, architectural description and architectural styles rules.

In [START_REF] Monperrus | A definition of "abstraction level" for metamodels[END_REF], 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 upper abstraction level and proposed splitting rules that are based on the inheritance and specialization relationships of the meta-model.

MoVAL APPROACH

MoVAL (Model, View and Abstraction Level based software architecture) is a multi-views/multihierarchy software architecture that complies with the IEEE standard (ISO/IEC/IEEE, 2011). The major benefits of MoVAL are: (i) it allows architects to solve more efficiently complexity problems; (ii) it allows them to build a complex, organized and coherent architecture (iii) and enhance the communication and harmony among different stakeholders by giving each of them the appropriate tools to express his interests.

Actually, a MoVAL model could be conceptualized, as shown is figure 1, by a matrix, in which the columns represent the views of the model and the lines represent the abstraction levels of a view.

Model views

A view of a model in MoVAL, is a representation of the entire system considering a set of the development process aspects and certain problems associated to a specific stakeholder or a group of stakeholders. Moreover, each view of the model is represented in a multi-levels multi-types hierarchy, but this paper will present only the abstraction levels, which are the highest hierarchy levels of a view.

View's abstraction levels

An abstraction level is the higher level in a view's hierarchy. It represents the level of details considered in certain point of the development process and defines the details that must be considered in this level and what to be relegated to lower levels. Each abstraction level specifies a well-defined diagrammatic notation that must be used to model the associated view considering the current level of details.

Links

The links are structural elements defined in MoVAL in order to express formally the relations that could exist between different abstraction levels and to conserve, consequently, the model's consistency. Those links are grouped in four categories, but this paper will focus only on two of them:

• Inter-views link, defining the relation among a couple of distinct abstraction levels belonging to two different views.

• Inter-levels link, defining a similar relation to that defined by the inter-views link, except that the abstraction levels here belong to the same view.

Actually, MoVAL has defined those links formally by attributing for each of them a semantic role that could be a simple connection, composition, expansion, etc. ... Also, MoVAL has created some semantic attributes for each of them in order to express formally all the necessary semantics of a relation between different abstraction levels of a model and guarantee its consistency.

Case study

To clarify MoVAL concepts, a reduced case study will be introduced in this section. This case study consists on a banking system in which two primary views are considered associated to a hierarchy of one single abstraction level: the Client view and the External In the considered portion of the banking system, an inter-views link could be defined between the abstraction levels of those views describing the relation between them and formalizing the fact that the external account management service component of the external application view's abstraction level uses the account management service of the client view's abstraction level.

ANALYSIS

RELATED WORKS LIMITATIONS

Using viewpoints to describe software architecture benefits the development process in a number of ways the separation of concerns, communication among stakeholder groups, complexity management and developer focus improvement. However, some limitations remain when using existing view-based approaches. We can summarize some of these limitations, which were solved in MoVAL, as follows:

• Needs to move between different abstraction levels: We assume that a software architect should define views at different levels of details. Thus, the software architect needs to think in terms of different abstraction levels and to be capable to move between them. Actually, in all the studied related works, an architect cannot specify a view or one of its representations in multiple abstraction levels, however in MoVAL he could identify for each view as many abstraction levels as he needs.

• Lack of an Architectural Description Process:

In almost all the studied approaches, except in [START_REF] Clements | A practical method for documenting software architectures[END_REF], it is unclear what the software architect has to do to define the suitable architectural description. This task is based mainly on his (her) experience and skills. So, MoVAL approach aims at defining an Architectural Description Process (ADP) which guides the software architect while defining the software architectural description. The ADP should be flexible, nonconstraining and iterative. Actually, MoVAL's ADP is out of this paper's focus. • Views Inconsistency: Using a number of Views to describe a system inevitably brings inconsistencies problems. So we need to achieve a crossview consistency within an architectural description, which is not offered by the majority of the studied related works, but MoVAL has defined the links (section 4.3) which hold the needed coherence rules in order to solve those inconsistencies.

CONCLUSION

This paper presents an overview of several approaches using Views in different fields: Requirements Engi-neering, Modeling, Implementation and Software Architecture. Limitations of existing approaches in Software Architecture field are emphasized. Also, this paper presents a preliminary approach for documenting intensive software systems architecture based on views and hierarchy levels. This approach complies with the IEEE standard 42010 and contributes with two major additions that are firstly, providing the software architect means to define views at different levels of detail and to move between them; then defining relationships that solve the inconsistencies between the architectural views. Actually, we are preparing a complete methodology or development process in order to allow system architects to build a rough and coherent multiviews/multi-hierarchy software architecture.

Figure 1 :

 1 Figure 1: Conceptual matrix of model

Figure 2 :Figure 3 :

 23 Figure 2: Client view's abstraction level

Table 1 :

 1 Existing works and their main characteristics.

		Inter-Views	Stakeholder	Fixed/Not Fixed	Hierarchy
		Relations	Roles	Views	Support
		Support
	(Delugach, 1990;	Represents	Development	Not fixed	NA
	Nuseibeh et al.,	dependency &	participants, End
	1994)	overlapping	user
	(Sommerville	Admits	Development	Not fixed	NA
	and Sawyer,	overlapping	participants, End
	1997)		user
	(Mullery, 1979)	Admits	Analyst, End user	Not fixed	Steps concept
		overlapping
	(Nassar, 2003)	NA	End user	not fixed	NA
	(Dijkman et al.,	Represents	Development	Not fixed	Single
	2008)	refinement &	participants, End		abstraction level
		overlapping	user		per viewpoint
	(Sowa and	NA	Planner, Owner,	Fixed	NA
	Zachman, 1992)		Designer, Builder
			and
			Subcontractor
	(Kruchten, 1995)	NA	Development	Fixed	NA
			participants
	(Hilliard, 1999;	Admits	Development	Not fixed	NA
	ISO/IEC/IEEE,	consistency	participants, End
	2011; Rozanski	relationships	user
	and Woods,	existence
	2011)
	MoVAL	Formal	Development	Not fixed	Multiple
		consistency	participants,		abstraction
		relationships	End user		levels per
					viewpoint


Ahmad Kheir
email: ahmad.elkheir@univ-nantes.fr

Hala Naja

Kifah Tout

Mourad Oussalah
email: mourad.oussalah@univ-nantes.fr

MoVAL: Towards a Multi-views/Multi-hierarchy Software Architecture

Keywords: Software architecture, Viewpoint, View, abstraction level

In order to manage software systems' life cycle and complexities, software development communities has recognized the needs to invest in software architectures. Despite numerous research and industrial works established in software engineering domain, there are always many significant limitations in current software architecture approaches, like the lack of relations definition among different architectural components on the one hand, and the lack of multi-hierarchy definition for each architectural component on the other hand. This paper presents MoVAL, a multi-views/multi-hierarchy software architecture which complies with the IEEE recommended practice for architectural description (ISO/IEC/IEEE standard 42010-2011).

I. INTRODUCTION

Software architecture is the organization of different software elements inside a software, usually called a system, independently of the used technology. An element could be a component in Component Based Software Engineering (CBSE), a service in Service Oriented Architecture (SOA), or a module in Object Oriented practices (OO). Actually, this organization is an intangible concept that needs to be communicated with different stakeholders. Thus, each software architecture should be represented via an architectural description (AD) that provides an overall picture of the system and its architecture. This AD provides intent, vision, and insight about the system, clarifies its purpose, goals, structural models, processes, and technology options. Despite the importance of software architecture and its architectural description in modern and complex systems development, this native concept remains not sufficient to resolve current software complexities. For this reason, a major track was considered in software engineering that is based on the multi-viewpoints (i.e. multi-views) concept, in order to reduce those complexities.

II. MOTIVATION

Despite the important advantages conducted by the viewpoint based software architecture approaches in general, these approaches still suffer some limitations. The study and analysis presented in [START_REF] Kheir | Overview of an Approach Describing Multi-Views/Multi-Abstraction Levels Software Architecture[END_REF], presents those limitations, which were the basis from which the objectives of our approach were made clear:

1. Existing approaches failed to treat the complexity that resides inside a single view. Indeed, in a view models are tangled (i.e. not organized according to some kind of relationships).

Clearly, we believe that models that make up a view should be organized into well-formed hierarchies according to different description levels. 2. Some existing approaches propose an architectural description process based on Views, but none of them clearly embed description levels definition as a step during the latter process. 3. The viewpoint based software architecture approaches haven't resolved the inconsistency problems between different views of the architecture, although they admitted the existence of some complementary and dependency aspects between those architectural views. Actually, our approach aims to define hierarchical multi-views software architecture in order to reduce the complexities of the system by breaking down its architectural description to several views and define for each view a hierarchy of levels. Also it aims define formal consistency rules between different views and hierarchy levels of the architecture in order to ensure the consistency of the resulting software architecture. [START_REF] Kheir | Hierarchical Multi-Views Software Architecture[END_REF] is a Model, View, and Abstraction Level based software architecture approach that is based on the construction of multi-views architectures, and the decomposition of each view to multiple abstraction levels of several types.

III. MOVAL APPROACH MoVAL

Actually, MoVAL extends the IEEE 42010 standard [START_REF] Jen | Working Group. IEEE recommended practice for architectural description of software-intensive systems[END_REF] and also complies with other important standards in software engineering, like the meta-object facilities (MOF) [START_REF] Omg | OMG Meta Object Facility (MOF) Core Specification[END_REF].

A view in MoVAL is a representation of the system considering a set of the development process' aspects, and some problems associated to a specific category of stakeholders or a group of categories of stakeholders. This view is defined in multiple levels of abstraction of different types: the achievement levels and description levels. In fact, an achievement level groups a set of artifacts defining an architecture at a specific phase of the architecture definition process, while the description level allows the architect to provide multiple descriptions having different granularity levels for each achievement level. Note that views and abstraction levels of a MoVAL architecture are linked together via formal architectural element called links. Those links were shaped formally in order to hold the relations that may exist between different architectural elements (views and abstraction levels) and to ensure the consistency of the architecture.

IV. MOVAL ARCHITECTURE DEFINITION PROCESS (ADP)

In order to benefit from MoVAL approach, it was crucial to define a methodology that guides the architect while developing his architecture. For this reason, a MoVAL specific architecture definition process (ADP) that complies with the Unified Process (UP) [START_REF] Jacobson | The Unified Software Development Process[END_REF] was developed.

As it complies with the UP, MoVAL process is an iterative process composed of four different phases: inception, elaboration, construction, and transition. ACKNOWLEDGMENT Authors would like to thank all who have contributed to the achievement of this preliminary and ongoing study, especially the Lebanese National Council for Scientific Research (LNCSR) and the Lebanese association for scientific research (LASeR) for funding this research project.