Engineering Dependability to Embedded Systems Software via Tactics

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

Engineering Dependability to Embedded Systems Software via Tactics Saleh H. Al-Daajeh1, Rafa E. Al-Qutaish2, Fuad Al-Qirem1 1

Department of Software Engineering, Al-Zaytoonah University of Jordan, Amman, Jordan 2 Department of MIS, Al Ain University of Science & Technology - Abu Dhabi Campus, Abu Dhabi, UAE [email protected], [email protected], [email protected] Abstract Embedded systems are used in many critical applications of our daily life. The increased complexity of embedded systems and the tightened safety regulations posed on them and the scope of the environment in which they operate are driving the need of more dependable embedded systems. Therefore, achieving a high level of quality and dependability to embedded systems is an ultimate goal. This research study investigates the inter-relationships between dependability and other embedded systems quality attributes using two pieces of information: Tactics and Dependability Quality attributes scenarios. Keywords: Real-Time Systems Embedded Systems, Dependability, Software Architecture, Software Architecture Strategies, Software Quality Attributes Relationships, Tradeoffs, ISO 9126, Quality Models.

1. Introduction When developing an embedded system, quality is a key characteristic, on its own or its implications. Thus, managing embedded systems‟ software quality is necessary to deliver an embedded system functioning in a useful, safe and reliable way. Embedded systems pervade modern society. From consumer electronics, to automobiles, to satellites, they represent one of the largest segments of the software industry. Since embedded systems are so pervasive, our society has come to depend on these systems for its day-to-day operations. An Embedded System is a computer system designed to perform certain dedicated functions [1]. The IEEE Standard Glossary of Software Engineering Terminologies defines embedded systems software as a part of a larger system which performs some of the requirements of that system [2]. The study of embedded systems shows that the various types of embedded systems share four common requirements such as: dependability, real-time constraints, resource consumption and a long operational life-cycle [3]. However, due to embedded systems‟ operational environment characteristics and the fore stated common requirements embedded systems are also known as safety-critical systems and real-time systems [1] [4]. Therefore, embedded systems are required to be dependable from failures, mishaps and attacks as well. For various types of systems, dependability consists of a small subset of quality attributes: Availability, Reliability, Integrity, Confidentiality, Safety, and Maintainability [5].

45

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

There are several approaches to be undertaken at different development stages to achieve dependability to a system [6]. Unfortunately, in most cases, the development of embedded systems faces many conflicts, and dependability is introduced at later stages [1] [7] [8]. The relationship between quality attributes exists [9]. Furthermore, the understanding of quality attributes relationships minimizes the chances of the occurrence of unwelcome system behavior during runtime and it increases the chances that the developed system will meet its specifications [7]. Additionally, it aids in supporting the prioritization of quality attributes for a system [10]. Thus, the understanding of the relationships between quality attributes is important to sustain a sufficient level of quality to the software system and its development processes [11]. This study is focused on increasing the likelihood of dependability of embedded systems at the software architecture stage. Nevertheless, this research investigates the relationships between dependability and other embedded systems qualities attributes, and provides systematic application of the quality attributes relationships reasoning framework proposed by Al-Daajeh et al. [11] in order to compromise the relationship between embedded systems and dependability different quality attributes [11]. This article is organized as follows: Section 2 further describes related work and the scope of this study. Section 3 systematically explains the quality attributes relationship assessment framework and its application to assess the relationships between dependability and other embedded systems quality attributes. Section 4 further describes the research outcomes. Sections 5 and 6 introduce the research results and elaborate on their applications in the context of real-time systems respectively. The article is concluded in section 7.

2. Background and Motivations This study is primarily concerned with embedded systems and dependability of embedded systems, which is explained in sections 2.1. Software architecture impersonates an important role on the achievement of quality to a software system [12] [13] [14]. Software architecture is further discussed in the context of embedded systems and dependability in section 2.2. In section 2.3, the aforementioned topics are connected by discussing how to ensure that the relevant quality attributes are going to be met in embedded systems software architecture through the use of software architecture evaluations. However, as stated in the introduction, it is always necessary to compromise between different quality attributes, which is further discussed in section 2.4. The section is summarized in 2.5. 2.1 Embedded Systems Dependability Dependability is a very important concern for embedded systems [4] [3]. For various types of systems, dependability is a small subset of quality attributes. According to Avizienis et al. [5] [15], dependability is defined as the property of a system that delivers justifiably services at a reliance level and the ability of the system to avoid failures that are serious and numerous. Dependability quality attributes are defined with respect to what the acceptable behavior is of the system in case of faults, attacks, mishaps and failures that occur when the system is operating, and what the acceptable amount is of effort required for the modifications needed to correct errors. For example, the system can be safe but not dependable by delivering incorrect, late or even early output in some cases. According to the software architecture society, dependability quality attributes can be classified as runtime and non-runtime quality attributes [5]. Moreover, more than one dependability quality attribute can share the same focus to achieve the overall dependability concerns.

46

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

The followings are the dependability quality attributes definitions and classification according to Barbacci et al. [16] and Avižienis et al. [5]: Run-time dependability quality attributes:  Availability: readiness of service for authorized users. It is measured by the duration it would take an intruder to cause a denial of service. This quality attribute focuses on the system behavior versus the faults encountered during the system operation.  Reliability: continuity of service. The system is expected to perform its task in spite of the existence of some faults. This quality attribute is also concerned with demonstrating acceptable behavior of the system when faults are encountered.  Integrity: non-occurrence of improper alternation of information. This quality attribute is concerned with the system behavior in case of attacks.  Confidentiality: non-occurrence of unauthorized disclosure of information as system data and programs are resistant to unauthorized modifications. This quality attribute describes how the system will behave in case of attacks.  Safety: non-occurrence of catastrophic consequences for the user(s) and in the operation environment. This quality attribute describes how the system should deal with mishaps and/or failures when they occur. Non run-time dependability quality attributes:  Maintainability: aptitude to undergo repairs and evolution. This quality attribute demonstrates the ease of modifying the software or system component to correct faults. 2.2 Engineering Quality to Embedded Systems via Software Architecture Usually the second stage of the software development life cycle is the software architecture or a high level design of the system. Software architecture supports the achievement of quality for a software system by providing design decisions and specifications that satisfies the means of quality attributes [12] [13] [14]. Ebert et al. denoted in their study of monitoring quality achievement progress throughout the software development processes that the quality achievement reaches 45% of the total quality before the software exits the virtual architecture quality gate (SAG) [14]. The Software Architecture Society has been active in this field and it has shown how software architecture constrains the achievement of quality [13] [17] [18] [19] [20] [21]. According to Bass et al., software architecture is the structure or structures of the system, which compromise software components, the externally visible properties of those components and the relationships between them [13]. Software architecture is documented via multiple methodologies and structured via different styles. Thus the architecture of embedded systems software provides the foundation on which system developers can achieve quality throughout the system development processes and evaluate a system‟s design in respect to the desired quality attributes [13] [17] [22]. Most importantly, the achievement of dependability quality attributes in the software development process is strongly related to the software architecture. The achievement of quality attributes for a system in software architecture can be separated into two levels, that is, the requirements and solutions. The software

47

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

architecture community has developed several frameworks used to elicit, specify and categorize quality requirements [13] [23] [24]. These frameworks are used to create what is known as quality attributes general scenarios, which help in developing quality attributes concrete scenarios and therefore assist in evaluating software architectures [13]. General scenarios can be used as a template to define concrete scenarios for quality attributes scenarios. Quality attributes concrete scenarios are methods to create a description of the problem (constraint or requirement) which questions whether the software architecture candidate solutions satisfies the desired non-functional requirements set on the system or not [6]. The solution for achieving software quality attributes during the software architecture stage is supported by selecting appropriate architectural strategies or “tactics” [13]. Tactics are known as design decisions that influence and control the response of quality attributes [13] [20]. Bass et al. [13] and Wu et al. [25] have suggested multiple tactics to support the achievement of different dependability quality attributes to a system. However, most of these tactics are conducted based on experience rather than theory [26]. The software architecture in terms of connectors and components provide a starting point for revealing the areas of potential change which might affect the sys tem dependability. The overall achievement of dependability is dependent on the individual achievement of its subset of quality attributes. Larsson [4] stated that the software‟s dependability quality attributes achievement is strongly related to the softw are architecture stage of the software development life cycle. Moreover, architectural level reasoning of dependability is an important theme to consider while developing dependable embedded systems software. 2.3 Software Architecture Evaluation To achieve quality for a software system at the architecture stage, it is important to evaluate the system architecture with respect to the desired quality and the requirements placed on the system. In general, the evaluation of software architecture aims at providing evidence as to whether the architecture is suitable with respect to its functional and nonfunctional requirements. Software architecture evaluation methods are usually based on critical analysis of how the system fulfills its specification. There are several methods that can be used to assess software architecture and predict the quality of software at the architectural level (e.g. ATAM, SAAM, etc.) [13]. Furthermore, Kazman et al. [24] identified two general categories suggested for software architecture evaluation methods which are Qualitative Analysis and Quantitative Measurement. The qualitative analysis of software architecture is usually based on questionnaires, checklists, and scenarios. On the other hand, quantitative measurements consist of simulations and metrics, for example modeling and testing. Quantitative measurement aims at estimating the fulfillment of a quality attribute in terms of probabilities [7] [24]. Nevertheless, there are several studies conducted to evaluate architectural styles / patterns that support different quality attributes [13] [21] [27]. Further recommendations on software architecture evaluation methods can be found in [19] [21]. Software architecture evaluation does not only help the evaluators to be able to reason about the achievement of software quality attributes and to have a certain level of predictability of the system‟s behavior, but it also helps to select suitable tactics to achieve the desired quality attributes and hence supports the trade -offs and therefore the

48

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

selection of an appropriate architectural pattern. Objective reasoning is one of the approaches used to assess the software quality requirements achievement in software architecture through reasoning based on logical arguments [20]. However, since des ign strategies are experience-based, the evaluation method adopted in this research is objective reasoning. 2.4 Tradeoffs in Embedded Systems and Dependability Trade-offs is made subconsciously on a daily basis. In embedded systems software development, system quality attributes are among the important subjects that in some situations require trade-offs especially when embedded systems face conflicts in requirements. Trade-offs differs from one situation to another, and a rigorous analysis might be required. Any technique that helps to make or consolidate the trade -off process or decision can be considered as a trade-off technique. Trade-offs can be done via multiple techniques in the same process to evaluate the results. Berander et al. [19] provided a classification of the trade-offs techniques that can be demonstrated into the following three categories:  Experienced based: which depends mainly on the experience for supplying the needed information to performing the trade-off.  Model based: which depends on constructing for example, a graphical model for illustrating the relations between trade-offs entities, thus facilitating the trade-off.  Mathematically based: which relies on mathematical formulas for constructing and representing the tradeoff, thus making it possible to feed the mathematical construct with appropriate values and receiving the best solutions. For example, Analytical Hierarchy Process “AHP”, which helps to control the trade-offs and can help to conduct the right selection depending on the factors that influence the model [28]. The critical part of trade-offs processes is to define the factors that have an impact on the selection of solution(s). However, trade-offs can be made at different levels and can also be constructed of several sub-trade-offs within one level which makes tradeoffs dependent on the depth and strength of analysis required. Software architects are the ones who make the final decisions on how the system shall meet its specifications and customers expectations. In embedde d systems software architecture trade-offs are done at two main levels with respect to software dependability and other quality constraints. The first level is to prioritize the desired system quality attributes, for example, a landing system must have high availability while the system is not required to be reliable for longer periods. The second level of trade-offs is the selection of a software architecture pattern / style that supports the pre-prioritized quality attributes the best way possible [19]. However, in the second main trade-offs a sub-trade-offs is needed in the form of technical reviews. The intention of technical reviews is to evaluate the solution(s) against the predefined specifications and compliance with standards and other documentations [28]. In this sub-tradeoff software architects are required to select and calibrate the best candidate tactics that support dependability quality attributes and have least impact on other quality attributes of the same system software. To make the appropriate selection, there are many factors to consider, for example if the selected architecture tactic supports the achievement of one quality attribute or more and if this tactic has a less negative impact on other system quality attributes and

49

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

could therefore fulfill the constraints made on the system with few undesired or expected consequences. However, software architects must consider the nature of the interrelationships between dependability quality attributes and other quality attributes to select and calibrate the best representative architectural strategies and therefore create an architecture that meets its predefined specifications. 2.5 Summary Dependability is a very important concern for embedded systems. In most cases, embedded systems are required to be dependable from attacks, faults, failures and mishaps when they are released to service. Dependability is a tangible and a high -level quality attribute that consists of six main quality attributes. Dependability quality attributes can be witnessed when the system is running or deactivated. Usually quality attributes can be found as nonfunctional requirements. Hence requirements are seldom elicited and documented in a disciplined way. Software quality attributes are specified with the help of general and concrete scenarios. There are three methods that can be adopted to achieve quality to a software system [18]. One of these three methods is engineering quality to software systems. This method aims to manifest quality attributes requirements at earl y stages of the system development such as software architecture. Hence this research is concerns with the implementation of dependability requirements at early system development stages. We focus on software architecture as it is one of software development initial stages were engineering quality to software system have great influence in achieving quality to software system. Additionally, software architecture plays a vital role and constrains the quality achievement to software system by providing multiple architectural tactics that is capable of satisfying the software quality attributes to some extent. The use of architectural tactics to achieve certain dependability quality attribute affects the achievement of other quality attributes and therefore c reates a relationship that could support or hinder the achievement of other quality attributes or have no impact.

3. Engineering Dependability to Embedded Systems via Tactics Engineering dependability to embedded systems software is done via investigating the dependability quality attributes candidate architectural tactics‟ impact on the achievement of other dependability and embedded systems quality attributes. The impact is evaluated through the application of the quality attributes relationships assessment framework developed by Al-Daajeh et al. Quality attributes‟ relationships assessment framework consists of three main steps, that is, the Preparation, Scenario Development, and Evaluation. In order to produce the promised results of the framework, both “Quality Attribute in Focus” and the “Compared Quality Attributes” must be received at the same level. Furthermore, candidate solutions to achieve the “Quality Attribute in Focus” are architectural strategies “Tactics”. To the knowledge of the investigator, there is only one study that investigates the quality attributes for embedded systems. This study is conducted by Sherman [29]. The embedded systems quality attributes found in the Sherman study are low-level quality attributes and do not only include software quality attributes but also incorporates hardware quality attributes as well. A survey was

50

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

distributed on thirty software engineering master students from the “Blekinge Institute of Technology” to translate the embedded systems quality attributes found in Sherman study to a high level using the ISO 9126 quality model. Table 1 illustrates the translation of embedded systems' quality attributes illustrated from T. Sherman study translated to a higher level using the ISO 9126 quality model [11]. However, the modifications made to the quality attributes assessment framework developed by Al Daajeh et al. [11], are found in the “Preparation Stage”; were embedded systems‟ quality attributes are translated to a higher level. Table 1: Embedded Systems Quality Attributes Translation to High Level Embedded Systems Quality Attributes Found in T. Sherman's Study [29] Code Size Memory Usage CPU Time Used Accuracy Compatibility Complexity, CPU, System, Peripherals, etc. Cost/Schedule Ease of Integration Ease of Use/Usability Expansion Capability Functionality System Resources Usage Versatility/Flexibility Performance Availability Reliability Safety Security Maintenance Durability Physical Size Power Consumption

Quality Attribute Type

Translation Using the ISO-9126 quality model

Level of Agreement

Software Quality Software Quality Software Quality Software & Hardware Quality Software & Hardware Quality

Efficiency Efficiency Efficiency Functionality Portability

100% 100% 93% 100% 93%

Software & Hardware Quality

Efficiency

100%

Software & Hardware Quality Software & Hardware Quality Software & Hardware Quality Software & Hardware Quality Software & Hardware Quality Software & Hardware Quality Software & Hardware Quality Software & Hardware Quality Software & Hardware Quality Software & Hardware Quality Software & Hardware Quality Software & Hardware Quality Software & Hardware Quality Software & Hardware Quality Hardware Quality Hardware Quality

No Equivalence Portability Usability Maintainability/Functionality Functionality Efficiency Maintainability Efficiency No Equivalence Reliability No Equivalence Functionality Maintainability Reliability Efficiency Efficiency

80% 87% 100% 73% 100% 100% 80% 87% 100% 87% 100% 100% 100% 100% 100% 100%

The execution of the developed framework intends to address the relationships between dependability and embedded systems quality attributes. Since the evaluation method is based on experiences and logical argumentation, survey was distributed among different participants from different backgrounds. The evaluation method adopted in the framework can be combined with other assessment or measurement techniques such as Prediction Enable Components Techniques “PECTS”. Figure 1 depicts the framework and its application investigating dependability and embedded systems quality attributes relationships.

51

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

Figure 1: Framework Modification and Application on Embedded Systems Dependability The process of identifying tactics as candidate solutions to a given quality attributes is dependent on quality attributes‟ concerns and characteristics. For example, the dependability quality attributes "„availability and reliability"‟ concerns can be satisfied via adopting the same tactics. Furthermore, security is a composition of both dependability quality attributes "„Integrity and Confidentiality"‟ [30]. Therefore, dependability quality attributes "„Integrity and Confidentiality"‟ share the same tactics which are proposed to achieve the quality attribute "„Security"‟ to a system [13]. The candidate tactics for the dependability quality

52

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

attribute "„Safety"‟ are illustrated directly from the study performed by [25]. The dependability quality attribute "„Maintainability"‟ encloses multiple sub-characteristics and concerns [19] [5]. Therefore, the identification of candidate tactics to achieve the dependability quality attribute "„Maintainability"‟ is based on the achievement of its concerns and sub-characteristics. However, dependability quality attributes candidate tactics are illustrated in table 2, and utilized from [13] and [25]. There are several tactics proposed to achieve different quality attributes that can be found in [13]. Table 2: Dependability Quality Attributes Candidate Architectural Tactics Availability and Reliability Fault Detection:

Integrity and Confidentiality Resisting Attacks:

Safety Failure Detection:

Ping/Echo

Authenticate Users

Timeout

Heartbeat

Authorize Users

Time Strap

Exception

Maintain Data Confidentiality

Sanity Checking

Recovery Preparation and Repair: Voting Active Redundancy Passive Redundancy Spare Recovery Reintroduction: Shadow State Resynchronization: Rollback Prevention: Removal from service Transactions Process Monitor

Maintain Integrity Limit Exposure Limit Access Detecting Attacks: Intrusion Detection Recovering From an Attack:

Maintainability Manage Input / Output: Record/Playback Separate Interfaces From Implementation Specialized Access Routines / Interfaces

Failure Containment: Localize Changes: Redundancy Replication Functional Redundancy Analytical Redundancy Recovery:

Semantic Coherence Anticipate/ Expected Changes Generalize Module Limit Possible Options Abstract Common Services

Restoration

Fix the error

Identification by audit trail.

Rollback

Hide Information

Degradation

Maintain Existing Interface

Configuration

Restrict Communication Paths

Masking: Voting

Prevention of Ripple Effect:

Use and Intermediary Internal Monitoring: Built in Monitors Defer Binding Time: Run-time registration Configuration Files Polymorphism Component Replacement Adherence to Define Protocols.

4. Framework Application on Dependability and Other Embedded Systems Quality Attributes This study is focused on engineering dependability quality attributes to an embedded system via selecting and calibrating the appropriate tactics used to achieve a given dependability quality attribute. The selection of these tactics shall be based on the dependability quality attributes candidate architectural tactics‟ impact evaluation on achieving other dependability and embedded systems quality attributes. Quality attributes relationships reasoning framework quality attributes in focus are the dependability quality attributes

53

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

undertaken respectively. The compared quality attributes are other dependability and embedded systems quality attributes. The impact of a certain dependability quality attribute candidate architectural tactic is evaluated positive (+) in case this tactic supports the achievement of the compared quality attributes. The impact is considered negative and given the sign (-) if the implementation of this tactic will hinder the achievement of the compared quality attributes as being the second opponent in this relationship. If the implementation of a certain dependability quality attribute does not support or hinder the achievement of the compared quality attributes the relationship is considered independent and given the sign (0). Furthermore, the strength of the impact is measured on a scale from (1 to 4); were 1 represents a slight impact, minor, 3 major, and 4 represents a severe impact on the achievement of the compared quality attributes. The overall relationship between the dependability quality attributes and the other quality attributes is considered positive when the majority of the quality attribute in focus candidate architectural tactics supports the achievement of the compared quality attributes. Furthermore, the relationship is considered negative when the majority of the quality attribute in focus candidate architectural tactics hinders the achievement of the compared quality attributes. Since tactics are experienced based and the evaluation method adopted in the fore stated framework is objective reasoning, a survey is distributed to 93 participants to evaluate the different tactics' impact on the achievement of dependability and other embedded systems quality attributes. Table 3 and Figure 2 depict tactics' impact evaluation survey details. Table 3: Dependability Quality Attributes Candidate Tactics Impact Evaluation Survey's Details Participants' Role

Number

Assessed Dependability Quality Attributes Tactics' Impact

Security Engineering

11

"Integrity and Confidentiality"

Academia

17

"Reliability and Availability, Maintainability"

Software Designers

10

"Reliability and Availability, Maintainability"

Software Developers

20

"Reliability and Availability, Maintainability"

5

"Reliability and Availability, Maintainability"

System Testers M.Sc. Software Engineering Students

30

Total Number of Participants

93

54

"Safety, Integrity and Confidentiality"

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

Figure 2: The Details of the ‘Tactics' Impact Evaluation Survey However, the inter-relationships between dependability quality attributes and other embedded systems quality attributes are evaluated and further described in Tables 4, 5, 6, and 7.

55

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

Efficiency

Usability

Portability

Integrity

Confidentiality

Maintainability

Safety

Level of Agreement

∑ Impact on QAs

Rank

Candidate Tactics Fault Detection: Ping/Echo Heartbeat Exception Recovery Preparation and Repair: Voting Active Redundancy Passive Redundancy Spare Recovery Reintroduction: Shadow State Resynchronization Rollback Prevention: Removal from service Transaction Process Monitor Relationships Relationship Strength (Impact Median Value)

Functionality

Table 4: Dependability Quality Attributes "Availability and Reliability" Candidate Tactics' Impact Evaluation

+4 +4 +4

+2 +1 -1

0 0 +1

+1 -1 -1

-3 +2 +4

-3 +2 +4

+4 +2 +2

-3 0 +1

67% 88% 83%

+2 +10 +14

3 2 1

-2 +2 +4 +4

-3 -3 +2 -1

0 0 0 -1

0 -1 +2 0

0 -1 +2 -1

+1 -3 +2 +2

-1 -2 +2 -1

+1 -4 +2 +1

83% 83% 83% 100%

-4 -10 +16 +3

3 4 1 2

+4 +4 +2

-1 -1 -1

0 0 -1

0 0 0

-2 -2 -4

+1 +1 +1

-1 -1 -3

+1 +1 +2

67% 17% 83%

+2 +2 -4

1 1 2

+4 +4 -2 Pos

-1 0 -2 Neg

-2 0 0 Neg

0 0 0 Neg

-2 +4 -2 Neg

-2 +2 -2 Pos

+1 0 0 Pos

+4 +4 -2 Pos

100% 67% 100%

+2 +14 -10

2 1 3

+1

-1

-0.5

+0.5

0

+0.5

+0.5

0

56

Usability

Portability

Availability

Reliability

Maintainability

Safety

Level of Agreement

∑ Impact on QAs

Rank

Resisting Attacks: Authenticate Users Authorize Users Maintain Data Confidentiality Maintain Integrity Limit Exposure Limit Access Detecting Attack: Intrusion Detection Recovering From Attack: Restoration Identification by audit trial Relationships Relationship Strength (Impact Median Value)

Efficiency

Candidate Tactics

Functionality

Table 5: Dependability Quality Attributes "Integrity and Confidentiality" Candidate Architectural Tactics Impact Evaluation

+2 +2 +2 +4 0 0

-3 -4 -1 -4 +4 0

+2 0 0 0 0 -4

-4 0 0 0 0 0

0 0 0 0 -3 -3

+2 0 0 +4 +4 +4

-3 -4 -4 -3 -4 0

-3 0 +2 +4 0 0

100% 100% 83% 67% 67% 67%

-7 -6 -1 +5 +1 -3

6 5 3 1 2 4

0

-3

0

-3

0

+2

-3

0

83%

-7

1

+3 0 Pos

-4 -4 Neg

0 0 Neg

0 -3 Neg

+2 0 Neg

+4 +4 Pos

+1 -3 Neg

+2 0 Pos

33% 67%

+8 -7

1 2

+3

-2.5

-1

-3.5

-0.5

+3

-1.5

+0.5

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

Efficiency

Usability

Portability

Availability

Reliability

Integrity

Confidentiality

Maintainability

Level of Agreement

∑ Impact on QAs

Rank

Candidate Tactics Failure Detection: Timeout Time Strap Sanity Checking Failure Containment: Redundancy Replication Functional Redundancy Analytical Redundancy Recovery Reintroduction: Fix the Error Rollback Degradation Reconfiguration Masking: Voting Relationships Relationship Strength (Impact Median Value)

Functionality

Table 6: Dependability Quality Attribute "Safety" Candidate Architectural Tactics Impact Evaluation

0 0 0

+4 -1 -1

+2 0

-1 +4 +4

+2 -1 -4

0 +4 +4

0 0 0

0 0 0

0 +4 +4

60% 60% 80%

+7 +10 +7

2 1 2

+4 +4 +2 0

-2 -2 -2 -2

0 0 0 0

+2 +2 +2 0

+3 +2 +2 0

+4 +2 +2 0

-2 -1 -2 0

-1 -1 -2 0

+4 +4 +2 0

80% 80% 60% 80%

+12 +2 +4 -2

1 3 2 4

+2 0 -4 +4

-2 -4 0 -1

0 0 0 0

0 0 0 +1

-2 -1 -3 0

+2 +3 -3 0

0 +4 0 0

0 0 0 0

+2 +2 0 +4

80% 60% 80% 60%

+2 +4 -10 +8

3 2 4 1

-1 Pos

-4 Neg

0 Pos

0 Pos

+4 Pos

+4 Pos

0 Neg

+1 Neg

-2 Pos

100%

+2

1

0

0

+1

+1.5

0

+0.5

-1

-0.5

+1

+2 +10 +2

2 1 2

0 0 0 -2 0

-2 -2 -1 +1 -2

+4 +4 +2 0 +4

+4 +2 0 +4

0 0 0 0

0 0 0 0

0 0 0 0

0 0 0 0

0 0 +1 0

80% 80% 100% 60% 80%

+2 +2 +1 -2 +2

1 1 2 3 1

0 0 0 0

-2 -1 +2 -4

+4 +2 +1 +2

+4 +2 +1 +2

0 0 0 +4

0 0 0 +4

0 0 +3 0

0 0 0 -1

0 0 0 +3

100% 80% 60% 80%

+2 +1 +6 +10

3 4 2 1

0

-1

+2

-3

+4

+4

+4

-2

+4

100%

+10

1

Run-time registration Configuration Files Polymorphism Component Replacement Adherence to Define Protocols

0 +2 0 +4 +2

-4 0 -2 -2 +2

0 +2 0 +2 0

+2 0 0 +2 +3

0 0 0 0 +1

0 0 0 0 0

0 -2 0 0 0

0 -1 0 -2 -1

0 0 0 0 0

80% 100% 80% 100% 60%

-2 +1 -2 +4 +6

4 3 4 2 1

Relationships Relationship Strength ( Impact Median Value)

Pos

Neg

Pos

Pos

Pos

Pos

Neg

Neg

Pos

0

0

+1

+1.5

0

+0.5

-1

-0.5

+1

Rank

∑ Impact on QAs

80% 100% 60%

Safety +2 +2 0

Confidentiality -2 0 0

Integrity 0 0 -1

Reliability +1 +2 0

Availability +1 +2 0

Portability 0 +4 -1

Usability 0 0 0

Efficiency 0 0 +4

Candidate Tactics

Functionality

Level of Agreement

Table 7: Dependability Quality Attribute "Maintainability" Candidate Architectural Tactics Impact Evaluation

Manage Input/Output: Record /Playback 0 Separate Interfaces from Implementation 0 Specialized Access Routines/Interfaces 0

Localize Changes: Semantic Coherence Anticipated Changes Generalize Module Limit Possible Options Abstract Common Services

Prevention of Ripple Effect: Hide Information Maintain Existing Information Restrict Communication Paths Use and Intermediary

Internal Monitoring: Built-in Monitors

Defer Binding Time:

57

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

5. Analysis This research is designed based on two main objectives: The first one is to understand the nature of the interrelationship between dependability quality attributes and other quality attributes of embedded systems based on the architectural strategies as solutions provided by the software architecture community. The second objective is to increase embedded systems‟ dependability by evaluating the impact of using tactics in order to achieve the dependability of embedded systems. Research results indicate that the relationships between dependability quality attributes are interchanging. For example, when achieving the dependability quality attribute maintainability by using proposed tactics; this has a slight support on achieving the dependability quality attributes integrity and confidentiality and therefore create a positive relationship. When focusing on achieving the dependability quality attributes integrity and confidentiality, the use of the proposed tactics has a minor impact which hinders the achievement of dependability quality attribute maintainability and therefore creates a negative relationship. There are many tactics that can be used to satisfy a certain concern of a dependability quality attribute. Such tactics have different levels of impact on the achievement of dependability and other embedded systems quality attributes. Software architects have the option to select and calibrate appropriate tactics to satisfy a certain concern for a dependability quality attribute and therefore balance the relationship between dependability and other embedded system quality attributes to meet certain system specifications. For example, to achieve the dependability quality attributes availability and reliability and satisfy one of its concerns "„Recovery Preparation and Repair"‟, software architects are recommended to select the tactic "„Passive Redundancy"‟. The impact of using such a tactic will deter less the achievement of dependability and other embedded systems quality attributes. On the other hand, the selection of the tactic "„Active Redundancy"‟ constrains the achievement of other dependability and embedded systems quality attributes. However, the dependability candidate architectural tactics which supports the best the achievement of dependability and other quality attributes for an embedded system are ranked in tables 4, 5, 6 and 7. However, the median value of impact level of proposed tactics represents the strength of the relationship between dependability and other quality attributes of embedded systems. For example, when utilizing the proposed tactics to achieve the dependability quality attribute "„Safety"‟ the impact median value shows to what level or extent it supports or hinders the achievement of dependability and other embedded systems quality attributes according to the predefined scale for impact level. It is important to understand that the adoption of a certain tactic used to achieve a dependability quality attribute of a system can affect the relationship between dependability and other embedded system quality attributes. By comparing the results of the foretasted studies investigating quality attributes relationships with this study‟s results, it can be seen that the relationships of quality attributes can be assessed and evolve differently depending on the considered factors, system‟s quality requirements, and the development stage. In this research, the relationship between quality attributes is based on the used solutions that are adopted to achieve a certain quality attribute and focused on the software architecture stage of embedded systems development. Tables 4 5 6 and 7 can be read vertically and horizontally. For example, tactics are ranked according to their influence on the achievement of embedded systems and dependability quality attributes. The processes of prioritizing tactics are based on the sum of their overall impact on the achievement of embedded systems and dependability quality attributes. Additionally, the relationship between certain quality attributes can be estimated when reading the tables vertically. For

58

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

example, the relationship itself can be undertaken positive when the quality attribute in focus tactics‟ impact evaluation shows a positive sum vertically. In the contrary of a negative relationship between the quality attribute in focus and the compared quality attribute when the indicators are negative.

6. Discussion The quality attributes‟ assessment framework is helpful to evaluate the quality attributes‟ candidate tactics impact in case of options to select tactics as candidate solution exists. This framework can only assess the impact when there are enough specifications of the developed system and its quality requirements. It also gives the opportunity to assess the tactics concerning the system‟s desired quality attributes before using them. Moreover, the framework structure is layer based, and therefore, the framework is flexible to obtain additional layers concerning additional factors. The developed framework gives the opportunity to software architects to perform a more disciplined approach to conduct correct trade-offs between tactics concerning quality attributes relationships and their influence on the achievement of system‟s quality. Additionally, the framework is adaptable to additional quality prediction techniques and other assessment approaches to be combined with objective reasoning evaluation method. The dependability of embedded systems can be increased by selecting the appropriate design decisions which have supportive influences on other dependability and embedded systems quality attributes. The degree which describes the level of impact is dependent on the extent to what a given dependability quality attribute candidate tactic affects the achievement of other quality attributes‟ sub-characteristics (criteria) - as most of the participants of the research‟s second survey wrote in their motivations explaining the base of their evaluation. For example, the candidate tactics that attempt to satisfy the concern of "„Availability and Reliability"‟ for failure detection have a great influence on the embedded system‟s quality attribute "„Functionality"‟ supporting the achievement of all the sub-characteristics of the „Functionality"‟ quality attribute and thus creates a positive relationship with the embedded system‟s quality attribute "„Functionality"‟ when satisfying the "„Availability and Reliability‟s"‟ fault detection concern. In the contrast, most of the "„Availability and Reliability"‟ candidate tactics used to satisfy recovery preparation and repair create various levels of negative relationships and one positive relationship with embedded systems quality attribute "„Efficiency"‟. Tactics impact evaluation can be undertaken at two levels: The first level describes the extent of hindering or supporting the compared quality attributes‟ subcharacteristics / criteria when using a given tactic. For example, using the tactic "„Authenticate Users"‟ to satisfy the concern "„Resisting Attack"‟ of the dependability quality attributes "„Integrity and Confidentiality"‟ assists the achievement of the embedded system‟s quality attribute "„Usability"‟ by supporting its sub- characteristics/ criteria "„Operability"‟ and "„Understandability"‟. The use of the same tactic will on the other hand hinder the achievement of the embedded system‟s quality attribute "„Portability"‟ by preventing the achievement of its sub-characteristics "„Ease of Integration"‟ and "„Compatibility"‟. The Second level of impact evaluation is the level by which this tactic is hindering/supporting the achievement of the compared quality attributes. For example, the achievement of the dependability quality attributes‟ "„Availability and Reliability"‟ concern "„Recovery Preparation and Repair"‟ via the proposed tactics has different levels of negative and positive impact over the embedded system‟s quality attribute "„Efficiency"‟. The variety between the levels in this case as the participants provided multiple reasons to motivate their evaluation- is dependent on the amount of "„consumptions in cost and time"‟ of the embedded systems. As

59

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

the tactic "„Passive redundancy"‟ does not consume more cost than other proposed tactics for the same concern as it‟s assigning one component to do the work rather than constructing another copy or redundant system components to perform multiple tasks this tactic has a minor positive impact on achieving efficiency for embedded systems as it does not support the achievement of all the sub-characteristics of the embedded system‟s quality attribute "„Efficiency"‟.

7. Conclusions When developing a software system, it is important to understand the impact of the used strategy or tactic on other desired quality attributes at earlier stages. Otherwise, more effort may be spent on trying to satisfy the system requirements. Conversely, the system development maybe facilitated if it is known that by satisfying a quality attribute using a certain tactic, other quality attributes are likely to follow because of the positive impact the used tactic has. The two main contributions of this research are focused on increasing the likelihood of having more dependable embedded systems by providing thorough analysis for the dependability quality attributes‟ relationship based on the available solution that could be illustrated from literature and experience [13] [25]. This study results‟ provide yet another factor for software architects to take into account when deciding on a dependability quality attributes candidate tactics prioritization; what, and in what order. Additionally, the relationships between quality attributes may vary depending on the depth, the scope, and the influencing factors that influence the investigation.

References E. A. Strunk and J. C. Knight, “Dependability through Assured Reconfiguration in Embedded System Software”, IEEE Transactions on Dependable and Secure Computing, Vol. 3, No. 3, 2006, pp. 172-187. [2] IEEE, IEEE Std. 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology, Institute of Electrical and Electronic Engineering, New York, USA, 2002. [3] I. Crnkovic, “Component-Based Approach for Embedded Systems”, in Proceedings of 9th International Workshop on Component-Oriented Programming, 2004. [4] M. Larsson, Predicting Quality Attributes in Component-Based Software Systems, Ph.D. Dissertation, Mälardalen University, Department of Computer Science and Electronics, Mälardalen, Sweden, 2004. [5] A. Avižienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basic Concepts and Taxonomy of Dependable and Secure Computing,” IEEE Transactions on Dependable and Secure Computing, Vol. 1, No. 1, 2004, pp. 1133. [6] J. Heit, Impact of Methods and Mechanisms for Improving Software Dependability on Non-Functional Requirements, Master‟s thesis, Stuttgart University, Department of Informatics, Stuttgart, Germany, 2007. [7] K. Misra, “Dependability Considerations in the Design of a System”, in Handbook of Performability Engineering, 1st Ed., (Misra, K., Editor), Springer, Germany, 2008, pp. 71-80. [8] A. Vulgarakis and C. Seceleanu, “Embedded Systems Resources: Views on Modeling and Analysis”, in Proceedings of the Annual International Conference on Computer Software and Applications, 2008, pp. 1321-1328. [9] J. A. McCall, “Quality factors”, in Encyclopedia of Software Engineering (Marciniak, J., Editor), 1994, pp. 958-969. [10] M. Svahnberg and K. Henningsson, “Consolidating Different Views on Quality Attributes Relationships”, in Proceedings of the 8th International Conference on Software Engineering Research and Practice (SERP‟08), 2008., pp. 46-50 [11] Saleh H. Al-Daajeh, Rafa E. Al-Qutaish, and Fuad Al-Qirem, “A Tactic-Based Framework to Evaluate the Relationships between the Software Product Quality Attributes”, to be published, International Journal of Software Engineering, 2011 [12] H. V. Vliet, Software Engineering Principles and Practice, 3nd Ed., John Wiley & Sons, New York, USA, 2008. [1]

60

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

[13] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 2nd Ed., Addison Wesley, New York, USA, 2003. [14] C. Ebert and R. Dumke, Software Measurement: Establish- Extract-Evaluate-Execute, Springer, Germany, 2007. [15] A. Avizienis, J. Laprie, and B. Randell, “Fundamental Concepts of Dependability”, in Proceedings of the 3rd International Survivability workshop, 2001. [16] M. Barbacci, M. H. Klein, T. A. Longstaff, and C. B.Weinstock, Quality Attributes, Technical Report ESCTR-95-021, Software Engineering Institute, Carnegie Mellon University, Pennsylvania, USA, 1995. [17] L. Zhu, M. A. Babar, and R. Jeffery, “Mining Patterns to Support Software Architecture Evaluation”, in Proceedings of the Working IEEE/IFIP Conference on Software Architecture, 2004, pp. 25-25. [18] M. S. Deutsch and R. R. Willis, Software Quality Engineering a Total Technical and Management Approach. Prentice Hall, New Jersey, USA, 1988. [19] P. Berander, L. Damm, J. Eriksson, T. Gorschek, K. Henningsson, P. Jönsson, S. Kågström, D. Milicic, F. Mårtensson, K. Rönkkö, P. Tomaszewski, L. Lundberg, M. Mattsson, and C. Wohlin, Software Quality and Trade-Offs, Technical Report, Blekinge Institute of Technology, Ronneby, Blekinge, Sweden, 2005. [20] L. Bass, M. Klein, and G. Moreno, Applicability of General Scenarios to the Architecture Trade-Off Analysis Method, Technical Report TR-014, Carnegie Mellon University, Pittsburgh, Pennsylvania, USA, 2001. [21] M. Svahnberg and C. Wohlin, “A Comparative Study of Quantitative and Qualitative Views of Software Architectures”, in Proceedings of the 7th International Conference on Empirical Assessment in Software Engineering, 2003, pp. 1-8. [22] C. Gacek and R. de lemos, Structure for Dependability Computer Based Systems from Interdisciplinary Perspective, Springer, Germany, 2006. [23] N. Lassing, D. Rijsenbrij, and H. van Vliet, “On Software Architecture Analysis of Flexibility, Complexity of Changes Size isn‟t enough”, in Proceedings of Second Nordic Software Architecture Workshop (NOSA‟99), 1999, pp. 1103-1581. [24] R. Kazman, S. J. Carrière, Woods, and G. Steven, “Toward a Discipline of Scenario-Based Architectural Engineering”, Annals of Software Engineering, Vol. 9, No. 1-4, 2000, pp. 5-33. [25] W. Wu and T. Kelly, “Safety Tactics for Software Architecture Design,” in Proceedings of the Annual International Conference on Computer Software and Applications, 2004, pp. 368-375. [26] F. Bachmann, L. Bass, and R. Nord, Modifiability Tactics, Technical Report TR-002, Software Engineering Institute Carnegie Mellon University, Pittsburgh, Pennsylvania, USA, 2007. [27] J. Bosch and P. Molin, “Software Architecture Design: Evaluation and Transformation”, in Proceedings of the IEEE International Conference on Engineering of Computer-Based Systems, 1999, pp.4-4. [28] J. Karlsson, C. Wohlin, and B. Regnell, “An Evaluation of Methods for Prioritizing Software Requirements”, Information and Software Technology, Vol. 39, No. 14-15, 1999, pp. 938-947. [29] T. Sherman, Advances in Computer and Information Sciences and Engineering, Springer, Germany, 2008. [30] G. Mustapic, Architecting Software for Complex Embedded Systems - Quality Attribute Based Approach to Openness, Ph.D. Dissertation, Mälardalen University, Department of Computer Science and Engineering, Thesis (No.38), Mälardalen, Sweden, 2004.

Authors Mr. Saleh H. Al-Daajeh is currently an instructor and a junior researcher at the software engineering department in Al-Zaytoonah University of Jordan. His research interests are in the area of Embedded Systems Software Engineering, Software Architecture, Software Quality, Software Metrics, Global Software Engineering, and Software metrics. He finished his first degree in computer science from Petra University in Jordan. He holds a MSc. Degree in the field of Software Engineering from the school of computing from the Blekinge Institute of Technology in Sweden. He completed most of his graduate degree courses with distinction.

61

International Journal of Software Engineering and Its Applications Vol. 5 No. 4, October, 2011

Dr. Rafa E. Al-Qutaish received the B.Sc. in Computer Science and M.Sc. in Software Engineering degrees in 1993 and 1998, respectively. Also, he received the Ph.D. degree in Software Engineering from the School of Higher Technology (ÉTS), University of Québec, Canada in 2007. Currently, he is a deputy dean and Assistant Professor of Software Engineering at Al Ain University of Science and Technology in Abu Dhabi, UAE. So far, he has published more than 17 papers in international peer-reviewed journals, 15 papers in international peerreviewed conferences & workshops, and 3 chapters. Dr. Fuad Al-Qirem received the B.Sc. in Civil engineering from Jordan University of Science and Technology, Jordan in 2002 and M.Sc. degree in Project Management from Sunderland University at United Kingdom in 2003 and received his PhD in Human Computer Interaction from Sunderland University at United Kingdom in 2009. His current position is an assistant professor at the software engineering department in Al-Zaytoonah university of Jordan in Amman, Jordan.

62