A Method for Assessing Maintainability of Software Architectural Styles in Self-healing Systems by Measuring Coupling and Cohesion

(1)

Journal of Computing and Security

January 2015, Volume 2, Number 1 (pp. 31–42)

http://www.jcomsec.org

A Method for Assessing Maintainability of Software Architectural

Styles in Self-healing Systems by Measuring Coupling and Cohesion

Azam Farrokh

a

, Seyed Morteza Babamir

a,

∗

a_{Department of Computer Engineering, University of Kashan, Kashan, Iran.}

A R T I C L E I N F O.

Article history: Received:29 August 2014 Revised:7 December 2014 Accepted:5 November 2015 Published Online:7 February 2016

Keywords:

Self-Adaptive System, Self-Healing System, Architectural Style, Maintainability, Coupling, Cohesion.

A B S T R A C T

In this article, our aim is to quantify the impact of three reference architectural styles, i.e. Aspect-peer-to-peer, Aggregator-escalator-peer, and Chain-of-configurators on the maintainability attribute in self-healing systems. To do so, we used metrics of coupling and cohesion. To show the effectiveness of our method, we applied it to the Wireless Body Area Network (WBAN) as a case study. Our findings showed the Chain-of-configurators architectural style, in comparison with two other styles, had the least (best) coupling and the most (best) cohesion. In fact, it was the best style from the maintainability point of view.

c

1 Introduction

Self-adaptive systems are systems that are able to adapt themselves to the new conditions of their envi-ronment through learning from their past experiences. Aself-healing system is a self-adaptive system which recovers from unexpected and impairing events [1,2]. In designing the software of self-healing systems, archi-tectural styles play important roles. [3] defined a style as: ”A specialization of element and relationship types, together with constraints on how they may be used.” In fact, an architectural style provides anabstraction of a family of systems. Accordingly, a suitable archi-tectural style is a contributory factor for satisfying quality attributes of a system.

Among others, three reference architectural styles, i.e., Aspect-peer-to-peer,Aggregator-escalator-peer, and Chain-of-configurators, have been presented and discussed for designing software of self-healing systems [4]. The first style assigns a monitor com-ponent andconfigurator to each condition or aspect

∗ _{Corresponding author.}

Email addresses:farrokh@grad.kashanu.ac.ir(F. Farrokh),

babamiri@kashanu.ac.ir(S.M. Babamir)

of the system. In the second style, the monitors are grouped and each group is allocated to one condition or aspect of the system and in the third style, several configurators could be chained together.

(2)

32 A Method for Assessing Maintainability of Software Architectural Styles . . . — A. Farrokh and S.M. Babamir

The rest of the paper is organized as follows. In Sec-tion2, the related work is discussed and in Section3, some properties of self-healing systems are introduced. In Section 4, the software architecture is described and in Section5, the effective metrics for quantifying the impact of software architectural styles on the sat-isfaction of the maintainability attribute is explained. In Section6, the WBAN system is proposed as a case study to show the effectiveness of our method. Finally in Section7, conclusions are drawn.

2 Related Works

In this study, we consider thequantitative evaluation of the impact of software architectural styles on the maintainability of self-healing systems. Accordingly, we consider first, the studies that have addressed the quantitative evaluation of software architectural styles’ influence on quality attributes and, second, the studies that dealt with the quantitative evaluation of the maintainability attribute.

Software architectureevaluationmethods are based on: (1) scenario, (2) simulation (3) mathematics and (4) measurement [6,7]. The measurement-based eval-uation methods use metrics for the evaluation, so they are more accurate than the others. Although, [8] discussed qualitative evaluations, these methods are less accurate than the quantitative and measurement-based methods. Therefore we consider a quantitative method for evaluation of quality attributes. Our quan-titative method uses coupling andcohesion metrics to quantitatively measure maintainability by three reference software architectural styles applied to self-healing systems.

Some software attributes have already been evalu-ated by quantitative methods such as Markov models. [9] introduced a Markov model to utilize software archi-tectural styles for assessing thereliability and perfor-mance attributes. Although they used a quantitative method but in contrast to our method, they did: (1) not use the software engineering metrics, coupling and cohesion, (2) not address the self-healing systems and (3) not quantitatively measure the maintainability.

For the software architecture of self-healing systems, three reference styles were introduced by [4] based on which [8] developed an analysis and reasoning framework to evaluate themodifiability attribute of the software architecture. However, they tailored a non-quantitative method for their work. Compared to this method, our work is different in two aspects: (1) we propose a quantitative method and (2) our method measures the maintainability with the reference styles. The similarity of our works is the use of reference styles as the basis.

As stated in Section 1, for self-healing systems, maximizing themaintainability is one of the main objectives. To evaluate the maintainability in the reference styles, [10] presented a method, which is similar to our method in two aspects: (1) considering the reference styles as the underlying principles and (2) assessing the level of maintainability. However, their method exploited a non-quantitative method which means they have not quantitatively measured the maintainability attribute in the reference styles.

3 Self-healing Systems

Soaring exchange of information among software sys-tems, and their complexity necessitates the long life and high availability of such systems. To this end, they should be self-adaptive meaning that they should be able to adapt themselves to their environment con-ditions at run-time. Such systems are able to learn from their past experiences to predict some future condition.

Various definitions of self-adaptive software have been presented. Self-adaptive software is defined as a closed-loop system with a feedback loop [11]. Devel-oping self-adaptive software through an adaptation engine and feedback loops, was proposed by [12]. The engine provides the adaptation at runtime through adaptable software models.

To satisfy users’ requirements, self-adaptive systems should respond to changes of their environment at run-time. Therefore, a self-adaptive system should: (1) monitor its environment changes and (2) react to the changes [13]. To this end, it needs to specify the critical goal that should be satisfied. Furthermore, since the self-adaptive systems are expected to have specific properties, they are called systems with self-* properties [14, 15]. For the adaptation process, the following questions should be answered [13]:

(1) Which parts of the system should be adapted? (2) Which aspects of the system should be changed

or maintained at run-time?

From the control point of view, one technique for implementing a self-adaptive system is adding a sepa-rate and external control unit to monitor and adapt the system during the run-time [13]Cheng; however, this method is expensive. Another method is monitor-ing and adaptmonitor-ing a system at run-time based on the software architectural model of the system [16]. Such methods are calledarchitecture-based self-adaptation.

(3)

January 2015, Volume 2, Number 1 (pp. 31–42) 33

of failure; furthermore, they can recover from an unexpected event [1]. In this article, we concentrate on this type of self-adaptive systems.

4 Software Architecture

The structural design of a software system is a crit-ical aspect of software design because it provides a high-level view of software components and their com-munication. [5] states: “The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, rela-tions among them, and properties of both.”

The rest of this section is organized as follows. In Section4.1, the relationship between software architec-ture and quality attributes is discussed. Sections4.2

and4.3are dedicated to software quality attributes and the concept of coupling and cohesion respectively.

4.1 Software Architecture and Quality

At-tributes

Satisfying quality attributes of a system is largely de-termined by its architecture; therefore, understanding the relationship between the software architecture and quality attributes is a significant concern. Designing a system without supporting quality attributes may lead to the redesign of the system during its lifetime. If we are able to evaluate a system before designing, we can avoid its redesign. Having carried out such an evaluation, we will be able to select the most suitable software architecture based on its level of support for quality attributes.

To evaluate the software architecture of a system, different compositions of the software components should be evaluated. A specific composition of com-ponents with a number of constraints governing the composition is called anarchitectural style, which is a building block of the software architecture. Since a style includes the features influencing quality at-tributes, we can evaluate the style by identifying its degree of support for quality attributes. Architectural styles have a strict impression on system quality at-tributes such as reliability and maintainability. This is why that selecting an appropriate architectural style is an important step for development of software [17].

4.2 Software Quality Attributes

In this section, we explain software quality attributes. In software engineering, software with highly satisfied quality attributes means there is no end users’ dissatis-faction problem. There is a standard for the evaluation of software quality [18] whose first part consists of the classified software quality attributes, Functionality,

Reliability,Usability,Efficiency,Maintainability and Portability. In addition, the self-healing systems have more features due to their changes and adaptations at runtime.

Self-healing is the ability of detection and recovery from a failure and the main purpose of developing such a system is the concentration on quality attributes such asavailability, durability, maintainability and reliability[2]. The relation between attributes of self-adaptive systems and common quality attributes was surveyed by [19]. As stated in Section1, among others, maximizing themaintainabilityattribute is one of the main objectives of self-healing systems. In Section1, the definition of themaintainabilityattribute by Bass et al was presented. ISO 9126 knows maintainabil-ity as one of the six major features of the software product quality whereadaptability,changeability, sta-bility, andtestability are counted as sub-features of themaintainability [18]. The softwaremaintainability attribute depends on the software design modularity, i.e. a design withlow coupling andhigh cohesion of modules. In other words, the sub-features of the main-tainability attribute of software will be improved when the coupling/cohesion degree between the software modules decreases/increases. The impact of cohesion and coupling on software maintainability is empha-sized in [20]. We explain cohesion and coupling more in the following section.

4.3 Cohesion and Coupling

Generally speaking,coupling is an attribute of a pair of modules indicating the degree of interdependency between them [21]. Based on the experience with design of some software systems, [22] presented the numeric values 0 to 5 for types of couplings (Table1).

According to [21] the coupling types are:

(1) No coupling: modules do not communicate with each other; this means that they are totally independent of each other,

(2) Data coupling: two modules share data with each

Table 1. Module Coupling Values

Coupling type Weight Symbol

No Coupling 0 w0

Data 1 w1

Stamp 2 w2

Control 3 w3

Common 4 w4

(4)

Table 2. Module Cohesion Values

Cohesion Type Weight Symbol

Coincidental 0 w0

Logical 1 c1

Temporal 2 c2

Procedural 3 c3

Communicational 4 c4

Sequential 5 c5

Functional 6 c6

other by the parameter passing mechanism, (3) Stamp coupling:two modules share a composite

data structure by parameter passing mechanism, (4) Control coupling: a module controls the process

of another by a control flag passing,

(5) Common coupling: some modules share the pro-gram global data,

(6) Content coupling:a module can change the in-ternal workflow of another.

[21] defined module cohesion as, how a module needs the other components to perform a job. They introduced the types of cohesion as follows. In this article, we use the numeric values 0 to 6 for types of cohesion (Table2).

(1) Coincidental cohesion:two modules of a compo-nent perform tasks that are not related to each other; but, they are appeared physically in one component,

(2) Logical cohesion: two modules of a component perform tasks that are logically related to each other such as handling routines of a component that gather mouse and keyboard inputs, (3) Temporal cohesion: a module of a component

performs tasks based on events received by the component,

(4) Procedural cohesion: a module of a component performs a task of a sequence of component’s tasks in a certain order,

(5) Communicational cohesion: two modules of a component operate on the same data,

(6) Sequential cohesion: in a component, outputs of a module is inputted to another one,

(7) Functional cohesion: two modules of a compo-nent together perform a single function.

4.4 Architectural Styles for Self-healing

Sys-tems

According to the style definition by Clements et al. (see Section1), a style introduces an architectural structure

5

This style (Fig. 2) assigns a monitor component to each condition or aspect of the system that should be monitored; furthermore, each monitor has a corresponding configurator to perform the needed adaptations. escalates to/

dispatches to monitors/

configures 0..1 1..n

Informs/ invokes Alert

Fig. 1. Conceptual model of self-healing architecture Fig. 2. Aspect Peer-to-Peer architectural style (Hawthorne & Perry 2005) (Hawthorne & Perry 2005)

 Aggregator-escalator-peer style:

In this style, a monitor sends the observed data to high-level aggregator monitors (Fig. 3), which they pack the data to a composite package. Then, the composite package is passed to its respective configurator.

 Chain-of-configurators style:

In this style, several configurator components are chained together. The configuration request is moved along with the chain so that it can be successfully processed. Fig. 4 shows this style consisting of a single monitor in the entire system; if one of the configurators is not able to perform a request successfully, one of the other configurators will try to do the request. Moreover, configurators can perform tasks together by dividing the task among themselves (Zhu et al. 2008).

Adaptation mechanism

System aspect

Reflection Configuration

Reasoning

System/ subsystem

System component

Environment aspect

Figure 1. Conceptual Model of Self-Healing Architecture [4]

consisting of elements such as modules, components, and connectors through recognizing the elements and their interrelationship.

A self-healing system must be able to adapt its be-havior to the changes of its environment. To this end, it must be able to continuously monitor its environment and react accordingly. Therefore, an architecture of a self-healing system should regard three basic mecha-nisms [4]: (1)Reflectionby which the system responds to its internal and external conditions, (2)Reasoning by which the system takes an action in response to a condition, and (3)Configurationby which the system adapt itself in response to the conditions (Figure1). In the reference architectural styles, the compo-nent runtime reflectionandcomponent configuration are called themonitor andconfigurator respectively. Now, we explain the reference architectural styles for self-healing software systems based on monitor and configurator components:

(1) Aspect-peer-to-peer style: This style

(Fig-ure2) assigns a monitor component to each con-dition or aspect of the system that should be monitored; furthermore, each monitor has a cor-responding configurator to perform the needed adaptations.

(2) Aggregator-escalator-peer style: In this

style, a monitor sends the observed data to high-level aggregator monitors (Figure 3), which they pack the data to a composite package. Then, the composite package is passed to its respective configurator.

(3) Chain-of-configurators style: In this style,

(5)

among themselves [10].

This style (Fig. 2) assigns a monitor component to each condition or aspect of the system that should be monitored; furthermore, each monitor has a corresponding configurator to perform the needed adaptations.

monitor 1..n 1..n configure

escalates to/

configures alert/reply 0..1 1..n request

• Aggregator-escalator-peer style:

• Chain-of-configurators style:

escalate to

delegate to alert/reply

request

alert escalate to

alerts from delegate to

alert/reply invoke

request request

alert/reply

request

Fig. 3. Aggregator-Escalator-Peer architectural style Fig. 4. Chain-of-configurators architectural style (Hawthorne & Perry 2005) (Hawthorne & Perry 2005)

System aspect

Reasoning System/ subsystem System component Environment aspect

Monitor Configurator

Aspect 2 Monitor

Aspect N Monitor Aspect 1

Monitor Aspect 1 _Configurator

Aspect 2 Configurator Aspect N Configurator System Aspect Environment Monitor Environment Configurator Memory Monitor Network Monitor CPU Monitor CPU Configurator Memory Configurator Network Configurator Subsystem Configurator Configuration manager Memory Monitor Configu- rator 1 Configu- rator 2 Configu- rator n 5 Figure 2. Aspect Peer-to-Peer Architectural Style [4]

This style (Fig. 2) assigns a monitor component to each condition or aspect of the system that should be monitored; furthermore, each monitor has a corresponding configurator to perform the needed adaptations.

escalates to/

escalate to

request

alert escalate to

alert/reply invoke

request request

alert/reply

request

System aspect

Monitor _Configurator

Aspect 2 Monitor

Aspect 2 Configurator Aspect N Configurator System Aspect Environment Monitor Environment Configurator Memory Monitor Network Monitor CPU Monitor CPU Configurator Memory Configurator Network Configurator Subsystem Configurator Configuration manager Memory Monitor Configu- rator 1 Configu- rator 2 Configu- rator n 5

Figure 3. Aggregator-Escalator-Peer Architectural Style [4] This style (Fig. 2) assigns a monitor component to each condition or aspect of the system that should be monitored; furthermore, each monitor has a corresponding configurator to perform the needed adaptations.

escalates to/

escalate to

request

alert escalate to

alert/reply invoke

request request

alert/reply

request

System aspect

Monitor Configurator

Aspect 2 Monitor

Aspect 2 Configurator Aspect N Configurator System Aspect Environment Monitor Environment Configurator Memory Monitor Network Monitor CPU Monitor CPU Configurator Memory Configurator Network Configurator Subsystem Configurator Configuration manager Memory Monitor Configu- rator 1 Configu- rator 2 Configu- rator n 5 Figure 4. Chain-of-Configurators Architectural Style [4]

5 Quantitative Measurement of

Archi-tectural Styles for Self-healing

Sys-tems

As explained in Section4.1, since quality attributes, such asreliability andmaintainability are influenced by an architectural style, selecting an appropriate style becomes a significant concern in designing software

and satisfying users’ requirements [17]. On the other hand, the main purpose of developing a self-healing system as an adaptive system is meeting quality at-tributes such asavailability,durability,maintainability andreliabilityof the system [2]. Among others, main-tainability is influenced by software cohesion and cou-pling [20] meaning that by increase/decrease of cou-pling/cohesion between software components, main-tainability will be reduced. In the following sections, we use the proposed coupling and cohesion metrics for measuring the satisfaction score of qualities gained by the reference styles (see Section4.4).

5.1 The Coupling Measurement Method

As stated in Section2, Hawthorne and Perry proposed three architectural styles for self-healing systems [4] but they didn’t propose any method for measuring the coupling and cohesion of those styles. In this arti-cle, we generalized the concept of “module coupling” to coupling of software architecture components and used it to measure the coupling degree of the software architectural styles for self-healing systems. We con-sider the relation between monitors and configurators (see the previous section) as a coupling relation be-cause they are two separate components. The coupling of a style is calculated in regard to the type of cou-pling and the number of components that the style is composed of. The more the coupling between the style components increases, the more theunderstandability, correctness andmaintainability of the style decrease [20].

We compute the coupling value of a style (consist-ing of monitors or configurators) as sum of coupl(consist-ing values of its components (indicated by CPS, Equa-tion (1). Similarly, the coupling value of a component is calculated as sum of its couplings to other compo-nents (Equation (2), where notation k denotes the number of couplings between componenti and other components, and notationwj indicates the weight of coupling between componentsi andj, indicated by CPj, see Table 1in Section 4.3. By increasing the style’s coupling (i.e.CPS in Equation (1) of compo-nents, themaintainabilitywill reduce [20] ; this means the coupling and maintainability are inversely related. Measuring coupling of software architectural styles for self-healing systems is explained in Section5.3.

CP S= n X

i=1

CP Ci (1)

CP Ci= k X

j=1

(6)

5.2 The Cohesion Measurement Method

In this article, we generalized the concept of “module cohesion” for the cohesion of software components and used it to measure the cohesion values of software architectural styles. For example, jointly performing a special task by two or more consolidated component modules can be considered as cohesion. The more the cohesion of components increases, the more the understandability, modifiability, and maintainability of the components increase. Similar to Equations (1) and (2), the cohesion of a style (indicated byCHS) and its components (indicated byCHC) are computed as Equations (3) and (4) (see Table2).

CHS= n X

i=1

CHCi (3)

CHCi= k X

j=1

wj∗CHj (4)

By increasing the cohesion between the components, the softwaremaintainability will increase. In fact, the cohesion and maintainability are directly related to-gether. The cohesion measurement of software archi-tectural styles for self-healing systems is explained in Section5.4.

5.3 Measuring the Style Coupling

(1) Aspect-peer-to-peer style: This

architec-tural style thinks of the software as a set of independent elements. The monitor and its re-spective configurator belong to an element and there is no relation between elements. Thus, such a strict peer-to-peer approach decreases coupling. It can be useful when configurators can decide based on just their respective moni-tors and not monimoni-tors of other components. This means that the configurator’s need for the in-formation provided by other monitors leads to Data coupling (See Table 1). Moreover, since monitors may send control flags to configurators, the control coupling may occur between moni-tors and configuramoni-tors. Therefore in this style, there is not coupling of type 1 or 2 (Data or Control). Given that there aren1couplings (con-sisting of n11Data andn12 Control couplings) between a component and other components, the style coupling is computed as Equation (5) (see Equations (1) and (2) and Table1). Note that coupling between two components is taken into account just one time.

n1 X

i=1

CP Ci= n11 X

1 w1+

n12 X

1

w2=n11w1+n12w2 (5)

(2) Aggregator-escalator-peer style: This

ar-chitectural style contains a set of independent elements arranged in a hierarchical structure. Each monitor component sends data to its upper-level monitor, which indicates a Data Coupling. The upper-level monitors pack data received from the lower-level and pass them to a peer configurator, which indicates a Stamp Cou-pling. Moreover, each upper-level monitor sends a control flag to its respective configurator, which denotes a Control Coupling. Configura-tors use the data received from the upper-level configurators, which denotes a Common Cou-pling. Therefore, between each two components of this style there exist at most 4 coupling types (Data, Stamp, Control, and Common). Given that there aren2 couplings (consisting of n21 Data,n22 Sample, n22 Control, and n21 Com-mon couplings) between two components, the style coupling is computed as Equation (6) (see Equations (1) and (2) and Table1). Note that coupling between each two components is taken into account just once.

n2 X

i=1

CP Ci= n21 X

1 w1+

n22 X

1 w3+

n22 X

1 w3+

n21 X

1 w3

=n21w1+n22w2+n22w3+n21w4 (6)

configurators collaborate to carry out tasks where each configurator passes data to its ad-jacent after completing its task. The process continues until performing all tasks successfully. [10]. Therefore, there is a Data Coupling be-tween each two configurators except for the last one, which has no more configurators to send the data to. This is why there exists just one coupling between each two components of this style. Accordingly, for an architecture consisting of n3 components, the total style coupling is computed as Equation (7).

n3 X

i=1

CP Ci= n3 X

1

w1= (n3−1)w1 (7) Below, the coupling equations for the three reference styles are shown.

(7)

n1 X

i=1

CP Ci= n11 X

1 w1+

n12 X

1 w2

=n11w1+n12w2 Aggregator-escalator-peer:

n2 X

i=1

CP Ci= n21 X

1 w1+

n22 X

1 w3+

n22 X

1 w3+

n21 X

1 w3

=n21w1+n22w2+n22w3+n21w4 Chain-of-configurators:

n3 X

i=1

CP Ci= n3 X

1

w1= (n3−1)w1

5.4 Measuring Style Cohesions

(1) Aspect-peer-to-peer style: In this style,

each element includes a monitor and its respec-tive configurator; therefore, there isn’t any type of cohesion between them.

(2) Aggregator-escalator-peer style: In this

style for each subsystem of the software there are two monitors, upper-level and lower-level, which they are related to a special aspect of the system. Each lower-level monitor supervises one part of the subsystem and the monitors logically related to. This means that there is Logical cohesion between monitors. Each con-figurator receives data from its upper-level ones, which denotes the existence of Communica-tional cohesion. Accordingly, between each two components in this style there exist at most 2 cohesions (Logical or Communicational type). Given that there arem2cohesions (consisting of m21 Logical andm22 Communicational co-hesions) between each two components, the style cohesion is computed as Equation (8) (see Equations (3) and (4) and Table 2) where c1 andc4are the weight of the Logical and Com-municational cohesions respectively. Note that cohesion between each two components is taken into account just once.

m2 X

i=1

CHCi=m21c1+m22c4 (8)

configurators are chained together and the con-trol passes from one configurator to its adjacent one. Therefore Procedural cohesion exists be-tween them. Furthermore, since data moves from one configurator to the adjacent one, Sequential cohesion exists. Therefore, between each two components in this style there exist at most 2 co-hesions (Procedural or Sequential type). Given

that there arem3 couplings (consisting ofm31 Procedural andm32 Sequential couplings) be-tween two configurators, the style cohesion is computed as Equation (9) (see Equations (3) and4 and Table 2) where c3 and c5 indicate the weight of the Procedural and Sequential co-hesions. Note that cohesion between each two configurators is taken into account just once.

m3 X

i=1

CHCi= (m31−1)c3+ (m32−1)c5 (9) Below the cohesion equations for three reference architectural styles are shown.

Aspect-peer-to-peer: Zero

Aggregator-escalator-peer:m21c1+m22c4

Chain-of-configurators: (m31−1)c3+ (m32−1)c5

6 Case Study: Wireless Body Area

Network

Nowadays, in many countries, the cost of health care is rising sharply. However, the main cause of more than 30% of deaths is the cardiovascular disease that most of them can be prevented by health care [23]. This has culminated in introducing the new systems that constantly monitor a patient. Among others, Wireless Body Area Networks (WBAN) is a system that constantly monitors medical parameters of the patient’s body and may be used with the patient in the hospital, at home or on the move.

A WBAN system contains various sensors implanted in the patient’s body or worn by the patient for receiv-ing/ sending data from/to the patient’s body. These sensors send the medical information to an external server such as a pocket PC lying outside of the pa-tient’s body (for instance, in the papa-tient’s clothing pocket). The server is responsible for storing, main-taining and analyzing patient’s body data[24]. Since the wired connections between the server and the pa-tient are difficult and expensive to handle, wireless connections are used. WBANs have the ability to self-heal patients leading to mitigation of the need for continuous surveillance by the physician.

6.1 Sensors and Actuators

Generally speaking, a WBAN system consists of

Sen-sorsandActuators[25] (Figure 5), where sensors

(8)

the patient interaction.

For a diabetic, for instance, an actuator is equipped with a built-in reservoir and pump so it can control the patient’s glucose level by injecting the correct dose of insulin based on the glucose level by sensors. Additionally, a personal device such as a phone can be used to interact with the user. Now, we explain components of a WBAN system. The received data from the sensors and actuators are assembled by a Wireless Personal Device (WPD) to determine the patient’s status and inform him/her via an external element.

As Figure5shows, sensors located in the patient’s clothing, on the patient’s body and under the patient’s skin for measuring parameters such as temperature, blood pressure, heart rate, heart electrical changes, brain electrical activity and respiration rate. The ac-tuators’ task is injecting medication into the patient’s body where the injection time can be pre-determined or triggered by an external source or determined by computing some monitored parameters.

An example is monitoring blood glucose levels of di-abetic patients; if, the glucose level sensor shows a sudden drop in the patient’s glucose, a signal will be sent to the respective actuator to begin the process of injecting insulin. In addition, a WBAN system can be used to help disabled persons. For example, a par-alyzed person can be equipped with:(1) sensors to help him/her in determining his/her location and (2) actuators to help him/her move [25]. In this section, software architectural styles for a WBAN system are considered (see Figure 5). Then, based on the mea-surement method introduced in Section5, we measure the coupling and cohesion of the WBAN system in the presence of the three reference styles. As explained in Section4, in implementing the system through soft-ware architectural styles for self-healing systems, the monitor andconfigurator components are used. In a WBAN system,sensorsandactuatorsact asmonitors andconfigurators respectively.

6.2 Design of WBAN Using

Aspect-Peer-to-Peer Style

Table3shows the design of the WBAN system us-ing the aspect-peer-to-peer architectural style where: (1) sensors have been intended for: Electroencephalo-gram (EEG), auditory, motion, position, Electrocar-diogram (ECG), heart rate, blood, fingertip, blood pressure, and blood oxygen and (2) actuators have been included in hearing aid cochlear implant, artifi-cial knee, artifiartifi-cial arm, blood pump, insulin injection, and pacemaker.

9

6.1. Sensors and Actuators

Generally speaking, a WBAN system consists of Sensors and Actuators (Fig. 5, Li & Kohno 2008) where sensors measure the patient’s medical parameters such as, glucose level, heartbeat, body temperature or heart electrical changes and actuators are responsible for performing suitable actions on the patient’s body according to the data received from the sensors or through the patient interaction. For a diabetic, for instance, an actuator is equipped with a built-in reservoir and pump so it can control the patient’s glucose level by injecting the correct dose of insulin based on the glucose level by sensors. Additionally, a personal device such as a phone can be used to interact with the user. Now, we explain components of a WBAN system. The received data from the sensors and actuators are assembled by a Wireless Personal Device (WPD) to determine the patient’s status and inform him/her via an external element. As Fig 5 shows sensors located in the patient’s clothing, on the patient’s body and under the patient’s skin for measuring parameters such as temperature, blood pressure, heart rate, heart electrical changes, brain electrical activity and respiration rate.The actuators’ task is injecting medication into the patient’s body where the injection time can be pre-determined or triggered by an external source or determined by computing some monitored parameters. An example is monitoring blood glucose levels of diabetic patients; if, the glucose level sensor shows a sudden drop in the patient’s glucose, a signal will be sent to the respective actuator to begin the process of injecting insulin.In addition, a WBAN system can be used to help disabled persons. For example, a paralyzed person can be equipped with: (1) sensors to help him/her in determining his/her location and (2) actuators to help him/her move (Li & Kohno 2008). In this section, software architectural styles for a WBAN system are considered (see Fig. 5). Then, based on the measurement method introduced in Section 5, we measure the coupling and cohesion of the WBAN system in the presence of the three reference styles. As explained in Section 4, in implementing the system through software architectural styles for self-healing systems, the monitor and configurator components are used. In a WBAN system, sensors and

actuators act as monitors and configurators respectively.

Table 5. Design of WBAN using the Fig. 5. A typical WBAN system

aspect-peer-to- peer style (Li & Kohno 2008)

6.2. Design of WBAN using aspect-peer-to-peer style

Table 5 shows the design of the WBAN system using the aspect-peer-to-peer architectural style where: (1) sensors have been intended for: Electroencephalogram (EEG), auditory, motion, position, Electrocardiogram (ECG), heart rate, blood, fingertip, blood pressure, and blood oxygen and (2) actuators have been included in hearing aidcochlear implant,artificial knee, artificial arm, blood pump, insulin injection,and pacemaker.

Sensor name (connected actuators)

Actuator name S1 EEG (A2, A3) A1 Hearing aid

S2 Audiometry (A1) A2 Artificial knee

S3 Motion

(A2, A3, A5, A6)

A3 artificial arm

S4 Positioning

(A2, A3, A5, A6)

A4 Blood pump

S5 ECG (A4) A5 Insulin injection

S6 Heartbeat

(A4, A8)

A6 Injection blood

pressure increaser/ decreaser S7 Blood (A5) A7 Blood oxygen

S8 Fingertip (A5) A8 pacemaker

S9 Blood pressure

(A6)

S10 Oxygen (A7)

EEG

Positioning Insulin Injection Glucose

Lactic acid Artificial knee

Hearing aid Motion sensor Blood pump ECG Blood oxygen Personal device

Artificial knee

Pressure sensor

Figure 5. A Typical WBAN System [25]

6.2.1 Identifying the System Components

To design the WBAN software using the aspect-peer-to-peer style, we need to identify the WBAN compo-nents for this style. There exist 10 sensors (monitors), each connected to some actuators (configurators) con-stituting a component (Table3). The ECG sensor, for instance, is connected to the artificial knee and arm actuators, which constitutes a component consisting of a monitor and two configurators.

An actuator as a configurator may be present in a number of components; the artificial knee actuator, for instance, is connected to three sensors, which each combination constitutes a component (Table3). Each component is responsible for a specific task. For ex-ample, the component including the injector actuator and the blood pressure detection sensor is meant to inject the drug for adjusting the patient’s blood pres-sure when the prespres-sure detection sensor finds high pressure. Furthermore, this actuator needs to receive data from motion and position sensors, which shows collaboration between components.

6.2.2 Measuring the Coupling and Cohesion

(9)

Table 3. Design of WBAN Using the Aspect-Peer-to-Peer Style

S# Sensor Name (Connected Actuators) A# Actuator Name

S1 EEG (A2, A3) A1 Hearing Aid

S2 Audiometry (A1) A2 Artificial Knee

S3 Motion(A2, A3, A5, A6) A3 Artificial Arm

S4 Positioning(A2, A3, A5, A6) A4 Blood Pump

S5 ECG (A4) A5 Insulin injection

S6 Heartbeat(A4, A8) A6 Injection blood pressure increaser/ decreaser

S7 Blood (A5) A7 Blood Oxygen

S8 Fingertip (A5) A8 Pacemaker

S9 Blood Pressure(A6) S10 Oxygen (A7)

are obtained for other actuators. Taking into account the data and control couplings mentioned above and based on Table 1, the coupling value of the aspect-peer-to-peer architectural style is calculated as:

CP S=w1(2 + 2 + 1 + 3 + 2) +w3(1 + 3 + 3 + 1) = 1×10 + 3×8 = 34

As explained in Section 5.4, the aspect-peer-to-peer architectural style has no cohesion; therefore, the cohesion value for this style is zero.

6.3 Design of WBAN Using

Aggregator-Escalator Style

Figure 6 shows the design of WBAN using the aggregator-escalator-peer architectural style.

6.3.1 Identifying the System Components

and Measuring Coupling and Cohesion

Figure6shows the WBAN configuration according to the aggregator-escalator style where individual moni-tors (sensors) and configuramoni-tors (actuamoni-tors) are aggre-gated to 4 complex monitors and 4 complex configura-tors respectively. As Figure6shows, 8 of 10 WBAN’s sensors constitute two separate complex monitors called ”motion” (including 3 individual sensors) and ”heart and blood” (including 7 individual sensors). These two complex sensors contain some common sen-sors such asmotionandpositioning;and 2 individual sensors, ”oxygen detection” and ”audiometry”, each one by itself constitute a separate monitor. Accord-ingly, there exist four monitors and similarly, four configurators in this style.

We measure the coupling value of the

aggregator-escalator-peer architectural style for the WBAN sys-tem according to Equation (6). Each individual moni-tor sends its data to its respective complex monimoni-tor; therefore, there is adata coupling whose value is equal to the number of the individual monitors. Furthermore, each complex monitor collects data from its individu-als and sends them to the corresponding actuator; this represents thestamp coupling. Moreover, each com-plex monitor sends a control flag to the corresponding actuator for announcing a new event; this indicates thecontrol coupling,and therefore the total control coupling is equal to the number of complex monitors. Similarly, the individual actuators use the complex ones’ data, which indicates thecommon coupling.

According to couplings mentioned above, the cou-pling value of the aggregator-escalator-peer style for the WBAN system is calculated as:

CP S= 10w1+ 2 (w2+w3) + 6w4 = 10 + 10 + 24 = 44

(10)

40 A Method for Assessing Maintainability of Software Architectural Styles . . . — A. Farrokh and S.M. Babamir 6.2.1. Identifying the system components

To design the WBAN software using the aspect-peer-to-peer style, we need to identify the WBAN components for this style. There exist 10 sensors (monitors), each connected to some actuators (configurators) constituting a component (Table 5). The ECG sensor, for instance, is connected to the artificial knee and arm actuators, which constitutes a component consisting of a monitor and two configurators.

An actuator as a configurator may be present in a number of components; the artificial knee actuator, for instance, is connected to three sensors, which each combination constitutes a component (Table 5). Each component is responsible for a specific task. For example, the component including the injector actuator and the blood pressure detectionsensor is meant to inject the drug for adjusting the patient’s blood pressure when the pressure detection sensor finds high pressure. Furthermore, this actuator needs to receive data from motion and position sensors, which shows collaboration between components.

6.2.2. Measuring the coupling and cohesion

According to Eq. 5, we deal with measuring the WBAN software coupling when the software is designed using the aspect-peer-to-peer architectural style. Since, as well as receiving data from own sensor, the artificial knee actuator obtain data from two other sensors, there are two data couplings. Furthermore, since in addition to obtaining data from own sensor, the blood pump actuator acts based on data received from another sensor, there is a data coupling. Similarly, the rest of data couplings are obtained for other actuators. Since the EEG sensor sends a control flag to its own actuator and another one, there is a control coupling. Similarly, the rest of control couplings are obtained for other actuators. Taking into account the data and control couplings mentioned above and based on Table 3, the coupling value of the aspect-peer-to-peer architectural style is calculated as:

𝐶𝑃𝑆 = 𝑤1(2 + 2 + 1 + 3 + 2) + 𝑤3(1 + 3 + 3 + 1) = 1 × 10 + 3 × 8 = 34

As explained in Section 5.4, the aspect-peer-to-peer architectural style has no cohesion; therefore, the cohesion value for this style is zero.

6.3. Design of WBAN using aggregator-escalator style

Fig. 6 shows the design of WBAN using the aggregator-escalator-peer architectural style.

EEG motion positioning artificial artificial ECG insulin knee arm injection

blood blood pressure motion blood pacemaker pump

injection heartbeat positioning fingertip blood pressure

oxygen detection injection blood oxygen

audiometry hearing aid

Fig. 6. The WBAN system design using the Aggregator-escalator-peer architectural style

6.3.1. Identifying the system components and measuring coupling and cohesion

Fig. 6 shows the WBAN configuration according to the aggregator-escalator style where individual monitors (sensors) and configurators (actuators) are aggregated to 4 complex monitors and 4 complex configurators respectively. As Fig. 6 shows, 8 of 10 WBAN’s sensors constitute two separate complex monitors called "motion" (including 3 individual sensors) and "heart and blood" (including 7 individual sensors). These two complex sensors contain some common sensors such as motion and positioning; and 2 individual sensors, "oxygen detection" and "audiometry", each one by itself constitute a separate monitor. Accordingly, there exist four monitors and similarly, four configurators in this style.

Motion monitor Motion actuator Heart & blood monitor Motion monitor

10 Figure 6. The WBAN System Design Using the Aggregator-Escalator-Peer Architectural Style

Figure 7. Design of the WBAN system using chain-of-configurators style

CHS=c1(3 + 7) +c4(2 + 4) = 10 + 4×6 = 34

6.4 Design of WBAN Using Chain-of-

Config-urators Style

As Figure7shows, there are a sensor (monitor) and seven actuators. In this style, actuators are chained to-gether in the form of a linear structure where data are flowed among actuators. This denotesdata coupling (see Equation (8)) whose value is calculated as:

CP S= (n−1)w1= (8−1)w1= 7×1 = 7 The cohesion value of the chain-of-configurators style for the WBAN is calculated according to Equa-tion (9). In this style, a sequence of operations is flowed through actuators; this indicates there is pro-cedural cohesion for each actuator except the last one. Furthermore, we havesequential cohesionfor each ac-tuator except the last one because the output of each actuator is used as input to its adjacent one. Since the WBAN system is composed of 8 actuators, the cohesion value of the chain-of-configurators style is calculated as:

CHS= (8−1)c3+ (8−1)c5 = 7×3 + 7×5 = 21 + 35 = 56 Figure 8shows the coupling and cohesion values of the three different reference styles for the design of the WBAN system. As Figure8shows, the

chain-Fig. 8. The coupling and cohesion values of styles for design of the WBAN system

7 Conclusions

In this article, we first found the significance of coupling and cohesion in assessing the support of

maintainability quality attribute by software architectural styles. The support assessment was quantified by proposing metrics for measuring the coupling and cohesion values. To show the significance of the metrics, we applied them to a self-healing system called the Wireless Body Area Network.

Our second finding was the way of using the reference software architectural styles for the design of self-healing systems so that one can evaluate the design using coupling and cohesion criteria. It was shown by applying the method to WBAN self-healing system. We showed the comparison mechanism that one can establish for types of system designs obtained from software architectural styles for self-healing systems. Through the proposed mechanism, we concluded the best style from the coupling and cohesion points of view is the chain-of-configurators style for the WBAN system, when our concern is the system maintenance on account of the lowest coupling and the most cohesion values.

References

Bass, L., Clements, P., & Kazman, R. (2012). Software Architecture in Practice (3rd_{Edition), Addison-Wesley}_.

Berns, A. & Ghosh, H. (2009). Dissecting Self-* Properties, The 3rd IEEE International Conference on Self-Adaptive and Self-Organizing Systems, pp. 10-19.

Brun et al. (2009). Engineering Self-Adaptive Systems through Feedback Loops. Self-Adaptive Systems, LNCS, Springer, 5525, pp. 48-70.

Cheng, S. W., & Garlan, D. (2007). Handling Uncertainty in Autonomic Systems. The 22nd_IEEE/ACM

International Conference on Automated Software Engineering.

Clements et al. (2011). Documenting Software Architectures Views and Beyond, The 2nd_Edition,

Addison-Wesley.

Fenton, N., & Bieman, J. (2014). Software Metrics: A Rigorous and Practical Approach, The 3rd_Edition,

Chapman & Hall/CRC.

Fenton, N., & Melton, A. (1990). Deriving Structurally Based Software Measures. Journal of Systems and Software, 12(3), pp. 177-187.

Garlan, D., Schmerl, B., & Cheng, S.W. (2009). Software Architecture-Based Self-Adaptation. Chapter 1 of Book Autonomic Computing and Networking, Eds., Denko M.K. et al., Springer, pp. 31-55.

Ha, I. (2015). Technologies and Research Trends in Wireless Body Area Networks for Healthcare: A Systematic Literature Review. International Journal of Distributed Sensor Networks, Article ID 573538, doi: 10.1155/2015/573538.

0 10 20 30 40 50 60

coupling cohesion

Aspect-peer-to-peer architectural style Aggregator-escalator-peer architectural style Chain-of-configurators architectural style

12 Figure 8. The coupling and cohesion values of styles for design

of the WBAN system

of-configurators style has the lowest/the most cou-pling/cohesion value in comparison with other ones; consequently, it is the best style from the maintain-abilitypoint of view.

7 Conclusions

(11)

proposing metrics for measuring the coupling and co-hesion values. To show the significance of the metrics, we applied them to a self-healing system called the Wireless Body Area Network. Our second finding was the way of using the reference software architectural styles for the design of self-healing systems so that one can evaluate the design using coupling and cohe-sion criteria. It was shown by applying the method to WBAN self-healing system. We showed the com-parison mechanism that one can establish for types of system designs obtained from software architec-tural styles for self-healing systems. Through the pro-posed mechanism, we concluded the best style from the coupling and cohesion points of view is the chain-of-configurators style for the WBAN system, when our concern is the systemmaintenance on account of the lowest coupling and the most cohesion values.

Acknowledgements

Authors like to thank University of Kashan for sup-porting this study by Grant No. 92/6188.

References

[1] Harald Psaier and Schahram Dustdar. A survey on self-healing systems: approaches and systems. Computing, 91(1):43–73, 2011.

[2] Chris Schneider, Adam Barker, and Simon Dob-son. A survey of self-healing systems frameworks. Software: Practice and Experience, 45(10):1375– 1398, 2015. ISSN 1097-024X. doi: 10.1002/spe. 2250. URL http://dx.doi.org/10.1002/spe. 2250.

[3] Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, and Judith Stafford. Documenting Software Ar-chitectures: Views and Beyond. Addison-Wesley Professional, 2011.

[4] Matthew J Hawthorne and Dewayne E Perry. Architectural styles for adaptable self-healing de-pendable systems. InProceedings of IEEE/ACM International Conference on Software Engineer-ing (ICSE 2005), 2005.

[5] Len Bass, Paul Clements, and Rick Kazman. Soft-ware Architecture in Practice. Addison-Wesley Longman Publishing Co., Inc., 3rd edition, 2013. [6] L. S. Maurya. Comparison of software archi-tecture evaluation methods for software qual-ity attributes. Journal of Global Research in Computer Science, 1(4):1–8, 2010. ISSN 2229-371X. URL http://www.jgrcs.info/index.

php/jgrcs/article/view/172.

[7] Zhao Li and Jiang Zheng. Toward industry friendly software architecture evaluation. In

Soft-ware Architecture, pages 328–331. Springer, 2013. [8] S. Neti and H.A. Muller. Quality criteria

and an analysis framework for self-healing sys-tems. InSoftware Engineering for Adaptive and Self-Managing Systems, 2007. ICSE Workshops SEAMS ’07. International Workshop on, pages 6–6, May 2007. doi: 10.1109/SEAMS.2007.15. [9] HaiCan Peng and Feng He. Software

trustworthi-ness modeling based on interactive markov chains. InProceedings of the International Conference on Information Technology and Computer Applica-tion Engineering (ITCAE 2013), page 219. CRC Press, 2013.

[10] Qin Zhu, Lei Lin, Holger M Kienle, Hausi Muller, et al. Characterizing maintainability concerns in autonomic element design. InSoftware Main-tenance, 2008. ICSM 2008. IEEE International Conference on, pages 197–206. IEEE, 2008. [11] Yuriy et al. Brun. Engineering self-adaptive

sys-tems through feedback loops. In Software en-gineering for self-adaptive systems, pages 48–70. Springer, 2009.

[12] Thomas Vogel and Holger Giese. Model-driven engineering of self-adaptive software with eurema. ACM Transactions on Autonomous and Adaptive Systems (TAAS), 8(4):18, 2014.

[13] Shang-Wen Cheng and David Garlan. Handling uncertainty in autonomic systems. InProceedings of the International Workshop on Living with Uncertainties (IWLU07). Citeseer, 2007.

[14] A. Berns and S. Ghosh. Dissecting self-* prop-erties. InSelf-Adaptive and Self-Organizing Sys-tems, 2009. SASO ’09. Third IEEE International Conference on, pages 10–19, Sept 2009. doi: 10.1109/SASO.2009.25.

[15] Ozalp Babaoglu, M´ark Jelasity, Alberto Mon-tresor, Christof Fetzer, Stefano Leonardi, Aad Moorsel, and Maarten Steen. Self-star Proper-ties in Complex Information Systems: Conceptual and Practical Foundations. Springer Berlin Hei-delberg, 2005. ISBN 978-3-540-32013-5. doi: 10. 1007/11428589 1. URL http://dx.doi.org/

10.1007/11428589_1.

[16] David Garlan, Bradley Schmerl, and Shang-Wen Cheng. Software architecture-based self-adaptation. In Autonomic computing and net-working, pages 31–55. Springer, 2009.

[17] Chiyoung Seo, G. Edwards, S. Malek, and N. Med-vidovic. A framework for estimating the impact of a distributed software system’s architectural style on its energy consumption. InSoftware Ar-chitecture, 2008. WICSA 2008. Seventh Working IEEE/IFIP Conference on, pages 277–280, Feb 2008. doi: 10.1109/WICSA.2008.28.

(12)

Switzer-42 A Method for Assessing Maintainability of Software Architectural Styles . . . — A. Farrokh and S.M. Babamir

land: International Organization for Standardiza-tion, 2001.

[19] Mazeiar Salehie and Ladan Tahvildari. Self-adaptive software: Landscape and research chal-lenges. ACM Transactions on Autonomous and Adaptive Systems (TAAS), 4(2):14, 2009. [20] Shari Lawrence Pfleeger and Joe Atlee. Software

engineering: Theory and practice, 2006. ISBN: 0-13-0290490-1, 2005.

[21] Norman Fenton and James Bieman. Software metrics: a rigorous and practical approach. CRC Press, 2014.

[22] Norman Fenton and Austin Melton. Deriving structurally based software measures. Journal of Systems and Software, 12(3):177–187, 1990. [23] J.O. Kephart and W.E. Walsh. An artificial

intel-ligence perspective on autonomic computing poli-cies. InPolicies for Distributed Systems and Net-works, 2004. POLICY 2004. Proceedings. Fifth IEEE International Workshop on, pages 3–12, June 2004.

[24] Ilkyu Ha. Technologies and research trends in wireless body area networks for healthcare: A systematic literature review. International Jour-nal of Distributed Sensor Networks, 2015:4:4– 4:4, January 2015. ISSN 1550-1329. doi: 10. 1155/2015/573538. URLhttp://dx.doi.org/

10.1155/2015/573538.

[25] Huan-Bang Li, K.-i. Takizawa, Bin Zhen, and R. Kohno. Body area network and its standard-ization at ieee 802.15.mban. InMobile and Wire-less Communications Summit, 2007. 16th IST, pages 1–5, July 2007.

Azam Farrokhreceived a Bachelor of Sci-ence degree in software engineering from the University of Qom, Qom, Iran, 2010 with the thesis of “Simulation of nanoscale electrical discharge using MATLAB”. She received a Master of Science degree in Software Engi-neering from the University of Kashan, Kashan, Iran, 2012 with the thesis of “Quality evaluation of software architecture styles using architectural tactics”. She has already authored 6 international and internal conference papers.

Seyed Morteza Babamirreceived BS de-gree in Software Engineering from Ferdowsi University of Meshhad and MS and PhD de-grees in Software Engineering from Tarbiat Modares University in 2002 and 2007 respec-tively. He was a researcher at Iran Aircraft Industries, Tehran, Iran, from 1987 to 1993, head of Computer Center in University of Kashan, Kashan, Iran, from 1997 to 1999 and head of Computer Engineering Department in University of Kashan from 2002 to 2005. He is associate professor of Computer Engineering Department in University of Kashan. He authored one book in Software Testing, 4 book chapters, 20 journal papers and more than 50 international and internal conference papers (http://ce.kashanu.ac.ir/

babamir/Publication.htm). He is managing director of Soft