1 / 28

Product-line Architecture in Industry: A Case Study

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:

kaemon
Download Presentation

Product-line Architecture in Industry: A Case Study

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

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

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

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

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

  19. Overview of the application • Interferometer

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

  21. Architecture recovery and specification • Baseline Architecture

  22. Architecture recovery and specification • Planned products in the product line

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

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

  25. Architecture evaluation using scenarios • Analyzing the architectures modifiability via scenarios

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

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

  28. Considerations

More Related