% ------------------------------------------------------------------ %
%                                                                    %
% Datei: werkzg2.tex                                                 %
% Autor: Oliver Nietsch                                              %
%                                                                    %
% Universitaet Hamburg                                               %
% Fachbereich Informatik                                             %
% Arbeitsbereich DBIS                                                %
%                                                                    %
% Thema: Diplomarbeit: Die Modellierung und Validierung dynamischen  %
%                      Systemverhaltens am Beispiel von StP/OMT      %
%                      und Tycoon                                    %
%                                                                    %
% Inhalt: LaTeX-Dokument: Diplomarbeit,                              %
%                         Kapitel 2: Werkzeugorientierte System-     %
%                                    entwicklung, Teil 2/2           %
%                                                                    %
% Version vom 18. 4.1997                                             %
% ------------------------------------------------------------------ %

\section{Die CASE Umgebung Software through Pictures (StP/OMT)}
\label{Sec:StPOMT}

Software through Pictures (StP) der Firma Interactive Development Environments (IDE) entspricht dem in Abschnitt~\ref{SubSec:Integration} dargestellten Ansatz integrierter CASE Umgebungen. Bei StP handelt es sich um eine Familie integrierter Mehrbenutzer CASE Umgebungen zur Entwicklung neuer und zum \engl{Re-Engineering} bestehender Systeme.

Jedes StP Produkt beinhaltet eine Familie integrierter Werkzeuge, zum Beispiel, wie in der Abbildung~\ref{Fig:Architektur} skizziert, grafische Editoren oder Tabelleneditoren f"ur die Systemmodellierung, Systeme zur Dokumenterstellung, Schnittstellen zu Versionskontrollsystemen etc.. Die Grafikeditoren innerhalb von StP/OMT unterst"utzen die in Abschnitt~\ref{Sec:OOMod} vorgestellte objektorientierte Methode OMT zur Softwareentwicklung auf integrale Art.

Alle StP Produkte benutzen eine gemeinsame Entwicklungsdatenbank, das in Abschnitt~\ref{SubSec:Repository} erl"auterte StP Repository. Somit realisiert die CASE Umgebung Software through Pictures eine in Abschnitt~\ref{SubSec:Integration} dargestellte offene Architektur, da die Werkzeugkommunikation "uber die Entwicklungsdatenbank unter Ber"ucksichtigung von Netzwerk-, Druck- und Benutzeroberfl"achenstandards erfolgt. Diese offene Architektur erm"oglicht eine Erweiterung oder Individualisierung der StP Umgebung. Dies wird in der Arbeit ausgenutzt, um eine Validierungskomponente in die Umgebung zu integrieren (vgl. Kapitel~\ref{Chap:Validierung}).

\subsection{Architekturmerkmale}
\label{SubSec:ArchitekturStP}

Zur Unterst"utzung der Anwendungsentwicklung bietet StP/OMT, wie in der Abbildung~\ref{Fig:Architektur} angedeutet, eine Menge grafischer Werkzeuge, welche die OMT Entwicklungskonzepte in allen Phasen des Softwarelebenszyklus unterst"utzen \cite{klees94}. Diese die Methode OMT implementierenden grafischen Werkzeuge sind wie allgemeine StP Komponenten oberhalb eines methodenunabh"angigen Kerns und unterhalb des StP Desktops angeordnet. Der methodenabh"angige Kern besteht aus dem StP Object Management System, Systemdateien (\engl{System Files}) und dem StP Repository.\\

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{figure=omtarch2.eps,width=10.5cm}
  \end{center}
  \caption{\label{Fig:Architektur} StP/OMT Architektur}
\end{figure}

Die Abbildung~\ref{Fig:Architektur} zeigt den schematischen Aufbau einer StP CASE Umgebung am Beispiel von StP/OMT. Die Werkzeuge der oberen Zeile der wei"s dargestellten Komponenten werden bei einem anderen CASE Werkzeug der StP Produktfamilie (z.B. StP Information Modeling StP/IM \cite{StPim93}) durch methodenad"aquate Komponenten substituiert. Die grau unterlegten Grundkomponenten der StP Umgebung stellen die Voraussetzung f"ur die Integration aller StP Werkzeuge dar.

Die in Kapitel~\ref{Chap:Anbindung} vorgestellte Anbindung des Tycoon Systems an die StP Umgebung erfolgt, wie in der Abbildung~\ref{Fig:TycAnbindg} dargestellt, unterhalb des StP Desktops und oberhalb des StP Kerns, also parallel zu den anderen installierten Werkzeugkomponenten.

\subsection{Basisdienste des StP Kerns}
\label{SubSec:Basis}

Alle Produkte der StP Familie sind oberhalb eines methodenunabh"angigen Kerns angesiedelt. Dieser leistet die in Abschnitt~\ref{SubSec:Anforder} geforderten grundlegenden Dienste der integrierten StP Entwicklungsumgebung, auf welche die jeweiligen StP CASE Werkzeuge zugreifen. In unterschiedliche Kategorien zusammengefa"st handelt es sich konkret bei diesen Diensten um das Desktopmanagement, die Proze"smodellierung, die Versionskontrolle und das Konfigurationsmanagement, die Mehrbenutzerkoordination, die Systemindividualisierung und Erweiterbarkeit sowie die optimale Visualisierung komplexer Diagramme \cite{StPwp93}.

F"ur die Realisierung dieser Arbeit sind das Objektmanagement, die Repositoryverwaltung und die G"ultigkeitspr"ufung als Dienste des StP Kerns zu betrachten.

\subsubsection*{Objektmanagement}
\label{SubSubSec:ObjMan}

Das StP Object Management System (OMS) implementiert das in Abschnitt~\ref{SubSec:Repository} dargestellte Informationsmodell StP Persistent Data Model (PDM), nach dem die werkzeugunabh"angige Ablage der StP/OMT Modellierungsdaten im Repository erfolgt. Au"serdem stellt es den Zugriff auf das StP Repository durch eine Menge von Operationen zur Verf"ugung. Somit definiert das OMS die Schnittstelle zwischen Werkzeugen der StP Umgebung und dem Repository. Eine Interaktion zwischen einem Werkzeug und dem OMS kann mit Hilfe der in Abschnitt~\ref{SubSec:ZugriffRep} vorgestellten StP Query and Reporting Language (QRL) oder dem StP Application Program Interface (API) erfolgen.

\subsubsection*{Repositoryverwaltung}
\label{SubSubSec:RepMan}

Die Verwaltung des Repositorys erfolgt auf der Grundlage des relationalen Datenbankverwaltungssystems {\sf Sybase} in einer heterogenen \engl{Client Server} Umgebung. Der Zugriff auf die Datenbankverwaltung wird direkt vom OMS umgesetzt, ohne dabei einen n"aheren Einblick in das zugrundeliegende relationale Datenbankmodell zu gew"ahren. Mit Hilfe von {\sf Sybase SQL} oder "ahnlicher StP unabh"angiger Datenbankwerkzeuge kann der Zugriff auf die Repositoryobjekte auch unter Umgehung des StP Object Management Systems realisiert werden. Diese M"oglichkeit des Zugriffs auf die Entwicklungsdatenbank ist jedoch kein Untersuchungspunkt dieser Arbeit.

\subsubsection*{G"ultigkeitspr"ufung}
\label{SubSubSec:ValMan}

StP Umgebungen bieten im Zusammenhang mit der Repositoryverwaltung noch einen weiteren Dienst zur Erzielung von Konsistenz innerhalb des Entwicklungsprozesses. Beim Speichern erstellter Modellierungsobjekte im Repository werden diese auf syntaktische Korrektheit "uberpr"uft. Sind Integrit"atsbedingungen im Rahmen des StP Persistent Data Models mi"sachtet oder ist eine Abbildung eines erweiterten Anwendungsdatentyps auf einen StP PDM Datentyp nicht m"oglich, so kann das betreffende Objekt nicht im Repository abgelegt werden.

\subsection{Das StP Repository}
\label{SubSec:Repository}

Jede einzelne in der Abbildung~\ref{Fig:Architektur} dargestellte StP/OMT Werkzeugkomponente ben"otigt oder erzeugt eine Vielzahl von Informationen innerhalb des Entwicklungsprozesses. In der verteilten \engl{Client Server} Umgebung entsteht somit innerhalb eines jeden Werkzeugs eine hohe Anzahl von Zugriffsoperationen auf die Datenbasis aller Entwicklungswerkzeuge. Das Repository integriert s"amtliche Datenbasen aller Werkzeuge der StP Umgebung. Es ist der "`zentrale Speicher"' der Projektinformation \cite{StPoms94}.

Um eine anwendungsunabh"angige Speicherung der Modellierungsobjekte in der Entwicklungsdatenbank zu erreichen und ein hohes Ma"s an Konsistenz innerhalb des Anwendungsentwicklungsprozesses zu erzielen, verwenden alle Werkzeuge der StP Umgebung das StP Object Management System. Es beinhaltet neben dem in diesem Abschnitt dargestellten Datenmodell und Zugriffsoperationen die in der StP Query and Reporting Language enthaltene OMS Query Language und das StP Application Program Interface (API), um auf Repositoryobjekte werkzeugunabh"angig zugreifen zu k"onnen.

\subsubsection*{Persistent Data Model (PDM)}
\label{SubSubSec:PDMModell}

Das StP Persistent Data Model ist ein konzeptuelles Schema, welches die Attribute und Beziehungen von Repositoryobjekten auf der Basis abstrakter Datentypen definiert. Somit entsteht f"ur jede Anwendung die gleiche Zugriffssicht auf die im Repository abgelegten Objekte \cite{StPoms94}.

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{figure=pdm.eps,width=13cm}
  \end{center}
  \caption{\label{Fig:PDModell} StP Persistent Data Model (PDM)}
\end{figure}

Die in der Abbildung~\ref{Fig:PDModell} dargestellten abstrakten PDM Datentypen stehen in einer Sub\-typ\-be\-ziehung. Das hei"st, da"s jeder Typ in einer Sub-/Supertypbeziehung zu einem anderen Typ steht. Der {\sl CASE Type} ist der Supertyp aller anderen Typen dieses Datenmodells. Supertypen, wie der {\sl CASE Type}, der {\sl Annotated Object Type}, der {\sl Reference Type} und der {\sl Software Engineering (SE) Type} werden als abstrakte Klassen bezeichnet und k"onnen nicht direkt im Repository gespeichert werden. Nur die Subtypen, die nicht Supertypen anderer Typen sind, k"onnen als Repositoryobjekte instantiiert werden. Eine Interpretation s"amtlicher StP PDM Datentypen erfolgt an dieser Stelle nicht. Tabellen aller PDM Datentypen und ihrer Attribute befinden sich in \cite{StPoms94}.

\subsubsection*{PDM Datentypen und Beziehungen}
\label{SubSubSec:PDMTypen}

Abgesehen von den konzeptuellen Sub-/Supertypbeziehungen stehen die StP PDM Datentypen noch in einer f"ur die Ablage der Modellierungsobjekte im StP Repository wesentlichen Beziehung: Zwischen Objekten der PDM Datentypen gelten referentielle Beziehungen \cite{StPoms94}.

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{figure=integr.eps,width=13cm}
  \end{center}
  \caption{\label{Fig:PDBeziehg} Integrit"atsbedingungen zwischen StP PDM Datentypen}
\end{figure}

Die in der Abbildung~\ref{Fig:PDBeziehg} dargestellten Integrit"atsbedingungen zur Speicherung von Objekten im Repository haben einen gro"sen Einflu"s auf die in Abschnitt~\ref{Sec:Modellierg} vorgeschlagene Modularisierung der zu erstellenden Bibliothek auf der Tycoon Ebene hinsichtlich ihrer Typisierung.

Beispielsweise kann ein {\sl cntx} Objekt nicht im Repository abgelegt werden, solange das referenzierte {\sl link} Objekt dort noch nicht vorhanden ist. In der Abbildung~\ref{Fig:PDBeziehg} stellen Pfeile die referentiellen Abh"angigkeiten zwischen Objekten dar. Die Existenz eines {\sl link} Objekts ist die Voraussetzung f"ur die Ablage des abh"angigen {\sl cntx} Objekts im Repository. 

Objektattribute, deren Name auf {\sl \_id} endet, verweisen also auf ein Repositoryobjekt (vgl. Fremdschl"ussel im relationalen Datenmodell). Ein mit einem Stern ({\sl *}) gekennzeichnetes Attribut eines Repositoryobjekts, z.B. {\sl annot\_file\_id*}, kann den Wert 0 annehmen, was bedeutet, da"s das Object Management System bei der Speicherung dieses Objekts im Repository nicht auf der Existenz eines von diesem Objekt referenzierten Objekts besteht.

\subsection{Anwendungssicht auf das StP Repository}
\label{SubSec:Sicht}

Die Verbindung zwischen den Modellkomponenten von StP/OMT Werkzeugen und den Datentypen des StP Persistent Data Models wird mit Hilfe der Abbildungsdatei {\tt omt.app.types} realisiert. Die Anwendungssicht auf das StP Repository ist in der Abbildung~\ref{Fig:AnwSicht} dargestellt \cite{StPoms94}. Darin werden StP/OMT Werkzeuge als Anwendung bezeichnet.\\

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{file=rep.eps,width=12cm}
  \end{center}
  \caption{\label{Fig:AnwSicht} Anwendungssicht auf das StP Repository}
\end{figure}

Bei der Abbildungsdatei {\tt omt.app.types} handelt es sich um eine um beliebige Anwendungsdatentypen erweiterbare Datei, welche die von StP Werkzeugen referenzierten Anwendungsdatentypen auf die vom StP Repository verwendeten PDM Datentypen abbildet \cite{StPoms94}.

In der Abbildung~\ref{Fig:appTyp} ist ein Ausschnitt der erweiterbaren Datei {\tt omt.app.types} wiedergegeben, in dem einige Anwendungsdatentypen des dynamischen StP/OMT Modells definiert sind (\engl{Application Type}), die auf einen StP \engl{Persistent CASE Object Type} (hier: {\tt ItemObject}, {\tt LinkObject}, {\tt NodeObject}) abgebildet werden.\\

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{file=dynapp.eps,width=14.5cm}
  \end{center}
  \caption{\label{Fig:appTyp} Abbildung von StP Anwendungsdatentypen auf PDM Datentypen}
\end{figure}

Dabei wird jedem Anwendungsdatentypen ein eindeutiger Identifikator (\engl{Identifier}) vom Typ {\tt int} zugeordnet, der im StP Repository mit den entsprechenden Repositoryobjekten abgelegt wird. Jeder \engl{Persistent CASE Object Type} entspricht einem g"ultigen PDM Datentyp (hier: Typen {\sl item}, {\sl link}, {\sl node}), dessen Attribute an jeden auf diese Weise definierten Anwendungsdatentypen vererbt werden (vgl. Abbildung~\ref{Fig:PDModell} auf Seite~\pageref{Fig:PDModell}). Zus"atzlich zu den geerbten Eigenschaften kann ein Anwendungsdatentyp um zus"atzliche Attribute spezialisiert werden, was mit Hilfe einer Datei (\engl{Annotation File}) geschieht.

Ein konkretes Beispiel f"ur die in der Datei {\tt omt.app.types} spezifizierte Abbildung von StP Anwendungsdatentypen des dynamischen StP/OMT Modells auf PDM Datentypen ist in Abbildung~\ref{Fig:appTyp} dargestellt. Ber"ucksichtigt sind hierbei die Anwendungsdatentypen, die f"ur die Generierung eines Tycoon Validierungsprototypen (vgl. Abschnitt~\ref{SubSec:Prototyp}) aus einem dynamischen StP/OMT Modell von Bedeutung sind. Die in der Abbildung~\ref{Fig:appTyp} wiedergegebenen PDM Datentypen repr"asentieren die in den Abbildungen~\ref{Fig:ChartMeta} und~\ref{Fig:ZustandsGen} vorgestellten Statechart Syntaxelemente f"ur die Tycoon Modellierung von dynamischem Systemverhalten.

\subsection{Zugriffsm"oglichkeiten auf StP Repositoryobjekte}
\label{SubSec:ZugriffRep}

Das StP Object Management System stellt dem Anwender neben dem StP Repository Browser die werkzeugunabh"angigen Zugriffsm"oglichkeiten der StP Query and Reporting Language (QRL) und des StP Application Program Interface (API) zur Verf"ugung, um direkt auf Repositoryobjekte zuzugreifen. Im Rahmen der StP QRL m"ussen vom Anwender QRL Skripte erstellt werden, in welchen der Repositoryzugriff mit Hilfe der OMS Query Language realisiert wird. StP QRL Skripte sind als integraler Bestandteil des StP Query and Reporting Systems (QRS) zu betrachten. Darin werden mit Hilfe des StP Query and Reporting Processors (qrp) die in einem StP QRL Skript enthaltenen QRL Befehle im Rahmen der Skriptinterpretation in OMS Anfragen umgesetzt, um so den eigentlichen Zugriff auf die Repositoryobjekte "uber die Schnittstelle des StP Object Management Systems zu erzielen. Eine Darstellung von StP QRL Skripten und des QRS selbst ist in \cite{StPqrs94} enthalten.

Neben der Einbettung von OMS Anfragen in Query and Reporting Language Skripte ist es ebenfalls m"oglich, die Repository Anfragen in Funktionen des StP API in der Form von an die API Funktionen "ubergebenen Argumenten zu integrieren. Dabei werden die StP API Funktionen in C Programme integriert und zur Laufzeit des C Programms ausgef"uhrt. Das StP Application Program Interface bildet somit eine Schnittstelle zwischen C Anwendungsprogrammen und dem StP Repository. Im Rahmen der Anbindung des Tycoon Systems an die StP Umgebung (vgl. Kapitel~\ref{Chap:Anbindung}) werden die C Funktionen des StP API f"ur den Repositoryzugriff eingesetzt. In der Tabelle~\ref{Tab:TypsProcs} sind exemplarisch einige ausgew"ahlte StP API Funktionen wiedergegeben. Weitere Funktionen sind in \cite{StPoms94} aufgef"uhrt.

\begin{table}
\begin{center}
\begin{tabular}{|l|l|}
\hline
{\bf Funktion} & {\bf Beschreibung}\\
\hline\hline
{\tt oms\_$<$pdm\_typ$>$\_create} & Erzeugt ein neues Repositoryobjekt\\
  & im Hauptspeicher und gibt einen darauf \\
  & weisenden Zeiger zur"uck.\\
\hline
{\tt oms\_$<$pdm\_typ$>$\_find} & Sucht im aktuellen Repository nach dem mit\\
  & den Funktionsparametern spezifizierten\\
  & Objekt. Dieses wird in eine neue\\
  & {\tt oms\_$<$pdm\_typ$>$\_tp} Struktur kopiert. Ein darauf\\
  & weisender Zeiger wird zur"uckgegeben.\\
  & Ansonsten wird der {\tt NULL}-Zeiger zur"uckgegeben.\\
\hline
{\tt oms\_$<$pdm\_typ$>$\_find\_by\_id} & Sucht im aktuellen Repository nach dem mit\\
  & den Funktionsparametern spezifizierten\\
  & Objekt. Dieses wird in eine neue\\
  & {\tt oms\_$<$pdm\_typ$>$\_tp} Struktur kopiert. Ein darauf\\
  & weisender Zeiger wird zur"uckgegeben.\\
  & Ansonsten wird der {\tt NULL}-Zeiger zur"uckgegeben.\\
\hline
{\tt oms\_$<$pdm\_typ$>$\_find\_by\_query} & Sucht im aktuellen Repository nach dem\\     
  & mit den "`OMS Anfragebedingungen"'\\
  & "ubereinstimmenden Objekt. Dieses wird in eine\\
  & {\tt oms\_$<$pdm\_typ$>$\_tp} Struktur kopiert. Ein darauf\\
  & weisender Zeiger wird zur"uckgegeben.\\
  & Ansonsten wird der {\tt NULL}-Zeiger zur"uckgegeben.\\
\hline
{\tt oms\_$<$pdm\_typ$>$\_free} & Nimmt die Adresse des "ubergebenen Zeigers\\
  & auf die {\tt oms\_$<$pdm\_typ$>$\_tp} Struktur und gibt den\\
  & damit assoziierten Hauptspeicherbereich frei.\\
\hline
{\tt oms\_$<$pdm\_typ$>$\_print} & Nimmt die Adresse des "ubergebenen Zeigers\\ 
  & auf die {\tt oms\_$<$pdm\_typ$>$\_tp} Struktur und gibt\\
  & alle Attributnamen und deren Werte in\\
  & einer zu spezifizierenden Datei aus.\\
\hline
{\tt oms\_$<$pdm\_typ$>$\_} & Weist einem Repositoryobjekt-\\
{\tt $<$attribut$>$\_asgn} & Attribut einen neuen Wert zu.\\
\hline
{\tt oms\_$<$pdm\_typ$>$\_update} & Aktualisiert oder f"ugt im Hauptspeicher\\
  & angelegte Strukturen im StP Repository als\\
  & Objekte ein. Tritt ein Fehler auf oder sind \\
  & referentielle Integrit"atsbedingungen nicht erf"ullt, \\
  & gibt die Funktion {\tt OMS\_FAIL} zur"uck,\\
  & ansonsten {\tt OMS\_SUCCEED}.\\
\hline
{\tt oms\_sys\_repos\_open} & "Offnet das spezifizierte Repository\\
  & f"ur den Zugriff.\\
\hline
{\tt oms\_repos\_close} & Schlie"st das aktuelle Repository nach\\
  & dem Abschlu"s der Zugriffsoperationen.\\
\hline
\end{tabular}
\end{center}
\caption{Ausgew"ahlte StP Application Program Interface Funktionen}
\label{Tab:TypsProcs}
\end{table}

Eingesetzt wird die Funktionalit"at des StP API im Rahmen der in Abschnitt~\ref{SubSec:Prototyp} vorgestellten Generierung eines auf einem dynamischen StP/OMT Modell basierenden Tycoon Prototypen zur Validierung der Verhaltensspezifikation eines zu entwerfenden Systems. Dabei werden z.B. OMS Query and Reporting Language Anweisungen als Parameter der StP API Funktion {\tt oms\_$<$pdm\_typ$>$\_find\_by\_query} "ubergeben. Ziel ist, die im StP Repository abgelegten Objekte eines dynamischen StP/OMT Modells zu identifizieren und auf sie zuzugreifen, um sie anschlie"send auf der Tycoon Ebene in eine ad"aquate Form eines Tycoon Statecharts zu "uberf"uhren.

Eine exemplarische StP QRL Anweisung zum Auffinden der {\sl node} Objekte mit dem Identifikator {\tt 701541}, der einen mit dem Diagrammeditor des dynamischen StP/OMT Modells erstellten Zustand repr"asentiert lautet:

\begin{quote}
{\tt for\_each\_in\_select("{}node$[$id = 701541$]$"{}, aktuellerNode)}
\end{quote}

Bei dieser OMS Anfrage wird der erste Wert des Anfrageergebnisses an die C Variable {\tt aktuellerNode} "ubergeben. S"amtliche StP API Funktionen werden, wie in Kapitel~\ref{Chap:Anbindung} dargestellt, auf Tycoon Funktionen "ubertragen, um aus dem Tycoon System heraus die gesamte Funktionalit"at des StP Object Management Systems benutzen zu k"onnen.

\clearemptydoublepage
