The Software Product Line Architectures

1
The Software Product Line Architectures

• Instructor Dr. Hany H. Ammar
• Dept. of Computer Science and Electrical
  Engineering, WVU

2
outline

• What is software Product Line.
• http//www.sei.cmu.edu/productlines/frame_report/w
  hat.is.a.PL.htm
• Product Line Architecture Development Process
• http//www.cs.ncl.ac.uk/publications/inproceedings
  /papers/574.pdf
• Examples

3
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.

4
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.

5
outline

• What is software Product Line.
• http//www.sei.cmu.edu/productlines/frame_report/w
  hat.is.a.PL.htm
• Product Line Architecture Development Process
• http//www.cs.ncl.ac.uk/publications/inproceedings
  /papers/574.pdf
• Examples

6
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_at_iese.fhg.de, http//www.cs.ncl.ac.uk/public
  ations/inproceedings/papers/574.pdf

7
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.

8
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.

9
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

10
PuLSE-DSSA Process The Domain Models 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.

11
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

12
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 iterations design decisions impose
  constraints on the architecture that delimit its
  further evolution.

13
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.

14
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

15
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

16
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

17
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.

18
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.

19
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.

20
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
• Identifying product specific requirements
• Initial screening of the components and selecting
  the ones that can be reused for the product
• From the component selected in the previous step,
  select only those components that are reusable
  after some adaptation

21
SPL Instantiation Process (cont.)

• Binding and adding variants for the variability
  points in the selected components
• Implementing new components to fulfill new
  requirements (product specific requirements).
  Some of these might end up being included in the
  product line architecture
• Integrating the resulting components and perform
  product specific development
• Finally, maintaining the product after deployment

22
outline

• What is software Product Line.
• http//www.sei.cmu.edu/productlines/frame_report/w
  hat.is.a.PL.htm
• Product Line Architecture Development Process
• http//www.cs.ncl.ac.uk/publications/inproceedings
  /papers/574.pdf
• Examples

23
Example 1 PLA for a Microwave Oven
24
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 ltltkernelgtgt 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 ltltoptionalgtgt is used to specify
  optionality in UML class diagrams.
• The optionality can concern classes, packages,
  attributes or operations. So the ltltoptionalgtgt
  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 ltltvariantgtgt and
• each subclass will be stereotyped ltltvariantgtgt, or
  ltltoptionalgtgt, the default value being variant.

25
Example 1(cont.) Microwave Sample Sequence
Diagram
26
Example 2 Library Class Diagram
27
Example 3 Ecommerce Class Diagram
28
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

29
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.

30
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