《软件工程》Computer Science 中.ppt

1、Object-Oriented Design Collaboration / Design Diagrams,Bill Bond 11/06/02,Chapter 14 - Design,Dynamic view, Interaction Diagrams - How objects will communicate to fulfill requirements Assign responsibilities Design patterns Static view, Design Class Diagrams - Definition of class and interfaces,Chap

2、ter 15 - Interaction Diagrams,Illustrates how objects interact via messages to fulfill tasks Prior artifacts Domain model System operation contracts Use cases Starting point - fulfillment of operation contract post-conditions,Diagram Types,Two types Collaboration Sequence,Collaboration Diagram,Seque

3、nce Diagram,Sequence Diagram,Strengths Clearly shows sequence or time ordering Weaknesses Must add new vertical line when adding new objects,Collaboration Diagram,Strengths Space economical Easier to illustrate complex branching, iteration, and concurrent behavior Weaknesses Difficult to see sequenc

4、e of messages More complex notation,Example - Collaboration,Example - Sequence,Same as previous diagram Emphasizes “focus of control”,Important Artifact,Assign responsibilities Design object collaborations Significant amount of time Use patterns - structural guidelines and principles Notation-only c

5、hapter,Approach,Create separate diagram for each system operation System operation is starting message If diagram gets complex (greater than 8.5x11) split into smaller diagrams,Approach,Use operation contract responsibilities / post-conditions and use case description as starting point Design system

6、 of interacting objects to fulfill tasks Apply GRASP and patterns to develop good design,Class And Instances,Instance is underlined Class name preceded by colon,Message Syntax,Return := message(parameter : parameterType) : returnType Parts are optional,Links,Connection path between instances Instanc

7、e of an association Client to server message,Messages,Labeled arrow Sequence,Message to “self” or “this”,Creation of Instance,Create is language independent Create maps to C+ “new”+constructor,Message Number Sequencing,Message Number Sequencing,Conditional Message,conditionalClause - must evaluate t

8、o TRUE,Mutually Exclusive,Iteration,Iteration indicated by * Sent repeatedly specified number of times,Iteration over Collection,Collection - multiobject,Message to a Class,Static method,Sequence Diagram - Messages,Focus of Control - Activation Box,Message to “self” or “this”,Creation of Instance,Ob

9、ject Lifelines,Conditional Message,Mutually Exclusive,Iteration,Iteration Over a Set of Messages,Iteration Over Multiobject,Message to a Class,Chapter 16 - GRASP,Patterns for assigning responsibilities Object-oriented system - objects sending messages to each other to complete operations GRASP patte

10、rns Good design principles Applied during creation of interaction diagrams,Responsibility,Contract or obligation of a type or class Knowing about private encapsulated data about related objects about things it can derive or calculate Doing something itself initiating action in other objects controll

11、ing and coordinating activities in other objects,Patterns,Responsibilities assigned during design Pattern - named description of problem and solution that can be applied to new context “One persons pattern is another persons primitive building block” Patterns capture existing, known knowledge,Patter

12、ns,Patterns have names suggests how it applies facilitates communication GRASP General Responsibility Assignment Software Pattern fundamental principles of assigning responsibilities to objects,First Five GRASP Patterns,Expert Creator High Cohesion Low Coupling Controller,Expert,Solution: Assign a r

13、esponsibility to the information expert-the class that has the information necessary to fulfill the responsibility. Problem: What is the most basic principle by which responsibilities are assigned in object oriented design?,Expert,A class model may define dozens or hundreds of software classes, and

14、an application may require hundreds or thousands of responsibilities to be fulfilled. During object-oriented design, when the interactions between objects are defined, we make choices about the assignment of responsibilities to classes. Done well, systems tend to be easier to understand, maintain, a

15、nd extend, and there is an opportunity to reuse components in future applications,Expert,Start assigning responsibilities by clearly stating the responsibility Who should be responsible for knowing the grand total of a sale? For all SaleLineItems sum their subtotals,Sale Is Expert,Expert,Sale: Knows

16、 (calculates) sale total,Expert,SalesLineItem: Knows (calculates) line item subtotal,Expert,ProductSpecification: Knows product price,Expert,Class Sale SalesLineItem ProductSpecification,Responsibility knows sale total knows line item subtotal knows product price,Expert,Basic guiding principle Objec

17、ts do things related to information they have May require “partial” experts Give responsibility to object with information necessary to fulfill Encapsulation maintained, objects use their own information,Creator,Solution: Assign class B the responsibility to create an instance of class A if one of t

18、he following is true: B aggregates A objects. B contains A objects. B records instances of A objects. B closely uses A objects. B has the initializing data that will be passed to A when it is created (thus B is an Expert with respect to creating A).,Creator,B is a creator of A objects. If more than

19、one option applies, prefer a class B which aggregates or contains class A.,Creator,Problem: Who should be responsible for creating a new instance of some class? The creation of objects is one of the most common activities in an object-oriented system. Consequently, it is useful to have a general pri

20、nciple for the assignment of creation responsibilities. Assigned well, the design can support low coupling, increased clarity, encapsulation, and reusability.,Creator,Who should be responsible for creating a SaleLineItem instance?,Creator,Sale contains (aggregates) SalesLineItem objects - Sale respo

21、nsible Aggregation - whole / part relationship,Low Coupling,Solution: Assign a responsibility so that coupling remains low. Problem: How to support low dependency and increased reuse?,Low Coupling,Coupling is a measure of how strongly one class is connected to, has knowledge of, or relies upon other

22、 classes. A class with low (or weak) coupling is not dependent on too many other classes; too many is context dependent but will be examined.,Low Coupling,A class with high (or strong) coupling relies upon many other classes. Such classes are undesirable; they suffer from the following problems: Cha

23、nges in related classes force local changes. Harder to understand in isolation. Harder to reuse because its use requires the additional presence of the classes it is dependent upon.,Low Coupling,Register: Which is preferred?,Low Coupling,Low Coupling,Second preferred, Register is less dependent Low

24、Coupling and Creator may suggest different solutions Coupling may not be important if reuse is not a goal, how important is reuse? Extreme of Low Coupling - few bloated, complex objects (violates high cohesion) Moderate coupling is expected,High Cohesion,Solution: Assign a responsibility so that coh

25、esion remains high. Problem: How to keep complexity manageable?,High Cohesion,In terms of object-oriented design, cohesion (or more specifically, functional cohesion) is a measure of how strongly related and focused the responsibilities of a class are. A class with highly related responsibilities, a

26、nd which does not do a tremendous amount of work, has high cohesion.,High Cohesion,A class with low cohesion does many unrelated things or does too much work. Such classes are undesirable; they suffer from the following problems: hard to comprehend hard to reuse hard to maintain delicate; constantly

27、 effected by change,High Cohesion,Low cohesion classes often represent a very large-grain of abstraction, or have taken on responsibilities that should have been delegated to other objects.,High Cohesion,Must consider in light of Expert / Low Coupling, strike a balance If a “person” takes on too man

28、y unrelated responsibilities, person is not effective “Fine grain” of related functionality supports reuse,Controller,Solution: Assign the responsibility for receiving or handling a system event message to a class representing one of the following choices: Represents the overall system, device, or s

29、ubsystem (facade controller).,Controller,Represents a use case scenario within which the system event occurs, often named Handler, Coordinator, or Session (use-case or session controller Use the same controller class for all system events in the same use case scenario. Informally, a session is an in

30、stance of a conversation with an actor. Sessions can be of any length, but are often organized in terms of use cases (use case sessions).,Controller,Corollary: Note that window, applet, application, view, and document classes are not on this list. Such classes should not fulfill the tasks associated

31、 with system events, they typically receive these events and delegate them to a controller.,Controller,Problem: Who should be responsible for handling an input system event? An input system event is an event generated by an external actor. They are associated with system operations - operations of t

32、he system in response to system events, just as messages and methods are related.,Controller,For example, when a cashier using a POS terminal presses the “End Sale” button, he is generating a system event indicating “the sale has ended.” Similarly, when a writer using a word processor presses the “s

33、pell check” button, he is generating a system event indicating “perform a spell check.” A Controller is a non-user interface object responsible for receiving or handling a system event. A Controller defines the method for the system operation.,Controller,Controller,Previously we identified “system o

34、perations”, “who is responsible for them? Possible Register - overall system Store - overall business Cashier - active in real-world BuyItemsHandler - artificial handler,Controller,Cohesion and coupling influence decision Normally, a controller should delegate to other objects the work that needs to

35、 be done; it coordinates or controls the activity. It does not do much work itself. Dont assign operations to “interface”,Bloated Controller,Single controller for all events and there are many Controller does not delegate tasks Controller has many attributes, maintains significant information Approa

36、ch Add more controllers Delegate responsibility,Chapter 17 - Design Model,Read this chapter! Explains design decisions There are multiple possible design solutions, design is a tradeoff between the design patterns previously discussed Not all required information will be found in existing artifacts,

37、Developing Interaction Diagrams,Create a separate diagram for each system operation - it is starting message Using contract responsibilities / post-conditions, and use case description as a starting point, design system of interacting objects to fulfill the tasks Apply patterns to develop good desig

38、n Next page more detail,Developing Interaction Diagrams,Choose the controller Separate Model from View (more detail next week) Creation / Association (from post-conditions) suggests Creator pattern State the responsibility Expert pattern - who will be responsible Do “startup” last - information will

39、 be available,Chapter 18 - Visibility,For a sender to send a message to an object, the sender must have a reference or pointer to the receiver object Visibility - ability of an object to see or have reference to another object; is one object within the scope of another,Types of Visibility,Attribute - B is an attribute of A Parameter - B is a parameter of a method of A Locally declared - B is declared as a local object Globally declared - B is declared as a global object,Attribute Visibility,Persists as long