The Software Product Line Architectures

Instructor: Dr. Hany H. Ammar

Dept. of Computer Science and Electrical Engineering, WVU

outline

What is software Product Line.– http://www.sei.cmu.edu/productlines/frame_report/what.is.a.PL.htm

Product Line Architecture Development Process– http://www.cs.ncl.ac.uk/publications/inproceedings/papers/574.pdf

Examples

What is software Product Line?

Re-use of asset architecture for some systems can maximize company investment.

Mature organization keeps their architecture as an intellectual asset which is very valuable and able to increase turn over and reduce cost.

Software Product Line – discipline, and re-use strategy sharing of asset in producing a group of products.

Objective – able to re-use asset from the previous projects such as basic architecture, the same element, designs, documentations, user manual, artifact project management such as budgeting and scheduling, and test plan & test cases.

When the product line produced, the assets will be kept in asset library to be used for other projects.

What is Software Product Line? Software product line is defined as “A set of

software-intensive systems sharing a common managed set of features that satisfy the specific needs of a particular market segment or mission”

These Systems are developed from a common core of assets (e.g. a common architecture) in a prescribed way.

The creation and validation of product line software architectures are inherently more complex than those of software architectures for single systems.

outline

What is software Product Line.– http://www.sei.cmu.edu/productlines/frame_report/wha

t.is.a.PL.htm Product Line Architecture

Development Process– http://www.cs.ncl.ac.uk/publications/

inproceedings/papers/574.pdf Examples

PLA Development Process

Creating Product Line Architectures1: Joachim Bayer, Oliver Flege, and Cristina Gacek Fraunhofer Institute for Experimental Software Engineering (IESE) Sauerwiesen 6, D-67661 Kaiserslautern, Germany {bayer, flege, gacek}@iese.fhg.de, http://www.cs.ncl.ac.uk/publications/inproceedings/papers/574.pdf

PuLSE-DSSA Process

The PuLSE-DSSA is a customizable process that integrates product line architecture creation and evaluation

The input is a scope definition and a domain model,

The scope definition determines the commonalities and variations of applications within the product line.

PuLSE-DSSA Process: Scope Definition as input

Ideally, the scope definition is based on a process that seeks to estimate the economic value each distinct feature would have for the product line

Determining which system functions are essential in the product line, and which are not.

Presenting organization scope about product types which will be developed now and in the future.

Input for the production of scopes comes from organization strategic planner, marketing staff, domain analysis and technology experts.

Scope of product line is one of the critical factors in determining the success of the product line.

The major problem in determining the scope is identifying the similarity in the systems that will reduce development cost of a system for an organization.

PuLSE-DSSA Process: The Domain Model as input, In the PuLSE product line development process,

the input domain model would be a product line model consisting of generic workproducts (i.e., products describing requirements in terms of commonalities and variabilities) and a decision model.

As an example of a generic workproduct can be defined on GUIs based on the commonalities and variabilities of different users

PuLSE-DSSA Process: The Domain Model’s Decision Model A decision model captures variability in a product

line in terms of open decisions and possible resolutions.

In a decision model instance, all decisions are resolved.

As variabilities in generic workproducts refer to these decisions, a decision model instance defines a specific instance of each generic workproduct and thus specifies a particular product line member.

PuLSE-DSSA Process Steps

1. Create Scenarios Determine the most important requirements captured in

scenarios that describe critical use-cases

Conventional scenarios are described on an instance level, which makes it difficult to convey the variability information needed for product line requirements

We need to create generic scenarios that represent commonalities and variabilities

PuLSE-DSSA Process Steps

2. Group and Sort Scenarios This step yields the architecture creation plan that defines

the iterations in which the architecture development is performed.

The first iteration deals with the most important group of scenarios, the second one with the second most important group and so forth

The order in which scenarios are addressed is highly significant, because

Each iteration’s design decisions impose constraints on the architecture that delimit its further evolution.

PuLSE-DSSA Process Steps

3. Define Test Cases For each group of scenarios, test cases are defined that

will be used to evaluate the architecture at the end of each iteration.

Specifying test cases before the actual development begins has a number of benefits, including a better understanding of the requirements and

avoidance of creating tests that, due to a fixed perspective, merely support what has been developed.

evaluating the architecture is based on specific kinds of system level quality objectives such as maintainability, understandability, and reusability.

PuLSE-DSSA Process Steps

4. Apply Scenarios The group of scenarios associated with the current

iteration is used to create the initial architecture or to refine/extend an already existing, partial architecture.

This step also includes the possible integration of existing components (legacy or COTS) as well as prototyping.

The result is a (partial) architecture description and possibly a prototype.

During architecture development some variabilities might become apparent that are not driven by the problem domain, but rather by the solution

PuLSE-DSSA Process Steps

5. Evaluate Architecture In this step, the architecture resulting from the previous

step is evaluated according to the architecture evaluation plan

Evaluation has to address instance-specific as well as family specific aspects and relies on a defined instantiation mechanism.

The ease with which instances can be created allows to draw conclusions on critical family-specific characteristics

A range of possible instantiations is used to ensure that the intended products are indeed covered by the reference architecture

PuLSE-DSSA Process Steps

6. Analyze Problems In this step, the underlying problems from the evaluation

step are examined in order to determine how the architecture development process can be continued.

The examination focuses on whether the current group of scenarios could be applied successfully to the architecture that resulted from the previous iterations.

Some design decisions from an earlier iteration are presumed to impose constraints that are too stringent for the current set of scenarios.

Therefore, extended backtracking is needed, which may include reformulating, regrouping, and reordering of some scenarios and then reentering the process in the appropriate iteration

Product Line Architecture variation points

The most important tasks that need to be done to define the architecture in product lines:– Identifying variation points.– Supporting variation points.

Identifying the Variation Point

Continuous task because:

– Variation maybe identified in development process.

– Variation maybe identified during the creation process, product line requirement like: purpose, platform, interface, quality, and target market.

– During the architecture design such as: choose as whether to perform the identified variation at the requirement analysis phase or architecture.

– During implementation.

Supporting Variation Point Architecture will support variation points in the form of:

– Using or eliminating elements.

– Using the same elements with variant attributes.

– Choosing the element which has same interface but different implementation or different quality attribute.

Implementation Techniques:

– In OO system, the use of specialization and generalization for class.

– Developing extension points at the element.

– Using the same parameter within the component.

– Over loading – using the same function in different type of data.

SPL Instantiation Process

The instantiation process involves using and adapting a product line to deliver a working product that meets the product specific requirements. The process typically involves the following steps:

1. Identifying product specific requirements 2. Initial screening of the components and selecting the

ones that can be reused for the product 3. From the component selected in the previous step,

select only those components that are reusable after some adaptation

SPL Instantiation Process (cont.)

4. Binding and adding variants for the variability points in the selected components

5. Implementing new components to fulfill new requirements (product specific requirements). Some of these might end up being included in the product line architecture

6. Integrating the resulting components and perform product specific development

7. Finally, maintaining the product after deployment

outline

What is software Product Line.– http://www.sei.cmu.edu/productlines/frame_report/wha

t.is.a.PL.htm Product Line Architecture

Development Process– http://www.cs.ncl.ac.uk/publications/

inproceedings/papers/574.pdf Examples

Example 1: PLA for a Microwave OvenDoorSensor<<kernel>>

+Door Opened()+Door Closed()

WeightSensor<<kernel>>

Keypad<<kernel>>

+Cooking Time Selected()+Cooking Time Entered()+Start()

HeatingElement<<kernel>>

Lamp<<optional>>

Display<<kernel>>

Beeper<<optional>>

Turntable<<optional>>

BooleanWeightSensor<<default>>

+Item Placed()+Item Removed()

AnalogWeightSensor<<variant>>

One-levelHeatingElement<<default>>

Multi-levelHeatingElement<<variant>>

One-lineDisplay<<default>>

+Read()

Multi-lineDisplay<<variant>>

MicrowaveOvenSystem

Definition of Terms Used in the Example Class Diagram

Kernel: Kernel in product lines represents the mandatory features for the product line members. i.e.: they cannot be omitted in products.

– The stereotype <<kernel>> is used to specify Kernel in UML class diagrams.

Optional: Optionality in product lines means that some features are elective for the product line members, which means they can be omitted in some products and included in others.

– The stereotype <<optional>> is used to specify optionality in UML class diagrams.

– The optionality can concern classes, packages, attributes or operations. So the <<optional>> stereotype can be applied to Classifier, Package and Feature meta-classes.

Variant: Variant classes are modeled using UML inheritance and stereotypes. Each variation point will be defined by an abstract class and a set of subclasses.

– The abstract class will be defined with the stereotype <<variant>> and – each subclass will be stereotyped <<variant>>, or <<optional>>, the default value

being variant.

Example 1(cont.): Microwave Sample Sequence Diagram

Example 2: Library Class Diagram

Example 3: Ecommerce Class Diagram

Evaluating the Architecture to Suit Product Lines

Product Line architecture is analyzed for:

– Robustness.

– Generality.

How and why and When to evaluate:

– How: Focus on the variation point – ensure suitability, flexibility, faster product development.

– Why: Identifying the quality of scenarios involved.

– When: Evaluate when a new product falls out of the scope, or needs components not included in the PLA

Creating and DevelopingProduct Line

From time to time, organization will add new member in product line based on the products that has been developed.

Problem in managing product line evolution that always increasing.

Product evolution comes from 2 sources:– External Source.

New element from produce/ manufacturer to be included in the product line and new product will be produce from it.

– Internal Source. For product function in the scope of product line will be using the

existing function. If not, new function will be developed, and it needs to be analyzed as whether it needs to be added in the product line or not.

Conclusions

This lectures introduced the concepts of product line architectures using 3 examples.

We also discussed issues related to evaluating and implementing product line architectures