Course: Ingegneria del Software II academic year: 2004-2005 Course Web-site: [www.di.univaq.it/ingegneria2/] Software Product Lines and Product Line Architectures Lecturer: Henry Muccini and Vittorio Cortellessa Computer Science Department University of L'Aquila -Italy muccini@di.univaq.it cortelle@di.univaq.it [www.di.univaq.it/muccini] [www.di.univaq.it/cortelle]
Copyright Notice» The material in these slides may be freely reproduced and distributed, partially or totally, as far as an explicit reference or acknowledge to the material author is preserved. Henry Muccini 2 2/41
Acknowledgment» This work is partially joined with A. van der Hoek (University of California Irvine), and Antonio Bucchiarone (ISTI CNR) 3 3/41
Agenda» Product Line» Product Line Architecture (PLA)» SA vs PLA» Testing Product Line Architecture 4 4/41
Product Lines and Product Families» Product Line: - This term was introduced by the US community» Product Family: - This term originated within a series of European industrial-cooperation projects 5 5/41
Product Line» Definition: A software product line is 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 and that are developed from a common set of core assets in a prescribed way. [P. Clements - L. M. Northrop, 2001] 6 6/41 (Software Engineering Institute, CMU)
Product Family» Definition: A product family defines a similar concept, which is, a group of systems sharing a common, managed set of features that satisfy core needs of a scoped domain. 7 7/41 [F. Van Der Linden and A. Van Der Klose, 2002] (CAFÉ and ESAPS European Projects)
The general idea» The idea behind a system-family approach is to: - build a new system or application from a common set of assets > A software asset might be a component, known requirements or design elements, models, artifacts that an engineer uses to build or modify a software product - in the same line (i.e., domain) > pertaining to a general production line of a company 8 8/41
An example Car product line 9 9/41
Keywords > 1/3» Variability: - Variability is the ability to change or customize a software system [Jan Bosch, 2002]» Variation point: - A variation point refers to a delayed design decision, i.e., it indicates a specific point in the development or deployment phase of a software system - The intention of designing a variation point into a system is to insert a variant (alternative) at a later phase in the lifecycle 10 10/41
Keywords > 2/3» Features: - Underlying def: a feature groups related requirements - Features are an abstraction mechanism to express variability - Cross-cutting features - FODA: Feature Oriented Domain Analysis 11 11/41
Keywords > 3/3» Levels: - Domain - Application» MDA: - Model driven Architecture 12 12/41
Why Product Lines? 13 13/41
Product Lines and Reuse 14 14/41
Reuse and Product Line 15 15/41
Reuse and Product Line 16 16/41
Product Line in Practice: success story 17 17/41
18 18/41
19 19/41
Results 20 20/41
21 21/41
Product Line Architectures» a product line architecture precisely captures, in a single specification, the overall architecture of a suite of closely-related products [Bosch2000]» A PLA explicitly specifies: i) elements that are present in all products, ii) elements that are optional, and iii) elements which may be incorporaten one of many forms (variants) 22 22/41» Whereas a regular architecture defines the structure of a single product, a product line architecture (PLA) defines the common architecture for a set of related products [Bosch2000]
An introductory example foo goop mandatory optional variant bar foobar variant 23 23/41 In total, twenty-four different product architectures can be formed.
A more complex Example 24 24/41
TDSPLA [RHMM03] 25 25/41 xadl2.0, Koala, and Maeare examples of PL ADL
SA vs PLA»a PLA captures the overall architecture of a suite of closely-related products [Bosch 00]» a PLA explicitly specifies mandatory, optional, and variant elements Mobile phone SA SA defines the structure and behavior of a single product 26 26/41 Mobile phone PLA
SA evolution vs PLA evolution» SA evolution: - Specification: from box-and line notations, to formal ADLs & UML-based notations - Analysis: model-checking, testing, deadlock detection, dependability, slicing [FormalSABook 03]» PLA evolution: - Specification: from informal notations to ADLs (such as Menage and Koala) & UML-based notations 27 27/41 - Analysis:???
Software Product Line Conference September 04 28 28/41
Testing PLA» A new challenge: - how to deal with optional elements or with the magnitude of products that may be present?» The goal of this paper is to highlight the challenges and opportunities for software testing of PLAs 29 29/41» We believe that existing mechanisms with which SAs are tested can be adapted to PLAs
Challenge» The challenge is in investigating how the entire PLA can be used to automatically generate testing information which may be effectively reused to test each derivable product. 30 30/41 modeling testing
Testing PLA- Unit Testing» SA: - Each SA component need to be unit tested» PLA: - all components should be unit tested as well > Including each optional component and each variant of a variant component - However,theorder in which they have to be tested can be adjusted based on priority. 31 31/41
Testing PLA Integration Testing» SA: - components and connectors are combined together according to the architecture configuration» PLA: - no single architectural configuration exists - Possible solutions: > Iterative build-up up integration approach: powerful but expensive > big bang: limited but effortless - Core-first + big bang approach 32 32/41 > Integrated with heuristics [15] to test only particular combinations
Testing PLA Conformance Testing» SA: - conformance testing has been used to detect conformance errors between the SA ants implementation [5].» PLA: - an implementation I conforms to its PLA when: > I conforms to a single PA > I conforms to all the possible PAs out of the PLA > I conforms, at least, to all the constraints and functionalities associated to the mandatory, core elements of the PLA 33 33/41 - a product architecture PA conforms to its PLA
Testing PLA Regression Testing» SA: - If a new version P1 v2 of an implementation P1 v1 is produced, regression testing techniques can be used to test the conformance of P1 to the initial SA - If a new version (SA v2 ) of an architecture SA v1 is produced, SA v2 test cases may be selected reusing SA v1 stest cases.» PLA: - During development (A)(B) 34 34/41 - During maintenance (C) - PLA evolution: PLAthat becomes PLA
35 35/41 PLA-based Testing (Strategy #1) 1) PLA-level testing: a. We use the PLA specification, as is, to identify PLA-based Test Cases (PlaTC) b. When a PA is selected, PlaTCs are refined to produce PA-based Test Cases - Use of combinatorial testing a. b. P L A P A
PLA-based Testing (Strategy #2) 2) Core-based testing: a. identify a particular product architecture, called minimal PA a. P L A b. Core-level test cases may be extracted, using existing SAbased testing approaches c. When a PA is selected out of the PLA, Core-level test cases are enriched 36 36/41 > SA-Based Regression Testing > Guided simulations b. c. P A
Summarizing» PLA-based Testing may keep pace with accelerated development as well as SA-based Testing» The real challenge is understanding how strategy #1 may work: - By the way, we still have to undestanf the two strategies are really different or not» For functional testing, we need a behavioral specification of PLA s components 37 37/41» Both Unit and Integration Testing
My Current work on PLA» Ongoing work: - "Towards Testing Product Line Architectures" H. Muccini, A. van der Hoek. In Etaps 03 workshop on Testing and Analysis of Component-Based Systems. - Behavioral Specification of a Product Line Architecture H. Muccini and A. Bucchiarone. - WAPLE: A Product Line Engineering Approach for Designing Web Applications H. Muccini and L. Orsini. 38 38/41 - Traceability Issues in Documenting Software Architecture in Product Families P. Lago, H. Muccini and Hans van Vliet
Who works on Product Lines>Projects 1/5» ARCHIMEDES Project - Managing Product-line Architectures - 3-year project (2001-2004) funded by TEKES (National Technology Agency) and several Finnish industrial partners (Ionific, Ingenix, Profit and Almare). - PractiseGroup -Software Systems Laboratory -Tampere University of Technology - Project leaders: Tommi Mikkonen, Kai Koskimies and Tarja Systä. 39 39/41 - http://practise.cs.tut.fi/index.html
Who works on Product Lines>Projects 2/5» CAFÉ Project - from Concept to Application in system-family Engineering - European R&D Projects -Philips Research - CAFE Project Leader: Frank van der Linden - http://www.extra.research.philips.com/euprojects/cafe/ 40 40/41
Who works on Product Lines>Projects 3/5» ESAPS Project - Engineering Software Architectures, Processes and Platforms for System-Families - Project Manager: Frank van der Linden and HenkObbink- Philips Research Laboratories - Industrial partners: Philips, Nokia, Siemens, Thomson-CSF, Sainco - Partners location: The Netherlands, Germany, Finland & Sweden, France, Spain 41 41/41 - http://www.esi.es/en/projects/esaps/overview.html
Who works on Product Lines>Projects 4/5» Kobra Project - Component-Based Product Line Engineering with UML - Project leader: Christian Bunse - Partners: FraunhoferIESE, PSIPENTA Software Systems GmbH, SoftlabGmbH, GMD FIRST - http://www.iese.fhg.de/kobra_method/ 42 42/41
Who works on Product Lines>Projects 5/5» ARES Project: - architectural reasoning for embedded systems - EC-funded research project, ESPRIT framework IV contract no. 20477-3 industrial and 3 university partners: 43 43/41 > Nokia Research Center, Philips Corporate Research, AseaBrown Boveri (ABB) Corporate Research > Technical University of Vienna, Imperial College of Science and Technology (London), and Polytechnic University of Madrid - http://www.infosys.tuwien.ac.at/staff/hg/projects/ares/homepa ge.html
Who works on Product Lines> People» Jan Bosch (variability)» Van der Linden (involven manyprojects)» Andre van der Hoek, University of California, Irvine (PLA)» Paul Clements and Linda Nortrop, Software Engineering Institute, CMU (Product Line Practice PLP)» A. Bertolino, S. Gnesi, G. Lami (ISTI CNR) and A. Fantechi (UniFi)» Charles W. Krueger, http://www.softwareproductlines.com/» P. Lago and Hans van Vliet, Vrije Universiteit» Rob van Ommering, Philips Research 44 44/41»