% Studienarbeit von Andreas Boesch
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
%
% Kapitel: Bewertung und Ausblick


%\cleardoublepage

\chapter{Zusammenfassung und Ausblick}
\label{Kap. Zusammenfassung und Ausblick}
In diesem abschlie"senden Kapitel soll auf meine Erfahrungen mit den benutzten Entwurfswerkzeugen n"aher eingegangen werden. Hierbei werden neben OMT insbesondere das Datenbankprogrammiersystem {\acc} und die Programmiersprache {\vb} n"aher betrachtet. Das Ende des Kapitels bildet eine kritische Beurteilung meiner Arbeit, sowie eine Aufstellung m"oglicher sinnvoller Erweiterungen und Verbesserungen des Prototypen \e{Polit\-Icon}.

\section{Erfahrungen mit OMT}
\label{Abs. Erfahrungen1}
OMT-Objektmodelle dienten in dieser Arbeit zur Visualisierung der statischen Struktur des Index zur politischen Ikonographie. Sie waren Grundlage der Diskussionen mit den Kunsthistorikern und wurden von diesen auch akzeptiert und verstanden. Das urspr"unglich geplante Bearbeiten aller vier OMT-Phasen mu"ste aus Termingr"unden entfallen. Au"serdem war bei den Kunsthistorikern nach ca. 8 Wochen Diskussion (insgesamt f"unf zweist"undige Treffen) "uber Problembeschreibungen und OMT-Objektdiagramme ein Nachlassen des Engagements zu bemerken. Dies kann auch daran gelegen haben, da"s diese Treffen mit entsprechender Vor- und Nachbereitung von den Kunsthistorikern zus"atzlich zu ihrem normalen Arbeitspensum bew"altigt werden mu"sten. 

Kritisch zu beurteilen ist in diesem Rahmen der Einsatz des CASE-Werkzeuges StP OMT, da hier der Einarbeitungsaufwand und der tats"achliche Nutzen in einem ung"unsti\-gen Ver\-h"alt\-nis zueinander standen.  In gr"o"seren Projekten, bei denen alle vier Phasen der OMT-Methode durchlaufen werden und an denen mehrere Entwickler gleichzeitig arbeiten, kann dieses Werkzeug jedoch sehr n"utzlich sein. 


\section{Erfahrungen mit {\acc}}
\label{Abs. Erfahrungen2}
Die Benutzung des Datenbankprogrammiersystems {\acc} hat den Entwurf des relationalen Datenbankschemas wesentlich vereinfacht, da sich die Tabellen und ihre Beziehungen zueinander mit relativ geringem Aufwand erstellen lie"sen. Die einfach zu benutzenden (teilweise grafischen) Editoren beschleunigten die Entwicklung um ein Vielfaches.

Die Einbindung des K"unstler-Lexikons des Bildarchiv Foto Marburg wurde durch die F"ahigkeit von {\acc} zum Import von Textdateien in unkomplizierter Weise m"oglich.

In dieser Arbeit wurde nur ein geringer Teil der von {\acc} zur Verf"ugung gestellten Funktionalit"at genutzt. Nicht benutzt wurden z.B. die Funktionen zum Entwurf von Benutzerschnittstellen. Mit diesen Funktionen h"atte der Prototyp \e{PolitIcon} auch ohne Zuhilfenahme der Programmiersprache {\vb} realisiert werden k"onnen. In dieser Arbeit sollte jedoch gerade auch das Zusammenspiel dieser beiden Komponenten erprobt werden, da dieses dem Hersteller {\ms} als Marketing-Argument dient. Nach kurzer Einarbeitungszeit und der Beschaffung der sogenannten Kompatibilit"atsschicht, die f"ur die Kommunikation zwischen {\acc} Version 2.0 und {\vb} Version 3.0 notwendig ist, erfolgte die Zusammenarbeit nahezu reibungslos. Negativ zu bemerken sind hier nur die zum Teil nicht n"aher erl"auterten Fehlermeldungen beim Datenbankzugriff von {\vb} aus. 

\section{Erfahrungen mit {\vb}}
\label{Abs. Erfahrungen3}
Das Erstellen einer grafischen Benutzeroberfl"ache mit {\vb} ist sehr einfach, da sich die gew"unschten Schnittstellenkomponenten (z. B. Text- oder Listenfelder, Befehlsschaltfl"achen, Auswahlboxen, etc.) einfach mit der Maus positionieren und in der Gr"o"se anpassen lassen. 

Prozeduren und Funktionen werden in {\vb} in Modulen zusammengefa"st. Das Aufrufen solcher Unterprogramme erfolgt aber ohne Bezugnahme auf die jeweiligen Modulnamen. Dadurch wird beim Vorhandensein von vielen Modulen das Verfolgen eines Programmlaufes sehr zeitaufwendig, wenn nicht gar unm"oglich. 

Ein weiteres Problem von {\vb}-Programmen ist die im Vergleich zu in der Programmiersprache {\cc} geschriebenen Anwendungen niedrige Performanz, d.h. {\vb}-Programme sind relativ langsam. 

Au"serdem war es im Rahmen des K"unstler-Index nicht m"oglich, beliebig viele Datens"atze in einem Listenfeld anzuzeigen, da die Speicherverwaltung von {\vb} nur einen Speicherbereich von 64 KB (entspricht 5440 Eintr"agen in einer Liste) pro Listenfeld bereitstellt.     

\section{Der Prototyp -- eine Abschlu"sbetrachtung}
\label{Abs. Abschluss}

Zusammenfassend kann gesagt werden, da"s die bestehende Form des Prototypen seine Aufgabe erf"ullt. Es ist hier festzuhalten, da"s es sich bei \e{PolitIcon} um einen Prototypen im Sinne der Definition aus Abschnitt~\ref{Abs. Zielsetzung} handelt und nicht um ein dem Benutzer zu "ubergebendes Endprodukt. Daher ist es ganz nat"urlich, da"s nicht alle in den Problembeschreibungen erarbeiteten Anforderungen realisiert wurden, da dies den Rahmen meiner Arbeit weit "uberschritten h"atte. Aufgrund der Tatsache, da"s sich die Kunsthistoriker w"ahrend der ca. 3 Monate dauernden Programmierung f"ur den Einsatz einer kommerziellen Bilddatenbanksoftware entschieden haben, fand leider keine Diskussion mit den vorgesehenen Anwendern "uber den vorliegenden Prototyp statt.

Nachfolgend sind eine Reihe von m"oglichen Erweiterungen und "Anderungen aufgef"uhrt, die den Umgang mit dem Datenbanksystem effizienter gestalten k"onnten und zugleich den Bedienungskomfort erh"ohen w"urden:

\begin {itemize}
\item Eine erweiterte Zugreifbarkeit des Bildmaterials "uber mehrere Indizes ist erforderlich. Das hei"st, es sollte m"oglich sein, das Bildmaterial nicht nur "uber die Haupt- und Unterstichworte zu erschlie"sen, sondern z.B. auch "uber den K"unstlernamen, das Bild\-entstehungsjahr oder den Bildtitel. Die dabei entstehenden Bildzusammenstellungen w"urden neue Perspektiven auf das Forschungsmaterial erlauben.
\item Ein Problem im jetzigen Prototyp ist die Neuverschlagwortung von Bildern, da diese nur f"ur jeweils ein Bild zur Zeit erfolgen kann. Erforderlich w"are hier eine Funktion mit entsprechender Benutzeroberfl"ache, die es dem Benutzer erlaubt, mehrere Bilder gleichzeitig einem oder mehreren Stichworten zuzuordnen.
\item Die Performanz einer {\vb}-Anwendung, die letztlich mehr als 200.000 Datens"atze samt Bilddateien verwaltet, wird f"ur professionelle Anspr"uche nicht ausreichend sein. Daher ist zu "uberlegen, ob ein Endprodukt nicht doch mit einer Programmiersprache wie {\cc} oder {\cpp} realisiert werden sollte.
\item Kunsthistoriker arbeiten vielfach so, da"s sie die von ihnen unter verschiedenen Kriterien zusammengestellten Bildkombinationen auf dem Schreibtisch nebeneinander ausbreiten, um sie dann vergleichend zu untersuchen. Diese Arbeitsweise sollte auch von einer EDV-L"osung unterst"utzt werden. Dies k"onnte so realisiert werden, da"s jeder Benutzer Einzelbilder markieren, in seiner individuellen Bildmappe sammeln und sp"ater diese neue Zusammenstellung betrachten kann.  
\end{itemize}

W"ahrend die o.g. Erweiterungen und "Anderungen sehr auf eine Abbildung des derzeitigen Arbeitsplatzes der Kunsthistoriker hinzielen, sind dar"uber hinaus noch viel weitergehende Ans"atze denkbar. So w"aren z.B. computergest"utzte Werkzeuge zum interaktiven Entwurf von kunsthistorischen Pr"asentationen oder Ausstellungen denkbar, die auf einem digitalen Index zur politischen Ikonographie basieren. Au"serdem kommt der weltweiten Vernetzung von Computern in letzer Zeit immer gr"o"sere Bedeutung zu, so da"s bei einer Vernetzung der digitalen Bildbest"ande in aller Welt eine viel umfassendere und vielschichtigere Forschung betrieben werden k"onnte als es derzeit der Fall ist. Auch die Einbindung und die Verkn"upfung weiterer Forschungsmaterialien (Texte, Filme, Audiosequenzen, Hypertext- und Hypermediadokumente) bietet noch viel Raum f"ur weitere Forschungsaktivit"aten. 

Bei allen diesen Visionen w"urden sich allerdings auch die Arbeitsabl"aufe der Kunsthistoriker entscheidend ver"andern und da gerade im Bereich Kunst und Kultur die Schwellenangst vor Computern sehr gro"s ist, k"onnen solche Ideen nur in enger Zusammenarbeit mit den Betroffenen ausgearbeitet und realisiert werden.    
