There's another long thread running that's spawned some interesting side discussions. I'd like to promote one of these out of there, since it's getting rather confusing and since I think there's a lot of valuable discussion going on I'd hate for it to get lost.
So this post follow on from the comment
Need to clarify the semantics of "the model" by Rudy.
When we're talking about "the model" we mean the business logic. We always partition an application into layers that include (some of) a User Interface layer (UI), a Problem Domain (PD) or "business logic" layer, a System Interface (SI) layer and a Data Management (DM) layer.
The UI is all about presentation. We use standard techniques like MVC or its variants to ensure these are decoupled, and most importantly there is a one-way dependancy from the UI on to the PD and not the other way around.
The SI layer deals with interfaces to external systems. We use a similar approach to the UI layer to decouple these, which achieves a dependancy from the SI back onto the PD and not the other way around.
The DM layer deals with persistence. These days it's more often a "buy-not-build" situation, as there are plenty of tools out there that can help. I prefer to use some kind of object-relational (OR) mapping technology (e.g. TopLink) here whenever possible, but you might be stuck with other approaches like vanilla JDBC or entity beans in an EJB environment.
The real core of the app is the PD layer. This is where we model the domain - the business we're in. It's the most important piece of the puzzle: if you get it wrong nothing else can save you. If you get it right you can vary the other layers independantly, or even have multiple different types for some of the layers (e.g. several different user interfaces at once).
If we don't specifically state otherwise, when we talk about "the model" we're talking about the PD layer. On an FDD project we will partition out the UI, and if present the SI. Each layer will have its own features list, progress reports, developers, designs, work packages, and codebase. The PD does not depend on anything else, but the UI and SI layers do have a dependancy on the PD. Then each layer is run as a "mini FDD project" - the entire process is performed for each layer.
The milestones described in the process descriptions are best suited to PD and SI layer development - for the UI we will change them to suit the UI technology and design process that's in use. Gavin might also be able to share some experiences deciding on appropriate milestones for UI development. On a similar note Martin has posted a discussion of using FDD for web development over here.
Because of the shape of the dependancies we typically kick off the PD development first. At some point after the initial modelling has been completed the UI interactions designers go to work. When we have a UI design, and the appropriate technology decisions, the UI development can proceed. The UI development sequence is obviously impacted by the PD development - you can't very easily code up the UI for pieces of the PD that aren't done yet. A similar approach is taken with the SI, though in this case the external interfaces and the requirements are usually very well established.
So "the model" we talk about is the PD model. Because of the partitioning there are no presentation details here, nor external system hookups. Depending on the technology chosen, there may be some consideration needed for persistence. This is why I prefer an OR-mapping tool - it's the least intrusive and I don't end up mangling the domain model just to get persistence capabilities.
The UI team will have its own model, that is built with a dependancy on the PD model. Often with UI development a class diagram is one of the less useful design artifacts. Sometimes only framework and support type classes, usually specific to the technology chosen, utilise class diagrams as the best way to express their design. That doesn't mean we don't use them however - just that there's often better ways to express the design.