Domain specific software architectures-command and control

Abstract

Abs_actGTE is the Command and Control contractor for the Domain Specific Software Architectures program. The objective of this program is to develop and demonstrate an architecturedriven, component-based capability for the automated generation of command and control (C2) applications. Such a capability will significantly reduce the cost of C2 application development and will lead to improved system quality and reliability through the use of proven architectures and components.A major focus of GTE's approach is the automated generation of application components in particular subdomains. Our initial work in this area has concentrated in the message handling subdomain; we have defined and prototyped an approach that can automate one of the most software-intensive parts of C2 systems development.This paper provides an overview of the GTE team's DSSA approach and then presents our work on automated support for message processing.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 walt until detailed design or implementation to search for reuse opportunities; instead, he/ she 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 th...

Lessons learned from real DSL experiments

“…Our first local formalism that was not designed for the computer professional was a language for describing the format of messages that conformed to a NATO communication standard [3]. This standard describes legal messages transmitted between all kinds of vehicles and processing stations, from tanks, to planes, to command centers.…”

C3 Domain Analysis, Lessons Learned

“…wo other domain analysis tasks also affected the results of this report. They are the DoD's Corporate Information Management (CIM) domain analysis task [Soflech, 1993], and the ARPA DSSA command and control (C 2 ) task [Braun, et al, 1993]. Both of these tasks produced object-oriented domain analysis methods baued on existing object-oriented methods traditionally used for systems analysis and design.…”