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 ...

crnarupa.singidunum.ac.rs
from crnarupa.singidunum.ac.rs More from this publisher
12.07.2015 Views

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

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!