Mixing of Join Point Interfaces and Feature-Oriented Programming for Modular Software Product Line

Feature-oriented programming (FOP) and aspect-oriented programming (AOP) focus on to modularize incremental classes behavior and crosscutting concerns, respectively, for software evolution. So, these software development approaches represent advanced paradigms for a modular software product lines production. Thereby, a FOP and AOP symbiosis would permit reaching pros and cons of both approaches. FOP permits a modular reﬁnement of classes collaboration for software product lines (SPL), an adequate approach to represent named heterogeneous crosscutting concerns. FOP works on changes of diﬀerent functionality pieces for which to deﬁne join points is not a simple task. Similarly, AOP structurally modularizes in a reﬁned manner homogeneous crosscutting concerns. Since traditional AOP like AspectJ presents implicit dependencies and strong coupling between classes and aspects, and the Join Point Interface JPI approach solves these classic AOP issues, this article presents JPI Feature Modules for the FOP + JPI SPL components modularization, i.e., collaboration of classes, aspects, and join point interfaces along with their evolution, for a SPL transparent implementation in a FOP + JPI context. In addition, this article shows JPI Feature Modules of a case study to highlight mutual beneﬁts of FOP and JPI approaches for a modular SPL software conception.


INTRODUCTION
The separation of concerns principle [15] mentions that generating modular programs is one of the main goals of programming.In this context, for software modularity, Object-Oriented Programming OOP represents an evolution concerning structured programming because OOP encapsulates attributes and functions as members of classes, and defines information hiding rules to access class members.Nevertheless, OOP neither directly encapsulates features and productline architectures [3] [19], nor crosscutting concerns as independent modules [17] for an organized software evolution.
Software development paradigms like Feature-Oriented Programming FOP [18] and Aspect-Oriented Programming AOP [17] look for to solve OOP issues: • FOP modularizes collaboration of classes, named heterogeneous crosscutting concerns, i.e., by classes refining, FOP works on changes of different functionality pieces for which to define join points is not a simple task, as features, and permits the step-wise development of software product lines [3] [10].In addition, as [3] [4] [6] indicate, FOP well modularizes static crosscutting concerns -new fields, methods, classes, and interfaces definition.Nevertheless, [17] [6] remark that FOP lacks adequate crosscutting modularity for software evolution since software has to change and adapt to fit non-predictable modifications.Particularly, for an homogeneous crosscutting concerns, i.e., for features which represent the same behavior that appear in different places in the features-tree hierarchy, "FOP does not modularize elegantly homogeneous crosscutting concerns" [3] [4] [6].For dynamic crosscutting concerns, FOP supports only methods interception [7], i.e., in a class refinement, it is possible to call refined and non-refined methods.
• AOP, looking for a modular behavior of classes, defines oblivious advised classes and modularizes crosscutting concerns as aspects, i.e., orthogonal methods non-part of the advised classes nature [17]; so AOP solutions are able to respect the single responsibility OOP design principles [21].Furthermore, AOP can modularize advanced dynamic crosscutting concerns not only methods interception.For example, AOP like AspectJ [9] permits the use of cflow, if, execution pointcuts.As [3] [4] [6] indicate, AOP modularizes homogeneous crosscutting concerns as aspects, but the modularization of classes collaboration by aspects results in software complex to evolve since aspects do not reflect the structure of the refined feature and its cohesion [7].Moreover, AOP like AspectJ [9] solutions introduce implicit dependencies between aspects and classes.Hence, aspects do no respect the information hiding principle, so oblivious classes can experience non-expected behavior and properties changes, and by modifying the advised behavior of classes, aspects can be spurious and other non-effective can appear.So, in traditional AOP like AspectJ, aspects need clearly to know about advised classes before advising them, a great issue for independent development [13] [14] [16].
Since, main FOP and AOP work focus are different kinds of crosscutting concerns, thus, as [3] [5] [7] [18] argue, a symbiosis of FOP and AOP profit of each other to obtain modular software.Thus, looking for a FOP and traditional AOP like AspectJ symbiosis, regarding a collaboration-based design, [3] [8] propose Aspectual Feature Modules (AFM) to represent modular classes and aspects along with their association and evolution.Nonetheless, AFM preserves already mentioned classic AOP issues.So, given the FOP benefits to modularize SPL heterogeneous and static crosscutting concerns, as well as the JPI capability to respect OO principle and modularize dynamic and homogeneous crosscutting concerns [13] [14] [16], hence the main goals of this article are, 1st to present JPI Feature Modules JPI-FM to structurally model JPI + FOP solutions for classes and aspects collaboration and get associated benefits in the massive customized software production, and 2nd, apply JPI-FM on a simple graph to evaluate the obtainable modularity.This article gives more details and extends previous work of [20].Specifically, this article presents a detailed study of an application example in order to discuss and find main points behind this proposal.
The rest of this paper is organized as follows.The next section presents main motivation for our research of proposing a mixing of JPI and FOP.Afterwards, next section presents FOP and AOP approaches as well as their traditional symbiosis, and an application example.After it, a section defines our JPI-FM approach to model and highlights its benefits and cons by means of an application example and shows part of its code solution.Finally, a section presents conclusions and future research work.

MOTIVATION
As was indicated before, traditional like AspectJ AOP and FOP look for to solve some OOP issues for the modular software production.This section details some pros and cons of these programming methodologies.
1st, traditional AOP in general modularizes crosscutting concerns of program modules, i.e., in an OOP context, orthogonal methods over classes.For OOP and AOP, since classes are oblivious of aspects, some OOP design principles for modular programs are respected such as the open-close and single responsibility [21].Traditional AOP like AspectJ defines pointcut rules and advices to identify join points in program execution and, by implicit-invocation, aspects advise on these join points.Mainly, by the use of wildcards and pattern matching mechanisms, AOP permits refining multiple join points by only one declaration rule, i.e., AOP permits good modularization of homogeneous crosscutting concerns.In addition, since AOP provides mechanisms to advised programs based on their dynamic execution, AOP also permits good support of dynamic crosscutting concerns [3].
Since in traditional AOP like AspectJ, pointcut rules indicate textual references to advised code, changes on advised base code can generate spurious pointcut rules, i.e., non-effective aspects.Furthermore, for the mentioned dependency, aspects are usually non-reusable and unable for evolution.Conversely, base code can obliviously experience non-desirable changes by the aspect advices invasiveness, possibly breaking assumptions over advised and non-advised base code, i.e, advised code by aspects and related code [14].
Clearly, classic AOP like AspectJ languages violate the principle of information hiding [3] since an aspect may affect internals of other modules directly regardless privacy rules, possibly even breaking module interfaces.
Furthermore, as Bodden et al. [14] [13] and Inostroza et al. [16] indicate, for traditional AOP like AspectJ methodologies, the independent development is non-possible since aspects developer have to know all classes and their behavior to define pointcut rules and associated advices adequately, and changes on base code could demand applying changes on aspects as well.So, the independent development and evolution of base code and aspects is hugely compromised.Figure 1 [14] illustrates implicit dependencies of aspects and advised classes of a classic AOP solutions.
For a strong aspects and base code decoupling, Bodden et al. [14] [13] and Inostroza et al. [16] propose a new AOP methodology to define join point interfaces JPI between aspects and advised classes for their decoupling.In addition, JPI permits respecting the information hiding principle since aspects access received values from classes methods which exhibit those aspects.Figure 2 [14] shows, for JPI solutions, a join point interface between aspects and advised code.Thus, the main goals of this research are to analyze, propose, implement, and evaluate pros and cons of a symbiosis of JPI and a Java style FOP language to reach modular software.

COLLABORATION-BASE DESIGN
To represent features variation for SPL, FOP uses Feature Models FM [3] [11].So, a FM displays all possible products of a SPL; but, traditionally, in a SPL context, as a conceptual model, a FM only presents composition, requires, or exclude features associations and does not show components structure.As Apel et al. [3] mention, collaborationbased diagrams are adequate to represent SPL hierarchical decomposition of classes structure and their collaboration associations.
Figure 3 [3] presents the feature model of a simple graph system, and Figure 4 [3] shows its classes, associations, and their evolution as a collaboration-based design.
Figure 5 [3] shows the code in Jak, a feature-oriented programming language.Feature Colored presents homogeneous crosscutting concerns, the highlighted repeated code; thus, in an AOP view, a more adequate solution should represent those crosscutting concerns as aspects.
As [3] [8] indicate, by means of an aspect-oriented instead of a FOP solution for features modularization, since aspects can merge different actions and behavioral roles, AOP solutions also can flatten inherent object-oriented structure of features.Thus, a mix of FOP and AOP seems more adequate because it would permit modularizing heterogeneous and homogeneous crosscutting concerns.Figure 6 [3] presents an AFM for the graph example in which heterogeneous crosscutting concerns continue being handled by a FOP solution meanwhile homogeneous crosscutting concerns, in this example, associated to a colored graph, are represented by a classic AOP solution.Figure 7 [3] presents AspectJ code for the aspect Colored.
Even though, FOP and classic AOP like AspectJ symbiosis solutions take into account modularization advantages of both paradigms, AFM retains issues of the last one.Thus, our JPI-FM should produce cleaner modular solutions.

JPI FEATURE MODULES: JPI-FM
Given the FOP and JPI benefits, this paper proposes JPI-FM looking for the symbiosis of both paradigms: 1st, FOP, for software evolution, for collaboration of classes and new elements of the system, heterogeneous and static crosscutting concerns; 2nd, JPI, to avoid code replication and adequately represent homogeneous and dynamic program behavior in terms of execution paths, dynamic homogeneous crosscutting concerns, and to respect information hiding and single responsibility OOP design principles.
Figure 8 illustrates an application of our JPI-FM proposal  for a system that presents a base layer and two layers of refinement: • Base layer (Layer 1) presents a set of N classes, a set of M join point interfaces, and a set of M aspects, i.e., Class1,..., ClassN ; jpi Interf ace1(< args >), ..., jpi Interf aceM (< args >); aspect Aspect1, ..., aspect AspectM respectively.Note that JPI units are exhibited by classes and implemented by aspects, and aspects, like in traditional AOP like AspectJ present before, around, and after advices.Clearly, our modeling proposal stereotyped classes to identify JPI elements.In addition, our model tries to be consistent with JPI ideas [14]; hence, each class that exhibits a join point interface also defines a pointcut PC rule to identify join point occurrences, and aspects implement those jpi interfaces.
• Layer 2 presents the refinement of previous layer ele-  It is important to know that, for the product lines definition, classes of a layer or of previous layers can exhibit a join point interface JPI.Note that our proposal only considers join point interfaces definition between classes and aspects.As part of a current research project, additional characteristics of FOP and JPI are going to be added to our proposal.Next, Figure 9 illustrates an application of JPI-FM on the graph example, and Figure 10 shows part of the associated code for layers Weighted and Colored, specifically for class Edge, and aspect Colored along with JPIColored respectively.Note that class Edge of layer Weighted is a class refinement of itself from layer Basic Graph which exhibits the JPI JPIColored for the execution of its method print(), and aspect Colored implements JPIColored before.Thus, clearly our proposal mixes JPI and FOP nature for the SPL development.

CONCLUSIONS
JPI-FM continues using FOP main properties to produce massive customized software applications presenting modularization advantages for SPL respecting AFM since JPI exhibits notable modularization improvements over classic AOP.Thus, JPI-FM models a high-level massive modular software in a FOP-JPI symbiosis context.Exactly, to produce a complete FOP and JPI symbiosis is our future main goal.In this context JPI-FM has to support a symbiosis of FOP and closure join points [12].
In addition, to evaluate JPI-FM modularization pros and cons regarding its source FOP and JPI approaches, we want to define a case study to apply our whole SPL development proposal.

Figure 1 :Figure 2 :Figure 3 :Figure 4 :Figure 5 :
Figure 1: Implicit Dependencies of Advised Base Code and Aspects of Classic AOP Solutions

Figure 6 :Figure 7 :
Figure 6: AFM of a graph example

Figure 9 :
Figure 9: JPI-FM of the graph example

Figure 10 :
Figure 10: JPI-FM code for the graph example