Modeling Concern Spaces Using Multi Dimensional Separation of Concerns

For software products, the specifications, the requirements even the variables, the code or the software modules are subject to be labelled with key-terms, or described using attributes or specific values. The purpose of these notations is linked to the semantic of the object labelled, and is used as an indexing form for that specific category. A separation of concerns meta model is proposed here to provide the support of using a unitary type of notation in labelling various kind of resources used in the process of developing software, from requirements and specifications all the way to variables, code or software modules. The use of a standard, unitary notation can have multiple benefits, covering areas like code reusability, reverse engineering, assigning technologies for development, aspect-oriented software development (AOSD), requirements engineering (engineering web applications, grouping requirements by categories, such as: technology, importance, actor, volatility, functionality).


INTRODUCTION
The separation of concerns in software engineering can provide multiple benefits such as reduced complexity, improved reusability, and simpler evolution. Using concerns help programmers to better visualize their work, stakeholders to relate the specifications. Reverse engineering, change impact analysis and reuse of code are also supported by concerns.Basically, software systems should benefit in many ways when using separation of concerns during product cycle.
Looking to a software product as an outsider, one might consider that describing the concerns produces a substantially large amount of metadata that adds bureaucracy during the development process of the software product. Although is needed to monitor closely the additional complexity that multi-dimensional separation of concerns can bring to the table; the software development and visualization tools are supposed to handle the added complexity; the benefits of using concerns outweigh clearly the miss concept of not using them.
With respects to generality, a concern can be considered to be any matter of interest in a software system, and also consider a concern space as an organized representation of concerns and their relationships. Defining concern spaces and relating concerns to the source code accordingly during development stage has the power to add semantic to the components of an application. The semantic value can be added to different entity spaces such as: the application model, the data, the relations, the views, and the design; also to the requirements, and not only.
We show that, while existing modelling approaches address concerns in specific contexts for specific purposes, a generalpurpose concern-modelling capability is still needed. The purpose of this paper is to express the need of a unitary framework for modelling Concern Spaces and the relations with different types of entities, to define primitives needed to represent such relations, and to propose patterns that can be followed in various scenarios during the use of the approach.
The paper will present in section 2 methodologies using different approaches regarding separation of concerns or models for the separation of concerns. In section 3 an approach to model concern spaces will be introduced. In section 4 a case study will be discussed. The paper will end with further work and conclusions sections.

RELATED WORK
In [4] authors are stressing the need of formalizing the concern spaces and to represent their relations to units as graphs, so a visual representation can be generated using specific tools. Is debated on using an implicit -null‖ concern in each space, to automatically map units in the system not connected to any other concerns in the space's domain. Also, an open discussion is presented over how the graphs should be expressed in terms of mathematical relations, with no restrictions or with restrictions, limiting the mapping to be injective (each unit maps to at most one concern), or surjective (each concern is -covered‖ by at least one unit). In [1], authors are using separation of concerns based by organizational concepts, not programming concepts, in order to close the semantic gap between the software system and its operational environment. They are proposing a software development methodology named Tropos which is founded on concepts used to model early requirements. Tropos posits five main classes of concerns: actors, resources, (hard) goals, soft goals, and tasks.
Sutton and Rouvellou are proposing to model the software concerns in Cosmos [11]. The Cosmos schema includes three types of elements: concerns, relationships, and predicates. In Cosmos, concerns are divided in two main types: logical and physical. Logical concerns are describing the concepts of interest regarding a system or artefact, such as: example, issues, aspects, features, and properties. Physical concerns indicate the elements of a system or the artefacts of software where the logical concerns can be applied. Cosmos presents a set of five logical concerns: classifications, classes, instances, properties, and topics. We can include in this category: functionality, behaviour, performance, robustness, state, coupling, configurability, usability, size, cost, and others. Physical Concerns are considered to be the -real world‖ entities of a system, like software, hardware, systems, and services. There are three types of physical concerns in Cosmos: instances, collections, and attributes. Physical instances are particular software units, physical collections are groups of instances or of other (sub) collections, while physical attributes are the characteristics of the previous two physical concerns: instances or collections.Another approach, ModelSoC, that uses concern separation for all artefacts (documents, models, code) as the primary (de)composition method for the complete process, is presented in [3]. They extend the hyperspace model for multi-dimensional separation of concerns to deal with information that is replicated in different models. A implementation based on their framework Reuseware organises all data provided during development in a concern space and composes integrated views as well as the final system from that. Their multidimensional approach refers here to artefacts and not to concern spaces. In [9] are provided hyperspaces to model the multi-dimensional separation of concerns. The process is used to simultaneous separation of units according to multiple, arbitrary kinds (dimensions) of concern. This allows on-demand remodularization. One gain is that concerns can overlap and interact. On the other hand, there are parts difficult to map to the hyperspace model as it is, because they are either not considered by the model or further refined parts of the model cannot be easily added to the system.In [12], authors are describing a paradigm for modelling and implementing software artefacts that allows separation of overlapping concerns along with multiple dimensions of composition and decomposition. Their paradigm addresses different stages of software lifecycle to offer artefacts traceability, flexibility and quality. O c t 1 0 , 2 0 1 3 The separation of concerns method is applied by Chen, Liu and Mencl [13] on Requirements Modelling. Even, though they split the model into several parts their approach is supporting separation of concerns and consistent and incremental modelling of requirements.The separation of concerns is taken to a higher level by Moreira, Rashid and Araujo [7], in a multi-dimensional separation of concerns. Despite of the fact that they give up on using viewpoints, use cases or themes in representing the requirements, the solution provided is conceptualized in such a way that different types of requirements (functional and NFR) are no longer described using separate representations, but are using a unique representation. All requirements are decomposed in a uniform pattern regardless of their functional or non-functional nature. The requirements space is divided into the system space and meta concern space, as in Figure 1. The system space gathers different types of systems that are possible to be realized (i.e. requirements associated to application that are just part of the requirements space); while the meta concern space comprises an abstract set of typical concerns (functional and non-functional requirements), that are found in various systems. Still, the relation in between the meta concern space and the system space entity is an restricting injective mapping.

MODELING CONCERN SPACES
One common characteristic of all approaches presented before is the focus on just one particular type of concern spaces. Mostly, the representations of the concern spaces used in each approach has appeared from the need to solve a certain problem, and for that reason a Concern Space was defined. The needs met by the use of Concern Spaces in the presented approaches are: organizational needs of the software system and system's operational environment in [1], artefacts classification needs in [3], remodularization needs by separating units in [9], the needs of separating concerns in logical ones and physical ones in software development only [11], artefacts traceability, flexibility and quality needs in [12], requirements modelling needs in [7] and [13]. So, the same concept of Concern Spaces was introduced in different ways by each of the approaches discussed before. A proper, generic type was not introduced, and the lack of standardization allowed multiple definitions of the same concept.
The model presented in this paper was introduced in [2], and extends the multi-dimensional separation of concerns defined by [7] already presented in the previous section. This higher level approach of the concerns spaces, provides a flexible structure and has the power to adapt the domain composition to changes in the range, always offering default mapping solutions. The range can express various types of entities, from common ones like code, software specifications or requirements to more specific ones like software artefacts, user types, developer profiles, technologies or even various informational systems.Concern Space groups one or more concerns and they are represented as multiple dimensions of the space (Figure 2).

Figure 2. A three-dimensional Concern Space
A novelty introduced by the approach is that the model can refer to multiple system spaces ( Figure 3) and can handle multiple concern spaces (Figure 4). The relations formed among these system spaces and concern spaces can add value to the software engineering field, providing a structure to represent relations, dependencies, qualities/attributes of different software concepts or entities.For example, different System Spaces (of two different web applications) can be related through the use of a Concern Space. This can lead to artefacts and code reusability. The following primitives will be defined: Concern Space, MultiSpace, Concern (Concern Dimension), Entity, Concern Value.
 Concern Space = a group of concerns referring to/describing similar capacities (issues /behaviour) of at least one type of entities. A Concern Space has a name, a description, and a set of dimensions (stored as a vector -one dimension for each concern in the space). Optional, parameters can be declared, to configure the Concern Space (a range of values for each dimension -[minValue, maxValue], by default [0,1]). The multiple dimensions of a concern space are represented visually in Figure 3.
 MultiSpace = Concern Space of Concern Spaces -Concern Spaces grouped by the same category of meta data. A MultiSpace space has a name, a description, and a set of Concern Spaces. On same level, the MultiSpaces, can be grouped interest-wise in a Meta MultiSpace on a higher level. So, MultiSpaces can be applied over MultiSpaces. This process can be applied recursively, on higher levels, if necessary.
 Concern = Concern Dimensionone of the elements in the set of dimensions of a Concern Space. A Concern has the purpose of describing an attribute of an entity, by assigning a corresponding value to the relation of an entity to that specific concern.
 Entityan object that can be associated to one or more Concern Dimensions from a Concern Space. Entities can be requirements, artefacts, users, software modules, technologies, specifications, even concern spaces.  System Spacesa collection of entities with cohesion. As entities can be of different categories, they can be grouped in separate System Spaces -such as Requirements system space, Viewpoints system space, Developers system space.
 Concern Valuea value that describes numerically (scalar) the relation between the Entity and the Concern Dimension. The value of the concern reflects the attribute weight of the entity regarding the concern space, the concern range values and the comparing/contrasting relation of the concern with the other concerns in the concern space. The Concern Space had to include at least one dimension (concern). It can be observed that any two consecutive levels in the meta model can be represented as weighted bipartite graphs. The relation in between the primitives is represented in the form of classes and relations in Figure 5. In concern spaces one or more dimensions (concerns) can be associated with the entities. Values are assigned for the dimensions from the {0,1} set, or from a set of positive fuzzy values, according to the considered impact of the dimension in the entity can be used, providing in this way a certain weight to the edge. The weight can be specified for each dimension (concern) in the space. By default, all the concerns in a Concern Space are associated to each entity with a value of 0, so no edge will be drawn to indicate the entity representation in that concern. Also, the vector of concerns of a particular concern space assigned to an entity is a vector of concerns with all values set at zero. The weight of a concernentity relation is not limited just as Boolean or Integer values; real numbers for describing weights (continuous quantities, time) had to be supported as has been demonstrated in [5].
For every entity, there is a vector from each Concern Space that is associated with the entity, expressing the blueprint of the entity in the Concern Space. This association can be expressed as a function with the entity and the concern space as the arguments, and with the associated vector of concerns as a result.
Let e be an entity in the system space E, S a n-dimension concern space and f a mapping function that describes the relation between the entity e and the concern space S.
f(e,S) = v, where eE, vR n We will present an example to illustrate the use of the function.
The system space E2 is formed by software modules to be implemented E2= {Module1, Module2, Module3}, where Module1 is a web form, Module2 is a database search engine and Module3 is a product page.
The relations in between the entities in the system spaces and the concern space are described below, using the mapping function.
In this way, relating different system spaces E1, E2 through the use of a Concern Space S1 is usefull in linking entities from one System Spaces to entities from another one, such as assigning the right developer to the task of implementing a module in the web application.
As represented in the Figure 5, one entity can be associated with more than one Concern Space. We will consider the following concern spaces: ISSN 2277-3061 2307| P a g e O c t 1 0 , 2 0 1 3 f(Entity1, S1)={0,1,0} Figure 5. Example of an entity linked to multiple concerns in different concern spaces with the respective values On refinements of entities such as requirements, the sub-requirements are inheriting all the upper levels (concern spaces) of the original requirement, as presented in Figure 6. Also a new concern-space, based on the original requirement is created, to show the relation in between the newly created sub-requirements, as presented in the next figure. In this Figure, we can consider the entity E7, as being a requirement in the web application Requirements Space with the description: -the members can edit their profile‖. This entity can be refined in two entities, entity E7.1 -the regular members can edit their profile‖ and entity E7.2 -the premium members can edit their profile‖. The newly created ConcernSpace5 gets as details the description of the former entity E7:‖ the members can edit their profile‖ and one dimension is automatically generated: the concern C5.1 -edit the profile‖. Following this refinement other concerns can be added to the ConcernSpace5, (such as concern C5.2 -upload video profile‖) that would be linked to entities (the concern C5.2 can link to entity E7.2 with the sense -premium members can upload a video profile‖) This refinement capacity offers stability (the use of same model structure) and flexibility (anytime entities can be changed and detailed).

CASE STUDY
This part will investigate the main existing web development methodologies and their tools, with respects to the tools supporting RE.
A wide use of the concerns is for describing requirements. Given a problem to be solved we will describe the requirements using the concern spaces created for the problem. The concern spaces proposed do not have to be used just for requirements. Once the problem is understood the concern spaces can be created together with the stakeholders to make clear different attributes of the product.
-A web application selling online songs and albums is required. Online users can listen songs and can buy songs. In order to buy songs the user had to be logged into the application and to pay using credits. Credits can be purchased by Credit Card, received as promotion (special holidays/contests) or as loyalty (long period member/purchase volume/ friend invites). Credits also can be donated/transferred from one user to another. Promotions are offered on the homepage. The application had to record browsing history for authenticated users in order to determine their client-profile. For administrative purposes a multi-user back-office will be created to administrate user accounts, music, promotions, and generate reports such as purchases/trends/profiles. Frontend had to be fast and to look professional.‖ Part of the entities in the Requirements Space will be introduced in Table 1, and will make the subject of our case study. Different concern spaces can be applied to the requirements determined in this example. Two concern spaces will be introduced now in the study, in Table 2 and Table 3. we can see the graph dependencies in between the requirements and the concern spaces in Figure 7. Figure 7. Modelling the selected concern spaces over the requirement space of the case study We can see that, regarding the type of user, most of the requirements are not the concern of the user -administrator‖. On the other hand, most of the requirements are connected to -information retrieval‖ activities or to users -guest‖ or -client‖.
For another view of the relations, a composition table for the mapping function can be made: This model can also be used on representing the concern spaces used in other approaces. In Model-Driven Software Development (MDSD) information that is captured in artifacts (documents, diagrams, etc.) that are created during the development of systems. These artifacts are regarded as models of the system and are integrated by means of transformation and composition. For example, ModelSoC [3] is introduced as an extension of the hyperspace model for multi-dimensional separation of concern defined by Ossher and Tarr [9] that can handle replication of information in different formats and usage of DSMLs for composing information. During the process, information is transported between different models-i.e., different views on the system-by model transformations. Five different types of viewpoints are supported by the approach: OpenOffice use case documents, UML use case models annotated with invariants, UML class models, Value Flow models and Java. Also, 12 concern dimensions were identified and defined as composition systems. The relation between viewpoints (y-axis) and concern dimension (x-axis) is presented below [ Table 5].  The composition systems in ModelSoC concern space S0 are composing the so-called -concerns‖. Examples of such -concerns‖ are given in the ModelSoC example: (a) Customer participates in Book Ticket (b) Bank participates in Book Ticket or (c) Account is exchanged between Customer and Bank. These -concerns‖ are considered to be -entities‖ in our approach.Considering the three entities as being part of a System Space called Features, we will be able to mapp the relations in between the entities in Features System Space and the S0 Concern Space. As mentioned in the ModelSoC example [3], the entities (a), (b) are linked to participation and to usecase concern dimensions, while (c) is linked to exchange concern dimension. Also another Concern Space can be defined here as the Actor Type Concern Space S1. Concerns in this space can be -Customer‖, -Bank‖, but, if needed, can be extended to other dimensions (like -ticket‖, -account‖).S1 = {1, -Actor Type‖, -types of actors in the system‖, (Customer, Bank), 1}Considering the Features System Space, we mapp with the f mapping function the relations to S1 Concern Space.
f("(c)Account...‖, S1) ={1,1} So we can see in this example 2 system spaces and also 2 concern spaces conected by using the multi-dimensional separation of concerns. This way we can track the relations [ Figure 8]from features entities to viewpoints entities using the conceptul binding by relating the system spaces to the same concern space S0, and from one concerns space to anotherfrom Actor types S1 to composition systems S0 using the conceptual binding through the Features system space. Figure 8. Conceptual bindings in between system spaces and in between concern spaces So, a transformation map of the primitives from ModelSoC to MultidimensionalSoC will convert as follows [ Table 6]:

FUTURE WORK
A methodology is necessary in order to systematically investigate and determine the proper concern spaces to be considered and used for different types of entities. Such work can extend the valuable contribution of Poshyvanyk et all in [10].
Samples of concern spaces and multispaces databases along with entities spaces (system spaces) should be created in order to support the development processes based on separation of concerns methodologies.
A tool to support for the implementation of concern spaces is under development. Conversion patterns from types of concern spaces introduced in other approaches towards the model introduced here is needed to prove model generality and acceptance.
Oher visualizations tools can provide graphical renditions, but may also offer query facilities. The manually mapping of code to concerns is difficult and time-demanding, as proved in [6]. Such activities should be assisted by and, if possible, partially automated with specialized tool.
The impact of this approach on web application requirements and product development will be also a subject of future research, as one direction can be to drop concern information into the web application source code for reverse engineering purposes. A valuable contribution is this direction is made by Marcus and Rajlich in [8].

CONCLUSION
The approach presented here is meant to introduce a generalization of the concern spaces and of the separation of concerns modelling. The model presented has multiple possible applications, such as requirements engineering, informational systems, reverse engineering. The model can be expressed visually as a graph, can handle complex scenarios and is flexible, reliable through the life cycle of the scope.