Step 2 Process in Detail - Practices

Step 2: Process in Detail

In Step 2 of Five-Step UML, you need to step through all of the use cases that you documented in Step 1, and examine them to determine the various scenarios of each one. You can then define these scenarios using Activity Diagrams, showing what happens at each stage and how different paths may be found through the use case. If diagrams become too large, complex detail can be hidden in subactivity states.

Let’s look at this process in more detail.

Pick a Use Case

To get started, just select any use case from the Use Case List. There’s no particular order you need to follow, since you’ll analyze every use case eventually.

Find the Scenarios

To work out your scenarios, you can use interviews with the end users, requirements documents, and brainstorming techniques. Ask yourself what should happen in the use case, and what else could occur. Make a Scenario List with some likely scenarios for the chosen use case. When you have finished, select one scenario as the most common or most trouble free or most desirable. This will be your Primary Scenario for the chosen use case.

Draw the Happy Path

Create an Activity Diagram that depicts the Primary Scenario. Break the scenario down into the business rule steps that you understand at this stage. You’re not trying to completely design the solution for this use case yet; rather, you’re trying to verify that you understand the steps that will satisfy the requirements of the actors. If you feel like you’re practically writing code, you’re getting too detailed!

Draw the Exception Paths

For each activity in the diagram, think about what could go wrong. At this stage, don’t worry about implementation exceptions (e.g., “What happens if the hard drive fills up?”). Instead, worry about exceptions within the problem domain and the business rules (e.g., “What happens if the user isn’t authorized to use the system?”) Add a branch after each activity that might result in an exception; then add transitions, guard conditions, and activities to handle each exception. Also add merges to reflect the flow rejoining where appropriate.

At about this point, you should be very grateful if you’re using a modeling tool or Post-it notes, and very sorry if you’re using only paper and pencil. Rearranging hand-drawn diagrams is hard work, and it’s only going to get worse in Step 3.

Check off each scenario in the Scenario List for the chosen use case as you add it to the Activity Diagram. Repeat until you’re comfortable that you have addressed the major issues and scenarios in the chosen use case. (Don’t cross off unrealized scenarios: they may be too detailed for this scope, and you may still have to handle them when you get into implementation design.)

Look for Parallel Behavior

Examine the Activity Diagram. Are there any activities that must occur simultaneously? If so, add forks and joins and threads that encompass these activities as appropriate. Don’t add threads gratuitously—especially not during analysis!— but be sure that you have them where parallel behavior is required.

Consider Subactivity States and Additional Diagrams

If your diagram is getting complex, consider adding some subactivity states and some contained diagrams. In particular, if you have forks and joins and threads, consider moving the entire contents of each thread into a subactivity state that represents that thread. Like threads, don’t add subactivity states gratuitously: multiple diagrams add a comprehension burden that may be worse than one slightly complex diagram. Only add subactivity states where they simplify the message.

Repeat for Each Remaining Use Case

Check off the chosen use case in the Use Case List. Then pick another use case, and draw the Activity Diagram for that use case. Repeat until all major scenarios have been diagrammed for all use cases.

If you’re working through this process as an exercise, I recommend that you do at least two Activity Diagrams for practice, and more if you wish.

Example

As an example, Figure 2-9 is another Activity Diagram from the Kennel Management System, based on the Locate Pet use case discovered in Step 1.

Figure 2-9.  Activity Diagram for Locate Pet use case

---

TIP To learn more about developing Activity Diagrams, see Chapter 7.

---

>>> More Practices Articles          >>> More By Apress Publishing

blog comments powered by Disqus