chObjectOrientedDesignPrinciples实用实用教案

1、1. Object-Oriented Design: Bridging from Analysis to Implementation Systems design is the bridge between user requirements and programming the new system. One strength of the object-oriented approach is that the design models are often just extensions of the requirements models. Obviously, it is muc

2、h easier to extend an existing model than to create entirely new design models. One tenet of Agile, adaptive approaches to development is to create models only if they have meaning and are necessary. The design models may not be formalized into a comprehensive set of documents and diagrams, but they

3、 are certainly necessary.2021-11-24第1页/共53页第一页，共54页。1.1 Overview of Object-Oriented Programs An object-oriented program consists of a set of program objects that cooperate to accomplish a result. Each program object has program logic and any necessary attributes encapsulated into a single unit. Thes

4、e objects work to get he by sending each other messages and working in concert to support the functions of the main program.2021-11-24第2页/共53页第二页，共54页。1.1 Overview of Object-Oriented Programs2021-11-24第3页/共53页第三页，共54页。1.1 Overview of Object-Oriented Programs An object-oriented system consists of set

5、s of computing objects. Each object has data and program logic encapsulated within itself. This is called an instantiation of the classthat is, making an instance (an object) based on the template provided by the class definition. Each object also represents a structure of three-layer architecture.

6、2021-11-24第4页/共53页第四页，共54页。1.2 Object-Oriented Design Models and Processes2021-11-24第5页/共53页第五页，共54页。1.2 Object-Oriented Design Models and Processes The domain model class diagram identifies all the classes, or “things,” that are important in the problem domain. The use case diagrams identified the

7、elementary business processes that the system needs to supportin other words, all the ways users want to use the system to carry out processing goals. The activity diagrams and use case descriptions document the internal workflow of each use case. 2021-11-24第6页/共53页第六页，共54页。1.2 Object-Oriented Desig

8、n Models and Processes An activity diagram shows the steps necessary to carry out a particular use case. The system sequence diagrams are closely related to activity diagrams, except that they show the messages or data that are sent back and forth between the user and the system during the steps of

9、the use case. Finally, state machine diagrams keep track of all status condition requirements for one particular class. They also show the business rules that control the changing of one state (status condition) to another.2021-11-24第7页/共53页第七页，共54页。1.2 Object-Oriented Design Models and Processes Ar

10、chitectural design is one of the first steps in systems design, in as much as it provides the big picture and overall structure of the new system. At the top of the right column are component diagrams and deployment diagrams. we next see design class diagrams, or DCDs, which are an expansion of the

11、domain model class diagram. The design version of sequence diagrams is much more detailed and is used to carry out much of the detailed design activity.2021-11-24第8页/共53页第八页，共54页。2. Object-Oriented Architectural DesignIn most cases, developers begin to think about how the system will be deployed and

12、 what the overall structure will look like during the early steps of requirements gathering and documentation.Software systems are generally divided into two types: single-user systems enterprise-level systems.2021-11-24第9页/共53页第九页，共54页。2. Object-Oriented Architectural Design Enterprise-level system

13、s almost always use client/server architectures with multiple layers. Characteristic of enterprise-level systems, the database and data access are on a central server because it is a shared resource throughout the organization.2021-11-24第10页/共53页第十页，共54页。2. Object-Oriented Architectural Design2021-1

14、1-24Design IssueClient/Server Network System Internet System (Web)StateStateful” or state-based system e.g., client/server connection is long term.“Stateless systeme.g., client/server connection is not long term and has no inherent memory.Client configuration Screens and forms that are programmed ar

15、e displayed directly.Domain layer is often on the client or split between client and servermachines.Screens and forms aredisplayed only through abrowser. They must conform to browser technologyServerconfiguration Application or data server directly connects to client tier.Client tier connectsindirec

16、tly to the application server through a Web server第11页/共53页第十一页，共54页。2. Object-Oriented Architectural Design The concept of state relates to the permanence of the connection between the client view layer and the server domain layer. If the connection is permanent, as in a client/server system, value

17、s in variables can be passed back and forth and are remembered by each component in the system. The view layer has direct access to the data fields in the domain layer. In a stateless system, such as the Internet, the client view layer doesnt have a permanent connection to the server domain layer.20

18、21-11-24第12页/共53页第十二页，共54页。2.1 Component Diagrams and Architectural Design The component diagram identifies the logical, reusable, and transportable (portable?) system components that define the system architecture. The essential element of a component diagram is the component element with its inter

19、faces. A component is an executable module or program, and it consists of all the classes that are compiled into a single entity. There are two ways to represent a component: as a general class or as a specific instance.2021-11-24第13页/共53页第十三页，共54页。2.1 Component Diagrams and Architectural Design2021

20、-11-24第14页/共53页第十四页，共54页。Stereotyping UML does have rules for stereotyping a symbol and for extending the language2021-11-24第15页/共53页第十五页，共54页。Two-Layer Architectural Design of Internet Systems2021-11-24第16页/共53页第十六页，共54页。Two-Layer Architectural Design of Internet Systems The business logic in the d

21、omain layer frequently relates only to data formatting and to deciding which database table to update. Due to the structure of Web servers, the program (defined as object-oriented classes) that processes the input forms also outputs the HTML code that is sent back to the client browser. The basic id

22、ea is that even a Web-based system can be developed in multiple layers of the viewthat is, the user interface, the model (which is the business logic and database access), and the controller (which provides a link between the view and the model).2021-11-24第17页/共53页第十七页，共54页。2.1 Component Diagrams an

23、d Architectural Design It is critically important for the same back end business logic and database accessto link with either user interface. Consequently, the design team must specify the architectural design in enough detail to ensure the programmers implement a system that can support both user i

24、nterfaces. Each component is an executable program and is made up of classes.2021-11-24第18页/共53页第十八页，共54页。3. Fundamental Principles of Object-Oriented Detailed Design The objective of object-oriented detailed design is to identify and specify all the objects that must work together to carry out each

25、 use case. One major responsibility of detailed design is to identify and describe each set of objects within each layer and to identify and describe the interactions or messages that are sent between these objects. The full sequence diagram is used for design and is a type of interaction diagram. A

26、 communication diagram is also a type of interaction diagram.2021-11-24第19页/共53页第十九页，共54页。3. Fundamental Principles of Object-Oriented Detailed Design2021-11-24第20页/共53页第二十页，共54页。3. Fundamental Principles of Object-Oriented Detailed Design2021-11-24第21页/共53页第二十一页，共54页。3. Fundamental Principles of Ob

27、ject-Oriented Detailed DesignIt describes the set of object-oriented classes needed for programming,navigation between the classes, attribute names and properties, and method names and properties. A design class diagram is a summary of the final design that was developed by using the detailed sequen

28、ce diagrams, and it is used directly when developing the programming code. 2021-11-24第22页/共53页第二十二页，共54页。Translate model into code. The same model is presented in different languages. 2021-11-24第23页/共53页第二十三页，共54页。第24页/共53页第二十四页，共54页。3.1 Object-Oriented Design Process2021-11-24第25页/共53页第二十五页，共54页。4.

29、 Design Classes and the Design Class Diagram The domain model class diagram shows a set of problem domain classes and their associations. During analysis, because it is a discovery process, analysts generally dont worry much about the details of the attributes. However, in OOP, the attributes of a c

30、lass must? be declared as public or private, and each attribute must also be defined by its type, such as character or numeric. During detailed design, it is important to elaborate on these details as well as to define the methods and parameters that are passed to the methods and the return values f

31、rom methods. 2021-11-24第26页/共53页第二十六页，共54页。4.1 Design Class Symbols A stereotype is simply a way to categorize a model element as a certain type. A stereotype extends the basic definition of a model element by indicating that it has some special characteristic we want to highlight.EntityControllerBo

32、undary 2021-11-24第27页/共53页第二十七页，共54页。 An entity class is the design identifier for a problem domain class. It is also usually a persistent class. A persistent classis one with objects that exist after the program quits. A boundary class , or view class, is specifically designed to live on the system

33、s automation boundary. In a desktop system, these classes would be the windows classes and all the other classes associated with the user interface.2021-11-24第28页/共53页第二十八页，共54页。4.1 Design Class Symbols A control class mediates between the boundary classes and the entity classes. In other words, its

34、 responsibility is to catch the messages from the boundary class objects and send them to the correct entity class objects. It acts as a kind of switch board, or controller, between the view layer and the domain layer. A data access class is used to retrieve data from and send data to a database. Ra

35、ther than insert database access logic, including SQL statements, into the entity class methods, a separate layer of classes to access the database is often included in the design.2021-11-24第29页/共53页第二十九页，共54页。4.1 Design Class Symbols2021-11-24第30页/共53页第三十页，共54页。4.1 Design Class Symbols2021-11-24第31

36、页/共53页第三十一页，共54页。4.2 Design Class NotationThe format that analysts use to define each attribute includes:VisibilityWhether other objects can directly access the attribute. (A plus sign indicates that an attribute is visible, or public; a minus sign indicates that it isnt visible, or private.)Attribu

37、te nameType-expression (such as character, string, integer, number, currency, or date)Initial-value, if applicableProperty (within curly braces), such as key, if applicable2021-11-24第32页/共53页第三十二页，共54页。4.2 Design Class NotationRemember that in the object-oriented approach, a class is a template to c

38、reate individual objects or instances.The third compartment contains the method signature information. A method signature shows all the information needed to invoke (or call) the method. It shows the format of the message that must be sent, which consists of these:Method visibilityMethod nameMethod

39、parameter list (incoming arguments)Return type-expression (the type of the return parameter from the method)2021-11-24第33页/共53页第三十三页，共54页。4.2 Design Class Notation2021-11-24第34页/共53页第三十四页，共54页。4.2 Design Class Notation Each of the subclasses also has a unique attribute that is underlined, such as no

40、OfPhoneSales. Underlined attributes are class-level attributes and have the same characteristics as class-level methods. A class-level attribute is a static variable, and it contains the same value in all instantiated objects of the same type. An italicized class name indicates that it is an abstrac

41、t class a class that can never be instantiated. Each of the three subclasses is considered a concrete class because it can be instantiated; in other words, objects can be created.2021-11-24第35页/共53页第三十五页，共54页。4.3 Developing the First-cut(初步(chb) Design Class Diagram2021-11-24第36页/共53页第三十六页，共54页。4.3

42、Developing the First-Cut Design Class DiagramThe first-cut design class diagram is developed by extending the domain model class diagram.It requires two steps: elaborating on the attributes with type and initial value information andadding navigation visibility arrows. As indicated earlier, object-o

43、riented design is use casedriven. 2021-11-24第37页/共53页第三十七页，共54页。4.3 Developing the First-Cut Design Class Diagram2021-11-24第38页/共53页第三十八页，共54页。Attribute Visibility, Navigation and Navigation VisibilityHere are a few general guidelines:One-to-many associations that indicate a superior/subordinate rel

44、ationship are usually navigated from the superior to the subordinate for example, from Sale to SaleItem. Sometimes, these relationships form hierarchies of navigation chainsfor example, from Promotion to ProductItem to InventoryItem.Mandatory associations, in which objects in one class cant exist wi

45、thout objects of another class, are usually navigated from the more independent class to the dependent classfor example, from Customer to Sale.When an object needs information from another object, a navigation arrow might be required, pointing either to the object itself or to its parent in a hierar

46、chy.Navigation arrows may be bidirectional.2021-11-24第39页/共53页第三十九页，共54页。4.3 Developing the First-Cut Design Class Diagram2021-11-24第40页/共53页第四十页，共54页。4.3 Developing the First-Cut Design Class DiagramThree points are important to note. First, as detailed design proceeds use case by use case, we need

47、 to ensure that the sequence diagrams support and implement the navigation that was initially defined. Second, the navigation arrows need to be updated as design progresses to be consistent with the design details. 1.Finally, method signatures will be added to each class based on the design decision

48、s made when creating the sequence diagrams for the use cases.2021-11-24第41页/共53页第四十一页，共54页。5. Detailed Design with CRC Cards CRC cards are a brainstorming technique that is quite popular among object oriented developers. Here, “CRC” is an acronym for Class Responsibility Collaboration. 2021-11-24第42

49、页/共53页第四十二页，共54页。5. Detailed Design with CRC CardsFor each use case you need to design, these steps are done iteratively:Selecting a use caseIdentifying the problem domain class that has responsibility for this use caseThis object will receive the first message from the use case controller. Using th

50、e domain model that was developed during analysis, select one class to take responsibility. Focus only on the problem domain classes. On the left side of the card, write the objects responsibility.1.Identifying other classes that must collaborate with the primary objectclass to complete the use case

51、2021-11-24第43页/共53页第四十三页，共54页。5. Detailed Design with CRC CardsAt the end of this process, you will have a small set of CRC cards that collaborate to support the use case. Another helpful step is to include the user-interface classes. Any other required utility classes can also be added to the solut

52、ion.2021-11-24第44页/共53页第四十四页，共54页。5. Detailed Design with CRC Cards2021-11-24第45页/共53页第四十五页，共54页。6. Fundamental Detailed Design Principles Coupling Coupling is a qualitative measure of how closely the classes in a design class diagram are linked. A simple way to think about coupling is as the number

53、 of navigation arrows on the design class diagram. Low coupling is usually better for a system than high coupling. In other words, fewer navigation visibility arrows indicate that a system is easier to understand and maintain.2021-11-24第46页/共53页第四十六页，共54页。6. Fundamental Detailed Design Principles Co

54、hesion But what if that same object also had methods to make classroom assignments or assign professors to courses? The cohesiveness of the class would be reduced. Classes with low cohesion have several negative effects. First, they are hard to maintain. Second, it is hard to reuse such classes.2021

55、-11-24第47页/共53页第四十七页，共54页。6. Fundamental Detailed Design Principles Protection from variations One of the underlying principles of good design is protection from variationsthe idea that the parts of a system that are unlikely to change should be segregated(or protected) from those that will change.

56、Protection from variations is a principle that drives the multilayer design pattern. 2021-11-24第48页/共53页第四十八页，共54页。6. Fundamental Detailed Design Principles Indirection Indirection is the principle of decoupling two classes or other system components by placing an intermediate class between them to serve as a link. In other words, instructions dont go directly from A to