DEV475 Mastering Object-Oriented Analysis and Design with UML ...
DEV475 Mastering Object-Oriented Analysis and Design with UML ... DEV475 Mastering Object-Oriented Analysis and Design with UML ...
DEV475 Mastering Object-Oriented Analysis and Design with UMLUse-Case SpecificationsUse-Case Specifications• Name• Brief description• Flow of Events• Relationships• Activity diagrams• Use-Case diagrams• Specialrequirements• Pre-conditions• Post-conditions• Other diagramsUse-Case ModelActorsUse Cases...Use-Case SpecificationsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 14The use case has a set of properties as shown in the graphic. The use-case propertiesmay be documented in use-case specifications, which can include the items listedbelow:• Brief description describes the role and purpose of the use case.• Flow of events are textual descriptions of what the system does with regard tothe use case. There can be multiple flows of events — for example, a basic flowand alternative flows.• Relationships are communicates-associations. The use case includes and extendsrelationships that the use case participates in.• Activity diagrams can be used to illustrate the structure of the flow of events.• Use-case diagrams can be used to show the relationships involving the use case.• Special requirements is a textual description that collects all use-caserequirements, like nonfunctional requirements, that are not considered in theUse-Case Model, yet need to be taken care of during design or implementation.• Pre-conditions define a constraint on the system regarding when the use casemay start.• Post-conditions define a constraint on the system that applies after the use casehas terminated.• Other diagrams can be used to illustrate the use case, like hand-drawn sketchesor screen captures from an user-interface prototype.3 - 14
Module 3 - Requirements OverviewUse-Case Flow of EventsUse-Case Flow of Events• Has one normal, basic flow• Several alternative flows• Regular variants• Odd cases• Exceptional flows for handling error situationsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 15A use case flow of events:• Contains the most important information derived from use-case modeling work.• Should describe the use case's flow clearly enough for an outsider to easilyunderstand it.• Should present what the system does, not how the system is designed to performthe required behavior.Guidelines for the flow of events. Specify that the content must:• Detail the flow of events. All "what“ questions should be answered. Rememberthat test designers will use this text to identify test cases.• Describe how the use case starts and ends.• Describe the flow of events, not only the functionality. To reinforce this, startevery action with "When the actor. . . .”• Describe only the events that belong to the use case and not what happens inother use cases or outside of the system.• Describe the data exchanged between the actor and the use case.• Avoid describing the details of the user interface unless they are needed toprovide an understanding the behavior of the system.• Avoid vague terminology such as "for example", "etc.," and "information."3 - 15
- Page 78 and 79: DEV475 Mastering Object-Oriented An
- Page 80 and 81: DEV475 Mastering Object-Oriented An
- Page 82 and 83: DEV475 Mastering Object-Oriented An
- Page 84 and 85: DEV475 Mastering Object-Oriented An
- Page 86 and 87: DEV475 Mastering Object-Oriented An
- Page 88 and 89: DEV475 Mastering Object-Oriented An
- Page 90 and 91: DEV475 Mastering Object-Oriented An
- Page 92 and 93: DEV475 Mastering Object-Oriented An
- Page 94 and 95: DEV475 Mastering Object-Oriented An
- Page 96 and 97: DEV475 Mastering Object-Oriented An
- Page 98 and 99: DEV475 Mastering Object-Oriented An
- Page 100 and 101: DEV475 Mastering Object-Oriented An
- Page 102 and 103: DEV475 Mastering Object-Oriented An
- Page 104 and 105: DEV475 Mastering Object-Oriented An
- Page 106 and 107: DEV475 Mastering Object-Oriented An
- Page 108 and 109: DEV475 Mastering Object-Oriented An
- Page 110 and 111: DEV475 Mastering Object-Oriented An
- Page 112 and 113: DEV475 Mastering Object-Oriented An
- Page 114 and 115: DEV475 Mastering Object-Oriented An
- Page 116 and 117: DEV475 Mastering Object-Oriented An
- Page 118 and 119: DEV475 Mastering Object-Oriented An
- Page 120 and 121: DEV475 Mastering Object-Oriented An
- Page 122 and 123: DEV475 Mastering Object-Oriented An
- Page 124 and 125: DEV475 Mastering Object-Oriented An
- Page 126 and 127: DEV475 Mastering Object-Oriented An
- Page 130 and 131: DEV475 Mastering Object-Oriented An
- Page 132 and 133: DEV475 Mastering Object-Oriented An
- Page 134 and 135: DEV475 Mastering Object-Oriented An
- Page 136 and 137: DEV475 Mastering Object-Oriented An
- Page 138 and 139: DEV475 Mastering Object-Oriented An
- Page 140 and 141: DEV475 Mastering Object-Oriented An
- Page 142 and 143: DEV475 Mastering Object-Oriented An
- Page 144 and 145: DEV475 Mastering Object-Oriented An
- Page 146 and 147: DEV475 Mastering Object-Oriented An
- Page 148 and 149: DEV475 Mastering Object-Oriented An
- Page 150 and 151: DEV475 Mastering Object-Oriented An
- Page 152 and 153: DEV475 Mastering Object-Oriented An
- Page 154 and 155: DEV475 Mastering Object-Oriented An
- Page 156 and 157: DEV475 Mastering Object-Oriented An
- Page 158 and 159: DEV475 Mastering Object-Oriented An
- Page 160 and 161: DEV475 Mastering Object-Oriented An
- Page 162 and 163: DEV475 Mastering Object-Oriented An
- Page 164 and 165: DEV475 Mastering Object-Oriented An
- Page 166 and 167: DEV475 Mastering Object-Oriented An
- Page 168 and 169: DEV475 Mastering Object-Oriented An
- Page 170 and 171: DEV475 Mastering Object-Oriented An
- Page 172 and 173: DEV475 Mastering Object-Oriented An
- Page 174 and 175: DEV475 Mastering Object-Oriented An
- Page 176 and 177: DEV475 Mastering Object-Oriented An
<strong>DEV475</strong> <strong>Mastering</strong> <strong>Object</strong>-<strong>Oriented</strong> <strong>Analysis</strong> <strong>and</strong> <strong>Design</strong> <strong>with</strong> <strong>UML</strong>Use-Case SpecificationsUse-Case Specifications• Name• Brief description• Flow of Events• Relationships• Activity diagrams• Use-Case diagrams• Specialrequirements• Pre-conditions• Post-conditions• Other diagramsUse-Case ModelActorsUse Cases...Use-Case Specifications<strong>Mastering</strong> <strong>Object</strong> <strong>Oriented</strong> <strong>Analysis</strong> <strong>and</strong> <strong>Design</strong> <strong>with</strong> <strong>UML</strong>Copyright © 2003 Rational Software, all rights reserved 14The use case has a set of properties as shown in the graphic. The use-case propertiesmay be documented in use-case specifications, which can include the items listedbelow:• Brief description describes the role <strong>and</strong> purpose of the use case.• Flow of events are textual descriptions of what the system does <strong>with</strong> regard tothe use case. There can be multiple flows of events — for example, a basic flow<strong>and</strong> alternative flows.• Relationships are communicates-associations. The use case includes <strong>and</strong> extendsrelationships that the use case participates in.• Activity diagrams can be used to illustrate the structure of the flow of events.• Use-case diagrams can be used to show the relationships involving the use case.• Special requirements is a textual description that collects all use-caserequirements, like nonfunctional requirements, that are not considered in theUse-Case Model, yet need to be taken care of during design or implementation.• Pre-conditions define a constraint on the system regarding when the use casemay start.• Post-conditions define a constraint on the system that applies after the use casehas terminated.• Other diagrams can be used to illustrate the use case, like h<strong>and</strong>-drawn sketchesor screen captures from an user-interface prototype.3 - 14