A Kết quả phân loại câu hỏi môn KTLT và CTDL&GT
3.9 Use-case diagram của hệ thống xây dựng
Trong các tính năng trên thì các tính năng đã có trong AGS và được sử dụng lại là: quản lý tổ chức, quản lý khố học, quản lý nhóm, quản lý bài thực hành trong khoá học và làm bài thực hành. Như vậy, các tính năng mới nhóm sẽ xây dựng là: làm bài thực hành tự luyện tập, quản lý ngân hàng câu hỏi, phân loại độ khó câu hỏi.
Đối với mỗi tính năng, nhóm xác định các u cầu sau:
• Tính năng làm bài thực hành nói chung (bài tập được gán và tự luyện tập): hệ thống kiểm tra tính đúng đắn của bài nộp và đưa kết quả đến người học. Việc chấm bài cần được thực
hiện bất đồng bộ. Hệ thống chấm bài một cách ổn định khi số lượng người dùng tăng lên, và có cơ chế mở rộng đơn giản bằng cách tăng con chấm.
• Tính năng làm bài thực hành tự luyện tập: tự động gợi ý các câu hỏi từ dễ đến khó và phù hợp với khả năng của từng người học.
• Tính năng quản lý ngân hàng câu hỏi: giúp người dạy tổ chức lưu trữ các câu hỏi lập trình một cách tiện lợi, là nguồn cung cấp câu hỏi đến người học.
• Tính năng phân loại câu hỏi: phân loại độ khó câu hỏi trên kết quả làm bài của người học, giúp người dạy xem xét đánh giá lại độ khó của câu hỏi gán cho người học.
3.3 Kiến trúc hệ thống mới
Cùng với những tính năng mới và một số yêu cầu được đặt ra, nhóm đề xuất một số thay đổi trên kiến trúc hệ thống đang có, cụ thể:
• Hệ thống sẽ có thêm những thành phần mới như Classifier dùng cho tính năng phân loại độ khó câu hỏi, Suggestor dùng cho tính năng gợi ý câu hỏi.
• Hệ thống phải thay đổi thành phần chấm bài, vì hiệu năng của con chấm được sử dụng là không tốt. Nguyên nhân cơ bản là do cơ chế bật tắt liên tục giữa mỗi lần chấm bài, do vậy cần tìm một giải pháp ln bật để cải thiện về hiệu năng cho q trình chấm bài. Ngồi ra, cần xem xét về luồng bất đồng bộ đang được sử dụng để tối ưu hơn nếu có thể.
Với sự thay đổi về các thành phần mới như Classifier, Suggestor:
• Nhờ vào kiến trúc microservices hiện có của AGS, nhóm thêm vào hai thành phần mới vào hệ thống để thực hiện các chức năng mới mà khơng gây ảnh hưởng gì đến các nghiệp vụ hiện có.
• Các thơng tin mà hai thành phần này cần như câu hỏi, bài nộp đều có sẵn trên CSDL của hệ thống. Do vậy, nhóm sẽ thiết kế hai thành phần này chỉ nhận lời gọi (request) từ phía Back-end và còn lại sẽ kết nối trực tiếp với CSDL của hệ thống để truy xuất thơng tin.
• Nhóm cũng cân nhắc về luồng thực thi cho cả hai quá trình là phân loại câu hỏi cũng như gợi ý câu hỏi. Vì cả hai đều cần lượng thơng tin lớn, xử lý dữ liệu nhiều, do vậy thời gian phản hồi tương đối lâu. Vì vậy, nhóm sẽ học tập luồng thực thi chấm bài để thiết kế các luồng thực thi cho hai thành phần này theo hướng bất đồng bộ để tối ưu hiệu năng của hệ thống.
Với sự thay đổi về thành phần con chấm, nhóm nhận thấy, con chấm Jobe của tiện ích CodeRunner cho nền tảng Moodle là một sự thay thế phù hợp. Khơng những có cơ chế hoạt động như nhóm mong đợi, mà nó cịn đang được sử dụng khá rộng rãi và ổn định trên các trang lớn như Bách Khoa e-Learning với số lượng người dùng tương đối lớn. Các thông tin chi tiết hơn và các đánh giá về Jobe sẽ được trình bày sau, tại phần 4.1.2.
Về luồng chấm bài bất đồng bộ hiện có của AGS, nhóm đánh giá là vẫn có cơ hội để cải tiến hơn nữa, thông qua việc ứng dụng một công nghệ mới là trung gian truyền tải thông điệp (message broker).
Message broker có khả năng chuyển hồn tồn luồng thực thi về bất đồng bộ, thay vì phải sử dụng kết hợp tổ hợp lời gọi chấm bài và một hàng đợi thông điệp (message queue) như hiện tại.