Diagrammtypen der UML 2.0

Transkript

1 Diagrammtypen der UML 2.0 UML-Diagramme Strukturdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm Verhaltensdiagramme Aktivitätsdiagramm Use-Case-Diagramm Zustandsautomat Interaktionsdiagramme Sequenzdiagramm Kommunikationsdiagramm Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering Timingdiagramm Interaktionsübersichtsdiagramm 1 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 2 1

2 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. 3 Notationselemente I Teilnehmerverwaltung Teilnehmerverwaltung <<provided interfaces>> Sortierter Zugriff Wahlfreier Zugriff <<required interfaces>> Speichermedium Teilnehmerverwaltung <<provided interfaces>> Sortierter Zugriff Wahlfreier Zugriff <<required interfaces>> Speichermedium <<realization>> Teilnehmer Verwaltungsmetadaten <<artifacts>> teilnehmer.jar Komponenten werden durch den Stereotyp angegeben es können zusätzlich die verwendeten Schnittstellen angegeben werden (blackbox-darstellung) <<provided interfaces>> <<required interfaces>> es kann zusätzlich die interne Realisierung angegeben werden (whitebox-darstellung) <<realization>> (Klassen) <<artifacts>> 4 2

3 Notationselemente II <<artifact>> Application.jar <<artifact>> Application.jar <<artifact>> ejb1.xml <<artifact>> ejb2.xml <<deployment spec>> app.xml 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 5 Notationselemente III Komponente1 Komponente1 Komponente2 Komponente2 Komponente1 <<use>> <<interface>> Schnittstellenname attribut operation() <<interface>> Schnittstellenname Schnittstellenname <<interface>> Schnittstellenname Schnittstellenname Komponente2 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 6 3

4 Notationselemente IV Komponente2 <<artifact>> Application.jar Drucken Komponente2 Schnittstellenname2 <<manifest>> <<substitute>> Komponente1 Komponente1 Drucken Sortieren Komponente1 Schnittstellenname1 zwischen Modellelementen können allgemeine Abhängigkeitsbeziehungen existieren (gestrichelter Pfeil, Quelle benötigt Ziel) zwischen Komponenten entspricht das der Verschachtelung (komplexe Komponenten) <<manifest>> wenn ein oder mehrere Artefakte durch eine Komponente realisiert werden <<substitute>> 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) 7 Anwendungsbeispiel Zeilennummer Zeilengenerator Feldinhalt Feldgenerator <<executable>> util.jar <<manifest>> Listengenerator <<use>> <<interface>> Speichermedium Zahlenfolge Addierer <<artifact>> list.class <<source>> list.java 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) 8 4

5 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. 9 Diagrammtypen der UML 2.0 UML-Diagramme Strukturdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm Verhaltensdiagramme Aktivitätsdiagramm Use-Case-Diagramm Zustandsautomat Interaktionsdiagramme Sequenzdiagramm Kommunikationsdiagramm Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering Timingdiagramm Interaktionsübersichtsdiagramm 10 5

6 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 11 Notationselemente I Klasse partname Ein Part repräsentiert eine Menge von Ausprägungen, die zu einer Ausprägung des sie umgebenden Classifiers (z.b. Klasse) gehören. Vorfahre Abstammung Nachkomme Ein Kollaborationstyp (Ellipse mit Linie) wird verwendet, um eine Sicht auf kooperierende Modellelemente herauszubilden. kollaboration1 : Kollaborationstyp1 Eine Kollaboration (Ellipse) wird verwendet, um die Zusammenarbeit der Elemente innerhalb eines Classifiers darzustellen. 12 6

7 Anwendungsbeispiel Verwandtschaft Nachkomme Mutterschaft : Abstammung Vorfahr Großmutter Vater Vorfahr Vaterschaft : Abstammung Nachkomme Sohn 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. 13 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. 14 7

8 Diagrammtypen der UML 2.0 UML-Diagramme Strukturdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm Verhaltensdiagramme Aktivitätsdiagramm Use-Case-Diagramm Zustandsautomat Interaktionsdiagramme Sequenzdiagramm Kommunikationsdiagramm Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering Timingdiagramm Interaktionsübersichtsdiagramm 15 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 16 8

9 Notationselemente objektname : Klassenname referent : Mitarbeiter vorname : String = André name : String = Köhler geburtsdatum : Date = personalnummer : String = 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. 17 Anwendungsbeispiel referent : Mitarbeiter, Person Uni Leipzig : Arbeitgeber vorname : String = André name : String = Köhler geburtsdatum : Date = personalnummer : String = : Gehalt einkommen : Geld = 100 Objektdiagramm Person Mitarbeiter Arbeitgeber Klassendiagramm vorname : String [1..*] name : String geburtsdatum : Date personalnummer : String Gehalt einkommen : Geld Wissenschaftlicher Mitarbeiter 18 9

10 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. 19 Diagrammtypen der UML 2.0 UML-Diagramme Strukturdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm Verhaltensdiagramme Aktivitätsdiagramm Use-Case-Diagramm Zustandsautomat Interaktionsdiagramme Sequenzdiagramm Kommunikationsdiagramm Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering Timingdiagramm Interaktionsübersichtsdiagramm 20 10

11 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 21 Notationselemente Knotenname <<device>> Name <<ExecutionEnvironment>> Name <<deployment spec>> Name Attribut: Typ <<deploy>> Ein Knoten repräsentiert eine Ressource, inner-halb der mit Artefakten gearbeitet werden kann. Es gibt zwei Ausprägungen von Knoten: Geräte (Hardware) <<device>> Ausführungsumgebungen (Softwareumgebung) <<ExecutionEnvironment>> 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

12 Anwendungsbeispiel <<device>> : DB Server 1..* Datenhaltung 1..* <<device>> : Application Server <<deployment spec>> AppDesc.xml <<artifact>> <<deploy>> <<ExecutionEnvironment>> : J2EE Server execution : thread Application.jar 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. 23 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)

13 Diagrammtypen der UML 2.0 UML-Diagramme Strukturdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm Verhaltensdiagramme Aktivitätsdiagramm Use-Case-Diagramm Zustandsautomat Interaktionsdiagramme Sequenzdiagramm Kommunikationsdiagramm Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering Timingdiagramm Interaktionsübersichtsdiagramm 25 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 26 13

14 Notationselemente Paketname +Classifier1 -Classifier2 Das Paket wird mit seinen zugehörigen Elementen dargestellt (z.b. Klassen) Elemente können mit einer Sichtbarkeit versehen werden (- private, + public). Paket X Paket A Paket B Elemente eines Pakets können wiederum Pakete sein. Paket C <<access >> <<import>> <<merge>> Pakete können andere Pakete importieren (Quelle importiert Ziel). <<access>>: importierte Classifiers werden als private definiert <<import>>: importierte Classifiers werden als public definiert <<merge>>: der komplette Classifier wird importiert und kann verändert werden 27 Anwendungsbeispiel P1 A <<access>> P3 <<import>> P2 P4 B Inhalt: P3 importiert A (P1) als private P3 importiert B (P2) als public P4 importiert P3 <<import>> Folge: P4 darf nicht auf A zugreifen P4 darf auf B zugreifen 28 14

15 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. 29 Diagrammtypen der UML 2.0 UML-Diagramme Strukturdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm Verhaltensdiagramme Aktivitätsdiagramm Use-Case-Diagramm Zustandsautomat Interaktionsdiagramme Sequenzdiagramm Kommunikationsdiagramm Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering Timingdiagramm Interaktionsübersichtsdiagramm 30 15

16 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 31 Starke Änderungen in UML 2.0 Neue Basis Aktivitätsdiagramme nutzen jetzt bewährte Mittel anderer Diagrammsprachen, 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

17 Notationselemente I Aktionsname 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 33 Notationselemente II Aktion und Signalsender Aktion und Signalempfänger 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

18 Notationselemente III Aktivität Eingangs-/ Ausgangsparameter <<precondition>> <<postcondition>> 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. Cocktail mixen <<precondition>> Durst Zutaten Zutaten mischen in Gläser füllen Cocktail Eis zerkleinern 35 Notationselemente IV Pin-Name Aktionsname Pin-Name Ein- und Ausgabeparameter einer Aktionen können auch durch Pins notiert werden. Aktion Aktionen können andere Aktivitäten aufrufen (Harke). Zutaten Cocktail Getränk Cocktail mixen Feiern Schrank durchsuchen Salzstangen Nahrung 36 18

19 Notationselemente V [Bedingung1] [Bedingung2] Der Verzweigungsknoten spaltet eine Kante in mehrere Alternativen auf (ein Token kann nur eine der ausgehenden Kanten passieren). [Bedingung3] 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. 37 Notationselemente VI Name 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. Bereich1 Bereich2 Aktivitätsbereiche werden verwendet, um Aktionen bestimmten Personen oder Organisationseinheiten zuzuordnen

20 Anwendungsbeispiel Zeitpunkt wählen Gäste einladen Einkaufen [Zusagen < 50%] [Zusagen >= 50%] Essen wegwerfen [Essen verbrannt] Essen kochen Getränke kalt stellen betrunken ins Bett fallen [Essen genießbar] Partyservice bestellen 1 Party abbrechen Feiern Essensreste wegwerfen Nahrung vertilgen Partygäste zählen {weight = 5} [Vorräte vorhanden] [<10% sind noch da] Party beenden [>=10% sind noch da] Müll rausbringen bei Tankstelle nachrüsten [keine Vorräte vorhanden] Vorräte prüfen Warnung der Polizei 1 39 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