1 DigInf 05/06 Diagrammtypen der UML 2.0 StrukturdiagrammeVerhaltensdiagramme Interaktionsdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Zustandsautomat Paketdiagramm Aktivitätsdiagramm Use-Case-Diagramm Sequenzdiagramm Kommunikationsdiagramm Verteilungsdiagramm UML-Diagramme Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering Timingdiagramm Interaktionsübersichtsdiagramm

2 DigInf 05/06 Komponentendiagramm Problem: Mehrere Klassen zusammen sollen als Komponente ein gemeinsames Verhalten in Form von öffentlich zugänglichen Schnittstellen bereitstellen. Diese zentrale Frage beantwortet das Diagramm: Wie werden meine Klassen zu wiederverwendbaren, verwaltbaren Komponenten zusammengefasst und wie stehen diese miteinander in Beziehung? Diese Stärken hat das Diagramm: a.zeigt Organisation und Abhängigkeiten einzelner technischer Systemkomponenten b.Modellierung angebotener und benötigter Schnittstellen möglich Quelle: Jeckle et al.: UML 2 - glasklar

3 DigInf 05/06 Komponentenbegriff Eine Komponente... ist ein modularer Systemteil, der seinen Inhalt kapselt und vor dem Nutzer verbirgt. besteht aus anderen Elementen (Klassen, andere Komponenten). bietet über extern nutzbare Schnittstellen klar definierte Funktionalitäten an. ist durch andere Komponenten, die die gleichen Schnittstellen anbieten, ersetzbar. wird durch Kombination mit anderen Komponenten zu einer größeren Einheit zusammengefügt. ist häufig eine eigenständige Anwendung.

4 DigInf 05/06 Notationselemente I Komponenten werden durch den Stereotyp > angegeben es können zusätzlich die verwendeten Schnittstellen angegeben werden (black- box-Darstellung) > es kann zusätzlich die interne Realisierung angegeben werden (white- box-Darstellung) > (Klassen) >

5 DigInf 05/06 Notationselemente II Artefakte sind physische Informationseinheiten Modelle, Quellcode, Scripte, Binärdateien, Tabelle einer DB, Textdokumente, s etc. Artefakte sind in diesem Diagramm konkrete Ausprägungen (Instanzen) einer Komponente Stereotype zur näheren Beschreibung file, document, executable, source, library weitere Stereotypdefinitionen gibt es in UML-Profilen (Enterprise Java Beans Profile EJB, Microsoft Component Profile COM) Artefakte können geschachtelt werden

6 DigInf 05/06 Notationselemente III Schnittstellen werden mit einem Klassensymbol dargestellt sie beschreiben eine Menge von Operationen, Merkmalen und „Verpflichtungen“ Komponente1 implementiert die Schnittstelle Pfeildarstellung Ball-Darstellung Komponente2 benötigt die Schnittstelle Pfeildarstellung Socket-Darstellung Ball-Socket-Darstellung

7 DigInf 05/06 Notationselemente IV zwischen Modellelementen können allgemeine Abhängigkeitsbeziehungen existieren (gestrichelter Pfeil, Quelle benötigt Ziel) zwischen Komponenten entspricht das der Verschachtelung (komplexe Komponenten) > wenn ein oder mehrere Artefakte durch eine Komponente realisiert werden > wenn eine Komponente eine andere ersetzen kann Schnittstellen sollten normalerweise den gleichen Namen tragen, um anzuzeigen, dass diese kompatibel zueinander sind wenn die Kompatibilität auch bei unterschiedlicher Benennung gegeben ist, kann das durch eine allgemeine Abhängigkeitsbeziehung ausgedrückt werden (Operationen einer Klasse heißen anders, erfüllen aber den gleichen Zweck)

8 DigInf 05/06 Anwendungsbeispiel die ausführbare Datei util.jar realisiert die Komponente Listengenerator und hängt vom Artefakt list.class ab, das wiederum von der Quellcodedatei list.java abhängt die Komponente Listengenerator hat die Schnittstelle Feldinhalt implementiert, benötigt die Schnittstelle Speichermedium und beinhaltet die Komponente Zeilengenerator die Komponente Zeilengenerator benötigt die Schnittstelle Zeilennummer (die Komponente Addierer implementiert die dazu kompatible Schnittstelle Zahlenfolge)

9 DigInf 05/06 Komponentendiagramm Änderungen gegenüber früheren UML-Versionen Manifestierung (früher Implementierung) neues Komponentensymbol neue Stereotypen (einige alte entfallen) Besondere Hinweise Es sollten Profile verwendet werden, um die Semantik der Komponenten und Artefakte besser widerzuspiegeln (z.B..NET und J2EE). Alle relevanten Dokumente des Entwicklungsprozesses sollten durch Artefakte dargestellt werden. Abhängigkeitsbeziehungen sollten möglichst vollständig dargestellt werden. Dazu sollten gegebenenfalls eigene Stereotype definiert werden.

10 DigInf 05/06 Diagrammtypen der UML 2.0 StrukturdiagrammeVerhaltensdiagramme Interaktionsdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Zustandsautomat Paketdiagramm Aktivitätsdiagramm Use-Case-Diagramm Sequenzdiagramm Kommunikationsdiagramm Verteilungsdiagramm UML-Diagramme Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering Timingdiagramm Interaktionsübersichtsdiagramm

11 DigInf 05/06 Kompositionsstrukturdiagramm Diese zentrale Frage beantwortet das Diagramm: Wie sieht das Innenleben einer Klasse, einer Komponente, eines Systemteils aus? Diese Stärken hat das Diagramm: a.ideal für die Top-down-Modellierung des Systems b.präzise Modellierung der Teile-Beziehungen über spezielle Schnittstellen (Ports) möglich Quelle: Jeckle et al.: UML 2 - glasklar

12 DigInf 05/06 Notationselemente I Ein Part repräsentiert eine Menge von Ausprägungen, die zu einer Ausprägung des sie umgebenden Classifiers (z.B. Klasse) gehören. Ein Kollaborationstyp (Ellipse mit Linie) wird verwendet, um eine Sicht auf kooperierende Modellelemente herauszubilden. Eine Kollaboration (Ellipse) wird verwendet, um die Zusammenarbeit der Elemente innerhalb eines Classifiers darzustellen.

13 DigInf 05/06 Anwendungsbeispiel Es ist die Verwandtschaftsbeziehung eines Enkels zu seiner Großmutter dargestellt (Kollaboration Verwandtschaft). Der Kollaborationstyp Abstammung wird verwendet, um die Vaterschaftsbeziehung zwischen Vater und Sohn und die Mutterschaftsbeziehung zwischen Großmutter und Vater zu beschreiben.

14 DigInf 05/06 Kompositionsstrukturdiagramm Änderungen gegenüber früheren UML-Versionen Das Kompositionsstrukturdiagramm wurde neu eingeführt. Besondere Hinweise Das Diagram sollte verwendet werden, um bestimmte Aspekte der Architektur des Systems zu veranschaulichen, z.B. beim Einsatz von Entwurfsmustern.

15 DigInf 05/06 Diagrammtypen der UML 2.0 StrukturdiagrammeVerhaltensdiagramme Interaktionsdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Zustandsautomat Paketdiagramm Aktivitätsdiagramm Use-Case-Diagramm Sequenzdiagramm Kommunikationsdiagramm Verteilungsdiagramm UML-Diagramme Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering Timingdiagramm Interaktionsübersichtsdiagramm

16 DigInf 05/06 Objektdiagramm Problem: Bestimmte komplexe Systemkonfigurationen sollen modelliert werden. Diese zentrale Frage beantwortet das Diagramm: Welche innere Struktur besitzt mein System zu einem bestimmten Zeitpunkt zur Laufzeit? Diese Stärken hat das Diagramm: a.zeigt Objekte und deren Attributbelegungen zu einem bestimmten Zeitpunkt b.Grad der Detaillierung wie im Klassendiagramm c.sehr gute Darstellung von Mengenverhältnissen Quelle: Jeckle et al.: UML 2 - glasklar

17 DigInf 05/06 Notationselemente Objekte werden mit dem Objektnamen und dem zugehörigen Klassennamen notiert. Attributwerte werden hinter dem Attributnamen notiert. Links sind Ausprägungen von Assoziationen und werden als Linie dargestellt.

18 DigInf 05/06 Anwendungsbeispiel Objektdiagramm Klassendiagramm

19 DigInf 05/06 Objektdiagramm Besondere Hinweise Die instanziierenden Klassen und Schnittstellen sollten immer für jedes Objekt mit angegeben werden, um die Lesbarkeit zu erhöhen. Es sollten nur so viele Wertbelegungen angegeben werden, wie für das Verständnis der spezifischen Konfiguration wirklich notwendig sind. Es ist keine zwingende Belegung aller Attribute mit Werten vorgeschrieben.

20 DigInf 05/06 Diagrammtypen der UML 2.0 StrukturdiagrammeVerhaltensdiagramme Interaktionsdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Zustandsautomat Paketdiagramm Aktivitätsdiagramm Use-Case-Diagramm Sequenzdiagramm Kommunikationsdiagramm Verteilungsdiagramm UML-Diagramme Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering Timingdiagramm Interaktionsübersichtsdiagramm

21 DigInf 05/06 Verteilungsdiagramm Problem: Es soll die Verteilung der Software des Systems auf die Hardware beschrieben werden. Diese zentrale Frage beantwortet das Diagramm: Wie sieht das Einsatzumfeld (Hardware, Server, Datenbanken etc.) des Systems aus? Wie werden die Komponenten zur Laufzeit wohin verteilt? Diese Stärken hat das Diagramm: a.zeigt das Laufzeitumfeld des Systems mit den greifbaren Systemteilen b.Darstellung von „Softwareservern“ möglich c.hohes Abstraktionsniveau, kaum Notationselemente Quelle: Jeckle et al.: UML 2 - glasklar

22 DigInf 05/06 Notationselemente Ein Knoten repräsentiert eine Ressource, inner-halb der mit Artefakten gearbeitet werden kann. Es gibt zwei Ausprägungen von Knoten: Geräte (Hardware)  > Ausführungsumgebungen (Software- umgebung)  > Eine Einsatzspezifikation (deployment spec) legt die genaue Ausführung von Artefakten fest. Kommunikationspfade werden durch eine Linie dargestellt (gerichtet und ungerichtet); über diese werden Nachrichten ausgetauscht. Verteilungsbeziehungen werden durch einen gestrichelten Pfeil dargestellt; damit wird dargestellt, welche Artfakte wo ablaufen.

23 DigInf 05/06 Anwendungsbeispiel Der Application Server (HW) ist assoziiert mit einem oder mehreren DB Servern (HW), auf ihm läuft die Ausführungsumgebung J2EE Server (SW). Die Anwendung Application.jar (Datei) wird vom J2EE Server ausgeführt. Die genauen Parameter der Ausführung sind in der Datei AppDesc.xml beschrieben.

24 DigInf 05/06 Verteilungsdiagramm Änderungen gegenüber früheren UML-Versionen Es wurde eine bessere Unterscheidung zwischen Soft- und Hardware-Ausführungsumgebungen vorgenommen. Verwendung von Artefakten. Besondere Hinweise Beschränken Sie sich durchgängig auf eine Darstellungsvariante, wenn mehrere Notationsvarianten möglich sind (z.B. mit oder ohne Deploy-Beziehungen).

25 DigInf 05/06 Diagrammtypen der UML 2.0 StrukturdiagrammeVerhaltensdiagramme Interaktionsdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Zustandsautomat Paketdiagramm Aktivitätsdiagramm Use-Case-Diagramm Sequenzdiagramm Kommunikationsdiagramm Verteilungsdiagramm UML-Diagramme Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering Timingdiagramm Interaktionsübersichtsdiagramm

26 DigInf 05/06 Paketdiagramm Problem: Große Softwaresysteme mit mehreren 100 Klassen lassen sich nicht mehr von einer Person überblicken. Diese zentrale Frage beantwortet das Diagramm: Wie kann ich mein Modell so schneiden, dass ich den Überblick bewahre? Diese Stärken hat das Diagramm: a.organisiert das Systemmodell in größeren Einheiten durch logische Zusammenfassung von Modellelementen b.Modellierung von Abhängigkeiten und Inklusionen ist möglich Quelle: Jeckle et al.: UML 2 - glasklar

27 DigInf 05/06 Notationselemente Das Paket wird mit seinen zugehörigen Elementen dargestellt (z.B. Klassen) Elemente können mit einer Sichtbarkeit versehen werden (- private, + public). Elemente eines Pakets können wiederum Pakete sein. Pakete können andere Pakete importieren (Quelle importiert Ziel). >: importierte Classifiers werden als private definiert >: importierte Classifiers werden als public definiert >: der komplette Classifier wird importiert und kann verändert werden

28 DigInf 05/06 Anwendungsbeispiel Inhalt: P3 importiert A (P1) als private P3 importiert B (P2) als public P4 importiert P3 Folge: P4 darf nicht auf A zugreifen P4 darf auf B zugreifen

29 DigInf 05/06 Paketdiagramm Änderungen gegenüber früheren UML-Versionen Keine (1.4 und 1.5). Besondere Hinweise Pakete sollten mit möglichst aussagekräftigen Namen versehen werden. Die UML unterstützt den Modellierer nicht in der logischen Zuschneidung der Pakete.

30 DigInf 05/06 Diagrammtypen der UML 2.0 StrukturdiagrammeVerhaltensdiagramme Interaktionsdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Zustandsautomat Paketdiagramm Aktivitätsdiagramm Use-Case-Diagramm Sequenzdiagramm Kommunikationsdiagramm Verteilungsdiagramm UML-Diagramme Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering Timingdiagramm Interaktionsübersichtsdiagramm

31 DigInf 05/06 Aktivitätsdiagramm Problem: Es sollen Abläufe, z.B. Geschäftsprozesse, modelliert werden. Im Vordergrund steht dabei eine Aufgabe, die in Einzelschritte zerlegt werden soll. Es sollen Details eines Use Cases festgelegt werden. Diese zentrale Frage beantwortet das Diagramm: Wie realisiert mein System ein bestimmtes Verhalten? Diese Stärken hat das Diagramm: a.Detaillierte Visualisierung von Abläufen mit Bedingungen, Schleifen und Verzweigungen. b.Parallelisierung und Synchronisation ist möglich. c.Darstellung von Daten- und Kontrollflüssen. Quelle: Jeckle et al.: UML 2 - glasklar

32 DigInf 05/06 Starke Änderungen in UML 2.0 Neue Basis Aktivitätsdiagramme nutzen jetzt bewährte Mittel anderer Diagramm- sprachen, z.B. Petri-Netze, Datenflussdiagramme, Struktogramme, Programmablaufpläne. Ablaufkonzepte höherer Programmiersprachen Es können jetzt alle gängigen Ablaufkonzepte (Kontrollstrukturen, Exceptions, parallele Ablaufsteuerung) modelliert werden. Tokenkonzept Ein Token (auch: Marke) zeigt an, an welchem Punkt sich der Ablauf gerade befindet. Es können beliebig viele Token unterwegs sein (parallele Abläufe). Token werden graphisch nicht dargestellt, sondern dienen nur der Erklärung der Abläufe.

33 DigInf 05/06 Notationselemente I eine Aktion ist der Aufruf eines Verhaltens die Summe aller Aktionen realisiert die Aktivität ein Pfeil steht für einen Kontrollfluss (Kante, die für die Steuerung des logischen Ablaufs notwendig ist) Objektfluss (Kante, die einen Objektknoten [Token] überträgt) Startknoten Endknoten für Kontrollflüsse Endknoten für Aktivitäten

34 DigInf 05/06 Notationselemente II Signalempfänger und –sender sind spezialisierte Aktionen. Bei Erreichen des Signalsenders wird ein Signal mit Payload versendet und an einen Signalempfänger versendet, der Kontroll- und Objektfluss wird fortgesetzt. Beim Empfang eines Signals durch den Signalempfänger wird der nachfolgende Kontroll- und Objektfluss ausgelöst.

35 DigInf 05/06 Notationselemente III Eine Aktivität ist die gesamte Einheit, die in einem Aktivitätsmodell modelliert wird. Eine Aktivität besteht aus Aktionen und kann Eingangs- und Ausgangsparameter (Objektknoten) haben. Aktivitäten können Vor- und Nachbedingungen haben. Aktivitäten können ineinander verschachtelt sein.

36 DigInf 05/06 Notationselemente IV Ein- und Ausgabeparameter einer Aktionen können auch durch Pins notiert werden. Aktionen können andere Aktivitäten aufrufen (Harke).

37 DigInf 05/06 Notationselemente V Der Verzweigungsknoten spaltet eine Kante in mehrere Alternativen auf (ein Token kann nur eine der ausgehenden Kanten passieren). Der Verbindungsknoten führt Kanten ohne Synchronisation zusammen (keine Verschmelzung der Token). Der Synchronisationsknoten führt eingehende Kanten zu einem gemeinsamen Ablauf zusammen (an allen eingehenden Kanten müssen Token anliegen). Der Parallelisierungsknoten teilt die eingehende Kante in mehrere parallele Abläufe auf.

38 DigInf 05/06 Notationselemente VI Strukturierte Knoten (gestrichelter Kasten) werden zur Gruppierung von Aktionen verwendet. Unterbrechungsbereiche werden verwendet, wenn bei Eintritt eines Ereignisses alle Aktionen in diesem Bereich beendet werden sollen und eine definierte Aktion ausgelöst werden soll. Aktivitätsbereiche werden verwendet, um Aktionen bestimmten Personen oder Organisationseinheiten zuzuordnen.

39 DigInf 05/06 Anwendungsbeispiel

40 DigInf 05/06 Aktivitätsdiagramm Änderungen gegenüber früheren UML-Versionen sind jetzt keine Sonderform der Zustandsdiagramme mehr, sondern basieren auf erweiterten Petri-Netzen damit sind viele Einschränkungen beseitigt: verbesserte Testbarkeit fast automatisch erkennbare Verklemmungsfreiheit bessere Unterstützung paralleler Flüsse Ausführbarkeit fast vollständig möglich mehr Flexibilität in der Modellierung durch das Tokenkonzept Besondere Hinweise Für die Modellierung reaktiver Systeme sollten lieber Zustandsautomaten verwendet werden. Verzweigungen und deren Bedingungen sollten immer exakt modelliert werden.