by John Zukowski

Last month, you learned about creating a set of use cases to help you in the development of a Todo List Manager application. There is more to use cases than identifying them with names such as Create Task and Generate Report. They are meant to specify a sequence of actions for the system to perform, as observed by an actor or user.

Once you have the high-level tasks defined in use cases, you can document the use case further by describing specific paths through the system. For instance, the Edit Task use case can have a sequence of actions through the use case as follows:

• System presents list of tasks to user.
• User identifies which task to edit.
• User makes changes to task.
• System updates record for task.

Going to this level of detail might seem overkill for such a small task, but as you understand the process, it makes larger projects that much easier to develop. It also allows someone to hand off the subparts of the use case to different team members, allowing well-understood work to be done in parallel. In addition, breaking the use cases down allows you to attach quantifiable measures if the tasks have requirements for things such as response time. Had this Todo List manager application been required to run on a telephone, how would the Edit Task action react when a phone call comes in?

Additionally, when defining use cases, it is best to identify test cases as well. For a single user Todo List application, the Edit Task use case is relatively easy. But when you have a multiuser environment, the use case can have a test case for handling multiple users.

If you define the appropriate response up front, before development has started, coding becomes that much easier because you already know how the system should respond to dual updates.

Part of the documenting of use cases and of a whole system's design is the creation of different diagrams. Last month, you saw the aptly named use-case diagram. This is a rather crude-looking diagram in which the actor is literally a stick figure. As you start to learn about other diagrams, a tool can be helpful. Two popularly available open-source options are the NetBeans 5.5 IDE UML Modeling pack plug-in and ArgoUML available through CollabNet.

These tools use Unified Modeling Language (UML) to document a system's model. The Object Management Group (OMG) standard offers a common method for system modeling. The process began a little over 10 years ago when "the Three Amigos" -- Grady Booch, Ivar Jacobson, and James Rumbaugh -- came together to adopt a common syntax that wasn't proprietary to help speed the adoption of object-oriented technologies. At the time, Linux was about five years old, and the open-source movement and all its associated sharing were not yet popular.

Although the latest UML release, 2.0, defines 13 types of diagrams, most tools don't support them all. The NetBeans IDE UML Modeling tool allows you to create eight diagrams: Use Case diagram, Activity diagram, Class diagram, Collaboration diagram, Component diagram, Deployment diagram, Sequence diagram, and State diagram. ArgoUML doesn't provide support for the Component diagram, but it does support the other seven. One nice feature that both tools offer is a reverse-engineering feature, allowing you to generate the UML model and diagrams straight from the source code. This feature can be useful in many different ways.

If you're new to an existing project and you understand the UML diagrams, this allows you to learn the system design quite easily. If you're lazy and didn't document your project, you can generate quite a bit of documentation for your boss when she asks for all that documentation you promised.

A third option helps you understand how to create UML diagrams themselves. If you're constantly using the same pattern in your development and not sure how to document it in UML, code it and then see how the tool does it. In fact, the NetBeans IDE UML tool includes a whole set of predefined patterns, including those from the Gang of Four and many EJB technology-related tasks.

As you learn more about system design and development, be sure to pick up one of these tools to help you along the way. You won't be disappointed.

Once you've picked one, try to create a sequence diagram for the Edit Task operation previously described. You will soon see why it is best to use a tool for just such a task.