CHAPTER 1
This chapter describes introduction of thesis which is about to enhance efficiency by implementing GOF design patterns in aspect oriented technology. Section 1.1 describes the need of enhancement of design patterns in aspect oriented technology. Section 1.2 highlights the issues which are need to be resolved. Section 1.3 discusses the problems and Section 1.4 presents what approach is presented towards a solution. Section 1.5 gives detail of work flow of entire plan used in this research and also discusses the details of stakeholders of this thesis.
Need for efficiency enhancement of deign patterns in aspect oriented technology
Design patterns perform a vital role in the field of software engineering. Design patterns are reusable solutions of recurring problems of software [Gamma et al., 1995]. Design patterns are not complete solutions but there can be addition or modification according to applications. Design patterns are in the form of template. In procedural and object oriented languages, design patterns are used at almost all software development life cycle i.e. requirements, design, detailed design, implementation and testing [Sherif M., 2003]. Design patterns describe the core of a solution.
There are different programming languages which are used to develop and implement systems in software engineering. Procedural languages and object oriented languages are used for development of systems. For automation of complex systems, rather than working on whole project at a time, designers divide the whole system into small modules and develop those modules independently. So complexity of those modules will be less than before [Deitel, 2002].
Modularity is becoming increasingly more important in the development of software. In procedural languages, focus will be on different functions of system. Object orientation gives modularity focuses on separation of code into real world objects [Deitel, 2002]. A program is in millions of line of code (LOC) so it is very difficult to handle its modularity. On the other hand, there is aspect oriented language which is extension of object oriented language. Aspect-orientation is an emerging approach to system design and implementation [ACM, 2001], [Kiczales et al., 1997]. It is used for modularity enhancement. It deals with crosscutting concerns. Concern is any particular concept in software. Crosscutting concern is a concern that spreads across more than one program abstractions [Kiczales, G.; et al.; 1997]. Crosscutting concern examples can be logging, performance, optimization, error handling etc. There is no concept to handle cross cutting concerns in procedural, structured and object oriented programming. If crosscutting concerns will not handle in different programming languages, results will be in the form of hard to understand, complex to maintain and difficult to reuse etc.
Mostly aspect oriented programming is used for large projects as in commercial applications. Applications of aspect oriented programming are middleware, operating system, fault tolerance, quality of service (QOS); secure applications in web based and distributed applications [Kiczales et al., 2002].
In this thesis, implementation of applications and design patterns in aspect oriented technology and focus is on enhancing the efficiency of design patterns in any application on the basis of separation of concerns, coupling, cohesion and reusability in aspect oriented technology. Then these applications or software's can be more modular, reusable and flexible.
Issues needed to be resolved
Design patterns can be implemented in any language. Lot of work has been done in design pattern. GOF design patterns particularly are used for object oriented languages in which classes and objects are used [Gamma et al., 1995]. There are three implementations of the real application: easy to understand but inefficient, efficient but difficult to understand, and an aspect oriented programming based implementation that is both easy to understand and efficient. AOP separates crosscutting concerns from program abstraction so that program will be cohesive, modular, reusable, simpler and easy to maintain. So implementation of design patterns gives more efficient and better results in aspect oriented languages i.e. AspectJ and CaesarJ. Aspect weaver compiler accepts the primary module and aspect programs as input, and emits a program as output. [Kiczales, G.; et al.; 1997]
Problem Statement of thesis
"Efficiency enhancement of aspect oriented technology after critical analysis and implementing design patterns in aspect oriented languages (i.e. aspectj and caesarj). The purpose of the thesis is to improve, enhance and examine modularity on the basis of separation of concerns, coupling, cohesion and reusability by implementing GOF design patterns in aspectj and caesarj (aspect oriented programming languages).
Thesis approach towards a Solution
Study of Research papers and books which are related to design patterns, and then criteria of choosing GOF design patterns. Analysis of aspect oriented technologies and aspect oriented programming languages AspectJ and CaesarJ.
Analyze which GOF design patterns improve modularity by implanting and comparison in different languages.
Software MyEclipse IDE 8.5 is used for implementation of GOF behavioral design patterns: Observer, Chain of Responsibility, Mediator, Command and visitor.
Implementation of these patterns is in aspect oriented programming.
Aspect oriented programming languages AspectJ and CaesarJ plug-in tools are used in MyEclipse IDE 8.5 for pattern implementations in both of them.
Efficiency Enhancement is measured by implementing GOF design patterns in aspect oriented technology: aspectj and caesarj.
Efficiency is checked on the basic of four software Characteristics: Separation of Concerns, Cohesion, Coupling and Reusability which are compared in both AspectJ and CaesarJ languages.
Implementation code and suggestions are given in the form of guidelines for designers, developers, researchers and users.
The details of these areas are given in Chapter 2.
Plan of work to be done under this Thesis
The thesis is composed of five chapters, in which first chapter describes the introduction of thesis. The second chapter explains the background literature used in this thesis and it also provides detailed study of design patterns, aspect oriented technologies, language constructs of aspect oriented languages i.e. AspectJ and CaesarJ. Third chapter explains the research methodology of the thesis. Fourth chapter deals with the final results in the form of comparison of aspect oriented languages for GOF design patterns and suggestions. Fifth chapter explains the conclusion and further enhancement of this thesis.
This research thesis provides following benefits of three types of stakeholders such as:
Designers
In this thesis, software designers decompose problem in different modules by using real world objects. Modules provide more reusable and flexible solution structure after applying design patterns and handling crosscutting concerns. This thesis is beneficial for software designers how to handle large complex systems.
Developers
This thesis is beneficial for developers how to implement exmples with design patterns in different aspect oriented technologies by using eclipse IDE with plug-in's of AspectJ and CaesarJ. Implementation is very simple, reusable and modular form for developers.
Users
In this thesis, it is very easy to understand and easy to maintain for users. They can easily reuse in other related applications.
Researchers
Aspect orientation is an emerging technology. Lot of work has been done in this domain as aspect weaver, composition filters etc. For enhance the maturity level of this domain, researchers are doing a lot of work in it.
CHAPTER 2
BACKGROUND STUDY
This chapter presents the background of this thesis. It divides into three major sections. Section 2.1 defines the design patterns, analysis of design patterns, what the reason of choosing GOF design patterns is and how they can improve efficiency in term of "Quality" factor. Section 2.2 describes the introduction of aspect oriented programming. Section 2.3 presents aspect oriented languages. Section 2.4 explains the constructs of aspect oriented languages i.e. AspectJ language and Section 2.5 gives detail descriptions of constructs of CaesarJ language. Section 2.6 analyzes and explains the reason of choosing particular software characteristics or software factors for efficiency enhancement in aspect oriented languages.
2.1 Design Patterns
The concept of design pattern is originated in work of the architect Christopher Alexander [Alexander et al., 1977], who describes pattern in:
"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."
This definition lies especially for the object oriented environment in the pattern community [Gamma et al., 1995].
At the time of designing or implementing an application, there is compulsory to program all different methods to run a whole application. These methods are called design methods. Some design methods are used in different applications that are called design patterns[Adelson and Soloway, 1985].
There are different kinds of patterns such as architectural patterns, design patterns and coding patterns. Architectural patterns contains on high level abstractions as focus is on overall whole system or framework [Buschmann et al., 2007]. These are also called conceptual patterns [Richard et al., 2005]. These patterns come in analysis part of software development life cycle (SDLC). Design patterns are medium level, some part of analysis and implementation of SDLC lies in this. And complete design phase of SDLC comes in design patterns. Its focus is on micro-architecture of subsystems [Buschmann et al., 2007]. Reusability of design patterns at subsystem level or component level come as classes, objects, inheritance etc in object oriented environment. Coding patterns are the part of implementation phase of SDLC. These patterns provide low level abstractions at language construct level [Buschmann et al., 2007]. These are also called idioms [Richard et al., 2005].
There are many design patterns which are used in different domains as: concurrency control design patterns, GRASP, GOF (Gang of Four) design patterns. There are architectural design patterns which describes overall behavior of complete system. There are also different patterns like domain specific patterns which are used in user interface design, web design, visualization, business model designs.
Almost above 200 standard design patterns exist which is very difficult to remember and according to every application, it is hard to recognize which design patterns will be use there [Buschmann et al., 1996]. Four authors Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides presented design patterns book "Element of Reusable Object Oriented Software" in 1995. These are specifically related to object oriented software and these are 23 design patterns [Gamma et al., 1995]. These design patterns belongs to architecture, design and idioms levels which comes in analysis, design and implementation levels of SDLC. So these design patterns are very popular design patterns. Four authors worked on these design patterns so that they called "Gange-of-Four" or "GOF" patterns. GOF design patterns typically show relationship between classes and objects without specify particular involved applications classes or objects.
2.1.1 GOF Design Patterns
GOF design patterns are used in domain of software engineering and these are standard patterns and implemented in different applications for efficiency enhancement [Gamma et al., 1995]. GOF design patterns allow designers and developers to communicate using well-known, well understood names for software interaction.
GOF design patterns enhance the speed of development process by providing tested, proven development paradigms. Reusing design patterns help to prevent minor issues that can cause major problems, and it also improves code readability for designers and developers who are familiar with the patterns.
Design patterns can be categorized in different forms through adopted by GOF along two axes: purpose and scope [Gamma et al., 1995].
Purpose describes that pattern is used for which purpose, either creational, structural or behavioral and Scope describes that patterns deals the use of class, objects or both [Gamma et al., 1995].
Creational
Structural
Behavioral
Class
Object
Purpose
Scope
Figure 1: Pattern Categories by GOF
GOF design patterns are divided into three categories: Creational Design Patterns, Structural Design Patterns and Behavioral Design Patterns [Gamma et al., 1995] on the basis of scheme of grouping patterns under the following roles [Buschmann et al., 1996].
Access Control group depicts pattern how to create and control access of services and objects so these type of grouping comes in creational design patterns.
Structural Decomposition, Management groups deal with structural design patterns. In structural decomposition how decompose component into parts and management deals with collection of objects. These type of groups lies in structural design patterns. Organization of work and communications deals with behavioral design patterns. In organization of work and communication, collaboration of components comes there.
Creational Design Patterns
In software engineering, Creational Design Patterns are those design patterns that deal with how to create objects. These patterns try to create objects in a manner suitable to scenario. Creational design patterns solve situation of scenario by controlling object creation.
Structural Design Pattern
In software engineering, Structural Design Patterns are design patterns that design by identifying a simple way to realize relationships between entities.
Behavioral Design Pattern
In software engineering, Behavioral Design Patterns are design patterns that identify common communication patterns between objects. By doing so, these patterns increase flexibility in carrying out this communication.
At the time of applying design patterns, there are different steps which have to follows to implement design pattern [Bushmann et al., 1996].
1. Specify Problem
2. Select Category of Pattern
3. Select problem category
4. Compare problem with Pattern
5. Compare Benefits
6. Select Pattern Variant
Figure2: Implementation of Design Pattern
Requirements
Pattern Knowledge
Pattern Repositories
In this thesis, concern is not changing in design patterns but study and analysis of design patterns and find out the efficiency factor with generic examples.
2.2 Aspect Oriented Programming
Aspect Oriented Programming separates crosscutting concerns from various programs. These separate crosscutting concerns are modular structure known as aspects. After handling crosscutting concerns, resultant programs are simpler, reusable and easy-to-maintain, easy to document.
Object oriented programming gives modularity when classes in an Object Oriented model perform a single, specific function. But these classes often share common functionalities with other classes that called secondary requirements. For example, if you want to add logging to classes within the data-access layer and also to classes in the user interface layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality that is logging is often identical.
Class UI{
Logging code save record
User Interface Code
Logging code save record
}
Object Oriented Design
But if there is approach of aspect orientation, application is divided into two basic modules which are primary modules and secondary modules. Primary module consists of core business logic of application and secondary module consists of non functional requirements. These non functional requirements are basically crosscutting concerns. There are some common cross cutting concerns like security, performance which will be in all classes. These secondary modules are also known as aspects. If one particular concern is used in multiple modules or different concerns are used in one module. These concerns are tangling and scattering concerns [Kiczales, G.; 2001].
Efficiency can be enhanced when there is aspect oriented programming. So this research is very beneficial according to efficiency point of view.
2.2.1 Example of Observer Pattern in Object Oriented Programming
Result: Observer
Update();
FigureElement
addObserver(Observer);
removeObserver(Observer);
notify();
Point: Subject
getX();
getY();
setX(int);
setY(int);
addObserver(Observer);
removeObserver(Observer);
notify();
Line: Subject
getPoint();
getPoint();
setPoint(Point);
setPoint(Point);
addObserver(Observer);
removeObserver(Observer);
notify();
Figure 3: Observer Example
In Figure3, there is an example of observer pattern of Subject and Observer roles which are implemented in object oriented programming language like java. There are two derived classes Point and Line which are from FigureElement base class. Both derived classes have setter methods to change coordinates of FigureElement. If there is need to log coordinate changes in a FigureElement, logging code will be placed in all four setter methods across two derived classes Point and Line of Base Class FigureElement. So, logging concern is crosscutting concern in FigureElement class hierarchy.
Problems in Object Oriented implementation
If design patterns are implemented in object oriented programming language without handling crosscutting concerns, there arises different problems which follows as:
Tangled Concerns
There are two different concerns involved in object oriented implementation i.e. java of observer pattern in Figure1- concern of the figure elements and concern of the Observer pattern. They are different because concern of the figure elements is to provide functionality for different kinds of shapes such as point or line that is core functionality while concern of the observer pattern is to notify registered observers for a change in the subject. In implementation of Figure 1, both these concerns are mixed up - class Point and class Line is tangled up with the two different concerns in which core functionality and secondary requirement non functional requirements both exist.
Reusability
Because of tangled code, classes Point and Line can not be reused at that place where pattern code is not required because of tangled code.
Hard to document
Tangled and scatter code are hard to document.
Redundant Code
Secondary requirements or crosscutting concerns are come in multiple classes for requirement of software.
Hard to maintain
Secondary requirement or crosscutting concerns are harder to maintain in object oriented implementation.
Design Pattern Implementation in Java and AspectJ
In Hanneman and kichzales paper [Hanneman, Kichzales, 2002], they implemented GOF design patterns in java and aspectj and showed that 17 patterns out of 23 which enhance modularity in term of locality, reusability, composition, (un) pluggability.
They divided GOF design patterns into categories, and provide general implementation strategies for each category of design patterns.
2.3 Aspect Oriented Programming Languages
Aspect Oriented Programming uses different programming languages for implementation. There are AspectJ, CaesarJ and HyperJ etc.
2.4 AspectJ- Programming Language
AspectJ is programming language. AspectJâ„¢ is a simple and practical aspect-oriented
extension to Javaâ„¢ [Kiczales, 2001] . AspectJ gives modular implementation of a range of crosscutting concerns after giving new constructs. AspectJ constructs are in detailed as below:
Join Points
Join points are used to capture the crosscutting structure of programs. "Join points are well-defined points in the execution of the program" [Kiczales, 2001] . Some examples of join points are:
Call Join Point
A method call join point refers to a call to some method. This exists in the calling object [Kiczales, G.; 2001].
Reception Join Point
A method call reception join point refers to a point in the control flow after the call but before the execution of the method. This join point exists within the called object. [6]
Execution Join Point
A method execution join point refers to a point in control flow when execution of a method starts [Kiczales, G.; 2001].
2.4.2 Pointcuts
Pointcut are used to capture these join points called pointcuts.
Pointcuts are collections of join points [Kiczales, G.; 2001].
Primitive PointCut Designator
AspectJ includes several primitive pointcut designators.
calls( void Point.setX( int ) )
This pointcut captures all those method call join points where signature of the called method matches void Point.setX( int )
receptions( void Point.setX( int ) )
This pointcut matches all those method call reception join points where signature of the method call matches void Point.setX( int ).
executions( void Point.setX( int ) )
This pointcut matches all those method execution join points where signature of the method call matches void Point.setX( int ).
User-Defined Pointcut Designator
Programmers can compose these to define user-defined pointcut designators.
Example:
poincut moves() :
calls( void Point.setX( int ) ) ||
calls( void Point.setY( int ) ) ||
calls( void Line.setP1( Point ) ) ||
calls( void Line.setP2( Point ) );
The pointcut moves captures calls to all those methods that cause change of coordinates in any of the FigureElement object.
2.4.3 Advice
Advice is used to actually implement crosscutting behavior. Advice is special method-like constructs that can be attached to pointcuts.
Advice is a method like mechanism used to declare that certain code should execute at each of the join points in a pointcut." [Kiczales, G.; 2001].
AspectJ supports three kinds of advice [Kiczales, G.; 2001]:
Before advice runs advice code before the execution of the join points marked by the associated poincut.
After advice runs advice code after the execution of the join points marked by the associated poincut.
Around advice preempts the normal computation at the join point, and starts running the advice code instead. Here are some examples of AspectJ advice mechanism:
after() : call( void Point.setX( int ) ) {
System.out.println( "Point Changed" );
}
The advice prints a message whenever method setX() is called on the object of class Point.
after() : moves() {
System.out.println("FigureElement coordinates changed");
}
The advice prompts user whenever the user-defined pointcut moves gets activated.
2.4.4 Aspects
"Aspects are modular units of crosscutting implementation." [Kiczales, 2001] Aspect declarations define aspects and have a form similar to that of class declarations. "Aspect declarations may include pointcut designators, advice declarations, as well as other kinds of declarations permitted in class declarations." [Kiczales, G.; 2001]
Following is an example aspect from [Kiczales, 2001] that keeps track of whether a figure element has moved recently. This aspect might be used by a screen update mechanism to find out whether any of the figure elements have changed since the last time the screen was updated.
aspect MoveTracking{
static boolean flag = true;
static boolean testAndClear() {
boolean result = flag;
flag = false;
return result;
}
pointcut moves():
receptions( void Point.setX( int ) ) ||
receptions( void Point.setY( int ) ) ||
receptions( void Line.setP1( Point ) ) ||
receptions( void Line.setP2( Point ) );
after(): moves() {
flag = true;
} }
At first aspect MoveTracking declares a static member flag of boolean type. Secondly it defines a method named testAndClear() that returns and resets the flag value. Thirdly it declares a pointcut moves that captures method calls to the setter methods of the two subclasses of FigureElement (see Figure 1). Finally it defines an after advice that activates every time pointcut moves gets activated and sets the flag variable.
Aspect Instantiation
Even though the form of an aspect declaration is similar to that of a class declaration, aspects are not instantiated like classes. Rather each non-abstract aspect has a single instance by default. Here "by default" means that the programmer do not create the instance explicitly.
2.4.6 Advantages of AspectJ
There are different advantages of aspectj language.
2.4.6.1 Untangled Concerns
Implementation classes are totally free from the pattern code. Roles can be added to and removed from different classes without changing their code. Even the whole pattern can be switched independently, because pattern concern is separated from the classes. So now pattern implementation is (un)pluggable. The two concerns - application concern and pattern concern, can be maintained independently. The pattern instances can be easily traced due to separation of different concerns into separate program abstractions. Consequently documentation is now an easier task.
2.4.6.2 Reuse
Implementation part of the pattern is reusable. Only the binding part is redefined for each new context. Because classes do not contain any pattern code they are also reusable now, and different classes need not to replicate code for the implementation part.
2.4.6.3 Independently Extensible Design
A class can participate in two different pattern roles (may belong to different patterns) without getting tangled with different types of code (concerns).
2.4.7 Flaws of AspectJ
Hannemann and Kiczales [Hannemann and Kiczales, 2002] work seemed quite promising until Mezini and Ostermann [Mezini and Ostermann, 2003] identified critical flaws in their implementations. In an introductory paper [Mezini and Ostermann, 2003] to their new language named CaesarJ [Mezini and Ostermann, 2003] (earlier named just Caesar), they mentioned the flaws in AspectJ implementation of Observer pattern[Hannemann and Kiczales, 2002] and illustrated how CaesarJ can implement Observer pattern overcoming problems with AspectJ implementations.
2.4.7.1 Violation of Object Oriented Principles
There is violation of object oriented principles in aspectj language. Methods are not attached with class but they determine object with parameters. Roles cannot be passed as parameter. This design is far from OO principles. Rather it is a procedural design having just an object oriented tag with it.
2.4.7.2 Tangling of Concerns
The basic principle behind AspectJ design is separation of concerns. However the HK's implementations [Hannemann and Kiczales, 2002] violate even this basic principle by mixing roles together into one programming abstraction.
2.4.7.3 Roles cannot be inherited
As it is desirable to keep the role interfaces empty in the HK implementations[Hannemann and Kiczales, 2002], individual roles cannot be extended by adding or overriding new features. If it is required to change their behavior anyway, the whole aspect needs to be inherited. This creates complexity and reduces program clarity.
2.5 CaesarJ -Programming Language
CaesarJ is a relatively new AOP language [Mezini, Ostermann, 2003]. It supports the basic features of AspectJ. It provides the concept of join points and provides different AOP constructs such as pointcut, advice and aspect (called as cclass). However it does not support AspectJ introductions, also known as inter-type declarations.
Besides the AspectJ constructs it provides some new features. Following subsections introduce these new features one by one.
2.5.1 Aspect Collaboration Interface
An aspect collaboration interface (ACI) is a class-like structure that collaborates mutually recursive types [Mezini, Ostermann, 2003]. It provides easy refinement of a whole group of related classes, and provides bidirectional communication between the two parts of a reusable aspect - implementation part and binding part. Consequently both the parts become reusable.
Figure 2 shows the structure of an ACI. It has three parts:
• Declaration part
• Implementation part
• Binding part
Aspect Collaboration Interface
cclass A
Provided Method
Expected Method
cclass B
Provided Method
Expected Method
ACI Implementation
cclass A
Provided Method
cclass B
Provided Method
ACI Binding
cclass A
Expected Method
cclass B
Expected Method
Figure 4: CaesarJ Structure
The declaration part declares nested types and their methods. These methods are of two kinds:
• Provided methods
• Expected methods
The provided methods implement the services that the ACI provides to any application. The expected methods on the other hand, are the methods that an ACI expects from its application. Therefore their implementation is application-dependent.
The implementation part of an ACI provides implementation for the provided methods, while the binding part provides implementation for the expected methods [Mezini, Ostermann, 2003].
As multiple implementations and bindings can be defined for a single ACI, an implementation-binding pair is needed to realize an aspect type. This implementation-binding pair is called as weavelet. By composing a weavelet, all the binding classes from the selected binding of an ACI are binded with the implementation classes in its selected implementation.
2.5.2 Wrapper Recycling Mechanism
Traditional methods of composing separated concerns such as AspectJ introductions and Hyper/J merging relationships results in several problems [Mezini, Ostermann, 2003] due to their persistent nature. A better way to compose separated concerns is to wrap classes from one concern over classes from another concern. CaesarJ supports this feature by providing support for maintenance of one-to-one mapping between instances of the wrappees and that of the wrappers, and by providing mechanisms to access a wrapper for a wrappee and vice versa.
2.5.3 Aspectual Polymorphism
With the capability of dynamic aspect deployment it is natural to have aspectual polymorphism. In CaesarJ we can treat a hierarchy of aspects polymorphically.
Virtual Types
In CaesarJ, all nested interfaces of an ACI and all classes that implement or bind such interfaces, are virtual types/classes. This means that the individual type(s) of an ACI can be refined by inheriting another ACI from it, and overriding the respective type(s). All references to instance(s) of such type(s) will be rebound to the refined type(s). This feature is known as family polymorphism [Mezini, Ostermann, 2003].
2.6 Software Characteristics
Efficiency enhancement of GOF Design Pattern can be checked on basic of four software characteristics which are separation of concerns, coupling, cohesion and reusability. The reasons of choosing these software characteristics as benchmark: according to [Garcia et al., 2005] the first three separation of concerns, coupling, cohesion are well-known SE characteristics and have been used in several studies. About the fourth characteristics Deitel's say: "There are three things important in software: reuse, reuse and reuse."
Here is a brief explanation for each of the four characteristics.
2.6.1 Separation of Concern
Separation of concern means that each concern should be implemented into a separate program abstraction. This principle can be violated in two ways: scattering and tangling concerns. Scattering means that more than one program abstractions implement a single concern's functionality. Tangling means that an abstraction implements functionality to support more than one concern [Kiczales, G.; 2001]. It seems more important property regarding aspect oriented technology.
2.6.2 Coupling
"Coupling is a qualitative indication of the degree to which a module is connected to other modules and to the outside world" [Pressman, 2001]. In an OO model, inheritance also contributes in increasing the amount of coupling besides associations.
2.6.3 Cohesion
"Cohesion is a qualitative indication of the degree to which a module focuses on just one thing" [Pressman, 2001].
2.6.4 Reusability
When a software component can be used in different application contexts without changing anything, the component is said to be reusable.
CHAPTER 3
METHODOLOGY
This chapter describes the design process of methodology of this thesis that how can be enhancing efficiency of GOF design patterns by using aspect oriented technology. In section 3.1, there is complete process of methodology. In section 3.2, there is work flow of thesis. In section 3.3, how implementation of GOF design patterns can be done in aspectj and caesarj.
3.1 Process of Methodology
This research thesis consists of four main parts.
Study and analysis of Design Patterns
Introduction of Aspect Oriented Technology
Contructs of Aspect Oriented Languages
Implementation of design patterns in aspect oriented languages
Measurements of efficiency enhancement in term of four basic software characteristics of design patterns in aspect oriented technology.
The flow of research thesis is shown as in figure 5.
Aspect oriented Languages
Design Patterns
Results in form of
-Code
-Suggestions which patterns enhance modularity
Implementation
Pattern Code
Application Code
Pattern Code
Application Code
Compare on the basis of:
- Separation of Concerns
- Coupling
- Cohesion
- Reusability
Implement GOF Design Patterns
-Creational Patterns
. Abstract Factory
. Bridge
. Factory
. Prototype
. Singleton
-Structural Patterns
. Adapter
. Bridge
. Composite
. Decorator
. Facade
. Flyweight
. Proxy
-Behavior Patterns
. ChainOfResponsibility
. Command
. Interpreter
. Iterator
. Mediator
. Memento
. Observer
. State
. Strategy
. TemplateMethod
. Visitor
Caesarj
Aspectj
Aspect Oriented Technology knowledge
3.2 Design Process of Methodology
Figure 5: Detailed Design of Methodology
Study of Research papers, journals and books which are related to design patterns [Gamma et al., 1995][Sherif M., 2003] [Alexander et al., 1977][Adelson and Soloway, 1985][Buschmann et al., 2007][Richard et al., 2005] [Buschmann et al., 1996] and then there are lot of design patterns from which criteria of choosing GOF design patterns[Gamma et al., 1995][ Alexander et al., 1977][ Buschmann et al., 2007]. Analysis of aspect oriented technologies [ACM, 2001] [Kiczales et al., 1997] [Kiczales, G.; et al.; 1997][ Kiczales et al.; 2002] and aspect oriented programming languages AspectJ and CaesarJ[Kiczales et al.; 2001] [Grek, J., 2007] [Aracic, I.; et al., 2003][www.aspectj.org][www.caesarj.org].
There are 17 GOF design patterns out of 23 in aspectj which enhance modularity in term of locality, reusability in aspectj [Hannemann, 2002]. Analyze which GOF design patterns improve modularity by implanting and comparison in different languages [Hannemann, 2002].
Due to time constraint, the work of this research thesis is implementing five design patterns which are lies in behavioral category and these are Observer, Chain of Responsibility, Mediator, Command and Visitor on the basis of two find maximum benefits in aspect oriented technology. Software MyEclipse IDE 8.5 is used for implementation of GOF behavioral design patterns. And aspectj 1.6.5 and caesarj 0.8 plug-in tools of aspect oriented technology are used to implementation of these five patterns.
Thorough study of language constructs of aspectj [Kiczales, 2001] and caesarj [Mezini, Ostermann, 2003] is required for implementation of patterns.
3.3 Design Patterns- AspectJ and CaesarJ Implementation
At the time of implementation of observer pattern, there are two roles Subject and Observer. When there is change in Color Cycle example [see annexure-A] which is called subject, observer will notify or update that color cycle has been updated. There are both compilers of java and aspectj are used. Business logic or application classes comes in .java classes. And aspects which is in fact pattern code comes in .aj aspectj files.
Business Logic Code Pattern Code
Java classes AspectJ aspects
Weaver
Compiler
Executable
Figure 6: Weaving Process in Aspect Oriented Technology
In figure 6, the weaving process is worth noting that the original code does not need not to know anything about the extending aspect, if one translates it without weaving, the result is the original application. If the aspects are included, the result is the application extended with the functionality of the aspects. It means that the original code need not be changed; the same program is used in both cases. If there is object oriented languages, then either business logic classes or application classes and pattern codes comes in same files with tangling concerns.
In aspectj of observer pattern, aspect code contains into two files. One file is generic and other file is related to specific application. Generic file contains implementation part and specific application contains binding part. On the other hand, caesarj provides more abstraction at the time of implementation. Through ACI, first prototypes of implementation and binding part come separately. Then implementation part is handled separately in file. And binding part is separately handled. In caesarj, implementation part denotes by provided methods and binding part denotes by expected methods. Caesarj used wrapper recycling mechanism rather than inheritance. Inheritance shows strong coupling. And in caesarj, it is indirectly binding of implementation part and binding part which gives better results.
In aspectj and caesarj, mechanism of reuse is differentiating because of inheritance. Aspectj used aspect and it is static inheritance and in caesarj rather aspects these are caesar classes which are used through polymorphic or dynamic way [Sousa et al., 2008].
Abstract Aspect
Concrete Aspect
Concrete Aspect
Application
Application
ACI
Component Implementation1
Component Implementation2
Binding
Binding
Application
Application
Figure:7 AspectJ vs CaesarJ Mapping
Static Inheritance
Static Inheritance
Polymorphic Layer
Polymorphic Layer
Figure 7 explains the mechanism of mapping between generalized and application part. In aspectj and caesarj compiler, it is internal working how they map both parts with each other. Because of polymorphic behavior, caesarj gives better results.
Remaining four design patterns chain of responsibility [see Annexure-B], mediator [see Annexure-C], command [see Annexure-D] and visitor [see Annexure-E] have also been implemented in aspectj and caesarj tools of aspect oriented technology.
Efficiency is checked on the basic of four software Characteristics: Separation of Concerns, Cohesion, Coupling [Pressman, 2001] and Reusability which gain maximum benefits after comparing both AspectJ and CaesarJ languages.
CHAPTER 4
RESULTS
Behavioral Design Patterns
Separation of Concerns
Coupling
Cohesion
Reusability
AspectJ
CaesarJ
AspectJ
Caesarj
AspectJ
CaesarJ
AspectJ
CaesarJ
Observer
[see Annexure-A]
Good
Better
High
Low
Low
High
Good
Better
Chain Of Responsibility
[see Annexure-B]
Good
Better
High
Low
Low
High
Good
Better
Mediator
[see Annexure-C]
Good
Better
High
Low
Low
High
Good
Better
Command
[see Annexure-D]
Good
Better
High
Low
Low
High
Good
Better
Visitor
[see Annexure-E]
Good
Better
High
Low
Low
High
Good
Better
Results are on the basis of different examples which are in Annexure.
Separation of concerns: Results
Average: separation of concerns in object oriented classes.
Good: separation of concerns in aspects gives abstraction.
Better: separation of concerns in aspects gives abstraction more carefully.
Coupling: Results Reusability: Results
Low Coupling: No of classes increased
High Coupling: No of classes decreased Average: No reusability
Good: less reusability
Better: More reusability
Cohesion: Results
Low Cohesion: No of classes decreased
High Cohesion: No of classes increased
4.1 Summary
These five behavioral design patterns implemented in MyEclipse8.5 IDE by using plug-ins of latest aspectj and caesarj. These five patterns Observer, Chain of Responsibility, Mediator, Command and Visitor give maximum benefits in term of these software characteristics: separation of concerns, coupling, cohesion and reusability. Although visitor pattern in aspectj just provides abstraction. There is no need of pointcut because of the behavior of visitor pattern. New classes which are added can belong to heterogeneous environment. All depends on the scenarios and examples. There are simple examples of patterns which are implemented in these patterns. In java, all patterns have also implemented [Hannemann, 2002] but they do not give more benefits because of tangling and scattering concerns. Java does not support crosscutting concerns. As compared to java, aspectj and caesarj both are used to enhance efficiency.
4.2 Suggestions
Caesarj version 0.9 is compatible with java2. It does not support java 5 as aspectj version 1.6.5. Java2 is old version as compared to java5. Although it is not mature compiler but gives better results in caesarj than aspectj. Aspectj creates problems when there is attachment of implementation part with binding part through aspectj inter type declaration: declare parents language constructs. It supports static mechanism. Caesarj supports Aspect Collaboration Interface (ACI) and wrapper recycling mechanism so it gives more abstraction almost all patterns. It supports dynamic aspectual polymorphism. There is no inheritance rather than it uses indirectly mechanism of binding among classes so they produce better results.
CHAPTER 5
CONCLUSION AND FUTURE ENHANCEMENTS
In this research work, there is complete study of design patterns. Elements of reusable software engineering which are part of object orientation and after analysis of design patterns, preference is on GOF design patterns repository for implementation. To measure the efficiency enhancement of design patterns, there is implementation of five behavioral design patterns i.e. Observer, Chain of Responsibility, Mediator, Command and Visitor due to time short time constraint. Behavioral design patterns focus is on communication among objects or sub-systems. Implementation of these design patterns is in aspect oriented tools i.e. aspectj and caesarj. There is inter type declaration IDT in aspectj and because of its static nature, it decreases the flexibility, reusability of classes among different applications. On the other hand, caesarj provides better mechanism of implementation of these design patterns to enhance modularity, flexibility and reusability. Efficiency enhancement of these patterns measured on the basic of software engineering characteristics i.e. separation of concerns, coupling, cohesion and reusability.
In further enhancement of work, there is complete study of repositories of GOF design patterns in aspectj and caesarj on the basis of these software characteristics i.e. separation of concerns, coupling, cohesion and reusability.
Chapter 6
