Integrating Independent Components with On-Demand

Remodularizationbased 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

Teacher Course Room

StudentYearStudent

teaches*

requiredCourses*

*

*

*

Use two different names for the two directions:teaches/taught_byrequiredCourses/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

Graph Vertex Edge(v1,v2)

Student Contacts Students v1 and v2 visit a common course

Student knows Teacher Students, Teachers Student v1 visits a course by teacher v2

Teacher uses Room Teachers, Rooms Course 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 graphclass 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 graphcontinued

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

CollaborationInterface

Collaboration1 Collaboration2

Remodularization1

Remodularization2

BaseApplicationbinds

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.