Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

Projekt: P2P Java Gui Plattform für LoNo Funktionen

<< < (3/8) > >>

Axel_Janssen:
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.

--- Code: ---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.

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


--- Code: ---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.

--- Ende Code ---

Axel_Janssen:
 
Sehr ähnlich sieht der Use Case “ Kategorie erstellen” aus

--- Code: ---Use Case2: Kategorie erstellen:
Main Success Scenario:
Der code Dokument producer wählt eine Oberkategorie für die neue Kategorie aus oder nicht. Wenn nicht, ist die neue Kategorie eine first-level Kategorie. Über den Button „Kategorie abspeichern“ sendet er eine Nachricht an die Datenbank, dass sie die neue Kategorie abspeichern soll.

Alternate Scenario1:
Wenn der code Dokument producer nichts in das Namensfeld der Kategorie eingetragen hat,. erhält eine eine Fehlermeldung und der Datensatz wird nicht in die Datenbank abgespeichert.

Alternate Scenario2:
Wenn die Datenbank zurückmeldet, dass sie unter der gleichen Oberkategorie bereits eine gleichnamige Kategorie abgespeichert hat, erhält der Code-Dokument producer eine Fehlermeldung und der Datensatz wird nicht in die Datebank abgespeichert.

Alternate Scenario3:
Wenn die Datenbank zurückmeldet, dass sie zur Zeit keine neuen Datensätze abspeichern kann, bekommt der Code Dokument producer eine Meldung in Form einer Messagebox.

--- Ende Code ---

Der Use Case für „Code Dokument suchen“ sieht so aus:

--- Code: ---Use Case2: Code Dokumente suchen:
Main Success Scenario:
Der Code Dokument Consumer (neuer Akteur!)
a)   wählt in einem hierarchischen Kategorie-Baum (ähnlich wie Windows-Explorer) die gewünschte Kategorie aus und
b)   macht einen Eintrag in das Feld Volltextsuche, betätigt den „Senden“-Button und
erhält eine Trefferliste, der gefundenen code Dokumente zurück.
Er kann die sich nun angucken. Wenn ihm ein code Dokument gefällt, kann er über den  Button „code Dokument in die Zwischenablage kopieren“, den code inklusive aller referenzierten Unterfunktionen in die Zwischenablage des OS-kopieren und im Domino Designer über Strg-V wieder reinkopieren.

Alternate Scenario1:
Der Volltextindexierungsservice kann die Anforderung nicht verarbeiten. Der code Dokument consumer erhält vom System eine Fehlermeldung.

--- Ende Code ---

Kommt nun noch das Kollaborationsfeature „Replizierung für Arme“. Es kann später durch einen echten P2P-Service ersetzt werden... Sollte das System genutzt werden, lohnt sich die Mühe. Im ersten Release gibt es nur „Replizierung für Arme“


--- Code: ---Use Case2: Replizierung durchführen:
Main Success Scenario:
Der replication requester wählt aus einer Liste an Teilnehmern aus, mit wem er replizieren will.
Betätigt der replication requester die Schaltfläche „request Datei erzeugen“ generiert das System eine xml-Datei (request.xml) als Übersicht über sämtliche Datensätze, die in der Datenbank des replication requesters enthalten sind.
Diese request.xml sendet er als email an denjeningen, von dem er eine pull-replikation haben will (replication requested).
Der replication responder empfängt die email und speichert die request.xml im selben OS-Verzeichnis wie sein code-store Programm. Er startet das code-store Programm. Er betätigt die Schaltfläche „replication request bearbeiten“. Das System überprüft, welche code-Dokument, Kategorie und Teilnehmer-Daten sich in seiner Datenbank enthalten sind, aber in der Übersicht der request.xml fehlen. Diese Datensätze packt das System in eine Datei response.xml.
Der replication responder sendet eine email an den replication requester mit der response.xml als attachment.
Der replication requester empfängt die email und packt die response.xml in das OS-Verzeichnis seines code-store Programms. Er startet das code-store-Programm und betätigt die Schaltfläche „replication-response einfügen“. Das System übergibt die Inhalte des Kommentarfeldes der Datensätze dem Volltextindexierungsservice, es fügt die neuen Datensätze aus der Datei response.xml in seine Datenbank ein und baut die Kategorisierung neu auf.

Alternate Scenario1
Das System kann die request.xml nicht erstellen. Der replication requester erhält eine Fehlermeldung als messagebox.

Alternate Scenario2:
Das System des replication responders kann die request.xml nicht verarbeiten. Der replication responder erhält eine Fehlermeldung als messagebox.

Alternate Scenario3
Das System des replication responders kann die response.xml nicht erstellen. Der replication responder erhält eine Fehlermeldung als Messagebox.


Alternate Scenario4
Das System des replication requesterskann die response.xml nicht verarbeiten. Der replication requester erhält eine Fehlermeldung als Messagebox.


Alternate Scenario5:
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 Scenario6:
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.
 
--- Ende Code ---

Es gibt noch weitere Use Cases zu den Themen Teilnehmerdaten verwalten, sowie Erweiterungen für die Anwendungsfälle "Code Dokument erstellen“ und „Kategorie erstellen“ (jeweils bestehende bearbeiten). Dies ist aber jetzt erst mal zu trivial, als das es aufgeführt werden müßte. Ich komme später darauf zurück.

Hier ist ein UML Use Case Diagramm, das alle Use Cases übersichtlich darstellt. So wahnsinnig sinnvoll ist dieser Diagrammtyp nicht, ausser das er eine Übersicht bietet.

Das <<verwendet>> zwischen "Code-Dokument erstellen" und "Kategorie erstellen" soll eigentlich <<uses>> heissen. Schuld ist erstmal Visio.
Wenn sich jemand den use case "code Dokument erstellen" noch mal durchliest, sieht er, dass in dem use case der code-Dokument producer eine neue Kategorie erstellen kann. Dies wird mit dem <<uses>> alias <<verwendet>> ausgedrückt.
Ach ja. Die lustigen Linien zwischen den Akteuren und den Use Cases zeigen an, welche Akteure bei weilchen Use Cases beteiligt sind.
Ich hätte auch noch die Anwendungsfälle "code-Dokument bearbeiten" und "Kategorie bearbeiten" hinzufügen können, die dann von den use cases "Code-Dokument erstellen" und "Kategorie erstellen" erben (Schlüsselwort <<extends>>) oder "code Dokument suchen" als abstrakten use case definieren können, von dem die use cases "code Dokument über Kategorie suchen" und "code Dokument über Volltextindex suchen" erben... . Das hätte aber das Diagramm überfrachtet. So wichtig ist der Sachverhalt nicht. Diese ganze Vererberei ist in OO-Land sowieso ein bischen out. Use Cases haben eine reichhaltiges Angebot an Erweiterungen (extension points, abstrakte use cases, etc). Die Literatur rät aber dringend dazu, die Dinge einfach zu halten, es sei denn man hat wirklich gute Gründe, die erweiterten features zu nutzen. Die sehe ich hier nicht.  

Für die Inception Phase fehlt jetzt noch auf jeden Fall eine Aufstellung der nicht-funktionalen Anforderungen. Schliesslich behandeln Use Cases nur funktionale Anforderungen. Aber das kommt morgen.

Der Text der Use Cases wird in der nun folgenden OOAnanalyse dazu dienen, die Klassen der Business Domäne herauszufinden: Das heisst, die Namen der Klassen, ihre Verantwortlichkeiten und ihre Kollaborationen (also welche Klassen mit welchen anderen Klassen zusammenarbeiten).
Ein Use Case mit starker Querschnittsfunktionalität für das gesamte System („Code Dokument erstellen“) werde ich auch schon mal durchprogrammieren (schliesslich will ich ja iterativ arbeiten, d.h. die Dinge Requirement Analyse --> OO-Analyse --> OO-Design --> codieren --> testen nicht streng hintereinander, sondern durcheinander durchführen).

Aufgrund der Gui-Lastigkeit der Anwendung macht ein GUI-Prototyp Sinn. Das notieren der Use-Cases haben mir auch geholfen, ein Bild der GUI im Kopf zu entwickeln. Dies sollte ich dann auch festhalten, sonst vergesse ich das wieder.
Um dies zu notieren, bieten sich theoretisch Java-Swing GUI-IDE-Tools an. Da ich aufgrund schlechter Erfahrungen Anfang Dezember mit dem momentanen Stand dieser Tools ein bischen auf dem Kriegspfad mit demselben bin, werde ich den Prototyp mit dem Notes-Client machen.

Axel_Janssen:
Keine Ahnung, ob sich das jemand durchliest, oder ob die spärlichen Leser dieses Forums mich für endgültig und unwiederbringlich durchgeknallt halten.  :-[

Dies ist für mich erstmal Teil meiner Vorbereitung von IBM_486. Es darüber hinaus ein Kommunikationsangebot. Praktische Objekt-Orientierung ist ein Prozess. Das versuche ich hier darzustellen. Nachdem die technischen Details wg. besserer Tools, allgemeinen Forum- und Google-Support und Globalisierung zunehmend zu einem commodity werden, kann es nur darum gehen die Prozesse zu beherrschen.
Das ist sicher nicht trivial. U.a. auch deshalb, weil ich teilweise ins Detail gehen muß. Meiner Ansicht nach bestehen extrem viel Missverständnisse bezüglich OOA/D. Ich versuche hier darzustellen, wie mein OOA/D-Prozess wirklich aussieht. Ich hoffe das ist einigermassen verständlich. Für viele enthält der Text sicherlich viele neue Konzepte und ist deshalb nicht einfach zu durchdringen.

Gruß Axel

animate:
klar liest das jemand.

ein paar Anmerkungen habe ich dazu:

an einigen Stellen in deinen UseCases bist du IMHO viel zu detailliert. Use Cases sind ein Teil der Analyse und beschreiben, wie du schon sagtest, das "Was", nicht das "Wie". Allerdings machst du in deinen Use Cases schon Vorgaben,(z.B.) dass eine Datei im xml-Format geschrieben werden soll, dass die Meldung an den Benutzer in Form einer Msgbox erfolgt.
Solche Sachen sind (alles IMHO) nicht Sache von UseCases.

Weiter oben in dem Thread schreibst du, dass die Datenbank (wieder so eine Vorgabe) Teil des Systems ist. In deinem UC-Diagramm ist die Datenbank aber eindeutig außerhalb des Systems.
Meine Frage deshalb, was umfasst das System? Nur die GUI, wie der Threadtitel vermuten lässt, oder all das, was später vom Benutzer dazu verwendet werden soll, um Code leicht wiederzuverwenden (denn dann würde ich sowohl die Datenbank als auch den Indizierungsservice mit zum System zählen)?

Ich les jetzt mal weiter, vielleicht habe ich dann noch ein paar mehr Anmerkungen.

Just my 0.02€

Frohe Weihnachten

Axel_Janssen:

--- Zitat von: potsmoker am 24.12.03 - 15:09:02 ---klar liest das jemand.

--- Ende Zitat ---

danke.


--- Zitat von: potsmoker am 24.12.03 - 15:09:02 ---an einigen Stellen in deinen UseCases bist du IMHO viel zu detailliert. Use Cases sind ein Teil der Analyse und beschreiben, wie du schon sagtest, das "Was", nicht das "Wie". Allerdings machst du in deinen Use Cases schon Vorgaben,(z.B.) dass eine Datei im xml-Format geschrieben werden soll, dass die Meldung an den Benutzer in Form einer Msgbox erfolgt.
Solche Sachen sind (alles IMHO) nicht Sache von UseCases.

--- Ende Zitat ---
Streber. ;D
Im Prinzip hast du völlig Recht. Wir befinden uns in der Analyse Perspektive. Ich habe hier ein vielleicht grundsätzliches Problem. Was würdest du statt xml-Datei verwenden???
Datei? Vielleicht besser. Oder was anderes?


--- Zitat von: potsmoker am 24.12.03 - 15:09:02 ---Weiter oben in dem Thread schreibst du, dass die Datenbank (wieder so eine Vorgabe) Teil des Systems ist. In deinem UC-Diagramm ist die Datenbank aber eindeutig außerhalb des Systems.
Meine Frage deshalb, was umfasst das System? Nur die GUI, wie der Threadtitel vermuten lässt, oder all das, was später vom Benutzer dazu verwendet werden soll, um Code leicht wiederzuverwenden (denn dann würde ich sowohl die Datenbank als auch den Indizierungsservice mit zum System zählen)?

--- Ende Zitat ---
Da war ich oben falsch. Ich räume das irgendwann auf. Datenbank und Indexierungsservice sind eindeutig nicht Teil des Systems. Sehr wohl wird aber der Database Access Layer, der aus der Anwendung mit der Datenbank kommuniziert, eindeutig Teil des Systems sein. Datenbank und Indexierungsservice sind dagegen black boxes für mich. Auch wenn es open Source ist, werde ich da vermutlich keinen code verändern, sondern sie vielmehr quasi als Dienste einbinden. Deshalb ausserhalb.
 
Der Begriff Datenbank sehe ich als keine starke Einschränkung ein. Es kann RDBMS, Notes-Datenbank oder xml-Datei sein (für mich sind xml-Dateien Datenbanken, wobei man darüber streiten kann). Wieder. Was würdest du statt Datenbank verwenden?
Neben GUI und Database Access Layer werden auch die Domain Objekte sowie verschiedene Helper, Startup und was weiss ich Klassen Teil des Systems sein.

Frohe Weihnachten

Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete