Analysis Model )
Trong quá trình phân tích thiết kế một Use-Case, ngay ở giai đoạn đầu tiên là gặp phải một số khái niệm liên quan đến các Use-Case trong một hệ thống. Đó chính là làm sao thống nhất các khái niệm liên quan đến quá trình phân tích các Use-Case và trước hết để hiểu Use-Case đó là cái gì (What), là bởi vì các Use-
Case được cấu thành từ các khái niệm khác có liên quan có tồn tại trong thực tế hoặc trừu tượng. Muốn phân tích chính xác các Use-Case thì trước hết phải làm rõ các khái niệm liên quan cấu thành Use-Case đó trước (trả lời câu hỏi What?). Chúng ta mới chỉ có duy nhất một tài liệu Glossary giải thích các khái niệm ấy, tuy nhiên không trực quan, và rất khó được mối quan hệ giữa các khái niệm ấy.
1.10.1.4.1 Tìm kiếm các lớp phân tích
Thí dụ: Use-Case Representation (trình diễn đồ hoạ) của dự án, trước hết cần làm rõ các khái niệm :Điểm 2 chiều, điểm 3 chiều, điểm trong toạ độ cực, đường thẳng, không gian 2 chiều,không gian 3 chiều, toạ độ, thế nào là hệ trục toạ độ Decac vuông góc, thế nào là hệ toạ độ cực, hình chữ nhật, hình tròn, đối tượng đồ hoạ 2 chiều, đối tượng đồ hoạ 3 chiều, vv, và cần mô tả các mối quan hệ liên quan giữa các khái niệm cấu thành các Use-Case trong hệ thống đó. Ví dụ như: Đường thẳng được cấu thành từ hai điểm, Hình chữ nhật được cấu thành từ hai điểm (góc trên bên trái và góc dưới bên phải). Tất cả các khái niệm đó được phân tích làm rõ và thống nhất biểu diến trên mô hình Domain Model. Ví dụ sau mô tả khái niệm tọa độ của một chất điểm trong không gian hai chiều được biểu diễn trên hệ tọa độ cực, nó bao gồm một cặp hai số (x,anpha), là vị trí của chất điểm trên trục cực (x) và góc cực (anpha).
Hình 3-23 Khái niệm tọa độ cực (CVPole)
Có thể coi việc mô hình hoá các khái niệm phân tích là một loại từ điển trực quan của dự án dùng trong giai đoạn phân tích và thiết kế, thể hiện các khái niệm liên quan trong một mối quan hệ thống nhất . Trong phần này còn một chú ý đối với các nhà phát triển dự án,nếu chưa thành thạo có thể sử dụng các Pattern (Analysis Pattern) [4], có thể dễ dàng thuận tiện hơn trong các phân tích thiết kế. Trong dự án này của tôi cũng sử dụng nhiều các pattern, và nó đóng một vai trò quan trọng. Tuy nhiên. để tránh trình bày lạc chủ đề và lan man tôi xin trình bày việc áp dụng các pattern đó trong chương sau của đồ án này
x O
Phần sau đây, tôi minh hoạ một số phân tích các khái niệm cấu thành các Use-Case của dự án và mô hình hoá sử dụng công cụ UML. Ví dụ Use-Case Login (Xem phần đặc tả Use-Case login), trong quá trình phân tích xuất hiện một số khái niệm liên quan đến nó là
Record PIN: Một bản ghi bao gồm tên định danh của người sử dụng hệ thống cùng password đã được mã hoá, sử dụng để ghi vào file cơ sở dữ liệu
PIN (Personal Identification Number): định danh của người sử dụng hệ thống và password được mã hoá
CKey: Mã hoá password của người sử dụng hệ thống. Mỗi người sử dụng hệ thống có một Password riêng đồng thời có cách mã hoá riêng của họ
Các khái niệm trên có liên quan đến nhau và được mô tả sơ lược như sau
Hình 3-24 Mô hình hoá khái niệm phân tích của Use-Case Login (Analysis Model) Với Use-Case Representation cũng tương tự như vậy
Hình 3-25 Mô hình hoá các khái niệm phân tích của Use-Case Representation Tuy nhiên để nhận ra các khái niệm phân tích này đôi khi cũng không phải là dễ. Thông thường các khái niệm phân tích này thường được thể hiện dạng danh từ và chứa trong một số lĩnh vực nhất định của dự án mà nhà phát triển dự án có thể dựa vào đó để tìm kiếm các khái niệm phân tích cho dự án, bao gồm:
Các khái niệm phân tích Ví dụ trong dự án
Đối tượng vật lý có thể quan sát Máy tương quan, màn hình
Các mô tả về một vấn đề Địa điểm
Các giao dịch
Vai trò con người Quản trị hệ thống,nhân viên
Các kho chứa Kho
Các phương tiện giao dịch điện tử Thẻ từ
Khái niệm trừu tượng Hệ trục toạ độ, điểm, hình chữ nhật,đối
tượng đồ hoạ Tổ chức
Sự kiện Thanh toán,
Luật và chính sách
Hợp đồng, sổ sách tài chính Sổ sách, báo cáo
Tài liệu, sách vở liên quan
1.10.1.4.2 Quan hệ giữa các lớp phân tích
Sau khi đã tìm kiếm được các lớp phân tích thì một điều cũng quan trọng là xác định được chính xác quan hệ giữa các lớp phân tích. Vì các quan hệ này thực sự cần thiết, nó ảnh hưởng đến toàn bộ các hoạt động về sau. Nếu việc tìm kiếm các lớp phân tích thiếu xót thì chỉ dẫn đến thiếu xót một chức năng nào đó của hệ thống thì việc phân tích và xác định các quan hệ sai dẫn đến sai lệch trong quan hệ ngữ nghĩa chức năng của cả hệ thống lớn. Tuy nhiên, mục tiêu chủ yếu của giai đoạn này là tìm kiếm các lớp phân tích vì chúng quan trọng hơn
Có một số quan hệ giữa các lớp phân tích mà ta có thể quan tâm lưu ý trong khi xem xét và mô hình hoá chúng lên mô hình phân tích
Phân loại quan hệ Ví dụ trong dự án
Lớp A là một bộ phận (vật lý hoặc logic) của lớp B
Quan hệ điểm -đường thẳng (quan hệ Include)
Lớp A bị chứa trong lớp B Hình bao gồm nhiều điểm
Lớp A là một dòng (báo cáo) của lớp B Dòng báo cáo-Báo cáo Lớp A là một tổ chức hay một hệ thống
con của lớp B
Lớp A sử dụng hay quản lý lớp B
A và B là hai đối tượng kế tiếp nhau Dòng báo cáo-Dòng báo cáo
A sở hữu B
A có quan hệ thông tin đến B
Bảng 3-5 Quan hệ giữa các lớp phân tích
Có thể đặt tên cho các quan hệ giữa các lớp phân tích, trong quy trình RUP và UML quy định một số chuẩn (không bắt buộc) cho việc đặt tên quan hệ như sau: [Tên lớp phân tích ]-Động từ-[Tên lớp phân tích] trong đó Tên lớp phân tích là không bắt buộc, tên quan hệ bắt đầu bằng chữ cái in hoa. Ví dụ [Hình chữ nhật]-
chứa-[điểm] hoặc có thể ngắn gọn hơn là Chứa
Hình 3-1 Quan hệ giữa các lớp phân tích
Cụ thể chi tiết dự án thì bạn đọc có thể xem trong mô hình phân tích của dự án phần Domain Model và Analysis Model
Quan hệ các lớp phân tích