Multiple Views and Relationships for Quality Driven Architecture with AADL: A Multimodel for Software Product Lines

Transcription

1 Multiple Views and Relationships for Quality Driven Architecture with AADL: A for Software Product Lines Emilio Insfran, Silvia Abrahão, Javier González Department of Information Systems and Computation Universitat Politècnica de València, Spain {einsfran, sabrahao}@dsic.upv.es AADL Standards Meeting Oct 30 - Nov 1, 2012 Phoenix, AZ - USA

2 A ing Approach for Quality-Driven 2 Outline A for Software Product Lines Quality-Driven

3 A ing Approach for Quality-Driven : Context MULTIPLE Project CICYT (TIN ) MULTIPLE (ing Approach for Quality-Aware Software Product Lines) Ministry of Economy - From 2010 to researchers at UPV (4 Professors and 6 PhD students) 5 external researchers: University of Leicester (UK), Universidad de Colima (Mexico) LERO (Ireland), IT University of Copenhagen (Denmark) Universidad Rey Juan Carlos (Madrid) EPO: Rolls-Royce (UK) Goi Eskola Politeknikoa. SEI John McGregor and Sholom Cohen

4 A Software Product Line (SPL) is a set of software systems sharing a common set of features, developed from a common set of core assets in a prescribed way. The product line architecture is driven by the functional, quality, and business requirements of the whole set of products within a SPL. Product architectures are obtained from the PL architecture by exercising its built-in variation points according to a prescribed set of variation mechanisms. However when the variation mechanisms are not sufficient to fulfill a required quality level additional architectural transformations are needed. This implies that: The knowledge about quality attributes related to architectural transformations need to be represented and used for selecting the transformation to be applied. The resulting product architecture has to be evaluated to asses if the required quality attribute levels are fulfilled. A ing Approach for Quality-Driven 4

5 A ing Approach for Quality-Driven 5 The objective of this work is to identify and specify the set of interrelated viewpoints (by means of a multimodel) for deriving product architectures in the context of SPL. The multimodel will comprise the set of viewpoints of interest (functional, variability quality, ) allowing the explicit representation of the relationships and constraints among the elements on these viewpoints. This multimodel will be the input for a quality-driven model transformation process which will apply architectural transformations to the SPL architecture to fulfill the required quality level.

6 A ing Approach for Quality-Driven 6 Definition A viewpoint is an abstraction that yields a specification of the whole system restricted to a particular set of concerns. In any given viewpoint it is possible to define a model of the system that contains only the objects that are visible from that viewpoint. Such a model is known as a viewpoint model, or a view of the system from that viewpoint (NIST 6928, 2003) 1. A multimodel is a set of interrelated models that represents different viewpoints of a particular system 2. 1 National Institute of Standards and Technology, U.S. Dept. of Commerce, USA 2 The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest.

7 Viewpoints for SPL In SPL, the multimodel is used to represent the different viewpoints of the set of products that can be derived from the SPL. This multimodel comprises 4 viewpoints of interest and the relationships among them: Variability: expressing the commonalities and variations within the SPL. It can be represented by a Cardinality-based Feature Model. Functional: expressing the functional components that satisfy the SPL requirements. It can be defined using different styles (e.g., component-and-connector). Quality: expressing the quality characteristics and attributes. It can be represented by a Quality Model (e.g. ISO 25010, IEEE 830). Transformations: expressing the possible available transformations (e.g., architectural patterns represented as transformations). A ing Approach for Quality-Driven Domain Engineering Application Engineering 7

8 A ing Approach for Quality-Driven 8 Relationships among Views Establishing relationships among elements of the viewpoint models in the multimodel allow us to analyze properties over the SPL as a whole. Functional and variability: elements in the functional view (e.g., AADL systems, system implementations, devices, and processes) can be combined to fulfill the requirements of one or more features E.g., a multimedia GPS navigator feature in a car is fulfilled by a combination of software and hardware functional components. Functional and quality: elements of the functional view may impact one or more quality attributes of the product E.g., integrating functional components in the functional view with low resource consumption will impact on the resource consumption quality attribute of the quality view. Variability and quality: features (or feature groups) in the variability view may impact one or more quality attributes of the product E.g., a feature group related to safety options may improve the reliability of a system. Transformation and quality: architectural patterns in the transformation view may impact quality attributes of the product. This allows using quality attributes as a decision factor in the selection among architectural transformations. E.g., the Homogeneous Redundancy (HR) pattern improves the reliability of a system.

9 A ing Approach for Quality-Driven 9 Metamodel (generic)

10 A ing Approach for Quality-Driven 10 Metamodel (for SPL)

11 A ing Approach for Quality-Driven 11 Example Variability View Excerpt [0..1] Stability Control Attributes Car Control Attributes [1..2] 0.2 [1..1] ABS Attributes 0.9 Quality View Excerpt Performance Resource Consumption Reliability Fault Tolerance Cost Functional View Excerpt antilock_brake_system abs_user_input abs_brake_out abs_brake_input abs_display_out abs_wheel_speed cruise_control_system cc_user_input cc_engine_input cc_throttle_out cc_brake_status cc_display_out cc_wheel_speed Transformation View Excerpt Triple Modular Redundancy Pattern Watchdog Pattern

12 A ing Approach for Quality-Driven 12 Quality-Driven In SPL, product definition begins with the derivation of the product architecture. The multimodel can be used to create product-specific production plans that describe how a specific product can be build from the core assets This includes how the product architecture can be derived from the PL architecture. The PL architecture defines the allowable variations within the product line s scope and the variation mechanisms for achieving them. However, in some cases the product architecture may include variation points that are not permitted by the original PL architecture but needed to assure some product-specific quality attributes. The multimodel can be used as input for deriving product architectures with the required quality attribute levels from the PL architecture. We use architectural patterns, which are represented as architectural transformations, as a means to improve the quality of the product architecture.

13 A ing Approach for Quality-Driven 13 Quality-Driven Two activities are carried out by model transformations: T1 - Product : applies the architectural transformations to an instance of the SPL to meet the required levels of quality attributes. T2 - Product Architecture Evaluation: applies the corresponding software measures from the quality model to the product architecture to assess if it meets the desired levels of quality attributes. T2 Product Architecture Product Line Architecture T1

14 A ing Approach for Quality-Driven 14 Quality-Driven The product architecture derivation is carried out by applying a qualitydriven model transformation approach Architectural patterns are represented as architectural transformations The application of architectural transformations generates different product architectures that satisfies different quality attributes. The domain expert should establish the impacts among architectural transformations and quality attributes. These impacts can be determined by using empirical evidence or the domain expert s experience. A trade-off analysis among quality attributes and architectural transformations is performed using the Analytic Hierarchy Process (AHP). The result of the AHP is a comparison matrix that shows the relative importance of each alternative with regard to each quality attribute. It is used in a quality-driven model transformation to select the appropriate architectural transformation to be applied.

15 Example: The Vehicle Control System The Vehicle Control System contains several subsystems (features): Antilock Braking System (ABS): ensures that the maximum braking force is transmitted to all four wheels of the vehicle. Traction Control System (TCS): prevents the wheels from slipping. Stability Control System (SCS): keeps the vehicle going in the direction in which the driver is steering the car. Cruise Control System (CC): attempts to maintain a constant driver determined. A ing Approach for Quality-Driven 15

16 Example: Subsystems Architecture Each subsystem consists of: Capturing input signals from sensors. Processing and transforming those inputs, based on specific control laws Sending the processed output (a control value) to an actuator that affects the state of some other subsystems or mechanical parts of the car (e.g., engine, throttle position, brakes, security belts). A ing Approach for Quality-Driven 16

17 A ing Approach for Quality-Driven 17 Example: Quality Attributes Safety, reliability, and performance are those key quality attributes in realtime embedded systems for the automotive domain: Reliability: the degree to which a system, product or component performs specified functions under specified conditions Fault tolerance: the degree to which a system operates as intended despite the presence of hardware or software faults. Metric: Key Node Safety Performance: characterized by the amount of resources used under stated condition for a stated period of time Time-behavior: the degree to which the response and processing times and throughput rates of a product or system meet the requirements when performing its functions. Metric: Latency time: time elapsed between firing an input event and obtaining the response from the system.

18 Example: Architectural Transformations (architectural patterns) The alternative architectural transformations considered here are: The Homogeneous Redundancy pattern (HR) Improves reliability offering two units of subsystem monitoring and performing the same operations on the input signals. The primary channel runs as long as there are no problems detected. When a failure in the primary channel is detected, the system switches to the backup channel and vice versa. There is no concurrency at run-time, only replication. The Triple Modular Redundancy pattern (TMR) Improves reliability (as well as safety) of a system by offering an odd number of channels operating in parallel. if there is a disagreement between channels, then the results with a two out of three majority win and are sent to the actuator. A ing Approach for Quality-Driven 18

19 A ing Approach for Quality-Driven 19 Example: Trade-Off Analysis (AHP) The domain expert ranks the N architectural patterns (2) with regard to the Q quality attributes (2) in a pairwise comparison: a) An AHP weight is assigned (e.g., TMR is strongly most important than HR = 5) b) The resulting matrix in (a) is normalized applying formula (1) c) The Impact is calculated applying formula (2)

20 A ing Approach for Quality-Driven 20 Example: T1 - Product Architecture derivation According to the multimodel relationships, if the quality attribute selected is fault tolerance the transformation will apply the triple modular redundancy pattern

21 A ing Approach for Quality-Driven 21 Example: T1 - Product Architecture derivation If the quality attribute selected is latency the transformation will apply the homogenous redundancy pattern The approach also supports multi-criteria quality attributes by ranking the relative importance of the quality attributes.

22 A ing Approach for Quality-Driven 22 Example: T2 - Architecture Evaluation We evaluate the derived product architecture to assess if the architectural transformation resulted in an improvement of its quality. We compare the measures values obtained over the product architectures with and without applying the architectural pattern. E.g., we use the the fault tolerance quality attribute to illustrate the product architecture evaluation after applying the Triple Modular Redundancy pattern: The fault tolerance attribute is measured by applying the Key Node Safety (KNS) metric on a fault tree for the product architecture. The value of the KNS metric expresses how a mutation of a system improves its fault tolerance; the higher value of the metric is the better the fault tolerance the system has.

23 A ing Approach for Quality-Driven 23 Example: T2 - Architecture Evaluation Key Node Identification Fault Tree of the original architecture Fault Tree after applying the TMR Pattern

24 A ing Approach for Quality-Driven 24 Example: T2 - Architecture Evaluation Metric Operationalization The following formula calculates the key node safety (KNS) metric: Original TMR k: Number of key nodes in the fault tree 0 1 h': Total height of the fault tree n: Total number of nodes in the fault tree 7 18 c i : Number of nodes in the sub-tree rooted at key node k i 0 15 d i : Depth of the sub-tree rooted at key node ki S: Key Node Safety Metric The metric results indicates that the TMR pattern improves the fault tolerance of the product when compared to the values of the original product architecture (0.069 > 0).

25 A ing Approach for Quality-Driven 25 We presented an approach for dealing with viewpoints in SPL development (product architecture). It includes the following: A multimodel that explicitly represents the PL from multiple and interrelated viewpoints. A model transformation process that generates product architectures driven by the required quality attributes from the product line architecture. The feasibility of the approach has been illustrated with an example of the automotive domain. Two different product architectures were generated and evaluated by applying architectural transformations to a fragment of a product line architecture. The multimodel and the model transformation process have been implemented in a prototype in the Eclipse Modeling Framework using the QVT language standard.

26 A ing Approach for Quality-Driven 26 The multimodel helps to have a richer semantic view of the SPL. Knowledge preservation. It provides a sufficiently formal interrelated model that can be supported by tools capable of automating portions of the PL production planning. The architectural transformations are guided by the relationships and constraints established in the multimodel. Rationale documentation.

27 A ing Approach for Quality-Driven 27 Use the multimodel for product configuration To select and deploy core assets on the product architecture, based not only on functional requirements but also on quality attribute requirement levels. Analyze the intra and inter model consistency. To represent the multimodel in a format that can be read by existing solvers (e.g., FAMA) Apply this approach to different domains where different patterns and quality attributes have been identified. At this moment, we only consider the relative importance of a quality attribute regarding other viewpoint elements We are also working to deal with specific NFR associated to quality attributes (e.g., RNF001 = cruise control reliability must range from to 0.999) reliability = f(fault tolerance, availability) Considering the RDAL annex as a viewpoint in the multimodel.

28 A ing Approach for Quality-Driven 28 Thanks for your attention