APPCs revisited 2/25/2019 APPCs revisited

APPCs: motivation Want classes and collaborations Want variation-oriented programming incremental change of collaborations by code addition instead of individual class editing Want traversal strategies structure-shyness and partially automated evolution 2/25/2019 APPCs revisited

Composition of APPCs, strategies and class graphs Strategy types gv1 gv2 st1 st1 st1 s1 s1 = refinement of st1 for CG1 Class graphs gv1 CG1 CG2 gv2(gv1)(s1 CG1) s1 gv2 instantiated behavior 2/25/2019 AOO

Loose coupling C S Strategy graphs Class graphs Each unit should hard-code as few assumptions as possible on the concrete form of the others. F APPCs 2/25/2019 AOO

Roles of strategy graph Participant management role define set of participants reachable from a class-valued variable define participant transportation participant name : abbreviation for path or reversed path Super-iterator role iterate while executing code of some APPC 2/25/2019 APPCs revisited

Roles of strategy graph Participant management role forward path abbreviation From a:A via b:B to c:C if unique path, c is abbreviation for path (used in A-object or B-object) backward path abbreviation if in C-object we need the last B-object visited, b is abbreviation for reversed unique path (used in C-object) 2/25/2019 APPCs revisited

Participant management role Interesting definition: unique reverse path PartList Loop does not matter for reverse path ClassDef Part Empty NonEmpty Reverse path from Part to ClassDef is unique. 2/25/2019 APPCs revisited

Super-iterator role Traverse and execute code of an APPC (visitor style). o.strategy(APPC) can be anywhere in a method f() strategy(APPC) introduce name f and then call o.f() 2/25/2019 APPCs revisited

Playing both roles Participant management role and super-iterator role. Adjacency to edge-list translation participant transportation along unique backward paths (backward path abbreviation) use same strategy as super-iterator Pricing set of participants along unique paths (forward path abbreviation) us same strategy as super-iterator 2/25/2019 APPCs revisited

APPC Consists of provided interface required interface implementation methods to class-valued variables output port to other components required interface methods from class-valued variables interface to class graph: paths required input ports from other components implementation 2/25/2019 APPCs revisited

APPC Required interface methods from class-valued variables interface to class graph: paths required A set of traversal strategies for participant management (unique forward and backward paths) as super-iterators input ports from other components 2/25/2019 APPCs revisited

APPC Implementation methods: refer to participants methods may call next(): result from next component next().n: result from component n subtraversal().s: continue traversal following strategy edge s ???? 2/25/2019 APPCs revisited

Compositionality and referring to traversals in APPC code Should keep it simple: go_on() (or next()) should be only way to talk about what to do next. Reason: we want to compose several APPCs and if each of them talks about its own way of navigation, it is not clear what composition means 2/25/2019 APPCs revisited

Kinds of APPCs Visitor style Adjuster style single-traversal collaborations addition or modification for duration of traversal Adjuster style multi-traversal collaborations add statically new methods to groups of classes statically modify methods in groups of classes 2/25/2019 APPCs revisited

Both kinds Parameterized by strategies class-valued variables method-valued variables 2/25/2019 APPCs revisited

Kinds of APPCs Visitor style single-traversal collaborations single strategy parameter, uniform single method name backbone of collaboration calls subtraversal().s // follow down strategy edge s ???? 2/25/2019 APPCs revisited

Kinds of APPCs Adjuster/Contract style multi-traversal collaborations several strategy parameters different method names 2/25/2019 APPCs revisited

Role of strategy graph At some class A we don’t call next() only. Can call subtraversal().x and subtraversal().y with any Java code in between. ??? Strategy graph describes where we might traverse: is the case anyway with around methods. ??? 2/25/2019 APPCs revisited

APPCs: visitor style APPC A (St1 s1){ instance variables methods B { // redefines node code instance variables, methods void my_role(){ { … next(); … } } -> X,y,Y { // redefines edge code void my_role() { … next(); … } St1 strategy type describing the collaboration. K,L appear in St1 2/25/2019 APPCs revisited

Structure of an APPC (visitor style) APPC (Strategy s, Method m1,…,mk){ // visitor style has only one strategy argument //variables global for traversal init()… return()… start()… final()… s.source //variables that temp. extend host object my_role() host.m1();… next-visitor.return;… next(); host.localMethod1();… localMethod1()(@ … @);… }// end of APPC 2/25/2019 AOO

APPC: adjuster style APPC A (St1 s1, St2 s2, …){ B { void f1() { { x.f2(); … next(); …} } C { void f2() { … Add new methods f1 and f2 to classes B and C, respectively. 2/25/2019 APPCs revisited

Open issues Composition of APPCs order modifies/assumes/extends uses Integrate visitor style and adjuster style? Visitor a special case of adjuster style Injecting APPCs into class graph 2/25/2019 APPCs revisited

Open issues Subtraversals: strategic traversal automaton using APPCs as arguments to other APPCs or parts of them like a uses relationship 2/25/2019 APPCs revisited