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 UMLWhy Use Analysis Mechanisms?Why Use Analysis Mechanisms?Oh no! I found a group of classes thathas persistent data. How am Isupposed to design these things if Idon’t even know what database we aregoing to be using?That is why we have a persistenceanalysis mechanism. We don’tknow enough yet, so we canbookmark it and come back to itlater.Analysis mechanisms are used during analysis to reduce the complexity ofanalysis and to improve its consistency by providing designers with ashorthand representation for complex behavior.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 22An analysis mechanism represents a pattern that constitutes a common solution to acommon problem. These mechanisms may show patterns of structure, patterns ofbehavior, or both. They are used during analysis to reduce the complexity of theanalysis, and to improve its consistency by providing designers with a shorthandrepresentation for complex behavior. Analysis mechanisms are primarily used as“placeholders” for complex technology in the middle and lower layers of thearchitecture. When mechanisms are used as “placeholders” in the architecture, thearchitecting effort is less likely to become distracted by the details of mechanismbehavior.Mechanisms allow the analysis effort to focus on translating the functionalrequirements into software concepts without bogging down in the specification ofrelatively complex behavior needed to support the functionality but which is notcentral to it. Analysis mechanisms often result from the instantiation of one or morearchitectural or analysis patterns.Persistence provides an example of analysis mechanisms. A persistent object is onethat logically exists beyond the scope of the program that created it. The need tohave object lifetimes that span use cases, process lifetimes, or system shutdown andstartup, defines the need for object persistence. Persistence is a particularly complexmechanism. During analysis we do not want to be distracted by the details of how weare going to achieve persistence. This gives rise to a “persistence” analysis mechanismthat allows us to speak of persistent objects and capture the requirements we willhave on the persistence mechanism without worrying about what exactly thepersistence mechanism will do or how it will work.Analysis mechanisms are typically, but not necessarily, unrelated to the problemdomain, but instead are "computer science" concepts. As a result, they typicallyoccupy the middle and lower layers of the architecture. They provide specificbehaviors to a domain-related class or component, or correspond to theimplementation of cooperation between classes and/or components.5 - 22
Module 5 - Architectural AnalysisSample Analysis MechanismsSample Analysis Mechanisms• Persistency• Communication (IPC and RPC)• Message routing• Distribution• Transaction management• Process control and synchronization (resourcecontention)• Information exchange, format conversion• Security• Error detection / handling / reporting• Redundancy• Legacy InterfaceMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 23Analysis mechanisms either provide specific behaviors to a domain-related class orcomponent, or they correspond to the implementation of cooperation betweenclasses and/or components.Some examples of analysis mechanisms are listed on this slide. This list is not meantto be exhaustive.Examples of communication mechanisms include inter-process communication (IPC)and inter-node communication (a.k.a. remote process communication or RPC). RPChas both a communication and a distribution aspect.Mechanisms are perhaps easier to discuss when one talks about them as “patterns”that are applied to the problem. So the inter-process communication pattern (that is,“the application is partitioned into a number of communicating processes”) interactswith the distribution pattern (that is, “the application is distributed across a number ofnodes”) to produce the RPC pattern (that is, “the application is partitioned into anumber of processes, which are distributed across a number of nodes”). This processprovides us a way to implement remote IPC.5 - 23
- 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 184 and 185: DEV475 Mastering Object-Oriented An
- Page 186 and 187: 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
- Page 234 and 235: DEV475 Mastering Object-Oriented An
- Page 236 and 237: 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>Why Use <strong>Analysis</strong> Mechanisms?Why Use <strong>Analysis</strong> Mechanisms?Oh no! I found a group of classes thathas persistent data. How am Isupposed to design these things if Idon’t even know what database we aregoing to be using?That is why we have a persistenceanalysis mechanism. We don’tknow enough yet, so we canbookmark it <strong>and</strong> come back to itlater.<strong>Analysis</strong> mechanisms are used during analysis to reduce the complexity ofanalysis <strong>and</strong> to improve its consistency by providing designers <strong>with</strong> ashorth<strong>and</strong> representation for complex behavior.<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 22An analysis mechanism represents a pattern that constitutes a common solution to acommon problem. These mechanisms may show patterns of structure, patterns ofbehavior, or both. They are used during analysis to reduce the complexity of theanalysis, <strong>and</strong> to improve its consistency by providing designers <strong>with</strong> a shorth<strong>and</strong>representation for complex behavior. <strong>Analysis</strong> mechanisms are primarily used as“placeholders” for complex technology in the middle <strong>and</strong> lower layers of thearchitecture. When mechanisms are used as “placeholders” in the architecture, thearchitecting effort is less likely to become distracted by the details of mechanismbehavior.Mechanisms allow the analysis effort to focus on translating the functionalrequirements into software concepts <strong>with</strong>out bogging down in the specification ofrelatively complex behavior needed to support the functionality but which is notcentral to it. <strong>Analysis</strong> mechanisms often result from the instantiation of one or morearchitectural or analysis patterns.Persistence provides an example of analysis mechanisms. A persistent object is onethat logically exists beyond the scope of the program that created it. The need tohave object lifetimes that span use cases, process lifetimes, or system shutdown <strong>and</strong>startup, defines the need for object persistence. Persistence is a particularly complexmechanism. During analysis we do not want to be distracted by the details of how weare going to achieve persistence. This gives rise to a “persistence” analysis mechanismthat allows us to speak of persistent objects <strong>and</strong> capture the requirements we willhave on the persistence mechanism <strong>with</strong>out worrying about what exactly thepersistence mechanism will do or how it will work.<strong>Analysis</strong> mechanisms are typically, but not necessarily, unrelated to the problemdomain, but instead are "computer science" concepts. As a result, they typicallyoccupy the middle <strong>and</strong> lower layers of the architecture. They provide specificbehaviors to a domain-related class or component, or correspond to theimplementation of cooperation between classes <strong>and</strong>/or components.5 - 22