scispace - formally typeset

Proceedings ArticleDOI

First-Class Change Objects for Feature-Oriented Programming

15 Oct 2008-pp 319-322

TL;DR: It is argued that the state-of-the-art approaches to FOP lack expressiveness because they specify a feature as a set of building blocks rather than a transition that has to be applied on a system in order to add that feature's functionality to the system.
Abstract: A growing trend in software construction advocates the encapsulation of software building blocks as features which better match the specification of requirements. As a result, programmers find it easier to design and compose different system variations. Feature-oriented programming (FOP) is the research domain that targets this trend. We argue that the state-of-the-art approaches to FOP lack expressiveness because they specify a feature as a set of building blocks rather than a transition that has to be applied on a system in order to add that feature's functionality to the system.We propose to specify features as sets of first-class change objects which can add, modify or delete building blocks to or from a software system. We present ChEOPS, a proof-of-concept implementation of this approach and use it to show how our approach contributes to FOP on three levels: expressiveness, composition verification and bottom-up FOP.

Summary (2 min read)

1 Feature oriented programming

  • Pioneering work on software modularity was made in the 70’s by Parnas [17] and Dijkstra [10].
  • 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” [6].
  • Mixin Layers [19], AHEAD [6], FeatureC++ [1], Composition Filters [7] and Delegation Layers [16] 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 [9], 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 [20] 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 [11].

2.2 Change-oriented programming

  • In [12] and [13] 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.

3 Advantages

  • 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.

4 Conclusions

  • 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

Content maybe subject to copyright    Report

First-class change objects for feature oriented programming
Peter Ebraert
Programming Technology Lab
Vrije Universiteit Brussel Pleinlaan 2, B-1050 Brussel, Belgium
pebraert@vub.ac.be
Abstract
A growing trend in software construction advocates the
encapsulation of software building blocks as features which
better match the specification of requirements. As a result,
programmers find it easier to design and compose different
variations of their systems. Feature-oriented programming
(FOP) is the research domain that targets this trend. We ar-
gue that the state-of-the-art techniques for FOP have short-
comings because they specify a feature as a set of build-
ing blocks rather than a transition that has to be applied
on a software system in order to add that feature’s func-
tionality to the system. We propose to specify features as
sets of first-class change objects which can add, modify or
delete building blocks to or from a software system. We
present ChEOPS, a proof-of-concept implementation of this
approach and use it to show how our approach contributes
to FOP on three levels: expressiveness, composition verifi-
cation and bottom-up development.
1 Feature oriented programming
Pioneering work on software modularity was made in
the 70’s by Parnas [17] and Dijkstra [10]. Both have pro-
posed the principle of separation of concerns that suggests
to separate each concern of a software system in a separate
modular unit. According to these papers, this leads to main-
tainable, comprehensible software that can easily be reused,
configured and extended. Feature Oriented Programming
(FOP) is an implementation of that idea that modularises
every concern as a separate feature. In FOP features are
the basic building blocks that are raised to first-class enti-
ties [4]. They satisfy intuitive user-formulated requirements
on the software system. A software product is built by com-
posing features. Many case studies show that FOP is an ap-
propriate technique to compose many variations of the same
software product ( e.g. [8, 3, 2, 5] ).
Aspect-oriented programming (AOP) [14] is another im-
plementation of that idea. Aspects focus on the quantifica-
tion by specifying predicates that identify join points at
which to insert code, feature implementations are actually
much closer to framework designs. That is, to add a feature
to a framework, there are predefined building blocks that are
to be extended or modified. In such designs, there is little
or no quantification, but there are indeed ”cross-cuts” [6].
Mixin Layers [19], AHEAD [6], FeatureC++ [1], Compo-
sition Filters [7] and Delegation Layers [16] are all state-
of-the-art approaches to FOP that implement features by
cross-cuts that are modifications or extensions to multiple
software building blocks.
The problem that we see with all approaches to FOP, is
that they all specify a feature by a set of building blocks,
rather than by a program transition that modifies a program
is such a way that the functionality that that feature imple-
ments is added. In [6], Batory already pointed out that a
feature can be looked at as a function that is applicable on a
base (a set of program building blocks). The application of
a feature on a base yields that the base is extended or modi-
fied with the building blocks specified by that feature. From
that point of view, a software composition is a sequence of
applied features to one base. AHEAD [6] is an algebra that
formalises how features can be composed as functions.
We strongly agree with that vision, but find that features
should not be limited to extend or modify existing pro-
grams. In some situations, a feature should also be able
to remove building blocks from a program. Examples of
such cases include anti-features (a functionality that a de-
veloper will charge users to not include, the creation of a
demo-application which consists of all features but only to
a certain extent, or the customisation of certain features so
that the software system copes with specific hardware re-
quirements (e.g. limited memory or computation power).
2 Change as first-class objects
Together with us, other researchers pointed out the use of
encapsulating change as first-class entities. In [18] 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 [9], 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. In this section, we
first explain a model of first-class changes and then show
how these changes can be used to do FOP.
2.1 Model of changes
We use the FAMIX model [20] to express the building
blocks of a software system. We chose FAMIX since it pro-
vides a generic model to wich most class-based program-
ming languages (e.g. Java, C++, Ada, Smalltalk) adhere.
Figure 1 shows that the core of the FAMIX model consists
of Classes, Methods, Attributes and relations between them.
Figure 1. Famix - Core Model
The model of changes expresses the different kinds of
change operations that can be applied on those building
blocks. The UML class diagram of the model’s core is
presented in Figure 2. The building blocks that are spec-
ified by the FAMIX model (FamixObject) form the
Subject of an Atomic Change. We identify three
possible commands on those subjects: the addition, the
removal and the modification of the building block. We
model those commands with the classes Add, Remove and
Modify respectively. A Composite Change is com-
posed of Changes (which can in their turn be of any
change kind). An elaborated discussion about atomic and
composite changes is is omitted because it does not resides
in the scope of this paper.
The figure shows a dependency relation between the
change objects, that is explained deeper in the following
section. Note that, thanks to the granularity of the FAMIX
model, our model allows the specification of changes on
the level of granularity of invocations and accesses (below
method level). For more information about the model of
changes, we refer to [11].
2.2 Change-oriented programming
In [12] and [13] we propose change-oriented program-
ming (ChOP): an approach that centralises change as the
apply
undo
Add
apply
undo
Modify
apply
undo
Remove
apply
undo
Atomic
Change
add
remove
modify
Subject
sourceAnchor
commentsAt
FamixObject
...
composites
apply
undo
Composite
Change
apply
undo
timeStamp
isApplied
intent
user
Change
dependentChanges
changeSubject
changesOnWhichIDepend
parent
affectingChanges
Figure 2. ChEOPS - Core Model
main development entity. Some examples of developing
code in a change-oriented way can be found in most inter-
active development environments (IDE): the creation of a
class through interactive dialogs or the modification of the
code by means of an automated refactoring. ChOP goes fur-
ther than that, however, as it requires all building blocks to
be created, modified and deleted in a change-oriented way
(e.g. adding a method to a class, removing a statement from
a method, etc).
Change and evolution oriented programming support
(ChEOPS) is an IDE plugin for VisualWorks, which we
created as a proof-of-concept implementation of ChOP.
ChEOPS fully supports ChOP but also has the capability
of logging developers producing code in the standard OO
way. Behind the scenes, ChEOPS produces fine-grained
first-class change objects that represent the development ac-
tions taken by the developer.
class Buffer {
int buf = 0;
int get() {
return( buf );
}
void set( int x ) {
buf = x;
}
}
B1
B1.1
B1.2
B1.3
B1.2.1
B1.3.1
class Buffer {
int buf = 0;
int back = 0;
int get() {
return( buf );
}
void set( int x ) {
buf = x;
back = buf;
}
void restore() {
buf = back;
}
}
R1
R2
R1.1
R2.1
class Buffer {
int buf = 0;
int back = 0;
int get() {
logit();
return( buf );
}
void set( int x ) {
logit();
buf = x;
back = buf;
}
void restore() {
logit();
buf = back;
}
void logit() {
print(back);
print(buf);
}
}
L1
L1.1
L1.2
L1.3
L1.4
L1.5
B1.2
class Buffer {
int buf = 0;
int get() {
return( buf );
}
void set( int x ) {
buf = x;
}
}
B1
B1.1
B1.2
B1.3
B1.2.1
B1.3.1
class Buffer {
int buf = 0;
int back = 0;
int get() {
return( buf );
}
void set( int x ) {
buf = x;
back = buf;
}
void restore() {
buf = back;
}
}
R1
R2
R1.1
R2.1
class Buffer {
int buf = 0;
int back = 0;
int get() {
logit();
return( buf );
}
void set( int x ) {
logit();
buf = x;
back = buf;
}
void restore() {
logit();
buf = back;
}
void logit() {
print(back);
print(buf);
}
}
L1
L1.1
L1.2
L1.3
L1.4
L1.5
B1
B1.1 B1.3
B1.2.1 B1.3.1
Buffer
Figure 3. Buffer: (left) source code (right)
change objects
Figure 3 shows the source code (on the left) and the
changes (on the right) of a Buffer. The change objects
are identified by a unique number: B1 is a change that adds
a class Buffer, B1.2.1 is a change that adds an access
of the instance variable buf. The dependencies between
change objects are also maintained by ChEOPS: B1.2.1
depends on the change that adds the method to which buf
is added (B1.2) and on the change that adds the instance
variable that it accesses (B1.1).
We 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 knowl-
edge. ChEOPS supports the former in an automatic way
and the latter by allowing the grouping of change objects in
sets that represent features denoted by the rounded squares
surrounding change objects.
class Buffer {
int buf = 0;
int get() {
return( buf );
}
void set( int x ) {
buf = x;
}
}
B1
B1.1
B1.2
B1.3
B1.2.1
B1.3.1
class Buffer {
int buf = 0;
int back = 0;
int get() {
return( buf );
}
void set( int x ) {
buf = x;
back = buf;
}
void restore() {
buf = back;
}
}
R1
R2
R1.1
R2.1
class Buffer {
int buf = 0;
int back = 0;
int get() {
logit();
return( buf );
}
void set( int x ) {
logit();
buf = x;
back = buf;
}
void restore() {
logit();
buf = back;
}
void logit() {
print(back);
print(buf);
}
}
L1
L1.1
L1.2
L1.3
L1.4
L1.5
class Buffer {
int buf = 0;
int get() {
return( buf );
}
void set( int x ) {
buf = x;
}
}
B1
B1.1
B1.2
B1.3
B1.2.1
B1.3.1
class Buffer {
int buf = 0;
int back = 0;
int get() {
return( buf );
}
void set( int x ) {
buf = x;
back = buf;
}
void restore() {
buf = back;
}
}
R1
R2
R1.1
R2.1
class Buffer {
int buf = 0;
int back = 0;
int get() {
logit();
return( buf );
}
void set( int x ) {
logit();
buf = x;
back = buf;
}
void restore() {
logit();
buf = back;
}
void logit() {
print(back);
print(buf);
}
}
L1
L1.1
L1.2
L1.3
L1.4
L1.5
Logging
B1
B1.1 B1.2B1.3
B1.2.1B1.3.1
L1
L1.1L1.2 L1.3L1.4 L1.5
R1 R2
R1.1 R2.1
B1
B1.1 B1.2B1.3
B1.2.1B1.3.1
L1
L1.1L1.2 L1.3L1.4 L1.5
R2R1
B1
B1.1 B1.2 B1.3
B1.2.1 B1.3.1
Buffer
R1
R2
R1.1 R2.1
Restore
B1
B1.1B1.3
B1
B1.1 B1.3
L1
L1.1L1.2 L1.3L1.4 L1.5
R1 R2
B1.2
Figure 4. (left) Restore source code, (middle)
Logging source code, (right) 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 ex-
ecuted. Notice the dashed line surrounding Loggings
changes: It not only denotes that these changes implement
the Logging feature, but also that Logging is a flexible
feature. 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 par-
tially. This information is used to verify whether a feature
composition is valid, as elaborated on in the next section.
2.3 Software composition
In our model, a feature composition is valid if the union
of the change sets that implement the features in that com-
position does not contain a change that has a dependency
to a change object that is not in the composition. Follow-
ing this definition, adding a flexible feature (like Logging)
to a composition is always possible, as the change objects
from such feature could be excluded from the composition
in case they would have 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. The left side of Figure 5
shows the graph of the Buffer with the Restore and
Logging features. The colors of the change objects de-
note the semantic dependencies that exist between them.
Change objects with a red full line belong to the monolithic
Restore feature. Change objects with a blue dashed line
belong to the flexible Logging.
Logging
B1
B1.1 B1.2B1.3
B1.2.1B1.3.1
L1
L1.1L1.2 L1.3L1.4 L1.5
R1 R2
R1.1 R2.1
B1
B1.1 B1.2B1.3
B1.2.1B1.3.1
L1
L1.1L1.2 L1.3L1.4 L1.5
R2R1
R1
R2
R1.1 R2.1
Restore
B1
B1.1B1.3
B1
B1.1 B1.3
L1
L1.1L1.2 L1.3L1.4 L1.5
R1 R2
B1.2
B1.2
B1
B1.1 B1.3
B1.2.1 B1.3.1
Buffer
Logging
B1
B1.1 B1.2B1.3
B1.2.1B1.3.1
L1
L1.1L1.2 L1.3L1.4 L1.5
R1 R2
R1.1 R2.1
B1
B1.1 B1.2B1.3
B1.2.1B1.3.1
L1
L1.1L1.2 L1.3L1.4 L1.5
R2R1
R1
R2
R1.1 R2.1
Restore
B1
B1.1B1.3
B1
B1.1 B1.3
L1
L1.1L1.2 L1.3L1.4 L1.5
R1 R2
B1.2
B1.2
B1
B1.1 B1.3
B1.2.1 B1.3.1
Buffer
Figure 5. Composition based on first-class
changes
The right part of Figure 5 presents a composition of a
Buffer with Logging. L12 and L15 would cause the
composition to be invalid (according to the definition of va-
lidity given above). The problem is that those changes re-
spectively depend on R1 and R2 which are not in the com-
position. The semantic information stating that the Log-
ging feature is flexible, allows the exlusion of L12 and L15
from the composition. This results in a valid composition
{B1, B11, B12, B13, B121, B131, L1, L11, L13, L14}
that specifies a buffer with a logging feature. The informa-
tion about what changes are not going to be applied (L12
and L15) and the information about changes that should be
added (R1 and R2) for the composition to be valid can be
presented to the developer in order to assist in producing a
valid composition.
3 Advantages
We see three advantages in the specification of fea-
tures 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 pro-
gram building blocks that might extend or modify existing
building blocks, our approach allows a more expressive fea-
ture specification. Features do not only express the build-
ing blocks that implement a feature, but also how that fea-
ture can be added to a software composition. Next to that,
features can express changes up to statement level, which
is more fine-grained than the state-of-the-art (only allow-
ing the expression of addition or modification on class or
method level). Finally, features can include the deletion of
certain building blocks, which is not supported by the state-
of-the-art.
The dependencies between change objects provide the
fine-grained information that is required to verify whether a
certain feature composition is valid. The notions of mono-
lithic and flexible features allow distinguishing between

change sets that must be applied as a whole (the former)
or that can be applied partially (the latter). This semantic
information allows for more flexible compositions than the
state-of-the-art approaches to FOP.
The final advantage of specifying features by change ob-
jects is that it enables a methodology for a bottom-up ap-
proach to FOP. Instead of having to specify a complete de-
sign of a feature oriented application before implementing
it (top-down), our approach allows the development of such
an application in an incremental way. Some state-of-the-art
approaches also provide an implementation of this bottom-
up approach. In [15], Liu shows that the ATS can be used to
do so by manually annotating all building blocks with infor-
mation that denotes the feature that building block belongs
to. That is a tedious task in comparison to our approach.
4 Conclusions
In this paper, we advocate feature oriented programming
(FOP) as the right development technique to modularize
software systems. We 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.
We present a model of first-class changes which can
add, modify or delete building blocks to or from a software
system. We propose to specify features in terms of those
changes. This increases the expressiveness of features as
they can specify adaptations to fine-grained building blocks
(classes, methods, attributes and statements). The depen-
dencies between the change objects provide the necessary
information to validate feature compositions. Specifying
features this way allows a bottom-up approach to do FOP.
References
[1] S. Apel, T. Leich, M. Rosenm
¨
uller, and G. Saake. Fea-
turec++: On the symbiosis of feature-oriented and aspect-
oriented programming. In R. Gl
¨
uck and M. R. Lowry, ed-
itors, GPCE, volume 3676 of Lecture Notes in Computer
Science, pages 125–140. Springer, 2005.
[2] D. Batory, L. Coglianese, M. Goodwin, and S. Shafer. Cre-
ating reference architectures: an example from avionics. In
SSR ’95: Proceedings of the 1995 Symposium on Software
reusability, pages 27–37, New York, NY, USA, 1995. ACM.
[3] D. Batory and S. O’Malley. The design and implementation
of hierarchical software systems with reusable components.
ACM Trans. Softw. Eng. Methodol., 1(4):355–398, 1992.
[4] D. Batory, J. N. Sarvela, and A. Rauschmayer. Scaling step-
wise refinement. In ICSE ’03: Proceedings of the 25th Inter-
national Conference on Software Engineering, pages 187–
197, Washington, DC, USA, 2003. IEEE Computer Society.
[5] D. Batory and J. Thomas. P2: A lightweight dbms generator.
Technical report, University of Texas at Austin, Austin, TX,
USA, 1995.
[6] D. S. Batory. A tutorial on feature oriented programming
and the ahead tool suite. In Generative and Transfor-
mational Techniques in Software Engineering, pages 3–35,
2006.
[7] L. Bergmans and M. Aks¸it. Composing crosscutting con-
cerns using composition filters. Comm. ACM, 44(10):51–57,
2001.
[8] A. Brown, R. Cardone, S. McDirmid, and C. Lin. Using
mixins to build flexible widgets. In G. Kiczales, editor,
Proc. 1st Int’ Conf. on Aspect-Oriented Software Develop-
ment (AOSD-2002), pages 76–85. ACM Press, 2002.
[9] M. Denker, T. G
ˆ
ırba, A. Lienhard, O. Nierstrasz, L. Renggli,
and P. Zumkehr. Encapsulating and exploiting change with
changeboxes. In ICDL ’07: Proceedings of the 2007 inter-
national conference on Dynamic languages, pages 25–49,
New York, NY, USA, 2007. ACM.
[10] E. W. Dijkstra. A discipline of programming. Prentice-Hall,
Englewood Cliffs, New Jersey, 1976.
[11] P. Ebraert, B. Depoortere, and T. D’Hondt. A meta-model
for expressing first-class changes. In T. Mens, K. Mens,
E. Van Paesschen, and M. D’Hondt, editors, Proceedings
of the Third International ERCIM Symposium on Software
Evolution, October 2007.
[12] P. Ebraert, J. Vallejos, P. Costanza, E. Van Paesschen, and
T. D’Hondt. Change-oriented software engineering. In
ICDL ’07: Proceedings of the 2007 international confer-
ence on Dynamic languages, pages 3–24, New York, NY,
USA, 2007. ACM.
[13] P. Ebraert, E. Van Paesschen, and T. D’Hondt. Change-
oriented round-trip engineering. Technical report, Vrije Uni-
versiteit Brussel, 2007.
[14] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda,
C. Lopes, J.-M. Loingtier, and J. Irwin. Aspect-oriented pro-
gramming. In M. Aks¸it and S. Matsuoka, editors, 11th Eu-
ropeen Conf. Object-Oriented Programming, volume 1241
of LNCS, pages 220–242. Springer Verlag, 1997.
[15] J. Liu, D. Batory, and C. Lengauer. Feature oriented refac-
toring of legacy applications. In ICSE ’06: Proceedings of
the 28th international conference on Software engineering,
pages 112–121, New York, NY, USA, 2006. ACM.
[16] K. Ostermann. Dynamically composable collaborations
with delegation layers. In ECOOP ’02: Proceedings of the
16th European Conference on Object-Oriented Program-
ming, pages 89–110, London, UK, 2002. Springer-Verlag.
[17] D. L. Parnas. On the criteria to be used in decomposing
systems into modules. Comm. ACM, 15(12):1053–1058, dec
1972.
[18] R. Robbes and M. Lanza. A change-based approach to soft-
ware evolution. Electronic Notes in Theoretical Computer
Science, pages 93–109, 2007.
[19] Y. Smaragdakis and D. Batory. Mixin layers: An object-
oriented implementation technique for refinements and
collaboration-based designs. ACM Transactions on Software
Engineering and Methodology, 11(2):215–255, 2002.
[20] S. Tichelaar. Modeling Object-Oriented Software for Re-
verse Engineering and Refactoring. PhD thesis, University
of Bern, 2001.
Citations
More filters

Journal ArticleDOI
TL;DR: This work raises awareness of the absence of a well-defined access control model for FOP, proposes three feature-oriented access modifiers, and offers an implementation of the model on the basis of a fully-fledged feature- oriented compiler.
Abstract: In feature-oriented programming (FOP) a programmer decomposes a program in terms of features. Ideally, features are implemented modularly so that they can be developed in isolation. Access control mechanisms in the form of access or visibility modifiers are an important ingredient to attain feature modularity as they allow programmers to hide and expose internal details of a module's implementation. But developers of contemporary feature-oriented languages have not considered access control mechanisms so far. The absence of a well-defined access control model for FOP breaks encapsulation of feature code and leads to unexpected program behaviors and inadvertent type errors. We raise awareness of this problem, propose three feature-oriented access modifiers, and present a corresponding access modifier model. We offer an implementation of the model on the basis of a fully-fledged feature-oriented compiler. Finally, by analyzing ten feature-oriented programs, we explore the potential of feature-oriented modifiers in FOP.

33 citations


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]....

    [...]


Proceedings ArticleDOI
13 Oct 2010-
TL;DR: A dashboard to support integrators getting an overview of proposed changes in the context of object-oriented programming and mixes text-based diff information with visual representation and metrics characterizing the changes is presented.
Abstract: Automatic and advanced merging algorithms help programmers to merge their modifications in main development repositories. However, there is little support to help release masters (integrators) to take decisions about the integration of published merged changes into the system release. Most of the time, the release master has to read all the changed code, check the diffs to build an idea of a change, and read unchanged code to understand the context of some changes. Such a task can be overwhelming. In this paper we present a dashboard to support integrators getting an overview of proposed changes in the context of object-oriented programming. Our approach named Torch characterizes changes based on structural information, authors and symbolic information. It mixes text-based diff information with visual representation and metrics characterizing the changes. We describe our experiment applying it to Pharo, a large open-source system, and report on the evaluation of our approach by release masters of several open-source projects.

27 citations


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 [13], [14]....

    [...]


Journal ArticleDOI
TL;DR: A visualization tool to support integrators of object-oriented programs in comprehending changes and an approach named Torch characterizes changes based on structural information, authors and symbolic information, which mixes text-based diff information with visual representation and metrics characterizing the changes.
Abstract: Revision Control Systems (e.g., SVN, Git, Mercurial) include automatic and advanced merging algorithms that help developers to merge their modifications with development repositories. While these systems can help to textually detect conflicts, they do not help to identify the semantic consequences of a change. Unfortunately, there is little support to help release masters (integrators) to take decisions about the integration of changes into the system release. Most of the time, the release master needs to read all the modified code, check the diffs to build an idea of a change, and dig for details from related unchanged code to understand the context and potential impact of some changes. As a result, such a task can be overwhelming. In this article we present a visualization tool to support integrators of object-oriented programs in comprehending changes. Our approach named Torch characterizes changes based on structural information, authors and symbolic information. It mixes text-based diff information with visual representation and metrics characterizing the changes. The current implementation of our approach analyses Smalltalk programs, and thus we describe our experiments applying it to Pharo, a large open-source system. We also report on the evaluations of our approach by release masters and developers of several open-source projects.

23 citations


Proceedings ArticleDOI
Quinten David Soetens1, Serge Demeyer1Institutions (1)
27 Mar 2012-
TL;DR: The tool prototype ChEOPSJ, which sits in the back of Eclipse and captures all changes made in the main editor while the developer is programming, and deduces which unit tests are relevant for a selected sequence of changes.
Abstract: Software is an ever-changing entity and frequently executed unit tests are the primary means to increase the confidence that the changed system continues to work as expected. Executing an entire test suite however can take a significant amount of time - much longer than developers are willing to wait before tackling the next change action. We demonstrate how our tool prototype ChEOPSJ may alleviate this problem by adopting a change-centric approach. Our tool sits in the back of Eclipse and captures all changes made in the main editor while the developer is programming. The changes and the dependencies between them are analyzed to deduce which unit tests are relevant for a selected sequence of changes.

20 citations


Journal ArticleDOI
TL;DR: A Systematic Mapping Study of 86 articles is presented to give an overview on the state of the art in this area of research and present a roadmap with open issues and future directions.
Abstract: Software must evolve to keep up with an ever-changing context, the real world. We discuss an emergent trend in software evolution research revolving around the central notion that drives evolution: Change. By reifying change, and by modelling it as a first-class entity, researchers can now analyse the complex phenomenon known as software evolution with an unprecedented degree of accuracy. We present a Systematic Mapping Study of 86 articles to give an overview on the state of the art in this area of research and present a roadmap with open issues and future directions.

16 citations


References
More filters

Journal ArticleDOI
Gregor Kiczales1Institutions (1)
TL;DR: This work proposes to use aspect-orientation to automate the calculation of statistics for database optimization and shows how nicely the update functionality can be modularized in an aspect and how easy it is to specify the exact places and the time when statistics updates should be performed to speed up complex queries.
Abstract: The performance of relational database applications often suffers. The reason is that query optimizers require accurate statistics about data in the database in order to provide optimal query execution plans. Unfortunately, the computation of these statistics must be initiated explicitly (e.g., within application code), and computing statistics takes some time. Moreover, it is not easy to decide when to update statistics of what tables in an application. A well-engineered solution requires adding source code usually in many places of an application. The issue of updating the statistics for database optimization is a crosscutting concern. Thus we propose to use aspect-orientation to automate the calculation. We show how nicely the update functionality can be modularized in an aspect and how easy it is to specify the exact places and the time when statistics updates should be performed to speed up complex queries. Due to the automatic nature, computation takes place on time for complex queries, only when necessary, and only for stale tables. The implementation language for the automated aspect-oriented statistics update concern is AspectJ, a well known and mature aspect-oriented programming language. The approach can however be implemented in any other aspect-oriented language. Unlike in traditional object-oriented pattern solutions, e.g. using the interceptor pattern, we do not have to modify existing code.

5,159 citations


Journal ArticleDOI
David Lorge Parnas1Institutions (1)
Abstract: This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decompositions are discussed. The unconventional decomposition, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.

4,962 citations


Book
01 Jan 1976-

4,654 citations


"First-Class Change Objects for Feat..." refers methods in this paper

  • ...Pioneering work on software modularity was made in the 70’s by Parnas [17] and Dijkstra [10]....

    [...]


Book ChapterDOI
Lodewijk Bergmans1, Cristina V. Lopes2Institutions (2)
14 Jun 1999-
TL;DR: An analysis of why certain design decisions have been so difficult to clearly capture in actual code is presented, and the basis for a new programming technique, called aspect-oriented programming, that makes it possible to clearly express programs involving such aspects.
Abstract: We have found many programming problems for which neither procedural nor object-oriented programming techniques are sufficient to clearly capture some of the important design decisions the program must implement. This forces the implementation of those design decisions to be scattered throughout the code, resulting in “tangled” code that is excessively difficult to develop and maintain. We present an analysis of why certain design decisions have been so difficult to clearly capture in actual code. We call the properties these decisions address aspects, and show that the reason they have been hard to capture is that they cross-cut the system's basic functionality. We present the basis for a new programming technique, called aspect-oriented programming, that makes it possible to clearly express programs involving such aspects, including appropriate isolation, composition and reuse of the aspect code. The discussion is rooted in systems we have built using aspect-oriented programming.

3,355 citations


Proceedings ArticleDOI
05 Jun 2000-

2,162 citations


"First-Class Change Objects for Feat..." refers background in this paper

  • ...Aspect-oriented programming (AOP) [14] is another implementation of that idea....

    [...]


Network Information
Related Papers (5)
Performance
Metrics
No. of citations received by the Paper in previous years
YearCitations
20211
20171
20152
20141
20132
20123