UML 2 Tutorial
Transcrição
UML 2 Tutorial
UML 2 Tutorial: Einführung in die neue Standardmodellierungssprache Mario Jeckle Chris Rupp Jürgen Hahn Barbara Zengler UML 2 Tutorial Net.ObjectDays 2003 Seite 1 Darum geht´s Präzisionssteigerung Ideen Übersichtlichkeit Vorschläge UML 2 Standardisierung Roadmap UML 2 Tutorial Net.ObjectDays 2003 Ausführbarkeit Abhängigkeiten Seite 2 Metamodell Praktischer Einsatz VerNeue besserte Diagramme Diagramme Was ist die UML? logische Sicht Use Case - Sicht Wunsch des Kunden Deployment - Sicht Requirements: Das System soll mit C++ realisiert werden Bei Anfrage durch einen Kunden muss die Funktionalität sichergestellt sein Requirements & Use CaseBeschreibungen ... Prozess - Sicht ImplementierungsSicht Datenmodell - Sicht Notation für Modell des Systems zeigt statische und dynamische Aspekte Nicht jede Sicht in jedem System sinnvoll UML 2 Tutorial Net.ObjectDays 2003 Seite 3 UML ... Geschichten von den fremden Meeren der Standardisierung OML Firesmith, HendersonSellers, Page-Jones; 1998 Unified Modeling Language v1.0 Booch, Jacobson, Rumbaugh; 1997 Catalysis D’Souza, Willes; 1996 Unified Method Booch, Rumbaugh; 1995 SOMA Graham; 1994 MOSES Henderson-Sellers; 1994 OBA Rubin; 1992 BON Nerson; 1992 OOA&D Martin, Odell; 1992 OOA Coad, Yourdan; 1991 SCOOP Cherry; 1990 Fusion Coleman, et al.; 1994 OOD Booch; 1992 OMT Rumbaugh, et al.; 1991 OOAD&I Henderson-Sellers, Macrone; 1992 OOSE Jacobson; 1992 OSA Embley; 1991 OOSA Shlear, Mellor; 1991 RDD Wirfs-Brock; 1990 HOOD ESA; 1990 OBA Bailin; 1989 Vom Methodenkrieg ... UML 2 Tutorial Net.ObjectDays 2003 State Charts Harel; 1987 Seite 4 UML ... Fragmentierung Vereinheitlichung Standardisierung Breiteneinsatz Erweiterung Geschichten von den fremden Meeren der Standardisierung OMG Unified Modeling Language 2.0 UML 2 Partners; unveröffentlicht Viele arbeiten für alle OMG Unified Modeling Language 1.5 UML Partners; 2003 Erfahrungen der Anwender OMG Unified Modeling Language 1.4 UML Partners; 2001 Object Management Group übernimmt Copyright OMG Unified Modeling Language 1.3 UML Partners; 1999 Modeling Language 1.2 ) ( OMG Unified UML Partners; 1998 XML Metadata Interchange Einige arbeiten für andere Unified Modeling Language 1.1 UML Partners; 9/1997 Integration der Object Constraint Language Unified Modeling Language 1.0 UML Partners 1/1997 Unified Modeling Language 0.9, 0.91 Booch, Rumbaugh, Jacobson; 1996 Einsatzerfahrung der Sprachschöpfer Unified Method 0.8 Booch, Rumbaugh 1995 OMT Rumbaugh, et al.; 1991 UML 2 Tutorial OOD Booch; 1992 Net.ObjectDays 2003 Wenige arbeiten für einige OOSE Jacobson; 1992 ... zum Standardisierungskrieg ... Seite 5 UML 2 ... Warum eine neue Version? Evolution - Der Markt hat sich bewegt... - Neue Programmiersprachen (z.B. C#, Python, PHP) - Neue Anwendungsdomänen (z.B. Serverprogrammierung, Echtzeitanwendungen) Erfahrung - Für einige Einsatzgebiete bietet UML v1.x ... - Manchmal zu wenig Konstrukte - Manchmal zu viele - Machmal so viele, dass die sinnvolle Auswahl schwerfällt Eliminierung - Einige Programmiersprachen verschwinden (z. B. C++) - Einige früher als modellierungsnah eingestufte Konzepte entwickeln sich inzwischen getrennt von UML weiter (z. B. Entwicklungsprozesse, Codegenerierung) UML 2 Tutorial Net.ObjectDays 2003 Seite 6 UML ... Ein Leiden am Second System Syndrom UML 2 Tutorial Net.ObjectDays 2003 Seite 7 UML 2 Die Ziele Übersichtlichkeit - Weniger graphische Modellkonstrukte - Weniger Basiskonzepte - Wiederverwendung von Basiskonzepten Präzisionssteigerung - Reformulierung des Meta-Modells - Weitestgehende OCL-Verwendung - Unveränderte Wiederverwendung von Basiskonstrukten soweit sinnvoll möglich Ausführbarkeit - Erweiterte Zustandsmaschinen - Stärkere Beziehungen zwischen statischen und dynamischen Diagrammen - Integration erprobter Konzepte außerhalb der UML UML 2 Tutorial Net.ObjectDays 2003 Seite 8 UML 2 Verrentung existierender Modellelemente 1. Durch UML-Werkzeuge nicht implementierte Sprachanteile 2. Durch OO-Methoden unberücksichtigte Sprachelemente 3. Programmiersprachen-spezifische Sprachelemente 4. Inpräzise UML-Sprachelemente UML 2 Tutorial Net.ObjectDays 2003 Seite 9 UML 2 Verrentung existierender Modellelemente 1. Durch UML-Werkzeuge nicht implementierte Sprachanteile 2. Durch OO-Methoden unberücksichtigte Sprachelemente 3. Programmiersprachen-spezifische Sprachelemente 4. Inpräzise UML-Sprachelemente SWE 1 System-Anforderungsanalyse und -Entwurf System SWE 9 SystemEbene System-Integration Systemanforderungen Systemarchitektur Handbuchinformationen Systemintegrationsplan DV-Segment SWE 2 SWE 8 DV-Anforderungsanalyse und -Entwurf DV-Integration SegmentEbene DV-Anforderungen DV-Architektur DV-Integrationsplan SWE 3 SW-Anforderungen Implementierungsdok. (SWKE) SWKEIntegration SW-Anforde rungsanalyse KonfigurationseinheitsEbene SWKE SWE 7 SW-Integration Implementierungsdok. (Komponente) SWE 4 KomponentenIntegration Grobentwurf SW-Architektur Schnittstellenentwurf SWKE-Integrationsplan KomponentenEbene Komponente Implementierungsdok. (Modul) SWE 5 Modul-/DatenbankDatenkatalog SW-Entwurf Ebene Feinentwurf Implementierungsdok. (Datenbank) Modul SWE 6 Datenbank Implementierung Legende: Prüfaktivitäten (siehe QS) Abb. 2.7 Funktionsüberblick Submodell SWE UML 2 Tutorial Net.ObjectDays 2003 Seite 10 UML 2 Verrentung existierender Modellelemente 1. Durch UML-Werkzeuge nicht implementierte Sprachanteile 2. Durch OO-Methoden unberücksichtigte Sprachelemente 3. Programmiersprachen-spezifische Sprachelemente 4. Inpräzise UML-Sprachelemente KlasseA irgend : int ein : bool wichtiges : float Element : byte UML 2 Tutorial Net.ObjectDays 2003 KlasseB «friend» Seite 11 noch : String viel : short wichtiger : float UML 2 Verrentung existierender Modellelemente 1. Durch UML-Werkzeuge nicht implementierte Sprachanteile 2. Durch OO-Methoden unberücksichtigte Sprachelemente 3. Programmiersprachen-spezifische Sprachelemente 4. Inpräzise UML-Sprachelemente Objekt1 : KlasseA irgend = 1 ein = true wichtiges = 3.1 Element = 42 UML 2 Tutorial Net.ObjectDays 2003 «copy» «become» Seite 12 Objekt2 : KlasseA irgend = 1 ein = true wichtiges = 3.1 Element = 42 UML 2 Neu: UML Schichten Ebene 3 Complete Ebene 2 Intermediate Ebene 1 Basic Ebene 0 Foundation Die Idee entstammt der SQL-Standardisierung Operationalisiert den Begriff der UML-Unterstützung Auch weniger UML ist immer noch UML UML 2 Tutorial Net.ObjectDays 2003 Seite 13 Use-Case Akivitätsdiagramm x Sequenzdiagramm x (noch nicht eingeteilt) Gewichtete Kanten, Streaming x (noch nicht eingeteilt) x (noch nicht eingeteilt) Parallelität (noch nicht eingeteilt) x x x Anwendungsfall Einfacher Ablaufplan Ablaufdiagramm x x x Grundlagen UseCases Grundlagen Aktivitäten Grundlagen Sequenzen UML 2 Tutorial Net.ObjectDays 2003 Seite 14 ... complete ... intermediate ... basic ... foundation Struktur und Einbettung von UML 2 Unified Modeling Language 2.0 OCL MOF2 Diagram Interchange Infrastructure Statische Anteile Dynamische Anteile überträgt Superstructure nutzt UML ist nicht mehr eine monolithische Sprache Vier seperate Entwicklungsgruppen werden vier seperate Weiterentwicklungen mit starken inneren Zusammenhang erzeugen UML 2 Tutorial Net.ObjectDays 2003 Seite 15 Struktur und Einbettung von UML 2 Verschiedene Weiterentwicklungsvorschläge: - Infrastructure: 36 Lettern of Intents (LOIs); 5 Einreichungen durch 28 Firmen - Superstructure: 37 LOIs; 5 Einreichungen durch 28 Firmen - OCL: 30 LOIs; 4 Einreichungen durch 10 Firmen - Diagram Interchange: 6 LOIs; 3 Einreichungen durch 6 Firmen Eingereicht durch Einzelfirmen und Konsortien Bezugnehmend auf einzelne Sprachaspekte der UML v1.x um diese neu zu erweitern; Vorschläge für vollständig neue Diagrammtypen oder die Abschaffung Existierender UML 2 Tutorial Net.ObjectDays 2003 Seite 16 Der Weg zu UML 2 Microsoft Hewlett-Packard Oracle Sterling Software MCI Systemhouse Unisys ICON Computing Rational Software 0.9 Ericsson IONA Motorola Telelogic Boldsoft Adaptive Financial System Architects SUN Gentleware DaimlerChrylser IntelliCorp i-Logix IBM ObjecTime Platinum Technology Alcatel Ptech Kabira Taskon Kennedy Carter Reich Technologies SOFTEAM Computer Associates 1.1/2 1.3 1.4 1.5 1.0 OMG EDS Sterling Software ICON Computing ObjecTime Platinum Technology MCI Systemhouse UML 2 Tutorial 2.0 Net.ObjectDays 2003 Seite 17 Microsoft Hewlett-Packard ICON Computing IntelliCorp Ptech Taskon Reich Technologies Vorschläge zur UML 2 Einige komplexe Dinge sollten einfacher werden ... UML 2 Tutorial Net.ObjectDays 2003 Seite 18 Vorschläge zur UML 2 Manchmal sagen Bilder einfach zu wenig ... UML 2 Tutorial Net.ObjectDays 2003 Seite 19 Vorschläge zur UML 2 Superstructure und Infrastructure: Ausgereiftester und mit breiter Unterstützung bedachter Vorschlag durch die sog. „UML2 Partners“: - Mitglieder: Alcatel, Computer Associates, Ericsson, Hewlett-Packard, IONA, Kabira Technologies, Motorola, Oracle, Rational Software, SOFTEAM, Telelogic, and Unisys - Unterstützer: Advanced Concepts Center, Ceira Technologies, Compuware, Commisariat à L´Energie Atomique, DaimlerChrysler, Embarcardero Technologies, Enea Business Software, France Telecom, ... UML 2 Tutorial Net.ObjectDays 2003 Seite 20 UML 2.0 Ablaufplan Ziel: Ein UML 2.0 Standard Infrastructure RFP Überarbeitete Einreichung Erste Einreichung Annahme Superstructure RFP Überarbeitete Einreichung Erste Einreichung Sep 00 UML 2 Tutorial Apr 01 Net.ObjectDays 2003 Seite 21 Jun 01 Annahme Aug 01 Okt 01 Jan 03 Apr 03 Dez 01 Feb 02 Sep 03 UML 2.0 Standardisierungsablauf Komplexer Annahmeprozess Bestätigung durch das OMG Architecture Board Jun 03 Bestätigung durch das OMG Board of Directors Okt 03 ? OMG Mitgliedsabstimmung Sep 04 ? angenommene Spezifikation gültige Spezifikation Ab diesem Zeitpunkt sind UML 2 Artikel, Bücher, Tools, ... Wahrscheinlich zu erwarten Sep 03 ? Jun 04 ? Okt 04 ? OMG Mitgliedsabstimmung UML 2.0 Finalization Task Force (FTF) Bestätigung durch das OMG Board of Directors „offizieller“ Standard (bis Oktober 2004 änderbar) UML 2 Tutorial Net.ObjectDays 2003 Seite 22 Diagramme der UML 2 Diagramme der UML 2 Strukturdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Verhaltensdiagramme Objektdiagramm Verteilungsdiagramm Aktivitätsdiagramm Paketdiagramm Use-CaseDiagramm Interaktionsdiagramme Sequenzdiagramm Interaktionsübersichtsdiagramm Kommunikationsdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 23 Zustandsautomat Zeitverlaufsdiagramm Wie hätten Sie´s denn gern? Rational Unified Process Arte Agiles Vorgehen XP Crystal OEP EOS ASD Lean Software Development V-Modell UML 2 Tutorial Net.ObjectDays 2003 Spiralmodell Unified Process Seite 24 SCRUM Entscheidungshilfe (1): Gibt es Vorschriften? Es gibt Vorschriften Es haben freie Wahl Was wird durch Ihre Umwelt erzwungen? - Standardkonformität erforderlich zwecks Freigabe des Systems (TÜV it, FDA,...)? - Standard/Vorgehensmodell schreibt gewisse Notation vor - Zertifizierbarkeit des Systems erforderlich? Machen Sie das Beste daraus! Sie haben keine Wahl! Allenfalls ergänzende Informationen in anderen Notationen hinzufügen und auf Vorschriften abbilden! UML 2 Tutorial Net.ObjectDays 2003 Seite 25 Entscheidunghilfe (2): Akzeptanz von Formalität Leser akzeptiert Formalismus Was wünschen/ akzeptieren die Stakeholder? - Wie hoch ist die Motivation, sich in Dokumente des Entwicklungsprozesses zu vertiefen? - Welche Grundausbildung haben die Betroffenen? - Aufgeschlossenheit gegenüber neuen Notationen vorhanden? - Starke Fixierung auf die alt bekannte Methode? UML 2 Tutorial Net.ObjectDays 2003 Seite 26 Leser akzeptiert keinerlei Formalismus Prototypen jeglicher Art (Lo-fi, Hi-fi) Entscheiden Sie zwischen „Lesbarkeit“, „Verständlichkeit“ auf der einen Seite und „Prüfbarkeit“, „Automatisierbarkeit“ auf der anderen Seite. Entscheidungshilfe (3): Eignung für die Problemstellung .... Jetzt kommt endlich die Fragen nach dem fachlichen Inhalt, den ein Modell darstellt UML 2 Tutorial Net.ObjectDays 2003 Seite 27 Diagramme der UML und ihre Anwendung I Diagrammtyp Diese zentrale Frage beantwortet das Diagramm Stärken Klassendiagramm Aus welchen Klassen besteht mein System und wie stehen diese untereinander in Beziehung? Beschreibt die statische Struktur des Systems. Enthält alle relevanten Strukturzusammenhänge/Datentypen. Brücke zu dynamischen Diagrammen. Normalerweise unverzichtbar. Paketdiagramm Wie kann ich mein Modell so schneiden, dass ich den Überblick bewahre? Logische Zusammenfassung von Modellelementen. Modellierung von Abhängigkeiten/ Inklusion möglich. Objektdiagramm Welche innere Struktur besitzt mein System zu einem bestimmten Zeitpunkt zur Laufzeit (Klassendiagrammschnappschuss)? Zeigt Objekte u. Attributbelegungen zu einem bestimmten Zeitpunkt. Verwendung beispielhaft zur Veranschaulichung Detailniveau wie im Klassendiagramm. Sehr gute Darstellung von Mengenverhältnissen. UML 2 Tutorial Net.ObjectDays 2003 Seite 28 Diagramme der UML und ihre Anwendung II Diagrammtyp Diese zentrale Frage beantwortet das Diagramm Stärken Kompositionsstrukturdiagramm Wie sieht das Innenleben einer Klasse, einer Komponente, eines Systemteils aus? Ideal für die Top-Down-Modellierung des Systems (Ganz-Teil-Hierarchien). Zeigt Teile eines „Gesamtelements“ und deren Mengenverhältnisse. Präzise Modellierung der TeileBeziehungen über spezielle Schnittstellen (Ports) möglich. Komponentendiagramm Wie werden meine Klassen zu wieder verwendbaren, verwaltbaren Komponenten zusammengefasst und wie stehen diese in Beziehung? Zeigt Organisation und Abhängigkeiten einzelner technischer Systemkomponenten. Modellierung angebotener und benötigter Schnittstellen möglich. Verteilungsdiagramm Wie sieht das Einsatzumfeld (Hardware, Server, Datenbanken, …) des Systems aus? Wie werden die Komponenten zur Laufzeit wohin verteilt? Zeigt das Laufzeitumfeld des Systems mit den „greifbaren“ Systemteilen. Darstellung von „Softwareservern“ möglich. Hohes Abstraktionsniveau, kaum Notationselemente. UML 2 Tutorial Net.ObjectDays 2003 Seite 29 Diagramme der UML und ihre Anwendung III Diagrammtyp Diese zentrale Frage beantwortet das Diagramm Stärken Use-Case-Diagramm Was leistet mein System für seine Umwelt (Nachbarsysteme, Stakeholder)? Außensicht auf das System. Geeignet zur Kontextabgrenzung. Hohes Abstraktionsniveau, einfache Notationsmittel. Aktivitätsdiagramm Wie läuft ein bestimmter flussorientierter Prozess oder ein Algorithmus ab? Sehr detaillierte Visualisierung von Abläufen mit Bedingungen, Schleifen, Verzweigungen. Parallelisierung und Synchronisation. Darstellung von Datenflüssen. Zustandsautomat Welche Zustände kann ein Objekt, eine Schnittstelle, ein Use Case, … bei welchen Ereignissen annehmen? Präzise Abbildung eines Zustandsmodells mit Zuständen, Ereignissen, Nebenläufigkeiten, Bedingungen, Ein- und Austrittsaktionen. Schachtelung möglich. Wer tauscht mit wem welche Informationen in welcher Reihenfolge aus? Darstellung d. Informationsaustauschs zwischen Kommunikationspartnern Sehr präzise Darstellung der zeitlichen Abfolge auch mit Nebenläufigkeiten. UML 2 Tutorial Net.ObjectDays 2003 Seite 30 Diagramme der UML und ihre Anwendung IV Diagrammtyp Diese zentrale Frage beantwortet das Diagramm Stärken Kommunikationsdiagramm Wer kommuniziert mit wem? Wer „arbeitet“ im System zusammen? Stellt den Informationsaustausch zwischen Kommunikationspartnern dar. Überblick steht im Vordergrund (Details und zeitliche Abfolge weniger wichtig). Timingdiagramm Wann befinden sich verschiedene Interaktionspartner in welchem Zustand? Visualisiert das exakte zeitliche Verhalten von Klassen,Schnittstellen,.. Geeignet für die Detailbetrachtungen, bei denen es wichtig ist, dass ein Ereignis zum richtigen Zeitpunkt eintritt. Interaktionsübersichtsdiagramm Wann läuft welche Interaktion ab? Verbindet Interaktionsdiagramme (Sequenz-, Kommunikation- und Timingdiagramme) auf Top-LevelEbene. Hohes Abstraktionsniveau. UML 2 Tutorial Net.ObjectDays 2003 Seite 31 UML 2 – Die Strukturdiagramme Barbara Zengler Mario Jeckle www.uml-glasklar.de UML 2 Tutorial Net.ObjectDays 2003 Seite 32 Zwei Dinge sind zu unserer Arbeit nötig: Unermüdliche Ausdauer und die Bereitschaft, etwas, in das man viel Zeit und Arbeit gesteckt hat, wieder wegzuwerfen. Albert Einstein UML 2 Tutorial Net.ObjectDays 2003 Seite 33 Diagramme der UML 2 Diagramme der UML 2 Strukturdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Verhaltensdiagramme Objektdiagramm Verteilungsdiagramm Aktivitätsdiagramm Paketdiagramm Use-CaseDiagramm Interaktionsdiagramme Sequenzdiagramm Interaktionsübersichtsdiagramm Kommunikationsdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 34 Zustandsautomat Zeitverlaufsdiagramm Die Strukturdiagramme Klassendiagramm Eine Zusammenstellung deklarativ-statischer Modellelemente (d.h. Klassen, Typen, ihre Inhalte und Beziehungen) Objektdiagramm Enthält Objekte und Beziehungsausprägungen Paketdiagramm Stellt die logische Organisation von Modellelementen und deren Abhängigkeiten dar Komponentendiagramm Zeigt die Organisation und Abhängigkeiten von Komponenten Kompositionsstrukturdiagramm Zeigt die interne Struktur eines classifiers sowie seine Möglichkeiten zu Interaktion mit anderen Systemkomponenten Verteilungsdiagramm Zeigt die Ausführungssicht des Systems Strukturdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 35 Objektdiagramm Verteilungsdiagramm Paketdiagramm Warum neue oder geänderte Strukturdiagramme? Strukturdiagramme Hintergrund Statische Modellierung seit Mitte der 1970er Jahre gängig und hinreichend erforscht (z.B. Entity-Relationship) Darstellung nicht ausführbarer statischer Zusammenhänge durch die ersten OO-Modellierungssprachen (u.a. Boochs OOSE, Rumbaughs OMT) weidlich bearbeitet Strukturdiagramme (insbesondere Klassendiagramme) ausgereiftester und stabilster Teil der UML v1.x Jüngere Entwicklungstrends, die eine Neufassung rechtfertigen Metamodellierung Konzeptionelle Bereinigung Wiederverwendung von bestehenden Konstrukten Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 36 Objektdiagramm Verteilungsdiagramm Paketdiagramm Änderungen an den Strukturdiagrammen!? Statische Diagramme besitzen in der UML und ihrer Anwendung eine hervorgehobene Bedeutung Bekanntester Diagrammtyp Meistverwendester Diagrammtyp Basis des UML-Metamodells Basis des UML-Metametamodells (Meta Object Facility) Änderungen „automatisch“ sehr sichtbar für den UML-Anwender „spürbar“ beeinflussen u.U. gesamtes Sprachkonzept wirken sich auf andere (Meta-)Sprachen aus Inhärente Bedeutung für den Modellaustausch zwischen Werkzeugen (XMI-Format wird aus Metamodell generiert) Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 37 Strukturdiagramme Objektdiagramm Verteilungsdiagramm Paketdiagramm Statische Diagramme der UML 2 Diagramme der UML 2 „wichtigster“ Diagrammtyp Strukturdiagramme Klassendiagramm meist-geänderter Diagrammtyp Komponentendiagramm Kompositionsstrukturdiagramm Verhaltensdiagramme Objektdiagramm Verteilungsdiagramm Aktivitätsdiagramm Paketdiagramm Use-CaseDiagramm Interaktionsdiagramme Sequenzdiagramm Interaktionsübersichtsdiagramm Kommunikationsdiagramm Klassendiagramm Komponentendiagramm 5% 15% 45% Objektdiagramm Kompositionsstrukturdiagramm 19% 7% 9% Verteilungsdiagramm Paketdiagramm neuer Diagrammtyp UML 2 Tutorial Net.ObjectDays 2003 Seite 38 Zustandsautomat Zeitverlaufsdiagramm Basiskonzepte Strukturdiagramme Die UML-Basiskonzepte sind Abstraktion Typisierung und Identität Strukturierung (d.h. gekapselte Eigenschaften und vielfältige Beziehungen) Erweiterbarkeit der Sprache Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 39 Objektdiagramm Verteilungsdiagramm Paketdiagramm Basiskonzepte Strukturdiagramme Die UML-Basiskonzepte sind Abstraktion Typisierung und Identität Strukturierung (d.h. gekapselte Eigenschaften und vielfältige Beziehungen) Erweiterbarkeit der Sprache Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm UML 2 ... Erweitert die Nutzung der Classifier Vereinheitlicht ähnliche Konzepte unter gemeinsamen Oberbegriffen Bietet neue Diagrammtypen und -sichten UML 2 Tutorial Net.ObjectDays 2003 Seite 40 Objektdiagramm Verteilungsdiagramm Paketdiagramm Basiskonzepte -- Abstraktion Strukturdiagramme UML 2 ... Erweitert die Nutzung der Classifier Vereinheitlicht ähnliche Konzepte unter gemeinsamen Oberbegriffen Bietet neue Diagrammtypen und -sichten Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm Classifier DataType PrimitiveType Signal Enumeration Class (from Kernel) Association CommunicationPath AssociationClass Activity Actor Behavior Artifact InformationItem Interface BehavioredClassifier Class (from Communications) UseCase Net.ObjectDays 2003 Collaboration StateMachine Class (from StructuredClasses) ProtocolStateMachine Node Interaction Device UML 2 Tutorial StructuredClassifier Seite 41 EncapsulatedClassifier ExecutionEnvironment Basiskonzepte -- Abstraktion Strukturdiagramme UML 2 ... Erweitert die Nutzung der Classifier Beziehungen (Assoziationen) werden zwischen ihnen geknüpft ... können Charakteristika (Attribute) besitzen ... können Verhaltensspezifikationen (Operationen) besitzen ... können generalisiert werden ... können autonom auf Signale reagieren ... können ausschließlich der Strukturierung dienen (abstract) Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Classifier DataType PrimitiveType Signal Enumeration Class (from Kernel) Association CommunicationPath AssociationClass Activity Behavior Interaction Actor Artifact InformationItem Interface BehavioredClassifier Class (from Communications) UseCase Collaboration StateMachine Class (from StructuredClasses) ProtocolStateMachine Node Device UML 2 Tutorial StructuredClassifier Net.ObjectDays 2003 EncapsulatedClassifier ExecutionEnvironment Seite 42 Objektdiagramm Verteilungsdiagramm Paketdiagramm Basiskonzepte -- Abstraktion Strukturdiagramme UML 2 ... Erweitert die Nutzung der Classifier Vereinheitlicht ähnliche Konzepte unter gemeinsamen Oberbegriffen Bietet neue Diagrammtypen und -sichten Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Beispiel: Artefakt kann beliebige paktierbare Elemente „manifestieren“ myWebApp «artifact» .xml .html .class .jsp «manifest» myApp.war Anwendung: Deployment von Webapplikationen UML 2 Tutorial Net.ObjectDays 2003 Seite 43 Paketdiagramm Basiskonzepte -- Abstraktion Strukturdiagramme UML 2 ... Erweitert die Nutzung der Classifier Vereinheitlicht ähnliche Konzepte unter gemeinsamen Oberbegriffen Bietet neue Diagrammtypen und -sichten Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Beispiel: Kompositionsstrukturdiagramm Zeigt die interne Struktur eines Classifiers sowie seine Möglichkeiten zu Interaktion mit anderen Systemkomponenten UML 2 Tutorial Net.ObjectDays 2003 Seite 44 Paketdiagramm Basiskonzepte Strukturdiagramme Die UML-Basiskonzepte sind Abstraktion Typisierung und Identität Strukturierung (d.h. gekapselte Eigenschaften und vielfältige Beziehungen) Erweiterbarkeit der Sprache Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm UML 2 ... Verhältnis zwischen Classifier und typisierten Elementen klarer gefasst Unterschied zwischen „typisiert sein“ und „Typ sein“ verwirklicht Identitätsverhalten geklärt (Insbesondere bei dynamischer Verarbeitung statischer Daten) UML 2 Tutorial Net.ObjectDays 2003 Seite 45 Basiskonzepte – Typisierung und Identität Strukturdiagramme UML 2 ... Verhältnis zwischen Classifier und typisierten Elementen klarer gefasst Unterschied zwischen „typisiert sein“ und „Typ sein“ verwirklicht Identitätsverhalten geklärt (Insbesondere bei dynamischer Verarbeitung statischer Daten) Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm UML 1.x Element Element ModelElement NamedElement name name Namespace GeneralizableElement Classifier UML 2 Tutorial Net.ObjectDays 2003 TypedElement Objektdiagramm Verteilungsdiagramm Paketdiagramm UML 2 Type Classifier Seite 46 Basiskonzepte – Typisierung und Identität Strukturdiagramme UML 2 ... Verhältnis zwischen Classifier und typisierten Elementen klarer gefasst Unterschied zwischen „typisiert sein“ und „Typ sein“ verwirklicht Identitätsverhalten geklärt (Insbesondere bei dynamischer Verarbeitung statischer Daten) Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm UML 2 ... Identitätsbesitz ist nicht mehr statisch über die gesamte Lebensdauer Identitätsbehaftete Objekte können durch dynamische Aktivitäten ihre Identität verlieren oder wechseln Teilweise (beispielsweise in Kollaborationen) ist sie sogar unerheblich UML 2 Tutorial Net.ObjectDays 2003 Seite 47 Basiskonzepte Strukturdiagramme Die UML-Basiskonzepte sind Abstraktion Typisierung und Identität Strukturierung (d.h. gekapselte Eigenschaften und vielfältige Beziehungen) Erweiterbarkeit der Sprache Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm UML 2 ... Assoziationen zur Formulierung von Beziehungen zwischen Classifier-Ausprägungen (viele (unnötige) Einschränkungen) entfallen (z.B. Anwendung auf Use-Cases)) Generalisierungen zur Hierarchisierung von Classifiern (Damit sind z.B. Pakete nicht mehr naiv generalisierbar, hierfür existiert ein separiertes „merge“-Konzept) Abhängigkeitsbeziehungen dokumentieren logische Wechselwirkungen UML 2 Tutorial Net.ObjectDays 2003 Seite 48 Basiskonzepte -- Strukturierung Strukturdiagramme UML 2 ... Assoziationen zur Formulierung von Beziehungen zwischen Classifier-Ausprägungen Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm (viele (unnötige) Einschränkungen) entfallen (z.B. Anwendung auf Use-Cases)) Generalisierungen zur Hierarchisierung von Classifiern (Damit sind z.B. Pakete nicht mehr naiv generalisierbar, hierfür existiert ein separiertes „merge“-Konzept) Abhängigkeitsbeziehungen dokumentieren logische Wechselwirkungen Konstruktion Konstrukteur Änderungswunsch entgegennehmen Kundenbetreuer UML 2 Tutorial Net.ObjectDays 2003 Seite 49 Basiskonzepte -- Strukturierung Strukturdiagramme UML 2 ... Assoziationen zur Formulierung von Beziehungen zwischen Classifier-Ausprägungen Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm (viele (unnötige) Einschränkungen) entfallen (z.B. Anwendung auf Use-Cases)) Generalisierungen zur Hierarchisierung von Classifiern (Damit sind z.B. Pakete nicht mehr naiv generalisierbar, hierfür existiert ein separiertes „merge“-Konzept) Abhängigkeitsbeziehungen dokumentieren logische Wechselwirkungen Kund enbe treue r Konstruktion Konstrukteur Änderungswunsch entgegennehmen Kundenbetreuer UML 2 Tutorial Net.ObjectDays 2003 Seite 50 Basiskonzepte -- Strukturierung Strukturdiagramme UML 2 ... Assoziationen zur Formulierung von Beziehungen zwischen Classifier-Ausprägungen Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm (viele (unnötige) Einschränkungen) entfallen (z.B. Anwendung auf Use-Cases)) Generalisierungen zur Hierarchisierung von Classifiern (Damit sind z.B. Pakete nicht mehr naiv generalisierbar, hierfür existiert ein separiertes „merge“-Konzept) Abhängigkeitsbeziehungen dokumentieren logische Wechselwirkungen Generalization 1 general isSubstitutable Classifier * specific Alle Classifier-Spezialisierungen sind nun spezialisierbar Substituierbarkeit expliziert UML 2 Tutorial Net.ObjectDays 2003 Seite 51 Der Classifier-Zoo Classifier DataType PrimitiveType Signal Enumeration Class (from Kernel) Association CommunicationPath AssociationClass Activity Actor Behavior Artifact InformationItem Interface BehavioredClassifier Class (from Communications) UseCase Collaboration StateMachine Class (from StructuredClasses) ProtocolStateMachine Node Interaction Device Net.ObjectDays 2003 Seite 52 EncapsulatedClassifier ExecutionEnvironment Alle Classifier-Spezialisierungen sind nun spezialisierbar UML 2 Tutorial StructuredClassifier Basiskonzepte -- Strukturierung Strukturdiagramme UML 2 ... Assoziationen zur Formulierung von Beziehungen zwischen Classifier-Ausprägungen Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm (viele (unnötige) Einschränkungen) entfallen (z.B. Anwendung auf Use-Cases)) Generalisierungen zur Hierarchisierung von Classifiern (Damit sind z.B. Pakete nicht mehr naiv generalisierbar, hierfür existiert ein separiertes „merge“-Konzept) Abhängigkeitsbeziehungen dokumentieren logische «stereotype» Wechselwirkungen xml «metaclass» Klasse «persistent, xml» Partyteilnehmer «stereotype» persistent «persistent» Gastgeber Neue Notation (genaugenommen gibt es erstmals eine) Programmiersprachenspezifische Abhängigkeiten entfallen z.B. C++-spezifisches „friend“ UML 2 Tutorial Net.ObjectDays 2003 Seite 54 Klassendiagramm --Das „wichtigste“ Diagramm Strukturdiagramme Komponentendiagramm Klassendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm KlassendiagrammPaketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 55 Klassendiagramm Strukturdiagramme Klassendiagramm Komponentendiagramm Objektdiagramm Funktion: Klassendiagramm Zusammenstellung deklarativ-statischer Modellelemente (d.h. Klassen, Typen, ihre Inhalte und Beziehungen) Kompositionsstrukturdiagramm Verteilungsdiagramm Aufgabe im Projekt: Variierend ... von der ersten Darstellung konzeptueller Dateninhalte über plattformunabhängige logische Modelle bis hin zu „Implementierungsbauplänen“ („Bilder-für-Java“, „Kästchen-und-Strichchen-statt-C++“) Ersetzt oftmals das klassische, in Entity Relationship-Notation abgefasste, Datenmodell UML 2 Tutorial Net.ObjectDays 2003 Seite 56 Paketdiagramm Klassendiagramm Klasse Komposition Strukturdiagramme Klassenname Aggregation abstrakte Klasse Feier Zutat +termin : Datum Klassendiagramm +name : String Kompositionsstrukturdiagramm abbrechen() Rolle Cocktail * 0..* Häppchen Zutaten : Zutat [1..*] isst {ordered} Partyteilnehmer «interface» Esser /betrunken : Boolean = false ~intus : Cocktail [1..*] #begeistert : Begeisterung 1..* iss(in h : Häppchen; return satt:Boolean) #überdenkeBegeisterung() ~trinke(in c : Cocktail) mixt Barmixer Schnittstelle Generalisierung +mixe(in z : Zutat [1..*], out c:Cocktail) 1 Esser Gast 1..* verabschiedet {unique} empfängt {unique} 1..* mixt für Esser Eigenschaftswert Gastgeber Stereotyp treibt an hektisch : Boolean = true 1..1 feiere() Attribut Operation Multiplizität gerichtete Assoziation UML 2 Tutorial Net.ObjectDays 2003 «enumeration» Begeisterung begruesse(in g : Gast) verabschiede (in g : Gast) treibeAn(in b : Barmixer) Assoziation Seite 57 Objektdiagramm VerteilungsPaketdiagramm Klassendiagramm diagramm unterhält besucht Komponentendiagramm ekstatisch verzückt neutral gelangweilt überdrüssig Klassendiagramm Klasse Komposition Strukturdiagramme Klassenname Aggregation Klasse abstrakte Klasse Feier Zutat +termin : Datum Klassendiagramm +name : String Komponentendiagramm Objektdiagramm Kompositionsstrukturdiagramm VerteilungsPaketdiagramm Klassendiagramm diagramm unterhält abbrechen() Rolle Cocktail Sichtbarkeit name (Richtung Name : Typ [Multiplizität]=Vorgabe {Eigenschaft=Wert}) : Rückgabetyp {Eigenschaft=Wert} besucht * 0..* Häppchen Zutaten : Zutat [1..*] isst {ordered} Partyteilnehmer «interface» Esser /betrunken : Boolean = false ~intus : Cocktail [1..*] #begeistert : Begeisterung 1..* [1..3] iss(in h : Häppchen; return satt:Boolean) #überdenkeBegeisterung() ~trinke(in c : Cocktail) mixt Barmixer Schnittstelle Generalisierung +mixe(in z : Zutat [1..*], out c:Cocktail) 1 Esser Gast 1..* verabschiedet {unique} empfängt {unique} 1..* mixt für Esser Eigenschaftswert Gastgeber Sichtbarkeit / name Stereotyp : Typ [Multiplizität] = Vorgabewert {Eigenschaft=Wert} treibt an hektisch : Boolean = true 1..1 feiere() Attribut Operation Net.ObjectDays 2003 «enumeration» Begeisterung begruesse(in g : Gast) verabschiede (in g : Gast) treibeAn(in b : Barmixer) Multiplizität gerichtete Assoziation UML 2 Tutorial Klasse Assoziation Seite 58 ekstatisch verzückt neutral gelangweilt überdrüssig Klassendiagramm Strukturdiagramme Klassendiagramm Neu in UML 2: Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm VerteilungsPaketdiagramm Klassendiagramm diagramm Klasse1 «Abhängigkeitsname» Klasse2 Klasse3 Klasse5 Klasse4 Klasse6 Kommentar zur Abhängigkeitsbeziehung UML 2 Tutorial Net.ObjectDays 2003 Seite 59 Klassendiagramm Strukturdiagramme Komponentendiagramm Neu in UML 2: Klassendiagramm - Attribute besitzen Ordnung - Graphische Assoziationsnotation (Nutzung des „großen leeren Diamanten“auch für binäre Assoziationen) - Kommentarnotation „mit Punkt“ Geändert in UML 2: - Graphische Schnittstellennotation (Lollipops) jetzt Standard - Spezifikation von Sichtbarkeit, Name, Typ und Multiplizität für Operationen und Attribute vereinheitlicht - Multiplizitätsdefinition schärfer formuliert - Attribute sind keine implizite Kompositionsassoziation mehr Entfällt in UML 2: - Programmiersprachenmanifestationsspezifische Eigenschaften (z.B. friend) - Eigenschaften und Stereotypen unklarer Semantik (z.B. become und copy) Klassendiagramm Kompositionsstrukturdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 60 Objektdiagramm Verteilungsdiagramm Paketdiagramm Kompositionsstrukturdiagramm --Ein neues Diagramm in UML 2 Strukturdiagramme Kompositionsstrukturdiagramm Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm UML 2 Tutorial Net.ObjectDays 2003 Objektdiagramm Verteilungsdiagramm Seite 61 Paketdiagramm Kompositionsstrukturdiagramm Strukturdiagramme Kompositionsstrukturdiagramm Funktion: Zeigt die interne Struktur eines Classifiers sowie seine Möglichkeiten zu Interaktion mit anderen Systemkomponenten Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Aufgabe im Projekt: Beschreibung von extern angebotenen Schnittstellen Abstraktion der Operationen und des Signals UML 2 Tutorial Net.ObjectDays 2003 Seite 62 Objektdiagramm Verteilungsdiagramm Paketdiagramm Kompositionsstrukturdiagramm Strukturdiagramme Kompositionsstrukturdiagramm Basiskonzepte: Part Port Kollaboration Konnektor Rollenverwendung UML 2 Tutorial Net.ObjectDays 2003 Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Seite 63 Objektdiagramm Verteilungsdiagramm Paketdiagramm Kompositionsstrukturdiagramm Strukturdiagramme Kompositionsstrukturdiagramm Basiskonzepte: Part Objekte oder Rollenausprägungen Port Öffentlich sicht- und zugreifbarer Interaktionspunkt, der auf einen Operationsaufruf oder den Empfang eines Signals reagiert Kollaboration Zusammenspiel von Operationen oder Classifiern Konnektor Assoziationsinstanz (Link), die Kommunikation zwischen (allgemeinen) Instanzen ermöglicht Rollenverwendung Bindet realisierende Classifier an Kollaborationsinstanz Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 64 Objektdiagramm Verteilungsdiagramm Paketdiagramm Kompositionsstrukturdiagramm Strukturdiagramme Kompositionsstrukturdiagramm Neu in UML 2: Port: Definiert einen öffentlich sichtund zugreifbaren Interaktionspunkt, der auf einen Operationsaufruf oder den Empfang eines Signals reagiert. Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm bereitgestellteSchnittstelle Klasse Verteilungsdiagramm Paketdiagramm partybeschallung Stereoanlage benötigteSchnittstelle UML 2 Tutorial Objektdiagramm Net.ObjectDays 2003 Seite 65 strom, medium Kompositionsstrukturdiagramm Strukturdiagramme Kompositionsstrukturdiagramm Neu in UML 2: Port: Werden durch andere Classifier oder Ports angesprochen. Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm Musikerzeugung Stereoanlage kabel : Steckdose Konnektor Musikerzeugung Konnektor Stereoanlage UML 2 Tutorial Net.ObjectDays 2003 Seite 66 transformator : Hamsterrad Kompositionsstrukturdiagramm Strukturdiagramme Kompositionsstrukturdiagramm Neu in UML 2: Behavior Port: Wie Port, allerdings mit der Einschränkung, dass der definierende Classifier das Verhalten selbst manifestieren muss, andernfalls ist die empfangende Botschaft oder das empfangene Signal verloren. Kann Sichtbarkeits- und Zugriffsbeschränkt sein. Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm partybeschallung Stereoanlage strom, medium UML 2 Tutorial Net.ObjectDays 2003 Seite 67 Objektdiagramm Verteilungsdiagramm Paketdiagramm Kompositionsstrukturdiagramm Strukturdiagramme Kompositionsstrukturdiagramm Überarbeitet in UML 2: Kollaboration: Visualisiert das Zusammenspiel von Operationen oder Classifiern UML 2 Tutorial Net.ObjectDays 2003 Seite 68 Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm Kompositionsstrukturdiagramm Strukturdiagramme Kompositionsstrukturdiagramm Überarbeitet in UML 2: Kollaboration: Visualisiert das Zusammenspiel von Operationen oder Classifiern UML 2 Tutorial Net.ObjectDays 2003 Seite 69 Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm Kompositionsstrukturdiagramm Strukturdiagramme Überarbeitet in UML 2: Beispiel: Kompositionsstrukturdiagramm Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 70 Objektdiagramm Verteilungsdiagramm Paketdiagramm Kompositionsstrukturdiagramm Strukturdiagramme Überarbeitet in UML 2: Beispiel: Kompositionsstrukturdiagramm Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 71 Objektdiagramm Verteilungsdiagramm Paketdiagramm Kompositionsstrukturdiagramm Strukturdiagramme Kompositionsstrukturdiagramm Neu in UML 2: - Der gesamte Diagrammtyp - Ports als gemeinsame Abstraktion von Operationen und Signalen - Auffassung von Kollaborationen als Teile von Kompositionsstrukturen Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Verteilungsdiagramm Geändert in UML 2: - Schnittstellennotation - Möglichkeiten zur Darstellung von Kollaborationen UML 2 Tutorial Net.ObjectDays 2003 Seite 72 Objektdiagramm Paketdiagramm Verteilungsdiagramm --Das Diagramm mit den meisten Änderungen Strukturdiagramme Verteilungsdiagramm Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm UML 2 Tutorial Net.ObjectDays 2003 Objektdiagramm Verteilungsdiagramm Seite 73 Paketdiagramm Verteilungsdiagramm Strukturdiagramme Verteilungsdiagramm Funktion: Zeigt die Ausführungssicht des Systems Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Paketdiagramm Aufgabe im Projekt: Beschreibung der Systemarchitektur Erweitert Systemsicht um an der Ausführung beteiligte oder zur Ausführung benötigte Hardwarekomponenten UML 2 Tutorial Net.ObjectDays 2003 Seite 74 Verteilungsdiagramm Strukturdiagramme Verteilungsdiagramm Basiskonzepte: Artefakt Physische Informationseinheit, die während des Entwicklungsprozesses erzeugt oder verwendet wird. (z.B. Modelle, Quellcode, Objekdateien, ...) Knoten Classifier, der eine zur Ausführungszeit verfügbare Ressource darstellt. Einsatzspezifikation (Deployment Specification) Paramtermenge, die Laufzeitverhalten festlegt Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 75 Objektdiagramm Verteilungsdiagramm Paketdiagramm Verteilungsdiagramm Strukturdiagramme Verteilungsdiagramm Knoten Klassendiagramm Komponentendiagramm Objektdiagramm Artefakt Kompositionsstrukturdiagramm «device» : Application Server «artifact» «execution environment» J2EE Server : J2EE Server «deploy» application.jar entry.jsp config.xml MyBean.class Deployment-Beziehung 1..* 1..* Assoziation execution : thread transaction : false «device» : DB Server Deployment-Spezifikation UML 2 Tutorial Net.ObjectDays 2003 «deployment spec» appDesc.xml Seite 76 Verteilungsdiagramm Paketdiagramm Verteilungsdiagramm Strukturdiagramme Verteilungsdiagramm Neu in UML 2: - Aktuelle Ausführungs- und Laufzeitumgebungen wie J2EE und .NET werden besser berücksichtigt Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm Geändert in UML 2: - Knoten können hinsichtlich ihrer Rollen zum Ausführungszeitpunkt feinspezifiziert werden - Ausdetaillierung der Abhängigkeitsbeziehungen Entfällt in UML 2: - Unpraktikable graphische Darstellung des Knotens UML 2 Tutorial Net.ObjectDays 2003 Seite 77 Paketdiagramm Fazit --statische Diagramme in UML 2 Absichtsvoll wenig „spürbar“ Neues - Im Hintergrund - Klarere Basiskonzepte - Deutlich mehr Wiederverwendung - Fast vollständig neues Metamodell Modifizierte Semantik vieler (Meta-)Modellelemente Einige neue graphische Primitive Reichhaltigeres Angebot an Abhängigkeiten und „eingebauten“ Modellerweiterungen (Stereotypen) Behutsame Verrentung „problematischer“ Modellelemente UML 2 Tutorial Net.ObjectDays 2003 Seite 78 UML 2 – Die Verhaltensdiagramme Chris Rupp Jürgen Hahn www.uml-glasklar.de UML 2 Tutorial Net.ObjectDays 2003 Seite 79 Diagramme der UML 2 Diagramme der UML 2 Strukturdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Verhaltensdiagramme Objektdiagramm Verteilungsdiagramm Aktivitätsdiagramm Paketdiagramm Use-CaseDiagramm Interaktionsdiagramme Sequenzdiagramm Interaktionsübersichtsdiagramm Kommunikationsdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 80 Zustandsautomat Zeitverlaufsdiagramm Use-Case-Diagramm „Die Neugier steht immer an erster Stelle eines Problems, das gelöst werden will.“ Galileo Galilei UML 2 Tutorial Net.ObjectDays 2003 Seite 81 Use-Case-Diagramm Anwendung im Projekt Darstellung der funktionalen Dienstleistungen eines Systems Abgrenzung des Systems gegenüber seiner Umwelt Aufteilen des Systems aus einer Außensicht Erstellung planbarer Einheiten Schaffen einer Kommunikationsgrundlage zwischen Stakeholdern UML 2 Tutorial Net.ObjectDays 2003 Seite 82 Use-Case-Diagramm Die Elemente im Überblick System Anwendungsfall Benutzer Use-Case Beziehung UML 2 Tutorial Subject Akteur «include» «extend» «include»-Beziehung «extend»-Beziehung Net.ObjectDays 2003 Seite 83 Generalisierungsbeziehung Use-Case-Diagramm Use-Case: - spiegelt ein funktionales Verhalten wieder - wird durch Akteur angestoßen - liefert ein für den Akteur sichtbares Ergebnis Akteur: - beschreibt eine Rolle - steht außerhalb des Systems - interagiert mit dem System - kann eine Person, ein Nachbarsystem, .... sein UML 2 Tutorial Net.ObjectDays 2003 Seite 84 Use-Case-Diagramm System (Betrachtungsgegenstand): - Umgrenzt die Einheit, welche die Use-Cases realisiert - Darstellung ist nicht zwingend notwendig Assoziationen: - beschreiben die Beziehungen zwischen Akteuren und UseCases - «Extend»-Beziehung: Verhalten eines Use-Case kann durch einen anderen erweitert werden - «Include»-Beziehung: Verhalten eines Use-Case ist vollständig in einem anderen enthalten UML 2 Tutorial Net.ObjectDays 2003 Seite 85 Use-Case-Diagramm Die Anwendung Systemname Use-Case Akteur Systemgrenze Verkauf Kunde nicht gefunden Verkaufsposten eingeben «extend» ExtendBeziehung extension points: fehlender Kunde Verkäufer «include» Assoziation UML 2 Tutorial Net.ObjectDays 2003 Kreditwürdigkeit prüfen Seite 86 Kundendaten einsehen IncludeBeziehung Use-Case-Diagramm Die Anwendung Finanzamt Steuern hinterziehen - Einkommen - Vermögen + Belege fälschen() + Privat-/Geschäftskosten vermischen() Lohnsteuerkarte beantragen Bürger - Familienstand - Steuerklasse + Formular ausfüllen() + Karte ausdrucken() Steuern zahlen Auskunft über Finanzen geben - Einkommen - Vermögen + Belege zeigen() + Einkommensbeleg vorlegen() UML 2 Tutorial Net.ObjectDays 2003 Seite 87 Use-Case-Diagramm Kontextabgrenzung Abgrenzung von Systemen zu ihren Nachbarsystemen Bestellung Fast Food Restaurant Rechnung Kunde Geld Nahrung Bestellung Geld Rechnung Zulieferer Waren Richtlinien Geld Bestätigung Zinsen Amt UML 2 Tutorial Net.ObjectDays 2003 Seite 88 Bank Use-Case-Diagramm Die wichtigsten Änderungen UML 1.x UML 2 Ein Akteur darf unbenannt sein Ein Akteur muss einen Namen haben Nur Pakete können Use-Cases besitzen. Classifier im Allgemeinen können Use-Cases besitzen. Als Realisierer von Use-Cases werden (Sub-) Systeme impliziert, obwohl jeder Classifier einen Use-Case realisieren darf. Es wird deutlich herausgestellt, dass alle Classifier Use-Cases realisieren können. Bei der «extend»-Beziehung werden die Vorbedingungen nur in der Nähe der entsprechenden Relation angetragen: Die Vorbedingung und die entsprechenden extension points werden als Notiz an die Erweiterungsbeziehung angehängt: «Vorbedingung» {Benutzer ruft Hilfefunktion auf} extension point: Hilfethema Benutzer ruft Hilfefunktion auf «extend» «extend» UML 2 Tutorial Net.ObjectDays 2003 Seite 89 Use-Case-Diagramm Vorsicht: Fehler die vermieden werden sollten Use-Case Name fehlt Akteur muss außerhalb des Systems stehen Verkauf Assoziationen dürfen nur binär sein Verkäufer Kreditwürdigkeit prüfen Bezeichnung des Akteurs fehlt Angabe des Erweiterungspunktes fehlt UML 2 Tutorial Net.ObjectDays 2003 Kundendaten einsehen «extend» Bürgen finden Kunde nicht gefunden Zwischen Use-Cases des selben Systems dürfen keine Assoziationen vorhanden sein Seite 90 Aktivitätsdiagramm „Wenn du etwas so machst, wie du es seit zehn Jahren gemacht hast, dann sind die Chancen recht groß, daß du es falsch machst.“ Charles Kettering UML 2 Tutorial Net.ObjectDays 2003 Seite 91 Aktivitätsdiagramm Anwendung im Projekt Aktivitätsdiagramme visualisieren mögliche Abläufe mit veränderbarem Detaillierungsgrad vielfache Anwendungsgebiete Geschäftsprozessmodellierung Beschreibung von Use-Cases Implementieren einer Operation UML 2 Tutorial Net.ObjectDays 2003 Seite 92 Aktivitätsdiagramm Das Tokenkonzept Das Tokenkonzept wurde den Petrinetzen entnommen Der Ablauf in einer Aktivität wird durch den Tokenfluss gesteuert Ermöglicht die präzise Beschreibung des Verhaltens Die Token sind nur ein Gedankenkonstrukt (keine explizite Modellierung) Aktion 1 Aktion 2 Achtung! Tokenkonzept bewirkt semantische Änderungen zu UML 1.x Aktion 1 Aktion 2 Aktion 1 Aktion 2 UML 2 Tutorial Net.ObjectDays 2003 ODER UND Aktion 3 Aktion 3 UML 1.x UML 2 Seite 93 Aktivitätsdiagramme Die wichtigsten Elemente im Überblick Aktivität Aktionsname Objekttyp Aktion Objektknoten Strukturierte Knoten Eingangsparameter Ausgangsparameter Kontrollelemente Name UML 2 Tutorial Startknoten Verzweigungsknoten Parallelisierungsknoten Endknoten Verbindungsknoten Synchronisationsknoten Net.ObjectDays 2003 Seite 94 Kante Aktivitätsdiagramm Aktivität - Aktion Aktivität beschreibt das komplette Diagramm Aktivität Kann Ein- und Ausgangsparameter haben Aktion Cocktail mixen Zutaten Zutaten mischen in Gläser füllen Cocktail Eis zerkleinern Ausgangsparameter Eingangsparameter Aktionen sind Verhaltensaufrufe Summe der Aktionen realisiert die Aktivität UML 2 Tutorial Net.ObjectDays 2003 Seite 95 Aktivitätsdiagramm Objektknoten Objektknoten repräsentieren nicht das Objekt selber, sondern den Typ des Objekts Darstellung als Objektknoten oder durch Pin-Notation Cocktail mixen Cocktail Cocktail mixen Objektknoten als Datenspeicher «datastore» Name [Zustand] Net.ObjectDays 2003 Seite 96 Cocktail Cocktail trinken «centralBuffer» UML 2 Tutorial Cocktail Aktivitätsdiagramm Kontrollelemente I Kontrollelemente steuern den Ablauf der Aktivität Kontrollelemente - starten und beenden Abläufe - ermöglichen parallele Abläufe - können mehrere Abläufe synchronisieren - lassen alternative Abläufe zu möglicher Ablauf Einladung bekommen Einladung Datum prüfen Kante [Zeit vorhanden] Lust auf Feier prüfen [keine Zeit] Bedingung [keine Lust] [Lust vorhanden] Kontrollknoten Feier absagen UML 2 Tutorial Net.ObjectDays 2003 Seite 97 Zur Feier zusagen Aktivitätsdiagramm Kontrollelemente II Startknoten: - Starten den Ablauf - Mehrere Startknoten initiieren parallele Abläufe Startknoten Endknoten: - Beenden die Aktivität oder - einen einzigen Ablauf Endknoten Kanten: - Übergänge zwischen zwei Knoten - Beschreiben die Ablaufrichtung UML 2 Tutorial Net.ObjectDays 2003 Seite 98 Kante Aktivitätsdiagramm Kontrollelemente III Verzweigungsknoten: - Ermöglichen alternative Abläufe - Bedingungen geben Ablaufrichtung vor Verbindungsknoten: - Vereinigen mehrere Abläufe Verzweigungsknoten Verbindungsknoten Parallelisierungsknoten: - Aufteilen in parallele Abläufe Parallelisierungsknoten Synchronisationsknoten: - Zusammenführen paralleler Abläufe Synchronisationsknoten UML 2 Tutorial Net.ObjectDays 2003 Seite 99 Aktivitätsdiagramm Unterbrechungsbereich und Exception-Handler Unterbrechungsbereich: - Umfasst ein oder mehrere Aktionen - Kann über Unterbrechungskante verlassen werden - Alle Aktionen im Bereich werden dann gestoppt Unterbrechungsbereich Exception-Handler: - Ermöglicht die Beschreibung von Ausnahmen - Exception-Handler substituiert eine Aktion Aktion ExceptionHandler ExceptionTyp UML 2 Tutorial Net.ObjectDays 2003 Seite 100 Unterbrechungskante Strukturierte Knoten Umfassen mehrere Elemente einer Aktivität Ablauf startet erst dann, wenn an allen eingehenden kanten Token anliegen Objektknoten als Ein- und Ausgangsparameter möglich Schlüsselwort UML 2 Tutorial Net.ObjectDays 2003 Seite 101 Strukturierte Knoten Entscheidungsknoten Visualisierung komplexer Entscheidungen if: prüfen der Bedingung Speise then: auszuführende if Speise bewerten Elemente else: möglicher Ablauf, wenn kein if-Bereich then Gute Kritik erstellen zutrifft else if: wie if-Bereich Restaurant nur mit Schlechte Kritik erstellen vorgegebener else Prüfreihenfolge UML 2 Tutorial Net.ObjectDays 2003 Seite 102 schmackhaft? Bewertung Strukturierte Knoten Mengenverarbeitung Einzelne Betrachtung der Elemente welche in der restlichen Aktivität nur als Sammlung betrachtet werden z.B. Vektorkomponenten, hashtable, verkettete Listen.... Elemente werden als Objektknoten (Pin) übergeben iterative Bierkiste besorgen UML 2 Tutorial Flasche öffnen Net.ObjectDays 2003 Flasche leeren Seite 103 leere Bierkiste zurückgeben Strukturierte Konten Schleifenknoten Visualisieren den Ablauf komplexer Schleifen for: initiale Aufgaben while: prüfen der Bedingung für einen Durchlauf do: Schleifenrumpf for Zahl 1 Zahl 2 X = Zahl 1 Y = Zahl 2 while A = X+ Zähler Reihenfolge do – while ist optional A<Y do Zähler = Zähler +1 UML 2 Tutorial Net.ObjectDays 2003 Seite 104 Zähler = 0 Aktivitätsdiagramm Aktivitätsbereiche Einteilen des Diagramms in Bereiche mit gemeinsamen Eigenschaften Hierarchische und mehrdimensionale Aufteilung möglich Fastfood-Restaurant besuchen Person Bereichsname UML 2 Tutorial PKW ausparken Bedienung PKW parken Ort Parkplatz Kunde Restaurant Menü bestellen Net.ObjectDays 2003 Seite 105 Menü verzehren Menü zusammenstellen Kassieren Aktivitätsdiagramm Die wichtigsten Änderungen UML 1.x UML 2 Aktivitätsdiagramm als „Sonderform“ des Zustandsdiagramms. Aktivitäten sind unabhängig von Zustandsautomaten. Aktivitätsdiagramme entsprechen in der Struktur den Zustandsdiagrammen. Aktivitäten verwenden eine den Petri-Netzen ähnlich Semantik (Token-Konzept). Diagramm heißt Aktivitätsdiagramm. Diagramm wird als Aktivität bezeichnet. Es ist nur ein Anfangszustand erlaubt. Es sind mehrere Startknoten erlaubt. Aktivitätsdiagramme haben keine Ein- und Ausgabeparameter. Aktivitäten können Ein- und Ausgabeparameter enthalten. Parallele Stränge müssen zusammengeführt werden. Parallel Abläufe müssen nicht wieder zusammengeführt werden. Swimlanes sind immer eindimensional Aktivitätsbereiche können hierarchisch oder multidimensional sein. Notationssymbole für Zustand und Aktivität unterschiedlich: Die Notation von Aktionen entspricht der Notation von Zuständen der UML 1.x Aktionszustand1 UML 2 Tutorial Net.ObjectDays 2003 Zustand Aktion Seite 106 Zustand Aktivitätsdiagramm Vorsicht: Fehler die vermieden werden sollten Fehlende Bedingungen Biergarten Biergarten betreten Sitzplatz suchen Bier bestellen Durch vorherige Verzweigung ist hier eine Synchronisation nicht möglich Bier trinken Fehlender Pin Fehlender Aktionsname Biergarten verlassen UML 2 Tutorial Net.ObjectDays 2003 bezahlen Seite 107 Zustandsautomaten „Take your chance while you still got a choice.“ Scott/Young/Young UML 2 Tutorial Net.ObjectDays 2003 Seite 108 Zustandsautomat Einfaches Beispiel sm Scheibenwischer [Wischer in Parkposition] Nachwischen Wa Ausgangsstellung entry / in Parkposition bringen [Wischer in Parkposition] after(3seconds) / Waschen beenden Waschen gewählt Fertigwischen entry / in Parkposition bringen Wischen gewählt Waschen gewählt Wischen beendet Wischen do / normal wischen Wischen [schnell] / schnell wischen Wischen [Intervall] / Intervall wischen [Wischer in Parkposition] Waschen do / Waschen Waschen Wi do / Waschen after(3seconds) / Waschen beenden Nachwischen Wi entry / in Parkposition bringen UML 2 Tutorial Net.ObjectDays 2003 Seite 109 Zustandsautomat Anwendung im Projekt Zustandsautomaten bilden Verhalten ab: - in welchem Zustand kann - unter welcher Bedingung - bei welchem eingehenden Ereignis - welche Transition ausgeführt werden Anwendungsgebiete - Zustandsbeschreibung von Classifiern, u. a. - Detaillierung von Use-Cases - Verhaltensbeschreibung von Interfaces und Ports - Detailbeschreibung von Signal- und Ereignisempfang UML 2 Tutorial Net.ObjectDays 2003 Seite 110 Zustandsautomat Die wichtigsten Elemente im Überblick sm Zustandsautomat Zustandsname Zustandsname Unterzustandsautomatenzustand : sm Unterzustandsautomat einfacher Zustand Unterzustandsautomatenzustand zusammengesetzter Zustand Trigger [Guard] / Aktivität [Vorbedingung] Operation / [Nachbedingung] Transition in Verhaltenszustandsautomaten Endzustand Transition in Protokollzustandsautomaten Pseudozustände Startzustand Gabelung UML 2 Tutorial Net.ObjectDays 2003 Kreuzung Entscheidung Vereinigung Seite 111 Austrittspunkt H H* flache Historie tiefe Historie Eintrittspunkt Terminator Zustandsautomat Zustandsautomat Unterscheidung: - Verhaltenszustandsautomaten - Protokollzustandsautomaten sm Zustandsautomatenname Ein Verhaltenszustandsautomat bildet das diskrete Verhalten einer Instanz eines Classifiers ab. Ein Protokollzustandsautomat beschreibt die erlaubte Aufrufsabfolge der Instanz eines Classifiers. UML 2 Tutorial Net.ObjectDays 2003 Seite 112 sm Zustandsautomatenname {protocol} Zustandsautomat Protokollzustandsautomat sm Ampel [aus] / rot(an) / rot [reset] schalte(rot) / schalte(rot) / gelb gelb(an) / schalte(gelb) / grün rot-gelb schalte(grün) / UML 2 Tutorial Net.ObjectDays 2003 Seite 113 Zustandsautomat einfacher Zustand und Transition Ein Zustand beschreibt eine bestimmte Ausprägung: - eine statische Situation - auf ein externes Ereignis wartend Kann Aktivitäten enthalten: - entry, do und exit activity - interne Transitionen - verzögerte Ereignisse Eine Transition ist der Übergang von einem Quell- zu einem Zielzustand Zustandsname Zustandsname entry / Aktivität exit / Aktivität do / Aktivität Trigger [Guard] / Aktivität Trigger [Guard] / defer [Vorbedingung] Operation / [Nachbedingung] Trigger [Guard] / Aktivität Transitionen in Verhaltenszustandsautomaten UML 2 Tutorial Net.ObjectDays 2003 Protokollzustandsautomaten Seite 114 Zustandsautomat Zustandsübergänge Verschiedenste Möglichkeiten einen Zustandsübergang anzustoßen Fertigwischen closed [Wischer in Parkposition] Ausgangsstellung entry / in Parkposition bringen [passiv offen] TCB erstellen [geschlossen] TCB löschen Stufe 1 listen do / langsam drehen PKW neu angemeldet PKW gebraucht do/ benutzen Stufe2 gewählt / schalte 2 Stufe1 gewählt / schalte 1 Stufe 2 aktiv UML 2 Tutorial after(60 seconds) Net.ObjectDays 2003 standby Seite 115 do / schnell drehen Zustandsautomat zusammengesetzter Zustand Setzt sich aus Zuständen, Pseudozuständen und Transitionen zusammen Zustandsname entry / Aktivität exit / Aktivität do / Aktivität Trigger / Aktivität Trigger / defer Zustandsname entry / Aktivität exit / Aktivität do / Aktivität Trigger / Aktivität Trigger / defer aktiv gedrückt [anykey] abgebrochen A Startort eingegeben Ziel gewählt rückgängig Zielort eingegeben rückgängig Termin gewählt Termin gewählt bestätigt / drucken gedruckt UML 2 Tutorial Net.ObjectDays 2003 Seite 116 B Zustandsautomat Unterzustandsautomatenzustand Steht stellvertretend für einen Zustandsautomaten Kann Ein- und Austrittspunkte besitzen sm Bezahlung Auswahl bestätigt [Z_art = BG] [Z_art = GK] abwickelnBezahlung : sm Bezahlung / ausgeben Getränk Bezahlen Bargeld : sm BB Bezahlen Geldkarte : sm BG [ok] / abbuchen [ok] / abbuchen Abbruch abgebrochen UML 2 Tutorial Net.ObjectDays 2003 Seite 117 abgebrochen Abbruch Zustandsautomat Region Verwendung von Regionen impliziert Parallelität Erreichbar durch Verwendung von: - Gabelungszuständen, oder - Startzuständen (einer pro Region) Flasche geöffnet offen Flasche geöffnet Temperatur Blubbereffekt kalt sprudelnd offen kalt after (Zeit) UML 2 Tutorial sprudelnd after (Zeit) warm still Temperatur Blubbereffekt Net.ObjectDays 2003 Seite 118 after (Zeit) warm after (Zeit) still Zustandsautomat Pseudozustände I Startzustand: - Verweist auf den ersten Zustand - Einer pro Region Entscheidung: - Ausgehende Transition wird während der Ausführung der Transition bestimmt Kreuzung: - Ausgehende Transition ist vor der Ausführung der Transition bekannt Ein- und Austrittspunkt: - Zum Betreten und Verlassen von Unterzustandsautomaten UML 2 Tutorial Net.ObjectDays 2003 Seite 119 Startzustand Entscheidung Kreuzung Austrittspunkt Eintrittspunkt Zustandsautomat Pseudozustände II Gabelung und Vereinigung: - Teilen eine Transition auf mehrere parallele Zustände auf bzw. fügen mehrere Transitionen zu einer zusammen Flache Historie: - Speichert den zuletzt aktiven Unterzustand eines komplexen Zustands Tiefe Historie: - Speichert den zuletzt aktiven Unterzustand eines in einem komplexen Zustand enthaltenen Zustand Terminator: - Bei Erreichen endet die Lebensdauer der Instanz des beschriebenen Classifiers UML 2 Tutorial Net.ObjectDays 2003 Seite 120 Gabelung Vereinigung H flache Historie H* tiefe Historie Terminator Zustandsautomat Beispiele Pseudozustände Betriebsmodi Autoradio probiert Prüfung Trinkbarkeit eingeschalten Trinkbarkeit geprüft do / Trinkbarkeit prüfen getrunken H Zustand3 manuell umgeschaltet [Kassette drin] [ist ok = ja] trinken manuell umgeschaltet [keine Kassette drin] [Kassette ausgeworfen] umschalten Kassette eingelegt Zustand2 [ist ok = nein] wegschütten ausgeschalten manuell umschalten [CD-Kassette drin] manuell umgeschaltet Zustand1 A do / x = 1 A do / x = 1 Trigger / x = -1*x Trigger / x = -1*x x [x<0] B UML 2 Tutorial Net.ObjectDays 2003 [x>=0] C Seite 121 [<0] [>=0] B C Zustandsautomat Explicit und default entry Default entry: Eine eingehende Transition endet am Rand des zusammengesetzten Zustands. default entry A B default entry Explicit entry: Eine eingehende Transition endet an einem Unterzustand des zusammengesetzten Zustands A A explicit entry B explicit entry explicit entry A UML 2 Tutorial Net.ObjectDays 2003 Seite 122 B Zustandsautomat Verlassen von Zuständen Das Verlassen von zusammengesetzten Zuständen und Zustandsautomaten kann auf verschiedene Arten erfolgen gesperrt [else] / einschalten [Pin unterdrückt] / einschalten A B Pin unterdrückt sm Authentifizierung X Trigger1 [Guard] / Aktivität Authentifizierung : sm Authentifizierung Pin eingeben / Eingabe# = 0 Y Pincodeabfrage do / Pincode prüfen C Trigger2 [Guard] / Aktivität Pincode geprüft Z [#<3] [Pin = falsch] / Eingabe#++ Fehleingabe do / Eingabe# prüfen [Pin = richtig] Pin unterdrückt UML 2 Tutorial Net.ObjectDays 2003 Seite 123 authentifiziert [#>=3] gesperrt Zustandsautomat Vererbung Spezialisierung von Zustandsautomaten durch - Erweiterung um Regionen, Zustände und Transitionen - Erweiterung von Regionen und Zuständen - Erweiterung von Transitionen sm Geldautomat {extended} sm Geldautomat Karte prüfen {final} Betrag einlesen {extended} Karte angenommen defekt {final} defekt anderer Betrag gewählt Betrag wählen Betrag gewählt Transaktion bestätigen {final} UML 2 Tutorial Betrag wählen Betrag eingeben Transaktion nicht bestätigen Karte ausgegeben {final} Net.ObjectDays 2003 ok Transaktion bestätigen {final} Seite 124 Zustandsautomat Die wichtigsten Änderungen UML 1.x UML 2 - Ports können nun Protokollzustandsautomaten besitzen. - Ein-, Austrittspunkte und Terminatoren wurden eingeführt. Tiefe Historien können nur eingehende Transitionen von außerhalb des enthaltenden Zustands haben. Tiefe Historien können auch Ziel einer Transition innerhalb des enthaltenen Zustands sein (also nicht nur von außen). - Regeln zur Ergänzung und Ersetzung von Transitionen bei vererbten Zustandsautomaten wurde hinzugefügt. Generalisierung von Zustandsautomaten wird durch eine Notiz kenntlich gemacht. Das vererbte Verhalten wird mit einem Zustandsautomaten dargestellt. UML 2 Tutorial Net.ObjectDays 2003 Seite 125 Zustandsautomat Vorsicht: Fehlerteufel Nur ein Startzustand pro Region gestattet sm Fehlerbeispiel Bei Startzuständen nur eine ausgehende Transition erlaubt A B C Vereinigung nicht orthogonaler Zustände nicht möglich Transition ohne Zielzustand Ausgehende Transition in einem Endzustand Transition ohne Quellzustand UML 2 Tutorial Net.ObjectDays 2003 D Seite 126 Interaktionsmodellierung mit der UML 2 „Auch in der Kommunikation gilt das Gesetz des abnehmenden Grenznutzens: Immer mehr Aufwand bringt – ab einem gewissen Punkt – immer weniger Erfolg.“ Michael Tost UML 2 Tutorial Net.ObjectDays 2003 Seite 127 Interaktionen Definition und Prinzip Interaktionen sind ein wichtiges Basiskonzept der UML-Verhaltensdiagramme Interaktion ist der Nachrichten- und Datenaustausch zwischen zwei Kommunikationspartnern Grundelemente der Interaktion: - Kommunikationspartner (repräsentiert durch Lebenslinien) Sender Empfänger - Nachrichten Nachrichtenaustausch verbindet Sende- und Nachricht Empfangsereignisse Sendeereignis UML 2 Tutorial Net.ObjectDays 2003 Seite 128 Empfangsereignis Interaktionen Wann modelliere ich Interaktionen im Projekt? Modellierung von Interaktionen auf verschiedenen Abstraktionsebenen vielfache Einsatzmöglichkeiten Lokale oder verteilte Kommunikation Beschreibung von Use-Cases Detailmodellierung im Feindesign Spezifikation von Schnittstellen Test und Simulation UML 2 Tutorial Net.ObjectDays 2003 Seite 129 Interaktionen Welche UML 2 Diagramme gibt es zur Interaktionsmodellierung? Diagramme der UML 2 Strukturdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Verhaltensdiagramme Objektdiagramm Verteilungsdiagramm Aktivitätsdiagramm Paketdiagramm Use-CaseDiagramm Interaktionsdiagramme Sequenzdiagramm Interaktionsübersichtsdiagramm Kommunikationsdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 130 Zustandsautomat Timing-Diagramm Interaktionen Sichten auf Interaktionen Interaktionsdiagramme zeigen nur Sichten auf Interaktionen Diagrammwahl nach hervorzuhebenden Modellierungsaspekt Kommunikationsdiagramm 1: Temp_einstellen :Koch :Herd :Koch :Herd Temp_einstellen :Herd Lebenslinie Temp_einstellen Nachricht :Koch Sequenzdiagramm Timing-Diagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 131 Sequenzdiagramm „Erst die richtige Reihenfolge macht aus klugen Gedanken ein gutes Ergebnis.“ A. van Rheyn UML 2 Tutorial Net.ObjectDays 2003 Seite 132 Sequenzdiagramm Kommunikationspartner sd Interaktion K1 K2 K3 Lebenslinie Nachricht1(Argument) Zeitlicher Verlauf Ok=Nachricht1 Nachricht2 Aktionssequenz Nachricht UML 2 Tutorial Net.ObjectDays 2003 Seite 133 Sequenzdiagramm Kontextabgrenzung sd Waschmaschine :Waschmaschine Benutzer :Stromnetz :Wasserleitung befüllen Waschmittel_zugeben Weichspüler_zugeben Programm_wählen Einheit Minuten Strom einschalten Wasser {30...90} Abwasser fertig auschalten aus Wäsche_entnehmen UML 2 Tutorial Net.ObjectDays 2003 Seite 134 :Kanal Sequenzdiagramm Beschreibung von Use-Cases Use-Case-Diagramm Sequenzdiagramm sd Wäsche waschen Waschmaschine :Benutzer Wäsche trocknen :Steuerung einschalten «extend» :Wasserventil :Heizelement öffnen Hausmann Wäsche waschen Wasser erhitzen(Temperatur=30°) schliessen Hauptwaschgang Benutzer Wasserventil abpumpen Heizelement Steuerung par Pumpe schleudern Motor abpumpen Klassendiagramm fertig UML 2 Tutorial Net.ObjectDays 2003 Seite 135 :Motor :Pumpe Sequenzdiagramm Die wichtigsten Elemente im Überblick Lebenslinie Zustandsbedingung sd Bild aufhaengen :Person :Hammer :Nagel :Daumen :Bild [gerade] loop Abbruchbedingung [Nagel haelt] alt schlagen getroffen = schlagen treffen Kombiniertes Fragment treffen Interaktions -verweis ref Daumen verbinden aufhaengen Nachricht UML 2 Tutorial Net.ObjectDays 2003 Seite 136 Aktionssequenz Sequenzdiagramm Lebenslinien Repräsentieren die Teilnehmer einer Interaktion Repräsentieren sd Internetsuche - den Classifier selbst, :Internetbrowser - die Attribute des Classifiers, suche_starten(Keyword) - Teile des Classifiers, z. B. Ports - die Operationen des Classifiers, suche_starten - und Parameter von Operationen aktualisieren - (lokale) Variablen einer Operation. Bestellung Darstellung der Aktionssequenzen Stopp löscht die Lebenslinie lösche UML 2 Tutorial Net.ObjectDays 2003 Seite 137 :Suchmaschine Aktionssequenz Sequenzdiagramm Beispiele für Lebenslinien Person Motor Motor + berechneAlter(int Geburtsjahr,Datum):Alter p:Getriebe Gaspedal + Beschleunigen() sd sd berechneAlter(int Geburtsjahr,Datum):Alter Operationsname kennzeichnet Rückgabewert Geburtsjahr:int Datum self p:Getriebe berechneAlter:Alter beschleunigen Setzen des Rückgabewerts sd Anschrift setzen Person UML 2 Tutorial Nachname :String Vorname[0] :String Vorname[1] :String Adresse Net.ObjectDays 2003 Nachname :String Seite 138 Vorname[0] :String Vorname[1] :String Adresse Sequenzdiagramm Zustandsinvariante-/Zustandsbedingung „Lebenslinie“ muss Bedingung erfüllen Wird zur Laufzeit überprüft sd Pizzabestellung :Kunde :Pizzaservice geöffnet bestellen bestellen UML 2 Tutorial Net.ObjectDays 2003 Seite 139 Zustandsbedingung für Lebenslinie „Pizzaservice“ Sequenzdiagramm Nachrichten Beschreiben den Informationsfluss zwischen den Synchrone Nachricht Kommunikationspartnern A Synchrone Nachrichten (Sender wartet auf Antwort) Asynchrone Nachrichten Found Nachricht (Antwort wird nicht erwartet) Abgebildet durch Pfeil und Pfeilspitze Lost und Found Nachrichten: UML 2 Tutorial Net.ObjectDays 2003 Seite 140 B N1 C N3 N2 N4 Antwortnachricht Asynchrone Nachricht Lost Nachricht Sequenzdiagramm Kombinierte Fragmente Teil einer Interaktion Mit bestimmten Regeln für - Auswahl - Reihenfolge - Häufigkeit der Nachrichten Interaktionsoperator :A :B trennt Operanden alt m [x == 1] } n [else] Interaktionsbedingung UML 2 Tutorial Net.ObjectDays 2003 Seite 141 kombiniertes Interaktionsfragment Interaktionsoperand Sequenzdiagramm Kombinierte Fragmente Alternativ (alt): - Existenz von mehr als einer Ablaufmöglichkeit - Bedingungen geben den Ablauf vor - Immer 2 Operanden Modellierung von - If-else-Bedingungen - Switch/case Anweisungen UML 2 Tutorial Net.ObjectDays 2003 sd Nahrung aufnehmen :Partygast :Buffet alt pluendern [Partygast.Hungergefühl>normal] aufessen [Partygast.Hungergefühl== normal] [else] Seite 142 weiterfeiern :Snacks Sequenzdiagramm Kombinierte Fragmente sd Interaktion ignore {N3, N4} Ignore (ignore) - Blendet Nachrichten aus, die für die Modellierung irrelevant sind - Im realen System können diese jedoch vorkommen A N1 N2 N5 sd Consider (consider) - Nur die genannten Nachrichten sind relevant - Betont Intention des Modellierers UML 2 Tutorial Net.ObjectDays 2003 Seite 143 C B Interaktion consider {N3, N4} A C B N1 N3 N4 Sequenzdiagramm Kombinierte Fragmente sd Spiel ignore {ziehen} Option (opt): - Interaktion, die nur unter bestimmten Bedingungen durchgeführt wird - If(...) then { ... } :Spieler :Würfel opt [keine Figur im Feld] loop (1,3) [Augenzahl!=6] wuerfeln Loop (loop) - Abbildung von Schleifen - Zählschleife: loop(min, max) - Abbruch/Ausführung durch [Bedingungen] steuerbar UML 2 Tutorial Net.ObjectDays 2003 Seite 144 wuerfeln opt loop [Augenzahl==6] [Augenzahl==6] wuerfeln wuerfeln Sequenzdiagramm Kombinierte Fragmente sd trinken Negative (neg) - Hebt ungültige Folgen von Einzelschritten hervor - Zur Betonung gedacht - Modellierung von negativen (Test-)fällen :Partygast :Glas austrinken neg austrinken sd Party verlassen Assertion (assert) - Legt eine bestimmte Reihenfolge fest - Zur Betonung gedacht :Partygast :Gastgeber verabschieden assert weggehen UML 2 Tutorial Net.ObjectDays 2003 Seite 145 Sequenzdiagramm Kombinierte Fragmente sd Unfallaufnahme Parallel (par) - Mehrere Abläufe sollen gleichzeitig ablaufen - „Threading“ Patient :Patient par Aufnahme :Aufnahme OP :OP aufnehmen operieren aufnehmen verlegen Critical Region (critical) - Festlegen eines ununterbrechbaren, statischen Ablaufs UML 2 Tutorial Net.ObjectDays 2003 critical aufnehmen (Herzinfarkt) Seite 146 aufnehmen (Herzinfarkt) operieren Station :Station Sequenzdiagramm Kombinierte Fragmente - Coregion Alternativdarstellung zum parallel kombinierten Fragment Aber nur wenn nur eine Lebenslinie betroffen ist Ablaufreihenfolge innerhalb der Coregion ist beliebig sd Tankstopp :Person :Auto tanken(Benzin) Scheiben putzen Öl kontollieren bezahlen UML 2 Tutorial Net.ObjectDays 2003 Seite 147 :Kasse Sequenzdiagramm Kombinierte Fragmente Break (break) - Unterberechen des normalen Ablaufs sd Drogenfahndung Fahrer :Fahrer Polizist :Polizist Auto :Auto anhalten durchsuchen Ergebnis Zur Modellierung von - Exceptions - Systemfehlern - Kritischen asynchronen Ereignissen UML 2 Tutorial Net.ObjectDays 2003 break [Ergebnis == Drogen gefunden] verhaften weiterfahren Seite 148 Sequenzdiagramm Notationselemente - Interaktionsverweis ref C sd Referenziert (ref) auf eine beliebige Interaktion Wiederverwendung in mehreren Diagrammen möglich „Zooming“ – Gedanke Auch für Lebenslinien möglich X Z Y ref C ref A ref B sd A sd B X Y Z Y UML 2 Tutorial Net.ObjectDays 2003 Seite 149 Z Sequenzdiagramm Modellierung von Zeitangaben X Y a t=now Zeitpunkte beschreiben, wann ein Ereignis eintritt Einheit Uhr Zeiteinheit für t ist ms {12.00..12.05} b t=now c t..t+5 Zeitdauerbedingung XX Zeitdauer beschreibt, Die Dauer von Nachrichten oder Aktionssequenzen UML 2 Tutorial Net.ObjectDays 2003 Seite 150 a Zeiteinheit Sekunden YY {2..10} Hilfslinien b b c ÜZeit=duration d {0..0,5*ÜZeit} {5..5} Zeitdauerbeobachtungsaktion Sequenzdiagramm Die wichtigsten Änderungen UML 1.x UML 2 Zerlegung von Lebenslinie nicht möglich, Referenzen von anderen Interaktionen nicht möglich Innerhalb von Sequenzdiagrammen kann auf andere Interaktionen verwiesen werden (Zerlegung von Abläufen oder Lebenslinien) Kontrollflussmöglichkeiten äußerst bescheiden: Schleifen und Nachrichtenbedingungen möglich Alle Kontrollflussmöglichkeiten (if, switch, ...) höherer Programmiersprachen durch kombinierte Fragmente, sehr gute Unterstützung von nebenläufiger Modellierung Nachrichtenarten: asynchron, synchron, unspezifiziert unspezifiziert entfällt, Nachrichten eingeführt lost und found Zustandsinvarianten können an Lebenslinien angetragen werden UML 2 Tutorial Net.ObjectDays 2003 Seite 151 Kommunikationsdiagramm „Auch das Chaos gruppiert sich um einen festen Punkt, sonst wäre es nicht einmal als Chaos da.“ Arthur Schnitzler UML 2 Tutorial Net.ObjectDays 2003 Seite 152 Kommunikationsdiagramm Die Elemente im Überblick Notationselemente: - Interaktion - Lebenslinien Nachrichtenname - Nachrichten - Sequenzbezeichner Name der Interaktion Lebenslinie cd Gassi gehen 1:Gassi gehen Hundehalter Sequenzbezeichner Hund 3:entfernen 2.1:schimpfen 1.1:machen 2:reintreten Richtung der Nachricht UML 2 Tutorial Net.ObjectDays 2003 Seite 153 Passant Häufchen Kommunikationsdiagramm Anwendung im Projekt Gehört zu den Interaktionsdiagrammen Zeigt das Zusammenspiel von strukturierten Kommunikationspartnern. Kontrollflüsse und zeitliche Aspekte sind weniger wichtig Gut geeignet für die Modellierung von Prinzipien und Konzepten Wenig Änderungen zur UML 1.x Version, dem Kollaborationsdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 154 Kommunikationsdiagramm Nachricht - Sequenzbezeichner Definiert für Nachrichten - Reihenfolge - Ebene der Abarbeitung cd Restaurantbesuch Gast 1b:bestellen 1a:bestellen 2a: [Glas voll] trinken Reihenfolge wird durch Zahlen spezifiziert 4:bezahlen (Betrag) Getraenk Essen 1:hinzufuegen Ausführungsbedingung in eckigen Klammern 2b*[Teller voll]: essen 1:hinzufuegen Rechnung 3:berechnen(Betrag) UML 2 Tutorial Net.ObjectDays 2003 Seite 155 Kommunikationsdiagramm Nebenläufigkeit und Schleifen Nebenläufigkeit durch Buchstaben im Sequenzbezeichner cd Reparaturauftrag 1a.1:Auftrag 1a:beauftragen Auftragsannahme Besitzer Mechaniker 1a.1.1.1:erledigt 1b:ausleihen 1a.1.1a:reparieren Definition von Schleifen mit einem Stern „*“ 2:fahren Auto Mietwagen 1a.1.1b*||[alle Ersatzteile vorhanden]: Ersatzteil beschaffen Kennzeichnung von nebenläufigen Schleifendurchläufen mit Doppelstrich „||“ Lager 1a.1.1c:[Ersatzteil nicht vorhanden]: bestellen Ersatzteil UML 2 Tutorial Net.ObjectDays 2003 Seite 156 Kommunikationsdiagramm Die wichtigsten Änderungen UML 1.x UML 2 Kollaborationsdiagramm Kommunikationsdiagramm Vollständig äquivalent zum Sequenzdiagramm Subset des Sequenzdiagramms, z. B. - keine Interaktionsverweise („ref“) - keine kombinierten Fragmente - Ereignisreihenfolge wird ignoriert UML 2 Tutorial Net.ObjectDays 2003 Seite 157 Timing-Diagramm „Die Neugier steht immer an erster Stelle eines Problems, das gelöst werden will.“ Galileo Galilei UML 2 Tutorial Net.ObjectDays 2003 Seite 158 Timing-Diagramm Die Elemente im Überblick Name des Diagramms ZeitBedingung td Fußgängerampel {d...6*d} :Ampel grün rot gehen betriebsbereit nicht gehen aktivieren Lebenslinien :Fußgänger aktiv wartend d Sek. 0 10 20 30 Zustand Zeitskala UML 2 Tutorial Net.ObjectDays 2003 Seite 159 Zustandslinie Nachricht Timing-Diagramm Anwendung im Projekt Gehört zu den Interaktionsdiagrammen Darstellung des zeitlichen Veränderung eines Classifiers (Klasse, Objekt, Komponente, ...) Für die Modellierung zeitkritischer Zustands- und Wertänderungen sinnvoll Neu in der UML 2! Bereits seit Jahren in Elektrotechnik genutzt (z. B. für elektronische Schaltvorgänge) UML 2 Tutorial Net.ObjectDays 2003 Seite 160 Timing-Diagramm Elemente – Lebenslinie - Zustandslinie Nur eine Lebenslinie oder kommunizierende Lebenslinien möglich Zeitliche Verzögerung des Zustandsüberganges td Fahrstuhltür Zustand Zustandslinien beschreiben den Wechsel der Zustände im Ablauf der Zeit UML 2 Tutorial Net.ObjectDays 2003 :Fahrstuhltür beim öffnen beim schliessen Zustandslinie :Lichtschrankensystem Meist nur Sicht auf wenige Zustände der auf Lebenslinie offen unterbrochen nicht unterbrochen 0 Seite 161 2 sek Timing-Diagramm Elemente - Nachrichten Nachrichten werden zwischen den Zustandslinien ausgetauscht Bewirken häufig einen Zustandswechsel :Verkehrsfunk td Autoradio aktiv inaktiv :Musiksender Anfang UML 2 Tutorial leise laut Net.ObjectDays 2003 Seite 162 Ende Nachricht Timing-Diagramm General-Value-Lifeline Alternative Darstellungsform td Waschstraße {2a..6,5a} {5a} {4a} :Waschstraße betriebsbereit Vorreinigung Hauptwäsche Trocknen betriebsbereit :Kunde aktiv warten a UML 2 Tutorial Net.ObjectDays 2003 Seite 163 aktiv Timing-Diagramm Vorsicht: Fehler die vermieden werden sollten td Schweinebraten zubereiten :Schweinebraten zubereitet roh fehlende Zustandsbeschriftung aktiv warten fehlende Lebenslinienbeschriftung Lücke in der Zustandszeitlinie UML 2 Tutorial Net.ObjectDays 2003 Seite 164 Empfangsereignis vor Sendeereignis Interaktionsübersichtsdiagramm „Wer auf morgen wartet, wird übermorgen erkennen, dass er heute versäumt hat das Notwendigste zu tun.“ Walter Scheffel UML 2 Tutorial Net.ObjectDays 2003 Seite 165 Interaktionsübersichtsdiagramm iod Betriebsfeier ref Verpflegung_organisieren sd :Chef ref :Angestellter Mitarbeiter.Hemmschwelle=Feier:Alkoholkonsum organisiereFeier ref Mitarbeiter_verständigen [Keine Hemmschwelle] sd sd :Chef :Mitarbeiter bedanken UML 2 Tutorial Net.ObjectDays 2003 Seite 166 :Chef :Personalchef mitarbeiterfeuern Interaktionsübersicht Anwendung im Projekt Darstellung der Ablaufreihenfolge mehrerer Interaktionen Besonders geeignet für: - Brückenschlag zwischen Aktivitäts- und Interaktionsdiagrammen - Logischen Zusammenhang zwischen mehreren Interaktionsdiagrammen schaffen Ablauf wird durch Kontrollelemente aus dem Aktivitätsdiagramm dargestellt Neu in der UML 2! UML 2 Tutorial Net.ObjectDays 2003 Seite 167 Fazit --dynamische Diagramme in UML 2 Viel neu - viel geklaut Aktivitätsdiagramme und Sequenzdiagramme faktisch neu Verbesserte Unterstützung der Codeabbildung Bessere Modellierung von Nebenläufigkeiten und Zeitverhalten möglich Î dennoch keine „Echtzeitsprache“ Deutlich bessere Schnittstelle zu Strukturdiagrammen Notationsvielfalt erfordert Tailoring Interaktionsübersichtsdiagramm, Timingdiagramm erfordern Nachbesserungen UML 2 Tutorial Net.ObjectDays 2003 Seite 168 Damit Sie klar sehen! Infos: •www.uml-glasklar.de •www.jeckle.de •www.sophist.de UML 2 Tutorial Net.ObjectDays 2003 Seite 169 Modelle der Realität erstellen Wir erkennen die Struktur Ihrer Projektanforderungen! Infos unter www.SOPHIST.de UML 2 Tutorial Net.ObjectDays 2003 Seite 170 UML 2 Tutorial Net.ObjectDays 2003 Seite 171