Académique Documents
Professionnel Documents
Culture Documents
Outline
Introduction
Software Product Line Product Line Architecture vs Product Architecture
Data analysis
Threats to the validity
Conclusions
Introduction
Software Product Line (SPL) development is an approach that takes advantage of the massive reuse of software assets to improve productivity and product quality In SPL development, there are two architectures:
the product line architecture contains a set of variation mechanisms that support the quality and functional requirements of the entire set of products that constitute the product line the product architecture is derived from the product line architecture by exercising its built-in variation mechanisms
Once the product architecture is derived, it should be evaluated to guarantee that meets the product specific NFRs
and.. when these NFRs cannot be attained by using built-in variation mechanisms certain architectural transformations may be applied
Objective
To introduce a model-driven product architecture derivation and improvement method (QuaDAI) for SPL aimed to: derive product architectures from the product line architecture
QuaDAI is a model-driven method for the derivation, evaluation and improvement of product architectures which is composed of:
a multimodel to represent different viewpoints (functionality, quality, variability, etc.) as interrelated models a process consisting of a set of activities conducted by model transformations
The multimodel also contains relationships among the elements of different viewpoints This can be used to establish relationships of interest, for example:
how a specific component impact on the reliability of the system how a specific transformation improves a given quality attribute
* In a viewpoint, it is possible to define model of the system that contains only the objects that are visible from that viewpoint. Such a model is known as a viewpoint model of the system from that viewpoint (NISTIR 6928, 2003)
6
Includes different activities in which the multimodel is used to drive the model transformation processes for the derivation, evaluation and improvement of product architectures in SPL development
Activity 1
Activity 2
Activity 3
Evaluator
Architect
Product Architecture
Evaluator
Architect
Product Architecture
Evaluation Report
10
Evaluator
Architect
Product Architecture
11
12
Having a NFR regarding fault tolerance which architectural transformation pattern will be applied?
relation TripleModularRedundancy { checkonly domain Source: ... {...}; enforce domain Target: ... {...}; } relation Watchdog { checkonly domain Source: ... {...}; enforce domain Target: ... {...}; }
13
Example. Activity 3. Product Architecture Transformation (ABS System) Obtaning a Fault Tolerant software architecture
Having a NFR regarding fault tolerance the transformation pattern automatically applied will be the TMR pattern
14
Outline
Introduction
Software Product Line Product Line Architecture vs Product Architecture
Data analysis
Threats to the validity
Conclusions
15
16
The experimental tasks include the evaluation of these quality attributes by means of two software metrics in each experimental object before and after applying the architecture evaluation methods (QuaDAI and ATAM)
17
Subjects Selection
31 subjects were selected from a group of fifth-year Computer Science students at the Universitat Politcnica de Valncia who were enrolled on an Advanced Software Engineering course from September 2012 to January 2013
18
The Perceived Utility which has been measured by means of 3 subjective dependent variables:
Perceived ease of use (PEOU), the degree to which evaluators believe that learning and using a particular method will be effort-free Perceived usefulness (PU), the degree to which evaluators believe that using a specific method will increase their job performance Intention to Use (ITU), which is the extent to which a person intends to use a particular method
19
H40: There is no significant difference between the perceived usefulness of QuaDAI and ATAM / H4a: QuaDAI is perceived as more useful than ATAM.
H50: There is no significant difference between the perceived intention to use of QuaDAI and ATAM / H5a: QuaDAI is perceived as more likely to be used than ATAM.
20
Software Architecture Evaluation using ATAM and QuaDAI session (60 + 60 minutes) 2nd
One of the subjects did not complete the 2nd session it was necessary to eliminate his first exercise Then, we had 30 subject distributed in 4 groups, we needed to discard two subjects, selected randomly, to maintain the balanced design consisting of a total of 28 subjects, 7 in each group
21
22
Mean
QuaDAI ATAM
0.68 0.63
Std. Dev.
0.39 0.36
Mean
0.029 0.020
Std. Dev.
0.018 0.013
Mean
25.36 31.11
Std. Dev.
7.26 9.15
PU Mean
3.80 3.72
Std. Dev.
0.88 0.82
Mean
3.65 3.55
Std. Dev.
0.84 0.70
23
ITU 0.767
Efficiency (not normally distributed): p-value from the 1-tailed t-test was 0.015
These results let us to conclude that: the difference in terms of Efficiency and PEOU was statistically significant the difference in terms of Effectiveness, PU and ITU was not statistically significant (although QuaDAI achieved better results)
24
Subjects experience. No differences in the subjects experience (none had experience in architecture evaluations)
Information exchange. Different experimental objects and monitoring the subjects while they performed the tasks. The participants returned the material at the end of each session Understandability of the material. Clearing up all the misunderstandings that appeared in each experimental session
25
2 different architectures, from 2 different domains, 2 different opposed NFRs and 4 different patterns for each experimental object
The participants had with no previous experience in architectural evaluations, and received only limited training on the evaluation methods
last year students (considered as novice users of architectural evaluation methods). Results could be considered as representative of novice evaluators
26
27
Conclusions
We presented the QuaDAI method for the derivation, evaluation and improvement of product architectures
Model-driven derivation, evaluation and improvement of product architectures Provides a systematic mechanism for dealing with those cases where the built-in variation mechanisms of the PL architecture is not enough Reuse of the architectural knowledge stored in the multimodel to help designers to decide and apply the architectural patterns required to improve product architectures
We also reported the validation of our method by means of a controlled experiment in which QuaDAI were compared ATAM
QuaDAI was more efficient and perceived to be easier to use than ATAM
With regard to the effectiveness, PU and ITU, the differences were not statistically significant (although QuaDAI achieved better results)
This may be due to the lack of experience of the subjects in architecture evaluation
28
Future work
To characterize those cases in which the variability mechanisms are not sufficient to achieve desired quality levels for a given product architecture To study other mechanisms for managing interrelationships among viewpoints in the multimodel we are using only simple values but they may not capture the full range of realworld impact relationships
we will explore the definition of functions that could express conditions on such values
To conduct replications of this experiment by considering: larger number of subjects with different subject profiles (e.g., practitioners or students with a higher level of knowledge and skills on architecture evaluation) different experimental objects in order to improve the representativeness of our results
29
, (
, =
=1
The subjective variables were measured by using a Likert scale questionnaire with a set of specific closed questions
The aggregated value of each subjective variable was calculated as the mean of the answers to the variable-related questions
31