Analyzing effect of Aspect Oriented concepts in design and implementation of design patterns with case study of Observer Pattern

Analyzing effect of Aspect Oriented concepts in design and implementation of design patterns with case study of Observer Pattern

Analyzing effect of Aspect Oriented concepts in design and implementation of design patterns with case study of Observer Pattern

Deepali A. Bhanage1, Sachin D. Babar2

Sinhgad Institute of Technology, Lonavala

Abstract Design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. Several patterns crosscut the basic structure of classes adding behaviour and modifying roles in the classes relationship. Recent studies have shown that several design patterns involve crosscutting concerns where object oriented abstractions failed to handle, this led to decreasing system modularity, reusability supportability, portability, reliability and maintainability. This encourages examining impact of Aspect Oriented Programming on S oftware development at Design Level. In this paper, effect of As pect Oriented Programming on Gang of Four (GOF) design pattern is analyzed. This investigation is further continued with implementing case study of Observer Pattern with example of IT Infrastructure Monitoring. This paper also explores use of JAVA Annotations in implementation of Observer Pattern with AOP.

Keywords Aspect Oriented Programming, AOP, AspectJ, Observer Pattern, Java annotations, GoF design patterns, Crosscutting.

1. INTRODUCTION

   Design pattern is a general repeatable solution to a commonly occurring problem in software design . It is a description or template for how to solve a problem that can be used in many different situations [1]. Design patterns can speed up the development process by providing tested, proven development paradigms. Design patterns helps to produce good design, which helps in producing better softwares. Design Patterns have gained its popularity after the Gang of Four book [1] where the first software pattern catalogue containing the 23 Gang-of-Four (Go F) patterns were introduced.

   Recent studies shown that s everal patterns crosscut the basic structure of classes adding behav iour and modifying roles in the classes relationship. Crosscutting represents the situation when a concern is met by placing code into objects through the system but the code doesnt directly relate to the functionality defined for those objects [2]. Exa mples of crosscutting concerns are logging, synchronization, error and e xception handling, scheduling and optimizat ion.

   Observer pattern is one of the popular pattern described by GoF. The observer pattern is a software design pattern in which an object, called the subject, ma intains a list of its dependents, called observers, and notifies them auto matically of any state changes, usually by calling one of their methods . The Observer Pattern Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. The observer pattern is used when the change of a state in one object must be reflected in another object without keeping the objects tight coupled. It is a lso used when fra mework needs to be enhanced in future with new observers with min ima l changes [1].

   Abstracting the imp le mentation offers great fle xib ility. Observers can observe the state change of any subject if that subject imple ments Subject interface and the observers themselves extend Observer abstract class. But at the same time the responsibilities of classes are also changed. In order to being a subject, an object has to imple ment the features of maintain ing the list of observers, notifying each observer when its state changes. When an observer wants to observe a subject, it has to extend an abstract class to indicate that it has the method receiving the notifications. These features all belong to Observer pattern, are tangled with the core features of the object, obscure the primary concern of objects. This violates the s ingle responsibility feature of OOP [3].

   Although the use of Observer pattern brings several benefits, they could hard-code the underlying system, ma king difficult to express changes. To imple ment Observer patterns described above in a system you may have to modify several classes, affecting their relationships and their c lients.

   The Object Oriented Progra mming is most commonly used and very popular methodology employed in software Industry, but it does not do as a good job in address many crosscutting concerns that must be included in mu ltip le modules [2]. In OOP crosscut concerns, code tangling and code scattering will be seen Code tangling is caused when a module handles multip le

   concerns simultaneously, the codes from other modules present in a module. Code scattering is caused when a single issue is imple mented in mult iple modules. Because crosscutting concerns are spread over many modules in nature, related imple mentations are also scattered over all modules. Code tangling and code scattering together result in lower code reuse and harder evolution [4]. If a module is imple menting mu ltip le concerns, it is hard to modify. When a module is scattered in many modules, if the module requires re imple mentation, many modules have to be modified. Th is fails of Open Close Princip le [4]. Unfortunately, object-oriented abstractions are often not able to modularize those crosscutting concerns, which in turn decrease the system reusability and ma intainability.

   Aspect Oriented Progra mming can help on separating some of the systems design patterns, specifying and imple menting them as single units of abstraction [5]. Co mpared with OOP imple mentation, Aspect-oriented Progra mming (AOP) offers one viable solution, duplicated code blocks are modeled in d iffe rent aspects that crosscut other modules . OOP and AOP co mple ment each other [6]. While aspect-orientation originally has eme rged at the programming leve l, modern software development is more than just coding, there was a need to study applying the aspect orientation also over other development phases, starting from the require ments analysis phase till the imp le mentation phase, which led to the emerge of aspect oriented software engineering . The aspect-oriented programming main goal is to help the developer in the task of c learly separate crosscutting concerns, using mechanisms to abstract and compose them to produce the desired system. The aspect-oriented programming e xtends other programming techniques (object oriented, structured, functional etc) that do not offer suitable abstractions to deal with crosscutting [5].

   When observer pattern imp le mented by AOP the subject or the observer doesn't extend an abstract class or imple ment an interface, an aspect introduces interfaces or classes to existing classes. At the same time when the subject notifies observers and which method of the observer receives notification are defined in the same aspect. Maintaining the list of observers is also finished by this aspect. When the subject state changes, this aspect will notify the observer. In this imple mentation, if an object wants to observe other objects, it only needs a response method, other modificat ions are not required. It is not necessary to modify the objects which will be observed. The imple mentation is clean which easily evolves and helps to address the crosscutting concerns of the OOP [3].

   While imp le menting the Observer pattern using AOP, every object has a single responsibility. The crosscut

   concern defining the relat ions between objects is modeled in an aspect, not in classes. Though there are many benefits of AOPas compared to OOP, users need to know Aspect Oriented Progra mming Language for imple mentation. Paper discuss about use of JAVA Annotations, to define the subject, the observer and their relations. Users employ these annotations instead of an aspect language to define the pattern concern [4]. Th is program analyses and generates the aspect, weaves this aspect with target classes by load-time weaving or compile-t ime weaving.

2. ST UDY FORMAT

   This paper is divided in fo llo wing sections. Section III will e xpla in the literature survey which highlights the problems occurring in tradit ional imple mentation and related solution that is use of AOP at the time of imple mentation of GoF Design Patterns. Section IV will give information about imple mentation of observer pattern with case study of IT Infrastructure event Management system with Aspect oriented concepts. With this exa mp le, paper will discuss crosscutting and how to overcome it with the help of AOP. Section V will e xp lore use of Java annotations in imp le mentation. Section VI unfolds the effect of AOP on Observer Pattern measured with respect to different software properties. Finally the conclusion of the paper is presented.

3. RELAT ED WORK

   The ma jority of applications available in market contain common functionality such as authentication, authorization, caching, co mmun ication, e xception manage ment, logging and instrumentation, and validation which are described as crosscutting concerns because it affects the entire application, and should be centralized in one location in the code where possible. To compensate for missing tools and languages we need architectural solutions for the problems around crosscutting concerns [9]. Design pattern provide reusable solution in all types of software designing and imple mentation. It beco mes important to verify the effect of Aspect oriented programming to re move the crosscutting concern so that it will imp rove modularity, ma intainability, reusability, uniformity, transparency, extensibility.

   Paper analyses comparison between use of Object Oriented and Aspect Oriented concepts at design level. After comparison it has been concluded that in few Go F Design Patterns crosscutting concern is present and it can be addressed by applying the aspect oriented approach at design level [3][8].

   TABLE I

   Effect of A OP on Design Patterns [3]

   Gang of Four De sign Patte rns	Crosscutting Concern	Improved Modularity	Improved Reusability
   Chain of Re sponsibility	Yes	Yes	Yes
   Command	Yes	Yes	Yes
   Interprete r	No	No	No
   Ite rator	No	No	Yes
   Me diator	Yes	Yes	Yes
   Memento	No	Yes	Yes
   Obse rve r	Yes	Yes	Yes
   State	No	Yes	Yes
   Strategy	No	Yes	Yes
   Te mplate Method	No	No	Yes
   Visitor	No	Yes	Yes
   Adapte r	No	Yes	Yes
   Bridge	No	Yes	Yes
   Composite	Yes	Yes	Yes
   De corator	No	Yes	Yes
   Façade	No	No	No
   Flyweight	No	Yes	Yes
   Proxy	No	Yes	Yes
   Abstract Factory	No	Yes	Yes
   Builder	No	No	Yes
   Factory Me thod	No	Yes	Yes
   Prototype	No	Yes	Yes
   Singleton	No	No	No

   crosscutting concerns. Table 1 shows the effect of Aspect Orientation in terms of e xistence of crosscutting concerns, improved modularity and reusability

   In this paper, case study of Observer pattern is done while applying AOP concepts at design as well as imple mentation level. The distinctive crosscutting ele ments in the Observer pattern are the roles (Subject and Observer) superimposed to the classes participating in the imp le mentation of the pattern, and the consistent behavior of notifying the observers required fro m the methods changing the state of the Subject object [6].

   This paper exp lains the Observer pattern with the help of AOP and e xa mple o f IT Infrastructure Event Management. The Informat ion Technology Infrastructure Library (ITIL) is a set of practices for IT service manage ment (ITSM ) that focuses on aligning IT services with the needs of business. Event Management and monitoring is process added in ITIL wh ich is responsible to manage all events that occur in the infrastructure to ensure normal operation and also to assist in detecting and escalating exception conditions. Event Management assists with the early identification of incidents through providing a baseline of automated operations in order to allo w service management staff to focus on become more proactive in their daily operations. Events are normally notifications/warnings created by an IT Service, Configurat ion Ite m (CI) or any type of monitoring tool around the status or availability.

   There were qualitat ive studies such as the work done by [2][4] which represents effort done in the area of addressing the impact of applying the aspect oriented programming approaches on GOF design patterns based on important software engineering attributes and other quantitative studies [3][8] performed to compare object oriented and aspect-oriented imple mentations based a metrics of measurements measuring the cohesion, coupling and size of both imp le mentations. There are mu ltip le surveys conducted to see the use of AOP with design patterns at design level. Most of the studies are not extensive and limited to theoretical work.

   As discussed in [2] applying aspect oriented concepts on GoF patterns could lead to improved modularity, ma intainability, reusability, uniformity, transparency, e xtensibility even if the pattern doesnt involve

4. IMPLEMENTATION OF OBSERVER PATTERN WIT H

   AOP

   Observer pattern maintains consistency among several objects that depends on a model data in a way that promotes reuse and keep a low coupling among classes. In this pattern, every time the Subject state changes, all the Observers are notified. The ma in problem with the object-oriented Observer pattern is that you should modify the structure of classes that participate in the pattern. So, it is hard to apply the pattern into an existing design as well as re move fro m it.

   The design of the Observer pattern is changed in order to represent it as classes and aspects. There is no Observer role neither a Subject one. Both structure and behavior of these two roles are e xpressed in the MonitoringObserverPattern aspect. ITSMSubject describes the interface that all the concrete subjects must be in accordance to (enforce by the MonitoringObserverPattern and

   MonitoringConcreteObserverPattrn). When imple mented, the ITSMSubject will contain a reference to its observers, and allow the dynamic addition and deletion of observers. Observer describes the interface

   that all the concrete observers must be in accordance to (enforce by the MonitoringObserverPattern and MonitoringConcreteObserverPattern). They are notified every time the state of the subject changes. ITSM ConcreteSubject Store state information to be used by ConcreteObservers. It does not, however, send notifications to its Observers. This responsibility is part of the MonitoringObserverPattern role. ConcreteObservers serve as basis to field and methods introduction performed by the MonitoringObserverPattern. MonitoringObserverPattern is an abstract aspect that encapsulates the behavior of the Observer pattern. The MonitoringObserverPattern contains the fields and methods to be included in the classes that are affected by the MonitoringConcreteObserverPattern. Concrete ObserverPattern specifies in what situations the ConcreteObservers are going to be notified as we ll as what is going to be executed when the ConcreteObservers are notified.

   In the imp le mentation of ITSM event management, diffe rent devices, applications, hardware, database and services are subjects. ITSM Ad min istrators and different application can serve as Observes. When some inc ident occurs for configurable item, popularly known as CI, sends notifications to the observer as event. Sometime observer may propose to receive events for analysis and informat ion. The list of all the observers is maintained in Aspect MonitoringObserverPattern. Pointcut and advices in MonitoringObserverPattern helps to waive the application. When the classes corresponding to concrete subjects and concrete observers are weaved together with the MonitoringConcreteObserverPattern, the follo wing methods and fields are attached to the ITSM ConcreteSubject and ConcreteObservers: fie lds Observer observers (ITSM ConcreteSubject), Subject subject (Concrete Observers) methods void add(Observer obs), void re move(Observer obs) (Concrete Subject), void setSubject(Subject s), Subject getSubject() (Concrete Observers) These attachments are specified in the abstract aspect (the MonitoringObserverPattern). The ITSM ConcreteSubject imple ments the ITSMSubject interface. The concrete observers imple ment the observer interface. The other modifications are done to the dynamic nature of the observer and subject classes, telling that every time that the state of the subject changes the update method of the observers is invocated.

5. USE OF JAVA ANNOTATION IN IMPLEMENTATION

   Ho wever, using this method you have to know how to define pointcuts, advices, inter-type declarations in aspects, how to weaving aspects with classes. This paper provides a method using Java annotations to define pattern participants and their relations, and then those annotations are used to generate aspects. In this

   Figure 1: Imp le menting Observer Pattern with AspectJ[2]

   imple mentation, users only use Java annotations rather than Aspect language; they don't have to know an Aspect language.

   1. Defining Annotation @subject and @observer

      @Subject is applied to specify the subject, @Observer is used to define the observer. Both annotations are used to annotate a class or an interface. Sometime there are many groups of different observing associations between objects, so the id property is defined to identity which group objects are in; its default value is o. The same class may be annotated with different id. Other annotations defined later a lso have this property.

   2. Annoting State Change and Update Method

      @Subject Change is applied to a method, indicting after e xecuting this method, the subject's state changes, and observers will be notified.

   3. Starting and Stopping Observing

      After annotating pattern participants, the subject and the observer, we need to establish the association between participants to start observing. It is apparent that only when we can get both the subject and the observer, we may establish their association.

6. RESULT OF ST RUCTURED ANALYSIS

In this paper, structured analysis is done for applying Aspect Oriented concepts on Observer Pattern to solve the problem e merg ing fro m the existence of Crosscutting concerns. It is realized that after applying AOP to Observer pattern leads to improve ment in some key software properties . Table 2 shows the effect of AOP on diffe rent software properties when applied to Observer Pattern.

After Applying AOP to Observer Pattern, paper analyzes the impact of using JA VA Annotation in Observer Pattern.

Results of the JAVA Annotation analysis is as follows Annotations provide a novel method to define participants and their re lations by annotations .

JAVA Annotation can be used to generate Aspects.

No need to understand AOP to overcome

shortcomings of Observer Pattern.

Use of annotation provides clean and simple solution to comple x imple mentations.

TABLE II

Structured Analysis of Observed Pattern with AOP

CONCLUSION

When applying Aspect Oriented Progra mming to design pattern lead to efficacious push towards building effective and intelligent solutions. Imple menting ITSM Event Management with Observer Pattern under the umbre lla of Aspect Orientation reduces the crosscutting concern and improves the maintainability, reusability, uniformity, transparency, extensibility. Use of Java

annotations in Observer Pattern helps to deliver c lean and powerful solution.

REFERENCES

1. Gamma, E. et al Design Patterns- Elem ents of Reusable Object Oriented Software. Addison-Wesley, 2009.

2. Eduardo Kessler Piveta; Luiz Carlos Zancanella;, Observer Pattern using Aspect – Oriented Programming SugarloafPLoP Conferenece, 2003.

3. El Maghawry, N.; Dawood, A. R.; ,Aspect oriented GoF design patterns, Informatics and systems (INFOS), 2010 The 7th International Conference on, vol., no., pp.1-7, 28-30 March 2010..

4. Liu Jicheng; Yin Hui; Wang Yabo; , A novel implementation of observer pattern by aspect based on Java annotation, Computer Science and Inform ation Technology (ICCSIT), 2010 3rd IEEE International Conference on , vol.1, no., pp.284 -288, 9-11july 2010.

5. Ramnivas Laddad . AspectJ in Action: Practical Aspect Oriented Programming. Addison- Wesley,2005.

6. Lei Zhang; , Study on comparison of AOP and OOP, Computer Science and Service Syatem (CSSS), 2011 International Conference on , vol., no., pp.3596-3599, 27-29 Jane 2011.

7. Christiansson, B.; Forss, M.; Hagen, I.; Hansson, K..; Jonasson, J.; M. Jonasson, Lott, F.; Olsson S.; and Rosevall, T. GoF Design Patterns- with example using Java and UML2,2009.

8. Wang Xiaohuan; Zhang Shu; T ang Wanmei. A New Programmng Fashion in OOP and AOP, Journal of Chongqing University of Arts and Sciences (Natural Science Edition), 2007, v.26 n. 14, pp.41-44.

9. Christa Schwanninger; Egon Wuchner; Michael Kircher Encapsulating Crosscutting Concerns in System Software. In Proceedings of the Third AOSD Workshop on Aspects,

   Components, and Patterns for Infrastructure Software 2004.

10. Marin, M. ; Moonen, L. ; van Deursen, A., A Classification of Crosscutting Concerns, Software Maintenance, 2005. ICSM'05. Proceedings of the 21st IEEE International Conference on 26- 29Sept2005.