Verify a Technical Report

Attention: Your report has not been accepted yet!

Please review your report for accuracy, grammar and spelling errors. If you are satisfied with your report then click the "Submit" button at the bottom of this page. If you wish to make changes to your report then click the "Back" button on your browser.

Project Title: DYNAMO: DYNamo Assembly from MOdels
Organization: Georgia Institute of Technology
AO Number: K504
Contract Number: F30602-00-2-0618
Start Date: 28 JUL 2000
End Date: 28 JUL 2002

Principal Investigator

Name:

Spencer     Rugaber
Address: College of Computing
  Georgia Institute of Technology
City,  State   Zip: Atlanta,   GA     30332-0280
Phone: 404-894-8450
Fax: 404-894-9442
Email: spencer@cc.gatech.edu
Level Of Participation - Billed: 8%
Level Of Participation - Unbilled: 15%
 

Financial POC

Name:

Dennis     Farmer
Address: Georgia Institute of Technology
 
City,  State   Zip: Atlanta,   GA     30332-0280
Phone: (404) 894-6941
Fax:
Email: dennis.farmer@osp.gatech.edu
 
Project URL: http://www.cc.gatech.edu/dynamo
Objective:

The DYNAMO project is concerned with assembling high-assurance systems from components, specifically, with guaranteeing correct synchronization of sets of large, heterogeneous components. Several problems that must be overcome to provide such guarantees:

  1. dealing with the sheer complexity of the individual components and their interoperation;
  2. maintaining design integrity and information hiding of the individual components;
  3. providing the desired guarantees, either statically (i.e., during design) or at run time; and
  4. not compromising efficiency while accomplish the other goals.
Approach:

DYNAMO addresses these problems with several techniques:

  1. a layered architecture limits complexity by reducing the amount of allowed interactions;
  2. a declarative specification mechanism abstracts away low-level details, such as event broadcast/handling and variable updates;
  3. static analysis of component designs are augmented with run-time status monitoring and gauges; and
  4. generic (compile-time) component-wrapper generation removes expensive, inter-layer procedure calls.

We apply each of these techniques simultaneously using a design abstraction called a mode component.

A mode component is a hierarchical (i.e., layered) software component whose modular interface provides a continuously updated view of its current status. Clients (i.e., higher-level components) of a mode component can interact with it by directly observing and triggering reactions to changes in this status view. These facilities enable the designer to compose mode components in a way that supports correct, synchronous inter-operation. Such a specification is more abstract (and therefore easier to write and to reason about) than an equivalent specification phrased as a collection of message-passing event protocols.

Mode components extend traditional modular interfaces with extra information, which is useful during static analysis. Consequently, designs built using mode components admit the detection of many errors statically, i.e., at deployment time as opposed to at run time. Moreover, the provision of continuously updated status simplifies the assembly and composition of run-time gauges, which allow even higher levels of assurance. In DYNAMO, designers are charged with thinking about the non-functional aspects of a component during component design, so that this information can be made available as status. We expect this to add discipline and rigor to the initial design of a component so that the designer will be contemplating "what to gauge" from the beginning.

A mode component provides status information to components above it in a layered architecture. The state of those components is updated automatically when changes occur to any of the status information in the mode component. The nature of the update is expressed declaratively without requiring detailed specification of event synchronization. Client components can also make service requests to a mode component using traditional method calls.

Each mode component is implemented according to a design pattern that facilitates the publication and propagation of status information at run time. A key enabling technology in this pattern is the use of C++ templates to declare assembly parameters, which are filled in when an assembly of mode components is declared. These assembly parameters (and various levels of glue code) are generated automatically from a design specification provided in ArgoUML. Use of templates and other advanced C++ features implements the specification without compromising the performance of the assembly of components.

Recent Accomplishments:
  • Demonstrated a proof-of-concept example of use of mode components to generate multiple variants of applications in a product line. This example product line comprises applications that faciliate browsing of a stream of data, which might come from a variety of sources (e.g., sensors, files, or databases), and which might be either static or continuously updated. Mode components used in this example include reusable GUI widgets (such as as view ports, sliders, and scrollbars), data sources (such as file managers, and network interfaces), and various gauges (such as dials and textual displays to present interesting assembly conditions).
  • Extended our library of reusable mode-components and gauges. In addition to adding more mode components and gauges to the library, the project team created a library of utilities that are useful for designing mode components and for composing multiple mode components into an assembly. One of these utilities is a programming abstraction called a data transformer, which is described below.
  • Developed a programming abstraction that supports the transparent refinement of assembly-level status constraints into an event-broadcast protocol that minimizes the number of events required to synchronize two interacting components. This abstraction, called a data transformer works by pushing knowledge of a client component's data needs closer to the source of the data, thereby enabling a variety of optimizations (e.g., optimizing away unnecessary event broadcasts). Data transformers correspond to collection functions in the Object Constraint Language (OCL). Because assembly constraints are specified in OCL, data transformers simplify the generation of code from (declarative) assembly constraints. This is a key enabling technology for the COGITO OCL compiler, which is described below.
  • COGITO: The OCL compiler. DYANMO assemblies are specified using a UML static-data model that is augmented with assembly constraints, which are specified in the UML Object Constraint Language (OCL). COGITO is a compiler for OCL developed by the DYNAMO project. As input, COGITO reads a UML class diagram annotated with OCL specifications of expected system behavior. The annotated diagram is represented in XMI (the UML CASE tool data interchange notation). As output, COGITO generates C++ code that guarantees that the specified properties hold. OCL specifications are abstract and declarative, allowing the designer to focus on essential system behavior. COGITO generates efficient and transparent code. Efficiency is obtained by taking advantage of C++ templates and inlining. Transparent code does not alter the internals of existing components, thereby promoting reusability.
  • DYNAMO methodology and design guidebook. A how-to manual for specifying mode-component assemblies and refining these assemblies into code using DYNAMO tools. Includes a detailed example with supporting components and generated code.
  • Several major pieces of tool infra-structure, that are useful not only in DYNAMO, but also in other products and projects:
    • AST representation of C++ code, useful for building generator tools that emit C++.
    • AST representation of OCL constraints, useful in building tools that process OCL.
Current Plan:
  • Extend and clean up the design of our COGITO compiler. Extensions include support for more of OCL.
  • Package up our demonstration product-line for easy distribution to other researchers and developers.
  • Perform empirical analysis of the efficiency improvement afforded by mode-component assembly and publish these results.
  • Continue adding new mode components to the library.
Technology Transition: We have spoken with two groups about the transition of DYNAMO technology to service organizations: Lydia Shen at the SPAWAR Systems Center and Mike Saboe of TACOM. We demonstrated our tools to both of them in Baltimore, and we visited SPAWAR last November and to deliver a briefing on our work.
Comments / Questions / Anything else you need: