không ñược xây dựng sẵn trong UML mà có thể thực hiện thông qua
việc thêm vào một giá trị thẻ.
•
Constraints (ràng buộc): mở rộng ngữ nghĩa của các thành phần của
UML, cho phép tạo ra những quy tắc mới hoặc sửa chữa những quy
tắc ñã có.
9. Kiến trúc của hệ thống
Khi xem xét một hệ thống, chúng ta cần xây dựng các mô hình từ những
khía cạnh khác nhau, xuất phát từ thực tế là những người làm việc với hệ
thống với những vai trò khác nhau sẽ nhìn hệ thống từ những khía cạnh khác
nhau.
UML xét hệ thống trên 5 khía cạnh:

1. Use-Case View
Bao gồm các Use Case mô tả ứng xử của hệ thống theo cách nhìn nhận của
người dùng, người phân tích hệ thống. Nó không chỉ ra cách cấu trúc của hệ
thống phần mềm, nó chỉ dùng ñể nhìn nhận một cách tổng quát những gì mà
hệ thống sẽ cung cấp, thông qua ñó người dùng có thể kiểm tra xem các yêu
cầu của mình ñã ñược ñáp ứng ñầy ñủ hay chưa hoặc có chức năng nào của
hệ thống là không cần thiết. Biểu ñồ dùng ñến là biểu ñồ Use Case.
2. Logical View
ðược dùng ñể xem xét các phần tử bên trong hệ thống và mối quan hệ, sự
tương tác giữa chúng ñể thực hiện các chức năng mong ñợi của hệ thống.
3. Process View
Chia hệ thống thành các tiến trình(process) và luồng(thread), mô tả việc
ñồng bộ hóa và các xử lý ñồng thời. Dùng cho người phát triển và tích hợp
hệ thống, bao gồm các biểu ñồ sequence, collaboration, activity và state.
4. Implementation View
Bao gồm các component và file tạo nên hệ thống vật lý. Nó chỉ ra sự phụ
thuộc giữa các thành phần này, cách kết hợp chúng lại với nhau ñể tạo ra
một hệ thống thực thi.

•
ðối với một vấn ñề cụ thể nào ñó thì Ai là người quan tâm ?
•
Hệ thống ñược dùng ở nơi nào trong tổ chức?
•
Ai là người ñược lợi khi sử dụng hệ thống?
•
Ai là người cung cấp thông tin cho hệ thống, sử dụng thông tin của hệ
thống và xóa các thông tin ñó?
•
Ai là người hỗ trợ và bảo trì hệ thống?
•
Hệ thống có sử dụng nguồn lực nào từ bên ngoài?
•
Có người nào ñóng một vài vai trò trong hệ thống? Có thể phân thành
2 actor
•
Có vai trò nào mà nhiều người cùng thể hiện? Có thể chỉ là một actor
•
Hệ thống có tương tác với các hệ thống nào khác không?
Có 3 loại Actor chính là:
•
Người dùng. Ví dụ: sinh viên, nhân viên, khách hàng
•
Hệ thống khác.
•
Sự kiện thời gian. Ví dụ: Kết thúc tháng, ñến hạn
ðiều gì tạo nên một tập hợp Actor tốt?
Cần phải cân nhắc kỹ lưỡng khi xác ñịnh actor của hệ thống. Công việc này
thường ñược thực hiện lặp ñi lặp lại. Danh sách ñầu tiên về các actor hiếm

như thế nào. Tập hợp tất cả Use case của hệ thống sẽ mô tả tất cả các trường
hợp mà hệ thống có thể ñược sử dụng.
Một Use case có thể có những biến thể. Mỗi một biến thể ñược gọi là một
kịch bản (scenario). Phạm vi của một Use case thường ñược giới hạn bởi các
hoạt ñộng mà người dùng thực hiện trên hệ thống trong một chu kì hoạt
ñộng ñể thực hiện một sự kiện nghiệp vụ.
Một Use case mô tả một nghiệp vụ thông thường. Nghiệp vụ này bao gồm
các bước riêng rẽ, còn ñược gọi là các hoạt ñộng. Khi các bước ñược mô tả
dưới dạng văn bản thì việc chỉ ra sự phụ thuộc giữa các bước là một việc mất
nhiều thời gian. Việc thể hiện các bước dưới dạng kí hiệu là dễ dàng và dễ
hiểu hơn. Do ñó Use case thường ñược mô tả chi tiết thông qua các biểu ñồ
mô tả hành vi (behavior) như biểu ñồ hoạt ñộng (activity diagram), biểu ñồ
trình tự (sequence diagram), biểu ñồ hợp tác(collaboration diagram).
Use case cũng có thể ñược mô tả thông qua các thiết kế nguyên mẫu màn
hình, các ví dụ về biểu mẫu báo cáo. ðiều này giúp cho người dùng dễ dàng
mường tượng hệ thống sẽ làm việc như thế nào, qua ñó có thể kiểm tra tính
ñúng ñắn của Use case.
Các câu hỏi thường ñược sử dụng ñể xác ñịnh Use Case cho một hệ thống
là:
•
Nhiệm vụ của mỗi actor là gì?
•
Có actor nào sẽ tạo, lưu trữ, thay ñổi, xóa hoặc ñọc thông tin trong hệ
thống?
•
Có actor nào cần báo tin cho hệ thống về một thay ñổi ñột ngột từ bên
ngoài?
•
Có actor nào cần ñược thông báo về một sự việc cụ thể xảy ra trong hệ
thống?

Ví dụ: trong luồng sự kiện chúng ta nói “Kiểm tra mã của người dùng” chứ
không nói rằng việc ñó phải thực hiện bằng cách xem xét ở trong một bảng
nào ñó trong cơ sở dữ liệu. Nó mô tả chi tiết những gì người dùng của hệ
thống sẽ làm và những gì hệ thống sẽ làm. Nó cần phải ñề cập tới:
•
Use case bắt ñầu và kết thúc khi nào và như thế nào
•
Có những sự tương tác nào giữa Use case và actor ñể thực hiện chức
năng ñó.
•
Những dữ liệu nào cần thiết cho Use case
•
Thứ tự thực hiện thông thường của các sự kiện
•
Các mô tả về các luồng ngoại lệ hoặc rẽ nhánh.
Mỗi dự án cần có một mẫu chuẩn cho việc tạo tài liệu về luồng sự kiện. Có
thể dùng theo mẫu ñơn giản như sau:
•
X. Luồng sự kiện cho Use case ABC
•
X1. ðiều kiện bắt ñầu: danh sách những ñiều kiện phải thỏa mãn
trước khi Use case ñược thực hiện. Ví dụ như: một Use case khác phải
thực hiện trước khi Use case này ñược thực hiện hay người dùng phải
có ñủ quyền ñể thực hiện Use case này. Không nhất thiết mọi Use
case ñều phải có ñiều kiện bắt ñầu.
•
X2. Luồng chính: mô tả những bước chính sẽ xẩy ra khi thực hiện Use
case.
•
X3. Các luồng phụ( luồng con).

1.4.2 E-2: Không ñủ tiền trong tài khoản
//////////////////////////////////////////////
Các mối quan hệ
1. Quan hệ giữa Use case và Actor:
Thường gọi là quan hệ tương tác vì nó thể hiện sự tương tác giữa một actor
và một Use case. Mối quan hệ này có thể là hai chiều (từ Actor ñến Use case
và ngược lại), nó cũng có thể chỉ là một chiều, lúc ñó chiều của quan hệ sẽ
chỉ ra rằng ai là người khởi tạo liên lạc (communicate). Quan hệ này thể hiện
bởi một ñường thẳng nối giữa actor và Use case (quan hệ hai chiều) hay một
mũi tên (quan hệ một chiều).
2. Quan hệ giữa Use case với Use case:
Có ba loại quan hệ sau: uses, extends và generalization.
Quan hệ Uses (sử dụng):
Có thể có nhiều Use case có chung một số chức năng nhỏ. Khi ñó nên tách
chức năng ñó thành một Use case riêng hơn là mô tả nó trong tất cả các Use
case mà cần chức năng ñó. Khi ñó có một quan hệ Uses giữa các Use case
trên và Use case vừa tạo ra.
Ví dụ: trong hệ thống quản lý thư viện, mọi Use case ñều bắt ñầu bằng việc
kiểm tra ñịnh danh của người dùng. Chức năng này có thể mô tả trong một
Use case tên là “ðăng nhập hệ thống”, sau ñó các Use case khác sẽ sử dụng
Use case này khi cần thiết.
Quan hệ Extends (mở rộng):
Không giống như quan hệ Uses trong ñó nói rằng khi một Use case A sử
dụng Use case B có nghĩa là trong khi thực hiện Use case A phải thực hiện
Use case B, quan hệ Extends dùng ñể chỉ:
•
Các hành vi tùy chọn: có thể thực hiện hoặc không.
Ví dụ: khi gửi email có thể thực hiện các thao tác bảo mật nội dung
thư hoặc là không. Ta có Use case “Bảo mật” có quan hệ extends với
Use case “Gửi email”.

ñó
•
Một biểu ñồ thể hiện tất cả các Use case ñược cài ñặt trong một giai
ñoạn phát triển.
•
Một biểu ñồ thể hiện một Use case và tất cả các mối quan hệ của nó.
Tuy nhiên nên cân nhắc ñể các biểu ñồ thể hiện ñủ các thông tin cần thiết,
nếu quá nhiều biểu ñồ sẽ gây ra sự nhầm lẫn và mất ñi lợi ích của việc ñơn
giản hóa. Tập hợp các Use case giúp cho khách hàng dễ dàng xem xét ở mức
tổng quát hệ thống mà ta sẽ xây dựng. Một hệ thống thông thường có từ 20
ñến 50 Use case.
3. Kí hiệu
Một biểu ñồ Use case bao gồm một tập các Use case và actor. Giữa Use case
và actor có một ñường nối nếu như actor ñó khởi ñầu một Use case.
Biểu Use case có thể lồng nhau, có nghĩa là một Use case trong một biểu ñồ
Use case có thể ñược phân nhỏ ra thành những Use case khác, nằm trong
một biểu ñồ Use case khác.
Ví dụ:
Hệ thống quản lý dự án và nguồn nhân lực. Có bốn Actor là Resource
Manager (Người quản lý nguồn nhân lực), Project Manager (Người quản lý
dự án), System Administrator (Người quản trị hệ thống) và Backup
System(hệ thống sao lưu dữ liệu).
Hình 1-1 là biểu ñồ use case ở mức tổng quát, cung cấp một bức tranh toàn
cảnh về các actor và use case của hệ thống. Hình 1-2 chi tiết hóa use case
"Quản lý nguồn nhân lực" bằng cách chỉ ra các use case mà actor Resource
Manager mong muốn ở hệ thống. Resource Manager có thể thêm mới, sửa,
xóa các thông tin về kĩ năng của nhân viên. Một kĩ năng phải ñược tìm ra
trong cơ sở dữ liệu trước khi nó ñược xóa hoặc sửa nên use case FindSkill
ñược tạo ra. Hai use case UpdateSkill và RemoveSkill ñều sử dụng chức
năng của use case FindSkill nên chúng có quan hệ uses với use case này.