Mit der Vereinheitlichung der objektorientierten Modellierung durch die UML erhält das Konzept der ingenieursmäßigen Software-Entwicklung (CASE = Computer Aided Software Engineering) eine neue Chance. Die dafür konzipierten Werkzeuge waren in den 80er Jahren nach anfänglicher Euphorie bei den Anwendern in Ungnade gefallen, weil die Projekte zuviel Zeit in Anspruch nahmen. Zudem zeigte sich, daß sich Funktionen und Daten mit solchen Werkzeugen nicht ausreichend gut voneinander getrennt modellieren ließen. Insbesondere der Änderungsaufwand schwoll mit der Größe der Projekte unverhältnismäßig an.

Die objektorientierte Software-Entwicklung geht einen anderen Weg und ermöglicht die gemeinsame Modellierung von Funktionen und Daten sowie eine saubere Trennung und Wiederverwendung der Anwendungsbausteine. Die Vorteile gegenüber herkömmlichen Methoden liegen dank Kapselung und Abstraktion vor allem in der Analysephase eines Projekts. Integrierte CASE-Tools ergänzen diese Phase, indem sie den gesamten Entwicklungsprozeß begleiten.

Die Autoren der Studie von IT Research "CASE und OO-Methoden" warnen jedoch davor, nun abermals übereilt solche Werkzeuge ohne vorherige Prüfung ins Haus zu holen. Zu den Grundvoraussetzungen für erfolgreiche Objektorientierung (OO) zähle vielmehr, daß Entwickler ein umfassendes betriebswirtschaftliches Wissen sowie ein hohes Abstraktionsvermögen für die komplexe Modellierung mitbringen. Ist dies nicht ausreichend vorhanden, müssen vor dem Tool-Kauf entsprechende Pilotprojekte und Schulungen durchlaufen werden. Diese können weit teurer kommen als der Kaufpreis der Software. Der Return on Investment stellt sich jedoch laut Studie mittelfristig ein (siehe "Beispielrechnung").

Ferner ist vorab die Programmiersprache für die künftige Entwicklung zu wählen. Grundsätzlich gilt, daß der Wechsel zu einer OO-Sprache etwa von C auf C++ nur dann Sinn gibt, wenn zugleich auf die durchgehende Umsetzung der OO-Analyse und damit vor allem die Nutzung von UML geachtet wird. Neben Java und Smalltalk gehen die Unternehmen derzeit aufgrund der großen Bestände an Cobol- und C-Code in erster Linie zu Hybridsprachen wie C++ und OO-Cobol über, die eine funktionale und objektorientierte Programmierung zulassen.

Gefährlich ist insbesondere der Wunsch einer langsamen Migration von C nach C++, der die Entwickler dazu verführt, die objektorientierte Sprache nach dem prozeduralen Konzept von C zu verwenden.

Auf diese Weise können zwar bestehende Ressourcen ohne Änderung übernommen werden, das Ziel einer einheitlich objektorientierten Entwicklung ist damit jedoch gefährdet. Gerade die Koexistenz von Objekten und Relationen einerseits mit herkömmlichen Datenstrukturen andererseits führt leicht zum Chaos. Besser, so die Autoren der Studie, ist eine vollständige OO-Neuentwicklung, die derzeit insbesondere wegen der teuren und zeitaufwendigen Schulungen gescheut wird. Laut Gerhard Versteegen, einem der Autoren der Studie, befinden sich damit sowohl Unternehmen als auch Anbieter in einem Dilemma: Der Wunsch nach vollständiger Objektorientierung wird nicht erfüllt und OO-CASE-Tools wenig gekauft. "Vor allem wegen der Jahr-2000-Projekte und der Euro-Umstellung warten selbst viele OO-interessierte Unternehmen mit der Neuanschaffung. Die Anbieter müssen deshalb in den nächsten zwei Jahren einen langen finanziellen Atem haben."

Wer hingegen bereits heute eine OO-Entwicklungsumgebung anschaffen will und die genannten prinzipiellen Fragen beantworten konnte, sieht sich einer wachsenden Palette an Produkten gegenüber. Für die Studie wurden zehn Tools ausgewählt (zu den Kritierien siehe Kasten "Zur Studie"), denen gemeinsam ist, daß ihre Anbieter auf dem deutschen Markt direkt vertreten sind, ausreichend Support bieten und die Arbeit mit OO-Methoden, insbesondere UML, unterstützen.

Die Produkte unterscheiden sich in ihrem Leistungsumfang und Funktionalität, so daß der Anwender, je nach seinen individuellen Anforderungen, aussuchen kann. So ist etwa die Methodenunterstützung sehr unterschiedlich ausgeprägt (siehe Tabelle "Unterstützte Methoden" auf Seite 13), und nicht durchweg gibt es eine umfassende Benutzerverwaltung (siehe Tabelle "Die Anbieter im Vergleich").

Weitere Aspekte sind:

-Client-Server: "Rose", "Together Professional" und "CASE/4/0" haben keine Client-Server-Architektur. Auf dem Client unterstützen alle Tools Windows NT, mit allen gängigen Unix-Derivaten arbeitet hingegen nur "Innovator".

-Repository: Für die interne Datenhaltung bieten nur "Objectteam" und "STP" ein eigenes Repository. Alle anderen sind File- oder datenbankbasiert. Auf ein Metamodell für die Datenhaltung muß der Anwender bei "Select Enterprise" verzichten.

-Programmiersprachen: Bis auf CASE/4/0, das nur strukturierte Sprachen unterstützt, ist C++ der Standard. Java wird bis auf "Designer 2000" ebenfalls von allen Tools genutzt. OO-Cobol hingegen kann nur mit "Innovator" und Together Professional verwendet werden.

Methodenwechsel kommt teuer zu stehen

Schließlich sollten bei der Tool-Auswahl einige allgemeine Kriterien berücksichtigt werden. Der Kunde ist gut beraten, sich für nur eine Methode als Standard in seinen Projekten zu entscheiden, da ein nachträglicher Wechsel sehr teuer kommt. Dementsprechend muß das gewählte Werkzeug die gewünschte Methode durchgängig verwenden. Ein Stolperstein ist immer wieder auch, wenn nicht alle im Unternehmen eingesetzten Systemplattformen unterstützt werden.

Wichtig ist außerdem eine automatische Fehlererkennung für die Modellierung, vor allem wenn Entwickler erstmals mit einer neuen Methode arbeiten und eine Kontrollfunktion brauchen. Außerdem sollte die Qualifikation des Anbieters danach beurteilt werden, ob er nicht nur teure Schulungen anbietet, sondern auch projektbegleitend arbeitet und auf Kundenwünsche eingeht.

Zr Studie

Die Studie "CASE und OO-Methoden" von IT Research richtet sich an Unternehmen, die planen, erstmals eine Software-Entwicklungsumgebung einzuführen oder auf ein anderes Produkt zu migrieren. Auswahlkriterien waren die Verfügbarkeit und ausreichender Support im deutschsprachigen Raum sowie die Unterstützung von OO-Methoden. Übrig blieben folgende Tools:

-"CASE 4/0" und "Objectif" von Microtool,

-"Designer 2000" von Oracle,

-"Innovator" von MID,

-"Objectteam" von Cayenne,

-"OTW" von OWIS,

-"Rational Rose" von Rational,

-"Select Enterprise" von Select,

-"Software Through Pictures" (STP) von Aonix und

-"Together Professional" von Object International.

Die Ergebnisse basieren auf den Aussagen der Hersteller sowie eigenen Tests der Autoren.

Bezug: IT Research GmbH, Arnikastraße 2, 85 635 Höhenkirchen.

Abb.1: Return on Investment

Ausgangsbasis ist eine Abteilung mit zehn Entwicklern. Es zeigt sich, daß OO-CASE-Tools nur mittelfristig, in diesem Beispiel nach zwei Jahren, profitabel sind. Quelle: IT-Research

Abb.2: Unterstützte Methoden

Die meisten Tools unterstützen neben der UML weitere objektorientierte und strukturierte Methoden. Quelle: IT Research

Abb.3: Die Anbieter im Vergleich

Nicht alle Tools koordinieren die Arbeit der Entwicklerteams. Quelle: IT Research