First Assignment — Front-End and Back-End Separation Calculator System

第一次作业——前后端分离计算器系统

---

To avoid missing any assignment requirements, please review the following checklist before submission:

• Complete all required functions
• Ensure front-end and back-end separation
• Persist calculation history in the back-end database
• Deploy the project and verify accessibility
• Submit the front-end and back-end GitHub repositories
• Write and publish the assignment blog before the deadline
  • Include GitHub repository links and code standards
  • Include the PSP table
  • Include project design and implementation description
  • Include sufficient screenshots, GIFs, or videos
• Review the grading criteria

---

Deadline

本次作业的截止时间为：2026年10月7日 23:59

The deadline for this assignment is: October 7, 2026 23:59

Note: The blog needs to be reviewed after publication. Please remember to publish the blog in advance to avoid affecting the assignment submission.

注意：博客发布后需要审核，请记得提前发布博客，以免影响作业提交。

---

Part 1: Homework Content

This assignment requires students to develop a calculator system using a front-end and back-end separation architecture.

The visualization client is not restricted and may be implemented as a Web application, Android/iOS application, WeChat Mini Program, or other suitable client.

The front end is mainly responsible for user interaction and information display, while the back end is responsible for calculation, expression processing, data validation, exception handling, and database operations.

The front end and back end should communicate through network interfaces such as HTTP/HTTPS APIs.

---

1. Basic Calculator Functions

Function 1: Basic Calculation

Implement the basic calculation functions of the calculator.

At least the following arithmetic operations should be supported:

• Addition +
• Subtraction -
• Multiplication ×
• Division ÷

The user enters the calculation content through the front end, and the front end sends the calculation request to the back end.

The final calculation result must be generated by the back end and returned to the front end.

The front end is not allowed to directly complete the core calculation and then send the calculated result to the back end only for storage or display.

For example:

12 + 8

The front end may send a request similar to:

{
  "expression": "12+8"
}

The back end performs the calculation and returns a result similar to:

{
  "expression": "12+8",
  "result": 20
}

The front end then displays the result returned by the back end.

The user interface may display multiplication and division as × and ÷, while the internal expression or API representation may use * and /.

---

Function 2: Compound Expression Calculation

The calculator should support compound mathematical expressions.

For example:

1 + 2 * 3
(1 + 2) * 3
10 / 2 + 7
8 - 3 * 2
-5 + 8
3 * -2

The back end should correctly process expressions according to mathematical rules, including at least:

• Operator precedence
• Parentheses
• Unary plus and minus, such as -5 and 3 * -2
• Decimal numbers
• Invalid expression handling
• Division by zero handling

The calculation process must be completed on the back end.

The front end must not directly calculate the final result of the expression.

For security reasons, direct execution of user input through functions such as eval, exec, or other equivalent arbitrary-code execution methods is prohibited.

Safe mathematical expression parsing libraries are allowed, but methods that execute user expressions as general-purpose program code are prohibited.

Students may:

• Implement expression parsing by themselves;
• Use a safe mathematical expression parsing library;
• Use other reasonable and secure implementation methods.

If a third-party library is used, please explain the library and implementation method in the assignment blog.

---

Function 3: Calculation History

Each successful calculation should be stored in the back-end database.

The stored calculation history should contain at least:

• Calculation expression
• Calculation result
• Calculation time

For example:

ID	Expression	Result	Time
1	1+2	3	2026-10-01 10:20:00
2	5*8	40	2026-10-01 10:21:00
3	(2+3)*4	20	2026-10-01 10:22:00

The front end should be able to retrieve and display calculation history.

Calculation history must be read from the back-end database and cannot rely only on front-end cache, LocalStorage, application memory, or other temporary storage.

Refreshing, restarting, or reopening the front-end client must not cause calculation history stored in the back-end database to disappear.

---

Function 4: Delete Calculation History

Users must be able to delete a specified calculation history record.

For example, the front end may send a deletion request according to the ID of a history record, and the back end should delete the corresponding record from the database.

Clearing all calculation history may be implemented as an additional function.

The deletion operation must be completed through the back-end API, and the corresponding record must actually be deleted from the back-end database.

After deletion, the front end should update the displayed history according to the latest state of the back-end database, for example by re-querying the history API.

---

2. Front-End and Back-End Separation Requirements

This assignment focuses on front-end and back-end separation.

The project should follow an architecture similar to:

Front End
    |
    | HTTP / HTTPS API
    | JSON
    v
Back End
    |
    v
Database

The responsibilities of the front end mainly include:

• User interface presentation
• Calculator button interaction
• Expression input
• Sending calculation requests
• Displaying calculation results
• Displaying calculation history
• Sending history deletion requests
• Displaying error messages returned by the back end

The responsibilities of the back end mainly include:

• Receiving calculation requests
• Validating input
• Parsing mathematical expressions
• Performing calculations
• Handling calculation exceptions
• Storing calculation history
• Reading calculation history
• Deleting calculation history
• Returning standardized API responses

The core calculation logic must be implemented on the back end.

The following implementation does not meet the requirements:

Front end calculates the result
        ↓
Front end sends the result to the back end
        ↓
Back end only stores the result

The required implementation should be:

Front end sends the expression
        ↓
Back end validates and parses the expression
        ↓
Back end calculates the result
        ↓
Back end stores the calculation record
        ↓
Back end returns the result
        ↓
Front end displays the result

A simple verification method is to stop the back-end service.

In this case, the front end may continue to accept user input and perform normal interface interaction, but it must not be able to independently obtain a new valid calculation result.

---

3. Other Instructions

About Extended Features

Students may extend the calculator with additional functions.

Extended functions may receive extra credit. For extended functions, please describe them in detail in the blog and demonstrate their actual running effect.

Optional extended features include, but are not limited to:

• Scientific calculation
• Number-base conversion
• Unit conversion
• Calculation history search or pagination
• User accounts and independent history
• Favorite calculation records
• Keyboard shortcuts
• Theme switching
• Calculation statistics
• Other meaningful calculator-related features

Extended features must actually work.

Adding interface elements without implementing the corresponding functionality will not be considered an effective extension.

---

About Development

The choice of front-end and back-end technologies is not restricted.

For the back end, common technologies or frameworks such as the following may be used:

• Spring / Spring Boot
• Flask
• FastAPI
• Django
• Express
• NestJS
• PHP
• JSP / Servlet
• Other reasonable back-end technologies

For the front end, students may use:

• Web
• Android
• iOS
• WeChat Mini Program
• Other suitable visualization technologies

Regardless of the technology stack, the front end and back end must be separated.

The technology used should be reasonably platform compatible and should not unnecessarily depend on a specific local environment.

The main objective of this assignment is to achieve functionality and understand front-end/back-end separation. Technical complexity itself only accounts for a certain number of points.

Do not use prototype tools or other methods to directly generate the complete assignment and submit it without understanding or modification. Once confirmed, the assignment may receive 0 points.

---

About Database

The project must use a back-end database to persist calculation history.

The database type is not restricted.

For example:

• MySQL
• PostgreSQL
• SQLite
• MariaDB
• Other reasonable databases

A calculation history table may contain fields similar to:

calculation_history
-------------------
id
expression
result
created_at

The specific database structure can be determined by the student according to the actual project implementation.

The database structure and design ideas should be explained in the assignment blog.

---

Part 2: Coding Requirements

1. Use of GitHub

This assignment will continue to use GitHub for code submission.

The project requires front-end and back-end separation.

Please submit the front-end project and back-end project separately in different GitHub repositories, and provide both repository links in the blog so that teaching assistants can check them conveniently.

---

Frontend Project Directory Structure

The directory structure does not have to be exactly the same as the following example, but the project structure should be clear and reasonable.

StudentID_calculator_frontend/
├── src/
│   ├── calculator.html/.vue/.jsx/.tsx/.xml/.wxml...
│   └── ...other files
├── README.md
└── codestyle.md

For Android, iOS, WeChat Mini Program, or other clients, the directory structure may be adjusted according to the conventions of the corresponding technology.

---

Backend Project Directory Structure

The directory structure does not have to be exactly the same as the following example, but the project structure should be clear and reasonable.

StudentID_calculator_backend/
├── src/
│   ├── controller/
│   ├── service/
│   ├── model/
│   ├── calculator.java/.go/.py/.js...
│   └── ...other files
├── README.md
└── codestyle.md

Students may adjust the project directory according to the architecture and framework used.

However, the project structure should clearly reflect the responsibilities of different modules.

---

2. API Requirements

The specific URL design of the API is not mandatory, but the responsibilities of each interface should be clear.

For example:

POST   /api/calculate
GET    /api/history
DELETE /api/history/{id}

If the project implements the optional "clear all history" function, an interface such as the following may also be provided:

DELETE /api/history

Example calculation request:

{
  "expression": "(1+2)*3"
}

Example successful response:

{
  "success": true,
  "expression": "(1+2)*3",
  "result": 9
}

Example error response:

{
  "success": false,
  "message": "Invalid expression"
}

Students may design their own API URL structure and response format.

However, the front end and back end should communicate through clear network interfaces, and the interface design should be described in the assignment blog.

Students are encouraged to use appropriate HTTP status codes for successful and failed requests, such as:

• 200 OK
• 201 Created
• 204 No Content
• 400 Bad Request
• 404 Not Found
• 500 Internal Server Error

The exact status code design may be determined according to the actual API implementation.

---

3. Code Standards Development

This assignment requires the creation of a codestyle.md as a code standard document.

The code standard should be derived from mainstream official standards or standards recommended by major companies or communities.

The source of the code standard should be indicated at the beginning of the codestyle.md document.

For example:

For Python projects, you may refer to:

PEP 8

For Java projects, you may refer to:

Google Java Style Guide

For JavaScript / TypeScript projects, you may refer to:

Google JavaScript Style Guide
Airbnb JavaScript Style Guide
Other widely recognized standards

Students should select standards appropriate to their actual technology stack.

The front-end and back-end repositories should each contain the corresponding codestyle.md.

---

4. README Requirements

Both the front-end and back-end repositories should contain a README.md.

The README should briefly explain at least:

• Project introduction
• Technology stack
• Runtime environment
• Installation method
• Startup method
• Configuration instructions
• Database initialization method
• Front-end/back-end connection method
• Other necessary information for running the project

Teaching assistants should be able to understand how to install, configure, and run the project through the README.

---

5. Technologies and Frameworks

The current assignment does not restrict the choice of programming languages, libraries, databases, or frameworks.

Students may choose technologies according to their own situation.

However, the selected technology must be able to meet the functional requirements of the assignment and clearly reflect the front-end/back-end separation architecture.

---

Part 3: Blog Writing Requirements

1. Assignment Description

Briefly introduce the background, objectives, and main requirements of this assignment.

Explain that the project is a calculator system based on a front-end and back-end separation architecture.

---

2. GitHub Repository Addresses

You should include the GitHub repository addresses at the beginning of your article.

At least include:

• Front-end GitHub repository
• Back-end GitHub repository
• Front-end code standard link
• Back-end code standard link

For example:

Frontend Repository:
https://github.com/...

Backend Repository:
https://github.com/...

Frontend Code Standard:
https://github.com/.../codestyle.md

Backend Code Standard:
https://github.com/.../codestyle.md

---

3. PSP Table

Before starting the implementation of the program, record the estimated development time of various modules of the program in the PSP table.

After implementing the program, record the actual time spent in the PSP table.

The PSP table may include:

• Requirement analysis
• System design
• Front-end development
• Back-end development
• Expression calculation module
• Database design
• Calculation history module
• Front-end/back-end integration
• Testing
• Deployment
• Blog writing
• Other work

The specific PSP structure may be adjusted according to the actual project.

---

4. Deployment

The project should be deployed so that the teaching assistant can check its actual running effect.

For Web Projects

Web projects should provide a publicly accessible project address during the assignment evaluation period.

For Android, iOS, WeChat Mini Program, or Other Clients

Students should provide an appropriate installation, test, preview, or demonstration method.

Regardless of the type of front-end client, the back-end service should remain accessible during the assignment evaluation period.

The assignment blog should clearly explain:

• How to access or install the project
• How to test the project
• Any necessary test instructions
• Other information required for evaluation

---

5. Presentation of the Finished Product

Present the finished product and demonstrate the required functions.

Students should provide 10 or more screenshots, or use GIFs / embedded videos as reasonable equivalent demonstrations.

Each displayed screenshot, GIF, or video should be accompanied by a brief text description.

The demonstration should cover the main functions as much as possible, such as:

• Main calculator interface
• Addition
• Subtraction
• Multiplication
• Division
• Decimal calculation
• Compound expression calculation
• Parentheses
• Unary positive / negative numbers
• Invalid expression processing
• Division by zero processing
• Calculation history
• History persistence
• Delete a specified history record
• Extended features

Students do not have to use exactly these demonstration items.

The screenshots, GIFs, and videos should correspond to the actual implementation of the project.

---

6. Design and Implementation Process

Describe the design and implementation process of the project.

At least include:

• Requirement analysis
• Overall system architecture
• Front-end design
• Back-end design
• API design
• Database design
• Calculation module design
• Calculation history module design
• Exception handling
• Front-end/back-end interaction process
• Deployment process

Provide a functional structure diagram.

A structure similar to the following may be used as a reference:

Calculator System
|
|-- Calculator
|   |
|   |-- Basic Calculation
|   |-- Compound Expression
|   |-- Error Handling
|
|-- Calculation History
|   |
|   |-- Save History
|   |-- Query History
|   |-- Delete History
|
|-- Front End
|   |
|   |-- User Input
|   |-- Result Display
|   |-- History Display
|
|-- Back End
    |
    |-- API
    |-- Expression Processing
    |-- Calculation Service
    |-- Database

Students may design their own functional structure diagram according to the actual project.

---

7. Code Explanation

Display the key code of the project and explain the implementation ideas.

Do not simply paste a large amount of source code.

The blog should focus on explaining important implementation logic.

Recommended content includes:

• Front-end API requests
• Back-end calculation interface
• Expression parsing
• Operator precedence processing
• Input validation
• Error handling
• Database insertion
• Database query
• Database deletion
• API response design
• Other important code

Explain why the code is designed in this way.

---

8. Personal Journey and Learnings

Summarize your development experience.

You may include:

• Problems encountered during development
• Debugging process
• Difficulties in front-end/back-end communication
• Difficulties in expression parsing
• Database-related problems
• Deployment-related problems
• Solutions
• New knowledge learned
• Possible future improvements

---

Part 4: Assignment Grading Criteria and Evaluation Rules

The total score for this assignment is 100 points.

---

(30') Basic Requirements [Covering Course Objective 2]

(15') Blog Formatting

Including:

• Use Markdown formatting correctly
• Provide a valid table of contents
• Provide the GitHub repository links correctly
• Provide the code standard links correctly
• Provide the PSP table
• Provide deployment/access information
• Provide sufficient screenshots, GIFs, or videos
• Keep the article structure complete and readable

---

(15') Function Analysis and Implementation Design

Including:

• Requirement analysis
• Functional design
• Front-end/back-end architecture
• API design
• Database design
• Functional structure diagram
• Implementation process
• Key technical explanation

---

(70') Coding Implementation [Covering Course Objective 4]

(20') Frontend Page Presentation

The front end should provide a usable calculator interface.

The evaluation may include:

• Interface completeness
• Basic interaction
• Expression input
• Button interaction
• Result display
• Calculation history display
• Error message display
• Front-end/back-end communication
• Overall usability

The front end does not need to pursue excessive visual effects, but the interface should be clear and usable.

---

(50') Backend Functionality Implementation

(15') Feature 1: Basic Calculation

At least support:

• Addition
• Subtraction
• Multiplication
• Division

The calculation must be completed by the back end.

The front end must send the calculation request to the back end and display the result returned by the back end.

---

(15') Feature 2: Compound Expression Calculation

Support compound expressions and correctly process mathematical rules.

The evaluation may include:

• Operator precedence
• Parentheses
• Decimal numbers
• Unary plus and minus
• Invalid expressions
• Division by zero
• Other reasonable exception handling

The core calculation must be completed by the back end.

Direct execution of arbitrary user input using eval, exec, or equivalent arbitrary-code execution methods is prohibited.

---

(10') Feature 3: Calculation History

Calculation history should be stored in the back-end database.

The front end should be able to retrieve and display calculation history from the back end.

History data should remain available after the front-end client is refreshed, restarted, or reopened.

The implementation must not rely only on front-end cache or temporary memory.

---

(10') Feature 4: Delete Calculation History

Support deleting a specified calculation history record.

The front end should send the corresponding record identifier to the back end, and the back end should delete the corresponding database record.

After deletion, the front end should correctly display the latest history data.

The corresponding data must actually be deleted from the back-end database.

---

(Extra Credit: 0' to 10') Additional Features

Students may implement additional functions beyond the basic requirements.

Examples are provided in Part 1 — About Extended Features.

The specific extra-credit score will be determined according to:

• Completion
• Practicality
• Technical implementation
• Stability
• Demonstration effect
• Explanation in the blog

Additional features should be clearly described and demonstrated in the assignment blog.

---

Part 5: Rules & Format

1. Blog Table of Contents

To facilitate readability and assist teaching assistants in grading, please provide a table of contents at the beginning of your blog as a content index.

Ensure that the table of contents can navigate correctly!

Be sure to include the following major headings. Similar meanings are acceptable, and you may personalize your own titles:

• Git Repository Link and Code Standards Link
• PSP Table
• Presentation of the Finished Product
• Design and Implementation Process
• Code Explanation
• Personal Journey and Learnings

You may add other headings according to your project.

---

2. Course Information Description

To help teachers or teaching assistants from other schools understand the course situation, please add a format description at the beginning of the assignment:

Course for This Assignment
Assignment Requirements
Objectives of This Assignment
Other References	...

Students should fill in the corresponding information according to the actual course situation.

---

3. Submission Rules

• The submission time for the blog post is based on the class assignment page; the time of code submission is based on GitHub.

• Submitting before the deadline will be graded based on the actual score.

  • If the post is under review (the post shows 404) after publication, you can first submit the link to the assignment page before the deadline and wait for it to be approved.

  • Excuses such as upload failure or network issues for late submissions will not be accepted.

• Late Submission: Submitting within two days after the deadline is considered a late submission, and the score will be 50% of the actual score; forgetting to submit the assignment and late submissions will be penalized equally.

• Missed Submission: Failing to submit within two days after the deadline will result in a score of 0.

• Plagiarism: When the teaching assistant finds that two blog posts have text/images/code that are too similar, both blog posts will be considered plagiarism, and both will receive a -100% score (note that it is negative).

• Falsifying Submissions: Although the assignment blog may not be completed, submitting it early only to reserve a submission position will be considered a falsified submission, and the score will be 0.

Note:

For assignments submitted in advance, if you actively respond to feedback from teachers or teaching assistants and make corresponding revisions before the deadline, these improvements may also be taken into consideration during subsequent grading.

Being well-prepared in advance has many benefits~

---

4. Notices

• Class group announcements are also part of the assignment requirements.

• Please check group announcements in a timely manner.

• If you need to fill out relevant information in the group and fail to do so before the deadline, you will be penalized by 50% of the actual score.

• If you have any questions about the assignment, please raise them in the class group at least three days before the deadline.

• If there are any changes to the assignment requirements, they will be announced in the class group. Please check the announcements and update your assignment according to the latest requirements.

• Please respond promptly to feedback from the teacher or teaching assistant.

• Even after submitting the assignment, you should continue to pay attention to announcements from teachers or teaching assistants in the class group.

---

5. Clarifications

• If you find any unclear or misunderstood parts of the assignment, you can leave a comment below this blog post or directly ask questions in the QQ group or WeChat group.

• If different descriptions in the assignment appear to conflict, please confirm with the teacher or teaching assistant before implementation.

• The final interpretation of the assignment requirements is subject to the latest notice issued by the course teaching team.