Konzept und Werkzeug zur erfahrungsbasierten Erstellung ... · PDF file8 2. Grundlagen 2.1 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

3

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.

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.

5

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

Inhaltsverzeichnis 6

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

7

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.

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

9

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 „<<inlude>>“, 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 „<<extend>>“ 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.

2. Grundlagen 10

2.1.2 Use Case Template

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 Te ilsystem 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

11

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.

2. Grundlagen 12

3a1 System weist den Kunden daraufhin, dass er sich einloggen muss.

3a Kunde ist nicht eingeloggt

3a2 Kunde loggt sich ein. 3b1 System listet alle Artikel im Warenkorb auf. 3b2 Kunde entfernt nicht gewünschte Artikel.

3b Kunde möchte einen Artikel aus 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

13

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.

2. Grundlagen 14

2.3 Wissen

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

15

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.

Abbildung 4: Erfahrungsweitergabe, vgl. [Buc05]

2.6 Wissensbasierte Systeme

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.

2. Grundlagen 16

2.7 Benutzer-Unterstützungssysteme

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)

17

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:

2. Grundlagen 18

• 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 anb ietet • 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

19

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]

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

21

so dass sie in seiner Umgebung nicht mehr angezeigt werden. Der Benutzer muss auch die Möglichkeit haben, seine Erfahrungen in das System einzugeben.


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.

3. Anforderungen 22

Abbildung 7: Use Case Diagramm: Projektverwaltung

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.


23

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

3. Anforderungen 24

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ücksicht igt 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

25

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.

3. Anforderungen 26

3.5.3 Übertragbarkeit

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 ebenfa lls 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.

27

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.

Abbildung 11: Klassifizierung von Erfahrung

4.2 Bearbeitung eines Use Cases

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

Erfahrung

Hilfe Kritik

Warnung Fehler

4. Konzept 28

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

29


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 Assis tent 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

4. Konzept 30

„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.


31

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.

4. Konzept 32

Abbildung 15: Fehlerfenster

4.3.4 Tipp des Tages

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

33

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.

4. Konzept 34

Abbildung 16: Architektur des Tools

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

35

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

4. Konzept 36

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

37

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).

4. Konzept 38

4.5.3 Erfahrungsmodell

Abbildung 19: Klassendiagramm des Erfahrungmodells

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

39

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,

4. Konzept 40

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

41

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

4. Konzept 42

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

43

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.

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

45

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.

5. Erfahrungssammlung 46

4. Allgemeiner Hinweis zu Use Cases

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 „authent ifiziert“ 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

47

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.


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.


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.


49

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


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.


51

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


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.


53

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.

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.


55

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

6. Tool 56

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 Struktur ierung 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.


57

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.

6. Tool 58

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


59

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 ve rschiedene 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.

Abbildung 24: Die Grafische Benutzeroberfläche

Der Projektbaum

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.

6. Tool 60

Das Formular

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.


61

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.

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.

63

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

8. Fazit 64

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.

65

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

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 knowledge-

based 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

67

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 Interessen

Benutzer: Gute Planung des Projekts System: Datenkonsistenz

Auslöser / auslösendes Event

Die Systemingenieure haben beschlossen, ein Projekt zu planen.

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.

Erfolgsszenario

5 Benutzer à UC 4: Benutzer speichert das Projekt. 2a Benutzer wiederholt den Schritt beliebig oft bis er

fertig ist. Erweiterungen

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

Anhang 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


Benutzer möchte ein Projekt anlegen.

Schritt Akteur Aktion 1 Benutzer möchte ein neues Projekt anlegen. 2 Benutzer gibt Metadaten wie Namen ein.

Erfolgsszenario

3 Projektverwaltung legt das Projekt an. Erweiterungen Keine Priorität Wichtig Performance / Durchlaufsdauer

unter eine Minute

Verwendungshäufigkeit einmalig zu jeden Projekt

Use Case 2: Benutzer legt ein Projekt an

A Use Cases

69

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

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.

Erfolgsszenario

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:

Erweiterungen

3a1 Projektverwaltung gibt Fehlermeldung an den Benutzer und versucht soviel anzuzeigen, dass die Daten noch konsistent sind.


unter eine Minute

Verwendungshäufigkeit mehrmals zu bei der Bearbeitung des Projekts Use Case 3: Benutzer öffnet ein gespeichertes Projekt

Anhang 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

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.

Erfolgsszenario

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:

Erweiterungen

2b1 Projektverwaltung gibt Fehlermeldung an den Benutzer und bricht ab.


unter eine Minute

Verwendungshäufigkeit mehrmals zu bei der Bearbeitung des Projekts

Use Case 4: Benutzer speichert das Projekt

A Use Cases

71

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 Interessen

Benutzer: Use Case anlegen Projektverwaltung: Eindeutigkeit durch Namen


Benutzer möchte ein Use Case erstellen.

Schritt Akteur Aktion 1 Benutzer möchte einen neuen Use Case

erstellen. 2 Projektverwaltung legt den Use Case an.

Erfolgsszenario

3 Benutzer gibt einen Titel ein. Schritt Akteur Aktion 3a Der Titel ist bereits vergeben: 3a1 Kritiksystem weist den Benutzer daraufhin und

fragt nach einen anderen Titel.

Erweiterungen

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

Anhang 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

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.

Erfolgsszenario

4 Projektverwaltung stellt sicher, dass der Use Case nicht in einen anderen Use Case verlinkt ist.

Schritt Akteur Aktion 4a Der Assistent stellt fest, dass ein anderer Use Case auf

den gelöschten verlinkt: 4a1 Projektverwaltung weist den Benutzer daraufhin.

Erweiterungen

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

73

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 Interessen

Benutzer: Use Case gut formatiert exportieren Projektverwaltung: Erfolgreiches exportieren


Benutzer möchte ein Use Case exportieren.

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.

Erfolgsszenario

4 Projektverwaltung exportiert die Informationen in eine Datei.

Schritt Akteur Aktion Der Use Case existiert nicht bzw. es existieren keine: 1a 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:

Erweiterungen

4b1 Projektverwaltung gibt Fehlermeldung an den Benutzer und bricht ab.

Priorität wünschenswert Performance / Durchlaufsdauer

unter eine Minute

Verwendungshäufigkeit einige wenige mal während des Projekts

Use Case 7: Benutzer exportiert ein Use Case

Anhang 74

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 Interessen

Benutzer: Use Case füllen bzw. korrigieren Konstruktion: Datenkonsistenz


Benutzer möchte ein Use Case ausfüllen bzw. korrigieren.

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.

Erfolgsszenario

5 Konstruktions-analyzer

validiert die Eingaben des Benutzers.

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.

Es existiert eine Erfahrung:

Erweiterungen

3c, 5a à UC 11: Der Assistent zeigt eine Erfahrung an.


Je nach Schnelligkeit des Benutzers zwischen einigen Minuten und einer Stunde

Verwendungshäufigkeit Sehr häufig, mehrmals am Tag

Use Case 8: Benutzer bearbeitet ein Use Case

A Use Cases

75

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 Interessen

Benutzer: einen (weiteren) Schritt anlegen Konstruktion: Datenkonsistenz


Benutzer möchte einen (weiteren) Schritt einfügen.

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.

Erfolgsszenario

4 Konstruktions- analyzer

validiert die Eingabe.

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. Es existiert eine Erfahrung:

Erweiterungen

2b,4a à UC 11: Der Assistent zeigt eine Erfahrung an.


wenige Minuten

Verwendungshäufigkeit Laufend Use Case 9: Benutzer fügt einen (weiteren) Schritt ein

Anhang 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


Benutzer möchte sich die Änderungen anzeigen.

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.

Erfolgsszenario

6 Konstruktion zeigt keine Änderung mehr an. 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.

Erweiterungen

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

77

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

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.

Erfolgsszenario

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.

Benutzer möchte die aktuelle Erfahrung ergänzen: 5d à UC 12: Benutzer erweitert eine Erfahrung.

5e Der Benutzer möchte den Assistenten deaktivieren, da die Warnungen und Erfahrungen stören:

5e1 Benutzer blendet den Assistenten aus.

Erweiterungen

5e2 Assistent blendet sich aus.

Anhang 78


Das Anzeigen der Erfahrungen dauert unter eine Sekunde. 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

79

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

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.

Erfolgsszenario

3 Assistent speichert die Änderung automatisch ab. 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.

Erweiterungen

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

Anhang 80

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 Interessen

Benutzer: seine Erfahrung anderen Benutzern zugänglich machen Argumentation: Datenkonsistenz


Benutzer möchte seine Erfahrung hinzufügen.

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.

Erfolgsszenario

4 Assistent fügt die neue Erfahrung ein. Schritt Akteur Aktion

Benutzer bricht ab: 1a, 2a, 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.

Erweiterungen

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

81

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

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.

Erfolgsszenario

4 Spezifikation wendet das Template auf alle im Projekt vorhandenen Use Cases an.

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:

Erweiterungen

4a1 Spezifikation verwirft die Daten. Priorität Wünschenswert Performance / Durchlaufsdauer

Einigen Minuten

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

Anhang 82

B XML Schemata

ProjectScheme.xsd

<?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="Project"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:element name="date_created" type="xsd:integer" minOccurs="1" maxOccurs="1"/> <xsd:element name="date_lastmodified" type="xsd:integer" minOccurs="1" maxOccurs="1"/> <xsd:element name="title" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="description" type="xsd:string" minOccurs="0" maxOccurs="1"/> <xsd:element name="usecases"> <xsd:complexType> <xsd:sequence> <xs:element ref="UseCase" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="template" type="UseCaseTemplate" minOccurs="1" maxOccurs="1"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="UseCase"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:key name="id"> <xsd:selector xpath=".//UseCase/id"/> </xsd:key> <xsd:element name="date_created" type="xsd:integer" minOccurs="1" maxOccurs="1"/> <xsd:element name="date_lastmodified" type="xsd:integer" minOccurs="1" maxOccurs="1"/> <xsd:element name="attribues"> <xsd:complexType> <xsd:sequence> <xs:element ref="UseCaseAttribute" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="UseCaseAttribute"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:element name="date_lastmodified" type="xsd:integer" minOccurs="1" maxOccurs="1"/> <xsd:element name="key" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="value"> <xsd:complexType> <xsd:choice> <xsd:element ref="xsd:string" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="Actor" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="Scenario" minOccurs="0" maxOccurs="1"/>

B XML Schemata

83

<xsd:element ref="Extension" minOccurs="0" maxOccurs="unbounded"/> </xsd:choice> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Actor"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:element name="interests" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="name" type="xsd:string" minOccurs="1" maxOccurs="1"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Scenario"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:element name="steps"> <xsd:complexType> <xsd:sequence> <xs:element ref="Step" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="LinkedUseCase" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Step"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:element name="actor" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="action" type="xsd:string" minOccurs="1" maxOccurs="1"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="LinkedUseCase"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:keyref name="linkedUseCase" refer="id"> <xsd:selector xpath=".//UseCase/id"/> </xsd:keyref> <xsd:element name="userPrintable" type="xsd:string" minOccurs="1" maxOccurs="1"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Extension"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:element name="extendingsteps" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="condition" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="scenario" type="Scenario" minOccurs="1" maxOccurs="1"/> </xsd:sequence> </xsd:complexType> </xsd:element>

Anhang 84

<xsd:element name="UseCaseTemplate"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:element name="attribues"> <xsd:complexType> <xsd:sequence> <xs:element ref="UseCaseTemplateAttribute" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="UseCaseTemplateAttribute"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:element name="key" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="required" type="xsd:boolean" minOccurs="1" maxOccurs="1"/> <xsd:element name="enabled" type="xsd:boolean" minOccurs="1" maxOccurs="1"/> <xsd:element name="choices" type="xsd:string" minOccurs="1" maxOccurs="1"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>

ExperienceBaseScheme.xsd

<?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="Help"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:key name="id"> <xsd:selector xpath=".//id"/> </xsd:key> <xsd:element name="date_created" type="xsd:integer" minOccurs="1" maxOccurs="1"/> <xsd:element name="date_lastmodified" type="xsd:integer" minOccurs="1" maxOccurs="1"/> <xsd:element name="teaser" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="description" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="weight" type="xsd:float" minOccurs="1" maxOccurs="1"/> <xsd:element name="forEditingUseCase" type="xsd:boolean" minOccurs="1" maxOccurs="1"/> <xsd:element name="forAttribute" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="attached"> <xsd:complexType> <xsd:sequence> <xs:element ref="ExperienceExtension" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element>

B XML Schemata

85

<xsd:element name="Warning"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:key name="id"> <xsd:selector xpath=".//id"/> </xsd:key> <xsd:element name="date_created" type="xsd:integer" minOccurs="1" maxOccurs="1"/> <xsd:element name="date_lastmodified" type="xsd:integer" minOccurs="1" maxOccurs="1"/> <xsd:element name="teaser" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="description" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="weight" type="xsd:float" minOccurs="1" maxOccurs="1"/> <xsd:element name="checker_classpath" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="param_string" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="attached"> <xsd:complexType> <xsd:sequence> <xs:element ref="ExperienceExtension" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Error"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:key name="id"> <xsd:selector xpath=".//id"/> </xsd:key> <xsd:element name="date_created" type="xsd:integer" minOccurs="1" maxOccurs="1"/> <xsd:element name="date_lastmodified" type="xsd:integer" minOccurs="1" maxOccurs="1"/> <xsd:element name="teaser" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="description" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="weight" type="xsd:float" minOccurs="1" maxOccurs="1"/> <xsd:element name="checker_classpath" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="param_string" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="attached"> <xsd:complexType> <xsd:sequence> <xs:element ref="ExperienceExtension" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="ExperienceExtension"> <xsd:attribute name="class" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:complexType> <xsd:sequence> <xsd:key name="id"> <xsd:selector xpath=".//id"/> </xsd:key>

Anhang 86

<xsd:element name="date_created" type="xsd:integer" minOccurs="1" maxOccurs="1"/> <xsd:element name="date_lastmodified" type="xsd:integer" minOccurs="1" maxOccurs="1"/> <xsd:element name="teaser" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="description" type="xsd:string" minOccurs="1" maxOccurs="1"/> <xsd:element name="attached"> <xsd:complexType> <xsd:sequence> <xs:element ref="ExperienceExtension" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>

C Programm und Quellcode

87

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.

Anhang 88

D Umfrageergebnis

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

89

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

Anhang 90

Erklärung

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

Konzept und Werkzeug zur erfahrungsbasierten Erstellung ... · PDF file8 2. Grundlagen 2.1 Use...

Documents

Transcript of Konzept und Werkzeug zur erfahrungsbasierten Erstellung ... · PDF file8 2. Grundlagen 2.1 Use...