Aspect-Oriented Software Engineering - Research Paper Example

Aspect-Oriented Software Engineering 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. Overview 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 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 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). Associated Concepts 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). 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). 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). 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). 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 handling, fault tolerance methods and a number of similar issues (Brichau and D’Hondt; Sommerville). All the above mentioned crosscutting issues necessitate an implementation of the technique that is at least moderate and span over a number of other systems based modules. Additionally, these issues are challenging for the reason that their implementations are tangled with other issues and scattered all the way through the entire system implementation. The tangling of the applications smashes the standard of division of concerns since a single system module holds the application of more than one issue. In this scenario, it further raises a variety of issues for instance, making the understanding of code difficult, hindering reuse of the particular issues as well as making them difficult to develop. The distribution of the illustration of a crosscutting issue all through the entire application development and design, minimize it mainly hard to develop for the reason that all modules that are crosscut required to be developed. On the other hand, the lack of a clear demonstration as well as modularization of crosscutting system development issues further make it unfeasible to reuse them in other system applications. This is precisely the issue that could be managed through aspect oriented system development approach. Aspect oriented system engineering openly demonstrates crosscutting issues as separate system entities, resolving a lot of the related evolution and reusability issues (Brichau and D’Hondt; Sommerville). Aspects in Software engineering The basic purpose behind the development of aspects was to provide support as a programming language construct however, this term is basically derived from the system development requirements. Consequently, it seems to be logical to accept and put into practice an aspect oriented software development method at all software development phases of the software development process. In fact, the adoption of an aspect oriented software development approach at the initial phases of software development outlines the notion of untying concerns as a foundation intended for identifying and prioritizing the requirements and the software design. In this scenario, understanding as well as modeling concerns should be an important element of the software development process like in requirements engineering process and system design areas. Aspect oriented approach regarding software development and programming languages then offer the technological support for maintaining the separation of concerns in our systems implementation (Brichau and D’Hondt; Sommerville; Bradley). 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 essential for a health record system that it maintains the privacy of patient details, in this scenario, there can be a variety of concerns for instance one would be connected with encryption and other will be associated with access control. There are numerous diverse kinds of extension that are assessed as the dissimilar kinds of issues (Brichau and D’Hondt; Sommerville). 1. Secondary functional extensions. These features are used to add extra functionalities to the functionality that is being integrated into the core system. For example, in case of a medical information system, the creation of reports on the drugs approved in the earlier month would be a secondary functional extension (Brichau and D’Hondt; Sommerville). 2. Policy extensions: These features are used to add functional capabilities with the purpose of supporting organizational policies. In this scenario, extensions that add security features can be very useful instances of policy extensions (Brichau and D’Hondt; Sommerville). 3. QoS (quality of service) extensions: As its name indicates, these features are used to add functional potential in order to fulfill and attain the QoS related requirements that have been specified for the system. For instance, there will be an extension which can require the implementation of a cache to with the purpose of reducing the number of accesses to a database or automatic backups for resuming in the case of a system collapse (Brichau and D’Hondt; Sommerville). 4. Infrastructure extensions: These features are used to add functional support related to some specific implementation platforms. In case of a human resource system, an extension to infrastructure can be employed to provide an interface to the primary DBMS. In addition, in order to implement changes to this interface will require software development team to make changes to the related infrastructure extensions (Brichau and D’Hondt; Sommerville; Bradley). Works Cited Bradley, Jeremy T. An Examination of Aspect-Oriented Programming in Industry. Technical Report CS-03-108. Fort Collins, Colorado, USA: Department of Computer Science, Colorado State University, 2003. Brichau, Johan and Theo D’Hondt. Aspect-Oriented Software Development (AOSD)- An Introduction. 2010. http://www.info.ucl.ac.be/~jbrichau/courses/introductionToAOSD.pdf. 05 October 2013. Filman, Robert E., et al. Aspect-Oriented Software Development. New York: Addison-Wesley Professional, 2004. Garcia, Alessandro, et al. "Aspects in agent-oriented software engineering: lessons learned." AOSE'05 Proceedings of the 6th 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. Read More