V M Gunda

The Five Steps are as follows:

◦ Define. Identify the requirements of your system via Use Case Diagrams. Add other diagrams where they shed light on the use cases.

◦ Refine. Detail the steps in each requirement via scenarios captured in Activity Diagrams. Add other diagrams where they shed light on the activities.

◦ Assign. Use the Activity Diagrams to assign the steps to elements of your system.

◦ Design. Show the relations among the elements with Component Diagrams. Add other diagrams where they shed light on the components.

◦ Repeat/iterate/drill down/divide and conquer. Narrow the scope of your process to individual elements (designed with Class Diagrams); or expand it out to whole systems (designed with Deployment Diagrams). Add other diagrams wherever they help you understand the system. Repeat Steps 1 through 4 as appropriate for the current scope. Like Boehm's Spiral development process, Evolutionary Development, and many other modern processes, Five-Step UML is an incremental, recursive approach.

Identify of your system via Use Case Diagrams, Add other Diagrams where they shed light on the use cases.

UML Diagram: Use Case Diagram Process in Detail

◦ Identify the actors and domain objects ◦ Each Actor your have identified, you should list all the use

cases initiated by actor◦ Domain objects should depict the real-world entities, not

their software representations◦ Identify Requirements for the Actor: Document the actor's

requirements as use cases in a Use Case Diagram for the chosen actor

◦ Identify Participating Actors: For each use case for the chosen actor, identify any new or existing actors that also participate in the use case. Add any new actors to the Actor List.

◦ Pick a Domain Object

◦ Identify Requirements That Relate to the Domain Object: Determine which use cases affect that domain object, and add them to the diagram. Then add the communications from the use cases to the object, and label the communications to describe the changes made by the use cases. Then add the actors that initiate each use case. (Don't add other participating actors, because the diagram will likely become too cluttered.)

Detail the steps in each requirement via scenarios captured in Activity Diagrams. Add other diagrams where they shed light on the activities

The Primary and Alternate Scenarios shall be captured in an Activity Diagram

An Activity Diagram is a way of depicting a set of steps of operation within your system, and is often attached to a use case (as you'll do in Five-Step UML).

UML Notation: Activity Diagram

Pick a Use Case Find the Scenarios 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. ◦ Note: 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 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.

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 Sub activity States and Additional Diagrams: ◦ If your diagram is getting complex, consider adding some sub

activity states and some contained diagrams

Repeat for Each Remaining Use Case

Use the Activity Diagrams to assign the steps to elements of your system.◦ In this step, you'll assign your activities (from the previous step) to elements of

your system◦ Assume that the elements in this case shall be components, interfaces exposed

by those components, and user interfaces provided by those components.

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 swim lanes (please see the notes) 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.

UML Notation: Swim Lanes

Pick an Activity Diagram

Look at the Initial State◦ 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.

if the activity doesn't seem to "belong" to any existing actor or interface, add a new interface that is responsible for it

For a New Actor or Interface or User Interface, Add a Swim lane◦ If the actor or interface has not been used in the current Activity

Diagram before, add a swim lane for it.

Drag the Activity into the Swim lane

Update All Transitions to Keep the Activity Diagram Intact

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

Search for Implicit Requirements and Back-End Activities

Consider Sub activity States and Additional Diagrams

Repeat for Each Activity Diagram

Show the relations among the elements with Component Diagrams. Add other diagrams where they shed light on the components

In this step, you'll assign the interfaces and user interfaces discovered in Step 3 to components, and then show the relationships between components and interfaces in Component Diagrams. You'll try to identify existing components and interfaces that can be reused, along with new components that will support the new interfaces.

UML Notation: Component Diagram, Interfaces

Pick an Interface

Assign the Interface to a Component

Repeat for Each Interface

From the Activity Diagrams, Identify Dependencies

Narrow the scope of your process to individual elements (designed with Class Diagrams). Add other diagrams where they help you understand the system. Repeat Steps 1 through 4 as appropriate for the current scope.

In this step, you'll narrow your scope to look at a single component (as identified in Step 4). By zooming in to the scope of the component, you can apply the same analysis and design processes to determine the structure of the component

UML Notation: Class Diagram

UML Applied: A .NET Perspective◦ by Martin L. Shoemaker