CS作业案例之Python Software Engineering 265 Software De
当前位置:以往案例 > >CS作业案例之Python Software Engineering 265 Software De
2018-10-29

Software Engineering 265 Software Development Methods Summer 2018
project 3



Due: Thursday, July 19th, 11:55 pm via a push by git “push.

No late submissions accepted

Programming environment
For this project you must ensure your work executes correctly on the machines in ECS B238 (i.e., these have Python 3.6 installed). You are free to do some of your programming on your own computers; if you do this, give yourself a few days before the due date to iron out any bugs in the Python script you have pushed to your remote repository.

Individual work
This project is to be completed by each individual student (i.e., no group work). Naturally you will want to discuss aspects of the problem with fellow students, and such discussion is encouraged. However, sharing of code fragments is strictly forbidden without the express written permission of the course instructor (Zastre). If you are still unsure regarding what is permitted or have other questions about what constitutes appropriate collaboration, please contact me as soon as possible. (Code-similarity analysis tools may be used to examine submitted programs.)

Objectives of this project
· Continue to learn features of the Python 3language.

· Use some of the object-oriented features of Python3.

· Use some of the error-handling features of Python3.

· Use some of the regular-expression functionality in Python3.

· Use Git to manage changes in your source code and annotate the evolution of your solution with “messages” provided duringcommits.

· Test your code against the twenty provided testcases.

· Be prepared to justify your script’s handling of errors during the project demonstration.

This project: formatdriver.py and uvroff_class.py

For this project you will wrap a solution to the formatting problem into a class. The class constructor will accept a filename and a list of strings. The formatted output will be available from the class instance via the get_lines() method.

· The class must be named UVroff and appear in a file nameduvroff_class.py.

· The script that uses this class is in a file named formatdriver.py. The file has been provided and you must not modifyit.

· If a non-blank filename is provided to the formatdriver.py script, then thatfile will be opened and its contents formatted.

· If no argument (i.e., filename) is provided to the formatdriver.py script, then the contents of stdin will beformatted.

· If an instance of UVroff is used without being called from formatdriver.py, and no filename is provided to the constructor (i.e., None is given as the filename argument), then the lines in the list provided as a parameter will be formatted. Put differently, the UVroff constructor will accept (besides “self”) two parameters: a string and a list of strings, with the latter having the value of None when the constructor is called from formatdriver.py. Have a look at the code in testlines.py in the /home/zastre/seng265/assign3 directory to find out how a list is passed to the constructor. (uvroff_class.py must therefore contain an implementation of UVroff that provides interface as is seen to be used in formatdriver.py.) Also provided is testnull.py that checks to ensure formatted lines are returned as a list (i.e., the formatted lines must not be output directly by the UVroffclass!).

· Global/module scope variables are not permitted in your solution. However, classes can and should have instance variables. Class variables must only be used for values that are constant (i.e., more than oneUVroff object should be permitted to exist in someprogram).

· The formatting specifications from the second project are to be usedfor this project.

· The script that uses this class will be in a file named formatdriver.py (as mentioned above).

· You must provide some error handling in UVroff. Your task is to enumerate the things that could go wrong when faced with such a formatting task, and to either provide or suggest the code for handling each error item. The provided test files are not meant to contain errors, so you may create up to five of your own test files containing errors. These must be in adirectory

named assign3/tests with names starting with the “e” (e.g., e_in01.txt and e_out01.txt, etc.). Document your chosen error cases—and your code’s handling of them—in a Markdown file named error_handling.md, and place this file in your a3 directory. (For more information on the Markdown file format, visit https://en.wikipedia.org/wiki/Markdown.)

· The solution must be written in Python 3 and work correctly on the workstations in the ELW B238laboratory.

With formatdriver.py using the code within your completed uvroff_class.py, the input would be transformed into the output (here redirected to a file) via one of the two following UNIX commands:

$ ./formatdriver.py /home/zastre/seng265/assign3/tests/in11.txt > \
./myout11.txt

% cat /home/zastre/seng265/assign3/tests/in11.txt \
|./formatdriver.py > ./myout11.txt
where the file myout11.txt would be written in your current directory. (Note: The backslash syntax shown above for the Unix commands is simply to permit the command to continue on the next line within bash.)

Exercises for this project
1. Within your Git repository project create an a3 subdirectory. Use the test files in /home/zastre/seng265/assign3/tests. (Note for the observant: These are the same test files as used for the previous project.) The formatdriver.py and your uvroff_class.py script files must appear in your repository’s a3 subdirectory. Ensure that when you create the assign3 directory, you immediately perform a git add and gitcommit.

2. Reasonable run-time performance of your script is expected. None of the test cases should take longer than 15 seconds to complete processing on a machine in ELWB238.

What you must submit
· Python 3 files named formatdriver.py (i.e., just a copy of what has been provided to you) and uvroff_class.py (i.e., your project solution) your git repository.

· A text file named error_handling.md which enumerates the errors that are addressed by yoursubmission.

· Additional test-case files for your error-handling implementation, with the files placed into youra3/tests.

Evaluation
Our grading scheme is relatively simple and is out of 10 points. We will award grades within the categories below.

· 10/10: formatdriver.py and uvroff_class.py run together without any problems. All tests pass. Errors have been enumerated in error_handling.md and are either suitably handled or a sensible response strategy has been suggested. The program is clearly written and uses functions appropriately (i.e., is wellstructured).

· 8/10 : A submission completing the requirements of the project. formatdriver.py and uvroff_class.py run together without any problems. All tests pass. Errors have been enumerated in error_handling.md and areeither suitably handled or a sensible response strategy has beensuggested.

· 7/10: A submission completing most of the requirements of theproject. formatdriver.py and uvroff_class.py run together with some problems. Some important error cases have beenoverlooked.

· 5/10: A serious attempt at completing requirements for theproject.

formatdriver.py and uvroff_class.py run together with quite a few problems.

· 4/10 or lower: Either no submission given, or submission represents very littlework.





在线提交订单