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 UMLExample: High-Level Organization of the ModelExample: High-Level Organization of the ModelApplicationBusiness ServicesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 18The above example includes the Application and Business-Specific layers for theCourse Registration System.The Application layer contains the design elements that are specific to the CourseRegistration application.We expect that multiple applications will share some key abstractions and commonservices. These have been encapsulated in the Business Services layer, which isaccessible to the Application layer. The Business Services layer contains businessspecificelements that are used in several applications, not necessarily just this one.5 - 18
Module 5 - Architectural AnalysisIdentify Analysis MechanismsArchitectural Analysis Steps• Key Concepts• Define the High-Level Organization ofSubsystems• Identify Analysis mechanisms• Identify Key Abstractions• Create Use-Case Realizations• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 19The architecture should be simple, but not simplistic. It should provide standardbehavior through standard abstractions and mechanisms. Thus, a key aspect indesigning a software architecture is the definition and the selection of themechanisms that designers use to give "life" to their objects.In Architectural Analysis, it is important to identify the analysis mechanisms for thesoftware system being developed. Analysis mechanisms focus on and address thenonfunctional requirements of the system (that is, the need for persistence, reliability,and performance), and builds support for such non-functional requirements directlyinto the architecture.Analysis mechanisms are used during analysis to reduce the complexity of analysis,and to improve its consistency by providing designers with a shorthand representationfor complex behavior. Mechanisms allow the analysis effort to focus on translating thefunctional requirements into software abstractions without becoming bogged down inthe specification of relatively complex behavior that is needed to support thefunctionality but which is not central to it.5 - 19
- 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
- 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 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 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
Module 5 - Architectural <strong>Analysis</strong>Identify <strong>Analysis</strong> MechanismsArchitectural <strong>Analysis</strong> Steps• Key Concepts• Define the High-Level Organization ofSubsystems• Identify <strong>Analysis</strong> mechanisms• Identify Key Abstractions• Create Use-Case Realizations• Checkpoints<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 19The architecture should be simple, but not simplistic. It should provide st<strong>and</strong>ardbehavior through st<strong>and</strong>ard abstractions <strong>and</strong> mechanisms. Thus, a key aspect indesigning a software architecture is the definition <strong>and</strong> the selection of themechanisms that designers use to give "life" to their objects.In Architectural <strong>Analysis</strong>, it is important to identify the analysis mechanisms for thesoftware system being developed. <strong>Analysis</strong> mechanisms focus on <strong>and</strong> address thenonfunctional requirements of the system (that is, the need for persistence, reliability,<strong>and</strong> performance), <strong>and</strong> builds support for such non-functional requirements directlyinto the architecture.<strong>Analysis</strong> mechanisms are used during analysis to reduce the complexity of analysis,<strong>and</strong> to improve its consistency by providing designers <strong>with</strong> a shorth<strong>and</strong> representationfor complex behavior. Mechanisms allow the analysis effort to focus on translating thefunctional requirements into software abstractions <strong>with</strong>out becoming bogged down inthe specification of relatively complex behavior that is needed to support thefunctionality but which is not central to it.5 - 19