Thiết kế Hệ thống

Một phần của tài liệu Xây dựng phần mềm quản lý bvu dormitory (Trang 48)

2.3.1. Thiết kế Giao diện

2.3.1.1. Ngôn ngữ thiết kế

Mặc định, Flutter hỗ trợ 2 ngôn ngữ thiết kế là Material và Cupertino. Material là ngôn ngữ thiết kế do Google tạo ra, trong đó phổ biến trên các thiết bị Android và kể cả Web frontend.

Cupertino là ngôn ngữ thiết kế do đội ngũ Flutter phát triển, cho phép người lập trình tạo ra giao diện mang phong cách của những ứng dụng iOS.

39

Ứng dụng BVU Dormitory sử dụng ngôn ngữ thiết kế thiên về bộ Cupertino, vì bản thân tôi thấy rằng đây là một bộ giao diện có tính nhất quán cao, thoáng, và dễ sử dụng.

2.3.1.2. Darkmode – Chế độ tối

Những năm gần đây, các ứng dụng lớn như của Google, Apple, Microsoft, Facebook… đều đã cho phép người dùng bật chế độ tối khi sử dụng ứng dụng. Chế độ tối giúp giảm thiểu tình trạng mỏi mắt khi dùng ứng dụng vào ban đêm (khuya), khi môi trường xung quanh có độ tương phản thấp.

Hình 2.21. Chế độ tối của Google Search

40

Không nằm ngoài xu thế đó, ứng dụng BVU Dormitory cũng cung cấp cho người dùng tùy chọn để thay đổi giao diện sáng/tối, nhằm bảo vệ sức khỏe mắt cho người sử dụng.

2.3.2. Thiết kế Cơ sở Dữ liệu

Cơ sở dữ liệu được sử dụng cho ứng dụng BVU Dormitory là Firebase

Firestore. Firestore là một Cơ sở dữ liệu không quan hệ (NoSQL). Nghĩa

rằng giữa các bảng dữ liệu sẽ không có ràng buộc khóa chính – khóa ngoại. Dữ liệu giữa các trường (dòng/bản ghi) có thể khác nhau kể cả khi chúng cùng thuộc một bảng. Điều này làm tăng tốc độ truy vấn lên đáng kể so với các cơ sở dữ liệu SQL như Microsoft SQL, MySQL… Cũng nhờ tốc độ

41

truy vấn cao mà Firestore hỗ trợ cả realtime updating (cập nhật thời gian thực tới các client bất cứ khi nào dữ liệu trong Firestore có thay đổi).

Một số đặc điểm của Firestore:

Linh hoạt: Dữ liệu trong Firestore được cấu trúc theo dạng các

Collection (tương ứng với bảng trong SQL), bên trong các Collection chứa các Document (tương ứng với bản ghi/dòng trong SQL). Đặc biệt, Firestore cho phép “lồng Collection bên trong Document”, có nghĩa rằng trong một bản ghi lại có thể chứa một “bảng khác”

Tốc độ: Mặc định, các dữ liệu trong Firestore được đánh chỉ mục,

điều này làm cho các câu truy vấn trong Firestore luôn giữ ở tốc độ nhanh. Bên cạnh đó Firestore cung cấp phương thức để truy vấn với nhiều điều kiện phức tạp, lồng nhau.

Cập nhật thời gian thực: Cũng tương tự Firebase Realtime DB, Firestore cho phép cập nhật (đồng bộ) dữ liệu trên các thiết bị đã kết nối mạng theo thời gian thực (có nghĩa rằng độ trễ rất thấp). Bên cạnh đó Firestore cũng cho phép lấy dữ liệu theo yêu cầu (on demand) thay vì tự động đồng bộ

Hỗ trợ offline: Firestore cung cấp cơ chế hoạt động offline (ngay cả

khi thiết bị không có kết nối mạng). Có nghĩa ngay cả khi không có mạng, Firestore vẫn cho phép các hành động như đọc/ghi/cập nhật dữ liệu diễn ra, khi thiết bị được kết nối tới mạng Internet trở lại, Firestore sẽ tự động tải các thay đổi từ thiết bị lên đám mây

Tính scale cao: Firestore là Cơ sở dữ liệu hiện đại nhất của Google,

hỗ trợ việc chuyển vùng dữ liệu để đảm bảo tốc độ; đảm bảo tính nhất quán; hỗ trợ transaction cùng các thao tác hàng loạt (atomic transaction)

42

Bảo mật: Với cơ chế bảo mật thông qua Security Rule, Firestore thậm chí có thể bảo vệ dữ liệu/phân quyền tới từng trường dữ liệu (column) của một Document (bản ghi). Ví dụ điển hình là hệ thống cho phép thay đổi các trường thông tin khác nhưng không cho chỉnh sửa username.

Các Securiry Rule được lưu trữ ở phía Firebase Console (đám mây), do đó mọi client (các ứng dụng phía Frontend) khi dùng tới dữ liệu đều phải tuân theo các quy định do Security Rule đặt ra.

Hình 2.24. Ví dụ Security Rule – Chặn cập nhật trên các trường nhất định

2.3.2.1. Các bảng dữ liệu và cấu trúc

Các bảng dữ liệu trong hệ thống ứng dụng BVU Dormitory được cấu hình như sau:

43

Hình 2.25. Biểu đồ ERD các bảng trong CSDL

2.3.2.2. Bảo mật Cơ sở dữ liệu

Bằng việc sử dụng Security Rules, các quy tắc trong hệ thống phần mềm BVU Dormitory cơ bản được định nghĩa dựa trên việc hạn chế quyền truy cập theo role (chức danh người dùng), trong đó admin có toàn

44

45

Ví dụ cho thấy hiệu quả của việc sử dụng Security Rules, áp dụng lên bảng “repair requests” (Hình 2.26, dòng 57):

Trong ví dụ (các ảnh trên), ảnh 1 từ trái qua là các Yêu cầu sửa chữa ở màn hình Admin, ảnh ở giữa là khi yêu cầu có nội dung “h” đã bị xóa khỏi danh sách của Phòng 101 (vẫn ở màn hình quản trị viên). Ảnh cuối cùng là khi ở màn hình Yêu cầu sửa chữa của Sinh viên, ứng dụng không thể xóa thông tin của bất kì yêu cầu nào bởi vi phạm quy tắc của Security Rule.

Điều này cho thấy độ hiệu quả khi sử dụng Security Rule để củng cố hàng rào bảo mật, đồng thời là tính linh hoạt khi các Security Rules có thể thay đổi ở Firebase Web Console bất kì khi nào, và có hiệu lực ngay lập tức lên các máy client.

46 CHƯƠNG 3. XÂY DỰNG PHẦN MỀM

3.1. Cấu trúc dự án

Cấu trúc các thư mục trong dự án như sau:

47

Chú thích nội dung các thư mục:

1. android: code của ứng dụng Android, thư mục này được Flutter tự động

tạo ra khi tạo mới dự án

2. build: thư mục chứa các file đầu ra để cài đặt lên các máy thật hoặc xuất

bản lên Google Play Store/Apple Store (định dạng .apk/.aab/.ipa)

3. ios: code của ứng dụng iOS, thư mục này được Flutter tự động tạo ra khi

tạo mới dự án

4. lib: chứa toàn bộ code Flutter của dự án

4.1. assets: chứa các tài nguyên tĩnh (static) của dự án, ví dụ như hình ảnh, fonts, icon…

4.2. app: chứa các code cấu hình chung (global) cho dự án, như cấu hình màu sắc, giao diện (themes), các file ngôn ngữ…

4.3. base: các class khuôn mẫu (blueprints) để các class khác kế thừa, ví dụ: BaseScreen (class mẫu cho các màn hình), BaseController (class xử lý logic của màn hình), BaseFirestoreModel (class cha dành cho việc ánh xạ dữ liệu từ Firestore thành các class nhất định, ví dụ như Invoice extends

BaseFirestoreModel)

4.4. helpers: các class tiện ích, cung cấp thêm chức năng cho các class sẵn có (extensions)

4.5. models: các class ánh xạ dữ liệu từ Firestore, ví dụ: Invoice, Building, Floor, Room, Student, Service…

4.6. repositories: các class chịu trách nhiệm xử lý dữ liệu từ Firestore, ví dụ: các thao tác lấy dữ liệu từ Firestore, các thao tác thêm/xóa/cập nhật dữ liệu… đều cần thông qua các repository class

48

4.7. screens: các màn hình/chức năng. Mỗi màn hình là một thư mục chứa, trong đó bao gồm screen, controller, widget con

4.7.1. shared: các màn hình dùng chung cho các quyền admin và student 4.7.2. admin: các màn hình dành cho quyền admin

4.7.3. student: các màn hình dành cho quyền student

4.8. widgets: các thành phần giao diện dùng chung cho dự án, có thể sử dụng lại nhiều lần ở các màn hình

3.2. Cấu hình đa ngôn ngữ

Tại thư mục lib/app/locales/, bằng việc sử dụng package (thư viện)

Localization của Flutter, ứng dụng có thể hiển thị các nội dung chữ (label) ở nhiều ngôn ngữ khác nhau, các nội dung đó được định nghĩa trong các file

app_<language_code>.arb. Khi lập trình các giao diện, người lập trình sử

dụng các nội dung được định nghĩa trong các file này, thay vì gán cứng trong giao diện sẽ gây khó khăn cho việc chỉnh về sau. Trong hình dưới đây là 2 ngôn ngữ Vietnamese (app_en.arb) và English (app_vi.arb).

49

Hình 3.3. Các chuỗi được định nghĩa trong Tiếng Việt

50 3.3. Các màn hình chức năng

3.3.1. Đăng nhập

Để sử dụng được các chức năng khác có trong ứng dụng, trước hết người dùng cần định danh bản thân bằng việc đăng nhập. Với việc sử dụng dịch vụ Firebase Authentication, ứng dụng này sử dụng phương thức đăng nhập thông qua số điện thoại (OTP) để tăng tính bảo mật và loại bỏ việc phải nhớ mật khẩu cho người dùng.

Bước 1: Khởi động ứng dụng

51 Bước 2: Nhập số điện thoại và nhấn “Đăng nhập”. Màn hình xác thực Captcha sẽ hiện ra. Người dùng cần vượt qua màn hình captcha này để có thể tiếp tục.

52 Bước 3: Khi captcha được vượt qua, màn hình

hiển thị chờ người dùng nhập mã số OTP đã được gửi tới số điện thoại được nhập trước đó hiện lên. Người dùng cần kiểm tra hộp thư đến tin nhắn và nhập mã OTP vào ứng dụng.

Hình 3.7. Lỗi đăng nhập khi người dùng chưa có tài khoản trong hệ thống

53

54 3.3.2. Chức năng quản trị thông tin Sinh viên

Hình 3.10. Màn hình chính (home) của Người quản lý

3.3.2.1. Thêm thông tin hồ sơ sinh viên

Sinh viên khi nhập vào ở Ký túc xá sẽ được người quản lý nhập thông tin vào hệ thống, đồng thời chọn phòng cho sinh viên đó.

Người quản lý cần chọn Khu à Tầng à Phòng, sau đó nhập thông tin sinh viên cho phòng này.

55 Bước 1: Ở màn hình home, chọn mục Phòng, sau đó chọn phòng muốn thêm thông tin sinh viên

56 Bước 2: Chọn mục Sinh viên trong màn hình chờ của phòng

57 Bước 4: Chọn nút thêm ở góc trên-phải để mở màn hình thêm thông tin sinh viên

cho phòng hiện tại. Tiến hành nhập thông tin và nhấn Tiếp tục khi đã hoàn tất. Nếu số điện thoại đã được sinh viên khác sử dụng, một thông báo lỗi sẽ hiện lên.

58

59 3.3.2.2. Chuyển thông tin sinh viên sang phòng khác

Trong quá trình ở Ký túc xá, đôi khi sẽ có trường hợp phòng nào đó gặp sự cố và không thể ở được trong một thời gian, hoặc sinh viên mong muốn chuyển phòng, người quản lý có thể chuyển thông tin sinh viên từ phòng này sang một phòng khác trong hệ thống.

Bước 1: Tại màn hình sinh viên của phòng, chọn vào chi tiết sinh viên muốn

chuyển phòng. Hộp thoại quản trị thông tin sinh viên hiện lên, chọn Chuyển

phòng. Sau cùng, chọn phòng khác để chuyển thông tin sinh viên tới.

60

Hình 3.15. Chọn phòng mới cho sinh viên

Hình 3.16. Chuyển thông tin sinh viên thành công

61 3.3.2.3. Xóa thông tin sinh viên

Khi sinh viên không còn nhu cầu ở lại Ký túc xá, người quản lý có thể xóa thông tin hồ sơ của sinh viên để tránh những dữ liệu dư thừa không dùng tới.

Bước 1: Chọn vào chi tiết sinh viên của phòng, khi hộp thoại quản trị thông

62

Sau khi xóa thông tin hồ sơ sinh viên thành công.

63 3.3.3. Các chức năng quản trị thông tin Dịch vụ

Khi ở Ký túc xá, một phòng thường đi kèm với các dịch vụ như: điện, nước,

wifi… Người quản lý có thể cấu hình thêm/cập nhật thông tin của các dịch vụ

như tên, đơn giá theo thời điểm nhằm đáp ứng nhu cầu thực tế.

Bước 1: Tại màn hình home, chọn mục Dịch vụ.

64 Bước 2: Tại đây, người quản lý có thể chọn vào dịch vụ để quản trị, hoặc nhấn

65 3.3.4. Chức năng quản trị thông tin Tài sản

Trong Ký túc xá, ở mỗi phòng đều có sử dụng/gắn các tài sản ví dụ như:

Giường, bóng đèn điện, điều hòa, bồn lavabo…

Người quản lý có thể quản trị thông tin các tài sản như thêm/cập nhật thông tin, gán thông tin vào phòng/bỏ gán khỏi phòng.

3.3.4.1. Quản trị thông tin Danh mục tài sản Bước 1: Tại màn hình home, chọn mục Tài sản

66 Bước 2: Tại đây, người quản lý có thể nhấn giữ để chọn vào danh mục tài sản

muốn quản trị, hoặc nhấn nút thêm ở góc trên-phải để mở màn hình thêm thông tin danh mục tài sản (danh mục tài sản ở đây có nghĩa là nhóm các loại tài sản

lại với nhau theo mục đích sử dụng hoặc tính năng)

67 3.3.4.2. Quản trị thông tin Loại tài sản

Loại tài sản ở đây là những tài sản có cùng nhà cung cấp, cùng mẫu mã. Các loại tài sản cùng đặc tính thì nằm chung trong danh mục tài sản.

Bước 1: Khi nhấp vào thông tin danh mục tài sản, màn hình chi tiết các loại tài

sản sẽ hiện ra

Người quản lý có thể nhấn giữ lên mục muốn quản trị, hoặc nhấn nút thêm ở góc trên-phải để mở cửa sổ thêm thông tin loại tài sản.

68 3.3.4.3. Quản trị thông tin Mã tài sản

Mã tài sản là các tài sản đơn lẻ, cùng thuộc một loại tài sản. Mỗi mã tài sản sẽ được gán vào phòng nào đó để thể hiện việc phòng sử dụng tài sản.

Bước 1: Tại màn hình các loại tài sản, khi nhấp vào một loại tài sản, màn hình chi

tiết các mã tài sản của thuộc loại đó sẽ hiện ra

69 3.3.4.4. Gán/Gỡ thông tin Mã tài sản lên phòng

Bước 1: Tại màn hình các mã tài sản, chọn vào mã tài sản muốn quản trị. Khi màn hình quản trị thông tin mã tài sản hiện ra, chọn vào Gỡ/Gán thông tin.

70 Bước 2: Khi chọn Gán vào phòng, màn hình chọn phòng hiện ra, người quản lý

chọn phòng muốn gán để gán thông tin mã tài sản vào phòng mong muốn

71

Mã tài sản sau khi Gỡ khỏi phòng sẽ hiện dấu “?’ ngay dưới chuỗi mã tài sản (ght1 trong hình dưới).

Hình 3.25. Mã tài sản sau khi gỡ thông tin khỏi phòng

72 3.3.5. Chức năng quản trị thông tin Yêu cầu sửa chữa

Trong quá trình ở Ký túc xá sẽ không thể tránh khỏi những sự cố xảy ra trong một phòng, ví dụ khi hỏng bóng điện, hỏng ống nước…

Người quản lý và sinh viên đều có thể tạo thông tin yêu cầu sửa chữa thông qua ứng dụng để lưu lại trong hệ thống. Người quản lý dựa vào thông tin các yêu cầu để chuẩn bị phương án xử lý – chuẩn bị đồ nghề khi đến phòng giải quyết sự cố.

Bước 1: Tại màn hình sảnh chờ của một phòng, chọn mục Yêu cầu sửa

chữa/Các yêu cầu. tại đây các yêu cầu trước đó sẽ hiện ra. Người quản

lý/Sinh viên thuộc phòng có thể chọn vào mục muốn quản trị thông tin, hoặc nhấp vào nút thêm ở góc trên–phải để mở cửa sổ thêm thông tin yêu cầu sửa chữa cho phòng

73

Hình 3.28. Màn hình cập nhật thông tin yêu cầu sửa chữa

74 3.3.6. Chức năng quản trị thông tin Hóa đơn

Mỗi cuối tháng, người quản lý có nhiệm vụ đi tới từng phòng để ghi nhận thông tin các chỉ số điện nước, nhằm tổng hợp thông tin và ghi phiếu báo tiền dành cho mỗi phòng.

Người quản lý có thể tạo thông tin hóa đơn cho các phòng, chi tiết hóa đơn được tính dựa trên tổng đơn giá của các dịch vụ mà phòng đang sử dụng. Các dịch vụ “tịnh tiến” như điện, nước được ứng dụng tự động lấy thông

tin chỉ số cũ từ hóa đơn gần nhất, đảm bảo việc tự động hóa trong cách

Một phần của tài liệu Xây dựng phần mềm quản lý bvu dormitory (Trang 48)

Tải bản đầy đủ (PDF)

(117 trang)