UML. So#wareprak*kum 2007

Transkript

1 UML So#wareprak*kum 2007

2 Inhalt Mo*va*on Eigenscha#en Sichten Klassendiagramm SoPra '07 2

3 Pro und Contra UML s just pain/ng David Schmidt, Kansas State University 2006 The UML as a Formal Modeling Nota/on R. France et al., Florida Atlan*c University SoPra '07 3

4 Mo1va1on (I) für die Entwicklung komplexer Systeme ist Modellierung unabdingbar Modellierung Abstrak*on der Realität mit Konzentra*on auf die wesentlichen Aspekte SoPra '07 4

5 Warum Modellierung? (I) Beispiel 1: Bau einer HundehüZe einfache ArbeitsschriZe einfache Werkzeuge einfacher Bauplan keine Architektur notwendig! SoPra '07 5

6 Warum Modellierung? (II) Beispiel 2: Bau einer Kathedrale aufwendige ArbeitsschriZe viele spezielle Werkzeuge komplizierte Baupläne ohne Architektur nicht realisierbar! SoPra '07 6

7 Mo1va1on (II) Modellierung hil# die Struktur und das Verhalten zu beschreiben und zu disku*eren das System zu verstehen die Probleme zu erkennen und zu beheben SoPra '07 7

8 Mo1va1on (III) Modellierung kann die Struktur und das Verhalten spezifizieren das System visualisieren aus einer Vorlage ein System konstruieren Entscheidungen dokumen*eren SoPra '07 8

9 Mo1va1on (IV) Modellierung braucht (zur Realisierung dieser Aspekte) eine einheitliche und umfassende Nota*on UML Unified Modeling Language SoPra '07 9

10 Eigenscha?en Visualisierung Konstrukte: z.b. Diagramme heute: Klassendiagramme Spezifika*on sehr abstrakt: Stereotypen sehr implemen*erungsnah: No*zen, OCL Konstruk*on Forward Engineering Reverse Engineering Dokumenta*on Spezifika*on: Analyse, Design Implemen*erung: Quellcode, Tesjälle SoPra '07 10

11 Sichten (I) Unterteilung der Konstrukte in Sichten Weshalb? Betrachtung des Systems aus einer bes*mmten Perspek*ve Fokussierung auf einen speziellen Sachverhalt Warum? es sind verschiedene Personengruppen involviert Kunde, Benutzer, Analy*ker, Entwickler, Tester, u.s.w. hilfreich für das Verständnis SoPra '07 11

12 Sichten (II) Strukturelle Klassifika*on Objekte und deren Beziehung zu anderen Objekten Dynamisches Verhalten Änderung des Systems in Abhängigkeit der Zeit Modell Management Organisa*on des Modells an sich SoPra '07 12

13 Sichten (III) SoPra '07 13

14 Klassendiagramm (I) Klassen stellen das Vokabular des Systems dar Sie bilden die Basis, auf der alle anderen Konstrukte auoauen SoPra '07 14

15 Klassendiagramm (II) SoPra '07 15

16 Findungsprozess Iden*fika*on von Dingen, die Benutzer und Entwickler zur Beschreibung des Problems und der Lösung benutzen HilfsmiZel: Anwendungsfall basierte Analyse CRC Karten (CRC = Class, Responsibility, Collabora*ons) SoPra '07 16

17 Verantwortlichkeiten In der Analyse Phase werden Klassen Verantwortlichkeiten zugeteilt; Ausgewogenheit ist wich*g Erst in der Entwurfs und Implemen*erungsphase werden AZribute und Opera*onen festgelegt, um die speziellen Verantwortlichkeiten zu bewerkstelligen SoPra '07 17

18 Sichtbarkeit Sichtbarkeit (Visibility) = Festlegung der Zugriffsrechte anderer Klassen auf die AZribute bzw. Opera*onen einer Klasse public (+) Jede beliebige Klasse darf zugreifen protected (#) Nur die definierende Klasse selbst und von dieser abgeleitete Klassen dürfen zugreifen private ( ) Zugriff nur durch die definierende Klasse SoPra '07 18

19 Sichtbarkeit (II) Graphische Darstellung: SoPra '07 19

20 AIribute ADribut (AZribute) = mit Namen versehene Eigenscha# einer Klasse Klasse kann beliebig viele (auch keine) AZribute besitzen SoPra '07 20

21 AIribute (II) Verschiedene Detaillierungsgrade möglich Generelle Syntax: [Sichtbarkeit] Name [[Mul*plizität]][:Typ] [= ini*aler Wert][{Eigenscha#}] SoPra '07 21

22 AIribute (III) Eigenscha#en für AZribute changeable keine Restrik*on (Standard) frozen Wert darf nicht mehr geändert werden, nachdem das Objekt ini*alisiert ist SoPra '07 22

23 Opera1onen Opera/on = mit Namen versehenes Verhalten einer Klasse, das für jedes Objekt dieser Klasse angefordert werden kann Opera*onen können den Zustand eines Objektes verändern SoPra '07 23

24 Opera1onen (II) Verschiedene Detaillierungsgrade möglich Generelle Syntax: [Sichtbarkeit] Name [(Parameter Liste)] [:Rückgabe Typ][{Eigenscha#}] SoPra '07 24

25 Opera1onen (III) Signatur = Name [(Parameter Liste)] Einzelnen Parameter der Signatur haben die folgende Syntax: [Richtung] Name : Typ [= Standard Wert] SoPra '07 25

26 Opera1onen (IV) Richtungen in out Eingabe Parameter; darf nicht geändert werden Ausgabe Parameter; ÜbermiZlung von Informa*on zum Aufrufer inout Eingabe Parameter, der modifiziert werden kann SoPra '07 26

27 Opera1onen (V) Eigenscha#en für Opera*onen: leaf Opera*on darf nicht überschrieben werden (Java: final, C++: nicht virtuelle Funk*on) isquery Ausführung der Opera*on ändert den Systemzustand nicht (keine Seiteneffekte) (C++: const Funk*on) SoPra '07 27

28 Abstrakte Klassen In komplexeren Klassenhierarchien werden üblicherweise gewisse Klassen als abstrakt (abstract) spezifiziert Abstrakte Klasse = Klasse, von der es keine direkten Objekte geben darf (Java: abstract, C++: mind. eine rein virtuelle Funk*on) Zur Nutzung der Funk*onalität von abstrakten Klassen leitet man eigene Klassen von diesen ab SoPra '07 28

29 Abstrakte Klassen (II) Graphische Darstellung: Klassenname wird kursiv geschrieben SoPra '07 29

30 Abstrakte Opera1onen Ebenso lassen sich Opera*onen als abstrakt spezifizieren (Java: abstract, C++: rein virtuelle Funk*on) Abstrakte Opera*onen müssen in abgeleiteten Klassen implemen*ert werden Graphische Darstellung: Opera*onsname wird kursiv geschrieben SoPra '07 30

31 Generalisierung Generalisierung (Generaliza*on) = Beziehung zwischen einem allgemeinen Element (hier Oberklasse (Superclass)) und einem spezielleren Element (hier Unterklasse (Subclass)) Durch Generalisierung erbt (inherits) die Unterklasse die Struktur und das Verhalten der Oberklasse SoPra '07 31

32 Generalisierung (II) Unterklasse erweitert oder modifiziert i.a. Funk*onalität der Oberklasse Vorteile der Generalisierung: Reduzierung des Implementa*onsaufwandes Oberklasse ist durch Unterklasse ersetzbar Nutzung von Polymorphie SoPra '07 32

33 Generalisierung (III) Graphische Darstellung: Linie mit Dreieck an dem Ende, welches auf die Oberklasse zeigt SoPra '07 33

34 Assozia1on Assozia/on (Associa*on) = strukturelle Beziehung zwischen Elementen MiZels Assozia*on modelliert man die direkte Zugriffsmöglichkeit der beteiligten Elemente aufeinander SoPra '07 34

35 Assozia1on (II) Graphische Darstellung: Linie zwischen beteiligten Elementen SoPra '07 35

36 Namen Assozia*on kann mit einem Namen versehen werden, um die Beziehung zu verdeutlichen Op*onal: Angabe der Richtung, in welcher der Name gelesen wird SoPra '07 36

37 Rollen Klassen, die an einer Assozia*on beteiligt sind, spielen in diesem Kontext eine gewisse Rolle Dieselbe Klasse kann verschiedene Rollen in anderen Assozia*onen spielen SoPra '07 37

38 Mul1plizität Mul/plizität einer Rolle = Anzahl der Verbindungen, die es für eine Rolle geben kann SoPra '07 38

39 Naviga1on Klasse A und Klasse B durch Assozia*on verbunden von Objekt der Klasse A kann man zu Objekt der Klasse B navigieren und umgekehrt Einschränkung der Navigierbarkeit durch explizite Spezifika*on der Richtung mit Pfeilspitze SoPra '07 39

40 Naviga1on (II) Beispiel: Einschränkung der Navigierbarkeit bedeutet nicht, dass überhaupt nicht auf das andere Objekt zugegriffen werden kann Im Vordergrund steht direkter, einfacher Zugriff (i.a. durch Speichern von Referenz/Pointer) SoPra '07 40

41 Sichtbarkeit Für Assozia*on lässt sich wie bei AZributen und Opera*onen Sichtbarkeit festlegen (Kennzeichnung am Rollennamen) Beispiel: Nur von Objekt der Klasse Benutzer selbst darf auf das Passwort Objekt zugegriffen werden SoPra '07 41

42 Referenzen Einführung in UML Dino Ahr Universität Heidelberg Wirtscha#sinforma*k I Prof. Dr. Hermann Siebdrat Fachhochschule Bonn Rhein Sieg SoPra '07 42

43 Buch Analyse und Design mit UML 2.1 Bernd Oestereich SoPra '07 43