Modelle für die Anwendungen

In den späten 90er Jahren wurde die Unified Modeling Language (UML) von dem Softwarehersteller Rational, der heute zu IBM gehört, zusammengestellt. Später hat sie dann die Object Management Group (OMG) standardisiert. Ziele sind, die Strukturen von Programmsystemen klar aufzubauen und grafisch darzustellen, Code zu generieren, wo immer möglich, und dadurch die Qualität der Software zu verbessern. Nicht zuletzt soll dadurch die Wartung einfacher werden: Dazu gehören Portierungen auf andere Betriebssysteme ebenso wie Integration und Interoperabilität mit Applikationen, die auf anderen oder neueren Basistechnologien beruhen, und natürlich Änderungen und Erweiterungen der Funktionalität, um veränderten Anforderungen gerecht zu werden.
»Auf Wartung und Integration entfallen 90 Prozent der Kosten im Software-Lebenszyklus«, schätzt OMG-Chef Richard Soley. Muss der Code geändert werden, so lassen sich doch die Modelle wieder verwenden. Auch für verwandte Aufgabenstellungen lassen sich vorhandene Entwurfsdiagramme nutzen, um Software-Familien zu erzeugen. Die Erstellung der Diagramme kostet zwar zunächst Zeit und Geld, doch Generierung und Wiederverwendung versprechen mittel- und langfristig Einsparungen. Methodologien wie der Rational Unified Process (RUP) bieten außerdem Handreichungen, den gesamten Software-Lebenszyklus auf die UML abzustimmen und Vorgehensweisen festzulegen.

KONKRETERE MODELLE
Die UML ist heute auch de facto zu einem Standard für den Entwurf größerer Anwendungen geworden. Nicht nur Produkte der Kategorie Analyse und Design unterstützen sie wie selbstverständlich, sondern auch Werkzeuge aus dem Bereich der Codierung ? egal, ob sie aus der Microsoft- oder der Java-Ecke kommen. Allerdings implementiert entgegen den Werbeaussagen bislang kein verfügbares Werkzeug die umfangreich gewordene Version 2 der UML, kritisiert der IT-Berater Gernot Starke.
In der Praxis werden häufig Modelle unterschiedlicher Abstraktionsstufen erstellt. Die OMG unterscheidet deshalb inzwischen plattformunabhängige und
-spezifische Modelle. Die letzteren entstehen aus den ersteren durch Transformationen und können zum Beispiel auf Microsofts .Net-Umgebung oder auf die Java 2 Enterprise Edition (J2EE) Bezug nehmen. Die einschlägigen OMG-Standards laufen unter dem Begriff Model Driven Architecture (MDA).
Bei Modellen unterschiedlicher Abstraktheit gehen indes Softwarehersteller und -anwender nicht immer mit den OMG-Standards konform. Allgemeiner wird deshalb statt von MDA auch von Model Driven Development (MDD) oder Model Driven Software Development (MDSD) gesprochen.

FACHNÄHERE DARSTELLUNG
Ein Trend im Rahmen der MDSD geht dahin, näher an den anwendungsfachlichen Aufgabenstellungen zu modellieren. Die Notationen der UML sind zwar vielfältig und komplex, aber eben doch sehr allgemein. Um die UML für gewisse Aufgaben zu erweitern, gibt es den Profiling genannten Mechanismus. Darüber hinaus arbeiten die IT-Experten inzwischen an so genannten domänenspezifischen Sprachen (Domain Specific Languages, DSLs), um die Anforderungen in bestimmten Anwendungsbereichen oder Branchen beim Softwareentwurf besser erfüllen zu können. Verwendet eine Beschreibung im Rahmen der UML bereits programmiersprachliche Konstrukte wie Objekte und deren Beziehungen, so wird mit einer DSL die gewünschte Funktionalität mit den Begriffen des Anwendungsbereichs dargestellt. Die künftigen Anwender aus den Fachabteilungen können dadurch in die Softwareentwicklung im Prinzip besser einbezogen werden, argumentiert der Berater Markus Völter aus dem württembergischen Heidenheim. An der Ausgestaltung der Idee scheiden sich indes die Geister. IBM etwa möchte mit DSLs stets im Rahmen der bewährten und etablierten UML bleiben, Microsoft hingegen nicht.
Für die IT-Abteilung eines Anwenderunternehmens stellt es jedenfalls einen beträchtlichen Aufwand dar, eine eigene Modellierungssprache zu definieren und einzuführen. Werkzeuge gibt es dafür noch kaum, außerdem wird einiges Know-how benötigt ? sowohl auf der Fach-, als auch auf der Informatik-Seite. Organisatorisch empfiehlt Völter eine Trennung der Rollen Domänenanalyse, Infrastruktur- und Anwendungsentwicklung. Wenn die IT-Abteilung die Sache strategisch anpackt, könne sie die Softwareentwicklung auf eine neue Grundlage stellen.