Câu hỏi về Critical Design Review

Mục tiêu chính của Critical Design Review (CDR) là gì?

• Đảm bảo giao diện đồ họa người dùng hoàn thiện.

• Xác nhận rằng thiết kế chi tiết phù hợp với yêu cầu.

• Xây dựng tất cả các sequence diagrams.

• Hoàn thành việc lập trình các lớp cơ bản.

Critical Design Review (CDR) nên được tổ chức khi nào?

• Ngay sau khi kết thúc giai đoạn phát triển.

• Trước khi bắt đầu lập trình.

• Trong giai đoạn kiểm thử.

• Sau khi phát hành sản phẩm.

Một nguyên tắc quan trọng trong thiết kế đối tượng (OOD) được nhấn mạnh trong Critical Design Review (CDR) là gì?

• Phân tách trách nhiệm (Responsibility-Driven Design).

• Tối ưu hóa giao diện người dùng.

• Tăng số lượng lớp để đảm bảo tính linh hoạt.

• Tập trung vào thiết kế giao diện.

Critical Design Review (CDR) có thể giúp phát hiện lỗi nào trong class diagram?

• Các lớp không có thuộc tính hoặc các lớp có quá nhiều trách nhiệm.

• Các lỗi trong cơ sở dữ liệu.

• Các lỗi trong việc thiết kế giao diện người dùng.

• Các lỗi về cú pháp mã nguồn.

Tại sao cần đảm bảo rằng các sequence diagram bao phủ cả kịch bản chính và kịch bản thay thế?

• Để giảm số lượng use case cần thiết.

• Để hệ thống có thể xử lý các tình huống bất thường.

• Để đảm bảo tính linh hoạt của giao diện người dùng.

• Để loại bỏ các lớp không cần thiết.

Một lỗi phổ biến liên quan đến "anemic domain model" là gì?

• Các lớp domain chỉ có thuộc tính mà không có hành vi.

• Các lớp controller chứa quá nhiều logic xử lý.

• Không sử dụng class diagram.

• Tập trung vào giao diện người dùng thay vì logic.

Một lợi ích của việc tập trung các trách nhiệm vào các lớp domain là gì?

• Dễ dàng tìm và sửa đổi các thay đổi liên quan đến domain.

• Giảm số lượng use case cần thiết.

• Tăng tốc độ lập trình.

• Loại bỏ nhu cầu sử dụng class diagram.

Khi nào cần chia nhỏ một sequence diagram thành nhiều diagram khác nhau trong quá trình Critical Design Review (CDR)?

• Khi một diagram trở nên quá phức tạp hoặc có nhiều kịch bản thay thế.

• Khi số lượng lớp trong class diagram vượt quá giới hạn.

• Khi một use case có ít hơn 3 kịch bản chính.

• Khi không có đủ thông điệp trên diagram.

Một lớp domain không có thuộc tính và chỉ có phương thức. Điều này có hợp lý không?

• Không hợp lý; cần thêm các thuộc tính để đảm bảo lớp thể hiện đầy đủ dữ liệu cần thiết.

• Hợp lý; các lớp domain chỉ cần các phương thức xử lý logic.

• Không hợp lý; cần chuyển các phương thức sang lớp controller.

• Hợp lý nếu các thuộc tính được xử lý ở lớp DAO.

Trong Critical Design Review (CDR), làm thế nào để kiểm tra rằng các lớp trong class diagram không vi phạm nguyên tắc phân tách trách nhiệm?

• Đảm bảo rằng mỗi lớp chỉ có một lý do để thay đổi.

• Loại bỏ tất cả các phương thức không cần thiết.

• Tăng số lượng thuộc tính trong các lớp.

• Giảm số lượng lớp xuống mức tối thiểu.