Home arrow Practices arrow Page 6 - Five-Step UML: OOAD for Short Attention Spans - Define, Refine, Assign

Step 2 Process in Detail - Practices

This article introduces the concepts of Five-Step UML, working from beginning to end. It introduces UML notation and goes into great detail. This article covers the first three of five steps. It is from chapter 2 of UML Applied A .NET Perspective, written by Martin L. Shoemaker (Apress, 2004; ISBN: 1590590872).

TABLE OF CONTENTS:
  1. Five-Step UML: OOAD for Short Attention Spans - Define, Refine, Assign
  2. Do It Yourself UML
  3. Step 1: Define
  4. Step 1 Process in Detail
  5. Step 2: Refine
  6. Step 2 Process in Detail
  7. Step 3: Assign
  8. Step 3 Process in Detail
By: Apress Publishing
Rating: starstarstarstarstar / 21
July 28, 2005

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

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
escort Bursa Bursa escort Antalya eskort
   

PRACTICES ARTICLES

- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: