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 UMLObjectives: Architectural AnalysisObjectives: Architectural Analysis• Explain the purpose of Architectural Analysisand where it is performed in the lifecycle.• Describe a representative architectural patternand set of analysis mechanisms, and how theyaffect the architecture.• Describe the rationale and considerations thatsupport the architectural decisions.• Show how to read and interpret the results ofArchitectural Analysis:• Architectural layers and their relationships• Key abstractions• Analysis mechanismsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 2A focus on software architecture allows you to articulate the structure of the softwaresystem (the packages/components), and the ways in which they integrate (thefundamental mechanisms and patterns by which they interact).Architectural Analysis is where we make an initial attempt at defining thepieces/parts of the system and their relationships, organizing these pieces/parts intowell-defined layers with explicit dependencies, concentrating on the upper layers ofthe system. This will be refined, and the lower layers will be defined duringIncorporate Existing Design Elements.5 - 2
Module 5 - Architectural AnalysisArchitectural Analysis in ContextArchitectural Analysis in Context[EarlyElaborationIteration][InceptionIteration (Optional)]ArchitectureAnalysisArchitectDefine a CandidateArchitecturePerformArchitecturalSynthesisAnalyze BehaviorRefine theArchitecture(Optional)DefineComponentsDesign theDatabaseMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 3As you may recall, the above diagram illustrates the workflow that we are using in thiscourse. It is a tailored version of the Analysis and Design core workflow of theRational Unified Process. Architectural Analysis is an activity in the Define aCandidate Architecture workflow detail.Architectural Analysis is how the project team (or the architect) decides to definethe project’s high-level architecture. It is focused mostly on bounding the analysiseffort in terms of agreed-upon architectural patterns and idioms, so that the “analysis”work is not working so much from “first principles.” Architectural Analysis is verymuch a configuring of Use-Case Analysis.During Architectural Analysis, we concentrate on the upper layers of the system,making an initial attempt at defining the pieces/parts of the system and theirrelationships and organizing these pieces/parts into well-defined layers with explicitdependencies.In Use-Case Analysis, we will expand on this architecture by identifying analysisclasses from the requirements. Then, in Incorporate Existing Design Elements, theinitial architecture is refined, and the lower architecture layers are defined, takinginto account the implementation environment and any other implementationconstraints.Architectural Analysis is usually done once per project, early in the Elaborationphase. The activity is performed by the software architect or architecture team.This activity can be skipped if the architectural risk is low.5 - 3
- 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 128 and 129: 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 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
Module 5 - Architectural <strong>Analysis</strong>Architectural <strong>Analysis</strong> in ContextArchitectural <strong>Analysis</strong> in Context[EarlyElaborationIteration][InceptionIteration (Optional)]Architecture<strong>Analysis</strong>ArchitectDefine a C<strong>and</strong>idateArchitecturePerformArchitecturalSynthesisAnalyze BehaviorRefine theArchitecture(Optional)DefineComponents<strong>Design</strong> theDatabase<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 3As you may recall, the above diagram illustrates the workflow that we are using in thiscourse. It is a tailored version of the <strong>Analysis</strong> <strong>and</strong> <strong>Design</strong> core workflow of theRational Unified Process. Architectural <strong>Analysis</strong> is an activity in the Define aC<strong>and</strong>idate Architecture workflow detail.Architectural <strong>Analysis</strong> is how the project team (or the architect) decides to definethe project’s high-level architecture. It is focused mostly on bounding the analysiseffort in terms of agreed-upon architectural patterns <strong>and</strong> idioms, so that the “analysis”work is not working so much from “first principles.” Architectural <strong>Analysis</strong> is verymuch a configuring of Use-Case <strong>Analysis</strong>.During Architectural <strong>Analysis</strong>, we concentrate on the upper layers of the system,making an initial attempt at defining the pieces/parts of the system <strong>and</strong> theirrelationships <strong>and</strong> organizing these pieces/parts into well-defined layers <strong>with</strong> explicitdependencies.In Use-Case <strong>Analysis</strong>, we will exp<strong>and</strong> on this architecture by identifying analysisclasses from the requirements. Then, in Incorporate Existing <strong>Design</strong> Elements, theinitial architecture is refined, <strong>and</strong> the lower architecture layers are defined, takinginto account the implementation environment <strong>and</strong> any other implementationconstraints.Architectural <strong>Analysis</strong> is usually done once per project, early in the Elaborationphase. The activity is performed by the software architect or architecture team.This activity can be skipped if the architectural risk is low.5 - 3