Figure 1: a) Two Major processes defined by the framework; b) Framework Components.
S. A. White
C. Lemus
University of Houston-Clear Lake Box 40
2700 Bay Area Blvd, Houston, TX 77058
Tel: (713) 283-3867/283-3802
Fax: (713) 283-3869
Email:
white@rbse.jsc.nasa.gov
lemus@rbse.jsc.nasa.gov
While reuse of code is important, in order to make truly large gains in productivity and quality, reuse of software designs and their surrounding knowledge offer the greater potential for return on investment. We believe this notion reflects the way expert designers and developers work. We believe that domain knowledge reuse in conjunction with reuse of the process of building domain-specific design tools can play an important role supporting reuse efforts. Therefore, we feel the process of reuse is not a strictly bottom up process (reuse of code) even though it looks that way at first glance. Rather there is a large intellectual view of the system to be constructed that is driving the reuse of software. We are trying to provide a tool and notation that will help capture past design experiences and provide support tools that that will allow a designer to use these experiences in a more explicit and reproducible manner. We present here our position on software reuse in more detail as well as our current work on the automated generation of Domain Specific Software Architectures (DSSAs) and their Domain Specific Languages (DSLs). We briefly describes the framework underlying this automated environment for generating DSLs and the results of a case study undertaken within the petrophysical surveying domain to test drive the framework and the lessons learned from this case.
Keywords: Architecture Reuse, Domain Specific Language, Domain Engineering, Application Engineering
Workshop Goals: Learning, networking, technology transfer
Working Groups: Domain Engineering Tools, Reuse and Product Lines
Dr. White is currently a member of the Repository Based Software Engineering (RBSE) research team at the University of Houston - Clear Lake. Recently, Dr. White, as principal investigator, was awarded funding from the Institute for Space Systems Operations for a UH-NASA/JSC Aerospace Post Doctoral Fellowship project titled ``Domain specific architectural design language generation'' [1]. This award provided funding for a post-doctoral fellow, Dr. Lemus, to work in conjunction with Dr. White and NASA/JSC to help fulfill the objectives of the project. One immediate goal of the project is to provide a designer of large, complex software with an architectural description language and support tools that will allow the designer to describe designs at the architectural level of detail. In addition, there is the larger goal of making the language domain specific, yet provide a general method of creating such a domain specific language. Specifically, both the language and the tool will contain domain specific knowledge surrounding software design within the application domain. This knowledge will allow the tool to provide guidance to design solutions to routine problems within the domain as well as design guidance to new but similar problems within the domain. Unique to this project is its aim to automate the creation of the domain specific architectural design language and its support tool set. It provides a methodology for the capture and reuse of domain specific knowledge that surrounds the design and implementation of an artifact.
Our position on software reuse is that while reuse of code is important we feel that in order to make truly large gains in productivity and quality, reuse of software designs and patterns offer the greater potential for return on investment. We believe this notion reflects the way expert designers and developers work. They draw on past successful design experiences when formulating a new design solution that is to be implemented. They do not in general begin a new design by examining source code. Even if they do examine source code early on there is a structure to this examination which is driven by their knowledge of past systems and the way in which is was put together (the architectural design). Therefore, we feel the process of reuse is not a strictly bottom up process (reuse of code) even though it looks that way at first glance. Rather there is a large intellectual view of the system to be constructed that is driving the reuse of software. We are trying to provide a tool and notation that will help capture past design experiences and provide support tools that that will allow a designer to use these experiences in a more explicit and reproducible manner. We strive to increase reuse at the architectural level of design which we feel will lead to insights into reuse at the source code level. Therefore our work deals with reuse of domain knowledge, reuse of architectural designs, and conditions for reuse of software components.
Our method, described briefly in the remainder of this paper, provides for automated reuse of the process of building domain-specific design tools, as well as capture and reuse of architectural domain knowledge. It provides support for reuse at the design level. It separates from traditional approaches to providing support for architectural design in two ways. 1) We feel that the the most effective tool is a domain-specific tool and that one universal architectural design language is not the answer. 2) We also feel that the process of building domain-specific design support tools can be automated if an adequate domain definition exists. These two beliefs together are the driving force behind this work that separates it from most. Another separating factor is our interest in multiple views and the provision of support for this within the tool.
We present in the remainder of this section the system defined and used for domain-specific design language generation and knowledge reuse. We call this system SDFR (Software Design for Realizability) [2] since its definition is derived directly from the Design for Realizability framework [3]. The framework identifies two major tasks or processes: the domain definition process and the design support process (see figure 1a). The domain definition process occurs first. This process is supported by a Domain Definition Language (DDL) and a database schema that together allow a design domain to be defined (see figure 1b). The Domain Definition Language allows a software design domain to be defined at the architectural level of detail. The schema definition provides a mechanism for rules concerning reuse of software components to be stored and utilized during the design support process. If there are reusable inventory components belonging to the domain, information regarding the conditions for their reuse is provided via use of the domain language and definition of attributes of the software as required by the database schema.
Figure 1: a) Two Major processes defined by the framework; b) Framework
Components.
Once the domain has been defined, the domain definition is input to a language generator and the output is a domain specific architectural design language (DSL) and support routines which can be used by the software designer to quickly build new architectural designs that are checked for conformance to design rules early in the design process. The key to the generation process is the DDL since execution of its semantic actions results in the creation of the DSL and its semantic actions. Figure 1b shows the major components of the framework that support the domain definition and design support tasks.
The Domain Definition Language component (DDL) of SDFR is a language that provides constructs that allow a domain definer to specify a set of user-defined component-types, connector-types, and connection-types (all such types are either off-shelf or to-realize), as well as rules about the allowable interactions among these types. The language also provides a set of built-in component, connector and connection types. The domain definer may specify conditions for reuse of off-shelf components and component interaction rules as well as attributes of components, connectors, and connections. The resulting domain definition provides a specific set of architectural building blocks and rules for how the blocks can be put together which form the basis for systems to be designed and built within the specified domain.
The Domain Specific Language component (DSL) (its syntax and semantics) is generated by SDFR from the domain definition. It consist of the component-types, connector-types, and connection-types specified using the DDL, as well as rules concerning their interaction and use/reuse. The generated DSL is to be used by the software architect to specify new designs using the building blocks provided. Rules concerning correct/suggested usage of these blocks are embedded in the semantic actions of the generated language and thus checking and enforcement of design rules is automated and applied during the architectural design phase.
The SDFR instance of the framework has been applied to a petrophysical surveying system by K. Cooley [4] who served as the domain definer. The idea was to test out the DDL to see if an existing application domain could be defined using this DDL and to discover what needed to be changed or added to make the DDL most useful. A petrophysical surveying system was chosen to be modeled as a domain. Systems of this type included multiple processors linked to a remote package of instruments via a telemetry link.
During the domain definition process, the domain definer first defined a serious of views by drawing graphical depictions of the architecture of each view. The first view of the system was the overall data acquisition view since the primary purpose of the system was data acquisition. This view described the major processing components of the system and their linkage to a remote package of instruments via a telemetry link. The next view of the system was a classical pipe-filter view. Yet another view of the system was defined which reflected an object-oriented view.
During the domain definition process of the case study it was apparent that the definition of multiple views are central to the process. However, the DDL did not support the separation of these views, but rather forced a composite view which makes domain definition more difficult and less natural than a definition process that allows each view to be defined separately. We are currently working on a new version of the DDL which will allow several views to be separately defined. Of course, this has already been suggested in theory [5]. Second, it became apparent that in addition to the specification of components, connectors, and connections the ability to provide a structured comment that allowed a rationale statement to explain the reasoning behind many design rules and restrictions was also needed. The language was augmented during the definition to allow for this ability. Thirdly, a graphical user interface is needed through which the domain can be specified more naturally and easily. Such a facility is currently under development.
This work deals directly with the creation and implementation of architectural design languages and as such is related in interest, and influenced by Perry and Wolf [6], Garlan and Shaw [7], and Kogut and Clements [8]. Since we deal also with domain experience and the capture and use of this experience it is also related to and influenced in subtle ways by Sidney Bailin's work on experience capture [9] and Vic Basili's work on the experience factory [10]. We also have similar goals as that set forth by ARPA's DSSA program [11]. DSSAs have been defined in several specialized domains [12] supporting a higher degree of reuse for designs and components in comparison with a traditional software development approach. We also strive for a DSSA and its promise of higher degrees of reuse. However, creation of the DSSA requires an investment in time, effort and money each time a domain specific tool needs to be developed. The SDFR framework addressed in this paper defines an automated process of building a useful DSL. Our work separates from traditional approaches to providing support for architectural design in two ways. 1) We feel that the the most effective tool is a domain-specific tool and that one universal architectural design language is not the answer. 2) We also feel that the process of building domain-specific design support tools can be automated if an adequate domain definition exists. These two beliefs together are the driving force behind this work that separates it from most. Another separating factor is our interest in multiple views and the provision of support for this within the tool, as well as support for automated GUI generation.
S. A. White is an Assistant Professor of Software Engineering at the University of Houston - Clear Lake. Dr. White's research interests include domain specification languages, architecture design languages, software architecture, and computer integrated design. Dr. White received the Ph.D. in Computer Science in May 1994 from the Center for Advanced Computer Studies at the University of Southwestern Louisiana.
C. Lemus is a Visiting Researcher in the Aerospace Post Doctoral Fellowship project. Dr. Lemus received the Ph. D. in Computer Science in 1996 from Tulane University. Dr. Lemus research interests include software engineering, software architecture, software design and programming languages.