Namenlos

5. Fazit

Sicherlich wird in dieser Darstellung einiges unklar geblieben sein, obwohl es vielleicht grundlegend für SE oder auch Rational Rose ist. Dies liegt zum großen Teil daran, daß die Probleme größerer Softwareprojekte oder auch die Mittel mit denen man versucht dieser Probleme Herr zu werden, sich schlecht nur aus den Erfahrungen anderer (-> Fachliteratur) verstehen lassen, wenn man selber wenig Erfahrung mit Programmentwicklung im großen Stil hat.

So sind Rational Roses Stärken sicherlich in den Mechanismen zu suchen, die die Abstraktion vom Problem auf sehr hoher Ebene suchen. Die sehr nah am wirklichen Objekt liegenden Darstellungen wie etwa Sequence Diagrams können sicherlich dem Programmierer als Anhaltspunkt, mindestens aber als sehr komfortabler Notizzettel dienen, sind aber möglicherweise im Detail genauso kompliziert zu handhaben, wie die letztendliche Programmierung selber.

Hier wären sicherlich auch ein paar Worte zum Round Trip Engineering angebracht. Mit den voreingestellten Parametern ließ sich nur sehr wenig sinnvoller Code generieren. Hier wurden für jede Klasse eine Datei mit einem Klassenrumpf und skelettmäßigen Codefragmenten für jede Methode erzeugt. Jede Klasse erhielt ein vordefiniertes Set an Kon- und Destruktoren, Zuweisungs- und Vergleichsoperationen, obwohl dies sicherlich nicht bei jeder Sinn macht. Ob die relativ undurchschaubaren Optionsrequester, die zur Anpassung jedes einzelnen Klassencodegenerierungsparameter hier mehr Komfort oder Sauberkeit bieten als "Cut & Paste" im Quellcode scheint auf den ersten Blick etwas fraglich.

Nebensächlichkeiten wie die Tatsache, das die erzeugten Quellcodedateien in 8.3-Namenskonventionen gezwungen werden und etwa Zielverzeichnisse in Optionsmenüs als Strings ohne die Hilfe eines entsprechenden "Browsers" (die altbekannte "Durchsuchen"-Funktion) eingegeben werden müssen scheinen gerade im Zeitalter von Windows 9x eher lästig (ohne hier die Bereitstellung entsprechender Standardfunktionen des Sytems als angewandte Objektorientierung all zu positiv herausstellen zu wollen).

Auch wenn dies alles auch mehr oder weniger Äußerlichkeiten sind, wirkt es jedenfalls verwirrend, wenn ein Programm, das beim Erstellen von Qualitäts-software helfen soll (oder dieses überhaupt erst möglich macht, wenn man die Werbung mal (nicht zu) wörtlich nimmt) Bugs aufweist, die sogar einem absoluten Laien in z.B. einem Terminplanerprogramm negativ auffallen würden. So darf man beispielsweise nicht einfach zwischen verschiedenen Notationsdarstellungen wechseln, wenn einem das mit viel Liebe erstellte Layout eines Diagramms sehr ans Herz gewachsen ist, da spätestens nach dem zweiten oder dritten Wechsel (wäre ja zu Vergleichszwecken durchaus denkbar) die Kastensymbole aller Diagramme bis zur Unkenntlichkeit entstellt sind, und sich nur jedes einzeln per Hand wiederherstellen läßt. Hier hilft die Autosize-Funktion auch nur begrenzt. Möglichkeiten wie das Ausblenden von Klassen und das nachträgliche expandieren eines Diagrammes um weitere Klassen sind grundsätzlich sehr gur, es wirft sich nur die Frage auf, wer diese gerade eben bei großen Projekten sinnvollen Optionen jemals anwenden wird, wenn die expandierten Klassen alle auf einen Fleck gehäuft werden, und sich nur wieder jede einzeln per Hand auseinenderziehen läßt, wenn man seine eigene Anordnung der automatischen vorzieht (und das wird man).

Daß sich das alles in einer wohlkonfigurierten Vollversion (zum Referat lag nur die C++-Demoversion 4.0.3 von 1996 vor, die aber bis auf Eischränkungen beim Speichern der Vollversion entsprechen soll) anders darstellt ist durchaus möglich. Allerdings ist es trotzdem ärgerlich, denn wer möchte sich schon bei den genannten Beispielen auf die langwierige Suche nach irgendwelchen Optionen machen, um das eigentlich zu erwartende Verhalten zu erzwingen.

Alle diese Nebesächlichkeiten haben schließlich während der Benutzung für soviel Stirnrunzeln gesorgt, daß sie wohl der Erwähnung Wert waren. Jedoch muß natürlich gesagt werden, daß bei einem so komplexen Programm, wie Rose durchaus eine lange Einarbeitungsphase und Erfahrung mit SE im allgemeinen vorrauszusetzen ist, und dann die gebotenen Möglichkeiten durchaus hilfreich sein werden. Die ist insbesondere wichtig, da die Unified Method/UML noch relativ neu ist, Rose wohl aber das erste Programm sein wird, das alle Aspekte dieses Industriestandards im Bereich OO-CASE-Methoden/Notationen beinhaltet. Außerdem zeigen viele Anwendungsbeispiele aus der Industrie, daß die zugrundeliegenden Methoden und Notationen sicherlich zu den durchdachtesten zählen, die im Gebrauch sind.

(Ach ja, da war noch das Unified Method - Dokument, welches mit Rose (Demoversion) gebundelt war, aber eine andere Notation als die verwendete beschrieb. Es handelte sich um Version 0.8, bestand zum Teil nur aus Überschriften und dürfte heute zwei Jahre alt sein.)

Zurück Index Anhang