00-Modellierungswerkzeuge im Vergleich

Modellierungswerkzeuge auf Basis der Unified Modeling Language etablieren sich am Markt. Wichtiges Verkaufsargument: Mit der UML gibt es endlich einen Standard für die Notation von Modellen. Wir haben uns die interessantesten Modellierungswerkzeuge näher angesehen.

Jahr für Jahr wächst die Nachfrage nach hochwertigen Softwaresystemen. Aber trotz neuer Softwaretechnologien ist es in der Informationsverarbeitung und Datenbankentwicklung nicht gelungen, diese Systeme schnell und ausreichend preiswert zu entwikkeln. Seit Mitte der 60er Jahre ist daher von einer Softwarekrise die Rede, weil:

• in aller Regel die Softwareprodukte nicht rechtzeitig fertiggestellt werden,

• der Etat der geschätzten und bewilligten Entwicklungsmittel überschritten wird,

• die Wartungskosten höher als geschätzt sind und

• die Gesamtqualität der Softwareprodukte mangelhaft ist.

Die Softwarekrise hat sich in den letzten Jahren verschärft. Die Ursache der Misere liegt auf der Hand: Die Softwareprodukte werden von Jahr zu Jahr komplexer (viele Anwendungen bestehen inzwischen aus mehreren Millionen Programmcodezeilen), und die Anwendungsgebiete in der Informationstechnik differenzieren sich immer mehr. Was läßt sich tun, um den oben genannten Defiziten etwas Wirksames entgegenzusetzen? Es bietet sich an, CASE-Tools bei der Softwareentwicklung zu benutzen. Viele moderne Applikationen werden basierend auf objektorientierten Prinzipien (beispielsweise Klassen, Methoden und Vererbung) entwickelt.

Objektorientierte CASE-Tools stellen objektorientierte Modellierungsnotationen und -methoden zur Verfügung und generieren sogar Teile objektorientierter Applikationen. Solche CASE-Tools bieten dem Entwickler vor allem dann Vorteile, wenn es sich um mittlere bis größere Projekte handelt. Hohe Ansprüche der Anwender an den Komfort und den Funktionsumfang führen zu bisher ungeahnten Dimensionen der Komplexität der Anwendung. Je größer das Projekt, desto wichtiger ist die lückenlose Benutzung von CASE-Tools über alle Ebenen der Entwicklung hinweg. Trotz der bekannten Vorzüge konnten sich CASE-Tools bis heute nicht bei den Entwicklern durchsetzen und wurden schnell als zeitaufwendig und überflüssig abgetan. Zur Zeit vollzieht sich allerdings in dieser Hinsicht ein Wandel in der Softwareindustrie: In Zeiten, in denen Software nach bestimmten Normen entwickelt wird und dem Auftraggeber die Projektphasen transparent zu machen sind, erscheinen Modellierungs- und CASETools mehr als hilfreich. Auch spielen die verkürzten Entwicklungszyklen eine große Rolle: Sie erschweren es, eine ausreichende Softwarequalität zu erzielen. Um Kosten und Nutzen zu optimieren, üben die oberen Unternehmensetagen enormen Druck auf die Entwicklungsabteilungen aus. Die Entwicklungsprozesse müssen nachvollziehbar sein. Und dies nicht nur, um das Projektende realistisch einplanen zu können.

00-Modellierungs Tools beziehungsweise 00-CASE-Tools (der Unterschied geht gegen Null) sollen aus dieser Misere helfen. Wenn geplant ist, 00-Modellierungs-Tools einzusetzen, sollten sie folgende Grundmerkmale aufweisen:

• Sie bieten die gängigsten Diagrammtypen,

• unterstützen die gängigen Programmiersprachen und alle wichtigen Engineerung-Methoden,

• realisieren automatische Dokumentationserstellung in möglichst vielen Formaten,

• lassen sich auf möglichst sielen Plattformen einsetzen,garantieren gute Team-Unterstützung für große Projekte,

• besitzen eine offene Architektur für beliebige Erweiterbarkeit,

• ermöglichen zentrale Verwaltung aller Werkzeuginformationen.

Der folgende Text geht der Frage nach, welche Disziplinen in welcher Qualität von den untersuchten Produkte unterstützt werden. Bei der Auswahl und Bewertung der Produkte ist in erster Linie darauf Wert gelegt worden, inwiefern sie den genannten Kriterien entsprechen.

OWIS OTW 2.0
Zur Projektrealisierung verfährt OTW2 streng nach dem inkrementellen Verfahren. Jede Projektphase baut auf der vorherigen auf und führt in acht Projektstufen vom Problem zur Lösung. Das Werkzeug bietet Techniken für die Analyse, das Design und die Implementierung. Dabei verwendet das Tool ein speziell auf die UML zugeschnittenes objektorientiertes Vorgehensmodell, das sogenannte SEPP/OT-Modell. Das Vorgehen wird an dieser Stelle näher beschrieben, da es für alle anderen Produkte ähnlich funktioniert. Jedes Projekt beginnt mit der Analysephase, in der sich mit Hilfe des Endkunden die Anforderungen an das Softwaresystem festhalten lassen. Anhand dieser Informationen werden die verschiedenen Anwendungsfälle in das Use-Case-Diagramm von OTW2 eingetragen. Die einzelnen Notationselemente werden dabei in der Toolbar selektiert und frei auf das Diagrammfenster plaziert. Da jeder Anwendungsfall mit einem konkreten Objekt (dem Aktor) verbunden ist, gibt es die tieferliegende Diagrammart „Objekt-Prozeß" (siehe Bild 1). Bei der Analyse wird das Gesamtsystem aus Kundensicht gesehen und entsprechend modelliert. Erst in der Designphase findet man die Entwicklersicht vor. Hier wird mit Hi1fe von Sequenzdiagrammen die Konkretisierung der Geschäftsfälle angestrebt, denn im Case werden die Fälle nur global beschrieben. Danach werden mit dem Zustandsdiagramm die dynamischen Aspekte zur Laufzeit der Applikation modelliert.
Nun lassen sich mit Hilfe des Klassenstrukturdiagramms die Klassenhierarchien für das Gesamtsystem festlegen. Bis dahin wird die physische Architektur überhaupt nicht beschrieben. Erst durch die Informationen im Komponentendiagramm weiß das 00-Werkzeug, wo die bereits erstellten Klassen physisch abgelegt werden.

Verteilungen visualisieren
In Zeiten von Multitier-Applikationen ist es sehr wichtig, genau zu planen, auf welchem Rechner welche Komponente residiert und wie diese vom Clientrechner angesprochen werden kann. Hier setzt das Verteilungsdiagramm an, das die Verteilungen in heterogenen Rechnerlandschaften visualisiert. Das erzeugte Gesamtmodell kann schließlich über einen Check-Mechanismus überprüft werden, um die Softwarequalität zu sichern und zugleich robuste, wiederverwertbare Softwarebausteine zu realisieren. Im Gegensatz zu eher grafisch orientierten CASE-Tools arbeitet OTW2 vorwiegend mit Dialogfenstern und kontextsensitiven Popup-Menüs. Eine mehr visuelle Bedienung wäre auf jeden Fall ergonomischer gewesen. Die Einarbeitung in OTW2 fällt leicht, da das Handbuch ein umfangreiches und anschauliches Beispiel beschreibt. Als weitere Einstiegshilfen werden verschiedene Beispielprojekte mitgeliefert. Außerdem sind ein Dokumentationsgenerator und ein Quellcodegenerator integriert, der aber manuell gestartet werden muß, damit er aktiv wird. Die Konsistenz zwischen Code und Modell nach dem Roundtrip-Engineering-Konzept wird jedoch nicht erhalten. Das Tool arbeitet mehr modellorientiert und nicht codeorientiert. Erst beim Projektende findet die Umsetzung statt und das Endergebnis liegt als Quelltext und als Projektdokumentation vor. Es werden lediglich ReverseEngineering und Forward-EngineerWg geboten. Dies liegt daran, daß Code und Modell in der Werkzeugarchitektur nicht synchron arbeiten. Dabei werden die Quelltexte von anderen Entwicklungsumgebungen eingelesen und in ein objektorientiertes Modell konvertiert. Die so erzeugten Modelle sind ausgereift und praxistauglich. OTW2 arbeitet mit einem proprietären Repository, in dem die Modellobjekte abgelegt sind. Leider verfügt OTW nicht über Multi-User-Fähigkeiten. Somit sucht man vergeblich eine Checkout- und Check-in-Funktion. Auch von Versionsverwathmg fehlt jede Spur. Hinsichtlich der Projektdokumentation setzt OTW2 voll auf Microsoft Word, das bereits installiert sein muß.

Der Dokumentengenerator erzeugt aus den Informationen im Repository eine gewöhnliche Textdatei. Anschließend wird ein Word-Makro gestartet, das die Dokumentation professionell formatiert und als Word-Datei sichert. Es besteht jedoch auch die Möglichkeit, sich einzelne Modelle dokumentieren zu lassen.
Eine 30-Tage-Testversion steht zum Herunterladen vom Server der Firma Owis (www.owis.de) bereit.

Fazit:
Insgesamt macht OTW2 den Eindruck eines guten, robusten Produkts. Leider enthält es nicht alle Funktionen, die man heute von einem Modellierungswerkzeug erwarten kann: Hierzu zählt, daß das Roundtrip-Engineering nicht möglich ist und die Integration in andere Werkzeuge :unzureichend' erfolgt. Lediglich über einen Dialog läßt sich die bevorzugte Entwicklungsumgebung auswählen, Wer jedoch ein schnell zu erlernendes Werkzeug sucht und sich auf gute Modelle beschränken kann, sollte sich das Tool auf jeden Fall näher anschauen.

Cayenne ObjectTeam 7.1
Die Modellierung unter ObjectTeam erfolgt nach dem Phasenkonzept und erlaubt die schrittweise Verfeinerung der Modelle in allen Entwicklungsstadien. Die Bedienungsfreundlichkeit läßt allerdings zu wünschen übrig. Dies liegt daran, daß die Funktionen, die das Werkzeug normalerweise automatisch ausführen müßte, dem Anwender aufgebürdet werden. So muß die Codeübersetzung oder die Kompilierung mit einem internen Tool manuell angestoßen werden, was den ßedienungsfluß ungemein hemmt.
`Object"Team ist prädestiniert für den Multi-User-Einsatz und die objektorientierte Applikationsentwicklung in großen I'rojekten. Als Notation unterstützt das Tool die OMT und die UML. Im Praxisalltag ist ObjectTeam gut im Real-Time-Bereich und für die Geschäftsmodellierung einzusetzen. Es erlaubt, Modellierungskomponenten für Analyse, Design und implementierung anzulegen und zu verwalten. Damit lassen sich Teile eines Modells oder Systems wiederverwenden und von verschiedenen Abteilungen gleichzeitig nutzen. Richtig genutzt, erschließt diese Technik enorme Einsparungspotentiale. Der Codegenerator fungiert als Bindeglied zwischen dem Modell und der lmplementierung. Der Generator extrahiert die benötigten Modellinformationen aus dem Repository und führt die Übertragung in die ausgewählte Zielsprache durch. Für eine Klasse ergeben sich dann der Rahmencode mit Vererbungsbeziehungen, die Definition der Instanzvariablen und der Methodenskelette, die anschließend vom Entwickler mit Anweisungen zu füllen sind.
Da sich die Modelle in beliebige Sprachen übersetzen lassen, steht der Verteilung von Softwarebausteinen auf heterogene Rechnersysteme nichts entgegen. Daher ist es das ideale Werkzeug, um mehrschichtige Applikationen zu entwerfen. Schnell lassen sich dann spezielle Komponenten für die Präsentationsschicht, Businesschicht und der Datenbankschicht erstellen, die in Folgeprojekten Wiederverwendung finden können.

Der verwendete Codegenerator ist in Tcl entwickelt und ist durch den Endbenutzer jederzeit an bestimmte Anforderungen anpaßbar. Darüber hinaus können in ObjectTeam die gängigsten Tools für das Konfigurationsmanagement eingesetzt werden. Standardmäßig unterstützt ObjectTeam die Hochsprachen C++, Java, Delphi, VisualBasic, PowerBuilder und Smalltalk. Ebenso ist es für kleinere Aufgaben geeignet, beispielsweise für SQL-Schemata und CORBA-IDL. ObjectTeam unterstützt als einziges Werkzeug die bereits verabschiedete UML-1.1-Konvention; so sind auch Collaboration- und State-TransitionDiagramme verwendbar. Auch ein OMT-Support ist vorhanden. Unverzichtbar für große Entwicklerteams ist die Eigenschaft, daß ObjectTeam in heterogenen Client/Server-Netz,werkumgebunp;en einsetzbar ist. Dabei kann der Datenabgleich des „Common Workspace" über eine Einwählverbindung vorgenommen werden. Über das Online-Repository verwenden alle Teammitglieder automatisch die letzten Projektinformationen. Ein Object-LockMechanismus erlaubt die Modifizierung einzelner Modellteile, ohne direkt das ganze Subsystem zu sperren. Bei jeder Änderung wird vollautomatisch eine Versionsnummer mitgeschrieben, um den Projektstand zu protokollieren. Über Zugriffsrechte wird jedem Teammitglied der Arbeitsbereich explizit zugeordnet. Die standardmäßige Dokumentierung wird mit DocExpress abgewickelt, während anforderugsspezifische Dokumente mit DocIt generiert werden.

Fazit:
Wer größere Projekte im Unternehmen mit den unterschiedlichsten Sprachen realisiert und auf ein ausgereiftes Team-Management angewiesen ist, muß sich mit diesem Werkzeug auseinandersetzen. Bei der Entwicklung von mehrschichtigen Applikationen bietet ObjectTeam eine gute Hilfe. Ein enormer Einarbeitsaufwand ist notwendig, um das Werkzeug vollständig zu beherrschen. Viele Funktiönalitäten sind schwer zu erreichen.

Rational Rose
Um alle Fähigkeiten von Rose nutzen zu können, muß bei der Installation Microsofts Visual Studio vorinstalliert sein. Nach dem Programmstart setzt Rose das etablierte Wizard-Konzept ein. So lassen sich neue oder existierende Modell-Frameworks schnell öffnen. Etliche solcher Prämeworks sind bereits vorhanden, zum Beispiel für die Entwicklung einer Bankeninfrastruktur, für Administrationssysteme oder Three-Tier-Applikationen - diese lassen sich sehr gut als Vorlage verwenden. Rose ist Multi-User-fähig und für große Entwickhmgsgruppen geeignet. Zu diesem Zweck legt Rose private Arbeitsbereiche für jeden Entwickler an und bietet individuelle Sichten auf das Gesamtmodell. Die eigentliche Modellierung erfolgt nicht immer rein visuell, sondern geht oft noch den Umweg über die Dialogfenster. Als Notation werden Booch, OMT und die UML angeboten. Um unterschiedliche Sprachen zu unterstützen, wählt Rose das bewährte Add-in-Prinzip, mit dem das Werkzeug beliebig erweiterbar ist. Das aktuell verwendete Add-in wird über einen Addin-Manager eingestellt. Bei der Online-Hilfe fehlt oft eine durchgängige Bedienbarkeit; deshalb muß häufig umständlich vor beziehungsweise zurückgesprungen werden. Auch fällt die Online-Hilfe an manchen Stellen nicht gerade umfangreich aus. Via COM ist Rose in der Lage, andere Applikationen wie VB oder WinWord anzusteuern. Das Produkt enthält auch eine Scriptsprache samt Entwicklungsumgebung, mit der sich die Modellierungsfunktionen und sogar die CodeErzeugung von Rose beeinflussen oder für Spezialfälle eigene Funktionen einbauen lassen.
Von Haus aus unterstützt Rose die Sprachen C++, Java, Smalltalk, Ada, Visual Basic, PowerBuilder, die iDL für CORBA und DDL für Datenbankapplikationen. Wurde eine Sprache ausgewählt, paßt sich die Werkzeugumgebung an die speziellen Fähigkeiten dieser Sprache an und wird „on the fly" generiert. Rose bietet von der Analyse bis zur Designphase Unterstützung. Aber auch der Rückwärtsgang vom Design zur Analyse ist gewährleistet: Mit Reverse-Engineering werden bereits vollendete Implementierungen wieder in Modelle verwandelt. Somit sind alle Phasen des Projektlebenszyklus abgesichert.

Außerdem ist Rose Multi-User-fähig und für große Entwicklungsgruppen geeignet. Hierfür legt Rose private Arbeitsbereiche für jeden Entwickler an und bietet individuelle Sichten auf das Gesamtmodell an. Sobald ein Entwickler die Arbeit an einem Teilmodell beendet hat, kann es durch ein Konfigurationsmanagement und Versionskontrollsystem wieder eingecheckt werden. Rose bietet hier die Wahl zwischen Rationals C1earCase und Microsofts SourceSafe. Da Rose über eine offene Architektur verfügt, können auch andere Systeme zum Einsatz kommen. Dem Kommunikations- und Informationsweg verteilter Projekte über Inter- und Intranet trägt das Produkt ebenfalls Rechnung. Rose erzeugt automatisch komplexe Hypertextdokumente im HTML-Format, die allen Projektbeteiligten über Intra- oder Internet zur Verfügung gestellt werden können.

Fazit:
Vom Konzept her verfolgt Rose eindeutig den Komponentenansatz bei der Modellierung, um so abgeschlossene Bausteine für ein System zu schaffen. Leider bringen größere Projekte noch immense Performanceeinbußen mit sich, da die Konvertierung zum Modell entsprechend lange dauert. Die Bedienbarkeit ist nicht gerade intuitiv, da die Dialoge oft zu tief verschachtelt sind. Da Modellierungsprofis bei der Produkterstellung beteiligt waren, ist unverständlich, wieso das Produkt den aktuellen UML-Standard hinterherhinkt, obwohl - andere Produkte schon längst gleichgezogen haben. Wegen der nicht gerade intuitiven Bedienung müssen Anfänger eine hohe Einarbeitungszeit in Kauf nehmen, um akzeptable Modelle zu realisieren.

Microtool ObjectiF 4.0
Das Produkt ObjectiF ist ein reines objektorientiertes CASE-Tool, das methodisch komplett die UML unterstützt. Es begleitet den Entwickler vom Softwareentwurf bis zur Implementierung. Folgende Diagrammtypen sind möglich:

• Anwendungsfalldiagramm,
• Sequenzdiagramm,
• Klassendiagramm,
• Zustandsdiagramm und
• Aktivitätsdiagramm.

ObjectiF hebt sich von den anderen Produkten ab: Es hält für die Anwendungsfälle differenzierte Beschreibungsmuster bereit, die eine einheitliche und vollständige Dokumentation der Systemanforderungen ermöglichen. Aus den Beschreibungen lassen sich durch Markierung einzelner Wörter und Click auf die rechte Maustaste direkt neue Klassen generieren. Alle Diagramme werden während der Arbeit konsistent gehalten. Eine Änderung an einem Diagramm aktualisiert automatisch alle anderen relevanten Stellen. Eine Erweiterung der Methodensignaturen einer Klasse innerhalb eines Sequenzdiagramms zieht automatisch die Übernahme aller betroffenen Methoden in das Klassendiagramm nach sich. Dies erspart eine Menge Arbeit in der Praxis. Weiterhin fallen die umfangreichen Navigationsmöglichkeiten auf. Aus Diagrammen heraus lassen sich andere Diagramme anlegen und zuordnen sowie bereits zugeordnete Diagramme öffnen. Nach dem Package-Konzept werden Klassendiagramme zu größeren Modelleinheiten zusammengefaßt. Bei ObjectiF besteht ein Package aus Klassen desselben fachlichen und technologischen Gebiets und aus solchen, die einen intensiven Nachrichtenaustausch betreiben. Alle Klassen, die als öffentlich deklariert sind, können von anderen t'ackages verwendet werden. Diese
stellt somit die Schnittstelle des Packages dar. Die Packages können dann später in weiteren Projekten Wiederverwendung finden.

Bereits während der Modellierung generiert ObjectiF Code und sorgt für die Konsistenz zwischen Modell und Code. Diese Codegenerierung erfolgt bei ObjectiF mittels Skripten. Es werden hierbei die Zielsprachen C++ und Java unterstützt. ObjectiF läßt sich jedoch auch für andere Sprachen konfigurieren. Während der Codierung wird man vom Code-Editor durch Syntax und Kontextmenüs unterstützt. Ist die Syntax dabei fehlerhaft, wird dies formell hervorgehoben. Die Codegenerierung wird bei Klassen angestoßen. Da die Architektur vom ObjectiF auf COM basiert, kann der Funktionsumfang bedarfsspezifisch jederzeit erweitert werden.
Bei Erweiterungen ist der Add-InManager hilfreich, indem er die Funktionen ins Menü integriert. Eine Reihe von Add-Ins bringt ObjectiF in Form von Visual-C++-Anbindung, JBuilderAnbindung, Java Bytecode Engineering und dem Web Publisher mit. Sehr wertvoll ist, daß sich Anwendungsfälle direkt mit Ansichten assoziieren lassen. Gerade für Einsteiger wird das Gesamtmodell somit wesentlich transparenter. Andere Tools bieten dies nicht, da dort die Sicht durch Ersatzklassen repräsentiert wird. Gelungen sind auch die Multimedia-Tutorials, die schnellen Einstieg in das Tool und die UML ermöglichen. Aber die Fensterflut trübt das Gesamtbild ein wenig.

Mit ObjectiF bekommt der Käufer ein ausgereiftes, zuverlässiges Produkt. Es läßt sich beliebig erweitern und arbeitet auch gut mit externen Werkzeugen zusammen. Es ist für größere Projekte geeignet. Ein Absturz während des Tests kam nicht vor. Besonders gefallen kann das Reverse Engineering aus Visual-C++-Projekten. Dabei wird alles protokolliert, so daß bei auftretenden Problemen die Fehleranalyse und -beseitigung einfacher sind. Die erstellten Pf6chtenhefte basieren auf der ANSI-Norm. Eine Testversion kann vom Server der Firma Microtool heruntergeladen werden.

Object International TogetherJ 3.0
Zur Ausführung von TogetherJ ist die virtuelle Maschine (VM) von Microsoft oder Sun notwendig. Da TogetherJ plattformtmabhängig entwickelt wurde, verfügt das Produkt auf verschiedenen Plattformen über das gleiche hook-and
rr~ artda-KmnmunNalfurrxvrischenieF- ic rrunde>d-emgeben~
Feel. Dies verringert die Einarbeitungszeit in Unternehmen mit heterogenen Systemen enorm. Wegen der 100°/>java-Codierung läßt die Performance allerdings zu wünschen übrig. Ob sich das durch die Hotspot-Technik ändern wird, bleibt abzuwarten. Ein 200-MIiz

Pentium mit 128 MByte RAM ist äußerstes Minimum, um das Tool sinnvoll einsetzen zu können. Die Oberfläche von TogethcrJ ist sehr intuitiv zu bedienen, da sich Klassen und deren Attribute und Methoden via Mausclick anlegen, ändern oder löschen lassen. Mit Drag-and-Drop können zusammengehörige Klassen visuell miteinander verbunden werden.
Bei der Modellierung unterstützt TogetherJ den Entwickler mit diversen Browsern für die verschiedenen Sichten. Es unterstützt die gängigsten Diagramme der UML wie Klassen-, Sequenz-, UseCase, ObjectModell, Komponenten- und Verteilungsdiagramme. Diagramme lassen sich in allen Modellierungsschritten miteinander verbinden. So ist etwa eine Verbindung von Klassen mit einem Zustandsdiagramm möglich, um ein umfassendes Gesamtmodell zu erhalten. Besonders praktisch ist, daß der generierte Code und das zugrundeliegende Modell synchron arbeiten und Änderungen sofort aktualisiert werden.

So zieht eine Änderung im Codefenster eine Aktualisierung im Diagrammfenster nach sich und umgekehrt. Dies erledigt der Fuzzy-1'arser automatisch und ermöglicht so das Roundtrip-Engineering am besten. Der Fuzzy-Parser hilft Zeit zu sparen, da nur Änderungen berücksichtigt werden müssen. Das Tool verwendet die Single-Source-Technik, das heißt, alle Informationen, die das Modellierungs-Tool benötigt, stehen im Quellcode. Damit gehört die redun
dante Datenhaltung der Vergangenheit an. Alle anderen Tools im Testfeld, die 12epository-orientiert arbeiten, können die Synchronität zwischen Modell um.- _~ode nicht bieten. TogetherJ eignet sich besonders für große Projekte ab 1000 Klassen. Die erzeugten Diagramme lassen sich in der Coad-, der OMTund der UML-Notation anschauen. Allerdings geht die Konvertierung zwischen den Notationen nicht gerade schnell vonstatten.
Laut Portfolio von Object International unterstützt TogetherJ die Sprachen Java, C++ und Object COBOL. Bald sollen jedoch auch Visual Basic und Smalltalk das Angebot bereichern. Der Funktionsumfang des Werkzeugs läßt sich durch die offene Architektur komfortabel erweitern. Braucht ein Unternehmen eine neue Tool-Funktion, wird diese im Menü von TogetherJ integriert. Der F ' 1-In-Manager stellt sicher, das Togeth..j ein Werkzeug aus einem Guß bleibt. Die Hilfe erläutert, wie einfach sich das Werkzeug in die 1DEs der Entwicklungssysteme von Borland oder Microsoft integrieren läßt. TögetherJ verfügt jetzt endlich über eine Versionskontrolle. So können sich mehrere Entwickler am Projekt beteiligen und ihre privaten Stände aus- beziehungsweise einchecken. Auch mit inneren Klassen kann TogetherJ jetzt umgehen. Sobald man eine Klasse auf eine andere zieht, wird diese als innere Klasse angelegt. Wurde beim Entwicklungprozeß falsch vorgegangen, läßt sich dies jetzt beliebig rückgängig (UNDO/KEDO) machen. Die Dokumentation für ein Projekt wird über den Menüpunkt Tools/ GenerateDocumentation angelegt. Je
doch zeigt der TemplateDesigner jetzt das endgültige Erscheinungsbild und läßt sich so überprüfen. Legt man jetzt eine RTF-Dokumentation an, wird diese selbsttätig in Word hineingeladen. Ein externer Editor läßt sich schnell über das Kontextmenü aufrufen. Nachdem der Anwender im Editor etwas editiert hat und nach TogetherJ zurückgekehrt ist, erfolgt eine automatische Aktualisierung. Auch Fehler von Compilern oder Debuggern berücksichtigt TogetherJ und zeigt diese im Nachrichtenfenster an. Der Import von Rose-Modellen oder der Export nach Rose verläuft jetzt endlich ohne Probleme. Für CORBA basierte Projekte ist ein IDL-Generator integriert, und auch das neue Web-Format XML kann TogetherJ importieren oder exportieren. Aus dem Internet läßt sich eine Testversion des Produkts herunterladen. Sie berücksichtigt jedoch nur drei Diagrammtypen.

Fazit:
Pluspunkte von TogetherJ sind die gute Bedienbarkeit und die vorbildliche Integration in das bevorzugte Entwicklungssystem. Es bietet zwar nicht alle Diagramme der ITML-Notation; da die Collaboration- und State-Transition-Diagramme fehlen, aber für den kompletten Entwicklungsprozeß reichen die gebotenen allemal aus: Der mitgelieferte „Started Guide° gestattet schnellen Einstieg in das Tool. Einziges Handikap ist die schlechte Performance: Wer Projekte ab 1000 Klassen modellieren will, könnte mit diesem Produkt richtig liegen. Somit ist das Produkt prädestiniert für Unternehmen, die sich mit größeren Projekten befassen.

Zusammenfassung
jedes der getesteten Werkzeuge weist spezielle Stärken auf. Bei der Auswahl geht es nur noch darum, sich über die Bedürfnisse und Zielvorstellungen im Unternehmen klar zu werden - ein passendes Produkt findet man dann immer. Rose wird Freunde unter den Modellierungsprofis finden, die an umfangreichem UML-Support besonders interessiert sind.
Wer jedoch mehr Wert auf gute Bedienbarkeit und schnelle Ergebnisse legt, dürfte eher mit TogetherJ glücklich werden. Sind umfangreiche Projekte im Unternehmen zu realisieren, ist Object Team die richtige Wahl - es ist prädestiniert für den Einsatz in heterogenen Unternehmenslandschaften. Für Einsteiger, die nicht im Team arbeiten, eignet sich OWIS OTW2. Aber auch ObjectiP ist für Newcomer eine gute Entscheidung.
Das Ende der Fahnenstange bei den 00-CASE-Tools ist noch nicht erreicht. Es bedarf noch einer Menge praktischer Erfahrungen, um leistungsfähigere Werkzeuge zu schaffen. Auch die UML wird sich sicherlich noch weiterentwikkeln. Vom Gesamteindruck her ist keines der Produkte derzeit schon völlig ausgereift - alle leiden unter kleineren oder größeren Mängeln. Aber schon heute sind sie eine große Hilfe bei der Entwicklung komplexer Software-Systeme.