Describing the system
Scot Hillier

Coding is obviously only a small portion of the development process. Planning and defining are much more important. In this tip, excerpted from InformIT, Scot Hillier discusses how to design successful applications using the Rational Unified Process. Scot is the author of Scot Hillier's COM+ programming with Visual Basic, published by Sams (2001).

---

After the functional requirements are gathered, you are ready to create a text-based model of the system. Designing a system is really a process of creating even more detailed models. This enables the system to be evaluated and changed more easily than if you move directly from requirements to code. The text-based model of the system is created through a set of use cases. A use case is a description of the set of steps necessary to accomplish a function. A complete set of use cases describes at least 80 percent of the system and is the basis for more detailed modeling.

Before you can create a use case, you must identify the actors involved in your system. Actors are people or other systems that will interact with your system. The key to identifying an actor is that the person or system must receive something of value from your system. For example, a customer might receive a product from the system, or the company billing system might receive the required information to create an invoice.

When defining actors, be careful to define them generically based on role, not based on job title. This is because many people in an organization can fill a role. For example, if all the sales personnel are at a meeting, the company vice president might pick up the phone to take an order, thus becoming a salesperson. Typical actors include customer, salesperson, and manager.

When the actors are identified, you can match them with the use cases that they affect. When initially identifying use cases, limit them to simple one-line phrases. Later, you will expand the detail in each use case, but for now you are trying to create a system outline based on the actors and use cases.

Naming actors and use cases takes practice, but remember that an actor interacts with the system to receive a value. The use case is a functional name of the value received. A simple example is to name an actor as "customer" and the use case as "purchase product." In this example, the customer interacts with the system, and the value received is a product.

The design process creates a set of models used to describe the system. These drawings and descriptions are the blueprints used to create the final product. Imagine a set of blueprints for a house, or electrical schematics for a computer. In both cases, you can imagine a set of drawings that completely defines the product to build. Each set of drawings also has its own set of symbols that are unique to the profession in which they are used. Software modeling is no different. In our profession, we use the Unified Modeling Language (UML) to represent the elements in the system.

Although you will ultimately create a complete text-based set of use cases, the first artifact that you create in the modeling process is the use case model. This model is a visual representation of the actors and the use cases. Although this model is extremely simple, I have found that it serves as an invaluable graphical overview of the system. To create the use case model, we use the UML symbol for an actor, and the UML symbol for a use case.

Along with the use case model, you must create the text-based documentation. Documenting the use case provides the underlying detail necessary to fully understand how the actor interacts with the system. Information required for the use case documentation is typically gathered through one-on-one interviews with domain experts and other interested parties. Just like the facilitated sessions, the interview process requires experience and skill to complete successfully.

---

To read more of this article, click over to InformIT. You have to register there, but registration is free.

To learn more about Scot Hillier's COM+ programming with Visual Basic, click here.

Like this tip? Let us know. Click here to sound off.