Family-based deductive verification of software product lines
26 Sep 2012-Vol. 48, Iss: 3, pp 11-20
TL;DR: This work presents a family-based approach of deductive verification to prove the correctness of a software product line efficiently and shows that the theorem prover KeY can be used off-the-shelf for this task, without any modifications.
Abstract: A software product line is a set of similar software products that share a common code base. While software product lines can be implemented efficiently using feature-oriented programming, verifying each product individually does not scale, especially if human effort is required (e.g., as in interactive theorem proving). We present a family-based approach of deductive verification to prove the correctness of a software product line efficiently. We illustrate and evaluate our approach for software product lines written in a feature-oriented dialect of Java and specified using the Java Modeling Language. We show that the theorem prover KeY can be used off-the-shelf for this task, without any modifications. Compared to the individual verification of each product, our approach reduces the verification time needed for our case study by more than 85%.
Citations
More filters
TL;DR: A classification of product-line analyses is proposed to enable systematic research and application in software-product-line engineering and develops a research agenda to guide future research on product- line analyses.
Abstract: Software-product-line engineering has gained considerable momentum in recent years, both in industry and in academia. A software product line is a family of software products that share a common set of features. Software product lines challenge traditional analysis techniques, such as type checking, model checking, and theorem proving, in their quest of ensuring correctness and reliability of software. Simply creating and analyzing all products of a product line is usually not feasible, due to the potentially exponential number of valid feature combinations. Recently, researchers began to develop analysis techniques that take the distinguishing properties of software product lines into account, for example, by checking feature-related code in isolation or by exploiting variability information during analysis. The emerging field of product-line analyses is both broad and diverse, so it is difficult for researchers and practitioners to understand their similarities and differences. We propose a classification of product-line analyses to enable systematic research and application. Based on our insights with classifying and comparing a corpus of 123 research articles, we develop a research agenda to guide future research on product-line analyses.
444 citations
18 Aug 2013
TL;DR: A key finding is that variability-aware analysis outperforms most sampling heuristics with respect to analysis time while preserving completeness.
Abstract: The advent of variability management and generator technology enables users to derive individual variants from a variable code base based on a selection of desired configuration options. This approach gives rise to the generation of possibly billions of variants that, however, cannot be efficiently analyzed for errors with classic analysis techniques. To address this issue, researchers and practitioners usually apply sampling heuristics. While sampling reduces the analysis effort significantly, the information obtained is necessarily incomplete and it is unknown whether sampling heuristics scale to billions of variants. Recently, researchers have begun to develop variability-aware analyses that analyze the variable code base directly exploiting the similarities among individual variants to reduce analysis effort. However, while being promising, so far, variability-aware analyses have been applied mostly only to small academic systems. To learn about the mutual strengths and weaknesses of variability-aware and sampling-based analyses of software systems, we compared the two strategies by means of two concrete analysis implementations (type checking and liveness analysis), applied them to three subject systems: Busybox, the x86 Linux kernel, and OpenSSL. Our key finding is that variability-aware analysis outperforms most sampling heuristics with respect to analysis time while preserving completeness.
152 citations
31 May 2014
TL;DR: This research summary outlines current and future research challenges anticipated from major trends in software engineering and technology and outlines a standardized software product line framework.
Abstract: Software product line engineering has proven to empower organizations to develop a diversity of similar software-intensive systems (applications) at lower cost, in shorter time, and with higher quality when compared with the development of single systems. Over the last decade the software product line engineering research community has grown significantly. It has produced impressive research results both in terms of quality as well as quantity. We identified over 600 relevant research and experience papers published within the last seven years in established conferences and journals. We briefly summarize the major research achievements of these past seven years. We structure this research summary along a standardized software product line framework. Further, we outline current and future research challenges anticipated from major trends in software engineering and technology.
148 citations
25 Mar 2012
TL;DR: This paper demonstrates how to take any standard intraprocedural data flow analysis and automatically turn it into a feature-sensitive dataflow analysis in three different ways, which are capable of analyzing all valid methods of an SPL without having to generate all of them explicitly.
Abstract: Software product lines (SPLs) are commonly developed using annotative approaches such as conditional compilation that come with an inherent risk of constructing erroneous products. For this reason, it is essential to be able to analyze SPLs. However, as dataflow analysis techniques are not able to deal with SPLs, developers must generate and analyze all valid methods individually, which is expensive for non-trivial SPLs. In this paper, we demonstrate how to take any standard intraprocedural dataflow analysis and automatically turn it into a feature-sensitive dataflow analysis in three different ways. All are capable of analyzing all valid methods of an SPL without having to generate all of them explicitly. We have implemented all analyses as extensions of SOOT's intraprocedural dataflow analysis framework and experimentally evaluated their performance and memory characteristics on four qualitatively different SPLs. The results indicate that the feature-sensitive analyses are on average 5.6 times faster than the brute force approach on our SPLs, and that they have different time and space tradeoffs.
93 citations
Cites background from "Family-based deductive verification..."
...[36] show how to formally prove that contracts are satisfied by a product line implementation....
[...]
TL;DR: An exploratory study on 10 feature-oriented systems found that the majority of feature interactions could be detected based on feature-based specifications, but some specifications have not been modularized properly and require undesirable workarounds to modularization.
74 citations
References
More filters
01 Nov 1990
TL;DR: This report will establish methods for performing a domain analysis and describe the products of the domain analysis process to illustrate the application of domain analysis to a representative class of software systems.
Abstract: : Successful Software reuse requires the systematic discovery and exploitation of commonality across related software systems. By examining related software systems and the underlying theory of the class of systems they represent, domain analysis can provide a generic description of the requirements of that class of systems and a set of approaches for their implementation. This report will establish methods for performing a domain analysis and describe the products of the domain analysis process. To illustrate the application of domain analysis to a representative class of software systems, this report will provide a domain analysis of window management system software.
4,420 citations
"Family-based deductive verification..." refers background in this paper
...A feature model is a hierarchical structure defining all features of a product line and their valid combinations [20]....
[...]
...A feature is an end-user-visible program characteristic [20]....
[...]
Book•
01 Aug 2001
TL;DR: The Three Essential Activities: Core Asset Development, Software Engineering Practice Areas, and Single-System Development with Reuse - All Three Together.
Abstract: Foreword. Preface. Acknowledgements. Dedication. Reader's Guide. I. SOFTWARE PRODUCT LINE FUNDAMENTALS. 1. Basic Ideas and Terms. What Is a Software Product Line? What Software Product Lines Are Not. Fortuitous Small-Grained Reuse. Single-System Development with Reuse. Just Component-Based Development. Just a Reconfigurable Architecture. Releases and Versions of Single Products. Just a Set of Technical Standards. A Note on Terminology. For Further Reading. Discussion Questions. 2. Benefits. Organizational Benefits. Individual Benefits. Benefits versus Costs. For Further Reading. Discussion Questions. 3. The Three Essential Activities. What Are the Essential Activities? Core Asset Development. Product Development. Management. All Three Together. For Further Reading. Discussion Questions. II. SOFTWARE PRODUCT LINE PRACTICE AREAS. Describing the Practice Areas. Starting versus Running a Product Line. Organizing the Practice Areas. 4. Software Engineering Practice Areas. Architecture Definition. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Architecture Evaluation. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Component Development. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. COTS Utilization. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Mining Existing Assets. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Requirements Engineering. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Software System Integration. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Testing. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Understanding Relevant Domains. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. 5. Technical Management Practice Areas. Configuration Management. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Data Collection, Metrics, and Tracking. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Make/Buy/Mine/Commission Analysis. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Process Definition. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Scoping. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Technical Planning. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Technical Risk Management. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Tool Support. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. 6. Organizational Management Practice Areas. Building a Business Case. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Customer Interface Management. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Developing an Acquisition Strategy. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Funding. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Launching and Institutionalizing. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Market Analysis. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Operations. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Organizational Planning. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Organizational Risk Management. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Structuring the Organization. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Technology Forecasting. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Training. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. III. PUTTING THE PRACTICE AREAS INTO ACTION. 7. Software Product Line Practice Patterns. The Value of Patterns. Software Product Line Practice Pattern Descriptions. The Curriculum Pattern. The Essentials Coverage Pattern. Each Asset Pattern. What to Build Pattern. Product Parts Pattern. Assembly Line Pattern. Monitor Pattern. Product Builder Pattern. Cold Start Pattern. In Motion Pattern. Process Pattern. Factory Pattern. Other Patterns. Practice Area Coverage. Discussion Questions. 8. Product Line Technical Probe. What Is the Product Line Technical Probe? Probe Interview Questions. Probe Participants. Probe Process. Using the Probe Results. Conducting a Mini Self-Probe. Discussion Questions. 9. Cummins Engine Company: Embracing the Future. Prologue. Company History. A Product Line of Engine Software. Getting off the Ground. An Organization Structured for Cooperation. Running the Product Line. Results. Lessons Learned. Epilogue. Practice Area Compendium. For Further Reading. Discussion Questions. 10. Control Channel Toolkit: A Software Product Line that Controls Satellites. Contextual Background. Organizational Profiles. Project History. Control Channels. Launching CCT. Developing a Business Case for CCT. Developing the Acquisition Strategy and Funding CCT. Structuring the CCT Organization. Organizational and Technical Planning. Operations. Engineering the CCT Core Assets. Domain Analysis. Architecture. Component Engineering. Testing: Application and Test Engineering. Sustainment Engineering: Product Line Evolution. Documentation. Managing the CCT Effort. Early Benefits from CCT. First CCT Product. Benefits beyond CCT Products. Lessons and Issues. Tool Support Is Inadequate. Domain Analysis Documentation Is Important. An Early Architecture Focus Is Best. Product Builders Need More Support. CCT Users Need Reuse Metrics. It Pays to Be Flexible, and Cross-Unit Teams Work. A Real Product Is a Benefit. Summary. For Further Reading. Discussion Questions. 11. Successful Software product Line Development in Small Organization. Introduction. The Early Years. The MERGER Software Product Line. Market Maker Software Product Line Practices. Architecture Definition. Component Development. Structuring (and Staffing) the Organization. Testing. Data Collection and Metrics. Launching and Institutionalizing the Product Line. Understanding the Market. Technology Forecasting. A Few Observations. Effects of Company Culture. Cost Issues. The Customer Paradox. Tool Support. Lessons Learned. Drawbacks. Conclusions: Software Product Lines in Small Organizations. For Further Reading. Discussion Questions. 12. Conclusions: Practices, Patterns and Payoffs. The Practices. The Patterns. The Success Factors. The Payoff. Finale. Glossary. Bibliography. Index.
3,502 citations
"Family-based deductive verification..." refers background in this paper
...Software product-line engineering aims at reuse across similar software products [13, 14]....
[...]
...systems that share a common code base [13]....
[...]
Book•
16 Jun 2000TL;DR: This chapter discusses Domain Engineering and Object-Oriented Analysis and Design, and main development steps in Generative Programming, as well as Static versus Dynamic Parameterization, and a Fresh Look at Polymorphism.
Abstract: 1. What Is This Book About? From Handcrafting to Automated Assembly Lines. Generative Programming. Benefits and Applicability. I. ANALYSIS AND DESIGN METHODS AND TECHNIQUES. 2. Domain Engineering. Why Is This Chapter Worth Reading? What Is Domain Engineering? Domain Analysis. Domain Design and Domain Implementation. Application Engineering. Product-Line Practices. Key Domain Engineering Concepts. Domain. Domain Scope and Scoping. Relationships between Domains. Features and Feature Models. Method Tailoring and Specialization. Survey of Domain Analysis and Domain Engineering Methods. Feature-Oriented Domain Analysis (FODA). Organization Domain Modeling (ODM). Draco. Capture. Domain Analysis and Reuse Environment (DARE). Domain-Specific Software Architecture (DSSA) Approach. Algebraic Approach. Other Approaches. Domain Engineering and Related Approaches. Historical Notes. Summary. 3. Domain Engineering and Object-Oriented Analysis and Design. Why Is This Chapter Worth Reading? OO Technology and Reuse. Solution Space. Problem Space. Relationship between Domain Engineering and Object-Oriented Analysis and Design (OOA/D) Methods. Aspects of Integrating Domain Engineering and OOA/D Methods. Horizontal versus Vertical Methods. Selected Methods. Rational Unified Process. 00ram. Reuse-Driven Software Engineering Business (RSEB). FeatuRSEB. Domain Engineering Method for Reusable Algorithmic Libraries (DEMRAL). 4. Feature Modeling. Why Is This Chapter Worth Reading? Features Revisited. Feature Modeling. Feature Models. Feature Diagrams. Other Infon-Nation Associated with Feature Diagrams in a Feature Model. Assigning Priorities to Variable Features. Availability Sites, Binding Sites, and Binding Modes. Relationship between Feature Diagrams and Other Modeling Notations and Implementation Techniques. Single Inheritance. Multiple Inheritance. Parameterized Inheritance. Static Parameterization. Dynamic Parameterization. Implementing Constraints. Tool Support for Feature Models. Frequently Asked Questions about Feature Diagrams. Feature Modeling Process. How to Find Features. Role of Variability in Modeling. 5. The Process of Generative Programming. Why Is This Chapter Worth Reading? Generative Domain Models. Main Development Steps in Generative Programming. Adapting Domain Engineering for Generative Programming. Domain-Specific Languages. DEMRAL: Example of a Domain Engineering Method for Generative Programming. Outline of DEMRAL. Domain Analysis. Domain Definition. Domain Modeling. Domain Design. Scope Domain Model for Implementation. Identify Packages. Develop Target Architectures and Identify the Implementation Components. Identify User DSLs. Identify Interactions between DSLs. Specify DSLs and Their Translation. Configuration DSLs. Expression DSLs. Domain Implementation. II. IMPLEMENTATION TECHNOLOGIES. 6. Generic Programming. Why Is This Chapter Worth Reading? What Is Generic Programming? Generic versus Generative Programming. Generic Parameters. Parametric versus Subtype Polymorphism. Genericity in Java. Bounded versus Unbounded Polymorphism. A Fresh Look at Polymorphism. Parameterized Components. Parameterized Programming. Types, Interfaces, and Specifications. Adapters. Vertical and Horizontal Parameters. Module Expressions. C++ Standard Template Library. Iterators. Freestanding Functions versus Member Functions. Generic Methodology. Historical Notes. 7. Component-Oriented Template-Based C++ Programming Techniques. Why Is This Chapter Worth Reading? Types of System Configuration. C++ Support for Dynamic Configuration. C++ Support for Static Configuration. Static Typing. Static Binding. Inlining. Templates. Parameterized Inheritance. typedefs. Member Types. Nested Classes. Prohibiting Certain Template Instantiations. Static versus Dynamic Parameterization. Wrappers Based on Parameterized Inheritance. Template Method Based on Parameterized Inheritance. Parameterizing Binding Mode. Consistent Parameterization of Multiple Components. Static Interactions between Components. Components with Influence. Components under Influence. Structured Configurations. Recursive Components. Intelligent Configuration. 8. Aspect-Oriented Decomposition and Composition. Why Is This Chapter Worth Reading? What Is Aspect-Oriented Programming? Aspect-Oriented Decomposition Approaches. Subject-Oriented Programming. Composition Filters. Demeter / Adaptive Programming. Aspect-Oriented Decomposition and Domain Engineering. How Aspects Arise. Composition Mechanisms. Requirements on Composition Mechanisms. Example: Synchronizing a Bounded Buffer. "Tangled" Synchronized Stack. Separating Synchronization Using Design Patterns. Separating Synchronization Using SOP. Some Problems with Design Patterns and Some Solutions. Implementing Noninvasive, Dynamic Composition in Smalltalk. Kinds of Crosscutting. How to Express Aspects in Programming Languages. Separating Synchronization Using AspectJ Cool. Implementing Dynamic Cool in Smalltalk. Implementation Technologies for Aspect-Oriented Programming. Technologies for Implementing Aspect-Specific Abstractions. Technologies for Implementing Weaving. AOP and Specialized Language Extensions. AOP and Active Libraries. Final Remarks. 9. Generators. Why Is This Chapter Worth Reading? What Are Generators? Transformational Model of Software Development. Technologies for Building Generators. Compositional versus Transformational Generators. Kinds of Transformations. Compiler Transformations. Source-to-Source Transformations. Transformation Systems. Scheduling Transformations. Existing Transformation Systems and Their Applications. Selected Approaches to Generation. Draco. GenVoca. Approaches Based on Algebraic Specifications. 10. Static Metaprogramming in C++. Why Is This Chapter Worth Reading? What Is Metaprogramming? A Quick Tour of Metaprogramming. Static Metaprogramming. C++ as a Two-Level Language. Functional Flavor of the Static Level. Class Templates as Functions. Integers and Types as Data. Symbolic Names Instead of Variables. Constant Initialization and typedef-Statements Instead of Assignment. Template Recursion Instead of Loops. Conditional Operator and Template Specialization as Conditional Constructs. Template Metaprogramming. Template Metafunctions. Metafinctions as Arguments and Return Values of Other Metafinctions. Representing Metainformation. Member Traits. Traits Classes. Traits Templates. Example: Using Template Metafunctions and Traits Templates to Implement Type Promotions. Compile-Time Lists and Trees as Nested Templates. Compile-Time Control Structures. Explicit Selection Constructs. Template Recursion as a Looping Construct. Explicit Looping Constructs. Code Generation. Simple Code Selection. Composing Templates. Generators Based on Expression Templates. Recursive Code Expansion. Explicit Loops for Generating Code. Example: Using Static Execute Loops to Test Metafunctions. Partial Evaluation in C++. Workarounds for Partial Template Specialization. Problems of Template Metaprogramming. Historical Notes. 11. Intentional Programming. Why Is This Chapter Worth Reading? What Is Intentional Programming? Technology behind IP. System Architecture. Representing Programs in IP: The Source Graph. Source Graph + Methods = Active Source. Working with the IP Programming Environment. Editing. Further Capabilities of the IP Editor. Extending the IP System with New Intentions. Advanced Topics. Questions, Methods, and a Frameworklike Organization. Source-Pattem-Based Polymorphism. Methods as Visitors. Asking Questions Synchronously and Asynchronously. Reduction. The Philosophy behind IP. Why Do We Need Extendible Programming Environments? or What Is the Problem with Fixed Programming Languages? Moving Focus from Fixed Languages to Language Features and the Emergence of an Intention Market. Intentional Programming and Component-Based Development. Frequently Asked Questions. Summary. III. APPLICATION EXAMPLES. 12. List Container. Why Is This Chapter Worth Reading? Overview. Domain Analysis. Domain Design. Implementation Components. Manual Assembly. Specifying Lists. The Generator. Extensions. 13. Bank Account. Why Is This Chapter Worth Reading? The Successful Programming Shop. Design Pattems, Frameworks, and Components. Domain Engineering and Generative Programming. Feature Modeling. Architecture Design. Implementation Components. Configurable Class Hierarchies. Designing a Domain-Specific Language. Bank Account Generator. Testing Generators and Their Products. 14. Generative Matrix Computation Library (GMCL). Why Is This Chapter Worth Reading? Why Matrix Computations? Domain Analysis. Domain Definition. Domain Modeling. Domain Design and Implementation. Matrix Type Generation. Generating Code for Matrix Expressions. Implementing the Matrix Component in IP. APPENDICES. Appendix A: Conceptual Modeling. What Are Concepts? Theories of Concepts. Basic Terminology. The Classical View. The Probabilistic View. The Exemplar View. Summary of the Three Views. Important Issues Concerning Concepts. Stability of Concepts. Concept Core. Informational Contents of Features. Feature Composition and Relationships between Features. Quality of Features. Abstraction and Generalization. Conceptual Modeling, Object-Orientation, and Software Reuse. Appendix B: Instance-Specific Extension Protocol for Smalltalk. Appendix C: Protocol for Attaching Listener Objects in Smalltalk. Appendix D: Glossary of Matrix Computation Terms. Appendix E: Metafunction for Evaluating Dependency Tables. Glossary of Generative Programming Terms. References. Index. 020130977T04062001
2,731 citations
"Family-based deductive verification..." refers background in this paper
...Software product-line engineering aims at reuse across similar software products [13, 14]....
[...]
...Generative programming is an approach to implement product lines such that each product can be derived automatically based on a feature selection [14]....
[...]
TL;DR: Methodological guidelines for object-oriented software construction that improve the reliability of the resulting software systems are presented and the theory of contract design and the role of assertions in that theory are discussed.
Abstract: Methodological guidelines for object-oriented software construction that improve the reliability of the resulting software systems are presented. It is shown that the object-oriented techniques rely on the theory of design by contract, which underlies the design of the Eiffel analysis, design, and programming language and of the supporting libraries, from which a number of examples are drawn. The theory of contract design and the role of assertions in that theory are discussed. >
2,201 citations
"Family-based deductive verification..." refers background or methods in this paper
...The idea of design by contract is to enrich programs with specifications, given in a formal language, that can be processed by tools [27]....
[...]
...Design by contract is a technique to formally specify the behavior of software along with source code [27]....
[...]
26 Sep 2005
TL;DR: This work integrates prior results to connect feature models, grammars, and propositional formulas, which allows arbitrary propositional constraints to be defined among features and enables off-the-shelf satisfiability solvers to debug feature models.
Abstract: Feature models are used to specify members of a product-line. Despite years of progress, contemporary tools often provide limited support for feature constraints and offer little or no support for debugging feature models. We integrate prior results to connect feature models, grammars, and propositional formulas. This connection allows arbitrary propositional constraints to be defined among features and enables off-the-shelf satisfiability solvers to debug feature models. We also show how our ideas can generalize recent results on the staged configuration of feature models.
1,231 citations
"Family-based deductive verification..." refers background or methods in this paper
...Common group types are alternative (exactly one of the subfeatures needs to be selected) and or (at least one of the subfeatures needs to be selected) [7]....
[...]
...Every relation between a feature and its subfeatures is translated into a propositional formula, which are then conjoined to a large formula representing the whole feature model [7]....
[...]
...For automated reasoning, feature models can also be represented using propositional formulas [7]....
[...]