chObjectOrientedDesignUseCaseRealizations实用学习教程.pptx

1.OverviewThe use case realization is used to extend the process of detailed design.In use case realization,each use case is taken individually to determine all the classes that collaborate on it.As part of that process,any other utility or support classes are identified.Care is taken during this process to definethe classes so the integrity of the multilayer architectural design is maintained.As the details of the classes are designed use case by use case the design classdiagram is also updated as necessary.10:55第1页/共60页2.Detailed Design of Multilayer SystemsCRC cards focus on collaborating domain objects to execute various use cases.In multilayer architecture,there are three objects representing the three layers of a system.Each object has certain responsibilities.The input window object has the primary responsibility of formatting and presenting student information on the screen.The student object represents the middle layer,or business logic layer,for the use case.The database access object represents the third layer in the multilayer design.10:55第2页/共60页Patterns of collaborating objectsPatterns,also called templates,are used repeatedly in everyday life.Patterns are created to solve problems.Over time and with many attempts,people who work on a particular problem develop a set solution to the problem.The solution is general enough that it can be applied over and over again.As time passes,the solution is documented and published,and eventually it becomes accepted as the standard10:55第3页/共60页2.Detailed Design of Multilayer SystemsDesign patterns became a widely accepted object-oriented design technique in 1996.Elements of Reusable Object-Oriented Software,1996by Erich Gamma,Richard Helm,Ralph Johnson,and John Vlissides.These four authors are now referred to as the Gang of Four(GoF).10:55第4页/共60页Pattern:Controller10:55第5页/共60页Pattern specificationPattern specification has five main elements:1.Pattern name2.Problem that requires a solution3.Solution to or explanation of the pattern4.Example of the pattern5.Benefits and consequences of the pattern10:55第6页/共60页Pattern:ControllerProblem:Domain classes have the responsibility of processing use cases.1.However,since there can be many domain classes,which one(s)should be responsible for receiving the input messages?2.User interface classes become very complex if they have visibility to all of the domain classes.3.How can the coupling between the user-interface classes and the domain classes be reduced?10:55第7页/共60页Pattern:ControllerSolution:Assign the responsibility for receiving input messages to a class that receives all input messages and acts as a switchboard to forward them to the correct domain class.There are several ways to implement this solution:1.Have a single class that represents the entire system,or2.Have a class for each use case or related group of use cases to act as a use case handler.10:55第8页/共60页Pattern:ControllerExample:The RMO Customer account subsystem accepts inputs from a:CustomerForm window.These input messages are passed to the:CustomerHandler,which acts as the switchboard to forward the message to the correct problem domain class.10:55第9页/共60页Pattern:ControllerBenefits and Consequences:Coupling between the view layer and the domain layer is reduced.The controller provides a layer of indirection.The controller is closely coupled to many domain classes.If care is not taken,controller classes can become incoherent,with too many unrelated functions.If care is not taken,business logic will be inserted into the controller class.10:55第10页/共60页3.Use Case Realization with Sequence DiagramsDeveloping interaction diagrams is at the heart of object-oriented detailed design.The realization of a use case is to determine what objects collaborate and the messages they send to each other to carry out the use case.Two types of interaction diagrams:1.sequence diagrams munication diagrams10:55Why?to design object collaboration第11页/共60页10:55ExampleUse Case:Create customer account第12页/共60页System sequence diagram for the Create customer account use caseThe system itself is treated as a single object named:System.第13页/共60页10:55The most important information on an System sequence diagram(SSD)is the sequence of messages between the actor and the system.How to reduce(separate)responsibilities with objects.第14页/共60页10:55第15页/共60页Activation Lifelinea representation of the period during which a method of an object is alive and executing.10:55第16页/共60页10:55Its now to look at the problem domain classes again and determine which classes are required for this use case.The Address class and the Account class are attached to Customer class.第17页/共60页10:55The Customer class has visibility to the other two classes:Account and Address.第18页/共60页10:55第19页/共60页10:55Its time is to determine the internal messages that must be sent between the objects第20页/共60页How to design interactionsWhen identifying and creating messages,we must first determine the origin and destination objects for the message.The origin object is the one that needs information or help in carrying out a responsibility so it will initiate a message.The destination object is the one that has the information to help in the solution and will receive the message and process it.After determining the origin and destination objects,we must name the message.Notice also that the input parameters provide the information that the destination object needs in order to provide the service.10:55第21页/共60页10:55ExampleUse Case:Fill Shopping Car第22页/共60页10:55Remember from Figure 3-16:The“Fill Shopping Car”use case“included”three other use cases.第23页/共60页10:55第24页/共60页10:55第25页/共60页.In UML,when a create message is sent to an object,it is often drawn directly to the objects box and not to the lifeline第26页/共60页Review:The relevant design principle is that objects that“own”other objects areresponsible for creating those objects;for example,a customer creates an online cart and then the online cart creates items in the cart.Another important consideration is navigation visibility.To send a message to the correct destination object,the source object must have visibility to the destination object.Remember that the purpose of doing design is to prepare for programming.10:55第27页/共60页Guidelines for First-Cut Sequence Diagram DevelopmentDesigning a use case or scenario by using sequence diagrams involves performing these tasks:Take each input message and determine all the internal messages that result from that input.For each message,Determine its objective.Determine what information is needed,What class needs it(the destination),and What class provides it(the source).Determine whether any objects are created as a result of the input.10:55第28页/共60页Guidelines for First-Cut Sequence Diagram DevelopmentAs you work with each input message,identify the complete set of classes that will be affected by the messageAny classes that are listed in either the preconditions or post conditions should be included in the design.Classes that are created during the use case,Classes that are the creators of objects for the use case,Classes that are updated during the use case Classes that provide information used in the use case.10:55第29页/共60页Guidelines for First-Cut Sequence Diagram DevelopmentFlesh out the components for each message;iteration,true/false conditions,return values,passed parameters.The passed parameters should be based on the attributes found in the domain class diagram.10:55第30页/共60页Assumptions for First-Cut Sequence Diagram DevelopmentThe development of the first-cut sequence diagram is based on several assumptions,including:Perfect technology assumptionPerfect memory assumptionPerfect solution assumption10:55第31页/共60页Developing a Multilayer DesignSeparation of Responsibilities principleIt recommend segregating classes into separate components based on the primary focus of the classes10:55第32页/共60页Developing a Multilayer DesignThree-layer design for the Fill shopping cart use caseView LayerDomain LayerData Access LayerDatabase10:55第33页/共60页Data Access Layer10:55第34页/共60页View Layer10:55第35页/共60页Review:View layer should doView layer classes should have programming logic to perform the following:Display electronic forms and reports.Capture such input events as clicks,rollovers,and key entries.Display data fields.Accept input data.Edit and validate input data.Forward input data to the domain layer classes.Start and shut down the system.10:55第36页/共60页Review:Domain layer should doDomain layer classes should have responsibilities to perform the following:Create problem domain(persistent)classes.Process all business rules with appropriate logic.Prepare persistent classes for storage to the database.10:55第37页/共60页Review:Data access layer should doData access layer classes should have responsibilities to perform the following:Establish and maintain connections to the database.Contain all SQL statements.Process result sets(the results of SQL executions)into appropriatedomain objects.Disconnect gracefully from the database.10:55第38页/共60页4.Designing with Communication Diagrams10:55第39页/共60页4.Designing with Communication DiagramsThe numbers on the messages indicate the sequence in which the messages are sent.The hierarchical dot numbering scheme is used when messages depend on previous messages.Drawing a communication diagram is an effective way to get a quick overview of the objects that work together.However,it is more difficult to visualize the sequence of the messages.10:55第40页/共60页4.Designing with Communication Diagrams10:55第41页/共60页5.Updating and Packaging the Design ClassesDesign class diagrams can now be developed for each layer.In the view layer and the data access layer,several new classes must be specified.The domain layer also has some new classes added for the use case controllers.10:55第42页/共60页5.Updating and Packaging the Design Classes10:55第43页/共60页5.1 Structuring the Major Components with Package Diagrams10:55第44页/共60页Dependency relationshipsIts a relationship between packages,classes,or use cases in which a change in the independent item requires a change in the dependent item.Dependency relationships are used in package diagrams,class diagrams,and even interaction diagrams.10:55The arrows tail is connected to the package that is dependent,and the arrowhead is connected to the independent package.第45页/共60页10:55Package diagrams can also be nested to show different levels of packages.第46页/共60页6.Some Design PatternsAdapterFactorySingleton10:55第47页/共60页6.1 Adapter PatternProblemA class must be replaced,or is subject to being replaced,by another standard or purchased class.The replacing class already has a predefined set of method signatures that are different from the method signatures of the original class.How do you link in the new class with a minimum of impact so that you dont have to change the names throughout the system to the method names in the new class?10:55第48页/共60页6.1 Adapter PatternSolutionWrite a new class,the adapter class,which serves as a link between the original system and the class to be replaced.This class has method signatures that are the same as those of the original class(and the same as those expected by the system).Each method then calls the correct desired method in the replacement class with the method signature.In essence,it“adapts”the replacement class so that it looks like the original class.10:55第49页/共60页6.1 Adapter PatternExampleThere are several places in the RMO system where class libraries were purchased to provide special processing.These purchased libraries provide specialized services such as tax calculations and shipping and postage rates.From time to time,these service libraries are updated with new versions.Sometimes a service library is even replaced with one from an entirely different vendor.The RMO systems staff applies protection from variations and indirection design principles by placing an adapter in front of each replaceable class class?10:55第50页/共60页6.1 Adapter PatternBenefits and consequences:The adaptee class can be replaced as desired.Changes are confined to the adapter class and do not ripple through the system.Two classes are defined,an interface class and the adapter class.Passed parameters may add more complexity,and it is difficult to limit changes to the adapter class.10:55第51页/共60页6.2 Factory PatternProblemWho should be responsible for creating utility type objects that do not specifically belong to the problem domain classes?These utility objects may also be accessed from various places within the system,so a given object may need to be instantiated from several classes.10:55第52页/共60页6.2 Factory PatternSolutionCreate an artifact that is a factory class.Its responsibility is only to instantiate utility classes.In many situations,only one instance of a particular utility class is allowed.Hence,all classes that need access to the class come through the factory.The factory ensures that only one instance is created.10:55第53页/共60页6.2 Factory PatternExampleSeveral places in the RMO system need to get data from an Order object and need to have a reference to an Order_DA data access object.The Order_DA object may or may not already have been instantiated.A data access factory is defined and an interface is created.The requesting object uses the methods defined in the interface to request the reference to the Order_DA object.It then can read the database of orders.10:55第54页/共60页6.2 Factory PatternBenefits and consequences:Higher cohesion of problem domain classesLess coupling between business logic layer and data layerSmaller,more maintainable classes10:55第55页/共60页6.3 Singleton PatternProblemOnly one instantiation of a class is allowed.The instantiation(new)can be called from several places in the system.The first reference should make a new instance,and later attempts should return a reference to the already instantiated object.How do you define a class so that only one instance is ever created?10:55第56页/共60页6.3 Singleton PatternSolutionA singleton class has a static variable that refers to the one instance of itself.All constructors to the class are private and are accessed through a method or methods,such as getInstance().The getInstance()method checks the variable;if it is null,the constructor is called.If it is not null,then only the reference to the object is returned.10:55第57页/共60页6.3 Singleton PatternExampleIn RMOs system,the connection to the database is made through a class called Connection.However,for efficiency,we want each desktop system to open and connect to the database only once,and to do so as late as possible.Only one instance of Connection(very bad idea)that is,only one connection to the databaseis desired.The Connection class is coded as a singleton.The following coding example is similar to C#and Java:class Connection private static Connection conn=null;public synchronized static getConnection()if(conn=null)conn=new Connection();return conn;Another example of a singleton