This preview shows pages 1–3. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: Technoplexus ASPECT - ORIENTED PROGRAMMING TECHNOPLEXUS08 KAKATIYA INSTITUTE OF TECHNOLOGY AND SCIENCE Author: K. Ratna Kumar III/IV BTECH (IT) Email : firstname.lastname@example.org Phno:9966024273 R.V.R & J.C.COLLEGE OF ENGINEERING (Approved by A.I.C.TE) (Affiliated to Acharya Nagarjuna University) Chandramoulipuram : Chowdavram GUNTUR - 19 Aop Technoplexus Abstract The goal of this work is to make it possible for programs to clearly capture all of the important aspects of a systems behavior, including not only its functionality, but also issues such as its failure handling strategy, its communication strategy, its coordination strategy, its memory reference locality, etc. Our current work is based on the belief that programming languages based on any SINGLE abstraction framework-procedures, constraints, whatever-are ultimately inadequate for many complex systems. The reason is that the different aspects of a systems behavior that must be programmed, each tend to have their own natural form, so while one abstraction framework might do a good job of capturing one aspect, it will do a less good job capturing others. This conclusion has led us to develop a concept we call Aspect-Oriented Programming (AOP). 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. 1 . Cross -Cutting The basic limitation of single abstraction framework languages is that one abstraction will not necessarily serve well for all the different issues that must be programmed in a specific system. A classic example is the notion of invariant relations among objects. While many standard object-oriented languages do a good job of clearly capturing the behavior of objects, they do a less good job of capturing structural and behavioral invariants, such as when this object gets a pop message, send this other object a refresh message. Many linguistic mechanisms have been developed to deal with special cases of this problem (i.e. before/after methods), but a great deal of the complexity in real world code still appears to come from cases where the language fails to provide adequate support for a secondary, but still important, aspect of a systems behavior. Some cases of this problem can be dealt with by isolating one issue in one part of the code, and another issue in another part of the code. This is often done using some form of procedure abstraction. For example, the details of memory allocation can be hidden behind the malloc/ free interface, the client code only attends to what to do with the objects....
View Full Document
This note was uploaded on 03/26/2011 for the course IT 101 taught by Professor Dontknow during the Spring '07 term at Northern Virginia.
- Spring '07