Productline Architecture in Industry: A Case Study

1
Product-line Architecture in Industry A Case
Study

• Jan Bosh
• University of Karlskrona/Ronneby

Vanilson Burégio vaab_at_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 90s, 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
• Todays 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
Printer-server architecture
Storage-server architecture
camera-server architecture
scanner-server architecture
IBMprinter-server architecture
General printer-serverarchitecture
CDROM-server architecture
File server architecture
Domain of study
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

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)
  253267

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