Multiple Criteria Decision Making for the Structural Organization of Software Architecture

Architectural decisions have a significant impact on the development process as well as on the quality of applied systems. On the other hand, it would be desirable to rely on mature solutions and proven experience when making such decisions. Partially this problem could be solved with the use of architectural patterns. Such solution for the same task can be implemented using different sets of patterns. As a result, there is a problem of choosing and evaluating the software architecture that is build using a number of patterns and that meets the system requirements. In this paper, the technique that allows selecting the optimal software architecture for applied software is proposed. This selection technique is reduced to the criteria importance theory problem. For applying it, we need to pick up a set of metrics that assess the characteristics of the software architecture. Next, we need to determine metrics scale and information about their importance. The results allow us making conclusions about usefulness of the proposed technique during architecture design phase for applied software.


Introduction
The formation of architecture is the first and fundamental step in the software design process and provides the framework of a software system that can perform the full range of detailed requirements [1,2].
Most of the existing techniques for constructing a software architecture are not well formalized and are usually not based on any mathematical theory [1]. Therefore, the problem of software architecture selection and analysis based on quantitative evaluation is very important. The analysis of an architecture enables early prediction of a system's qualities. In other words, it would be desirable to have a formalized technique that is based on mathematical theory, and which allows the user to analyse and make decisions when choosing a software architecture or its components.
A number of techniques have been proposed to assist software architects in making architecture decisions [3,4]. There are several groups of such techniques, where some of them focused on architecture trade-off analysis, quality evaluation model analysis, performance optimization and some others well-known techniques [5,6,7,8,9,10,11,12,13,14,15].
Some other studies propose the usage of the criteria of efficiency and the architecture efficiency metrics for quantitative evaluation of a software architecture structure [16,17]. The disadvantage of this method is that the components of the architecture efficiency metrics are explicitly defined, and we cannot easily extend them to reflect the required software architecture features.
One of the key artefact obtained on the architecture design phase is the structural organization of the architecture, which can be represented using Unified Modeling Language (UML) or Architecture Description Language (ADL) [1,2,18].
In this paper, we consider exactly the structural organization of the architecture. In the initial stages of software development there were no standardized approaches for the development of the structural organization of software systems. Those that existed were too much generalized and not very accurate. In consequence of that the development of such systems it is required much more time and financial resources. Usually, highly skilled professionals were required for such development. To reduce the development costs the more formalized techniques began to emerge. This work resulted in the appearance of software design patterns [1]. The patterns later became more complex and some evolved to architectural patterns. Nowadays there are plenty of different design patterns. With the help of these patterns you can build a variety of different architecture alternative, and the question then is how to make a choice among these alternatives. To answer this question there have been proposed different approaches that allows to make such decisions. Unfortunately, most of existing techniques does not well examine architectures' structural organization.
In this paper, we propose a technique that allows us to make architectural decisions when creating structure of a software architecture using set of architectural patterns. In other words, this technique allows us to choose the best structural organization of the software architecture that is build using the architectural patterns.
The proposed technique is based on so-called criteria importance theory [19,20]. It allows decisions to be made when choosing a software architecture system from among several alternatives and lacks the disadvantages that exists with other methods.

Selection of Optimal Architecture
The software architecture is the structure of the system, which comprise software components, the externally visible properties of those components, and the relationships among them [1]. The software architecture is a complex design artefact.
It's a complicated task to make a validation of software architecture at early design stage and it's much easier to rely on tried and tested approaches for solving certain classes of problems. One of the approaches is to use architectural patterns. An architectural pattern, expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them [1,2,18]. The architectural patterns improve partitioning and promote design reuse by providing solutions to frequently recurring problems. They allow reducing a risk by reusing successful designs with known engineering attributes.
Creating a software architecture based on architectural patterns we need to bear in mind that different architectural patterns are focused on different areas and solve different problems. That is why they might be categorized in several groups. There are several approaches of architectural patterns classification [17,18,21,22,23,24,25]. Usually the software isn't limited to a single architectural pattern. It is often a combination of architectural patterns that make up a complete system. For instance, there might be SOA based architecture where some services are designed using layered or N-tier architecture approach [18,22].
Software architectural patterns themselves won't help us to satisfy the requirement, to do so they need to be organized in structures; that is, we need to identify and connect elements that are derived from the selected design concepts. Such structure of architectural patterns created a reference architecture. Reference architecture is blueprints that provide an overall logical structure for particular types of applications. A reference architecture is a reference model mapped onto one or more architectural patterns [1,18,22,25].
During the software architecture design stage there could be obtained several different reference architectures, built using architectural patterns. In this case, there is a problem of comparison and choose the best architecture that is best satisfying the software requirements. In this paper, we use a model based on criteria importance theory [19] for selecting the optimal software architecture.
To apply this technique, we need to perform a number of steps represented on Fig 1. The detailed process of applying the technique is as following: 1. Select software architecture metrics that assess the characteristics of the software architecture. In our case, we define our own metrics as the available architecture metrics are very limited and not easy to apply for component structure of a software architecture [2,12,16,17,26,27]; 2. Determine the metrics scale, metrics unification and normalization; 3. Group the metrics into several metric groups; 4. Determine vector criterion; 5. Define information regarding the metrics importance and define preference relations for the metric groups; 6. Identify and create potential software architecture candidates; 7. Obtain the software metrics values for the selected software architecture alternatives; 8. Select optimal software architecture by applying the mathematical model based on criteria importance theory.
For our case study we use the minimum number of required metrics. At the same time, we rely on the classical approach, which is adopted in software engineering theory for assessing the quality of project design, including size (complexity), coupling and cohesion [2]. Moreover, we consider the functional complexity that is measured using a modification of the well-known Function Point metric by Albrecht [28]. Also, we have a bit extended the number of metrics by the well-known quality characteristics from ISO/IEC 25023:2016 [29]. The resulting set of metrics can be slightly expanded, since it doesn't change the essence of the technique in general.

Model Definition
The mathematical model of individual decision-making for multiple criteria includes the following components [19,20]: • set of alternatives X; • vector criterion f; • preference and indifference relations of the decision maker (DM), which are denoted as Р (preference) and I (indifference).
Each alternative x from the set of alternatives X is characterized by a number of criteria f i , i = 1, ..., m, which are called particular criteria. The ordered set of such criteria forms a vector criterion f = (f 1 , …, f т ). The criterion f i is the function defined on X and taking its values from z i , which is called a common scale (or number of assessments of such criterion). According to the standard software engineering terminology we call particular criteria metrics.
Assume that we have a number of different software architecture options. For example, the architecture of some transport system can be implemented based on a service-oriented pattern; an alternative architecture could be based on a Multitier pattern; another with the use of a micro services architectural pattern and so on. We define a set of such alternative software architectures as X = {X i i = 1, …, n}. Let us assume that all alternative metrics are homogeneous, i.e. they are all measured using the same scale and have the same range defined as Z 0 . Suppose that the number of scale gradations is finite, then: In other words, each metric f i from the set of alternative software architectures X can take the values from the set of scale gradations Z 0 . Assume that all estimates are expressed in numerical form and higher values are preferable to smaller ones. Thus, each software architecture alternative X i is characterized by values f i (X i ) of every metric and forms its vector estimate y = f( , ij y I y where y ijvector estimate, which is obtained from vector y by replacing its components y i and y j .
The fact that metric f i from one group is more important than metric f j from another group is denoted as .
i j f f  In that case, for the pair of vector estimates y and y ij , the DM prefers the first one to the second one, and it is denoted as 0 . ij y P y In addition to this, it is necessary to be able to quantitatively indicate for how many times the metrics from one group are more important than the metrics from the other group. To do so, we define the matrix of degrees of importance superiority When using it the preference relation is written as follows:

Metric Selection
For the formation of the vector criteria, it is necessary to define a set of metrics that will be used. To select the metrics, we can use the technique of selection of the metric suite [26].
During the architecture design stage, the architectural patterns are treated as a "black box", so we could make some indirect measures of system characteristics. One of the most suitable metric for such measures is function point (FP) metric, which indirectly measures software and the cost of its development. The value of this metric reflects the functional complexity of the product [2,26,27,28].
In addition to the complexity metrics, outer (Coupling) and inner (Cohesion) relations in architectural patterns can be measured. Coupling is a metrics that express the degree of data interconnection between modules. Low coupling is an indication of a well-designed system. Cohesion is a measure of how strongly the functionality inside a module is related. High cohesion of a module is a desirable trait [2,27].
In addition to these metrics, we need to measure the architecture quality characteristics [27] such as complexity, responsibility, scalability, maturity, reusability, extensibility, replaceability, supportability, performability, interoperability and suitability.
For a comprehensive evaluation of the architecture, we combine the above listed metrics into three the following groups: • Architecture size metrics; • Architecture links metrics; • Architecture's quality characteristics.
Since most of available software metrics are not applicable for the software architecture, we need to define such metrics first.

Architecture Size Metrics
For architecture size metrics, we consider the metrics that directly or indirectly measure the size of a software system.

Architecture Function Points (AFP)
One of the metrics which indirectly measure the software complexity is Function Points metric [2,26,28]. The input data for this metric are obtained using system requirements. Since the application of each architectural pattern has its own features, impacts and requires a different amount of effort, it is advisable to consider the software architecture impact for each separate component.
For Function Points metric we need to get Unadjusted Function Point count, which includes number of external inputs, external outputs, external inquiries, internal logical files, and external interface files [28]. Next, to determine the Degree of Influence we need to evaluate each of the 14 general system characteristics [28]. Examples of such general system characteristics include data communications, distributed data processing, performance, reusability, etc. The resulting degree of influence must be in the range of 0.65 to 1.35 [28]. After multiplying the Unadjusted Function Point count by the Degree of Influence we get the adjusted Function Point count.
For our calculations we must also consider the impact of patterns on the system's characteristics. Thus, the metric is defined as follows: 14 1 0.65 0.01 , where UFP -Unadjusted Function Point count; СF i -defined as follows: , where F i -degree of influence coefficient from FP metric; c i -influence of architectural pattern on the i-th system's characteristic.
To get the c i values, first, we need to evaluate a characteristic using the following scale: 1 -use of a pattern reduces the significance of a system characteristic; 2 -use of a pattern slightly reduces the significance of a system characteristic; 3 -no influence; 4 -use of a pattern slightly actualizes a system characteristic; 5 -use of a pattern actualizes a system characteristic.
Next, these values are converted into c i using the scale conversion rule presented in Table 1.

Architecture Links Metrics
For software architecture links, we consider the strength of the relationship between the architectural components and inside each individual component. Roughly, this is similar to the relationship between classes in Object Oriented Programming, although here we evaluating software architecture components. For such evaluation, we define two new metrics, which are based on Software Package Metrics [30]. One of the metrics is used to measure the coupling, while the other is used to measure a cohesion.

Architecture Instability (AI)
Adaptation of the original instability metric [27,30] for architectural functional components allows us to define the following instability of the architecture's component metric: where C e -efferent coupling (outgoing dependencies). The number of classes inside this component that depend on classes outside this component. C e is a form of the fan-in of a component.
C a -afferent coupling (incoming dependencies). The number of classes outside this component that depend on classes within this component. C a is really the fan-out of a component.
If there are no outgoing dependencies, then CI will be zero and the component is stable. If there are no incoming dependencies, then CI will be one and the component is unstable.
Having the instability metric, let us define an Architecture Instability metric as follows: where i CI -instability of the i-th architecture's component; N -number of components of the architecture.

Architecture Relational Cohesion (ARC)
Adaptation of the Package Relational Cohesion metric [27,30] for architectural functional components allows us to define the following relational cohesion of the architecture's component metric:

Architecture's Quality Characteristics
For the third group of the metrics let us choose the metrics that evaluate the architecture's quality characteristics. Metrics from this group are based on the international standard "Systems and software Quality Requirements and Evaluation (SQuaRE) -Measurement of system and software product quality" [27,29]. The group includes the metrics listed in the table 2.
The scale for evaluation quality characteristics we define in range from 0 to 1. Where low value means that this characteristic is poorly supported by the considered architecture; high value of the characteristic indicates the opposite.

Uniformity and Normalization of Metrics
The selected metrics allow us to obtain a vector criterion for software architecture evaluation. Table 3 lists the metrics with their scale. As long as for two metrics the lower values are preferable, it is necessary to overcome this contradiction. To do that we replace the Architecture Function Points and Architecture Instability metrics by the alternatives which are listed below.

Inverted Architecture Function Points (AFP′)
The Architecture Function Points metric must be normalized, and its value must be proportional to the preference. Therefore, we define the metric Inverted Architecture Function Points as: where AFP i -Architecture Function Points for the i-th architecture, AFP max -maximum value of AFP for compared architectures.

Architecture Stability (AS)
The original Architecture Instability metric is replaced by the Architecture Stability metric, which is determined as: where AI -Architecture Instability for the architecture.

Scale
To apply the criteria importance theory model, we need to convert the linear scale for all metrics to an ordinal scale, where values are distributed from 1 to 10. Thus, all the metrics will have a common scale and higher values are preferable to lower ones.
To obtain the rank value we need to use the normalized value of the metric and convert it using the following definition: The resulting relations forms the quantitative information about metrics importance Θ.

Case Study
To illustrate the example of usage of the proposed model, we conducted a case study for which we built several software architectures using different architectural patterns.

Selection of Optimal Architecture for Airline Business Case Study
Let us consider four different architectures for airline reservation system. The system should have information regarding planes, their departure and arrival times, source and destination. The system should have passenger details. The software should provide search options and checking for ticket availability. The user should be able to make and cancel a reservation. In addition, user should be able to check-in for the flight and select meal preferences. The domain model for that architecture is represented in Fig. 2.
From all possible solutions, we are considering three different approaches for creation of the architecture for such system. All these options are based on different architectural patterns that provides various capabilities and introduces specific requirements. The considered solutions include: A 1 -Architecture that is based on a Service Oriented Architecture (SOA) architectural pattern; A 2 -Architecture that is based on a Multitier architectural pattern; A 3 -Architecture that is based on a Database-centric architectural pattern; A 4 -Architecture that is based on a micro services architectural pattern.

Obtaining Values of the Metrics
It is necessary to obtain values for the selected metrics for the given software architectural solutions. Metrics f 1 , f 2 and f 3 are evaluated based on the created software architectural models; and metrics f 4 -f 14 are obtained using expert evaluation.
The obtained metric values are given in table 4.
To transform the problem where the particular criteria from different groups are not equally important to the problem where all criteria are equally important, we need to create an N-model from criteria importance theory [19,20]. For that purpose, the preference relations and number of the criteria in the group should be taken into consideration.
By substituting the above-listed data into the proposed decision-making model, we get the result that A 1 is non-dominated; A 2 , A 3 and A 4 are dominated by A 1 ; A 2 and A 3 are dominated by A 4 ; A 3 is dominated by A 4 .

Conclusions
The paper proposes a technique that allows selection of the optimal software architecture for applied software is proposed. This selection technique is reduced to the criteria importance theory problem.
We defined a model based on criteria importance theory that could be used to choose the optimal software architecture. To apply the model, picked up a set of metrics that assess the characteristics of a software architecture; determined the scale and information about the metrics importance.
For the formation of the vector criterion, we defined a set of metrics that includes metrics from three different groups, some of which asses the size, links and different quality characteristics of the software architecture.
To validate the proposed model, we conducted a case study for which we built three software architectures using different architectural patterns. For every software architecture alternative, the metrics values were evaluated and the corresponding vector criterions obtained. The result of the case study proved the correctness of the proposed model, which is based on the criteria importance theory. During the case study, we identified the optimal software architecture for the transport system with the specified requirements.
The results obtained indicate that the proposed technique is applicable for solving problems of the selection of optimal software architecture for applied systems.
As the next step of the research, we are planning to undertake extension of the proposed technique for case of hierarchical criteria.