Một tổng kết nho nhỏ về các quan hệ giữa các actor và

actor ,
usecase và usecase.
1. ĐỊNH NGHĨA ACTOR :
Actor là Một người hay một thứ gì đó nằm ngoài hệ
thống và tương tác hệ thống, mong chờ kết quả có thể
thấy được từ hệ thống.
2. LƯU Ý VỀ NHẬN DẠNG ACTOR :
• Máy in có phải là actor hay không ? Nếu lập trình
driver để tương tác với máy in mới nhất thì máy in
là acto . Nếu lập trình phần mềm có chức năng in
thì máy in không là actor
• Nếu lập trình chuột thay bằng bút vẽ thì chuột là
actor vì mình tốn công lao lập trình cái đó, nếu
đơn giản quá thì không cần chuột là actor
• Nếu lập trình chương trình auto game online phải
đọc bộ nhớ trạng thái nhân vật thì các phần mềm
game là actor của chương trình autoplay đó
• Khi viết 1 plugin cho chương trình outlook thì
outlook là actor của plugin
3. CÁC QUAN HỆ GIỮA CÁC ACTOR
3.1 Quan hệ tổng quát hóa
(generalization) . Chi tiết –> tổng quát
- Quan hệ tổng quát hóa làm cho gọn gàng mô
hình chứ không có ý nghĩa gì trong coding
- Ví dụ về dùng quan hệ generalization sai
- Giả sử ta có sơ đồ use case sau :
- Bác sĩ thì có các use case sau :
• Ghi nhận toa thuốc
• Ghi nhận bệnh án
• Tra cứu thuốc
- Y tá thì có các use case sau :
• Ghi nhận bệnh án
• Tra cứu thuốc
• Tra cứu bệnh
- Bệnh nhận thì có các use case sau
• Tra cứu thuốc
• Tra cứu bệnh
- Nhận xét rằng : 3 actor trên có sử dụng chung
nhiều usecase , nên ta gom thành “thừa số chung”
dùng quan hệ generalization
- Bạn thấy mô hình 2 nhìn sạch sẽ gọn gàng hơn
mô hình 1 , nhưng điều đó không hợp lý , nếu làm bài
thi sẽ bị 0 điểm ngay , vì đơn giản , quan hệ
generalization là quan hệ IS-A , A ->B thì đọc là A là
trường hợp đặc biệt của B. Nên khi dùng ta phải xét
ngữ nghĩa có hợp lý không, đọc lên phải có nghĩa 1
chút , không bị ngượng nghĩu . Nếu theo quan hệ trên
mô hình 2 mình đọc là :
• Bác sĩ là trường hợp đặc biệt của y tá
• Y tá là trường hợp đặc biệt của bệnh nhân
- Bạn thấy đọc lên là đã không đúng rồi.
4. QUAN HỆ GIỮA CÁC ACTOR VÀ USECASE
4.1 Include :
- Trên mũi tên lúc nào cũng có : stereotype
<<include>>.
- A –included–> B : trong A luôn có B, B không
đứng độc lập được , nó luôn 1 phần của 1 user case lớn
• B là use case nhỏ
• A là use case lớn (use case gốc) ,
- Mũi tên thường là nét đứt (tùy công cụ CASE)
- User case gốc ở gốc mũi tên. Người ta thường
sử dụng usecase để tách 1 phần chung của nhiều
usercase
VD1 :

- Nghĩa là :
• Giáo viên chọn môn học để giảng dạy thì bắt buộc
phải đăng nhập (xác nhận người dùng)
• Giáo viên yêu cầu phân công giảng dạy bắt buộc
phải đăng nhập
VD2 :
Nghĩa là
• Thủ Thư : muốn xóa độc giả thì luôn phải qua use
case tra cứu độc giả
• Thủ Thư : muốn cập nhập độc giả thì luôn phải
qua use case tra cứu độc giả
• (có thể hiểu nữa là phải qua 1 GUI , hay 1 màn
hình tra cứu độc giả nữa)
4.2 Extend
• Ký hiệu : A –extended–> B :
o B là use case lớn (use case gốc ),
o A là use case nhỏ
o Use case mới (A) mở rộng (extend) use case
ban đầu vì nó thêm các bước mới vào trình tự
trong use case gốc, hay được gọi là use case
cơ sở (base).
o Trên mũi tên lúc nào cũng có : stereotype
<<extend>>.
• Việc mở rộng chỉ xảy ra tại một số điểm cụ thể
trong trình tự của use case cơ sở. Những điểm này
gọi là điểm mở rộng (extension point)
• Mũi tên thường là nét đứt (tùy công cụ CASE)
Người ta dùng mối quan hệ extend để chỉ rõ
• Hành vi tùy chọn
 • Hành vị chỉ xảy ra dưới một số điều kiện nào đó
(chẳng hạn kích hoạt 1 báo động)
• Nhiều luồng sự kiện có thể xảy ra theo sự lựa chọn
của actor
- Nếu extend có điều kiện mở rộng thì điều kiện
và điểm mở rộng được ghi trong 1 Chú thích (hình chữ
nhật có gấp góc). Nếu điểm mở rộng không có điều
kiện thì điểm mở rộng được viết trong hình elip của
user case gốc của extend.

4.3 Generalization
- Không có gì để nói , giống quan hệ
generalization của actor hay class