Software Product Line
Architectures (SPLA)
Nipun Shah
999-33-3588
nms043000@utdallas.edu
Overview
• SPLA - Introduction
• COPA
• FAST
• FORM
• KobrA
• QADA
• Conclusion
SPLA – Why?
Architecture is crucial
❖ Ensure product features
❖ Control complexity
❖ Organize development
❖ Manage evolution
SPLA – Why?
• A common platform is specified to a family of software
products.
• The platform is based on the similarities between
several products close to each other.
• The variabilities among the members of a product
family can be implemented with different variation
techniques such as parametrization or conditional
compilation.
Product Families
• A product family is a group of products sharing a
common, managed set of features that satisfy specific
needs of a selected market or application domain.
COPA
• Component-Oriented Platform Architecting Method
• Arose with Phillips Company
• The specific goal of the COPA method is to achieve the best possible fit
between business, architecture, process and organization.
• Find balance between component-based and architecture-centric
approaches
• The component-based approach is a bottom-up approach relying on
composition.
COPA
Five views of architecture
COPA
COPA covers the following aspects of product lines: business, architecture,
process and organizational aspects.
FAST
• Family Oriented Abstraction, Specification and Translation
• Introduced at AT&T
• Further developed at Lucent Technologies Bell Laboratories
• Development process for producing software in a family-oriented way
• Rapid production and careful engineering are difficult to achieve
at the same time. However, product-line engineering via FAST
tries to resolve the dilemma and to achieve both the goals.
FAST
• Separates product-line engineering process into two main parts:
1. One step concentrates on providing the core assets including the
environment for implementing each product
2. The other step utilizes the environment in the production of
different software products belonging to the family
• FAST process can be divided into the following sub-processes:
1. Domain qualification to identify families worthy of investment
2. Domain engineering to invest in facilities for producing family
members
3. Application engineering to use those facilities to produce family
members rapidly
FAST
Domain engineers
take care of the
evolution of the
family and control
that the investment in
the family stays
paying.
Application engineers
produce family
members. They are
in contact with
customers to be able
to satisfy their
requirements.
FORM
• Feature Oriented Reuse Method
• Kyo C. Kang and his co-fellows in Pohang University of Science
and Technology, Korea
• Prescribes how the feature model is used to develop domain
architectures and components for reuse
• Specific goal on how to apply domain analysis results to
engineering of reusable and adaptable domain components
FORM
Two major processes: Asset Development and Product Development
FORM
• Asset development consists of analyzing a product line (such as
marketing and product plan development and refinement,
feature modeling, and requirements analysis) and developing
architectures and reusable components based on analysis results
•
Product development includes analyzing requirements, selecting
features, selecting and adopting an architecture, and adapting
components and generating code for the product
KobrA
• Komponentenbasierte Anwendungsentwicklung
• Practical method for component-based product line engineering
with UML
• Basic goal of providing a systematic approach to the development
of high-quality, component-based application frameworks.
KobrA
• Strict distinction of products and processes
• Products of a KobrA project (e.g., models, documents, code
modules, test cases, etc.) are defined independently of, and
prior to, the processes by which they are created, and effectively
represent the goals of these processes.
KobrA
• Each Komponent is described at two levels of abstraction –
1. Specification: Defines the Komponent's externally visible properties and
behaviors
2. Realization, which describes how the Komponent fulfils this contract in
terms of contracts with lower level Komponents.
QADA
• Quality-driven Architecture design and analysis
• States a product line architecture design method providing
traceable product quality and design time quality assessment
• Quality requirements are the driving force when selecting
software structures
• Architecture design is combined with quality analysis, which
discovers if the designed architecture meets the quality
requirements set in the very beginning
QADA
• The output of the QADA method is twofold: design and analysis.
Design covers software architecture at two abstraction levels:
- Conceptual architecture
- Concrete architecture
• Analysis provides precious information concerning the quality of
the design.
- Analysis results in feedback of whether the design addresses the
quality requirements defined for the system.
- Analysis may also produce quality feedback about an existing
system.
Conclusion
•
The methods do not seem to compete with each other, because each of them has
a special goal or ideology
- COPA. Concentrated on balancing between top-down and bottom-up approaches
and covering all the aspects of product line engineering i.e. BAPO
- FAST. Family oriented process description with activities, artifacts and roles.
Therefore, it is very adapting but not applicable as it is
- FORM. Feature-oriented method for capturing commonality inside a domain.
Extended also to cover architectural design and development of code assets
- KobrA. Practical, simple method for traditional component-based software
engineering with UML. Adapts to both single systems and family development
- QADA. Concentrated on architectural design according to quality requirements
Provides support for parallel quality assessment of product line software
architectures
THANK YOU