Software Product Line Architectures (SPLA)

1. Software Product Line Architectures (SPLA) Nipun Shah 999-33-3588 nms043000@utdallas.edu

2. Overview • SPLA - Introduction • COPA • FAST • FORM • KobrA • QADA • Conclusion

3. SPLA – Why? Architecture is crucial ❖ Ensure product features ❖ Control complexity ❖ Organize development ❖ Manage evolution

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

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

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

7. COPA Five views of architecture

8. COPA COPA covers the following aspects of product lines: business, architecture, process and organizational aspects.

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

10. FAST • Separates product-line engineering process into two main parts: • One step concentrates on providing the core assets including the environment for implementing each product • 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: • Domain qualification to identify families worthy of investment • Domain engineering to invest in facilities for producing family members • Application engineering to use those facilities to produce family members rapidly

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

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

13. FORM Two major processes: Asset Development and Product Development

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

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

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

17. KobrA • Each Komponent is described at two levels of abstraction – • Specification: Defines the Komponent's externally visible properties and behaviors • Realization, which describes how the Komponent fulfils this contract in terms of contracts with lower level Komponents.

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

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

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

21. THANK YOU