\documentclass[12pt,fleqn,a4paper]{report}
\usepackage[austrian]{babel}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage{german}
\usepackage{amsfonts}
\usepackage{latexsym}
\usepackage{xspace}
\usepackage{epsfig}
\usepackage{psfrag}
\usepackage{graphicx}

\textheight     680pt
\textwidth      460pt
\topmargin      -40pt
\oddsidemargin    5pt
\evensidemargin   5pt
\parindent        0pt

\begin{document} 
\begin{titlepage}
\centerline{\large  PS Software Engineering}
\vspace{0.5cm}
\hspace {2.3cm} 
PS-SWE-WS2000
\hspace{5.2cm}
\today

\vspace{2cm}
\centerline{\large\bf Archäologisches Managementsystem }
\vspace{0.2cm}
\centerline{\large\bf }

\vspace{1cm}
\centerline{\bf Report}
\centerline{\bf }


\vspace {1cm}
\centerline{Academic Supervisor Mag. Dipl.-Ing. Schwaiger Roland}

\vspace{1cm}
\centerline{\large Department of Computer Science}
\vspace{0.3cm}
\centerline{\large University of Salzburg}

\vspace{6.4cm}
Correspondence to: \\
\centerline{Universit\"{a}t Salzburg} \\
\centerline{Institut f\"{u}r Computerwissenschaften und Systemanalyse} \\
\centerline{Jakob--Haringer--Straße 2} \\
\centerline{A--5020 Salzburg} \\
\centerline{Austria}

\clearpage
\end{titlepage}






\date{}


\tableofcontents

\begin{abstract}
Erstellung eines Software- Packetes, das zur Erfassung und Verwaltung von archäologischen Daten verwendet wird. Die Erfassung, sowie die Bearbeitung und Darstellung der Daten soll webbasierend sein. Weiters wird über das Internet die Suche nach archäologgischen Daten (Funden) durch eine Suchmaschine ermöglicht. Eine bestimmte Auswahl an Informationen kann, durch die Erfasser aufbereitet, über das Internet in einem {\it{virtuellen Museum}} (VM) betrachtet werden.\\
Die Erstellung einer CD- ROM aus einem VM und die Zusammenstellung einer Auswahl der archäologischen Daten zu einem Fund- Katalog soll ebenfalls möglich sein.
\end{abstract}

\chapter{Architektur}

In einer generellen Betrachtung haben wir für die Darstellung des Systemes als Architektur den {\it Layer pattern} gewählt.
In dieser Methode wird das System aus verschiedenen Layern aufgebaut. Die einzelnen Bestandteile haben nach innen eine starke
Bindung und nach außen kommunizieren sie nur über Interfaces.

\section{Schichten Architektur}
Das System ist daher aus folgenden Schichten (Layer) aufgebaut:
\begin{description}
\item[Layer 7:] GUI-Engine
\item[Layer 6:] Session: Kontrolle und Steuerung der gesamten Session mit Prüfung der Berechtigungen zu den
		Aktivitäten.
\item[Layer 5:] Datenrepräsentation: Verwaltung aller, für diese Session benötigten Daten.
\item[Layer 4:] Filterung und Steuerung des Datenbankzugriffes, eingeteilt in die Teilbereiche {\bf Suchen, Einfügen
		und Ändern, Löschen}.
\item[Layer 3:] Datenbankzugriff mit Abfragen in aggregierter (komplexer) Form.
\item[Layer 2:] Aufspaltung von komplexen Abfragen in atomare Aufrufe und Kapselung des gesamten Datenbanksystems,
		um die Datenhaltung flexibel zu halten (Loadbalancing, mehrere Datenbanken, ...).
\item[Layer 1:] Datenbankverwaltung
\end{description}

Eine Darstellung dieser Architektur ist zu sehen in Abbildung \ref{archi_1}.

\newpage
\begin{figure}[h!]
{\par\centering \resizebox*{0.95\textwidth}{!}
{\includegraphics{archtektur.eps}} \par}
\caption{\label{archi_1}Architektur-Diagramm}
\end{figure}

\newpage
\section{Subsysteme}
In Abbildung \ref{archi_2} sind die einzelnen Teile der Architektur aufgeteilt in {\it Subsysteme} dargestellt.


\begin{figure}[h!]
{\par\centering \resizebox*{1\textwidth}{!}
{\includegraphics{subsystem.eps}} \par}
\caption{\label{archi_2}Diagramm von Subsystemen}
\end{figure}

\newpage
Für die bisher beschriebenen Use Cases stellt diese Architektur-Darstellung einen Querschnitt der einzelnen
Teilbereiche dar, die von jedem Use Case durchlaufen werden muß.
Am Beispiel des Suchens durch den Erfasser:
\begin{itemize}
\item Die GUI-Engine erzeugt (nach korrektem Login) eine Eingabeform für den Erfasser.
\item Die Session verwaltet die Berechtigungen  bezüglich des Erfassers beim Suchen.
\item Die Datenrepräsentation enthält alle relevanten Suchbegriffe und Ergebnisdaten der Suche.
\item Bei der Suche wird im {\it Layer 4} die Suche aufgerufen.
\item Die Frage wird weitergereicht an die darunterliegenden Layer, die nach entsprechendem Aufwand eine atomare
Datenbankabfrage durchführen.
\item Nach dem Durchsuchen der Datenbank werden von dort in umgekehrter Reihenfolge die einzelnen Stationen
durchlaufen bis die Ergebnisse die GUI-Engine erreicht haben, die dann eine Ergebnisdarstellung aufbaut.
\end{itemize}

Die Subsysteme enthalten verschiedene Bereiche der Funktionalitäten, welche den anderen Subsystemen mittels
Interfaces zur Verfügung gestellt werden.

\subsection{Funktionalität und Interface}



\begin{enumerate}
\item {\bf GUI-Engine: } 
	\begin{description}
	\item[Funktionalität: ]
	Generierung einer GUI aus der Funktionalität (Use Cases), der
	vorhandenen Daten und der zur Verfügung stehenden Rechte.
	
	\item[Interface: ] GUI-Oberfläche (Html-Fenster am Browser).
	
	\end{description}
\item {\bf Session: } 
	\begin{description}
	\item[Funktionalität: ]
	Auswertung, Filterung und Weiterleitung  der Informationen zwischen GUI
	und der darunterliegenden Schichten (Daten, Rechte, ..). \\
	Hier befinden sich die gesamten Use-Case Repräsentationen. \\
	Nach den Use Cases werden die darunterliegenden Schichten entspechende
	Aktionen ausführen. \\ Bsp: Artefakte suchen: \\ Daten von Artefakte werden
	gespeichert und Suchaufrufe suchen nach Artefakten (nicht Personendaten).
	Die Überprüfung der Berechtigungen erfolgt ebenfalls hier. D.h. Funktionen
	der unteren Schichten werden nur dann ausgeführt, wenn auch eine
	Berechtigung dafür gegeben ist (z.B. Artefakte löschen).	
	\item[Interface: ]\begin{itemize}
		\item getData: Ist eine überladene Methode, die je nach Use Case die entsprechenden Daten
				zur Verfügung stellt.
		\item search\underline{ }for\underline{ }Data: Mit Suchkriterien als Parameter wird eine Suche veranlaßt.
		\item insert\underline{ }updateData
		\item delete\underline{ }Data
		\end{itemize}
	\end{description}

\item {\bf Datenrepräsentation: } 
	\begin{description}
	\item[Funktionalität: ]
	Verwaltung und Speicherung der gesammelten Daten dieser Sitzung.	
	\item[Interface: ]\begin{itemize}
		\item getData: Ist eine überladene Methode, die je nach Use Case die entsprechenden Daten
				zur Verfügung stellt.
		\item search\underline{ }for\underline{ }Data: Mit Suchkriterien als Parameter wird eine Suche veranlaßt.
		\item insert\underline{ }updateData
		\item delete\underline{ }Data
		\end{itemize}
	\end{description}
\item {\bf Suchen: } 
	\begin{description}
	\item[Funktionalität: ]
	Aufbereitung der Anfragen für die Suche in der Datenbank in Abhängigkeit
	zur Art der Suche (Artefakte suchen als Erfasser, \\ Internet-Besucher, ...). \\
	Die Aufbereitung ist abhängig vom übergebenen Objekt der Suchkriterien. \\
	Rückgabe der Ergebnisse aus der Suche an die darüberliegende Schicht.	
	\item[Interface: ] search\underline{ }for\underline{ }Data: Der Parameter ist ein Objekt zur Identifikation der Art der Suche.
				    Rückgegeben wird das Suchergebnis oder eine Fehlermeldung.
	\end{description}
\item {\bf Einfügen und Ändern: } 
	\begin{description}
	\item[Funktionalität: ]
	Ein übergebenes Objekt wird zum Insert oder Update für Aktualisierung an 
	die untere Schicht weitergeleitet.
	Bestätigung des Erfolgsstatus wird an die obere Schicht zurückgegeben.	
	\item[Interface: ] insert\underline{ }updateData
	\end{description}
\item {\bf Löschen: } 
	\begin{description}
	\item[Funktionalität: ]
	Informationen aus der oberen Schicht werden für die untere Schicht
	aufbereitet, um bestimmte Informationen aus der Datenbank zu entfernen
	(z.B. ganzes Artefakt entfernen, Publikation entfernen).	
	\item[Interface: ] delete\underline{ }Data
	\end{description}
\item {\bf Bearbeitung: } 
	\begin{description}
	\item[Funktionalität: ]
	Stellt der oberen Schicht die Funktionen zur Verfügung, die Abfragen
	komplexerer Datenbankzugriffe ermoglichen und gibt diese an die untere
	Schicht weiter. \\
	Die Ergebnisse aus dem Datenbankzugriff werden in entsprechend
	aggregierter Form an die darüberliegende Schicht weitergegeben (Bsp
	Suchertgebnisse bei Suche nach Artefakten).	
	\item[Interface: ]\begin{itemize} \item select: Rückgabe ist das Suchergebnis in aggregierter Form.
	 	   \item insert: Rückgabe ist eine Erfolgsmeldung oder Fehlermeldung.
		   \item update: wie bei insert.
		   \item delete: wie bei insert. \\
		   \end{itemize}
	\end{description} 
\item {\bf Datenzugriff: } 
	\begin{description}
	\item[Funktionalität: ]
	Die aggregierten Anweisungen auf die Datenbank werden von der oberen
	Schicht übernommen und in atomare Datenbankanweisungen aufgeteilt.
	Hier finden die atomaren Datenbankzugriffe statt.
	Die Ergebnisse des Datenbankzugriffes (in Rohform) an die obere Schicht
	zurückgegeben (bei Suche), oder nur die entsprechende Erfolgsrückmeldung
	(Bestätigung für erfolgreiches Insert, Update oder Delete).	
	\item[Interface: ] \begin{itemize} \item select: Rückgabe ist das Suchergebnis in aggregierter Form.
	 	   \item insert: Rückgabe ist eine Erfolgsmeldung oder Fehlermeldung.
		   \item update: wie bei insert.
		   \item delete: wie bei insert.
		   \end{itemize}
	\end{description}
\end{enumerate}


\chapter{Project Plan}

Aufgrund der Einteilung des Systems mittels Layer-Pattern ist ein Projektplan rein auf Basis der Use Cases nicht
sinnvoll. Vielmehr ist die Einteilung der Implementierung in Subsysteme in Verbindung mit Use Cases zu betrachten.

\section{Kategorisierung}

Eine Kategorisierung der Use Cases bezüglich der Problemstellung ist zwar noch mit dem Kunden genauer zu definieren, jedoch wollen
wir hier eine Diskussionsgrundlage anführen.
In der nachfolgenden Reihung ist die Priorität höher, je kleiner die Nummer der Kategorie ist (1 ist die höchste).
\begin{description}
\item[Kategorie 1:] Erfassung, Bearbeitung und Entfernung von archäologischen Daten.
\item[Kategorie 2:] Erfassung, Bearbeitung und Entfernung von personellen Daten.
\item[Kategorie 3:] Suche nach und Anzeige von gefundenen Daten.
\item[Kategorie 4:] Erfassung, Bearbeitung und Entfernung von wissenschaftlichen Daten.
\item[Kategorie 5:] Erzeugung, Bearbeitung und Besuch von VM und Sonderschauen.
\item[Kategorie 6:] Erzeugung eines Kataloges oder einer CD.
\end{description}

Bei der Kategorisierung muß jedoch auch die Implementierung bezüglich der Subsysteme berücksichtigt werden.
So sind für die Implementierung einer Kategorie die Subsysteme der Layer eins bis vier Voraussetzung.
Die Prioritäten der Subsysteme gehen aus der Layer-Darstellung der Architektur aus Abbildung \ref{archi_1} hervor.
Die Aufteilung der Priorität bei den Layern:
\begin{enumerate}
\item {\bf Layer 1-4: } Datenbank mit Datenbankmodell, DB Zwischenschicht, DB Bearbeitungsschicht, Suchen, Einfügen und Ändern, Löschen
\item {\bf Layer 5-7: } Datenrepräsentation, Session, GUI-Engine. Hier werden die Use Case spezifischen Teile implementiert (siehe Kategorien). 
\end{enumerate}

\section{Entwicklungsrisiko}

Das Entwicklungsrisiko ist bei der Aufteilung der Prioritäten für die Subsysteme berücksichtigt.
Größtes Risiko liegt in den Layern eins bis vier der Layer-Architektur.

\section{Entwicklungszeit}

In der ersten Durchführbarkeitsstudie war die gesamte Mann-Wochen Anzahl bei 135 Stunden. Dieses Ergebnis soll hier nocheinmal betrachtet werden.

Ziel der Einteilung der Implementierungsphase in einzelne gleichgroße Iterationsschritte ist, daß nach jedem Iterationsschritt ein Teil der Implementierung (ein Use Case zum Beispiel) dem Kunden zum Testen übergeben werden kann.\\
 So ist ein regelmäßiges Feedback für beide Seiten möglich.
Hierbei sei jedoch zu beachten, daß nach Abschluß der Implementierung der Layer eins bis vier diese bei der Implementierung der Use Cases weiter angepasst werden müssen. \\ 

Durch die Einteilung in {\it Kategorien} und {\it Subsystemen} ergibt sich eine Einteilung in sieben Iterationsschritte. \\
Die ersten vier Layer der Layer-Architektur sind ein wesentliches Grundgerüst für die einzelnen Kategorien, deshalb werden hier zwei Iteratiosschritte einberechten. \\  

Mit der Orientierung auf die erste Durchführbarkeitsstudie mit einer Projektgesamtlänge von 135 Mann-Wochen sind hier für die Implementierung eine Dauer von 120 Mann-Wochen eigerechnet. \\
Ein Iterationsschritt hat demzufolge (acht Iterationen) eine Dauer von 15 Mann-Wochen.

Die Implementierungsreihenfolge nach Priorität ist nachfolgend angeführt:
\begin{enumerate}
\item {\bf Subsysteme: } Layer eins bis vier der Layer-Architektur. - {\bf zwei Iterat.-S.: 30 M-W)} 
\item {\bf Kategorie: 1} -  ein Iterationsschritt: {\bf 15 M-W}
\item {\bf Kategorie: 2} -  ein Iterationsschritt: {\bf 15 M-W}
\item {\bf Kategorie: 3} -  ein Iterationsschritt: {\bf 15 M-W}
\item {\bf Kategorie: 4} -  ein Iterationsschritt: {\bf 15 M-W}
\item {\bf Kategorie: 5} -  ein Iterationsschritt: {\bf 15 M-W}
\item {\bf Kategorie: 6} -  ein Iterationsschritt: {\bf 15 M-W}
\end{enumerate}

{\bf Implementierungsgesamtdauer: 120 Mann-Wochen}\\ \\
{\bf Anzahl der Iterationsschritte: 8} (2 Schritte für Layer eins bis vier). \\ \\




\end{document}
