Product-line Architecture in Industry: A Case Study Jan Bosh University of Karlskrona/Ronneby Vanilson Burégio

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

Contents Context Case Study Method Case Study organizations Problems Issues Conclusions

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

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

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.

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

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

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

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

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

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

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

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

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

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

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 Describes experiences with the architectural specification and tool-assisted architectural analysis of high-performance software product line

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

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

Overview of the application Interferometer

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

Architecture recovery and specification Baseline Architecture

Architecture recovery and specification Planned products in the product line

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

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

Architecture evaluation using scenarios Analyzing the architectures modifiability via scenarios

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

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

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