1
Software Product Line Engineering
Andrew Burmester
Abstract
Software product line engineering is a successful way to greatly reduce costs and time to market. This is done by designing a framework that can be used to develop multiple applications from a single common platform. To allow for customers and engineers to successfully create these products it is necessary to document how and where the platform can be changed to achieve the amount of customization desired. Care needs to be taken during analysis and design of the platform so that the amount of diversification can be reached. This paper will provide a fundamental understanding of the processes involved to create a software product line.
Introduction
People have always wanted something special out of their vehicles. Be it from exterior and interior appearance, better safety, or higher performance, consumers have wanted to customize and personalize their own vehicles. In order to meet demands for the level of customizability of automobiles, the automotive industry has used product lines. These product lines allow for variation to take place while maintaining a similar design to its family members, allowing many more vehicles to be produced in a shorter amount of time with a relatively high quality. Can the practices used in the automotive industry apply to developing software? This paper will explore how a software product line (SPL) can be built and utilized to create a family of software products that are able to meet customers' diverse needs and be able to produce applications that meet these needs quickly.There are two distinct parts that make up a SPL that need to be specified, designed, implemented and tested separately. The first part that needs to be developed is the platform. "A software platform is a set of subsystems and interfaces that form a common structure from which a set of derivative products can be efficiently developed and produced." [1] The "derivative products" are distinct applications that utilize the platform.The processes involved with creating these components will be discussed in greater detail later in the paper.
Benefits of SPLs
There are a few motivations for a company to adopt software product line engineering (SPLE). First, there is a reduction of development costs and time to market for multiple systems [1].The initial cost for the first few systems is higher because the platform needs to be designed and may not be fully defined to support the level of variability to support the amount of customization needed to create a product family. After the platform is mature, applications can be designed and implemented quicker and cheaper.Companies that have adopted SPLE have experienced these benefits.For example, "after introducing product line engineering, medical systems provider Phillips Healthcare reported a 50 percent reduction in both time to market and product defect density and a two- to fourfold overall reduction in development effort" [3].These products are also of higher quality. Since the platform is used within multiple applications, it must be well tested [1]. The high level of testing carries into the distinct applications due to the amount of the platform being reused.Maintenance costs are also reduced. Since the system is decomposed well, bugs found within a part of the platform can be found and can propagate throughout the entire product family, saving time and resources from having to fix a problem that could have arisen in multiple applications.
Drawbacks of SPLs
Even though the benefits of SPLE are quite large, there are still numerous drawbacks that can hinder a company’s usage of SPLs.Since the payoffs from implementing a SPL only happen after a few systems, SPLE would not be appropriate if there were was not a need to create multiple systems. There are also numerous team issues that need to be overcome in order for SPLE to work. These include:
- Lack of vision toward the product line. If the entire team does not support a SPLE mind set, the process will not work.
- Incompatible team modes. Many people that are in industry have always used a specific way to manage a team and will not be able to pick up SPLE.
- Lack of core assets development. If the platform does not get designed well enough, applications will not be able to be developed from them [5].
Engineering the Product Line
Developing a SPL is very similar to developing a single system an intent to reuse large modules.However, SPLE puts a strong emphasis on documenting and modeling where the system can be varied.This difference is very important in determining how the platform can be used and what can be changed to create the desired system.Figure 1 below shows an overview of the process used to create a SPL. Domain Engineering is the process of defining how the platform will be able to change and generating artifacts that are common to the platform. Application Engineering is the process of taking the artifacts that were produced in the domain engineering process and modifying the artifacts to create the new product. This is realized by adding or changing components from the platform.
Figure 1: Graphical representation of the process of developing a product line[4]
Before talking about domain and application engineering, an understanding of how the product line handles variability in the system and how this is documented.
Variability and Documentation
Variability is the main component of a SPL and thusly needs to be documented well.There are a couple ways to capture variability in the product line; such as including variable features within standard UML diagrams [4]. The other method is using an Orthogonal Variability Model (OVM). "An orthogonal variability model is a model that defines the variability of a software product line. It relates the variability defined to other software development models such as feature models, use case models, design models, and test models"[1]. The OVM is a common place to store all information dealing with how and where a system can be changed or added to to create a new application. There are a few benefits to use the OVM over including variability into other artifacts, namely:
- OVM are smaller and less complex than UML diagrams.
- Variability is defined consistently across all system artifacts.
- Communication is easier, due to a relatively easier to understand model compared to more complex UML models. [4]
The OVM can be applied to all system artifacts to view how each variation point affects the system.
OVM, A Closer Look
Now that the benefits of using an OVM have been explained, we can explore how the OVM is created. Figure 2 shows a list of common symbols that are found in the OVM.
Figure 2: Components found in an Orthogonal Variability Model [1]
A Variation Point refers to a point that is able to change. It does not explicitly state what the value can be, but that this is a point to change. A Variant is the specific object that can be inserted at a variation point.Alternative choice is used to link a Variation Point to a Variant. It also explains any constraints on the number of variants that can be used at the Variation Point.Optional Variability Dependencies show that variants are optional if the Variation Point is to be used in the Application. A mandatory variability dependency requires that a variant be present if that Variation Point is in use [1]. Constraint dependencies state dependencies between variants and/or variation points. These are used to show if a variant requires another specific variant or variation point to work.Artifact dependencies show a relationship between the OVM and common UML diagrams. This link allows an easy way to show what artifacts are dependent upon specific variants.
Figure 3 shows a simple example of using OVM to model a security system.The diagram shows three different variation points and seven different variants. The Security Variation Point has two distinct variants, a Basic package or Advanced package. The Basic Package includes Keypad Door Locks and Motion Sensors, which are variants of points Door Locks and Intrusion Detection respectively. The inclusion of these features is captured with the “requires” constraint dependency.
Figure 3: OVM example of a security system[1]
Domain Engineering
Domain engineering is the process of developing a stable, flexible, and maintainable platform. This is done by following a typical software development process but with different goals for each phase.
Domain Specification
The purpose of this phase is to generate requirements that can be used across the entire product family.Domain requirements are gathered by analyzing the domain of that the product line is being used to modeled [2].This allows for the SPL to capture the basis of the domain, and should allow for applications to be generated much easier.During the initial specification, it is necessary to specify which requirements are common to all applications and which ones are variable. The variable requirements are used to generate the OVM[1].
Domain Design
The main focus of the domain design phase is to develop an architecture that is easily expandable by an application design [1]. The design must be highly decoupled in order to support the variability that the SPL requires, thus it is imperative to use the variation points found in the OVM to insure that a system is able to cope with variants without having to require a subsystem that may not be necessary. To help this, architectural patterns should be used [2]. It may also begin to be time to look for commercial of the shelf (COTS) components to use in the system where appropriate [1].
Domain Implementation
Domain Implementation is the process of creating all common subsystems and the interfaces to use these components. There are no real differences between implementing a single system and a domain besides that the domain is purely abstract, there is no execution of the individual pieces [1].
Application Engineering
Engineering individual applications is similar to single system development with a few differences. While gathering application requirements, it is necessary to map requirements to variation points in the OVM. New requirements that cannot be mapped back to the OVM need to be fully analyzed and estimated before being added into the project [1]. The cost of integrating new pieces into the application may be too expensive using SPLE, and may be better developed as a single system. During the application design phase, the domain design should be used wherever necessary[2]. This allows the system to be more robust without adding redundancies into the design. It is also possible that new pieces of the application design could be useful to multiple products. In this case, it may be necessary to assimilate these modules into the platform [1].When implementing an application it is necessary to set up any domain interfaces to insure that the correct variation is achieved.
Testing the Product Line
Due to the nature of SPLs, there are different precautions when testing the product line. Special care needs to be taken when testing the domain especially. Since there is no execution point in the platform, there is no easy way to test that the domain is functioning correctly as whole. Small test applications can be built off of the platform, allowing the domain to be validated much earlier than waiting for actual products to be developed [1]. This type of testing will also mimic a single system testing schema. Another approach to testing the platform is to generate test artifacts, such as unit tests, functional tests, integration tests, etc. These artifacts can then be used during application testing to maximize reuse of the test artifacts.
More consideration needs to be given to the tests because a test artifact may be used across multiple products, making it necessary that tests are well written [7]. Since these tests can be used over multiple applications, the number of test cases to test a single module may become too great to adequately test.[7] gives a few guidelines to help mitigate the effects variability has on testing:
- Structure the set of testing processes to test each artifact as early as possible.It is imperative for tests to be developed under a strict context to reduce test cases as module is used more often, reducing the amounts of defects that need to be found as more is added into the system.
- Structure test artifacts to accommodate the product line variation.Tests need to address the innate variability of the SPL. If this is done correctly, a single test can be reused in multiple areas, thus reducing the generation of multiple tests.
- Maintain the test artifacts.As the system evolves the test documents need to be modified with the changing products. Since the test artifacts are being changed with the production artifacts, they remain up to date without adding extra stress on trying to figure out what was being done.
- Structure the testing software for traceability.To make the testing much easier to follow with the SPL, the testing software should model the architecture of the product line itself. This makes it easier to continue adding to the test suite as more is added into the code.
- Automate regression testing. Using tests that run on similar products canhelp make sure that a new product is correct. These regression tests should focus on variation points since there is a greater chance of defects occurring there. Automating these tests will encourage testing.
- Expand the testing portfolio. Adding new tests after the product is complete can reduce failures in the field.
Organization Structure
Adoption of SPLE requires a much different approach than what is required by a standard software developing approach. Since there is a common base that multiple products are being created off of, it may not be in the best interest to have a one to one relationship between software teams and projects [5]. This relationship tended to lead to redundant roles across projects. Figure 4 shows a better approach to organize a group of teams.
Figure 4: Matrix Product Line Model [5]
The matrix product line organizational model eliminates issues that arise in the one to one organization [5]. Since teams in the matrix work on a single aspect of multiple projects, they are familiar with the platform and what is necessary to complete that part of the project. If a team would work through a single project from start to finish, the team members will not gain the same amount of experience that the matrix product line model grants.
Conclusion
SPLE is a process that can greatly reduce an application's time to market and production cost with few drawbacks. This is done by defining points of variation within a defined platform. These variation points are documented and can link to analysis, design, implementation, and testing artifacts to insure that the system works as planned. After the platform is designed, and the variation points are noted, it is possible to generate a large amount of applications for much less than what is possible in a shorter time range that a single system approach.
References
[1] Bockle, G., Pohl, K., & van der Linden, F. (2010).Software product line engineering. Germany: Springer.
[2] Casteleyn, S., Daniel, F., Dolog, P., & Matera, M. (2009).Engineering web applications[pp. 205-207]. Retrieved from doi: 10.1007/978-3-540-92201-8
[3]Schaefer, I., & Hahnle, R. (2011). Formal methods in software product line engineering.Computer,44(2), Retrieved from
[4] Metzger, A., & Pohl, K. (2007). Variability management in software product line engineering.Proceedings of the 29th International Conference on Software Engineering, 10.1109/ICSECOMPANION.2007.83 .
[5]Li, D., & Chang, C.K. (2009). Initiating and institutionalizing software product line engineering: from bottom-up approach to top-down practice .Proceedings of the Computer Software and Applications Conference, 10.1109/COMPSAC.2009.17 .
[6] Jaring, M., Krikhaar, R.L., & Bosch, J. (2008). Modeling variability and testability interaction in software product line engineering mode.Proceedings of the Composition-Based Software Systems, 10.1109/ICCBSS.2008.9 .