1 / 43

UML-Historie (1/2)

UML-Historie (1/2). Vereinheitlichung und Erweiterung bestehender OO-Modellierungstechniken: Grady Booch (OOD, “Wolkenklassen”) James Rumbaugh (OMT) Ivar Jacobsen (Use-Cases) Januar 1997: Version 1.0 (von OMG als Standard gewählt); heute: Version 1.3 in Vorbereitung

nizana
Download Presentation

UML-Historie (1/2)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UML-Historie (1/2) • Vereinheitlichung und Erweiterung bestehender OO-Modellierungstechniken: • Grady Booch (OOD, “Wolkenklassen”) • James Rumbaugh (OMT) • Ivar Jacobsen (Use-Cases) • Januar 1997: Version 1.0 (von OMG als Standard gewählt); heute: Version 1.3 in Vorbereitung • Exakte Spezifikation unter: http://www.rational.com Frank Simon, BTU Cottbus: Einführung in UML

  2. UML-Historie (2/2) Frank Simon, BTU Cottbus: Einführung in UML

  3. Ziel von UML: • Objektorientierte Modellierung aller Systeme in allen Entwicklungsstufen. • Umfangreiche Dokumentation. • Detaillierte Spezifikation der Semantik. • Verfügbarkeit, Akzeptanz, Erweiterbarkeit Frank Simon, BTU Cottbus: Einführung in UML

  4. Implementation view User view Behavioral view Structural view Environment view Views (Ansichten) Frank Simon, BTU Cottbus: Einführung in UML

  5. Implementation view User-View (1/5) User view Behavioral view Structural view Environment view • Wie sieht der Anwender das System? • Beschreibt das Problem und die Lösung aus der Sicht derjenigen Menschen, dessen Probleme durch die Lösung angesprochen werden. • Summe aller Beschreibungen bildet die externe Sicht des Systems. • UML-Notationen: • Use-Cases Frank Simon, BTU Cottbus: Einführung in UML

  6. Implementation view User view Behavioral view Structural view Environment view User-View (2/5): Use Case Diagramme • Einsatz • Analysephase • Kommunikation mit Auftraggeber / Benutzer • Erfassung von Anwendungsfällen (Use Cases) • Elemente • Akteure • System • Use Cases • Kommentare • Beziehungen <<Acteur>> Name Name Name Name Frank Simon, BTU Cottbus: Einführung in UML

  7. Implementation view User view Behavioral view Structural view Environment view Name Name <<uses>> Name Name <<extends>> User-View (3/5): Use Case Diagramme • Beziehungen (Fts): • <<uses>>:Ein Anwendungsfall D benutzt (uses) einen Anwendungsfall B, wenn er dessen Verhalten beinhaltet. Die <<uses>>-Beziehung faktorisiert gemeinsames Verhalten aus Anwendungsfällen heraus, um es in verschiedenen anderen Fällen benutzen zu können. • <<extends>>:Ein Anwendungsfall D erweitert (extends) einen Anwendungsfall B, wenn er an einem Erweiterungspunkt zusätzliches spezialisiertes Verhalten einfügt. Frank Simon, BTU Cottbus: Einführung in UML

  8. Implementation view User view Behavioral view Structural view Environment view User-View (4/5): Use Case DiagrammeBeispiel 1: Frank Simon, BTU Cottbus: Einführung in UML

  9. User-View (5/5): Use Case DiagrammeBeispiel 2: Frank Simon, BTU Cottbus: Einführung in UML

  10. Implementation view User view Behavioral view Structural view Environment view Structural View (1/11) • Modelliert statische Struktur der Problemwelt und der Lösung (logische Sicht). • Ignoriert weitestgehend Verhalten des Systems. • Anwendbar auf verschiedenen Abstraktionsniveaus • Durchgängig benutzbar von Analyse bis zur Wartung • UML-Notationen: • Klassendiagramme (Statische Struktur des Systems) • Objektdiagramme (Statische Struktur des Systems zu einem bestimmten Zeitpunkt während der Ausführung. Beschreiben konkrete Instanziierung eines Klassendiagramms.) Frank Simon, BTU Cottbus: Einführung in UML

  11. Implementation view User view Behavioral view Structural view Environment view Structural View (2/11): Klassendiagramme • Elemente • Klassen: Beschreibung von einer Menge von Objekten mit gleichen strukturellen Eigenschaften und gleichem Verhalten. • Sichtbarkeit: + public, # protected, - private • Besonderheiten: Klassenvariablen und -methoden, abstrakte Klassen/Methoden (Stereotyp) Name Attribute [:type [=initval]] oder Name Operation (arglist): retype Frank Simon, BTU Cottbus: Einführung in UML

  12. Implementation view User view Behavioral view Structural view Environment view Structural View (3/11): Klassendiagramme Name Name • Elemente (Fts) • Interfaces:Definieren eine Menge von extern verfügbarenOperationen, die anderen Klassen angeboten werden. • Templates:Beschreiben eine Familie vonKlassen, die eine gemeinsameForm haben. Spezielle Klassenlegen freie Parameter der Template-Klasse fest. • Entwurfsmuster:Standardentwürfe für Teilprobleme Parameter-List Name <<bind>> (Value-List) Name Rolle Klasse1 Entwurfs- muster Klasse2 Rolle Frank Simon, BTU Cottbus: Einführung in UML

  13. Implementation view User view Behavioral view Structural view Environment view Structural View (4/11): Klassendiagramme * | n..m * | n..m Name Klasse1 Klasse2 • Beziehungen: • Assoziationen (binär) • Beschreiben Verbindungenzwischen Klassen. • Zahlen oder * an den Endender Assoziationen geben an,wieviele Objekte der Klasse manan diesem Ende finden kann, wenn man von einem Objekt auf der anderen Seite ausgeht. Keine Angabe= 1 • „Name“ sollte durch ein  die Leserichtung vorgeben. • Gerichtete Assoziationen (Pfeilspitze) kennzeichnen lediglich Referenzen in Pfeilrichtung. • Assoziationen (n-är) • Raute, die mit den beteiligten Klassen verbunden ist. Rolle1 Rolle2 Name Klasse1 Klasse3 Klasse2 Frank Simon, BTU Cottbus: Einführung in UML

  14. Implementation view User view Behavioral view Structural view Environment view Structural View (5/11): Klassendiagramme Klasse1 Klasse2 Name • Beziehungen (Fts) • Assoziation (Fts) • Qualifizierte AssoziationZugriffsschlüssel auf beteiligteKlasse. • AggregationGanzes-Teil-Beziehung • Kardinalitäten wie bei AssoziationStandard 1:n • KompositionStrengere Form der Aggregation,Teil vom Ganzen existenzabhängig. • Kardinalitäten wie bei Aggregation Klasse1 Klasse2 Klasse1 Klasse2 Frank Simon, BTU Cottbus: Einführung in UML

  15. Implementation view User view Behavioral view Structural view Environment view Structural View (6/11): Klassendiagramme Klasse1 • Beziehungen (Fts) • VererbungGeneralisierung/Spezialisierung Klasse2 Klasse3 Frank Simon, BTU Cottbus: Einführung in UML

  16. Structural View (7/11): 1. Beispiel Kardinalitäten? Frank Simon, BTU Cottbus: Einführung in UML

  17. Structural View (8/11): 2. Beispiel Frank Simon, BTU Cottbus: Einführung in UML

  18. Implementation view User view Behavioral view Structural view Environment view Structural View (9/11): Objektdiagramme • Variante des Klassendiagramms • Zeigt alle in Beziehung stehenden Instanzen • „Snapshot“ eines (Teil-) Systems • Können verwendet werden, um spezielle Objektkonfigurationen zu untersuchen. • Notation: • InstanzName:Klassenname • Nur einfache Links zwischen Klassen • Keine Methoden Frank Simon, BTU Cottbus: Einführung in UML

  19. Implementation view User view Behavioral view Structural view Environment view Structural View (10/11): Objektdiagramme1. Beispiel t=x Frank Simon, BTU Cottbus: Einführung in UML

  20. Implementation view User view Behavioral view Structural view Environment view Structural View (11/11): Objektdiagramme2. Beispiel Frank Simon, BTU Cottbus: Einführung in UML

  21. Implementation view User view Behavioral view Structural view Environment view Behavioral View (1/15) • Modelliert dynamische Aspekte des Systems, sein Verhalten • Ignoriert weitestgehend Struktur des Systems. • Anwendbar auf verschiedenen Abstraktionsniveaus • Durchgängig benutzbar von Analyse bis zur Wartung • UML-Notationen: • Sequenz-Diagramme: Stellt den Fluß von Nachrichten zwischen Objekten im Zeitablauf dar. • Kooperations-Diagramme: Andere Form der Sequenzdiagramme mit Fokus auf der Verantwortlichkeit und Kooperation der beteiligten Objekte. • Statechart-Diagramme: Geben an, bei welchen Ereignissen Objekte einer Klasse ihren Zustand ändern und welche Reaktionen sie dabei zeigen. • Aktivitäts-Diagramme: Andere Form der Statechart-Diagramme, wobei meistens in Zuständen eine Aktivität ausgeführt wird und die meisten Zustandsübergänge durch das Ende einer Aktivität ausgelöst wird. Frank Simon, BTU Cottbus: Einführung in UML

  22. Implementation view User view Behavioral view Structural view Name Environment view Behavioral View (2/15): Sequenzdiagramme • Elemente • Objektinstanz mit Lebenslinie • Aktivierung eines Objektes • Nachricht / Antwort • Rekursion • Löschen eines Objektes Name() Name Frank Simon, BTU Cottbus: Einführung in UML

  23. Implementation view User view Behavioral view Structural view Environment view Behavioral View (3/15): Sequenzdiagramme1. Beispiel Frank Simon, BTU Cottbus: Einführung in UML

  24. Behavioral View (4/15): Sequenz-diagramme2. Beispiel Frank Simon, BTU Cottbus: Einführung in UML

  25. Implementation view User view Behavioral view Structural view Environment view Behavioral View (5/15): Kooperationsdiagramme Objekt::Klasse • Elemente • Objektinstanz • Nachricht • Erstellung /Löschen • Reihenfolge Name New() Destroy() Reihenfolge-Nr.(geschachtelt) Name Frank Simon, BTU Cottbus: Einführung in UML

  26. Behavioral View (6/15): Kooperationsdiagramme1. Beispiel Frank Simon, BTU Cottbus: Einführung in UML

  27. Behavioral View (7/15): Kooperationsdiagramme2. Beispiel Frank Simon, BTU Cottbus: Einführung in UML

  28. Implementation view User view Behavioral view Structural view Environment view Behavioral view (8/15): Statechart-Diagramme(erweiterte Zustandsautomaten) Name Aktivitäten(entry, do, exit) • Elemente • Zustand(Ausprägung von Eigenschafteneines Objektes, die über einegewisse Zeitspanne konstant ist) • Anfangszustand • Endzustand • Zustandsüberführung • Zustandshierarchie Ereignis [Bedingung]/ Aktion E/A Frank Simon, BTU Cottbus: Einführung in UML

  29. Implementation view User view Behavioral view Structural view Environment view Behavioral view (9/15): Statechart-Diagramme • Elemente (Fts.) • Nebenläufige Zustände • Synchronisation Frank Simon, BTU Cottbus: Einführung in UML

  30. Implementation view User view Behavioral view Structural view Environment view Behavioral view (10/15): Statechart-Diagramme1. Beispiel Frank Simon, BTU Cottbus: Einführung in UML

  31. Behavioral view (11/15): Statechart-Diagramme2. Beispiel Frank Simon, BTU Cottbus: Einführung in UML

  32. Behavioral view (12/15): Aktivitäts-Diagramme Implementation view User view Behavioral view Structural view Environment view Name • Elemente • Aktivität • Aktivitätswechsel • Entscheidung • Synchronisation / Splitting [Bedingung] [Bedingung1] [Bedingung2] Frank Simon, BTU Cottbus: Einführung in UML

  33. Behavioror view (13/15): Aktivitäts-Diagramme Implementation view User view Behavioral view Structural view Environment view • Elemente (Fts.) • Startaktivität • Endaktivität • Mitführen vonrelevanten Objektenund deren Zustand Objekt::Klasse [Zustand] Frank Simon, BTU Cottbus: Einführung in UML

  34. Behavioral view (14/15): Aktivitäts-Diagramme1. Beispiel Frank Simon, BTU Cottbus: Einführung in UML

  35. Behavioral view (15/15): Aktivitäts-Diagramme 2. Beispiel Frank Simon, BTU Cottbus: Einführung in UML

  36. Implementation view User view Behavioral view Structural view Environment view Implementation view (1/3) • Beschreibt Struktur der Realisierung (Komponenten, Beziehungen und Abhängigkeiten) • Ignoriert weitestgehend Struktur des Anwendungssystems. • Anwendbar auf der Ebene der Implementierung. • UML-Notationen: • Komponenten-Diagramm Frank Simon, BTU Cottbus: Einführung in UML

  37. Implementation view User view Behavioral view Structural view Environment view Implementation view (2/3): Komponenten-Diagramm Name:Typ • Elemente: • Komponente(Quellcodes, Libraries,Programme...) • Aufruf, Abhängigkeit Frank Simon, BTU Cottbus: Einführung in UML

  38. Implementation view (3/3): Komponenten-Diagramm, 1. Beispiel Frank Simon, BTU Cottbus: Einführung in UML

  39. Implementation view User view Behavioral view Structural view Environment view Environment view (1/3) • Modelliert strukturelle Aspekte aus der Umgebung des Problembereichs und den Zusammenhang zur erstellten Software. Betrachtet wird dabei ein laufendes System. • Stellt Zusammenhang zwischen Implementierung und der Zielumgebung her. • Anwendbar auf der Ebene der Implementierung. • UML-Notationen: • Deployment-Diagramm Frank Simon, BTU Cottbus: Einführung in UML

  40. Implementation view User view Behavioral view Structural view Environment view Environment view (2/3): Deployment-Diagramm Name:Typ • Elemente • Komponenten(Computer, Geräte...) • Kommunikation zwischenKomponenten • Enthaltensein vonImplementierung Name:Typ Name:Typ Name:Typ Frank Simon, BTU Cottbus: Einführung in UML

  41. Environment view (3/3): Deployment-Diagramm, 1. Beispiel Frank Simon, BTU Cottbus: Einführung in UML

  42. Implementation view User view Behavioral view Structural view Environment view Zusammenfassung Komponenten- Diagramm Sequenz-, Kooperations-, Statechart-, Aktivitäts- Diagramm Klassen-, Objekt- Diagramm Deployment- Diagramm Frank Simon, BTU Cottbus: Einführung in UML

  43. Referenzen • Sinan Si Alhir: „UML in a nutshell - a desktop quick reference“, O‘Reilly & Associates, USA 1998 • Klaus Zerbe: „Bauplan für Objekte - eine Einführung in objektorientierte Verfahren mit der Unified Modelling Language“, in c‘t 21/1999, Seite 338-354, Heise-Verlag, Hannover 1999 • Günter Wahl: „UML kompakt“, in OBJEKTspektrum 2/98, Seite 22-33, SIGS Conferences, Bergisch Gladbach 1998 • Alek Opitz: „Unified Modeling Language (UML)“, Ausarbeitung für das Proseminar „Java“ im Sommersemester 1998 Frank Simon, BTU Cottbus: Einführung in UML

More Related