close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

Datenbanksysteme: Was, Wie, Warum?

EinbettenHerunterladen
LEHRSTUHL FÜR DATENBANKEN
Informatik II für Verkehrsingenieure
Objektorientierung Softwareentwicklung
© Dr.-Ing. Dirk Habich |
> Organisatorisches
Klausurtermin
 Datum: 07.08.2014
 Uhrzeit: 13:00 – 14:30 Uhr
 Ort (tentativ)
 SCH/A251/H
 HSZ/AUDI/H
 Einschreibung über HISQIS
 Materialien
 Personal- und Studentenausweis
 dokumentenechter Stift
 Trinken und Essen
© Dr.-Ing. Dirk Habich |
|
2
> Überblick
Folgende Begriffe/Prinzipien sollten bekannt sein
Abstraktion
Objekte
Vererbung
Klasse
Objektorientierte
Programmierung
Attribute
Fähigkeiten
Kapselung
Beziehungen
Persistenz
Polymorphie
© Dr.-Ing. Dirk Habich |
|
3
> Objektorientierte SW-Entwicklung
Prozess der objektorientierten Softwareentwicklung
Analyse
Entwurf/Design
- Wünsche und Anforderungen erfassen
- Fachkonzept erstellen
- „Mini-Welt“ als Objektmodell modellieren
- Übertragung des Objektmodells der „Mini-Welt“
in die Welt der Software
- Ergänzungen und Modifizierungen vornehmen
Transformation
Software
© Dr.-Ing. Dirk Habich |
- Lauffähiges Programm wird erstellt unter
Verwendung einer objektorientierten Sprache
|
4
>
Analyse
© Dr.-Ing. Dirk Habich |
|
5
> UML
UML = Unified Modeling Language
UML ist eine Modellierungssprache.
 UML dient der Anforderungsbeschreibung für Organisationssysteme und
Softwaresysteme.
 UML ermöglicht die Beschreibung von Struktur und Verhalten (Abläufe)
Benutzer
 Softwareentwickler
 Systemanalytiker
 Systemarchitekten
Anwendungsbereiche
 Informatik
 Informationsmanagements
 Prozessmanagements
© Dr.-Ing. Dirk Habich |
|
6
> UML (2)
Wichtige Ziele des UML-Sprachentwurfs:
Höhere Abstraktionsform
Verständlichkeit
 durch die Verwendung der Diagrammform
Lesbarkeit für diese Zielgruppen:
 Manager
 Benutzer
Ausführbarkeit (z.B. Code-Generierung)
© Dr.-Ing. Dirk Habich |
|
7
> UML Modellelemente
Use Case
Assoziation
Dynamisches
Konzept
statisches
Konzept
Generalisierung
Szenario
Aktivität
Paket
Attribut
Zustandsautomat
Operation
Basiskonzepte
statisches
Modell
© Dr.-Ing. Dirk Habich |
Objekt
Klasse
dynamisches
Modell
|
8
> UML - Elemente
© Dr.-Ing. Dirk Habich |
|
9
> Anwendungsfalldiagramme
© Dr.-Ing. Dirk Habich |
|
10
> Anwendungsfälle
Ein Anwendungsfall (use case)
spezifiziert eine Folge von Aktionen, die
das System in Interaktion mit Akteuren
ausführt.
Ein Akteur ist eine Rolle, die ein Benutzer
bzw. ein anderes System spielt, wenn es
mit dem System interagiert.
Anwendungsfalldiagramm
 Überblick über das System und seine
Schnittstellen zur Umgebung auf
hohem Abstraktionsniveau
System als Black Box betrachtet
 Akteure stets außerhalb des
betrachteten Systems
© Dr.-Ing. Dirk Habich |
|
11
> Beispiel
© Dr.-Ing. Dirk Habich |
|
12
> UML distilled
© Dr.-Ing. Dirk Habich |
|
13
> Beziehung von Anwendungsfällen
Erweiterung <<extend>>
 Use Case B spezifiziert Erweiterung für
Basis Use Case A
 Erweiterung wird unter bestimmten
Bedingungen ausgeführt
Einschließen <<include>>
 Gemeinsame Funktionalität in Use
Case A und B wird in Use Case C
beschrieben
 Use Case C wird als Teil von Use Case
A und B wiederverwendet
Generalisierung
 Use Case B und C spezialisieren Use
Case A
© Dr.-Ing. Dirk Habich |
|
14
> Sequenzdiagramme
© Dr.-Ing. Dirk Habich |
|
15
> Szenario
Ist eine Folge von Verarbeitungsschritten, die unter bestimmten Bedingungen
auszuführen ist
Schritte sollen Hauptziel des Akteurs realisieren
Beginnen mit auslösendem Ereignis
Laufen bis Ziel erreicht ist oder abgebrochen wird
Anwendungsfall kann durch Kollektion von Szenarien dokumentiert werden
Modellierung durch Interaktionsdiagramme:




Sequenzdiagramm
Kommunikationsdiagramm
Timing-Diagramm
Interaktionsübersichtsdiagramm
© Dr.-Ing. Dirk Habich |
|
16
> Use Case Diagram
© Dr.-Ing. Dirk Habich |
|
17
> Sequenzdiagramm für Kauf am Telefon
© Dr.-Ing. Dirk Habich |
|
18
> Sequenzdiagramm
Zeigt Folge von Verarbeitungsschritten als Interaktion zwischen mehreren
Kommunikationspartnern (Objekte mit Lebenslinie)
© Dr.-Ing. Dirk Habich |
|
19
> Modellierungsphilosophien
Anwendungsfälle zuerst
 Beginne mit Anwendungsfällen
 Leite Struktur- und Verhaltensmodelle ab
Nicht Anwendungsfall-getrieben
 Regelmäßige Konsistenzkontrolle zwischen
 Anwendungsfallmodellen und
 allen anderen Modellen
© Dr.-Ing. Dirk Habich |
|
20
> Aktivitätsdiagramme
© Dr.-Ing. Dirk Habich |
|
21
> Aktivitäten
Beschreiben Ausführung von Funktionalität bzw. Verhalten
Beschreibt sowohl Kontroll- als auch Datenfluss
Gerichteter Graph mit unterschiedlichen Knotentypen
 Aktionsknoten
 kleinste ausführbare Funktionseinheit
 Kontrollknoten
 Start- und Endknoten, Split und Synchronisation, Entscheidung und Zusammenführung
 Objektknoten
 Modellieren Datenübergabe zwischen Aktionen
Insbesondere zur detaillierten Spezifikation von Anwendungsfällen
© Dr.-Ing. Dirk Habich |
|
22
> Beispiel
Besuch einer Vorlesung
© Dr.-Ing. Dirk Habich |
|
23
> Aktivitätsdiagramme
Datenfluss
 Rechteck definiert Objektknoten
zur Datenübergabe
Ereignisse
 Ereignisempfänger = Aktionen zur
Ereignisverarbeitung
© Dr.-Ing. Dirk Habich |
|
24
> Aktivitätsdiagramme
Darstellung der Sequenz von Aktionen
Ablauf von Start- bis Endpunkt
Betrachtung von Entscheidungspunkten
Darstellung paralleler Verarbeitung
Einbezug beteiligter Objekte
Weitere (nicht illustrierte) Ausdrucksmittel
 Unterbrechungen
 Signale (Eingabe/Ausgabe)
 ...
© Dr.-Ing. Dirk Habich |
|
25
> Zustandsdiagramme
© Dr.-Ing. Dirk Habich |
|
26
> Zustandsautomat
Besteht aus Zuständen und Zustandsübergängen
Objekt kann nacheinander verschiedene Zustände annehmen
Befindet sich zu einem Zeitpunkt in genau einem Zustand
Zustandsübergänge werden durch Ereignisse ausgelöst
 Nutzerinteraktion, Operationsaufruf, zeitliches Ereignis
Zustandsübergang modelliert Ausführen einer Aktivität
Zwei Typen von Zustandsdiagrammen:
 Verhaltenszustandsautomat
 Protokollzustandsautomat
© Dr.-Ing. Dirk Habich |
|
27
>
Verhaltenszustandsautomat
Modellierung des Verhaltens von
Modellelementen (z.B. Klassen)
Ausführen von Aktivitäten in einem
Zustand
 Entry – beim Eintritt in den Zustand
 Exit – beim Verlassen des Zustands
 Do – über die gesamte Dauer des
Zustands
© Dr.-Ing. Dirk Habich |
|
28
>
Protokollzustandsautomat
Beschreibt in welchem Zustand und
bei welchen Bedingungen welche
Operationen aufgerufen werden
können
Kann Lebenszyklus von Objekten
beschreiben
Definition von Vor- und
Nachbedingungen für Operationen
Entry, do und exit Aktivitäten nicht
erlaubt
© Dr.-Ing. Dirk Habich |
|
29
> Zusammenfassung
Objektorientierte Analyse - Modellierung dynamischer Konzepte:
Anwendungsfälle beschreiben Interaktionen von Akteuren mit System,
abstrakte Sicht auf System
Aktivitätsdiagramme beschreiben Folge von Funktionalitäten bzw. Verhalten
zur Umsetzung der Anwendungsfälle
Szenarien beschreiben möglichen Ablauf von Anwendungsfällen
Kollektion von Szenarien beschreibt Varianten der Ausführung von
Verarbeitungsschritten eines Anwendungsfalls
 Sequenzdiagramme, Kommunikationsdiagramme
Zustandsdiagramme beschreiben Verhalten von Modellelementen bzw.
Lebenszyklus von Klassen
© Dr.-Ing. Dirk Habich |
|
30
>
Objektorientierte Softwareentwicklung
am Beispiel
am Fallbeispiel Autovermietung
© Dr.-Ing. Dirk Habich |
|
31
> Die zentrale Frage der
Softwaretechnologie
Wie kommen wir vom Problem des Kunden zum Programm?
Von der
Beschreibung der
Welt des Kunden
(Domänenmodell,
Weltmodell)
© Dr.-Ing. Dirk Habich |
Zum Programm
(oder Produkt)
|
32
> Objektorientierte Analyse und Entwurf
Analyse
AnforderungsSpezifikation
(Pflichtenheft)
AnforderungsErmittlung
Produktdefinition
(OOA-Model)
SystemModellierung
ArchitekturSpezifikation
ArchitekturEntwurf
Entwurf
DetailEntwurf
Klassen- bzw. ModulSpezifikationen
© Dr.-Ing. Dirk Habich |
|
33
> Inhalte einer
Anforderungsspezifikation
Analyse
AnforderungsErmittlung
AnforderungsSpezifikation
(Pflichtenheft)
Pflichtenheft
 Beschreibt das Was, Nicht das Wie.
 Wird von der Analyse bis zu Test und Wartung verwendet von verschiedenen Personen
verwendet
Aufbau
 Begriffe, allgemeine Zielstellung und Rahmenbedingungen
 Beschränkungen
 Spezifische Anforderungen
 Funktionale Anforderungen (Was soll das System können?)
 nicht-funktionale Anforderungen (Mit welcher Qualität?)
Hauptproblem dabei: Anforderungen finden / erkennen / aufdecken
© Dr.-Ing. Dirk Habich |
|
34
> Beispiel Pflichtenheft
1.
Zielbestimmung
Muss-Kriterien





Reservierung von Autos per Telefon, E-Mail und vor Ort
Änderung von Reservierungen
Abholen und Zurückgeben von Autos durch Kunden
Abwicklung der Bezahlung bei Abholung
…
Kann-Kriterien
 Verwaltung von Kunden in einem Kundenklubprogramm
2. Einsatz
Anwendungsbereich
 Funktionen zum Vermieten von Fahrzeugen an Kunden in allen Filialen des Autovermieters
sowie in Call-Centern
Zielgruppe
 Kunden, Filialmitarbeiter, Call-Center-Mitarbeiter
© Dr.-Ing. Dirk Habich |
|
35
> Beispiel Pflichtenheft (Fortsetzung)
3. Umgebung
 Software: Microsoft Windows XP, Windows 7, Mac OS X Lion
 Hardware: Beliebige Windows- sowie Apple-Rechner, iPad3
4. Funktionalität (funktionale Anforderungen)




/F01/ Reservieren eines Autos mit bestimmter Fahrzeugklasse
/F02/ Änderung einer Reservierung
/F03/ Erstellung eines Ausleihvertrags
….
5. Daten:
 Verwaltung der Daten zur Fahrzeugflotte, zu Kunden und Reservierungen
6. Qualitätsziele (nicht-funktionale Eigenschaften)
 Hohe Benutzerfreundlichkeit
 Einfache Erweiterbarkeit
 Skalierbarkeit
© Dr.-Ing. Dirk Habich |
|
36
> Systemmodellierung
Ausgangspunkt sind meist “user stories” in Form von Interviews,
Tonbandmitschnitte, Protokolle, Gesprächen
Identifikation und Gruppierung von Aktivitäten
In der Regel werden mehrere Anwendungsfalldiagramme benötigt
Reservierung
von Autos
Ausleihe und
Rückgabe von
Autos
KundenclubProgramm
© Dr.-Ing. Dirk Habich |
|
37
> Akteure
Akteure stehen mit dem System in Bezug
Es erfolgt noch keine Festlegung von Systemfunktionen
Autovermietung
© Dr.-Ing. Dirk Habich |
|
38
> Fachliches Modell
Modelliert Organisationen, Dinge, Geschäftsvorgänge sowie die involvierten
Personen
Modellierung im Klassendiagramm
 Klassen , Assoziationen und Aggregationen finden
 Noch ohne Angaben zu Multiplizität und Attributen
© Dr.-Ing. Dirk Habich |
|
39
> Reservierungssystem
Identifikation neuer Elemente beim „Ausrollen“ des Systems
Auch in anderen Diagrammen umsetzen
Reservierungssystem
© Dr.-Ing. Dirk Habich |
|
40
> Szenarienanalyse mit
Sequenzdiagrammen
Hier nur positive Fälle
© Dr.-Ing. Dirk Habich |
|
41
> Ausleihsystem
Ausleihsystem
© Dr.-Ing. Dirk Habich |
|
42
> Szenarienanalyse - Aktivitätsdiagrammen
Use Case „Auto abholen“
Kunde
© Dr.-Ing. Dirk Habich |
Ausleihsystem
Reservierungssystem
Mechaniker
|
43
> Erweiterung des fachlichen Modells
Attribute finden
Operationen finden
© Dr.-Ing. Dirk Habich |
|
44
> Kundenprogramm
© Dr.-Ing. Dirk Habich |
|
45
> Szenarioanalyse mit
Zustandsautomaten
Kunde als Klubmitglied verwalten
© Dr.-Ing. Dirk Habich |
|
46
> Zusammenfassung Analyse
Szenarienanalyse hilft uns, aus
Anwendungsfalldiagrammen
Fachliche Modelle zu finden
Enge Verzahnung der Entwicklung
des statischen und dynamischen
Modells
Mehrere Iterationen von Use-Cases
zu fachlichem Modell
Implementierungsaspekte
ausklammern
 Annahme perfekter Technologie
 Funktionale Essenz des Systems
Use-Case-Modell erstellen
·
·
·
Aktivitätsgruppen identifizieren
Akteure identifizieren
Use-Cases modellieren
·
·
Use-Case-Diagramme
Verfeinerung durch Aktivitätsdiagramme, Sequenzdiagramme,
Kommunikationsdiagramme, Zustandsdiagramme
Statisches Modell
erstellen
·
·
·
·
·
© Dr.-Ing. Dirk Habich |
Dynamisches Modell
erstellen
Klassen identifizieren
Assoziationen,
Generalisierungen,
Aggregationen identifizieren
Attribute und Operationen
identifizieren
·
·
Textuelle Beschreibungen
Klassendiagramme,
Objektdiagramme
·
·
·
·
Szenarien erstellen
Zustandsdiagramme
erstellen
Operationen identifizieren
Operationen modellieren
Sequenzdiagramme,
Zustandsdiagramme
Aktivitätsdiagramme,
Klassendiagramme
|
47
> Entwurf
ArchitekturSpezifikation
ArchitekturEntwurf
Entwurf
DetailEntwurf
Klassen- bzw. ModulSpezifikationen
© Dr.-Ing. Dirk Habich |
|
48
> Typische Bestandteile eines
Softwaresystems
Anwendungsspezifische Funktionen
Kommunikationsdienste
Benutzungsoberfläche
Sicherheitsfunktionen
Ablaufsteuerung
Zuverlässigkeitsfunktionen
Datenhaltung
Systemadministration
Infrastrukturdienste
 Installation, Anpassung
 Systembeobachtung
 Objektverwaltung
 Interne Objekt- und
Prozesskommunikation
 Verteilungsunterstützung
Architektur
Anwendung
(spezifisch)
Technik
© Dr.-Ing. Dirk Habich |
|
49
> Aspekte des Architekturentwurfs
• (Grobe) Strukturelle Zerlegung:
F1
– Blockdiagramme
F2
F3
– Schichten, Sichten
• Physikalische Verteilung:
– Zentral oder verteilt?
f1
f2
– Topologie
f3a
f3b
Kommunikation zwischen den Teilkomponenten
Einhaltung nichtfunktionaler Anforderungen:
 Skalierbarkeit
 Ausfallsicherheit
© Dr.-Ing. Dirk Habich |
|
50
> Strukturelle Zerlegung:
Blockdiagramme
Blockdiagramme sind das meistverbreitete Hilfsmittel zum Skizzieren der
logischen Struktur einer Systemarchitektur.
(informelle) Blockdiagramme sind kein Bestandteil von UML
Umfassendes
Subsystem
Ausleihsystem
Schnittstelle
Reservierungssystem
© Dr.-Ing. Dirk Habich |
Kundenklubprogramm
• Subsystem umfasst Objekte
bestimmter Klassen
• Schnittstelle ist klar
definiert
(Aufrufschnittstelle,
Kommunikationsprotokoll)
Subsystem
|
51
> Verteilung: Drei-Schichten-Architektur
• Klassische Struktur eines interaktiven Anwendungssystems
• Schichten sind in sich abgeschlossen und lose gekoppelt
 Erlaubt Änderungen der Schichten ohne Wirkung auf andere Schichten
Benutzungsschnittstelle
Basiert
auf
Analysemodell
Fachlicher
Kern
Datenverwaltung
© Dr.-Ing. Dirk Habich |
<<boundary>>
<<control>>
<<data>>
|
52
> Schichtenstruktur Autovermietung
© Dr.-Ing. Dirk Habich |
|
53
> Konfigurationsdiagramme
Konfigurationsdiagramme sind nicht Bestandteil von UML
Konfigurationsdiagramme sind das meistverbreitete Hilfsmittel zur
Beschreibung der physikalischen Verteilung von Systemkomponenten.
Lokales
Kommunikationsnetz
Speicherndes
System
Filiale B
Desktop-Rechner
Filiale A
Server
Reservierungs-/
Ausleihsystem
iPad
CallCenter
© Dr.-Ing. Dirk Habich |
DatenkommunikationsNetz
Kundenklubprogramm
Rechner, Knoten
|
54
> UML zum logischen Detailentwurf
Analyse-Modell
Entwurfs-Modell
Notation: UML
Notation: UML
Objekte: Fachgegenstände
Objekte: Softwareeinheiten
Klassen: Fachbegriffe
Klassen: Schemata
Vererbung: Begriffsstruktur
Vererbung: Programmableitung
Annahme perfekter
Technologie
Erfüllung konkreter
Rahmenbedingungen
Funktionale Essenz
Gesamtstruktur des Systems
Völlig projektspezifisch
Ähnlichkeiten zwischen
verwandten Projekten
Grobe Strukturskizze
Genaue Strukturdefinition
Schrittweise Verfeinerung
Mehr Struktur & mehr Details
© Dr.-Ing. Dirk Habich |
|
55
> Zusammenfassung
Methodisches Vorgehen ist essentiell zur Entwicklung großer Softwaresysteme
Modellierung mit UML erlaubt abstraktere Sicht auf Softwaresystem
 Verschiedene Diagrammtypen zur Modellierung von Struktur und Verhalten
 Kein Softwareprozess implizit verankert

Methodische Vorgehensweise
 Legt Regeln für Verwendung von UML Elementen fest
 Analyse aufbauend auf Pflichtenheft
 Use-Cases
 fachliches Modell
 noch viele Details ausgeklammert
 Entwurf aufbauend auf fachlichem Modell der Analyse
 Architekturentwurf
 Detailentwurf
© Dr.-Ing. Dirk Habich |
|
56
Document
Kategorie
Kunst und Fotos
Seitenansichten
11
Dateigröße
1 909 KB
Tags
1/--Seiten
melden