Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

Projekt: P2P Java Gui Plattform für LoNo Funktionen

<< < (2/8) > >>

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:

--- Zitat von: Axel_Janssen am 06.12.03 - 10:54:30 ---
Werde noch heute mit der Anforderungsanalyse des Systems beginnen.  

--- Ende Zitat ---

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.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete