Projekt: P2P Java Gui Plattform für LoNo Funktionen

[Axel_Janssen]

Hi,

ich labere zuviel rum  

Deshalb mein Vorschlag hier etwas Praktisches zu machen.
Obwohl ich eigentlich keine Zeit habe.

Also:
TMC & Mitstreiter sammeln zur Zeit LotusScript Funktionen. Ich möchte nun ein hippes Programm dafür basteln, das
a) diese Funktionen in einer xml-Datei speichert.
b) eine SWING-GUI besitzt, welche die Suche nach den Funktionen erleichtert und zwar mittels Baumnavigation und Volltextsuche.
c) Im Persistenz-Layer kann zwischen unterschiedlichen "Datenbanken" gewechselt werden (xml, RDBMS, LotusNotes).
d) P2P Features enthält. Das heisst jeder User kann über die GUI in sein xml-Repository neue Funktionen einstellen, bestehende ändern und im Extremfall löschen. Diese Änderungen können dann zwischen den Beteiligten ausgetauscht werden (quasi eine Replikation zwischen verschiedenen Datenbeständen im Eigenbau).

Die Punkte a) und b) sind relativ Standard, dh nix ist ja wirklich einfach.
c) ist schon mehr eine Herausforderung. Ich kann das durch einen halbautomatisierten Prozess mit Austausch von emails abkürzen. Richtig cool wäre aber wirkliches P2P. Hierzu gibt es Frameworks/APIs + Dokumentation. Nur weiss ich nicht wie kompliziert und stabil das ist.  

Das ganze will ich in einem hier dokumentierten transparenten UML-gestützten (Rational) Unified Process durchführen.
Sinn und Zweck ist, dass ich durch die öffentliche Selbstblamage inkorrekt angewandten UP+UML in genau diesen Punkten besser werde. Dies auch als praktische Umsetzung meiner IBM-UML certi Vorbereitung. Ich merke nämlich durch das Theorie-Lesen, dass ich viel falsch mache und das Gelesene trotzdem immer wieder vergesse.

Ich glaube, dass über intelligente Prozesse Arbeit effizienter werden kann. (Rational) Unified Process lässt sich nur teilweise auf LotusDomino Entwicklung übertragen, eben weil es stark mit Objekt Orientierter Analyse/Design gekoppelt ist. Teile (z.B. Anwendungsfälle) können aber sehr wohl auch in einer reinen Domino Umgebung eingesetzt werden.

Ich werde hier den Fortlauf mit Dokumenten und Source-code posten. Fragen, Kritik, etc. sind herzlich willkommen und es gibt wirklich keine dooven Fragen.
Ich will u.a. auch zeigen, dass Java keine hoffnungsvolle Zukunft hat sondern mehr eine effektive Gegenwart.

Gruß Axel

[Axel_Janssen]

In einer legendären Urzeit lag die Welt noch im Gleichgewicht:
- Programmierer schrieben ihre Treiber selber.
- Anwender wussten bei Projektbeginn, was sie wollten.
- ein Herr Cray sagte so Dinge wie 2 starke Ochsen sind besser als 220 Hühner, um ein Feld zu pflügen.
- Wenn ein Treiber sein Endgerät in attack-mode schaltete hatte der Anwender immer Biberfellmütze und Bärentöter griffbereit in Bürostuhl nähe und wusste sich zu verteidigen.

Danach kam die Verwirrung in die Welt.
- Programmierer schrieben ihren code basierend auf irgendwelchen mehr oder weniger funktionierenden "Plattformen".
- User wurde erst gegen Projektende wirklich klar, was sie wollten.
- Ein Herr Gates behauptete, man könne ein Feld doch besser mit 220 Hühnern als mit 2 Ochsen pflügen und alle glaubten ihm.
Unter diesesn Bedingungen konnte das altbewährte Modell des Projektmanagements (Wasserfallmodell) nicht mehr funktionieren.
Das Wasserfallmodell begreift ein Projekt als linearen Prozess:
Zunächst gibt es eine vollständige Anforderungsanalyse
dann eine vollständiges Design/Planung der Anwendung
dann schrieben die Programmierer die Treiber, sonstigen Dinge und testeten diese code-Einheiten.
dann wurden die Einheiten zu Subsystemen zusammengeschweisst und Subsystemtests durchgeführt.
dann wurde aus den Subsystemen ein Gesamtsystem gebaut, das dann auch getetestet wurde.

Was aber, wenn bei einem solchen Vorgehen beim Systemtest am Ende festgestellt wird, dass der Programmierer seine Plattform doch nicht richtig verstanden hat? oder den Anwender stehen vor dem fertigen System und sie mäkeln, dass sie ja eigentlich was anderes wollten? Es muß dann in das komplexe, fertige System Änderungen eingefügt werden und das ist kompliziert und teuer.

Es geht nicht. Unter diesen Bedingungen braucht man ein anderes Vorgehen. Ganz logisch ist da ein iteratives und inkrementelles Projektmanagement.
Es gibt eine Vorplanung. Danach wird eine Anforderungsanalyse durchgeführt. Diese erhebt aber im Gegensatz zum Wasserfallmodell keinen Anspruch auf Vollständigkeit. Die Programmierer überschätzen sowieso ihre Fähigkeiten sowie die ihrer Plattformen und den Anwendern wird erst langsam im Laufe des Systems klar, was sie eigentlich wollen.

Anstatt alles richtig zu machen, werden besonders risikoreiche Elemente des Systems und die Grundlinien des Systems identifiziert und mit lustigen Diagrammen und Texten designt. Das sieht dann so ähnlich aus wie im Bastellbogen des Yps-Hefts. Es ist nicht nur Text sondern auch bildlich und entspricht so unseren Sehgewohnheiten. Man nennt das Analyse und Design.
 
Ohne das Analyse/Design fertig ist, implementieren (=coden) die Programmierer die als risikoreich identifizierten Teile und die Grundlinien des Systems.

Die Anwender können dieses unfertige Ursystem dann testen. Anstatt feature-Listen zu lesen, spielen sie ein bischen mit dem unfertigen Computer-Programm rum. Sie sehen dann, wo sie von den arroganten Schlippsträgern und chaotischen Programmierern falsch verstanden wurden. Dies gibt ihnen die Möglichkeit ihre Anforderungen so formulieren, dass auch diese Idioten offensichtliche Dinge erkennen.

Aus den gewonnenen Erfahrungen können dann in der nächsten Iteration die Anforderungen, die Analyse, die Implementierung (=coding) verfeinert werden. Es gibt dann wieder Akzeptanztests usw.

So. Das sieht jetzt wie ein Kreis aus. Das geht aber auch nicht. Schliesslich sind wir in der Wirtschaft und nicht bei einem Seminar zu süd/ostasiatischer Religionsphilosophie. Irgendwie muss es ja nach vorne gehen und das tut es auch. Der Wasserfallprozess ist eine Linie. Das hier ist eine Spirale, die sich nach oben in ihrem Radius immer mehr verjüngt.
Die Iterationen laufen in größeren Zeiteinheiten (Phasen genannt), in denen sich dem seine Aufgabe erfüllenden Gesamtsystem angenähert wird.
In der Konzeptualisierungsphase dominiert die Anforderungsanalyse. Trotzdem findet in diesen anfänglichen Iterationen schon ein bischen Analyse/Design und sogar Implementierung statt. Und zwar zielgerichtet auf den Aufbaus von durch Anwender testbare Grundlinien des Systems sowie besonders risikoreiche Aspekte.
Danach folgt die Entwurfsphase. Es dominiert Analyse und Design sowie eine Ausgestaltung der Anforderungsanalyse. Das Grundliniensystem wird immer umfangreicher und es werden Lösungen für die risikoreichen Aspekte gefunden (wenn nicht kann man das Projekt frühzeitig abbrechen).
In der nächsten Phase, Konstruktion genannt, ist die Anforderungsanalyse bereits ziemlich stabil. Für Analyse und Design sind auch nur noch Verfeinerungen notwendeig. Es dominiert die Implementierung (=coding) sowie ständige Tests der Teile und die Gesamtheit des Systems.
In der abschliessenden Übergangs-Phase nehmen die Tests und die Verteilung der Software die meiste Zeit in Anspruch.

Für Anforderungsanalyse sowie für Analyse und Design stellt der (Rational) Unified Prozess verschiedene textliche und graphische Formate zur Verfügung. Diese dienen den Team-Mitgliedern als Kommunikationsmittel. Einige dieser Formate entstammen der Unified Modelling Language (UML). Andere nicht.

Werde noch heute mit der Anforderungsanalyse des Systems beginnen.  

[Axel_Janssen]

Ich habe schon eine Weile dieses iterative Vorgehen im Kopf. Die Gefahr am Anfang ist, dass man das als Entschuldigung dafür nimmt, Dinge nicht zu Ende zu machen. Also Funktionen programmieren und sich dann mit Halbheiten zufriedengeben. Man kann das ja in der nächsten Iteration machen.
Da ist die Gefahr groß, dass man den Überblick verliert. Die Selbstdisziplin Gedankenansätze zu Komponenten, Klassen, Subsysteme, etc. auch durchzuprogrammieren halte ich inzwischen für absolut wichtig.

[animate]

Wichtig dabei ist (für mich zumindest), dass du dir für jede Iteration konkrete Ziele und einen Zeitraum zum Erreichen der Ziele setzt.
Aber das is eh klar, oder?

Zum Thema OO-SW-Entwicklungsprozess und Lotus Notes: Inwiefern ist das ein Problem bei deinem Projekt? Wenn ich das richtig verstanden habe, willst du ein Tool entwickeln, das die Verwaltung von Code-Schnipseln unterstützt. Für die Umsetzung hast du bereits Java gewählt. Was ich vermute ist, dass das Tool eine Schnittstelle für andere Anwendungen bietet, um auf die vorhandenen Code-Schnipsel zuzugreifen (ich denke, du willst die Code-Schnipsel nicht auf LS beschränken, dadurch wird das Tool vielleicht auch für andere Anwendungen interessant).
Dann ist die einzige Stelle, wo LotusNotes auftaucht, der Zugriff auf die Schnipsel über die Schnittstelle deines Tools. Und schwups hast du kein Lotus Notes mehr in deinen Systemgrenzen, das dir bei  OOA(da weniger weils ja technologieneutral ist)/OOD (da schon mehr) Schwierigkeiten bereitet.


Edit:
Ach übrigens, kannst du dich noch daran erinnern:

Beispielprojekt:
- Code Schnippsel, die bei der täglichen Arbeit mit Notes benötigt werden, werden kategorisiert in einer RDBMS wie z.B. my-sql abgelegt (später kann dann auf Lotus-Domino als Daten-Layer gewechselt werden).
z.B. Cat.LotusScript-->Cat.String-Handling-->String gemäss eines Trennzeichens in ein Array aus Strings konvertieren
z.B. Cat.LotusScript-->Cat.View-Handling--> Ein View-Objekt besorgen und durch die Elemente iterieren.
etc.

Aus einer einfachen Java-Swing-Gui kann durch die Kategorieren explorer-mässig navigiert werden. Hat man das entsprechende code-snippet gefunden, wird es per Knopf-Druck in die Zwischenablage kopiert und kann über Str-V oder sonstwie in den Domino-Designer kopiert.      

[Axel_Janssen]

Hi

Wichtig dabei ist (für mich zumindest), dass du dir für jede Iteration konkrete Ziele und einen Zeitraum zum Erreichen der Ziele setzt.
Aber das is eh klar, oder?

ja.  

Zum Thema OO-SW-Entwicklungsprozess und Lotus Notes: Inwiefern ist das ein Problem bei deinem Projekt?

Es geht mir zunächst einmal darum einen möglichst reinen Prozess durchzuführen. Ich bezweifele gar nicht, dass man dieses Projekt schnell mit LotusNotes durchprogrammmieren könnte. Dies bietet sich nur als ein einfaches Beispielaufgabe an.
 

Wenn ich das richtig verstanden habe, willst du ein Tool entwickeln, das die Verwaltung von Code-Schnipseln unterstützt. Für die Umsetzung hast du bereits Java gewählt. Was ich vermute ist, dass das Tool eine Schnittstelle für andere Anwendungen bietet, um auf die vorhandenen Code-Schnipsel zuzugreifen (ich denke, du willst die Code-Schnipsel nicht auf LS beschränken, dadurch wird das Tool vielleicht auch für andere Anwendungen interessant).

Ich möchte die Aufgabe einfach halten. Deshalb zunächst eine Datenbasis rein bezogen auf LotusScript.

Dann ist die einzige Stelle, wo LotusNotes auftaucht, der Zugriff auf die Schnipsel über die Schnittstelle deines Tools. Und schwups hast du kein Lotus Notes mehr in deinen Systemgrenzen, das dir bei  OOA(da weniger weils ja technologieneutral ist)/OOD (da schon mehr) Schwierigkeiten bereitet.

Bisher taucht LotusNotes rein als Datenbank vor. Neben xml und rdbms. Beide sind auch nicht objektorientiert. Aber die Datenbank ist innerhalb der Systemgrenzen. Systzemgrenzen ist ein gutes Stichwort zum Übergang auf die Use Cases (Anwendungsfälle), wo es ua darum geht die Systemgrenzen auszuloten. Der Prozess ist für Java ausführlich dokumkentiert (was mir die Arbeit extrem erleichtert). Diskussion inwieweit Teile für LotusNotes anwendbar sind, fände ich interessant.

Edit:
Ach übrigens, kannst du dich noch daran erinnern:

Beispielprojekt:
- Code Schnippsel, die bei der täglichen Arbeit mit Notes benötigt werden, werden kategorisiert in einer RDBMS wie z.B. my-sql abgelegt (später kann dann auf Lotus-Domino als Daten-Layer gewechselt werden).
z.B. Cat.LotusScript-->Cat.String-Handling-->String gemäss eines Trennzeichens in ein Array aus Strings konvertieren
z.B. Cat.LotusScript-->Cat.View-Handling--> Ein View-Objekt besorgen und durch die Elemente iterieren.
etc.

Aus einer einfachen Java-Swing-Gui kann durch die Kategorieren explorer-mässig navigiert werden. Hat man das entsprechende code-snippet gefunden, wird es per Knopf-Druck in die Zwischenablage kopiert und kann über Str-V oder sonstwie in den Domino-Designer kopiert.      

ja. Der einzige Unterschied zu jetzt ist, dass ich xml und nicht mySql als Hauptdatenbank verwende und die Datenbasis zunächst auf LotusScript beschränke. Eine Erweiterung wäre ohne weiteres später machbar.

Gruß Axel

[Semeaphoros]

Oh ja, wie weit lässt sich das auf LND übertragen, diese Fragestellung wäre gewiss interessant. Da gibt es ein riesiges Loch, und da IBM die LND-Gemeinde ja ganz gerne ein wenig in diese Richtung bewegen möchte, bestünde da eigentlich Handlungsbedarf, der von IBM selber bisher kaum an die Hand genommen wurde.  Darüber hinaus würden OOA/OOD/OOP ja eigentlich Mittel in die Hand geben, die durchaus den Entwicklungsprozess ganz allgemein stärker stabilisieren könnte und und LotusScript hat ja durchaus Elemente davon implementiert, die darauf warten, genutzt zu werden. Genau das war das Thema meiner Vorrtäge anfangs Jahr in Orlando und Düsseldorf und mein Schluss aus den Reaktionen der Leute: das Bewusstsein fehlt, die Vorgehensweisen sind nicht bekannt, den Leuten fehlt ganz einfach die notwendige Arbeitstechnik, kein Wunder, dass sich die LND-Welt nur widerwillig in eine OO-dominierte Welt migririeren lassen will. Dass Schnittstellen beispielsweise zu UML fehlen, das alleine ist der Grund nicht, denn selbst die bescheidenenen vorhandenen Mittel würden schon enorme Vorteile bringen, wenn man sie nutzen würde.

In dem Sinne, wenn da am Schluss eine "Portierung der Erkenntnisse" auf LND herauskommt, wäre das sehr wertvoll. Würde ich glattweg als Vortragsthema für 2005 wählen.

[Axel_Janssen]

Werde noch heute mit der Anforderungsanalyse des Systems beginnen.  

Ich und meine Versprechungen  
Werde dies und den Tomcat Thread auf jeden Fall später aufgreifen. Das kann morgen sein, nächstes Wochenende, spätestens aber nach dem 20.12.. Das ist schon ziemlich anstrengend und ich hab auch gegenüber meinem Bröttchengeber eine gewisse Verpflichtung fit zu den Projekten zu pilgern, von denen 2 abgeschlossen werden und 1 an mich übergeben. Das gleiche gilt btw. für den Tomcat-Thread. Hab heute abend mit Andreas Schmidt telefoniert und der meinte es würde eine neue offizielle Domino-Schulungsunterlage "Domino und Tomcat" oder so herauskommen. Den muss ich also sowieso betreuen.

Ansonsten freue ich mich über die rege Beteiligung.

@all: Es soll keiner abgeschreckt werden. Was folgt, muss nicht unbedingt in allen Details verstanden werden, um den weiteren Fortlauf des Threads zu verfolgen.

@Jens da bin ich wieder ziemlich de acuerdo mit dir. Mich würde Unterlagen zu den Vorträgen interessieren, falls das möglich ist.
Letztlich kann OOA/D/P unter dem Aspekt einer ingenieursmässigeren Herangehensweise an IT-Projekte gesehen werden. Und angesichts der realen kunden und consultingseitigen Frustration über mehr oder minder gescheiterte Projekte, ist es wirklich an der Zeit darüber ernsthaft nachzudenken.
Ganz doll "hacken" zu können kann es imnsho auf die Dauer nicht sein, wenn man sich nicht durch irgendwelche Prozesse selbst managed/schützt.

In Java gibt es die geschilderte Ablehnung nicht, da sich die Sprache ja explizit als OO verkauft.
 
Was meinst du mit Schnittstellen zu UML?
Ich würde sagen die Mehrheit der Java Programmierer benutzt z.Zt. die jetzt vorhandenen reverse-engineering UML Tools wie Rational Rose, Rational XDE, Togethersoft, Poseidon nicht und verfolgt mehr einen Papier oder MS-Visio mit Zusatz-stencils Ansatz (u.a. ich). Dh ich versuche immer mal wieder mich mit den Tools anzufreunden, hab aber bisher immer entnervt aufgegeben. Mir persönlich macht es auch mehr Spaß zusammen mit 3 Leuten Diagramme auf grosse Papierbögen zu malen.  
netter Artikel: http://www.javaworld.com/javaworld/jw-01-2002/jw-0111-ootools.html

Bin kein OO-Weltmeister, aber auch nicht wirklich OO-naiv. Ich versuche hier in einem relativ reinen Prozess eine Art an (Rational) Unified Process angelehntes OO-Projekt durchzuführen. Dies ist in verschiedenen Büchern hinreichend beschrieben. Wir können dann schauen, wie sich das auf Notes übertragen lässt. In POJO (Plain Old Java Objects) dürfte es wesentlich einfacher sein. EJBs sind aber z.B. auch nicht besonders OO, wenn man genau drüber nachdenkt.
 
Ich packe also das OO in einen Prozess und greife auf Standards wie UML und Design Patterns zurück.

Es ist auch irgendwie ein hermetisches Thema. Entweder man macht es oder man macht es nicht. Es ist auch ein längerer Prozess, sich da einzugewöhnen und zuerst versteht man nur Bahnhof (mir gings so). Viele Leute haben auch falsche Vorstellungen. Die glauben z.B., es ginge um den Aufbau von langen erbenden Klassenhierarchien mit extends, dabei wird genau das als explizitest schlechte Idee angesehen.
In Java_Land steht auch nicht alles zum besten. Zum Bleistift beschreibt dieser Artikel super-typische Fehler, wie man pseudo-OO schreibt (und diese Fehler mache ich: http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?).

Gruß Axel  

[Semeaphoros]

Ah, das sind mal wirklich gute Artikel, die Du da zitierst. Und danke für diesen Update über die verschiedenen Tools, ich selber habe damit gar keine Erfahrung, aber nach den Vorträgen wurde ich des öfteren mal danach gefragt, so schien mir das ein Bedürfnis zu sein. Dieser Artikel erklärt aber sehr wohl, warum das nicht tut. Natürlich wollen die Leute, wenn man ihnen den OOP-Floh aufsetzt, gleich wissen, ob man mit diesen Tools dann auch arbeiten kann, aber da Notes nun mal eine weitgehend geschlossene Umgebung bietet, ist das natürlich nicht so "out of the Box" möglich, offenbar eigentlich auch nicht notwendig -- sehr gut zu wissen.

Der Mann sagt ja kurz zusammengefasst: statt zu theoretisieren krempelt doch einfach mal die Aermel hoch und fangt an zu arbeiten, aber vergesst dabei nicht das Denken einzuschalten. Seine Beispiele erinnern mich an ein Erlebnis vor rund 10 Jahren: gerade eben ist Turbo-Pascal mit OO versehen worden. Ich hatte mal zuerst selber meine eigenen Probleme, dieses "neue" Modell zu verstehen. Als ich dann das Wesentliche begriffen hatte, bekam ein Mitarbeiter ein internes Projekt zugesteckt mit der Aufgabe, das OO-mässig zu realisieren, sprich ein Objekt aus der Aufgabe (wenn ich mich richtig erinnere, ein Objekt zum Manipulieren von INI-Dateien, also ein wirklich schönes Projekt für OO). Was kam heraus? Ein einziges Objekt, bestehend aus einem Konstruktor (weil der obligatorisch ist) einem Destruktor (weil auch der obligatorisch ist) und einer einzigen Methode ... nennen wir sie mal DoIt. Das Hauptprogramm bestand aus Instantiieren des Objektes, Aufruf von DoIt und Dereferenzieren des Objektes. Die Methode DoIt war ellenlang und prozess-orientiert die Lösung der Aufgabe (oder wäre das geworden, wenn ich da nicht auf halbem Weg Stopp gesagt hätte und kurz nochmal das Prinzip von OO erklärt hätte, schliesslich wollten wir das Ding haben, um es in andere Programme einbauen zu können). Die Geschichte mit den Gettern und Settern im Artikel sind auf anderer Ebene genau dasselbe Phänomen ....

Ich selbst hab mit den verschiedenen Tools bisher nichts zu tun gehabt. Ich bin aus dem OO wieder ausgestiegen, als sie modern wurden. Da kam ich aus dem OO-Umfeld, eben Delphi (logisch, wenn man vorher mit TurboPascal gearbeitet hatte) und bin dann in die LoNoDo Welt eingetaucht. Da erging es mir wie offenbar den meisten: Aha, es gibt Objekte - interessant. Dann hat man sich die Beispiele zu Herzen geführt, und die sind nun mal allesamt prozessorientiert in einem eigentlich OO-basierenden Umfeld. Ergebnis: PO-Code in den vom System vorgegebenen Ereignissen und Methoden der System-Objekte: Man schreibt einfach seinenen "traditionellen" Code in den gegebenen QueryOpen und PostClose oder was immer.

Mir gabs den Kick, als ich die Komplexität erreicht hatte, die beim PO-Ansatz zum Kopieren von Code führt und dadurch bei Aenderungen eine Kaskade von Veränderungen herbeiführt. Garantiert vergisst man von 5 Stellen, die angepasst werden müssen 2 und hat riesige Zeitverluste, um die Fehler zu finden. Das Umschreiben einer Applikation unter Ausnutzung von Custom-Classes, also eigenen Objekten, war eine Fleissaufgabe, hat die Realisationszeit einer neuen Version um rund 30% verlängert, eine Zeitinvestition, die  ich unterdessen schon längstens wieder reingeholt habe: das Schreiben der Datenkonversion, die beim Update auf die neue Version erforderlich war, hat dann nur noch 50% der sonst üblichen Zeit gebraucht, also bereits bei der Migration konnte ich einen Teil der Zeitninvestiion bereits wieder "kapitalisieren". Das ist nur ach so typisch ....... so ähnlich wie Du ja Deine eigene Entwicklung auch erzählst.


Meine Vorträge findest Du hier: http://www.ligonet.ch

Gruss
Jens

[Axel_Janssen]

Hi,

werd mir mal die Vorträge anschauen:

zu Tools: Das ist natürlich verlockend. Wenn die Tools wirklich funktionieren erzeugen sie aus UML-Modellen code. Den code kann man dann verfeinern und daraus wieder UML-Modelle erzeugen (etwa zu Beginn der nächsten Iteration im Projekt).
Die Probleme sind:
- UML-Modelle sind Mittel zur Kommunikation. Wenn man sie für die Kommunikation mit Entwicklern benutzt, brauchen sie einen wesentlich geringeren Grad an Exaktheit als wenn man sie zur Kommunikation mit einer Maschine benutzt, die daraus code generiert. Dieser höhere Grad an Exaktheit ist natürlich ein Problem gerade für Neueninsteiger. Es ist auch fraglich, ob das bei wirklich komplexen real world Sachen so einfach funktioniert. Der neue in diesem Jahr verabschiedete UML2.0 Standard fokussierte sich hauptsächlich darauf, diese exakten Bestandteile der UML weiter auszubauen.

- Rational Rose bestand aus vielen einzelnen Tools und das zu beherrschen, ist alles andere als trivial. Bereits vor dem Kauf durch IBM begann Rational die Tools als plug-ins für WSAD und MS-Visual Studio zu entwickeln (Rational XDE). Das hat dann eine gemeinsame Oberfläche. Wirklich trivial ist das aber auch nicht zu bedienen. Ich habe es, muß aber irgendwann mal mehr Zeit haben, um mich da wirklich einzuarbeiten.
Die openSource Tools sind noch schwerer zu bedienen. Relativ beliebt ist das Produkt Poseidon der Hamburger Firma Gentleware. Ist kleiner als Rational zeugs. Hab ich viel mit rumgespielt. Für unser Webservices Projekt hab ich es vorgeschlagen, die anderen wollten aber nicht. Ich hab auch schon von Leuten gelesen, bei denen irgendwann in der 6. Programmwoche die Daten des sorgsam erstellten UML-Modells korrupt waren und nicht mehr von Poseidon gelesen werden konnten. Und so was finde ich wirklich abschreckend.

zu pseudo-OO code schreiben:
OO ist ja an sich kein Vorteil, sondern es eröffnet nur Möglichkeiten besser managebaren code zu schreiben.
Deshalb ist auch ein guter OO-Prozess so wichtig. Und dies ist mir in aller Deutlichkeit erst in den letzten Wochen klargeworden. Prozesse wie RUP sind eine Arbeitsanleitung, die einen dazu bringen sollen, die guten Sachen von OO auch wirklich auszunutzen.
RUP an sich ist ein schwergewichtiger Prozess mit vielen Dokumenten. Gängige Praxis vieler moderner OO-Lehrbücher ist es, sich auf die wichtigsten Elemente von RUP konzentrieren. Der Prozess wird so leichtgewichtig. So will ich das hier auch halten.

Gruß Axel

[Semeaphoros]

Danke für diese Beschreibung, grundsätzlich sehe ich das auch so, mangels Erfahrung mit den Tools wusste ich natürlich nicht wirklich, was ich jeweils dazu hätte sagen sollen. Mit Deinen Angaben habe ich jetzt aber die Grundlage für eine gute Antwort.

Stimmt, OO ist nicht an sich gut, sondern ein Hilfsmittel, das richtig genutzt Nutzen bringt und eben auch schadet, wenn es falsch eingesetzt wird. Theoretisch müsste man ja nicht einmal eine OO-Sprache zur Verfügung haben, um den eigenen Code nach OO zu erstellen, es wird nur ein bisschen tricky.

Die Sache mit UML hatte ich, als sie aufgekommen war, auch so aufgefasst und war dann plötzlich sehr überrascht (da ich es ja dann nicht mehr so genau beobachtete), dass UML plötzlich zur Generierung verwendet werden sollte. Bin jetzt richtig gespannt, wie das hier bei Dir weitergeht und wie wir das dann auf die LoNoDo Umgebung umsetzen können.

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

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. 

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

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. 

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. 
 

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]

klar liest das jemand.

danke.

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.

Streber.
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?

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

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

[animate]

Was würdest du statt xml-Datei verwenden???
Datei? Vielleicht besser. Oder was anderes?

mir würde in diesem Fall schon reichen, dass eine Liste aller Datensätze erstellt wird.
Wie das Teil mal aussieht ist im Moment nicht relevant.

Mir ist beim Durchlesen des Replizieren-Use Cases noch was aufgefallen: nämlich ein weiteres Beispiel dafür, dass du die UseCases viel zu detailliert beschreibst. In meinen Augen ist das Ziel von Use Cases nicht, z.B. eine Replikation in all ihren Schritten detailliert zu beschreiben (mit Formaten, Speicherorten, Kommunikationsmechanismen, etc.). Ich denke, sie sollten abstrakter beschrieben werden, um z.B. einen Überblick zu bekommen, welche Stakeholder beteiligt sind und was da mal ganz grob ablaufen wird.
Wie die Replikation genau abläuft, das kannst du dann z.B. in einem Aktivitätsdiagramm modellieren; eine genaue Beschreibung des Ablaufs gehört IMHO aber nicht in die Anforderungen an dieses System.

[Axel_Janssen]

Hallo Potsmoker,

Auf jeden Fall. D.h. ein Aktivitätsdiagramm ist das bessere Format.

Ich würde aber diesen Use Case schon in der Inception-Phase genauer spezifizieren (besser mit Aktivitätsdiagramm als mit Use Case).
Der Grund für die frühe Spezifizierung sehe ich darin, dass dies der sowohl programmatisch und v.a. organisatorisch der komplexeste Use Case ist. Hier ist das Risiko am größten, dass der Budget-Verantwortliche nicht mit diesem Vorgehen einverstanden ist. Deshalb neige ich hier dazu, früh für klare Verhältnisse zu sorgen.

Aktivitätsdiagramme sind
- an sich nicht objektorientiert.
- eignen sich sehr gut dazu, Workflows darzustellen
Deshalb stellen sie ein sinnvolles Modellierungs-Werkzeug für Notes-Projekte dar. Teilzweck dieser Veranstaltung besteht ja darin herauszufinden, wo UML für Lotus Notes gut genutzt werden kann.

Zu allgemein bei der Spezifizierung zu bleiben, halte ich übrigens aus meiner Erfahrung für keine gute Idee. Vor allem in Organisationen mit einer strengen Trennung zwischen Projekt-Management und Coding dürften zu wolkige Spezifikationen dazu führen, dass dem Programmierer zuviel Verantwortlichkeit/Arbeit übertragen wird. Ich arbeite zum Glück nicht in einer solchen Organisation.

some work for a lazy friday afternoon.
Werd mal den Jakobs Krönung stock der hiesigen Kiosk-Szene abchecken und meld mich dann wieder...

Gruß Axel

[Axel_Janssen]

Hier ist das Aktivitäts-Diagramm für den Anwendungsfall "Pull Replizierung initiieren".


Die schwarzen Kreise am Start und Ende symbolisieren den Anfang und das Ende der Aktivität. Die Kästchen mit den runden Ecken sind Aktivitäten. Die Pfeile dazwischen Transitionen zwischen den Aktivitäten.  
Die einzelnen Aktivitäten sind auf "Spalten" aufgeteilt mit einem "Spaltentiteln" (z.B. "Replication Requester System". Der Fachmann spricht hier von Verantwortlichkeitsbereichen (swimlanes). Durch sie ist eine Zuordnung von einer Aktivität zu einem Akteur möglich.

Ein Aktivitätsdiagramm beschreibt einen Fluss von sequentiell aufeinander folgenden Aktivitäten. Es existiert auch eine Syntax für Verzweigungen (if-then) und Aufspaltung (für nebenläufige parallel in verschiedenen Threads ablaufende Aktivitäten). Beides wird aber in diesem Diagramm nicht benötigt.
Diese Abfolge von Aktivitätszuständen hat nix mit OO zu tun. Der Diagrammtyp hat sich aber für die folgenden Aufgaben bewährt:
- Analyse eines Anwendungsfalls
- Verstehen eines Workflows/Geschäftsprozesses.
- Beschreiben eines komplizierten sequentiellen Algorithmus
- Umgang mit Anwendungen mit mehreren Threads.  

Die Kästchen mit den Eselsohren sind sogenannte UML-Notes. Das sind sowas wie Kommentare. Die UML-Notes können in verschiedenen UML Diagrammtypen benutzt werden.

Was oben ein bischen untergegangen ist: Bei den << >> wie in <<uses>>  handelt es sich um sogenannte Stereotypen. Mit ihnen kann die semantische Bedeutung von UML Elementen erweitert, d.h. genauer spezialisiert werden. Der Use Case "Code-Dokument erstellen" steht in einer Beziehung zu dem Use Case "Kategorie erstellen" .<<benutzt>> zeigt an, dass diese Beziehung eine "benutzt"-Beziehung und keine "erbt-von" Beziehung handelt.

Inzwischen dürfte klar sein, dass die UML ein Bündel an verschiedenen Diagramm-Typen für unterschiedliche Aufgabenstellungen für ein Softwareprojekt enthält. Es gibt in UML 1.4 ungefähr 8 bis 10 verschiedene Diagrammtypen. Man kann wirklich nicht sagen, dass 1 Diagrammtyp "wichtiger" ist als ein anderer.  
 

[Semeaphoros]

Hab mir den ganzen Thread jetzt noch einmal in aller Ruhe angeschaut und auf mich wirken lassen. Und dann ein wenig zurück überlegt. Interessant ist ja schon, dass ich diese Vorgehensweise schon immer praktiziert habe, natürlich ohne die unterdessen erfolgte Formalisierung, der Weg war hingegen in etwa derjenige, der jetzt durch (R)UP ganz offensichtlich in ein formales Gerüst gegossen wurde.

Als Vorbereitung auf die Verbindung mit LotusNotes: Im Zusammenhang mit meinen Vorträgen über OOP und Prototyping (das gehört hier auch mit hinein, man will ja den Anwender in die Entwicklung mit einbeziehen) bin ich natürlich mit verschiedenen Leuten ins Gespräch gekommen.

Erstens: zu OOP: Offensichtlich ist für viele ND-Entwickler, auch wenn sie intensiv mit LS arbeiten und dabei eigentlich Objekte perfekt benutzen, OO ein absolut fremd(artig)er Begriff. Ja, man interessiert sich dafür, wagt aber den Schritt nicht zu machen, in diese Welt einzusteigen. Ok, LS macht es einem ja nicht leicht, da die Unterstützung für eigenes OOP zwar vorhanden, aber nicht gerade ideal ist. Sprich, der Hauptteil der LoNo Entwicklung wird nach wie vor prozessorientiert durchgeführt, man arrangiert sich irgendwie mit dem OO-Framework und dem Event-Modell, das zugrunde liegt, ohne es aber eigentlich zu verstehen. Von verschiedenen Leuten wurde ich sehr lobend dafür angesprochen, das Thema aufgegriffen zu haben. Schaut man die Literatur an, so stellt man auch rasch fest, dass es für die Basics, die für den "Umsteiger" so wichtig sind, so gut wie keine Literatur gibt.

Zweitens, Prototyping: Ich hab mal in der Runde der Teilnehmer in Dortmund gefragt, wie ihre Erfahrungen und Erwartungen sind: Nur gerade 2 der Teilnehmer haben es überhaupt je versucht, Prototyping zu verwenden. Natürlich waren die Zuhörer dort motiviert, sonst wären sie ja nicht in den Vortrag gekommen, es zeigte sich aber deutlich, dass man zwar ganz gerne "neues" machen möchte, gleichzeitig spürte man aber auch die Angst heraus, mit dem Endanwender schon während der Entwicklung zusammen zu arbeiten. Natürlich gibt es auch auf der Anwenderseite Probleme: das setzt natürlich voraus, dass der Benutzer eben auch Zeit aufwendet schon während der Entwicklung. Und die Leute dazu zu motivieren, ist nicht einfach, geht aber definitiv nicht, wenn die Entwicklerseite nicht von der Wirksamkeit überzeugt ist. Danach habe ich mich nicht mehr gewundert, dass es fast keine Literatur zum Thema gibt, obwohl man doch schon bald seit Jahrzehnten von Prototyping spricht, und in anderen Branchen ist das Verfahren ja schon lange absoluter Alltag.

Fazit: Es geht nicht nur darum, neue Verfahren auszuhecken und umzusetzen, man darf nicht vergessen, die Menschen mitzunehmen. Schliesslich gilt das auch für die Softwareentwicklung selber: Wenn wir die Anwender nicht mitnehmen, mit einbeziehen, dann funktioniert der Prozess nicht (und das gilt jetzt eigentlich ganz allgemein und sagt auch gleich aus, warum das Wasserfall-Model so leicht zu langen Gesichtern führt ....).

Hatte gerade mit jemandem von Lotus-Education einen kurzen Mailwechsel kurz vor Weihnachten und werde in dem Sinne in Orlando weiter diskutieren: Das ist bei der gegenwärtigen IBM-Strategie eindeutig ein Problem, will man die Leute, die heute mit LoNo entwickeln, in die "neuen Welten" mirgrieren, muss man ihnen genau diese Zusammenhänge nahebringen. Das geschieht aber nicht, wenn man nicht genau diesen Leuten spezielle Brücken zur Verfügung stellt in Form von Aus- und Weiterbildung spezifisch auf das Problem des "Paradigmenwechsels" von Prozess-O zu OO und alles was damit zusammenhängt. Ich denke mal, das Bewusstsein dafür ist noch nicht vorhanden.

[Axel_Janssen]

Use Cases fokussieren sich hauptsächlich auf funktionale Anforderungen an das System. Daneben existieren die sogenannten nicht-funktionalen Anforderungen.
Allgemein spricht man von FURPS+ Requirements.
- Functionality
- Usability
- Reliability
- Performance
- Supportability
- Implementations-Beschränkungen, Komponenten, Interfaces, Domain Rules, Legal Issues

Die meisten dieser Anforderungen sollten laut (R)UP in einem speziellen Dokument gesammelt werden, dem sogenannten Supplementary Specification Document.  Viele der nicht funktionalen Anforderungen sind Gegenstand der Architektur-Analyse. Mehr dazu später.

Ich übernehme das Template von Larman für das Supplementary Specification Document.

+ Functionality
(gemeinsam für viele Use Cases)
Logging und Error Handling
Alle Fehler werden in ein Log geschrieben. Ausserdem erhält der Anwender eine Nachricht in Form einer Messagebox.

- Sicherheit
Ist hier nicht so wichtig

+ Usability
Das User Interface soll möglichst ähnlich wie für die Anwender vertraute Windows-Anwendungen aussehen.

Schnelligkeit, Einfachheit und Fehlerfreiheit sind wichtig, damit die Anwendung benuttz wird.  
 
+Reliability
Außer beim halbautomatisierten Replikations-Prozess handelt es sich bei der Anwendung um eine Standalone-Anwendung. Ausfälle des Netzwerk fallen erst mal aus. Ausfälle von externen Komponenten oder Systemen (RDBMS, Lotus Notes, korrupte xml Datei, Indexierungsservice) sollen dem Anwender in Form einer Messagebox in transparenter Form mitgeteilt werden. Ausserdem werden sie in das log geschrieben.

+Performance
Performance ist sehr wichtig für die Akzeptanz der Anwendung. Um die Responsivität der GUI zu maximieren, soll Multithreading benutzt werden. Die GUI soll nie länger als 0.5 Sekunden blockiert sein.  

+ Supportability
- Adaptability
Als Datenbank soll zunächst eine xml-Datei genommen werden.
Der Database Access Layer wird so designt, dass die xml-Datei einfach durch Lotus Notes oder eine Relationale Datenbank ersetzt werden kann.
Die Anwendung soll mehrsprachlich sein.
- Configurability
Die Wahl der Datenbank (und der spätere Wechsel) soll über eine Konfígurationsdatei (ohne Programmierung) möglich sein.
Die GUI soll ohne Programmierung neue Sprachen unterstützen.

Implementation Constraints
Das Management board hat sich mit einstimmiger Mehrheit für Java als Programmierplatform entschieden.
Grund dafür ist die Einfachheit der Programmierung.

Gekaufte Komponenten
- Lotus Notes
- evtl db2

freie Open Source Komponenten
Open Source ist oft eine gute Idee (es gibt Ausnahmen). Es sollen reife und häufig verwendete Open Source Komponenten eingesetzt werden.
Kandidaten sind:
- Java Swing
- Log4u
- Look and Feel von Carsten Jentzsch (damit Swing nach Windows und nicht wie eine Milka-Kuh aussieht).
- Forms Layout Manager von Carsten Jentzsch (weil das sehr vielversprechend aussieht und ich dem Mann vertraue. Ausser denke ich darüber nach, einen Bericht über das Forms-Layout für den Javaranch Newsletter zu schreiben).
- Für xml entweder DOM oder JDOM. JDOM ist möglicherweise einfacher.
- vermutlich Dinge aus dem utils Package von apache.jakarta
- als Haupt-Entwicklungs-RDBMS MySQL.  

Interfaces- Hardware
PC (inklusive Laptop).

Legal Issues
sauber bleiben und kein Scheiss bauen.

Information in Domain of Interest
...