DJ: traversal-visitor-style programming in Java Josh Marshall/ Doug Orleans Want to add more on traversal through collections and Aspectual Components

History Fall 1996: Lars Hansen: early proposal Johan Ovlinger: TAO Traversal automata by Wand and Ovlinger Doug Orleans: AP Library makes DJ possible David Wagstaff (Novell): Pure Java AP

Motivation Better to have an easy to use less powerful system than a harder to use more powerful system to get initial users. Build on Demeter/Java experience –through AP Library –visitor organization Extend Demeter/Java: generalize traversals: find, add, delete,...

DJ Features Name traversals Provide abstract visitor class Create class graph from Java source Compute traversals dynamically

Comparison DJ –interprets traversal strategies: slower, dynamic –only requires DJ package Demeter/Java –generates traversal code: faster, static –new programming language

Good for DJ over Java Extending traversals for collections (b..*) –returning a single object instead of a collection (Find) –modifying the collection (Add, Delete) –implementations are different for different implementations of collections

Embedding versus path control Embedding does mapping work once but requires mapping construct Path control may repeat mapping work

Reuse of an AC written with DJ Copy AC rename everything change path control: assumes original AC is written with path control Leads to duplication of code

UML Class Diagram Library Book 0..* books User users 0..* Copy copies 0..* book checkOutItems 0..* Boolean avail bN BookName UserId uId

UML Class Diagram Library Book 0..* books User users 0..* Copy copies 0..* book checkOutItems 0..* Boolean avail bN BookName UserId uId CheckOutItem copy

How can addition be expressed with ACs Required: participant graph Provided: modified participant graph: has all the paths in original but may have more

Interaction schema CheckOut { Library( Find-> Book Find(avail==true)-> c:Copy; Find-> u:User;) addCopy { u:User Add-> Copy; c:Copy Set(avail,false)-> Boolean } }//participants: Library, Book, Copy, User Checkout a book for a user

CheckOut (Library lib,BookName bN, UserId uId){ lib:Library( )-> Book Find(this.bN==bN)-> Book Find(avail==true)-> Find(avail==true)->c:Copy; Find(this.uId==uId)-> u:User;) addCopy { u:User Add(c)-> Copy; c:Copy Set(avail,false)-> Boolean } Compiler asks for information or determines it by rules

class Library { Copy CheckOut (Library lib,BookName bN, UserId uId){ Book b = lib.Find(“Book”,“bN”,bN); Copy c = b.Find (“Copy”,“avail”,true); Copy c = b.Find (“Copy”,“avail”,true); User u = lib.Find(“User”,“uId”,uId); User u = lib.Find(“User”,“uId”,uId); u.Add(“Copy”,c); c.Set(“avail”,false); return c; } Compiler asks for information or determines it by rules

class Library { Copy CheckOut (Library lib,BookName bN, UserId uId){ Book b = cg.Find(lib,“to Book”,“bN”,bN); Copy c = cg.Find (b,“to Copy”,“avail”,true); Copy c = cg.Find (b,“to Copy”,“avail”,true); User u = cg.Find(lib,“to User”,“uId”,uId); User u = cg.Find(lib,“to User”,“uId”,uId); cg.Add(u,“to Copy”,c); cg.Set(c,“to Boolean”,”avail”,false); return c; } For DJ

Doug’s proposal Book b = cg.fetch( lib, new Strategy (“to Book”), new Predicate() { boolean match(Object obj){ return((Book) obj).get_isbn() == 678); } ) Instead of: Book b = cg.Find(lib,“to Book”,“isbn”,678);

Doug’s proposal Book b = cg.fetch( lib, new Strategy (“to Book”), new Predicate() { boolean match(Object obj){ return((Book) obj).get_isbn() == 678); } ) Instead of: Book b = cg.Find(lib,“to Book”,“isbn”,678); interface Predicate { boolean match(Object); } Anonymous object of anonymous class More flexible but more verbose

Book b = cg.Find(lib,“to Book”,“bN”,bN); Copy c = cg.Find (b,“to Copy”,“avail”,true); Copy c = cg.Find (b,“to Copy”,“avail”,true); User u = cg.Find(lib,“to User”,“uId”,uId); User u = cg.Find(lib,“to User”,“uId”,uId); cg.Add(u,“to Copy”,c); “avail”,true Copy cg.Delete(u,“to Copy”, “avail”,true); cg.Set(c,“to Boolean”,”avail”,false); Boolean cg.Get(c,“to Boolean”,”avail”); int cg.Traverse(company,”to Salary”,v); For DJ/paper

0..*, 1..*: Book b = cg.Find(lib,“to Book”,“bN”,bN); cg.Add(u,“to Copy”,c); “avail”,true cg.Delete(u,“to Copy”, “avail”,true); cg.Traverse(company,”to Salary”,v); cg.Gather(company,”to Salary”); 0..1, 1..1 cg.Set(c,“to Boolean”,”avail”,false); cg.Get(c,“to Boolean”,”avail”); For DJ/paper/constraints

0..*, 1..*: Book cg.Find(lib,“to Book”,“bN”,bN); Find in library lib a book with data member “bN” = bN. void cg.Add(u,“to Copy”,c); Add to user u a copy c “avail”,true Copy cg.Delete(u,“to Copy”, “avail”,true); Delete from user u a copy with avail == true For DJ/paper/constraints

0..*, 1..*: int cg.Traverse(company,”to Salary”,v); traverse from company to Salary and perform visiting actions of v. Vector cg.Gather(company,”to Salary”); collect all Salary-objects reachable from company 0..1, 1..1 Boolean cg.Set(c,“to Boolean”,”avail”,false); Boolean cg.Get(c,“to Boolean”,”avail”); For DJ/paper/constraints

CheckOut { )-> Book Find(this.bN==bN)-> Book Find(avail==true)-> Find(avail==true)->Copy; Find(this.uId==uId)-> User; addCopy { u:User Add(c)-> Copy; } Aspect Language: don’t use

CheckOut (lib,bN,uId){ lib:Library( )-> Book Find(this.bN==bN)-> Book Find(avail==true)-> Find(avail==true)-> c:Copy; Find(this.uId==uId)-> u:User;) addCopy { only one choice u:User Add(c)-> Copy; c:Copy Set(avail,false)-> Boolean } Compiler asks for information or determines it by rules Definition: an interaction schema is a sequence of navigation statements of the form o1:T1 -Action1-> o2:T2 -Action2-> o3:T3...

Advantages High-level description of behavior in terms of an ideal UML class diagram Behavior can be adapted to many concrete class diagrams –Some details of action parameters may be filled in under compiler control

Generalized Traversals Library Find-> Book Traversal from Library to Book must have upper cardinality > 1, e.g., 0..*, 1..*. Compiler will ask for properties to select a book. Rule: if an object of the class of a data member of Book is available, it will choose that one as default

Generalized traversals lib:Library Find-> b:Book DJ: Book b = cg.Find(lib, new Strategy(“from Library to Book”), “property bN”,bookName); Book b = cg.Find(lib, new Strategy(“from Library to Book”), “property isbn”,isbnNumber);

Connection actions/class graph lib:Library Find-> b:Book u:User Add(c)-> Copy lib:Library Delete-> b:Book 0..*, 1..*

Connection actions/class graph c:Copy Set(avail,false)-> Boolean c:Copy Get(avail)-> b:Boolean == c:Copy Fetch(avail)-> b:Boolean 1..1, traverse a little different c:Company Traverse(v1)-> r:Result traverses to all classes mentioned in v1 and performs visiting action. There must be a path to each such class?

Generalized traversals lib:Library Find-> b:Book DJ: Book b = cg.Find(lib, new Strategy(“from Library to Book”), “property author”,authorName); Find is like a generalized fetch

Generalized traversals u:User Add(c)-> Copy; cg.Add(u,new Strategy (“from User to Copy”), c); Expects a unique path from User to Copy that is “insertable” and it adds c at end. Insertable means...

New Operations for DJ Find, Delete, Add Set, Get=Fetch Traverse, Gather c:Copy Set(avail,false)-> Boolean cg.Set(c, new Strategy( “from Copy through -> *,avail,* to Boolean”), false);

DJ: dealing with vectors How can DJ deal with Java vectors and other collection classes? A = B C. //from A via B to C B = Vector. R = Q. Q = C. S = T. T =.

DJ: dealing with vectors A = B C. //from A via B to C B = Vector. R = Q. Q = C. S = T. T =. A B C Vector R Q S T

DJ: dealing with vectors A = B C. //from A via B to C B = Vector. R = Q. Q = C. S = T. T =. A B C Vector R Q S T

Dealing with Vector Enlarge the class graph by drawing a subclass edge from Vector to every node. Might create many edges Use the generality of the strategy compilation algorithm

Parametric types Essential for code reuse program fragment viewed in different ways intersection/union types derived automatically: analysis principal type: expect less for free variables, more for result

Subtraversal s as argument s.apply(“a”);