Das Notes Forum
Sonstiges => Offtopic => Thema gestartet von: -Michael- am 16.04.04 - 20:48:00
-
Hi zusammen,
u.a. habe ich mir jetzt folgenden Thread angesehen:
OO Entwicklung mit LotusScript - Frage externer Editor / Eclipse? (http://www.atnotes.de/index.php?board=3;action=display;threadid=15263;start=21)
Und bin gewillt, dazuzulernen :-)
Ich muss dazu sagen, dass ich mich mit L'Script noch nicht allzu lange beschäftige. Ich habe aber mittlerweile den Komfort entdeckt, Functions und Subs in ScriptLibraries auszugliedern.
Nun aber die Frage: Wo fängt OO an?
Also welche weiteren Möglichkeiten habe ich?
Ist eine Script-Ausgliederung in Functions/Subs ein erster Schritt in die Notes-OO oder habe ich damit schon alles ausgeschöpft?
Mir erscheint ehrlich gesagt OO ein wenig als Hype-Begriff im ND-Bereich. Oder ist eine Ausgliederung in Functions/Subs OO pur?
Ich glaube mir fehlt einfach eine Definition, was OO überhaupt ist (im Notes/Domino - Umfeld).
Aber ich lerne da wie schon gesagt gerne dazu.
Michael
-
Ich bin zusammen mit Thomas Völk in den Startlöchern, um versuchsweise einen OOP-Online-Kurs für die Verwendung von eigenen Objekten in LotusScript hier im Forum anzubieten. Momentan sind wir noch in der Planung und wissen noch nicht ganz genau, wie wir das mit der Forums-Software realisieren sollen. Wir sind derzeit mit Arne im Kontakt, um abzuklären, welche Möglichkeiten zur Organisation eines solchen Kurses uns zur Verfügung stellen, habe also noch ein wenig Geduld, auch wenn ich im Moment noch nicht voraussagen kann, wann wir damit starten können.
-
Well, danke schonmal für die Infos, Semaphoros.
Was mich trotzdem sehr konkret interessieren würde (weil ja OO in aller Munde ist):
- fahre ich mit der Ausgliederung von Subs/Functions gegen die OO-Welle oder ist das ein (massiver) Bestandteil von OO? Gibt es - wenn man von OO im ND - Bereich spricht - völlig andere Konzepte?
- Was heißt OO im Notes/Domino - Umfeld überhaupt
(ich spreche jetzt für mich: keine Web-Applikationen, sondern rein Notes-Client-bezogen)
Ich komme mir jedenfalls vor - wenn ich so manche Artikel im www lese - dass ich völlig hinter dem Mond lebe. Daher auch meine Hype-Vermutung und die Frage, was ND tatsächlich bietet im OO-Bereich.
In ungeduldiger Erwartung Eures Online-Kurs :-)
Michael
-
Also ganz kurz:
ND selbst ist OOrientiert, Du verwendest die Notes-Objekte wie NotesDocument ja dauernd.
Wie Du in dem zitierten Thread ja schon lesen konntest, ist allerdings die Untestützung für eigene Objekte in LotusScript eher rudimentär und nicht besonders attraktiv implementiert.
Trotzdem ergeben sich (manchmal gewaltige) Vorteile, wenn man das Wenige, was man zur Verfügung hat auch einsetzt - allerdings muss man es richtig machen, das ist ein Knackpunkt, und deswegen wollen wir ja auch den Kurs machen.
Eingesetzt wird die OO-Technik in LS noch viel zu wenig. Gründe dafür gibt es viele: Wenig Beispiele, wenig Literatur.
Dein Weg, Prozeduren in Script-Libs auszulagern, ist einer der Grundgedanken, die in OO aufgenommen wurden (er ist aber älter als OO, als Module kennen wir das schon bald ewig). Wenn ich selbst ein Projekt OO-Basierend in LS realisiere, dann tendiere ich dazu, pro Klasse (Ojekt) eine eigene Bibliothek zu erstellen. Bei normalen Projekten geht das sehr gut und ist hilfreich, bei grossen Projekten stösst das allerdings an Grenzen (Ladezeiten, Uebersichtlichkeit).
Beantwortet Dir die Frage noch nicht ganz, aber gibt Dir einen Vorgeschmack auf das Kommende :)
-
Hi, Michi,
OOP ist ein aufwändigerer Weg der Programmgestaltung, der sich aber massiv auszahlen kann. Es kommt darauf an, wo und wann man seinen Code so aufbaut - und wo es sich eben nicht lohnt.
Die gesamte Klassenbibliothek von Notes-LotusScript ist bereits objekt-orientiert, letztlich arbeitest Du also schon mit Objekten.
Eigene Routinen in Subs oder Functions zu verpacken, hat mit OOP nichts zu tun. ScriptLibs sind wiederum nur Sammlungen Deines Codes.
Schau mal in diesen Artikel - ich fand ihn sehr hilfreich:
http://www-10.lotus.com/ldd/today.nsf/lookup/object_oriented_LotusScript (http://www-10.lotus.com/ldd/today.nsf/lookup/object_oriented_LotusScript)
Das wäre mal ein Startpunkt.
HTH,
Bernhard
-
Danke schonmal für Eure Hinweise :-)
Dein Weg, Prozeduren in Script-Libs auszulagern, ist einer der Grundgedanken, die in OO aufgenommen wurden (er ist aber älter als OO, als Module kennen wir das schon bald ewig).
Das dachte ich mir eigentlich schon :-) Der "Trick" bzw. diese Methodik ist ja uralt. Kenne ich noch von meinen alten Amiga-Zeiten, wo ich in C Includes entsprechend 'included' habe, also ausgelagerten, immer wiederverwendbaren Code, dank #include verwendete.
D.h. für mich: Eigentlich ist nicht wirklich was neu, was meine Hype-Theorie bestätigt :-)
OK. Mit Klassen habe ich dabei noch wenig gearbeitet, genervt hat mich dabei nur, dass alles in den Declarations landet und *nicht* sauber strukturiert ist
Trotzdem:
Was kann ich sonst noch tun, um objektorientiert zu programmieren?
Ich bin noch immer nicht überzeugt, dass OO mit Notes/Domino kein Hype ist :-)
Ciao,
Michael
-
... ich halte OO konkret anwenden für einen längerfristigen Prozess, für den man eine Menge Geduld und Frustrationstoleranz braucht.
Es ist mehr wie eine Reise, wo man eben jeder mal verirrt.
Im englischen Raum erscheinen ein paar scheinbar interessante Bücher, die sich explizit an Einsteiger wenden.
z.B. http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=49&t=000520
Ich persönlich finde, man lernt OO am besten mit einer Voll-OO Sprache wie Java, dot.NET-Sprachen oder (besser nicht, weil zu schwierig) C++.
Das ist aber in diesem Forum eine Minderheitenmeinung.
Axel
-
Michael:
OO ist kein Hype, sondern längerfristig eine Notwendigkeit, denn IBM setzt auf das Pferd von J2EE zum Bleistift ganz direkt auf eine Technologie auf, die ohne OO einfach nicht geht. DotNET tut ähnliches. Auch wenn man bei Sonne nicht so genau weiss, wie lange sie noch zu scheinen vermag, ist das dort entstandene Java und was drumherum noch so gebaut wurde, ebenfalls reines OO, sprich, es sind am Horizont nur OO-Frameworks zu erkennen, die unsere Zukunft bestimmen werden.
Solange man OO als Hype sieht, denke ich, ist die Chance, es zu erlernen oder es nützlich anzuwenden nicht sehr gross. OO ist, wie Axel richtig indirekt aussagt, Arbeit und hängt ganz stark davon ab, dass man es von Anfang an richtig anlegt. Ob aufwändiger, wie Bernhard sagt, wage ich etwas zu bezweifeln, denn dann wäre es ja nicht nützlich. Es scheint tatsächlich grob gesehen so, weil sich die Aufwände von der Implementierung hin zur Planung verschieben, und dieser Effekt wird häufig vernachlässigt und schon läuft es schief.
Stimmt natürlich, was Axel sagt, dass das Erlernen von OO mit Java einfacher ist, als mit etwas anderem, da ein Ausbrechen aus OO, wie das in LS nur allzu leicht und verlockend ist, wie man es auch in C++ machen kann (auch wenns dort nicht so naheliegt wie bei LS) einfach nicht möglich ist.
Der Vorteil, sich jetzt mit LS mit OO anzufreunden - trotz der Nachteile, die Du richtig gesehen hast - liegt ganz klar darin, dass man nicht früh genug sich an das völlig andere Paradigma der OOP im Vergleich zu prozessorientiertem Programmieren gewöhnen kann. Und, richtig eingesetzt, nützt das ganze auch etwas (sonst würden wohl deutlich weniger die Nachteile des Designers in Kauf nehmen und trotzdem mit OO-Technologien arbeiten)
-
Sorry, aber vielleicht denke ich zu sehr schwarz/weiss.
Ich persönlich mag es immer direkt. OO ist für mich alles andere als direkt, die bisherigen Umschreibungen machen mir einen sehr schwammigen Eindruck.
Bei meinen C - Includes wusste ich woran ich bin. Genau so weiss ich auch bei den ScriptLibs woran ich bin. Nehme ich ein "Use XYZ" dann gilt diese in der entsprechenden Umgebung.
Daher nach wie vor meine Frage: Was ist sonst noch OO in Script? Ich würde mich über konkrete Beispiele freuen.
@Hernan:Es ist mehr wie eine Reise, wo man eben jeder mal verirrt.
. Sorry, aber das ist für mich alles andere als konkret an.
Hört sich für mich an wie "ach, mit dem Amiga war alles noch schön". Oder "Australien ist auch ein schönes Urlaubsland".
Michael
-
Berichtigung: Mein letztes Posting war nicht auf das von Semaphoros bezogen !!
-
Danke, Semeaphoros, für Deine Worte.
Trotzdem sehe ich noch immer nicht den überhaupt möglichen Einsatz von OO.
Angenommen ich stelle mich heute hin und sage:
"Jawoll, ich will OO-Programmieren".
Was muss ich denn machen, damit ich meine Aussage erfülle?
Auslagerung in Subs/Functions hatten wir ja bereits.
Der Rest ist imho gesunder Menschenverstand. (Nutzung globaler Agenten, evtl. Nutzung Shared Actions - wenn auch damit Probleme zu erwarten sind, Definition globaler Variablen wenn man das braucht, etc.).
Vielleicht bin ich auch schon mittendrin.
Michael
-
Das dachte ich mir eigentlich schon :-) Der "Trick" bzw. diese Methodik ist ja uralt. Kenne ich noch von meinen alten Amiga-Zeiten, wo ich in C Includes entsprechend 'included' habe, also ausgelagerten, immer wiederverwendbaren Code, dank #include verwendete.
Da ist schon ein kleiner Unterschied mit starken Auswirkungen.
Funktionsbibliotheken sind eine Sammlung von Funktionen.
Objekte bestehen aus State und Methoden.
State ist vereinfacht gesprochen sowas wie Variablen.
Funktionen einer Funktionsbibliothek arbeiten über von aussen kommende Variablen (lokale Variablen ist etwas anderes). In Objekten sind die Variablen (state) und die Methoden zusammen.
Eine Funktion kannst du aufrufen, die Funktion errechnet einen Rückgabewert und terminiert.
Objekte hälst du über einen beliebigen Zeitraum im Arbeitsspeicher. Während dieser Zeit kannst du sie immer aufrufen, den state ändern, sie abfragen, etc.
Klassen sind "Förmchen" für Objekte. Ein Objekt kann andere Objekte enthalten. Das sind dann schon Datenstrukturen.
Eigentlich geht es primär um Übersichtlichkeit. Wiederverwendbarkeit ist dann schon die höhere Schule.
Ich empfehle wirklich ein Einsteigerbuch. Kann ich nicht so einfach erklären.
Gruß Axel
-
Eigentlich geht es primär um Übersichtlichkeit.
Axel, ich denke Du bringst es langsam auf den Punkt.
Was sind eigentlich meine Ziele bei einem Code:
- ein Außenstehender soll sich zurecht finden
- ich selbst soll es einfach haben: Änderungen nur an 1 zentralen Stelle
- übersichtlicher, sauber dokumentierter Code
- einheitliche Syntax
etc.
Das alles erscheint mir selbstverständlich. Jeder gute Programmierer wird sich wohl daran halten.
Michael
-
Michael
Nein, Du stehst nicht mittendrin, Dir fehlt effektiv die "grundlegende" Definition, die will ich hier aber nicht in unsauberer Art und Weise geben, genau da soll ja der Kurs einsetzen. OO geht weit über das hinaus, was Du da antönst, auch wenn es solche Ansätze als Grundlage verwendet.
Wenn Du heute sagst, "ich programmiere sofort nur noch OO", dann wirst Du wohl eine Weile lang gar nichts mehr produktiv tun, weil Du das Denken ändern musst. Das ist aber jedem so gegangen, der erfolgreich von PO auf OOP umgestiegen ist, ich inklusive, das ist aber schon mal ungefähr 15 Jahre her (schon allein deswegen kann ich es nicht als Hype sehen, Hypes haben es so in sich, dass sie ziemlich kurzlebig sind).
Der Thread hier driftet in meinen Augen ziemlich ins Abseits, das Problem, das da im Moment auftaucht, wirklich begreifen lässt es sich nur in einer "ganzheitlichen Betrachtung" und die kann eine solche Diskussion hier eindeutig nicht bieten.
-
Was sind eigentlich meine Ziele bei einem Code:
- ein Außenstehender soll sich zurecht finden
- ich selbst soll es einfach haben: Änderungen nur an 1 zentralen Stelle
- übersichtlicher, sauber dokumentierter Code
- einheitliche Syntax
etc.
Das ist alles nicht eigentlich OOP, OOP kann dabei ein Hilfsmittel sein, dafür muss es aber richtig eingesetzt werden. OOP hilft - richtig eingesetzt - genau diese Ziele zu erreichen, OO ist dafür abrer nicht zwingend Voraussetzung und OO hat andere Eigenschaften. OOP falsch eingesetzt bewirkt genau das Gegenteil, nämlich Unübersichtlichkeit, und wer nicht mit einer BlackBox umgehen kann, ist bei OO völlig verloren (so Leute gibts, und die haben es immer schwerer im Leben, die BlackBoxes in unserer Umgebung nehmen rasant zu)
-
Danke Jens.
Durch Deinen Beitrag komme ich wirklich ins Überlegen.
Wir sprechen bei OO wohl wirklich nicht nur von einer Methodik, sondern von einer neuen Art der Programmierung, die man erst mal (kennen)-lernen muss.
Ich frage hier sehr bewusst simpel und einfach. Aber ich habe verstanden.
Mir fehlt der nötige OO-Background, um geziehlt konstruktive Kritik loszulassen. Ich werde mich da entsprechend weiter informieren.
Trotzdem schonmal danke für die interessante Diskussion,
Michael
P.S. tolles Forum, man kann hier fachlich diskutieren, und andere Meinungen werden ernst genommen und nicht einfach abgestempelt :-)
Ich bin ja noch nicht ganz Eurer Meinung, habe aber ein Wissens-Defizit, welches ich durch Bücher aufzuholen versuche im Bereich OO :-) Melde mich auf jeden Fall wieder zu diesem Thema :-)
-
Ich glaube, solch eine Diskussion wie diese hier kann und wird auch den angedachten OOP-Kurs oder -Grundlagenbeitrag stimulieren.
Daher doch noch ein Nachtrag dazu:
Ich bleibe bei meiner Meinung: OOP ist aufwändiger als prozedurale Prgrammierung - man muss sich einfach viel, viel mehr Gedanken machen. Ebenso muss man entscheiden: Wann ist die Aufgabe so klein - oder besser - so strukturiert, dass sie prozedural (zeit-)effektiver gelöst wird.
Einen ganz entscheidenden Beitrag (aus meiner Sicht) hat Axel eben geliefert:
Eine Funktion kannst du aufrufen, die Funktion errechnet einen Rückgabewert und terminiert.
Objekte hälst du über einen beliebigen Zeitraum im Arbeitsspeicher. Während dieser Zeit kannst du sie immer aufrufen, den state ändern, sie abfragen, etc.
Michi, Du arbeitest doch auch mit Objetken wie NotesSession oder NotesDatabase. Die instantiierst Du ein einziges Mal und kannst dann auf ihre Eigenschaften und Methoden immer wieder zugreifen. Stell' Dir vor, Du könntest selber solche Objekte schaffen und dann ebenso mit diesen arbeiten !
Beispiel: Du hast eine QM-Datenbank und dort ein Objekt "QMDocument". Dieses Objekt instantiierst Du einmal (gibst dabei dem Konstruktor die notwendigen Informationen mit wie welches Dokument, Rechte des current users etc.). Ab dann kannst Du auf DEINE definierten Eigenschaften und Methoden simpelst zurückgreifen (und Dein Objekt immer als black box sehen):
Print QMDocument.Status
Call QMDocument.CreateVersionCopy
Set QMDocument.Status = "Approved"
Was hinter diesen Properties und Methods passiert, programmierst Du einmal und brauchst Dir später nie wieder Gedanken darüber zu machen (es sei denn, Du musst Dein Objekt erweitern um Props und Methods). Aber auch das wird Deinen bisherigen Code (ausser dem Objekt selbst) nicht jucken.
Wo immer das hinpasst, ist es ein riesiger Billigmacher. Und - wie es Jens schon sagte - in genau diese Richtung läuft der Hase. Auch LotusScript wird sicherlich in dieser Richtung Erweiterungen erfahren - IBM kommt da gar nicht vorbei (auch wenn genau auf dem Gebiet einiges an Hype dröhnt, und das seit mehr als einem Jahrzehnt mit jeweils unterschiedlichen Marschrichtungen). An OOP geht aber nix vorbei.
Was derzeit das angenehme ist: Man kann im Notes-Umfeld das Thema langsam angehen, tut sich keinen Zwang an und gewöhnt sich dabei an faszinierende Möglichkeiten.
Keine Frage aber auch: In LS v4 ist die OOP-Unterstützung etwas verbesserungsbedürftig (gaaaanz vorsichtig ausgedrückt). Aber es geht und belohnt den Aufwand !
HTH,
Bernhard
-
Der Thread hier driftet in meinen Augen ziemlich ins Abseits, das Problem, das da im Moment auftaucht, wirklich begreifen lässt es sich nur in einer "ganzheitlichen Betrachtung" und die kann eine solche Diskussion hier eindeutig nicht bieten.
Das stimmt.
OO ist schon eine andere Art zu arbeiten und erfordert ein gewisses Mass an fokussierter Beschäftigung.
Sonst besteht die Gefahr, dass unsere Kommunikation so abläuft, dass
- du nur das siehst, was du sehen willst, und mir zustimmst, aber eben Teile nicht wahrnimmst oder
- mich als authistischen, weltfremden Schwätzer wahrnimmst.
Gruß Axel
-
Beide Angaben von Bernhard und Axel sehr nützlich und geben dem Thread hier seine korrekte Bedeutung, danke.
Daher doch noch ein Nachtrag dazu:
Ich bleibe bei meiner Meinung: OOP ist aufwändiger als prozedurale Prgrammierung - man muss sich einfach viel, viel mehr Gedanken machen. Ebenso muss man entscheiden: Wann ist die Aufgabe so klein - oder besser - so strukturiert, dass sie prozedural (zeit-)effektiver gelöst wird.
Bernhard: das stimmt, aber das gehört nicht in die Programmierung sondern ist Architektur und Design, wie gesagt, die Aufwände verlagern sich, in der Summe bleiben sie anfänglich etwa gleich, später reduzieren sie sich im OO-Ansatz gegenüber dem prozeduralen Ansatz ....... sofern richtig eingesetzt, dazu gehört natürlich auch, dass man ein typisch "von Hause aus prozedurales" Problem eben nicht mit OO-Ansätzen löst.
-
Axel, Du denkst aber schon noch an die Basis dieses Threads, oder ? Es geht darum, das jemand wissen möchte, welche OO-Ansätze LotusScript in einer puren Notes-Client-Umgebung hergibt.
Und dort kann man ja zumindest erstmal starten. Und vor allem: Das ist eine absolut stabile Umgebung in diesem Kontext, mit der man zu sicheren Resultaten kommen kann.
Was Michaels Befürchtung hinsichtlich Hype angeht: Man kann OOP auch totdiskutieren und so nie zu Resultaten kommen. Und Theorien auf diesem Gebiet hat es genug gegeben, und genügend Leute Propheten, deren Thesen wenige Jahre später nicht mehr wahr waren.
Bei aller notwendiger Theorie: Auch diese muss sich an der Praxis beweisen. MUSS !
Und Polemik sollten wir gerade in diesem Kontext hier mal 'rauslassen.
Bernhard
-
Jens,
aber das gehört nicht in die Programmierung sondern ist Architektur und Design, wie gesagt, die Aufwände verlagern sich, in der Summe bleiben sie anfänglich etwa gleich, später reduzieren sie sich im OO-Ansatz gegenüber dem prozeduralen Ansatz ....... sofern richtig eingesetzt, dazu gehört natürlich auch, dass man ein typisch "von Hause aus prozedurales" Problem eben nicht mit OO-Ansätzen löst.
Du hast das genau auf eben den Punkt gebracht, den ich wohl nicht richtig formulieren konnte. OOP verlangt mehr "Grips", mehr Gedanken über die Architektur. Es handelt sich auch aus meiner Erfahrung "nur" (!) um eine Verlagerung. Richtig eingesetzt, erspart man sich aber um Grössenordnungen unnötige Aufwände. Und das schon in LS v4 mit seinen beschränkten Möglichkeiten.
Bernhard
-
Genau so ist es, und mehr Grips zu investieren, hat noch nie geschadet :D
Es ist tatsächlich so, dass man Objekte in der Regel nicht einfach aus dem Handgelenk schüttelt. Die zwangsweise bessere Planung führt zu besserem Code (was ja eigentlich eine Binsenwahrheit ist und nicht wirklich OO-spezifisch) und damit zu späterem Profit.
Und genau das ist der springende Punkt: selbst die beschränkten Möglichkeiten von OO in LS genügen, um davon profitieren zu können, nebst der Vorbereitung für die Zukunft, wie Du das weiter oben sehr schön dargestellt hast.
-
Es ist tatsächlich so, dass man Objekte in der Regel nicht einfach aus dem Handgelenk schüttelt.
... deshalb kommt man auch bei OO-Programmierung zu bestimmten Prozessen der Projektdurchführung.
Also mehr Planung. Es gibt da verschiedene Schulen (z.B. RUP oder xTreme Programming).
Man sollte das aber gerade als Anfänger nicht so ernst nehmen. Es gibt verschiedene Arten die konkrete Objektstruktur zu "entdecken".
Man braucht da auch kein Tool für. Ich prduziere zum Beispiel gerade höchst heterodoxes UML mit Bleistift auf Rechenkästchen basierend auf einem noch persönlicheren Prozess und kann kein Radiergummi finden und muss bald wohl einen Kiosk suchen, der sowas hat ::)
buy-a-book
Axel
-
Richtig, es braucht mehr Planung, ein Prozess kann nützlich sein, es muss aber nicht unbedingt ein bestimmter sein. Mit Uebung lässt sich bei kleinen Sachen OOA und OOD durchaus auch im Kopf machen, aber gemacht werden muss es, und den Kopf kann man ganz gut mit Papier, Bleistift, Radiergummi, und wer mag Kaugummi oder Cervisia unterstützen.
-
**************************
Ich kann zu dieser Diskussion leider nicht viel beitragen
und will Sie auch in keine andere Richtung lenken, aber
ich lese Sie mit großem Interesse und die
Fragen von -Michael- hätte ich auch gerne
gestellt, mich aber nie getraut.
Würde mich freuen, wenn dieser Thread noch eine
Weile existiert.
Ciao
Don Pasquale
****************************
-
Wenn dir beim Warten langweilig wird, kannst du ja in der Zwischenzeit hier ein bischen schmökern. ;D
http://c2.com/cgi/wiki?ObjectOrientation
grossartiger Grusel to deepen your angst :o
-
einige kurze und nicht so tiefe Erklärungen und Erzählungen gibts auch bei uns auf der Homepage (link ist unter meinem Avatar). Dort im Menü auf Fachliches klicken und dann auf Objektorientierung. Und dann gibts da noch eine Menüebene drunter, die evtl. ein paar erste Fragen beantwortet.
-
Mit Uebung lässt sich bei kleinen Sachen OOA und OOD durchaus auch im Kopf machen, aber gemacht werden muss es, und den Kopf kann man ganz gut mit Papier, Bleistift, Radiergummi, und wer mag Kaugummi oder Cervisia unterstützen.
Ich stimme damit nicht überein.
An eine Anwendung werden Anforderungen aus der realen Welt gestellt (business cases).
Ein OO-Analyst bildet diese business cases in einem Objektmodell ab.
Mit UML Diagrammen kann man verschiedene Sichten dieses Objektmodells darstellen.
Genau diese Sichten liefern etwas, woran es heute in vielen Unternehmens-ITs mangelt: Eine übersichtliche, menschenlesbare Dokumentation der Anwendungen.
Vielleicht sehe ich das aber auch nur stärker als Problem als andere Kinder, da ich eben oft in Notes Projekte kam, die vor die Wand gelaufen waren und die Java/J2EE Projekte im Team entwickle (so ungewöhnlich auch nicht, d.h. viele von euch werden sich da wiedererkennen). Für beide Aufgaben stellt eine vernünftige Dokumentation einen hohen Wert dar.
Diagramme stellen Information wesentlich übersichtlicher dar als Source code dar. Tool (z.B. Rational Rose) erzeugte Diagramme sind leichter zu lesen als menschenerzeugte (v.a. wenn ich es zeichne). Trotzdem haben diese Tools ein...
<exkurs>
Problem: Die vom OO-Analyst gezeichneten Diagramme stellen Prognosen für eine effiziente programmatische Lösung der business cases dar. Bei der Umsetzung in code kann sich herausstellen, dass es anders als gezeichnet eben besser geht.
Die UML-Sichten müssten also neu gezeichnet werden. Dies läuft auf eine mehrfache Pflege von "source code" hinaus. Eine Lösung aus diesem Dilemma wären roundtrip engineering tools, wo aus Source code UML Modelle generiert werden können. Dies erfordert aber einen hohen UML- und OO-Design-Tool Sachverstand.
</exkurs>
Für einen OO-Anfänger sind solche Tools wie Rational Rose sicher nichts. Ich benutze Rose seit 2 Wochen, aber nur Teile und bislang mehr intuitiv. Hat meine Erwartungen übererfüllt, aber ich beschäftige mich schon länger mit diesem OO/UML Zeugs und ich war skeptisch.
Aber OOD/A im Kopf? Dadurch verliert man dieses wichtige Dokumentations-Feature. Überhaupt... Mein Kopf reicht für meine OO-Aufgabenstellungen nicht aus. Ich bezweifele stark, dass der Kopf von irgendjemand für OO/A Aufgabenstellung, die eine gewisse Trivialitätsschranke überschreiten, ausreicht.
Ich meine: Ein Warenkorb besteht aus einer Menge an zu kaufenden Items. O.k.. Aber jemand einen Vorschlag für die Objektmässige Darstellung des Spielplans der EM 2004 in Portugal. Im Kopf?
Ich nehm dafür lieber Rational Rose.
Gruß Axel
-
Axel: Du hast etwas ganz wichtiges Ueberlesen:
für KLEINE SACHEN
Du redest definitiv nicht von kleinen Sachen, wenn Du von Team(s) redest.
-
für KLEINE SACHEN
Hi,
Das müssen aber schon sehr kleine Sachen sein.
Hier ist eine Sache, die ich neben der Arbeit, mit mir selber ausmache:
Das ist eine statische Klassenstruktur der Objekte des Spielplans wie ich sie für ein Tippspiel benötige. Das Ergebnis von 2 Stunden mässig fokussierter Arbeit (inklusive nachdenken) von 1 tio loco:
(http://www.atnotes.de/attachments/em2004.GIF)
Wenn ich es nicht in Rose (oder mit Papier und Bleistift) persistiert hätte, hätte ich es heute vergessen.
Und das ist bei weitem noch nicht fertig. Im Grunde fehlen da sogar Kommentare (und zwar dringend).
Bevor ich anfange zu coden, brauche ich sowieso ausserdem noch eine dynamisches Modell für bestimmte Anwendungsfälle.
Wenn Leute eine Relationale Datenbank neu planen, malen sie doch auch ein Entity Relationship Model. Warum soll das mit Objekten anders sein ???
Ich bleibe dabei: Gezeichnetes UML ist für reale Welt OO unverzichtbar.
Alles andere ist a-bit-to-rapid-application-development mit den nachteiligen Folgen:
- unzureichende Dokumentation
- oft fällt einem während des Zeichenprozesses ein, wie man es besser machen kann
Axel
-
Es hat auch niemand gesagt, man soll es machen .....