Domino 9 und frühere Versionen > ND6: Entwicklung

Größere Notes-Anwendung planen?

(1/7) > >>

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


--- Zitat von: Marinero Atlántico am 20.06.05 - 19:17:02 ---...
Was heisst Klassenbezug? Du willst in LotusScript Klassen programmieren oder du siehst die Forms and Views als Klassen an?
...

--- Ende Zitat ---

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

Navigation

[0] Themen-Index

[#] Nächste Seite