Organizing and Enabling Domain Engineering to Facilitate Software Maintenance
Christopher W. Pidgeon, Ph.D.
Semantic Designs, Inc.
12636 Research Blvd. C-214
Austin, TX 78759-2200
+1 512-250-1018
Abstract
Semantic Designs, Inc. is producing a prototype Design Maintenance System (DMS), a fundamentally different software engineering environment. It is a semantically-based software engineering environmentùone which emphasizes tool-supported design capture and modification. We preserve design knowledge by requiring and enabling the design to be updated as a natural by-product of maintenance acts. DMS embodies seven key ideas:
Keywords:
Software Engineering Environment, Domain Engineering, Domain, Design Maintenance, Reuse
Workshop Goals:
We hope to "infect" others with our meme for software maintenance.
Background: DMS, A Domain-based Software Engineering Environment
Semantic Designs, Inc. is producing a prototype Design Maintenance System (DMS), a fundamentally different software engineering environment. It is a semantically-based software engineering environmentùone which emphasizes tool-supported design capture and modification. We preserve design knowledge by requiring and enabling the design to be updated as a natural by-product of maintenance acts. Programmers do not touch the code! How is this achieved?
DMS includes a semi-interactive code generation engine. Knowledge for code generation is organized into a network of domains. Domain Engineering identifies problem concepts and implementation knowledge comprising the domain interconnection network. A DMS domain expresses:
The domain interconnection network identifies potential mappings of abstract problem ideas to target implementation ideas. During Application Engineering, the software engineer guides choices among alternative mappings. The code generation engine uses domain implementation knowledge to mechanically transform identified abstract domain concepts into target implementations. DMS records the actual transforms used and their justifications as part of the design's history. During a maintenance episode, the software engineer can browse the design and its history to identify and specify changes. Then, DMS is used to install the desired changes by revising the recorded design and its history. This approach yields a continuous, incremental model of software constructionùone that explicitly addresses maintenance.
Position: Tool-supported Domains are key for the entire software lifecycle ù including maintenance.
Position 1: The goal for DMS is the efficient and effective support for the incremental construction and maintenance of large application systems driven by semantics and persistent designs.
DMS is a software engineering environment that records:
What a system is supposed to doùthe specification.
How the implementation does itùthe code.
Why the implementation works correctly and meets performance goalsùthe design.
A key feature of DMS is machine interpretable semantics (denoting the meaning of programs). This allows DMS to provide specification analyses, assist in the choice of implementations, as well as supply explanations of implementations.
The knowledge required for DMS is organized by problem domain. A DMS domain definition includes the following parts:
Position 3: All of the elements of a DMS domain are machine processable.
Some Domain Engineering proponents choose to define a domain as a problem area of interest chosen by subject matter, customer application need, community of users, etc. Practical problems in a domain must be implementable. This requires experience in solving such problems. Engineers must be able to articulate implementation knowledge. For a DMS domain definition to be considered feasible, we insist on the presence of such knowledge. Otherwise, there is little hope for machine support. The domain is relegated to mere expository roles. It cannot be considered an active element in software synthesis or maintenance. Thus, a DMS Domain realizes two important notions:
The DMS environment, then, supports two activities: Domain Engineering and Application Engineering.
DMS Support of Domain and Application Engineering
The following signatures characterize the functionality of DMS tools supporting Domain Engineering.
Parser Generator: GrammarDomain ® ParserDomain
Unparser Generator: GrammarDomain ┤ Rendering RulesDomain ® UnparserDomain
Semantics Definer: External FormDomain ┤ ParserDomain ┤ Domain DescriptionOtherDomain ® SemanticsDomain
Transform Definer: External FormDomain ┤ ParserDomain ┤ SemanticsDomain ┤ Domain DescriptionTargetDomain ® TransformsDomain
Performance Analyzer Definer: External FormDomain ┤ ParserDomain ┤ SemanticsDomain ┤ Domain DescriptionTargetDomain ® Performance AnalyzerDomain
Many of these tools aid the domain engineering process by providing consistency checks on proposed Domain Definitions.
The following signatures characterize the tools that were synthesized during Domain Engineering for use in support of Application Engineering.
ParserDomain: External FormDomain ® Internal FormDomain
UnparserDomain: Internal FormDomain ® External FormDomain
SemanticsDomain: {fmap(Internal FormDomain, Internal FormOtherDomain)}
TransformsDomain: Internal FormDomain ┤ Location ® Internal FormDomain
Performance AnalyzerDomain: Internal FormDomain ┤ Internal Form Location ┤ Performance Parameters ® Performance Value
Under the guidance an Application Engineer ( who views specifications in their external form) DMS is directed to perform property preserving transformationsùoptimization or refinementùon internal forms until a final implementation is achieved. The finality here is determined by the Application Engineer who stipulates the properties of a specification which constitute a final implementation, usually called code. Example properties include:
Position 5: DMS records the transformational derivation history for the design in order to support subsequent changes. However, unlike naive code regeneration from scratch, DMS uses sophisticated compiler and delta propagation technology to propagate changes through the design and derivation history. This is how we achieve scaleability, but the topic is beyond the scope of this position paper.
Domain Engineering: in-the-large vs. in-the-small
Position 4: For any particular problem domain, we favor a modest number (~10 to ~100) of modular, specific purpose domains over a small number (~1) of monolithic, general purpose domains. This allows reuse of most of the very specific domains in new problem areas.
|
Modular |
Monolithic |
Number of Domains |
~10 to ~100 |
~1 |
Ease of Acquisition |
Easier |
Difficult |
Ease of Application |
Easier |
Difficult |
Reuse Potential |
Higher |
Lower |
Development & Maintenance Cost |
Lower |
Higher |
Repository Management |
Tractable |
Trivial |
In essence, this devolves to the argument between a larger number of more specialized domains having more desirable properties than a smaller number of more generalized domains.
Position 7: We propose a domain interconnection network as exemplified below.
Box = DMS Domain, Arrow = "implemented using"
DMS will be made available with a collection of reusable domains (shaded region) either from the vendor or third parties. Domain Engineers concentrate on defining the value-adding generic and specific application domains that are defined and implemented in terms of the other implementation-oriented domains.
WhatÆs a Component?
The prevailing notion is that a component ultimately connotes a fragment of code that realizes some domain concept. Quite often the domain concept is implicit, at least from the perspective of a tool expected to support implementation of the concept. The advantage to this approach is that anyone can write them. The disadvantage is that they can be quite hard to use. Why? There are usually no explicit composition rules. One merely concatenates the code fragments. Another disadvantage is that it is difficult to discern the applicability conditions for the component. Will it work in my configuration? What assumptions is it predicated upon? What constraints does its use impose on subsequent design and implementation decisions?
Position 7: A DMS Component is a triple <domain, concept, method>. The domain establishes the problem context -- it indicates available background knowledge like other components, performance measures, optimizations, etc. The concept, which may be parameterized, is the explicit idea being realized. Method is the transformation control plan to implement the concept. It implicitly requires transforms. It may require components at lower level of abstraction. It may be shared with other domain concepts. The composition rules are defined by the transformations, and can be checked when applied.
How Do You Get Components?
Position 6: Reverse engineering is a legitimate, pragmatic domain engineering activity. The process is simple to define, though challenging in practice:
By recasting reverse engineering for maintenance as a domain engineering activity, we achieve several desirable outcomes:
Conclusion
Position 2: Domain engineering is essential for comprehensive, anticipatory software production and maintenance.
In sum, a DMS domain captures problem domain concepts and construction knowledge. The principal task of domain engineering is the identification of the domain concepts and implementation knowledge, and encoding that knowledge so it can be reused. The DMS domain interconnection graph identifies potential maps of abstract problem ideas to target execution languages. Since DMS is aware of domains, their interdependencies, and their parts, they can be used by DMS to mechanically transform specified domain concepts to code. In the process, the actual transforms and their justifications are recorded as the design. Using the external form in a familiar notation, both the application engineer and the domain engineer can navigate the design, moving freely across domain notations to understand how the code works and why it is present in a particular configuration.
Acknowledgements
Construction of a DMS prototype is supported by the National Institute of Standards and Technology, Advanced Technology Program, Component-Based Software Initiative.
References
Biography
Dr. Pidgeon received a B.S. in Computer Information Systems (1976) and a Masters in Business Administration (1978) from California State Polytechnic University, Pomona. He received a Ph.D. in Computer Science (1990) from the University of California at Irvine where he studied with the Reusable Software Engineering (REUSE) group under the direction of Dr. Peter Freeman (now the Dean of the College of Computing at Georgia Institute of Technology). From 1979 to 1991 Pidgeon taught undergraduate and graduate courses for the Computer Information Systems Department at Cal Poly, Pomona. From 1988 to 1992 Pidgeon was a scientist with Hughes Space & Communications group. From 1992 to 1995 he was a director with Cambridge Technology Partners. Together with Dr. Ira Baxter, he founded Semantic Designs, Inc. in September of 1995. Subsequently Semantic Designs was awarded a three year, $2M grant to develop the prototype Design Maintenance System.