Aspect-Oriented Software Development

Transcription

1 Claudia Marcos ISISTAN Instituto de Sistemas Tandil Facultad de Ciencias Exactas - UNICEN Current Methods and Languages Most current programming languages support abstraction mechanisms for breaking a system down into parametrised components which perform some function. Current methods and notations concentrate on finding and composing functional units - generally expressed as objects, modules, procedures. 1

2 Decomposition & Composition of Concerns complex systems design practices support decomposition into components programming languages support implementation and composition of components Benefits of Good Modularity Also known as clean separation of concerns Each decision / function in a single place easy to understand easy to modify easy to unplug 2

3 Modularity is not always possible... (1) A system may be seen as a set of concerns: basic functionality performance data persistence resource sharing error handling performance optimizations synchronization tracing security... Modularity is not always possible... (2) Some concerns don t localize to objects their code tends to be orthogonal to the rest of the requirements and is spread out through many modules Logging Security Persistence Implementation modules Concerns associated to different requirements 3

4 Book Cross-cutting User Library class Book { class User { interface LibraryInterface extends Remote { private BookID id; private UserID id; public BookID getbook(userid u, String title) throws private PostScript ps; Library thelibrary; RemoteException; private UserID borrower; Printer theprinter; public PostScript getbookps(bookid bid) throws RemoteException; public Book(String t, String a, String i, PostScript p) { public User(String n) { id = new UserID(n); id = new BookID(t,a,i); ps = p; public boolean getbook (String title) { class Library extends UnicastRemoteObject implements BookID abook=null; LibraryInterface { try{ Hashtable books; public UserID get_borrower() {return borrower; abook = thelibrary.getbook(id, title); Library() throws RemoteException { public void set_borrower(userid u) {borrower = u; catch (RemoteException e) { books = new Hashtable(100); public PostScript get_ps() { return ps; try { public BookID get_bid() { return id; theprinter.print(id, abook); public BookID getbook(userid u, String title) catch (RemoteException e) { throws RemoteException { return true; System.out.println("REQUEST TO GET BOOK " + title); class BookID { if(books.containskey(title)) { private String title; public UserID get_uid() { return id; Book b = (Book)books.get(title); private String isbn; System.out.println("getBook: Found it:" + b); if (b!= null) { public BookID(String t, String a, String i) { class UserID { if (b.get_borrower() == null) title = t; private String name; b.set_borrower(u); author = a; return b.get_bid(); isbn = i; public UserID(String n) { name = n; public String get_name() { return name; public String get_title() {return title; return null; public PostScript getbookps(bookid bid) throws RemoteException { Printer if (books.containskey(bid.get_title())) { Book b = (Book)books.get(bid.get_title()); interface PrinterInterface extends Remote { if (b!= null) public boolean print (UserID u, BookID b) throws RemoteException; return b.get_ps(); return null; public class Printer extends UnicastRemoteObject implements PrinterInterface { private Vector jobs = new Vector(10, 10); private Library thelibrary; this optimization cross-cuts public Printer() throws RemoteException{ public boolean print (UserID u, BookID b) throws RemoteException{ PostScript ps=null; try{ the primary structure of the ps = thelibrary.getbookps(b); catch (RemoteException e) { return queue(newjob); program boolean queue(job j) { //... return true; Cross-cutting Symptoms Tangled code Code duplication and dispersion Difficult to reason about why is this here? what does this connect to? it destroys modularity 4

5 Effects of Cross-cutting Consequences: Bad quality code Poor traceability Low productivity Low reusability Testing difficulties Bad adaptability Poor evolution Aspect-Oriented Paradigm The goal of AOP is to provide methods and techniques for: decomposing problems into a number of functional components as well as a number of aspects which crosscut the functional components, and then composing these components and aspects to obtain system implementations. 5

6 Aspect-Oriented Programming Component: can be encapsulated in procedures well located, acceded and clear Aspect: can not be encapsulated in an only one procedure, it is disseminated in the functional components An object is something: Is an entity An aspect is not something is something about something: An aspect exist to incorporate orthogonal functionality to an object Objects not depend on aspects: Objects do not change because of aspects Aspect-Oriented Programming Properties or features that don t align with the functional components of a system cross-cut the primary division of labour that is achieved with objects. An aspect is a feature or unit that cross-cuts other components in the design or implementation. Weaving is the systematic process of combining the aspects and the functional units of a system. A join-point is the place where the weaver introduces the aspect code into the basic component. 6

7 class User { private String name; class Book { private String title; Library thelibrary; Printer the; Printer public User(String n) { name = n; public boolean getbook (String title) { Book abook = thelibrary.getbook(this, title); private String author; private String isbn; private PostScript ps; private User borrower; public Book(String t, String a, String i, PostScript p) { title = t; author = a; isbn = i; ps = p; public User get_borrower() {return borrower; public void set_borrower(user u) {borrower = u; public PostScript get_ps() { return ps; theprinter.print(this,abook); return true; portal Printer { void print(book book) { book: Book: {direct pages; public class PrinterImpl { String status = Idle Vector jobs; class Library { Hashtable books; public PrinterImpl() { pubilc get_status() { return status public add_job(int j) { jobs.add(j); Library(){ books = new Hashtable(100); public Book getbook(user u, String title) { System.out.println("REQUEST TO GET BOOK " + title); if(books.containskey(title)) { Book b = (Book)books.get(title); System.out.println("getBook: Found it:" + b); if (b!= null) { if (b.get_borrower() == null) return null; b.set_borrower(u); return b; portal Library { Book find (String title){ return: Book: {copy title, author, isbn; Aspect Weaving A weaver combines classes and aspects compiler / pre-processor / interpreter statically or dynamically unambiguously coordinates cross-cutting classes aspect weaver executable code aspects Additional Concepts Planes Composition Strategies Conflicts between aspects 7

8 Planes: Encapsulating Aspects Collection of aspects which carry out a specific functionality Different levels of granularity Planes will facilitate the handling of groups of aspects, their reuse, their interaction with the rest of the system, their adaptability The concept of plane is not to be confused with the concept of level or hierarchy of levels Heterarchical vs. Hierarchical structure (heterarchy: a form of organization resembling a network or fishnet) Composition Strategies Different association strategies imply different joinpoints between aspects and other components Class composition: the aspect code is activated when all objects of the composed class receive a message Method composition: the aspect code is activated when all objects of the class receive a message with the composed method Object composition: the aspect code is activated when the composed object receives a message Object-Method composition: the aspect code is activated when the composed object receives a message with the composed method 8

9 Composition Strategies Functional class ClassA Method1 () Method2 () Composition Aspect AspectA AspMethod() instance-of Asp:AspectA AspMethod O2:ClassA Behaviour Mechanism O1:ClassA Method2 Conflicts A conflict may occur if two or more aspects compete for activation Aspect 1 Aspect 2 Message Object 1 Object 2 9

10 Conflicts between Aspects Static conflict: detected when the association is established; similar to system restrictions Dynamic conflict: detected at run-time Detection and Solving Conflicts Which aspects are to be executed? They can be defined at design time or if it depends on the execution time information it can be at execution time Activation order Conflict Taxonomy according to the development life cycle step InOrder ReverseOrder Optional Exclusive Null Context-dependent 10

11 Levels of Conflict Aspect-Aspect: between two specific aspects Aspect-Plane: between an aspect and a plane (all the aspects of this plane) Plane-Plane: between two specific planes (all aspects of one plane with respect to all aspects of another) Aspect-All: between a specific aspect and all the others (in any plane) Aspect-Oriented Applications Implementation Current programming languages extensions A language to define the functional components A language to define the aspects An aspect weaver Frameworks Specific tools 11

12 Aspects Extractor Tool Early Aspects Identification Engineering requirement approach by which aspects are identified, specified, integrated and evaluated in the first steps of the system life cycle Several steps are followed in order to identify candidate aspects Possible conflict situations are identified however not solved Aspects Extractor Tool Use Cases Non-functional Requirements Key words System input Task 1: Analyze the input information Task 2: Selection of candidate aspects Task 3: Specification of candidate aspects Use case analysis Analyst information analysis Identification of conerns by an stemming algorithm Selection of the candidate aspects Description of aspects responsibilities Identification of the relationship bentween aspects and functional components. Conflicts Task 4: Identification of conflicts System output T Task 5: UML modeling Extended use case diagram 12

13 Aspects Extractor Tool Application Creation Functionality Description with Aspects Extractor Tool 13

14 Functionality Description with Rational Rose Selection of Candidate Aspects Identified 14

15 Description of Candidate Aspects Description of Conflict Situations 15

16 UML Use Case Diagram with Aspects Alpheus Aspect-Oriented Development Tool Dynamic composition of aspects with functional units Flexible strategies for association and activation/composition of aspects Multiple levels of aspects Facilities for the reuse and adaptability of aspects Handling of conflicts between simultaneously active and competing aspects Framework to permit instantiation of different applications (in different domains) 16

17 Alpheus Reflective Architecture Metalevel Metaobjects Aspects Composition Base Level Base level objects Alpheus Components Definition 17

18 Alpheus Components Definition Alpheus Composition Specification 18

19 Alpheus Definition of Conflicts Alpheus Visualization ASObsPatient ASObsPatient ASStStatistic ASStStatistics sendmessage( GetPatStatistics [], Patient, NewPatient[] ) GetPatStatistics() sendmessage( Store[], Patient, NewPatient[] ) Store() 19

20 Alpheus Code Generation Alpheus Pending Tasks 20

21 Current Work - ASTOR an AspectJ extension to solve conflict situation, static resolution - Aspects reuse in AspectJ - Extension of Aspects Extractor tool in order to solve automatically the conflict situations, early conflicts - Rule system in order to solve conflict situations, design level - Architectural aspects 21