Vorlesung "Software-Engineering"

Transkript

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

2 Bücher über UML2 objektorientierte Modellierung mit UML2 M. Hitz, G. Kappel, E. Kapsammer, W. Retschitzegger UML 2 und Patterns angewendet - Objektorientierte Softwareentwicklung Craig Larman Methodische objektorientierte Softwareentwicklung Mario Winter 2

3 Diagramme der UML2 M. Jeckle: UML 2.0. Modellierung 2004, Marburg,

4 Klassendiagram (1 / 2) Eine Klasse beschreibt Objekte mit gemeinsamen Eigenschaften. Diese Eigenschaften umfassen Struktur, d.h. Attribute und Beziehungen, als auch Verhalten. Die von einer Klasse beschriebenen Objekten werden als Instanzen dieser Klasse bezeichnet. Jede 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 Auß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. 4

5 Klassendiagram (2 / 2) Eine UML Klasse wird als Typ in einer Objektorientierten Programmiersprache abgebildet. 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. 5

6 Klassendiagramm: Aufgabe in Projekt 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. In diesem Fall, haben wir mit ORM (Object-Relational Mapping) zu tun. 6

7 Visuelle Notation von Klassendiagramme M. Jeckle: UML 2.0. Modellierung 2004, Marburg,

8 Attribute Attribute können mit den in Programmiersprachen üblichen Typen typisiert werden: Boolean, Integer, Real, Date aber auch mit anwendungsspezifischen Datentypen: Adresse, Bestellungsnummer Auf Wunsch, kann man die Deklaration eines Attributs ergänzen um: einen Defaultwert Sichtbarkeit (public, private) Änderbarkeit (changeable, readonly) 8

9 Operationen Eine Operation kann Attributwerte lesen oder schreiben, Berechnungen ausführen, Verbindungen zu anderen Objekte knüpfen und lösen sowie Operationen anderer Objekte aufrufen. Beispiel: public static void main(string[] args) { ILoyaltyProgram lp = new LoyaltyProgram(); ICustomer c = new Customer(); c.addtocards(new CustomerCard( true)); lp.getparticipants().add(c); } 9

10 Eigenschaften von Attributen und Operationen 10

11 Assoziationen 11

12 Assoziation - Navigationsrichtung 12

13 Assoziation als Attribut 13

14 Assoziation - Multiplizität 14

15 Assoziation - Rollen 15

16 Assoziation - Ordnung und Eindeutigkeit 16

17 Assoziation - Teilmenge und Vereinigung 17

18 Exklusive Assoziation 18

19 Qualifizierte Assoziation 1/2 19

20 Qualifizierte Assoziation 2/2 20

21 Assoziationsklasse 1/2 21

22 Assoziationsklasse 2/2 22

23 N-äre Assoziation 23

24 N-äre Assoziation 24

25 Aggregation 25

26 Schwache Aggregation 26

27 Starke Aggregation 27

28 Aggregation - Gegenüberstellung der Eigenschaften Kunde Auftrag Tisch Tischbeine..* Stipendium Eltern Projekt Mitarbeiter Autobestandteil Auto 28

29 Starke Aggregation vs. Assoziation - Faustregeln 29

30 Abstrakte Klassen 30

31 Generalisierung 31

32 Generalisierung - Eigenschaften 32

33 Generalisierung von Assoziationen 33

34 Generalisierung - Redefinition von geerbten Merkmalen 1/2 34

35 Generalisierung - Redefinition von geerbten Merkmalen 2/2 35

36 Beispiel CALENDARIUM 36

37 Abhängigkeiten 37

38 Interface 38

39 Interface Beispiel CALENDARIUM 1/2 39

40 Interface Beispiel CALENDARIUM 2/2 40

41 Interface Vorteile 41

42 Parametrisierte Klasse Template 1/2 42

43 Parametrisierte Klasse Template 2/2 43

44 Parametrisiertes Paket Paketschablone 44

45 Objektdiagramm - Basiskonzepte 45

46 Objektdiagramm - Beispiel 46

47 Paketdiagramm 47

48 Packetdiagramm - Einführung 48

49 Packetdiagramm Import(1) 49

50 Packetdiagramm Import(2) 50

51 Packetdiagramm Import(3) Verwendet man statt <<import>> <<accces>> -> keine Transitivität 51

52 Paketdiagramm - Hierarchien von Paketen 52

53 Beispiel 53