Câu hỏi: SWR302 - Phần 5: Ca sử dụng, câu chuyện người dùng và quy tắc nghiệp vụ

Đáp án đúng: "A User Story is a brief description of a user’s need, typically written in the format “As a [user], I want [goal] so that [benefit].”". User story là một câu ngắn ghi nhu cầu của người dùng theo mẫu vai trò, mục tiêu, lợi ích; nó là lời hứa cho một cuộc trao đổi sau, chi tiết được bổ sung bằng tiêu chí chấp nhận. Khác biệt chính với use case: use case mô tả chi tiết chuỗi tương tác giữa tác nhân và hệ thống, có luồng chính, luồng thay thế và ngoại lệ. "A User Story is a detailed step-by-step description of the user’s interaction with the system." mô tả use case chứ không phải user story. "A User Story focuses on the system’s non-functional requirements." sai vì user story chủ yếu diễn đạt nhu cầu chức năng của người dùng. "A User Story is used to completely replace a Use Case in all situations." sai vì nhiều dự án dùng cả hai, use case hợp khi cần đặc tả chi tiết. "A User Story is a tool for test planning, while a Use Case is only for designing the interface." sai cả hai vế: cả hai đều là cách diễn đạt yêu cầu người dùng.

Đáp án đúng: "Skipping the identification of alternative flows". Một use case tốt gồm luồng chính (normal flow) cùng các luồng thay thế (alternative flows) và ngoại lệ (exceptions); bẫy thường gặp là chỉ viết con đường suôn sẻ rồi bỏ qua các biến thể, khiến hệ thống không xử lý được tình huống lệch khỏi luồng chính và lập trình viên phải tự đoán. Phương án "Including too many preconditions" không phải bẫy điển hình, vì tiền điều kiện (preconditions) là thành phần bình thường và cần thiết của use case, chỉ cần đúng và đủ. Phương án "Writing the use case without validation" là thiếu sót chung của thẩm định yêu cầu, áp cho mọi loại yêu cầu, không phải bẫy riêng của cách viết use case. Phương án "Ignoring business rules" cũng là thiếu sót chung của phân tích; use case chỉ tham chiếu tới quy tắc nghiệp vụ còn quy tắc được ghi riêng.

Đáp án đúng: "Creating highly complex use cases with many embedded logic and branching conditions, making them incomprehensible". Một cái bẫy kinh điển khi viết use case là nhồi quá nhiều logic, điều kiện rẽ nhánh và ngoại lệ vào một ca sử dụng, khiến người dùng lẫn nhà phát triển đọc không hiểu và khó thẩm định; cách chữa là giữ luồng chính ngắn gọn, tách luồng thay thế và ngoại lệ, đưa logic phức tạp sang quy tắc nghiệp vụ hoặc bảng quyết định. Phương án "Only creating a few very high-level use cases" là vấn đề khác: ca sử dụng quá chung chung thiếu chi tiết, nhưng câu hỏi hỏi về bẫy độ phức tạp. Phương án "Separating normal flows from alternative flows" là thực hành tốt được khuyến khích, không phải bẫy. Phương án "Using use case diagrams to visualize relationships." cũng là thực hành tốt, giúp nhìn tổng thể các tác nhân và ca sử dụng cùng quan hệ giữa chúng.

Đáp án đúng: "Process Flows". Phân loại đơn giản về business rule (quy tắc nghiệp vụ) có năm loại: fact (sự thật đúng về nghiệp vụ), constraint (ràng buộc giới hạn hành động), action enabler (quy tắc kích hoạt hành động khi điều kiện thoả), inference (suy diễn ra tri thức mới từ điều kiện) và computation (công thức tính toán). Luồng quy trình mô tả trình tự công việc, là mô hình quy trình chứ không phải một loại quy tắc nghiệp vụ. "Facts" là loại đầu tiên, như mỗi đơn hàng có một mã duy nhất. "Constraints" là loại giới hạn, như sinh viên chỉ được đăng ký tối đa một số tín chỉ nhất định. "Computations" là quy tắc tính toán, như công thức chiết khấu theo số lượng. "Inferences" là quy tắc suy ra kết luận, như khách quá hạn thanh toán ba mươi ngày thì bị coi là tài khoản nợ xấu.

Đáp án đúng: "A verb followed by an object". Tên use case nên thể hiện mục tiêu mà tác nhân muốn đạt, viết dạng động từ hành động cộng tân ngữ, ví dụ Request a Chemical hay Print Boarding Pass, để đọc tên là hiểu ngay người dùng làm gì với hệ thống. "A noun followed by a verb" sai trật tự, kiểu đặt tên này khiến tên giống mô tả sự vật thay vì hành động hướng tới mục tiêu. "A random combination of words" rõ ràng không có giá trị vì tên use case phải nhất quán và dễ hiểu cho mọi bên liên quan. "A descriptive phrase" nghe hợp lý nhưng quá chung chung: một cụm mô tả có thể là danh từ hay tên chức năng như Chemical Management, không nói rõ hành động và mục tiêu cụ thể, nên không phải quy ước đặt tên được khuyến nghị.

Đáp án đúng: "Include relationship". Quan hệ include dùng khi một chuỗi bước chung được nhiều ca sử dụng cần tới; phần chung được tách thành ca sử dụng riêng, và các ca sử dụng gốc luôn gọi nó. Kiểm tra tín dụng ở đây là bước bắt buộc của cả gửi yêu cầu vay lẫn đề nghị hạn mức tín dụng, nên hai ca sử dụng này include ca sử dụng Perform credit check. "Extend relationship" sai vì extend dùng cho hành vi tuỳ chọn hoặc chỉ xảy ra khi có điều kiện, bổ sung vào ca sử dụng gốc tại một điểm mở rộng; ca gốc vẫn hoàn chỉnh khi không có phần mở rộng, trong khi kiểm tra tín dụng là phần không thể thiếu. "Generalization relationship" sai vì khái quát hoá diễn tả quan hệ cha con, ca sử dụng con là một dạng đặc biệt của ca cha và kế thừa hành vi; kiểm tra tín dụng không phải dạng tổng quát của gửi yêu cầu vay hay đề nghị hạn mức, mà chỉ là một bước dùng chung.

Đáp án đúng: "include". Quan hệ include nghĩa là ca sử dụng cơ sở luôn gọi tới ca sử dụng được bao gồm như một hành vi con dùng chung; extend nghĩa là ca mở rộng chỉ chen vào ca cơ sở khi một điều kiện tuỳ chọn xảy ra. Ở đây chọn include với lập luận thanh toán hoá đơn luôn cần bước viết séc như một hành vi con dùng chung. Cần nói thẳng đây là câu còn tranh cãi: câu hỏi không mô tả nội dung hai ca sử dụng, tên Play a bill ở đây cần hiểu là Pay a bill (thanh toán hoá đơn), và nếu viết séc chỉ là một trong nhiều cách thanh toán tuỳ chọn thì quan hệ hợp lý lại là "extend"; đáp án được chốt vẫn là include. "generalization" không khớp vì quan hệ tổng quát hoá dùng khi một ca là phiên bản chuyên biệt của ca kia, mà viết séc là một bước trong việc trả tiền chứ không phải một kiểu thanh toán hoá đơn.

Đáp án đúng: "Use a word processor or a simple catalog". Business rules (quy tắc nghiệp vụ) là chính sách, quy định, công thức, ràng buộc áp lên hoạt động của tổ chức; nhiều hệ thống dùng chung một quy tắc nên cần lưu chúng ở một nơi. Cách đơn giản để bắt đầu là ghi chúng vào một danh mục quy tắc nghiệp vụ (business rules catalog) bằng trình soạn thảo hay bảng tính, mỗi quy tắc có mã, phát biểu, loại, nguồn. "Implement a full-scale business rule management tool" là bước về sau, khi tổ chức có rất nhiều quy tắc và muốn quản lý tập trung, chi phí và công sức lớn nên không phải cách bắt đầu đơn giản nhất. "Use a requirements management tool" là cách phức tạp hơn một bậc, hợp khi muốn liên kết và truy vết quy tắc tới yêu cầu, nhưng cần công cụ và cấu hình. "Write business rules directly in application code" sai vì nhúng quy tắc vào mã khiến chúng khó tìm, khó dùng lại và khó sửa khi chính sách đổi; đó không phải cách quản lý quy tắc.

Đáp án đúng: "They are short and simple, avoiding "or" logic on the left-hand side and "and" logic on the right-hand side of "if/then" constructs, to facilitate reuse and modification.". Atomic business rule (quy tắc nghiệp vụ nguyên tử) là quy tắc không thể tách nhỏ hơn mà vẫn giữ nghĩa; quy tắc dạng nếu thì có điều kiện nối bằng hoặc nên tách thành nhiều quy tắc, kết quả nối bằng và cũng vậy, nhờ đó mỗi quy tắc dễ tái sử dụng, dễ sửa và dễ truy vết. "They combine multiple details into a single complex rule" ngược hẳn với tính nguyên tử, gộp nhiều chi tiết là thứ cần tránh. "They are primarily used for computational logic" sai vì tính nguyên tử áp dụng cho mọi loại quy tắc, từ fact, constraint tới inference, không riêng computation. "They are specific to a single software application and cannot be reused." sai vì quy tắc nghiệp vụ thuộc về tổ chức chứ không thuộc một ứng dụng, và viết nguyên tử chính là để dễ tái sử dụng.

Đáp án đúng: "Use case diagrams show the graphical user interface that needs to be implemented.". Câu hỏi tìm phát biểu không đúng về mục đích của use case diagram (sơ đồ ca sử dụng): sơ đồ này chỉ thể hiện tác nhân, ca sử dụng và quan hệ giữa chúng ở mức khái niệm, hoàn toàn không mô tả màn hình hay giao diện đồ họa cần xây, vì giao diện thuộc thiết kế. Phát biểu "both behavior diagrams because they describe the behavior of the system" đúng theo UML, vì sơ đồ ca sử dụng mô tả hành vi và có thể được xem như một dạng đặc biệt của sơ đồ lớp với bộ phân loại là tác nhân và ca sử dụng, nên không được chọn. Phát biểu "usually referred to as behavior diagrams used to describe a set of actions" cũng đúng, nêu mục đích mô tả tập hành động hệ thống thực hiện cùng người dùng bên ngoài. Phát biểu "A use case describes a sequence of interactions between a system and an external actor" là định nghĩa chuẩn của ca sử dụng, nên cũng không phải đáp án.

Đáp án đúng: "A condition that must be satisfied or a state the system must be in before a use case can begin.". Trong đặc tả ca sử dụng, pre-condition (tiền điều kiện) là điều phải đúng trước khi ca bắt đầu, ví dụ người dùng đã đăng nhập; hệ thống không kiểm tra lại nó trong luồng chính mà mặc định nó đã thỏa. Phương án "A condition that describes the state of a system after a use case is successfully completed." là định nghĩa post-condition (hậu điều kiện), mô tả trạng thái sau khi ca kết thúc thành công. Phương án "A condition that initiates execution of the use case" là trigger (sự kiện kích hoạt), thứ khiến ca bắt đầu chạy, khác với điều kiện phải có sẵn. Phương án "A condition that must be satisfied so that system run successful." quá chung chung, nói về việc hệ thống chạy thành công nói chung, không gắn với thời điểm trước khi một ca sử dụng bắt đầu.

Đáp án đúng: "An atomic business rule cannot be further subdivided, whereas a composite business rule is composed of multiple atomic rules.". Quy tắc nghiệp vụ (business rule) nguyên tử là quy tắc chỉ phát biểu một điều, không tách nhỏ được nữa; quy tắc phức hợp gộp nhiều quy tắc nguyên tử lại. Viết quy tắc ở dạng nguyên tử giúp mỗi quy tắc có định danh riêng, dễ truy vết tới yêu cầu chức năng, dễ tái sử dụng và dễ sửa khi chính sách đổi. Phương án "apply only to functional requirements, while composite rules apply to non-functional" sai vì tính nguyên tử nói về cấu trúc của quy tắc, không về loại yêu cầu nó ảnh hưởng. Phương án "used only in Agile projects, whereas composite rules are used in Waterfall" sai vì quy tắc nghiệp vụ tồn tại độc lập với mô hình phát triển. Phương án "Atomic business rules are always shorter than composite rules." sai vì độ dài câu chữ không phải tiêu chí; tiêu chí là quy tắc có tách được thành quy tắc nhỏ hơn hay không.

Đáp án đúng: "fact". Trong phân loại quy tắc nghiệp vụ, fact (sự kiện) là phát biểu luôn đúng về doanh nghiệp, mô tả quan hệ hoặc thuộc tính giữa các khái niệm nghiệp vụ mà không kèm điều kiện hay hành động; câu mọi đơn hàng đều có phí vận chuyển đúng dạng này. Phương án "constraint" sai vì ràng buộc giới hạn hành động được phép, thường có dạng phải hoặc không được, ví dụ khách dưới 18 tuổi không được mua rượu. Phương án "action enabler" sai vì quy tắc kích hoạt hành động có dạng nếu điều kiện thì hệ thống làm gì đó. Phương án "inference" sai vì quy tắc suy diễn tạo ra một sự thật mới từ điều kiện, ví dụ nếu khách chưa thanh toán sau 30 ngày thì tài khoản bị coi là quá hạn. Câu được hỏi không có điều kiện hay hành động nào, chỉ nêu một sự thật.