% ------------------------------------------------------------------ %
%                                                                    %
% Datei: werkzeug.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 1/2           %
%                                                                    %
% Version vom 18. 4.1997                                             %
% ------------------------------------------------------------------ %

\chapter{Werkzeugorientierte Systementwicklung}
\label{Chap:WerkSystem}

Wie in Kapitel~\ref{Chap:Einleitung} erl"autert, soll der Softwareentwicklungsproze"s werkzeugorientiert durchgef"uhrt werden, um die in Abschnitt~\ref{Sec:Motiv} dargestellten Anforderungen an die Systementwicklung erf"ullen zu k"onnen. Abschnitt~\ref{Sec:Computer} erl"autert diesen werkzeugorientierten Softwareentwicklungsproze"s.

Grundlage einer werkzeugorientierten und computerbasierten Systementwicklung ist in dieser Arbeit die Anwendungsentwicklungsmethode \engl{Object Modeling Technique} OMT \cite{rumb91}, wobei der Schwerpunkt auf der dynamischen Systemmodellierung liegt (vgl. Abschnitt~\ref{Sec:OOMod}). Implementiert wird OMT mit dem in Abschnitt~\ref{Sec:StPOMT} erl"auterten CASE Werkzeug StP/OMT, welches ein Bestandteil der CASE Umgebung Software through Pictures ist.

\section{Computerunterst"utzte Anwendungsentwicklung}
\label{Sec:Computer}

Werkzeuge des \engl{Computer Aided Software Engineering} (CASE) sollen neben den in Kapitel~\ref{Chap:Einleitung} erw"ahnten Verbesserungen zu einer Optimierung des Prozesses der Softwareentwicklung f"uhren, um somit unter anderem die Transparenz und Kommunikation innerhalb der Produktentwicklung zu erh"ohen. Dabei hat sich die Bedeutung des Begriffs der computerunterst"utzten Softwareentwicklung im Verlauf der vergangenen Jahre ver"andert. Verstand man fr"uher unter automatisierter Unterst"utzung isolierte Softwarewerkzeuge, so ist es heute eine integrierte Anzahl von Werkzeugen, mit denen alle Phasen des Softwarelebenszyklus sowohl unterst"utzt als auch umgesetzt werden k"onnen \cite{balzert93}. 

\subsection{Anforderungen an CASE}
\label{SubSec:Anforder}

Grundlage einer automatisierten Anwendungsentwicklung ist nicht allein die Leistungsf"ahigkeit der einzelnen CASE Werkzeuge. Vielmehr m"ussen die eingesetzten Werkzeuge im Kontext mit der ihnen zugrundeliegenden CASE Umgebung betrachtet werden. Dabei lassen sich die Anforderungen je nach Kategorie der eingesetzten Computerunterst"utzung trennen: nach allgemeinen Anforderungen, die an eine CASE Umgebung gestellt werden (Basisanforderungen), und solchen, die von den einzelnen Werkzeugen dieser Umgebung zu erf"ullen sind. In diesem Zusammenhang werden in dieser Arbeit sowohl Basisanforderungen an die gesamte CASE Umgebung als auch Anforderungen an die einzelnen CASE Werkzeuge betrachtet.\\

{\bf {\sf Basisanforderungen an die CASE Umgebung}}

\begin{itemize}
  \item Integrierte Datenhaltung aller Datenbasen jedes separaten CASE Werkzeugs zur Bildung von die Entwicklungsphasen "ubergreifenden Werkzeugketten
  \item Erweiterbarkeit um weitere Werkzeuge
  \item Offenheit und Transparenz bez"uglich der Import- und Exportschnittstellen
  \item Multi- und Interprojektf"ahigkeit
  \item Unterst"utzung verschiedener Entwicklungsplattformen
\end{itemize}

{\bf {\sf Anforderungen an einzelne CASE Werkzeuge}}

\begin{itemize}
  \item Import- und Exportschnittstellen zur Kommunikation mit fremden Werkzeugen oder der CASE Umgebung
  \item Integrierbarkeit in die CASE Umgebung
\end{itemize}

Neben diesen technisch bedingten Anforderungen m"ussen die eingesetzten Werkzeuge nat"urlich auf die dem Entwicklungsproze"s zugrundeliegende Methode der Anwendungsentwicklung abgestimmt sein, um "uberhaupt eine durchg"angige Werkzeugkette "uber alle Phasen des Softwareerstellungsprozesses gew"ahrleisten zu k"onnen.

\subsection{Werkzeugintegration}
\label{SubSec:Integration}

Eine Unterst"utzung des Anwendungsentwicklungsprozesses erfolgt, indem s"amtliche verwendeten separaten Werkzeuge in einer integralen Art miteinander verkn"upft werden, so da"s ihre Kombination ein einziges, gro"ses Gesamtwerkzeug, n"amlich die komplette Entwicklungsumgebung, ergibt. Die Integrationsbeziehungen zwischen den einzelnen Werkzeugen beziehen sich auf die Pr"asentation der Mensch-Werkzeug-Schnittstelle (\engl{Presentation Integration}), die von allen Werkzeugen verwendeten Daten (\engl{Data Integration}), den Kontrollflu"s zwischen den Werkzeugen innerhalb des Entwicklungsprozesses (\engl{Control Integration}) und den Proze"s des Einsetzens der Werkzeuge selbst (\engl{Process Integration}) \cite{thomas92}. Die Integration aller Werkzeuge einer verteilten Anwendungsentwicklungsumgebung findet ihre Ber"ucksichtigung in der Plattformintegration (\engl{Platform Integration}) \cite{wasser89}.

Die Integrationsmechanismen gelten f"ur zwei Klassen von Anwendungsentwicklungswerkzeugen: Werkzeuge zur Unterst"utzung des Entwicklungsprozesses in den jeweiligen Phasen des Anwendungserstellungsprozesses (\engl{Vertical Tools}) und Werkzeuge zur phasen"ubergreifenden Unterst"utzung (\engl{Horizontal Tools}). Phasen"ubergreifende Entwicklungswerkzeuge umfassen Werkzeuge f"ur Dokumentationszwecke, Projekt- und Proze"smanagement, Konfigurationsmanagement und das Nachweisen der Ber"ucksichtigung von gestellten Systemanforderungen. Bei Werkzeugen der jeweiligen Projektphasen werden \engl{Upper CASE} Werkzeuge von Werkzeugen des \engl{Lower CASE} unterschieden. \engl{Upper CASE} Werkzeuge werden in den Phasen Analyse und Entwurf eingesetzt, \engl{Lower CASE} Werkzeuge hingegen in den Phasen der Kodierung und des Testens von Anwendungssystemen.\\

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{figure=env.eps,width=12cm}
  \end{center}
  \caption{\label{Fig:Integra} Integrierte CASE Umgebung}
\end{figure}

In der Abbildung~\ref{Fig:Integra} sind die erw"ahnten Integrationsbeziehungen zwischen Werkzeugen einer computerunterst"utzten, verteilten Entwicklungsumgebung dargestellt \cite{StPpc93}. Wichtig ist hierbei, da"s die Integration aller Werkzeuge im Rahmen der Datenintegration "uber das Repository erfolgt. Auf die Entwicklungsdatenbank greifen sowohl die den Entwicklungsproze"s in den jeweiligen Phasen unterst"utzenden Werkzeuge ({\engl{Vertical Tools}) als auch die phasen"ubergreifenden Werkzeuge (\engl{Horizontal Tools}) zu.

Das in Abschnitt~\ref{Sec:StPOMT} dargestellte CASE Werkzeug StP/OMT unterst"utzt phasenorientiert den Anwendungsentwicklungsproze"s als  computerbasiertes Analyse-, Entwurfs- und Kodierungswerkzeug (\engl{Vertical Tool}, vgl. Abbildung~\ref{Fig:Integra}). Au"serdem stellt es phasen"ubergreifende Funktionalit"aten (\engl{Horizontal Tools}) dem Anwendungsentwickler zur Verf"ugung (z.B. einen Druckmanager zur Aufbereitung und anschlie"sendem Ausdruck der in den einzelnen Phasen erstellten Dokumentationen der separaten StP/OMT Diagramm- und Tabelleneditoren). Die Integration von StP/OMT in die StP Umgebung erfolgt "uber das StP Repository (\engl{Data Integration}).

\section{Objektorientiertes Modellieren und Entwerfen mit OMT}
\label{Sec:OOMod}

Die objektorientierte Methode OMT f"ur die Entwicklung von Anwendungssystemen besteht darin, ein Modell einer Anwendungsdom"ane zu erstellen und diesem danach, beim Entwurf des Systems, Implementierungsdetails hinzuzuf"ugen \cite{rumb91}. Dabei umfa"st die OMT Methode die folgenden Phasen:

\begin{enumerate}
  \item In der Analysephase wird ausgehend von einer informellen Problembeschreibung ein Analysemodell erstellt, welches darstellt, was das zu entwerfende System leisten soll. Die Objekte des Modells sind implementierungsunabh"angige Abstraktionen der Objekte aus der Anwendungsdom"ane. Das Analysemodell enth"alt keine Implementierungsdetails und richtet sich sowohl an die Anwender als auch an die Systementwickler. Das OMT Analysemodell besteht aus Objektmodell, dynamischem Modell und funktionalem Modell. Abschnitt~\ref{SubSec:Dynam} erl"autert das in dieser Arbeit im Mittelpunkt stehende dynamische Modell n"aher.
  \item Beim Systementwurf wird eine Strategie f"ur die Implementierung des Systems entwickelt. Es werden Entscheidungen "uber die Gesamtarchitektur des zu erstellenden Anwendungssystems getroffen. Ausgehend vom Analysemodell und einer vorgeschlagenen Architektur wird das System in Teilsysteme organisiert.
  \item Innerhalb des Objektentwurfs wird auf Grundlage des Analysemodells ein Entwurfsmodell erstellt, welches Implementierungsdetails enth"alt. Inhalt des Objektentwurfs sind Datenstrukturen (z.B. Klassen und Assoziationen) und Algorithmen (Methoden), die zur Implementierung jeder Klasse ben"otigt werden. Die Objektklassen aus der Analysephase werden um diese Datenstrukturen und Algorithmen erweitert. Sowohl anwendungsspezifische als auch implementationsspezifische Objekte werden mit den gleichen objektorientierten Konzepten und der gleichen Notation beschrieben.
  \item In der Implementierungsphase werden die beim Objektentwurf entwickelten Objektklassen und Relationen in eine bestimmte Programmiersprache, Datenbank oder Hardwareimplementierung "ubersetzt.
\end{enumerate}

\subsection{OMT Metamodell}
\label{SubSec:OMTMeta}

Innerhalb der Analysephase verwendet die Methode OMT drei unterschiedliche Modelle zur Beschreibung eines Systems. Jedes dieser Modelle (Objektmodell, dynamisches Modell, funktionales Modell) spezifiziert eine eigene Sicht auf das zu entwerfende System. Erst die Integration aller dieser Modelle f"uhrt zu einer kompletten Beschreibung eines Systems im OMT Analysemodell \cite{losavio94}.\\

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{figure=omt.eps,width=13.5cm}
  \end{center}
  \caption{\label{Fig:OMTModell} OMT Modelle}
\end{figure}

In der Abbildung~\ref{Fig:OMTModell} sind die drei Modelle des OMT Analysemodells und ihre Inhalte dargestellt. Das Objektmodell beschreibt die statische Struktur der Objekte in einem System und ihre Relationen zueinander. Es enth"alt Objektdiagramme, welche in der Form eines Graphen dargestellt werden. Knoten innerhalb eines Objektdiagramms repr"asentieren Objektklassen, Kanten die Relationen zwischen diesen Klassen. Das Objektmodell wird vor dem dynamischen und dem funktionalen Modell entwickelt.

Das dynamische OMT Modell beschreibt die Aspekte eines Systems, die sich im Zeitablauf ver"andern. Das dynamische Modell wird f"ur die Spezifikation der Steuerungsoperationen eines Systems verwendet. Es enth"alt Zustandsdiagramme, welche als Graph dargestellt werden (vgl. Abschnitt~\ref{SubSec:Dynam}). Knoten innerhalb eines Zustandsdiagramms repr"asentieren Systemzust"ande, Kanten die Transitionen zwischen diesen Zust"anden. Spezifiziert wird damit das Systemverhalten im Zeitablauf, welches durch das Eintreten von Ereignissen aus der Systemumgebung bestimmt wird.

Grundlage der Zustandsdiagramme innerhalb des dynamischen OMT Modells sind Statecharts \cite{harel87}, wobei die innerhalb des dynamischen OMT Modells verwendeten Zustandsdiagramme eine Spezialisierung und Einschr"ankung der in \cite{harel87} dargestellten Statechartnotation darstellen. Alternativ k"onnten zur Spezifikation dynamischen Systemverhaltens Petri-Netze eingesetzt werden. Eine Abbildung von Statecharts auf Petri-Netze wird in \cite{fricke95} vorgestellt.

Das funktionale OMT Modell beschreibt die Transformation von Datenwerten innerhalb des Systems. Es enth"alt Datenflu"sdiagramme, welche als Graph dargestellt werden. Knoten innerhalb eines Datenflu"sdiagramms repr"asentieren Prozesse, Kanten Datenfl"usse.

Im Rahmen dieser Arbeit ist im folgenden ausschlie"slich das dynamische OMT Modell Gegenstand der Betrachtung. Eine Darstellung des OMT Objektmodells und des funktionalen OMT Modells ist in \cite{rumb91} zu finden.

\subsection{Modellierung dynamischer Systemaspekte}
\label{SubSec:Dynam}

Das dynamische Modell spezifiziert das zeitabh"angige Verhalten des zu erstellenden Systems und seiner Objekte. Die wichtigsten Konzepte der dynamischen Modellierung sind Ereignisse, die Nachrichten an eine Objektklasse repr"asentieren und Zust"ande, die Werte von Objekten repr"asentieren. Eine Vorgehensweise zur Konstruktion eines dynamischen Modells umfa"st die folgenden, in diesem Abschnitt betrachteten Schritte:

\begin{itemize}
  \item F"ur jedes Objekt des Systems werden die sichtbaren Ereignisse und Reaktionen identifiziert. Diese Ereignisse, die von einer Objektklasse zu einer anderen Objektklasse gesendet werden, k"onnen in einem Ereignisflu"sdiagramm grafisch dargestellt werden. Ein Ereignisflu"sdiagramm fa"st Ereignisse zwischen Objektklassen ohne Ber"ucksichtigung ihrer Reihenfolge des Eintretens zusammen. Kanten in Ereignisflu"sdiagrammen zeigen m"ogliche Kontrollfl"usse zwischen Objektklassen eines Systems.\\

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{figure=tvuse.eps,width=11.5cm}
  \end{center}
  \caption{\label{Fig:UseCase} OMT Ereignisflu"sdiagramm}
\end{figure}

In der Abbildung~\ref{Fig:UseCase} ist ein Ereignisflu"sdiagramm zwischen den in dieser Arbeit betrachteten Objekten einer Fernsehersteuerung dargestellt, wobei die identifizierten Ereignisse zwischen den Objektklassen nur exemplarischen Charakter besitzen. Das spezifizierte Ereignisflu"sdiagramm hat keinen Anspruch auf Vollst"andigkeit. Die kursiv dargestellten Ereignisse zwischen der Klasse {\sl Remote-Control} und {\sl Video Recorder} bzw. {\sl Video Recorder} und  {\sl Television} werden in den folgenden Abschnitten nicht weiter ber"ucksichtigt.

Von der Objektklasse {\sl Remote-Control} k"onnen die in Abbildung~\ref{Fig:UseCase} wiedergegebenen Ereignisse {\sl standby}, {\sl progr\_button}, {\sl vtxt}, {\sl sound\_on}, {\sl sound\_off}, {\sl hide\_picture} und {\sl hide\_progrNr} an die Klasse {\sl Television} gesendet werden. Bei der Spezifikation des Verhaltens der Klasse {\sl Television} sind diese Ereignisse als Nachrichten zu ber"ucksichtigen.

\item Ausgehend von den identifizierten und innerhalb eines Ereignisflu"sdiagramms dargestellten Ereignissen zwischen den Objektklassen eines Systems werden f"ur anwendungstypische Interaktionssequenzen Szenarios erstellt, um eine zeitlich geordnete Abfolge der Ereignisse zwischen den Objektklassen darzustellen. Ein Szenario bezeichnet in dieser Arbeit eine m"ogliche zeitliche Abfolge von Ereignissen. Ein Ereignispfad ist eine geordnete Liste tabellarisch angeordneter Ereignisse zwischen Objekten.\\

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{figure=tvevent.eps,width=11cm}
  \end{center}
  \caption{\label{Fig:Event} OMT Ereignispfaddiagramm}
\end{figure}

In der Abbildung~\ref{Fig:Event} wird ein m"ogliches Szenario zwischen den Klassen {\sl Remote-Control}, {\sl Television} und {\sl Video Recorder} wiedergegeben. Im Rahmen dieser Arbeit werden in den folgenden Abschnitten ausschlie"slich Ereignisse von der Objektklasse {\sl Remote-Control} an die Klasse {\sl Television} ber"ucksichtigt.

Das in Abbildung~\ref{Fig:Event} dargestellte Szenario beginnt mit dem Ausl"osen des Ereignisses {\sl progr\_button} in der Objektklasse {\sl Remote-Control} und endet mit dem Ereignis {\sl standby} an die Klasse {\sl Television}. Spezifiziert ist hier eine Interaktionssequenz, bei der ein Anwender mit Hilfe der Fernbedienung einen Fernseher und einen Videorekorder steuert. Eingeschaltet wird das Fernsehger"at mit der Programmtaste 1 auf der Fernbedienung (Ereignis {\sl progr\_button (1)} von der Klasse {\sl Remote-Control} an die Klasse {\sl Television}). Anschlie"send wird der Videorekorder gestartet (Ereignis {\sl play}), der den Videokanal am Fernsehger"at einschaltet (Ereignis {\sl progr\_button (0)} von der Klasse {\sl Video Recorder} an die Klasse {\sl Television}) und daraufhin das Videobild anzeigt (Ereignis {\sl display\_progr}). Danach h"alt der Benutzer die Wiedergabe des Videorekorders an (Ereignis {\sl stop}), wo\-rauf\-hin das Videobild nicht mehr angezeigt wird (Ereignis {\sl undisplay\_program}). Sp"ater wechselt der Anwender in das Programm 6 (Ereignis {\sl progr\_button (6)}), ruft danach den Videotextmodus auf (Ereignis {\sl vtxt}), w"ahlt die Videotextseite 285 und verl"a"st den Videotextmodus wieder (Ereignis {\sl vtxt}). Nachdem mit der Fernbedienung der Ton des Fernsehers ausgeschaltet wurde (Ereignis {\sl sound\_off}), wird das Fernsehger"at in den Bereitschaftsmodus zur"uckversetzt (Ereignis {\sl standby}).

Die kursiv dargestellten Ereignisse zwischen den Klassen {\sl Remote-Control} und {\sl Video Recorder} bzw. {\sl Video Recorder} und  {\sl Television} werden in den folgenden Abschnitten nicht weiter ber"ucksichtigt.

\item Ausgehend von den erstellten Ereignispfaddiagrammen (eine Anzahl von Szenarios) werden die Zustandsdiagramme, die das Verhalten der Objektklassen spezifizieren, erstellt. Grundlage des Verhaltens eines Systems ist das Verhalten seiner Objekte. F"ur jede Objektklasse wird in der Methode OMT ein Zustandsdiagramm erstellt, das die Ereignisse zeigt, welche die Objektklasse empf"angt und sendet. Dabei entspricht jeder Ereignispfad einem Pfad durch das Zustandsdiagramm \cite{rumb91}.

Da die Klasse {\sl Remote-Control} in dieser Arbeit nur als Ereignissender auftritt, wird f"ur sie kein Zustandsdiagramm erstellt. Das Zustandsdiagramm f"ur das Verhalten der Klasse {\sl Television} ist in Anhang~\ref{Ann:TVstatecharts} in einer an die Darstellung der Zustandsdiagramme in der Methode OMT angelehnten Form wiedergegeben.
\end{itemize}

Im Zusammenhang mit der Erstellung der Zustandsdiagramme stellt die in Kapitel~\ref{Chap:Validierung} erl"auterte Validierung dynamischen Systemverhaltens die Verbindung zwischen den einzelnen Diagrammen her. Ausgehend von einer Anzahl spezifizierter Ereignispfaddiagramme soll das Verhalten des spezifizierten Systems gegen die Erwartungen des Anwenders untersucht werden. Eine Menge von Ereignispfaddiagrammen gibt die typischen Interaktionssequenzen an, so da"s auf deren Basis ein Gro"steil aller in der Realit"at eintretenden Ereignisse schon vor dem Entwurf des Systems validiert werden k"onnen.

\input{werkzg2}
