First-Class Change Objects for Feature-Oriented Programming
Summary (2 min read)
1 Feature oriented programming
- Pioneering work on software modularity was made in the 70’s by Parnas  and Dijkstra .
- Feature Oriented Programming (FOP) is an implementation of that idea that modularises every concern as a separate feature.
- They satisfy intuitive user-formulated requirements on the software system.
- In such designs, there is little or no quantification, but there are indeed ”cross-cuts” .
- Mixin Layers , AHEAD , FeatureC++ , Composition Filters  and Delegation Layers  are all stateof-the-art approaches to FOP that implement features by cross-cuts that are modifications or extensions to multiple software building blocks.
2 Change as first-class objects
- Together with us, other researchers pointed out the use of encapsulating change as first-class entities.
- Robbes shows that the information from the change objects provides a lot more information about the evolution of a software system than the central code repositories.
- In , Denker shows that first-class changes can be used to define a scope for dynamic execution and that they can consequently be used to adapt running software systems.
2.1 Model of changes
- The authors use the FAMIX model  to express the building blocks of a software system.
- Figure 1 shows that the core of the FAMIX model consists of Classes, Methods, Attributes and relations between them.
- The authors identify three possible commands on those subjects: the addition, the removal and the modification of the building block.
- An elaborated discussion about atomic and composite changes is is omitted because it does not resides in the scope of this paper.
- For more information about the model of changes, the authors refer to .
2.2 Change-oriented programming
- In  and  the authors propose change-oriented programming (ChOP): an approach that centralises change as the main development entity.
- Behind the scenes, ChEOPS produces fine-grained first-class change objects that represent the development actions taken by the developer.
- The authors distinguish between two kinds of dependencies: syn- tactic dependencies – imposed by the meta-model of the used programming language and exemplified above – and semantic dependencies – that depend on domain knowledge.
- Logging source code, change objects.
- Figure 4 shows two extra features: Restore allows the buffer to restore its previous value, Logging makes sure that all methods of the buffer are logged when executed.
- The difference between flexible (dashed lines) and monolithic features (full lines) is that the latter can only be applied as a whole, while the former can be applied partially.
2.3 Software composition
- In their model, a feature composition is valid if the union of the change sets that implement the features in that composition does not contain a change that has a dependency to a change object that is not in the composition.
- Change objects and the dependencies amongst them can be visualised by a directed graph.
- Change objects with a blue dashed line belong to the flexible Logging.
- The problem is that those changes respectively depend on R1 and R2 which are not in the composition.
- The semantic information stating that the Logging feature is flexible, allows the exlusion of L12 and L15 from the composition.
- The authors see three advantages in the specification of features in terms of fine-grained first-class change objects: increased expressiveness, improved composability and a novel bottom-up approach to FOP.
- In comparison with state-of-the-art approaches to FOP, which allow the specification of features as a set of program building blocks that might extend or modify existing building blocks, their approach allows a more expressive feature specification.
- Next to that, features can express changes up to statement level, which is more fine-grained than the state-of-the-art (only allowing the expression of addition or modification on class or method level).
- The dependencies between change objects provide the fine-grained information that is required to verify whether a certain feature composition is valid.
- Some state-of-the-art approaches also provide an implementation of this bottomup approach.
- The authors advocate feature oriented programming (FOP) as the right development technique to modularize software systems.
- The authors find the state-of-the-art approaches to FOP not satisfactory and present an alternative approach based on the specification of features by sets of change objects rather than program building blocks.
- Features are functions that can be applied to add the functionality they implement.
- This increases the expressiveness of features as they can specify adaptations to fine-grained building blocks (classes, methods, attributes and statements).
- The dependencies between the change objects provide the necessary information to validate feature compositions.
Did you find this useful? Give us your feedback
Cites result from "First-Class Change Objects for Feat..."
...So, our results support the philosophy of viewing features as cohesive units that should be developed independently [7,28,29], rather than viewing features as transformations that have access to all program elements [30,31]....
Cites background from "First-Class Change Objects for Feat..."
...Patches are changes of source code that do not track the complete history of actions that led to the changes , ....
"First-Class Change Objects for Feat..." refers methods in this paper
...Pioneering work on software modularity was made in the 70’s by Parnas  and Dijkstra ....
Related Papers (5)
Romain Robbes, Michele Lanza
Axel Rauschmayer, Alexander Knapp +1 more
Richard Holt, David A. Penny +1 more
James Leslie Keedy, Klaus Espenlaub +3 more