% Studienarbeit von Andreas Boesch
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
%
% Kapitel: Analyse mit OMT


\chapter{Analyse mit OMT}
\label{Kap. OMT}

Das Ziel der objektorientierten Analyse ist, einen Teilbereich der realen Welt so zu modellieren, da"s das Modell
\begin{itemize} 
	\item verst"andlich ist,
	\item die Anforderungen an das System widerspiegelt,
	\item als Basis f"ur die Abstimmung zwischen Anwender und Softwareentwickler dient.
\end{itemize}

In diesem Kapitel wird in Abschnitt~\ref{Abs. omtIntro} allgemein die \e{Object Modelling Technique} (OMT) aus \cite{R*91}  und in Abschnitt~\ref{Abs. StP} das darauf basierende CASE\footnote{Computer Aided Software Engineering}-Werkzeug \pn{Software through Pictures / Object Modeling Technique} (StP OMT) aus \cite{StPOMT} der Firma \pn{Interactive Development Environments} vorgestellt. Nach dieser Einf"uhrung folgt in Abschnitt~\ref{Abs. Objektmodell} anhand der Analyse des Index zur politischen Ikonographie eine vertiefende, aber nicht vollst"andige Darstellung des Objektmodells von OMT. 

\section{OMT - ein "Uberblick}
 \label{Abs. omtIntro}

OMT ist eine aus einer ganzen Reihe von Methoden zur objektorientierten Entwicklung von Software (vgl. \cite{Stei93} oder \cite{Fow93}). Es handelt sich hierbei nicht um eine Programmiertechnik, sondern um ein Modellierungskonzept, das von einer Programmiersprache unabh"angig ist. Zu der Methode geh"ort eine Notation, die objektorientierte Konzepte grafisch abbildet (siehe Abschnitt~\ref{Abs. Objektmodell}).   

\subsection{Die vier Phasen der Entwicklung}
\label{Abs. vierPhasen}

Die OMT-Methode basiert darauf, ein Modell einer Anwendungsdom"ane zu entwickeln und dann w"ahrend des Designs des Systems Implementationsdetails hinzuzuf"ugen.
Die Methode umfa"st vier Phasen: 

\begin{description}
\item [Analyse:]\hspace{.1cm}
Ausgehend von einer informalen Problembeschreibung wird in der Analyse ein Bereich der realen Welt m"oglichst kurz, pr"azise und verst"andlich modelliert.  Das Analysemodell legt fest, welche Funktionalit"at das gew"unschte System erf"ullt; es sollte keinerlei Implementationsentscheidungen beinhalten.
\end{description}

\begin{description}
\item [Systementwurf:]\hspace{.1cm}
Beim Systementwurf werden Entscheidungen "uber die Gesamtarchitektur getroffen, \dh, das geplante System wird in seine Hauptkomponenten, die in OMT Subsysteme genannt werden, unterteilt. Desweiteren m"ussen die Anforderungen an die vom System zu erbringende Leistung und die sich daraus ergebenden Hardwareanforderungen abgesch"atzt werden.

\end{description}

\begin{description}
\item [Objektentwurf:]\hspace{.1cm}
Diese Phase besteht aus der Erweiterung des Analysemodells um implementierungsbezogene Objekte, Klassen, Datenstrukturen und Algorithmen \cite{Matt94}. 
\end{description}

\begin{description}
\item [Implementierung:]\hspace{.1cm}
Die Objektklassen und Beziehungen, die w"ahrend des Objektentwurfes entwickelt wurden, werden in Konzepten von Programmiersprachen oder Datenbanken oder als Hardwareimplementierung realisiert. Die Programmierung sollte ein relativ kleiner und mechanischer Teil des Entwicklungsprozesses sein, da alle wichtigen Entscheidungen bereits w"ahrend des Designs getroffen werden sollten.
\end{description}

Von besonderer Wichigkeit ist die Analysephase, da in dieser die Weichen f"ur das sp"atere System gestellt werden, d.h. Fehler, die in dieser Phase gemacht werden, k"onnen in den nachfolgenden Phasen nur noch mit hohem Aufwand beseitigt werden. Die Analyse wird deshalb im folgenden Abschnitt genauer vorgestellt. 

\subsection{Die Analysephase}
\label{Abs. Analyse}

Analyse ist der erste Schritt der OMT-Methode. Das Ziel dieser Phase ist ein pr"azises, verst"andliches und korrektes Modell der realen Welt.

In Abbildung~\ref{AnalyseProzess} wird das Vorgehen deutlich. Am Anfang des Analyseprozesses steht eine Problembeschreibung, die in erster Linie vom Benutzer, m"oglicherweise aber auch in Zusammenarbeit mit dem Entwickler bzw. Manager formuliert wird. Die Problembeschreibung ist eine textuelle Beschreibung der Systemanforderungen und soll die Frage beantworten: 
\begin{quote}
{\em Was} soll das System leisten?
\end{quote} 
und nicht
\begin{quote} 
{\em Wie} soll das System arbeiten? 
\end{quote}

Es ist in der Analysephase nicht wichtig, Probleme, die das Design und die Implementation betreffen, zu formulieren (z.B. Algorithmen, Datenstrukturen, Gesamtarchitekur, ...). Am Anfang des Analyseprozesses ist ein generelles Verst"andnis des Problems anzustreben. Darum sollten die folgenden Punkte in einer Problembeschreibung Beachtung finden: 
\begin{itemize}
\item Umfang des Problems
\item Ben"otigte Ressourcen
\item Kontext der Anwendung
\item Annahmen
\item Leistungsanforderungen
\end{itemize}

In der Analysephase des Index zur politischen Ikonographie haben die Kunsthistoriker ohne Kenntnis dieser in \cite{R*91} aufgestellten Anforderungen eine Problembeschreibung erstellt, die die meisten dieser Punkte beinhaltet (siehe Anhang~\ref{Koop}). Das spricht f"ur die Nat"urlichkeit der o.g. Anforderungen an eine Problembeschreibung.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=10cm \epsfysize=10cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/omt/analyseProz.epsf}
\end{center}
\caption{Der Analyseproze"s im "Uberblick}
\label{AnalyseProzess}
\end{figure}

Ausgehend von einer Problembeschreibung, die in der Regel von den Benutzern erstellt wird, wird nun mit Hilfe von Benutzerbefragungen, Fachgebietswissen und praktischer Erfahrung ein Analysedokument erstellt. Hierbei versteht man unter Fachgebietswissen das Wissen "uber die Anwendungsdom"ane. Das Analysedokument dient dann als Grundlage f"ur die sp"ateren Designphasen. Dadurch, da"s am Anfang des Softwareentwicklungsprozesses ein genaues Modell der Anwendungsdom"ane erstellt werden mu"s, wird der Entwickler gezwungen, Mi"sverst"andnisse in dieser sehr fr"uhen Phase auszur"aumen.

\newpage

Das Analysedokument besteht aus drei Modellen:

\begin{description}
\item[Objektmodell:]\hspace{.1cm}
Das \e{Objektmodell} beschreibt die statische Struktur der Objekte im System und ihre Beziehungen zueinander. Es enth"alt \e{Objektdiagramme}. Ein Objektdiagramm ist ein Graph, in dem die Knoten Klassen und die Kanten Beziehungen zwischen Klassen sind.
\end{description}

\begin{description}
\item[Dynamisches Modell:]\hspace{.1cm}
Das \e{dynamische Modell} beschreibt die Ver"anderungen des Systems "uber die Zeit. Es enth"alt \e{Zustandsdiagramme}. Ein Zustandsdiagramm ist ein Graph, in dem die Knoten Objektzust"ande und die Kanten von Ereignissen ausgel"oste Transitionen zwischen Objektzust"anden sind.
\end{description}

\begin{description}
\item[Funktionales Modell:]\hspace{.1cm}
Das \e{funktionale Modell} beschreibt die Transformation von Daten durch Prozesse. Es enth"alt \e{Datenflu"sdiagramme}. Ein Datenflu"sdiagramm ist ein Graph, in dem die Knoten Prozesse und die Kanten Datenfl"usse sind.
\end{description}

Das Objektmodell ist die Basis der beiden anderen Modelle, da es n"otig ist, zuerst zu beschreiben, \e{was} sich "andert, bevor man beschreibt, \e{wann} oder \e{wie} es sich "andert. Das Objektmodell wird in Abschnitt~\ref{Abs. Objektmodell} n"aher erl"autert.

\section{StP OMT}
\label{Abs. StP}
W"ahrend sich 90 Prozent aller CASE-Werkzeuge auf strukturierte Methoden wie z.B. `Strukturierte Analyse` nach \cite{DeMa79} und Entity-Relationship-Modelle nach \cite{Chen76} st"ut\-zen, die strikt zwischen Daten- und Funktionssicht trennen, werden diese Sichten in ob\-jekt\-ori\-entierten Methoden wie z.B. OMT integriert \cite{Vers93}.

In diesem Abschnitt wird das CASE-Werkzeug StP OMT vorgestellt, mit dem die Objektmodelle f"ur das PolitIcon-Projekt entwickelt wurden. Diese Objektmodelle waren Diskussionsgrundlage f"ur Benutzerbefragungen und dienten der Verst"andigung zwischen Benutzer und Entwickler "uber das vorhandene Datenmaterial und dessen Struktur.

StP OMT erf"ullt folgende Anforderungen:
\begin{itemize}
	\item interaktiver Grafikeditor
	\item mehrbenutzerf"ahiger Datenspeicher (\e{repository})
	\item Versionsmanagement
	\item Zugangskontrollmechanismen
	\item F"ahigkeiten zum Speichern von verschiedenen Konfigurationen und Voreinstellungen f"ur Benutzer, Gruppen oder Projekte
	\item Einbettung in die Implementierungsphase, z. B. automatische Codegenerierung
\end{itemize}
 
Wie in Abbildung~\ref{StPArchitektur} aus \cite{StPOMT} gezeigt wird, bietet StP OMT eine Reihe von Editoren und Hilfsmitteln an, die es erlauben, OMT Modelle zu entwickeln. Wichtig f"ur diese Arbeit waren im wesentlichen die beiden folgenden Editoren: 

\begin{description}
\item [Objektmodell Editor:]\hspace{.1cm}
Mit diesem Editor lassen sich OMT-Objektmodelle erzeugen und ver\-"an\-dern, da die von \cite{R*91} entwickelte Notation vollst"andig unterst"uzt wird.
\end{description}

\begin{description}
\item [Klassentabellen Editor:]\hspace{.1cm}
Im Klassentabellen Editor k"onnen Klassen mit ihren Attributen und Operationen (siehe Abschnitt~\ref{Abs. ObjUndKl}) vollst"andig definiert werden.
\end{description}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=10cm \epsfysize=10cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/omt/stp2omt.epsf}
\end{center}
\caption{Die Systemarchitektur von StP OMT}
\label{StPArchitektur}
\end{figure}

Die Struktur und alle Details eines OMT Modells werden im \pn{StP Repository} gespeichert und sind "uber das \pn{Object Management System} zugreifbar. Erw"ahnenswert ist an dieser Stelle noch der integrierte \pn{Script Manager}, mit dem sowohl die Generierung von {\cpp} Kode als auch die Pr"ufung auf Konsistenz und semantische Korrektheit m"oglich ist. Gerade die M"oglichkeit, solche "Uberpr"ufungen automatisch durchf"uhren zu k"onnen, ist in gro"sen Projekten mit mehreren Entwicklern wichtig. 


\section{Analyse des Index zur politischen Ikonographie}
\label{Abs. Objektmodell}
Die Analyse wurde in zwei Schritten durchgef"uhrt:
\begin{enumerate}
\item Erstellung einer Problembeschreibung
\item Umsetzung der Problembeschreibung in ein OMT-Objektmodell
\end{enumerate}

Ein \e{Objektmodell} beschreibt die statische Struktur eines Systems. Zur statischen Struktur eines Systems geh"oren:
\begin{itemize}
\item Objekte
\item Beziehungen zwischen Objekten
\item Attribute und Operationen, die eine Klasse von Objekten charakterisieren
\end{itemize}

Hier sollen nun die Konzepte und die dazugeh"orige Notation des OMT-Objektmodells als das grundlegende Modell der OMT Methodik erl"autert werden. Am Beispiel des Index zur politischen Ikonographie wird die Entwicklung eines Objektmodells verdeutlicht. 

\subsection{Die Problembeschreibung}
\label{Abs. Problembeschreibung}
Wie in Abschnitt~\ref{Abs. Analyse} bereits dargestellt, steht vor der Erstellung eines Objektmodells eine ad"aquate Problembeschreibung, die die Anforderungen an das System erl"autert. Ein Benutzerhandbuch f"ur das gew"unschte System ist eine gute Problembeschreibung. 

Die erste Problembeschreibung ist von den Mitarbeitern der politischen Ikonographie entworfen worden (siehe Anhang~\ref{Koop}). Sie enth"alt bereits alle f"ur eine Problembeschreibung wichtigen Anforderungen (Abschnitt~\ref{Abs. Analyse}), wenn sich auch einige der enthaltenen Angaben im weiteren Analyseprozess als unvollst"andig herausgestellt haben. So fehlte z.B. eine wichtige Eigenschaft der Bildkarten v"ollig, n"amlich die Auftragsnummer der Fotostelle. Diese Auftragsnummer wird meist auf der R"uckseite der Bildkarten eingetragen und dient dem Wiederfinden der nach diesen Nummern abgelegten Negative zu den Bildern.

Diese Problembeschreibung wurde mit den Mitarbeitern der Politischen Ikonographie besprochen und eine zweite Version erstellt (siehe Anhang~\ref{Beschreib}). Beide Dokumente dienten dann zus"atzlich zu den Notizen der Gespr"ache mit den Kunsthistorikern als Grundlage f"ur das Objektmodell. Insgesamt fanden in der Analysephase f"unf jeweils ca. zweist"undige Treffen mit den Kunsthistorikern statt, bei denen die Problembeschreibungen und darauf aufbauend die Entw"urfe zu den OMT-Objektmodellen besprochen und diskutiert wurden. 

\subsection{Objekte und Klassen}
\label{Abs. ObjUndKl}

Ein \e{Objekt} ist ein Konzept, eine Abstraktion oder eine Sache mit klar umrissenen Grenzen, das in einem Anwendungszusammenhang sinnvoll ist. So ist z. B. im Index zur politischen Ikonographie eine Bildkarte oder ein Stichwort, unter dem diese Bildkarte abgelegt ist, ein Objekt. Objekte haben den Zweck, einerseits das Verst"andnis der realen Welt zu f"ordern und andererseits als Basis f"ur die Implementation zu dienen.

Die Dekomposition eines Problems in Objekte h"angt vom individuellen Blickwinkel des Betrachters ab. Es gibt nicht \e{die} korrekte Repr"asentation. 

Alle Objekte haben eine Identit"at und sind unterscheidbar, auch wenn sie eventuell gleich aussehen und sich auch im Verhalten nicht unterscheiden. \e{Objektidentit"at} ist eines der wichtigen Konzepte in der Objektorientierung \cite{K*90}, z.B. im Gegensatz zum relationalen Modell \cite{Lo87}.

Eine \e{Objektklasse} beschreibt eine Menge von Objekten mit gleichartigen Eigenschaften (Attributen), gemeinsamem Verhalten, gleichartigen Beziehungen zu anderen Objekten und derselben Semantik. In unserem Fall sind z.B. die Menge der Bildkarten und die Menge der Stichworte Objektklassen.

\subsubsection{Objektdiagramme}
\label{Abs. Objektdiagramme}

Mit Hilfe von \e{Objektdiagrammen} lassen sich Objekte, Klassen und die Beziehungen zwischen diesen formal grafisch abbilden. Man unterscheidet zwei Arten von Objektdiagrammen:

\begin{description}
\item [Klassendiagramm:]\hspace{.1cm}
Ein Klassendiagramm ist ein Schema - "ahnlich dem eines Entity-Relationship Modells \cite{Fow93} - zur Beschreibung vieler verschiedener Instanzen von Daten. Ein Klassendiagramm beschreibt Objektklassen. 
\end{description}

\begin{description}
\item [Instanzendiagramm:]\hspace{.1cm}
Ein Instanzendiagramm stellt eine bestimmte Menge von Objekten und ihre Beziehungen zueinander dar. Instanzendiagramme sind f"ur die Dokumentation von Testl"aufen und Diskussionsbeispielen sinnvoll. Zu einem gegebenen Klassendiagramm gibt es eine unendliche Menge von Instanzendiagrammen. Ein Instanzendiagramm beschreibt Objektinstanzen.
\end{description}

Abbildung~\ref{KlUndObj} zeigt ein Klassendiagramm (links) und ein m"ogliches Instanzendiagramm (rechts). Die Objekte \e{Ludwig XIV. und B. Franklin} und \e{Tetrarchen-Denkmal an San Marco} sind Instanzen der Klasse \e{Bildkarte}.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=10cm \epsfysize=3cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/omt/klassenundobjekte.epsf}
\end{center}
\caption{Klassen und Objekte}
\label{KlUndObj}
\end{figure}

In Anhang~\ref{WichtigeKlassen} ist eine Sammlung der f"ur den Index zur politischen Ikonographie wichtigen Klassen abgebildet.  

\subsubsection{Attribute}
\label{Abs. Attribute}

Ein \e{Attribut} ist ein Datenwert, der zu jedem Objekt einer Klasse geh"ort. So sind z.B. Bildtitel und die Entstehungszeit des Bildes Attribute der Klasse Bildkarte. Jedes Attribut hat einen Wert f"ur jede Instanz eines Objektes. Verschiedene Objektinstanzen k"onnen gleiche oder verschiedene Werte f"ur ein gegebenes Attribut haben. 

Abbildung~\ref{AttUndWer} zeigt die Klasse \e{Bildkarte} mit den Attributen \e{Bildtitel} und \e{Bildentstehungszeit}, die beide vom Typ String sind. Das eine Objekt der Klasse \e{Bildkarte} hat den Wert \e{Ludwig XIV. und B. Franklin} als Bildtitel, das andere \e{Tetrarchen-Denkmal an San Marco}. Entsprechend ist es bei den Werten f"ur das Attribut \e{Bildentstehungszeit}.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=10cm \epsfysize=3cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/omt/attributeundwerte.epsf}
\end{center}
\caption{Attribute und Werte}
\label{AttUndWer}
\end{figure}

Neben den Attributen hat jede Klasse von Objekten auch ihre eigenen \e{Operationen}, die auf oder von den Objekten der Klasse angewendet werden k"onnen. Auf die Objekte der Klasse Bildkarte k"onnte z.B. die Operation \e{Bildkarte anzeigen} angewendet werden.
Nach der OMT-Methodik werden Operationen erst mit der dynamischen bzw. funktionalen Modellierung in das Objektmodell eingef"ugt, da ja erst dann die ben"otigten Operationen bekannt sind, die ein bestimmtes dynamisches oder funktionales Verhalten produzieren sollen. Weil in dieser Arbeit keine dynamische und funktionale Modellierung durchgef"uhrt wurde, sind in den folgenden Objektdiagrammen nur die Attribute der jeweiligen Klassen aufgef"uhrt.

\subsection{Verbindungen und Assoziationen}
\label{Abs. Assoz}

Eine \e{Verbindung} ist eine physische oder konzeptuelle Beziehung zwischen Objektinstanzen. So ist z.B. die Bildkarte `Ludwig XIV. und B. Franklin` \e{abgelegt unter} dem Stichwort `politische Begegnungen`. Eine Verbindung ist die Instanz einer Assoziation.

Eine \e{Assoziation} beschreibt eine Menge von Verbindungen mit gleicher Struktur und Semantik. So ist z.B. eine Bildkarte \e{abgelegt unter} einem Stichwort. Alle Verbindungen in einer Assoziation verbinden Objekte der selben Klassen. Eine Assoziation beschreibt eine Menge potentieller Verbindungen, so wie eine Klasse eine Menge potentieller Objekte beschreibt.

Assoziationen sind bidirektional, d.h. bin"are Assoziationen gelten in beiden Richtungen. So wird z.B. aus der Beziehung `eine Bildkarte \e{ist unter} einem Stichwort \e{abgelegt}` in umgekehrter Richtung `\e{unter} einem Stichwort \e{sind} Bildkarten \e{abgelegt}`. In Wirklichkeit "andert sich an der Assoziation nur der Name, die Bedeutung bleibt gleich.

Abbildung~\ref{VerbUndAssoz} zeigt eine n:m Assoziation mit entsprechenden Verbindungen. Sowohl Assoziationen als auch Verbindungen werden als Linien dargestellt.
 
\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/omt/verbundassoz.epsf}
\end{center}
\caption{Verbindungen und Assoziationen}
\label{VerbUndAssoz}
\end{figure}

\subsubsection*{Kardinalit"at}
\label{Abs. Kard}

Die \e{Kardinalit"at} legt fest, wieviele Instanzen einer Klasse zu einer Instanz einer anderen Klasse in Verbindung stehen d"urfen. Objektdiagramme visualisieren Kardinalit"at mit speziellen Symbolen an den Enden der Assoziationslinien. In Abbildung~\ref{VerbUndAssoz} handelt es sich um eine n:m Assoziation, d.h eine Bildkarte kann unter mehreren Stichworten abgelegt werden und ein Stichwort kann mehrere Bildkarten enthalten.

Die Notation der m"oglichen Kardinalit"aten ist in Abbildung~\ref{Kard} dargestellt.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=3cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/omt/kard.epsf}
\end{center}
\caption{Kardinalit"aten}
\label{Kard}
\end{figure}


\subsection{Verbindungsattribute}
\label{Abs. Verbindungsattribute}

Ein Attribut ist eine Eigenschaft von Objekten einer Klasse. Dementsprechend ist ein \e{Verbindungsattribut} die Eigenschaft einer Verbindung in einer Assoziation. So ist z.B. in Abbildung~\ref{Verbindungsattribut} \e{istOriginal} ein Attribut von \e{abgelegt unter}. Die Notation betont die "Ahnlichkeit von Objektattributen und Verbindungsattributen.
Die n:m Assoziation in der Abbildung~\ref{Verbindungsattribut} bietet zwingende Gr"unde f"ur ein Verbindungsattribut. Eine Karte kann unter mehreren Unterstichworten abgelegt werden und ein Unterstichwort kann mehrere Karten enthalten. Da der Benutzer aber gerne wissen m"ochte, wo sich die Originalkarte im physischen Index zur politischen Ikonographie befindet, ist das Verbindungsattribut \e{istOriginal} notwendig und kann ohne Informationsverlust  nicht einer der beiden Klassen zugordnet werden.


\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=3cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/omt/verbattrib.epsf}
\end{center}
\caption{Verbindungsattribut}
\label{Verbindungsattribut}
\end{figure}

\subsection{Generalisierung und Vererbung}
\label{Abs. GenUndVererb}

\e{Generalisierung} ist die Beziehung zwischen einer Klasse und einer oder mehrerer ihrer verfeinerten Versionen. Die Klasse, die verfeinert wird, nennt man \e{Superklasse}, jede ihrer Verfeinerungen wird als \e{Subklasse} bezeichnet. In Abbildung~\ref{Generalisierung} ist \e{Stichwort} die Superklasse der Klassen \e{Hauptstichwort} und \e{Unterstichwort}. Gemeinsame Attribute und Operationen einer Gruppe von Subklassen werden der Superklasse zugeordnet und gelten dann f"ur jede Subklasse, ohne da"s sie dort noch einmal aufgef"uhrt werden. Man sagt, jede Subklasse \e{erbt} die Kennzeichen ihrer Superklasse.  

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=4cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/omt/general.epsf}
\end{center}
\caption{Generalisierung}
\label{Generalisierung}
\end{figure}

\subsection{Das Objektmodell f"ur den Index zur politischen Ikonographie}
\label{Abs. OM-PI}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=15cm \epsfysize=14cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/omt/omt1.ps}
\end{center}
\caption{OMT Objektmodell Stichworte}
\label{Index1}
\end{figure}

Das Objektmodell f"ur den Index zur politischen Ikonographie wurde der besseren "Ubersicht wegen in zwei Teile geteilt. Die Abbildung~\ref{Index1} beschreibt die Struktur des Index selbst, also die Struktur von Haupt- und Unterstichworten. Man sieht in der Abbildung deutlich, da"s ein Stichwort entweder Hauptstichwort oder Unterstichwort sein kann und da"s mehrere Unterstichworte ein beliebiges Stichwort pr"azisieren k"onnen. Au"serdem k"onnen beliebig viele Karten unter beliebig vielen Unterstichworten abgelegt werden. Wenn eine Karte mehreren Unterstichworten zugeordnet wurde, enth"alt das Assosziationsattribut \e{istOriginal} die Information, welchem Unterstichwort die Originalkarte zugordnet wurde. Das ist wichtig, wenn neben der sp"ater m"oglichen Bildschirmdarstellung der Karte auf das physische Original zugegriffen werden soll.   

In Abbildung~\ref{Index2} ist das Modell unterhalb der Stichwort-Ebene zu sehen.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=15cm \epsfysize=8,5cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/omt/omt2b.ps}
\end{center}
\caption{OMT Objektmodell Karten}
\label{Index2}
\end{figure}

Die Klasse \e{Karte} ist eine abstrakte Klasse, d.h. es gibt keine Instanzen dieser Klasse. Die Klasse \e{Karte} dient als Superklasse f"ur die Klassen \e{Bildkarte}, \e{Karte mit Zitat aus Literatur} und \e{Karte mit Literaturangaben}. Die abstrakte Klasse \e{Karte} vererbt also ihre Attribute \e{"Anderungsdatum} und \e{Bearbeiter} an ihre drei Subklassen (siehe Abschnitt~\ref{Abs. GenUndVererb}). Die Generalisierung ist hier disjunktiv, d.h. eine Karte kann entweder eine \e{Bildkarte} oder eine \e{Karte mit Zitat aus Literatur} oder eine \e{Karte mit Literaturangaben} sein, niemals jedoch sowohl \e{Bildkarte} als auch \e{Karte mit Zitat aus Literatur}. 

"Uber die Klasse \e{Literatur} k"onnte eine Verbindung zum Datenbestand der Literaturdatenbank der politischen Ikonographie, die mit dem Programm Allegro verwaltet wird, hergestellt werden. Au"serdem gibt es in der Marburger Bibliothek bereits eine gro"se K"unstlerdatenbank, von der Teile bereits in den Prototyp eingearbeitet wurden. Diese Daten werden in Marburg mit Hilfe von MIDAS, dem Marburger Inventarisations-, Dokumentations- und Administrations-System \cite{Heu94} erfa"st und hier in der Klasse \e{K"unstler} verwaltet. 





