Aspect oriented programming
computer science crazy|
Joined: Dec 2008
24-02-2009, 01:55 AM
Object-oriented programming (OOP) has been presented as a technology that can fundamentally aid software engineering, because the underlying object model provides a better fit with real domain problems. However most software systems consist of several concerns that crosscut multiple modules. Object-oriented techniques for implementing such concerns result in systems that are invasive to implement, tough to understand, and difficult to evolve. This forces the implementation of those design decisions to be scattered throughout the code, resulting in tangled code that is excessively difficult to develop and maintain. The new aspect-oriented programming (AOP) methodology facilitates modularization of crosscutting concerns. Using AOP, you can create implementations that are easier to design, understand, and maintain. Further, AOP promises higher productivity, improved quality, and better ability to implement newer features. AOP helps overcome the aforementioned problems caused by code tangling and code scattering. Here are other specific benefits AOP offers: Modularized implementation of crosscutting concerns: AOP addresses each concern separately with minimal coupling, resulting in modularized implementations even in the presence of crosscutting concerns. Such an implementation produces a system with less duplicated code. Since each concern s implementation is separate, it also helps reduce code clutter. Further, modularized implementation also results in a system that is easier to understand and maintain. Easier-to-evolve systems: Since the aspected modules can be unaware of crosscutting concerns, it s easy to add newer functionality by creating new aspects. Further, when you add new modules to a system, the existing aspects crosscut them, helping create a coherent evolution. Late binding of design decisions: Recall the architect s under/overdesign dilemma. With AOP, an architect can delay making design decisions for future requirements, since she can implement those as separate aspects. More code reuse: Because AOP implements each aspect as a separate module, each individual module is more loosely coupled. For example, you can use a module interacting with a database in a separate logger aspect with a different logging requirement. In general, a loosely coupled implementation represents the key to higher code reuse. AOP enables more loosely coupled implementations than OOP.
Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
Joined: Apr 2012
19-06-2012, 04:43 PM
ASPECT ORIENTED PROGRAMMING
ASPECT ORIENTED PROGRAMMING.docx (Size: 717.17 KB / Downloads: 25)
In software engineering, the programming paradigms of Aspect- Oriented
programming (AOP), and Aspect- Oriented Software development (AOSD) attempt to aid programmers in the separation of concerns, specifically cross-cutting concerns, as an advance in modularization. AOP does so using primarily language changes, while AOSD uses a combination of language, environment, and method. Separation of concerns entails breaking down a program into distinct parts that overlap in functionality as little as possible. All programming methodologies including procedural programming and object-oriented programming support some separation and encapsulation of concerns (or any area of interest or focus) into single entities.
Aspect Oriented Programming (AOP) is a promising new technology for separating crosscutting concerns that are usually hard to do in object-oriented programming . Now-a-days, object-oriented programming (OOP) has become the mainstream programming paradigm where real world problems are decomposed into objects that abstract behavior and data in a single unit.OOP encourages software re-use by providing design and language constructs for modularity, encapsulation, inheritance, and polymorphism. Although OOP has met great success in modelling and implementing complex software systems, it has its problems. Practical experience with large project and implimentations has shown that programmers may face some problems with maintaining their code because it becomes increasingly difficult to cleanly separate concerns into modules.
GOALS OF AOP
Aspect-oriented programming (AOP) better separates concerns than previous
methodologies, thereby providing modularization of crosscutting concerns.
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. 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. Polymorphisms provided a common behavior and interface for related concepts, and allowed more specialized components to change a particular behaviour without needing access to the implementation of base concepts.
CROSS- CUTTING CONCERNS
Separation of concerns entails breaking down a program into distinct parts that overlap in functionality as little as possible. All programming methodologies including procedural programming and object-oriented programming support some separation and encapsulation of concerns (or any area of interest or focus) into single entities. For example, procedures, packages, classes, and methods all help programmers encapsulate concerns into single entities. But some concerns defy these forms of encapsulation. Software engineers call these crosscutting concerns, because they cut across many modules in a program.
An example of crosscutting concerns is "logging," which is frequently used in distributed applications to aid debugging by tracing method calls. Suppose we do logging at both the beginning and the end of each function body. This will result in crosscutting all classes that have at least one function.