20551系統(tǒng)分析與設(shè)計方法7e chap

1、Chapter 18Object-Oriented Design and Modeling Using the UML18-2ObjectivesUnderstand entity, interface, control, persistence, and system classes.Understand the concepts of dependency and navigability.Define visibility and explain its three levels.Understand the concept object responsibility and how i

2、t is related to message sending between object types.Describe the activities involved in object-oriented design.Differentiate between a design use-case narrative and an analysis use-case narrative.Describe CRC card modeling.Model class interactions with sequence diagrams.Construct a class diagram th

3、at reflects design specifics.Model object states with state machine diagrams.Understand the role of coupling and cohesion in object reuse.Describe the use of design patterns and two common design patterns.Differentiate between design patterns, object frameworks, and components.Understand the use of

4、communication diagrams, component diagrams, and deployment diagrams.18-318-4Object-Oriented DesignObject-oriented design (OOD) an approach used to specify the software solution in terms of collaborating objects, their attributes, and their methods.Continuation of object-oriented analysis18-5Design C

5、lassesIn OO programming every piece of code resides inside an object class18-6Types of Design ClassesEntity Class - contains business related information and implements analysis classes.Interface Class - provides the means by which an actor interacts with the system.A window, dialogue box, or screen

6、.For nonhuman actors, an application program interface (API).Control Class - contains application logic.Persistence Class - provides functionality to read and write to a database.System Class - handles operating system-specific functionality.18-7Design Relationships - DependencyA dependency relation

7、ship is used to model the association between two classes:To indicate that when a change occurs in one class, it may affect the other class.To indicate the association between a persistent class and a transient class. Interface classes typically are transientIllustrated with a dashed arrow18-8Design

8、 Relationships - NavigabilityClasses with associations can navigate (send messages) to each other.By default the associations are bidirectional.Sometimes you want to limit the message sending to only one direction.Illustrated with an arrow pointing in the direction a message can be sent.18-9Attribut

9、e and Method VisibilityVisibility the level of access an external object has to an attribute or method.Public attributes/methods can be accessed/invoked by any other method in any other object or class. Denoted by the + symbolProtected attributes/methods can be accessed/ invoked by any method in the

10、 same class or in subclasses of that class. Denoted by the # symbolPrivate attributes/methods can be accessed/invoked by any method in the same class. Denoted by the symbolMethod the software logic that is executed in response to a message.18-10Object ResponsibilitiesObject responsibility the obliga

11、tion that an object has to provide a service when requested and thus collaborate with other objects to satisfy the request if required.An object responsibility is implemented by the creation of methods that may have to collaborate with other objects and methods.18-11Object Responsibility18-12The Pro

12、cess of Object-Oriented DesignRefining the use case model to reflect the implementation environment.Modeling class interactions, behaviors, and states that support the use case scenario.Updating the class diagram to reflect the implementation environment.18-13Refining The Use Case ModelStep 1: Trans

13、form the “Analysis” Use Cases to “Design” Use CasesImplementation detailsControlsWindow/web page namesNavigation instructionsStep 2: Update the Use Case Model Diagram and Other Documentation to Reflect any New Use Cases18-14Design Use Case18-15Design Use Case (continued)18-16Design Use Case (continu

14、ed)18-17Design Use Case (concluded)18-18Modeling Class Interactions, Behaviors, and StatesStep 1: Identify and Classify Use-Case Design ClassesStep 2: Identify Class AttributesStep 3: Identify Class Behaviors and ResponsibilitiesStep 4: Model Object StatesStep 5: Model Detailed Object Interactions18

15、-19Step 1: Identify and Classify Use-Case Design ClassesInterface, Control, and Entity Classes of Place New Order Use CaseInterface ClassesController ClassesEntity ClassesW00-Member Home PageW02-Member Profile DisplayW03-Display Order SummaryW04-Display Order ConfirmationW09-Member Account Status Di

16、splayW11-Catalog DisplayW15-Product Detail DisplayPlace New Order HandlerBilling AddressShipping AddressEmail AddressActive MemberMember OrderMember Ordered ProductProductTitleAudio TitleGame TitleVideo TitleTransaction18-20Step 2: Identify Class AttributesMany attributes already identified during o

17、bject-oriented analysis.Revised use cases may mention additional attributes.Must update class diagram to include new attributes.18-21Step 3: Identify Class Behaviors and ResponsibilitiesAnalyze use cases to identify required system behaviorsSearch for verb phrasesSome will reflect manual actions, ot

18、hers automatedAssociate behaviors and responsibilities with classesModel classes that have complex behaviorExamine class diagram for additional behaviorsVerify classifications18-22Condensed Behavior ListCondensed Behavior List for Place New Order Use CaseBehaviorsClass TypeProcess new member orderCo

19、ntrolRetrieve product catalog informationEntityDisplay W11-Catalog Display windowInterfaceRetrieve member demographic informationEntityDisplay W02-Member Profile Display windowInterfaceValidate quantity amountEntityVerify the product availabilityEntityDetermine an expected ship dateEntityDetermine c

20、ost of the total orderEntityDisplay W03-Order Summary Display windowInterfacePrompt userInterfaceCheck Status of member accountEntity.18-23Tools for Identifying Behaviors and ResponsibilitiesClass Responsibility Collaboration (CRC) Card - a card that lists all behaviors and responsibilities assigned

21、 to a class.Often built interactively in a group setting that walks through a use caseSequence diagram - a UML diagram that models the logic of a use case by depicting the interaction of messages between objects in time sequence.18-24CRC Card Listing Behaviors and Collaborators of a ClassObject Name

22、: Member OrderSub Object:Super Object: TransactionBehaviors and ResponsibilitiesCollaboratorsReport order informationCalculate subtotal costCalculate total order costUpdate order statusCreate Ordered ProductDelete Ordered ProductMember Ordered Product18-25Sequence DiagramActorInterface classControll

23、er classEntity classesMessagesActivation barsReturn messagesSelf-callFrame18-26Another Sequence Diagram18-27Guidelines for Constructing Sequence DiagramsIdentify the scope of the sequence diagram, whether entire use-case scenario or one step.Draw actor and interface class if scope includes that.List

24、 use-case steps down the left-hand side.Draw boxes for controller class and each entity class that must collaborate in the sequence (based on attributes or behaviors previously assigned).Add persistence and system classes if scope includes that.Draw messages and point each to class that will fulfill

25、 the responsibility.Add activation bars to indicate object instance lifetimes.Add return messages as needed for clarity.Add frames for loops, optional steps, alternate steps, etc.18-28Step 4: Model Object StatesObject state a condition of the object at one point in its lifetime.State transition even

26、t occurrence that triggers a change in an objects state through updating of one or more of its attribute values.State machine diagram a UML diagram that depicts:the combination of states that an object can assume during its lifetime,the events that trigger transitions between states,the rules govern

27、ing the objects in transition.18-29Object State Example18-30State Machine Diagram18-31Verifying Object Behavior and CollaborationRole playing the act of simulating object behavior and collaboration by acting out an objects behaviors and responsibilities.Participants may assume the role of an actor o

28、n an object typeMessage sending is simulated by using an item such as a ball that is passed between the participants.Useful for discovering missing objects and behaviors.18-32Updating Object Model to Reflect Implementation EnvironmentDesign class diagram a diagram that depicts classes that correspon

29、d to software components that are used to build the software application. Includes:ClassesAssociations and gen/spec and aggregation relationshipsAttributes and attribute-type informationMethods with parametersNavigabilityDependencies18-33Transforming Analysis Class Diagram to Design Class DiagramAdd

30、 design objects to diagramAdd attributes and attribute-type information to design objectsAdd attribute visibilityAdd methods to design objectsAdd method visibilityAdd association navigabilityAdd dependency relationships18-34Four Implicit Object BehaviorsCreate new instancesUpdate data or attributesD

31、elete instancesDisplay information18-35Partial Design Class Diagram18-36Object ReusabilityCoupling - the degree to which one class is connected to or relies upon other classes.Cohesion - the degree to which the attributes and behaviors of a single class are related to each other.The two overarching

32、goals of object-oriented design are low coupling and high cohesion.Allows for object reuse.18-37Object ReusabilityThe OO Success StoryComparison of an OO Language and a 3GL LanguageProgramming LanguageProject Duration (calendar months)Level of Effort (person months)Software Size (lines of code)PL/11

33、9152265,000Smalltalk3.510.422,00018-38Design PatternsDesign pattern - a common solution to a give problem in a given context, which supports reuse of proven approaches and techniques. AdvantagesAllow us to design with the experiences of those who came before rather than having to reinvent the wheel.

34、Provide designers a short-hand notation for discussing design issues.18-39Sample Design Pattern18-40Gang-of-Four PatternsCreationalAbstract factorBuilderFactory methodPrototypeSingletonStructuralAdapterBridgeCompositeDecoratorFaadeProxyBehavioralChain of responsibilityCommandFlyweightInterpreterIteratorMediatorMementoObserverStateStrategyTemplate methodVisitor18-41Strategy PatternPattern:StrategyCategory:BehavioralProblem:How to design for varying and changing policy algorithms?Solution:Define each algorithm in a separate class with a common interface.18-42Adapter P