Ippon!Soft Feature Driven Development (FDD) & Modeling in Color (Peter Coad)

ippon!Soft

Feature Driven Development (FDD)&

Modeling in Color

(Peter Coad)

ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 2

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>> Farbe Rot

0..* actual

plan

0..1

1 1..*

<<mi-detail>>MomentIntervalDetail

-qty:int

+calcTotal:void

<<moment-interval>>MomentInterval

-number:int-dateOrDateTimeOrInterval:int-priority:int-total:int-status:int

+makeMomentInterval:void+addDetail:void+calcTotal:void+recalcTotal:void+complete:void+cancel:void+mi_generateNext:void+mi_assessWRTPrior:void+mi_assessWRTNext:void+mi_comparePlanVsActual:void+listMIs:void+assessAcrossMIs:void


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 <<role>>

ThingRole

-assignedNumber:int-status:int

+assessAcrossMIs:void+listMIs:void+listRoles:void+assessAcrossRoles:int

<<role>>PlaceRole



<<role>>PartyRole




Archetypen

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

ThingDescription

-type:int-description:int-itemNumber:int-defaultValue:int

+assessWithPlugInElseDefault:void+assessAcrossThings:void+findAvailable:void+calcQtyAvailable:void+calcTotalFor:int+listThings:int+listDescs:int+assessAcrossDescs:int

<<description>>PlaceDescription


+assessWithPlugInElseDefault:void+assessAcrossPlaces:void+findAvailable:void+calcQtyAvailable:int+calcTotalFor:int+listPlaces:int+listDescs:int+assessAcrossDescs:int

<<description>>PartyDescription


+assessWithPlugInElseDefault:void+assessAcrossParties:void+findAvailable:int+calcQtyAvailable:int+calcTotalFor:int+listParties:int+listDescs:int+assessAcrossDescs:int


Archetypen

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

Place

-serialNumber:int-name:int-address:int-customValue:int

+assessAcrossRoles:int+getCustomElseDefaultValue:void+listRoles:int+listPlaces:void+assessAcrossPlaces:int

<<thing>>Thing


+assessAcrossRoles:int+getCustomElseDefaultValue:void+listRoles:int+listThings:void+assessAcrossThings:int

<<party>>Party


+assessAcrossRoles:int+getCustomElseDefaultValue:void+listRoles:int+listParties:void+assessAcrossParties:int


Domain-Neutral Component

0..*

1

0..1

0..*

plan

actual

1 0..*1 1..*

0..* 1

<<description>>Description


<<role>>Role


<<thing>>PartyPlaceThing



-number:int-dateOrDateTimeOrInterval:int-priority:int-total:int-status:int


-qty:int


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)

1

11 0..*

0..1

0..1

0..*

plan

actual

0..*

0..*0..*

1

1..*

1 0..*

0..*

1

1

0..1

1

0..1

0..1

1 10..*

10..*

0..*

1

0..1

0..1

<<description>>PartyDescription

<<plug-in point>>interfaceIAssess

+assess:void



<<role>>PartyRole

<<role>>PlaceRole

<<moment-interval>>NextMI

<<place>>Place

<<description>>PlaceDescription


+assess:void

<<plug-in point>>interface

IMakeMomentInterval

+makeMomentInterval:void

<<moment-interval>>PriorMI

<<party>>Party

<<role>>ThingRole

<<thing>>Thing

<<description>>ThingDescription


+assess:void


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.



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>>



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!



0..*

1

1 0..*

1 0..*

0..* 1

0..*

1..*

1 0..* 10..*

0..*1

0..*

1

1

0..*

/ (derivable)1

0..*

/ (derivable)

1

0..*

10..*

0..* 1..*

0..*

1..*

/ (derivable)

1..*

<<moment-interval>>CashSaleSession

<<moment-interval>>CashDrawerAssignment

<<moment-interval>>CashSale

<<thing>>CashDrawer

<<role>>ProductBeingSold

<<description>>ProductDescription

<<thing>>Product

<<role>>FacilityAsBusinessLocation

<<place>>Facility

<<role>>Customer

<<party>>Person

<<role>>Cashier

<<mi-detail>>CashSaleDetails


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

D evelopan

O verallM odel

Build aFeatures

List

P lanby

Feature

D esignby

Feature

Buildby

Feature


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.


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 Projektablaufssetzt ein feingranulares Reporting voraus! Basis:

“Mini-Meilensteine” mit adaptierbarer Gewichtung...

Design by Feature Build by Feature

DomainWalkthrough

Design Design Inspection Code Code InspectionPromote toBuild

1 % 40 % 3 % 45 % 10 % 1 %

Design by Feature Build by Feature

DomainWalkthrough

Design Design Inspection Code Code InspectionPromote toBuild

1 % 40 % 3 % 45 % 10 % 1 %


Reporting in FDD

Documents

Ippon!Soft Feature Driven Development (FDD) & Modeling in Color (Peter Coad)