Aspect Oriented Program Design in Distributed Application

467

Aspect Oriented Program Design in Distributed

Application

Ravi Uyyala, Kundan Kumar Mishra

Dept.of Computer Science And Engineering, BM College of Technology, Indore,India Dept.of Computer Science And Engineering,BM college of Technology, Indore, India

[email protected] [email protected]

Abstract: Aspect Oriented Programming is changing the way software is developed in various domains of computing and software Engineering. In this project we discuss the main characteristics of Aspect oriented program (AOP) with a particular focus on distributed systems. Our experiments support the hypothesis that the use of Aspect oriented program will result in a better separation of concerns and thus in better maintainability and portability of such systems (in comparison with a classical object oriented program development approach). Classical object oriented program is not allowing the separation of concerns but here in aspect oriented program is allowing the separation of cross cutting concerns. Aspect oriented programming (AOP) is a programming paradigm that increases modularity by allowing the separation of cross-cutting concerns. Separation of concerns leads to breaking down a paradigm into distinct parts called concerns. We focus mainly, in this project, is designing the Aspect oriented program with a particular focus on distributed application. The use of Aspect oriented program will result in a better separation of concerns and thus in better maintainability and portability of distributed applications.

Keywords: Aspect oriented program(AOP),Object Oriented Program(OOP),Aspetctj, Aspect oriented software development (AOSD), Aspect Oriented Design(AOD), Unified Modeling Language(UML).

I.

I

NTRODUCTION

Aspect oriented programming (AOP) is a programming paradigm that increases modularity by allowing the separation of cross-cutting concerns. These concerns are very important things in the program. We focus mainly, in this project, is designing the AOP with a particular focus on distributed systems. The use of AOP will result in a better separation of concerns and thus in better maintainability and portability of such systems. When dealing with AOP it is necessary to distinguish between crosscutting concerns and core concerns.

A. Cross cutting concerns and Core concerns

Logging, security, policy enforcement, pooling, caching, authentication, authorization and transactional management are some crosscutting concerns that can typically be dealt by means of AOP. Core concerns capture the central functionality of individual modules. It is the core part of the program towards aspect oriented programming and design (AOP). AOP will improve the software modularity by separating the concerns. Aspects are the key concept of AOP.

468

OOP

AOP

Fig1. Differences between OOP and AOP II. ASPECTS IN DISTRIBUTED SYSTEMS

Generally speaking, a distributed system is a collection of independent systems that appears to its users as a single coherent system. Important issues that we need to consider when dealing with such systems are: communication, processes, naming, synchronization, consistency and replication, fault tolerance, integrity and security. Distributed computer systems are characterized by a substantial amount of complexity and a strict preservation of modularity. In particular fault tolerance, fault detection, and eliminating the central point of failures, are examples of concerns that are not easily addressed. But these issues tend to span multiple components in distributed applications.

However, they may be addressed with aspects, but with caution. In this paper we have discussed about logging, security, synchronization, consistency, communication aspects.

III. LITERATURE REVIEW

The central idea is that aspects enable the modular representation of crosscutting concerns. A concern is a dimension in which a design decision is made, and is crosscutting if it cannot be realized in traditional object-oriented designs except with scattered and tangled code. Aspect oriented design (AOD) research is fragmented. Barriers to AOD adoption are, due to the fragmented nature of AOD research. There have been many approaches to Aspect Oriented Design (AOD). Each approach attempts to capture and address a significant issue or issues relating to crosscutting in design.

A. Aspect oriented software development (AOSD). In the early days of computer science, developers wrote programs by means of direct machine-level coding. Unfortunately, programmers spent more time thinking about a particular machine's instruction set than the problem at hand. Slowly, we migrated to higher-level languages that allowed some abstraction of the underlying machine.

Cu

tting concerns Original application

classes

Modified application classes

Changes to cross cutting Cutting concerns

Modified aspects Original application

classes

Aspects

Modified

469

Then came structured languages, we could now decompose our problems in terms of the procedures necessary to perform our tasks. However, as complexity grew, we needed better techniques. Object oriented programming (OOP) let us view a system as a set of collaborating objects.

Classes allow us to hide implementation details beneath interfaces. Currently, OOP serves as the methodology of choice for most new software development projects. Indeed, OOP has shown its strength when it comes to modeling common behavior. However, OOP does not adequately address behaviors that span over many often unrelated modules. Separation of concerns is a basic engineering principle that is also at the core of object-oriented analysis and design methods in the context of UML. Separation of concerns can provide many benefits: additive, rather than invasive, change, improved comprehension and reduction of complexity, adaptability, customizability, and reuse. In contrast, AOP methodology fills this void. AOP quite possibly represents the next big step in the evolution of programming methodologies.

B. Aspect Oriented Program and Design.

A gap exists between requirements and designs on one hand and between design and code on the other hand. Aspect oriented programming (AOP) extended to the modeling level where aspects could be explicitly specified during the design process will make it possible to weave these aspects into a final implementation model. Another step could be extension of AOP to the entire software development cycle. Each aspect of design and implementation should be declared during the design phase so that there is a clear traceability from requirements through source code thus using UML as the design language to provide an aspect oriented design environment. The separation and encapsulation of crosscutting concerns has been promoted as a means of addressing these difficulties, the standard object-oriented paradigm does not suffice. In order to overcome the difficulties for crosscutting concerns throughout the lifecycle, an approach is required that provides a means to separate and encapsulate both the design and the code of crosscutting behavior.

IV.

M

OTIVATION

In traditional software development common concerns are identified and used to modularize a program. Aspect oriented program development adds crosscutting concerns to address those features that cut across modules. Commonly cited examples are logging and security concerns .

Measurement of object oriented software has been given a fundamental philosophical basis . Implementation of a distributed application requires distribution of modular components among location. Conventional Object-Oriented Programming (OOP), doesn‟t offer easy way of changing the design decision about distribution, because of tangled code (code with different concerns interlacing to each other) and scattered code (code regarding one concern spread in several units of the system). AOP offers an appealing approach since it allows the design decisions regarding different distributions policies to be specified separately, making it easy to design them and to switch from one to another

.

V.

S

EPARATION OF

A

SPECTS

The object oriented program can sometimes separate the concerns in an intuitive manner by grouping concerns into object. The Building of distributed applications involves many different concerns application functionality, distribution structure, tolerance for partial failure, security and so forth. Aspect-oriented software development (AOSD) is a new technique that improves separation of concerns in software development. AOSD makes it possible to modularize crosscutting concerns of a software system. Thus making it easier to maintain and evolve. AOSD can lead to better quality software, but it does not provide the correctness by itself. An aspect-oriented design can lead to better system architecture, and an aspect-oriented programming language enforces a disciplined coding style, but they do not protect against mistakes made by programmers during the system development. In addition, Aspect oriented programming can introduce specific (and hard to detect) errors that ordinary object-oriented programming is not subject to. As a result, software testing remains an inevitable and important task in AOSD. When we treat an aspect as a unit and intend to test its aspectual behavior unit test for an aspect are created to test in isolation pieces of advice defined in the aspect.

VI. IMPLEMENTATION DETAILS AND RESULT

470

The key purpose of an AOP language is to specify structured runtime transformations on a program. The transformations Involve the dynamic insertion (or removal) of runtime code at (before or after) well-defined program points. The most common locations for such „on the fly‟ code modifications are function or procedure calls. AspectJ is a popular and well established AOP language that provides support for specifying and composing crosscutting code into a core system.We have used aspectj to separate the concerns in this application. In this application we have to written java classes and aspects to modularize the concerns.First we have downloaded the Aspectj tool and plug-ins of the aspectj. Already it is supporting the eclipse initiation so we have used that flexibility in our AspectJ program. After initiated Aspectj in eclipse we have modeled and implemented aspects in the aspectj tool. Join points are the key points in the program. And point cuts are the crosscutting concerns in the aspects. Collection of join points in the program is called point cuts. Advices are three types 1.before advice 2.after advice.3.around advice. These can be explained in the application. These advices are used whenever point cut wants some code to be executed.

VII.

AOP

M

ODELLING OF

S

YNCHRONIZATION

A. Synchronization

Synchronization is timekeeping which requires the coordination of events to operate a system in unison. Systems operating with all their parts in synchrony are said to be synchronous. Some systems maybe only approximately synchronized.

B. Process synchronization

Refers to the idea that multiple processes are to join up or handshake at a certain point, so as to reach an agreement or commit to a certain sequence of action.

C. Data synchronization

Refers to the idea of keeping multiple copies of a dataset in coherence with one another Process synchronization primitives are commonly used to implement data synchronization. So Synchronization is the important aspect in the distributed system. We should modify the content after doing some operation on the data base. That has to visible to all other customers.

D. Coordinator

471

<<

point cuts>>

Fig:2 AOP modelling of bank application Agent#1

Communication aspect/concern

Persistence Persist()

Agent#2 Security aspect

Security admin Login, account number

Access control Authenticate user Password ()

Role Operations

User Customer ()

Agent#3

Consistency _Aspectj

(It is a tool

)

Compiler Execution

Agent#4

Synchronization aspect

Locator Coordinator

Consistency Persistence

Availability

Security policies

472

Fig:3. Aop modeling of synchronization

VIII.

S

ECURITY AS AN

A

SPECT

Security is a very important concern. Modelling of Security Policies Using AOP is to compose different security policies in a system. Apply decomposition techniques normally used for separation of concerns to security policies. Using AOP, we can separate a good large chunk of these concerns from the code base. There will be some cases where centralization is not possible (e.g. very specific error handling), AOP allows developers to concentrate on these type of problems

A Access control

Access control is to prevent unauthorized agents to access services from hosts that do not grant permission for accessing such hosts. This is done by first applying proper access control mechanisms, which require the host or agent to mutually authenticate each other before any transaction is initiated between the two. An agent that has access to the platform and its resources, services without proper authorization does have the potential to harm

other agents on the platform and the host itself. A platform that hosts agents from very many organizations must look into the authorization process with much care. It is worth mentioning that we focus on the agents that can directly interfere with the public services of host or the platform like attempting buffer overflow and reset to the initial state and so on. We are not concerned about the situations where an agent accesses the data or code of other agents.

B. Security administrator

It is the concern that is checking whenever a new user is enters into the protocol. Security administrator is associated with access control C. User

User is the customer he will perform operations like adding some constraints or deleting some other constraints. He will perform correct operations or incorrect operations. He has to login and perform the operation. He has to maintain the secure password and Account number.

Persistence

Consistency <Aspect>

Connection/ Disconnection

Availability

Security policies Coordinator

<Aspect>

473

Fig4: Aop modeling of security

IX. BASIC

M

ECHANISM OF

A

SPECT

J

In AspectJ programs, Java classes are used to implement the core characteristics, and aspects (understandable as pseudo classes) are used to implement crosscutting concerns in a modular fashion. In an AspectJ application, everything revolves around join points. These are points in the control flow graph of a compiled program, where crosscutting concerns are woven in. According to AspectJ‟s terminology there are two types of Static crosscutting describes crosscutting that influence the interfaces of the involved types and does not modify the execution behavior of the system. Aspectj provides the following two mechanisms to achieve this kind of influence. Introduction introduces changes to the classes, aspects and interfaces of the system. Compile-time Declaration adds compile time warnings and error messages for the case that certain occurrences of patterns are captured.

A.Join points and Point cuts.

In all aspect-oriented programming languages, aspects can only be invoked at some well defined and principled points in the program‟s execution. These points are referred to as join points and the possible kinds of join points are described in a join point model. A point cut is indeed often expressed using a set of dedicated predicates that reason about the entire possible set of join points in a software application to determine the correct set of join points for a specific aspect.

B.Advice

We mentioned that the aspect‟s advice code (the aspect functionality code) is not substantially different from other code, Nevertheless, there are some interesting issues.

While many aspect languages feature advice code segments that basically can contain the same kind of procedural source code as standard functions or methods in that language, there are aspect languages where the advice code is expressed in a different language or even in a different paradigm.

Security <aspect>

users <aspect

>

Persistence

<aspect>

Access control <aspect>

474

As we explained in the above discussions in the bank system we have used so many aspects in the Aspectj. Some (not all) of the Join points, Point cuts, Advices

that are used in bank system are illustrated in following examples.

Example1:

Aspect AccountPolice { This is one of the Aspect

pointcut goingOverdrawn(Account acct,double amount): This is the point cut of execution(* debit(..)) && this(acct) && going overdrawn balance

args(amount) && if((acct.getBalance()-amount<0));

before(Account acct) : goingOverdrawn(acct,*) { Here we need a before advice System.err.println( in front of the point cut going "Account "+acct.getAccountNumber()+ overdrawn balance

" is going overdrawn"); }

}

Example2:

public aspect FindingMathematicalOperations { This aspect defines the operations

pointcut addOperation(): call(void performAdd()); these all are pointcuts pointcut subtractOperation(): call(void performSubtract()); different operations.

pointcut multiplyOperation(): call(void performMultiply()); pointcut divideOperation(): call(void performDivide());

pointcut mathematicalOperation():

addOperation() || subtractOperation() || multiplyOperation() || divideOperation();

475

X.

A

NALYSIS OF BANK SYSTEM BY USING

AOP

We have developed by this application by using the AOP approach

A.Anonyms

Actors are the users of the system being modeled. Each Actor will have a well-defined role, and in the context of that role have useful interactions with the

system.A person may perform the role of more than one Actor, although they will only assume only one role during one use case interaction. An Actor role may be performed by a non-human system, such as another computer program.

B. Actors

C. Admin

Analyzes each

customer Makes _transactions

Analysis of all

customers

Views accounts details

Changes options Create

new account

Prints customer balances

The System

476

Analysis of all customers: The administrator will analyze all the customer details. He can view the customer grades

based on the transactions done by the customer.

Analyzes each customers :The administrator will analyze the each and every customer‟s transaction data and gets the details about the transaction data. Like customer grading, and transaction details

Changes options:The options will enable the user to change the application theme, background color etc., Makes Transaction: The user will make transactions like, deposit, withdraw and delete account.

Prints customer balance: The user will print the customer balance based on the transactions done by the customer.

View accounts details: The user will view the account details by person or one by one.

Create new account: The user will click on new account creation to create a new account in the banking system.

Some of the results we got by using the AOP in banking Application

477

This is showing file options

In this we can open new account, we can print customer balance, and we can quit from the data banking application.

This is showing edit options

In this edit options we can deposit, withdraw money, we can delete customer, and we can search by no and by name.

This is showing view options

In this view options we can view one by one customer or we can view all customers at a time

This is showing analysis options

478

XI.

A

DVANTAGES AND

D

ISADVANTAGES OF

AOP

AOP promotes clear design and reusability by enforcing the principles of abstraction and separation of concerns. AOP explicitly promotes separation of concerns, unlike earlier development paradigms. This separation of concerns provides cleaner assignment of responsibilities, higher modularization and easier system evolution, and should thus lead to software systems which are easier to maintain. The process is to collect scattered concerns into compact structure units, namely the aspects. On the other hand, AOP cannot be elegantly applied to every possible problem situation: AOP is mostly suited for large scale software development projects, in distributed systems. However it brings with it certain difficulties as far as testing and debugging are concerned. This is due to the side effects which stem from the dynamic (ad-hoc) injection of runtime code and which could, in the worst case, lead to semantic ambiguities in the control-flow of an aspect oriented program. Different aspects can actually interfere at the same points of in-weaving. Thus, AOP can violate the principle of encapsulation, although in a rather systematic and well-controlled way.

XII.

C

ONCLUSION

In AOP, the different aspects of a systems behavior are each programmed in their most natural form, and then these separate programs are woven together to produce executable code. Our work on AOP is being carried out in the context of both general-purpose and domain specific languages, we believe that it has contributions to make to both areas. The goal of Aspect-Oriented Programming (AOP) is to make it possible to deal with crosscutting aspects of a systems behavior as separately as possible. We want to allow programmers to first express each

of a

system‟s aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form using a tool called an Aspect Weaver or Aspectj.

XIII.

F

UTURE WORK

Investigation of aspects in distributed systems has been done at a conceptual level. The actual implementation of this approach will follow in one more step, and also further work is needed to re-design distributed computing to make use of aspects. As part of an industrially oriented project, the

distributed computing to be augmented with parallel algorithms. The new system will be known as parallel distributed systems. These algorithms require high speed computing and a framework for execution in parallel. Algorithms of this nature are also environment dependant and functionality is required to determine the best algorithm for a given environment. Based on discussion in this project and aspects in distributed systems, there is a place for investigation to incorporate aspects in distributed systems. Aspects are emerging in others research areas as well, such as aspects in concurrency, aspects in operating systems, Aspects in databases and aspects for composition of web services.

References

[1].Dabke, P, “Enterprise Integration via CORBA-Based Information Agents”, IEEE Internet Computing 3, September 1999, pp. 49–57.

[2].Aksit M and M. Bergmans, “Composing Synchronization and Real-Time Constraints”, “Journal of Parallel and S distributed Computing36”, 1996, pp. 32-52,

[3]Siobhan Clarke and Robert J. Walker, “Towards a Standard Design Language for AOSD,” ACM Proceedings on Aspect Oriented Software Development, April 2002, pp. 113-119

[4]. V. Basili,”The role of experimentation”,Past, current, and future. In Proceedings of the 18th International Conference on Software Engineering, Mar. 1996, pp. 442–450

[5].A. Black, N. Hutchinson, E. Jul, and H. Levy. “Object structure in the Emerald system”. ACM SIGPLAN Notices,21(11), Nov. 1986, pp.78–86.

[6].D. Boehm-Davis, R. Holt, and A. Schultz, “The role of program structure in software maintenance”,

International Journal of Man-Machine Studies, 36(1), Jan. 1992, pp.21–63

[7]. B. Curtis, E. Soloway, R. Brooks, J. Black, K. Ehrlich, and H. Ramsey, “Software psychology”, “The need for an interdisciplinary program”, Proceedings of the IEEE, 74(8), Aug. 1986, pp. 1092–1106.

[8].Ball, T., and Larus, J., “Optimally Profilling and Tracing Programs”, ACM Transactions on Programming Languages and Systems, Vol 16, no. 4, July 1994, pp 1319 – 1360.

[9] .Tikir MM, Hollingsworth JK.,“Efficient instrumentation for code coverage testing.”, ACM. Sigsoft Software Engineering Notes, vol.27, no.4, July 2002, pp.86-96. USA.

479

15.Author’s profile

Name: Ravi Uyyala.

Email:[email protected].

Qualification: B.E(CSE), MTECH(CSE) . Papers accepted: 3

Name: Kundan Kumar Mishra