Bối cảnh và vấn đề nghiên cứu

Trong bối cảnh xã hội hiện đại phát triển không ngừng, việc duy trì sức khỏe, kiểm soát vóc dáng và thực hiện lối sống lành mạnh đã trở thành mối quan tâm hàng đầu của con người. Sức khỏe bền vững đòi hỏi sự kết hợp đồng bộ giữa chế độ dinh dưỡng hợp lý, thời gian nghỉ ngơi khoa học và chế độ vận động thể chất thường xuyên. Tuy nhiên, phần lớn cá nhân gặp khó khăn trong việc tự định lượng chính xác khối lượng chất dinh dưỡng và năng lượng nạp vào cơ thể mỗi ngày, cũng như chưa đánh giá được mức độ tiêu hao năng lượng tương ứng với từng cường độ vận động. Nhằm giải quyết nhu cầu kiểm soát thói quen ăn uống và sinh hoạt, tác giả Nguyễn Văn Phú đã thực hiện đồ án tốt nghiệp ngành Công nghệ Thông tin với đề tài "Xây dựng website tính calories" tại Trường Đại học Sư phạm Kỹ thuật Thành phố Hồ Chí Minh, dưới sự hướng dẫn của ThS. Nguyễn Hữu Trung.

Về tính cấp thiết, tác giả chỉ ra rằng quỹ thời gian của người tiêu dùng ngày càng bị thu hẹp, dẫn đến nhu cầu gia tăng đối với các ứng dụng tiện ích, dễ thao tác và có tính tùy biến cao. Mặc dù thị trường đã xuất hiện nhiều ứng dụng đo lường chỉ số sức khỏe, phần lớn các giải pháp hiện nay chưa tối ưu hóa trải nghiệm cho người dùng Việt Nam do rào cản ngôn ngữ, giao diện phức tạp hoặc dữ liệu thực phẩm chưa phù hợp. Đề tài được xây dựng nhằm đáp ứng hai tiêu chí cốt lõi: đơn giản, dễ sử dụng và có độ đa dạng chức năng cao.

Mục tiêu và nhiệm vụ nghiên cứu của đề tài được phân định cụ thể thành hai phần:

  1. Phần lý thuyết:
    • Tìm hiểu và nghiên cứu framework phát triển giao diện Flutter.
    • Tìm hiểu và nghiên cứu web framework FastAPI trên nền tảng Python.
    • Nghiên cứu cơ sở lý thuyết về tỷ lệ trao đổi chất cơ bản (BMR) và tổng năng lượng tiêu thụ hàng ngày (TDEE).
    • Tìm hiểu cơ chế lập lịch tự động cronjob phục vụ hệ thống thông báo.
  2. Phần thực hành:
    • Sử dụng FastAPI để thiết kế và xây dựng tầng xử lý phía máy chủ (server-side) theo kiến trúc RESTful API.
    • Sử dụng Flutter để phát triển giao diện người dùng phía máy khách (client-side).
    • Cài đặt và tích hợp các công thức tính toán BMR và TDEE vào logic xử lý nghiệp vụ của hệ thống.
    • Thiết lập cronjob nhằm gửi thông báo nhắc nhở tự động cho người dùng.

Đối tượng và phạm vi nghiên cứu của đồ án bao gồm:

  • Đối tượng sử dụng hệ thống: Được chia làm hai nhóm tác nhân chính:
    • Người dùng thông thường (User): Đăng ký tài khoản, đăng nhập, khai báo các chỉ số thể chất (chiều cao, cân nặng, độ tuổi, mục tiêu thể trạng) để hệ thống tính BMR; nhập nhật ký thực phẩm tiêu thụ theo bữa ăn; ghi nhận các bài tập thể thao thực hiện trong ngày; theo dõi lượng calo nạp vào, lượng calo đốt cháy và calo còn lại; tra cứu lịch sử ăn uống, luyện tập và xem thống kê dinh dưỡng theo ngày hoặc theo tuần.
    • Người quản trị hệ thống (Admin): Thực hiện quản lý danh mục dữ liệu nền tảng, bao gồm thêm, xem, chỉnh sửa và thay đổi trạng thái hoạt động của danh mục thực phẩm, hàm lượng dinh dưỡng và các bài tập luyện.
  • Phạm vi nghiên cứu: Hệ thống tập trung giải quyết các nghiệp vụ vận hành của một ứng dụng quản lý chỉ số calories hoàn chỉnh trên môi trường web. Thời gian thực hiện đồ án diễn ra từ ngày 21/08/2023 đến ngày 25/12/2023.

Cơ sở lý thuyết và phương pháp

Khung lý thuyết và mô hình tính toán năng lượng sinh học

Đồ án tích hợp hai chỉ số sinh học quan trọng để định lượng năng lượng cơ thể:

  • Tỷ lệ trao đổi chất cơ bản (BMR - Basal Metabolic Rate): Đây là mức năng lượng tối thiểu cần thiết để duy trì các chức năng sống cơ bản của cơ thể (hô hấp, tuần hoàn) ở trạng thái nghỉ ngơi. Hệ thống áp dụng công thức Mifflin-St Jeor dựa trên các tham số: giới tính, độ tuổi (năm), chiều cao (cm) và cân nặng (kg):
    • Nam giới: $\text{BMR} = (9.92 \times \text{age}) + 5$
    • Nữ giới: $\text{BMR} = (9.92 \times \text{age}) - 161$
  • Tổng tiêu thụ năng lượng hàng ngày (TDEE - Total Daily Energy Expenditure): Là tổng năng lượng cơ thể sử dụng cho mọi hoạt động trong 24 giờ, được tính theo công thức: $$\text{TDEE} = \text{BMR} \times R$$ Trong đó, hệ số vận động $R$ được xác định theo 4 cấp độ:
    • $R = 1,2$: Người không vận động hoặc rất ít vận động (nhân viên văn phòng, thu ngân).
    • $R = 1,375$: Người vận động nhẹ, tập luyện từ 1 đến 3 buổi/tuần (nhân viên giao hàng).
    • $R = 1,55$: Người vận động cường độ vừa phải từ 4 đến 5 buổi/tuần (nhân viên phục vụ, giáo viên thể chất).
    • $R = 1,9$: Người vận động cường độ rất cao, chế độ tập luyện khắc nghiệt (vận động viên).
  • Quy tắc điều chỉnh cân nặng:
    • Tăng cân: Nạp lượng calo lớn hơn TDEE.
    • Giảm cân: Cắt giảm từ 200 đến 300 calo so với mức TDEE.
    • Duy trì cân nặng: Nạp lượng calo tương đương TDEE.

Phương pháp nghiên cứu

Đồ án áp dụng các phương pháp nghiên cứu kỹ thuật bao gồm:

  1. Phương pháp khảo sát hiện trạng: Đánh giá, phân tích chức năng và giao diện của ba ứng dụng theo dõi calo hiện hành: MyNetDiary, MyFitnessPal và Calorie Counter - EasyFit.
  2. Phương pháp so sánh và lựa chọn công nghệ: Phân tích định lượng các thông số kỹ thuật giữa các framework front-end (Flutter, React Native, Kotlin) và back-end (FastAPI, Flask, Django).
  3. Phương pháp phân tích và thiết kế hệ thống hướng đối tượng: Sử dụng chuẩn UML để xây dựng biểu đồ Use Case, các biểu đồ tuần tự (Sequence Diagrams) và thiết kế cơ sở dữ liệu quan hệ.
  4. Phương pháp kiểm thử chức năng (Functional Testing): Thiết lập các ca kiểm thử (test cases) để đánh giá độ chính xác của các luồng nghiệp vụ trên hệ thống thực nghiệm.

Nguồn dữ liệu

Dữ liệu sử dụng trong hệ thống bao gồm danh mục các loại thực phẩm, món ăn, định lượng dinh dưỡng (Protein, Carb, Fat, Calories) và danh mục các bài tập vận động thể chất (phân loại theo Cardio và Strength).

Thiết kế và triển khai

Kiến trúc tổng thể của hệ thống

Hệ thống được thiết kế theo kiến trúc 3 tầng truyền thống (3-tier architecture):

  • Tầng trình diễn (Front-end): Xây dựng bằng Flutter, chịu trách nhiệm kết xuất giao diện người dùng đa nền tảng và tiếp nhận tương tác.
  • Tầng ứng dụng (Back-end): Sử dụng FastAPI (ngôn ngữ Python), xây dựng theo kiến trúc RESTful API, tiếp nhận yêu cầu từ client, xử lý logic nghiệp vụ và tính toán các chỉ số BMR/TDEE.
  • Tầng cơ sở dữ liệu (Database): Sử dụng hệ quản trị cơ sở dữ liệu quan hệ PostgreSQL để lưu trữ thông tin người dùng, lịch sử dinh dưỡng, nhật ký vận động và danh mục hệ thống.

Phân tích và lựa chọn công nghệ

Tiêu chí so sánh Flutter React Native Kotlin
Năm phát hành 2018 2015 2011
Đơn vị phát triển Google Facebook JetBrains
Ngôn ngữ lập trình Dart JavaScript Kotlin
Mã nguồn Mã nguồn mở Mã nguồn mở Mã nguồn mở
Tốc độ lập trình Nhanh Chậm hơn Flutter Chậm hơn Flutter
Độ phổ biến Rất phổ biến Rất phổ biến Trung bình
Khả năng tái sử dụng code 95% 85% 70%
Hiệu suất Nhanh Bình thường Nhanh hơn Flutter một chút
Hỗ trợ Hot reload Có hỗ trợ Không hỗ trợ Không hỗ trợ

Tác giả lựa chọn Flutter nhờ khả năng chia sẻ mã nguồn lên đến 95%, hỗ trợ tính năng hot reload giúp rút ngắn thời gian phát triển giao diện và có tài liệu phong phú từ Google.

Tiêu chí so sánh FastAPI Flask Django
Năm phát hành 2018 2010 2005
Tác giả / Tổ chức Sebastián Ramírez Armin Ronacher Django Software Foundation
Ngôn ngữ Python 3.7+ Python Python
Mã nguồn Mã nguồn mở Mã nguồn mở Mã nguồn mở
Tốc độ lập trình Rất nhanh Bình thường Bình thường
Độ phổ biến Thấp Cao nhất Cao
Khả năng tái sử dụng code Cao Cao Cao
Hiệu suất Rất cao Hiệu suất cao Hiệu suất thấp

FastAPI được chọn cho tầng back-end nhờ hiệu suất cao ngang tầm Node.js và Go nhờ khả năng xử lý bất đồng bộ, giảm thiểu khoảng 40% lỗi lập trình phát sinh, tối giản mã nguồn trùng lặp và tuân thủ các chuẩn mở JSON Schema.

Thiết kế dữ liệu và các quy tắc nghiệp vụ (Business Rules)

Hệ thống quản lý dữ liệu qua các bảng thực thể chính: Food_Diary, Food_History, Exercise_Diary, Exercise_History, Notification_Count cùng các bảng người dùng và danh mục thực phẩm. Các quy tắc ràng buộc bao gồm:

  • BR1-1 & BR1-2: Địa chỉ email người dùng phải có định dạng @gmail.com; mật khẩu bắt buộc phải được mã hóa trước khi lưu trữ vào cơ sở dữ liệu.
  • BR2-1: Trường hợp người dùng đăng nhập sai mật khẩu quá 3 lần liên tiếp, hệ thống tự động khóa tài khoản trong thời gian 5 phút.
  • BR3-1, BR3-2, BR3-3: Chiều cao tính bằng centimet (cm), cân nặng tính bằng kilogram (kg); các chỉ số cân nặng hiện tại, cân nặng mong muốn và mục tiêu không được mâu thuẫn logic.
  • BR9.1-1, BR9.1-2: Thời gian tập bài cardio tính bằng phút, giới hạn không quá 480 phút.
  • BR9.2-1, BR9.2-2: Số lượt tập bài strength tính bằng set, giới hạn không vượt quá 50 set.
  • BR10-1: Kết quả tìm kiếm thực phẩm và bài tập được phân trang, tải tối đa 10 mục mỗi lần.
  • NFR12.4-1 & NFR13.4-1: Khi thực hiện xóa thực phẩm hoặc bài tập, hệ thống áp dụng cơ chế xóa mềm (soft delete) bằng cách cập nhật thuộc tính status sang giá trị INACTIVE, không xóa vật lý khỏi cơ sở dữ liệu nhằm bảo toàn lịch sử người dùng.
  • NFR5-1, NFR12.1-1: Tất cả các thao tác nghiệp vụ (xem nhật ký, tạo mới danh mục) phải đảm bảo thời gian phản hồi dưới 1 giây.

Nội dung chính theo từng chương

Chương 1: Tổng quan về đề tài

Chương này tập trung trình bày bối cảnh xã hội, lý do chọn đề tài và tính cấp thiết của việc xây dựng công cụ tính calories phù hợp với người dùng trong nước. Tác giả tiến hành khảo sát và đánh giá hiện trạng của ba ứng dụng tương tự trên thị trường.

Tiêu chí MyNetDiary MyFitnessPal Calorie Counter - EasyFit
Giao diện Cơ bản, nhiều chi tiết rườm rà, khó sử dụng Bình thường, đơn giản, dễ thao tác Thiết kế đẹp mắt, sinh động, có thanh đo calo biến động linh hoạt
Bảo mật Không yêu cầu xác thực nhiều bước Không yêu cầu xác thực nhiều bước Đơn giản, không đòi hỏi xác thực nhiều bước
Tính năng Đầy đủ tính năng cơ bản; một số tính năng yêu cầu trả phí Đầy đủ tính năng cơ bản miễn phí; yêu cầu trả phí cho tính năng nâng cao Đầy đủ tính năng; tính năng Current Streak và Water Tracker yêu cầu trả phí
Tốc độ tải dữ liệu Nhanh Nhanh Nhanh
Ưu điểm Đưa ra lời khuyên dinh dưỡng và luyện tập phù hợp Nền tảng xã hội chia sẻ món ăn, dữ liệu lớn (khoảng 5 triệu món ăn), hỗ trợ tiếng Việt Hơn 80.000 món ăn, có chức năng quét mã vạch thực phẩm
Nhược điểm Nhiều thông tin dư thừa, ngôn ngữ chính là tiếng Anh Khó tùy chỉnh kích thước khẩu phần ăn, dễ trùng lặp tên món ăn Ngôn ngữ tiếng Anh, tính năng mở rộng có thu phí

Từ kết quả khảo sát, tác giả xác định các yêu cầu chức năng (quản lý BMR, TDEE, nhật ký, thống kê, cảnh báo cronjob) và yêu cầu phi chức năng (giao diện đơn giản, tốc độ phản hồi nhanh, dữ liệu chính xác). Kế hoạch thực hiện đồ án được chia thành 13 giai đoạn từ 21/08/2023 đến 25/12/2023.

Chương 2: Cơ sở lý thuyết

Chương 2 mô tả chi tiết kiến trúc 3 tầng và giao thức RESTful API kết nối giữa các dịch vụ. Nội dung chương đi sâu vào việc so sánh định lượng giữa Flutter với React Native và Kotlin; phân tích hiệu năng của FastAPI trước Flask và Django. Tác giả trình bày tường minh các công thức toán học sinh học để tính toán chỉ số BMR theo Mifflin-St Jeor và chỉ số TDEE với các hệ số vận động $R$ từ 1,2 đến 1,9, làm cơ sở khoa học cho thuật toán tính mức thâm hụt hoặc thặng dư năng lượng.

Chương 3: Phân tích thiết kế

Chương 3 là phần trọng tâm về kỹ thuật phần mềm, thiết lập toàn bộ mô hình chức năng của hệ thống. Tác giả xây dựng đặc tả chi tiết cho 18 nhóm Use Case chính:

  • Nhóm xác thực và người dùng: UC-1 (Đăng ký), UC-2 (Đăng nhập), UC-3 (Nhập thông tin cá nhân), UC-4 (Chỉnh sửa thông tin cá nhân).
  • Nhóm nhật ký và tìm kiếm: UC-5 (Xem nhật ký), UC-6 (Xem nhật ký ngày hôm trước), UC-7 (Xem nhật ký ngày hôm sau), UC-8 (Thêm đồ ăn vào nhật ký), UC-9.1 (Thêm bài cardio), UC-9.2 (Thêm bài strength), UC-10 (Tìm kiếm thức ăn), UC-11 (Tìm kiếm bài tập).
  • Nhóm quản trị: UC-12.1 đến UC-12.4 (Tạo, xem, sửa, xóa thực phẩm), UC-13.1 đến UC-13.4 (Tạo, xem, sửa, xóa bài tập).
  • Nhóm lịch sử, thống kê và thông báo: UC-14.1, UC-14.2 (Xem lịch sử dùng thực phẩm và luyện tập), UC-15, UC-16 (Cập nhật và xem thông tin dinh dưỡng), UC-17.1, UC-17.2 (Xem thống kê dinh dưỡng theo ngày và tuần), UC-18.1, UC-18.2 (Xem thông báo chưa nhập nhật ký cuối ngày và thông báo thiếu chất theo tháng).

Đi kèm với các use case là các biểu đồ tuần tự (Sequence Diagram) mô tả luồng thông điệp giữa Actor, Front-end, Back-end API và Cơ sở dữ liệu. Chương này cũng hoàn thiện sơ đồ quan hệ thực thể và mô tả chi tiết các bảng dữ liệu.

Chương 4: Hệ thống thử nghiệm và kiểm thử

Chương này trình bày kết quả hiện thực hóa giao diện người dùng và kiểm thử phần mềm. Tác giả xây dựng hệ thống màn hình UI trên Flutter bao gồm: Welcome page, Đăng nhập, Dashboard Admin, Danh sách Food/Exercise, Màn hình tạo và chỉnh sửa danh mục, Màn hình Diary (hỗ trợ chuyển đổi ngày hiện tại, ngày hôm trước, ngày hôm sau), Màn hình tìm kiếm và Giao diện thông tin người dùng. Phần kiểm thử tập trung thực hiện các ca kiểm thử chức năng cho quá trình đăng ký tài khoản, đăng nhập, thêm/chỉnh sửa thực phẩm và thêm bài tập thể chất.

Chương 5: Kết luận và hướng phát triển

Chương tổng kết đánh giá mức độ hoàn thành nhiệm vụ nghiên cứu, nêu rõ các nội dung đã đạt được, chỉ ra các mặt hạn chế còn tồn đọng và đề xuất các hướng mở rộng cho hệ thống trong tương lai.

Kết quả và đóng góp

Kết quả chính đạt được

  • Xây dựng thành công ứng dụng web tính toán và theo dõi calo hoàn chỉnh, tích hợp kiến trúc 3 tầng: giao diện Flutter, máy chủ API FastAPI và cơ sở dữ liệu PostgreSQL.
  • Cài đặt chính xác các thuật toán tính toán năng lượng sinh học dựa trên công thức Mifflin-St Jeor và TDEE, cho phép tự động xác định lượng calo mục tiêu dựa trên chiều cao, cân nặng, giới tính, độ tuổi và mức độ vận động.
  • Thiết lập đầy đủ chức năng quản lý nhật ký ăn uống và vận động hàng ngày, hỗ trợ tìm kiếm linh hoạt dữ liệu thức ăn và bài tập thể thao (phân chia cardio theo phút, strength theo set).
  • Cài đặt hệ thống thông báo định kỳ sử dụng cơ chế cronjob, tự động nhắc nhở người dùng chưa hoàn thành nhật ký vào cuối ngày và cảnh báo tình trạng thiếu hụt nhóm chất dinh dưỡng theo chu kỳ tháng.
  • Đáp ứng các yêu cầu phi chức năng đề ra: thời gian xử lý và phản hồi nghiệp vụ dưới 1 giây, cơ chế soft delete giúp duy trì toàn vẹn dữ liệu.

Giải pháp và đóng góp của tác giả

  • Cung cấp một giải pháp phần mềm hướng tới người dùng Việt Nam với giao diện trực quan, tinh giản các bước thao tác so với các ứng dụng quốc tế phức tạp.
  • Khắc phục các hạn chế về việc dữ liệu trùng lặp hoặc khó kiểm soát phần ăn của MyFitnessPal bằng cách xây dựng quy trình phân quyền quản trị Admin chặt chẽ, kiểm soát định danh duy nhất và phân trang tìm kiếm (10 mục/lần).
  • Kết hợp công nghệ hiện đại (Flutter đa nền tảng và FastAPI bất đồng bộ) giúp tối ưu hóa khả năng tái sử dụng mã nguồn và nâng cao hiệu suất xử lý hệ thống.

Hạn chế và hướng nghiên cứu tiếp

Hạn chế

  • Ứng dụng mới dừng lại ở việc xử lý các nghiệp vụ cơ bản của một website tính calo, chưa bao quát được các kịch bản dinh dưỡng chuyên sâu hoặc các chế độ ăn bệnh lý.
  • Dữ liệu thực phẩm và bài tập phụ thuộc hoàn toàn vào quá trình nhập liệu thủ công của người quản trị, chưa có cơ chế thu thập dữ liệu tự động hoặc mở cho cộng đồng đóng góp có kiểm duyệt.
  • Chưa tích hợp tính năng quét mã vạch (barcode scanner) trực tiếp từ bao bì thực phẩm như các ứng dụng thương mại MyFitnessPal hay Calorie Counter - EasyFit đã làm được.

Hướng nghiên cứu tiếp

  • Mở rộng kho dữ liệu thực phẩm, cập nhật phong phú các món ăn truyền thống và đặc trưng của từng vùng miền tại Việt Nam.
  • Nghiên cứu và phát triển tính năng quét mã vạch thực phẩm qua camera thiết bị để tự động trích xuất thông tin dinh dưỡng.
  • Tích hợp thêm các chỉ số theo dõi sức khỏe chuyên sâu như lượng nước uống hàng ngày (Water Tracker) hoặc theo dõi chuỗi ngày hoàn thành mục tiêu (Current Streak).
  • Mở rộng khả năng kết nối đồng bộ dữ liệu với các thiết bị đo bước chân và đồng hồ thông minh để tự động cập nhật mức độ tiêu hao năng lượng.

Giá trị tham khảo

Đồ án là tài liệu tham khảo hữu ích cho:

  • Sinh viên ngành Công nghệ thông tin và Kỹ thuật phần mềm: Cung cấp tài liệu mẫu mực về quy trình xây dựng đồ án tốt nghiệp, từ khảo sát hiện trạng, so sánh lựa chọn công nghệ, phân tích yêu cầu bằng chuẩn Use Case Specification đến thiết kế sơ đồ tuần tự và cơ sở dữ liệu.
  • Lập trình viên full-stack: Cung cấp ví dụ thực tế về việc kết hợp framework Flutter ở phía máy khách với FastAPI ở phía máy chủ, đặc biệt là cách tổ chức kiến trúc RESTful API bất đồng bộ và xử lý ràng buộc nghiệp vụ (Business Rules).
  • Người phát triển ứng dụng y tế - sức khỏe: Cung cấp phương pháp số hóa các công thức tính toán năng lượng sinh học (Mifflin-St Jeor, TDEE, phân bổ dinh dưỡng đa lượng Macro) vào hệ thống phần mềm quản lý chỉ số cơ thể.

Câu hỏi thường gặp

1. Đồ án áp dụng công thức nào để tính chỉ số BMR và TDEE?

Tác giả áp dụng công thức Mifflin-St Jeor để tính chỉ số BMR dựa trên giới tính và độ tuổi (với nam: $\text{BMR} = 9.92 \times \text{age} + 5$; với nữ: $\text{BMR} = 9.92 \times \text{age} - 161$). Chỉ số TDEE được tính bằng công thức $\text{TDEE} = \text{BMR} \times R$, trong đó hệ số vận động $R$ nhận các giá trị cố định gồm 1,2 (ít vận động), 1,375 (vận động nhẹ), 1,55 (vận động vừa) và 1,9 (vận động nặng).

2. Kiến trúc công nghệ của hệ thống được tổ chức như thế nào?

Hệ thống được tổ chức theo mô hình 3 tầng truyền thống giao tiếp qua RESTful API: tầng trình diễn front-end sử dụng framework Flutter (ngôn ngữ Dart), tầng xử lý nghiệp vụ back-end sử dụng framework FastAPI (ngôn ngữ Python) và tầng lưu trữ dữ liệu sử dụng hệ quản trị cơ sở dữ liệu PostgreSQL.

3. Cơ chế xóa dữ liệu thực phẩm và bài tập của người quản trị được thiết kế ra sao?

Theo quy tắc phi chức năng NFR12.4-1 và NFR13.4-1 trong tài liệu đặc tả, hệ thống không thực hiện xóa vật lý các bản ghi thực phẩm hoặc bài tập khỏi cơ sở dữ liệu PostgreSQL. Thay vào đó, hệ thống thực hiện cơ chế xóa mềm bằng cách cập nhật thuộc tính status của bản ghi sang trạng thái INACTIVE, giúp bảo toàn dữ liệu lịch sử nhật ký của người dùng đã sử dụng trước đó.

4. Hệ thống thiết lập những quy tắc nghiệp vụ nào đối với bảo mật tài khoản và nhập liệu nhật ký?

Về bảo mật, hệ thống quy định email đăng ký phải có đuôi @gmail.com, mật khẩu phải được mã hóa trong cơ sở dữ liệu và tài khoản sẽ bị tạm khóa 5 phút nếu đăng nhập sai quá 3 lần liên tiếp. Về nhật ký tập luyện, bài tập cardio giới hạn thời gian nhập tối đa 480 phút, còn bài tập strength giới hạn số set tập không quá 50.

5. Tại sao FastAPI được lựa chọn cho tầng back-end thay vì Flask hay Django?

Dựa trên bảng phân tích so sánh công nghệ của tác giả, FastAPI cung cấp hiệu suất xử lý rất cao sánh ngang với Node.js và Go nhờ khả năng xử lý bất đồng bộ, tốc độ lập trình rất nhanh, hỗ trợ giảm thiểu khoảng 40% lỗi lập trình phát sinh và được xây dựng trên các tiêu chuẩn mở hiện đại như JSON Schema.

Kết luận

Khóa luận tốt nghiệp "Xây dựng website tính calories" của sinh viên Nguyễn Văn Phú đã hoàn thành việc nghiên cứu lý thuyết và xây dựng thành công một ứng dụng quản lý dinh dưỡng và vận động thể chất hoàn chỉnh. Hệ thống kết hợp hài hòa giữa kiến trúc giao diện Flutter đa nền tảng, máy chủ dịch vụ FastAPI hiệu năng cao và cơ sở dữ liệu PostgreSQL, giải quyết tốt bài toán tính toán năng lượng BMR và TDEE theo chuẩn khoa học. Toàn bộ tài liệu đặc tả use case, quy tắc nghiệp vụ và kết quả kiểm thử được trình bày chặt chẽ, tạo nền tảng vững chắc cho việc phát triển và mở rộng các giải pháp phần mềm theo dõi sức khỏe trong tương lai.