Seit ihrer ersten Vollversion im Jahr 1997 hat sich UML zu einem wichtigen Hilfsmittel in objektorientierten Softwareprojekten gemausert. Nun soll sie weiterentwickelt werden und für neue Anwendungsgebiete herhalten wie etwa das gemeinsame Design von Hard- und Software. Und schließlich übernehmen Modellierungssprachen heutzutage mehr und mehr die Aufgaben einer Programmiersprache - allerdings auf einer höheren Abstraktionsebene -, mit dem Ziel, eine "ausführbare" Sprache verwenden zu können, welche die Funktionen von Systemen beschreibt.
Neue Einsatzgebiete
Diese Aspekte bewegten die für die Standardisierung zuständige Object Management Group (OMG) - das Gremium, das für die Definition und Weiterentwicklung der UML verantwortlich zeichnet -, die Arbeiten für eine große Revision aufzunehmen. Der Spezifikationsprozess für die nächste Generation, die UML 2.0, befindet sich gerade in der abschließenden Phase.
Anhand einiger wichtiger Anforderungen, bei denen immer wieder Skalierbarkeit und Präzision eine Rolle spielen, lassen sich die Ziele dieser Revision besser verstehen. Ursprünglich wurde UML konzipiert, um den objektorientierten Entwicklungsansatz zu unterstützen, derzeit jedoch findet ein Paradigmenwechsel zu einem auf Komponenten basierenden Ansatz statt. Dies ist eine Folge des weit verbreiteten Einsatzes von Komponenten-Frameworks wie COM+ und Enterprise Javabeans sowie neueren Enterprise Frameworks wie Java 2 Micro Edition und .NET. Ähnliche Anforderungen findet man auch bei der Entwicklung von eingebetteten Systemen. Für die Modellierung in diesem Umfeld ist eine verbesserte Unterstützung in UML 2.0 notwendig.
Ein anderes anspruchsvolles Ziel besteht darin, die Sprache zu vereinfachen, ohne dass ihr Umfang deswegen geringer würde. Auch wenn einige selten genutzte Konstrukte wahrscheinlich wegfallen werden, so wird die Zahl der neu hinzukommenden Konstrukte überwiegen. Die Vereinfachung verfolgt das Ziel, eine konsistente Architektur der Sprache sicherzustellen und die intuitive Benutzung zu erleichtern. Die Erweiterung des Sprachumfangs erklärt sich unter anderem aus dem Bedürfnis nach einer detaillierten Spezifikation von Verhalten, was beispielsweise präzise Spezifikationen von Actions und Statements voraussetzt wie Assignments, Decisions und Loops.
Die aktuelle Version von UML erlaubt eine Beschreibung des Verhaltens üblicherweise nur in Form von Sourcecode, welcher als Fragment an geeigneter Stelle im Modell platziert und bei der Codegenerierung später übernommen wird. Das Modell selbst ist nicht ausführbar, man braucht zusätzlich eine Programmiersprache und einen Compiler, um letztendlich etwas zu erhalten, das sich ausführen lässt. Derartige Lösungen können je nach dem eingesetzten Werkzeug stark variieren.
Praktischer dürfte es dagegen sein, das UML-Modell erst in Code zu übersetzen, anschließend die ebenfalls in UML beschriebenen Configuration- und Deployment-Informationen anzuwenden und dann erst den Code zu kompilieren. Der wird in diesem Fall behandelt wie Intermediate Code und braucht dann nicht mehr verändert werden. Dieser Ansatz hat den besonderen Vorteil, dass damit UML 2.0 nicht nur von der Plattform, sondern auch von der Zielsprache unabhängig ist. Kombiniert man nun diese Besonderheit mit anderen Initiativen wie der Definition eines UML-Profils für Tests, verspricht dies die Möglichkeit einer frühen Verifikation des Systems.
Da eine vollständige Diskussion der UML 2.0 den Rahmen dieses Artikels sprengen würde, werden im Folgenden nur einige Aspekte kurz vorgestellt, die insbesondere für die Entwicklung von Applikationen für Embedded-Systeme relevant sind.
Embedded-Systeme entwickeln
Das am häufigsten verwendete Konstrukt in UML ist die "Klasse", und bei eingebetteten Applikationen wird normalerweise zwischen aktiven und passiven Klassen unterschieden. Erstere kontrollieren ihr eigenes Verhalten, während passive Klassen ausschließlich im Kontext anderer, aktiver Einheiten wie zum Beispiel einer aktiven Klasse ausgeführt werden können. Alle derzeit in UML existierenden Mechanismen zur Beschreibung von Klassen sollen in der neuen Version beibehalten und durch die hier beschriebenen Konstrukte ergänzt werden.
Für Klassen werden mit UML 2.0 auch "Ports" eingeführt. Sie dienen als Interaktionspunkte und bilden Öffnungen in der "Schale" der gekapselten Klasse, durch welche die Klasse Signale oder Operationen mit ihrer Umgebung austauschen kann. Für Ports können ebenso wie für Klassen Schnittstellen definiert werden. Jeder Port repräsentiert einen "View" auf die Klasse, der separat adressiert werden kann, sobald eine Instanz der Klasse erzeugt worden ist. Beispiele aktiver Klassen mit Ports und Schnittstellen zeigt die Grafik "Bestandteile der UML". Mit derartigen Klassen lässt sich in der Regel sowohl Software als auch Hardware modellieren.
Das Innere einer Klasse kann eine Vielzahl unterschiedlicher Formen annehmen. Im einfachsten Fall sind die von einer Klasse bereitgestellten Operationen direkt implementiert. Das Verhalten einer Operation kann auf viele verschiedene Arten beschrieben sein, zum Beispiel durch die Definition eines Zustandsautomaten oder mittels einer Aktivität, welche diese Funktionalität beschreibt. In komplexeren Fällen wird die interne Struktur der Klasse mit Hilfe "hierarchischer Dekomposition" beschrieben. Dabei werden wiederum Klassen für die Beschreibung von Teilfunktionen verwendet. Wie diese Klassen miteinander agieren, muss ebenfalls spezifiziert werden, da sie je nach Kontext unterschiedlich verbunden werden können. Diese Darstellung geschieht mit Hilfe von "Parts" und "Connectors". Als Part bezeichnet man die Spezifikation der Instanzen, die von einer bestimmten Klasse erzeugt werden. Connectors werden benutzt, um Parts miteinander zu verbinden, und zeigen an, welche Pfade bei der Instanziierung aufgebaut werden. Klassen, die in der internen Struktur benutzt werden, können ihrerseits eine interne Struktur haben. So lassen sich Modelle mit beliebiger Dekompositionstiefe anlegen und bearbeiten.
Der hier zitierte Vorschlag für die UML 2.0 hat gute Aussichten auf eine breite Akzeptanz. Dennoch bleibt bis zur Fertigstellung noch viel zu tun. Sprachdesigner müssen die Vorlage gemeinsam mit anderen Konsortien konsolidieren und dabei weitere Ideen einarbeiten, um innerhalb der OMG zu einem Konsens zu gelangen. Das sollte weder den Zeitplan noch die Sprachqualität gefährden. (as)
*Cris Kobryn ist Chief Technologist, Morgan Björkander Methodenspezialist bei Telelogic in Malmö. Beide Autoren sind an der Spezifikation von UML beteiligt.
Angeklickt
UML 2.0 soll die Art und Weise grundlegend verbessern, wie zukünftig Softwaresysteme spezifiziert werden. Die neue Version der Modellierungssprache soll auch die eng an die Hardware angelehnte Entwicklung von Embedded- und Echtzeitsystemen erleichtern. Aktuelle Informationen über den Stand der Arbeiten und der Standardisierung finden sich auf der Web-Seite http://www.u2-partners.org. Dort steht die neueste Fassung des Proposals zum Download bereit, es gibt Links zu anderen Vorschlägen, und Interessenten können sich einer Diskussionsgruppe anschließen.
Abb: Bestandteile der UML
UML enthält Modellelemente, Bezeichnungen und diverse Diagramme für die Analyse und das Design von objektorientierten Anwendungen. Quelle: CW