[Next] [Previous] [Up] [Top] [Contents]

CHAPTER 8

8.1 Summary of Contributions

Several significant research issues were resolved in achieving the stated goal of creating a Comprehensive Software Information System: the epistemology of software representations was identified as second order, a general extension to first order representation systems was created to handle software representations, the code-level representation was able to automatically detect side-effects in procedures, vestigial code, and some delocalized plans, and an ontology for on-line information was defined. The success of the representation implies a new paradigm for software development.

8.1.1 Beyond Object Orientation

This approach has essentially taken object-oriented development one step further. The object-oriented paradigm advocates a strong commitment to describing objects in the software and how they behave. This research has shown that software can be made more understandable from a domain and a code-level perspective by formally modeling the domain, making that model explicit in some representational medium, and then expanding that model to include a specification of the software itself.

The implications of this approach should have significant impact on the way software development is carried out. It has been shown that a goal of understandability can be achieved through the medium in which the software is specified. Text-based programming language specifications serve well for compilation, but fall well short of the understandability goal. This leads to software that is difficult to maintain and to develop.

A deeper representation, such as the ontology for code-level knowledge presented here, makes information about the software more accessible. This facilitates the recognition of common obstacles to understanding, such as side-effects, delocalized plans, and vestigial code, and the implementation of tools for understanding the software, such as the user interface, different views, complex queries, etc. A deeper representation can also make the semantic consequences of certain development decisions more clear, leading to code which is itself more understandable to begin with.

No focus on software understanding would be complete without some support for understanding the domain. While previous efforts in knowledge-based software engineering have also addressed formal domain models as the foundation for software development, none have been able to present a developer or maintainer with a concrete view of that domain knowledge. This research has shown that doing so requires a second-order representation, and a facility rich enough for representing this specific kind of second-order relationship was developed which avoids undecidability.

The research has also shown that an increased facility for understanding can affect every phase of the lifecycle. Development and maintenance, in particular, can be significantly improved by providing access to information about the software and the domain. This leads to the grand vision behind this work: a formal and explicit model of the domain can serve as the foundation of a development system that is entirely domain-oriented. This system could spin off numerous applications within the domain, essentially reusing aspects of the domain knowledge relevant to each. Support, meanwhile, would center on the central artifact, the common domain model.

8.1.2 Software as a Second Order Domain

All software representations have been, to date, purely first order representations [Smith and Jullig, 1994]. This research has shown that the instances of code-level concepts like "procedure" and "data type" are themselves parts of the models of other domains, and that a code-level ontology is second order with respect to the ontologies of application domains; it is a representation of a representation language, and is fundamentally at a different "level" than traditional ontologies [Welty, 1995a].

The identification of this special nature of code-level knowledge was the key to solving the code model/domain model dichotomy. What had previously stood in the way of integrating these two types of model was the fact that they consisted of two different kinds of knowledge. By making domain modeling knowledge (not domain knowledge) part of the code-level ontology, it was possible to create the framework in which the domain model and code model could co-exist.

This framework required a knowledge representation language which supported multiple universes of discourse and certain special objects that span these universes to provide the relationships between objects at different representational levels. Based on this research, an enhancement to the knowledge representation language Classic will be made to support spanning objects. At the present time, Classic is not able to support multiple universes of discourse at once, so an temporary enhancement was made to Classic through which a completed code-level representation will automatically generate a domain ontology in a file which can then be loaded into Classic.

8.1.3 The KBEDS Ontology

The domain model for the knowledge-based email distribution system turns out to be extremely useful for representing on-line information in general, such as is found on the world-wide-web. The unique and interesting aspect of the ontology is the mechanism chosen to represent the three major concepts in the domain: information topics, items, and views. This approach facilitates an easier specification of interface, browser, and retrieval mechanisms than the rather simple representations implicit in most network information tools (like Mosaic, Gopher, etc.).

The fairly recent explosion of the WWW makes this a timely and tremendously applicable contribution [Welty, 1993] [Welty, 1994] [Welty, 1995b].


Chris Welty - Dissertation - 17 SEP 1996
[Next] [Previous] [Up] [Top] [Contents]

Generated with Harlequin WebMaker