240 likes | 405 Vues
This document delves into the complexities of feature models within software product lines, highlighting the need for formal descriptions of product instances sharing common features with varying implementations. By exploring essential concepts such as mandatory features, optional features, exclusive or, and conflicting features, it elucidates how to model product variability. Key examples like the Windows 7 product line demonstrate practical applications. The framework supports creating variations through techniques such as subclassing and conditional statements, essential for effective software engineering.
E N D
Reading for Monday • REST Topics • http://www.infoq.com/articles/rest-introduction • Arch book p. 414–422 • Roy Fielding’s thesis perhaps most cited CS thesis, worth a scan if you want to see what one looks like.
Product Lines • Want to make several related products • Products share many common features • But features vary between products • Want a formal description of all possible product instances in a product line • Use Feature Models! • Model formalizes feature requirements • Does not address implementation
Software Product Line Example • Windows 7 Product Line • Starter • Home Premium • Professional • Ultimate
Cross-Tree Constraints X X X X Conflict Requires
Realistic Feature Model • For illustration purposes only • Uses extra syntax we don’t learn in this course
Mandatory Feature Product Line also referred to as Product Concept (denoted as C)
Conflicting Features • Two features that cannot • exist in the same product • Used when features are not • siblings • {C}, {C, f1}, {C, f1, f2} • {C, f2}, {C, f1, f3} X X
Dependent Features • When one feature requires • another • Used when features are • not parent/child • {C}, {C, f1}, {C, f1, f2} • {C, f2}, {C, f1, f2, f3}
Feature Implementation • Often, a feature is not a class • Hence, feature models are not class diagrams • A feature can be implemented many ways • Class • Set of classes • A scattered set of methods • A scattered set of statements • etc… • The Feature Modeler does not concern themselves with such details
Example: Logging Feature class Account { private double total; public void deposit(double amount) { System.out.println(“User is depositing: “ + amount); … } public void withdraw(double amount) { System.out.println(“User is withdrawing: “ + amount); … } public double balance() { System.out.println(“User is checking balance”); … } } Where is the logging feature?
Example: Logging Feature class Account { private double total; public void deposit(double amount) { System.out.println (“User is depositing: “ + amount); … } public void withdraw(double amount) { System.out.println(“User is withdrawing: “ + amount); … } public double balance() { System.out.println(“User is checking balance”); … } } Where is the logging feature?
Where is Logging in Apache Tomcat? Picture from: Waterhouse and Kersten, kerstens.org/mik/publications/aspectj-tutorial-oopsla2004.ppt
Consider Your Project • At the end of the term … If I asked you where each User Story was in your code … • Most likely each User Story could not be isolated to a single • Class • Method • Statement • A good bonus mark candidate would be to describe your product using a feature model as described here.
Variability Implementation • How do we create variation in product lines? • Subclassing • Conditionals and IFDEF statements • Decorators/Connectors • Separate code bases • Likely to be different branches of a repository
Linux variability Linux has ~ 5400 features