Chapter 18 -- Other Use Cases and Other Facades

[Previous] [Next]

Chapter 18

As we said in Chapter 3, "On Rules and Their Locations," the sample we've been using in most of this book is a very simple part of a larger application. The sample consists of one simple use case, and it features a single facade class only. We hope this simplicity has made the ideas presented in the book easier to follow.

In the real world, most applications must support dozens of use cases and hundreds or even thousands of scenarios. Normally, according to our architecture, each use case has its own facade class, so the application has dozens of facade classes as well. These facade classes are the clients of your main business objects, and the main business objects must support every facade class that might use its services.

The more you know about the requirements of all your facades, the better you can design your main business objects and their interfaces. You should never design your main business classes from one facade only, as we have done so far in this book. We might wrongly have given you the impression that you should develop your applications in accordance with the following action list:

1. Define a use case for a specific way an actor will use the application.
2. Design a facade class that supports this use case.
3. Generate code for this facade class, and add the code needed to make each method of the class a test stub.
4. Create a UI prototype to test the facade class, and validate your ideas with your users or customers.
5. Define main business classes and interfaces to support the facade class.
6. Define data access classes to support the data access needs of each main business class.
7. Implement and test all these classes.

The preceding procedure is not what we want you to follow. The following action list is a much better description of the process we recommend:

1. Define a set of use cases for each actor. As we described in Chapter 2, "Designing for Scalability," a use case represents one way for an actor to use or interact with the system. You should at least define all the most important use cases.
2. Design (in principle) one facade class for each use case defined.
3. As soon as a facade class is designed, someone should generate code for it and insert test stub code in each of the methods of the class.
4. If and when a facade class is converted to a test stub class, and also well tested through a realistic test form, turn it over to UI developers. Have them create prototypes that validate the design of your facade classes. Ask them to show their GUI prototypes to users and decision makers for further validation and for early proof of concept.
5. As facade validations come in, modify the design of the facade classes in answer to the changed requirements (or discovered design errors). Publish new versions of the facade class test stubs until UI developers and customers are satisfied with them. (We're not suggesting that customers give final approval, but merely that they've agreed they can't find any more shortcomings at the moment. This kind of agreement isn't bad in itself, even if it isn't a green light either.)
6. As facades are validated, use them one at a time to design main business objects and interfaces. If the main business objects and interfaces already exist from the development of an earlier application, you must make sure that the existing business objects and interfaces support each requirement from every facade.
7. Don't even begin to think that the design of a main business class or an interface is finished until you have taken all its clients, meaning all the facade classes that will use the class or the interface, under consideration.
8. When a main business class or an interface is designed to support all facade classes in need of its services, perform a stability check on the class or interface. Remove redundancy in methods and behavior. Make the class or interface into a useful and reusable resource, part of an infrastructure based on business logic, rather than a service merely to the very facade class that initialized the design of it.
9. Postpone the design of data access classes until you know as much as possible about what they have to do. You won't know that until the design of your main business classes is finished and stable.
10. Implement and test all the classes of the entire application in an iterative fashion.

Again, this is a simplified action list. If you're particularly interested in system development process models, you should find out more about one or two of them. Here's a short list of such models that might interest you:

• The Rational Unified Process Model. This is a huge model, available at a price from Rational Software in Cupertino, California.
• Microsoft Solution Framework, available from Microsoft Consulting Services.

Both these process models contain everything you need and more. They're not incompatible with each other, even if you can't honestly say that they're very compatible either. The two models come from different backgrounds. Microsoft's model, or rather framework, comes from Microsoft's way of building applications such as Excel, Word, Visual Basic, and Windows. Rational's model comes from a background of pure object orientation, not primarily from building effective and scalable COM+ or Microsoft Transaction Server (MTS) applications that are constructed from mainly stateless COM components. Just the same, you could rather easily adapt either one of them to your own reality and to the ideas put forward in this book.