7 Lessons Learned Case Study: Replay a Log on Petri Net for Conformance Checking plug-in
Quality-Driven Conformance Checking in Product Line Architectures
description
Transcript of Quality-Driven Conformance Checking in Product Line Architectures
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
#3
Outline
Introduction Challenges Variation Point Concepts Usage Open Issues
#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
#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?
#6
Reengineering towards Product Line
#7
Outline
Introduction Challenges Variation Point Concepts Usage Open Issues
#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?
#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?
…
#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
#11
Outline
Introduction Challenges Variation Point Concepts Usage Open Issues
#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
#13
Example
Consider the following architecture
#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)
#15
Scenario 1: architecture is a PA The primitive components are fully specified
Two cases may be considered
#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
#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
#18
Scenario 2: architecture is the CA Only the unshaded boxes are fully specified
Again, two cases may be distinguished
#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
#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
#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
#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 …
#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
#24
Outline
Introduction Challenges Variation Point Concepts Usage Open Issues
#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