Washi.cs.waseda.ac.jp

Comparative Evaluation of Programming Paradigms: Separation of Concerns
with Object-, Aspect-, and Context-Oriented Programming
Fumiya Kato, Kazunori Sakamoto, Hironori Washizaki, and Yoshiaki Fukazawa Abstract
OOP, AOP, and COP and perform comparative experimen-tation on these paradigms to research their effectiveness of There are many programming paradigms for the sep- achieving SoC. To measure the effectiveness of achieving aration of concerns (SoC). Each paradigm modularizes SoC, we perform experimentation in terms of the descrip- tion amount and the locality of change. The purpose of this ming (COP) has been developed as a supplement to object- study is to answer the following research questions (RQs): oriented programming (OOP), which is one of the most RQ1: Do the description amount and the locality of
widely used paradigms for SoC. It modularizes concerns change differ in implementing programs with the
that are difficult for OOP. In this paper, we focus on three same requirement by OOP, AOP, and COP?
paradigms - OOP, aspect-oriented programming (proposed RQ2: Are there any situations in which COP is superior
as a supplement to OOP that has a different approach from or inferior to OOP and AOP in terms of the descrip-
COP), and COP - and study whether COP can modular- tion amount and the locality of change?
ize concerns better than other two paradigms in given sit- RQ3: What features of COP result in its superiority to
uations. Then we determine the reasons why COP can or OOP and AOP?
cannot better modularize concerns. RQ4: What features of COP result in its inferiority to
OOP and AOP?
The contributions of this paper are as follows: • Suggestion of the comparative evaluation scheme
1. INTRODUCTION
for programming paradigms.
• The comparative results of the superiority or infe-
In software development, the separation of concerns riority of OOP, AOP, and COP in terms of the de-
(SoC) is an important matter. To deal with SoC, numer- scription amount and the locality of change.
ous programming paradigms have been proposed. Object- • Specification of the causes of superiority and inferi-
oriented programming (OOP) is one of the most widely ority in the comparative results.
The rest of the paper is structured as follows. Section cutting concerns (CCCs) are difficult to modularize for 2 introduces the cross-cutting concerns that are difficult to OOP and are often scattered over modules in a program. As modularize by OOP, and how AOP and OOP modularize a supplement to OOP, aspect-oriented programming (AOP) such concerns. Section 3 presents the study format: the has been proposed. AOP modularizes CCCs as aspects that purpose of study, the method of comparative study, and the programming languages used. Section 4 shows the results In recent years, context-oriented programming (COP) of the study and our analysis. We discuss related works in has been proposed as a supplement to OOP that has a dif- Section 5 and summarize the paper in Section 6.
ferent approach from AOP. COP modularizes behavior thatdepends on the state of execution as layers. Several COP 2. BACKGROUND
languages have been developed [1, 2, 3] however, there has 2.1. Cross-Cutting Concerns
been little research on the situations COP is most effectivefor developing and how COP modularizes concerns better CCC is a type of concern that is entangled with other concerns. As the source code level, CCCs are often scat- In this paper, we focus on three programming paradigms: tered over modules in a program. For instance, logging to Figure 2. Modularization of CCC with layer
the layer is activated. Layers are activated by with state-ments. In addition, base definitions can be called from thedefinitions in a layer by proceed statements.
Figure 1. Cross-cutting concern of logging
3. COMPARATIVE EVALUATION SCHEME
code in OOP (top) and modularization of CCC
of logging code in AOP (bottom)
Figure 3 shows the overview of the comparative evalu- ation. To detect situations in which COP is superior or in- carry out debugging is one CCC. As shown in the top of Fig- ferior to OOP and AOP, we performed comparative experi- ure 1, it is difficult to modularize CCCs by OOP. A logging mentation. In this paper, we created three sample programs code can be written in many modules in a program in OOP.
containing CCCs about changing behavior, implemented Such a situation worsens maintainability, because scattered them in three programming languages, and performed seven logging codes make programs unreadable, and causing mis- modification experimentation. In addition, we implemented takes in modifying or deleting logging codes.
some parts of open-source software (OSS) in Java with eachprogramming language. From the results of our implemen- 2.2. Aspect-Oriented Programming
tation, we discuss the superiority and inferiority of COP.
In the analysis of the results, we use two criteria: de- AOP has been proposed as a supplement to OOP. AOP scription amount and locality of change. For comparison of the locality of change, we created seven change tasks shows the modularization of CCCs about logging by AOP.
as follows: add classes related or unrelated to CCCs, add Aspects separate CCCs from the major concerns that each methods related or unrelated to CCCs, rename methods re- class modularizes by weaving CCC codes into other mod- lated or unrelated CCCs, and delete CCCs. We counted the ules. AOP has a pointcut-advice mechanism for achieving chunks of code that the change tasks forced to modify.
weaving. Advice defines the operation woven into other As programming languages for OOP, AOP, and COP, we modules. Pointcut defines the modules into which advice use Java, AspectJ [4, 5] , and JCop [1] respectively. As- is woven and the points - for instance, particular methods pectJ and JCop are implemented by extending Java. Thus, are executed or particular types of objects are accessed - at the forms of the fundamental descriptions of Java, AspectJ, and JCop are similar. Therefore, the results should be lessaffected by differences in the abstraction level and gram- 2.3. Context-Oriented Programming
mar of languages, and more affected by differences amongparadigm features.
COP has been proposed as a supplement to OOP via a different approach from AOP. COP can modularize CCCsabout changing behavior depending on the state of execu- 4. EVALUATION EXPERIMENTATION
tion as layers. A layer defines the methods in other classes.
Methods defined in a layer are executed in a particular state 4.1. Target
instead of the original method definitions. Figure 2 shows 4.1.1. Sample Programs
the modularization of CCCs about logging by COP. A layerdefines the methods in other classes with logging codes.
To compare OOP, AOP, and COP, we created three Method definitions with logging codes in a layer can be ex- sample programs that are based on the samples on the JCop ecuted instead of the base definitions in other classes when project page [6]: address book, bank account system, and Figure 4. Design of address book and addi-
tional design concern
Figure 3. Overview of the comparative evalu-
ation.
Figure 5. Output of address book: each op-
tion is switched independently
adigm). They contain CCCs about changing behavior of guideline can be used to recommend to developers the more several classes depending on the state of execution.
positive use of COP than of OOP. Then we performed a Figure 4 shows the design of the address book. As the comparative study of OSS in the Java that decorator pattern base behavior, the StandardRenderer class implementing a are applied. The OSS we used is JHotDraw 5.3 [7], a Java Renderer interface outputs the fields of a Person object. The GUI framework for graphics editor. We found four places CCCs about changing behavior enable renderer classes to decorator patterns are applied, and rewrote them in AspectJ switch the styles of output: to render a name with an ad- dress, to add HTML tags, and to decorate outputs by . As shown in Figure 5, each output option is 4.2. Evaluation Results
switched independently. As the description amount, thelines of code (LOC) to implement the program are counted.
The top of Figure 6 shows the LOC to implement sample As the change of locality, the seven change tasks defined programs in each programming language. In the three sam- in Section 3 are applied to the CCCs about output options.
ple programs, implementation in Java needs the most LOC, For instance, Add-Related-Class adds a new renderer class and implementation in JCop needs the least LOC.
so that output options can be set, and Add-Unrelated-Class Table 1 shows the change tasks and chunks of code that adds a new class unrelated to output options.
the tasks forced to change. In Add-Related-Method, Add- In the same way as the address book, bank account sys- Unrelated-Method, and Rename-Unrelated-Method, imple- tem has CCCs: logging and encryption of data. The BMI mentation in AspectJ and JCop need less change than in the calculator, which is a GUI application with a Qt Jambi case of OOP. In particular, in Add-Related-Method of the framework [8], also has CCCs: switching units of input and address book and bank account system, implementation in JCop needs less change than in the other languages. On theother hand, in Add-Related-Method, JCop has the largest Open-Source Software
We perform a comparative study of sample programs The modularization of CCCs about changing behavior in prior to the comparative study of OSS. The results and anal- sample programs is achieved using the decorator pattern in ysis of the samples, presented in a later section, indicate that Java, aspects in AspectJ, and layers in JCop.
a correspondence relation between layers in JCop and the The bottom of Figure 6 shows the LOC of implementa- decorator pattern - one of the GoF design patterns - in Java tion where the decorator pattern is applied in each program- exists. If JCop improves implementation in the decorator ming language. In three of the four cases, implementation pattern, we can propose the part of the programs the dec- in JCop needs the most LOC, and in the other case, it is orator pattern is applied as the COP usage guideline. The impossible for implementation in JCop to rewrite the codes Table 1. Seven change tasks and affected chunks of code.
indicates the number of times the
tasks, e.g. in Add-Related (Unrelated)-Class,
indicates the number of added classes (n > 0).
properly in appropriate situations would improve the soft-
ware quality from the viewpoint of the description amount
and the locality of change compared with that in the case of
using a single paradigm.
RQ2: Are there any situations in which COP has supe-
riority or inferiority to OOP and AOP in terms of the
description amount and the locality of change?
The comparative results of the sample programs shown in the top of Figure 6 indicate that situations in which COPis superior to OOP and AOP exist from the viewpoint of thedescription amount. On the other hand, the results for OSSshown in the bottom of Figure 6 indicate that situations inwhich COP is inferior to OOP and AOP exist.
The results shown in Table 1 indicate that situations in which COP is both superior and inferior to OOP and AOPexist from the viewpoint of the locality of change. The situ-ations in which COP is superior to OOP are the change tasksof Add-Unrelated-Method, Rename-Unrelated-Method, andDelete-Concerns. These change tasks affect COP in thesame way as AOP. In Add-Related-Class, COP is less af- Figure 6. LOC for sample program (top)
and OSS with the decorator pattern (bottom)
RQ3: What features of COP result in its superiority to
implementation in three programming lan-
OOP and AOP?
The situations in which COP is superior to other two paradigms can be classified under two types of descriptions: applied the decorator pattern without changing the funda- necessary for Java but unnecessary for AspectJ and JCop, mental structure of the program. Implementation in AspectJ and necessary for AspectJ but unnecessary for JCop.
can reduce LOC in two of the four cases, and in the other First, we discuss the former. As mentioned above, the cases LOC increases compared with that in OOP.
decorator pattern is applied in implementation in Java. Fig-ure 7 shows that the concerns about changing behavior 4.3. Discussion
are implemented as the Html class; such a class is called RQ1: Do the description amount and the locality of
decorator class. The Html class changes the behavior of change differ in implementing programs with the same
StandardRenderer class - such classes are called compo- requirement by OOP, AOP, and COP?
nent classes - through the field of a component class ob- The comparative result shown in Figure 6 indicates that ject. Therefore, decorator classes need descriptions that set the description amount differ in implementing programs and get component class objects. On the other hand, im- with the same requirement by OOP, AOP, and COP. The re- plementation in AspectJ or JCop does not need such de- sults shown in Table 1 indicate that the localities of change scriptions, because aspects and layers have mechanisms of also differ. Therefore, using the programming paradigms weaving codes that change behavior into other classes.
Figure 7. Part of address book program implemented in Java (left), AspectJ (center), and JCop (right).
Furthermore, a decorator class needs to implement the derer class is added. The TableRenderer class has meth- same interface with a component class in implementation ods that changes behavior the same as the StandardRenderer in Java. Therefore, a decorator class needs to define not class. This change task does not force an aspect to change only the methods that change behavior but also other meth- any codes, because the pointcut rendering in the Html as- ods unrelated to the concerns about changing behavior. On pect already defines the classes that are weaved codes as the other hand, aspects and layers do not need to define the subclasses of the Renderer interface. Such a definition is methods unrelated to the concerns about changing behav- ior, because if aspects or layers do not describe the methods On the other hand, Add-Related-Class forces layers to of other classes, the methods defined in each class are just describe redundant method definitions as shown in Figure called. For that reason, adding methods unrelated to the 8. An Html layer needs to describe almost the same method concerns about changing behavior does not force aspects or definitions that differ only in class path to weave into the layers to change any codes and only implementation in Java StandardRenderer and TableRenderer classes, because each need to change codes as shown in Figure 7.
method definition is bound on only one class. Therefore, Secondly, we present the later. Figure 7 shows the exam- situations in which COP is inferior to OOP and AOP exist.
ple. Adding a method that changes behavior forces decora- The main reasons why implementation in JCop needs tor classes, aspects, and layers to change codes. To adopt more LOC than that in other languages in OSS are the same the added method, aspects need to define advice - that is the as those for sample programs. A decorator class is often operation weaved into other classes - and the pointcut that applied to two or more component classes; therefore, im- defines the classes and timing advice is weaved for each ad- plementation in JCop needs redundant method definitions vice. Therefore, two chunks of code - pointcut and advice - such as in the example given in Figure 8.
are needed for each new method that changes behavior. On In addition, layers in JCop cannot define members that the other hand, the method definitions in layers are bound are not weaved into other classes. Therefore, in Java, if dec- to only classes weaved codes. The timing at which weaved orator classes define private members, layers cannot define codes are validated is bound to layers. Therefore, if the tim- such members. Thus, each class that is weaved code by lay- ing of validating weaved codes is common to the methods ers needs to define members that are accessed by only lay- defined in a layer, JCop defines it only once no matter how ers. For this reason, implementation in JCop makes codes many methods are defined in a layer. For these reasons, im- plementation in JCop needs less change in the Add-Related-Method than that in AspectJ.
4.4. Threats to Validity
RQ4: What features of COP result in its inferiority to
OOP and AOP?
The results and analysis are based on our implementa- The situations in which COP shows inferiority originate tion in each programming paradigm. Therefore, threats to from the change task Add-Related-Class in Table 1 and the internal validity exist, because the affect of the difference results of the decorator pattern in OSS shown in Figure 6.
in the developer on the comparative results is not discussed Figure 8 shows an example: part of the address book pro- in this paper. As future work, we will perform implementa- gram. In the change task Add-Related-Class, the TableRen- tion experimentation with several programmers to validate proposed. From the viewpoints of the description amountand the locality of change, we performed comparative stud-ies of OOP, AOP, and COP to detect situations in whichCOP achieves better SoC and determine the reason whyCOP can or cannot achieve better SoC. From these results,several avenues for future work exist.
The next step would be a comparative study with larger projects applying metrics used in prior works [11, 13]. Acomparative study focusing on multi-perspective analysiswould also be interesting, for instance, reusability, implicit-ness, ease of description, and learning cost. A second line ofwork would be to discuss and develop a COP language that Figure 8. Situation in which COP has infe-
improves the inferior situations detected in this research.
riority to OOP and AOP. Adding a new re-
lated class forces layers to describe redun-
dant method definitions that differ only in
References
class path.
[1] Appeltauer, M. et al. : Event-Specific Software Com- position in Context-Oriented Programming, SC 2010, the generality of the results and analysis discussed in this [2] Appeltauer, M. et al. : Context-oriented Programming with Java, 26th JSSST Annual Conference, 2009.
5. RELATED WORK
In recent years, many COP languages have been devel- Toolchain Integration for Context-Oriented Program- oped [9] including those for Java [1, 2, 3, 10]. These studies focused on specification of the languages and their perfor- [4] AspectJ, http://www.eclipse.org/aspectj/ mance of execution. However, these studies do not evaluate [5] Kiczales, G. et al. : An Overview of AspectJ, ECOOP how degree and what situations these languages can achieve SoC compared with other programming paradigms.
The prior works that have guided this study is given in [11, 12, 14, 15]. Figueiredo et. al [11] performed a quantitative study of AOP that investigated the efficacy of AOP to prolong design stability of software product lines.
This study focused upon a multi-perspective analysis in [9] Schippers, H. et al. : An Implementation Substrate terms of modularity, change propagation, and feature de- for Languages Composing Modularized Crosscutting pendency measured by metrics for concerns [13]. Kiczales Concerns, SAC’09, pp. 1944-1951, 2009.
and Mezini [14] performed comparative study of program- [10] Hirschfeld, R. et al. : Context-oriented Programming, ming paradigms, which dealt with procedure calls, pointcut- Journal of Object Technology, Vol. 7, No. 3, pp.125- advice, and annotation by the implementation of a sample program. The comparison was in terms of the locality and [11] Figueiredo, E. et al. : Evolving Software Product the implicitness. Hannemann and Kiczales [15] performed Lines with Aspects: An Empirical Study on Design study of improving design patterns by AOP, which showed Stability, ICSE’ 08, pp. 261-270, 2008.
a comparison of Java and AspectJ by implementation of [12] Soares, S. et al. : Implementing Distribution and Per- sample programs including design patterns. The compar- sistece Aspects with AspectJ, OOPSLA’02, pp. 174- ison was in terms of the modularity and the reusability.
Our study is inspired by these studies and focuses on COP.
[13] Figueiredo, E. et al. : On the Maintainability of We perform comparative studies in terms of the description Aspect-Oriented Software: A Concern-Oriented Mea- amount and the locality of change measured by basic met- surement Framework, CSMR 2008, pp. 183-192, 2008 rics such as LOC and chunks of code as a first step towardsthe evaluation of the efficacy of COP to deal with CCCs.
[14] Kiczales, G. and Mezini, M.: Separation of Concerns with Procedures, Annotations, Advice and Pointcuts, 6. CONCLUSIONS AND FUTURE WORK
[15] Hannemann, J. and Kiczales, G.: Design Pattern Im- As the programming paradigm that achieves SoC with a plementation in Java and AspectJ, OOPSLA’02, 2002.
different approach from existing paradigms, COP has been

Source: http://www.washi.cs.waseda.ac.jp/wp-content/uploads/2013/07/148-ComparativeEvaluationofProgrammingParadigmSeparationofConcernswithObject-Aspect-and-Context-OrientedProgramming.pdf