uml 2.0: alles wird gut?

objekte
uml 2.0: alles wird gut?
von bernd oestereich und
tim weilkiens
mehr zum thema:
www.omg.org/uml/
www.u2-partners.org
UML 2.0:
ALLES WIRD GUT?
Die „Unified Modeling Language” (UML) überfordert und verwirrt viele Anwender
durch ihre Notationsvielfalt, obwohl einige wichtige Elemente fehlen. Andere Elemente
sind unbrauchbar oder fehlerhaft, bestimmte Elemente wurden zur allgemeinen
Verwirrung in Notation und Semantik von Version zu Version geändert. Jetzt steht die
UML 2.0 vor der Tür und wird in Kürze offiziell verabschiedet – wird jetzt alles besser?
Der Artikel beschreibt die für die Praxis wichtigsten zu erwartenden Neuerungen.
In Folge der Erfahrungen mit der UML 1.x
wurde die Kritik- und Wunschliste für
neue UML-Versionen immer länger. Da
sich einige elementare Anforderungen
nicht sinnvoll in die UML integrieren ließen, war es notwendig geworden, sie von
Grund auf neu aufzusetzen – deshalb nun
der Versionswechsel vor dem Punkt von
1.x auf 2.0. In UML 2.0 wurde die UML
komplett renoviert, beispielsweise ist das
Metamodell ganz anders aufgebaut.
Im Fokus: MDA, XMI,
RT und BPM
Beim Entwurf der UML 2.0 wurde unter
anderem folgenden Bereichen größere
Aufmerksamkeit gegeben:
■ verbesserter Modellaustausch durch
XML Metadata Interchange (XMI),
z.B. inklusive Diagramm-LayoutInformationen,
■ verbesserte Unterstützung der Model
Driven Architecture (MDA), d. h. auch
von Modelltransformationen und ausführbaren UML-Modellen1) ,
■ bessere Unterstützung von Echtzeitmodellierung (RT) durch neue Diagrammtypen und erweiterte Semantik,
■ bessere Unterstützung von Geschäftsprozessmodellierung (BPM).
Nachdem die Object Management Group
(OMG) den Bedarf einer größeren Überarbeitung erkannt hatte, forderte sie zur
Einreichung entsprechender Vorschläge
auf. Im Wesentlichen beteiligen sich drei
Konsortien an der sogenannten Infra- und
Superstruktur-Spezifikation der UML 2.0:
■ 3C (Clear Clean Concise): Financial
Systems Architects, MEGA International, TogetherSoft Corporation
■ U2 Partners: Alcatel, Computer
Associates, Enea Business Software,
Ericsson, Hewlett-Packard, IBM,
I-Logix, IONA, Kabira Technologies,
Motorola, Oracle, Rational Software,
SOFTEAM,
Telelogic,
Unisys,
WebGain
■ 2U (Umambigous UML): Adaptive,
Data Access Technologies, Kinetium,
Project Technology, Inc., Siemens,
Softlab, Dr. A. Clark (Kings College,
London, UK), Dr. A. Evans (University
of York, UK), Dr. S. Kent (University
of Kent, UK)
Von diesen Einreichungen hat sich das U2Partner-Konsortium mit der deutlich erkennbar strukturiertesten und umfassend1
) Zum Thema MDA mit UML 2.0 finden Sie übrigens einen eigenen Beitrag von Chris Kobryn u.a.
auf S. 32 in diesem Heft.
d i e a u t o re n
Bernd Oestereich
(E-Mail: [email protected]) ist
Geschäftsführer der oose.de Dienstleistungen für innovative Informatik
GmbH.
Tim Weilkiens
(E-Mail: [email protected])
arbeitet bei der Firma oose.de als
Trainer und Berater.
sten Spezifikation durchgesetzt. UML 2.0
ist formal in folgende Teile gegliedert:
■ Infrastructure: Kern der Architektur,
Profile und Stereotypen
■ Superstructure: statische und dynamische Modellelemente
■ Object Constraint Language (OCL):
formale Sprache für Zusicherungen
■ Diagram Interchange: UML-Austauschformat
In diesem Artikel betrachten wir nur die
Infra- und Superstruktur und auch daraus
Abb. 1: Aktivitätsmodelle jetzt mit Petri-Netz-Semantik
36
37
w w w. o b j e k t s p e k t r u m . d e
objekte
uml 2.0: alles wird gut?
nur ausgewählte Aspekte.
Im Bereich der statischen Modellierung
wurde nur wenig geändert, Klassendiagramme sind weitgehend unverändert,
nur im Bereich der Komponentenmodellierung sind ein paar wichtige
Neuerungen zu verzeichnen. Die grundlegendsten Änderungen finden wir in der
Verhaltensmodellierung, vor allem bei den
Aktivitätsdiagrammen.
Aktivitäten sind jetzt
keine Aktivitäten mehr...
In der UML 1.x war ein Aktivitätsdiagramm eine Spezialform eines
Zustandsdiagramms, was theoretisch und
praktisch viele Probleme aufwarf und zu
einer eher ausdrucksschwachen Notation
führte. Nun sind Aktivitätsdiagramme
auch im Metamodell eigenständig, d. h.
auch formal etwas völlig Neues.
Zur allgemeinen Verwirrung werden leider einige Begriffe aus der UML 1.x beibehalten, obwohl sie stellenweise eine grundlegend andere Bedeutung haben.
Während früher die einzelnen Schritte
im Ablauf Aktivitäten genannt wurden,
heißt nun das Diagramm bzw. Modell
„Aktivität”. Die einzelnen Schritte heißen
nun „Verhaltensaufruf” (activity invocation). Wie der Name sagt, repräsentiert ein
Ablaufschritt nun nicht mehr selbst ein
Verhalten, sondern ruft es nur auf. Verhalten und der Aufruf von Verhalten wurden somit getrennt. Aufgerufen werden
können verschiedene Arten von Verhalten,
entweder eine elementare Operation oder
wiederum eine ganze Aktivität (d. h. ein
komplettes Untermodell).
Neben diesen begrifflichen Umstellungen gibt es verschiedene inhaltliche
Neuerungen. Aktivitätsmodelle haben nun
große Ähnlichkeit mit Petrinetzen, was
ihre Ausdruckfähigkeit stark erhöht:
■ Die Semantik von Synchronisationsund Splitting-Punkten hat sich geändert. Die Einschränkung, dass eine
Aufteilung stets wieder synchronisiert
werden muss, besteht nicht mehr.
■ Ein Aktivitätsmodell darf nun endlich
mehrere Anfangszustände (heißen nun
Startknoten) besitzen, wodurch parallele Abläufe gestartet werden. Auch
Signale können Startknoten sein.
■ Es gibt eine neue Art von Endzustand,
das Ablaufende, bei dem nur ein Ablaufzweig der Aktivität stoppt, während beim Aktivitätsende stets die
gesamte Aktivität stoppt.
■ Aktivitätsmodelle dürfen nun Ein- und
Ausgabeparameter erhalten.
■ Objektflüsse lassen sich besser beschreiben. Die bisherigen Objektzustände werden durch Objektknoten
ersetzt, die nun (ähnlich wie bei der
Trennung von Verhalten und Verhaltensaufruf) nicht mehr die Objekte
selbst repräsentieren, sondern diese
nur in der Art eines Containers referenzieren.
■ Die Zählung von Tokens, ähnlich wie
in Petrinetzen, ist möglich.
■ Innerhalb von Aktivitätsmodellen dürfen nun auch einzelne Schritte als
Sequenzdiagramm repräsentiert werden.
Abbildung 1 zeigt als Beispiel, wie immer
sechs Flaschen abgefüllt und etikettiert
werden, die dann zu einem Sechser-Pack
gebündelt werden. Durch die Schleife nach
dem Splitting-Balken wird ausgedrückt,
dass bereits die nächste Flasche angefüllt
Abb. 2: Herzschrittmacher als Timing-Diagramm (nach [Dou98])
1/2003
werden kann, während die vorige noch
etikettiert wird.
Sobald Feierabend ist, werden keine
neuen Flaschen mehr abgefüllt, die bereits
abgefüllten werden aber noch etikettiert.
Sofern gerade noch sechs Flaschen zusammenkommen, werden diese auch noch
gebündelt.
Bald ernst zu nehmen:
Echtzeitmodellierung mit
der UML
Aufgrund der hardwarenahen Programmierung adaptieren RTE-Entwickler
(Real-Time and Embedded) seltener neue
Technologien als „normale” Entwickler.
Aber zunehmende Komplexität der RTESysteme und kürzere Auslieferungszyklen
erfordern auch in diesem Bereich einen
Wandel. Konferenzen zu RTE-Systemen
zeigen, dass vermehrt objektorientierte
Konzepte eingesetzt werden und somit die
UML in den Fokus der RTE-Entwickler
gekommen ist. Die Neuauflage der UML
hat einige interessante Aspekte für RTEEntwickler zu bieten.
Bewährte Konzepte aus „Real-Time
Object-Oriented Modeling” (ROOM,
[Sel94]), einem der Standardwerke zum
Thema Echtzeitmodellierung, sind in der
UML 2.0 enthalten.
Mittels Parts, Connectors und Ports
können interne Laufzeitstrukturen von
Klassen modelliert werden.
Timing-Diagramme ermöglichen die
Modellierung von zeitgenauen Zustandsübergängen. Die Technik wird schon lange
erfolgreich von Elektro-Ingenieuren verwendet und wird nun in die UML 2.0 als
Diagrammform aufgenommen. Abbildung 2
zeigt ein Timing-Diagramm für einen
Herzschrittmacher.
Die Beschreibung von Verhalten ist mit
der UML 2.0 sehr viel detaillierter und
formaler möglich, sodass Modelle erstellt
werden können, die ausführbar sind (executable UML). Entgegen dem „rush-tocode”-Syndrom können Konzepte frühzeitig überprüft werden.
Domänen-spezifische Konstrukte sind
in der UML nicht bzw. sollten nicht enthalten sein. Daher kann auch die UML 2.0
nicht alle Anforderungen von RTEEntwicklern befriedigen. Hierfür sind
Profiles notwendig – ein Erweiterungsmechanismus der UML. Speziell für RTE
gibt es ein „UML Profile for Schedulability, Performance and Time” und
„UML Profile for Quality of Service
(QoS)” (in Arbeit) (siehe www.omg.
org/uml).
w w w. s i g s - d a t a c o m . d e
objekte
uml 2.0: alles wird gut?
Abb. 3: Sequenzdiagramme mit Unterdiagrammen und Schleifen
Sequenzdiagramme: Sind
Neuerungen wirklich wichtig?
Die Überarbeitung der Verhaltensmodellierung bringt auch eine Änderung im
Bereich der Sequenzdiagramme mit sich.
Bekannte Schwächen der UML 1.4, wie
z.B. bedingte Nachrichten, wurden in der
neuen Fassung verbessert. Eine weitere
wesentliche Neuerung ist die Möglichkeit,
in Sequenzdiagrammen auf andere Sequenzen zu verweisen. Somit können
Sequenzen zerlegt werden („divide and
conquer”). Immer wieder vorkommende
Sequenzen können so einmal modelliert
und mehrfach referenziert werden (siehe
Abb. 3). Die Vermeidung von redundanten Informationen trägt sehr zur Qualität
des Modells bei.
Sequenzdiagramme zeigen den Ausschnitt eines konkreten dynamischen
Verhaltens. Sie sind somit recht volatil, da
hier bis zum Ende der Systementwicklung
mit Änderungen zu rechnen ist. Es ist
daher fragwürdig, ob sich hier der
Modellierungsaufwand lohnt oder ob Sequenzdiagramme besser nur als Whiteboard-Instrument zum besseren Verständnis und Herleiten von dynamischen
Aspekten geeignet sind.
Fazit?
Die UML 1.x ist komplex, hat unüberschaubar viele und teilweise redundante
38
39
Modellelemente, viele Konstrukte wurden
von Version zu Version geändert, einige
sind schlecht oder falsch erläutert, teilweise semantisch schwach oder fehlerhaft
spezifiziert und dennoch fehlen einige
wichtige Elemente. Wird die UML 2.0 sich
dieser Kritik entziehen können?
Die Neuauflage der UML ist nicht gerade klein geraten. Alleine die Superstruktur
umfasst bereits weit über 600 eng
bedruckte Seiten. In ihrer Gesamtheit wird
die UML 2.0 somit auch sehr komplex.
Für Projekte ist zu Beginn ein „Tailoring”
notwendig, um eine überschaubare
Projektversion der UML zu erhalten. Das
Anpassen an spezifische Bedürfnisse
(Profile, Stereotypen) ist in der UML 2.0
verbessert worden.
In der UML 2.0 werden viele neue
Konstrukte und Ideen dazugekommen,
von denen viele auf Anhieb nützlich
erscheinen, viele aber nur für spezielle
Anwendungsbereiche wichtig sind. Dabei
sollten domänen-spezifische Konstrukte
eigentlich nur in UML-Erweiterungen zu
finden sein. Timing-Diagramme sind beispielsweise der RTE-Domäne zuzuschreiben, sind aber dennoch Teil des neuen
Standards (vielleicht weil im U2-PartnerKonsortium bekannte RTE-Unternehmen
vertreten sind?).
Ein Teil des Umfangs ist sicherlich auf
die ausführlichere und sauberere formale
Spezifikation zurückzuführen und wird
viele UML-Anwender nicht direkt betreffen. Mit den neuen Diagrammtypen und
Modellelementen, von denen hier nur die
Spitze des Eisberges gezeigt wurde, wird
sich aber auch ein Großteil der gewöhnlichen UML-Anwender früher oder später
beschäftigen müssen.
Also wird es wieder eine Weile dauern,
bis die Praxis entschieden hat, mit welchen
20% der Konstrukte 80% der Modellierungsbedürfnisse abgedeckt werden. Als
ersten Schritt hierzu haben wir eine
Notationsübersicht für die wichtigsten
Elemente aus UML 2.0 zusammengestellt,
die unter www.oose.de/uml hinterlegt ist,
da sie den Rahmen dieses Artikels sprengen würde.
Im Moment ist die Herausarbeitung des
Kerns nicht so dringlich, da es noch eine
Weile dauern wird, bis die Hersteller von
UML-Werkzeugen die UML 2.0 adaptiert
haben. Dabei werden sicherlich auch zahlreiche Portierungsprobleme und Kinderkrankheiten auftreten, da gerade das
Metamodell und das Modelldatenaustauschformat von den Änderungen betroffen sind.
Für UML-Interessierte werden die nächsten Monate auf jeden Fall nicht langweilig.
■
Literatur & Links
[Dou98] B.P. Douglass, Real-Time
UML: developing efficient objects for
embedded systems, Addison-Wesley,
1998
[Oes01] B. Oestereich, Objektorientierte Softwareentwicklung, Analyse
und Design mit der UML, 5. Aufl.,
Oldenbourg Wissenschaftsverlag 2002
[OMG02-a] Object Management Group,
Unified Modeling Language: Superstructure, version 2 beta R1, Revised
submission, ad/2002-09-02
[OMG02-b] Object Management Group,
Unified Modeling Language: Infrastructure, version 2.0, Updated submission, ad/2002-09-01
[Sel94] B. Selic, G. Gullekson, P. T.
Ward, Real-Time Object-Oriented
Modeling, John Wiley & Sons, Inc.,
1994
[UML-a] UML 2.0-Glossar, siehe: http://
www.oose.de/uml/glossar
[UML-b] UML 2.0-Notationsübersicht,
siehe: http://www.oose.de/uml/notation
w w w. o b j e k t s p e k t r u m . d e

Download Report