UML WS 09/10: Datenbanken vs MarkUp Dozent: Prof. Dr. Manfred Thaller

Präsentation zum Thema: "UML WS 09/10: Datenbanken vs MarkUp Dozent: Prof. Dr. Manfred Thaller"—  Präsentation transkript:

1 UML WS 09/10: Datenbanken vs MarkUp Dozent: Prof. Dr. Manfred Thaller
Referentin: Sarah Burmann Datum :

2 Was ist UML? UML = Unified Modeling Language
standardisierte Modellierungssprache (durch die OMG) legt einen bestimmten Sprachumfang fest in dem festgehalten ist, welche Begriffe Teil der Sprache sind und was die einzelnen Begriffe bedeuten ist darauf ausgelegt Modelle zum besseren Verständnis zu erstellen Elemente der Sprache werden durch grafische Elemente dargestellt (z.B. Klasse =Rechteck) besitzt eine Grammatik durch die verschiedene Elemente logisch miteinander verknüpft werden können

3 Was ist UML? wurde zur Erstellung von Modellen in der Softwareentwicklung entwickelt Modell = Betrachtung eines Teilausschnitts; wichtige Aspekte werden herausgestellt, unwichtige vernachlässigt/weggelassen (information hiding) UML ermöglicht eine einfache/einfachere Beschreibung eines Originals mit dem Ziel, dass Original besser verstehen zu können

4 Was ist UML? UML definiert 13 Diagrammtypen
Je nach Betrachtungsweise werden unterschiedliche UML-Elemente und unterschiedliche Regeln zum Zusammenstellen benötigt verhindert, dass alle Formen verwendet werden müssen UML unterscheidet zwischen Struktur- und Verhaltensdiagrammen Strukturdiagramme: werden verwendet, um die Struktur einer Software zu beschreiben (statisch) Klassendiagramme Verhaltensdiagramme: werden verwendet, um Abläufe zu erklären (dynamisch) Use cases

5 Vorteile von UML soll helfen, den Überblick zu behalten
soll die Entwicklung aus unterschiedlichen Blickwinkeln beleuchten soll als Koordinationsinstrument ein Vorhaben vorantreiben als grafische Darstellung nicht nur für „Techniker“ gedacht/geeignet, sondern abteilungsübergreifend einsetzbar ist unabhängig von Programmiersprachen und Plattformen

6 Klassendiagramme Klassendiagramme sind die wichtigsten Strukturdiagramme der UML stellen die Zusammenhänge zwischen Klassen und/oder den Aufbau von Klassen dar statischer Diagrammtyp, da lediglich die Klassen mit ihren Methoden und Attributen sowie die statischen Verbindungen zwischen ihnen dargestellt werden

7 Klassendiagramme Zur Erinnerung: eine Klasse ist eine Zusammenfassung gleichartiger Objekte und definiert die Attribute und Methoden dieser Objekte. Alle Objekte (Instanzen) einer Klasse haben das gleiche Verhalten und die selben Attribute UML stellt Klassen durch Rechtecke dar Attribute und Operationen der Klasse werden jeweils durch eine horizontale Linie vom Klassennamen getrennt Attribute können näher beschrieben werden, z.B. durch ihren Typ oder Initialwert, müssen aber mindestens mit ihrem Namen dargestellt werden Operationen/Methoden können ebenfalls näher beschrieben werden (Parameter, Initialwerte) und müssen auch mindestens mit ihrem Namen dargestellt werden

8 Klassendiagramme Klassenname Attribute Methoden

9 Klassendiagramme UML ermöglicht die Einschränkung des Zugriffs auf Attribute und Methoden - private (privates Klassenmerkmal) + public (öffentliches Klassenmerkmal) # protected (geschützt) ~ package (Paket) die Definition von Attributen und Methoden erfolgt durch die folgende Notation AttributName : Datentyp MethodenName () : Datentyp

10 ObjektName: KlassenName
Klassendiagramme Exkurs Objekte: Objekte sind Exemplare einer Klasse mit einer bestimmten Anzahl von Attributen, deren Struktur in der Klasse des Objekts definiert sind Objekte werden in UML ebenfalls durch Rechtecke dargestellt der Objektname muss unterstrichen werden und ggfs. die zugehörige Klasse, durch einen Doppelpunkt getrennt, angegeben werden ObjektName ObjektName: KlassenName Name der Klasse kann weggelassen werden, wenn die Klasse des Objekts aus dem Zusammenhang deutlich erkennbar ist, oder wenn die Klasse unbekannt ist Standard-Angabe eines Objekts

11 Klassendiagramme Beziehungen von Klassen können in Klassendiagrammen unterschiedlich dargestellt werden Gewöhnliche Assoziation: Klasse A kann auf Klasse B zugreifen (Navigierbarkeit) Komposition: Klasse C ist abhängig von Klasse D und kann ohne diese nicht existieren Vererbung: Klasse F ist Kind von Klasse E und erbt alle Eigenschaften und Methoden dieser Klasse

12 Klassendiagramme eine Verfeinerung der Assoziationen lässt sich durch das Einfügen von Multiplizitäten an den navigierbaren Enden erreichen Eine Multiplizität gibt an, ob es sich zwischen zwei Klassen um eine 1:1, 1:n oder n:m Beziehung handelt 1:1 = jedes Objekt einer Klasse steht mit genau einem Objekt einer anderen Klasse in Verbindung 1:n = ein Objekt einer Klasse hat Zugriff auf mehrere Objekte einer anderen Klasse n:m = Objekte beider Klassen haben Zugriff auf mehrere Objekte der anderen Klasse keine Angabe bedeutet immer, dass eine 1:1 Beziehung besteht 1:n Beziehungen werden durch setzen eines * am navigierbaren Ende dargestellt n:m Beziehungen werden durch das setzen einer Zahl angegeben (Unter- und Obergrenze können durch setzen zweier Punkte angegeben werden (0..2))

13 Klassendiagramme Ein Objekt der Klasse A kann auf mehrere Objekte der Klasse B zugreifen Ein Objekt der Klasse C hat Zugriff auf kein oder genau ein Objekt der Klasse D

14 Klassendiagramme Ein Beispiel: Dargestellt werden soll ein Einkaufsvorgang in einem Onlineshop

15 Use-Case-Diagramme dt. Anwendungsfall-Diagramm
dynamisches Diagramm der Kategorie Verhaltensdiagramme wird zur Spezifikation der Anforderungen an ein System eingesetzt stellt die Beziehungen und Abhängigkeiten zwischen Anwendungsfällen und Akteuren dar Ziel ist, zu zeigen was mit einem Softwaresystem (welches noch nicht existiert) erreicht werden soll Wichtig ist das WAS nicht das WIE

16 Use-Case-Diagramme grundlegende Begriffe eines Use-Case-Diagramms sind: Akteur, System, Use Case (Anwendungsfall), Assoziation, Beziehungen (inculde, extend) Use Case (Anwendungsfall): beschreibt eine bestimmte Menge von Aktionen, die durch schrittweise Ausführung ein bestimmtes Verhalten formen Darstellungsform eines Use Case System: zu entwickelnde Software (realisiert das Verhalten, das durch die Use Cases beschrieben wird) Darstellungsform eines Systems UseCaseName SystemName

17 Use-Case-Diagramme Akteur:
stellt den Anwender dar. Er interagiert mit dem System und befindet sich immer außerhalb des Systems Darstellungsform eines Akteurs Assoziationen: Verbindungslinien, die Zusammenhänge zwischen Elementen an den Enden der Verbindungslinie darstellen Es gibt zwei Arten von Verbindungslinien 1. eine durchgezogene Linie stellt eine Assoziation zwischen Akteur und Use Case dar (Akteur wendet Use Case an) Name

18 <<include>>
Use-Case-Diagramme 2. ein gestrichelter Pfeil stellt eine Assoziation zwischen zwei Use Cases dar Da es zwei Arten der Assoziation zwischen Use Cases gibt, werden Schlüsselwörter zur eindeutigen Benennung eingesetzt <<include>>-Beziehung: beschreibt, dass ein Use Case A das Verhalten eines Use Case B importiert Wenn Use Case A ausgeführt wird, wird von diesem Use Case ausgehend Use Case B gestartet. include-Beziehungen sind nicht optional, sondern werden immer ausgeführt Kundendaten ändern Berechtigung prüfen <<include>> Use Case B Use Case A

19 <<extend>>
Use-Case-Diagramme <<extend>>-Beziehung: gibt an, dass der Use Case von dem die Linie ausgeht möglicherweise den anderen Use Case erweitert Der erste Use Case wird nur dann ausgeführt, wenn bestimmte Bedingungen im zweiten Use Case wahr sind extension points: Beschriftung CD beschriften Musik CD erstellen <<extend>>

20 Use-Case-Diagramme