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

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

Product-line architecture

Storage-server architecture

camera-server architecture

scanner-server architecture

CDROM-server architecture

File server architecture

Variations Variations

Variations Variations

Domain of study

Printer-server architecture

General printer-serverarchitecture

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

Product Overview

InterVision(System integration)

EBL 512 UC 40 scanner-server architecture

IC 20

IC 24EBL 1000

EBL 2000

Fire-alarm systems Intruder-alarm systems access control systems camera 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. GannodThe 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 analyzingOverview of the applicationArchitecture recovery and specificationArchitecture evaluation (using scenarios)Tool assisted architecture analysisConsiderations

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.

TranslationSpin Model Checker

Spin output of verification

Considerations

Paper I 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