ippon!soft feature driven development (fdd) & modeling in color (peter coad)
TRANSCRIPT
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...
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 3
“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!
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 4
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!
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 5
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”
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 6
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...
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 7
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...
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 8
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
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 9
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
-assignedNumber:int-status:int
+assessAcrossMIs:void+listMIs:void+listRoles:void+assessAcrossRoles:int
<<role>>PartyRole
-assignedNumber:int-status:int
+assessAcrossMIs:void+listMIs:void+listRoles:void+assessAcrossRoles:int
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 10
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
-type:int-description:int-itemNumber:int-defaultValue:int
+assessWithPlugInElseDefault:void+assessAcrossPlaces:void+findAvailable:void+calcQtyAvailable:int+calcTotalFor:int+listPlaces:int+listDescs:int+assessAcrossDescs:int
<<description>>PartyDescription
-type:int-description:int-itemNumber:int-defaultValue:int
+assessWithPlugInElseDefault:void+assessAcrossParties:void+findAvailable:int+calcQtyAvailable:int+calcTotalFor:int+listParties:int+listDescs:int+assessAcrossDescs:int
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 11
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
-serialNumber:int-name:int-address:int-customValue:int
+assessAcrossRoles:int+getCustomElseDefaultValue:void+listRoles:int+listThings:void+assessAcrossThings:int
<<party>>Party
-serialNumber:int-name:int-address:int-customValue:int
+assessAcrossRoles:int+getCustomElseDefaultValue:void+listRoles:int+listParties:void+assessAcrossParties:int
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 12
Domain-Neutral Component
0..*
1
0..1
0..*
plan
actual
1 0..*1 1..*
0..* 1
<<description>>Description
-type:int-description:int-itemNumber:int-defaultValue:int
<<role>>Role
-assignedNumber:int-status:int
<<thing>>PartyPlaceThing
-serialNumber:int-name:int-address:int-customValue:int
<<moment-interval>>MomentInterval
-number:int-dateOrDateTimeOrInterval:int-priority:int-total:int-status:int
<<mi-detail>>MomentIntervalDetail
-qty:int
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 13
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
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 14
“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
<<mi-detail>>MomentIntervalDetail
<<moment-interval>>MomentInterval
<<role>>PartyRole
<<role>>PlaceRole
<<moment-interval>>NextMI
<<place>>Place
<<description>>PlaceDescription
<<plug-in point>>interfaceIAssess
+assess:void
<<plug-in point>>interface
IMakeMomentInterval
+makeMomentInterval:void
<<moment-interval>>PriorMI
<<party>>Party
<<role>>ThingRole
<<thing>>Thing
<<description>>ThingDescription
<<plug-in point>>interfaceIAssess
+assess:void
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 15
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.
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 16
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>>
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 17
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!
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 18
Barverkauf (“Cash Sale”)Ein Beispiel
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
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 19
Best Practices
Domain Object Modeling
Developing by Feature
Individual Class (Code) Ownership
Feature Teams
Inspections
Regular Builds
Configuration Management
Reporting/Visibility of Results
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 20
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
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 21
FDD-Prozesse
D evelopan
O verallM odel
Build aFeatures
List
P lanby
Feature
D esignby
Feature
Buildby
Feature
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 22
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.
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 23
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.
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 24
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.
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 25
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 %
ippon!Soft© 2001-2003 Dr.Ch.Mann (Stand: 04.11.2003) 26
Reporting in FDD