SWT WS1213 Folien v21

Grundlagen der
Softwaretechnik
(SWT)
Vorlesung im Wintersemester 2012/2013
Leibniz Universitt Hannover
Prof. Dr. Kurt Schneider
Fachgebiet Software Engineering
Kurt.Schneider@Inf.Uni-Hannover.de
Kurt Schneider Leibniz Universitt Hannover SWT-WS0910 - 3 SWT 2012-13
1.
Grundlagen der Softwaretechnik
1. Wieso Software Engineering?
2. Programmieren: Vom Einzelkmpfer zum Groprojekt
3. Entwurf: Strukturen und nicht-funktionale Eigenschaften
4. Entwrfe notieren mit UML: Modelle im Software Engineering
5. Design Patterns: Entwurfserfahrungen
6. Anforderungen: Die Basis des Projekts
7. Projektmanagement: Wie alles zusammenspielen muss
8. Prozesse, Reife, Agilitt: ber den Tellerrand des Projekts
Anspruch der Veranstaltung
Lernziele von SWT (Vorlesung und bungen)
Sie kennen die Schlagworte des Software Engineering
Sie wissen, wie wichtige Verfahren im Prinzip funktionieren
Sie haben einige selbst ausprobiert
Sie wissen, wo sie genauer nachlesen knnen
Sie knnen vernnftig in SW-Projekten mitarbeiten
Sie achten beim Programmieren auf Verstndlichkeit
Sie machen einige hufige Fehler nicht, weil Sie sie kennen
Sie wgen ab und
Sie entscheiden auf Basis eines begrndeten Urteils
Sie lernen dagegen nicht
Grundlagen des Programmierens
Irgendein kommerzielles Werkzeug zu bedienen
Organisatorisches
Aktuelle Informationen, Folien etc.:
Wir verwenden StudIP
Melden Sie sich auch hier an: www.se.uni-hannover.de
Hier werden Bonuspunkte verwaltet.
Klausur
Klausur SWT (und danach SWQ):
18.3.2013, Conti-Gebude Raum VII 201, 13:30 SWT, 14:45 SWQ
Diese Angaben ohne Gewhr! Lesen Sie kurz vorher www.se.uni-hannover.de
bungen: Anna Averbakh (Anna.Averbakh@inf.uni-hannover.de)
Montags, 14:45 - 15:30 Uhr, MMH (Anna Averbakh)
--> berlauftermin, nur fr die Anfangsphase, dann beendet
Dienstag, 11:15 12:15 Uhr, G323 (Polina Yakovleva)
Dienstag, 15:00 16:00 Uhr, G323 (Oliver Karras)
Mittwoch, 11:15 12:15 Uhr, G323 (Wadim Friedrich)
Freitag, 10:00 11:00 Uhr, G323 (Matthias Herrmann)
Irrtum und nderungen vorbehalten!
Vorlesung bung Praktikum
Vorlesung
Konzepte vorstellen
Erklren
kurz zeigen
bung
Wichtiges noch mal zeigen
Selbst anwenden/erklren
Erfahrungen und Fragen diskutieren
brigens: Korrelation bung-Note
Programmier Praktikum(ProPra)
Programmieren ben
Scheu verlieren
In grerem Zusammenhang anwenden
Klausur
Berufspraxis
Wo Sie die angegebene Literatur finden
Bibliothek gegenber dem Hauptgebude
Systemstelle Software Engineering (L inf 430)
Im Lesesaal oder zu bestellen
in Anlehnung an Cockburn, A.: Writing Effective Use Cases. Addison-Wesley, 2001
Manche Bcher
sind sehr gut zu
lesen. Blttern Sie
doch mal durch!
Ein paar Tipps, aus Erfahrung
Das Wesen einer Vorlesung
Frei gewhlt und doch kein Kino
Laptop, Block, oder Gedchtnis?
Ein wenig Arbeitstechnik
Auch hier achten wir auf freundlichen, professionellen Stil
Kommen Sie pnktlich
Seien Sie leise, stren Sie Ihre Kollegen nicht
Gehen Sie respektvoll miteinander um
Spielen Sie mit Handy und Laptop: aber bitte nur drauen!
Wie man hineinruft
Wir wollen, dass Sie Erfolg haben
und Ihnen die Sache Spa macht!
Anliegen und Ziele
Herausforderungen an Software-Profis
Grundbegriffe
Geschichte und Vorbild Ingenieur
Gedankenexperiment: Informationsfluss
Kapitel 1
Wieso
Software Engineering?
weiche Botschaften - harte Wahrheiten
Einstimmungsbild
http://www.plexispos.com/screens/touchkey1.jpg
(20.9.2006)
Software ist berall
Bankomat
Animierter Film
Auto
Zndschlssel
Spielzeug
Gehaltsabrechnung
PC-Spiel
Luftraumkontrolle
Medizin
...
Mit SW ist jeder stndig konfrontiert
jemand muss eine Idee fr SW haben
jemand muss sie entwickeln
jemand muss sie kaufen
jemand muss sie installieren
jemand muss sie verwenden (wollen)
jemand braucht die Resultate
Fazit: Einfluss von Software
SW beeinflusst Technik
SW beeinflusst Wirtschaft
SW beeinflusst Menschen
Software
Software ...
Ist der faszinierende Werkstoff unserer Zeit!
Aber es kommt darauf an,
was man daraus macht
... und wie man es macht!
Wenn es dagegen nicht funktioniert
Katastrophenbeispiele
Flugzeug bremst nicht
Marssonde geht verloren
Fahrkartenautomat macht einen verrckt
Spiel ist nicht zu kapieren, Geburtstagskind heult
Was htten Sie besser gemacht?
Sie werden Gelegenheit bekommen, das zu beweisen:
Auto
Banken, Brsen
Kernkraftwerke
Spielzeughersteller
Admin. Software

Hier oder in vielen anderen Bereichen
schon in bungen und Softwareprojekt!
Softwareentwicklung richtig machen
ein kleiner Unterschied
Annahme: Sie wollen nicht Hobbyprogrammierer werden,
sondern Softwareprofi dazu gehrt die richtige Einstellung
Nach dieser Vorlesung sollen Sie
Fhigkeiten
Fertigkeiten und
berzeugungen gewonnen haben,
die die Wahrscheinlichkeit fr erfolgreiche Projekte erhhen.
Programmieren ist nicht schwer, professionell Entwickeln sehr
Technische Seite: Programmstruktur und Methoden
konomische Seite: Kosten und Nutzen
Menschliche/psychologische Seite: Kunden und Mitarbeiter
Nehmen Sie die Softwaretechnik ernst, dann macht sie Spa
Kritik ist einfach
Bluescreen
Microsofts Datenerhebung
Zu komplizierte Oberflchen
Langsame Verarbeitung
Unlogische/doppelte Abfragen
Strende Releasewechsel
Sicherheitsbedenken
Anforderungen klren
Benutzer verstehen
Neueste Technik einsetzen
Seris planen und verfolgen
Qualitt und Risiken prfen
Unsere Frage muss sein: was knnen wir (als Informatiker) dagegen tun?
Herausforderung an Profis 1
Software soll tun, was Kunden erwarten
Aber woher wissen wir, was Kunden erwarten?
Anforderungen erfassen und umsetzen
Irrglauben ablegen, wir wssten selbst am besten, was richtig ist
Und wer genau sind diese Kunden?
Initiator des Auftrags, Kufer, Anwender, Marketing
Nicht nur den Erstbesten befragen
Aber wenn die es nicht sagen?
dann knnen sie es vielleicht einfach nicht!
Wir mssen helfen dafr gibt es Techniken (Requirements Eng.)
Aber fr wen?
Verschiedene Leute haben unterschiedliche Bedrfnisse
Usability Engineering: Benutzerprofil erstellen
Und in welchem Zusammenhang?
Eigentlich will kaum einer ein Programm bedienen sondern
eine Aufgabe erledigen
Usability Engineering: Aufgabenanalyse durchfhren
Aber sind Oberflchen nicht Geschmackssache?
Irrtum: darum geht es gar nicht! Man kann objektiv sagen:
manche Farbkombinationen sind physiologisch ungnstig
Man merkt sich nur 5+/-2 oder 3*3 Einheiten
und so weiter: das zu bedenken hilft schon sehr
Geschmacksfragen von obj. Bedienbarkeit trennen
Software soll leicht zu bedienen sein
Software soll im Zeit- und Kostenplan bleiben
Software
Zeit
Kosten Qualitt
ACHTUNG!
Qualitt umfasst hier
Funktionalitt und
nicht-funktionale
Eigenschaften
Realistisch planen trotz vieler Unsicherheiten
Alle relevanten Aspekte methodisch planen (Projektmgmt.)
Systematisch aus Erfahrung lernen
Neueste Technik einsetzen, dennoch gut schtzen
Typische Informatikerfehler vermeiden, Schtztechniken
Auswirkungen von Zeit- und Kostenberziehung bedenken
Risiken fr den Kunden abschtzen
Damit eigene Risiken
Software Engineering
Hilft, diese Herausforderungen anzugehen
Bietet systematische Methoden und Techniken
Projektmanagement
Risikomanagement
Requirements Engineering
Usability Engineering
und viele Techniken mehr
Bezieht sich auf SW-Entwicklung, -Akquisition und -Wartung
Bietet Konzepte, praktische Tipps fr den tglichen Bedarf
... aber auch ungelste Forschungsfragen
SE wird beeinflusst
Fazit:
Das ist kein softes Bild: harte Einflsse!
SE muss sich in der Praxis dieses Spannungsfelds bewhren
Software-Profis knnen sich nicht nur auf einen Aspekt strzen
Menschen
Technik
Wirtschaft
Software
Engineering
Grundbegriffe
Software (SW)
Computer programs, procedures and possibly associated
documentation and data pertaining to the operation of a computer
system (IEEE Std 610.12 - 1990)
Bemerkungen: Computer system im weiteren Sinn: embedded
Software Engineering (SE)
(1) the application of a systematic, disciplined, quantifiable approach
to the development, operation, and maintenance of software; that
is, the application of engineering to software
(2) the study of approaches as in (1) (IEEE Std 610.12 - 1990)
offenbar ist also Engineering: a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of X
Parnas: SE erst ab 2 Personen und 2 Versionen
Softwaretechnik (SWT): hier als Synonym fr Software Engineering
Ingenieursprinzipien
A systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of X
Konsequenzen
Kostendenken
Kein Perfektionismus
Qualittsbewutsein
es luft reicht nicht
Anwendung von Normen und Regeln
keine Knstler
Probleme durch Zerlegung lsen
divide et impera
Baugruppen und Wiederverwendung
statt not invented here
Wieso Software Engineering?
Hardware wird relativ immer billiger und besser
Speicher ist grer, schneller, billiger
Rechner auch
Netzwerke auch
Software kann nicht mithalten Produktivittsgap
Denn Software entsteht im wesentlichen im Hirn
Das wchst nicht so schneller wie Chips und Speicher
Verzahnung mit Wirtschaft und Gesellschaft
Immer mehr Software in allen Bereichen
steigende Komplexitt
wachsende Lebensdauer
grere Technologiesprnge
SW=Risiko+Chance
Muss man systematisch
angehen, nicht zufllig
Kurze Geschichte
des Software Engineering
Sehnsucht: ingenieursmig auch bei Software vorgehen!
Verklrung des Ingenieurs
Bei Hardware klappt es so gut, und bei Brcken und Husern
Aber Software ist anders
SW ist immateriell nur Entwicklung, keine Fertigung
SW hat unstetiges Verhalten Testen viel schwieriger
universelles Material fr alle mglichen Anwendungen
amorphes Material keine implizite Struktur
Entwickler berschtzen sich regelmig
Trotzdem mchte man SW genauso gut in den Griff kriegen
F.L. Bauer, NATO Science Conference, Garmisch-Partenkirchen 1968
Anwendung von Ingenieursprinzipien fr zuverlssige SW,
die auf realen Rechnern luft und
mit wirtschaftlichen Mitteln erstellt wird.
NATO Science Conference
Garmisch-Partenkirchen 1968
ht t p: / / homepages. cs. ncl . ac. uk/ br i an. r andel l / NATO/ N1968/
Der Begriff Software Engineering
wird geprgt
Prof. F.L. Bauer
Professionelle Softwareentwicklung?
http://www.csss.cs.ubc.ca/files/images/DSCN2559.preview.jpg
(29.9.06)
SW-Entwicklung
Elemente der Software-Entwicklung
Computer/
Ressource
Person
7300
Day One
7200
Info-Material
1
2
a: Bedienkonzept
Entwickeln (3)
3
b: Kassiererschulung
Erarbeiten (3)
4
d: Infomaterial
Entwickeln (3)
e: Infomaterial
verteilen
(1)
5
c: Kassierer-
Schulung
halten
(2)
6 f: erster Tag
operativ
(1)
0
3
6
6
9/9
/8
/7
/6
/3
/
4
/0
7 8
Plan
Phase
Projekt-
definition
Abfolge
Rolle
Anforderungs-
erhebung
Codierung
Aktivitten
Dokument
Handbuch
SW-Entwicklung
Modelle sind Voraussetzung fr Planung
Rolle
Computer/
Ressource
Dokument
Person
7300
Day One
7200
Info-Material
1
2
a: Bedienkonzept
Entwickeln (3)
3
Erarbeiten (3)
4
d: Infomaterial
Entwickeln (3)
e: Infomaterial
verteilen
(1)
5
c: Kassierer-
Schulung
halten
(2)
6 f: erster Tag
operativ
(1)
0
3
6
6
9/9
/8
/7
/6
/3
/
4
/0
7 8
Plan
Phase
Projekt-
definition
Abfolge
Anforderungs-
erhebung
Codierung
Aktivitten
Handbuch
Modell
Original
Grundbegriff Modell
Original
Modell
Relevante Eigenschaften
Prterierte
Eigenschaften
Abundante
Eigensch.
Modell-
Abbildung
Fragen zu Charakterisierung und Verstndnis
Was ist das Original?
Modell fr wen?
Modell zu welchem Zweck (welche Operationen)?
Welche Eigenschaften sind dafr relevant?
Wozu modelliert man was?
Modell-
element
Original Relevante
Eigenschaften
Fr wen, wozu?
Aktivitt Bestimmte
Ttigkeit
Ziel, Ergebnis,
Dauer, Teilnehmer
Projektleiter,
Mitarbeiter: Plan,
Aufgaben
Rolle Bndel von
Aufgaben,
Rechten u.
Pflichten
Aufgaben,
Zustndigkeiten
Verantwortg.
Alle Projekt-beteiligte:
wissen, wer was tun
muss
Dokument Papier- oder
elektron.
Dokument
Zugnglich, lesbar,
meist mit definierter
Struktur
Autor und Leser: was
ist zu leisten/zu
erwarten
Person Individueller
Mensch
Individuum;
Fhigkeiten,
Krankheiten
Projektleiter: Rollen
zuweisen, Eigen-
heiten beachten
Beziehungen Abhngigkeit,
Kenntnisse
(verschieden) (vielfltig: meist um
bersicht zu wahren
Wie modelliert man Software-Entwicklung?
SPEM / Syntax
SPEM heit
Software & Systems Process Engineering Meta-Model
Dt.: Metamodell fr Entwicklungsprozesse der Software- und Systemtechnik
Version 2.0 vom April 2008
Historie
Es gibt verwirrend viele Ablaufnotationen
Nach dem Vorbild von UML angegangen; aber anderes Original
Als UML subset definiert (merkt man aber kaum)
D.h: ordentlich definiertes Austauschformat fr Prozessbeschreibungen
SPEM ist kein Prozess sondern eine Modellierungsnotation dafr
<Anleitung>
z.B. CodeConventions
<Rolle>
z.B.: Entwickler
<Aufgabe>z.B. programmieren
<Produkt>
z.B. SourceCode
SPEM-Notation (Auszug)
Work Product Definition
Dokument oder anderes Produkt
Role Definition
Bndel von (erwarteten) Fhigkeiten u. Kompetenzen
AKV: Aufgaben, Kompetenzen, Verantwortlichkeiten
Task Definition
Arbeitsvorgang; kann unterteilt werden
Category
Zum Strukturieren von Elemente (in eine Hierarchie)
Guidance
Anleitende Info.: Templates, Checklisten, Vorgaben
Person und Rolle
Immer genau unterscheiden
Beide Konzepte sind wichtig
Aber sie bedeuten nicht das Gleiche!
Rolle
Auf Zweck hin definiert:
Aufgabe erfllen
Profil vorausgesetzt:
Kenntnisse, Fhigkeiten
Definierte Aufgaben, Zu-
stndigkeiten, Verantwortg.
Mit Erwartungen verbunden
Von einer oder mehreren
Personen auszufllen
Person
Individuum mit persnlicher
Geschichte: ist, wie sie ist
Hat ein Profil, passt mehr oder
weniger zu Rolle
Wird Rolle zugewiesen, ber-
nimmt deren Aufgaben usw.
Erfllt Erwartung mehr/weniger
Kann eine, mehrere oder keine
(definierte) Rolle wahrnehmen
Patrizia
Paul
Entwickler
Analytiker
Ordnung im Softwareprojekt
durch Prozesse und Prozessmodelle
Aktivitten und Ablufe
Normaler Ablauf
es gibt aber Alternativen!
Analyse
(Anford.)
Entwurf Codierung Integration Betrieb
Code&fix: lieber nicht!
Codierung Codierung Codierung Fix Fix
Beispiel fr eine Variante
Prototyping auch davon gibt es noch Unter-Varianten
Analyse
(Anford.)
Codierung
Integration Betrieb
Entwurf
Analyse
(Anford.)
Codierung
Ordnung im Softwareprojekt
7300
Day One
7200
Info-Material
1
2
a: Bedienkonzept
Entwickeln (3)
3
Erarbeiten (3)
4
d: Infomaterial
Entwickeln (3)
e: Infomaterial
verteilen
(1)
5
c: Kassierer-
Schulung
halten
(2)
6 f: erster Tag
operativ
(1)
0
3
6
6
9/9
/8
/7
/6
/3
/
4
/0
7 8
Projektplan
Benutzer-
Handbuch
Dieter-Paul
Einige Beziehungen
Patrizia
ist erstellt
Betrieb
Integra-
tion
Codierung Entwurf
Analyse
(Anford.)
(Betriebs-Ing.)
Projektleiter
Programmierer Designer Analytiker
Tech.Writer
Grundbegriffe fr diese Vorlesung
Diese Dokumentarten
muss man kennen
Wie die Aktivitten
treten sie in verschiedenen
Formen/Namen auf
Grundbezeichnungen
(rechts) sind ein guter
Anhaltspunkt
... wir kommen darauf zurck!
Lasten-
heft
Pflichten-
heft
Grob-
entwurf
Fein-
entwurf
Code
Technische
Doku-
mentation
Roll-Out-
Plan
Test-
plne
Benutzer-
Handbuch
Software = ... and documentation
Betrieb
Integra-
tion
Codie-
rung
Entwurf
Analyse
(Anford.)
Gedankenexperiment
zum Informationsfluss in Projekten
Ein Experiment, um die Dynamik zu sehen!
Softwareprojekt ist etwas hoch Dynamisches
Gesucht: Entscheidungshilfe in vielen SE-Situationen
wie wirkt sich eine Handlung auf Projektfortschritt aus?
Gefunden: Softwarequanten-Metapher
Metapher half schon bei der Simulation von SW-Projekten
Software-Quanten
Software-Quanten
wandern
Spezifikation
Software-Quanten
wandern
Spezifikation Entwurf Code
... und am Schluss
Spezifikation Entwurf Code
Zusammenfassung von Kapitel 1
Software beeinflusst Technik, Wirtschaft, Menschen
Software Engineering wird davon beeinflusst
Professioneller Softwareingenieur beachtet alle Aspekte
Geschichte des Begriffs Software Engineering
NATO Science Conference 68, F.L. Bauer, Engineering als Vorbild
Aber Software ist ein spezielles Material!
Software Engineering: Viel Neues in Forschung und Praxis
Modelle fr bersicht und Planung
Aspekte eines Softwareprojekts
Gedankenmodell Software-Quanten
Probieren Sie es aus: www.se.uni-hannover.de/en/qgame
Programmhygiene und egoless programming
Dokumentation und Zusammenarbeit
Konfigurationsmanagement
Information Hiding
Interfaces
Kapitel 2
Programmieren
Vom Einzelkmpfer zum Groprojekt
Situation Einzelkmpfer
Allein
Keiner bezahlt
Keiner beteiligt sich
Selbst die Idee gehabt
Wird nicht weiterentwickelt
Muss keinem Kunden gefallen
Muss nicht zusammenpassen
Muss nicht verstndlich sein
Muss man keinem zeigen
Muss nicht gelingen
Stellen Sie sich vor
Sie haben eine neue Stelle
Sie sollen Code entwickeln und pflegen
Zu Anfang bekommen Sie das Programm eines Kollegen
Er hat sehr auf Speichereffizienz geachtet, heit es
Er ist leider versetzt worden
Nicht mehr verfgbar
Viel Spa
Was tut dieses Programmstck?
Erst verstehen, dann verbessern
Wieso verstehen Sie das nicht?
Das Programm funktioniert doch!
Quellcode dient der Kommunikation
Syntax korrekt der Compiler versteht
Semantik korrekt das Programm tut, was es soll
Dennoch kann es unverstndlich und unwartbar sein!
Dann ist es in der Praxis nutzlos
Fazit
Quellcode dient
der Kommunikation
mit dem Compiler
vor allem aber
mit anderen Menschen
Quellcode
Entwickler
<Mensch>
Erster Versuch: Bessere Formatierung
Schon besser.
Bezeichner sind nicht hilfreich, im Gegenteil
berlang, kryptisch, mit Sonderzeichen
bezeichnen nichts, sondern verwirren
Kein Hinweis!
FALSCH!
Bedeutung der intVar?
x, y: Koordinaten?
Irrefhrend
Zweiter Versuch: Bessere Bezeichner
Fazit: Auch das Format ist wichtig
Leerzeilen, Leerzeichen, Tabs
Umbrche, Einrckungen
Sieht wie Fehler aus
Leere strt
Leere fehlt
Gegen die Semantik
Format und Bezeichner besser
Keine Kommentare
Alles public, keine Exceptions
Verstehen Sie, was hier passiert und warum?
Kommentare sind kein Luxus
Schreiben Sie Programme
zum Lesen fr Menschen!
Dazu gehren
Bezeichner
Kommentare
Optische Verteilung
Hintergrundinformation
Huffmann Code
Fazit: Wie sehen Programme aus?
Sie whlen im Quellcode:
Klassennamen
Methodennamen
Leerzeichen
Kommentare
Einrckungen
Variablentypen
Schleifen
Rckgabewerte

Ziele
Verstndlichkeit
Lesbarkeit
Software Engineering: Zoom out
Vom Einzelkmpfer zum Team und Projekt
Programmierstil:
subjektive Vorlieben und professionelles Verhalten
Sie programmieren nicht vor allem fr sich
Man soll nicht merken, wer es gemacht hat (egoless!)
Jemand anders macht damit weiter evtl. nach langer Zeit
Software-Entwicklung ist viel mehr als Programmieren
Sie mssen zusammen erfolgreich sein
Sie sind nicht allein.
Groe Systeme kann man nicht allein entwickeln
Entwicklung findet immer mit vielen Beteiligten statt
Viele Kunden
Viele Entwickler
Koordination erforderlich
Entwicklungsprozesse fr die Ablufe
Versions- und Konfigurationsmanagement fr die Technik
Untersttzung durch Werkzeuge
z.B. CVS, Subversion oder Git
Richtlinien
Bezeichner: machen knapp ihre Bedeutung klar
Format: gewohnte Struktur erleichtert die Orientierung
Kommentare: erklren den Quellcode (warum ist das so?)
Externe Dokumentation: Beschreibt ausfhrlicher Hintergrnde
Aufteilung und Struktur: entspricht den Entwurfsentscheidungen
Pakete: Nicht vergessen!
Anzahl von Klassen, Methoden, LOC, Kommentaren: ausgewogen
Vererbung: einsetzen, aber nicht zu tief vererben
Komplizierte Stellen im Programm mssen erklrt werden
Wieso muss das gemacht werden?
Wieso wird es so gemacht?
Was bedeutet die Konstante, woher kommt die Formel?
Welche Funktion hat das im Algorithmus?
Mglichst macht man aber gleich gar nichts kompliziert
Beispiele aus dem ProPra zur Diskussion
package de.unihannover.se.pp.Engine;
public class Account implements IAccount {
private String name;
private int balance;
public Account(String name, int balance)
{
setName(name);
setBalance(balance);
}
public String getName() {
return name;
}
public void setName(String name) {
if(name == null)
throw new IllegalArgumentException();
if(name.equals(""))
throw new IllegalArgumentException ("Der Kontoname sollte mindestens ein Zeichen lang sein!");
this.name = name;
}
// Folgen noch getter und setter
public int getBalance() {
return balance;
}
Aufgabe
Implementierung fr Interface IAccount
- Kontostand abrufen
- Inhabernamen abrufen und setzen
Sinnvoller
Paketname
Gute Bezeichner
Position inkonsistent: {
Sogar sehr gut: Sonderflle behandelt
Bezeichner sorgfltig whlen
Konstanten benennen
Symbolische Namen: PI statt 3.141592
Gro geschrieben: MEHRWERTSTEUER statt 16.0
Kurzbezeichner (nur) dort, wo sie blich sind
Schleifenzhler: i, j, k
Koordinaten: x, y
Aber nicht aus Faulheit: asrstz (Abschreibungsrabattsatz)
Konvention: Teilweise zur Vereinheitlichung erzwungen U2-MEA-PREM
Lngere Bezeichner
Drcken inhaltliche Bedeutung aus: steuersatz, kontonr
Hinweise auf Typ sind akzeptabel: kontoNrInt (nicht so gut)
Aber NICHT der Typ allein: float1
Nicht zu lang whlen: steuerlichAbsetzbarerPauschbetrag
Jedes Objekt soll EINE einzige Bedeutung haben: eindeutig benennen
Deutsch oder Englisch: kein Gemisch
Methodennamen
Bezeichnen, was der Empfnger tun soll: <Verb> (<Objekt>)
setName
fillRectangle
Update
Methoden mit Rckgabe: Name bezeichnet Rckgabewert
isEmpty implizierte Rckgabewerte: ja oder nein
getName nicht so schn, aber blich (Rckgabe: name)
conflictingRules ermittelt Sammlung widersprchlicher Regeln
Rckgabe: Rules (und zwar die mit Konflikt)
Am besten lesen sich Aufrufe wie normale Stze
steuerformular.steuersatz(kunde.getEinkommen())
Hallo Steuerformular, was ist der Steuersatz vom Einkommen des kunden?
Vertiefung: Variablendefinition
Nur eine pro Zeile definieren, dahinter // Kommentar
doubl e st euer sat z; // Durchschnittssatz, in Prozent
Initalisieren, wenn nicht stets erst eine Berechnung ntig
doubl e mehr wer t st euer = 19. 0; //normaler Satz, in %
Mglichst lokal definieren
Schleifenvariablen in der Schleife
for (int i = 1; i<10; i++) {}
2
Java-Konventionen von Sun
Google: Java code conventions (von Sun). Auszug:
Code-Konventionen
Wozu?
Einheitlicher Code (egoless)
Welches sind die besten Konventionen?
Eclipse, Sun, Firma XY, Ihre eigenen?
Welche sollte eine Firma verwenden, wie oft wechseln?
Bekannte
Einfache
Prfbare
Antwort: vor allem immer dieselben!
Eclipse hilft bei Java-Konventionen
Rechtes-Maus-Men
ProPra-Beispiel zur Diskussion
keine Angst: stets anonym
protected JLabel account1, account2;
private IAccount acc1, acc2;
JLabel lblAcc1 = (JLabel)main.getContentPane().getComponents()[6];
JLabel lblAcc2 = (JLabel)main.getContentPane().getComponents()[7];
// Fr die Fhigkeit, ein Fenster darzustellen: die GANZE Klasse
public class Fenster extends JFrame {
public Fenster(){
}
}
public class Konto extends JFrame implements IAccount
public Konto(ArrayList<Konto> liste)
Konto kann alles
Nur der Name neu?
Keine sprechenden Namen
schlecht zu merken
fehleranfllig
Components nicht gemerkt,
Mssen kryptisch angesprochen werden
public MoneyTransfer(Account source, Account destination, int sum)
{
source.setBalance(source.getBalance() - sum);
destination.setBalance(destination.getBalance() + sum);
this.sum = sum;
this.source = source;
this.destination = destination;
}
public void execute()
{
source.setBalance(source.getBalance() - sum);
destination.setBalance(destination.getBalance()+sum);
}
Wieso (erst jetzt)?
Achtung: Schon im Constructor geschehen!
Besser:
1. Parameter in Attribute bernehmen
2. Erst bei explizitem execute() ausfhren
package uebung01;
public class MoneyTransfer implements IMoneyTransfer {
Account source;
Account destination;
int amount;
public MoneyTransfer(Account source, Account destination, int amount) {
this.source = source;
this.destination = destination;
if (amount >= 0)
this.amount = amount;
else
this.amount = -1;
}
public void execute() {
if (amount == -1)
System.out.println("Buchung nicht erfolgreich - negativer Betrag!");
else {
source.setBalance(source.getBalance() - amount);
destination.setBalance(destination.getBalance() + amount);
System.out.println("Buchung erfolgreich!");
}
}
}
Wenig Luft: Leerzeilen, Kommentare
Paketname entspricht nicht der Norm
Abfrage bereits im Konstruktor. Wieso?
Fehler implizit durch Code gekennzeichnet, keine Reaktion
Scheinbar unsinnig enge Abfrage: was ist mit -200?
Information Hiding
Interfaces
Kapitel 2
Programmieren
Dokumentation im Code
Kopfkommentare (header)
Bis zu einer Druckseite/Methode blich
Struktur und Gestalt des Codes
Code ist Dokument, muss lesbar gemacht werden
Einrckungen, Kommentare, Bezeichner
Namen von Variablen, Klassen, Methoden usw.
Hufig Namenskonventionen
Dennoch sprechende Benennung
Kommentare
Wo, wie viel, welche Angaben (v.a. Kopfkommentare)?
Im Projekt standardisieren!
Nicht beschreiben, was man sieht (5 addieren, Exception werfen)
Eher warum es geschieht und warum auf diese Weise
Wichtig wieder:
Rationale
(Begrndung)
Arten von Dokumentation
Fr den Benutzer
Manual, Bedienungsanleitung
Roll-Out-Plan
Wartungsunterlagen, technische Dokumentation
Fr den Entwickler
Codekommentare
Technische Dokumentation
Hintergrundinformation
Fr das Projekt und das Management
Produktdokumentation
Projektdokumentation (Ablauf, Zeitplne, Organisatorisches)
Prozessdokumentation (Zwischendokumente, Prozessangaben)
Javadoc
Verlinkte Dokumentation, aus Kommentaren generiert
doc comments:
/** <docu>*/
Schnitt-
Stellen
(APIs)
Javadoc / Graphics
Externe JavaDoc-Dokumentation erzeugen
1. JavaDoc-Kommentare einfgen
normale Kommentare werden ignoriert
JavaDoc an die richtige Stelle schreiben
Es gibt Schlsselwrter (mit @)
2. JavaDoc generieren
Einige weitere Angaben,
[command liegt unter J ava/bin/javadoc.exe],
dann
3. Erzeugte Dokumentation verwenden
Ein ganzer Dokumentenbaum wird erzeugt; z.B. index.html:
Viel ist mglich in JavaDoc
Externe Dokumentation
Beispiel: Entwurfsidee Huffmann-Code
Teilweise als JavaDoc aus dem Programm generiert
Teils separat geschrieben (nicht im Programm: Beispiel, Theorie)
3
6
7
22
23
30
46
55
200
7
22
23
30
46
55
200
9
3
6
16
22
23
30
46
55
200
7
9
3
6
16
Eintrge nach Hufigkeit sortieren.
3
6
7
22
23
30
46
55
200
9
7
22
23
30
46
55
200
9
3
6
Die zwei kleinsten streichen,
ihre Summe in einen neuen Eintrag
stecken und einsortieren.
Diesen Schritt wiederholen,
bis aus der Liste ein Baum
geworden ist.
A
B
C
D
E
F
G
H
I
Externe Dokumentation
Beispiel: Entwurfsidee Huffmann-Code
Auch interessant: Beweis, dass dies zu optimalem Code fhrt
Wichtige Entwicklerdokumentation: Empfohlene Datenstruktur
geworden ist.
22
23
30
46
55
200
7
9
3
6
16
38
53
84
108
192
392
3
6
7
22
23
30
46
55
200
A
B
C
D
E
F
G
H
I
Jeweils 0 und 1 an
Verzweigung schreiben.
Egal, was wohin.
Der 01-Pfad ist der
Code fr den Buch-
staben
0
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0 0 0 0 1 0
0 0 0 0 1 1
0 0 0 0 0
0 0 0 1
0 1 0 0
0 1 0 1
0 0 1
0 1 1
1
Huffmann-Code
Information Hiding
Interfaces
Kapitel 2
Programmieren
Code organisieren:
Versionen und Konfigurationen
Ziele
Dateien, die bei der Entwicklung anfallen, fr Team koordinieren
Fr alle zugreifbar
Kein versehentliches Lschen
Kein gegenseitiges berschreiben
Klarheit ber jeweils gltige Fassung
xy
yz
xyneu
v1
V2/3
v2
Code organisieren:
Versionen und Konfigurationen
Grundgebriffe
Version =
Def
Definierter Stand eines Dokuments
Konfiguration =
Def
Menge der Versionen aller Bestandteile eines Systems,
die zu einem definierten Stand gehren
v3 v2 v1
v18 v17
V2.0 V1.1 V0.8
Teil A
Teil B
Teil C
System = A+B+C
Zeit
Konfiguration (t
k
)
t
k
Grundlagen
Aufbau einer Versionsverwaltung
DB Filesystem
Repository
Working Copy Working Copy
Client Client
Server
Client Interface
Wichtige Begriffe 1/2
Repository
Zentraler Datenspeicher
Working Copy
Lokale Arbeitskopie
Checkout
Arbeitskopie aus dem
Repository erstellen
Update
Arbeitskopie mit nderungen im
Repository aktualisieren
Add
Neue Datei/Verzeichnis dem
Repository hinzufgen
Checkin/Commit
nderungen der Arbeitskopie ins
Repository schreiben
v1
V2/3
v2
Optimistisch
Mehrere haben Zugriff auf ein Dokument
Falls beide ndern, gibt es Kollission
Pessimistisch
Sicherheitshalber darf nur einer ndern
Keine Kollission
Behindert aber Parallelarbeit
Wichtige Begriffe 2/2
Conflict
Gleichzeitige nderung der selben Stelle einer Datei
Diff
Differenzen zweier Dateien anzeigen
Merge
Zusammenfhren von zwei in Konflikt stehenden Dateien
Tag
Spezieller Name einer Version (z.B.: Release 1.4)
Branch
Separater Zweig eines Projekts, an dem unabhngig vom
Hauptzweig weitergearbeitet wird
Z.B.: Hauptzweig: Firefox 1.5.x, Branch: Firefox 2.0.x
Versionsmanagement
Prinzip (optimistisch)
Grundoperationen
1. Aufsetzen: Pfade, Rechte etc.
2. Datei beim System anmelden: add
3. Datei eintragen: commit
4. Datei herausholen: checkout
5. Datei zurckgeben: commit
6. Datei nochmal holen: update
d
3 commit d
2 add d
1 <Aufsetzen des Systems>
5b commit d
6 update d
Weiterfhrendes
Branches (Verzweigungen)
Abspalten: branch
Verbinden: merge
Konflikte
Nie beim Auslesen: optimistisch
Falls beim Zurckgeben:
Merge versuchen
Sonst Warnung, manuell
4b checkout d
d
4a checkout d
(d ndern)
d
working
directories
5 commit d
7 Konflikt auflsen
8 commit
Information Hiding
Interfaces
Kapitel 2
Programmieren
Sie arbeiten im Team
Stellen Sie sich vor
Sie haben den Huffmann-Code programmiert.
Nun soll ihn das ganze Team benutzen.
Was geben Sie den Kollegen, damit sie das tun knnen?
Was mssen die anderen wissen?
Beispiel Huffmann-Code-Programm
3
6
7
22
23
30
46
55
200
3
6
7
22
23
30
46
55
200
9
7
22
23
30
46
55
200
9
3
6
7
22
23
30
46
55
200
9
3
6
16
22
23
30
46
55
200
7
9
3
6
16
geworden ist.
A
B
C
D
E
F
G
H
I
22
23
30
46
55
200
7
9
3
6
16
38
53
84
108
192
392
3
6
7
22
23
30
46
55
200
A
B
C
D
E
F
G
H
I
Jeweils 0 und 1 an
0
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0 0 0 0 0 1 0
0 0 0 0 1 1
0 0 0 0 0
0 0 0 1
0 1 0 0
0 1 0 1
0 0 1
0 1 1
1
Huffmann-Code
Perspektivenwechsel
Was mchten Sie in dieser Situaton wissen (mssen)?
Oh, es gibt jetzt einen effizienteren
Algorithmus! Verwenden Sie doch
den! Wir haben ein Modul gekauft.
Es ist aber sehr kompliziert; 12
Seiten Mathe wenn Sie das nicht
verstanden haben, knnen Sie das
Programm kaum richtig einsetzen.
Aber wir haben auch die ganze
Entwicklerdoku hier drei Ordner!
Super, oder?
Wollen
Sie
das
BetterCode
+addChar(char, int)
+printCodeBook()
Oder eher das:
Also: Was mssen die anderen wissen?
Beispiel Huffmann-Code-Programm
3
6
7
22
23
30
46
55
200
3
6
7
22
23
30
46
55
200
9
7
22
23
30
46
55
200
9
3
6
7
22
23
30
46
55
200
9
3
6
16
22
23
30
46
55
200
7
9
3
6
16
geworden ist.
A
B
C
D
E
F
G
H
I
22
23
30
46
55
200
7
9
3
6
16
38
53
84
108
192
392
3
6
7
22
23
30
46
55
200
A
B
C
D
E
F
G
H
I
Jeweils 0 und 1 an
0
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0 0 0 0 0 1 0
0 0 0 0 1 1
0 0 0 0 0
0 0 0 1
0 1 0 0
0 1 0 1
0 0 1
0 1 1
1
Huffmann-Code
HuffmannCode
+addChar(char, int)
+printCodeBook()
Das meiste
verstecken wir!
Zum Glck.
Entwurfsprinzip Information Hiding
Von David Parnas, 1972
Absolute Grundlage des SE!
Taucht immer wieder auf
Von Implementierung bis Doku.
Idee: Jede Einheit gibt nur das Ntigste preis, um sie zu nutzen
Das ist die Schnittstelle mit Dokumentation
Wie sie funktioniert, ist dagegen versteckt (hidden)
ndert sich etwas Internes, merkt man es auen nicht
Da vor ihm/ihr versteckt, braucht Nutzer keine Selbstdisziplin
Jede Einheit versteckt (min.) eine Entwurfsentscheidung
Parnas
Beispiel/Szenario
Vereinfachtes Telefonbuch
A schreibt Customer Management System (CMS)
Will darin ein vereinfachtes Telefonbuch nutzen
Beauftragt B
B macht sich Anforderungen klar
(Name, Telefonnummer)-Eintrge verwalten
Suche nach richtigem Eintrag untersttzen
Lschen, Initialisieren
Alles Kompliziertere lassen wir in diesem Beispiel weg!
Namen seien eindeutig, null werde abgefangen usw.
Ziel: Sinn von Information Hiding mit Interfaces zeigen
A
B
Beispiel
Interfaces
PhoneTable
Erster Versuch: B verwendet Array
PhoneTable(int size)
setEntry(int id, String name, String number)
getNumber(String name): String
getID(String name): int
delete(id)
1
2
3
4
5
6
7
Mller
Huber
Schneider
Schmidt
Khler
0511/97865
0241/12-4711
762-19666
001-(303) 492
030/762-123
Als simples Array implementiert
public void organize() {
PhoneTable ph = new PhoneTable(7);
ph.setEntry(3, "May", "089/4567");

nr = ph.getNumber("Khler");
ph.delete(ph.getID("Huber"));
}
CMS verwendet PhoneTable
Beispiel
Interfaces
PhoneList
Zweiter Versuch: B versucht verkettete Liste
first(): Node
search(String): Node
insert(Node)
append(Node)
delete(Node)
Als verkettete Liste implementiert
import theNodePackage.Node;
public void organize() {
PhoneList ph = new PhoneList();
// insert or append
ph.insert(new Node("May", "089/4567"));
nr=ph.search("Khler").get_Number();
ph.delete(ph.search("Huber"));
}
CMS verwendet
PhoneList
Node
1 *
get_Name(): String
set_Name(String)
get_Number(): String
set_Number(String)
get_nextNode(): Node
set_nextNode(Node)
get_prevNode(): Node
set_prevNode(Node)
Mller 0511/97865
Huber 0241/12-4711
Schneider 762-19666
Schmidt 001-(303) 492
Khler 030/762-123
Beispiel
Interfaces
nextNode
prevNode
TreeNode
1 *
C berredet A zu sortiertem Baum
first(): TreeNode
search(String): TreeNode
add(TreeNode)
delete(TreeNode)
PhoneTree
Als speziell sortierter Baum implementiert
import theTreePackage.TreeNode;
public void organize(){
PhoneTree ph = new PhoneTree();
ph.add(new TreeNode("May", "089/4567"));

nr=ph.search("Khler").get_Number();
ph.delete(ph.search("Huber"));
}
CMS verwendet
PhoneList
get_Name(): String
set_Name(String n)
get_Number(): String
set_Number(String nr)
get_leftNode():TreeNode
set_leftNode(TreeNode)
get_rightNode():TreeNode
set_rightNode(TreeNode)
Mller
0511/97865
Huber
0241/12-4711
Schneider
762-19666
Schmidt
001-(303) 492
Khler
030/762-123
< left() > right()
Beispiel
Interfaces
Information Hiding: Interfaces!
add(String name, String number)
get_Number(String name): String
delete(String name)
IPhoneBook
IPhoneBook ph;
ph = new PhoneTree();
ph.add("May", "089/4567");
nr=ph.get_Number("Khler");
ph.delete("Huber");
}
Java
Interface
Beispiel
Interfaces
oder: PhoneList()
oder: PhoneTable(7)
Das ist der einzige Unterschied!
Aber wie ist es denn nun implementiert?
Programming to an Interface
von zwei Seiten: Aufrufer und Anbieter verlassen sich darauf
Beispiel
Interfaces
delete(String name)
interface
IPhoneBook
PhoneTable(int size)
delete(String name)
PhoneTable
delete(String name)
sortInverse()
PhoneTree
Wir wissen es nicht! Und wollen es nicht wissen!

implements Implementierer 3 Implementierer 1
CMS
ph
Aufrufer
Was zeigt das Beispiel
Abhngigkeiten zwischen Programmteilen entstehen leicht
ndert sich eines, muss man das andere ndern
Aufwndig!
Fehleranfllig!
Was fehlte, war ein klarer Bezugspunkt: Schnittstelle/Interface
Zwischen Beteiligten ausgehandelt: Contract
Interfaces
Sind syntaktische Einheit in Java
Abstrakte Klasse mit Methodenschnittstellen, ohne Rmpfe
Im Aufrufer dennoch als Typ verwenden IPhoneBook
Letztlich braucht man natrlich auch eine Implementierung
PhoneTree, PhoneList oder PhoneTable
Vorteile
Nur Implementor-Name ist spezifisch im Aufrufer-Code
Aufrufer braucht bei nderungen im Implementor nichts zu tun
Interface in Java definieren
Schlsselwort interface statt class
Methoden
ohne Rumpf
Interface in Java anbieten/implementieren
usw.
Als Liste implementieren
Spezialmethoden
lieber private machen
Angebotene Methoden aufrufen
IPhoneBook ph;
ph = new PhoneList();
ph.add("May", "089/4567");
nr=ph.getNumber("Khler");
ph.delete("Huber");
}
Methoden wie IPhoneBook
Implementiert als PhoneList
Nutzerprogramm, wie CMS
Information Hiding
Zusammenfassung
Trennung von Schnittstelle und Implementierung
Schnittstelle muss ich kennen
Implementierung lieber nicht (information hiding)
In Java: Spezielle Klassenkonstruktion
Ein Interface kann keine Instanzen haben
Kann ja nichts tun, spezifiziert nur
Etwas allgemeineres Konzept: Abstrakte Klasse
Implementor erbt alle Methoden der Schnittstelle
berschreibt sie, d.h.: implementiert, was da passiert
Kann zustzliche Methoden haben; die nutzt Aufrufer lieber nicht
Nutzer bezieht sich nur auf das Interface
Vorteil von Programming to an Interface
Beide Seiten knnen sich unabhngig ndern
Probleme werden zerlegt
Beispiel aus dem Alltag: Info. Hiding
Volkswagen-Website, 14.11.04
Smart-Website, 14.11.04
Kommunikation nicht nur mit Rechnern
Schnittstellen und APIs
Prinzipien Kohsion und Kopplung
Architektur und Entwurfsebenen
Erfahrungen und Design Patterns
Anforderungen Entwurf Codierung
Kapitel 3
Entwurf
Strukturen und
nicht-funktionale Eigenschaften
Kommunikation ber groe Systeme
Worber kommunizieren?
Auch ber zuknftigen Code
Nicht zu viele Details
Nur die Strukturen
Wozu kommunizieren?
Zur Orientierung
Zum Erklren
Zur Arbeitsaufteilung
Zur Diskussion
Zur Dokumentation
Quellcode
Entwickler
<Mensch>
Entwurf
Einem neuen Softwaresystem Struktur geben
also: strukturieren, was es noch nicht gibt
fr die vielen Entwickler, die es bauen sollen: Vorgabe
nur Strukturen, Details meiden (info. Hiding)
Entwurf aufschreiben
Oft mit graphischen Modellen (UML, folgt spter)
berlegungen und Entscheidungen textuell erklren
Zielgruppe: Entwickler
Aufgabe: ohne Missverstndnisse in Code umsetzen
Ziele
Code verschiedener Entwickler muss zusammenpassen
Qualittsanforderungen strukturell untersttzen
Entwicklung und Wartung eine Richtung geben
Struktur auf Dauer verstndlich machen und dadurch erhalten
Zwischenziele des Entwurfs
Entwurfsideen kommunizieren
Alternativen vergleichen und
diskutieren
Kreativitt nutzen, aber
Ergebnisse sichern
Erfahrungen einflieen lassen
Weichen stellen, wohin der Entwicklungszug fhrt!
Entwurfsstufen
Top-Down Entwurf
Architektur/Grobentwurf: Bleibende Strukturen
Feinentwurf: Strukturen und Schnittstellen
Code: Ausfllen der Strukturen, Erfllen der Schnittstellen
Reifestufen der Entwurfsdokumentation
Skizze an der Tafel
Abgezeichnet in grafischer Notation (meist UML): Draft
berarbeitet
Freigegeben, verbindlich
berlegenswert
Wird Entwurf aktualisiert oder weggeworfen?
Wozu dient ein UML-Modell genau?
Was tut man, wenn man bei Codierung Entwurfsmngel sieht?
Strukturen sind wichtiger als Details
Struktur legt Mglichkeiten fest
Manches ist damit sehr einfach
Anderes sehr schwer
Das muss zu den Anforderungen passen
Leider kennt man die nicht immer
Oder sie ndern sich
Es gibt kaum Patentrezepte
Teile und Herrsche
Kohsion und Kopplung

Daher auch unterschiedliche Lsungsideen
Um damit weiterzuarbeiten: Dokumentieren!
Struktur prgt
Verhaltensmglichkeiten
Grundprinzip: Teile und herrsche
Man kann bei einem (groen) Programm nicht an alles
gleichzeitig denken
Lsung: Probleme zerkleinern
Ein groes Problem wird in mehrere kleinere zerlegt
Dann werden die kleinen rekursiv zerlegt
Die noch kleineren werden gelst das ist einfacher!
Die Lsungen werden zusammengesetzt
Von unten nach oben werden die Teile zusammengesetzt
Bis man wieder auf der obersten Ebene ankommt
Damit sollte das groe Problem gelst sein
Folgt rmischem Prinzip: divide et impera!
Was man erst einmal klein zerlegt hat, hat man im Griff
Wie das rmische Reich oder ein groes Programm
Programmcode im Entwurf strukturieren
Evelyn
entwirft
Strukturierung durch Zerlegen
Schnittstelle:
Durchtrennte
Verbindung
Datenflu
Kontrollflu
Vorstellung des
Programms
Schnittstellen beschreiben
Was gehrt zu einer
Schnittstellenbeschreibung?
Name der Funktion oder Methode
Sichtbarkeit: von wem aufrufbar?
Welcher Parametertyp
Welcher Rckgabetyp
Zusatzinformationen
Sinn der Schnittstelle:
wer nutzt sie fr welchen Zweck?
Pre-/Postconditions
ber Schnitt-Stellen kann man
verhandeln und sie ndern.
Schnittstelle:
Durchtrennte
Verbindung
Datenflu
Kontrollflu
Teilsysteme

Java-Signatur einer Methode
Schnittstellen-Beschreibung fr den Compiler
DEFINITION Die Signatur einer Java-Methode umfasst :=
Def
Methodennamen und Parametertypen
KOMPLIZIERT bei Generics (z.B. List<Type>)
Two method or constructor declarations M and N have the
same argument types if all of the following conditions hold:
Have same numbers of formal and of type parameters
Let <A1,...,An> be the formal type parameters of M and
let <B1,...,Bn> be the formal type parameters of N.
After renaming each occurrence of a Bi in N's type to Ai the
bounds of corresponding type variables and the argument types of M and N
are the same.
GENAUER Two methods have the same signature [ =
Def
]
if they have the same name and argument types:
Java Language Specification, 3rd Edition, 2005.
Download: http://java.sun.com/docs/books/jls/
Alles, was Java wissen muss, um die Methode eindeutig zu identifizieren
ACHTUNG: nicht
den Rckgabewert
(trotz Wikipedia)
Aufruf-Schnittstelle
Schnittstellen-Beschreibung fr den Verwender
public static double factorial (int x)
{
double fact;
...
return fact;
}
Allgemein: die Aufruf-Schnittstelle einer Java-Methode umfasst
alles, was ein Aufrufer/Verwender wissen muss - und nichts mehr:
Modifiers type name (parameter-list) [throws exceptions]
Modifier:
Sichtbarkeit
Modifier:
Klasse/Instanz?
Typ des
Rckgabewerts
Name
Parameter(-liste):
je Typ, Name
Rckgabe eines Werts vom
Rckgabewert-Typ
Dazu: ausgelste
(geworfene)
Exceptions
API: Bedienungshandbuch mit Zusatzinfo
Komfortable Schnittstellen-Beschreibung
Allgemein:
Application Programming Interface (API) =
Def
eine dokumentierte Software-Schnittstelle, mit deren Hilfe ein Programm
bestimmte Funktionen eines anderen Programms nutzen kann
Dokumentation
Was tut die Funktion?
Contract:
Voraussetzungen?
Zusicherungen?
Worauf kann sich Nutzer
verlassen?
Organisatorische Schnittstellen
Zwischen Auftraggeber und
Auftragnehmer
Zwischen einer Business
Unit und der anderen
Zwischen einem Team
und dem anderen
Zwischen einzelnen
Bearbeitern
Auftraggeber
SW-Auftragnehmer
Auch fr diese Schnittstellen gelten sinngem
die selben Regeln und Erfahrungen!
Zusammenfassung: Schnittstellen
Technische Schnittstellen sind exakt festzulegen
Programmiersprachen-spezifisch (Signatur, Aufruf, API)
Paketzugehrigkeit, Aufrufart usw.
Schnittstellen-Beschreibungen beachten!
Organisatorische Schnittstellen so genau wie mglich
Organisationseinheiten und Personen
Aufgaben, Kompetenzen, Verantwortlichkeiten (AKV)
Genaue Regeln bei der bergabe von einem zum anderen
Das reicht noch nicht: Zusatzinformationen nicht vergessen
Sinn der Schnittstelle: wieso und wieso hier getrennt?
Pre-/Postconditions
Ergebnis der Schnittstellen-Verhandlungen
Gute Struktur anstreben
1. Was ist die Struktur von Code?
import theTreePackage.TreeNode;
PhoneTree ph;
ph.add(new TreeNode(Lahm, 089/4567));

nr=ph.search(Beckenbauer).get_Number();
ph.delete(ph.search(Huber));
}
CMS verwendet PhoneTree
this
CMS
new
TreeNode
ph
Phone
Tree
Objekte
u. Nachrichten
Fazit:
Es gibt nicht nur
eine Struktur
Methoden
u. Aufrufe
CMS
TreeNode
PhoneTree
add
search
delete
new
get_Number
Gute Struktur anstreben
2. Was ist gute Struktur?
Wollen wir groe oder kleine Einheiten?
Viele oder wenige?
Wir brauchen Kriterien fr gute Struktur!
Klassen
u. Vererbung
Entry
HelperEntry CodeEntry
UsingHuffmannCode
HuffmanCode
Grade von Kohsion und Kopplung
3. Die wichtigsten Strukturkriterien
Kohsion soll hoch sein
Zufllig
Logisch hnliche Operationen
Zeitlich zusammengehrig (Init)
Sequenziell nacheinander
auszufhrende Funktionen
Um wichtige Funktion herum
Informational
(um Daten gruppiert)
Kopplung soll niedrig sein
Beeinflusst lokale Daten anderer
Globale Daten
Beeinflusst fremden Kontrollfluss
(flags sind bel!)
Explizite Daten-Parameter
Objekt-basiert/-orientiert
Daten verborgen
Methoden zugeordnet
Instanzen von Klassen
besser-werdend
Gleiches Prinzip auf verschiedenen Ebenen
A B C D
Programm-
Einheit P1
P3 P2
Datenelemente
Zugriff von berall
auf alle (globalen) Daten
Programmeinheiten
(Module, Klassen usw.)
Klasse X Klasse Y
A
B
C
D
Klassen
mit Daten
Zugriff auf fremde Daten
nur ber Methoden dort
Selbstaufrufe
mglich
Schlecht: Daten und Programme getrennt, hngen aber voneinander ab
Besser: Objekt-Orientierung
Gleiches Prinzip auf verschiedenen Ebenen
Klasse X Klasse Y
A
B
C
D
Klassen
mit Daten
Zugriff auf fremde Daten
nur ber Methoden dort
Selbstaufrufe
mglich
Aber hier noch nicht gut: Stark gekoppelte Klassen, wenig innere Kohsion
Besser: innen starker Zusammenhalt, wenig zwischen den Klassen
Klasse X Klasse Y
A
C
B
D
Klassen
mit Daten
Weniger
Abstimmungsbedarf
Innen starker
Zusammenhalt
Auch auf grberem Granulat
Hohe Kohsion, niedrige Kopplung anstreben
GUI
Bank
DB
Konto Kredit
Brgschaft
Intro
KontoVerwaltung
Werbung
Oracle
Access
Pakete (Packages)
darin: Klassen
Dazwischen: irgendeine Verwendung
Weitere Entwurfsregeln
genauer hingesehen
Fr schwache Kopplung
Wenige Schnittstellen: nicht viele Verbindungen
Kleine Schnittstellen: wenig Informationen austauschen
(Wenig Interaktion ber Schnittstellen) das ist nicht so wichtig!
Klare Verhltnisse schaffen
Nur explizite Schnittstellen, keine impliziten Nebenwirkungen
Dokumentieren, ob sich Einheit noch ndert (Stabilitt der Schnittstellen)
Weitere Entwurfsregeln
genauer hingesehen
Once and only once: Keine Doppelungen
Algorithmen doppelt
Daten doppelt gehalten
Struktur dupliziert
Fhren zu Inkonsistenzen und nderungsanomalien
Kognitive Grenzen beachten
Nutzer der Schnittstellen soll mglichst wenig wissen-mssen
Interna geheimhalten und verstecken
Struktur des Systems begrnden und dokumentieren:
Hinweis auf hnliche Strukturen im Anwendungsfeld
Hinweis auf hnliche Teamstruktur (schlechter, da vergnglich)
Oder andere, explizit genannte Grnde
Architektur
die Lehre von der Struktur(-ierung)
SW-Architektur beschftigt sich mit
Abstraktion, mit Zerlegung und
Zusammenbau, mit Stil und sthetik.
(Kruchten 95)
Architektur
Legt grobe Struktur fest
Liefert den Bauplan
bergang von Analyse zur Realisierung
Verwendet verschiedene Sichten
Abstrahiert
Erklrt Systemaufbau
Schliet und begrndet Komromisse
Siehe: Starke, G. (2002): Effektive Software-Architekturen. Carl Hanser Verlag

Grundlegende Architekturen
Datenfluss-Systeme
Batch
Pipes and filters
Call-and-return Systeme
Haupt- und Unterprogramme
OO Systeme
Hierarchische Schichten
Unabhngige Komponenten
Kommunizierende Prozesse
Event-getriebene Systeme
Virtuelle Maschinen
Interpreter
Regel-basierte Systeme
Repository-Systeme
DB, Hypertext, Blackboards
Schichten-Architekturen
Monolithisches
System
Anwendung
DB
Infrastruktur
2-Schichten/2-Tier
Anwendung (mit GUI)
DB
Infrastruktur
Geschftslogik
3-Schichten/3-Tier
Externes
Schema
Konzeptuelles
Schema
Internes
Schema
System-Infrastruktur
Gemeinsame Datenbank
Netzwerk
Vgl.: Zuser et al. (2004): Software Engineering mit UML und dem Unified Process. Pearson Studium
Praxis-Zusammenfassung
Schichten-Architektur und Pakete
Erstellen Sie je ein Paket (in Java: Package) fr jeden Aspekt.
Stecken Sie Module, Klassen usw. in diese Pakete, sortiert nach den
Aspekten.
Die Pakete sollen sich nur sparsam gegenseitig aufrufen und
dabei die mittlere Schicht nicht berspringen.
Jedes Paket kann rekursiv weitere enthalten:
entweder feinere Schichten oder
Groe Ansammlungen von Code, die man noch aufteilt.
Vorteile
Sie knnen gezielt auf einen Aspekt zugreifen, ohne andere anzufassen.
Sie brauchen (fast) nichts ber die anderen zu wissen (Information Hiding)
Min. 2
Aspekte?
3
Schichten
Pakete
zu gro?
Rekursiv
verfeinern
Paketstruktur
Architektur finden
N
J
J
N
WENN mindestens zwei der folgenden Aspekte vorkommen:
GUI
Nicht-triviale Logik
Datenverwaltung/Verteilung
DANN verwenden Sie eine Drei-Schichten-Architektur!
Architekturen fr verteilte Systeme
Master-Slave
Client-Server
Peer-to-Peer
Historie der UML
Objektorientierung: Konzepte und Denkweise
Klassendiagramme
Sequenz- und Kollaborationsdiagramme
Weitere Diagrammarten
Kapitel 4
Entwrfe notieren: UML
Modelle im Software Engineering
Wozu grafische Notation (2D)?
Grafische Notation := 2-dimensionale Syntax +Semantik +Pragmatik
Modelltheorie
Irrelevante Details ausblenden
Relevante Eigenschaften hervorheben
Abundante Eigenschaften gnstig gestalten
Leicht zu verstehen
Leicht zu ndern
Menschlicher Kognition entgegenkommen: Patterns, 2D >> 1D (Text)
Spektrum von Formalittsgraden
Mehr oder weniger viele relevante Eigenschaften
Anfangs wenige, Grobstruktur schnell erstellen
Schritt fr Schritt mehr, Detail ausfeilen, nher zum Code
Was ist UML?
Unified Modeling Language
Sammlung vorwiegend grafischer Sprachen [ mehrere! ]
zur Erstellung von Anforderungs- und Entwurfsmodellen
aus verschiedenen Perspektiven
UML-Spezifikation oder UML-Modell =
Def
Sammlung von UML-Diagrammen,
die sich inhaltlich ergnzen und berlappen
Klassenmodell spezifiziert strukturellen Aufbau des Systems
Bei Anforderungen zeigt es folgende relevante Originalaspekte:
Gegenstnde der Realitt, mit denen das System umgehen muss
Bei Entwurf und Implementierung zeigt es:
Klassen der Lsung
Klassen und Objekte: Eine Denkweise
Genauer hingesehen
Eine Klasse ist die gemeinsame Beschreibung
des Verhaltens und
der Attribute
aller Objekte dieser Klasse
Objekte
sind verschiedene Individuen
haben je eigenen Zustand
zeigen Verhalten:
sie versenden Nachrichten
und reagieren auf Nachrichten
anderer Objekte
Klasse beschreibt:
Verhaltensmuster
Attribute pro Objekt
Bezeichner
Jedes Objekt hat
Dieselben Bezeichner
Evtl. verschiedene Zustnde
Evtl. verschiedene Attributwerte
Folglich evtl. verschiedene Situationen
im selben Verhaltensmuster
Interaktionssicht
UML Diagramme
Zustands-
diagramm
Verhaltenssicht:
Innere Zustnde
und Verhalten
der Objekte
einer Klasse
Aktivitts-
diagramm
Aktivittssicht:
Gemeinsame
Bearbeitung einer
Aufgabe
Sequenz-
diagramm
Zusammenspiel
weniger
Objekte
Use Case Diagramm
Benutzersicht: Interaktion von Benutzern mit dem System
Kollaborations-
diagramm
Zusammenspiel
vieler Objekte
VerteilungsdiagrammPhysische Sicht: Physische Systemstruktur und Verteilung
Paketdiagramm Gliederungssicht: Aufteilung in Pakete und Substrukturen
Klassendiagramm
Statische Sicht:
Beteiligte Klassen und Strukturen
Ein UML Modell
Beispiel fr ein Klassendiagramm
Martin Glinz (2002): Vorlesung Requirements Engineering Grundlagen und berblick, Universitt Zrich
Historie: Merger von Methoden
Diagramm von Prof. H. Lichter, RWTH Aachen: Vorlesung Softwareentwicklung, SS 2003, aktualisiert
die drei Amigos
heute UML V2.3 (V2.x) Strkere Formalisierung; Profile zur Erweiterung
UML-Diagramme bearbeiten
Mein Tipp:
Malen Sie erst von Hand
Danach holen Sie sich ein Werkzeug
Fr diese Vorlesung: StarUML (open source, kostenlos)
Download: http://sourceforge.net/projects/staruml (letzter Zugriff: 30.10.2011)
StarUML ist nicht hypermodern, aber leicht zu handhaben
Viele andere Werkzeuge sind fr unsere Zwecke weniger geeignet
Wozu Sie StarUML verwenden sollten
Nach einer Handskizze: Diagramme sauber abzeichnen
Speichern, Datei im Team verteilen und verwenden
ndern und aktualisieren
Generieren, C# usw.?
Es geht noch viel mehr mit StarUML und hnlichen Werkzeugen
Das brauchen Sie in SWT noch nicht
Klassen
Basisvarianten
Bedeutung
Klassenname
Keine Attribute def.
Operationen auch nicht
Verwendungshinweise
Kann Stck fr Stck
vervollstndigt werden
Mssen nicht
Java-konform sein
() ist Konvention
fr Operation,
nicht nur in Java
Dies sind die Minimalangaben
Oft zuerst die Operationen
festlegen: Attribute zweitrangig
Konto
Konto
kontoNr
kontostand
kreditRahmen
verschluesseltePIN
erzeugeKontoNr()
verschluesslePIN()
getKontoStand()
einzahlen()
abheben()
ueberweisen()
istPINkorrekt()
setInhaber()
getInhaber()
setKreditRahmen()
getKreditRahmen()
Konto
kontoNr
kontostand
kreditRahmen
verschluesseltePIN
Attributnamen
Operationsnamen
Konto
+kontoNr: int
-kontostand: EURO
-kreditRahmen: EURO
~verschluesseltePIN: SecretPINtype
+erzeugeKontoNr()
+verschluesslePIN(pin)
+getKontoStand()
+einzahlen(betrag: EURO)
+abheben(betrag: EURO)
+ueberweisen(betrag: EURO, zielkonto: Konto)
-istPINkorrekt(pin)
+setInhaber(name: String)
+getInhaber()
+setKreditRahmen(kreditObergrenze: EURO)
+getKreditRahmen()
Klassen
fortgeschrittene Angaben
Bedeutung
Klassenname
Attribute mit Typen
Sichtbarkeit
+ public
- private
~ package
# protected
Operationen
Sichtbarkeit
Parameter
mit und ohne Typ
Verwendungshinweise
Kann Stck fr Stck
vervollstndigt werden
Man kann Sichtbarkeit auch
zunchst offen lassen
Ebenso: Parametertypen
Viele Tools dulden das nicht:
alle oder keine Sichtbarkeiten
Mglichst wenige
Getter und Setter
Nicht fr alle Attribute
Evtl. im Modell ausblenden
Hintergrundfarbe wei
Farbe, Schatten, 3D vermeiden!
Klassen
und entsprechender Code
UML-Modell
Konto
kontoNr
kontostand
kreditRahmen
verschluesseltePIN
erzeugeKontoNr()
verschluesslePIN()
getKontoStand()
einzahlen()
abheben()
ueberweisen()
istPINkorrekt()
setInhaber()
getInhaber()
setKreditRahmen()
getKreditRahmen()
public class Konto {
public int kontoNr;
private EURO kontostand;
private EURO kreditRahmen;
public SecretPINtype verschluesseltePIN;
public int erzeugeKontoNr() { }
public SecretPINtype verschluesslePIN
(int pin) { }
public EURO getKontoStand() { }
public void einzahlen(EURO betrag) { }
public EURO abheben(EURO betrag) { }
public void ueberweisen
(EURO betrag, Konto zielkonto) { }
private boolean istPINkorrekt
(Object pin){}
public void setInhaber(String name) { }
public String getInhaber() { }
public void setKreditRahmen
(EURO kreditObergrenze) { }
public EURO getKreditRahmen() { }
}
Java
#if !defined(_KONTO_H)
#define _KONTO_H
#include "Kunde.h"
class Konto {
public:
int kontoNr;
int erzeugeKontoNr();
SecretPINtype verschluesslePIN(int pin);
EURO getKontoStand();
void einzahlen(EURO betrag);
EURO abheben(EURO betrag);
void ueberweisen
(EURO betrag, Konto zielkonto);
void setInhaber(String name);
String getInhaber();
void setKreditRahmen
(EURO kreditObergrenze);
EURO getKreditRahmen();
private:
EURO kontostand;
EURO kreditRahmen;
boolean istPINkorrekt(int pin);
};
C++
(Konto.h)
Interfaces
PhoneTree
+add(name, number: String)
+get_Number(name: String)
+delete(name: String)
-sortInverse()
PhoneTable
+PhoneTable(size: int)
+add(name, number: String)
+get_Number(name: String)
+delete(name: String)
IPhoneBook
CMS
+organize()
benutzt ein
Interface
Interface-Symbol
(nur dessen Name ist sichtbar)
realisieren das Interface
IPhoneBook
+add(name, number)
Kompromiss
in StarUML:
Abstrakte Klasse
ACHTUNG
gehen ber
das Interface
hinaus!
<<interface>>
IPhoneBook
+add(name, number)
Oder besser
(geht leider
nicht in StarUML)
Konto
+kontoNr: int
-kontostand: EURO
-kreditRahmen: EURO
~verschluesseltePI N: SecretPI Ntype
+erzeugeKontoNr()
+verschluesslePI N()
+getKontoStand()
+einzahlen()
+abheben()
+ueberweisen()
-istPI Nkorrekt()
+setI nhaber()
+getI nhaber()
+setKreditRahmen()
+getKreditRahmen()
Schlerkonto
+zinssatz
kreditRahmen
= 0
Bankomat
-istPI Nkorrekt()
+kontostandAnzeigen()
+abheben()
+arbeitsKonto
+bedienstation
0..1
0..1
ecKarte
+kontoNr: int
-verschlsseltePI N: SecretPI Ntype
+setPI N()
+getPI N()
+verbucheAbhebung()
+eingeleseneKarte
0..1
1
Kunde
+Name
+inhaber
1..*
1..3
1
1..*
+besitzt
1
1..*
Kundenerfassung
+erffneKonto()
+erfrageNamen()
+erfrageAusweisNummer()
+neueKonten
*
1
Prfbehrde
+vermerkeNeuesKonto()
+getKreditwrdigkeit()
+schufa
1
GUI
+getPI N()
~gebeGeldFrei()
Beziehungen zwischen Klassen
Assoziationen
Kommentar
Vererbung
Multiplizitten
Benannte Assoziationsenden
bedient
Leserichtung
ist-geffnet-in
Interaktion in Sequenzdiagrammen
Sequenzdiagramm 1: Konto anlegen
erffneKonto()
:Kundenerfassung
new()
:Konto
kontoNr
erzeugeKontoNr()
kontoNr
erfrageAusweisNummer()
setKreditrahmen()
erfrageWunschPIN()
verschlsslePIN()
erfrageNamen()
setInhaber()
Schufa
getKreditwrdigkeit()
meldeNeuesKonto()
Interaktion in Sequenzdiagrammen
Bedeutung der Symbole
erffneKonto()
:Kundenerfassung
new()
:Konto
kontoNr
erzeugeKontoNr()
kontoNr
erfrageAusweisNummer()
setKreditrahmen()
erfrageWunschPIN()
verschlsslePIN()
erfrageNamen()
setInhaber()
Schufa
getKreditwrdigkeit()
meldeNeuesKonto()
Das Ganze ist eine
Interaktion, nicht
jede Nachricht fr sich!
new() erzeugt ein Objekt
Objekte
Nachrichten
Antwort
Selbstaufruf
Lebenslinie
Aktivierung
Objektname
(auch Objektname:Klasse)
Anonym, nur
:Klassenangabe
Interaktion als Sequenzdiagramm
Sequenzdiagramm 2: Geld abheben am Bankomaten
:GUI :Bankomat :ec-Karte :Konto
istPINkorrekt(PIN)
getKreditRahmen()
getKontoStand()
abheben (wunschBetrag)
getPIN()
verschlsseltePIN
getPIN()
PIN
gebeGeldFrei (verfgbarerBetrag)
verbucheAbhebung()
verfgbarerBetrag
Kommentar
(in allen Diagrammen erlaubt)
verfgbarerBetrag =
min( wunschBetrag,
kontoStand+kreditRahmen)
Interaktion als Kollaborationsdiagramm
Geld abheben am Bankomaten, andere Modellart
:GUI
:Bankomat
myCard:ecKarte
:Konto
2.1: getPIN() 2.2: getPIN()
1: abheben()
2: abheben()
2.3: istPINkorrekt()
2.4: abheben()
2.4.1: getKontoStand()
2.4.2: getKreditRahmen()
2.5: verbuche-
Abhebung()
2.6: gebeGeldFrei()
Interaktion als Kollaborationsdiagramm
Geld abheben am Bankomaten, andere Modellart
:GUI
:Bankomat
myCard:ecKarte
:Konto
1: abheben()
2: abheben()
2.4: abheben()
2.4.1: getKontoStand()
2.4.1: getKreditRahmen()
2.5: verbuche-
Abhebung()
2.6: gebeGeldFrei()
Objekte
Objekte
Objekte (Namenskonventionen wie blich)
Auslser
Nachrichten mit
Reihenfolge
Unter-Reihenfolgen in
Punkt-Notation (2.3)
Unter-Reihenfolgen,
tiefer verschachtelt (2.4.1)
quivalent zu Sequenzdiagramm
Unterschiede nur in den semantisch
nicht-relevanten Modelleigenschaften.
Fr Handhabung jedoch wichtig.
Konto
+kontoNr: int
-kontostand: EURO
-kreditRahmen: EURO
+erzeugeKontoNr()
+getKontoStand()
+einzahlen()
+abheben()
+ueberweisen()
-istPI Nkorrekt()
+setI nhaber()
+getI nhaber()
+setKreditRahmen()
+getKreditRahmen()
Schlerkonto
+zinssatz
kreditRahmen
= 0
Bankomat
-istPI Nkorrekt()
+abheben()
+arbeitsKonto
+bedienstation
0..1
0..1
ecKarte
+kontoNr: int
+setPI N()
+getPI N()
+verbucheAbhebung()
+eingeleseneKarte
0..1
1
Kunde
+Name
+inhaber
1..*
1..3
1
1..*
+besitzt
1
1..*
Kundenerfassung
+erffneKonto()
+erfrageNamen()
+erfrageWunschPI N()
+neueKonten
*
1
Prfbehrde
+schufa
1
GUI
+getPI N()
~gebeGeldFrei()
Klassendiagramm aktualisieren
Erkenntnisse aus Interaktionssicht einarbeiten
Klassendiagramm aktualisieren
Erkenntnisse aus Interaktionssicht einarbeiten
Konto
+kontoNr: int
-kontostand: EURO
-kreditRahmen: EURO
+erzeugeKontoNr()
+getKontoStand()
+einzahlen()
+abheben()
+ueberweisen()
-istPI Nkorrekt()
+setI nhaber()
+getI nhaber()
+setKreditRahmen()
+getKreditRahmen()
Schlerkonto
+zinssatz
kreditRahmen
= 0
Bankomat
-istPI Nkorrekt()
+abheben()
+arbeitsKonto
+bedienstation
0..1
0..1
ecKarte
+kontoNr: int
+setPI N()
+getPI N()
+verbucheAbhebung()
+eingeleseneKarte
0..1
1
Kunde
+Name
+inhaber
1..*
1..3
1
1..*
+besitzt
1
1..*
Kundenerfassung
+erffneKonto()
+erfrageNamen()
+erfrageWunschPI N()
+neueKonten
*
1
Prfbehrde
+schufa
1
GUI
+getPI N()
~gebeGeldFrei()
5
Methode im Zusammenhang
Modelle fr Statik und fr Dynamik
Konto
+kontoNr: int
-kontostand: EURO
-kreditRahmen: EURO
~verschluesseltePIN: SecretPINtype
+erzeugeKontoNr()
+getKontoStand()
+einzahlen()
+abheben()
+ueberweisen()
-istPI Nkorrekt()
+setInhaber()
+getI nhaber()
+setKreditRahmen()
+getKreditRahmen()
Schlerkonto
+zinssatz
kreditRahmen
= 0
Bankomat
-istPINkorrekt()
+abheben()
+arbeitsKonto
+bedienstation
0..1
0..1
ecKarte
+kontoNr: int
+setPIN()
+getPI N()
+verbucheAbhebung()
+eingeleseneKarte
0..1
1
Kunde
+Name
+inhaber
1..*
1..3
1
1..*
+besitzt
1
1..*
Kundenerfassung
+erffneKonto()
+erfrageNamen()
+neueKonten
*
1
Prfbehrde
+schufa
1
GUI
+getPI N()
~gebeGeldFrei()
Ein Klassendiagramm: Basis und Statische Aspekte
istPINkorrekt(PIN)
getKreditRahmen()
getKontoStand()
getPIN()
verschlsseltePIN
getPIN()
PIN
verbucheAbhebung()
verfgbarerBetrag
Viele Diagramme fr Dynamik
+
= das UML-Modell
:
G
U
I
:Bankomat
myCard:ecKarte
:Konto
1: abheben()
2: abheben()
2.4: abheben()
2.4.1: getKontoStand() 2.4.1: getKreditRahmen()
2.5: verbuche-
Abhebung()
2.6: gebeGeldFrei()
Kollaborationsdiag.
Sequenzdiag.
und andere
Kleine Variationen durch Tooleinsatz
Beispiel: Sequenzdiagramm in StarUML
:GUI :Bankomat :ec-Karte gehaltskonto : Konto
1 : abheben()
2 : getPIN()
3 : verschlsseltePIN
4 : getPIN()
5 : PIN
6 : istPINkorrekt()
7 : abheben()
8 : getKontoStand()
9 : getKreditRahmen()
10 : verfgbarerBetrag
11 : verbucheAbhebung()
12 : gebeGeldFrei()
Nummerierung automatisch
Gelber Hintergrund
(abschaltbar)
Stapel von
Aktivittsboxen
Objektname mit : nur
durch Tricksen
Code entspricht Sequenzdiagramm
istPINkorrekt (eingegebenePIN, verschlsseltePIN)
getKreditRahmen()
getKontoStand()
getPIN()
verschlsseltePIN
getPIN()
PIN
gebeGeldFrei
(verfgbarerBetrag)
verbucheAbhebung()
verfgbarerBetrag
Pseudocode einer Methode des Bankomaten
// Var i abl en sei en vor bel egt
public void abheben (EURO wunschbetrag) {
verschlsseltePIN = meineKarte.getPIN();
eingegebenePIN = dieGUI.getPIN();
if (istPINkorrekt(eingegebenePIN, verschlsseltePIN) {
verfgbarerBetrag = arbeitsKonto.abheben(wunschBetrag);
meineKarte.verbucheAbhebung(verfgbarerBetrag);
dieGUI.gebeGeldFrei(verfgbarerBetrag);
}
}
Aufbau und Verhalten von Klassen
aus mehreren Diagrammen ableiten
Ein Klassendiagramm: Basis und Statische Aspekte
istPINkorrekt(PIN)
getKreditRahmen()
getKontoStand()
getPIN()
verschlsseltePIN
getPIN()
PIN
verbucheAbhebung()
verfgbarerBetrag
Viele Diagramme fr Dynamik
:
G
U
I
:Bankomat
myCard:ecKarte
:Konto
1: abheben()
2: abheben()
2.4: abheben()
2.4.1: getKontoStand() 2.4.1: getKreditRahmen()
2.5: verbuche-
Abhebung()
2.6: gebeGeldFrei()
Kollaborationsdiag. Sequenzdiag. und andere
Bankomat
-istPINkorrekt()
+abheben()
Code
Klassen, Attribute,
Methoden-Schnittstellen (Parameter, Typen)
Teile von Methodenrmpfen
mehrerer Klassen
Methodenrmpfe
Konsistenz von Diagrammen
Ein UML-Modell ist auf mehrere UML-Diagramme verteilt
In der Regel verschiedene relevante Aspekte betont
berlappungen mssen konsistent sein
Objekte passen zu Klassen aus dem Klassendiagramm
Sichtbarkeiten, Parameter und Typen sind konsistent dargestellt
Methodennamen in Sequenzen passen zu Klassendiagramm
Use Case Modelle (kommen noch) passen zu Interaktionspersp.
Verschiedene Interaktionsdiagramme widersprechen sich nicht
Zweck aller Diagramme in einem Modell
Konsistente Darstellung aller relevanten, interessanten Aspekte
Genau genug fr Programmierung
Mglicherweise sogar fr (teilweise oder vollstnd.) Generierung
Wnde
Weitere Beispiele
Computer - Ballspiel
Blast thru Special Edition. rockSolid Software ca. 2002
Wand
Schlger
Boden
Ball
Steine
Klassen-Diagramm des Spiele-Beispiels
Stein
punktewert
istGetroffen ()
Wand
istGetroffen ()
Spiel
hindernisse, ball
score, level
start (), stop ()
nextLevel ()
Schlger
breite
elastizitt
istGetroffen ()
Ball
position, winkel
geschwindigkeit
fliegt-los ()
fliegt ()
trifft (Hindernis)
verschwindet ()
Hindernis
position
groesse
istGetroffen ()
Msste Ball nicht auch ein
Hindernis sein? Sonst prallen
Blle nicht aneinander ab.
Entwurf:
zwischen Anforderungen
und Entscheidungen
Kollaborationsdiagramme
Interaktion mehrerer Objekte in UML
Allgemein
1: <startNachricht()>
[Bedingung] <hier.Zahl>:
antw := nachricht()
Nachrichten
Pfeile mgl. waag-/senkrecht
Bedingung mglich
Antwort mglich (Rckgabe)
<hier.Zahl>: 1, 1.1, 1.2, 1.1.1
:<Klasse>
:<Klasse>
<hier.Zahl>.*: <nachr(args)>
Mehrfach (an alle)
An doppeltes Klassenrechteck
<hier.Zahl>: 1, 1.1, 1.2, 1.1.1 ,
J edoch mit * als letzte Stelle
Beispiel
meinSpiel:Ballspiel
:Ball
:<Klasse>
:Hindernis
1: start()
1.2: fliegt ()
1.2.1*: treffer :=istGetroffen()
punktestand:Score
1.2.2: aktualisien ()
initLevel:Level
1.1: aufbauen ()
Objekte (Alternativen)
Objektsymbol
Klassenrechteck
:<Klasse>
<Objekt:Klasse>
<Objekt>:<Klasse>
Benutzer (Mnnchen)
Sequenzdiagramme
Interaktion von (wenigen) Objekten in UML
Allgemein
Objekte
Unterstrichener
Objektname oder
:Klassenname
Objekt1
<Kommentar
und Be-
schreibung
am Rand.
Zeit von oben
nach unten.>
Lebenslinie des Objekts
:<Klasse>
Konstruktion
Objekt der Klasse
wird erzeugt
new()
Ablauf
Waagrecht oder
schrg (Zeit
vergeht)
<Nachricht>()
<antwort>
Destruktion
Objekt
wird zerstrt
delete()
Selbstaufruf <Nachri>()
Beispiel: Ausschnitt
myGame
:Ball
new()
shoot()
score
delete()
flies()
:Hindernis
hits()
score-or-0
delete()
updateScore()
Fugngerberweg als Sequenzdiagramme
Interaktion weniger Objekte
Beispiel: Kreuzung
Knopf
Anforderung
fussgaengerAnforderung
:Fugngerampel :berweg :Autoampel
stop
gelb
rot
stehen
3 s
rotgelb
grn fahren
go
5 s
go
4 s
30 s
10 s
stop
Zeitangaben
und Klammern sind
UML-Kommentare,
nur fr Menschen
bedeutungsvoll.
Dieser Text ebenso.
Zustandsdiagramme/Statecharts
Verhalten einzelner Objekte in UML
Allgemein
<Ereignis>/[<Konsequenz>]
[<Bedingung>]
Transitionen
Von Zustand zu Zustand
Aber nur, wenn Bedingung erfllt (opt.)
bei Eintritt des <Ereignisses>
lst dies <Konsequenz>aus (optional).
Externe, zeitabhngige und interene
Ereignisse/Konsequenzen.
Entsprechend variiert deren Notation.
Zustnde
mit <Bezeichner>
Hierarchie mglich (groes Oval)
Startzustand: schwarz. Kreis
geht sofort in Folgezustand ber
Endzustand:
Kreis mit schwarzem Kern
<Bezeichner>
<OberBezeichner>
Beispiel
Idee
Bauvorhaben
geplant aufgeschoben
beantragt
bewilligt
In Arbeit
abgeschlossen
Plan_erstellen
stellt_Antrag
abgelehnt
gehtPleite
Stattgegeben/feiere
beauftrage Abnahme
Rohbau Ausbau
Neue Idee
t: 3 Monate
/Beschwerde
T:5Mo
Ampel als Statecharts
Ampelberweg als Statecharts
Gemeinsame Aktivitt mehrerer Objekte
gehen
stehen
1) Fussgngerampel
stop go
Autos
fahren
Beide
Stehen-2
Fussgnger
gehen
Beide
Stehen-1
t:30s/fussg.stop t:10s/fussg.go
t:10s/autos.go Anforderung
/autos.stop
3) berweg
Diskussion
-Licht aus von Kreuzung?
-Timing der Ampeln?
-Hierarchie?
go
t:5s
stop
t:3 s
Licht aus
T:>0:00h
T:>6:00h
Licht aus
T:>0:00h
T:>6:00h
stehen
fahren
2) Autoampel
Rot/gelb
grn
gelb
Vergleich der drei Interaktionsdiagramme
Sequenzdiagramme
Komplizierte Ablufe zwischen wenigen Objekten
Exakte Abfolge auf einen Blick sichtbar
Komplizierte, reiche Notation in UML
Kollaborationsdiagramme
Zusammenarbeit mehrerer Objekte
Abfolge nicht auf einen Blick sichtbar
Relativ einfache Notation in UML
Zustandsdiagramme/Statecharts
Basis: Hierarchische Zustandsautomaten
(siehe Statecharts von Harel)
Kompliziertes Innenleben
einer Klasse, eines Use Case usw.
Zusammenarbeit mit anderen nicht so zentral
Fr jedes UML-Element
(Domain Model, Klasse, Use Case)
einsetzbar.
Ziel:
Genaues Innenleben klren.
Oberbegriff: Interaktionsdiag.
Fr je ein zentrales Szenario
in Use Cases
Nchster Schritt: Code
Pakete
In J ava:Packages
Klassennamen knnen
als <Packagename>::<Klassenname> geschrieben werden
Notizen und
Kommentare
berall in UML
Pakete und Infrastruktur
UML
<Notiz>
<Paketname>
Noch grere Einheiten: Verteilung (Rechner als 3D-Blcke)
Praxis-Zusammenfassung
Von UML-Modellen zu Java-Code
1. Anforderungserhebung liefert auch Domain Model und Use Cases
2. Architekturentscheidung
Siehe Daumenregeln zur 3-Schichten-Architektur
Verteilung und weitere Entscheidungen nach nicht-funktionalen Anford.
Entscheidungen und Grnde (Rationale) dokumentieren
3. Entwurf: Statik und Dynamik nebeneinander her
Domain Model zu Klassendiagramm weiterentwickeln (Statik)
Use Cases zu Sequenzdiagrammen weiterprzisieren (Dynamik, Verhalten)
Evtl. mehrere Sequenzdiagramme pro Use Case, fr verschiedene Szenarien
4. Verbinden
Alle Sequenzdiagramme mit Objekten der selben Klasse kombinieren
Vorteil: Systematische Vorgehensweise ohne groe Brche
Ausblick auf die Theorie:
Modellbasierte SW-Entwicklung
Code
UML
Req.
konventionell
Code
Modelle
fr
Req.
&
Design
(zur
Doku)
Modell-basiert
Spezielle Ausprgung:
Model-Driven Architecture
(MDA)
Von OMG, speziell UML
Schwerpunkte:
-Portabilitt
- Interoperabilitt
MDA
Code
Modelle
fr
Req.
&
Design
&
Code-
Gene-
rierung
Model-getrieben
(MDSD: Model-Driven SW Dev.)
spezieller
Ausblick auf weiterfhrende Themen
Vorlesung im Masterstudium:
Moderne Software-Entwicklungsmethoden (MEM)
Teil 1: Modellbasierte und getriebene Entwicklung
Prinzipien der Codegenerierung aus Modellen
Mit bungen
Vorlesung im Masterstudium:
Experience and Knowledge Management in SE (EKSE)
Wissensbasierte Anstze im SE
Werkzeuge modellgetrieben generieren
Mit intensiven bungen
Unregelmig, auf Englisch
Es gibt auch ganz andere Modellnotationen als UML!
Petri-Netze Synchronisation von Prozessen
EPK Geschftsprozesse
BPMN Business Process Modeling Notation (SOA)
Freihand
Idee der Design Patterns
Beispiel Adapter-Pattern
Beispiel Composite-Pattern
Beispiel Observer-Pattern
Model-View-Controller
Kapitel 5
Design Patterns
Entwurfserfahrungen
Design Patterns
Prinzip: Entwurfserfahrungen verpacken, wiederholt nutzen
Ansatz
Gewisse Probleme im Entwurf tauchen immer wieder auf
Erfahrene Entwickler finden auch hnliche, bewhrte Lsungen
Idee: Problem-Lsungspaar wird als Muster beschrieben
Wenn das Problem noch einmal auftaucht, gleich die Lsung einsetzen
Vorteile
Erfahrung sind in Patterns codiert, nicht im Hirn
Anwendung auch fr nicht so erfahrene Entwerfer mglich
Nur das beste Muster muss man sich merken (Auslese)
Hinweis: Muster sind meist abstrakter als Code
Daher eher UML-Muster als Code. Nur Fragmente von Code.
Vorteil: Nicht nur in einer Programmiersprache anwendbar
Problem ist nur teil-formal beschrieben, Entwickler muss es erkennen
Vorschau: Patterns und Beispiele
Vier Patterns ausgewhlt
Drei einfache, grundlegende
Ein komplizierteres, sehr weit einsetzbares (MVC)
An einem fortgesetzten Beispiel erklrt: Drucker
Das ist NUR EIN BEISPIEL!
Natrlich kann man die Patterns auf vieles andere anwenden!
Das Beispiel ist absichtlich sehr einfach gehalten
Hier zeige ich den Kern davon
Sie bekommen gerne den vollstndigen Code (ist nicht viel)
Flexibilitt frdern: ein Beispiel
4219/MRP
print(text)
print(text)
newPage()
print(text)
newPage()
print(text)
newPage()
StdOutPrinter
newPage()?
newPage():= (mitzhlen, dann)
print("\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n);
Alte
Methode
anpassen
Verallgemeinert: Pattern Adapter
Objekt-Adapter (re)
Erbt nicht von Adaptee
Benutzt aber
adaptee-Objekte,
um SpecificRequest ()
auszufhren
Klassen-Adapter (li)
Gibt einer Klasse ein
neues Methoden-
Interface
Erbt/implementiert
Interface von Target,
erbt echte Methoden
von Adaptee
Nach Gamma et al. (1994) Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley
Blauer Pfeil:
kein UML
Adapter im Drucker-Beispiel
betroffende Codeausschnitte
package de. uni hannover . se. swt . boer se. pr i nt er ;
public interface I Pr i nt er {
public void pr i nt ( St r i ng t ext ) ;
public void newPage( ) ;
}
public class St dOut Pr i nt er {
public void pr i nt ( St r i ng t ext ) {
Syst em. out . pr i nt ( t ext ) ;
}
}
public class St dOut Pr i nt er Adapt er implements I Pr i nt er {
int l i neCount = 0; / / count pr i nt ed l i nes
private St dOut Pr i nt er pr i nt er = new St dOut Pr i nt er ( ) ;
public void newPage( ) {
for( int i = l i neCount ; i < 40; i ++) / / ski p r emai ni ng l i nes
this. pr i nt er . pr i nt ( " \ n" ) ;
l i neCount = 0;
}
public void pr i nt ( St r i ng t ext ) {
this. pr i nt er . pr i nt ( t ext ) ;
. . . / / count pr i nt ed l i nes
}
}
Schlecht: Jede Anwendung zhlt mit, bei diesem Drucker, sagt:
theStdOutPrinter.print("\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n");
Besser: Nur dieser Adapter zhlt mit!
Anwendungen behandeln alle Drucker gleich:
for (IPrinter printer : printers) {
printer.newPage();
printer.print(Aktienauswertung);
}
Gemeinsames Interface
vorschreiben
Pattern Composite
Einheitliche Handhabung, bessere Flexibilitt und nderbarkeit
Beispiel:
graphischer Editor
Gruppierung wie
Linien oder Rechtecke
Alle kann man lschen,
dehnen, frben auf
gleiche Weise
Operation()
Zusammengesetzte Objekte
wie Einzelteile behandeln
(sind gruppiert)
Client unterscheidet nicht
Iteriert wird im Composite
Beispiel: Drucken von Dateien und Ordnern
Idee: Befehl Drucken an Ordner wie an Einzeldateien
Ordner geben den Befehl an ihre Inhalte weiter
und rekursiv weiter
Beispiel: Ordner drucken ohne Composite
Naiver Ansatz
public class MausMenue {
public static void main(String[] a) {
Ordner o1=new Ordner();
o1.add(new WordDatei());
o1.add(new PdfDatei());
o2.add(o1);
}
}
Ordnerstruktur
Men will o2 auf naive Weise drucken:
Alle Elemente von o2 durchgehen
WENN sie pdf oder Word sind: drucken
SONST alle Elemente davon durchgehen
WENN sie pdf oder Word sind:
Schon besser: Rekursiv
SCHLECHT: bei JEDEM AUFRUF ntig!
Aufwndig, fehleranfllig, nderungsfeindlich
o2
o1
WordDatei
WordDatei
PdfDatei
PdfDatei
Beispiel: Ordner drucken
Das mchte man tun knnen
public class MausMenue {
public static void main(String[] a) {
o2.add(o1);
o2.drucken();
}
}
Einfache
Ordnerstruktur
aufbauen
Gesamte Struktur drucken
(wie eine Einzeldatei)
Die Bestandteile vorher
public class WordDatei {
public void drucken () {
System.out.println("WordDatei wird ausgedruckt.");
}
}
public class PdfDatei {
public void drucken () {
System.out.println("Pdf-Datei wird ausgedruckt.");
}
}
public interface Komponente {
public void drucken();
}
und nachher
implements Komponente
implements Komponente
Bindeglied: Composite/Ordner
import java.util.LinkedList;
import java.util.ListIterator;
public class Ordner implements Komponente {
LinkedList inhalt = new LinkedList();
public void add(Komponente k) {
inhalt.add(k);
}
}
public void drucken() {
Komponente komp;
for (ListIterator it=inhalt.listIterator(); it.hasNext(); ) {
komp = (Komponente) it.next();
komp.drucken();
}
Der Witz:
Iteration im Composite
(zusammenges. Objekt)
statt im Aufrufer
Patterneinsatz dokumentieren
Beispiel, hnlich UML
Composite
client
component
composite
leafs
Wie wurde Pattern umgesetzt?
Konkrete Klassen u. ihre
Rollen
Erinnerung
PdfDatei Ordner WordDatei
MausMenue
<<interface>>
Komponente
6
Pattern Observer
Erhht die Flexibilitt, entkoppelt Systemteile
Verschiedene
Sichten auf ein Obj.
Zustand ndert sich
Alle kriegen es mit
Beispiel
Struktur des Patterns
Sequenz--
diagramm
Beispiel fr Patterns
Brse
Beispiel: Brsenkurse
Ein Kurs,
drei Sichten:
zwei Observer,
ein Drucker
Dynamischer Plot
Dynamische Anzeige
Drucken (akt. Wert)
Ausganssituation
public class Stock {
private String name;
private int price; // in cents
public Stock(String name) {
this.name = name;
}
public String toString() {
return this.getName() + " ("
+ String.format("%1.2f", this.getPrice() / 100.0) + ")";
}
public String getName() { return name;}
public int getPrice() { return price;}
public void setPrice(int price) {
if (price >= 0) {
this.price = price;
}
}
}
MainFrame.this.getSelectedStock().setPrice(4711);
printer1.print(MainFrame.this.getSelectedStock().toString());
Aufruf
Brse, nun mit Observer-Pattern
Import java.util.Observable;
publ i c cl ass St ock extends Observable {
pr i vat e St r i ng name;
pr i vat e i nt pr i ce; / / i n cent s
publ i c St ock( St r i ng name) {
t hi s. name = name;
}
publ i c St r i ng t oSt r i ng( ) {
r et ur n t hi s. get Name( ) + " ( "
+ St r i ng. format( " %1. 2f " , t hi s. get Pr i ce( ) / 100. 0) + " ) " ;
}
publ i c St r i ng get Name( ) { r et ur n name; }
publ i c i nt get Pr i ce( ) { r et ur n pr i ce; }
publ i c voi d set Pr i ce( i nt pr i ce) {
i f ( t hi s. pr i ce >= 0) {
t hi s. pr i ce = pr i ce;
this.setChanged();
this.notifyObservers();
}
}
}
Erbt von Java-Klasse Observable
Kann damit alles, was Observable kann
Insbesondere:
1. sich bei nderungen selbst benachrichtigen
2. notifyObservers() meldet an alle Observer weiter
3. Dann mssen sich Observer aktualisieren (update())
Observer an- und abmelden
beim Observable; der verwaltet sie (geerbt)
Jeder Observer trgt sich beim Observable ein
public GraphComponent(Stock stock) {
super();
this.stock = stock;
stock.addObserver(this);
}
public StockQuoteFrame(Stock stock) {
super();
initialize();
this.stockNameLabel.setText(stock.getName());
this.stockQuoteLabel.setText(""+stock.getPrice()/100);
this.stock = stock;
this.stock.addObserver(this);
}
Nicht vergessen: nicht mehr ntige abhngen!
public void dispose() {
super.dispose();
this.stock.deleteObserver(this);
}
Was tut notifyObservers?
public void notifyObservers() {
Observer[] allObservers;
for (ListIterator it=allObservers.listIterator();

it.hasNext(); ) {
obs=it.next();
obs.update();
}
}
}
Ganz einfach: schickt an alle eingetragenen Observer eine update()-Aufforderung
Die Beobachter
public void update(Observable o, Object arg) {
if (this.stock == o) {
this.stockQuoteLabel.setText(""+this.stock.getPrice()/100);
}
}
Patterneinsatz dokumentieren
Beispiel, hnlich UML
Pattern-Symbol:
gestricheltes Oval mit Patternnamen; Pfeile mit Rollennamen
Meist in Kollaborationsdiagramm
Oder wie hier in Klassendiagramm
Zustzliche Text-Info ist meist hilfreich (Begrndung, Methoden etc.)
Observer
StockQuoteFrame
GraphComponent
Observable
Stock
Observer
subject
concreteSubject
observer
concreteObserver
concreteObserver
Spezialfall von
Erben: Interface
realisieren
Patterns verwenden
WENN eines der Patterns mit seinem Problem-Teil zu Ihrem Problem passt
DANN berlegen Sie, ob Sie es einbauen wollen
WENN es sich zu lohnen scheint, DANN bauen Sie es ein
SONST nicht!
1. Geeignete Patterns finden: Im Entwurf
1. Sie sollten einige Patterns auswendig kennen: im Geiste durchgehen
2. Haben Sie ein wichtiges Problem, lesen Sie Problemteile weiterer Patterns durch
2. Anwendbarkeit prfen
1. Passt der Problem Teil?
2. Wie wichtig ist Ihnen die angestrebte Eigenschaft (oft Flexibilitt)?
3. Abwgen und dokumentieren von Nutzen und Aufwand
3. Einsatzort festlegen
Genau festlegen, welche konkrete Klasse o.. zu welcher Rolle im Pattern passt
4. Pattern-Lsungsteil einfgen
In UML-Entwurf, evtl. auch in schon existierenden Code
5. In der Regel erst Pattern aussuchen, dann programmieren
Sehr ntzlich: MVC
Model View Controller
Anwendung (mit GUI)
DB
Infrastruktur
Geschftslogik
3-Schichten/3-Tier
Vgl.: Zuser et al. (2004): Software Engineering mit UML und dem Unified Process. Pearson Studium
WENN Sie ein Programm entwickeln
Mit intensiver Logik/Datenhaltung
UND nicht-trivialer Oberflche
DANN trennen Sie Oberflche vom Rest
UND verwenden Sie dabei das MVC-Pattern
Ziel: Entkoppelung zwischen Inhalt (Model) und
Oberflche (View-Controller)
Gibt genaue Interaktion vor
Damit kann man fast jede Komponente separat
ndern (information hiding, divide et impera)
berblick (Daumenregeln folgen)
Komplizierteres Pattern: MVC
Vorteile:
Vorstrukturiert
Flexibel
Mehrere Sichten mglich
Model
Zustand
View
Ausgabe
Controller
Eingabe
u.Interaktion
Kunden-Adressen
O. Brill, G 302, Tel. 19 672
S. Meyer, G 304, Tel. 19 675
K. Schneider, G 310, Tel. 19 666
Sebastian Meyer
Zi. G 309, 19675
LUH
Welfengarten 1
30167 Hannover
MVC
im Detail
Zuvor
MVC aufbauen
Vs sind Observer
(Pattern im Pattern)
V fragt M nach
Werten, stellt sie
dar (Ausgangsp.)
Bsp. Bankomat
1. Benutzer gibt 4
Ziffern ein, ok
2. V informiert C
ber Eingabe
3. C teilt M die
Ziffern als PIN mit
4. M prft PIN, lsst
Benutzer ein
5. M informiert V
6. V fragt nach
Kontostand, stellt
ihn dar
1 2
3
4
5
6
Zugrunde liegendes Bild: Sun (2002)
http://java.sun.com/blueprints/patterns/MVC-detailed.html
Beispiel fr MVC
im Detail
Zuvor
Zwei Sichten
haben sich bei
Dateien (z.B.
Einfhrunsv...)
angemeldet
Interaktion
Benutzer ndert
Dateinamen:
1. Gibt String ein in C
2. C teilt File M neuen
Namen mit
3. File M bernimmt
Namen
4. File informiert seine
Observer (V1, V2)
ber nderung
5. V1, V2 fragen nach
Namen, stellen ihn
(verschieden) dar
Java-Beispiel
Emailchecker evaluiert Email-Adressen
Wie lang sind sie? LengthView
Sind sie zu lang? Bar View
Ziel dieses Beispiels: reines MVC
Echtes Java-Beispiel
Nutzt MVC in Java
Sonst nichts, so klein und simpel wie mglich
LengthView
BarView
Relevanter Code
Die Anwendung als Applet, MVC-Teile fett
publ i c cl ass Emai l Checker Appl et ext ends J Appl et {
EmailEvaluator model = new EmailEvaluator();
LengthView numbView = new LengthView(model); / / Zahl
BarView barView = new BarView(model); / / Bal ken
publ i c voi d i ni t ( ) {
t hi s. set Si ze( 400, 140) ;
Gr i dLayout gr i dBag = new Gr i dLayout ( 2, 1) ;
get Cont ent Pane( ) . set Layout ( gr i dBag) ;
/ / Vi ews i n di e Gr i dBag ei nf gen
get Cont ent Pane( ) . add( numbVi ew) ;
get Cont ent Pane( ) . add( bar Vi ew) ;
}
}
Relevanter Code
Model
publ i c cl ass Emai l Eval uat or extends Observable {
pr i vat e St r i ng emai l ="";
publ i c voi d set Emai l ( St r i ng emai l Addr ess) {
email = emailAddress; // Model aendert sich
setChanged(); / / Auf Aender ung hi nwei sen
notifyObservers();
}
Relevanter Code
LengthView
publ i c Lengt hVi ew( Emai l Eval uat or anEval uat or ) {
t hi s( ) ; / / baut GUI - El ement e zusammen
model = anEvaluator;
model.addObserver(this);
evalController = new EmailEvalController(model);
set Pr ef er r edSi ze( new Di mensi on( 350, 100) ) ;
}
public void update( Obser vabl e obs, Obj ect obj ) {
length.setText(String.valueOf(model.getLength()));
r epai nt ( ) ;
}
LengthView wei selbst
- interessanten Aspekt in Model
- wie holen
- wie darstellen
Relevanter Code
BarView
publ i c cl ass Bar Vi ew ext ends J Panel implements Observer{
private EmailEvaluator model;
publ i c Bar Vi ew( Emai l Eval uat or aModel) {
super ( ) ;
model = aModel; / / i n MVC ei nbauen
model.addObserver(this);
}
publ i c voi d update( Obser vabl e i gnor ed, Obj ect al soI gnor ed) {
r epai nt ( ) ; / / r uf t pai nt ( ) auf , akt ual i si er t Bal ken
}
publ i c voi d pai nt ( Gr aphi cs g) {
super . pai nt ( g) ;
. . .
/ / Far ben mar ki er en, ob di e Lnge akzept abel i st
i f ( numOf Char s > 23) {
gc. set Col or ( Col or . RED) ;
. . .
gc.fillRect(5,5, barLength , 30); / / Emai l - Bal ken zei chnen
}
}
Die Grenzen
(23) gehren
eigentlich zur
Logik und
damit zum
Model.
Wichtige Variante: MVC im Web
Beispiel: Play!-Framework
Folgt MVC
Aber modifiziert
Kein Observer VM mglich
V bemerkt M-nderung nicht
hnliche Umsetzung
HTTP-Request lst aus
Framework sucht zustndigen C
Controller vermittelt an M, Vs
Antwortet: HTTP Response
Das ist blich und ok!
Modifiziertes MVC-Pattern
fr das Web: keine Observer
In der View:
eingeschachteltes 2. MVC
Nur in Bezug auf diese View.
MVC in die Architektur einbetten
WENN Sie in eine nicht-triviale GUI und mindestens einen der folgenden Aspekte haben:
Nicht-triviale Logik
Datenverwaltung/Verteilung
DANN verwenden Sie MVC zur Entkoppelung
Legen Sie dabei View und Controller in eine Schicht (die oberste)
Zunchst: jede Schicht ein Java-Package
Darunter: Schicht bei Bedarf noch in feinere Pakete zerlegen
View und Controller mglichst in unabhngige Klassen u. Pakete
Aber gerade VC lassen sich nicht immer wirklich trennen
In Java arbeiten Sie mit Listenern fr Controller; das geht
In C# oder Visual Basic ist die Trennung schwerer mglich
Andere Sprachen sind bei VC oft auch eigenwillig
Legen Sie das Model in eine andere Schicht
Model muss von VC besonders klar getrennt sein, in allen Sprachen
Drei-Schichten-Architektur st ein Spezialfall
Vorteile
Oberflchen ndern sich oft; nicht mit Model vermischt, nderungen unabhngig
Selbst ohne klaren Controller sind VC von M getrennt; geht in vielen Sprachen
Ideal ist natrlich eine weitere Trennung von V und C
(Datenschicht)
Model
View Controller
Schicht
Packages
(rekursiv)
Optional: 3.Schicht
Es gibt etliche Patterns
Das Gamma-Buch ist der
absolute Klassiker GoF
Hat eine Disziplin
begrndet
Enhlt mehr als 20
Patterns
Sind Allgemeingut
Wenige andere
bekannt
Jeder kann eigene
definieren
Aber es sind nicht
hunderte von Pattern
Ein SW-Designer kann
- und sollte! - sie kennen
Bewertung von Design Patterns
Grere (und abstraktere) Entwurfsbestandteile
als Klassen und Objekte; programmiersprachen-unabhngig
Patterns sind konstruktive Qualittssicherung
Qualitt betroffen (oft: mehr Flexibilitt)
Rationale/Begrndung gehrt zum Pattern
Erklrungen werden kompakter mit Patterns
Effiziente Kommunikation unter Experten mglich
Davon profitieren Lesbarkeit, Flexibilitt, Wartbarkeit
Ein Pattern-Katalog ist wie ein Musterbuch fr Architekten
Sind in der OO-Zunft bekannt und werden vorausgesetzt
Fast jeder Entwickler hat davon gehrt
Profis knnen sie selbst einsetzen
7
Aufgaben und Herausforderungen
Structured Analysis (SA) mit
Datenflussdiagrammen (DFD)
Objekt-Orientierte Analyse (OOA)
Ablufe erfassen mit Use Cases
Kapitel 6
Anforderungen
Die Basis des Projekts
Professionelle Anforderungsanalyse
Ist doch ganz einfach:
Der Kunde beschreibt,
was er mchte,
und wir bauen das!
So einfach ist es leider nicht.
Da lauern berall Fallen
und Missverstndnisse.
Aber wenn man sie kennt,
kann man damit umgehen.
naiv
professionell
Kunde beschreibt was er mchte
Wenn jemand Software will,
kommt er zu uns
er muss eben genau sagen,
was er will
aber wir kennen uns ja auch
aus, vielleicht sogar besser als
so mancher Kunde
Vielleicht braucht er vor allem
bessere Geschftsprozesse?
Man muss schon zum Kunden
gehen, und so genau kann der
das gar nicht sagen
Anfngerfehler! In seinem Fach
ist der Kunde Knig und kennt
sich aus
und berhaupt
Wer ist der Kunde?
Nutzer
Kufer
Manage-
ment
?
Symmetry of Ignorance beachten
nach Gerhard Fischer
Unverstndnis zwischen Informatikern und Kunden fhrt sehr oft
zu vielen Missverstndnissen und zu Frustration
Kunden/Fach-Leute wissen nicht
was Software leisten kann
was Informatiker knnen
wovon sie reden (UML)
welche Lsungen mglich wren
dass die Informatiker sie auch
nicht verstehen
? ?
Informatiker wissen nicht
wie das Geschft luft
was Kunden wollen, brauchen
was sie meinen
was das Problem ist
dass sie es nicht wissen
Hinterfragen Sie scheinbare
Selbstverstndlichkeiten
Hten Sie sich davor zu glauben,
Sie wssten sowieso, was der Kunde will
Unverstndnis auf beiden Seiten
( symmetrisch )
ber
mich
ber
Partner
ber Be-
ziehung
Anforderungserhebung als
Kommunikationsaufgabe
ber
Partner
ber Be-
ziehung
ber
die Sache
ber
die Sache
ber
mich
Feedback
Auf allen Ebenen
Antworten
Beobachtungen
Warnungen
Finetuning
Beispiel
Sie mssen sich natrlich an
alle blichen Sicherheits-
standards halten;
wir versuchen das auch stets.
Kommunikation = Sprechen und Verstehen
Beispiel
(Sie wissen hoffentlich, welche
Standards das sind?)
(Traue ich Ihnen kaum zu, sonst
msste ich das nicht sagen)
(Ich bin hier der Boss deshalb
dieser Ton)
(Wir schaffen es selten, aber wir
geben es nicht zu)
Naives Loswerkeln rcht sich
Stellen Sie frh fest,
wer Anforderungen hat
Versetzen Sie sich in seine/ihre
Lage, so gut es geht
Beschftigen Sie sich mit dem
Arbeitsgebiet des Kunden
Nehmen Sie nichts fr
selbstverstndlich,
fragen Sie nach
Glauben Sie nicht,
Sie wssten schon alles
Kommunizieren Sie
bewusst auf allen Ebenen
Prfen Sie, was Sie gefunden
haben und wiederholen Sie
Betreiben Sie systematisch
(folgt )
Erinnerung wieder einmal Engineering:
a systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of Requirements
Konsequenzen auf den Umgang mit Anforderungen
Kostendenken
Qualittsbewutsein
nicht nur subjektiv definiert
Anwendung von Normen und Regeln
keine Knstler
Baugruppen und Wiederverwendung
statt not invented here
Probleme durch Zerlegung lsen
divide et impera
Systemanalyse Req. Management
E
l
i
c
i
t
a
t
i
o
n
I
n
t
e
r
p
r
e
t
a
t
i
o
n
N
e
g
o
t
i
a
t
i
o
n
D
o
k
u
m
e
n
t
a
t
i
o
n
V
a
l
i
d
.
/
V
e
r
i
f
.
C
h
a
n
g
e

M
g
m
t
.
T
r
a
c
i
n
g
Aufgaben im Requirements Engineering
Anforderungen suchen: Elicitation
Herauskitzeln von Anforderungen
Grober Ablauf
1. Stakeholder herausfinden: wer ist betroffen?
2. Umfeld des Systems erheben: Altsysteme, Schnittstellen, Doku.
3. Sprechen mit Stakeholdern
Sprechen: Interviews, Workshops, Fragebgen
Beobachtung und Aufzeichnung
Regelrechte Elicitation-Techniken fr tacit knowledge
Rohanforderungen mssen danach veredelt werden
Beispiel Bankomat
Stakeholder: Kunden; die Bank; DB-Admin; Geldbefller
Schnittstellen: zur DB, zu Schalterauszahlung u. Money-Mgmt.
Sprechen: Interview mit Schalterbeamten, Kundenfragebogen
Interpretation von Anforderungen
Die Anforderungen werden inhaltlich bearbeitet
Dazu ist Interpretation (=Zusprechen von Bedeutung) ntig
Diese Interpretation kann falsch sein!
Spreu vom Weizen trennen
Was ist essenziell, was Nebensache
Was ist wirklich gefordert, was nur Erluterung
Ordnen und Sortieren, Strukturieren
hnliche Anforderungen zusammen
Detaillieren und Konkretisieren
Formulierungen schrfen (erfordert Interpretation)
Prfbar machen
Beispiel Bankomat
Identifikation: Stornierung ist vor ok-Button gefordert, danach nicht mehr
Sortieren: Anford. an die Bedienung; an die Geschwindigkeit; an die Funktion
Konkretisieren: Jede Kontostandprfung muss in 5 s. fertig und besttigt sein
1 Identifikation
2 Strukturierung
Verfeinern
Verschmelzen
Gruppieren
3 Konkretisierung
1. Abhngigkeiten identifizieren
Eine Anforderung erzwingt andere.
Beispiel: Online-berweisung => Alpha-Tastatur => Sicherheitsanf.
Anforderungen widersprechen sich
2. Widersprchliche Anforderungen identifizieren
Bsp.: Mchtiges Werkzeug oder billiges Hilfsmittel?
Bsp.: Fr Laien oder fr Experten optimiert?
3. Konflikt ist blich: Verhandlungsprozess, Moderation ntig
Es gibt nicht eine objektive Wahrheit, sondern viele Interessen
4. Inkonsistenzen auflsen oder auch nicht!
Entscheidungsprozess
Selten eine technische Entscheidung
Mit gewissen Widersprchen kann man leben
Anforderungen verhandeln: Negotiation
Dokumentation
Anforderungen zu hren reicht nicht
Anforderungen mssen fixiert werden
Und trotzdem ndern sie sich!
Aber nur bei dokumentierten merkt man es
Anforderungen drfen sich ndern
Dann muss man nachdokumentieren
Und bezahlen muss das der Urheber (meistens)
Sehr wichtig: mehr dokumentieren als reine Anforderungen
Gesprchspartner, Rollen, Ziele
Hintergrnde und Randbedingungen
Annahmen
Absichten, Rivalitten, alte Fehlversuche
1 Fixieren
2 Zerlegen in
Einzelanforderungen
3 Mit Attributen
beschreiben
4 Anforderungen
verbinden
Verbesserte Noteneinsicht
Beispiel
Stellen Sie sich vor, es gibt eine Idee:
Noten sollen schon vor Einsichtnahme zu sehen sein
Aber noch nicht freigegeben kann sich ja noch ndern!
Daran hngen viele weitere Anforderungen
Von Studierenden
Von Lehrenden
Von Fachschaft
Von Prfungsamt
Werden erhoben wie oben beschrieben (Elicitation, Int., )
Fiktives
Beispiel
Dokumentation
(Auszug)
[R01] Studierende haben Zugang ber Name und PIN
Entscheidungstabelle, in Workshop abgesegnet (Negot.-WS)
[R02] PIN fnfstellig, nicht mit Matrikelnummer korreliert
Matrikelnummer steht ffentlich auf Studentenausweis (Dekan)
Fnfstellige PINs ausreichend (Theorie-Vertreter)
[R03] Alle Verbindungen zum Notenserver sind verschlsselt
Fordern Dekanat, Prfungsamt, Dozenten. Studierende implizit.
[R04] Zugriff nur auf die eigenen Noten mglich
Kein online-Gesamtaushang, damit keine externen Robots (anonyme)
Notenprofilauswertungen vornehmen knnen
[R05] Statistik ebenfalls nur dort sichtbar, nicht offen
Siehe [R04]
[R06] Alle eigenen Noten des laufenden Prfungszeitraums zusammen
bei einem Login zu sehen
Studenten wollen sich weder mehrfach einloggen noch Klausurnamen merken
Fiktives
Beispiel
Vielfltige Beziehungen von Anforderungen
manuell kaum zu berblicken
Es gibt noch mehr Beziehungsarten
Es gibt weitere Dokumente
Anforderungen werden verfeinert: Dokument->Satz
Man kann Regeln (ber Beziehungen) definieren
...
Und so weiter!
Rand-
bedingungen
Anforderungen
Glossar
Parameter
Parameter-
formate
verwendet
Format
wird eingeschrnkt
durch
verwendet
Schnittstellen
verwendet
Definiert in
Definiert in
Verfeinert
verwendet
Begriff
Validierung und Verifikation
Begriffe
Validierung :=
sind die dokumentierten auch
die wirklichen Anforderungen?
Egal, was bisher
aufgeschrieben wurde
Verifikation := stimmen Anf. mit
zuvor dokumentierten berein?
Egal, ob der Kunde das
(noch) wirklich will
Inhaltliche
Prfung
Formale
Prfung
Validierung
Verifikation
Verschiedene Prfungstechniken
Validierung: Befragung, Interview,
Nachprfung, Konfrontation
Stimmt der Inhalt?
Verifikation: Formale Verfahren,
Konsistenzprfungen, Erreichbarkeit
Ist alles Bisherige korrekt
weitergegeben worden?
Verschiedene Referenzpunkte
Requirements Management
Die Verwaltung der Anforderungen
Leicht handhabbar ablegen
Werkzeug (wie Doors, RequisitePro)
nderungen und Versionen
im Griff behalten
Besonders interessant: auch die
Grnde fr nderungen erfassen
und aufbewahren!
nderungen weitergeben,
Verfolgbarkeit in beide Richtungen
(Tracing)
Das ist sehr schwer!
Schon seit Jahrzehnten ungelst
Hier helfen Werkzeuge
Verfolg-
barkeit
(Tracing)
nderungs-
management
nderungs-
wnsche
Versionen von
Anforderungen
(Historie)
Propagieren
der nderung
(->Tracing)
Festhalten
der Annahmen,
Quellen von
Anforderungen
(pre-tracing)
Auswirkungen
von Anforderg.
im System
(post-tracing)
Req. Management
Klassifikation von Anforderungen
Funktionale Anforderungen an das Produkt
Was die SW tun soll
Nicht-funktionale Anforderungen an das Produkt
In welcher Weise die SW es tun soll
Qualittsanforderungen
Flexibilitt, Portabilitt, Wartbarkeit, Schnelligkeit usw.
Andere nicht-funktionale Anforderungen
Mengengerst
Prozessanforderungen
Welchen Ablufen und Vorgaben das Projekt folgen soll
Projektanforderungen
Mit welchem Zeit- und Geldbudget das Projekt auskommen soll
8
Klassifikation
(Fiktives Beispiel; Auszug)
[R01] Studierende haben Zugang ber Name und PIN
Entscheidungstabelle, in Workshop abgesegnet (Negot.-WS)
[R02] PIN fnfstellig, nicht mit Matrikelnummer korreliert
Matrikelnummer steht ffentlich auf Studentenausweis (Dekan)
Fnfstellige PINs ausreichend (Theorie-Vertreter)
[R03] Alle Verbindungen zum Notenserver sind verschlsselt
Fordern Dekanat, Prfungsamt, Dozenten. Studierende implizit.
[R04] Zugriff nur auf die eigenen Noten mglich
Kein online-Gesamtaushang, damit keine externen Robots (anonyme)
Notenprofilauswertungen vornehmen knnen
[R05] Statistik ebenfalls nur dort sichtbar, nicht offen
Siehe [R04]
[R06] Alle eigenen Noten des laufenden Prfungszeitraums
zusammen bei einem Login zu sehen
Studenten wollen sich weder mehrfach einloggen noch
Klausurnamen merken
Funktional
Funktional
Funktional
Funktional
Sicherheit
Qualittsanford.
Sicherheit
Qualittsanford.
Fiktives
Beispiel
Klassifikation
(Fiktives Beispiel; Auszug, fortgesetzt
[R42] Der jetzige Arbeitsablauf von Dozenten und
Prfungsamt ist zu beachten. Mehraufwand ist zu
vermeiden
[R61] Die technische Schnittstelle zu den HIS-
Programmen ist unvernderlich und muss beachtet
werden.
[R82] Das Programm soll bis zum Sommersemester

operativ laufen
[R89] Alle Studierenden der Fakultt sollen dann alle

neuen Klausurnoten einsehen knnen.
[R90] Eine Zugriffsrate von 200 Personen pro Tag, bis zu

20 gleichzeitig muss verkraftet werden und darf
nicht zu Antwortzeiten von ber 10 sek. fhren
Funktional
(Geschftsproz.)
Constraint
Qualitt/Geschw.
unklar def.
Mengengerst
Mengengerst
Projektanford.
Fiktives
Beispiel
bersicht:
Techniken um Anforderungen
Bisher:
Wieso sind Anforderungen so wichtig?
Wo sind die Schwierigkeiten?
Aufgaben und Forschungsthemen im RE
Weiter mit Techniken zum RE:
Anforderungsanalyse mit Datenflssen (Strukturierte Analyse)
Das Wichtige betonen: Essenzielle Systemanalyse
Denken in Objekten: Objekt-Orientierte Analyse
Ablufe im Zentrum: Use Cases
Elicitation
Interpretation
Negotiation
Documentation
Validation
Tracing
Kapitel 6
Anforderungen
Structured Analysis (SA)
dt.: Strukturierte Analyse
Eine wichtige, grundlegende Methode vonTom DeMarco
Idee:
Man muss verstehen, wie die Daten
durch das System flieen sollen.
Das dann zu programmieren ist leicht
Tom DeMarco
Atlantic Systems Guild
Grundelemente von SA
Datenflussdiagramme (DFDs)
Data Dictionaries (DD)
Prozessbeschreibung (MiniSpecs)
Es gibt andere, hnliche Notationen:
Gane/Sarsson ist auch sehr bekannt
Relativ hnlich wie DeMarcos
Strukturierte Analyse hilft
Lsungsvorschlge aus SA
Keiner wei so recht, nach welchen Anforderungen fragen
Welche Daten sind ntig?
Wo kommen sie her, wo flieen sie?
Wie soll man fragen, um wahre Anforderungen zu erfahren?
Kunden danach fragen, welche Daten sie/er will und welche hineingehen
woher und wohin die Daten laufen, wie sie aufgebaut sind
ob alle fr einen Bearbeitungsschritt ntigen auch vorhanden sind
Wenn Anforderungen kommen: wie aufschreiben?
Grafisch und handmalbar, das ist besser fr Laien (?)
wohl-definiert: Bedeutung muss klar sein
Wie sicherstellen, dass Notiertes bercksichtigt wird?
Einbauen dieser grafischen Modelle in eine Methode -> Entwurf
Grundelemente der Strukt. Analyse (SA)
bersicht
Datenflsse ...
Quellen und Senken liegen
auerhalb des Systems
... mit Beschriftung:
Datenflussdiagramme (DFDs)
... kommen aus Prozessen oder gehen
in sie hinein
In Datensammlungen (Files) kann
man Daten aufbewahren
Beschriften und Verfeinern
Data Dictionary:
Namen der Datenflsse
Minispecs
Prozesszerlegung, feinste Ebene
Kunde Drucker
Druckauftrag
System
Weniger Komplexitt durch Zerlegung
Tom DeMarco
When a system is too large to be shown on a single page (...) we
will devide ... into subsystems. And so on.
Tom DeMarco: Structured Analysis and
System Specification. Prentice-Hall 1979
Context Diagram (CD) bei DeMarco
Grenzt relevanten Bereich ab
Notationsregeln
Alle Externals tauchen im CD auf
Externals tauchen nur im CD auf
Es gibt im CD nur einen Prozess
Der Prozess hat die ID 0
Handgemalt ist wichtig
Entsteht in der Diskussion
Sauber abmalen ist oft
kontraproduktiv
Beispiel: Klausurverwaltung
Klausur
DFD-Elemente (1)
Syntax Semantik - Pragmatik
DFD
<Nr>
<Bezeich.>
4
Kunden-
identifi-
zieren
<Bezeichner>
KartenDaten
Beispiel Bankomat
Prozess
Verarbeitungsschritt, wandelt
Datenflsse in andere um
Kreis mit ID-Nummer
ID auf jeder Ebene eindeutig!
In Context-DFD nur 0, nchste
Ebenen jeweils: 1, 2, 3
Hierarchische ID: 1.1, 1.2 etc.
Bezeichner eindeutig im Modell
Datenfluss
Daten, die ein Prozess zu
seiner Arbeit braucht
Pfeil mit eindeut. Bezeichner
Syntaxregeln fr Datenflsse:
Nicht direkt zwischen
Speichern oder Externals
Immer Prozess dazwischen!
Keine Zyklen
Parallele Datenflsse
sind durchaus oft sinnvoll
DFD-Elemente (2)
<Bezeichner>
<Bezeich.> ec-Karte
KundenDaten
DFD Beispiel Bankomat
External
Etwas auerhalb des Systems
Personen und Systeme
Interagiert mit dem System -
liefert Daten (nicht nur Start-
Impuls), erhlt Resultate
Viereck mit eindeut. Bezeichner
Speicher
Um sich Daten zu merken
Dadurch zeitliche Entkopplung
der Prozesse
Zwei Striche mit eind. Bezeichner
(Nur) Datenflsse von/zu Spei-
chern drfen unbeschriftet sein!
Dort fliet je genau ein Element
des Speichers
Doppelpfeile sind falsch: Zyklus
DFD-Elemente (3)
Ein Element besteht aus mehreren Teilen:
A= B + C + D
Element ist eine von mehreren
Alternativen A = [ B C D ]
Ein Element ist optional (kann fehlen)
A = B+(C)
Ein Element tritt ein bis mehrmals auf:
A = {B}+C+D
Kommentar: *Sterne links u. re.*
Textuelle Beschreibung
KartenDaten =
Name + verschluesselte_PIN
Name = [ PersName FirmenName ]
PersName = (Titel)+Vorname+Name
Kundenkontakt =
{Kd-Adresse}+email+Handy-Nr
*Limit: in Euro;nach Bonitt*
Data Dictionary
Verzeichnis von Datenelementen: Datenflsse, Speicher
Verfeinerung und Aufbau: Woraus besteht das Element (unten)?
Textuelle Beschreibung: weitere Informationen zum Element
Notation Beispiel Bankomat
<Bez>
Hauptwort
(Bsp: Kunde)
<Nr>
<Bez.>
Zur schnellen
Identifikation
Zur leichten
Kommunikation;
oft: <Objekt><Verb>
(Bsp. Geld abheben)
Spezifisch formulieren!
Ausnahme im
ContextDFD:
Auch Systemname
(Bsp: Bankomat)
<Bez.>
Daten, nicht Impulse!
Eindeutiger Bezeichner,
Oft: <Adjektiv>_<Subst.>
(Bsp.: gewhlter_Betrag)
<Datensatzbez.>
Wie heit ein Datensatz?
Nicht: wie heit die
Sammlung? (Also nicht:
Kundenstamm)
DFDs: Regeln zur Benennung
So werden DFDs besser lesbar
Auf Arbeitsebene beginnen
mittlere Ebene
Student
Fiktives
Beispiel
Dozent
Noten
eintragen
1
DozentenPIN
Status
Klausurergebnisse
Auswertung
erstellen
2
Statistische_
Auswertung
Prfung
zugeordnete_
Prfungen
HIS
End-
ergebnisse
melden
4
Besttigte_Klausurlisten
Name
PIN
Eigene-Notenliste
eigene
Noten
Abfragen
3
Einzelnote
Studierender
Data Dictionary
Status = [ pending final]
Klausurergebnisse = gepr_Fach+{Name+Matrikelnr+Note}
Zugeordnete_Prfungen =
DozentenID+{gepr_Fach+Prfungsnummer}
Einzelnote=Matrikelnr+Prfungsnummer+Note+Status
Studierender = Name+Matrikelnr+PIN
Besttigte_Klausurlisten = Prfungsnummer+{Einzelnote}
Systemabgrenzung festlegen
Mit Context DFD diskutieren
Student
HIS
Wichtig!
Die Pfeile in/aus dem Prozess
mssen exakt mit denen in der
Verfeinerung bereinstimmen!
Fiktives
Beispiel
Noten
eintragen
End-
ergebnisse
melden
Auswertung
erstellen
Dozent
Einzelnoten
Prfung
DozentenPIN
Status
Statistische_
Auswertung
zugeordnete_
Prfungen
Name
PIN
Eigene-Notenliste
eigene
Noten
abfragen
NotenOnlineAbfrage
0
Klausurergebnisse
Studierender
und dann verfeinern
Student
Fiktives
Beispiel
Dozent
Noten
eintragen
1
DozentenPIN
Status
Klausurergebnisse
Auswertung
erstellen
2
Statistische_
Auswertung
Prfung
zugeordnete_
Prfungen
HIS
End-
ergebnisse
melden
4
Name
PIN
Eigene-Notenliste
eigene
Noten
Abfragen
3
Einzelnote
Studierender
Data Dictionary
Status = [ pending final]
Klausurergebnisse = gepr_Fach+{Name+Matrikelnr+Note}
Zugeordnete_Prfungen =
DozentenID+{gepr_Fach+Prfungsnummer}
Einzelnote=Matrikelnr+Prfungsnummer+Note+Status
Studierender = Name+Matrikelnr+PIN
Besttigte_Klausurlisten = Prfungsnummer+{Einzelnote}
Verfeinern von Prozessen bei Bedarf
zweite Ebene unter ContextDFD
Wichtig!
Die Pfeile in/aus dem Prozess
mssen exakt mit denen in der
Verfeinerung bereinstimmen!
Fiktives
Beispiel
Noten
eintragen
1
Dozent
Einzelnote
Prfungen
DozentenPIN
Status
Klausurergebnisse
Einzelnote
Prfung
DozentenPIN
Status
Klausurergebnisse
zugeordnete_
Prfungen
Berech-
tigung
prfen
1
Prfungsnr.
zuordnen
2
Einzelnoten
eintragen
3
Verfeinern in Minispecs
unterste Ebene
Student
Fiktives
Beispiel
Einzelnote
Name
PIN
Eigene-Notenliste
eigene
Noten
abfragen
3
Studierender
Hier gibt es keine
expliziten
Pfeile mehr, aber im
Minispec werden
Datenflsse
angesprochen
(konsistent!)
3 eigene Noten abfragen:
Wenn PIN zu Name passt:
SELECT
e.gepr_Fach,
e.Prfungsnummer,
e.Note
FROM Einzelnote e
INNER JOIN Studierender s
WHERE
s.Matrikelnr = s.Matrikelnr
oder
3 eigene Noten abfragen
Wenn PIN zu Name passt:
Suche alle Einzelnote heraus,
die zu Studierender
passen.
Anhand der Matrikelnr.
feststellen.
Modellarten in der Strukturierten Analyse
Modellierte Aspekte
Prozesse
Datenflsse
Speicher
Aufbau der Daten
System
Analyse, Anforderungen
Ist-Modell/-DFD
Soll-
Modell/-DFD
Umsetzung
i
Kapitel 6
Anforderungen
Wie Strukturierte Analyse die Welt sieht
Irgendwo flieen Daten und Informationen
Irgendwer (oder -was) fhrt Prozesse durch
1
Identifi-
zieren
2
Authenti-
fizieren
4
Abheben
3
Kontost.
holen
Kartendaten
Konto
nr
PIN
Kunden-
ID
Betrag
A
u
s
z
a
h
l
e
r
Auth.Kd.
Auth.
Anrede
Kontostand
Kontostand
Limit
Stand
Neue Sichtweise: OOA
(objekt-orientierte Analyse)
Die Welt besteht aus Objekten (Dingen, Agenten)
Objekte sind unterscheidbar
Sie schicken sich Nachrichten und interagieren auf diese Weise
Konto
Karten-
leser
Karte
Realer
Kunde
Geld-
betrag
Bankomat
Kunden-
stamm
Identifiziere-mich
Finde-Kd
konto
Hebe-ab
Zahl-Dich-aus
Gebe-Scheine
Stecke-ein
Erinnerung:
es geht hier um die oo Analyse eines Systems und seines Umfeldes
Beschreibung Schritt fr Schritt (=Methode)
1. Systemgrenzen festlegen
2. Objekte finden (stehen fr reale Dinge, Konzepte etc.)
3. Objekte sortieren und klassifizieren (Domain Concepts)
4. Interaktion und Abhngigkeiten ermitteln
Schritte 1-4 werden zwei Mal absolviert:
Zunchst IST-Zustand ermitteln
Dann den Soll-Zustand
Objekt-Orientierte Analyse
Beispiel: OOA fr das Computerspiel
Zu Anfang: Idee im Kopf
1.Schritt: Systemgrenzen festlegen
Wie viele Levels?
Highscore?
Internet-Option?
Spielstandspeicher?
Musik?
Ladbare
Elemente?
Spieler-erweiterbar?
und so weiter...
2. Schritt: Objekte finden
Soll-Analyse
Entwickeln Sie ein Computerspiel,
bei dem man einen Schlger
(unten im Bild) lenkt.
Ein Ball wird ins Bild geschossen, er
trifft auf Hindernisse (Steine, Bomben)
und zerstrt diese. Das gibt Punkte.
An anderen prallt er ab.
Wenn der Ball am Schlger vorbei
unten aus dem Bild luft, ist er weg.
Dann kommt der nchste Ball
Entwickeln Sie ein Computerspiel,
bei dem man einen Schlger
(unten im Bild) lenkt.
Ein Ball wird ins Bild geschossen, er
trifft auf Hindernisse (Steine, Bomben)
und zerstrt diese. Das gibt Punkte.
An anderen prallt er ab.
Wenn der Ball am Schlger vorbei
unten aus dem Bild luft, ist er weg.
Dann kommt der nchste Ball
Objekte suchen:
Substantive
unterstreichen
Wnde
Objekte festlegen
Danach kommen Entwurf u. OO Programmierung
Wand
Schlger
Boden
Ball
Steine
DANN
3. Identifizierte Objekte klassifizieren und
Klassen ableiten
4. Beziehung und Interaktion festlegen
weiter mit UML
Kapitel 6
Anforderungen
Wichtig: Use Cases
Definition
Beschreibung einer Interaktion zwischen (min.) einem Akteur
und dem System, durch das ein Ziel des Hauptakteurs erreicht wird.
Beispiel Bankomat (Kern eines Use Case)
Use Case Geld abheben
1. Kunde f hr t Kar t e i n Kar t enschl i t z ei n
2. Syst emf r agt nach PI N
3. Kunde gi bt PI N ei n
4. Syst emf r agt nach gewnscht er Akt i on
5. Kunde whl t Abhebung und gi bt Bet r ag ei n
6. Syst emgi bt zuer st Kar t e aus, dann Geld
7. Kunde kann si ch Qui t t ung geben l assen
8. Syst emgeht i n den Ausgangszust and ber
Akteur
(Actor)
Ziel: Geld haben
Absichten, keine
Interface-Details!
Sys-Grenzen?
(Scope)
Interaktion
...
Ablauf
...
Wozu Use Cases?
Beschreiben das Systemverhalten
Das ganze, extern wahrnehmbare Systemverhalten
Aber nicht mehr als das (keine Interna, keine Qualittsanforderungen)
Meist von Entwicklern geschrieben
In Zusammenarbeit mit Fach-Experten
Diskussion fhrt zu Reflexion, klrt vieles (elicitation)
Sind Basis fr alle weiteren Aktivitten
Stellen Analyse-Schritt dar (Ist-Use Cases)
Reprsentieren Requirements (Soll- Use Cases)
Design muss Use Cases ermglichen
Testflle knnen aus Use Cases abgeleitet werden
Hinweis: Einfacher Use Case ist nahe an Testfall ist aber keiner
Use Case: Klasse von Ablufen. Testfall: ein ganz konkreter
Als Contract (Vertrag) dienen sie beim Abnahmetest
Formate fr Use Cases
Im Prinzip ist jedes Format mglich - wenn es hilft
In der Literatur dominieren die graphischen UML-Modelle
Aber Achtung!
Diagramme zeigen nur den berblick
Welche use cases gibt es?
In welcher Beziehung stehen Actors und use cases?
Sie zeigen nicht: den eigentlichen Kern des Use Cases
die Abfolge der Schritte,Vor- u. Nachbedingung etc.
Geld abheben
Bankomat
Primary Actor Use Case Beziehung Actor (System)
Use Case-Diagramme
Allgemein
actor
<Name>
<Name>
Aktoren mit Namen name
Rechteck fr Systeme
Stereotype <<actor>>
Strichmnnchen sonst
include
Ausgeklammerter
Teil-Use Case
extend
Optionale
Erweiterung
<UC name> Use Case mit Namen name
<Actor> nimmt teil an <UC>
Systemgrenze (Rahmen)
Geld abheben
Beispiel
Kunde
Kontostand prfen
Quittung drucken
include
extend
actor
Konten-DB
Betreuer
Bonitt prfen
include
Makler
actor
Bankomat
Formate fr Use Cases
Die Interaktionen knnen in vielen Notationen beschrieben
werden
Ablaufdiagramm
Struktogramme
Petri-Netze
Pseudo-Code
Echter Code
Wichtig: ihre Aufgabe ist Kommunikation unter Menschen
Daher eignet sich fr viele Use Cases besonders: Text
Aber den sollte man strukturieren
Stile textbasierter Use Cases
nach Alistair Cockburn / (meine deutschen Entsprechungen)
Narrative / Geschichtchen (noch kein Use Case)
Peter braucht schnell Geld frs Kino. Er betritt den
Bankomatenraum und steckt seine Karte ein. Dadurch wird er
identifiziert und durch seine PIN authentifiziert. Er gibt den Betrag
ein, erhlt Geld und Karte.
Brief / Kurzfassung
Ein Absatz: Zusammenfassung, oft des Haupt-Erfolgsszenarios.
Casual / Informell
Mehrere informell geschriebene Abstze, darin mehrere Ablufe.
Fully dressed / Detailliert
Am ausgefeiltesten.
In Tabellenform sind alle Schritte und Varianten detailliert
aufgefhrt. Zusatzangaben wie Voraussetzungen, Garantien.
Elemente von Use Case Beschreibungen
Akteure / Actors
auerhalb der Systemgrenzen
Interagiert mit dem System im Rahmen des Use Case
Hauptakteur (Primary Actor): der, dessen Ziel erreicht werden soll
Stakeholder
Jemand mit Interesse am Use Case - muss nicht daran teilnehmen
Wer ist das? Fertigkeiten, Aufgaben, Hintergrund? -> Separate Tabelle
Systemgrenzen / Scope
Was gehrt noch zum modellierten System, was nicht mehr?
Erfolgsfall und Misserfolgsfall / success and failure
Wenn der gewnschte Fall eintritt bzw. wenn er nicht eintritt
Garantie
Was man auch im Misserfolgsfall noch sicherstellen kann
Formular fr einen vollen Use Case
Use Case Nr . <nr >
Umf el d
Syst emgr enzen
Ebene
Haupt akt eur
St akehol der
u. I nt er esse
Vor ausset z.
Gar ant i en
Er f ol gsf al l
Ausl ser
Beschr ei bung
Er wei t er ungen
Technol ogi e . . .
<Name: kurzer, aktiver Satz>
Umf el d
<Scope: was gehr t noch dazu?>
<ber bl i ck, Auf gabe oder Tei l f unkt i on>
<Kur zbeschr ei bung dessen, der Zi el hat >
St akehol der I nt er esse
<er st e> <i hr e I nt er essen>
<zwei t er > <sei ne I nt er essen>
<wovon kann man bei Begi nn ausgehen?>
<was i n j edemFal l gewhr l ei st et i st >
<bei er f ol gr ei cher Beendi gung>
<wann der Use Cases st ar t et >
Schr i t t Akt i on
1 <von Ausl ser bi s Auf r umen>
2 <z. B. : . . zur ck i n Ausgangsz.
1a WENN . . . DANN <and. Use Case>
<Var i at i onen dur ch Techni k>
Szenario :=
Ein Ablauf in
einem Use Case
N-
Beispiel: Bankomat
Use Case Nr . 3
Umf el d
Syst emgr enzen
Ebene
Haupt akt eur
St akehol der
u. I nt er esse
Vor ausset z.
Gar ant i en
Er f ol gsf al l
Ausl ser
Beschr ei bung
Er wei t er ungen
Technol ogi e . . .
berweisung am Automaten ttigen
I mBankf oyer , r obust es Gehuse m. Tast .
Kei n Bel egl eser . Tr ansakt i ons- Schni t t st
Noch sel t ene, aber wi cht i ge Auf gabe
Bankkunde wi l l ber wei sung di r ekt ei nt i ppen
Kunde si cher ! schnel l , wi e gewohnt auf
Papi er . Bel egausgabe
Bank Umweg ber Papi er ver mei den,
weni ger Er f asser - Auf wand
I st unt er sei ner PI N ei ngel oggt
ber wei sung ganz oder gar ni cht ; er kennbar
ber w. ver anl asst , Bel eg ausgedr uckt
Kd. dr ckt i mHaupt men ber wei sung
Beispiel: Bankomat
Beschr ei bung
Er wei t er ungen
Technol ogi e . . .
Schr i t t Akt i on
1 Kd dr ckt ber wei sung
2 Syst emzei gt Hi nwei s, dass er TAN
br aucht . Kd qui t t i er t .
3 For mul ar wi e Papi er er schei nt
4 Kd f l l t di e Fel der aus. I st Kd f er t i g, schal t et
er wei t er
5 Syst emzei gt ausgef l l t es For mul ar
6 Syst emf r agt nach TAN
7 Kd gi bt ( ver deckt ) TAN ei n
8 Sys f r agt , ob Bel eg gewnscht . Kd best t i gt
9 Sys dr uckt Bel eg
10 Sys ver abschi edet si ch, Ruhezust .
2a WENN Kd kei ne TAN dabei hat DANN br i cht Kd ab
5a WENN ei n Fel d f al sch ausgef l l t i st DANN
f r agt Syst em( nur ! ) nach di esemFel d. Kd macht
Angaben. Wei t er : 5
7a WENN ungl t i ge TAN, DANN Fehl er mel dung,
zur ck zu 6
I n Fi l i al en mi t Fi nger kuppenl eser kei ne TAN nt i g
Use Case Nr . <nr >
Beschr ei bung
Umf el d
Syst emgr enzen
Ebene
Haupt akt eur
St akehol der
u. I nt er esse
Vor ausset z.
Gar ant i en
Er f ol gsf al l
Ausl ser
Haupt szenar i o
Er wei t er ungen
Technol ogi e . . .
<Name: kurzer, aktiver Satz>
<i nf or mel l er Text >
<unt er wel chen Umst nden ei nzuset zen?>
<Scope: was gehr t noch dazu?>
<ber bl i ck, Auf gabe oder Tei l f unkt i on>
<Kur zbeschr ei bung dessen, der Zi el hat >
St akehol der I nt er esse
<er st e> <i hr e I nt er essen>
<zwei t er > <sei ne I nt er essen>
<wovon kann man bei Begi nn ausgehen?>
<was i n j edemFal l gewhr l ei st et i st >
<bei er f ol gr ei cher Beendi gung>
<wann der Use Cases st ar t et >
Schr i t t Akt i on
1 <von Ausl ser bi s Auf r umen>
2 <z. B. : . . zur ck i n Ausgangsz.
1a WENN . . . DANN <and. Use Case>
<Var i at i onen dur ch Techni k>
Das Cockburn-Use Case-Formular
Bitte verwenden
Wie man Use Cases einsetzt
1. Akteure identifizieren
1. Wer benutzt das System? Wozu? -> Actor Profile-Tabelle
2. Wer ist mit Ein- und Ausgaben konfrontiert?
2. Systemgrenzen festlegen
Akteure sind auen, Use Cases beschreiben das Hin und Her
3. Wichtigste Use Cases identifizieren
Narrative, Beziehung zwischen Use Case und Actor herstellen (UML)
4. Zunehmend genauer beschreiben
1. Narrative (Geschichtchen)
2. Kurzfassung -> Informell oder Detailliert
1. Erfolgsszenarien
2. Fehlerszenarien
3. Use Cases mit dem Kunden diskutieren
4. Bei Bedarf: grafische bersicht (UML, Beziehungen) ergnzen
Zwei Schleifen: ber alle Use Cases, durch die Ebenen; mit Kunden
Wann ist man fertig?
Fertig, sobald
alle Hauptakteure identifiziert
ihre Ziele genannt
durch mindestens je einen Use Case abgedeckt
Und wenn alle Use Cases klar und verstndlich geschrieben:
Sponsoren sagen (agree), sie knnen damit Abnahme machen
Nutzer sagen, sie knnen das als Systemverhalten akzeptieren
Sponsoren sagen, die Use Cases sind (erst mal) vollstndig
Natrlich ist man dann nicht endgltig fertig!
Tipps und Tricks
Use Cases erfassen nur funkt. Anforderungen, die aber alle
Zuerst in die Breite arbeiten, dann in die Tiefe
Eher zu wenig als zu viel schreiben
Sonst liest es eh keiner, dann hilft es nichts
Es geht um das Geschriebene, nicht das Gemalte
Diskussion ber Formalitt und Stil nicht bertreiben
Es kommt letztlich halt auf Klarheit an - egal, wie
Keine if-Konstrukte in Hauptszenarios
Sond. Extensions/Abzweig-Szenarien
Sehhhe nicht aus den Augen verlieren
aus Cockburn, A.: Writing Effective Use Cases. Addison-Wesley, 2001
essenzielle Use Cases
Werkzeuge verbinden Arbeitsschritte
Beispiel: DOORS
Bilder von:
Ian Alexander: SemiAutomatic Tracing of Requirement Versions to Use Cases Experiences & Challenges
Eindeutige ID
Anforderung
Grund
Anforderung
im Use Case
Beispiel:
Testfall vs. Use Case zum Bankomat
Beschr ei bung
Er wei t er ungen
Technol ogi e . . .
Schr i t t Akt i on
1 Kd dr ckt ber wei sung
2 Hi nwei s er schei nt , dass er TAN
br aucht . Kd qui t t i er t .
3 For mul ar wi e Papi er er schei nt
4 Kd f l l t di e Fel der aus
5 I st Kd f er t i g, schal t et er wei t er
6 Ausgef l l t e ber wei sung wi r d gezei gt , nach TAN
gef r agt
7 Kd gi bt ( ver deckt ) TAN ei n
8 Sys f r agt , ob Bel eg gewnscht
9 Sys dr uckt Bel eg
10 Sys ver abschi edet si ch, Ruhezust .
2a WENN Kd kei ne da hat DANN beendet er di e
Auf gabe
5a WENN ei n Fel d f ehl t oder f al sch i st DANN
f r agt Syst emnur nach di esemFel d. Wei t er : 6
7a WENN ungl t i ge TAN, DANN Fehl er mel dung,
zur ck zu 6
I n Fi l i al en mi t Fi nger kuppenl eser kei ne TAN nt i g
Testfall
Ablauf gleich
Aber konkrete
Eingaben in
Formular
- Empfnger: Bill
- Betrag: 50
- Kontonr.: 3312
- BLZ: 500 000 12
- Grund: Wette
- TAN=45312
Konkretes Soll:
berweisung
besttigt
(und durchgef.)
Gliederung eines Anforderungsdokuments
Beispiel fr ein Lastenheft-Inhaltsverzeichnis
1 Aufgabe und Grenzen
1.1 Was sind Aufgabe und Grenzen?
1.2 Stakeholders - wen betrifft es?
1.3 Was ist in den Grenzen, was nicht?
2 Begriffe und Glossar
3 Use Cases
3.1 Hauptakteure und ihre Hauptziele
3.2 Use Cases fr Business-Prozesse
3.3 Use Cases fr System-Prozesse
4 Eingesetzte Technologie - Anforderungen und Schnittstellen
5 Andere Anforderungen
5.1 an das Entwicklungsprojekt (Teilnehmer, Feedback, Abh.)
5.2-5.n Business rules, Performance, Security, Documentation,
Usability, Maintenance and Portability, Unresolved or deferred
6 Risikovorsorge und organisatorisches Umfeld
6.1 Notlsung bei Ausfall; politische Anforderungen; erwartete System-
Auswirkungen; Trainings-Bedarf; Annahmen und Voraussetzungen
Nicht-funktionale
und Qualitts-
anforderungen
Es gibt auch Projekt- u.
Prozess-, nicht nur
Produkt-Anforderungen
In Anlehnung an: Cockburn, A.: Writing Effective Use Cases. Addison-Wesley, 2001
Anforderungen: Bezugspunkt von SW-Entwurf, -Entwicklung, -Test
Anforderungen sind aber nicht leicht zu bekommen
Sie erfordern Kommunikation mit Fach-Leuten
Symmetry of ignorance
Alle Schwierigkeiten blicher Kommunikation eingeschlossen
Requirements Engineering umfasst mehrere Aktivitten
Elicitation: Herauskitzeln
Interpretation: Das Gehrte deuten
Negotiation: Priorisieren, Widersprche auflsen, Verhandeln
Dokumentieren: Aufschreiben
Validation & Verification: Prfen
Managen und Tracen: Verfolgen, nderungen einarbeiten
Wichtige RE-Techniken
Structured Analysis (SA): Anforderungen aus Datensicht
Objekt-orientierte Analyse: Die Welt aus interagierenden Objekten
Use Cases: Ablufe im Zentrum
Wiederholung: Anforderungen
Aufgaben des Projektleiters
Aufwandsschtzungen
Risikomanagement in Softwareprojekten
Kapitel 7
Projektmanagement
Wo alles zusammenspielen muss
Was ist ein Projekt?
Inhaltlich abgeschlossenes Vorhaben
Keine stndige Aufgabe
Vorhaben komplexer Natur
Zeitlich begrenzt
Definierten Anfangs- und Endtermin
Einmaligkeit der Bedingungen (nicht immer das Gleiche: Risiken)
Projektziele
Neuartige oder unbekannte Probleme zu lsen
Abgrenzung der Aufgabe
Mitwirkende Organisationen
Projektteam: Teilnehmende Personen
Budget und Ressourcen
Arten von Software-Projekten
nicht alle Projekte sind gleich (... aufwndig etc.)!
Art der Software
Art der Aufgabe
Neuentwicklung
Wartung
Weiterentwicklung
Prozessanalyse
Integration COTS
K
a
u
f
m
n
n
i
s
c
h
e
A
n
w
e
n
d
u
n
g
T
e
c
h
n
i
s
c
h
e
A
n
w
e
n
d
u
n
g
E
c
h
t
z
e
i
t
s
y
s
t
e
m
S
y
s
t
e
m
n
a
h
e
A
n
w
e
n
d
u
n
g
I
n
t
e
r
n
e
t
A
p
p
l
i
k
a
t
i
o
n
W
i
s
s
e
n
m
g
m
t
.
S
y
s
t
e
m
Softwareprojekt A
Softwareprojekt B
Softwareprojekt C
Softwareprojekt D
Angelehnt an: Houdek, Frank (2002): Vorlesung Management von Software-Projekten, Univ. Ulm
Gutes Projekt-Management
Erfolgsfaktoren fr Projekte
Einbeziehung der Benutzer (aller Stakeholder, 16%)
Untersttzung durch das Management (14%)
Klar beschriebene Anforderungen (13%)
Geeignete Planung (10%)
Realistische Erwartungen (8%)
Ausreichend feine Meilensteine (8%)
Gut ausgebildete Mitarbeiter (7%)
Ownership (5%)
Klare Vision und Ziele (3%)
Motivierte, hart arbeitende Mitarbeiter (2%)
Sonstiges (13%)
Chaos Report, The Standish Group, 1995: Ein Klassiker
Klassische Fehler in der Software-Entwicklung:
Es wird direkt mit der Codierung angefangen
Das Vorgehensmodell fehlt bzw. wird nicht befolgt
Die Terminvorgaben sind unrealistisch
Die Weiterbildung der Mitarbeiter ist nicht zielgerichtet
Auswahl und Einsatz der Werkzeuge bzw. Methoden ist
unzureichend vorbereitet
Risikomanagement wird nicht betrieben
Eine Abnahme der Phasenergebnisse erfolgt nicht
Es wird nicht systematisch bzw. unzureichend getestet
Anforderungen und Qualittsziele werden nicht festgelegt
Was soll Projektmanagement verhindern?
Quelle: Interne Untersuchung bei Bosch
Organisation von Projekten
Projektleiter
Kunde
Mitarbeiter (Team)
Management
der eigenen Firma
Lenkungsausschuss
Stab
Projektleitung
Management
Kunde
Mitarbeiter (Team)
Teamleiter
Teilprojekte
Grer,
komplexer
Pfeil:
Bericht,
Zuarbeit
SW-Projekt als Regelstrecke
Projektmanagement als Regler
Regelstrecke
(Projekt)
Regler
(PM)
Strgre
Ausgangsgr.
(Ergebnisse)
Fhrungsgr.
(Ziele, Anf.)
Zustandsdaten
Steuergr.
(Manahmen)
Aufgaben des Projektleiter:
Planen, Steuern, Messen
Risikomanagement
Kapitel 7
Projektmanagement
Aufgaben des Projektleiters
Regelstrecke
(Projekt)
Regler
(PM)
Strgre
Ausgangsgr.
(Ergebnisse)
Fhrungsgr.
(Ziele, Anf.)
Zustandsdaten
Steuergr.
Manahmen
Planen
Schtzen
Fhren
Messen
Risiken abwehren
Reprsentieren
Planen
Geistige Vorwegnahme des Kommenden
Ein Projekt muss geplant werden
Was erreicht werden soll
Welche Aufwnde und Zeit es brauchen darf
Wann was getan werden muss
Wer zustndig ist, wie geprft wird
Planung ist ein Kompromiss
Schtzen, wie lange es dauert/wie viel man braucht
Bercksichtigen, wie viel der Kunde und die eigene Firma geben kann
Entscheiden, was die Vorgabe an das Projekt ist
Plan liegt meist zwischen Wunsch und Schtzung
Forderung an ingenieursmiges Vorgehen:
Schtze nicht blind, sondern messe und vergleiche mit Deiner Schtzung.
Auf dieser Basis schtze das nchste Mal besser.
Welche Aspekte sind zu planen?
Was ist zu tun?
Struktur der Aufgabe
Organisation des Projekts
Planung der Arbeitspakete
Reihenfolgen
Kapazitten
Kosten
Verwaltung
Risiken
Lastenheft, Pflichtenheft
Projektstrukturplan (PSP)
Leitung, Zustndigkeitstabelle
Arbeitspaketbeschreibung
Netzplan, Ablaufplan
Kapazittenplan
Kostenplan
Berichtsplan, Projektakte
Risikolisten
Projekt-
definition
Projekt-
struktur
Organi-
sation
Arbeits-
pakete
Abhngigk.
Zeiten
Berichts-
wesen
Kapazitt
Kosten
Risiken
Planungsprozess
Legende
Wichtig, hier neu
An anderer Stelle besprochen
Projektdefinition
Oft schon vor Projektbeginn bzw. im Vorprojekt
Beim Projektstart: Kickoff
Offizielle Vorstellung von Aufgabe und Leiter
Startschuss
Ergebnis der Projektdefinition:
Lastenheft und Pflichtenheft/Spezifikation
Sinn: Bezugspunkt fr Entwicklung, Prfung, Planung
Wer definiert das Projekt?
Auftraggeber? Lenkungsausschuss?
Mgmt. des Auftragnehmers? Projektleiter?
Projekt-
definition
Projekt-
struktur
Organi-
sation
Arbeits-
pakete
Abhngigk.
Zeiten
Berichts-
wesen
Kapazitt
Kosten
Risiken
Projekt-Strukturplan: Was ist zu tun?
Work breakdown structure
Hierarchische Aufgliederung
So fein wie ntig (meist drei Ebenen)
Projekt
Teilprojekt
Arbeitspaket
(evtl. noch: Vorgang/Aktivitt)
Durch hierarchische Nummerierung wiedergegeben
Schtzung und weitere Planung auf feiner Ebene
Kleine Teile leichter vergleich- und schtzbar
Wieder-zusammenrechnen ergibt Gesamtplan
PSP ist nach Aufgaben strukturiert, diese oft analog Produkt
Die Anordnung impliziert nicht
Abhngigkeiten
Reihenfolge der Bearbeitung
wie oft ein Arbeitspaket angepackt wird
Projekt-
definition
Organi-
sation
Arbeits-
pakete
Abhngigk.
Zeiten
Berichts-
wesen
Kapazitt
Kosten
Risiken
Projekt-
struktur
0000 MensaCard-Projekt
4100
MVC-Entwurf
4200
Corp. Design
4000
Bedienober-
flche
3000
Konzeption
2000
IST-Analyse
Projektstrukturplan
Beispiel
1100
ROI
1400
Budgetfhrung
1300
Verwaltung
1200
Controlling
1500
Berichte
7100
Kassierer-
schulung
7300
Day One
7200
Info-Material
6100
Barzahlungs-
Integration
6300
Aufwerter
6200
Kartenleser
5100
Implementierung
Busi. Logic
5400
ISO 9000
Zertifizierung
5300
Verknpfung
Nutzer-DB
5200
Verknpfung
Finanz-Sys.
5500
Sicherheits-
Zertif.
4100
MVC-Entwurf
4400
Experten-
evaluation
4300
Entwurfs-
Prototypen
4200
Corp. Design
4500
UI-Realisierung
3100
Stakeholder-
Workshops
3300
Architektur
3200
Mengengerst
2100
Kassen-
beobachtung
2400
Altdokumente
2300
Technische
Messungen
2200
Nutzer-
Interviews
3400
Feinentwurf
1000
Projekt-
management
6000
Umfeld
5000
Business
Layer
4000
Bedienober-
flche
3000
Konzeption
2000
IST-Analyse
7000
Roll-Out
Ausgewogenheit ist wichtig
Weitere Planungsebene
sinnvoll, doch selten im PSP
Projektorganisation: wie gehen wirs an?
Verantwortlichkeiten regeln
Projekt-
definition
Projekt-
struktur
Organi-
sation
Arbeits-
pakete
Abhngigk.
Zeiten
Berichts-
wesen
Kapazitt
Kosten
Risiken
Vorstand
Hauptabteilungsleiter
Abteilungsleiter
Gruppenleiter
Teamleiter
Disziplinarische
Fhrung
(Gehalt, Befrderung)
Matrixorganisation
Projektleiter
Teilprojektleiter
Fachliche
Fhrung
(Aufgaben, Ziele, Bericht)
Arbeits-
paket-
leiter
Zustndigkeiten: wer tut was?
AKV (Ausschnitt)
Rolle Projektleiter
Aufgaben
Plant Projekt
Kontrolliert Durchfhrung
Berichtet
Lenkungsausschuss
Kompetenzen
Kann MA aus Linie
einfordern
Kann MA Aufgaben
zuweisen
Verantwortung
Termin- u. Budgetkontrolle
Risikoberwachung
Projekt-
definition
Projekt-
struktur
Organi-
sation
Arbeits-
pakete
Abhngigk.
Zeiten
Berichts-
wesen
Kapazitt
Kosten
Risiken
4100
MVC-Entwurf
4200
Corp. Design
4000
Bedienober-
flche
3000
Konzeption
2000
IST-Analyse
Fr. YX
Hr. XY
Arbeitspakete: Was ist im einzelnen zu tun?
Projekt-
definition
Projekt-
struktur
Organi-
sation
Arbeits-
pakete
Abhngigk.
Zeiten
Berichts-
wesen
Kapazitt
Kosten
Risiken
AP-Beschreibung enthlt
Titel, Verantwortlicher
Bearbeitungszeitraum
Textuelle Aufgabenbeschreibung
Ergebnisse/Deliverables
Kundennutzen
Interne Plne (Meilensteine, Vorg.)
Besonderheiten
Nutzen von APs
Erfolgsmessung
Geht in Meilensteine ein
Aufwand auf APs gebucht
Arbeitspaket (AP)
Meist tiefste PSP-Ebene
Bezugspunkt fr Schtzung
Unterteilung in Vorgnge
mglich
Zweck
Klare, inhaltliche Aufgabe
Verantwortlicher AP-Leiter
Identifizierbarer Baustein
Form: unterschiedlich
Meist Formular fr Beschreibung
Offizieller Planungsbestandteil
Ablauf- und Terminplanung
Mit Abhngigkeiten planen
Abhngigkeiten (Netzplan)
1. Vorwrts rechnen
Start + Dauer
sptester aller eingehenden Pfeile
2. Frhesten Endtermin ermitteln: 9
3. Rckwrts rechnen (z.B. /7)
Sptester Beginn, um Termin zu halten?
4. Puffer = zeitlicher Spielraum
Es gibt verschiedene Pufferarten
Wichtig: Sptester - frhester Start
5. kritischer Pfad:
Aktivitten mit Puffer=0 (z.B. 6/6)
Versptung fhrt zu Projektverzug
Projekt-
definition
Projekt-
struktur
Organi-
sation
Arbeits-
pakete
Abhngigk.
Zeiten
Berichts-
wesen
Kapazitt
Kosten
Risiken
7100
Kassierer-
schulung
7300
Day One
7200
Info-Material
7000
Roll-Out
1
2
a: Bedienkonzept
Entwickeln (3)
3
Erarbeiten (3)
4
d: Infomaterial
Entwickeln (3)
e: Infomaterial
verteilen
(1)
5
c: Kassierer-
Schulung
halten
(2)
6
f: erster Tag
operativ
(1)
0
3
6
6
9/9
/8
/7
/6
/3
/4
/0
7 8
N-
Netzplne des MensaCard-Systems
Beispiel
1
2
a: System Grob-
Entwurf
b: Aufladegert entwickeln
3
c: Kassen-HW
4
d: SW-Entwurf
e: Kassen-SW
5
f: Kassen-Test
g: Abrechnungs-SW
h: Kartenlieferanten
whlen
7
j: System-Integration
k: Karten-Produktion
10
o: Demo-
Installation
8
l: Infokonzept
entwickeln
9
m: Aushnge entwerfen
p: Infostand vor Mensa
11
q: Personal-
Schulung
n: Kursdetails
planen
6
i: Testkarten
liefern
Puffer und Kritischen Pfad ermitteln
Noch ein Beispiel: Ausschnitt aus MensaCard
2
b: Aufladegert entwickeln (11)
3
c: Kassen-HW (10)
4
d: SW-Entwurf (7)
e: Kassen-SW (8)
5
f: Kassen-Test
(12)
g: Abrechnungs-SW (6)
1. Vorwrts rechnen
Start + Dauer
Je spteste Aktivitt
2. Frhester Endtermin
Hier Nr.5: t=27
3. Rckwrts rechnen
Sptester Beginn jeder
Aktiv. fr frhest.
Endtermin
4. Puffer (oft in Tabelle)
Sptester-frhester Start
5. kritischer Pfad
Hat Puffer=0
Jede Versptung
verzgert ganzes Projekt
Aktiv. FrStart SptStart Puffer
c 0 5 5
...
e 7 7 kritisch:0
g 7 21 14
8
4/
2/
7/
7
2
/5
/3
3
ProFLOW fr Netzplne
Es gibt mehrere Werkzeuge fr Netzplne
hier implementiert in ProFLOW von FG SE
Zum Zeichnen und zum Berechnen Tabelle der Zeiten u. Puffer
Aus der Bachelorarbeit von Michael Gross (2009) am FG SE
Meilensteine
Geplanter Zustand des Projekts zu best. Zeitpunkt
Geplanter Zeitpunkt
Geplanter Entwicklungsstand
Zustand von Dokumenten, Code, Prfungen
Jeder Aspekt mglich (z.B. technisch, organisatorisch)
Entscheidungs-relevante Bndelung von Teil-Zustnden
Erreichungskriterien klar definiert
Zweck
Klares, inhaltlich definiertes (komplexes) Kriterium fr Projektfortschritt
Bewusst und spezifisch gesetzt, um Klarheit zu gewinnen
Innerhalb Projekt: interner Meilenstein, fr interne Planung
Nach auen/zum Kunden: externer Meilenstein
An geplanten Meilenstein-Zeitpunkten wird entschieden
Ist Meilenstein erreicht?
d.h.: geplanter Entwicklungsstand gengt den definierten Kriterien
Dagegen reicht NICHT: der geplante Zeitpunkt ist erreicht
Und damit: Fortschritt wie geplant?
Sind nderungen im Plan ntig?
MS 3.2
Meilenstein-Symbol
in Plnen; dazu
Beschreibung ntig
Kapazitt
Kosten
Ablaufplan
Abfolgen festlegen
im Rahmen der
Abhngigkeiten (Netzplan)
Kapazitten bestimmen
mglichen Parallelittsgrad
Bearbeiter und Ressourcen
Konkrete Zeiten und Bearbeiter
zuordnen
Projekt-
definition
Projekt-
struktur
Organi-
sation
Arbeits-
pakete
Abhngigk.
Zeiten
Berichts-
wesen
Kapazitt
Kosten
Risiken
1
2
a: Bedienkonzept
Entwickeln (3)
3
Erarbeiten (3)
4
d: Infomaterial
Entwickeln (3)
5
c: Kassierer-
Schulung
halten
(2)
e: Infomaterial
verteilen
(1)
6
f: erster Tag
Operativ
(1)
0
3
6
6
9
/8
/7
/6
/3
/4
/0
7 8
Tage/Wochen/Monate
Infom.
verteilen
Erster
Tag
Kassierer-
schulung
Kassiererschulung
erarbeiten
Infomaterial
entwickeln
Bedienkonzept
entwickeln
Zeit
Konzept ok Material
bereit
eingefhrt
Kapazitt
Frau X
Herr Y
Kosten = PersKostenX*5+PersKostenY*9
Berichts- und Dokumentationsplan
Risikomanagement
Projekt-
definition
Projekt-
struktur
Organi-
sation
Arbeits-
pakete
Abhngigk.
Zeiten
Berichts-
wesen
Kapazitt
Kosten
Risiken
Welche Dokumente?
Fr wen?
Wozu?
Wie erzeugt?
Wie geprft?
Risikomanagement
Wieso betreiben?
Was tun?
Schtzen von Dauer und Aufwand
Kostenschtzungsprozess
Produktanforderungen
Identifikation der
Komponenten
Komponenten
Umfangsschtzung
Randbedingungen
Bewertung der
Komplexitt der
Aufgabenstellung
Komponenten
Umfang
Aufwandsschtzung
Solide Schtzung
Aufwand
Validation
Historische
Daten
Siehe auch: Houdek, Frank (2002): Vorlesung Management von Software-Projekten, Univ. Ulm
Anstze fr Aufwandsschtzung
Analogie-Methode (Basis: Umfangsschtzung)
Software-Umfang schtzen
Vergleich mit abgeschlossenen Projekten (Dreisatz ber Umfang)
Prozentsatz-Methode (Basis: Erfahrungswerte fr Phasen)
Basis: Bereits erbrachte Aufwnde fr Systemanalyse
Hochrechnen mit Systemanalyseanteil anderer Projekte
Beispiel:
Wir haben 6 PM Systemanalyse getrieben
Bei hnlichen Projekten macht Systemanalyse 20% aus
Wenn es hier wieder 20% sind, wird Gesamtaufwand also 30 PM sein
Expertenschtzungen (z.B. Delphi)
Parametrierte Verfahren (COCOMO, Function Points)
Ermittlung von Aufwand, Dauer und Personalstrke ber Formeln
Aufwandsschtzung mit COCOMO
von Barry Boehm auf Basis von 63 TRW-Projekten
Boehm hat Formeln ermittelt
Ausgangsbasis: Schtzung f. KLOC
Aufwand = a * KLOC
b
Dauer = c * Aufwand
d
Personal = Aufwand/Dauer
Parameter je nach Projektart
Organic Semidetached Embedded
a 2,4 3,0 3,6
b 1,05 1,12 1,2
c 2,5 2,5 2,5
d 0,38 0,35 0,32
( parametriertes Verfahren)
Beispielrechnungen
Kleine Projekte (z.B. im Studium)
3 KLOC, organic
7,6 PM Aufwand; 5,4 Monate; 1,4 Pers.
6 KLOC, organic
15,7 PM Aufwand; 7,1 Monate; 2,2 Pers.
Grere Projekte (Schtzung*100)
600 KLOC, organic
1983 PM Aufwand; 45 Monate; 44 Pers.
600 KLOC, semidetached
3878 PM Aufwand; 45 Monate; 86 Pers.
Hufig verwendet: Function Points
5 Kategorien
von Op.
Anzahlen Op.
schtzen
Komplexitt d.
Projekts
ermitteln
Gewichtungs-
vektor an-
wenden
Summieren,
Adaptieren:
Function
Points
Prinzip: In Std-Komponenten zerlegen; Analogieschtzung auf diesen
12
3
5
20
2
48
30
20
100
14
212
Details in der Originalverffentlichung: Albrecht, A.J. (1979): Measuring Application Development Productivity.
Proc. IBM Applic. Dev. Symposium, Monterey, CA, pp 83-92
* 14 Korrekturfaktoren = FP
(Menschen-) Fhrung
hier nur eine bersicht
Legitimation: Projektorganisation
Fachliche oder disziplinarische Fhrung?
Grundlage: Fhrungsqualitten
Dazu gehrt:
Aufgaben zuweisen
Durchfhrung kontrollieren, justieren
Ressourcen verteilen und zurckfordern
Projekt vorstellen, vertreten, reprsentieren
Informationsfluss regeln (schriftlich und in Besprechungen)
Kultur des Projekts prgen (Meetings, Zusammenarbeit,
Atmosphre)
Motivieren, Rgen, Konflikte bewltigen
Messen
Ziel: Fortschritt (Funktion u. Qualitt) feststellen
Einfaches Beispiel: was misst Lines of Code
Funktionsumfang?
Leistung der Programmierer?
Komplexitt des Programms?
oder einfach die Lnge des Programms?
Was kann man aus den Ergebnissen schlieen?
Auf welcher Skala liegen die Messungen?
Was tut man damit?
Generell: Vorsicht beim Interpretieren!
Gefhrlicher Ansatz: was knnen wir denn leicht messen?
Ganz anderes Prinzip: Goal-Question-Metric
Messen
Controlling und Meilenstein-Trendanalyse
Zeit
Plan vom
1. J anuar
J an Feb Mrz April Mai J uni J uli Aug
1. Februar
Soll=Ist-Linie
1. Mrz
1. April
1. Mai
1. J uni
1. J uli
Ausweichender
Meilenstein
Trend der Meilensteine erkennbar: rechtzeitig erfllt oder ausweichend?
Einsammeln von
Prfunterlagen
(nach Checkliste)
Inhaltliche Prfung
(unabhngig, einzeln)
Sitzung
- Aufnahme der Befunde
- Entscheidung
- Unterschrift, Protokoll
Bestanden
weiter arbeiten
Stop
Projekt beenden
Nchste Phase
nderung ntig,
dennoch
weiter arbeiten
Gate-Anmeldung
QGate-Schritt
Projektfortschritt
Entscheidungsoptionen
Fortschrittsmessung mit Quality Gates
Multiprojektmanagement und Qualitt
Vorlufig zurckgestellt
Nicht
nchste Phase beginnen
Nacharbeit
an alter Phase
(mit Feedback)
Hufige Planungsfehler
Unrealistische Plne und Wnsche
Unrealistische Wunschtermine
Schtzung u. Planung werden vom Management
berstimmt/ignoriert
Schtzungen ohne Erfahrungsbasis
Basieren auf unklaren/unzureichenden Daten
Plne nicht mit Betroffenen abgestimmt
Ist das eingeplante Personal dann wirklich verfgbar?
Wer plant noch mit diesen Ressourcen?
Auf Selbstverstndlichkeiten verlassen
Kosten nicht (ausreichend) geplant
Entwicklung nicht so weit vorhersehbar
Aufgaben des Projektleiter:
Planen, Steuern, Messen
Risikomanagement
Kapitel 7
Projektmanagement
Wieso IT-Risiken managen?
Ziel: Eisberge (Risiken)...
kennen (Wetterbericht fragen)
vermeiden (Umweg; Eisbrecher)
Folgen verringern (Aufprallwinkel)
auf Folgen vorbereiten (Rettungsboote)
oder: ... das riskieren wir! (nichts tun)
Viele IT-Risiken sind verborgen!
Vorteile durch Risikomanagement
Proaktiv entscheiden:
berraschungen und Probleme
rechtzeitig vermeiden
Schlechte Folgen mindern
Projektfortgang bestimmen ...
... statt von Problemen getrieben sein
IT-tanic
Menschen
Business
Auftraggeber-
risiken
Egerter, Heidi; Schneider, Kurt (2002): Risikomanagement fr SW-Projekte. SQM-Kongress. SQS
Begriffe
Risiko =
Def
potenzielles Problem (verbunden mit einem Verlust),
das eintreten kann, aber nicht sicher eintritt.
Ein Problem ist damit kein Risiko mehr (es ist ja schon eingetreten).
Eine Gefahr ist ein noch nicht erkanntes (unbewusstes) Risiko.
Risikomanagement (RM)
systematische Vorgehensweise, um
Projektrisiken (aller Art) frhzeitig zu erkennen und
whrend der Projektlaufzeit fortlaufend zu berwachen,
um mgliche Nachteile und Verluste zu verringern.
Risk Exposure (nach B. Boehm):
Risk Exposure =
Def
Probability (Outcome) * Loss (Outcome)
Was kann man mit Risiken tun?
Die fnf Kategorien mglicher Manahmen am Beispiel
Situationsbeispiel
Projektleiter in kleinem
Softwarehaus
braucht Treiber-Zulieferung
einer anderen Firma
um sein 3-Jahres-Projekt
abzuschlieen
Zwei Risiken:
WENN der Treiber nicht
rechtzeitig kommt,
DANN wird das gesamte Projekt
nicht fertig und die Bezahlung
verzgert sich
WENN der Treiber nicht
funktioniert DANN wird der Kunde
nicht abnehmen und die
Bezahlung verzgert sich
1. Verhindern
Lsung mit Standard-Treiber anstreben
2. Schaden verringern
hnlichen Treiber/Vorversion
bereithalten
3. Wahrscheinlichkeit verkleinern
Zulieferer auf Bedeutung des Termins
hinweisen/Vertrag
4. Vorbereiten auf Schaden
Kunden langsam vorbereiten,
dass er evtl. vorerst ohne
diese Funktion auskommen muss
5. Hinnehmen
Wird schon klappen;
Kunde merkt es auch nicht so schnell
WENN X DANN Y
Speziell: 1
2 Allg.: 3
4
(5)
Wieso muss Risikomanagement
diszipliniert und einheitlich ablaufen?
Hufiger Einwand:
Intuitiv machen wir das schon!
Aber intuitives Vorgehen reicht nicht!
versagt genau, wenn man es braucht:
unter Druck
Egerter, Heidi; Schneider, Kurt (2002): Risikomanagement fr SW-Projekte. SQM-Kongress. SQS
Risiken identifizieren
Wichtig
Checklisten helfen,
systematisch zu suchen
Insiderkenntnisse helfen,
spezifische Schwachstellen zu
finden
Breitensuche ist aufwndig,
im nchsten Zyklus kann man
abkrzen
RM im Projekt RM im Projekt
aufsetzen
g
RM-
Einweisung
Risiken
identifizieren
y
Risiken
analysieren
g
Manahmen
festlegen
Manahmen
durchfhren
Risikostatus
aktualisieren
CMU
Aus: CMU/SEI-93-TR-6
Wo lauern Risiken?
Im Netz liegen
Checklisten
Individuelle Erfahrung
bringt mehr
Risiko-Analyse und
Manahmenplanung
Worin besteht das Risiko?
Wie gro ist ein Risiko?
Risk Exposure =
Def
Wahrscheinlichkeit * Schaden
Danach priorisiert man Risiken
Allerdings nochmal Plausibilitt prfen, nicht nur Rechnen
Fr top-5 oder top-10 Risiken
berlegt man Manahmen
aufsetzen
g
RM-
Einweisung
Risiken
identifizieren
y
Risiken
analysieren
g
Manahmen
festlegen
Manahmen
durchfhren
Risikostatus
aktualisieren
WK
Schaden
H
M
G
G M H
1
2
3
Risk
Exposure
Risikostatus aktualisieren
Regelmig Status
der Manahmen abfragen
Vernderte WK und
Auswirkung eines Risikos
vermerken
Manahmen rejustieren
oder beenden
aufsetzen
g
RM-
Einweisung
Risiken
identifizieren
y
Risiken
analysieren
g
Manahmen
festlegen
Manahmen
durchfhren
Risikostatus
aktualisieren
risk
analysis
risk
analysis
plan
measures
plan
activities
implement
& control
measures
implement
& control
activities
risk
monitoring
risk
monitoring
risk
identification
risk
identification
Risiken aufschreiben
Praktisches Beispiel fr gutes Format
1. WENN der Kunde spt noch weitere Optionen verlangt,
DANN mssten wir den Entwurf noch deutlich modifizieren,
dadurch verzgert sich das Projektende und die Architektur verliert ihre Klarheit
(Wartbarkeit nimmt ab, geforderter Qualittsaspekt)
2. WENN die biometrischen Sensoren nicht fein genug auflsen
DANN kann unsere Software die Gesichter nicht unterscheiden und die
Hauptfunktion der Zugangssteuerung funktioniert nicht;
das Projekt ist vorerst gescheitert
3. WENN die Nachbarabteilung nicht
motiviert ist, mitzuarbeiten
DANN werden wir den engen Zeitplan nicht
halten und als die Verursacher dastehen
WK
Auswirkung
H
M
G
G M H
Abhilfemanahmen
Zu 1: Design-Pattern Strategy einsetzen, um flexibler zu bleiben
Zu 2: Vorabtest-Resultate vom Hersteller einfordern,
bei ersten Anzeichen weitere Manahmen planen
1
2
3
Tipps und Tricks
Zusammenfassung aus Erfahrung
Einstellung
Offenheit und Kultur sind wichtig
Risiken nicht Personen anlasten
Organisation
Nicht zu viele Risiken verfolgen, die aber richtig
Jedes Risiko bekommt einen Beauftragten
Risikomanagement in die Regelkommunikation einfgen
Regelmig kontrollieren, auch wenn nichts los ist
Disziplin und Einheitlichkeit sind besonders wichtig!
Darstellung des Nutzens
Bewltigte Risiken herausstellen
Worst Case nennen: zeigt, welcher Schaden verhindert wurde
SCRUM Agile Methode
Vorgehensmodelle und Prozesse
Prozessreifegrade
Kapitel 8
Prozesse
Kochrezepte
Sonderflle
Process Owner
Input
Ablauf
1
2
3
4
5
Tipps u. Erfahrungen
Wichtig!
Output, Einsatz
und Bewertung
http://www.hausfrauenseite.de/index.shtml?http://www.hausfrauenseite.de/rezepte/kuchen/lebkuchen/index.html (11.12.06)
Warum Vorgehensweise betonen?
Das Verfahren bestimmt das Ergebnis
Analog zum Rezept: Schnell oder langsam garen?
Zuverlssige Ablufe fhren zuverlssig zu guten Resultaten
Hngen nicht vom Zufall ab
Hngen nicht von der Tagesform ab
Sind verstndlich und wiederholbar beschrieben
Erfolg hngt nicht von Helden ab
Helden sind im SE eher nicht so populr
Wer ist schon ein Held?
Helden? Nein danke!
Ein einfaches Modell eines SW-Projekts
Software-
Integration
Integrationstest
Software-
Anforderungen
Software-
Design/Arch.
Software-Implementierung
Software-Modultest
Testflle
Integrationstest
Testflle
Modultest
Wasserfallmodell nach Royce
Rcksprnge
Die unbekannte Seite des
Wasserfallmodells nach Royce
Vereinfachte Version fr diese Vorlesung
vgl. Folie 40
Diese Dokumentarten
muss man kennen
Wie die Aktivitten
treten sie in verschiedenen
Formen/Namen auf
Grundbezeichnungen
(rechts) sind ein guter
Anhaltspunkt
... wir kommen darauf zurck!
Lasten-
heft
Pflichten-
heft
Grob-
entwurf
Fein-
entwurf
Code
Technische
Doku-
mentation
Roll-Out-
Plan
Test-
plne
Benutzer-
Handbuch
Software = ... and documentation
Betrieb
Integra-
tion
Codie-
rung
Entwurf
Analyse
(Anford.)
Spiralmodell von Barry Boehm
Iteratives, risiko-getriebenes Vorgehensmodell
Risikoanalyse
Prototyp
Alternativen bewerten
Risiken identifizieren,
Ausrumen (=lsen)
Weiterentwicklung d. Produkts
(hier mit Wasserfall oder sonstwie)
Folgeplanung
Orientierung:
Ziele,
Alternativen,
Restriktionen erkunden
Nach auen:
Fortschritt
Ntzlichkeit
Entlang der Spirale:
Zeit, Ablauf
Iteration: Risikominderung
Eher Quadranten
als Achsen
Alternativen,
Restriktionen
herausarbeiten
Das V-Modell 97
Mutter aller deutschen Vorgehensmodelle
Submodell (!)
Qualittssicherung
im
V-Modell
Dokumente
Aktivitten
und Teilprozesse
Das V-Modell
Submodell
Systemerstellung
Verwaltet von IABG, Mnchen
www.v-modell.iabg.de
Version 1997
Neue Version
V-Modell XT seit 2005
am selben Ort verfgbar
Nicht so weit verbreitet
Nicht so plakativ
Software-Projekte
viele, spte
nderungen
Softwareprojekte unter Druck
Motivation
Qualitt
und
Wartbarkeit
schnellere
Releasezyklen
krzere
time-to-market
Wachsender Zeitdruck
Qualitt ist wichtig
Zwischenlieferungen erwartet
Anforderungen vage oder unklar
Viele spte nderungen
Das Versprechen: Agile Prinzipien (1)
Hchste Prioritt: Kundenzufriedenheit
durch frhe und hufige Auslieferung laufender Software
Einfachheit ist wichtigstes Konstruktionsprinzip
Mglichst wenig unntige Arbeit, nicht auf Vorrat arbeiten
Auch spte nderungen werden willkommen geheien
nderungen bedeuten Verbesserungen fr den Kunden
Das Versprechen: Agile Prinzipien (2)
Manager und Entwickler arbeiten zusammen - jeden Tag
Projekte werden um motivierte Mitarbeiter herum aufgebaut
mglichst ideale Umgebung, Vertrauen in Entwickler
Direkte Mensch-zu-Mensch Kommunikation
Effektiv und effizient Informationen austauschen
Regelmig eigene Leistung kontrollieren und verbessern
Feedback als Grundprinzip
Konspirativ: Agile Alliance
Prinzip
Was ist agil?
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck, Alistair Cockburn
Martin Fowler, Jim Highsmith, Ron Jeffries
Ken Schwaber und 11 andere
www.agilemanifesto.org
Was ist agil? Struktur agiler Methoden
Prinzip
Grundwerte
change over plan
Prinzipien
Praktiken
(Umsetzung,
sehr bekannt)
Hchste Prioritt: Kundenzufriedenheit
frhe und hufig laufende Software
Einfachheit
unntige Arbeit vermeiden
Auch spte nderungen willkommen
bedeuten Verbesserungen fr den Kunden
...
Direkte Mensch-zu-Mensch Kommunikation
Beste Mglichkeit zum Informationsaustausch
Regelmige berprfung und Verbesserung
der eigenen Effektivitt
Feedback auf mehreren Ebenen
SCRUM
Master
SCRUM
Room
SCRUM team 7+/-2
Product
Backlog
(priorisiert)
Product
Owner
SPRINT: 30 days
Andere
Daily SCRUM
15 min.
SPRINT
Backlog
Increment
SCRUM erleben
Kurt Schneider, Univ. Hannover
Ebenen in SCRUM
Arbeitstag
oder auch
Projekt-Ziele: Projekt Backlog
Projekt aus
SPRINTS
SPRINT
mit Backlog und Goal
Koord.
mehrerer
Teams
mehrere SCRUM-Teams sprinten parallel. Master-SCRUMs
Arbeitstag
Ein Arbeitstag:
SCRUM zu SCRUM
Dailiy SCRUM Nach-
Build (15 min.) bespr.
SPRINT im
30 SCRUM-Takt
Planung
SPRINT
Review 3h
SPRINT erzeugt
ein Produkt-Inkrement
Kurt Schneider, Univ. Hannover
Sprint-Fortschritt schtzen
ein typischer Verlauf fr neues SCRUM-Team
Nach Schwaber, Ken; Beedle, Mike (2002): Agile Software Development with Scrum. Prentice Hall.
Es geht
anfangs
langsam los.
Immer mehr
taucht auf.
Gemeinsame
Anstrengung
nach dem
Wochenende
Frustration;
mit
SCRUM-
Master wird
der Umfang
verringert
Vorgehensmodelle und Prozesse
Agile Methoden
Prozessreifegrade
Kapitel 8
Prozesse
CMM - Capability Maturity Model
Entwickelt seit 1987
SEI (Software Engineering Institute)
Carnegie Mellon University (CMU)
Im Auftrag des DoD (US Verteidigungsministerium)
Ziel: Bewertung von Softwarelieferanten ber
Referenzmodell und dabei
Nicht Prozess vorschreiben,
Sondern Reife eines (beliebigen) Prozesses
(Hufiges Missverstndnis:
CMM schreibt NICHT das Wasserfallmodell vor!)
Vorgehen: Einordnung in 5-stufige Skala (CMM-Level)
Vergleichbar
Verstndlich fr viele Stakeholder (Management, Entwickler)
Fortschritt sichtbar
Qualitt von Entwicklungsprozessen
Was ist und wie misst man Prozessreife?
Das Capability Maturity Model (CMM)
1
initial
Chaotischer Zustand;
Erfolg hngt an
einzelnen Helden;
Feuerwehreinstze sind an der Tagesordnung
2
repeatable
Prozesse auf Projektebene
beschrieben. Erfolg hngt noch an
Individuen, aber bessere Untersttzung
3
defined
Personen knnen sich auf eingespielte Prozesse
sttzen; integrierte Prozesse projektbergreifend
Probleme werden vorhergesehen und vermieden
4
managed
Prozesse stabil und
quantitativ im Griff
echtes Teamwork
5
optimizing
vorausschauende
Steuerung und
Innovation
Requirements Management
Projektplanung
Projektverfolgung und -berblick
Lieferantenmanagement
Qualittssicherung
Configuration Management
S
i
c
h
e
r
h
e
i
t
R
i
s
i
k
o
Begriffe im CMM
Jede KPA (d.h.: jedes Thema) hat
Goals
Stets diese fnf
Common Features
Commitment to perform
Ability to perform
Activities performed
Measurement and Analysis
Verifying Implementation
Key Practices
Verfeinern Common Features
Sind KPA-spezifisch
Die Auswirkungen reiferer Prozesse
Carnegie Mellon University, Software Engineering Institute (1995): The Capability Maturity Model, Addison Wesley
Projektplan (klassisch)
nach IEEE Std 729-1983
Legt 6w fest
Was getan wird
warum
fr wieviel Geld
von wem
wann
womit (Entwicklungs- und Management-Hilfsmittel und -Techniken)
Zu klren
Zustndigkeiten des Projektleiters
Erkennbar ntige Manahmen
Erwartete Resultate
detaillierter Lieferumfang: Programme, Dokumentation, Leistungen
fr Dokum.: Inhaltsverzeichnis, Leserkreis, Detaillierung
Idealerweise mit Abnahmekriterien, auch fr Dokumente
Wieviel Planung braucht ein Projekt?
nach Barry Boehm
feingranulare Vertrge
++klareArbeitsgrundlage
+finanzielle Sicherheit
- - enormaufwndig
- - nderungen auch fr
AG schwer durchsetzbar
nach Barry Boehm
ad hoc
+wenig Planungsaufwand
+individuelle Freiheit
- - Ergebnis unvorhersehbar
- - abhngig von Helden
feingranulare
Vertrge
nach Barry Boehm
Meilenstein- u. Plangetrieben
+langfristige Vorhersagen
+gute Zustandskontrolle
- - nderungen aufwndig
- - unrealistischeAnnahmen
schwer zu eliminieren
feingranulare
Vertrge ad hoc
nach Barry Boehm
Meilenstein- u. Risikogesteuert
++Risiken aktiv ausgerumt
+Teilergebnisse frh
- kaum langfristig planbar
- relativ aufwndig
feingranulare
Vertrge ad hoc
Meilenstein- u.
Plangetrieben
Planungshorizont nach Ma
nach Barry Boehm
Agile Methoden
feingranulare
Vertrge ad hoc
Meilenstein- u.
Plangetrieben
Meilenstein- u.
Risikogesteuert
eXtreme
Programming
Agiles Beispiel: SCRUM
+mittelfristig geplant
+reagiert schnell
- hngt an MA-Qualifikation
- Endprodukt nicht spezifiziert
Daily SCRUM
+ SPRINT
Prinzip und Denkweise
von Agilen Methoden
Bisheriger Ansatz Agiler Ansatz
Mitwirkung des
Kunden
unwahrscheinlich kritischer
Erfolgsfaktor
Etwas Ntzliches
wird geliefert
erst nach einiger
(lngerer) Zeit
mindestens alle
sechs Wochen
Das Richtige
entwickeln durch
langes Spezifizieren,
Vorausdenken
Kern entwickeln,
zeigen, verbessern
Ntige Disziplin formal, wenig informell, viel
nderungen erzeugen Widerstand werden erwartet und
toleriert
Kommunikation ber Dokumente zwischen Menschen
Vorsorge fr
nderungen
durch Versuch der
Vorausplanung
durch flexibel
Bleiben
nach Frhauf,
Conquest 2001
Inkrementelles Entwicklungsmodell
Exkurs: Alternativen zu V-Modell?
Versetzte Entwicklungsstrnge
Jedes Inkrement fr sich ist vollwertig einsetzbar
Von vornherein als Ausbaustufen vorgesehen (Fkt-Block)
Relativ unabhngig whrend der Entwicklung
Anstze des Prototyping
Alle fhren zu iterativem Arbeiten
Explorativ
Ziel: Anforderungen feststellen
Alternativen vorstellen, Reaktionen sichern
Experimentell
Ziel: Technische Alternativen untersuchen
Machbarkeit und Umsetzung ausprobieren
Evolutionr
Ziel: Passendes System trotz genderter Anforderungen
Laufendes System immer wieder an genderte Anforderungen
und Rahmenbedingungen anpassen
An-
Ford.
Technik
Technik
An-
Ford.

SWT WS1213 Folien v21

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SWT WS1213 Folien v21

Hochgeladen von

Copyright:

Verfügbare Formate

Grundlagen der

ph.setEntry(3, "May", "089/4567");

ph.add(new TreeNode("May", "089/4567"));

Wir wissen es nicht! Und wollen es nicht wissen!

Kurt Schneider Leibniz Universitt Hannover SWT-WS0910 - 115 SWT 2012-13

ph.add(new TreeNode(Lahm, 089/4567));

Siehe: Starke, G. (2002): Effektive Software-Architekturen. Carl Hanser Verlag

for (ListIterator it=allObservers.listIterator();

[R82] Das Programm soll bis zum Sommersemester

[R89] Alle Studierenden der Fakultt sollen dann alle

[R90] Eine Zugriffsrate von 200 Personen pro Tag, bis zu

Das könnte Ihnen auch gefallen