Pflichtenheft von byteme - PI - Praktische Informatik

Pflichtenheft
der Gruppe ByteMe
Sinisa Djukanovic
Sebastian Eifert
Matthias Orgler
Kai Stroh
Carole Urvoy
Mario Vekic
Version 1.0
02.03.2004

Inhaltsverzeichnis
1 Einleitung 9
1.1 Beteiligte Parteien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Kapitelübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Projektübersicht 11
2.1 Ist-Zustand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Soll-Zustand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Musskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Wunschkriterien . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Anforderungsspezifikation 15
3.1 Use Case Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Persistenzmanagement . . . . . . . . . . . . . . . . . . . . . 17
3.1.1.1 Ein bestehendes Netz öffnen . . . . . . . . . . . . 17
3.1.1.2 Ein neues Netz anlegen . . . . . . . . . . . . . . . 18
3.1.1.3 Das aktuelle Netz exportieren / speichern . . . . . . 19
3.1.1.4 Zusammenführen von zwei Netzen . . . . . . . . . 20
3.1.2 Knotenmanagement . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2.1 Einen neuen Knoten in ein Netz einfügen . . . . . . 21
3.1.2.2 Einen Knoten aus einem Netz löschen . . . . . . . 22
3.1.2.3 Eigenschaften eines Knotens bearbeiten . . . . . . 23
3.1.3 Verbindungsmanagement . . . . . . . . . . . . . . . . . . . . 24
3.1.3.1 Eine Verbindung zwischen zwei Knoten erstellen . 24
3.1.3.2 Eine Verbindung zwischen zwei Knoten auflösen . . 25
3.1.3.3 Eigenschaften einer Verbindung bearbeiten . . . . . 26
3.1.3.4 Die Zielknoten einer Verbindung bearbeiten . . . . 27
3.1.4 Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.4.1 Knoten fokussieren . . . . . . . . . . . . . . . . . 28
3.1.4.2 Navigation durch das Netz . . . . . . . . . . . . . 29
3.1.4.3 Visualisierungsmodus verändern . . . . . . . . . . 30
3.1.4.4 Anwenden eines Filters auf die Visualisierung . . . 31
3.1.4.5 Suchen eines Knotens . . . . . . . . . . . . . . . . 32
3.1.5 Typenmanagement . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.5.1 Neues Typenprofil anlegen . . . . . . . . . . . . . 33
3.1.5.2 Bestehendes Typenprofil laden . . . . . . . . . . . 34
3.1.5.3 Neuen Typen hinzufügen . . . . . . . . . . . . . . 35
3.1.5.4 Typ löschen . . . . . . . . . . . . . . . . . . . . . 36
3.1.5.5 Typ bearbeiten . . . . . . . . . . . . . . . . . . . . 37
3

4 INHALTSVERZEICHNIS
3.1.5.6 Einem Netz ein Typenprofil zuordnen . . . . . . . . 38
3.1.6 Sonstiges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.6.1 Eine mit einem Knoten verbundene Aktion ausführen 39
3.1.6.2 Undo / Redo . . . . . . . . . . . . . . . . . . . . . 40
3.1.6.3 Bookmark auf einen Knoten erstellen . . . . . . . . 41
3.1.7 Priorisierung der Use Cases . . . . . . . . . . . . . . . . . . 42
3.2 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . . . 42
4 Benutzerinterface 45
4.1 Persistenzmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Knotenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Verbindungsmanagement . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4 Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5 Typenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.6 Sonstiges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Architektur 51
5.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6 Entwicklungsprozess 53
6.1 Interne Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Prozessstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.1 Rational Unified Process . . . . . . . . . . . . . . . . . . . . 54
6.2.1.1 Einführungsphase . . . . . . . . . . . . . . . . . . 54
6.2.1.2 Entwurfsphase . . . . . . . . . . . . . . . . . . . . 54
6.2.1.3 Konstruktionsphase . . . . . . . . . . . . . . . . . 54
6.2.1.4 Übergangsphase . . . . . . . . . . . . . . . . . . . 54
6.2.2 Extreme Programming . . . . . . . . . . . . . . . . . . . . . 55
6.2.2.1 Pair-Programming . . . . . . . . . . . . . . . . . . 55
6.2.2.2 Refactoring . . . . . . . . . . . . . . . . . . . . . 56
6.3 Iterationsplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.4 Prototypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.5 Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.6 Verwendete Software und Tools . . . . . . . . . . . . . . . . . . . . 59
6.6.1 Werkzeuge zur Dokumentation . . . . . . . . . . . . . . . . . 59
6.6.2 Werkzeuge zur Verwaltung und Kommunikation . . . . . . . 60
6.6.3 Werkzeuge zur Entwicklung . . . . . . . . . . . . . . . . . . 60
7 Qualitätssicherung 61
7.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2 Qualitätsmerkmale . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2.1 Änderbarkeit/Analysierbarkeit . . . . . . . . . . . . . . . . . 61
7.2.2 Stabilität/Zuverlässigkeit . . . . . . . . . . . . . . . . . . . . 62
7.2.3 Übertragbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.2.4 Konfigurierbarkeit . . . . . . . . . . . . . . . . . . . . . . . 62
7.2.5 Nutzwert . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.2.6 Konformität . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.2.7 Anwendbarkeit/Benutzerfreundlichkeit . . . . . . . . . . . . 62
7.2.8 Effizienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

INHALTSVERZEICHNIS 5
7.2.9 Prozessqualität . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3 Umsetzung im Projekt . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3.2 Richtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.3.3 Dokumentation von Änderungen . . . . . . . . . . . . . . . . 64
7.3.4 Layout und Stil . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.3.4.1 Code-Dokumentation . . . . . . . . . . . . . . . . 65
7.3.4.2 Namensgebung . . . . . . . . . . . . . . . . . . . 65
7.3.4.3 Programmierstandard . . . . . . . . . . . . . . . . 65
7.3.5 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3.5.1 Unit-Tests . . . . . . . . . . . . . . . . . . . . . . 65
7.3.5.2 Manuelle Tests . . . . . . . . . . . . . . . . . . . . 66
7.3.5.3 Fehlerdokumetation . . . . . . . . . . . . . . . . . 66
7.3.5.4 Durchführung . . . . . . . . . . . . . . . . . . . . 66
7.3.6 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . 66
7.4 Merkmals-Maßnahmen-Zuordnung . . . . . . . . . . . . . . . . . . . 67
7.5 Kontrolle der Qualität . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.6 Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.6.1 Mangelhafter Zeitplan . . . . . . . . . . . . . . . . . . . . . 68
7.6.2 Keine ordentliche Spezifikation . . . . . . . . . . . . . . . . 68
7.6.3 Anforderungs-Inflation . . . . . . . . . . . . . . . . . . . . . 69
7.6.4 Weggang von Personal . . . . . . . . . . . . . . . . . . . . . 70
7.6.5 Umzug in das Zintl-Gebäude . . . . . . . . . . . . . . . . . . 70
7.6.6 Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8 Rechtsgrundlagen 73
8.1 Vertragspartner und Vertragsgegenstand . . . . . . . . . . . . . . . . 73
8.2 Urheber- und Nutzungsrechte . . . . . . . . . . . . . . . . . . . . . . 73
8.3 Change-Request-Verfahren . . . . . . . . . . . . . . . . . . . . . . . 73
8.4 Schadensersatz- und Wartungsansprüche . . . . . . . . . . . . . . . . 74
8.4.1 Gewährleistung und Wartung . . . . . . . . . . . . . . . . . . 74
8.4.2 Schadensersatzansprüche . . . . . . . . . . . . . . . . . . . . 74
8.5 Anwendbares Recht und Gerichtsstand . . . . . . . . . . . . . . . . . 74
8.6 Zusicherungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.7 Ende des Vertragsverhältnisses . . . . . . . . . . . . . . . . . . . . . 74
A Eine Einführung in Topicmaps 77
A.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.2 Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.2.1 Kurze Einführung in Topicmaps . . . . . . . . . . . . . . . . 78
B Glossar 81

6 INHALTSVERZEICHNIS

Abbildungsverzeichnis
2.1 Sitemap von www.inxight.com . . . . . . . . . . . . . . . . . . . . . 13
2.2 Visual Thesaurus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Übersicht über den Zusammenhang der Use Cases. . . . . . . . . . . 16
4.1 Konzeptzeichnung der Benutzeroberfläche . . . . . . . . . . . . . . . 46
4.2 Erste Implementierung einer Benutzeroberfläche (erweiterter Prototyp 1) 46
6.1 Zeitliche Fixierung der Meilensteine . . . . . . . . . . . . . . . . . . 59
7

8 ABBILDUNGSVERZEICHNIS

Kapitel 1
Einleitung
Die Gruppe ByteMe nimmt am Software-Engineering-Praktikumder Technischen Universität
Darmstadt - Fachbereich Informatik - Fachgebiet Softwaretechnologie im Wintersemester
2003/2004 (SE2003) teil und entwickelt für die Firma Daedalos Consulting
GmbH 1 ein Werkzeug zur Bearbeitung und Visualisierung semantischer Netze. Für die
Betreuung seitens der TU Darmstadt ist Dipl.-Ing. Michael Haupt zuständig.
Dieses Pflichtenheft soll die genaue Aufgabenstellung festlegen, und damit Mißverständnisse
zwischen Daedalos und ByteMe verhindern. Die Angaben in diesem Dokument
sind für beide Seiten bindend, es handelt sich also um einen Vertrag zwischen der
Firma Daedalos und der Gruppe ByteMe.
1.1 Beteiligte Parteien
An der Entwicklung des Visualisierungswerkzeugs sind folgende Parteien beteiligt,
nachfolgend Auftraggeber und Auftragnehmer genannt:
Auftraggeber
Daedalos Consulting GmbH
Ruhrtal 5
D-58456 Witten
Germany
Der Auftraggeber wird vertreten durch:
Thorsten Dittmar
E-Mail: Thorsten.Dittmar@daedalos.com
Auftragnehmer
TUD, Projektgruppe ByteMe, bestehend aus
• Sinisa Djukanovic
• Sebastian Eifert
1 http://www.daedalos.com/
9

10 KAPITEL 1. EINLEITUNG
• Matthias Orgler
• Kai Stroh
• Carole Urvoy
• Mario Vekic
1.2 Kapitelübersicht
• Kapitel 2 gibt einen allgemeinen Überblick über den Ist- und den Soll-Zustand
des Projektes. Insbesondere werden an dieser Stelle die Muß- und Wunschkriterien
festgelegt.
• Kapitel 3.1 enthält die Anforderungen an das Projekt in Form von Use Cases.
Diese Use Cases spiegeln somit den gewünschten Funktionsumfang des Projektes
wider.
• Kapitel 4 beschreibt das geplante Benutzerinterface.
• Kapitel 5 beschreibt die grundlegende Architektureigenschaften des Systems.
• Kapitel 6 stellt den Entwicklungsprozess und einige darin verwendete Verfahren
dar und gibt einen Überblick über den zeitlichen Rahmen des Projekts.
• Kapitel 7 behandelt Aspekte der Qualitätssicherung.
• Kapitel 8 erläutert die rechtlichen Bedingungen des Vertrags mit Daedalos.
• Anhang A gibt eine kurze Einführung zum Thema Topicmaps.
• Anhang B ist ein Glossar, der Fachbegriffe erläutert.

Kapitel 2
Projektübersicht
Seit einiger Zeit gibt es aus unterschiedlichen Ansätze, für den Menschen typische
Denkstrukturen auch rechnergestützt zu erfassen und zu modellieren. Zwei Richtungen
sind dabei besonders sichtbar.
Zum einen versucht das W3C, eine neue Art von Web zu implementieren. Den Seiten
dieses Webs wird neben struktureller Information auch jede Menge semantischer
Information mitgegeben. Wer in Zukunft zum Beispiel in Google nach LKW sucht,
der wird auch die Seiten finden, in denen das Wort Lastkraftwagen steht. Diese zusätzlichen
Informationen können nicht nur die Qualität der Suchergebnisse erheblich
verbessern, auch wird es völlig neue Navigationswege geben.
Zum anderen werden Mindmaps und artverwandte Kreativitätsmanagementmethoden
immer beliebter. Dabei werden Gedanken, Ideen und ähnliches in einer nicht sequentiellen
Form als „Knoten“ erfasst, zwischen denen anschließend semantische Verknüpfungen
durch das Anlegen von Verbindungen hergestellt werden können. Verschiedene
Möglichkeiten der Bearbeitung erlauben anschließend die Reorganisation
von solchen Gedanken oder sogar die Generierung von Kapitelstrukturen, beispielsweise
für Word-Dokumente.
Manche Werkzeuge führen diese Ansätze auch zusammen, indem sie Websites
durchsuchen und aus deren Linkstruktur eine Art Mindmap erzeugen.
Die Struktur ist heute weitestgehend beschrieben. Unter anderem hat das W3C
einen Standard festgelegt, der das Format der Speicherung von semantischen Netzen
in einem XML-Dokument beschreibt (das so genannte XTM-Format).
Auch gibt es einige Open-Source-Werkzeuge zur textuellen Bearbeitung, doch bisher
sind entsprechende grafische Werkzeuge sehr teuer und meist auch nicht an eigene
Bedürfnisse anpassbar.
2.1 Ist-Zustand
Die Firma Daedalos benutzt derzeit zu Testzwecken einige Tools zur Strukturierung
von Informationen, zur Visualisierung solcher Strukturen sowie zur Erfassung inhärenter
Zusammenhänge. Eines dieser Tools ist „PersonalBrain“ der Firma „TheBrain
Technologies Corporation“.
Hierbei sind die Mitarbeiter allerdings auf zahlreiche Schwächen des Systems gestoßen.
Zunächst besitzt PersonalBrain nicht die gewünschte Flexibilität, da es nur zwei
Verbindungstypen (Synonym und Abhängigkeit) kennt. Zudem ist die Software nicht
11

12 KAPITEL 2. PROJEKTÜBERSICHT
plattformübergreifend, sondern nur für Win32-Systeme erhältlich. Daedalos setzt jedoch
hauptsächlich Linux- und Apple-Rechner ein.
Schwierigkeiten treten darüberhinaus bei der Interaktion mit bestehenden Knoten
(z.B. dem Verschieben) oder bei der visuellen Auswertung der Informationsnetze auf,
da immer nur ein sehr kleiner Ausschnitt des Netzes angezeigt wird.
2.2 Soll-Zustand
Ziel des Projektes ist es, eine Anwendung zu entwickeln, die es erlaubt, Knoten und
deren Verbindungen zu anderen Knoten in semantischen Netzen zu verwalten.
Die verwendete Technologie muss Java ab Version 1.4 sein. Alle dabei benutzten
Komponenten müssen lizenzrechtlich die Weiterentwicklung des Projektes auf Open-
Source-Basis zulassen.
Sowohl Knoten als auch die Verbindungen können unterschiedlichen Typs sein.
Verbindungen eines bestimmten Typs von einem Knoten zum nächsten können zum
Beispiel bedeuten, dass der eine Knoten ein Synonym für einen anderen Knoten ist.
Viele weitere Typen sind denkbar (Simplifizierung, Spezialisierung, Teilaspekt, Konsequenz,
etc.). Auch Knoten können Typen haben, z.B. eine These, ein Fakt, ein Axiom
oder eine Datei. Die Typen unterscheiden sich durch Layoutinformationen, Farben,
Umrandung und gegebenenfalls andere Aktionsmöglichkeiten. Es soll die Möglichkeit
bestehen, Typen je nach individuellem Bedarf zu erstellen und die oben erwähnten
Eigenschaften festzulegen.
Dabei sollte mit verschiedenen Sichtweisen auf das Netz experimentiert werden.
Gängige Sichtweisen sind
• die Fokussierung auf einen Knoten, verbunden mit der automatischen Darstellung
der angrenzenden Knoten,
• sich selbst dynamisch anordnende Knoten, wobei meist nur ein Teil des Netzes
dargestellt werden kann,
• vollständige Abbildung des Netzes (hauptsächlich von kleineren Netzen) mit
oder ohne automatischer Anordnung der Knoten.
Beispiele für eine gelungene Implementierung einiger dieser Darstellungsweisen
sind auf den folgenden Webseiten zu finden:
• http://inxight.com/map/ (siehe Abbildung 2.1)
• http://www.visualthesaurus.com/online/index.html(siehe Abbildung
2.2)
Da der Auftraggeber für seine Aufgabe ein flexibles Tool benötigt, das insbesondere
beliebige Knoten- und Verbindungstypen unterstützt und dabei plattformübergreifend
einsetzbar ist, reichen die bisher am Markt erhältlichen Programme nicht aus. Unser
Ziel ist es, eine in den genannten Punkten verbesserte Software zur Visualisierung semantischer
Netze zu entwickeln.

2.2. SOLL-ZUSTAND 13
Abbildung 2.1: Sitemap von www.inxight.com
Abbildung 2.2: Visual Thesaurus

14 KAPITEL 2. PROJEKTÜBERSICHT
2.2.1 Musskriterien
Die Implementierung der folgenden Musskriterien wird von der Gruppe ByteMe fest
zugesagt. Details zu den einzelnen Kriterien werden im Rahmen der Use Cases (s.
Kapitel 3.1) näher spezifiziert.
• Das Programm muss die Möglichkeit bieten, semantische Netze in einer 2D-
Ansicht darzustellen und eine Navigation durch die Netze erlauben.
• Der Benutzer muss in der Lage sein, Knoten zu einem Netz hinzuzufügen und
wieder zu löschen. Die Eigenschaften eines Knotens sollen bearbeitbar sein. Diese
Anforderungen gelten analog auch für Verbindungen.
• Es muss möglich sein, die Netze in Form von Dateien abzuspeichern und wieder
zu laden. Das Zusammenführen von mehreren Netzen muss möglich sein.
• Das Programm muss die Möglichkeit bieten, im laufenden Betrieb zwischen den
verfügbaren Visualisierungsarten umzuschalten. Der Benutzer muss darüberhinaus
in der Lage sein festzulegen, bis zu welcher Tiefe die verschiedenen Verbindungstypen
- ausgehend vom derzeit fokussierten Knoten - verfolgt werden
sollen.
• Das Typenmanagement muss hinsichtlich Flexibilität und Konfigurierbarkeit den
Ist-Zustand übertreffen. Es muss möglich sein, die einzelnen Typen anhand einer
Farbcodierung o.ä. in der verwendeten Ansicht zu unterscheiden.
• Es muss möglich sein, einem Knoten bzw. seinem Typ eine Aktion (z.B. das
Starten eines Programms oder das Öffnen einer Webseite) zuzuordnen, die auf
Befehl des Benutzers vom System ausgeführt wird.
2.2.2 Wunschkriterien
Die nachfolgenden als wünschenswert erachteten Funktionen sind keine Musskriterien,
d.h., sie werden von der Gruppe ByteMe nur implementiert, falls vor Ablauf des
Vertrages bereits alle Musskriterien verwirklicht und ausreichend getestet sind. Die
hier aufgeführten Punkte sind nicht verpflichtend, sollen aber eine spätere Richtung
der Weiterentwicklung aufzeigen. ByteMe wird versuchen, das Projekt so zu gestalten,
dass eine spätere Implementierung einfach möglich ist.
• Nach Vervollständigung der 2D-Ansicht, die in den Musskriterien beschrieben
ist, können weitere Experimente mit alternativen Visualisierungsarten (z.B. eine
sphärische 2D-Visualisierung) folgen.
• Eine Kompatibilität zum XTM (XML Topicmap) Standard wäre wünschenswert,
d.h. die Möglichkeit, Netze einzulesen, die ursprünglich nicht von unserem Programm
erstellt wurden.
• Evtl. könnte die Datenhaltung in einer Datenbank erfolgen, so dass alle Aktionen
des Benutzers sofortige Auswirkungen auf die persistente Speicherung haben.
• Netze könnten von entfernten Quellen geladen werden, die sich nicht im lokalen
Dateisystem widerspiegeln, z.B. über das Internet via HTTP.

Kapitel 3
Anforderungsspezifikation
3.1 Use Case Modell
Die hier beschriebenen Use Cases spezifizieren den gewünschten Funktionsumfang der
Anwendung. Sie stellen implementierungsunabhängig Episoden aus der Benutzung in
abstrakter Weise dar, die zum Erreichen eines Ziels des Benutzers dienen. Konkrete
Vorgehensweisen, die stark vom Design der Benutzerschnittstelle abhängen, werden,
soweit sie zum gegenwärtigen Zeitpunkt schon geplant sind, in Kapitel 4 beschrieben.
Abbildung 3.1 verdeutlicht den Zusammenhang zwischen den einzelnen Use Cases.
Der Benutzer unseres Programm kann zwei Rollen annehmen:
• Als Information Designer gibt er Informationen und Wissen in das semantische
Netz ein,
• als Information User nutzt der die Informationen des Netzes für seine Arbeit.
Der Information Designer benötigt dabei insbesondere die Möglichkeit, die Informationen
im Netz zu bearbeiten. Er kann Knoten- und Verbindungen erstellen, bearbeiten
und löschen. Weiterhin steht ihm das Typenmanagement zur Verfügung, durch das er
Knoten und Kanten optisch und in Ihrer Funktionalität (verknüpfte Aktionen) kategorisieren
kann. Undo/Redo-Funktionalität und die Möglichkeit, semantische Netze
abzuspeichern, machen nur für den Information Designer Sinn. Während der Eingabe
von Daten muss er sich durch die Informationen bewegen können und hat insbesondere
bei größeren Netzen ein Interesse an den Filtermöglichkeiten der Visualisierung. Somit
hat der Benutzer in dieser Rolle auch alle Möglichkeiten, durch das Netz zu navigieren.
Der Information User will Informationen aus dem Netz gewinnen, wobei er kein
Interesse daran hat, die Daten im Netz zu verändern. Er benötigt insbesondere die Möglichkeit,
das Netz ansprechend darzustellen und durch die Informationen zu navigieren.
Hierbei stehen ihm Komfortfunktionen wie die Filterung bestimmter Typen (enthalten
in der Visualisierung), das Setzen von Bookmarks auf bestimmte Knoten oder das
Ausführen von mit Knoten verbundenen Aktionen (z.B. der Aufruf einer Webseite) zur
Verfügung. Der Information User benötigt außer dem Use Case ein bestehendes Netz
öffnen keine weiteren Funktionen des Persistenzmanagements.
15

16 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
Abbildung 3.1: Übersicht über den Zusammenhang der Use Cases.
Elementare Use Cases sind weiß, Use Cases zum Eingeben von Informationen in ein
Netz sind gelb und orange, Use Cases zum Navigieren durch das Netz sind blau und
türkis. Persistenzmanagement, Knotenmanagement, Verbindungsmanagement, Typenmanagement
und Visualisierung stellen dabei die Kategorien dar unter denen die elementaren
Use Cases zusammengefasst sind.

3.1. USE CASE MODELL 17
3.1.1 Persistenzmanagement
Das Persistenzmangagement fasst Aktionen zusammen, die das Netz als ganzes betreffen,
insbesondere das Speichern des aktuellen Zustandes und das Wiederherstellen
eines gespeicherten Zustandes. Der Speicherort sollte dabei flexibel sein, bespielsweise
sollte eine Wahlmöglichkeit zwischen einem Dateisystem und einer Datenbank zu
Verfügung stehen.
3.1.1.1 Ein bestehendes Netz öffnen
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Ein bestehendes Netz öffnen
Benutzer als Information Designer oder Information User, System
Benutzer: Will den Zustand eines zu einem früheren Zeitpunkt
erstellten Netzes wiederherstellen
System läuft
Hauptablauf
1. Der Benutzer erteilt dem System den Befehl, ein externes Netz
zu öffnen.
2. Das System präsentiert eine Übersicht der vorhandenen Quellen
(Datei, Datenbank...) und der darin vorhandenen Netze.
3. Der Benutzer wählt das gewünschte Netz.
4. Das System zeigt das gewählte Netz in der Visualisierung an
und stellt das zugehörige Typenprofil zu Verfügung.
Alternativer Ablauf
2a. Das System soll nur jeweils ein Netz geöffnet halten und es
ist bereits ein Netz geladen, das noch nicht gespeicherte Änderungen
enthält.
2a1. Das System bietet nach Use Case „Das aktuelle Netz exportieren/speichern“
eine Speichermöglichkeit für das alte Netz.
2a2. Das System präsentiert eine Übersicht der vorhandenen
Quellen (Datei, Datenbank...) und der darin vorhandenen Netze.
2a3. Weiter bei Hauptablauf, Punkt 3
3a. Abbruchwunsch
3a1. Der Benutzer bricht den Vorgang ab
3a2. Das System zeigt das vorher geöffnete Netz wieder an.
3a3. Use Case beendet.
4a. Fehler beim Laden
4a1. Das System stellt einen Fehler beim Laden fest (Datei nicht
gefunden, Formatfehler).
4a2. Das System teilt dem Benutzer den Fehler mit und zeigt
das vorher geöffnete Netz wieder an.
4a3. Use Case beendet.
Hauptablauf
Das neue Netz ist zur Bearbeitung verfügbar.
Alternativer Ablauf
2a.: Das neue Netz ist zur Bearbeitung verfügbar.
3a., 4a.: Der Zustand des alten Netzes ist unverändert.

18 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
3.1.1.2 Ein neues Netz anlegen
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Ein neues Netz anlegen
Benutzer als Information Designer, System
Benutzer: Will mit der Bearbeitung eines neuen Netzes beginnen
System läuft
Hauptablauf
1. Der Benutzer erteilt dem System den Befehl, ein externes Netz
zu erstellen.
2. Das System präsentiert eine Übersicht der vorhandenen Typenprofile.
3. Der Benutzer wählt ein Profil.
4. Das System zeigt die leere Arbeitsfläche an und stellt die Typen
aus dem evtl. geladenen Profil zu Verfügung.
Alternativer Ablauf
2a. Das System soll nur jeweils ein Netz geöffnet halten und es
ist bereits ein Netz geladen, das noch nicht gespeicherte Änderungen
enthält.
2a1. Das System bietet nach Use Case „Das aktuelle Netz exportieren/speichern“
eine Speichermöglichkeit für das alte Netz.
2a2. Das System präsentiert eine Übersicht der vorhandenen Typenprofile.
2a3. Weiter bei Hauptablauf, Punkt 3
3a. Abbruchwunsch
3a1. Der Benutzer bricht den Vorgang ab.
3a2. Das System zeigt das vorher geöffnete Netz wieder an.
3a3. Use Case beendet.
Hauptablauf
Das neue, leere Netz ist zur Bearbeitung verfügbar.
Alternativer Ablauf
2a.: Das neue, leere Netz ist zur Bearbeitung verfügbar.
3a.: Der Zustand des alten Netzes ist unverändert.

3.1. USE CASE MODELL 19
3.1.1.3 Das aktuelle Netz exportieren / speichern
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Das aktuelle Netz exportieren / speichern
Benutzer als Information Designer, System
Benutzer: Will den Zustand des aktuellen Netzes festhalten, um
ihn zu einem späteren Zeitpunkt oder an einem anderen Ort wiederherzustellen.
System läuft, ein Netz ist geöffnet.
Hauptablauf
1. Der Benutzer erteilt dem System den Befehl, das aktuelle Netz
zu speichern.
2. Das System präsentiert eine Übersicht der Zielorte (Datei, Datenbank...),
die zur Verfügung stehen.
3. Der Benutzer wählt den Ort und spezifiziert die exakte Position.
4. Das System führt die Speicherung aus und zeigt wieder das
aktuelle Netz auf der Arbeitsfläche.
Alternativer Ablauf
3a. Abbruchwunsch
3a1. Der Benutzer bricht den Vorgang ab.
3a2. Das System zeigt das aktuelle Netz wieder an.
3a2. Usecase beendet.
4a. Fehler beim Speichern
4a1. Das System stellt einen Fehler beim Speichern fest (Datenträger
voll, Datenbankfehler).
4a2. Das System teilt dem Benutzer den Fehler mit.
4a3. Weiter mit Schritt 2.
Das aktuelle Netz bleibt zur Bearbeitung verfügbar.

20 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
3.1.1.4 Zusammenführen von zwei Netzen
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Zusammenführen von zwei Netzen
Benutzer als Information Designer, System
Benutzer: Will den Inhalt von zwei Netzen in einem kombinieren
System läuft, ein Netz ist geöffnet.
Hauptablauf
1. Der Benutzer erteilt dem System den Befehl, ein zweites Netz
zu integrieren.
2. Das System präsentiert eine Übersicht der vorhandenen Quellen
(Datei, Datenbank...) und der darin vorhandenen Netze.
3. Der Benutzer wählt das zu integrierende Netz.
4. Das System zeigt das kombinierte Netz auf der Arbeitsfläche
an.
Alternativer Ablauf
3a. Abbruchwunsch
3a1. Der Benutzer bricht den Vorgang ab.
3a2. Das System zeigt das vorher geöffnete Netz wieder an.
3a3. Usecase beendet.
4a. Fehler beim Laden
4a1. Das System stellt einen Fehler beim Laden fest (Datei nicht
gefunden, Formatfehler).
4a2. Das System teilt dem Benutzer den Fehler mit und zeigt
das vorher geöffnete Netz wieder an.
4a3. Usecase beendet.
4b. Konflikte beim Zusammenführen
4b1. Das System stellt einen Konflikt bei den Netzinhalten fest
(z.B. identische Knotennamen).
4b2. Das System bietet dem Benutzer die Möglichkeit, die Konflikte
aufzulösen.
4b3. Der Benutzer löst die Konflikte.
Hauptablauf
Das kombinierte Netz ist zur Bearbeitung verfügbar.
Alternativer Ablauf
3a., 4a.: Der Zustand des alten Netzes ist unverändert.
4b.: Das kombinierte Netz ist zur Bearbeitung verfügbar.

3.1. USE CASE MODELL 21
3.1.2 Knotenmanagement
Das Knotenmanagement dient der Verwaltung von allen auf Knoten bezogenen Aktionen.
Knoten im Netz stellen Gedanken, Sachverhalte und Dinge dar. Jeweils zwei
Knoten sind die Endpunkte einer Verbindung, die dann als „Knoten A steht in Relation
R zu Knoten B“ gelesen werden kann.
Der Benutzer soll Knoten anlegen, editieren und löschen können. In den Eigenschaften
eines Knotens sind universelle Daten wie z.B. sein Name, Erstellungsdatum
und sein Typ gespeichert, aber auch visualisierungsabhängige Daten wie seine Position
relativ zu andern Knoten o.ä.
Falls das Löschen eines Knotens dazu führt, dass das Netz in zwei oder mehr disjunkte
Teilgraphen zerfällt, so können Knoten aus anderen Teilnetzen nach wie vor
über die Suchfunktion oder die Knotenübersicht erreicht werden.
3.1.2.1 Einen neuen Knoten in ein Netz einfügen
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Einen neuen Knoten in ein Netz einfügen
Benutzer als Information Designer, System
Benutzer: Will eine Repräsentation eines Gedankens (oder eines
Objekts, ...) haben.
System läuft, ein bearbeitbares Netz steht zur Verfügung
Hauptablauf
1. Der Benutzer wählt einen Knotentyp aus dem Typenprofil.
2. Der Benutzer erteilt dem System den Befehl zum Erstellen
eines Knoten und teilt eine Benennung mit.
3. Das System stellt den neuen Knoten in der Visualierung mit
dem restlichen Netz dar.
Alternativer Ablauf
3b. Fehlschlag
3b1. Das System kann den Knoten nicht erstellen.
3b2. Das System zeigt eine Fehlerinformation an.
3b3. Use Case beendet.
Hauptablauf
Das Netz enthält den neuen Knoten und ist zur Bearbeitung verfügbar,
Undo- und Datumsinformationen sind gespeichert.
Alternativer Ablauf
Der Zustand des Netzes ist unverändert.

22 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
3.1.2.2 Einen Knoten aus einem Netz löschen
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Einen Knoten aus einem Netz löschen
Benutzer als Information Designer, System
Benutzer: Benötigt die vom Knoten repräsentierte Information
nicht mehr.
System läuft, ein bearbeitbares Netz mit mindestens einem Knoten
steht zur Verfügung
Hauptablauf
1. Der Benutzer wählt einen Knoten aus.
2. Der Benutzer erteilt dem System den Befehl zum Löschen des
Knotens.
3. Das System stellt das restliche Netz ohne den gelöschten Knoten
und ohne die ihn berührenden Verbindungen in der Visualisierung
dar.
Alternativer Ablauf
3b. Fehlschlag
3b1. Das System kann den Knoten nicht löschen.
3b2. Das System zeigt eine Fehlerinformation an.
3b3. Usecase beendet.
Hauptablauf
Das Netz ohne den gelöschten Knoten und die ihn berührenden
Verbindungen ist zur Bearbeitung verfügbar, Undo-
Informationen sind verfügbar. Der Knoten ist nicht in den Bookmarks
enthalten.
Alternativer Ablauf
Der Zustand des Netzes ist unverändert.

3.1. USE CASE MODELL 23
3.1.2.3 Eigenschaften eines Knotens bearbeiten
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Eigenschaften eines Knotens bearbeiten
Benutzer als Information Designer, System
Benutzer: Möchte einem Knoten andere Eigenschaften (anderer
Name, Typ etc.) zuordnen.
System läuft, ein bearbeitbares Netz mit mindestens einem Knoten
steht zur Verfügung
Hauptablauf
1. Der Benutzer wählt einen Knoten aus.
2. Der Benutzer erteilt dem System den Befehl zum Bearbeiten
des Knotens.
3. Das System stellt die Eigenschaften des gewählten Knotens
dar.
4. Der Benutzer bearbeitet die Eigenschaften und erteilt den Befehl
zur Übernahme der neuen Eigenschaften.
Alternativer Ablauf
2b. Die Eigenschaften des gewählten Knotens sind ständig sichtbar
2b1. Das System stellt die Eigenschaften des gewählten Knotens
automatisch dar.
2b2. Weiter bei Hauptablauf Punkt 4.
4b. Abbruch
4b1. Der Benutzer bricht das Bearbeiten der Eigenschaften ab.
Hauptablauf
Der gewählte Knoten besitzt nun die neuen Eigenschaften.
Undo-Informationen sind gespeichert.
Alternativer Ablauf
2b.: Der gewählte Knoten besitzt nun die neuen Eigenschaften.
Undo-Informationen sind gespeichert.
4b.: Der gewählte Knoten besitzt die alten Eigenschaften.

24 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
3.1.3 Verbindungsmanagement
Das Verbindungsmanagement kümmert sich um das komplette Handling der Verbindungen.
Verbindungen beschreiben die semantischen Zusammenhänge zwischen Knoten.
Der Benutzer hat die Möglichkeit, die Eigenschaften einer Verbindung zu manipulieren.
Dies betrifft z.B. Zielknoten, Farbe, Art der Relation, usw.
Falls das Löschen einer Verbindung dazu führt, dass das Netz in zwei disjunkte
Teilgraphen zerfällt, so können Knoten aus dem jeweils anderen Teilnetz nach wie vor
über die Suchfunktion oder die Knotenübersicht erreicht werden.
3.1.3.1 Eine Verbindung zwischen zwei Knoten erstellen
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Eine Verbindung zwischen zwei Knoten erstellen
Benutzer als Information Designer, System
Benutzer: Will eine semantische Verknüpfung zwischen zwei
durch Knoten repräsentierte Informationseinheiten erstellen.
System läuft, ein bearbeitbares Netz mit mindestens zwei Knoten
steht zur Verfügung
Hauptablauf
1. Der Benutzer wählt den gewünschten Verbindungstyp aus.
2. Der Benutzer erteilt dem System den Befehl zum Erstellen
einer Verbindung.
3. Der Benutzer wählt den ersten Knoten aus.
4. Der Benutzer wählt den zweiten Knoten aus.
5. Das System stellt die neue Verbindung in der Visualisierung
dar.
Alternativer Ablauf
3a. Abbruch des Vorgangs
3a1. Der Benutzer erteilt dem System den Befehl, den Vorgang
abzubrechen.
3a2. Use Case beendet.
4a. Abbruch des Vorgangs
4a1. Der Benutzer erteilt dem System den Befehl, den Vorgang
abzubrechen.
4a2. Use Case beendet.
Hauptablauf
Das Netz enthält die neu erstellte Verbindung zwischen den gewählten
Knoten und ist zur Bearbeitung verfügbar, Undo- und
Datumsinformationen sind gespeichert.
Alternativer Ablauf
Der Zustand des Netzes ist unverändert.

3.1. USE CASE MODELL 25
3.1.3.2 Eine Verbindung zwischen zwei Knoten auflösen
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Eine Verbindung zwischen zwei Knoten auflösen
Benutzer als Information Designer, System
Benutzer: Will eine bestehende semantische Verknüpfung zwischen
zwei durch Knoten repräsentierte Informationseinheiten
entfernen.
System läuft, ein bearbeitbares Netz mit mindestens einer Verbindung
steht zur Verfügung.
Hauptablauf
1. Der Benutzer wählt die zu löschende Verbindung.
2. Der Benutzer erteilt dem System den Befehl zum Löschen
einer Verbindung.
3. Das System stellt das aktuelle Netz ohne die gewählte Verbindung
neu dar.
Alternativer Ablauf
2a. Abbruch des Vorgangs
2a1. Der Benutzer erteilt dem System den Befehl, den Vorgang
abzubrechen.
Hauptablauf
Das Netz enthält die gelöschte Verbindung nicht mehr und ist zur
Bearbeitung verfügbar, Undo-Informationen sind gespeichert.
Alternativer Ablauf
Der Zustand des Netzes ist unverändert.

26 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
3.1.3.3 Eigenschaften einer Verbindung bearbeiten
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Eigenschaften einer Verbindung bearbeiten
Benutzer als Information Designer, System
Benutzer: Will die Art des Zusammenhangs zwischen zwei Informationseinheiten
ändern.
System läuft, ein bearbeitbares Netz mit mindestens einer Verbindung
steht zur Verfügung.
Hauptablauf
1. Der Benutzer wählt eine Verbindung aus.
2. Der Benutzer erteilt dem System den Befehl zum Bearbeiten
einer Verbindung.
3. Das System stellt die Eigenschaften der gewählten Verbindung
dar.
4. Der Benutzer bearbeitet die Eigenschaften und erteilt den Befehl
zur Übernahme der neuen Eigenschaften.
Alternativer Ablauf
2b. Die Eigenschaften der gewählten Verbindung sind ständig
sichtbar
2b1. Das System stellt die Eigenschaften der gewählten Verbindung
automatisch dar.
2b2. Weiter bei Hauptablauf Punkt 4.
4b. Abbruch
4b1. Der Benutzer bricht das Bearbeiten der Eigenschaften ab.
Hauptablauf
Die gewählte Verbindung besitzt nun die neuen Eigenschaften.
Undo-Informationen sind gespeichert.
Alternativer Ablauf
2b.: Die gewählte Verbindung besitzt nun die neuen Eigenschaften.
Undo-Informationen sind gespeichert.
4b.: Die gewählte Verbindung besitzt die alten Eigenschaften.

3.1. USE CASE MODELL 27
3.1.3.4 Die Zielknoten einer Verbindung bearbeiten
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Die Zielknoten einer Verbindung bearbeiten
Benutzer als Information Designer, System
Benutzer: Möchte die Verbindung auf andere Informationseinheiten
verweisen lassen.
System läuft, ein bearbeitbares Netz mit mindestens einer Verbindung
steht zur Verfügung.
Hauptablauf
1. Der Benutzer wählt eine Verbindung aus.
2. Der Benutzer erteilt dem System den Befehl zum Bearbeiten
der Zielknoten einer Verbindung.
3. Das System stellt die aktuellen Zielknoten dar.
4. Der Benutzer ändert die Zielknoten und erteilt den Befehl zur
ihrer Übernahme.
Alternativer Ablauf
4b. Abbruch
4b1 Der Benutzer bricht das Ändern der Zielknoten ab.
Hauptablauf
Die Verbindung bezieht sich auf die neuen Knoten. Undo-
Informationen sind gespeichert.
Alternativer Ablauf
Die Verbindung bezieht sich auf die alten Zielknoten.

28 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
3.1.4 Visualisierung
In den Bereich der Visualisierung fällt die Darstellung des Netzes auf eine Art, die dem
Benutzer eine einfache Navigation, also das Richten des Blickpunkts auf veschiedene
Knoten bzw. Teile des Netzes und das Traversieren der Verbindungen, ermöglicht.
Das Filtern bestimmter Knoten- oder Verbindungstypen hilft, die Übersichtlichkeit
der Darstellung zu erhöhen.
Die hier dargestellten Aktionen sind nicht für jede Art der Visualisierung sinnvoll.
Bei der dynamischen Selbstanordnung führt beispielsweise die Positionsveränderung
eines einzelnen Knotens automatisch zu Veränderungen in der Darstellung des restlichen
Netzes.
3.1.4.1 Knoten fokussieren
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Knoten fokussieren
Benutzer als Information Designer oder Information User, System
Benutzer: Hat eine relevante Information im Netz entdeckt und
will den entsprechenden Knoten zum Ausgangspunkt einer neu
angeordneten Darstellung machen.
System läuft, ein bearbeitbares Netz mit mindestens einem Knoten
steht zur Verfügung.
Hauptablauf
1. Der Benutzer erteilt dem System den Befehl, den Fokus auf
den gewünschten Knoten zu richten (z.B. auf einen nicht fokussierten
Knoten in der Visualisierung, ein Bookmark etc.).
2. Das System baut eine neue Visualisierung des Netzes auf, die
den gewünschten Knoten in seiner Umgebung zeigt.
3. Das System nimmt den neu fokussierten Knoten in die Liste
der zuletzt besuchten Knoten auf und stellt diese dar.
Hauptablauf
Das Netz ist unverändert.

3.1. USE CASE MODELL 29
3.1.4.2 Navigation durch das Netz
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Navigation durch das Netz
Benutzer als Information Designer oder Information User, System
Benutzer: Möchte die Umgebung des momentan fokussierten
Knoten in einer anderen Art und Weise darstellen (z.B. sich weiter
vom fokussierten Knoten entfernen, um einen besseren Überblick
zu erlangen)
System läuft, ein bearbeitbares Netz mit mindestens einem Knoten
steht zur Verfügung.
Hauptablauf
1. Der Benutzer erteilt dem System den Befehl, die Darstellung
der Umgebung des fokussierten Knotens zu verändern (die zur
Verfügung stehenden Möglichkeiten sind abhängig vom gewählten
Visualisierungsmodus und reichen von einer Rotation des
Blickfeldes bis zu einer Expansion eines entfernten Knotens).
2. Das System stellt die Umgebung des fokussierten Knotens auf
die gewünschte Weise dar.
Hauptablauf
Das Netz ist unverändert.

30 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
3.1.4.3 Visualisierungsmodus verändern
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Visualisierungsmodus verändern
Benutzer als Information Designer oder Information User, System
Benutzer: Möchte die Darstellungsform des Netzes ändern
System läuft, ein bearbeitbares Netz steht zur Verfügung.
Hauptablauf
1. Der Benutzer erteilt dem System den Befehl, für die Darstellung
des Netzes einen anderen Visualisierungsmodus zu benutzen.
2. Das System ersetzt den momentanen Visualisierungsmodus
durch den neu gewählten.
Hauptablauf
Das Netz ist unverändert.

3.1. USE CASE MODELL 31
3.1.4.4 Anwenden eines Filters auf die Visualisierung
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Anwenden eines Filters auf die Visualisierung
Benutzer als Information Designer oder Information User, System
Benutzer: Will für ihn momentan irrelevante Knoten- und Verbindungstypen
ausblenden, um die Übersichtlichkeit zu erhöhen.
System läuft, ein bearbeitbares Netz steht zur Verfügung.
Hauptablauf
1. Der Benutzer erteilt dem System den Befehl, einen bestimmten
Knoten- oder Verbindungstyp auszublenden (bzw. bei Verbindungstypen
nur bis zu einer gewissen Tiefe einzublenden).
2. Das System stellt die Umgebung um den momentan fokussierten
Knoten nach den neuen Vorgaben dar.
Hauptablauf
Das Netz ist unverändert.

32 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
3.1.4.5 Suchen eines Knotens
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Suchen eines Knotens
Benutzer als Information Designer oder Information User, System
Benutzer: kennt den Namen und/oder bestimmte Eigenschaften
eines Knotens. Er möchte diesen Knoten im Netz auffinden.
System läuft, ein bearbeitbares Netz steht zur Verfügung.
Hauptablauf
1. Der Benutzer erteilt dem System den Befehl, einen Knoten zu
suchen.
2. Das Benutzer gibt die bekannten Eigenschaften des gesuchten
Knotens ein.
3. Das System stellt das Resultat der Suche (evtl. direkt in der
Visualisierung) dar.
Alernativer Ablauf
2b. Abbruch der Suche
2b1. Der Benutzer erteilt dem System den Befehl, die Suche abzubrechen.
2b2. Ende des Use Cases
Der Zustand des Netzes ist unverändert.

3.1. USE CASE MODELL 33
3.1.5 Typenmanagement
Die Verwaltung von Typenprofilen sollte unabhängig von den Netzen geschehen, damit
verschiedene Netze auf die gleichen Profile zurückgreifen können.
Wenn ein Benutzer gerade ein Netz bearbeitet und einen zusätzlichen Knoten- oder
Verbindungstyp erstellt, so wird das verwendete Profil um den neuen Typ erweitert.
Dieser neue Typ steht somit auch allen anderen Netzen zur Verfügung, die dieses Profil
verwenden.
Ein Typ klassifiziert einen Knoten oder eine Verbindung. Er definiert sowohl Eigenschaften
wie die Darstellung in der Visualisierung als auch die semantische Bedeutung
des Knotens oder der Verbindung innerhalb des Netzes. In den Verbindungstypen werden
dabei unter anderem die Rollen der verbundenen Knoten festgelegt. Knotentypen
können zusätzlich Informationen über mit dem Knoten verbundene Aktionen enthalten
(z.B. das Öffnen einer Webseite). Die dazu notwendigen Parameter (in diesem Fall die
URL) werden in den Eigenschaften der einzelnen Knoten dieses Typs festgehalten.
3.1.5.1 Neues Typenprofil anlegen
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Neues Typenprofil anlegen
Benutzer als Information Designer, System
Benutzer: Will einen neuen Satz von zusammengehörigen
Knoten- und Verbindungstypen anlegen.
System läuft.
Hauptablauf
1. Der Benutzer erteilt den System den Befehl, ein neues Typenprofil
anzulegen.
2. Der Benutzer teilt dem System den Namen des anzulegenden
Typenprofils mit.
3. Der Benutzer wählt aus, welches Typenprofil er als Vorlage
verwenden möchte bzw. dass er ein leeres Profil erstellen möchte.
4. Das System legt gemäß den Vorgaben ein neues Typenprofil
an.
Alternativer Ablauf
4a. Fehler beim Erzeugen des Typenprofils
4a1. Das System teilt dem Benutzer den Fehler mit
4a2: UseCase beendet
4b. Ein Typenprofil mit dem gewünschten Namen existiert bereits.
4b1. Das System weist den Benutzer auf den Konflikt hin
4b2. Der Benutzer gibt einen neuen Namen für das Typenprofil
ein.
4b3. Der Benutzer bestätigt das Verwerfen des alten Typenprofils.
Hauptablauf
Es existiert ein Typenprofil gemäß den Vorgaben.
Alternativer Ablauf
4a.: Am Ausgangszustand wurde nichts verändert
4b.: Es existiert ein Typenprofil gemäß den Vorgaben.

34 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
3.1.5.2 Bestehendes Typenprofil laden
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Bestehendes Typenprofil laden
Benutzer als Information Designer, System
Benutzer: Will einen einen bestehenden Satz Knoten- und Verbindungstypen
laden.
System läuft, es existiert ein Typenprofil
Hauptablauf
1. Der Benutzer erteilt den System den Befehl, ein Typenprofil
zu laden.
2. Das System präsentiert dem Benutzer eine Auswahl bestehender
Profile.
3. Der Benutzer wählt ein Typenprofil.
4. Das System zeigt das gewählte Profil an.
Alternativer Ablauf
3a. Abbruch
3a1. Der Benutzer bricht den Vorgang ab.
3a2. Use Case beendet.
4a. Fehler beim Laden des Typenprofils
4a1. Das System teilt dem Benutzer den Fehler mit
4a2: Use Case beendet
Hauptablauf
Das gewählte Typenprofil wurde geladen.
Alternativer Ablauf
Der Ausgangszustand bleibt unverändert.

3.1. USE CASE MODELL 35
3.1.5.3 Neuen Typen hinzufügen
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Neuen Typen hinzufügen
Benutzer als Information Designer, System
Benutzer: Will einen neuen Knoten- oder Verbindungstyp in das
aktuelle Profil einfügen
System läuft
Hauptablauf
1. Der Benutzer erteilt den Befehl, einen neuen Knoten- oder
Verbindungstyp zu erstellen.
2. Das System erzeugt einen neuen Typ mit Standardwerten.
3. Der Benutzer editiert die Standardwerte nach seinen Vorstellungen.
4. Das System speichert den neuen Typ automatisch im aktuellen
Typenprofil.
Alternativer Ablauf
3a. Konflikt mit existierenden Typen
3a1. Das System meldet den bestehenden Typenkonflikt.
3a2. Der Benutzer löst den Konflikt auf.
4a. Beim Speichern des veränderten Typenprofils tritt ein Fehler
auf .
4a1. Das System meldet den Fehler.
4a2. Das aktuelle Typenprofil bleibt erhalten (inkl des neu hinzugefügten
Typs).
4a2a. Der Benutzer behebt den Fehler.
4a2b. Das neue Typenprofil wird gespeichert.
Hauptablauf
Das geänderte Typenprofil wird angezeigt und wurde gespeichert.
Alternativer Ablauf
4a.: Falls der Benutzer den Fehler nicht behebt, wird das geänderte
Typenprofil angezeigt. Es wurde jedoch nicht gespeichert.

36 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
3.1.5.4 Typ löschen
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Typ löschen
Benutzer als Information Designer, System
Benutzer: Will einen bestehenden Knoten- oder Verbindungstyp
löschen
System läuft
Hauptablauf
1. Der Benutzer wählt einen Knoten- oder Verbindungstyp
2. Der Benutzer löscht den selektierten Typ
3. Das System speichert automatisch das geänderte Typenprofil
Alternativer Ablauf
3a. Beim Speichern des veränderten Typenprofils tritt ein Fehler
auf
3a1. Das System weist den Benutzer auf den Fehler hin
3a2. Das aktuelle Typenprofil bleibt erhalten (der gelöschte Typ
existiert nicht mehr)
3a2a. Der Benutzer behebt den Fehler
3a2b. Das neue Typenprofil wird gespeichert
Hauptablauf
Das geänderte Typenprofil wird angezeigt und wurde gespeichert.
Alternativer Ablauf
3a.: Falls der Benutzer den Fehler nicht behebt, wird das geänderte
Typenprofil angezeigt. Es wurde jedoch nicht gespeichert.

3.1. USE CASE MODELL 37
3.1.5.5 Typ bearbeiten
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Typ bearbeiten
Benutzer als Information Designer, System
Benutzer: Will einen bestehenden Knoten- oder Verbindungstyp
bearbeiten
System läuft, Typenprofil mit mindestens einem Typ ist geöffnet
Hauptablauf
1. Der Benutzer wählt einen neuen Knoten- oder Verbindungstyp
2. Der Benutzer editiert die Typenwerte nach seinen Vorstellungen
3. Das System speichert den geänderten Typ automatisch im aktuellen
Typenprofil
Alternativer Ablauf
2a. Die vom Benutzer eingegebenen Werte stehen in Konflikt mit
einem bereits existierenden Typen.
2a1. Das System zwingt den Benutzer, den Konflikt aufzulösen
3a. Beim Speichern des veränderten Typenprofils tritt ein Fehler
auf
4a1. Das System weist den Benutzer auf den Fehler hin
4a2. Das aktuelle Typenprofil bleibt erhalten (inkl des bearbeiteten
Typs)
4a2a. Der Benutzer behebt den Fehler
4a2b. Das neue Typenprofil wird gespeichert
Hauptablauf
Das geänderte Typenprofil wird angezeigt und wurde gespeichert.
Alternativer Ablauf
4a.: Falls der Benutzer den Fehler nicht behebt, wird das geänderte
Typenprofil angezeigt. Es wurde jedoch nicht gespeichert.

38 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
3.1.5.6 Einem Netz ein Typenprofil zuordnen
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Einem Netz ein Typenprofil zuordnen
Benutzer als Information Designer, System
Benutzer: Will ein bestehendes Typenprofil mit dem aktuellen
Netz verknüpfen
System läuft, ein bearbeitbares Netz steht zur Verfügung.
Hauptablauf
1. Der Benutzer gibt dem System den Befehl, das aktuelle Netz
mit einem anderen Typenprofil zu verknüpfen.
2. Das System präsentiert eine Auswahl der vorhandenen Typenprofile.
3. Der Benutzer wählt ein Typenprofil.
4. Das System weist den Benutzer darauf hin, dass durch diese
Aktion das alte Typenprofil des aktuellen Netzes von diesem
entkoppelt und alle Typen von Knoten und Verbindungen zurückgesetzt
werden
5. Das System verknüpft das aktuelle Netz mit dem gewählten
Typenprofil und setzt alle Knoten- und Verbindungstypen auf
einen Standardwert zurück.
Alternativer Ablauf
3a. Der Benutzer bricht den Vorgang ab
3a1. UseCase beendet.
4a. Der Benutzer wünscht, das alte und neue Typenprofil zu verschmelzen
4a1. Das System fragt den Benutzer, ob dafür ein neues Profil
angelegt oder eines der beiden bestehenden ersetzt werden soll.
4a2. Das System erzeugt ein neues Typenprofil durch Vereinigung
des gewählten Profils mit dem des aktuellen Netzes.
4a3. UseCase beendet.
4a1a. Der Benutzer bricht den Vorgang ab
4a1a1. Use Case beendet
Hauptablauf
Das aktuelle Netz ist nun mit dem neuen Typenprofil verknüpft.
Alle Knoten und Verbindungen des Netzes wurden auf einen
Standardwert zurückgesetzt.
Alternativer Ablauf
3a. 4a1a.: Ausgangszustand unverändert.
4a.: Es wurde ein neues Typenprofil als Schnittmenge der beiden
existierenden erstellt. Dabei wurde evtl. (je nach Wahl des
Benutzers) eines der alten Profile ersetzt. Alle Knoten- und Verbindungen
behalten ihren Typ bei.

3.1. USE CASE MODELL 39
3.1.6 Sonstiges
Dieser Abschnitt beschreibt alle Use Cases, die sich nicht einer der obigen Kategorien
zuordnen lassen.
3.1.6.1 Eine mit einem Knoten verbundene Aktion ausführen
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Eine mit einem Knoten verbundene Aktion ausführen
Benutzer als Information Designer oder Information User, System
Benutzer: Möchte die mit dem Knoten repräsentierte Information
nutzen.
System läuft, ein bearbeitbares Netz mit mindestens einem Knoten
steht zur Verfügung.
Hauptablauf
1. Der Benutzer erteilt dem System den Befehl, eine Aktion auszuführen,
die sich aus dem Typ eines bestimmten Knotens und
der in diesem Knoten enthaltenen Information ergibt. Eine Aktion
ist beispielsweise das Öffnen eines Dokuments bzw. einer
Webseite oder das Starten eines einfachen, integrierten Texteditors.
2. Das System führt die Aktion aus.
Alternativer Ablauf
2b. Die Aktion kann nicht ausgeführt werden
2b1. Das System informiert den Benutzer darüber, dass die Aktion
nicht ausgeführt werden kann.
Das Netz ist unverändert.

40 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
3.1.6.2 Undo / Redo
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Undo / Redo
Benutzer als Information Designer, System
Der Benutzer möchte eine zuvor ausgeführte Aktion rückgängig
machen bzw. eine rückgängig gemachte Aktion wieder herstellen.
System läuft, ein bearbeitbares Netz steht zur Verfügung, Undobzw.
Redo-Informationen stehen zur Verfügung.
Hauptablauf
1. Der Benutzer erteilt dem System den Befehl, eine Aktion
rückgängig zu machen / wieder herzustellen.
2. Das System führt die Anweisung aus und aktualisiert die Visualisierung.
Hauptablauf
Das Netz befindet sich in dem Zustand vor der rückgängig
gemachten bzw. nach der wieder hergestellten Aktion. Undo-
Informationen sind aktualisiert.

3.1. USE CASE MODELL 41
3.1.6.3 Bookmark auf einen Knoten erstellen
Name
Akteure
Ziele
Vorbedingung
Beschreibung
Nachbedingung
Bookmark auf einen Knoten erstellen
Benutzer als Information Designer oder Information User, System
Der Benutzer möchte einen Knoten für einen schnellen Zugriff
markieren.
System läuft, ein bearbeitbares Netz mit mindestens einem Knoten
steht zur Verfügung.
Hauptablauf
1. Der Benutzer wählt einen Knoten aus.
2. Der Benutzer erteilt dem System den Befehl zum Erstellen
eines Bookmarks.
3. Das System nimmt den gewählten Knoten in die Bookmark-
Liste auf.
Hauptablauf
Das Netz ist unverändert. Die Bookmark-Liste enthält den gewählten
Knoten.

42 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION
3.1.7 Priorisierung der Use Cases
Um die Reihenfolge der Implementierung festzulegen, werden den einzelnen Use Cases
verschiedene Prioritäten zugeordnet. Die geschätzte Schwierigkeit der Use Cases
wird bei der Zeitplanung berücksichtigt.
Name Schwierigkeit Priorität
Ein bestehendes Netz öffnen mittel hoch
Ein neues Netz anlegen niedrig mittel
Das aktuelle Netz exportieren / speichern mittel mittel
Zusammenführen von mehreren Netzen mittel niedrig
Einen neuen Knoten in ein Netz einfügen mittel hoch
Einen Knoten aus einem Netz löschen mittel mittel
Eigenschaften eines Knotens bearbeiten niedrig mittel
Eine Verbindung zwischen zwei Knoten erstellen mittel hoch
Eine Verbindung zwischen zwei Knoten auflösen niedrig mittel
Eigenschaften einer Verbindung bearbeiten niedrig mittel
Die Zielknoten einer Verbindung bearbeiten mittel niedrig
Knoten fokussieren mittel hoch
Navigation durch das Netz hoch hoch
Visualisierungsmodus verändern hoch niedrig
Anwenden eines Filters auf die Visualisierung hoch mittel
Suchen eines Knotens mittel mittel
Neues Typenprofil anlegen niedrig niedrig
Bestehendes Typenprofil laden mittel niedrig
Neue Typen hinzufügen mittel mittel
Typ löschen mittel niedrig
Typ bearbeiten mittel niedrig
Einem Netz ein Typenprofil zuordnen mittel mittel
Eine mit einem Knoten verbundene Aktion ausführen hoch mittel
Undo / Redo hoch mittel
Bookmark auf einen Knoten erstellen niedrig niedrig
3.2 Nicht-funktionale Anforderungen
Dieser Abschnitt beschreibt zusammenfassend die Anforderungen an das Programm,
die nicht direkt mit der Funktionalität im Zusammenhang stehen. Zum Teil wird auf
diese Anforderungen auch an anderen Stellen dieses Pflichtenhefts Bezug genommen.
• Aufgrund der späteren Veröffentlichung des Quelltextes muss während der Entwicklung
auf bestimmte rechtliche Aspekte geachtet werden (wie z.B. die Verwendung
von lizenzrechtlich unbedenklichen externen Komponenten).
• Aus dem gleichen Grund wird darauf Wert gelegt, dass der Quelltext angemessen
kommentiert ist und die Vorgaben des Java Style Guide beachtet werden (siehe
auch Abschnitt 7.3.4), so dass die Einarbeitung anderer Entwickler in unseren
Quelltext erleichtert wird.
• Das Programm soll optisch ansprechend sein und das Navigieren durch das Netz
soll „flüssig von der Hand gehen“, so dass das Stöbern in den Informationen, die

3.2. NICHT-FUNKTIONALE ANFORDERUNGEN 43
das Netz repräsentiert, Spaß macht.
• Bezüglich des Laufzeitverhaltens wird angestrebt, Netze in der Größenordnung
von 10.000 Knoten in akzeptabler Geschwindigkeit bearbeiten zu können.

44 KAPITEL 3. ANFORDERUNGSSPEZIFIKATION

Kapitel 4
Benutzerinterface
Das Benutzerinterface soll wegen des hohen Grades an Interaktivität bei dieser Anwendung
nicht in allen Einzelheiten vorausgeplant werden. Stattdessen soll während der
Implementierungsphase eine ständige Evaluation und gegebenenfalls eine Optimierung
der Bedienabläufe erfolgen. Auf diese Weise können Elemente der Benutzerschnittstelle,
unergonomisch oder nicht intuitiv genug sind, besser erkannt und bei Bedarf im
nächsten Iterationsschritt überarbeitet werden. Abbildung 4.1 zeigt eine Konzeptzeichnung
der geplanten Benutzeroberfläche. Die Interaktionsmöglichkeiten bezüglich der
implementierten Use Cases (siehe Abschnitt 6.3) orientieren sich an dem in diesem
Kapitel beschriebenen Entwurf.
Eine erste Umsetzung dieser Oberfläche in frühen Iterationsstufen ist in Abbildung
4.2 zu sehen. Es ist geplant, dieses Layout in seinen Grundzügen beizubehalten, auch
wenn aus den genannten Gründen spätere Iterationsstufen davon abweichen können.
Das Layout ist aufgeteilt in eine Knotenübersicht, die eine Übersicht über alle im Netz
enthaltenen Knoten anzeigt, ein Eigenschaftspanel, in dem alle bekannten Eigenschaften
des jeweils ausgewählten Elements dargestellt werden, und der eigentlichen Sicht
auf das Netz, die den größten Teil des Bildschirms einnimmt. Die momentan markierten
Knoten sind blau hervorgehoben.
Über die Werkzeugleiste hat der Benutzer ständig Zugriff auf oft benötigte Funktionen,
wie z.B. das Anlegen eines neuen Knotens. Die Verwendung von Dialogboxen
soll so selten wie möglich erfolgen; lediglich das Typen- und Persistenzmanagement
wird noch darauf zurückgreifen müssen. Ansonsten werden sie nur noch für die globalen
Einstellungen des Programms benötigt. Alle anderen änderbaren Eigenschaften
sollen in ständig sichtbaren Panels angezeigt werden.
Im Folgenden soll kurz beschrieben werden, wie sich die einzelnen Use-Case-
Kategorien in den geplanten GUI-Elementen widerspiegeln.
4.1 Persistenzmanagement
Die Befehle zum Laden und Speichern eines Netzes werden wahlweise über Menüpunkte
im „File“-Menü, über eine Schaltfläche in der Toolbar oder aber über einen
Hotkey gegeben. Die eigentliche Auswahl der zu öffnenden bzw. zu speichernden Datei
erfolgt im regulären Dateidialog, der von der Java-Umgebung bereitgestellt wird.
Bei Verwirklichung des als Wunschkriterium klassifizierten Datenbankzugriffs oder
des Zugriffs über Netzwerke werden über einen Dialog die entsprechende Quelle so-
45

46 KAPITEL 4. BENUTZERINTERFACE
Abbildung 4.1: Konzeptzeichnung der Benutzeroberfläche
Abbildung 4.2: Erste Implementierung einer Benutzeroberfläche (erweiterter Prototyp
1)

4.2. KNOTENMANAGEMENT 47
wie evtl. nötige Zugangsdaten abgefragt.
Der Befehl zum Neuanlegen eines Netzes ist über die gleichen Wege erteilbar. Der
Benutzer muss daraufhin auswählen, welches Typenprofil er dem neuen Netz zu Grunde
legen möchte. Dazu wählt er das gewünschte Profil aus einer Dialogbox aus.
Das Zusammenführen mehrerer Netze erfolgt wie das Laden eines Netzes. Anschließend
erscheint ein Dialog, über den eventuell auftretende Konflikte, die z.B.
durch mehrfach vorhandene Typen auftreten können, manuell aufgelöst werden müssen.
4.2 Knotenmanagement
Um einen Knoten in ein Netz einzufügen, muss zunächst der gewünschte Typ des Knotens
über eine Auswahlliste bestimmt werden. Alternativ kann der momentan eingestellte
Typ beibehalten werden, in diesem Fall ist keine besondere Aktion nötig. Anschließend
wird in der Toolbar die Schaltfläche zum Einfügen eines Knotens gewählt.
Da der neue Knoten noch keine Verbindungen zu anderen Knoten besitzt, erscheint er
in der graphischen Liste der zuletzt besuchten Knoten.
Das Löschen eines Knotens erfolgt durch Auswahl des Knotens in der Visualisierung
und dem anschließenden Wählen des Löschbefehls in der Toolbar oder des
Auslösens eines Hotkeys.
Um die Eigenschaften eines Knotens zu bearbeiten, genügt es, den Knoten in der
Visualisierung anzuwählen. Das System stellt dessen Eigenschaften dann automatisch
in einem ständig sichtbaren Bildschirmbereich dar, wo sie wie in einer Tabellenkalkulation
direkt bearbeitet werden können. Die Übernahme der geänderten Daten erfolgt
ebenfalls automatisch.
Ein ausgewählter Knoten wird in der Visualisierung durch einen Rahmen optisch
hervorgehoben.
4.3 Verbindungsmanagement
Um eine Verbindung zu erstellen, wird - ähnlich wie beim Erstellen eines neuen Knotens
- der Verbindungstyp über eine Auswahlliste bestimmt, sofern ein anderer als der
aktuell eingestellte Typ gewünscht wird. Als nächstes muss der erste Zielknoten angewählt
werden, was direkt in der Visualisierung geschieht, d.h. entweder in der eigentlichen
Netzdarstellung oder aber im Bereich der zuletzt besuchten Knoten. Anschließend
wird über die Toolbar oder das Menü der Befehl zum Erstellen einer neuen Verbindung
gegeben. Die Verbindung wird in das Netz eingefügt, sobald der Benutzer den zweiten
Zielknoten auf analoge Weise auswählt.
Zum Löschen wird eine Verbindung zunächst durch Anklicken in der Visualisierung
ausgewählt. Danach muß nur noch über das Menü oder die Toolbar der Befehl
zum Löschen der Verbindung ausgewählt werden.
Das Bearbeiten der Eigenschaften einer Verbindung erfolgt nach dem selben Schema
wie bei einem Knoten, wobei sich natürlich die verfügbaren Eigenschaften und
Bearbeitungsmöglichkeiten unterscheiden. Auch das Ändern der Zielknoten einer Verbindung
erfolgt über das Eigenschaften-Panel, da die Zielknoten normale Eigenschaften
der Verbindung sind.

48 KAPITEL 4. BENUTZERINTERFACE
4.4 Visualisierung
Das Arbeiten in der Visualisierung kann sich je nach gewähltem Visualisierungsmodus
unterscheiden. Hier soll die Benutzerschnittstelle in der 2D-Darstellung beschrieben
werden.
Um einen Knoten zu fokussieren, genügt es, in der Visualisierung einen Doppelklick
auf sein Icon auszuführen. Ist der gewünschte Knoten momentan nicht sichtbar,
so kann er über die Gesamtliste der Knoten ausgewählt werden. Die Visualisierung
wird daraufhin automatisch aktualisiert.
Die Navigation durch das dargestellte Netz erfolgt durch Auswahl der gewünschten
Aktion (Verschieben des Sichtbereiches, Rotation oder Zoom) in einer visualisierungsspezifischen
Unter-Toolbar. Die Aktion selbst wird dann durch Ziehen der Maus bei gedrückter
Maustaste umgesetzt. Der Benutzer kann in Echtzeit die Auswirkungen seiner
Aktionen sehen. Bei der sich selbst anordnenden Visualisierung erfolgt die Navigation
durch direktes Ziehen eines Knotens in die gewünschte Richtung. Die verbundenen
Knoten folgen dem gezogenen Knoten und ordnen sich automatisch an.
Das Umschalten des Visualisierungsmodus erfolgt über das Menü, wo alle dem
System bekannten Modi aufgelistet sind.
Das Aktivieren von Filtern kann zum einen über die Eigenschaften einer Verbindung
geschehen. Der Filter gilt dann für alle Verbindungen des gleichen Typs. Zum
anderen kann man im Typenmanagement die Filter für jeden Verbindungstyp setzen.
Dies ist z.B. dann notwendig, wenn keine Verbindung eines bestimmten Typs mehr
in der Visualisierung angezeigt wird, da man sie dann logischerweise nicht auswählen
kann.
Um einen Knoten zu suchen, kann statt der Gesamtliste der Knoten eine Liste eingeblendet
werden, die nur Knoten mit den gewünschten Eigenschaften enthält. Beim
Umschalten auf die Suchansicht wird das Feld, das normalerweise die Eigenschaften
von Knoten und Verbindungen enthält, geleert, so dass dort die gewünschten Suchbegriffe
eingegeben werden können. Das Betätigen des ebenfalls eingeblendeten Suchen-
Buttons startet die Suche.
4.5 Typenmanagement
Aktionen, die das Typenmanagement betreffen, sind in einer Dialogbox verfügbar, die
über das Hauptmenü aufgerufen werden kann. In dieser Dialogbox kann über separate
Tabs auf die Knoten- und Verbindungstypen zugegriffen werden. Die einzelnen Typen
werden jeweils in einer Liste aufgeführt. Daneben werden der Eigenschaften des
aktuell gewählten Elements angezeigt und können direkt verändert werden.
Daneben ist es möglich, das aktuelle Typenprofil in eine neue Datei zu speichern
oder ein bestehendes Typenprofil für die Verwendung im momentan geöffneten Netz
zu laden.
4.6 Sonstiges
Will der Benutzer eine mit einem Knoten verbundene Aktion durchführen, so muß er
zunächst den gewünschten Knoten durch Anklicken auswählen. Falls mit dem Knoten
eine Aktion verknüpft ist, so wird dies im Eigenschaften-Panel angezeigt. Hier hat der
Benutzer dann die Möglichkeit, die Aktion über eine Schaltfläche zu starten.

4.6. SONSTIGES 49
Im Bearbeiten-Menü findet der Benutzer den Befehl „Undo“, über den die letzten
ausgeführten Aktionen in umgekehrter Reihenfolge rückgängig gemacht werden
können. Analog können über den Befehl „Redo“ rückgängig gemachte Aktionen wiederhergestellt
werden. Alternativ können auch Hotkeys verwendet werden.
Ist ein Knoten markiert, so hat der Benutzer die Möglichkeit, über den Menüeintrag
„Bookmark / Add“ den Knoten in das Bookmark-Menü aufzunehmen. Über die Option
„Manage Bookmarks“ kann der Benutzer diese Liste einsehen und Bookmarks löschen.
Durch das Auswählen eines Bookmarks in diesem Menü wird die Ansicht sofort auf
diesen Knoten fokussiert.

50 KAPITEL 4. BENUTZERINTERFACE

Kapitel 5
Architektur
5.1 Grundlagen
Das Projekt basiert auf Java 1.4 oder höher. Hinsichtlich der bereits erwähnten Platformunabhängigkeit
wird Kompatibilität mit MS Windows 2000/XP, Apple Mac OS X
und Linux/X11 vorausgesetzt. Als GUI-Toolkit wird Swing/JFC verwendet.
Zur besseren Darstellung einzelner Menübefehle in der GUI wird zumindest in
Teilen das „Java Look And Feel Graphics Repository“ 1 verwendet. Diese Grafiken
garantieren eine konsistente Darstellung nach den Java look and feel design guidelines.
Das Repository ist eine frei erhältliche Erweiterung der Firma Sun Microsystems zur
verwendeten Programmiersprache Java.
5.2 Bibliotheken
Zur Begrenzung des Programmieraufwands und zur Ausnutzung bereits erprobter Programmteile
sollen verschiedene Bibliotheken eingesetzt werden. Aufgrund der späteren
Veröffentlichung des Projekts als Open-Source verwendet ByteMe dabei nur Bibliotheken,
deren Lizenzen die Verwendbarkeit des Projektes in keiner signifikanten
Weise beschneiden.
Zur Repräsentation des Netzes verwenden wir die TM4J-Bibliothek (z.Zt. in der
Version 0.9). Diese basiert auf dem ISO-Topicmap-Standard (siehe Anhang). Um nicht
zu stark abhängig von den Formalitäten des Standards und der Bibliothek selbst zu
sein, erstellen wir eine Abstraktionsschicht zwischen der Bibliothek und unserer Anwendung,
die den Zusammenhang zwischen einer Topicmap (siehe Anhang A) und
unserem „Netz“ herstellt.
TM4J bietet neben der Topicmap-Repräsentation auch Dienste zum Im- und Exportieren
von ISO-Topicmaps im XTM-Format, so dass wir dieses Format zur Serialisierung
verwenden können. Zudem besteht so die Möglichkeit, bei zukünftigen Erweiterung
des Programms die Topicmap in einer externen Datenbank abzulegen.
Auch für die Visualisierung werden wir Bibliotheken verwenden. Zu diesem Zeitpunkt
steht bereits die Verwendung von Teilen der Graphendarstellungs-Bibliothek
„GraphLayout“ 2 (aktuelle Version 1.21) fest, die die dynamische Anordnung der Knoten
über Abstoßungs- und Anziehungskräfte bereitstellt.
1 http://java.sun.com/developer/techDocs/hi/repository/
2 http://www.touchgraph.com/
51

52 KAPITEL 5. ARCHITEKTUR
Daneben benutzen wir das Open-Source-Werkzeug Log4J 3 , um applikationsweit
Log-Ausgaben zu erstellen. Es ist eine weit verbreitete Logging-Bibliothek und zählt
heute zum De-facto-Standard für Logging. Log4J ist zur Laufzeit konfigurierbar und
beeinflusst die Performance der Applikation nur minimal. Es bietet die Möglichkeit,
auf alle bekannten Ausgabekanäle zu loggen (u.a. Konsole, Textdatei, Mail usw.). Die
Geschwindigkeit und Flexibilität von Log4J erlaubt es, die Log-Anweisungen im Code
zu belassen und sie zur Laufzeit zu aktivieren, ohne Codeänderungen durchzuführen.
3 http://logging.apache.org/log4j/docs/

Kapitel 6
Entwicklungsprozess
6.1 Interne Organisation
Die Gruppe ByteMe besteht aus sechs gleichberechtigten Mitgliedern. Es gibt keinen
expliziten Projektleiter; lediglich bestimmte dauerhafte Aufgaben werden längerfristig
einer bestimmten Person zugeordnet:
Qualitätssicherung
Außenminister
Homepage
Sinisa Djukanovic
Matthias Orgler
Kai Stroh
Am Anfang jeder Teamsitzung wird ein neuer Protokollant bestimmt. Der Protokollant
nimmt auch die Rolle eines Moderators wahr, indem er, sofern nötig, die Diskussion
leitet und darauf achtet, dass Diskussionen nicht abschweifen. Die Protokolle
werden in einen für alle Teammitglieder zugänglichen Bereich auf unserer Homepage
abgelegt, so dass nachträgliches Informieren über die Beschlüsse einer Teamsitzung
jederzeit möglich ist.
Die Tagesordnung für die folgende Sitzung wird am Ende jeder Sitzung im Wiki
(siehe Glossar) geschrieben und kann dann von jedem Teammitglied eingesehen und
bei Bedarf ergänzt werden.
6.2 Prozessstruktur
Im Zuge der heutigen Vorstellungen von Software, besonders unter qualitativen Gesichtspunkten
als auch in finanzieller und zeitlicher Hinsicht, ist es unerläßlich, den
Entwicklungsprozess diesen Gesichtspunkten anzupassen bzw. daran auszurichten. Es
gibt verschiedene Modelle, die den Entwicklungsprozess analysieren und versuchen,
eine Lösung anzubieten. Die Gruppe ByteMe hat sich entschlossen, ihren Arbeitsprozess
an den folgenden Modellen auszurichten: dem Rational Unified Process und Extreme
Programming von Kent Beck (dargestellt in [3]). Dabei sollen diese Prozessabläufe
nicht strikt verfolgt werden, sondern vielmehr als Leitfaden und Kontrollinstrument für
einen erfolgreichen Entwicklungsprozess dienen.
53

54 KAPITEL 6. ENTWICKLUNGSPROZESS
6.2.1 Rational Unified Process
Der Rational Unified Process (RUP) ist in vier Phasen eingeteilt. Diese Phasen geben
Auskunft über den Reifegrad des Projektes und jede schliesst mit einem sogenannten
Meilenstein ab. Sie erlauben eine Organisation des Projektes entsprechend des zeitlichen
Ablaufs.
6.2.1.1 Einführungsphase
Die Einführungs- oder auch Vorbereitungsphase (engl. inception phase) bildet sozusagen
den Einstiegspunkt in ein neues Projekt. Es werden die Hauptanforderungen an das
zu entwickelnde System erarbeitet. Das Ziel ist festzustellen, ob das Produkt realisiert
werden kann oder nicht.
Hierfür haben wir die ersten Use Cases entwickelt und in Kurzform („casual format“)
festgehalten, um einen ersten Eindruck von der Funktionalität des Systems zu
bekommen. Darüberhinaus wurden Technologien wie z.B. Bibliotheken und Entwicklungswerkzeuge
bezüglich ihrer Eignung für die Verwendung in unserem Projekt evaluiert.
Damit verbunden war auch eine erste Risikoabschätzung für die bereits hier
erkennbaren Risiken (siehe auch Abschnitt 7.6).
6.2.1.2 Entwurfsphase
Die Aufgabe der Entwurfsphase (engl. elaboration phase) ist quasi die Vorbereitung
für die Konstruktionsphase. Wir haben das Use-Case-Modell vervollständigt und die
bereits existierenden Use Cases in das „fully dressed format“ überführt. Zusätzlich
wurde eine Priorisierung und eine Einteilung der Use Cases nach ihrer Schwierigkeit
vorgenommen.
Nach der Evaluierung von Werkzeugen und Technologien in der Einführungsphase
erfolgte hier die Festlegung auf diejenigen, die geeignet erschienen. Mit Hilfe des
UML-Tools Together haben wir ein Klassenmodell erstellt, auf dessen Basis ein erster
lauffähiger Prototyp entwickelt wurde. Dieser ist die Basis für die weitere Systementwicklung.
6.2.1.3 Konstruktionsphase
Die Hauptaufgabe der Konstruktionsphase (engl. construction phase) ist die Implementierung
und das Testen der Systemkomponenten. Basis für die Entwicklung ist der in
der Entwurfsphase entstandene Architektur-Prototyp. Die grundlegende Analyse des
Systems ist beendet, jedoch können noch während der Konstruktionsphase Veränderungen
im Design vorgenommen werden, um flexibel auf geänderte Umstände (z.B.
zusätzliche Anregungen des Auftraggebers) reagieren zu können. Daher wollen wir in
dieser Phase vor allem auf verschiedene Prinzipien des XP zurückgreifen, die in Abschnitt
6.2.2 näher betrachtet werden.
6.2.1.4 Übergangsphase
In dieser Phase (engl. transition phase) erfolgt der Übergang des Systems aus der Entwicklungsumgebung
zum Kunden. Diese Phase ist bei uns von geringerer Bedeutung,
da der Auftraggeber schon während der Konstruktionsphase Zugriff auf Vorversionen
des Systems hat. Daher sollten hier folglich keine Schwierigkeiten auftreten.

6.2. PROZESSSTRUKTUR 55
6.2.2 Extreme Programming
Diese von Kent Beck entwickelte Methode stellt mit ihren Regeln und Bedingungen
einen Rahmen für die Durchführung von Software-Projekten zur Verfügung. Durch die
relativ kleine Anzahl von Gruppenmitgliedern bietet sich der Einsatz von Extreme Programming
an und verspricht einen erfolgreichen und schnelleren Implementierungs-
Prozess.
XP verzichtet auf eine Reihe von Elementen der klassischen Softwareentwicklung,
um so eine schnellere und effizientere Kodierung zu erlauben. Die dabei entstehenden
Defizite werden durch stärkere Gewichtung anderer Konzepte (insbesondere der
Testverfahren) zu kompensieren versucht.
Weil der Programmcode das ultimative Ziel einer Softwareentwicklung ist, fokussiert
XP von Anfang an genau auf diesen Code. Im Gegensatz dazu wird Dokumentation
als aufwändiger Ballast betrachtet. Eine Dokumentation ist aufwändig zu erstellen
und sehr oft viel fehlerhafter als der Code, weil sie nicht automatisch analysier- und
testbar ist. Folgerichtig wird in XP-Projekten kaum externe Dokumentation erstellt. Im
Ausgleich dafür wird Wert auf eine gute Kommentierung des Quellcodes durch Coding
Standards und eine umfangreiche Test-Sammlung gelegt.
Dies alles basiert auf den folgenden grundlegenden Prinzipien eines XP-Prozesses:
Kommunikation: Permanente und intensive Kommunikation der Entwickler untereinander
sowie mit dem Kunden erlaubt schnellstmögliches Feedback sicherzustellen,
unnötige Funktionalität zu verhindern, entstehende Probleme so schnell
wie möglich zu lösen und das Problem der fehlenden Dokumentation zu mildern.
Dies wollen wir durch regelmäßige Teamsitzungen und die Verwendung
von modernen Kommunikationsmitteln (Wiki, ICQ etc.) erreichen.
Einfachheit: Die Software soll so einfach wie möglich gehalten werden, keine Vorbereitung
möglicher zukünftiger Erweiterungen, keine redundante oder unnötige
Funktionalität und keine redundanten Strukturen sind geduldet. Dadurch bleibt
das System einfach und wartbar. Wir weichen von diesem Prinzip des XP insofern
ab, als dass wir die Erweiterbarkeit des Programms sicherstellen wollen,
auch wenn dies zu Lasten der Einfachheit gehen kann.
Feedback: Evolutionäre Entwicklung des Systems in möglichst kleinen Releases und
eine permanente Verfügbarkeit des Kunden erlaubt schnelles Feedback und dadurch
flexible Steuerung des Projektfortschritts. Dem wollen wir durch die Einbeziehung
des Auftraggebers und unsere geplanten Intervalle zwischen den einzelnen
Iterationen Rechnung tragen (siehe hierzu auch Abschnitt 6.5).
Eigenverantwortung: Im XP sind die Entwickler gehalten, eigenverantwortlich zu
handeln. Dies impliziert, in Absprache mit dem Kunden Funktionalitäten anzupassen
und Pläne zu überdenken.
Zu diesen Prinzipien gehören auch die folgenden Entwicklungspraktiken, die in unserer
Gruppe zur Anwendung kommen.
6.2.2.1 Pair-Programming
In der Coding-Phase werden wir das sogenannte Pair-Programming benutzen. Hierbei
sitzen während des Schreibens von Quellcode jeweils zwei Leute an einem Rechner.
Der momentane Benutzer von Tastatur und Maus konzentriert sich auf eine bestmögliche
Implementierung des aktuellen Code-Abschnitts, während der andere eher

56 KAPITEL 6. ENTWICKLUNGSPROZESS
hinsichtlich des aktuellen Lösungsansatzes strategisch vorausdenkt und versucht, Auswirkungen
der aktuellen Implementierung auf das Gesamtsystem abzuschätzen. Die
Rollen können dabei jederzeit getauscht werden.
Die Gruppe ist in drei Kleingruppen gegliedert, die sich zwar nicht, wie in XP
vorgesehen, regelmäßig neu bilden, da dies aus organisatorischen Gründen (Zeit- und
Wohnsituation) nicht praktikabel ist. Jedoch wird eine Umgruppierung zu einem späteren
Zeitpunkt des Projekts nicht ausgeschlossen.
Model
Visualisierung
Controller
Mario Vekic, Sinisa Djukanovic
Kai Stroh, Sebastian Eifert
Matthias Orgler, Carole Urvoy
Grundlegend zu all diesen Punkten gehört auch die enge Zusammenarbeit zwischen
Auftraggeber und -nehmer, um den Fortschritt des Projektes in die richtige Richtung
garantieren zu können. Es wäre wünschenswert, während der Programmierphase kontinuierlich
Rückmeldungen vom Auftraggeber zu erhalten und für die jeweils nächste
Iteration zu berücksichtigen.
6.2.2.2 Refactoring
Software, die benutzt wird, muss laufend den sich ändernden Anforderungen angepasst
werden, d.h. sie muss gewartet werden. Leider führt Software-Wartung in der Regel
zur Degeneration der Struktur der Software. Das macht weitere Änderungen immer
schwieriger, bis schließlich nur noch eine Neuimplementierung sinnvoll ist.
Eine Möglichkeit, dieser „natürlichen“ Degeneration der Software-Struktur entgegenzuwirken,
ist die kontinuierliche Software-Restrukturierung oder „Refactoring“,
die dafür sorgt, dass die Software jederzeit verständlich und änderbar bleibt.
Das Refactoring umfasst also konstruktive Maßnahmen, die dazu dienen, eine vorhandene
Software oder Teile davon verständlicher und leichter änderbar zu machen,
ohne dabei das beobachtbare Verhalten zu verändern.
Durch die Wahl von Eclipse als Entwicklungsumgebung fällt die Anwendung solcher
Maßnahmen relativ leicht, da dort bereits weitreichende Unterstützungsfunktionen
zur Durchführung verschiedener Refactoring-Prozesse vorhanden sind.
6.3 Iterationsplan
Wie im Abschnitt zur Prozessstruktur (s. 6.2) bereits erwähnt, werden wir das Projekt
nicht „in einem Rutsch“ implementieren, sondern mehrere, kleinere Iterationen durchführen.
Dies hat mehrere Vorteile. Zunächst einmal sind die Teilaufgaben, die in jeder
Iteration zu lösen sind, weniger komplex und damit besser überschaubar als die Gesamtaufgabe.
Weiterhin besteht bei einem iterativen Vorgehen die Möglichkeit, frühzeitig
(d.h. spätestens nach dem ersten Release) Feedback vom Auftraggeber zu erhalten
und damit eventuelle Unklarheiten aufzuklären. Schließlich versucht man, durch mehrere
Meilensteine das Projektrisiko zu senken. Dies ist darin begründet, dass die riskantesten
und schwierigsten Aufgaben möglichst früh im Projekt implementiert werden,
d.h. wenn noch viel Zeit für möglicherweise nötige Umstrukturierungen bleibt, während
in späteren Iterationen nur noch vergleichsweise einfache und damit sicherer zu
bewältigende Aufgaben übrig bleiben. Der aktuelle Iterationsplan wird stets in unserem
Wiki festgehalten.

6.3. ITERATIONSPLAN 57
Der Funktionsumfang der einzelnen Milestones läßt sich bis zu einem gewissen
Grad aus der Prioritätenliste der Use Cases ableiten:
Milestone 0
• Grundstruktur des Programmaufbaus
• Anbindung an die TM4J-Bibliothek
• Use Cases:
– Ein bestehendes Netz öffnen (aus einer Datei)
– Knoten fokussieren in einer einfachen textbasierten Baumansicht
Milestone 1
• Grafische Visualisierung
• Use Cases:
– Das aktuelle Netz exportieren / speichern
– Ein neues Netz anlegen
– Einen neuen Knoten in ein Netz einfügen
– Eine Verbindung zwischen zwei Knoten auflösen
– Einen Knoten aus einem Netz löschen
– Eine Verbindung zwischen zwei Knoten erstellen
– Navigation durch das Netz
Milestone 2
• Fertigstellung des Benutzerinterfaces
• Use Cases:
– Eigenschaften eines Knotens bearbeiten
– Eigenschaften einer Verbindung bearbeiten
– Die Zielknoten einer Verbindung bearbeiten
– Anwenden eines Filters auf die Visualisierung
– Suchen eines Knotens
– Neue Typen hinzufügen
– Einem Netz ein Typenprofil zuordnen
– Eine mit einem Knoten verbundene Aktion ausführen
– Undo / Redo

58 KAPITEL 6. ENTWICKLUNGSPROZESS
Final Release
• Use Cases:
– Zusammenführen von mehreren Netzen
– Visualisierungsmodus verändern
– Neues Typenprofil anlegen
– Bestehendes Typenprofil laden
– Typ löschen
– Typ bearbeiten
– Bookmark auf einen Knoten erstellen
In jeder Iteration wird soweit wie möglich das Feedback des Auftraggebers mit einbezogen.
Mit jeder dazwischen liegenden Iteration werden Teile der für den nächsten
Meilenstein geplanten Ausbaustufe des Programms hinzugefügt. Die Reihenfolge der
Implementierung wird dabei flexibel und nach Bedarf festgelegt. Auch kann die Umsetzung
der in vorherigen Stufen integrierten Use Cases in späteren Iteration noch angepasst
oder erweitert werden, insbesondere was Aspekte der Benutzerfreundlichkeit
angeht.
6.4 Prototypen
Um sicherzustellen, dass das Projekt die vom Auftraggeber gewünschte Richtung beibehält,
werden regelmäßig abgeschlossene Iterationen als „Prototypen“ zum Auftraggeber
gesandt.
Durch dieses Prototyping werden zum einen Missverständnisse zwischen Auftraggeber
und Auftragnehmer frühzeitig aufgedeckt. Auch kann auf diese Weise auf übersehene
essentielle Funktionalität hingewiesen werden. Der Auftraggeber ist zudem
ständig über den aktuellen Entwicklungsstand informiert.
Mit Hilfe dieser Entwicklungsmethode können bestimmte Qualitätsmerkmale bezüglich
ihrer Umsetzung kontrolliert werden. Hierbei sei besonders auf die Benutzerfreundlichkeit,
den Nutzwert und die Zuverlässigkeit durch den frühzeitigen Einsatz
hingewiesen.
Des weiteren ist Prototyping eines der zentralen Wesensmerkmale eines iterativen
Programmiermodells und erleichtert durch die Konzentration auf Teile der Gesamtaufgabe
die schrittweise Annäherung an das endgültige Produkt.
6.5 Zeitplanung
In diesem Abschnitt wird der Zeitplan für das Projekt wiedergegeben. Oberstes Ziel
unserer Planung ist die Einhaltung der vorgegebenen Termine. Daneben soll erreicht
werden, dass die anfallenden Aufgaben möglichst gerecht (vom Zeitaufwand und vom
Anspruch) auf die verschiedenen Teammitglieder verteilt werden.
Unsere Zeitplanung ergibt sich aus einem fest vorgebenden Gerüst externer Termine,
sowie der von uns gesetzten Meilensteine.

6.6. VERWENDETE SOFTWARE UND TOOLS 59
Abbildung 6.1: Zeitliche Fixierung der Meilensteine
Datum
Ziel/Ereignis
7. November 2003 Beginn des Projektes
7. Januar 2004 1. Steering Committee
21. Dezember 2003 Pflichtenheft 0.1
Ende Januar 2004 Prototyp - Milestone 0
4. Februar 2004 2. Steering Committee
Ende Februar 2004 Abgabe Pflichtenheft 1.0
Anfang März 2004 1. Review
Anfang April 2004 Milestone 1
Mitte Mai 2004 3. Steering Committee
Anfang Juli 2004 2. Review
Mitte Juni 2004 Milestone 2
Anfang August 2004 Fertigstellung des Produktes
Anfang Oktober 2004 Abgabe
Mitte Oktober 2004 Abschlußreview
Anfang November 2004 SE - Messe
Der verbindliche Abgabetermin ist Anfang Oktober 2004. Die Diskrepanz zu dem
oben erwähnten, internen Termin der Fertigstellung Anfang August 2004 kommt auf
Grund interner Pufferzeiten zustande.
Abbildung 6.1 veranschaulicht die geplanten Zeiträume der verschiedenen Projektphasen.
6.6 Verwendete Software und Tools
Die Gruppe ByteMe setzt zur Realisierung dieses Projektes für die unterschiedlichen
Aufgaben nachfolgend aufgeführte Software ein.
6.6.1 Werkzeuge zur Dokumentation
Zur Erstellung der Dokumentation und der Protokolle haben wir uns für den Einsatz
verschiedener, für ihren Zweck jeweils am besten geeigneter Werkzeuge entschieden.

60 KAPITEL 6. ENTWICKLUNGSPROZESS
Im einzelnen sind dies:
• verschiedene einfache Texteditoren zur Erstellung des HTML-Codes für die Homepage,
• OpenOffice 1.1.0 zur Erstellung der Protokolle und zum PDF-Export,
• Together 6.0 für das Design eines Klassenmodells,
• L Y X 1.3.2 und L A TEX 2.0.2 für das Pflichtenheft,
• OpenOffice 1.1.0, um Folien für Steering Committees und Reviews zu erzeugen.
6.6.2 Werkzeuge zur Verwaltung und Kommunikation
Zur Kommunikation außerhalb der Teamsitzungen und zur Verwaltung und Verteilung
der erstellten Dokumente verwenden wir
• verschiedene E-Mail-Programme,
• verschiedene HTML-Browser,
• verschiedene ICQ-kompatible Instant-Messaging-Programme,
• WinSCP, um Dateien in den Downloadbereich unserer Homepage zu stellen,
• das MoinMoin Wiki 1 zur Projektplanung und -koordination,
• ein selbst geschriebenes PHP-Skript zur Zeiterfassung.
6.6.3 Werkzeuge zur Entwicklung
Die Entscheidung bezüglich der Wahl der Entwicklungswerkzeuge fiel auf
• CVS zur Versionsverwaltung zur Aufnahme von Quellcode, Testklassen und
Beispieldateien,
• Eclipse 3.0 zur Erstellung des Java Quellcodes,
• JUnit als Test-Framework (in Eclipse).
1 http://moin.sourceforge.net/

Kapitel 7
Qualitätssicherung
7.1 Einleitung
Die Qualitätssicherung spielt eine zentrale Rolle im Prozess der Softwareentwicklung
und beginnt bereits in der Planungsphase eines Projektes. Dieser Qualitätsbegriff bezieht
sich jedoch nicht nur auf den erstellten Code, sondern auch auf die zugehörigen
Dokumente wie Pflichtenheft, Code-Dokumentation, Benutzer- und Entwicklerhandbuch.
In diesem Kapitel werden zunächst die wichtigsten Qualitätsmerkmale auf Basis
der DIN ISO 9126 beschrieben und ggf. deren Bedeutung für das Projekt erläutert.
Anschließend soll der Qualitätssicherungsplan vorgestellt werden, welcher in die praktische
Umsetzung während der Projektarbeit sowie die Testfallübersicht untergliedert
ist.
7.2 Qualitätsmerkmale
Allgemein formuliert ist Qualität die Gesamtheit von Eigenschaften und Methoden
eines Produktes oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener
Erfordernisse bezieht. Im Folgenden werden Merkmale der Qualität nach DIN ISO
9126 und deren Bedeutung im Projekt dargestellt.
7.2.1 Änderbarkeit/Analysierbarkeit
Das Design des Softwaresystems in seinen unterschiedlichen Komponenten und Schnittstellen
muss transparent, einheitlich und gut dokumentiert sein. Diese Attribute sind
eng miteinander verknüpft: Die eingesetzten Klassen sollten minimale Abhängigkeiten
untereinander besitzen und die Schnittstellen so ausgelegt sein, dass Änderungen
in der Implementierung keine Auswirkungen nach außen haben. Ein einheitliches System
in der Namensgebung von Variablen und Formatierung der Quellcodes erleichtert
ebenfalls die Wartung und Weiterentwicklung der Software. Der wichtigste Aspekt ist
eine gute und vollständige Dokumentation des Codes. Nur wenn diese Eigenschaften
erfüllt sind, kann das Produkt mit vertretbarem Aufwand gewartet und ausgebaut werden.
61

62 KAPITEL 7. QUALITÄTSSICHERUNG
7.2.2 Stabilität/Zuverlässigkeit
Ein grundlegendes Merkmal der Qualität ist die Zuverlässigkeit des entwickelten Softwaresystems.
Das betrifft in erster Linie die Zahl der (kritischen) Programmfehler, aber
auch die Behandlung von Ausnahmesituationen wie Hardwarefehler, Ausfälle und andere.
Da es in diesem Projekt zentral um Datenerfassung und -verwaltung geht, hat
die Konsistenz der zu speichernden Informationen einen hohen Stellenwert. Ein weiterer
wichtiger Punkt in diesem Zusammenhang ist die Toleranz gegenüber fehlerhaften
Eingaben des Anwenders. Der Datenbestand darf dadurch nicht gefährdet werden.
7.2.3 Übertragbarkeit
Allgemein wird dieser Begriff mit Plattformunabhängigkeit assoziiert, das Softwaresystem
soll im Idealfall in unterschiedlichsten Rechner- und Softwareumgebungen bei
minimalem Anpassungsaufwand einsetzbar sein. Hier wird vor allem Wert auf uneingeschränkte
Kompatibilität zu Linux- und Mac OS-Systemen gelegt.
7.2.4 Konfigurierbarkeit
Hinter diesem Begriff steht die Frage, inwieweit der Anwender das Softwaresystem
seinen Bedürfnissen anpassen kann, ohne den Quellcode zu modifizieren. Dieses Projekt
soll gerade in dieser Hinsicht dem Benutzer die besten Möglichkeiten geben, Daten
verschiedenster Art zu erfassen und zu verwalten.
7.2.5 Nutzwert
Das Ziel jedes Softwareprojekts ist die Erstellung eines Systems, welches genau die
Funktionalität besitzt, die sich der Auftraggeber vorgestellt hat. Die elementaren Voraussetzungen
dafür sind
• ein Pflichtenheft, welches die Anforderungen an die Software möglichst eindeutig
definiert,
• regelmäßige Rücksprachen mit dem Auftraggeber,
• Qualitätssicherung bei der Erstellung des Programmcodes.
7.2.6 Konformität
Dieser Begriff ist eng mit dem des Nutzwertes und der Analysierbarkeit verknüpft. Es
ist wichtig, dass die tatsächliche Implementierung des Softwaresystems den Anforderungen
des Pflichtenheftes genügt.
7.2.7 Anwendbarkeit/Benutzerfreundlichkeit
Diese Attribute zielen vor allem auf eine intuitive Benutzeroberfläche ab: Das System
soll sich so verhalten, wie es der Anwender erwartet. Der Benutzer soll in der Lage
sein, das Softwaresystem nach möglichst kurzer Einarbeitungszeit nutzen zu können.
Ungültige Eingaben müssen so weit wie möglich abgefangen werden und dürfen vor
allem in unserem Projekt nicht die verwalteten Datenbestände gefährden. Zur Benutzerfreundlichkeit
gehören auch geringe Antwortzeiten der Software.

7.3. UMSETZUNG IM PROJEKT 63
7.2.8 Effizienz
Das Softwaresystem soll so effizient wie möglich gestaltet werden. Dieses Attribut
steht jedoch oft im Widerspruch zur Toleranz gegenüber Ausnahmesituationen und ungültigen
Eingaben durch den Benutzer. Da wir Plattformunabhängigkeit garantieren
wollen und daher Java als Programmiersprache verwenden, muss bei Überlegungen
bezüglich der Performance stets in Betracht gezogen werden, dass das Programm nur
innerhalb einer Virtual Machine laufen kann. Hier ist also in der Regel mit einem Verlust
an Effizienz gegenüber einer nativen Implementierung zu rechnen. Grundsätzlich
sollte beim Design darauf geachtet werden, die jeweils günstigsten Methoden für den
konkreten Anwendungsfall zu finden, der allen genannten Punkten gerecht wird.
7.2.9 Prozessqualität
Dieser Begriff umfasst folgende Attribute, die speziell die Organisation der Projektgruppe
betreffen
• Prüfbarkeit der Prozessabläufe,
• Nachvollziehbarkeit,
• Personenunabhängigkeit.
Prüfbarkeit bedeutet in diesem Zusammenhang, dass das Vorhandensein der wichtigsten
Prinzipien des angewandten Entwicklungsprozesses im Rahmen eines Projektes
von außen sichtbar sein sollte. Darunter fallen etwa Release-Planung und Qualitätssicherung,
die in diesem Pflichtenheft beschrieben werden.
Diese Prozesse müssen auch im Rückblick nachvollziehbar sein, d.h. es muss ersichtlich
sein, auf welche Weise ein bestimmtes Ergebnis zustande gekommen ist. Diesem
Punkt wird unter anderem durch den Einsatz des CVS-Tools Rechnung getragen,
durch das alle Versionen eines damit verwalteten Dokuments oder Codestücks verfügbar
sind. Desweiteren werden sämtliche Entscheidungen der Gruppe protokolliert und
können somit auch zu späteren Zeitpunkten rekonstruiert werden.
Teile des Entwicklungsprozesses dürfen nicht an eine einzelne Person gebunden
sein. Um dies sicherzustellen, entwickeln wir einerseits kaum in Einzelarbeit, sondern
hauptsächlich in Zweier-Teams. Darüberhinaus stellen wir durch die Dokumentation
des Quellcodes und den ständigen Informationsaustausch über die Teamsitzungen und
das Wiki sicher, dass alle Teammitglieder stets einen umfassenden Überblick über die
Arbeit jeder Kleingruppe haben.
7.3 Umsetzung im Projekt
7.3.1 Einleitung
Die Sicherung der oben aufgeführten Qualitätskriterien im Projekt wird durch die folgenden
Verfahrensweisen unterstützt:
• Einhaltung von Richtlinien zur Erhaltung der Transparenz und Wartbarkeit des
Produkts,
• Anwendung von Tests zur Minimierung von Programmfehlern,

64 KAPITEL 7. QUALITÄTSSICHERUNG
• Hinreichende Kommunikation intern und extern zur Bildung einer gemeinsamen
Basis und zur Vermeidung von Missverständnissen.
In den folgenden Unterkapiteln werden diese Verfahren detailliert erläutert.
7.3.2 Richtlinien
Ziel von einheitlichen Konventionen bei der Durchführung wichtiger Prozesse im Projekt
ist die Gewährleistung von Transparenz und Wartbarkeit des Produktes. Dadurch
wird sowohl die Zusammenarbeit in der Gruppe unterstützt, als auch die spätere Weiterentwicklung
durch den Auftraggeber und ggf. die Open-Source-Gemeinde erleichtert.
7.3.3 Dokumentation von Änderungen
Jede Modifikation eines Dokumentes wird dokumentiert. Dies betrifft vor allem den
Quelltext, aber auch alle schriftlichen Dokumente wie z.B. das Benutzer- und Entwicklerhandbuch.
Dies wird aus technischer Sicht für den Quellcode und die Testdefinitionen
durch den Einsatz des Programmpakets CVS (Concurrent Version System) gewährleistet.
Durch den Einsatz von Eclipse, in dem eine umfassende CVS-Unterstützung
integriert ist, wird die Nutzung dieses Systems durch alle Gruppenmitglieder sichergestellt.
Hierbei wird bei jedem „Commit“-Vorgang, d.h. bei jedem Hinzufügen von
neuem oder Ändern von bestehendem Code, ein begleitender Kommentar abgefragt.
Wir haben daher die Regel aufgestellt, commits stets mit sinnvollen Kommentaren
durchzuführen. Dadurch können Änderungen einheitlich protokolliert werden und die
Versionskontrolle ist gewährleistet.
Bei anderen Dokumenten, wie z.B. diesem Pflichtenheft, werden grundsätzlich alle
alten Versionen archiviert und sind stets über den Dateibereich auf unserer Homepage
verfügbar.
7.3.4 Layout und Stil
Dokumentation:
Für alle schriftlichen Dokumente werden einheitliche Formatvorlagen verwendet. Diese
wurden vom Zuständigen für die Qualitätssicherung erzeugt. Er überprüft auch die
Einhaltung und Benutzung der Vorlagen. Die Einhaltung von Layoutkonventionen ist
sehr wichtig, da Dokumente in der Regel auch lange nach ihren Erstellungsdatum noch
oft gelesen werden, und ein einheitlicher Stil das Zurechtfinden erheblich verbessert.
Programmierstil:
Auch die Formatierung der Quelltexte und das Klassendesign sind einheitlich festgelegt.
Dies erleichtert vor allem die Lesbarkeit von Komponenten, die von anderen
Gruppenmitgliedern erstellt wurden. Zu einem guten Programmierstil gehört auch die
Dokumentation im Quelltext und die Einhaltung von bestimmten Richtlinien bei der
Benennung von Variablen, Methoden und Klassen. Im wesentlich orientieren wir uns
hierbei am Java Style Guide der Firma Sun. Einige Punkte werden nachfolgend kurz
erläutert.

7.3. UMSETZUNG IM PROJEKT 65
7.3.4.1 Code-Dokumentation
Die Quelltexte sollen auch von anderen Gruppenmitgliedern und zukünftigen Entwicklern
gut lesbar und verständlich sein. Darum werden alle wichtigen Variablen und Methoden
(JavaDoc-konform) direkt im Programmcode kurz erläutert. Bei komplexeren
Methoden wird in gleicher Weise auch auf Unterabschnitte bzw. Funktionsblöcke eingegangen.
7.3.4.2 Namensgebung
Für die Benennung von Klassen, Methoden und Variablen wird eine einheitliche Richtlinie
festgelegt. Zum Beispiel soll der Verwendungszweck einer Variable direkt anhand
des jeweiligen Bezeichners erkennbar sein. Diese Vorgehensweise erleichtert die Verständlichkeit
des Quelltexts. Insbesondere bei der Benennung von Methoden wird auf
eine klassenübergreifende Konsistenz geachtet, soweit dies möglich und sinnvoll ist.
Vor allem wird bei der Namesgebung darauf geachtet, die englische Sprache zu verwenden,
was vor allem in Bezug auf das spätere Open-Source-Dasein dieses Projektes
äußerst wichtig ist.
7.3.4.3 Programmierstandard
Die Umsetzung eines bestimmten Programmierstandards schließt bereits die Verwendung
von Namenskonventionen mit ein. Den Kern bildet jedoch ein Regelwerk das
festlegt, wie die syntaktischen Mittel der eingesetzten Programmiersprache verwendet
werden dürfen. Dies unterstützt zum einen die Erstellung von einheitlichem Code, hilft
aber auch dabei, Fehler zu vermeiden, die zum Beispiel beim Einsatz von bestimmten
Sprachmitteln auftreten können. Auch hier halten wir uns an den Java Style Guide 1 von
Sun.
7.3.5 Tests
Tests von Komponenten und Prototypen dienen der frühzeitigen Fehlererkennung. Je
später ein Programmfehler entdeckt wird, desto aufwendiger wird seine Behebung. Daher
wird bei der Implementierung auf die regelmäßige Anwendung von Tests geachtet.
Wir verwenden beim Testen sowohl automatische Unit-Tests als auch manuelle Tests.
7.3.5.1 Unit-Tests
Die sogenannten Unittests, die im XP eine elementare Rolle einnehmen (siehe Abschnitt
6.2.2), werden mit Hilfe von JUnit 2 durchgeführt. JUnit ist ein kleines, mächtiges
Java-Framework zum Schreiben und Ausführen automatischer Unit-Tests. Hierbei
werden Programmeinheiten in Isolation von anderen im Zusammenhang des Programms
benötigten Einheiten getestet. Die Größe der unabhängig getesteten Einheit
kann dabei von einzelnen Methoden über Klassen bis hin zu Komponenten reichen.
Hierbei wird, soweit dies möglich ist, auf Test First Programming gesetzt, bei dem
zunächst der Test und dann die Einheit programmiert wird.
1 http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
2 http://www.junit.org

66 KAPITEL 7. QUALITÄTSSICHERUNG
7.3.5.2 Manuelle Tests
Hierbei werden Programmabläufe von den Teammitgliedern selbst getestet. Es wird dabei
eine Reihe von Aktionen ausgeführt, die speziell einen Programmteil testen, oder
gar einen ganzen Programmablauf. Dabei werden unter anderem vorher erzeugte Testeingabedateien
verwendet, bzw. festgelegte Testszenarien durchgeführt. Da das Projekt
einen sehr großen Wert auf eine ansprechende Optik und Benutzerführung legt,
muss sehr oft die Tauglichkeit der GUI, bzw. der Visualisierung, durch wiederholten
Einsatz geprüft werden. Hierbei sollen Fehler oder Umständlichkeiten in der Benutzerfreundlichkeit
des Programms aufgedeckt werden.
7.3.5.3 Fehlerdokumetation
Testfälle müssen sehr genau dokumentiert werden, um eine Reproduktion des Fehlers
zu ermöglichen. Hierzu hat sich die Gruppe auf einen gemeinsamen Standard der Fehlerdokumentation
geeinigt. Es werden bei jedem Test der genaue Testablauf, und falls
vorhanden, die Fehlermeldung festgehalten und auf dem Wiki der Gruppe festgehalten.
So können Fehler jederzeit von allen Mitgliedern der Gruppe eingesehen und analysiert
werden.
7.3.5.4 Durchführung
Die Implementierung des Projekts ist in eine Reihe von Iterationen unterteilt. Im Zuge
jeder Iteration werden dem Projekt bestimmte Funktionalitäten bzw. Funktionsblöcke
hinzugefügt. Vor der Implementierung eines solchen Abschnittes werden geeignete
Testfälle spezifiziert, um die gewünschte Semantik zu charakterisieren. Zum Abschluss
einer Iteration muss sichergestellt sein, dass alle Testfälle fehlerfrei durchgeführt werden
können. Außerdem werden die Programmieraufgaben in gegenseitiger Kontrolle
von Kleingruppen bearbeitet, sodass logische Fehler möglichst früh gefunden bzw.
vermieden werden können.
7.3.6 Kommunikation
Zur Schaffung einer gemeinsamen Basis und der Vermeidung von Missverständnissen,
ist ein regelmäßiger Austausch zwischen allen Beteiligten des Projektes von zentraler
Bedeutung.
Intern
Die Gruppe trifft sich mindestens einmal wöchentlich zur gemeinsamen Teamsitzung.
Darin werden unter anderem alle wichtigen Fragen abgestimmt, Aufgaben definiert
und verteilt sowie Ergebnisse von Kleingruppen diskutiert. Dadurch sind alle Gruppenmitglieder
kontinuierlich über Stand und Fortschritt des Projektes informiert, und
Missverständnisse können schnell erkannt und ausgeräumt werden.
Extern
Sämtliche Kommunikation von der Gruppe nach außen läuft über den Außenminister.
Er ist unter anderem auch für die Kommunikation mit dem Auftraggeber Daedalos
zuständig. Einerseits unterrichtet er die anderen Teammitglieder über Nachrichten des
Auftraggebers, andererseits berichtet er dem dem Auftraggeber regelmäßig über den

7.4. MERKMALS-MASSNAHMEN-ZUORDNUNG 67
aktuellen Stand des Projekts. Desweiteren hat der Auftraggeber die Möglichkeit, mit
der Gruppe über das gemeinsame Wiki zu kommunizieren.
7.4 Merkmals-Maßnahmen-Zuordnung
Merkmal
Änderbarkeit / Analysierbarkeit
Stabilität / Zuverlässigkeit
Übertragbarkeit
Konfigurierbarkeit
Nutzwert
Konformität
Anwendbarkeit / Benutzerfreundlichkeit
Effizienz
Prozessqualität
Maßnahme
Code-Richtlinien, Code-Dokumentation
Tests, Fehlerdokumentation
Tests (auf verschiedenen Plattformen)
(wird erfüllt durch Konformität, da in funktionaler
Spezifikation)
Tests, Kommunikation mit dem Auftraggeber
interne Kommunikation
Kommunikation mit dem Auftraggeber
(Last-) Tests
Dokumentation von Änderungen, interne Kommunikation
7.5 Kontrolle der Qualität
Die Qualitätssicherung im Projekt basiert im Kern auf einer Sammlung von Richtlinien
zur Sicherstellung der Transparenz, auf dem Einsatz von statischen wie auch dynamischen
Tests und auf der regelmäßigen Kommunikation zwischen allen Beteiligten. Diese
Punkte wurden bereits dargestellt. Darüber hinaus werden alle wichtigen Prozesse
durch folgendes Zweischichten-Modell gesichert.
Aufgaben wie z.B. die Erstellung eines Dokumentes werden an Kleingruppen vergeben.
Die Mitglieder einer solchen Kleingruppe kontrollieren sich während der Arbeit
gegenseitig. Sollte nur eine Person an einem Thema arbeiten, so werden die Resultate
zunächst vom Beauftragten für Qualitätssicherung gegengelesen. Anschließend werden
die Ergebnisse in der gesamten Gruppe vorgestellt und diskutiert. Sollten Änderungen
erforderlich sein, die nicht sofort durchgeführt werden können, durchlaufen sie den angeführten
Vorgang erneut. Bei bestimmten Aufgabentypen können andere Vorgehensweisen
besser geeignet sein. Im Allgemeinen werden alle Dokumente und Quellcodes
mindestens vom Beauftragten für Qualitätssicherung auf Format und Korrektheit geprüft.
7.6 Risikomanagement
Im Folgenden werden die von uns erkannten Kernrisiken, die den erfolgreichen Abschluss
des Projekts gefährden könnten, dargestellt und analysiert. Insbesondere werden
vorbeugende Maßnahmen besprochen und Schritte für den Fall des Eintretens festgelegt.

68 KAPITEL 7. QUALITÄTSSICHERUNG
7.6.1 Mangelhafter Zeitplan
Problem:
Der Projektumfang wird von Anfang an komplett unterschätzt. Es ist möglich, dass
wirklich eine ehrliche Schätzung versucht wurde und diese völlig falsch lag, doch oftmals
ist eher der Grund, dass Wunschtermine zu festen Lieferdaten gemacht werden.
Zusammen mit anderen unumstößlichen Randbedingungen des Projekts führt dies zu
einem Projekt, das nach [1] „overconstrained“ ist.
Risiko:
Mittel - Der Umfang des Projektes scheint in unseren Augen gut abschätzbar zu sein.
Vorbeugende Maßnahmen:
Der Abgabetermin ist von Seiten der Universität festgesetzt und somit unabänderlich.
Wir benutzen jedoch einen iterativen Entwicklungsprozess, wodurch sichergestellt ist,
dass auch frühe Versionen unserer Software bereits eine gewisse Kernfunktionalität
besitzen. In jedem Fall sollte der von uns aufgestellte Iterationsplan im Auge behalten
werden, um Verzögerungen im Zeitplan schnell zu erkennen und darauf zu reagieren.
Wenn das Risiko zu einem Problem wird:
Sollten wir unter hohen Zeitdruck geraten, bietet sich an, nur die Kernfunktionalitäten
des Programms zu implementieren. Zu diesem Zweck sind die Use Cases nach
Schwierigkeit und Priorität sortiert. Sollte sich das Risiko manifestieren, so werden
wir im Zweifelsfall trotz der Einplanung einer Pufferzone am Ende unseres Zeitplans
einige niedrig-priorisierte Features nicht fertiggestellen können. Da das Projekt auch
nach Abschluss der Software Engineering-Veranstaltung als Open-Source-Projekt weitergeführt
wird, besteht dennoch Hoffnung, dass noch nicht implementierte Features
von anderen Entwicklern der Open-Source-Gemeinde aufgegriffen und außerhalb des
Rahmens dieser Veranstaltung verwirklicht werden.
7.6.2 Keine ordentliche Spezifikation
Problem:
Der Auftraggeber kann sich nicht zu einer genauen Spezifikation des zu erstellenden
Softwareprodukts durchringen bzw. es gibt widersprüchliche Anforderungen von verschiedenen
Seiten.
Risiko:
Hoch - Die bisher vom Auftraggeber erhaltenen Anforderungen sind sehr allgemein
gehalten. Ein Grund dafür mag sein, dass das Projekt nicht die Erstellung von unternehmenskritischer
Software zum Ziel hat, sondern mehr als Machbarkeitsstudie, fast
schon als „Experiment“ gesehen wird.

7.6. RISIKOMANAGEMENT 69
Vorbeugende Maßnahmen:
Es gibt (kommerzielle) Alternativen zu unserem Programm. Da nicht zu erwarten ist,
dass wir detailliertere Spezifikationen erhalten werden, sollten wir uns bemühen, eine
erschöpfende und in sich konsistente Anforderungsspezifikation in eigener Regie zu
erstellen.
Wenn das Risiko zu einem Problem wird:
Im Falle einer mangelhaften Spezifikation sollten wir uns an den erwähnten Programmen
orientieren und versuchen, ein Produkt mit ähnlicher Funktionalität zu erstellen.
Diese von uns erstellte Spezifikation wird als Teil des Pflichtenhefts dem Auftraggeber
vorgelegt und im Idealfall von ihm abgesegnet. Im Zuge der Planung und Programmierung
werden wir versuchen, die Funktionalität der bereits existierenden Programme
nachzubilden. Dies gilt auch für den Fall, dass sich nach Unterschrift des Pflichtenhefts
irgendwelche Unklarheiten / fehlende Kernfunktionalitäten ergeben. Da die
erwähnten Programme von Drittherstellern bisher noch nicht vom Auftraggeber eingesetzt
wurden, ist mit einem eventuellen Scheitern des Projekts in keinem Fall ein
Verlust verbunden, sondern höchstens eine Art „entgangener Gewinn“.
7.6.3 Anforderungs-Inflation
Problem:
Nach einer Einigung auf eine Anforderungsspezifikation kommen im Laufe des Projekts
immer weitere zusätzliche Anforderungen hinzu und drohen, den Zeitplan des
Projekts durcheinanderzubringen.
Risiko:
Niedrig - Dieses Pflichtenheft mit der darin beschriebenen Funktionalität ist rechtlich
bindend.
Vorbeugende Maßnahmen:
Streng genommen ist nur die in diesem Pflichtenheft beschriebene Funktionalität für
uns bindend. Da es jedoch nach dem Risikofaktor „Keine ordentliche Spezifikation“
möglich ist, dass sich Teile der benötigten Funktionalität erst im Laufe der Programmierarbeit
ergeben, sollten wir dieses Risiko nicht völlig aus dem Auge verlieren.
Wenn das Risiko zu einem Problem wird:
Für den Fall, dass zu einem späten Zeitpunkt im Verlauf des Projekts weitere Funktionalitäten
eingefordert werden, die nicht im ursprünglich abgegebenen und unterschriebenen
Pflichtenheft auftauchen, können wir - je nachdem, wie wir im Zeitplan liegen
- entweder die Machbarkeit beurteilen und die gewünschte Funktionalität nachträglich
als Muss-Kriterium aufnehmen, oder aber ablehnen, wozu wir nach den Bedingungen
in diesem Pflichenheft das Recht haben.

70 KAPITEL 7. QUALITÄTSSICHERUNG
7.6.4 Weggang von Personal
Problem:
Mitglieder des Teams scheiden aus, bevor das Projekt beendet ist
Risiko:
Niedrig - In den ersten Wochen hat sich gezeigt, dass wir ein gutes Betriebsklima haben,
das von Gleichberechtigung und gegenseitigem Respekt geprägt ist.
Vorbeugende Maßnahmen:
Alle Teilnehmer der Veranstaltung sind in einem Team gebunden, weswegen eine „firmeninterne“
Umschichtung von Personal nicht möglich ist. Wir sollten daher bemüht
sein, unser gutes Betriebsklima zu erhalten und Unstimmigkeiten frühzeitig zur Sprache
bringen, bevor sie zu einem echten Problem werden.
Wenn das Risiko zu einem Problem wird:
Sollte das Team entgegen aller Erwartungen auseinanderbrechen und die Fertigstellung
des Projekts daher nicht mehr möglich sein, bietet die TU Darmstadt selbst erstellte
Auffangprojekte an, die es den einzelnen Personen immerhin erlauben, die Veranstaltung
erfolgreich abzuschließen.
7.6.5 Umzug in das Zintl-Gebäude
Problem:
Der Fachbereich Informatik zieht vor Beginn der Vorlesungen im Sommersemester
2004 in das ehemalige Zintl-Gebäude um. Während dieser Zeit ist die Infrastruktur des
Fachbereichs nur eingeschränkt nutzbar. Dies betrifft vor allem die Server, auf denen
unsere Homepage und die CVS-Repositories liegen.
Risiko:
Sehr Hoch - Der Umzug wird stattfinden, auch wenn er möglicherweise später als ursprünglich
geplant stattfindet.
Vorbeugende Maßnahmen:
Da es einfach zu bewerkstelligen ist und keine großen Kapazitäten benötigt, sollten
wir - zusätzlich zu den täglichen Backups der TU Darmstadt- über ein regelmäßiges
eigenes Backup aller wichtigen Daten nachdenken. Ein Ausweichserver kann besonders
für die CVS-Funktionalität sinnvoll sein, um die Programmierarbeit nicht unnötig
zu behindern. Sollte niemand einen Server mit dauerhafter Netzanbindung zur Verfügung
stellen können, so läßt sich möglicherweise bereits in diesem frühen Stadium des
Projekts ein Account bei SourceForge 3 oder einem ähnlichen Dienst einrichten, der im
Notfall genutzt werden kann.
3 http://www.sourceforge.net/

7.6. RISIKOMANAGEMENT 71
Wenn das Risiko zu einem Problem wird:
Sollten wichtige Teile der Infrastruktur tatsächlich über einen längeren Zeitraum nicht
nutzbar sein, so können wir auf die vorbereiteten Backup-Server ausweichen. Dieses
Risiko ist jedoch streng genommen nicht unser eigenes Risiko, sondern das unseres
„Vorgesetzten“ in Form des Fachbereichs. Dieser sollte sich daher darum bemühen,
die Ausfallzeiten so kurz wie möglich zu halten und den Umzug aus sicht der Netzinfrastruktur
transparent zu gestalten.
7.6.6 Bibliotheken
Problem:
Im Verlauf der Entwicklung stellen sich Details der verwendeten Bibliotheken (TM4J,
GraphLayout) als unvorteilhaft heraus, d.h. die Bibliotheken sind beispielsweise zu
langsam, bewältigen die geforderte Datenmenge nicht fehlerfrei o.ä. Da die Bibliotheken
als Open Source Projekte ständig in Entwicklung sind, ist es auch möglich, dass
sich in zukünftigen Versionen eine Änderung der Schnittstellen ergibt.
Risiko:
Niedrig - Die Bibliotheken kommen auch in einer Vielzahl anderer Projekte zum Einsatz,
woraus auf eine gewisse Zuverlässigkeit geschlossen werden kann. Es ist außerdem
nicht anzunehmen, dass die Entwickler der Bibliotheken in zukünftigen Versionen
Änderungen an der Schnittstelle in einer Weise vornehmen, die eine komplette
Umstukturierung notwendig macht.
Vorbeugende Maßnahmen:
Die Bibliotheken wurden vor ihrer Verwendung ausgiebig auf ihre Eignung getestet.
Die Schnittstelle zwischen unserem Projekt und den Bibliotheken wird möglichst schmal
gehalten, so dass eventuelle Änderungen nur geringfügige Anpassungen an unserem
Projekt notwendig machen.
Wenn das Risiko zu einem Problem wird:
Sollte sich eine Bibliothek nachträglich als ungeeignet für unser Projekt herausstellen,
so muß die absolut notwendige Grundfunktionalität manuell reimplementiert werden.
Der dadurch entstehende Zeitverlust muss durch die Pufferzone in der Zeitplanung
aufgefangen werden.

72 KAPITEL 7. QUALITÄTSSICHERUNG

Kapitel 8
Rechtsgrundlagen
8.1 Vertragspartner und Vertragsgegenstand
Auftraggeber ist die Daedalos Consulting GmbH. Auftragnehmer ist die Studentengruppe
ByteMe. Das Vertragsverhältnis zwischen Auftraggeber und Auftragnehmer
entspricht einem Werkvertrag. Vertragsgegenstand ist das oben genannte Projekt in
seinem vollen Umfang in Form von Dokumenten und ausführbaren Programmen.
8.2 Urheber- und Nutzungsrechte
Die Urheber- und Nutzungsrechte werden in dem separaten Dokument „Lizenzvereinbarung“
festgelegt.
8.3 Change-Request-Verfahren
Änderungswünsche, die nach beidseitiger Unterzeichnung des Pflichtenheftes auftreten,
werden nur unter Zustimmung sowohl des Auftraggebers als auch des Auftragnehmers
berücksichtigt. Bei beidseitigem Einverständnis bezüglich Änderungen des
Auftrages müssen diese Änderungen in einem separaten Schriftstück festgehalten und
durch beidseitige Unterschrift bestätigt werden. Ein solches Schrifstück enthält in der
Regel folgende Punkte:
• Änderungswunsch,
• Notwendigkeit,
• Lösungsvorschlag,
• Dringlichkeit,
• Kosten und Auswirkungen auf das Projekt.
73

74 KAPITEL 8. RECHTSGRUNDLAGEN
8.4 Schadensersatz- und Wartungsansprüche
8.4.1 Gewährleistung und Wartung
Es besteht keinerlei Gewährleistung für die entwickelten Programme, weder seitens
der TU Darmstadt, noch seitens des Auftragnehmers. Bei den zu entwickelnden Programmen
handelt es sich um eine Studie. Die Eignung für einen kommerziellen Einsatz
kann nicht garantiert werden. Dem Auftraggeber ist bekannt, dass bei Softwareprodukten,
trotz Erprobung unter repräsentativen Einsatzbedingungen, Fehler im Programm
nicht auszuschließen sind. Daher gilt ein subjektiver Fehlerbegriff. Das bedeutet, dass
ein Fehler immer dann gegeben ist, wenn der Software eine Eigenschaft fehlt, die im
Pflichtenheft ausdrücklich zugesichert wurde. Weder Auftragnehmer noch die Technische
Universität Darmstadt übernehmen Wartungsverpflichtungen jeglicher Art für das
Produkt.
8.4.2 Schadensersatzansprüche
Im Falle einer Nutzung durch den Auftraggeber liegt das Risiko für jegliche Art von
Schäden beim Auftraggeber. Weder die TU Darmstadt, noch der Auftragnehmer haften
für die bei der Nutzung entstandenen Schäden soweit diese nicht durch Vorsatz entstehen.
Der Auftraggeber trägt allein das Risiko für Schäden wie z.B. Datenverluste,
Hardwaredefekte oder Systemabstürze. Etwaige durch die Benutzung der Programme
entstehende Kosten für die Wiederbeschaffung von Daten und Programmen sowie Kosten
für Reparaturen an der Hardware sind vom Benutzer zu tragen. Der Auftragnehmer
kann nicht für Sach-, Personen- und Vermögensschäden haftbar gemacht werden,
die im Zusammenhang mit dem Einsatz der vom Auftragnehmer erstellten Programme
entstehen könnten. Bei Schaden Dritter, der durch den Einsatz des Produktes entsteht,
übernimmt der Auftragnehmer keinerlei Haftung. Eine Haftung der Technischen Universität
Darmstadt für den Auftragnehmer als deren Erfüllungsgehilfen nach §278 BGB
scheidet ebenfalls aus.
8.5 Anwendbares Recht und Gerichtsstand
Für die Rechtsbeziehungen zwischen Auftraggeber, Auftragnehmer, Technischer Universität
Darmstadt und etwaigen Dritten gilt das Recht der Bundesrepublik Deutschland
als zwingend vereinbart. Andere nationale Rechte werden ausgeschlossen. Der
Gerichtsstand ist Darmstadt.
8.6 Zusicherungen
Der Auftragnehmer verpflichtet sich, die in Abschnitt 3.1 (als garantiert) zugesicherte
Funktionalität zu liefern. Der Auftraggeber verpflichtet sich, diese abzunehmen.
8.7 Ende des Vertragsverhältnisses
Das Projekt endet, sobald der Auftraggeber nach der Übergabe der zugesicherten Programme/Prototypen
die Vollständigkeit und Korrektheit der Produkte im Sinne des

8.7. ENDE DES VERTRAGSVERHÄLTNISSES 75
Pflichtenheftes bestätigt, spätestens jedoch am 30. September 2004. Sollten hier Meinungsverschiedenheiten
auftreten, wird die TU Darmstadt (Fachbereich Informatik,
Fachgebiet Softwaretechnologie) als Schiedsstelle hinzugezogen.

76 KAPITEL 8. RECHTSGRUNDLAGEN

Anhang A
Eine Einführung in Topicmaps
(Übersetzung der englischen Version, zu finden unter [4].)
A.1 Einleitung
Ein Buch ohne Index ist ein Land, für das keine Landkarte existiert.
Doch wie interessant und spannend die Erfahrung, ohne Landkarte von A nach B
zu fahren, auch sein mag, so besteht doch kein Zweifel, dass eine Karte dann unerläßlich
ist, wenn man sein Ziel so schnell wie möglich (oder zumindest ohne unnötige
Verzögerung) erreichen will.
Sucht man analog nach einer bestimmten Information in einem Buch (anstatt es
von vorne bis hinten durchzulesen), so ist ein guter Index ein immenses Plus. Ein traditioneller
Index am Ende eines Buches ist wie eine sorgfältig erstellte, handgemalte
Landkarte, und das Erstellen eines solchen Index ist wie eine Aufzeichnung aller Themen
des jeweiligen Dokuments in einer übersichtlichen und genauen Landkarte für den
Leser.
Bisher gab es keine Entsprechung des traditionellen Index am Ende eines Buches
in der Welt der elektronischen Information. Zwar können wir einzelne Wörter in einer
Textverarbeitung markieren und so einen automatischen Index erzeugen lassen, doch
diese Indizes sind zu sehr an ein bestimmtes Dokument gebunden und für eine Veröffentlichung
auf Papier ausgelegt. Die Welt der elektronischen Informationen ist anders,
wie uns das World Wide Web gelehrt hat. Die Unterscheidung zwischen verschiedenen
Dokumenten verschwimmt, und Indizes, die mehrere Dokumente und manchmal noch
größere Informationsressourcen umspannen, wären wünschenswert. Daraus Ergibt sich
die Notwendigkeit, Indizes zu verschmelzen und benutzerdefinierte Sichten auf die Informationen
zuzulassen. In dieser Situation sind traditionelle Indizes unbrauchbar.
Das Problem ist seit Jahrzehnten in der Domäne der Dokumentenverwaltung bekannt,
aber die Methoden, es zu lösen - Volltextindizes - haben das Problem nur teilweise
gelöst. Jeder, der schon einmal eine Suchmaschine im Internet benutzt hat, kann
dies bestätigen.
Das Hauptproblem mit Volltextindizes ist ihr Mangel an Unterscheidungskraft. Sie
indizieren alles. Man stelle sich einen traditionellen Index am Ende eines Buches vor,
der jedes einzelne Wort des Buches umfaßt, abgesehen von ein paar hundert wirklich
unnützer Wörter, und von den verbleibenden jedes einzelne Vorkommen auflistet.
Selbst ohne Berücksichtigung verschiedener Flexionsformen wäre das Ergebnis ziem-
77

78 ANHANG A. EINE EINFÜHRUNG IN TOPICMAPS
lich nutzlos. Eine rein mechanische Indizierung berücksichtigt nicht, dass ein Sachverhalt
durch verschiedene Wörter ausgedrückt werden kann (das Synonym-Problem),
oder dass ein Wort verschiedene Dinge bezeichnen kann (das Homonym-Problem).
Und dennoch ist dies das Funktionsprinzip gängiger Web-Suchmaschinen (kein Wunder,
dass sie stets tausende irrelevanter Ergebnisse liefern und man das Gesuchte darunter
nicht findet!).
Daher werden neue Methoden benötigt. Topicmaps bieten einen Ansatz, der das
beste aus verschiedenen Welten verbindet, einschließlich der des traditionellen Indexerstellens,
Bibliothekswissenschaft und Wissensrepräsentation, mit fortgeschrittenen
Techniken des Verweisens und Adressierens. Wir sind der Überzeugung, dass sie für
die Informationsanbieter von morgen so unerläßlich sein werden wie Landkarten für
einen Reisenden. Und wenn Topicmaps erst einmal allgegenwärtig sind, werden sie
das GPS-System der Informationswelt sein.
A.2 Konzepte
Dieser Abschnitt beschreibt die Konzepte, die für das Verständnis von XML Topicmaps
(XTM) notwendig sind.
Der Zweck einer Topicmap ist es, Wissen über bestimmte Sachverhalte durch ein
darübergelegtes Netz, das diese Sachverhalte kartographiert, zu vermitteln. Eine Topicmap
enthält alle Themen, die für den jeweiligen Sachverhalte wichtig ist, sowie die
Beziehungen zwischen diesen Themen. Die Topicmap ist dabei unabhängig von einer
konkreten Implementierung.
Die Grundkonzepte einer Topicmap sind Topics (Themen), Associations (Beziehungen)
und Occurences (Vorkommnisse).
Ein Topic ist eine Ressource innerhalb des Computers, die ein Thema aus der realen
Welt repräsentiert. Beispiele für solche Themen sind das Theaterstück Hamlet, der
Autor William Shakespeare, oder die Beziehung „ist Autor von“.
Topics können Namen haben. Sie können auch Occurences besitzen, d.h. Informationsressourcen,
die in einer bestimmten Weise als für ihr Thema relevant angesehen
werden. Außerdem können Topics die Bestandteile von Beziehungen (Associations)
sein, wo sie die Rolle eines Teilnehmers einnehmen.
Topics haben also drei Charakteristika: Namen, Occurences und Rollen, die sie in
den Associations spielen. Die Zuweisung dieser Charakteristika ist für einen bestimmten
Kontext oder Scope gültig.
Topicmaps können miteinander verschmolzen werden. Diese Verschmelzung kann
zur Laufzeit auf Initiative eines Benutzers oder einer Applikation erfolgen, oder vom
Autor der Topicmap bei ihrer Erstellung vorgegeben sein.
Der folgende Abschnitt ist eine kurze Einführung, die ein einfaches Beispiel aus
dem Sachgebiet von Enzyklopädien benutzt. Anschließend folgt eine detailliertere Übersicht
über die Konzepte von Topicmaps.
A.2.1
Kurze Einführung in Topicmaps
Um die Verwendung der Topicmaps, wie sie in dieser Spezifikation definiert sind, zu
verdeutlichen, betrachten wir ein einfaches Beispiel. Angenommen, wir wollen Informationen
über das Thema eines Dokuments so speichern, dass es den Index einer elektronischen
Enzyklopädie aufgenommen werden kann. Dies soll in einer Weise gesche-

A.2. KONZEPTE 79
hen, die unabhängig von bestimmten Endgeräten und unabhängig von einer bestimmten
Implementierung ist.
Für bestimmte Themen, z.B. William Shakespeare, Ben Johnson, ihre Stücke Hamlet
und Volpone, und die Städte London und Stratford, wollen wir für alle Stellen in
der elektronischen Enzyklopädie - Textpassagen, Bilder oder Tondokumente - festhalten,
wo sie besprochen, abgebildet oder sonstwie erwähnt werden. Wir nennen diese
Vorkommnisse „Occurences“ dieser Themen. Unterschiedliche Occurences können auf
unterschiedliche Weise auf ihr Thema bezug nehmen. Dies wollen wir ebenfalls unterscheiden.
Detaillierte Besprechungen, kurze Erwähnungen und Abbildungen müssen
voneinander unterschieden werden, damit Benutzer schneller das gesuchte finden können.
Die Enzyklopädie, mit der wir arbeiten, existiert in elektronischer Form, so dass jede
Occurence eines Themas eine elektronische Ressource ist. Somit hat jede Ressource
eine Adresse. (Ohne ins Detail über den Aufbau von Adressen zu gehen, definieren wir
eine Adresse als einen Ausdruck, der dem Computer erlaubt, eine Ressource zu lokalisieren.)
Es sind also adressierbare Informationsressourcen.
Die Autoren William Shakespeare und Ben Johnson sind dagegen keine adressierbaren
Ressourcen. Sie sind überhaupt keine elektronischen Dinge, sondern Menschen.
Um die Verbindung zwischen einer Occurence eines Themas und dem Thema selbst zu
repräsentieren, würde man gerne der Reihe nach auf beide zeigen und sagen „an dieser
Stelle wird dieses Thema behandelt“ (oder diesen Vorgang in sein elektronisches Äquivalent
übersetzen, indem man die Adresse der Occurence und die Adresse des Themas
angibt und die Verbindung dazwischen in einer Beschreibungssprache formuliert).
Da nicht alle Themen in elektronischer Form vorliegen, können wir folglich manchmal
keine Adresse dafür angeben. Stattdessen können wir einen elektronischen Ersatz
für das Thema erzeugen. Dieser Ersatz heißt „Topic“. Jedes Topic ist ein Platzhalter
für ein bestimmtes Thema. Man sagt, das Topic vergegenständlicht das Thema oder
macht das Thema für das System greifbar. Das Erstellen eines Topics für ein bestimmtes
Thema erlaubt dem System, die Charakteristika eines Themas zu manipulieren, zu
verarbeiten und zuzuweisen, indem diese Operationen mit dem entsprechenden Topic
vorgenommen werden. Wenn wir eine Adresse für das Thema benötigen, benutzen wir
die Adresse seines Topics, das dem System bekannt ist.
(Da jedes Topic ein Thema repräsentiert und jedes Thema als Vorlage für ein Topic
dienen kann, ist die Unterscheidung manchmal nicht wichtig. Daher werden in diesen
Fällen die Begriffe Topic und Thema gleichwertig benutzt.)
Da die Menge der Indexeinträge eine Art Karte der Enzyklopädie darstellen, die
zeigt, an welcher Stelle bestimmte Themen behandelt werden, nennen wir die elektronische
Entsprechung eines Index eine Topicmap.
Topics, die einige von William Shakespeares Werken repräsentieren, könnten in
etwa so aussehen:
Hamlet, Prince of Denmark

80 ANHANG A. EINE EINFÜHRUNG IN TOPICMAPS
The Tempest

Anhang B
Glossar
Code: Unter Code (auch Quellcode oder Source genannt) wird der eigentliche Programmtext
verstanden, der nach der Kompilierung das fertige Softwaresystem
liefert.
CVS: Abkürzung für „Concurrent Versions System“. Softwaresystem zur Versionskontrolle.
Filter: Festlegung, welche Verbindungsstypen in der visuellen Repräsentation des Netzes
angezeigt werden.
GUI: Abkürzung für „Graphical User Interface“ bzw. „Grafische Benutzerschnittstelle“.
Java: Programmiersprache, die speziell für die Entwicklung von plattformunabhängigen
Anwendungen konzipiert wurde. Die Syntax ist an die Sprache C++ angelehnt
und fördert objektorientiertes Design.
Knoten: Knoten repräsentieren in einem Netz einen Gedanken, ein Objekt oder ein
Thema.
Mindmap: Eine Mindmap ist eine grafische Darstellung, die Beziehungen zwischen
verschiedenen Begriffen aufzeigt. Mindmaps eignen sich zum Festhalten von
Notizen, für Brainstorming-Sitzungen und allgemein für das Zusammenfassen,
Überprüfen und Systematisieren von Ideen. Formal gesehen bestehen sie aus beschrifteten
Baumdiagrammen (ggf. mit zusätzlichen Anmerkungen). Wenn die
Begriffe komplexer miteinander verbunden werden können, spricht man auch
von semantischen Netzen, wo die mit Linien und Pfeilen dargestellten Beziehungen
zwischen einzelnen Begriffen eine definierte Bedeutung besitzen können.
Musskriterien: Musskriterien sind Kernfunktionen der abzuliefernden Software, die
auf jeden Fall implementiert werden müssen. (→Wunschkriterien).
Netz: Ein Netz bezeichnet bei uns die Gesamtheit von Knoten und Verbindungen.
Open Source: Open Source steht für Programme, deren Quellcode veröffentlicht worden
ist. Dadurch kann jeder Interessierte das Funktionieren der Software nachvollziehen.
Open-Source-Programme sind oftmals verbunden mit einer freien Lizenz,
so dass Außenstehende Veränderungen vornehmen oder auf bestehenden
Programmen basierende Anwendungen entwickeln können.
81

82 ANHANG B. GLOSSAR
Pflichtenheft: Das Pflichtenheft spezifiziert verbindlich die genaue Aufgabenstellung
und die Anforderungen der abzuliefernden Software zwischen dem Auftraggeber
und dem Auftragnehmer.
semantische Netze: Ein semantisches Netz besteht aus Knoten, die Konzepte repräsentieren
und Verbindungen, die Beziehungen zwischen den Knoten herstellen.
Semantische Netze werden zur formalen Wissensrepräsentation genutzt und können
in Form von verallgemeinerten Graphen dargestellt werden. Ein mögliches
Format der Speicherung ist der Topicmap-Standard. (→ Mindmap)
Server: Rechner, der durch geeignete Software in der Lage ist, bestimmte Dienste in
einem Netzwerk anzubieten.
Software Engineering Praktikum: Das Software Engineering Praktikum ist ein Praktikum,
das jedes Wintersemester an der TU Darmstadt beginnt und sich über ein
Jahr erstreckt. Reale Unternehmen vergeben, unter Vermittlung und Betreuung
des Fachgebietes Praktische Informatik des Fachbereiches Informatik, reale Aufträge,
die von einer Gruppe mit 5-7 Studenten übernommen und ausgeführt werden.
Auf den Software Engineering Messen im November jeden Jahres werden
neue Aufträge vorgestellt bzw. die Ergebnisse der alten Aufgaben präsentiert.
Soll-Zustand: Beschreibt den von unserem Auftraggeber erwarteten Zustand zum Zeitpunkt
der Übergabe der Software.
SourceForge: SourceForge 1 ist ein gemeinschaftliches Softwareentwicklungs-Managementsystem,
das ein Portal zur Verfügung stellt, wo Software-Entwickler ihre
Open-Source-Software verwalten und präsentieren können.
TM4J: TM4J ist eine von uns verwendete Open-Source-Bibliothek, die auf dem Topicmap-
Standard basiert und uns die Möglichkeit bietet, neben der Topicmap-Repräsentation
auch Dienste zum Im- und Export von Topicmaps im XTM-Format verwenden
können.
Topicmap: Ein Topicmap ist ein abstraktes Modell und ein dazu gehöriges in XMLbasiertes
Datenformat zur Formulierung von Wissensstrukturen. Topicmaps bestehen
aus so genannten Topics (Themen, Personen, Orte...), Associations und
Occurences (Instanzen von oder Dokumente zu Topics). (siehe Anhang A)
UML: Abkürzung für „Unified Modeling Language“. Grafische Beschreibungssprache
zum strukturierten, abstrahierten Design von (Software-) Systemen.
URL: Dokumente werden im World Wide Web mittels sog. URLs (Uniform Resource
Locator) adressiert.
Use Case: Textuelle und/oder grafische Beschreibung von Anwendungsfällen, die in
einem Softwaresystem auftreten können. Die Menge aller Use Cases sollte die
gesamte Funktionalität einer Software erfassen. Englisch für „Anwendungsfall“;
dies bezeichnet einen Arbeitsschritt, der bei der Behandlung des gesamten Problemkomplexes
als einzelner Teilschritt auftreten kann.
Use Case Modell: Das Use Case Modell stellt die für die Behandlung des Problemkomplexes
nötigen Teilschritte (einzelne Use Cases) und ihre Zusammenhänge
zum einen graphischen und zum anderen verbal (in Tabellen) dar.
1 http://www.sourceforge.net/

83
Verbindung: Eine zwischen zwei Knoten bestehende Beziehung wird durch eine Verbindung
dargestellt.
Visualisierung: Die grafische Darstellung des → Netzes
W3C: Das World Wide Web Consortium (W3C) ist ein im Oktober 1994 gegründeter
Zusammenschluss verschiedener Institutionen, die das World Wide Web weiterentwickeln,
zum Beispiel durch die Verabschiedung von Standards für Datenübertragungsprotokolle.
Wir: Dies bezeichnet die Studentengruppe ByteMe, die an dem Software Engineering
Praktikum im Wintersemester 2003/2004 des Fachbereichs Informatik, Fachgebiet
Praktische Informatik der TU Darmstadt teilnimmt.
Wiki: Ein Wiki ist eine im World Wide Web verfügbare Sammlung von Seiten, die von
den Benutzern nicht nur gelesen, sondern auch online geändert werden können.
Wunschkriterien: Wunschkriterien sind Funktionen der abzuliefernden Software, die
vom Auftraggeber erwünscht sind, die von der Gruppe jedoch nur bei ausreichender
Zeit implementiert werden können (→ Musskriterien).
XML: Die „Extensible Markup Language“ ist ein Quasi-Standard zur Erstellung strukturierter
Dokumente im World Wide Web, der von einer Arbeitsgruppe entwickelt
wurde, die unter der Schirmherrschaft des → W3C steht.
XTM: XTM ist eine Spezifikation, die ein abstraktes Modell und eine → XML-Grammatik
für den Austausch von Topicmaps beschreibt. Sie wurde von den Mitgliedern der
Topicmaps.Org Authoring Group verfasst.

84 ANHANG B. GLOSSAR

Literaturverzeichnis
[1] Tom DeMarco, Timothy Lister: Waltzing With Bears: Managing Risk on Software
Projects, Dorset House 2003
[2] Alistair Cockburn: Writing Effective Use Cases, Addison-Wesley 2000
[3] Kent Beck: Extreme Programming Explained: Embrace Change, Addison-Wesley
1999
[4] Steve Pepper: The TAO of Topic Maps,
http://www.gca.org/papers/xmleurope2000/papers/s11-01.html
85

Index
Änderbarkeit, 61
Änderungen, 64
Übergangsphase, 54
Übertragbarkeit, 62
öffnen, 17
Abgabetermin, 59
Aktion, 14, 39
Analysierbarkeit, 61
Anforderungs-Inflation, 69
Anforderungsspezifikation, 69
anlegen, 18, 21, 33
Anwendbarkeit, 62
Associations, 78
Außenminister, 66
auflösen, 25
Auftraggeber, 9, 56, 62, 66
Auftragnehmer, 9
Ausfälle, 62
Ausnahmesituationen, 62
bearbeiten, 23, 26, 37
Benutzerfreundlichkeit, 62
Benutzerinterface, 45
Benutzeroberfläche, 62
Bibliotheken, 51
Blickpunkt, 28
Bookmark, 41, 42, 49
ByteMe, 9
Change-Request-Verfahren, 73
CVS, 60, 63, 64
Daedalos, 9, 66
Datenbank, 14, 17
Dialogbox, 45
DIN ISO 9126, 61
Dokumentation, 59, 61, 64
Eclipse, 60
editieren, 21
Effizienz, 63
Eigenschaften, 21, 24, 26
Eigenschaftspanel, 45
Eigenverantwortung, 55
Einarbeitungszeit, 62
einfügen, 21
Einführungsphase, 54
Einfachheit, 55
Entwicklung, 60
Entwicklungsprozess, 53
Entwurfsphase, 54
erstellen, 24
Erstellungsdatum, 21
exportieren, 19
Farbcodierung, 14
Feedback, 55, 56, 58
Fehlerdokumetation, 66
Filter, 28, 31
fokussieren, 28
Formatvorlage, 64
Funktionsumfang, 15
Gedanken, 21
Gerichtsstand, 74
Gewährleistung, 74
Glossar, 81
Google, 11
GraphLayout, 51
GUI, 66
Handbuch, 61
hinzufügen, 35
Implementierung, 61
Information Designer, 15
Information User, 15
Ist-Zustand, 11
Iteration, 56, 66
Iterationsplan, 56
Java, 51
JavaDoc, 65
86

INDEX 87
JUnit, 60
Kernfunktionalität, 68
Klassendesign, 64
Knoten, 11, 12
Knotenmanagement, 21, 47
Kommunikation, 55, 64, 66
Komponenten, 61
Konfigurierbarkeit, 62
Konformität, 62
Konstruktionsphase, 54
Kontrolle, 67
löschen, 21, 22, 36
laden, 34
LaTeX, 60
Lesbarkeit, 64
Lesezeichen, 28
Lizenz, 51
Lizenzvereinbarung, 73
Log4J, 52
LyX, 60
Meilenstein, 56, 59
Meilensteine, 58
Mindmap, 11
Missverständnisse, 66
Modell, 15
Musskriterien, 14
Namensgebung, 65
Namenskonventionen, 65
Navigation, 14, 28, 29
nicht-funktional, 42
Nutzungsrechte, 73
Nutzwert, 62
Occurences, 78
Open Source, 65
OpenOffice, 60
Pair-Programming, 55
Persistenzmanagement, 15, 17, 45
Personal, 70
PersonalBrain, 11
Pflichtenheft, 61, 62
Plattformunabhängigkeit, 62
Priorisierung, 42
Programmfehler, 62
Programmierstandard, 65
Programmierstil, 64
Projektumfang, 68
Prototyp, 58
Prozessqualität, 63
Prozessstruktur, 53
Pufferzeiten, 59
Qualitätsmerkmale, 61
Qualitätssicherung, 61
Quelltext, 42, 64
Rücksprachen, 62
Rechtsgrundlagen, 73
Redo, 40, 49
Refactoring, 56
Relation, 21
Release, 56, 63
Richtlinien, 64
Risikomanagement, 67
Rollen, 78
RUP, 53, 54
Schadensersatzansprüche, 74
Schnittstellen, 61
Scope, 78
Sichtweisen, 12
Software, 59
Software Engineering, 9
Soll-Zustand, 12
speichern, 17, 19
Spezifikation, 68
Stabilität, 62
Stil, 64
Style Guide, 64, 65
suchen, 32, 48
Tagesordnung, 53
Teamsitzung, 66
Termine, 58
Tests, 65
TM4J, 51
Together, 60
Toolbar, 45
Tools, 59
Topic, 78
Topic Map, 51
Topicmap, 14, 77
Transparenz, 67
Traversieren, 28
Typenmanagement, 15, 33, 48
Typenprofil, 33

88 INDEX
Umsetzung, 63
Umzug, 70
Undo, 40, 49
Unittests, 65
Use Case, 15
Verbindungen, 11, 12, 24
Verbindungsmanagement, 24, 47
Versionskontrolle, 64
Vertragsverhältnis, 74
Visualisierung, 15, 28, 48
Visualisierungsmodus, 30
W3C, 11
Wartbarkeit, 63
Wartung, 74
Wartungsansprüche, 74
Web, 11
Werkzeuge, 59
Werkzeugleiste, 45
Wiederherstellen, 17
Wiki, 53, 56, 60, 66
Wunschkriterien, 14
XML, 11, 14
XP, 53, 55
XTM, 11, 14, 51
Zeitplan, 68
Zeitplanung, 42, 58
Zielknoten, 27
zusammenführen, 14, 20
Zusicherungen, 74
Zuverlässigkeit, 62

Unterschriftenseite
Das vorstehende Pflichtenheft wird von der Firma Daedalos Consulting GmbH und der
Studentengruppe ByteMe als Grundlage für das Software-Engineering-Projekt „Visualisierung
und Bearbeitung von Informationen in Form semantischer Netze“ anerkannt.
__________________________
Daedalos Consulting GmbH
__________________________
Djukanovic, Sinisa
__________________________
Eifert, Sebastian
__________________________
Orgler, Matthias
__________________________
Stroh, Kai
__________________________
Urvoy, Carole
__________________________
Vekic, Mario
89