% File:    workbench.tex
% Author:  Ingrid Wetzel and Florian Matthes
% Date:    09-AUG-1995
% Purpose: Fide-2 Book Contribution
% Note:    Requires include file "om.tex"
	
\documentstyle[xple_sl,epsf]{clmult01}

\pagestyle{myheadings}

% program text embedded within main document text
\newcommand{\p}[1]{{\sl{}#1}}

% program keyword
\newcommand{\k}[1]{{\bf{}#1}}

% emphasize
\newcommand{\e}[1]{{\em{}#1\/}}

% Bug fix for clmult01: Description labels in bold face:
\def\descriptionlabel#1{\hspace\labelsep \bf #1\hfil}

\input{om}

\title{Chapter 3.2.2\\The STYLE Workbench: \\
Systematics of Typed Language Environments}

\author{Ingrid Wetzel\inst{1} \and Florian Matthes\inst{2} \and Joachim W. Schmidt\inst{2}}

\institute{Universit\"at Hamburg, Vogt-K\"olln Stra{\ss}e 30, D-22527 Hamburg, Germany
\and 
Technical University Hamburg-Harburg, Harburger Schlo{\ss}stra{\ss}e 20, D-21071 Hamburg, Germany}

%------------------------------------------------------------------------

\begin{document}

\authorrunning{Ingrid Wetzel \and Florian Matthes \and Joachim W. Schmidt}
\titlerunning{The STYLE Workbench: Systematics of Typed Language Environments}

\maketitle

\abstract{
STYLE is a method to systematically construct a customized development
environment (CDE) for a given high-level data model by exploiting and
extending an existing persistent programming environment along three
dimensions.

On the functional dimension, polymorphic types and higher-order
functions are used to extend the system functionality with new generic
services and through the integration of external tools. On the
operational dimension, orthogonal persistence is provided for
application and meta data related to design objects. Finally, on the
modal dimension, reflective capabilities of persistent programming
environments make it possible to view data as executable code and vice
versa. This is used in a CDE to switch dynamically between different
modes of a design object.

The STYLE approach is illustrated using a concrete CDE implemented for an
object-oriented data model exploiting and extending the Tycoon
persistent programming environment. This STYLE workbench provides
integrated graphical and textual modelling tools, generation support and
data model animation.
}

%------------------------------------------------------------------------

\section{Introduction and Overview}

One of the remarkable features of persistent programming languages like
PS-algol \cite{ACC81a}, Napier-88 (see Chapter 1.1.3) and Tycoon (see Chapter 1.1.1)
is their rich set of data structuring facilities.  Languages with
orthogonal persistence and a sophisticated \e{type system} greatly
simplify the task of implementing information systems that have to work
with complex, long-lived bulk data structures (see Chapter 1.4.2).

In parallel to the development of persistent programming languages,
research in the area of database and conceptual models led to the
development of advanced \e{data models} (see, e.g. \cite{Abri74,BMS84,HuKi87}) some of which have been integrated into
database programming languages, such as Pascal/R
\cite{Schm77a}, DBPL (see Chapter 2.1.2), Galileo \cite{ACO85} and Fibonacci
(see Chapter 1.1.2).

The STYLE\footnote{Style: Systematics of TYped Language Environments.}
approach \cite{Wetz94} described in this paper clarifies the
relationship between data models and type systems. STYLE is based on the
assumption that high-level data models capture important application
semantics that are beyond the scope of type systems (see
section~\ref{Sec:AddedValue} for a more detailed discussion).
Therefore, STYLE proposes a phase-oriented design process for
information systems which involves transformation tools that
bridge the gap between a given semantic (conceptual) model and the
logical (computational) model underlying a typed programming language
\cite{BDRZ83,WSSB93}. The requirements on these tools are
described in section~\ref{Sec:TransformationTools}. Due to the
continuous evolution of data models, the set of transformation tools has
to be tailored to the data model at hand.

STYLE's main research contribution is a \e{systematic} method to
construct a customized development environment (CDE) for a given
high-level data model. A CDE exploits and extends an existing persistent
programming environment (PPE) along three dimensions as discussed in
section~\ref{Sec:StyleSpecific}. On the functional dimension,
polymorphic types and higher-order functions are used to extend the
system functionality through the development of generic services and
through the integration of external tools. On the operational dimension,
orthogonal persistence is provided for application and meta data related
to design objects. Finally, on the modal dimension, reflective
capabilities of persistent programming environments make it possible to
view data as executable code and vice versa. This is used in a CDE to
switch dynamically between different modes of a design object.

In each of these three dimensions, the CDE tools are organized into
four levels (kernel services, database functionality, data model support
and data model usage) that exhibit different degrees of reusability. The
resulting matrix architecture of a CDE is depicted in
figure~\ref{Fig:Matrix} and explained further in
section~\ref{Sec:Architecture}.

In section~\ref{Sec:CaseStudy} the STYLE approach is illustrated through a
case study, the development of an integrated workbench for the
high-level object-oriented data model OM1 \cite{SSW92} using the Tycoon
system (see Chapter 2.1.4) as the underlying persistent programming
environment. This CDE integrates multiple graphical and textual
modelling tools, application generators and animation support which
includes transactional programming and access to external servers.

%------------------------------------------------------------------------

\section{Added Value through High-Level Data Models}
\label{Sec:AddedValue}

This section discusses the main advantages of enriching a persistent
programming environment by a high-level data model, namely:
\begin{itemize}
\item provision of domain-specific conceptual abstractions,
\item system-enforced integrity beyond types, and
\item enriched generic system functionality.
\end{itemize}


\subsection{Domain-Specific Abstractions}

Data models provide domain-specific abstractions that capture the
essential modelling concepts required for the description of information
systems. Data models emphasize the conceptual modelling of an application
in terms of user concepts (e.g., classification, generalization,
aggregation) instead of implementation abstractions (e.g.,
parameterization, modularization).  These concepts are made available in
a user-oriented language with a mnemonic syntax (with keywords chosen are
close to natural language) that is easy to write and to understand. Many
data models also specify an alternative or additional graphical
representation.

Data models are a medium for the communication between software
engineers and users during the modelling process and at the same time they should
provide a precise specification of the system to be realized. 
Therefore, data models tend
to blur the borderline between conceptual and computational perceptions of
an information system.


\subsection{System-Enforced Integrity beyond Types}

Some data model concepts can be captured directly by type systems,
others are beyond the scope of even the most sophisticated type systems.
Nevertheless, it is possible to provide language and system support for
these concepts (like exception handling, run-time integrity checking or
active rules) that leads to a system-enforced integrity beyond types.
The following discussion of object-oriented data modelling concepts
may explain this idea which is central to the STYLE approach.
 
An object has structural properties described in terms of attributes. An
attribute can have a complex structure and it can reference other
objects. A specialized object may inherit attributes of a more generic
object, possibly with restrictions on their attribute domains. Classical
type systems suffice to describe and enforce such structural object
properties (perhaps lacking a user-oriented presentation). The fact that
an object has an immutable identity during its full lifetime is also
captured easily in a typed persistent language.

A class describes objects with the same set of properties.  In the
context of data models, a class serves several purposes which are
partially incompatible with the notion of a typed class in
object-oriented programming \cite{Wetz94}. First, a class gives a
structural description of objects (\e{intensional aspect}). In data models
a class also 
denotes a set of objects with the same structure (\e{extensional
aspect}). In some data models, the identification of an object is also
based on its class (\e{identification aspect}). Finally, a class
provides generic standard methods for creating, deleting, observing and modifying
objects (\e{dynamic aspect}).

The interaction between the intensional and the dynamic aspects of a
class leads to the difficult problem of how to handle the restriction of an
attribute domain when an object is specialized. A domain restriction
makes perfect sense from a modelling perspective but implies a covariant
method specialization which leads to well-known difficulties in static
type systems for which -- up to now -- no satisfactory solution has been
found \cite{Coo89}.

The extensional aspect of a class also goes beyond pure static type
constraints. At first glance, it appears sufficient to declare a
persistent bulk type variable to store the set of complex objects that
make up the extent of a class. However, plain insert and delete
operations on a class extent do not enforce an extensional aspect of
classes, namely that the extent of a subclass is a subset of the extent
of all its superclasses. This subset constraint can be enforced easily
by a programming methodology where, for example, an object inserted in a
class is automatically inserted into its (transitive) superclasses.
Similarly, referential integrity constraints on class extents are
introduced if objects in one class reference objects in other classes.
Again, the verification of such inter-class constraints is beyond the
scope of type systems.

Finally, some data models permit an object to migrate between classes that
are not in a subclass relationship at all and to dynamically lose attributes
during its lifetime without changing its object identity. Such
operations can change dynamically the type of an object which has been
bound to an identifier in a scope different from the scope of the update
operation (for example, in another transaction). Therefore, such
operations cannot be type-checked statically, even in languages with
flexible subtyping or type matching rules. However, by enforcing a
programming methodology that correctly propagates a
type change of an object \p{o} to all scopes that possibly reference
\p{o}, global application integrity can be ensured at run-time.


\subsection{Enriched Generic System Functionality}
 
Data models traditionally provide standard generic methods for objects
of any class (create, delete, update, acquire attribute, lose attribute,
\ldots). These methods have to satisfy (at least) the model-inherent
integrity constraints. As discussed in the previous subsection, the
semantics of these generic methods may depend on global schema
information and can therefore not be captured fully by type systems that
rely on local type information only.

As described in \cite{STSW92}, the code of such generic methods can be
generated automatically based on the information provided by a data
model. In a persistent programming environment, type-directed
reflective programming techniques can be utilized to simplify this code
generation process \cite{Wetz94}. 

%------------------------------------------------------------------------

\section{Data Modelling with STYLE}

As explained so far, the STYLE approach supports a high-level data model
by a customized development environment (CDE) that extends the
functionality of a typed persistent programming environment.

Based on a classification of the tasks and tools in such a CDE given in
section~\ref{Sec:TransformationTools}, the advantages of the STYLE
approach which utilizes the PPE \e{itself} for the tool implementation
are explained in section~\ref{Sec:StyleSpecific}.
Section~\ref{Sec:Architecture} presents the generic matrix architecture
underlying all CDEs that are built following the STYLE approach.

\subsection{A Classification of Data Modelling Tools and Tasks}
\label{Sec:TransformationTools}

A CDE consists of a highly connected and smoothly integrated set of
tools that automate work patterns which are typical for the design and
implementation of an information system using a high-level data model.
One can classify these tools based on the work patterns they support.

\begin{description}

\item[Modelling tools:] On the data model level a CDE provides schema
browsers and editors for graphical and textual modelling. Additionally,
it assists in analyzing the status and the consistency of a schema
through navigation tools (like class hierarchy, class association and
integrity rule browsers) as well as local and global static schema
checkers which are very similar to type checkers. Advanced CDEs
automatically propagate local renaming and restructuring operations
between different components of a large data model to ensure global
schema consistency.

\item[Generator tools:] A CDE offers generators that map between
different views (or modes) of a design object. On the data-model level,
generators can ensure the consistency between textual and graphical
schema representations.  Code generators bridge the gap between data
model and type system by generating type specifications enriched with
procedural or declarative code to ensure the maintenance of high-level
model-inherent and user-defined integrity constraints by the generic
methods that insert, delete and update objects. Since the preservation
of integrity constraints is central to the STYLE approach
\cite{SSSTW92}, the methods generated have transaction semantics
with recovery functionality. Finally, generators can also be used to
provide graphical or textual user interfaces that visualize typed
persistent objects in a way that is consistent with the high-level data
model.

\item[Integration facilities:] A CDE should integrate the 
modelling and generator tools described above and should provide analysis and
visualization facilities for the whole design process. In particular,
dependency information between design objects at different levels of
abstraction should be recorded and, if possible, be exploited for
automatic view and change propagation.
\end{description}

\subsection{Specifics of the STYLE Approach}
\label{Sec:StyleSpecific}

The systematic and flexible customization of development environments in
STYLE exploits and expands the underlying PPE along three dimensions
that should be orthogonal to each other to achieve maximum modelling and
system flexibility \cite{Wetz94}.
\begin{description}
\item[Functional dimension:] A rich language semantics including subtyping,
polymorphism and higher-order functions enables the construction of
libraries with generic services including type-safe wrappers for
external design tool integration.

\item[Operational dimension:] Orthogonal persistence (object lifetimes
independent of object types), distribution abstraction, multi-threading
and orthogonal mobility of data, code and threads, greatly simplify the
construction of CDEs.

\item[Modal dimension:] Modern persistent programming environments 
provide multiple, typed views onto code and data objects (concrete
syntax, abstract syntax, intermediate code, executable code) and
flexible bidirectional mappings between these modes as provided, for
example, by extensible grammars (see Chapter 3.2.3) and reflective programming
techniques \cite{SSF92}. This can be exploited in a design environment
to realize flexible mode switches on design objects.

\end{description}
Each of these dimensions contributes to specific tasks in the
construction of a CDE as follows.

\begin{description}
\item[Functional dimension for tool building:]
The positive consequences of using a strongly and polymorphically-typed
PPE for CDE construction can be summarized as follows.
\begin{itemize}

\item Information system construction and design tool construction take
place in the same language and system framework which facilitates code
sharing and code re-use.

\item The components of a CDE can be provided as an open set of typed
libraries working on shared persistent data structures and not as a
loosely coupled set of applications that exchange design information in
an ad-hoc manner via files, command-line arguments or message queues.
As sketched in figure \ref{Fig:Matrix}, and discussed further in
the next section, these libraries can be organized systematically into a
matrix architecture.
\end{itemize}

\begin{sloppypar}
\item[Operational dimension for meta data management and analysis:]
Information system development is itself a data-intensive application
\cite{JMW*90} since it is necessary to store and retrieve bulk (meta)
information about design objects (like graphical schemata, textual class
definitions, or module interfaces) and design decisions. A design
decision is an annotated relationship between design objects. For
example, a design decision may relate a specification and several
alternative implementations to an annotation that explains why a
certain alternative was chosen.
\end{sloppypar}

The consequences of utilizing a PPE for CDE construction are obvious.
\begin{itemize}
\item Meta data of complex structure can be stored persistently without
the need for complicated transformations into a canonical repository
data format.
\item Schema analysis and browsing tools can utilize tailored bulk data
structures and high-level iteration abstractions to query meta data.
\item It is possible to define declarative views on a design object that
correspond to different levels of abstraction in a
graphical schema or to multiple refinements of a design object.
\item Change propagation can be realized by meta data analysis and
updates exploiting integrity constraints defined for the meta data model.
\end{itemize}

\item[Modal dimension for generation support:] In STYLE, the graphical
representation of a class, its textual description, its corresponding
module and its GUI to visualize class instances are regarded as
different modes of a single design object. Each mode has its own
operations and tool support. Switches between different modes are
implemented by parsers and generators that typically make use of the
modal base services of a PPE.

\end{description}
%
A key characteristic of STYLE is the \e{integration} of the CDE tools as
typed modules in an open persistent programming environment. This makes
it possible to implement flexible cross-calls between tools for
navigation purposes and to factor-out shared functionality like queries
on meta data, generators or dependency tracking. A shared,
strongly-typed and persistent meta data repository also contributes to a
tight tool integration. Furthermore, external services can be integrated
seamlessly by means of wrapper modules with strongly-typed interfaces.


\subsection{The STYLE Matrix Architecture}
\label{Sec:Architecture}

On each of the three dimensions identified in the previous section, the
CDE tools are organized into four layers (kernel services, database
functionality, data model support and data model usage) that exhibit
different degrees of reusability. The resulting matrix architecture of a
CDE is depicted in figure~\ref{Fig:Matrix}.

\begin{figure}[htb]
\begin{center}
\leavevmode
\epsfxsize=\textwidth
\epsffile{stylesyst.epsf}
\end{center}
\caption{The architecture of a STYLE customized development environment}
\label{Fig:Matrix}
\end{figure}

\noindent
The CDE is realized as a layered library of typed modules of the target
persistent programming environment. The services of higher library
layers are implemented based on services of lower library layers.

For example, the kernel services \p{bulk} and \p{iter} provide multiple bulk
data structures (lists, sets, bags) and iteration abstractions
(selection, projection, join) that are utilized by a generic integrity
checking layer \p{IC check} that implements predicative integrity
checking on multiple bulk types. These services are specialized further
in the next layer to support the inherent integrity constraints of a
specific data model. The topmost layer is responsible for the
presentation of these services to the user.

A similar layering applies to the operational and modal dimension. Some
of the modules are simply wrappers for external tools (like text editors
or graph editors) and external services (like SQL databases or GUI
libraries). 

A typical user of a CDE environment is not aware of the fine-structure
of these tools but interacts directly with an integrated STYLE workbench
that provides modelling, generation, programming and integration support.

An application described in a given high-level data model is transformed
with the help of the CDE tools into a self-contained but open
application library in the target language TL. This library consists of
generated TL interfaces and modules which exploit the type system of the
target language and utilize at run-time modules of the CDE itself to
provide system integrity beyond typing. This dependency between
applications and the CDE is indicated by horizontal arrows from the
application library to the three lower levels of the CDE library.

%------------------------------------------------------------------------


\section{A CDE for an Object-Oriented Data Model} 
\label{Sec:CaseStudy}

In this section, the STYLE approach is illustrated by the description of a
specific CDE, an integrated workbench for the high-level object-oriented
data model OM1 \cite{SSW92} using the Tycoon system
(see Chapter 2.1.4) as the underlying persistent programming environment.

\subsection{Overview of the OM1 Data Model}
 
\begin{figure}
\begin{center}
\leavevmode
\classb{PackageTour}
\relationships{
\specialization{
\ii \oisA Tour \ofix\\
}
\dependencies{
\ii \odeleteDependentOn Hotel \owith removePackageTourWithHotel,\\
\ii \odeleteDependentOn Flight ...
}
}
\structure{
\attributes{
\ii \okey region : \orf Region,\\
\ii \okey town : \orf Town,\\
\ii hotel : \orf Hotel,\\
\ii flights : \orecord{forth : \orf Flight, back : \orf Flight}
}
}
\constraints{
\static{
\ii HotelFlight:\\
\ii (\othis.hotel.region = \othis.flights.forth.destAirport.region) $\wedge$\\
\ii (\othis.hotel.region = \othis.flights.back.depAirport.region),\\
\ii (* the forth flight's destination airport and the return flight's\\  
\iii departure airport must belong to the same region as the hotel *),\\
\ii ...
}
}
\methods{
\transactions{
\ii removePackageTourWithHotel\\
\iii (packageTour : \orf PackageTour date : Date) =\\
\iii \obegin\\
\iiii ActualizedTour.modifyWithPackageTour(packageTour date);\\
\iiii removePackageTour(packageTour)\\
\iii \oend\\
\ii ...
}
}
\classe{}
\end{center}
\caption{A class definition in the object-oriented data model OM1}
\label{Fig:PackageTour}
\end{figure}

\noindent The data model OM1 is based on concepts of semantic data models
\cite{HuKi87,BMS93} which emphasize the structural definition of
objects. In addition, it provides additional constructs for formulating
inter-object integrity constraints. Furthermore, OM1 is influenced by a
formalization of object-oriented data models that supports both,
structured values and objects \cite{Beer90,Beer92a,SSW92,STW92}.  An
application schema consists of a set of type and class definitions.
Values are grouped into types describing immutable sets of values with a
uniform structure together with operations defined on such
values. Objects are abstractions of real-world entities and have an
identity. This identity is independent of the values which are used to
describe objects. Object identifiers are immutable during an object's
lifetime. Objects with the same structure and behaviour are grouped into
classes providing mutable collections as well as abstractions of
individual objects. Relationships between objects are expressed by
reference attributes.  The description of multiple aspects or roles of
the same object is modelled by simultaneous membership of an object in
more than one class and by the migration of objects between classes.

OM1 has the usual model-inherent subclass and referential integrity
constraints and supports the formulation of user-defined integrity
constraints.

Application-specific object behaviour is expressed in the OM1 data model
using a calculus derived from formal specification languages
\cite{DiSc89,Nels89} \cite{SSW*91}. It is not necessary to specify
standard query and update methods that satisfy the integrity
constraints. Instead of this, integrity-preserving implementations for
these methods are provided by the data model.

\noindent
Figure~\ref{Fig:PackageTour} gives an example of a textual OM1 class
definition.  The class \p{PackageTour} is part of a larger information
system for travel agencies. The main classes of this application are
flights, hotels and package tours (see also the nodes and arcs in the
schema graph depicted in figure~\ref{Fig:Integration}). Each package
tour consists of a pair of back and forth flights together with hotel
information. A user-defined integrity constraint states that the area
specified for the flights has to match the area specified for the hotel.

\subsection{User-Oriented Modelling Tools}

The actual implementation of the OM1 CDE integrates the following
modelling tools, some of which are visible in
figure~\ref{Fig:Integration}.

\begin{figure}[htb]
\begin{center}
\leavevmode
\epsfxsize=\textwidth
\epsffile{integrated.ps}
\end{center}
\caption{Integration of components in a STYLE workbench}
\label{Fig:Integration}
\end{figure}

\begin{itemize}

\item A graphical schema editor is used to define class and type nodes with
class reference arcs and inheritance links between classes. The editor
supports views of different granularity.  

\item A class and type browser is used to select class and type names
defined in a schema, for example, to invoke a text editor on a class.

\item A textual class editor and a textual type editor are used to
specify class components and type structures.

\item Additional tools support the parsing, consistency checking and the
generation of pretty-printed LaTeX documents for (parts of) an OM1 schema.

\item A generator maps graphical OM1 class diagrams into corresponding
textual OM1 class definitions. 

\item A toolbox provides additional local and global consistency 
checks and mechanisms to propagate changes in an OM1 schema (for example,
class or attribute renaming). These algorithms can be invoked
interactively from virtually all CDE tools.
\end{itemize}


\subsection{Application Generators}

\begin{figure}[htb]
\begin{xple}
\k{interface} PackageTour
\k{import}
  :OM1Object  :Iter  :Type  :Country  :Area  :Hotel  :Flight  :Town
  tour  town  flight  hotel  area  country
\k{export}
   error :\k{Exception} \k{with}  \k{end}
   T $<:$tour.T
   ...
   getKey :\k{Fun}(o :T) :KeyT
   keyEqual :\k{Fun}(k1 :KeyT k2 :KeyT) :Bool
   lookup :\k{Fun}(k :KeyT) :T
   lookupObject :\k{Fun}(o :OM1Object.T) :T
   create :\k{Fun}(v :InputT) :T
   remove :\k{Fun}(o :T) :\k{Ok}
   fromTour :\k{Fun}(o :tour.T v :AddT) :T
   getTourNo :\k{Fun}(o :T) :Int
   getCountry :\k{Fun}(o :T) :country.T
   getTravelTime :\k{Fun}(o :T) :Type.TravelTime
   getArea :\k{Fun}(o :T) :area.T
   getTown :\k{Fun}(o :T) :town.T
   getHotel :\k{Fun}(o :T) :hotel.T
   getFlights :\k{Fun}(o :T) :\k{Record} forth :flight.T  back :flight.T \k{end}
   setTravelTime :\k{Fun}(o :T  travelTime :Type.TravelTime) :\k{Ok}
   setFlights :\k{Fun}(o :T  flights :\k{Record} forth :flight.T  back :flight.T \k{end}) :\k{Ok}
   elements :\k{Fun}() :Iter.T(T)
   classInfo :\k{Tuple} name :String  \k{end}
\k{end};
\end{xple}
\caption{A typed Tycoon implementation of the OM1 class \p{packageTour}} 
\label{Fig:Interface}
\end{figure}

\noindent
An OM1 class definition consists of structure, constraint and method
specifications and is implemented by typed interfaces and modules in the
Tycoon language TL (see figure~\ref{Fig:Interface}). The TL
implementation defines encapsulated objects with standard methods that
satisfy the model-inherent and user-defined constraints.  Access to the
TL objects is only possible through the generated standard
methods. User-defined class methods correspond to transactions of the
information system and are built on top of the standard methods. As
indicated in figure~\ref{Fig:Interface}, the standard methods raise
exceptions to signal integrity violations which can then be handled by
the application code without breaking the encapsulation of the object.

The interfaces and modules created for class definitions extend the
Tycoon environment with an application-specific library.  The generated
modules can be kept concise by utilizing pre-existing
data-model-specific libraries of the CDE to factor out repeating tasks
from the generated code. The provision of data-model-specific libraries
is termed \e{situative lifting of the target language} in the STYLE
approach.
 
The cooperation between TL code generators and the generic CDE services
can be exemplified by the integrity checking task of a CDE. For a
specific OM1 integrity constraint (e.g., referential integrity between
two classes), preconditions and delayed conditions have to be generated
for the insert and delete methods of the classes involved. Instead of
hard-wiring these conditions into the method's implementation code, a
generic TL library for constraint handling is utilized. It provides
dynamic collections of constraints (implemented as bulk collections of
function values in TL) that can be attached dynamically to methods. As a
consequence, the constraint handling is fully separated from the OM1
interface and module generation process. Global OM1 constraints are
transformed into boolean TL predicates which are then attached
dynamically to the relevant methods.

The main benefit of this approach is \e{locality}. A local update of a
single class definition leads to a local update of the corresponding TL
class implementation and a reinitialization of the constraint database.
No other method code needs to be recompiled.

\subsection{Animation Support}

An animation component provides a generic database browser to create,
delete and update individual objects (instances of classes) and to
navigate through the persistent object base following the (set-valued)
associations between objects. The animation tool uses the generated
application modules to guarantee the enforcement of integrity
constraints specified in the data model. The type-specific visualization
code is also generated automatically.

\subsection{Integration with Tycoon Transaction Code}

Arbitrary user transactions can be implemented on top of the generated
class implementations using the algorithmically-complete persistent
programming language TL. For example, a user-defined method
\p{removeHotel} can extend the functionality of the \p{hotel.remove}
operation by rebooking all package tours prior to the removal of a
hotel. See \cite{Sche94b} for a discussion on how generic methods and
user-defined transaction code have to interact to maintain the
consistency in an object base.

The language TL also provides mechanisms to enable interoperability of
OM1 applictation code with existing (legacy) database systems like
Ingres, Oracle and ObjectStore.


\subsection{Application Development Using the Integrated Prototype}

Figure~\ref{Fig:Demo} sketches the main modelling steps supported by the
OM1 customized development environment. First, the structural schema
information is modelled using the graphical editor.

Based on this information the structural part of the textual class
definitions is generated. Interactive queries at the schema level can be
utilized to detect incomplete schema information, e.g. references to
undefined classes. Integrity constraints and user-defined class methods
are also added at this stage using a structured-text editor. Navigation
facilities to referenced and referencing classes simplify the
formulation of inter-class integrity constraints.

The programming layer is automatically populated with the generated
class interfaces and modules implementing the standard methods. The
application programmer implements the user-defined methods on top of
these interfaces. If necessary, user-defined methods can also override
standard methods.

The animation component supports the validation of an OM1 model by
populating a persistent object base with sample objects and by invoking
standard and user-defined methods on these objects. The visualization
code generated for the animation can also be reused and adapted for use
after the prototype phase.

\begin{figure}[htb]
\begin{center}
\leavevmode
\epsfxsize=\textwidth
\epsffile{styledemolayer.epsf}
\end{center}
\caption{Tasks and tools involved in the OM1 modelling process}
\label{Fig:Demo}
\end{figure}


\section{Concluding Remarks}

The customized development environment for the OM1 data model clearly
demonstrates that persistent programming environments are a suitable
platform for both the construction of data-intensive applications
utilizing a high-level data model as well as for the construction of
tightly integrated design and modelling tools.

The distinction between functional, operational and modal requirements
was of great use in the organization of the STYLE tool
infrastructure. It remains to be verified how much of this
infrastructure can be re-used for the construction of other CDEs.

\begin{acknowledgement}
This research is supported by ESPRIT Basic Research, Project FIDE,
\#6309.
\end{acknowledgement}

%-------------------------------------------------------------------------

\small 
\bibliographystyle{plain}
\bibliography{../dbis-macros,../florian}

\end{document}
  
