We have seen that abstraction is useful during software design both for expressing the instructions of an algorithm and for describing algorithm’s data. But abstraction can be used even before the process of software design begins.
Thermostat Too
heatSwitchSetting: ( COOL / OFF / HEAT )
fanSetting: ( ON / AUTO )
temperatureSetting: integer
setMainFunction( f : COOL / OFF / HEAT )
setFan ( b : ON / AUTO )
setTemperature( t : integer )
Use case diagrams are a technique for depicting a system—software sys- tem or some other system—by way of interaction between computer users and a system. The two main components of a use case diagram are actors and use cases. Each actor represents a group of users of similar type, and a use case is an action that can be performed by the system. Lines are drawn from each actor to the particular actions that this type of user can perform.
Figure 4.19 is a simple use case diagram that describes the work of a cab driver. The single actor shown in this diagram is the cab driver and there are four use cases to abstract four significant actions performed by the actor.
Figure 4.20 is a use case diagram for a more complex system: a com- puter program for online student course registration. In this case a rect- angle has been drawn around the actions to indicate that they collectively represent the functionality of the registration system.
Padlock
dialPosition : integer
latch : (OPEN / CLOSED)
turnLeftTo( j : integer )
turnRightTo ( j : integer )
pullLatchOpen()
pushLatchClosed()
FIGURE 4.18 Padlock class diagram.
Pick up taxi from depot Pick up next passenger Deliver passenger & collect fare Return taxi to depot Cab Driver
Actors of a use case diagram are grouped into roles. The reason for the different roles is to group users according to their shared actions. In the registration example there are three roles and, therefore, three actors: stu- dent, registrar, and professor. Students can perform four actions: register- ing for a class, canceling a class registration, logging in, and viewing online courses. Professors do not need to register for classes or cancel such enroll- ment, but they might want to view their class lists or increase/decrease the number of possible students who can enroll. The registrar needs to be able to perform still other actions. It is common for some actions to be avail- able to multiple actors. For example, students, professors, and registrars must all be able to log into the student registration system.
Use case diagrams may also depict relationships between actions. Two of the more common relationships are labeled «extend» and «include».
Cancel a course registration Register for a course Registration System Change maximum course size
Student Log in securely
View courses Display class list Create new course Cancel course Professor Registrar
An «extend» relationship occurs whenever one action is an extension or specialized version of another. An «include» relationship results from one action making use of another as part of its function. Figure 4.21 contains examples of both of these relationships.
This use case diagram illustrates a simplified version of the checkout system in a grocery store. Two actors—the customer and the checkout clerk—are pictured. The primary action of a customer is to purchase items from the store. However, liquor is handled somewhat differently because of the need to be certain that the customer is of legal age to purchase liquor. Therefore, the action of purchasing liquor is a specialized version of making a purchase.
There are three «include» relationships pictured in Figure 4.21. The action of purchasing liquor involves the action of verifying the customer’s age. Likewise, receiving money from the customer and printing a sales receipt are both actions that are a part of completing the sale.
Purchase liquor Purchase item <<<include>>> <<<include>>> Grocery Store Complete the sale Print sales receipt Customer Checkout Clerk Verify age of customer Receive cash from customer <<<extend>>> <<<include>>>
4.7 SUMMARY
The four problem-solving techniques—problem definition, logical reason- ing, decomposition, and abstraction—that make up the foundation of this chapter form an interconnected structure that are at the core of compu- tational thinking. Problem definitions are decomposed into functional requirements that are typically expressed abstractly using forms borrowed from logic. Deductive reasoning is based in logical reasoning. The 3-tiered design model is itself a decomposition into three abstract modules, one of which is focused on the logic of the processing solution. Similarly, top- down design, prototyping, and data decomposition all rely upon problem definition, logical reasoning, and abstraction.
The five patterns of control—sequential execution, selection, repetition, control abstraction, and concurrency—are essential for expressing algo- rithms, and algorithms are the form of problem solutions in the software world. Diagrams are also helpful in the process of designing software solu- tions. Use case diagrams are used to analyze the problem; state-activity diagrams help ensure completeness of a set of functional requirements; and class diagrams are effective tools for software design.
Most of the problem-solving techniques of this chapter had their ori- gins long before computers existed and most have utility that extends well beyond computer science. What employee could not benefit by improved problem-solving skills? Occupations from scientific research to crime scene investigation are rooted in logical reasoning. Sociologists, econo- mists, and politicians all decompose populations into abstractly defined groups—another form of data decomposition.
4.8 WHEN WILL YOU EVER USE THIS STUFF?
Life can be viewed as an endless sequence of problems. When you wake up you must solve the problem of what clothes to wear and what to eat for breakfast, and at the end of the day you must decide when to retire and when to set the alarm clock for your next day. The middle of our workdays tend to result in more complex problems, and it is these more challenging problems that determine things like success and paycheck size. It is also these more challenging problems that benefit from well-honed problem- solving skills.
How many times have you been overwhelmed by a new project, say- ing something like, “I don’t know where to begin”? There are two good answers to this question in this chapter: (1) begin by defining the problem,
and (2) you can always limit the focus of the problem by using abstrac- tions. The chapter goes further to teach strategies, such as listing func- tional requirements for problem definition and use case diagrams for abstraction.
Many problem-solving strategies are not unique to computer science. Divide and conquer problem solving is something many would label as common sense. However, computer science applies divide and conquer in many ways from top-down design to prototyping, from dividing data in half for a binary search to identifying simultaneous efforts in multitasking.
Logical reasoning also permeates all of humankind’s discoveries. From a few experiments, scientists can generalize findings by careful use of inductive reasoning. The scientist might also rely upon the patterns from prior observations as a way to determine which future experiments are of interest, thereby applying a form of deductive reasoning.
Yes, we are all problem solvers. But when it comes to problems with algorithmic solutions, no one understands better how to solve the prob- lems than the computer scientist.
REFERENCES
1. Doyle, Sir Arthur Conan. The Sign of Four. (1890).
2. Miller, G. “The magical number seven, plus or minus two: Some limits on our capacity for processing information.” The Psychological Review 63 (1956): 81–97.
TERMINOLOGY
3-tiered architecture abstraction actor algorithm analysisattributes (of a class) binary search class diagram content expert control abstraction control flow control structure customer (software) data abstraction data organization decomposition deductive reasoning design (of software)
divide and conquer functional requirements grid computing inductive reasoning linear search logical reasoning multitasking nonfunctional requirements operations (of a class) outlining patterns problem definition prototype repetition requirements (software) role (of users)
search algorithm sequential (execution) state-activity table successive prototyping top-down design use case
use case diagram
EXERCISES
1. Write a group of functional requirements in the style of Figure 4.1 for the task of setting the time on a common wristwatch.
2. Draw a class diagram for the wristwatch described in the previ- ous exercise.
3. Draw a class diagram for the DVD player described in Figure 4.1. 4. Create a use case diagram for handling books in a library. Be certain
to capture the work of patrons and librarians.
5. For each of the following situations, describe whether the reasoning is deductive or inductive.
a. Scientific investigation relies upon two different laboratories that are able to repeat the same experiment before publishing the result. b. Using the current weather radar and local forecast for the day,
you decide whether to schedule an outdoor party.
c. Based upon the US Constitution lawyers argue a specific case in front of the Supreme Court.
d. A mathematician proves a new theorem by applying accepted axi- oms and other theorems as reasoning for each step of the proof. e. A painter decides whether to use oil or water colors for a particular
painting based upon past experiences using these different media. f. A forensic expert concludes that someone died of natural causes,
based upon her education and the results of an autopsy. 6. Consider the following set of functional requirements:
Index: W1 Name: Parka
Action: If the current temperature is less than 0 degrees Fahrenheit
and the forecast is for snow, then you should wear a parka.
Index: W2 Name: Raincoat
Action: If the current temperature is greater than 0 degrees Fahrenheit
and the forecast is for snow, then you should wear a raincoat.
Index: W3 Name: Umbrella
Action: If the current temperature is greater than 0 degrees
Fahrenheit and the forecast is for precipitation, then you should carry an umbrella.
Index: W4 Name: Leather
Action: If the current temperature is less than 0 degrees Fahrenheit
and the forecast is for no precipitation, then you should wear a leather coat.
a. Create a state-activity table for this set of requirements. b. Identify all of the conflicts in the set of requirements.
c. Identify all of the ways in which the requirements are incomplete.
7. In Section 4.2 the following algorithm is proposed as an incorrect way to attempt to swap the contents of two variables. Assuming that the myDog variable is assigned “Fido” initially, while yourDog stores “Rover,” then what values do each variable store after this algorithm executes?
myDog ← yourDog yourDog ← myDog
8. Suppose you are given the task of looking for a particular name in a telephone book with roughly 4,000 names.
a. Which name of the phone book would be the first one examined using a linear search?
b. Which name of the phone book would be the first one examined using a binary search?
c. Assuming the person you are searching for is not in the phone book, how many names would be examined to discover this when using a linear search?
d. Assuming the person you are searching for is not in the phone book, about how many names would be examined to discover this when using a binary search?
129
C h a p t e r