UML Weekend Crash Course⢠- To Parent Directory
UML Weekend Crash Course⢠- To Parent Directory UML Weekend Crash Course⢠- To Parent Directory
SESSION 8 Identifying the Use Case Scenarios Session Checklist ✔ Explaining the purpose and function of Use Case scenarios ✔ Finding Use Case scenarios for the case study ✔ Modeling the Use Case scenarios AUse Case identifies a primary goal of the system. When an actor attempts to accomplish a goal using the system, there are usually decisions and rules that could influence the outcome. Exception conditions may also hinder the accomplishment of the goal. Describing Use Case Scenarios Each possible outcome of an attempt to accomplish a Use Case goal is called a scenario. A scenario is a single logical path through a Use Case. You could call a scenario an instance of a Use Case in that a scenario is one realization, or execution, of the conceptual Use Case. In other words, a Use Case defines what could happen, whereas a scenario defines what does happen under a given set of conditions. The word scenario is used a number of ways. In the context of UML Use Cases, scenarios have a very specific meaning. Be careful not to confuse the Tip more general usage of the term scenario, as an example or situation, with the explicit definition used here. There are many ways to work with scenarios. You can simply read the narrative and extract each logic path from the text. Or you can draw out the logic with an Activity diagram so that the flow of logic can be visualized and more easily segmented. But whatever the means, the scenarios start to reveal the inner workings of the system and the expectations of the users in
82 Saturday Morning a way that the Use Case alone could not. This closer look will, as you’ll see in subsequent sessions, open doors to further analysis of the system and ultimately to the design. Probably the key lesson to learn here is the necessity of tackling the important questions and issues early, when you have the best chance to come up with the best possible solution. All too often, developers leave these questions until they’re working on the code, when many of the big issues are easily lost in the mountain of details and the requirements are expressed in a form that is alien to most users. Why you should care about Use Case scenarios In some situations, a Use Case is simple enough that the narrative is more than ample to explain all the issues that define its proper execution. But in many other Use Cases, the logic can become troublesome. Many of the applications we work on are complex and require significant scrutiny. That is one reason why the UML provides a whole set of tools rather than just one. In addition to addressing complexity, you need some way to test the accuracy and completeness of the Use Cases. Unfortunately, for many projects, developers often hold off testing until the end of the project, when they’re short on time and focused on the solution rather than the requirements. Or worse yet, there is no time for testing at all, so final tweaking happens in production. Speaking of requirements, did you know that the overwhelming majority of litigation regarding software projects is based on misunderstandings over requirements In a recent abstract regarding his participation in litigation over software projects, Capers Jones of Software Productivity Research had this to say: “The clients charge that the development group has failed to meet the terms of the contract and failed to deliver the software on time, fully operational, or with acceptable quality. The vendors charge that the clients have changed the terms of the agreement and expanded the original work requirements.” Furthermore, the problems that Mr. Jones refers to here are on projects where there is a contract. Consider how much worse the situation can become where the requirements process is less formal! If you’ve ever worked in a quality-assurance group, or even worked with one, you know how frustrating the tester’s role can be. Think about how the tester’s challenge changes when she’s able to create a test plan at the beginning of the project instead of waiting until the end. Then testing can take place in small increments throughout the project, instead of in a massive, difficult, and frustrating process at the end (if there is time to test at all). This is why scenarios have taken on an increasingly important role in the requirements phase. But what happened to other tools like screen layouts and prototypes They are still valuable, and in some cases provide a great way for users to visualize what you are trying to express in words and diagrams. The challenge is that the layouts themselves don’t explain how they’ll be used and why. Another liability with prototypes is that they give the false impression that the application is nearly complete. This makes sense because the user only works with the interface. To users, the interface is the application. But you know that there is a lot more to it, including
- Page 52 and 53: Session 3—How to Approach the UML
- Page 54 and 55: Session 3—How to Approach the UML
- Page 56: Session 3—How to Approach the UML
- Page 59 and 60: 36 Friday Evening Remember to pay c
- Page 61 and 62: 38 Friday Evening Constraints The s
- Page 63 and 64: 40 Friday Evening An Inventory Cont
- Page 65 and 66: 42 Friday Evening Performance How
- Page 67 and 68: 44 Friday Evening In the effort to
- Page 70 and 71: Part II — Saturday Morning Sessio
- Page 72 and 73: SESSION 5 Understanding the Use Cas
- Page 74 and 75: Session 5—Understanding the Use C
- Page 76 and 77: Session 5—Understanding the Use C
- Page 78 and 79: Session 5—Understanding the Use C
- Page 80 and 81: Session 5—Understanding the Use C
- Page 82: Session 5—Understanding the Use C
- Page 85 and 86: 62 Saturday Morning Order Fulfillme
- Page 87 and 88: 64 Saturday Morning What does the
- Page 89 and 90: 66 Saturday Morning For example, th
- Page 91 and 92: 68 Saturday Morning REVIEW The goal
- Page 93 and 94: 70 Saturday Morning Much of this la
- Page 95 and 96: 72 Saturday Morning You reply that
- Page 97 and 98: 74 Saturday Morning Writing a Use C
- Page 99 and 100: 76 Saturday Morning Use Case dialog
- Page 101 and 102: 78 Saturday Morning Table 7-7 The F
- Page 106 and 107: Session 8—Identifying the Use Cas
- Page 108 and 109: Session 8—Identifying the Use Cas
- Page 110 and 111: Session 8—Identifying the Use Cas
- Page 112 and 113: Session 8—Identifying the Use Cas
- Page 114: Session 8—Identifying the Use Cas
- Page 117 and 118: 94 Saturday Morning The Class diagr
- Page 119 and 120: 96 Saturday Morning Attribute visib
- Page 121 and 122: 98 Saturday Morning In a modeling t
- Page 123 and 124: 100 Saturday Morning Table 9-2 Cont
- Page 125 and 126: 102 Saturday Morning Operation comp
- Page 128 and 129: SESSION 10 The Class Diagram: Assoc
- Page 130 and 131: Session 10—The Class Diagram: Ass
- Page 132 and 133: Session 10—The Class Diagram: Ass
- Page 134 and 135: Session 10—The Class Diagram: Ass
- Page 136 and 137: Session 10—The Class Diagram: Ass
- Page 138 and 139: Part II — Saturday Morning Part R
- Page 140 and 141: SESSION 11 The Class Diagram: Aggre
- Page 142 and 143: Session 11—The Class Diagram: Agg
- Page 144 and 145: Session 11—The Class Diagram: Agg
- Page 146 and 147: Session 11—The Class Diagram: Agg
- Page 148 and 149: Session 11—The Class Diagram: Agg
- Page 150: Session 11—The Class Diagram: Agg
SESSION<br />
8<br />
Identifying the Use Case Scenarios<br />
Session Checklist<br />
✔ Explaining the purpose and function of Use Case scenarios<br />
✔ Finding Use Case scenarios for the case study<br />
✔ Modeling the Use Case scenarios<br />
AUse Case identifies a primary goal of the system. When an actor attempts to accomplish<br />
a goal using the system, there are usually decisions and rules that could influence the<br />
outcome. Exception conditions may also hinder the accomplishment of the goal.<br />
Describing Use Case Scenarios<br />
Each possible outcome of an attempt to accomplish a Use Case goal is called a scenario. A<br />
scenario is a single logical path through a Use Case. You could call a scenario an instance of<br />
a Use Case in that a scenario is one realization, or execution, of the conceptual Use Case. In<br />
other words, a Use Case defines what could happen, whereas a scenario defines what does<br />
happen under a given set of conditions.<br />
The word scenario is used a number of ways. In the context of <strong>UML</strong> Use<br />
Cases, scenarios have a very specific meaning. Be careful not to confuse the<br />
Tip more general usage of the term scenario, as an example or situation, with<br />
the explicit definition used here.<br />
There are many ways to work with scenarios. You can simply read the narrative and extract<br />
each logic path from the text. Or you can draw out the logic with an Activity diagram so that<br />
the flow of logic can be visualized and more easily segmented. But whatever the means, the<br />
scenarios start to reveal the inner workings of the system and the expectations of the users in
Change language