PS Software Engineering^{†} Individuelles Gesamtdokument

A^{‡}

Universität Salzburg Institut für Computerwissenschaften A–5020 Salzburg, Austria

31. Oktober 2000

†gehalten an der Universität Salzburg von Mag. Dipl.-Ing. Schwaiger Roland im WS 2000/01 ‡Email: A@sbg.ac.at

Kapitel 1

Einleitung

Für das PS Software Engineering ist als praktische Übung für die Konzepte und Methoden des Software Engineerings das Systemdesign einer gestellten Aufgabe zu erarbeiten. Dazu sollen wir die Rolle eines Angestellten der fiktiven Firma “SE-AG” einnehmen, die mit diesem Problem beauftragt wurde und sie diesem Projekt zugeteilt hat. Es soll nicht nur eine individuelle Lösung ausgearbeitet werden, es ist auch im Rahmen einer Gruppenarbeit eine Gruppenlösung zu erstellen.

1.1 Einführung in die Aufgabenstellung

Die Aufgabenstellung für das zu erarbeitende Projekt ist in Form eines Gesamtszenarios und eines darin eingebetteten Business Case definiert.

1.1.1 Gesamtszenario

Unser Unternehmen, die SE AG, ist ein kompetenter Partner der Industrie und der öffentlichen Stellen. Wir sind bekannt als Ansprechpartner für Problemstellungen aller Art. Spezielles know-how und die entsprechenden Referenzkunden können wir im Bereich Software Engineering anbieten, dadurch hat sich auch der weiter unten angeführte (anonyme) Kunde vertrauensvoll an uns gewandt.

Zur Realisierung der angeführten Problemstellung wurde vom Vorstand beschlossen, Entwicklungsgruppen einzurichten, die parallel an der Problembearbeitung tätig sind.

1.1.2 Business Case

An unser Unternehmen wurde die Anforderung herangetragen, ein Software System zur Erfassung von archologische Daten(Siedlungen, Grber, Artefakte) über ein Web Frontend zu erstellen. Dabei sollten die erfaßten Daten ab dem Zeitpunkt der Erfassung, je nach Attribuierung des Erfassers im Internet zur Betrachtung zur Verfügung gestellt werden. Diese Artefakte sollten vom Internetbesucher gesucht und selektiert werden können. Dabei ist darauf zu achten, daß nur gewisse Daten dem Internetbesucher präsentiert werden.

Es wurde vom Kunden erwähnt, daß es unterschiedliche Erfassergruppen gibt. Die eine Gruppe, im folgenden als Erfasser bezeichnet, erfassen die Grunddaten eines zu Siedlungen, Gräber, Artefakts, die zweite Gruppe, im folgenden als wissenschaftliche Erfasser bezeichnet, pflegen weitere Daten, wie z.B. Interpretationen zum Artefakt, Publikationen zum Artefakt, etc. Im Gegensatz zum Internetbesucher sollte der Erfasser die Möglichkeit haben, auf alle Daten der Datenbank zuzugreifen und Beziehungen zwischen den archäologischen Daten zu hinterlegen. Dies wird insbesondere dann vonnöten sein, wenn sich z.B. mehrere Artefakte in einem Grab befinden. Weitere Beziehungen sollten für vorhandene Publikationen zu den Artefakten eingegeben werden können. Eine weitere Anforderung besteht darin aus den erfaßten Daten ein Virtuelles Museum - bestehend aus virtuellen Rumen - aufzubauen, wobei der Erfasser die Möglichkeit haben sollten, aus den erfaßten Daten Virtuelle Vitrinen zusammenzustellen, die an beliebigen Orten im Virtuellen Museum positioniert werden knnen. Die Einzelobjekte sollten aus dieser Vitrine selektiert und wie oben beschrieben dargestellt werden. Natürlich wird vom Kunden erwartet, daß zusätzliche Texte als Rahmen für das Virtuelle Museum (=Thema), die Virtuellen Räume(=Thema) und die Virtuellen Vitrinen erfaßt werden können, vergleichbar mit Schautafeln in einem realen Museum. Natürlich wird erwartet, daß die Darstellung am Web Frontend augenfällig sein soll, das bedingt, daß der Erfasser, bis zu einem gewissen Grad, Gestaltungsmöglichkeiten zur dargestellten Information haben muß. Der Kunde erwartet sich eine zentrale Datenhaltung, die nicht vor Ort sein sollte, also werden wir als ASP (Application Service Provider) gegenüber dem Kunden auftreten. Dies bedingt, dass die Pflege der Datenbank (Änderungen, Wartung, Backup, etc.), der Programme (Wartung, neue Versionen, Fehlerbehebung, etc.), etc. in unseren Händen liegen wird und wir dafür die notwendigen Werkzeuge entwickeln müssen. Es wurde von der Geschäftsleitung der Einsatz von XML gefordert, um die Inhalte auf einer breite Palette an Endgeräten zu präsentieren. Nicht zuletzt stellte der Kunde die Anforderung, repräsentative CD-ROMs der Virtuellen Museen (=Sonderschauen) und gedruckte Kataloge zu den Sonderschauen zu erstellen. Die Geschäftsleitung hat weiters beschlossen, den Rational Unified Process als Grundlage für die Systementwicklung zu verwenden.

1.2 Die Dokumentation

Das hier vorliegende Dokument beinhaltet als formalen Teil die für dieses Projekt zu erstellende individuelle Gesamtlösung.

Des weiteren sind aber auch einige der bei Überlegungen entstandenen Ideen und mögliche Konzepte darin enthalten. Die davon geeignet erscheinenden Ansätze werden später während des Projektverlaufs ebenfalls in den formalen Teil übernommen.

Auch soll in dieser Dokumentation der Projektablauf mit seinen Iterationsschritten verfolgbar werden.

Project Description

2.1 Aufgabenstellung

Aus dem in der Einleitung definierten Business Case ist eine ausführliche Problembeschreibung zu erstellen. Dabei sollen sich Auftraggeber und Software-Entwickler klar werden, was eigentlich zu machen ist. In der Problembeschreibung sollte erfaßt sein, WAS erreicht werden soll, nicht WIE. Falls wichtige Aspekte auftauchen, die NICHT Bestandteil des Projektes sein sollten, dann muß das ebenfalls in der Problembeschreibung enthalten sein.

Im ersten Schritt sind dazu die anfänglich nur grob spezifizierten Anforderungen (initial statement of needs) an das zu erstellende System aus dem Business Case zu identifizieren. Diese stellen vorläufig die sogenannten key features des Systems dar. Weiters sollen bereits vorgegebenen Randbedingungen erfaßt werden.

Um diese vorerst nur grob umrissenen Anforderungen präzisieren, erweitern und ergänzen zu können, muß nun der Dialog mit dem Auftraggeber und den zukünftigen Benutzern des zu erstellenden Systems gesucht werden. Zusätzlich sollen weitere Ansprechpartner für spezielle Teilbereiche des zu behandelnden Problems identifiziert werden.

Damit sollten in dieser ersten Phase der Projektdefinition hauptsächlich Fragen an den Auftraggeber (dh. an einen repräsentativen Teil der zukünftigen Benutzer des Systems) im Vordergrund stehen. Aus der Beantwortung dieser Fragen muß nun die Problembeschreibung ausgearbeitet werden. Da diese Antworten ebenfalls wieder neue Fragen aufwerfen werden, ist dies ein iterativer Prozess. Dieser wird fortgesetzt bis eine detaillierte Problembeschreibung vorliegt, aus der im nächsten Schritt unmittelbar die Anforderungen entnommen werden können.

Es sollte dabei auf Vermutungen und unbegründete Annahmen bezüglich der Funktionalität des Systems verzichtet werden. In jenen Bereichen, die nicht speziell dem zu untersuchenden Fachgebiet (sondern mehr der Software-seitigen Implementierung) zuzuordnen sind, sollen dem Auftraggeber jedoch Vorschläge zur Orientierung und eventuell Prototypen zur Demonstration der Möglichkeiten der zu erstellenden Software vorgelegt werden.

2.2 Key features und Umgebungsbedingungen

Das zu erstellende Software-System soll den Benutzern die folgenden aus dem Business Case identifizierten Funktionen zur Verfügung stellen.

• Erfassen und Pflege von archäologischen Daten in einer Datenbank (über ein Web-Frontend).

• Datenbankabfragen zur Darstellung der erfaßten Daten.

• Unterschiedliche Zugriffsrechte auf die Inhalte der Datenbank.

• Erstellen von virtuellen Museen aus den erfaßten Daten mit der Möglichkeit der visuellen Gestaltung der darzustellenden Information.

• Erstellung von CD-ROM’s und gedruckten Katalogen dieser virtuellen Museen.

Dabei sind die folgenden Umgebungsbedingungen zu berücksichtigen.

• Es wird vom Kunden eine zentrale Datenhaltung gewünscht, er will diese Aufgabe jedoch nicht selbst übernehmen. Daher wird diese Aufgabe von uns in der Rolle eines ASP (Application Service Provider) übernommen. Dies impliziert die Verwendung von entsprechenden Betriebsmitteln (Hard- und Software, Werkzeuge zur Datenbank-Administration, etc.).

• Es ist der Rational Unified Process als Grundlage für die Systementwicklung zu verwenden.

• Für die Präsentation der Inhalte ist der Einsatz von XML gefordert.

2.3 Verzeichnis der Ansprechpartner

Problemspezifische Informationen könnten aus den folgenden Quellen akquiriert werden:

• Kompetenzen des Auftraggebers berücksichtigen.

• Interviews mit Repräsentanten der aus der vorläufigen Problembeschreibung identifizieren Benutzer-Klassen.

• Für den Aufbau der Datenbank Experten aus dem Bereich der Multimedia-Datenbanken zurate ziehen. Beantwortung von Fragen der Art - Wie können multimediale Inhalte optimal in einer Datenbank gespeichert werde? - Welche Tools und Werkzeuge stehen zur Wartung und Pflege von Datenbanken bereits standardmäßig zur Verfügung?

• Um die Aufgaben der Erfasser zu untersuchen, kann eine Ausgrabung besucht werden. Dabei können die Tätigkeiten der Erfasser direkt vor Ort untersucht werden.

• Durch den Besuch von Museen, die sehr wahrscheinlich ihren Bestand bereits in einer Art Datenbank (schriftlich oder elektronisch) aufgelistet haben. Aus diesen können unter anderem Informationen über die benötigten Datenfelder extrahiert werden. Auch der Ablauf der Erfassung von archäologische Daten kann hier vielleicht verfolgt werden.

• Evaluation von bereits bestehenden archäologischen Datenbanken und virtuellen Museen im Internet.

• Es sollte vor allem untersucht werden, ob für archäologische Daten bereits eine einheitliche Standardschnittstellen zur Verfügung stehen!

2.4 Die erste Iteration

Im ersten Schritt des iterativen Verfeinerungsprozesses sollten vor allem jene Fragen geklärt werden, die wichtig für das Problemverständnis sind.

2.4.1 Verzeichnis der zu klärenden Fragen

Die sich aus dem Business Case ergebenden Fragen in diesem Abschnitt sind grob nach den identifizierten Key Features strukturiert.

Zu Begin sollte das sehr zentrale Problem der Rollen der verschiedenen Benutzer des Systems analysiert werden. Die vorliegende Problembeschreibung bietet in diesem Zusammenhang nur sehr ungenügende Ansätze. Es werden lediglich die beiden Aktoren “Erfasser” und “wissenschaftlicher Erfasser” eingeführt und deren grundlegende Tätigkeiten angegeben. Die folgenden Fragen sollen hier zu mehr Transparenz führen und sie sollend die beiden Rollen voneinander abgrenzen.

Frage 1: Wie werden archäologische Funde im jetzigen System dokumentiert? Frage 2: Wie sieht die Verteilung von Kompetenzen bei der Erfassung von archäologischen

Daten zwischen den beiden Aktoren “Erfasser” und “wissenschaftlicher Erfasser” aus?

Frage 3: Sind die durchzuführenden Aufgabenbereiche disjunkt oder gibt es hier Über-

schneidungen?

Frage 4: Wer hat die Rechte zur Datenfreigabe? Frage 5: Auf welchen Teil der Daten darf ein wissenschaftlicher Erfasser zugreifen? Frage 6: Gibt es in diesem Zusammenhang eine aktorenbezogene Bearbeitung bzw. Frei-

gabe von Daten?

Frage 7: Kann also ein wissenschaftlicher Erfasser die Daten des Erfassers bearbeiten bzw.

freigeben und umgekehrt?

Frage 8: Soll bei der Eingabe eines archäolog. Artefakts die Identität des Erfasser mit

gespeichert werden?

Frage 9: Falls ein Erfasser ein bestimmtes Artefakt nicht freigeben hat, soll dann dieses Artefakt nur für ihn sichtbar sein, oder aber auch für alle anderen Mitglieder der Erfassergruppe?

Frage 10: Soll es eine Art von Redaktionssystem geben, sodaß nur bestimmte Anwender die Daten erst nach einer redaktionellen Prüfung freigeben können?

Die folgenden Fragen sollen die Thematik der Erfassung und Pflege der Daten präzisieren.

Frage 1: Welche verschiedenen Typen (Text, Ton, Bild, ...) von Daten sind zu erfassen? Frage 2: Welche Aktoren erfassen welche Daten? Frage 3: Wie werden die Daten in die Datenbank integriert? Frage 4: Können die zu erfassenden Artefakte klassifiziert werden (zB. Klassifikation über

eine allgemeine Bezeichnung wie Grab, Vase, etc.)? Kann also jedes Artefakt einer bestimmten Gruppe zugeordnet werden?

Frage 5: Falls solch eine Einteilung erfolgen soll, kann es Artefakte geben, die in das vorhandene Klassifikationsschema nicht eingeordnet werden können? Welche Strategien sollen in solch einem Fall verfolgt werden?

Frage 6: Gibt es gemeinsame Attribute, die allen zu erfassenden Artefakten zugeordnet

werden können?

Frage 7: Ist in einer vorgegeben Klasse von Artefakten die Menge der Attribute vorgege-

ben?

Frage 8: Ist die verfügbare Menge der Datenfelder einer Klasse von Artefakten statisch, oder können bei der Dateneingabe neue Datenfelder definiert werden, die dann eventuell auch als klasseninhärente Datenfelder übernommen werden können?

Frage 9: Wurden bereits Standards zur Archivierung von archäologischen Daten definiert? Diese Frage kann von einer immensen Bedeutung für den Erfolg des Produktes sein. Falls solche Standards vorhanden sind, können diese auf das vorliegende Problem angewendet werden?

Frage 10: Soll ein eigener Standard definiert werden? In diesem Zusammenhang sollten

bereits existierende Systeme evaluiert werden.

Frage 11: Aus der Problematik der Rollenteilung zwischen den Gruppen der Erfasser resultiert weiters die Frage nach der unterschiedlichen Gestaltung der Eingabeoberfläche. Kann dabei eine gemeinsame Eingabemaske verwendet werden oder sollen spezifische Formulare verwendet werden?

Frage 12: Wie werden die geforderten Querverweise hergestellt?

Durch die unterschiedlichen Rechte wird es notwendig werden, die verschiedenen Benutzer der Datenbank zu unterscheiden.

Die folgenden Fragen sollen die Funktion der Abfrage der Daten präzisieren.

Frage 1: Welche Suchkriterien dh. welche Datenfelder der Datenbank können für die Be-

nutzer von Interesse sein?

Frage 2: Welche Suchmethoden (Volltextsuche, Suche durch bestimmten Klassifizierungs-

merkmalen, weiche Suche, ...) sollen zur Verfügung gestellt werden?

Frage 3: Wie können bestimmte Ton oder Bild-Dokumente gesucht werden – mittels Be-

schreibungen der Inhalte dieser Datentypen?

Frage 4: Wie soll das Ergebnis der Suche präsentiert werden? Frage 5: Sollen dabei verschiedene Ansichten auf das Suchergebnis möglich sein? Frage 6: Soll das aktuelle Suchergebnis durch Eingabe weiterer Kriterien verfeinert werden

können?

Frage 7: Sortierung des Ergebnisses nach bestimmten Kriterien? Frage 8: Wie schränken die verschiedenen Rechte der Benutzer der Datenbank das Ergebnis

der Suchanfrage ein? Dazu könnte ein “anonymer” Benutzer eingerichtet werden, der sich für die Abfrage nicht anzumelden hat, dem jedoch nur eine eingeschränkte Information (geregelt durch die Freigabe der Erfasser) präsentiert wird (ähnlich dem ALEPH-System der Bibliothek). Erfassern und wissenschaftlichen Erfassern kann nach einer erfolgten positiven Autorisierung der volle Datenbestand oder auch je nach Gruppenzugehörigkeit ein definierter Subset davon freigegeben werden.

Sehr aufwendig erscheint mir die Forderung nach der Möglichkeit der Erstellung von virtuellen Museen. Daher wurden vorläufig hauptsächlich jene Aspekte berücksichtigt, die einen Zusammenhang mit der zu erstellenden Datenbank haben.

Frage 1: Werden an die Daten der “Austellungsstücke” bestimmte Anforderungen gestellt

(zB. bestimmte zwingend vorhandene Attribute)?

Frage 2: Welche Benutzergruppe soll aus dem Datenbestand virtuelle Museen erstellen

können?

Frage 3: Dürfen auch nicht freigegebene Artefakte vom Ersteller der Datenbank in einem

virtuellen Museum verwendet werden?

Frage 4: Sollen die zugrundeliegenden Daten nach der Erstellung eines virtuellen Museums statisch sein, oder sollen Änderungen in der Datenbank automatisch auch in den anhängigen Museen erfolgen?

Frage 5: Soll das Museum nach bestimmten “Austellungsstücken” durchsucht werden kön-

nen?

Frage 6: Sollen dabei ähnliche Suchmechanismen zum Einsatz kommen wie bei den Da-

tenbankabfragen?

Frage 7: Welcher Freiraum soll dem Ersteller eines virtuellen Museums bei der textuellen

und graphischen Gestaltung eingeräumt werden?

Frage 8: Können bzw. sollen bestimmte Gestaltungselemente vorgegeben werden? Frage 9: Wie soll die Navigation in den Museen aussehen?

Zur Erstellung von CD-ROM’s und gedruckten Katalogen ist zu überlegen:

Frage 1: Welchen Datenumfang werden die zu erstellenden Museen normalerweise haben? Falls der Datenumfang sehr viel größer als die Speicherkapazität einer CD-ROM sein sollte, dann sollte überlegt werden, ob nicht gewisse (unwesentliche oder umfangreiche) Teile der zugrundeliegenden Daten aus dem Museum nur online zur Verfügung gestellt werden.

Frage 2: Welche Informationen werden aus den Museen in die gedruckte Kataloge über-

nommen.

Frage 3: In welchem Format/Layout (ganz allgemein) sollen die gedruckten Kataloge erzeugt werden? Hier sollte ein realer Katalog als Vorlage dienen.

Das Thema Präsentation der Inhalte mittels XML wurde vorerst noch nicht recherchiert.

Zu den nichtfunktionalen Anforderungen ergeben sich die folgenden Fragen.

Frage 1: Wie groß ist die zu erwartende Kapazität der zu erfassenden Daten? Frage 2: Welche durchschnittliche/maximale Abfragerate an die Datenbank ist zu erwar-

ten?

Frage 3: Maximale Anzahl der sich gleichzeitig im System befindenden Benutzer? Frage 4: Welche Anforderungen an die Verfügbarkeit der Datenbank gibt es?

Diese Faktoren bestimmen wesentlich die Dimensionierung des zu verwendenden Datenbanksystems.

Da die Bereitstellung und Pflege der Datenbank in unserem Aufgabenbereich liegt, soll auf eine aufwändige Entwicklung von Tools und Werkzeugen zur Wartung und für sonstige Aufgaben möglichst verzichtet werden. Da benutzerspezifische Zugriffsrechte auf die Inhalte der Datenbank benötigt werden, wird ein umfangreiches Benutzermanagement erforderlich sein.

Bemerkung: Es wäre (in der Praxis) sehr sinnvoll, wenn man zu den gestellten Fragen die jeweiligen Ansprechpartner notieren würde! Außerdem sollten die Fragen mit Prioritäten versehen werden, sodaß wichtige Fragen (u.a. jene von denen wieder weitere Fragen abhängen) zuerst geklärt werden können.

2.4.2 Evaluierung der Gesprächsprotokolle

Aus der Diskussion der obigen Fragen mit den entsprechenden Ansprechpartnern (in unserem Fall ja nur mit dem Proseminarleiter) ergeben sich nunmehr eine Reihe von Gesprächsprotokollen.

Bei der Evaluierung dieser Protokolle soll nun untersucht werden, wie die Antworten auf die gestellten Fragen ausgefallen sind (z.B.: klären diese die Frage nur zum Teil, entstehen dadurch neue Fragen, etc.), und wie sich diese in den bestehenden Business-Case einordnen lassen (z.B.: sind dabei Widersprüche zu den ursprünglichen Angaben entstanden, sind zusätzliche Aufgaben dazu gekommen, etc.).

[todo ...]

2.4.3 Verfeinerte Problembeschreibung

Aus der Diskussion der obigen Fragen mit den entsprechenden Ansprechpartnern ergibt sich nunmehr eine verfeinerte Problembeschreibung. Dabei ist als formale Grundlage das Ergebnis der Diskussion (in unserem Fall das vom project leader erstellte Gesprächsprotokoll) zu verwenden.

[todo ...]

2.5 Literaturverzeichnis

Ein großer Teil der Vorbereitungszeit wurde für das Einlesen in die themenspezifische Literatur und in die Einarbeitung der angegebenen Referenzen verwendet. Dazu wurden die folgenden Literaturquellen herangezogen:

• Jacobson, Booch, Rumbaugh: The Unified Software Development Process In Kapitel 3 ist eine Motivation der Use-Cases. Im Kapitel 6.3 “From Vision to Requirements” (u.a.) werden die ersten Schritte zur Anforderungserfassung ausführlich beschrieben. Eine detaillierte Beschreibung der Inception Phase findet sich in Kapitel 13.

• Österreicher: Objektorientierte Software und UML Es ist das Kapitel “Anforderungsanalyse” relevant. Insbesondere der Abschnitt “Vorstudie” mit einer Liste der der zu erstellenden Ergebnisdokumente und einer Checkliste!

• Sommerville: Software Engineering Enthält einen Anforderungskatalog.

• Vossen: Datenbank-Management-Systeme

• Artikel über XML im Computermagazin iX von 2/1999 und 6/1997

Requirement Analysis

In ihrer letzten Instanz sollte die Problembeschreibung bereits die Anforderungen informell beschreiben. Während die Problembeschreibung die Frage “Worin besteht das Problem bzw. die Aufgabe?” beantworten soll, behandelt die Anforderungsanalyse die Frage “Was ist zu tun, um dieses Problem / die Aufgabe zu lösen bzw. zu erfüllen?”.

3.1