Database Organization for Application Generation

Bruce I. Blum
The Johns Hopkins University (Retired)

The software process can be described as a transformation from a need to a software product designed to respond to that need. Because the response alters the need (and the understanding of it), the process decomposes into iterations of a three-step modeling cycle. The first step models how the target software product will respond to the need; this descriptive model is called a conceptual model. (In this context, the conceptual model is assumed to contain descriptions of both the target database and the operations to be performed by the target product.) The next step transforms the conceptual model into a formal model that prescribes what the software is to do, and the final step realizes an implementation that is correct with respect to the formal model (e.g., the specification). Traditionally, the first iteration is called development, and all subsequent iterations are called maintenance.

For some domains, it is possible to derive a representation scheme that is at once conceptual and formal (i.e., one that both describes and prescribes). Moreover, for relatively mature domains it may be possible to transform automatically the formal model into its implementation. If this can be done, then the software process reduces to a conceptual modeling activity where the model serves as an as-built specification of the target system. (In contrast, the three-step process views the formal model as a build-to specification.)

The domain of interactive information systems is sufficiently mature to support this development paradigm. During the past 14 years, this fact has been demonstrated with an environment that (among other things) has been used to build and maintain a million-line clinical information system that supports life-threatening decision making. This environment maintains a data base (described as relations) that contains the conceptual model and the transformations used to realize the implementation.

This talk considers the knowledge necessary for the automatic generation of applications, how such knowledge may be classified and organized, and the implications of adopting this alternative paradigm. Experience with the Johns Hopkins Oncology Clinical Information System (OCIS) is summarized.