Aspect Oriented Software Engineering

International Journal of Engineering, Management & Sciences (IJEMS) ISSN-2348 –3733, Volume-2, Issue-4, April 2015

Aspect Oriented Software Engineering Marwan Ali Albahar  Abstract— Aspect-Oriented Software Engineering (AOSE) has emerged a latest and very attractive software development model that is intended to complement and improve a wide variety of modern development areas. In addition, aspect oriented software engineering offers a wide variety of advanced and unique program development and modularization mechanisms. The research has shown that the development of software applications through aspect oriented software engineering mechanisms improves the implementation structure of a software application which has significant influence on a number of important software attributes for instance reduced complexity and enhanced reusability. Hence, these software attributes improves the quality of software development lifecycle as well as results in better software development (Brichau and D’Hondt; Garcia, Kulesza and Sant'Anna). This paper presents a detailed analysis of some of the important aspects associated with aspect oriented software engineering.

This paper will outline some of the fundamental areas of aspect orientation approach which are required in contemporary software development. This paper will also discuss the role of aspect oriented software engineering in improving the performance of current software development lifecycles.

Index Terms—— Aspect-Oriented Software, Software Components, Concern Modeling.

I. INTRODUCTION In the majority of huge software applications, it is difficult for the software development teams to understand the relationships between the software components and requirements. In fact, a number of software components can be implemented through a single requirement as well as each software component can have the ingredients of a number of requirements. In other words, the implementation of a change in the requirements can require from the software development team to completely understand and modify a number of other components. On the other hand, a software component is intended to provide some fundamental functionality however it can also contain code that can be used to implement a number of software requirements. In case when the software development team needs to reuse some of the important system components, it can be difficult or costly to reuse such components for the reason that reuse sometimes requires from software developers to make changes to these components in order to eliminate additional code that has no relationship with the key functionality of the software component (Sommerville 566; Nakagawa, Ferrari and Sasaki). In this scenario, AOSE is a very helpful technique for software development that has been developed to deal with this issue in order that it becomes easy for the software Manuscript received April 24, 2015.

Marwan Ali Albahar, Department of Computer Science, Frost Burg State University, Maryland, USA

29

development team to maintain and reuse the software components. Basically, the fundamental idea of AOSE is based on the concept of abstractions which are acknowledged as aspects. Additionally, these aspects are used to apply some of the core system functionality that can be required at various different sections or areas in a software application. In addition, these aspects are used to capture functionality that coexists and overlaps with other functionality that is the part of a system. However, these aspects are utilized in combination with other abstractions for instance methods and objects. In this scenario, a working aspect-oriented software application can be developed by automatically integrating (merging) methods, objects and aspects, along with requirements specifications those were mentioned in the program source code (Sommerville 566; Nakagawa, Ferrari and Sasaki).

One of the most important features of these aspects is that they contain a description of where they should be integrated in a software application or specific components, along with the code executing the crosscutting feature.

However, a software programmer can mention that the cross-cutting source code is added after or before a definite routine call or when a call will be made to that attribute.

Fundamentally, the aspect is merged into the key software program with the intention of building a new improved system (Sommerville 566; Wampler).

One of the most important advantages of aspect-oriented software engineering is that it is very useful in the separating the concerns. The research has shown that splitting concerns into several autonomous components instead of merging a number of diverse concerns in the single consistent abstraction is a noble software development approach. In other words, the separation of cross-cutting concerns into different aspects makes it easy for software development team to understand, modify and reuse autonomously, even without having the need for where the code is written in the application. This situation can be better understood with the aid of an example in which a user authentication can be denoted as an aspect that is created to ask the used for a login name and password. In this scenario, this routine can be automatically integrated into the software application all the way through the code wherever authentication mechanism is required. For instance, a client asks the software development team to add a requirement into the system. In this requirement a user needs to be authenticated before giving them permission to make any modification to personal details saved in a database.

However, the software development team can denote this requirement as an aspect by mentioning that the authentication code must be added before any call to routines that are used to make any change to personal details.

Afterward, this requirement can be further extended for

www.alliedjournals.com

Aspect Oriented Software Engineering authentication and verification methods required for all database updates. In fact, they can straightforwardly implement it by making minimal changes to the aspect. In order to perform this operation, the software development team just needs to modify the description of where the implementation of authentication code is required in the system. They do not need to go through the system searching for all events of these routine. As a result, there are less chances of making mistakes or errors and introducing unintentional security threats into a software application (Sommerville 566; Nakagawa, Ferrari and Sasaki).

In addition, the majority of researches carried out in the field of aspect oriented software engineering have mainly focused on aspect oriented programming. In this scenario, aspect-oriented programming languages have been developed with the intention of extending the scope of object-oriented programming in order to include aspects. At the present, a large number of organizations make use of aspect-oriented programming as an important part of their software development process. However, it is still a challenge to deal with crosscutting concerns at other stages of the software development process. In fact, the majority of researches is being carried out to examine how software engineers can make use of aspect-orientation in software design and requirements engineering, as well as how do they carry out a variety of testing techniques and verify aspect oriented programming (Sommerville 566; Nakagawa, Ferrari and Sasaki).

II. ASSOCIATED CONCEPTS A. What is a Concern?

Though the majority of software developers will be well aware of this term, however its appropriate definition is difficult to form. In simple words, in the context of aspect oriented software engineering, aspects also lie in the category of concern. In this scenario, an aspect is a characteristic of a software application that cannot be efficiently encapsulated in a generalized procedure for instance a method, object, API (application programming interface), or procedure. In the same way, an aspect can also be defined as a program characteristic that forces crosscutting in the development. In these definitions, a critical feature of some concerns seems common that allows partitioning of concerns difficult in traditional programming languages. A concern is normally defined as a base over software units. Additionally, this definition of concern does not only take into consideration the code aspect of software application but also properly focuses on the lifecycle. In addition, it is still based on software units.

In order to support and identify the scope of concerns to exceptional status in software development lifecycle, it is essential for software developers to define them autonomously of any explicit type of software artifact and even of software artifacts on the whole. However, according to a dictionary definition, a concern is defined as “a matter for consideration�. In the context of aspect oriented software engineering a concern can be any matter of interest related to a software application. Though, it does not seem like a specifically technical definition, however it is simple, open, and instinctive, and includes various definitions, and can be used in different contexts (Filman, Elrad and Clarke).

30

B. A view of Concerns Basically, a variety of concerns appear all the way through the system development lifecycle. In this scenario, these concerns can be used for different activities, purposes, formalisms, and artifacts linked with a number of stages of software development. Hence, software developers document a number of concerns, in different forms for requirements specification, design and architecture, programming, testing, and maintenance and evolution (Filman, Elrad and Clarke).

C. Need for concern modeling The majority of software development activities can be observed as modeling linked to concerns. In view of the fact that the primary focus of these activities is on other aspects such as requirements, design, architecture, implementation, etc. In addition, the modeling techniques that are presently utilized by software developers allow the modeling of a variety of kinds of concerns in different forms.

But, none of these modeling techniques models concerns as a whole or in the abstract. For instance, there is no technique that allows software developers to describe merely that performance is a major concern, though they allow software developers to define that attaining high performance from system is a major objective or to decide for an architectural style based on performance attributes (Filman, Elrad and Clarke).

D. Specification and Analysis of Concerns across the Development Lifecycle and Artifacts As discussed above, concerns, separately and jointly, occur all the way through the software development lifecycle as well as development artifacts. Hence, software development teams should be capable of identifying and analyzing concerns all the way through the development lifecycle and artifacts. The existence of concerns depends on the lifespan of a system. In view of the fact that concerns occur all the way through the system development, the system itself occurs from some concerns that preceded it, and these concerns occur before and after any demonstration they can have in the system or allied work artifact. In addition, concerns can also have various representations with respect to any specific formalism and artifact, and the significance of specific concerns marks software development approaches, stages and processes (Filman, Elrad and Clarke).

E. Crosscutting Concerns In object orientation based development approach, issues and objects can be separated by decomposing a system into entity based objects. In a perfect situation, each of these objects demonstrates the implementation of a particular concern. Though, in the past object-orientation has offered a very useful facility to attain this facility for instance using polymorphism, encapsulation, delegation and inheritance.

Unluckily, there are yet critical issues whose implementation will always become scattered all through diverse objects, in spite of selected decomposition in system based objects.

These issues and concerns are stated to cross-cut the other apprehensions. In this scenario, some of the common instances of crosscutting issues are synchronization strategies in multi-threaded technology based arrangement, error

www.alliedjournals.com

International Journal of Engineering, Management & Sciences (IJEMS) ISSN-2348 –3733, Volume-2, Issue-4, April 2015 handling, fault tolerance methods and a number of similar essential for a health record system that it maintains the issues (Brichau and D’Hondt; Sommerville). privacy of patient details, in this scenario, there can be a variety of concerns for instance one would be connected with All the above mentioned crosscutting issues encryption and other will be associated with access control. necessitate an implementation of the technique that is at least There are numerous diverse kinds of extension that are moderate and span over a number of other systems based assessed as the dissimilar kinds of issues (Brichau and modules. Additionally, these issues are challenging for the D’Hondt; Sommerville). reason that their implementations are tangled with other issues and scattered all the way through the entire system 1. Secondary functional extensions. These features are used to implementation. The tangling of the applications smashes the add extra functionalities to the functionality that is being standard of division of concerns since a single system module integrated into the core system. For example, in case of a holds the application of more than one issue. In this scenario, medical information system, the creation of reports on the it further raises a variety of issues for instance, making the drugs approved in the earlier month would be a secondary understanding of code difficult, hindering reuse of the functional extension (Brichau and D’Hondt; Sommerville). particular issues as well as making them difficult to develop.

The distribution of the illustration of a crosscutting issue all 2. Policy extensions: These features are used to add functional through the entire application development and design, capabilities with the purpose of supporting organizational minimize it mainly hard to develop for the reason that all policies. In this scenario, extensions that add security features modules that are crosscut required to be developed. On the can be very useful instances of policy extensions (Brichau and other hand, the lack of a clear demonstration as well as D’Hondt; Sommerville). modularization of crosscutting system development issues further make it unfeasible to reuse them in other system 3. QoS (quality of service) extensions: As its name indicates, applications. This is precisely the issue that could be managed these features are used to add functional potential in order to through aspect oriented system development approach. fulfill and attain the QoS related requirements that have been Aspect oriented system engineering openly demonstrates specified for the system. For instance, there will be an crosscutting issues as separate system entities, resolving a lot extension which can require the implementation of a cache to of the related evolution and reusability issues (Brichau and with the purpose of reducing the number of accesses to a database or automatic backups for resuming in the case of a D’Hondt; Sommerville). system collapse (Brichau and D’Hondt; Sommerville).

III. ASPECTS IN SOFTWARE ENGINEERING 4. Infrastructure extensions: These features are used to add The basic purpose behind the development of functional support related to some specific implementation aspects was to provide support as a programming language platforms. In case of a human resource system, an extension to construct however, this term is basically derived from the infrastructure can be employed to provide an interface to the system development requirements. Consequently, it seems to primary DBMS. In addition, in order to implement changes to be logical to accept and put into practice an aspect oriented this interface will require software development team to make software development method at all software development changes to the related infrastructure extensions (Brichau and phases of the software development process. In fact, the D’Hondt; Sommerville; Bradley). adoption of an aspect oriented software development approach at the initial phases of software development outlines the notion of untying concerns as a foundation REFERENCES intended for identifying and prioritizing the requirements and [1] G G Bradley, Jeremy T. An Examination of Aspect-Oriented the software design. In this scenario, understanding as well as Programming in Industry. Technical Report CS-03-108. Fort Collins, modeling concerns should be an important element of the Colorado, USA: Department of Computer Science, Colorado State University, 2003. software development process like in requirements engineering process and system design areas. Aspect oriented [2] Brichau, Johan and Theo D’Hondt. Aspect-Oriented Software Development (AOSD)An Introduction.

2010. approach regarding software development and programming http://www.info.ucl.ac.be/~jbrichau/courses/introductionToAOSD.pd languages then offer the technological support for f. 05 October 2013. maintaining the separation of concerns in our systems [3] Filman, Robert E., et al. Aspect-Oriented Software Development. New York: Addison-Wesley Professional, 2004. implementation (Brichau and D’Hondt; Sommerville; [4] Garcia, Alessandro, et al. "Aspects in agent-oriented software Bradley). engineering: lessons learned." AOSE'05 Proceedings of the 6th The foundation system is a group of system characteristics that is responsible for implementing the necessary features of software. Consequently, if the basic intention of a specific software is to store and maintain information of hospital’s patients, then the fundamental system should offer an approach of developing, editing, handling and connecting a database of health record. If some changes are made to the fundamental system it will reproduce additional stakeholder related issues, those have to be incorporated into the foundational system. For instance, it is

31

[5] [6] [7]

international conference on Agent-Oriented Software Engineering.

Berlin, Heidelberg: Springer-Verlag, 2005. 231-247.

Nakagawa, Elisa Y., et al. "An aspect-oriented reference architecture for Software Engineering Environments." Journal of Systems and Software, Volume 84 Issue 10 (2011): 1670-1684.

Sommerville, Ian. Software Engineering, 9th Edition. New York: Addison-Wesley, 2010.

Wampler, Dean. Aspect-Oriented Design Principles: Lessons from Object-Oriented Design. 2007. http://aosd.net/2007/program/industry/I6-AspectDesignPrinciples.pdf . 08 October 2013.

www.alliedjournals.com