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

Projekt: P2P Java Gui Plattform für LoNo Funktionen

<< < (7/8) > >>

Axel_Janssen:
Für den Use Case „Code Dokument erstellen“ generiere ich ein sogenanntes System Sequence Diagram. Das ist eine Sequenz an Nachrichten, die der Anwender mit dem System austauscht. Das System selbst wird dabei als black box betrachtet.

Inzwischen bin ich überzeugt, dass Potsmokers Einwände zu 95% korrekt waren. Ich habe Fehler gemacht. Ich bringe den Use Cases in ein vollständiges Format und ändere ein paar Dinge. Tatsächlich war der Begriff Datenbank unglücklich gewählt. Korrekt ist es zunächst bei einem Begriff zu bleiben, der aus der Welt der Problem-Domäne und nicht der Lösungs-Domäne angehört. Ich wähle also Code-Dokument Katalog statt Datenbank.
Ausserdem war es ein bischen design-overkill, den Anwender in die Rollen code-document producer, code-document consumer, etc. aufzuspalten.
Für dieses kleine System reicht eine Rolle Anwender, die mehrere Funktionen im System ausfüllt:
UC1: Code Dokument erstellen

Primärer Akteur: Anwender
Stakeholders and Interests:
[...] hier zu trivial

Main Success Scenario
Preconditions: Anwender ist im System authentifiziert
Postconditions:
Das neue Code-Dokument ist im Code Dokument Katalog eingefügt.
Der Indexierungsservice hat das Code-Dokument indexiert.
Das Code-Dokument kann über die Kategoriesuche und die Volltextsuche jederzeit aufgerufen werden.

Main Success Scenario:
1.   Anwender startet Erstellung eines neuen Code Dokuments
2.   Anwender fügt die benötigten textlichen Informationen  (Beschreibung, Beschreibung der Verwendung, code)
3.   Anwender wählt bei Bedarf aus der Liste der bestehenden LotusScript-Funktionen die aus, auf die der code im neuen Code-Dokument zugreift.
4.   Anwender wählt die Kategorie des neuen Code Dokuments
5.   Anwender teilt mit, dass Eingaben abgeschlossen.
6.   System prüft Korrektheit der Eingaben.
7.   Indexierungsservice indexiert Beschreibung.
8.   System fügt Code Dokument dem Code-Dokument Katalog hinzu und persistiert diese Änderung in eine Datenbank (hehe).
9.   System logged erfolgeiche Erstellung des neuen Code Dokuments.
10.   System teilt Anwender mit, dass Code-Dokument erfolgreich dem Code-Dokument Katalog hinzugefügt wurde.

Extensions (or Alternative Flows)
4. a) Anwender erstellt eine neue Kategorie -> Use Case „Neue Kategorie erstellen”

6.a) Anwender wird mit einer Nachricht auf die fehlenden Eingaben. Zurück zu 3.

7.a) Indexierung schlägt fehl
8.a) System fügt Code Dokument dem Code-Dokument mit dem Attribut „Code-Dokument nicht indexiert“ hinzu und persistiert diese Änderung in eine Datenbank.
9.a) System locked Erstellung des neuen Code Dokuments mit Hinweis auf fehlende Volltextindexierung.
10.a) System teilt Anwender mit, dass Code-Dokument erfolgreich dem Code-Dokument Katalog hinzugefügt, aber nicht volltextindexiert wurde.
11.   Bei einem Neustart des Systems wird versucht den Volltextindex zu erstellen (Teil des startup Use Cases!).

8.a) Hinzufügung des Code Dokuments zum Code Dokument Katalog und ?ersistierung diese Änderung in eine Datenbank.scheitert.
9.a) System logged gescheitertes Hinzufügen des Code Dokuments zum Code Dokument Katalog
10.a) User erhält Nachricht über gescheitertes Hinzufügen des Code Dokuments zum Code Dokument Katalog

Man kann nun noch für das Main Success Scenario ein sogenanntes System Sequence Diagram erzeugen. Das Sequence Sequence Diagram enthält die zwischen den Akteuren gesendeten Nachrichten. Dabei wird das System als Black Box betrachtet.
Ich habe ein bischen die Orthodoxie verlassen, indem ich nicht nur die Interaktion zwischen dem primären Akteur „Anwender“ und dem System zeige, sondern auch die Interaktion mit den sekundären Akteuren Datenbank, Indexierungsservice und Loggingservice. Ob das sinnvoll ist, kann ich nicht beurteilen. Eigentlich verliert das System dadurch ein wenig seinen (passiven) black box Charakter. Es ruft ja selber akiv die Operationen indexCodeDocument(), saveCodeDocument() und logMessage() auf.
Ich finde, man muß das nicht so päbstlich sehen. Modelle sind nie richtig oder falsch sondern immer mehr oder weniger nützlich. Bubbles don’t crash. An einem ausführbaren Programm kann in der Regel gut gezeigt werden, dass es nicht funktioniert. Bei einem Modell ist das schwieriger. Ein Modeller kann sich besser rausreden als ein Programmierer.

Da die deutsche Sprache in Computern sowieso meist zu einer kruden Mischung aus Deutsch und Englisch führt, nehme ich Englisch als Sprache. Als Input für die Namensfindung benutze ich den Text des Use Cases.

Beispiel:
Anwender wählt die Kategorie des neuen Code Dokuments
wird zur Operation selectCategory() usw.
 
Dieses generelle Vorgehen ist charakteristisch für den (Rational) Unified Process. Es wird sich von dem spezifischen Problem in der Welt der Anwender immer näher der Lösung, dem Computerprogramm angenähert. Auf dem Weg wird ein Haufen an Dokumenten erstellt. Bei jedem neuen Schritt wird auf die in die vorherigen Schritte erstellten Dokumente zurückgegriffen. Trotz aller Objektorientierung geht man also davon aus, dass die Domäne des Geschäftsprozesses, der durch die Software unterstützt werden soll, unterschiedlich ist von der Welt der Software. Ansonsten bräuchte man nicht diesen komplexen Analyseprozess. Mit Objektorientierung wird nur die semantische Lücke zwischen Geschäftsbereich und Software geringer, nicht geschlossen.



Die Kästchen oben beschreiben den Akteur. Ich stelle sie als UML-Objekte dar. Der Syntax von UML-Objekten ist Objektbezeichner:Klassenbezeichner. Ich benötige keinen Objektbezeichner, deshalb nehme ich :Klassenbezeichner. Die vertikalen gestrichelten Linien sind die Objektlebenslinien. Das Diagramm zeigt, dass die Akteurs-Objekte länger leben als die Zeitspanne des dargestellten Use Cases. Die Pfeile stehen für Nachrichten, die zwischen den Objekten ausgetauscht werden. Eine Nachricht ist: Objekt x ruft die Operation a des Objekts y auf.

Beispiel: Der Akteur User ruft die Operation selectFunctionsUsed() des System auf.

Die Begriffe Operation und Methode werden oft synonym verwendet. Das ist nicht ganz richtig. Eine Operation bezeichnet lediglich den Methoden-Header. Methode strenggenommen nur die Implementierung.


--- Code: ---public String intToString(int num) {
   return “” + num;
}

--- Ende Code ---
ist eine Methode. (Header und Body).


--- Code: ---public String intToString(int num)

--- Ende Code ---
die entsprechende Operation der Klasse, die von ausserhalb oder innerhalb eines Objekts der Klasse angesprochen werden kann. Da wir uns im konzeptionellen Analyse-Modus und nicht im Implementierungs-Modus befinden, interessieren uns nur die Operationen, nicht die Methoden.  

Rückgaben von Operationen können optional als gestrichelte Pfeile angezeigt werden. Der Anwender sendet dem System eine Nachricht, indem er dessen Operation saveCodeDocument() aufruft.
Dies führt zu einer Sequenz von Nachrichten, die zwischen den Akteuren System, Database, IndexService und LoggingService gesendet werden. Am Ende erhält der Anwender „message“ als Rückgabewert der Operation.
In diesem frühen konzeptionellen Diagramm habe ich auf Operationsparameter und die Spezifizierung der Rückgabewerte verzichtet. Ein Modell soll nicht die wirkliche Welt darstellen, sondern sich auf die wichtigen Dinge fokussieren. Bubbles don’t crash.

Von diesen Operationen lassen sich später die tatsächlichen Methoden des ausführbaren Systems ableiten.

animate:
Der renovierte UC1 gefällt mir jetzt echt sehr gut. Eigentlich vorbildlich.

Axel_Janssen:
Es ist nun an der Zeit, sich dem statischen Domänen Modell zuzuwenden.
Die Use Cases und das System Sequence Diagramm beschreiben eine dynamische Sicht auf Geschäftsprozesse (eine Funktion notieren, kategorisieren und ablegen, Funktionen suchen, ). Es sollen nun aus einer konzeptionellen Perspektive heraus die statischen Entitäten und Akteure (konzeptionelle Klassen) dieses Geschäftsprozesses, ihre Beziehungen untereinander sowie ihre Attribute herausgearbeitet werden.
Dies ist der entscheidende objekt-orientierte Schritt dieses Analyse-Prozesses. Die betrachtete Geschäfts-Domäne wird in verschiedene konzeptionelle Klassen dekompositioniert

Die Dokompisitionen der Geschäftsprozesse in der Analyse strukturierter Softwareentwicklung fokussiert sich vornehmlich auf die Prozesse und Funktionen, die objekt-orientierte Methode fokussiert sich auf die Aufteilung in konzeptionelle Klassen (Objekte). .

Das Klassenmodell aus der konzeptionellen Perspektive wird später im Design Modell in eine objektorientiertes Klassenmodell für die Softwarelösung transformiert werden.

Das System Sequence Diagramm (und die später im Design zu erstellenden Interaktionsdiagramme) beschreiben eine dynamische Sicht auf das Objektmodell der betrachteten Domäne. Das Klassenmodell eine statische Sicht.

In 3 Schritten werden jetzt
1. Die Klassen gesucht
2. Die Beziehungen zwischen den Klassen untersucht
3. Attribute für die Klassen hinzugefügt

Der erste (und wichtigste) besteht nun darin, die Analyse Klassen zu finden. Es wird gesagt, es ist besser ein Domain Modell über- als zu unterzuspezifizieren.
Wie finden wir nun diese konzeptionellen Klassen?
Larman führt 2 Techniken auf:
1. Aus allgemeinen Listen von Kategorien von konzeptionellen Klassen
2. Jedes Substantiv in einem Text über die Geschäftsdomäne (z.B. die Use Cases) ist ein Kandidat für eine konzeptionellen Klasse.
 
Ich wende Larmans Kategorie-Listen auf die bisher bekannten Use Cases an. Dabei benutze ich die Substantive in den Texten der UseCases als Kandidaten für konzeptionelle Klassen. Rein technische Komponenten, wie LoggingService und Database sind nicht Bestandteil des Domain Models. Der IndexingService jedoch schon, da er das Modell um einen Aspekt aus Anwendersicht erweitert:
LarmanKlassen im Projektphysische ObjekteBeschreibungen von Sachen CodeDocumentOrteTransaktionenItems in TransaktionenRollen von PersonenUserContainer für andere DingeCodeDocumentCatalog, UserCatalog, ReplicationRequest, ReplicationResponse, SearchHits, Dinge in einen ContainerReplicationRequestItem.Technische Geräte ausserhalb des SystemsIndexingServiceAbstrakte KonzepteCategoryOrganisationenEreignisseProzesseFullTextSearch, CategorySearchRegeln und PoliciesVerträgefinanzielle Instrumente und DiensteDokumente, Bücher
Dies ist keine abschliessende Liste. In späteren Analysen werden weitere Klassen gefunden und bestehende verworfen.

Nun sollen die statischen Verbindungen zwischen diesen Klassen gesucht werden.

Axel_Janssen:
Es geht nun darum, im Domain Modell Assoziationen zwischen den Klassen (genauer den Instanzen der Klassen im Programm) herzustellen.

Die Dauer der Beziehung wird dabei nicht im Fokus. Die Beziehungen können lang- oder kurzfristig sein.

Die Assoziation wird durch eine Linie zwischen den Klassen dargestellt. Im Domain Modell macht es oft Sinn die Assoziationsbeziehung durch einen Bezeichner wie contains, owns, etc. näher zu charakterisieren.

An beiden Typenden  heissen Rollen. Die Rollen besitzen neben einem Namen (oft nicht benutzt) und einer Navigierbarkeit (in Analysemodellen in der Regel nicht benutzt) eine Kardinalität (multiplicity). * steht für beliebig viele. Mögliche Kardinalitäten sind Zahlen oder Zahlenmengen wie 1 oder 0...3 oder 1,2,4.

Beispiel im Diagramm: Ein CodeDocumentCatalog enthält * (also 0 bis unendlich viele) CodeDocuments. Ein CodeDocument ist in einem CodeDocumentCatalogCatalog enthalten.

2 Typen können mehrere Assoziationen untereinander haben. Ein ReplicationRequest ist requested-by einem User. Ein Replication ist directed-to einem User (2 Beziehungen im Modell).

Zu viele Assoziationen verschlechtern die Lesbarkeit eines Domain Modells. Manche Assoziationen sind wichtiger als andere.

Normalerweise werden alle UML Diagramme von links oben nach rechts unten gelesen. Die schwarzen Pfeile sind nur da die Leserichtung des Bezeichners der Assoziation zu erleichtern.

animate:
Ahh, das Klassendiagramm...

Ein paar Anmerkungen/Fragen dazu hab ich wieder (dabei gehe ich davon aus, dass das ein UML-Diagramm ist):

Vorsicht bei den 1:1-Beziehungen. So eine Beziehung zwischen User und CodeDokument würde bedeuten, dass ein Dokument von genau einem User erzeugt wurde (was ja auch richtig ist), aber ein User auch nur ein Dokument erzeugen kann (zumindest lese ich das so). 1:1-Beziehungen kommen vergleichsweise selten vor, ich würde alle nochmal prüfen.

Ist Category eine Fachklasse oder ist das "nur" ein Attribut vom Codedokument? Welche Aufgaben hat diese Klasse?

Bei der Beziehung zwischen User und ReplicationRequest bin ich nicht ganz sicher, ob diese zwei Beziehungen nötig/richtig sind.
Dein Modell würde ich so lesen, dass der User Beziehungen zu zwei verschiedenen ReplicationRequest-Objekten hat. In meinen Augen ist aber das Objekt, das er erzeugt und das, das er zurückbekommt, das gleiche, dann wäre in meinen Augen eine "einfache" Beziehung angebracht.
(Ich habe gerade mal in dem Buch nachgeschlagen, das du scheinbar verwendest. Da ist ja dieses Flight-Airport-Beispiel drin. Dieses Beispiel könnte z.B. bedeuten, dass ein Flug-Objekt (LH522) zu einem Airport-Objekt(FFM) fliegt und von einem anderen Airport-Objekt(MUC) aus startet. Und umgekehrt kennt ein Airport-Objekt(FFM) mehrere abgehende Flug-Objekte(BA1,LH2,SA3) und mehere ankommende(RA4,LH5,CP6))

Sehr schön finde ich das "Listen-Pattern" bei RRequest und RRequestItem und bei den anderen beiden Stellen (zumindest im Moment ;-)


Viel Spaß noch beim Modellieren.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete