Integrating Independent Components with On-Demand Remodularization based on OOPSLA 2002 paper by Mira Mezini Klaus Ostermann Prepared by Karl Lieberherr

Important Characteristic of DRE Applications DRE applications need to consider composing aspects at several time epochs. The environments in which many DRE applications are fielded are dynamic and unpredictable. This makes it difficult to a priori (i.e., at design time) determine exactly the nature of the interaction between composed aspects.

Implication 1:dynamic activation Need to do things like: if (wantOnlineScheduling) { SchedulingGraph sg = wantScheduling1 ? new Scheduling1(courses): new Scheduling2(courses); … } class Scheduling1 = SuccessiveAugmentationColoring + SchedulingGraph; class Scheduling2 = SimulatedAnnealingColoring + SchedulingGraph;

Implication 2: on-demand remodularization A-posteriory integration of aspects into existing applications, without physically changing them. Need to apply aspect to a specific group of objects that is computed at run-time. Apply aspect at object level. Remodularization only used when functionality of aspect is used.

What is new? Program generic behavior in a hierarchy of participant graphs: nested collaboration interfaces making up a family of vitual types. –client-from-server (implement), server-from-client (bind) When binding is chosen, select one leaf of generic behavior (+ operator). Dynamic remodularization for binding: mapping roles to classes is not good enough. –Binding at object level –On-demand remodularization using wrapper recycling.

Example Graph algorithms for a generic graph structure –Graph coloring –Graph matching Reuse those algorithms in many different structures

University Example TeacherCourse Room StudentYearStudent teaches * requiredCourses * * * * Use two different names for the two directions: teaches/taught_by requiredCourses/required_by

Mappings to Graph Graph: Course Collision Vertex: Course Edge(v1,v2) : Teacher teaches both v1 and v2 or both v1 nad v2 required by same student year

Possible Mappings to Graphs GraphVertexEdge(v1,v2) Student ContactsStudentsv1 and v2 visit a common course Student knows TeacherStudents, TeachersStudent v1 visits a course by teacher v2 Teacher uses RoomTeachers, RoomsCourse with teacher v1 assigned to room v2

Side note: express re- modularizations adaptively Use a version of traversal strategies suitable for UML class diagrams with bidirectional associations. cg refers to class graph in the following. Use DJ programming style.

Student Contacts Students v1 and v2 visit a common course iff cg.collect(v1, t1) intersect cg.collect(v2, t1) is non-empty, where t1 = “only forward: from Student to Course”. All edges are only used in the forward direction.

Student knows Teacher Student v1 visits a course by teacher v2 iff cg.collect(v1,”only forward: from Student to Teacher”) contains v2.

Teacher uses Room Course with teacher v1 assigned to room v2 iff cg.collect(v1, “only forward: from Teacher to Room”) contains v2.

Course collision Courses conflicting with a course v1: union –cg.collect(v1,”from Course via Teacher to Course”) –cg.collect(v1,”from Course via StudentYear to Course”)

Graph Collaboration Interfaces interface Graph { expected Vertex[] vertices; interface Vertex { expected Edge[] edges(); } interface Edge { expected Vertex getV1(); expected Vertex getV2(); } This looks strange: it should say that a graph consists of an array of vertices.

Graph Collaboration Interfaces interface ColoredGraph extends Graph { provided compMinimumColoring(Vertex v[]); refine Vertex { expected void setColor(int c); expected int getColor(); } refine Edge { provided float getBadness(); } Should be Graph

Connector for scheduling graph class SchedulingGraph binds ColoredGraph { class CourseVertex binds Vertex { Course c; Edge[] cachedEdges; CourseVertex(Course c) {this.c = c;} Edge[] edges() { if (cachedEdges == null) { cachedEdges = // from Course via Teacher to x:Course // from Course via StudentYear to x:Course // add CourseCollision(c,x); return cachedEdges; } …

Connector for scheduling graph continued class SchedulingGraph binds ColoredGraph { // continued class CourseCollision binds Edge { Course c1, c2; CourseCollision(Course c1, Course c2){ this.c1 = c1; this.c2 = c2; } // wrapper recycling Vertex getV1() {return CourseVertex(c1);} Vertex getV2() {return CourseVertex(c2);} }

Demo Code class Scheduling1 = SuccessiveAugmentationColoring + SchedulingGraph; class Scheduling2 = SimulatedAnnealingColoring + SchedulingGraph; ColoredGraph colorg = wantScheduling1 ? new Scheduling1(): new Scheduling2(); computeScheduling(colorg, someCourses);

Looks familiar Similar kind of genericity achievable with DJ. In DJ can influence generic behavior through visitor selection and binding through dynamic class graph and traversal strategy selection. But not compile-time type safe: compatability of generic behavior with binding checked only at run-time.

Similar code in DJ (not as compile-time type-safe) ClassGraph cg = wantCg1 ? new ClassGraph(…):new ClassGraph(…); String st = wantSt1 ? new String(…):new String(…); Visitor vis = wantVis1 ? new Visitor(…):new Visitor(…); compute(cg,st,vis,someInput); // cg.traverse(someInput,st,vis); // vary generic algorithm through vis // vary binding through cg and st

What is gained? Traditional: To reuse a generic algorithm, translate from a low-level data structure to the higher-level data structure of the generic algorithm and run the algorithm there and map the result back to the low-level data structure. Translation is done by binding. Proposed solution: why is it better?

What is gained? Can organize generic computations hierarchically and combine with different bindings. Translation is done on-demand.

Connector for contact graph class StudentContactGraph binds Graph { class StudentVertex binds Vertex { Student s; StudentVertex(Student s) {this.s = s;} Edge[] edges() { // from Student to Course (forward) // from Course to Student (forward) } class StudentContact binds Edge { }

Binding a collaboration interface to a concrete application Requires on-demand remodularization of the application. Remodularization: specify how the model structure of the base application should be transformed to match the model structure expected of the collaboration interface.

Remodularization Virtual: base model structure is never changed. Defines a virtual view on top of the physical structure. The remodularization for binding a collaboration interface C is effective only on the demand of executing functionality in C.

Architecture for collaboration interfaces Collaboration Interface Collaboration1Collaboration2 Remodularization1 Remodularization2 Base Application binds

Free combination of collaborations and connectors Class A = Coloring1 + StudentContactsColoring; Class B = Coloring2 + StudentContactsColoring; Class C = Matching1 + StudentContactsMatching; Class D = Matching2 + StudentContactsMatching;

Fluid Aspect-Oriented Programming Gregor: Fluid AOP involves the ability to temporarily shift a program (or other software model) to a different structure to do some piece of work with it, and then shift it back. Mira: on-demand remodularization a good starting point for fluid AOP. Karl: Adaptive Programming is an instance of fluid AOP: different structure = minimum structure needed for algorithm.

Fluid Aspect-Oriented Programming Karl: An adaptive program written in DJ is by definition fluid. By providing class graphs and strategies we transform that program into a different context where it will execute. Then we can change the context at run-time and run the program again.

Fluid AOP Callback methods describe events (joinpoints) that should lead to the execution of the method. Similar to Doug Orleans’ branches. There is an additional apply clause expressible by a cflow.

Conclusions We should investigate the dynamic properties of Mira’s approach to dynamic deployment and combinations of aspects in DRE systems. Need to generalize from ACs without aspectual methods to ACs with aspectual methods.

Conclusions How can we simulate those components with units? In this paper interfaces are hierarchical. In units they are flat.