Ausgew¨ahlte Aspekte zur Einfu¨hrung in UML und XMI 27. Oktober 2005

Florian Marwede Carl von Ossietzky Universit¨at Oldenburg Fakult¨at II Department f¨ur Informatik Abteilung Entwicklung korrekter Systeme

Ausgew¨ahlte Aspekte zur Einf¨ uhrung in UML und XMI

Projektgruppe Syspect

Inhaltsverzeichnis 1 UML - Unified Modeling Language 1.1 Einleitung . . . . . . . . . . . . . . . . . . . ¨ 1.2 Ubersicht u ¨ber die einzelnen Diagrammtypen 1.2.1 Strukturdiagramme . . . . . . . . . . 1.2.2 Verhaltensdiagramme . . . . . . . . . 1.3 Drei Diagrammtypen am Beispiel erl¨autert . 1.3.1 Kompositionsstrukturdiagramm . . . 1.3.2 Klassendiagramm . . . . . . . . . . . 1.3.3 Zustandsdiagramm . . . . . . . . . . 1.4 Wesentliche Neuerungen in der UML 2.0 . .

. . . . . . . . .

3 3 3 3 4 5 5 6 6 7

2 XMI - XML Metadata Interchange 2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ 2.2 Ein Uberblick u ¨ber XML . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Ein Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 8 8 9

3 Literatur

9

Florian Marwede

2

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

27. Oktober 2005

Ausgew¨ahlte Aspekte zur Einf¨ uhrung in UML und XMI

1

Projektgruppe Syspect

UML - Unified Modeling Language

1.1

Einleitung

UML ist eine standardisierte Beschreibungssprache f¨ ur Strukturen und Abl¨aufe in objektorientierten Softwaresystemen und wurde ab Ende 1997 von der Object Management Group (OMG) entwickelt. Sie ist also eine Sammlung grafischer Notationsweisen, die in zwei Bereiche aufgeteilt ist: 1. Strukturdiagramme, um statische Aspekte darzustellen 2. Verhaltensdiagramme, um dynamische Aspekte darzustellen Die einzelnen Diagrammtypen, die sich den beiden Bereichen zuordnen lassen, werden im n¨achsten Kapitel dargestellt. UML wird durch ein Metamodel, die Meta Object Facility (MOF) definiert; diese wird im Wesentlichen durch vier Abstraktionsebenen beschrieben: • M0-Ebene: Konkret. Ausgepr¨agte Daten. • M1-Ebene: Modelle. Z.B. physikalische oder logische Daten-, Prozess- oder UMLbzw. Objekt-Modelle, die die Daten der M0-Ebene definieren. • M2-Ebene: Meta-Modelle. Definieren, wie die Modelle aufgebaut und strukturiert sind. • M3-Ebene: Meta-Meta-Modelle (bzw. MOF-Ebene). Abstrakte Ebene, die zur Definition der M2-Ebene herangezogen wird.

1.2 1.2.1

¨ Ubersicht u ¨ ber die einzelnen Diagrammtypen Strukturdiagramme

• Klassendiagramm (engl. class diagram): Ein Klassendiagramm beschreibt sogenannte Klassen bzw. Objekt-Klassen, also programmierte Vorbilder“ f¨ ur zur Lauf” zeit aktive Software-Einheiten, die Objekte. Eine Klasse wird als Rechteck dargestellt und sie wird beschrieben durch Angaben u uhrbaren Operationen. Den ¨ber ihren Zustand und m¨ogliche auf ihr durchf¨ Zusammenhang zwischen mehreren Klassen kann man durch die Angabe von Relationen zwischen ihnen darstellen, welche durch verschiedene Pfeile und Linien ausgedr¨ uckt werden. • Objektdiagramm (engl. object diagram): Objekte sind – wie gesagt – konkrete Instanzen und Objektdiagramme stellen somit Objekte und Relationen zwischen Objekten dar.

Florian Marwede

3

27. Oktober 2005

Ausgew¨ahlte Aspekte zur Einf¨ uhrung in UML und XMI

Projektgruppe Syspect

• Komponentendiagramm (engl. component diagram): Komponentendiagramme stellen Software-Komponenten und deren Schnittstellen dar. SoftwareKomponenten stellen in sich geschlossene Module auf einer h¨oheren Abstraktionsebende als Klassen und Objekte dar. Eine wesentliche Anforderung an Komponenten ist eine m¨oglichst geringere Kopplung nach außen zu anderen Bausteinen des Systems und eine m¨oglichst hohe Koh¨asion in ihrem Inneren. • Kompositionsstrukturdiagramm (engl. composite structure diagram): Mit einem Kompositiobsstrukturdiagramm lassen sich die inneren Zusammenh¨ange innerhalb bestimmter Elemente der UML darstellen. Wesentliche innere Bestandteile in einem Kompositionsdiagramm sind die sogenannten Parts, die definierte Rollen u ¨bernehmen. Welcher konkrete Software-Baustein diese Rolle dann tats¨achlich u ¨bernimmt, wird hier nicht betrachtet. • Verteilungsdiagramm (engl. deployment diagram): In einem Verteilungsdiagramm werden typischerweise die Zusammenh¨ange zwischen Hard- und Software eines Systems dargestellt, also z.B. welche Teile der Software auf welchen Servern untergebracht werden. • Paketdiagramm (engl. package diagram): Wenn in der Software Klassen zu Paketen zusammengefasst sind, lassen sich diese und die Zusammenh¨ange zwischen ihnen in einem Paketdiagramm darstellen. Obwohl dies der naheliegenste Anwendungsfall f¨ ur diesen Diagrammtyp ist, l¨asst er sich viel allgemeiner einsetzen – z.B. k¨onnen auch Aktivit¨aten (siehe Aktivit¨atsdiagramm) in Paketen zusammengefasst werden und entsprechend auch mit dem Paketdiagramm dargestellt werden. 1.2.2

Verhaltensdiagramme

• Anwendungsfalldiagramm (use case diagram): Es zeigt eine bestimmte Sicht auf das erwartete Verhalten eines Systems und wird deshalb f¨ ur die Spezifikation der Anforderungen an ein System eingesetzt. In einem Anwendungsfalldiagramm werden typischerweise Anwendungsf¨alle und Akteure mit ihren Abh¨angigkeiten und Beziehungen dargestellt. • Zustandsdiagramm (engl. statechart): Das UML Zustandsdiagramm ist eines von vielen in der Informatik gebr¨auchlichen Notationsformen, um die Folge von Zust¨anden zu definieren, die ein Objekt einnehmen kann. Es werden hierf¨ ur alle Zust¨ande, Zustands¨ uberg¨ange und Bedingungen f¨ ur und Konsequenzen von Zustands¨ uberg¨angen in Form eines endlichen Automaten dargestellt. • Aktivit¨atsdiagramm (engl. activity diagram): Mit einem Aktivit¨atsdiagramm wird h¨aufig der Ablauf eines Anwendungsfalls beschrieben, eignet sich aber zur Modellierung aller Aktivit¨aten innerhalb eines Systems. • Sequenzdiagramm (engl. sequence diagram): Ein Sequenzdiagramm ist eine graphische Darstellung einer Interaktion und spezifiziert den Austausch von Nach-

Florian Marwede

4

27. Oktober 2005

Ausgew¨ahlte Aspekte zur Einf¨ uhrung in UML und XMI

Projektgruppe Syspect

richten zwischen Auspr¨agungen, die im Diagramm als Lebenslinien dargestellt sind. Zum Beispiel ist der Aufruf einer Java-Methode in diesem Sinne eine Sequenz, da nacheinander weitere Methoden (Nachrichten) von verschiedenen Objekten (Auspr¨agungen) aufgerufen werden. • Interaktions¨ ubersichtsdiagramm (engl. interaction overview diagram): Ist eine Interaktion zu komplex, um beispielsweise in einem Sequenzdiagramm dargestellt zu werden (da diese bei zuvielen Lebenslinien und Nachrichten zu un¨ ubersichtlich werden), k¨onnen die wichtigsten Aktivit¨aten und Abl¨aufe dieser Interaktion abstrakt in einem Interaktions¨ ubersichtsdiagramm dargestellt werden. Teilinteraktionen, die sich aus diesem Diagramm ablesen lassen k¨onnen, sind dann wieder als Sequenzdiagramm darstellbar. • Kommunikationsdiagramm (engl. communication diagram): Kommunikationsdiagramme stellen ebenso wie Sequenzdiagramme Interaktionen mit ihren versendeten Nachrichten dar, doch liegt hier nicht der Schwerpunkt auf der Reihenfolge der versendeten Nachrichten, sondern auf den Relationen der Auspr¨agungen, die diese Nachrichten versenden, zueinander – eine Zeitachse ist hier also nicht gegeben, daf¨ ur k¨onnen die Symbole f¨ ur die Auspr¨agungen so angeordnet werden, dass sie f¨ ur die Darstellung am u ¨bersichtlichsten sind. • Zeitverlaufsdiagramm (engl. timing diagram): Zeitverlaufsdiagramme sind zweidimensionale Diagramme, bei denen die X-Achse die Zeit, und die Y-Achse Objekte (im weitesten Sinne) und deren Zust¨ande darstellen. Dieser Diagrammtyp ¨ahnelt damit der Anzeige eines Oszilloskops, wird also seit langem in der Elektrotechnik verwendet.

1.3 1.3.1

Drei Diagrammtypen am Beispiel erl¨ autert Kompositionsstrukturdiagramm

Abbildung 1 zeigt ein Kompositionsstrukturdiagramm f¨ ur einen Software-Baustein Wetterstation“. Diese hat drei Parts, also innere Bausteine: einen Logger, einen Report” Generator und einen Data-Collector. Der Baustein besitzt außerdem einen komplexen Port, der die beiden Schnittstellen Anfrage“ und Report“ bereitstellt. Werden die” ” se Schnittstellen verwendet, wird dies nach innen delegiert, d.h. die Anfrage“ wird ” an den Logger und der Report“ an den Report-Generator delegiert, die jeweils eine ” entsprechende Schnittstelle bereitstellen. Nach demselben Prinzip hat der Baustein Wetterstation einen Port, der die Schnittstelle Temperatur ben¨otigt. Hier k¨onnen also Temperatursensoren andocken“, um Tempe” raturdaten zu u ¨bermitteln. Diese werden wieder delegiert und zwar zum Part Data” Collector.“ Intern stellen der Logger“ und der Report-Generator“ Schnittstellen f¨ ur den Data” ” ” Collector“ bereit, damit dieser ihnen Daten u ¨bermitteln kann.

Florian Marwede

5

27. Oktober 2005

Ausgew¨ahlte Aspekte zur Einf¨ uhrung in UML und XMI

Projektgruppe Syspect

Abbildung 1: Ein Kompositionsstrukturdiagramm am Beispiel einer Wetterstation 1.3.2

Klassendiagramm

Ein einfaches Beispiel f¨ ur ein Klassendiagramm ist das Interface T¨ ur“ welches die ” Schnittstelle f¨ ur eine T¨ ursteuerung beschreiben kann:

Abbildung 2: Ein Klassendiagramm am Beispiel einer T¨ ursteuerung Ein Interface in der UML ist ein vordefinierte Stereotyp f¨ ur das Klassendiagramm, d.h. es wird die Definition das Klassendiagramm modifiziert und eingeschr¨ankt. In diesem Fall ist die wesentliche Beschr¨ankung das Verbieten von Attributen. 1.3.3

Zustandsdiagramm

Es gibt zwei Arten von Zustandsdiagrammen: 1. Protokollzustandsdiagramm 2. Verhaltenszustandsdiagramm Das Verhaltenszustandsdiagramm stellt die Abfolge innerer Zust¨ande eines Objektes dar, das Protokollzustandsdiagramm nur die einer Schnittstelle, diesem steht deshalb auch nur eine Untermenge der Notationsm¨oglichkeiten des Verhaltenszustandsdiagramm zu Verf¨ ugung. Abbildung 2 zeigt ein Protokollzustandsdiagramm f¨ ur die Schnittstelle einer T¨ ursteuerung.

Florian Marwede

6

27. Oktober 2005

Ausgew¨ahlte Aspekte zur Einf¨ uhrung in UML und XMI

Projektgruppe Syspect

Abbildung 3: Protokollzustandsdiagramm am Beispiel einer T¨ ursteuerung Abbildung 3 zeigt ein Verhaltenszustandsdiagramm f¨ ur eine Ampelsteuerung. Im Wesentlichen ist hier auch einer der auff¨alligsten Unterschiede zu den Protokollzustandsdiagrammen dargestellt: Die M¨oglichkeit, eine Art Unterautomaten“ darzustellen: ” Beim Ereignis start geht das Objekt vom Zustand aus in den Zustand bereit bzw. bereit.rot, weil rot der Initialzustand von bereit ist. Ist das Objekt im Zustand bereit“ ” – gleich in welchem Unterzustand –, und wird das Ereignis stop ausgel¨ost, geht das Objekt wieder in den Zustand aus.

Abbildung 4: Verhaltenszustandsdiagramm am Beispiel einer Ampelsteuerung

1.4

Wesentliche Neuerungen in der UML 2.0

• Konsolidierung des Metamodels: MOF und UML waren vorher unabh¨angig voneinander. Dadurch, dass es nun ein durchg¨angiges Metamodell f¨ ur die UML gibt, soll es m¨oglich sein, individuelle Anpassungen an der UML vorzunehmen, um z.B. Codegenerierung f¨ ur bestimmte Anwendungsgebiete zu erleichtern. • Neue Konzepte (Parts, Ports, Konnektoren, Interaktion): Aufgrund der Erfahrungen, die mit der UML 1.* gemacht wurden, sind einige neue Aspekte hinzugef¨ ugt worden, um das Modellieren anwendungsnaher gestalten zu k¨onnen. Florian Marwede

7

27. Oktober 2005

Ausgew¨ahlte Aspekte zur Einf¨ uhrung in UML und XMI

Projektgruppe Syspect

• Neue Notationen (CompositePart, Interaktions¨ ubersicht, Zeitverlauf): Demselben Gedanken geschuldet sind neue Diagrammtypen, die gerade im Darstellen dynamischer Abl¨aufe das Sequenzdiagramm entlasten sollen, welches nicht f¨ ur alle Anwendungen hier optimal ausgelegt ist.

2 2.1

XMI - XML Metadata Interchange Einleitung

XMI geh¨ort zur Sprachfamilie der eXtensible Markup Language (XMI), d.h. ein XMIDokument ist immer auch ein XML-Dokument, und ein XMI-Schema ist immer auch ein XML-Schema. In einem XML-Dokument werden Daten gespeichert, in einem XML-Schema wird festgelegt, wie diese Daten auszusehen haben. Man kann also XML-Dokumente gegen XML-Schema laufen lassen“, um zu pr¨ ufen, dass ihre Daten die korrekte Form, das ” korrekte Format haben. XMI ist eine Spezialisierung hiervon. Bei XMI geht es nicht allgemein um Daten, sondern um Objekte bzw. um das, was in der Informatik unter Objekt verstanden wird. Genauer: Was in der MOF unter dem Begriff verstanden wird, denn dies ist das Metamodell f¨ ur XMI – womit die Br¨ ucke zwischen UML und XMI geschlagen ist. In einem XMI-Dokument werden also Objekte gespeichert, w¨ahrend in einem XMISchema festgelegt wird, wie diese Objekte auszusehen haben. Dies kann unter anderem beliebig konkret ausgedr¨ uckt werden. Zum Beispiel kann festgelegt werden, dass alle Objekte keine Attribute haben d¨ urfen, oder dass sie generell welche haben d¨ urfen. Aber auch, dass sie z.B. nur eine bestimmte Anzahl eines bestimmten Typs haben d¨ urfen usw.

2.2

¨ Ein Uberblick u ¨ ber XML

Die allgemeine Form eines XML-Element ist: Inhalt Ein XML-Element besteht mindestens aus einem sogenannten Tag: . Hat dieser Tag einen Inhalt, wird er in zwei Tags aufgespalten“, einen ¨offnenden und einen ” schließenden Tag: Hallo Welt. Attribute sind eine optionale Liste von Name-Wert-Paaren: Hallo Welt. XML-Elemente k¨onnen baumartig ineinander verschachtelt werden, wobei der schließende Tag eines inneren Elements nie nach dem schließenden Tag des dieses Element umschließenden Tags kommen darf. Außerdem ist nicht viel n¨otig, um XML-Dokumente verstehen zu k¨onnen: Es gibt Namensr¨aume, in denen Namen eindeutig sein m¨ ussen, Regeln, die definieren, was f¨ ur Zeichen in Namen vorkommen d¨ urfen und eine M¨oglichkeit, Tags als plain text zu schreiben, also uninterpretiert zu lassen. XML-Schemata jedoch haben viele weitere Syntaxelemente – diese zu erkl¨aren, ist nicht Ziel dieses Abschnitts. Es sei nur soviel gesagt, dass XML-Schemata auch XMLDokumente in dem Sinne sind, dass sie der grundlegenden XML-Syntax (die eben Florian Marwede

8

27. Oktober 2005

Ausgew¨ahlte Aspekte zur Einf¨ uhrung in UML und XMI

Projektgruppe Syspect

angedeutet beschrieben wurde) folgt. Jedoch gibt es hier viele definierte Element- und Attributnamen mit einer festgelegten Semantik. Schließlich sei noch erw¨ahnt, dass die sogenannten Document Type Definitions (DTDs) eine veraltete M¨oglichkeit sind, die Struktur und das Format von XML-Dokumenten festzulegen. Sie haben wieder eine eigene Syntax, die nicht auf XML aufbaut.

2.3

Ein Beispiel

Um mit XMI sinnvoll arbeiten zu k¨onnen, sind Grundkenntnisse der XMLSchemadefinitionen notwendig. Diese k¨onnen – direkt an der Quelle – unter http://www.w3.org/XML/Schema erworben und vertieft werden. Nehmen wir an, es soll eine Anwendung f¨ ur eine Autovermietung modelliert werden und in einem dabei geschaffenen Klassendiagramm gibt es eine Klasse Car. Diese soll einfach nur ein Attribut available vom Typ boolean haben. W¨ urde dieses Klassendiagramm nach XMI importiert, k¨onnte der entsprechende Code so aussehen: Eine Klasse wird immer als complexType definiert. In einem complexType-Element, ist es m¨oglich, durch ein element-Element, ein Attribut der Klasse anzugeben. Mit minOccurs und minOccurs kann man Unter- und Obergrenzen festlegen, wieviele solcher Elemente auftauchen d¨ urfen. Die default-Werte f¨ ur beides sind 1“, k¨onnen also im Fall ” von unserem Attribut available weggelassen werden. Wir sehen aber auch, dass dieser complexType null oder beliebig viele sogenannte extensions haben kann. Dies dient dem Zweck, tool-spezifische Informationen zu speichern, also z.B. Angaben, an welcher Stelle die entsprechende Klasse im Diagramm eingezeichnet war. Folgendes XML-Dokument ist also korrekt im Sinne dieses Schemas: true

3

Literatur • Timothy J. Grose, Gary C. Doney, Stephen A. Brodsky: Mastering XMI. Wiley 2002. • Torsten Posch, Klaus Birken, Michael Gerdom: Basiswissen Softwarearchitektur. Dpunkt 2004.

Florian Marwede

9

27. Oktober 2005