Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit

EMATM0048: Software Development: Programming and Algorithms (SDPA)

Coursework Assessment (100%)

This unit assessment asks you to apply the skills and tools that you’ve learned throughout the unit, on a selection of different tasks. General guidelines are as follows:

•    Deadline: 13:00 (UK time) on 9th January 2023.

•    Rules: Don't share your code with anybody. You are welcome to discuss questions with other students, but don't share the answers. The experience of solving the problems in this project will prepare you for real problems in data science (and life).

•    Support: You are not alone! Book drop-in sessions, office hours, participate in the forum and talk to your classmates. If you're ever feeling overwhelmed or don't know how to make progress, email the teaching team for help.

•    Plagiarism: Your work must not be plagiarized. More information is available here:https://www.bristol.ac.uk/students/support/academic-advice/plagiarism/

•    Advice: Develop your answers incrementally. To perform a complicated task, break it up into steps, perform each step on a different line, give a new name to each result, and check that each intermediate result is what you expect.

Part 1: Software Development (50%)

In this part of the coursework, you need to build a fully functional text-based money transfer system. This task includes the following tasks:

1.  Designing the architecture of the system. - You need to define the components involved in the workflow of your program through an object-oriented approach, which implies applying concepts such as polymorphism, inheritance, encapsulation in your design.

2.   Implementing your design. - Once your classes are defined, you need to reflect your design in a masterpiece of code.

3.   Testing thefunctionality of the system. - It is important to ensure that your program works as expected. Hence, you need to try the functionalities of your program, including those   scenarios where the customer might “break down” the system.

Context and overall description

Imagine that you are a fintech entrepreneur with software developer skills. Somehow, your     friend has managed to get you a showcase interview with one of the most important groups of investors across the globe. Then, you decide to present what you have in mind:

My software can be seen as an electronic manager of money where customers can have their

funds. The system can perform typical money operations such as withdrawing and depositing money or transferring money to other customers. The mainfeature of the system is thatcustomers can have wallets, which are “money containers” associated with a specific purpose.

Namely, daily use, saving, holidays and mortgage.”

Thus, you need to develop a proof of concept for your idea to show it to the investors.

System requirements

In this part, you are required to write a text-based (no GUI is required) python program using object-oriented programming to build a proper proof of concept. Your system must have the following functionalities:

A.  A customer account can be created with the following data: (i) first name; (ii) last name; (iii) country of residence; (iv) age; (v) email; (vi) password, (vii) username. Customers  can log in using their username and their password, they can later log out.

B.  Registered customers can create/delete wallets, and deposit/withdraw money when applicable (see points I and  II of Section Technical considerations).

C.  Customers can have one or more wallets of the same type. Customers can transfer money   among their wallets and transfer money to another customer. Customers also can look up   the details of their wallets, including the balance of each wallet. A wallet contains

(i)wallet id; (ii) balance; (iii) last transaction [withdraw/deposit/transference]; (iv) type of wallet (see point I of Section Technical considerations).

D.  For each run, all the data associated with a customer must be available even after they log out. For instance, if a customer creates some wallets containing money, then logs out and logs in again, all the data must be still available. When the program terminates, then all    information will be deleted. Since it is a proof of concept, no persistence data is

necessary (i.e., it is not necessary to use files or databases to store customers’ data).

Technical considerations

I.   There are 4 types of wallets. The following table shows their capabilities in terms of transactions:

Wallet

Withdraw

Deposit

Transfer to wallets

Transfer to other customers

Daily Use

Y

Y

Y

Y

Saving

Y

Y

N

N

Holidays

Y

Y

Y

N

Mortgage

N

Y

N

N

II.  Transactions may have a fee. The following table presents the fees per transaction:

Transaction

Fee

Deposit

Free

Withdraw

Free

Transfer among wallets

0.5% of the amount transferred

Transfer to other customers

1.5% of the amount transferred

III. Since there exist fees for transactions, the money charged per transaction should be sent to the system account” .

Task specifications

Create your classes (15%)

Your program should have at least 3 classes:

-     Customer Account: This class should contain the data of customer (see point A of section Task requirements). This class is responsible for managing customer accounts and associated wallets, depositing money into a specific wallet, and transferring money among wallets         (when possible).

-     Wallet: see point C of section Task requirements.

-     Banking System: This is the orchestrator class. It is responsible for creating customer  accounts and triggering the methods of Customer Account objects. It also saves money charged for transactions made by customers.

Hint1: Before writing code, think of the program in terms of components. Then, wrap up the components in classes. Architecture is everything! 

Hint 2: Make sure you utilize the inheritance concept in your design. The use of inheritance is a crucial aspect of object-oriented programming. Are there any components in the system that    can be modelled as variations of others?

Run your code (15*%)

The main script should show in the console a set of options to interact with your system such as 1) create an account; 2) access an account. Once an account has been created, the  program should go back to the main menu. If a customer wants to access their account, after login, another menu should be displayed with options such as 1) create wallet; 2) deposit money to a  wallet; 3) show details of wallets; 4) Transfer money from one wallet to another wallet. Once a wallet has been created, the program should go back to the customer account's main menu. Feel free to design your own menu and workflow that captures all functionalities of your system, the above are only examples.

Extend your program (20%)

A.   Extend your program by adding more functionalities such as deleting a customer account, deleting wallets, and transferring money to other customers, etc. (see Task requirements    section). Consider that when you add these new functionalities, the menus described in the previous step should be updated accordingly. Do not forget to include suitable handling of

errors and exceptions.

B.   Consider a scenario when a customer transfers or withdraws money from a wallet which doesn’t have sufficient money, then the program finds an alternative wallet that contains enough money and offers the user to transfer funds between wallets in order to complete the transaction. Note the constraints on different types of wallet when implementing this feature.

Bonus question (+5%)

For this part, customers’ login detail (e.g., username, password) should be saved in a file, that is  appended for each run with new records for new customers. This means records for customers in the previous runs are saved and can be retrieved. To keep the data secured, all passwords must be encrypted.

In this task, you are required to implement your own function to encrypt customers’ passwords.   As a proof-of-concept, you need to save your encrypted password in the same file along with the original password (with no encryption). The choice of the 'encryption strategy’ is yours, but the   things to consider are: how strong is your encryption and what is the complexity of your method? You need to comment on the robustness and complexity of your method in the readme. md”      file. Notes: Decryption is not required. Using cryptographic modules and Caesar Cipher are not

allowed for this task.

Errors and exceptions handling (included in the grading for each step) It is assumed that the system that you build is robust. It means that is capable to handle unexpected scenarios such as (i) bad formats in inputs; (ii) sending money to an inexistent customer; (iii) withdrawing more money than available; (iii) updating the balance of a wallet   once the customer performed an action; (iv) having a negative balance; (v) Customers with the same username.  These are some examples. Your program should present coherent behaviour.  Pay attention to that!

Note: Your program must be text-based and should not have a graphical customer interface. It is also not allowed to use any external library for implementation only python standard libraries    can be usedhttps://docs.python.org/3/library/index.html.

Part 2: Data Analytics (50%)

Jupyter notebook will be used for this part. Your answer for each step must include both your

code and your explanation and answers to questions in the markdown cells. Please refer to the information given for markdown cells in each step.

Step 1: Crawl a real-world dataset (2%)

Find an interesting external (remotely hosted) dataset to extract and analyse. Your dataset can be either extracted from APIs and/or via web scraping. Reading datafrom non-external (i.e., local)

files is notpermittedfor this task. Extracted data must contain at least 5 columns and 150 rows.  Save your extracted data in a CSV format.

Examples of data sources are:

-    Bitstamp (link)

-    Coinbase (link)

-    Investopedia (link)

-    Strip (link)

-    WooCommerce (link)

Note: “pandas.read_table” is not allowed for this task. You may use data from multiple sources and merge them as far as at least one of them is crawled from APIs/ web scraping that satisfies the requirement.

Explain in the markdown cells: Where does the data comefrom? What are the variables of interest? How was the data scraped/collected?

Step 2: Perform data preparation & cleaning (5%)

• Load the dataset into a data frame using Pandas

• Handle missing data, if any.

• Handle any outliers or inconsistencies in the data, if any.

• Perform any additional steps to enrich your data (parsing dates, creating additional columns/features, etc.)

Explain in markdown cells: steps to prepare, clean your data, or extract newfeatures.

Step 3: Perform exploratory analysis (8%)

Explore your data, examples are as follows:

•    Compute the mean, sum, range, and other interesting statistics for numeric columns

•    Explore distributions of numeric columns using histograms etc.

•    Explore the relationship between columns using scatter plots, bar charts, etc.

Explain in markdown cells: steps for exploratory data analysis and your observations.

Step 4: Ask questions about your data (30%)

•    Ask at least three interesting questions about your dataset. Your questions must be complex enough to have sub-questions. The quality of your questions is assessed based   on their complexity and interestingness. Trivial and basic questions will not give you full marks.

•    Answer the questions either by computing the results using Numpy/Pandas or by plotting graphs using Matplotlib. Perform grouping/aggregation wherever necessary. You can use hypothesis testing and basic modelling (such as regression models) to answer the proposed questions.

Explain in markdown cells Outline in detail your entire analysis. Explain your insights clearly. You should include a brief description of the intent /interpretation of each plot.

Step 5: Summarise and write a conclusion (5%)

Explain in markdown cells:

•     Write a summary of what you've learned from the analysis.

•     Share ideas for future work on the same topic using other relevant datasets/sources.

Coursework general instructions:

Code commenting and documentation

Your code must be documented appropriately using docstring comments. Document as you go,   not all at the end. One strategy is to write a brief comment about the “one thing” that the function is supposed to do when you declare it, then refer to that comment while implementing it: this       helps maintain focus when implementing the function and helps stop yourself from making it do more than the ‘one’ thing it is supposed to do. Each class and each method should have at least    one docstring which can be brief. For this project, you will need to create a readme.md text file  in your ~/project folder that explains each part of the project. Specifications are below:

Part 1: readme.me file should include a description of your code design, classes,

methods, and other key details. Your readme.md file should be at least several

paragraphs in length and should explain what your project is, what each of the files you    wrote for the project contains and does, and if you debated certain design choices, explain why you made them. Ensure you allocate sufficient time and energy to writing a readme.md that documents your code thoroughly.

Part 2: Documentation for part 2 is in Jupyter notebook using markdown cells. Any additional libraries and external sources needed to run the code correctly must be

explained in the readme.md file.

If you are unfamiliar with Markdown syntax, you might find GitHub’sBasic Writing and Formatting Syntaxhelpful

Version Control

You must use version control to keep track of your progress during implementation, using Git.    You should perform regular commits as you implement features and fix errors. Your commit       comments should reflect the context of the changes that were made in each commit—a fellow     developer can always diff the contents to see exactly what changed but that does not provide the context. You should try to ensure each commit comment contains a short subject line. Ensure that the repository is private, i.e., cannot be seen by people other than yourself. Failure to do that will be considered plagiarism. If version control is not submitted or made public, 10 pts will be   deduced.

Submitting your coursework

Your submission will comprise your entire version control repository for the three parts. Your repository must contain all source files required to run your program.

Your submission must include your code for each part: part 1 and part 2.

•    Part 1: Includes different Python scripts to run your code.

•    Part 2: Jupyter Notebook file that includes code and explanation in the markdown for each step. The collected data saved in Step 1 must be submitted too.

•    GitHub markdown (readme.md file): to explain any required instructions for running your code (please refer to code documentation and commenting section”).

•    If you have used any additional code for part 2, beyond standard Python packages, then   you will need to include an additional subdirectory containing additional code required to run your scripts. The authorship of any such code should be clearly stated in the GitHub  markdown (readme.md).

•    Note: A link of GitHub repository must be included in your readme.md file.

For submitting your work on Blackboard, you will need to submit a zip file and GitHub              Repository with the name (“UOBusername_EMATM0048). Your zip file/repository should        contain the latest version of your GitHub repository.You will need to add "SDPA-UoB" as a collaborator to your repository. Please note you must NOT change your remote repository once you added SDPA-UoB as a collaborator.

Grading

Your grade will be assessed on both correctness and style.

•    Correctness:  How well the program works according to specifications. How good is the quality of your analysis.

•    Style: The quality of the code and documentation.

Your code should be well-written and well-commented. You are encouraged to format your code perPython style guidelines. It should be clear enough for another programmer, such as the course staff, to understand and modify it if needed. Quality code is expected to meet our style requirements:

•   Every function written is commented, in your own words, using a docstring format that describes its behaviour, parameters, returns, and highlights any special cases.

•    There is a comment at the top of each code file you write with your name, section, and a brief description of what that program does.