1 / 53

Chapter 6

Chapter 6. Considering Objects. Learning objectives. Explain what is meant by object-oriented development, and how it differs from other development paradigms ( 范例 );

oneida
Download Presentation

Chapter 6

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 6 Considering Objects

  2. Learning objectives • Explain what is meant by object-oriented development, and how it differs from other development paradigms(范例); • Understand what use cases are, discuss why they can be useful in software development, and use them to describe system functionality • Use and understand UML diagrams • Explain how object-orientation is used for system design • Explain how object-orientation is used for program design;

  3. 6.1 WHAT IS OO? • Object orientationis an approach to softwaredevelopment. both the problem and its solution as a collection of discrete objects; both data structure and behavior are included in the representation. • OO useclassification(分类) to group objects that have attributes(属性) and behaviors in common.each group can be considered a class FIGURE 6.1 Example of objects grouped into classes

  4. 6.1 WHAT IS OO? • Each object in an OO system usually has name,also called a reference or handle; a set ofattributes;and a set ofbehavior FIGURE 6.2 Box representing an object’s name,attribute,and behavior

  5. 6.1 WHAT IS OO? • Attributeare simple variables whose values can vary over timeand among different entities of the class • behavioris an action or transformation that an object performs • Sometimes, the same behavior may be exhibited(呈现) differently on different class or subclass, a property called polymorphism(多态性) • seven characteristics: • Identity(同一性), abstraction(抽象性), classification (分类性), encapsulation(封装性), inheritance(遗传性) , polymorphism(多态性), and persistence(持久性)

  6. 6.2 THE OO DEVELOPMENT PROCESS • One advantage of OO development is its consistency (一致性) of language. We can describe both the problem and the solution in the same terms: classes, objects, methods, attributes and behaviors. No matter where in the process we represent an object, we must include the object's name, attributes, and behaviors. At the next higher level, describing classes using OO representation requires three perspectives: static, dynamic, and restrictive (限制性). • Static view(观察) include descriptions of the objects, attributes, behaviors, and relationships • Dynamic view describe communication, control/timing,and the states and state changes • The restrictions describe constraints(约束) on the structure and the dynamic behavior.

  7. 6.2 THE OO DEVELOPMENT PROCESS OO Development Processes 1. OO Requirements No matter what the life cycle, an OO development process requires steps for describing requirements, designing the system, designing the programs, coding, and testing. OO requirements analysis is usually done in the user’s language and discusses the the concepts and scenarios(想定) likely in the application domain 2. OO Design There are two guidelines that apply to representing a system design in an object-oriented way. First, we should identify and represent classes and object. Second, we must identity(同一性) the interactions(交互作用) and relationships among objects and class

  8. 6.2 THE OO DEVELOPMENT PROCESS 3. OO Coding and Testing Once the program design is done, the system is described at a very low level, using models of objects, attributes, and behaviors.Coding proceeds by translating the models to an OO programming language. Testing an OO system involves some of the same activities that are performed when testing any kind of system. The coders unit-test their own work, then cooperate with the test team to do integration, system, and acceptance testing. FIGURE 6.4 Relationship of testing types to OO structure

  9. 6.3 USE CASES • To development a system using an object-oriented approach, it is help to elicit requirements and describe them with a technique known as use case • A use case describes particular functionality that a system is supposed to perform or exhibit • The entity interacting with the system is called anactor,and it can be a user,a device or another system • Use case diagrams have four elements: actors, case, extension(范围), and uses

  10. 6.3 USE CASES ROYAL SERVICE STATION REQUEREMENTS Book Page 197 SIDEBAR 6.1 FIGRUE 6.5 Overview of Royal Service Station FIGURE 6.6 First extension of Royal Service Station diagram to include preventive maintenance

  11. 6.3 USE CASES FIGURE 6.7 Second extension of Royal Service Station Diagram to include credit card system

  12. 6.3 USE CASES • Finally, we extend the system to include all participants(参与者). To do that, we look for all entities(实体) in the environment that interact(互相影响) with the system to accomplish a task or provide a service. We can use a set of questions to help us identify participants: • What users or groups use the system to perform a task? • What users or groups are needed so that the system can perform its functions? • What external systems use the system to perform a task? • What external systems, users, or groups send information to the system? • What external systems, users, or groups receive information from the system?

  13. 6.3 USE CASES FIGURE 6.8 Third extension of Royal Service Station diagram to include inventory and accounting

  14. 6.3 USE CASES Once we have use cases,we can examine them further to find existing and potential problems. For example, we can ask the following kinds of questions: • Do the use cases use the right terminology? That is, are there two or more terms to describe the same entity or actor in the requirement? • Do the activities match the perspectives? That is ,does a use case describe system interaction with a participant in a way that is consistent with the description of the participant?

  15. 6.3 USE CASES • Are the descriptions of activities and participants clear and complete? Is there more than one way to interpret the description? • Is there an interaction described that is missing its complementary participant description? • Is there an external system or set of users described but not actually involved in an activity or interaction with the system? • Is it clear when each activity starts and ends?

  16. 6.4 REPRESENTING OO: AN EXAMPLE USING UML UML in the process UML is a notational approach that is popular for describing OO solutions. Figure 6.9 shows how UML can be used in requirements specification, design, and coding. FIGURE 6.9 How UML supports the development process

  17. 6.5 OO SYSTEM DESIGN The design process starts with a statement of the requirements. We try to extract nouns (析取名词), looking for particular items that can suggest our first cut at object classes.we seek(寻找): • structures • external systems • devices • roles • operation procedures • places • organization • thing that are manipulated(使用) by the system to be built

  18. 6.5 OO SYSTEM DESIGN Example: the first Royal Service Station requirement: A customer has the option to be billed automatically at the time of purchase(of fuel, maintenance or parking ) or to be sent a monthly paper bill. In either case, customers can pay using cash, credit card, or personal check. Royal Service Station fuel is sold according to price per gallon, depending on whether the fuel is diesel, regular, or premium. Service is priced according to the cost of parts and labor. Parking is sold according to daily, weekly, and monthly rates. The prices for fuel, maintenance services, parts, and parking may vary; only Manny, the station manager, can enter or change prices. At his discretion, Manny may designate a discount on purchases for a particular customer; this discount may vary from one customer to another. A 5% local sales tax applies to all purchase

  19. 6.5 OO SYSTEM DESIGN • From this requirements statement,we can extract several tentative classes, including • Personal check • Paper bill • Credit card • Customer • Station manager • Purchase • Fuel • Services • Discounts • Tax • Parking • Maintenance • Cash • prices

  20. 6.5 OO SYSTEM DESIGN These questions can as guidelines for what can be included in a list of candidate classes: 1. What needs to be “processed” in some way? 2. What items have multiple attributes? 3. When do you have more than one object in a class 4. What is based on the requirements themselves, not derived from you understanding of the requirements? 5.what attributes and operations are always applicable to a class or object? These questions can help us to group the candidate classes and objects as show in table 6.2

  21. 6.5 OO SYSTEM DESIGN

  22. 6.5 OO SYSTEM DESIGN Next we examine other requirements to see what they add to our exiting table of attributes and classes ,for example The system applies only to regular repeat customers. A regular repeat customer means a customer identified by name, address, and birthdate who uses the station’s services at least once per month for at least six months The system will send periodic message to customers, reminding them when their vehicles are due for maintenance. Normally, maintenance is needed every six months

  23. 6.5 OO SYSTEM DESIGN

  24. 6.5 OO SYSTEM DESIGN For the full set of requirements, we might expand our table to include all of the classes in table 6.4

  25. 6.5 OO SYSTEM DESIGN Next,we identify behaviors that be described in our design. From the requirements statements, we extract verbs again,we can look for particular items that suggest behaviors • imperative verbs • Passive verbs • Actions • Things or reminded events • Roles • Operation procedures • Services provided by an organization

  26. 6.5 OO SYSTEM DESIGN Design classes FIGURE 6.10 Class box representing a bill

  27. 6.5 OO SYSTEM DESIGN Relationships FIGURE 6.11 Inheritance relationship

  28. 6.5 OO SYSTEM DESIGN FIGURE 6.12 Association of classes

  29. 6.5 OO SYSTEM DESIGN FIGURE 6.13 Type of class relationships

  30. 6.5 OO SYSTEM DESIGN FIGURE 6.14 Additional UML notation for notes and qualifiers

  31. 6.5 OO SYSTEM DESIGN FIGURE 6.15 First cut at Royal Service Station design

  32. 6.5 OO SYSTEM DESIGN FIGURE 6.15 Second cut at Royal Service Station design

  33. 6.5 OO SYSTEM DESIGN FIGURE 6.15 Third cut at Royal Service Station design

  34. 6.5 OO SYSTEM DESIGN FIGURE 6.18 Package diagram for the Royal Service Station

  35. 6.5 OO SYSTEM DESIGN FIGURE 6.19 Sequence diagram for the refuel use case

  36. 6.5 OO SYSTEM DESIGN FIGURE 6.20 Collaboration diagram for the packing use case

  37. 6.5 OO SYSTEM DESIGN FIGURE 6.21 State diagram example

  38. 6.5 OO SYSTEM DESIGN FIGURE 6.22 State diagram for inventory class

  39. 6.5 OO SYSTEM DESIGN FIGURE 6.23 State diagrams for inventory class

  40. 6.5 OO SYSTEM DESIGN FIGURE 6.24 Activity diagram notation

  41. 6.5 OO SYSTEM DESIGN FIGURE 6.25 Activity diagram for inventory class

  42. 6.6 OO PROGRAM DESIGN Our program design efforts begin with the objects and classes from the system design, but we must embellish and modify them to include more items: • nonfunctional requirements, such as performance and input/output constraints • reused components from previously built systems • reusable components intended for use in more systems than just the one at hand • user interface requirements • data structure and management details

  43. 6.6 OO PROGRAM DESIGN Design Aids(设计工具) No one way of designing is best for all situations. The only guideline that applies to all system is this:design for change. No matter what system you are building, it is likely to change at some time or other. There are many OO-related techniques to help you make the system more flexible and maintainable. • A toolkit: is a set of related, reusable classes that provide a well-defined set of functionality. For example, you may employ a toolkit to build the user interface from buttons and windows, rather than write the code anew yourself.

  44. 6.6 OO PROGRAM DESIGN • Frameworks and patterns are also design aids. They differ form a toolkit in that they are more focused on design reuse than on code reuse. For example, suppose you are building an interactive display of stored values. Gamma et al suggest that you use the mode-view-controller pattern. The model is a set of classes that contain the stored information. The view is a set of classes that implement the user interface. The controller classes control the interaction between the user interface and the stored data.

  45. 6.6 OO PROGRAM DESIGN A pattern is a template of abstract architectural elements that can be used guide you in generating you design.Every pattern has a context and forces defined with it. The context explains the situations in which the pattern would be appropriate. The force are elements of the context that vary to some degree. A framework is a reuse of part of a domain-specific design. It is more specialized than a design pattern, and it can incorporate patterns in its specification.

  46. 6.6 OO PROGRAM DESIGN User Interface Design To complete the user interface portion of a program design, we must consider several issues: • defining the humans who will interact with the system • developing scenarios for each way that the system can perform a task • designing a hierarchy of user commands • refining the sequence of user interactions with the system • designing relevant classes in the hierarchy to implement the user interface design decisions • integrating the user interface classes in the overall system class hierarchy

  47. 6.6 OO PROGRAM DESIGN FIGURE 6.26 Transition from paper to screen

  48. 6.6 OO PROGRAM DESIGN FIGURE 6.26 Possible design for new billing screen

  49. 6.6 OO PROGRAM DESIGN Data Management Design The program design must also address ways to store and recover persistent objects. The data management takes into account the system requirements and constraints, we must lay out a design for the objects and for their operations. We can perform this task in four step: • Identify the data, data structures, and relationships among them. • Design services to manage the data structures and relationships • Find tools, such as database management systems, to implement some of the data management tasks. • Design classes and class hierarchies to oversee the data managementfunctions

  50. 6.6 OO PROGRAM DESIGN FIGURE 6.28 Implementing the class using a relational database

More Related