Phân tích thiết kế hướng đối tượng - Mô hình hóa yêu cầu (biểu đồ ca sử dụng)

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 Nội dung chi tiết 1. Các khái niệm hướng đối tượng 2. Tổng quan về ngôn ngữ mô hình hóa UML 3. Mô hình hóa yêu cầu (biểu đồ ca sử dụng) 4. Mô hình hóa lĩnh vực ứng dụng (biểu đồ lớp lĩnh vực) 5. Mô hình hóa hành vi( biểu đồ tương tác, trạng thái) 6. Biểu đồ kiến trúc vật lý và phát sinh mã trình 7. Mô hình hóa dữ liệu 2010 Phân tích thiết kế hướng đối tượng Bài 1 - 3 Phâ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  Trường hợp sử dụng (Use case-UC)  Tác nhân (Actor)  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)?  hay tác nhân ngoài là một vai trò của một hay nhiều người, vật thể trong sự tương tác với hệ thống (Mô tả ai, cái gì tương tác với hệ thống- đóng vai)  Đố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: theo vai trò, không theo tên cụ thể vì nó là lớp Customer Phâ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? Phân tích thiết kế hướng đối tượng Bài 4 - 8/31 Ví dụ  Các đối tác được phát hiện trong ví dụ đăng ký học Phân tích thiết kế hướng đối tượng Bài 4 - 9/31 Ca sử dụng - Use case.  1994: Ivar Jacobson đề xuất sử dụng UC  Use case?  UC là chức năng mức cao do hệ thống cung cấp, cái nhìn tổng thể về hệ thống  Không cho biết hệ thống làm việc bên trong?  Không phải là thiết kế, cài đặt mà là một phần của vấn đề cần giải quyết  Mô tả bất kỳ cái gì bên trong phạm vi hệ thống Purchase Ticket Phân tích thiết kế hướng đối tượng Bài 4 - 10/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 của người sử dụng được thỏa mãn bởi hệ thống Purchase Ticket Phân tích thiết kế hướng đối tượng Bài 4 - 11/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 - 12/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?  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. Phân tích thiết kế hướng đối tượng Bài 4 - 13/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 Phân tích thiết kế hướng đối tượng Bài 4 - 14/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 - 15/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  Theo khái niệm nghiệp vụ của tổ chức  Không sử dụng từ kỹ thuật, chuyên mô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 - 16/31 Ví dụ: Hệ thống đăng ký học  Sinh viên: dùng hệ thống để đăng ký các môn học ,lấy về thời khóa biểu  Sau khi hoàn tất việc đăng ký môn học cần cung cấp các thông tin tính học phí cho hệ thu học phí  Thầy giáo: dùng hệ thống để chọn giáo trình giảng dạy cho 1 học kỳ, lấy về bản phân công giảng dạy  Cán bộ quản sinh: Sản sinh danh sách môn học quản lý thông tin về kế hoạch học, sinh viên, thầy giáo  Đăng ký môn học (đăng ký, nhận thời khóa biểu);  Chọn môn để giảng ; Yêu cầu bản phân công để giảng, yêu cầu thời khóa biểu (yêu cầu bản phân công)  Duy trì thông tin môn học; Duy trì thông tin sinh viên; Duy trì thông tin thầy; lập bản giói thiệu các môn học (Duy trì khóa học) Phân tích thiết kế hướng đối tượng Bài 4 - 17/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? Phân tích thiết kế hướng đối tượng Bài 4 - 18/31 Luồng sự kiện trong UC  Tài liệu luồng sự kiện (flow of events) mô tả hành vi của UC  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ụ  Kịch bản (Scenario). Một ca sử dụng phải là tập hợp của nhiều chuỗi hành động. Mỗi chuỗi hành độ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 - 19/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 - 20/31 Tài liệu luồng sự kiện  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, . Phân tích thiết kế hướng đối tượng Bài 4 - 21/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 - 22/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:  Tên ca sử dụng: Purchase ticket  Mục đích: Giúp khách hàng mua vé đến địa điểm mong muốn  Tóm lược: Khách hàng chọn nơi đến sau đó có thể xem các thông tin về các chuyến bay và có thể đặt mua vé và kết thúc  Đối tác: Khách hàng  Ngày lập. Người lập. Version.  Mô tả các kịch  Điều kiện đầu vào: Ca sử dụng được thực hiện khi khách hàng đăng nhập thành công vào hệ thống  Kịch bản chính (còn nữa) 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 “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) Phân tích thiết kế hướng đối tượng Bài 4 - 24/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 - 25/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:  Tên ca sử dụng: Đăng ký học  Mục đích: Giúp sinh viên đăng ký môn học mà mình sẽ học trong mộ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 và kết thúc  Đối tác: sinh viên  Ngày lập. Người lập. Version.  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  Kịch bản chính (còn nữa) Phân tích thiết kế hướng đối tượng Bài 4 - 26/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 nhập học kỳ mình muốn, 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 Thí 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 phải học trong học kỳ, sinh viện chọn môn học phù hợp (R3). Hệ thống kết nối sinh viên với môn học (R4). Ca sử dụng bắt đầu lại  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 Phân tích thiết kế hướng đối tượng Bài 4 - 27/31 Đặ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 - 28/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 Đặ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 - 29/31 Phân tích thiết kế hướng đối tượng Bài 4 - 30/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  Quan hệ gộp (Includes)  Quan hệ mở rộng (Extends)  Quan hệ khái quát hóa (Generalization) Customer Purchase Ticket Customer Purchase Ticket Credit System Phân tích thiết kế hướng đối tượng Bài 4 - 31/31 Các quan hệ  Quan hệ kết hợp (Association)  Quan hệ gộp (Includes)  Trước phiên bản UML 1.3 quan hệ > có tên là >  Thể hiện một UC luôn luôn sử dụng chức năng của UC khác  Sử dụng để mô hình hóa để tách một phần chung sử dụng lại giữa hai hay nhiều UC  Quan hệ mở rộng (Extends)  Quan hệ khái quát hóa (Generalization) Check Credit Customer Purchase Ticket > Phân tích thiết kế hướng đối tượng Bài 4 - 32/31 Các quan hệ  Quan hệ kết hợp (Association)  Quan hệ gộp (Includes)  Quan hệ mở rộng (Extends)  Một UC tùy ý mở rộng chức năng do UC khác cung cấp  Mô tả một UC sử dụng chức năng của UC khác if and only if... Nghĩa là nó sát nhật tùy theo điện kiện nào đó hành vi của ca sử dụng kia tại một số điểm đặc biệt trong kịch bản của nó.  (đặt trước có thể trả tiền trước hoặc không)  Quan hệ khái quát hóa (Generalization) Check Credit Customer Change Reservation > Phân tích thiết kế hướng đối tượng Bài 4 - 33/31 Các quan hệ  Quan hệ kết hợp (Association)  Quan hệ gộp (Includes)  Quan hệ mở rộng (Extends)  UC trừu tượng  Quan hệ includes và extends đều có tính chất chung là cùng sử dụng chức năng do UC khác cung cấp  Phần chức năng sử dụng chung có thể để trong UC mới – UC trừu tượng  UC trừu tượng không bị tác nhân kích hoạt giao tiếp  Quan hệ khái quát hóa (Generalization) Check Credit Change Reservation > Purchase Ticket > Abstract UC Concrete UC Phân tích thiết kế hướng đối tượng Bài 4 - 34/31 Các quan hệ  Quan hệ kết hợp (Association)  Quan hệ gộp (Includes)  Quan hệ mở rộng (Extends)  Quan hệ khái quát hóa (Generalization)  Chỉ ra một vài tác nhân hay UC có một số cái chung, giống nhau  Không nhất thiết hình thành quan hệ này cho các tác nhân  Khi một loại tác nhân kích hoạt một hay vài UC mà loại tác tác nhân khác không kích hoạt -> nên hình thành quan hệ khái quát hóa  Khi cả hai loại tác nhân cùng sử dụng các UC -> không cần mô hình hóa quan hệ khái quát hóa Customer Corporate Customer Individual Customer Private Company Govenment Agency Abstract Actor Concrete Actors Phân tích thiết kế hướng đối tượng Bài 4 - 35/31 Biểu đồ Use Case  Mô hình UC được mô tả bởi một hay nhiều biểu đồ UC  Số lượng biểu đồ UC cho một dự án là tùy ý  Không quá nhiều làm rối loạn  Phải đảm bảo đầy đủ để biểu diễn đầy đủ thông tin của hệ thống  Nó là công cụ mạnh giúp thu thập yêu cầu chức năng hệ thống  Nó chỉ ra quan hệ giữa UC và tác nhân và giữa UC với nhau  Sử dụng biểu đồ để làm tài liệu UC, tác nhân và các quan hệ giữa chúng  Lợi ích chính của biểu đồ UC là làm giao tiếp  Khi quan sát các UC, customer biết hệ thống có các chức năng nào  Khi quan sát các tác nhân, customer biết ai giao tiếp với hệ thống  Khi quan sát cả UC và tác nhân, customer biết phạm vi dự án Phân tích thiết kế hướng đối tượng Bài 4 - 36/31 Thí dụ biểu đồ Use Case Phân tích thiết kế hướng đối tượng Bài 4 - 37/31 Thí dụ biểu đồ Use Case Phân tích thiết kế hướng đối tượng Bài 4 - 38/31 Biểu đồ Use Case  Các chú ý khi xây dựng biểu đồ UC  Không nên mô hình hóa quan hệ kết hợp giữa tác nhân với tác nhân -> vì giao tiếp giữa các tác nhân là ở bên ngoài hệ thống  Hãy sử dụng biểu đồ luồng công việc để khảo sát quan hệ giữa các tác nhân  Không hình thành quan hệ Association giữa các UC  Biểu đồ chỉ ra có các UC nào nhưng không chỉ ra trật tự thực hiện chúng  Mỗi UC phải có tác nhân kích hoạt (trừ UC trong quan hệ extends và quan hệ includes)  Nên vẽ mũi tên thể hiện association đi từ tác nhân đến UC  Có thể xem CSDL là lớp ở dưới biểu đồ UC  Có thể nhập tin vào CSDL ở UC này và xâm nhập dữ liệu trong CSDL ở UC khác  Không vẽ association giữa các UC để chỉ ra luồng thông tin Phân tích thiết kế hướng đối tượng Bài 4 - 39/31 Biểu đồ hoạt động  Biểu đồ hoạt động (Activity diagram) do Odell đề xuất cho UML để  mô tả luồng công việc trong tiến trình nghiệp vụ trong mô hình hóa nghiệp vụ  mô tả luồng sự kiện trong mô hình hóa hệ thống  Sử dụng text như trước đây sẽ khó đọc khi logíc phức tạp, có nhiều rẽ nhánh  Biểu đồ hoạt động sử dụng để mô hình hóa  khía cạnh động của hệ thống  các bước trình tự hay tương tranh trong quá trình tính toán Phân tích thiết kế hướng đối tượng Bài 4 - 40/31 Biểu đồ hoạt động Activity với actions “Display available flight” Display fare Enter credit information Ticket [Unconfirmed] Reserve seat Generate confirmation number Ticket [Purchased] [Approved] [ Invalid account, Insufficient funds, Credit system not available ] Phân tích thiết kế hướng đối tượng Bài 4 - 41/31 Biểu đồ hoạt động Reserve seat Generate confirmation number Display fare Enter credit information Generate and E-mail receipt Display confirmation number [ Approved ] [ Invalid account; Insufficient funds; Credit system not available ] Phân tích thiết kế hướng đối tượng Bài 4 - 42/31 Tóm tắt  Bài này đã xem xét các vấn đề sau  Biểu đồ UC là gì?  Quan hệ giữa biểu đồ UC và biểu đồ nghiệp vụ  Các khái niệm của mô hình UC  Cách tìm kiếm UC, tác nhân, quan hệ trong mô hình UC  Cách mô tả luồng sự kiện  văn bản  biểu đồ hoạt động  Các phần tử đồ họa xây dựng biểu đồ UC Bài tập 1  Máy rút tiền ATM có các chức năng sau  Cấp phá tiền cho những ai có thẻ ngân hàng, cho phép rút một số lượng tiền bởi hệ thống thông tin của ngân hàng và những ai có thẻ VISA (cho phép từ xa bởi hệ thống VISA)  Cho xem kiểm tra số tiền tài khoản và bỏ tiền vào tài khoản bằng tiền mặt hoặc ngân phiếu đối với những ai có thẻ ngân hàng  Tất cả các giao tác đều được kiểm tra an toàn  Kiểm tra mã PIN,  Mã PIN nhập sai 3 lần thì thẻ bị nuốt  Cần phải thường xuyên nạp tiền vào mãy, lấy ngân phiếu và các thẻ bị nuốt ra dvduc-2004 Phân tích thiết kế hướng đối tượng Bài 4 - 43/31 Xác định các tác nhân và ca sử dụng, Vẽ biểu đồ ca sử dụng Bài tập 2  Quản lý đào tạo nhân viên: Một công ty muốn mô tả bằng UM: việc đào tạo nhân viên để tin học hóa một số công việc. Việc đào tạo bắt đầu khi người quản lý đào tạo nhận được yêu cầu đào tạo của một số nhân viên. Nhân viên này có thể xem danh mục các chuyên đề đào tạo của các đơn vị đào tạo ký kết với công ty. Yêu cầu của nhân viên được xen xét bởi người quản lý đạo tạo và người quản lý sẽ trả lời là chấp nhận hay từ chối đề nghị đó. Trong trường hợp chấp nhận, người quản lhys sẽ xã định chuyên đề phù hợp trong danh mục các chuyên đề sau đó gửi cho nhân viên nội dung của chuyên đề và danh sách các khóa đào tạo. Nhân viên sẽ chọn khóa đào tạo và người quản lý sẽ đăng ký khóa học với đơn vị đạo tạo cho nhân viên. Trong trường hợp muốn hủy bỏ đăng ký, nhân viên phải thông baosowms cho người quanrlys biết sớm để người quản lý thực hiện hủy bỏ. Cuối khóa khọc nhân viên chuyển phiếu đánh giá kết qur học về cho công ty. Người quản lý sẽ kiểm tra hó đơn thanh toán tiền của đơn vị đào tạo  Xây dựng biểu đồ ca sử dụng dvduc-2004 Phân tích thiết kế hướng đối tượng Bài 4 - 44/31