1. Product-line Architecture in Industry: A Case Study Jan Bosh University of Karlskrona/Ronneby Vanilson Burégio vaab@cin.ufpe.br

2. Product-line Architecture in Industry: A Case Study A case study investigating the experiences from using product line Architecture in two companies: – Axis Communications AB – Securitas Larm The study identified a collection of problems and issues

3. Contents Context Case Study Method Case Study organizations Problems Issues Conclusions

4. Context Product-line architecture (PLA) have received special attention in software industry – Increase reuse – minimize product-specific development – Competitive advantage The paper reports on a product-line architecture case study involving two Swedish organizations

5. Case Study Method The goals – Understanding of the PLA state of pratice in small- and medium-sized interprises – Identify research issues that are more relevant to software industry The used method: interviews – with the system architects and technical managers – The main focus: process and technological issues

6. Case Study Organizations Case 1: Axis Communications AB Case 2: Securitas Larm AB Since the beginning of the 90’s, both organizations have adopted PLA based software development and use of O.O. frameworks and reusable assets.

7. Case 1: Axis Communications AB Started its business in 1984 With Development of a IBM-pecific printer server product Today’s Products IBM-specific and general printer servers, CD-ROM and storage servers, network cameras and scanner servers Maintains a PLA and a set of reusable assets that are used for product construction

8. Case 1: Axis Communications AB Product-line architecture Storage-server architecture camera-server architecture scanner-server architecture CDROM-server architecture File server architecture Variations Domain of study Printer-server architecture General printer-server architecture IBM printer-server architecture Variations

9. Case 1: Axis Communications AB Organization model – System development was organized into business units Need to increase the focus on individual products – PLA and assets is shared between the business units and assets responsible are assigned – Evolution products is a major challenge

10. Case 2: Securitas Larm AB Business domain – Develops, sells, installs and maintains safety and security systems, intruder alarm systems, passage control systems and video surveillance systems – Focus in larger buildings and complexes Requiring integration between the systems

11. Case 2: Securitas Larm AB Product Overview InterVision (System integration) EBL 512UC 40 scanner-server architecture IC 20 IC 24EBL 1000 EBL 2000 Fire-alarm systemsIntruder-alarm systems access control systemscamera control systems

12. Case 2: Securitas Larm AB Organization Model – Single develoment Departament Acts a an internal supplier to business units responsible for marketing, installation and maintenance of the products

13. Problems Background knowledge Information Distribution Multiple versions of assets Dependencies between assets Assets in new contexts Documentation Tool support Effort estimation

14. Issues Domain engineering units – It is unclear if and, if so, in what cases an organization should have separate domain engineering – The explicit division was not present at interviewed companies When to split off products from product-line – Deciding to include or exclude a product in the product-line is a complex decision to make...

15. Issues Business units versus development departament – There are no general answers to wich organizational form is best Time-to-market versus asset quality – The lack of economic models clearly showing the return on investiment of PLA and reusable assets Commom feature core versus feature superset – What to include in the PLA and what to include in the product- specific and product variation specific code

16. Conclusions A number of problems were identified in the case study organization, but the general consensus si that PLA approach is beneficial Research issues – High-level abstractions are not present programming language – Documentation – Tested and simple aconomic model – Programming and architecture description language

17. Analysis of a software product line architecture: an experience report Robyn R. Lutz a,Gerald C. Gannod The Journal of Systems and Software 66 (2003) 253–267

18. Analysis of a software product line architecture: an experience report Describes experiences with the architectural specification and tool-assisted architectural analysis of high-performance software product line

19. Contents The process used in analyzing Overview of the application Architecture recovery and specification Architecture evaluation (using scenarios) Tool assisted architecture analysis Considerations

20. The process used in analyzing Structured analysis of an existing product line architecture using: – Architecture recovery and specification – Architecture evaluation – Model checking of behavior to determine the level of robustness and fault tolerance at the architectural level

21. Overview of the application Interferometer

22. Architecture recovery and specification Process – Inputs: project documentation, source code, and communication with developers – Steps Study of the product-line requirements Recovery a draft architecture from the available information and compared with an existing description

23. Architecture recovery and specification Baseline Architecture

24. Architecture recovery and specification Planned products in the product line

25. Architecture recovery and specification Lessons learned for product lines – Resolving discrepancies between actual and documented architectures some product lines are not originally designed as product lines but evolve into them as new products are created – Abstraction Some systems in the product line (e.g., testbeds) use a single copy of this building block – Advantages of ADL specifications encouraged communication and review by experts graphical view provided a front-end that represented the abstract architecture

26. Architecture evaluation using scenarios Process – Study the modifiability of the interferometry product line architecture determine to what extent the architecture was amenable to a product line development approach – Identify four categories of modifiability: extensibility deleting capabilities portability Restructuring

27. Architecture evaluation using scenarios Analyzing the architectures modifiability via scenarios

28. Tool assisted architecture analysis Process – Architecture specification in an ADL – Formal specifi-cation of behavior – Analysis of behavior to determine fault-tolerance and robustness Used tools and languages – ACME: provides an infrastructure for high-level architecture specification and ADL Wright, was used for the formal specification of behavior – Spin Model Checker: is a model checker that has been used for verifying the behavior of a wide variety of hardware and software applications Promela, the input specification language for Spin

29. Tool assisted architecture analysis Example Wright specification. Promela specification. Translation Spin Model Checker Spin output of verification

30. Considerations Paper IPaper II DocumentationAn identified problemSome documentation of the requirements and architecture design were outdated ADLResearch issuesACME was used to specify the architecture Variations and Commonalities A problem in the asset evolution process Understanding the required variations among the systems in the product line was he most difficult part of architectural recovery and specification