Ziel: Computerprogramm in Rahmen eines iterativen OOA/D-Prozesses zu erstellen.
Zunächst fokussiere ich mich darauf, die groben Anforderungen für das System zu ermitteln.
Da es sich um einen iterativen Prozess handelt, wird
nicht jedes Anforderungs-Detail genau spezifiziert. Schliesslich ändern die User ihre Anforderungen sowieso.
Use Cases sind nicht OO-spezifisch. Ich benutze seit Jahren Use Cases für die Ermittlung von Anforderungen in reinen Notes-Projekten.
Anwender verfolgen spezifische Business-Ziele. Ein Computersystem soll sie dabei unterstützen. OOA/D besteht aus einem Analyse Teil (das A) und einem Design-Teil (das D). In dem Analyseteil soll erst mal ermittelt werden, „was“ das System leisten soll. Im Design-Teil wird danach gesucht, „wie“ das System die Anforderungen erfüllen soll. Bevor man mit der OO-Analyse überhaupt richtig anfängt benötigt man erstmal eine Analyse der Anforderungen.
Sprachlich treffen in einem Software-Projekt 2 Welten aufeinander. Auf der einen Seite die Entwickler mit ihrer Fachsprache und auf der anderen Seite die Anwender mit ihrer Fachsprache. Der Vorteil von Fachsprachen besteht darin, dass komplexe Sachverhalte effizient ausgedrückt werden können. Der Nachteil ist, dass sie in aller Regel relativ hermetisch sind. D.h. Außenseiter in Bezug auf die jeweiligen Fachsprache verstehen erst mal nur Bahnhof. Die wichtige Quelle für die Anforderungen sind die Anwender. Deshalb soll auch deren Sprache dominieren. Die Entwickler müssen also lernen, sich in der Fachsprache der Anwender einigermassen zurechtzufinden. Als zusätzliches sinnvolles Analyse-Artefakt kann ein Glossar über die Fachsprache erstellt werden. Da hier ein System erstellt wird, dass Entwicklern hilft, Lotus-Script Funktionen zu speichern, katalogisieren und auszutauschen, sprechen hier Anwender und Entwickler die selbe Sprache. Die Anwender sind eben auch Entwickler.
Larman spricht von unterschiedlichen Formaten für Use-Cases. Zunächst kann das brief-informal Format benutzt werden.
Use Case1: Code-Dokument erstellen
Der Anwender wählt die Kategorie, unter dem die neue Funktion gespeichert werden soll oder er erzeugt eine neue Kategorie. Er gibt der Funktion einen Namen, gibt einen Kommentar an, fügt Referenzen auf bestehende Funktionen hinzu, von denen die neue Funktion abhängt, schreibt einen aussagekräftigen Kommentar, fügt den code ein und sendet an das System die Nachricht, dass das neue code-Dokument abgespeichert werden soll. Das System validiert, ob alle notwendigen Eingaben getätigt sind und übergibt den Text des Kommentarfeldes dem Volltextindiexierungsservice und speichert das code-Dokument in einer exterenen Datenbank ab.
So werden funktionale Anforderungen in der Form kleiner Geschichten aufgezeichnet, die darüber handeln, wie die Anwender das System benutzen, um ihre Geschäftsziele zu erreichen. Also keine unzusammenhängenden feature-Listen. Der Ausschnitt des beschriebenen Systemverhalten ist so groß, dass er aus der Sicht des Anwenders einen Wert für seine Arbeit hinzufügt. Füllt der Anwender eine Maske aus und speichert die Daten über einen „Speichern“-Button in eine Datenbank, ist „Speichern in eine Datenbank“ kein eigener Use Case. Für den Anwender ist die Eingabe der Daten und das Drücken des „Speicher“-Buttons ein atomarer Vorgang. Eingeben und Speichern zusammen ist also möglicherweise ein Use Case. Muß ein Anwender beispielsweise für einen Geschäftsvorgang ein Kategoriedokument erstellen und dann erst das eigentliche Dokument, dann ist Kategoriedokument erstellen kein eigener Use cases, sondern beides zusammen.
Begriffe der Informatik werden vermieden. So kann der Gebrauch von „Datenbank“ angegriffen werden. Ich finde das aber ok, weil es ein Begriff ist, der von den meisten verstanden wird. Der oben aufgezeichnete informelle Anwendungsfall nimmt viele Details nicht auf. Das ist möglicherweise gut so, um den use case für alle Beteiligten einfach verstänlich zu halten. Schliesslich will keiner bei der Arbeit unnötig intelektuell gefordert werden. Das führt sowieso nur zu zuviel Kaffee oder gar schlimmeren (z.B. Zigaretten).
In unseren Use Case fehlen aber noch definitiv die Fehlerbedingungen, die auftreten können und wie die Fehlermeldungen dem Anwender mitgeteilt werden. Ich kenne mindestens 2 größere Notes-Projekte, bei denen Verbindungsprobleme mit einer externen RDBMS dem Anwender nicht korrekt mitgeteilt wurden. Die standen dann im Log. Das las keiner. Die Systeme arbeiteten dann über einen mehr oder weniger langen Zeitraum nicht korrekt und die Anwender wurden verunsichert, da keiner wusste warum das System nicht richtig rund lief. Konkrete Fehlermeldungen sind also konkret wichtig.
Der oben aufgeführte Use Case sollte also noch in ein exakteres Format übertragen werden. Das informelle Format beschreibt eigentlich nur ein Szenario bzw. eine Instanz des Use Cases. Den sogenannten lucky path oder main success scenario(alles funktioniert). Daneben sollen auch Fehlerbedingungen aufgeführt werden.
Ausserdem sollte man bei der Spezifizierung der UML-Akteure genauer sein. Anwender ist ein wenig zu allgemein. Eine physische Person kann mehrere UML-Akteure verkörpern. Ein besserer Begriff für Akteur (engl. actor) wäre Rollen. Angeblich geht diese semantische Unschärfe auf Übersetzungsfehler aus dem schwedischen zurück. Die erste Person, die theoretisch über Use Cases publizierte, war der Ericson Mitarbeiter Ivar Jacobson.
Die Use Cases dienen letztlich in ihrer Gesamtheit dazu, alle Akteure (d.h. Rollen) eines Systems zu ermitteln.
Als Akteure haben wir zunächst den code-Dokument producer. Daneben sind auch andere Systeme, mit denen unser System kommuniziert, Akteure. In unserem Fall sind dies zunächst der Volltextindexierungs- Service und die Datenbank.
Deshalb gehen wir zum nächsten Format über, dem sogenannten casual Format (laut Larman).
Use Case1: Code-Dokument erstellen
Main Success Scenario:
Der code-Dokument producer wählt die Kategorie, unter dem die neue Funktion gespeichert werden soll oder er erzeugt eine neue Kategorie. Er gibt der Funktion einen Namen, gibt einen Kommentar an, fügt Referenzen auf bestehende Funktionen hinzu, von denen die neue Funktion abhängt, schreibt einen aussagekräftigen Kommentar, fügt den code ein und sendet an das System die Nachricht, dass das neue code-Dokument abgespeichert werden soll. Das System validiert, ob alle notwendigen Eingaben getätigt sind, übergibt den Text des Kommentarfeldes dem Volltextindiexierungsservice und speichert das code-Dokument in einer exterenen Datenbank ab.
Alternate Scenario1:
Wenn das System bei der Validierung der eingegebenen Daten bemerkt, dass die Daten nicht komplett sind, wird der code-Dokument producer mit einer Message-Box darauf aufmerksam gemacht. Eine Volltextindexierung und das Abspeichern der Daten in der Datenbank findet nicht statt.
Alternate Scenario2:
Wenn der Volltextindexierungsservice zurückmeldet, dass er den Text des Kommentarfeldes nicht verarbeiten kann, wird der Datensatz in die Datenbank mit einem Vermerk „nicht Volltextindexiert“ abgespeichert. Der Anwender wird mittels einer Messagebox über die nicht stattgefundene Volltextindizierung informiert. Bei einem späteren Systemstart, wird versucht die Volltextindexierung für das entsprechende code-Dokument durchzuführen. Der Vermerk im Datensatz in der Datenbank wird auf „volltextindiziert“ umgestellt. Der Anwender wird informiert.
Alternate Scenario3:
Wenn die Datenbank zurückmeldet, dass sie zur Zeit keine neuen Datensätze abspeichern kann, bekommt der code Dokument producer eine Meldung über eine Messagebox. Die Volltextindexierung wird rückgängig gemacht.
Thema: Projekt: P2P Java Gui Plattform für LoNo Funktionen (Gelesen 31373 mal)