OO-Design-Tools am Beispiel von Rational Rose

Rose = UML?

Objektmodellierung beginnt nicht damit, daß man Quellcode eingibt. Diese Weisheit hat sich inzwischen herumgesprochen. Daß es in der Objektmodellierung leistungsfähige Ansätze zu Vorgehensweise und graphischer Darstellung gibt, ist inzwischen ebenso bekannt. Hier hat die Diskussion um die UML als Standardsprache zur Darstellung von Objekt- und Klassenmodellen schon gewirkt.

Wie aber erhält man ein graphisch repräsentiertes Modell, ohne auf CAD- oder Graphikprogramme oder gar auf Stift und Papier zurückgreifen zu müssen?

Ein Tool hierzu ist das Programm Rose der Firma Rational. Wenn Ihnen der Name bekannt vorkommt, weil die Autoren der UML, Grady Booch, James Rumbaugh und Ivar Jacobson in deren Sold stehen, ist das ganz richtig: genau diese Firma ist auch Hersteller des Designwerkzeuges Rose. In der Version 98 liegt nunmehr die erste Version dieses Tools vor, die nach der Standardisierung der UML erscheint und es gilt die Frage zu klären: hat Rational durch die Arbeit der eigenen Leute an der UML einen Vorsprung bei der Toolentwicklung? Immerhin wurde diese Vorstellung mehr oder weniger offen von anderen Herstellern für OO-Werkzeuge geäußert. In diesem Artikel soll geklärt werden, was die Version 98 an Neuerungen bietet und ob Rose ein in der Praxis brauchbares Programm ist, das den Entwicklern von OO-Systemen eine wirkliche Unterstützung bietet.

Der nächste Schritt: Komponentendesign

Die Oberfläche von Rose 98 orientiert sich, wie schon die der Vorgängerversion, an den Funktionalitäten von Windows 95/NT. Wie auch schon die letzte Vorgängerversion ist Rose 98 zunächst für diese Plattform entwickelt worden und wird erst jetzt für Unix portiert. Hier – wie auch in anderen Bereichen – schlägt sich die Partnerschaft mit Microsoft nieder, die Rational für die Entwicklung seiner Tools eingegangen ist. Diese Partnerschaft hat sicherlich auch dazu beigetragen, daß Rational mit Rose nach eigener Aussage Marktführer bei den Tools zur Objektmodellierung ist.

Der Hauptbildschirm von Rational Rose 98

Rose 98 bietet gegenüber der Version 4.0 keinen Quantensprung in der Funktionalität oder der Unterstützung von UML-Spracheigenschaften. Im Vordergrund standen vielmehr zwei Bereiche, in denen Rose überarbeitet wurde: Komponentendesign und Ergänzungen am eigenen Objektmodell. Der Bereich, der in der Bedienung und Funktionalität der Oberfläche die größten Auswirkungen hat, ist die stärkere Unterstützung bei der Entwicklung von Komponenten. Daneben wurde an der Komplettierung des Objektmodells und am Einbau von Features der UML 1.1 in den Funktionsumfang des Programms gearbeitet.

Die Neuerungen

Das Hauptfeature, das in der Version 98 neu hinzugekommen ist, ist die Unterstützung von Modellen, aus denen sich Quellcode für verschiedene Sprachen erzeugen läßt. Ausgangspunkt hierfür ist die „Component View“, in der sich zu jeder im Modell angelegten Komponente festlegen läßt, in welcher Sprache der Code erzeugt werden soll. Eine Komponente ist aus Sicht von Rose dabei eine Datei, die die Implementation von mehreren Klassen aus dem logischen Modell übernimmt. Mit der Bindung der Implementationssprache an diese Komponenten können z.B. einzelne Teile einer Anwendung in C++, andere Teile in Visual Basic oder Java erzeugt werden. Die Codegeneratoren werden von Rose nun als „Add-In“ behandelt, können alsonebeneinander in Rose betrieben werden.

Das Tools-Menü unter Rose mit den Einträgen für die verschiedenen Sprachen.

Die Erzeugung von Code kann für einzelne Komponenten gestartet werden. So können jetzt auch einzelne Teile der Implementation Schritt für Schritt aufgebaut oder modifiziert werden. Das zeitaufwendige Generieren des kompletten Codes für ein Modell, wie es noch unter Rose 4.0 notwendig war, wenn auch nur eine Klasse geändert wurde, entfällt damit.

Auf dem Weg, die Entwicklung von Komponenten besser zu unterstützen werden nun auch die in der UML vorgesehenen Interfaces unterstützt. Interfaces sind eine Art Klasse, in der verschiedene Operationen einer Komponente zu einem Funktionsblock, der von außen angesteuert werden kann, zusammengefaßt werden. Das Symbol dazu ist der sogenannte „Lollipop“. In Rose wird diese Darstellung über einen nun fest definierten Stereotyp „Interface“ unterstützt. Wie schon in der Version 4.0 können für jeden Stereotyp eigene Symbole vergeben werden, allerdings ist dem Entwickler diese Arbeit für den Stereotyp Interface schon abgenommen. Neben der Darstellung als Symbol kann man in Rose Stereotype auch mit dem Namen, eingeschlossen in doppelte spitze Klammern, anzeigen lassen.

Die Interfaces für ein ActiveX-Control

Einen weiteren Schritt in bezug auf die Unterstützung von Komponentenentwicklung stellt der Typelib-Importer dar. Mit Hilfe dieses Tools können auf einem Windows-Rechner vorhandene OLE-Server analysiert und in ein Modell integriert werden. Die Anwendung ist denkbar einfach: die .EXE-, .DLL- oder .TLB-Datei wird per Drag’n-Drop auf die Komponentensicht des Browsers in Rose gezogen.

Drag’n-Drop mit der Typelib zu Data Access Objects

Rose startet automatisch den Typelib-Analyzer, der die Komponente mit allen in der Typelib abgelegten Interfaces in der Komponentensicht erzeugt. Gleichzeitig werden Klassenabbilder der in der ActiveX-Komponente enthaltenen Interfaces in der logischen Sicht angelegt. Zu allen Klassen werden die Attribute und Operationen mit Typdefinition und (bei den Operationen) Argumenten hinzugefügt.

…und das Ergebnis des Imports

Eine Applikation, die – wie heute unter Windows üblich - Gebrauch von verschiedenen ActiveX-Controls macht, kann damit ohne „Löcher“ dokumentiert werden. Mit den über den Typelib-Importer erzeugten Klassen bzw. Interfaces kann direkt weitermodelliert werden, alle Abhängigkeiten der eigenen Klassen von den ActiveX-Komponenten lassen sich lückenlos darstellen.

Leider ist der Analyzer nicht sehr performant. Das Importieren z.B. der .TLB, die für Rose selbst mitgeliefert wird (182KB Größe) dauert auf einem PII 233 rund eine halbe Stunde. Ist eine solche Datei oder ein anderes Modell erst einmal geladen, hält die Verarbeitungsgeschwindigkeit von Rose aber auch auf schwächeren Systemen durchaus mit dem normalen Arbeitstempo mit.

Neben der Orientierung hin zur Komponentenmodellierung gibt es aber noch weitere Neuerungen. Zunächst wäre hier das interne Objektmodell zu nennen. In ihm sind die von Rose selbst verwalteten Klassen für die Zugriff auf eine Modelldatei enthalten. Dieses war in der Version 4.0 zwar schon für die Auswertung des Klassenmodells brauchbar, wichtige Teile des Modells, wie Objekte der Interaktionsdiagramme oder die Diagramme selbst, ließen sich jedoch nicht ansprechen. Inzwischen stehen wirklich alle Modellelemente per Ansteuerung des OLE-Servers im Zugriff, auch die Diagramme selbst, die sich im .WMF-Format exportieren und z.B. in ein Textdokument übernehmen lassen. Daneben gibt es auch eine wesentlich verbesserte Dokumentation des Rose-Klassenmodells, sinnigerweise auch in Form einer Rose-Datei (www.rational.com/products/rose/downloads.html, allerdings nur für Rose-Eigner verfügbar).

Außerdem lassen sich mit Rose 98 Dateien oder URLs zu Dokumentationszwecken an weitere Elemente des Modells anfügen. In Rose 4.0 konnten diese Verweise nur zu Use Cases zugeordnet werden. Rose fungiert dabei als OLE-Client, d.h., die zugeordneten Dokumente oder URLs lassen sich über die damit verbundene Anwendung (z.B. Word) per Doppelklick direkt öffnen. Dieses Feature gibt es nun auch für Packages, Komponenten und Klassen. Damit lassen sich externe Beschreibungen oder Dokumente direkt aus der Arbeit in Rose öffnen, um z.B. bei der Verwendung eines ActiveX-Controls die mitgelieferte Dokumentation zur Verfügung zu haben. Die Angabe einer URL erlaubt auch den Aufbau eines zentralen Repositories für Dokumentation für ein Projekt, auf das dann alle Entwickler unabhängig von den Pfaden der Arbeitsstation Zugriff haben.

Die Packages in Rose 98 haben nun endlich eigene Namespaces. Das heißt, daß Klassennamen nicht mehr für das gesamte Modell einmalig sein müssen. Unter Rose 4.0 war es sehr ärgerlich, wenn mehrere Bearbeiter in ihren Teilprojekten auf die Idee kamen, eine Klasse z.B. „WindowManager“ zu nennen. Rose 4.0 konnte diesen Namenskonflikt nicht auflösen. Unter Rose 98 lassen sich nun die gleichen Klassennamen in verschiedenen Packages verwenden. Rose zeigt dann einen Warnhinweis an, der sich aber abschalten läßt.

Die weiteren Neuerungen spielen sich im Bereich Verbesserung des User-Interfaces und Bugfixing ab. Hier sind Dinge hinzugekommen wie Unterstützung von Farben in den Graphiken, endlich die korrekte Darstellung von abstrakten Klassen in den Diagrammen oder „ Class Name Completion“. Class Name Completion heißt, daß beim Anlegen eines neuen Klassensymbols in einem Diagramm eine Liste aller im System definierten Klassen angezeigt wird. Aus der wird mit Hilfe einer inkrementellen Suche anhand der eingegebenen Buchstaben der Name einer bereits definierten Klasse gesucht. Der gewinnbringende Einsatz dieses auf den ersten Blick sinnvollen Features ist an zwei Bedingungen geknüpft: erstens sollte das Modell nicht allzuviele Klassen beinhalten, da die Liste schnell unübersichtlich wird und zweitens sollte sich das Modell in einer gewissen Reife befinden, damit nicht bei jeder neu anzulegenden Klasse diese Liste erscheint. Zum Glück läßt sich dieses Feature in den Optionen unter „Diagrams“ abschalten. Nachdem die meisten Klassen definiert wurden, kann diese Option wieder eingeschaltet werden und erleichtert dann die Arbeit in den Diagrammen.

Mit Hilfe der Einstellung „ WordBreakProc=No“ in der Rose.INI läßt sich Rose 98 auch stabil mit Maustreibern verwenden, die unter Rose 4.0 noch zu Problemen führten.

Ebenfalls neu ist das „Visual Differencing“. Dieses Tool erlaubt es, zwei Modelldateien miteinander zu vergleichen. Ergebnis eines solchen Vergleiches ist eine Liste von Unterschieden in den Modelldateien, die den üblichen Darstellungen von Versionskontrollsystemen nachempfunden ist. Hier können die Änderungen an einem Modell z.B. gegenüber einer Vorgängerversion in einer Übersicht dargestellt werden und ggf. einzeln wieder rückgängig gemacht oder bestätigt werden.

In Sequenzdiagrammen, die dazu tendieren, über die auf dem Bildschirm sichtbare Höhe hinauszugehen, wurden in der Version 4.0 die oben dargestellten Objekte unsichtbar, was die Navigation zwischen den Lebenslinien sehr erschwerte. In der Version 98 werden nun die Namen der Objekte unverdeckbar am oberen Rand des Fensters dargestellt, so daß man auch in Diagrammen, die über mehrere Seiten gehen, immer sieht, zwischen welchen Objekten die Nachrichten laufen.

Ebenfalls neu ist die Verwaltung von einzelnen „Add-Ins“, die sich analog zu der Handhabung in vielen Microsoft-Produkten über einen Add-In-Manager installieren bzw. aktivieren lassen. Als solch ein Add-In wird nun die Anbindung an Visual SourceSafe behandelt. Diese hat ein komplett eigenes Interface bekommen, das nun die Steuerung des Ein- oder Auscheckvorgangs übernimmt.

Geblieben sind die vielfältigen Möglichkeiten der Navigation zwischen den Diagrammen bzw. zwischen den Modellteilen (Klassen, Objekte, Packages), die eine Arbeit auch über komplexe Modelle ermöglicht. Leider auch geblieben sind die unbefriedigenden Möglichkeiten, eine ordentliche Ausgabe der Graphiken zu erhalten. Immer wieder schafft es Rose, die Darstellung auf dem Bildschirm so zu verunstalten, daß z.B. Beschriftungen gekappt werden oder aus den Klassensymbolen herausrutschen. Nur teilweise hilft hier die Möglichkeit, ein „Autosize All“ aus dem Tools-Menü aufzurufen. Von dieser Schwäche in der graphischen Repräsentation ist auch die Ausgabe auf Papier betroffen, die meist keine befriedigenden Ergebnisse bringt.

Nach wie vor ist – obwohl die Oberfläche MDI-Fähigkeit vorgaukelt - nur ein Modell gleichzeitig bearbeitbar.

Ebenfalls unverändert ist die Einbindung von Rosescript. Dies ist ein Basic-Modul, über das sich in einer VBA-ähnlichen Syntax das OLE-Modell von Rose programmieren läßt. Rosescript wird mit einer kleinen IDE, die einen Debugger und einen Dialogeditor enthält, geliefert. Interessanterweise bezieht Rational dieses Modul von Summit Software und nimmt nicht etwa VBA von Microsoft.

Die Zusammenarbeit mit Microsoft schlägt sich dagegen z.B. in der Benennung der verschiedenen Versionen nieder. Die Komplettversion von Rose 98 heißt nun „Enterprise-Version“. Sie enthält neben dem eigentlichen Modellierungstool alle Codegeneratoren (für C++, Java, Visual Basic, IDL, DDL, Oracle8). Die sprachspezifische „Professional Version“ enthält die Unterstützung für nur jeweils eine Sprache. Zur „Visual Modeling Edition“ werden keine Codegeneratoren mitgeliefert, diese ist nur für die Bearbeitung von Modellen und ggf. die Anwendung eines eigenen Codegenerators gedacht.

Eine Evaluationskopie läßt sich von www.rational.com/demos/rose98eval/ downloaden (ca. 20MB). Auch die Regionalbüros von Rational versenden auf Anfrage CDs, die neben einer voll funktionstüchtigen Rose-Version eine Reihe von Beispielen und die komplette UML-Dokumentation enthalten.

Rational unterhält auf dem Internet eine vom Rose-Support betreute Mailliste (Rose_Forum), über die Diskussionen zu Problemen geführt und Lösungen ausgetauscht werden.

Fazit

Rational Rose ist in der vorliegenden Version sicherlich noch nicht das Tool, das alle Wünsche erfüllt. Neben einigen merkwürdigen Verhaltensweisen der Oberfläche und der Graphikdarstellung kann auch die fehlende Unterstützung für Aktivitätsdiagramme auf der Negativliste verbucht werden. So gesehen muß man nicht unbedingt von der Version 4.0 updaten, zumal das Dateiformat weitgehend kompatibel ist, man also auch mit Rose 98 erstellte Modelle unter Rose 4.0 bearbeiten kann. Blickt man jedoch auf das inzwischen recht runde Objektmodell, das Rose zugrunde liegt, wird deutlich, daß in dem Produkt noch sehr viel Potential steckt, das die Entwickler bei Rational sicherlich in den folgenden Versionen ausschöpfen werden. Dieses Objektmodell macht es auch heute schon möglich, ausgefeilte Auswertungstools, Codegeneratoren oder Scripte zum Checken des Modells zu entwickeln. Die guten Navigationsmöglichkeiten und das Bereitstellen eines zentralen Modells, um alle Informationen zu einem OO-System darzustellen und zu verwalten, schlägt die Alternative, das System „zu Fuß“ zu verwalten dann doch um Längen.