Quality-Driven Conformance Checking in Product Line Architectures

1. Quality-DrivenConformance Checking in Product Line Architectures Femi Olumofin and Vojislav B. Mišić University of Manitoba Winnipeg, MB, Canada

2. OUTLINE • INTRODUCTION • CHALLENGES • VARIATION POINT CONCEPTS USAGE • OPEN ISSUES #2

3. Outline • Introduction • Challenges • Variation Point Concepts Usage • Open Issues #3

4. Introduction • In architecture-centric development of software products, the architecture is the first place where the behavioral and quality characteristics of the software are addressed • Immediately on launch, the architecture of the runtime product should comply with its documented architecture • After some series of maintenance operations on the system, its quality characteristics can become inconsistent with the documented architecture – despite functional correctness #4

5. Reengineering • Architecture reengineering (or reverse engineering):a technique for recovering the architecture of a system from its runtime image • Reconstruction once again ensures that the documented (or as-designed) architecture is consistent with the runtime (or as-built) architecture • The key question: How can reengineering techniques be used to construct a product line architecture from existing products and legacy applications? #5

6. Reengineering towards Product Line #6

7. Outline • Introduction • Challenges • Variation Point Concepts Usage • Open Issues #7

8. Quality-Driven Conformance Checking • A product architecture (PA) should remain consistent with the common architecture (CA) • The only exception is when the development of a product architecture involves an overlap of a variation point with a sensitivity point • The quality attributes allowed for in the CA can only become degraded by design decisions of the PA at these points; point of transforming variation point into product variants • How do we use this insight to ensure quality conformance of a PA to those of the CA? #8

9. Challenges • How to extract the commonalities and variability from existing system architectures and legacy architectures? • Once the product architectures have been created, how to ensure they remain in consistent (in terms of quality attributes) with the common architecture? • … #9

10. Quality-Driven Conformance Checking • The common architecture (CA) features: • Mandatory components • Variation points – placeholders for augmenting the CA with behavioral extensions • Sensitivity points – areas of the architecture whose design decision interacts with at least one quality attributes • Tradeoff points – sensitivity points for two or more quality attributes #10

11. Outline • Introduction • Challenges • Variation Point Concepts Usage • Open Issues #11

12. Evolvability points • We use the concept of evolvability points • Evolvability point: an area of the architecture which is a sensitivity point and, at the same time, contains at least one variation point • We accompany each evolvability point in the CA with appropriate constraint and/or guideline (or several of them) which are utilized to guide subsequent PA design decisions and conformance checking #12

13. Example • Consider the following architecture #13

14. Example • Primitive components: mandatory (unshaded), alternatives (vertically striped) and optional (shaded) • Complex (or composite) components CC1, CC2, CC3 • Assuming that • sensitivity points are located in some of the components; and • performance and availability are the two quality goals of highest priority • We shall consider two scenarios: • Scenario 1: the architecture is taken to be a product architecture (PA) • Scenario 2: the architecture is taken to be the common architecture (CA) #14

15. Scenario 1: architecture is a PA • The primitive components are fully specified • Two cases may be considered #15

16. Scenario 1 • Case 1: sensitivity points for performance and availability are located in mandatory components PC23 and PC 24, respectively (preset in the CA) • Implications: This PA and indeed every other PA,will provide the preset performance and availability response #16

17. Scenario 1 • Case 2: sensitivity points for performance are jointly located in mandatory components PC23, and alternative component PC21 • Note: design decisions of PC23 are determined in the CA definition while those of PC21 are determined in this particular PA definition • Implications: If there is to be a performance guarantee, this PA must correctly specialize PC21 from its variation point in the CA • The relevant design decisions need to be guided or constrained in an appropriate manner #17

18. Scenario 2: architecture is the CA • Only the unshaded boxes are fully specified • Again, two cases may be distinguished #18

19. Scenario 2 • Case 1: sensitivity points are only located in mandatory components • Although this is the goal of every CA design – this rarely occurs in reality • Implications: the CA would address the quality goals of ALL products #19

20. Scenario 2 • Case 2: sensitivity points are localized in both fully specified mandatory components and some underspecified alternative and optional components • Implications: The architects can only design to fulfill the quality goals of the mandatory components • … and expect the product architects to fulfill their part in designing the variant for appropriate quality response • Caveat: If the teams are different this may be hard to do without duplication of efforts #20

21. Scenario 2: architecture is the CA • So, to ensure the conformance of the PA design decisions to those of the CA, an evolvability point and evolvability constraints are needed • Note: Not every variation point is an evolvability point – only those interacting with sensitivity points are • An evolvability constraint (EC) is a statement about an evolvability point (EP) to guide product architecture creation • It can be described in the syntax and semantics of an ADL, or perhaps in another constraint language #21

22. Sample Evolvability Point and the Accompanying Evolvability Constraint • EP: The response time of the ** product to tasks delegated to, is dependent on … • EC: To enhance response time for transaction involving a product, external data request …Alternatively, an external integration mechanism may be deployed to synchronize … #22

23. Key Idea • The combined use of evolvability points and evolvability constraints ensures the PAs remain in conformance with the CA • Main contributions: • Architecture-centric focus for reasoning about quality attributes conformance of the product architectures to the CA • Systematic use of variation points to constrain product architectures from deviating from the preset qualities of the CA • Both of these should enhance our understanding of the interactions and tradeoffs between quality attributes of different forms of architecture #23

24. Outline • Introduction • Challenges • Variation Point Concepts Usage • Open Issues #24

25. (Some of the) Open Issues • How to extract CA and PAs from existing systems? • How to characterize the areas of the CA that do not feature any variation points, but have the potential of determining qualities both in the CA and the PAs? • How can software product line specialists utilize the result of the characterizations of conformance checks between a product line’s CA and PAs for checking conformance of the code-dependent (as-built) architecture to the documented (as-designed) PAs? • While tool support is always a plus, the exact details of support for quality conformance checking and traceability in a product line context are yet to be worked out #25