Hi Mira: below are some sketches of the following ideas: 1. Adjusters should be parameterized by multiple strategies. The strategies specify the collaboration structure. 2. Visitors may be used inside adjusters. Adjusters are used to coordinate multiple visitors. 3. Both adjusters and visitors have a "next" adjuster or visitor. -- Karl strategy s as parameter of collaboration add behavior to several classes {CashAccount,Propertymanagement} -> Journal CashAccount deposit withdraw PropertyManagement buy sell need sources and targets role of strategy graph: methods from sources to targets picks out strategy which is needed may be used multiple times Account deposit before ... Journal deposit before Account withdraw before Account withdraw before relationship to Batory if no strategy: with and without strategy: refer to super adjuster parallel connections, coordinated refinement what we cannot do: A f1 before strategy s1 J f1 before A f2 before strategy s2 J f2 before Want: do s1 A f1 before ... J f1 before do s2 A f2 before J f2 before parameterize adjuster with multiple strategies Adjuster (strategy types s1, s2) { do s1 A f1 before J f1 before do s2 A f2 before J f2 before } Connection between visitors and adjusters: Adjuster (s1, s2) { do s1 f1 visitor1 do s2 f2 visitor2 do s1 f3 visitor3 } to do embed in two different class graphs Find all nodes which have at least one successor. Use OCL notation. {Graph -> Successor}-> asSet Graph -> Adjacency -> Vertex ->stop Adjacency ->{through -> *,source,*} to Vertex Successor == Adjacency. reachable through an edge, nodes with at least one predecessor A = . B = A. C = . Graph = List(Node) List(Edge). Edge = Node Node. Mapping: Graph ->{through -> *,t,*} Node Network Node Node Graph Adjacency Vertex discussion of part-free programming (terminal classes have special role) strategy types; take existing strategies but drop unimportant details. needs to be done manually