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