In previous work a framework was defined for the integration of the design and realization (manufacturing) phases of product development, called Design for Realizability (DFR).[1,2] One goal of this work was to allow a way for the product designer to create designs that result in the efficient and timely production of a quality product. This framework and its constituent domain language was defined for use in physical product realization domains such as manufacturing domains. The proposed project is funded to perform the definition of a framework similar to DFR but for use in logical realization domains (i.e. software development domains).
The Domain Specific Architectural Design Language generation project addresses the issues of creation, representation, analysis, and evaluation of software at the architectural design level. Each of these issues contribute to the objective of providing a software designer with an architectural design tool that contains the knowledge of the software domain (family of software systems). The design tool utilizes this knowledge to help reduce the time and cost associated with the development and maintenance of large complex software systems. Thus the project is primarily concerned with the improvement of the design and maintenance of large complex software systems. The underlying goal is to provide a method of generating domain-specific design languages that capture a set of necessary design requirements and the language constructs and structure needed to specify designs accurately, completely, and easily. These goals are conflicting and difficult to meet if one tries to provide a universal design language that is capable of allowing designs from any domain to be described. In general, the ideal design tool will be domain-specific. It will embody knowledge of the rules of the domain that need to be enforced and will provide such enforcement automatically. This built-in knowledge reduces the specification detail that must be provided by the designer. It allows the designer to describe the design at a higher level of abstraction using the vocabulary of the domain, leaving many details to the tool. The obvious problem with this domain-specific tool building approach is the time, effort and money required to build a tool for each design domain. The answer to this problem? Automate the process of building the domain-specific design tool.
This project takes this approach. It strives to provide a domain specification language that will allow design domain to be defined in terms of the architectural components, their interactions, and constraints upon these components and interactions. This domain definition is then used to automatically generate an Architectural Design Language (ADL) that embodies the specified design rules. The generated domain-specific ADL can be used by the software designer to build new designs that are checked for conformance to design rules early in the design process. Figure 1 shows the domain development and design process defined by this work and their interaction. Figure 2 shows the major components of these two phases that are being developed. The software domain language (Gdes in Fig. 2) that will allow a particular product design domain to be defined in terms of a set of component types, connection types, and associated rules concerning each. In essence the problem is one of defining a domain model for the class of logical product designs and then using this model to define language constructs that will allow instances of this model to be specified. The main goal of this project is the development of a tool which can automate the creation of domain specific architectural design languages which embody a core-set[3] of design rules. Enforcement of these rules can then be automated.
The ADLs generated will strive to provide the designer with:
This project is directly concerned with the definition and implementation of an Architecture Description Language (ADL)[4] as a design tool. An ADL is a set of notations, languages, standards, and conventions addressing representation and description issues of architectural development and analysis. It is a design notation that allows software to be designed at the architectural level of detail; a level concerned with the major components, connections, and interactions.[5] It allows the architecture of the system to be documented and analyzed at a larger and more encompassing level than traditional design notations.
An important issue worth highlighting is the need of multiple views.[6] The design of complex systems requires more than one structural viewpoint along with the relationships among these views. Each view is concerned with aspects of the design of interest to a given stakeholder (user) of the architecture. Each view will provide a set of constructs to support that view in a given architectural style. Elements in one view can relate to elements of another; therefore a framework is required to analyze and reason formally about them.[7] Such multiple view analysis is therefore another major aspect of this project.
This project will contribute to the interest of Repository Based Software Engineering Program (RBSE)[8] at the University of Houston Clear Lake in domain engineering, as well as to the interest of NASA in increasing the efficiency of software development and reducing software development cost by providing early decision support for critical design issues, and promotion of large scale reuse. In particular, this project has the potential to benefit NASA by providing a framework within which NASA's avionics systems could be defined. Such a definition would capture the knowledge associated with the implementation of avionics systems at the architectural level of detail, as well as associated documentation such as design documents, testing, and requirements. This domain definition can be processed and a design tool (ADL and its supporting tool set) generated that embodies this knowledge and is capable of using it to assist the software designer. This generated tool can then be used by software designers to design new avionics-based software systems for NASA. The knowledge captured in the tool will be able to provide design solutions to routine problems that occur repeatedly as well as provide design guidance to new but similar problems. In essence this work provides a methodology for reuse of the knowledge that surrounds a large scale software project, but is generally lost (development team leaves, information is implicitly embedded, etc.) or very difficult to pull from the sea of information.
References
1S. A. White. "A Design Metalanguage for Design Language
Creation," Proceedings of the ASME and API Energy Information
Management-Incorporating ETCE, Houston, TX., Jan. 29-Feb. 2, 1996; Computers in
Engineering 1(1996): 135-44.
2S. A. White. "A Framework for the Development of Domain Specific Design
Support Systems," Proceedings of the First World Conference on Integrated
Design & Process Technology, Austin, TX., Dec. 6-9, 1995. 1: 37-42.
3S. A. White. "Software Architecture Design Domain," Proceedings of
the Second Integrated Design and Process Technology Conference Austin, TX., Dec.
1-4, 1996. (To be published.)
4P. Kogut and P. C. Clements. "Features of Architecture Representation
Languages," Proceedings of the 7th Annual Software Technology Conference
Salt Lake City, Utah, Air Force Software Technology Support Center, April 1995.
1-39.
5D. E. Perry and A. L. Wolf. "Foundations for the Study of Software
Architecture," Software Engineering Notes 17.4 (1992): 40-45.
6C. Lemus. "Abstract Interpretation of Multiple Views in Software
Design," Ph.D. thesis, Tulane University. May 1996.
7C. Lemus and B. Belkhouche. "Multiple View Analysis of Designs,"
ACM Workshop of Viewpoints in Software Development, 4th Symposium on the
Foundations of Software Engineering. San Francisco, CA. Oct. 14-18, 1996.
8Reusable Based Software Engineering Program.
(http://rbse.jsc.nasa.gov/eichmann/rbse/rbse_desc.html).