Folien zum Buch in Powerpoint für die dritte Auflage

Grundkurs Software-Engineering
mit UML
Konzepte für die erfolgreiche SoftwareEntwicklung
Prof. Dr. Stephan Kleuker
• Bitte beachten Sie die Rechte des Verlages SpringerTeubner an
der Buchinhalten und Bildern
• Diese Folien sind als Begleitfolien für das Buch konzipiert
Grundkurs Software-Engineering mit UML
Stephan Kleuker
1
Inhaltsverzeichnis
1 Was ist Software-Engineering?
2 Prozessmodellierung
3 Vorgehensmodelle
4 Anforderungsanalyse
5 Grobdesign
6 Vom Klassendiagramm zum Programm
7 Konkretisierungen im Feindesign
8 Optimierung des Designmodells
9 Implementierungsaspekte
10 Oberflächengestaltung
11 Qualitätssicherung
12 Umfeld der Software-Entwicklung
Hinweis: grüne Kästchen verlinken auf das genannte Kapitel
Grundkurs Software-Engineering mit UML
Stephan Kleuker
2
1. Motivation von SoftwareEngineering
Grundkurs Software-Engineering mit UML
Stephan Kleuker
3
Historie des SW-Engineering (1/4)
•
•
Ende 60er
– Bedarf für Softwaretechnik neben der reinen
Programmierung erstmals voll erkannt
– Vorher sind zahlreiche große Programmentwicklungen
(möglich durch verbesserte Hardwareeigenschaften)
gescheitert
– Arbeiten von Dijkstra 1968 (u.a. gegen Verwendung von
GOTO) und Royce 1970 (Software-Lebenszyklus),
• Top-Down-Entwurf, graphische Veranschaulichungen
(Nassi-Shneiderman Diagramme)
Mitte 70er
– Top-Down-Entwurf für große Programme nicht
ausreichend, zusätzlich Modularisierung erforderlich
– Entwicklung der Begriffe Abstrakter Datentyp,
Datenkapselung und Information Hiding
Grundkurs Software-Engineering mit UML
Stephan Kleuker
4
Historie des SW-Engineering (2/4)
•
•
•
Ende 70er
– Bedarf für präzise Definition der Anforderungen an ein
Softwaresystem, Entstehen von Vorgehensmodellen, z. B.
Structured Analysis Design Technique (SADT)
80er Jahre
– Vom Compiler zur Entwicklungsumgebung (Editor,
Compiler, Linker, symbolischer Debugger, Source Code
Control Systems)
– Weiterentwicklung der Modularisierung und der
Datenkapselung zur objektorientierten Programmierung
90er Jahre
– Objektorientierte Programmierung nimmt zu (wieder
ausgehend von der Implementierung)
– Neue Programmiersprache Java (ab Mitte 80er C++)
– Anwendungs-Rahmenwerke (Application Frameworks) zur
Vereinfachung von Design und – vor allem –
Programmierung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
5
Historie des SW-Engineering (3/4)
•
•
•
•
90er Jahre
– Geeignete Analyse- und Entwurfsmethoden entstehen
(Coad/Yourdon, Rumbaugh, Booch, Jacobson und andere)
1995
– Vereinigung mehrerer Ansätze zunächst als Unified Method
(UM) von Booch und Rumbaugh, dann kommt Jacobson
hinzu (Use Cases).
– 3 Amigos definieren die Unified Modeling Language (UML)
als Quasi-Standard.
1997
– UML in der Version 1.1 bei der OMG (Object Management
Group) zur Standardisierung eingereicht und angenommen
– UML ist jedoch keine Entwicklungsmethode
(Phasenmodell), nur eine Beschreibungssprache
1999
– Entwicklungsmethode: Unified Process (UP) und Rational
Unified Process (RUP) (erste Version)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
6
Historie des SW-Engineering (4/4)
• Heute
– Vorgehensweisen auf individuelle
Projektanforderungen abgestimmt
– CASE-Methoden und –Tools orientieren sich an
der UML
– Aktueller Stand 2013: UML 2.4.1
(http://www.uml.org/)
– Aufbauend auf Analyse und Design erzeugen
Codegeneratoren Programmgerüste
– Haupttätigkeiten bei Softwareentwicklung sind
Analyse und Design, vieles andere versucht man
zu automatisieren (!?)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
7
Warum scheitern SW-Projekte (kleine Auswahl)
• Die Software wurde wesentlich zu spät geliefert
• Die Software erfüllt nicht die Wünsche des Kunden
• Die Software läuft nicht auf den vereinbarten
Rechnersystemen, sie ist zu langsam oder kommt
mit dem Speicher nicht aus
• Die Software kann nicht erweitert werden oder mit
anderer Software zusammenarbeiten
• …
Grundkurs Software-Engineering mit UML
Stephan Kleuker
8
Antworten des Software-Engineering
• 1967: Prägung des Begriffs Software-Krise
• Lösungsansätze:
– Programmiersprachen: kontinuierliche Einführung
von Abstraktion (Datentypen, Funktionen,
Modulen, Klassen, Bibliotheken, Frameworks)
– Dokumentation: Einheitliche Notationen für
Entwicklungsergebnisse (UML)
– Entwicklungsprozesse: Aufgabenbeschreibungen,
wann was wie gemacht wird
– Vorgehensmodelle: Entwicklung passt sich an
Bedürfnisse des Kunden an
Grundkurs Software-Engineering mit UML
Stephan Kleuker
9
Definitionsversuch Software-Engineering
Zusammenfassend kann man Software-Engineering
als die Wissenschaft der systematischen
Entwicklung von Software, beginnend bei den
Anforderungen bis zur Abnahme des fertigen
Produkts und der anschließenden Wartungsphase
definieren. Es werden etablierte Lösungsansätze für
Teilaufgaben vorgeschlagen, die häufig kombiniert
mit neuen Technologien, vor Ihrer Umsetzung auf
ihre Anwendbarkeit geprüft werden. Das zentrale
Mittel zur Dokumentation von Software-EngineeringErgebnissen sind UML-Diagramme.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
10
2. Prozessmodellierung
2.1 Unternehmensprozesse
2.2 Prozessmodellierung mit Aktivitätsdiagrammen
2.3 Risikomanagement
Grundkurs Software-Engineering mit UML
Stephan Kleuker
11
Umfeld von SW-Projekten
2.1
Unternehmensführung
Unterstützung
Vertrieb
Projektmanagement
Controlling
SW-Projekt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
12
Prozesse in Unternehmen aus SW-Projektsicht
(Annahme SW ist wichtiges Kernprodukt)
• Unternehmensführung gibt Geschäftsfelder und
Strategien vor
• Vertriebsleute müssen Kunden finden, überzeugen
und Aufträge generieren
• Aufträge führen zu Verträgen, die geprüft werden
müssen
• Das Personal für Aufträge muss ausgewählt werden
und zur Verfügung stehen
• Der Projektablauf muss beobachtet werden,
Abweichungen z. B. in Zeitplan müssen zu
Steuerungsmaßnahmen führen
• Die SW muss realisiert werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
13
Rollenbegriff
• Unterschiedliche Menschen arbeiten in
verschiedenen Rollen zusammen
• Rolle: genaue Aufgabenbeschreibung, mit
Verantwortlichkeiten (was soll gemacht werden) und
Kompetenzen (welche Entscheidungen können
getroffen werden, z. B. „Arbeit anweisen“)
• Mensch kann in einem Unternehmen/Projekt
mehrere Rollen haben
• Eine Rolle kann von mehreren Menschen besetzt
werden
• Beispielrollen: Vertriebsleiter, Vertriebsmitarbeiter,
Projektleiter, Analytiker, Implementierer, Tester
Grundkurs Software-Engineering mit UML
Stephan Kleuker
14
Prozessbegriff
Prozessbeschreibungen regeln die Zusammenarbeit
verschiedene Menschen (genauer Rollen),
• Was soll in diesem Schritt getan werden?
• Wer ist verantwortlich für die Durchführung des Schritts?
• Wer arbeitet in welcher Rolle in diesem Schritt mit?
• Welche Voraussetzungen müssen erfüllt sein, damit der Schritt
ausgeführt werden kann?
• Welche Teilschritte werden unter welchen Randbedingungen
durchgeführt?
• Welche Ergebnisse kann der Schritt abhängig von welchen
Bedingungen produzieren?
• Welche Hilfsmittel werden in dem Prozessschritt benötigt?
• Welche Randbedingungen müssen berücksichtigt werden?
• Wo wird der Schritt ausgeführt?
Prozesse sind zu dokumentieren und zu pflegen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
15
Prozessmodellierung mit Aktivitätsdiagrammen
2.2
Zur Beschreibung werden folgende elementare Elemente genutzt:
genau ein Startpunkt
einzelner Prozessschritt (Aktion)
Kontrollknoten (Entscheidung)
Kontrollknoten (Zusammenführung)
Endpunkt (Terminierung)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
16
Parallelität in Prozessen
• Waagerechter oder senkrechter
Strich steht für mögliche
Prozessteilung (ein Pfeil rein,
mehrere raus) oder
Zusammenführung (mehrere
Pfeile rein, ein Pfeil raus)
• Am zusammenführenden Strich
steht Vereinigungsbedingung,
z. B.
– {und}: alle Aktionen
abgeschlossen
– {oder}: (mindestens) eine
Aktion abgeschlossen
• UML 1.1 hatte andere
Restriktionen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
17
Beteiligte, Produkte, Werkzeuge
• Beteiligte, Produkte,
Werkzeuge werden hier als
einfache Datenobjekte
modelliert, dabei steht
zunächst die Objektart und
dann die genaue
Bezeichnung
• In eckigen Klammern kann
der Zustand eines Objekts
beschrieben werden
• neben „Verantwortlicher“
noch „Mitwirkender“
möglich
• auch Entscheidungen
können Verantwortliche
haben
Grundkurs Software-Engineering mit UML
Stephan Kleuker
18
Anmerkungen
• Lesbarkeit leidet unter
Beteiligte, Produkte,
Werkzeuge, da zentraler
Ablauf versteckt
• immer erst ohne
"Kästen" modellieren
• häufig alternative
Darstellungen für Rollen
und Werkzeuge
• Variante: nur Ablauf,
Rest in
Textdokumentation
Grundkurs Software-Engineering mit UML
Stephan Kleuker
19
Beispiel: Vertrieb (1/4)
• Zu modellieren ist der Vertriebsprozess eines Unternehmens,
das SW verkauft, die individuell für den Kunden angepasst und
erweitert werden kann
• Modelle werden wie SW inkrementell erstellt; zunächst der
(bzw. ein) typische Ablauf, der dann ergänzt wird
• Typisches Szenario: Vertriebsmitarbeiter kontaktiert Kunden
und arbeitet individuelle Wünsche heraus; Fachabteilung
erstellt Kostenvoranschlag; Kunde unterschreibt Vertrag;
Projekt geht in den Prozess Projektdurchführung (hier nicht
modelliert)
• Beteiligt: Vertriebsmitarbeiter, Kunde, Fachabteilung
• Produkt: Individualwünsche, Kostenvoranschlag, Vertrag
• Aktionen: Kundengespräch, Kosten kalkulieren,
Vertragsverhandlung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
20
Beispiel: Vertrieb (2/4)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
21
Beispiel: Vertrieb (3/4)
nächster Schritt: Einbau alternativer Abläufe
• Kunde ist am Angebot nicht interessiert
• In den Vertragsverhandlungen werden neue
Rahmenbedingungen formuliert, so dass eine
Nachkalkulation notwendig wird [nächste Folie]
• Bis zu einem Vertragsvolumen von 20 T€
entscheidet der Abteilungsleiter, darüber die
Geschäftsleitung ob vorliegender Vertrag
abgeschlossen werden soll oder
Nachverhandlungen nötig sind
• Die Fachabteilung hat Nachfragen, die der
Vertriebsmitarbeiter mit dem Kunden klären muss
Grundkurs Software-Engineering mit UML
Stephan Kleuker
22
Beispiel: Vertrieb (4/4)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
23
Modellierungsfalle
• Basierend auf Erfahrungen mit Flussdiagrammen könnte man
zu folgender Modellierung kommen
• Dies würde nach UML-Semantik bedeuten, dass für die Aktion
Vertragsverhandlung zwei Kostenvorschläge (initial und
aktualisiert) vorliegen müssten
• Wenn verschiedenen Wege zu einer Aktion führen sollen, muss
vor der Aktion ein Zusammenführungs-Kontrollknoten stehen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
24
Problem Lesbarkeit
• Diagramme können leicht komplex werden
Lösungsmöglichkeiten:
• Verteilung von Diagrammen auf mehrere Seiten mit
Ankerpunkten
• Verzicht, alle Elemente in einem Diagramm
darzustellen (z. B. Produkte weglassen; dies nur in
der immer zu ergänzenden Dokumentation
erwähnen)
• Diagramme hierarchisch gestalten; eine Aktion kann
durch ein gesamtes Aktivitätsdiagramm verfeinert
werden, z. B. ist „Kosten kalkulieren“ eigener
Prozess; dies sollte im Modell sichtbar werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
25
Prozessverfeinerung: Kosten kalkulieren
Anmerkung: Verantwortliche
weggelassen, da immer „Projektbegleiter der Fachabteilung“
Grundkurs Software-Engineering mit UML
Stephan Kleuker
26
Nutzung von Schwimmbahnen (für Rollen)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
27
Problem Abstraktionsgrad
• Frage: Wann nur eine Aktion, wann mehrere Aktionen
• Indikator: Mehrere Aktionen zusammenfassen, wenn
– nur ein Produkt entsteht, das ausschließlich in diesen
Aktionen benötigt wird („lokale Variable“)
– oder diese von nur einer Person bearbeitet werden
• Typischerweise Prozesshierarchie:
– Unternehmensebene; d.h. ein Diagramm für jeden Prozess
der Kern-, Management- und Supportprozesse
– Prozessebene: Verfeinerung des Prozesses, so dass alle
auch nur intern sichtbaren Rollen und Produkte sichtbar
werden
– Arbeitsprozess: Individuelle Beschreibung der
Arbeitsschritte einer Rolle für eine/ mehrere Aktionen
• Probleme: Flexibilität und Akzeptanz
Grundkurs Software-Engineering mit UML
Stephan Kleuker
28
Querschnittsprozess: Projekt-Risikomanagement
2.3
• Projekte stoßen häufig auf Probleme, die man frühzeitig hätte
erkennen und auf die man dann reagieren könnte; dieser Prozess
heißt (Projekt-) Risikomanagement (RM)
• Idee: frühzeitig über potenzielle Probleme nachdenken, genauer:
– Vermeidungsmöglichkeiten
– Maßnahmen zur Verringerung der Eintrittswahrscheinlichkeit
– Maßnahmen beim Eintreffen des Problems
• ersten beiden Ansätze heißen pro-aktives RM, letzter Ansatz
reaktives RM oder Notfall-Plan
DeMarco, T.; Lister, T.: Bärentango – Mit Risikomanagement Projekte zum Erfolg
führen, Hanser, München, 2003
Wallmüller, E.: Risikomanagement für IT- und Software-Projekte, Hanser, München,
2004
Gaulke, M.: Risikomanagement in IT-Projekten, Oldenbourg, München, 2004
Versteegen, G.: Risikomanagement in IT-Projekten, Springer, Berlin, 2003
Grundkurs Software-Engineering mit UML
Stephan Kleuker
29
Beispiel RM bei Projektplanung
• Risiko: Mangelnder Austausch von Know-How im Projektteam
• Auswirkungen: Arbeiten werden doppelt gemacht,
vorhandenes Wissen nicht eingesetzt
• Ursache: Neues Projektteam, dass noch nicht
zusammengearbeitet hat
• Maßnahme: (Verringerung) Erste Projektveranstaltung (Kickoff) findet in kleinem Hotel außerhalb des Unternehmens statt;
moderierte Workshops zum Aufbau des Verständnisses der
Projektaufgabe und zur Findung vorhandener Kompetenzen
• Messung des Maßnahmenerfolgs: Kontrolle auf
Doppelarbeiten; Verfolgung der Qualität der Ergebnisse, die
von mehreren Personen erstellt wurden (nur weiches Maß)
• Hinweis: Ursache und Risiko können verwischen, da Ursachen
wieder Ursachen haben können (... irgendjemand in den Apfel
gebissen hat  )
Grundkurs Software-Engineering mit UML
Stephan Kleuker
30
Risikomanagement
Risiken
identifizieren
Optimieren
Risiken
analysieren
Maßnahmen
planen
RisikoDatenbank
Maßnahmen
durchführen
Maßnahmen
bewerten
Grundkurs Software-Engineering mit UML
Stephan Kleuker
31
Phasen des Risikomanagements (1/3)
• Risiken identifizieren
– Identifikation eines Risikos, Festlegung der
Risikoaussage und des Risikokontextes
– Aufnahme in die Risikoliste
• Risiken analysieren
– Festlegung der Eintrittswahrscheinlichkeit, der
Auswirkungen, der erwarteten Tendenz und des
Ursachenfeldes
– Priorisierung der vorhandenen Risiken unter
Berücksichtigung der Gesamtrisikolage
Grundkurs Software-Engineering mit UML
Stephan Kleuker
32
Phasen des Risikomanagements (2/3)
• Maßnahmen planen
– Passende Maßnahmen definieren
– Festlegen der verantwortlichen Personen/Rollen
– Erfolgsfaktoren für Maßnahmen festlegen
• Maßnahmen durchführen
– Sammeln von Informationen/Daten zu den
Veränderungen der Risiken und dem Erfolg der
Maßnahmen
– Erstellen von Risikomeldungen für das
Management
Grundkurs Software-Engineering mit UML
Stephan Kleuker
33
Phasen des Risikomanagements (3/3)
• Maßnahmen bewerten
– Bewertung der Veränderung von Risiken und des
Erfolgs der angewendeten Maßnahmen
– Entscheidungsfindung zur weiteren Behandlung
der Risiken und Anpassung der Maßnahmen
– Informationsverteilung zu den Risiken in Richtung
Team und Vertragspartnern/Kunde
• Optimieren
– Maßnahmen zielgerichtet anpassen
– Hinweise/ Optimierungspotenziale für zukünftige
Projekte erkennen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
34
3. Vorgehensmodelle
3.1 Phasen der Software-Entwicklung
3.2 Wasserfallmodell
3.3 Prototypische Entwicklung
3.4 Iterative Entwicklung
3.5 Iterativ-inkrementelle Entwicklung
3.6 Allgemeines V-Modell
3.7 Das V-Modell der Bundesrepublik Deutschland
3.8 Rational Unified Process
3.9 Agile Vorgehensmodelle
3.10 Scrum
3.11 Extreme Programming
Grundkurs Software-Engineering mit UML
Stephan Kleuker
35
Herausforderungen der SW-Entwicklung
3.1
Software-Systeme sind heutzutage verteilte
Anwendungen
– Anschluss an existierende Software (z.B. SAP, MS
Office, bestehende Unternehmenssoftware...)
– Integration neuer Komponenten in existierende
Systeme
– Erweiterung existierender Systeme
eigene
Komponenten
neues System
?
?
?
Legacy Systeme
Grundkurs Software-Engineering mit UML
Systeme an
anderen Standorten
?
?
Systeme
anderer Anbieter
Stephan Kleuker
36
Die Phasen der SW- Entwicklung
• Erhebung und Festlegung des
Anforderungsanalyse
WAS mit Rahmenbedingungen
Grobdesign
Feindesign
Implementierung
Test und Integration
• Klärung der Funktionalität und
der Systemarchitektur durch
erste Modelle
• Detaillierte Ausarbeitung der
Komponenten, der Schnittstellen,
Datenstrukturen, des WIE
• Ausprogrammierung der
Programmiervorgaben in der
Zielsprache
• Zusammenbau der Komponenten,
Nachweis, dass Anforderungen
erfüllt werden, Auslieferung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
37
Wasserfallmodell
3.2
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
Grundkurs Software-Engineering mit UML
Merkmale:
Phasen werden von oben nach unten
durchlaufen
Vorteile:
- Plan auch für Nichtexperten verständlich
- einfache Meilensteinplanung
- lange Zeit am häufigsten eingesetzt
Nachteile:
- Anforderungen müssen 100%-ig sein
- späte Entwicklungsrisiken werden spät
erkannt
- Qualität des Design passt sich Zeitplan an
Optimierung:
es ist möglich, in die vorherige Phase zu
springen
Stephan Kleuker
38
Prototypische Entwicklung
3.3
Anforderungsanalyse
Anforderungsanalyse
Grobdesign
Grobdesign
Feindesign
Feindesign
Implementierung
Implementierung
Test und
Integration
Test und Integration
Prototyp
Grundkurs Software-Engineering mit UML
Merkmale:
- potenzielle Probleme frühzeitig
identifiziert,
- Lösungsmöglichkeiten im Prototypen
gefunden, daraus Vorgaben abgeleitet
Vorteile:
- frühzeitige Risikominimierung
- schnelles erstes Projektergebnis
Nachteile:
- Anforderungen müssen fast 100%-tig
sein
- Prototyp (illegal) in die Entwicklung
übernommen
- Kunde erwartet schnell Endergebnis
Optimierung:
es ist möglich, in die vorherige Phase
zu springen
Stephan Kleuker
39
Iterative Entwicklung
3.4
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
Merkmale:
- Erweiterung der Prototypidee; SW wird in
Iterationen entwickelt
- In jeder Iteration wird System weiter verfeinert
- In ersten Iterationen Schwerpunkt auf Analyse
und Machbarkeit; später auf Realisierung
große Vorteile:
- dynamische Reaktion auf Risiken
- Teilergebnisse mit Kunden diskutierbar
Nachteile im Detail:
- schwierige Projektplanung
- schwierige Vertragssituation
- Kunde erwartet zu schnell Endergebnis
- Kunde sieht Anforderungen als beliebig
änderbar
Grundkurs Software-Engineering mit UML
Stephan Kleuker
40
Iterativ Inkrementelle Entwicklung (State of the Art)
3.5
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
Bsp.: vier Inkremente
Grundkurs Software-Engineering mit UML
Merkmal:
- Projekt in kleine Teilschritte zerlegt
- pro Schritt neue Funktionalität
(Inkrement) + Überarbeitung
existierender Ergebnisse (Iteration)
- n+1-ter Schritt kann Probleme des nten Schritts lösen
Vorteile:
- siehe „iterativ“
- flexible Reaktion auf neue funktionale
Anforderungen
Nachteile:
- siehe „iterativ“ (etwas verstärkt)
Optimierung/Anpassung:
Anforderungsanalyse am Anfang
intensiver durchführen
Stephan Kleuker
41
Fertigstellung mit Iterationen
Iterationen
1.
2.
3.
4.
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
0%
Grundkurs Software-Engineering mit UML
Fertigstellungsgrad
Stephan Kleuker
100%
42
Bekanntheit von Vorgehensmodellen (1/2)
41
Wasserfallmodell
71
24
V-Modell
63
19
Spiralmodell
52
26
Inkrementelle Entwicklung
45
17
Evolutionäres Prototyping
Extreme Programming
RUP (Rational Unified Process)
keines dieser Modelle
41
4
39
15
32
20
11
genutzte Modelle
bekannte Modelle
Quelle: Softwareentwicklung läuft nicht auf Zuruf, Computer Zeitung Nr. 46/05
Grundkurs Software-Engineering mit UML
Stephan Kleuker
43
Bekanntheit von Vorgehensmodellen (2/2)
Wasserfallmodell
5,4
V-Modell
RUP
phasenorientiert 54
19,7
2,3
anderes explizites Modell
14,3
individuelles Modell
12,4
Scrum
agil
33
Extreme Programming
anderes explizites Modell
individuelles Modell
keines
13
Grundkurs Software-Engineering mit UML
18,8
1,3
4,0
8,9
13
Stephan Kleuker
44
Struktur komplexer Vorgehensmodelle
3.6
• Aktuelle Vorgehensmodelle, wie
V-Modell XT des Bundes
(Rational) Unified Process
OEP (Object Engineering Process)
enthalten Aktivitäten (was soll gemacht werden), Rollen (wer ist
wie an Aktivität beteiligt) und Produkte (was wird benötigt; bzw.
ist Ergebnis)
• es gibt Vorschläge für typische Anwendungsszenarien, wie
Aktivitäten zu verknüpfen sind
• Rahmenwerke, am Anfang eines Projekts muss
(werkzeuggestützt) bestimmen, welche Aktivitäten, Rollen,
Produkte und Reihenfolgen von Aktivitäten für das individuelle
Projekt relevant sind (tailoring, d. h. „zurecht schneidern“,
benötigt viel Erfahrung)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
45
allgemeines V-Modell
Validierung
Anforderungsdefinition
manuelle
Prüfung
Validierung
Funktionaler
Systementwurf
manuelle
Prüfung
Validierung
Technischer
Systementwurf
manuelle
Prüfung
Konstruktion
KomponentenSpezifikation
manuelle
Prüfung
Abnahmetest
Systemtest
Integrationstest
Validierung Komponenten-
test
Programmierung
Integration
Anmerkung: wird iterativ / inkrementell
zum W-Modell
Grundkurs Software-Engineering mit UML
Stephan Kleuker
46
V-Modell des Bundes
3.7
• Regelung der Softwarebearbeitung (im Bereich der
Bundeswehr, des Bundes und der Länder)
• einheitliche und (vertraglich) verbindliche Vorgabe von
– Aktivitäten und
– Produkten (Ergebnissen),
• Historie: V-Modell 92 (Wasserfall im Mittelpunkt), Überarbeitung
V-Modell 97 (Anpassung an inkrementelle Ideen (W-Modell);
Forderung nach zu früher Festlegung von Anforderungen)
• aktuell: V-Modell XT (eXtreme Tailoring), neuer Erstellung mit
Fokus auf Verhältnis von Auftragnehmer und Auftraggeber
(starker akademischer Einfluss bei Entwicklung)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
47
Struktur des V-Modell XT
http://www.v-modell-xt.de
für V-Modell XT-Informationen:
Copyright Reserved © Bundesrepublik Deutschland 2004.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
48
Produktorientierung im V-Modell XT
• Eine Projektdurchführungsstrategie definiert die Reihenfolge
der im Projekt zu erreichenden Projektfortschrittsstufen; nutzt
Entscheidungspunkte (go, no go)
• Produkte stehen im Mittelpunkt, sie sind DIE Projektergebnisse
• Projektdurchführungsstrategien und Entscheidungspunkte
geben die Reihenfolge der Produktfertigstellung und somit die
grundlegende Struktur des Projektverlaufs vor
• Die detaillierte Projektplanung und -steuerung wird auf der
Basis der Bearbeitung und Fertigstellung von Produkten
durchgeführt
• Für jedes Produkt ist eindeutig eine Rolle verantwortlich und im
Projekt dann eine der Rolle zugeordnete Person
• Die Produktqualität ist überprüfbar durch definierte
Anforderungen an das Produkt und explizite Beschreibungen
der Abhängigkeiten zu anderen Produkten
Grundkurs Software-Engineering mit UML
Stephan Kleuker
49
Entscheidungspunkte des V-Modells XT
relevant für alle V-Modell-Projekte
Schnittstelle Auftraggeber / Auftragnehmer
Organisationsspezifisches V-Modell
Systementwicklung
Projekt
genehmigt
Vorgehensmodell
analysiert
Verbesserung
Vorgehensmodell
konzipiert
Verbesserung
Vorgehensmodell
realisiert
Projekt
definiert
Anforderungen
festgelegt
Geamtprojekt
aufgeteilt
Projekt
ausgeschrieben
Gesamtfortschritt überprüft
Projektfortschritt überprüft
Projekt
beauftragt
Iteration
geplant
System spezifiziert
Abnahme
erfolgt
Projekt
abgeschlossen
Lieferung durchgeführt
System entworfen
System integriert
Feinentwurf abgeschlossen
Grundkurs Software-Engineering mit UML
Angebot
abgegeben
Systemelemente realisiert
Stephan Kleuker
50
Beispiel: Projektdurchführungsplan
(Systementwicklungsprojekt eines Auftraggebers (AG))
Grundkurs Software-Engineering mit UML
Stephan Kleuker
51
Beispielaktivität: Anforderungen festlegen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
52
Rational Unified Process (RUP)
3.8
Phasen
Disziplinen
Konzeption
Konstruktion
Ausarbeitung
Inbetriebnahme
Geschäftsprozessmodell
Anforderungsanalyse
Design
Implementierung
Test
Installation
Konfigurations- und
Änderungsmanagement
Projektmanagement
Projektumfeld
Start
aus IBM/Rational:
Rational Unified Process
Konzeption
Iteration 1
Grundkurs Software-Engineering mit UML
Konzeption Ausarbeitung Ausarbeitung Ausarbeitung Inbetrieb
Iteration 2 Iteration 1
Iteration 2
Iteration n
Iteration 1
Inbetrieb
Iteration 2
Iterationen
Stephan Kleuker
53
Phasen des RUP
• inception (Konzeption): Ermittlung zentraler
Anforderungen, Projektumfang definieren, erste
Entwurfs- und Implementierungsansätze,
Identifikation der Projektrisiken und Aufwände
• elaboration (Ausarbeitung): stabile, möglichst
vollständige Anforderungen, Entwurfsspezifikation,
detaillierter Projektplan mit aktivem
Risikomanagement
• construction (Konstruktion): Implementierung,
Integration, auslieferbare Version
• transition (Inbetriebnahme): Beta-Test, Endabnahme,
Inbetriebnahme, Endlieferung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
54
Struktur des RUP
Software
Engineering
Process
bearbeitet
Rolle
strukturiert
durch
Disziplin
beschrieben
in
Arbeitsablauf
Aktivität
Ergebnis
Eingabe
verantwortlich für
Hilfsmittel
verfeinert
durch
erstellt mit Hilfe
von
Hilfsmittel
Checkliste
Arbeitsablaufdetails
Produkt
(Artifact)
Strukturbeschreibung
(Template)
Werkzeuganleitung
Hilfsmittel
Bericht
beschrieben durch
Grundkurs Software-Engineering mit UML
Stephan Kleuker
55
Kritik an klassischen Vorgehensmodellen
3.9
• Es müssen viele Dokumente erzeugt und gepflegt
werden
• Eigene Wissenschaft Modelle wie V-Modelle und
RUP zu verstehen und zurecht zu schneidern
• Prozessbeschreibungen hemmen Kreativität
• Anpassung an neue Randbedingungen, z. B. neue
Technologien (Web-Services) in Prozessen und
benutzten Werkzeugen ist extrem aufwändig
• alternativer Ansatz: „Menschen machen Projekte
erfolgreich, traue den Menschen“
=>
agile Prozesse (vorherige Name:
leichtgewichtige Prozesse)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
56
Arten von agilen Prozessen (1/2)
• generell: Methoden lernen von einander; es gibt
nicht die eine agile Methode
• Variante 1: Beschreibung auf Metaprozessebene
– Grundregeln zur Projektorganisation
– Vorgehensweisen in Projekten werden vom Team
festgelegt
– Beispiele:
• Scrum (u. a. Ken Schwaber, Jeff Sutherland) [s.
Folien]
• Crystal Methodenfamilie (Alistair Cockburn)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
57
Arten von agilen Prozessen (2/2)
• Variante 2: Konkrete Prozessbeschreibungen
– Für verschiedene Phasen der SoftwareEntwicklung werden konkrete Verfahren
vorgeschlagen
– Abhängigkeiten der Verfahren werden
dokumentiert („wer A macht muss auch B
machen“); Möglichkeiten zur individuellen
Optimierung
– Beispiele:
• eXtreme Programming (XP) (u. a. Kent Beck,
Ward Cunningham) [s. Folien]
• Dynamic Systems Development Method
(Konsortium)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
58
Agiles Manifest (Februar 2001)
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin
Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
www.agileAlliance.org
Grundkurs Software-Engineering mit UML
Stephan Kleuker
59
Scrum (1/2)
3.10
• („Scrum“: Gedränge beim Rugby)
• Scrum Teams mit maximal 7 Personen mit unterschiedlichen
Fähigkeiten, Koordinator (Scrum Master),
Anforderungsdefinerer (Product Owner), Entwickler-Team
• Bei größeren Teams: mehrere Teilteams durch Scrum Master
koordiniert
• Zentrales Steuerungselement: Scrum meetings; jeden Tag 15
Minuten:
– was habe ich seit letztem Meeting gemacht?
– was werde ich bis zum nächsten Meeting machen?
– was hat meine Arbeit behindert?
• Scrum Master ist Koordinator; beseitigt Behinderungen;
kommuniziert im Unternehmen
• Arbeitsablauf im Team wird vom Team selbst geregelt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
60
Scrum (2/2)
• Projektplanung: Eng mit dem Kunden werden Hauptaufgaben
identifiziert (Stack mit product backlog)
• Product Owner nimmt Rolle des Kunden ein (kommt von
Kunden, oder erfahren im Anwendungsgebiet)
• Hauptaufgaben können auch Test von Technologien und die
Entwicklung von Prototypen sein
• Scrum Team schätzt Aufwände; wählt mit Kunden aus product
backlog wichtigste nächste Aufgaben für nächste Iteration
(heißt sprint) aus (in sprint backlog)
• Jeder sprint dauert ca. 5-30 Tage; sprint backlog mit
priorisierten Aufgaben; sorgt für nicht unterbrochene
Arbeitsphase des Teams (Scrum Master kann abbrechen)
• Nach jedem sprint Analyse mit dem Kunden, was wurde
erreicht; wie kann Projekt verbessert werden [zurück Planung]
• siehe auch: www.controlchaos.com
Grundkurs Software-Engineering mit UML
Stephan Kleuker
61
Scrum - Überblick
Product
backlog
sprint
backlog
Aufgabe 1
Teilaufgabe 1
Aufgabe 2
Teilaufgabe 2
...
...
Planung
für sprint
Arbeitstag
Scrum-Meeting
Sprint Review
Sprint Retrospective
Grundkurs Software-Engineering mit UML
sprint
21 Arbeitstage
Stephan Kleuker
62
Ideen des Extreme Programming (XP) (1/3)
3.11
•
•
•
•
•
•
•
•
•
Planning
User stories are written
Release planning creates
the schedule
Make frequent small
releases
The Project Velocity is
measured
The project is divided into
iterations
Iteration planning starts
each iteration
Move people around
A stand-up meeting starts
each day
Fix XP when it breaks
Grundkurs Software-Engineering mit UML
•
•
•
•
•
•
Designing
Simplicity
Choose a system metaphor
Use CRC cards for design
sessions
Create spike solutions to
reduce risk
No functionality is added
early
Refactor whenever and
wherever possible
Stephan Kleuker
63
Ideen des Extreme Programming (XP) (2/3)
•
•
•
•
•
•
•
•
•
Coding
The customer is always
available
Code must be written to
agreed standards
Code the unit test first
All production code is pair
programmed
Only one pair integrates
code at a time
Integrate often
Use collective code
ownership
Leave optimization till last
No overtime
Grundkurs Software-Engineering mit UML
•
•
•
•
Testing
All code must have unit
tests
All code must pass all unit
tests before it can be
released
When a bug is found tests
are created
Acceptance tests are run
often and the score is
published
Stephan Kleuker
64
Ideen des Extreme Programming (XP) (3/3)
Testfälle
neue User-Story
geänderte
Randbedingung
User
Stories
Anforderungen
Systemidee
Architekturansatz
Fehler
Release- ReleaseIteration
plan
Planung
unklare
Annahmen
abgesicherte
Annahmen
aktuelle
Version
nächste
Iteration
Miniprototyp
(Spike)
Akzeptanz
-tests
Kundenzustimmung
kleine
Releases
• Quelle der XP-Folien : www.extremeprogramming.org
• Varianten: z. B. in der Nutzung von Dokumentation (keine –
minimal)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
65
Versuch einer Beurteilung von agilen Methoden
• agile Methoden haben viele Innovationen in verstaubte SWEntwicklungsprozesse gebracht (etwas Neues; viel neu
arrangiertes)
• Einsetzbarkeit hängt stark von technischen und menschlichen
Fähigkeiten des Teams ab
• große Erfolge möglich, wenn Dream-Team gefunden
• Aufpassen bei Beratungs-Hype („XP ist die Zukunft“)
Hamburger Berater: Wir haben agile Methoden erfolgreich in
Versicherung X eingeführt und manifestiert
Projektleiter bei X: Haben neue Ideen zur Optimierung unseres
existierenden Prozesses genutzt; konkret übrig geblieben sind
Stand-Up-Meetings
• Agiles Manifest interessant für alle SW-Entwicklungsprozesse
• Ideen auf andere Ansätze übertragbar
• Überblick mit Kommentaren in Artikeln von J. Coldewey
http://www.coldewey.com/publikationen/Kolumne.html
Generell: Vorgehensmodell muss zum Projekt und den Menschen passen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
66
4. Anforderungsanalyse
4.1
4.2
4.3
4.4
4.5
4.6
Stakeholder und Ziele
Klärung der Hauptfunktionalität (Use Cases)
Beschreibung typischer und alternativer Abläufe
Ableitung funktionaler Anforderungen
Nicht-funktionale Anforderungen
Lasten- und Pflichtenheft
Literatur:
• [RS] C. Rupp, SOPHIST GROUP, Requirements- Engineering und –
Management, Hanser Fachbuchverlag
• [OW] B. Oestereich, C. Weiss, C. Schröder, T. Weilkiens, A. Lenhard,
Objektorientierte Geschäftsprozessmodellierung mit der UML,
dpunkt.Verlag
Grundkurs Software-Engineering mit UML
Stephan Kleuker
67
so nicht (1/4): Beispiel-Szenario
Zur Stundenerfassung und Abrechnung werden von
den Projektmitarbeitern spezielle Excel-Tabellen
jeden Freitag ausgefüllt und am Montag vom
Projektleiter bei der Verwaltung abgegeben.
Der zuständige Sachbearbeiter überträgt dann die für
den Projektüberblick relevanten Daten manuell in ein
SAP-System. Dieses System generiert automatisch
eine Übersicht, aus der die Geschäftsführung
ablesen kann, ob die Projekte wie gewünscht laufen.
Dieser Bericht liegt meist am Freitag der Woche vor.
Die Bearbeitungszeit ist der Geschäftsführung zu
lang, deshalb soll der Arbeitsschritt automatisiert
werden.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
68
so nicht (2/4): Die Projektplanung
• Es wird ein Projekt „Projektberichtsautomatisierung“
(ProAuto) beschlossen.
• Der Leiter der hausinternen IT-Abteilung wird über
die anstehende Aufgabe informiert. Er erhält eine
Beschreibung der Excel-Daten und der gewünschten
SAP-Daten.
• Der Leiter stellt fest, dass seine Abteilung das Knowhow und die Kapazität hat, das Projekt
durchzuführen und legt der Geschäftsführung einen
Projektplan mit einer Aufwandsschätzung vor.
• Die Geschäftsführung beschließt, das Projekt intern
durchführen zu lassen und kein externes Angebot
einzuholen.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
69
so nicht (3/4): Die Schritte zum Projektmisserfolg
• Die IT-Abteilung analysiert
die Excel-Daten und wie die
Daten in das SAP-System
eingefügt werden können.
• Kurz nach dem geschätzten
ProAuto
Projektende liegt eine
technisch saubere Lösung
vor. Excel wurde um einen
Knopf erweitert, so dass die
Projektleiter per Knopfdruck die Daten nach SAP überspielen
können.
• Vier Wochen nach Einführung des Systems wird der Leiter der
IT-Abteilung entlassen, da die Daten zwar jeden Montag
vorliegen, sich aber herausgestellt hat, dass sie nicht nutzbar
sind und die erzürnte Geschäftsleitung falsche
Entscheidungen getroffen hat. Das Projekt wird an eine
Beratungsfirma neu vergeben.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
70
so nicht (4/4): so doch, Geschäftsprozessanalyse
Grundkurs Software-Engineering mit UML
Stephan Kleuker
71
Aufgabe der Anforderungsanalyse
4.1
Bestimmung aller Anforderungen an die zu erstellende
Software bzw. an das zu erstellende DV-System,
Anforderungen müssen
–vollständig,
–notwendig ("WAS statt WIE"),
–eindeutig und
–richtig ("abgestimmt als Teil einer Zielhierarchie")
sein.
Bemerkung zur Ablauforganisation: Anforderungen
müssen nicht notwendig in einer Phase vor Beginn des
Entwurfs vollständig bestimmt werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
72
Probleme mit Anforderungen an große Systeme
• Auftraggeber, Nutzer, Betreiber etc. sind häufig verschiedene
Personen, unterschiedliche Personen haben teilweise
widersprüchliche Anforderungen
• die Effekte des angestrebten Systems sind schwer vorhersehbar
• Anforderungen ändern sich im Laufe der Entwicklungszeit
• großer Umfang der Anforderungen
• komplexe Interaktion mit anderen Systemen
• Erste Aufgabe: Ermittlung der Stakeholder
Definition: Jemand der Einfluss auf die Anforderungen hat, da er
vom System betroffen ist (Systembetroffener)
• Zweite Aufgabe: Ermittlung der Ziele des Systems
Grundkurs Software-Engineering mit UML
Stephan Kleuker
73
Checkliste zum Finden von Stakeholdern (1/3) [RS]
• Endanwender
– Die größte und wichtigste Gruppe, liefert Großteil der
fachlichen Ziele
– Durchdachtes Auswahlverfahren für die
Anwenderrepräsentanten nötig (Vertrauensbasis der
gesamten Anwendergruppe berücksichtigen!)
• Management des Auftragnehmers (wir)
– Gewährleisten die Konformität mit Unternehmenszielen und
Strategien, sowie der Unternehmensphilosophie
– Sind die Sponsoren!
• Käufer des Systems
– Wer ist für die Kaufentscheidung verantwortlich?
– Liefer-Vertrags-Zahlungskonditionen?
• Prüfer, Auditoren
– sind für Prüfung, Freigabe und Abnahme notwendig,
• Entwickler
– Entwickler nennen die technologiespezifischen Ziele
Grundkurs Software-Engineering mit UML
Stephan Kleuker
74
Checkliste zum Finden von Stakeholdern (2/3)
• Wartungs- und Servicepersonal
– Wartung und Service muss unkompliziert und zügig
durchzuführen sein
– Wichtig bei hohen Stückzahlen
• Produktbeseitiger
– Wichtig, wenn ausgeliefertes Produkt nicht nur Software
umfasst, Frage der Beseitigung (z.B. Umweltschutz), kann
enormen Einfluss auf die Zielsetzung einer
Produktentwicklung haben
• Schulungs- und Trainingspersonal
– Liefern konkrete Anforderungen zur Bedienbarkeit,
Vermittelbarkeit, Hilfesystem, Dokumentation, Erlernbarkeit,
• Marketing und Vertriebsabteilung
– Marketing und Vertrieb als interne Repräsentanten der
externen Kundenwünsche und der Marktentwicklung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
75
Checkliste zum Finden von Stakeholdern (3/3)
• Systemschützer
– Stellen Anforderungen zum Schutz vor Fehlverhalten von
Stakeholdern
• Standards und Gesetze
– vorhandene und zukünftige Standards/Gesetze
berücksichtigen
• Projekt- und Produktgegner
– Die Klasse der Projekt- und Produktgegner - vor allem zu
Beginn des Projekts wenn möglich mit einbeziehen, sonst
drohen Konflikte
• Kulturkreis
– setzt Rahmenbedingungen, z.B. verwendete Symbolik,
Begriffe, …
• Meinungsführer und die öffentliche Meinung
– beeinflussen oder schreiben Ziele vor, Zielmärkte
berücksichtigen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
76
Regeln für die Definition von Zielen
Ziele müssen
– vollständig,
– korrekt,
– konsistent gegenüber anderen Zielen und in sich
konsistent,
– testbar,
– verstehbar für alle Stakeholder,
– umsetzbar — realisierbar,
– notwendig,
– eindeutig und positiv formuliert sein.
Zwei weitere Merkmale:
– Lösungsneutralität
– einschränkende Rahmenbedingungen
Hinweis: Ziele sind abstrakte Top-Level-Anforderungen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
77
Schablone zur Zielbeschreibung
Ziel
Stakeholder
Was soll erreicht werden?
Welche Stakeholder sind in das Ziel
involviert? Ein Ziel ohne Stakeholder macht
keinen Sinn.
Auswirkungen
Welche Veränderungen werden für die
auf Stakeholder Stakeholder erwartet?
RandWelche unveränderlichen Randbedingungen
bedingungen
müssen bei der Zielerreichung beachtet
werden?
Abhängigkeiten Ist die Zielverknüpfung mit anderen Zielen
unmittelbar verknüpft? Dies kann einen
positiven Effekt haben, indem die Erfüllung
von Anforderungen zur Erreichung mehrerer
Ziele beiträgt. Es ist aber auch möglich, dass
ein Kompromiss gefunden werden muss, da
Ziele unterschiedliche Schwerpunkte haben.
Sonstiges
Was muss organisatorisch beachtet werden?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
78
Projektbeschreibung
Zu entwickeln ist ein individuell auf die Unternehmenswünsche
angepasstes Werkzeug zur Projektverwaltung. Dabei sind die
Arbeitspakete (wer macht wann was) und das
Projektcontrolling (wie steht das Projekt bzgl. seiner Termine
und des Budgets) zu berücksichtigen. Projekte werden zur Zeit
ausgehend von Projektstrukturplänen geplant und verwaltet.
Projekte können in Teilprojekte zerlegt werden.
Die eigentlichen Arbeiten finden in Arbeitspaketen, auch
Aufgaben genannt, statt.
Projekten werden von zusammenzustellenden Projektteams
bearbeitet, die zugehörigen Mitarbeiterdaten sind zu verwalten.
Zur Ermittlung des Projektstands tragen Mitarbeiter ihre
Arbeitszeit und den erreichten Fertigstellungsgrad in das
System ein.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
79
Ziele für eine Projektmanagementsoftware (1/3)
Ziel
1. Die Software muss die Planung und Analyse aller
laufenden Projekte ermöglichen
Projektplaner, Projektleiter, Mitarbeiter, Controlling
Stakeholder
(alle als Endanwender)
Auswirkungen Projektplaner: Alle Planungsdaten fließen in das
auf Stakeholder neue Werkzeug, es gibt sofort eine Übersicht, wer an
was, von wann bis wann arbeitet.
Projektleiter: Der Projektleiter ist immer über den
Stand informiert, er weiß, wer an was arbeitet.
Mitarbeiter: Die Mitarbeiter sind verpflichtet, ihre
Arbeitsstunden und erreichten Ergebnisse in das
Werkzeug einzutragen. Sie sehen, für welche
Folgearbeiten sie wann verplant sind.
Controlling: Hat Überblick über Projektstand.
Existierende Datenbestände sollen übernommen
Randbedingungen werden. Die Randbedingungen zur Verarbeitung
personalbezogener Daten sind zu beachten.
Abhängigkeiten Es liegt eine Studie des Kunden vor, warum kein
Sonstiges
Produkt vom Markt zur Realisierung genommen wird.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
80
Ziele für eine Projektmanagementsoftware (2/3)
Ziel
2. Der neue Kunde soll von der fachlichen Kompetenz unseres Unternehmens überzeugt werden.
Management, Entwickler
Stakeholder
Auswirkungen Management: Der Projekterfolg hat große
auf Stakeholder Auswirkungen auf die nächsten beiden
Jahresbilanzen.
Entwickler: Es werden hohe Anforderungen an die
Software-Qualität gestellt.
Es muss noch geprüft werden, ob langfristig eine
Randfür beide Seiten lukrative Zusammenarbeit
bedingungen
überhaupt möglich ist.
Abhängigkeiten Überschneidung mit dem Ziel 3, da eine
Konzentration auf die Wünsche des neuen Kunden
eventuell einer Verwendbarkeit für den allgemeinen
Markt widersprechen kann.
Das Verhalten des neuen Kunden bei
Sonstiges
Änderungswünschen ist unbekannt.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
81
Ziele für eine Projektmanagementsoftware (3/3)
Ziel
3. Das neue Produkt soll für einen größeren Markt
einsetzbar sein.
Management, Vertrieb, Entwickler
Stakeholder
Auswirkungen Management: Es soll eine Marktposition auf dem
auf Stakeholder Marktsegment Projektmanagement-Software
aufgebaut werden.
Vertrieb: In Gesprächen mit Kunden wird das neue
Produkt und seine Integrationsmöglichkeit mit
anderen Produkten ab Projektstart beworben.
Entwickler: Die Software muss modular aufgebaut
aus Software-Komponenten mit klaren
Schnittstellen bestehen.
Randbedingungen Abhängigkeiten zu Ziel 2 (Beschreibung dort)
Eine Analyse der Konkurrenten auf dem Markt liegt
Sonstiges
vor. Es sind Möglichkeiten für neue, den Markt
interessierende Funktionalitäten aufgezeigt worden.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
82
Rahmenbedingungen und weiteres Vorgehen
Traceability:
• alle Anforderungen müssen sich auf ein Ziel
zurückführen lassen
• alle Ziele benötigen einen Stakeholder (ÖkonomieCheck)
Kommunikation:
• die ausgewählten Stakeholder müssen nun
detaillierter befragt und dauerhaft in das Projekt
integriert werden
Warum der ganze Aufwand:
• Vergessene Ziele und Stakeholder führen zu
massiven Change Requests
Das eigentliche SW-Projekt kann beginnen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
83
Überblick über den Analyseprozess
4.2
1. Erfassung der Systemaufgaben mit
„Use Cases“
2. Beschreibung der Aufgaben mit
Aktivitätsdiagrammen
(optional 3. Formalisierung der Beschreibungen
in Anforderungen)
4. Aufbau eines tieferen Verständnisses durch
Klassenmodellierung und
Sequenzdiagramme (Grobdesign)
iterativer Prozess
Grundkurs Software-Engineering mit UML
Stephan Kleuker
84
Erfragung des WAS?
• Zentrale Frage:
Was sind die Hauptaufgaben des Systems?
• Wer ist an den Aufgaben beteiligt?
• Welche Schritte gehören zur Aufgabenerfüllung?
=> Aufgaben werden als Use Cases
(Anwendungsfälle) beschrieben
=> Beteiligte werden als Aktoren festgehalten
(können meist aus der Menge der
Stakeholder
entnommen werden)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
85
Use Case (Anwendungsfall)
• Use Case beschreibt in der Sprache der Stakeholder, d.h. in
natürlicher Sprache, eine konsistente und zielgerichtete
Interaktion des Benutzers mit einem System, an deren Anfang
ein fachlicher Auslöser steht und an deren Ende ein definiertes
Ergebnis von fachlichem Wert entstanden ist
• Ein Use Case beschreibt das gewünschte externe
Systemverhalten aus Sicht des Anwenders und somit
Anforderungen, die das System erfüllen soll
• eine Beschreibung was es leisten muss, aber nicht wie es dies
leisten soll
• Unterscheidung in Geschäftsanwendungsfall (business use
case) formuliert aus Geschäftssicht (z. B. Vertriebsprozess vom
Anfang) und Systemanwendungsfall (system use case)
formuliert aus Sicht der durch die neue SW zu lösenden
Aufgabe
Grundkurs Software-Engineering mit UML
Stephan Kleuker
86
Zusammenhang der Use Case Arten
• Für ein neu geplantes SW-System wird zunächst analysiert,
welche Prozesse mit der SW unterstützt werden sollen
(Geschäftsprozessmodellierung)
• Oft geht mit dieser Modellierung auch eine Optimierung einher
• Man erhält zentrale Aufgaben, die das SW-System übernehmen
soll (Business Use Case)
• Ausgehend davon werden die Aufgaben geplant, die das SWSystem unterstützen/ausführen soll, dies sind die System Use
Cases
• Häufig gehört zu einem Business Use Case ein System Use
Case, d. h. es gibt die gleiche Überschrift, aber eine
unterschiedliche Beschreibung (im System Use Case steht die
Nutzung des neues SW-Systems im Mittelpunkt)
• Es kann weitere System Use Cases geben, die z. B. die
Systemwartung oder neue Analysemöglichkeiten betreffen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
87
Wege zur Use Case-Ermittlung
•
•
•
•
•
•
moderierter Workshop zentraler Stakeholder
Beobachtung des Kunden, der Endnutzer
Fragebögen
Interviews
Kunde vor Ort im Projekt
Analyse von Altsystemen und Dokumenten des
Kunden
• Simulationsmodelle
Grundkurs Software-Engineering mit UML
Stephan Kleuker
88
Darstellungsbeispiel: Lagerverwaltungssystem
Externe Sicht des Nutzers
auf die Aufgaben des
Systems
Aktoren können Personen
oder andere Systeme sein
Use Cases können in
Teilpaketen strukturiert
werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
89
Systematische Use-Case Ermittlung (1/2)
1. Welche Basisinformationen / Objekte sind zu bearbeiten (keine
Detailmodellierung, keine Informationen, die aus anderen
berechenbar sind)?
Beispiel (Projektmanagementsystem): Projekte, Mitarbeiter
Prüfe ob neues System Basisinformationen verwaltet oder Sie
aus existierenden Systemen stammen
neues System: Use Case „Basisinformation XY verwalten“
gefunden (evtl. in „anlegen“, „bearbeiten“, „löschen“
trennen)
existierendes System: tritt als Aktor auf, wenn Daten benötigt
2. Welche Prozessinformationen sind zu verwalten, also
dynamisch entstehende Daten, Daten zur Verknüpfung von
Basisinformationen
Beispiel: Projektteams, Arbeitsstunden der Mitarbeiter
Ergänze Use Cases, die die Verknüpfung der Daten herstellen,
z. B. „Projektteams zusammenstellen“, „Arbeitsstand
aktualisieren“
Grundkurs Software-Engineering mit UML
Stephan Kleuker
90
Systematische Use-Case Ermittlung (2/2)
3. Ermittle Funktionalität, die auf Basis der Verarbeitung von
Basis- und Prozessinformationen benötigt wird
abstrakte Beispiele: Entscheidungsprozesse/
Analyseprozesse zur Auswertung (Statistiken, Übersichten)
Ergänze Use Case für jede der Prozessarten (Art bedeutet,
Zusammenfassung eng verwandter Funktionalität)
Beispiel: „Projektstand analysieren“
4. Ermittle Use Cases zur reinen Systempflege insofern es
besondere Herausforderungen gibt
abstrakte Beispiele: langfristige Datenhaltung, Systemstart,
Systemterminierung
Zeichne Use Case-Diagramm und ergänze Aktoren (z. B.
Stakeholder, genutzte Systeme, Time) und Dokumentation
Grundkurs Software-Engineering mit UML
Stephan Kleuker
91
Abgeleitetes Use Case-Diagramm
Grundkurs Software-Engineering mit UML
Stephan Kleuker
92
Use Case-Erstellung genauer
• Beschreibung eines Use Cases
– zunächst verbal
– relativ abstrakt, wird später verfeinert
• Leitfragen für die Ermittlung von Akteuren und Prozessen
– Welcher Akteur löst Use Case aus?
– Welche Akteure sind am Use Case beteiligt?
– Welche Aufgaben sind im Use Case zu erfüllen?
– Wer ist verantwortlich für Planung, Durchführung, Kontrolle
der Aufgaben?
– Welche Ereignisse starten den Use Case, treten im Use Case
auf?
– Welche Bedingungen sind zu beachten?
– Was sind die Ergebnisse des Use Cases?
– Welche Beziehungen gibt es zu welchen anderen Use Cases?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
93
Verfeinerung der Use Case-Dokumentation
4.3
• Im ersten Schritt werden in den Use Cases nur die
Hauptaufgaben des Systems beschrieben
• Zur Dokumentation der Use Cases gehört zunächst
nur eine grobe kurze Beschreibung (maximal 5
Sätze) des Inhalts
• Im nächsten Schritt wird dieser Inhalt konkretisiert.
Dabei ist es sinnvoll, auf eine
Dokumentationsschablone zurück zu greifen (oder
eine für das Projekt zu entwickeln)
• Im ersten Schritt der Beschreibungsentwicklung
wird nur der typische Ablauf des Use Cases ohne
Alternativen, dann mit Alternativen beschrieben
Grundkurs Software-Engineering mit UML
Stephan Kleuker
94
Dokumentationsschablone für Use Cases (1/3)
Name des Use
Case
Nummer
1
Paket
2
Autor
1
Version
1
Kurzbeschreibung
beteiligte
Aktoren
(Stakeholder)
1
1
1
kurze prägnante Beschreibung, meist aus Verb
und Nomen
eindeutige Nummer zur Verwaltung, sollte von der
eingesetzten Entwicklungsumgebung vergeben
werden
bei sehr komplexen Systemen können Use Cases
in Teilaufgabenbereiche zusammengefasst
werden, diese Bereiche können in der UML als
Pakete dargestellt werden
wer hat den Use Case erstellt und wer
mitgearbeitet
aktuelle Versionsnummer, möglichst mit
Änderungshistorie, wer hat wann was geändert
kurze Beschreibung, was mit dem Use Case auf
welchem Weg erreicht werden soll,
welche Aktoren sind beteiligt, wer stößt den Use
Case an
Grundkurs Software-Engineering mit UML
Stephan Kleuker
95
Dokumentationsschablone für Use Cases (2/3)
Fachverantwortlicher
1
Referenzen
2
Vorbedingungen
Nachbedingungen
2
typischer
Ablauf
2
alternative
Abläufe
3
2
wer steht auf fachlicher Seite für Fragen zum Use
Case zur Verfügung und entscheidet auf
Auftraggeberseite für die Software über den Inhalt
Nennung aller Informationen, die bei der späteren
Ausimplementierung zu beachten
beziehungsweise hilfreich sind, dies können
Verweise auf Gesetze, Normen oder
Dokumentationen existierender Systeme sein
was muss erfüllt sein, damit der Use Case starten
kann
wie sieht das mögliche Ergebnis aus, im nächsten
Schritt sind auch die Ergebnisse alternativer
Abläufe zu berücksichtigen
welche einzelnen Schritte werden im Use Case
durchlaufen, dabei wird nur der gewünschte
typische Ablauf dokumentiert
welche Alternativen existieren zum typischen
Ablauf
Grundkurs Software-Engineering mit UML
Stephan Kleuker
96
Dokumentationsschablone für Use Cases (3/3)
Kritikalität
3
Verknüpfungen 3
funktionale
4
Anforderungen
nicht4
funktionale
Anforderungen
wie wichtig ist diese Funktionalität für das
Gesamtsystem
welche Zusammenhänge bestehen zu anderen
Use Cases
welche konkreten funktionalen Anforderungen
werden aus diesem Use Case abgeleitet
welche konkreten nicht-funktionalen
Anforderungen werden aus diesem Use Case
abgeleitet
• Nummer gibt Iteration an, in der das Feld gefüllt wird
• typischer und alternative Abläufe werden jetzt genauer
betrachtet
• funktionale und nicht-funktionale Anforderungen weiter
hinten in diesem Abschnitt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
97
Beispielbeschreibung (1/2)
Name des Use
Case
Projektstruktur bearbeiten
Nummer
U1
Paket
-
Autor
Ali Analytiker
Version
1.0, 30.01.2013, Erstellung
Kurzbeschreibung
Mitarbeiter des Projektbüros haben die Möglichkeit,
Projekte mit Teilprojekten anzulegen und zu
bearbeiten.
beteiligte
Aktoren
(Stakeholder)
Projektbüro (startet Use Case durch Auswahl der
Funktionalität im zu erstellenden System)
Fachverantwortlicher
Lisa Leitung (zentrale Ansprechpartnerin des Kunden)
Referenzen
Handbuch zur Führung von Projekten des Kunden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
98
Beispielbeschreibung (2/2)
Vorbedingungen
Die Software ist vollständig installiert und wurde
gestartet.
Nachbedingungen
Neue Projekte und Teilprojekte sowie Änderungen von
Projekten und Teilprojekten wurden vom System
übernommen.
typischer Ablauf 1. Nutzer wählt Funktionalität zur Bearbeitung von
Projektstrukturen
2. Nutzer legt Projekt mit Projektstandarddaten an
3. Nutzer ergänzt neue Teilprojekte
4. Nutzer verlässt Funktionalität
alternative
Abläufe
Nutzer kann existierendes Projekt auswählen,
Nutzer kann Daten eines Teilprojekts ändern
Kritikalität
sehr hoch, System macht ohne Funktionalität keinen
Sinn
Grundkurs Software-Engineering mit UML
Stephan Kleuker
99
Hinweise zu Use Cases (1/2)
• Verwende für den Use Case eine sinnvolle
Bezeichnung, die mindestens aus einem echten
Substantiv und einem aktiven Verb ("Antrag
erfassen") oder dem zugehörigen Gerundium
("Antragserfassung") besteht!
• Definiere zuerst den fachlichen Auslöser und das
fachliche Ergebnis, um Anfang und Ende des Use
Cases festzulegen!
• Formuliere den Use Case so abstrakt wie möglich
und so konkret wie nötig!
• Betreibe zunächst keine Zerlegung in abgeleitete,
sekundäre Use Cases!
• Standardisiere die Sprache in den Use Cases!
Grundkurs Software-Engineering mit UML
Stephan Kleuker
100
Hinweise zu Use Cases (2/2)
• Use Cases eignen sich nicht zur funktionalen
Zerlegung, d.h. ein Use Case beschreibt keine
einzelnen Schritte, Operationen oder Transaktionen
(bspw. "Vertrag drucken", "Kunden-Nr. erzeugen"
etc.), sondern relativ große Abläufe (bspw. "Neuen
Kunden aufnehmen")
• Es wird keine Ablaufreihenfolge definiert. Hierzu gibt
es andere Ausdrucksmittel, z.B. Aktivitätsdiagramme
• Use Cases belassen das Sprachmonopol beim
Stakeholder, wodurch die Use Cases angreifbarer
und besser kritisierbar werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
101
Analyse von Use-Case-Dokumentationen
• Bei der Dokumentation von Use Cases kann es
passieren, dass identische Abläufe mehrfach
beschrieben werden
• Diese (nicht trivialen) Abläufe können als eigene Use
Cases ausgegliedert werden; man sagt dann „ein
Use Case nutzt einen anderen Use Case“
• UML-Darstellung:
A
<<include>>
B
• In spitzen <<Klammern>> stehen so genannte
Steoreotypen, mit denen man UML-Elementen
zusätzliche Eigenschaften zuordnen kann
Grundkurs Software-Engineering mit UML
Stephan Kleuker
102
Beispiel zu <<include>>
Grundkurs Software-Engineering mit UML
Stephan Kleuker
103
<<extend>>
• Seltene Variation des erweiterten Use Cases
• Wird nur unter bestimmter Bedingung ausgeführt, z. B.
Sonderfall oder Fehlerbehandlung
• eigentlicher Use Case nicht durch Spezialfälle überfrachtet
Grundkurs Software-Engineering mit UML
Stephan Kleuker
104
Hinweis zu <<include>>, <<extend>> (persönlich)
• <<include>> ist ein sehr nützlicher Stereotyp, der die
Dokumentation verkürzen kann
• Gerade bei in der Modellierung unerfahrenen
Kunden sollte <<include>> zunächst verheimlicht
werden, da sonst funktionale Zerlegungen in
Bäumen das Ergebnis sind
• <<include>> wird dann bei der Dokumentation und
späteren Verfeinerung bei der Umstrukturierung der
Use Cases als Optimierung eingesetzt
• Hinweis: <<extend>> und weitere nicht erwähnte
Möglichkeiten werden hier ignoriert, da es Kunden
eher verwirrt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
105
Beschreibung verschiedener Abläufe
• Bei Projekten mit enger Kundenbindung (z.B. bei
engen Beziehungen zwischen AG und IT-Abteilung
bei Inhouse-Projekten) können Use Cases (oder
Nutzer Stories) als Anforderungsdokumentation
ausreichen, wenn das Projekt in kleinen Iterationen
und der Möglichkeit eines großen Kundeneinflusses
entwickelt wird
• Oftmals ist die Beschreibung der Use Cases aber zu
ungenau, gerade bei der Darstellung typischer und
Alternativer Abläufe stellt sich die rein sprachliche
Beschreibung als recht aufwändig heraus
• Da die UML eine graphische Sprache ist, stellt sie
auch für Ablaufbeschreibungen eine grafische
Darstellungsmöglichkeit, nämlich
Aktivitätsdiagramme, zur Verfügung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
106
Modellierungsrichtlinie für Aktivitätsdiagramme
Modelliere zu jedem Use Case genau ein Aktivitätsdiagramm
• Mache aus den Use Case-Schritten Aktionen.
• Zerlege die Aktionen ggfls. mit einem Aktivitätsdiagramm, so
dass sie stets genau einen fachlichen Arbeitsschritt
repräsentieren.
• Ergänze den Ablauf um alle bekannten fachlichen Ausnahmen,
fachlichen Fehler und fachlichen Ablaufvarianten, so dass das
Diagramm eine vollständige Beschreibung aller zulässigen
Ablaufmöglichkeiten darstellt.
(sinnvoll jetzt oder später) Modelliere den Objektfluss:
• Beschreibe zu jeder Aktion die vorausgesetzten (zu
verarbeitenden) und resultierenden (erzeugten oder
veränderten) Geschäftsobjekte (Produkte).
• Unterscheide, bei welchen ausgehenden Transitionen bzw.
Bedingungen welche Objekte bzw. Objektzustände resultieren.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
107
Aktivitätsdiagramm mit typischen Ablauf
Use Case: Projektstruktur bearbeiten
Anmerkung: typischer Ablauf ist immer einfache Sequenz von
Aktionen, Ausnahme wie hier: einfache Schleifen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
108
Aktivitätsdiagramm um Alternativen ergänzt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
109
Erinnerung: Modellierung aus Business-Sicht
Grundkurs Software-Engineering mit UML
Stephan Kleuker
110
Modellierung aus System-Sicht
Grundkurs Software-Engineering mit UML
Stephan Kleuker
111
Formulierung von Anforderungen
4.4
• Analog zu den Use Cases sind die Aktivitätsdiagramme zu
dokumentieren, dabei ist genau zu beschreiben, was unter
Nutzung welcher Hilfsmittel unter Berücksichtigung welcher
Nebenbedingungen gilt
• Die Beschreibungen können oft unvollständig oder unklar
formuliert sein, so dass es in größeren oder kritischeren
Projekten sinnvoll ist, die Texte genauer zu analysieren
• Statt einer Fließtextdokumentation von Aktivitätsdiagrammen,
kann eine Darstellung von systematisch abgeleiteten textuellen
Anforderungen sinnvoll sein
• Man benötigt einen Ansatz, Texte möglichst präzise zu
formulieren
Grundkurs Software-Engineering mit UML
Stephan Kleuker
112
Probleme mit natürlich-sprachlichen Formulierungen
• Hauptprozesse der menschlichen Modellbildung
– Tilgung
– Generalisierung
– Nominalisierung
• Problem: Anforderungen werden für Menschen mit
anderer Modellbildung (da andere Erfahrungen)
unsauber formuliert
• In Prosatexten sind Wiederholungen unerwünscht;
bei Anforderungen müssen immer die gleichen
Worte für den gleichen Sachverhalt genutzt werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
113
Definition: Tilgung
• Tilgung ist ein Prozess, durch den wir unsere
Aufmerksamkeit selektiv bestimmten Dimensionen
unserer Erfahrungen zuwenden und andere
ausschließen. (Bandler/Grinder)
• Beispiel: Die Fähigkeit des Menschen, In einem
Raum voller sprechender Menschen alle anderen
Geräusche auszuschließen oder auszufiltern, um der
Stimme einer bestimmten Person zuzuhören.
• Anforderungen: implizite Annahmen, unvollständige
Vergleiche
Grundkurs Software-Engineering mit UML
Stephan Kleuker
114
Beispiele für Tilgungen (1/2)
• Grundstruktur: Manche Prozessworte (Verben und
Prädikate) implizieren zwei oder mehr
Substantivargumente
• Sprachliche Vertreter
– Eingeben: Wer? Was? Wie? Wo? Wann?
– Anzeigen: Was? Wo? In welcher Weise? Wann?
– Übertragen: Wer? Was? Von wo? Wohin? Wann?
– „Die Auszahlungsmöglichkeit soll überprüft und
die Auszahlung verbucht werden“
– Überprüfen: Wer überprüft? Was wird überprüft?
Nach welchen Regeln wird überprüft? Wann wird
überprüft? Wie?
– Verbuchen: Wer verbucht? Was wird verbucht?
Wann wird es verbucht? Wie?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
115
Beispiele für Tilgungen (2/2)
• Grundstruktur: Der Bezugspunkt. die Messbarkeit und die
Messgenauigkeit für einen Komparativ oder Superlativ fehlt.
• Sprachliche Vertreter: Adjektiv + Endung "-er/en", "-ste" oder
"more", "less", "least", oder "weniger", "mehr"
• In beiden Sprachen: Adjektive wie leicht, easy, schwer,
complicated, ...
• Für durchschnittlich große Menschen soll das Display im
normalen Bedienabstand gut lesbar sein.
• Die Eingabe des angeforderten Geldbetrages soll vom System
durch eine intuitive Benutzerführung so unterstützt werden,
dass Fehleingaben minimiert werden.
– Kann man den Sachverhalt überhaupt messen?
– Ist der Bezugspunkt des Vergleiches angegeben?
– Mit welcher Messgenauigkeit wird gemessen?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
116
Definition: Generalisierung
• Generalisierung ist der Prozess, durch den Elemente
oder Teile eines persönlichen Modells von der
ursprünglichen Erfahrung abgelöst werden, um dann
die gesamte Kategorie, von der diese Erfahrung ein
Beispiel darstellt, zu verkörpern. (Bendler/Grindler)
• Beispiel: Ein Kind verbrennt sich an einer heißen
Herdplatte die Hand. Es sollte für sich die richtige
Generalisierung aufstellen, dass es schmerzhaft ist
auf heiße Herdplatten zu fassen.
• Anforderungen: Universalquantoren, unvollständige
Bedingungen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
117
Generalisierung durch Universalquantoren
Universalquantoren
• Grundstruktur: Menge an Objekten wird
zusammengefasst
• Sprachliche Vertreter:
– Im Deutschen: nie, immer, kein, jeder, alle, ...
– Im Englischen: never, ever, not, each, always, ...
• Frage:
– Wirklich alle/jede, immer/nie? Gibt es keine
Ausnahme?
– Achtung! Auch Sätze ohne Universalquantoren
überprüfen, die keine Angaben über die Häufigkeit
enthalten!
Grundkurs Software-Engineering mit UML
Stephan Kleuker
118
Beispiele für Generalisierungen
• Jede Auszahlung soll für die Rückverfolgbarkeit
zusätzlich mit einem Zeitstempel etikettiert werden.
– Wirklich jede Auszahlung?
• Das System soll eine Sicherung von aufgezeichneten
Auszahlungsdaten auf ein externes Speichermedium
ermöglichen.
– Durch jede Person? Immer? Aller
Auszahlungsdaten?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
119
Definition: Verzerrung
• Verzerrung ist der Prozess, etwas mittels
Überlegungen, Fantasie oder Wünschen, so
umzugestalten, dass ein neuer Inhalt oder eine neue
Bedeutung entsteht. (Dörrenbacher)
• Beispiel: Behauptung, dass auf A dann B folgt oder
Gedankenlesen
– Da jemand zu spät ist, ist das Projekt gefährdet
– Ich denke, der mag mich nicht
– Er wollte wissen, wie ich mich jetzt fühle
Grundkurs Software-Engineering mit UML
Stephan Kleuker
120
Verzerrung: Beispiele und Analyse
• Der Nutzer muss zunächst sein Login und dann sein
Passwort eingeben.
• Dem Nutzer muss am Anfang immer die
Übersichtsseite gezeigt werden.
• Der Nutzer muss eingeloggt sein, um die Übersicht
zu sehen.
• Was führt zur Annahme, dass diese Reihenfolgen
notwendig sind?
• Was würde sich bei einer anderen Reihenfolge oder
Verlassen einer Einschränkung ändern?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
121
Verzerrung durch Nominalisierung
• Grundstruktur: Ein Prozesswort (Verb oder Prädikat) wird zu
einem Ereigniswort (Substantiv oder Argument) umgeformt.
• Dadurch wird ein Vorgang zu einem Ereignis und viele
vorgangsrelevante Informationen gehen verloren.
• Es ist möglich, dass sich die Bedeutung der Aussage dadurch
ändert.
– Die Berechtigung für die Administration des Geldautomaten
– Die Auszahlung wird nach der Buchung durchgeführt
– Wer? zahlt wann? Wem? Was? Unter Einhaltung welcher
Regeln? Mit welcher Zuverlässigkeit? Mit welcher
Verfügbarkeit?
– Wer? bucht wann? Was? Wohin? Unter Einhaltung welcher
Regeln? Mit welcher Zuverlässigkeit? Mit welcher
Verfügbarkeit?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
122
Erkennen von Nominalisierungen
Fragen/Vorgehen:
• Intuition, Sprachgefühl
• Suche nach ähnlichem Prozesswort
• Sprachtest durch Einsetzen in "ein(e) andauernde(r) …".
Wahre Substantive passen nicht in diese Aussage
Beispiele:
• Bei der Auswahl der Auszahlungsfunktion soll die …
• der Anzeige, Benutzerführung, Bestätigung, ....
• die Eingabe, Erfassung, ....
• das Ereignis, die Meldung, ...
• die Buchung, Ausgabe, Prüfung, ....
Anmerkung: Nominalisierung wird oft auch als Tilgung angesehen
http://nlpportal.org/nlpedia/wiki/Metamodell
Grundkurs Software-Engineering mit UML
Stephan Kleuker
123
Entwicklung strukturierter Anforderungen
• ein Ansatz zu qualitativ hochwertigen
Anforderungen: erste Version erstellen und dann
Textqualität schrittweise verbessern
• Alternative: „von Anfang an“ hochwertige
Anforderungen zu schreiben
• Dieser Ansatz kann durch Anforderungsschablonen
unterstützt werden, die den Satzbau von
Anforderungen vorgeben (vorgestellter Ansatz folgt
[RS])
• Man beachte, bereits erwähnte Ausdrucksprobleme
auch in diesem Ansatz noch relevant
Grundkurs Software-Engineering mit UML
Stephan Kleuker
124
Charakterisierung von Systemaktivitäten
• Selbständige Systemaktivität:
Das System führt den Prozess selbständig durch.
• Benutzerinteraktion:
Das System stellt dem Nutzer die
Prozessfunktionalität zur Verfügung.
• Schnittstellenanforderung:
Das System führt einen Prozess in Abhängigkeit von
einem Dritten (zum Beispiel einem Fremdsystem)
aus, ist an sich passiv und wartet auf ein externes
Ereignis.
• Für jede dieser Systemaktivitäten gibt es eine
Schablone.
• Frage: Werden Systemaktivitäten so in disjunkte
Klassen aufgeteilt?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
125
Visualisierung der Systemaktivitäten
Typ 2 Anforderungen:
Funktionalität zur
Verfügung stellen
Typ 1 Anforderungen:
System führt Prozess
aus
stößt an
Nutzer
ruft auf
Schnittstelle
externer
Prozess
stößt
an
zu entwickelndes System
System-Kern
macht
Eingaben
Typ 3 Anforderungen:
System fähig, externe
Anfrage zu bearbeiten
Grundkurs Software-Engineering mit UML
Stephan Kleuker
126
Anforderungsformulierung (Rupp-Schablone)
-
muss
<Wann?>
<Randbedingung>
soll
Typ 1
Typ 2
das
System
<wem?> die
Möglichkeit
bieten
<Objekt mit
Randbedingung>
<Prozesswort>
wird
fähig sein Typ 3
Typ 1: Selbständige Systemaktivität, System führt Prozess
selbständig durch, z. B. Berechnung des bisherigen Aufwandes
eines Projekts durch Abfrage aller Teilprojekte und Ergebnisanzeige
Typ 2: Benutzerinteraktion, System stellt Nutzer die
Prozessfunktionalität zur Verfügung, z: B. Verfügbarkeit eines
Eingabefeldes, um den Projektdaten einzugeben
Typ 3: Schnittstellenanforderung, d. h. das System führt einen
Prozess in Abhängigkeit von einem Dritten (zum Beispiel einem
Fremdsystem) aus, ist an sich passiv und wartet auf ein externes
Ereignis, z. B. Anfrage einer anderen Bürosoftware nach einer
Übersicht über die laufenden Projekte annehmen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
127
Typ 1: Selbständige Systemaktivität
-
muss
<Wann?>
<Randbedingung>
soll
Typ 1
Typ 2
das
System
<wem?> die
Möglichkeit
bieten
<Objekt mit
Randbedingung>
<Prozesswort>
wird
fähig sein Typ 3
Nach Abschluss der Eingabe (mit „Return“-Taste oder
Bestätigungsknopf) bei der Bearbeitung von Daten muss das
System neu eingegebene Daten in seine permanente Datenhaltung
übernehmen. [„Daten“ muss konkretisiert werden]
Nach der Eingabe eines neuen Teilprojekts oder einer neuen
Projektaufgabe und nach der Aktualisierung des Aufwandes eines
Teilprojekts oder einer neuen Projektaufgabe muss das System
die Aufwandsangaben auf Plausibilität prüfen.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
128
Typ 2: Benutzerinteraktion
-
muss
<Wann?>
<Randbedingung>
soll
Typ 1
Typ 2
das
System
<wem?> die
Möglichkeit
bieten
<Objekt mit
Randbedingung>
<Prozesswort>
wird
fähig sein Typ 3
In der Projektbearbeitung muss das System dem Nutzer die
Möglichkeit bieten, ein neues Projekt mit Projektausgangsdaten
anzulegen.
In der Projektbearbeitung muss das System dem Nutzer die
Möglichkeit bieten, jedes Projekt auszuwählen.
Nach der Projektauswahl muss das System dem Nutzer die
Möglichkeit bieten, für existierende Projekte neue Teilprojekte
anzulegen.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
129
Typ 3: Schnittstellenanforderung
-
muss
<Wann?>
<Randbedingung>
soll
Typ 1
Typ 2
das
System
<wem?> die
Möglichkeit
bieten
<Objekt mit
Randbedingung>
<Prozesswort>
wird
fähig sein Typ 3
Nach der Kontaktaufnahme durch die Software „Globalview“ muss
das System fähig sein, Anfragen nach den Projektnamen, deren
Gesamtaufwänden und Fertigstellungsgraden anzunehmen.
(folgt Typ2: Nach der Annahme der Anfrage … )
Grundkurs Software-Engineering mit UML
Stephan Kleuker
130
Vom Aktivitätsdiagramm zur textuellen Anforderung
• Jede Aktion wird mit einer Anforderung oder
mehreren Anforderungen beschrieben
• Jede Transition und Entscheidung wird mit einer
Anforderung oder mehreren Anforderungen
beschrieben
• Aus dem Ablauf der zur Aktion, Transition oder
Entscheidung führt, wird der erste Teil der jeweiligen
Anforderung („Wann?“) erzeugt.
• Hinweis: Anforderungen zum Beispiel stehen im
folgenden Kapitel
Grundkurs Software-Engineering mit UML
Stephan Kleuker
131
Beispielübersetzung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
132
Nicht-funktionale Anforderungen (1/2) [sehr kurz]
4.5
• Bisher lag der Schwerpunkt auf funktionalen Anforderungen
„was muss das System machen“
• SW unterliegt unterschiedlichen nicht-funktionalen
Anforderungen, die maßgeblich für den Projekterfolg sein
können
Hier wird eine Charakterisierung vorgestellt:
• technische Anforderungen: Hardwareanforderungen,
Architekturanforderungen, Anforderungen an die
Programmiersprachen
• Anforderungen an die Benutzungsschnittstelle: Form und
Funktion von Ein- und Ausgabe-Geräten
• Anforderungen an die Dienstqualität: DIN EN ISO 66272
unterteilt die Dienstgüte in die fünf Merkmale Zuverlässigkeit,
Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit
Grundkurs Software-Engineering mit UML
Stephan Kleuker
133
Nicht-Funktionale Anforderungen (2/2)
• Anforderungen an sonstige Lieferbestandteile: Selten besteht
das System nur aus einem Stück kompilierten Programmcodes,
es werden Zusatzlieferungen, wie Systemhandbücher und
Installationshandbücher gefordert
• Anforderungen an die Durchführung der Entwicklung und
Einführung: z. B. Anforderungen an die Vorgehensweise
(Software-Erstellung, Software-Prüfung), anzuwendende
Standards, Hilfsmittel (Tools), die Durchführung von
Besprechungen, von Abnahmetests (fachliche Abnahme,
betriebliche Abnahme) und die Festlegung von Terminen
• rechtlich-vertraglichen Anforderungen: z. B. Angaben zu
Zahlungsmeilensteinen, Vertragsstrafen, dem Umgang mit
Änderungen der Anforderungen, Eskalationspfade
Grundkurs Software-Engineering mit UML
Stephan Kleuker
134
Lastenheft / Pflichtenheft
4.6 •
Lastenheft wird vom Auftraggeber (Kunden)
geschrieben
– welche Funktionalität ist gewünscht
– welche Randbedingungen (SW/ HW) gibt es
• Pflichtenheft wird vom Auftragnehmer (SoftwareEntwicklung) geschrieben
– welche Funktionalität wird realisiert
– auf welcher Hardware läuft das System
– welche SW-Schnittstellen (Versionen)
berücksichtigt
• Variante: Kunde beauftragt Auftragnehmer direkt in
Zusammenarbeit Pflichtenheft zu erstellen
– ein gemeinsames Heft ist sinnvoll
– Pflichtenheft ist meist (branchenabhängig) zu
bezahlen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
135
Lastenheft / Pflichtenheft: möglicher Aufbau
0. Administrative Daten: von wem, wann genehmigt, ...
1. Zielbestimmung und Zielgruppen
In welcher Umgebung soll System eingesetzt werden?
Ziele des Systems, welche Stakeholder betroffen?
2. Funktionale Anforderungen
Produktfunktionen (Use Cases, Aktivitätsd.,
Anforderungen)
Produktschnittstellen (a.GUI-Konzept b. andere SW)
3. Nichtfunktionale Anforderungen
Qualitätsanforderungen
weitere technische Anforderungen
4. Lieferumfang
5. Abnahmekriterien
6. Anhänge (insbesondere Glossar)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
136
5. Grobdesign
5.1
5.2
5.3
5.4
5.5
Systemarchitektur
Ableitung von grundlegenden Klassen
Ableitung von Methoden und Kontrollklassen
Validierung mit Sequenzdiagrammen
Überlegungen zur Oberflächenentwicklung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
137
Systemarchitektur
5.1
Festlegen der Randbedingungen bzgl. Hardware, Betriebssystem,
verwendeter Software, zu integrierender Systeme
• Vorgabe der Hardware, die Software muss z. B. auf einer
Spezialhardware funktionieren
• Vorgabe des Betriebssystems, die Software muss eventuell mit
anderer Software auf Systemebene zusammenarbeiten
• Vorgabe der Middleware, die Software wird häufig auf
verschiedene Prozesse verteilt, die miteinander kommunizieren
müssen
• Vorgaben zu Schnittstellen und eingesetzten
Programmiersprachen, die Software soll mit anderer Software
kommunizieren und muss dabei deren Schnittstellen
berücksichtigen
• Vorgaben zum „Persistenzframework“, die Daten der zu
erstellenden Software müssen typischerweise langfristig
gespeichert werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
138
Beispiel: Projektstrukturplan
5.2
Projekt
Perpetuum
(Teil-)Projekt
Aufgabe
Projektleitung
P. Palaver (30%)
Qualitätssicherung
Projektinfrastruktur
QS-Leitung
G. Genau (30%)
Adminstration
S. Super (20%)
Tester
P. Penibel (100%)
Installation
P. Prökel (50%)
Entwicklung
Entwicklungsleitung
P. Palaver (70%)
Sicherung
S. Safe (20%)
Oberflächenentwicklung
Programmierung
W. Widget (100 %)
Businessmodell
Datenbankanbindung
Analyse
S. Schlaubi (100 %)
Programmierung
E. Entität (100 %)
Programmierung
M. Muster (100 %)
Programmierung
H. Hack (100 %)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
139
Erste Iteration: Klassen finden
• Aktivitätsdiagramme werden durch Anforderungen
konkretisiert
• Text der Anforderungen ist Grundlage zum Finden
erster Klassen
• Im Text werden Objekte identifiziert; sind Individuen,
die durch Eigenschaften (Exemplarvariablen) und
angebotene Funktionalität charakterisiert werden
• grober Ansatz: Nomen in Anforderungen und
Glossar ansehen; können Objekte oder
Eigenschaften sein
• Adjektive können auf Eigenschaften hindeuten
• Informationen in Klassen gesammelt; Klassen
beschreiben Struktur, die jedes Objekt hat
Grundkurs Software-Engineering mit UML
Stephan Kleuker
140
Analyse der Anforderungen (1/5)
A1.1: In der Projektbearbeitung muss das System dem Nutzer die
Möglichkeit bieten, ein neues Projekt mit Projektausgangsdaten
anzulegen.
• Glossar Projektausgangsdaten: automatisch vergebene
eindeutige Projektnummer, Projektname, geplanter Start- und
Endtermin, geplanter Aufwand.
• gefunden: Klasse Projekt mit Exemplarvariablen
Projektnummer, Projektname, geplanter Starttermin, geplanter
Endtermin, geplanter Aufwand
A1.2: Nach Abschluss der Eingabe (mit „Return“-Taste oder
Bestätigungsknopf) bei der Bearbeitung von Daten muss das
System neu eingegebene Daten in seine permanente
Datenhaltung übernehmen.
A1.3: In der Projektbearbeitung muss das System dem Nutzer die
Möglichkeit bieten, jedes Projekt auszuwählen.
• gefunden: keine Klassen oder Exemplarvariablen
(Funktionalität später)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
141
Analyse der Anforderungen (2/5)
A1.4: Nach der Projektauswahl muss das System dem Nutzer die
Möglichkeit bieten, für existierende Projekte neue Teilprojekte
anzulegen.
gefunden: Exemplarvariable Teilprojekte für Projekt, (eventuell)
neue Klasse Teilprojekt
A1.5: Bei der Projektdatenbearbeitung muss das System
Teilprojekte wie Projekte behandeln und dem Nutzer die
gleichen Möglichkeiten zur Bearbeitung bieten.
• Teilprojekt und Projekt sind für die Software Synonyme,
deshalb keine eigene Klasse
• generell auf Synonyme (verschiedene Wörter mit gleicher
Bedeutung) und Homonyme (Wörter mit verschiedenen
möglichen Bedeutungen achten)
A1.6: Nach der Projektauswahl muss das System dem Nutzer die
Möglichkeit bieten, den realen Starttermin, das aktuell
kalkulierte Fertigstellungsdatum, den geplanten Aufwand und
den Projektkommentar zu bearbeiten.
• Exemplarvariablen für Projekt: realer Starttermin, aktuelles
Fertigstellungsdatum, Kommentar
Grundkurs Software-Engineering mit UML
Stephan Kleuker
142
Analyse der Anforderungen (3/5)
A1.7: Nach der Projektauswahl muss das System dem Nutzer die
Möglichkeit bieten, neue Teilaufgaben mit dem
Aufgabennamen, dem geplanten Start- und Endtermin, dem
Arbeitsanteil des Mitarbeiters und dem geplanten Aufwand zu
definieren.
• Glossar Projektaufgabe: Teilaufgabe in einem Projekt, die einen
Namen und einen eindeutigen Bearbeiter hat, der zu einem
gewissen Prozentsatz der Aufgabe zugeordnet ist, die einen
geplanten und realen Aufwand, geplante und reale Start- und
Endtermine und einen Fertigstellungsgrad hat und die nicht
weiter verfeinert wird.
• Glossar Fertigstellungsgrad: Für Projektaufgaben geben die
jeweiligen Bearbeiter den Fertigstellungsgrad in % an. Die
Bearbeiter sind angewiesen, dass bei einer Bearbeitung ohne
besondere Probleme dieser Wert möglichst linear wächst. Der
Fertigstellungsgrad von Projekten wird aus den
Fertigstellungsgraden der Teilprojekte und Aufgaben,
gewichtet nach dem geplanten Aufwand berechnet.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
143
Analyse der Anforderungen (4/5)
• Glossar Aufwand: Für Projektaufgaben gibt der jeweilige
Bearbeiter an, wie viele Stunden er bereits mit seiner Aufgabe
verbracht hat. Der Aufwand von Projekten berechnet sich aus
den Aufwänden der jeweiligen Teilprojekte und
Projektaufgaben.
• gefunden: Exemplarvariable Aufgaben für Projekt
neue Klasse Projektaufgabe mit Exemplarvariablen Namen,
Bearbeiter, Arbeitsanteil, geplanter Aufwand, realer Aufwand,
geplanter und realer Starttermin, geplanter und realer
Endtermin, Fertigstellungsgrad
Projekt hat auch Exemplarvariablen Fertigstellungsgrad und
realer Aufwand, die allerdings vollständig aus anderen Werten
berechnet werden können. Man spricht dabei von einer
abhängigen Exemplarvariable.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
144
Analyse der Anforderungen (5/5)
A1.8: Nach der Projektauswahl muss das System dem Nutzer die
Möglichkeit bieten, Projektaufgaben zu selektieren.
A1.9: Nach der Projektaufgabenauswahl muss das System dem
Nutzer die Möglichkeit bieten, sämtliche Eigenschaften der
Projektaufgabe zu bearbeiten.
A1.10: Nach der Projektauswahl muss das System dem Nutzer die
Möglichkeit bieten, (Teil-)Projekte anzugeben, von deren
Fertigstellung das Projekt abhängig ist.
• gefunden: (in A1.8 und A1.9) nichts, in A1.10 Exemplarvariable
Vorgänger für Projekt
• (weitere Anforderungen nur für zweite Iteration relevant)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
145
Erstes Klassendiagramm
• Klassenname,
• Exemplarvariable:Typ
• Sichtbarkeit (-) kein Zugriff von Außen (+) Zugriff von außen (für
Exemplarvariable unerwünscht)
• Schreibweise Menge() unüblich, / für abgeleitet
Grundkurs Software-Engineering mit UML
Stephan Kleuker
146
UML-Notation
• Assoziationen: Beziehung zwischen Klassen
• Rollenname am Ende entspricht Exemplarvariablennamen
• Multiplizitäten „von..bis“, * für beliebig, alternativ 0..* statt *
Grundkurs Software-Engineering mit UML
Stephan Kleuker
147
Zusammenhang Klasse und Objekt
•
•
•
•
Objekte lassen sich auch in der UML darstellen
Kasten mit unterstrichenem „:<Klassenname>“
vor Doppelpunkt kann Objektname stehen
Objekte werden nicht im Klassendiagramm dargestellt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
148
UML unterstützt iteratives Vorgehen
• UML-Teile weggelassen bzw. ausblenden, abhängig von
notwendigen bzw. vorhandenen Teilinformationen
• Je implementierungsnäher desto detaillierter
Grundkurs Software-Engineering mit UML
Stephan Kleuker
149
Zweite Iteration: Methoden suchen
5.3
• Methoden stehen für Funktionalität, die ein Objekt anbietet;
typisch: Zustand (d. h.) Exemplarvariable ändern, Ergebnis
basierend auf Exemplarvariablen berechnen
• Ansatz 1: Analysiere Verben im Text
• Ansatz 2: Aus Use Cases lässt sich häufig eine
Steuerungsklasse (Koordinationsklasse) ableiten
• folgende Anforderungen an die Klassenformulierung müssen
beachtet werden:
– Klassen übernehmen jeweils eine Aufgabe und besitzen
genau die zur Durchführung benötigten Methoden und die
für die Methoden benötigten Exemplarvariablen
– Klassen sollen möglichst wenig andere Klassen kennen,
wodurch die Schnittstellenanzahl gering gehalten wird
• (Hinweis: unser Beispiel ist datenlastig, deshalb wenige
Methoden)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
150
zweite Analyse der Anforderungen (1/5)
• get- und set-Methoden werden gerne im Modell weggelassen,
für Exemplarvariable x:Typ in Java
public Typ getX() {return x;}
public void setX(Typ x){this.x=x;}
A1.1: In der Projektbearbeitung muss das System dem Nutzer die
Möglichkeit bieten, ein neues Projekt mit Projektausgangsdaten
anzulegen.
• Konstruktoren werden nur genannt, wenn besondere Arten
gefordert werden. Wird kein Konstruktor explizit genannt, wird
davon ausgegangen, dass ein Default-Konstruktor ohne
Parameter zur Verfügung steht.
hier: Projekt(String, Datum, Datum, int)
A1.2: Nach Abschluss der Eingabe (mit „Return“-Taste oder
Bestätigungsknopf) bei der Bearbeitung von Daten muss das
System neu eingegebene Daten in seine permanente
Datenhaltung übernehmen.
• Hier steckt nur eine verstecke Anforderung an die Benutzung
dahinter, als Funktionalität wird nur set... gefordert.
Datenhaltung wird später geklärt.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
151
zweite Analyse der Anforderungen (2/5)
A1.3: In der Projektbearbeitung muss das System die Möglichkeit
bieten, jedes Projekt auszuwählen.
• Steuerungsklasse Projektverwaltung
• Exemplarvariablen: alle Projekte und selektiertes Projekt
• Projektauswahl ist set-Methode
A1.4: Nach der Projektauswahl muss das System dem Nutzer die
Möglichkeit bieten, für existierende Projekte neue Teilprojekte
anzulegen.
• Wie bei Mengen von Werten üblich, wird meistens eine addund eine delete-Methode gefordert. In diesem Fall nur
teilprojektHinzufuegen(Projekt): void
A1.7: Nach der Projektauswahl muss das System dem Nutzer die
Möglichkeit bieten, neue Projektaufgaben mit dem
Aufgabennamen, dem geplanten Start- und Endtermin, dem
Arbeitsanteil des Mitarbeiters und dem geplanten Aufwand zu
definieren.
• Projekt hat Methode aufgabeHinzufuegen(Projektaufgabe): void
• Konstruktor Aufgabe(String, Datum, Datum, int, int)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
152
zweite Analyse der Anforderungen (3/5)
Glossar Aufwand: ... Der Aufwand von Projekten berechnet sich
aus den Aufwänden der jeweiligen Teilprojekte und
Projektaufgaben.
• hier „versteckt“ sich die Funktionalität, dass für Projekte der
aktuelle Aufwand berechnet werden soll:
realenAufwandBerechnen(): int
• analog: fertigstellungsgradBerechnen(): double
A1.8: Nach der Projektauswahl muss das System dem Nutzer die
Möglichkeit bieten, Projektaufgaben zu selektieren.
• Projekt hat Exemplarvariable selektierteAufgabe [erster Ansatz,
wichtig nur vollständiges Modell]
A1.10: Nach der Projektauswahl muss das System dem Nutzer die
Möglichkeit bieten, (Teil-)Projekte anzugeben, von deren
Fertigstellung das Projekt abhängig ist.
• Projekt hat vorgaengerHinzufuegen(Projekt): void
Grundkurs Software-Engineering mit UML
Stephan Kleuker
153
zweite Analyse der Anforderungen (4/5)
A1.11: Nach der Eingabe eines neuen Teilprojekts oder einer
neuen Projektaufgabe und nach der Aktualisierung des
Aufwandes eines Teilprojekts oder einer neuen Projektaufgabe
überprüft das System die Aufwandsangaben auf Plausibilität.
• folgt, dass Teilprojekt die Möglichkeit haben muss,
festzustellen, zu welchem (Teil-)Projekt es gehört.
• eine Lösung: in angegebener Assoziation, mit der Teilprojekte
festgehalten werden, ist diese Information bereits in der
Multiplizität 0..1 enthalten, es wird Rollenname zur
Veranschaulichung ergänzt.
• (Ansatz: Durch die Angabe von Rollennamen wird ersichtlich,
in welche Richtung Assoziationen navigierbar sein müssen)
• Projekt: aufwandsaenderungPruefen(neuerAufwand: int): bool
• Projektaufwand: zugeordneter Aufwand (geplanter Aufwand)
minus verteilter Aufwand, also: verteilterAufwand():int
• Für Projekte auch:
aufwandsaenderungPruefen(Projektaufgabe, int): bool
Grundkurs Software-Engineering mit UML
Stephan Kleuker
154
zweite Analyse der Anforderungen (5/5)
A1.12: Bei der Überprüfung der Aufwandsangaben auf Plausibilität
muss das System prüfen, ob die Summe der geplanten
Teilprojekte und Aufgaben eines Projekts kleiner-gleich der
geplanten Summe des Projekts ist.
• beschreibt nur detailliert, wie die vorher gefundene Methode zu
realisieren ist
A1.13: Nach einer gescheiterten Aufwandsplausibilitätsprüfung
muss das System den Nutzer über das Problem informieren
und darf den Aufwandswert nicht verändern.
• Projektverwaltung bekommt die Möglichkeit, auf das gefundene
Problem hinzuweisen ( zu GUI-Funktionalität später mehr)
inkonsisteneAktualisierungAnzeigen(grund:String):void
Grundkurs Software-Engineering mit UML
Stephan Kleuker
155
Klassendiagramm
Grundkurs Software-Engineering mit UML
Stephan Kleuker
156
Vererbung
• Analysemodell wird auf erste Optimierungen geprüft
• Wenn Objekte verschiedener Klassen große Gemeinsamkeiten
haben, kann Vererbung genutzt werden
• Variante 1: Abstrakte Klasse mit möglichen Exemplarvariablen,
einigen implementierten und mindestens einer nichtimplementierten Methode
• Variante 2: Interface ausschließlich mit abstrakten Methoden
(haben später noch Bedeutung)
• Vererbung reduziert den Codierungsaufwand
• Vererbung erschwert Wiederverwendung
• Liskovsches Prinzip für überschreibende Methoden der
erbenden Klassen berücksichtigen:
– Vorbedingung gleich oder abschwächen
– Nachbedingungen gleich oder verstärken
Grundkurs Software-Engineering mit UML
Stephan Kleuker
157
Beispiel: Vererbung
nächster Schritt: Prüfen, wo statt Projekt und Projektaufgabe Projektkomponente
stehen kann (Abstrahierung)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
158
Aufzählungen
• Häufiger gibt es Exemplarvariablen, die bestimmte Werte, z. B.
{rot,gelb,grün} annehmen können
• Aufzählungstypen werden in der UML
wie rechts gezeigt beschrieben
• Der Stereotyp <<enumeration>> gibt an, dass es sich um eine
Klasse mit bestimmten Eigenschaften handelt
• Die UML hat einige Stereotypen vorgegeben; weitere können
beliebig vereinbart werden.
• Wie bei allen UML-Sprachelementen gilt, dass man vor dem
Modellierungsstart festlegen muss, welches Diagramm und
welche Notation wann eingesetzt werden soll
Grundkurs Software-Engineering mit UML
Stephan Kleuker
159
Validierung mit Sequenzdiagrammen
5.4
• Mit Hilfe des erreichten
Modells kann man mit
Sequenzdiagrammen
validieren, ob die im
Aktivitätsdiagramm
beschriebenen Abläufe
möglich sind
• rechte Seite zeigt
verschiedene
Darstellungsmöglichkeiten
eines Methodenaufrufs
• Rückgabewerte werden
häufig weggelassen, wenn
nur Ablauf wichtig
• (Stellen auch Testfälle dar)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
160
Zusammenhang: Programm und Sequenzdiagramm
public class A {
extern
:A
b:B
private B b= new B();
private C c;
mach(42)
tues(42)
public char mach(int x){
int t= b.tues(x);
42
c= new C(t,t+1);
return b.yeah(c);
new C(42,43)
}
c:C
}
yeah(c)
public class B {
sach(A)
public int tues(int x){
return x%255;
'U'
}
'V'
public char yeah(C c){
'V'
char e=c.sachA();
return (char) (e+1);
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
161
Iterative Entwicklung und Validierung
Beispielablauf
• Ableitung von Methodennamen
• Zeichnen eines kleinen Sequenzdiagramms mit
dieser Methode; feststellen, ob weitere Methoden
benötigt
• Ergänzung von Methodenparametern
• Ergänzung des Sequenzdiagramms um Parameter;
feststellen, ob weitere Methoden benötigt
• Falls kein Sequenzdiagramm herleitbar, auf
Ursachenforschung gehen (Modellfehler?)
• Optimales Ziel: Mögliche Durchläufe durch
Aktivitätsdiagramme werden abgedeckt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
162
Zusammenhang zwischen Aktivitäts- und
Sequenzdiagrammen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
163
Iterative Entwicklung eines Sequenzdiagramms
:A
• generell: zunächst unterspezifiziert,
• dann Parameter verfeinern
• abstrakter Ablauf (x) oder konkreter
Beispielablauf (mit Werten)
• Ergänzung interner Berechnungen,
z. B. in A z= this.oh();
• interne Collections meist nicht
dargestellt
• Darstellung aber möglich, in B:
public void hinzu(C c){
l.add(c);
}
Grundkurs Software-Engineering mit UML
b:B
tues()
l:Set
tues(x)
tues(42)
z=oh()
hinzu(c)
hinzu(c)
Stephan Kleuker
add(c)
164
Sequenzdiagramm und Kommunikationsdiagramm
• gleiches Ausdrucksvermögen wie einfache
Sequenzdiagramme
• Zusammenspiel der Objekte wird deutlicher
• interne Berechnung 2.1, 2.2 (ggfls. 2.1.1, 2.1.1.1)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
165
Highlevel-Sequenzdiagramme
Grundkurs Software-Engineering mit UML
Stephan Kleuker
166
Beispiel: Initialisierung
• Anmerkung: Typischerweise „befruchten“ sich die
Entwicklung von Klassendiagrammen und
Sequenzdiagrammmen (Optimierung in einem iterativen
Prozess)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
167
Beispiel: Anstoß der Funktionalität
• häufig werden Teilsysteme spezifiziert, deren Nutzung von
außen angestoßen wird
• dann im Sequenzdiagramm „außen“ als „Extern“ modellieren
Grundkurs Software-Engineering mit UML
Stephan Kleuker
168
Beispiel: Fertigstellungsgrad berechnen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
169
Beispiel: Prüfung Projektaufwand aktualisierbar (1/2)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
170
Beispiel: Prüfung Projektaufwand aktualisierbar (2/2)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
171
Beispiel: Projektaufgabenaufwand aktualisierbar?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
172
GUI-Modellierung
5.5
• fachlich hängt Oberfläche (GUI, Graphical User
Interface) eng mit unterliegendem
Geschäftsklassenmodell (bisher behandelt)
zusammen
• möglicher Ansatz: „Mache alle Modellanteile an der
Oberfläche sichtbar, die ein Nutzer än-dern oder für
dessen Inhalte er sich interessieren kann.“
• Variante: mache ersten GUI-Prototyp und halte bei
Ein- und Ausgaben fest, welche Modellinformationen
sichtbar sein sollen
• GUI-Prototyp gut mit Kunden dieskutierbar
• Hinweis: Thema Softwareergonomie später
Grundkurs Software-Engineering mit UML
Stephan Kleuker
173
Erweiterung mit Boundary-Klassen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
174
Sequenzdiagramm mit Nutzungsdialog
Grundkurs Software-Engineering mit UML
Stephan Kleuker
175
Anforderungsverfolgung
Typische Fragen:
• Werden alle Anforderungen umgesetzt?
• Wo werden Anforderungen umgesetzt?
• Gibt es Spezifikationsanteile, die nicht aus
Anforderungen abgeleitet sind?
• Woher kommt eine Klasse, eine Methode, ein
Parameter?
• Was passiert, wenn ich eine Anforderung oder eine
Klasse ändere?
• Generell werden die Fragen wesentlich komplexer zu
beantworten, wenn Software später umgebaut oder
erweitert wird
Grundkurs Software-Engineering mit UML
Stephan Kleuker
176
Anforderungsverfolgung - Beispielzusammenhänge
Grundkurs Software-Engineering mit UML
Stephan Kleuker
177
6. Vom Klassendiagramm
zum Programm
6.1
6.2
6.3
6.4
6.5
6.6
CASE-Werkzeuge
Übersetzung einzelner Klassen
Übersetzung von Assoziationen
Spezielle Arten der Objektzugehörigkeit
Aufbau einer Software-Architektur
Weitere Schritte zum lauffähigen Programm
Grundkurs Software-Engineering mit UML
Stephan Kleuker
178
Analyse des Ist-Standes
• bekannter Weg: Kundenwünsche,
Anforderungsformulierung, Analyse-Modell
• Analysemodell kann realisiert werden, aber:
– Klassen kaum für Wiederverwendung geeignet
– Programme meist nur aufwändig erweiterbar
– viele unterschiedliche Lösungen zu gleichartigen
Problemen
• deshalb: fortgeschrittene Designtechniken studieren
• aber: um fortgeschrittenes Design zu verstehen,
muss man die Umsetzung von Klassendiagrammen
in Programme kennen (dieses Kapitel)
• aber: um fortgeschrittenes Design zu verstehen,
muss man einige OO-Programme geschrieben haben
Grundkurs Software-Engineering mit UML
Stephan Kleuker
179
UML-Toolsuiten / CASE-Werkzeuge
6.1
Theorie:
• UML-Werkzeuge unterstützen die automatische Umsetzung von
Klassendiagrammen in Programmgerüste (Skelette)
• Entwickler müssen die Gerüste mit Code füllen
• viele Werkzeuge unterstützen Roundtrip-Engineering, d.h.
Änderungen im Code werden auch zurück in das Designmodell
übernommen (wenn man Randbedingungen beachtet)
• Roundtrip beinhaltet auch Reverse-Engineering
Praxis:
• sehr gute kommerzielle Werkzeuge (z. B. IBM Rational, Borland
Together); allerdings muss man für Effizienz Suite von
Werkzeugen nutzen; d. h. auf deren Entwicklungsweg einlassen
• ordentliche nicht kommerzielle Ansätze für Teilgebiete;
allerdings Verknüpfung von Werkzeugen wird aufwändig
Grundkurs Software-Engineering mit UML
Stephan Kleuker
180
Übersetzung einfacher Diagramme (1/3)
6.2
Anmerkung: auch
bei Realisierung
kann vereinbart
werden, dass getund set-Methoden
in Übersichten
weggelassen (und
damit als gegeben
angenommen)
werden
Klassenmethoden
sind unterstrichen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
181
Übersetzung einfacher Diagramme (2/3)
public class Mitarbeiter {
/**
* @uml.property name="minr"
*/
private int minr;
/**
* Getter of the property <tt>minr</tt>
* @return Returns the minr.
* @uml.property name="minr"
*/
public int getMinr() {
return minr;
}
/**
* Setter of the property <tt>minr</tt>
* @param minr The minr to set.
* @uml.property name="minr"
*/
public void setMinr(int minr) {
this.minr = minr;
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
182
Übersetzung einfacher Diagramme (3/3)
private String vorname = "";
public String getVorname() { return vorname;}
public void setVorname(String vorname) {
this.vorname = vorname;
}
private String nachname = "";
public String getNachname() {return nachname;}
public void setNachname(String nachname) {
this.nachname = nachname;
private static int mitarbeiterzaehler;
public static int getMitarbeiterzaehler() {
return mitarbeiterzaehler;
}
public static void setMitarbeiterzaehler
(int mitarbeiterzaehler) {
Mitarbeiter.mitarbeiterzaehler = mitarbeiterzaehler;
}
}
= evtl. notwendige Korrekturen, bei CASE-Werkzeug
Grundkurs Software-Engineering mit UML
Stephan Kleuker
183
Notwendige Code-Ergänzung durch Entwickler
public Mitarbeiter(String vorname, String nachname){
this.vorname=vorname;
this.nachname=nachname;
this.minr=Mitarbeiter.mitarbeiterzaehler++;
}
@Override
public String toString() {
return minr+": "+vorname+" "+nachname;
}
= vom Entwickler ergänzt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
184
Umgang mit Assoziationen im Design
6.3
• Assoziationen zunächst nur Strich mit Namen (und
Multiplizitäten)
• für Implementierung jede Assoziation konkretisieren (Richtung
der Navigierbarkeit, Multiplizitäten sind Pflicht)
public class Projektaufgabe {
/** werkzeugspezifische Kommentare weggelassen
*/
private Mitarbeiter bearbeiter;
public Mitarbeiter getBearbeiter() {
return bearbeiter;
}
public void setBearbeiter(Mitarbeiter bearbeiter) {
this.bearbeiter = bearbeiter;
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
185
Multiplizität 1
• Objekreferenz darf nie null sein
private Mitarbeiter bearbeiter = new Mitarbeiter();
• oder im Konstruktor setzen
• man sieht, default-Konstruktoren sind auch hier
hilfreich; deshalb, wenn irgendwie möglich
definieren
• Gleiche Problematik mit der Werte-Existenz, bei
Multiplizität 1..n
Grundkurs Software-Engineering mit UML
Stephan Kleuker
186
Multiplizität n (1/2)
• Umsetzung als Collection (Sammlung, Container)
• Umsetzung hängt von Art der Collection ab
– sollen Daten geordnet sein
– sind doppelte erlaubt
– gibt es spezielle Zuordnung key -> value
• Entwickler muss zur Typwahl spätere Nutzung kennen
• eine Umsetzung für 1..*
import java.util.List;
import java.util.ArrayList;
public class Projektaufgabe {
private List<Mitarbeiter> bearbeiter =
new ArrayList<Mitarbeiter>();
• bitte, bitte in Java nicht alles mit ArrayList realisieren (!!!)
• Multiplizität 0..7 als Array umsetzbar
Grundkurs Software-Engineering mit UML
Stephan Kleuker
187
Multiplizität n (2/2)
• Zum Codefragment der letzten Zeile passt besser folgendes
Klassendiagramm
*
• Hinweis: Standardhilfsklassen z. B. aus der JavaKlassenbibliothek oder der C++-STL werden typischerweise in
Klassendiagrammen nicht aufgeführt
• Anmerkung: man sieht die UML-Notation für generische (oder
parametrisierte) Klassen
• UML-Werkzeuge unterscheiden sich bei der Generierung und
beim Reverse-Engineering beim Umgang mit Collections
Grundkurs Software-Engineering mit UML
Stephan Kleuker
188
Arten der Zugehörigkeit (Aggregation 1/2)
6.4
• nicht exklusiver Teil eines Objekts (Mitarbeiter kann bei
mehreren Projektaufgaben Bearbeiter sein)
• in C++: Mitarbeiter *bearbeiter;
Mitarbeiter* Projektaufgabe::getBearbeiter(){
return bearbeiter;}
oder Mitarbeiter bearbeiter;
Mitarbeiter& Projektaufgabe::getBearbeiter(){
return bearbeiter;}
• Realisierungsproblem: Projektaufgabe kann Namen des
Bearbeiters ändern bearbeiter->setNachname("Meier");
• Kann als Verstoß gegen Kapselung (Geheimnisprinzip)
angesehen werden
• Designansatz: Klasse erhält Interface, die Methoden enthält, die
bestimmte andere Klassen nutzen können
Grundkurs Software-Engineering mit UML
Stephan Kleuker
189
Arten der Zugehörigkeit (Aggregation 2/2)
• Designansatz: Verhindern unerwünschten Zugriffs durch
Interface (generell gute Idee !)
Kurzdarstellung
Interfacerealisierer:
Grundkurs Software-Engineering mit UML
Stephan Kleuker
190
Arten der Zugehörigkeit (Komposition 1/2)
• Konkretisierung der Zugehörigkeit: existenzabhängiges Teil,
Exemplarvariable gehört ausschließlich zum Objekt (Mitarbeiter
kann [unrealistisch] nur exakt eine Projektaufgabe bearbeiten;
niemand anderes nutzt dieses Objekt)
• Realisierung in C++
Mitarbeiter bearbeiter;
Mitarbeiter Projektaufgabe::getBearbeiter (){
return bearbeiter;
}
• Bei Rückgabe wird Kopie des Objekts erstellt und zurück
gegeben
Grundkurs Software-Engineering mit UML
Stephan Kleuker
191
Arten der Zugehörigkeit (Komposition 2/2)
• Java arbeitet nur mit Zeigern (unschöne Ausnahme sind
Elementartypen), wie realisiert man
@Override // in Mitarbeiter.java
public Mitarbeiter clone(){ // echte Kopie
Mitarbeiter ergebnis= new Mitarbeiter();
ergebnis.minr=minr;
ergebnis.nachname=nachname; //Strings sind
ergebnis.vorname=vorname;
//Konstanten
return ergebnis;
}
// in Projektaufgabe
public Mitarbeiter getBearbeiter() {
return bearbeiter.clone();
}
• Variante: bei Realisierung überall doll aufpassen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
192
Kurzzeitige Klassennutzungen
• Klassen nutzen andere Klassen nicht nur für Exemplar- (und
Klassen-) Variablen
• Klassen erzeugen Objekte anderer Klassen lokal in Methoden,
um diese weiter zu reichen
public class Projektverwaltung {
private Projekt selektiertesProjekt;
public void projektaufgabeErgaenzen(String name){
Projektaufgabe pa= new Projektaufgabe(name);
selektiertesProjekt.aufgabeHinzufuegen(pa);
}
• Klassen nutzen Klassenmethoden anderer Klassen
• In der UML gibt es hierfür den „Nutzt“-Pfeil
• (Omondo: <<include>>)
• Wenn zu viele Pfeile im Diagramm, dann mehrere Diagramme mit
gleichen Klassen zu unterschiedlichen Themen
• UML-Werkzeuge unterstützen Analyse von Abhängigkeiten
Grundkurs Software-Engineering mit UML
Stephan Kleuker
193
Erstellen einer Softwarearchitektur
6.5
• Ziel des Design ist ein Modell, welches das Analysemodell
vollständig unter Berücksichtigung
implementierungsspezifischer Randbedingungen umsetzt
• allgemeine Randbedingungen: Es gibt ingenieurmäßige
Erfahrungen zum gutem Aufbau eines Klassensystems; dieses
wird auch SW-Architektur genannt
• Ziele für die Architektur
– Performance
– Wartbarkeit
– Erweiterbarkeit
– Verständlichkeit
– schnell realisierbar
– Minimierung von Risiken
Grundkurs Software-Engineering mit UML
Stephan Kleuker
194
Systematische Entwicklung komplexer Systeme
• Für große Systeme entstehen viele Klassen; bei guten Entwurf:
• Klassen die eng zusammenhängen (gemeinsame
Aufgabengebiete)
• Klassen, die nicht oder nur schwach zusammenhängen
(Verknüpfung von Aufgabengebieten)
• Strukturierung durch SW-Pakete; Pakete können wieder Pakete
enthalten
Grundkurs Software-Engineering mit UML
Stephan Kleuker
195
Typische 3-Schichten-SW-Architektur
• Ziel: Klassen eines oberen Pakets
greifen nur auf Klassen eines
unteren Paketes zu (UML-“nutzt“Pfeil)
• Änderungen der oberen Schicht
beeinflussen untere Schichten
nicht
• Analysemodell liefert
typischerweise nur Fachklassen
• Datenhaltung steht für Persistenz
• typisch Varianten von 2 bis 5
Schichten
• Klassen in Schicht sollten
gleichen Abstraktionsgrad haben
• Schicht in englisch „tier“
• obere und untere Schichten
können stark von speziellen
Anforderungen abhängen (später)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
196
Beispiel: grobe Paketierung (eine Variante)
• Anmerkung: Datenverwaltung noch nicht konzipiert
Grundkurs Software-Engineering mit UML
Stephan Kleuker
197
Beispiel: grobe Paketierung (zweite Variante)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
198
Forderung: azyklische Abhängigkeitsstruktur
Grundkurs Software-Engineering mit UML
Stephan Kleuker
199
Umsetzung von Paketen in Java und C++
package fachklassen.projektdaten;
import fachklassen.projektmitarbeiter.Mitarbeiter;
public class Projektaufgabe {
private Mitarbeiter bearbeiter;
/* ... */
}
#include "Mitarbeiter.h" //evtl. mit Dateibaum
using namespace Fachklassen::Mitarbeiterdaten;
namespace Fachklassen{
namespace Projektdaten{
class Projektaufgabe{
private:
Mitarbeiter *bearbeiter; // ...
};
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
200
Paketabhängigkeiten optimieren
• Ziel ist es, dass Klassen sehr eng
zusammenhängen; es weniger Klassen gibt, die eng
zusammenhängen und viele Klassen und Pakete, die
nur lose gekoppelt sind
• Möglichst bidirektionale oder zyklische
Abhängigkeiten vermeiden
• Bei Paketen können Zyklen teilweise durch die
Verschiebung von Klassen aufgelöst werden
• Wenig globale Pakete (sinnvoll für projektspezifische
Typen (z. B. Enumerations) und Ausnahmen)
• Es gibt viele Designansätze, Abhängigkeiten zu
verringern bzw. ihre Richtung zu ändern
Grundkurs Software-Engineering mit UML
Stephan Kleuker
201
Trick: Abhängigkeit umdrehen
• generell können Interfaces häufiger in anderen Paketen liegen,
als ihre Implementierer
• Java-Klassenbibliothek Swing fordert häufig die InterfaceImplementierung bei der Ereignisbehandlung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
202
Architektursichten
6.6
• Paket- und Klassendiagramme geben einen guten
Überblick über die Ergebnisse des statischen SWEntwurfs
• Es gibt aber mehr Sichten (Betrachtungsweisen), die
für eine vollständige SW-Architektur relevant sind
• z. B. wurde die HW des zu entwickelnden Systems
noch nicht berücksichtigt
• Diese Sichten müssen zu einem System führen;
deshalb müssen sich Sichten überlappen
• z. B. eigenes Diagramm mit Übersicht über
eingesetzte Hardware und Vernetzung; dazu
Information, welche SW wo laufen soll
Grundkurs Software-Engineering mit UML
Stephan Kleuker
203
4+1 Sichten
Logische Sicht
- funktionale Analyseergebnisse
- Klassenmodell
Implementierungssicht
- Subsysteme
- Schnittstellen
Szenarien
Ablaufsicht
- Prozesse
- Nebenläufigkeit
- Synchronisation
Grundkurs Software-Engineering mit UML
Physische Sicht
- Zielhardware
- Netzwerke
Stephan Kleuker
204
4+1 Sichten mit (Teilen der) UML
Logische Sicht
- Klassendiagramme
- Paketdiagramme
Implementierungssicht
- Komponentendiagramme
Szenarien
-Use Case-Diagramme
- Aktivitätsdiagramme
Ablaufsicht
- Sequenzdiagramme
Physische Sicht
- Kommunikations- Deploymentdiagramme
- Zustandsdiagramme
diagramme
Grundkurs Software-Engineering mit UML
Stephan Kleuker
205
Ablaufsicht
• wichtig für verteilte Systeme; bzw. Systeme, die
verteilt (auch auf einem Rechner) laufen
• Festlegen der Prozesse
• Festlegen etwaiger Threads
• so genannte aktive Klassen; werden Objekte dieser
Klassen gestartet, so starten sie als eigenständige
Prozesse/Threads
AktiveKlasse
aktivesObjekt:
AktiveKlasse
• Prozessverhalten u. a. durch Sequenzdiagramme
beschreibbar
• (übernächste VL etwas mehr; gibt eigenes Modul
dazu)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
206
Implementierungssicht
• Das Designmodell muss physikalisch realisiert
werden; es muss eine (ausführbare) Datei entstehen
• Pakete fassen als Komponenten realisiert Klassen
zusammen
• häufig werden weitere Dateien benötigt: Bilder,
Skripte zur Anbindung weiterer Software,
Installationsdateien
• Komponenten sind austauschbare Bausteine eines
Systems mit Schnittstellen für andere Komponenten
• Typisch ist, dass eine Komponente die Übersetzung
einer Datei ist
• Typisch ist, dass eine Komponente die Übersetzung
eines Pakets ist; in Java .jar-Datei
Grundkurs Software-Engineering mit UML
Stephan Kleuker
207
Komponentendiagramm
• Bilder zeigen zwei alternative
Darstellungen
• Komponenten bieten
Schnittstellen(realisierungen) (Kreis) und
benötigen Schnittstellen(realisierungen)
(Halbkreis)
• Komponenten können über Schnittstellen
in Diagrammen verknüpft werden
• in die Komponenten können die
zugehörigen Klassen eingezeichnet
werden
• Ports erlauben den Zugriff auf bestimmten
Teil der Klassen und Interfaces (nicht im
Diagramm)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
208
Physische Sicht: vorgegebene HW mit Vernetzung
• Einsatz- und Verteilungsdiagramm (deployment diagram)
• Knoten steht für physisch vorhandene Einheit, die über
Rechenleistung oder/und Speicher verfügt
• <<executable>> (ausführbare Datei) und <<artifact>> (Datei)
müssen zur HW-Beschreibung nicht angegeben werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
209
7. Konkretisierungen im
Feindesign
7.1 Zustandsdiagramme
7.2 Object Constraint Language
Grundkurs Software-Engineering mit UML
Stephan Kleuker
210
Verfeinerte Modellierung
• Durch die verschiedenen Sichten der Systemarchitektur wird
der Weg vom Anforderungsmodell zur Implementierung
beschrieben
• Es bleiben offene Themen:
– Wie bekomme ich ein gutes Klassendesign (nächstes
Kapitel)?
– Wie kann man das komplexe Verhalten von Objekten noch
beschreiben (Klassendiagramme sind statisch,
Sequenzdiagramme exemplarisch)?
Antwort: Zustandsdiagramme
– Wie kann man bei der Klassenmodellierung
Randbedingungen formulieren, was in Klassendiagrammen
(Bedingungen in geschweiften Klammern) nur bedingt
möglich ist?
Antwort: Object Constraint Language
Grundkurs Software-Engineering mit UML
Stephan Kleuker
211
Zustandsdiagramme
7.1
• generell wird der Zustand eines Objekts durch die Werte seiner
Exemplar- und Klassenvariablen beschrieben
• Häufig wird der Begriff Zustand auch für eine spezielle
Exemplarvariable genutzt, die z. B. über eine Enumeration
realisierbar ist
• z. B. : Ampel: rot, rotgelb, gelb, grün
• z. B. : Projekt: vorbereitet, grob geplant, Mitarbeiter zugeordnet,
verschoben, in Bearbeitung, in Endabnahme, in
Gewährleistung, beendet
• Die Übergänge zwischen den Zuständen werden durch
Ereignisse, zumeist Methodenaufrufe, veranlasst
• Die Übergänge lassen sich durch ein Zustandsdiagramm
(ursprünglich Statechart nach D. Harel) spezifizieren
• Zustandsautomaten spielen auch in der theoretischen und
technischen Informatik eine zentrale Rolle
Grundkurs Software-Engineering mit UML
Stephan Kleuker
212
Struktur von Zustandsdiagrammen
• Zustandsdiagramm gehört zu einem Objekt einer Klasse
• alle Angaben für Zustände und Transitionen sind Optional
• Transition wird ausgeführt, wenn Ereignis eintritt und
Bedingung erfüllt ist
• ohne Ereignis und Bedingung wird Transition dann ausgeführt,
wenn Entry, Do, und Exit durchlaufen
• Einfacher Automat muss deterministisch sein
Grundkurs Software-Engineering mit UML
Stephan Kleuker
213
Beispiel: Zustandsdiagramm eines Projekts
• man erkennt: nach Planung keine Planungsänderung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
214
Hierarchische Zustände
Grundkurs Software-Engineering mit UML
Stephan Kleuker
215
Parallele Unterzustände
• unabhängige Teilzustände
können in parallelen
Zuständen bearbeitet
werden
• ohne Parallelität müsste
Kreuzprodukt der
Zustände der parallelen
Automaten betrachtet
werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
216
Beispiel: Uhr
Grundkurs Software-Engineering mit UML
Stephan Kleuker
217
Zustandsmodellierung und Realzeitsysteme
• in klassischen OOProgrammen gibt es
meist wenige zentrale
Klassen, für die sich
eine
Zustandsmodellierung
anbietet
• In Systemen mit Zeit
kann
Zustandsmodellierung
Zeitbedingungen
beinhalten
• auch warte(5 sek)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
218
Event [Condition] / Action
• Transitionsbeschriftung Ereignis[Bedingung]/Aktion
• Was ist Ereignis? Hängt von Applikation ab
– Methodenaufruf
– Ereignis im Programm (Variable wechselt Wert)
– technische Systeme: Signale
typisches Beispiel: Steuersysteme
• erhalten Signale (->Ereignisse) von Sensoren wenn
etwas passiert (z. B. ein-/ausgeschaltet)
• lesen Werte anderer Sensoren, Teilsysteme
(-> Bedingung), die Entscheidungen
beeinflussen
• senden Signale (-> Aktion) an andere Systeme
Grundkurs Software-Engineering mit UML
Stephan Kleuker
219
Microsteps und Macrosteps (1/2)
• Actions eines Teilautomaten können Events eines
anderen Teilautomaten sein
• Microstep: einzelne Schritte betrachten
Start -> K(A1,B1) –p-> K(A2,B1) –x-> K(A2,B2) –q->
K(A3,B2) –y-> K(A3,B3) –z-> K(A3,B1) –r-> K(A1,B1)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
220
Microsteps und Macrosteps (2/2)
• Macrostep: nur Zustände nach vollständiger
Bearbeitung betrachten (Ausnahme: Livelock)
Start -> K(A1/B1) –p-> K(A3/B3) –z-> K(A1/B1)
• typischerweise nur an Macrosteps interessiert
Grundkurs Software-Engineering mit UML
Stephan Kleuker
221
Beispiel: Start-Stopp-Automatik (1/3)
• zentrale Aufgabe: Start-Stopp-Automatik stellt den
Motor immer dann selbstständig aus, wenn dieser
nicht mehr benötigt wird (z. B. Halt an Ampel)
• Randbedingung: keine Abschaltung bis maximal 3
Grad und ab minimal 30 Grad
• Ablauf:
– Zündschlüssel einstecken, Motorstartknopf
drücken, dann startet Automatik
– Motorein- und Abschaltung wird anhand der
Kupplung erkannt
– Automatik kann auch wieder gestoppt werden
• [Frage: was fehlt alles zur Realität]
Grundkurs Software-Engineering mit UML
Stephan Kleuker
222
Beispiel: Start-Stopp-Automatik (2/3)
• Klärung, von welche Sensoren werden Signale
empfangen:
– Zündschloss: start und ende
– Kupplung: leerlauf und druecken
– Automatiksteuerung: an und aus
• Klärung, welchen Sensoren können abgefragt werden:
– Temperaturwert temp in lokaler Variablen
• Klärung an welche Sensoren Signale geschickt
werden
– Motorsteuerung: motor_an und motor_aus
Grundkurs Software-Engineering mit UML
Stephan Kleuker
223
Beispiel: Start-Stopp-Automatik (3/3)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
224
GUI als Zustandsdiagramm
Grundkurs Software-Engineering mit UML
Stephan Kleuker
225
Android als Zustandsdiagramm
Grundkurs Software-Engineering mit UML
Stephan Kleuker
226
Umsetzung von Zustandsdiagrammem
• Abhängig davon, wie formal die Zustände und Transitionen
spezifiziert sind, kann aus Zustandsdiagrammen
Programmcode erzeugt werden
• Typisch: Iteratives Vorgehen: informelle Beschreibungen
werden schrittweise durch formalere ersetzt
• Ereignisse können für folgendes stehen
– Methodenaufrufe
– externe Ereignisse des GUI (-> Methodenaufruf)
– Teilsituation, die bei der Abarbeitung einer Methode
auftreten kann
• Automat wird zunächst zu komplexer Methode, die z. B. anhand
der Zustände in Teilmethoden refaktoriert werden kann
Grundkurs Software-Engineering mit UML
Stephan Kleuker
227
Klassendiagramm und versteckte Randbedingungen
7.2
• Welche Randbedingungen vermuten Sie?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
228
Grundidee von Object Constraint Language (OCL)
• Rahmenbedingungen (Constraints) definieren, die
von Objekten bzw. Objektmengen eingehalten
werden können
• Constraints sind prüfbar
• möglichst einfach formulierbar (ursprünglich zur
Formulierung von Geschäftsregeln für
Versicherungsanwendungen, [Syntropy, IBM])
• Angepasst an Objektorientierung:
– Zugriff auf Exemplarvariablen
– Zugriff auf Methoden, die keine
Objektveränderungen vornehmen
– Vererbung wird beachtet
• typisiert, Collections wichtiger Typ
Grundkurs Software-Engineering mit UML
Stephan Kleuker
229
Einfache Bedingungen für Objekte (Invarianten)
• Die Matrikelnummer ist mindestens 10000
context Studi inv hoheMatrikelnummern:
self.matnr>=10000
• eine Variante:
context s:Studi inv:
s.matnr>=10000
• context gibt eindeutig an, um welche Klasse es
geht
• Strukturierung durch Nutzung der Paketstruktur
package com::meineFirma::meineSW
context Studi inv: ...
context Studi inv: ...
endpackage
Grundkurs Software-Engineering mit UML
Stephan Kleuker
230
Vor- und Nachbedingungen für Methoden
• Wenn Studi da, dann hört er Veranstaltungen
context Studi::belegteVeranstaltungen():Integer
pre studiIstDa: self.freisemester=false
post hoertVeranstaltungen: result>0
• Man kann auf Parameter der Methoden zugreifen
• result ist vordefiniert (vom Rückgabetyp)
• Erhöhung der Anzahl der belegten Veranstaltungen:
context Studi::veranstaltungEintragen(v:
Veranstaltung)
pre: nichtBelegt(v)
post: self.belegteVeranstaltungen()@pre=
self.belegteVeranstaltungen()-1
• self.belegteVeranstaltungen()@pre, für Ergebnis vor der
Methodenausführung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
231
Einschub: Basistypen und Operationen
• Jeder OCL-Ausdruck hat einen Typ
• Verknüpfe Ausdrücke müssen vom Typ her passen
• Geringe Typanpassungen möglich
Typ
Beispielwerte
Boolean
true, false
Integer
1, -5, 42, 4242424242
Real
3.14, 42.42, -99.999
String
'Hallo Again', 'Heidi', ''
Typ
Beispieloperationen
Boolean and,or,xor,not,implies,if then else endif
Integer *, +, -, /, abs()
Real
*, +, -, /, floor()
String
concat(), size(), substring()
Grundkurs Software-Engineering mit UML
Stephan Kleuker
232
Zugriff auf Assoziationen
• Zugriff auf verbundene Elemente möglich,
Kardinalitäten beachten (einfach oder Menge)
• wenn Relation benannt, dann dieser Name
sonst über Name der verbundenen Klasse (klein)
• Profs laufender Veranstaltungen sind nicht im
Ausland
context Veranstaltung inv:
self.status = Veranstaltungsstatus::laeuft
implies
not self.prof.imAusland
• Man sieht auch Zugriff auf eine Enumeration
Grundkurs Software-Engineering mit UML
Stephan Kleuker
233
Assoziationsklassen
• Ausgehend von Assoziationsklassen kann mit
Punktnotation auf beteiligte Klassen (deren Objekte)
mit deren Rollennamen zugegriffen werden
• Prüfungsnoten nur für abgeschlossene
Veranstaltungen
context Pruefung inv:
self.studienfach.status =
Veranstaltungsstatus::abgeschlossen
implies
(self.note>=1.0 and self.note<=5.0)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
234
Beispiele: Mengenoperationen (1/2)
• bei der Betrachtung zugehöriger Objekte ist das Ergebnis meist
eine Collection von Objekten
• in OCL auch: Set, OrderedSet, Sequence, Bag
• auf Collections existieren verschiedene Methoden, genereller
Aufruf
collection -> methode(<parameter>)
• Ergebnis kann wieder eine Collection oder ein Wert eines
anderen Typs sein
• Studi macht höchstens 12 Veranstaltungen
context Studi inv:
studi.studienfach
-> select (s | s.status =
Veranstaltungsstatus::laeuft)
-> size() <= 12
Grundkurs Software-Engineering mit UML
Stephan Kleuker
235
Beispiele: Mengenoperationen (2/2)
• Korrektheit von hatTheorieBestanden
context Studi::hatTheorieBestanden():Boolean
post: result = self.pruefung
-> exists( p | p.note<=4.0
and p.studienfach.titel='Theorie'))
• Korrektheit für bestandeneVeranstaltungen
context Studi::
bestandeneVeranstaltungen():Collection
post: result=self.pruefung
->select( p | p.note<=4.0)
->iterate(p:Pruefung;
erg:Collection=Collection{}|
erg->including(p.studienfach))
Grundkurs Software-Engineering mit UML
Stephan Kleuker
236
8. Optimierung des
Designmodells
8.1
8.2
8.3
8.4
Design im Kleinen
Model View Controller
Vorstellung einiger GoF-Pattern
Abschlussbemerkungen zu Pattern
Grundkurs Software-Engineering mit UML
Stephan Kleuker
237
Zentrale Aufgabe: von Analyse zum Design (1/2)
• Analyse der Klassen:
– haben sie klar definierte Aufgabe
– können Klassen vereinigt werden
– sollten Klassen aufgeteilt werden
– welche Optimierungen sind aus Design-Sicht
möglich? (zentrale Frage, untersuchen wir weiter)
• Exemplar- und Klassenvariablen müssen Typen
haben
• Variablen und Methoden brauchen Sichtbarkeiten
• Methoden brauchen Rückgabe- und Parametertypen
(Signaturen); in Java und C++ spielen Ausnahmen
eine Rolle
Grundkurs Software-Engineering mit UML
Stephan Kleuker
238
Zentrale Aufgabe: von Analyse zum Design (2/2)
• für Assoziationen
– Multiplizitäten beachten
– über mögliche Richtungen nachdenken
– Art der Zugehörigkeit klären
• GUI-Klassen und persistente Datenhaltung einbauen
• Anmerkung 1: Übergang von Analyse zu Design ist
durch Iterationen (Verfeinerungen) fließend
• Anmerkung 2: Die vorgestellten Regeln sind häufig
90-10 Regeln (in 90% müssen sie angewandt werden,
bei Verstößen muss man argumentieren können,
warum)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
239
Einfache Basisregeln
8.1
• KISS = Keep It Simple Stupid, man soll die einfachst
mögliche Realisierung wählen, die das Problem
vollständig löst und gut nachvollziehbar ist (kein
„Quick and Dirty“, sondern eine klare Entscheidung
für einen einfachen Entwicklungsstil)
• YAGNI = You Ain’t Gonna Need It, keine
Verallgemeinerungen entwickeln, die das Design für
theoretisch in der Zukunft vielleicht gewünschte
Erweiterungen vereinfachen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
240
Keine allwissenden Klassen
ändere Fertigstellungsgrad einer Projektaufgabe
besser:
Grundkurs Software-Engineering mit UML
Stephan Kleuker
241
Korrekte Methodenplatzierung
• Objekte sollen genau die Aufgaben übernehmen, für die sie
Kenntnisse haben
• falscher Ansatz: allwissende Objekte saugen alles Wissen aus
Exemplarvariablen und verarbeiten es
• Beispiel: Klasse Dominostein mit Exemplarvariablen links und
rechts (Steine können nicht gedreht werden)
• Klasse Spiel mit Exemplarvariable mitte, einem Stein, an dem
angelegt werden soll
• Spiel benötigt Methode, die für einen zweiten Stein prüft, ob
dieser angelegt werden kann
• schlecht:
bool Spiel::ablegbar(Dominostein d){
return d.getLinks()==mitte.getRechts
|| d.getRechts()==mitte.getLinks();
}
• gut:
bool Dominostein::anlegbar(Dominostein d){
return links==d.rechts || rechts==d.links;
} // in Spiel dann mit mitte.anlegbar(d) prüfen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
242
„Verpacken“ von Exemplarvariablen (Aggregation)
• Generell kann man für Exemplarvariablen vom Typ X statt einer
get-Methode alle Methoden von X anbieten, die man an die
Exemplarvariable weiterleiten will.
• Ansatz auch für Collections geeignet
• XNutzer: Aufrufe an x weiterleiten (Methoden
müssen nicht gleich heißen)
public int getA(){
return x.getA();
}
public void setA(int a){
x.setA(a);
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
243
Erinnerung: Bedeutung von Schnittstellen
• Schnittstellen sind zentrales Element des Design by Contract
• vorgegebene Aufgabe: Implementiere mir folgende
Funktionalität ... beschrieben durch
– Vorbedingung
– Signatur <Sichtbarkeit> <Methodenname>(<Parameter>)...
– Nachbedingung
• Entwickler realisiert OO-Programm (Details sind frei)
• Entwickler garantiert, dass Schnittstelle (oder Fassade)
gewünschte Funktionalität liefert
• generell sollte man bei Vererbungen und Implementierungen
die am wenigsten spezielle benötigte Klasse nutzen; deshalb
List<Projektaufgaben> aufgaben
und nicht
ArrayList<Projektaufgaben> aufgaben im Code
Grundkurs Software-Engineering mit UML
Stephan Kleuker
244
Design by Contract
Grundkurs Software-Engineering mit UML
Stephan Kleuker
245
Dependency Injection
woher kommen Objekte für Exemplarvariablen?
• Variante 1: Werte werden als Parameter übergeben,
aus denen Objekte gebaut werden
• Variante 2: Objekte werden als Referenzen
übergeben
– Optimierung: Typen der Objektvariablen sind
Interfaces; so konkrete Objekte leicht
austauschbar
• Variante 2 heißt Dependency Injection mit get- und
set-Methoden oder über Konstruktoren
Grundkurs Software-Engineering mit UML
Stephan Kleuker
246
Dependency Injection - Beispiel
Inter1
Inter2
Inter3
Nutzer
inter1
inter2
inter3
nutzer
=
=
=
=
new
new
new
new
Grundkurs Software-Engineering mit UML
Inter1RealA(42);
Inter2RealC(43);
Inter3RealD("Hallo");
Nutzer(inter1, inter2, inter3);
Stephan Kleuker
247
Erinnerung: Bedeutung von Polymorphie (1/2)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
248
Erinnerung: Bedeutung von Polymorphie (2/2)
8Rechteck:
273
#include <iostream>
5Kreis:
201.062
8Rechteck:
56
#include <typeinfo>
5Kreis:
50.2655
#include "Rahmen.h"
6RahmenI8RechteckS0_E:
217
#include "Rechteck.h"
6RahmenI8Rechteck5KreisE: 222.735
#include "Kreis.h"
6RahmenI5Kreis8RechteckE: 145.062
6RahmenI5KreisS0_E: 150.796
int main(void){
Rechteck re1(Punkt(6,16),Punkt(27,3));
Kreis k1(Punkt(15,9),8);
Rechteck re2(Punkt(12,13),Punkt(19,5));
Kreis k2(Punkt(15,9),4);
Rahmen<Rechteck,Rechteck> r1(re1,re2);
Rahmen<Rechteck,Kreis> r2(re1,k2);
Rahmen<Kreis,Rechteck> r3(k1,re2);
Rahmen<Kreis,Kreis> r4(k1,k2);
GeoObjekt *g[8]={&re1,&k1,&re2,&k2,&r1,&r2,&r3,&r4};
for(int i=0;i<8;i++)
std::cout<<typeid(*g[i]).name()<<":\t„
<<g[i]->flaeche()<<"\n";
return 0;
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
249
Umgang mit Collections
• Collections sollen als Rückgabeparameter vermieden werden,
damit nicht alle Collection-Methoden nutzbar sind
• Ansatz: Iteratoren auf Listen zurück geben
• Java: Interface Iterable implementieren
public interface Iterable<T>
Implementing this interface allows an object to be the target of the "foreach" statement.
Method Summary
Iterator<T> iterator() Returns an iterator over a set of elements of type T.
• Methode gibt dann (schon implementierten) Iterator der
Collection zurück
• Iterator leicht selbst zu implementieren, mit Methoden
boolean hasNext() Returns true if the iteration has more elements.
E next() Returns the next element in the iteration.
void remove() Removes from the underlying collection the last
element returned by the iterator (optional operation).
Grundkurs Software-Engineering mit UML
Stephan Kleuker
250
Method Chaining (1/3)
• immer sinnvolle Rückgabe nutzen; wenn wählbar
wird statt void Objekt selbst zurück gegeben (this)
• verstößt klar gegen Command-Query Separation
• Beispiel Integer-Menge
public class Main {
public static void main(String[] args) {
IntMenge tmp = new IntMenge();
tmp = tmp.hinzu(new int[]{1,21,11,41,31,1})
.kleinerAls(41).groesserAls(11);
System.out.println(tmp);
}
}
[21, 31]
Grundkurs Software-Engineering mit UML
Dr. Stephan Kleuker
251
Method Chaining (2/3)
public class IntMenge {
private Set<Integer> menge = new HashSet<>();
public IntMenge(){ }
public IntMenge hinzu(int... wert){
for(int w:wert){
this.menge.add(w);
}
return this; // hier sieht man Chaining
}
public IntMenge kleinerAls(int grenze){
IntMenge ergebnis = new IntMenge();
for(int w:this.menge){
if(w < grenze){
ergebnis.hinzu(w);
}
}
return ergebnis;
}
Grundkurs Software-Engineering mit UML
Dr. Stephan Kleuker
252
Method Chaining (3/3)
public IntMenge groesserAls(int grenze){
IntMenge ergebnis = new IntMenge();
for(int w:this.menge){
if(w > grenze){
ergebnis.hinzu(w);
}
}
return ergebnis;
}
public boolean beinhaltet(int wert){
return this.menge.contains(wert);
}
@Override
public String toString(){
return this.menge.toString();
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
253
Grundidee von Design-Pattern
8.2
Damit nicht alle Klassen eng miteinander gekoppelt sind, gibt es
Ansätze:
• die Aufgaben einer Klasse von der Verwaltung der Klassen, die
Informationen dieser Klasse benötigen, zu trennen
• die Erzeugung von Objekten möglichst flexibel zu gestalten
• Interfaces zur Trennung von Implementierung und
angebotenen Methoden einzusetzen
• Hierzu werden so genannte Design-Pattern eingesetzt, die für
einen bestimmten Aufgabentyp eine flexible Lösung
vorschlagen
• oft zitiert: E. Gamma, R. Helm, R. Johnson, J. Vlissides,
Entwurfsmuster, Addison-Wesley, 2004 (Gang of Four [GoF]Buch, hier neuere Auflage)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
254
Model-View-Controller
• Typisch für graphische Oberflächen ist, dass es Objekte zur
Eingabe gibt, die zur Bearbeitung der eigentlichen
Inhaltsklasse führen, die dann eventuell zu Änderung der
Anzeige führen
• Die Aufteilung in die drei genannten Aufgaben führt zum ModelView-Controller (MVC)-Ansatz
• MVC wurde zuerst in Smalltalk Ende der 80'er des vorigen
Jahrhunderts eingesetzt:
– Model: Zustandsinformation der Komponente
(Inhaltsklasse)
– View: Beobachter des Zustands, um diesen darzustellen; es
kann viele Views geben
– Controller: Legt das Verhalten der Komponente auf
Benutzereingaben fest
• Idee: Controller steuert Änderungen des Modells, Modell teilt
allen Views mit, dass eine Änderung aufgetreten ist
• Hinweis: Spezielle Form des Beobachter-Musters (Observer)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
255
Java-Beispiel zum MVC (1/6)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
256
Java-Beispiel zum MVC (2/6)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
257
Java-Beispiel zum MVC (3/6)
import java.util.*;
public class XModel{
private ArrayList<XModelListener> listener =
new ArrayList<XModelListener> ();
private int modellwert = 42;
//Verwaltung der Listener des Modells
public void addXModelListener(XModelListener x){
this.listener.add(x);
}
private void fireXModelChanged(){
for(XModelListener x:this.listener)
x.xModelChanged();
}
//Auslesen der Modellinhalte
public int getWert(){
return this.modellwert;
}
//Veränderung des Modells
public void changeValue(int delta){
this.modellwert += delta;
fireXModelChanged();
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
258
Java-Beispiel zum MVC (4/6)
import javax.swing.*;
public class XView extends JFrame implements XModelListener{
private XModel xmodel;
private JLabel jlabel = new JLabel("Modellwert:
");
public XView(XModel x){
super("Ich bin der View");
this.xmodel = x;
this.xmodel.addXModelListener(this);
//Rest Swing für Anzeige
getContentPane().add(this.jlabel);
setDefaultCloseOperation(EXIT_ON_CLOSE);
setSize(250,60);
setLocation(0,0);
setVisible(true);
}
}
public void xModelChanged() {
this.jlabel.setText("Modellwert: "
+ this.xmodel.getWert());
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
259
Java-Beispiel zum MVC (5/6)
import java.awt.FlowLayout;
import java.awt.event.*;
import javax.swing.*;
public class XController extends JFrame{
private XModel xmodel;
public XController(XModel x){
super("Ich bin der Controller");
this.xmodel = x;
getContentPane().setLayout(new FlowLayout());
JButton plus = new JButton("plus");
getContentPane().add(plus);
plus.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e){
this.xmodel.changeValue(1);
}});
JButton minus = new JButton("minus");
getContentPane().add(minus);
minus.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e){
this.xmodel.changeValue(-1);
}});
setDefaultCloseOperation(EXIT_ON_CLOSE);
setSize(250,60); setLocation(0,90);´setVisible(true);
}
Grundkurs Software-Engineering mit UML
}
Stephan Kleuker
260
Java-Beispiel zum MVC (6/6)
public interface XModelListener {
public void xModelChanged();
/* Anmerkung: alternativ kann man auch geänderte
Werte als Parameter übertragen */
}
public class XStarter {
public static void main(String[] args) {
XModel x = new XModel();
new XView(x);
new XController(x);
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
261
Pattern-Varianten
Pattern schlagen eine mögliche Lösung vor; kann in
Projekten variiert werden
• Interface weglassen, wenn nur eine View-Art
• Aufteilung auch sinnvoll, wenn nur ein View existiert
(klare Aufgabentrennung)
• wenn Controller und View eng verknüpft, können sie
vereinigt werden, z. B. GUI-Elemente in Java-Swing
• Listenerverwaltung kann vom Model in Controller
verlegt werden
• auch ohne Listen ist MVC-Aufteilung sinnvoll
4: neue Darstellung
View
Controller
1: Nutzereingabe
Grundkurs Software-Engineering mit UML
2: Eigenschaften aktualisieren
3: Aktualisierung
Stephan Kleuker
Model
262
Ansatz Observer-Observable
8.3
• Es gibt Subjekte für deren Zustand sich viele
interessieren (z. B. Nachrichtenkanäle)
• Die Subjekte bieten die Möglichkeit, dass sich
Interessenten anmelden (z. B. Kanal abonnieren)
• Bei jeder Subjektzustandsänderung werden
Interessenten informiert (neue Nachrichten)
• Interessent muss sich bei Subjekt anmelden
• Damit obiges Objekt weiß, wie Interessent
angesprochen werden soll, muss Interessent
Schnittstelle realisieren
• Hinweis: Enge Verwandtschaft zu Model-ViewController
Grundkurs Software-Engineering mit UML
Stephan Kleuker
263
Beobachter (Observer – Observable)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
264
Pattern und Varianten
• Für fast jeden Pattern gibt es Varianten, die abhängig
von Randbedingungen sinnvoller sein können
Bsp.: Wertänderung mit aktualisieren übertragen
Bsp.: Java hat keine Mehrfachvererbung
• Subjekt wird Interface
• Listenverwaltung in
Hilfsklasse
• Konkretes Subjekt
delegiert Listenaufgaben an Objekt
der Hilfsklasse
Grundkurs Software-Engineering mit UML
Stephan Kleuker
265
Adapter - Problem
Szenario:
• Klasse IchBrauchB benötigt ein Objekt der Klasse B, genauer
spezielle Funktionalität (Methode) der Klasse B
• Wir haben bereits eine Klasse C, die die von IchBrauchB von B
geforderte Funktionalität anbietet
• C bietet die gewünschte Funktionalität unter dem falschen
Methodennamen an, da C Teil einer komplexen
Klassenstruktur ist, kann C nicht verändert werden
Lösung:
• Schreibe Adapterklasse, die sich wie B verhält (von B erbt bzw.
Interface B implementiert) und Objekt der Klasse C aggregiert
• Adapter leitet Aufruf der von IchBrauchB gewünschten
Funktionalität an C weiter
Grundkurs Software-Engineering mit UML
Stephan Kleuker
266
Adapter - Lösung
public class Adapter implements B{
private C c = null;
...
public Adapter(){
c = new C();
}
...
@Override
public void machWasTolles(){
return c.kannWasWasAuchBKoennenSoll();
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
267
Fassade nach außen
• Generell sollen Klassen eng zusammenhängend sein, z. B. Methoden können nicht
auf mehrere Klassen verteilt werden.
• anderen Nutzern möchte man nur eine
einfache externe Sicht bieten, deshalb
liefern zusammenhängende Klassen
häufiger eine Fassadenklasse
(„davorgeklatscht“) nach außen.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
268
Beispielanwendung: Abstract Factory Pattern
Grundkurs Software-Engineering mit UML
Stephan Kleuker
269
Ausschnitt aus möglichem Code
public class Verpackung{
private Spielefabrik fabrik=null;
private Spielbrett brett=null; //
private Spielfigur figur=null;
public Verpackung(Spielefabrik sf){
fabrik=sf;
brett=fabrik.getSpielbrett();
figur=fabrik.getSpielfigur();
}
...
public int berechneVolumen(){
return
brett.getFlaeche()*figur.getHoehe();
}
...
}
Vorteil: Leichte Ergänzung neuer Spiele, mit Spielbrettern und
Spielfiguren
Nachteil: Aufwändig neue Objektart, z. B. Spielanleitung, zu
ergänzen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
270
Einsatzmöglichkeiten von Sichtbarkeiten
• Standard-OO-Programmierung: Exemplarvariablen private
[oder protected], Exemplarmethoden public (analog für
Klassenvariablen und –methoden)
• In Spezialfällen können Sichtbarkeiten geändert werden,
Beispiel:
– Im gesamten System gibt es ein Objekt, mit dem die
Verbindung zu anderen Systemen aufgebaut wird
– Wird das Objekt das erste Mal benötigt, wird es erzeugt, bei
weiteren Anfragen werden Referenzen auf dieses identische
Objekt zurück gegeben
• Objekt muss in Klassenvariable gespeichert werden
• Nutzer dürfen keine Konstruktoren aufrufen, da es sonst
verschiedene Objekte gibt (Konstruktoren werden
private)
• Zugriff auf das Objekt über Klassenmethoden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
271
Singleton (1/3)
public class Singleton {
private int x = 0;
private int y = 0;
private static Singleton pkt = null; // einziges
//Exemplar
private Singleton(int x, int y){
this.x = x;
this.y = y;
}
public static Singleton getPunkt(){
if (pkt==null) // ein einziges Mal erzeugen
pkt= new Singleton(6,42);
return pkt;
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
272
Singleton (2/3)
@Override
public Singleton clone(){
//echtes Kopieren verhindern
return this;
}
public void ausgeben(){
System.out.print("["+this.x+","+this.y+"]");
}
public void verschieben(int dx, int dy){
this.x += dx;
this.y += dy;
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
273
Singleton (3/3)
public class Main {
public static void main(String[] s){
Singleton p1=Singleton.getPunkt();
Singleton p2=Singleton.getPunkt();
// Singleton sing= new Singleton();
//constructor not visible
p1.ausgeben();
p2.ausgeben();
if(p1==p2)
System.out.println("\n identisch");
p1.verschieben(3,5);
[6,42][6,42]
p1.ausgeben();
identisch
p2.ausgeben();
[9,47][9,47]
Singleton p3=p1.clone();
identisch
if(p2==p3)
System.out.println("\n identisch");
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
274
Proxy
• Beim Proxy (oder Stellvertreter)-Pattern wird der Zugriff auf
eine „wertvolle“ Ressource durch eine vorgeschaltete Klasse
gesteuert
• Nutzer des Proxys nutzen diesen wie die eigentliche Klasse
Grundkurs Software-Engineering mit UML
Stephan Kleuker
275
Proxy – Implementierungsmöglichkeit (1/2)
public interface KlasseMitWertvollemInhalt {
public int anfrage(String details);
}
public class RealeKlasse implements
KlasseMitWertvollemInhalt {
private Verbindung verbindung;
public RealeKlasse(String verbindungsdaten){
verbindung=new Verbindung(verbindungsdaten);
}
public int anfrage(String details) {
return verbindung.befragen(details);
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
276
Proxy – Implementierungsmöglichkeit (2/2)
public class Proxy implements KlasseMitWertvollemInhalt {
//Variante mit Singleton (gibt Alternativen)
private static RealeKlasse realesObjekt;
public Proxy(){
if(realesObjekt==null)
realesObjekt= new RealeKlasse("Spezialinfos");
}
public int anfrage(String details) {
return realesObjekt.anfrage(details);
}
}
public class Nutzer {
public int proxyNutzen(String anfrage){
KlasseMitWertvollemInhalt k=new Proxy();
return k.anfrage(anfrage);
}
public static void main(String[] s){
//etwas sinnlos, zu Testzwecken
Nutzer n= new Nutzer();
System.out.println(n.proxyNutzen("gib41"));
}
Grundkurs Software-Engineering mit UML
}
Stephan Kleuker
277
Strategy - Problem
• Für eine Methode gibt es verschiedene
Möglichkeiten sie zu implementieren
• Die Wahl der Implementierungsart soll leicht
verändert werden können
Einsatzszenarien
• Prototypische Implementierung soll später leicht
ausgetauscht werden können
• Wahl der effizientesten Methode hängt von weiteren
Randbedingungen ab (z. B. suchen / sortieren)
• Ausführungsart der Methode soll zur Laufzeit
geändert werden können (Kunde zahlt für einen
Dienst und bekommt statt WerbeDetailinformationen)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
278
Strategy - Lösungsbeispiel
Grundkurs Software-Engineering mit UML
Stephan Kleuker
279
State-Pattern (eigene Variante)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
280
State-Pattern – Implementierungsauszug (1/2)
public abstract class Zustand {
protected int x;
public abstract Zustand setX(int x);
public abstract String status();
protected Zustand(int x){
this.x=x;
}
}
public class ZustandOK extends Zustand{
public ZustandOK(int x) {
super(x);
}
@Override
public Zustand setX(int x) {
this.x=x;
if(x>=42) return new ZustandKritisch(x);
return this;
}
@Override
public String status() {return "alles ok";}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
281
State-Pattern – Implementierungsauszug (2/2)
public class Messstation {
private String standort = "City";
private Zustand z= new ZustandOK(0);
public void zustandAendern(int wert){
z=z.setX(wert);
}
public void ausgeben(){
System.out.println(standort
+" Zustand: "+z.status());
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
282
Command-Pattern
• Problem: unterschiedliche Aktionen werden zentral
ausgeführt und verwaltet
• Ansatz: Stecke detaillierte Ausführung in ein
(Command-)Objekt; diese haben gemeinsames
Interface
• Command-Objekte kennen Details der Ausführung
• Steuerung dann einfach änder- und erweiterbar
• Beispiel: Kleiner Taschenrechner mit + und – und
einem Zwischenspeicher für einen Wert, der dann
aufaddiert werden kann
Grundkurs Software-Engineering mit UML
Stephan Kleuker
283
Beispiel 1/12 : Rechner 1/2
package business;
public class Rechner {
private int anzeige;
private int speicher;
public int getAnzeige() {
return anzeige;
}
public void setAnzeige(int anzeige) {
this.anzeige = anzeige;
}
public int getSpeicher() {
return speicher;
}
public void setSpeicher(int speicher) {
this.speicher = speicher;
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
284
Beispiel 2/12 : Rechner 2/2
public void addieren(int wert) {
this.anzeige += wert;
}
public void subtrahieren(int wert) {
this.anzeige -= wert;
}
public void speichern(){
this.speicher = this.anzeige;
}
public void speicherAddieren(){
this.anzeige += this.speicher;
}
public void speicherSubtrahieren(){
this.anzeige -= this.speicher;
}
@Override
public String toString(){
return "Speicher: "+ this.speicher +"
+ this.anzeige;
}
Grundkurs Software-Engineering mit UML
}
Stephan Kleuker
Wert: "
285
Beispiel 3/12 : Klassischer Dialog 1/2
package io;
import business.Rechner;
public class Dialog {
private Rechner rechner = new Rechner();
public void dialog() {
EinUndAusgabe ea = new EinUndAusgabe();
int eingabe = -1;
while (eingabe != 0) {
System.out.println("(0) Programm beenden\n"
+ "(1) addieren\n"
+ "(2) subtrahieren\n"
+ "(3) Anzeige in Speicher\n"
+ "(4) Speicher addieren\n"
+ "(5) Speicher subtrahieren");
eingabe = ea.leseInteger();
switch (eingabe) {
case 1: {
System.out.print("Wert eingeben: ");
this.rechner.addieren(ea.leseInteger());
break;
}
Grundkurs Software-Engineering
mit UML
Stephan Kleuker
286
Beispiel 4/12 : Klassischer Dialog 2/2
case 2: {
System.out.print("Wert eingeben: ");
this.rechner.subtrahieren(ea.leseInteger());
break;
}
case 3: {
this.rechner.speichern();
break;
}
case 4: {
this.rechner.speicherAddieren();
break;
}
case 5: {
this.rechner.speicherSubtrahieren();
break;
}
}
System.out.println(this.rechner);
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
287
Beispiel 5/12 : Funktioniert immerhin
(0) Programm beenden
(1) addieren
(2) subtrahieren
(3) Anzeige in Speicher
(4) Speicher addieren
(5) Speicher subtrahieren
1
Wert eingeben: 43
Speicher: 0 Wert: 43
(2) subtrahieren
2
Wert eingeben: 1
Speicher: 0 Wert: 42
(3) Anzeige in Speicher
3
Speicher: 42 Wert: 42
Grundkurs Software-Engineering mit UML
(4) Speicher addieren
4
Speicher: 42 Wert: 84
(5) Speicher subtrahieren
5
Speicher: 42 Wert: 42
(0) Programm beenden
0
Speicher: 42 Wert: 42
Stephan Kleuker
288
Beispiel 6/12 : Ansatz 1: Steuerungsklassen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
289
Beispiel 7/12 : Umsetzung 1/3
package io.commands;
public interface Command {
public void execute();
}
package io.commands;
import main.EinUndAusgabe;
import business.Rechner;
public class Addieren implements Command {
private Rechner rechner;
typischerweise werden
Zusatzinformationen
public Addieren(Rechner rechner){
this.rechner = rechner;
benötigt
}
eigentliche
@Override
Ausführung
public void execute() {
System.out.print("Wert eingeben: ");
this.rechner.addieren(new EinUndAusgabe().leseInt());
}
@Override
public String toString(){return "addieren";}
} Grundkurs Software-Engineering mit UML
Stephan Kleuker
290
Beispiel 8/12 : Umsetzung 2/3 (Varianten -> Praktikum)
package main;
import java.util.HashMap;
import java.util.Map;
import business.Rechner;
public class Dialog {
private Rechner rechner = new Rechner();
private Map<Integer,Command> aktionen = new HashMap<>();
public Dialog(){
this.aktionen.put(1, new Addieren(this.rechner));
this.aktionen.put(2, new Subtrahieren(this.rechner));
this.aktionen.put(3
, new AnzeigeSpeichern(this.rechner));
this.aktionen.put(4
, new SpeicherAddieren(this.rechner));
this.aktionen.put(5
, new SpeicherSubtrahieren(this.rechner));
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
291
Beispiel 9/12 : Umsetzung 3/3
public void dialog() {
EinUndAusgabe ea = new EinUndAusgabe();
int eingabe = -1;
while (eingabe != 0) {
System.out.println("(0) Programm beenden");
for(int tmp:this.aktionen.keySet()){
System.out.println("("+tmp+") "
+ this.aktionen.get(tmp));
}
eingabe = ea.leseInteger();
Command com = this.aktionen.get(eingabe);
if(com !=null){
com.execute();
}
System.out.println(this.rechner);
}
Grundkurs
Stephan Kleuker
292
} Software-Engineering mit UML
Beispiel 10/12 : Undo
• Command-Pattern eignet sich sehr gut, Aktionen
wieder rückgängig zu machen
• es müssen alle Änderungen der Aktion bekannt und
reversibel sein
• gibt verschiedene Varianten
– Ansatz 1: jedes Command-Objekt hat undoMethode und wird gespeichert
– Ansatz 2: es gibt eigenes Undo-Command-Objekt
als Ergebnis von execute()
– Ansatz 3: Undo- und Command-Objekte haben
keine gemeinsame Klasse / Interface
–…
Grundkurs Software-Engineering mit UML
Stephan Kleuker
293
Beispiel 11/12 : Variante Undo-Methode
Grundkurs Software-Engineering mit UML
Stephan Kleuker
294
Beispiel 12/12 : Variante Undo-Objekte (Skizze)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
295
Fazit Command-Pattern
• generell oft bei Steuerungen einsetzbar
• oft gut für Undo- und Redo geeignet
• meist individuelle Varianten des Patterns sinnvoll
• (in UML-Diagrammen oft zusätzliche Klasse, die auf
Command zugreifen kann)
• Command-Klassen müssen einfach an benötigte
Informationen kommen können; wird dies
kompliziert, ist der Patter-Einsatz nicht sinnvoll
Grundkurs Software-Engineering mit UML
Stephan Kleuker
296
Beschreibung des Pattern
8.4
Name: Abstract Factory
Patterngruppe: Objekterzeugung
Kurzbeschreibung: Client kann mit einer AbstractFactory zu einer
abstrakten Klasse passende Exemplare aus einem Satz konkreter
Implementierungen für bestimmtes Produkt erzeugen, kennt den
konkreten Typ des erzeugten Exemplars nicht
Kontext: viele verschiedene gleichartige, aber unterscheidbare
Objekte sollen verwaltet werden
Problem: Klasse soll verschiedene Objekte bearbeiten, benötigt
aber nur deren gemeinsame Eigenschaften
Lösung: Einführung von zwei abstrakten Klassen, die zum Einen
Objekterzeugung, zum Anderen Objektzugriff erlauben, Client
muss nur diese Klassen kennen
Einsatzgebiete: ...
Varianten: ...
Grundkurs Software-Engineering mit UML
Struktur: s.o.
Stephan Kleuker
Beispiele:
297
Gruppen von Pattern (Beispiele)
• Strukturpattern befassen
sich mit der Komposition
von Klassen und Objekten,
um größere Strukturen zu
bilden
Zielsetzungen:
– Anpassung von
Schnittstellen (Adapter)
– Trennung von
Abstraktion und
Implementierung
(Brücke)
– Zusammensetzung von
Objekten (Kompositum)
– Erzeugen von
Stellvertreterobjekten
(Proxy)
Grundkurs Software-Engineering mit UML
• Erzeugungspattern sollen
das Wissen um das System
und die konkreten Klassen
des Systems vor dem
Benutzer verstecken
Zielsetzungen:
– Systeme leichter
konfigurierbar zu machen
– Änderungen im Entwurf
vorherzusehen
• Verhaltenspattern ...
Stephan Kleuker
298
GoF-Pattern Übersicht (nicht auswendig lernen)
Objekt
Einsatzbereich
Klasse
Aufgabenbereich
Erzeugung
Struktur
Verhalten
Factory
Adapter
Interpreter
Template
Abstract
Factory
Adapter
Command
Builder
Bridge
Observer
Prototype
Decorator
Visitor
Singleton
Facade
Memento
Composite
Strategy
Proxy
Mediator
Flyweight
State
Chain of
Responsibility
Grundkurs Software-Engineering mit UML
Stephan Kleuker
299
Pattern in der UML
Pattern-Name im gestrichelten Kreis, verbunden mit eingekreisten
Klassen, verbunden mit Pattern und Bennenung der Rollen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
300
Kritische Betrachtung von Pattern
• Pattern für Anfänger wenig geeignet, man
muss erste Erfahrungen haben, um von
Erfahrungen anderer zu profitieren
• überlagernde Pattern schwer pflegbar, später
in Implementierungen teilweise schwer
erkennbar
• ?? Wer mit Pattern umgehen kann, sollte in
kritischeren Bereichen einer Firma eingesetzt
werden ??
• Pattern finden Einzug in Bibliotheken, Beispiel:
Event-Handling in Java ist „Observer-Pattern“
• Generell sind Pattern ein wichtiger Teilschritt
zum ingenieurmäßigen SW-Engineering
• Gute Programmier-Aufgabe: Entwickeln Sie
kleine Beispiele zu allen GoF-Pattern !!!
Grundkurs Software-Engineering mit UML
Stephan Kleuker
301
9. Implementierungsaspekte
9.1 Einfluss nicht-funktionaler Anforderungen
9.2 Verteilte Systeme
9.3 Grundideen von XML
Hinweis: Hier nur Skizze
9.4 Programmbibliotheken
interessanter Konzepte,
9.5 Komponenten
die Schwerpunkte weiterer
9.6 Frameworks
Veranstaltungen sind
9.7 Persistente Datenhaltung
9.8 Annotationen
9.9 Domain Specific Languages
9.10 Model Driven Architecture
9.11 Refactoring
Grundkurs Software-Engineering mit UML
Stephan Kleuker
302
Randbedingungen für erfolgreiches Design
Nach Analysemodell und vor Design stehen wichtige
Entscheidungen
bisher:
• wir kennen die generelle Entwicklung einer SW-Architektur
(Pakete)
• wir entwickeln klassische SW für einen Rechner, Objekte
können theoretisch Methoden beliebiger anderer Objekte
aufrufen
aber vor Beginn der Designphase spielt auch die
Berücksichtigung weiterer Randbedingungen zentrale Rolle:
• muss existierende SW eingebunden werden?
• muss für eine spezielle HW entwickelt werden?
• welche Anforderungen gibt es an die Verteilung von SW auf
unterschiedliche Rechner?
• welche Rolle spielen nichtfunktionale Anforderungen (Safety,
Security, Performance, Oberflächendesign)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
303
Beispiel: Rahmenbedingungen für SW-Architektur
9.1
• Berücksichtigung von speziellen SW-Schnittstellen
nicht objektorientiert entwickelter Systeme, z. B. von
Application Programming Interfaces (API) fremder
SW
• Berücksichtigung/Benutzung existierender
Datenhaltungssysteme, z. B. Vorgabe des
Datenbankmanagementsystems (DBMS)
• Berücksichtigung bestimmter Design-Prinzipien, z.
B. Gesamtsteuerung mit Enterprise Java Beans
(EJB) oder .NET für die Realisierung
• Alt-Software (z. B. in COBOL), so genannte LegacySysteme müssen eingebunden werden; Einsatz einer
Middleware (z. B. Common Object Request Broker
Architecture, CORBA)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
304
Einfluss nichtfunktionaler Anforderungen
Beispiel: Sicherheit (Security)
• Alle Nachrichten müssen über den speziellen
Krypto-Server laufen; dieser hat bestimmte
Bandbreite (Bottle-neck); SW muss auf allen Seiten
möglichst viel ohne Verbindung arbeiten können
(Redundanz wird erlaubt)
Beispiel: Sicherheit (Safety)
• Berechnungen zur Steuerung müssen redundant auf
drei Rechnern mit unterschiedlichen Verfahren
durchgeführt werden
Beispiel: Performance
• Die rechenintensiven 3D-Berechnungen müssen
sehr schnell sein; dies kann zum Einsatz von C mit
langen komplexen Funktionen führen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
305
Rahmenbedingung: verteilte Systeme
9.2
• in der klassischen OO-Programmierung gibt es einen
Programmablauf (Prozess) und man nutzt synchrone Aufrufe:
Objekt O1 ruft Methode von Objekt O2 auf; O2 übernimmt die
Programmausführung und antwortet dann O1
• bei verteilten Systemen laufen viele Prozesse parallel ab, die
Informationen austauschen können
• synchroner Aufruf ist möglich, bedeutet aber, dass Verbindung
aufgebaut werden muss und Sender bzw. Empfänger auf
Bereitschaft warten müssen
• asynchroner Aufruf bedeutet, dass Sender Aufruf abschickt und
danach weiterarbeitet; später prüft, ob ein Ergebnis vorliegt
• asnychrone Aufrufe sind schneller (nur abschicken); Prozesse
sind aber schwer zu synchronisieren
• die Herausforderung effizienter verteilter Systeme hat nicht die
eine Lösung und wird Sie Ihr Informatik-Leben-lang verfolgen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
306
Probleme der Aufrufmechanismen
synchroner Aufruf
Problem: Deadlock
Prozess A Prozess B Prozess C
warten auf
Antwort
warten auf
Antwort
asynchroner Aufruf
Problem: B denkt, x hat
vor y stattgefunden
Problem: C denkt, x hat
vor y stattgefunden, A
denkt, y hat vor x
stattgefunden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
307
Typische Probleme verteilter Systeme
• Deadlocks: kein Prozess/Thread kann voran schreiten
• partielle Deadlocks: einige Prozesse im Deadlock, andere nicht
• Livelocks: System versucht, sich zyklisch zu synchronisieren,
ohne dass das System voran schreitet
• (starke) Fairness : kommen Prozesse, die immer mal wieder
darauf warten, in den kritischen Bereich zu kommen, auch dran
• (schwache) Fairness: kommen Prozesse, die immer darauf
warten, in den kritischen Bereich zu kommen, auch dran
• synchronized() in Java (Methode wird garantiert ohne
Parallelnutzung des aufgerufenen Objekts genutzt) hat starken
negativen Einfluss auf die Laufzeit
• Erinnerung/Ausblick: Notwendige Transaktionssteuerung bei
Datenbankmanagementsystemen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
308
Beispiel: Varianten von Client-Server-Systemen
• Thin Client: Hier nur
Datenannahme,
Weiterleitung, Darstellung,
keine komplexen
Berechnungen
• Beispiele: Web-Browser, DBClients
Client
Netzwerk
• Fat Client: Client führt
eigene komplexe
Berechnungen aus; nutzt
Server nur zur Verwaltung
zentraler Informationen und
zum Nachrichtenaustausch
• Beispiel: vernetzbare Standalone-Spiele (Autorennen)
Client
Netzwerk
Server
Server
Grundkurs Software-Engineering mit UML
Stephan Kleuker
309
Beispiel: 3-Tier-Architektur
Client
Präsentationsschicht
Server für Anwendung
eigentliche Anwendungs-SW
Datenbank-Server
persistente Datenhaltung
Grundkurs Software-Engineering mit UML
Verteilung:
• Nur Darstellung (GUI) beim
Client
• eigener Server für Anwendung
• eigene Datenspeicherung
Vorteile:
• benötigte DB-Verbindungen
können angepasst werden
(Kosten)
• Datenbank nicht direkt für
Client zugreifbar (Sicherheit)
• Änderungen einer Schicht
müssen andere Schichten
nicht beeinflussen
Stephan Kleuker
310
Erinnerung: XML
9.3
• eXtensible Markup Language
• strukturierte maschinen- und ansatzweise menschenlesbare
Informationsbeschreibung
• Applikationen müssen Daten vor der Programmbeendung
speichern, sollten diese mit anderen Programmen austauschen
können (-> Definition eines gemeinsamen XML-Formats)
• Neben reiner Syntax kann auch die erlaubte inhaltliche Struktur
spezifiziert werden (DTD: Document Type Definition), XMLSchema
• Viele gute Werkzeuge und Bibliotheken zur XML-Verarbeitung
• zentrale Inhalte werden mit Elementen und Attributen
beschrieben
• Strukturierung durch Namensräume
Grundkurs Software-Engineering mit UML
Stephan Kleuker
311
Elemente
• Elemente beschreiben zentrale Inhalte von XMLDokumenten
• Namen der Elemente können vom Autor frei
vergeben werden (soll Dokument mit verschiedenen
Applikationen bearbeitet werden, muss man sich auf
das Vokabular einigen -> später)
• Typische Form
<projektname> XML-DB </projektname>
• Element heißt projektname, der Inhalt ist vom
sogenannten Start- und End-Tag umgeben
• Abkürzungsmöglichkeit bei leerem Inhalt:
<projektname/>
• Leerzeichen führen meist zu Fehlern, hier z. B. drei
<■bla > <■/■bla >
Grundkurs Software-Engineering mit UML
Stephan Kleuker
312
Hierarchischer Aufbau
• Elemente können ineinander geschachtelt werden
• Ausgehend vom obersten Element ergibt sich ein Baum
<team>
<mitarbeiter>
<minr>42</minr>
team
<name>Aische Meier</name>
<anteil>40</anteil>
mitarbeiter
mitarbeiter
</mitarbeiter>
<mitarbeiter>
minr name anteil
minr name anteil
<minr>46</minr>
<name>Nabil Ibn</name>
<anteil>50</anteil>
</mitarbeiter>
</team>
Grundkurs Software-Engineering mit UML
Stephan Kleuker
313
Attribute
• Jedes Element kann eine beliebige Anzahl an
Attributen haben
• Attribute stehen in Anführungsstrichen (" oder ')
<projekt abteilung="Entwicklung"
vertrag="Festpreis">
<projektname>Speichermodul</projektname>
<kunde blz="65566445" knr="35674534" />
<projektleiter kosten="1000">
<minr>49</minr>
<name>Ute Rose</name>
<anteil>50</anteil>
</projektleiter>
</projekt>
Grundkurs Software-Engineering mit UML
Stephan Kleuker
314
Attribute oder Elemente
• Attribute beschreiben Eigenschaften von Elementen
• Eigentlicher Inhalt steht zwischen den Tags
• Aus theoretischer Sicht vertauschbar
<projekt abteilung="Entwicklung"
vertrag="Festpreis"/>
• alternativ
<projekt>
<abteilung> Entwicklung </abteilung>
<vertrag> Festpreis </vertrag>
</projekt>
• Aus Sicht der Verarbeitung leichte Unterschiede,
Tendenz zu Attributen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
315
Kommentare und Namensregeln
• Grundsätzlich existieren nur kommentierte Produkte
• XML Kommentar in <!-- und --> eingeschlossen
<!-- Isch bin ähn Gommenta -->
• Im Kommentartext kein -- erlaubt, auch keine Schachtelung
• Kommentare in Elementen nicht erlaubt
• XML unterscheidet Groß- und Kleinschreibung, Elemente und
Attribute meist klein (keine sehr feste Regel)
• Bezeichner müssen mit Buchstaben oder _ oder : beginnen
• In Bezeichnern beliebige Zeichen erlaubt
• Grundregeln für eigene Elementnamen:
– selbsterklärend
– nicht mit _ oder : beginnen (für Spezialfälle, : generell nicht)
– auf Umlaute verzichten
Grundkurs Software-Engineering mit UML
Stephan Kleuker
316
Genereller Aufbau eines XML-Dokuments
• Dokument beginnt mit XML-Deklaration gefolgt von Element
• folgt: jedes XML-Dokument als Baum mit Wurzel betrachtbar
(mit root element oder document element)
<?xml version="1.0" encoding="utf-8"?>
<!-- angeblich generiert aus Spro -->
<projekt abteilung="Entwicklung"
vertrag="Eigenentwicklung">
<projektname>Speicher </projektname>
</projekt>
• version (bleibt vielleicht immer) 1.0 oder 1.1
• encoding gibt verwendeten Zeichensatz an, hier klein oder
Großschreibung möglich, typisch sind
UTF-8
8 Bit Zeichenbereite (Standard)
UTF-16
16 Bit Zeichenbreite (bel. Sprachen)
ISO-8859-1
Westeuropäische Sprachen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
317
Nutzung von Programmbibliotheken
9.4
• Programmbibliotheken stellen Standardlösungen für häufig
wiederkehrende Probleme dar
• typische Nutzung: Nutzer erzeugt und ruft Objekte (Klassen)
der Bibliothek auf
• Bibliotheken sind geprüft (hoffentlich) und für Laufzeiten
optimiert
• Dokumentation von Bibliotheken wichtig zum effizienten
Einsatz (was rufe ich wann auf)
• Je größer der Verbreitungsgrad, desto einfacher die
Weiterverwendung von Ergebnissen (großer Vorteil der JavaKlassenbibliothek)
• Grundregel für erfahrene Entwickler: Erfinde das Rad niemals
zweimal, weiß aber, wo viele Blaupausen für viele verschiedene
Räder sind
• Grundregel für Informatikanfänger: Lerne zu verstehen, wie
man das erste Rad baut, baue das erste Rad und lerne warum
man wie die Blaupause variieren kann
Grundkurs Software-Engineering mit UML
Stephan Kleuker
318
Idee von Komponenten
9.5
• Komponenten sind komplexe in sich abgeschlossene „binäre“
SW-Bausteine, die größere Aufgaben übernehmen können
• Ansatz: SW statt aus kleinen Programmzeilen aus großen
Komponenten (+ Klebe-SW) zusammen bauen
• Komponenten werden konfiguriert, dazu gibt es get-/setMethoden (Schnittstelle) oder/und Konfigurationsdateien
• Beispiel Swing-Klassen, wie JButton haben (u. a.)
Komponenteneigenschaft; man kann u. a. einstellen:
– Farben (Hintergrund, Vordergrund)
– Schrifttypen
– Form der Ecken
– dargestelltes Bild
• Komponenten sind themenorientiert und können
unterschiedliche Aufgaben erfüllen (z. B. Daten filtern, Werte
überwachen)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
319
GUI-Builder (1/2)
• Die Programmierung von Oberflächen in Java ist
zwar recht strukturiert möglich, viele Arbeitsschritte
wiederholen sich aber monoton
• GUI-Builder stellen einen anderen Ansatz zur
Entwicklung von Oberflächen vor, Oberflächen
werden per Drag-and-Drop zusammengestellt
• Die weitere Programmierung findet durch den
Entwickler „unterhalb“ der GUI-Elemente statt, jeder
Code muss einer Komponente zugeordnet werden
• GUI-Builder eignen sich damit sehr gut, schnell
einen GUI-Prototypen zu erstellen, um mit den
späteren Nutzern das Look-and-Feel zu diskutieren
Grundkurs Software-Engineering mit UML
Stephan Kleuker
320
GUI-Builder (2/2)
• GUI-Builder haben aber auch Nachteile:
– Software ist häufig nicht GUI-gesteuert entwickelbar, je
komplexer das „Innenleben“ ist, desto weniger steht das GUI
in der Entwicklung im Mittelpunkt
– wer nicht weiß, wie ein GUI funktioniert, programmiert nur
Fragmente und kennt das Zusammenspiel des Systems nicht
– oftmals können ohne GUI-Builder entwickelte Oberflächen
nicht mit dem GUI-Builder weiter bearbeitet werden
– GUI-Builder geben die Struktur des Codes vor, d.h. man
muss sich auf die Programmiereigenheiten des GUI-Builders
zu 100% einlassen
– die Unterstützung von Pattern (guten Designideen, wie MVC)
ist nicht immer gegeben
• Fazit: Der Einsatz eines GUI-Builders sollte nur in Betracht
gezogen werden, wenn man die Grundsätze zur GUI-Entwicklung
in der jeweiligen Programmiersprache verstanden hat, danach
muss getestet werden, ob man mit dem resultierenden Code
leben kann
Grundkurs Software-Engineering mit UML
Stephan Kleuker
321
Zentrale Eigenschaften von Komponenten
Grundkurs Software-Engineering mit UML
Stephan Kleuker
322
Idee der Framework-Technologie
9.6
• statt vollständiger SW werden Rahmen
programmiert, die um Methodenimplementierungen
ergänzt werden müssen
• Frameworks (Rahmenwerke) können die Steuerung
gleichartiger Aufgaben übernehmen
• typische Nutzung: Nutzer instanziiert FrameworkKomponenten, d. h. übergibt seine Objekte zur
Bearbeitung durch das Framework; typischer
Arbeitsschritt: Framework steuert, d. h. ruft Methode
der Nutzerobjekte auf
• eventuelles Problem: schwieriger Wechsel zu
anderem Framework oder bei Ablösung des
Frameworks
Grundkurs Software-Engineering mit UML
Stephan Kleuker
323
Framework-Technologie in Swing
Framework-Technologie „im Kleinen“:
• auch Java-Klassenbibliothek [kritischer Name] bietet es an,
dass einfache Klassen zu Komponenten des Model-DelegateAnsatzes der Swing-Komponenten werden
• Beispiele: JTree (oder JTable)
• Forderung: Eine darzustellende Klasse muss das zugehörige
Interface TreeModel implementieren
• Konstruktor JTree(TreeModel tm)
• Eigenschaften eines JTree, z. B. wie Inhalte dargestellt werden,
können über Methoden gesteuert werden (JTree wird als
normales Element der Klassenbibliothek genutzt)
• JTree steuert die Darstellung, ruft dazu Methoden des
TreeModel auf
Grundkurs Software-Engineering mit UML
Stephan Kleuker
324
TreeModel
Ausschnitt: angebotene Methoden (s. Java-Dokumentation)
void addTreeModelListener(TreeModelListener l)
Adds a listener for the TreeModelEvent posted after the tree changes.
Object getChild(Object parent, int index)
Returns the child of parent at index index in the parent's child array.
int getChildCount(Object parent)
Returns the number of children of parent.
int getIndexOfChild(Object parent, Object child)
Returns the index of child in parent.
Object getRoot()
Returns the root of the tree.
boolean isLeaf(Object node)
Returns true if node is a leaf.
void removeTreeModelListener(TreeModelListener l)
Removes a listener previously added with addTreeModelListener.
void valueForPathChanged(TreePath path, Object newValue)
Messaged when the user has altered the value for the item identified
by path to newValue.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
325
Skizze einer Beispielimplementierung (1/5)
Knoteninformation dient dazu, für den jeweiligen Knoten die
darstellungsrelevanten Informationen zu liefern
Grundkurs Software-Engineering mit UML
Stephan Kleuker
326
Skizze einer Beispielimplementierung (2/5)
ProjektTreeModel ptm =
new ProjektTreeModel();
JTree baum = new JTree(ptm);
JScrollPane scroller =
new JScrollPane(baum);
add(scroller,BorderLayout.CENTER);
Grundkurs Software-Engineering mit UML
Stephan Kleuker
327
Skizze einer Beispielimplementierung (3/5)
public class ProjektTreeModel implements TreeModel {
private Projektverwaltung projektverwaltung;
private List<TreeModelListener> listener =
new ArrayList<TreeModelListener>();
public ProjektTreeModel() {
this.projektverwaltung = new Projektverwaltung();
}
public Object getRoot() {
return this.projektverwaltung;
}
public Object getChild(Object arg0, int i) {
return ((Knoteninformation)arg0).itesElement(i);
}
public int getChildCount(Object arg0) {
return ((Knoteninformation)arg0).anzahlElemente();
}
public void addTreeModelListener(TreeModelListener arg0){
this.listener.add(arg0);
}
} // nur Ausschnitt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
328
Skizze einer Beispielimplementierung (4/5)
public class Projektverwaltung implements Knoteninformation{
private List<Projekt> projekte = new ArrayList<Projekt>();
public int anzahlElemente() {
return this.projekte.size();
}
public Knoteninformation itesElement(int i) {
return this.projekte.get(i);
}
public boolean istBlatt() {
return false;
}
public String titel() {
return "Projektverwaltung";
}
@Override
public String toString(){
return titel();
}
} // nur Ausschnitt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
329
Skizze einer Beispielimplementierung (5/5)
public class Projekt implements Knoteninformation{
private Eigenschaft[] eigenschaften = new Eigenschaft[8];
private BaumListe<Projekt> teilprojekte =
new BaumListe<Projekt>("Teilprojekte");
private BaumListe<Projekt> vorgaenger =
new BaumListe<Projekt>("Vorgaenger");
private BaumListe<Aufgabe> aufgaben =
new BaumListe<Aufgabe>("Aufgaben");
public int anzahlElemente() {
return this.eigenschaften.length+3;
}
public Knoteninformation itesElement(int i) {
switch(i){
case 0: case 1: case 2: case 3: case 4: case 5: case 6:
case 7: return eigenschaften[i];
case 8: return vorgaenger;
case 9: return teilprojekte;
case 10:return aufgaben;
}
return null;
}
} Grundkurs
// nur
Ausschnitt
Software-Engineering mit UML
Stephan Kleuker
330
Ziele komplexere Framework-Ansätze
neben Spezialaufgaben werden hauptsächlich folgende
Aufgaben gelöst
• sorgenfreies Lesen und Speichern von Objekten in
Datenbanken (Persistenz)
• sorgenfreie konsistente Verteilung von
Informationen (Prozesskommunikation)
• sorgenfreie Steuerung verteilter Abläufe mit
Überwachung von Transaktionen
• Beispiele sind Enterprise Java Beans, Microsoft DotNet-Technologie, Spring, Hibernate, viel im Bereich
AJAX
Grundkurs Software-Engineering mit UML
Stephan Kleuker
331
Persistente Datenhaltung
9.7
Typische Java-Möglichkeiten
• Anschluss an klassische relationale DB über JDBC
(typisch bei Anbindung an existierende DB)
• Nahtlose Integration der Datenhaltung in die
Entwicklung (Ansatz: statt Objekt zu erzeugen
Methode holeObjekt(), später sichere Objekt),
typisch für Hibernate (häufig genutzt, bei kleinen
Spezialanwendungen, z. B. Handy, Organizer)
• relativ nahtlose Integration durch zusätzliche
Software, die objekt-relationales Mapping übernimmt
• Nutzung eines Frameworks, das Persistenz und
Transaktionssteuerung übernimmt, Enterprise Java
Beans
Grundkurs Software-Engineering mit UML
Stephan Kleuker
332
Beispiel: JavaBeans (kleiner Ausschnitt)
• Java unterstützt Reflektion, damit kann ein Objekt nach seiner
Klasse, seinen Exemplarvariablen und Exemplarmethoden
befragt werden
• Hält man sich an folgende einfache Regel für eine Klasse
– sie implementiert Serializable (geht nur, wenn alle
verwendeten Typen Serializable)
– für alle Exemplarvariablen gibt es die Standard get- und setVariablen
– es gibt einen leeren Default-Konstruktor
dann sind einige Framework-Ansätze nutzbar
– Objekte speichern und lesen in XML
– Nutzung als JavaBeans (sinnvoll weitere Standardmethoden)
– Objekte speichern in einer Datenbank mit JDO, als Entity
– Objekte im Binärformat lesen und schreiben (reicht
Serializable)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
333
XMLEncoder und XMLDecoder (Ausschnitt)
private void speichern(String datei){
try {
XMLEncoder out= new XMLEncoder(
new BufferedOutputStream(new
FileOutputStream(datei)));
out.writeObject(table.getModel());
out.close();
} catch (FileNotFoundException e) {} //wegschauen
}
private void laden(String datei){
try {
XMLDecoder in= new XMLDecoder(
new BufferedInputStream(new
FileInputStream(datei)));
table.setModel((DefaultTableModel)in.readObject());
in.close();
} catch (FileNotFoundException e) {} //wegschauen
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
334
Annotationen
9.8
• klassische imperative Programmierung (=prozedural,
objektorientiert): man beschreibt welche Schritte
gemacht werden sollen
• Annotationen: man schreibt was man haben will;
eigentliche Realisierung wird vom Framework
übernommen
• verwandt mit aspektorientierter Programmierung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
335
Beispiel JPA (1/2)
@Entity soll persistiert werden
public class Mitarbeiter implements Serializable {
private static final long serialVersionUID Schlüssel
= 1L;
Exemplarvariable ist Schlüssel
automatisch
@Id
generiert
@GeneratedValue(strategy = GenerationType.AUTO)
private int minr;
private String name;
1:N-Beziehung
@OneToMany(mappedBy="bearbeiter",
cascade={CascadeType.PERSIST,
CascadeType.MERGE})
private Set<Projektauftrag> auftraege =
new
HashSet<Projektauftrag>();
...
public void auftragHinzu(Projektauftrag pa){
auftraege.add(pa);
} Software-Engineering
// getund set- für Stephan
Exemplarvariablen
Grundkurs
mit UML
Kleuker
336
Beispiel JPA (2/2) – nur Überblick
private EntityManagerFactory emf =
Persistence.createEntityManagerFactory("JPAKonfigD
atei");
private EntityManager em =
emf.createEntityManager();
public void mitarbeiterBeispieldaten(){
Mitarbeiter m[]= {new Mitarbeiter("Egon"),
new Mitarbeiter("Aische"), new
Mitarbeiter("Urs")};
em.getTransaction().begin();
for (int i=0; i<m.length; i++)
em.persist(m[i]);
em.getTransaction().commit();
}
public void datenZeigen() {
for (Mitarbeiter m : em.createQuery(
"SELECT m FROM Mitarbeiter
Grundkurs
Software-Engineering mit UML
Stephan Kleuker
m",Mitarbeiter.class)
337
In Erprobung/Entwicklung: : Domain Specific Languages
9.9
• Problem: General Purpose Sprachen sind sehr
mächtig, aber für spezifische Entwicklungsbereiche
geht sehr viel Energie in für den Bereich gleichartige
Programmierung
• Spezielle Entwicklungssprache für individuellen
Bereich, spezielle komplexe Hochsprachelemente
anbietet
• Neue Sprache z. B. mit XML (Syntax mit XMLSchema) darstellbar; Umwandlung in Programm mit
Übersetzung (z. B. XSLT) ; hilfreich ist
Visualisierungsmöglichkeit der DSL
• Hinweis: UML (evtl. mit konkreter Ausprägung) kann
mit MDA-Transformationen auch als spezieller DSLAnsatz angesehen werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
338
DSL Prozesse
Grundkurs Software-Engineering mit UML
Stephan Kleuker
339
In Erprobung/Entwicklung: Model Driven Architecture
9.10
• Ansatz: Häufig benötigt man die gleichen Ideen (z. B.
Sortierverfahren) in sehr unterschiedlichen Sprachen; warum
nicht in einer Sprache modellieren und dann in andere
Sprachen transformieren?
• Da Sprachen extrem unterschiedlich, soll Modellumwandlung
schrittweise passieren
• Zur Modellbeschreibung wird eigene Sprache mit eigener
Semantik benötigt (Metamodell und Metametamodell)
• Ansatz: Umwandlung des CIM mit Transformationsregeln in ein
PIM und dann ein PSM
CIM: Computer Independent Model
PIM: Platform Independent Model
PSM: Platform Specific Model
• z. B. UML-Modell, dann Realisierungssprache wählen, dann
HW-Plattform mit Kommunikationsprotokollen wählen (zwei
parametrisierte Transformationen)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
340
Prozess der MDA (Theorie)
• Realität: häufig nur
eine konkrete Ebene
• viele manuelle
Einstellungen für die
Transformation
• Generieren gibt es
schon lange (YACC,
Dateien zur
Beschreibung von
Fenstern, von UML
zum Programmskelett)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
341
Formaler Hintergrund der MDA
Semantik definiert durch
Abarbeitungsreihenfolge
konkretes
Modell1
konkrete Menge von
Regeln mit konkreten
Parametern
Instanz von
Instanz von
Transformationsregeln
Modellart1
konkretes
Modell2
Instanz von
Modellart2
Transformationsmodel
Meta Object Faciliy (MOF)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
342
Refactoring
9.11
• Komplexe Methoden sollen grundsätzlich vermieden werden
• Lösungsansatz: Refactoring, d. h. ein Programmblock wird in
einer Methode mit selbsterklärendem Namen ausgegliedert
• Wann ist Ausgliederung möglich?
– Im Block darf nur eine lokale Variable auf der linken Seite
einer Zuweisung stehen
• Wie funktioniert Refactoring?
– Bestimme alle lokalen Variablen, die im Block lesend
genutzt werden; diese werden zu Parametern
– Falls eine lokale Variable links in einer Zuweisung
vorkommt, bestimmt sie den Rückgabetypen (sonst void)
• Exemplarvariablen spielen keine Rolle, da auf sie in allen
Methoden der Klasse zugegriffen werden darf
• Probleme bei mehr als einer zu verändernden lokalen Variablen
oder bei enthaltenen Rücksprüngen (aufwändig regelbar)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
343
Refactoring – Positives Beispiel
public int ref(int x, int y, int z){
int a=0;
public int ref(int x, int y, int z){
if(x>0){
int a=0;
a=x;
if(x>0){
x++;
a = mach(x, y, z);
--y;
}
a=a+y+z;
return a;
}
}
return a;
private int mach(int x, int y, int z){
}
int a;
a=x;
x++;
--y;
a=a+y+z;
return a;
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
344
Refactoring – nicht einfaches Beispiel
public int ref2(int x){
int a=0;
int b=0;
int c=0;
if(x>0){
a=x;
b=x;
c=x;
}
return a+b+c;
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
345
Refactoring – (nicht) einfaches Beispiel in C++
int Rechnung::ref2(int x){
int a=0;
int b=0;
int c=0;
if(x>0){
abcAnpassen(a,b,c,x);
}
return a+b+c;
}
void Rechnung::abcAnpassen(int& a, int& b, int& c,
int x){
a=x;
b=x;
c=x;
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
346
10. Oberflächengestaltung
10.1 Hintergründe der Oberflächengestaltung
10.2 Konkretisierung des Nutzbarkeitsbegriffs
10.3 Berücksichtigung der Ergonomie im
Software-Entwicklungsprozess
10.4 Prüfung der Nutzbarkeit
http://usability.is.uni-sb.de/index.php (Arbeitsbereich Usability
Engineering )
http://usability.gov/guidelines/index.html (U.S. Department of Health
and Human Services)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
347
Begriff: Ergonomie
10.1
• Der Begriff "Ergonomie" setzt sich aus den griechischen
Wörtern
ergon = Arbeit, Werk und
nomos = Gesetz, Regel zusammen.
Nach Auffassung der International Ergonomics Association
wird unter Ergonomie die Lehre von der menschlichen Arbeit
und die Erkenntnis ihrer Gesetzmäßigkeiten verstanden.
• Laut der offiziellen Definition der internationalen ISO-Norm
verwendet Ergonomie wissenschaftliche Erkenntnisse, um
Arbeitsaufgaben, Arbeitsumgebungen und Produkte an die
physischen und mentalen Fähigkeiten und Grenzen von
Menschen anzupassen. Hierbei soll Gesundheit, Sicherheit,
Wohlbefinden und Leistungsvermögen verbessert werden.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
348
Ergonomie als Schnittstelle der Forschung
• Psychologie: In der Gestaltungspsychologie wird u. a.
untersucht, welche Wirkungen Farben und Formen haben.
Dabei ist zu beachten, dass Fragen im Kontext betrachtet
werden müssen.
• Arbeitswissenschaft: Ein Teil der Arbeitswissenschaften
beschäftigt sich mit der ergonomischen Gestaltung von
Arbeitsplätzen. Dabei ist eine zentrale Forderung, dass die
Arbeitsumgebung und die Arbeitsmittel zur Aufgabe passen.
Software ist dabei in vielen Berufen ein zentrales Arbeitsmittel
von vielen Personen, die sich nicht mit der SoftwareEntwicklung beschäftigen. Für diese Personen muss der
Zugang zur IT aus ihrer Sicht intuitiv sein.
• Software-Ergonomie: In der Software-Ergonomie als InformatikDisziplin beschäftigt man sich mit der Umsetzung der Ideen der
vorher genannten Arbeitsgebiete in der Software. Dabei muss
als besondere Randbedingung die Realisierbarkeit von
gestalterischen Ideen berücksichtigt werden.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
349
Psychologie: Beispiel Farbwahl
Farbe
Assoziation
weiß
Reinheit, Unschuld (Asien: Trauer)
schwarz
Tod, Trauer, Eleganz, Schwere, Ernst
grau
Neutral, spannungslos
blau
Geist, Kosmos, Ewigkeit, wirkt kühl, steigert in
Kombination die Wirkung warmer Farbtöne
rot
Dynamik, Aktivität, Wärme, Warnfarbe
gelb
Anregend, heiter, dynamisch, kalte Farben wirken durch
Zusatz von gelb kälter, warme Farben wärmer
orange
Hohes Maß an Aktivität und Dynamik, erregt
Aufmerksamkeit, Warnfarbe
violett
Ernst, feierlich, je nach Blauanteil kühl oder warm
grün
Natur, Wachstum, beruhigend (langweilig)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
350
Zusammenhang der Normen ISO 9241
10.2
ISO 9241
Teil 17
Formulardialoge
Teil 16
Direkte Manipulation
Teil 14
Menüdialoge
Teil 15
Kommandodialoge
Teil 110 Dialogprinzipien
Teil 13 Benutzerführung
Teil 12 Informationsdarstellung
Teil 11 Anforderungen an die Gebrauchstauglichkeit
Grundkurs Software-Engineering mit UML
Stephan Kleuker
351
Leitlinien aus ISO 9241-110
Software-ergonomische Grundsätze der
Dialoggestaltung
•
•
•
•
•
•
•
Lernförderlichkeit
Fehlertoleranz
Erwartungskonformität
Aufgabenangemessenheit
Selbstbeschreibungsfähigkeit
Steuerbarkeit
Individualisierbarkeit
Grundkurs Software-Engineering mit UML
Stephan Kleuker
352
Lernförderlichkeit
• Ein Dialog ist lernförderlich, wenn er den Benutzer
beim Erlernen des Dialogsystems unterstützt und
anleitet.
• Praktische Anforderungen:
– Kann der Benutzer sich ohne Hindernisse in die
Nutzung des Systems einarbeiten?
– Kann der Benutzer das System ausprobieren,
ohne dafür „bestraft“ zu werden?
– Begriffe sinnfällig wählen
– Gleicher Aufbau von Grundstrukturen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
353
Fehlertoleranz
• Ein System ist fehlertolerant, wenn das
beabsichtigte Arbeitsergebnis trotz erkennbar
fehlerhafter Eingaben entweder mit keinem oder mit
minimalem Korrekturaufwand durch den Benutzer
erreicht werden kann.
• Praktische Anforderungen:
– Ist die Software gegen Fehleingaben robust?
– Kann der Benutzer Fehlersituationen leicht
korrigieren? Werden Vorschläge generiert?
– Warnung vor folgenschweren Fehlern
– Keine Werturteile („Unsinnige Eingabe!“)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
354
Erwartungskonformität
• Ein Dialog ist erwartungskonform, wenn er konsistent ist und
den Merkmalen des Benutzers entspricht, z.B. den Kenntnissen
aus dem Arbeitsgebiet, der Ausbildung und der Erfahrung
sowie allgemein anerkannten Konventionen.
• Praktische Anforderungen:
– Reagiert das System so, wie der Benutzer es erwartet?
– Entsprechen in Menüfolgen die suggerierten Abläufe dem
typischen Arbeitsablauf?
– Kann der Benutzer das Systemverhalten voraussagen?
– Konsistenz – anwendungsintern und
anwendungsübergreifend:
Platzierung, wiederkehrende Ablaufschemata, einheitliche
Funktionstastenbelegung, Sprache, Screen und Print
Grundkurs Software-Engineering mit UML
Stephan Kleuker
355
Aufgabenangemessenheit
• Ein System ist aufgabenangemessen, wenn es den
Benutzer unterstützt, seine Aufgabe effektiv und
effizient zu erledigen.
• Praktische Anforderungen:
– Muss der Benutzer unnötige Dialogschritte
durchführen?
– Sind überflüssige / ablenkende Informationen
vorhanden, die mit der Aufgabe nichts zu tun
haben?
– Erhält der Benutzer alle gewünschten
Ergebnisse?
– Vorgaben von Standardwerten, wenn sinnvoll
Grundkurs Software-Engineering mit UML
Stephan Kleuker
356
Selbstbeschreibungsfähigkeit
• Ein Dialog ist selbstbeschreibungsfähig, wenn jeder
einzelne Dialogschritt durch Rückmeldung des
Systems unmittelbar verständlich ist oder auf
Anfrage erklärt wird.
• Praktische Anforderungen:
– Sind alle für einen Arbeitsschritt benötigten
Informationen übersichtlich am Bildschirm
vorhanden?
– Weiß der Benutzer, was er als nächstes tun kann?
– Präzise, unmissverständliche und einfache
Systemmeldungen
– weiß der Nutzer, was das System macht?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
357
Steuerbarkeit
• Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den
Dialogablauf zu starten sowie seine Richtung und
Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist.
• Praktische Anforderungen:
– Kann der Benutzer seine Arbeitsschritte so steuern, wie es
von seiner Aufgabe her notwendig ist?
– Reihenfolge der Arbeitsschritte wählbar bei variablen oder
dynamischen Aufgaben
– Kann der Benutzer Arbeitsschritte unterbrechen oder
abbrechen, wenn dies erforderlich ist?
– Kann der Nutzer mit Maus und Tastatur manövrieren?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
358
Individualisierbarkeit
• Ein Dialog ist individualisierbar, wenn das System
Anpassungen an die Erfordernisse der Aufgabe,
individuelle Vorlieben und Fähigkeiten des
Benutzers zulässt.
• Praktische Anforderungen:
– Kann der Benutzer Layout und Funktion des
Systems an seine individuellen Anforderungen
anpassen?
– Können eigene Funktionen (z. B. Macros) definiert
werden?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
359
Anforderungsanalyse aus Usability-Sicht
10.3
• SOLL-Prozesse müssen mit dem Kunden und den
Endanwendern geklärt werden
• Vokabular der Kundenprozesse muss definiert sein
• potenzielle alternative Prozessabläufe müssen bekannt sein
• Technische Randbedingungen müssen definiert sein
Usability (insbesondere Web-Seiten):
• Welche gewünschten Nutzer haben welche Erfahrungen
(Computererfahrung /Alter)?
• Welche Technologie wird zur Implementierung eingesetzt
(Browser, Javascript, ASP, ActiveX, Applets)? [je mehr
heterogene Nutzer desto weniger Technik erlaubt]
• Wie werden erwünschte Nutzer verbunden? [Privat-Nutzer
häufiger noch über analoge Modems]
Grundkurs Software-Engineering mit UML
Stephan Kleuker
360
Design aus Usability-Sicht
• Typischerweise wird SW in Paketen und Schichten
entwickelt, meist wird die graphische Oberfläche als
eine Schicht in getrennten Paketen entwickelt
• Ansatz garantiert, dass Darstellung und Inhalt
konsequent getrennt werden, einheitliche
Darstellung wird erleichtert
• Ansatz hat Problem, dass die Schnittstelle sehr breit
wird, muss frühzeitig abgesprochen werden
• Entwicklung unterschiedlicher Oberflächenmasken
orientiert sich an gewünschten Prozessabläufen
(ähnlich zu einem Storyboard im Trickfilm)
• Gute Oberflächengestaltung ist Designern zu
überlassen (die Prozesse verstehen müssen)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
361
Integration der Oberflächenentwicklung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
362
Überblick über Usability-Testmethoden
10.4
• Expertenzentrierte Methoden
– heuristische Evaluation
– Guidelines und Checklisten
• Nutzerzentrierte Methoden
– Befragung
– Task-based Testing / Discount Usability Testing
– Thinking-Aloud-Tests
• Kombinationen der genannten Verfahren
Grundkurs Software-Engineering mit UML
Stephan Kleuker
363
Heuristische Evaluation
= eine Gruppe von externen Gutachtern untersucht
eine Website und überprüft, inwieweit diese mit
grundlegenden Prinzipien der Usability (sog.
Heuristiken) übereinstimmt.
• Die individuellen Einschätzungen werden zuerst
schriftlich fixiert und danach von der
Gutachtergruppe bewertet bzw. eingestuft.
• Vorteile:
– konkrete Benennung der einzelnen Defizite
– Empfehlungen zur Behebung derselben
• Nachteile:
– zeitintensiver Einsatz von teuren Experten
– passende Experten müssen gefunden werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
364
Guidelines und Checklisten
= eine Gruppe von (externen oder internen) Gutachtern
untersucht eine SW anhand von Guidelines und
Checklisten, in denen Usability-Kriterien
zusammengestellt sind.
• Antwortvorgaben resultieren in Zahlenwerten /
Noten.
• Besonders geeignet für ähnliche Websites.
• Vorteile:
– schnell und computergestützt realisierbar
– Ergebnisse erlauben unterschiedlichste
Auswertungen (Abhängigkeiten)
• Nachteile:
– stark formalisierte Ergebnisse (Gewichtungen?)
– Anpassungsbedarf für Einsatzbereich der Seite
Grundkurs Software-Engineering mit UML
Stephan Kleuker
365
Nutzerbefragung
• = mündlich, schriftlich (in Seite integriert, e-mail, online-Chat,
...); anhand von standardisierten Fragebögen oder als
qualitative Interviews;
• Zielgruppen sind (potenzielle) Benutzer
• mögliche Erkenntnisziele:
– Erwartungen einer Zielgruppe
– Nutzungsformen und Gründe dafür
– Vorkenntnisse und Nutzungsverhalten
– subjektive Erfahrungen von Versuchspersonen
• Vorteile:
– viele Einschätzungen einholbar
– unmittelbarer Kontakt mit Endnutzern
• Nachteile:
– Subjektivität der Ergebnisse (wer antwortet warum)
– mögliche Heterogenität der Ergebnisse
Grundkurs Software-Engineering mit UML
Stephan Kleuker
366
Task-based Testing / Discount Usability Testing
= typische Anfragen bzw. Aufgaben werden von für die
Zielgruppe typischen Nutzern bearbeitet
• Die Probanden werden dabei beobachtet, ihre
Reaktionen notiert und später evaluiert
• Vorteile:
– geringe Anzahl von Testpersonen erbringt schon
aussagekräftige Ergebnisse
– man sieht, wie Ergebnis von anderen genutzt wird
• Nachteile:
– Vorkenntnisse und Voreinstellungen der Tester
können die Analyse verzerren
– teilweise schwierige Findung typischer Anfragen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
367
Thinking-Aloud-Tests (1/2)
= Personen aus der gewünschten Nutzergruppe
bearbeiten ein zumeist vorgegebenes
Aufgabenszenario. Während der Bearbeitung sollen
sie ihre diesbezüglichen Gedanken und ihr Handeln
laut aussprechen bzw. kommentieren.
• Während des Tests werden in einem sog. UsabilityLabor Ton und Bild von der Versuchsperson sowie
Kopien des Bildschirminhalts aufgezeichnet.
• Ergänzend werden mit einem Screenrecorder die
Bewegungen auf dem Bildschirm aufgezeichnet.
• Anschließend werden die Daten zur Bewertung in
eine analysierbare Form gebracht.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
368
Thinking-Aloud-Tests (2/2)
• Vorteile:
– genaue Daten aus unterschiedlicher Perspektive
– wenige Probanden ergeben gute Einsichten
• Nachteile:
– aufwändige und teure Grundausstattung incl.
geschultem Personal nötig
– Fähigkeit der Testpersonen zur Verbalisierung
ihres Handelns und Denkens ist unterschiedlich
– ggf. ist Spontanität “ausgebremst”
(Laborsituation)
– Vorkenntnisse und Voreinstellungen der Tester
können die Analyse verzerren
Grundkurs Software-Engineering mit UML
Stephan Kleuker
369
Notwendige Anzahl von Testnutzern
Grundkurs Software-Engineering mit UML
Stephan Kleuker
370
11. Qualitätssicherung
11.1 Formale Korrektheit
11.2 Zusicherungen
11.3 Unit-Tests
11.4 Testbarkeit von Systemen herstellen
11.5 Äquivalenzklassentests
11.6 Kontrollflussbezogene Testverfahren
11.7 Testarten und Testumfeld
11.8 Metriken
11.9 Konstruktive Qualitätssicherung
11.10 Manuelle Prüfverfahren
Grundkurs Software-Engineering mit UML
Stephan Kleuker
371
Korrektheit
11.1
• Korrekt bedeutet: Unter folgenden Vorbedingungen sollen die
Ergebnisse des Programms folgende Nachbedingungen
erfüllen
• Wunsch alles zu testen meist nicht erfüllbar
public static boolean impliziert(boolean a,
boolean b){
return !a || b;
}
public static void main(String[] args) { // Tests
boolean werte[]={true,false};
for(boolean a:werte)
for(boolean b:werte)
System.out.println("a="+a+" b="+b
+" liefert "+impliziert(a,b));
}
• Tests sollen möglichst viele möglichst kritische Fehler finden
können
Grundkurs Software-Engineering mit UML
Stephan Kleuker
372
Ansatz: Model Checking
• Idee: Gegeben ist ein Modell (oder Spezifikation) und
eine Anforderung, dann überprüft der ModelChecking-Algorithmus, ob das Modell die
Anforderung erfüllt oder nicht. Falls das Modell die
Anforderung nicht erfüllt, sollte der Algorithmus ein
Gegenbeispiel liefern
• Theoretisches Ergebnis: Generell gibt es so ein
Verfahren nicht (unentscheidbar), man muss
Modellierungssprache und Anforderungslogik
einschränken
• Ansatz: Berechne alle erreichbaren Zustände und
analysiere sie
• Beispiel: SPIN entwickelt von Gerard Holzmann,
zunächst als Simulator, dann Verifikationswerkzeug
(www.spinroot.com)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
373
Assertions in JDK ab Version 1.4
11.2
•
Sprachänderung
– neues Keyword assert
•
Erweiterung des java.lang-Pakets
java.lang.AssertionError
•
Neue Dokumentation
– unter Guide to Features
– unter Assertion Facility
– unter javadoc
doc/guide/lang/assert.html
• Compiler-Option –source 1.4
javac –source 1.4 Klasse.java
damit javac assert akzeptiert
• Interpreter-Option –ea
java –ea Klasse
Grundkurs Software-Engineering mit UML
Stephan Kleuker
374
Syntax und Semantik von assert
assert überprüft zur Laufzeit eine Zusicherung, ist diese nicht
erfüllt, wird ein AssertionError ausgelöst
public void (int a, int b){
assert a>b && exemplar>5;
...
}
Syntax:
assert <Boolescher_Ausdruck>
assert <Boolescher_Ausdruck>:<bel_Objekt>
<bel_Objekt> ist meist ein String, der bei der Fehlermeldung
mit angezeigt wird
Grundkurs Software-Engineering mit UML
Stephan Kleuker
375
Kostenregel
• Zusicherungen sollen nichts kosten, wenn sie ausgeschaltet
sind [nicht immer zu 100% möglich].
• Falsch:
private static double EPS=0.000001;
public static double sqrt(double par) {
double res = Math.sqrt( par );
boolean test = Math.abs(par -res *res) < EPS;
assert test;
return res;
}
• Richtig:
assert Math.abs( par - res * res ) < EPS;
Grundkurs Software-Engineering mit UML
Stephan Kleuker
376
Vorbedingungsregel
• nur interne Vorbedingungen mit assert prüfen, die bei
korrekter Software erfüllt sein müssten
• kein Ersatz für Ausnahmen
Beispiel:
public double sqrt(double param) {
if ( param < 0 ) throw
new IllegalArgumentException("Negativer
Parameter");
return Math.sqrt( param );
}
• Nicht als zweite Zeile:
assert param >= 0;
• deswegen AssertionError und nicht AssertionException
• Assertions dürfen nur in der Entwicklung zu Fehlern führen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
377
Nachbedingungsregel
• Nachbedingungen lassen sich immer mit assert
beschreiben
• Typisch stehen Nachbedingungen unmittelbar vor
jedem return-Statement oder der abschließenden
geschweiften Klammer
• Beispiel
private static double EPS=0.000001;
public static double sqrt(double par) {
double res = Math.sqrt( par );
assert Math.abs( par - res * res ) < EPS;
return res;
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
378
Invariantenregel
• Invarianten von Objekten werden nach außen nie verletzt (bei
internen Berechnungen erlaubt)
• Ansatz: Invariante wird als eigenständige Methode
implementiert
private boolean invariant(...){
boolean erg = <Invariantenberechnung>;
return erg;
}
• Überprüfung der Invariante assert invariant(...); am
– Ende eines jeden Konstruktors
– am Anfang jeder public-Methode
– am Ende jeder public-Methode
Grundkurs Software-Engineering mit UML
Stephan Kleuker
379
Fehlermöglichkeiten mit assert
while (iter.hasNext()) {
assert iter.next() != null;
do_something( iter.next() );
}
public class Stack {
int size = 0;
...
public int length() {
assert this.length() >= 0;
return size;
} // length
} // Stack
Grundkurs Software-Engineering mit UML
Stephan Kleuker
380
JUnit
11.3
• Framework, um den Unit-Test eines JavaProgramms zu automatisieren
• einfacher Aufbau
• leicht erlernbar
• geht auf SUnit
(Smalltalk) zurück
• mittlerweile für
viele Sprachen
verfügbar
Grundkurs Software-Engineering mit UML
Stephan Kleuker
381
Konstruktiver Ansatz
• Testfälle werden in Java programmiert, keine
spezielle Skriptsprache notwendig
• Idee ist inkrementeller Aufbau der Testfälle parallel
zur Entwicklung
– Pro Klasse wird mindestens eine Test-Klasse
implementiert
• JUnit ist in Entwicklungsumgebungen integriert,
sonst muss das Paket junit.jar zu CLASSPATH
hinzugefügt werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
382
Testen mit JUnit
• Tests werden mit Methoden durchgeführt, die mit
Annotation @Test markiert sind
• Testmethoden haben typischerweise keinen
Rückgabewert (nicht verboten)
• Tests stehen typischerweise in eigener Klasse; für
Klasse X eine Testklasse XTest (können auch in zu
testender Klasse stehen)
• Mit Klassenmethoden der Klasse Assert werden
gewünschte Eigenschaften geprüft
Assert.assertTrue("korrekter Vorname"
,m.getVorname().equals("Ute"));
• JUnit steuert Testausführung, Verstöße bei
Prüfungen werden protokolliert
Grundkurs Software-Engineering mit UML
Stephan Kleuker
383
Assert (1/2)
• Die Klasse Assert definiert eine Menge von assertXY
Methoden, welche die Testklassen erben.
• Mit den assertXY Methoden können unterschiedliche
Behauptungen über den zu testenden Code aufgestellt werden.
• Trifft eine Behauptung nicht zu, wird ein Testfehler
protokolliert.
• assertTrue (boolean condition)
verifiziert, ob einen Bedingung wahr ist.
• assertEquals(Object expected, Object actual)
verifiziert, ob zwei Objekte gleich sind. Der Vergleich erfolgt mit
der equals Methode.
• assertEquals(int expected, int actual)
verifiziert, ob zwei ganze Zahlen gleich sind. Der Vergleich
erfolgt mit dem == -Operator.
• assertNull(Object object)
verifiziert, ob einen Objektreferenz null ist.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
384
Assert (2/2)
• assertEquals(double expected, double actual,
double delta)
verifiziert, ob zwei Fließkommazahlen gleich sind. Da
Fließkommazahlen nicht mit unendlicher Genauigkeit
verglichen werden können, kann mit delta ein Toleranzwert
angegeben werden.
• assertNotNull(Object object)
verifiziert, ob eine Objektreferenz nicht null ist.
• assertSame(Object expected, Object actual)
verifiziert, ob zwei Referenzen auf das gleiche Objekt verweisen.
• Für die primitiven Datentypen float, long, boolean,
byte, char und short existieren ebenfalls assertEquals
Methoden.
• Jede Assert-Methode gibt es mit einem zusätzlichen ersten
Parameter vom Typ String, dieser String wird zum Fehler
ausgegeben (also sinnvoll diese Methoden zu nutzen)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
385
Anmerkungen
• keine gute Idee: mehrere Asserts hintereinander
(scheitert das Erste, wird Zweite nicht betrachtet ->
Tests trennen)
• Assert-Methoden haben optionalen ersten StringParameter
• String kann genauere Informationen über erwartete
Werte enthalten, z. B. über toString-Methoden der
beteiligten Objekte
• generell reicht Assert.assertTrue() aus, gibt viele
weitere Methoden
• Um nicht immer die Klasse Assert vor Methoden
angeben zu müssen, kann man auch (persönlich
unschön) folgendes nutzen:
import static org.junit.Assert.*;
Grundkurs Software-Engineering mit UML
Stephan Kleuker
386
Test-Fixture
• Testfall sieht in der Regel so aus, dass eine
bestimmte Konfiguration von Objekten aufgebaut
wird, gegen die der Test läuft
• Menge von Testobjekten heißt Test-Fixture
• Damit fehlerhafte Testfälle nicht andere Testfälle
beeinflussen können, wird die Test-Fixture für jeden
Testfall neu initialisiert
• In der mit @Before annotierten Methode werden
Exemplarvariablen initialisiert
• In der mit @After annotierten Methode werden
wertvolle Testressourcen wie zum Beispiel
Datenbank- oder Netzwerkverbindungen wieder
freigegeben
Grundkurs Software-Engineering mit UML
Software-Qualität
387
Testen von Exceptions
• Exceptions in Java mit catch Block behandelt
• Mit der Methode fail aus der Assert Klasse wird
ein Testfehler ausgelöst und protokolliert
• Im Beispiel wird beim Aufruf des Konstruktors der
Klasse MyClass mit einer negativen Zahl die
IllegalArgumentException ausgelöst
@Test
public void testNegativeInitialisierung() {
try {
new MyClass(-10);
fail("Meine Meldung im Fehlerfall");
}catch (IllegalArgumentException e) {}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
388
Zu testende Klasse (1/2)
package kapitel11_Rabatt;
public class Rabatt {
private double rabatt;
private boolean gesperrt;
public Rabatt(double rabatt, boolean gesperrt) {
this.rabatt = rabatt;
this.gesperrt = gesperrt;
}
public boolean isGesperrt() {
return this.gesperrt;
}
public void setGesperrt(boolean gesperrt) {
this.gesperrt = gesperrt;
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
389
Zu testende Klasse (2/2)
public double getRabatt() {
return rabatt;
}
public void setRabatt(double rabatt) {
this.rabatt = rabatt;
}
double preis(double ursprungspreis)
throws RabattException{
if(this.gesperrt)
throw new RabattException();
return ursprungspreis*(1-(rabatt/100));
}
}
package kapitel11_Rabatt;
public class RabattException extends Exception {}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
390
Testfälle (1/3)
package kapitel11_Rabatt;
public class RabattTest {
// imports fehlen
private Rabatt gut;
private Rabatt boese;
@Before
protected void setUp() throws Exception {
super.setUp();
gut = new Rabatt(3.0,false);
boese = new Rabatt(0.0,true);
}
@Test
public void testGetRabatt(){
assertTrue(3.0 == gut.getRabatt());
assertTrue(0.0 == boese.getRabatt());
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
391
Testfälle (2/3)
@Test
public void testSetRabatt(){
gut.setRabatt(17.0);
assertTrue(17.0 == gut.getRabatt());
}
@Test
public void testIsGesperrt(){
assertTrue(!gut.isGesperrt());
assertTrue(boese.isGesperrt());
}
@Test
public void testSetGesperrt(){
gut.setGesperrt(true);
boese.setGesperrt(false);
assertTrue(gut.isGesperrt());
assertTrue(!boese.isGesperrt());
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
392
Testfälle (3/3)
@Test
public void testPreisErfolgreich(){
try {
double ergebnis=gut.preis(100.0);
assertEquals(ergebnis,97.0,0.001);
} catch (RabattException e) {
fail("falsche RabattException");
}
}
@Test
public void testPreisMitException(){
try {
boese.preis(100.0);
fail("fehlende RabattException");
} catch (RabattException e) {
}
}
public static void main(String[] args) {
junit.swingui.TestRunner.run(RabattTest.class);
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
393
TestSuite
Für große Projekte sind folgende Wünsche bzgl. der
Tests typisch:
a) mehrere Testklassen sollen zusammen laufen
können
b) man möchte Tests flexibel kombinieren können;
Testwiederholung soll davon abhängen, welche
Klassen betroffen sein können [schwierige
Weissagung]
c) man möchte Tests automatisiert ablaufen lassen
können möglich z. B.:
– JUnit hat Klassen zum einfachen Start von der
Konsole aus
– Nutzung eines cron-Jobs
zu a) und b) TestSuite in JUnit
Grundkurs Software-Engineering mit UML
Stephan Kleuker
394
Vergleich von JUnit und Assertions
• Assertions werden vom Entwickler eingesetzt um
Vor- und Nachbedingungen, sowie Invarianten zu
beschreiben
• Assertions können auch innerhalb von Methoden für
lokale Zustandsüberprüfungen eingesetzt werden
• Assertions werden tief in der Programmstruktur
eingesetzt, JUnit schaut auf die Schnittstellen der
Klassen von außen
• JUnit ist sehr mächtig, da nicht nur einzelne
Klassen, sondern auch die Zusammenarbeit von
Klassen geprüft werden kann (der Name „Unit“ ist
eher irreführend)
• Es spricht nichts dagegen, Assertions und JUnit
zusammen einzusetzen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
395
Klassen testbar machen
11.4
• Bei Objekten mit internen Zuständen ist der Test von außen mit
JUnit sehr schwierig
• es ist oftmals hilfreich, zusätzliche Methoden zu
implementieren, die das Testen einfacher machen
public String getInternenZustand(){ return "..." }
• Häufiger reicht ein get für den internen Zustand nicht aus, es
muss Methoden geben, mit denen man ein Objekt von außen in
einen gewünschten Zustand versetzen kann (Ergänzung
weiterer Testmethoden)
• Im Quellcode sollen Testmethoden eindeutig von anderen
Methoden getrennt sein, damit sie ggfls. automatisch gelöscht
werden können
• Bei komplexeren Klassen sollte man Teile der Entwicklung
bereits testen, hierzu müssen die aufgerufenen Methoden
zumindest in minimaler Form implementiert werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
396
Zusammenspiel von Klassen testen
• Bis jetzt wurde nur eine Klasse betrachtet, die keine
Assoziation zu anderen zu testenden Klassen hat, diese
Klassen werden elementare Klassen genannt
• Grundsätzlich sollte man versuchen, zunächst elementare
Klassen und dann Klassen, die auf diesen aufbauen, zu Testen
• Da es in der Entwicklung nicht garantiert werden kann, wann
Klassen vorliegen, muss man sich häufiger mit einem Trick
behelfen
• Dieser Trick ist es, die benötigte Klasse soweit selbst zu
implementieren, dass man die eigene Klasse testen kann. Diese
Klasse wird Mock genannt.
• Die Grundregel lautet, den Mock so primitiv wie möglich zu
halten
• Liegt die Klasse vor, die man temporär durch den Mock prüfen
wollte, müssen diese Tests mit der realen Klasse wiederholt
werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
397
Mocks programmieren
• Es wird zunächst eine Klasse mit den notwendigen Methoden
implementiert, die alle die leere Implementierung oder die
Rückgabe eines Dummy-Werts enthalten
public void setParameter(int parameter){}
public int getParameter() { return 0;}
• Diese Implementierung wird soweit ergänzt, dass wir unsere
Klasse testen können (möglichst einfache
Fallunterscheidungen, man bedenke, dass man von der
Korrektheit der anderen Klasse ausgeht)
• Es gibt Werkzeuge, die die einfachst möglichen Mocks
automatisch generieren, die können dann ergänzt werden
• D. h., neben den Tests entsteht ein zusätzlicher Codieraufwand
für Mocks, in größeren (erfolgreichen) Projekten kann der
Anteil des Testcodes am Gesamtcode in Abhängigkeit von der
Komplexität des Systems zwischen 30% und 70% liegen!
Grundkurs Software-Engineering mit UML
Stephan Kleuker
398
Beispiel für Mock-Erstellung (1/4)
public class Buchung {
public static LogDatei logging;
...
public synchronized void abbuchen(int id, Konto konto,
int betrag) throws BuchungsException{
if(konto.istLiquide(betrag)){
konto.abbuchen(betrag);
logging.schreiben(id+ " bearbeitet");
}
else{
logging.schreiben(id +" abgebrochen, insolvent");
throw new BuchungsException("insolvent");
}
}
...
}
• Zum Test der Methode abbuchen werden Test-Mocks der
Klassen Konto und LogDatei benötigt, Ziel ist es möglichst
einfache Mocks zu schreiben
Grundkurs Software-Engineering mit UML
Stephan Kleuker
399
Beispiel für Mock-Erstellung (2/4)
• Mock für LogDatei (wahrscheinlich) einfach
public class LogDatei { // Mock für Buchung
public void schreiben(String s){}
}
• Für Konto verschiedene Varianten denkbar, wichtig für unsere
Tests, dass istLiquide() true und false zurück geben kann
public class Konto { //Mock für Buchung
public boolean istLiquide(int betrag){
if( betrag < 1000) return true;
return false;
}
public void abbuchen(int betrag){}
}
• In dieser Variante muss sich der Tester den Schwellenwert zur
Prüfung merken (Mocks müssen auch getestet werden)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
400
Beispiel für Mock-Erstellung (3/4)
public class BuchungTest {//nutzen
private Konto konto;
private Buchung buchung;
@Before
protected void setUp() throws Exception {
Buchung.logging= new LogDatei();
buchung= new Buchung();
konto= new Konto();
}
@After
protected void tearDown() throws Exception {
// logging schließen}
@Test
public void testErfolreicheBuchung(){
try {
buchung.abbuchen(42,konto,100);
} catch (BuchungsException e) {
fail();
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
401
Beispiel für Mock-Erstellung (4/4)
@Test
public void testErfolgloseBuchung(){
try {
buchung.abbuchen(42,konto,2000);
fail();
} catch (BuchungsException e) {
} }...
• Die Tests des Mocks gehören in eine eigene Testklasse, da sie
später bei einer Testwiederholung für eine vollständige
Implementierung nicht wiederholt werden
• Werden kompliziertere Mock-Eigenschaften verlangt, sollte die
Klasse generell spezielle Konstruktoren oder Methoden zum
Setzen des internen Zustands beinhalten
• In Coding-Guidelines ist auf das Ziel der Testbarkeit
hinzuweisen, Programmierer müssen die internen Zustände
ihrer Klassen zu Testzwecken sichtbar machen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
402
Vererbung - Test von Unterklassen
• Tests einer Unterklasse C’ (einer Oberklasse C) sind
durchzuführen
• für alle neuen Methoden:
neue Testfälle aufstellen und ausführen
• für alle redefinierten Methoden:
neue Testfälle aufstellen und ausführen; semantisch ähnliche
Programm(teil)e müssen unterschiedlichen Tests unterzogen
werden
• für alle geerbten Methoden:
müssen alle Testfälle der Klasse C erneut durchgeführt werden;
Kontext der Unterklasse ist anders, erneuter Test daher
notwendig
nach : E. Perry, G. E. Kaiser, Adequate Testing and ObjectOriented Programming. Journal of Object-Oriented
Programming, Vol. 2, No. 5, Seiten 13-19
Grundkurs Software-Engineering mit UML
Stephan Kleuker
403
Klassen von Testfällen
11.5
In der Literatur gibt es recht unterschiedlich detaillierte
Klassifizierungen von Testfällen, eine erste grobe
Einteilungsmöglichkeit ist :
• Datenbezogene Testfälle: Ausgehend von der
Spezifikation des zu untersuchenden Objekts
werden verschiedene Eingaben überlegt, deren
gewünschtes Resultat aus der Spezifikation
abzuleiten ist
• Ablaufbezogene Testfälle: Es wird die Struktur des
zu untersuchenden Programms analysiert und
versucht, möglichst alle Ablaufalternativen (if, while)
durchzuspielen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
404
Äquivalenzklassenbildung
• Äquivalenzklassenbildung zerlegt Menge in
disjunkte Teilmengen
• jeder Repräsentant einer Teilmenge hat das gleiche
Verhalten bzgl. einer vorgegebenen Operation
• Beispiel: Restklassen (modulo x), werden zwei
beliebige Repräsentanten aus Restklassen addiert,
liegt das Ergebnis immer in der selben Restklasse
• Übertragungsidee auf Tests: Eingaben werden in
Klassen unterteilt, die durch die Ausführung des zu
testenden Systems zu „gleichartigen“ Ergebnissen
führen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
405
Beispiele für Äquivalenzklassen von Eingaben
• erlaubte Eingabe: 1 <= Wert <= 99 (Wert sei ganzzahlig)
– eine gültige Äquivalenzklasse: 1 <= Wert <= 99
– zwei ungültige Äquivalenzklassen: Wert < 1, Wert > 99
• erlaubte Eingabe in einer Textliste: für ein Auto können
zwischen einem und sechs Besitzer eingetragen werden
– eine gültige Äquivalenzklasse: ein bis sechs Besitzer
– zwei ungültige Äquivalenzklassen: kein Besitzer, mehr als
sechs Besitzer
• erlaubte Eingabe: Instrumente Klavier, Geige, Orgel, Pauke
– vier gültige Äquivalenzklassen: Klavier, Geige, Orgel, Pauke
– eine ungültige Äquivalenzklasse: alles andere, z.B. Zimbeln
Grundkurs Software-Engineering mit UML
Stephan Kleuker
406
Regeln zur Bildung von Äquivalenzklassen
• man muss mögliche Eingaben kennen (aus Spezifikation)
• für einfache Zahlenparameter meist einfach:
– Intervall mit gültigen Werten
– eventuell Intervall mit zu kleinen und Intervall mit zu großen
Werten (wenn z. B. alle int erlaubt, gibt es nur eine
Äquivalenzklasse, etwas schwieriger bei double))
• explizit eine Menge von Werten vorgegeben:
– jeder Wert eine Äquivalenzklasse dar
– andere Eingaben möglich: dies zusätzliche
Äquivalenzklasse
• falls nach Analyse der Spezifikation Grund zur Annahme
besteht, dass Elemente einer Äquivalenzklasse unterschiedlich
behandelt werden, ist die Klasse aufzuspalten
Grundkurs Software-Engineering mit UML
Stephan Kleuker
407
Beispiel (1/5)
Spezifikation:
• Als Beispiel dient eine Methode, genauer ein
Konstruktor, zur Verwaltung von Studierendendaten,
der ein Name, ein Geburtsjahr und ein Fachbereich
übergeben werden. Dabei darf das Namensfeld nicht
leer sein, das Geburtsjahr muss zwischen 1900 und
2000 liegen und es können nur die Fachbereiche
FBING, FBBWL und FBPOL aus einer Aufzählung
übergeben werden.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
408
Beispiel (2/5)
Äquivalenzklassen:
Eingabe
gültige
Äquivalenzklassen
ungültige
Äquivalenzklassen
Name
Ä1) nicht leer
Ä2) leer
Geburtsjahr
Ä4) 1900< =
Ä3) Geburtsjahr < 1900
Geburtsjahr <= 2000 Ä5) Geburtsjahr > 2000
Fachbereich
Ä6) FBING
Ä7) FBBWL
Ä8) FBPOL
Grundkurs Software-Engineering mit UML
Stephan Kleuker
409
Testfallerzeugung aus Äquivalenzklassen
• Die Äquivalenzklassen sind eindeutig zu
nummerieren. Für die Erzeugung von Testfällen aus
den Äquivalenzklassen sind zwei Regeln zu
beachten:
• gültige Äquivalenzklassen:
– möglichst viele Klassen in einem Test
kombinieren
• ungültige Äquivalenzklassen:
– Auswahl eines Testdatums aus einer ungültigen
Äquivalenzklasse
– Kombination mit Werten, die ausschließlich aus
gültigen Äquivalenzklassen entnommen sind.
– Grund: für alle ungültigen Eingabewerte muss
eine Fehlerbehandlung existieren
Grundkurs Software-Engineering mit UML
Stephan Kleuker
410
Beispiel (3/5)
Testfälle nach einer Äquivalenzklassenanalyse: (jeder Klasse
wird [mindestens] einmal getestet, die Testanzahl soll
möglichst gering sein)
Testnummer
1
geprüfte
Ä1
Äquivalenz- Ä4
klassen
Ä6
Name
2
3
4
5
6
(Ä1)
(Ä4)
Ä7
(Ä1)
(Ä4)
Ä8
Ä2
Ä3
Ä5
„Meier“
„Meier“
„Meier“ „Schmidt“ „Schulz“ „“
Geburtsjahr 1987
1985
1988
1892
2006
Fachbereich FBING FBBWL
FBPOL
FBING
FBING
FBING
Ergebnis
ok
Abbruch Abbruch Abbruch
ok
1989
ok
Grundkurs Software-Engineering mit UML
Stephan Kleuker
411
Grenzwertanalyse
• Viele Software-Fehler sind auf Schwierigkeiten in Grenzbereichen
der Äquivalenzklassen zurück zu führen (z.B. Extremwert nicht
berücksichtigt, Array um ein Feld zu klein)
• Aus diesem Grund wird die Untersuchung von
Äquivalenzklassen um die Untersuchung der Grenzen ergänzt
• Beispiel: 1<=Wert<=99 (wobei Wert ganzzahlig ist)
– Äquivalenzklasse Int-Wert<1: obere Grenze Wert=0 (untere
Grenze spielt hier keine Rolle)
– Äquivalenzklasse Int-Wert>99: untere Grenze Wert=100 (obere
Grenze spielt keine Rolle)
– Äquivalenzklasse 1<=Int-Wert<=99 : untere Grenze Wert=1
und obere Grenze Wert=99
• Diese Grenzfallbetrachtung kann direkt in die Testfallerzeugung
eingehen (es gibt Ansätze, bei denen zusätzlich ein Fall mit
einem Wert aus der „Mitte“ der Äquivalenzklasse genommen
wird)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
412
Beispiel (4/5)
• Testfälle nach einer Äquivalenzklassenanalyse und
Grenzwertanalyse
• Anmerkung: Testfallanzahl erhöht sich meist
Testnummer
1
geprüfte
Ä1
Äquivalenz- Ä4U
klassen
Ä6
Name
2
3
4
5
6
(Ä1)
Ä4O
Ä7
(Ä1)
(Ä4)
Ä8
Ä2
Ä3O
Ä5U
„Meier“ „Schmidt“ „Schulz“ „“
Geburtsjahr 1900
1985
1988
1899
2001
Fachbereich FBING FBBWL
FBPOL
FBING
FBING
FBING
Ergebnis
ok
Abbruch Abbruch Abbruch
ok
2000
„Meier“ „Meier“
ok
Grundkurs Software-Engineering mit UML
Stephan Kleuker
413
Beispiel (5/5)
• mögliche Übersetzung nach JUnit (Ausschnitt)
public class ImmatrikulationTest {
...
@Test
public void test1(){
try{
new Immatrikulation("Meier",1900,Bereich.FBING);
}catch(ImmatrikulationsException e){
fail("falsche Exception");
}
}
@Test
public void test4(){
try{
new Immatrikulation("",1988,Bereich.FBING);
fail("fehlende Exception");
}catch(ImmatrikulationsException e){
}
}
...
Grundkurs Software-Engineering mit UML
Stephan Kleuker
414
Schwierige Äquivalenzklassenbildung (1/4)
• Schreibe eine Methode max(), der drei Integer-Werte übergeben
werden, die den größten Wert dieser Werte zurück gibt
public class Maxi {
public static int max(int x, int y, int z){
int max=0;
if(x>z)max = x;
if(y>x)max = y;
if(z>y)max = z;
return max;
}
}
• nullter Klassenansatz: jeder Parameter darf beliebige Werte
annehmen, jeweils eine Klasse für x, y, z
• erster Klassen-Ansatz: es gibt keine Ausnahmefälle, also drei
Ergebnisse : Maximum steht an erster, zweiter oder dritter
Stelle
Grundkurs Software-Engineering mit UML
Stephan Kleuker
415
Schwierige Äquivalenzklassenbildung (2/4)
public class MaxiTest {
public MaxiTest(String arg0) {
super(arg0);
}
@Test
public void testErstesMax(){
assertTrue("Maximum an erster Stelle",
7==Maxi.max(7,5,4));
}
@Test
public void testZweitesMax(){
assertTrue("Maximum an zweiter Stelle",
7==Maxi.max(5,7,4));
}
Alle Tests laufen erfolgreich,
allerdings war die
Klassenbildung zu ungenau,
nächster Versuch mit den
Klassen:
x>=y>=z
x>=z>=y
z>=x>=y
z>=y>=x
y>=x>=z
y>=z>=x
[Frage: sind dies
Äquivalenzklassen ??]
@Test
public void testDrittesMax(){
assertTrue("Maximum an dritter Stelle",
7==Maxi.max(4,5,7));
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
416
Schwierige Äquivalenzklassenbildung (3/4)
• sechs Testfälle, Ausschnitt:
@Test
public void testXYZ(){
assertTrue("X>=Y>=Z", 7==Maxi.max(7,5,4));}
@Test
public void testXZY(){
assertTrue("X>=Z>=Y", 7==Maxi.max(7,4,5));}
@Test
public void testYXZ(){
assertTrue("Y>=X>=Z", 7==Maxi.max(5,7,4));}
• Fall X>=Z>=Y offenbart, dass das Verfahren nicht funktioniert
• Allerdings ist die Äquivalenzklassenwahl nicht sauber
Grundkurs Software-Engineering mit UML
Stephan Kleuker
417
Schwierige Äquivalenzklassenbildung (4/4)
• Saubere Äquivalenzklassen sind:
– x>y=z
y=z>x
– y>x=z
x=z>y
– z>y=x
y=x>z
– z>y>x
z>x>y
– y>z>x
y>x>z
– x>z>y
x>y>z
– x=y=z
• Bei Grenzwertanalyse muss der Übergang zwischen den
untersuchten Klassen betrachtet werden, d.h. wenn zwei oder
drei Argumente gleich sind (letzter Fall liefert auch Fehler)
• Aus der Spezifikation nicht ableitbar, allerdings gegebenenfalls
aus der Erfahrung mit der Mathematik zu ergänzen, ist die
Untersuchung des Verhaltens bei negativen Zahlen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
418
Äquivalenzklassenbildung und Objektorientierung
• Äquivalenzklassenbildung ist ein zentrales
Verfahren, um systematisch Tests aufzubauen
• für Methoden von Objekten spielt neben Ein- und
Ausgaben der interne Zustand häufig eine wichtige
Rolle (erst wenn Methode x ausführt wurde, dann
kann Methode y sinnvoll ausgeführt werden)
• Konsequenterweise muss man sich also mit dem
Ein-/Ausgabeverhalten pro möglichem
Objektzustand beschäftigen (was noch extrem
aufwändiger sein kann)
• das bisher vorgestellte Verfahren kann in der reinen
Form nur für gedächtnislose Objekte genutzt werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
419
Äquivalenzklassen und Objekte (1/5)
Spezifikation:
• In einem Bestellsystem wird für jeden Kunden im Objekt einer
Klasse Zuverlaessigkeit festgehalten, wie er bezüglich seines
Bezahlverhaltens eingestuft wird. Diese Einstufung wird durch
die folgende Aufzählung beschrieben.
public enum Bezahlstatus {
STANDARD, GEPRUEFT, KRITISCH;
}
• Die Klasse Zuverlaessigkeit soll eine Methode anbieten, mit der
geprüft werden soll, ob eine Bestellung über eine bestimmte
Summe ohne eine weitere Liquiditätsprüfung erlaubt werden
soll. Die Bestellung soll für geprüfte Kunden immer und für
kritische Kunden nie ohne zusätzliche Prüfung möglich sein.
Für sonstige Kunden muss eine Prüfung ab einer
Bestellstumme von 500€ erfolgen.
Grundkurs Software-Engineering mit UML
Stephan Kleuker
420
Äquivalenzklassen und Objekte (2/5)
public class Zuverlaessigkeit { // zu testen
private Bezahlstatus status;
public void setStatus(Bezahlstatus status){
this.status = status;
}
public boolean einkaufssummePruefen(int wert){
switch(this.status){
case GEPRUEFT:{
return true;
}
case STANDARD:{
return wert < 500;
}
}
return false;
}
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
421
Äquivalenzklassen und Objekte (3/5)
• erste Überlegung: nur Parameter wert zu testen, [wert<500] und
[wert>=500] (zwei Tests)
• zweite Überlegung: Objektzustand als weiteren Parameter
berücksichtigen; ergibt drei Testfälle: jeder Objektzustand mit
wert=499 oder wert=500 (Grenzwertanalyse) kombiniert
• dritte Überlegung: Kombination von Äquivalenzklassen
betrachten [status==STANDARD && wert==499] und
[status==STANDARD && wert==500] (d. h. vier Tests, noch
einen für GESPRUEFT und KRITISCH)
• vierte Überlegung: Alle Kombinationen betrachten (leider nur
selten machbar) (d. h. sechs Tests)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
422
Äquivalenzklassen und Objekte (4/5)
public class ZuverlaessigkeitTest extends {
private Zuverlaessigkeit zvl;
@Before
protected void setUp() throws Exception {
zvl = new Zuverlaessigkeit();
}
@Test
public void testGeprueft1(){
zvl.setStatus(Bezahlstatus.GEPRUEFT);
assertTrue(zvl.einkaufssummePruefen(499));
}
@Test
public void testGeprueft2(){
zvl.setStatus(Bezahlstatus.GEPRUEFT);
assertTrue(zvl.einkaufssummePruefen(500));
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
423
Äquivalenzklassen und Objekte (5/5)
}
@Test
public void testKritisch1(){
zvl.setStatus(Bezahlstatus.KRITISCH);
assertTrue(!zvl.einkaufssummePruefen(499));
}
@Test
public void testKritisch2(){
zvl.setStatus(Bezahlstatus.KRITISCH);
assertTrue(!zvl.einkaufssummePruefen(500));
}
@Test
public void testStandard1(){
zvl.setStatus(Bezahlstatus.STANDARD);
assertTrue(zvl.einkaufssummePruefen(499));
}
@Test
public void testStandard2(){
zvl.setStatus(Bezahlstatus.STANDARD);
assertTrue(!zvl.einkaufssummePruefen(500));
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
424
Kontrollflussgraph (KFG)
11.6
• eines Programms P ist ein gerichteter Graph
KFG(P) =def G = (V,E, VStart, VZiel)
• V: Menge der Knoten (Anweisungen des Programms)
• E ist Teilmenge von V×V: Menge der Kanten
(Nachfolgerelation bezüglich der Ausführung des
Programms)
• VStart , VZiel aus V : Ausgewählte Knoten für Start,
Ende des Programms
(VZiel kann auch eine Menge von Knoten sein)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
425
Beispiel: KFG
public int aha(int ein){
int erg=-ein/2;
//
int i=ein;
//
while(i>0){
//
erg=erg+(i--);
//
}
if (ein <0 || ein%2==1){//
erg=0;
//
}
return erg*2;
//
}
0
1
2
3
4
5
6
0
01
1
2
2
3
3
4
4
5
5
6
6
• Wunsch: Graph sollte unabhängig von der Formatierung sein!
• Programm gibt Quadrat aller positiven geraden Zahlen, sonst 0
zurück
• Testergebnisse werden vereinfachend bei folgenden
Testfallbeschreibungen weggelassen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
426
Normalisierung eines KFG durch Blockung
folgende Regeln, mit denen mehrere Knoten k1,k2,...,kn,
die nacheinander durchlaufen werden können, also
k1k2...kn, zu einem Knoten verschmolzen
werden.
• Die Knotenfolge wird bei jedem Durchlauf immer nur
über k1 betreten, es gibt außer den genannten
Kanten keine weiteren Kanten, die in k2,...,kn enden.
• Die Knotenfolge wird bei jedem Durchlauf immer nur
über kn verlassen, es gibt außer den genannten
Kanten keine weiteren Kanten, die in k1,...,kn-1
beginnen.
• Die Knotenfolge ist maximal bezüglich a) und b).
Grundkurs Software-Engineering mit UML
Stephan Kleuker
427
Analyse vollständiger Pfade
• Ein vollständiger Pfad ist eine Folge von verbundenen Knoten
(über Kanten) im KFG, die mit Vstart beginnt, und mit Vziel
endet.
• Die möglichen Ausführungsreihenfolgen des Programms sind
eine Teilmenge der vollständigen Pfade
• Wunsch: Durchlauf „repräsentativer“ vollständiger Pfade beim
Test
• Überdeckung aller vollständigen Pfade ist im allgemeinen nicht
ausführbar
• Ansatz: Verschiedene Approximationsstufen
(Anweisungsüberdeckungstest, ..., MehrfachBedingungsüberdeckungstest) für die Menge der vollständigen
Pfade bei Auswahl der Testdurchläufe wählen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
428
Anweisungsüberdeckung (C0)
• Ziel: alle Anweisungen des Programms durch Wahl geeigneter
Testdaten mindestens einmal ausführen, alle Knoten des KFG
mindestens einmal besuchen.
Anzahl der ausgeführten Knoten
• Testmaß
C0=
|V|
• Ziel: C0=1 (=100%)
• für {-1}
C0=
5/6
• für {-1,0}
C0=
5/6
• für {-1,2}
C0=
6/6
C0=
Grundkurs Software-Engineering mit UML
ein=-1
ein=0
ein=1
ein=2
01
01
01
01
2
2
2
2
3
3
3
3
4
4
4
4
5
5
5
5
6
6
6
6
5/6
4/6
6/6
5/6
Stephan Kleuker
429
Zweigüberdeckung (C1)
• Ziel :alle Kanten des KFG überdecken, d.h. alle Zweige des
Programms einmal durchlaufen
• Testmaß
Anzahl der durchlaufenen Kanten
C1=
|E|
ein=-1
• Ziel: C1=1
• für {-1}
C1=
4/7
• für {-1,0}
C1=
5/7
• für {-1,2}
C1=
7/7
C1=
Grundkurs Software-Engineering mit UML
ein=0
ein=1
ein=2
01
01
01
01
2
2
2
2
3
3
3
3
4
4
4
4
5
5
5
5
6
6
6
6
4/7
3/7
6/7
5/7
Stephan Kleuker
430
Kommentare zur Anweisungs- und Zweigüberdeckung
• Vorteile der Anweisungsüberdeckung:
– einfach
– geringe Anzahl von Eingabedaten
– nicht ausführbare Programmteile werden erkannt
• großer Nachteil der Anweisungsüberdeckung:
– Logische Aspekte werden nicht überprüft
• deshalb: Zweigüberdeckungstest gilt als das Minimalkriterium
im Bereich des dynamischen Softwaretests,
– schließt den Anweisungsüberdeckungstest ein,
– fordert die Ausführung aller Zweige eines KFG,
– jede Entscheidung mindestens einmal wahr und falsch
• Nachteile der Zweigüberdeckung:
– Fehlende Zweige werden nicht automatisch entdeckt
– Kombinationen von Zweigen sind unzureichend geprüft
– Komplexe Bedingungen werden nicht analysiert
– Schleifen werden nicht ausreichend analysiert
Grundkurs Software-Engineering mit UML
Stephan Kleuker
431
Einfache Bedingungsüberdeckung
• Ziel: Teste gezielt Bedingungen in Schleifen und
Auswahlkonstrukten
• Bedingungen sind Prädikate
– A1,..., A4 atomar
• z.B. (x==1) [auch !(x==1)]
– zusammengesetzt
• Konjunktion K
• Disjunktion D
• ( ( (x==1) || (x==2) )&&( (y==3) || (y==4) ) ) hat
7 Teilprädikate: x==1, x==2, y==3, y==4, (x==1) || (x==2),
(y==3) || (y==4) , ( ( (x==1) || (x==2) )&&( (y==3) || (y==4) ) )
• Hinweis: Bei Java und anderen Programmiersprachen ist der
Unterschied zwischen || und && (mit Kurzschlussauswertung)
und | und & (ohne Kurzschlussauswertung) zu beachten
if(true || 5/0==0) läuft, if(true | 5/0==0) läuft nicht
Grundkurs Software-Engineering mit UML
Stephan Kleuker
432
Einfache Bedingungsüberdeckung (C2)
• Ziel: alle atomaren Prädikate einmal TRUE, einmal FALSE
|wahre Atome| + |falsche Atome|
• Testmaß:
C2=
2 * |alle Atome|
• |alle Atome| =Anzahl aller Atome, |wahre Atome|= Anzahl aller
Atome, die mit true ausgewertet werden (analog | falsche
Atome|)
Testfälle {-1} {0} {1} {2}
{-1,0} {0,1} {1,2} {-1,1} {-1,1,2}
i>0
f
f
f,t
f,t
f
f,t
f,t
f,t
f,t
ein<0
t
f
f
f
t,f
f
f
t,f
t,f
ein%2==1 -
f
t
f
f
f,t
t,f
t
t,f
C2-Überdeckung
3/6 4/6 4/6
4/6
5/6
5/6
5/6
6/6
2/6
Grundkurs Software-Engineering mit UML
Stephan Kleuker
433
Kein Zusammenhang zwischen C1 und C2
• Die Nummerierung C1, C2 ist historisch gewachsen
• betrachte if (a || b)
– a=true, b=false
a=false, b=true
• garantiert vollständige einfache
Bedingungsüberdeckung (C2)
• else-Zweig wird nicht durchlaufen, keine Zweigoder Anweisungsüberdeckung (C1, C0)
– a=true, b=false
a=false, b=false
• if- und else-Zweig wird durchlaufen, damit
Zweig- und Anweisungsüberdeckung
• keine vollständige einfache
Bedingungsüberdeckung, da b=true fehlt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
434
Minimale Mehrfachbedingungsüberdeckung (C3)
• Ziel: alle Prädikate und Teil-Prädikate einmal TRUE, einmal
FALSE
|wahre Teilprädikate| + |falsche Teilprädikate|
C3=
• Testmaß:
2 * |alle Teilprädikate|
Testfälle {-1} {0} {1} {2}
{-1,0} {0,1} {1,2} {-1,1} {-1,1,2}
i>0
f
f
f,t
f,t
f
f,t
f,t
f,t
f,t
ein<0
t
f
f
f
t,f
f
f
t,f
t,f
ein%2==1 -
f
t
f
f
f,t
t,f
t
t,f
ein<0 ||
ein%2==1
t
f
t
f
t,f
f,t
t,f
t
t,f
C3-Überdeckung
3/8
4/8 5/8 5/8
6/8
7/8
7/8
6/8
8/8
Grundkurs Software-Engineering mit UML
Stephan Kleuker
435
Zusammenhang zwischen den Testverfahren
Anmerkung: Diese Thema
kann noch wesentlich
vertieft werden
Minimaler
Mehrfachbedingungsüberdeckungstest (C3)
Zweigüberdeckungstest (C1)
Einfacher Bedingungsüberdeckungstest (C2)
Anweisungsüberdeckungstest (C0)
vollständige Überdeckung des einen bedeutet
vollständige Überdeckung des anderen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
436
Automatisierung der Ci-Tests
• Ohne eine Tool-Unterstützung ist es sehr aufwändig
und fehlerträchtig, solche Überprüfungen zu machen
• Für andere Sprachen als Java (und C#) sind
Coverage-Werkzeuge vorhanden, die man bzgl. der
zu untersuchenden Überdeckung einstellen kann
• Für Java gibt es nur verschiedene Programme, die
den Anweisungsüberdeckungstest und teilweise den
Zweigüberdeckungstest (CoceCover, Eclemma,
Coverlipse, JCoverage, Hansel für JUnit, Clover)
unterstützen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
437
Info: Standard DO-178B
•
•
•
•
•
•
Um die Zertifizierung der Federal Aviation Administration (FAA) zu
erhalten, muss Software für Luftverkehrssysteme den Richtlinien des
Standards DO-178B für requirement-basiertes Testen und Code
Coverage Analysen genügen.
DO-178B-Levels orientieren sich an den Konsequenzen möglicher
Softwarefehler: katastophal (Level A), gefährlich/schwerwiegend
(Level B), erheblich (Level C), geringfügig (Level D) bzw. keine
Auswirkungen (Level E).
Je nach DO-178B-Level wird der 100%-ige Nachweis folgender
Testabdeckungen (Code Coverages) verlangt:
DO-178B Level A:
– Modified Condition Decision Coverage (MC/DC)
– Branch/Decision Coverage
– Statement Coverage
DO-178B Level B:
– Branch/Decision Coverage
– Statement Coverage
DO-178B Level C:
– Statement Coverage
Grundkurs Software-Engineering mit UML
Stephan Kleuker
438
Teststufen (grober Ablauf)
11.7
Klassentest
entwicklungsintern
Integrationstest
Systemtest
entwicklungsextern (mit Kunden)
Grundkurs Software-Engineering mit UML
Abnahmetest
Stephan Kleuker
439
Klassentest (Modultest)
• Varianten:
– Unit-Test: einzelne Methoden und/oder Klassen
– Modultest: logisch-zusammengehörige Klassen,
z.B. ein Package in Java
• Testziel: Prüfung gegen Feinspezifikation
– Architektur, Design, Programmierkonstrukte
• Testmethode: White-Box-Test
• Alle Module müssen getestet werden
– eventuell mit unterschiedlicher Intensität
Grundkurs Software-Engineering mit UML
Stephan Kleuker
440
Integrationstest
• Module werden zu einem System integriert und gemeinsam
getestet
• Testziele:
– Werden Schnittstellen richtig benutzt?
– Werden Klassen bzw. ihre Methoden richtig aufgerufen?
• Konzentration auf (Export-) Schnittstellen
– Interne Schnittstellen können nicht mehr direkt beeinflusst
werden
– Geringere Testtiefe als beim Modultest
– Grey-Box-Test (oder auch Black-Box)
• Techniken ähnlich wie bei Modultest
– Pfadanalyse über die komplette Interaktion der Module oft
nicht mehr sinnvoll
• Mit minimaler Systemkonfiguration beginnen,
Integrationsstrategie spielt eine Rolle
Grundkurs Software-Engineering mit UML
Stephan Kleuker
441
Systemtest
• Orientierung an den spezifizierten Systemaufgaben (z.B. Use
Cases)
• Interaktion mit den (simulierten) Nachbarsystemen
• (endgültige) Validierung der nicht-funktionalen Anforderungen,
z.B. Skalierbarkeit, Verfügbarkeit, Robustheit, ...
• wichtige Teilaufgabe: Testdaten-Verwaltung
– Wiederherstellung des ursprünglichen Zustands der
Testdaten
– Autarke Datenbestände:
Kein gegenseitiges “Zerschießen“ der Testdaten
– für DB: Kollisionen in den Nummernkreisen der
Schlüsselattribute vermeiden
– Datumsfelder können altern. Wie können Testdaten zum
aktuellen Datum passen?
• Tagesdatum aus (manipuliertem) Kalender-Modul holen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
442
Testansätze zusammengefasst
White-Box-Test
Gray-Box-Test
Anweisungen
Entscheidungen
Pfade
Black-Box-Test
Paket/
Komponente
Eingaben
Schnittstellen
System
Ausgaben
Methoden-/Klassentest
Grundkurs Software-Engineering mit UML
Integrationstest
Stephan Kleuker
Systemtest
443
Testfälle und die UML
Entwicklung in der UML
Testen
Use Case Diagramme
Systemtestfälle
Aktivitätsdiagramme
Komponentendiagramme
Integrationstestfälle
Sequenzdiagramme
Klassentestfälle
Klassendiagramme
Zustandsdiagramme
Grundkurs Software-Engineering mit UML
Stephan Kleuker
444
Effiziente Massentests
• Oftmals muss man recht ähnliche Daten zum Testen
nutzen, dabei bietet es sich an, diese Testdaten in
einem File zu speichern und die Daten schrittweise
auszulesen
• Generell können professionelle Testwerkzeuge meist
Daten aus Datenbanken, kommaseparierten Listen,
Excel-Files, ... lesen
• TestNG als JUnit-Erweiterung erlaubt
Testdatengenerierung für Unit-Tests
Grundkurs Software-Engineering mit UML
Stephan Kleuker
445
Prinzip des Regressionstests
Software
Version n
Testfallspezifikation
Version n
Test
Testarchivierung
der Iteration n
Referenztestfälle
Testfallergebnisse
Software
Version n+1
Regressionstest
Testfalldatenbank
Vergleich der
Testergebnisse
Grundkurs Software-Engineering mit UML
Stephan Kleuker
446
Regressionstests im Entwicklungszyklus
Testfallentwicklung
erste Entwicklung
Version 1
Test
Testfallentwicklung
Weiterentwicklung
Regressionstestfälle
Test
Testfallentwicklung
Version 2
Weiterentwicklung
Regressionstestfälle
Test
Grundkurs Software-Engineering mit UML
Version n
Stephan Kleuker
447
Regressionstest
• Änderungen an bereits freigegebenen Modulen sind
notwendig
• Gibt es Auswirkungen auf die alten Testergebnisse?
• Wenn ja, welche?
• Wiederholbarkeit der Tests
• Wiederherstellung der Testdaten
• Der Testprozess muss automatisierbar sein
• Testfälle müssen gruppiert werden können, damit
man sie wegen der untersuchten Funktionalität (oder
auch Testdauer) gezielt einsetzen kann
Grundkurs Software-Engineering mit UML
Stephan Kleuker
448
Wartung und Testen
• Der Test ist geteilt in Änderungstest (White-Box) und
Regressionstest (Black-Box)
• Änderungstest vom Entwickler, er schreibt die
Testfälle fort.
• Regressionstest von unabhängiger Testgruppe mit
den alten plus neuen Testfällen durchgeführt
• Testgruppe ist für Pflege und Fortschreibung der
Systemtestfälle verantwortlich
Grundkurs Software-Engineering mit UML
Stephan Kleuker
449
Lasttest
• Geforderte Performance
– Durchsatz bzw. Transaktionsrate
– Antwortzeiten
• Skalierbarkeit
– Anzahl Endbenutzer
– Datenvolumen
– Geografische Verteilung
• Zugriffskonflikte konkurrierender Benutzer
• Entspricht dem Zeitraum nach der Inbetriebnahme
• Simulation von
– Anzahl Endbenutzer,
– Transaktionsrate , ...
– Über einen signifikanten Zeitraum (mehrere Stunden)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
450
Untersuchung des Laufzeitverhaltens
• wie oft wird jede Methode aufgerufen (oder Quellcodezeile
durchlaufen)
• welche Methode ruft wie oft welche andere Methode
(descendants) auf oder von welchen Methoden (callers) wird
eine Methode wie oft gerufen
• wie viel Prozent der Gesamtlaufzeit wird mit Ausführung einer
bestimmten Methode verbracht (ggf. aufgeteilt nach callers und
descendants)
Nutzen der ermittelten Daten
• Operationen, die am meisten Laufzeit in Anspruch nehmen,
können leicht identifiziert (und optimiert) werden
• tatsächliche Aufrufabhängigkeiten werden sofort sichtbar
Grundkurs Software-Engineering mit UML
Stephan Kleuker
451
Untersuchung des Speicherplatzverhaltens
• welche Operationen fordern wie viel Speicherplatz an (geben
ihn frei)
• wo wird Freigabe von Speicherplatz vermutlich bzw. bestimmt
vergessen (memory leak = Speicherloch):
• bestimmt vergessen: Objekt lebt noch, kann aber nicht mehr
erreicht werden (Garbage Collector von Java würde es
entsorgen)
• vermutlich vergessen: Objekt lebt noch und ist erreichbar, wird
aber nicht mehr benutzt (Garbage Collector von Java kann es
nicht freigeben)
• wo wird auf bereits freigegebenen Speicherplatz zugegriffen
(nur für C++) bzw. wo wird Speicherplatz mehrfach freigegeben
(nur für C++)
• wo wird auf nicht initialisierten Speicherplatz zugegriffen;
anders als bei der statischen Programmanalyse wird für jede
Feldkomponente (Speicherzelle) getrennt Buch darüber geführt
• wo finden Zugriffe jenseits der Grenzen von Arrays statt
(Laufzeitfehler in meisten Programmiersprachen)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
452
Lasttest und Speicherverhalten in Java
• Hinweis: Java unterstützt das „Profiling“, hierzu
stehen explizite Compiler- und Ausführungsoptionen
zur Verfügung
• kommerzielle Produkte, z. B. „IBM/Rational Purify
und Quantifiy
• freies Werkzeug:
– JMeter: http://jakarta.apache.org/jmeter/
(besonders interessant für Lasttests von WebServern und Datenbankzugriffen)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
453
Test von Oberflächen
• Grundsätzlich sind Oberflächen gewöhnliche SW-Module und
können wie diese getestet werden.
• Für xUnit-Werkzeuge ist der Zugriff auf Oberflächen teilweise
schwierig (xUnit muss auf Oberflächenkomponenten zugreifen
und diese bedienen können, JButton in Java hat z.B. Methode
doClick())
• Für Oberflächen gibt es deshalb Capture & Replay-Werkzeuge
• Grundidee: Das Werkzeug zeichnet alle Mausbewegungen und
Tastatureingaben auf, die können dann zur Testwiederholung
erneut abgespielt werden
• Typisch ist, dass der Nutzer die aufgezeichneten Skripte
modifizieren kann (z. B. Test von berechneten Daten)
• Tools können teilweise auch Oberfläche lesen (Frage ob Texte
richtig ausgegeben), Snapshots vergleichen
• professionelle Beispiele: Winrunner von HP (früher Mercury),
VisualTest von IBM-Rational
• zum Ausprobieren: Abbot (http://abbot.sourceforge.net/)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
454
Nutzung von Maßsystemen
• Die bisherigen Überprüfungsverfahren sind recht aufwändig,
es besteht der Wunsch, schneller zu Qualitätsaussagen zu
kommen
• Der Ansatz ist die Einführung eines Maßsystems, aus dem
System werden Zahlenwerte generiert, deren Werte ein Indiz
für die Qualität eines Produktes geben
• Werden diese Maße automatisch berechnet, kann man
Qualitätsforderungen stellen, dass bestimmte Maßzahlen in
bestimmten Bereichen liegen
• Wichtig ist, dass man weiß, dass nur Indikatoren betrachtet
werden, d.h. gewonnene Aussagen müssen nachgeprüft
werden
• Ähnliche Ansätze in der Projektverfolgung und Analyse der
Firmengesamtlage (-> Balanced Scorecard)
-> siehe Qualitätsmanagement
Grundkurs Software-Engineering mit UML
Stephan Kleuker
455
Metriken zur Ermittlung des Projektstands
11.8
programmiert/
überdeckt
100%
50%
0%
Use
Cases
Grundkurs Software-Engineering mit UML
Pakete
C1-Überdeckung
Stephan Kleuker
C2-Überdeckung
456
Grobe Metriken (Min, Max, Schnitt, Abweichung)
• Lines of Code pro Methode (LOC)
Nach der Grundregel des guten Designs sollte die maximale
Zahl unter 20 liegen
• Methoden pro Klasse
Die Zahl sollte zwischen 3 und 15 liegen
• Parameter pro Methode
Die Zahl sollte unter 6 liegen
• Exemplarvariablen pro Klasse
Die Zahl sollte unter 10 liegen [Entitäten ?]
• Abhängigkeiten zwischen Klassen
Keine Klasse sollte von mehr als vier Klassen abhängen
• andere Maßzahlen, wie die Anzahl von Klassenvariablen und
Klassenmethoden können auch als Indikatoren eingesetzt
werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
457
Zyklomatische Zahl nach McCabe
1. Man konstruiere die Kontrollflussgraphen
2. Man messe die strukturellen Komplexität
Die zyklomatische Zahl z(G) eines
Kontrollflussgraphen G ist:
z(G) = e – n + 2 mit
• e = Anzahl der Kanten des Kontrollflussgraphen
• n = Anzahl der Knoten
Zyklomatische Komplexität gibt Obergrenze für die
Testfallanzahl für den Zweigüberdeckungstest an
In der Literatur wird 10 oft als maximal vertretbarer Wert
genommen (für OO-Programme geringer, z. B. 5)
für Java: #if + #do + #while + #switch-cases+ 1
Grundkurs Software-Engineering mit UML
Stephan Kleuker
458
Beispiele für die zyklomatische Zahl
Anzahl
Kanten
Anzahl
Knoten
McCabe
Zahl
0
2
4
3
6
1
3
4
3
5
1
1
2
2
3
Grundkurs Software-Engineering mit UML
Stephan Kleuker
459
Erweiterte McCabe-Zahl
• Komplexität von Verzweigungen berücksichtigen
• gezählt werden alle Booleschen Bedingungen in
if(<Bedingung>) und while(<Bedingung>):
anzahlBedingung
• gezählt werden alle Vorkommen von atomaren
Prädikaten: anzahlAtome
z. B.: ( a || x>3) && y<4 dann anzahlAtome=3
• erweitere McCabe-Zahl
ez(G) = z(G) + anZahlAtome - anzahlBedingung
• wenn nur atomare Bedingungen, z. B. if( x>4), dann
gilt ez(G) = z(G)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
460
Lack of Cohesion in Methods (LCOM*)
• nutzt(a) die Zahl der Methoden, die eine Exemplarvariable a der
untersuchten Klasse nutzen
• sei avgNutzt der Durchschnitt aller Werte für alle
Exemplarvariablen
• sei m die Anzahl aller Methoden der untersuchten Klasse
• LCOM* = (avgNutzt–m) /(1-m)
• Ist der Wert nahe Null, handelt es sich um eine eng
zusammenhängende Klasse
• Ist der Wert nahe 1, ist die Klasse schwach zusammenhängend,
man sollte über eine Aufspaltung nachdenken
• Hinweis: Es muss vorher festgelegt werden, ob
Klassenvariablen und Klassenmethoden berücksichtigt werden
sollen
• Was passiert, wenn man konsequent exzessiv OO macht und
auch in den Exemplarmethoden get() und set() Methoden nutzt?
Wie ist LCOM* dann rettbar?
Grundkurs Software-Engineering mit UML
Stephan Kleuker
461
LCOM*-Beispiel
public class LCOMSpielerei {
private int a;
private int b;
private int c;
public void mach1(int x){
a=a+x;
}
public void mach2(int x){
a=a+x;
b=b-x;
}
nutzt(a)=3
nutzt(b)=2
nutzt(c)=1
avgNutzt=6/3=2
LCOM*= (2-3) /(1-3)
= -1/-2= 0.5
public void mach3(int x){
a=a+x;
für Eclipse gibt es Plugin Metrics
b=b-x;
http://sourceforge.net/projects/metrics/
c=c+x;
berechnet u. A. erweiterte
}
MCCabe-Zahl und LCOM*
}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
462
Konstruktive Qualitätssicherung
11.9
• die analytische Qualitätssicherung greift erst, wenn
ein Produkt erstellt wurde
• interessant ist der Versuch, Qualität bereits bei der
Erstellung zu beachten
• typische konstruktive Qualitätsmaßnahmen sind
– Vorgabe der SW-Entwicklungsumgebung mit
projekteigenem Werkzeughandbuch, was wann
wie zu nutzen und zu lassen ist
– Stilvorgaben für Dokumente und Programme
(sogenannte Coding-Guidelines)
• Die Frage ist, wie diese Maßnahmen überprüft
werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
463
Coding Guidelines
• Detailliertes Beispiel: Taligent-Regeln für C++
(http://pcroot.cern.ch/TaligentDocs/TaligentOnline/D
ocumentRoot/1.0/Docs/index.html)
• Sun hat auch Regeln für Java herausgegeben (nicht
ganz so stark akzeptiert)
• z. B. Eclipse-Erweiterung Checkstyle
• Generell gibt es Regeln
– zur Kommentierung,
– zu Namen von Variablen und Objekten (z.B.
Präfix-Regeln),
– zum Aufbau eines Programms (am schwierigsten
zu formulieren, da die Programmarchitektur
betroffen ist und es nicht für alle Aspekte „die
OO-Regeln“ gibt)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
464
Beispiel-Coding-Regel
•
•
Ausschnitt aus „Java Code Conventions“, Sun, 1997
Inhalt soll sich nicht nur auf Formatierung beziehen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
465
Anti-Pattern
• Pattern dienen zur sinnvollen Strukturierung komplexer, aber
gleichartiger Systeme
• Anti-Pattern sind wiederkehrende schlechte Lösungen, die man
an Strukturen erkennen kann, z. B.
– Spaghetti-Code, viele if, while und repeat-Schleifen
gemischt, intensive Nutzung der Möglichkeiten mit break,
früher: goto
– Cut-and-Paste-Programmierung: „was oben funktionierte,
funktioniert hier auch“
– allmächtige Klassen, kennen jedes Objekt, sitzen als Spinne
im Klassendiagramm, immer „gute“ Quelle für
Erweiterungen
– Rucksack-Programmierung: bei vergessenem Sonderfall in
allen betroffenen Methoden
if (Sonderfall){ Reaktion } else { altes Programm}
• Literatur (z. B.): W. J. Brown, R. C. Malveau, H. W. McCormick
III, T. J. Mowbray, AntiPatterns, Wiley, 1998
Grundkurs Software-Engineering mit UML
Stephan Kleuker
466
Manuelle Prüfmethoden
11.10
• Produkte und Teilprodukte werden manuell
analysiert, geprüft und begutachtet
• Ziel ist es, Fehler, Defekte, Inkonsistenzen und
Unvollständigkeiten zu finden
• Die Überprüfung erfolgt in einer Gruppensitzung
durch ein kleines Team mit definierten Rollen
• Anmerkung: Es werden hier Inspektionen, Reviews
und Walkthroughs betrachtet (in abnehmender
Formalität), in der Literatur ist „Reviews“ teilweise
der Oberbergriff
Grundkurs Software-Engineering mit UML
Stephan Kleuker
467
Voraussetzungen manueller Prüfmethoden
• notwendigen Aufwand und benötigte Zeit einplanen
• Jedes Mitglied des Prüfteams muss in der
Prüfmethode geschult sein
• Prüfergebnisse nicht zur Beurteilung von
Mitarbeitern nutzen
• Die Prüfmethode muss schriftlich festgelegt und
deren Einhaltung überprüft werden
• Prüfungen haben hohe Priorität, d.h. sie sind nach
der Prüfbeantragung kurzfristig durchzuführen
• Vorgesetzte und Zuhörer sollen an den Prüfungen
nicht teilnehmen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
468
Inspektionsablauf (1/3)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
469
Inspektionsablauf (2/3)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
470
Inspektionsablauf (3/3)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
471
weitere manuelle Prüfmethoden (1/2)
Review
• weniger formal als Inspektion
• Gutachter überprüfen ein schriftliches Dokument, um dessen
Stärken und Schwächen festzustellen
• Review-Ablauf ist im wesentlichen wie der Ablauf einer
Inspektion. Die Unterschiede bestehen darin, dass:
– der Autor dabei ist (passiv und um Missverständnisse zu
klären),
– der Autor die verteilten und markierten Kopien des
Prüfobjekts erhält und
– das Review-Team im Falle einer Zurückweisung eine
erneute Sitzung verlangen kann
• Während des Reviews werden keine Lösungen diskutiert!
Damit gute Ideen nicht verloren gehen, kann eine formlose
„dritte Stunde“ angehängt werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
472
weitere manuelle Prüfmethoden (2/2)
Walkthrough
• ist abgeschwächte Form des Reviews
• Autor leitet als Moderator die Walkthrough-Sitzung
• Zu Beginn [evtl. früher] der Sitzung erhält jeder
Gutachter eine Kopie des Prüfobjektes
• Das Prüfobjekt wird Schritt für Schritt vorgestellt
und die Gutachter stellen spontane Fragen und
versuchen so, mögliche Probleme zu identifizieren
• Probleme werden protokolliert
• Walkthrough-Variante besteht darin, vor der Sitzung
eine individuelle Vorbereitung durchzuführen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
473
Vor- und Nachteile manueller Prüfmethoden
+ Oft die einzige Möglichkeit, Semantik zu überprüfen
+ Notwendige Ergänzung werkzeuggestützter Überprüfungen
+ Die Verantwortung für die Qualität der geprüften Produkte wird
vom ganzen Team getragen
+ Da die Überprüfungen in einer Gruppensitzung durchgeführt
werden, wird die Wissensbasis der Teilnehmer verbreitert
+ Jedes Mitglied des Prüfteams lernt die Arbeitsmethoden seiner
Kollegen kennen
+ Die Autoren bemühen sich um eine verständliche
Ausdrucksweise, da mehrere Personen das Produkt
begutachten
+ Unterschiedliche Produkte desselben Autors werden von
Prüfung zu Prüfung besser, d.h. enthalten weniger Fehler
- In der Regel aufwändig (bis zu 20 Prozent der
Erstellungskosten des zu prüfenden Produkts)
- Autoren geraten u.U. in eine psychologisch schwierige
Situation (»sitzen auf der Anklagebank«, »müssen sich
verteidigen«)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
474
12. Umfeld der SoftwareEntwicklung
12.1 Versionsmanagement
12.2 Build-Management
12.3 Grundlagen der Projektplanung und verfolgung
12.4 Aufwandsschätzung
12.5 Qualitätsmanagement
12.6 Der Mensch im Projekt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
475
Typischer Weg der Software-Entwicklung
12.1
Aufgabenteil
auswählen
Programmstück
kodieren
Programmstück
testen
[läuft]
[nicht fertig]
[kleiner
Fehler]
Korrekturversuch
[Fehler
unklar]
Einbau/Nutzung von
Debuginformationen
[kleine
Überarbeitung]
kleine
Lösungsvariante
[Umstrukturierung]
große
Lösungsvariante
[fertig]
Grundkurs Software-Engineering mit UML
Stephan Kleuker
476
Software-Versionen
• Software entwickelt sich inkrementell, bei Versuchen muss der
Weg zurück möglich sein
• Versionsbaum
Paket 1
Paket 2
Paket 3
V1
V1
V1
V2
V2
V2
V3
V4
V3
V4
V5
V6
V3
Inkrement 1
V4
V5
V6
Inkrement 2
V7
V5
Grundkurs Software-Engineering mit UML
Stephan Kleuker
477
Verwaltung von Software
• Die gemeinsame Entwicklung von Software hat u. a.
folgende Aufgaben zu lösen:
– wie kann ein Entwickler seine eigene
Softwareentwicklung koordinieren
– wie bekommen andere Entwickler mit, was der
aktuelle Entwicklungsstand ist
– wie wird aus den einzelnen Dateien effizient das
lauffähige System kompiliert
• Die ersten beiden Fragen beantwortet ein
Versionskontrollsystem
• die letzte Frage fordert die Erweiterung zum
Softwarekonfigurationsmanagementsystem (-> Ant)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
478
Konflikt bei gemeinsamer Bearbeitung
Arton
Datei D
auschecken
Nadia
Datei D
Version n
Datei D
auschecken
D bearbeiten
D bearbeiten
Datei D
Version n+1
Datei D
einchecken
Datei D
einchecken
Grundkurs Software-Engineering mit UML
Stephan Kleuker
479
Versionskontrolle: konservative Variante
•
•
•
•
Dateien werden zentral im Repository verwaltet
Entwickler checkt zu ändernde Software aus
Entwickler erhält damit lokale Kopie zur Bearbeitung
Während der Entwickler an der Software arbeitet, kann niemand
anderes diese Software bearbeiten (erhält die Situation
klärenden Hinweis)
• Entwickler checkt lokale Kopie (mit Änderungsverweis) wieder
ein; jeder kann diese Kopie zur erneuten Bearbeitung
auschecken
• Vorteil: garantiert nur ein Bearbeiter
• Nachteile: keine gleichzeitige Arbeit an unterschiedlichen
Programmstellen, wartende Entwickler, vergessenes
Einchecken
• Realisierung von Repository sehr unterschiedlich lösbar
(Datenbanksystem, Aufsatz auf Filesystem)
• Hinweis: Generell sollte das Einchecken mit einer Prüfung
verbunden sein
Grundkurs Software-Engineering mit UML
Stephan Kleuker
480
Versionskontrolle: progressive/chaotische Variante
•
•
•
•
Dateien werden zentral im Repository verwaltet
Entwickler checkt zu ändernde Software aus
Entwickler erhält damit lokale Kopie zur Bearbeitung
andere Entwickler können gleichen Programmcode
auschecken
• erst beim Einchecken wird geprüft, ob seit dem Auschecken
zwischenzeitliche neue Version eingecheckt wurde, wenn ja,
passiert Versionsabgleich, Konflikt muss gelöst werden
• Vorteil: massive parallele Arbeit wird möglich, kein
Ausbremsen anderer Entwickler
• Nachteil: Chaos bei häufig veränderten Ressourcen
• Lösung: für selten genutzte Dateien progressiver, für sehr
kritische oder häufig genutzte Dateien konservativer Ansatz
Grundkurs Software-Engineering mit UML
Stephan Kleuker
481
Herstellung der Entwicklungsumgebung
12.2
• In großen Projekten arbeiten Entwickler häufig nicht auf einer
Quelldatei; Dateien werden lokal kopiert und dort bearbeitet
– Vorteil: ordentliche Verfolgung von Änderungen, laufende
Programmversionen können nicht verloren gehen
– Nachteil: Entwickler muss Kopien für seinen Arbeitsbereich
erstellen
• Lösung: Automatisierung des Kopier- und
Übersetzungsprozesses (+ weiterer Standardaufgaben)
– Einsatz von Skripten sh, *.bat
– besser: Einsatz von Werkzeugen, wie make und ant (auch
Build-Tools genannt)
• In Großprojekten muss der Entwickler die dahinter liegenden
automatisierten Prozesse nicht kennen, er muss nur wissen,
wo „seine“ mit welchen Randbedingungen läuft
• Software durchläuft bei der Installation häufig eine Installationsroutine, bei der u. a. Pfade gelesen und bearbeitet werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
482
Ant
• Apache Ant (another neat tool, James Duncan
Davidson) ist Alternative zu make-Files
• Ant-Files können betriebssystemunabhängig
formuliert werden
• alle Befehle im XML-Format
• viele Werkzeuge bieten XML-Tasks an, mit denen
verschiedene Befehle des Werkzeugs aus Ant
heraus ausgeführt werden können (z. B.
Kompilieren)
• Ant kann leicht erweitert werden, da in Java
geschrieben, als Framework konzipiert
• Ant benötigt XML-Parser, Apache Xerces mitgeliefert
• erste Schritte auf Veranstaltungswebseite
Grundkurs Software-Engineering mit UML
Stephan Kleuker
483
Konzept von Ant (und make)
• Es gibt zentrales Ziel (project) , was erreicht werden
soll (z. B. vollständige Kompilation)
• Jedes Ziel besteht aus Teilzielen (target), die vorher
erreicht werden müssen (z. B. Übersetzung eines
Teilpakets)
• Werkzeug stellt Regeln auf, was in welcher
Reihenfolge gemacht werden muss, um zentrales
Ziel zu erreichen
• Werkzeug bietet dabei u. a.
– Reaktionsmöglichkeiten bei Fehlern
– Varianten bei der Ausführung
– Möglichkeit, Ordner zu löschen und anzulegen,
Dateien zu kopieren, verschieben und löschen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
484
Erinnerung an make
all : file1.o file2.o file3.o
gcc -o prog file1.o file2.o file3.o
file1.o : file1.c
gcc -Wall -c file1.c
file2.o : file2.c
gcc -Wall -c file2.c
file3.o : file3.c
gcc -Wall -c file3.c
Grundkurs Software-Engineering mit UML
Stephan Kleuker
485
Beispiel für Abhängigkeiten
<target
<target
<target
<target
name="init"/>
name="preprocess" depends="init"/>
name="compile" depends="init,preprocess"/>
name="package" depends="compile"/>
• Die Reihenfolge der Ziele (target) in der Datei hat keine
Bedeutung, nur „depends“ dabei wichtig
• Neben einem default-Ziel kann man beim Start ein Ziel
auswählen, z. B. compile
• alle depends betrachtet und schrittweise vom Werkzeug in
mögliche Reihenfolge gebracht, hier:
– init hat keine Abhängigkeiten, wird zuerst ausgeführt (was,
hier nicht sichtbar)
– preprocess benötigt init, da schon ausgeführt, wird nur
preprocess ausgeführt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
486
Ant-Basisskript (erzeugt von Eclipse)
<?xml version="1.0"?>
<!-- =============================================
Projekt, Datum, Aufgabe Autor,
============================================= -->
<project name="project" default="default">
<description>
description
</description>
<!-- =================================
target: default
================================= -->
<target name="default" depends="depends"
description="--> description">
</target>
<!-- - - - - - - - - - - - - - - - - target: depends
- - - - - - - - - - - - - - - - - -->
<target name="depends">
</target>
</project>
Grundkurs Software-Engineering mit UML
Stephan Kleuker
487
Skript-Konstanten (Eigenschaften, Properties)
• <property name="eigen" value = "Wert" />
• Nutzung von Property-Werten mit ${eigen}
<property name= "db" value = "${eigen}.db"/>
• Bei Pfaden wird statt „value“ dann „location“ genutzt, dabei
werden / und \ automatisch angepasst
<property name="ziel" location="${p}/bla/fas"/>
<property name="ziel" location="${p}\bla\fas"/>
• Laufwerksbuchstaben, wie „C:“ sind verboten (möglichst mit
relativen Pfaden arbeiten)
• Es gibt vordefinierte Properties, z. B. ${user.home}
Grundkurs Software-Engineering mit UML
Stephan Kleuker
488
Beispiel-Task: Kompilieren
<!-- classpath in der Form besser weglassen! -->
<target name="compile"
depends="start"
description="kompiliere">
<javac srcdir="src"
destdir="build"
classpath="."
debug="on">
</javac>
<echo message="in compile"/>
</target>
• weitere Parameter können der Ant-Dokumentation entnommen
werden (...\ant\docs\manual\index.html)
• classpath nur nutzen, wenn weitere Pakete genutzt werden
• echo hier als Spielerei
• Übersetzung aller Klassen in Verzeichnis src und
Unterverzeichnissen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
489
Beispiel-Task: Packen
<!-- existierendes Manifest mit Attribut file="" -->
<target name="pack"
depends="compile"
description="packe">
<jar destfile="dist/gepackt.jar"
basedir="build">
<manifest>
<attribute name="Main-class"
value="de.kleuker.XStarter">
</attribute>
</manifest>
</jar>
<echo message="in pack"/>
</target>
• hier wird Manifest-Datei direkt erzeugt, zu nutzende Datei kann
auch angegeben werden
Grundkurs Software-Engineering mit UML
Stephan Kleuker
490
Hilfsmittel: Zeitstempel
• Einfachste Form: Task <tstamp/> , dann nutzbare Variablen:
– DSTAMP: aktuelles Datum, Default-Format yyyymmdd
– TSTAMP: aktuelle Uhrzeit, Default-Format hhmm
– TODAY: aktuelles Datum als String
• konfigurierbar über format-Property
<target name="zeigeZeit">
<tstamp>
<format property="TODAY"
pattern="dd.MMMM.yyyy" locale="de,DE"/>
</tstamp>
<echo message="DSTAMP = ${DSTAMP}"/>
<echo message="TSTAMP = ${TSTAMP}"/>
<echo message="TODAY = ${TODAY}"/>
</target>
[echo] DSTAMP = 20080209
[echo] TSTAMP = 1234
[echo] TODAY = 09.Februar.2008
Grundkurs Software-Engineering mit UML
Stephan Kleuker
491
Umgang mit Files und Dateien
• <mkdir dir="${builddir}"/>
– legt auch fehlende Unterverzeichnisse z. B. bei
/dist/nase/simpel/billig an
– übersprungen, falls Verzeichnis existiert
• <delete dir="${builddir}"/>
• <copy file="src/Hai.java" tofile="back/Hai.java"/>
• <move file="src/Hai.java" tofile="back/Hai.java"/>
• Pattern / Wildcards / reguläre Ausdrücke
– * für beliebig viele Zeichen
– ? für genau ein Zeichen
– ** alle Unterverzeichnisse, z. B. **/*.java
• häufig Property fileset zum Ein- und Ausschließen nutzbar
<copy todir="archive">
<fileset dir="src">
<include name="*.java"/>
</fileset>
</copy>
Grundkurs Software-Engineering mit UML
Stephan Kleuker
492
Aufgaben des Konfigurationsmanagements (1/3)
BuildManagement
ReleaseManagement
Versionsmanagement
Änderungsmanagement
Grundkurs Software-Engineering mit UML
ProzessUnterstützung
Stephan Kleuker
493
Aufgaben des Konfigurationsmanagements (2/3)
• Versionsmanagement
– soll Produkte zu einem definierten Zeitpunkt eindeutig
identifizieren und kennzeichnen
– erstellt damit Gültigkeitsreihenfolge
• Build-Management
– den Build-Prozess vollständig beschreiben
– automatische Abläufe unterstützen
– Reproduzierbarkeit von Softwareintegrationen sicher
stellen
• Release-Management
– Verwaltung von ausgelieferter Software
– Releaseplanung
– Distribution (Erstauslieferung, Ersatz gelieferter SoftwareVersionen)
– Rückruf gelieferter Software
Grundkurs Software-Engineering mit UML
Stephan Kleuker
494
Aufgaben des Konfigurationsmanagements (3/3)
• Änderungsmanagement
– stellt die kontrollierte Änderung von akzeptierten Produkten
sicher
– dazu werden Daten festgehalten über:
• Fehler- und Problemmeldungen
• Änderungsaufträge
• Bearbeitungsstand der Änderungsaufträge
• erforderliche und geleistete Aufwände
• geänderte Produkte
• Prozessunterstützung
– da im KM alle Projekt-Produkte verwaltet werden, muss das
werkzeuggestützte KM die zugehörigen Prozesse
unterstützen
– Erstellung und Änderung von Produkten
– Berücksichtigung von Abhängigkeiten
Grundkurs Software-Engineering mit UML
Stephan Kleuker
495
Voraussetzungen für einen Projektbeginn
12.3
• klare Aufgabenbeschreibung
• Festlegung des Projektleiters
• Klärung, welche technischen und organisatorischen
Randbedingungen berücksichtigt werden müssen
• in studentischen Projekten liegt meist keine
Aufwandsschätzung vor, diese muss durch
Annahmen ersetzt werden
• Übung: Diskutieren Sie typische Vorgaben für
Projekte in Unternehmen, die gemacht werden, aber
nicht unbedingt hilfreich sind
Grundkurs Software-Engineering mit UML
Stephan Kleuker
496
Auswahl des Vorgehensmodells
• Vorgehensweise beeinflusst Planung maßgeblich
– Wasserfall
– prototypische Entwicklung
– iterativ inkrementelles Modell
– agiles Vorgehensmodell
• Planungsaufwand (am Anfang und im Laufe des
Projekts) nimmt von oben nach unten zu
• Vorgehensweise muss zur Aufgabengröße und
Projektmitarbeitern passen
• im folgenden: kurzer inkrementeller Ansatz (leicht
für komplexere Ansätze erweiterbar)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
497
Festlegung der Arbeitspakete
• Zerlegung in sogenannter Work-BreakdownStructure (auch Projektstrukturplan)
• hierarchische Untergliederung
• Ziele: klare Aufgabenpakete, Vermeidung
überflüssiger Schnittstellen
• Berücksichtigung von Querschnittsaufgaben wie
Projektleitung, Qualitätssicherung
• für Aufgabenpakete werden Aufwände kalkuliert (wie
siehe später)
• Später kann WBS weiter verfeinert werden
(Detailaufgaben, Verantwortliche, Beteiligte)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
498
Beispiel für WBS
• PT = Personentage
• Es muss deutlich sein, wo
welches Produkt zugehört
(hier z. B. Dokumentation
querschnittlich bei allen)
Projekt
Perpetuum
130 PT
10 PT
Projektleitung
80 PT
Qualitätssicherung
Prototypentwicklung
35 PT
Projektinfrastruktur
Use Case
Energieverbrauch
15 PT
Grundkurs Software-Engineering mit UML
10 PT
5 PT
Entwicklung
Use Case
Energieerzeugung
35 PT
Stephan Kleuker
Netzwerkanbindung
20 PT
499
Abhängigkeiten von Arbeitspaketen
Es gibt Beziehungen zwischen
Arbeitspaketen:
• typisch: Paket 2 benötigt Ergebnisse
von Paket 1, also muss Paket 1 vorher
fertig werden (Ende-Anfang-Beziehung)
• Anfang-Anfang-Beziehung: Arbeiten
sollen bzw. müssen parallel starten (z.
B. Nutzung gemeinsamer Ressourcen,
wie Testumgebungen)
• Ende-Ende-Beziehung: Arbeiten sollen
möglichst gleichzeitig abgeschlossen
werden (z. B. damit Ergebnisse
integriert werden können)
• (Anfang-Ende-Beziehung, vor dem
Anfang einer Arbeit muss andere Arbeit
abgeschlossen sein, bei
Rückwärtsplanung)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
500
Netzplan und kritische Pfade
• Abhängigkeiten und Aufwände können als Graph dargestellt
werden
P2
Paket
4 6
min.
max.
P1
P5
Dauer Dauer
3 7
5 7
P3
P4
2 5
3 4
• Grundregel 1: Jedes Arbeitspaket enthält einen gewissen
Risikoaufschlag
• Jeder zeitlich mögliche Durchlauf durch den Graphen stellt
möglichen Projektplan dar
• Beispiel P1 P2 P3 P4 P5, minimale Dauer 17, maximale Dauer 29
• Optimierungen berechnen, hier z. B. zuerst P1, dann parallel P2
und P3 starten, nach P3 dann P4, nach P4 und P2 dann P5,
minimale Dauer 13, maximale Dauer 23
• zwischen P2 und P5 maximale Pause von 5
• Man erkennt kritische Pfade (legen Projektdauer fest)
• Grundregel 2: Jedes Arbeitspaket auf dem kritischen Pfad
erhält einen zusätzlichen Risikoaufschlag
Grundkurs Software-Engineering mit UML
Stephan Kleuker
501
Einflüsse der Projektplanung
Abhängigkeiten von
Arbeitspaketen
Risikominimierung
durch Zeitpuffer
Projektplan
Verfügbarkeit
von Mitarbeitern
Grundkurs Software-Engineering mit UML
individuelle
Randbedingungen
(z. B. Kundenwünsche,
Ausbildungen, Messen)
Stephan Kleuker
502
Erster Projektplan (1/2)
Mai 2008
Juni 2008
Juli 2008
Projekt Perpetuum
Machmann[30%]
[30 %]
> Projektleitung
Penibel[30%]
[30 %]
> Qualitätssicherung
Versionmann[20%]
[30 %]
> Infrastruktur
> Entwicklung
> Prototyp
> Analyse
> Design
Schmidt[60%]
[100 %]
Schmidt[80%]
[100 %]
> Codierung
Meier[80%]
[100 %]
> Abnahme
Netzbert[50%]
Grundkurs
Software-Engineering mit UML
> Netzwerkanbindung
Stephan Kleuker
[70 %]
503
> Codierung
Meier[80%]
[100 %]
Erster
Projektplan (2/2)
> Abnahme
Netzbert[50%]
> Netzwerkanbindung
[70 %]
> UC Energieverbrauch
> Analyse
> Design
> Codierung
Meier[20%], Schmidt[60%]
[30 %]
Meier[80%]
[0 %]
Meier[100%]
[0 %]
> Abnahme
> UC Energieerzeugung
Schmidt[80%]
> Analyse
> Design
> Codierung
[30 %]
Schmidt[80%]
[0 %]
Schmidt[80%]
[0 %]
Meier[40%] Schmidt[80%]
[0 %]
> Integration
> Endabnahme
Grundkurs Software-Engineering mit UML
Stephan Kleuker
504
Sachstandsanalyse
Ressourcenverbauch
(Abweichung)
zu langsam
Verbrauch ok
-50%
(zu) schnell
(zu) effizient
zu langsam
Verbrauch
nicht ok
Fertigstellungsgrad
(Abweichung)
0
-50%
Desaster!
+50%
(zu) schnell
Verbrauch ok
50%
(zu) schnell
Verbrauch
nicht ok
Grundkurs Software-Engineering mit UML
Stephan Kleuker
505
Meilensteintrendanalyse zur erwarteten Fertigstellung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
506
Burndown-Chart zur erwarteten Fertigstellung (Scrum)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
507
Aufwand oder Kosten ?
12.4
• Aufwand (costing):
–was getan werden muss,
Personenmonate für technische Ausführung,
Verwaltung, Management, Material
• Kosten (prizing):
–wie viel wird vom Kunden verlangt?
–Gewinnmaximierung vs. Ölfleck
Kosten können sich aus politischen Gründen
ändern,
der Aufwand für die gleiche Aufgabe nicht
Grundkurs Software-Engineering mit UML
Stephan Kleuker
508
Warum schätzt man?
• Aufwandsbestimmung am Anfang des Projekts
• Schätzung des verbleibenden Aufwands im laufenden
Projekt
• Gegenseitige Aufwandsschätzung bei
Geschäftspartnern
• Offenlegung der Aufwandsansetzung gegenüber dem
Kunden (Preisfindung)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
509
Zusammenfassung der Function Point Analyse
funktionale Anforderungen
Einflussfaktoren
Schätzung
Schätzung
ungewichtete Function-Points
Projekteinflüsse
Berechnung
gewichtete Function-Points
Ableitung
Aufwand Personenmonate
Grundkurs Software-Engineering mit UML
Stephan Kleuker
510
Function-Point-Methode (1/4) [Bal98]
Jede Anforderung (bzw. ermittelte Funktionalität) in eine der fünf
Kategorien einordnen
• Internal Logical Files (ILF, Datenbestand): Datenbestände, die
innerhalb des zu entwickelnden Systems bearbeitet werden, z.
B. die selbstentwickelten Klassen
• External Interface Files (EIF, Referenzdaten): Datenbestände
die von außerhalb des zu entwickelnden Systems kommen und
bearbeitet werden
• External Inputs (EI, Eingabe): Eingaben von außerhalb in das
zu entwickelnde System mit denen der Datenbestand
verändert wird, z. B. über Eingabemasken, Dateien in
bestimmten Eingabeformaten, Eingaben von externen
Systemen
• External Outputs (EO, Ausgabe): Ausgaben an außerhalb des
zu entwickelnden System liegende Komponente, z. B.
Ausgabemasken, Dateien in bestimmten Ausgabeformaten;
Ausgaben weden aus vorhandenen Daten berechnet
• External Inqueries (EQ, Abfrage): Abfragen von Informationen
des Datenbestands von außerhalb des Systems, z. B.
Abfragemasken, reines Anzeigen der verwalteten Daten
Grundkurs Software-Engineering mit UML
Stephan Kleuker
511
Function-Point-Methode (2/4)
Kategorie
Eingabedaten
Abfragen
Ausgaben
Datenbestände
Referenzdaten
Anzahl
Klassifizierung
Gewichtung
Zeilensumme
6
einfach
*3
18
4
mittel
*4
16
komplex
*6
einfach
*3
mittel
*4
komplex
*6
6
einfach
*4
24
9
mittel
*5
45
komplex
*7
einfach
*7
mittel
* 10
komplex
* 15
einfach
*5
mittel
*7
komplex
* 10
4
7
Summe ungewichteten Function-Points
Grundkurs Software-Engineering mit UML
12
49
164
Stephan Kleuker
512
Function-Point-Methode (3/4)
Summe unbewertete Function-Points
164
Verflechtung mit anderen
Anwendungssystemen (0-5)
1
Dezentrale Daten,
dezentrale Verarbeitung (0-5)
2
Transaktionsrate (0-5)
2
Verarbeitungslogik
Rechenoperationen (0-10)
1
Kontrollverfahren (0-5)
3
Ausnahmeregelungen (0-10)
0
Logik (0-5)
2
Wiederverwendbarkeit (0-5)
3
Datenbestandskonvertierungen (0-5)
2
Anpassbarkeit (0-5)
1
Summe der Einflussfaktoren (EF)
Faktor Einflussbewertung (FE) =
17
EF / 100 + 0,7
0,87
Gewichtete Function-Points = ungewichtete Functionpoints *FE
143
Grundkurs Software-Engineering mit UML
Stephan Kleuker
513
Function-Point-Methode (4/4)
1000
Personenmonate
X
X
X
X
X
X
o
X
o
o
X
X
0
X
X
Unternehmen 1
Unternehmen 2
o
X
0
Grundkurs Software-Engineering mit UML
Function Points
Stephan Kleuker
5000
514
Fazit zur Function-Point Analyse
• Wissenschaftlich fundiert
• Schätzdetails nur von speziellen Schätzexperten beurteilbar
• firmenspezifische und methodenspezifische Optimierung
schwierig
• Wenn FPA eingesetzt werden soll, muss sie (evtl. rückwirkend)
für verschiedene Projekte evaluiert werden
• sinnvoll, wenn eigene Schätzabteilung zur Betreuung aller
Schätzungen aufgebaut wird
• wesentlich höherer Aufwand als später vorgestellte vereinfachte
Analogieschätzung, Schätzer fühlen sich nicht für
Schätzergebnis verantwortlich
Grundkurs Software-Engineering mit UML
Stephan Kleuker
515
Von CoCoMo81 zu CoCoMo II
Kostenschätzverfahren von Barry W. Boehm (ab 1981)
• Die Art der SW-Entwicklung hat sich in den Jahren wesentlich
verändert (Methodik)
• Die Programmiersprachen haben sich verändert (Aufkommen
von OO-Sprachen)
• Man kann weitere Einflussfaktoren auf den Aufwand feststellen
• Es ist interessant, eine Schätzung zu verschiedenen
Zeitpunkten des Projektfortschritts durchzuführen
• Mittlerweile viele Varianten für verschiedene Vorgehensmodelle
und Projektarten
-> führt zur Verbesserung von CoCoMo 81
Literatur: B. W. Boehm, C. Abts, A. W. Brown, Software Cost
Estimation with Cocomo II, Prentice Hall PTR, 2000
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html
Grundkurs Software-Engineering mit UML
Stephan Kleuker
516
CoCoMo II – zentrale Formel
• Personenmonat wird mit 152h gerechnet
• EM sind die einzelnen Kostentreiber
• für Early Design : n=7
• für Post Architecture: n=17
• A ist Produktionskonstante, kann für verschiedene IT-Sektoren
unterschiedlich sein (Default 2.45 in 1999)
• Size bezieht sich wieder auf KDSI (Kilo Lines of Documented
Source Instrctions)
• Hinweis: Alle Default-Werte von CoCoMo basieren auf einer
größeren Anzahl (>60) von Projekten
Grundkurs Software-Engineering mit UML
Stephan Kleuker
517
Variable E
• B hat Standardwert 0.91 (1999)
• Dazu kommen fünf Scaling Factors:
Sehr
gering
Geschäftstätigkeit im
PREC
Produktbereich
Entwicklungsfreiräume
FLEX
Ausgereiftheit des
RESL
Produktentwurfs
Einvernehmen zwischen
TEAM
Stakeholdern
Software-Prozessreife (nach
SEI-CMM[I])
PMAT
Grundkurs Software-Engineering mit UML
Gering
Normal
Hoch
Sehr
hoch
Extra
hoch
6.20
4.96
3.72
2.48
1.24
0
5.07
4.05
3.04
2.03
1.01
0
7.07
5.65
4.24
2.83
1.41
0
5.48
4.38
3.29
2.19
1.10
0
7.80
6.24
4.68
3.12
1.56
0
Stephan Kleuker
518
Kostentreiber EM (Early Design)
Einflussfaktor
Extra Sehr Gegering gering ring
Produktzuverlässigkeit
0.73
und -Komplexität
0.81
Normal
Hoch
Sehr Extra
hoch hoch
0.98 1
1.30 1.74 2.38
Angestrebte
Wiederverwendbarkeit
0.95 1
1.07 1.15 1.24
Zielplattformbesonder
heiten
0.87 1
1.29 1.81 2.61
Personalfähigkeit
2.12
1.62
1.26 1
0.83 0.63 0.50
Personalerfahrung
1.59
1.33
1.12 1
0.87 0.71 0.62
Qualität der Entwicklungsbedingungen
1.43
1.30
1.10 1
0.87 0.73 0.62
1.43
1.14 1
1
Entwicklungszeitrahmen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
1
519
CoCoMo im Überblick
Abschätzung der
Systemgröße (KDSI)
Produkt-, Prozess-, Plattformund Personal-Attribute
Wiederverwertbarkeits- und
Wartbarkeitsparameter
CoCoMo II
Abschätzung für
Entwicklungsund Wartungskosten
für verschiedene
Entwicklungsphasen
Daten bereits
abgeschlossener Projekte
Iterative
Aktualisierung
Kalibrierung auf eigene
Organisation
Grundkurs Software-Engineering mit UML
Stephan Kleuker
520
Vereinfachter Analogieschluss
Forderungen an das Schätzverfahren
• Erfahrungen aus anderen Projekten müssen
einfließen können
• Verfahren muss für alle Schätzbeteiligten
verständlich sein
• Einzelne Schätzfaktoren müssen verständlich sein
• Schätzfaktoren müssen an Projekteigenheiten
anpassbar sein
• Schätzergebnisse müssen an neue Projektsituationen
anpassbar sein
• Schätzergebnis muss dokumentierbar
(nachvollziehbar) sein
• Einbettung in weitere Geschäftsprozesse
Grundkurs Software-Engineering mit UML
Stephan Kleuker
521
Vorbereitung der Schätzung
Grundkurs Software-Engineering mit UML
Optionseinstellungen
Graphikeinbindung
Ansichtenerstellung
2. vergleichbares
Projekt liegt mit
Aufwandsdaten und
vergleichbarer
Komponentenstruktur
vor
Nutzer-Interface
Textbearbeitung
1. Projekt in
dokumentierte
Komponenten /SWEinheiten / Use Cases
zerlegt
Basisdienste
Stephan Kleuker
522
Umgang mit „Projektumfeldkosten“
• HW wird getrennt betrachtet
• Projektmanagement (PM), Qualitätsmanagement und
Konfigurationsmanagement wird analog zum
Vergleichsprojekt (Normierungsprojekt) behandelt
Wünschenswert: genannte Managementkosten in
Komponenten des Normierungsprojekts eingerechnet
Wenn nicht möglich: Aufwände aus bekannten
Aufwänden des Normierungsprojekts extrapolieren
Beispiel: Entwicklungsaufwand 100 PT
(Personentage), für PM 15 PT, dann später 15% für
PM auf berechneten Wert aufschlagen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
523
Aufbau des Schätzansatzes
Vorbereitung der Schätzung
Durchführung der Schätzung
Analogieschluss
Grundkurs Software-Engineering mit UML
Stephan Kleuker
524
Analogie-Schätzung (1/3): Vorbereitung
1. Festlegung der Schätzparameter
A: Wiederverwendung [1-3] (vollständig bis neu)
B: Funktionsumfang [1-8] (einfach bis hoch komplex)
C: Abhängigkeiten
[1-3] (gering bis stark)
D: Kritikalität
[1-2] (niedrig, mittel, hoch)
K-Faktor= A*B*C*D
2. gemeinsame Skalierung der Parameter durch Schätzer
(„B=4 heisst ...“)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
525
Schätzparameter- zwischen Erfahrung und Voodoo
Generell gilt: gezeigte Schätzparameter sind
Vorgabe, die sich häufig als sinnvoll herausgestellt
hat
Aber: Anpassungen der Wertebereiche und der
Anzahl der Schätzparameter erlaubt
Ansatz: mit Standardparametern anfangen, bei
unrealistischem Ergebnis modifizieren,
Änderungen dokumentieren
Grundkurs Software-Engineering mit UML
Stephan Kleuker
526
A: Wiederverwendung
1
1,3
1,6
1,9
3
Komponente besteht rein aus der Wiederverwendung
bereits existierender Ergebnisse, die nur neu
zusammengesetzt werden müssen
Hoher Grad der Wiederverwendung, es müssen nur
Anpassungen an relativ leicht zu identifizierenden Stellen
vorgenommen werden
Hoher Grad der Wiederverwendung, neben kleinen
Anpassungen müssen einige eigenständige Erweiterungen
vorgenommen werden, aus der vorliegenden
Dokumentation wird deutlich, wo Neuentwicklungen
eingebunden werden sollen
Einige Teile können wiederverwendet werden,
grundlegende Designideen sind übernehmbar
Neuentwicklung, bzw. alle existierenden Ergebnisse
müssen intensiv überprüft werden
Hinweis: Wiederverwendung kann sich auf selbst erstellte Software,
Freeware oder gekaufte SW beziehen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
527
B: Funktionalität
1-8
es muss festgehalten werden, wie groß der maximale
Unterschied in der Größe der Komponenten sein
kann, für einen oder mehrere Werte sollen konkrete
Beispielfunktionalitäten (Teilkomponenten) genannt
werden, es werden nur neue und zu modifizierende
Funktionalitäten betrachtet
1- sehr einfach
8 - hochkomplex
Hinweis: Funktionalität bezieht sich nur auf die
Komplexität der neu zu erstellenden SW (also B=0,
wenn nichts gemacht werden muss)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
528
C: Schnittstellen
1
keine oder geringe Abhängigkeiten von anderen
Komponenten
2
Kommunikationsaufwand mit verschiedenen
Komponenten
3
hoher Kommunikationsaufwand mit anderen
Komponenten, starke Abhängigkeit von anderen
Komponenten
Hinweis: Der C-Wert steigt, wenn es um Schnittstellen
über Firmengrenzen hinweg oder um Schnittstellen
noch zu entwickelnder Systeme geht
Grundkurs Software-Engineering mit UML
Stephan Kleuker
529
D: Kritikalität
1
niedrige Kritikalität
Projekt scheitert nicht, wenn Komponente
kleinere/ mittlere Fehler enthält
1,5
mittlere Kritikalität
Funktionalität und Kundenzufriedenheit wird bei
Fehlern eingeschränkt, System bleibt nutzbar
2
hohe Kritikalität
Projekt scheitert, wenn nur kleinere oder mittlere
Fehler in dieser Komponente sind
Hinweis: Kritikalität ist hier zunächst nach V-Modell
gegeben, Übersetzung für andere Modelle:
Projektrisiko, wenn Komponente nicht vollständig
oder „wie gewünscht“ funktioniert (-> Testaufwand)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
530
Skalierung der Schätzparameter
Alle Schätzer setzen sich an einen Tisch,
wählen eine Beispielkomponente, die jeder gut
verstanden hat
und legen beispielhaft Werte für A,B,C,D fest.
Achtung! Der resultierende Wert A*B*C*D hat zunächst
keine Bedeutung.
Technisches Ziel: Vermeidung, dass später zu häufig
B=1 auftritt
Gesamtziel: „Gleichschaltung“der Köpfe bzgl.
Parameterwerte
Grundkurs Software-Engineering mit UML
Stephan Kleuker
531
Analogie-Schätzung: Durchführung
1. Gemeinsame Schätzung einer
neuen Beispielteilaufgabe (evtl.
mehrere)
Teilaufgabe A
Neu1
B C D ABCD
1.9 5 2 2
38
2. Individuelle Schätzung mit
Konsolidierung durch
Schätzkonferenz
Teilaufgabe A
B C D
ABCD
Neu1
1.9 5 2 2
Neu2
3
4 2 1.5 32
Neu3
3
6 1 1.5 27
Neu4
3
2 3 2
36
Neu5
1.6 5 2 1
16
Grundkurs Software-Engineering mit UML
38
3. Individuelle Schätzung des
Altprojekts (Aufwand in Personentagen, PT, bekannt), mit Konsolidierung durch Schätzkonferenz
Teilaufgabe PT A
B C
D ABCD
Alt1
188 3
5 2
2
60
Alt2
62 1.9 5 2
1
19
Alt3
149 3
6 1.5 2
54
Alt4
54 3
2 3
18
Summe 453
1
151
4. Berechnung des Wertes eines
Aufwandspunktes 453/151 = 3
Stephan Kleuker
532
Analogie-Schätzung: Analogieschluss
5. Bestimmung des Aufwandes in PT des neuen
Projekts mit Analogieschluss
Teilaufgabe A
B
Neu1
1.9 5
Neu2
3
4
C
2
2
D
ABCD
2
38
1.5 32
Aufwand
114
96
Neu3
Neu4
Neu5
1
3
2
1.5 27
2
36
1
16
81
108
48
3
6
3
2
1.6 5
Grundkurs Software-Engineering mit UML
Stephan Kleuker
533
Kommentare zum Schätzverfahren
• Schätzendergebnis wird von allen Schätzern begutachtet, wenn
nicht plausibel, dann Parameter modifizieren
Beispiel: C=1,2,3 zu weit, Ansatz C=2, 2.5, 3
• Die Qualität steigt, wenn jeder Schätzer jede Komponente
schätzen kann, dies ist in der Realität meist nicht möglich
• Zur Normierung der Schätzer im Schritt 2 ist auch Komponente
des Vergleichsobjekts wählbar
• Vergleichsprojekt können Teilkomponenten aus einem
größeren System sein
• Der Begriff der mathematischen Unabhängigkeit (insbesondere
zwischen Funktionalität und Schnittstellen, sowie
Funktionalität und Kritikalität) muss den Schätzern klar sein
• Ergänzung um Vergleich der Projektrisiken der beiden Projekte
sinnvoll (Skalierungsfaktor), nächste Folie; falls große
Abweichung von Null Skalierungsprojekt evtl. nicht geeignet
Grundkurs Software-Engineering mit UML
Stephan Kleuker
534
Logische und psychologische Zahlen
• Diskussionspunkte sind häufig die Wertebereiche der einzelnen
Schätzfaktoren, dabei ist das Verständnis wichtig, dass von
C=1 zu C=1.5 der Aufwand um 50% steigt
• Der Wertebereich bei der Funktionalität wurde aus
„psychologischen Gründen“ sehr hoch angesetzt, da hier meist
der größte Klärungsbedarf im Verständnis besteht
• Man beachte: wird ein Wertebereich z.B. bei C von [1…3] auf
[1…9] erweitert und wird dann statt C=2 mit C=6 gerechnet,
ändert sich am Schätzwert nichts
AufwandN = AN*BN*CN*DN*(AufwandA/ (AA*BA*CA*DA))
= AN*BN*CN*3*DN*(AufwandA/ (AA*BA*CA*3*DA))
N = neu, A= alt
Grundkurs Software-Engineering mit UML
Stephan Kleuker
535
Variante Planning Poker
1
2
3
5
8
13
21
34
55
89
?
∞
• statt Schätzung von ABCD wird nur mit einer jeweils
verdeckt aufgelegten Karte geschätzt
• ? = keine Ahnung, ∞ = gibt zu wenig Informationen
• höchster und niedrigster Wert werden diskutiert
• solange wiederholen, bis konsolidiert
• wieder Analogieschluss mit vorherigen Projekten
oder bei Sprints mit vorherigen Sprints
Grundkurs Software-Engineering mit UML
Stephan Kleuker
536
Teufelsquadrat für IT-Projekte nach Sneed
12.5
Qualität
Funktionalität
Kosten
Zeit
• Konzentration auf ein Ziel erzwingt bei gleichen
Rahmenbedingungen Vernachlässigung mindestens eines
anderen Ziels (Verbesserung im Bild bedeutet ziehen des
Schwerpunkts in diese Richtung)
• generelle Verbesserung nur durch Verbesserung der
Rahmenbedingungen (z.B. der Prozesse)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
537
Definition Qualitätsmanagement (eine Variante)
Definition:
Umfasst »alle Tätigkeiten der Gesamtführungsaufgabe, welche
die Qualitätspolitik, Ziele und Verantwortungen festlegen sowie
diese durch Mittel wie Qualitätsplanung, Qualitätslenkung,
Qualitätssicherung und Qualitätsverbesserung im Rahmen des
Qualitätsmanagementsystems verwirklichen« (DlN EN ISO
8402).
Unterscheidung in:
• Produktorientiertes Qualitätsmanagement
(Produkt und Zwischenergebnisse auf festgelegte
Gütemerkmale prüfen)
• Prozessorientiertes Qualitätsmanagement
(Alle Mitarbeiter müssen ein Qualitätsbewusstsein entwickeln
permanente Adaptierung)
Grundkurs Software-Engineering mit UML
Stephan Kleuker
538
Zusammenhang der Q-Begriffe
Qualitätsmanagement
(Qualität aller Prozesse)
Prozess X
Prozess Y
Software-Entwicklungsprozess
Qualitätssicherung
konstruktiv
Grundkurs Software-Engineering mit UML
analytisch
Stephan Kleuker
539
Prozesse als Firmenqualitätsmaßstab: CMM[I]
• ursprünglich Capability Maturity Model (CMM)
• Auftrag durch das DoD
• Hilfsmittel zur Beurteilung der Leistungsfähigkeit von
Softwarelieferanten
• Reifegrad der Software-Entwicklungs5 Optimizing
prozesse ermitteln
• gezielte Prozessverbesserung
4 Quantitatively Managed
• CMM(I) definiert 5 Stufen der
Managed (CMM)
Reife einer Organisation
3 Defined
• aktuell: CMMI for
Development,
2 Managed
Version 1.2
Repeatable (CMM)
(CMMI-DEV)
1 Initial
Grundkurs Software-Engineering mit UML
Stephan Kleuker
540
Stufe 1: Initial
• Merkmal: Keine stabile Umgebung, ad-hoc
Durchführung
• Fokus: gute Mitarbeiter
• Unvorhersagbares Ergebnis: bei erneuter
Durchführung des Projektes würde alles ganz anders
laufen
• Brandbekämpfung statt Planung, Planabweichung in
Krisensituationen
• Gelingen des Projektes nur durch äußersten Einsatz
aller Beteiligter, hängt an Einzelpersonen
• Risikobehaftet, unplanbar und ineffizient
Grundkurs Software-Engineering mit UML
Stephan Kleuker
541
Stufe 2: Nachvollziehbar (managed)
• Merkmal: Gleiche Anforderungen ergeben gleiche
Resultate
• Fokus: Projektmanagement
– Richtlinien für Software-Projektmanagement
existieren und werden umgesetzt
– Überwachung von Zeit, Kosten, Produktqualität
• Basierend auf früheren Projekten
• Softwarestandards, Konfigurationsmanagement
• Stabiler Prozess
Grundkurs Software-Engineering mit UML
Stephan Kleuker
542
Stufe 3: Definiert (defined)
• Merkmal: Wohldokumentierte Prozesse
• Fokus: Organisationsunterstützung
– Stabile und wiederholbare SW-Entwicklungs- und
SW-Projektmanagement-Prozesse
– Abnahmekriterien, Standards, QS-Maßnahmen
definiert und dokumentiert
– Möglichkeit der Anpassung von Standards
• Rolle des Softwareprozess-Verantwortlichen
• Weiterbildungsmaßnahmen eingeplant
• Regelmäßige Expertenbegutachtung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
543
Stufe 4: Beherrscht (quantatively managed)
• Merkmal: Quantitativ messbare Prozesse
• Fokus: Produkt- und Prozessqualität
– Leistungsmessung von Produktivität und Qualität
– Metriken für Software
• Messbare, vorhersagbare Prozesse in definierten
Grenzen
• Messbare, vorhersagbare Produktqualität
• Steuerungsmöglichkeit bei Schwankungen
Grundkurs Software-Engineering mit UML
Stephan Kleuker
544
Stufe 5: Optimierend (optimizing)
• Merkmal: Gesamte Organisation fokussiert auf
kontinuierliche Prozessverbesserung
• Fokus: Ständige Evaluation und Einführung neuer
Technologien und Verbesserungsmöglichkeiten
– Möglichkeit zur Stärken/Schwächenanalyse
– Proaktive Fehlervermeidung
– Dauernde Implementierungsmöglichkeit für
Verbesserungen der Softwareprozesse (direkte
Einbringung von Verbesserungsvorschlägen)
• Verbesserungen auf der Meta-Ebene
Grundkurs Software-Engineering mit UML
Stephan Kleuker
545
Überblick: Verbesserungen mit dem CMMI
Stufe 5
Optimizing
Start
Ende
Start
Ende
Stufe 3
Defined
Start
Ende
Stufe 2
Managed
Start
Stufe 1
Initial
Start
Stufe 4
Quantitatively
Managed
Grundkurs Software-Engineering mit UML
Analyse
Entwicklung
Bearbeitung
Stephan Kleuker
Test
Ende
Ende
546
Skizze einer CMMI-Anpassung
alter
Firmenstandard
SP 1.1
des CMMI
Grundkurs Software-Engineering mit UML
nach CMMIÜberarbeitung
fehlen: Produkte,
Verantwortlichkeiten
Stephan Kleuker
547
Personal Software Process (PSP)
• CMMI gibt Rahmen für Unternehmensprozesse; nicht einfach
auf Individuum herunterbrechbar
• Ansatz: Entwickler durchlaufen Qualitätsentwicklung z. B.
durch Schulungen; Ansatz des PSP
in Programmierung ausgebildete Entwickler
definierten Prozess nutzen
Zeit erfassen
PSP 0
Defekte erfassen und analysieren
PSP 1
Arbeiten planen
Aufwände schätzen, Zeitpläne erstellen
Optimierungen analysieren
PSP 2
Qualitätsmanagement
Erstellung von Qualitätsplänen
Messung eigener Qualität
Entwickler mit garantierter Qualität und Schätzfähigkeit
Grundkurs Software-Engineering mit UML
Stephan Kleuker
548
Ganzheitliche Projektsicht
12.6
Arbeitsumfeld [schwarz]
Fähigkeiten (Know how) [blau]
soziale Ebene
[rot]
Grundkurs Software-Engineering mit UML
Prozessebene
[grün]
Stephan Kleuker
549
Ebenen des ganzheitlichen Projektmanagements
• Fähigkeiten: was können Projektmitglieder, welche
Erfahrungen haben sie
• Prozessebene: wie sind Arbeitsprozesse organisiert, sind
Rollen klar abgegrenzt
• Arbeitsumfeld: welche Werkzeuge gibt es, wie sind
Arbeitsplätze organisiert
• soziale Ebene: wer kann wie mit wem
Grundregel: Probleme der einen Ebene können nicht auf der
anderen Ebene gelöst werden
• wenn Leute nicht miteinander können, helfen
Prozessregelungen wenig
• fähige Mitarbeiter werden durch schlechte Werkzeuge, große
räumliche Trennung, unsaubere Toiletten ausgebremst
• neue Werkzeuge benötigen Schulungen und Einarbeitung
Grundkurs Software-Engineering mit UML
Stephan Kleuker
550
Teamrollen
• Es gibt einige psychologische Ansätze Menschen in ihrem
Verhalten zu kategorisieren
• Grobe Beschreiben, wie „eher extrovertiert“ oder „introvertiert“
sind möglich
• Es gibt Typen die typischerweise gut miteinander können und
andere, die zu Konflikten führen
• Selten, dass Menschen sehr gute Techniker und sehr gute
Verkäufer sind
• Für erfolgreiche Projekte werden unterschiedliche Typen
benötigt
• „zu einem Typ gehörig“ ist weder negativ noch positiv; Teams
müssen harmonisch zusammengesetzt werden
• vorgestellter Ansatz beruht auf Meredeth Belbin
• Achtung: Das Einteilen von Menschen in Typen mit bestimmten
Verhaltensweisen ist aus gutem Grund von vielen Seiten
angreifbar
Grundkurs Software-Engineering mit UML
Stephan Kleuker
551
Teamrollentypen nach Belbin (1/3)
• Specialist
– Experten, können sich neue Techniken erarbeiten, Stolz auf
eigene Fähigkeiten
– wenig Interesse an Anderen
• Completer Finisher
– sorgfältig bis ins Detail, beginnen nur Sachen, die sie
beenden können, arbeiten stark aus eigenem Antrieb
– delegieren ungern, undiplomatisch gegenüber Generalisten
• Implementer
– gute Pragmatiker (was ist wichtig und machbar),
systematisch im Umgang mit komplexen Aufgaben, loyal
zum Unternehmen, eher introvertiert, integer
– nicht spontan, steht sehr kreativen Ideen ablehnend
gegenüber
Grundkurs Software-Engineering mit UML
Stephan Kleuker
552
Teamrollentypen nach Belbin (2/3)
• Teamworker (ausgeglichen, extrovertiert, kaum dominant)
– guter Zuhörer, kommuniziert frei mit allen im Team, passt
sich neuen Situationen schnell an
– geht Konfrontationen aus dem Weg, überfordert mit
zentralen Entscheidungen
• Monitor Evaluator
– ausgeglichen, ernsthafter klarer Blick für die aktuelle
Situation, meist hohe Intelligenz, hohe Kreativität, entdeckt
schnell Fehler
– braucht lange für Entschlüsse, manchmal taktlos und
herabsetzend in Analysen, zu kritisch
• Shaper
– hoch motiviert, leitet und koordiniert Teams gerne, findet
Wege um Probleme, extrovertiert, besorgt, ob gewünschter
Fortschritt erreicht wird
– impulsiv, ungeduldig, manchmal leicht reizbar, gibt
vielleicht zu schnell auf
Grundkurs Software-Engineering mit UML
Stephan Kleuker
553
Teamrollentypen nach Belbin (3/3)
• Co-ordinator
– stabil, dominant, extrovertiert, diszipliniert, führt Team,
bemüht, externe Ziele und Vorgaben zu erreichen, guter
Kommunikator, gut in der Besetzung von Projektrollen
– eher kein kreativer Denker, geht (zu) ruhig an Aufgaben
heran
• Resource Investigator
– locker, kommunikativ, leicht zu interessieren, bringt Ideen
von Außen, Diplomat, Verkäufer, viele Außenkontakte
– neigt zu zu großem Enthusiasmus, lässt Sachen schnell
fallen, benötigt Anregungen von Außen
• Plant
– Quelle von originellen Ideen, Anregungen und Vorschlägen,
dominierend, meist hohe Intelligenz, konzentriert auf
Hauptaufgaben
– introvertiert, kann störend oder kränkend wirken, kein
Detailinteresse, wenig kritikfähig
Grundkurs Software-Engineering mit UML
Stephan Kleuker
554
Ermittlung des Teamrollentypen
• Möglichkeit mit Fragebogen, möglich zur Selbstbewertung und
Fremdbewertung
• Beispiel: Verteilen Sie 10 Punkte auf die folgenden Aussagen,
die auf Sie am Besten zutreffen (Häufung von Punkten auf
wenigen Aussagen gewünscht)
Wie verhalte ich mich, wenn ich mit anderen Leuten an einem
Projekt beteiligt bin:
– Ich besitze die Gabe jemanden zu beeinflussen, ohne ihn
unter Druck zu setzen
– Meine ständige Wachsamkeit verhindert Leichtsinnsfehler
und Versäumnisse
– Man kann sich darauf verlassen, dass ich originelle Ideen
habe
– Ich bin immer bereit, gute Vorschläge zu unterstützen, wenn
sie im allgemeinen Interesse sind
– Ich bin immer begierig, die allerneusten Ideen und
Entwicklungen zu entdecken
– ...
Grundkurs Software-Engineering mit UML
Stephan Kleuker
555
Kommunikation
• Paul Watzlawik: „Man kann nicht nicht kommunizieren“
• Versuch, eine gemeinsame Informationsbasis zu finden
• abhängig vom gemeinsamen Verständnis
Decodierung
Feedback
Codierung
Sender
Empfänger
Codierung
Nachricht
Decodierung
• wichtig: Hintergründe, was passiert wann bei wem wohl warum,
der Kommunikation erkennen
• Achtung! Überinterpretationen
• Kommunikationsverhalten kann/soll geschult werden, wobei
Authentizität erhalten bleiben muss
Grundkurs Software-Engineering mit UML
Stephan Kleuker
556
vierfache Gestalt einer Äußerung (1/4) [SRS03]
• Jeder Äußerung kann man vier Ebenen zuordnen
• Beispiel: Prof zum Studi, „Die Klasse sollten Sie endlich mal
kommentieren“
• Jede Äußerung enthält die vier genannten Botschaften
• für jede Botschaft kann es eine Interpretation des Senders und
des Empfängers geben
• bei mehreren Anwesenden vervielfacht sich die Interpretation
Grundkurs Software-Engineering mit UML
Stephan Kleuker
557
vierfache Gestalt einer Äußerung (2/4)
• Sachinhalt (worüber ich informiere)
– Beispiel: Klassen sind zu kommentieren
– kann aus Wahrheitsgehalt geprüft werden
– kann auf Relevanz geprüft werden
– kann auf Hinlänglichkeit geprüft werden (reicht Information
aus, verstehen beide das Gleiche)
– meist zentraler Bestandteil der Äußerung
• Selbstkundgabe (was ich von mir zu erkennen gebe)
– Beispiel: Prof ist verunsichert, ob zentrale Wünsche ernst
genommen werden, Studi meint, dass Prof schlechte Laune
hat
– was geht in mir vor, wofür stehe ich, wie sehe ich meine
Rolle
– individuelle Schnabelform: Selbstdarstellung, Authentizität
Grundkurs Software-Engineering mit UML
Stephan Kleuker
558
vierfache Gestalt einer Äußerung (3/4)
• Beziehung (was ich von dir halte und wie ich zu dir stehe)
– Beispiel: Prof glaubt, dass Studi Potenzial hat, seine
Schludrigkeit ihn aber von besseren Ergebnissen abhält,
Studi meint, dass Prof ihn für unfähig hält, selbst einfachste
Aufgaben zu lösen
– geprägt durch Tonfall, Formulierung und Kontext der
Äußerung
– meist ein sehr sensibles Ohr
– Beziehungsebene muss stabil sein, da sonst hier viele
unterschwellige Konflikte möglich
• wenn nicht: Uneinigkeit auf der Sachebene führt zu
Störung der Beziehungsebene
Grundkurs Software-Engineering mit UML
Stephan Kleuker
559
vierfache Gestalt einer Äußerung (4/4)
• Appell (was ich bei dir erreichen möchte)
• Beispiel: Prof möchte, dass der Studi systematischer arbeitet,
Studi (miss)-interpretiert, mach erstmal einfache Aufgaben
bevor du programmierst
• bei längeren Äußerungen kann der konkrete Appell verloren
gehen
• wenig erfolgreich, aber verbreitet: Appell mit negativer
Beziehungsbotschaft zu verknüpfen „können Sie endlich mal
...“
Literatur
• [SRS03] F. Schulz von Thun, J. Ruppel, R. Stratmann,
Miteinander Reden: Kommunikationspsychologie für
Führungskräfte, 2. Auflage, Rowohlt, Reinbek, 2003
Grundkurs Software-Engineering mit UML
Stephan Kleuker
560
Teufelskreis „Führung“ [SRS03]
• Kommunikationsproblem: „Verstärkung der
Ansichten und negativen Empfindungen“
Führungskräfte
machen:
planen ihre Entscheidungen
am „grünen Tisch“, tun seltene
Kritik ab „höre ich selten,
andere schaffen es auch“
fühlen:
Bestätigung,
dass der Kurs
stimmt
fühlen:
Druck, Angst
vor Positionsverlust
machen:
schweigen, dulden, antworten,
auf Nachfragen „Läuft alles
soweit gut“
Grundkurs Software-Engineering mit UML
Stephan Kleuker
Mitarbeiter
561
Metakommunikation
• Denken über Kreise, statt handeln in den Rechtecken
• Kommunikation über den Nachrichtenfluss
• Ausgangspunkt: Beschreibung des eigenen Fühlens und der
Wahrnehmung des Anderen
• persönliches Gespräch
• fördert offene Kommunikation
• Metakommunikation ist ein scharfes Schwert, dass mit Bedacht
eingesetzt werden muss
• Übungsaufgabe: Überlegen Sie Kommunikationsteufelskreise
in Ihrem momentanen Leben und ob Metakommunikation
helfen könnte
Grundkurs Software-Engineering mit UML
Stephan Kleuker
562