APS106语言代做、Python程序调试、Python编程代写

日期：2021-04-21 11:13

APS106 Final Assessment

Due: April 28, 2021 at 23:59 Toronto time

As engineers around the world, including at U of T, are developing treatments, designing ventilators,

redesigning supply chains, and repurposing production lines, you, the students of APS106, will be

provided a simple dataset of information that might be collected by a COVID-19 contact tracer, and

will develop data structures that allow quick access to and manipulation of that data. We hope that

this task will give you a sense of the power of coding to gather and display data, and help in

understanding important worldwide events.

You have ten days to complete this project, but we do NOT expect this to take ten days, because we

know you’re taking other courses, and have other final assessments to complete.

Good luck!

Academic Integrity

The project is “open book” meaning that students are allowed to use a Python IDE (e.g. Wing 101), all

course material (lecture notes and videos, labs, textbook), and other offline and online resources.

A student may NOT:

? collaborate with any other student;

? consult any person, except the course instructors via the APS106 piazza site;

? submit work not wholly created by the student.

Doing any of the above is an academic offense. We will use tools to detect such offenses.

Submission of your project deliverables constitutes agreement with the following statement.

In submitting this assessment, I confirm that my conduct adheres to the Code of Behaviour on

Academic Matters. I confirm that I did NOT act in such a way that would constitute cheating,

misrepresentation, or unfairness, including but not limited to, using unauthorized aids and

assistance, impersonating another person, and committing plagiarism. I pledge upon my

honour that I have not violated the Faculty of Applied Science & Engineering’s Honour Code

during this assessment.

Any academic offence will be pursued to the full extent of University regulations.

page 2 of 11

Instructions

In addition to the instructions you’re reading now, please download the datafile tracking.csv.

There are 5 parts to this project; each is described later in this document. Some are easier than

others, but each is worth the same number of marks.

For each of the five project parts, you will submit two files:

? a Python (.py) file that is only the code for that part;

? and a .pdf file that describes how you developed and would test the code for that part.

The 5 Python files

You will likely implement this project as a single Python file. But to help us autograde your code via

MarkUS, you’ll submit it as five separate Python files, where each file “part#.py” will contain ONLY the

code you wrote for part #, where # is a number from 1 to 5.

Part 1 asks you to write a class definition, including its data and method attributes; only submit that in

part1.py. Each of parts 2 to 5 asks you to write one or two functions; for each part only submit the

requested function(s) in the corresponding part#.py file.

The only module you may import is csv. You should only import it into the .py files where it is used. If

you don't use it, don't import it.

Do NOT include any input() or print() statements in any of the part#.py files.

As in the labs, you may submit your part#.py files to MarkUS multiple times and we will mark the last

one submitted before the deadline.

The MarkUS tests that we are providing do not test your code's functionality. We are providing

some very basic MarkUS tests that are not even close to sufficient for assessing if your code works.

Our tests provide a “sanity check” to help you identify simple syntax problems and typos.

See the "Description of Provided MarkUS tests" on page 11 of this document for details.

page 3 of 11

The 5 .pdf files

Each .pdf file will contain:

? page 1 – an algorithm plan

? page 2 – a programming plan

? page 3 (and more, if you like) – a testing plan

The Algorithm and Programming Plans

Write your algorithm and programming plans before you start coding, based on examples you’ve

seen presented throughout the course, and in particular during the Friday Design Problem

sessions. The algorithm plan must fit on one page; the programming plan on another page. Write

as little or much as you think is necessary to explain how you planned to write the code for that

part.

The Testing Plan

This part of each .pdf file will document tests of the code for that part. NOTE that the testing plan

may extend to multiple pages if necessary.

For each test you propose, show the Python code used for testing, the input and expected output,

and include a description of what the test does and why you proposed the test (i.e., what is it

testing?).

We will not run these tests via MarkUS, and please do NOT include these tests in your part#.py

files. Rather, your testing plan is meant to allow another programmer (like someone grading your

project) to appreciate that you’ve thought of all possible inputs and outputs to your various

functions.

page 4 of 11

How to submit your 5 Python files and your 5 .pdf files

All files (part#.py and part#.pdf) should be submitted to MarkUS. As with the labs, MarkUS will only

accept files that are named correctly. You do not need to submit all the files at the same time. You

can submit each individual file as you complete it and run the “sanity check” MarkUS tests on each

part individually. You will be able to run these “sanity check” tests 5 times per hour.

Note that if you are including images (especially pictures of sketches taken with your phone), your

document may be larger than 5 Mb. If you wish to include pictures of sketches, you may need to

compress the image before inserting it in your document. For information on how to compress an

image inserted into a Word document, go to https://support.microsoft.com/en-us/topic/compress-apicture-4598c336-688b-4ade-a582-ef966a978ffd.

When you’re ready to submit, you will upload your python and pdf files to MarkUS. The submission

process is the same as the labs. Go to https://markus.engineering.utoronto.ca/aps106/, sign-in with

your UtorID, and navigate to the ‘final project’ assignment from the MarkUS home page. From there,

you can navigate to the ‘Submissions’ tab where you will be able to upload your files. Remember,

MarkUS will only accept files with the correct naming conventions. Once your files are successfully

uploaded, you should be able to see them listed in the submitted files table.

Each part#.pdf file must be less than 5 Mb. MarkUS will not accept

larger documents. APS106 is not responsible for documents

exceeding the 5 Mb limit.

page 5 of 11

Evaluation

Each part of this project is worth 20 marks, distributed as follows:

8 MarkUS autograding of your part#.py file

2 Algorithm plan

2 Programming plan

3 Testing Plan

5 Code quality

NOTES:

? MarkUS will evaluate your code with tests that are unknown to you, and different than the

basic tests available to you to test your part#.py files.

? The other components will be evaluated by a human being:

o When grading your algorithm and programming plans, we will assess the extent to

which you demonstrate thought about the requirements of that part of the project,

and articulate a clear approach to attacking it – even if that approach is different than

what you actually did/coded.

o Your testing plan will be evaluated by assessing the comprehensiveness of your tests,

and the logic of your explanations.

o The quality of your code will be assessed by considering clarity, simplicity, meaningful

variable names, comments, documentation, etc.

page 6 of 11

Part 1 – Represent the Contact Tracing Data

In this part, you will design and implement a data structure that will be used to represent information

about an infected person, and others infected by contact with that person.

TO DO:

Create an Infected_person class that contains the following data and method attributes:

Data Attribute Name Type Format Description

id str

unique identifier of an infected

person

infected_on str YYYY-MM-DD date that person was infected

infected list list of Infected_person

objects others infected by this person

Method

Name

Input Parameters Output Description

__init__ self

– type:Infected_person

pid

– type: str

date

– type: str

– default value: “unknown”

Constructor of class Infected_person:

- initializes id to pid

- initializes infected_on to date

- initializes infected to an empty list

__str__ self

– type: Infected_person

str Returns a string representation of the object

in the form "(A,B,C)" where:

- A is the object’s id

- B is the infected_on date

- C is the size of the infected list

infects self

– type:Infected_person

person

– type: Infected_person

Adds a person to the infected list. The

order in which the objects are stored in the

infected list does not matter. The list

should not contain duplicates.

page 7 of 11

Part 2 – Parse the Contract Tracing Data

In this part, you will design and implement a function to process the content of a file containing data

on persons and infections. The data file is in csv format and has the following structure:

id,infected-by,date

a3959d249c3444dbb36310bb16e2a689,d03ba6ffa3b5475989ce477973d1617d,2021-02-09

ae66eefa796a4a59aa375d0514620fcf,209864c2f0f543089f8466e7bcff3acd,2021-01-27

435e781627db4635b966c3d4fd493728,d161fa8d17f244d186ef9a47b40e931c,2021-03-21

0583968bf83442858853ef7c2d0f75cb,c921ae9021ab440aa440601e20fdb45f,2021-01-16

Notes about the data file:

? There is a header row as shown above.

? Each row of the file after the header contains the id of someone infected by COVID, the id of

the person who infected them, and the date of the infection. Someone can only be infected

once, by one other person. However, one person may infect many others on the same or

different dates.

? There may be persons who appear in the infected-by column who do not appear in the first

(id) column. For these persons, the date of infection, and person that infected them, are

unknown.

? The date is a string of format "YYYY-MM-DD".

? Make no assumptions about the order of the data in the file (i.e., it is not necessarily in

alphabetical or chronological order).

TO DO:

Write a function parse_contacts whose only argument is a string filename, which is the name

of the data file the function will process. parse_contacts then returns a dictionary of the

following format:

{id : Infected_person-object, ...}

where:

? each key, id, is a string representing a person’s id;

? each value is an object of type Infected_person

Notes:

? all persons mentioned in the data file (in either the id or infected-by columns) should

have an entry in the dictionary

? each row in the data file lists an infected person and who they were infected by. An

Infected_person object contains information about an infected person and who they

infected. Be mindful of these details in order to successfully translate the data file into the

required dictionary representation.

? if the data file is empty (i.e., has no rows), parse_contacts should return an empty

dictionary.

page 8 of 11

? You may assume that all test data files will have the format described above. You may also

assume that any non-empty test data file will contain a header row (and only one header row)

as its first line and at least one data row.

? DO NOT hardcode the name of the file. We will test your code with different data files.

Part 3 – Identify the Top Direct Superspreaders

A “direct superspreader” is a person who directly infects many others. In this part, you will design and

implement a function to identify the top direct superspreader(s): the person(s) that directly infected

the most other persons.

Notes:

? there may be one top direct superspreader, or more than one in case of a tie

? the data file lists direct infections. We will look at indirect infections in Part 5.

TO DO:

Write a function find_top_direct_superspreader:

? its only argument is a dictionary with format {id : Infected_person-object,

...}

o this is the output of function parse_contacts in Part 2

? it returns a list of person id’s corresponding to top direct superspreader(s), [id1, id2,

...]. Again, remember that there may only be one, or more than one in the case of a tie. The

order in which the id’s are stored in the list is not important. The list should not contain

duplicates.

o If the input is an empty dictionary, find_top_direct_superspreader should return

an empty list.

o You can assume that find_top_direct_superspreader will be called with a

dictionary as its only argument. You can also assume that the dictionary, if not empty , will

have the format {id : Infected_person-object, ...}.

page 9 of 11

Part 4 – Find Superspreading Dates

We define a superspreading date as the date in which the most persons were infected. Ties are

possible and so there may be multiple direct superspreading dates.

TO DO:

Write a function find_superspreading_date:

? its only argument is a dictionary with format {id : Infected_person-object,

...}

o this is the output of function parse_contacts in Part 2

? it returns a tuple of the form ([date1,...], max-infected) where:

o [date1,...] is a list of strings representing the dates that had the maximum

number of infections. The order in which the dates are stored in the list is not

important. The list should not contain duplicates.

o max_infected is the maximum number of direct infections on any of those dates.

For example, if max_infected is 10, each of the dates in the list [date1,...]

had 10 direct infections.

o If the input dictionary is empty, find_superspreading_date should return the

tuple ([], 0)

o You can assume that find_superspreading_date will be called with a

dictionary as its only argument. You can also assume that the dictionary, if not empty,

will have the format {id : Infected_person-object, ...}.

Part 5 – Identify the Top (Direct + Indirect) Superspreaders

In Part 3 we looked at direct infections: when one person infects one or more others. Indirect

infections are the ones that follow from a direct infection. For example, if person A infects person B

and person B infects persons C and D, A is said to have indirectly infected C and D. If C and D do not

infect anyone else, A is said to have (directly + indirectly) infected three persons: B, C, and D.

In this part, you will design and implement two functions to identify all people directly or indirectly

infected by a person, and to identify the top (direct + indirect) superspreader(s).

page 10 of 11

TO DO:

5A – First write a function get_all_infected, with two arguments:

? a dictionary with format {id : Infected_person-object, ...}

o this is the output of function parse_contacts in Part 2

? a string that represents the id of a person of interest

The function returns a list of the ids of all persons (directly + indirectly) infected by the person of

interest.

5B – Then write a function find_top_direct_plus_indirect_superspreader:

? its only argument is a dictionary with format {id : Infected_person-object,

...}

o this is the output of function parse_contacts in Part 2

? it returns a tuple of the form ([id1, id2, ...], max_infection_count) where:

o ([id1, id2, ...] is a list of person id’s corresponding to the top (direct +

indirect) superspreader(s). Again, remember that there may only be one, or more than

one in the case of a tie. The order in which the id’s are stored in the list is not

important. The list should not contain duplicates.

o max_infection_count represents the maximum number of (direct + indirect)

infections.

o If find_top_direct_plus_indirect_superspreader is called with an

empty dictionary as argument, it should return the tuple ([], 0)

o You can assume that find_top_direct_plus_indirect_superspreader

will be called with a dictionary as its only argument. You can also assume that the

dictionary, if not empty, will have the format {id:Infected_person-object,

...}.

Notes:

? there may be one top (direct + indirect) superspreader, or more than one in case of a tie

? you may use the first function, get_all_infected, to implement the second function,

find_top_direct_plus_indirect_superspreader

page 11 of 11

Description of the Provided MarkUS tests

Unlike in your labs, we are only providing MarkUS tests that will tell you if there are basic problems

(e.g. syntax errors, typos in function names, etc.) with your submission that prevent MarkUS from

evaluating your code. These tests will not check any outputs from your functions, they will only check

that the functions and classes are correctly defined and can be run by MarkUS when grading starts.

You will be able to run these “sanity check” tests 5 times per hour.

It is your responsibility to create sufficient tests to be confident in the correctness of your code.

Below is a summary of what our simple tests will evaluate for each part of the assignment.

Part 1:

? the file part1.py contains a class named Infected_person; AND

? the Infected_person class includes the following methods: __str__ and infects;

AND

? the file contains no syntax errors that prevent MarkUS from running the code in the file

part1.py

Part 2:

? the file part2.py contains a function named parse_contacts; AND

? the file contains no syntax errors that prevent MarkUS from running the code in the file

part2.py

Part 3:

? the file part3.py contains a function named find_top_direct_superspreader; AND

? the file contains no syntax errors that prevent MarkUS from running the code in the file

part3.py

Part 4:

? the file part4.py contains a function named find_superspreading_date; AND

? the file contains no syntax errors that prevent MarkUS from running the code in the file

part4.py

Part 5:

? the file part5.py contains a function named get_all_infected; AND

? the file part5.py contains a function named

find_top_direct_plus_indirect_superspreader; AND

? the file contains no syntax errors that prevent MarkUS from running the code in the file

part5.py

Our tests provide a “sanity check” to help give you confidence that you will not lose MarkUS grades

for simple typos or syntax errors. You will be able to run these tests in the same way you ran MarkUS

tests for labs 2-9. That is, submit your code to MarkUS and then click on “Run Tests” under the

automated testing tab. After a few minutes, refresh the page and the results of the tests will be

displayed.