UML 2 Tutorial: Einführung in die neue Standardmodellierungssprache

Transkript

1 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

2 Darum geht s Ideen Vorschläge UML 2 Roadmap Neue Diagramme Praktischer Einsatz Standardisierung Übersichtlichkeit Präzisionssteigerung Ausführbarkeit Abhängigkeiten Metamodell Verbesserte Diagramme UML 2 Tutorial Net.ObjectDays 2003 Seite 2

3 Was ist die UML? logische Sicht Use Case - Sicht Wunsch des Kunden Requirements: - Das System soll mit C++ realisiert werden - Bei Anfrage durch einen Kunden muss die Funktionalität sichergestellt sein Requirements & Use Case- Beschreibungen... Deployment - Sicht Implemen- tierungs- Sicht Prozess - Sicht 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

4 UML... Geschichten von den fremden Meeren der Standardisierung OML Firesmith, Henderson- Sellers, Page-Jones; 1998 Unified Method Booch, Rumbaugh; 1995 Unified Modeling Language v1.0 Booch, Jacobson, Rumbaugh; 1997 Catalysis D Souza, Willes; 1996 MOSES Henderson-Sellers; 1994 SOMA Graham; 1994 Fusion Coleman, et al.; 1994 OBA Rubin; 1992 BON Nerson; 1992 OOA Coad, Yourdan; 1991 OOA&D Martin, Odell; 1992 OOD Booch; 1992 OMT Rumbaugh, et al.; 1991 OOSE Jacobson; 1992 OSA Embley; 1991 OOAD&I Henderson-Sellers, Macrone; 1992 OOSA Shlear, Mellor; 1991 SCOOP Cherry; 1990 HOOD ESA; 1990 RDD Wirfs-Brock; 1990 Vom Methodenkrieg... OBA Bailin; 1989 State Charts Harel; 1987 UML 2 Tutorial Net.ObjectDays 2003 Seite 4

5 UML... Geschichten von den fremden Meeren der Standardisierung Erweiterung OMG Unified Modeling Language 2.0 UML 2 Partners; unveröffentlicht Viele arbeiten für alle Fragmentierung Vereinheitlichung Standardisierung Breiteneinsatz 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 XML Metadata Interchange Integration der Object Constraint Language Einsatzerfahrung der Sprachschöpfer OMT Rumbaugh, et al.; 1991 OMG Unified Modeling Language 1.5 UML Partners; 2003 ( OMG Unified Modeling Language 1.2 ) UML Partners; 1998 Unified Modeling Language 1.1 UML Partners; 9/1997 Unified Modeling Language 1.0 UML Partners 1/1997 Unified Modeling Language 0.9, 0.91 Booch, Rumbaugh, Jacobson; 1996 Unified Method 0.8 Booch, Rumbaugh 1995 OOD Booch; 1992 OOSE Jacobson; 1992 UML 2 Tutorial Net.ObjectDays 2003 Seite 5... Einige arbeiten für andere Wenige arbeiten für einige... zum Standardisierungskrieg

6 UML 2... Warum eine neue Version? Evolution - Der Markt hat sich bewegt... Erfahrung - Neue Programmiersprachen (z.b. C#, Python, PHP) - Neue Anwendungsdomänen (z.b. Serverprogrammierung, Echtzeitanwendungen) - Für einige Einsatzgebiete bietet UML v1.x... - Manchmal zu wenig Konstrukte - Manchmal zu viele - Machmal so viele, dass die sinnvolle Eliminierung Auswahl schwerfällt - 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

7 UML... Ein Leiden am Second System Syndrom UML 2 Tutorial Net.ObjectDays 2003 Seite 7

8 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

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 UML 2 Tutorial Net.ObjectDays 2003 Seite 9

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 SWE 1 System-Anforderungsanalyse und -Entwurf SWE 9 System-Integration System System- Ebene Systemanforderungen Systemarchitektur Systemintegrationsplan Handbuchinformationen DV-Anforderungen SWE 2 DV-Anforderungsanalyse und -Entwurf SWE 8 DV-Integration DV-Segment Segment- Ebene DV-Architektur DV-Integrationsplan SW-Anforderungen SWE 3 SW-Anforde rungsanalyse SWKE- Integration Implementierungsdok. (SWKE) Konfigurations- einheits- Ebene SWE 7 SWKE SWE 4 SW-Integration Implementierungsdok. (Komponente) SW-Architektur Schnittstellenentwurf SWKE-Integrationsplan Grobentwurf Kompo- nenten- Integration Komponenten- Ebene Komponente Datenkatalog SW-Entwurf SWE 5 Feinentwurf Implementierungsdok. (Modul) Modul-/Datenbank- Ebene Implementierungsdok. (Datenbank) SWE 6 Modul Datenbank Implementierung Legende: Prüfaktivitäten (siehe QS) Abb. 2.7 Funktionsüberblick Submodell SWE UML 2 Tutorial Net.ObjectDays 2003 Seite 10

11 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 «friend» KlasseB noch : String viel : short wichtiger : float UML 2 Tutorial Net.ObjectDays 2003 Seite 11

12 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 «copy» «become» Objekt2 : KlasseA irgend = 1 ein = true wichtiges = 3.1 Element = 42 UML 2 Tutorial Net.ObjectDays 2003 Seite 12

13 UML 2 Neu: UML Schichten Ebene 3 Ebene 2 Ebene 1 Ebene 0 Complete Intermediate Basic 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

14 Use-Case Akivitätsdiagramm Sequenzdiagramm x (noch nicht eingeteilt) Gewichtete Kanten, Streaming x (noch nicht eingeteilt)... complete x (noch nicht eingeteilt) Parallelität x (noch nicht eingeteilt)... intermediate x Anwendungsfall x Einfacher Ablaufplan x Ablaufdiagramm... basic x Grundlagen Use- Cases x Grundlagen Aktivitäten x Grundlagen Sequenzen... foundation UML 2 Tutorial Net.ObjectDays 2003 Seite 14

15 Struktur und Einbettung von UML 2 Unified Modeling Language 2.0 MOF2 OCL Infrastructure Diagram Interchange überträgt Statische Anteile Dynamische Anteile nutzt Superstructure 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

16 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

17 Der Weg zu UML 2 Microsoft Hewlett-Packard Oracle Sterling Software MCI Systemhouse Unisys ICON Computing Rational Software IntelliCorp i-logix IBM ObjecTime Platinum Technology Ptech Taskon Reich Technologies SOFTEAM Alcatel Kabira Kennedy Carter Computer Associates Ericsson IONA Motorola Telelogic Boldsoft Adaptive Financial System Architects SUN Gentleware DaimlerChrylser 1.1/ OMG EDS Sterling Software ICON Computing ObjecTime Platinum Technology MCI Systemhouse Microsoft Hewlett-Packard ICON Computing IntelliCorp Ptech Taskon Reich Technologies UML 2 Tutorial Net.ObjectDays 2003 Seite 17

18 Vorschläge zur UML 2 Einige komplexe Dinge sollten einfacher werden... UML 2 Tutorial Net.ObjectDays 2003 Seite 18

19 Vorschläge zur UML 2 Manchmal sagen Bilder einfach zu wenig... UML 2 Tutorial Net.ObjectDays 2003 Seite 19

20 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

21 UML 2.0 Ablaufplan Ziel: Ein UML 2.0 Standard Infrastructure RFP Erste Einreichung Überarbeitete Einreichung Annahme Superstructure RFP Erste Einreichung Überarbeitete Einreichung Annahme Sep 00 Apr 01 Jun 01 Aug 01 Okt 01 Dez 01 Feb 02 Jan 03 Apr 03 Sep 03 UML 2 Tutorial Net.ObjectDays 2003 Seite 21

22 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? OMG Mitgliedsabstimmung Jun 04? UML 2.0 Finalization Task Force (FTF) Okt 04? Bestätigung durch das OMG Board of Directors offizieller Standard (bis Oktober 2004 änderbar) UML 2 Tutorial Net.ObjectDays 2003 Seite 22

23 Diagramme der UML 2 Diagramme der UML 2 Strukturdiagramme Verhaltensdiagramme Klassendiagramm Komponentendiagramm Objektdiagramm Aktivitätsdiagramm Use-Case- Diagramm Zustandsautomat Kompositionsstrukturdiagramm Interaktionsdiagramme Verteilungsdiagramm Paketdiagramm Zeitverlaufsdiagramm Sequenzdiagramm Kommunikationsdiagramm Interaktionsübersichtsdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 23

24 Wie hätten Sie s denn gern? Rational Unified Process Arte Agiles Vorgehen Crystal OEP Lean Software Development XP EOS ASD Spiralmodell V-Modell Unified Process SCRUM UML 2 Tutorial Net.ObjectDays 2003 Seite 24

25 Entscheidungshilfe (1): Gibt es Vorschriften? Es gibt Vorschriften 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? Es haben freie Wahl 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

26 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? 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. UML 2 Tutorial Net.ObjectDays 2003 Seite 26

27 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

28 Diagramme der UML und ihre Anwendung I Diagrammtyp Klassendiagramm Paketdiagramm Objektdiagramm Diese zentrale Frage beantwortet das Diagramm Aus welchen Klassen besteht mein System und wie stehen diese untereinander in Beziehung? Wie kann ich mein Modell so schneiden, dass ich den Überblick bewahre? Welche innere Struktur besitzt mein System zu einem bestimmten Zeitpunkt zur Laufzeit (Klassendiagrammschnappschuss)? Stärken Beschreibt die statische Struktur des Systems. Enthält alle relevanten Strukturzusammenhänge/Datentypen. Brücke zu dynamischen Diagrammen. Normalerweise unverzichtbar. Logische Zusammenfassung von Modellelementen. Modellierung von Abhängigkeiten/ Inklusion möglich. 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

29 Diagramme der UML und ihre Anwendung II Diagrammtyp Kompositionsstrukturdiagramm Komponentendiagramm Verteilungsdiagramm Diese zentrale Frage beantwortet das Diagramm Wie sieht das Innenleben einer Klasse, einer Komponente, eines Systemteils aus? Wie werden meine Klassen zu wieder verwendbaren, verwaltbaren Komponenten zusammengefasst und wie stehen diese in Beziehung? Wie sieht das Einsatzumfeld (Hardware, Server, Datenbanken, ) des Systems aus? Wie werden die Komponenten zur Laufzeit wohin verteilt? Stärken Ideal für die Top-Down-Modellierung des Systems (Ganz-Teil-Hierarchien). Zeigt Teile eines Gesamtelements und deren Mengenverhältnisse. Präzise Modellierung der Teile- Beziehungen über spezielle Schnittstellen (Ports) möglich. Zeigt Organisation und Abhängigkeiten einzelner technischer Systemkomponenten. Modellierung angebotener und benötigter Schnittstellen möglich. 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

30 Diagramme der UML und ihre Anwendung III Diagrammtyp Use-Case-Diagramm Aktivitätsdiagramm Zustandsautomat Diese zentrale Frage beantwortet das Diagramm Was leistet mein System für seine Umwelt (Nachbarsysteme, Stakeholder)? Wie läuft ein bestimmter flussorientierter Prozess oder ein Algorithmus ab? Welche Zustände kann ein Objekt, eine Schnittstelle, ein Use Case, bei welchen Ereignissen annehmen? Wer tauscht mit wem welche Informationen in welcher Reihenfolge aus? Stärken Außensicht auf das System. Geeignet zur Kontextabgrenzung. Hohes Abstraktionsniveau, einfache Notationsmittel. Sehr detaillierte Visualisierung von Abläufen mit Bedingungen, Schleifen, Verzweigungen. Parallelisierung und Synchronisation. Darstellung von Datenflüssen. Präzise Abbildung eines Zustandsmodells mit Zuständen, Ereignissen, Nebenläufigkeiten, Bedingungen, Ein- und Austrittsaktionen. Schachtelung möglich. Darstellung d. Informationsaustauschs zwischen Kommunikationspartnern Sehr präzise Darstellung der zeitlichen Abfolge auch mit Nebenläufigkeiten. UML 2 Tutorial Net.ObjectDays 2003 Seite 30

31 Diagramme der UML und ihre Anwendung IV Diagrammtyp Timingdiagramm Kommunikationsdiagramm Interaktionsübersichtsdiagramm Diese zentrale Frage beantwortet das Diagramm Wer kommuniziert mit wem? Wer arbeitet im System zusammen? Wann befinden sich verschiedene Interaktionspartner in welchem Zustand? Wann läuft welche Interaktion ab? Stärken Stellt den Informationsaustausch zwischen Kommunikationspartnern dar. Überblick steht im Vordergrund (Details und zeitliche Abfolge weniger wichtig). 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. Verbindet Interaktionsdiagramme (Sequenz-, Kommunikation- und Timingdiagramme) auf Top-Level- Ebene. Hohes Abstraktionsniveau. UML 2 Tutorial Net.ObjectDays 2003 Seite 31

32 UML 2 Die Strukturdiagramme Barbara Zengler Mario Jeckle UML 2 Tutorial Net.ObjectDays 2003 Seite 32

33 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

34 Diagramme der UML 2 Diagramme der UML 2 Strukturdiagramme Verhaltensdiagramme Klassendiagramm Komponentendiagramm Objektdiagramm Aktivitätsdiagramm Use-Case- Diagramm Zustandsautomat Kompositionsstrukturdiagramm Interaktionsdiagramme Verteilungsdiagramm Paketdiagramm Zeitverlaufsdiagramm Sequenzdiagramm Kommunikationsdiagramm Interaktionsübersichtsdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 34

35 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 UML 2 Tutorial Net.ObjectDays 2003 Seite 35 Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektdiagramm Paketdiagramm

36 Warum neue oder geänderte 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 Klassendiagramm Wiederverwendung von bestehenden Konstrukten Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektdiagramm Paketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 36

37 Ä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 Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Inhärente Bedeutung für den Modellaustausch zwischen Werkzeugen (XMI-Format wird aus Metamodell generiert) Verteilungsdiagramm Komponentendiagramm Objektdiagramm Paketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 37

38 Statische Diagramme der UML 2 Diagramme der UML 2 wichtigster Diagrammtyp Strukturdiagramme Verhaltensdiagramme Klassendiagramm Komponentendiagramm Objektdiagramm Aktivitätsdiagramm Use-Case- Diagramm Zustandsautomat meist-geänderter Diagrammtyp Kompositionsstrukturdiagramm Interaktionsdiagramme Verteilungsdiagramm Paketdiagramm Zeitverlaufsdiagramm Sequenzdiagramm Klassendiagramm Kommunikationsdiagramm Interaktionsübersichtsdiagramm 15% 5% Komponentendiagramm 45% Objektdiagramm 19% Kompositionsstrukturdiagramm 7% 9% Verteilungsdiagramm Paketdiagramm neuer Diagrammtyp UML 2 Tutorial Net.ObjectDays 2003 Seite 38

39 Basiskonzepte Die UML-Basiskonzepte sind Abstraktion Typisierung und Identität Strukturierung (d.h. gekapselte Eigenschaften und vielfältige Beziehungen) Erweiterbarkeit der Sprache Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektdiagramm Paketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 39

40 Basiskonzepte Die UML-Basiskonzepte sind Abstraktion Typisierung und Identität Strukturierung (d.h. gekapselte Eigenschaften und vielfältige Beziehungen) Erweiterbarkeit der Sprache Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektdiagramm Paketdiagramm 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

41 Basiskonzepte -- Abstraktion UML 2... Erweitert die Nutzung der Classifier Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Vereinheitlicht ähnliche Konzepte unter gemeinsamen Oberbegriffen Bietet neue Diagrammtypen und -sichten Classifier Verteilungsdiagramm Komponentendiagramm Objektdiagramm Paketdiagramm DataType Signal Association Class (from Kernel) Actor InformationItem BehavioredClassifier StructuredClassifier PrimitiveType Enumeration CommunicationPath AssociationClass Behavior Artifact Interface Class (from Communications) UseCase Collaboration EncapsulatedClassifier Activity Interaction StateMachine Class (from StructuredClasses) ProtocolStateMachine Node Device ExecutionEnvironment UML 2 Tutorial Net.ObjectDays 2003 Seite 41

42 Basiskonzepte -- Abstraktion UML 2... Erweitert die Nutzung der Classifier Classifier Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektdiagramm Paketdiagramm 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) DataType Signal Association Class (from Kernel) Actor InformationItem BehavioredClassifier StructuredClassifier PrimitiveType Enumeration CommunicationPath AssociationClass Behavior Artifact Interface Class (from Communications) UseCase Collaboration EncapsulatedClassifier Activity Interaction StateMachine Class (from StructuredClasses) ProtocolStateMachine Node Device ExecutionEnvironment UML 2 Tutorial Net.ObjectDays 2003 Seite 42

43 Basiskonzepte -- Abstraktion UML 2... Erweitert die Nutzung der Classifier Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Vereinheitlicht ähnliche Konzepte unter gemeinsamen Oberbegriffen Bietet neue Diagrammtypen und -sichten Verteilungsdiagramm Komponentendiagramm Objektdiagramm Paketdiagramm Beispiel: Artefakt kann beliebige paktierbare Elemente manifestieren mywebapp.xml.html.class.jsp UML 2 Tutorial Net.ObjectDays 2003 Seite 43 «artifact» «manifest» myapp.war Anwendung: Deployment von Webapplikationen

44 Basiskonzepte -- Abstraktion UML 2... Erweitert die Nutzung der Classifier Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Vereinheitlicht ähnliche Konzepte unter gemeinsamen Oberbegriffen Bietet neue Diagrammtypen und -sichten Verteilungsdiagramm Komponentendiagramm Objektdiagramm Paketdiagramm 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

45 Basiskonzepte Die UML-Basiskonzepte sind Abstraktion Typisierung und Identität Strukturierung (d.h. gekapselte Eigenschaften und vielfältige Beziehungen) Erweiterbarkeit der Sprache Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektdiagramm 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

46 Basiskonzepte Typisierung und Identität UML 2... Verhältnis zwischen Classifier und typisierten Elementen klarer gefasst Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektdiagramm Unterschied zwischen typisiert sein und Typ sein verwirklicht Identitätsverhalten geklärt (Insbesondere bei dynamischer Verarbeitung statischer Daten) UML 1.x Element Element UML 2 Paketdiagramm ModelElement name NamedElement name Namespace GeneralizableElement TypedElement Type Classifier Classifier UML 2 Tutorial Net.ObjectDays 2003 Seite 46

47 Basiskonzepte Typisierung und Identität UML 2... Verhältnis zwischen Classifier und typisierten Elementen klarer gefasst Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektdiagramm Unterschied zwischen typisiert sein und Typ sein verwirklicht Identitätsverhalten geklärt (Insbesondere bei dynamischer Verarbeitung statischer Daten) 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

48 Basiskonzepte Die UML-Basiskonzepte sind Abstraktion Typisierung und Identität Strukturierung (d.h. gekapselte Eigenschaften und vielfältige Beziehungen) Erweiterbarkeit der Sprache Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektdiagramm 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

49 Basiskonzepte -- Strukturierung UML 2... Assoziationen zur Formulierung von Beziehungen zwischen Classifier-Ausprägungen (viele (unnötige) Einschränkungen) entfallen (z.b. Anwendung auf Use-Cases)) Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektdiagramm 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 Paketdiagramm Konstrukteur Konstruktion Kundenbetreuer UML 2 Tutorial Net.ObjectDays 2003 Seite 49 Änderungswunsch entgegennehmen

50 Basiskonzepte -- Strukturierung UML 2... Assoziationen zur Formulierung von Beziehungen zwischen Classifier-Ausprägungen (viele (unnötige) Einschränkungen) entfallen (z.b. Anwendung auf Use-Cases)) Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektdiagramm 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 Paketdiagramm Konstrukteur Kundenbetreuer Konstruktion Kundenbetreuer UML 2 Tutorial Net.ObjectDays 2003 Seite 50 Änderungswunsch entgegennehmen

51 Basiskonzepte -- Strukturierung UML 2... Assoziationen zur Formulierung von Beziehungen zwischen Classifier-Ausprägungen (viele (unnötige) Einschränkungen) entfallen (z.b. Anwendung auf Use-Cases)) Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektdiagramm 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 1 general Classifier specific Generalization issubstitutable Alle Classifier-Spezialisierungen sind nun spezialisierbar Substituierbarkeit expliziert * Paketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 51

52 Der Classifier-Zoo Classifier DataType Signal Association Class (from Kernel) Actor InformationItem BehavioredClassifier StructuredClassifier PrimitiveType Enumeration CommunicationPath AssociationClass Behavior Artifact Interface Class (from Communications) UseCase Collaboration EncapsulatedClassifier Activity Interaction StateMachine Class (from StructuredClasses) ProtocolStateMachine Node Device ExecutionEnvironment Alle Classifier-Spezialisierungen sind nun spezialisierbar UML 2 Tutorial Net.ObjectDays 2003 Seite 52

53 Basiskonzepte -- Strukturierung UML 2... Assoziationen zur Formulierung von Beziehungen zwischen Classifier-Ausprägungen (viele (unnötige) Einschränkungen) entfallen (z.b. Anwendung auf Use-Cases)) Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Objektdiagramm 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 «metaclass» Klasse «stereotype» xml «stereotype» persistent Paketdiagramm «persistent, xml» Partyteilnehmer Neue Notation (genaugenommen gibt es erstmals eine) Programmiersprachenspezifische Abhängigkeiten entfallen z.b. C++-spezifisches friend UML 2 Tutorial Net.ObjectDays 2003 Seite 54 «persistent» Gastgeber

54 Klassendiagramm --- Das wichtigste Diagramm Komponentendiagramm Strukturdiagramme Klassendiagramm Kompositionsstrukturdiagramm Klassendiagramm Verteilungs- Paketdiagramm Objektdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 55

55 Klassendiagramm Komponentendiagramm Klassendiagramm Objektdiagramm Funktion: Zusammenstellung deklarativ-statischer Modellelemente (d.h. Klassen, Typen, ihre Inhalte und Beziehungen) Strukturdiagramme Kompositionsstrukturdiagramm Klassendiagramm Verteilungs- Paketdiagramm 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

56 Klassendiagramm Aggregation Klasse Komposition Klassenname Strukturdiagramme abstrakte Klasse Feier Zutat Klassendiagramm Komponentendiagramm Objektdiagramm Rolle unterhält +termin : Datum abbrechen() +name : String Kompositionsstrukturdiagramm Klassendiagramm Verteilungs- Paketdiagramm besucht * Partyteilnehmer /betrunken : Boolean = false ~intus : Cocktail [1..*] #begeistert : Begeisterung #überdenkebegeisterung() ~trinke(in c : Cocktail) Generalisierung isst {ordered} 0..* «interface» Esser Häppchen iss(in h : Häppchen; return satt:boolean) Schnittstelle Cocktail Zutaten : Zutat [1..*] Barmixer 1..* mixt +mixe(in z : Zutat [1..*], out c:cocktail) Esser Eigenschaftswert Esser 1 mixt für feiere() Gast 1..* 1..* verabschiedet {unique} empfängt {unique} Attribut Operation Gastgeber hektisch : Boolean = true begruesse(in g : Gast) verabschiede (in g : Gast) treibean(in b : Barmixer) treibt an 1..1 Multiplizität «enumeration» Begeisterung ekstatisch verzückt neutral gelangweilt überdrüssig Stereotyp gerichtete Assoziation Assoziation UML 2 Tutorial Net.ObjectDays 2003 Seite 57

57 Klassendiagramm abstrakte Klasse Aggregation Klasse Klasse Feier Komposition Zutat Klassenname Klassendiagramm Komponentendiagramm Strukturdiagramme Objektdiagramm Rolle unterhält +termin : Datum abbrechen() +name : String Kompositionsstrukturdiagramm Klassendiagramm Verteilungs- Paketdiagramm Sichtbarkeit name (Richtung Name : Typ [Multiplizität]=Vorgabe {Eigenschaft=Wert}) : Rückgabetyp {Eigenschaft=Wert} Cocktail besucht * Häppchen 0..* Zutaten : Zutat [1..*] Partyteilnehmer isst {ordered} /betrunken : Boolean = false ~intus : Cocktail [1..*] #begeistert : Begeisterung #überdenkebegeisterung() ~trinke(in c : Cocktail) Generalisierung «interface» Esser iss(in h : Häppchen; return satt:boolean) Schnittstelle Barmixer 1..* mixt +mixe(in z : Zutat [1..*], out c:cocktail) [1..3] feiere() Esser Gast Eigenschaftswert 1..* 1..* verabschiedet {unique} empfängt {unique} Attribut Operation Gastgeber Esser hektisch : Boolean = true begruesse(in g : Gast) verabschiede (in g : Gast) treibean(in b : Barmixer) treibt an 1..1 Multiplizität 1 mixt für «enumeration» Begeisterung ekstatisch verzückt neutral gelangweilt überdrüssig Stereotyp Klasse Sichtbarkeit / name : Typ [Multiplizität] = Vorgabewert {Eigenschaft=Wert} gerichtete Assoziation Assoziation UML 2 Tutorial Net.ObjectDays 2003 Seite 58

58 Klassendiagramm Komponentendiagramm Strukturdiagramme Neu in UML 2: Klasse1 «Abhängigkeitsname» Klasse2 Klassendiagramm Kompositionsstrukturdiagramm Klassendiagramm Verteilungs- Paketdiagramm Objektdiagramm Klasse3 Klasse5 Klasse4 Klasse6 Kommentar zur Abhängigkeitsbeziehung UML 2 Tutorial Net.ObjectDays 2003 Seite 59

59 Klassendiagramm Komponentendiagramm Strukturdiagramme Neu in UML 2: - 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) UML 2 Tutorial Net.ObjectDays 2003 Seite 60 Klassendiagramm Kompositionsstrukturdiagramm Klassendiagramm Verteilungs- Paketdiagramm Objektdiagramm

60 Kompositionsstrukturdiagramm --- Ein neues Diagramm in UML 2 Kompositionsstrukturdiagramm Klassendiagramm Objektdiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Paketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 61

61 Kompositionsstrukturdiagramm Funktion: Zeigt die interne Struktur eines Classifiers sowie seine Möglichkeiten zu Interaktion mit anderen Systemkomponenten Kompositionsstrukturdiagramm Klassendiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Objektdiagramm Paketdiagramm Aufgabe im Projekt: Beschreibung von extern angebotenen Schnittstellen Abstraktion der Operationen und des Signals UML 2 Tutorial Net.ObjectDays 2003 Seite 62

62 Kompositionsstrukturdiagramm Basiskonzepte: Part Port Kollaboration Konnektor Rollenverwendung Kompositionsstrukturdiagramm Klassendiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Objektdiagramm Paketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 63

63 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 Kompositionsstrukturdiagramm Klassendiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Objektdiagramm Paketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 64

64 Kompositionsstrukturdiagramm Neu in UML 2: Port: Definiert einen öffentlich sichtund zugreifbaren Interaktionspunkt, der Kompositionsstrukturdiagramm Klassendiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm auf einen Operationsaufruf oder den Empfang eines Signals reagiert. Objektdiagramm Paketdiagramm bereitgestellteschnittstelle partybeschallung Klasse Stereoanlage benötigteschnittstelle strom, medium UML 2 Tutorial Net.ObjectDays 2003 Seite 65

65 Kompositionsstrukturdiagramm Neu in UML 2: Port: Werden durch andere Classifier oder Ports angesprochen. Kompositionsstrukturdiagramm Klassendiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Objektdiagramm Paketdiagramm Musikerzeugung Stereoanlage kabel : Steckdose Konnektor Musikerzeugung Konnektor Stereoanlage transformator : Hamsterrad UML 2 Tutorial Net.ObjectDays 2003 Seite 66

66 Kompositionsstrukturdiagramm Neu in UML 2: Behavior Port: Wie Port, allerdings mit der Einschränkung, dass der Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm definierende Classifier das Verhalten selbst manifestieren muss, andernfalls ist die empfangende Botschaft oder das empfangene Signal verloren. Kann Sichtbarkeits- und Zugriffsbeschränkt sein. partybeschallung Paketdiagramm Stereoanlage strom, medium UML 2 Tutorial Net.ObjectDays 2003 Seite 67

67 Kompositionsstrukturdiagramm Überarbeitet in UML 2: Kollaboration: Visualisiert das Zusammenspiel von Operationen oder Classifiern Kompositionsstrukturdiagramm Klassendiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Objektdiagramm Paketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 68

68 Kompositionsstrukturdiagramm Überarbeitet in UML 2: Kollaboration: Visualisiert das Zusammenspiel von Operationen oder Classifiern Kompositionsstrukturdiagramm Klassendiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Objektdiagramm Paketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 69

69 Kompositionsstrukturdiagramm Überarbeitet in UML 2: Beispiel: Kompositionsstrukturdiagramm Klassendiagramm Objektdiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Paketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 70

70 Kompositionsstrukturdiagramm Überarbeitet in UML 2: Beispiel: Kompositionsstrukturdiagramm Klassendiagramm Objektdiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Paketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 71

71 Kompositionsstrukturdiagramm Neu in UML 2: - Der gesamte Diagrammtyp - Ports als gemeinsame Abstraktion von Operationen und Signalen Klassendiagramm Strukturdiagramme Kompositionsstrukturdiagramm - Auffassung von Kollaborationen als Teile von Kompositionsstrukturen Verteilungsdiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Paketdiagramm Geändert in UML 2: - Schnittstellennotation - Möglichkeiten zur Darstellung von Kollaborationen UML 2 Tutorial Net.ObjectDays 2003 Seite 72

72 Verteilungsdiagramm --- Das Diagramm mit den meisten Änderungen Verteilungsdiagramm Klassendiagramm Objektdiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Paketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 73

73 Verteilungsdiagramm Funktion: Zeigt die Ausführungssicht des Systems Klassendiagramm Verteilungsdiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Objektdiagramm 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

74 Verteilungsdiagramm Basiskonzepte: Klassendiagramm 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 Verteilungsdiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Objektdiagramm Paketdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 75

75 Verteilungsdiagramm Knoten Verteilungsdiagramm «device» : Application Server Artefakt Klassendiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Verteilungsdiagramm Objektdiagramm Paketdiagramm «execution environment» J2EE : J2EE Server Server entry.jsp config.xml MyBean.class 1..* 1..* Assoziation «deploy» Deployment-Beziehung «artifact» application.jar «deployment spec» appdesc.xml «device» : DB Server execution : thread transaction : false Deployment-Spezifikation UML 2 Tutorial Net.ObjectDays 2003 Seite 76

76 Verteilungsdiagramm Neu in UML 2: - Aktuelle Ausführungs- und Laufzeitumgebungen wie J2EE und.net werden besser berücksichtigt Klassendiagramm Verteilungsdiagramm Verteilungsdiagramm Komponentendiagramm Strukturdiagramme Kompositionsstrukturdiagramm Objektdiagramm Paketdiagramm 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

77 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

78 UML 2 Die Verhaltensdiagramme Chris Rupp Jürgen Hahn UML 2 Tutorial Net.ObjectDays 2003 Seite 79

79 Diagramme der UML 2 Diagramme der UML 2 Strukturdiagramme Verhaltensdiagramme Klassendiagramm Komponentendiagramm Objektdiagramm Aktivitätsdiagramm Use-Case- Diagramm Zustandsautomat Kompositionsstrukturdiagramm Interaktionsdiagramme Verteilungsdiagramm Paketdiagramm Zeitverlaufsdiagramm Sequenzdiagramm Kommunikationsdiagramm Interaktionsübersichtsdiagramm UML 2 Tutorial Net.ObjectDays 2003 Seite 80

80 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

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

82 Use-Case-Diagramm Die Elemente im Überblick System Anwendungsfall Benutzer Use-Case Subject Akteur «include» «extend» Beziehung «include»-beziehung «extend»-beziehung Generalisierungsbeziehung UML 2 Tutorial Net.ObjectDays 2003 Seite 83

83 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

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 Use- Cases - «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

85 Use-Case-Diagramm Die Anwendung Use-Case Systemname Systemgrenze Akteur Verkauf Verkaufsposten eingeben Kunde nicht gefunden «extend» Extend- Beziehung Verkäufer extension points: fehlender Kunde Assoziation Kreditwürdigkeit prüfen «include» Kundendaten einsehen Include- Beziehung UML 2 Tutorial Net.ObjectDays 2003 Seite 86

86 Use-Case-Diagramm Die Anwendung Bürger Finanzamt Steuern hinterziehen - Einkommen - Vermögen + Belege fälschen() + Privat-/Geschäftskosten vermischen() Steuern zahlen Lohnsteuerkarte beantragen - Familienstand - Steuerklasse + Formular ausfüllen() + Karte ausdrucken() Auskunft über Finanzen geben - Einkommen - Vermögen + Belege zeigen() + Einkommensbeleg vorlegen() UML 2 Tutorial Net.ObjectDays 2003 Seite 87

87 Use-Case-Diagramm Kontextabgrenzung Abgrenzung von Systemen zu ihren Nachbarsystemen Bestellung Rechnung Fast Food Restaurant Geld Nahrung Bestellung Kunde Geld Rechnung Zulieferer Waren Richtlinien Geld Amt Bestätigung Zinsen Bank UML 2 Tutorial Net.ObjectDays 2003 Seite 88

88 Use-Case-Diagramm Die wichtigsten Änderungen UML 1.x UML 2 Ein Akteur darf unbenannt sein Nur Pakete können Use-Cases besitzen. Ein Akteur muss einen Namen haben 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. Bei der «extend»-beziehung werden die Vorbedingungen nur in der Nähe der entsprechenden Relation angetragen: Es wird deutlich herausgestellt, dass alle Classifier Use-Cases realisieren können. Die Vorbedingung und die entsprechenden extension points werden als Notiz an die Erweiterungsbeziehung angehängt: Benutzer ruft Hilfefunktion auf «extend» «Vorbedingung» {Benutzer ruft Hilfefunktion auf} extension point: Hilfethema «extend» UML 2 Tutorial Net.ObjectDays 2003 Seite 89

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 Kundendaten einsehen Kreditwürdigkeit prüfen «extend» Bürgen finden Bezeichnung des Akteurs fehlt Kunde nicht gefunden Angabe des Erweiterungspunktes fehlt Zwischen Use-Cases des selben Systems dürfen keine Assoziationen vorhanden sein UML 2 Tutorial Net.ObjectDays 2003 Seite 90

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

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

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 ODER Aktion 3 UND Aktion 3 UML 1.x UML 2 UML 2 Tutorial Net.ObjectDays 2003 Seite 93

93 Aktivitätsdiagramme Die wichtigsten Elemente im Überblick Aktivität Aktionsname Objekttyp Aktion Objektknoten Eingangsparameter Strukturierte Knoten Ausgangsparameter Kontrollelemente Name Startknoten Verzweigungsknoten Parallelisierungsknoten Kante Endknoten Verbindungsknoten Synchronisationsknoten UML 2 Tutorial Net.ObjectDays 2003 Seite 94

94 Aktivitätsdiagramm Aktivität - Aktion Aktivität beschreibt das komplette Diagramm Kann Ein- und Ausgangsparameter haben Aktivität Aktion Cocktail mixen Zutaten Zutaten mischen in Gläser füllen Cocktail Eis zerkleinern Eingangsparameter Ausgangsparameter Aktionen sind Verhaltensaufrufe Summe der Aktionen realisiert die Aktivität UML 2 Tutorial Net.ObjectDays 2003 Seite 95

95 Aktivitätsdiagramm Objektknoten Objektknoten repräsentieren nicht das Objekt selber, sondern Cocktail mixen Cocktail den Typ des Objekts Darstellung als Objektknoten oder durch Pin-Notation Cocktail mixen Cocktail Cocktail Cocktail trinken «centralbuffer» Objektknoten als Datenspeicher «datastore» Name [Zustand] UML 2 Tutorial Net.ObjectDays 2003 Seite 96

96 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 Kante Bedingung Einladung Einladung bekommen Datum prüfen [keine Zeit] möglicher Ablauf [Zeit vorhanden] Lust auf Feier prüfen Kontrollknoten [keine Lust] [Lust vorhanden] Feier absagen Zur Feier zusagen UML 2 Tutorial Net.ObjectDays 2003 Seite 97

97 Aktivitätsdiagramm Kontrollelemente II Startknoten: - Starten den Ablauf - Mehrere Startknoten initiieren parallele Abläufe Startknoten Endknoten: - Beenden die Aktivität oder - einen einzigen Ablauf Kanten: - Übergänge zwischen zwei Knoten - Beschreiben die Ablaufrichtung Endknoten Kante UML 2 Tutorial Net.ObjectDays 2003 Seite 98

98 Aktivitätsdiagramm Kontrollelemente III Verzweigungsknoten: - Ermöglichen alternative Abläufe - Bedingungen geben Ablaufrichtung vor Verbindungsknoten: - Vereinigen mehrere Abläufe Parallelisierungsknoten: - Aufteilen in parallele Abläufe Verzweigungsknoten Verbindungsknoten Parallelisierungsknoten Synchronisationsknoten: - Zusammenführen paralleler Abläufe Synchronisationsknoten UML 2 Tutorial Net.ObjectDays 2003 Seite 99

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 Unterbrechungskante Exception-Handler: - Ermöglicht die Beschreibung von Ausnahmen - Exception-Handler substituiert eine Aktion Aktion Exception- Typ Exception- Handler UML 2 Tutorial Net.ObjectDays 2003 Seite 100

100 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

101 Strukturierte Knoten Entscheidungsknoten Visualisierung komplexer Entscheidungen if: prüfen der Bedingung then: auszuführende Elemente else: möglicher Ablauf, wenn kein if-bereich zutrifft else if: wie if-bereich nur mit vorgegebener Prüfreihenfolge Restaurant if Speise then else Speise bewerten Gute Kritik erstellen Schlechte Kritik erstellen schmackhaft? Bewertung UML 2 Tutorial Net.ObjectDays 2003 Seite 102