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 |
|
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% |
|
|
|
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:
- dealing with the sheer complexity of the individual components and their interoperation;
-
maintaining design integrity and information hiding of the individual components;
-
providing the desired guarantees, either statically (i.e., during design) or at run time; and
-
not compromising efficiency while accomplish the other goals.
|
Approach: |
DYNAMO addresses these problems with several techniques:
-
a layered architecture limits complexity by reducing the amount of allowed
interactions;
-
a declarative specification mechanism abstracts away low-level details, such as event broadcast/handling and variable updates;
-
static analysis of component designs are augmented with run-time status
monitoring and gauges; and
-
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: |
|
|