Software Engineering Issues for Ibiquitous Computing

class LifeCycleBindingMixin { String bindFc (...) { if (getFcState() != STOPPED) throw new Exception(); return _super_bindFc(...); } abstract String _super_bindFc (...);} class XYZ extends BasicBindingController { String bindFc (...) { if (getFcState() != STOPPED) throw new Exception(); return super.bindFc(...); } }  Result of of mixins composition depends on the order in which they are composed  Controllers are builts as composition of control classes and mixins T. Coupaye, LAFMI Summer School, Puebla, Mexico, August 2004 France Telecom R&D Division 37 Interceptors  Interceptors  Most control aspects have two parts  A generic part (a.k.a. “advice”)  A specific part based on interception of interactions between components (a.k.a. « hooks »)  Interceptors have to be inserted in functional (applicative) code  Interceptor classes are generated in bytecode form by an generator which relies on ASM  Interceptor class generator  G(class, interface(s), aspect code weaver(s)) -> subclass of class which implement interface(s) and aspect(s)  Transformations are composed (in the class) in the order aspects code weavers are given  Aspect code weaver  An object that can manipulate the bytecode of operations arbitrarily  Example:  Transformation of void m { return delegate.m }  Into void m { // pre code... try {delegate.m();} finally {//post code... }}  Configuration  Interceptors associated to a component are specified at component creation time  Julia comes with a library of code weavers:  life cycle, trace, reification of operation names, reification of operation names and arguments T. Coupaye, LAFMI Summer School, Puebla, Mexico, August 2004 France Telecom R&D Division 38 Life Cycle Management Approach based on invocation count  Interceptors behind all interfaces increment and decrement a counter in LifeCycle controller  LifeCycle controller waits for counters to be nil to stop the component (STARTED->STOPPED) when then component is in sate STOPPED, all activities (includind new incoming ones) are blocked  activities (and counter increment) are unblocked when the component is started again Composite components stop recursively  the primitive components in their content  and primitive client components of these components Because of inter-component optimization (detailed later)  Same algorithm with n counters  NB: needs to wait for n counters to be nil at the same time with a risk of livelock Limitations  Risk of livelock when waiting for n counters to be nil at the same time  No state management hence integrity is not fully guaranteed during reconfigurations T. Coupaye, LAFMI Summer School, Puebla, Mexico, August 2004 France Telecom R&D Division 39 Intra-component optimization  3 possibilities for memory optimization  Fusion of controller objects (left)  Fusion of controller objects and interceptors (middle) if interceptors do all delegate to the same object  Fusion of controllers and contents (right) for primitive components Merging is done in bytecode form by generating a class based on lexicographic patterns in concerned controller classes  weavableX for a required interface of type X in controller is replaced by this in the generated class  weavableOptY for a required interface of type Y is replaced by this or null in the generated class T. Coupaye, LAFMI Summer School, Puebla, Mexico, August 2004 France Telecom R&D Division 40 Inter-component Optimization Shortcut algorithm  Optimized links for performance (“shortcuts”) subtituted to implementation ( ) and delegate links ( ) in binding chains NB:  behaviour is hazardous if components exchange references directly (e.g. this) instead of always using the Fractal API  Shorcuts must be recomputed each time a binding is changed Initial path