1 / 7

Commercializing Soar: Software Engineering Perspective

This article discusses the challenges and potential solutions for commercializing Soar, including reducing entry barriers and improving low-level reuse in software development. It also explores the importance of layered abstraction and the potential directions for reimplementation and componentization of Soar.

antoniorivera
Download Presentation

Commercializing Soar: Software Engineering Perspective

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. Thinking… …inside the box Commercializing Soar: Software Engineering Perspective Randolph M. Jones

  2. Commercialization Issues • The primary concern for commercialization is the ability to build and maintain the systems we want quickly and cheaply • Other general requirements • The systems run as efficiently as possible • The systems are robust and bug-free • Other Soar-specific requirements • We want developers to be able to use Soar easily when Soar is the right tool to use • Provide a smooth transition path from non-Soar solutions to Soar solutions • Remove or reduce the barriers to entry to Soar programmers

  3. The Software Life Cycle • Because of barriers to entry, Soar’s advantages are most pronounced for large applications that exploit Soar’s strengths • Relational knowledge base, knowledge-based decision making • Pattern matching, associative retrieval • Significant situation interpretation and representation • Intricate belief representation • Complex (hierarchical) goal structures and least-commitment execution • Explanation-based learning • Re-entrant, interrupt-driven decision making • These advantages imply that the (current) best commercial uses of Soar will be for relatively large systems • The primary costs for large, long-lived systems are in development and maintenance • There are proven software engineering methods for reducing these costs

  4. Lessons from Computer Science • A primary solution approach to these types of problems is layered levels of abstraction • E.g., hardware, virtual machine, high-level language, libraries • Each layer is designed to foster reuse at that level • Component-oriented virtual/hardware layer • High-level language that captures common idioms and patterns • Formal interfaces for high-level components • Ultimately, specification at each level needs to be developer-friendly, not machine-friendly • Efficiency and robustness are issues, but should be handled by the compiler and virtual machine

  5. Obstacles to Low-Level Reuse in Soar • The current programming primitives in Soar are very close to the low-level architecture • Programming is akin to programming in assembly language • You can write reusable modules in assembly language, but nobody does it any more • Many current Soar “behavior libraries” rely on the goal stack • The goal stack is a limited resource • Two integrated libraries must contend for the resource • Architecture-level interface to libraries • Higher-level interface  increased generality  more reuse • Because there is no formal design level, there can be little design-level reuse • Crippled low-level functionality for common functions • Counting, sets, structure copying, data chunking, accumulation of historical information • Solutions will necessarily be idiosyncratic • A higher-level language with well-defined semantics will allow the current best (or alternative) implementation to be used uniformly

  6. Reducing Entry Barriers • How can we reduce the learning curve for Soar, or make it less important? • Change low-level language syntax • Provide a higher level language • Allow procedural access to Soar data structures (e.g., object-oriented access to working memory) • This could also provide a smooth migration path from procedural systems to Soar systems, as well as the potential for easily integrated hybrid systems • JESS and CLIPS have done similar things • Provide an easily extensible library of components for cognitive and non-cognitive tasks

  7. Potential Directions • Reimplement and “componentize” Soar • Allows smooth migration path for software engineers • Allows easier integration, extension, experimentation • Allows application-specific configuration of reasoning engine • Allows easier insertion of common low-level functions • Allows easier, rational choices for hybrid systems • Build/prototype your own subsystems and components • Reimplement appropriate pieces in Soar • Make Soar’s production syntax into a modern and comprehensible (to engineers) language • Strong typing • Syntactic encapsulation • This can be a pre-processor or compiler, so Soar remains backwards compatible • Develop high-level languages and tools • Must be informed by (and will inform) lower-level changes • Should exploit the defining programming paradigm differences • Re-entrant, event-driven, relational pattern-oriented, least commitment

More Related