A Good Fit

[Previous] [Next]

The kind of architecture we describe in this book enables your team to begin writing code for user interfaces very early. In fact, as soon as someone has designed the facade classes of a specific use case, others can begin to build working prototypes of the user interface classes. UI developers can then create first-pass user interfaces and show them to users and customers.

While this work goes on, the analysts can design other facade classes to make them available as well for prototyping. Activities that used to be carried out one after the other can now happen in parallel.

From Early Validation to Usable Prototypes to Real Applications

All this work can go on even before the inner parts of the server application are designed. As a result, users and buyers might be able to validate the external design of the application before too much work on the internals has been done. Because of all this, analysts and users can cooperate to sharpen requirements early. Naturally, this reasoning assumes that you're designing an end-to-end application rather than designing new user interfaces and new facades for an existing server application.

Since requirements defined this way are sharper, the detailed design of the application will probably be much more to the point. Work will be more effective because more of it will be directed to the creating of functionality that's really needed. Users who participate in this process also gain a much more concrete understanding of their own requirements and of the consequences of some unrealistic requirements of little business value they might be considering. Early prototypes produced this way are the embryonic forms of real applications because they're based completely on requirements. As the requirements are more sharply focused, so are the prototypes. With each iteration of the development process, the prototypes more closely resemble a production system. In the end they will, in fact, be one system.