53
1 Vorlesung "Software-Engineering" Vorige Vorlesung Pflichtenheft (requirements specification document) Charakterisierung von Software-Qualität Detaillierte Anforderungsanalyse (detailed requirements engineering) Heute: Spezifikation mit UML Strukturdiagramme Teil 1 Rainer Marrone, TUHH, Arbeitsbereich STS

Vorlesung Software-Engineering - STS · 2 Bücher über UML2 z UML@Work objektorientierte Modellierung mit UML2 z M. Hitz, G. Kappel, E. Kapsammer, W. Retschitzegger z UML 2 und Patterns

Embed Size (px)

Citation preview

1

Vorlesung "Software-Engineering"

zVorige VorlesungyPflichtenheft (requirements specification document)

Charakterisierung von Software-Qualität

yDetaillierte Anforderungsanalyse (detailed requirements

engineering)

zHeute:ySpezifikation mit UML

yStrukturdiagramme Teil 1

Rainer Marrone, TUHH, Arbeitsbereich STS

2

Bücher über UML2

z UML@Work

objektorientierte

Modellierung mit UML2

z M. Hitz, G. Kappel, E.

Kapsammer, W.

Retschitzegger

z UML 2 und Patterns

angewendet -

Objektorientierte

Softwareentwicklung

z Craig Larman

z Methodische

objektorientierte

Softwareentwicklung

z Mario Winter

3

Diagramme der UML2

M. Jeckle: UML 2.0. Modellierung 2004, Marburg, 2004-03-24

4

Klassendiagram (1 / 2)

z Eine Klasse beschreibt Objekte mit gemeinsamen

Eigenschaften. Diese Eigenschaften umfassen Struktur,

d.h. Attribute und Beziehungen, als auch Verhalten.

z Die von einer Klasse beschriebenen Objekten werden als

Instanzen dieser Klasse bezeichnet.

yJede Klasse (für sich allein betrachtet) stellt die gültige

Wertebereiche ihrer Instanzen fest, z.B. „jede Person muss

einen Vornamen und ein Namen besitzen“

yAußerdem, Assoziationen und Kompositionen machen Aussagen

über die gültigen Beziehungsausprägungen (Verbindungen)

zwischen Objekten

z.B. „jedes Auto verfügt über einen Motor, d.h. es kann keine

Instanzen von Motor geben die isoliert stehen“.

5

Klassendiagram (2 / 2)

z Eine UML Klasse wird als Typ in einer Objektorientierten

Programmiersprache abgebildet.

z OCL (Object Constraint Language) kann auch ins Spiel kommen, um die

Aussagen über gültige Wertebereiche und Verbindungen weiter zu

verschärfen, z.B.

context Person

inv: isFahrer implies age >= 18

d.h. obwohl nach dem Typ vom Attribut age (Integer) Werte unter 18

zulässig sind, wird OCL eingesetzt, um zu dokumentieren, dass diese

Werte in Zusammenhang mit isFahrer = true nicht zulässig sind. Das

System darf nicht solche Weltdarstellungen abbilden. Die

Implementierung sollte sich an diese Regeln halten. Das wird durch

automatisierte Generierung aus Modellen, Tests oder Verifikation

sichergestellt.

6

Klassendiagramm: Aufgabe in Projekt

z Aufgabe im Projekt:

yVariierend ...

y… von der ersten Darstellung konzeptueller Dateninhalte

y… über plattformunabhängige logische Modelle

y… bis hin zu „Implementierungsbauplänen“

(„Bilder-für-Java“, „Kästchen-und-Strichchen-statt-C++“)

z Ersetzt oftmals das klassische, in Entity Relationship-

Notation abgefasste, Datenmodell. In diesem Fall, haben

wir mit ORM (Object-Relational Mapping) zu tun.

7

Visuelle Notation von Klassendiagramme

M. Jeckle: UML 2.0. Modellierung 2004, Marburg, 2004-03-24

8

Attribute

z Attribute können mit den in Programmiersprachen

üblichen Typen typisiert werden:

yBoolean, Integer, Real, Date

z aber auch mit anwendungsspezifischen Datentypen:

yAdresse, Bestellungsnummer

z Auf Wunsch, kann man die Deklaration eines Attributs

ergänzen um:

yeinen Defaultwert

ySichtbarkeit (public, private)

yÄnderbarkeit (changeable, readOnly)

9

Operationen

z Eine Operation kann Attributwerte lesen oder schreiben,

Berechnungen ausführen, Verbindungen zu anderen Objekte knüpfen

und lösen sowie Operationen anderer Objekte aufrufen.

z Beispiel:

public static void main(String[] args) {

ILoyaltyProgram lp = new LoyaltyProgram();

ICustomer c = new Customer();

c.addToCards(new CustomerCard( true));

lp.getParticipants().add(c);

}

10

Eigenschaften von Attributen und Operationen

11

Assoziationen

12

Assoziation - Navigationsrichtung

13

Assoziation als Attribut

14

Assoziation - Multiplizität

15

Assoziation - Rollen

16

Assoziation - Ordnung und Eindeutigkeit

17

Assoziation - Teilmenge und Vereinigung

18

Exklusive Assoziation

19

Qualifizierte Assoziation 1/2

20

Qualifizierte Assoziation 2/2

21

Assoziationsklasse 1/2

22

Assoziationsklasse 2/2

23

N-äre Assoziation

24

N-äre Assoziation

25

Aggregation

26

Schwache Aggregation

27

Starke Aggregation

28

Aggregation - Gegenüberstellung der Eigenschaften

Kunde – Auftrag Tisch – Tischbeine

Projekt – MitarbeiterStipendium – Eltern

Autobestandteil – Auto

..*

29

Starke Aggregation vs. Assoziation - Faustregeln

30

Abstrakte Klassen

31

Generalisierung

32

Generalisierung - Eigenschaften

33

Generalisierung von Assoziationen

34

Generalisierung - Redefinition von geerbten

Merkmalen 1/2

35

Generalisierung - Redefinition von geerbten

Merkmalen 2/2

36

Beispiel – CALENDARIUM

37

Abhängigkeiten

38

Interface

39

Interface – Beispiel CALENDARIUM 1/2

40

Interface – Beispiel CALENDARIUM 2/2

41

Interface – Vorteile

42

Parametrisierte Klasse – Template 1/2

43

Parametrisierte Klasse – Template 2/2

44

Parametrisiertes Paket – Paketschablone

45

Objektdiagramm - Basiskonzepte

46

Objektdiagramm - Beispiel

47

Paketdiagramm

48

Packetdiagramm - Einführung

49

Packetdiagramm – Import(1)

50

Packetdiagramm – Import(2)

51

Packetdiagramm – Import(3)

Verwendet man statt <<import>> <<accces>> -> keine Transitivität

52

Paketdiagramm - Hierarchien von Paketen

53

Beispiel