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 UMLDescribing Analysis MechanismsDescribing Analysis Mechanisms• Collect all analysis mechanisms in a list• Draw a map of the client classes to theanalysis mechanisms• Identify characteristics of the analysismechanismsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 54In Architectural Analysis, the possible analysis mechanisms were identified anddefined.From that point on, as classes are defined, the required analysis mechanisms andanalysis mechanism characteristics should be identified and documented. Not allclasses will have mechanisms associated with them. Also, it is not uncommon for aclient class to require the services of several mechanisms.A mechanism has characteristics, and a client class uses a mechanism by qualifyingthese characteristics. This is to discriminate across a range of potential designs. Thesecharacteristics are part functionality, and part size and performance.6 - 54
Module 6 - Use-Case AnalysisExample: Describing Analysis MechanismsExample: Describing Analysis Mechanisms• Analysis class to analysis mechanism mapAnalysis ClassStudentScheduleCourseOfferingCourseRegistrationControllerAnalysis Mechanism(s)Persistency, SecurityPersistency, SecurityPersistency, Legacy InterfacePersistency, Legacy InterfaceDistributionMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 55As analysis classes are identified, it is important to identify the analysis mechanismsthat apply to the identified classes.The classes that must be persistent are mapped to the persistency mechanism.The classes that are maintained within the legacy Course Catalog system are mappedto the legacy interface mechanism.The classes for which access must be controlled (that is, control who is allowed toread and modify instances of the class) are mapped to the security mechanism.Note: The legacy interface classes do not require additional security as they are readonlyand are considered readable by all.The classes that are seen to be distributed are mapped to the distribution mechanism.The distribution identified during analysis is that which is specified/implied by theuser in the initial requirements. Distribution will be discussed in detail in theDescribe Distribution module. For now, just take it as an architectural given that allcontrol classes are distributed for the OOAD course example and exercise.6 - 55
- 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 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
- 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
- Page 270 and 271: DEV475 Mastering Object-Oriented An
- Page 272 and 273: DEV475 Mastering Object-Oriented An
- Page 274 and 275: DEV475 Mastering Object-Oriented An
- Page 276: 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>Describing <strong>Analysis</strong> MechanismsDescribing <strong>Analysis</strong> Mechanisms• Collect all analysis mechanisms in a list• Draw a map of the client classes to theanalysis mechanisms• Identify characteristics of the analysismechanisms<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 54In Architectural <strong>Analysis</strong>, the possible analysis mechanisms were identified <strong>and</strong>defined.From that point on, as classes are defined, the required analysis mechanisms <strong>and</strong>analysis mechanism characteristics should be identified <strong>and</strong> documented. Not allclasses will have mechanisms associated <strong>with</strong> them. Also, it is not uncommon for aclient class to require the services of several mechanisms.A mechanism has characteristics, <strong>and</strong> a client class uses a mechanism by qualifyingthese characteristics. This is to discriminate across a range of potential designs. Thesecharacteristics are part functionality, <strong>and</strong> part size <strong>and</strong> performance.6 - 54
Change language