February 2018, Volume 5, Issue 2 JETIR (ISSN-2349-5162) JETIR1802156 Journal of Emerging Technologies and Innovative Research (JETIR) www.jetir.org 902 ASPECT ORIENTED PROGRAMMING: A TOOL TO HANDLE CROSS-CUTTING CONCERNS IN MODULARIZATION MECHANISM Dr. Mahua Banerjee Department of Information Technology, Xavier Institute of Social Service, Ranchi, Abstract: Traditional programming languages limit the level of modularity which is essential for creating evolvable software. Some requirements, features, properties cannot be modularized. The code related to these concerns is then scattered and tangled. Such concerns are called cross-cutting concerns which results in difficulties for modularization. AOP aims at modularizing crosscutting concerns into a new kind of module, called aspect. In AOP, non cross-cutting concerns are programmed in a base programming language. Cross-cutting concerns are expressed as aspects. The aspects are then woven into the base program with an aspect weaver which restricts scattering and tangling. Keywords: Aspect-oriented programming, join-point, pointcut, advice, Inter type declarations 1. INTRODUCTION This paper focuses on analyzing the role of cross-cutting concerns in software development. Aspect Oriented Programming (AOP) is a novel paradigm which aims at separating and modularizing cross-cutting concerns by means of a new kind of module known as aspects. Many of the current approaches to software engineering view the development process as being an evolutionary cycle that continues throughout the lifetime of a piece of software. This is in contrast to the classical waterfall approach where the stages of development are partitioned into a strict chronological order that begins with requirements gathering and ends with deployment and maintenance. Under the evolutionary approach software artifacts undergo continual revision and expansion as new requirements are discovered, bugs are found and the external environment changes. One of the primary goals of software engineering is to assist developers in dealing with this dynamic environment, where a large part of their work is to change existing code rather than to write new code. One of the ways in which this can be done is through better separation of concerns. Programming languages provide mechanisms for dividing programs into modules that represent particular design decisions, features or pieces of functionality which can be generally referred to as concerns. Modularizing concerns helps during evolution because developers do not have to deal with the program in its entirety every time they want to make a change. They can focus on just the modules that relate to their task and the compiler can provide some assurances that implementation details will not have far reaching effects. Modules also provide a means for encapsulating generic functionality so that code can be reused across multiple projects [1]. However, not all concerns can be easily modularized. When a designer chooses a decomposition of a program into modules, he or she does so with the intent of making the expected evolution tasks easier for developers to perform. In practice, finding a decomposition that supports all required evolution tasks is often impossible. In some cases this is due to new requirements or environmental changes that could not have been predicted and so were not planned for. In other cases the programming language used to implement the software does not provide adequate means to modularly express the tangled web of interactions that exist between all the relevant concerns. This leads to the existence of concerns whose implementations are scattered across multiple modules. This mismatch between the chosen decomposition and the required programming tasks is often referred to as the tyranny of the dominant decomposition and is one of the main motivations for aspect-oriented programming (AOP) [2]. Aspect-oriented programming builds on top of object-oriented programming by introducing new forms of modularity. AOP languages provide more flexibility in choosing decomposition through the use of aspects which define both state and behaviour that can be woven into the object- oriented structure of a program [3]. While this improves the coverage of decompositions over evolution tasks, it does not provide a complete solution because there is still only a single decomposition available. AOP approaches make it easier to modularize concerns that were previously scattered amongst object-oriented classes. At the same time they tend to scatter the implementation of classes across aspects. This makes some tasks easier to perform at the expense of making others more difficult. 2. Literature Review A number of studies will be reviewed in this section to offer a literature overview about the concepts of AOP and its relevance in modular programming. 2.1 CONCERNS AND ASPECTS Object-Oriented Programming (OOP) is probably the most commonly used programming paradigm today. The evolution from assembler language to current software engineering paradigms reflects the will for better readability and re-usability—or, more generally, better organization— in designing applications. Functional, procedural and object-oriented programming languages have a common way of abstracting and separating out concerns: they rely on explicitly calling subprograms (subroutines, procedure, methods, etc.) that represent functional units of the system. However, not all concerns can be encapsulated properly in a functional decomposition. For example, tracing and logging are concerns that are usually distinct from the functional units they are related to (i.e. the units whose behavior is traced or logged). As a result, they