Die Argumente, die für und gegen UML, den vor einigen Monaten verabschiedeten Standard der Object Management Group (OMG), ausgetauscht wurden, finden sich im wesentlichen auch in einem White Paper des britischen Marktforschungsinstituts Ovum Ltd. (www.ovum.com/ news/uml/umlwp. html). OOP-Diskukanten und Ovum-Analysten sind sich einig, daß die bloße Existenz eines Sprachstandards für die objektorientierte Modellierung gar nicht hoch genug eingeschätzt werden kann. Immerhin gehöre "semantisches Durcheinander", so Ovum, bisher zu den zeitraubendsten IT-Problemen.
Um so gravierender fällt ins Gewicht, daß es sich bei der UML um eine "Komiteesprache" handelt, die keine klare Syntax hat und kaum über semantische Regeln verfügt, wie auf einer OOP-Podiumsdiskussion deutlich wurde. Sie verbindet die Notation und Syntax der Modellierungsmethoden "OMT" von Jim Rumbaugh, "Booch" von Grady Booch und "OOSE" von Ivar Jacobson. Daraus resultiert, daß die UML komplexer als notwendig ist, Interaktionen, Strukturen und Verhalten sich überlappen und verschiedene Interpretationen eines Modellierungselements möglich sind. So kann es vorkommen, daß verschiedene Tools, die ein UML-Subset implementieren, untereinander nicht kompatibel sind.
Darüber hinaus sind die Versionen 1.0 und 1.1 noch inkonsistent. So stimmten etwa Zustandsautomaten und Sequenzdiagramme nicht überein. Vorsicht ist nach Ansicht der Experten auch bei der Verwendung von Component- und Deployment-Diagrammen geboten.
Laut Ovum gehört zu den Schwächen der UML zudem die mangelnde Unterstützung von Codegeneratoren, Prozessen, einer einheitlichen Verfahrensweise und der Entwicklung von Echtzeitsystemen. Es fehlten Formalismen für Begrifflichkeiten und zur Beschreibung von Konditionen und Invarianzen. Einig waren sich die OOP-Spezialisten darin, daß die Semantik "glattgezogen" werden müsse. Standardisierungsgremien widmen sich bereits der Entwicklung einer Echtzeit-Variante der UML, "UML-RT".
Bezüglich der Code-Erzeugung und der Unterstützung einer einzigen Methodik herrschte kein Konsens. Codegenerierung sei Aufgabe der Tools, die die UML unterstützten, und ein einheitliches Verfahren beschränke die Freiheit in der Entwicklung und lasse sich ohnehin nicht für jegliche Anwendung finden, lauteten die Gegenargumente.
Die OOP-Quintessenz der UML-Standardisierung zeichnet sich auf dem Markt bereits ab. Die Tool-Hersteller setzen darauf. Die Anwender, die objektorientiert entwickeln, können ebenfalls darauf bauen, sollten sich zum gegenwärtigen Zeitpunkt allerdings auf bewährte UML-Bestandteile stützen.
Java eignet sich für ernsthafte Projekte
Als Fazit der Java-Diskussion läßt sich vorausschicken, daß ein erfolgreicher Einsatz von Programmiersprache und Plattform weniger eine Frage des Reifegrads, der schnell wechselnden Releases und deren Inkompatibilitäten sowie der Schnelligkeit von JIT-Compilern und Interpretern ist. Vielmehr hängt das Gelingen davon ab, ob die Entwickler fit in Objektorientierung sind. Java-spezifisch scheint allerdings zu sein, daß in der Projektarbeit zusätzlicher Aufwand für die Optimierung der Programme einkalkuliert werden muß.
Zudem verhalten sich die virtuellen Maschinen unterschiedlich. So können die Widgets einer Applikation verrutschen oder die Farben variieren. Meistens genügt ein einzelnes Tool nicht, sondern es kommen mehrere Werkzeuge, oftmals von verschiedenen Herstellern, zum Einsatz. So ist IBMs "Visual Age für Java" eher an Smalltalk angelehnt als "Visual Café" von Symantec, das sich stärker an C++ orientiert. Daher eignet sich mal das eine, mal das andere Produkt. Um so wichtiger sei es, meinten viele Diskutanten, "100% pure Java" einzusetzen, um wenigstens annähernd Verträglichkeit zu erreichen. Doch häufig unterstützen die Tools, Broker und Browser nicht dieselben Release-Stände.
Während die OOP-Experten sich von Java-Objekten auf dem Server begeistert zeigten, kritisierte man allgemein die fehlende Verträglichkeit mit Browsern. Das liege jedoch weniger an Java als am Entwicklungsstand dieser Thin Clients.
Die Rügen für Bugs in den Entwicklungs-Tools fielen dagegen vergleichsweise harmlos aus. So sei etwa längst bekannt, daß das sogenannte Image für die grafische Oberfläche von Java-Applikationen in Visual Age nicht nach Gebrauch wieder gelöscht wird, sondern ständig weiterwächst. Kritisiert wurde, daß die wenigsten Tools über eine hinreichende Dokumentation und Support für die Entwicklung im Team, Debugger oder ein Konfigurations-Management verfügen.
Trotz der Mängel laufen derzeit mit Java nicht nur "Spiel-Projekte", wie etwa die Daimler-Benz-Anwendung zeigt, die Andreas Mahling, Geschäftsführer der Ars Nova Software GmbH, schilderte. Das Softwarehaus entwickelt für den Automobilhersteller einen Logistikbus, der die Belieferung der Händler mit Ersatzteilen neu regeln soll. Die Anwendung soll im Jahr 2001 fertiggestellt sein.
Nahezu alle OOP-Redner betonten, mit einer Entscheidung für den Einsatz von Java befinde sich der Anwender auf der "sicheren Seite". Die hohen Investitionskosten von Herstellerfirmen wie IBM und Sun garantierten den langfristigen Bestand der Sprache und der Tools.
Java-Wissen
Die Renner auf der OOP '98 waren die deutschsprachigen Vorträge. Nach Interpretation der Veranstalter, der Sigs Conferences GmbH, Bergisch Gladbach, liegt das daran, daß es zunehmend auch in Deutschland Experten für die Objektorientierung gibt. In den Vorjahren hatte man bevorzugt den Stars aus den USA gelauscht. Zum ersten Mal auf der OOP war Microsoft mit einem größeren Forum repräsentiert. Zu den Vorträgen, die sich rund um das Component Object Model (COM) rankten und nicht beitragspflichtig waren, hatten sich bereits vor der Veranstaltung rund 300 Besucher angemeldet.
OOP-Premiere feierte auch der International Java Club (www.java-club.com). Er warb um Mitglieder und Sponsoren, die bereit sind, tief in die Tasche zu greifen: Ab 10 000 Mark sind sie dabei. Neben Sun und IBM gehören etwa auch Sigs, GSE und Daam zu den Geldgebern. Präsident der 100%-Java-Liga ist zur Zeit Michael Stal, beschäftigt bei der Siemens AG.