Một Hướng Dẫn Toàn Diện Về Mô Hình Hóa CRC (Lớp Trách Nhiệm Hợp Tác)

Dựa trên các nguyên tắc nền tảng của phân tích hướng đối tượng (OO), hướng dẫn này trình bày quy trình mô hình hóa CRC. Mô hình hóa CRC là một phương pháp hiệu quả cao, công nghệ thấp, được thiết kế để thu hẹp khoảng cách giao tiếp giữa các nhà phát triển và người dùng, đảm bảo rằng các yêu cầu kinh doanh được xác định và hiểu đúng trước khi viết mã.

---

1. Các Khái Niệm Chính: Cấu Trúc Của Thẻ CRC

Mô hình hóa CRC dựa trên các thẻ ghi chú tiêu chuẩn được chia thành ba phần riêng biệt. Mỗi phần đại diện cho một khái niệm cốt lõi trong thiết kế hướng đối tượng.

A. Lớp (Phần Trên Thẻ)

Một lớp đại diện cho một tập hợp các đối tượng tương tự nhau. Một đối tượng có thể là một người, địa điểm, vật thể, sự kiện, khái niệm, màn hình hoặc báo cáo liên quan đến hệ thống.

• Quy Tắc Đặt Tên: Sử dụng một hoặc hai từ số ít (ví dụ như Khách hàng, không phải Khách hàng).

• Ví dụ: Trong một hệ thống vận chuyển/kho hàng, các lớp bao gồm Mặt hàng kho, Đơn hàng, Mặt hàng đơn hàng, Khách hàng, và Địa chỉ bề mặt.

B. Trách Nhiệm (Cột Bên Trái)

Một trách nhiệm là bất kỳ điều gì mà một lớp biết hoặc làm.

• Những gì nó biết (Dữ liệu/Thuộc tính): Ví dụ: Một Khách hàng lớp biết tên của nó, số khách hàng và số điện thoại.

• Những gì nó làm (Hành vi/Phương thức): Ví dụ: Một Khách hàng lớp có thể đặt hàng sản phẩm, hủy đơn hàng và thực hiện thanh toán.

C. Cộng tác viên (Cột bên phải)

Sự cộng tác xảy ra khi một lớp cần thông tin hoặc sự hỗ trợ từ một lớp khác để thực hiện trách nhiệm.

• Ví dụ: Một Đơn hàng đối tượng có trách nhiệm “tính tổng cộng.” Tuy nhiên, nó không biết giá của các mặt hàng hoặc số lượng đã đặt. Do đó, nó phải cộng tác với Mặt hàng đơn hàng (nhờ biết số lượng) và Mặt hàng tồn kho (nhờ biết giá) để tính tổng cộng cuối cùng.

---

2. Đội mô hình CRC

Một buổi mô hình CRC thành công đòi hỏi các vai trò cụ thể để đảm bảo quá trình diễn ra trơn tru và ghi nhận chính xác logic kinh doanh.

1. Chuyên gia lĩnh vực kinh doanh (BDEs): Những người dùng thực tế của hệ thống (thường là 4 đến 5 nhân viên trực tiếp). Họ sở hữu kiến thức kinh doanh hàng ngày. Lưu ý: Các cấp lãnh đạo thường không phù hợp cho CRC; họ phù hợp hơn với các Trường hợp sử dụng cấp cao.

2. Người điều phối: Điều hành buổi họp, giải thích kỹ thuật, đặt các câu hỏi liên quan, đảm bảo các thẻ được điền đúng, và dẫn dắt kiểm thử tình huống.

3. Người ghi chép (s): 1 hoặc 2 người ngồi ở phía sau/bên cạnh. Họ không tham gia trực tiếp vào mô hình hóa nhưng ghi chép lại logic và quy tắc kinh doanh chi tiết mà không thể ghi vào các thẻ nhỏ.

4. Người quan sát: Người học việc hoặc các bên liên quan ngồi ở phía sau và quan sát mà không tham gia.

---

3. Quy trình mô hình hóa CRC 6 bước

Bước 1: Thành lập nhóm

Thu thập 4-5 thành viên BDE trực tiếp, một người điều phối và 1-2 người ghi chép. Đảm bảo sự hỗ trợ từ quản lý để các thành viên tham gia có thể dành thời gian cần thiết.

Bước 2: Sắp xếp phòng làm việc

• Bề mặt có thể viết: Bảng flipchart hoặc bảng trắng để thảo luận ý tưởng và xây dựng bản mẫu.

• Bàn mô hình hóa: Một bàn lớn, ở trung tâm để các BDE đặt và di chuyển các thẻ.

• Vị trí ghi chép: Bàn được đặt ở xa nhưng vẫn có tầm nhìn rõ ràng.

• Đồ dùng: Thẻ nhỏ, bút dạ, và một quả bóng bóng mềm, đàn hồi (dùng sau này để kiểm thử tình huống).

Bước 3: Thảo luận ý tưởng

Đưa ra ý tưởng mà không đánh giá ngay. Người điều phối đặt các câu hỏi mở để hiểu nhu cầu kinh doanh.

• Câu hỏi ví dụ: “Hệ thống này dành cho ai?”, “Hệ thống này hỗ trợ nhu cầu kinh doanh nào?”, “Chúng ta có thể làm điều này nhanh hơn/hiệu quả hơn/ít tốn kém hơn thế nào?”, “Có những công việc đơn giản nào chúng ta có thể tự động hóa không?”

Bước 4: Giải thích kỹ thuật

Người điều phối dành 10–15 phút giải thích các khái niệm CRC, hiển thị rõ ràng các định nghĩa trên tường, và hướng dẫn nhóm tạo một vài thẻ ví dụ.

Bước 5: Mô hình hóa CRC lặp lại

Các BDE đứng hoặc ngồi quanh bàn và lần lượt xây dựng mô hình:

• Tìm lớp: Theo dõi dòng tiền, tìm kiếm báo cáo/màn hình, và xác định ngay 3-5 lớp chính.

• Tìm trách nhiệm: Hỏi lớp đó biết và làm gì.

• Xác định các cộng sự:Xác định ai đang nắm giữ thông tin bị thiếu cần thiết để thực hiện một trách nhiệm.

• Sắp xếp các thẻ: Bước quan trọng.Các thẻ hợp tác thường xuyên được đặt gần nhau trên bàn. Những thẻ ‘bận rộn’ được đặt ở trung tâm. Di chuyển các thẻ một cách vật lý giúp nhóm hình dung được các mối quan hệ và liên kết.

Bước 6: Kiểm thử tình huống dùng (Bài tập ném bóng)

Đây là một bài tập kiểm chứng nơi nhóm ‘diễn xuất’ các luồng công việc của hệ thống để đảm bảo mô hình chính xác.

1. Gọi một tình huống:Người hướng dẫn mô tả một tình huống sử dụng (ví dụ: “Khách hàng đặt hàng”) và ném quả bóng mềm cho BDE đang giữ thẻ trách nhiệm ban đầu (ví dụ:Đặt hàng).

2. Xác định trách nhiệm:Nhóm xác nhận thẻ này xử lý nhiệm vụ. Nếu không, họ cập nhật hoặc tạo thẻ mới.

3. Mô tả logic:BDE đang giữ bóng mô tả logic kinh doanh từng bước (mã giả) cho người ghi chép.

4. Hợp tác:Nếu BDE cần thông tin từ một lớp khác (ví dụ:Mặt hàng tồn kho), họ ném bóng cho BDE đang giữ thẻ đó. BDE đó sau đó mô tả phần logic của họ.

5. Chuyền bóng lại:Một khi nhiệm vụ hoàn thành, bóng được ném lại cho người trước đó, cuối cùng quay trở lại người hướng dẫn để bắt đầu tình huống tiếp theo.

---

4. CRC phù hợp như thế nào vào vòng đời phát triển phần mềm (SDLC)

Mô hình CRC không tồn tại trong khoảng trống; nó là một phần của quy trình mô hình hóa hướng đối tượng rộng lớn hơn, vốn làtheo trình tự lớn (di chuyển từ yêu cầu đến thiết kế đến mã hóa) vàlặp lại ở quy mô nhỏ (nhảy qua lại giữa các mô hình).

• Mức độ chi tiết:CRC nằm ở giữa. Bạn bắt đầu đơn giản vớiCác tình huống sử dụng vàMô hình giao diện người dùng, chuyển sang chi tiết trung bình của Mô hình CRC, và kết thúc bằng chi tiết cao của Sơ đồ lớp.

• Các sản phẩm đầu ra thúc đẩy các sản phẩm đầu ra: Sơ đồ trường hợp sử dụng được ghi chép thông qua các trường hợp sử dụng, được ghi chép bằng sơ đồ tuần tự, cuối cùng dẫn đến mã nguồn. Mô hình CRC cung cấp trực tiếp cho việc vẽ sơ đồ lớp.

---

5. Các thực hành tốt nhất và mẹo để thành công

1. Gửi chương trình họp: Phân phát chương trình họp vài ngày trước để BDE có thể chuẩn bị.

2. Hiển thị định nghĩa: Dán bố cục thẻ CRC lớn và các định nghĩa lên phía trước phòng họp.

3. Sử dụng thuật ngữ lĩnh vực: Tránh dùng thuật ngữ kỹ thuật; sử dụng chính xác những từ mà BDE sử dụng trong công việc hàng ngày của họ.

4. Giữ đơn giản, ít công nghệ: Công cụ cho CRC là tùy chọn. Giấy ghi chú nhỏ rẻ tiền, dễ mang theo và rất hiệu quả.

5. Chuẩn bị để tạo mô hình thử nghiệm: Vẽ phác thảo màn hình và báo cáo trên bảng flip-chart trong buổi họp giúp người dùng hình dung hệ thống.

6. Lên kế hoạch cho nhiều ngày: Hệ thống lớn yêu cầu nhiều buổi họp. Điều này là bình thường và cần thiết.

7. Nhận sự hỗ trợ từ ban lãnh đạo: Đảm bảo ban lãnh đạo hiểu được giá trị của việc mô hình hóa trước khi lập trình.

8. Nhắm đến nhân viên trực tiếp làm việc: CRC rất chi tiết và hoạt động tốt nhất với người dùng hàng ngày, chứ không phải các lãnh đạo cấp cao.

---

6. Ưu điểm và nhược điểm

Những ưu điểm

• Chuyên gia thực hiện phân tích: Những người thực sự làm công việc sẽ xây dựng mô hình.

• Sự tham gia cao từ người dùng:Sự tham gia tích cực làm tăng sự hài lòng và tinh thần sở hữu của người dùng.

• Xóa bỏ rào cản:Người dùng và nhà phát triển làm việc song song với nhau.

• Đơn giản và không gây áp lực:Chỉ là những tấm thẻ ghi chú. Người dùng không bị choáng ngợp bởi các công cụ phần mềm phức tạp, và họ không cảm thấy công việc của mình đang bị tự động hóa bởi một ‘máy móc’.

• Rẻ tiền và dễ mang theo:Tốn vài đô la và vừa vặn trong một chiếc cặp.

• Chuyển tiếp liền mạch:Phù hợp hoàn hảo với việc tạo mẫu và dẫn trực tiếp đến các sơ đồ lớp chính thức.

Những nhược điểm

• Gây lo lắng cho một số nhà phát triển:Một số nhà phát triển nhầm lẫn rằng kiến thức kỹ thuật của họ vượt trội hơn kiến thức kinh doanh của người dùng.

• Lên lịch trình là khó khăn:Việc tập hợp 4-5 người dùng then chốt trong cùng một phòng đòi hỏi lên kế hoạch trước.

• Thẻ bị giới hạn:Một đống thẻ ghi chú không phải là sản phẩm chính thức được chấp nhận cho phần lớn tổ chức. CRC cần được bổ sung bằng các trường hợp sử dụng chính thức, mẫu thử nghiệm và sơ đồ lớp.

---

Kết luận

Mục tiêu cuối cùng của phát triển ứng dụng là đểgiải quyết các vấn đề kinh doanh, chứ không phải để thỏa mãn sự tò mò trí tuệ của nhà phát triển bằng công nghệ mới. Mô hình CRC buộc các nhà phát triển phải làm việccùng vớingười dùng thay vì chống lại họ. Bằng cách sử dụng môi trường công nghệ thấp nhưng rất hợp tác, các đội nhóm có thể ghi nhận, xác minh và tinh chỉnh các yêu cầu kinh doanh một cách chính xác trước khi viết bất kỳ dòng mã nào.