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

Step 3 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 3: Process in Detail

The Activity Diagrams that you created in Step 2 serve as your starting point. In Step 3 of Five-Step UML, you need to work through these diagrams, adding swimlanes to each of them. The best place to start is with the actor that initiates the use case, and then you can look at every activity in turn and think about what part of your system should be responsible for it.

Letís have a look at this process in more detail.

Pick an Activity Diagram

You need to start somewhere, so pick an Activity Diagram. Go for a simple one first off, particularly if youíre trying to get some practice. You can work on more complicated diagrams later.

Look at the Initial State

Add a swimlane for the actor that requested the corresponding use case. Drag the initial and terminal states into that swimlane. (Here is where youíll really appreciate a modeling tool or Post-it notes.) Or perhaps youíll want to preserve the original diagram and re-create it with swimlanes.

Look at the First Activity

Look at the first activity and try to figure out which existing actor or interface should be responsible for that activity. If itís an activity performed by an actor, the actor is responsible. If itís an activity performed directly in response to an actor (such as processing user input or responding to a timer or receiving a message), an interface for the corresponding actor is responsible. If itís a query to a database, a database interface is responsible. If itís a call to an existing interface, that interface is responsible. And if the activity doesnít seem to ďbelongĒ to any existing actor or interface, add a new interface that is responsible for it, as described in the next part of this exercise.

When adding interfaces, think in terms of high-level groups of services that together form a useful set of services.

For a New Actor or Interface or User Interface, Add a Swimlane

If the actor or interface has not been used in the current Activity Diagram before, add a swimlane for it. If the new element is a heretofore-undiscovered actor, add it to the Actor List. If the new element is a heretofore-undiscovered interface, add it to an Interface List. (You may find it convenient to maintain this Interface List as an evolving Component Diagram. Weíll see more about Component Diagrams later on in this chapter.) Brainstorm about the purpose of the new interface and what sort of other operations it might support.

Drag the Activity into the Swimlane

Now that you have identified the correct swimlane, drag the activity into it. If the swimlane represents an interface, add the activity to the interface (in the Interface List) as a required operation. If the swimlane represents a user interface, add the activity to the user interface (in the User Interface List) as a required operation.

Update All Transitions to Keep the Activity Diagram Intact

If youíre drawing the diagrams by hand, youíll have to correct the transitions to and from the activity that you moved. Consider adding new activities and using the ęinvokeĽ and ęinterruptĽ transitions where appropriate.

Repeat for All Branches, Merges, Activities, Forks, and Joins in the Diagram

Continue revising and adding swimlanes until each element of the diagram has been assigned to a swimlane. Rearrange the swimlanes and activities until youíre comfortable with the assignment of responsibilities. Make sure you keep all interface icons, class icons, and node icons up to date with these changes.

Search for Implicit Requirements and Back-End Activities

Look at your architectural assignments, and see whatís missing. Have implicit requirements been revealed? Have you found back-end activities that are needed? Add the new activities, along with swimlanes for interfaces to support them.

Consider Subactivity States and Additional Diagrams

As in Step 2, consider adding subactivity states and contained diagrams where they simplify the message.

Repeat for Each Activity Diagram

Add swimlanes to each of the remaining Activity Diagrams. Reuse interfaces where appropriate, but try to keep each interface cohesive. Donít assign an activity to a given interface unless it fits the overall purpose of the interface.

If youíre working through this process as an exercise, then I recommend that you add swimlanes to at least two Activity Diagrams for practice, and more if you wish.

Example

As an example, Figure 2-15 is the Activity Diagram for the Locate Pet use case (shown in Figure 2-9), with an initial swimlane for the actor added.


Figure 2-15.  Activity Diagram for Locate Pet use case (with Swimlanes)

To add further structure to this, we can add activities that reflect the Pet Owner controlling the process, and we can add support interfaces to carry out back-end services. This is shown in Figure 2-16.

There are a few interesting things to note on this diagram:

I rearranged some of the flow, so that if the pet name is wrong, we simply display an error message. Itís up to the pet owner to reenter the name. Nothing in the application forces the pet owner to do so.

Note that the Call for Pet activity uses the Fetch Pet activity of the Care Giver swimlane (corresponding to the Care Giver actor). It does so via an ęinvokeĽ transition to the Call for Pet activity of the Care Giver UI, which then instructs the Care Giver to fetch the pet. This diagram doesnít indicate the mechanism behind this asynchronous UI request. It might be a pager, it might be a pop-up message, it might be electrodes implanted in the care giverís brain, but you canít tell from this diagram. That is an implementation issue for the Care Giver UI.


Figure 2-16.  Activity Diagram for Locate Pet use case (interfaces added)

Next, letís turn the preceding diagram into an architectural diagram by wrapping the business rules in subactivity states, as shown in Figure 2-17.


Figure 2-17.  Activity Diagram for Locate Pet use case (architectural view)


TIP: For more on swimlanes, architecture, and interface design, see Chapter 8.

 

Step 4: Design and Step 5: Repeat will appear next week.



 
 
>>> 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: