1 / 41

Automated Software Reuse Using Dynamic Abstraction

Automated Software Reuse Using Dynamic Abstraction. Jonathan Phillips 11/22/2002. Overview. Review Dynamic Abstraction Implementation Overviews Future Work. Reuse: Why? Why Not?. Why: (ideally) Cost Reliability Why not: Specification difficulty Verification (when size is large)

Download Presentation

Automated Software Reuse Using Dynamic Abstraction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related