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 UMLFind Classes from Use-Case BehaviorFind Classes from Use-Case Behavior• The complete behavior of a use case has tobe distributed to analysis classesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 12The technique for finding analysis classes described in this module uses threedifferent perspectives of the system to drive the identification of candidate classes.These three perspectives are:• The boundary between the system and its actors• The information the system uses• The control logic of the systemThe use of stereotypes to represent these perspectives (for example, boundary,control, and entity) results in a more robust model because they isolate those thingsmost likely to change in a system: the interface/environment, the control flow, andthe key system entities. These stereotypes are conveniences used during Analysis thatdisappear in Design.Identification of classes means just that: They should be identified, named, anddescribed briefly in a few sentences.The different stereotypes are discussed in more detail throughout this module.6 - 12
Module 6 - Use-Case AnalysisWhat Is an Analysis Class?What Is an Analysis Class?SystemboundarySysteminformationUse-casebehaviorcoordinationSystemboundarySysteminformationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 13Analysis classes represent an early conceptual model for “things in the system thathave responsibilities and behavior.” Analysis classes are used to capture a “first-draft”rough-cut of the Object Model of the system.Analysis classes handle primarily functional requirements. They model objects fromthe problem domain. Analysis classes can be used to represent "the objects we wantthe system to support" without making a decision about how much of them tosupport with hardware and how much with software.Three aspects of the system are likely to change:• The boundary between the system and its actors• The information the system uses• The control logic of the systemIn an effort to isolate the parts of the system that will change, the following types ofanalysis classes are identified with a “canned” set of responsibilities:• Boundary• Entity• ControlStereotypes may be defined for each type. These distinctions are used duringAnalysis, but disappear in Design.The different types of analysis classes can be represented using different icons or withthe name of the stereotype in guillemets (>): , , .Each of these types of analysis classes are discussed on the following slides.6 - 13
- 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 212 and 213: 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 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
- Page 262 and 263: DEV475 Mastering Object-Oriented An
- Page 264 and 265: DEV475 Mastering Object-Oriented An
- Page 266 and 267: DEV475 Mastering Object-Oriented An
- Page 268 and 269: DEV475 Mastering Object-Oriented An
Module 6 - Use-Case <strong>Analysis</strong>What Is an <strong>Analysis</strong> Class?What Is an <strong>Analysis</strong> Class?SystemboundarySysteminformationUse-casebehaviorcoordinationSystemboundarySysteminformation<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 13<strong>Analysis</strong> classes represent an early conceptual model for “things in the system thathave responsibilities <strong>and</strong> behavior.” <strong>Analysis</strong> classes are used to capture a “first-draft”rough-cut of the <strong>Object</strong> Model of the system.<strong>Analysis</strong> classes h<strong>and</strong>le primarily functional requirements. They model objects fromthe problem domain. <strong>Analysis</strong> classes can be used to represent "the objects we wantthe system to support" <strong>with</strong>out making a decision about how much of them tosupport <strong>with</strong> hardware <strong>and</strong> how much <strong>with</strong> software.Three aspects of the system are likely to change:• The boundary between the system <strong>and</strong> its actors• The information the system uses• The control logic of the systemIn an effort to isolate the parts of the system that will change, the following types ofanalysis classes are identified <strong>with</strong> a “canned” set of responsibilities:• Boundary• Entity• ControlStereotypes may be defined for each type. These distinctions are used during<strong>Analysis</strong>, but disappear in <strong>Design</strong>.The different types of analysis classes can be represented using different icons or <strong>with</strong>the name of the stereotype in guillemets (>): , , .Each of these types of analysis classes are discussed on the following slides.6 - 13