27. Oktober 2005 Florian Marwede

Transkript

1 Ausgewählte Aspekte zur Einführung in UML und XMI 27. Oktober 2005 Florian Marwede Carl von Ossietzky Universität Oldenburg Fakultät II Department für Informatik Abteilung Entwicklung korrekter Systeme

2 Inhaltsverzeichnis 1 UML - Unified Modeling Language Einleitung Übersicht über die einzelnen Diagrammtypen Strukturdiagramme Verhaltensdiagramme Drei Diagrammtypen am Beispiel erläutert Kompositionsstrukturdiagramm Klassendiagramm Zustandsdiagramm Wesentliche Neuerungen in der UML XMI - XML Metadata Interchange Einleitung Ein Überblick über XML Ein Beispiel Literatur 9 Florian Marwede Oktober 2005

3 1 UML - Unified Modeling Language 1.1 Einleitung UML ist eine standardisierte Beschreibungssprache für Strukturen und Abläufe 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ächsten 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ägte 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 Übersicht über die einzelnen Diagrammtypen Strukturdiagramme Klassendiagramm (engl. class diagram): Ein Klassendiagramm beschreibt sogenannte Klassen bzw. Objekt-Klassen, also programmierte Vorbilder für zur Laufzeit aktive Software-Einheiten, die Objekte. Eine Klasse wird als Rechteck dargestellt und sie wird beschrieben durch Angaben über ihren Zustand und mögliche auf ihr durchführbaren Operationen. Den Zusammenhang zwischen mehreren Klassen kann man durch die Angabe von Relationen zwischen ihnen darstellen, welche durch verschiedene Pfeile und Linien ausgedrückt werden. Objektdiagramm (engl. object diagram): Objekte sind wie gesagt konkrete Instanzen und Objektdiagramme stellen somit Objekte und Relationen zwischen Objekten dar. Florian Marwede Oktober 2005

4 Komponentendiagramm (engl. component diagram): Komponentendiagramme stellen Software-Komponenten und deren Schnittstellen dar. Software- Komponenten stellen in sich geschlossene Module auf einer höheren Abstraktionsebende als Klassen und Objekte dar. Eine wesentliche Anforderung an Komponenten ist eine möglichst geringere Kopplung nach außen zu anderen Bausteinen des Systems und eine möglichst hohe Kohäsion in ihrem Inneren. Kompositionsstrukturdiagramm (engl. composite structure diagram): Mit einem Kompositiobsstrukturdiagramm lassen sich die inneren Zusammenhänge innerhalb bestimmter Elemente der UML darstellen. Wesentliche innere Bestandteile in einem Kompositionsdiagramm sind die sogenannten Parts, die definierte Rollen übernehmen. Welcher konkrete Software-Baustein diese Rolle dann tatsächlich übernimmt, wird hier nicht betrachtet. Verteilungsdiagramm (engl. deployment diagram): In einem Verteilungsdiagramm werden typischerweise die Zusammenhänge 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änge zwischen ihnen in einem Paketdiagramm darstellen. Obwohl dies der naheliegenste Anwendungsfall für diesen Diagrammtyp ist, lässt er sich viel allgemeiner einsetzen z.b. können auch Aktivitäten (siehe Aktivitätsdiagramm) in Paketen zusammengefasst werden und entsprechend auch mit dem Paketdiagramm dargestellt werden Verhaltensdiagramme Anwendungsfalldiagramm (use case diagram): Es zeigt eine bestimmte Sicht auf das erwartete Verhalten eines Systems und wird deshalb für die Spezifikation der Anforderungen an ein System eingesetzt. In einem Anwendungsfalldiagramm werden typischerweise Anwendungsfälle und Akteure mit ihren Abhängigkeiten und Beziehungen dargestellt. Zustandsdiagramm (engl. statechart): Das UML Zustandsdiagramm ist eines von vielen in der Informatik gebräuchlichen Notationsformen, um die Folge von Zuständen zu definieren, die ein Objekt einnehmen kann. Es werden hierfür alle Zustände, Zustandsübergänge und Bedingungen für und Konsequenzen von Zustandsübergängen in Form eines endlichen Automaten dargestellt. Aktivitätsdiagramm (engl. activity diagram): Mit einem Aktivitätsdiagramm wird häufig der Ablauf eines Anwendungsfalls beschrieben, eignet sich aber zur Modellierung aller Aktivitäten innerhalb eines Systems. Sequenzdiagramm (engl. sequence diagram): Ein Sequenzdiagramm ist eine graphische Darstellung einer Interaktion und spezifiziert den Austausch von Nach- Florian Marwede Oktober 2005

5 richten zwischen Ausprägungen, 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ägungen) aufgerufen werden. Interaktionsübersichtsdiagramm (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übersichtlich werden), können die wichtigsten Aktivitäten und Abläufe dieser Interaktion abstrakt in einem Interaktionsübersichtsdiagramm dargestellt werden. Teilinteraktionen, die sich aus diesem Diagramm ablesen lassen können, 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ägungen, die diese Nachrichten versenden, zueinander eine Zeitachse ist hier also nicht gegeben, dafür können die Symbole für die Ausprägungen so angeordnet werden, dass sie für die Darstellung am ü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ände darstellen. Dieser Diagrammtyp ähnelt damit der Anzeige eines Oszilloskops, wird also seit langem in der Elektrotechnik verwendet. 1.3 Drei Diagrammtypen am Beispiel erläutert Kompositionsstrukturdiagramm Abbildung 1 zeigt ein Kompositionsstrukturdiagramm für 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 diese 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ötigt. Hier können also Temperatursensoren andocken, um Temperaturdaten zu übermitteln. Diese werden wieder delegiert und zwar zum Part Data- Collector. Intern stellen der Logger und der Report-Generator Schnittstellen für den Data- Collector bereit, damit dieser ihnen Daten übermitteln kann. Florian Marwede Oktober 2005

6 Abbildung 1: Ein Kompositionsstrukturdiagramm am Beispiel einer Wetterstation Klassendiagramm Ein einfaches Beispiel für ein Klassendiagramm ist das Interface Tür welches die Schnittstelle für eine Türsteuerung beschreiben kann: Abbildung 2: Ein Klassendiagramm am Beispiel einer Türsteuerung Ein Interface in der UML ist ein vordefinierte Stereotyp für das Klassendiagramm, d.h. es wird die Definition das Klassendiagramm modifiziert und eingeschränkt. In diesem Fall ist die wesentliche Beschränkung das Verbieten von Attributen Zustandsdiagramm Es gibt zwei Arten von Zustandsdiagrammen: 1. Protokollzustandsdiagramm 2. Verhaltenszustandsdiagramm Das Verhaltenszustandsdiagramm stellt die Abfolge innerer Zustände eines Objektes dar, das Protokollzustandsdiagramm nur die einer Schnittstelle, diesem steht deshalb auch nur eine Untermenge der Notationsmöglichkeiten des Verhaltenszustandsdiagramm zu Verfügung. Abbildung 2 zeigt ein Protokollzustandsdiagramm für die Schnittstelle einer Türsteuerung. Florian Marwede Oktober 2005

7 Abbildung 3: Protokollzustandsdiagramm am Beispiel einer Türsteuerung Abbildung 3 zeigt ein Verhaltenszustandsdiagramm für eine Ampelsteuerung. Im Wesentlichen ist hier auch einer der auffälligsten Unterschiede zu den Protokollzustandsdiagrammen dargestellt: Die Möglichkeit, 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öst, 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ängig voneinander. Dadurch, dass es nun ein durchgängiges Metamodell für die UML gibt, soll es möglich sein, individuelle Anpassungen an der UML vorzunehmen, um z.b. Codegenerierung für 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ügt worden, um das Modellieren anwendungsnaher gestalten zu können. Florian Marwede Oktober 2005

8 Neue Notationen (CompositePart, Interaktionsübersicht, Zeitverlauf): Demselben Gedanken geschuldet sind neue Diagrammtypen, die gerade im Darstellen dynamischer Abläufe das Sequenzdiagramm entlasten sollen, welches nicht für alle Anwendungen hier optimal ausgelegt ist. 2 XMI - XML Metadata Interchange 2.1 Einleitung XMI gehört zur Sprachfamilie der extensible Markup Language (XMI), d.h. ein XMI- Dokument 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üfen, 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ür XMI womit die Brücke zwischen UML und XMI geschlagen ist. In einem XMI-Dokument werden also Objekte gespeichert, während in einem XMI- Schema festgelegt wird, wie diese Objekte auszusehen haben. Dies kann unter anderem beliebig konkret ausgedrückt werden. Zum Beispiel kann festgelegt werden, dass alle Objekte keine Attribute haben dürfen, oder dass sie generell welche haben dürfen. Aber auch, dass sie z.b. nur eine bestimmte Anzahl eines bestimmten Typs haben dürfen usw. 2.2 Ein Überblick über XML Die allgemeine Form eines XML-Element ist: <Name Attribute>Inhalt</Name> Ein XML-Element besteht mindestens aus einem sogenannten Tag: <Name/>. Hat dieser Tag einen Inhalt, wird er in zwei Tags aufgespalten, einen öffnenden und einen schließenden Tag: <Name>Hallo Welt</Name>. Attribute sind eine optionale Liste von Name-Wert-Paaren: <Name farbe="rot">hallo Welt</Name>. XML-Elemente können 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ötig, um XML-Dokumente verstehen zu können: Es gibt Namensräume, in denen Namen eindeutig sein müssen, Regeln, die definieren, was für Zeichen in Namen vorkommen dürfen und eine Möglichkeit, Tags als plain text zu schreiben, also uninterpretiert zu lassen. XML-Schemata jedoch haben viele weitere Syntaxelemente diese zu erklären, ist nicht Ziel dieses Abschnitts. Es sei nur soviel gesagt, dass XML-Schemata auch XML- Dokumente in dem Sinne sind, dass sie der grundlegenden XML-Syntax (die eben Florian Marwede Oktober 2005

9 angedeutet beschrieben wurde) folgt. Jedoch gibt es hier viele definierte Element- und Attributnamen mit einer festgelegten Semantik. Schließlich sei noch erwähnt, dass die sogenannten Document Type Definitions (DTDs) eine veraltete Möglichkeit 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önnen, sind Grundkenntnisse der XML- Schemadefinitionen notwendig. Diese können direkt an der Quelle unter erworben und vertieft werden. Nehmen wir an, es soll eine Anwendung für 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ürde dieses Klassendiagramm nach XMI importiert, könnte der entsprechende Code so aussehen: <xsd:complextype name="car"> <xsd:element name="available" type="xsd:boolean"/> <xsd:element minoccurs="0" maxoccurs="unbounded" ref="xmi:extension"/> </xsd:complextype> Eine Klasse wird immer als complextype definiert. In einem complextype-element, ist es möglich, durch ein element-element, ein Attribut der Klasse anzugeben. Mit minoccurs und minoccurs kann man Unter- und Obergrenzen festlegen, wieviele solcher Elemente auftauchen dürfen. Die default-werte für beides sind 1, können 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: <Car> <available>true</available> </Car> 3 Literatur Timothy J. Grose, Gary C. Doney, Stephen A. Brodsky: Mastering XMI. Wiley Torsten Posch, Klaus Birken, Michael Gerdom: Basiswissen Softwarearchitektur. Dpunkt Florian Marwede Oktober 2005