Größere Notes-Anwendung planen?

[Simon Dotschuweit]

Hallo, auch auf die Gefahr mich jetzt als anfänger zu outen , ich würde nur gerne mal wissen,
wie ihr so designtechnisch vorgeht, wenn ihr ein größeres Projekt planen müsst.

Ich hab jetzt die Aufgabe, mit Hilfe der Featurelist(Pflichtenheft vom Kunden) innerhalb
einer Woche die Planung durchzuführen, so dass nächste WE die Implementierung
beginnen kann.

Vieleicht noch kurz was zum Projekt, es geht um ein Bewertungstool
für firmeninterne Schulungen mit diversen Statistiken und Reports mit einem Userpeak
von ca. 1000, achja und sie soll auch noch lokal replizierbar sein.

Da ich mich für einen OO-Ansatz entschieden habe, wollte ich folgendermaßen vorgehen:

1. Use Cases + Diagramm unter Berücksichtigung des Sicherheitskonzepts definieren
2. UML-Klassendiagram auf Basis des Use Case-Diagrams erstellen
3. Alle Views und Forms (mit Klassenbezug) entwerfen und die Felder definieren
4. Methoden der Klassen aufführlicher definieren(also was sie genau machen sollen und wie)
5. Eventuelle Agenten definieren.

Ist das eurer Meinung nach eine sinnvoller Designprozess(auch im Hinblick auf die Reihenfolge)?
Oder habt ihr vieleicht noch weitere Idee oder vieleicht auch wehemente Einsprüche ?
Ich bin für jedes konstruktive Feedback dankbar, vielen Dank schon mal im voraus!

[Marinero Atlántico]

Im Grunde finde ich es gut über use cases zu gehen.
Meiner Ansicht nach sind weder Notes-Forms noch Notes-Views Objekte im Sinne von Smalltalk/C++/Java Objekten --> vor dem Hintergrund dieser Sprachen wurde UML entwickelt, bzw. weiterentwickelt. So dass es da evtl. einen missmatch gibt.
Denke bitte auch an nicht-funktionale Requirements.

Ich würd mit der OOA Definition nicht zu weit ins Detail gehen. Gerade als Anfänger: Wenn du beim proggen merkst, dass du dich verplant hast, mußt du dann deine dolle OOAnalyse umschreiben und das macht irgendwann überhaupt keinen Spaß mehr.

Ausserdem halte ich kleinere Projekte einen iterativen Prozeß für sinnvoller. So wie du das schilderst, ist das kein großes Projekt. Großes Projekt ist für mich etwas mit >10 Mannjahre. Auch von der Aufgabe her, ist das kein großes Projekt.
Werd aber nicht zu iterativ. Schliesse Sachen eindeutig ab. Ich bin derzeit ein bischen unter Feuer, weil ich in letzter Zeit ein bischen in meine schlechte Eigenschaft der 80% Lösungen zurückgefallen bin und die Leute haben Recht.

Was heisst Klassenbezug? Du willst in LotusScript Klassen programmieren oder du siehst die Forms and Views als Klassen an?

Letztlich ist UML ein Hilfsmittel, dass sehr unterschiedlich eingesetzt wird. Model Driven Architecture Leute sehen es als eine Art Programmiersprache an und mehr Agile geprägte Leute predigen die Anschaffung von Whiteboards und adHoc Modellierung zur Kommunikation von Ideen.

Es ist aber sehr gut, dass du dir über Dokumentation Gedanken machst. Es ist komplex und es gibt keine festen Regeln. Fang also nicht irgendwann darüber zu jammern an: "Das geht nicht in Notes". In Java geht es nämlich eigentlich auch nicht (meine Meinung. Kann mißverstanden werden. Ich bin UML-User).

Schalte deinen kritischen gesunden Menschenverstand ein.

Axel

[jr]

Hallo Simon,

prinzipiell sieht das sehr gut aus. Wenn Du das tatsächlich von Anfang bis Ende so durchziehen kannst, ziehe ich meinen Hut. Ich mache seit über 10 Jahren Projekte mit Lotus Notes (und davor weitere 10 Jahre mit andern Progrmmiersprachen)  und habe bisher noch nie Use Cases oder ein UML-Diagramm erstellen müssen (das habe ich zwar auf der Uni gelernt, hab's aber schnell wieder vergessen). Ich glaube nicht, dass sich das später irgend jemand noch einmal ansieht. Vielleicht noch die Datenbank in BNF beschreiben und die Korrektheit beweisen...

Im Ernst: Ich spreche da wirklich nur für mich.
Mein Problem ist, dass ich in meiner gesamten Eintwicklerzeit noch nie ein Projekt hatte, das tatsächlich so durchgeführt wurde wie es ursprünglich spezifiziert war. Immer gab es während der Entwicklung Erweiterungen, Veränderungen oder einfach nur neue Erkenntnisse. Vielleicht bin ich da auch einfach zu doof dazu und bei den anderen klappt das immer.

Meine Vorgehensweise war bisher immer der Bottom-Up-Ansatz. Also mit kleinen Moduln anfangen und diese sändig ergänzen und erweitern, bis das gewünschte Ziel erreicht wurde. Wenn mehrer Leute an einem Projekt arbeiten kannst Du so auch relativ einfach die Funktionalitäten aufteilen. Hierzu müssen lediglich die Schnittstellen sauber definiert werden.

Bei Klassen ist es genauso. Zuerst die Schnittstellen definieren, dann die internen Funktionen codieren.

Und noch ein Tipp aus meiner Erfahrung: Kommentiere so viel wie Du kannst im Code selbst, denn das ist wichtiger als alles andere. Nach spätestens 6 Wochen, wo Du den Code nicht mehr gesehen hast, weißt Du nicht mehr, was Du gemacht hast und musst Dich erst wieder durch den Code durcharbeiten. UML und andere Dokumentationshilfsmittel nützen da nur bedingt.

Ich weiß nicht, ob ich Dir jetzt damit ein bisschen geholfen habe, aber so habe ich es in den letzten Jahren kennengelernt. "Divide and conquer" ist mein Ansatz und ich bin bisher sehr gut damit gefahren.

Gruß,

Joachim

[Simon Dotschuweit]

Vielen Dank schon mal für die schnellen Antworten 

...
Was heisst Klassenbezug? Du willst in LotusScript Klassen programmieren oder du siehst die Forms and Views als Klassen an?
...

Damit meinte ich, dass wenn die Objekte und ihre Beziehung untereinander feststeht, ich alle für alle Objekte (Dokumente), die der Nutzer selbst anlegen und sehen darf sozusagen als User Interface die Forms und Views auf Basis der Klassen definiere.

[Marinero Atlántico]

Also mir hilft sowohl UML als auch Use Cases schon.
Klar wurde das von den Konzept-Consultants dieser Welt überhyped.
Careful
Diesmal mit der Extrapolation von eigenen Erfahrungen als Naturgesetze.
Wobei ich das mehr zur Skizzierung von Ideen benutze, wie ich ein Problem angehe.

Darüber hinaus erlebe ich gerade, wie Leute für nicht kleine Bestandteile einer großen Anwendung mit einem stark Model Driven Architecture geprägten Ansatz mit Code Generierung aus Modellen Erfolg haben. Nicht in Notes.
 
Nur wurde das alles von den Konzept Consultings dieser Welt deutlich überhyped und von den happy naives from lala-Land gerne gegessen. Gerade davon kann man aber nicht auf eine grundsätzliche Irrelevanz in der Praxis schliessen.

Als Anfänger würde ich aber auch mit einfacheren Ansätzen anfangen und keine übertriebene Erwartungen an UML haben.

Gruß Axel

[jr]

Hallo,

es ist sehr schwer, auf dieses Thema allgemeine Antworten zu geben. Ich denke, dass hier jeder seinen eigenen Weg gehen muss. Und was für den einen das Alleinseligmachende ist, kann für den anderen als absolut nutzlos angesehen werden.

Wenn man mit einer Methode klar kommt und damit glücklich ist, dann sollte man auch dabei bleiben, wenn man es kann. Oftmals sitzt da aber noch der Chef dazwischen, der hier genaue Vorgaben verlangt. Deshalb ist es sicher nicht verkehrt, wenn man auch die anderen Möglichkeiten kennt.

Wie oben geschrieben mache ich seit etwa 20 Jahren Projektarbeit und habe da verschiedene Ansätze kennen gelernt. Als Bereichsleiter Lotus Notes einer großen Discount-Kette habe ich dann damals ganz genaue Anforderungen an meine Mitarbeiter gehabt. Als ich dann das Unternehmen verlassen habe, hat mein Nachfolger einen komplett anderen Ansatz verfolgt und heute hat das mit dem was ich damals gemacht habe nicht mehr viel gemeinsam. Die Mitarbeiter sind aber die gleichen geblieben und die mussten sich dann halt entsprechend umgewöhnen.

Seit vier Jahren bin ich jetzt selbständig und habe dadurch den Vorteil, dass ich mir meine Regeln selbst auferlegen kann. Dass aber auch dies nicht das Optimum darstellt habe ich dann gemerkt, als ich einen weiteren Entwickler eingestellt habe, der dann plötzlich wieder ganz andere Ideen hatte.

Um das Ganze noch einmal auf den Punkt zu bringen: Man sollte über die verschieden Projektentwicklungsansätze bescheid wissen und für sich den Optimalen heraussuchen. Mit der Zeit wird man seinen eigenen Stil bekommen. Tipps von Kollegen sind da sicher hilfreich, aber eben immer nur Tipps.

Gruß,

Joachim

[Marinero Atlántico]

Ich finde das grundsätzlich von Leuten, die OO mehr von aussen betrachten viel zu viel Wert auf die OO-Analyse gelegt wird und zu wenig auf OO-Development.
Und weil sie dazu tendieren zu glauben, man müßte da grundsätzlich irgendwelche gewaltigen Domain Models modellieren, versuchen sie es nicht.
Man kann sowieso nur Klassen modellieren, wenn einem wirklich klar ist, wie man das programmiert.

[Semeaphoros]

Das stimmt, ist eigentlich nicht nur in OO so. Erst wenn man eine Ahnung von den angestrebten "Mechanismen" hat, ist man überhaupt in der Lage, etwas so zu modellieren, dass es dann am Schluss auch Chancen hat, zu funktionieren.

[Simon Dotschuweit]

Vielen Dank erstmal für die vielen Antworten!

Ich bin jetzt gerade beim Klassendiagramm und hätte da gleich mal eine Frage, macht es Sinn, alle Felder aus dem Dokument in der Klasse mit Setter und Getter Methoden abzubilden?

@Semeaphoros: Ich hab mal in deine beiden Beispiel DBs geschaut und da machst du da nicht so, kann daraus entnehmen, dass es unsinnig wäre und man lieber direkt auf die items im dokument zugreift?

[animate]

bist du in Analyse oder Design?

Im Analysediagramm würde ich alle Felder als Attribute der Klasse modellieren.

Im Design kann ich das nicht so pauschal sagen. Spontan würde ich eine Aggregation von der Klasse zur NotesDocument-Klasse vorschlagen. Die NotesDocument-Klasse bietet schon Methoden an, mit denen du Feldwerte auslesen und setzen kannst.

Ferner würde ich eine Klasse/ein Modul erstellen, das die Feldnamen als Konstanten hält. Dann kannst du in der Anwendung über NotesDocument-Obkjekt und Konstanten auf die Feldwerte zugreifen.

Wie gesagt, in meinen Augen kann das Design unterschiedlich aussehen, je nach Bedarf.

[Semeaphoros]

Dem von Thomas gesagtem ist nur wenig hinzuzufügen. Für jedes Feld eine eigene Setter oder Getter Methode zu machen, halte ich für sinnlos. Die Feldnamen als Konstanten in ein eigenes Modul zu hinterlegen ist ein sehr guter Vorschlag und kann gleichzeitig auch als Bestandteil der Doku dienen.

[Marinero Atlántico]

Um Himmels willen nein. Ich würd das auch nicht in der Designphase in das Diagramm packen.
Solche Variablen ändern sich schnell mal, stärker zu Beginn des Projekts.
Wenn du die getter und setter ins Diagramm schreibst, mußt du an 6 Stellen ändern:
Property in Code, setter in Code, getter in code, Property in Modell, setter in Modell, getter in Modell.
Am Rande: In Eclipse drücke ich einmal das Renaming Refactoring und Eclipse kümmter sich um das umbenennen der getter/setter, sowie aller existierenden Referenzen.

Die zusätzliche Information, die die explizit vorhandenen getter und setter liefern, tendiert gegen Null und es macht das Modell unübersichtlicher. Selbst wenn - was selten der Fall ist - der getter oder setter nicht einfach gettet oder settet sondern vor- oder nachbearbeitet, gehört diese Information allenfalls als Kommentar zu der Variable und nicht als expliziten getter oder setter im Modell.

Axel

[Simon Dotschuweit]

@Semeaphoros:

Ich bin gerade deine beiden Beispiele(Adressbuch und ServiceDB) am studieren und bin nicht ganz sicher, welche ich als Vorlage für mein Design verwenden soll. Bitte versteh mich jetzt nicht falsch,
ich will deinen Quellcode nicht kopieren, will mich aber an deinem Ansatz orientieren, da ich zwar viel
Erfahrung in OO, aber nicht in Notes habe. Wenn ich das richtig sehe, dann hast du beim Adressbuch
auf N zu N Relationen gesetzt und bei der ServiceDB auf Main-Responsedocs.

Für meinen Ansatz müsste ich beides kombinieren, ich brauch also beide Relationen, irgentwie hab ich aber den Eindruck bekommen, dass z.B. das BaseDocument beim Adressbuch ausgereifter ist (z.B. die Absicherung gegen Replikationskonflikte über eigene Docids), oder enthält es einfach nur mehr Funktionalität für die N-N Relationen? Lässt sich eine Kombination überhaupt ohne weiteres umsetzen? Oder beissen sich da bestimmte Funktionalitäten?

Thx

[Semeaphoros]

Das hast Du richtig beobachtet .... 

Wenn Du N zu N Relationen brauchts, orientiere Dich an der AdressDB. Deren Architektur hat zwar einen älteren Ansatz, ist in manchen Teilen technisch weniger ausgereift als die Service-Applikation, daran wurde aber auch wesentlich länger gearbeitet, ist also - wie Du richtig bemerkts - ausgereifter. Kombinieren könnte man die Ansätze eigentlich schon, macht aber irgendwie keinen Sinn, denn wenn man 1 zu N und N zu N braucht, dann ist 1 zu N eine Untermenge von N zu N. Was ich allerdings heute anders machen würde, das wäre eine Trennung von UI und Backendklassen, das ist bei der gegenwärtigen Lösung nicht gegeben.

[Simon Dotschuweit]

Ok, dass heißt also wenn ich 1 zu N und N zu N Relationen brauche, macht es Sinn, sich an der AdressDB zu orientieren und für die 1 zu N auf die Responsearchitektur zu verzichten. Denn mir ist ein durchgehender Ansatz sowieso lieber. (Außer dem ist die AdressDB besser dokumentiert  )

Für die Unterteilung nach Front und Backend schiel ich dann mal ab und zu auf die ServiceDB, da werd ich dich auch bestimmt noch viel fragen

[Semeaphoros]

Genau so würde ich das auch sagen. 

[animate]

Ich würde nicht soweit gehen, pauschal zu sagen, dass es nicht sinnvoll ist, sowohl die Notes-Funktionalität für Parent-Child-Beziehungen, als auch eine eigene Verknüpfungslogik zu nutzen.

Was spricht dagegen, etwas zu benutzen, was schon da ist? Und dessen Vorteile zu Nutzen? - mir fällt gerade nur der eine ein, dass ich die Antworthierarchie in Ansichten darstellen kann, naja, und dass es halt schon funktioniert.

Ein "durchgehender Ansatz" ist in meinen Augen auch, für alles, was wie eine Parent-Child Beziehung aussieht, die Notes-Funktionalität zu nutzen und für alles, was Notes nicht kann, das eigene Zeug.

[Semeaphoros]

Grundsätzlich richtig, Thomas, und wäre auch meine Antwort, nur, die Randbedingungen sind hier anders. Auch die N zu N Verbindung, die aus meinem Beispiel stammt, funktioniert und bringt ähnliche Funktionalität wie die eingebaute. Der Vergleich ist hier nicht allgemeiner Natur - wie Du ihn machst - sondern der Vergleich zweier realer Implementationen untereinander und die Frage, ob man das so mischen soll oder nicht. Kennt man die Innereien der beiden Beispiele, komme ich zu meinem Schluss, dass es in dieser Gegenüberstellung keinen Sinn macht, nicht jedoch, dass dieser Schluss generell so zu fällen ist.

[Simon Dotschuweit]

@Semeaphoros:

Also ich arbeite mich gerade durch das BaseDocument und du verwendest doch das feld ViewMainEntry für die Kategorisierung in der View, oder? Also sowohl Hauptdokument als auch die Childdocs haben den gleichen ViewMainEntry.

Aber wozu braucht man dann diese Felder: ViewSecondEntry und ViewEntryExtension?

Ich hab mir einfach mal alle Dokumente in der Adressdb angeschaut und da ist immer nur der MainEntry gesetzt, die beiden anderen scheinen nicht genutzt zu werden, oder täusch ich mich da?

[Semeaphoros]

Kann sein, dass die Einträge im Beispiel nicht genutzt werden. Suche die Einträge doch mal über die Design-Uebersicht, dann hast Du die Antwort schnell. Die Sache stammt natürlich aus einer grösseren Applikation und wurde auf das Wesentliche reduziert, da sind Nebeneffekte denkbar. Mit dem ViewSecondEntry ist es möglich, das Dokument unter einem alternativen Begriff in der kategorisierten Ansicht anzuzeigen, bei der ViewEntryExtension müsste ich jetzt selber nachsehen, wo da der Zweck genau ist, ob das die beiden Kategorie-Einträge modifiziert oder ob das dazu dient, Inhaltsinformationen in den Ansichten anzuzeigen ..... Wenn Dus nicht findest, sags nochmal, dann schau ich rasch nach.