24127167-Wu Zhengyang-First Assignment-Front-End and Back-End Separation Calculator
Assignment 1: Front-End and Back-End Separation Calculator System
| Course for This Assignment | Software Engineering Practice |
|---|---|
| Assignment Requirements | Front-end / back-end separated calculator system |
| Objectives | Master front-end/back-end separation, API development, database persistence, system design, and technical blog writing |
| Name / Student ID | WU Zhengyang / 24127167 |
Repositories
- Frontend: https://github.com/Wzy13850918263/24127167_calculator_frontend
- Backend: https://github.com/Wzy13850918263/24127167_calculator_backend
1. PSP Table
| PSP2.1 | Stages | Estimated (min) | Actual (min) |
|---|---|---|---|
| Planning | Planning | 30 | 25 |
| Development | Development | 320 | 360 |
| · Analysis | · Requirements analysis | 30 | 25 |
| · Design | · System/API/DB design | 40 | 45 |
| · Coding | · Backend (RPN + DB) | 90 | 110 |
| · Coding | · Frontend page | 60 | 70 |
| · Test | · Test all features | 30 | 35 |
| Reporting | Reporting | 150 | 160 |
| Total | Total | 500 | 545 |
2. Requirements Analysis
This assignment requires a strictly separated front-end / back-end calculator. All computation must run on the backend; the frontend only collects the expression and sends it via HTTP POST. History must persist in a backend database (no localStorage). Must support operator precedence, parentheses, decimals, unary minus. No eval/exec. Two independent GitHub repos, each with README.md and codestyle.md. Support deleting history by id.
Tech stack: Python + FastAPI, SQLite, plain HTML/CSS/JS, hand-written Reverse Polish Notation.
3. System Design
Browser (index.html)
│ HTTP/JSON
▼
FastAPI (main.py)
├── Expression parser (tokenize → infix-to-postfix → evaluate)
├── History module (SQLAlchemy ORM)
▼
SQLite (calculator.db)
| Endpoint | Method | Purpose |
|---|---|---|
| /api/calculate | POST | Calculate expression and save to history |
| /api/history | GET | Get all history (descending) |
| /api/history/{id} | DELETE | Delete a record by id |
4. Feature Demonstration
Main Interface

Basic Arithmetic (12+8=20)

Decimal (2.5*4=10)

Parentheses ((1+2)*3=9)

Unary Minus (3*-2=-6)

Division by Zero

Invalid Expression

History List

Refresh Keeps History

Delete Record

5. Key Code
Frontend: submit expression
async function submitCalc(){
const resp = await fetch(BACKEND_URL + "/api/calculate", {
method: "POST",
headers: {"Content-Type": "application/json"},
body: JSON.stringify({expression: inputDom.value.trim()})
});
const data = await resp.json();
resultDom.innerText = data.success ? "Result = " + data.result : "Error: " + data.message;
loadHistory();
}
Backend: calculate API
@app.post("/api/calculate")
def calc(req: CalcRequest):
db = SessionLocal()
try:
res = calculate_expression(req.expression)
record = CalcHistory(expression=req.expression, result=res)
db.add(record); db.commit()
return {"success": True, "expression": req.expression, "result": res}
except ZeroDivisionError:
return {"success": False, "message": "Division by zero"}
except Exception as e:
return {"success": False, "message": "Invalid expression: " + str(e)}
finally:
db.close()
Unary minus tokenization
if c == "-":
if i == 0 or expr[i-1] in "(+-*/":
tokens.append("u-") # unary minus
else:
tokens.append(c) # binary subtraction
6. Summary
- CORS: opened index.html via file:// blocked fetch; fixed with CORSMiddleware.
- Unary minus was the hardest part —
3*-2and leading-5needed a separateu-token with highest precedence. - All errors caught at the API layer to avoid 500s.
- History verified by refreshing and restarting the backend.
- Key takeaway: frontend is dumb (display + request), backend is the brain (compute + store).
相关推荐
Delphi 13.2控件之扫描大师PRO-推广介绍.rar
Delphi 13.2控件之扫描大师PRO-推广介绍.rar
一个MATLAB应用设计器系统,用于校准负载传感器、估算未知重量并计数果冻豆。.zip
1.版本:matlab2014a/2019b/2024b 2.附赠案例数据可直接运行。 3.代码特点:参数化编程、参数可方便更改、代码编程思路清晰、注释明细。 4.适用对象:计算机,电子信息工程、数学等专业的大学生课程设计、期末大作业和毕业设计。
插座数据集821张VOC+YOLO格式.zip
数据集格式:Pascal VOC格式+YOLO格式(不包含分割路径的txt文件,仅仅包含jpg图片以及对应的VOC格式xml文件和yolo格式txt文件) 图片数量(jpg文件个数):821 标注数量(xml文件个数):821 标注数量(txt文件个数):821 标注类别数:1 所在github仓库:datasets_sl 标注类别名称:["socket"] 每个类别标注的框数: socket 框数 = 1165 总框数:1165 每个类别占有图片数: socket 占有图片数 = 821 图片分辨率:多分辨率图片,如667x500,889x500等 使用标注工具:labelImg 数据集是否增强:否 标注规则:对类别进行画矩形框 重要说明:数据集没有划分训练验证测试集需自行划分 特别声明:本数据集不对训练的模型或者权重文件精度作任何保证
光伏阵列故障特性分析与故障定位方法研究(Simulink仿真实现)
内容概要:本文系统研究了光伏阵列的故障特性分析与故障定位方法,并基于Simulink平台进行了仿真验证。文章首先对光伏阵列在典型故障工况下的电气行为进行建模,深入分析了短路、断路、局部阴影遮挡等常见故障对系统输出电流、电压及功率特性的影响规律,揭示了各类故障的独特电气特征。在此基础上,提出了具有针对性的故障检测判据与定位算法,并构建了包含光伏模块、MPPT控制器、逆变器及并网控制环节在内的完整光伏系统Simulink仿真模型,用于验证所提方法的有效性。仿真结果能够清晰呈现不同故障场景下的动态响应过程,实现了对故障类型和位置的准确识别,为光伏发电系统的智能运维、故障预警及安全稳定运行提供了坚实的理论依据和技术支撑。; 适合人群:具备电力电子技术、新能源发电系统等相关基础知识,从事光伏系统故障诊断、电力系统自动化、智能电网监控等领域的科研人员与工程技术人员,尤其适合研究生及以上学历层次或拥有相关科研项目经验的专业人士。; 使用场景及目标:①作为光伏电站故障诊断算法研究与教学演示的核心参考资料;②为开发高可靠性、智能化的光伏电站监控与运维系统提供理论模型和仿真验证平台;③服务于高水平学术论文撰写、科研课题申报及光伏发电工程项目前期的技术可行性论证。; 阅读建议:建议读者结合提供的Simulink仿真模型进行同步操作与参数调试,通过对比不同故障场景下的仿真波形,深刻理解故障机理与定位逻辑,重点掌握电气特征与故障类型的映射关系,为进一步改进现有算法或开发新型故障识别策略以提升系统的定位精度、鲁棒性和实时性奠定基础。
使用模型预测控制(MPC)对锂离子电池组进行实时电动汽车电池单体均衡MATLAB中实现.rar
使用模型预测控制(MPC)对锂离子电池组进行实时电动汽车电池单体均衡MATLAB中实现.rar


