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 Analysis OverviewUse-Case Analysis OverviewGlossaryProject SpecificGuidelinesSoftwareArchitectureDocumentUse-Case RealizationSupplementarySpecificationsUse-CaseAnalysisAnalysis ModelUse-Case ModelAnalysis ClassesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 4Use-Case Analysis is performed by the designer, once per iteration per Use-CaseRealization. What event flows, and therefore what Use-Case Realizations you aregoing to work on during the current iteration are defined prior to the start of Use-Case Analysis in Architectural Analysis.Purpose• To identify the classes that perform a use case’s flow of events• To distribute the use case behavior to those classes, using Use-Case Realizations• To identify the responsibilities, attributes and associations of the classes• To note the usage of architectural mechanismsInput Artifacts• Glossary• Supplementary Specifications• Use-Case• Use-Case Model• Use-Case Realization• Software Architecture Document• Analysis Class• Analysis Model• Project Specific GuidelinesResulting Artifacts• Analysis Classes• Analysis Model• Use-Case RealizationsNote: We will not be developing a separate Analysis Model in this course.6 - 4
Module 6 - Use-Case AnalysisUse-Case Analysis StepsUse-Case Analysis Steps• Supplement the Use-Case Description• For each Use-Case Realization• Find Classes from Use-Case Behavior• Distribute Use-Case Behavior to Classes• For each resulting analysis class• Describe Responsibilities• Describe Attributes and Associations• Qualify Analysis Mechanisms• Unify Analysis Classes• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 5The above are the major steps of the Use-Case Analysis activity.First we must review the use-case descriptions developed in the Requirementsdiscipline. Chances are, they will need some enhancements to include enough detailto begin developing a model.Next, we study the use-case flow of events, identify analysis classes, and allocate usecaseresponsibilities to the analysis classes. Based on these allocations, and theanalysis class collaborations, we can begin to model the relationships between theidentified analysis classes.Once the use case has been analyzed, we need to take a good look at the identifiedclasses, making sure they are thoroughly documented and identify which analysis andmechanisms they implement.Last, but not least, we need to make sure that our developed Analysis Model isconsistent.6 - 5
- 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
- Page 178 and 179: DEV475 Mastering Object-Oriented An
- Page 180 and 181: DEV475 Mastering Object-Oriented An
- Page 182 and 183: DEV475 Mastering Object-Oriented An
- Page 184 and 185: DEV475 Mastering Object-Oriented An
- Page 186 and 187: DEV475 Mastering Object-Oriented An
- Page 188 and 189: DEV475 Mastering Object-Oriented An
- Page 190 and 191: DEV475 Mastering Object-Oriented An
- Page 192 and 193: DEV475 Mastering Object-Oriented An
- Page 194 and 195: DEV475 Mastering Object-Oriented An
- Page 196 and 197: DEV475 Mastering Object-Oriented An
- Page 198 and 199: DEV475 Mastering Object-Oriented An
- Page 200 and 201: DEV475 Mastering Object-Oriented An
- Page 202 and 203: DEV475 Mastering Object-Oriented An
- Page 204 and 205: DEV475 Mastering Object-Oriented An
- Page 206 and 207: DEV475 Mastering Object-Oriented An
- Page 208 and 209: DEV475 Mastering Object-Oriented An
- Page 210 and 211: DEV475 Mastering Object-Oriented An
- Page 214 and 215: DEV475 Mastering Object-Oriented An
- Page 216 and 217: DEV475 Mastering Object-Oriented An
- Page 218 and 219: DEV475 Mastering Object-Oriented An
- Page 220 and 221: DEV475 Mastering Object-Oriented An
- Page 222 and 223: DEV475 Mastering Object-Oriented An
- Page 224 and 225: DEV475 Mastering Object-Oriented An
- Page 226 and 227: DEV475 Mastering Object-Oriented An
- Page 228 and 229: DEV475 Mastering Object-Oriented An
- Page 230 and 231: DEV475 Mastering Object-Oriented An
- Page 232 and 233: DEV475 Mastering Object-Oriented An
- Page 234 and 235: DEV475 Mastering Object-Oriented An
- Page 236 and 237: DEV475 Mastering Object-Oriented An
- Page 238 and 239: DEV475 Mastering Object-Oriented An
- Page 240 and 241: DEV475 Mastering Object-Oriented An
- Page 242 and 243: DEV475 Mastering Object-Oriented An
- Page 244 and 245: DEV475 Mastering Object-Oriented An
- Page 246 and 247: DEV475 Mastering Object-Oriented An
- Page 248 and 249: DEV475 Mastering Object-Oriented An
- Page 250 and 251: DEV475 Mastering Object-Oriented An
- Page 252 and 253: DEV475 Mastering Object-Oriented An
- Page 254 and 255: DEV475 Mastering Object-Oriented An
- Page 256 and 257: DEV475 Mastering Object-Oriented An
- Page 258 and 259: DEV475 Mastering Object-Oriented An
- Page 260 and 261: 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 <strong>Analysis</strong> OverviewUse-Case <strong>Analysis</strong> OverviewGlossaryProject SpecificGuidelinesSoftwareArchitectureDocumentUse-Case RealizationSupplementarySpecificationsUse-Case<strong>Analysis</strong><strong>Analysis</strong> ModelUse-Case Model<strong>Analysis</strong> Classes<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 4Use-Case <strong>Analysis</strong> is performed by the designer, once per iteration per Use-CaseRealization. What event flows, <strong>and</strong> therefore what Use-Case Realizations you aregoing to work on during the current iteration are defined prior to the start of Use-Case <strong>Analysis</strong> in Architectural <strong>Analysis</strong>.Purpose• To identify the classes that perform a use case’s flow of events• To distribute the use case behavior to those classes, using Use-Case Realizations• To identify the responsibilities, attributes <strong>and</strong> associations of the classes• To note the usage of architectural mechanismsInput Artifacts• Glossary• Supplementary Specifications• Use-Case• Use-Case Model• Use-Case Realization• Software Architecture Document• <strong>Analysis</strong> Class• <strong>Analysis</strong> Model• Project Specific GuidelinesResulting Artifacts• <strong>Analysis</strong> Classes• <strong>Analysis</strong> Model• Use-Case RealizationsNote: We will not be developing a separate <strong>Analysis</strong> Model in this course.6 - 4