An initial project-wide activity with domain and development members working together under the guidance of an experienced object modeler in the role of Chief Architect.
Domain Experts perform a high-level walkthrough of the scope of the system and its context. They then perform detailed domain walkthroughs for each area of the domain that is to be modeled. After each domain walkthrough, small groups are formed with a mix of domain and development staff. Each small group composes its own model in support of the domain walkthrough and pre-sents its results for peer review and discussion. One of the proposed models or a merge of the mod-els is selected by consensus and becomes the model for that domain area. The domain area model is merged into the overall model, adjusting model shape as required.
The object model is then updated iteratively with content by process 4, Design by Feature.
- Domain Experts, Chief Programmers, and the Chief Architect have been selected for the project.
|Form the Modeling Team||Project Manager||Required|
|The modeling team consists of permanent
members from the domain and development areas, specifically, the
Domain Experts and the Chief Programmers. Rotate other project
staff through the modeling sessions so that everyone gets a chance
to participate and to see the process in action.
|Conduct a Domain Walkthrough||Modeling Team||Required|
A Domain Expert gives an overview of the domain area to be modeled. This should include information that is related to this domain area but not necessarily a part of its implementation.
|Study Documents||Modeling Team||Optional|
|The team studies available reference or
requirements documents, such as object models, functional
requirements (traditional or use-case format), and user
|Develop Small Group Models||Modeling Team in Small Groups||Required|
|Forming groups of no more than three,
each small group composes a model in support of the domain area.
The Chief Architect may propose a "strawman" model to facilitate
the progress of the teams. Occasionally, the groups may also sketch
one or more informal sequence diagrams to test the model
|Develop a Team Model||Modeling Team||Required|
|A member from each small group presents
that group's proposed model for the domain area. The Chief
Architect may also propose further model alternatives. The modeling
team selects one of the proposed models or composes a model by
merging ideas from the proposed models.
|Refine the Overall Object Model||Chief Architect, Modeling Team||Required|
|Every so often, the team updates the
overall object model with the new model shapes produced by
iterations of the previous two tasks.
|Write Model Notes||Chief Architect, Chief Programmers||Required|
|Notes on detailed or complex model
shapes and on significant model alternatives are made for future
reference by the project.
|Internal and External Assessment||Modeling Team, Business||Required|
|Domain Experts actively participating
in the process provide internal or self-assessment. External
assessment is made on an as-needed basis by referring back to the
business (users) for ratification or clarification of issues that
affect the model.
To exit the process, the modeling team must produce an object model to the satisfaction of the Chief Architect. The object model consists of:
Class diagrams focusing on model shape, the classes in the domain, how are they connected to one another and under what constraints, plus any operations and attributes identified.
Sequence diagram(s),if any.
Notes capturing why a particular model shape was chosen and/or what alternatives were considered.
This version of FDD Process #1 is taken from the book, Palmer, Felsing, 'A Practical Guide to Feature-Driven Development' , Prentice Hall, 2002.