Domino 9 und frühere Versionen > ND6: Entwicklung

Zusammenspiel von UML und Lotus Notes - Transformation von UML nach Notes

<< < (2/3) > >>

MadMetzger:
Es geht mir ja auch nicht um eine 1:1-Transformation, aber mein Ziel ist es halt, mich an UML-Diagrammen zu orientieren, und versuchen irgendwie eine Interpretation nach Notes zu finden... vielleicht kommen mir auch Ideen, wenn sich mein Modell mehr konkretisiert hat. Ich habe zumindest eine ganz grobe Idee atm, muss aber noch mehr analysieren vorher... Problem ist auch, dass ich das für eine Projektarbeit machen will, und da sollte man ja Modelle zumindest ansatzweise auch mal graphisch skizzieren. Ein Freund von zu starken Formalismen bin ich auch nicht wirklich, das kann unter Umständen mehr hindern als helfen...

MadMetzger:
Also, ich bin jetzt ein ganzes Stück weiter gekommen. Die Schwierigkeiten waren bis jetzt noch nicht sehr groß. Einige meiner Klassen konnte ich 1:1 nach Script übertragen, jedoch habe ich bei diesem Konstrukt hier so meine Bedenken, ob das so funktioniert.
In Java würde man ja den Zustand als Interface implementieren, was aber Lotus Script nicht kann. Also habe ich mir eine Klasse Zustand definiert, die die Methoden definiert. Danach habe ich dann die Klassen Neu etc. von der Klasse Zustand erben lassen und die Methoden überschrieben. Mein Problem ist eigentlich, ob ich jetzt Funktionen mit einem Parameter vom Typ Zustand auch Argumente vom Typ der Unterklassen akzeptieren. Oder wie würdet ihr dieses Konstrukt umsetzen?

MadMetzger:
Vielleicht noch mal ein paar Worte von mir zu meinem Ansatz der UML-Transformation nach Notes, da zumindest Einzelne ihr Interesse an diesem Thema bekundet haben und ich persönlich es für nicht uninteressant halte.

Mein primärer Ansatz war es mich an Model-View-Controller zu richten. Im Prinzip ist mir das durch folgenden Ansatz auch gelungen:

* View wird repräsentiert durch alle Darstellungskomponenten, insbes. die Masken
* Den "Controller" bilden alle Agenten, welche aus den Viewkomponenten heraus aufgerufen werden
* Das Model ließ sich dann in LS-Klassen implementieren
* Als zusätzliche Komponente gibt es die Persistenzschicht, ebenfalls als Klasse in LS implementiert, die die Daten aus den Dokumenten in Objekte lädt und umgekehrt.
Das angehängte Klassendiagramm soll dieses Vorgehen durch das Zusammenfassen der Klassen zu den 4 Packages verdeutlichen.

flaite:
Was habe ich von einem Interface, das nur 1 implementierende Klasse kennt ? -> PersistenzManager.

 
Halten sich reale Entwickler auch an dein Meta-Modell?
Wenn sie es nicht tun, wäre es überhaupt wünschenswert/effizient, dass sie es täten ?
Fragen über Fragen...

MadMetzger:
@Axel: Natürlich ist in solch einem Fall ein Interface nicht unbedingt sinnvoll, jedoch ist diese Geschichte ja eine Projektarbeit für mein Studium und in dem Fall soll dieses Interface zeigen, dass es theoretisch mit dem Interface möglich ist, dieses Modell von der Datenbank abzutrennen. Natürlich stecken dahinter noch weiterführende Probleme, aber eben diese müsste man dann gesondert untersuchen.

Die Fragen die du aufwirfst, sind natürlich berechtigt, jedoch wollte ich damit auch mein Versprechen einhalten, noch einmal darüber zu berichten.

Auf jeden Fall ist diese Modellierung teilweise mit mehr Entwicklungsarbeit verbunden, als andere mögliche Ansätze. Aber ich finde diese Modellierung gar nicht so schlecht und sie spiegelt IMHO auch relativ gut OO-Ansätze und MVC wieder.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete