1 / 25

Quality-Driven Conformance Checking in Product Line Architectures

Quality-Driven Conformance Checking in Product Line Architectures. Femi Olumofin and Vojislav B. Mišić University of Manitoba Winnipeg, MB, Canada. OUTLINE. INTRODUCTION CHALLENGES VARIATION POINT CONCEPTS USAGE OPEN ISSUES. Outline. Introduction Challenges

hanley
Download Presentation

Quality-Driven Conformance Checking in Product Line Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related