Our goal is to provide an understanding of the object-oriented system development process and give students the opportunity to become competent in some of the techniques involved. Many thanks are due to Matthew Britton, who provided technical advice on programming matters and helpful comments on the final chapters of the book.
Introduction
Learning outcomes
Key words that you will find in the glossary"
How to get the best from this book
All chapters in the main body of the book follow a similar structure, introducing the topic of the chapter with examples drawn mainly from the wheel case study. This chapter concludes with a list of system requirements that is developed in the rest of the book.
The system life cycle
Appendix A collects all the material related to the Wheels bike rental case study, and Appendix B contains introductory information about a second case study, which can be used as a tool for practicing all the techniques covered in the book. There is also a bibliography for readers who want to know more about certain topics in more detail, and a glossary with definitions of all the key words used in the book.
Traditional life cycle models
A set of models that each provide a different view of the system, which together provide a complete picture. A skeleton version is produced that covers the full functionality of the system and then refined as development progresses.
The object-oriented approach
For example, requirements development and analysis will of course take place initially, but there may well also be some design activity and even some implementation if all or part of the system is to be prototyped. Instead of the ordered table in Table 1.2, the object-oriented approach to development views the relationships between workflows and development phases in the same way as the spider web in Figure 1.2, where any phase can involve all workflows, and a workflow can be executed in any phase.
C nttr~ I
While traditional systems life cycles were concerned with issues such as quality, ease of customization, and potential reuse, they tended to view these as adjuncts to the core development process. In the object-oriented approach, such issues are considered central and developers are encouraged to take them into account throughout the time they are working on the system.
The Rational Unified Process (RUP)
RUP follows the phases of the generic object-oriented life cycle (initialization, processing, construction, and transition) described earlier in this chapter. Therefore, we describe the development of the Wheels bicycle rental system within a simplified object-oriented framework.
The Unified Modelling Language (UML)
Abstraction provides a means to concentrate only on those aspects of the system that are currently of interest, leaving aside other details for the moment. One of the primary uses of the models is as a basis for discussion, as talking about the system as represented helps identify gaps and inconsistencies in the information.
UML models
The use case view describes the external behavior of the system and is captured in the use case model discussed in Chapter 3. The blueprint view describes the classes (including attributes and operations) of the system and their interactions.
Introduction to the case study
Mike has recently come to the realization that, although he has a successful business, he will not be able to expand as he would like unless he gets his business processes up to date, and that he will need to make them much more effective to be able to do that. use of the computer.
Chapter summary
Bibliography
18 STUDENT GUIDE TO OBJECT ORIENTED DEVELOPMENT. bike number, type, size, make, model, daily payment and deposit. 1998) Visual Modeling with Rational Rose and UML, Addison-Wesley, Reading, MA. 1991) Object Oriented Modeling and Design, Prentice-Hall, Englewood Cliffs, NJ.
Quick check questions
Requirements for the Wheels case study system
Towards the end of the chapter you will find a list of requirements that the new Wheels system must meet. These requirements form the starting point for the object-oriented development of the Wheels system described in the rest of the book.
Requirements engineering
It is not possible to do justice to the entirety of requirements engineering within the scope of this book, but if you are interested in the topic and would like to read more about it, you will find a list of useful texts at the end of the chapter. and in the bibliography. In this chapter we simply provide a brief description of the key stages of requirements development, and show how some of the most useful techniques can be applied to the Wheels case study.
Requirements elicitation
9 One of the mechanics checks the bike and confirms that it has been in good condition. A summary of the interview with Annie Price, Wheels store manager, can be seen in Figure 2.8.
List of requirements for the Wheels system
This chapter provides more details about the Wheels bicycle rental system which is used as a source of examples in the rest of the book. It also provides a summary of the requirements for Wheels that form a starting point for the object-oriented development described in the rest of the book.
Exercises
3 as a guide, design a questionnaire to find out if there is a market for sporting goods rentals among Wheels' current customers. 5, write a scenario to illustrate what happens when a customer, Sheena Patel, returns a bicycle on the due date but there is some damage to the front wheel which is charged to s.
Use cases
Key words you will find in the glossary
Once the use case model has been completed and checked with the user, it forms a core set of structured information upon which other system models will be based. The use case model structures the system in the user's view of its main tasks, the class diagram structures the system into logical software units.
USE CASE DIAGRAM 41
The use case
9 The system confirms that it is a man racer and displays the daily rates and deposit. In summary, the purpose of the use case model is to describe, from the user's perspective, what the system does.
Use case descriptions
Next, it is useful to have more detailed structured descriptions known as extended use case descriptions (see Figure 3.6). This section describes the main alternative courses of action Figure 3.7 Model for an extended use case.
Actors and actor descriptions
More precisely, an actor represents a particular way of using the system; a way to interact with the system to achieve a use case goal. Another way to think about it is that users can wear different hats when using the system.
Use case relationships" communication association, include and extend
The <
Boundary
Note that the minor use case is always modeled as an extension of the major one, i.e. if we have added <
Using the use case model in system development
Technical points
If the Receptionist issues a bike to a completely new customer, she uses the specialized use case 'Issue bike to new customer'. However, if she issues a bike to an existing customer, she uses the common use case 'Right bike out'.
Reception~
In the W he e ls case study we did not model the customer as an actor, even though it is often the customer who initiates a use case. A use case will have an essential form in the early stages of software development, before these decisions have been made.
Receptionist
In other words, the realization of a use case for a single use case requires complete iteration through all development activities. For example, we modeled "Customer pays amount owed (deposit plus rental cost)" as part of the "Issue a bike" use case.
USE CASES
CHAPTER SUMMARY 63
The use case 'Handling customer payments' (see Figure E. 5 on page 354) therefore sometimes involves looking at the system to find a product and its price. Redraw the use case diagram shown in Figure E.13 on page 361 to avoid having duplicate functionality in use cases.
ObJects and classes: the basic concepts
Key words you will find in the glossary"
We briefly summarize why the object-oriented community bases their software decomposition on the object rather than on traditional top-down functional decomposition. Finally, we examine the various relationships that may exist between objects and explain what they mean in the context of the developing system.
Why a new development method was needed
Although objects are based on the data in the system, this does not mean that object-oriented software ignores the required functionality. In the traditional structured approach to development, some of the models used to capture user requirements (such as the data flow diagram) were abandoned during the design stage where a new modeling technique was used to specify the structure of the code (for example, structure maps). .
We can tell, for example, whether a bank account object is in an overdrawn state by looking at the value of the state attribute. The object's public interface is the only thing the rest of the program knows about the object, other than its name.
9 If the interface itself is not changed, the internal code of a module can be changed without affecting any client modules. In this sense, the internal code of a module (as well as any data) is encapsulated, it is hidden from the rest of the program.
A class of objects is a group of objects with the same set of attributes, the same relationships, and the same behavior. We can then think and model in terms of classes of objects and their relationships with each other.
Relationships between classes
In the inheritance hierarchy shown in Figure 4.29, the perform() operation occurs in all classes in the hierarchy. We can populate this with objects of all comparable classes in the robot hierarchy, as shown in Figure 4.31.
Common problems
The object-oriented approach is based on the object, a software construct that aims to overcome the problems of structured software. 1998) Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design, Prentice Hall, New Jersey.
I tatione,Yl
Sort items into categories such as stationery (pens, notebooks, etc.), communication (cell phones, etc.), clothing (hats, gloves, etc.). d Study the categories and try to refine them into subcategories, eg within the stationery group there may be stationery, electronic equipment, etc. e Repeat d) until you no longer improve. See if any of the items on the table can be detached (without breaking them).
I Pen ]
This question relates to the rugby counterexample in the section on encapsulation and data hiding. Complete Table 4.3 (related to the European hierarchy), which lists object names, classes, attribute values, and responses to the greet() message.
The c ass diagram
Subsequently, with classes added that are part of the solution and not the problem domain (eg interface classes), it is used to design a solution. Finally, with classes added to facilitate implementation (eg buttons, windows, mouse listeners, etc.), it is used to design the application code.
Stages in building a class diagram
In the class diagram in Figure 5.1, leases are modeled as an association for customers and bicycle. The list of requirements (Rio) specifies that the system 'keep track of the condition of each bike, e.g.
Packages
Bike [~ SpecialistBike
Using the class diagram in system development
As we said at the beginning of the chapter, there are many ways to construct a class diagram. It is not mandatory to use grouping or any relationship construct in a class diagram.
Identifyi ng fu nctiona ity
CRC cards and interaction diagrams
In this chapter we discuss how to use the CRC technique to divide responsibilities among classes and process the interaction between classes required to implement use case scenarios. We then discuss how to translate these high-level responsibilities into operations in classes and how to describe the functionality of the operations using process specifications.
Identifying operations using the CRC card technique
Each class is considered to have certain responsibilities to provide services to the user of the system (such as maintaining a customer record) or to another class (such as providing data for a calculation). It illustrates how the overall functionality of the 'Issue bike' use case will be divided between the classes in the system.
Customer)
9 The system confirms that it is a women's mountain bike and displays the daily price(s) and deposit(s) (: Bicycle).
Payment collaborating with :Customer)
Payment [:Bike
This is again the responsibility of the Bike class, so we need another operation on Bike, getCharges(no.Days). It is the responsibility of the Hire Class to record these details; we need an operation to create a new Hire object and record the details.
Interaction diagrams
9 The system confirms that this is a women's mountain bike and displays the daily rate (s) and the deposit (s. 4 The system confirms that this is a women's mountain bike and displays the daily rate (s) and the deposit (s.
Specifying operations
9 The signature of the action (its name, any arguments and the type of values it returns) 2. The relevant actions are shown under each rule in the lower right corner of the table.
Using the CRC cards and interaction diagrams in system development
For example, in the sequence diagram in Figure 6.22, I am trying to model the behavior of the customer and the receptionist. Following the guidelines given in the section on deriving operations from CRC responsibilities, identify two operations required on the reservation class.
State Diagrams
Key words that you will find in the glossary
States and events
The state of the object here refers to the situation in which it is meeting some condition (such as a bank account having some money) or waiting for an event (such as someone trying to withdraw or deposit money) . We can tell if an object is in a certain state by looking at the values of some of its attributes and its connections to other objects.
An example of a simp e state diagram
While the "In credit" state is, the "Deposit money" event leaves a BankAccount object in the same state. Another event that a BankAccount object can undergo while in the 'In Credit' state is a 'withdraw funds' event.
Constructing a state diagram
First stage of the state diagram for the job application class .. application form received and . , dh details registered dr Application logged ) read by manager [shortlisted]. The job application class behavior description states that an applicant can withdraw at any time.
An example from the Wheels case study
