The Importance of Unified Modeling Language (UML) 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 like "Create Task" and "Generate Report". They are meant to specify a sequence of actions for the system to perform as observed by an actor (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 sub-parts of the use case to different team members, allowing work to be done in parallel. In addition, this breaking the use cases down allows you to attach quantifiable measures if the tasks have requirements for things like response time. Had this Todo List manager application been required to run on a telephone with Java FX Mobile, how does the Edit Task action react when a phone call comes in? Additionally, when defining use cases, it is best to identify test cases, too. For a single user Todo List application, the Edit Task use case is relatively easy. But, when you have a multi-user environment, the use case can have a test case for handling multiple users. By defining the appropriate response up front, before development has started, coding becomes that much easier because you already know how the system should respond for 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 where the actor is literally a stick figure. As you start to learn about the different diagrams, it is helpful to have a tool to help. Two popularly available open source options are the NetBeans 5.5 UML Modeling pack plugin and ArgoUML available through CollabNet. These tools use something called UML, short for Unified Modeling Language, to document a system's model. The OMG standard offers a common way for system modeling so that everyone doesn't have their own way of doing things. The process began a little over ten 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 up the adoption of object-oriented technologies. While Linux was about 5 years old at the time, the open source movement and all its associated sharing was not that popular at the time. While the latest UML release, 2.0, defines 13 types of diagrams, most tools don't support them all. The NetBeans UML Modeling tool allows you to create a Use Case diagram and seven others: 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 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), it 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 UML tool includes a whole set of predefined patterns, including those from the Gang of Four and many EJB 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. | 
