Konzept und Werkzeug zur erfahrungsbasierten Erstellung von Use ...

Leibniz Universität Hannover
Fachgebiet Software Engineering
Institut für Praktische Informatik
Fakultät für Elektrotechnik und Informatik
Konzept und Werkzeug zur erfahrungsbasierten
Erstellung von Use Cases
Masterarbeit
im Studiengang Informatik
von
Christian Crisp
Prüfer: Prof. Dr. Kurt Schneider
Zweitprüfer: Prof. Dr. Rainer Parchmann
Betreuer: M. Sc. Eric Knauss
Hannover, 23. Oktober 2006

Abstract
Steigende Komplexität und Termindruck erlauben bei der Planung und Umsetzung neuer
Systeme keine Fehler. Entwickler müssen gleich zu Beginn, nämlich in der
Anforderungserhebungsphase, das System gut und fehlerfrei planen. In der Softwaretechnik
bedient man sich dazu der Technik der Use Cases, um das Verhalten des Systems und alle
denkbaren Fehlermöglichkeiten aufzuzeigen. Für das Gelingen von Projekten sind
letztendlich aber Erfahrungen nötig.
Diese Arbeit befasst sich mit der Entwicklung einer Domainorientierten Entwurfsumgebung
zur Erstellung von Use Cases. Ziel dieses Tools ist die Unterstützung des Benutzers bei der
Aufstellung der funktionalen Anforderungen, um eine gute und hoffentlich fehlerfreie
Planung zu erhalten. Dabei soll das Tool die Arbeit des Benutzers aktiv analysieren,
Hilfestellungen geben und kritisieren. Erfahrungen müssen automatisch herausgesucht und
dem Benutzer leicht zugänglich gemacht werden. Idealerweise werden nur relevante
Erfahrungen angezeigt. Die Arbeit darf dabei nicht behindert oder aufgehalten werden.
3

4
Danksagungen
Ich danke allen, die mir bei dieser Arbeit mit Rat und Tat zur Seite standen und dabei
geholfen haben, das Tool auf Tauglichkeit zu überprüfen. Ein besonderer Dank geht an
meinen Betreuer M. Sc. Eric Knauss, der mich stets vorbildlich und mit großem Interesse
betreut hat.

Inhaltsverzeichnis
Inhaltsverzeichnis..................................................................................................................... 5
1 Einleitung ............................................................................................................................... 7
1.1 Problemstellung................................................................................................................ 7
1.2 Ziel der Arbeit .................................................................................................................. 7
1.3 Gliederung........................................................................................................................ 7
2. Grundlagen........................................................................................................................... 8
2.1 Use Cases ......................................................................................................................... 8
2.1.1 Use Case Diagramm.................................................................................................. 8
2.1.2 Use Case Template.................................................................................................. 10
2.2 Erfahrung........................................................................................................................ 13
2.3 Wissen............................................................................................................................ 14
2.4 Erfahrungsnutzung......................................................................................................... 14
2.5 Weitergabe von Wissen und Erfahrung ......................................................................... 14
2.6 Wissensbasierte Systeme................................................................................................ 15
2.7 Benutzer-Unterstützungssysteme................................................................................... 16
2.8 Kritik .............................................................................................................................. 16
2.9 Domain-Oriented Design Environments (DODEs)........................................................ 16
2.10 SER Prozessmodell ...................................................................................................... 19
3. Anforderungen................................................................................................................... 20
3.1 Zielbestimmung.............................................................................................................. 20
3.2 Systemvorrausetzungen.................................................................................................. 20
3.3 Benutzertypen................................................................................................................. 20
3.4 Funktionale Anforderungen........................................................................................... 21
3.5 Qualitätsanforderungen.................................................................................................. 24
3.5.1 Benutzbarkeit (Usability) ........................................................................................ 24
3.5.2 Funktionalität .......................................................................................................... 25
3.5.3 Übertragbarkeit........................................................................................................ 26
3.5.4 Wartbarkeit .............................................................................................................. 26
4. Konzept ............................................................................................................................... 27
4.1 Klassifizierung von Erfahrung....................................................................................... 27
4.2 Bearbeitung eines Use Cases.......................................................................................... 27
4.3 Anzeigen von Erfahrung, Kritik, Hinweisen, Tipps....................................................... 29
4.3.1 Microsoft Word....................................................................................................... 29
4.3.2 Eclipse ..................................................................................................................... 30
4.3.3 PopUp-Fehlerfenster ............................................................................................... 31
4.3.4 Tipp des Tages ........................................................................................................ 32
4.3.5 Hilfe auf Anfrage .................................................................................................... 32
4.3.6 Fazit......................................................................................................................... 32
4.4 Architektur des Tools..................................................................................................... 33
4.5 Modelle........................................................................................................................... 35
4.5.1 Projekt und Use Case Modell.................................................................................. 35
4.5.2 Template Modell ..................................................................................................... 37
4.5.3 Erfahrungsmodell.................................................................................................... 38
4.6 Erfahrungsmatcher ......................................................................................................... 40
4.7 Erfahrungsschatz............................................................................................................ 41
4.8 GUI Entwurf................................................................................................................... 42
5. Erfahrungssammlung ........................................................................................................ 44
5.1 Allgemeine Erfahrungen auf Projekt- und Use Case-Ebene .......................................... 44
5

6
Inhaltsverzeichnis
5.2 Erfahrungen für Use Case Attribute............................................................................... 47
6. Tool ...................................................................................................................................... 54
6.1 Beschreibung von Schnittstellen und Erweiterungsstellen............................................ 54
6.1.1 Das Use Case Template........................................................................................... 54
6.1.2 Die Erfahrungsbasis ................................................................................................ 54
6.1.3 CriticChecker .......................................................................................................... 57
6.1.4 Der Assistent ........................................................................................................... 57
6.1.5 Die Persistenzschicht............................................................................................... 57
6.1.6 Mehrsprachigkeit..................................................................................................... 58
6.1.7 Export-Filter............................................................................................................ 58
6.2 Kurze Benutzereinführung............................................................................................. 58
7. Ausblick............................................................................................................................... 62
8. Fazit..................................................................................................................................... 63
Abbildungsverzeichnis ........................................................................................................... 65
Literaturverzeichnis............................................................................................................... 66
Anhang .................................................................................................................................... 67
A Use Cases ......................................................................................................................... 67
B XML Schemata................................................................................................................. 82
C Programm und Quellcode................................................................................................. 87
D Umfrageergebnis .............................................................................................................. 88

1 Einleitung
1.1 Problemstellung
Bei immer weiter steigender Komplexität und Zeitdruck in der Softwareentwicklung ist es
von sehr großer Bedeutung, ein neues System gleich in der Erhebungsphase korrekt und
vollständig zu entwerfen. Spätere Änderungen und Erweiterungen bedeuten oft erheblichen
zusätzlichen Aufwand, der zu zeitlichen Verzögerungen führt und nicht selten zu Ärger mit
dem Auftraggeber. In der Softwaretechnik bedient man sich verschiedene Techniken, wobei
Use Cases sich großer Beliebtheit erfreuen. Sie dienen der Erhebung von Anforderungen und
können frühzeitig Fehler und Missverständnisse beseitigen. In einen so genannten
Anwendungsfall stehen ein Akteur und sein Ziel im Vordergrund. Der Weg zu dem Ziel und
somit das Verhalten des (Teil-) Systems wird durch ein Szenario beschrieben. Die Erstellung
von guten Use Cases setzt jedoch Erfahrung voraus, z. B. die nötigen Stakeholder vollständig
zu ermitteln, ein gutes Maß zwischen groben und feinen Schritten zu finden und mögliche
Fehler zu erkennen und zu behandeln. Gerade deshalb sind Use Cases alles andere als trivial.
1.2 Ziel der Arbeit
Ziel dieser Arbeit ist es, die oben genannten Schwierigkeiten bei der Aufstellung von Use
Cases aufzuzeigen und eine Erfahrungssammlung zusammenzustellen, die bei der Erstellung
von Use Cases helfen soll. Erfahrungen werden heute zwar bereits gesammelt, sie werden
jedoch nur selten auch genutzt, da eine Suche mit Zeit und Aufwand verbunden ist. Ein
umgesetztes Tool soll bei der Erstellung von Use Cases aktiv helfen. Dabei gibt das Tool je
nach Bedarf verschiedene Hilfestellung und zeigt Hinweise und Warnungen selbständig. Ein
geeignetes Konzept soll Erfahrungen für den Benutzer leicht zugänglich machen, so dass sie
auch tatsächlich genutzt werden. Die Erfahrungen werden unabhängig vom Programm
gespeichert und sind durch den Benutzer jederzeit erweiterbar. Darüber hinaus generiert das
Programm aus den Anwendungsfällen automatisch ein Use Case Diagramm als grafisches
Inhaltsverzeichnis.
1.3 Gliederung
In Kapitel 2 wird zunächst eine kurze Einführung in das Thema Use Cases, Erfahrung und
andere Grundlagen gegeben. Die Anforderungen des Tools werden in Kapitel 3 spezifiziert.
Kapitel 4 stellt das Konzept, Modelle und die Architektur des Tools vor. In Kapitel 5 werden
einige aus der Literatur gesammelte Erfahrungen wiedergegeben und beschrieben, wie ein
Kritiksystem die Einhaltung überprüfen kann. Kapitel 6 soll eine kurze Anleitung des Tools
geben, sowie eine Beschreibung von Schnittstellen und Erweiterungsmöglichkeiten. Die
Arbeit endet mit einem Ausblick und einem Fazit.
7

8
2. Grundlagen
2.1 Use Cases
Ein Use Case, zu Deutsch Anwendungsfall, ist nach Cockburn [Coc01] ein Vertrag zwischen
den Stakeholdern eines Systems über sein Verhalten. Er beschreibt das Verhalten (bzw. die
Funktion) des Systems (bzw. Teile des Systems) unter verschiedenen Bedingungen und wie
das System auf Anfragen eines Stakeholders reagiert. Der Hauptakteur initiiert eine
Interaktion mit dem System um sein Ziel zu erreichen. Das System durchläuft ein Szenario
und schützt die Interessen aller Stakeholder. Use Cases beschreiben immer das äußere und
extern wahrnehmbare Systemverhalten, das innere Verhalten und die innere Struktur bleiben
unbekannt. Somit beschreiben Anwendungsfälle was ein System leisten soll und nicht wie es
etwas erreicht.
Uses Cases dienen als Technik zur Erhebung funktionaler Anforderungen und sind daher in
die Anforderungserhebungsphase einzuordnen. Sie sind somit kein Bestandteil des Entwurfs.
Da Use Cases nichts über Performance, Schnittstellen, Datenformate und Architekturen
sagen, sind bei einem Entwurf eines Systems weitere Techniken notwendig. Use Cases
erfreuen sich großer Beliebtheit, weil sie schon frühzeitig, nämlich in der Anforderungsphase
Grundlage für Diskussionen sind und mögliche Widersprüche, Fehlerszenarios, weitere Ziele
und neue Stakeholder aufdecken können.
Anwendungsfälle können als freier Text verfasst werden, durch Templates formalisiert sein,
aber auch grafische Notationen wie Flussdiagramme, Sequenzdiagramme und Petri Netze
sind denkbar. Jede Form hat natürlich ihre Vor- und Nachteile. Freie Texte können alle
Beteiligten ohne Zusatzwissen verstehen, benötigte Teilinformationen müssen jedoch
extrahiert werden. In tabellarischer Form sind die Informationen schneller zu finden und bei
einem festgelegten Template einheitlich strukturiert. Grafische Notationen, die u. a. in UML
(Unified Modeling Language) standardisiert wurden, können komplizierte Sachverhalte
übersichtlicher darstellen, setzen jedoch semantisches Wissen voraus und können daher
anders oder sogar falsch verstanden werden. Grafische Notationen enthalten oft nur wenig
Information und können das Verhalten des Systems nicht so gut beschreiben wie ein in
Textform verfasstes Szenario. Außerdem müssen Kunden die Anforderungen verstehen, um
sie validieren zu können, jedoch UML in der Regel nicht beherrschen. Daher sind Textformen
oft die bessere Wahl.
2.1.1 Use Case Diagramm
Use Case Diagramme sind in UML (Unified Modeling Language) von der Object
Management Group [OMG06] standardisiert worden und zeigen die Funktionen des Systems
und die beteiligten Stakeholder. Sie stellen einen Überblick und Abhängigkeiten gut dar.
Abläufe können jedoch nicht dargestellt werden.
Die Systemgrenzen werden durch einen Rechteck dargestellt. Die Akteure, die als
Strichmännchen dargestellt werden, stehen außerhalb des Systems und greifen auf die
Anwendungsfälle des Systems zu. Anwendungsfälle werden durch Ovale mit ihren Namen

2.1 Use Cases
gekennzeichnet. Abbildung 1 zeigt das Use Case Diagramm „Bankautomat“ mit dem ein
Kunde „Geld abheben“ und „Geld einzahlen“ kann.
Abbildung 1: Use Case Diagramm: Bankautomat
Anwendungsfälle und Akteure können spezialisiert werden, man kennzeichnet dieses durch
einen Pfeil mit nicht ausgefülltem Kopf, der auf den allgemeinen Fall zeigt. Use Cases
können andere Anwendungsfälle einbinden. Man spricht von einem Importieren, wenn der
eingeschlossene Anwendungsfall zwingend mit eingeschlossen wird und kennzeichnet dieses
durch einen gestrichelten Pfeil mit „“, der auf den importierten Fall zeigt. Von
Erweitern spricht man, wenn der Anwendungsfall optional eingeschlossen wird. Eine
Erweiterung wird durch einen gestrichelten Pfeil mit dem Attribut „“
gekennzeichnet, der vom erweiterten Fall wegzeigt.
Abbildung 2 zeigt wieder das Use Case Diagramm Bankautomat. Die Funktion „Geld
abheben“ importiert die Funktion „Kunde authentifizieren“, also der Kunde muss im Szenario
„Geld abheben“ seine PIN eingeben. Die Funktion „Geld einzahlen“ wurde um eine optionale
Funktion „Quittung drucken“ erweitert. Der Kunde kann auf Wunsch einen Einzahlungsbeleg
anfordern. Der Geschäftskunde ist ein Spezialfall des Kunden.
Abbildung 2: Use Case Diagramm: Detaillierter Bankautomat
UML sagt nichts darüber aus, zu welchem Zeitpunkt oder an welcher Stelle ein
eingeschlossener Use Case ausgeführt wird. Deswegen sind zur Beschreibung von Verhalten
zusätzliche Techniken, wie die Use Case Templates in Kapitel 2.1.2 notwendig.
9

10
2.1.2 Use Case Template
2. Grundlagen
Use Case Templates können je nach Bedarf verschieden aufgebaut sein. Sie haben mal mehr,
mal weniger Felder und können auf verschiedenen Abstraktionsniveaus geschrieben sein, je
nachdem für welchen Bereich und für welchen Zweck Use Cases erstellt werden. Als obersten
Leitsatz sollte man sich jedoch stets vor Augen halten, dass es viel wichtiger ist, ein Use Case
korrekt aufzuschreiben als ihn detailliert aufzuschreiben. Details können nachträglich
hinzugefügt werden. Ein unvollständiger bzw. fehlerhafter Use Case ist eine mögliche
Fehlerquelle, da ein solcher Use Case zu Fehlinterpretationen beim Programmierer führen
kann. Die Folge ist eine fehlerhafte Software oder, falls der Fehler vor Auslieferung entdeckt
wird, eine zeitliche Verzögerung. In beiden Fällen ist das mit zusätzlichen Kosten verbunden.
Lange und sehr detaillierte Use Cases sind zu dem oft reine Zeitverschwendung, da sie selten
gelesen werden und die kreative Freiheit des Programmierers einschränken.
Da das Use Case Template von Alistair Cockburn in der Literatur vielfach zitiert wird und
sich im Software Engineering als zweckmäßig erwiesen hat, soll hier auf dieses tabellarische
Template näher eingegangen werden. Neben einer Use Case Nummer und einem Titel, der als
kurzer, aktiver Satz formuliert wird, besteht das Use Case Template von Alistair Cockburn
[Coc06] aus folgenden sechs Abschnitten:
1. Charakteristische Informationen des Use Cases, wie Beschreibung, Ebene,
Vorbedingungen und Zusicherungen bei Erfolg bzw. Misserfolg
2. Haupt-Erfolgsszenario, in der das Szenario schrittweise im Erfolgsfall geschildert wird
3. Erweiterungsmöglichkeiten und Fehlerbehandlung des Haupt-Erfolgsszenarios
4. mögliche technische Variationen
5. weitere Informationen zum Use Case wie Priorität, Verwendungshäufigkeit, Dauer,
Referenz auf höhere bzw. eingebundene Use Cases
6. offene Punkte, die noch zu erledigen sind.
1. Charakteristische Informationen
Erläuterung:
Das Ziel des Use Cases wird ausführlicher als im Titel beschrieben.
Systemgrenze (Scope):
Das betrachtete (Teil-) System als Black Box, mit dem der Hauptakteur agiert.
Das Umfeld ist dabei so groß wie möglich zu wählen, so dass der Hauptakteur
gerade noch außerhalb des Systems steht. Ein betrachtetes Teilsystem kann
auch eine Softwarekomponente sein. Der Begriff „Systemgrenze“ ist etwas
irreführend, daher wird im Folgenden der englische Begriff „Scope“
verwendet.
Ebene:
Abstraktionsebene, auf die der Use Case geschrieben ist, beispielsweise
Zusammenfassung, Benutzerebene, Subfunktion
Vorbedingung:
Bedingungen die für den Use Case vorausgesetzt werden, z. B. „der Benutzer
ist eingeloggt“

2.1 Use Cases
Mindestgarantie:
Zusicherungen, die mindestens erfüllt werden, also auch bei einem Scheitern,
mit welchen Resultat kann man mindestens rechnen, zum Beispiel „System
protokolliert die Interaktion“
Erfolgsgarantie:
Zusicherungen bei einem erfolgreichen Durchlauf des Use Cases, insbesondere
Erfüllung des Ziels, aber auch weitergehende Aktionen wie „System veranlasst
einen Mitarbeiter, die Bestellung zusammenzustellen und zu verschicken“
Hauptakteur (Primary Actor):
Der Hauptakteur der im Use Case in Erscheinung tritt und mit dem System
agiert
Stakeholder und ihre Interessen:
Auflistung der beteiligten Stakeholder und ihre Interessen, zum Beispiel:
Kunde: Ware erwerben (Bestellung vornehmen)
Warenhaus: Geld vom Kunden einnehmen (Rechnung erstellen)
Auslöser / auslösendes Ereignis:
Der Auslöser des Use Cases, in der Regel der Hauptakteur, der ein Ziel hat, z.
B. „Kunde möchte eine Ware bestellen“, es kann aber auch ein Ereignis sein
wie „eine Bestellung ist eingegangen“ oder „es ist 3 Uhr morgens“
2. Haupt-Erfolgsszenario
In diesem Abschnitt erfolgt eine Auflistung der Schritte vom auslösenden Event bis
hin zum Erreichen des Ziels. Die Schritte sind in einfachen aktiven Sätzen zu
schreiben. Es sollte vermieden werden von „er“, „sie“ oder „es“ zu sprechen. Es sollte
klar sein, wer in einen Schritt etwas aktiv tut. Es sollten keine Beschreibung zu der
grafischen Oberfläche aufgeführt werden. Aussagen wie „Der Benutzer drückt auf
Enter“ sind tabu. Erweiterungen und Fehlerbehandlungen haben hier ebenfalls nichts
zu suchen, sie werden unter Erweiterungen angegeben. Beispiel:
Schritt Akteur Aktion
1 Kunde legt Waren in virtuellen Einkaufswagen.
2 System zeigt Inhalt des Warenkorbs an.
3 Kunde bestätigt seine Bestellung.
4 System reicht Bestellung an einen Bearbeiter weiter.
… … …
3. Erweiterungen
Es werden alle Erweiterungs- und Fehlermöglichkeiten aufgelistet, die im Haupt-
Erfolgsszenario auftreten können. Die Schrittnummer referenziert auf einen Schritt im
Erfolgsszenario. Unterschiedliche Erweiterungen zu einem Schritt werden mit
unterschiedlichen Buchstaben gekennzeichnet. Beispiel:
Schritt Bedingung Aktion
1a Ware ist nicht
vorhanden
1a1 System weist den Kunden daraufhin, dass es
zu Verzögerungen kommen wird.
11

12
2. Grundlagen
3a Kunde ist nicht 3a1 System weist den Kunden daraufhin, dass er
eingeloggt
sich einloggen muss.
3a2 Kunde loggt sich ein.
3b Kunde möchte 3b1 System listet alle Artikel im Warenkorb auf.
einen Artikel aus 3b2 Kunde entfernt nicht gewünschte Artikel.
dem Warenkorb
entfernen
3b3 System löscht die Artikel.
… … …
4. Technische Variationen
Technische Variationen sind z. B. Medien, die alternativ zu denen im Szenario
verwendet werden können. Beispiel:
Schritt Was Aktion
5 Rechnung Rechnung wird per Mail, Fax oder Post versendet
5. Weitere Informationen
Weitere Informationen sind optional und werden je nach Bedarf benötigt oder können
entfallen. Einige sind redundant und dienen nur als zusammenfassende Übersicht.
Priorität:
Die Wichtigkeit des Use Cases, z. B. unverzichtbar, wichtig oder
wünschenswert.
Performance / Durchlaufsdauer:
Wie schnell wird der Use Case durchlaufen, zum Beispiel 10 Minuten für
Eingabe der Bestellung, 24 Stunden bis zum Versand
Verwendungshäufigkeit:
Wie oft wird der Use Case aufgerufen, zum Beispiel mehrmals die Stunde,
einmal am Tag
Super Use Case:
Der allgemeine Use Case auf höherer Ebene, der diesen aufgerufen hat
Sub Use Cases:
Auflistung der Use Cases, die dieser Use Case verwendet, also die verlinkte
Use Cases auf niedriger Ebene, wie Subfunktionen
Kommunikationsweg zum Hauptakteur
Wie kann man mit dem Hauptakteur in Verbindung treten, zum Beispiel mit
Hinweisen auf der Webseite während der Bestellung oder per E-Mail nach der
Bestellung
Weitere Akteure
Auflistung weiterer Akteure, zum Beispiel der Kommissionierer, der die
Bestellung zusammenstellt

2.2 Erfahrung
Kommunikationsweg zu den weiteren Akteuren
Wie können die weiteren Akteure benachrichtigt werden, zum Beispiel per
Mail oder Ausdruck
6. Offene Punkte
Im letzten Abschnitt werden offenen Punkte aufgelistet, die noch diskutiert und gelöst
werden müssen. Dies sind z. B. Einfälle, die während des Erstellens aufgetaucht sind
und Probleme, die man nicht sofort lösen konnte. Dies könnten beispielsweise Fragen
sein, wie „Was ist, wenn der Benutzer noch kein Kunde ist?“ oder „Was wird bei
einen Systemabsturz gemacht?“
Gerne wird das Template von Cockburn nach Bedarf erweitert oder gekürzt, um ein auf das
Projekt zugeschnittenes Template zu erhalten. Die Unterteilung in 6 Abschnitte ist nicht
zwingend erforderlich, oft wird ein Use Case auch in einer einzigen Tabelle geschrieben.
Dadurch wird der Use Case kompakter, wodurch allerdings die Übersichtlichkeit leiden
könnte. Ein tabellarischer Use Case wirkt auch als eine Art Checkliste. Eine derartige
Auflistung kann leicht auf Vollständigkeit geprüft werden.
Beispiele für weitere Erweiterungen ist die Angabe eines Status, in der der Entwicklungsstand
des Use Cases angegeben wird, da so ersichtlich ist ob der Use noch im Entwurf ist, bereits
überprüft wurde oder abgeschlossen ist. Und da ein Use Case vermutlich mehrmals
modifiziert wird, ist eine Unterscheidung durch eine Versionsnummer und
Aktualisierungsdatum ratsam. Sicherlich wird ein Use Case nicht nur von einer Person
erstellt, so dass die Angabe des Erstellers und die Bearbeiter des Use Cases helfen würden,
die Verantwortlichen für eventuelle Rückfragen zu finden.
2.2 Erfahrung
Erfahrung = Beobachtung + Gefühlswert + Hypothese und Schlussfolgerung
Definition von Erfahrung [S H02]
Erfahrungen sind in Anlehnung an [SH02] Kenntnisse und Fertigkeiten, die durch Erlebnisse,
Beobachtungen, Messungen oder Experimenten erworben werden und zu einem höheren
Wissensstand führen. Mit einem eigenen Gefühl stellt man heraus, was an der Beobachtung
bemerkenswert ist. Man bewertet und klassifiziert sie beispielsweise in positive und negative
(Lebens-) Erfahrung. Mit der Aufstellung einer Hypothese und der Schlussfolgerung zieht
man eine Konsequenz für die Zukunft. Gesammelte Erfahrungen helfen bei der Abschätzung
der Vor- und Nachteile von Lösungsmöglichkeiten und steuern erheblich zur
Entscheidungsfindung bei. Erfahrungen helfen Erfolge zu wiederholen und Fehler zu
vermeiden und haben für das Software Engineering den Vorteil, schneller, kostengünstiger
und qualitativ bessere Software herstellen zu können.
13

14
2.3 Wissen
2. Grundlagen
Während Erfahrung nur auf praktisch erworbene Kenntnisse beruht, ist Wissen „die
Gesamtheit der Kenntnisse und Fähigkeiten, die Individuen zur Lösung von Problemen
einsetzen“ ([TK98]), also auch die, die beispielsweise durch Lehrbücher erworben werden.
Wissen schließt also neben eigene Erfahrungen auch übernommene Erfahrung anderer ein,
aber auch erlernte Informationen, Fakten und Regeln. Wissen sind sicherere Informationen
und somit das Gegenteil von Vermutungen oder Glauben ([Wik06]).
2.4 Erfahrungsnutzung
Um Erfahrungen nutzen zu können, muss sie zunächst erfasst werden. Erfahrungen werden
gesammelt, analysiert und aufbereitet. Man versucht die Erfahrungen zu abstrahieren und zu
generalisieren, so dass die Erfahrungen auf möglichst viele Probleme angewendet werden
können. Die Erfahrungen müssen in geeigneter Weise aufbewahrt werden. Dies geschieht in
einer so genannten Experience Base [BCR94], eine Ansammlung der Erfahrung, die in der
einfachsten Form ein Forum oder eine FAQ sein kann. Die dort abgelegten Erfahrungen
können nun für neue Projekte genutzt werden. Dazu müssen verschiedene Mechanismen, wie
zum Beispiel eine Suche, zur Verfügung gestellt werden. Neu gewonnene Erfahrungen
müssen wieder zurück in die Experience Base fließen. Dies sind zum einen völlig neue
Erfahrungen, zum anderen aber auch die Erfahrung über die Nutzung dieser Erfahrung, also
eine Art Feedback. Durch diesen Zyklus, der auch Erfahrungskreislauf genannt wird
(Abbildung 3), ergibt sich eine stetige Verbesserung der Erfahrung. Mit dem Sammeln,
Aufbereiten, Formalisieren, Generalisieren, Analysieren, Speichern, Suchen und Kombinieren
der Erfahrungen befasst sich das Modell des Experience Factorys ([BCR94]). Sie hat als Ziel,
Projekte in der Planung und der Ausführung durch gesammelte Erfahrungen aus anderen
Projekten zu unterstützen.
Abbildung 3: Er fahrungskreislauf, vgl. [Sch00] und [Lir04]
2.5 Weitergabe von Wissen und Erfahrung
Wissen und Erfahrungen können weitergegeben werden. [NT95] unterscheidet, wie in
Abbildung 4 verdeutlicht, zwei Zustände von Wissen. Das implizite Wissen ist das Wissen,
das im Gedächtnis verankert ist, das explizite Wissen ist das aufgeschriebene Wissen. Wird
implizites Wissen mündlich weitergegeben, so spricht man von Sozialisation. Das

2.6 Wissensbasierte Systeme
Aufschreiben und digitale Erfassen von implizitem Wissen wird als Externalisierung
bezeichnet. Explizites Wissen kann zu neuen explizitem Wissen kombiniert werden. Wenn
eine Person explizites Wissen aufnimmt, so spricht man von Internalisierung. Er wandelt
explizites Wissen wieder in implizites Wissen um. Die Aufnahme von Wissen durch
Sozialisation und Internalisierung kann als Lernen bezeichnet werden.
In dieser Arbeit wird ein Konzept erstellt, um den Schritt der Internalisierung zu unterstützen,
also wie ein Entwickler explizites Wissen aufnehmen und nutzen kann um bessere Use Cases
zu erstellen. Ein Entwickler kann nicht immer an alles denken und an dieser Stelle soll ein
Tool ihn bei der Arbeit unterstützen. Dabei soll natürlich auch ein Lernprozess beim
Entwickler ausgelöst werden. Der Entwickler soll seine Fähigkeiten und Kompetenzen
erweitern. Um den Erfahrungskreislauf zu schließen, soll auch der Schritt der
Externalisierung unterstützt werden, so dass die Erfahrungen des Entwicklers nicht verloren
gehen und auch für andere archiviert werden.
2.6 Wissensbasierte Systeme
Abbildung 4: Erfahrungsweitergabe, vgl. [Buc05]
Wissensbasierte Systeme sind intelligente Systeme. Sie bestehen aus einer Wissensbasis, in
der Fakten und Regeln abgelegt sind, und einem Inferenzmechanismus, welche Anfragen und
Fakten mit Hilfe der Regeln versucht zu kombinieren, um zu einer Aussage zu kommen.
Wissensbasierte Systeme können selbständig Probleme lösen und Entscheidungen treffen. Sie
finden u. a. bei der automatischen Auswertung von Bildern oder in der Medizin zur
Unterstützung bei Diagnosen Anwendung.
15

16
2.7 Benutzer-Unterstützungssysteme
2. Grundlagen
Benutzer-Unterstützungssysteme sollen den Benutzer im Umgang mit einem Programm
unterstützen. Balzer unterscheidet dabei in [Bal01] vier Gruppen von Systemen:
• Hilfesysteme, die den Benutzer bei Problemen helfen
• Tutorsysteme, die den Benutzer interaktiv in ein System einarbeiten
• Beratungssysteme, die den Benutzer bei der Lösungsfindung mit Ratschlägen
unterstützen und
• Assistenzsysteme, die schwerfällige Teilaufgaben selbst übernehmen.
Bauer und Schwab haben in [BS88] Hilfesysteme klassifiziert. So kann eine Hilfe statisch
bzw. dynamisch sein. Dynamische Hilfe berücksichtigt den aktuellen Kontext, statische nicht.
Hilfesysteme können uniforme oder individuelle Hilfe geben. Uniforme Hilfssysteme geben
für jeden Benutzer dieselbe Hilfe, wo hingegen bei einer individuellen Hilfe der Kenntnis-
und Erfahrungsstand des Benutzers im Umgang mit dem Programm berücksichtigt werden.
Schließlich kann eine Hilfe passiv oder aktiv erfolgen. Passive Hilfe muss vom Benutzer
explizit angefordert werden. Dies kann er aber nur tun, wenn er selbst ein Problem erkannt hat
bzw. Hilfe benötigt. Das hat zu Folge, dass nur etwa 40 Prozent des Funktionsumfangs eines
Systems tatsächlich genutzt wird [FLS85]. Ein aktives Hilfesystem erkennt selbständig
Probleme und gibt automatisch Hilfestellungen. Erkennt das System eine Arbeitserleichterung
für den Benutzer, so schlägt das System dem Benutzer die Erleichterung vor. Diese
Klassifizierung kann leicht auf Tutor-, Beratungs- und Assistenzsysteme angewandt werden.
2.8 Kritik
Kritik ist eine prüfende Beurteilung, die durch begründete Wertschätzungen untermauert
wird. Man unterscheidet zwischen positiver Kritik, also ein Lob, und negativer Kritik, ein
Tadel. Kritik kann konstruktiv sein, wenn eine Hinterfragung mit Änderungs- bzw.
Verbesserungsvorschlägen stattfindet oder destruktiv, wenn sie weder begründet noch zu
einer Verbesserung beisteuert. Eine destruktive Kritik ist oft abwertend und beleidigend
gemeint, wo hingegen eine konstruktive Kritik zur Verbesserung beitragen soll, jedoch als
negativ bzw. destruktiv verstanden werden kann. Eine Kritik dient der Erkennung von
Schwächen und soll sie minimieren bzw. beseitigen. Schwächen könnten beispielsweise die
Missachtung von Standards und Normen sein oder der Verstoß gegen gesetzliche
Bestimmungen oder Naturgesetzen. Eine Kritik kann auch durch eine Erfahrung begründet
werden, wenn zum Beispiel eine aktuelle Konfiguration nach gemachten Erfahrungen zu
Problemen führt. Idealerweise wird eine Kritik auch geäußert, wenn eine bessere oder
mögliche bessere Alternative bekannt ist. Kritiken sollten stets begründet werden, da sie sonst
nicht verstanden und missachtet werden könnten.
2.9 Domain-Oriented Design Environments (DODEs)
Eine besondere Form von wissensbasierten Systemen stellen Domänenorientierte
Entwurfsumgebungen dar. Sie sind wissensbasierte Kritik-, Hilfs-, Tutor-, Beratungs- und
Assistenzsystem zugleich und geben dynamische, individuelle und aktive Hilfe. Domain-

2.9 Domain-Oriented Design Environments (DODEs)
Oriented Design Environments reduzieren den konzeptionellen Abstand zwischen der
Domäne und das Computersystem und unterstützen den Designer, der sich nicht mit
verschiedenen Tools zur Lösung eines Problems beschäftigen muss, sondern sich voll und
ganz auf seine Domäne und das Problem selbst konzentrieren und eine optimale Lösung
finden kann. Seine Arbeit wird mit zum Zeitpunkt relevanten Informationen an geeigneten
Stellen unterstützt. Das System kritisiert die Arbeit des Entwicklers durch Hinweise bzw.
Fehlermeldungen und steuert zur Findung einer optimalen Lösung bei, indem es alternative
Lösungen vorschlägt. Eventuelle Fehler, die u. a. durch Wissenslücken, Unachtsamkeit oder
Neuerungen entstehen, können so frühzeitig beseitigt werden. Die Kritik kann auf Wunsch
des Domaindesigners angefordert werden oder durch das System automatisch nachdem ein
mögliches Problem erkannt wurde. Die Schwierigkeit besteht darin, dass im ersten Fall eine
Kritik zu spät oder sogar gar nicht angezeigt wird, und im zweiten Fall, dass sich
überhebliche und vermeintliche Fehlermeldungen störend auswirken könnten.
Ein Beispiel für DODEs ist Framer [LF90], ein Designer für Dialogfenster. Ein GUI-Designer
soll sich auf seine Aufgabe konzentrieren, nämlich Benutzeroberflächen zu entwerfen und
muss sich nicht damit auseinandersetzen, wie beispielsweise ein Menu in Quellcode
programmiert werden muss. Dazu werden zum einen fertige Bauteile zur Verfügung gestellt,
zum anderem wird der Entwurf wissensbasiert unterstützt, indem das Programm Elemente
vorschlägt und Kritiken äußert, wobei natürlich der Kontext berücksichtigt wird.
Ein weiteres Beispiel ist ein Küchenplaner wie JANUS [FMM89], der neben
Allgemeinwissen auch Sicherheitsstandards und Ergonomität berücksichtigt. Wenn zum
Beispiel ein Küchendesigner den Kühlschrank neben den Ofen stellt oder die Laufweite
zwischen Kühlschrank, Herd und Waschbecken zu groß wählt, wird der Planer darauf
aufmerksam gemacht und das System schlägt Verbesserungen vor. JANUS hilft durch Fragen
bei der Erhebung der Anforderungen und vergleicht diese mit dem aktuellen Entwurfsstand.
Domänenorientierte Entwurfsumgebungen stellen eine Erweiterung von wissensbasierten
Systemen dar. Fischer betont in [Fis94], dass der Computer nie den Menschen ersetzen kann,
da der Mensch gerne Dinge selbst macht und vor allem lieber selbst die Entscheidungen trifft.
Daher sind Domänenorientierte Entwurfsumgebungen Systeme, die den Menschen nicht
ersetzen, sondern in seiner Arbeit als Designer unterstützen, in dem sie den Benutzer mit
kontextsensitiver Hilfe dient, als Tutor in die Arbeit mit dem System zur Seite steht und
fehlende Kenntnisse vermittelt, als Berater Kritik und Ratschläge äußert und als Assistent
Aufgaben übernimmt, die er ungern macht (wie Programme in Assembler zu verfassen).
Während wissensbasierte Systeme von Programmierern erweitert werden, soll in
Domänenorientierten Entwurfsumgebungen der Designer selbst neues Wissen einfügen und
anderen zu Verfügung stellen. Ein wesentlicher Unterschied ist der unterschiedliche
Lösungsansatz. Während in wissensbasierten Systemen ein Top-Down-Entwurf verfolgt wird,
verfolgt man bei Domänenorientierten Entwurfsumgebungen einen Bottom-Up-Entwurf, ein
so genannter „Design by Composition“. Dabei werden fertige Entwürfe, die aus einer
ähnlichen Spezifikation hervorgingen den aktuellen Bedürfnissen angepasst. Designer haben
schon Erfahrungen mit alten Entwürfen gesammelt und verwenden lieber diese noch mal als
die Entscheidungen eines wissensbasierten Systems zu übernehmen.
Fischer schlägt in [Fis94] eine domainunabhängige Architektur vor, die aus folgenden
Komponenten bestehen:
17

18
2. Grundlagen
• Konstruktionsumgebung, in der die Artefakte entwickelt und entworfen werden,
• Argumentationssystem, in der Streitpunkte angesprochen werden, Antworten geliefert
werden und die Argumentation stattfindet
• Katalog, das fertige Vorlagen zur Widerverwendung anbietet
• Spezifikationskomponente, in der die Anforderungen des Kunden abgelegt sind
• Simulationskomponente, die den Designer ermöglicht, verschiedene Varianten zu
testen und zu simulieren
Abbildung 5: Domainunabhängige Architektur, vgl. [Fis94]
Ein Katalog Explorer soll Benutzern die Suche im Katalog vereinfachen. Dazu müssen
verschiedene Mechanismen angeboten werden, die einfache Anfragen, zum Beispiel durch
vorbereitete Datenbankanfragen, ermöglichen. Ein Argumentationserläuteter soll Kritiken
begründen und Verbesserungsvorschläge erläutern und durch Beispiele aus dem Katalog
untermauern. Dies ist besonders wichtig, da ein Designer in der Regel keine unerläuterte
Kritik vertraut. Oft gibt es keine klare Antwort, so müssen zum Beispiel durch eine
Auflistung von Pro und Contra zur Entscheidungsfindung geholfen werden. Der
Konstruktionsanalyser und Spezifikationsüberprüfer ist das Kritiksystem, das laufend die
aktuelle Arbeit des Designers untersucht und kritisiert und dabei sicherstellt, dass der
Benutzer seine Arbeit nicht nur richtig, sondern auch gut macht. Dabei soll er den Zugriff auf
die Argumentations- bzw. Spezifikationskomponente bereitstellen.
Fischers Arbeit wird jedoch u. a. von Ning [Nin94] kritisiert. So sei seine Arbeit nichts
Neues. Fischer fordere lediglich die Entwicklung von Domänenorientierten
Entwurfsumgebungen, sage jedoch nur wenig darüber aus, wie diese zu konstruieren sind.
Bisher seien DODE nur für generische Domänen auf niedrigen Level entwickelt wurden.
Ning vermutet, dass es noch nicht mal Sinn mache, DODE auf kompliziertere Domäne
anzuwenden, da sie teuer seien und nicht zum Erfolg führten.
Sutcliffe meint in [Sut94], dass noch einiges an Arbeit zu leisten sei. Fischers Arbeit hätte
viele offene Fragen unbeantwortet gelassen. Eine wichtige Frage ist, ob ein in einer
Domainorientierten Umgebung entwickeltes Artefakt wirklich besser ist und ob das Ergebnis
zuverlässig funktioniert und wartbar ist. Außerdem vermutet Sutcliffe, dass es keine generelle
Architektur gäbe, sondern dass DODE für jede Domäne angepasst oder neu gebaut werden
müsse.

2.10 SER Prozessmodell
Trotz der Warnung, dass eine Domänorientierte Entwurfsumgebung schwer zu realisieren sei
und eventuell sogar nicht zum Erfolg führe, soll in dieser Arbeit eine solche Umgebung
entworfen und umgesetzt werden, um die vielen Gesichtspunke, einer solchen
Entwurfsumgebung zu demonstrieren.
2.10 SER Prozessmodell
Das SER Prozessmodell von Gerhard Fischer ([Fis94]) beschreibt die soziale und technische
Interaktion bei der Nutzung von Domänenorientierten Entwurfsumgebungen. Im ersten
Schritt muss eine Saat ausgelegt werden (Seeding). In diesen Schritt tauschen Entwickler und
Domaindesigner Ideen und Erfahrungen aus und halten sie in der Experience Base fest. Es
folgt die Phase der „Evolutionary Growth“, in der die Samen bildlich betrachtet keimen und
anfangen zu wachsen. Die Erfahrungen werden genutzt, erweisen sich als nützlich oder
weniger hilfreich und es werden durch die Nutzung der Erfahrungen neue Erfahrungen
gemacht und gesammelt. Diese neuen Erfahrungen müssen nun in der Reflexionsphase
aufbereitet werden, mit den bestehenden Erfahrungen in der Experience Base kombiniert
werden und dort sortiert wieder abgelegt werden. Diese Phase wird bildlich betrachtet als neu
aussähen (Reseeding) bezeichnet. Es folgt die weitere Nutzung dieser erweiterten Erfahrungen
in der Experience Base, wo erneut weitere Erfahrungen gemacht werden. Ein so genannter
Umgebungsentwickler ist für das Verwalten der Erfahrungen zuständig. Er muss von Zeit zu
Zeit die neuen Erfahrungen aufbereiten und neu organisieren.
Abbildung 6: SER Prozessmodell, [Fis94]
19

20
3. Anforderungen
Anforderungen sind Aussagen über die zu erfüllenden Eigenschaften und zu erbringende
Leistung eines Produktes. Sie definieren die Erwartungen und Wünsche eines Kunden an das
zu entwickelnde System. Im Folgenden sollen diese Erwartungen beschrieben werden.
3.1 Zielbestimmung
Es ist ein Tool zu entwickeln, mit dem ein Benutzer qualitativ hochwertige Use Cases
erstellen kann. Dazu soll das Tool den Benutzer durch Hinweise und Warnungen unterstützen.
Erfahrungen sollen leicht zugänglich gemacht werden, dürfen den Benutzer bei seiner Arbeit
jedoch nicht stören oder behindern. Es sollten stets nur relevante Erfahrungen angezeigt
werden, die nach ihrer Wichtigkeit sortiert werden. Die Erfahrungen müssen auf den
individuellen Benutzer anpassbar sein und müssen erweitert werden können. Die
Dateneingabe soll über ein anpassbares Template erfolgen.
Das Tool soll zunächst aus Zeitgründen als Standalone-Applikation konzipiert werden, so
dass der Benutzer auch unterwegs ohne Netzzugang arbeiten kann. In einer späteren
Entwicklung könnte das Tool um eine Server-Komponente erweitert werden, die eine
Projektverwaltung und Versionisierung übernimmt, so dass mehrere Benutzer gleichzeitig an
einem Projekt arbeiten können. Es ist daher darauf zu achten, dass diese Erweiterung ohne
großen Aufwand erfolgen kann. Der Benutzer soll bestehende Erfahrungen in seiner
Erfahrungsbasis erweitern können und neue hinzufügen können. Der Austausch mit anderen
Benutzern soll zunächst manuell erfolgen, könnte aber in einer späteren Entwicklung
ebenfalls von einer Serverkomponente übernommen werden.
Die grafische Benutzeroberfläche ist auf einen deutschsprachigen Personenkreis auszulegen.
Es sollte jedoch bei der Planung darauf geachtet werden, dass die Applikation und der
Erfahrungsschatz leicht um weitere Sprachen erweitert werden kann. Dies kann z. B. dadurch
erreicht werden, dass eine externe Sprachdatei angelegt wird. Des Weiteren soll ein Use Case
Diagramm als grafische Übersicht automatisch generiert werden (siehe Kapitel 4.8).
3.2 Systemvorrausetzungen
Das Tool soll Plattform unabhängig sein. Auf den Rechnern wird lediglich Java 1.5
vorausgesetzt. Alle benötigen Komponenten müssen mitgelieft werden.
3.3 Benutzertypen
Das Tool wird von Benutzern mit unterschiedlichen Kenntnissen verwendet. Daher soll der
Benutzer durch aktive Hilfe geführt werden. Den Benutzern soll ein gewohntes tabellarisches
Use Case Formular angeboten werden. Der Umstieg von bisher verwendeten Standard-
Textverarbeitungsprogrammen soll leicht fallen. Der Benutzer soll Projekte und Use Cases
anlegen, bearbeiten und löschen können, sowie bestimmte Erfahrungen deaktivieren können,

3.4 Funktionale Anforderungen
so dass sie in seiner Umgebung nicht mehr angezeigt werden. Der Benutzer muss auch die
Möglichkeit haben, seine Erfahrungen in das System einzugeben.
3.4 Funktionale Anforderungen
Für die Anforderungsanalyse dieser Masterarbeit wird das Use Case Template von Cockburn
gekürzt verwendet und in einer einzelnen Tabelle komprimiert (siehe Anhang A). Auf eine
längere Erläuterung wird verzichtet, da die Titel der Use Cases klar sein sollten. Technische
Variationen sind keine bekannt und daher wird auf die explizite Auflistung verzichtet. Ebenso
soll auf eine Auflistung der Super- bzw. Sub Use Cases verzichtet werden, da diese
Informationen redundant sind und lediglich der Übersicht dient. Da die Akteure
ausschließlich mit dem System kommunizieren sollte der direkte Kommunikationsweg
ebenfalls klar sein.
Im Szenario wird der Akteur durch eine gesonderte Spalte hervorgehoben. So wird zum einen
erzwungen, stets einen Akteur anzugeben, wodurch klar gestellt werden kann, wer etwas tut,
zum anderen legt es den Satzaufbau fest. Da der Akteur am Anfang des Satzes steht, ist es
wesentlich schwieriger einen Passivsatz zu konstruieren.
Der Scope sollte wie in Kapitel 2.1.2 beschrieben so gewählt werden, dass der Hauptakteur
gerade noch außerhalb dieses Teilsystems steht. Es wurde hier als Scope die Komponenten
des DODE Systems gewählt. Diese Unterteilung stellt sich als zweckmäßig heraus, da der
Benutzer mit diesen Komponenten kommuniziert.
Die Projektverwaltung ist für die Verwaltung des Projekts und die dazugehörigen Use Cases
zuständig. Der Benutzer kann über ihn neue Projekte anlegen, sie speichern und auch wieder
laden. Es können Use Cases hinzugefügt werden und falls ein Use Case nicht mehr benötigt
wird, soll dieser auch wieder gelöscht werden können. Da Use Cases in der Regel weiter
verarbeitet werden, sollten sie auch in andere Dateiformate exportiert werden können. So soll
es dem Benutzer möglicht werden, erstellte Use Cases in seine Projektplanung zu
übernehmen. Des Weiteren soll auch ein Kopieren der Use Cases in die Zwischenablage
möglich sein, so dass der Benutzer die Daten direkt übernehmen kann.
21

22
Abbildung 7: Use Case Diagramm: Projektverwaltung
3. Anforderungen
Die Konstruktionskomponente ist für die eigentliche Bearbeitung der Use Cases zuständig.
Der Benutzer kann die angelegten Use Cases bearbeiten. Dazu gehört die Eingabe von
Texten, aber auch das Einfügen neuer Schritte, die Verlinkung von Use Cases, das Erweitern
von Schritten, uvm. Die Anzeigemöglichkeit der letzten Änderungen könnte sich als sehr
nützlich erweisen.
Abbildung 8: Use Case Diagramm: Konstruktion
Die Argumentationskomponente stellt neben der Erstellung der Use Cases eine Kernfunktion
des Editors dar. Dabei stellt ein Assistent laufend den Kontext fest und zeigt entsprechend
relevante Hilfestellungen an. Die aktuelle Planung wird ebenfalls laufend analysiert und sollte
der Assistent mögliche Fehler finden, zeigt er diese dem Benutzer an geeignete Stellen an.

3.4 Funktionale Anforderungen
Der Benutzer kann diese Erfahrungen dann lesen. Sollte er mehr Informationen benötigen,
kann er diese anfragen. Er kann eine bestehende Erfahrung erweitern, wenn er bspw.
Erfahrung bei der Nutzung der Erfahrung gemacht, oder sie kommentieren, wenn er anderer
Ansicht ist oder er Ausnahmen kennt. Das Anlegen neuer Erfahrungen und das Ignorieren der
Erfahrungen, die ihm nicht weiter helfen, sind ebenfalls möglich.
Abbildung 9: Use Case Diagramm: Argumentation
In der Spezifikationskomponente erfolgt die Bearbeitung des Templates. Dazu gehört das
hinzufügen neuer Attribute, aber auch das Löschen nicht benötigter Attribute.
Bestandsattribute sollen nur deaktiviert bzw. wieder aktiviert werden können.
Abbildung 10: Use Case Diagramm: Spezifikation
23

24
3. Anforderungen
Die Wiederverwendung von fertigen Use Cases aus früheren Projekten soll nicht unterstützt
werden. Zwar stellt dieses eine nützliche Arbeitserleichterung dar, es wird jedoch bezweifelt,
gute Use Cases durch diese Art zu schreiben. Übernommene Use Cases müssten kontrolliert
und angepasst werden, der Benutzer wird diese Kontrolle vermutlich unterlassen, da er seine
Arbeit in der Regel vertraut. So können sich Fehler einschleichen und eine gute Planung ist
nicht mehr gegeben.
3.5 Qualitätsanforderungen
Qualitätsanforderungen sind ein nicht zu vernachlässigender Bestandteil von Anforderungen.
Es muss definiert werden, welche Qualitätsaspekte berücksichtigt werden müssen, welche
besonders wichtig sind und wie sie erreicht werden können. Im Folgenden soll näher auf diese
Anforderungen eingegangen werden.
Merkmal sehr gut gut normal nicht relevant
Benutzbarkeit
Bedienbarkeit x
Erlernbarkeit x
Verständlichkeit x
Funktionalität
Effizienz x
Fehlertoleranz x
Korrektheit x
Sicherheit x
Zuverlässigkeit x
Übertragbarkeit
Installierbarkeit x
Portabilität x
Wartbarkeit
Änderbarkeit x
Erweiterbarkeit x
Modifizierbarkeit x
Wiederverwendbarkeit x
3.5.1 Benutzbarkeit (Usability)
Die Benutzbarkeit (engl. Usability), stellt die größte und wichtigste Herausforderung dar. Das
Tool sollte unbedingt selbsterklärend sein. Ein neuer Benutzer sollte das Tool auf Anhieb
ohne große Einführung benutzen können. Es ist daher sinnvoll, das Tool auf bekannte
Anwendungen auszulegen, so dass die Umgebung nicht fremd erscheint. Es wird
angenommen, dass die Softwareingenieure die das Tool nutzen sollen, auch mit Eclipse
[Ecl06] arbeiten und Kenntnisse in Word [Msw02] besitzen. Ferner kann die Selbsterklärung

3.5 Qualitätsanforderungen
dadurch erreicht werden, dass das Use Case Template eine Formularstruktur aufweist. Die
Verwendung des Tools muss für den Benutzer einen Vorteil bringen. Ein Vorteil ist natürlich
die Erfahrung, aber die Verwendung des Tools darf nicht zusätzliche Arbeit hervorrufen.
Vielmehr muss der Benutzer mit dem Tool effektiv arbeiten können und Zeit einsparen. Ein
Tool, das zusätzlichen Aufwand verursacht oder zur Lösung des Problems mehr Zeit benötigt,
wird ungern oder gar nicht eingesetzt.
Hinweise und Tipps müssen leicht zugänglich sein, damit sie auch tatsächlich verwendet
werden. Allerdings dürfen sie auch nicht die Arbeit stören. Dies kann zum einem dadurch
erreicht werden, dass auch tatsächlich relevante Informationen angezeigt werden, zum
anderen dadurch, dass die Hilfe deaktiviert werden kann, wenn sie nicht benötigt wird oder
stört. Die Anzeige von Erfahrung sollte die Arbeit nicht behindern, daher ist von Fenstern die
das Formular überdecken abzusehen. Vorschläge und Warnungen müssen nachvollziehbar
sein und auf Wunsch näher erklärt werden. Des Weiteren sollte der Benutzer nach benötigten
Funktionen nicht lange suchen müssen, sondern sie intuitiv finden können. Die Usability soll
dadurch gewährleistet werden, dass mehrere Benutzer das Tool probeweise verwenden sollen,
um Use Cases zu erstellen. Dabei soll auch nach der subjektiven Empfindung gefragt werden,
ob man mit dem Tool tatsächlich weniger Zeit zur Erstellung der Use Cases benötigt als mit
Word. Interessant wäre auch, ob der Eindruck entsteht, bessere Use Cases erstellt zu haben.
Das Ergebnis dazu ist im Anhang D zu finden.
3.5.2 Funktionalität
Das Tool darf nicht unnötig Ressourcen verbrauchen. Daher ist es sinnvoll darauf zu achten,
dass beispielsweise Berechnungen und Überprüfungen nur dann ausgeführt werden, wenn
sich eine Änderung ergeben hat und nach Möglichkeit soll die Berechnung nur für die
Änderung und seine Folgen erfolgen. Antwortzeiten können durch optimierten Code und
Vorhalten der Daten im Arbeitsspeicher möglichst kurz gehalten werden, da Plattenzugriffe
vermieden werden. Da Dateianhänge nur unnötig Arbeitsspeicher belegen, sollten diese stets
auf der Festplatte ausgelagert bleiben.
Zwar sollen abgespeicherte Daten nicht manuell geändert werden, dennoch wird dieses von
erfahrenen Benutzern immer wieder gewünscht. Es sollte daher darauf geachtet werden, dass
die Dateien fehlerhaft sein könnten. Die Laderoutine sollte nach Möglichkeit Fehler
übergehen oder selbst korrigieren können.
Eine Verschlüsselung der Daten ist nicht geplant. Der Benutzer kann bei Bedarf geheime
Geschäftsdaten durch externe Programme wie GnuPGP (siehe [Gnu06]) vor ungewünschten
Zugriffen schützen.
Benutzer sollten sich auf das System verlassen können. Operationen sollten korrekt und
vollständig ausgeführt werden, da das System sonst wenig oder keine Akzeptanz erfahren
wird. Das System sollte stets auf Konsistenz der Daten achten, insbesondere dürfen keine
fehlerhaften Referenzen oder unschlüssige Daten vorkommen. Gespeicherte Projekte müssen
korrekt und vollständig wieder geladen werden können, Informationen dürfen nicht verloren
gehen. Die Zuverlässigkeit kann unter anderem durch Schreiben von Tests und die
grundsätzliche Instanzierung von Variablen zur Vermeidung von Nullpointern erhöht werden.
25

26
3.5.3 Übertragbarkeit
3. Anforderungen
Es muss möglich sein, dass Tool auf unterschiedlichen Systemen einzusetzen. Da das System
in Java geschrieben wird, dürfte die Plattformunabhängigkeit kein Problem darstellen. Die
Hardware spielt auf Grund der Java Runtime Environment eine untergeordnete Rolle. Sofern
der Rechner über ausreichend Festplattenplatz, Arbeitsspeicher und Rechenleistung verfügt,
dürfen keine Probleme auftreten. Die Portabilität soll durch ein Testen auf unterschiedlichen
Windows und Linux Rechnern erfolgen. Das Tool muss sich ohne manuelle Konfiguration
selbständig installieren können.
3.5.4 Wartbarkeit
Da eine Software oft erweitert oder abgeändert wird, ist es ebenfalls sehr wichtig, dass das
System leicht wartbar ist. Dieses kann man zum einen durch einfachen, einheitlichen,
dokumentierten und testbaren Code erreichen, zum anderen durch einen modulartigen
Aufbau. Durch einen modularen Aufbau können Teile komplett ausgetauscht werden, ohne
Änderungen in anderen Komponenten durchführen zu müssen. Die Einfachheit des Codes soll
u. a. durch ein Eclipse Plugin [Met06] garantiert werden, das die zyklische Komplexität nach
McCabe berechnet. Nicht verwendete Quellcode-Passagen sollen nach Möglichkeit noch vor
Auslieferung entfernt werden.
Besonders wichtig ist die Erweiterbarkeit des Erfahrungsschatzes. So muss der Benutzer
laufend und problemlos neue Erfahrungen einfügen und bestehende Erfahrung ergänzen
können.
Das Use Case Template muss an die Bedürfnisse angepasst werden können. Es ist
erforderlich, dass das Template geändert werden kann, also dass nicht benötigte
Formularelemente deaktiviert und zusätzlich benötigte Formularelemente hinzugefügt werden
können. Dies soll über die grafische Oberfläche erfolgen.

4. Konzept
4.1 Klassifizierung von Erfahrung
Erfahrungen in Bezug auf Use Case Erstellungen sind Hilfestellungen, die den Benutzer dabei
unterstützen sollen, gute Use Cases zu erstellen. Diese Erfahrungen wurden von Personen
gesammelt und aufgeschrieben (Externalisierung, s. Kapitel 2.5) und stellen die
Erfahrungsbasis des Tools dar. Dieses explizite Wissen kann man unterteilen in Hilfe und
Kritik.
Hilfe sind Hinweise und Tipps, die den Benutzer vor seiner Eingabe sagen, was an einer
aktuellen Stelle eingegeben werden muss und was dabei zu beachten ist. Im Falle des
Szenarios könnte der Hinweis lauten, dass ein Szenario aus drei bis neun Schritten bestehen
sollte.
Kritiken können erst geäußert werden, nachdem eine Eingabe erfolgt ist. Das Kritiksystem
gibt Warnungen, wenn etwas nicht optimal ist, z. B. wenn ein Szenario weniger als drei
Schritte hat, und zeigt einen Fehler an, wenn ein gravierender Mangel vorliegt. Ein Fehler
könnte beispielsweise ein Szenario ohne Schritte sein, ein Use Case ohne Titel oder eine
Verlinkung auf ein nicht existierenden Use Case. Diese Kritiken müssen auch verdeutlichen,
was weniger gut ist und wie es erfahrungsgemäß besser wäre. Kritiken werden weiter
unterteilt, da eine Warnung nicht ein Fehler darstellen muss.
Erfahrung
Hilfe Kritik
Abbildung 11: Klassifizierung von Erfahrung
4.2 Bearbeitung eines Use Cases
Warnung Fehler
Die Bearbeitung eines Use Cases erfolgt in einen Kreislauf und einer ständigen Interaktion
mit dem System. Sobald der Benutzer ein Attribut auswählt, ermittelt das Tool den Kontext
und sucht daraufhin die relevanten Erfahrungen aus seiner Erfahrungsbasis heraus.
Im Falle einer Hilfe kann sie allgemein für ein Projekt gelten, für die Bearbeitung eines Use
Cases oder für die Bearbeitung eines Attributes. Wird also ein Projekt angelegt, sind nur
27

28
4. Konzept
Erfahrungen relevant, die allgemein bei einen Projekt gelten. Sobald der Benutzer einen Use
Case öffnet, sind die Hilfen interessant, die bei der Bearbeitung eines Use Case relevant sind.
Wenn der Benutzer ein Attribut bearbeitet, möchte er Hilfe zu diesem Attribut haben. Im
Falle einer Hilfe ist der Kontext also die Ebene (Projekt, Use Case, Attribut), auf der sich der
Benutzer befindet.
Diese ermittelten Erfahrungen sortiert das System nach der Relevanz und zeigt sie dem
Benutzer an. Der Benutzer liest die Erfahrung(en) und macht daraufhin seine Eingabe. Wenn
der Benutzer das nächste Attribut zur Bearbeitung auswählt, wird der neue Kontext ermittelt
und so schließt sich der Kreislauf. Der Benutzer und das System interagieren laufend
miteinander. Das System beliefert den Benutzer ständig mit aktuellen und relevanten
Hilfestellungen und der Benutzer macht nach Aufnahme dieser Hilfe seine Eingabe.
Abbildung 12: Use Case Bearbeitung
Sollte das System etwas an der Arbeit des Benutzers zu kritisieren haben, z. B. weil er mehr
als 9 Schritte in einen Szenario hat, so kann das System dem Benutzer auf diesem Wege auch
warnen. Eine Kritik kann für das Projekt gelten, einen Use Case, einen Use Case Attribut oder
einen Teil des Attributs, z. B. einen Schritt. Während bei einer Hilfe nur die Ebene zählt, zählt
bei einer Kritik auch die Objekte selbst auf der jeweiligen Ebene. Eine Hilfe bezieht sich
allgemein auf eine Objektgruppe, z. B. alle Attribute mit den Namen Szenario, da sie
gleichermaßen für alle Fälle interessant sind. Eine Kritik bezieht sich auf ein einzelnes
Objekt, das kritisiert wird, z. B. ein Szenario eines Use Cases. Die Kritik ist für ein Szenario
in einen anderen Use Case nicht gültig und somit nicht relevant.
Dieser Unterschied hat zu Folge, dass die Bestimmung der Relevanz einer Hilfe und der einer
Kritik auf unterschiedliche Weise erfolgt. Wie dies genau geschieht, ist im Abschnitt 6 dieses
Kapitels beschrieben.
Eine Kritik sollte natürlich im Assistenten nur dann erscheinen, wenn der Benutzer das
fehlerhafte Attribut ausgewählt hat bzw. bearbeitet, da es sonst nicht relevant ist. Der
Benutzer kann dann durch Befolgen eines der vorgeschlagenen Lösungsmöglichkeiten den
Fehler beheben.

4.3 Anzeigen von Erfahrung, Kritik, Hinweisen, Tipps
4.3 Anzeigen von Erfahrung, Kritik, Hinweisen, Tipps
Die Frage ist nun, wie Erfahrungen angezeigt werden können, ohne den Benutzer zu stören.
Sie soll aber auch genutzt und nicht ignoriert werden. Es werden zunächst Verfahren aus
bekannten Programmen untersucht und daraus eigene Lösungen entwickelt.
4.3.1 Microsoft Word
Microsoft Word [Msw02] hat einen Office-Assistenten, den man jederzeit einblenden und
wieder deaktivieren kann. Der Assistent beobachtet laufend die Schritte des Benutzers und
gibt Hinweise und Tipps. Der Assistent schlägt auch Arbeitserleichterungen vor. Ein
unerfahrener Benutzer geht vielleicht noch mit den Cursortasten jedes Zeichen einzeln durch.
Word erkennt dieses und schlägt vor, „STRG und die rechte oder linke Pfeiltaste“ zu drücken,
„um sich Wort für Wort durch den Text zu bewegen“. Word gibt also aktiv Hilfe. Der
Benutzer kann auch Hilfe anfordern. Dazu kann er direkt Fragen formulieren und der
Assistent versucht die Schlagwörter zu extrahieren und mögliche Antworten zu geben. Gibt
man zum Beispiel ein, dass man eine Tabelle erstellen möchte, stellt er mehrere
Möglichkeiten zur Auswahl (siehe Abbildung 13a), in diesem Fall an erster Stelle die
gewünschte Hilfe.
Abbildung 13: Office-Assistent, (a) Tabelle erstellen, (b) Brief schreiben, (c) Umschlag erstellen
Wenn der Benutzer anfängt einen Brief zu schreiben, erkennt Word dieses und der Assistent
meldet sich mit Hilfe zur Erstellung eines Briefes (s. Abbildung 13b). Wählt der Benutzer
29

30
4. Konzept
„Hilfe zur Erstellung des Briefes anfordern“ aus, öffnet sich der Brief-Assistent, in dem man
verschiedene Vorlagen auswählen und diverse Briefinformationen angeben kann. Der
Assistent erstellt dann automatisch einen Briefrumpf mit allen eingegeben Informationen. Die
Unterstützung geht sogar weiter, denn im nächsten Schritt fragt er den Benutzer, ob er einen
passenden Briefumschlag oder Adressetiketten erstellen möchte (s. Abbildung 13c). Möchte
der Benutzer einen Brief ohne Hilfe erstellen, kann er dieses auswählen oder diesen Tipp
deaktivieren.
Das Schöne an dem Assistent ist, dass er nicht im Wege ist und in gewisser Weise
menschliche Züge annimmt. Durch die Darstellung mit Augen und der gelegentlichen
Animation, aber auch weil man Fragen frei formulieren kann, wird der Eindruck erweckt,
dass man mit einen menschlichen Assistenten kommuniziert und nicht mit dem Computer.
Erfahrenen Benutzern, die nicht ständig „beobachtet“ werden wollen, mag der Assistent auf
Dauer stören, da er vielleicht auch Tipps anzeigt, die man schon lange kennt oder gar nichts
mit der aktuellen Arbeit zu tun hat. Vermutlich ist der Word-Assistent eher für Benutzer
nützlich, die wenig Umgang mit Computer bzw. Word haben oder sich gerade in Word
einarbeiten.
4.3.2 Eclipse
Eclipse [Ecl06] unterscheidet Fehler und Warnungen. Fehler werden mit rot, Warnungen, also
mögliche Probleme, nicht verwendete Variablen, usw., mit gelb hervorgehoben.
Warnmeldungen und Fehler werden wie in Abbildung 14 gekennzeichnet auf mehrere Weisen
an den Benutzer weitergegeben. Zum einem kann man im Package Explorer (1) fehlerhafte
Pakete ausfindig machen und durch die Baumstruktur zur Klasse und Methode springen. In
den Tabs (2) werden Klassen, die Warnungen bzw. Fehler enthalten mit einem
entsprechenden Icon versehen. Bei der Bearbeitung einer Klasse werden zum einen an der
linken Seite (3) Fehler hervorgehoben, aber auch im Quelltext (4) selbst, wobei die Fehler
bzw. Warnungen in der entsprechenden Farbe unterstrichen werden.
Textverarbeitungsprogramme wie Word verwenden bei der Rechtschreibüberprüfung auch
dieses Verfahren. Unbekannte Wörter werden mit rot unterstrichen, vermutete Fehler mit
grün. Da eine Klasse in der Regel nicht auf eine Bildschirmseite passt, werden neben dem
Scrollbalken (5) die Fehler und Warnungen der ganzen Klasse skaliert zum verfügbaren Platz
angedeutet. Schließlich gibt es noch eine ProblemView (6), in der die Fehler und Warnungen
des gesamten Projekts angezeigt werden und nach wählbaren Kriterien gefiltert bzw. sortiert
werden können. Die Fehler und Warnungen werden durch Tooltipps näher erläutert und in
einigen Fällen werden so genannte Quickfixes angeboten, zum Beispiel hier das Umändern in
einer Methode ohne Rückgabewert oder das Einfügen eines Rückgabewertes.

4.3 Anzeigen von Erfahrung, Kritik, Hinweisen, Tipps
Abbildung 14: Entwicklungsumgebung von Eclipse, [Ecl06]
Ferner unterstützt Eclipse den Benutzer durch automatische Vervollständigung und
erleichtertes Navigieren durch das Projekt. Mühselige Aufgaben wie der Vergleich von zwei
Klassen, die Extrahierung zu einem Interface und die Generierung der getter- und setter-
Methoden können vom Programm ausgeführt werden. Auch die automatische Generierung
von Schleifen-Rümpfe aus Vorlagen ist möglich.
4.3.3 PopUp-Fehlerfenster
Beim Programmieren in Eclipse wäre es sehr störend, wenn bei jedem Fehler sofort ein
PopUp-Fenster aufgehen würde. Denn wenn man beispielsweise gerade eine Methode
schreibt, hat man vielleicht den Rückgabewert noch nicht aufgeschrieben. Daher ist es
sinnvoll, die Fehler nur durch Markierungen hervorzuheben, der Programmierer kann weiter
arbeiten und den Fehler später beheben, wenn er soweit ist.
Mit schwerwiegenden Fehlern sieht es jedoch anders aus. Kann eine Operation wie die
Umbenennung einer Datei nicht ausgeführt werden, sollte der Benutzer darauf explizit
aufmerksam gemacht werden. Da die Erwartung des Benutzers nicht erfüllt wird, wird er sich
wundern, warum nichts geschehen ist. Die Fehlermeldung sollte der Benutzer nicht übersehen
können. Da macht es dann durchaus Sinn, ein PopUp-Fenster zu öffnen, dass die
Arbeitsfläche überdeckt, so dass der Fehler nicht übersehen werden kann.
31

32
4.3.4 Tipp des Tages
Abbildung 15: Fehlerfenster
4. Konzept
Bei einigen Programmen wird beim Start ein Tipp angezeigt. Meist kann man sich auch
weitere Tipps anzeigen lassen. Die Auswahl der Tipps erfolgt in zufälliger Reihenfolge und
berücksichtigt dabei nicht den Erfahrungsstand des Benutzers. Für einen neuen Benutzer
können diese Tipps helfen, das Programm näher kennen zulernen und sich in unbekannte
Funktionalitäten und so genannten Shortcuts einzuarbeiten. Benutzer die schon länger mit
dem Programm arbeitet und denen die Tipps nicht weiterhelfen, da sie das Programm schon
ausführlicher kennen, stören die Tipps vermutlich. Daher können sie in der Regel diese Tipps
deaktivieren.
4.3.5 Hilfe auf Anfrage
Viele Programme bieten passive Hilfe über die Menubar an. Diese Hilfe erfolgt nur auf
expliziten Wunsch des Benutzers. Dazu muss der Benutzer ein Problem selbst erkannt haben.
In der Regel ist dies nur der Fall, wenn der Benutzer nicht weiß, wo er eine Funktion findet
oder nicht weiß, wie er eine Funktion ausführt. Eine Antwort muss er durch Suchen im
Inhaltsverzeichnis bzw. im Index selbst finden. Oft wird eine Suche angeboten, die jedoch nur
Schlagwörter durchsucht, aber keinen Volltext. Für die Anzeige von Erfahrung ist diese Art
von Hilfe ungeeignet, da sie passiv erfolgt. Ein Benutzer kann nicht wissen, dass zu einem
Problem eine Erfahrung existiert. Er wird seine Arbeit gewissenhaft machen und nicht
vermuten, dass es eine bessere Lösung gibt. Daher ist eine aktive Hilfe für das zu
entwickelnde Tool unerlässlich.
4.3.6 Fazit
Es soll eine Kombination aus diesen vorgestellten Verfahren verwendet werden. Ein Assistent
ist gut geeignet, um Hinweise bei der Bearbeitung anzuzeigen. Die Anzeige stört nicht, wenn
sie in einen getrennten Bereich erfolgt. Einzelne Hinweise sollten deaktiviert werden können,
wenn der Benutzer meint, den Hinweis schon zu kennen. Der Assistent kann auch dazu
genutzt werden, Warnungen und Fehler anzuzeigen und Verbesserungsvorschläge zu geben.
Er kann aktiv dynamische Hilfestellung geben. Die freie Formulierung von Fragen ist
allerdings schwierig und soll zunächst nicht implementiert werden. Allerdings ist eine
nachträgliche Erweiterung denkbar.

4.4 Architektur des Tools
Die Anzeige von Fehlern und möglichen Problemen kann ähnlich wie in Eclipse erfolgen.
Fehler bzw. Warnungen können durch entsprechende Icons neben ein Formularelement
angezeigt werden. So ist es dem Benutzer möglich, auf einen Blick zu erkennen wo es noch
Probleme gibt. Durch Auswahl des Feldes zeigt der Assistent dann die Fehlermeldung an.
Ebenfalls ist ein Tooltipp ähnlich wie in Eclipse wünschenswert, da der Benutzer den
Assistenten ausgeblendet haben könnte. Entsprechende Icons können auch in einem Baum an
der Seite angezeigt werden, welches ihm eine Navigation zu den Fehlern erleichtert. So ist
sichergestellt, dass Fehler und Hinweise angezeigt werden, auch wenn der Assistent
ausgeblendet wurden ist.
Die Idee eines ProblemViews ermöglicht den Benutzer alle Fehler übersichtlich darstellen zu
lassen und sollte ihm ebenfalls zur Verfügung gestellt werden. Falls der Benutzer den
Assistenten ausblendet, stellt diese Übersicht eine weitere Möglichkeit dar, den Benutzer zu
erreichen.
PopUps sollten vermieden werden, da sie bei der Arbeit stören. Lediglich bei
schwerwiegenden Fehlern bei der eine Operation nicht ausgeführt werden kann, soll sich ein
Fenster öffnen. Dies sind zum Beispiel Fehler beim Laden bzw. Speichern des Projekts. Es ist
auch denkbar den Benutzer durch PopUps zu erreichen, falls er den Assistenten ausgeblendet
hat. Allerdings wird er den Assistenten nicht ohne Grund ausgeschalten haben und diese Art
von „Unterstützung“ ist weitaus störender als ein Assistent an der Seite. Daher sollen weder
Kritiken noch Hinweise über PopUps erfolgen.
Ein Tipp des Tages ist hilfreich für neue Benutzer, soll aber in dem Assistenten integriert
werden. Beim Starten des Programms kann der Assistent als erstes immer einen Tipp
anzeigen, es sei denn der Benutzer hat die Anzeige des Tipps deaktiviert bzw. den Assistenten
ausgeblendet.
Durch ein aktives System, das die relevanten Erfahrungen selbständig heraussucht, soll die
Diskrepanz zur Nutzung vorhandener Erfahrungen erheblich minimiert werden, so dass sie
auch tatsächlich genutzt werden. Ein Assistent und eine dezente Markierung von Fehlern und
Problemen sollen den Benutzer in seiner Arbeit unterstützen und dabei nicht hinderlich sein.
So soll er ruhig die Warnungen erst mal ignorieren können und später dann beheben, so dass
seine gegenwärtige Arbeit und sein Gedankenfluss nicht gestört werden.
4.4 Architektur des Tools
Die Architektur ist an das MVC Pattern angelehnt. Im MVC Pattern werden das Modell, die
View und der Controller voneinander getrennt. Das Modell hält die Daten vor und wird von
der View beobachtet. Das Modell weiß nichts über die innere Struktur der View und
benachrichtigt lediglich die View bei Änderungen. Die View stellt die Daten, also das Modell,
grafisch dar. Sie aktualisiert sich automatisch, wenn sich das Modell geändert hat. Bei einer
Eingabe durch den Benutzer werden Ereignisse ausgelöst. Der Controller interpretiert die
Ereignisse und verändert das Modell. Der Vorteil dieses Patterns ist die Austauschbarkeit und
die beliebige Erweiterbarkeit um weitere Views. Die Trennung von Modell, View und
Controller macht Sinn, da man auf diese Weise eine übersichtliche Struktur erhält, die zudem
auch noch leicht wartbar ist. Da mit dem Observer-Pattern gearbeitet wird, können
Änderungen auch Berechnungen anstoßen.
33

34
Abbildung 16: Architektur des Tools
4. Konzept
Der Use Case Editor hat drei Modelle, das Template Modell, das Projekt und Use Case
Modell und das Erfahrungsmodell. Das Template Modell ermöglicht die individuelle
Anpassung des Template durch Hinzufügen bzw. Entfernen von Attributen. Das Projekt und
Use Case Modell hält die Projektdaten und die Use Cases bereit und das Erfahrungsmodell
die aktuell relevanten Erfahrungen.
Alle drei Modelle werden von der View, also der grafischen Benutzeroberfläche, beobachtet.
Bei einer Änderung der Modelle aktualisiert sie die dargestellten Informationen. Der Benutzer
modifiziert über die Grafische Benutzeroberfläche die Daten und löst dabei verschiedene
Events aus, die vom Controller aufgenommen und interpretiert werden. Der Controller ändert
dann die Modelle um.
Weiterhin hat der Controller Zugriff auf die Projektverwaltung, über die er Projekte laden
und speichern kann, und die Persönliche Sicht auf die Erfahrungsbasis. So können bestimmte
Erfahrungen deaktiviert werden, es können aber auch neue hinzugefügt oder bestehende
erweitert werden. Die Persönliche Sicht greift auf die Erfahrungsbasis zu und filtert nicht
gewünschte Erfahrungen heraus. Wo die Erfahrungsbasis für jeden Benutzer die gleiche ist,
kann der Benutzer in dieser Sicht, individuell Erfahrungen ausblenden, die ihn stören oder die
er nicht mehr für informativ hält.
Der Erfahrungsmatcher beobachtet das Projekt und Use Case Modell, greift auf diese
persönliche Erfahrungssammlung zu und sucht die relevanten Erfahrungen aus, die er im
Erfahrungsmodell setzt. Die GUI zeigt diese Erfahrungen schließlich an. Es wäre auch
möglich, den Erfahrungsmatcher als Teil des Controllers zu implementieren. Dadurch wäre
dieser jedoch komplexer und unübersichtlicher geworden. Durch die Trennung ist eine
Erweiterung (siehe Kapitel 3.5.4) einfacher. Wenn man das Tool beispielsweise durch eine
Webkomponente erweitern möchte, hätte man den Erfahrungsmatcher erneut implementieren
müssen. Da dieser jedoch ausgelagert ist, muss lediglich nur der Controller selbst neu

4.5 Modelle
geschrieben werden. Auch ein Austausch der Komponenten stellt keine größeren Probleme
dar, weil die Komponenten kleiner und überschaubarer sind.
Die Komponenten einer Domänorientierten Entwurfsumgebung sind in dieser Architektur
wieder zu finden. Die GUI stellt zweifelsfrei die Konstruktionskomponente dar, in der die
Use Cases „konstruiert“ werden. Der Matcher analysiert die Konstruktion und gehört
zusammen mit der Erfahrungsbasis und den Assistenten zur Argumentationskomponente. Die
Projektverwaltung ist zwar für die Speicherung der Projekte zuständig, stellt zugleich aber
auch den Katalog dar, in der in einer späteren Entwicklung nach ähnlichen Use Cases gesucht
werden könnte. Die Spezifikationskomponente ist in Teilen der GUI und dem Template
Modell wieder zu finden. Im Template Modell wird spezifiziert, wie ein Use Case aussehen
soll, also welche Attribute aktiviert bzw. deaktiviert sind. Die Simulationskomponente könnte
später integriert werden. So ist die Ableitung eines grafischen Prozessmodells aus den Use
Cases denkbar, welches dann simuliert werden könnte (siehe Kapitel 7).
4.5 Modelle
4.5.1 Projekt und Use Case Modell
Abbildung 17: Klassendiagramm des Projekt und Use Case Modells
Ein Projekt soll die Attribute Titel, Beschreibung, Erstellungsdatum und Letzte Änderung
besitzen. Der Benutzer soll einem Projekt einen kurzen Titel geben können, um es schnell
wieder identifizieren zu können. Unter Beschreibung hat er die Möglichkeit eine
ausführlichere Kennzeichnung und Erläuterung anzugeben. Weitere Metadaten sind das
35

36
4. Konzept
Erstelldatum sowie der Zeitpunkt der letzten Änderung, wodurch es denn Benutzer ermöglicht
wird, verschiedene Versionen zu unterscheiden. Ein Projekt bündelt beliebig viele Use Cases.
Ein Use Case weist ebenfalls ein Erstell- und Änderungsdatum auf und umfasst beliebige und
beliebig viele Attribute, die aus einen eindeutigen Schlüssel und einen beliebigen Objekt
bestehen. Ein Attribut hat ebenfalls ein Änderungsdatum, so dass der Benutzer die
Möglichkeit hat, sich die letzten Änderungen anzeigen zu lassen. Die abgelegten Objekte sind
in der Regel einfache Zeichenketten wie Titel, Beschreibung oder Vorbedingung, aber auch
komplexere Datenstrukturen sind möglich. So kann ein Attribut auch das
Haupterfolgsszenario sein.
Ein Szenario besteht aus Schritten, wobei ein Schritt aus einem Akteur und seiner Aktion
besteht. Da in einem Szenario auch ein Use Case verlinkt werden kann (Include), wurde das
Interface IStep eingeführt, das Step und LinkedUseCase implementieren. Die Klasse
LinkedUseCase beinhaltet einen Verweis auf den Use Case und einen frei definierbaren
Aktionsnamen. Gibt der Benutzer keinen eigenen Namen ein, so wird der Titel des Use Cases
verwendet, welcher allerdings nicht unbedingt zu einen satzfreundlichen Aufbau führt. Ist der
verlinkte Use Case null, so liegt eine fehlerhafte Verlinkung vor. Das Kritiksystem muss
diesen Fehler anzeigen.
Schritte können erweitert werden. Daher müssten Schritte eigentlich ein Attribut
„Erweiterungen“ besitzen. Da aber auch mehrere Schritte durch die gleiche Erweiterung
erweitert werden könnten, werden Erweiterungen als Use Case Attribut abgelegt. Diese
Trennung hat auch einen Verwaltungsvorteil, da Erweiterungen in der grafischen Oberfläche
als ein Datenfeld für sich dargestellt werden (vgl. Use Case Template von Cockburn,
[Coc06]). Der Nachteil ist allerdings, dass die Konsistenz nicht automatisch gegeben ist. Der
Benutzer bzw. das Kritiksystem muss überprüfen, dass keine fehlerhaften Referenzen
vorkommen. Eine Erweiterung hat ein Attribut, dass die erweiterten Schritte referenziert, eine
Bedingung und ein Szenario, das durchlaufen werden soll, wenn die Bedingung erfüllt ist.
Ein weiteres Use Case Attribut können die Technischen Variationen (Klassenname
Variation) sein. Sie verfügen ähnlich wie die Erweiterungen über ein Attribut, das die
Schritte referenziert, die variiert werden und ein Attribut, das die Variation angibt. Technische
Variationen listen Alternativen auf. Sie haben kein Szenario, da nur die Variationsart
interessant ist. Sollte ein alternativer Weg vorliegen, sollte dieser besser in Erweiterungen
aufgeführt werden. Auch bei den Variationen muss die Konsistenz der Schritte durch das
Kritiksystem geprüft werden.

4.5 Modelle
4.5.2 Template Modell
Abbildung 18: Klassendiagramm des Template Modells
Ein Template bündelt aktuelle sowie deaktivierte Attribute. Dazu wurde die bereits bekannte
Klasse UseCaseAttribute um Variablen erweitert, die besagen, ob das Attribut aktiviert
ist, ob es unerlässlich ist und ob sie eine Auswahlbeschränkung unterliegt. Ein Beispiel für ein
unerlässliches Attribut ist das Erfolgsszenario. Ein Use Case ohne Szenario verliert den
eigentlichen Sinn eines Use Cases. Auf das Attribut Performance könnte hingegen durchaus
verzichtet werden. Mit der optionalen Angabe einer Auswahlbeschränkung, können in der
GUI nur die vordefinierten Möglichkeiten ausgewählt werden. Dies findet zum Beispiel bei
der Angabe des Levels eine Verwendung. Hier kann der Benutzer nur zwischen den 3 Levels
Überblick, Funktion und Subfunktion wählen und keine eigene angeben.
Ob ein Attribut aktiviert bzw. deaktiviert ist, kann über die bereitgestellten Methoden
abgefragt und modifiziert werden. Der Benutzer kann auch beliebige eigene Attribute
hinzufügen (siehe Use Case 14: Benutzer bearbeitet das Use Case Template).
37

38
4.5.3 Erfahrungsmodell
Abbildung 19: Klassendiagramm des Erfahrungmodells
4. Konzept
Erfahrungen bestehen hier aus einem Teaser und einer Erläuterung. Mit einem kurzen Text
wird die Erfahrung in einem Satz geschildert. Wenn dem Benutzer die oberflächliche
Information nicht ausreicht, muss er eine Erklärung bzw. eine ausführlichere Beschreibung
des Problems mit möglichen Lösungsvorschlägen abrufen können. Da es vermutlich mehrere
relevante Erfahrungen gibt, sollten sie nach ihrer Wichtigkeit sortiert angezeigt werden (siehe
Anforderung in 3.1). Daher ist eine Priorität nötig. Darüber hinaus hat eine Erfahrung zur
eindeutigen Identifizierung eine ID, die auch zur Speicherung der deaktivierten Erfahrungen
verwendet wird und ein Änderungsdatum, um Aktualisierungen zu erkennen.
Die Erweiterbarkeit von Erfahrung wurde durch die Klasse ExperienceExtension
gelöst. Der Benutzer kann eine Art Feedback über bestehende Erfahrungen abgeben, wenn er
beispielsweise anderer Ansicht ist oder Erfahrungen über die Nutzung dieser Erfahrungen
besitzt. Dabei sind lediglich die Attribute Teaser und Erläuterung relevant. Der Kontext und
die Gewichtung gehen aus der bestehenden Erfahrung hervor. Selbstverständlich kann eine
Erweiterung abermals erweitert werden und kann beliebig viele Erweiterungen besitzen. Um
unnötige instanceof-Abfragen zu ersparen, wurde das Interface Extandable
eingeführt, dass die Klasse Experience und ExperienceExtension implementieren.
Sie setzt Methoden zum Abfragen und Setzen des Teasers und der Erläuterung, sowie das
Hinzufügen, Löschen und Abragen der Erweiterungen voraus.
Die Klasse Help ist von der abstrakten Klasse Experience abgeleitet und verfügt über
zwei Attribute, nämlich forEditingUseCase und forAttribute. Das erste Attribut
besagt, ob die Hilfe für das Editieren eines Use Cases dient und das zweite Attribut für
welches Use Case Attribut sie relevant ist. Ist das Use Case Attribut null, so handelt es sich
um eine allgemeine Hilfe für die Bearbeitung eines Use Cases, ist das erste Attribut unwahr,
so ist die Hilfe allgemein und dient der Bearbeitung des Projekts. Des Weiteren hat die Klasse
Help eine Methode checkContext, die überprüft, ob die Hilfe für die übergebenen

4.5 Modelle
Parameter relevant ist. Dies ist notwendig, da bei der Bearbeitung stets nur relevante
Erfahrungen angezeigt werden sollen.
Die Klasse Critic erweitert ebenfalls die abstrakte Klasse Experience. Sie verfügt über
eine Methode, die wahr zurückgibt, wenn die Kritik mindestens einmal im Projekt zutrifft.
Dieser Wahrheitswert wird dadurch berechnet, dass eine Klasse instanziiert wird, die die
Überprüfung vornimmt und mit wahr antwortet, wenn sie eine weniger gute Lösung oder gar
einen Fehler entdeckt hat. Die Klasse, die diese Überprüfung durchführt, wird als Klassenpfad
angegeben und muss das Interface CriticChecker implementieren. CriticChecker
hat eine Methode checkForProject, das bei der Überprüfung ContextObjecte
erzeugt, die die Kritikstellen im Projekt speichern. Es wäre auch möglich, dass die Klasse
Critic dieses direkt überprüft. Man hätte dann die Klasse erweitern müssen und das für
jede Kritikmöglichkeit, obwohl sich jedoch nur die Prüfmethode ändert. Daher wurde durch
Wahl einer externen Klasse das Strategy Pattern verwendet, so dass eine klare Trennung des
eigentlichen Modells von den erweiterbaren Erfahrungen erfolgt. Die Klasse Critic bleibt
also unverändert. Da Erfahrungen austauschbar sein sollen, könnte es unter Umständen
vorkommen, dass für die gleiche Kritik unterschiedliche Implementierungen nötig sind, zum
Beispiel wenn mal neun und in einen anderen Fall zwölf Schritte als maximale Szenariolänge
gesehen werden. Auch die Mehrsprachigkeit wird dadurch besser unterstützt. Ferner kann
wegen der Einheitlichkeit die Eingabe von Teaser, Erläuterung, Kontext und Klassenpfad
über eine grafische Benutzeroberfläche erfolgen. Ferner wurde für die Änderbarkeit und
Erweiterbarkeit ein optionaler Parameter vorgesehen, über das z. B. sprachabhängige Wörter
gesetzt werden können.
Abbildung 20: Klassendiagramm CriticChecker
Ob eine Kritik dem aktuellen Kontext entspricht, kann über die Methode matches abgefragt
werden. Ihr werden als Parameter das Projekt, der Use Case, das Attribut und der Teil des
Attributs übergeben. Die Methode liefert wahr, sofern ein Teil des Pfades übereinstimmt. Auf
diese Weise ist es möglich, dass eine Kritik für ein ganzes Projekt, ein Use Case, ein Use
Case Attribut bzw. für einen Teil des Attributes, z. B. einen Schritt, gelten kann. Die Methode
matches dient den Knoten aus den Projektbaum bzw. den Formularelementen dazu,
39

40
4. Konzept
festzustellen, ob es einen Icon anzeigen muss oder nicht. Sie übergeben dabei die bekannten
Parameter und wenn die Kritik für diesen Kontext zutrifft, liefert die Methode wahr.
Die Klasse Critic wird entsprechend Kapitel 4.1 weiter unterteilt in Error und
Warning, da eine Warnung nicht gleich ein Fehler bedeuten muss.
Die Klasse ExperienceModell speichert die aktuellen Erfahrungen. Dabei wird zwischen
Hilfe und Kritik unterschieden. Hilfe wird, wie oben erwähnt, angezeigt, bevor der Benutzer
eine Eingabe macht, also dann wenn er ein Datenfeld ausgewählt hat. Eine Hilfe bezieht sich
daher immer auf den aktuellen Kontext. Eine Kritik hingegen, die immer erst nach der
Eingabe erfolgen kann, muss sich nicht auf den aktuellen Kontext beziehen. Dieser
Unterschied bedeutet auch, dass die Ermittlung der relevanten Hilfe und Kritiken auf
unterschiedliche Weise erfolgt. Die Trennung kann bei vielen Erfahrungen auch zu einer
besseren Performance führen. Aus diesen Gründen wird eine Trennung vorgenommen.
4.6 Erfahrungsmatcher
Abbildung 21: Sequenzdiagramm zur Anzeige von Hilfe
Wenn der Benutzer ein Use Case bearbeitet, löst er bei beim Selektieren eines Formularfeldes
ein Event aus. Es wird ein Update an den Erfahrungsmatcher geschickt. Der Matcher holt sich
daraufhin die aktivierten Hilfestellungen aus der Erfahrungsbasis, die er über die persönliche
Sicht erhält. Die Hilfestellungen werden durchlaufen und die, die mit dem aktuellen Kontext
(Ebene der Bearbeitung, also Projekt-, Use Case- oder Attributebene) übereinstimmen,
werden in dem Erfahrungsmodell gesetzt. Der Assistent, der das Erfahrungsmodell
beobachtet, erhält daraufhin eine Benachrichtigung über die Änderung und aktualisiert seine
Anzeige.

4.7 Erfahrungsschatz
Abbildung 22: Sequenzdiagramm zur Anzeige von Kritik
Wenn der Benutzer mit der Bearbeitung eines Formularfeldes fertig ist, wird dabei der Use
Case aktualisiert und ein Event ausgelöst. Es wird ein Update an den Erfahrungsmatcher
geschickt und ähnlich wie bei der Hilfe holt sich der Matcher die aktivierten Kritiken aus der
Erfahrungsbasis. Die Kritiken werden durchlaufen und für jede Kritik wird überprüft, ob sie
für einen der Use Cases zutrifft. Dazu wird die im Klassenpfad referenzierte Klasse
instanziiert. Sie implementiert das Interface ContextChecker und verfügt daher über eine
Methode checkProject. Die Methode gibt wahr zurück, sofern die Kritik mindestens
einmal im Projekt zutrifft. Bei der Überprüfung werden ContextObjecte erzeugt, die sich
die Kritikstellen im Projekt merken. Die ermittelten Kritiken werden dann dem
Erfahrungsmodell übergeben, wodurch der Assistent, der Projektbaum, die ProblemView und
das Formular, die alle das Erfahrungsmodell beobachtet, benachrichtigt werden und diese ihre
Anzeige aktualisieren.
Die Hilfe ändert sich nur, wenn ein anderes Attribut ausgewählt wurde. Der Assistent ist der
einzige der sich für eine solche Änderung interessiert. Die Kritiken werden aktualisiert, wenn
sich das Projektmodell ändert, also wenn der Benutzer eine Eingabe gemacht und diese
übernommen wurde. Für eine solche Änderung interessieren sich alle, die Warnungen und
Fehler visualisieren, also der Assistent, der einen Fehler anzeigt, wenn das dazugehörige
Attribut ausgewählt ist, sowie der Projektbaum und das Formular, die die Stellen markieren
und die ProblemView, die alle Kritiken in einer Ansicht zusammenfasst.
4.7 Erfahrungsschatz
Der Erfahrungsschatz könnte auf verschiedene Art und Weisen realisiert werden. Da der
Benutzer auch unterwegs ohne Netzanschluss arbeiten können muss, fällt die Wahl eines
41

42
4. Konzept
Servers, der die Erfahrungen heraussucht, weg. Die Auswahl der aktuellen Erfahrung kann
daher nur clientseitig erfolgen. Es ist aber durchaus denkbar, ein Update des
Erfahrungsschatzes über einen Server durchzuführen, ähnlich wie die gängigen
Virenprogramme ihre Virendefinitionen aktualisieren. So kann ein Client bei vorhandenem
Netzzugang seine neuen Erfahrungen auf dem Server veröffentlichen und anderen Benutzern
zur Verfügung stellen und neue Erfahrungen der anderen Benutzer herunterladen. Dieses
könnte in einer späteren Entwicklung realisiert werden, in der ersten Version soll dieses
manuell durch den Benutzer erfolgen.
Die Speicherung der Erfahrung könnte in einer Datenbank erfolgen. Das Matching könnte
durch eine Abfrage in SQL erfolgen, die dann die relevanten Erfahrungen zurückgibt. Dies
hätte den Nachteil, dass eine Datenbank zusätzlich installiert werden müsste, d.h. man könnte
nicht auf einem fremden Notebook arbeiten. Darüber hinaus bedeutet die Verwaltung der
Datenbank zusätzlichen Arbeitsaufwand, insbesondere wenn weitere Tabellen bzw. Spalten
benötigt werden.
Daher soll die Erfahrungsbasis immer lokal und in einer Datei bereitgestellt werden. Da das
XML-Format eine gute Art ist, Daten zu strukturieren, und zudem auch gut erweiterbar ist,
sollen hier XML-Dateien eingesetzt werden. Dies gilt auch für die Projekt- und
Konfigurationsdateien, da auch Use Cases beliebige und beliebig viele Attribute annehmen
können. Eine Aktualisierung der Erfahrung soll wie schon erwähnt zunächst manuell erfolgen
und in einer späteren Entwicklung über einen Server erfolgen.
4.8 GUI Entwurf
Abbildung 23: GUI Entwurf

4.8 GUI Entwurf
Abbildung 23 zeigt den Entwurf der grafischen Benutzeroberfläche. Die Oberfläche ist an
anderen Anwendungen, insbesondere Eclipse [Ecl06], angelehnt, so dass sie auf den Benutzer
vertraut wirkt. Auf diese Weise kann der Benutzer viele Funktionen intuitiv auf Anhieb
finden.
Auf der linken Seite befindet sich der Projektbaum, der dazu dient, die im Projekt vorhanden
Use Cases als Liste anzuzeigen. Mit einem Klick auf einen Use Case kann dieser geöffnet
werden. Des Weiteren ist es möglich, über die linke Maustaste Use Cases hinzufügen und zu
löschen. Ein Use Case kann aufgeklappt werden, so dass die einzelnen Attribute des Use
Cases sichtbar sind. Mit der Auswahl eines Attributes ist es möglich, direkt zu einen Attribut
zu springen. Fehler und Warnungen sollen durch ein kleines Icon neben dem Element
angedeutet werden, so dass der Benutzer eine nützliche Übersicht erhält, wo noch
Verbesserungsbedarf besteht.
In der Mitte der grafischen Oberfläche und somit im Zentrum findet die Bearbeitung eines
Use Cases statt. Sollte es zu einem Attribut eine Warnung oder einen Fehler geben, erscheint
neben dem Attributnamen ein entsprechendes Icon. Im Szenario wird der Akteur von der
Aktion getrennt. So ist es zum einen wesentlicher schwieriger, Passivsätze zu bilden, da der
Satz immer mit einem Akteur beginnen muss, zum anderen ist so klarer, wer etwas tut.
Cockburn hält es in [Coc01] für äußerst wichtig, immer klarzustellen, wer in einen Schritt
aktiv ist, um Missverständnisse gleich zu Beginn aus dem Weg zu räumen. Der Benutzer wird
also angeregt, sich zu überlegen, wer etwas tut. Durch die Trennung ist es auch leichter
feststellbar, in welchen Use Cases ein Akteur tätig ist. Leider hat die Trennung auch einen
Nachteil. Der Benutzer ist in seinen Satzbau nicht mehr frei, so dass sich ein Schritt eventuell
etwas holprig anhören könnte. Da aber ein gewünschter Satzaufbau in der Form „Subjekt
Prädikat Objekt“ erzielt wird, überwiegt dieser Nachteil nicht all zu sehr. Auf dieser Weise
werden außerdem eventuelle Nebensätze ans Ende gestellt, so dass der Hauptsatz und somit
der eigentliche Schritt im Vordergrund steht. Nebensätze sind zweitrangig und gehören daher
ans Ende.
Unter dem Bearbeitungsbereich befindet sich die ProblemView, die tabellarisch Warnungen
und Fehler im gesamten Projekt darstellt. Durch einen Doppelklick ist es möglich, zum
Problem zu springen.
Im rechten unteren Bereich befindet sich ein Assistent, der aktuelle Hinweise, Warnungen
und Fehler bei der Bearbeitung eines Use Cases anzeigt. Der Assistent liefert auf Anfrage
weitere Erklärungen und gibt Verbesserungsvorschläge. Insgesamt soll der Assistent den
Benutzer während seiner Arbeit unterstützen und dabei nicht stören. Aus diesem Grund wurde
ein Bereich am Rande des Fensters gewählt. Ferner ist es überaus wichtig, dass er stets nur die
relevanten Erfahrungen anzeigt. Falls es mehrere Erfahrungen gibt, kann sich der Benutzer
diese durch entsprechende Buttons anzeigen lassen.
Schließlich soll eine grafische Darstellung des aktuellen Use Cases als Überblick dienen, um
die Funktion und verlinkte Use Cases zu erkennen.
43

44
5. Erfahrungssammlung
Ohne eine erste Sammlung einiger Erfahrungen, würde die Akzeptanz des Tools äußerst
gering ausfallen. Um den Erfahrungskreislauf zu starten, sollen wichtige Erfahrungen gesät
werden (Seeding, vgl. 2.10). Diese Erfahrungen stellen die Grundlage der Erfahrungsbasis
dar. Da Benutzer ihre eigenen Erfahrungen hinzufügen und bestehende kommentieren
können, wächst die Erfahrungsbasis mit der Zeit (Evolutionary Growth). Die Benutzer sollen
dazu angeregt werden, ihr eigenes Wissen einzubringen und zu guten Projektplanungen
beizutragen. In regelmäßigen Abständen muss die Erfahrungsbasis durch einen
Erfahrungsingenieur aufbereitet werden, da sie unkontrolliert wächst. Neue Erfahrungen
werden zwar eingefügt, eventuell aber nicht an der richtigen Stelle. Erfahrungen könnten sich
auch widersprechen bzw. redundant vorkommen. Daher muss ein Erfahrungsingenieur die
Erfahrungsbasis so zu sagen aufräumen und erneut sähen (Reseeding). Mit der Zeit wird sich
dann auch die Qualität des Erfahrungsschatzes erhöhen.
Die folgenden Erfahrungen stammen aus [Coc01] und [ABC03]. Alistair Cockburn, den man
als Spezialisten auf dem Gebiet der Use Cases bezeichnen kann, hat in seinen Buch „Writing
Effective Use Cases“ ([Coc01]) viele Hinweise aus der Praxis gebracht, die bei der Use Case
Erstellung nützlich sind. Zum Buch von Steve Adolph und Paul Bramble, „Patterns for
Effective Use Cases“ ([ABC03]), lieferte er viele wertvolle Beiträge. Daher wurden diese
beiden Bücher für die folgenden Erfahrungen herangezogen. Zunächst sollen einige
allgemeine Erfahrungen über das Team, das Projekt und ganze Use Cases gegeben werden,
sowie eine Vorgehensweise vorgeschlagen werden. Im nächsten Abschnitt folgen dann
Erfahrungen zu den einzelnen Attributen sortiert nach den Auftreten im Use Case Template
von Cockburn (s. [Coc06]).
Die Erfahrungen sind positiv formuliert, also wie man Use Cases gut erstellt. Die im
Folgenden aufgelisteten Erfahrungen können daher direkt als Hilfe übernommen werden.
Durch Negation lassen sich die Kritiken ableiten. Leider lassen sich nicht alle Kritiken
problemlos implementieren. Ein ideales Kritiksystem müsste die Bedeutung des Geschrieben
verstehen. Es müsste z. B. erkennen, dass ein Titel unklar formuliert ist oder eine Bedingung
nicht überprüfbar ist. Leider kann man sich dabei nur an anderen Metriken bedienen, wie zum
Beispiel der Länge einer Eingabe oder ob ein bestimmtes Schlüsselwort vorkommt. Man kann
nur Vermutung äußern, dass beispielsweise ein GUI Element beschrieben wird oder eine
Erläuterung nicht ausführlich genug ist. Sofern solche Methoden existieren, werden sie mit
angegeben.
Etwas unproblematischer sind Überprüfungen, die die Syntax betreffen. Fehlen bspw.
benötigte Angaben wie Titel oder Szenario oder existiert ein verlinkter Use Case nicht mehr,
dann kann dies zweifelsfrei festgestellt werden. Diese Beispiele wären dann Fehler, weil man
mit Sicherheit sagen kann, dass etwas nicht gut ist.
5.1 Allgemeine Erfahrungen auf Projekt- und Use Case-Ebene
1. Das Team
Use Cases sollten in kleinen Teams geschrieben werden. Je größer das Team wird, desto
schwieriger wird es, einen gemeinsamen Termin für einen Meeting zu organisieren, desto

5.1 Allgemeine Erfahrungen auf Projekt- und Use Case-Ebene
größer und schwieriger wird der Kommunikationsaufwand und desto uneinheitlicher werden
die Use Cases, da sie von verschiedenen Personen geschrieben werden. Es bringt jedoch auch
nichts, wenn nur eine Person alles alleine schreibt. Ein Team aus unterschiedlichen
Charakteren haben unterschiedliche Ansichtspunkte und Hintergrundwissen. Sie ergänzen
sich gegenseitig, so dass ein besseres Ergebnis erreicht werden kann. Ein Team besteht
idealerweise aus Experten auf unterschiedlichen Gebieten, so dass eine gemeinsame
domainunspezifische Sprache verwendet werden muss.
2. Der Kunde sollte bei der Use Case Erstellung eingebunden werden.
Es ist überaus wichtig, den Kunden bei der Use Case Erstellung einzubinden, denn ohne sein
Feedback können z. B. die Interessen der Stakeholder nicht vollständig abgedeckt werden. Oft
beschreibt ein Kunde die Anforderungen nicht klar genug, so dass Missverständnisse
entstehen können. Diese führen dann zu Unzufriedenheit beim Kunden, teuren
Nachbesserungen und vielleicht sogar dazu, dass der Kunde ein neues System nicht kauft.
Unzufriedenheit kann auch bei den Benutzern des Systems entstehen, wenn z. B. die
Interessen eines Stakeholders nicht berücksichtigt werden, die der Auftraggeber vergessen
hat. Daher sollte auch ein Gespräch mit den Benutzern eines zu entwickelnden Systems
geführt werden.
3. Man sollte sich vor dem Schreiben von Use Cases Klarheit verschaffen.
Die Beteiligten Entwickler wissen oft nicht, was der Sinn des zu entwickelnden Systems ist.
Unklare Definitionen und Zeitdruck können dazu führen, dass die Entwickler das System
fehlerhaft implementieren. Darüber hinaus neigen Entwickler dazu, die Systemgrenzen zu
erweitern oder Funktionen einzubauen, die sie für nützlich halten, die aber nicht benötigt
werden. Da das eigentliche Ziel nie diskutiert wurde, kreieren sich die Beteiligten ein eigenes
Bild, das zwischen den Benutzern teilweise stark variieren kann. Hinzu kommt, dass die
Mitarbeiter nur unzureichend kommunizieren.
Daher sollte gleich zu Beginn, ein gemeinsames und klares Ziel des Systems verfasst werden.
Alle Beteiligten sollten sich im Klaren sein, welche Probleme das System lösen soll und
welche nicht. Es sollte eine sehr deutliche Grenze zwischen System und Umgebung gezogen
werden, so dass unnötige Features vermieden werden. Auf diese gemeinsame Sicht können
dann Use Cases geschrieben werden, die klarer definiert sind und nicht den eigentlichen Sinn
des Systems verfehlen.
Nicht nur die Stakeholder müssen bekannt sein, sondern auch ihre Rollen und ihre
Bedürfnisse. Ohne die Berücksichtigung ihrer Rollen, bleiben wichtige Systemverhalten
eventuell unentdeckt. Sind nicht alle Bedürfnisse bekannt, bleiben diese unabgedeckt und
können später zu teuren Änderungen führen. Daher ist es erforderlich, dass die Rollen und
Belange eines jeden Benutzers genau beschrieben werden. Eventuell hilft es auch
aufzuschreiben, was ein Benutzer nicht darf, um die Rechte eines Benutzers klar abzugrenzen.
Gegebenfalls lassen sich Rollen zusammenfassen, so dass Redundanz vermieden werden
kann.
45

46
4. Allgemeiner Hinweis zu Use Cases
5. Erfahrungssammlung
Ein Use Case spiegelt ein Vertrag zwischen Stakeholdern über das Verhalten des Systems
unter verschiedenen Bedingungen. Ein Hauptakteur löst eine Interaktion aus und möchte ein
Ziel erreichen. Der Ablauf dieser Interaktion wird im Hauptszenario festgehalten. Gut
geschriebene Use Cases sind simple, leicht zu lesen und gut zu verstehen. Use Cases können
frühzeitig als Diskussionsgrundlage dienen, um Missverständnisse oder Fehler aufzudecken.
Je größer ein Projekt ist, desto länger und ausführlicher sollten Use Cases geschrieben sein.
Hat man hingegen nur ein kleines Projekt mit wenigen Systemfunktionen, lohnt sich der
Aufwand eher nicht und man kann sich die Zeit und die Arbeit sparen.
5. Ein Use Case sollte leicht zu lesen sein.
Use Cases werden von verschiedenen Personen gelesen, unter anderem auch vom Kunden,
der nicht immer über Fachkenntnisse verfügt. Daher dürfen keine fachspezifischen Begriffe
oder Quellcode-Elemente vorkommen. Use Cases sollten kurz, prägnant und einfach
geschrieben sein, da lange Use Cases nur ungern gelesen werden. Es sollten vollständige
Sätze gebildet werden, die grundsätzlich in der Gegenwart und in aktiv formuliert sind. Es
muss klar hervorgehen, was das Ziel des Akteurs in einen Schritt ist und wer aktiv ist. Dies
geschieht in der Regel nicht mit einen in passiv formulierten Satz oder durch Beschreibung
von GUI Elementen. Uses Cases können leichter gelesen werden, wenn sie einen konsistenten
Stil aufweisen. Stilvorgaben machen zwar Sinn, es ist aber sehr kostspielig, jeden Use Case in
ein festes Muster zu pressen.
Strategie für das Kritiksystem: Diese Erfahrung kann das Kritiksystem überprüfen, indem
es zum einen nach Schlüsselwörtern wie „if“, „else“, „for“, „Button“, „Menu“ oder „Enter“
sucht, zum anderen die Sätze nach allen Formen von „werden“ untersucht. Dabei ist es
überaus wichtig, dass nach den Wörtern und nicht nach Teilzeichenketten gesucht wird. Sonst
würde das Kritiksystem bei der Aktion „Kunde authentifiziert sich“ eine Warnung anzeigen,
weil „authentifiziert“ das Schlüsselwort „if“ enthält. Bei Falschmeldungen würde die
Akzeptanz des Tools fallen.
6. Vorgehensweise
Idealerweise fängt man mit einem Use Case auf höchster Ebene an, der das Gesamt-Ziel des
Benutzers beschreibt. Um dieses Ziel zu erreichen, müssen kleinere (Zwischen-) Ziele erreicht
werden. Diese können wieder in Use Cases beschrieben werden. Dieses Verfahren bezeichnet
Cockburn in [Coc01] als „Ever-Unfolding Story“. Dabei sollte stets zuerst in die Breite
gegangen werden und nur ebenenweise in die Tiefe. Denn je tiefer man geht, desto
detaillierter werden die Use Cases. Richtigkeit und Vollständigkeit sind jedoch wichtiger als
Details. Use Cases können bei Bedarf jederzeit weiter verfeinert werden, aber wenn ein Use
Case erst mal fehlerhaft ist, verursacht er möglicherweise Folgefehler und letztendlich hohe
Kosten. Use Cases auf unterster Ebene werden nur ungern gelesen, weil sie wenig aussagen
und lange aufhalten. Dadurch werden aber mögliche Fehler nicht entdeckt. Außerdem sind
genaue Details oft nicht notwendig. Use Cases brauchen nur so detailliert zu sein, dass ein
Programmierer weiß, was er tun soll.
Strategie für das Kritiksystem: Auch diese Erfahrung kann durch das Kritiksystem
überprüft werden. Wenn ein Use Case nicht durch einen auf höherer Ebene motiviert ist, hat
der Benutzer diese Vorgehensweise verletzt. Der Benutzer hat sie auch verletzt, wenn er mit

5.2 Erfahrungen für Use Case Attribute
einen Use Case auf einer unteren Ebene beginnt. Der erste Use Case sollte idealerweise ein
Use Case auf dem höchsten Level sein.
7. Use Cases sind nicht die ganzen Anforderungen.
Use Cases decken nur die funktionalen Anforderungen ab, sie sind nur eine Beschreibung für
die Anforderungen des Verhaltens. Daher müssen zur Abdeckung aller Anforderungen stets
zusätzliche Techniken verwendet werden.
8. Das Schreiben von Use Cases kann auch zur Aufdeckung von
Anforderungen dienen.
Wird ein neues System entworfen, kennt man eventuell nur ein oberstes Ziel. Um dieses Ziel
zu erreichen, müssen zunächst Unterziele erreicht werden, die neue Anforderungen darstellen.
Man kann sich während der Erhebungsphase fragen, warum man etwas will oder wie man das
Ziel erreicht, oder was ist, wenn eine Aktion fehlschlägt. So kommt man zu neuen
Anforderungen, Fehlerbehandlungen und Variationen.
5.2 Erfahrungen für Use Case Attribute
9. Als Titel sollte ein kurzer aktiver Satz stehen, der das Ziel des Use Cases
ankündigt.
Der Titel sollte den Use Case kurz und prägnant in einem Satz umschreiben, so dass schon
beim Lesen des Titels klar ist, was in einem Use Case geschieht. Wenn das Ziel des Akteurs
bereits im Titel genannt wird, muss der gesamte Use Case nur gelesen werden, wenn die
genauen Details von Interesse sind.
Strategie für das Kritiksystem: Hier soll auf einen in aktiv formulierten Satz geprüft
werden. Eine Titellänge von 100 Zeichen sollte ausreichen, um ein Ziel zu beschreiben. Bei
einem längeren Titel wird vermutet, dass er nicht kurz und prägnant genug ist. Fehlt der Titel,
so muss von einem Fehler ausgegangen werden. Es sollte auch kein zweiter Use Case mit
ähnlichem Titel existieren, da entweder Redundanz vorliegt oder die Titel nicht klar genug
formuliert wurden. Die Ähnlichkeit zweier Zeichenketten lässt sich mit der Levenshtein-
Distanz [Lev66] bestimmen, bei der die eingefügten und gelöschten Zeichen gezählt werden,
um auf die andere Zeichenketten zu kommen. Bei einer Distanz von mehr als 10 auf 100
Zeichen soll eine Warnung ausgesprochen werden. Fehlt der Titel, ist von einem Fehler
auszugehen. Use Case ohne Titel sind schlecht, da sie nicht das Ziel des Use Cases
wiedergeben.
10. Eine Erläuterung beschreibt den Use Case ausführlicher als der Titel.
Während der Titel einen ganz groben Überblick geben soll, kann in der Erläuterung ein etwas
genauerer Überblick gegeben werden. Allerdings bringt es wenig, das Szenario
nachzuerzählen. Eventuell ist eine Erläuterung nicht erforderlich, wenn der Titel
aussagekräftig genug ist und der Use Case leicht zu überblicken ist.
47

48
5. Erfahrungssammlung
Strategie für das Kritiksystem: Sollte die Erläuterung kürzer als der Titel sein, ist er
offensichtlich nicht ausführlicher. Je mehr Schritte und Erweiterungen ein Use Case hat, desto
länger sollte die Erläuterung sein. Das Kritiksystem sollte daher eine Warnung anzeigen,
wenn die Erläuterung entsprechend der Längen des Titels und der Anzahl der Schritte und
Erweiterungen nicht lang genug ist.
11. Mit der Angabe eines Scopes grenzt man das System ab.
Der Scope (Umfang / Systemgrenzen) sollte so klein gewählt werden, dass der Hauptakteur
gerade noch außerhalb des betrachteten Systems steht. Mit der Angabe des Scopes versucht
man abzugrenzen, was zum zu implementierenden System gehört. Missverstände können
später zu hohen Kosten führen, daher sollte der Scope schon in der Erhebungsphase klar
definiert sein. Generell sollten Use Cases Black Boxes beschreiben. Die innere Struktur, also
wie ein Verhalten erreicht wird, ist in der Erhebungsphase irrelevant.
12. Die Ebene gibt die Tiefe des Detaillierungsgrades an.
Je tiefer man geht, desto detaillierter ist ein Use Case. [Coc01] benutzt dabei folgende
Metapher: Dort wo Himmel und Meer sich treffen, ist die Funktionsebene und die Ebene, die
die interessanten Use Cases enthält. Man kann auf beliebig vielen Ebenen nach oben zu den
Wolken gehen, und trifft dabei auf die Use Cases auf Überblickebene. Man kann auch
beliebig nach unten gehen und trifft auf die Subfunktionen und irgendwann auf den
Meeresgrund. Es macht wenig Sinn, sehr detaillierte Use Cases zu schreiben. Sie weisen zu
viele Informationen auf, die oft niemanden interessieren und sind daher vergeudete Zeit und
Arbeit. [Coc01] empfiehlt 3 Ebenen, also die eigentlich wichtigen Use Cases auf
Funktionsebene, die durch einen oder einige wenige Use Cases auf Überblickebene motiviert
werden und einige Use Cases als Subfunktionen verwenden. Subfunktionen sollten nur aus
Übersichtsgründen verwendet werden bzw. wenn mehrere Use Cases diese Subfunktion
verwenden.
Strategie für das Kritiksystem: Das Kritiksystem sollte den Benutzer warnen, wenn er viele
Use Cases auf niedrigsten Level geschrieben hat. Die meisten Use Cases sollten sich auf einer
mittleren Abstraktionsebene befinden. Konkret soll das System warnen, wenn mehr als 25%
der Use Cases auf den unteren Ebenen geschrieben wurden.
13. Vorbedingungen müssen wahr sein und werden im Use Case nicht mehr
überprüft.
Vorbedingungen werden von aufrufenden Use Cases auf höherer Ebene sichergestellt, so dass
eine weitere Überprüfung nicht erforderlich ist. Es sollten jedoch nur Vorbedingungen
aufgelistet werden, die auch tatsächlich nötig sind. Vorbedingungen brauchen und sollten im
Szenario nicht noch mal geprüft werden.

5.2 Erfahrungen für Use Case Attribute
14. Mindestgarantien werden auf jeden Fall, also auch bei einem Fehlschlag,
eingehalten.
Mindestgarantien sind zugesicherte Versprechen, die im Erfolgsfall aber auch bei einem
Fehlschlag auf jeden Fall eingehalten werden. Der Hauptakteur oder ein aufrufendes Use Case
wird sich darauf verlassen. Die Interessen der Stakeholder sollten berücksichtigt werden.
15. Erfolgsgarantien sind Zusicherungen, die nur im Erfolgsfall erfüllt werden.
Erfolgsgarantien enthalten das Ziel des Hauptakteurs und implizit die Mindestgarantien. Sie
werden erfüllt, wenn das Hauptszenario bzw. eine Erweiterung erfolgreich zum Ende des
Szenarios führen. Die Interessen aller Stakeholder müssen erfüllt sein.
16. Stakeholder haben Verhalten und Interessen
Ein Stakeholder ist Jemand bzw. Etwas mit Verhalten und Interessen. Als Stakeholder müssen
Hauptakteur und Akteure aufgelistet werden. Stakeholder können aber auch Akteure sein, die
in einem Use Case nicht auftreten, aber trotzdem Interessen an einen Use Case haben.
17. Der Hauptakteur ist der Akteur, der in einem Szenario im Vordergrund steht.
In der Regel ist es eine Person, die das Ziel des Use Cases verfolgt und das Verhalten des
Systems nutzt. Der Hauptakteur kann aber genauso gut das System oder ein Teil des Systems
sein, der eine Unterfunktion aufruft.
Strategie für das Kritiksystem: Der Hauptakteur ist ein Stakeholder. Sollte er daher nicht
mit seinen Interessen unter Stakeholder aufgelistet sein, ist vom Kritiksystem eine Warnung
auszusprechen. Sollte er im Szenario gar nicht in Erscheinung treten, ist offensichtlich etwas
nicht in Ordnung.
18. Der Auslöser des Use Cases ist ein Ereignis.
In der Regel ist das auslösende Ereignis der Hauptakteur, der eine Funktion des Systems
nutzen möchte. Dies ist aber nicht immer der Fall. So kann auch ein zeitliches Ereignis zum
Beispiel eine Backup-Funktion auslösen. Es ist ebenfalls denkbar, dass der Hauptakteur auf
Anlass eines Dritten handelt, zum Beispiel wenn ein Kunde über das Telefon bei einem
Mitarbeiter eine Bestellung aufgibt. In diesem Beispiel ist das auslösende Ereignis der Kunde,
der etwas bestellen möchte.
19. Im Hauptszenario wird der Verlauf bis zum Erreichen des Ziels im
Erfolgsfall beschrieben.
Der Ablauf vom auslösenden Event bis hin zum Ziel wird schrittweise aufgezeigt. Ein
Szenario sollte aus 3-9 Schritten bestehen. Zu viele Schritte lassen den Use Case
unübersichtlich und langwierig wirken, wo hingegen ein Szenario mit wenigen Schritten
unverhältnismäßig viel Aufwand verursacht. Lange Szenarios sind oft zu detailliert und
werden ungern gelesen. Man kann dieses Problem lösen, indem man sich fragt, wieso ein
Akteur dieses tut und kommt dadurch auf einen höheren abstrakten Level. Oft lassen sich
49

50
5. Erfahrungssammlung
Aufzählungen wie „Name, Anschrift, Telefon, …“ zu einem allgemeinen Begriff, wie
„persönliche Daten“, zusammenfassen. Es sollten keine GUI Elemente erwähnt werden.
Wichtig ist die Absicht des Akteurs, nicht seine Bewegung oder welche Schaltflächen er
drücken muss. Use Cases stellen keine Benutzeranleitung dar. Zu kurze Use Cases können zu
einem Use Case auf höherer Ebene zusammengefasst werden. Des Weiteren machen
Erweiterungen und Fehlerbehandlungen das Szenario unübersichtlich und komplizierter. Sie
haben daher im Hauptszenario nichts zu suchen und werden unter Erweiterungen aufgeführt.
Strategie für das Kritiksystem: Das System kann hier einiges prüfen. Sollten keine Schritte
vorhanden sein, so ist dieses ein Fehler. Ein Use Case ohne Schritte macht keinen Sinn.
Szenarios mit weniger als 3 bzw. mehr als 9 Schritten sind verbesserungsfähig und es sollte
eine Warnung angezeigt werden. Das Kritiksystem sollte auch bei zu langen Schritten
warnen. Es wird davon ausgegangen, dass eine Aktion mit mehr als 100 Zeichen zu lang ist.
Eine Warnung ist auch auszusprechen, wenn ein Schritt zu viele Aufzählungen besitzt. Dies
kann leicht festgestellt werden, indem die Kommata gezählt werden. Konkret soll das System
bei mehr als drei Kommata warnen. Punkte sollen nicht gezählt werden. Es ist zwar nicht
erlaubt, mehrere Sätze anzureihen, jeder Schritt sollte nur eine Aktion sein, aber da dies mit
Punkten bei Abkürzungen kollidiert, ist die sichere Erkennung nicht gegeben. Allerdings
sollten auch Abkürzungen vermieden werden, da diese eventuell nicht auf Anhieb verstanden
werden.
20. Die Schritte eines Szenarios sollten in einer einfachen Sprache gehalten
werden.
Die Sätze sollten möglichst einfach und für jeden verständlich geschrieben sein. Dabei ist ein
Satzaufbau in der Form „Subjekt … Prädikat … Objekt“ zu empfehlen, wobei ein Schritt in
der Gegenwart und in aktiv formuliert sein sollte. Es sollte stets klar sein, wer etwas tut, daher
ist es keine schlechte Idee, den Akteur durch eine entsprechende Spalte hervorzuheben. Es ist
auch wichtig, was er genau tut. Ungenaue Formulierungen sind daher zu vermeiden. Es sollte
nicht aus Sicht der Akteure beschrieben werden, was sie tun, sondern vielmehr aus der
Vogelperspektive, so dass eine unabhängige Sicht von Außen gewährleistet ist. Die Absicht
der Akteure ist wichtig, nicht seine Bewegungen. GUI Beschreibungen und Technologien
haben in einen Use Case nichts zu suchen, da sie nicht Bestandteil der
Anforderungserhebungsphase sind. Die Verwendung von Programmierkonstrukten wie „if“,
„end if“, „loop“, „while“ sind zu vermeiden, da sie Fachwissen voraussetzen und vom
Kunden, der die Anforderungsdokumente verstehen muss, nicht immer verstanden werden.
Zusätzlich leidet die Lesbarkeit, wenn if-Anweisungen geschachtelt werden.
Strategie für das Kritiksystem: Die GUI und Technologie-Neutralität könnte dadurch
gewährleistet werden, dass nach Schlüsselwörtern wie „if“, „while“, „Button“, „Menu“,
„Return“, „Java“ und „C++“ gesucht wird. Der Satzaufbau wird durch die Trennung von
Akteur und Aktion bereits sichergestellt. Es ist zwar schwer, einen Passivsatz zu formulieren,
dennoch möglich. Daher soll auf alle Formen von „werden“ geprüft werden. Ein Beispiel für
eine ungenaue Formulierung ist, „Der Benutzer gibt etwas ein.“ Die Frage ist, was er eingibt,
z. B. seinen Namen. Daher könnte das Kritiksysteme nach Wörtern wie „etwas“ oder
„jemand“ suchen.

5.2 Erfahrungen für Use Case Attribute
21. „Validieren“ ist besser als „Prüfen ob“.
Eine der wichtigsten Fragen ist stets, was das eigentliche Ziel ist. Zum Beispiel ist ein Ziel bei
einer Benutzereingabe, dass die Daten korrekt sind. Es muss also validiert werden ob bspw.
eine E-Mail Adresse gültig ist. Bei Aktionen die etwas prüfen, bleibt das eigentliche Ziel
verborgen. Was ist bspw. wenn eine E-Mail Adresse geprüft wurden ist? Läuft das Szenario
weiter, auch wenn die Adresse fehlerhaft ist? Das Haupterfolgszenario beschreibt
ausschließlich den Weg im Erfolgsfall, also den Fall, wenn etwas positiv validiert wird. Sollte
die Validierung fehlschlagen, so ist dieses unter den Erweiterungen aufzuführen.
Strategie für das Kritiksystem: Das Kritiksystem kann hier nach dem Schlüsselwort
„prüfen“ in allen Formen suchen.
22. Schritte in der Form „wenn … dann …“ sind Erweiterungen.
Wenn Bedingungen erfüllt sein müssen, so dass ein Schritt ausgeführt wird, hat man in der
Regel eine optionale Erweiterungen vorliegen. Erweiterungen haben im Hauptszenario nichts
zu suchen, da sie den eigentlichen Ablauf im Erfolgsfall stören. Die Behandlung von
Ausnahmebehandlungen stört ebenfalls den Fluss des Hauptszenarios und gehört daher auch
zu den Erweiterungen.
Strategie für das Kritiksystem: Es soll eine Kritik angezeigt werden, wenn Wörter wie
„wenn“ oder „falls“ in der Aktion zu finden sind.
23. Wiederholung von Schritten sollten am Ende dieser Schritte angeführt
werden.
Ein Szenario ist leichter zu lesen, wenn die wiederholbaren Schritte zunächst geschrieben
werden und mit einen weiteren Schritt in der Art „Benutzer wiederholt Schritte 3-5 solange,
bis …“ abgeschlossen werden. Wird nur ein einziger Schritt wiederholt, kann die Angabe im
Schritt selbst erfolgen.
Strategie für das Kritiksystem: Das Kritiksystem könnte versuchen dieses sicherzustellen,
indem es nach dem Wort „wiederholen“ in Kombination mit einer Schrittnummer sucht. Das
sichere Finden solcher Fälle ist aber schwierig und kann gegebenenfalls sogar gar nicht zu
treffen. Daher wurde diese Überprüfung nicht umgesetzt.
24. In einem Szenario können Use Cases eingebunden werden.
Im Szenario können auch komplette Use Cases als einen Schritt stehen. Das Szenario springt
dann zeitweise in den verlinkten Use Case und nach dessen Durchlauf wieder zurück. Das
Einbinden von Use Cases hat den Vorteil, dass Szenarios übersichtlicher werden. Wenn der
eingebundene Use Case eine Unterfunktion ist, die von mehreren Use Cases aufgerufen
werden, hat dies zu dem den Vorteil, dass das Szenario nur einmal aufgeschrieben wird und
somit auch weniger Verwaltungsaufwand verursacht.
Strategie für das Kritiksystem: Das Kritiksystem sollte hier überprüfen, ob die Ebene des
eingebundenen Use Cases niedriger ist als die des aufrufenden Use Cases. Ein Use Case auf
gleicher Ebene ist eigentlich nicht erlaubt. Da aber keine Zwischenebenen ausgewählt werden
51

52
5. Erfahrungssammlung
können, soll dieses hier erlaubt werden. Man stelle sich in so einen Fall einfach vor, dass
dieser Sub Use Case geringfügig unter dem Super Use Case liegt.
25. Erweiterungen sind mögliche Fehler und optionale Pfade.
Zunächst sollte das Hauptszenario komplett aufgeschrieben werden. Mit einem Brainstorming
kann man überlegen, was alles schief laufen kann. Hat man alle möglichen Fälle, können
eventuell einige zusammengefasst werden und schließlich können die dazugehörigen
Szenarios aufgeschrieben werden. Es muss klar gestellt sein, mit welchen Schritt im
Hauptszenario angeknüpft wird oder ob der Use Case komplett fehlschlägt. Eine Abdeckung
aller möglichen Fehler trägt zum Bau eines robusten Systems bei. Daher ist es sehr wichtig,
dass alle Erweiterungen aufgedeckt werden. Diese sind zum Beispiel alternative Pfade,
falsches Verhalten, falsche Eingaben, Time-outs, fehlende Ressourcen oder Systemabstürze.
Spätere Änderungen in der Implementierungsphase sind teuer. Erweiterungen können
ebenfalls erweitert werden, das allerdings schnell unübersichtlich wird. Daher sollte man
diese in einen weiteren Use Case auslagern. Wenn man zu viele Erweiterungen hat, sollte man
sich überlegen, ob man nicht einige zusammenfassen kann oder eine Auslagerung in einem
Unter Use Case vornehmen kann.
Strategie für das Kritiksystem: Das Kritiksystem kann eine Warnung geben, wenn es zu
viele Erweiterungen gibt und empfehlen, einen Unter Use Case anzulegen oder Erweiterungen
zusammenzufassen. Ein Use Case kann in der Regel immer irgendwo schief laufen, daher soll
auch eine Warnung ausgesprochen werden, wenn ein Use Case keine Erweiterung besitzt.
26. Eventuell sind die Details für einen Fehlschlag uninteressant.
Möglicherweise blähen Detailbeschreibungen die Erweiterungen nur unnötig auf.
Beispielsweise kann es irrelevant sein, ob der Benutzer keine Schreibrechte oder nicht genug
Speicher hat, wichtig ist eventuell nur, dass das Schreiben einer Datei fehlgeschlagen ist.
Strategie für das Kritiksystem: Wenn ein Schritt sehr oft erweitert wird, soll das
Kritiksystem warnen und vorschlagen, die Erweiterungen zusammenzufassen.
27. Ein System muss die Bedingungen prüfen können.
Das System muss die Erweiterungsbedingungen überprüfen können. Beispielsweise ist eine
Bedingung wie „Der Benutzer hat seine PIN vergessen“ nicht prüfbar. Richtiger wäre da der
Ablauf eines Timers: „Der Benutzer hat nach 60 Sekunden keine Eingabe getätigt.“
28. Ein gemeinsames Subverhalten mehrerer Use Cases gehört in einen
einzelnen Use Case.
Es bringt wenig, gleiche Erweiterungen und Subverhalten in jeden Use Case redundant
aufzuführen. Dies erhöht den Verwaltungsaufwand unnötig und birgt das Risiko der
Inkonsistenz. Daher sollte in solchen Fällen ein Use Case geschrieben werden, dass als
Funktion aufgerufen werden kann. So lässt sich ein gemeinsames Subverhalten erkennen und
spart bei der Implementierung Zeit. Sollte sich eine Änderung ergeben, muss sie nur an einer
Stelle durchgeführt werden.

5.2 Erfahrungen für Use Case Attribute
29. Variationen haben das gleiche Ziel, verwenden aber unterschiedliche Mittel.
Ein Ziel, zum Beispiel „Ware bezahlen“ kann auf unterschiedlichen Wegen erreicht werden.
Idealerweise wird das Ziel nur auf einer abstrakten Ebene beschrieben. Unter Variationen
werden die unterschiedlichen Mittel dann explizit aufgelistet, also zum Beispiel „Bar,
Einzugsermächtigung oder Kreditkarte“. Variationen haben kein Szenario, da lediglich die
Art und nicht der Weg der Variation interessant ist.
30. Die Priorität zeigt die Wichtigkeit des Use Cases.
Mit der Angabe einer Priorität kann festgehalten werden, wie wichtig ein Use Case für das
Projekt ist, bzw. wie wichtig eine Funktionalität für den Kunden ist. Je höher die Priorität ist,
desto eher sollte sie implementiert werden. Use Cases mit sehr niedriger Priorität könnten bei
Zeitnot entfallen.
Strategie für das Kritiksystem: Wenn ein Use Case im Hauptszenario als Funktion
eingebunden wird, läuft ein Szenario ohne die Implementierung dieser Funktion nicht.
Folglich muss die Priorität mindestens so hoch sein wie eines der aufrufenden Use Cases.
Wird hingegen ein Use Case als Erweiterung eingebunden, so ist sie möglicherweise optional
und darf somit nicht wichtiger als der aufrufende Use Case sein.
31. Die Performance gibt die Durchlaufsdauer eines Use Cases an.
Die Durchlaufsdauer eines Use Cases kann unter einer Sekunde liegen, oder sogar mehrere
Monate in Anspruch nehmen. Daher kann es nützlich sein, sich darüber im Klaren sein. Denn
wenn ein Use Case mehrere Tage dauert, ist vielleicht eine Session notwendig.
32. Die Verwendungshäufigkeit spiegelt die Wichtigkeit des Use Case wieder.
Wird ein Use Case laufend verwendet, ist diese Funktion vermutlich wichtiger als ein Use
Case, der nur einmalig verwendet wird. Wer Klarheit über die Verwendungshäufigkeit hat,
kann die Wichtigkeit eines Use Case besser bestimmen.
Strategie für das Kritiksystem: Sollte ein Use Case sehr oft verwendet werden, aber nur
eine geringe Priorität besitzen, ist etwas eventuell nicht korrekt. Ähnlich verhält es sich, wenn
ein wichtiger Use Case zu selten genutzt wird. In diesen Fällen muss das Kritiksystem dieses
durch eine Warnung hervorheben.
53

54
6. Tool
6.1 Beschreibung von Schnittstellen und Erweiterungsstellen
Bei der Planung und Implementierung des Tools wurde auf Erweiterbarkeit geachtet, so dass
Weiterentwicklungen ohne bzw. nur mit wenigen Änderungen des bestehenden Systems
erfolgen können. Teilweise wurde die Erweiterbarkeit bereits soweit vorbereitet, dass dies
über die grafische Oberfläche erfolgen kann.
6.1.1 Das Use Case Template
Es ist ohne großen Aufwand möglich, beliebige weitere Use Case Attribute über die Grafische
Benutzeroberfläche anzulegen. Sofern keine Auswahlbeschränkung angegeben wird, erscheint
im Formular ein Textfeld, über das ein beliebiger Text eingegeben werden kann. Wird eine
Auswahlbeschränkung vorgenommen, so erscheint ein Drop-Down-Menu, über das die durch
Komma getrennten Elemente ausgewählt werden können. Auf dieser Weise kann bereits eine
Vielzahl von zusätzlichen Attributen verwendet werden. Das Use Case Modell lässt dabei
jedoch auch beliebige Objekte zu. Sollte ein komplexeres Objekt als eine Zeichenkette mit
oder ohne Auswahlbeschränkung abgespeichert werden, muss der Quellcode erweitert
werden. Bei einem Attribut mit tabellarischem Charakter kann die Klasse
UseCaseTablePanel erweitert werden. Sie verfügt über Buttons, um neue Zeilen
hinzuzufügen, Zeilen zu löschen und Zeilen zu verschieben. Bei Bedarf können weitere
Buttons eingefügt werden. Die Methoden setData und getData müssen erweitert werden,
um einen neuen Datentyp in der Tabelle darzustellen bzw. eingegebene Daten wieder ins
Modell zu übernehmen.
6.1.2 Die Erfahrungsbasis
Wie bereits in Kapitel 4.5.3 beschrieben, ist auch das Erfahrungsmodell auf eine beliebige
und ständige Erweiterung ausgelegt. Es können nicht nur neue Erfahrungen eingefügt werden,
sondern auch bestehende können kommentiert werden. Dies kann in beiden Fällen über die
grafische Oberfläche erfolgen, wobei der Benutzer bei einer neuen Hilfe den Kontext
angegeben muss und bei bestehenden Hilfen und Kritiken der Bezug zur erweiterten
Erfahrung erhalten bleibt. Auf dieser Weise bleibt auch während der Evolutionary Growth (s.
Kapitel 2.10) die Erfahrungsbasis einigermaßen ordentlich. Dies ist unbedingt notwenig, da
bei einer ungeordneten Erfahrungsbasis die Relevanz und Wichtigkeit deutlich schwerer
sicherzustellen ist. Darüber hinaus wird dem Erfahrungsingenieur bei einem Reseeding viel
Arbeit abgenommen.
Der Austausch von Erfahrungen soll zunächst manuell erfolgen. Dazu kann der Benutzer über
die grafische Benutzeroberfläche mehrere Erfahrungsbasen laden und das System übernimmt
dabei neue Erfahrungen und ergänzt noch nicht vorhandene Erweiterungen selbständig.

6.1 Beschreibung von Schnittstellen und Erweiterungsstellen
Neue Kritiken können ebenfalls hinzugefügt werden, wobei das bestehende Modell in keiner
Weise geändert werden muss. Der Erfahrungsingenieur muss eine Klasse schreiben, die das
Interface CriticChecker implementiert. Die Klasse muss über einen parameterlosen
Konstruktor und die Methoden setParamString(String) und
checkForProject(Project) verfügen.
Die erste Methode ist für optionale Parameter gedacht und kann beispielsweise für eine
individuelle Konfiguration des Kritiküberprüfers verwendet werden. Auf diese Weise kann
die Klasse dynamisch geändert werden, ohne dass sie umgeschrieben werden muss. Dies ist
zum Beispiel nützlich, wenn in einem Fall neun Schritte im Szenario als Maximum angesehen
werden, in einem anderen Projekt aber zwölf. Eine Schlüsselwortsuche ist in der Regel
sprachabhängig. Wo im Deutschen nach „klicken“ gesucht werden muss, muss im Englischen
nach „click“ gesucht werden. Wäre diese Methode nicht vorhanden, müsste für
unterschiedliche Projekte und unterschiedliche Sprachen eine eigene Klasse geschrieben
werden, obwohl sie sich im Verhalten nicht unterscheiden. Die Eingabe von Parameter erfolgt
über die Grafische Benutzeroberfläche.
Die zweite Methode, checkForProject(Project), übernimmt schließlich die
Überprüfung für das übergebene Projekt. Dabei sollte sie für jede gefundene Stelle ein
ContextObject erzeugen und alle gefundenen Stellen am Ende zurückgeben. Zur
Verdeutlichung soll im Folgenden eine Beispielimplementierung gezeigt und besprochen
werden. Es soll überprüft werden, ob das Szenario mehr als neun Schritte hat.
Listing 1: Beispielimplementierung des CriticCheckers
55

56
6. Tool
Die Zeilen 1-11 zeigen die Methode setParameter. Wie der Parameter-String aufgebaut
wird, ist letztendlich Sache des Implementierers. Es wird jedoch empfohlen, eine leserliche
Strukturierung vorzunehmen, woraus hervorgeht, welche Bedeutung einzelne Werte haben,
zum Beispiel in der Form
stepcount=9;parameter2=wertxy;
Über die statische Hilfsmethode Utilities.getParameterFromString, die auch für
zukünftige Implementierungen genutzt werden kann, wird der gewünschte Parameter
extrahiert. Schließlich wird versucht, den Pater in eine Zahl umzuwandeln. Sollte die
Umwandlung schief gehen, wird nur eine Ausgabe in die Konsole geschrieben. Es wäre
überaus ärgerlich, wenn der Benutzer dazu eine Fehlermeldung zu Gesicht bekommt, da er
damit nichts anfangen kann bzw. die Implementierung nur schwer ändern kann. Es ist auch
ärgerlich, wenn er wiederholt eine solche Meldung erhält und bei der Arbeit gestört wird.
Lediglich der geschulte Benutzer oder der Erfahrungsingenieur interessiert sich für so eine
Meldung. Es sollte daher darauf geachtet werden, dass der Wert in der Implementierung einen
Standardwert hat.
Die eigentlich interessante Methode ist die nächste in den Zeilen 13-35. Da mehrere Stellen
während der Überprüfung gefunden werden können, wird ein Vector angelegt, der die
Zwischenspeicherung übernimmt. In Zeile 16 werden alle Use Cases genommen und jeweils
einzeln überprüft. Zeile 18-19 holt sich das gewünschte Attribut, also das
Haupterfolgsszenario. Es muss auf null überprüft werden, da das Attribut eventuell
deaktiviert sein könnte. Weiterhin muss der Value-Wert kontrolliert werden und ob er Instanz
der erwarteten Klasse ist. In diesem Fall ist das Hauptszenario ein Attribut, dass auf jeden Fall
existiert und auch eine erwartete Instanz ist. Für Implementierungen die andere Attribute
betreffen, ist es aber durchaus möglich, dass dieser nicht vorkommt. Sollte diese Überprüfung
fehlschlagen, also hat man das Attribut nicht gefunden, könnte man ggfs. den Use Case
kritisieren, der nicht über ein benötigtes Attribut verfügt.
In Zeile 23 erfolgt schließlich die Überprüfung, ob das Szenario mehr als die gewünschten
Schritte, zum Beispiel neun, hat. In so einen Fall wird ein ContextObject erzeugt. Dabei
wird der Pfad zur Stelle übergeben, nämlich das Projekt, der Use Case und das fehlerhafte
Szenario selbst. Bei einer Kritik, die zum Beispiel ein gesamtes Projekt betrifft, wird lediglich
das Projekt übergeben, die anderen Werte werden auf null gesetzt. Sollte eine Kritik einen
Teil eines Attributes betreffen, also zum Beispiel einen Schritt, kann dieser über den vierten
Parameter angegeben werden. In diesem Fall ist dieser jedoch null, da das Szenario
fehlerhaft ist.
Dieses erzeugte ContextObject wird dem am Anfang initialisierten Vector zur
Zwischenspeicherung übergeben. Es folgt die Überprüfung der weiteren Use Cases und für
jedes gefundene Szenario, dass mehr als die erlaubten Schritte hat, wird ein neues Objekt
angelegt und zwischengespeichert. Am Ende werden die gefundenen Stellen zurückgegeben.
Es wurde bei der Implementierung auf Robustheit geachtet. So kann von ausgegangen
werden, dass die übergebenen Parameter für beide Methoden nicht null sein kann, eine
Überprüfung ist daher nicht erforderlich. Als Rückgabewert bei der Methode
checkForProject wird ein ContextObject-Array erwartet. Wenn kein Kritikpunkt
gefunden wurde, hat das Array idealerweise die Länge 0. Es ist aber auch ein null-Wert
möglich, dieser wird von der aufrufenden Methode abgefangen.

6.1 Beschreibung von Schnittstellen und Erweiterungsstellen
6.1.3 CriticChecker
Das Schreiben einer eigenen Klasse, die das Interface CriticChecker implementiert, ist
gegebenenfalls gar nicht notwendig. Möchte man beispielsweise eine Kritik anlegen, die nach
Schlüsselwörtern in den Hauptszenario sucht, kann dazu die bestehende allgemeine Klasse
WordMatcherForScenario verwendet werden. Sie nimmt einen Parameter entgegen die
die Wörter, getrennt durch einen Komma, im Hauptszenario sucht. Dies ist ganz nützlich,
denn der Benutzer braucht in so einen Fall keine neue Klasse zu schreiben und kann die Kritik
direkt über die grafische Benutzeroberfläche eingeben.
Auch bestehende Kritiken lassen sich durch ändern eines Parameters problemlos anpassen.
Sollte man der Ansicht sein, dass ein Szenario 12 Schritte haben darf, muss dazu lediglich der
Parameter geändert werden. Dies kann direkt in der GUI erfolgen, so dass der Benutzer keine
neue Klasse schreiben muss.
6.1.4 Der Assistent
Der Assistent wurde durch einen JEditorPane mit einem HTMLEditorKit realisiert.
Auf dieser Weise ist nicht nur eine fast beliebige Darstellung der Erfahrungen möglich,
sondern die Anzeige ist auch erweiterbar. Beispielsweise können zusätzliche Links eingeführt
werden, die beliebige Aktionen auslösen können. Dazu muss zum einen ein Link eingefügt
werden, zum anderen die Methode hyperlinkUpdate erweitert werden. Als Konvention
wurde festgelegt, dass diese Links mit einer Zeichenketten als Befehl anfangen, gefolgt von
einem Doppelpunkt und einen beliebigen Parameterstring. Beispielsweise sieht der Link, um
die fünfte Erfahrung in der Anzeige zu erweitern, dann folgendermaßen aus: „extend:5“.
Neben Links können in HTML natürlich auch Formularelemente eingebunden werden, um
beispielsweise eine Suche zu realisieren.
6.1.5 Die Persistenzschicht
Die Persistenzschicht ist durch eine eigene Speicherroute realisiert wurden. Es können
beliebige Objekte gespeichert werden, die ein Interface DiscableObject implementieren.
Dies ist zum Beispiel bei den Erfahrungen aber auch den Use Cases der Fall. Das Interface
setzt die Methoden getClassName, getAttributes und setAttributes voraus.
Die erste Methode liefert den Pfadnamen der Klasse, so dass eine Wieder-Instanzierung des
Objekts möglich ist. Dabei wird ein Konstruktor erwartet, das eine java.util.Map als
Parameter hat. In einer solchen Mappe werden die Key-Value-Beziehungen gespeichert. Die
Schlüssewerte sind dabei Strings, die dazu abgelegten Werte entweder ebenfalls ein String,
ein DiscableObject oder ein Array von DiscableObjecten. Die Methode
getAttributes bzw. setAttributes müssen eine solche Mappe von Wertebeziehung
erzeugen bzw. verarbeiten. Sollten also weitere Attribute oder Klassen angelegt werden, muss
die Speicherroutine nicht erneut angefasst werden. Die Verarbeitung dieser Attribute müssen
lediglich in den beiden Methoden hinzugefügt werden und eine neue Klasse die gespeichert
werden soll, muss diese Methoden implementieren. Auf dieser ist eine Erweiterung möglich,
ohne dass die Speicherung erweitert werden muss.
57

58
6. Tool
Die Speicherroutine erzeugt dann eine XML-Datei, die die gespeicherten Objekte enthält.
Dazu wird die Bibliothek von [Jdom06] verwendet, mit der eine leichte Erstellung von XML-
Dateien möglich ist. Das Schema zu einem gespeicherten Projekt und das für die
Erfahrungsbasis befinden sich im Anhang. Um die Projekt- und Erfahrungsverwaltung über
den Server zu lösen, kann die Speicherroutine erweitert werden, so dass zur Übertragung auch
XML verwendet werden kann.
6.1.6 Mehrsprachigkeit
Um die Mehrsprachigkeit zu gewährleisten, wurde eine Sprachdatei im XML-Format
eingeführt, die sämtliche sprachspezifischen Titel enthält. So ist eine Übersetzung in andere
Sprachen möglich, ohne das Programm selbst umschreiben zu müssen. Es wurde darauf
geachtet, möglichst aussagekräftige Namen zu verwenden. Die Namen mögen zwar etwas
lang erscheinen, so ist aber bei einer Bearbeitung eine eindeutige Identifizierung möglich. Bei
einer Übersetzung darf nicht vergessen werden, dass auch die Erfahrungsbasis übersetzt
werden muss.
In einer Property-Datei werden auch andere Einstellungen wie das Datumsformat abgelegt. So
ist es möglich, das Datum statt in der deutschen Schreibweise auch in eine beliebige andere
Schreibweise zu formatieren. Auch hier muss das Programm nicht umgeschrieben werden.
6.1.7 Export-Filter
Das Exportieren, wo derzeit nur ein Export in HTML möglich ist, kann um weitere
Dateiformate erweitert werden. Dazu wurde ein Interface ExportFilter geschrieben, dass
über die Methoden getData und getFileSuffix verfügt. getData erhält als
Parameter das gesamte Projekt und die zu exportierenden Use Cases und sollte diese in seinen
Dateiformat darstellen. Die Daten gibt er als byte-Array zurück, so dass auch binäre
Formate möglich sind. getFileSuffix wird verwendet, wenn der Benutzer einen
Dateinamen ohne Endung angegeben hat.
Ein neuer Export-Filter muss also dieses Interface implementieren und sollte von der Klasse
javax.swing.filechooser.FileFilter abgeleitet sein, die noch eine
Implementierung der abstrakten Methoden accept und getDescription benötigt,
accept um zu überprüfen, ob eine übergebene Datei akzeptiert wird, getDescription
um einen benutzerfreundlichen Namen zu vergeben. So ist es dann insgesamt möglich, den
neu geschriebenen Filter dem Fenster zu übergeben, über welches der Benutzer einen
Speicherort und Dateinamen wählen kann und wo der Benutzer nun das gewünschte Format
auswählen kann.
6.2 Kurze Benutzereinführung
Wie im Entwurf bereits beschrieben besteht die Oberfläche aus verschiedenen Bereichen. Im
linken Bereich wird das Projekt mit seinen Use Cases dargestellt. Im Zentrum findet die

6.2 Kurze Benutzereinführung
Bearbeitung eines geöffneten Use Cases statt. Im oberen rechten Bereich ist eine grafische
Visualisierung des aktuellen Use Cases zu sehen. Der Assistent gibt im unteren rechten
Bereich Hilfestellungen und erklärt verschiedene Probleme. Eine Zusammenfassung aller
Probleme ist im ProblemView direkt unter der Konstruktion zu finden. Alle Bereiche, also
auch der Assistent und die ProblemView lassen sich auf Wunsch ausblenden.
Der Projektbaum
Abbildung 24: Die Grafische Benutzeroberfläche
Im Projektbaum können Use Cases durch Auswählen zur Bearbeitung geöffnet werden. Es
öffnet sich ein Formular bzw. das bereits geöffnete Formular wird mit den Daten des
ausgewählten Use Cases ausgefüllt. Mit dem Auswählen eines Attributs lässt sich direkt zum
Attribut springen, dabei wird das Formular automatisch gescrollt.
Mit der rechten Mautaste lassen sich neue Use Cases anlegen bzw. bestehende löschen. Auch
das Sortieren ist möglich. Dazu kann zwischen den Attributen „Use Case ID“, „Titel“,
„Ebene“, „Status“ und „Priorität“ gewählt werden, wobei die ersten beiden alphanumerisch
sortiert werden, die übrigen nach der Reihenfolge der auswählbaren Werte im Formular.
Im Projektbaum erfolgt auch die Markierung von fehlerhaften Use Cases bzw. Attribute.
Dazu werden ähnlich wie in Eclipse ([Ecl06]) entsprechende Icons an den Knoten gesetzt und
zwar so, dass zum Fehler navigiert werden kann.
59

60
Das Formular
6. Tool
Die Bearbeitung des Use Cases erfolgt in einen Formular. Dazu werden die zuvor
geschriebenen Werte geladen und angezeigt. Der Benutzer kann bestehende Texte frei
editieren und im Falle eines Auswahlfeldes eine andere Option auswählen. Die Stakeholder,
Szenarios, sowie die Variationen werden in einer Tabelle dargestellt. Über die Buttons auf der
rechten Seite kann der Benutzer weitere Akteure, Schritte bzw. Variationen einfügen, löschen,
oder verschieben. Des Weiteren lässt sich im Falle des Hauptszenarios ein bzw. mehrere
Schritte erweitern, oder ein Use Case verlinken. Durch Drücken der Shift-Taste und anklicken
eines eingebundenen Use Case kann man zum verlinkten Use Case springen.
Auf Grund der Übersichtlichkeit lassen sich sie die Erweiterungen ein- und ausklappen. Im
ersten Feld wird der referenzierte Schritt angegeben und im darauf folgenden Feld lässt sich
die Bedingung angeben. Es kann ein Szenario angegeben werden, wenn die Erweiterung
ausgeklappt ist. Eine Erweiterung lässt sich durch das Icon neben der Bedingung entfernen.
Eine weitere Besonderheit stellen die Dateianhänge dar. Beim Hinzufügen eines
Dateianhanges wird die ausgewählte Datei in einen Ordner kopiert. Dieser Ordner befindet
sich im gleichen wie die Projektdatei und trägt den gleichen Namen dieser Datei gefolgt von
einem „_attachments“. Beim Kopieren des Projekts auf einen anderen Datenträger, muss
dieser mitkopiert werden, da die Dateianhänge sonst verloren gehen. Die Dateianhänge lassen
sich durch gedrückter Shift-Taste und anklicken des Anhangs direkt öffnen (Vorraussetzung
ist Windows XP).
Auch im Formular werden Fehler und Warnungen durch entsprechende Icons an den
Attributen angezeigt.
Overview
Im so genannten Overview wird der Use Case grafisch dargestellt. Dazu werden auch die
verlinkte Use Cases angezeigt, die durch einen Doppelklick geöffnet werden können
Assistent
Der Assistent zeigt je nach Kontext die entsprechenden Hilfestellungen, Warnungen und
Fehler an. Bearbeitet man beispielsweise gerade den Titel, so werden nur Erfahrungen
angezeigt, die dazu nützlich sein könnten. Der Assistent zeigt nur einen Teaser an. Möchte
man mehr wissen, muss man auf den entsprechenden Link drücken. Der Assistent erläutert
daraufhin die Erfahrung ausführlicher und gibt gegebenenfalls Hilfestellungen, die beim
Lösen des Problems helfen sollen.
Ist der Benutzer mit der Erfahrung nicht einverstanden bzw. hat selbst Erfahrungen gemacht,
so kann er die bestehende Erfahrung kommentieren. Dazu kann er eine Kurzbeschreibung und
eine ausführliche Erläuterung eingeben. Diese werden dann unter der bestehenden angezeigt.
Sollte eine Erfahrung nicht nützlich sein, so hat der Benutzer die Möglichkeit, diese für einen
Use Case oder für alle Fälle zu ignorieren.
Eventuell gibt es mehrere Erfahrungen. Daher kann er durch die entsprechen Buttons unter
der Anzeige zur der nächsten springen bzw. wieder zurück navigieren.

6.2 Kurze Benutzereinführung
Die ProblemView
Die Problemsicht fasst alle Probleme im Projekt zusammen. Der Benutzer kann durch die
Kurzbeschreibung erkennen, um was für ein Problem es sich handelt und durch Angabe des
Use Cases und des Attributes wo der Fehler ist. Durch einen Doppelklick kann er direkt zum
Fehler springen. Durch Anklicken der Spaltennamen können die Kritiken nach Art
(Fehler/Warnung), Kurzbeschreibung, Use Case oder Attributname sortiert werden.
Das Menu
Im Datei-Menu kann der Benutzer ein neues Projekt anlegen, ein Projekt laden, oder ein
geöffnetes speichern. Auch das Exportieren ist möglich, wobei er zunächst die gewünschten
Use Cases und dann ein Format auswählen kann. Derzeit wird jedoch nur HTML unterstützt.
Das Use Case Diagramm in der grafischen Übersicht kann als Bild im JPEG-Format
exportiert werden. Über Beenden kann das Programm geschlossen werden.
Über das Bearbeiten-Menu sind die aus anderen Standardanwendungen gewohnten
Funktionen wie Ausschneiden, Kopieren und Einfügen möglich. Ferner kann der Benutzer
Use Cases in die Zwischenablage kopieren und in Anwendungen wie Word, OpenOffice oder
Mozilla Composer einfügen.
Unter Projekt kann der Benutzer neue Use Cases anlegen, Titel und Beschreibung des
Projekts ändern und das Template bearbeiten. Bei einer Bearbeitung des Templates kann der
Benutzer bestehende Attribute deaktivieren, neue hinzufügen und wieder löschen, sowie die
Reihenfolge ändern. Gibt der Benutzer eine Auswahlbeschränkung ein, so ist bei der
Bearbeitung der Use Cases nur eine Auswahl zwischen den angegebenen Optionen möglich.
Ferner kann sich der Benutzer über das Projekt-Menu die letzten Änderungen bzw. die
Änderungen seit einem freidefinierbaren Zeitpunkt anzeigen lassen. Dazu werden die
Änderungen im Projektbaum hervorgehoben.
Die Erfahrungsbasis lässt sich über Einstellungen bearbeiten. Die Erfahrungen werden dazu
mit Icon in einer Liste angezeigt und sofern Kommentare verfügbar sind, werden sie unter
den Erfahrungen baumartig angehängt. Durch einen Doppelklick lässt sich eine Erfahrung im
Detail anzeigen und editieren. Über die Buttons auf der rechten Seite können neue
Erfahrungen hinzugefügt, (de-) aktiviert, angezeigt und gelöscht werden. Es lassen sich neue
Erfahrungen einspielen und die eigene Erfahrungsbasis exportieren.
61

62
7. Ausblick
Eine Software ist nie fertig und dies gilt für Domainorientierte Entwurfsumgebungen umso
mehr. Denn die Erfahrungsbasis weist bisher nur einen Grundschatz auf. Ob diese
Erfahrungen nützlich sind, kann erst durch die Nutzung in der Praxis festgestellt werden,
wodurch neue Erfahrungen entstehen und die Erfahrungsbasis weiter wächst.
Die Bewertung der Erfahrungen beruht derzeit auf einen statischen Wert. Es machte zum
derzeitigen Zeitpunkt wenig Sinn, eine Bewertung aus anderen Quellen zu beziehen. Sollte
das Tool jedoch um eine Serverkomponente erweitert werden, das den Austausch der
Erfahrungen übernimmt, wäre die Einführung einer Erfahrungsbewertung vorteilhaft, über die
dann eine dynamische und sicherlich praxistauglichere Relevanzbestimmung erfolgen kann.
Die Einführung der Serverkomponente hätte auch den Vorteil, dass Erfahrungen leichter
ausgetauscht werden können und alle Benutzer von den Erfahrungen anderer Benutzer
profitieren können.
Die Akzeptanz des Tools wurde bisher nur in einem kleinen Kreis getestet. In wie fern das
Tool in umfangreichen Projekt Verwendung findet, soll von der Fachgruppe Software
Engineering im Softwareprojekt herausgefunden werden.
Die Erweiterung des Tools um eine Rechtschreibprüfung könnte auch vorteilhaft sein. Das
Tool ermöglicht viele Funktionen die auch mit Word gelöst werden könnten, aber eine
Überprüfung der Rechtschreibung fehlt. Die Integration in Eclipse könnte die Akzeptanz auch
weiter steigen, da der Benutzer nicht mehrere Programme geöffnet haben muss.
Sobald es auch die ersten fertig geplanten Projekte gibt, ist die Erweiterung um eine Suche
nach ähnlichen Use Cases in Erwägung zu ziehen. Die Übernahme von wiederkehrenden
Anforderungen aus alten Projekten stellt eine wesentliche Arbeitserleichterung dar. Es können
dabei auch Fehlerbehandlungen übernommen werden, an die der Benutzer eventuell nicht
gekommen wäre. Immer wiederkehrende Use Cases sind zum Beispiel „Einloggen“,
„Ausloggen“, „Öffnen“, „Speichern“ oder „Drucken“. Natürlich müssen diese Use Cases
kontrolliert und angepasst werden, da sie aus einem anderen Projekt stammen. Sicherlich hat
man auch neue Einfälle oder hat Erfahrungen mit den alten Use Cases gemacht. Auf jeden
Fall stellt diese Funktionalität eine nicht zu vergessene Zeitersparnis dar und der Benutzer
kann sich auf andere wichtigere Use Cases konzentrieren.
In der jetzigen Entwicklungsumgebung fehlt eine Simulationskomponente. Es wäre denkbar,
aus den Use Cases ein grafisches Prozessmodell abzuleiten, das dann simuliert werden
könnte. Eventuell ließe sich aus den erstellten Use Case diverse Metriken berechnen, um zu
sehen, ob die Planung qualitativ gut ist. Diese Metriken könnten dann auch dazu verwendet
werden, um herauszufinden, ob eine andere Lösung besser ist als die bestehende. Idealerweise
würde das System selbständig verschiedene Varianten untersuchen und den Benutzer dann
eine Empfehlung geben. Mit Hilfe der Use Case Point Methode ließe sich bspw. die
Realisierungskosten berechnen, so dass eine bessere Unterstützung im Entwicklungsprozess
erzielt werden könnte.

8. Fazit
Zu Beginn dieser Arbeit wurde eine Einführung in die Problematik gegeben. Es wurde u. a.
erklärt, was Use Cases sind und was Erfahrungen und Kritik sind. Die Nutzung und
Weitergabe von Erfahrungen wurde durch einen Kreislauf verdeutlicht. Darauf aufbauend
wurde eine Einführung in Benutzer-Unterstützungssystemen gegeben, woraus sich dann die
Domainorientierten Entwurfumgebungen, ableiten lies. Ein wesentliches Merkmal dieser
speziellen Benutzer-Unterstützungssysteme ist das SER-Prozessmodell, in der der
Erfahrungsschatz laufend erweitert und verbessert wird.
Im Folgenden wurde gezeigt, wie Erfahrungen helfen können, Anforderungen besser zu
erheben. Dazu wurde aufbauend auf Domainorientierte Entwurfsumgebungen ein System
konzipiert, das Hilfestellungen gibt ohne den Benutzer bei der Arbeit zu stören. Dabei wurde
auch untersucht, wie andere Anwendungen dieses Problem lösen. Es wurde eine kleine
Erfahrungsbasis geschaffen, das als Saat des Erfahrungskreislaufes dient. Die Einhaltung
dieser Erfahrungen soll durch ein Kritiksystem gewährleistet werden. Dazu wurden
Möglichkeiten vorgestellt, wie das Kritiksystem Mängel feststellen kann.
Das Kritiksystem analysiert die Arbeit des Software Ingenieurs laufend und zeigt weniger
gute Stellen auf mehrere Weisen an. Ein Assistent erklärt Kritiken und gibt verschiedene
Lösungsmöglichkeiten. Der Benutzer, der nur einen beschränkten Überblick über das Projekt
hat und nicht immer auf alles achten kann, wird dabei in seiner Arbeit unterstützt. Das
limitierte Wissen wird durch die Erfahrung anderer Benutzer erweitert, so dass der Benutzer
insgesamt auf einen größeren Erfahrungsschatz zurückgreift als ein einzelner Nutzer. Ferner
wird bei der Bearbeitung auch ein Lernprozess durchlaufen. Gerade Unerfahrene können so
vom Wissen anderer profitieren.
Zurückblickend kann man sagen, dass mit Benutzerunterstützungssystemen sehr viel möglich
ist. Die Unterstützung des Benutzers und die Usability kann ins Unendliche getrieben werden,
was letztendlich auch zu Verzögerungen in der Fertigstellung des Tools führten. Auf Grund
der Zeitbegrenzung musste daher leider auf sehr viele Funktionen verzichtet werden. Da das
Tool aber auf Erweiterungen ausgelegt wurde, können diese in einer späteren Entwicklung
nachgeholt werden.
Auf Grund der Komplexität und Schwierigkeit einer Domainorientierten Entwurfsumgebung
könnte die Befürchtung von Ning [Nin94] eintreten. Durch gute Planung und Anwendung
modernster Techniken kann jedoch ein Scheitern entgegen gewirkt werden. Die Umsetzung
einer Domainorientierten Entwurfsumgebung lohnt sich auf jeden Fall, da in einen solchen
System Fehler und mögliche Probleme frühzeitig entdeckt werden. Je früher Missstände
gefunden werden, desto einfacher und günstiger ist eine Korrigierung. Mit dem umgesetzten
Tool können Fehler bereits vor den ersten Reviews aufgedeckt werden. Das Tool minimiert
dabei die Distanz zwischen Benutzer und Entwurfsumgebung, da es selbständig Erfahrungen
heraussucht und nur relevante anzeigt. Man kann auf das Wissen und die Erfahrungen anderer
Entwickler zurückgreifen und so insgesamt bessere Ergebnisse erzielen.
Daher lassen sich auch die Befürchtungen von Sutcliffe in [Sut94] entkräften. Das Ergebnis
eines Artefakts, dass in einer Domainorientierten Entwurfsumgebung geschaffen wurde, hier
also eines Use Cases, ist zweifelsfrei besser. Ein Benutzer ist nur ein Mensch und macht
Fehler oder kann den einen oder anderen Fehler übersehen. Durch ein System, das den
Benutzer in seiner Arbeit unterstützt und dabei Fehler, aber auch mögliche Probleme
63

64
8. Fazit
selbständig anzeigt, können diese zumindest minimiert werden. Durch den Zugriff auf die
Erfahrungen anderer Benutzer lassen sich nicht nur bessere Ergebnisse erzielen, sondern auch
die Qualität wird laufend gesteigert, weil die Softwareingenieure bei der Entwicklung den
Erfahrungsschatz und damit auch ihren Wissensstand ständig erweitern.
Insgesamt lässt sich sagen, dass die Erwartungen an das Tool erfüllt wurden. Dieses konnte
durch eine kleine Umfrage (s. Anhang D) bei Softwareentwicklern belegt werden. Da nur 9
Personen das Tool getestet haben, ist die Umfrage nicht sehr aussagekräftig. Die Personen
haben sicherlich auch kein vollständiges Projekt geplant. Es lässt sich jedoch eine klare
Tendenz erkennen. So waren sich alle einig mit dem Tool mindestens genau so gute oder
bessere Use Cases zu schreiben. Die Mehrheit der Personen hatte den Eindruck, nicht mehr
Zeit oder mehr Arbeit als üblich zu benötigen. Und einige würden das Tool sogar einsetzen.
Auch die Usability konnte überprüft werden. Die Mehrheit der Benutzer konnte die
Funktionen des Tools intuitiv finden. Mit der Darstellung der Kritiken und Hilfen waren alle
zufrieden.

Abbildungsverzeichnis
Abbildung 1: Use Case Diagramm: Bankautomat ..................................................................... 9
Abbildung 2: Use Case Diagramm: Detaillierter Bankautomat................................................. 9
Abbildung 3: Erfahrungskreislauf, vgl. [Sch00] und [Lir04]................................................... 14
Abbildung 4: Erfahrungsweitergabe, vgl. [Buc05] .................................................................. 15
Abbildung 5: Domainunabhängige Architektur, vgl. [Fis94].................................................. 18
Abbildung 6: SER Prozessmodell, [Fis94] .............................................................................. 19
Abbildung 7: Use Case Diagramm: Projektverwaltung........................................................... 22
Abbildung 8: Use Case Diagramm: Konstruktion................................................................... 22
Abbildung 9: Use Case Diagramm: Argumentation................................................................ 23
Abbildung 10: Use Case Diagramm: Spezifikation................................................................. 23
Abbildung 11: Klassifizierung von Erfahrung......................................................................... 27
Abbildung 12: Use Case Bearbeitung...................................................................................... 28
Abbildung 13: Office-Assistent, (a) Tabelle erstellen, (b) Brief schreiben, (c) Umschlag
erstellen ............................................................................................................................ 29
Abbildung 14: Entwicklungsumgebung von Eclipse, [Ecl06]................................................. 31
Abbildung 15: Fehlerfenster..................................................................................................... 32
Abbildung 16: Architektur des Tools....................................................................................... 34
Abbildung 17: Klassendiagramm des Projekt und Use Case Modells..................................... 35
Abbildung 18: Klassendiagramm des Template Modells ........................................................ 37
Abbildung 19: Klassendiagramm des Erfahrungmodells......................................................... 38
Abbildung 20: Klassendiagramm CriticChecker ..................................................................... 39
Abbildung 21: Sequenzdiagramm zur Anzeige von Hilfe ....................................................... 40
Abbildung 22: Sequenzdiagramm zur Anzeige von Kritik ...................................................... 41
Abbildung 23: GUI Entwurf.................................................................................................... 42
Abbildung 24: Die Grafische Benutzeroberfläche................................................................... 59
65

66
Literaturverzeichnis
ABC03 Steve Adolph, Paul Bramble, Alistair Cockburn, Andy Pols, Patterns for Effective
Use Cases, Addison Wesley, 2003
Bal01 Helmut Balzert, Lehrbuch der Software-Technik, 2001
BCR94 V. R. Basili, G. Caldiera, H. D. Rombach, The Experience Factory, 1994
BS88 J. Bauer, T. Schwab, Anforderungen an Hilfesysteme in Einführung in die
Software-Ergonomie, Berlin, 1988
Buc05 Tobias Buchloh, Erstellung eines Baukastens für Experience Bases, Masterarbeit,
Hannover, Oktober 2005
Coc01 Alistair Cockburn, Writing Effective Use Cases, Addison Wesley, 2001
Coc06 Homepage von Alistair Cockburn, http://alistair.cockburn.us, online 04.05.2006
Ecl06 Eclipse, http://www.eclipse.org, online 17.09.2006
Fis94 Gerhard Fischer, Domain-Oriented Design Environments, Automated Software
Engineering Vol. 1, 1994
FLS85 G. Fischer, A. Lemke, T. Schwab, Knowledge-based Help Systems, CHI 85
Proceedings, April 1985
FMM89 G. Fischer, R. McCall, A. Morch, JANUS: Integrating hypertext with a knowledgebased
design environment, Proceedings of Hypertext'89, November 1989
Gnu06 GnuPG, freie Verschlüsselung, http://www.gnupg.org, online 17.09.2006
Java06 Java Dokumentation, insbesondere Java und Tutorials für Java 1.5.0,
http://java.sun.com/j2ee/1.5.0/docs/, online 11.10.2006
Jdom06 Bibliothek zur einfachen Generierung wohlgeformter XML-Dateien,
http://www.jdom.org/, online 01.06.2006
Jgo06 Bibliothek für das Look & Feel, http://www.jgoodies.com/, online 01.06.2006
Lev66 Vladimir I. Levenshtein: Binary codes capable of correcting deletions, insertions,
and reversals, Soviet Physics Doklady, 1966
LF90 A. Lemke, G. Fischer, A cooperative problem solving system for user interface
design, Eighth National Conference on Artificial Intelligence, August 1990
Lir04 Thomas Liro, Konzept und Realisierung eines Werkzeuges zur Erhebung,
Verwaltung und Bewertung von Erfahrungen, Bachelorarbeit, Hannover, August
2004
Met06 Metrics, Plugin für Eclipse, http://metrics.sourceforge.net/, online 11.07.2006
Msw02 Microsoft Word 2002
Nin94 Jim Q. Ning, Developing Domain-Oriented Design Environments – The Question
is How, not Why, Automated Software Engineering Vol. 1, 1994
NT95 Nonaka, Takeuchi, The Knowledge Creating Company, Oxford University Press,
1995
OMG06 Object Management Group, http://www.omg.org, online 01.06.2006
Sch00 K. Schneider, LIDs: A Light-Weight Approach to Experience Elicitation and
Reuse, Profes-Conference, Oulu, Finnland, Juni 2000
SH02 K. Schneider, J. P. v. Hunnius, Experience in Implementing a Learning Software
Organization, IEEE Software, 2002
Sut94 Alistair Sutcliffe, Commentary on ‘Domain Oriented Design Environments’ by
Gerhard Fischer, Automated Software Engineering Vol. 1, 1994
TK98 Hugo Tschirky, Stefan Koruna, Technologie-Management. Idee und Praxis,
Oktober 1998
Wik06 Wikipedia – Die freie Enzyklopädie, http://de.wikipedia.org/, online 04.05.2006

Anhang
A Use Cases
Titel Benutzer plant ein Projekt
Scope Client
Ebene Zusammenfassung
Vorbedingung Das System ist komplett installiert und einsatzbereit.
Mindestgarantie Keine
Erfolgsgarantie Ein geplantes Projekt mit guten Uses Cases.
Hauptakteur Benutzer
Stakeholder & ihre Benutzer: Gute Planung des Projekts
Interessen
System: Datenkonsistenz
Auslöser / auslösendes Die Systemingenieure haben beschlossen, ein Projekt zu planen.
Event
Erfolgsszenario
Erweiterungen
Schritt Akteur Aktion
1 Benutzer UC 2: Benutzer legt ein Projekt an.
2 Benutzer UC 5: Benutzer erstellt einen neuen
Use Case.
3 Benutzer UC 8: Benutzer bearbeitet ein Use
Cases.
4 Benutzer UC 7: Benutzer exportiert ein bzw.
mehrere Use Cases.
5 Benutzer UC 4: Benutzer speichert das Projekt.
2a Benutzer wiederholt den Schritt beliebig oft bis er
fertig ist.
3a Benutzer wiederholt den Schritt beliebig oft bis er
fertig ist.
Priorität Wichtig
Performance /
Durchlaufsdauer
Mehrere Wochen bis mehrere Monate
Verwendungshäufigkeit zu jedem Projekt ein Mal
Use Case 1: Benutzer plant ein Projekt
67

68
Titel Benutzer legt ein Projekt an
Scope Projektverwaltung
Ebene Benutzerebene
Vorbedingung Keine
Mindestgarantie Keine
Erfolgsgarantie Die Projektverwaltung hat ein neues Projekt angelegt.
Hauptakteur Benutzer
Stakeholder & ihre
Interessen
Benutzer: Projekt anlegen
Auslöser / auslösendes Benutzer möchte ein Projekt anlegen.
Event
Erfolgsszenario
Anhang
Schritt Akteur Aktion
1 Benutzer möchte ein neues Projekt anlegen.
2 Benutzer gibt Metadaten wie Namen ein.
3 Projektverwaltung legt das Projekt an.
Erweiterungen Keine
Priorität Wichtig
Performance /
unter eine Minute
Durchlaufsdauer
Verwendungshäufigkeit einmalig zu jeden Projekt
Use Case 2: Benutzer legt ein Projekt an

A Use Cases
Titel Benutzer öffnet ein gespeichertes Projekt
Scope Projektverwaltung
Ebene Benutzerebene
Vorbedingung Der Benutzer hat zuvor das Projekt vollständig und korrekt
abgespeichert.
Mindestgarantie Keine
Erfolgsgarantie Die Projektverwaltung hat das Projekt vollständig geladen.
Hauptakteur Benutzer
Stakeholder & ihre
Interessen
Auslöser / auslösendes
Event
Erfolgsszenario
Erweiterungen
Benutzer: Ein zu einen früheren Zeitpunkt abgespeichertes Projekt
wieder vollständig laden
Projektverwaltung: Datenkonsistenz
Benutzer möchte ein Projekt laden.
Schritt Akteur Aktion
1 Benutzer wählt die Projekt-Datei aus.
2 Projektverwaltung lädt das Projekt.
3 Projektverwaltung spielt die Use Cases ein und
verlinkt sie wieder richtig.
Schritt Akteur Aktion
1a Datei ist nicht vorhanden:
1a1 Projektverwaltung gibt Fehlermeldung an den
Benutzer und bricht ab.
2a Es handelt sich um keine Projektdatei bzw. die Datei ist
fehlerhaft:
2a1 Projektverwaltung gibt Fehlermeldung an den
Benutzer und bricht ab.
2b Der Benutzer hat keine Leserechte:
2b1 Projektverwaltung gibt Fehlermeldung an den
Benutzer und bricht ab.
3a Die Verlinkung der Use Cases ist fehlerhaft:
3a1 Projektverwaltung gibt Fehlermeldung an den
Benutzer und versucht soviel
anzuzeigen, dass die Daten noch
konsistent sind.
Priorität Wichtig
Performance /
unter eine Minute
Durchlaufsdauer
Verwendungshäufigkeit mehrmals zu bei der Bearbeitung des Projekts
Use Case 3: Benutzer öffnet ein gespeichertes Projekt
69

70
Titel Benutzer speichert das Projekt
Scope Projektverwaltung
Ebene Benutzerebene
Vorbedingung Der Benutzer hat ein Projekt geöffnet bzw. erstellt.
Mindestgarantie Keine
Erfolgsgarantie Die Projektverwaltung hat das Projekt gespeichert.
Hauptakteur Benutzer
Stakeholder & ihre
Interessen
Auslöser / auslösendes
Event
Erfolgsszenario
Erweiterungen
Benutzer: Projekt abspeichern, so dass es zu einen späteren
Zeitpunkt vollständig wieder geladen werden kann
Projektverwaltung: Alle Daten so ablegen, dass sie wieder
geladen werden können
Benutzer möchte das aktuelle Projekt speichern
Schritt Akteur Aktion
1 Benutzer wählt den Speicherort und einen
Dateinamen aus.
Anhang
2 Projektverwaltung speichert das Projekt.
Schritt Akteur Aktion
1a Datei ist bereits vorhanden:
1a1 Projektverwaltung warnt den Benutzer und ermöglicht
ihm den Namen zu ändern bzw. die
Datei zu überschreiben.
1a1a1 Benutzer möchte die Datei überschreiben.
1a1b1 Benutzer gibt einen anderen Namen ein.
1b Ein Speicherort und ein Dateiname ist bereits bekannt,
weil der Benutzer diese schon mal ausgewählt hat oder
das Projekt aus einer bestehenden Datei geladen hat:
1b1 Schritt entfällt, weiter mit 2.
2a Es existiert nicht genug Speicherplatz:
2a1 Projektverwaltung gibt Fehlermeldung an den
Benutzer und bricht ab.
2b Der Benutzer hat keine Schreibrechte:
2b1 Projektverwaltung gibt Fehlermeldung an den
Benutzer und bricht ab.
Priorität Wichtig
Performance /
unter eine Minute
Durchlaufsdauer
Verwendungshäufigkeit mehrmals zu bei der Bearbeitung des Projekts
Use Case 4: Benutzer speichert das Projekt

A Use Cases
Titel Benutzer erstellt einen neuen Use Case
Scope Projektverwaltung
Ebene Benutzerebene
Vorbedingung Ein Projekt ist geöffnet.
Mindestgarantie Keine
Erfolgsgarantie Der neue Use Case ist angelegt.
Hauptakteur Benutzer
Stakeholder & ihre Benutzer: Use Case anlegen
Interessen
Projektverwaltung: Eindeutigkeit durch Namen
Auslöser / auslösendes Benutzer möchte ein Use Case erstellen.
Event
Erfolgsszenario
Schritt Akteur Aktion
1 Benutzer möchte einen neuen Use Case
erstellen.
2 Projektverwaltung legt den Use Case an.
3 Benutzer gibt einen Titel ein.
Erweiterungen Schritt Akteur Aktion
3a Der Titel ist bereits vergeben:
3a1 Kritiksystem weist den Benutzer daraufhin und
fragt nach einen anderen Titel.
3a2 Benutzer gibt einen anderen Titel ein.
Priorität Wichtig
Performance /
Durchlaufsdauer
unter eine Minute
Verwendungshäufigkeit Mehrmals während eines Projekts, vielleicht 1-3 mal die Stunde
Use Case 5: Benutzer erstellt einen neuen Use Case
71

72
Titel Benutzer löscht einen Use Case
Scope Projektverwaltung
Ebene Benutzerebene
Vorbedingung Das Projekt ist geöffnet und der Use Case existiert.
Mindestgarantie Keine
Erfolgsgarantie Der Use Case ist gelöscht.
Hauptakteur Benutzer
Stakeholder & ihre
Interessen
Auslöser / auslösendes
Event
Erfolgsszenario
Anhang
Benutzer: Use Case ist gelöscht
Projektverwaltung: Datenkonsistenz, keine Verlinkung auf das
gelöschte Use Case
Benutzer möchte ein Use Case löschen.
Schritt Akteur Aktion
1 Benutzer wählt den Use Case aus.
2 Benutzer löscht den Use Case.
3 Projektverwaltung löscht den ausgewählten Use Case.
4 Projektverwaltung stellt sicher, dass der Use Case
nicht in einen anderen Use Case
verlinkt ist.
Erweiterungen Schritt Akteur Aktion
4a Der Assistent stellt fest, dass ein anderer Use Case auf
den gelöschten verlinkt:
4a1 Projektverwaltung weist den Benutzer daraufhin.
4a2 Benutzer korrigiert den Fehler.
Priorität Wichtig
Performance /
Durchlaufsdauer
Unter eine Minute
Verwendungshäufigkeit Selten
Use Case 6: Benutzer löscht einen Use Case

A Use Cases
Titel Benutzer exportiert ein Use Case
Scope Projektverwaltung
Ebene Benutzerebene
Vorbedingung Ein Projekt ist geöffnet und er Use Case existiert.
Mindestgarantie Keine
Erfolgsgarantie Der Benutzer hat den gewünschten Use Case exportiert.
Hauptakteur Benutzer
Stakeholder & ihre Benutzer: Use Case gut formatiert exportieren
Interessen
Projektverwaltung: Erfolgreiches exportieren
Auslöser / auslösendes Benutzer möchte ein Use Case exportieren.
Event
Erfolgsszenario
Erweiterungen
Schritt Akteur Aktion
1 Benutzer wählt den Use Case aus, den er
exportieren möchte.
2 Benutzer wählt Speicherort, Dateiname und
Format aus.
3 Projektverwaltung fasst die Daten des Use Cases
zusammen und stellt sie gut
formatiert zusammen.
4 Projektverwaltung exportiert die Informationen in eine
Datei.
Schritt Akteur Aktion
1a
Der Use Case existiert nicht bzw. es existieren keine:
Der Use Case kann nicht exportiert werden, der
Benutzer bzw. das System bricht das Szenario.
1b Der Benutzer exportiert gleich mehrere Use Cases.
2a Es existiert bereits eine Datei mit gleichen Namen:
2a1 Projektverwaltung warnt den Benutzer und ermöglicht
ihm den Namen zu ändern bzw.
eine anderen Namen einzugeben.
2a1a1 Benutzer möchte die Datei überschreiben.
2a1b1 Benutzer gibt einen anderen Namen ein.
2b Der Benutzer bricht ab:
2b1 Projektverwaltung beendet das Szenario und exportiert
nichts.
4a Es existiert nicht genug Speicherplatz:
4a1 Projektverwaltung gibt Fehlermeldung an den
Benutzer und bricht ab.
4b Der Benutzer hat keine Schreibrechte:
4b1 Projektverwaltung gibt Fehlermeldung an den
Benutzer und bricht ab.
Priorität wünschenswert
Performance /
unter eine Minute
Durchlaufsdauer
Verwendungshäufigkeit einige wenige mal während des Projekts
Use Case 7: Benutzer exportiert ein Use Case
73

74
Anhang
Titel Benutzer bearbeitet ein Use Case
Scope Konstruktion
Ebene Benutzerebene
Vorbedingung Ein Projekt ist geöffnet und der gewünschte Use Case existiert.
Mindestgarantie Keine
Erfolgsgarantie Die Änderungen am Use Case sind übernommen.
Hauptakteur Benutzer
Stakeholder & ihre Benutzer: Use Case füllen bzw. korrigieren
Interessen
Konstruktion: Datenkonsistenz
Auslöser / auslösendes Benutzer möchte ein Use Case ausfüllen bzw. korrigieren.
Event
Erfolgsszenario
Schritt Akteur Aktion
1 Benutzer wählt den gewünschten Use Case aus.
2 Konstruktion zeigt den Use Case an.
3 Benutzer füllt das Formular aus bzw. korrigiert
die Eingaben.
4 Konstruktion übernimmt die Eingaben.
5 Konstruktions- validiert die Eingaben des Benutzers.
analyzer
Erweiterungen Schritt Akteur Aktion
3a UC 9: Der Benutzer fügt einen (weiteren) Schritt ein.
3b Der Benutzer möchte eine Datei anhängen.
3b1 Benutzer wählt die Datei aus.
3b2 Konstruktion hängt sie an.
3c, 5a Es existiert eine Erfahrung:
UC 11: Der Assistent zeigt eine Erfahrung an.
Priorität Wichtig
Performance /
Je nach Schnelligkeit des Benutzers zwischen einigen Minuten
Durchlaufsdauer und einer Stunde
Verwendungshäufigkeit Sehr häufig, mehrmals am Tag
Use Case 8: Benutzer bearbeitet ein Use Case

A Use Cases
Titel Benutzer fügt einen (weiteren) Schritt ein
Scope Konstruktion
Ebene Benutzerebene
Vorbedingung Ein Projekt ist geöffnet und der Use Case existiert.
Mindestgarantie Benutzer bearbeitet ein Use Case.
Erfolgsgarantie Ein (weiterer) Schritt ist eingefügt.
Hauptakteur Benutzer
Stakeholder & ihre Benutzer: einen (weiteren) Schritt anlegen
Interessen
Konstruktion: Datenkonsistenz
Auslöser / auslösendes Benutzer möchte einen (weiteren) Schritt einfügen.
Event
Erfolgsszenario
Schritt Akteur Aktion
1 Benutzer möchte einen Schritt einfügen.
2 Benutzer gibt die nötigen Daten ein.
3 Konstruktion legt den Schritt an.
4 Konstruktions- validiert die Eingabe.
analyzer
Erweiterungen Schritt Akteur Aktion
2a Der Benutzer möchte einen Use Case verlinken:
2a1 Konstruktion stellt die verfügbaren Use Cases zur
Auswahl.
2a2 Benutzer wählt den Use Case aus, den er an
diese Stelle verlinken möchte.
2b,4a Es existiert eine Erfahrung:
UC 11: Der Assistent zeigt eine Erfahrung an.
Priorität Wichtig
Performance /
Durchlaufsdauer
wenige Minuten
Verwendungshäufigkeit Laufend
Use Case 9: Benutzer fügt einen (weiteren) Schritt ein
75

76
Titel Benutzer guckt sich die letzten Änderungen an
Scope Konstruktion
Ebene Benutzerebene
Vorbedingung Ein Projekt ist geöffnet.
Mindestgarantie Keine
Erfolgsgarantie Konstruktion hebt die Änderungen hervor.
Hauptakteur Benutzer
Stakeholder & ihre
Interessen
Benutzer: alle Änderungen einsehen
Auslöser / auslösendes Benutzer möchte sich die Änderungen anzeigen.
Event
Erfolgsszenario
Anhang
Schritt Akteur Aktion
1 Benutzer möchte die letzte Änderungen sehen.
2 Konstruktion vergleicht das vorgemerkte Datum mit
den Daten der Änderungen.
3 Konstruktion hebt die Attribute die sich geändert
haben hervor.
4 Benutzer sieht die Änderungen.
5 Benutzer möchte die Ansicht ausschalten.
6 Konstruktion zeigt keine Änderung mehr an.
Erweiterungen Schritt Akteur Aktion
1a Benutzer möchte die Änderungen seit einen
eingegebenen Datum sehen:
1a1 Benutzer gibt ein beliebiges Datum an.
3a Es existieren keine Änderungen seit dem Datum:
3a1 Konstruktion hebt nichts hervor.
4a Benutzer wiederholt die Schritte 1a bis 4 beliebig oft.
4b Benutzer arbeitet während der Anzeige weiter
Priorität Wichtig
Performance /
Durchlaufsdauer
Unter eine Minute
Verwendungshäufigkeit Gelegentlich
Use Case 10: Benutzer guckt sich die letzten Änderungen an

A Use Cases
Titel Der Assistent zeigt eine Erfahrung an
Scope Argumentation
Ebene Benutzerebene
Vorbedingung Der Benutzer bearbeitet ein geöffnetes Projekt.
Mindestgarantie Keine
Erfolgsgarantie Der Assistent zeigt die relevanteste Erfahrung an.
Hauptakteur Assistent
Stakeholder & ihre
Interessen
Auslöser / auslösendes
Event
Erfolgsszenario
Erweiterungen
Benutzer: relevante und richtige Hinweise und Erfahrungen lesen,
gute Use Cases erstellen, nicht gestört werden
Assistent: seine Empfehlungen und Kritiken sollen Beachtung
finden
Der Benutzer bearbeitet ein Attribut in einem Use Case.
Schritt Akteur Aktion
1 Benutzer bearbeitet ein Attribut.
2 Assistent wählt alle relevanten Erfahrungen
aus.
3 Assistent sortiert seine Auswahl nach der
Relevanz.
4 Assistent zeigt die relevanteste Erfahrung an.
5 Benutzer liest die Erfahrung.
6 Benutzer macht seine Eingabe.
Schritt Akteur Aktion
2a Es gibt keine Erfahrung zu diesem Attribut:
2a1 Assistent zeigt nichts an.
4a Es gibt mehr als eine relevanteste Information mit
gleicher Bewertung:
4a1 Assistent wählt eine zufällig aus.
5a Der Benutzer möchte weitere Informationen:
5a1 Assistent zeigt dem Benutzer eine
ausführlichere Erläuterung.
5b Der Benutzer möchte die angezeigte Erfahrung für
diesen Fall ignorieren bzw. für alle Fälle ignorieren:
5b1 Assistent merkt sich, dass der Benutzer diese
Erfahrung in diesen bzw. in allen
Fällen nicht mehr sehen will.
5b2 Assistent fängt mit Schritt 2 wieder an und
zeigt die nächste relevanteste
Erfahrung an.
5c Der Benutzer möchte weitere Erfahrungen zu diesem
Kontext lesen:
5c1 Assistent zeigt die nächste relevanteste
Erfahrung an.
5d
Benutzer möchte die aktuelle Erfahrung ergänzen:
5e
UC 12: Benutzer erweitert eine Erfahrung.
Der Benutzer möchte den Assistenten deaktivieren, da
die Warnungen und Erfahrungen stören:
5e1 Benutzer blendet den Assistenten aus.
5e2 Assistent blendet sich aus.
77

78
Anhang
Priorität Wichtig
Performance /
Das Anzeigen der Erfahrungen dauert unter eine Sekunde.
Durchlaufsdauer Erweiterung dauert etwa 1 Minute.
Verwendungshäufigkeit Laufend
Anhang Beispiele für Erfahrungen:
• Es existieren mehr als 9 Schritte in einem Szenario.
Der Benutzer solle Schritte zusammenfassen oder einen
Unter Use Case erstellen.
• Ein Schritt ist in Passiv formuliert.
Der Satz sollte umformuliert werden.
• Ein Schritt ist zu lang.
Der Satz sollte gekürzt werden oder auf mehrere
Schritte verteilt werden.
• weitere siehe Kapitel 5
Use Case 11: Der Assistent zeigt eine Erfahrung an

A Use Cases
Titel Benutzer erweitert eine Erfahrung
Scope Argumentation
Ebene Benutzerebene
Vorbedingung Der Benutzer ist mit der angezeigten Erfahrung nicht ganz
einverstanden und möchte sie ergänzen.
Mindestgarantie Die alte Erfahrung bleibt erhalten.
Erfolgsgarantie Die Erfahrung ist um die Erfahrung des Benutzers erweitert.
Hauptakteur Benutzer
Stakeholder & ihre
Interessen
Auslöser / auslösendes
Event
Erfolgsszenario
Benutzer: Richtigstellung und seine Erfahrung anderen Benutzern
zugänglich machen
Argumentation: Datenkonsistenz, kurze Teaser, ausführliche
Erläuterung
Benutzer hat eine Erfahrung angezeigt bekommen und möchte
diese erweitern.
Schritt Akteur Aktion
1 Benutzer gibt einen Teaser und eine ausführlichere
Erläuterung ein.
2 Assistent ergänzt die aktuelle Erfahrung um die
neue Erfahrung.
3 Assistent speichert die Änderung automatisch ab.
Erweiterungen Schritt Akteur Aktion
1a Der Benutzer bricht ab:
1a1 Assistent bricht das Szenario ab und erweitert die
Erfahrung nicht.
1b Der Teaser ist zu lang für eine kurze Beschreibung:
1b1 Assistent weist den Benutzer daraufhin.
1b2 Benutzer kürzt den Teaser.
1c Die Erläuterung ist zu kurz um ausführlich genug zu
sein:
1c1 Assistent weist den Benutzer daraufhin.
1c2 Benutzer gibt eine ausführlichere Erläuterung ein.
Priorität Wünschenswert
Performance /
Durchlaufsdauer
einige Minuten
Verwendungshäufigkeit Zu Beginn vermutlich öfters, danach nur noch gelegentlich
Use Case 12: Benutzer erweitert eine Erfahrung
79

80
Anhang
Titel Benutzer legt eine neue Erfahrung an
Scope Argumentation
Ebene Benutzerebene
Vorbedingung Der Benutzer hat eine Erfahrung, die noch nicht vorhanden ist,
und möchte sie anderen Benutzern zur Verfügung stellen.
Mindestgarantie Bestehende Erfahrungen bleiben erhalten.
Erfolgsgarantie Der Benutzer hat den Erfahrungsschatz um seine neue Erfahrung
erweitert.
Hauptakteur Benutzer
Stakeholder & ihre Benutzer: seine Erfahrung anderen Benutzern zugänglich machen
Interessen
Argumentation: Datenkonsistenz
Auslöser / auslösendes Benutzer möchte seine Erfahrung hinzufügen.
Event
Erfolgsszenario
Erweiterungen
Schritt Akteur Aktion
1 Benutzer gibt einen Teaser und eine ausführlichere
Erläuterung ein.
2 Benutzer gibt an, wann der Assistent die
Erfahrung anzeigen soll.
3 Benutzer legt die Wichtigkeit der Erfahrung fest.
4 Assistent fügt die neue Erfahrung ein.
Schritt Akteur Aktion
1a, 2a,
Benutzer bricht ab:
3a Assistent bricht das Szenario ab und legt die
Erfahrung nicht an.
1b Der Teaser ist zu lang für eine kurze Beschreibung:
1b1 Assistent weist den Benutzer daraufhin.
1b2 Benutzer kürzt den Teaser.
1c Die Erläuterung ist zu kurz für eine ausführliche
Beschreibung:
1c1 Assistent weist den Benutzer daraufhin.
1c2 Benutzer gibt eine ausführlichere Erläuterung ein.
3a Der Benutzer hat eine ungültige Eingabe gemacht:
3a1 Assistent weist den Benutzer daraufhin.
3a2 Benutzer korrigiert die Eingabe.
Priorität Wünschenswert
Performance /
Durchlaufsdauer
einige Minuten
Verwendungshäufigkeit Zu Beginn vermutlich öfters, danach nur noch gelegentlich
Use Case 13: Benutzer legt eine neue Erfahrung an

A Use Cases
Titel Benutzer bearbeitet das Use Case Template
Scope Spezifikation
Ebene Benutzerebene
Vorbedingung Keine
Mindestgarantie Keine
Erfolgsgarantie Die Änderungen am Template sind übernommen und auf die Use
Case angewandt.
Hauptakteur Benutzer
Stakeholder & ihre
Interessen
Auslöser / auslösendes
Event
Erfolgsszenario
Benutzer: Individuelles und an dem Bedarf orientiertes Template
System: Datenkonsistenz, notwendige Attribute beibehalten,
einheitliche Use Cases
Benutzer möchte das Template bearbeiten.
Schritt Akteur Aktion
1 Benutzer fügt / löscht / deaktiviert ein Attribut.
2 Benutzer speichert das Template.
3 Spezifikation übernimmt die Änderungen.
4 Spezifikation wendet das Template auf alle im
Projekt vorhandenen Use Cases an.
Erweiterungen Schritt Akteur Aktion
1a Der Name eines neuen Attributs ist bereits vergeben:
1a1 Spezifikation gibt eine Fehlermeldung an den
Benutzer und fügt das Attribut nicht
hinzu.
1b Das zu löschende Attribut ist kein zusätzliches Attribut:
1b1 Spezifikation gibt eine Fehlermeldung an den
Benutzer und löscht das Attribut nicht.
1c Der Assistent stellt fest, dass das Attribut erforderlich ist
(z. B. Hauptszenario und Titel):
1c1 Spezifikation gibt eine Fehlermeldung an den
Benutzer und deaktiviert das Attribut
nicht.
1d Der Benutzer wiederholt Schritt 1 beliebig oft.
1e Der Benutzer bricht ab:
1e1 Spezifikation bricht das Szenario ab, ohne die
Änderungen zu übernehmen.
4a Es gibt ein oder mehrere Attribute, die Daten enthalten:
4a1 Spezifikation verwirft die Daten.
Priorität Wünschenswert
Performance /
Einigen Minuten
Durchlaufsdauer
Verwendungshäufigkeit In der Regel einmal zu Beginn des Projekts, vermutlich nicht
mehr während des Projekts, oder nur sehr selten
Use Case 14: Benutzer bearbeitet das Use Case Template
81

82
B XML Schemata
ProjectScheme.xsd
Anhang

B XML Schemata
83

84
Anhang
ExperienceBaseScheme.xsd

B XML Schemata
85

86
Anhang

C Programm und Quellcode
C Programm und Quellcode
Auf der beigelegten CD befinden sich eine lauffähige Version des Tools und die
dazugehörigen Quellcode Dateien. Es wurden die Bibliotheken [Jdom06] zum Verarbeiten
von XML-Dateien und [Jgo06] als Look&Feel verwendet, die sich ebenfalls auf der CD
befinden. Weiterhin befinden sich die Use Cases aus Anhang A als Projektdatei, die
Erfahrungssammlung, sowie die dazugehörigen Schemadefinitionen auf der CD.
87

88
D Umfrageergebnis
Anhang
1. Wie würden Sie Ihren Wissensstand über Standardanwendungen wie Microsoft Word,
OpenOffice und / oder anderen Textverarbeitungsprogramme einschätzen?
Fortgeschritten: 7
Gute Basiskenntnisse: 2
Keine Kenntnisse: 0
2. Wie würden Sie Ihren Wissensstand in Eclipse, JBoss oder ähnlichen
Entwicklungsumgebungen einschätzen?
Fortgeschritten: 6
Gute Basiskenntnisse: 3
Keine Kenntnisse: 0
3. Haben Sie schon mal Use Cases verwendet?
Ja, verwende ich regelmäßig: 2
Ja, habe ich mal verwendet: 6
Nein: 1
Ich weiß nicht, was das ist: 0
4. Hatten Sie bei der Nutzung des Tools Schwierigkeiten?
Ich hatte keine Probleme: 7
Ich hatte nur leichte Probleme: 2
Ich habe das Tool nicht verstanden: 0
Es hat nicht funktioniert: 0
5. Sind die Funktionalitäten des Tools intuitiv zu finden?
Ja, immer: 7
Ja, bis auf einige Ausnahmen: 2
Nein: 0
6. Ist die Darstellung der Kritiken und Hilfen angebracht?
Ja: 9
Verbesserungsfähig: 0
Nein: 0
7. Haben Sie den Eindruck, durch die Verwendung des Tools Zeit zu sparen?
Ja, erheblich: 0
Ja, etwas: 3
Bleibt gleich: 5
Nein, brauche mehr Zeit: 1
Nein, brauche wesentlich mehr Zeit: 0

D Umfrageergebnis
8. Haben Sie den Eindruck, durch die Verwendung des Tools Arbeit zu sparen?
Ja, erheblich: 0
Ja, etwas: 2
Bleibt gleich: 6
Nein, brauche mehr Arbeit: 1
Nein, brauche wesentlich mehr Arbeit: 0
9. Haben Sie den Eindruck, durch die Verwendung des Tools bessere Use Cases zu
erstellen?
Ja, erheblich: 3
Ja, etwas: 5
Bleibt gleich: 1
Nein, die Use Cases sind schlechter: 0
Nein, die Use Cases sind wesentlich schlechter: 0
10. Würden Sie das Tool zur Planung von Projekten einsetzen?
Ja, auf jeden Fall: 1
Ja, ich würde das mal gerne probieren: 4
Eventuell: 2
Eher nicht: 2
Auf keinen Fall: 0
11. Welches Betriebssystem verwendeten Sie bei der Erprobung des Tools?
Windows: 5
Unix / Linux: 2
Macintosh: 0
Andere: 4
89

90
Erklärung
Anhang
Hiermit versichere ich, dass ich die vorliegende Masterarbeit und die dazugehörige
Implementierung selbständig und ohne fremde Hilfe verfasst und keine anderen als die in der
Arbeit angegebenen Quellen und Hilfsmittel verwendet habe.
Hannover, 23. Oktober 2006
______________________________________
Christian Crisp