Creating the Paper Prototype
After the use cases are complete, you will have a strong description of the system and how it functions. You should have a good understanding of the system flow and the rules by which it will interact with users. At this point, you are ready to create the paper prototype. The paper prototype, also know as the storyboard, is a set of drawings that shows every screen in the system. The objective is to bring the use cases to life and to prove that your system will work when built.
The first technical model that we create is the database model. Database models are perhaps the best understood of all system models. In nearly all projects, even poorly designed ones, some kind of database model will be created. Most developers are at least familiar with the process of identifying entities and relationships.
Although most developers can create a database model, few have actually created a logical model. A logical model represents the software classes in the system. Just as a database model can be used to create a database, the logical model can be used to create COM+ components.
Almost anyone can learn to successfully create use cases, but jumping from use cases to a logical model takes a tremendous amount of experience. Often companies will employ "business analysts" to produce use cases, but the logical model can be created only by a true software architect.
The goal of a logical model is to create a completely defined model that contains the name and definition of every class in the application with 80 percent accuracy. That's rightthe software architect must define every class, every method, and every property without ever writing a single line of code. This is why the software architect must be an experienced developer who understands the use cases completely.
Defining the classes and components in a system is done with UML. UML provides symbols for defining classes as well as components such as ActiveX DLLs. The UML-compliant Microsoft Visual Modeler can be used to create logical models. Figure 2 shows the UML symbol for a class.
The UML symbol for a class
One of the most useful ways to present the classes you've designed is through a three-tier diagram. The three-tier diagram shows all the classes that you've designed, broken into their associated tier. In this way, developers can see what classes make up data services, business services, and user services. The three-tier diagram doesn't require any new work on your part; it's simply a convenient way of showing the required classes. Figure 3 shows a typical three-tier diagram.
Three-tier diagrams help developers understand a system
When the modeling is complete, these diagrams should be turned over to developers for construction. The actual system coding should be about 35 percent of the overall effort. You should also find that the coding effort is greatly simplified because you have answered many of the technical questions during the system modeling.