Designing Using Uml (5 Steps)
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Designing Using Uml (5 Steps) as PDF for free.
More details
- Words: 1,205
- Pages: 14
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
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
Related Documents
Designing Using Uml (5 Steps)
April 2020 9
Uml Diagram Steps
April 2020 15
Uml 5
November 2019 2
Oo Sw Development Using Uml
May 2020 4
Business Modelling Using Uml V1
November 2019 12