1 2
Nội dung
PHÂN TÍCH THIẾT KẾ HỆ THỐNG THÔNG TIN
1. Mô hình hóa chức năng 2. Biểu đồ use case 3. Đặc tả use case 4. Biểu đồ activity 5. Case study
Chương 5. Mô hình hóa chức năng sử dụng use case
1.1. Bức tranh PTKTHT
Mô hình hóa chức năng
• Bức tranh PTKTHTTT • Mục đích • Mô hình hóa chức năng
1
3 4
Bức tranh PTKTHT (2)
1.2. Mục đích
• Thiết lập và duy trì sự thoả thuận giữa khách
hàng và người tham gia dự án về việc hệ thống sẽ làm được những gì • Không nói làm như thế nào để đạt được điều đó • Giúp cho những người phát triển hệ thống một sự hiểu biết rõ hơn về những yêu cầu của hệ thống • Đưa ra những giới hạn mà hệ thống sẽ thực hiện và
KHÔNG thực hiện
• Cung cấp các thông tin cơ bản để lập kế hoạch phát
triển dự án
5 6
1.2. Mục đích (2)
1.2. Mục đích (3)
• Cung cấp những cơ sở để ước lượng giá thành và thời
gian để phát triển hệ thống
• Nắm bắt được những yêu cầu và mục đích của người sử
dụng
2
7 8
1.3. Mô hình hóa yêu cầu (3)
1.3. Mô hình hóa chức năng
Các thành phần chính:
• Mô hình hóa các chức năng mà hệ thống sẽ thực thi • Mô hình bao gồm các chức năng định trước của hệ thống • Sử dụng khái niệm Use Case
9 10
11 12
Nội dung
Biểu đồ Use-Case
1. Mô hình hóa yêu cầu 2. Biểu đồ use case 3. Đặc tả use case 4. Biểu đồ activity 5. Case study
3
2.1. Actor và use case
2.1.1. Tác nhân
Actor
• Tác nhân (actor) biểu diễn bất cứ thứ gì tương tác với hệ thống.
Tác nhân biểu diễn các vai trò của một người dùng trong hệ thống Có thể là người, máy móc hoặc hệ thống khác mà chúng ta không phải xây dựng Ví dụ như các thiết bị ngoại vi, thậm chí là database
Có thể chủ động trao đổi thông tin với hệ
• Use case (Chức năng)
thống
Actor
Use Case
Có thể là người đưa thông tin vào hệ thống Có thể là người nhận thông tin.
Không phải là một phần của hệ thống
• Mô tả chức năng mà hệ thống có • Mục đích là để PHÂN TÍCH yêu cầu nghiệp vụ của bài toán chứ không phải để THIẾT KẾ phần mềm
Actors are EXTERNAL.
13 14
Ví dụ về tác nhân
Tìm kiếm tác nhân của hệ thống • Đặt các câu hỏi sau để tìm ra tác nhân:
– Nhóm người nào yêu cầu hệ thống làm việc giúp họ? – Nhóm người nào kích hoạt chức năng của hệ thống? – Nhóm người nào sẽ duy trì và quản trị hệ thống hoạt
động?
– Hệ thống có tương tác với các thiết bị hay phần mềm
ngoại vi nào khác hay không?
• Thông tin về tác nhân:
Tác nhân KHÔNG phải là một phần của hệ thống!!! Tác nhân có thể là: • Người dùng, • Thiết bị phần cứng • Hệ thống phần mềm khác
– Tên tác nhân phải mô tả vai trò của tác nhân đó một
cách rõ ràng
• Tác nhân trao đổi thông tin với hệ thống:
– Tên nên là danh từ – Cần mô tả khái quát khả năng của tác nhân đó
• Gửi thông tin tới hệ thống • Nhận thông tin từ hệ thống
4
15 16
2.1.2. Use case
Tìm use case của hệ thống
• Xem các yêu cầu chức năng để tìm ra các UC • Đối với mỗi tác nhân tìm được, đặt các câu hỏi:
– Các tác nhân yêu cầu những gì từ hệ thống – Các công việc chính mà tác nhân đó muốn HT thực thi? – Tác nhân đó có tạo ra hay thay đổi dữ liệu gì của HT? – Tác nhân đó có phải thông báo gì cho HT? – Tác nhân đó có cần thông tin thông báo gì từ HT?
• Thông tin về use case:
– Tên của UC nên chỉ rõ kết quả của quá trình tương tác với
Mỗi Use-Case biểu diễn cho một chức năng của hệ thống Use-Case là một chuỗi bao gồm nhiều hành động Mỗi Use-Case có thể mở rộng (extext) thành nhiều Use- Case khác Mỗi Use-Case có thể bao hàm (include) nhiều Use-Case khác Use-Case được đặt bên trong phạm vi hệ thống Ký hiệu: hình elip + tên Use-Case (động từ)
tác nhân
– Tên nên là động từ – Mô tả ngắn gọn về mục đích của UC
Mượn sách
Use Case
Nguyễn Thị Thu Trang, SE-FIT-HUT
17 18
Ví dụ: Xác định tác nhân và Use Case
Những điều nên tránh khi tạo UC
• Tạo ra các UC quá nhỏ
• Hành động quá đơn giản mà chỉ cần mô tả bởi vài dòng
• Tạo ra quá nhiều Use case (hàng chục)
• Nhóm các Use case liên quan thành một Use case tổng quát (mức
1)
• Mô tả các Use Case tổng quát ở một sơ đồ khác (mức 2) • Ví dụ: “Quản lý sách” bao gồm “Nhập sách”, “Xuất sách”, “…”
• Sử dụng các Use-case quá cụ thể, hoặc làm việc với dữ
liệu quá cụ thể. Ví dụ: • “Tìm sách theo tên” (nên là “Tìm sách”) • “Nhập Pin vào máy ATM” (nên là “Nhập PIN”) • “Thêm sách” (nên là “Quản lý sách” bao gồm “Thêm sách”)
5
19 20
Ví dụ: Xác định tác nhân và Use Case
Phân loại tác nhân
21 22
Xác định Use Case
Xác định Use Case
6
23 24
2.2. Mối liên hệ (relationship)
• Mối liên hệ giữa các actor với nhau
2.2.1. Mối liên hệ giữa các actor với nhau • Khái quát hóa (Generalization) • Tác nhân con kế thừa tính chất và
hành vi của tác nhân cha
• Khái quát hóa (Generalization)
• Mối liên hệ giữa actor và use case
• Giao tiếp
• Mối liên hệ giữa các use case với nhau
• Generalization: Khái quát hóa • Include: Bao hàm • Extend: Mở rộng
25 26
2.2.2. Mối liên hệ giữa actor với use case (2)
2.2.2. Mối liên hệ giữa actor với use case
Chiều của quan hệ chính là chiều của tín hiệu gửi đi • Từ tác nhân tới Use Case
• Thiết lập quan hệ giữa Tác nhân và Use Case • Chúng tương tác bằng cách gửi các tín hiệu cho nhau
• Một use case mô hình hóa một hội thoại giữa các tác
nhân và hệ thống
• Một use case được bắt đầu bởi một tác nhân để gọi một
• Kích hoạt Use case • Hỏi thông tin nào đó trong hệ thống • Thay đổi thông tin nào đó trong hệ thống • Thông báo cho UC về một sự kiện đặt biệt nào đó xảy ra với hệ thống
chức năng nào đó trong hệ thống.
• Từ Use Case tới tác nhân:
• Nếu như có một điều gì đó xảy ra với HT và tác nhân đó cần được biết
sự kiện đó
• UC đôi khi cần hỏi thông tin nào đó từ một tác nhân trước khi UC đó
đưa ra một quyết định
Use Case
Association
Actor
7
27 28
Quan hệ generalization
2.2.3. Mối liên hệ giữa các use case với nhau
• Được sử dụng để chỉ ra một vài tính chất chung của một nhóm tác nhân hoặc UC
• Sử dụng khái niệm kế thừa
• Generalization
• <
• Mô tả hành vi chung (chia sẻ) trong
• sometime use
UC cha
• Mô tả hành vi riêng trong (các) UC
con
29 30
<
<
trong UC Base
• Sử dụng stereotype là <
(Khi thực hiện thực hiện UC Base thì thực hiện UC extension ở một số tình huống nào đó, chứ không bắt buộc)
• Chèn vào lớp cơ sở tại điểm phát sinh (extension point)
• Sử dụng stereotype là <
8
32 34
35 37
Nội dung
Biểu đồ Use Case
1. Mô hình hóa yêu cầu 2. Biểu đồ use case 3. Đặc tả use case 4. Biểu đồ activity 5. Case study
• Biểu đồ use case (use case diagram) • Là tập hợp các actor và các use case lại; bổ liên sung các mối (association) quan giữa chúng và lập thành biểu đồ use case
Đặc tả use case
Đặc tả Use Case • Kết thúc quá trình mô hình hóa yêu cầu phải đặc tả lại tất
cả Use-case của hệ thống
• Mỗi Use-Case cần những thông tin
• Tên
• Đặc tả use case là gì? • Mẫu đặc tả use case • Ví dụ minh họa từ các case study
• Tên của Use case • Mô tả ngắn gọn:
• Mô tả về vai trò và mục đích của use case, tránh kiểu diễn xuôi tên Use Case
• Ràng buộc (điều kiện)
• Tiền điều kiện • Hậu điều kiện
• Luồng sự kiện (kịch bản):
• Mô tả bằng lời những gì mà hệ thống sẽ làm thể hiện trên use-case, luồng sự
kiện chính, luồng sự kiện con, luồng sự kiện ngoại lệ.
• Biểu đồ hoạt động
• Minh họa luồng sự kiện bằng mô hình
• Các yêu cầu đặc biệt…
9
38 39
Luồng sự kiện của use-case
Luồng sự kiện của use-case (2)
• Trả lời được quá trình từ khi bắt đầu đến khi kết thúc của
• Luồng chính (Basic flow)
• Luồng lý tưởng mà Use case thường hoạt động
một use-case • Chỉ mô tả chi tiết các sự kiện thuộc use-case đó • Nếu có sự liên hệ với Use Case khác, nên có sự phân tích và tham
khảo ngắn gọn
• Mô tả dữ liệu được trao đổi giữa tác nhân và use-case đó
• Luồng phát sinh (Alternative flow) • Sử dụng nhiều lần trong luồng chính • Các trường hợp đặc biệt (vd nhấn mạnh một tính năng của HT) • Gây ra lỗi, cách xử lý lỗi trong tình huống đó
• Chú ý
• Chỉ cần luồng chính là có thể hiểu được tác vụ chính mà Use Case
đó sẽ thực thi
• Cấu trúc: Ai làm gì, khi nào, với dữ liệu gì, [vì mục đích gì] • Cần phân tích rõ hệ thống cần phải làm gì để đáp ứng được yêu cầu của tác nhân đó. Không được mặc định cho rằng hệ thống tự biết làm điều đó
• Tránh mô tả chức năng hoặc GUI (Graphic User Interface) • Tránh mô tả chung chung, hoặc lúc nào cũng đúng
• Phải có lời gọi luồng phát sinh từ luồng chính • Tránh viết luồng phát sinh dài hơn luồng chính • Tránh viết luồng phát sinh quá dài • Tránh tách quá nhiều luồng phát sinh
40 41
Luồng sự kiện của use-case (3)
Ví dụ
• Kịch bản là một thể hiện của UC đó
• Một Use Case có nhiều kịch bản tùy thuộc vào ngữ
cảnh cụ thể mà nó phát sinh
42 43
UC Rút tiền 1. Gọi UC “Xác thực KH” 2. Hiển thị menu. 3. KH chọn chức năng “Rút tiền”
4.
...
UC Xác thực KH 1. Đưa thẻ vào máy 2. Kiểm tra thẻ 3. KH nhập PIN 4. Hệ thống kiểm tra PIN E1: Thẻ sai E2: Sai PIN E3: ...
10
ID:
Mức quan trọng:
Tên Use-case:
Loại Use-case:
Tác nhân chính:
Người liên quan và công việc quan tâm:
Mô tả tóm tắt:
Ví dụ đặc tả UC Rút tiền mặt
Ràng buộc:
Loại:
• Luồng phát sinh:
• Luồng chính:
• Luồng phát sinh “Rút tiền xu”
1.Gọi UC “Xác thực KH” để
Các mối quan hệ: 1. Kết hợp 2. Bao hàm 3. Mở rộng 4.
Tổng quát hóa
ktra KH
•
2.Hiển thị menu 3.KH chọn chức năng “Rút
tiền”
nếu <điều kiện> đúng thì thực hiện S-1: thực hiện công việc /*TH1*/ nếu <điều kiện> đúng thì thực hiện S-2: thực hiện công việc /*TH2*/
Các dòng sự kiện tổng quát chính: /*mô tả các dòng sự kiện chính*/ 1. Hoạt động 1: 2. Hoạt động 2: /*hoạt động cho nhiều trường hợp xử lý*/ 3. Hoạt động 3: …. n. Hoạt động n:
4.Nhập số tiền cần rút 5.HT gửi giao dịch tới ngân
hàng chờ chấp thuận 6.Máy ATM xuất tiền (tiền
phát sinh tại bước 6 trong luồng chính (Có thể có luồng phát sinh khác như Hết tiền…) • Luồng phát sinh Rút tiền xu: (Phần này có thể viết chung với UC Rút tiền, hoặc có thể viết riêng như một UC nếu nó tương đối phức tạp) 1. Nếu KH chọn thể loại tiền xu 2. KH nhập số lượng xu 3. Hệ thống tính ra tổng số tiền
giấy)
1. Hoạt động 1 2…… 3. Hoạt động n
cần rút
7.Trả lại thẻ 8.In biên lai
Các dòng sự kiện chi tiết chính: /*mô tả các hoạt động chi tiết cho các trường hợp trên*/ S-1: Thực hiện công việc A /*mô tả cho trường hợp 1 TH1*/ S-2: Thực hiện công việc B /*mô tả cho trường hợp 2 TH2*/
1. Hoạt động 1 2…… 3. Hoạt động n
4. KH chấp nhận 5. Khay tiền xu mở để xuất tiền 6. UC Rút tiền tiếp tục thực hiện
Các dòng sự kiện ngoại lệ: /*mô tả các dòng sự kiện xử lý ngoại lệ cho các dòng sự kiện chính hoặc các dòng sự kiện con*/ 1.a. Hoạt động ngoại lệ cho hoạt động 1 3.a. Hoạt động ngoại lệ cho hoạt động 3 S-1 2.a. Hoạt động ngoại lệ cho hoạt động 2 trong S-1
44 45
46 47
Tên Use-case: Đặng nhập
ID: 1
Mức quan trọng: cao
Tác nhân chính: người dùng
Loại Use-case: chi tiết cần thiết
Người liên quan và công việc quan tâm: người dùng muốn đăng nhập vào ht để thực hiện một thao tác trên HT
Biểu đồ hoạt động
Mô tả tóm tắt: Use-Case này mô tả xử lý đăng nhập vào HT của một người dùng
Ràng buộc: Người dùng chọn chức năng đăng nhập từ trang chủ của HT Loại: Bên ngoài
• Biểu đồ hoạt động trong mô hình use case được sử dụng
Các mối quan hệ: 1. Kết hợp: Người dùng 2. Bao hàm: không có 3. Mở rộng: không có 4.
Tổng quát hóa: không có
để lưu lại các hoạt động và các hành động được thực hiện trong một use case Minh họa luồng sự kiện • Biểu đồ luồng (flow chart): Chỉ ra luồng điều khiển từ hoạt động
hoặc hành động này đến hoạt động/hành động khác.
nếu người dùng nhập thông tin đăng nhập thực hiện S-1: xử lý đăng nhập nếu người dùng chọn quên mật khẩu thực hiện S-2: xử lý quên mật khẩu
Các dòng sự kiện chính: /*mô tả các dòng sự kiện chính*/ 1. Hệ thống hiển thị trên màn hình đăng nhập 2. Người dùng chọn chức năng: /*hoạt động cho nhiều trường hợp xử lý*/ 3. hệ thống hiển thị màn hình thông báo kết quả cho giao tác liên quan đến người dùng
This use case starts when the Registrar requests that the system close registration.
Activity 2
1. kiểm tra thông tin tài khoản 2. Hiển thị màn hình thông báo đăng nhập thành công
1. The system checks to see if registration is in progress. If it is, then a message is displayed to the Registrar and the use case terminates. The Close Registration processing cannot be performed if registration is in progress.
Activity 1
Activity 3
Các dòng sự kiện con: /*mô tả các hoạt động chi tiết cho các trường hợp trên*/ S-1: Xử lý đăng nhập S-2: Xử lý quên mật khẩu:
1. HT hiển thị màn hình để người dùng nhập Email 2. Người dùng nhập email và chọn nút chức năng lấy lại mật khẩu 3. HT kiểm tra email hợp lệ 4. Gởi liên kết để tạo lại mật khẩu mới 5. Gởi email thông báo đã tạo mới mật khẩu
2. For each course offering, the system checks if a professor has signed up to teach the course offering and at least three students have registered. If so, the system commits the course offering for each schedule that contains it.
Hệ thống hiển thị lại màn hình đăng nhập để khách hàng nhập thông tin. Quy lại bước 1 trong luồng sự kiện S-1
Các dòng sự kiện ngoại lệ: /*mô tả các dòng sự kiện xử lý ngoại lệ cho các dòng sự kiện chính hoặc các dòng sự kiện con*/ S-1 2a. Xử lý nhập mật khẩu sai 1. 2. S-2.3a. Xử lý nhập email không hợp lệ 1. Hiển thị thông báo lỗi và yêu cầu nhập lại email 2. Quay lại bước 3 trong S-2
11
Flow of Events
Biểu đồ hoạt động
Biểu đồ hoạt động (2)
• Hoạt động
• Đặc tả cho hành vi được diễn tả như một luồng thực thi thông qua sự sắp xếp thứ tự của các đơn vị nhỏ hơn.
• Các đơn vị nhỏ hơn bao gồm các hoạt động lồng nhau và
các hành động riêng lẻ cơ bản
• Có thể chứa các ràng buộc biểu thức logic khi hoạt động
được gọi hoặc kết thúc
49
48
Biểu đồ hoạt động
Biểu đồ hoạt động
12
50 51
Biểu đồ hoạt động
• Được sử dụng để minh hoạ luồng sự kiện
53 54
13
55 56
Case study – Course Registration
Mô hình hóa nghiệp vụ
• Xác định được phạm vi, hệ thống, trực quan hóa hệ thống phức tạp
• Nắm bắt các yêu cầu nghiệp vụ, biểu
diễn các quy trình nghiệp vụ
• Actor? • Use case? • Relationship?
Hệ thống
• Biểu diễn sự thay đổi, cải tiến quy trình đã tồn tại, hoặc xây dựng quy trình mới, hoặc nâng cấp môi trường,…
Mô hình hóa
60 61
Các bước mô hình hóa nghiệp vụ
Các bước mô hình hóa nghiệp vụ
• Đánh giá hiện trạng tổ chức
• Mục đích:
• Đánh giá hiện trạng tổ chức • Nắm bắt thông tin về tổ chức:
• Đánh giá và nắm bắt thông tin về tổ chức. • Xác định các đối tượng liên quan (stakerholder) và khách hàng của hệ
• Cơ cấu tổ chức, phân cấp và các vai trò trong hệ thống. • Mô tả ngắn gọn các thành phần và mối quan hệ này thông qua
thống.
sơ đồ tổ chức
• Định nghĩa phạm vị của việc mô hình hóa nghiệp vụ. • Xác định những tiềm năng cải tiến và các mục tiêu mới của tổ chức. • Mô tả những mục tiêu chính của tổ chức.
Tổ văn phòng
Tổ bảo vệ
Tổ tin học
Tổ thu ngân
Tổ mặt hàng
62 63
Sơ đồ tổ chức của siêu thị
14
Các bước mô hình hóa nghiệp vụ
Các bước mô hình hóa nghiệp vụ • Đánh giá hiện trạng tổ chức
• Đánh giá hiện trạng tổ chức
64 65
Mô tả
• Nắm bắt và phân tích các yêu tố sau:
Tổ văn phòng
Gồm 1 Giám Đốc và 2 phó Giám Đốc có nhiệm vụ điều phối toàn bộ hoạt động của siêu thị. Tổ phải nắm được tình hình mua bán, doanh thu của siêu thị để báo cáo lại cho ban GĐ. Việc báo cáo thực hiện hàng tháng, hàng quý hoặc cũng có khi báo cáo đột xuất theo yêu cầu
Tổ bảo vệ
Kiểm tra và bảo vệ an ninh của siêu thị, ghi nhận hàng hóa đổi lại của khách hàng
• Hỗ trợ ra quyết định • Ưu thế cạnh tranh • Hoàn vốn đầu tư, chỉ ra lợi kinh tế rõ ràng • Giảm chi phí • Hỗ trợ cho việc quản lý nghiệp vụ. • Khả năng thực hiện công việc phải nhanh hơn và tốt hơn.
Tổ thu ngân Thực hiện việc bán hàng và lập hóa đơn cho khách hàng, đồng thời ghi nhận lại số hàng hóa bán được của mỗi loại để báo cáo cho tổ quản lý sau mỗi ca làm việc
Tổ mặt hàng Kiểm tra chất lượng hàng hóa và nắm tình trạng hàng hóa của siêu thị, đảm bảo hàng hóa luôn ở trong tình trạng tốt nhất khi đến tay khách hàng. Khi phát hiện hàng hư hỏng phải kịp thời báo cáo cho tổ văn phòng để có biện pháp giải quyết và điều phối hàng
Tổ tin học
Thực hiện việc thu thập, kết xuất các báo cáo cần thiết phục vụ cho tổ văn phòng
Các bước mô hình hóa nghiệp vụ
Các bước mô hình hóa nghiệp vụ • Đánh giá hiện trạng tổ chức
• Đánh giá hiện trạng tổ chức
• Ví dụ: xác định các đối tượng liên quan và khách hàng trong hệ
thống siêu thị
• Xác định các đối tượng liên quan và khách hàng
• Đối tượng liên quanL là những người chịu ảnh hưởng trực tiếp từ các
66 67
Tên
Đại diện
Vai trò
tác động của hệ thống.
• Khách hàng: người dùng hệ thống, có thể những người liên quan
Người quản lý
Giám đốc, người quản lý siêu thị
• Mô tả nhu cầu của đối tượng liên quan
Theo dõi tiến trình phát triển của dự án và theo dõi tình hình hoạt động của siêu thị
Chịu trách nhiệm trong khâu bán hàng ở siêu thị, duy trì hoạt động của siêu thị
Nhân viên bán hàng Tên
Người nhập thông tin trong hệ thống Mô tả
Đối tượng liên quan
Người quản lý
Người quản lý
Đáp ứng các nhu cầu quản lý siêu thị như hàng hóa, khách hàng, doanh số.
Nhân viên bán hàng
Nhân viên bán hàng
Đảm bảo rằng hệ thống sẽ đáp ứng các nhu cầu của công việc bán hàng
Khách hàng Đáp ứng nhu cầu tra cứu thông tin về
hàng hóa có trong siêu thị
15
Các bước mô hình hóa nghiệp vụ
Các bước mô hình hóa nghiệp vụ
• Đánh giá hiện trạng tổ chức
• Đánh giá hiện trạng tổ chức
• Giới hạn hệ thống phát triển
• Giới hạn hệ thống phát triển
• Xác định ranh giới phát triển hệ thống bằng cách
• Chỉ ra những thực thể nằm ngoài hệ thống • Chỉ ra những thực thể bên trong tổ chức như nằm ngoài hệ thống
68 69
Các bước mô hình hóa nghiệp vụ
Các bước mô hình hóa nghiệp vụ
• Đánh giá hiện trạng tổ chức
• Xác định thuật ngữ nghiệp vụ
• Ví dụ: xác định và trình bày các vấn đề của hệ thống
16
70 71
Mô hình hóa nghiệp vụ với mô hình Use case
Mô hình hóa nghiệp vụ với mô hình Use case
• Cách thực hiện
• Xác định ranh giới của nghiệp vụ • Xác định tác nhân (Actor) • Xác định nghiệp vụ/chức năng (Use-case) • Xác định mối quan hệ giữa Actor với Actor, giữa Actor với Use-
case, giữa Use-case với Use-case
• Mô hình hóa nghiệp vụ với mô hình Use-case
72 73
Mô hình hóa nghiệp vụ với mô hình Use case
17
74
