1. Basic Information

Item	Content
Course	Software Engineering Practice
Assignment	Assignment 1
Project	Front-End and Back-End Separated Web Calculator
Main Technologies	JavaScript, Vite, FastAPI, SQLite, Render
Development Model	Front-end / Back-end Separation

The goal of this assignment is to develop a complete Web calculator based on a front-end and back-end separated architecture.

The front end is responsible for user interaction, expression input, result display, and calculation-history display. The back end is responsible for expression validation, mathematical calculation, exception handling, and database persistence.

The front end communicates with the back end through RESTful APIs.

One important design principle of this project is that the actual calculation is performed on the server side rather than directly in the browser.

---

2. Project Links

2.1 Front-End Repository

https://github.com/Victor32-max/software-engineering-homework-frontend

2.2 Back-End Repository

https://github.com/Victor32-max/software-engineering-homework-backend

2.3 Online Front-End

https://software-engineering-homework-frontend.onrender.com

2.4 Online Back-End

https://software-engineering-homework-backend.onrender.com

2.5 Swagger API Documentation

https://software-engineering-homework-backend.onrender.com/docs

2.6 Code Style

Front-end code style:

https://github.com/Victor32-max/software-engineering-homework-frontend/blob/main/codestyle.md

Back-end code style:

https://github.com/Victor32-max/software-engineering-homework-backend/blob/main/codestyle.md

---

3. Table of Contents

1. Basic Information
2. Project Links
3. Table of Contents
4. PSP Table
5. Final Product Demonstration
6. Requirement Analysis
7. Overall System Design
8. Functional Structure
9. Front-End Design
10. Back-End Design
11. REST API Design
12. Database Design
13. Expression Evaluation Design
14. Calculation History
15. Error Handling
16. Front-End and Back-End Communication
17. Deployment
18. Key Code Explanation
19. Testing
20. Problems Encountered and Solutions
21. Summary and Reflection

---

4. PSP Table

The PSP table records both the estimated time and the actual development time for each stage.

PSP Stage	Estimated Time / min	Actual Time / min
Requirement Analysis	20	20
System Design	30	30
Front-End Development	60	60
Back-End Development	60	60
Expression Evaluation	40	45
Database Design	20	30
History Module	30	25
Front-End / Back-End Integration	40	35
Testing and Debugging	40	45
GitHub Repository Preparation	25	30
Deployment	40	40
Blog Writing	60	60
Total	465	480

---

5. Final Product Demonstration

The final system provides a complete Web calculator interface with arithmetic calculation, decimal numbers, parentheses, negative numbers, error handling, persistent calculation history, history reuse, and deletion.

5.1 Main Interface

The main page contains two major areas.

The left side is the calculator, including the expression input field, result display, number buttons, operators, parentheses, clear button, backspace button, and equal button.

The right side displays the calculation history.

---

 

5.2 Addition

Input:

1+2

Expected result:

3

---

 

5.3 Subtraction and Negative Result

Input:

1-4

Result:

-3

 

---

 

5.4 Multiplication

Input: 

3*2

Result: 

6

---

 

5.5 Division

Input:

10/2

Result:

5

---

 

5.6 Decimal Calculation

Input:

1.2+3.5

Result:

4.7

---

 

5.7 Parentheses and Compound Expression

Input:

(1+2)*3

Result:

9

 

This test verifies both parentheses and operator precedence.

---

5.8 Division-by-Zero Error

Input:

1/0

The system displays:

不能除以 0

 

The application does not crash when division by zero occurs. Instead, the back end returns an error message and the front end displays it to the user.

---

5.9 Invalid Expression

Input:

1+++

The system displays:

表达式格式错误

 

This demonstrates that invalid expressions are detected on the server side.

---

5.10 Calculation History

Every successful calculation is stored in the back-end database.

Each history record contains:

Expression
Result
Created time

 

After refreshing the browser, the historical records are still available. This demonstrates that the records are persistently stored in SQLite rather than only being stored in the browser memory.

---

5.11 Reusing a Historical Expression

Each historical record contains a “Reuse” button.

When the user clicks it, the expression is automatically copied back into the calculator input field.

 

This is an additional usability feature implemented in the project.

---

5.12 Deleting History Records

Each historical record also contains a delete button.

When the user deletes a record, the front end sends a request to the back end. The corresponding record is removed from the SQLite database, and the history list is refreshed.

---

 

5.13 Swagger API Documentation

FastAPI automatically provides Swagger documentation.

The deployed API documentation can be accessed at:

https://software-engineering-homework-backend.onrender.com/docs

---

 

5.14 GitHub Repositories and Deployment

---

6. Requirement Analysis

The project contains four major functional requirements.

The first requirement is arithmetic calculation.

The calculator should support:

+
-
*
/

It should also support:

• decimal numbers;
• parentheses;
• negative numbers;
• compound expressions;
• standard operator precedence.

The second requirement is error handling.

The application should correctly handle situations such as:

Division by zero
Invalid expression
Empty expression
Unsupported expression

The third requirement is persistent calculation history.

After every successful calculation, the back end stores:

id
expression
result
created_at

The fourth requirement is history management.

The user should be able to:

• query historical records;
• reuse a previous expression;
• delete a specified record.

The core calculation must be performed by the back end.

---

7. Overall System Design

The project adopts a front-end and back-end separated architecture.

                Web Calculator
                      |
          +-----------+-----------+
          |                       |
       Frontend                 Backend
       Vite/JS                  FastAPI
          |                       |
          |      HTTP/JSON        |
          +---------------------->|
                                  |
                         Expression Parser
                                  |
                         Calculation Logic
                                  |
                              SQLite

The main data flow is:

User inputs expression
        ↓
Front-end JavaScript
        ↓
POST /api/calculate
        ↓
FastAPI receives expression
        ↓
Expression validation
        ↓
AST parsing
        ↓
Server-side calculation
        ↓
Save result into SQLite
        ↓
Return JSON response
        ↓
Display result in browser

This architecture clearly separates presentation logic from business logic.

---

8. Functional Structure

Web Calculator
│
├── Calculator
│   ├── Addition
│   ├── Subtraction
│   ├── Multiplication
│   ├── Division
│   ├── Decimal Calculation
│   ├── Parentheses
│   ├── Positive / Negative Numbers
│   └── Error Handling
│
├── Calculation History
│   ├── Save History
│   ├── Query History
│   ├── Reuse Expression
│   └── Delete History
│
├── Frontend
│   ├── Calculator Interface
│   ├── Button Interaction
│   ├── Expression Input
│   ├── API Request
│   ├── Result Display
│   └── History Display
│
└── Backend
    ├── REST API
    ├── Input Validation
    ├── AST Expression Parsing
    ├── Calculation Logic
    ├── Exception Handling
    └── SQLite Database

---

9. Front-End Design

The front end is implemented with:

HTML
CSS
JavaScript
Vite

The interface is divided into two main sections.

The calculator section includes:

Expression input
Result display
Number buttons
Arithmetic operators
Parentheses
AC
Backspace
Equal button

The history section includes:

Expression
Result
Time
Reuse button
Delete button

The front end does not calculate the final mathematical result independently.

Instead, it sends the expression to the back-end API.

---

10. Back-End Design

The back end is implemented with:

Python
FastAPI
SQLite

Its responsibilities include:

• receiving expressions from the front end;
• validating user input;
• parsing the mathematical expression;
• performing arithmetic calculations;
• detecting errors;
• writing successful calculations into SQLite;
• querying calculation history;
• deleting calculation records;
• returning JSON responses.

FastAPI was selected because it provides a simple REST API development model and automatically generates Swagger documentation.

---

11. REST API Design

The system provides three main business APIs.

HTTP Method	Endpoint	Function
POST	/api/calculate	Calculate an expression and save the result
GET	/api/history	Get calculation history
DELETE	/api/history/{history_id}	Delete a history record

There is also a basic testing endpoint:

HTTP Method	Endpoint	Function
GET	/	Check whether the back end is running

Example request:

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

Example response:

{
  "id": 1,
  "expression": "(1+2)*3",
  "result": 9,
  "created_at": "2026-10-07 15:25:39"
}

---

12. Database Design

SQLite is used as the database.

The main table is:

history
--------------------------------
id          INTEGER PRIMARY KEY
expression  TEXT
result      TEXT
created_at  TEXT

The fields have the following meanings:

• id: unique identifier of the record;
• expression: the expression submitted by the user;
• result: the calculation result;
• created_at: the time when the calculation was completed.

The table is initialized automatically when the application starts.

CREATE TABLE IF NOT EXISTS history

Therefore, no manual database initialization is required before the first run.

---

13. Expression Evaluation Design

Expression evaluation is one of the most important parts of this project.

A direct implementation such as:

eval()

or:

exec()

was intentionally avoided.

Executing raw user input with eval() may create security risks because arbitrary Python expressions could potentially be executed.

Instead, this project uses Python's ast module.

parsed = ast.parse(expression, mode="eval")

The expression is first transformed into an Abstract Syntax Tree.

Only specific AST operators are allowed:

allowed_operators = {    ast.Add: operator.add,    ast.Sub: operator.sub,    ast.Mult: operator.mul,    ast.Div: operator.truediv,    ast.USub: operator.neg,    ast.UAdd: operator.pos,}

Therefore, expressions such as:

1+2*3
(1+2)*3
-5+8
3*-2

can be correctly evaluated.

At the same time, unsupported AST node types are rejected.

This approach provides better security than executing raw input directly.

---

14. Calculation History Module

After a calculation succeeds, the result is stored using a parameterized SQL statement.

cursor.execute(    """    INSERT INTO history    (expression, result, created_at)    VALUES (?, ?, ?)    """,    (expression, str(result), created_at))

Parameterized SQL is used instead of string concatenation.

The history API is:

GET /api/history

Records are returned in descending order of ID so that newer records appear first.

A specified record can be deleted through:

DELETE /api/history/{history_id}

After deletion, the front end reloads the history data.

---

15. Error Handling

Several error conditions are handled by the application.

15.1 Empty Expression

If no expression is entered, the system returns an error message.

表达式不能为空

15.2 Division by Zero

Before performing a division operation, the back end checks whether the denominator is zero.

if operator_type == ast.Div and right == 0:    raise ZeroDivisionError("不能除以 0")

The front end then displays:

不能除以 0

15.3 Invalid Expression

For example:

1+++

The parser rejects the expression and returns:

表达式格式错误

15.4 Unsupported AST Node

Any AST node outside the allowed set is rejected instead of being executed.

---

16. Front-End and Back-End Communication

Consider the expression:

(1+2)*3

The complete process is:

① User inputs (1+2)*3
          ↓
② JavaScript reads the expression
          ↓
③ POST /api/calculate
          ↓
④ FastAPI receives JSON
          ↓
⑤ AST parses the expression
          ↓
⑥ Server calculates the result: 9
          ↓
⑦ Result is stored in SQLite
          ↓
⑧ Back end returns JSON
          ↓
⑨ Front end displays 9
          ↓
⑩ GET /api/history
          ↓
⑪ History list is refreshed

If the back-end service is unavailable, the front end can still display the calculator interface, but a new calculation cannot be completed.

This confirms that the core calculation logic is located on the server side.

---

17. Deployment

The entire project is deployed on Render.

17.1 Back-End Deployment

The FastAPI back end is deployed as a Web Service.

The dependency file is:

requirements.txt

Its main content is:

fastapi
uvicorn

The start command is:

uvicorn main:app --host 0.0.0.0 --port $PORT

The deployed back-end address is:

https://software-engineering-homework-backend.onrender.com

---

17.2 Front-End Deployment

The front end is deployed as a Render Static Site.

Build command:

npm install && npm run build

Publish directory:

dist

The deployed front-end address is:

https://software-engineering-homework-frontend.onrender.com

The front-end API base URL was changed from the local development address:

http://127.0.0.1:8000

to the deployed back-end address:

https://software-engineering-homework-backend.onrender.com

CORS was also configured on the FastAPI server so that the deployed front end can communicate with the deployed back end.

---

18. Key Code Explanation

18.1 Front-End API Request

The front end sends the expression to the back end through fetch().

const response = await fetch(
  `${API_BASE}/api/calculate`,
  {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      expression: expression
    })
  }
)

The front end only submits the expression.

It does not calculate the mathematical result itself.

---

18.2 Back-End Calculation API

@app.post("/api/calculate")def calculate(request: CalculateRequest):

The main workflow is:

Receive expression
→ Validate expression
→ Evaluate expression
→ Handle errors
→ Save history
→ Return result

---

18.3 AST-Based Expression Parsing

Only selected AST elements are accepted.

Add
Sub
Mult
Div
USub
UAdd
Constant

This avoids direct execution of arbitrary user input.

---

18.4 History Query

The query used to obtain the historical records is:

SELECT    id,    expression,    result,    created_atFROM historyORDER BY id DESC

This causes newer calculation records to appear first.

---

19. Testing

The following functional tests were performed.

Test	Input	Expected Result	Actual Result
Addition	1+2	3	Passed
Subtraction	1-4	-3	Passed
Multiplication	13*0	0	Passed
Division	10/2	5	Passed
Decimal	1.2+3.5	4.7	Passed
Operator precedence	1+2*3	7	Passed
Parentheses	(1+2)*3	9	Passed
Unary negative	3*-2	-6	Passed
Division by zero	1/0	Error message	Passed
Invalid expression	1+++	Error message	Passed
Save history	Successful calculation	Saved to database	Passed
Refresh page	Refresh browser	History remains	Passed
Delete history	Delete one record	Record disappears	Passed
Reuse expression	Click reuse	Expression is restored	Passed

---

20. Problems Encountered and Solutions

20.1 CORS Error

At the beginning of development, the front end was running at:

http://localhost:5173

while the back end was running at:

http://127.0.0.1:8000

The browser displayed an error similar to:

blocked by CORS policy

Although both services were running on the same computer, they were considered different origins.

The problem was solved using FastAPI's:

CORSMiddleware

This issue helped me better understand browser same-origin policies and why CORS configuration is necessary for separated front-end and back-end applications.

---

20.2 Git User Identity Was Not Configured

When I first attempted to commit the project, Git displayed:

Author identity unknown

The reason was that user.name and user.email had not yet been configured on the computer.

After configuring Git identity information, the local commit was completed successfully.

---

20.3 GitHub HTTPS Connection Problem

During the GitHub upload process, Git reported:

Failed to connect to github.com port 443

The browser could access GitHub normally, but Git command-line HTTPS access was unstable.

I checked the network connection, HTTPS settings, and GitHub authentication.

To ensure that the assignment could be submitted on time, I finally uploaded the project files through the GitHub Web interface.

Through this process, I became familiar with the basic workflow of:

git init
git add
git commit
git remote
git push

as well as GitHub authentication.

---

20.4 Deployment API Address Problem

After the front end was first deployed, the page displayed:

Failed to fetch

The reason was that the GitHub version of the front end was still using:

http://127.0.0.1:8000

as its back-end address.

This works only when the back-end service is running on the user's own computer.

After deployment, the front end must instead call the public Render back-end service.

Therefore, the API base URL was changed to:

https://software-engineering-homework-backend.onrender.com

After the front end was redeployed, the online application worked correctly.

This problem helped me understand the difference between local development environments and production deployment environments.

---

21. Summary and Reflection

Before completing this assignment, my understanding of front-end and back-end separation was mainly conceptual.

Through this project, I completed a relatively complete development workflow:

Requirement Analysis
→ System Design
→ Front-End Development
→ Back-End Development
→ REST API Design
→ Database Persistence
→ Integration
→ Debugging
→ GitHub
→ Cloud Deployment

The most important thing I learned was how different parts of a Web application cooperate with each other.

First, I gained a clearer understanding of the responsibility boundary between the front end and the back end. The front end mainly handles presentation and user interaction, while the back end performs the main business logic.

Second, I learned how REST APIs can be used to exchange data between two independent applications.

Third, I learned how to use SQLite to persist calculation records instead of storing data only in browser memory.

Fourth, I used an AST-based solution to safely parse mathematical expressions instead of directly calling eval().

Fifth, I encountered and solved several practical engineering problems, including CORS, Git identity configuration, GitHub authentication, network connectivity, local-to-production API migration, and Render deployment.

These problems were as valuable as implementing the calculator itself because they provided practical experience with a complete software-development process.

There are still several possible improvements for this project in the future:

Scientific calculation
History search
Clear-all-history function
Dark mode
Improved mobile responsiveness
PostgreSQL database
Environment-variable-based API configuration
Automated testing

Overall, this assignment gave me experience not only in writing code, but also in turning separate front-end, back-end, database, version-control, and deployment components into a complete Web application that can actually be accessed through the Internet.