代写Anteater Inn、代做Anteater Inn代写

日期：2018-05-26 10:15

Anteater Inn

Assignment summary: You will write a program to keep track of reservations at "Anteater Inn", a small inn.

This assignment is divided into five stages. Each succeeding stage is built upon what you have already written for the previous stage. We expect you to design, write, and test this program according to these stages—first get the first-stage program working, then modify it to satisfy the second stage, and so on. As always, be sure to keep a copy of each completed stage. That way, if you decide you've gotten off on the wrong track for a stage, you can start again easily from the end of the previous stage, without the painstaking task of removing each addition. You should make sure that each stage is entirely correct and working perfectly before you go on to the next. As you complete each stage, you should demonstrate briefly to your TA or tutor that it works correctly before you go on to the following stage. The code you turn in will be the last stage you completed correctly.

Development by stages is good software engineering practice. It is far better to have a program that is correct but incomplete (i.e., it doesn't implement all the features but what it does implement is correct) than one that contains bugs. Grading for this assignment will reflect this, too; it will hurt your score much more to turn in buggy code than not to reach some of the later stages. Let's say that again: Your score will be higher if you do the first three stages correctly than if you do all five with some bugs in the last stages.

What to turn in: On Checkmate, a single Python file containing your last-stage code. You must name your file AnInX.py, where X is one of 1,2,3,4,or 5, indicating which stage your code completes correctly, without bugs.

Grading: Your grade depends on organized development (did you design and debug each stage in sequence), completeness (does your program do everything the specification requires), correctness (does it produce the correct results), quality and clarity of your output, good modular design (i.e., organization into functions), good data organization (using data structures appropriately), and good programming style (are your identifier names descriptive, is your organization clear). You will receive appropriate partial credit for each stage you complete correctly. You will receive no credit for work on a later stage if the previous stages are incomplete or incorrect. The whole point of incremental development (i.e., stages) is to kee a programmer from biting off more than he or she can chew.

Finally, have a sense of proportion: Don't knock yourselves out to finish every stage. Many students do, but many students get high grades by turning in a correct version that doesn't complete all the stages. And every quarter, a few students turn in code they copied from someone other than their partner; that's a very sorry situation. The lab assignments count for 30% of your grade. That's 3% for each of 10 assignments. Let's say this AnIn problem is half of Lab 9; that makes it worth 1.5%. And turning in something that works correctly for an earlier stage might get you at least 50% credit. So between that and a perfectly complete program is only about 0.75% of the course, or 3/4 of a point out of 100. You'll learn more by doing more, but you can also finish it over the break to keep your skills sharp for ICS 32.

Statement of the problem: UCI has just started a program in hotel and restaurant management; its dean has established a small inn as a lab for the program's students. The dean has asked you to write the reservations software for this new inn. Your program will be called  AnIn.

Your program will keep track of the rooms available for rent (these vary, since sometimes a room is closed for redecoration) and the reservations that guests have made for these rooms.

When the full AnIn system is completed, it might have a graphical user interface, but for now your program will be a batch program; this means that you will supply one input file that contains all the commands and one output file that will contain all your output. Include these two lines in your code:

infile = open('INNcommands.txt', 'r')

outfile = open('INNresults.txt', 'w')

The automated checking depends on your using precisely those file names.

You could easily convert this program to an interactive one with a fancy user interface, where the program presents the user with a menu of commands, accepts the user's selection, prompts the user for whatever additional information the command requires, and then displays the results of that command. We made this assignment a batch program for three reasons: First, it's extra work for you to write the menu-printing and input-prompting commands, some of which you have already done in other assignments. It's easier simply to assume that the data appears in the correct format in the input files. Second, it gives you more practice reading data from external text files. Third, testing your program will be much easier when you can create files of test data rather than typing in each test interactively every time.

The input for this program comes from a single text file named

INNcommands.txt, which consists of an unlimited number of input command lines. You will create this file based on expected input described below. For each stage, you will implement (or modify) a few more commands.

Stage 1: For this stage, your program will keep track of the rooms that are available. This stage implements four commands, as described below. On each command line, the first four non-whitespace characters are the command; command letters may be upper or lower case.

ANBR

(for "add a new bedroom") followed by an integer room number (in the range 1–999). Add a new bedroom with the specified room number.

LABR

(for "list of available bedrooms"). Print a list of the bedrooms currently available. The input file may contain any number of these commands in any order; each LABR command prints a list of available bedrooms based on what has been added as of that point. See the sample output below for the format of the printed bedroom list. For this stage, it doesn't matter what order the bedrooms appear in.

PNTL

(for "print line"), followed by any text. Simply print (or "echo") a line, copying the input (not counting the PNTL and leading whitespace) to the output. You'll find it useful in testing, and it's also a simple way to make the program's reports clearer or fancier.

**

Comment, followed by any text. Like comments in a program, comment lines don't have any effect on the program's behavior; they just serve as annotations in the command file.

Below is a sample input file for this stage.

** This is a sample command file for the AnIn, Stage 1

PNTL ***********************************************************

PNTL Here is a list of available bedrooms (before adding any!)

** A well-written program works gracefully with empty lists.

LABR

PNTL ***********************************************************

** Now let's add a bedroom:

ANBR 101

LABR

** And some more:

ANBR 104

** Extra blanks around the command should be ignored

ANbr    102

   ANBr 201

   aNbr      203

LABR

PnTL Thank you for perusing the Anteater Inn Reservation System!

** That's the end of the sample data for Stage 1.

From this input file, your program should produce the following output:

***********************************************************

Here is a list of available bedrooms (before adding any!)

Number of bedrooms in service:  0

------------------------------------

***********************************************************

Number of bedrooms in service:  1

------------------------------------

101

Number of bedrooms in service:  5

------------------------------------

101

104

102

201

203

Thank you for perusing the Anteater Inn Reservation System!

One of the early questions to ask when designing a program is what data structure(s) you should use to represent the main information in the program. Making decisions like this becomes easier with practice, but there are two things to keep in mind. First, start with the simplest data structure that does the job. (For the collection of bedrooms in this stage, maybe a list of integer room numbers is good enough, or maybe a set of room numbers.) Second, accept that your first choice may not be your final choice; as the specifications become clearer or as circumstances change (or as you get to later stages in a problem like this one), you may decide that something else would work better. This kind of revision is a normal part of programming. It's no tragedy to rewrite some code in a better way, just as you should expect to revise natural-language documents. (For the bedrooms in this problem, we might decide to use a dictionary whose key is the room number and whose value is a namedtuple of room information. But we shouldn't necessarily jump to this arrangement until we're sure it helps us.)