Aspect-oriented programming Laura Ricci A.A. 2001-2002.

Slides:



Advertisements
Similar presentations
Aspect Oriented Programming. AOP Contents 1 Overview 2 Terminology 3 The Problem 4 The Solution 4 Join point models 5 Implementation 6 Terminology Review.
Advertisements

1 JAC : Aspect Oriented Programming in Java An article review by Yuval Nir and Limor Lahiani.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 32 Slide 1 Aspect-oriented Software Development.
Introduction To System Analysis and Design
7M701 1 Software Engineering Object-oriented Design Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 12 )
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
SMM5101 (ADVANCED MULTIMEDIA PROGRAMMING) Review of Multimedia Programming.
ASPECT ORIENTED SOFTWARE DEVELOPMENT Prepared By: Ebru Doğan.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Software Engineering Module 1 -Components Teaching unit 3 – Advanced development Ernesto Damiani Free University of Bozen - Bolzano Lesson 2 – Components.
1 Computer Systems & Architecture Lesson 1 1. The Architecture Business Cycle.
1 A Student Guide to Object- Orientated Development Chapter 9 Design.
Course Instructor: Aisha Azeem
Chapter 10: Architectural Design
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Software Product Line Architectures (SPLA) Nipun Shah
Domain-Specific Software Engineering Alex Adamec.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Architectural Design.
What is Software Architecture?
Software Architecture in Practice (3rd Ed) Introduction
Deriving AO Software Architectures using the AO-ADL Tool Suite Luis Fernández, Lidia Fuentes, Mónica Pinto, Juan A. Valenzuela Universidad de Málaga
Introduction to Aspect- Oriented Programming CS 3360 Gregor Kiczales, et. al. Getting started with AspectJ, CACM, 44(10):59-65, October Fall 2012.
Chapter 10 Architectural Design
The Design Discipline.
© Drexel University Software Engineering Research Group (SERG) 1 Based on the paper by Philippe Kruchten from Rational Software.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
1 CS 456 Software Engineering. 2 Contents 3 Chapter 1: Introduction.
Introduction to Aspect Oriented Programming Presented By: Kotaiah Choudary. Ravipati M.Tech IInd Year. School of Info. Tech.
ITEC224 Database Programming
An Introduction to Software Architecture
Architecture-Based Runtime Software Evolution Peyman Oreizy, Nenad Medvidovic & Richard N. Taylor.
Aspect Oriented Programming Razieh Asadi University of Science & Technology Mazandran Babol Aspect Component Based Software Engineering (ACBSE)
Supporting Heterogeneous Users in Collaborative Virtual Environments using AOP CoopIS 2001 September 5-7, Trento, Italy M. Pinto, M. Amor, L. Fuentes,
Lecture 9: Chapter 9 Architectural Design
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Architecting Web Services Unit – II – PART - III.
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
Introduction To System Analysis and Design
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 32 Slide 1 Aspect-oriented Software Development 1.
Aspect Oriented Programming Sumathie Sundaresan CS590 :: Summer 2007 June 30, 2007.
Aspect Oriented Programming Gülşah KARADUMAN.
Chapter 7 System models.
Software Architecture and Patterns
Architectural Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Information Systems Engineering. Lecture Outline Information Systems Architecture Information System Architecture components Information Engineering Phases.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
AOP-1 Aspect Oriented Programming. AOP-2 Aspects of AOP and Related Tools Limitation of OO Separation of Concerns Aspect Oriented programming AspectJ.
Modeling Component-based Software Systems with UML 2.0 George T. Edwards Jaiganesh Balasubramanian Arvind S. Krishna Vanderbilt University Nashville, TN.
Introduction Better Faster Cheaper (pick any two) On-going issue that continues to motivate research in software engineering Applications: –continue to.
Aspect-Oriented Programming and Modular Reasoning G. KiczalesM. Mezini Presented by Alex Berendeyev.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Introduction to Software Architecture.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University IWPSE 2003 Program.
Alloy-based Lightweight Verification for Aspect-oriented Architecture Naoyasu Ubayashi(Kyushu Institute of Technology) Yuki Sato(Kyushu Institute of Technology)
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
WELCOME TO OUR PRESENTATION UNIFIED MODELING LANGUAGE (UML)
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
Object-Oriented Analysis and Design
Unified Modeling Language
OO Methodology OO Architecture.
An Introduction to Software Architecture
SAMANVITHA RAMAYANAM 18TH FEBRUARY 2010 CPE 691
Aspect-oriented programming
Presentation transcript:

Aspect-oriented programming Laura Ricci A.A

Index  Introduction to AOP  What are aspects?  The role of aspects in software design  AOP issues  AspectJ  What next?

Introduction Currently, the dominant programming paradigm is object-oriented programming that: Object orientation is a clever idea, but has certain limitations  has been presented as a technology that can fundamentally aid software engineering  is reflected in the entire spectrum of current software development methodologies and tools

Introduction A new programming technique called aspect-oriented programming (AOP):  makes it possible to clearly express those programs that OOP fail to support  enables the modularization of crosscutting concerns by supporting a new unit of sw modularity – aspects – that provide encapsulation for crosscutting concernscrosscutting concerns

What are aspects? The current working definition is (May 99, Gregor Kiczales):  modular units that cross-cut the structure of other modular units  units that is defined in terms of partial information from other units  exist in both design and implementation

Concerns AOP is based on the idea that computer systems are better programmed by separately specifying the various concerns of a system Separation of concerns is an important software engineering principle guiding all stage of a sw development methodology Concerns:  are properties or areas of interest  can range from high-level notion ot low level- notion  can be functional or nonfunctional (systemic) back

Example of crosscutting concerns Consider: This requires every method that moves a figure element to do the notification  the UML for a simple figure editor in which there are two concrete classes of figure element, points and lines  the concern that the screen manager should be notified whenever a figure element moves It is taken from C. of the ACM

Example of crosscutting concerns Display FigureFigureElement * PointLine getX() getY() getP1 setP1 DisplayUpdating setX(int) setY(int) setP1(Point) setP2(Point) 2 The red box is drawn around every method that must implement this concern DisplayUpdating fits neither inside of nor around the other boxes in the figure DisplayUpdating cuts across the other boxes

What are aspects? Aspects are similar to classes because:  have type  can extend classes and other aspects  can be abstract or concrete  can have fields, methods, and types as members

What are aspects? Aspect are different than classes because:  can additionally include as members pointcuts (picks out join points), advice (code that executes at each join point )pointcutsadvice  do not have constructor or finalizer and they cannot be created with the new operator  priviliged aspects can access private members of other types

What are aspect? Aspects may arise at any stage of the software lifecycle Common example of crosscutting aspects are design or architectural constraints, systemic properties or behaviours and features

Examples of how aspects cross- cut components We wanted to implement a distributed digital library that stores documents in many forms and provides a wide range of operations on those documents application components aspects digital database, minimizing network Library printers, traffic, services synchronization constraints, failure handling It is taken from AOP document

Examples of how aspects cross- cut components There are several aspects of concerns, including:  communication, by which we mean controlling the amount of network bandwidth the application uses by being careful about which objects get copied in remote method calls  coordination constraints, by which we mean the synchronization rules require to ensure that the component program behaves correctly  failure handling, by which we mean handling the many different forms of failure that can arise in a distributed system

The role of aspects in software design AOP aims at providing better means of addressing the well-known problem of separation of concerns Three basic approaches to addressing the process of separation of concerns:  language-based  framework-based  architecture-oriented

Language-based approach It is based on the definition of a set of language constructs Relevant concerns are identified at the problem domain and translated to aspectual construct The final application is obtained by weaving the primary structure with the crosscutting aspects

Framework-based approach Provides more flexible constructs Concerns are materialized as aspectual classes at the framework level Developers can customize these aspects using the mechanism supported by the framework These types of framework are known as AO frameworks (explicitly engineers concerns)framework

Architecture-oriented approach Early identification of concerns using architectural organizational models Architectural view-point involves a higher level of abstraction than the previous approaches It tipically comprises two stages

Architecture-oriented approach First, developers should determine the problem architecture Then, the approach enables several kinds of aspect materialization through different frameworks Concerns are initially mapped to architectural construct

AOP technologies example Empirical analysis based on a simulation case study of the temperature control system (TCS) of a building () This comprises a building with rooms requiring specific temperatures and a network consisting of radiators, pipes and a boiler To simulate TCS, a simple mathematical model of temporal differential equations specifies the heat flow among the different components It is taken from C. of the ACM

AOP technologies example Relevant aspects in TCS Aspect It refers to how the simulated entities should run Relationships Synchronization Scheduling It basically involves access to shared variables and race condition Description It works together with scheduling It works together with synchronization

AOP technologies example Four different groups of programmers implementing:  typical OO view  aspect language (AL)  reflective AO framework (R-AO)  event-based architectural framework (EBA)

AOP technologies example  TCS evaluation according to the different implementation  Analyzed features: scheduling and synchronization  OO modeling: SS are scattered across the components requiring these facilities (inheritance anomalies)  EBA: SS are provided as built-in features in the framework. It may be difficult to customize some of these policies  R-AO – AL: There are specific aspects dealing with SS. They are kept separated, but some problems about the way they interact (aspect composition) may arise

AOP technologies example Several execution of the simulation programs are maded TCS performance with the different implementation:  results were very similar except in the case of R-AO  similarities found in the study seem to indicate that both EBA and AL run almost like standard code

AOP technologies example  To obtain a measure of the complexity of the implementations, it is gathered code statistics (NCSS) about:  number of methods per class  the NCSS per methods  cyclomatic complexity (CNN per methods) In particular, the best results were obtained with EBA (this payoff comes mainly from the autonomy of component and decoupling prescribed by framework).

The role of aspects in software design The central problem of aspect technologies, whatever the approach we consider, is not just about crosscutting or separation of concerns, but it involves deeper research about how to understand a number of software parts as separated artifacts and then integrate some of then into a coherent system

AOP issues AOP must address both what the programmer can say and how the computer system will realize the program in a program system AOP system:  provides a way of expressing crosscutting concerns  also ensures these mechanisms are conceptually straighforward and have efficient implementations

AOP issues How an AOP system specifies aspects: What composition mechanisms the system provides:  join points join points  aspect parameterization  d ominant decomposition  visibility  mechanism provided

AOP issues Implementation mechanisms: Software process:  static/dinamic distinction  modular compilation  target representation  methodology or framework (the system provides for organizing the system-building activity)  reusability  domain-specificity

AspectJ Aspectj is: Aspectj enables the modular implementation of a wide range of crosscutting concerns  a general-purpose Ao extension to Java  Java platform compatible  easy to learn and use  freely available under an Open Source license

AspectJ When written as an aspect the structure of a crosscutting concern is explicit and easy to reason about Aspects are modular AspectJ enables:  name-based crosscutting (tend to affect a small number of other classes)  property-based crosscutting (range from small to large scale)

AspectJ Adoption of it into an existing project can be a straightforward and incremental task: The goals of the AspectJ project are to make AOP technology available to a wide range of programmers, to build and support an AspectJ user community  to begin with development aspects  other paths are possible,depending on the needs of the projects Example

What next? Software engineering researchers provide some help to determine if it is beneficial for sw development organization to adopt AOP for building their sw products A number of study have been conducted to asses the usefulness of AOP Two basic techniques for assessing a programming technology:  experiments  case study

What next? Three areas emerge as important in supporting the use of AOP:  exposing join points  managing aspect interface  structuring aspects

References Communications of the ACM (October 2001-Volume 44, Number 10) AOP official web site: AspectJ official web site: Sites from which you can find documents about conferences and several informations: l l tml tml

Crosscutting Crosscutting is how to characterize a concern than spans multiple units of OO modularity Crosscutting concerns resist modularization using normal OO construct back

Pointcut Picks out join points Can be defined in classes or in aspects and can be named or be anonymous back

Advice It is code that executes at each join point picked out by pointcut His power comes from the advice being able to access value in the execution context of a pointcut back

Join points Are well-defined points in the execution of a program Only those points that can be used in a disciplined and principled manner back

Framework It is based on decomposition of aspects in system design that consists of components, aspects, and layers. By separating the different aspects of each component, we can separate components, aspects, and layers from each other back

AspectJ example An aspect is defined very much like a class and can have methods, fielsd, constructors, initializers, named pointcuts and advice An example is tracing aspect that prints messages before certain display operation The overall effect of this aspect is to print a descriptive message whenever the traced methods are called It is taken from C. of the ACM

AspectJ example Aspect SimpleTracing { pointcut traced() : call (void Display.update () ) || call (void Display.repaint (..) ); before() : traced () { println(“Entering:” + thisJoinPoint); } void println (String str) { } } Traced identifies calls to several key methods on Display Before advice on this pointcut uses a helper method of the aspect to print a message Advice uses the thisJoinPoint special variable to an object that describes the current join point back