Feature Driven Development (FDD) & Modeling in Color (Peter Coad) 00000, 1.1.061

Coad im Kontext Peter Coad: OO-Zelebrität der ersten Stunde (“Coad & Yourdon”) Author einer Vielzahl von Büchern (auch über Software-Patterns) “Credo”: Datenorientiertes Modellieren vor Prozessorientierung! “Modeling in Color”: Aktuelle Darstellung von Coads Weg der OO-Modellierung... Kontext: Feature Driven Development... Grundidee: Farbe als zusätzliches Modellierungsmittel...

“Death by Use Case” Am Anfang von Feature Driven Development (FDD) steht die Erfahrung des Scheiterns! 2 Jahre Projektlaufzeit... 3500 Seiten Use-Case-Beschreibung... Mehrere Hundert Klassen mit tausenden Attributen, aber ohne Methoden... Keine Zeile lauffähiger Code... Die Feststellung, das Projekt sei nicht machbar!

Die Lösung Ein kompleter Neubeginn: Leichtgewichtiges Prozess-Framework... (Jeff De Luca, Nebulon) Feingranulare Anforderungsanalyse auf Basis von Features... (Peter Coad, TogetherSoft) Kleine, dynamische Teams mit integriertem Coaching... Gute Leute! Nach 15 Monaten war das Projekt erfolgreich beendet!

Features & Feature Sets Feingranulare Anforderungsanalyse: Feature: <action> <result> <object> Beispiel: “Berechne den Tarif des Vertrags“ Feature Set: Menge zusammengehöriger Features... <action><-ing> a(n) <object> Beispiel: “calculating a contract” “Berechnen eines Vertrages”

Feature Sets, Use Cases, Komponenten Ein Feature Set entspricht in etwa einem Use Case... Ein Major Feature Set entspricht in einer fachliche Komponente. Major Feature Set: <object> management Beispiel: “contract management” “Vertragsverwaltung” Eine fachliche Komponente wird oft durch eine Menge zusammengehöriger Use Cases beschrieben...

Geschäftsobjekte & Archetypen Features gruppieren sich typischerweise um bestimmte zentrale Geschäftsobjekte! Geschäftsobjekte sind in der Regel persistent. Nicht jedes persistente Objekt ist ein Geschäftsobjekt! Nicht jedes Geschäftsobjekt ist “zentral”! Zentral = Kristallisationspunkt für zentrale Geschäftsvorgänge...  Vier grundlegende “Archetypen”! Jedem Archetyp ist ein spezifischer UML-Stereotyp zugeordnet... Jedem Archetyp ist eine spezifische Farbe zugeordnet...

Archetypen Moment-Interval Zeitpunkt oder Zeitraum, der registriert bzw. verfolgt werden muss. Beispiele: Handelsabschluss, Mietverhältnis... Stereotyp <<moment-interval>> Farbe Rot Moment-Intervall wird oft durch ein Detail-Objekt ergänzt Stereotyp <<mi-detail>>

Archetypen Role Art der Teilnahme durch eine Partei, einen Ort, oder ein Ding. Beispiele: Käufer im Handelsabschluss, Mieter im Mietverhältnis... Stereotyp <<role>> Farbe Gelb

Archetypen Description Typ-Beschreibung eines Objektes ähnlich einem Katalogeintrag. Beispiele: Produkt eines Versicherungsvertrages... Stereotyp <<description>> Farbe Blau

Archetypen Party, Place or Thing Partei (Person oder Organisation), Ort, oder Ding. Beispiele: Kunde, Fabrik, Automobil... Stereotyp <<party>>, <<place>>, <<thing>> Farbe Grün

Domain-Neutral Component

Nutzung der Archetypen Archetypen sind Formen, denen alle Dinge derselben Art mehr oder weniger folgen... Archetypen sind nicht sinnvoll als abstrakte Oberklassen zu implementieren! Objekte, die einem Archetyp folgen, bilden ihn soweit als nötig nach. Verhaltensanpassungen erfolgen über “Plugin-Point”-Schnittstellen Vorgesehen Plugin-Points in der domain-neutral Component: Erzeugung spezifischer Moment-Interval-Objekte Komplexe Auswertungen von Description-Objekten

“Domain-Neutral Component” (Erweiterte Struktur)

Barverkauf (“Cash Sale”) Ein Beispiel Situation: Ein Kassierer sitzt zu einer bestimmten Zeit an einer Kasse. Ein Kunde kauft eine bestimmte Menge eines bestimmten Produktes bei dem Kassierer. Der Barverkauf ereignet sich in einer bestimmten Filiale.

Barverkauf (“Cash Sale”) Ein Beispiel Ein Kassierer sitzt zu einer bestimmten Zeit an einer Kasse: Kassierer => <<party>> Kasse => <<thing>> Zuordnung Kassierer-Kasse => <<moment-interval>> Ein Kunde kauft eine bestimmte Menge eines bestimmten Produktes bei dem Kassierer: Kunde => <<party>> Produkt => <<thing>> Barverkauf => <<moment-interval>> Menge im Barverkauf => <<mi-detail>> Der Barverkauf ereignet sich in einer bestimmten Filiale: Filiale => <<place>>

Barverkauf (“Cash Sale”) Ein Beispiel Achtung! Ein Kassierer kann auch manchmal Kunde sein... Eine Filiale ist Verkaufsort aus Sicht des Barverkaufs... Arbeitsplatz aus Sicht des Kassierers... Ein Produkt ist Handelsgegenstand aus Sicht des Barverkaufs... Fabrikationsgegenstand aus Sicht des Produzenten...  Rollen! Das Produkt ist als Gegenstand weitgehend irrelevant! Interessiert vor allem als Typ-Beschreibung!

Barverkauf (“Cash Sale”) Ein Beispiel

Best Practices Domain Object Modeling Developing by Feature Individual Class (Code) Ownership Feature Teams Inspections Regular Builds Configuration Management Reporting/Visibility of Results

Rollen Schlüsselrollen: Project Manager Chief Architect Development Manager Chief Programmers Class Owners Domain Experts Unterstützende Rollen: Domain Manager Release Manager Language Lawyer bzw. Guru Build Engineer Toolsmith System Administrator Zusätzliche Rollen: Testers Deployers Technical Writers

FDD-Prozesse

Develop an Overall Model: FDD-Prozesse Develop an Overall Model: Erstellen eines (skizzenhaften) Domain Object Model mit informellen Anmerkungen. Build a Features List: Erstellen einer (möglichst vollständigen) Liste der Features auf der Basis des Domain Object Models: Identifikation von Geschäftsbereichen (“major feature sets”). Identifikation von Aktivitäten (“feature sets”) in den Geschäftsbereichen. Funktionalen Dekomposition in einzelne Features.

Priorisierung der Feature-Liste. Aufwandsabschätzung FDD-Prozesse Plan by Feature: Priorisierung der Feature-Liste. Aufwandsabschätzung Zeitpunkt der voraussichtlichen Realisierung für Features & Feature Sets... Granulation: Monat! Zuordnen der Klassen des Domain Object Models zu ihren Eigentümern. Zuordnen der Feature Sets an die Chef-Programmierer als Arbeitspakete.

FDD-Prozesse Design by Feature: Analyse des Feature durch den Chef-Programmierer. Zusammenstellen des Feature Teams auf Basis der betroffenen Klassen. Domain Walkthrough. Verfeinerung des Objektmodells. Design & Design-Inspektion. Build by Feature: Implementierung des Designs. Unit-Tests & Code-Inspektionen. Freigabe für den Build.

Reporting in FDD Kontinuierliche Feinabstimmung des Projektablaufs setzt ein feingranulares Reporting voraus! Basis: “Mini-Meilensteine” mit adaptierbarer Gewichtung...

Reporting in FDD