Wendrich InformatikIhr Partner für komplette Lösungen mit Microsoft Standardsoftware |
 |
|
|
Zum Seminar 1917 "Objektorientierter Softwareentwurf" LG Praktische Informatik III 20.07.98 Unified Modeling Language (UML)Ausarbeitung Autor: Volker Wendrich Inhaltsverzeichnis Abbildungsverzeichnis 1. Abstract
Zur Bewältigung der Entwicklungsproblematik von Software
sind Hilfsmittel unbedingt notwendig. Grafische Notationen zur
Modellierung (Darstellung der Systeme als Diagramme) sind ein
solches Hilfsmittel. UML ist der Standard der OMG (Object Management
Group). Aufgrund der Standardisierung entfallen Diskussionen über
den besten Standard, und Entwürfe werden austauschbar. In
diesem Bericht liegt der Schwerpunkt auf den Aufgaben der Teilmodelle
und Beispielen zur Notation. Dadurch soll der Leser einen Eindruck
von der Komplexität der Modelle erhalten und eine Vorstellung
bekommen, wie Systeme mit UML modelliert werden. 2. Geschichtliche Einführung
Anfang der 90-er Jahre gab es konkurrierende OOA/ OOD-Methoden
wie Coad/ Yourdon, Rumbaugh und Shlaer/Mellor. 1996 wurden u.a.
die Entwurfssprachen von Booch (OOD), Rumbaugh (OMT), Jacobson
(OOSE) und Harel (Statecharts) zur grafischen Notation UML vereinigt.
Im Januar 1997 wurden Vorschläge zu UML 1.0 bei der OMG zur
Standardisierung angemeldet. Heute ist UML 1.1 ein einheitlicher
Standard. Dieser wird zur Zeit noch um eine Beschreibung zum methodischen
Vorgehen ergänzt. 3. AllgemeinesWie schon gesagt, ist die UML bisher nur eine grafische Notation, enthält also noch nicht die Beschreibung zum methodischen Vorgehen einer "Methode". Diese Lücke soll in Anlehnung an das "Objectory" nach Jacobson geschlossen und noch 1998 standardisiert werden. Mit der UML kann ein Analyse-, ein Entwurfs- und ein Implementationsmodell erstellt werden. Die UML besteht aus Teilmodellen, die zu den verschiedenen Entwicklungsphasen gehören und dynamisches Verhalten und/oder statische Beziehungen zeigen. Die Modelle werden neben der Notation, die in diesem Bericht noch am Beispiel eines fiktiven Bibliothekssystems erläutert wird, auch durch ein Metamodell spezifiziert. Das folgende Beispiel soll diesen Begriff erklären: Eine Klasse besitze mehrere Methoden. Dem entsprechen im Metamodell ein Objekt der Metaklasse "Class" und mehrere Objekte der Metaklasse "Method". Zwischen diesen Objekten muß aufgrund des Metamodell eine 1:n Beziehung bestehen.
Die Entwicklung mit UML kann durch Werkzeuge unterstützt
werden. Dadurch können Verknüpfungen und Konsistenzprüfungen
zwischen den Modellelementen realisiert werden, beispielsweise
kann ein und dieselbe Methode in mehreren Diagrammen vorkommen.
Aufgrund der internen Verknüpfung muß die genaue Spezifikation
der Methode nur einmal gespeichert sein und kann daher nicht inkonsistent
geändert werden. Für die einzelnen Modellelemente bietet
der UML Standard oft mehrere Darstellungsoptionen. Bei Benutzung
eines Werkzeugs ist man meist auf eine bestimmte der möglichen
Optionen eingeschränkt. 4. Modellkategorisierung nach EntwicklungsphasenIm folgenden werden die einzelnen Modelle der UML strukturiert und im Rahmen eines möglichen Entwurfsprozess gezeigt. Dieser vereinfachte Prozeß besteht in der Erstellung eines Analysemodells und mehrerer Entwurfsmodelle, die sukzessive alle Anwendungsfälle des Analysemodells abdecken. Daneben kann ein physikalisches Modell erstellt werden. Natürlich kann es vorkommen, daß das Analysemodell später geändert werden muß, was zur Folge hat, daß auch der Entwurf neu zu schreiben ist. Die folgende Gliederung zeigt die Struktur des idealisierten Prozesses:
Das physikalische Modell ist nach Meinung des Autors zur Bewältigung
der Softwareproblematik nicht so wichtig wie das logische Modell.
Auch Martin Fowler behandelt es is seinem
Buch nur kurz am Ende. Daher wird es in diesem Bericht nicht genauer
vorgestellt. Die Einhaltung einer formalen Modellsyntax ist bei
komplexen verteilten Systemen wichtig, um diese möglichst
verständlich zu beschreiben. 5. Ziele der ModelleDie Modelle sollen für viele Systeme, die ganz unterschiedlich aufgebaut sein können, einsetzbar sein, aber dennoch nicht zu viele Elemente umfassen, damit man leichter damit umgehen kann. Heutzutage ist beispielsweise häufig die Darstellbarkeit von Parallelität nötig. Die Modelle sollen konsistent sein und die wesentlichen Aspekte des zu entwickelnden Systems abdecken. Da die genannten Ziele sich widersprechen, haben die Entwickler von UML benutzerdefinierte Erweiterungsmöglichkeiten vorgesehen. Wenn davon zu stark Gebrauch gemacht wird, kann die Austauschbarkeit der Entwürfe darunter leiden. Ein wichtiges Entwicklungsziel ist die Zuordnung von Verantwortlichkeit ("Objektsicht").
Auf den folgenden Seiten werden jetzt die einzelnen Diagramme
des logischen Modells anhand von Beispielen zum bereits oben erwähnten
fiktiven Bibliothekssystem vorgestellt. 6. AnwendungsfallmodellAbbildung 1: Anwendungsfalldiagramm
Elemente des Anwendungsfallmodells sind
Akteure, Anwendungsfälle, Benutzungs- und Erweiterungsbeziehungen.
Ein Anwendungsfall beschreibt immer einen kompletten Vorgang aus
Benutzersicht. Die dazu erforderlichen Teilschritte, wie beispielsweise
einzelne Mausklicke, sind keine Anwendungsfälle. Das Anwendungsfallmodell
dient der Feststellung der Anforderungen und findet zur Planung
des Entwicklungsprozesses Verwendung. Es stellt noch keine Objekte
dar. Abbildung 1 zeigt als
Beispiel drei Anwendungsfälle
des Bibliothek-Systems und zwei Akteure,
welche mit dem System kommunizieren. Das große Rechteck
stellt die Systemgrenze
dar. Die Abbildung zeigt auch die benutzt-
und die erweitert-Beziehung.
Beide lagern Vorgänge aus und sind daher leicht zu verwechseln.
Typisch für die erweitert-Beziehung ist die Erstellung eigener
Anwendungsfälle für besondere Situationen, um den ursprünglichen
Anwendungsfall nicht zu überlasten. Typisch für die
benutzt-Beziehung ist erstens, gemeinsames Verhalten mehrerer
Anwendungsfälle zusammenzufassen. Zweitens kommunizieren
die Akteure häufig nicht mit solchen ausgegliederten Teilen:
Z. B. kommt der Kunde nicht extra in die Bibliothek, um seine
Daten aufnehmen zu lassen, sondern dies geschieht beim erstmaligen
Ausleihen eines Buches. 7. AktivitätsdiagrammAbbildung 2: Aktivitätsdiagramm
Das Aktivitätsdiagramm ist eines der beiden Zustandsdiagramme von UML. Die Abbildung 2 zeigt die Darstellung der Zustände in abgerundeten Rechtecken. Ein wesentlicher Unterschied zum später behandelten, auch ebenso genannten "Zustandsdiagramm" ist, daß hier die Übergänge durch das "Abarbeiten" der "Aktivitäten", dort jedoch durch "Ereignisse" (events) ausgelöst werden. Das Aktivitätsdiagramm hat meist die Aufgabe, einen Anwendungsfall für die Analyse, seltener eine Methode für den Entwurf, zu beschreiben. Es kann auch, wie hier, den Ablauf über mehrere Anwendungsfälle hinweg darstellen (engl. workflow). Die Abbildung 2 zeigt die beiden Anwendungsfälle "Buchausleihe" (Start links) und "Buchrückgabe" (Start rechts).
Mit Hilfe des Stern-Operators kann eine Schleife
angezeigt, und durch eckige Klammern können Bedingungen
und Fallunterscheidungen dargestellt werden. Parallele Abläufe
stellt das Aktivitätsdiagramm im Gegensatz zu einem reinen
Flußdiagramm sehr anschaulich dar. Die waagerechte Linie
unten rechts ist ein Synchronisationsbalken.
Wie bei einem Petri-Netz kann die Verarbeitung nur fortfahren,
wenn sie von beiden Eingangsflüssen her abgeschlossen ist.
Daß es sich hierbei um dasselbe Buchobjekt handeln muß,
ist jedoch nicht ganz klar. Auch die Zuordnung der Aktivitäten
zu Objekten ist nicht vorhanden. Durch Linien im Diagramm, "Verantwortungsgrenzen"
(engl. swimlanes) genannt, kann dies abgemildert werden. Andererseits
ist die Objektsicht bei der Analyse noch nicht so wichtig.
8. Klassendiagramme8.1 SichtweisenKlassendiagramme stellen rein statische Beziehungen dar. Sie können für Analyse, Entwurf und Implementation verwendet werden. Martin Fowler nennt das die konzeptionelle, spezifizierende und implementierende Sichtweise. UML selbst hat nur ein Modell für alle drei Phasen. Die beiden vom Autor getesteten Tools unterstützen dementsprechend keine Trennung der Sichtweisen. Es besteht daher die Gefahr der Verwässerung dieser Unterscheidung und des verfrühten Denkens in der Implementationssicht. Die Analyse stellt Realweltobjekte dar. Hierfür gibt es Regeln wie "welche Objekte kann man anfassen?" und "versuche nicht, ein anderes Modell, wie z. B. ein Papiermodell, nachzumodellieren" (Beispiel zur zweiten Regel: Eine gedruckte Rechung sollte kein Realweltobjekt sein). Aus solchen Regeln ergeben sich dann Objekte und Assoziationen zwischen ihnen. Im Modell sollten auch einige wichtige Attribute und Methoden gezeigt sein. Damit ergibt sich eher ein Skelett (die Knochen sind detailliert dargestellt, aber das Fleisch fehlt), als eine "abstrakte" Darstellung. Zusätzlich können mit UML Bedingungen angegeben werden. Der Entwurf betont die Schnittstellen der Klassen. Zur Darstellung von Verantwortlichkeiten mittels Klassenkarten gibt es keine besondere UML-Syntax. Es ist möglich, die kompletten Methodensignaturen in das Modell aufzunehmen. Typisch für die spezifizierende Sichtweise sind auch Interfaces, da sie die Schnittstelle von der Implementierung trennen. Die Implementation kann schließlich 1:1 in ein Programm umgesetzt werden. Manche Darstellungselemente sind nur für bestimmte Sichtweisen vorgesehen. Beispielsweise ergibt die später erklärte Navigierbarkeit in konzeptionellen Klassendiagrammen keinen Sinn.
Abbildung 3: Klassendiagramm
1 8.2 Klassen und ObjekteAbbildung 3 zeigt die Darstellung von Klassen, Objekten, Attributen und Methoden. Klassen und Objekte sind durch Rechtecke dargestellt. Diese Rechtecke sind in Gebiete (engl. compartments) für den Namen, die Attribute und die Methoden gegliedert, wobei nur das name-compartment immer gezeigt werden muß. Objekte werden durch Unterstreichen des Namens dargestellt (im Beispiel: Drucker ist ein Objekt, die anderen Rechtecke stellen Klassen dar). Klassen und Objekte haben also beide Rechteck-Symbole. Objektdiagramme sind ein Grenzfall von Klassendiagrammen, der nur Objekte enthält. Ein Objekt kann auch mit der, ebenfalls unterstrichenen, Schreibweise <Objektname>:<Klassenname> benannt werden, wenn gleichzeitig gezeigt werden soll, zu welcher Klasse es gehört. Sichtbarkeit
Die Pluszeichen in Abbildung 5
bedeuten die "public" Sichtbarkeit,
während die Minuszeichen "private" bedeuten. Neben
Attributen und Methoden können auch die im Folgeabschnitt
erklärten Assoziationsrollen eine Sichtbarkeit haben. Letztere
entspricht der Sichtbarkeit der Referenz und hat die gleiche Bedeutung
wie die Sichtbarkeit von Attributen. (Referenzen auf andere Objekte
zur Implementierung von Assoziationen werden normalerweise nicht
zusammen mit den eigentlichen Attributen gezeigt, gehören
aber zu den Daten des Objekts und haben daher auch eine Sichtbarkeit.)
Die öffentliche Sichtbarkeit für Attribute impliziert
beim Entwurfsmodell Zugriffsfunktionen auf das Attribut, im Implementationsmodell
bedeutet sie jedoch ein Speicherfeld.
Abbildung 5 zeigt ferner
ein statisches
Attribut ("kundenzahl" = unterstrichen gezeichnetes
Attribut der Klasse). 8.3 AssoziationenAbbildung 3 zeigt auch Assoziationen. Diese können einen Assoziationsnamen wie "leiht" haben. Der Pfeil bei "leiht" bedeutet, daß die Assoziation wie "Kunde leiht Buch" gelesen werden muß. Die Zahlen an den Linienenden sind Kardinalitäten. Der Stern bedeutet "beliebig viele".
Abbildung 4: Aggregation und Komposition
Weitere, spezielle Assoziationen, sind die in Abbildung 4 gezeigten Aggregations- und Kompositionsbeziehungen. Aggregation und Komposition:Abbildung 4 zeigt mit Hilfe des Pfeilsymbols mit der weißen Raute als Spitze die Beziehung der Aggregation an: Die Kartei ist eine Aggregation von Kunden. Es handelt sich hierbei um eine gerichtete Objektbeziehung, wobei es aber keine vordefinierten Symbole für Konstruktionen, Behälter und logische Zusammenschlüsse gibt, wie es im Kurs SW-Engineering II gezeigt wurde. Diese Unterscheidung könnte zwar durch Stereotypen angezeigt werden, dies ist dann aber nicht genormt. Außerdem ist durch die Raute des Aggregationspfeils die Navigierbarkeit in einer Richtung nicht mehr anzeigbar. Die Definition der Aggregation ist nicht sehr genau, es wird sogar empfohlen, sich jeweils eine eigene Interpretation für ein Projekt zu definieren. Die Interpretation des Autors ist die Zugehörigkeit der Teile zu genau einem Ganzen und die Löschverantwortung des Ganzen für seine Teile. Navigierbarkeit:Die Navigierbarkeit deutet auf eine "Auskunftsverantwortlichkeit" beim Entwurf und auf das Vorhandensein von Zeigern bei der Implementation hin. In Abbildung 5 zeigt der Pfeil am Ende der Assoziation von Buchbestand und Buch, daß der Buchbestand die Methoden eines enthaltenen Buches aufrufen kann, jedoch nicht umgekehrt. Assoziationsklassen:Ein Beispiel einer Assoziationsklasse ist die Klasse "Leihschein" in Abbildung 5. Es kann bei UML nur ein Objekt der Klasse "Leihschein" zwischen zwei Instanzen von "Buch" und "Kunde" geben. Daher wäre es in UML z. B. nicht erlaubt, mehrere Buchungsbelege für einen Kunden und ein Konto als Instanzen einer Assoziationsklasse zu modellieren. Da Assoziation und Assoziationsklasse ein Modellelement sind, müssen die beiden Namen übereinstimmen, aber nicht unbedingt gezeigt sein. Man könnte also den Namen "Leihschein" der Assoziation weglassen, da sich "Kunde Leihschein Buch" schlecht liest und der Name schon durch die Assoziationsklasse festgelegt ist. qualifizierte Assoziationen:Die Qualifikation einer Assoziation ist in Abbildung 5 mit Hilfe des kleinen Rechtecks mit dem Text "ISBN" gezeigt. Dies kann als Zugriff über den "Schlüssel" ISBN interpretiert werden. Außerdem werden die Zielobjekte in Partitionen aufgeteilt.
Der Sinn dieses Beispieles ist, festzulegen, daß ein Kunde
ein bestimmtes Buch nur einmal ausleihen kann, auch wenn es mehrfach
vorhanden ist. 8.4 Zusatzinformationen und Bedingungen
Zusatzinformationen sind kursiv gedruckt. Ungeklammert auftretender
kursiver Text bedeutet einen Kommentar. In geschweifte Klammern
eingeschlossener Text bedeutet Bedingungen
(engl. constraints). Diese können benutzer- oder vordefiniert
sein. Im Metamodell werden Bedingungen als boolesche Meta-Attribute
den einzelnen Metaklassen zugeordnet (Bedingung modelliert Attributwert
TRUE). Den benutzerdefinierten Bezeichnern können beliebige
Werte (engl. tagged values) zugeordnet werden. Solche
Informationen werden bei Werkzeugen häufig durch Anklicken
hervorgeholt. Zusatzinformationen können auch in einer note
(angehängter Notizzettel) gezeigt sein, wie bei "Adresse
drucken" in Abbildung 3.
Dann ist mehr Platz für Kommentar und ausführliche Bedingungen.
Abbildung 5: Klassendiagramm 2
8.5 StereotypenEin Stereotyp ist ein Subtyp einer vorhandenen Klasse im Metamodell, also eine Spezialisierung eines Modellierungselementes. Benutzerdefinierte Stereotypen können von allen Modellelementen, u. a. von Klassen und Methoden, gebildet werden. Ein Beispiel ist <<persistent>> in Abbildung 5. Es gibt auch vordefinierte Stereotypen. Beispiele sind <<extends>> beim Anwendungsfallmodell, <<Interface>> in Klassendiagrammen und <<transparent>> in Paketdiagrammen. Stereotypen werden oft mit Bedingungen (z. B. {abstract}) verwechselt.
Werkzeuge können vom Stereotyp abhängigen Code generieren.
Beispiel: Der Stereotyp <<persistent>> generiert Datenbankbefehle
oder die "serialize" Funktion. 8.6 Vererbung
8.7 PaketeZur Beherrschung der Komplexität bietet UML Pakete (engl. Package) an. Ein Beispiel dazu ist Abbildung 7. Ein Klassendiagramm, in dem nur Pakete und deren Abhängigkeiten vorkommen, wird Paketdiagramm genannt. Wie man aber hier an der Klasse Drucker sieht, dürfen Pakete und andere Elemente von Klassendiagrammen zusammen gezeigt werden. Jede Klasse gehört zu genau einem Paket, das auch den Namensraum für den Klassennamen bestimmt, innerhalb dessen der Name eindeutig sein muß. Tritt ein Klassenname in mehreren Paketen auf, so kann die Klasse mit Hilfe der Schreibweise <Paketname>::<Klassenname> und ein Objekt der Klasse über <Objektname>:<Paketname>::<Klassenname> eindeutig angegeben werden. Ein Beispiel kam weiter vorne im Text vor: Abbildung 5 zeigte die paketqualifizierten Klassennamen der Klassen "Kartei" und "Kunde", die aus dem Paket "Kunden" importiert werden. Abbildung 7 zeigt die Abhängigkeit (Importbeziehung, Benutzung) des "User Interface" vom "Problembereich". Somit können alle Klassen des "User Interface" auf den Drucker zugreifen. Dieser gestrichelte Pfeil wurde bisher übergangen, ist aber ein allgemeines Darstellungselement, kann also auch für Benutzungsbeziehungen von Klassen statt Paketen Verwendung finden. Ein weiteres Beispiel für diese Beziehung wird im Folgeabschnitt bei der Benutzung von Interfaces gegeben. Durch <<transparent>> wird der zusätzliche Zugriff auf Elemente des eingeschachtelten Paketes "Bücher" ermöglicht, soweit dessen Methoden "public" Sichtbarkeit haben. Die spitzen Klammern bedeuten hier einen Stereotyp. Pakete sind als Basis für Tests und spezifizierende Klassendiagramme geeignet und können eine eigene Versionsnummer erhalten.
Die Vererbung
kann auch für Pakete genutzt werden. 8.8 Interfaces und Templates
In Abbildung 8 sind weitere
Elemente von Klassendiagrammen zu sehen: Drei Klassen, zwei Interfaces,
der Methodenvererbungspfeil, die Lolli-Notation, eine Template-Vorlage
und eine instanziierte Template-Klasse. Da Interfaces in der objektorientierten Programmierung nützlich zur Klassifikation und Abstraktion sind, wurden sie im Metamodell von UML den Klassen gleichgestellt, obwohl sie sich als Grenzfall einer abstrakten Klasse, in der alle Methoden abstrakt sind, darstellen lassen. Die gemeinsame Oberklasse der Metamodellklassen Class und Interface wird Classifier genannt.
Abbildung 8: Klassendiagramm 3
Mit dem gestrichelten Pfeil von rechts nach links oben im Bild wird modelliert, daß die Klasse Kartei Objekte vom Typ Sortable benutzt, ohne genauer zu sagen, welche das sind. Wenn man das festlegen möchte, kann man statt des Methodenvererbungspfeils auch die sogenannte Lolli-Notation verwenden (Diagramm Mitte unten): Die Klasse "Kunde" implementiert die Interfaces Sortable und Printable. Objekte der Klasse Kunde können in ihrer Eigenschaft, Printable zu sein, vom "Druckauftrag" benutzt werden. Der Druckauftrag darf andere Methoden von Kunde als print() nicht aufrufen. In der rechten Bildhälfte ist das Template-Konzept dargestellt: "Kartei" ist ein Template mit einem nicht spezifizierten Parameter T. Für eine Templateinstanz wie "Kartei<Kunde>" wird die Parameterbindung dann mittels des <<bind>> Pfeils vollzogen. Die folgende Problemstellung versucht, das Template- und das Interfacekonzept miteinander in Beziehung zu bringen: Für das Bibliothekssystem werden eine Kundenkartei und eine Bücherkartei gebraucht. Die erstere soll nur Kunden und die letztere nur Bücher aufnehmen können. Beide Karteien sollen sortiert werden, aber die entsprechende Funktion soll nur einmal vorhanden sein. Die Lösung wäre ein Template, dessen Parameter ein Subtyp von "Sortable" sein muß. Dafür gibt es jedoch in UML keine spezielle Notation.
Martin Fowler empfiehlt, Templates nur zu verwenden, wenn sie
von der Programmiersprache unterstützt werden. Er schreibt
in seinem Buch, daß das nützliche an Templates sei,
"daß der Compiler die Benutzung des Parameters prüft".
Da man zur Entwurfsphase noch keinen Compiler hat, bräuchte
man also ein spezielles Werkzeug. 9. InteraktionsdiagrammeEin Interaktionsdiagramm zeigt ein Szenario. Ein oder mehrere Diagramme bzw. Szenarien zeigen die Zusammenarbeit zwischen Objekten für genau einen Anwendungsfall. SequenzdiagrammDas Sequenzdiagramm enthält eine Zeitachse und kann dynamisches Verhalten darstellen. Es zeigt die beteiligten Objekte und kann deren Lebensdauer anhand einer Lebenslinie darstellen. Blockierende Nachrichten werden mit einer vollen, nicht blockierende, asynchrone Nachrichten mit einer halben Pfeilspitze dargestellt. Das Sequenzdiagramm kann auch einfache Bedingungen und Schleifen darstellen. Dies ist hier nicht gezeigt und erfolgt mit der gleichen Notation wie beim Aktivitätsdiagramm. Diagramme dieser Art wurden bisher oft für Signalmodelle (Netzwerke, "Telefonanlagen") verwendet. Für solche Anwendungen können die Nachrichtenpfeile auch schräg nach unten gezeichnet werden, um die Übertragungszeit zu veranschaulichen. Abbildung 9: Sequenzdiagramm
Wenn eine Methode eines Objekts gerade rechnet, oder wenn in einem prozeduralen Modell eine von ihr aufgerufene Methode ausgeführt wird, dann kann die Lebenslinie des Objekts zur Darstellung der Aktivierung verbreitert eingezeichnet werden. Wenn die Methode tatsächlich selbst rechnet, also nicht auf die Rückkehr einer anderen Methode wartet, kann die Aktivierung zusätzlich schraffiert werden (oberstes Stackframe). Die dünne horizontale Linie zeigt, wie die Belegung des Laufzeitstapels zu einem bestimmten Zeitpunkt bei rein prozeduralem Verhalten ermittelt werden könnte. Dies ist hier nur zu Demonstrationszwecken gezeigt und nicht sinnvoll, da jeder Thread seinen eigenen Stack hat. Im Beispiel existieren Bibliothekar und Kunde schon vorher, während Leihschein und Druckauftrag neu erzeugt werden. Der Druckauftrag wird durch (Selbst-)Vernichtung wieder gelöscht.
Das Sequenzdiagramm kann durch Kommentare
leichter verständlich gemacht werden. KollaborationsdiagrammAbbildung 10: Kollaborationsdiagramm
Das Kollaborationsdiagramm enthält statische Beziehungen sowie dynamisches Verhalten. Es ist einem "Szenario" mit Nachrichtenkanälen aus dem Kurs Software-Engineering II (KE 3) sehr ähnlich. Abbildung 10 zeigt, wie das Kollaborationsdiagramm die Zusammenarbeit zwischen Objekten für einen Anwendungsfall darstellt. Außerdem sieht man, wie die statischen Beziehungen dieser Objekte, d. h. die Instanzen der Assoziationen, genannt Links, mit unterstrichenen Namen eingezeichnet werden. Die zeitliche Abfolge der Nachrichten muß den Sequenznummern entnommen werden, ist also nicht so leicht wie beim Sequenzdiagramm zu erkennen. Zur Darstellung prozeduraler Abläufe wird eine Stufennumerierung verwendet. Bei parallelem Objektverhalten ist die Numerierung einstufig. Die Parallelität wird nicht sehr gut veranschaulicht. Im Diagramm enthalten sind auch Kollaborationsrollen. Dabei gibt es zwei Typen: Erstens die Rollen eines Objekts einer Klasse oder eines Interface (engl. Classifier Role) und zweitens die Assoziationsrollen. Durch Entwurfsmusternamen und Entwurfsmusterrollen strebt UML an, Entwurfsmuster darstellen zu können. Damit allein kann dieses Gebiet, das in einem anderen Bericht dieses Seminars behandelt wird, aber nicht komplett dargestellt werden.
Schleifen und Bedingungen sind auch darstellbar. Dies ist hier
nicht gezeigt und erfolgt neben den Nachrichtenpfeilen mit der
gleichen Notation wie beim Aktivitätsdiagramm.
10. Zustandsdiagramm
Abbildung 11: Zustandsdiagramm
Die Aufgabe des Zustandsdiagramm ist die Beschreibung des Verhaltens eines einzelnen Objekts während seiner gesamten Lebensdauer und für alle Anwendungsfälle auf einmal. Es entspricht einem endlichen Automaten, der hierarchisch strukturiert werden kann. Es gibt auch eine Notation zur Darstellung paralleler Abläufe, die aber nicht primäre Aufgabe des Zustandsdiagramms sind. Zustände werden durch Rechtecke mit abgerundeten Ecken dargestellt. Zustandsübergänge werden durch Ereignisse ausgelöst.
Abbildung 11 zeigt ein Beispiel.
Der Startzustand
wird über den Pfeil oben links, dessen Anfang durch einen
schwarzgefüllten Kreis markiert ist, betreten. Die Bedeutung
der zwei Oberzustände
"da" und "weg" soll hier sein, daß ein
Buch in der Bibliothek oder beim Entleiher ist. Die Oberzustände
haben wiederum jeweils einen eigenen Startzustand, in den man
nach dem Betreten des Oberzustands gelangt. Um den Übergang
"Buch leihen" darzustellen, ist nur ein Pfeil nötig,
obwohl die Aktion von zwei Zuständen (verleihbar und zurückgelegt)
ausgehen kann. Wenn der Ausgangszustand "zurückgelegt"
war, wird vor dem Übergang noch die exit-Aktion
"Merker löschen" ausgeführt. Aktivitäten
wie "registriere" sind unterbrechbar (also im Beispiel
schlecht modelliert), Aktionen
wie "Leihschein drucken" sind nicht unterbrechbar. "[Kunde
registriert]" ist eine Bedingung
für das Ereignis "leihen". Ferner ist die Verwendung
des after-Schlüsselworts
dargestellt, durch das der Zustand nach Ablauf der Zeitspanne,
die mit dem Erreichen des Zustands begann, wieder verlassen wird.
11. AusblickNeue Entwicklungen im SW-Engineering werden auf UML aufbauen. Es wird nötig werden, UML zu verstehen, da viele Dokumente in dieser Form geschrieben werden. Vielleicht entstehen bessere Werkzeuge, da die Hersteller einen breiteren Markt haben, wenn sich UML allgemein durchsetzt.
|
