Last Month

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