Software Engineering - Fachbereich Informatik

Software Engineering - Fachbereich Informatik
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
1. Einleitung
Quellenhinweis: Diese Folien entstanden in enger Kooperation mit Prof. R. Hahn.
Einige Folien stammen aus Präsentationen von Prof. G. Raffius, Prof. B. Humm und anderen Professoren des FBI
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
1
Eine Anekdote
Spitzenleute werden auf ein teures Seminar geschickt.
Sie sollen lernen, auch in ungewohnten Situationen Lösungen zu erarbeiten.
Am zweiten Tag wird einer Gruppe von Managern die Aufgabe gestellt, die Höhe einer
Fahnenstange zu messen.
Sie beschaffen sich also eine Leiter und ein Maßband. Die Leiter ist aber zu kurz, also
holen sie einen Tisch, auf den sie die Leiter stellen. Es reicht immer noch nicht. Sie
stellen einen Stuhl auf den Tisch, aber immer wieder fällt der Aufbau um.
Alle reden durcheinander, jeder hat andere Vorschläge zur Lösung des Problems.
Eine Frau kommt vorbei, sieht sich das Treiben an. Dann zieht sie die Fahnenstange
aus dem Boden, legt sie auf die Erde, nimmt das Maßband, misst die Stange, schreibt
das Ergebnis auf einen Zettel und drückt ihn einem der Männer in die Hand.
Kaum ist sie um die Ecke, sagt einer: "Typisch Frau! Wir benötigen die Höhe der Stange
und sie misst die Länge! Deshalb lassen wir Weiber auch nicht in den Vorstand.„
Was wird hier falsch gemacht?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
2
1. Einleitung
Aussagen im Umfeld des Software Engineering
 „Programmieren klappt doch auch so!“
 „Wen interessieren schon Boxen und Linien?“
 „Ihr werdet nicht für bunte Folien mit Kästchen bezahlt!“
 „Prozesse haben noch nie ein Produkt geliefert!“
Wozu brauchen Sie Software Engineering?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
3
1. Einleitung
Szenario
 Stellen Sie sich bitte folgendes vor:
 Sie arbeiten in einem Software-Projekt mit einem
Entwicklungsaufwand von
ca. 15 Mio. Euro (50 Personen über 3 Jahre)
 Geplanter Umsatz des Projekts sind ca. 500 Mio. Euro
 Sie müssen nach der Auslieferung 10 Jahre Wartung bieten
 Die Zukunft Ihrer Firma, Ihr Gehalt und Ihre Karriere hängen
am Erfolg des Projektes
Welche Probleme können dann auf Sie zukommen?
... in der Entwicklung ?
... im Management ?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
4
1. Einleitung
Gründe für den Einsatz von Software Engineering








Komplexität:
Funktion:
Qualität:
Wartung:
Planung:
Organisation:
Methodik:
…
Strukturierung, Verbergen von Details
Erfassen der Wünsche von Kunde (und eigener Firma)
Sicherheit, Regressanspruch, Zugänglichkeit
Gewährleistung, Dokumentation
Umfang, Personal, Kosten, Termine, Qualität, Reporting
Teamgröße, Standortverteilung, unterschiedliche Sprache
Arbeitstechniken, Prozesse, Standards
 große Softwaresysteme in vorgegebener Qualität im vorgegebenen ZeitRahmen erstellen!
 Vermittlung von Modellen, Methoden und Techniken für die Arbeit
in solchen Projekten
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
5
1. Einleitung
Konkrete Gründe für die Notwendigkeit von Software Engineering
 In komplexen Projekten…








kann (und will) eine Person nicht mehr alles wissen
ist Aufgabenteilung erforderlich
gibt es oft verteilte Entwicklung
gibt es Wartungsverpflichtungen
muss ein Budget realistisch abgeschätzt und dann eingehalten werden
gibt es Mitarbeiterfluktuation während der Laufzeit
gibt es Qualitätsauflagen (Intern oder vom Auftraggeber)
…
 Software Engineering (oder auch "Software-Technik")…
 bietet Methoden um damit umzugehen!
 ist der einzige bekannte Lösungsansatz für komplexe Projekte!
 wird in der industriellen SW-Entwicklung von Informatikern erwartet!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
6
1. Einleitung
SWE im Projekt (Auszug)
Kunde
(Auftraggeber)
Marketing
Manager
(Controlling,
Projektleitung)
Durchführung von Maßnahmen
Qualitätssicherung
SW-Entwicklung
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
7
1. Einleitung
SWE im Projekt (Auszug)
Vorgehen
Prozesse
Planung
Kunde
(Auftraggeber)
Marketing
UML
Qualität
Prozesse
UML
Manager
(Controlling,
Projektleitung)
Durchführung von Maßnahmen
Qualitätssicherung
OO, UML
Prozesse
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
SW-Entwicklung
8
1. Einleitung
Konzept der Veranstaltungen OOAD und SWE
 OOAD
 Praktikum OOAD
 Objektorientierung
 Analyse und Design
 Dokumentation der Arbeit
-
UML
 "Handwerkszeug" für SW-Entwickler
-
Gutes Design
 SWE
 Gesamtkonzept / Zusammenhänge
-
Arbeit in großen Projekten
Anwendung des Handwerkszeugs
Qualitätssicherung
Organisation
 Umgang mit dem Handwerkszeug
-
Erste Modellierung
"Entwickeln" eines Mini-Projekts
Arbeit mit der UML
Kennenlernen des CASE-Tools
Kennenlernen der Entw.umgebung
(siehe Prakt.-Aufgabe letztes
Semester)
 Praktikum SWE
 Anwendung der Verfahren aus
OOAD und SWE
 Entwicklung eines Systems in kleinen
Teams
 Möglichst hohe Realitätsnähe
-
Eigenständige Lösung der Aufgaben
Überprüfung durch Reviews
Aufteilung der Arbeiten im Team
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
9
1. Einleitung
Literatur
"Methodische objektorientierte
Software-Entwicklung";
Mario Winter;
dpunkt-Verlag; 2005
"Software Engineering"
Jochen Ludewig, Horst Lichter;
dpunkt Verlag; 2006
"Software Engineering"
Ian Sommerville;
Pearson Studium;
9. Auflage, 2010
"Softwareentwicklung
von Kopf bis Fuß"
Dan Pilone, Russ Miles;
O'Reilly Verlag; 2008
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
10
Hochschule Darmstadt
Fachbereich Informatik
Objektorientierte Analyse und Design
2. Grundlagen des Software Engineering
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
11
2. Grundlagen des Software Engineering
Lernziele
 Sie sollen in diesem Kapitel verstehen,






was alles zu Software gehört
wie Software Engineering entstanden ist
was Qualität von Software ausmacht
wie wichtig die Qualitätseigenschaften für die Software sind
welche Phasen in der SW-Entwicklung vorkommen
welche Inhalte die Entwicklungsphasen haben
Hinterher ahnen Sie, warum in großen Projekten anders
gearbeitet wird, als in kleinen Projekten!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
12
2. Grundlagen des Software Engineering
Was ist das Problem?
 Komplexe SW-Projekte sind gekennzeichnet durch
 Software wird in mehreren Versionen weiterentwickelt und erweitert
- Bedeutung von Dokumentation und Modellen für die Wartbarkeit
 Lange Entwicklungszeit
- Bedeutung von Projektplanung und Terminüberwachung
 Einsatz von Entwicklerteams evtl. an mehreren Standorten
- Bedarf an Standards und Regeln für Kommunikation und Dokumentation
 Lange Lebensdauer mit sich verändernden Anforderungen
- Bedeutung von Dokumentation und Modellen für die Änderbarkeit
 Die Methode VHIT (Vom Hirn Ins Terminal) ist zur Entwicklung
solcher Projekte nicht geeignet
 Wir benötigen andere Vorgehensweisen als für das Programmieren
einer kleinen Anwendung
 Wie kann man "ingenieurmäßig" Software entwickeln?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
13
2. Grundlagen des Software Engineering
Begriffsklärung: Was ist Software?
 Software
 Enges Verständnis:
... unter Software subsumiert man alle immateriellen Teile, d.h. alle auf einer
Datenverarbeitungsanlage einsetzbaren Programme
(Lexikon der Informatik und Datenverarbeitung. H.-J. Schneider (Hrsg.), 1986)
 Mittleres Verständnis:
Software (engl., eigtl. »weiche Ware«), Abk. SW, Sammelbezeichnung für
Programme, die für den Betrieb von Rechensystemen zur Verfügung stehen,
einschl. der zugehörigen Dokumentation (Brockhaus Enzyklopädie)
 Weites Verständnis = Unser Verständnis:
Software: Menge von Programmen oder Daten zusammen mit begleitenden
Dokumenten, die für ihre Anwendung notwendig oder hilfreich sind
(Ein Begriffssystem für die Softwaretechnik, W. Hesse et al., 1984)
Software: Computer programs, procedures, rules, and possibly associated
documentation and data pertaining to the operation of a computer system
(IEEE Standard Glossary of Software Engineering Terminology, ANSI 1983).
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
14
2. Grundlagen des Software Engineering
Was ist Software Engineering? (1)
 Zielorientierte Bereitstellung und systematische Verwendung
von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige,
ingenieurmäßige Entwicklung und Anwendung von umfangreichen
Software-Systemen.
(in Anlehnung an Balzert, SWT-Lehrbuch)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
15
2. Grundlagen des Software Engineering
Zeit
Was ist Software Engineering? (2)
 Die Kunst, wie man Softwaresysteme
in der erforderlichen Qualität, zum
gewünschten Termin mit gegebenen
Kosten erstellt
Kosten
Qualität
„Das magische Dreieck“
 d.h. Vermittlung von Modellen, Methoden und Techniken für:
- die konstruktiven Phasen der Software Entwicklung (Analyse, Entwurf, Implementierung),
die verwendet werden um die Arbeitsergebnisse
dieser Phasen zu strukturieren.
- Definition von Qualität (Qualitätseigenschaften, Qualitätsmodelle).
- zeitlichen Strukturierung in verschiedene Entwicklungsphasen (Phasenmodelle).
- Überprüfung der Phasenergebnisse (Test, Verifikation, Qualitätssicherung).
 In Software Engineering lernen Sie eine Menge von nützlichen
Werkzeugen kennen. Welches Werkzeug für welches Projekt
angebracht ist, müssen Sie aber immer noch selbst entscheiden!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
16
2. Grundlagen des Software Engineering
Geschichtliche Entwicklung (1)
 In der „Steinzeit“ der Software Entwicklung, in den 50er und 60er Jahren:
 Hardware war sehr teuer und wenig leistungsfähig
 Wo waren Computer eingesetzt? Welche Tätigkeiten konnte man damals durch
den Computer unterstützen?
 Software und Computer fast ausschließlich im naturwissenschaftlichen Bereich
 Die eingesetzten Programme dienten hauptsächlich der Lösung mathematischer
Probleme
 Die relativ kleinen Programme waren sehr preisgünstig oder wurde von den
Anwendern selbst geschrieben.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
17
2. Grundlagen des Software Engineering
Geschichtliche Entwicklung (2)
 Durch sinkende Hardwarepreise:
 Computer wurden für eine größere Zielgruppe erschwinglich.
 Es veränderten sich die Anforderungen an die Software:
- Software wurde für die verschiedensten Bereiche gebraucht.
- Der Umfang der Software wurde immer größer.
- Ihre Komplexität war mit den bis zu diesem Zeitpunkt bekannten Vorgehensweisen für
das „Programmieren im Kleinen“ nicht mehr zu beherrschen.
 fehlerhafte und unzuverlässige Programme
 nicht termingerechte Fertigstellung
 geplante Kosten wurden überschritten
 Dieser Zustand der Software Industrie wurde charakterisiert mit dem Begriff
"Softwarekrise"
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
18
2. Grundlagen des Software Engineering
Geschichtliche Entwicklung (3)
 Reaktion darauf:
 strukturierte Programmiersprachen (keine GOTOs)
 Entwicklungsmethoden
 Der Begriff „Software Engineering“ wurde zuerst auf einer
Software-Engineering-Konferenz der NATO 1968 in Garmisch geprägt.
 Diese Konferenz gilt als Geburtsstunde des Software Engineering
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
19
2. Grundlagen des Software Engineering
Geschichtliche Entwicklung (4)
1. Erster Ansatz zur Entwicklung übersichtlicher Programme (1968)
 "strukturierte Programmierung": Vermeidung von GOTO-Anweisungen etc.
(Dijkstra)
2. Entwicklung von Software-Engineering-Prinzipien (1968 - 1974)
 Strukturiertere Entwicklung von Programmen:
-
strukturierte Programmierung
schrittweise Verfeinerung
Geheimnis-Prinzip
Programmmodularisierung
Software-Lifecycle
Entitiy-Relationship-Modell
Software-Ergonomie
Frage: Wissen Sie, was sich hinter den Begriffen verbirgt?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
20
2. Grundlagen des Software Engineering
Geschichtliche Entwicklung (4)
1. Erster Ansatz zur Entwicklung übersichtlicher Programme (1968)
 "strukturierte Programmierung": Vermeidung von GOTO-Anweisungen etc.
(Dijkstra)
2. Entwicklung von Software-Engineering-Prinzipien (1968 - 1974)
 Strukturiertere Entwicklung von Programmen:
-
strukturierte Programmierung (keine GOTOs, nur Verzweigung, Schleifen, Pozeduren),
schrittweise Verfeinerung (Hierarchie von Funktionen, Top-down-Entwurf),
Geheimnis-Prinzip (rufende Prozedur kennt nur Schnittstellen der aufgerufenen Proz.),
Programmmodularisierung (Aufteilen des Programms in Teile)
Software-Lifecycle (mehrere Phasen der SW-Entwicklung)
Entitiy-Relationship-Modell (konzeptionelles Datenmodell mit Datenobjekten und Bez.),
Software-Ergonomie (bedienerfreundliche Benutzerschnittstelle)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
21
2. Grundlagen des Software Engineering
Geschichtliche Entwicklung (5)
3. Entwicklung von phasenspezifischen Software-Engineering-Methoden
(1972 - 1975)
 Umsetzen der Software-Engineering-Prinzipien in Entwurfsmethoden:
- Struktogramme
- HIPO (Hirachical - Input - Process - Output)
- Jackson, Constantine-Methode / Structured Analysis (Workflow), Structured Design
(Spezielle Aufrufhierarchiediagramme)
4. Entwicklung von phasenspezifischen Werkzeugen (1975 - 1985)
 Einsatz von SE-Methoden mit maschineller Unterstützung z.B.
- ProgrammInversion
(zu einer Prozedur: Tabellarische Auflistung von gerufenen Prozeduren, rufenden
Prozeduren, Verwendeten Bildschirmmasken, gelesene, geschriebene Dateien, ... – auch
als Aufrufmatrix -> Kap. Metriken)
- Batchwerkzeuge
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
22
2. Grundlagen des Software Engineering
Geschichtliche Entwicklung (6)
5. Entwicklung von phasenübergreifenden (integrierten) Software-EngineeringMethoden (ab 1980)
 Automatische Weitergabe der Ergebnisse einer Phase des Software-Lifecycles
an die nächste Phase: Methodenverbund
6. Entwicklung von phasenübergreifenden (integrierten) Werkzeuge (Case-Tools)
(ab 1980)
 Einsatz einer Datenbank als automatischer Schnittstelle zwischen den einzelnen
Phasen des Software-Lifecycles.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
23
2. Grundlagen des Software Engineering
Geschichtliche Entwicklung (7)
7. Definition verschiedener, konkurrierender objektorientierter Methoden
(ab 1990)
 Es entstanden parallel verschiedene objektorientierte Analyse- und
Entwurfsmethoden:
-
Booch
Jacobson
Rumbaugh
Shlaer/Mellor
Coad/Yourdon u. a.
 Die Methoden wurden in CASE Tools realisiert.
8. Integration der OO-Methoden zur UML- Unified Modeling Language (ab 1995)
 Jacobson, Booch und Rumbaugh schließen sich zusammen und entwickeln die
UML. Die UML soll
- die Schwächen der frühen OO-Methoden beseitigen und
- ein weltweit gültiger, einheitlicher Standard werden
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
24
2. Grundlagen des Software Engineering
Geschichtliche Entwicklung (8)
9. Definition von mächtigen Methoden zur Entwicklung von Systemen (ab 1997)
 Es entstanden parallel verschiedene Vorgehensmodelle:
- RUP (Rational Unified Process) seit 1998
- V-Modell XT (seit 2005)
- u. a.
 Die Methoden erfordern oft mächtige Tools.
10. Agile Software Entwicklung (seit 2000)
 Das „Agile Manifest“ wird von Kent Beck und 16 weiteren anerkannten Größen
der Software Entwicklung unterschrieben und veröffentlicht (2001)
 Gegenbewegung zu den „schwergewichtigen Methoden“ als Rückbesinnung auf
das eigentliche Ziel: lauffähige Software
 Es stellt Menschen, lauffähige Software, Zusammenarbeit und
Änderungsbereitschaft über Prozesse, Dokumentation, Verträge und Pläne.
Software Engineering, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, WS 2013, h_da, Fachbereich Informatik
25
Hochschule Darmstadt
Fachbereich Informatik
Objektorientierte Analyse und Design
2.1 Grundlagen des Software Engineering:
Softwarequalität
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
26
2.1 Grundlagen des Software Engineering: Softwarequalität
Ziel des Software Engineering
 Ziel:
 Softwaresysteme in der erforderlichen Qualität, zum gewünschten Termin mit
gegebenem Kosten erstellen
 Welche Eigenschaften machen für SIE die Qualität einer Software aus?
 aus Entwicklersicht?
 aus Benutzersicht?
 Was ist Qualität / eine Qualitätseigenschaft?
 Und welche Qualität ist erforderlich? Wie definiere ich das?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
27
2.1 Grundlagen des Software Engineering: Softwarequalität
Softwarequalitätseigenschaften
Funktionserfüllung
Qualitätsmerkmale aus
Benutzersicht
Qualitätsmerkmale aus
Entwicklersicht
Effizienz
HW-Effizienz
Zuverlässigkeit
SW-Effizienz (Performance)
Benutzbarkeit
Robustheit
Sicherheit
Fehlertoleranz
Erweiterbarkeit
Änderbarkeit
Wartbarkeit
Verständlichkeit
Übertragbarkeit
Testbarkeit
Wiederverwendbarkeit
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
28
2.1 Grundlagen des Software Engineering: Softwarequalität
Softwarequalitätseigenschaften: Beispiele
 Funktionserfüllung
tatsächlich realisierter Funktionsumfang
geplantes System
 Effizienz


Hohe Ablaufgeschwindigkeit (Performanz)
wenig HW-Ressourcenverbrauch (z. B. geringer Speicherplatzbedarf)
- HW wird immer billiger ⇒ verliert immer mehr an Bedeutung
- Aber: immer noch wichtig bei hohen Stückzahlen z.B. bei embedded Systems

Schnelle Algorithmen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
29
2.1 Grundlagen des Software Engineering: Softwarequalität
Softwarequalitätseigenschaften: Bedeutung
 Die Umsetzung von Qualitätseigenschaften verursacht erhebliche Aufwände
 nachträgliche Änderungen von nicht eingeplanten Qualitätseigenschaften
sind in der Regel sehr aufwändig
 Qualitätseigenschaften sind nicht unabhängig voneinander.
 Werden Maßnahmen zur Verbesserung einer Qualitätseigenschaft getroffen, so
wirken sich diese möglicherweise auf andere Qualitätseigenschaften negativ aus.
 Beispiel:
 Wird die Effizienz verbessert, kann dies ein unzuverlässigeres System ergeben;
die Robustheit kann sinken, das System kann schwerer änderbar sein
(weil die Effizienzsteigerung z.B. durch Assemblereinsatz erreicht wurde)
 Hardwarenahe Programmiersprachen wirken sich natürlich auch auf die
Wartbarkeit und Übertragbarkeit aus.
 Die Festlegung der geforderten Qualitätseigenschaften ist
genauso wichtig wie die Festlegung der Funktionalität
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
30
2.1 Grundlagen des Software Engineering: Softwarequalität
Maße für Qualität(seigenschaften)
 Bei der Spezifikation muss die Qualität der zu erstellenden Software definiert
werden
 Es kann nach der Fertigstellung nachgeprüft werden, ob die Software den
spezifizierten Qualitätsanforderungen genügt.
 Funktionserfüllung:
 Test: Funktioniert die Software so wie vereinbart?
 d.h. tut die Software das, was in der vom Auftraggeber abgezeichneten
Spezifikation steht?
 Effizienz:
 spezifiziert durch Angabe von maximalen Antwortzeiten, Speicherverbrauch etc.
 Zuverlässigkeit:
 Spezifiziert durch Wahrscheinlichkeit, dass in der Zeit 0-t kein Fehler auftritt.
 Andere Maße, wie z.B. für Erweiterbarkeit oder Wartbarkeit:
 sind schwieriger zu definieren ( Kapitel Softwaremetriken)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
31
2.1 Grundlagen des Software Engineering: Softwarequalität
Qualität in der (deutschen) Sprache
 Die "Qualität", die ein Produkt hat, wird häufig in direkter Verbindung mit der
Fehlerfreiheit gesehen
 Es gibt allerdings viele andere Qualitätseigenschaften, welche die Qualität eines
Produkts bestimmen
 Die Zuverlässigkeit ist nur eine dieser Qualitätseigenschaften
 Die "erforderliche Qualität" hängt stark vom Projekt ab und wird auch oft von
verschiedenen Beteiligten unterschiedlich gesehen
- aus Sicht der Entwicklerfirma soll das Produkt z.B. erweiterbar sein und wenig
Wartungskosten verursachen
- aus Sicht des Anwenders soll es z.B. die gewünschten Funktionen bieten, zuverlässig
und sicher sein
 Es gibt Qualität im Sinn von Zuverlässigkeit und Qualität als Oberbegriff für die
gesammelten (Qualitäts)Eigenschaften eines Systems
 Der Begriff „Qualität“ wird umgangssprachlich
für beide Aspekte verwendet!
Software Engineering, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, WS 2013, h_da, Fachbereich Informatik
32
Hochschule Darmstadt
Fachbereich Informatik
Objektorientierte Analyse und Design
2.2 Grundlagen des Software Engineering:
Phasen der Softwareentwicklung
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
33
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Phasen der Softwareentwicklung
 Was denken Sie
 Welche Phasen gibt es im SW-Erstellungsprozess?
 Welche Phasen kennen Sie schon?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
34
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Der Software Lebenszyklus (Software Life Cycle)
Analyse
Einführung,
Betrieb
Abnahme
IntegrationsTest
Definition
Architektur
Integration
KomponentenTest
Design
Implementierung
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
35
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Phasen bei der Softwareentwicklung
 Im Praktikum "Programmieren"
 wurde immer eine Aufgabe gestellt, d.h. die Definition war vorgegeben
- es wurde nie gefragt, ob die Entwicklung sinnvoll ist
 Sie mussten sich nur wenig Gedanken über den Aufbau des Systems machen
- es ging direkt los mit der Implementierung – es war keine Planung erforderlich
 Bei der Entwicklung großer Systeme gibt es wichtige Phasen schon vor der
Implementierung:
 Analyse:
- Einarbeitung in die fachlichen Gegebenheiten
- Soll ein System erstellt werden?
- Ist eine Erstellung unter Kostengesichtspunkten ratsam und möglich?
 Definition (oft Teil der Analyse-Phase:
- Spezifikation des Funktionsumfang und Qualität gemeinsam mit Benutzer / Auftraggeber
 Architektur und Entwurf:
- Strukturierung des Systems und Entwurf der IT-Lösung
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
36
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Analyse
 In der Analysephase
 wird erarbeitet (und verstanden) was die Software leisten soll
 Ein Systemanalytiker muss
-
das Anwendungsgebiet verstehen, den Ist-Ablauf aufnehmen,
begreifen was der Kunde will,
die Schwachstellen analysieren und Verbesserungsvorschläge prüfen,
zusätzliche Wünsche berücksichtigen.
Verstehen, was die Software leisten soll
 Ergebnis
- Die fachlichen Anforderungen an die Software werden dokumentiert und mit dem
Auftraggeber abgestimmt
- Es wird analysiert ob die Aufgabe durchführbar (lösbar) ist
- ob sie finanzierbar ist und ob das notwendige Personal vorhanden ist
- Es wird eine erste Kostenkalkulation vorgenommen
 Fehler in der Analysephase
- sind sehr teuer und wirken sich auf alle folgenden Phasen aus
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
37
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Definition (oft auch Teil der Analysephase)
 In der Definitionsphase
 informellen Anforderungen der Analyse überführt in eine
 (möglichst) vollständige, konsistente Spezifikation
 Ergebnis
-
Beschreibt wie das Produkt aus Benutzersicht funktionieren soll
insbesondere wird der Abnahmetest mit dem Benutzer / Auftraggeber festgelegt
Soll normalerweise implementierungsunabhängig formuliert sein
Legt bereits Qualitätseigenschaften fest
 Die Definition beschreibt, „Was“ das System tun soll
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
38
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Architektur (Grobentwurf)
 In der Architektur
 wird die IT-Lösung auf einer hohen Abstraktionsebene entworfen
 es werden Festlegungen getroffen
-
Systembestandteile
Schnittstellen zu anderen Systemen
Interne Schnittstellen zwischen Systemteilen
Grundlegende Art der Umsetzung (z. B. Schichtenarchitektur)
 Ergebnis
- Das System wird in grundlegende Bestandteile (Komponenten) zerlegt, die in
Architekturdiagrammen (z.B. Komponentendiagramm) dargestellt werden
- Tests für die grundlegenden Eigenschaften des Systems (Qualitätseigenschaften)
 Die Architektur beschreibt grob, „Wie“ das System aufgebaut ist
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
39
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Design (Feinentwurf)
 Im Entwurf
 wird die IT-Lösung nahe am Zielsystem entworfen
 werden diverse Festlegungen getroffen
-
Bei kleinen Systemen
werden Architektur und
Entwurf oft
zu einer Phase "Design"
zusammen gelegt
welches Betriebssystem,
welche Programmiersprache
welche Hardware,
Grundlegende Umsetzungsprinzipien (Design Patterns)
Datenbanksystem, notwendige Systemschnittstellen zu Fremdsystemen etc.
 Ergebnis
- Das System (bzw. seine Komponenten) wird in Klassen zerlegt, die in
Designdiagrammen (z.B. Klassen-, Sequenzdiagramm) dargestellt werden
- Testpläne für die einzelnen Module und zusammengebaute Bestandteile
 Das Design beschreibt, „Wie“ das System im Detail aufgebaut ist
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
40
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Implementierung, Integration und Tests
 Implementierung und Test
 kennen Sie schon aus der Lehrveranstaltung Programmieren.
 Zumindest kleine Programme wurden von Ihnen implementiert und (grob) getestet

Komponenetentest, Integration und Integrationstest bei großen Systemen
 Bei großen Systemen kann man das System nicht als Ganzes implementieren und
testen
 implementiere und teste zuerst die einzelnen Module (=Funktionen bzw.
Komponenten) (Funktionen- bzw. Komponententest)
 montiere anschließend diese getesteten Module schrittweise zusammen
(Integration) und teste sie (Integrationstest, Systemtest).
 Vor Beginn der eigentlichen Codierung:
- Es wird entschieden, in welcher Reihenfolge die Komponenten implementiert und
zusammengebaut werden (z. B. Top-Down- oder Bottom-Up-Vorgehensweise).
- Detaillierte Testpläne für die einzelnen Funktionen, Komponenten, für die Teilsysteme
und das Gesamtsystem sind, falls nicht schon in vorhergehenden Phasen geschehen,
zu erstellen.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
41
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Abnahme
 Abnahme
 Kennen Sie schon aus dem Programmierpraktikum.
 Es wird geprüft:
- Stimmen die Leistungen des Systems mit den in der Spezifikation vereinbarten
Leistungen überein? ("Abnahmetest")
- Ein Abnahmetest für ein großes System muss systematisch geplant werden und ist
wesentlich aufwendiger als im Programmierpraktikum
- Ist ein externer Auftraggeber vorhanden, überprüft dieser die Systemfunktionen mit
einem eigenen Prüfkatalog
 Ergebnis
- Im Programmierpraktikum: Sie bekamen Ihre Abnahme – fertig –
- Bei der kommerziellen Softwareentwicklung: Die Software kommt zum Einsatz
d.h. der Betrieb des Systems
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
42
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Einführung
 In der Einführung ("Rollout")
 wird das neue System in Betrieb genommen und evtl. ein altes System
abgeschaltet
- Evtl. stückweise Umstellung
- Evtl. mit Möglichkeit zur Wiederherstellung des alten Systems ("Rollback")
- Evtl. anfangs Parallelarbeit im alten und neuen System
 Tätigkeiten
-
Planung der Einführung (Termine, Ankündigungen, Verteilung von Anleitungen usw.)
Schulung des Personals
Aufbereitung/Migration von Daten, Erfassung von Daten
Installation der Software / der Hardware
Bereitstellung einer Hotline
Eigentliche Umstellung
 Ergebnis
- Das System ist bereit für den "Normalbetrieb"
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
43
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Betrieb
 Betriebsphase
 ist die längste aller Phasen
 verursacht oft sehr hohe Kosten
Frage: Was meinen Sie? Wie lang? Wie viel % der Kosten?
 ca. 80% der Kosten aller Phasen
 d.h. es rentiert sich Aufwand zu investieren für die Erstellung
- übersichtlich entworfener und
- gut getesteter Programme
- mit guter Dokumentation
 Ergebnis
- Fehler und Unzulänglichkeiten am Produkt werden hier bereinigt.
- SW wird an geänderte Einsatzzwecke und betriebliche Abläufe angepasst.
- Oft ist das Zurückgehen über mehrere Phasen hinweg notwendig.
Auch wenn diese Phase einen Entwickler wenig interessiert – viele der Aktivitäten im
Software Engineering sind nur durch die Aufgaben in der Betriebsphase zu begründen!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
44
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Der Software Lebenszyklus (Software Life Cycle)
Analyse
Einführung,
Betrieb
Abnahme
IntegrationsTest
Definition
Architektur
Integration
KomponentenTest
Design
Implementierung
 Die Detaillierung der einzelnen Phasen hängt vom Bedarf ab:
 Zusammenlegung „uninteressanter“ Phasen
 Verfeinerung „interessanter“ Phasen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
45
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Phasenmodelle
 Durch den Einsatz von Phasenmodellen wird ein Softwareprojekt zeitlich
strukturiert. Es wird festgelegt:






Welche Arbeiten sind in welchen Phasen zu erledigen?
Welche Arbeitsergebnisse müssen in den Phasen erzeugt werden?
Welche Personen haben die Ergebnisse zu erarbeiten?
Wie sollen die Ergebnisse dokumentiert werden?
Welche Termine müssen eingehalten werden?
Welche Standards und Richtlinien sind einzuhalten?
 Phasenmodelle regeln auch die Zusammenarbeit zwischen den am
Softwareerstellungsprozess Beteiligten.
 Es existieren verschiedene Phasenmodelle für die Softwareentwicklung.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
46
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Wasserfallmodell
Anforderungsdefinition
Grobentwurf
Feinentwurf
Implementierung
Test u. Abnahme
Einführung, Betrieb
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
47
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Wasserfallmodell -> V-Modell (ursprüngliche Version)
Anwendungsszenarien
Anforderungsdefinition
Testfälle
Grobentwurf
Feinentwurf
Modul-Implementierung
Testfälle
Testfälle
(Einführung, Betrieb)
Abnahmetest
Systemtest
Integrationstest
Modultest
Weitere Modelle
im Kapitel 11:
Vorgehens- und
Prozessmodelle
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
48
2.2 Grundlagen des Software Engineering: Phasen der Softwareentwicklung
Ergebnisse der Phasen
 Als Ergebnis jeder Phase entstehen Dokumente,
 die als Grundlage für das Weiterarbeiten dienen.
 Fehler in frühen Phasen verursachen (sehr) hohe Kosten in späteren Phasen
z.B.: Auswirkungen von Fehlern oder missverständlichen Formulierungen in der
Spezifikation, die erst zum Zeitpunkt der Abnahme festgestellt werden
- alle Phasen müssen noch mal durchlaufen werden,
- man muss sich in den Aufbau des Programms hineindenken und Änderungen im Code
vornehmen
- System ist neu zu testen (Komponenten- und Integrationstest des gesamten Systems)
- Dokumentation ist anzupassen
 Qualitätssichernde Maßnahmen (z.B. Reviews und Codeinspektionen)
 prüfen die Phasen-Ergebnisse
 und evtl. auch innerhalb der Phasen - an so genannten Meilensteinen anfallende Zwischenergebnisse
Eine ausführliche Betrachtung von Phasenmodellen (auch mit mehreren
Zyklen) kommt später!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
49
2. Grundlagen des Software Engineering
Kontrollfragen








Gehören Dokumentation und Skizzen auch zur Software?
Was war die Software-Krise?
Was ist strukturierte Programmierung
Was ist schrittweise Verfeinerung
Was ist Qualität von Software?
Was ist das "magische Dreieck"?
Was passiert in der Phase "Betrieb"?
Diskussion: Warum verkauft sich Software mit Fehlern trotzdem?
Jetzt ahnen Sie, warum in großen Projekten anders gearbeitet
wird, als in kleinen Projekten!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
50
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
3. Anforderungsanalyse
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
51
3. Anforderungsanalyse
Häufige Mängel in Software-Projekten… sind vermeidbar
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
52
3. Anforderungsanalyse
Phasenmodell: Zur Erinnerung - V-Modell
Anwendungsszenarien
Anforderungsdefinition
Testfälle
Grobentwurf
Feinentwurf
Modul-Implementierung
Testfälle
Testfälle
Abnahmetest
Systemtest
Integrationstest
Modultest
Diese Phasen kommen
auch in anderen
Phasenmodellen vor...
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
53
3. Anforderungsanalyse
Lernziel Anforderungsanalyse
 Sie sollen in diesem Kapitel verstehen,





Was in der Anforderungsanalyse gemacht wird
Warum die Anforderungsanalyse so schwierig ist
Woher die Kommunikationsprobleme in der Anforderungsanalyse kommen
Welche Arten von Anforderungen es gibt
Welche Dokumente zu einer Anforderungs-Spezifikation gehören
Anschließend können Sie ein System so spezifizieren,
dass es beauftragt oder entwickelt werden könnte
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
54
3. Anforderungsanalyse
Typischer Beginn eines Projekts I
 Auftragnehmer (SW-Firma)
 Auftraggeber
 hat ein Problem und sucht eine
Lösung
 kennt sich oft nicht mit SW aus
 Formuliert (evtl.) die
Randbedingungen
 hat ein gewisses Budget
 Formuliert den Bedarf
 hat eine eigene Sprache
 hat eigene Prozesse
Lastenheft
 soll einen Lösungskonzept erstellen
 hat ein bestimmtes Fachwissen in
SW
 kennt die Randbedingungen nicht
 soll ein Angebot machen
 kennt sich mit der Anw.domäne nicht
aus
 hat eine eigene Sprache
 hat eigene Prozesse
Pflichtenheft
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
55
3. Anforderungsanalyse
Typischer Beginn eines Projekts II
 Ziele
 Abgestimmte Beschreibung des Lieferumfangs
- aber nur mit eingeschränktem Aufwand !
- angestrebter Detaillierungsgrad ist definiert im Vorgehensmodell
 Vertragsinhalte festlegen
- Funktionalität, Bezahlung, Termine, Abnahme, Strafen,…
- Iteration des Pflichtenhefts (und evtl. Lastenhefts)
- Erarbeiten eines gemeinsamen Verständnisses
Lastenheft
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
Pflichten
heft
56
3. Anforderungsanalyse
Inhalt eines Lastenhefts (Idealergebnis)
I.
Titel
Systemname, Datum, Autor
Zielbestimmung und Zielgruppen
Ausgangssituation, grundsätzl. Zielsetzung
I.a. Produktperspektive
I.b. Einsatzkontext
II.
Funktionale Anforderungen
II.a. Produktfunktionen
II.b. Produktschnittstellen
II.c. Anwenderprofile
III. Nichtfunktionale Anforderungen
III.a. Qualitätsanforderungen
III.b. Technische Anforderungen
IV. Lieferumfang
V. Abnahmekriterien
Anhänge
Erwartete Verbesserung
Einsatzmöglichkeiten
Welche Leistung liefert das Produkt?
Funktionalität
Schnittstellen zu anderen Systemen
potenzielle Benutzer
Wie (gut) wird die Leistung erbracht?
siehe nächste Folie
Einsatzumgebung
Dokumente, Systeme, Code, Wartung
Minimalkriterien für die Akzeptanz
Sonstiges
Quelle: M. Winter "Methodische objektorientierte Softwareentwicklung"
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
57
3. Anforderungsanalyse
Zur Erinnerung: Softwarequalitätseigenschaften
Die müssen
erarbeitet werden!
Funktionserfüllung
Qualitätsmerkmale aus
Benutzersicht
Qualitätsmerkmale aus
Entwicklersicht
Effizienz
HW-Effizienz
Zuverlässigkeit
SW-Effizienz (Performance)
Benutzbarkeit
Robustheit
Sicherheit
Fehlertoleranz
Erweiterbarkeit
Änderbarkeit
Wartbarkeit
Verständlichkeit
Übertragbarkeit
Testbarkeit
Wiederverwendbarkeit
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
58
3. Anforderungsanalyse
Versteckte Anforderungen
 Nur wenige Menschen werden Ihnen sofort Anforderungen nennen
 Oft erhalten Sie Lösungsvorschläge
 es gibt meist viele versteckte Anforderungen
- Ihre Aufgabe ist es, diese Anforderungen herauszufinden!
- Es gibt oft versteckte Hinweise auf Anforderungen in Dokumenten und Präsentationen…
schauen bzw. hören Sie genau hin!
Information
Hinweis z.B. auf
Einsatzort des Systems
Wartungsart: Remote oder vor Ort
Vertriebsweg und Markt
Art der Installation
Benutzungsfrequenz
Performanz, Hardware-Auslegung
Folgen bei Ausfall
Robustheit, Sicherheit
Anwenderprofil
Internationalisierung, Bedienbarkeit
Geschäftsplanung
Erweiterbarkeit
Probleme
kritische Anforderungen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
59
3. Anforderungsanalyse
Übung CocktailPro (I): Firmenpräsentation Cocktail4U
Dieses System werden
Sie im Praktikum
entwickeln!
 Cocktail4U GmbH
 5 Mitarbeiter
 100% Tochter der DfF GmbH (Dosierer für Fertigungsstraßen)
- automatisierte Dosierer, Waagen, Mischer uvm.
- Einsatz in Brauereien, Konditoreien, Lebensmittelverpackung
 Geschäftsidee Cocktail4U: CocktailPro
 Wandgerät für Kneipen und Bars
 hochwertige Cocktails auf Knopfdruck
 Situation:
 DfF hat die Dosierer, Waage, etc.
 es fehlt nur noch die Steuer- und Kontrolleinheit
 Cocktail4U beauftragt die Entwicklung ... bei IHNEN!?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
60
3. Anforderungsanalyse
Übung CocktailPro (II): Lastenheft
CocktailPro, Cocktail4U GmbH
I.
Zielbestimmung und Zielgruppen
I.a. Produktperspektive:
I.b. Einsatzkontext:
II.
Standardausstattung in der Gastronomie
Cocktailbar, Restaurant, Kneipe
Funktionale Anforderungen
II.a. Produktfunktionen:
II.b. Produktschnittstellen:
II.c. Anwenderprofile:
Cocktail auf Knopfdruck
Wasser, Strom, Dosierer
Wirte; geringe Ausbildung
III. Nichtfunktionale Anforderungen
III.a. Qualitätsanforderungen:
III.b. Techn. Anforderungen:
IV. Lieferumfang:
V. Abnahmekriterien:
Anhänge:
einfaches GUI (Knopf = Cocktail),
1 Cocktail in 30 Sek
Innenraum, Wandmontage
Gesamtsystem, Code, Wartung
50 Cocktails ohne Störung
Systemskizze, Beschreibung von
Dosierer, etc.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
61
3. Anforderungsanalyse
Übung: CocktailPro (III): Systemüberblick aus Sicht des Auftraggebers
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
62
3. Anforderungsanalyse
Übung: CocktailPro (IV): Offene Punkte
Im Praktikum dokumentieren
Sie die funktionalen
Anforderungen als Use Cases!
 Obwohl das Lastenheft alle Punkte anspricht, fehlen noch viele Infos!
 Unklar ist zum Beispiel:













Wer liefert den Rechner, das Gehäuse?
Woher kommen die Rezepte?
Wie werden (neue) Rezepte eingespielt? (Remote? vor Ort? Schnittstelle?)
Wie viele Rezepte werden angeboten? (Das GUI Konzept verlangt je 1 Knopf)
GUI (Sprachen, Internationalisierung, Sonderzeichen, Auflösung, Farbe)
Was passiert bei einer Störung? (Fernwartung oder Führung durch System)
Wer zahlt bei Störungen in zugelieferten Teilen?
Wie viele Zutaten können gemischt werden (# Dosierer)?
Was wird gewartet? Ausgelieferte Systeme oder nur die Software? Rezepte?
Gesetzliche Auflagen (z.B. Hygiene, Reinigungskonzept)
Aussagen zu nicht-funktionalen Anforderungen (z.B. Erweiterbarkeit)
Auflagen für Programmiersprache, Betriebssystem
…
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
63
3. Anforderungsanalyse
Erstellung eines Pflichtenhefts (I)
 Annahme:
Es liegt ein "gutes" Lastenheft vor
 Was fehlt noch?




Details ...
gemeinsame Sprache
gemeinsames Verständnis der Funktion
gemeinsames Verständnis der Randbedingungen
gemeinsame Vorstellung über das Zielsystem
 Glossar
 Funkt. Anf.
 n.-funkt. Anf.
 GUI
 Wie kommt man dahin?
Extrahieren
Validieren und Verifizieren
nach K. Pohl "ProcessCentered Requiremens
Engineering", 1996
Spezifizieren
Verhandeln
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
64
3. Anforderungsanalyse
Erstellung eines Pflichtenhefts (II)
Extrahieren
Spezifizieren
Validieren und Verifizieren
Verhandeln
 Extrahieren (Extraction / Elicitation)
 Kennenlernen der Anwendungsdomäne, Aufnahme Istablauf
 Gemeinsames Brainstorming, Diskussionen, Anwenderbefragungen, Dokumenten- und
Literaturstudium
 Schwachstellen, Verbesserungsvorschläge, Wünsche, verborgene Anforderungen finden
 Lösungsalternativen finden und auswählen
 Spezifizieren (Specification)
 Thema verständlich und kommunizierbar machen, dokumentieren
 Validieren
 Werden Erwartungen der Benutzer / Auftraggeber wirklich erfüllt?
 Diskussionen von Auftragnehmer & Auftraggeber
 Verifizieren
 Konsistenz der Einzelspezifikationen prüfen, Technische Überprüfung z.B. durch
Spezialisten, Test-Team
 Verhandeln (Negotiation)
 Einigung auf Reihenfolge, Priorität, Umfang etc. einer Realisierung mit allen Stakeholdern
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
65
3. Anforderungsanalyse
Bestandteile eines Pflichtenhefts
Alle Beschreibungen beziehen
sich auf den Problemraum!
Lösungen im Detail sind hier noch
nicht von Interesse!
 Funktionale Anforderungen
 konkrete Anwendungsfälle und Abläufe (z. B. Use Cases, Story Cards = Text)
 Benutzer, Akteure
Die konkrete Art der
Dokumentation wird mit
 Nicht-funktionale Anforderungen
dem Geschäftspartner
 Systematische Betrachtung der Qualitätseigenschaften
festgelegt!
 Priorisierung der Qualitätseigenschaften
 Benutzungsschnittstelle (GUI=Graphical User Interface / HMI=Human Machin Interface)
 Skizzen und Snapshots, Navigationskonzepte, Dialogführung
 Glossar
 Zentrale Sammlung der Definitionen aller wichtigen Dinge der Problemwelt
 den Auftraggeber nicht mit neuen Begriffen "beglücken"!
 Universalausdrücke vermeiden / genau spezifizieren: (System, Komponente, …)
 Sonstiges
 z.B. Modellierung der Daten des interessierenden Realweltausschnitts (AnalyseKlassendiagr.)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
66
3. Anforderungsanalyse
Tätigkeiten bei der Anforderungsanalyse und Dokumentationsformen
 Definition der Funktionalität
 siehe OOAD: Use Cases, Aktivitätsdiagramme, Zustandsdiagramme
 Definition der nichtfunktionalen Anforderungen
 Qualitätseigenschaften als Text dokumentieren
 Erstellung von HMI-Skizzen und Navigation
 Vorlesung "Entwicklung nutzerorientierter Anwendungen" (ENA)
 Glossar
 Normale alphabetische Definitionsliste (evtl. mit Index)
 Sonstiges
 z.B. Modellierung der Anwendungsdomäne: siehe OOAD: Analyseklassenmodell
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
67
3. Anforderungsanalyse
Anforderungsanalyse - Was ist eigentlich daran so schwer?
 Nette Gesprächsrunden (viel Kaffee, viele Kekse)…
 …gemeinsames Verständnis finden…
 …Aufschreiben der Ergebnisse…
 … und fertig???
 Nicht ganz, denn…
 … in der Regel können nicht alle Anforderungen umgesetzt werden
- Priorisierung, Planung und Verhandlung ist erforderlich
- Ablehnung von Anforderungen ist oft nötig
 … die Anforderungen ändern sich mit der Zeit
- Umgang mit neuen / geänderten Anforderungen
- Konsistenz der Anforderungen erhalten
- Verwaltung der Anforderungen
 Change Request Management
 Requirements Engineering statt Requirements Management
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
68
3. Anforderungsanalyse
Kontrollfragen zur Anforderungsanalyse






Welches Ziel verfolgt die Anforderungsanalyse?
Was wird in der Anforderungsanalyse gemacht?
Warum ist die Anforderungsanalyse so schwierig?
Welche Arten von Anforderungen gibt es?
Welche Dokumente gehören zu einer Anforderungs-Spezifikation?
Welche Methode eignet sich zur Dokumentation von funktionalen
Anforderungen?
 Was geschieht, wenn man ein Projekt ohne aufwändige Anforderungsanalyse
angeht / angehen muss?
Könnten Sie jetzt ein System so spezifizieren,
dass es beauftragt oder entwickelt werden könnte?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
69
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
4. Abnahmetest
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
70
4. Abnahmetest
V-Modell
Anwendungsszenarien
Anforderungsdefinition
Testfälle
Grobentwurf
Feinentwurf
Modul-Implementierung
Testfälle
Testfälle
Abnahmetest
Systemtest
Integrationstest
Modultest
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
71
4. Abnahmetest
Lernziel Abnahmetest
 Sie sollen in diesem Kapitel verstehen,
 Was ein Abnahmetest ist
 Warum ein Abnahmetest wichtig ist
 Wie man Testfälle für die Abnahme findet
Anschließend können Sie ausgehend von einer Spezifikation
die Abnahmetests spezifizieren.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
72
4. Abnahmetest
Was ist ein Abnahmetest und wie führe ich ihn durch
 Was ist ein Abnahmetest?
 Prüfung, ob erstelltes System = spezifiziertes System
 die Abnahmetests sind Bestandteil des Vertrags
 Nach erfolgreicher Abnahme wird bezahlt
 Wie führe ich einen Abnahmetest durch?
 Zusammen mit dem Auftraggeber
 Mit formeller Protokollierung
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
73
4. Abnahmetest
FURPS-Modell
 Was muss getestet werden?





F: Functonality (Funktionalität)
U: Usability (Benutzbarkeit)
R: Reliability (Zuverlässigkeit)
P: Performance (Leistung)
S: Supportability (Wartbarkeit)
...
 Funktionstests
 Überprüfung auf korrekte Funktion des Systems
kommt gleich im Detail !
 Benutzbarkeitstests
 Überprüfung der Bedienoberfläche durch Endanwender
 Intuitive Bedienung, Lesbarkeit, Reaktivität, ...
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
U
74
4. Abnahmetest
Tests: (RPS)
 Zuverlässigkeitstests
 Zuverlässigkeit: Max. Anzahl der Abstürze/Fehlfunktionen in Zeitintervall T
 Beim Funktionstest bekommt man auch Hinweise auf die Zuverlässigkeit
 Eigentlicher Zuverlässigkeitstest erst im Einsatz
R
 Leistungstests
 Überprüfung der Nichtfunktionalen Anforderungen zu
- Performance: Zeitvorgaben,
d. h. Überprüfung der Schnelligkeit durch Überprüfung der Zeitvorgaben
- Robustheit: Belastungs- oder Stresstest,
d. h. Funktionstests auch bei maximaler Last, maximaler Durchsatz, hohem
Datenaufkommen etc.
P
 Wartbarkeitstest
 Überprüfung von Code und Dokumentation auf Verständlichkeit
 z. B. durch Anwendung von Metriken (später in der Vorlesung)
S
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
75
4. Abnahmetest
Tests: Funktionstest im Detail
F
 Woher kennen wir die gewünschte Funktionalität?
 In der Anforderungsanalyse wurden die Funktionalität durch Eingaben und die
darauf erwartete Reaktion des Systems beschrieben
 Annahme: Wir haben Anwendungsfälle beschrieben
 In Anwendungsfällen sind Eingaben ins System und Ausgaben vom System
dokumentiert
 Beim Abnahmetest werden die einzelnen Anwendungsfälle ein- oder mehrmals
durchgespielt
 Um nachzuprüfen, ob die - vom Anwendungsfall beschriebene - Funktionalität
wie erwartet abläuft
Wie extrahiert man die Testfälle und die
dazugehörenden Daten aus Anwendungsfällen?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
76
4. Abnahmetest
Ableiten von Funktionstests (I) aus Use Cases
Trigger
Basic
Course
Alternate
Course
Login-System fragt Kunden nach PIN
Step #
Action
1
System fordert zur PIN-Eingabe auf
2
Kunde gibt PIN ein
Gefährlich!
Wirklich
immer?
3
System validiert PIN
4
System gibt Zugang frei
Step #
Condition
Action(s)
*
Kunde bricht ab
Abbruch
2a
Keine Eingabe für 30 Sek.
Abbruch
3a
PIN stimmt nicht und Versuche <3
Goto 1
3b
PIN stimmt nicht und Versuche>=3
Abbruch
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
77
4. Abnahmetest
Ableiten von Funktionstests (II): Essentielle Aktivitäten ohne Fehler- und
Ausnahmesituationen
Zur Anschauung:
Darstellung als
Aktivitätendiagramm
Aufforderung PIN-Eingabe
Kundenreaktion
PIN-Validierung
System gibt Zugang frei
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
78
4. Abnahmetest
Beispiel: Ableiten von Funktionstests (III): Aktivitäten mit Ausnahmen
Aufforderung PIN-Eingabe
Kundenreaktion
keine Eingabe für 30 Sek.
Kunde bricht ab
PIN-Eingabe erfolgt
PIN falsch und
< 3 Fehlversuche
PIN-Validierung
PIN als richtig
validiert
System gibt Zugang frei
PIN falsch und
>= 3 Fehlversuche
Abbruch
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
79
4. Abnahmetest
Ableiten von Funktionstests (IV)
 Man kann das System nicht mit allen möglichen Eingabedaten testen.
⇒ man teilt die Menge der Testfälle (der möglichen Eingaben) in Klassen ein, so dass
man sagen kann:
□ Falls ein Testfall aus der Menge der Testfälle der Klasse richtig abläuft, so laufen auch die
anderen mit großer Wahrscheinlichkeit richtig ab.
,
: mögliche Testfälle
: ausgewählter Testfall
 Testplan besteht aus der Menge der ausgewählten Testfälle. ( )
 Für jeden Testfall sind alle Eingabewerte (Bildschirmeingaben, Zustände des
Systems) und Ausgabewerte (Bildschirmausgaben, Zustände des Systems)
spezifiziert.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
80
4. Abnahmetest
Ableiten von Funktionstests (IV) - Zweigtesten
Frage: Wie teile ich in Äquivalenzklassen ein?
Welche Eingabedaten wählen Sie für die Testfälle?
 3 Arten der Einteilung in Klassen:
Testfälle so auswählen, dass folgendes gilt:
 Aktivitätentest (Aktivitätenüberdeckung)
 Jeder Kasten des Aktivitätsdiagramms wird 1 Mal durchlaufen
 So viel Durchläufe, dass jeder Kasten mind. 1 Mal durchlaufen wird
Frage: wie oft muss ich den obigen Use-Case durchlaufen?
 Zweigtesten
 Jeder der Zweige des Aktivitätendiagramms wird mindestens ein Mal durchlaufen,
 d. h. jeder Pfeil im Aktivitätsdiagramm wird mindestens ein Mal durchlaufen.
 Jeder Durchlauf ist ein Testfall
Frage: wie oft muss ich den obigen Use-Case durchlaufen?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
81
4. Abnahmetest
Beispiel: Ableiten von Funktionstests (V): Aktivitatsdiagramm = Zweiggraph
Aufforderung PIN-Eingabe
Kundenreaktion
keine Eingabe für 30 Sek.
Kunde bricht ab
PIN-Eingabe erfolgt
PIN falsch und
< 3 Fehlversuche
PIN-Validierung
PIN als richtig
validiert
System gibt Zugang frei
PIN falsch und
>= 3 Fehlversuche
Abbruch
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
82
4. Abnahmetest
Ableiten von Funktionstests (VI) - Zweigtesten
Eingabe
keine Eingabe für 30 Sek.
Abbruch-Taste gedrückt
richtige PIN eingegeben
Soll-Zwischenergebnisse
Soll-Ergebnis
Abbruch
Abbruch
Zugang frei
3x falsche PIN eingegeben
2 Mal Aufforderung der erneuten PIN-Eingabe
Abbruch
Frage: Ist dies ein Testplan?
Wie würde ein Testplan aussehen?
Dies ist die Spezifikation
der Äquivalenzklassen!
Testplan:
Vorzustand
Eingabe
keine Eingabe für 30 Sek.
Gültige PIN zu Kunden ist 4711
Gültige PIN zu Kunden ist 4711
Abbruch-Taste gedrückt
richtige PIN 4711 eingegeben
PIN 1234, 2436, 7777
eingegeben
Soll-Zwischenergebnisse
Soll-Ergebnis
Abbruch
Ist-Erg.
Abbruch
Zugang frei
2 Mal Aufforderung der
erneuten PIN-Eingabe
Abbruch
konkrete Werte!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
83
4. Abnahmetest
Ableiten von Funktionstests (VII) - Pfadtesten
 Jedes mögliche Szenario wird mindestens einmal getestet
 d. h. jeder mögliche Pfad in den zu den Use-Cases gehörenden
Aktivitätsdiagrammen wird mindestens ein Mal durchlaufen.
 Anzahl der Wege wird schnell zu groß ( Auswahl wichtiger Tests)
Frage: Was ist der Unterschied zwischen Zweig und Pfad?
Frage: Wie oft muss ich den obigen Use-Case durchlaufen?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
84
4. Abnahmetest
Beispiel: Ableiten von Funktionstests (VIII): Pfadgraph
Aufforderung PIN-Eingabe
keine Eingabe für 30 Sek.
Kundenreaktion
Kunde bricht ab
PIN-Eingabe erfolgt
PIN-Validierung
PIN als
richtig
validiert
PIN falsch und < 3 Fehlversuche
Aufforderung PIN-Eingabe
keine Eingabe für 30 Sek.
Kundenreaktion
PIN-Eingabe erfolgt
Kunde bricht ab
Ein Pfadgraph stellt alle möglichen Pfade
dar. Er hat keine Rückwärtssprünge.
Ein Szenario ist ein Weg vom Startknoten zu
einem Endknoten.
=> Wenn jeder Pfeil mindestens ein Mal
durchlaufen ist, sind alle Pfade durchlaufen,
d. h. jedes mögliche Szenario ist mindestens
ein Mal durchgespielt.
PIN-Validierung
PIN als
richtig
validiert
PIN falsch und < 3 Fehlversuche
Aufforderung PIN-Eingabe
Kundenreaktion
PIN-Eingabe erfolgt
PIN-Validierung
PIN als richtig validiert
System gibt Zugang frei
Frage: Wie viele Tests hätten wir, wenn
wir PIN unendlich oft eingeben
können und nur durch Abbruch
raus kommen?
keine Eingabe für 30 Sek.
Kunde bricht ab
PIN falsch und
>= 3 Fehlversuche
Abbruch
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
85
4. Abnahmetest
Ableiten von Funktionstests (IX) - Pfadtesten
 Spezifikation der Äquivalenzklassen:
Eingabe
Soll-Zwischenergebnisse / -ausgaben
SollEndergebnis
richtige PIN eingegeben
ein Mal falsche PIN eingegeben,
beim 2. Versuch richtige PIN
zwei Mal falsche PIN eingegeben,
beim 3. Versuch richtige PIN
Zugang frei
1 Mal Aufforderung der erneuten PIN-Eingabe
Zugang frei
2 Mal Aufforderung der erneuten PIN-Eingabe
Zugang frei
drei Mal falsche PIN eingegeben
2 Mal Aufforderung der erneuten PIN-Eingabe
Abbruch
keine Eingabe für 30 Sek. statt 1. PIN-Eingabe
Abbruch
Abbruch statt 1. PIN-Eingabe
Abbruch
keine Eingabe für 30 Sek. statt 2. PIN-Eingabe
1 Mal Aufforderung der erneuten PIN-Eingabe
Abbruch
Abbruch statt 2. PIN-Eingabe
1 Mal Aufforderung der erneuten PIN-Eingabe
Abbruch
keine Eingabe für 30 Sek. statt 3. PIN-Eingabe
2 Mal Aufforderung der erneuten PIN-Eingabe
Abbruch
Abbruch statt 3. PIN-Eingabe
2 Mal Aufforderung der erneuten PIN-Eingabe
Abbruch
Frage: Wie sieht der Testplan aus?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
86
4. Abnahmetest
Ableiten von Funktionstests (X)
 Schwierigkeit bei den obigen Verfahren: Ich habe oft nicht das gesamte System
als Use-Cases, sondern nur einige Scenarien definiert.
=> Ich muss mir überlegen, welche Scenarien ich zu Testzwecken noch
zusätzlich spezifizieren sollte.
 Wie teste ich nun? Aktivitätentesten, Zweigtesten oder Pfadtesten?
- es kommt darauf an, wie ausführlich man bei der Abnahme testen möchte.
-> Testen aller Aktivitäten
-> Testen einiger Zweige
-> vollständiger Zweigtest
-> Zweigtesten + einige Pfade aus dem Pfadgraphen oder
-> vollkommener Pfadtest - falls überhaupt möglich
(Wenn man z. B. die PIN-Eingabe beliebig oft wiederholen darf,
=> Pfadgraph ist unendlich groß => vollkommener Pfadtest nicht möglich)
-> ungültige Äquivalenzklassen (Eingabe „A“) – Hier darf das System auch nicht
abstürzen (Fehlertoleranz!)
-> zusätzlich intuitive Testfälle (Eingabe 0 oder Blank),
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
87
4. Abnahmetest
Kontrollfragen zum Abnahmetest








Welches Ziel haben Abnahmetests?
Wann werden Abnahmetests festgelegt?
Wie finden Sie Tests für funktionale Anforderungen?
Kann es unendlich viele Testpfade geben?
Was tun Sie, wenn es zu viele Testpfade gibt?
Wie testen Sie nicht-funktionale Anforderungen?
Welche Bedeutung hat der Abnahmetest im vertraglichen Sinn?
Wie hängt der Abnahmetest mit den Anforderungen zusammen?
Können Sie jetzt ausgehend von einer Spezifikation
Abnahmetests spezifizieren?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
88
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
5. Software-Architektur (Grob-Design)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
89
5. Software-Architektur
Einordnung im V-Modell
Anwendungsszenarien
Anforderungsdefinition
Grobentwurf
(SW-Architektur)
Feinentwurf
(Design)
Modul-Implementierung
Testfälle
Testfälle
Testfälle
Abnahmetest
Systemtest
Integrationstest
Modultest
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
90
5. Software-Architektur
Architektur einer Brücke
Quelle: R. Hahn
Diese "Brücke"
•
kann von einer Person
realisiert werden
•
Einfacher Bauplan
•
Einfache Arbeitsschritte
•
Einfache Werkzeuge
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
91
5. Software-Architektur
Architektur einer großen Brücke
“... every large software
project is similar to the
first attempt to build a
flying-buttress construction
cathedral.”
(Richard P. Gabriel)
Quelle: Wikipedia, GFDL
Die Funktion der großen HängeBrücke ist im Prinzip gleich,
aber diese Brücke
• wird von vielen spezialisierten
Personen(gruppen) realisiert
• in mehrjähriger Bauzeit
• komplizierte Baupläne
• aufwändige Arbeitsschritte
• viele spezielle Werkzeuge
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
92
5. Software-Architektur
Bau einer großen Brücke
 Es gibt mehrere professionelle Architekten
 möglichst mit Erfahrungen mit ähnlichen Bauvorhaben,
 die den Bau leiten und die Arbeiten koordinieren
 Es werden diverse Pläne erstellt,
die die Brücke bzgl. verschiedener Aspekte zeigen




Technische Zeichnungen zu Stahlkonstruktion
Fundamentpläne
Statikpläne mit Kräftevektoren
Seilaufbaupläne
 Die Arbeiten müssen in Arbeitspakete zerlegt werden.
 Die Realisierung erfolgt später durch mehrere (spezialisierte) Teams
... und für
Software-Projekte???
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
93
5. Software-Architektur
Software-Projekt: Fahrerinformationssystem
Quelle: www.blaupunkt.com
 Umfang:
 Bereitstellung neuer Funktionalität (Spracheingabe, …)
 Neuentwicklung großer Teile (User Interface komplett)
 Auslieferung von Zwischenständen
 Team: ca. 50 SW Entwickler + Management + Querschnitt
 Dauer: 2-3 Jahre
 Budget: ca. 30 Mio. €
 Architektur
Frage: Wie gehe ich solch ein Projekt an?
für Software
ist notwendig!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
94
5. Software-Architektur
Situation im Projekt




Es ist (mehr oder weniger) verstanden, was der Auftraggeber will
Es ist ein großes Projekt
Nun geht es an die Umsetzung in Software
aber wie gehe ich in einem großen Projekt vor?
Idee: Erstelle eine grobe Skizze des Systems!





noch keine Details (Implementierung, Programmiersprache, Technik, …)
Aufteilung in Teile (Pakete / Komponenten)
Beschreiben der Verantwortlichkeiten der Pakete / Komponenten
Beschreiben der Kommunikation der Pakete / Komponenten
erste Evaluation der Funktionalität möglich
 "Software-Architektur"
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
95
5. Software-Architektur
Definition
Die Software-Architektur eines
Rechnersystems beschreibt die Struktur
der Software des Systems, die aus
Komponenten, deren extern sichtbaren
Eigenschaften und Verantwortlichkeiten
Dilbert:
... Its a bunch of shapes
connected by lines...
und deren Beziehungen besteht
(Len Bass et. al.)
Eine von vielen Definitionen…
siehe auch:
http://www.sei.cmu.edu/architecture/definitions.html
Es kommt darauf an, die der Aufgabenstellung angemessenen
Komponenten und Beziehungen zu finden!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
96
5. Software-Architektur
Lernziel Software-Architektur
 Sie sollen in diesem Kapitel verstehen,








warum eine Software-Architektur für ein großes Projekt wichtig ist
was eine Software-Architektur ist
dass es viele Architekturen zu einer Aufgabe gibt
dass die verwendeten Techniken der SW-Architektur von der Anwendung abhängen
dass die Qualitätsanforderungen entscheidend für die Architektur sind
dass es bekannte Architekturstile mit bekannten Qualitätseigenschaften gibt
dass es schwierig ist, eine gute Architektur zu entwickeln
wie man eine Architektur darstellt
Anschließend verstehen Sie die Bedeutung einer SW-Architektur und
ahnen, wie man eine SW-Architektur erstellt !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
97
5. Software-Architektur
Literatur
Len Bass et.al.:
Software Architecture in Practice;
Addison-Wesley; 2003
Paul Clements et.al.:
Documenting Software Architectures;
Addison-Wesley; 2002
Johannes Siedersleben:
Moderne Software-Architektur;
dpunkt; 2004
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
98
5. Software-Architektur
Literatur
Ralf Reussner, Wilhelm Hasselbring:
Handbuch der Software-Architektur,
dpunkt.verlag, 2006
[Douglass06]
Bruce Powel Douglass:
Real Time UML Third Edition,
Addison Wesley, 2006
[Kruchten95]
Philippe Kruchten:
Architectural Blueprints – The “4+1!
View Model of Software Architecture,
in IEEE Software 12 (6) November
1995, pp. 42-50
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
99
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
5.1 Architekturstile
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
100
5.1 Architekturstile
Auf der Suche nach dem Architekturstil (=Architekturmuster) für ein
Programm(-system) - Beispiel "KWIC"
 Aufgabe
 Wie sieht eine Architektur für folgendes (einfache) System aus?
The KWIC (KeyWord in Context) index system accepts an ordered set of lines;
each line is an ordered set of words, and each word is an ordered set of
characters. Any line may be ›circulary shifted‹ by repeatedly removing the first
word and appending it at the end of the line. The KWIC index system outputs a
listing of all circular shifts of all lines in alphabetical order.
“On the Criteria for Decomposing Systems into Modules”, David Parnas. CACM, 1972
 Anwendung: z.B. Index im Unix Manual oder auch in Bibliotheken
 Suche nach Stichwörtern
siehe auch: "Software Architecture: Perspectives on an Emerging Discipline"
Mary Shaw and David Garlan, Prentice Hall, 1996.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
101
5.1 Entwicklung einer SW-Architektur
Funktionalität von "KWIC"
 Eingabe
 Perspectives on Software Architecture
 Computers in Context
 Zwischenergebnis (zyklische Shifts)
Perspectives on Software Architecture
on Software Architecture Perspectives
Software Architecture Perspectives on
Architecture Perspectives on Software
Computers in Context
in Context Computers
Context Computers in
KeyWord in Context:
Jede Eingabezeile wird wortweise
zyklisch geshifted und dann die
Ergebniszeilen sortiert
 Ausgabe (sortiert)
Architecture Perspectives on Software
Computers in Context
Context Computers in
in Context Computers
on Software Architecture Perspectives
Perspectives on Software Architecture
Software Architecture Perspectives on
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
102
5.1 Architekturstile
KWIC: Prozeduraler Stil
Direct Memory Access
Subprogram Call
System IO
Input




Master Control
Circular Shift
Characters
Input
Medium
"Subroutine with shared data"
Index
Alphabetizer
Output
Alphabetized
Index
Output
Medium
Zerlegung in vier Basisfunktionen
Koordination durch ein Hauptprogramm, das sie sukzessive aufruft
Daten werden als gemeinsame Ressource von den Modulen verwendet
Keine Kapselung der Daten
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
103
5.1 Architekturstile
KWIC: Objektorientierter Stil (zentral gesteuert)
Subprogram Call
System IO
"Abstract Data Types"
Master Control
Input
Output
i-th
Circular Shift
alphsort
getline
getword
char
Input
Medium
shift
getword
getchar
setchar
Characters
Alphabetic
Shifts
Output
Medium
 Kontrollfluss durch zentrale Koordination
 Datenkapselung
 Algorithmen und Datenrepräsentation der einzelnen Klassen können geändert
werden, ohne die anderen zu beeinflussen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
104
5.1 Architekturstile
KWIC: Eventgesteuerter Stil
Implicit Invocation
Subprogram Call
System IO
Input
Alphabetizer
Output
i-th
delete
insert
Lines
i-th
delete




Circular Shift
insert
Input
Medium
"Implicit Invocation"
IO Control
Lines
Output
Medium
Keine zentrale Steuerung
Veränderung der Daten löst Events aus
Events führen zu Aktionen, die ihrerseits Events erzeugen
Modell „aktiver Daten“
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
105
5.1 Architekturstile
KWIC: Pipes & Filters als Stil
Input
Medium
Input
Circular
Shift
Pipe
System IO
Alphabetizer
Output
"Pipes and Filters"
Output
Medium
 Verteilte Steuerung: jeder Filter arbeitet, sobald Daten an seiner Eingabe
anliegen
 Die Daten existieren nur temporär als I/O zwischen den Filtern
 Die Filter sind voneinander unabhängig, sie kommunizieren nur über die Pipes
zwischen ihnen
 Datenfluss und Kontrollfluss fallen zusammen
Frage: Ist Compiler durch Pipes & Filters realisiert?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
106
5.1 Architekturstile
Architekturstil Pipes and Filters: Beispiel Compiler
ASCII Programmtext
Lexikalische Analyse / Scanner
Token Strom
Syntaxanalyse Parser
Abstrakter Syntaxbaum
Semantische Analyse
Attributierter abstrakter Syntaxbaum
Zwischencode Generierung
Zwischencode
Optimierung
Optimierter Zwischencode
Mips
Intel
Sparc
Interpreter
Programm
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
107
5.1 Architekturstile
Architekturstil 4-Schichten (Layers): Typischer Einsatz
Externe Schnittstelle
Anwendungslogik
Anwendungsdaten
Persistente
Datenhaltung
Mit Hilfe des LayersStils lassen sich
Anwendungen
strukturieren, die in
Gruppen von
Teilaufgaben zerlegbar
sind und in denen
diese Gruppen auf
verschiedenen
Abstraktionsebenen
liegen
User Interface
Applikation
Betriebssystem
Treiber
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
108
5.1 Architekturstile
Zuordnung der 4-Schichtenarchitektur zu Klassen-Stereotypen
Stereotypname
Externe Schnittstelle
Schnittstellenklasse
<<boundary>>
Anwendungslogik
Kontrollklasse
<<control>>
Anwendungsdaten
Entitätsklassen
<<entity>>
Symbol
Persistente
Datenhaltung
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
109
5.1 Architekturstile
Beispiel: Aufruf von Funktionen in einer 4-Schichten-Software-Architektur
Schicht 1: Externen Schnittstelle
A
B
Schicht 2: Anwendungslogik
D
E
Schicht 3: Anwendungsdaten
F
G
Schicht 4: Persistente Datenobjekte
H
I
C
J
Objekte mit Funktionen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
110
5.1 Architekturstile
Was sind Schnittstellenklassen?
 Schnittstellenklassen sind zuständig für die Interaktion des System mit seiner
Umgebung wie
 Benutzer
 anderen Systemen, die das entwickelte System benutzen
 Die Interaktionen beinhalten in der Regel
 die Auswahl und Aktivierung bestimmter (Anwendungs-)Funktionen sowie
 die Ein- und Ausgabe von Daten
 Weitere Aufgaben:




Umsetzung der Interaktionen der Akteure in anwedungsinterne Ereignisse
Prüfung von Eingabedaten
Umsetzung von Eingabedaten in eine für Akteure verwertbare Form
Ausgabe von Daten
 Wir können aus Use-Cases Schnittstellenklassen ableiten
 diese sind zuständig für die in dem Use-Case spezifizierte Kommunikation mit dem
Akteuren.
 Klassenname: Use-Case-Name mit angehängten AF [Wi05] oder UC:
GeldAbhebenUC
 Oft haben Use-Cases auch Kontrollfunktion. In [Wi05]:
 Schnittstellenklassen sind oft versteckt in GUI-Frameworks
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
111
5.1 Architekturstile
Was sind Kontrollklassen?
 Kontrollklassen beinhalten die anwendungsfallbezogene (meistens mehrere
Instanzen von Entitätsklassen betreffende) fachliche Logik.
 Sie steuern die Abläufe
 Sind Vermittler zwischen Schnittstellen- und Entitätsklassen und kontrollieren, ob
die von der Schnittstellenklasse angenommenen Eingaben und Modifikationen
der Akteure auf den Entitätsklassen ausgeführt werden dürfen
 (Falls Anwendungslogik trivial: Auch direkte Kommunikation zwischen
Schnittstellen- und Entitätsklassen. – In Schnittstellenklassen ist dann evtl.
anwendungsfallbezogene fachliche Logik integriert)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
112
5.1 Architekturstile
Was sind Entitätsklassen?
 Enthalten Daten.
 Enthalten die fachliche Logik, die die einzelnen Instanzen der Entitätsklasse
betreffen. (Die fachliche Logik, die nur eine Instanz einer Entitätsklasse betrifft,
sollte nicht in Kontrollklassen untergebracht sein – vor allem nicht in einer
großen Kontrollklasse, die die gesamte Anwendungslogik enthält! = Blob)
 Jede Entitätsklasse ist dafür verantwortlich, dass ihre Instanzen nur die gemäß
Geschäftsregeln erlaubten Zustände annehmen (Setter, Getter).
 u. a. werden oft die in der Phase Anforderungsermittlung ermittelten Domain- /
Analyseklassen in Entitätsklassen überführt.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
113
5.1 Architekturstile
Persistente Datenhaltung
 Diese Schicht enthält die persistent gespeicherten Daten.
 Entweder
 werden Instanzen von als persistent gekennzeichnete Klassen gespeichert
(OODBMS)
oder
 die Daten werden in z. B. relationalen DBMS abgelegt.
(Mit Umsetzungsschicht, die für die Transformation der Klassensicht in relationale
Sicht und umgekehrt zuständig ist. Z. B. Hibernate)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
114
5.1 Entwicklung einer SW-Architektur
Welchen Architekturstil wende ich für meine Aufgabe an?
 Der "richtige" Architekturstil
 ist abhängig von der Anwendung / Teilanwendung / Hardware
z. B. bei KWIC: Passen Daten in Hauptspeicher
 es können auch mehrere Stile kombiniert werden
z. B. ereignisgesteuert, objektorientiert und 4-Schichten
 ist abhängig von den Anforderungen
- Änderungsfreundlichkeit bezüglich Datenstruktur, Funktionalität,
- Performance (Platz, Laufzeit), ...
 Jeder Architekturstil hat Vorteile und Nachteile
 die resultierende Implementierung ist stark verschieden
 Die bekannten Eigenschaften eines
Architekturstils helfen bei der Auswahl !
Software Engineering, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, WS 2013, h_da, Fachbereich Informatik
115
5.1 Entwicklung einer SW-Architektur
Vorgehen beim Grobentwurf (Finden der richtigen Architektur)
Idee: Entwerfen und Analysieren!
 Durch Entwerfen von Komponenten, Beziehungen und
Verantwortlichkeiten (z.B. OOAD: Komponentendiagramme)
 iteratives Analysieren der Anforderungen mit Szenarien
("Welche Änderungen werden erwartet? Sind wahrscheinlich?)
vgl. OOAD: Sequenzdiagramme, Kommunikationsdiagramme auf
Klasseninstanz-Ebene
 Erleichterung durch (Wieder-)Verwendung von bewährten "Mustern"
mit bekannten Eigenschaften ("Architektur-Stile")
 Erfahrung hilft dabei sehr !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
116
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
5.2 Darstellung der SW-Architektur
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
117
5.2 Darstellung der Architektur
Darstellung der Architektur
Was macht ein Architekt?
Viele Pläne!
Elektro
Endkunde
Bauarbeiter
Sanitär
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
118
5.2 Darstellung der Architektur
Sichten der Software-Architektur
 Beim Hausbau gibt es viele verschieden Pläne ("Sichten")




Raumaufteilung (Grund- und Seitenriss)
Elektroinstallation und Datennetz
Sanitäre Installation
…
 Bei der Software gibt es ebenfalls verschiedene Sichten









Logische Zerlegung
Verteilung auf Zielsysteme
Quelldateien
Prozesse / Threads
…
komplexe Systeme werden in mehreren Sichten ("Views") dargestellt
Im konkreten Fall wählt man die "passenden" Sichten
Das Wesentliche der Architektur lässt sich in der Regel nicht in einer einzigen
Sicht darstellen
Es gibt von unterschiedlichen Autoren viele verschiedene Einteilungen in Views
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
119
5.2 Darstellung der Architektur
Logische and Physikalische Architektur
nach [Douglasss04]: Real Time UML, Addison Wesley, 2004
Physical
Architecture:
Logical
Architecture:
Organisiert Dokumente zum System
(Jedes Dokument taucht nur 1 Mal auf)
Stellt das Zusammenspiel der
Systemteile zur Laufzeit dar,
wie Subsysteme, Komponenten
und Tasks
Folgende Namen hat diese Sicht in der Literatur:
Folgende Namen haben diese Sichten in der Literatur:
• Paket-Sicht / Domänen Sicht / Logische Architektur
• Subsystem- und Komponenten-Sicht / Logische Sicht
• Prozess-Sicht / Thread-Level / Concurrency and Resource View
• Einsatz-/ Deployment-/ Physische Sicht (HW-Komponenten)
• Implementations- / Dateien-Sicht
• Anwendungs-Sicht (nach [Kruchten95])
• ....
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
120
5.2 Darstellung der Architektur
Paket-Sicht / Domänen Sicht / Logische Architektur
 Organisiert Dinge die zur Design Zeit existieren.
 System wird in Pakete (Domänen) gegliedert.
 Ein Paket ist ein Bereich mit Dingen (Ergebnisse von Arbeitsprozessen =
Artifakte), normalerweise mit einem eigenen Vokabular (Namensraum bei
Programmen)
 Jeder Artifakt ist genau einem Paket zugewiesen
 Pakete werden oft in Abhängigkeits-Hierarchien angeordnet.
Gliederung des Gesamtpakets zum System (Menge aller Artifakte) in Schichten,
z. B. Paket für Anforderungsanalyse, Design, Implementierung (siehe auch linkes
Fenster im Case-Tool des Praktikums).
 Unter Anforderungsanalyse: Für jedes Use-Case-Diagramm ein (Unter-)Paket
 Unter Design: Aufteilen der Klassen des Klassendiagramms auf versch. Pakete.
Eine Generalisierungshierarchie befindet sich normalerweise in einem Paket
 Unter Implementierung: mehreren Pakete (getrennte Name-spaces) für den Code.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
121
5.2 Paketdiagramme in der UML
Paket-Sicht (gemäß UML, siehe Vorl. OOAD W.Weber) / Domänen Sicht / Logische Architektur
Paket
Abhängigkeit
Praktikum OOAD
Implementierung
Arzt
■
■
<<import>>
Behandlung
Doku
Hierarchie von Paketen (dargestellt durch Schachtelung)
import: Das Quellpaket (Paket, bei dem Pfeil beginnt) kann auf alle publicElemente des Zielpaketes ohne Qualifizierung (Zielpaket::) zugreifen.
-> Programmier-Vorl.: Paket std
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
122
5.2 Paketdiagramme in der UML
Paket-Sicht / Domänen Sicht / Logische Architektur(in Anlehnung an [Douglass06])
 Beispiel mit
Darstellung
der Klassen
und deren
Beziehungen
in den
Paketen
Alarm Domain
Hold classes and
types for Alarm
Management
Alarm Filter
Policy
Critical
Alarm
1
Informational
Alarm
Alarm
1
*
1
*
Alarm
Manager
1
1 1
<<import>>
User Interface Domain
*
Display
Control
Text
<<import>>
*
1
0..1
Window
1
Text List
*
Hardware Domain
Hold classes
and types for
User Interface
1
Speaker
Hold classes and
types that represent
hardware
Pushbutton
Turnknob
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
1
Button
Knob
123
5.2 Darstellung der Architektur
Physikalische Architektur
 Physikalische Architektur stellt Zusammenspiel der Systemteile dar, wie
Subsysteme, SW-/HW-Komponenten und Tasks
 Einige Subsysteme verwenden nur Artifakte aus einer Domäne (Paket), andere
benutzen Teile aus verschiedenen Domänen
 Die Physikalische Architektur beschreibt auch die Nutzung der Infrastruktur des
Systems
 Folgende Sichten sind in der Literatur beschrieben:






Subsystem- und Komponenten-Sicht / Logische Sicht
Prozess-Sicht / Thread-Level / Concurrency and Resource View
Einsatz-/ Deployment-/ Physische Sicht (was läuft auf welcher HW-Komponente)
Implementation- / Dateien-Sicht
Anwendungs-Sicht (nach [Kruchten95])
...
-> Tafelbild
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
124
5.2 Darstellung der Architektur
Ebenen der Abstraktion: Subsysteme, Komponenten, Threads (siehe [Douglass06])
System Level
Actor
Actor
Systems Engineering
Level
<<subsystem>>
<<subsystem>>
<<subsystem>>
Electronic
Software
Mechanic
Multidisciplinary
Level
Component
Component
Component
Component
Software Component
Level
<<subsystem>>
<<active>>
<<active>>
Thread Level
<<active>>
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
125
5.2 Darstellung der Architektur
Subsystem-Sicht, Komponenten-Sicht / Logische Sicht
 Die Subsystem- und Komponenten-Sicht identifiziert die großen Teile des Systems
und wie sie zusammenpassen (Darstellung z. B. durch das Komponentendiagramm der UML)
 Es gibt keine klare Unterscheidung zwischen Subsystemen und Komponenten
 Wenn wir annehmen, dass Subsysteme die größten Teile eines Systems sind,
dann sind Komponenten Teile von Subsystemen oder Komponenten
 Ein Subsystem / eine Komponente ist ein sehr großes Teil des Systems, das über
Komposition kleinere Teile des Systems enthält, die die Arbeit des Subsystems /
der Komponenete erledigen
 Das Kriterium für die Aufnahme in ein Subsystem / Komponente ist ein
gemeinsamer zu erfüllender Zweck (starke Kohäsion)
 Ein Subsystem / eine Komponente stellt gut definierte Interfaces zur Verfügung und
delegiert die Dienste zu internen versteckten Teilen.
 Die konkrete Kommunikation zwischen instanziierten Komponenten beschreibt den
Ablauf des Systems (Darstellung z. B. durch Kommunikations- oder Sequenzdiagramme der UML)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
126
5.2 Darstellung der Architektur
Subsystem-Sicht (in Anlehnung an [Douglass06]) /Logische Sicht
Darstellung der Subsysteme und der Beziehungen zwischen den Subsystemen.
(Könnte auch mit UML-Komponentendiagramm dargestellt werden)
1
Air Traffic Control System
Primary Radar
1
1
1
Radar_Subsystem
1
<<subsystem>>
1
1
AircraftSpace
Subsystem
*
<<subsystem>>
1
<<subsystem>>
1
Display_Subsystem 1
1
Controller
1
1
1
1
Alarm_Subsystem
Secondary
Radar
Antenna
Subsystem
1
<<subsystem>>
1
<<subsystem>>
1
AircraftCommunication
Subsystem
1
1
NAS_Interface
<<subsystem>>
National
Airspace System
1
1
*
<<subsystem>>
1
Scheduling
Subsystem
Aircraft
<<subsystem>>
1
1
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
Flight Planning
System
127
5.2 Darstellung der Architektur
Komponenten-Sicht (in Anlehnung an [Douglass06]) /Logische Sicht
Komponenten des Display-Subsystems
Protocol
Stack
<<use>>
<<use>>
Aircraft
Database
Flight Scheduling
Database
<<use>>
Display
M anager
Icon Library
<<use>>
Display Widget
<<use>>
M ath Library
<<use>>
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
128
5.2 Darstellung der Architektur
Komponenten- / Logische Sicht (in Anlehnung an [Kruchten95])
cod Autoradio
«component»
Audio Manager
Audio Requests
1
1..*
«component»
Audio Source Control
{abstract}
«component»
«component»
«component»
«component»
Traffic Announcement
Radio
Cassette
CD
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
129
5.2 Darstellung der Architektur
Komponenten-Sicht: Komponentendiagramm (gemäß UML) - Beispiel
InternetAccessForWebBrowserInterface
<<component>>
<<component>>
Internet_Access
Web_Browser
<< provided Interfaces>>
ThemeInterface
PluginInterface
<<required Interfaces>>
InternetAccessForWebBrowserI
nterface
<<realizations>>
Browser_GUI
HTML_Translator
<<artifacts>>
Browser.hpp
Browser.cpp
ThemeInterface
<<component>>
<<component>>
Web_Browser
Theme
<<component>>
Plugin
Black-Box
(Überblick)
PluginInterface
<<component>>
Web_Browser
Plugin greift auf
Webbrowser zu
<<Interface>>
PluginInterface
<<component>>
<<use>>
Plugin
White-Box
(mit Interna)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
130
5.2 Darstellung der Architektur
Komponenten-Sicht: Komponentendiagramm (gemäß UML) - Darstellungselemente
[UML2 glasklar]
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
131
5.2 Darstellung der Architektur
Komponenten-Sicht: Komponentendiagramm (gemäß UML) - Darstellungselemente
 Port: Kommunikationspunkt (interaction point). Z. B. zur Gruppierung mehrerer
Schnittstellen (die evtl. nur gewissen anderen Komponenten zur Verfügung
gestellt werden).
 In einer Komponenete können auch die in ihr enthaltenen Klassen und deren
Beziehungen untereinander dargestellt sein (auch möglich in einem
Kompositionsstrukturdiagramm (S. 191f in [UML2glasklar]) oder Structured
Class ([Douglass06])).
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
132
5.2 Darstellung der Architektur
Komponenten-Sicht: Komponentendiagramm (gemäß UML) - Darstellungselemente
[UML2
glasklar]
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
133
5.2 Darstellung der Architektur
Komponenten-Sicht: Komponentendiagramm (gemäß UML) - Beispiel
– Erklärung der Elemente
 Teilnehmerverwaltung bietet einen Port mit den Schnittstellen „Sortierter Zugriff“
und „Wahlfreier Zugriff“ an und benötigt die Schnittstelle Speichermedium.
 Speichermedium wird bereit gestellt durch Komponente
Datenbankmanagementsystem.
 Datenbankmanagementsystem besteht aus 2 Komponeneten
 Listengenerator benötigt die Schnittstelle „Sortierter Zugriff“
 Paginierer und Satzprogramm sind Unterkomponenten von Listengenerator, die
von Listengenerator benötigt werden
 Die Komponenete Listengenerator wird durch Lister_v2.0.ear realisiert.
Frage: Was könnten bei Cocktail-Pro Komponenten sein?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
134
5.2 Darstellung der Architektur
Prozess-Sicht / Thread-Level / Concurrency und Resourcen View
 Richtet sich auf das Management von Resourcen und die
Nebenläufigkeitsaspekte der Systemausführung
 Die Sicht beschreibt die Synchronisation von Threads und die gemeinsame
Nutzung von Resourcen
 Dies ist insbesondere für Embedded Systeme und Systeme zur
Prozesssteuerung eine der wichtigsten Sichten
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
135
5.2 Darstellung der Architektur
Prozess-Sicht / Thread-Level (in Anlehnung an [Douglass06]) / Concurrency and Resource View
Darstellung von
Beziehungen zwischen
Threads
Built in Test Thread
<<Task>>
1
1
Alarm Filtering Thread
Separation Distance
Monitor Thread
<<Task>>
1
<<Task>>
CmdRequest Queue
<<Message Queue>>
1
Aircraft Flight Plan
M onitor Thre ad
1
1
<<Task>>
1
1
Lock
1
<<Semaphore>>
1
1
1 1
1
Alarm List
<<Resource>>
1
Alarm Annunciation
Thread
1
<<Task>>
1
1
Speaker
1
ListView
<<Resource>>
Concurrency
view in the Alarm
subsystem
*
Alarm
1
*
TextView
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
136
5.2 Darstellung der Architektur
Prozess-Sicht (in Anlehnung an [Kruchten95]) / Thread-Level / Concurrency and Resource View
cd
PHP Request
1: HTML Get (URI)
<<process>>
Mozilla : HTMLClient
<<process>>
Apache : Webserver
2: PHP Parse(HTML_Code)
4: return(HTMLPage)
3 return (HTMLPage)
Darstellung der
Kommunikation zwischen
Threads (Prozessen)
<<process>>
tempPHP : PHP
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
137
5.2 Darstellung der Architektur
Einsatz- / Deployment- / Physische Sicht
 Betrachtet, wie die Softwarearchitektur auf die physikalischen Komponeten
abgebildet wird (Rechnerknoten im Netz, Prozessoren etc.)
 Viele Embedded Systeme bestehen aus Multiprozssorsystemen mit vielen
unterschiedlichen Hardwareeinheiten. (Manche Autos haben mehr als 50
Prozessorknoten und mehrere hundert Sensoren)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
138
5.2 Darstellung der Architektur
Einsatz- / Deployment-Sicht (in Anlehnung an [Douglass06]) / Physische Sicht
Verteilungs/Deploymentdiagramm:
Main Data
Aqu
Processor
Primary
Radar
Radar
Bus
Secondary
Radar
Backup Data
Aqu Processor
Network
Tape System
GPS
Sensor
Flight
Recorder
Mirrored Tape
System
Scheduling
Backup
Display
Controller
Display
Controller
NAS
Interface
Device
Terminal
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
139
5.2 Darstellung der Architektur
Einsatz- / Deployment- / Physische Sicht (in Anlehnung an [Kruchten95])
csd
Audio-Video-Hardware
Audio-Video-System
CD/DVD Player (vorne)
Audio/Videosystem
(Vorne)
Unterstützt TV,
DVD, MP3,
CD-Audio
CD1 Control Send
Liest DVD,
MP3, CDAudio
CD1 In
CD Out
CD2 Control Send
CD Changer
CDC Control
CD2 In
Liest CD-Audio
AV In
AV Out
TV In
(FBAS)
CD Control
CD Out
Videoterminal
TV Tuner
Monitor – zeigt
eine
Videoquelle an
Empfängt TV
Signal und
liefert ein TV
Video
TV Out
(FBAS)
Antenne
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
140
5.2 Darstellung der Architektur
Implementations-Sicht (in Anlehnung an [Kruchten95])
 Komponentendiagramm mit Dateien, Repositories und deren Beziehungen
untereinander
cod CocktailPro2006
«artifact»
Rezepturprozessor.hpp
«use»
Rezepturprozessor
CocktailPro.cpp
«use»
«artifact»
«component»
«artifact»
«us
e»
Rezepturprozessor.cpp
«component»
Dosierer
«use»
«artifact»
Rezeptbuch.hpp
«artifact»
Rezeptbuch.o
«artifact»
Dosierer.hpp
«artifact»
Dosierer.cpp
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
141
5.2 Darstellung der Architektur
Anwendungs-Sicht (nach [Kruchten95])
 Darstellung des Verhalten des Systems, der Interaktion z. B. zwischen
Komponenten-Objekten
 Umsetzung: Sequenz-, Kommunikationsdiagramme u. ä.
sd
Stationstaste aufrufen
:Stationmanager
Radio UI: UI Page
ActiveTuner: Tuner
Radiohörer
SelectPreset(n)
CallStation(n)
SetFrequency(f)
Beep()
Software Engineering, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, WS 2013, h_da, Fachbereich Informatik
142
5.2 Darstellung der Architektur
Dokumentation und Tools
 Die UML bietet diverse Möglichkeiten um Architektursichten darzustellen.
Zum Beispiel:
 Paket-Sicht - Logische Architektur – Domänen-Sicht :Paketdiagramm
 Subsystem- und Komponenten- / Logische Sicht:
 Statik: Komponentendiagramm, Klassendiagramm,
Kompositionsstrukturdiagramm (Structured Classes),
 Dynamik: Kommunikationsdiagramm, Sequenzdiagramm
 Prozess-/ Thread-Sicht / Concurrency and Resource View:
 Zustandsdiagramm, Kommunikationsdiagramm, Sequenzdiagramm (Message
Sequence Chart), Aktivitätsdiagramm, Timing Diagramm
 Einsatz-/ Deployment-/ Physische Sicht :
 Verteilungs-Diagramm, Komponentendiagramm
 Implementations-Sicht / Dateien-Sicht :
 Komponentendiagramm
Welche Diagramme verwendet werden (dürfen), legt der Architekturprozess fest!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
143
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
5.3 Zusammenfassung SW-Architektur
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
144
5.3 Zusammenfassung Software-Architektur
Beispiel zur Softwarearchitektur (I)
 Stellen Sie sich vor, Sie sollen ein einfaches Autoradio entwickeln
 mit Radio inklusive Verkehrsfunk, Kassette und CD
 mit den üblichen Verstärkerfunktionen
 Was sollten Sie nun in der Architektur festlegen?
 alles was festgelegt werden muss, bevor die Bestandteile des Systems einzeln
bearbeitet werden können:
- die Aufteilung des Systems in Komponenten (z.B. Radio, CD, usw.) mit
Verantwortlichkeiten
- die Schnittstellen zwischen diesen Komponenten untereinander und zur Außenwelt
- die Verteilung der Software auf Dateien
 den Aufbau des Systems als Hardware
- die Umsetzung von kritischen Vorgängen (z.B. Timingverhalten beim Überblenden)
- die Verteilung der Software zur Laufzeit auf Hardware (Entwicklungsrechner, Target)
- die Umsetzung von (komponentenübergreifenden) Use Cases zur Veranschaulichung
(z.B. "Wechsel von CD auf Radio" betrifft CD, Amplifier und Radio)
Logische Sicht, Implementierungs-Sicht, Prozess-Sicht,
SWEPhysische
© Prof. Dr. W.Sicht,
Weber, Anwendungssicht!
h_da, Fachbereich Informatik
145
5.3 Zusammenfassung Software-Architektur
Beispiel zur Softwarearchitektur (II)
cod Autoradio
«component»
Audio Manager
Audio Requests
1
 Ein Ergebnis der Architektur für das
Autoradio könnte sein:
1..*
«component»
Audio Source Control
{abstract}
 Diverse Komponentendiagramme,
welche die Aufteilung des Systems
in Komponenten und Schnittstellen zeigen (z.B. Audio Source
und Audio Manager) und die
Verantwortlichkeiten dokumentieren
 Verteilungsdiagramme, welche die Hardware und die jeweils darauf laufende
Software aufzeigen (Soundprozessor, Entwicklungsrechner, Target etc.)
 Timing-Diagramme, welche die Umsetzung von kritischen Vorgängen mit
Prozessen und Threads zeigen z. B. für Zeitverhalten beim Überblenden
 Sequenzdiagramme, welche die Umsetzung von Use Cases skizzieren, die
mehrere Komponenten betreffen (z.B. Audioquelle wechseln)
 weitere Dokumente und Diagramme je nach Entwicklungsprozess
«component»
«component»
«component»
«component»
Traffic Announcement
Radio
Cassette
CD
Die Anzahl und Art der Diagramme hängt stark vom Entwicklungsprozess, dem
Projekt, dem Team und dem Kommunikationsbedarf ab!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
146
5.3 Zusammenfassung Software-Architektur
Nutzen einer SW-Architektur
 für den Entwicklungsprozess





trifft weitreichende, frühe Designentscheidungen
weist Machbarkeit von Softwarefunktionalität nach
macht Vorgaben für Design und Implementierung
strukturiert den Entwicklungsprozess
bietet Kommunikationsplattform
 für die Planbarkeit
 liefert die Einheiten der Planung für Design, Implementierung, Test und Wartung
 für die Wettbewerbsfähigkeit
 reduziert Kosten durch Wiederverwendung im Großen
 erhöht Flexibilität durch Betrachtung von Varianten ohne Umsetzung
Ohne eine SW-Architektur ist die Komplexität eines großen
Projekts nicht zu bewältigen!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
147
5.3 Zusammenfassung Software-Architektur
Auswirkungen von Fehlern in der SW-Architektur
 Falsche Requirements:
 Unterschätzung der Bedeutung / Übersehen eines wichtigen Requirements
- Schwerwiegende Änderungen in späteren Phasen / keine Wiederverwendung
 Überschätzung der Bedeutung
- Unnötige Arbeit und Kosten
 Falsche Gewichtung der Requirements gegeneinander
- Falsche Ausrichtung der Architektur / Verfehlung des Projektziels
 Fehler in der Struktur aus Komponenten und deren Beziehungen:
 Ungeschickte Aufteilung bzw. Festlegung der Verantwortlichkeiten
- Kleine Änderungen haben große Auswirkung
 Zu grobe Struktur
- Keine ausreichenden Vorgaben für die Entwicklung / Übersehen von Problemen
 Zu feine Struktur
- Ineffiziente Architektur-Arbeit
Architekturentwicklung ist immer eine Gratwanderung!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
148
5.3 Zusammenfassung Software-Architektur
Kontrollfragen zur Software-Architektur





Warum ist eine Software-Architektur für ein großes Projekt wichtig?
Was passiert, wenn die Bedeutung einer Anforderung unterschätzt wird?
Welche Aspekte des Entwurfs drückt man in der SW-Architektur aus?
Wie wirkt sich die Verwendung eines Architektur-Stils aus?
Hängt die SW-Architektur von der Programmiersprache / dem Betriebssystem
ab?
 Wie dokumentieren Sie eine SW-Architektur?
Ahnen Sie jetzt wie man eine SW-Architektur erstellt?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
149
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
6. (Fein-)Design
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
150
6. Design
Einordnung im V-Modell
Anwendungsszenarien
Anforderungsdefinition
Grobentwurf
(SW-Architektur)
Feinentwurf
(Design)
Modul-Implementierung
Testfälle
Testfälle
Testfälle
Abnahmetest
Systemtest
Integrationstest
Modultest
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
151
6. Design
Lernziel Design
Frage: Was wissen Sie schon über das Design von Software?
Welche Modelle kennen Sie bereits zum Design von SW (aus OOAD)?
Welche Grundprinzipien, Welche Regeln des Designs kennen Sie?
 Sie sollen in diesen Kapitel,







verstehen was im Design passiert
weitere Techniken kennen lernen, die einen guten Entwurf fördern
wiederholen, welche Grundprinzipien beim Entwurf gelten
wiederholen, welche Regeln es zum Entwurf von Klassen und Assoziationen gibt
verstehen warum man Design-Patterns verwenden sollte
verstehen was ein Anti-Pattern ist
verstehen warum ein Blob kein guter Entwurf ist
Anschließend können Sie Vor- und Nachteile an
einem Entwurf erkennen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
152
6. Design
Vorgehen im Projekt
 Situation im Projekt
 Ein relativ kleines Team von Systemanalytikern und Architekten hat
die Anforderungen bestimmt und eine Architektur entworfen
 Die Architektur beschreibt das System auf einer abstrakten Ebene
 Verfeinere die SW-Architektur !
 Verteile die Komponenten, welche durch die Architektur festlegt sind, für die
Ausarbeitung der Details
- an interne Teams oder auch an Externe
 die Beziehungen zwischen den Komponenten legt die Architektur fest
- Die Erfüllbarkeit der wesentlichen Anforderungen wurde mit der
Architektur analysiert und "getestet"
Die SW-Architektur gibt einen Rahmen vor,
der im Design ausgefüllt wird !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
153
6. Design
Die Aufgabe des Designs
 Die SW-Architektur
 gibt eine Zerlegung in Arbeitspakete mit Verantwortlichkeiten vor
 macht Vorgaben für das weitere Vorgehen und die Umsetzung
(z.B. Installation, Prozesse, Verteilung auf Rechner usw.)
 Es fehlen noch sämtliche detaillierte Beschreibungen mit Methoden, Parametern,
konkreten Abläufen
 Im Design
 werden Details ausgearbeitet
- Klassen mit Methoden und Datentypen
- Abläufe
- Betriebssystemanbindung (Threads, Scheduler, Timer,… )
 entstehen Klassendiagramme, Sequenzdiagramme, Zustandsdiagramme usw.
 erfolgt die Umsetzung auf Programmiersprache(n), Betriebssystem(e), Hardware
 Im Design wird das Konzept für die Implementierung
der (einzelnen) Komponenten gemacht !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
154
6. Design
Gutes Design
 Im Design
 gibt es viele Lösungen
 sind viele Lösungen ungeeignet, einige sind geeignet
 je konkreter die Randbedingungen vorgegeben sind, desto weniger gute
Lösungen gibt es – bis hin zu überhaupt keiner
Frage: Welche Lösung ist gut, welche Lösung ist schlecht?
 Wege zu einem guten Design:
 Prinzipien lernen
 Regeln / Tipps und Tricks lernen (Best Practices)
 aus eigenen Fehlern lernen
 Designprinzipien
 Regeln
 Üben
 Weitere Möglichkeiten
 Bekannte (und gute) Lösungen einsetzen
 aus bekannten Fehlern lernen
 Design Patterns
 Anti Patterns
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
155
6. Design
Zur Erinnerung aus OOAD: Regeln für ein gutes Design (I)
 Grundprinzipien
 Trennung von Zuständigkeiten => starker Zusammenhalt
- jeder Teil / jede Klasse hat genau eine Aufgabe
 Minimierung von Abhängigkeiten
- Minimiere die Abhängigkeiten zwischen Systemteilen
 Geheimnisprinzip
- Kapsele das interne Wissen eines Systemteils und verrate es niemand anderem
 Homogenität
- Löse ähnliche Probleme mit ähnlichen Lösungen und verwende ähnliche
Strukturierungsgrößen innerhalb einer Strukturierungsebene
 Redundanzfreiheit
- Keine Teile sind doppelt vorhanden
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
156
6. Design
Zur Erinnerung aus OOAD: Regeln für ein gutes Design (II)
 Regeln zum Entwurf von Klassen







Setze Vererbung sparsam ein
Normalisiere das Datenmodell
Vermeide transitive Assoziationen
Analysiere m:n-Beziehungen genau
Vermeide 1:1-Beziehungen
Modelliere nur fachliche, nie technischen Aspekte
Beschränke Dich auf das für das System Notwendige
 Regeln zum Entwurf von Operationen und Schnittstellen






Operationen sind unabhängig von der verwendeten Technologie
Gib keine Referenzen nach außen
Normalisiere die Schnittstelle
Mache die Operationen grobgranular
Mache die Operationen idempotent
Mache die Operationen kontextfrei
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
157
6. Design
Zur Erinnerung aus OOAD: Regeln für ein gutes Design (III)
 Es gibt weitere Prinzipien bzw. diverse Varianten dieser Prinzipien
 die Kernaussage bzw. Zielrichtung ist allerdings seit vielen Jahren unumstritten
 Diese Grundprinzipien sind anwendbar
 für implementierungsnahen Entwurf ("Feinentwurf")
 aber auch für den Entwurf von Anwendungen auf höherer Abstraktionsebene
("Software Architektur") bis hin zu Anwendungslandschaften
Diese Regeln geben konkrete Leitlinien für den Entwurf !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
158
Hochschule Darmstadt
Fachbereich Informatik
Objektorientierte Analyse und Design
6.1 Wiederholung, für die, die nochmals nachschauen wollen:
Grundprinzipien für das Design
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
159
6.1 Grundprinzipien für das Design
Idee für das 1. Grundprinzip
Trenne, was nicht zusammengehört
Trenne das, was nicht zusammen gehört –
oder andersrum:
Sorge dafür, dass (z. B. innerhalb einer
Klasse) alles stark zusammenhängt !
 Für Funktionen, Klassen, Komponenten: "Starker Zusammenhalt" (Strong
Cohesion)
 Kohäsion ist ein Maß dafür, wie eng die Beziehungen und der Fokus der
Verantwortlichkeiten in einem Modul (Funktion, Klasse, .. ) sind
- Schwache Kohäsion:
•
Ein Modul ist verantwortlich für viele Aufgaben
- Starke Kohäsion:
•
Jeder Modul hat einen einzigen, klaren Zweck
z. B. jede Operation einer Klasse hat einen einzigen, klaren Zweck und
z. B. die Operationen einer Klasse bilden eine Gruppe zusammengehörender Aufgaben
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
160
6.1 Grundprinzipien für das Design
Grundprinzip 1: Starker Zusammenhalt (Strong Cohesion),
Trennung von Zuständigkeiten (Separation of Concerns)
 Unterteile das System so in Teile, dass jeder Teil genau eine Aufgabe hat !
 Diese Aufgabe wird auch nur von diesem Teil erledigt
 Die Abgrenzung gegenüber anderen Teilen ist klar erkennbar
 Die Aufgabe ist genau und prägnant definiert und spiegelt sich
im Namen des Teils wider
 Trenne Teile an denen sich (voraussichtlich) keine Änderungen ergeben, von
Teilen an denen sich wahrscheinlich Änderungen ergeben!
 Vorteile von getrennten Zuständigkeiten:
 Ein Systemteil, der nur eine Zuständigkeit hat, ändert sich nur, wenn an dieser
einen Zuständigkeit eine Änderung nötig wird!
 Trennung von Zuständigkeiten fördert
die Wartbarkeit (Gute Verständlichkeit),
Erweiterbarkeit und Wiederverwendbarkeit !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
161
6.1 Grundprinzipien für das Design
Idee für das 2. Grundprinzip
A
B
- A* f();
- void g(D d);
- void h(C* c)
- B* f();
- void g(D d);
- void h(C* c)
C
- B* f();
- void g(D d);
- void h(A* a)
D
- B* f();
- void g(C c);
- void h(A* a);
Ein System ist schwer zu handhaben,
wenn jeder jeden kennt!
Reduziere die Anzahl der Beziehungen
auf das Nötige!
 Für Funktionen, Klassen, Komponenten: "Schwache Kopplung" (Loose
Coupling)
 Kopplung ist ein Maß dafür, wie sehr ein Element von anderen abhängt
 z. B. Klasse A ist von B abhängig, wenn:
- A hat ein Attribut vom Typ B oder verwendet eine Methode eines Objekts vom Typ B
- A hat eine Methode mit Parameter/Return vom Typ B
- A ist von B abgeleitet oder A implementiert die Schnittstelle von B
 Das Prinzip der schwachen Kopplung fordert Klassen so zu definieren, dass nur
die nötige Kopplung da ist
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
162
6.1 Grundprinzipien für das Design
Grundprinzip 2: Schwache Kopplung (Loose Coupling)
Minimierung von Abhängigkeiten
 Minimiere die Abhängigkeiten zwischen Systemteilen !
 fasse stark zusammenhängende Teile zusammen
 überprüfe die Verantwortlichkeiten auf eine saubere Trennung
 entkopple abhängige Teile (evtl. durch Auslagerung in einen neuen Teil)
 Vorteile von minimierten Abhängigkeiten:
 Veränderungen eines Systemteils tangieren nur wenige andere Klassen !
 Minimierung von Abhängigkeiten fördert die
Verständlichkeit, Wiederverwendbarkeit und Wartbarkeit !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
163
6.1 Grundprinzipien für das Design
Idee für das 3. Grundprinzip
Class Diagram: CRM
CustomerStack
- void push ( string name, string address );
- int getPositionInStack (string name);
- void modify ( int position, string address );
Änderungen werden erschwert, wenn
die interne Realisierung eines Systemteils
anderen Systemteilen bekannt ist und diese
die Interna ansprechen und verwenden !
Die aufrufenden Objekte erfahren, dass
die Umsetzung über einen Stack erfolgt.
Die aufrufenden Objekte müssen sogar
Stackoperationen verwenden und die
Funktionsweise eines Stacks verstehen
 Eselsbrücke "Geheimagenten-Prinzip":
 Jeder "verrät" nur das, was ein anderer wissen muss, um mit ihm zu arbeiten!
 Jeder "weiß" nur das, was er wissen muss, um seinen Job zu machen!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
164
6.1 Grundprinzipien für das Design
Grundprinzip 3: Geheimnisprinzip ("Information Hiding")
 Kapsele das interne Wissen eines Systemteils und verrate es niemand anderem!
 Abläufe, Daten und Strukturen sind gekapselt
 Systemteile sind benutzbar ohne Kenntnis der Realisierung (Nur Schnittstelle ist
bekannt, nicht die Implementierung)
 interne Änderungen sind von außen nicht sichtbar
 Umsetzung in C++:
 Sichtbarkeit "private" für alle Attribute und interne Methoden
 Vorteile des Geheimnisprinzips:
 unterstützt Trennung von Zuständigkeiten und Minimierung der Abhängigkeiten
 erleichtert verteilte Entwicklung
 Das Geheimnisprinzip fördert die
Wartbarkeit, Änderbarkeit und Testbarkeit !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
165
6.1 Grundprinzipien für das Design
Idee für das 4. Grundprinzip
Navi-System
Ein uneinheitlicher Entwurf
erschwert das Verständnis !
GPS-Driver
Navigation
Statusbar
EmergencyCall
Die Komponenten des Systems haben stark
unterschiedliche Komplexität
(z.B. die gesamte Navigation im Vergleich zu
einem Statusbar) und sind auch nicht intuitiv
angeordnet (z.B. in Schichten für Treiber,
Anwendungen usw.))
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
166
6.1 Grundprinzipien für das Design
Grundprinzip 4: Homogenität
 Verwende ähnliche Strukturierungsgrößen innerhalb einer Strukturierungsebene
 entwerfe Systemteile innerhalb einer Strukturierungsebene
(z.B. Anwendungsschicht) so, dass die Größe und Komplexität
ungefähr gleich ist
 verwende bei Bedarf mehrere - jeweils homogene - Strukturierungsebenen
 löse ähnliche Probleme mit ähnlichen Lösungen!
 verwende bereits bekannte Lösungen erneut – sofern es keine wichtigen Gründe
für eine andere Lösung gibt
 Vorteile der Homogenität:
 vermeidet unnötiges Neuerfinden von vorhandenen Lösungen
 erleichtert die Entscheidungsfindung
 Homogenität fördert die
Wartbarkeit und die Verständlichkeit !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
167
6.1 Grundprinzipien für das Design
Idee für das 5. Grundprinzip
Know-how (in jeglicher Form), das an
mehreren Stellen im Entwurf auftaucht,
wird früher oder später inkonsistent
und führt zu Problemen !
Class Diagram: CRM
CustomerManager
// Die Verwaltung der Kunden erfolgt so, dass...
// ... dabei ist zu beachten ...
CustomerUser
// Dies muss so sein, weil die Verwaltung der
// Kunden so erfolgt, dass...
// ... dabei ist zu beachten ...
Die spezielle Art der Kundenverwaltung
wird an mehreren Stellen berücksichtigt
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
168
6.1 Grundprinzipien für das Design
Grundprinzip 5: Redundanzfreiheit (DRY - Don’t Repeat Yourself)
 Entwerfe das System so, dass jedes Stück Know-how in dem System nur an
genau einer Stelle umgesetzt wird, die eindeutig und zuständig ist !
 Damit ist nicht nur Code gemeint! Es kann sich um alle Teile handeln, in denen
Know-how steckt – also auch um Teile des Entwurfs, ein Datenbankschema oder
auch die Dokumentation
 ziehe mehrfach verwendete Teil heraus und mache Sie für Andere verfügbar
 finde eine eindeutige und sinnvolle "Heimat" für das Know-how
 vermeide "Copy & Paste – Entwicklung"
 Vorteile der Redundanzfreiheit:
 fördert die Trennung der Zuständigkeiten (man muss sich entscheiden)
 Korrekturen müssen nur noch an einer Stelle erfolgen
 Redundanzfreiheit fördert die
Wiederverwendbarkeit, Wartbarkeit und die Verständlichkeit !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
169
6.1 Grundprinzipien für das Design
Zusammenfassung der Grundprinzipien
 5 Grundprinzipien





Trennung von Zuständigkeiten (Kohäsion / Zusammenhalt)
Minimierung von Abhängigkeiten (schwache Kopplung)
Geheimnisprinzip
Homogenität
Redundanzfreiheit
 Es gibt weitere Prinzipien bzw. diverse Varianten dieser Prinzipien
 die Kernaussage bzw. Zielrichtung ist allerdings seit vielen Jahren unumstritten
 Diese Grundprinzipien sind anwendbar
 für implementierungsnahen Entwurf ("Feinentwurf")
 aber auch für den Entwurf von Anwendungen auf höherer Abstraktionsebene
("Software Architektur") bis hin zu Anwendungslandschaften
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
170
Hochschule Darmstadt
Fachbereich Informatik
Objektorientierte Analyse und Design
6.2 Wiederholung, für die, die nochmals nachschauen wollen:
Regeln zum Entwurf von Klassen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
171
6.2 Regeln zum Entwurf von Klassen
Zur Erinnerung: Schritte zum Entwickeln von Klassendiagrammen
1. Klassen(kandidaten) finden




2.
Substantive bestimmen
überflüssige Begriffe rausfiltern
Attribute identifizieren
Operationen über Verben suchen
Spezialisierungsbeziehungen suchen
 Ähnliche Klassen identifizieren (Aber: "Ist-ein-Regel" beachten!)
 Evtl. Schnittstellen durch abstrakte Klasse + Spezialisierung definieren
3. Assoziationen zwischen Klassen bestimmen




"Kennt"-Beziehungen: normale Assoziation
"Besteht aus"-Beziehung: Aggregation bzw. Komposition
evtl. Leserichtung und Rollen angeben
Objekte, deren Existenz an einer Assoziation hängt: Assoziationsklasse
4. Multiplizitäten und Navigationsrichtungen eintragen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
172
6.2 Regeln zum Entwurf von Klassen
Entwurf von Klassen
 Bisher kennen Sie ein "Standardverfahren" zur Bestimmung von Klassen
und den Beziehungen dazwischen
 es geht darum, die Klassen so zu entwerfen, dass die Qualitätsanforderungen
möglichst gut erfüllt werden
 aber es gibt immer viele verschiedene Lösungen mit unterschiedlichen
Eigenschaften, welche die Qualitätseigenschaften mehr oder weniger gut erfüllen
 Wir betrachten nun einige Beispiele und




erarbeiten jeweils eine (naheliegende) Lösung
analysieren die Nachteile dieser Lösung
diskutieren eine zweite Lösung, welche die Nachteile nicht hat
leiten daraus eine Regel für den Entwurf von Klassen ab
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
173
6.2 Regeln zum Entwurf von Klassen
Aufgabe 1
 Modellieren Sie folgenden Sachverhalt:
 Ein Softwaresystem für eine Firma soll Kunden, Lieferanten und Mitarbeiter
verwalten
 Alle werden durch Name und Adresse identifiziert
 Ein Mitarbeiter ist entweder Arbeiter oder Manager
 Prüfen Sie, wie die folgenden naheliegenden Punkte mit Ihrer Lösung umgesetzt
werden können:
 Kunden können gleichzeitig auch Lieferanten sein
 Arbeiter können zu Managern befördert werden
 In Zukunft können auch weitere Personen wie Gesellschafter etc., aber auch
weitere Laufbahnstufen wie Ingenieur etc. relevant werden
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
174
6.2 Regeln zum Entwurf von Klassen
Lösung A: mit Generalisierung / Spezialisierung
Object Diagram Person mit Vererbung
Class Diagramm Person mit Vererbung
Redundanter Name und
Adresse, wenn Huber sowohl
Kunde als auch Lieferant ist.
Person
- adresse: String
- name: String
Huber: Kunde
Kunde
Lieferant
Huber: Lieferant
Mitarbeiter
Bei der Beförderung von Schmidt
vom Arbeiter zum Manager muss das
Arbeiter-Objekt gelöscht, ein neues
Manager-Objekt angelegt und alle
Attribute vom Arbeiter- zum
Manager-Objekt kopiert werden.
Arbeiter
Manager
Schmidt: Arbeiter
Schmidt: Manager
Einfügen neuer Personen wie Gesellschafter etc.,
oder weiterer Laufbahnstufen wie Ingenieur etc.
erfordern eine strukturelle Änderung des Modells.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
175
6.2 Regeln zum Entwurf von Klassen
Lösung B: Mit Assoziation (bzw. Komposition, Aggregation)
Object Diagram Person mit Assoziation
Dieselbe Person kann verschiedene
Rollen haben. Name und Adresse
werden nur einmal gespeichert.
Huber: Person
Class Diagram Person mit Assoziation
Lieferant: Rolle
Rolle
Person
adresse: String
name: String
Kunde: Rolle
*
-
typ: enum {Kunde, Lieferant, Mitarbeiter:Arbeiter,
Mitarbeiter:Manager}
Die Beförderung vom Arbeiter zum
Manager wird durch Änderung des
Attributstyps dargestellt
Schmidt: Person
Warum nicht als Attribut Rolle[ ] in Person?
MyPosition: Rolle
typ = Mitarbeiter:
Arbeiter 
typ= Mitarbeiter:
Manager
Neue Rollen wie Gesellschafter
etc. können durch einfache
Erweiterung des Aufzählungstyps
dargestellt werden
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
176
6.2 Regeln zum Entwurf von Klassen
Regel 1: Setze Vererbung (Generalisierung / Spezialisierung) sparsam ein
 Vererbung (Generalisierung / Spezialisierung) ist das am meisten überschätzte
und überbenutzte Konzept der Objekt-Orientierung
 Setze Vererbung nur bei echter „ist ein“ Beziehung ein
 Ersetze, wo sinnvoll möglich, eine Vererbung durch eine Assoziation
 Beispiele:
 Ein Kunde ist eine Person  eine Person hat die Rolle Kunde
 Eine Frau ist eine Person  eine Person hat das Geschlecht weiblich
 Ein Rothaariger ist eine Person  eine Person hat die Haarfarbe rot
 Verwende nur einfache Vererbung (Single Inheritance)
 „Bei der Einfachvererbung hat man nur einen Schuss – und der muss sitzen!“
 Schachtele Vererbungsbäume nicht zu tief
 Tiefe 2-3 reicht meistens aus
 Sparsame Verwendung von Vererbung fördert
die Einfachheit und Erweiterbarkeit von Modellen !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
177
6.2 Regeln zum Entwurf von Klassen
Aufgabe 2
 Modellieren Sie folgenden Sachverhalt:
 In einem MP3-Archiv sollen Lieder gespeichert werden
 Für jedes Lied soll der Titel des Lieds, Titellänge, der Interpret, der Wohnort des
Interpreten, der Name des Albums und das Bild des Album-Covers gespeichert
werden
 Prüfen Sie, wie die folgenden naheliegenden Punkte mit Ihrer Lösung umgesetzt
werden können:
 Wurde der Name des Interpreten oder des Albums falsch geschrieben, so kann
dies leicht korrigiert werden
 In der nächsten Version sollen zu einem Album weitere Daten gespeichert
werden wie z.B. das Genre (Klassik, Rock, ...)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
178
6.2 Regeln zum Entwurf von Klassen
Lösung A: mit Redundanzen
Object Diagram Lied
Not That Kind: Lied
interpret = Anastacia ...
album = Not That Kind ...
Class Diagram Lied
...
I'm Outta Love: Lied
interpret = Anastacia ...
album = Not That Kind ...
...
Cowboys & Kisses: Lied
interpret = Anastacia ...
album = Not That Kind ...
...
Lied
interpret: String
intepret-wohnort: String
album: String
album-cover: Bild
titel: String
titel-länge: Int
Shine On You Crazy
Diamond: Lied
interpret = Pink Floyd ...
album = Wish You Were Here ...
...
Ist der Name des Interpreten oder das Album
falsch geschrieben, so muss dies in allen
Objekten vom Typ Lied korrigiert werden.
Inkonsistente Einträge können leicht entstehen.
Weitere zu Album gehörende Daten wie z.B.
das Album-Cover sind in allen Liedern
redundant vorhanden.
 Die Normalisierung das Datenmodells
reduziert Redundanzen !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
179
6.2 Regeln zum Entwurf von Klassen
Lösung B: normalisiert
Object Diagram Lied normalisiert
Not That Kind:
Lied
Anastacia:
Interpret
von
Not That Kind:
Album
I'm Outta Love:
Lied
Cowboys & Kisses:
Lied
Class Diagram Lied normalisiert
Interpret
-name: String
-ort: String
Album
◄ von
1..* -titel: String
-cover: Bild
Lied
-titel: String
1..* -länge: Int
Normalisierung reduziert
Redundanzen:
siehe Vorlesung Datenbanken!
Pink Floyd:
Interpret
von
Wish You Were
Here: Album
Shine On You
Crazy Diamond
:Lied
Ist der Name des Interpreten oder das Album
falsch geschrieben, so muss dies nur im Objekt
Interpret bzw. Album korrigiert werden.
Weitere zu Album gehörende Daten wie z.B.
das Album-Cover sind nicht redundant
vorhanden.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
180
6.2 Regeln zum Entwurf von Klassen
Aufgabe 3
 Modellieren Sie folgenden Sachverhalt aus einem Auftragssystem:
 Kunden können Bestellungen aufgeben
 Mehrere Bestellungen zusammen bilden einen Monats-Auftrag
 Ein Monats-Auftrag bezieht sich immer auf einen Kunden
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
181
6.2 Regeln zum Entwurf von Klassen
Lösung A: Transitive Assoziationen
Object Diagram Bestellung mit Zykel
Müller: Kunde
Huber: Kunde
Class Diagram Bestellung mit Zykel
Kunde
▲ von
1
gibt auf
1
gibt auf
▲ von
Dezember:
*
Monats-Auftrag
*
Monats-Auftrag
*
1
Buch: Bestellung
Bestellung
Müller hat den Monats-Auftrag für Hubers Bestellungen. Das
ist natürlich fachlich falsch. Das Datenmodell erlaubt es aber.
Das Modell könnte durch eine entsprechende Einschränkung
(Constraint) korrigiert werden, aber es gäbe immer noch eine
redundante Assoziation.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
182
6.2 Regeln zum Entwurf von Klassen
Lösung B: Ohne transitive Assoziationen
Object Diagram Bestellung ohne Zykel
Müller: Kunde
Class Diagram Bestellung ohne Zykel
Kunde
▲ von
1
1
▲ von
Buch: Bestellung
Dezember:
*
Monats-Auftrag
Monats-Auftrag
*
1
Bestellung
Der Kunde als Auftraggeber ist
nun eindeutig bestimmt
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
183
6.2 Regeln zum Entwurf von Klassen
Regel 3: Vermeide transitive Assoziationen
Class Diagram Bestellung mit Zykel
Kunde
1
1
 Transitive Beziehungen bieten mehrere Wege für eine
Beziehung zwischen zwei Objekten
gibt auf
▲ von
*
MonatsAuftrag
*
*
Bestellung
1
 in Lösung A gibt es
- die direkte Beziehung "gibt auf" von Kunde zu Bestellung
- eine Beziehung von Kunde über Auftrag zu Bestellung
 Man kann die Beziehungen mit unterschiedlichen Objekten assoziieren (wie in
Lösung A)
 Vermeide transitive Assoziationen
 Transitive Beziehungen können meist durch Weglassen von (redundanten)
Assoziationen aufgelöst werden
 Falls transitive Beziehungen nicht vermeidbar sind, müssen Widersprüche über
Constraints ausgeschlossen werden
z.B. Kunde der Bestellung muss gleich sein dem Kunden des Auftrags
 Vermeidung von transitiven Beziehungen reduziert
Redundanzen und erhöht die Korrektheit!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
184
6.2 Regeln zum Entwurf von Klassen
Aufgabe 4
 Es soll ein Customer Relation Management (CRM) für einen Reiseveranstalter
entworfen werden. Modellieren Sie folgenden Sachverhalt:
 Reisende können viele Reisen buchen (d.h. Reiseaufträge erteilen)
 Ein Reiseauftrag kann mehrere Reisende umfassen
 Prüfen Sie, wie der folgende naheliegende Punkt mit Ihrer Lösung umgesetzt
werden kann:
 Das System soll in der Wartungsphase so umgebaut werden, dass zusätzlich der
Status eines Visa für jede Reise und jeden Reisenden erfasst werden kann
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
185
6.2 Regeln zum Entwurf von Klassen
Lösung A: m:n-Beziehungen
Class Diagram: CRM mit m:n Beziehungen
Object Diagram: CRM mit m:n Beziehungen
Mallorca:
Reiseauftrag
Huber: Kunde
Reisender
1..*
Indien:
Reiseauftrag
*
Reiseauftrag
Mayer: Kunde
Russland:
Reiseauftrag
HuberNachIndien:
HuberNachIndien:
Reisevoraussetzung
Reisevoraussetzung
Ein Visum ist abhängig vom Reisenden und vom
Reiseziel. Der Zustand muss in einer Assoziationsklasse
abgespeichert werden!
Das erfordert allerdings in der Realisierung eine neue
Klasse und Änderungen an Reisender oder Reiseauftrag!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
186
6.2 Regeln zum Entwurf von Klassen
Lösung B: m:n-Beziehungen aufgelöst
Class Diagram: CRM mit 1:n Beziehungen
Reisender
Object Diagram: CRM mit 1:n Beziehungen
Huber:
Reisender
1
HuberNachMallorca:
Reisevoraussetzung
- Visum: keins
HuberNachIndien:
Reisevoraussetzung
- Visum: OK
*
Reisevoraussetzung
- Visum_Status
Indien:
Reiseauftrag
MayerNachIndien:
Reisevoraussetzung
- Visum: beantragt
1..*
Reiseauftrag 1
Mallorca:
Reiseauftrag
Mayer: Reisender
MayerNachRussland:
Reisevoraussetzung
Russland:
Reiseauftrag
- Visum: OK
Zu einem Reiseauftrag können nun für alle Reisenden die
Reisevoraussetzungen gespeichert werden.
Damit keine transitive Assoziation entsteht, wird die Assoziation
zwischen Reiseauftrag und Reisender jetzt über die
Reisevoraussetzung geführt.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
187
6.2 Regeln zum Entwurf von Klassen
Regel 4: Analysiere m:n-Beziehungen genau
 Hinter m:n-Beziehungen können sich leicht Probleme verbergen
 Hinter m:n-Beziehungen stecken oft eigenständige Klassen (vgl. Assoziationsklassen) oder auch Attribute, die in der Analyse nicht aufgetaucht sind
- entdeckt man solche Klassen oder Attribute erst in der Wartungsphase, entsteht
unerwünschter Aufwand, weil die Änderung mehrere Klassen betrifft
 Das gezielte Hinterfragen der m:n-Beziehung löst im Beispiel das Problem:
- "Gibt es irgendetwas das jeder einzelne Reisende für eine Reise braucht?" liefert
"Ja, für diverse Länder braucht man ein spezielles Visum" ( Reisevoraussetzung)
 Wandle m:n-Beziehungen um, wenn es sinnvoll erscheint
 Löse m:n-Beziehungen in (mehrere) 1:n-Beziehungen auf
 Füge dazu neue Klassen ein (vgl. Umsetzung von Assoziationsklassen in C++)
und finde fachlich passende Begriffe für die neuen Entitäten.
- Manchmal gibt es noch keinen Begriff für die neue Entität. Dieser sollte dann
zusammen mit der Fachabteilung festgelegt werden
- Häufig enthalten die neu entstehenden Entitäten weitere fachliche Informationen
(z.B. ein Datum).
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
188
6.2 Regeln zum Entwurf von Klassen
Weitere Regeln - eigentlich selbstverständlich, aber …
 Vermeide 1:1-Beziehungen
 Stehen zwei Entitäten in einer 1:1-Beziehung, so sollte man sie - sofern fachlich
sinnvoll - in eine Entität zusammenfassen. Das vereinfacht das Modell.
Beispiel: Auftrag und Auftragskopf  Auftrag
 Modelliere nur fachliche, nie technischen Aspekte
 Beispiel: Eine Entität "Liste" oder gar "VerketteteListe" gibt es nicht
(= Realisierung von x:n-Assoziation)
 Beschränke Dich auf das für das System Notwendige
 Beispiel: Sollen für einen Reisekatalog die Ausstattungen von Hotels (Pool,
Sauna, Tennis, etc.) modelliert werden, so sind nur die Kategorien relevant.
Irrelevant ist hier, dass Tennis eine Sportart ist, ob Pool und Saunabereich
aneinander grenzen etc.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
189
6.2 Regeln zum Entwurf von Klassen
Zusammenfassung der Regeln
 Regeln zum Entwurf von Klassen







Setze Vererbung sparsam ein
Normalisiere das Datenmodell
Vermeide transitive Assoziationen
Analysiere m:n-Beziehungen genau
Vermeide 1:1-Beziehungen
Modelliere nur fachliche, nie technischen Aspekte
Beschränke Dich auf das für das System Notwendige
 Diese Regeln geben konkrete Leitlinien zum Entwurf von
Klassen und deren Beziehungen !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
190
Hochschule Darmstadt
Fachbereich Informatik
Objektorientierte Analyse und Design
6.3 Entwurfsmuster
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
191
6.3 Entwurfsmuster
Muster (Patterns)
„Auf der Grundlage von
Erfahrung und der
Reflexion darüber...
...können wir
wiederkehrende
Muster erkennen ...
Einmal erkannte Muster
leiten unsere
Wahrnehmung.“
M.C. Escher: Luft und Wasser 8
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
192
6.3 Entwurfsmuster
Ein Problem aus der IT Welt
 Beispiel: Absatzformatierung in einer Textverarbeitung
 es gibt verschiedene Strategien um Absätze schnell oder schön zu formatieren
 neue Strategien sollen leicht einbaubar sein (am besten ohne Änderung in der
eigentlichen Textverarbeitung)
1. Idee: Implementiere die "Textverarbeitung" als eine Klasse mit einer abstrakten
Funktion "Formatiere()" und realisiere diese dann durch Spezialisierung!
TextVerarbeitung
Formatiere()
...
TextV_FormatiererA
TextV_FormatiererB
Formatiere()
Formatiere()
 dann entsteht eine Klasse für jede
Strategie
- wenn aber z.B. die
Rechtschreibkorrektur ebenfalls in
verschiedenen Verfahren existiert, dann
gäbe es für alle Kombinationen von
Formatierern und Korrekturen je eine
Klasse
z.B. TextV_FormatiererA_KorrekturA, …
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
193
6.3 Entwurfsmuster
Ein Problem aus der IT Welt (2. Versuch)
2. Idee: Die Textverarbeitung muss gar nicht "wissen", welche Formatierung (oder
Rechtschreibkorrektur) gewünscht ist – es reicht, wenn die Aufrufweise bekannt ist!
 Definiere eine einheitliche Schnittstelle für die austauschbaren Algorithmen
-
ein Interface mit einer Methode (z.B. Formatiere oder Rechtsschreibkorrektur)
 Jeder Algorithmus erbt diese Schnittstelle und implementiert sie
 Der gewünschte Algorithmus muss der Textverarbeitung bekannt sein
-
Realisierung als Aggregation (Pointer auf konkreten Formatierer)
formatierer
TextVerarbeitung
...
Repariere()
// soll formatieren
Repariere() verwendet:
pFormatiererobjekt->Formatiere()
«interface»
Formatierer
Formatiere()
EinfacherFormatierer
TeXFormatierer
ArrayFormatierer
Formatiere()
Formatiere()
Formatiere()
Frage: Wie kann hier Rechtschreibkorrektur integriert werden?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
194
6.3 Entwurfsmuster
Das Strategie-Muster
Struktur
strategie
Kontext
KontextSchnittstelle()
KonkreteStrategieA
AlgorithmusSchnittstelle()
«interface»
Strategie
AlgorithmusSchnittstelle()
KonkreteStrategieB
AlgorithmusSchnittstelle()
Schnittstelle definiert
eine Operation
KonkreteStrategieC
AlgorithmusSchnittstelle()
 Teilnehmer und Interaktionen:
 Kontext: Wird mit einem KonkreteStrategieX-Objekt konfiguriert, verwaltet eine
Referenz auf ein Objekt einer konkreten Strategieklasse und kann eine Schnittstelle
für den Zugriff auf seine Daten definieren.
 Strategie: Schnittstellendeklarationen für alle unterstützten Algorithmen
 Konkrete Strategie: Implementiert einen Algorithmus unter Verwendung der
Strategieschnittstelle
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
195
6.3 Entwurfsmuster
Das Strategie-Muster (Strategy Pattern)
 Konsequenzen:
 Strategien ersetzen Bedingungsanweisungen
 Bei Hinzufügung einer konkreten Strategie
- keine Änderung im Kontext (TextVerarbeitung)
- kleine Änderung bei der Instanziierung und Übergabe der Strategieklasse
 Beispielcode mit und ohne Strategieobjekt
void TextVerarbeitung::Repariere() {
mein_formatierer->Formatiere(...);
}
void TextVerarbeitung::Repariere() {
switch(_umbruchStrategie) {
case EinfacheStrategie:
FormatiereMitEinfacherStrategie(...);
break;
case TeXStrategie:
FormatiereMitTeXStrategie(...);
break;
// ...
}
}
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
196
6.3 Entwurfsmuster
Das Strategie-Muster - Beispielcode für die Absatzformatierung (1)
class TextVerarbeitung {
Hier wird die
public:
TextVerarbeitung(Formatierer*) { ....}; gewünschte
Strategie
void Repariere() {
// Vorbereitung der Übergabeparameter übergeben!
// der Formatiere-Funktion
mein_formatierer->Formatiere( ... );
// Darstellung gemäß der vom Formatierer
// berechneten und zurück gelieferten Daten
// ...
};
private:
Formatierer* mein_formatierer;
...
};
...
class Formatierer {
public:
virtual int Formatiere(... ) = 0;
protected:
Formatierer();
};
class ArrayFormatierer : public Formatierer {
public:
ArrayFormatierer(int breite);
...
virtual int Formatiere(...)
{
.......
}
// ...
};
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
197
6.3 Entwurfsmuster
Das Strategie-Muster - Beispielcode für die Absatzformatierung (2)
⇒ Instanziierung verschiedener KompositionsObjekte:
TextVerarbeitung* schnell =
new TextVerarbeitung (new EinfacherFormatierer);
TextVerarbeitung * schick =
new TextVerarbeitung (new TeXFormatierer);
TextVerarbeitung* icon =
new TextVerarbeitung (new ArrayFormatierer);
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
198
6.3 Entwurfsmuster
Das Strategie-Muster - Beispielcode für die Absatzformatierung (3)
Instanzen und Verzeigerungen für Beispiel
TextVerarbeitung* icon =
new TextVerarbeitung (new ArrayFormatierer);
Objekt der Klasse
icon-Pionter auf Objekt der
KlasseTextverarveitung
:Textverarbeitung
Repariere (...)
mein_formatierer-Pionter auf Objekt
der Klasse Arrayformatierer
Objekt der Klasse
:Arrayformatierer
Formatiere(...)
Aufruf:
icon->Repariere(...)
Repariere ruft auf:
mein_formatierer->Formatiere(...)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
199
6.3 Entwurfsmuster
Das Strategie-Muster: Eigenschaften (I)
 Zweck:
 Das Strategiemuster ermöglicht es, einen Algorithmus unabhängig von den ihn
nutzenden Klienten zu variieren
 es können sogar mehrere Algorithmen austauschbar gemacht werden
 Definiere eine Familie von Algorithmen, kapsele jeden einzelnen und mache sie
austauschbar
 Auch bekannt als:
 Policy
 Motivation:
 Es gibt unterschiedliche Algorithmen für ein spezielles Problem
 Es ist nicht wünschenswert, alle möglichen Algorithmen in einer Klasse fest zu
codieren
 Jeder Algorithmus wird als "Strategie" in einer Klasse gekapselt und ist über eine
(abstrakte) Superklasse, die eine geeignete Schnittstelle zur Verfügung stellt,
anwendbar
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
200
6.3 Entwurfsmuster
Das Strategie-Muster: Eigenschaften (II)
 Anwendbarkeit
 Viele verwandte Algorithmen unterscheiden sich nur in ihrem inneren Verhalten
 Unterschiedliche Varianten eines Algorithmus werden benötigt, z.B. mit
unterschiedlichen Vor- und Nachteilen bzgl. der Geschwindigkeit und des
Speicherplatzverbrauchs
 Daten, die für den Algorithmus relevant sind, aber dem Aufrufer nicht bekannt
sein sollen, können in einer Strategie „verborgen“ werden
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
201
6.3 Entwurfsmuster
Diskussion Strategie-Muster
 Vorteile beim Einsatz des Strategie-Musters
 Strategien können leicht hinzugefügt oder entfernt werden
 Der Aufruf wird nicht komplizierter, bloß weil es verschiedene Strategien gibt
 Nachteile
 Die Implementierung ist etwas schwieriger
 Diskussion:
 Ein Navigationssystem bietet Ihnen die schönste Route, die schnellste Route
oder auch die kürzeste Route. Wie würden Sie dies als Strategiemuster
umsetzen?
 Sie implementieren eine Klasse, die Daten sortiert. Vorerst implementieren Sie
aber nur Bubblesort und wollen dies später durch Quicksort ersetzen. Würden
Sie dazu ein Strategiemuster verwenden?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
202
6.3 Entwurfsmuster
Noch ein Problem aus der IT Welt: Observer-Muster (kennen Sie schon)
 Stellen Sie sich vor, Sie sollen die Systemuhr für ein modernes Betriebssystem
implementieren
 Polling (zyklische Abfrage) soll vermieden werden
 Bereitstellung der neuesten Zeit und des neuesten Datums
 Unterstützung für eine im Voraus nicht bekannte Anzahl von Interessenten
(Word, Tray-Clock, ...)
 Die Lösung soll möglichst übertragbar sein (z.B. für den Batteriestatus)
 Entwerfen Sie Komponenten mit Verantwortlichkeiten und Beziehungen
 Analysieren Sie folgende Szenarien
1. Die Uhrzeit ändert sich und soll (ohne Polling) angezeigt werden
2. Interessenten kommen während der Laufzeit hinzu (oder fallen weg)
3. Analoge Aufgabe: Ermitteln des Batteriestatus des Rechners
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
203
6.3 Entwurfsmuster
1. Die Uhrzeit ändert sich und soll (ohne Polling) angezeigt werden
Systemuhr
Datum
Zeit
gibStunde()
setzeStunde()
...
Zeit_Beobachter
UhrClient
Zeit
Zeitgeber
anzeigen()
aktualisiere()
 Idee: Drehe den Spieß um und "sage Bescheid", wenn sich die Zeit ändert!




Bei einer Zeitänderung ruft die Systemuhr beim UhrClient eine Methode auf
UhrClient besorgt sich dann von der Systemuhr die erwünschten Daten
Definiere dazu beim Client eine Methode aktualisiere()
kein Polling und dennoch immer die aktuelle Uhrzeit!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
204
6.3 Entwurfsmuster
2. Interessenten kommen während der Laufzeit hinzu (oder fallen weg)
realisiert durch list of * Beobachter
Systemuhr
Beobachter
Zeit_Beobachter *
Datum
Zeit
{abstract} aktualisiere()
gibStunde()
setzeStunde()
...
meldeAn(Beobachter)
meldeAb(Beobachter)
benachrichtige()
Zeit_Beobachter
UhrClient
Zeit
1 Zeitgeber
aktualisiere()
anzeigen()
 Idee: Alle Interessenten (UhrClients) "registrieren" sich bei der Systemuhr
 Bei einer Zeitänderung ruft die Systemuhr in ihrer Methode benachrichtige() bei
allen registrierten Clients die Methode aktualisiere() auf
 aber das geht nur, wenn alle UhrClients zu einer Klasse gehören!
 Einführung einer (abstrakten) Oberklasse ("Beobachter") und
Verschiebung der Assoziation
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
205
6.3 Entwurfsmuster
3. Analoge Aufgabe für den Batteriestatus des Rechners
Subjekt
meldeAn(Beobachter)
meldeAb(Beobachter)
benachrichtige()
Zeit_Beobachter *
Beobachter
Zeit_Beobachter *
aktualisiere()
Systemuhr
Datum
Zeit
1 Zeitgeber
gibStunde()
setzeStunde()
meldeAn(Beobachter)
...
UhrClient
Zeit
aktualisiere()
anzeigen()
 Idee: Das "Registrieren und Benachrichtigen" ist ein allgemeines Verfahren –
unabhängig von den bereitgestellten Daten
 Herausziehen dieses Teils durch Vererbung ("Subjekt") ... und fertig ist das
Beobachter-Muster
 Verschieben der Assoziation zum Benachrichtigen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
206
6.3 Entwurfsmuster
Ein anderes Problem mit der gleichen Lösung
 Mehrere Diagramme hängen von einem
gemeinsamen Datenobjekt ab
 Änderungen der Daten sollen in allen
Diagrammen angezeigt werden
 Die Anzahl der Diagramme ist variabel
Was ist Subjekt
was ist Beobachter?
Säule 1: ...........
Säule 2: a=50%
b=30%
c=20%
Säule 3: ..........
90
80
70
60
50
40
30
Säul e 1
Säul e 2
Säul e 3
20
10
0
 Dieses Problem taucht immer wieder auf!
 Das Design-Pattern Beobachter bzw.
Observer bzw. "publish-subscribe"
bietet eine allgemeine Lösung dafür!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
Se gme nt 1
Se gme nt 2
Se gme nt 3
207
6.3 Entwurfsmuster
Ein anderes Problem mit der gleichen Lösung
 es gibt eine Datenbasis ("Subjekt")
 es gibt mehrere "Beobachter"
 das Subjekt benachrichtigt die
Beobachter über Änderungen
90
80
70
60
Säule 1: ...........
Säule 2: a=50%
b=30%
c=20%
Säule 3: ..........
50
40
30
Säul e 1
Säul e 2
Säul e 3
20
10
0
1.) Benachrichtigung
über Änderung
Se gme nt 1
Se gme nt 2
Se gme nt 3
2.) Holen der
Veränderungen
(Aufruf gibt Zustand zurück)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
208
6.3 Entwurfsmuster
Beobachtermuster (Observer Pattern)
Beobachter
Subjekt
*
Beobachter
meldeAn(Beobachter)
meldeAb(Beobachter)
benachrichtige()
aktualisiere()
1
Subjekt
KonkretesSubjekt
subjektZustand
gibZustand()
setzeZustand()
abstrakt
KonkreterBeobachter
beobachteterZustand
daten-speichernde
Instanz
aktualisiere()
Säule 1: ...........
Säule 2: a=50%
b=30%
c=20%
Säule 3: ..........
daten-verwendende
Instanz
Bei Veränderung  benachrichtige(): für alle angemeldeten Beobachter b: {b->aktualisiere}
Nach Benachrichtigung  aktualisiere(): {beobachteter Zustand = subjekt->gibZustand}
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
209
6.3 Entwurfsmuster
Beobachtermuster (Observer Pattern): Aufrufverhalten
einKonkretesSubjekt:
konkretesSubjekt
einKonkreterBeobachter: einAndererKonkreterBeobachter:
konkreterBeobachter
konkreterBeobachter
setzeZustand()
benachrichtige()
aktualisiere()
gibZustand()
return(Zustand)
aktualisiere()
gibZustand()
return(Zustand)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
für jeden
angemeldeten
Beobachter
210
6.3 Entwurfsmuster
Beobachtermuster (Observer Pattern): Einsatz in der Modellierung
Beobachter
Subjekt
*
Beobachter
meldeAn(Beobachter)
meldeAb(Beobachter)
benachrichtige()
aktualisiere()
1
KonkretesSubjekt
Subjekt
abstrakt
KonkreterBeobachter
beobachteterZustand
subjektZustand
aktualisiere()
gibZustand()
setzeZustand()
 Ein Pattern ist eine (weltweit) bekannte Musterlösung!
 Bitte ordnen Sie die Klassen auch genau so an (evtl. als eigenes Diagramm)
 benennen Sie die Klassen Subjekt und Beobachter und Methoden auch so – passen Sie
nur die Parameter an
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
211
6.3 Entwurfsmuster
Beobachtermuster – Beispielcode Digitaluhr
Struktur:
Beobachter
Subjekt
*
Beobachter
meldeAn(Beobachter)
meldeAb(Beobachter)
benachrichtige()
aktualisiere()
1
Subjekt
DigitalUhr
Zeitgeber
subjektZustand
gibStunde()
...
setzeZustand()
beobachteterZustand
aktualisiere()
zeichne()
weitere mögl. Beobachter:
z. B. Kalender, Analoguhr
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
212
6.3 Entwurfsmuster
Beobachtermuster – Beispielcode Digitaluhr
class Subjekt{
public:
virtual ~Subjekt();
virtual void meldeAn(Beobachter*);
virtual void meldeAb(Beobachter*);
virtual void benachrichtige();
protected:
Subjekt();
private:
Liste<Beobachter*> _beobachter;
};
class ZeitGeber : public Subjekt {
public:
ZeitGeber();
virtual int gibStunde();
virtual int gibMinute();
virtual int gibSekunde();
void tick() {
// zählt um eine Sekunde hoch
benachrichtige() }
};
class Beobachter {
public:
virtual ~Beobachter();
virtual void aktualisiere(Subjekt*
geaendSubjekt)=0; // pure virtual
protected:
Beobachter()
};
void Subjekt::meldeAn(Beobachter* beobachter) {
_beobachter->haengeAn(beobachter); //Methode von Liste
}
void Subjekt::meldeAb(Beobachter* beobachter) {
_beobachter->entferne(beobachter);
}
void Subjekt::benachrichtige() {
ListenIterator<Beobachter*> iter(_beobachter);
for(iter.start(); !iter.istFertig(); iter.weiter())
{
iter.aktuellesElement()->aktualisiere(this);
}
};
class DigitalUhr: public Widget,
public Beobachter{
public:
DigitalUhr(ZeitGeber* subjekt){
_subjekt=subjekt;
_subjekt->meldeAn(this)};
virtual ~DigitalUhr(){...meldeAb(this)};
virtual void aktualisiere(Subjekt* geaendSubjekt){
... zeichne()};
virtual zeichne() {
int stunde=_subjekt->gibStunde; ... }
private:
ZeitGeber* _subjekt;
};
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
213
6.3 Entwurfsmuster
Diskussion Beobachtermuster
 Vor- und Nachteile beim Einsatz des Beobachter-Musters
 Beobachter können leicht hinzugefügt oder entfernt werden
 Es wird nur aktualisiert, wenn sich etwas geändert hat
 Wenn es nur wenige und feste Beobachter sind, ist es etwas komplizierter als
eine direkte Implementierung mit Abhängigkeiten
 Anwendungen:
 E-Mail Verteiler für SW-Updates (Benachrichtigung automatisch, Aktualisierung
manuell)
 Anzeige der Uhr in vielen Clients auf einem PC
 im Praktikum: Dosierer, Mischbehälter und Display beobachten die Waage
 Diskussion:
 Würden Sie bei einer (traditionellen) Kuckucksuhr den Kuckuck als Beobachter
der Uhr implementieren?
 Wie würden Sie in einem Autoradio implementieren, dass CD, Kassette, etc. bei
einer Verkehrsfunkdurchsage anhalten
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
214
6.3 Entwurfsmuster
Das Kompositum-Muster (Composite Pattern)
Zweck:
 Füge Objekte zu Baumstrukturen zusammen, um Teil-Ganzes-Hierarchien zu
repräsentieren.
 Ermöglicht es Klienten, sowohl
 einzelne Objekte (Blätter eines Baumes) als auch
 Kompositionen von Objekten (Nicht-Blatt-Knoten)
einheitlich zu behandeln (z. B. zeichne()).
Motivation:
 Aufbau komplexer Diagramme aus einfachen Komponenten, z. B. grafische
Anwendungen.
 Der Benutzer kann aus „elementaren“ Komponenten (Blätter eines Baumes)
größere Komponenten zusammenfügen und aus diesen wiederum größere
Komponenten etc.
 Idee: Ein Client sollte bei der Verwendung der Komponenten nicht differenzieren
müssen, ob es sich um eine elementare oder eine zusammengesetzte
Komponente handelt.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
215
6.3 Entwurfsmuster
Das Kompositum-Muster
Grafik
Zeichne()
FuegeHinzu(Grafik)
Entferne(Grafik)
GibKindobjekt(int)
1..*
rekursive Beziehung
Abbildung
Zeichne()
FuegeHinzu(Grafik)
Entferne(Grafik)
GibKindobjekt(int)
Zeichne(): für alle g in grafiken: g->Zeichne()
Linie
Zeichne()
Kreis
Zeichne()
eineAbbildung
grafiken
Text
Zeichne()
eine Abbildung1
einText1
eineLinie1
eineLinie2
einKreis1
einKreis2
eine rekursive Struktur aus Grafikobjekten
FügeHinzu(Graphik g): Füge g in Liste der Grafikobjeke ein (Liste,
die Teil-von-Beziehung realisiert)
Anwendbarkeit:
 Repräsentation von Teil-Ganzes-Hierarchien
 Klient soll in der Lage sein, die Unterschiede zwischen zusammengesetzten und
einzelnen Objekten zu ignorieren
 d. h. Klient soll alle Objekte im Kompositum einheitlich behandeln können.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
216
6.3 Entwurfsmuster
Das Kompositum-Muster
Struktur:
Klient
Komponente
Operation()
FuegeHinzu(Komp.)
Entferne(Komp.)
GibKindobjekt(int)
1..*
kindobjekte
einKompositum
einBlatt
Blatt
Operation()
Kompositum
Operation()
FuegeHinzu(Komp.)
Entferne(Komp.)
GibKindobjekt(int)
einBlatt
einBlatt
einKompositum
einBlatt
einBlatt
einBlatt
rekursive Struktur aus Komponenten
Teilnehmer:
 Komponente: Schnittstellendeklarationen / -Implementierungen von Defaultverhalten.
 Blatt:
Besitzt keine Kindobjekte,
definiert Verhalten für die primitiven Objekte in der Komposition.
 Kompositum: Definiert Verhalten für Objekte, die Kindobjekte haben,
speichert Kindobjektkomponenten,
implementiert entsprechende Operationen der Schnittstelle von Komponenten.
 Klient:
Manipuliert die Objekte in der Komposition durch Schnittstelle-Operationen von Komponenten.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
217
6.3 Entwurfsmuster
Das Kompositum-Muster
Interaktionen:
 Klienten verwenden Schnittstellen der Klasse Komponente, um mit Objekten der
Komponentenstruktur zu interagieren.
 Wenn Empfänger = Blatt
⇒ Direkte Abhandlung der Anfrage.
 Wenn Empfänger = Kompositum
⇒ Weiterleitung der Anfrage an Kindobjekte
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
218
6.3 Entwurfsmuster
Das Kompositum-Muster - Beispiel-Klassendiagramm
Geraet
Geräte (=Komponenten)
als Teil-GanzesHierarchien bzw.
EnthaltenseinHierarchien.
Karte
Leistung()
GesamtPreis()
DiscountPreis()
Leistung() ...
FuegeHinzu(Geraet*)
Entferne(Geraet*)
ErzeugeIterator()
FloppyDisk
ZusammengesetztesGeraet
Leistung()
GesamtPreis()
DiscountPreis()
Leistung() ...
FuegeHinzu(Geraet*)
Entferne(Geraet*)
ErzeugeIterator()
Bus
Leistung()
GesamtPreis()
DiscountPreis()
Rahmen
Leistung()
GesamtPreis()
DiscountPreis()
Gehaeuse
Leistung()
GesamtPreis()
DiscountPreis()
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
219
Das Kompositum-Muster - Beispielcode (1)
class Geraet {
public:
virtual ~Geraet();
const char* Name()
{return _name;}
virtual Watt Leistung();
virtual Betrag GesamtPreis();
virtual Betrag DiscountPreis();
virtual FuegeHinzu(Geraet*);
virtual Entferne(Geraet*);
virtual Iterator<Geraet*>*
ErzeugeIterator();
protected:
Geraet(const char*);
private:
const char* _name;
Betrag Einzelteil_Preis; ...
};
class FloppyDisk:public Geraet {
public:
FloppyDisk(const char*);
virtual ~FloppyDisk();
virtual Watt Leistung();
virtual Betrag GesamtPreis();
virtual Betrag DiscountPreis();
};
class ZusammengesetztesGeraet:
public Geraet {
public:
virtual ~ZusammengesetztesGeraet();
virtual Watt Leistung();
virtual Betrag GesamtPreis(); nächste Seite
virtual Betrag DiscountPreis();
virtual FuegeHinzu(Geraet*);
virtual Entferne(Geraet*);
virtual Iterator<Geraet*>*
ErzeugeIterator();
protected:
ZusammengesetztesGeraet(const char*);
private:
Liste<Geraet*> _teile;
};
class
Rahmen
class Gehaeuse:
public ZusammengesetztesGeraet {
public:
Gehaeuse(const char*);
virtual ~Gehaeuse();
//virtual Watt Leistung();
//virtual Betrag GesamtPreis();
//virtual Betrag DiscountPreis();};
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
220
Das Kompositum-Muster - Beispielcode (2)
class ZusammengesetztesGeraet:
public Geraet {
Betrag ZusammengesetztesGeraet::GesamtPreis() {
Iterator<Geraet*>* iter = ErzeugeIterator();
Betrag gesamt = 0;
public:
...
virtual Betrag GesamtPreis();
...
};
for (iter->Start(); !iter->IstFertig(); iter->Weiter())
gesamt += iter->AktuellesElement()->GesamtPreis();
delete iter;
return gesamt + Einzelteil_Preis;
}
Instanziierung
eines Baums:
...
Gehaeuse *gehaeuse = new Gehaeuse("PC Gehaeuse");
Rahmen *rahmen
= new Rahmen("PC Rahmen");
gehaeuse->FuegeHinzu(rahmen);
Bus* bus = new Bus("MCA Bus");
bus->FuegeHinzu(new Karte("16Mbs Token Ring"));
rahmen->FuegeHinzu(bus);
rahmen->FuegeHinzu(new FloppyDisk("3.5in Floppy"));
cout << "Der Gesamtpreis betraegt“ << gehaeuse->GesamtPreis()
<< endl;
...
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
221
6.3 Entwurfsmuster
Literatur zu Entwurfsmustern
Erich Gamma, Richard Helm, Ralph Johnson,
John Vlissides:
"Design Patterns – Elements of Reusable
Object-Oriented Software",
(Addison-Wesley, 1994)
deutsch: Entwurfsmuster 1996
-Beispiele des Skripts stammen aus diesem
Buch
Eric. Freeman & Elisabeth Freeman et.al.:
Entwurfsmuster von Kopf bis Fuß", O'REILLY, 2006
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
222
6.3 Entwurfsmuster
Fazit zu Entwurfsmustern
 Entwurfsmuster




bieten bewährte Lösungen für immer wiederkehrende Probleme im Design
sind als Lösung durch Literatur dokumentiert und international bekannt
machen einen Entwurf änderbar und flexibel
helfen, existierende SW-Entwürfe zu analysieren und zu reorganisieren
 Aber
 Entwurfsmuster machen das Design komplizierter und abstrakter
 es muss nicht jedes Problem mit einem Entwurfsmuster gelöst werden
 Entwurfsmuster sollten nur dann eingebaut werden, wenn die Flexibilität auch
tatsächlich benötigt wird
Hat man ein Problem einmal selbst gelöst, weiß man das entsprechende Pattern zu
schätzen - vorher versteht man leider oft nicht, warum die Lösung so gut ist !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
223
6.3 Entwurfsmuster
Arten von Mustern
 Architekturmuster (Architekturstile / Architectural Patterns)
 dokumentieren Entwurfserfahrungen, die sich auf globale Aspekte des Gesamtsystems
beziehen
 siehe Kapitel Architektur, z.B. 4-Schichten-SW-Architektur
 Entwurfsmuster (Design Patterns)
 machen lokale, sich auf wenige Klassen beziehende Entwurfserfahrungen der
Wiederverwendung zugänglich
 nur abstrakt (UML-Modelle)
 oft keine Implementierung
 Sie kennen Beobachtermuster, Strategiemuster, Kompositum-Muster
 Software Development Antipatterns
 demonstrieren häufig gemachte Entwurfsfehler (nächstes Kapitel)
 Rahmenwerke (Frameworks)




erlauben Wiederverwendung von ganzen Entwürfen
mit teilweiser Implementierung
umfassen wesentliche Aspekte einer Gruppe ähnlicher Anwendungssysteme
siehe Programmieren. Sie kennen: Visual C++, später: C++Unit
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
224
Hochschule Darmstadt
Fachbereich Informatik
Objektorientierte Analyse und Design
6.4 Anti Patterns
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
225
6.4 Anti Patterns
Software Development Anti Patterns
 While patterns help you to identify and implement procedures,
designs, and codes that work, Anti Patterns do the exact opposite;
(Brown, Malveau, McCormick, Mitp-Verlag 2004)
www.antipatterns.com/catalog.htm
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
226
6.4 Anti Patterns
The Blob - ein Beispiel
Library_Main_Control
Catalog
1
*
Topic
Inventory
...
Person
Name
User_ID
Items_Out
Fines
1
*
...
Funktionserfüllung
Zuverlässigkeit
Wartbarkeit
Erweiterbarkeit
Current_Catalog
Current_Item
User_ID
Fine_Amount
Etc.
...
Do_Inventory
Check_Out_Item(Item)
Check_In_Item(Item)
Add_Item(Item)
Delete_Item(Item)
Print_Catalog
Sort_Catalog
Search_Catalog(Params)
Edit_Item
Find_Item
Print
Open_Library
List_Catalogs
Issue_Library_Card
Archive_Catalogs
Calculate_Late_Fine
...
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
www.antipatterns
.com/catalog.htm
Item
1
*
Titel
ISBN
Author
Publisher
Cost
Date_In
Qty
etc.
...
Frage:
Was ist schlecht,
Was kann man
besser machen?
227
6.4 Anti Patterns
The Blob - ein Beispiel
 Typisch für den Blob ist eine Klasse, welche die gesamte Verarbeitung als
Monopol verwaltet, während andere Klassen primär die Daten kapseln
 fast die gesamte Verantwortung liegt bei einer einzelnen Klasse
=> unübersichtlich
 Im Klassendiagramm drückt sich dies dadurch aus, dass eine komplexe
„Controller Klasse“ umgeben ist von zahlreichen einfachen Datenklassen
 "fette Spinne im Netz"
 Im Grunde genommen entspricht der Blob einem prozeduralen Entwurf, der mit
Hilfe einer objekt-orientierten Sprache implementiert wird
 Was bedeutet das für die Entwurfsprinzipien ?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
228
6.4 Anti Patterns
The Blob - ein Software Development Anti Pattern
 Symptome
 Einzelne Klasse mit einer großen Anzahl von Attributen, Operationen oder beidem. Mehr
als 50 Attribute und Operationen => Blob!?
 Fehlendes objekt-orientiertes Design. Die einzige Controller-Klasse kapselt die gesamte
Funktionalität des Programms, ähnlich einer prozeduralen Main-Funktion
 Eine Klasse enthält eine Ansammlung der unterschiedlichsten Attribute und Operationen,
die keine Beziehungen untereinander haben (Trennung von Zuständigkeiten!)
 Eine einzige Controller-Klasse mit wenigen assoziierten, einfachen Daten-Objekt-Klassen
 Konsequenzen
 Der Blob begrenzt die Möglichkeiten, das System zu modifizieren ohne die Funktionalität
anderer, gekapselter Objekte zu beeinflussen (Geheimnisprinzip)
 Typischerweise ist der Blob zu komplex für Wiederverwendbarkeit und Tests. Es ist
nahezu ausgeschlossen, Untermengen der Funktionalität eines Blobs wieder zu verwenden
 Es kann aufwändig sein, eine Blob-Klasse in den Speicher zu laden, da sie exzessiv
Ressourcen verbraucht, selbst für einfache Operationen.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
229
6.4 Anti Patterns
The Blob - Lösungsansätze (I)
 Ziel einer Neustrukturierung ist es,
 Verhalten aus dem Blob herauszunehmen und gekapselten Datenobjekten
zuzuordnen.
- Im Beispiel kapselt die Library-Klasse die Summe aller System-Funktionalitäten.
 Identifiziere oder kategorisiere zusammengehörige Attribute und Operationen
- Die Zusammengehörigkeit sollte sich auf einen gemeinsamen Fokus, ein Verhalten
oder eine Funktionalität im Gesamtsystem beziehen.
- Wir sammeln Operationen, die Bezug haben zum Katalog-Management, wie
Sort_Catalog und Search_Catalog.
- Ebenso identifizieren wir alle Operationen und Attribute die Bezug haben zu einem
einzelnen Ausleiheobjekt, wie z.B. Print_Item, Delete_Item etc.
 Finde eine geeignete Oberstruktur für diese neuen Gruppierungen
(„natural homes“) um sie dort einzubinden.
- Im Beispiel sind dies die bereits vorhandenen Klassen Catalog und Item.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
230
6.4 Anti Patterns
The Blob - Lösungsansätze (II)
 Löse alle redundanten oder indirekten Beziehungen und ersetze sie durch direkte
Beziehungen. Im Beispiel betrifft dies die Beziehung zwischen Item und Library:
- Jedes Item steht zunächst in unmittelbarer Beziehung zu einem Katalog und nur über
diesen - also indirekt - auch in Beziehung zur gesamten Bücherei.
- Wir verzichten auf die Beziehung zwischen Item und Library und definieren die direkte
Beziehung zwischen Catalog und Item.
 Prüfe, ob assoziierte Klassen ggf. als Klassen erkannt werden können, die von
einer gemeinsamen Basisklasse abgeleitet sind
 Ersetze, füge hinzu: transiente*) Beziehungen und Beziehungsklassen
- durch Klassen, die die entsprechenden Attribute und Operationen kapseln.
- Im Beispiel entstehen bei diesem Schritt Klassen wie Checked_out_Item.
*)
transient: vorübergehend existierend
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
231
6.4 Anti Patterns
The Blob - die überarbeitete Lösung
Library_Main_Control
Person
Name
User_ID
Items_Out
Fines
...
0..1
*
1
Current_Catalog
Current_ItemFine_Amount
Etc.
...
Catalog
1
*
Do_Inventory
Search_Catalog(Params)
Print
Open_Library
Issue_Library_Card
Calculate_Late_Fine
...
Topic
Inventory
...
1
0..*
Item
Titel
ISBN
Author
Publisher
Cost
Date_In
Qty
...
Print_Catalog
Sort_Catalog
List_Catalogs
Archive_Catalogs
Checked-out-Item
Due_Date
 Verbesserte Wartung,
Modifizierbarkeit,
Wiederverwendbarkeit...
*
0..*
Check_In_Item
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
Check_Out_Item
1 Add_Item
Delete_Item
Edit_Item
Find_Item
232
6.4 Anti Patterns
Fazit zu Anti Patterns
 Der Blob




ist ein "beliebtes" Entwurfsprinzip bei Anfängern
einfache Kommunikation, einfache Zuständigkeit, einfache Realisierung...
erschwert aber Wartung, Modifizierbarkeit, Wiederverwendbarkeit etc.
kann leicht vermieden werden, wenn man das Anti Pattern kennt
 Regeln zum Umgang mit Anti Patterns (nach Hays W. McCormick)
 Anti Patterns veranschaulichen häufige Fehler und bieten bessere Ansätze
 Anti Patterns sind normale Lösungen, die den Stand der Entwicklung
widerspiegeln
- Manche Anti Patterns muss man tolerieren
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
233
6. Zusammenfassung Design
Kontrollfragen Design
 Was ist die Aufgabe des Designs?
 Welche Grundprinzipien für den Entwurf kennen Sie?
 Erkennen Sie in Ihrem Praktikumsentwurf von SWE Teile des Blob?
 Warum sollte man Design-Patterns verwenden?
 Wozu sind Anti Patterns gut?
 Woran erkennen Sie ein Design-Muster bei Ihrer Arbeit?
 Wann setzen Sie das Strategiemuster ein? Erklären Sie die Funktionsweise.
 Warum kann man Strategien nicht einfach als Vererbung umsetzen?

Woher wissen Sie welche Klassen und Operationen ihr Entwurf enthalten
sollte?
Können Sie jetzt einen guten Entwurf machen ?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
234
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
7. Implementierung
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
235
7. Implementierung
Einordnung im V-Modell
Anwendungsszenarien
Anforderungsdefinition
Testfälle
Grobentwurf
(SW-Architektur)
Feinentwurf
Testfälle
(Design)
Modul-Implementierung
Testfälle
Abnahmetest
Systemtest
Integrationstest
Modultest
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
236
7. Implementierung
Lernziel Implementierung
 Sie sollen in diesen Kapitel verstehen,
 wo der Unterschied zwischen Implementierung in "Programmieren I & II"
und Implementierung in "OOAD & SWE" liegt
 was Programmierrichtlinien festlegen
 warum Programmierrichtlinien wichtig sind
 warum Programmierrichtlinien unbeliebt sind
Anschließend wundern Sie sich nicht mehr, warum es in
einem großen Projekt so viele Regeln gibt!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
237
7. Implementierung
Implementierung
 In Programmieren I und II haben Sie gelernt
- Konzeption von Datenstrukturen und Algorithmen
- Strukturierung von Programmen
- Dokumentation der Lösung und der Implementierung
- Umsetzung der Konzepte in C++
- grobes Testen der entwickelten Programme
 allerdings für kleine Projekte in kleinen Teams
("Programmieren im Kleinen")
 Im Software Engineering geht es um "Programmieren im Großen"
 die erlernten Implementierungstechniken bleiben gültig
 aber die Randbedingungen ändern sich!
 Wartbarkeit und Beherrschung der Komplexität dominieren die Entwicklung!
Damit ein großes Projekt entwickelt werden kann,
müssen gemeinsame Spielregeln vereinbart werden!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
238
7. Implementierung
Bedeutung von Programmierrichtlinien
 Ziele





Zusammenarbeit in einem Projekt erleichtern
Integration und Test erleichtern
Langjährige Wartung ermöglichen
Zuverlässigkeit und Robustheit erhöhen
Steigerung der Effizienz der Entwicklung
 Richtlinien
 sind verbindlich für den Entwickler
 sollten nach Möglichkeit eingehalten werden
 werden bei Beauftragungen zur Auflage gemacht
 die Einhaltung der Richtlinien wird überprüft
 Abweichungen sind nur mit (guter) Begründung erlaubt
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
239
7. Implementierung
Exemplarischer Inhalt einer Programmierrichtlinie (mit Beispielen)
 Allgemeines
- Es ist nach dem ISO C++-Standard zu programmieren
 Kommentierung
- Jede Klasse muss am Ort ihrer Deklaration mit einem Kommentar eingeleitet werden,
der Name und Zweck der Klasse, Autor, Erstellungsdatum und Version sowie eine
Änderungsliste enthält
 Namenskonventionen
- Die C++-Schlüsselwörter sind als Symbolnamen (auch in Großbuchstaben) nicht
zulässig
 Deklarationen
- Bei paarweise existierenden Operatoren wie == und != muss, falls einer überladen
wird, auch der andere überladen werden
 Fehlerbehandlung
- Der Rückgabewert von new muss vor der ersten Verwendung geprüft werden
 Sonstiges
- Statt der Funktionen alloc() und free() sind new und delete zu verwenden
- Bei Bedarf sind die Standard-Datentypen string, vector und set zu verwenden
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
240
7. Implementierung
Inhalt einer Programmierrichtlinie: Weitere Themen
 Festlegung




der I/O-Methoden
der verwendeten Zeichensätze
von erlaubten Dateinamen
von Variablennamen mit Datentypen (z.B. uint32MyNumber)
 Regeln







zur Verwendung von Zeigern
zur Verwendung von Sichtbarkeiten / Zugriffsrechten
zum Umgang mit dem Preprozessor / Compiler-Warnungen
zum Aufteilung des Codes auf Dateien (z. B. eine h-Datei enthält eine Klasse)
zur Art der Fehlerbehandlung
zur Initialisierung von Variablen
zu Layout, Formatierung des Codes
 und vieles mehr – je nach Projekt und Bedarf!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
241
7. Implementierung
Vorteile einer Programmierrichtlinie
 Wartbarkeit
 erhöht die Verständlichkeit des Codes für Teammitglieder und Neulinge
 reduziert Bedarf an speziellem Fachwissen
 Integrierbarkeit
 Vermeidung von spät auffallenden Inkompatibilitäten von Bibliotheken
 Einheitliche Aufteilung des Codes auf Quellcode-Dateien
 Zuverlässigkeit
 klare Regeln zum Umgang mit fehlerträchtigen Konstrukten (z.B. Pointern)
 Robustheit
 Initialisierungsregeln, Zuweisungsregeln
 Testbarkeit
 Einheitliche Fehlerbehandlung
 Effizienz der Entwicklung
 Bietet eine Kommunikationsbasis
 Empfehlung von anerkannten / bewährten Elementen
 Vermeidung von bekannten fehleranfälligen Sprachkonstrukten
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
242
7. Implementierung
Nachteile einer Programmierrichtlinie
 Echte Nachteile:
 Einschränkung der Individualität des Entwicklers
 Gewöhnung an die vorgegebene Lösungen erforderlich
 beliebte Ausreden zur Umgehung:
 "Schönes Programmieren ruiniert die Performanz"
→ der Unterschied wird von heutigen Compilern weg-optimiert!
 "Kommentare in halbfertigem Code sind sinnlos"
→ grundlegende Entscheidungen wurden im Modell getroffen!
 "Die Anpassungen mache ich, wenn ich fertig bin"
→ das passiert dann nie
 Oft Widerstand – speziell von den "Programmier-Profis"
Die Richtlinien müssen als etwas Positives empfunden werden!
 Erstellung zusammen mit den Programmier-Profis
 unter Beteiligung aller Projektparteien
(Entwickler, Tester, Integratoren, Qualitätssicherung…)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
243
7. Implementierung
Kontrollfragen Implementierung
 Warum sind Programmierrichtlinien oft unbeliebt?
 Wie kann man den Widerstand der Entwickler reduzieren?
 Warum wird die Einhaltung von Regeln höher gewichtet als Effizienz, Stimmung
und Entwicklungsgeschwindigkeit?
 Was passiert in einem großen Projekt, wenn es keine Programmierrichtlinien
gibt?
 Wann treten erstmalig Probleme auf, wenn Sie eine andere String-Bibliothek
verwenden, als die in den Richtlinien vorgegebene?
Könnten Sie jetzt in einem Team an einem großen
Projekt mitarbeiten?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
244
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
8. Test und Integration
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
245
8. Test und Integration
Einordnung im V-Modell
Anwendungsszenarien
Anforderungsdefinition
Abnahmetest
Testfälle
Grobentwurf
(SW-Architektur)
Feinentwurf
(Design)
Modul-Implementierung
Testfälle
Testfälle
Testfälle
Systemtest
Integrationstest
Modultest
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
246
8. Test und Integration
Lernziel Test und Integration
 Sie sollen in diesen Kapitel verstehen





was ein Fehler ist
was Testen ist
wie man geschickt Testfälle auswählt
dass Black-Box und White-Box unterschiedliche Testmöglichkeiten bieten
welche Unterschiede es gibt zwischen Anweisungs-, Zweig-, Pfad- und
Bedingungsüberdeckung
 was Integration ist
 warum es im V-Modell 4 Testphasen gibt
 was in den einzelnen Testphasen zu tun ist
Anschließend können Sie systematisch Testfälle erstellen
und anwenden!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
247
8. Test und Integration
Was ist ein Fehler?
Ein Fehler ist eine Abweichung des tatsächlichen
Verhaltens vom erwarteten Verhalten
 Abstürze
 Datenverluste
 Fehlverhalten
 falsch implementierte Regeln / Berechnungen
 1. Ursache: Programmierfehler
- Lösung: Test der Programme
 2. Ursache: unzureichendes Verständnis der Sachverhalte
- Lösung: Nachfragen bei Unklarheiten, Missverständnissen bei Anforderungsanalyse und
während des Projektes -> Spezifikation präzisieren
- Beispiel: IsPrime(1) liefert false, der Test erwartet true – wer hat recht?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
248
8. Test und Integration
Was ist ein Fehler? (II)
 aber auch:
 unerfüllte Erwartungen (der Benutzer hat sich etwas anderes vorgestellt)
 mangelnde / unvollständige Kommunikation mit den Anwendern
- Lösung: Sorgfältige Anforderungsermittlung, Prototypen
 Schlechte Performance
 bei Anforderungsermittlung definiert
 auch: technische Machbarkeit prüfen
- Lösung: Performance-Prototypen, Performance-Tests
 Inkonsistente Benutzerschnittstellen




stören Arbeitsfluss
erzeugen Fehlbedienungen
verursachen geringe Akzeptanz
erzeugen hohen Schulungsbedarf
- Lösung: genauer spezifizieren,
Prototypen zum Testen der Verständlichkeit,
Einhaltung Regeln zur Ergonomie
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
249
8. Test und Integration
Wie findet man Fehler?
 Entwicklertests
 sollen zeigen, dass das Programm funktioniert
- "demonstratives" Testen
 überprüfen die Funktion der Software auf Korrektheit im normalen Betrieb
 werden vom Entwickler "freiwillig" durchgeführt
 das kennen Sie in beschränktem Umfang aus Ihrer Entwicklertätigkeit
 Robustheitstests
 überprüfen die Funktion der Software auf Korrektheit am Rande bzw. außerhalb
des normalen Betriebs
 werden oft von einem speziellen Test-Team durchgeführt
 versuchen systematisch Fehler aufzudecken
- "destruktives" Testen
 das kennen Sie in beschränktem Umfang von der Praktikumsabnahme in
Programmieren
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
250
8. Test und Integration
Grundidee Testen
 Ein Test(fall) zu einem Fehler erzeugt ein vom Soll-Ergebnis
abweichendes Ergebnis, wenn der Fehler vorliegt
Frage: Wie finde ich Soll-Ergebnis?
 Falls Ist-Ergebnis = Soll-Ergebnis => dieser Testfall ist richtig abgelaufen und der
Fehler liegt nicht vor
 Falls Ist-Ergebnis != Soll-Ergebnis => es liegt mindestens ein Fehler vor
Teste alle möglichen
Eingabekombinationen
Frage: Was halten Sie von diesem Konzept? Ist das möglich?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
251
8. Test und Integration
Grenze des Testens
Frage: Zeit für Test eines Multiplizier-Verfahrens für 2 Zahlen a 32 Bit
( 0*1, 1*0, 0*2, ..) bei Testgeschwindigkeit von 109 Tests/Sek
 264 ≈ 1,8 * 1019 verschiedene Eingaben
 Ein Testdurchlauf: 585 Jahre !
ohne Herleitung Sollergebnisse und Vergleich mit den Sollergebnissen
(Für einen Multiplizierer für 64-Bit-Zahlen: 10,8 Trilliarden Jahre !)
Wähle "geschickte" Stichproben !
 Aber: Durch Testen kann in der Regel nicht die Fehlerfreiheit der Software
nachgewiesen werden
 Sondern: Testen kann nur Zuverlässigkeit verbessern
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
252
8. Test und Integration
Auswahl von Testfällen
 Wie finde ich "geschickte Stichproben" (Testfälle),
so dass mit großer Wahrscheinlichkeit viele Fehler entdecket werden?
Für Bereiche, die sich gleich verhalten sollte ein Test
durchgeführt werden.
Teste an den Stellen wo erfahrungsgemäß besonders häufig
Fehler gemacht werden.
 Bilde „Bereiche gleichen Verhaltens“ ("Äquivalenzklassen„) und führe
Test für je einen "Vertreter„ durch
 Fehler werden meist da gemacht, wo sich etwas ändert!
=> teste an den Grenzen
- von Äquivalenzklassen, von Schleifen, in Bedingungen
- In der Mitte eines Bereichs gibt es kaum Fehler
 Ergänze durch "Intuitive Testfälle" (Erfahrung)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
253
8. Test und Integration
Kontrollfragen zum Test
 Wann ist ein Programm oder eine Funktion fehlerfrei?
 Ist es normalerweise möglich alle Testfälle laufen zu lassen?
 Was kann man tun um die Anzahl der Testfälle zu reduzieren?
 Können wir die Fehlerfreiheit durch Testen nachweisen?
 Wie erreichen wir, dass die Zuverlässigkeit nach dem Test möglichst hoch ist?
 Wo treten besonders häufig Fehler auf und wie wählt man geschickt Testfälle
aus?
... und was ist eigentlich ein Testfall genau?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
254
8. Test und Integration
Inhalt eines Testfalls
 Ein Testfall ist ein Durchlauf durch das Programm.
 Erzeugt er ein vom Soll-Ergebnis
abweichendes Ergebnis => es liegt ein Fehler vor
 Aber:
 Ein Testfall muss den Test genau spezifizieren
=> die Durchführung muss immer das gleiche Ergebnis liefern!
Frage: z. B. Erstellung Angebot Eingabe: 3 Wasserkocher: Summe ist 30 €, beim
Test in 3 Wochen: Summe ist 33 € - Warum?
Frage: Beim Geld abheben gebe ich ein: 500 €, aber es kommt kein Geld raus!
Warum? Liegt hier ein Fehler vor?
 Auch der Zustand – sowohl vor dem Test als auch nach dem Test - muss
vollständig beschrieben werden
 Ein Testfall wird beschrieben durch ein Paar:
(Eingangszustand, Eingabe) → (Sollausgabe, Sollzustand nach dem Test)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
255
8. Test und Integration
Was muss bei der Spezifikation eines Testfalls angegeben werden?







Eingabe-/Rückgabe-Parameter einer Funktion
Daten, die über Bildschirm ein- und ausgegeben werden
Daten, die gelesen und geschrieben werden, z.B. von / in
Datenbanken,
Sensoren, externe Geräte (evtl. zu simulieren -> replizierbare Ergebnisse )
Globale Variablen, die vom zu testenden Programm gelesen / geschrieben werden.
Attribute von Klasseninstanzen, die vom zu testenden Programm gelesen /
geschrieben werden.
 Rückgabeparameter von aufgerufenen Unterfunktionen
 Auch der Zustand des zu testenden Programms ist vollständig zu beschreiben
– sowohl vor dem Test als auch nach dem Test
Ein Testfall wird beschrieben durch ein Paar:
(Eingangszustand, Eingabe) → (Sollausgabe, Sollzustand nach dem Test)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
256
8. Test und Integration
Varianten von Testobjekten
Es gibt 2 grundlegende Varianten:
 Black-Box
Spezifikation




Das zu testende Modul ist ein "schwarzer Kasten"
Die innere Struktur ist für den Tester unbekannt
Interne Zustände des Moduls sind nicht sichtbar
Man sieht nur die Oberfläche (das "Was"),
d.h. die Modulspezifikation. Nur daraus können Testfälle abgeleitet werden.
 z.B. externe Software-Zulieferungen als Object-File oder Abnahmetest
 White-Box
 Man schaut in den Kasten hinein
 Die innere Struktur (das "Wie") des Programms
wird zur Überprüfung hinzugezogen
 z.B. Eigenentwicklungen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
Methoden
Zweige
257
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
8.1.1 Black-Box-Test
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
258
8.1.1 Black-Box-Test
Spezifikation
f(x)
Beispiel
+1
Über den float-Zahlen sei folgende Fkt. definiert:
f(x)=sin(x)
f(x)=1
für 0° ≤ X ≤ 360°
für x > 360°
0
0°
90°
270°
360°
x
-1
1. Äquivalenzklassen
 Es gibt vier Klassen von Eingaben: [-∞,0°[; [0°,360°] ;]360°, ∞] und Eingabe ∉ float (falls
diese Eingabe möglich)
(gültige Äquvalenzklassen sind abgeleitet aus den Fallunterscheidungen (hier jeder Zeile) der
Spezifikation plus zwei ungültige Äquivalenzklassen)
 Teste einen Vertreter in jeder Klasse!
2. Grenzwerte
 An den Rändern passieren "gerne" Fehler
 Teste die Grenzwerte jeder Äquivalenzklasse!
3. Erfahrung, intuitive Tests
 Der Sinus für 90°-270° wird oft aus dem Sinus von 0°-90° berechnet,
um Speicherplatz zu sparen!
 Teste in jedem Sinus-Segment durch einen Vertreter, ob die Berechnung stimmt
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
259
8.1.1 Black-Box-Test
Spezifikation
Reduzierung der Tests durch Bildung von Äquivalenzklassen
 Bilden von Äquivalenzklassen
 Einteilung der Menge der möglichen Werte zu einer Eingabe (z. B. Parameter) /
einem Eingabezustand (z. B. das Ergebnis beeinflussendes Attribut der Klasse)
in Äquivalenzklassen)
 Annahme: Das Testobjekt reagiert bei der Verarbeitung eines Vertreters aus
einer Äquivalenzklasse "genauso" wie bei allen anderen Werten dieser
Äquivalenzklasse,
d.h. läuft das Testobjekt mit dem Repräsentanten der Äquivalenzklasse fehlerfrei,
dann läuft es auch mit allen anderen Werten dieser Äquivalenzklasse fehlerfrei
 Beim “Äquivalenzklassentest“ testet man das System mit jeweils einem
Repräsentanten pro Äquivalenzklasse
 Es gibt
- gültige Äquivalenzklassen (mit gültigen Eingabewerten) und
- ungültige Äquivalenzklassen (mit ungültigen Eingabewerten)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
260
8.1.1 Black-Box-Test
Spezifikation
Äquivalenzklassen: Beispiel Dreieck (I)
 Spezifikation der Funktion "Dreieck":
 DREIECKTYP dreieck (SEITE1 int, SEITE2 int, SEITE3 int);
mit Rückgabewert enum DREIECKTYP {NORMAL, GLEICHSCHENKLIG,
GLEICHSEITIG, KEIN_DREIECK};
 Zweck:



SEITE1, SEITE2 und SEITE3 sind die Seitenlängen eines Dreiecks
Die Seitenlängen seien positive Werte
Die Funktion stellt fest, ob es sich um ein
-

einfaches (normales),
ein gleichschenkliges,
ein gleichseitiges oder
um gar kein Dreieck handelt
Zulässige Eingabewerte seien die positiven ganzen Zahlen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
261
8.1.1 Black-Box-Test
Spezifikation
Äquivalenzklassen: Beispiel Dreieck (II)
 KEIN_DREIECK, wenn // 2 Seiten zusammen kürzer sind als die 3. Seite
((SEITE1 + SEITE2) <= (SEITE3)) or
((SEITE1 + SEITE3) <= (SEITE2)) or
Frage: Wie sehen die
((SEITE2 + SEITE3) <= (SEITE1)), sonst
Äquivalenzklassen
und Testfälle aus?
 GLEICHSEITIG, wenn // 3 Seiten gleich
SEITE1 == SEITE2 == SEITE3, sonst
 GLEICHSCHENKLIG, wenn // Dreieck, bei dem 2 Seiten gleich, 3. verschieden
((SEITE1 == SEITE2) and (SEITE1 != SEITE3)) or
((SEITE1 == SEITE3) and (SEITE1 != SEITE2)) or
((SEITE2 == SEITE3) and (SEITE2 != SEITE1)), sonst
 EINFACH, wenn // Dreieck, bei dem alle Seiten verschieden
(SEITE1 != SEITE2) and (SEITE1 != SEITE3) and (SEITE2 != SEITE3)
Frage: können wir nicht einfach sagen: Gemäß mathematischer Definition?
 Notwendigkeit einer formalen Spezifikation:
 Gemäß der Mathematik beinhalten gleichschenklige Dreiecke gleichseitige Dreiecke.
 Die obige Spezifikation von GLEICHSCHENKLIG definiert abweichend von der
mathematische Definition: Bei GLEICHSCHENKLIG müssen zwei Seiten ungleich sein,
also disjunkte Aufteilung der Menge der Dreiecke!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
262
8.1.1 Black-Box-Test
Spezifikation
Äquivalenzklassen: Beispiel Dreieck (III)

Welche Äquivalenzklassen ergeben sich auf Grund der Spezifikation?
 Äquivalenzklasse 1 :
Zahlen für die kein Dreieck konstruiert werden kann
(eine Seitenlänge länger oder gleich der Summe der beiden
anderen Seiten), Soll-Ergebnis: KEIN_DREIECK
Repräsentant : 1,2,5
 Äquivalenzklasse 2 :
3 gleiche Zahlen, Soll-Ergebnis: GLEICHSEITIG
Repräsentant : 3,3,3
Alle folgenden Äquivalenzrelationen sind nicht KEIN_DREIECK mit folgenden zus. Bed.
 Äquivalenzklasse 3a : 1. und 2 Zahl gleich, 3. ungleich, Soll-Ergebnis: GLEISCHENKLIG
Repräsentant : 3,3,4
 Äquivalenzklasse 3b : 1. und 3 Zahl gleich, 2. ungleich, Soll-Ergebnis: GLEISCHENKLIG
Repräsentant : 3,4,3
 Äquivalenzklasse 3c : 2. und 3 Zahl gleich, 1. ungleich, Soll- Ergebnis: GLEISCHENKLIG
Repräsentant : 4,3,3
 Äquivalenzklasse 4 :
alle Zahlen ungleich, Soll-Ergebniss: EINFACH
Repräsentant : 4,2,3
 Äquivalenzklasse 5:
fehlerhafte Eingabewerte, Soll-Ergebnis: Typfehler (falls Eingabe mögl.)
Repräsentant: -1,-15,0 (ungültige Äquivalenzklasse)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
263
8.1.1 Black-Box-Test
Spezifikation
Regeln für Äquivalenzklassen
Folgende Regeln sollten beachtet werden:
 Falls Eingabetyp = Wertebereich,
z. B. Tage = (1 . . 31)
 eine gültige Äquivalenzklasse (1 ≤ Tage ≤ 31)
 zwei ungültige Äquivalenzklassen (Tage < 1, Tage > 31)
 Ist anzunehmen, dass Elemente einer Äquivalenzklasse unterschiedlich
verarbeitet werden
z. B. Gleichschenkliges Dreieck
 evtl. Aufteilung in schmalere Äquivalenzklassen
 Falls Eingabetyp = Aufzählungstyp
z. B. Zahlungsart = (Scheck, Überweisung, bar)
 für jeden Wert eine gültige Äquivalenzklasse (mit einem Repräsentant)
 und eine ungültige Äquivalenzklasse (z.B. Zahlungsart = gemischt)
 Falls durch den Eingabetyp Eingabebedingungen beschrieben werden
z. B. erstes Zeichen muss Buchstabe sein
 eine gültige Äquivalenzklasse (1. Zeichen = Buchstabe)
 eine ungültige Äquivalenzklasse (1. Zeichen = kein Buchstabe)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
264
8.1.1 Black-Box-Test
Spezifikation
Kombination von Äquivalenzklassen
 Wie ist zu testen, falls mehrere Eingabewerte / -zustände existieren und zu
jedem Eingabewert / -zustand mehrere Äquivalenzklassen existieren?
 Bilde das Kreuzprodukt der Äquivalenzklassen (~ N-dimensionaler Raum)
 Kombinationen aller kombinierbaren Repräsentanten
 z.B. bei 2 Eingabevariablen ergeben sich max. n * m Testläufe
 mit n, m = Anzahl der Äquivalenzklassen der Eingabevariablen
oft weniger, da
 ungültige Äquivalenzklassen zu einem Eingabewert oft nur einmal getestet
werden müssen, da unabhängig von anderen Eingabewerten
(z. B. direkter Abbruch unabhängig von anderen Werten)
 Auch Eingabewerte von gültige Äquivalenzklassen können unabhängig von
anderen Werten sein
 zwischen n * m und n + m Testläufen
 falls zu viele Testläufe
 Einschränkung auf Teilmenge der Eingabewertekombinationen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
265
8.1.1 Black-Box-Test
Spezifikation
Ergänzung der Tests durch die Grenzwertanalyse
 Unterscheidung zum Äquivalenzklassentest
 Nicht irgendein Element aus der Äquivalenzklasse wird als Repräsentant
ausgewählt, sondern ein oder mehrere Elemente, so dass jeder Rand der
Äquivalenzklasse getestet wird bezüglich der
- Eingabewerte / -zustände und
- Ausgabewerte / -zustände
 Testfälle decken die Grenzwerte der Äquivalenzklassen ab
 Erhöhung der Quote der gefundenen Fehler
 Nur sinnvoll, wenn Elemente einer Äquivalenzklasse auf natürliche Weise
geordnet sind, z.B.: Tage - aber nicht Zahlungsart
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
266
Spezifikation
Beispiel veränderte Sinusfunktion
f(x)=sin(x)
für 0° ≤ X ≤ 360°
f(x)=1
für x > 360°
f(x)
+1
0
0°
90°
270°
360°
x
-1
1.) Äquivalenzklassen
 Es gibt zwei gültige Klassen von Eingaben: [0°,360°] ; ]360°, ∞]. Es gibt zwei
Klassen von ungültigen Eingaben: [-∞,0°[ ; Eingaben ∉ float
 Teste einen Vertreter in jeder Klasse. -1; 180; 370; „a“
2.) Grenzwerte
 Eingaben zu Eingabegrenzwerten: 0; 360; 360,0001; -0,0001
(evtl. auch größte / kleinste darstellbare Zahl – abh. v. Rechner!! Ergebnis auch
noch im gültigen Zahlenbereich?)
 Eingaben zu Ausgabegrenzwerten: 90 (zu max(f(x)=1); 270 (zu min(f(x)=-1)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
267
Spezifikation
Beispiel X-Quadrat: f(x) = x2 für x ist Integer
 1.) Äquvalenzklassen: gültig: [-∞, ∞ ]; ungültig: Eingaben ∉ integer (falls diese Eingabe möglich)
Representanten: 6; „a“
2.) Grenzwerte:
0 (Ausgabegrenzwert)
 zus. zu beachten:
 Ist Ausgabewert im Typ des Ausgabewerts darstellbar? (< Max(Ausgabetyp)?).
 Weitere ungültige Äquivalenzklasse?
 (Ja,) Äquivalenzklassen bezüglich maximal darstellbarer Zahlenwerten für die Ausgabe (Eingabe)
(Max(Ausgabetyp) ist abhängig vom Rechner!)
 => Falls Ausgabewert vom Typ Integer:
1.) Äquvalenzklassen:
gültig:
[-int(sqr(MAX_INT)), +int(sqr(MAX_INT))] - ansonsten ist x2 > MAX_INT
ungültig: Eingabe ∉ integer; [-∞, -int(sqr(MAX_INT))-1] ; [int(sqr(MAX_INT))+1, +∞]
Representanten: 6; „a“; int(-sqr(5 345 432 100)); int(sqr(5 345 432 100))
2.) Grenzwerte?
gültig:
-int(sqr(4 294 967 296)); int(sqr(4 294 967 296)); 0 (Ausgabegrenzwert)
ungültig: -int(sqr(4 294 967 296))-1; int(sqr(4 294 967 296))+1;
(„x ∉ integer“ ist nicht geordnet => kein Grenzwert!);
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
268
8.1.1 Black-Box-Test
Spezifikation
Ergänzung der Tests durch Intuitive Testfallermittlung
 Ein erfahrener Tester kennt die "beliebten" Fehler und Umsetzungsvarianten der
Entwickler!
 der Tester macht Annahmen über die (wahrscheinliche) Umsetzung innerhalb
der Black-Box und ergänzt die Testfälle entsprechend
 Oft findet man dabei Spezialfälle, die auch bei der Spezifikation übersehen
wurden (vgl. IsPrime(1))
 Zum Finden von intuitive Testfällen sollten Tester und Entwickler
unterschiedliche Personen sein
 Beispiele






Wert 0 (bei Ein- / Ausgabewerten)
Steuerzeichen in Zeichenketten
Kein Eintrag oder leerer Eintrag bei Tabellenverarbeitung
Einlesen von Kommazahlen in Integerfelder
Gleichzeitiges oder andauerndes Drücken von Tasten
…
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
269
8.1.1 Black-Box-Test
Spezifikation
Beispiel Fakultät
 Entwickeln Sie die Testfälle
 nach der Methode des Äquivalenzklassentests
 nach der Methode der Grenzwertanalyse
 Ergänzen Sie intuitive Testfälle
 FAK(n) {...} , n=integer
Berechnung der Fakultät : n! = n * (n-1) *...3*2*1
 Unsere Funktion FAK(n) sei (abweichend von der math. Def.) folgendermaßen
definiert:
 FAK(n) = -1
wenn n < 0

1
wenn n = 0 or n = 1

n* FAK(n-1)
sonst
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
270
8.1.1 Black-Box-Test
Spezifikation
Beispiel Fakultät: Lösung
 Äquivalenzklassen
 gültige Klassen:
[-∞,0[ ; [0,1] ; ]1, ∞].
 ungültige Klassen:
Eingabewert ∉ ganze Zahlen
 Testfälle: (-5,-1); (0,1); (5, 120); (1.5, UNDEF)
 nach der Methode der Grenzwertanalyse
 Testfälle: (-1,-1); (0,1); (1,1); (2,2);
Bei Ausgabewert
Überschreitung des
Zahlenbereichs?
⇒ andere Klasseneinteilung mit
Berücksichtigung
von MAX_INT
 Intuitive Testfälle
 Die Funktion wächst so schnell, dass die Berechnung oft durch eine Wertetabelle
ersetzt wird (FAK(13)>MAX_INT, FAK(21)>MAX_LONG).
 Eingabefehler können in jedem Wert auftreten
 Totaler Test möglich! => Teste jeden einzelnen Wert bis zur maximalen Größe
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
271
8.1.1 Black-Box-Test
Spezifikation
Beispiel Fakultät: Lösung bei Eingabe, Ausgabe = Integer
 Äquivalenzklassen
 gültige Klassen:
[-∞,0[ *) ; [0,1] ;
 ungültige Klassen:
nicht ganze Zahlen; [13,+ ∞].
]1, +12].
 Testfälle: (-5,-1); (0,1); (5, 120); (1.5, UNDEF); (13,UNDEF).
 nach der Methode der Grenzwertanalyse
 Testfälle: (-1,-1); (0,1); (1,1); (2,2); (12,479001600); (13,UNDEF).
Bei Ausgabewert
Überschreitung des
Zahlenbereichs?
⇒ andere Klasseneinteilung mit
Berücksichtigung
von MAX_INT
*) bei Eingabewert = -∞, + ∞ kann natürlich nur maximal -MAX_INT, +MAX_INT eingegeben werden -> Grenzwert?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
272
Spezifikation
8.1.1 Black-Box-Test
Black-Box-Test – Beispiel Suchen in Liste
Zu testende Funktion: void suche (int Wert, int & Nr_des_Elementes) in der Klasse Liste
in der Klasse Liste
Eingabewert: Integer-Wert, Eingabezustand: Liste.
Ausgaben: Nr. des gefundenen Elements (int). Falls nicht gefunden: -1
class Liste
{...
void suche (int Eingabe, int &Nr_des_Elementes) ...
void anfuege (int Element) ...
}
Welche Äquivalenzklassen (abhängig von welchen Werten)?
Welche Testfälle?
Wie sieht das Testprogramm aus?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
273
Spezifikation
8.1.1 Black-Box-Test
Black-Box-Test – Beispiel Suchen in Liste
Zu testende Funktion: void suche (int Wert, int &Nr_des_Elementes) in der Klasse Liste
Welche Äquivalenzklassen (abhängig von welchen Werten)?
Welche Testfälle?
Eingabe:
- Listenlänge = 1 (Ein Wert in Liste) (Intuitiv) u.
- (eingegebener) Wert in Liste (hier: 6) (Grenzwert der Ausgabe : Nr_des_Elementes=1)
- Wert nicht in Liste (hier: 7) (Ausgabe: Nr_des_Elementes=-1)
- Listenlänge länger als 1 (hier: Einträge in Liste: 6,4,3,2) und
- Wert = erstes Element der Folge (hier: Wert = 6) (Grenzwert der Ausgabe (Nr_des_El..))
- Wert = mittleres Element der Folge (hier: . 2. Element, Wert = 4)) (intuitiv)
- Wert = letztes Element der Folge (hier: Wert = 2) (Grenzwert der Ausgabe (Nr_des_El..))
- Wert nicht in Folge (hier: Wert = 10) (Ausgabe: Nr_des_Elementes=-1)
- Listenlänge = 0 (Grenzwert des Eingabezustands (Listenlaenge)) und
- Wert nicht in Liste (hier: 6)
- unabhängig von Listenlänge
- Wert ein Character (hier: ‘W‘)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
274
Spezifikation
8.1.1 Black-Box-Test
Black-Box-Test – Beispiel Suchen in Liste
Zu testende Funktion: void suche (int Wert, int &Nr_des_Elementes) in der Klasse Liste
Wie sieht das Testprogramm aus?
//Testprogramm zu Testfall 1
...
Liste dieListe;
dieListe.anfuege(6);
int Nr_des_Elementes;
dieListe.suche (6, Nr_des_Elementes);
if not Nr_des_Elementes ==1
cout <<Testfall 1 mit Fehler;
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
275
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
8.1.2 White-Box-Test
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
276
8.1.2 White-Box-Test
White-Box-Test
 Alternative Begriffe: Glas-Box-Test, Strukturtest
 Man schaut in den Kasten hinein
 Die innere Struktur (das "Wie") des Programms wird zur Überprüfung
hinzugezogen
 (Zusätzliche) Testfälle werden aus der inneren Struktur abgeleitet
Es wird – je nach Testziel - geprüft,
 ob alle
- Anweisungen,
- Zweige,
- Pfade
des Programms durchlaufen werden bzw.
Auch für eine White-Box
können Blackbox-Tests
angewendet werden!
ob alle
- Teilausdrücke von zusammengesetzten Bedingungen mindestens einmal true und
einmal false sind
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
277
8.1.2 White-Box-Test
Codebeispiel
ergebnis= -1
int fak (x) {
ergebnis = -1;
if (x >= 0) {
ergebnis = 1;
for (i=2; i <= x; i++) {
ergebnis = ergebnis * i;
}
}
// else { }
return ergebnis;
}
ELSE
IF (x>=0)...
THEN
ergebnis= 1
FOR ...
erg = erg * i
ENDOFFOR
ENDIF
RETURN
Frage: Was ist vollständige
Anweisungsüberdeckung?
Kontrollflussgraph / gerichteter Programmgraph
der Berechnung der Fakultät
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
278
8.1.2 White-Box-Test
Testziele (I)
ergebnis= -1
 Vollständige Anweisungsüberdeckung
 Jede Anweisung des zu testenden
Programms wird mindestens einmal
ausgeführt
 Bedeutung:
Wichtig für Laufzeitfehler (z.B.
Speicherübergriffe, uninitialisierte
Variablen etc.)
ELSE
IF (x>=0)...
THEN
ergebnis= 1
FOR ...
erg = erg * i
ENDOFFOR
Frage: Wie viele Testfälle?
Was gebe ich als Parameter ein?
ENDIF
RETURN
Was ist Zweigüberdeckung?
Kontrollflussgraph / gerichteter Programmgraph
der Berechnung der Fakultät
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
279
8.1.2 White-Box-Test
Testziele (II)
ergebnis= -1
 Vollständige Zweigüberdeckung
 Jeder Zweig des Programms wird mindestens
einmal durchlaufen
 Zweig = Kante (
) im gerichteten
Programmgraphen
 Ein gerichteter Programmgraph, ist ein Graph,
der jeden möglichen Kontrollfluss des Programms
enthält (z. B. Programm-Ablauf-Plan(PAP),
Aktivitätsdiagramm)
 Ein If hat in dieser Darstellung immer einen Thenund einen Else-Zweig (auch wenn dieser im Code
nicht explizit angegeben wurde)
 Frage: Unterschied zu Anweisungsüberdeckung?
Die Zweigüberdeckung testet zusätzlich "leere"
Else-Zweige
Frage: Wie viele Testfälle?
Was gebe ich als Parameter ein?
Was ist Pfadüberdeckung?
ELSE
IF (x>=0)...
THEN
ergebnis= 1
FOR ...
erg = erg * i
ENDOFFOR
ENDIF
RETURN
Kontrollflussgraph / gerichteter Programmgraph
der Berechnung der Fakultät
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
280
8.1.2 White-Box-Test
Testziele (II)
 Vollständige Pfadüberdeckung
 Jeder Pfad im Ablauf des Programms wird mindestens einmal durchlaufen
 Pfad = Weg durch den "Ausführungsbaum" von seinem Anfang bis zu einem
Ende
- Der Ausführungsbaum enthält alle möglichen Abläufe im Programm
- Schleifen werden mehrfach durchlaufen.
- Beispiel: Ein Programm mit einer Schleife, die 1 bis 3 Mal durchlaufen werden kann,
muss zumindest 3 Mal getestet werden, so dass die Schleife beim 1. Testlauf 1 Mal,
beim 2. Testlauf 2 Mal und beim 3. Testlauf 3 Mal durchlaufen wird.
 Bedeutung:
Sehr gründliche Tests, aber schnell sehr große Menge an Testfällen. (Falls eine
Schleife beliebig oft durchlaufen werden darf, bräuchten wir unendlich viele
Testfälle!)
Frage: Bei Funktion fak(n):
Wie viele Testfälle? Was gebe ich ein?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
281
8.1.2 White-Box-Test
Pfadüberdeckung
ergebnis= -1
ergebnis= -1
ergebnis= -1
ELSE
a
IF (x>=0)...
IF (x>=0)...
ELSE
THE
N
THE
N
ergebnis= 1
ergebnis= 1
ELSE
IF (x>=0)...
THEN
FOR ...
FOR ...
b
erg = erg * i
erg = erg * i
ergebnis= 1
d
ENDIF
ENDIF
g
e
Testfall 1: x = -1 (a, c, j)
erg = erg * i
f
RETURN
RETURN
FOR ...
h
ENDOFFOR
ENDOFFOR
Testfall 2: x = 0 (a, b, d, h, k, j )
ergebnis= -1
ergebnis= -1
ELSE
IF (x>=0)...
ELSE
THEN
IF (x>=0)...
THE
N
ergebnis= 1
ergebnis= 1
FOR ...
FOR ...
erg = erg * i
erg = erg * i
ENDOFFOR
ENDOFFOR
ENDOFFOR
c
ENDIF
j
RETURN
ENDIF
ENDIF
RETURN
RETURN
Frage:
alle Pfade
püfbar ?
Testfall 4 (,5,...): x = 3(,4,..)
Testfall 3: x = 2
(a, b, d, [e, f, g] i, h, k, j) , i=2(,3,...)
(a, b, d, e, f, g, h, k, j)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
Kontrollflussgraph der Fakultäts-Berechnung
282
8.1.2 White-Box-Test
Pfadüberdeckung - Ausführungsbaum
ergebnis= -1
IF (x>=0)...
THE
N
ergebnis= 1
ENDIF
FOR ...
RETURN
ENDIF
RETURN
erg = erg * i
ENDOFFOR
FOR ...
ENDIF
erg = erg * i
RETURN
ENDOFFOR
FOR ...
ENDIF
erg = erg * i
ENDOFFOR
RETURN
FOR ...
Testfall 1, .., 6, ..:
x = -1: (a, c, j)
x = 0, ..,5, .. : (a, b, d, [e, f, g] i, h, j)
ENDIF
RETURN
erg = erg * i
ENDOFFOR
FOR ...
ENDIF
...
RETURN
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
283
8.1.2 White-Box-Test
Pfadüberdeckung
ELSE
IF (..)
THEN
Frage: Wie oft muss dieses
Programm bei vollständiger
Pfadüberdeckung getestet
werden?
4 Mal
ELSE
IF (..)
THEN
RETURN
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
284
8.1.2 White-Box-Test
Testziele (III)
 Vollständige Bedingungsüberdeckung
 Jede Teilbedingung (und Gesamtbedingung) in einer Abfrage nimmt mindestens
einmal den Wert true und mindestens einmal den Wert false an
 Beispiel: IF (Z=="A") OR (Z=="E") OR (Z=="I") → Testfälle: A, E, I, X
 Bedeutung:
Fehler bei der Erstellung von Bedingungen werden erkannt
Bemerkung:
Für eine Bedingungsüberdeckung langt nicht, dass jede Gesamtbedingung
mindestens einmal den Wert true und mindestens einmal den Wert false
annimmt (= Zweigüberdeckung!)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
285
8.1.2 White-Box-Test
Vergleich der Testprinzipien
Entdecken von fehlerhaften
Teilbedingungen im IF
Rand-Fehler in komplexer
Bedingung (x>0 statt x ≥0)
Anzahl von Testfällen
viele
Bedingungsüberdeckung
schwierige Fehler in
IF-Bedingungen
Pfadüberdeckung
"leere"
Else-Anweisung





Zweigüberdeckung
Fehlerhafte Anweisung
Anweisungsüberdeckung
Ergebnisse für vollständige
Abdeckung















viele
sehr
viele
viele
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
 wird entdeckt
 wird nicht entdeckt
 wird tlw. entdeckt
286
8.1.2 White-Box-Test
Kombination von Testprinzipien
 Häufig treten in der Software Fehler auf, weil eine If-Abfrage an
der Grenze zwischen den beiden Fällen unsauber formuliert ist
(z.B. x>0 statt x≥0)
Kombiniere die Zweigüberdeckung mit
der Grenzwertanalyse!
 d.h. teste nicht nur irgend einen Wert pro Zweig, sondern die Grenzwerte!
 Werte, die - falls sie etwas größer bzw. kleiner wären - den Ablauf in den anderen
Zweig steuern würden („Ränder von Schleifen“)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
287
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
8.1.3 Testdurchführung
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
288
8.1.3 Testdurchführung
Allgemeine Strategie
1) Testfälle nach Black-Box-Test suchen
2) Wenn möglich - ergänzende Testfälle nach White-Box-Test suchen
nach Zweigüberdeckung
evtl. zusätzliche Testfälle gemäß Bedingungsüberdeckung
evtl. teilweise Pfadüberdeckung
3) Zusätzlich intuitive Testfälle suchen
 Testziel
 Ziel ist es so viele Fehler wie möglich zu finden
- und nicht die Fehlerfreiheit nachzuweisen!
 psychologischer Grund: Prüfer muss motiviert werden, Fehler zu finden!
Dijkstra: "Program testing can be used to show the presence of
bugs, but never to show their absence!"
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
289
8.1.3 Testdurchführung
Ablage von Testdaten
 Tests müssen reproduzierbar sein
 die Funktion muss erneut getestet werden können
- z. B. nach einer Programmänderung
- Eingabe- und Ausgabedaten müssen aufgehoben werden
 Ablage und Testautomatisierung mit Hilfe von Testwerkzeugen
 Bei Erstellung des Testplans
- Ein- / Ausgabedaten und Vor- / Nachzustände werden hergeleitet.
 Beim Testlauf (für den Test eines Testfalls)
- Durch eine Setup-Funktion wird die Testumgebung erstellt (z. B. Instanziierung von
Klassen etc.) und die Vorzustände ( z. B. Attributwerte von Klasseninstanzen, globale
Variablen, Datenbankzustände etc.) werden gesetzt.
- Das Testwerkzeug ruft die Funktion mit vorgegebenen Eingabedaten auf und
- testet das Ergebnis auf Korrektheit. (Ergebnis muss manuell hergeleitet werden!)
- Evtl. müssen auch Nachzustände auf Korrektheit geprüft werden.
 Nach Testlauf:
- Das Testwerkzeug räumt auf (Tear-down-Funktion), d. h. durch new instanziierte
Klassen müssen destruiert werden etc.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
290
8.1.3 Testdurchführung
Toolunterstützung
 Test-Tools
 erleichtern die Erstellung von Testfällen und das Aufsetzen der Zustände für den
Test (z.B. JUnit, C++Unit, ...)
 verwalten Testfälle und automatisieren die Test-Durchführung
 "markieren" nach der Durchführung einer Menge von Testfällen die
durchlaufenen Anweisungen, Zweige und Bedingungen
- man muss "nur noch" fehlende Tests ergänzen
- erleichtert schnelle Erkennung von schwer / nicht testbaren Programmteilen
 Bei schlechter Überdeckung:
-
Überarbeitung des Codes zur Verbesserung der Testbarkeit
Entfernen von unbenutztem Code
Einbau von Zugriffsmöglichkeiten zu Testzwecken
"Design for Testability"
Ohne Tool sind systematische Tests für größere Programme
kaum machbar!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
291
8.1.3 Testdurchführung
Einordnung im V-Modell
Anwendungsszenarien
Anforderungsdefinition
Testfälle
Grobentwurf
(SW-Architektur)
Feinentwurf
Testfälle
(Design)
Modul-Implementierung
Testfälle
Abnahmetest
Systemtest
Integrationstest
Modultest
Die Testspezifikation sollte jeweils an den Phasenenden erfolgen!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
292
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
8.2 Modultest
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
293
8.2 Modultest
Was ist ein Modultest?
 Ein Modultest ist der Test eines einzelnen Teilstücks der Software - eines Moduls:
 Funktionen
- lokales Testen von globalen Funktionen / Funktionen in Klassen
 Klassen
- Testen aller Funktionen (Schnittstelle) mit Aufruf von Funktionen der gleichen Klasse.
 Ketten von verbundenen Klassen z.B. durch Assoziationen / gegenseitige Aufrufe
- Testen von Funktionen mit Aufruf von Funktionen anderer Klasseninstanzen
 Komponenten
- Testen aller Funktionen der Schnittstelle der Komponente.
Jede Funktion wird zuerst einzeln für sich getestet! Aber wie?
Simuliere die Umgebung des Moduls durch Test-Module.
Die aufrufende Module ersetze ich durch „Driver“,
die aufgerufene Module durch "Stubs"
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
294
8.2 Modultest
Isolierter Test einzelner Funktionen
 "Drivers" sind Testmodule, die
 das Verhalten einer aufrufenden Funktion simulieren
driver A
Modul A
- Testumgebung erstellen
- Eingangszustände setzen (Datenbank, Datei,
Attribute von Klassen, globale Variablen ... )
stub A1
stub A2
- die zu testende(n) Funktion(en) des Moduls aufrufen
und mit Parametern versorgen,
- Bildschirmeingaben definieren oder durch Umleitung des Streams automatisch
einspielen
- Ergebnisse entgegennehmen
- Ergebnisse (Ausgabeparameter, Bildschirmausgaben) und Ausgangszustände
(Datenbank, Datei, Klassenattribute, globale Variablen ... ) prüfen bzw. den Benutzer bei
der Prüfung unterstützen
- System in Zustand vor dem Test zurückversetzen
 "Stubs" sind Testfunktionen, die
 das Antwort-Verhalten einer echten aufgerufenen Funktion (mehr oder weniger)
simulieren
- Parameter von der zu testenden Funktion entgegennehmen
- Ergebnisparameter (die evtl. "falsche" Werte besitzen können) nach oben zurückgeben
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
295
8.2 Modultest
Besonderheiten beim Modultest
 Test von Funktionen in Klassen:
 Instanziieren von Klasseninstanzen
 Eine Funktion hat evtl. auch Attribute von Klasseninstanzen als
Eingabe- oder Ausgabezustände.
 Beim Test berücksichtigen!
 Aufrufhierarchien von mehreren Funktionen
 Es werden einzeln getestete Funktionen zu Aufrufhierarchien (auch über
Klassengrenzen hinweg) zusammengeführt
- innerhalb einer Klasseninstanz:
Teil des Klassentests.
- Über Klasseninstanzgrenzen hinweg:
Hier können Attributwerte der anderen Klasseninstanzen auch
Ein-/Ausgabezustände sein.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
296
8.2 Modultest
Modultest
 Was ist ein Modultest?
 Beim Modultest wird für ein Modul die Erfüllung der Spezifikation geprüft
 Da ein Modul meistens alleinstehend nicht lauffähig ist,
wird zunächst eine Testumgebung erstellt,
d.h. Programme, welche das Modul mit Testdaten versorgen
 Fehler können dann z.B. mit einen Debugger lokalisiert werden
 Wie führe ich einen Modultest durch?
 als Entwickler in einer simulierten Zielumgebung
 ohne den Auftraggeber
 Was wird in einem Modultest getestet?
 Die Funktion eines (einzelnen) Moduls
Der Modultest ist ein Black Box- oder White Box-Test
 systematischer Entwicklertest
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
297
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
8.3 Integration und Integrationstest
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
298
8.3 Integrationstest
Zur Erinnerung: Tätigkeiten im Design
 Zerlegung des Systems in Programmteile & Systemkomponenten ("Module")
 Anbindung an konkrete Programmiersprache, Betriebssystem, Hardware
 Ausarbeiten von Details
- Klassen mit Methoden und Attributen mit Datentypen
- Abläufe
- Betriebssystemanbindung (Threads, Scheduler, Timer,… )
 Umsetzung der Vorgaben aus der Architektur
 Das Grob-Design (die SW-Architektur) zerlegt das System in
Systemkomponenten
 Das Zusammenbauen von Systemkomponenten zu Teilsystemen
(Sub-Systemen) heißt "Integration"
 Der Test, ob mehrere Systemkomponenten fehlerfrei zusammen wirken, heißt
"Integrationstest"
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
299
8.3 Integrationstest
Integrationstest – die Idee
 Ein komplexes System besteht aus (sehr) vielen Systemkomponenten,
die zu unterschiedlichen Zeitpunkten fertig werden
 Das Lokalisieren von Fehlern in einem solchen System ist sehr schwer
Ich erweitere die Teilsysteme Schritt für Schritt und
führe wiederholt Tests
auf dem inkrementell wachsenden Teilsystem durch
 Ich mache Änderungen an nur wenigen Stellen
 neu entdeckte Fehler hängen mit der letzten Änderung zusammen
 Fehler können aber durchaus auch in den "alten" Teilen liegen
 "Inkrementelle Integration" statt "Big-Bang-Integration"
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
300
8.3 Integrationstest
Inkrementelle Integration
weiterer Testfall
(nach Testen von
T1, T2 und T3)
Testfall
T2
T1
A
T3
B
T2
T1
Integration
A
T3
B
T4
C
...
Komponente
Teilsystem
Testfolge 1
Testfolge 2
...
Außerdem: Sukzessives Ersetzen von Stubs und Drivers durch echte Module
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
301
8.3 Integrationstest
Top-Down-Vorgehensweise
 Zuerst Implementierung, Montierung und Test der obersten Schicht,
 die noch nicht hinzugefügten Funktionen werden durch Stubs simuliert
 sukzessives Ersetzen der darunter liegenden Stubs durch echte Funktionen
Version 1
TOP
Modul
1.2
STUB 1.1
Version 2
STUB
3.1
STUB
3.2
TOP
Modul
1.1
Modul 3
Modul 2
Modul 1
STUB
1.1.1
Modul 3
STUB 2
Modul 1
Modul
1.2
STUB
3.1
STUB
3.2
STUB
1.1.2
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
302
8.3 Integrationstest
Bottom-Up-Vorgehensweise
 Zuerst Implementierung, Montierung und Test der untersten Schicht,
 die darüber liegenden Module werden durch "Driver" simuliert
 sukzessives Ersetzen der darüber liegenden Driver durch echte Funktionen
Version 1
driver 1
driver 2
Modul 1
Modul 1.1
Modul 2
...
Modul 1.2
...
...
driver A
Modul A
Version 2
Modul 1
Modul 2
Modul 1.1
Modul 1.2
...
...
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
303
8.3 Integrationstest
Vergleich: Bottom-Up-Vorgehensweise Top-Down-Vorgehensweise
 Bottom-Up-Vorgehensweise
 Vorteil:
- Ergebnisse die auf oberster montierter Schicht zu sehen sind, sind echt, da das
System darunter schon fertig ist
- Es kommen keine Stubs zur Anwendung
 Nachteil:
- Der Benutzer sieht erst in den späten Phasen der Entwicklung etwas, das dem
Endergebnis entspricht (Benutzschnittstelle ist normalerweise oben!).
 Top-Down-Vorgehensweise
 Vorteil:
- Der Benutzer sieht schon zu Beginn der Integration etwas
 Nachteil:
- Die Ergebnisse auf oberster Schicht sind nicht echt (Simulationen)
 Kombination von Bottom-Up und Top-Down ist möglich
 Es kommen dann gleichzeitig Drivers und Stubs zum Einsatz
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
304
8.3 Integrationstest
Integrationstest
 Was ist ein Integrationstest?
 Prüfung, ob mehrere Module fehlerfrei zusammenwirken
 Test von Teilen des Gesamtsystems
 Fokus auf das Zusammenspiel der Systemkomponenten
 Wie führe ich einen Integrationstest durch?
 durch ein Test- bzw. Integrations-Team
 Schrittweiser Zusammenbau des Teilsystems und Ansteuerung mit Drivers und
Verwendung von Stubs
 Was wird in einem Integrationstest getestet?
 Ein Verbund aus
- bereits einzeln getesteten Systemkomponenten oder
- bereits integrierte und getestete Teilsystemen
 Die verwendeten Module hängen von deren Verfügbarkeit zum Zeitpunkt des
Tests, sowie der gewählten Integrationsstrategie ab
Ein Integrationstest ist ein Test für ein Teilsystem bestehend aus mehreren Systemteilen
 sowohl White-Box als auch Black-Box-Tests
 mit Fokus auf die Interaktion der integrierten Komponenten
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
305
8.3 Integrationstest
Frage Integrationstest
 Wo finden wir im SW-Entwurf mit UML für den OO-Test die Aufrufhierarchie?
 In den Sequenzdiagrammen
 Wie sind Sie in im Praktikum vorgegangen?
 Wie würden Sie Vorgehen beim Test von Konstruktor Dosierverwalter
(bzw. entsprechende Fkt. zur Erstellung der Dosierer in Rezeptprozessor)?
Was ist der Vorzustand, die Eingabe, der Nachzustand, die Ausgabe?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
306
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
8.4 Systemtest, Abnahmetest
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
307
8.4 Systemtest / Abnahmetest
Unterschied zwischen Systemtest und Abnahmetest
Was ist ein Abnahmetest?
Was ist ein Systemtest?
 die Abnahmetests sind Bestandteil des
Vertrags
 Nach erfolgreicher Abnahme wird bezahlt
Wie führe ich einen Abnahmetest durch?
 Zusammen mit dem Auftragsgeber in der
echten Zielumgebung
 Mit formeller Protokollierung
 Test des integrierten Gesamtsystems
 Alles, was beim Abnahmetest getestet wird - aber
noch ausführlicher
Wie führe ich einen Systemtest durch?
 ohne den Auftraggeber,
mit Entwicklern und Qualitätssicherung in der echten
Zielumgebung
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
308
8.4 Systemtest / Abnahmetest
Unterschied zwischen Systemtest und Abnahmetest
Was wird in einem Abnahmetest getestet?
Was wird in einem Systemtest getestet?
 Alles was spezifiziert wurde:
 Funktionstests ✔
 Leistungstests (z. B. Antwortzeiten bei
Normallast)
 Benutzbarkeitstests (z. B. einheitliche
Benutzerschnittstelle, Help-Bildschirme,
Benutzerhandbuch)
 Robustheitstests (Prüfen der Reaktion bei
unzulässigen Eingaben)
 evtl. Volumentests (z. B. maximale
Datenmengen)
 evtl. Stresstests (z. B. maximale
Anforderung von Prozessorleistung)
 Funktionstests, Leistungstests, Benutzbarkeitstests,
Robustheitstests Volumentests, Stresstests, (evtl.
ausführlicher als beim Abnahmetest)
 außerdem Sicherheit, Zuverlässigkeit, Wartbarkeit,
Dokumentation, ...
 auch Installation, Datenkonvertierung, Start und
Initialisierung
 auch Betriebsfunktionen wie Backup und Recovery
 auch Provozieren von Abstürzen, um Lauffähigkeit
und Robustheit zu prüfen
(Datei defekt, Plattenausfall, Datenbank korrupt, …)
 auch Berücksichtigung von außergewöhnlichen
Zuständen des Systems (Datenbank etc.).
 auch Berücksichtigung von Schnittstellen nach außen
(andere IT-Systeme. Peripheriegeräte wie Drucker
etc.).
Der Abnahmetest ist ein Blackbox-Test
für das Gesamtsystem
 aus Auftraggeber-Sicht
Der Systemtest ist ein Blackbox-Test für
das Gesamtsystem
 aus Auftragnehmer-Sicht
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
309
8.4 Systemtest / Abnahmetest
Leistungs-(Performance-)Test
 Bedingungen
 “Normale Last”
 Messen von Antwortzeiten und Kapazität
 Selbstverständliche Forderungen:
 Sofortige Antwort bei Tastendruck
 1-2 Sekunden für leichte Fragen
 Ein Bescheid, wenn es länger dauert
 Batch Jobs über Nacht fertig
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
310
8.4 Systemtest / Abnahmetest
Volumentest
 Ziele




Maximale Datenmengen
Mehr als Maximum
Randomgenerierte oder alte Daten
Versuchen Sie, den ganzen Platz zu belegen
 Beobachtungen




Verliert das System Daten?
Verfälscht das System Daten?
Stoppt das System mit Meldung / ohne Meldung?
Braucht es enorme Zeit?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
311
8.4 Systemtest / Abnahmetest
Stresstest
 Ziele






Maximale Input-Geschwindigkeit
Input an allen Linien (z. B. alle Sensoren senden gleichzeitig)
Dasselbe Kommando an allen Linien
Alarm an allen Linien
Komplizierte Funktionen
Nicht alle Systemressourcen zugänglich
 Reaktionen




Werden Inputs vergessen?
Bricht das System zusammen?
Braucht es zu lange Zeit?
Werden Daten verfälscht?
 Ein ungeheuer wichtiger Test bei Realzeitsystemen!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
312
8.4 Systemtest / Abnahmetest
Benutzbarkeitstest




Evaluation durch Experten (Ergonomen)
Standard für Benutzerschnittstelle
Messen der Lernkurve
Beurteilung der Voraussetzungen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
313
8.4 Systemtest / Abnahmetest
Sicherheitstest
 Ziel: Durchbrechen der Zugangskontrolle des Systems
 Kontrollieren Sie die Zugangsprivilegien für jede Benutzerklasse und jede
Funktion
 Destruktiver Test
 Kontrolle von Backup- und Recovery-Funktionen
 Paralleler Zugriff von mehreren Terminals auf die selben Resourcen
 Virus Check
 Arbeitsumfeld (Organisation)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
314
8.4 Systemtest / Abnahmetest
Weitere Tests
 Abhängig von den erwarteten und erwünschten Systemeigenschaften
 Kunde
- Erweiterungsfähigkeit
- Integrationsfähigkeit
- Zuverlässigkeit
- Robustheit, Fehlertoleranz
 Intern
- Wartungsfreundlichkeit
- Erweiterungsfähigkeit
- Portabilität
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
315
8.4 Systemtest / Abnahmetest
Test-Gesamtplanung
 Erstellung der Montage- und Testplanung, Erstellung der Testfälle erfolgt bereits
an den jeweiligen Phasenenden (V-Modell)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
316
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
8.5 Beispiel Modul-, Integrationstest
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
317
8.5 Beispiel Modul-, Integrationstest
Beispiel Modultest - Beobachtermuster (Observer Pattern)
dieWaage
:KonkretesSubjekt
Interaktionen:
dasDisplay
:KonkreterBeobachter
derDosierer
:KonkreterBeobachter
aktiviere()
erhoehe_gewichte
benachrichtige()
aktualisiere()
getdelta_gewicht()
out: delta_gewicht
zeigeAn()
aktualisiere()
getdelta_gewicht()
vergleicheGewicht(delta_gewicht)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
Aufgabe: Leiten Sie
die Aufrufhierarchie ab
318
8.5 Beispiel Modul-, Integrationstest
Beispiel Modultest Beobachtermuster (Observer Pattern)
Es sollen folgende Funktionen getestet werden:
 getdelta_gewicht von Waage (Stubs nicht erforderlich)
 vergleicheGewicht von Dosierer (Stubs nicht notwendig)
 aktualisiere von Dosierer (Modultest (mit Stubs und) mit schon
ausprogrammierten aufzurufenden Funktionen)
 aktiviere von Waage (nur Test mit schon ausprogrammierten Funktionen)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
319
8.5 Beispiel Modul-, Integrationstest
Beispiel Modultest
(gewKennz?)
Aufrufhierarchie in Form
eines Strukturdiagramms
dieWaage.
für das Beispiel
erhoehe_gewichte
Observermuster der
Praktikumsaufgabe
dieWaage.
aktiviere
(gewKennz?)
dieWage.
benachrichtige
dasDisplay.
aktualisiere
deltaGew
Wird bei Ihnen
Gewichtskennzeichen
so zurückgegeben?
(gewKennz?)
derDosierer.
aktualisiere
deltaGew
dieWaage.
getdelta_gewicht
t
Displayausgabe deltaGew
(gewKennz?)
deltaGew
dasDisplay.
zeigeAn
deltaGew?
dieWaage.
getdelta_gewicht
Attribut deltaGew
derDosierer.
vergleicheGewicht
Woher kommt Delta-/Sollgewicht
von Zutat?? Parameter? Attribut?
Attribut von welcher Instanz?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
320
8.5 Beispiel Modul-, Integrationstest
Beispiel Modultest Beobachtermuster (Observer Pattern)
 Können Sie eine Funktion einer Klasse einfach aufrufen?
 Nein, erst instanziieren, initialisieren der Klasseninstanzen
 Welche Zustände müssen Sie setzen zum Austesten welcher Funktionen, was
sind Parameter?
 Delta-Gewicht, zu dosierendes Sollgewicht gemäß Rezeptschritt,
Erhöhungsgewicht? für welche Funktion? und zusätzlich??
 Wo erfolgt das Instanziieren, Setzen der Zustände, Übergeben, Annehmen der
Parameter der zu testenden Funktion, Prüfung der Ergebnisse?
 Im Driver
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
321
8.5 Beispiel Modul-, Integrationstest
Wie schreiben wir Tests?
 Wohin?
 Wie?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
322
8.5 Beispiel Modul-, Integrationstest
Wie schreiben wir Tests?
Wollen Sie es so realisieren (Tests oder Testaufrufe in main())?
Oder: Erstellung der Test-Funktionen in eigener Klasse (z. B. WaageTest)?
void main()
// includes
..
//Test-Driver:
void Waage_getdelta_gewichtTest ()
{
//Instanziieren der Klasseninstanzen, Vorzustand setzen, d. h. z. B. setze Attribut dieWaage.deltaGew zu 4
// (Evtl. Instanziieren von Pointern auf Klassenobjekte global und Kreieren von Objekten zu Pointern und Setzen von Attributen
//auch außerhalb in spezieller SetUp-Fkt., die vor jedem Test aufgerufen wird)
Waage dieWaage;
dieWaage.SetDeltaGew(4);
//Aufruf von dieWaage.getdelta_gewicht() und
//Testen des Ergebnisses auf Korrektheit (per assert-Statement) oder Ausgabe der Ergebnisse (anschließend:
// manueller Vergleich)
assert (dieWaage.getdelta_gewicht()==4); //oder if ...
//Allgemein: Ergebnis kann sein:
//Rückgabe-Parameter / &-Parameter oder
//Zustände von Attributen, globale Variablen, Datei- / Datenbankfelder (Nachzustand)
//Zurücksetzen Attribute / destruieren Klasseninstanzen evtl. auch in spezieller tearDown-Funktion, die nach jedem Test
//aufgerufen wird (z. B. durch new erzeugte Instanzen müssen gelöscht werden.)
}
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
323
8.5 Beispiel Modul-, Integrationstest
Wie schreiben wir Tests?
void Dosierer_vergleicheGewichtTest (deltaGewicht) // sollGewicht als Attribut in Dosierer?
{
...
...
}
void Dosierer_aktualisiereTest ()
{
//Instanziieren der Klasseninstanzen
//setze Attribut ...
..
//Aufruf von aktualisiere() ... //(1. mit getdelta_gewicht() und vergleicheGewicht() als Stubs bzw.)
//2. mit getdelta_gewicht() und vergleicheGewicht() als schon fertige Funktionen (Integrierte Funktionen)
..
//Ausgabe Ergebnis
..
//Zurücksetzen Attribute
}
void Dosierer_aktualisiereTest2 () ... // evtl. nur mit Stubs oder mit anderen Rückgabewert für gew_Kennz
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
324
8.5 Beispiel Modul-, Integrationstest
Wie schreiben wir Tests?
// eigentlicher Test
//Test 1:
..... Waage_getdelta_gewichtTest ();
//Test 2:
.....Dosierer_vergleicheGewichtTest ();
//Test3
.....Dosierer_aktualisiereTest ();
//Test 4:
.....Dosierer_aktualisiereTest2 (); //mit Stubs
..
//Test n:
.....
..
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
325
8.5 Beispiel Modul-, Integrationstest
Beispiel Integrationstest
 Teilsysteme d, e ... werden zu größeren Teilsystem c zusammengesetzt.
(d oder e kann auch Fremdsystem sein.)
 Beispiel in unserem Praktikum:
d und e sind Teilsysteme mischen und start,
c ist Gesamtsystem
=> Integrationstest der obersten Stufe
(bei uns recht trivial)
=> Ein Testfall für diesen Integrationstest ist der normalerweise schon nach
der Anforderungsdefinition spezifizierte Abnahmetestfall
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
326
8.5 Beispiel Modul-, Integrationstest
Beispiel Integrationstest
Teil- bzw. Gesamtsystem
Das muss alles
beim Schreiben
des Testfalls
berücksichtigt
werden
Daten von externen
Subsystemen /
Dateien?
(Vorzustand)
Gewichtwert von
externer Waage
(wenn simuliert =>
deterministisch!)
Teilsystem start
Teilsystem mischen
Bildschirmausgabe B1,
... ?
Attribute A1,... ?
(Nachzustand)
Bildschirmeingabe B1, ... ?
Attribut A1, A2,... ?
(Vorzustand)
Kommandos Ventil
auf, ... an externe
Dosierer, ...
Gew-Wert auf Display
...
Bildschirmeingabe B2, ... ?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
327
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
8.6 Testwerkzeuge
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
328
8.6 Testwerkzeuge
Testen in größeren Projekten (I)
 Stellen Sie sich nun vor, alle Ihre zu testenden Programme sind Module, die zu
einem größeren Projekt gehören
 Die Module sollen regelmäßig integriert und getestet werden
- Sie müssen die Testaufrufe aus den Main-Funktionen der Einzelprojekte
zu EINER - zunehmend unübersichtlichen - Main-Funktion zusammenführen
- Die Tests für ein Modul können dann nicht mehr einzeln durchgeführt werden
- Jeder neue Testfall erfordert eine Änderung an der Main-Funktion.
- Die Reihenfolge der Tests kann evtl. eine Auswirkung auf das Ergebnis haben
 Die manuelle Durchführung dieser Tests
-
wäre in der Summe sehr aufwändig
wäre nicht reproduzierbar
wäre nicht systematisch
wäre nicht zuverlässig genug für ein professionelles Projekt
In einem größeren Projekt ist der einfache Test-Ansatz
über eine Main-Funktion nicht brauchbar!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
329
8.6 Testwerkzeuge
Testen in größeren Projekten (II)
 Üblicherweise findet in einem größeren Projekt die Entwicklung
von Modulen in verschiedenen Teams statt
 Die Tests müssen einzeln durchführbar sein – aber auch leicht zusammen zu
führen sein
 Jedes Team entwickelt "seine" Klassen und schreibt entsprechende Tests
 Üblicherweise findet in einem größeren Projekt die Entwicklung
in Iterationen statt
 Nach jeder Iteration - also täglich oder mindestens wöchentlich - muss getestet
werden
- ob die entwickelten Module (noch) die Modultests besteht
- ob die integrierten Module die Integrationstests bestehen
In einem größeren Projekt müssen Tests
 verteilt und unabhängig voneinander entwickelt werden
 automatisiert durchgeführt werden
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
330
8.6 Testwerkzeuge
xUnit
http://cppunit.sourceforge.net/projects/cppunit
 xUnit = Familie von Open Source Frameworks für das Testen
-
JUnit für Java
CppUnit für C++
NUnit für .Net
uvm. ...
 alle mit gleichem Funktionsprinzip und ähnlicher Verwendungsweise
 xUnit ermöglicht






die verteilte und unabhängige Entwicklung von funktionalen Tests
die einfache Zusammenführung der verschiedenen Tests
die automatische Durchführung der Tests
die automatische Protokollierung und Überprüfung der Ergebnisse
Tests in der gleichen Programmier-Sprache wie die Anwendung
und viele anderer nützliche Dinge...
xUnit ist die Standardlösung
für (open Domain) Testframeworks !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
331
8.6 Testwerkzeuge
Ein einfacher Test mit CppUnit (I) (Prinzip) – Aufgabe
 Wir wollen eine Klasse Complex zum Rechnen mit
komplexen Zahlen in C++ entwickeln
 mit den üblichen mathematischen Operatoren
 Wir wollen eine Testklasse ComplexNumberTestCase
entwickeln, die die Klasse Complex mit CppUnit testet
 Die Testklasse enthält
- Eine Testmethode (runTest), welche Methoden der
zu testenden Klasse aufruft
- Die Methoden setUp() und tearDown() die vor bzw.
nach jeder Testmethode ausgeführt werden
 Mit speziellen Zusicherungen ("Assert's") werden
zu prüfende "Soll-Ergebnisse" festgelegt
 Bei der testgetriebenen Entwicklung entwickeln Sie
erst den Test und dann die zu testende Klasse
Complex
double real, imaginary;
Complex( double r, double i )
bool operator ==
(Complex &a, Complex &b)
Complex operator+
(Complex& a, Complex& b)
...
bezieht sich auf
ComplexNumberTestCase
runTest()
setUp()
tearDown()
Die zu testende Klasse wird nicht modifiziert !
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
332
8.6 Testwerkzeuge
C++-Unit - Ein einfacher Test-Case (Prinzip)
Als Erstes entwickeln wir den Testfall (Testgetriebene Entwicklung):
#include ... // hier müssen u. a. Dateien des Frameworks inkludiert werden
class ComplexNumberTestCase : public CppUnit_NS::TestCase
{
public:
ComplexNumberTest(string name ) : CppUnit_NS:: TestCase( name ) {}
void runTest() {
CPPUNIT_ASSERT( Complex (10, 1) == Complex (10, 1) );
CPPUNIT_ASSERT( !(Complex (1, 1) == Complex (2, 2)) ); }
};
Testmethode
Zusicherungen
(falls falsch=> Fehler)
Wir entwickeln nun die zu testende Klasse Complex und den Operator ==, so dass der Test läuft:
class Complex {
friend bool operator ==(const Complex& a, const Complex& b);
double real, imaginary;
public:
Complex( double r, double i = 0 )
: real(r), imaginary(i) { }
};
bool operator ==( const Complex &a, const Complex &b ){
return a.real == b.real && a.imaginary == b.imaginary;
};
Dann können wir den TestCase ComplexNumberTestCase instanziieren und runTest()
aufrufen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
333
8.6 Testwerkzeuge
C++-Unit - Mehrere Tests mit setUp und tearDown - TestFixture
 Normalerweise wollen wir einige Instanzen der zu testenden und evtl. weiterer Klassen
incl. Daten vorher definieren und
 mit diesen Instanzen eine Anzahl von Tests fahren (z. B. testEquality() (s. o.) und
TestAddition()). Bei jedem Test soll aber der Zustand vor dem jeweiligen Test jeweils in
den definierten AnfangsTestFixture
zustand gebracht werden.
setUp()
⇒ Wir verwenden die Klasse TestFixture,
tearDown()
in der die abstrakten Operationen
setUp und tearDown stehen, die vor/nach
TestCase
jedem Test den definierten Zustand herstellen.
⇒ die setUp und tearDown-Methoden wie auch
die eigentlichen Tests (z. B. testEquality und
testAddition) werden in der eigentlichen Testfixture
(z. B. ComplexNumberTest) implementiert.
Die eigentlichen TestCases werden dann durch das
C++-Unit-Framework zusammengestellt und aufgerufen.
runTest()
setUp()
tearDown()
ComplexNumberTest
testEquality()
testAddition()
setUp()
tearDown()
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
334
8.6 Testwerkzeuge
C++-Unit - setUp und tearDown in der TestFixture
#include ...
class ComplexNumberTest : public CppUnit_NS::TestFixture
{
private:
Complex *m_10_1, *m_1_1, *m_11_2;
Members zum Testen
public:
void setUp()
{
Testvorbereitung
m_10_1 = new Complex( 10, 1 );
m_1_1 = new Complex( 1, 1 );
m_11_2 = new Complex( 11, 2 );
}
Testnachbereitung
void tearDown()
{
delete m_10_1;
delete m_1_1;
delete m_11_2;
}
};
Was muss jetzt noch hinzugefügt werden?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
335
8.6 Testwerkzeuge
C++-Unit - setUp und tearDown und die einzelnen Tests in der TestFixture
#include ...
class ComplexNumberTest : public CppUnit_NS::TestFixture
{
private:
Complex *m_10_1, *m_1_1, *m_11_2;
public:
void setUp()
{
m_10_1 = new Complex( 10, 1 );
m_1_1 = new Complex( 1, 1 );
m_11_2 = new Complex( 11, 2 );
}
void tearDown()
{
delete m_10_1;
delete m_1_1;
delete m_11_2;
}
void testEquality()
{
CPPUNIT_ASSERT( *m_10_1 == *m_10_1 );
CPPUNIT_ASSERT( !(*m_10_1 == *m_11_2) );
}
void testAddition()
{
CPPUNIT_ASSERT( *m_10_1 + *m_1_1 == *m_11_2 );
}
};
Testmethoden
Zusicherungen
Zu jeder der hier aufgeführten 2 Testmethoden wird vom Framework ein TestCase mit einem runTest() erstellt,
in dem jeweils setUp() und tearDown() vor und nach dem eigentlichen Test (hier z. B. testEquality) abläuft.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
336
8.6 Testwerkzeuge
C++-Unit mit TestSuite - Überblick
CppUnit*
Test
+ run(TestResult*) //abstract
Kennen Sie
das Muster?
*
TestFixture
ComplexNumberTest
+ testEquality()
+ testAddition()
......
+ setUp()
+ tearDown()
+ setUp()
// abstract
+ tearDown() // abstract
1
Die Klasse
mit den Testmethoden
TestSuite
TestCase
Das TestFramework
+ run(TestResult*) //abstract
+ setUp()
//abstract
+ tearDown()
//abstract
+ run(TestResult*)
+ addTest(Test*)
bezieht sich auf
Complex
double real, imaginary;
TestMain.cpp
// Main-Funktion zum
Aufrufen der Tests durch
das Framework.
+ Complex( double r, double i )
- bool operator ==
(Complex &a, Complex &b)
- Complex operator+
(Complex& a, Complex& b)
Die zu testenden Klasse
...
konkrete, durch das Framework
aus den TexFixtures erstellte TestCases
* Darstellung vereinfacht. Tatsächlich gibt es deutlich mehr
Klassen und Methoden innerhalb des Frameworks.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
337
8.6 Testwerkzeuge
C++-Unit mit TestSuite
 Wie konstruiere ich den Test, so dass ich alle Tests zusammen laufen lassen kann?
=> Kreiere eine Suite mit mehreren Tests:
 Mit Hilfe des Frameworks werden einzelne TestCases aus den Methoden der
konkretenTestfixture (z. B. ComplexNumberTest) gebildet und der Suite hinzugefügt. Jeder
TestCase besteht aus der SetUp-, der Test-, der TearDown- und der run(TestResult*)Methode. In der run(TestResult*)-Methode werden die anderen Methoden aufgerufen.
 Beim Ausführen der Suite werden dann alle Elemente der Suite ausgeführt (run(...) aller
Elemente wird aufgerufen)
 Elemente der Suite können TestCases oder auch Suites sein (Compositum-Muster!)
 Falls das Element ein TestCase ist, wird durch Run(...) die SetUp-, Test- und TearDownMethode des TestCase ausgeführt
 Falls das Element eine TestSuite ist, werden in run(...) die Run()-Methoden der
darunterliegenden Elemente aufgerufen
 Die oben aufgeführten Schritte und die Registrierung der Suite werden über Macro-Aufrufe
des Frameworks durchgeführt
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
338
8.6 Testwerkzeuge
C++-Unit mit TestSuite – Erstellung und Registration in der TestFixture
#include ...
class ComplexNumberTest : public CppUnit_NS::TestFixture
{
CPPUNIT_TEST_SUITE(ComplexNumberTest);
CPPUNIT_TEST(testEquality);
CPPUNIT_TEST(testAddition);
CPPUNIT_TEST_SUITE_END();
private:
Complex *m_10_1, *m_1_1, *m_11_2;
public:
void setUp()
{
m_10_1 = new Complex( 10, 1 );
m_1_1 = new Complex( 1, 1 );
m_11_2 = new Complex( 11, 2 );
};
void tearDown()
{
delete m_10_1;
delete m_1_1;
delete m_11_2;
};
void testEquality()
{
CPPUNIT_ASSERT( *m_10_1 == *m_10_1 );
CPPUNIT_ASSERT( !(*m_10_1 == *m_11_2) );
};
void testAddition()
{
CPPUNIT_ASSERT( *m_10_1 + *m_1_1 == *m_11_2 );
};
};
CPPUNIT_TEST_SUITE_REGISTRATION(ComplexNumberTest);
Aufbau einer
Testsuite aus
einzelnen
Testfällen
ein TestCase testEquality
mit den Methoden setUp(),
testEquality() und TearDown()
wird erstellt und in der Suite
ComplexNumberTest
hinzugefügt.
Registrierung der
Testsuite in der
Registry des
Frameworks
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
339
8.6 Testwerkzeuge
C++-Unit - Der Testlauf
 Zur Ausführung des Tests muss aus den Angaben in der Registry der Test
erstellt und anschließend ausgeführt werden:
#include ....
int main()
{
CppUnit_NS::TextUi::TestRunner runner;
runner.addTest(CppUnit_NS::TestFactoryRegistry::getRegistry().makeTest() );
bool wasSuccessful = runner.run();
return wasSuccessful;
}
makeTest() erstellt
aus den Angaben
der Registry den
Gesamttest
 Im Framework gibt es noch Listener, Resultcollectors und Outputter mit denen
die Results des Tests gesammelt und übersichtlich ausgegeben werden können
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
340
8.6 Testwerkzeuge
Testen mit xUnit – Das Ergebnis
 In den Zusicherungen wird das Soll-Ergebnis mit dem Ist-Ergebnis verglichen
 Gibt es einen Unterschied, erfolgt eine entsprechende Meldung
 Die Tests werden jedenfalls weiter ausgeführt (und nicht abgebrochen)
In der Methode
testAddition wurde
eine Zusicherung
verletzt!
Mit xUnit können Tests
 verteilt und unabhängig voneinander entwickelt werden
 automatisiert durchgeführt werden
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
341
8.6 Testwerkzeuge
Testen mit xUnit – Sonstiges
 Im xUnit Framework
 ist es recht einfach Tests zu erstellen, wenn man das Prinzip verstanden hat. Ein
funktionierendes Beispiel erleichtert den Start aber erheblich!
 ist der Zugriff auf private Attribute und Methoden normalerweise nicht möglich.
Es gibt aber oft "Tricks" um zu Testzwecken darauf zugreifen zu können
 wird der praktische Einsatz diverser Design-Patterns demonstriert
 kann testgetrieben entwickelt werden. d.h. es wird immer erst ein Test
geschrieben und erst dann der Code, der den Test zum Erfolg bringt.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
342
8.6 Testwerkzeuge
Testen mit xUnit – im Gesamtzusammenhang
 Mit entsprechenden Addons zu xUnit
 kann aus den Testfällen eine Dokumentation der Testfälle erzeugt werden
 kann die erzielte Anweisungs- oder Zweigüberdeckung berechnet und dargestellt
werden ("Test Coverage")
 können Messungen für Last- und Performancetests ("Profiling") durchgeführt
werden
 können leere Rahmen für zu schreibende Testklassen erzeugt werden
 ...
 Es gibt neben den Unit-Tests weitere Testwerkzeuge
 für die Verwaltung, Planung und Automatisierung der Testdurchführung
 für automatisierte GUI-Tests
 zur Durchführung von "statischen Tests"
(die den Code "nur" analysieren, aber nicht ausführen)
 uvm...
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
343
8. Test und Integration
Literatur zu Testen
Balzert, Helmut: Lehrbuch der Softwaretechnik: Softwaremanagement,
Softwarequalitätssicherung, Unternehmensmodellierung; Spektrum,
akademischer Verlag; 1998
Vigenschow, Uwe: Objektorientiertes Testen und Testautomatisierung; dpunktVerlag; 2005
Westphal, Frank: Testgetriebene Entwicklung mit JUnit & FIT; dpunkt-Verlag; 2006
Köhler: Der C/C++ Projektbegleiter; dpunkt Verlag; 2007
http://cppunit.sourceforge.net/projects/cppunit
http://sourceforge.net/apps/mediawiki/cppunit
http://cppunit.sourceforge.net/doc/lastest/cppunit_cookbook.html
http://www.evocomp.de/tutorials/tutorium_cppunit/howto_tutorial_cppunit.html
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
344
8. Test und Integration
Kontrollfragen Test und Integration











Wann ist ein Programm fehlerfrei?
Was bedeutet es, wenn alle Tests fehlerfrei laufen
Ist es normalerweise möglich alle möglichenTestfälle laufen zu lassen?
Welche Prinzipien zur Auswahl von Testfällen kennen Sie?
Wie unterscheiden sich Black-Box-Tests und White-Box-Tests?
Welche Unterschiede gibt es zwischen Anweisungs-, Zweig-, Pfad- und
Bedingungsüberdeckung?
Was ist Integration?
Was halten Sie von der Aussage "Sie haben das Programm doch getestet – wie
kann dann so ein Fehler auftreten?"
Warum muss man in der Architektur, im Design,… schon an Test denken?
Warum gibt es im V-Modell 4 Testphasen? Wie unterscheiden sie sich?
Woher "weiß" CppUnit welche Tests ausgeführt werden sollen, wenn die
Testklassen nicht in der Main-Funktion instanziiert werden?
Können Sie jetzt Tests spezifizieren, entwickeln und anwenden?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
345
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
Teil II - Querschnittsthemen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
346
Querschnittsthemen
Was sind Querschnittsthemen?
 Bisher wurden die Themen entlang eines Projektdurchlaufs behandelt
 es gibt aber auch Themen, die den einzelnen Phasen übergeordnet sind
 oder in vielen Phasen vorkommen
 Wir behandeln folgende Querschnittsthemen
(weiterhin aus der Sicht eines Software-Entwicklers):






Qualitätssicherung
Software-Metriken
Vorgehens- und Prozessmodelle
Technisches Management
Prozessorientiertes Qualitätsmgmt (ISO, CMM, Assessments)
... es gibt aber noch viele andere Themen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
347
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
9. Qualitätssicherung
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
348
9. Qualitätssicherung
Qualitätssicherung
 Qualitätssicherung beinhaltet Maßnahmen, die sicherstellen sollen,
dass ein Produkt ein vorgegebenes Qualitätsniveau erreicht
 es geht darum, eine vorgegebene Qualität zu erreichen - nicht unbedingt um die
höchste Qualität
 Produktqualität
 Die Maßnahmen zielen auf die Qualität der Bestandteile des Produkts.
- Anwendung konstruktiver Maßnahmen bei der Entwicklung des Produktes
- Anwendung analytischer Maßnahmen zur Untersuchung der Produktteile
siehe
nächste
Folien !
 Prozessqualität
 Die Maßnahmen zielen auf die Qualität des Prozesses mit dem das Produkt
erstellt wird.
- Definition bzw. Festlegung und Anwendung eines Entwicklungsprozesses,
- Aktive Suche nach Schwachstellen im Entwicklungsprozess,
- Systematische Verbesserung des Entwicklungsprozesses
(so dass beim nächsten Projekt nicht wieder die gleichen Fehler gemacht werden)
- siehe z.B. Norm ISO 9001; CMM, CMMI; SPICE
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
349
9. Qualitätssicherung
Produktqualität: Konstruktive Qualitätssicherung
 Es wird versucht, das Entstehen von Qualitätsmängeln bereits während der
Entwicklung (Konstruktion) des Produkts zu verhindern!
 Beseitige bei entdeckten Mängeln nicht nur den Mangel selbst, sondern auch
seine Ursache(n)
 Gestalte den Entwicklungsprozess so, dass Qualitätsmängel seltener werden
 Dazu werden während der Entwicklung geeignete Maßnahmen eingesetzt
 bewährte Methoden, Techniken, Konstruktionsprinzipien
(UML, Pair Programming, Test First, OO-Entwurf, 4-Schichten-Architektur, ...)
 formale Verfahren (formale Spezifikation)
 Werkzeuge (Case Tool, IDE, ...)
 Vorgehensmodelle und Vorgehensrichtlinien (Wasserfallmodell, V-Modell,
Einsatz von Prototypen, Coding Guidelines, ...)
Qualität kann nicht nachträglich in ein Produkt "hineingeprüft"
werden, Sie muss von Anfang an "eingebaut" werden!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
350
9. Qualitätssicherung
Produktqualität: Analytische Qualitätssicherung
 Es wird versucht, entstandene Fehler zu entdecken (und zu beseitigen), indem die
vorliegenden Teile des Produkts analysiert werden!
 Untersuche (Teil-)Produkte nach ihrer Fertigstellung auf Qualität
 Bessere nach, wo Mängel auftreten
 In der analytischen Qualitätssicherung unterscheidet man
 dynamische Maßnahmen, welche die "laufende" Software untersuchen
- Tests: Performancetests, Robustheitstests, Testüberdeckungen usw. (vgl. Kap. Test)
 statische Maßnahmen, die eingesetzt werden können bevor die Software "läuft"
- Manuelle Prüfverfahren zur Prüfung der fertigen Artifakte (= Reviews, vgl. OOAD)
- Automatische Prüfverfahren zur Prüfung der fertigen Artifakte
•
•
•
•
Automatische statische Codeanalyse zur Überprüfung des Codes auf potenziell fehlerhafte
Konstrukte (z.B. „=“ in einer If Bedingung) und auf Verstöße gegen die
Implementierungsrichtlinien
Konsistenz-Checks über dem UML-Modell mit Hilfe des CASE-Tools
Kompilierung des Codes zum Finden formaler Fehler (z. B. Syntaxfehler)
Codeanalyse mit Werkzeugen zur Bestimmung von Qualitäts-Maßen (vgl. Kapitel Metriken)
- Mathematisches Beweisen der Korrektheit von Programmen (Formale Verifikation)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
351
9. Qualitätssicherung
QS-Maßnahmen - Übersicht
konstruktiv
QS
Sicherung
ProduktQualität
dynamisch
analytische
QS
QSMaßnahmen
statisch
Test (Kap.8)
man. Prüfverf (Review)
automatische Prüfverf.
math. Beweisen
Sicherung
ProzessQualität (Kap. 11)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
352
9. Qualitätssicherung
Statische Codeanalyse (Beispiel einer analytischen statischen QS-Maßnahme)
 Bei der autom. statischen Codeanalyse
untersucht ein Tool den Quellcode
 es werden "beliebte" Fehlerquellen
entdeckt und angezeigt
-
Arrayüberschreitungen
Zuweisung statt Vergleich
Gefahr von Rundungsfehlern
uvm.
 z.B. „Codecheck“ in „Understand“, „QAC++" von QA Systems oder „PC-lint for
C/C++"
 Nette Übung bei PC-lint – suchen Sie den
Fehler im "Bug of the month"
http://www.gimpel.com/html/bugs.htm
 Sie können dort auch in der "Interactive
Demo" Ihren eigenen Code untersuchen
lassen
#include <iostream.h>
int main() {
const double three = 3.0;
double x, y, z;
x = 1 / three;
y = 4 / three;
z = 5 / three;
if( x + y == z )
cout << "1/3 + 4/3 == 5/3 \n";
else
cout << "1/3 + 4/3 != 5/3 \n";
return 0;
}
PC-lint liefert:
if( x + y == z ) bug777.cpp(15):
Testing floats for equality
PC-lint weist auf ein (wahrscheinlich) unerwartetes
Ergebnis des Vergleichs hin – nämlich false wegen
Rundungsfehlern, die bei float's auftreten.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
353
9. Qualitätssicherung
Formale Verifikation (Beispiel einer analytischen statischen QS-Maßnahme)
 Es wird mathematisch bewiesen,
 dass ein Programm zu zulässigen Eingabewerten die richtigen Ergebnisse
(Ausgabewerte) liefert, d.h. richtig ist und
 dass der Algorithmus in jedem Fall terminiert.
 Vorgehen bei der formalen Verifikation
 Jede Funktionalität eines Softwaresystems hat die Aufgabe,
- aus bestimmten Anfangsbedingungen über Daten („precondition“)
- bestimmte Endbedingungen über Daten („postcondition“) herbeizuführen.
 Dies ist wie ein Vertrag zu sehen zwischen demjenigen,
- der eine Funktionalität benutzt,
- und dem, der sie erfüllt.
 Die formale Verifikation eines Systems verläuft nun folgendermaßen:
 Durch formales Anwenden von Regeln der mathematischen Prädikatenlogik wird
über die Wirkungsweise des Algorithmus der Beweis geführt, dass er aus seinen
Anfangsbedingungen die Endbedingungen herstellt.
 Gelingt dieser Beweis, erfüllt das System exakt die Spezifikation und ist korrekt.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
354
9. Qualitätssicherung
Kontrollfragen Qualitätssicherung
 Was ist der Unterschied zwischen Prozessqualität und Produktqualität?
 Angenommen, Sie verwenden einen Standard zur Sicherung der Prozessqualität
(z.B. ISO 9001). Entsteht dadurch eine gute Produktqualität?
 Angenommen, Sie unternehmen zur Sicherung der konstruktiven Produktqualität
erhebliche Anstrengungen. Entsteht dadurch eine gute Produktqualität?
 Angenommen, Sie unternehmen zur Sicherung der analytischen Produktqualität
erhebliche Anstrengungen. Entsteht dadurch eine gute Produktqualität?
Um gesicherte Produktqualität zu erzielen, müssen Sie alle
Maßnahmen gezielt kombinieren!
Software Engineering, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, WS 2013, h_da, Fachbereich Informatik
355
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
10. Metriken
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
356
10. Metriken
Motivation (I)
 Situation
 Projekt mit 100 Mitarbeitern, Laufzeit 3 Jahre
 anschließend 10 Jahre Wartung
 SIE sind Projektleiter
 Woher wissen Sie (als Projektleiter) frühzeitig,







ob das Ergebnis wartbar sein wird
ob die versprochene Funktionalität geboten wird
ob der Code effizient läuft
ob die Tests einfach erstellt werden können
ob das Projekt aus dem Ruder läuft
...
ob die Investition von über 50 Mio. Euro ein Erfolg wird???
Kann man aus Arbeitsergebnissen (automatisch)
Indizien für diese Dinge berechnen!?
 "Messungen" und "Metriken"
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
357
10. Metriken
Motivation (II)
 Situation
 SIE sind einer der 100 Mitarbeiter
 Sie entwickeln selbständig einen Teil
 Woher wissen Sie vor dem Review,








ob Ihr Arbeitsergebnis gut (genug) ist
ob Sie genug Kommentare haben
ob Ihr Code erweiterbar ist
ob Ihr Code wiederverwendbar ist
ob Ihr Code testbar ist
wo Sie Ihr Ergebnis noch verbessern sollten
...
ob Sie ein guter oder schlechter Entwickler sind???
Kann man aus Arbeitsergebnissen (automatisch)
Indizien für diese Dinge berechnen!?
 "Messungen" und "Metriken"
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
358
10. Metriken
Lernziel Metriken
 Sie sollen in diesen Kapitel lernen,







wozu Metriken gedacht sind
was mit Metriken gemessen werden soll
was mit Metriken tatsächlich gemessen wird
welche Standard-Metriken es gibt
wie Tools den Umgang mit Metriken erleichtern
wie Metriken sinnvoll in Projekten eingesetzt werden
welche Gefahren Metriken bergen
Anschließend können Sie in einer vernünftigen Weise mit
Metriken umgehen?!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
359
10. Metriken
Was will man messen?
 Arbeitsfortschritt und
Qualitätseigenschaften
Qualitätsmerkmale aus
Benutzersicht
Qualitätsmerkmale aus
Entwicklersicht
Funktionserfüllung
Effizienz
HW-Effizienz
Zuverlässigkeit
SW-Effizienz (Performance)
Benutzbarkeit
Robustheit
Sicherheit
Fehlertoleranz
Erweiterbarkeit
Änderbarkeit
Wartbarkeit
Verständlichkeit
Übertragbarkeit
Testbarkeit
Wiederverwendbarkeit
Aber wie kann man das messen??
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
360
10. Metriken
Metriken – die Grundidee
 Leite elementare Eigenschaften aus den Arbeitsergebnissen ab:
 z.B. für Code
-
Codegröße (Anzahl der Zeichen, Zeilen etc.)
Anteil an Kommentaren
Anzahl an komplexen Konstrukten (IF, WHILE,...)
Anzahl von Vererbungen
...
 z.B. für die Architektur
- Anzahl der Abhängigkeiten zwischen Klassen
- Größe der Dokumentation
- ...
 Durch Kombination von elementaren Eigenschaften können Aussagen
über SW-Qualitätseigenschaften abgeleitet werden z.B.
 Verständlichkeit
 Wartbarkeit
 …
Es gibt aber viele
Interpretationsmöglichkeiten...
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
361
10. Metriken
Metriken: Einfache Ansätze
 Wie messe ich die Größe eines Programms (einer Funktion)?
 Anzahl Zeilen (LOC)
- Durch viele Anweisungen in einer Zeile wird ein Programm nicht kleiner (einfacher)!
- Durch Leerzeilen oder übertriebene Aufteilung aber auch nicht größer!
 Anzahl Anweisungen
- Durch Zusammenfassung von Einzelanweisungen zu komplizierten Anweisungen wird
ein Programm nicht kleiner!
 Anzahl Bytes
- Durch Sparen von Bytes (z. B. kurze Variablennamen) wird ein Programm auch nicht
kleiner!
Zähle nur die verschiedenen Operanden und die Operatoren
 "Halstead-Metriken"
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
362
10. Metriken
Halstead-Metriken: "Textuelle Komplexität"
 Anzahl der unterschiedlichen Operatoren:
η1
 Anzahl der unterschiedlichen Operanden:
η2
 Anzahl des Auftretens von Operatoren:
N1
 Anzahl des Auftretens von Operanden:
N2
Primitives Beispiel zur
Veranschaulichung des Maßes:
void tausch(float &x, float &y)
{
float z;
z=x;
x=y;
y=z;
}
Operatoren
void
Anz.
1
Operanden
Anz.
x
3
1
y
3
&
2
z
3
float
3
=
3
{ }
1
,
1
;
4
η1 = 8
N1 = 16
η2 = 3
N2 = 9
(
)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
363
10. Metriken
Halstead-Metriken: "Textuelle Komplexität"
 Abgeleitete Maße:
 Größe des Vokabulars:
η = η1 + η2
- tausch: 8+3 = 11
 Länge der Implementierung:
N = N1 + N2
- tausch: 16 + 9 = 25
 Berechnete Länge:
N^ = η1*ld(η1) + η2*ld(η2)
- tausch: N^ = 8*ld(8) + 3*ld(3)
N^ = 24 + 4.75 = 28.75
 Programmgröße (Volumen):
V = N*ld(η)
- V = 25*ld(11) = 25 * 3,5 = 87,5
 es gibt viele weitere Maße mit umstrittener Aussagekraft...
Einfache Zuweisungen zählen genauso wie komplizierte Schleifen!?
 "Strukturelle Komplexität": "McCabe Maß"
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
364
10. Metriken
McCabe-Maß, "zyklomatische Zahl„: Strukturelle Komplexität
 Gibt Auskunft über die Komplexität der Kontrollstruktur einer Funktion
 zyklomatische Zahl z(G):
 Originaldefinition:
z(G) = P
- P = Anzahl der linear unabhängigen Pfade
durch den Programm-Graphen G
 Alternative Berechnung
z(G) = e – n + 2p
- e: Anzahl Kanten von G,
- n: Anzahl Knoten von G,
- p: Anzahl der verbundenen Komponenten
 Alternative Berechnung (für p=1)
z(G) = π + 1 (für p=1)
- π = Anzahl der Verzweigungen über
booleschen Bedingungen in G
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
365
10. Metriken
McCabe-Maß: Programm-Graph
Start
Start
a
a
b
4
3
c
d
6
b
4
3
c
1
2
1
2
d
6
7
7
5
5
e
e
8
9
f
8
9
f
10
10
Ende
Ende
 z(G) = 4
(1.<2,3,7,8,10>, 2.<2,4,6,8,10>, 3.<2,4,6,8,9,8,10>, 4.<1.5>)
<2,3,7,8,9,8,10> ist z.B. linear abhängig (= 3. – 2. + 1.)
 z(G) = e – n + 2p = 10 – 8 + 2 = 4
(10 Kanten, 8 Knoten, 1 Komponente)
 z(G) = π + 1 = 3 + 1 = 4
(Verzweigungen: Start, a, f)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
366
10. Metriken
Bewertung McCabe
 Das McCabe Maß
 ist nur für Code anwendbar
 betrachtet nicht, wie kompliziert eine einzelne Anweisung ist, oder wie stark sie
verschachtelt ist
 dennoch wird das McCabe Maß oft eingesetzt:
"Zerlege jedes Programm mit z(G) ≥ 10 in Teilprogramme,
so dass für jedes Teilprogramm gilt: z(G) < 10"
Aber was macht man, wenn es nicht um Code von Funktionen geht,
sondern Kommunikation zw. Teilen??
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
367
10. Metriken
Maße zur Beurteilung der der Kopplung zwischen Teilen des Systems:
Informationsfluss-Analyse - IF4
<<component>>
Internet_Access
<<component>>
<<component>>
Web_Browser
Theme
Kopplung ist erkennbar an
KommunikationsBeziehungen!
<<component>>
Plugin
 "Informationsfluss-Analyse":
 FIm: "fan-in"
 FOm: "fan-out"
 IF4m(S) = (FIm * FOm)2
Zahl der Datenflüsse, die zu einem Modul m führen
Zahl der Datenflüsse, die von einem Modul wegführen
Maßzahl für den Modul m im System S
n
 IF4(S) = Σ (FIi * FOi)2
Maßzahl für die Architektur des Systems S
i=1
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
368
10. Metriken
Beispiel für die Informationsfluss-Analyse
 Beispiel:
A
x
x
B
y
y, z
C
D
A, B, C, D seien Funktionen und
C ruft A auf mit AufrufParametern y, z und Rückgabeparameter x. Oder
A, B, C, D seien Klassen und
z.B. eine Funktion der Klasse A
ruft eine Funktion der Klasse C
mit Aufrufparameter x auf und
eine Funktion der Klasse C ruft
eine Funktion der Klasse A mit
Aufrufparametern y, z auf, ...
Database
fan-in (FIi)
fan-out (FOi)
FIi * FOi
IF4i = (FIi * FOi)2
A
3
2
6
36
B
0
2
0
0
C
2
2
4
16
D
2
0
0
0
Modul
IF4(S) = 52
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
369
10. Metriken
Relevanz der Maße für den Informationsfluss
 Empirische Studien haben gezeigt:
 Es besteht eine starke Abhängigkeit zwischen Informationsfluss-Maßen und dem
Wartungsaufwand
 Beim “Altern“ der Software entartet sehr oft die Struktur;
 IF4 und die verschiedenen IF4i können aufzeigen, ob und wo ein
Re-Engineering notwendig bzw. sinnvoll wäre
 IF4 kann benutzt werden, um Architekturen miteinander zu vergleichen
 Deutlich geringeres IF4  weniger starke Kopplung unter den Komponenten
 Ein Blob (mit Daten außerhalb des Blobs) zeigt ein sehr hohes IF4
 Welches ist die optimale Größe von Moduln?
 Zu diesem Zweck können kombinierte Maße wie (LOCi, IF4i ) oder
(McCabei, IF4i) benutzt werden, um ausgeartete Module zu lokalisieren
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
370
10. Metriken
Messwerte und Schlussfolgerungen
 Man kann fast alles messen...
Wer viel misst,
misst viel Mist!
(Reinhard K. Sprenger)
 z.B. die Anzahl von Pizzadeckeln im Papierkorb
- als Maß für den Terminverzug
 ...und aus den Messungen fast alles folgern!
 Die Auswahl der richtigen Metriken ist entscheidend
 Die Interpretation der Ergebnisse erfordert viel Erfahrung und Sachkenntnis
 Beispiel 1: Was sagt uns eine Mitarbeiter-Fluktuation von nur 2 Prozent?
 Dass die Angestellten zufrieden sind und es der Firma gut geht? oder
 dass die Mitarbeiter keine Alternative haben, weil die Firma in einer exotischen
Nische lebt?
 Beispiel 2: Was sagt uns die Anzahl der vergangenen Tage seit Projektbeginn
im Vergleich zu anderen Projekten?
 Nichts! Aber mit schicken Grafiken kann Wally seinen (unfähigen) Chef
beeindrucken (Dilbert 1996)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
371
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
10.1 Metriken und Tools
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
372
10.1 Metriken und Tools
Tools
 Tools
 messen und berechnen grundlegende Metriken
 bieten komplexe zusammengesetzte Qualitätsmaße, die Schlussfolgerungen aus
den gemessenen Werten ziehen (durch Verknüpfung und Gewichtung)
Analysierbarkeit
Wartbarkeit
Änderbarkeit
Stabilität
Testbarkeit
STMT
VG
AVGS
COMF
FAN_IN
FAN_OUT
LEVL
PARAval
...
NBCALLING
COND_STRUCT
...
...
Teil des Qualitätsmodells des Testtools Logiscope der Fa. Verilog
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
373
10.1 Metriken und Tools
Komplexe zusammengesetzte Qualitätsmaße
STMT
VG
AVGS
COMF
FAN_IN
FAN_OUT

Anzahl der Statements einer Komponente
Je größer die Anzahl der Statements in einem Programm, um so schwerer ist es zu verstehen,
d.h. um so größer ist der Aufwand zur Fehlersuche oder bei Änderungen in der Wartung.
zyklomatisches Maß nach McCabe
durchschnittliche Länge der Statements
Dieses Maß ist ein komplexes Maß und wird nach folgender Gleichung berechnet:
AVGS=(N1+N2+1) / (STMT+1)
wobei
N1 = Gesamtanzahl der Operatoren (Halstead)
N2 = Gesamtanzahl der Operanden
Je länger eine Anweisung ist, um so größer ist der Aufwand sie zu verstehen.
Kommentarfrequenz
Verhältnis von Kommentaren und Anweisungen.
Zahl der Datenflüsse, die zu einem Modul führen
Je größer diese Zahl für einen Modul ist, um so stärker wird der Modul durch seine Umgebung
(die rufenden Module) beeinflusst.
Zahl der Datenflüsse, die von einem Modul wegführen
Je größer diese Zahl für einen Modul ist, um so größer ist der Einfluss dieses Moduls auf seine
Umgebung ( besonders genau überprüfen)
Analysierbarkeit =
f1*STMT + f2*VG + f3*AVGS + f4*COMF + f5*FAN_IN + f6*FAN_OUT
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
374
10.1 Metriken und Tools
Darstellung der Messergebnisse: Kiviatdiagramm
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
Ausreißer!
 Ursache
untersuchen!
375
10.1 Metriken und Tools
Darstellung der Messergebnisse: Kontrollflussgraph
Jede Verzweigung ist
ein If- bzw. CaseStatement
Was bedeutet ein
solches "Gebirge" für
die Testbarkeit?
Kontrollflussgraph eines Teils der Implementierung des Spiels Carcasonne
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
376
10.1 Metriken und Tools
Metriken und Tools
 Mit modernen Tools können sehr viele, verschiedene, vordefinierte Metriken auf
die Arbeitsergebnisse (vor allem auf Code) angewandt werden
 Die Darstellungen erlauben eine schnelle Identifizierung von Ausreißern und die
interaktive Analyse der Ursachen
 Die Versuchung ist groß, viele Metriken zu verwenden
 Die Versuchung ist groß, Ausreißer in allen Metriken zu analysieren
 Die intelligente Auswahl der Metriken und Grenzwerte wird umso wichtiger
Tools erleichtern den Umgang mit Metriken enorm –
aber sie ersetzen nicht die Denkarbeit!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
377
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
10.2 Umgang mit Metriken
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
378
10.2 Umgang mit Metriken
Gefahren von Metriken
 Metrik-Teufelskreis
1. Das Projekt hat Terminverzug
2. Das Management will den Grund für den Verzug verstehen und fordert
detaillierte Metriken
3. Die Mitarbeiter sammeln Daten für Metriken anstatt produktiv zu arbeiten
4. GOTO1
 Metrik-Overkill
 ein von Metriken und Zahlen überzeugter Manager lässt zu viele Daten erfassen
 Die Mitarbeiter sammeln Daten für Metriken anstatt produktiv zu arbeiten
Dilbert: ... Here's my time report, in fifteen minute increments...
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
379
10.2 Umgang mit Metriken
Umgang mit Metriken
 Metriken - ein normales und wichtiges Arbeitsmittel in modernen Projekten
 es sollten einige wenige angebrachte Metriken ausgewählt und konsequent
verfolgt werden
 Metriken liefern Hinweise auf potenzielle Problemstellen – aber nicht jede
Verletzung der Metrikvorgabe muss ein Problem sein
(Manchmal sind Dinge auch einfach kompliziert)
 Mit modernen Tools können Metriken schnell berechnet und die Ergebnisse übersichtlich visualisiert werden. Dies liefert wertvolle Hinweise für die Entwicklung.
 Die Interpretation der Ergebnisse erfordert oft viel Erfahrung und Sachkenntnis
 Metriken müssen von allen Beteiligten mit Verstand eingesetzt werden
 Ein Entwickler kann Metriken immer austricksen! Kennt man die
Berechnungsvorschrift, kann man die Metrik auch manipulieren.
 Ein Manager darf die Ergebnisse der Metriken nicht überbewerten
"Nicht alles, was zählt, kann gezählt werden, und nicht alles was
gezählt werden kann, zählt" (Albert Einstein)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
380
10. Metriken
Kontrollfragen Metriken
 Was halten Sie von LOC (Lines of Code) zur Beurteilung Ihres
Arbeitsfortschritts? Welche Metrik ist besser?
 Wozu sind Metriken wichtig?
 Wofür können Metriken definiert werden?
 Warum sind Metriken oft bei Managern beliebt und bei Entwicklern unbeliebt?
 Was passiert, wenn zusätzliche Metriken / Maßzahlen erfasst werden, um den
Verzug eines Projekts zu verstehen?
 Wie können Tools die Einhaltung von Metriken mit Sollwerten visualisieren?
 Welche Bedeutung hat das Maß IF4?
Können Sie jetzt in einer vernünftigen Weise mit
Metriken umgehen?!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
381
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
11. Vorgehens- und Prozessmodelle
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
382
11. Vorgehens- und Prozessmodelle
Lernziel Vorgehensmodelle
 Sie sollen in diesen Kapitel lernen,




was ein Vorgehensmodell beinhaltet
wozu Vorgehensmodelle wichtig sind
was die verschiedenen Modelle auszeichnet
wodurch sich die verschiedenen Modelle unterscheiden
Anschließend können Sie zu einem Projekt ein
Vorgehensmodell empfehlen!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
383
11. Vorgehens- und Prozessmodelle
Vorgehen in Projekten am Beispiel
Projekt A
Projekt B
x-te Weiterentwicklung mit
langer Wartung
innovatives Produkt; basierend auf
traditionellem Produkt
Beispiel
traditionelles Autoradio
neuartiges Navigationssystem
Auftraggeber
weiß genau was er will
weiß nicht wirklich was er will
weiß genau, wie es geht
weiß auch nicht so genau was sinnvoll ist
Projektart
Auftragnehmer
 Wie würden Sie diese Projekte angehen?
 In welcher Reihenfolge würden Sie die bekannten Entwicklungsphasen
durchlaufen?
 Würden Sie die Phasen einmal vollständig, oder eher inkrementell durchlaufen?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
384
11. Vorgehens- und Prozessmodelle
Die Grundidee für Vorgehensmodelle am Beispiel
 Die Projekte erfordern ein unterschiedliches Durchlaufen der Phasen!
Analyse des
Teilsystems
Analyse
Def. des Teilsystems
Definition
Analyse des
Teilsystems
Projekt B
iterativ mit
Teilsystemen
Analyse des
Teilsystems
.
Entwurf
.
Entwurf des
Teilsystems
Abnahme des
Teilsystems
Abnahme
Betrieb & Evaluation
des Teilsystems
Betrieb und
Evaluation
Def. des Teilsystems
.
Implementierung und
Test des Teilsystems
Implementier
ung und Test
Projekt A
ein Durchlauf,
alles sofort vollständig
Def. des Teilsystems
Entwurf des
Teilsystems
Entwurf des
Teilsystems
Implementierung und
Test des Teilsystems
Implementierung und
Test des Teilsystems
Abnahme des
Teilsystems
Abnahme des
Teilsystems
Betrieb & Evaluation
des Teilsystems
Betrieb & Evaluation
des Teilsystems
 ähnliche Projekte kann man immer wieder so durchführen
 die Abarbeitung der Phasen kann als Modell dokumentiert werden
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
385
11. Vorgehens- und Prozessmodelle
Warum braucht man Vorgehensmodelle?
 Softwareentwicklung ist ein komplexer Prozess und erfordert ein
systematisches, geplantes Vorgehen
 Ein Vorgehensmodell
 gibt einen bewährten Leitfaden für den Entwicklungsprozess
 erlaubt die Beschreibung, Optimierung und Zertifizierung von
Entwicklungsprozessen
 Vorgehensmodelle unterstützen die geplante, erfolgreiche
Durchführung von Softwareentwicklungen,
d.h. innerhalb definierter Zeit, Kosten und Qualität!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
386
11. Vorgehens- und Prozessmodelle
Was ist ein Vorgehensmodell?
 Ein Vorgehensmodell legt fest:







die Reihenfolge des Arbeitsablaufs (Entwicklungsstufen, Phasenkonzepte)
Jeweils durchzuführende Aktivitäten in den Phasen
Definition der Teilprodukte (Arbeitsergebnisse)
Fertigstellungskriterien und Abnahmekriterien
Notwendige Mitarbeiterqualifikationen
Verantwortlichkeiten und Kompetenzen
Anzuwendende Standards, Richtlinien, Methoden und Werkzeuge
 Für ein konkretes Softwareentwicklungsprojekt muss das Vorgehensmodell
konkretisiert werden (neu-deutsch: Tailoring)
 Ein Vorgehensmodell ist eine systematisch dokumentierte Vorlage für die
Durchführung und das Management von Projekten!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
387
11. Vorgehens- und Prozessmodelle
Welche Vorgehensmodelle gibt es?
Klassische Modelle
neue, komlexe Modelle











(Code & Fix)
Wasserfall-Modell
Evolutionäres Modell
Inkrementelles Modell
V-Modell
Prototypen-Modell
...
Unterscheiden sich in der
Abfolge von Phasen
Rational Unified Process (RUP)
V-Modell XT
Agile Entwicklung
...
Definieren den Gesamtprozess mit
Definition der Aktivitäten,
Arbeitsergebnissen etc. der
einzelnen Prozessschritte (Phasen)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
388
11. Vorgehens- und Prozessmodelle
Code & Fix
Erstelle erste
Version
Ausmusterung
Ändern bis der
Kunde
zufrieden ist
Einsatz der
Version
Ein häufig anzutreffendes
"Vorgehensmodell"
Entwicklung
Verbesserung
Nicht jedes Vorgehensmodell sorgt für gute Qualität!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
389
11. Vorgehens- und Prozessmodelle
Bewertung von Code & Fix
Vorteile
Nachteile
 Geringer Managementaufwand
 Schlechtere Wartbarkeit,
Zuverlässigkeit und
Übersichtlichkeit des Codes
 Zufriedene Kunden
 Starke Abhängigkeit vom
individuellen Programmierer
 Differenzen über Funktionsumfang
zwischen Entwickler und Anwender
 Keine Entwicklung von
Dokumentation und Testfällen
 Für große Projekte ungeeignet!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
390
11. Vorgehens- und Prozessmodelle
Das Wasserfall-Modell
Analyse
 Sequentieller Entwicklungsablauf
 Top-Down-Vorgehen
Definition
 Durchführung jeder Aktivität in der
richtigen Reihenfolge und in vollem
Umfang
Entwurf
 Abgeschlossene Dokumentation am
Ende jeder Aktivität
 Iterationen nur zwischen zwei
aufeinanderfolgenden Stufen
Änderungen
während der
Entwicklung
Änderungen /
Fehlerkorrektur
während der
Wartung
Implementier
ung und Test
Abnahme
"Wir machen
gleich alles
richtig!"
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
Betrieb und
Evaluation
391
11. Vorgehens- und Prozessmodelle
Bewertung des Wasserfall-Modells
Vorteile
 Extrem einfaches Modell
 Geringer Management-Aufwand
 Disziplinierter, kontrollierbarer und
sichtbarer Prozessablauf
Trotz aller Nachteile sehr beliebt bei
Managern
- und immer noch weit verbreitet!
Auch das traditionelle V-Modell ist
ein Wasserfallmodell
Nachteile
 Strenge Sequentialität oft nicht
sinnvoll/machbar
 Möglichkeit von Feedback kaum
gegeben
 Erkennen von Problemen erst am
Ende
 Benutzerbeteiligung nur bei
Anforderungen und im Betrieb
 Gefahr einer zu starken Gewichtung
der Dokumentation
 Lange Projektlaufzeit, keine
Zwischenversionen zu früheren
Zeitpunkten
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
392
11. Vorgehens- und Prozessmodelle
Nullvers.
Das evolutionäre Modell
 Kernanforderungen des Auftraggebers
führen direkt zur „Nullversion“ (wird
ausgeliefert)
Analyse des
Teilsystems
Definition des
Teilsystems
 Konzentration auf lauffähige
Teilprodukte
 Stufenweise Entwicklung durch
Modell, Steuerung durch die Erfahrung
der Benutzer
 Vermeidung der Implementierung
eines Produkts gleich in voller Breite
zum nächsten
Zyklus
Entwurf des
Teilsystems
Änderungen
Implementierung
und Test des
Teilsystems
 Neue Anforderungen  neue Version
 Integration von Pflegeaktivitäten in
den Prozess
Baue erst den Systemkern –
dann ergänze den Rest!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
Abnahme des
Teilsystems
Betrieb und
Evaluation des
Teilsystems
393
11. Vorgehens- und Prozessmodelle
Bewertung des evolutionären Modells
Vorteile
Nachteile
 Einsatzfähige Produkte für den
Auftraggeber in kurzen Abständen
 Eventuell mangelnde Flexibilität der
Nullversion zur Anpassung an
unvorhersehbare Evolutionspfade
 Integration der Erfahrungen der
Anwender in die Entwicklung
 Überschaubare Projektgröße
 Eventuell komplette Änderung der
Architektur in späteren Versionen
 Korrigierbare Entwicklungsrichtung
 Keine Ausrichtung auf einen
einzigen Endtermin
Gut geeignet, wenn der Auftraggeber noch nicht sicher ist, was er will!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
394
11. Vorgehens- und Prozessmodelle
Das iterativ-inkrementelle Modell
 Möglichst vollständige
Erfassung und Modellierung der
Anforderungen an das zu
entwickelnde Gesamtprodukt
Analyse des
Gesamtsystems
Def. des Gesamtsystems
.
inkl.
Zyklenplanung
 Realisierung der nächsten
Ausbaustufe unter
Berücksichtigung der
Erfahrungen des Auftraggebers
Änderungen
mit der laufenden Version
 Einsatzfähiges System für den
Auftraggeber schon nach relativ
kurzer Zeit
SWE
Entwurf des
Teilsystems
Anpassungen auf
Grund von Erfahrung
mit dem Teilsystem
zum nächsten
Zyklus
Implementierung und
Test des Teilsystems
Abnahme des
Teilsystems
Plane erst das
Betrieb & Evaluation
Gesamtsystem – dann
des Teilsystems
baue in Zyklen die
© Teilsysteme!
Prof. Dr. W. Weber, h_da, Fachbereich Informatik
395
11. Vorgehens- und Prozessmodelle
Bewertung des inkrementellen Modells
Vorteile
Nachteile
 zusätzlich zu den Vorteilen der
evolutionären Entwicklung:
 Vollständige Spezifikation nicht
immer möglich
 Inkrementelle Erweiterungen passen
zum bisherigen System
 die Entwicklung der ersten Version
dauert länger als beim evolutionären
Modell
Gut geeignet, wenn der wesentliche Inhalt klar ist,
aber viele Details offen sind!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
396
11. Vorgehens- und Prozessmodelle
Prototypen
 Erstellung von lauffähigen Prototypen zur
Prototypen spezifizieren
frühzeitigen Klärung von Problemen
 Auswahl alternativer Lösungsmöglichkeiten
 Sicherstellung der Realisierbarkeit
Prototypen herstellen
 Vervollständigen, Korrigieren von Anforderungen
 Einbeziehen von Anwendern in die Entwicklung
Prototypen(-Phasen)-Modell
 Schrittweise Weiterentwicklung des ersten
Prototyps / der frühen Produktversionen (addon-Prototyp s. u. )
Experimentieren
Prototyp
akzeptiert?
ja
nein
Ändern und erweitern
Probieren wir erst mal
aus, ob es so klappt /
ob es so gemeint ist!
Prototypen-Modell
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
397
11. Vorgehens- und Prozessmodelle
Prototypen
 Verwendung von Prototypen nicht nur im Prototypen-Modell, sondern auch bei
Verwendung anderer Vorgehensmodelle zur Prüfung der Machbarkeit, Verbesserung
von Anforderungsspezifikation und Entwurf.
Definition:
 Ein Prototyp ist ein Experimentiersystem, mit dessen Hilfe Fragestellungen zu
Eigenschaften des endgültigen Produkts oder seiner Einsatzumgebung geklärt
3.
werden
 Prototyping ist die systematische Anwendung von Prototypen
2.
 3 Klassifikationskriterien:
1.
1. Was wird durch den Prototyp getestet?
2. Wie ist der Prototyp aufgebaut?
3. Inwieweit findet der Prototyp Verwendung bei der Implementierung des endgültigen
Systems?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
398
11. Vorgehens- und Prozessmodelle
1. Was wird durch den Prototyp getestet? (I)
 Benutzer-Prototyp (Explorativer Prototyp)
 dient als Kommunikationsgrundlage zwischen Endbenutzer und den
Systementwicklern
 Spätere Arbeitsweise wird durchgespielt
 Schwächen und Fehler der Spezifikation werden erkannt und vor der
Weiterarbeit beseitigt
 Beispiel:
- Implementierung (eines Teils) der Benutzeroberfläche
•
•
ohne oder
mit darunterliegender Logik und Datenbank
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
399
11. Vorgehens- und Prozessmodelle
1. Was wird durch den Prototyp getestet? (II)
 Technischer Prototyp (Experimenteller Prototyp,
Labormodell)
 dient den Entwicklern intern als Bewertungsgegenstand, der Fragen der
technischen Umsetzung und Realisierbarkeit klären soll
 Beispiel für Zielsetzungen von technischen Prototypen:
-
Überprüfung der Machbarkeit
Abschätzung des Aufwandes / des Zeitbedarfs / der Kosten der Realisierung
Vergleich von Alternativen
Performance-Tests
Fragen der Konfiguration (Anschluss von Druckern, Vernetzung, …)
Einsatz von Tools
......
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
400
11. Vorgehens- und Prozessmodelle
2. Wie ist ein Prototyp aufgebaut? (I)
horizontaler Prototyp
 z. B. nur Schnittstelle zum Benutzer
 Mit Hilfe solch eines Prototyps kann das Arbeiten mit dem System gezeigt
werden
 Da die tieferen Ebenen fehlen, liefert das System normalerweise falsche Werte
horizontaler Prototyp
User-Schnittstelle
Verarbeitungslogik
Dateizugriffe
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
401
11. Vorgehens- und Prozessmodelle
2. Wie ist ein Prototyp aufgebaut? (II)
vertikaler Prototyp
 exemplarisch ausgewählte Teilfunktionen des zukünftigen Systems vollkommen
realisieren
 z.B. Performanz einer kritischen Anwendung
 auch als explorativer Prototyp
vertikaler Prototyp
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
402
11. Vorgehens- und Prozessmodelle
2. Wie ist ein Prototyp aufgebaut? (III)
Gesamtsystem mit Lücken
 alle Teilsysteme realisiert außer z.B.
-
Plausibilitätsprüfungen
Ausnahme- und Fehlersituationen
komplexe Berechnungsroutinen
....
Prototyp mit Lücken
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
403
11. Vorgehens- und Prozessmodelle
3. Inwieweit findet der Prototyp Anwendung im endgültigen System?
Throw-away-Prototype (Quick-and-dirty-P, RapidSpecification-P.)
 findet keine Verwendung bei nachfolgender Implementierung
 dient einzig und allein zur Entwicklung korrekter, robuster Spezifikationen
Add-on-Prototype (Rapid-Cyclic-Prototype)
 wird bei der Implementierung des Zielsystem mitverwendet
 ausgehend von einem ersten Add-on-Prototype wird zum Zielsystem
weiterentwickelt
z. B. Prototypenmodell:
In jeder Iterationsstufe
 wird der schon entwickelte Teil weiter verbessert
 wird System vom Umfang her erweitert
 wird weiterentwickelt, bis das Zielsystem vorliegt
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
404
11. Vorgehens- und Prozessmodelle
Bewertung Prototypen / Prototypen-Modell
Vorteile
Nachteile
 Sinnvolle Integration in andere
 Erhöhter Entwicklungsaufwand
Vorgehensmodelle möglich
 Schaffung einer starken
Rückkopplung zwischen
Endbenutzern und Herstellern
 Schnelle Erstellung von Prototypen
durch geeignete Werkzeuge
durch zusätzliche Herstellung von
Prototypen
 Gefahr der Umwandlung eines
„Wegwerf-Prototyps“ zu einem Teil
des Endprodukts aus
Termingründen
 Prototypen "ersetzen" fehlende
Dokumentation
Prototypen sind geeignet, um das Entwicklungsrisiko zu reduzieren!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
405
11. Vorgehens- und Prozessmodelle
Rational Unified Process
 Der Rational Unified Process (RUP) ist ein von der Firma Rational
Software parallel zur Unified Modeling Language entwickeltes
Vorgehensmodell zur Softwareentwicklung
 Der RUP definiert 6+3 grundlegende Disziplinen
und
 orthogonal dazu 4 Phasen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
406
11. Vorgehens- und Prozessmodelle
Disziplinen (Arbeitsschritte) im RUP
Wasserfallmodell
mit verwaschenen Grenzen
und Iterationen
Disciplines (Arbeitsschritte)
Geschäftsprozessmodellierung
Anforderungsanalyse
Analyse & Design
Implementierung
Test
Auslieferung
Projektmanagement
Konfigurations- und Änderungsman.
Erst. d. Umgebung, Konfig. d. Prozesses
Zeit
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
407
11. Vorgehens- und Prozessmodelle
Disziplinen (Arbeitsschritte) und Phasen im RUP
Phases
Disciplines (Arbeitsschritte)
Konzeption
Ausarbeitung
Erstellung
Übergang
Quelle: Rational Unified Process 2000 Tool
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
408
11. Vorgehens- und Prozessmodelle
Disziplinen (Arbeitsschritte) und Phasen im RUP
Beispiel:
Auftragserfassung im Kernsystem
Auftragserfassung im fertigen System (mit Sonderfällen)
Disciplines (Arbeitsschritte)
Implementierungs-Meilensteine:
Machbarkeitsstudien
mit Prototyping
Kernsystem incl.
Tests
fertiges
System
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
System incl.
Anpassungen
409
11. Vorgehens- und Prozessmodelle
Bewertung: RUP / UP
Vorteile
Nachteile



Durch die Überlappung verkürzt sich Dauer
RUP stellt hohe Anforderungen an das
des Projektes
Management durch die hohe Parallelität des
Unterstützt die Planung und Steuerung von
Entwicklungsprozesses
Projekten durch Standardisierung
Für jeden (Teil-)Prozess:

Die Anforderungen werden relativ früh
festgelegt
Welche Arbeiten,
welche Arbeitsergebnisse,
wer verantwortlich.

Anpassbar an projektspezifische
Anforderungen (Tailoring)

Gute Anbindung zur UML

Gut dokumentiertes Modell
RUP ist ein gut dokumentiertes und
modernes iteratives Modell
– aber nicht evolutionär!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
410
Rest von RUP nur zur Info, nicht prüfungsrelevant
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
411
11. Vorgehens- und Prozessmodelle
Unterschied zwischen Rational Unified Process (RUP) und Unified Process (UP)
 UP wurde 1999 von Jacobson veröffentlicht
 RUP ist eine konkrete Implementierung des UP durch die Firma Rational nach 1999
 RUP wird von Rational (inzwischen aufgekauft von IBM) als Produkt vertrieben,
Rational bietet für RUP eine Reihe von darauf abgestimmte Formularen und
Werkzeugen an.
 UP teilt Projekte in folgende Disziplinen (Arbeitsschritte) ein:
 Anforderungen
 Analyse
 Entwurf
 Implementierung
 Test
Wir sehen, es fehlen gegenüber dem RUP:
 Geschäftsmodellierung
 Auslieferung
 Konfigurations- und Änderungsmanagement (siehe Kap 9)
 Projektmanagement (mit Risiko-, Personal-, Budget- und Vertragsmanagement)
 Erstellung und Pflege der Infrastruktur
Selbstverständlich brauchen wir in UP auch die in RUP explizit zusätzlich erwähnten Disziplinen.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
412
11. Vorgehens- und Prozessmodelle
Phasen und Ergebnisse
Ergebnisse (Produkte) der
GeschäftsprozessModellierung
Siehe auch S. 39-45 in [Arlow, Neustadt]
Inception Phase ("Konzeption", "Proj.definition")
Elabor.
Haupt-Geschäftsfälle sind definiert
.
.
Anforderungsdefinition
Projektziele, Schlüsselanforderungen (Anwendungsfälle Kernsystem), Akteure
Visionen-Dokument mit Hauptanforderungen, Funktionen und Grenzen des
Gesamtsystems , Priorisierung der Anforderungen, Projekt-Glossar,
.
Analyse, Design
Erster Entwurf der Systemarchitektur, Schnittstellen zu anderen Systemen
Nachweis der Machbarkeit und Brauchbarkeit durch technische Studien
Implementierung u. Test
Nachweis der Machbarkeit und Brauchbarkeit durch definierte technische / explorative
Prototypen
.
.
.
Kosten-, Zeitschätzung und Projektplanung mit genau definierten Meilensteinen,
Risikoanalyse, Nutzen des Systems ist dargestellt, Kosten-Nutzenanalyse liegt vor,
Groben Kosten- und Terminplan liegt vor.
.
Auslieferung
ProjektManagement
Env: Infrastruktur eingerichtet
Stakeholder haben den obigen Punkten zugestimmt
und entschließen sich, das Projekt fortzuführen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
413
11. Vorgehens- und Prozessmodelle
Phasen und Ergebnisse
Ergebnisse (Produkte) der
GeschäftsprozessModellierung
Siehe auch S. 39-45 in [Arlow, Neustadt]
Elaboration Phase ("Ausarbeitung ", "Entwurf")
Constr.
Mit den Stakeholder überarbeitetes endgültiges Gesamtgeschäftsprozessmodell als
Workflow mit verbalen Beschreibungen liegt vor
.
UML Use Case Diagramm (fertig), UML Use Case Beschreibungen (fast fertig)
nichtfunktionale Anforderungen sind definiert
.
.
Analyse, Design
Statische und dynamische UML-Modelle zu Analyse (fertig),
Architektur (fertig), Design (zum großen Teil fertig)
Benutzerdokumentation (begonnen)
Implementierung u. Test
Ein belastbares, robustes, ausgetestetes, ausführbares Kernsystem (Prototyp)
Testplan und Testfälle (fast fertig)
.
Kernsystem (zum Prüfen) ausgeliefert
.
Detaillierter Projektplan, mit einer realistischen Einschätzung über benötigte Zeit,
Geld und weitere Resourcen,
verfeinerte Risikoanalyse, Kosten-Nutzenanalyse liegt vor.
.
Anforderungsdefinition
Auslieferung
ProjektManagement
Geschäftsmodell ist mit Projektplan abgestimmt und von Stakeholdern genehmigt
Stakeholder entschließen sich, das Projekt fortzuführen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
414
11. Vorgehens- und Prozessmodelle
Phasen und Ergebnisse
Ergebnisse (Produkte) der
GeschäftsprozessModellierung
Siehe auch S. 39-45 in [Arlow, Neustadt]
Construction Phase ("Erstellung", "Konstruktion")
Trans.
Alle Produkte sind auf dem neuestem Stand und konsistent zueinander (fertig)
.
Anforderungsdokument mit zusätzlich gefundene Anforderungen (fertig)
.
Benutzerdokumentation und Help-Bildschirme fertig
Alle übrigen Teile sind fertig
.
Implementierung u. Test
Ein genügend belastbares, robustes, ausgetestetes, ausführbares Gesamtsystem,
um es an den Benutzer auszuliefern,
Beta-Test fertig
.
Auslieferung
Teilsysteme wurden bereits ausgeliefert
Schulungsunterlagen sind erstellt
.
Endgültiger Installations- und Einführungsplan
Nachkalkulation der Kosten und Schwachstellenfindung als Grundlage für nächste
Projekte
.
Anforderungsdefinition
Analyse, Design
ProjektManagement
Env: Zielumgebung vorbereitet
Stakeholder habe der Auslieferung der Software zugestimmt
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
415
11. Vorgehens- und Prozessmodelle
Phasen und Ergebnisse
Ergebnisse (Produkte) der
GeschäftsprozessModellierung
Siehe auch S. 39-45 in [Arlow, Neustadt]
Transition Phase ("Übergang", "Übergabe")
Alle Produkte sind auf dem neuestem Stand und konsistent zueinander
Alle Produkte sind auf dem neuestem Stand und konsistent zueinander
Anforderungsdefinition
Alle Produkte sind auf dem neuestem Stand und konsistent zueinander
Analyse, Design
Implementierung u. Test
Auslieferung
ProjektManagement
Env: Zielsystem eingerichtet
Installiertes abgenommenes System, Benutzer-Test ist abgeschlossen, gefundene
Fehler sind korrigiert, SW ist an evtl. zusätzlich gefundene / geänderte Anforderungen
angepasst
Alle für den Kunden notwendigen Produkte sind ausgeliefert, Software ist
installiert u. für spezielle Benutzer konfiguriert, Daten sind übernommen, Schulungen
sind durchgeführt, Benutzer wurde bei der Handhabung des Systems unterstützt,
Projekt-Abschluss Review ist durchgeführt.
Sämtliche Projektdaten sind im Unternehmen archiviert
Plan zur weiteren Unterstützung des Benutzers ist abgestimmt
Stakeholder sind (hoffentlich) zufrieden
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
416
11. Vorgehens- und Prozessmodelle
Phasen und Ergebnisse
 Iterationen
 Bei größeren Projekten sind insbesondere die Phasen Ausarbeitung, Erstellung und
Übergang in mehrere Iterationen unterteilt.
 Nach jeder Iteration ist man den Endziel etwas näher gekommen und es sind weitere
Ergebnisse (Produkte) entstanden.
 Es entstehen u. a. Zwischenversionen des lauffähigen Programms (incl. Dokumentation),
die entweder nur intern zur Bewertung des Arbeitsfortschritts dienen oder die an den
Kunden zum Testen oder schon für den produktiven Einsatz ausgeliefert werden.
 Man spricht von einem iterativ inkrementellen Prozess, da in jeder Iteration ein Inkrement
(Produkte eines Arbeitsschritts, d. h. UML-Modelle, ..., lauffähiger Code) zum System
hinzugefügt wird. (Allerdings können die verschiedenen Arbeitsschritte zu einem
Programmteil in unterschiedlichen Iterationen ablaufen! – s. nächste Folie)
 Im Gegensatz zu dem normale íterativ-inkrementellen Ansatz können sich hier die Zyklen
überlappen, d. h. der Folgezyklus beginnt, bevor der Vorgängerzyklus abgeschlossen ist.
 Nicht nur die Ziele und Produkte der einzelnen Disziplinen,
sondern auch die Ziele und Produkte der Iterationen (Meilensteine) müssen definiert sein
und durch Reviews überprüft werden.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
417
11. Vorgehens- und Prozessmodelle
V-Modell-XT
 Verbindliches Vorgehensmodell bei der Vergabe von Entwicklungsprojekten durch
Bundesbehörden
 V-Modell (1988) -> V-Modell 97 (1997) -> V-Modell XT (2005)
 XT = extreme Tailorig -> kann durch Tailoring an unterschiedliche Projektarten angepasst
werden
 Es wird vom Staat ein rechnerunterstütztes Tailoringsystem angeboten
 Die zugeschnittene Ausprägung des V-Modell-XT ist abhängig von
 dem „Projekttyp“ (Projekt aus Auftragnehmer oder Auftraggeber-Sicht)
 weiteren „Projektmerkmalen“ (Fertigprodukt, Projekt mit hohem Risiko,...)
 der „Projektdurchführungsstrategie“ (inkrementelle Entwicklung, komponentenbasierte
Entwicklung, agile Entwicklung, Wartung, ...)
 ausgewählten „Entscheidungspunkten“ (=Meilensteine: z. B. System spezifiziert, ..) und
einer vorgeschlagenen Reihenfolge der Entscheidungspunkte (Workflow)
 Zu jeden Entscheidungspunkt werden Produkte vorgeschlagen, die beim Eintreten des
Entscheidungspunkts vorliegen müssen
 gewissen Projekttypen können gewissen „Vorgehensbausteine“ zugeordnet werden
(Vertragsabschluss(AG), Evaluierung Fertigprodukte, Systemerstellung)
Alle Abbildungen in diesem Kapitel aus : V-Modell XT, Release 1.3
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
418
V-Modell-XT - Tailoringsystem
11. Vorgehens- und Prozessmodelle
V-Modell-XT - Entscheidungspunkte, Projektdurchführungsstrategie
jeder Entscheidungspunkt
hat mehrerer Produkte
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
420
Rest von V-Modell-XT ob nur zur Info, nicht prüfungsrelevant
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
421
V-Modell-XT - Metamodell
Projektmerkmale
1..3
1..2
1..*
Projekttyp
Vorgehensbausteingruppe
optional
1
1..4
1..*
mandatory
1..*
Projektdurchführungsstrategie
Vorgehensbaustein
1
1..* 1..*
{ordered as 1..*
1..*
workflow}
Entscheidungspunkte
1
1..9
1..*
1..*
1..*
Produkt-Gruppe
1
1..*
1..*
is dependant on
Produkte
1..*
contribute
1..*
Rolle
1..*
responsible
1
1
1
1..*
Aktivität
1..*
1..*
Aktivitäts-Gruppe
1
1..*
Aktivitätsschritt
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
422
11. Vorgehens- und Prozessmodelle
V-Modell-XT - Vorgehensbausteine
z. B. SW-Entwicklung
-> Systemerstellung
-> Qual-Sicherung etc.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
423
11. Vorgehens- und Prozessmodelle
V-Modell-XT - Vorgehensbausteine, Entscheidungspunkte
V-Modell-Kern
Schnittstelle
zum
Auftraggeber
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
424
11. Vorgehens- und Prozessmodelle
Agile Softwareentwicklung
http://agilemanifesto.org
 Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen
Softwareentwicklungsprozessen wie RUP oder V-Modell
 Idee: Schnell eine einsetzbare Software ausliefern und inkrementell (in kurzen
Zyklen) in engem Kontakt mit dem Kunden ausbauen
 "Agile Werte" bilden das Fundament der Agilen Softwareentwicklung
 Offenheit und Kommunikation statt Formalismen
 Die Grundprinzipien der agilen SW-Entwicklung (agiles Manifest [Beck,…]) stellen
● Individuen und Interaktion
über
● Prozesse und Werkzeuge
● Lauffähige Software
über
● umfassende Dokumentation
● Zusammenarbeit mit dem Kunden
über
● Vertragsverhandlungen
● Reaktion auf Änderungen
über
● Befolgung eines Plans
"Obwohl die rechten Punkte ihren Wert haben,
bewertet die agile SW-Entw. die linken höher."
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
425
11. Vorgehens- und Prozessmodelle
Die agile SW-Entwicklung – die Grundidee
 "Der Kunde kennt die wirklichen Anforderungen zum Projektbeginn
meist noch nicht komplett! Er fordert Features, die er nicht braucht,
und vergisst solche, die benötigt werden!"
 Wie begegnet die agile Methode typische Gefahren für Software-Entwicklungsprojekte:
 Unbenutzbarkeit aufgrund von Programmierfehlern
- Lösung: Viele und frühe Tests
 Unbenutzbarkeit aufgrund von Fehlentwicklung
- Lösung: Kunde mit in den Entwicklungsprozess einbeziehen
 Unwartbarkeit
- Lösung: Viele und frühe Tests
 Zeitplan nicht einhaltbar
- Lösung: Nur Implementieren, was höchstes Nutzen/Aufwand-Verhältnis hat
 "Featuritis" ("Vielleicht brauchen wir einmal dieses Feature...")
- Lösung: Lass es!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
426
11. Vorgehens- und Prozessmodelle
Die agile SW-Entwicklung – die Grundidee
 verzichte auf einen strikten Anforderungskatalog
 Kundenwünsche, die sich noch während der SW-Entwicklung ergeben,
werden einfach noch berücksichtigt
 implementiere nur die im aktuellen Iterationsschritt benötigten Merkmale
 durchlaufe immer wieder in kurzen Zyklen (typ. eine Woche) sämtliche
Disziplinen der klassischen Softwareentwicklung
 (Anforderungsanalyse, Design, Implementierung, Test)
 verwende kurze Release-Zyklen und integriere dauernd
 lauffähige Systeme in kurzen Zeitabständen
 erstelle eine gute Dokumentation
 leicht verständlich, vollständig aber nicht ausschweifend
agile Entwicklung ist ein
evolutionäres Modell
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
427
11. Vorgehens- und Prozessmodelle
Agile Vorgehensweisen
Agile SW-Entwicklung ist nicht eine bestimmte, sondern ein Überbegriff für verschiedenen
Vorgehensweisen.
 Extreme Programming (K. Beck)
 Adaptive Software Development (J. Highsmith)
 Lean Software Development (M. Poppendieck)
 Crystal (A. Cockburn)
 Scrum (K. Schwaber)
 …
 Wir wollen hier "Extreme Programming" und "Scrum" näher anschauen.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
428
11. Vorgehens- und Prozessmodelle
Die agile Vorgehensweise „Extreme Programming (XP)“
- Grundprinzipien
 Prinzipien (Auswahl)
 Sit together - das gesamte Team entwickelt in einem Raum
 Alle Informationen sind jedem zugänglich (z. B. auch auf an den Wänden)
 Kollektives Eigentum - jeder darf jederzeit jeden Quellcode verändern
 Enge Einbeziehung zum Kunden - "Story-Cards" beschreiben
Anwendungsfälle exemplarisch in Form kurzer Geschichten
 offene und respektvolle Kommunikation - Kritik, Informationen
 Pair-Programming - zwei Programmierer; einer codiert, einer denkt mit
(regelmäßig die Rollen tauschen, Vier-Augen-Prinzip)
 Testgesteuerte Programmierung - erst Unit-Tests schreiben, dann Funktionalität
programmieren
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
429
11. Vorgehens- und Prozessmodelle
Die agile Vorgehensweise „Extreme Programming (XP)“ - Grundprinzipien
 Prinzipien (Auswahl)
 Inkrementelles Design, d. h. Design ist nicht von vornherein festgelegt, sondern
ständig änderbar / erweiterbar.
 Ständige Integration neu erstellter / veränderter Teile. (Build sollte in 10 Minuten
durchführbar sein.)
 Refactoring – systematisches und regelmäßiges Überarbeiten der Ergebnisse:
entferne Redundanz, lösche überflüssige Funktionalität, überarbeite das Design!
 Wöchenzyklen: Meeting mit Planung der Arbeit für eine Woche.
 Quartalszyklus: Meeting mit Besprechung der Themen für nächstes Quartal.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
430
Die agile Vorgehensweise „Scrum“ - Grundprinzipien, Rollen
 Scrum ist ein Prozessmodell für agile Produkt- und Softwareentwicklung.
 Für Scrum sind auch die oben beschriebenen Prinzipien gültig.
 Scrum besteht aus einfachen Arbeitstechniken und Ritualen sowie
wenigen Rollen und Artifakten.
 Eine kurze, aber etwas detailliertere Beschreibung finden Sie unter
http://www.microtool.de/instep/de/scrum.asp
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
431
Die agile Vorgehensweise „Scrum“ - Rollen
Rollen:
Product-Owner:
Nimmt Interessen der Stakeholder wahr,
legt Ziele der Entwicklung fest.
Stellt Finanzierung sicher.
Cross-functional Team:
Organisiert sich eigenständig.
Schätzt jeweils Aufwände für Entwicklung.
ScrumMaster:
Sorgt dafür, dass Team produktiv arbeiten
kann.
Ermittelt Verbesserungspotential im Prozess
Optimiert Arbeitsbedingungen.
Quelle:
http://www.microtool.de/instep/de/scrum.asp
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
432
Die agile Vorgehensweise „Scrum“ - Arbeitstechniken
Sprint Planning Meeting (8 Std.)
Sprint
- Product Owner präsentiert
Product Backlogs mit höchster
Priorität.
- Verständnisfragen von
Teammitgliedern.
- Team wählt Funktionen für
kommenden Sprint.
- Team erzeugt Sprint Backlog.
Daily Scrum Meeting (15 Min.)
Aufgabenliste für Sprint
erstellt durch Team
Quelle:
http://www.microtool.de/instep/de/scrum.asp
Priorisierte Liste von zu liefernden Funktionen
(Stories) erstellt durch Product Owner
- Täglich gleicher Ort u. Zeit
- Alle Teammitglieder
- Nur einer redet
- Jedes Teammitglied:
Was habe ich erreicht
Was will ich heute erreichen
Welche Hindernisse
- ScrumMaster beseitigt Hindernisse
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
433
Die agile Vorgehensweise „Scrum“ - Arbeitstechniken
Sprint Review Meeting (4 Std)
am Ende des Sprints
- Team präsentiert Project Owner
neue Funktionalität
Sprint
Sprint Retrospective Meeting
Aufgabenliste für Sprint
erstellt durch Team
Quelle:
http://www.microtool.de/instep/de/scrum.asp
(15 Min.) nach Review Meeting
- ScrumMaster überlegt mit Team,
wie Ablauf des nächsten Sprints
verbessert werden kann,
so dass Arbeit effizienter wird
und mehr Spaß macht
Priorisierte Liste von zu liefernden Funktionen
(Stories) erstellt durch Product Owner
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
434
11. Vorgehens- und Prozessmodelle
Bewertung: agiles Vorgehen
Vorteile
 Einsatzfähige Produkte für den
Auftraggeber in kurzen Abständen
 Integration der Erfahrungen der
Anwender in die Entwicklung
 Überschaubare Projektgröße
 Korrigierbare Entwicklungsrichtung
 Keine Ausrichtung auf einen einzigen
Endtermin
 Wissensverbreiterung durch Pair
Programming
 Weniger Bürokratie / mehr Spaß !?
Nachteile
 Auftraggeber und Team müssen
mitspielen (sehr gute Vertrauensbasis
zum Auftraggeber erforderlich)
 Erfordert hohe Prozessreife
des Teams
 Verzicht auf ein reguläres
Anforderungsmanagement erschwert
Planung von Kosten und Terminen
 Das Projektmanagement muss frühzeitig
kommunizieren und Entscheidungen
fällen, andernfalls können geschätzter
und realer Aufwand auseinanderlaufen
Agiles Vorgehen ist
 gut geeignet, wenn der Auftraggeber noch nicht sicher ist, was er will!
 weniger geeignet, für umfangreiche Projekte mit planbaren Kosten & Terminen!?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
435
11. Vorgehens- und Prozessmodelle
Kontrollfragen Vorgehensmodelle







Wozu sind Vorgehensmodelle wichtig?
Was beinhaltet ein Vorgehensmodell?
Was ist ein iterativ- inkrementelles Modell?
Welche Nachteile hat das Wasserfallmodell?
Welche Vorteile bietet das V-Modell?
Welche Klassifikationen von Prototypen gibt es?
Was halten Sie von der Aussage "In meinem letzten Projekt hat sich das Modell
"X" bewährt – so mache ich das jetzt immer"?
 Ist der RUP ein agiles Vorgehens-Modell? Denken Sie an Iterationen,
Zykluslängen, Zeitpunkt der Architekturentstehung, Dokumentation)
 Welches Vorgehensmodell haben wir im Praktikum eingesetzt?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
436
Folgendes Kapitel nicht prüfungsrelevant (Kap 11.1)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
437
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
11.1 Modelle zur Bewertung von
Software-Entwickungsprozessen
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
438
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
Lernziel Vorgehensmodelle
 Sie sollen in diesen Kapitel lernen,
 wie man im Modell SPICE vorgeht, um die Güte von SoftwareEntwickungsprozessen zu bewerten
 was die Unterschiede zu CMMI sind (CMMI ist ein anderes Model zur
Bewertung von SW-Entwicklungsprozessen)
 was die Unterschiede zu V-Modell-XT bzw. RUP sind
Anschließend wissen Sie wie man die
Qualität eines Prozesses messen kann!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
439
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
Einführung
Jedem hier ist klar::
Projekt
Seit dem es Computer gibt
 scheitern SW-Projekte,
 zugesagte Termine werden nicht eingehalten,
 kalkulierte Kosten werden überschritten,
 die Qualität der SW ist viel geringer als erwartet.
=> Wir brauchen einen klar strukturierten SW-Entwicklungsprozess.
=> Wir müssen bewerten können, wie gut man die durchzuführenden
Aufgaben mit dem eingesetzten SW-Entwicklungsprozess lösen kann.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
440
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
Prozess-Bewertungs-Modell, SW-Entwicklungsprozess-Modelle und Projekte
Prozess-Bewertungs-Modelle
SPICE,
CMMI,
...
Prinzipien sollten beachtet werden
SW-EntwicklungsprozessModelle
V-Modell XT,
RUP,
Messen die Qualität des SWEntwicklungsprozesses in Organisationen
(nicht die Qualität der Software!!)
Prinzipien, die beachtet werden müssen.
Assessment /
Appraisal
Durch „Tailoring“ wird der SW-Entwicklungsprozess
an die Erfordernisse des Projektes angepasst
(Tools, Templates, Methoden, Rollen,..)
...
Wird verwendet von
Projekte in der Organisation
Projekte verwenden einen projektspezifischen
SW-Entwicklungsprozess
(Planung, Abwicklung des Projektes...)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
441
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
Was ist SPICE? – Das „Process Reference Model“ (PRM) - ISO/IEC 15504-5
process category
1
1..4
process group
1
1..12
(live cycle) process
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
442
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
SPICE – „Process Assessment Model“ (PAM)
Die Qualität eines
Prozesses (z. B. ENG.1)
ist bewerted mit einem
Capability Level:
Capability
(Fähigkeits-)
Dimension
Optimizing 5
Optimierend
Predictable 4
Vorhersagbar
Established 3
Etabliert
Managed
Gemanagt
2
Performed 1
Durchgeführt
Incomplete 0
Unvollständig
Prozess 1
e. g.:
2
3
4
5
6
ACQ.1
ACQ.3
ENG1
ACQ.2
ACQ.4
ENG.2
....
n
Process
Dimension
SUP.10
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
443
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
SPICE - Capability Level 0 und 1
Wie sind die „Capability-Levels“ (der „Live Cycle Processe“) definiert?
Level 0: Incomplete (unvollständiger) Process
 Der Prozess ist nicht implementiert.
Level 1: Performed (durchgeführter) Process
 Level 1 ist erreicht, wenn der
implementierte Prozess den Zweck
(“Process Purpose”) des Prozesses erfüllt.
Zur Bewertung wird geprüft ob
 die “Process outcomes” erzielt werden,
 die “base practices” implementiert sind,
 die “input and output work products”
existieren .
(live cycle) process
process purpose
1..*
1
1
1..*
process outcome
1..*
1..*
base practice
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
1..*
1..*
work products
444
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
SPICE - Beispiel ENG.1 (aus ISO/IEC 15504-5)
Process ID:
ENG.1
Process name:
Requirements elicitation
Process purpose:
The purpose of the requirements elicitation process is to gather, process, and track evolving customer needs and requirements
...
Process outcomes:
As a result of successful implementation of requirements elicitation process
1. continuing communication with the customer is established;
2. agreed customer requirements are defined and baselined;
3. a change mechanism is established;
4. a mechanism is established for continuous monitoring of customer needs;
...
Base practices:
(live cycle) process
Obtain customer requirements and requests (Outcome: 1, 4)
1
1
Agree on requirements (Outcome: 2)
1..*
process purpose
1..*
Establish customer requirements baseline (Outcome: 2, 3)
...
process outcome
Input work products
1..*
1..*
Commitment / agreement (Outcome: 2)
1..*
1..*
Change request (Outcome: 3)
...
base practice
work products
Output work products
Customer requirements (Outcome: 2, 3)
Communication record (Outcome: 1, 4)
Change control record (Outcome: 3, 4)
...
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
445
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
SPICE - Capability Level 2, „Process Attributes” and “Indicators”
Level 2: Managed Process
 Der “Performed (durchgeführte) Process” (Level 1)
 wird zusätzlich geplant, verfolgt und angepasst und
 Die Arbeitsprodukte sind adequat implementiert, stehen unter Konfigurationsmanagement,
werden qualitätsgesichert, gemanaged und fortgeschrieben
Für die Bewertung eines Processes genügt keine informelle Beschreibung
=> “Process Attributes” und “Indicators”
 Zu Capability Level 2 oder höher existieren jeweils 2
capability level
1
 “Process Attributes”
0..2
process attribute
 Für jedes “Process Attribute” sind “Indicators” definiert:
1
1
- “Generic Practices”
1
1..*
1..*
1..*
- “Generic Resources”
generic practice
generic resource
generic work product
- “Generic Work Products”
Diese “Indicators” helfen dem Assessor den “Capability-Level” des Prozesses zu bestimmen.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
446
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
SPICE - Attributes, Generic Practices, Generic Resources,
Generic Work Products für Level 2: Managed Process (aus ISO/IEC 15504-5)
Process Attribute 2.1: Performance Management
is a measure of the extent to which the performance (Durchführung) of the process is managed.
...
 Generic Practices:
Identify the objectives (Ziele) for the performance of the process.
Plan and monitor the performance of the process.
Adjust the performance of the process (if planned results are not achieved).
...
 Generic Resources:
capability level
project planning, management tools and control tools,
communication mechanisms,

...
Generic Work Products:
Documentation of the objectives,
milestones and timetable,
results and status of the process,
...
1
0..2
process attribute
1
1..*
generic practice
1
1..*
generic resource
1
1..*
generic work product
Process Attribute 2.2: Work Product Management
is a measure of the extent to which the work products produced by the
process are appropriately managed. (Configuration management)
...
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
447
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
SPICE - Capability Level 3
Level 3: Established Process
 Der Live-Cycle-Process existiert als ein organisationseinheitlich festgelegter
Standard-Prozess
 Ein Projekt verwendet eine angepasste (“tailored”) Version dieses
Standard-Prozesses, => definierter Prozess.
 Während der Prozessausführung
-
Identifikation von Schwachstellen
Verbesserung des Standardprozesses
 Der Established Process hat auch wieder 2 Process Attributes, für die die
Generic Practices, Generic Resources, Generic Work Products nachgeprüft
werden
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
448
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
SPICE - Capability Level 4
Level 4: Predictable Process
 In jedem Projekt werden “Schlüsseldaten” gesammelt wie z. B.:
- Anzahl der im Integrationstest gefundenen Fehler pro Zeile,
- statistische Daten über den Grund der Fehler, ...
 Es können Schlüsseldaten von unterschiedlichen Projekten verglichen werden
(wegen Einführung Standardprozess).
 Es können statistische Auswertungen über den archivierten Schlüsseldaten
gemacht werden.
 Wir können Konsequenzen von Entscheidungen voraus sagen.
 Wir können vor dem Eintreten negativer Auswirkungen reagieren.
 Das Management kann das Projekt objektiv bewerten.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
449
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
SPICE - Capability Level 5
Level 5: Optimizing Process
 Quantitative Prozessziele werden gesetzt und die Einhaltung verfolgt.
 Prozesse werden fortlaufend verbessert
 Innovative Ansätze werden erpobt und über erhobene Schlüsseldaten bewertet.
 Bemerkung: Wegen des hohen Aufwands wird normalerweise nur das Erreichen
von Capability Level 2 oder 3 angestrebt.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
450
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
SPICE – Bestimmung des Capability Level (Fähigkeitsgrad) eines Prozesses
Wir Bewerten das Erfülltsein von
• Prozess-Attributen bzw. das
• Durchführen von generischen Praktiken,
• Verfügbarsein von generischen Resourcen und
process category
• Vorhandensein von Arbeitsergebnissen
1
1..4
Wann ist ein bestimmter
Capability Level erreicht?
1
has
process group
1
1..12
0..*
capability level
(live cycle) process
1
1
0..2
process attribute
1
1..*
generic practice
1
1..*
1..*
1
1..*
generic resource
process purpose
1
1..*
generic work product
process outcome
1..*
1..*
base practice
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
1..*
1..*
work products
451
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
SPICE - Evaluation der Prozess Attribute und
Bestimmung des Capability Levels des Prozesses
Bewertung des Erfülltseins eines Prozess-Attributes:
 F: Fully achieved.
 L: Largely achieved
 P: Partially achieved
 N: Not achieved
Um F zu erreichen




müssen nicht unbedingt alle Praktiken implementiert sein,
müssen nicht unbedingt alle geforderten Resourcen verfügbar sein,
müssen nicht unbedingt alle Arbeitsergebnisse erstellt werden.
Es hängt vom speziellen Umfeld und der Meinung des Assessorenteams ab,
was unbedingt vorhanden sein muss.
 Ein Level ist erreicht, wenn
alle Prozess-Attribute
 des Levels mindestens “largely achieved” sind und
 die Prozess-Attribute der darunterliegenden Levels “fully achieved” sind.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
452
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
Was ist CMMI?
 Die Zielsetzung vom CMMI ist die gleiche wie die Zielsetzung von SPICE:
 Bewertung des SW-Entwicklungsprozesses (in CMMI zus. System-Entw.-Process)
 CMMI bietet 2 Methoden zur Bewertung an:
 Die kontinuierliche Darstellung (continuous representation) ist SPICE sehr ähnlich:
- Bewertet einzelne “Process Areas” (~“Live Cycle Processes" in SPICE) mit einem
“Capability Level”
- wie im “Target Profile” definiert (~“Process Assessment Modell" in SPICE)
 Die stufenförmige Darstellung (staged representation)
- bewertet die Organisation mit einem Reifegrad (maturity level).
(Im Normungsgremium von SPICE wurde inzwischen auch eine stufenförmiger Darstellung
erarbeitet.)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
453
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
CMMI Continuous Representation
category
1
1..8
capability level
has
1
1
0..1 {0 only if capability level 0}
generic goal
1
1..*
generic practice
0..*
process area
1
1..*
1
1..*
purpose statement
specific goal
1
1..*
specific practice
1
0..*
process category
1
1..4
work product
process group
SPICE meta model
1
1..12
1
capability level
has
1
0..2
1..*
generic practice
(live cycle) process
1
1..*
process attribute
1
0.
.*
1
1..*
generic resource
process purpose
1
1..*
generic work product
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
1
1..*
process outcome
1..*
1..*
1..*
base practice
work products
1..*
454
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
CMMI Staged Representation
organisation
0..* has
1
maturity level
category
have to be
examined
1..*
1
0..1 {1 only if maturity level 2 or 3}
generic goal
1
1..*
generic practice
1
1..8
1..*
process area
1
1..*
1
specific goal
1..*
purpose statement
1
1..*
specific practice
1
0..*
work product
Meta model of the CMMI
Continuous Representation:
capability level
has
1
1..*
1
0..1 {0 only if capability level 0}
generic goal
1
1..*
generic practice
category
1
1..8
process area
1
1..*
specific goal
1
1..*
purpose statement
1
1..*
specific practice
1
0..*
work product
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
455
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
V-Modell XT
1..*
project type
process module group
optional
1
1..4
1..*
mandatory
1..*
project execution strategy
1
1..9
1..*
process module
{ordered as 1..*
1..*
workflow}
decision gate
1
1..*
1..*
1..*
product/activity group
1
1..*
1..*
is dependant on
work products
1..*
contribute
1..*
role
1..*
responsible
1
1..*
1
1
activity
process category
1
1..*
1
1..4
activity step
process group
SPICE meta model
1
1..12
1
capability level
has
1
0..2
1..*
generic practice
(live cycle) process
1
1..*
process attribute
1
0.
.*
1
1..*
generic resource
process purpose
1
1..*
generic work product
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
1
1..*
process outcome
1..*
1..*
1..*
base practice
work products
1..*
456
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
Impliziert die Verwendung des V-Modells XT
eine gute Bewertung in SPICE oder CMMI?
 In der Beschreibung des V-Modells XT wird gezeigt, dass
die einzelnen spezifischen und generischen Ziele von Level 2 und 3 des CMMI
auf Vorgaben im V-Modell XT abgebildet werden können.
 Das heißt nicht, dass bei Verwendung von V-Modell XT automatisch CMMI-Level 3
erreicht ist.
 CMMI ist ein Modell zur Überprüfung des Fähigkeitgrads bzw. Reifegrades eines
Entwicklungsprozesses.
 Es muss unabhängig von der Verwendung eines Vorgehensmodells geprüft werden
inwieweit die spezifischen und generischen Ziele bei der Umsetzung des Prozesses
wirklich erreicht sind.
=> Durch die Verwendung des V-Modells XT ist eine gute Basis gelegt für eine gute
Bewertung in CMMI, aber erst nach dem Appraisal-(Begutachtungs-)Prozess kann
entschieden werden, welcher Level erreicht ist.
 Die gleiche Argumentation gilt für SPICE
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
457
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
Rational Unified Process (RUP)
core workflow category
1
1..6
core workflow
{ordered as
workflow}
1
1..*
artifact
is dependant on
1..*
1..*
1
1..*
activity
1
worker
1..*
responsible
1
1..*
Meta model of the V-Model-XT:
activity step
project type
1..*
process module group
optional
1
1..*
mandatory
1..4
1..*
process module
project execution strategy
{ordered as workflow}
1
1..9
1..*
1
1..*
1..*
1..*
decision gate
1..*
1..*
1..*
work products
contribute
1..*
responsible
1..*
1
role
1..*
1
1
product/activity group
1..*
1
is dependant on
1..*
activity
1
1..*
activity step
458
11.1 Modelle zur Bewertung von Software-Entwickungsprozessen
Impliziert die Verwendung des RUP
eine gute Bewertung in SPICE oder CMMI?
 Wir haben hier die gleichen Argumente wie beim V-Modell XT:
⇒ Durch die Verwendung des RUP ist eine gute Basis gelegt für eine gute
Bewertung in SPICE oder CMMI, aber erst nach dem Appraisal-Prozess kann
entschieden werden, welcher Level erreicht ist.
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
459
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
12. Technisches Management
Quellenhinweis:
Einige Folien dieses Kapitels entstammen Präsentationen von Prof. A. del Pino
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
460
12. Technisches Management
Änderungsmanagement (Change Management)
 Anforderungen ändern sich im Lauf der Zeit
 neue Anforderungen kommen hinzu
 bestehende Anforderungen werden modifiziert
 Die Prioritäten bestehender Anforderungen ändern sich
 "Change Management": Systematischer Umgang mit Änderungsanträgen
1. Analyse der Veränderungen gegenüber geplanten Zeiten, Kosten und Risiken
2. Analyse der Auswirkung dieser Veränderung auf andere Anforderungen
3. Freigabe der Änderung und Einarbeitung in das Pflichtenheft, Designdokumente,...
 Achtung! Die Analyse jedes Change Requests erfordert bereits Ressourcen
 Für die Umsetzung müssen oft Kosten nachverhandelt werden
Change Management ist eine Gratwanderung zwischen
Kundenzufriedenheit und Einhaltung des Projektplans
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
461
12. Technisches Management
Risikomanagement (I)
 In jedem Projekt bestehen Risiken
 Mitarbeiter können kündigen oder das Projekt verlassen
 Getroffene Annahmen stellen sich als falsch heraus
- z.B. Arbeitspaket X ist in 3 Tagen fertig
 Zulieferungen bleiben aus oder verspäten sich
- z.B. Technologie X ist bis zum Termin Y verfügbar
 ...
 Ein Risiko ist der Zusammenhang zwischen einer Ursache, die mit einer
gewissen Wahrscheinlichkeit eintreten kann, und einer in der Regel negativen
Auswirkung, bei der ein Verlust entsteht
 Die negative Auswirkung muss nicht zwangsläufig eintreten –
man kann auch Glück haben
 Der Verlust kann zum Beispiel eine zeitliche Verzögerung, zusätzliche Kosten
oder eine Verschlechterung der Qualität sein
Wie geht man mit Risiken um?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
462
12. Technisches Management
Risikomanagement (II)
 Ein Risikomanagement-Prozess ist das systematische Zusammenspiel von
Prozessbausteinen mit dem Ziel, Risiken letztlich akzeptierbar zu machen
1. Risikoidentifikation
-
Nicht alle Risiken sind unmittelbar bekannt. Sie müssen proaktiv gesucht und
entdeckt werden
Das Ergebnis ist ein Dokument, das für jedes Risiko neben seiner Beschreibung,
auch die Wahrscheinlichkeit seines Auftretens und den möglichen Verlust identifiziert
2. Risikoanalyse
-
In der Risikoanalyse werden die erkannten Risiken nach wohldefinierten Kriterien
analysiert, und nach ihrer relativen Bedeutung für das Projekt priorisiert
Das Ergebnis der Risikoanalyse ist eine priorisierte Risikoliste
3. Risikoplanung
-
Auf der Basis der priorisierten Risikoliste werden in einem Aktionsplan Szenarien
entwickelt, und die Alternativen zur Auflösung von Risiken beschrieben
Es werden Schwellwerte festgelegt, wann der Aktionsplan zum Einsatz kommen soll
Das Ergebnis der Risikoplanung ist ein Aktionsplan
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
463
12. Technisches Management
Risikomanagement (III)
 Der Risikomanagement-Prozess (fortgesetzt)
4. Risikoverfolgung
-
Hierbei wird überprüft, ob während des Projektverlaufs bestimmte Metriken die im
Aktionsplan festgelegten Schwellwerte überschreiten, und gegebenenfalls werden
bestimmte Abläufe des Aktionsplans ausgelöst
5. Risikoauflösung
-
Die Risikoauflösung ist die Reaktion auf einen Auslöser, wobei dann bestimmte Teile
des Aktionsplans durchgeführt werden
 Risiken in einem Projekt sind normal und unvermeidbar
 Als Entwickler sind Sie vor allem an der Risikoidentifikation und
Risikoanalyse beteiligt
 Risikomanagement erlaubt den bewussten Umgang mit diesen Risiken
und verhindert böse Überraschungen
 Evtl. auch Einsatz von Prototypen zur Risikobewertung
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
464
12. Technisches Management
Konfigurationsmanagement (I)
Quelle: IEEE Standard Glossary of Software Engineering Terminology
 A system is a collection of components (=Systemteile) organized to accomplish a
specific function or set of functions




Hardware-Komponenten
Software-Komponenten
Firmware-Komponenten
...
 Die Konfiguration eines Systems beschreibt die Komponenten, die jeweils in
einer bestimmten Version vorliegen und mit einer wohl definierten Prozedur zu
dem System zusammengesetzt werden können
 Während der Entwicklung eines Systems entstehen viele Konfigurationen




Jedes Release entspricht (mindestens) einer Konfiguration
Jedes Testszenario entspricht einer Konfiguration
Jeder Zwischenstand in der Integration entspricht einer Konfiguration
...
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
465
12. Technisches Management
Konfigurationsmanagement (II)
 Beim Konfigurationsmanagement geht es darum, die vielen entstehenden
Konfigurationen zu verwalten
 systematische und nachvollziehbare Durchführung von Änderungen
- Was wurde gegenüber der letzten Konfiguration geändert?
- In welchen Konfigurationen wird diese Version der Komponente noch verwendet?
 Wiederherstellung von "alten" Konfigurationen
- wenn z.B. ein Fehler zu einem Release gemeldet wird
 Konfigurationsmanagement-Tools




verwalten sehr viele Dateien und zusätzliche Datenstrukturen darauf
verwalten Versionen von Quellcode (bekannt als CheckIn und CheckOut)
bieten Funktionen zum Suchen, Verzweigen, und Zusammenführen von Dateien
Beispiele (Open Source): Subversion (SVN), Concurrent Version System (CVS)
Eigentlich müssten auch die Hardware, das Betriebssystem, die
Entwicklungsumgebung uvm. mitverwaltet werden, damit eine
Konfiguration nach vielen Jahren tatsächlich wiederherstellbar ist
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
466
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
13. Zusammenfassung
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
467
13. Zusammenfassung
Themen in der Veranstaltung
 Software Engineering im Projekt






Anforderungsanalyse (Spezifikation)
Abnahme und Systemtests
Architektur
Design
Implementierung
Test
 Querschnittsthemen





Qualitätsmanagement
Software-Metriken
Vorgehens- und Prozessmodelle
Technisches Management
(Prozessorientiertes Qualitätsmgmt (CMMI, SPICE, Assessments)
-leider nicht geschafft)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
468
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
13.1 Ergebnisse im Praktikum
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
469
13.1 Ergebnisse im Praktikum
Inhalt des Praktikums
 Der CocktailPro war kein wirklich großes Projekt....





(relativ) geringer Umfang, kurze Laufzeit, kleines Team
keine Wartung
keine Change Requests
wenige Schnittstellen nach außen (z.B. Zulieferung von Fremdcode)
keine Ausnahme- und Fehlerbehandlung
 ....aber, es wurden dennoch viele Themen behandelt








OOA, OOD, Modellierung (Use Cases, Klassendiagramme, Sequenzdiagramme)
Implementierung (Guidelines, Objektorientierung)
Beobachter-Muster
Integration (Zulieferung Rezeptbuch / verteilte Entwicklung)
Test (Blackbox, Whitebox, C++Unit)
Review
Metriken
CASE-Tool, Round-Trip-Engineering
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
470
13.1 Ergebnisse im Praktikum
Wie gut ist Ihr Entwurf?
 Analysieren Sie bitte folgende Change Requests:
1.
2.
3.
4.
5.
es wird ein neues Rezeptbuch mit neuen Rezepten zugeliefert
das User-Interface soll in Deutsch und Englisch verfügbar sein
es wird in den Rezepten ein neuer Verarbeitungsschritt "Rühren" eingeführt
es soll bei einem Füllstand von 200g ein Warnungs-Piepton ausgegeben werden
die gleiche Zutat kann in mehreren Dosierern sein (es soll automatisch
umgeschaltet werden, wenn ein Dosierer leer ist)
6. die Cocktails sollen schneller gemischt werden, indem die Zutaten parallel
abgewogen werden. Dazu erhält jeder Dosierer eine eigene Messvorrichtung.





In welchen Klassen und Methoden müssen Sie Änderungen machen?
Ist die Änderung eher ein Hack oder passt sie ins Design?
Könnte die Änderungen auch leicht jemand anderes machen?
Wie viele Stunden brauchen Sie zur Umsetzung?
Könnten Sie diese Änderungen auch im Code Ihres Kollegen machen?
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
471
13.1 Ergebnisse im Praktikum
Lessons Learned? (I)
 Haben Sie den Wert der Modelle erkannt?
 die Abstraktion hilft beim Bewahren des Überblicks
 die Darstellung erleichtert das Verständnis
 In den Modellen werden Entscheidungen getroffen und wichtige Vorgaben
gemacht
 die Implementierung wird geradlinig und einfacher
(oder auch nicht, falls die Modelle nicht adäquat sind)
 ...aber, falls der Detaillierungsgrad nicht stimmt, klappt es nicht
 z.B. Implementierung trotz unvollständiger Klassen- und Sequenzdiagramme
führt zu häufigen Schnittstellenänderungen
 ...
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
472
13.1 Ergebnisse im Praktikum
Lessons Learned? (II)
 Haben Sie den Wert von Metriken erkannt?
 schnelle und frühe Analyse der Ergebnisse
 wertvolle Hinweise auf potenzielle Schwachstellen
 Anregungen zur Verbesserung des persönlichen Entwicklungsstils
 ...aber, auch die Gefahren?
 übertrieben gute Ergebnisse für halbfertigen Code (keine Fehlerbehandlung.)
 die Erfassung und Auswertung zu vieler Metriken verursacht viel Arbeit
 Haben Sie jetzt besser verstanden was Design ist?
 Geheimnisprinzip, schwache Kopplung und starker Zusammenhalt
 Vererbung und Überladung als praktische Techniken
 Verwendung von Klassen und Sichtbarkeit
 Haben Sie den Nutzen von Design Patterns jetzt besser verstanden?
 Observer als praktisches Pattern
 Tipp: Das (einfache) Singleton-Pattern hätte einiges stark vereinfacht...
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
473
Hochschule Darmstadt
Fachbereich Informatik
Software Engineering
13.2 Gesamtergebnis
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
474
13.2 Gesamtergebnis
Häufige Mängel in Software-Projekten… sind vermeidbar
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
475
13.2 Gesamtergebnis
Häufige Mängel in Software-Projekten… sind vermeidbar
Anf.-analyse
Pflichtenheft
Lastenheft
Architektur, Design,
Implementierung
ProjektManagement
Reviews,
VorgehensModelle,
Metriken
AnforderungsAnalyse
Pflichtenheft
Lastenheft
Modellierung,
Dokumentation
Integration,
Test,
Abnahme
ProjektManagement
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
476
13.2 Gesamtergebnis
Kritische Bemerkungen zum Schluss
 Modelle und Prozesse sind wichtige Instrumente auf dem Weg zur Software
 aber die Software ist das Ziel, nicht das Modell oder der Prozess!
 Modelle sind sinnvoll, solange sie Aufwand reduzieren (auch in der Wartung!) –
das Modell darf aber kein Selbstzweck werden !
 In der Modellierung geht es nicht darum, die neuesten UML-Features zu
verwenden – Sie dokumentieren für Ihre Kollegen und für die Wartungsphase!
Verwenden Sie einfach eine Notiz im Modell um Hinweise zu geben
 Dokumentieren Sie auch Zusatzinformationen wie
-
Zwischenergebnisse,
grundsätzliche Ideen und Lösungsansätze,
nicht so leicht ersichtliche Randbedingungen und
die Gründe bei einer Entscheidung mit Alternativen
 Ein Prozess soll helfen! Wenn er mehr behindert als nützt, ist er der falsche (für
dieses Projekt)
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
477
13.2 Gesamtergebnis
Kontrollfragen zum Software Engineering
 Wie stellen Sie in einem großen Projekt sicher,








dass eine Person nicht alles wissen muss?
dass Qualitätsauflagen (intern oder vom Auftraggeber) erfüllt werden?
dass die Wartungsverpflichtung berücksichtigt wird?
dass Ihr Kunde auch das kriegt was er will?
dass Sie auch in Teams an verschiedenen Standorten arbeiten können?
dass die Ergebnisse der Teams auch zusammen passen?
dass die Software stabil läuft?
dass die Entwickler nicht alles neu erfinden?
Sie sollten jetzt in einem großen Projekt
mitarbeiten können!
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
478
ENDE
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
479
 Ergänzungsfolien
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
480
Operationen der Schnittstellen-Klasse zu Rezeptbuch
class SKRezeptbuch
{
public:
void SKRezeptbuch();
int
GetAnzahlRezepte();
int
GetAnzahlRezeptschritte (int NrRezept);
string GetNameRezept (int NrRezept);
string GetZutat (int NrRezept, int NrRezeptschritt);
float GetMenge (int NrRezept, int NrRezeptschritt); …
}
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
481
Operationen der Realisierungs-Klasse in Komponente KRezeptbuch
class KompRezeptbuch::public SKRezeptbuch
{
public:
void KompRezeptbuch()
{ Rezeptbuch dasRezeptbuch };
int GetAnzahlRezepte()
{ return dasRezeptbuch.GetAnzahlRezepte() };
int GetAnzahlRezeptschritte (int NrRezept)
{ return dasRezeptbuch.getRezept(NrRezept)->getAnzahlRezeptschritte() };
string GetNameRezept (int NrRezept)
{ return dasRezeptbuch.getRezept(NrRezept)->getName() };
string GetZutat (int NrRezept, int NrRezeptschritt)
{return dasRezeptbuch.getRezept(NrRezept)
->getRezeptschritt (NrRezeptschritt)->getM_Zutat() };
float GetMenge (int NrRezept, int NrRezeptschritt)
{ ...->GetM_Menge}; …
}
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
482
 Nicht aktuelle Folien:
SWE © Prof. Dr. W. Weber, h_da, Fachbereich Informatik
483
Cocktail-Mischmaschine
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement