Aspect and Subject Oriented Programming Paradigms

Conférence CISC’14, Jijel, du 09 au 10 Décembre 2014 -P24

Aspect and Subject Oriented Programming Paradigms: A Comparative Study Meriem Chibani Research Laboratory on Computer Science's Complex Systems ReLa(CS)2 University of Oum El Bouaghi Po. Box 358, 04000 Oum El Bouaghi Algeria [email protected]

Brahim Belattar Department of Computer Science, University of Batna, Batna, 5000, Algeria [email protected]

Abstract The object-oriented software suffers from code tangling and code scattering problems leading to weak code reusability and difficult application evolution. New approaches supporting an advanced separation of concerns (ASoC) are proposed to overcome this dilemma. These latter provide a more powerful constructs for software decomposition than the object-oriented paradigm and their comparison is increasingly considered as an important issue. This paper is dedicated to the comparison and the assessment of two samples of ASoC approaches: aspect-oriented programming (AOP) and subjectoriented programming (SOP).

1. Introduction Object-oriented software design suffers from code tangling and code scattering problems. Tangling occurs when multiple concerns are addressed in a single module. Then, scattering results occur when the implementation of a concern is spread over multiple modules. These both problems affect software quality attributes leading to bad traceability, lack productivity, weak code reusability and difficult application evolution. To avoid these problems, several techniques are being researched that attempt to increase the expressiveness of the OO paradigm. Such techniques are known as advanced separation of concerns (ASoC).

Abdelhabib Bourouis Research Laboratory on Computer Science's Complex Systems ReLa(CS)2 University of Oum El Bouaghi Po. Box 358, 04000 Oum El Bouaghi Algeria [email protected]

They provide a more powerful constructs for software decomposition than the object-oriented paradigm in order to realize a better separation of concerns, i.e. the separation of concern (SOC) principle. Xerox aspect-oriented programming (AOP) [1], subject-oriented programming (SOP) [2], composition filters (CF), adaptive programming, and multi-dimensional separation of concerns. All these approaches aim to providing better concepts and mechanisms to make sure that different concerns are represented in modular way. Unfortunately, their philosophies are different from others and their concepts used are not similar. In front of this diversity, software community hopes to unify concerns modularization and increase software reuse, evolution and maintainability in a standard manner [3]. In order to contribute for achieving this goal a comparative study has been undertaken, in this paper. AOP and SOP are the used approaches in this comparison. The rest of this paper is organized into five sections. Section 2 and 3 describe the main concepts of AOP and SOP approaches. Section 4 presents the comparison. Section 5 discusses related work and finally a conclusion is presented in section 6.

2. Aspect-oriented programming 2.1. Principe and goals The aspect-oriented programming paradigm is a newly introduced methodology for software

Conférence CISC’14, Jijel, du 09 au 10 Décembre 2014 -P24

development. It could be seen as a complementary technique that co-exists with other approaches such as object-oriented, procedural, functional and eventdriven programming [4]. Cristina Lopes and Gregor Kiczales of the Palo Alto Research Center (PARC), a subsidiary of Xerox Corporation, are among the early contributors to AOP. Gregor coined the term “AOP” in 1996. There are several implementations of AOP like AspectC for C, AspectS for smaltalk, AspectC# for C# and Pythius for Python. Moreover, there are others implementations of AOP for java language such as AspectJ, Caesar, Jiazzi, JBossAOP, AspectWerkz and JasCo [5]. This approach considers that the code of a given software system contains a base code, i.e., functional concerns and a non-functional part. The functional code consists of objects that achieve functionalities of the system, whereas non-functional concerns are made of code that crosscut functionalities like transaction management, logging and synchronization. In the object-oriented paradigm, concerns are scattered throughout the source code, consequently a tangling arises [1]. AOP provides independent specifications for each crosscutting concern and functionality, and then weave them together to build the resulting system. It is appropriate for a wide range of applications because of crosscutting concerns as security, synchronization, transactions management, distribution, logging are separated from the system base code. It presents undeniable advantages in all applications as following [5]: 2.1.1. Simplified design. The architect of a system is often faced with underdesign/overdesign issues. In the case of underdesign, considerable changes may be needful later in the development cycle. On the other case of overdesign, the implementation may be burdened with code of questionable usefulness. With AOP, design decisions are possible for future requirements because of aspects are implemented separately. AOP harmonizes with one of most of popular trends of agile programming by supporting the practice of “You aren’t gonna need it” (YAGNI). Implementing a feature requirement just because it is needful in the future often results in wasted effort. This principle focuses just on the current requirements of the system. With AOP features may be added incrementally through the introduction of aspects, often without modifying the rest of the code. 2.1.2. Cleaner implementation. AOP allows a module to take responsibility only for its core concern. A module is no longer liable for other crosscutting concerns. For example, a module implementing business logic is no longer responsible

for the security functionality. These results in cleaner assignments of responsibilities, reduced code clutter, and less duplication. It also improves the traceability of requirements to their implementation. Reduced code tangling makes it simpler to test code, spot potential problems, and perform code reviews. Reviewing the code of a module that implements only one concern requires the participation of an expert in the functionality implemented by that module. Such a simplified process leads to higher-quality code. Reduced code scattering avoids the cost of modifying many modules to implement a crosscutting concern. Thus, AOP makes it cheaper to implement a crosscutting feature. The end effect is a cheaper overall feature implementation, better time-to-market, and easier system evolution. 2.1.3. Better code reuse. The key to greater code reuse is a more loosely coupled implementation. If a module is implementing multiple concerns, other systems requiring similar functionality may not be able to use the module if they implement a different set of crosscutting concerns. In AOP system, each crosscutting module is implemented as an aspect, core modules are not aware of crosscutting functionality. By modifying the aspects, the system configuration may be changed. For example, a service layer may be secured in a project with one security scheme, in another project with another scheme, or in still another project with no security at all by including or excluding appropriate aspects. Without AOP, a service layer tied with a specific security implementation may not be reused in another project.

2.2. Basic Concepts The process of developing a system using AOP contains three phases as shown in Figure1 [5]: • Aspectual decomposition: it decomposes the functional core from crosscutting concerns. • Concern implementation: it implements functional concerns by using procedural or OOP language. In addition to that, an AOP language as AspectJ is used for implementing each crosscutting concern independently. • Aspectual recomposition: it specifies the recomposition using an aspect weaver. This latter takes the implementation of the core and crosscutting concerns and weaves them together to form the final system.

Conférence CISC’14, Jijel, du 09 au 10 Décembre 2014 -P24

Figure 1. An AOP system that provides a weaver in the form of a compiler [5]. To implement crosscutting concerns, an AOP system may include many of the following concepts [5]: 1. Identifiable points in the execution of the system: the system exposes points during the execution of the system. These may include execution of methods, creation of objects, or throwing of exceptions. Such identifiable points in the system are called join points. 2. A construct for selecting join points: Implementing a crosscutting concern requires selecting a specific set of joinpoints. The pointcut construct selects any join point that satisfies the criteria. This is similar to a SQL query selecting rows in database. A pointcut may use another pointcut to form a complex selection. Pointcuts also collect context at the selected points. For example, a pointcut may collect method arguments as context. The concept of join points and the pointcut construct together form an AOP system’s join point model. 3. A construct to alter program behavior: After a pointcut selects join points, an additional or alternative behavior must augment those join points. The advice construct in AOP provides a facility to do so. An advice adds behavior before, after, or around the selected join points. Before advice executes before the join point, whereas after advice executes after it. Around advice surrounds the join point execution and may execute it zero or more times. Advice is a form of dynamic crosscutting because it affects the execution of the system. 4. Constructs to alter static structure of the system: Some times, to implement crosscutting functionality effectively, altering the static structure of the system is necessary. For example, when implementing tracing aspect, the

5.

implementation of logger field into each traced class is needful; inter-type declaration constructs make such modifications possible. In some situations, to detect certain conditions, typically the existence of particular joinpoints, before the execution of the system; weave-time declaration constructs allow such possibilities. Collectively, all these mechanisms are referred to as static crosscutting, given their effect on the static structure, as opposed to dynamic behavior changes to the execution of the system. A module to express all crosscutting constructs: Because the end goal of AOP is to have a module that embeds crosscutting logic. The aspect construct provides this capability. An aspect contains pointcuts, advice, and static crosscutting constructs. Moreover, it may be related to other aspects.

3. Subject-oriented programming 3.1. Principe and goals Subject-oriented programming paradigm was introduced in 1993 at IBM Thomas J. Watson Research Center. It is an extension of the objectoriented programming paradigm that considers systems as a set of subjects with different subjective views. Although subjects are standalone running components of the software, working independently of each other, they are not comp letely isolated [6]. In the subject-oriented programming paradigm various forms of interactions may occur between subjects [7]: ü a request for function or state change to be supplied by another subject. ü performance of an activity in which another subject might participate. ü notification of an occurrence which may be of interest to another subject. ü use of subject's behavior as part of the "larger" behavior of another; ü sharing of state. Multiple subjects may be composed to produce a complete suite of applications. Neither source code access nor recompilation is required to perform composition. Each subject is compiled separately to produce a binary subject that consists of a label providing information about it, and binary code produced by the compiler. Then, the subject-oriented compositor uses information in the labels to tie the subjects together as shown in Figure 2, without any

Conférence CISC’14, Jijel, du 09 au 10 Décembre 2014 -P24

modification of the individual subjects' binary code [2].

subject 2

Subject compiler

Binary code S2

SO compositor

Binary code Sn

subject n

Subsidiary subject

Binary code S1

subject 1

Subject-oriented programming paradigm adds several new concepts to an object-oriented program: (i) subjects, (ii) label and (iii) composition rules. i. Subject. It is an object-oriented program or program fragment that models its domain in its own subjective way. A subject is written in an object-oriented source language and compiled using a subject compiler for that language. The result is a binary subject. This latter consists of binary code including the compiled method bodies and a label. ii. Label. It specifies the class hierarchy that describes the subject’s view of the world without any code. Information in a subject label includes classes, operations, methods mapping and aliases declarations. The classes are defined and/or used by the subject with their instance variables. The operations are generic functions that are defined and/or used by the subject. The methods mapping that map the operation and class pairs to sets of method bodies. Finally, a set of aliases that specify the relationship between the names used in the label and symbols referring to classes and operations defined in the label binary code. iii. Composition Rules. The SOP language is an extensible collection of composition rules. Applied to a collection of input subjects the composition rules cause an output subject to be created. Composition takes place statically, before the program is run. Each input subject realizes some concern by defining a set of classes, field, variables and operations whose execution will produce the desired behavior. The output subject also is a set of classes, field variables and operations. The behavior of the output subject depends on the input behaviors and the semantics of the composition rules used in its creation. In the following, Table1, represents a rules, defined informally, using set notation, or as instantiations of more general rules is provided [10].

L A B E L

Figure 2. Subjects composition. This paradigm provides suitable solutions for many problems in object-oriented software development such as [8]: • Developing large systems. These suites of interoperating or integrated applications evolve in unplanned ways without changing or recompiling existing source code. • Decentralized development. Multiple teams of different applications that share objects may use different views of shared classes separately and these subjective views may later be composed. This prevents developers from working simultaneously on overlapping parts of the same classes. • Application and composition of design patterns. In SOP, design patterns implementation code could be separated from the code to which they apply. Next to this, new programming capabilities are added as non-invasive addition of patterns at any time and the description of pattern interactions using composition rules. • System decomposition according to requirement-based or feature-based development. The code that implements a requirement or feature can be built as a coherent subject, rather than being interleaved amongst other code in a way that makes it hard to identify and maintain. One of the main strength points of the SOP is its distributed characteristics advantages as code reuse, location transparency, migration transparency, concurrency transparency, security, and scalability over the object-oriented paradigm in distributed environment [9].

4. Comparing SOP and AOP Starting from the over mention description of the two approaches. A common pointes and differences between SOP and AOP approaches are concluded as follows:

3.2. Basic concepts

4.1. Similarities

•

Both approaches have a common goal to solve problems in software development relating to

Conférence CISC’14, Jijel, du 09 au 10 Décembre 2014 -P24

•

prevent scattering and tangling code, and in cleanly dividing system into separate modules to achieve the separation of concern (SOC) principle.

In the both methodologies, the system passes under the same life cycle. First, the decomposition of the system into several modules (according to the realization of the SOC principle. Then, the use of several mechanisms to compose system modules.

Table 1. SOP composition rules library based on [11]. The Composition Rule name

Formula

Operation Composition

compose [Cg](n,q) (signatures(q))”}

Correspondence

equate[R](n, q) = R(n, q) U {“qi —> n”| 1= i = length(q)}

Instance Variable Composition

{“

n

Comments =

operation

composev [Gt] (n, q) = {“n = ivar of Ct(types(q))”}

Class Composition

compose0c [Sv](n, q) ={“n= class”} U instvars(q))

Set Rules

Sname [R](n, Q) =

Cg

type

Sv (n,

U R(n. x, 〈 x , x ,..., x 〉 ) 1

2

k

q: operation declarations. Cg: specifies the combinator to be used for combining signatures. n: is the name of the result operation. R: specifies any rule. n: is the name of the result. q: the input sequence types(q)): denotes the sequence of types from the instance variable declarations. q: the instance variable declarations. Gt: specifies the combinator to be used for combining types. This generic rule takes as generic parameter a subrule that specifies how to compose the instance variables. The formula of most common set rule name matching.

x

Class Merge

Class Override

Realization Composition

Set

Mapping Composition

merge c = equate[compose0c [Sname [ equate[composev [equivalent]]]]]

It insists on corresponding instance variables having equivalent types

overridec = equate[compose0c [Sname [ equate[composev [first]]]]]

It allows the type declared in the first class to override the others.

compose0r [Cu, Sr, Ro] (n, q) = {“n =rsef returning Cu (rvspecs(q))”} U Sr (n, realizations(q)) U Ro( n, q)

It uses the combinator Cu to combine return value specifiers; the set rule Sr to compose the sets of realizations; and the ordering rule Ro to specify cross-subject ordering constraints. The result of Ro is a set of after clauses referring to realizations within realization set n. A mapping is a collection of realization sets. Thus, composing mappings involves composing appropriate realization sets.

composee (r) =

Relationship Clause Composition

Label Composition

“C(n l ) after C(n 2 )"  if r =" n 1after n 2 "   ‘ i alias C(n)”  if r =" i alias n" compos0l [So, Sc , Sm ](n, q) = So(n, operations(q)) U Sc (n, classes(q)) U Sm (n, realizationsets(q) U {composee (r) | r ∈ I is a relationship clause}

This relationship rule takes just a single clause as parameter.

This rule takes as generic parameter the subrules that specify composition of the operations, classes and mapping.

Conférence CISC’14, Jijel, du 09 au 10 Décembre 2014 -P24

Merge

merge 1 = composel [Sname , equivalent, Sname , Sname , equivalent, make-equal, Sname , random]

Override

overridel = composel[Sname , first, Sname , Sname , first, first, Sfirst, random]

4.2. Differences •

•

In SOP, a system comprises a number of modules (subjects) that may be equal. Subjects may contain functional or nonfunctional concerns. On the other side, in AOP, a system under development comprises the base code (functional module) and a number of aspects that contain non-functional code. AOP is based on the centralization principle. In SOP, the information about the constructs which are involved with composition; and how these latter should be combined are specified outside subjects. They are separated into an independent file in the form of composition rules. Next to this, in AOP, the places of the crosscutting concerns injections

are specified inside aspects themselves grace to pointcuts mechanism and advice modifiers as shown in Figure 3.

They defined in terms of generic label rules. These rules form the basis of almost every composition expression.

A system in SOP approach corresponds to a set of subjects and composition rules to compose them. Let SU be a SOP system: SU= 〈 S, C 〉 S: is a set of subjects each one represents a subsystem of SU. C: composition rules that used for combining subjects. If we restrict SU to only one system, S set becomes the functional and the non-functional requirements of this latter. The counterpart of SU in AOP is 〈 A, F 〉 where: A: a set of aspects that represent the non-functional part. F: represents a set of classes they implement the functional part of a system. The mapping is S= A U F. C is translated to advices and pointcuts that may be added to aspects code, A. Moreover, advices code must be omitted from functional code, F. Generally, the mapping from SOP to AOP is possible only if SOP represents one application. This means that AOP is a particular case of SOP. The following table presents the summary of our mapping model of the two approaches based in their main concepts. Table 2. Mapping model used to the assessment of AOP and SOP

Figure3. Composition mechanism in AOP and SOP [12].

4.3. The Concepts Mapping The idea behind the mapping consists of answering to the question: For each given specification of one of the approaches, what is the corresponding specification in the other? In our work, we try to

identify the correspondence between both AOP and SOP approaches.

Xerox PARC AOP Aspect

SOP Subject

Functional code Weaving mechanism

Subject Composition rules

Pointcuts specification Join points

Labels specification Subject parts

5. Related work Because AOP and SOP are new paradigms, compared to OOP, and since they are continually evolving, only a limited amount of research work is dedicated to the assessment and comparison of them. In the following, a brief description of most of interesting existing works: In [13], a comparison between AOP and related object-oriented approaches as SOP, role, Crome and split objects techniques is performed. The author

Conférence CISC’14, Jijel, du 09 au 10 Décembre 2014 -P24

pointed out the common principle between these approaches which is the separation of crosscutting concerns. On one hand, in the AOP terminology, the crosscutting members are aspects and components; the interaction points are join points. On the other hand, in the SOP paradigm, the modular units are subjects and objects; the interaction points are parts of description in subjects. In this study, the difference between AOP and the other approaches is skipped. In addition to that join points in AOP are parts of components. So, the concepts mapping between AOP and SOP is wrong. In [14], a survey of recent software development programming paradigms as aspect-oriented programming and generative programming is discussed to attempt of finding the best paradigm. The authors considered SOP, Xerox Parc AOP, composition filters, and adaptive programming as aspect-oriented programming approaches without any explication. Moreover, they presented a simple tracking access example to demonstrate the mapping between AOP and SOP. In [15], a brief look at the programming methods is presented. The AOP separates non functional concerns unlike SOP separates both functional and non functional requirements. This is the only mentioned point. In [16], the authors clarified two central common concepts between AOP and SOP. The first one is correspondence which specifies constructs that could be used as reference points for the composition process. Next to this, unification is the process by which corresponding constructs are combined. In this position paper, a formal composition model for both AOP and SOP is proposed. In [17], the authors used a case study to compare three methods: AOP, SOP and view-oriented programming. The case study consists of taking a sample application, and submitting it to two maintenance scenarios, one adding a functional requirement, and the second, consisting of adding a new architectural requirement, namely, distributing (or “remoting”) some objects. In [12], the authors have revealed insights into the similarities and differences between SOP and AOP in terms of their assumptions about the software development process through an experiment study. The experiments performed in this study use only toy programs and they could not give insight into the issues that may arise when the approaches tools are deployed in real development projects. Next to this, the Watson Subject Compiler (WSC) and AspectJ tools give some idea of benefits that may be achieved by adopting these approaches but they do not support all features of their respective techniques.

Most of the previous mentioned works are not complete in the form of glances. They take several ASOC approaches without sufficient details adopting practical use. In the same time, this type of research work is necessary to guide the evolution of the two approaches towards promising issues. Thus, our work clarifies the main concepts of AOP and SOP. Besides that, it provides the relation and the differences between the both technologies.

6. Conclusion and perspectives This paper discusses AOP and SOP progra mming paradigms. It clarifies their base concepts, their similarities, differences, and concepts mapping. The conclusion derived from this comparison shows that each approach does not constitute a ‘killer application’ for the other, neither subsumes the other. On one hand, differences preclude a straight forward and one-to-one mapping. In the same time, this differences let to each approach the possibly to pick the nice ideas from the other to overcome its drawbacks. Subject-oriented programming, for instance, has nice ideas, but it has not a wide spread. On the other side, AOP has now reached a certain maturity and a lot of developers and programmers are using it. On the other hand, similarities are the initial seeds to the emergence of a unified concern modeling approach. Moreover, a comparison between other advanced separation of concerns approaches such as composition filters and adaptive programming is considered one of our interests.

References [1] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Videira Lopes, J-M, Loingtier, J. Irwin, “Aspect-Oriented Programming”, in Proc. Of ECOOP’97, Lecture Notes in Computer Science vol. 1241, 1997, pp. 220–242. [2] H. Ossher, W. Harrison, F. Budinsky, and I. Simmonds, “Subject-oriented programming: Supporting decentralized development of objects”, in Proceedings of the 7th IBM Conference on Object-Oriented Technology, Santa Clara, CA, 1994, pp.1-13. [3] D. Walker, S. Zdancewic, and J. Ligatti, J, “A theory of aspects”, in Proceedings of the eighth ACM SIGPLAN international conference on Functional programming, Volume 38 Issue 9, August 2003, pp. 127-139. [4] L. Gulyás, and T.Kozsik, “The use of aspect-oriented programming in scientific simulations”, in: Jaan Penjam, editor, Software Technology, Fenno-Ugric Symposium (FUSST'99), Tallinn, Estonia, 1999, pp. 17-28.

Conférence CISC’14, Jijel, du 09 au 10 Décembre 2014 -P24

[5] R. Laddad, Aspectj in Action: Enterprise AOP with Spring Applications, Manning Publications, Second Edition, 2009. [6] W. Harrison and H. Ossher, “Subject-oriented programming (a critique of pure objects)”, in Proceedings of the Conference on Object- Oriented Programming: Systems, Languages, and Applications, Washington, D.C., September 1993, pp. 411-428. [7] A. Balogh, and Z. Csörnyei, "SUBJECT-ORIENTED OPERATING SYSTEM DEVELOPMENT BASED ON SYSTEM PREDICATE CLASSES",Annales Univ. Sci. Budapest., Sect. Comp. 30 (2009), pp. 117-139 [8] W. Harrison, and P. Tarr, “Using Subject-Oriented Programming to Overcome Common Problems in ObjectOriented Software Development/Evolution”, ICSE '99 Proceedings of the 21st international conference on Software engineering, 1999, pp. 687-688. [9] David L., Mcreynolds, Sheryl L. Duggins, Doreen L. Galli, and John H. Mayer, “Distributed characteristics of subject oriented programming: An evaluation with the process and object paradigms”, in Proceedings of the 37th annual Southeast regional conference (CD-ROM), ACM, 1999, p. 19. [10] A. Batenin, “Subjectivity and ownership: A perspective on software reuse”, Technical Report, Department of Computer Science, University of Bath, ISSN 1740-9497, December 2006. [11] H. Ossher, M. Kaplan, A. Katz, W. Harrison, and V. Kruskal, “Subject-Oriented Composition Rules”. OOPSLA ‘95 Austin, TX, USA. TAPOS, 2(3), 1995, pp. 235-250. [12] M. Skipper, “The Watson Subject Compiler & AspectJ (A Critique of Practical Objects”, in Workshop on Multi-Dimensional Separation of Concerns at OOPSLA, 1999. [13] D. Bardou, “Roles, Subjects and Aspects: How do they relate?”, proceedings of the aspect-oriented programming workshop at ecoop’98, 1998, pp. 8-15. [14] V. Vranie, “Towards Multi-Paradigm Software Development”, Journal of Computing and Information Technology - CIT 10, 2002, 2, pp. 133-147. [15] K.R. Christiansen, and N. Oost, “A look at Programming Methods for solving problems of current Software Development”, in the proceedings for StudColl. University of Groningen, 2005, p.67. [16] M. Skipper, and S. Drossopoulou, “Formalising Composition-Oriented Programming”, ECOOP Workshops, volume 1743 of Lecture Notes in Computer Science, Springer, 1999, pp. 307-308. [17] H. Mcheick, H. Mili, A. El-Kharraz, and S.A. Sadou, “comparaison of Aspect-Oriented software development techniques for distributed applications”,

Proceedings of International Conference Applied Computing. San Sebastian, Spain, IADIS Press, Feb. 2528, 2006, pp. 324-333.