S O F T WA RE T ECHNOLOGIE S
Formal Methods in Software Product Line Engineering Ina Schaefer, Braunschweig University of Technology Reiner Hähnle, Chalmers University of Technology
Formal methods could overcome the limitations of current SPLE practice, ensuring high product quality while decreasing time to market.
D
iversity poses a central challenge in modern software system development . Ty pic a l ly, engineers create system variants simultaneously to address a wide range of application contexts or customer requirements. For example, modern premiumclass cars have up to 1020 possible configuration variants for the same model. Apart from the interior and exterior design, customers can select from numerous extras, such as driver-assistance systems and safety or entertainment packages. Car manufacturers assert that such variability is necessary to meet consumers’ expectations and constitutes a key success factor. Likewise, there is a vast array of modern medical devices to support diagnosis and intervention, such as x-ray, ultrasound, computed tomography, and magnetic resonance imaging machines, to meet diverse customer requirements. More generally, application software on desktop computers is becoming increasingly configurable to meet users’ needs. Word processing and spreadsheet applications, for example, offer many
82
COMPUTER
options to customize their look and feel. This trend toward high software configurability extends to the system level: a recent study reveals that the Linux kernel distinguishes from among some 5,000 features, of which 4,800 are user-configurable (S. She et al., “The Variability Model of the Linux Kernel,” Proc. 4th Int’l. Workshop Variability Modeling of Software-Intensive Systems, ICB, 2010, pp. 48-51).
SPLE: BENEFITS AND LIMITATIONS Diversit y adds to complexit y because developers must anticipate variability in the requirements analysis, design, implementation, and validation stages and then realize it in the completed artifacts. Software product line engineering (SPLE) aims to alleviate this complexity by providing a set of systems with well-defined commonalities and variabilities. When developing these product lines, software engineers create customized, reusable assets and assemble them into actual products during application development.
Published by the IEEE Computer Society
SPLE offers a commercially successful approach that can improve both time to market and quality. 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 (www.splc. net/fame.html). However, current SPLE practice faces several obstacles. First, further reducing time to market without sacrificing product quality is difficult. This is especially true for applications with high safety and security requirements, such as those in the medical or automotive domains, which mandate product certification and verification. Quality assurance emerges as an even more pressing problem, given that software systems tend to become longer-lived and evolve over time to adapt to changing requirements. And maintaining a product line is more difficult and expensive than single-system maintenance. After each change cycle, the product line architecture degrades and sizable investments must be made for
0018-9162/11/$26.00 © 2011 IEEE
rearchitecting, recertification, and reverification. A major limiting factor of quality assurance in existing SPLE practice is the heterogeneity of modeling formalisms in different development phases. During requirements analysis, developers frequently use feature description languages to define a product line’s scope, while in family design they typically apply architecture description languages to represent components common to all products. In addition, developers deploy various behavioral description formalisms, such as state charts or message sequence diagrams, to model system behavior at early design stages. The lack of a uniform semantic foundation makes it difficult to ensure consistency of the different views when developing a product line. Furthermore, the only way to provide executable artifacts for prototyping or visual animation in early development stages is to create a concrete product in an implementation language, such as C or Java. This language choice, however, forces premature design decisions that should be addressed much later.
APPLYING FORMAL METHODS TO SPLE Formal methods have the potential to overcome the limitations of current SPLE practice, ensuring high product quality while decreasing time to market.
Formal methods Based on notations that have a semantics defined with mathematical rigor, formal methods allow for modeling a system and its assumed properties precisely and unambiguously. Formal system models provide the input of tools for various kinds of dynamic and static analyses, automated test-case generation, model checking, and functional verification.
During the past decade, formal methods and their accompanying tools have moved from the academic to the commercial realm. Costa, ESC/ Java, JPF, KeY, KIV, Krakatoa, PEX, SLAM, Specware, Spec#, Terminator, and Vcc are among many tools that incorporate the formal semantics of industrial programming languages such as C, C#, C++, and Java, and developers have applied them to production code in various contexts.
SPLE should be cast as a model-centric development process relying on a uniform formal modeling framework.
Uniform formal modeling framework Researchers have recently proposed several formal approaches to SPLE. Most of these approaches focus on feature or architecture description languages with formal semantics. Furthermore, some researchers have used behavioral models based on generalized temporal logic to provide generic frameworks. We argue that SPLE should be cast as a model-centric development process relying on a uniform formal modeling framework. Such a framework and its underlying modeling language include the following requirements. Formal semantics. The modeling language should be capable of expressing all relevant system aspects and their variability, based on a common formal semantics. Aspects specific to a particular deployment platform or programming language (scheduling, for example) can be left partially unspecified in early development phases. Refinement. In later development stages, models should be refined to incorporate additional design deci-
sions. During refinement, tools can check the preservation of consistency or functional properties. In this way, model refinement facilitates all phases of model-centric development. Compatibility. The framework should be compatible with traditional models of system diversity to ease the transition to a formal, modelcentric approach. It must be possible to apply feature modeling to capture a product line’s scope or to use architecture description techniques for standard component-based software development. Behavioral specification. The modeling framework should contain rich behavioral specification mechanisms in addition to structural description techniques that allow for modeling and reasoning about system behavior. Projections of the overall model provide specific views on the product line for specific purposes—for example, to focus on the component structure. The uniform semantic foundation ensures consistency of the different views. Specifically, the relation between feature models, architectural models, and behavioral component descriptions can be formally established with tool support. Variability, evolution, and reuse. Variability modeling to represent system diversity is integral to a uniform modeling framework. Variability should be captured as a first-class entity to facilitate visualization and analysis. In addition to the anticipated variability of initially planned products, modeling concepts should be flexible and expressive enough to handle unanticipated changes to support product line evolution. The language should provide primitives for reusing artifacts between different system variants. Integrating reuse mechanisms necessitates specifying and analyzing common product components only once. Modularization. The modeling language should contain structur-
FEBRUARY 2011
83
S O F T WA RE T ECHNOLOGIE S Family engineering Consistency analysis
Correctness of use
Family visualization
Test-case generation
Validation, verification
Family evolution
Validation, verification
Product evolution
Product line models with uniform formal semantics
Rapid prototyping
Code generation
Product visualization
Test-case generation
Application engineering Figure 1. A model-centric development process for software product lines based on a uniform formal modeling framework can evolve into a single-source technology that offers several important advantages over the current state of the art in SPLE.
ing mechanisms to express products and their variability modularly and hierarchically. Modularization allows splitting the product line model into manageable parts to alleviate design complexity. Hierarchical decomposition facilitates distributed development and fosters separation of concerns. Modularity and hierarchical decomposition, in connection with the explicit representation of variability, provide the foundation of efficient model analysis and validation by incremental and compositional reasoning. Executability. Models should be executable at different levels of abstraction to allow simulation and visualization. Analysis of executable product models reveals errors in system behavior in the early design stages. For ease of use, simulation and visualization tools should be integrated into the development environment. Verification. Test-case generation, model checking, theorem proving, and other verification techniques should be integrated in the development environment to rigorously ensure structural or behavioral
84
COMPUTER
constraints on both the family and product-model levels. Code generation. When models are refined to contain sufficiently ma ny det a ils, code generation techniques make it possible to implement products directly from the specified system models. Code generation should be automatic. It shouldnot require manual intervention, decrease time to market, and enable reverse engineering.
SINGLE-SOURCE TECHNOLOGY A model-centric development process for software product lines based on a uniform formal modeling framework can evolve into a singlesource technology that offers several important advantages over the current state of the art in SPLE, as Figure 1 shows. Integrating different modeling formalisms on the basis of a common formal semantics lets developers analyze the consistency of various modeling concerns, such as feature modeling, architectural descriptions, and behavioral component specifications. Language concepts for artifact
reuse help ensure consistency and correctness through formal analysis techniques. Executable models of the product line, as well as of individual products, support the use of simulation and visualization techniques during all phases of family and application engineering. This helps developers discover and correct defects early, and permits rapid prototyping of products for communication with stakeholders. Formal models allow automatic generation of test cases at both the family and product levels, which is essential for reusability and maintainability. At the product level, test cases can be reused for different products that share common components, enabling formal verification of critical system requirements during early development stages. Derived products are immediately certifiable. The product line model’s modular and hierarchical structure supports efficient validation and verification based on incremental and compositional reasoning. Code generation from formal models strives to decrease time to market without sacrificing quality. Certified code generators preserve critical requirements established at the modeling level for generated products. Model-centric development supports product line maintenance and evolution. Changes can be performed at a high level of abstraction and propagated consistently. The code for evolved products can be automatically regenerated. To deal with legacy applications or evolution at the code level, developers can use model mining techniques to derive a formal model of the system from existing code.
T
he first steps to realizing a model-centric vision of SPL E a re being undertaken in HATS (Highly Adaptable
Reiner Hähnle is a professor in the Department of Computer Science and Engineering at Chalmers University of Technology, Gothenburg, Sweden. Contact him at
[email protected].
Methods in Software Product Line Engineering (www.iese.fraunhofer.de/ de/veranstaltungen_messen/fmsple) to foster collaboration between researchers and practitioners. The FMSPLE workshop focused mainly on the potential and challenges of formal methods in SPLE. A second workshop is planned for SPLC 2011 in Munich, Germany.
Editor: Mike Hinchey, Lero—The Irish Software Engineering Research Centre;
[email protected]
Ina Schaefer is acting chair of the Software Systems Engineering Institute at Braunschweig University of Technology. Contact her at i.schaefer@ tu-braunschweig.de.
Selected CS articles and columns are available for free at http://ComputingNow.computer.org.
IEEE Software offers pioneering ideas, expert analyses, and thoughtful insights for software professionals who need to keep up with rapid technology change. It’s the authority on translating software theory into practice.
www.computer.org/ software/subscribe
SubScribe TodaY
and Trustworthy Software Using Formal Models), an integrated project supported by the European Commission’s 7th Framework Programme (www.hats-project.eu). This project aims to develop the Abstract Behavioral Specification language, a modeling language for objectoriented distributed systems that exhibit a high degree of variability, together with an integrated toolset. At the 2010 Software Product Line Conference in Jeju Island, Korea, attendees convened for the First International Workshop on Formal
FEBRUARY 2011
85
