代写program、代做python设计程序
- 首页 >> C/C++编程 Important: when running your assignment as python3 a5.py the GUI should load automatically.
In your final project, you will build upon and extend what you have learned in the course and what you completed in your assignments. In assignment 5, you will integrate multiple aspects of what you have learned in the class to create a complete software product!
For your final assignment, you will develop a module that enables a program to send and receive direct messages to another user on the DSP platform. You will then incorporate this module into a graphical user interface (GUI) using Tkinter that should allow any student to communicate with any other student in this class as long as they know each other usernames.
To help you get started, the requirements for your final program have been divided into different parts. You are encouraged to follow each part in order. Note that each part can be written and tested independently.
Very important: do not wait until near the deadline to start this project, as you will certainly not have time to complete it if you do so, and this project deadline will not be extended.
Part 1: Implement the Direct Messaging Protocol
To communicate with another user on the DSP platform, your program will need to use new protocol messages. To support these new messages, your program must extend your ds_protocol module to support direct messaging with the following commands:
directmessage
Accepts a message to be sent directly to another user. The username is passed in the "recipient" part of the command. Also retrieve messages from the server. Example:
# Send a directmessage to another DS user (in the example bellow, ohhimark)
{"token":"user_token", "directmessage": {"entry": "Hello World!","recipient":"ohhimark", "timestamp": "1603167689.3928561"}}
# Request unread messages from the DS server
{"token":"user_token", "directmessage": "new"}
# Request all messages from the DS server
{"token":"user_token", "directmessage": "all"}
Recall from a3 that user_token is retrieved by sending a successful join command. So to send a direct message, you must first join the server and retrieve the token that you must later use.
The DS server will respond to directmessage requests with the following ok response messages:
# Sending of direct message was successful
{"response": {"type": "ok", "message": "Direct message sent"}}
# Response to request for **`all`** and **`new`** messages. Timestamp is time in seconds
# of when the message was originally sent.
{"response": {"type": "ok", "messages": [{"message":"Hello User 1!", "from":"markb", "timestamp":"1603167689.3928561"},{"message":"Bzzzzz", "from":"thebeemoviescript" "timestamp":"1603167689.3928561"}]}}
To process these new response messages, you will need to extend the message conversion code that you wrote for a3. How you solve this requirement is up to you, but a good approach will likely include adding a function to your ds_protocol that converts JSON messages to a list or a dictionary.
Writing a Test
When your code is complete, write a small test program to verify that your messages are processed as expected. Your program should import your module (e.g., import ds_protocol, if you are extending your ds_protocol module) and call the code you have written with a few test messages. You can use the messages provided as examples above or create a few of your own as test cases. You can name your test whatever you like, but it should be prepended with the word test_:
test_ds_message_protocol.py
Once your test program is complete, you can move on to the next part of the assignment.
Part 2: The DS Direct Messenger Module
Now that you have a functioning protocol, you can write your message send and retrieve code. The first thing you will do is complete the direct messenger module. Your module must adhere to the following rules:
It must be named ds_messenger.py
It must implement the following classes and methods
class DirectMessage:
def __init__(self):
self.recipient = None
self.message = None
self.timestamp = None
class DirectMessenger:
def __init__(self, dsuserver=None, username=None, password=None):
self.token = None
def send(self, message:str, recipient:str) -> bool:
# must return true if message successfully sent, false if send failed.
pass
def retrieve_new(self) -> list:
# must return a list of DirectMessage objects containing all new messages
pass
def retrieve_all(self) -> list:
# must return a list of DirectMessage objects containing all messages
pass
You are free to add as many supporting methods to either of these classes as you need, but the ds_messenger.py module must be able to function without any other dependencies. A program that imports your module should be able to call the required functions to exchange messages with the DS server. You may reuse or import the code you have written for the ds_client.py module to reduce the amount of code you have to write here!
Writing a Test
Once again, when your code is complete, write a small test program to verify that your ds_messenger module is functioning correctly. You can name your test whatever you like, but it should be prepended with the word test_:
test_ds_messenger.py
Once your test program is complete, you can move on to the next part of the assignment.
Part 3: Store Messages Locally
Some of the data your program uses should be preserved across multiple users. To complete this feature, you can either implement your own data storage code or, what can be more straightforward, extend the Profile module to support serializing new data.
Your program should be able to store message data locally so that when the program starts, it does not have to connect to the DSP server to display new messages. Your program should also store recipient data locally so that your user does not have to add the same recipients each new time the program is run (for instance, you can create a new attribute in Profile containing list of "friend" usernames). It’s OK if you require a user to first load their dsu profile (or any other custom file format you build) before displaying data. The important thing here is to NOT require an internet connection to get messages that were already previously retrieved.
However you handle this requirement, after using your program once, all recipients who were previously added and all the messages that were previously retrieved by the user, should appear in your GUI (see Part 4) when it starts at any subsequent use.
Part 4: The Graphical User Interface
The final part of the assignment will be to write a graphical user interface (GUI) for your module using Tkinter. You are free to implement the interface however you like or to adapt the Tkinter GUI starter code that you were given in assignment 5.
There are many ways to create a graphical interface for a direct messaging program. You are not required to follow the example below. However, if you are unsure where to start, the following wireframe should point you in the right direction.
In the wireframe model presented above, there are 5 widgets which are responsible for all of the input and output in the program:
1.On the left is a treeview widget that displays all of the DS users that have sent you messages. Selecting a user must display the messages that they have sent in (2).
2.On the upper right is the display widget that contains the messages sent by the user selected in (1).
3.On the lower right is the text input widget where new messages are written.
4.The ‘Add User’ button adds new contacts (recipients) to receive direct messages.
5.The ‘Send’ button sends the message entered in (3) to the user selected in (1).
A small help: The layout used in this wireframe is nearly identical to the layout provided to you as an example code in this link Download example code in this link. You may reuse this existing code to save you some steps, but if you decide to use this code instead of writing your own interface from scratch, you must to modify it a bit (for instance by moving some options around, adding new options, or a new design, reconfiguring the way that the messages are printed by adding color, etc.) and you also need to finish implementing it, as the provided code is not fully operational.
One possible version of the Social Messenger app is pictured above. In this version, the add user requirement has been moved to the settings menu.
In addition to the requirements described above, there are a few other tasks you must do to complete the assignment:
1.Your GUI must automatically retrieve new messages while the program runs (see the after method to create timed events in tkinter, as we covered in week 9).
2.Your conversations must be visually separated in some way between the different students (e.g., left/right align, color, identifier, etc; if you are using a tkinter text widget, look for how to use tags with the text insert methods).
3.Selecting a new contact in the treeview should display any recent messages with that contact in the message window (e.g. you will need to clear the text box contents and then insert the previous messages of the selected user).
What to submit?
You are free to design your code as you wish as long as you respect the assignment's requirements above and the standing requirements for assignments of the course (usage of git/style/exceptions/unitests/README; see important reminder notes below). After you finish developing and testing your code, submit your assignment on canvas.
You will submit to Canvas your entire code, including your .git local repository, and a simple README file that includes a simple description in English in one or two paragraphs of what your software does in your own words. You must compress your entire project using zip (from linux, if you are inside your project folder, you just need to write zip -r Assignment5.zip . and you should produce the correct file to submit (mind the space and the dot after the file name; that means that you want to include all files, including hidden files, as the git repo folder, inside the compressed file).
You must respect the following simple file structure for this project:
Assignment5.zip
.............. README.txt
.............. a5.py
.............. ds_protocol.py
.............. ds_messenger.py
.............. test_ds_message_protocol.py
.............. test_ds_messenger.py
...............py
.............. .git/...
You must put your main() function (and obviously your if __name__ == "__main__": code) inside the a5.py file.
No late submission for assignment five will be allowed.
Important reminder notes: as usual in a professional code development scenario, you are required: to keep track of your development using git with regular commits, as we previously saw in the quarter; to respect PEP8 Python coding styles; to add a simple but descriptive README file; and to deal with possible exceptions and errors that may happen. You will not get additional points for respecting these software development requirements, but penalties in the assignment are associated with not following them, as you would be producing lower-quality software.
1. On the number of commits to your local git repository: if you have a single commit, you may get no grade; you do need to have several commits to demonstrate how you wrote your assignment and how you solved bugs, etc., during your development. As a rule of thumb, for this assignment, we expect you to have at least as many commits as you have functions/classes/methods defined in your code, but usually, you will possibly have many more. If you have one single commit where you commit your entire code to your local repository, we will consider that you have no commit at all.
2. On the coding style: before submission, make sure to check your style and possible code mistakes using pycodestyle and pylint as seen in lecture, and make all the necessary changes, including in any starter code provided to you, as they include simple style issues for you to correct. It should be simple to fix most of the code issues, thus respecting PEP8, if you address the pycodestyle and pylint errors and warnings, thus avoiding any penalty.
3. On testing: it is expected that your assignment 5 code will include unit tests for the most important functions/methods/classes. Make sure that you develop these test cases to be compatible with pytest.
Rubric
A5
A5
Criteria Ratings Pts
This criterion is linked to a Learning OutcomeAuto-graded functionality requirements: DirectMessenger
Can you instantiate the DirectMessenger as specified in the assignment prompt? 3 pts
This criterion is linked to a Learning OutcomeAuto-graded functionality requirements: send() method
Does send() work AND return True/False as specified in the assignment prompt? 3 pts
This criterion is linked to a Learning OutcomeAuto-graded functionality requirements: retrieve_all() method
Does retrieve_all() work AND return a list of DirectMessage objects as specified in the assignment prompt? 3 pts
This criterion is linked to a Learning OutcomeAuto-graded functionality requirements: retrieve_new()
Does retrieve_new() work AND return a list of DirectMessage objects as specified in the assignment prompt? 3 pts
This criterion is linked to a Learning OutcomeUser interface functionality requirement: organization
How organized is the User Interface? (i.e., how easy and clear is the user interface? can someone use it without thinking too much/reading the manual/reading the code?) 2 pts
This criterion is linked to a Learning OutcomeUser interface functionality requirement: sending messages
Does the graphical user interface allow someone to send a message to another user? Is this functionality working properly? 2 pts
This criterion is linked to a Learning OutcomeUser interface functionality requirement: message display
Does the graphical user interface clearly distinguishes between messages that were sent to and received from other users? 2 pts
This criterion is linked to a Learning OutcomeUser interface functionality requirement: retrieve new messages automatically
Is the graphical user interface automatically retrieving new messages from the server? (i.e., when someone sends you a message, is this message displayed in your user interface automatically after a few seconds?) 1 pts
This criterion is linked to a Learning OutcomeUser interface functionality requirement: history display
Does the graphical user interface automatically displays previous messages exchanged with another user (i.e., "friend", "contact", etc.) when this user is selected in the interface? 1 pts
This criterion is linked to a Learning OutcomeDesign, development, and documentation requirements: existence and naming
Does the code exists and if it is properly named as required in the assignment prompt? 3 pts
This criterion is linked to a Learning OutcomeDesign, development, and documentation requirements: README
Does your code come with a README file? 0.5 pts
This criterion is linked to a Learning OutcomeDesign, development, and documentation requirements: coding style standards
Is your code following PEP8 standards? 3 pts
This criterion is linked to a Learning OutcomeDesign, development, and documentation requirements: git
Have you followed the course requirements for git usage during the development? 1.5 pts
This criterion is linked to a Learning OutcomeDesign, development, and documentation requirements: possible issues
Is your code being flagged for any possible quality issue by standard static code analysis tools (pylint)? 3 pts
This criterion is linked to a Learning OutcomeDesign, development, and documentation requirements: testing
Have you implemented unit tests and is the code coverage of your test suite reasonable as specified in class? 4 pts
Total Points: 35
v
In your final project, you will build upon and extend what you have learned in the course and what you completed in your assignments. In assignment 5, you will integrate multiple aspects of what you have learned in the class to create a complete software product!
For your final assignment, you will develop a module that enables a program to send and receive direct messages to another user on the DSP platform. You will then incorporate this module into a graphical user interface (GUI) using Tkinter that should allow any student to communicate with any other student in this class as long as they know each other usernames.
To help you get started, the requirements for your final program have been divided into different parts. You are encouraged to follow each part in order. Note that each part can be written and tested independently.
Very important: do not wait until near the deadline to start this project, as you will certainly not have time to complete it if you do so, and this project deadline will not be extended.
Part 1: Implement the Direct Messaging Protocol
To communicate with another user on the DSP platform, your program will need to use new protocol messages. To support these new messages, your program must extend your ds_protocol module to support direct messaging with the following commands:
directmessage
Accepts a message to be sent directly to another user. The username is passed in the "recipient" part of the command. Also retrieve messages from the server. Example:
# Send a directmessage to another DS user (in the example bellow, ohhimark)
{"token":"user_token", "directmessage": {"entry": "Hello World!","recipient":"ohhimark", "timestamp": "1603167689.3928561"}}
# Request unread messages from the DS server
{"token":"user_token", "directmessage": "new"}
# Request all messages from the DS server
{"token":"user_token", "directmessage": "all"}
Recall from a3 that user_token is retrieved by sending a successful join command. So to send a direct message, you must first join the server and retrieve the token that you must later use.
The DS server will respond to directmessage requests with the following ok response messages:
# Sending of direct message was successful
{"response": {"type": "ok", "message": "Direct message sent"}}
# Response to request for **`all`** and **`new`** messages. Timestamp is time in seconds
# of when the message was originally sent.
{"response": {"type": "ok", "messages": [{"message":"Hello User 1!", "from":"markb", "timestamp":"1603167689.3928561"},{"message":"Bzzzzz", "from":"thebeemoviescript" "timestamp":"1603167689.3928561"}]}}
To process these new response messages, you will need to extend the message conversion code that you wrote for a3. How you solve this requirement is up to you, but a good approach will likely include adding a function to your ds_protocol that converts JSON messages to a list or a dictionary.
Writing a Test
When your code is complete, write a small test program to verify that your messages are processed as expected. Your program should import your module (e.g., import ds_protocol, if you are extending your ds_protocol module) and call the code you have written with a few test messages. You can use the messages provided as examples above or create a few of your own as test cases. You can name your test whatever you like, but it should be prepended with the word test_:
test_ds_message_protocol.py
Once your test program is complete, you can move on to the next part of the assignment.
Part 2: The DS Direct Messenger Module
Now that you have a functioning protocol, you can write your message send and retrieve code. The first thing you will do is complete the direct messenger module. Your module must adhere to the following rules:
It must be named ds_messenger.py
It must implement the following classes and methods
class DirectMessage:
def __init__(self):
self.recipient = None
self.message = None
self.timestamp = None
class DirectMessenger:
def __init__(self, dsuserver=None, username=None, password=None):
self.token = None
def send(self, message:str, recipient:str) -> bool:
# must return true if message successfully sent, false if send failed.
pass
def retrieve_new(self) -> list:
# must return a list of DirectMessage objects containing all new messages
pass
def retrieve_all(self) -> list:
# must return a list of DirectMessage objects containing all messages
pass
You are free to add as many supporting methods to either of these classes as you need, but the ds_messenger.py module must be able to function without any other dependencies. A program that imports your module should be able to call the required functions to exchange messages with the DS server. You may reuse or import the code you have written for the ds_client.py module to reduce the amount of code you have to write here!
Writing a Test
Once again, when your code is complete, write a small test program to verify that your ds_messenger module is functioning correctly. You can name your test whatever you like, but it should be prepended with the word test_:
test_ds_messenger.py
Once your test program is complete, you can move on to the next part of the assignment.
Part 3: Store Messages Locally
Some of the data your program uses should be preserved across multiple users. To complete this feature, you can either implement your own data storage code or, what can be more straightforward, extend the Profile module to support serializing new data.
Your program should be able to store message data locally so that when the program starts, it does not have to connect to the DSP server to display new messages. Your program should also store recipient data locally so that your user does not have to add the same recipients each new time the program is run (for instance, you can create a new attribute in Profile containing list of "friend" usernames). It’s OK if you require a user to first load their dsu profile (or any other custom file format you build) before displaying data. The important thing here is to NOT require an internet connection to get messages that were already previously retrieved.
However you handle this requirement, after using your program once, all recipients who were previously added and all the messages that were previously retrieved by the user, should appear in your GUI (see Part 4) when it starts at any subsequent use.
Part 4: The Graphical User Interface
The final part of the assignment will be to write a graphical user interface (GUI) for your module using Tkinter. You are free to implement the interface however you like or to adapt the Tkinter GUI starter code that you were given in assignment 5.
There are many ways to create a graphical interface for a direct messaging program. You are not required to follow the example below. However, if you are unsure where to start, the following wireframe should point you in the right direction.
In the wireframe model presented above, there are 5 widgets which are responsible for all of the input and output in the program:
1.On the left is a treeview widget that displays all of the DS users that have sent you messages. Selecting a user must display the messages that they have sent in (2).
2.On the upper right is the display widget that contains the messages sent by the user selected in (1).
3.On the lower right is the text input widget where new messages are written.
4.The ‘Add User’ button adds new contacts (recipients) to receive direct messages.
5.The ‘Send’ button sends the message entered in (3) to the user selected in (1).
A small help: The layout used in this wireframe is nearly identical to the layout provided to you as an example code in this link Download example code in this link. You may reuse this existing code to save you some steps, but if you decide to use this code instead of writing your own interface from scratch, you must to modify it a bit (for instance by moving some options around, adding new options, or a new design, reconfiguring the way that the messages are printed by adding color, etc.) and you also need to finish implementing it, as the provided code is not fully operational.
One possible version of the Social Messenger app is pictured above. In this version, the add user requirement has been moved to the settings menu.
In addition to the requirements described above, there are a few other tasks you must do to complete the assignment:
1.Your GUI must automatically retrieve new messages while the program runs (see the after method to create timed events in tkinter, as we covered in week 9).
2.Your conversations must be visually separated in some way between the different students (e.g., left/right align, color, identifier, etc; if you are using a tkinter text widget, look for how to use tags with the text insert methods).
3.Selecting a new contact in the treeview should display any recent messages with that contact in the message window (e.g. you will need to clear the text box contents and then insert the previous messages of the selected user).
What to submit?
You are free to design your code as you wish as long as you respect the assignment's requirements above and the standing requirements for assignments of the course (usage of git/style/exceptions/unitests/README; see important reminder notes below). After you finish developing and testing your code, submit your assignment on canvas.
You will submit to Canvas your entire code, including your .git local repository, and a simple README file that includes a simple description in English in one or two paragraphs of what your software does in your own words. You must compress your entire project using zip (from linux, if you are inside your project folder, you just need to write zip -r Assignment5.zip . and you should produce the correct file to submit (mind the space and the dot after the file name; that means that you want to include all files, including hidden files, as the git repo folder, inside the compressed file).
You must respect the following simple file structure for this project:
Assignment5.zip
.............. README.txt
.............. a5.py
.............. ds_protocol.py
.............. ds_messenger.py
.............. test_ds_message_protocol.py
.............. test_ds_messenger.py
..............
.............. .git/...
You must put your main() function (and obviously your if __name__ == "__main__": code) inside the a5.py file.
No late submission for assignment five will be allowed.
Important reminder notes: as usual in a professional code development scenario, you are required: to keep track of your development using git with regular commits, as we previously saw in the quarter; to respect PEP8 Python coding styles; to add a simple but descriptive README file; and to deal with possible exceptions and errors that may happen. You will not get additional points for respecting these software development requirements, but penalties in the assignment are associated with not following them, as you would be producing lower-quality software.
1. On the number of commits to your local git repository: if you have a single commit, you may get no grade; you do need to have several commits to demonstrate how you wrote your assignment and how you solved bugs, etc., during your development. As a rule of thumb, for this assignment, we expect you to have at least as many commits as you have functions/classes/methods defined in your code, but usually, you will possibly have many more. If you have one single commit where you commit your entire code to your local repository, we will consider that you have no commit at all.
2. On the coding style: before submission, make sure to check your style and possible code mistakes using pycodestyle and pylint as seen in lecture, and make all the necessary changes, including in any starter code provided to you, as they include simple style issues for you to correct. It should be simple to fix most of the code issues, thus respecting PEP8, if you address the pycodestyle and pylint errors and warnings, thus avoiding any penalty.
3. On testing: it is expected that your assignment 5 code will include unit tests for the most important functions/methods/classes. Make sure that you develop these test cases to be compatible with pytest.
Rubric
A5
A5
Criteria Ratings Pts
This criterion is linked to a Learning OutcomeAuto-graded functionality requirements: DirectMessenger
Can you instantiate the DirectMessenger as specified in the assignment prompt? 3 pts
This criterion is linked to a Learning OutcomeAuto-graded functionality requirements: send() method
Does send() work AND return True/False as specified in the assignment prompt? 3 pts
This criterion is linked to a Learning OutcomeAuto-graded functionality requirements: retrieve_all() method
Does retrieve_all() work AND return a list of DirectMessage objects as specified in the assignment prompt? 3 pts
This criterion is linked to a Learning OutcomeAuto-graded functionality requirements: retrieve_new()
Does retrieve_new() work AND return a list of DirectMessage objects as specified in the assignment prompt? 3 pts
This criterion is linked to a Learning OutcomeUser interface functionality requirement: organization
How organized is the User Interface? (i.e., how easy and clear is the user interface? can someone use it without thinking too much/reading the manual/reading the code?) 2 pts
This criterion is linked to a Learning OutcomeUser interface functionality requirement: sending messages
Does the graphical user interface allow someone to send a message to another user? Is this functionality working properly? 2 pts
This criterion is linked to a Learning OutcomeUser interface functionality requirement: message display
Does the graphical user interface clearly distinguishes between messages that were sent to and received from other users? 2 pts
This criterion is linked to a Learning OutcomeUser interface functionality requirement: retrieve new messages automatically
Is the graphical user interface automatically retrieving new messages from the server? (i.e., when someone sends you a message, is this message displayed in your user interface automatically after a few seconds?) 1 pts
This criterion is linked to a Learning OutcomeUser interface functionality requirement: history display
Does the graphical user interface automatically displays previous messages exchanged with another user (i.e., "friend", "contact", etc.) when this user is selected in the interface? 1 pts
This criterion is linked to a Learning OutcomeDesign, development, and documentation requirements: existence and naming
Does the code exists and if it is properly named as required in the assignment prompt? 3 pts
This criterion is linked to a Learning OutcomeDesign, development, and documentation requirements: README
Does your code come with a README file? 0.5 pts
This criterion is linked to a Learning OutcomeDesign, development, and documentation requirements: coding style standards
Is your code following PEP8 standards? 3 pts
This criterion is linked to a Learning OutcomeDesign, development, and documentation requirements: git
Have you followed the course requirements for git usage during the development? 1.5 pts
This criterion is linked to a Learning OutcomeDesign, development, and documentation requirements: possible issues
Is your code being flagged for any possible quality issue by standard static code analysis tools (pylint)? 3 pts
This criterion is linked to a Learning OutcomeDesign, development, and documentation requirements: testing
Have you implemented unit tests and is the code coverage of your test suite reasonable as specified in class? 4 pts
Total Points: 35
v