Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino
Projekt: P2P Java Gui Plattform für LoNo Funktionen
Axel_Janssen:
Hi,
ich labere zuviel rum ;D
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:
--- Zitat von: Axel_Janssen am 17.04.03 - 13:38:47 ---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.
--- Ende Zitat ---
Axel_Janssen:
Hi
--- Zitat von: potsmoker am 06.12.03 - 11:40:26 ---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?
--- Ende Zitat ---
ja.
--- Zitat von: potsmoker am 06.12.03 - 11:40:26 ---Zum Thema OO-SW-Entwicklungsprozess und Lotus Notes: Inwiefern ist das ein Problem bei deinem Projekt?
--- Ende Zitat ---
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.
--- Zitat von: potsmoker am 06.12.03 - 11:40:26 ---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).
--- Ende Zitat ---
Ich möchte die Aufgabe einfach halten. Deshalb zunächst eine Datenbasis rein bezogen auf LotusScript.
--- Zitat von: potsmoker am 06.12.03 - 11:40:26 ---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.
--- Ende Zitat ---
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.
--- Zitat von: potsmoker am 06.12.03 - 11:40:26 ---Edit:
Ach übrigens, kannst du dich noch daran erinnern:
--- Zitat von: Axel_Janssen am 17.04.03 - 13:38:47 ---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.
--- Ende Zitat ---
--- Ende Zitat ---
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
Navigation
[0] Themen-Index
[#] Nächste Seite
Zur normalen Ansicht wechseln