Gv: Vũ Thị Dương Email: duongvt01@gmail.com KHOA CÔNG NGHỆ THÔNG TIN Trường Đại học công nghiệp Hà Nội PHÂN TÍCH THIẾT KẾ HƯỚNG ĐỐI TƯỢNG Mô hình hóa trường hợp sử dụng Bài 3 Phân
Trang 1Gv: Vũ Thị Dương
Email: duongvt01@gmail.com
KHOA CÔNG NGHỆ THÔNG TIN
Trường Đại học công nghiệp Hà Nội
PHÂN TÍCH THIẾT KẾ
HƯỚNG ĐỐI TƯỢNG
Mô hình hóa
trường hợp sử dụng
Bài 3
Phân tích thiết kế hướng đối tượng Bài 2 - 3/53
Mục tiêu
Sau khi học xong bài sinh viên nắm được
Khái niệm ca sử dụng
Khái niệm đối tác
Các loại quan hệ trong biểu đồ ca sử dụng
Vẽ được biểu đồ ca sử dụng
Trang 2Phân tích thiết kế hướng đối tượng Bài 4 - 4/31
Giới thiệu mô hình hóa UC
Trong pha thu thập yêu cầu và phân tích hệ thống thường phải xây
dựng các biểu đồ cho
Mô hình nghiệp vụ
Mô hình trường hợp sử dụng
Mô hình giao diện người sử dụng
Mô hình trường hợp sử dụng (Use case model) mô tả hệ thống được
sử dụng như thế nào
Use case (UC) hệ thống và tác nhân hệ thống xác định phạm vi hệ thống
UC là những gì bên trong hệ thống
Actor là những gì bên ngoài hệ thống
Biểu đồ UC mô tả tương tác giữa các UC và tác nhân để hình thành chức
năng hệ thống
Phân tích thiết kế hướng đối tượng Bài 4 - 5/31
Các khái niệm mô hình hóa UC
Các khái niệm cơ bản
Tác nhân (Actor)
Trường hợp sử dụng (Use case-UC)
Quan hệ (Relationship)
Biểu đồ hoạt động (Activity Diagram)
Biểu đồ trường hợp sử dụng (Use case Diagram)
Phân tích thiết kế hướng đối tượng Bài 4 - 6/31
Tác nhân
Tác nhân (actor)?
tác nhân (tác nhân ngoài) là một vai trò của một hay
(Mô tả ai, cái gì tương tác với hệ thống)
Đối tác phải là người (vật thể) có trao đổi thông tin với
hệ thống hay hưởng lợi từ hệ thống và phải có sự tự
trị trong quyết định
Bốn loại:
Đối tác chính: con người sử dụng trực tiếp chức năng
chính hệ thống (khách hàng, giáo viên)
Đối tác phụ: Những người làm công tác quản lý, bảo
dưỡng hệ thống
Thiết bị ngoài: Thiết bị được hệ thống điều khiển
Hệ thống khác: là các hệ thống không thuộc hệ thống
đang xây dựng nhưng có tương tác với nó
Đặt tên: là danh từ hay cụm danh từ, theo vai
trò, không theo tên cụ thể vì nó là lớp
Customer
Trang 3Phân tích thiết kế hướng đối tượng Bài 4 - 7/31
Tìm kiếm tác nhân như thế nào?
Hãy trả lời các câu hỏi sau để tìm ra tác nhân hệ thống
Ai sẽ sử dụng chức năng chính của hệ thống?
Ai giúp hệ thống làm việc hàng ngày?
Ai quản trị, bảo dưỡng để hệ thống làm việc liên tục?
Hệ thống quản lý thiết bị phần cứng nào?
Hệ thống đang xây dựng tương tác với hệ thống khác nào?
Ai hay cái gì quan tâm đến kết quả hệ thống cho lại?
Thí dụ ứng dụng UML
Một trường đại học thực hiện tin học hóa hệ thống đăng ký học và dạy học theo hệ thống tín
chỉ
Hệ thống cho phép sinh viên có quyền lựa chọn môn học cho mỗi học kỳ
Trước khi bước vào học kỳ mới, Giáo vụ gửi danh sách các môn học trong học kỳ và thời khóa
biểu dự kiến chocác thầy giáo Thầy giáo đăng ký các môn mà mình có thể giảng trong học kỳ
Căn cứ vào ds thầy + môn ở trên và vào kế hoạch học tập chung của trường, cán bộ quản
sinh lập 1 danh sách các môn học có trong học kỳ kèm với các thông tin cần thiết như: thầy
giáo, số giờ, các môn phải học trước … để sinh viên có căn cứ để lựa chọn
Tiếp đó mỗi sinh viên đăng ký các môn mà mình học rồi gửi cho phòng quản sinh Thông
thường mỗi sinh viên được chọn từ 6-8 môn/học kỳ và thực hiện đăng ký trong vòng 1 tuần
Khi hết hạn đăng ký, cbqs dựa vào thông tin nhận được tổ chức các lớp giảng cho từng môn
Mỗi lớp giảng không dưới 10 người và k quá 30 người Do điều kiện hạn chế này mà có thể
xảy ra trường hợp lớp giảng quá vắng không tổ chức được hoặc lớp giảng quá đông mà tổ
chức thêm 1 lớp nữa thì lại thiếu người Trong trường hợp đó hệ thống sẽ thông báo lại với
sinh viên để học đăng ký lại
Khi đã hoàn tất việc xếp lớp phòng quản sinh thông báo cho từng thầy lịch day và cho sinh
viên lịch hoc của mình Mặt khác, ds các môn học cho các môn học cho từng sinh viên cũng
được gửi cho phòng tài vụ để tính học phí
Nhà trường muốn xây dựng một hệ thống thông tin trên máy tính để trợ giúp quá trình đăng
ký nói trên Trong đó các thầy cô giáo có thể truy nhập trực tiếp để đăng ký môn dạy hay
xem danh sách sinh viên lớp mình dạy, còn sinh viên thì được dành một số ngày cho phép để
truy cập hệ thống để sửa (thêm hay bỏ) các môn học mà mình sẽ đăng ký
Phân tích thiết kế hướng đối tượng Bài 4 - 9/31
Ca sử dụng - Use case
Use case là một biểu diễn của một tập hợp
các chuỗi hành động mà hệ thống thực
hiện nhằm cung cấp 1 kết quả cụ thể cho 1
đối tác
Tập hợp các ca sử dụng là mô tả toàn bộ
hệ thống cần xây dựng
Một ca sử dụng tương ứng với 1 chức
năng của hệ thống dưới góc nhìn của
người sử dụng
Một ca sử dụng chỉ ra làm thế nào 1 mục tiêu cuả
người sử dụng được thỏa mãn bởi hệ thống
Purchase Ticket
Trang 4Phân tích thiết kế hướng đối tượng Bài 4 - 10/31
Ca sử dụng
Lưu ý:
Ca sử dụng phải liên kết với một hay một số đối tác trong đó có 1
đối tác chính (Đối tác kích hoạt ca sử dụng một cách trực tiếp hay
gián tiếp)
Một ca sử dụng phải dẫn tới 1 kết quả cụ thể- nghĩa là 1 kết quả
nhận biết được trọn vẹn va đo đếm được
Cần phân biệt các mục tiêu của người sử dụng và các tương tác
của họ với hệ thống
Mục tiêu là cái mà người sử dụng mong đợi
Tương tác là kỹ thuật cho phép đáp ứng mục tiêu
Ví dụ: Mục tiêu: có được một văn bản trình bày đẹp
Tương tác: Chọn định dạng trang, font, lề…
Phân tích thiết kế hướng đối tượng Bài 4 - 11/31
Ca sử dụng
Ví dụ:1
Giáo vụ cần phải thêm môn học, sửa môn học, loại bỏ môn học
Đó có là 3 ca sử dụng không?
Không, vì Quản lý môn học mới là khái niệm trọn vẹn, kích hoạt
bỏi cùng 1 đối tác (giáo vụ), đề cập tới cùng một thực thể trong hệ
thống là kế hoạch học tập để nhằm hoàn tất nó
Ví dụ 2:
Xây dựng hệ thống ATM cho phép rut tiền:
Đưa thẻ vào
Nhập mã pin – chọn số tiền rut- khẳng định số tiền rút-lấy tiền, lấy
thẻ- lấy biên lại rút
Tìm các ca sử dụng?
Phân tích thiết kế hướng đối tượng Bài 4 - 12/31
Xây dựng UC để làm gì?
Hình thành và mô tả yêu cầu chức năng hệ thống
Là kết quả thỏa thuận giữa khách hàng và người phát triển hệ
thống phần mềm
Cho phép mô tả rõ ràng và nhất quán cái hệ thống sẽ làm
Mô hình có khả năng được sử dụng xuyên suốt quá trình phát triển
Cung cấp cơ sở để kiểm tra, thử nghiệm hệ thống
Cho khả năng dễ thay đổi hay mở rộng yêu cầu hệ thống
Phân tích
Thu thập,
lọc và đánh
giá UC
Thiết kế, cài đặt
Cài đặt UC
Kiểm tra
Kiểm tra xem UC thỏa mãn?
UC gắn các bước trong tiến
trình phát triển
UC và tiến trình phát triển
Trang 5Phân tích thiết kế hướng đối tượng Bài 4 - 13/31
Xây dựng UC để làm gì?
Ai quan tâm đến UC?
Người
sử dụng Phân tích viên
Thử nghiệm
Kiến trúc sư Lập trình viên
Use case
Diễn đạt Hiểu
Kiểm tra Thiết kế Cài đặt
Phân tích thiết kế hướng đối tượng Bài 4 - 14/31
Tìm kiếm UC như thế nào?
Với mỗi tác nhân đã tìm ra, hãy trả lời các câu hỏi sau để tìm ra
các Use case hệ thống
Tác nhân yêu cầu hệ thống thực hiện chức năng nào?
Tác nhân cần đọc, tạo lập, bãi bỏ, lưu trữ, sửa đổi các thông tin nào
trong hệ thống?
Tác nhân cần thông báo cho hệ thống sự kiện xảy ra trong nó?
Hệ thống cần thông báo cái gì đó cho tác nhân?
Hệ thống cần vào/ra nào? Vào/ra đi đến đâu hay từ đâu?
Đặt tên UC hệ thống
Động từ + cụm danh từ diễn tả ý nghĩa của UC
Đặt theo khái niệm nghiệp vụ của tổ chức
Không đặt tên sử dụng từ kỹ thuật, chuyên môn
Nên sử dụng các động từ, cụm từ ngắn gọn
Tùy theo tầm cỡ dự án mà mỗi hệ thống có từ 20-70 UC
Phân tích thiết kế hướng đối tượng Bài 4 - 15/31
Đã tìm đầy đủ UC cho hệ thống?
Các câu hỏi sau giúp xác định đã tìm đầy đủ UC?
Mỗi yêu cầu chức năng ở trong ít nhất một UC?
Nếu yêu cầu chức năng không ở trong UC nào thì nó sẽ không
được cài đặt sau này
Đã khảo sát mọi tác nhân tương tác với hệ thống?
Tác nhân cung cấp cho hệ thống thông tin nào?
Tác nhân nhận thông tin nào từ hệ thống?
Đã nhận biết mọi hệ thống bên ngoài tương tác với hệ
thống đang xây dựng?
Thông tin nào hệ thống bên ngoài nhận và gửi cho hệ
thống đang xây dựng?
Trang 6Phân tích thiết kế hướng đối tượng Bài 4 - 16/31
Luồng sự kiện trong UC
Tài liệu luồng sự kiện (flow of events)- đặc tả UC- mô tả hành vi của
từng ca sử dụng
Mô tả luồng logíc đi qua UC
mô tả người sử dụng làm gì, hệ thống làm gì
Trong một UC có nhiều luồng sự kiện: luồng chính, luồng phụ
Mỗi luồng đó gọi là 1 kịch bản (scenario)
Các loại kịch bản
Kịch bản chính
Kịch bản phụ
Kịch bản ngoại lệ và sai hỏng
Kịch bản 3
UC
Kịch bản 1 Kịch bản 2
Phân tích thiết kế hướng đối tượng Bài 4 - 17/31
Làm tài liệu UC (đặc tả)
Mô tả UC (chỉ nói rõ what, không how)
Đặc tả chỉ rõ ca sử dụng trao đổi thông tin với các đối tác
nào, nó bắt đầu và kết thúc ra sao, nó có thể diễn ra theo
các kịch bản nào
Thông thường bao gồm các thông tin sau
Phân tích thiết kế hướng đối tượng Bài 4 - 18/31
Tài liệu đặc tả UC
Mô tả tóm tắt (bắt buộc): tên, mục đích tóm lược, đối
tác, ngày lập, người lập, version
Mô tả các kịch bản (bắt buộc):
Tiền điều kiện (pre-condition):
Điều kiện cần thực hiện trước khi UC khởi động ;
Không phải UC nào cũng có tiền điều kiện
Luồng sự kiện chính và luồng sự kiện rẽ nhánh
Hậu điều kiện (post-condition)
Các yêu cầu về giao diện: (tùy ý) : thêm các ràng buộc về giao
diện người máy
Các ràng buộc phi chức năng (tùy ý): Tấn suất khối lượng, …
Trang 7Phân tích thiết kế hướng đối tượng Bài 4 - 19/31
Tài liệu luồng sự kiện
Tài liệu luồng sự kiện bao gồm
Mô tả vắn tắt UC
Tiền điều kiện (pre-condition)
Luồng sự kiện chính và luồng sự kiện rẽ nhánh
chi tiết về UC được mô tả trong hai luồng sự kiện này
mô tả cái gì sẽ xảy ra để thực hiện chức năng của UC
Nội dung tài liệu
UC khởi động như thế nào?
Các đường đi xuyên qua các UC
Luồng chính thông qua UC
Luồng rẽ nhánh thông qua UC
Các luồng lỗi
UC kết thúc thế nào
Hậu điều kiện (post-condition)
Là điều kiện được thực hiện ngay sau khi kết thúc UC
Phân tích thiết kế hướng đối tượng Bài 4 - 20/31
Thí dụ tài liệu luồng sự kiện
Làm tài liệu các luồng sự kiện cho UC “Purchase Ticket”
Mô tả tóm tắt:
về các chuyến bay và có thể đặt mua vé và kết thúc
Mô tả các kịch
nhập thành công vào hệ thống
(còn nữa)
Phân tích thiết kế hướng đối tượng Bài 4 - 21/31
Thí dụ tài liệu luồng sự kiện
Làm tài liệu các luồng sự kiện cho UC “Purchase Ticket”
Các bước trong luồng sự kiện chính
1.UC bắt đầu khi customer chọn chức năng xem thông tin chuyến bay
2.Hệ thống hiển thị thành phố đến, đi và thời gian hạ cánh, cất cánh
3.User nhập nơi đến, đi, thời gian ngày tháng khởi hành và trở về
4.Hệ thống hiển thị danh sách chuyến bay và giá vé
A1 Không còn chuyến bay
5.User chọn chuyến bay để đặt trước
6.Hệ thống hiển thị các loại vé để user chọn
7.User chọn giá vé
A2 User chọn giá vé cho thành viên frequent-flyer
8.Hệ thống hiển thị giá vé sẽ bán cho khách hàng
9.User khẳng định giá vé
10 Hệ thống hiển thị loại thẻ tín dụng, số thẻ, thời gian hết hạn
11 User nhập loại thẻ tín dụng, số thẻ, thời gian hết hạn
12 Hệ thống trình mua bằng thẻ
(còn nữa)
Trang 8Phân tích thiết kế hướng đối tượng Bài 4 - 22/31
Thí dụ tài liệu luồng sự kiện
A6 Không thấy tài khoản
A7 Không đủ tiền
E1 Không xâm nhập được hệ thống tín dụng
13.Hệ thống dành chỗ cho user
14.Hệ thống phát sinh và hiển thị mã xác thực cho user
15.User khẳng định đã nhận mã
16.Use case kết thúc
Luồng phụ
A1 Không có chuyến bay
1 Hệ thống hiển thị thông điệp thông báo không có chuyến bay
2 User khẳng định thông điệp
3 Trở lại luồng chính Bước 2
A2 Vé dành cho thành viên frequent-flyer
1 Hệ thống hiển thị số hiệu frequent-flayer
2 User nhập số
3 Hệ thống khẳng định tính hợp lệ của số
A3 Số không hợp lệ
Phân tích thiết kế hướng đối tượng Bài 4 - 23/31
Thí dụ tài liệu luồng sự kiện
Làm tài liệu các luồng sự kiện cho UC “Đăng ký môn học”
Mô tả tóm tắt:
học kỳ nào đó
Tóm lược: Sinh viên chọn một học kỳ rồi sau đó có thể thêm, bỏ,
xem in các môn học, chọn ngày học, chọn lớp và kết thúc
Đối tác: sinh viên
Mô tả các kịch
Điều kiện đầu vào: Ca sử dụng được thực hiện khi sinh viên đăng
nhập thành công vào hệ thống và chỉ hoạt động được khi ca sử dụng
duy trì thông tin môn học đã được thực hiện
(còn nữa)
Phân tích thiết kế hướng đối tượng Bài 4 - 24/31
Thí dụ đặc tả ca sử dụng
Ca sử dụng này bắt đầu khi sinh viên đăng nhập vào hệ thống ĐKMH
và nhập mật khẩu của mình
Hệ thống kiểm tra thấy mật khẩu là đúng đắn (R1) và nhắc sinh viên chọn năm
học, học kỳ này hay sau (R2)
Sinh viên chọn học kỳ, năm học
hệ thống nhắn sinh viên chọn việc trong Thêm, Bỏ, Xem, In, Ra
Nếu thêm được chọn thì kịch bản con: C1- Thêm một mộn học được
thực hiện
Nếu Bỏ được chọn thì kịch bản con: C2- Bỏ một mộn học được thực
hiện
Nếu Xem được chọn thì kịch bản con: C3- xem một lịch biểu được
thực hiện
Nếu in được chọn thì kịch bản con: C4- In một lịch biểu được thực
hiện
Nếu Ra được chọn thì ca sử dụng kết thúc
Trang 9Thí dụ đặc tả ca sử dụng
Các kịch bản con
C1: Thêm một môn học
Hệ thống hiển thị danh sách các môn học có thể được chọn
Sinh viên chọn môn (R3)
Hệ thống hiển thị các lớp và tên thầy giáo dạy + thời gian
Sinh viên chọn lớp
Hệ thống gán lớp học + môn cho sinh viên
Phân tích thiết kế hướng đối tượng Bài 4 - 25/31
Các kịch bản khả dĩ khác
R1: Mật khẩu đưa vào là không hợp lệ, người dùng có thể nhập lại
hoặc kết thúc ca sử dụng
R2: Học kỳ đưa vào là không đúng đắng Người dùng có thể nhập
lại học kỳ hặc kết thúc ca sử dụng
R3: Các lớp giảng không hiển thị được: Thông báo cho người dùng
là chọn lựa đó chưa sẵn sàng ở thời điểm hiện tại, Ca sử dụng bắt
đầu lại
R4: Kết nối không được thiết lập: Thông tin được sao lưu và hệ
thống sẽ kết nối sau
vtduong2010 Phân tích thiết kế hướng đối tượng 26/62
Đặc tả ca sử dụng
Các cách mô tả khác
Mô bả gồm 2 sự kiện chính và các sự kiện ngoại lệ Các sự kiện chi
làm 2 luồng, luồng tương tứng với tác nhân và luồng tương ứng
với hệ thống
Phân tích thiết kế hướng đối tượng Bài 4 - 27/31
Hành động của tác nhân Hành động của hệ thống
Sinh viên: Đưa vào mật
khẩu và tên đăng nhập
2 Hệ thống xác nhận mật khẩu và tên đăng nhập 3.Sinh viên chọn học kỳ và
năm học
4.Hệ thống hiển thị các môn học có thể có trong học kỳ 5.Sinh viên chọn môn học 6 Hệ thống ghi nhận việc
chọn môn học 7.Sinh viên kết thúc việc
chọn môn
Trang 10Đặc tả ca sử dụng
Tóm lại
Xác định các ca sử dụng nhiều có thể
Không đi vào quá chi tiết nhằm giảm độ phức tập
Mô tả ngắn gọn về mỗi ca sử dụng là đủ
Đảm bảo rằng các ca sử dụng bao gồm hết các yêu cầu của hệ
thống
Phân tích thiết kế hướng đối tượng Bài 4 - 28/31
Phân tích thiết kế hướng đối tượng Bài 4 - 29/31
Các quan hệ
Quan hệ kết hợp (Association)
Là loại quan hệ giữa tác nhân và UC
Mũi tên cho biết ai là người khởi xưởng giao tiếp
Customer Purchase Ticket
Customer Purchase Ticket Credit System
Quan hệ gộp giữa 2 Use-case
Dùng để liên kết 2 Use-case: có stereotype là <<include>>
Trong Use-case nguồn có điểm mở rộng mà tại đó bắt
buộc phải chèn Use-case đích vào
Tại điểm mở rộng, diễn tiến của use-case nguồn tạm thời ngừng
lại để chuyển sang diễn tiến của use-case đích
Khi kết thúc use-case đích, diễn tiến của use-case nguồn lại tiếp
tục
Quan hệ ký hiệu là mũi tên đứt nét, đầu mũi tên huướng về UC
đích kèm theo khuôn dập <<include>>
Đăng nhập (UC đích)
<<include>>
Tìm kiếm (UC nguồn)