Domain Specific Software Architectures -- Command and Control
Christine Braun
GTE Contel Federal Systems
braun@europa.asd.contel.com
1 Introduction
The objective of the DARPA DSSA research program (part of DARPA's
"megaprogramming" thrust) is to develop and demonstrate an architecture-driven, component-based capability for the automated generation of DoD applications.
Such a capability will significantly reduce the cost of DoD application
development and will lead to improved system quality and reliability through
the use of proven architectures and components.
DARPA has selected five domain teams, each focusing on a domain of importance
to the DoD. GTE is the contractor for the Command and Control domain.
2 The DSSA Concept
DSSA is based on the concept of an accepted generic software architecture for
the target domain. As defined by DSSA, a software architecture describes the
topology of software components, specifies the component interfaces, and
identifies computational models associated with those components. The
architecture must apply to a wide range of systems in the chosen domain; thus
it must be general and flexible. It must be established with the consensus of
practitioners in the domain.
Once an architecture is established, components that conform to the
architecture-i.e., that implement elements of its functionality in conformance
with its interfaces-will be acquired. They may be acquired by identifying and
modifying (if required) existing components or by specifically creating them.
One of the ways they may be created is through automated component generation.
DARPA has sponsored work in this area at USC Information Sciences
Institute-the AP5 application generator project, and is interested in
incorporating this or related technology.
The existence of a domain-specific architecture and conformant component base
will dictate a significantly different approach to software application
development. The developer will not wait until detailed design or
implementation to search for reuse opportunities; instead, he will be driven
by the architecture throughout. The architecture and component base will help
define requirements and allow construction of rapid prototypes. Design will
use the architecture as a starting point. Design and development tools will
be automated to "walk through" the architecture and assist the developer in the selection of appropriate components. The ultimate goal is to significantly
automate the generation of applications. A major DSSA task is to define such
a software lifecycle model and to prototype a supporting toolset.
These activities will be accompanied by extensive interaction with the
development community for the target domain, and by technology transition
activities. One aspect of this is that each domain team is working closely
with a DoD agency that carries out major developments in the designated area.
(The GTE team is working with the US Army Communications and Electronics
Command.)
3 Why Command and Control?
There are many reasons why the command and control domain is an excellent
target for DSSA technology. It is a high payoff area; command and control
systems are needed even in the current military climate. (This is particularly true when one recognizes that applications such as drug interdiction fall
within the C2 "umbrella".) It is a well-understood area; most of the
processing performed in C2 applications is not algorithmically complex.
However, C2 applications are very large, and much of this size comes from
repeated similar processing-for example, parsing hundreds of types of messages. In addition to this commonality within applications, there is much commonality
across applications. Multiple C2 systems must handle the same message types,
display the same kinds of world maps, etc.
The kinds of commonality in C2 applications are very well-suited to DSSA
techniques. In some areas, components can be reused identically; these can be
placed in the DSSA component base and highly optimized. In other areas,
components will be very similar in nature but differ in the particulars, e.g.
message parsing. These areas are a natural fit to the DSSA component
generation technology, allowing a table-driven generator to quickly create the
needed specific component instances.
4 GTE's Approach
Initially, project work will follow two parallel threads. The first will
define a software process model appropriate to architecture-driven software
development and will develop a toolset to support that process. The second
will establish a capability that implements the process for the command and
control domain, based on a C2 architecture and a set of reusable C2 components.
The DSSA process model will address all aspects of the software life cycle. It will describe activities for establishing system requirements, developing the
software system, and sustaining the system after delivery. The DSSA toolset
will support all of these activities, automating them as far as possible. In
particular, it will automate system development activities by using the
architecture as a template, guiding the selection of available reusable
components, and automating the generation of specific required components. The toolset will be constructed insofar as possible from available tools -- both
commercial products and products of the research community. In particular, it
will make use of USC/ISI's AP5 application generator, DARPA/STARS reuse
libraries, and DARPA/Prototech tools. Open tool interfaces will be emphasized
to minimize specific tool dependencies, thus making the toolset usable in the
widest range of environments.
Fundamental to the C2 DSSA capability is the development of a C2 software
architecture. This starts with development of a multi-viewpoint domain model,
created through interaction with all elements of the DoD C2 community. The
automated Requirements Driven Development (RDD) methodology will be used in
model creation. From this, an object-oriented software architecture will be
developed. The architecture will tie back to the multi-viewpoint model so that mappings to different views of the domain functional decomposition are
apparent. George Mason University's Center for C3I will play a major part in
this modeling and consensus-building activity. A base of components conforming to the architecture will then be developed. Many of these will be existing
components, perhaps modified to fit the architecture. Others will be
automatically generated using AP5.
The DSSA capability will be demonstrated by development of a prototype C2
subsystem, most likely an element of the Army Tactical Command and Control
System. An independent metrics/validation task will assess the effectiveness
of the approach and gather metrics. The methodology and toolset will be
revised based on findings and further necessary research will be identified.
Throughout the program, a technology transfer task will present results in
conferences, papers, seminars, and short courses. The George Mason University Center for C3I will serve as a focal point for technology transfer.
5 Status
Project work is officially just beginning, though it builds on work previously
in C2 reuse at GTE Contel. Initial domain modeling and process definition are
