Productline Architecture in Industry A Case Study Jan

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

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

Contents l l l Context Case Study Method Case Study organizations Problems Issues Conclusions

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

Case Study Method l The goals – – l Understanding of the PLA state of pratice in smalland 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

Case Study Organizations l l 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.

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

Case 1: Axis Communications AB l Organization model – System development was organized into business units l 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

Case 2: Securitas Larm AB l Product Overview Inter. Vision (System integration) EBL 512 IC 20 EBL 1000 IC 24 UC 40 scanner-server architecture EBL 2000 Fire-alarm systems Intruder-alarm systems access control systems camera control systems

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

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

Issues l Domain engineering units – – l 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. . .

Issues l Business units versus development departament – l Time-to-market versus asset quality – l There are no general answers to wich organizational form is best 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 productspecific and product variation specific code

Conclusions l l 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

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

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

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

The process used in analyzing l 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

Overview of the application l Interferometer

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

Architecture recovery and specification l Baseline Architecture

Architecture recovery and specification l Planned products in the product line

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

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

Architecture evaluation using scenarios l Analyzing the architectures modifiability via scenarios

Tool assisted architecture analysis l Process – – – l 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 l – 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 l Promela, the input specification language for Spin

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

Considerations Paper II Documentation An identified problem Some documentation of the requirements and architecture design were outdated ADL Research issues ACME 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