Automated Software Reuse Using Dynamic Abstraction

1. Automated Software ReuseUsing Dynamic Abstraction Jonathan Phillips 11/22/2002

2. Overview • Review • Dynamic Abstraction • Implementation Overviews • Future Work

3. Reuse: Why? Why Not? • Why: (ideally) • Cost • Reliability • Why not: • Specification difficulty • Verification (when size is large) • Scope and power vs. cost

4. The Utility of Reuse • Is the implementation of automated reuse cost prohibitive? • Large scale formal (automated) reuse requires a massive initial investment. • Domain analysis • Modified software engineering process • Can reuse systems be designed with future problems in mind? • Increased number of control rules • Size of code database

5. Review: Problem Description • To automate software reuse in a typical high level language programming domain while overcoming the limitations of previous manual and automated reuse systems. • Use dynamic abstraction • Construct common operations based on behavior • Update abstraction algorithm to include new operations • Utilize new operations in the future

6. Dynamic AbstractionAn Attempt at Formalism Given: O = {op01,op02,…,op0n }Set of primitive operators A = {a1, a2, …, am}Set of levels of abstractionwhere levels are ordered according to: a1< a2 < … < am ai= {oi1, oi2, …, oip}Where oij is an abstract operator at level i oij = {oi-1k, oi-1k+1…}, Ord Where Ord is an ordering on oik that describes how the operators are composed to create the abstract operator Show: Dynamic abstraction can generate am+1 automatically AND/OR dynamic abstraction can create a new oijat level i.

7. Dynamic Abstraction Cont. • Further requirements • New abstractions based on experience • Updated abstractions propagate throughout reuse system • Specification translation, code retrieval, synthesis/adaptation

8. Dynamic Abstraction Ex. • Let’s consider a simple robot software example: • Note: assume the primitive operators represent code that executes the given instructions O = {pick(?x), put(?x, ?y)} A = {a1}, a1 = {stack(?x, ?y), unstack(?x)} • How can we add abstract operators?

9. Example Block Problems Initial Goal Initial Goal Initial Goal Initial Goal Initial Goal Initial Goal

10. New Operators • restack(?blockList, ?blockOrder) • unstackAll(?blockList, ?blockOrder) • Combine these in level 2 to create a2

11. Abstraction Hierarchy This hierarchy shows some of the difficulties involved within dynamic abstraction: Program restack unstackAll unstack stack pick put

12. New Issues • Efficiency: difficult to guarantee optimality of generated operators (fewest number of primitive operations) • Reasoning at different levels of abstraction. • Some problems will still require using concrete operations • Can we (or do we want to) reason with both abstract and concrete operations?

13. New Problem Description • Develop a formal methodology for dynamic abstraction (in a software reuse domain) that maintains: • Solution optimality • Completeness of the set of solutions for the set of problems originally solvable

14. What’s Next • Implement a simple reuse system to gain experimental knowledge • Test for identification of potential abstractions • Develop algorithms to maintain optimality and completeness

15. Review: Solution Framework • Specification system • Initial abstraction algorithm • Synthesis system

16. Source Studies • Looked at several different works • Determine schemes used for specification, abstraction, and synthesis • Extract most appropriate ideas that apply to software generation

17. Sources • Olson – Automated generation of simulation models • Son – Automated generation of shop floor simulation control

18. Combined Discrete/ContinuousSimulation : Olson • Specification: • Part description and process plan • Predicates describing the processes and environment in a step of the plan • Abstraction: • Sentences encapsulate qualitative planning information • Process descriptions contain model retrieval info • Synthesis: • Instantiate and connect dynamic models for a process • Produce qualitative model from sentences

19. Blocks World Example Informal specification: The problem is to generate software that guides a robot through the solution to this blocks world problem: D A A D B B C C Initial State Goal State

20. Ex: Problem Specification • In the planning domain this problem can be described easily: Initial State: On (Table, B), On(B, A), On (Table, C), On(C, D), Clear(A), Clear(D), HandEmpty Goal State: On (Table, C), On(C, B), On (B, A), On (A, D), Clear(D), HandEmpty And this yields the following process plan:

21. Ex. Process Plan PID: 1 unstack (A) S TART JOIN END AND PID: 3 stack (C, B) PID: 4 stack (B, A) PID: 5 stack (A, D) PID: 2 unstack (D)

22. Ex: Process Description • Now we represent individual processes using logical sentences:

23. Where’s the Code? • The predicates in the process descriptions can be divided into two groups: • Process allocations => Functions/Programs • Process attributes => Input/Output Parameters • Retrieve and instantiate code from database

24. Program/Function Database • Store by name • Keep contract of input/output • Holds block of code

25. Synthesis: Continuous/Discrete • Discrete elements from process plan • Main function, calls all sub functions • Continuous elements linked for each call in the main function

26. Summary of Methods: Cont./Disc. • Specification • Processes use predicates • Problem is represented more abstractly • Abstraction • Several levels: Initial problem, process plan, process description, concrete code • Synthesis • Traverse plan, combine functions

27. Shop Floor Control : Son • Specification: • Resource and control models • Abstraction: • Dropping messages from control representation • Synthesis: • Rules associating messages with code blocks

28. Software Example • Programs/functions used in the domain are specified in connectivity graph (resource model):

29. Control Model • The messages passed between elements of the system are represented by a message-passing state graph (MSG) • Communicating finite state machine • Shows all messages sent • Depends on state of system • Messages update state of system by changing state variables

30. MSG • We will reuse the robot software example to display a possible MSG for the system, not just the one problem

31. Generating Control • The resource model and control model used to generate control • Messages to subparts are dropped (e.g. calls within MoveArm, GrabBlock, etc.) • Blocks of code are generated for each control message • Determine state of the system and the path of a program during generation

32. “Shop Floor” Program Synthesis • The shop floor in this case is a domain that has a given number of operations (possibly classes,objects, etc. with associated operations) • Problems are encountered in the form of orders input to the system • Orders contain processing information that direct flow through the program shop

33. Synthesis Example • Same problem as on slides 18 through 24 • In this case process plan would be the input: unstack(A), unstack(D), stack(C, B), stack(B, A), stack(A, D) • Next slide shows path through MSG

34. Route For Program Generation

35. Missing Details • Described program synthesis system is missing some details • Control flow • Program composition • Generation of resource and control models

36. Summary: Shop Floor • Specification • Resource and control “graphs” • Domain definition • Program process plans • Abstraction • MSG • Synthesis • “Part processing” for programs • Are YOU a shop floor control system?

37. Specifications • Still haven’t answered the question of how user enters a specification • Need “translator” between external and internal representations of a problem • Process planner gets process plan from part description

38. Internal vs. External Specification • External specification • Software specification languages (VDM) • Visual representations (e.g. KHORUS, Modelica) • Graphical Representations (UML) • Internal specification • Process plans • Abstract operators • Predicate descriptions

39. Synthesis • Built-in rules • Also useful in defining new abstract operators • Instantiation • Connection • Adaptation • Useful ingenerating optimal operators

40. Other Implementation Work • To Do: • Further research on abstraction • CBR and derivational analogy as discussed in the last presentation

41. Future Work • Implementation • Testing (raw data to identify abstraction candidates) • Construction of dynamic abstraction formalisms