Agile Geschäftsprozeßanalyse OOA/D am Beispiel einer Seminarverwaltung
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Agile Geschäftsprozeßanalyse OOA/D am Beispiel einer Seminarverwaltung

on

  • 3,615 views

In einer Vielzahl von GFU-Kursen wurde bereits die UML-Notation vermittelt. Von praktischem Interesse ist jedoch die Umsetzung im Rahmen einer GPA/OOA/OOD, um eine Umsetzung in modernen ...

In einer Vielzahl von GFU-Kursen wurde bereits die UML-Notation vermittelt. Von praktischem Interesse ist jedoch die Umsetzung im Rahmen einer GPA/OOA/OOD, um eine Umsetzung in modernen objektorientierten Programmiersprachen zu ermöglichen.

Im Rahmen dieses Vortrages wird die Anwendung der UML am Fallbeispiel einer Software zur Seminarverwaltung unter Verwendung von agilen Methoden beschrieben. Im Fokus steht dabei, den objektorientierten Ansatz der Softwareentwicklung zu verdeutlichen. Ausserdem soll die spezielle Sichtweise jedes UML-Diagramms auf die zu entwickelnde Software sowie die Zusammenhänge der Diagramme betont werden. Behandelt werden soll:

GPA/OOA mit Use Cases
GPA/OOA mit Aktivitätsdiagrammen
OOA Objekt- und Klassendiagramme
OOD Klassendiagramme
OOD Zustandsdiagramme
OOD Sequenzdiagramme

Damit in Zusammenhang werden agile Konzepte vorgestellt:
der ideale Kunde & der ideale Programmierer
Methoden der Entwicklung: Scrum, TDD, FDD
OOA Anwendungsfälle mit Story Cards
OOA Risk/Value Priorisierung und Planning Poker
OOA/D Ermittlung der Klassen mittels CRC-Kartenmethode
OOP Pair-Programming
OOP Continuous Integration

Statistics

Views

Total Views
3,615
Views on SlideShare
3,615
Embed Views
0

Actions

Likes
1
Downloads
29
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Agile Geschäftsprozeßanalyse OOA/D am Beispiel einer Seminarverwaltung Document Transcript

  • 1. Vortrag am Dienstag, 10. März 2009 Thema Agile Geschäftsprozeßanalyse (GPA), objektorientierte Analyse & Design (OOA/D) am Beispiel einer Seminarverwaltung Referent Dr. Frank Dopatka, GFU Cyrus AG Inhalt • Das Fallbeispiel der GFU („Ist-Zustand bis 2008“) • GPA/OOA: Story Cards, Use Cases, Aktivitäten, Objekte & Klassen, CRC-Karten, Risk/Value-Priorisierung, Planning Poker • OOD: Klassen-, Zustands- & Sequenz-Diagramme • OOP: Test Driven Development, Feature Driven Development, Scrum, Pair-Programming, Continous Integration • Der ideale Kunde & der ideale Programmierer Ziel ist eine Übersicht über alle Notationen/Verfahren & deren Verzahnung zu erkennen!
  • 2. Das Fallbeispiel Was existierte bislang? _____INHALT_____ Fallbeispiel Die GFU Cyrus AG verwendete GPA / OOA - Story Cards - Use Cases von 1988 bis Ende 2008 - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker ein in Cobol selbst geschriebenes Programm zur OOD • Verwaltung der Kunden, - Klassen - Zustände - Sequenzen • deren Ansprechpartner und zur OOP • Dokumentation der Kommunikation von - TDD & FDD - Scrum GFU-Mitarbeitern mit den Kunden (Vorgänge). - Pair Programming - Cont. Integration • Auch zur Fakturierung verwendet. Der ideale Kunde & Programmierer • Über eine Kalenderfunktion wurden die Seminare, Anmeldungen von Teilnehmern, Hotel- & Parkplatzbelegung verwaltet. Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 4
  • 3. Was existierte bislang? _____INHALT_____ Fallbeispiel • Angebote: GPA / OOA in den letzten Jahren in MS Word 97 erstellt - Story Cards - Use Cases - Aktivitäten • Zusätzlich: - Objekte & Klassen - CRC-Karten 8 Jahre altes Programm zur Seminar- - Risk/Value+Poker verwaltung, das in VB6 geschrieben wurde OOD - Klassen  Abgleich mit den Internet-Daten - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 5 So sah die Kundenverwaltung & Fakturierung aus... _____INHALT_____ Fallbeispiel GPA / OOA - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 6
  • 4. So sah die Seminarverwaltung aus... _____INHALT_____ Fallbeispiel GPA / OOA - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 7 Was soll verbessert werden? _____INHALT_____ Fallbeispiel • Das Cobol-Programm berechnet ab 2009 die GPA / OOA Kalenderwochen falsch, eine Anpassung ist - Story Cards - Use Cases „schwierig“ im Quellcode durchzuführen. - Aktivitäten - Objekte & Klassen • Die Fakturierung soll automatisiert werden. - CRC-Karten - Risk/Value+Poker • Da keine relat. DB-Struktur verwendet wurde, OOD - Klassen waren Statistiken über Kurserfolge schwierig, - Zustände - Sequenzen z.B. Gewinn aus Schulungen der Kategorie „Java“ OOP ermitteln. - TDD & FDD - Scrum • Es sind im Cobol-Programm alte Funktionen - Pair Programming - Cont. Integration vorhanden, die nicht mehr verwendet werden, u.a. Der ideale Kunde & - Verwaltung von Lizenznummern und Programmierer - Verwaltung von Update-Abos ...aus Zeiten, in denen bei der GFU noch Cobol-Compiler verkauft wurden. Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 8
  • 5. Was wird im Vortrag behandelt? _____INHALT_____ Fallbeispiel Im Folgenden wird exemplarisch gezeigt, wie man mit GPA / OOA • einer Geschäftsprozeß-Analyse (GPA) - Story Cards - Use Cases • einer Objektorientierten Alalyse (OOA) und - Aktivitäten - Objekte & Klassen • einem Objektorientierten Design (OOD) - CRC-Karten - Risk/Value+Poker einen Lösungsansatz für die zu erstellende Software OOD - Klassen ermitteln kann. - Zustände - Sequenzen Im Fokus steht dabei OOP - TDD & FDD • der Zusammenhang der verschiedenen - Scrum - Pair Programming UML-Diagramme, deren Blickwinkel sowie - Cont. Integration • die Anwendung agiler Methoden bei der Der ideale Kunde & Programmierer Softwareentwicklung. Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 9 GPA & Story Cards
  • 6. Was macht man in der GPA & OOA? _____INHALT_____ Fallbeispiel • In der Analyse geht es darum, die Anforderungen GPA / OOA zu erfassen: - Story Cards - Use Cases Fakten sammeln, darstellen, prüfen - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker  Objektorientierte Analysemodell: OOD - fachliche Beschreibung mit OO-Konzepten - Klassen - Zustände - hebt das Wesentliche hervor und lässt - Sequenzen Unwichtiges weg OOP - TDD & FDD - Scrum - Pair Programming • Bezug zur Informationstechnik ist - Cont. Integration unerwünscht! Der ideale Kunde & Programmierer • OOA-Modell sollte statische & dynamische Aspekte enthalten ( Datenstrukturen & Abläufe) Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 11 Was sind Story Cards? _____INHALT_____ Fallbeispiel • User Story („Benutzergeschichte“): GPA / OOA - eine in Alltagssprache formulierte Software- - Story Cards - Use Cases Anforderung - Aktivitäten - Objekte & Klassen - bewusst kurz gehalten: nicht mehr als zwei Sätze - CRC-Karten - Risk/Value+Poker OOD • Jede User Story wird auf eine Story Card - Klassen - Zustände geschrieben. Autor: Kunde bzw. User - Sequenzen OOP - TDD & FDD • Die Story Card ist die wichtigste Methode, um ein - Scrum - Pair Programming agiles Projekt zu steuern! - Cont. Integration Der ideale Kunde & Programmierer • Aus den Story Cards entwickeln sich in kooperativer Zusammenarbeit mit dem Kunden die Use Cases  Workshops Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 12
  • 7. Inhalt einer Story Card _____INHALT_____ Fallbeispiel  Datum, fortlaufende Nummer GPA / OOA  Nummer der übergeordneten Story Card - Story Cards - Use Cases  Aktivität: neu / Fehler beheben / Funktion erweitern - Aktivitäten - Objekte & Klassen  Funktion umgesetzt - CRC-Karten - Risk/Value+Poker OOD  Priorität (Kunde/Programmierer) - Klassen - Zustände  Risiko & Aufwandschätzung - Sequenzen OOP - TDD & FDD  kurze, präzise Beschreibung - Scrum - Pair Programming  Notizen - Cont. Integration Der ideale Kunde & Programmierer  aktueller Fortschritt: Datum, Status, Aufgabe, Kommentar Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 13 Exemplarische Story Card: „Seminarverwaltung“ _____INHALT_____ Fallbeispiel GPA / OOA - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer
  • 8. Use Cases Was genau sind Use Cases (Anwendungsfälle)? _____INHALT_____ Fallbeispiel • Interaktion zwischen Akteuren und dem GPA / OOA betrachteten System: - Story Cards - Use Cases Dabei soll ein fachliches Ziel erreicht werden! - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker • Grafisches UML Use Case: OOD Identifikation der Funktion & der beteiligten - Klassen - Zustände Akteure im Vordergrund - Sequenzen OOP - TDD & FDD • Informationsgehalt eines graphischen Use Cases - Scrum - Pair Programming ist gering! - Cont. Integration  Use Case Schablone Der ideale Kunde & Programmierer  Verlauf textuell beschreiben  Bezug zum Geschäftsprozeß  Basis kann Story Card sein! Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 16
  • 9. Perspektiven _____INHALT_____ Fallbeispiel Use Cases können (wie auch alle anderen UML- GPA / OOA Diagramme) in verschiedenen Abstraktions-Ebenen - Story Cards - Use Cases erstellt werden: - Aktivitäten Wolke - Objekte & Klassen - CRC-Karten Manager-View - Risk/Value+Poker OOD - Klassen - Zustände Drachen - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming Meeres-Spiegel - Cont. Integration User-View Der ideale Kunde & Programmierer Muschel Fisch Entwickler-View Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 17 Exemplarischer grafischer Use Case der Seminarverwaltung (Manager-View) _____INHALT_____ Fallbeispiel GPA / OOA - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 18
  • 10. Etwas detailliertere Darstellung des Use Cases „Seminare verwalten“ _____INHALT_____ Fallbeispiel GPA / OOA - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 19 Exemplarischer textueller Use Case der Seminarverwaltung _____INHALT_____ Buchen eines Seminars Fallbeispiel Ziel: GPA / OOA - Story Cards Anmeldebestätigung an den Kunden geschickt. - Use Cases Vorbedingung: - Aktivitäten --- - Objekte & Klassen - CRC-Karten Nachbedingung Erfolg: - Risk/Value+Poker Kunde ist angemeldet. OOD Nachbedingung Fehlschlag: - Klassen Mitteilung an Kunden, dass Veranstaltung ausgebucht ist, ausfällt oder nicht existiert. - Zustände Akteure: - Sequenzen Kunde, GFU-MA OOP Auslösendes Ereignis: - TDD & FDD Anmeldung des Kunden liegt vor. - Scrum - Pair Programming Beschreibung: - Cont. Integration 1. Kundendaten abrufen 2. Seminar prüfen Der ideale Kunde & Programmierer 3. Anmeldebestätigung erstellen Erweiterung: 1a. Kundendaten aktualisieren 1b. Wenn Kunde MA einer Firma ist, Firmendaten erfassen bzw. wenn vorhanden, dann abrufen und aktualisieren 1c. Zahlungsmoral prüfen Alternativen: 1a. Neukunden erfassen, wenn Kunde noch nicht existiert 1b. Auf alternative Veranstaltungen hinweisen, wenn ausgebucht 1c. Mitteilung „Falsche Veranstaltung“, falls Veranstaltung nicht existiert und auch nichts ähnliches
  • 11. Aktivitäten, Szenarien & Geschäftsabläufe Wozu Aktivitäts-Diagramme? _____INHALT_____ Fallbeispiel • Geben die Struktur eines Prozesses als Fluss GPA / OOA dynamisch wider - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen • Heben den Steuerungsfluss von Objekten im - CRC-Karten - Risk/Value+Poker Geschäftsprozeß untereinander hervor OOD - Klassen - Zustände • Werden typischerweise aufgestellt, wenn die Use - Sequenzen Cases fertig sind OOP - TDD & FDD Ziel: grundsätzliche Abläufe darstellen - Scrum - Pair Programming - Cont. Integration • Überschneidung der Ansicht zu einem Der ideale Kunde & Programmierer textuellen Use Case ist groß  Alternativ dazu anwenden?! Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 22
  • 12. Was ist ein Szenario? _____INHALT_____ Fallbeispiel Eine spezifische Sequenz von Aktionen, die das GPA / OOA Verhalten des Systems unter bestimmten Bedingungen - Story Cards - Use Cases beschreibt, z.B.: - Aktivitäten - Objekte & Klassen • Login - CRC-Karten - Risk/Value+Poker • Bestellvorgang OOD • Rechnungsstellung - Klassen - Zustände • Auszahlung von Geld - Sequenzen • Angebotserstellung OOP - TDD & FDD • … - Scrum - Pair Programming - Cont. Integration Im Allgemeinen: Der ideale Kunde & Einen Geschäftsprozess des Unternehmens! Programmierer Bei der Entwicklung werden alle wichtigen Szenarien in Aktivitäts-Diagrammen fest gehalten. Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 23 Aktivitäts-Diagramm der Seminarverwaltung: erfolgreiche Anmeldung _____INHALT_____ Fallbeispiel Kunde 1 Seminarverwaltung GPA / OOA - Story Cards - Use Cases Suchbegriff „Java Einsteiger“ - Aktivitäten - Objekte & Klassen in die GFU-Seite eingegeben - CRC-Karten - Risk/Value+Poker Liste der Seminare OOD zurückgeben - Klassen - Zustände - Sequenzen Seminar auswählen OOP - TDD & FDD :Seminar - Scrum pers. Daten eingeben [status: buchend] - Pair Programming - Cont. Integration [AnzTN=MaxTN-1] Buchung abschicken Der ideale Kunde & Programmierer Daten prüfen und ggf. abgleichen :Seminar [status: ausgebucht] [AnzTN=MaxTN] Dr. rer. nat. Frank Dopatka Bestätigung der Buchung FrankDopatka@web.de senden Folie 24
  • 13. Aktivitäts-Diagramm der Seminarverwaltung: fehlerhafte Anmeldung _____INHALT_____ Fallbeispiel GPA / OOA - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 25 Objekte & Klassen in der Analyse
  • 14. Warum noch Objekt-Diagramme? _____INHALT_____ Fallbeispiel • Objekt-Diagramme besitzen die gleiche Notation GPA / OOA wie Klassen-Diagramme, stellen aber konkrete - Story Cards - Use Cases Beispiele/Instanzen dar: - Aktivitäten - Objekte & Klassen - derFrank: Dopatka, Frank, Schmiedeweg,... - CRC-Karten - Risk/Value+Poker  Kunde: Name, Vorname, Strasse,... OOD - Klassen - Zustände • In der Praxis als erster Schritt der Analyse - Sequenzen leicht verständlich, da anwendungsnah OOP - TDD & FDD - Scrum - Pair Programming • Klassen: Abstraktionen der Objekte - Cont. Integration  auf höherem Niveau! Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 27 Warum Klassen-Diagramme in der Analyse? _____INHALT_____ Fallbeispiel • Klassen-Diagramme existieren vereinfacht in einer GPA / OOA Analyse-Form: - Story Cards - Use Cases Identifikation der Klassen und deren - Aktivitäten - Objekte & Klassen Beziehung zueinander im Vordergrund! - CRC-Karten - Risk/Value+Poker OOD • Klassen und deren Beziehungen orientieren sich - Klassen - Zustände am Geschäftsprozeß  nicht plötzlich „falsch“ - Sequenzen OOP - TDD & FDD • Beziehungen: textuell beschrieben - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 28
  • 15. Exemplarisches Objekt-Diagramm: ein Seminar _____INHALT_____ Fallbeispiel GPA / OOA - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 29 Exemplarisches Objekt-Diagramm: Bezug eines Seminars zu anderen Objekten _____INHALT_____ Fallbeispiel GPA / OOA - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 30
  • 16. Ausschnitt aus einem Klassen-Diagramm (OOA) der Seminarverwaltung _____INHALT_____ Fallbeispiel GPA / OOA - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 31 CRC-Karten
  • 17. Wie kommt man an die Objekte & Klassen? _____INHALT_____ Fallbeispiel • Durch Erfahrung! GPA / OOA - Story Cards - Use Cases • Indem Sie in Gesprächen und Beschreibungen - Aktivitäten - Objekte & Klassen achten auf: - CRC-Karten - Risk/Value+Poker - nicht-triviale Hauptwörter (Raum, Kunde,...) OOD  Klassen - Klassen - Zustände - Sequenzen - triviale Hauptwörter, die durch einzelne OOP Zeichenketten, Zahlen oder wahr/falsch - TDD & FDD - Scrum darstellbar sind (Name, Mail-Adresse,...) - Pair Programming - Cont. Integration  Attribute Der ideale Kunde & - Verben (anlegen, buchen, suchen, stornieren,...) Programmierer  Methoden - Ausdrücke wie „ist ein“ bzw. „besteht aus“  Vererbung bzw. Aggregation oder Komposition Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 33 Was ist eine CRC-Karte? _____INHALT_____ Fallbeispiel • Prinzip einer Class-Responsibility-Collaboration- GPA / OOA Karte: - Story Cards - Use Cases für jede Klasse eine Karteikarte erstellen & - Aktivitäten - Objekte & Klassen auf dieser deren Eigenschaften zu notieren - CRC-Karten - Risk/Value+Poker OOD • Eine solche Karte besteht aus folgenden Bereichen: - Klassen - Zustände - Name der Klasse - Sequenzen - Aufgaben der Klasse OOP - TDD & FDD - Klassen, mit denen die beschriebene Klasse - Scrum - Pair Programming zusammenarbeitet - Cont. Integration - Rückseite: wichtigste Attribute und Methoden Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 34
  • 18. Vorteile der CRC-Karten _____INHALT_____ Fallbeispiel • Einfache Handhabung: GPA / OOA Problemlos Informationen hinzufügen oder streichen - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen • Unabhängig von Programmiersprachen & Tools - CRC-Karten - Risk/Value+Poker OOD • begrenzte Platz - Klassen - Zustände  auf die wesentlichen Aufgaben einer Klasse - Sequenzen konzentrieren OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 35 Vorgehensweise _____INHALT_____ Fallbeispiel • Mit dem Kunden typische Anwendungsfälle GPA / OOA definieren  Use Cases - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen • Anwendungsfälle nacheinander durchspielen - CRC-Karten - Risk/Value+Poker  Aktivitäten OOD - Klassen - Zustände • Auf den CRC-Karten neue Aufgaben und - Sequenzen Partnerklassen festhalten OOP - TDD & FDD - Scrum - Pair Programming  Mit der Zeit ergibt sich ein vollständiges Bild. - Cont. Integration Der ideale Kunde & Programmierer • Wichtig: - Untersuchung aller typischen Anwendungsfälle & Szenarien - Festhalten aller Details Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 36
  • 19. Beispielhafte CRC-Karte „Seminar“  Klasse „Seminar“ _____INHALT_____ Fallbeispiel Seminar GPA / OOA - Story Cards Aufgaben: - Use Cases Erstellen und verwalten von Seminaren und deren Inhalten. Man soll Seminare suchen - Aktivitäten können und im Internet veröffentlichen. Man kann sich anmelden, solange die max. TN-Tahl - Objekte & Klassen - CRC-Karten nicht erreicht ist. Abmelden geht auch jederzeit. Die GFU kann notfalls ein Seminar auch - Risk/Value+Poker stornieren, wenn keine Anmeldung vorliegt oder der geplante Dozent krank ist und kein Ersatz gefunden werden konnte. OOD - Klassen - Zustände - Sequenzen Partnerklassen: Seminarverwaltung, Rechnung, Termin -> (Raum, Dozent, Anmeldungen -> (Teilnehmer)) OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Risk-Value Priorisierung & Planning Poker
  • 20. Was wird wie priorisiert & welche Konsequenzen ergeben sich? _____INHALT_____ Fallbeispiel Bereits bei den Story Cards wurden die Begriffe GPA / OOA • Priorität, - Story Cards - Use Cases • Risiko und - Aktivitäten - Objekte & Klassen • Aufwandschätzung - CRC-Karten - Risk/Value+Poker für jede Funktionalität (Use Case) erwähnt. OOD - Klassen - Zustände - Sequenzen Jetzt wissen alle Beteiligten bereits mehr über die OOP Funktionen & Abläufe. - TDD & FDD - Scrum - Pair Programming - Cont. Integration  So langsam können Sie folgende Fragen Der ideale Kunde & beantworten... Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 39 Was wird wie priorisiert & welche Konsequenzen ergeben sich? _____INHALT_____ Fallbeispiel • Wie wichtig ist unserem Kunden diese GPA / OOA Funktionalität?  0..10 Punkte K - Story Cards - Use Cases • Wie wichtig sehen die Programmierer die - Aktivitäten - Objekte & Klassen Integration der Funktionalität im Kontext der - CRC-Karten - Risk/Value+Poker Anwendung?*  0..10 Punkte P OOD - Klassen • Wie sehen die Programmierer die Schwierigkeit - Zustände - Sequenzen der technischen Umsetzung (Risiko) der OOP Funktion?*  0..10 Punkte S - TDD & FDD - Scrum • Wie (zeit-)aufwendig sehen die Programmierer - Pair Programming - Cont. Integration die Umsetzung?* Der ideale Kunde &  Schätzverfahren COCOMO, Lines Of Code, Programmierer Function Points  Preis dieser Funktion * basierend auf ihrer Projekterfahrung Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 40
  • 21. Womit fängt man jetzt an? _____INHALT_____ Fallbeispiel K+P: 12 -20 GPA / OOA S: 6 -10 - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen K+P: 0 -6 OOP - TDD & FDD S: 0 -3 - Scrum - Pair Programming - Cont. Integration K+P: 12 -20 Der ideale Kunde & S: 0 -3 Programmierer Man beginnt mit dem höchsten Risiko und dem höchsten Wert! Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 41 Exemplarische Priorisierung aus der Seminarverwaltung _____INHALT_____ Fallbeispiel Planning Poker: GPA / OOA - Story Cards Zusammen mit dem - Use Cases - Aktivitäten Kunden die nächsten - Objekte & Klassen - CRC-Karten Schritte planen! - Risk/Value+Poker OOD Wie detailliert? - Klassen - Zustände vgl. eine Scrum-Aufgabe - Sequenzen  <16 Mannstunden OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 42
  • 22. Klassen im Design Von den Klassen zum Code _____INHALT_____ Fallbeispiel In der Design-Form beinhalten Klassen-Diagramme GPA / OOA alle notwendigen Methoden und Attribute. - Story Cards - Use Cases  mit Modellierungs-Werkzeuge Java- oder - Aktivitäten - Objekte & Klassen C#-Coderümpfe generieren - CRC-Karten - Risk/Value+Poker  „Nur noch“ mit Funktionalität füllen OOD - Klassen - Zustände Auch Beziehungen zwischen Klassen wie - Sequenzen „ein Kunde hat n Rechnungen“ OOP - TDD & FDD - Scrum können automatisch in Java-Collections abgebildet - Pair Programming - Cont. Integration werden; u.a. mit ObjectIf von MicroTool Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 44
  • 23. Von den Klassen zum Code _____INHALT_____ Fallbeispiel GPA / OOA - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 45 Beispiel: Together Edition for SAP NetWeaver Developer Studio _____INHALT_____ Fallbeispiel GPA / OOA - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer
  • 24. Einige Klassen im Design aus der Seminarverwaltung _____INHALT_____ Seminarverwaltung Fallbeispiel Seminar-Termin - Seminare: ArrayList - instance: Seminarverwaltung - von: Date GPA / OOA - bis: Date - Story Cards - Use Cases + getInstance(): Seminarverwaltung + suche (String Inhalt): Seminar + DozentZuweisen (Dozent d) - Aktivitäten + RaumZuweisen (Raum r) - Objekte & Klassen + suche (Long ID): Seminar - CRC-Karten .... ... - Risk/Value+Poker * 0: individuelles OOD In-House Seminar - Klassen * - Zustände Seminar - Sequenzen - ID: Long OOP - Zustand: Enum {existiert, buchend, ausgebucht, - TDD & FDD durchgeführt, storniert, gelöscht} - Scrum - Kurzbeschreibung: String - Pair Programming - Inhalt: String - Cont. Integration - SeminarZiel: String Der ideale Kunde & - Ort: String Programmierer - Dauer: Byte - minAnzTN: Byte - maxAnzTN: Byte - Preis: Decimal + Daten anzeigen (): String + Daten aktualisieren (Date von,...): String + anmelden (Termin T, Teilnehmer TN) + abmelden (Termin T, Teilnehmer TN) + stornieren (Termin T) Dr. rer. nat. Frank Dopatka + entfallen (Termin T) FrankDopatka@web.de hinzufügen(Date von, Date bis) + Termin Folie 47 .... Zustands-Diagramme
  • 25. Wieso noch Zustandsdiagramme? _____INHALT_____ Fallbeispiel Sicht auf alle möglichen Zustände eines Objektes GPA / OOA  bezieht sich auf genau eine Klasse - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen Zustandsübergänge treten i.d.R. dadurch auf, dass - CRC-Karten - Risk/Value+Poker das betreffende Objekt „angetriggert“ wird OOD  Methodenaufruf - Klassen - Zustände - Sequenzen Prinzipiell kann jede Methode eines Objektes jederzeit OOP - TDD & FDD aufgerufen werden: - Scrum - Pair Programming Methodenaufruf Y im Zustand X erlaubt ??? - Cont. Integration  Zustandsdiagramm Der ideale Kunde & Programmierer  wenn nicht erlaubt  Exception Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 49 Sichere Automaten! _____INHALT_____ Fallbeispiel Vollständige Zustandsautomaten... GPA / OOA - Story Cards - Use Cases  Robustheit der Software: - Aktivitäten - Objekte & Klassen im Alltag werden oft einzelne Methodenaufrufe in - CRC-Karten - Risk/Value+Poker bestimmten Zuständen „vergessen“ OOD - Klassen - Zustände  Ein Objekt ist gegen seinen Zustandsautomaten - Sequenzen testbar OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 50
  • 26. Zustands-Diagramm aus der Seminarverwaltung _____INHALT_____ Fallbeispiel Ein Objekt der Klasse „Seminar“: GPA / OOA - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 51 Sequenz-Diagramme
  • 27. Aktivitäten vs. Sequenzen _____INHALT_____ Fallbeispiel Aktivitäts-Diagrammen: GPA / OOA Abläufe aus Sicht des Geschäftsprozesses mit deren - Story Cards - Use Cases Zuständigkeiten modelliert - Aktivitäten - Objekte & Klassen  Fachliches Modell - CRC-Karten - Risk/Value+Poker Nun wurden bereits Klassen, deren Methoden und OOD Beziehung ermittelt... - Klassen - Zustände - Sequenzen Sequenz-Diagramm: OOP Darstellung des technisch modellierten Ablaufs - TDD & FDD - Scrum darstellen - Pair Programming - Cont. Integration  Technisches Modell Der ideale Kunde & Programmierer • Ablauf von Nachrichten von Objekten untereinander durch gegenseitige Methoden- Aufrufe • Auslöser: Akteur, der einen Use-Case initiiert Sequenz-Diagramm aus der Seminarverwaltung: „Buchung vornehmen“
  • 28. Test Driven Development & Feature Driven Development Was ist Testgetriebene Entwicklung? _____INHALT_____ Fallbeispiel • Ziel: Software-Tests vor den zu testenden GPA / OOA Komponenten erstellen! - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen  Erstellte Unit-Tests sind Grey-Box-Tests - CRC-Karten - Risk/Value+Poker statt klassischer White-Box-Tests OOD - Klassen - Zustände • Unit-Tests und mit ihnen getestete Units werden - Sequenzen stets parallel entwickelt. OOP - TDD & FDD - Scrum - Pair Programming • eigentliche Programmierung in kleinen & - Cont. Integration wiederholten Schritten Der ideale Kunde & Programmierer • eine Iteration (Dauer: wenige Minuten) hat drei Hauptteile: Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 56
  • 29. Was ist Testgetriebene Entwicklung? _____INHALT_____ Fallbeispiel 1. Schreiben Sie einen Test für das erwünschte GPA / OOA fehlerfreie Verhalten, das implementiert werden soll. - Story Cards - Use Cases Dieser Test wird erst einmal nicht erfüllt bzw. es gibt - Aktivitäten - Objekte & Klassen den Code gibt es noch gar nicht. - CRC-Karten - Risk/Value+Poker 2. Änderen/schreiben Sie den Code mit möglichst OOD wenig Aufwand, bis nach dem anschließend - Klassen - Zustände angestoßenen Testdurchlauf alle Tests bestanden - Sequenzen werden. OOP - TDD & FDD - Scrum 3. Räumen Sie im Code auf (Refactoring): - Pair Programming - Cont. Integration - Wiederholungen entfernen Der ideale Kunde & - Code abstrahieren Programmierer - Code nach Konventionen ausrichten - ... - testen! Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 57 Test-Entwurf aus der Seminarverwaltung _____INHALT_____ Fallbeispiel Test: GPA / OOA Seminar anlegen - Story Cards - Use Cases Vorbedingung: - Aktivitäten - Objekte & Klassen --- - CRC-Karten prüfbare Nachbedingung Erfolg: - Risk/Value+Poker Seminar wurde mit seinen Daten in der OOD Seminarverwaltung aufgenommen und - Klassen eine neue Seminar-ID wurde vergeben. - Zustände Nachbedingung erwarteter Fehlschlag: - Sequenzen Seminar mit diesem Titel existiert OOP bereits. - TDD & FDD Test: - Scrum Seminar buchen - Pair Programming - Cont. Integration Vorbedingung: Der ideale Kunde & Seminar existriert bereits und ist Programmierer zum gewählten Termin nicht ausgebucht prüfbare Nachbedingung Erfolg: Kunde wurde als TN in die Liste der TN zum gewählten Termin aufgenommen Nachbedingung erwarteter Fehlschlag: Meldung „Nicht möglich: Kunde hat Dr. rer. nat. Frank Dopatka noch >3 offene Rechnungen!“ FrankDopatka@web.de Folie 58
  • 30. Was ist Feature-getriebene Entwicklung? _____INHALT_____ Fallbeispiel FDD wird eingesetzt, um ein (großes) zeitkritisches GPA / OOA Projekt (z.B. 15 Monate, 50 Entwickler) durchzuführen. - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen Jedes Feature stellt einen Mehrwert für den Kunden - CRC-Karten - Risk/Value+Poker dar. OOD - Klassen - Zustände Die Entwicklung wird anhand eines Feature-Plans - Sequenzen organisiert. OOP - TDD & FDD - Scrum - Pair Programming Eine wichtige Rolle spielt der Chef-Architekt, der - Cont. Integration ständig den Überblick über die Gesamtarchitektur und Der ideale Kunde & Programmierer die fachlichen Kernmodelle behält. Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 59 Prozesse der Feature-getriebenen Entwicklung _____INHALT_____ Fallbeispiel 1. Entwicklen Sie ein Gesamtmodell: GPA / OOA - Konsens über Inhalt und Umfang des zu - Story Cards - Use Cases entwickelnden Systems - Aktivitäten - Objekte & Klassen - fachliche Kernmodell - CRC-Karten - Risk/Value+Poker  grobe Use Cases OOD - Klassen 2. Erstellen Sie eine Feature-Liste: - Zustände - Sequenzen - nach dem einfachen Schema OOP <Aktion> <Ergebnis> <Objekt> - TDD & FDD - Scrum - Bsp.: „Berechne Gesamtsumme der Verkäufe“ - Pair Programming - Cont. Integration - max. zwei Wochen zur Realisierung Der ideale Kunde &  Risk/Value & Planning Poker Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 60
  • 31. Prozesse der Feature-getriebenen Entwicklung _____INHALT_____ Fallbeispiel 3. Planen Sie jedes Feature GPA / OOA - Reihenfolge der Realisierung festlegen - Story Cards - Use Cases - Fertigstellungstermine je Geschäftsaktivität - Aktivitäten - Objekte & Klassen - Projektleiter, Entwicklungsleiter sowie - CRC-Karten - Risk/Value+Poker Senior-Programmierer beteiligt OOD - Klassen 4. Entwurf jedes Features - Zustände - Sequenzen - Entwicklerteams zuweisen OOP - Erstellung von Sequenz-Diagrammen - TDD & FDD - Scrum - erste Klassen- und Methodenrümpfe - Pair Programming - Cont. Integration Der ideale Kunde & 5. Ausprogrammierung der Features Programmierer - Pair Programming & TDD Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 61 Scrum
  • 32. Was ist Scrum? _____INHALT_____ Fallbeispiel • „Das Gedränge“: agiles Vorgehensmodell GPA / OOA Meetings, Artefakten, Rollen & Werten - Story Cards - Use Cases  folgt dem Prinzip der „Schlanken Produktion“ - Aktivitäten - Objekte & Klassen (lean production) - CRC-Karten - Risk/Value+Poker OOD • Teammitglieder organisieren ihre Arbeit - Klassen - Zustände weitgehend selbst & wählen auch die eingesetzten - Sequenzen Entwicklungswerkzeuge und -Methoden OOP - TDD & FDD - Scrum - Pair Programming • Entwicklung ist sehr komplex - Cont. Integration  im Voraus weder in große abgeschlossene Der ideale Kunde & Programmierer Phasen noch in einzelne Arbeitsschritte (Granularität von Mannstunden) planbar  Selbst-Organisation! Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 63 Grundlegende Begriffe des Scrum _____INHALT_____ Fallbeispiel • Zentrales Element ist der Sprint: GPA / OOA Umsetzung einer Iteration (ca. 30 Tage) - Story Cards - Use Cases - Aktivitäten - Objekte & Klassen • Vor dem Sprint: - CRC-Karten - Risk/Value+Poker Produkt-Anforderungen des Kunden in einem OOD Product Backlog sammeln - Klassen - Zustände  beinhaltet alle Funktionalitäten, die der - Sequenzen Kunde wünscht OOP - TDD & FDD  Priorisierung der Funktionen - Scrum - Pair Programming - Cont. Integration • Hoch priorisierte Features: Der ideale Kunde & Programmierer  von den Entwicklern im Aufwand geschätzt  ins Sprint Backlog übernehmen: - enthält alle Aufgaben, um das Ziel des Sprints zu erfüllen - eine Aufgabe: < 16 Stunden - längere Aufgaben: in Teilaufgaben zerlegen
  • 33. Meetings, Review & Retrospektive _____INHALT_____ Fallbeispiel Täglich: Daily Scrum Meeting (max. 15min.) GPA / OOA  Team stellt sich gegenseitig folgende Fragen: - Story Cards - Use Cases • „Bist du gestern mit dem fertig geworden, was du dir - Aktivitäten - Objekte & Klassen vorgenommen hast?“ - CRC-Karten - Risk/Value+Poker • „Welche Aufgaben wirst du bis zum nächsten OOD Meeting bearbeiten?“ - Klassen - Zustände • „Gibt es ein Problem, das dich blockiert?“ - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Meetings, Review & Retrospektive _____INHALT_____ Fallbeispiel • Nach einem Sprint: GPA / OOA Ergebnis einem informellen Review unterziehen: - Story Cards - Use Cases Team & Kunden - Aktivitäten - Objekte & Klassen  Ergebnis des Sprints (laufende Software) - CRC-Karten - Risk/Value+Poker vorführen OOD - Klassen - Zustände • Kunde prüft, ob das Sprint-Ergebnis seinen - Sequenzen Anforderungen entspricht: OOP - TDD & FDD Änderungswünsche  Product Backlog - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 66
  • 34. Meetings, Review & Retrospektive _____INHALT_____ Fallbeispiel • Retrospektive: GPA / OOA zurückliegende Sprint-Phase betrachten; - Story Cards - Use Cases zunächst wertfreien Rückblick auf die Ereignisse - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker • Teilnehmer notieren die wichtigen Ereignisse auf OOD Zetteln. - Klassen - Zustände - Sequenzen • Anschließend schreiben die Teilnehmer Antworten OOP - TDD & FDD auf die Fragen - Scrum - Pair Programming - „Was war gut?“ (Best practice) - Cont. Integration - „Was könnte verbessert werden?“ Der ideale Kunde & Programmierer (Verbesserungspotential) • Jedes Verbesserungspotential wird priorisiert und mit Zuständigkeiten versehen. Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 67 Pair Programming
  • 35. Wie funktioniert Pair Programming? _____INHALT_____ Fallbeispiel • jeweils zwei Programmierer an einem Rechner GPA / OOA - Story Cards - Use Cases • einer schreibt den Code, der andere: - Aktivitäten - Objekte & Klassen - nachdenken über die Problemstellungen - CRC-Karten - Risk/Value+Poker - Code kontrollieren  Probleme sofort OOD ansprechen  sofort lösen - Klassen - Zustände - Sequenzen • Rollen abwechseln & Zusammensetzung der OOP - TDD & FDD Paare häufig ändern - Scrum - Pair Programming - Cont. Integration Ziel: Der ideale Kunde & Programmierer Erhöhung der Software-Qualität Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 69 Vorteile des Pair Programming _____INHALT_____ Fallbeispiel • Höhere Disziplin: GPA / OOA Paare entwickeln eher an der richtigen Stelle & - Story Cards - Use Cases machen kürzere Pausen - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker • Besserer Code: OOD Man entwickelt man sich weniger leicht in - Klassen - Zustände Sackgassen. - Sequenzen OOP - TDD & FDD • Höhere Moral: - Scrum - Pair Programming spannender & interessanter als alleine - Cont. Integration Der ideale Kunde & Programmierer • Collective Code Ownership: alle erlangen Wissen über die gesamte Codebasis, die gemeinsam erstellt wurde Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 70
  • 36. Vorteile des Pair Programming _____INHALT_____ Fallbeispiel • Mentoring: GPA / OOA Jeder hat Wissen, das andere nicht haben. - Story Cards - Use Cases  einfache Wissensverbreitung - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker • Team-Bildung: OOD Leute lernen sich gegenseitig schneller kennen - Klassen - Zustände  Zusammenarbeit verbessert - Sequenzen OOP - TDD & FDD • Weniger Unterbrechungen: - Scrum - Pair Programming Paare werden seltener unterbrochen. - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 71 Continous Integration
  • 37. Motivation _____INHALT_____ Fallbeispiel Unit-und Modul-Tests... GPA / OOA mit Werkzeugen wie JUnit mitlerweile - Story Cards - Use Cases automatisiert erstellbar! - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker  Wie können „höhere“ Tests - z.B. Integrationstest, OOD gehandhabt werden? - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer ??? Motivation _____INHALT_____ Fallbeispiel Gerade wenn bei der Integration der Komponenten GPA / OOA Design-Fehler entdeckt werden, ist dies entsprechend - Story Cards - Use Cases teuer! - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker OOD - Klassen - Zustände - Sequenzen OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 74
  • 38. Die Idee der Continous Integration _____INHALT_____ Fallbeispiel • Kontinuierliche Integration: GPA / OOA regelmäßiges, vollständiges Neubilden & - Story Cards - Use Cases Testen einer Anwendung - Aktivitäten - Objekte & Klassen - CRC-Karten - Risk/Value+Poker  Änderungen in die Versionsverwaltung einchecken OOD  Gesamtsystem neu bauen & automatisch - Klassen - Zustände testen - Sequenzen OOP - TDD & FDD  alle Tests erfolgreich: - Scrum - Pair Programming  Änderungen an die nächste Stufe geben - Cont. Integration  Tests scheitern: Der ideale Kunde & Programmierer  Änderungen zurücknehmen (Rollback)  zur Korrektur vorlegen Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 75 Werkzeuge zur Continous Integration _____INHALT_____ Fallbeispiel Voraussetzung: GPA / OOA - Versionsverwaltungssystem - Story Cards - Use Cases - zeitnahes Check-In - Aktivitäten - Objekte & Klassen - nur funktional vollständige Blöcke eingecheckt - CRC-Karten - Risk/Value+Poker Das Java-basierte CruiseControl hilft bei der OOD - Klassen Umsetzung der CI: - Zustände - Sequenzen - Benachrichtigung per E-Mail, OOP - Nutzung von Apache Ant - TDD & FDD - Scrum & anderen Werkzeugen - Pair Programming - Cont. Integration - Web-Oberfläche: aktuellen und vorherigen Der ideale Kunde & Zustand der Software anzeigen Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 76
  • 39. Der ideale Kunde & Programmierer Mit welchen Kunden funktionieren agile Methoden (nicht)? _____INHALT_____ Fallbeispiel • experimentierfreudig GPA / OOA • selbst erhebliche Ressourcen aufwenden - Story Cards - Use Cases - Aktivitäten • Worin besteht das Gewek? - Objekte & Klassen - CRC-Karten ... das durch den vereinbarten Preis erworben - Risk/Value+Poker wird OOD - Klassen • Kunde verzichtet auf formale Spezifikation und - Zustände - Sequenzen bindendes Angebot OOP - TDD & FDD • Es darf nicht die Mentalität „das machen wir mal - Scrum - Pair Programming eben nebenbei“ vorherrschen - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 78
  • 40. Mit welchen Kunden funktionieren agile Methoden (nicht)? _____INHALT_____ Fallbeispiel • Vertreter des Kunden darf selbst nicht gezwungen GPA / OOA sein, seinen Vorgesetzten eine - Story Cards - Use Cases - Planung im Vorfeld - Aktivitäten - Objekte & Klassen - Erfüllung bestimmter Funktionen zu festgelegten - CRC-Karten - Risk/Value+Poker Terminen zu berichten OOD - Klassen - Zustände • "Kunde vor Ort"-Prinzip - Sequenzen  Mitarbeiter des Kunden benötigen selbst einen OOP - TDD & FDD erheblichen Wissensumfang - Scrum - Pair Programming  Sind diese Personen entbehrlich? - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 79 Mit welchen Programmierern funktionieren agile Methoden (nicht)? _____INHALT_____ Fallbeispiel • Programmierer: sehr gute Fähigkeiten GPA / OOA  häufige Änderungen - Story Cards - Use Cases  umfangreiche Programmiererfahrung - Aktivitäten - Objekte & Klassen  geeignete Werkzeuge - CRC-Karten - Risk/Value+Poker OOD • ausgeprägtes Ego: - Klassen - Zustände  große Überzeugung von „richtigen Lösungen“ - Sequenzen  Besitzdenken des geschriebenen Codes äußert: OOP - TDD & FDD  Nicht jeder kann damit umgehen, - Scrum - Pair Programming dass „sein“ Code von anderen verändert wird - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 80
  • 41. Mit welchen Programmierern funktionieren agile Methoden (nicht)? _____INHALT_____ Fallbeispiel • XP weist eine Reihe von Merkmalen auf, GPA / OOA - die hohe Disziplin erfordern - Story Cards - Use Cases  TDD & CI, permanante Refactorings, - Aktivitäten - Objekte & Klassen Programmieren in Paaren - CRC-Karten - Risk/Value+Poker - und andere, die eine gewisse Disziplin- OOD - Klassen losigkeit fördern - Zustände - Sequenzen  das Auslassen von Spezifikation OOP - TDD & FDD - Scrum - Pair Programming - Cont. Integration Der ideale Kunde & Programmierer Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 81 Vielen Dank für Ihre Aufmerksamkeit! Noch Fragen? Quellen des Vortrags: • Wikipedia <http://de.wikipedia.org> • Vorlesung „Einführung in die Informatik II“ <http://www.bs.informatik.uni-siegen.de/www/lehre/ss09/ei2/index_html> • Fowler, Scott: UML konzentriert; 2. Auflage; Addison Wesley Verlag; ISBN 3-8273-1617-0 • Helmut Balzert: Lehrbuch der Software-Technik: Software-Entwicklung; 2. Auflage; Spektrum-Verlag; ISBN 3-8274-0480-0 • Booch, Rumbaugh, Jacobson: Das UML Benutzerhandbuch; Addison-Wesley Verlag; ISBN 3-8273-2295-2