• Trong chương này chúng ta sẽ thảo luận về cách Thu thập thông tin bằng cách sử dụng các kỹ thuật được tổ chức và trình bày dưới dạng các hoạt động diagrams và các use case • Một mô hình quy trình có thể được sử dụng để ghi lại hệ thống hiện tại hoặc một hệ thống tương lai • Ngày nay đều sử dụng sơ đồ hoạt động và sử dụng các trường hợp để lập tài liệu và sắp xếp các yêu cầu thu được trong quá trình phân tích giai đoạn. Được sử dụng cho bất kỳ loại hoạt động mô hình hóa quy trình nào.
Mục lục I Giới thiệu khái quát • • • Trong chương thảo luận cách Thu thập thông tin cách sử dụng kỹ thuật tổ chức trình bày dạng hoạt động diagrams use- case Một mơ hình quy trình sử dụng để ghi lại hệ thống hệ thống tương lai Ngày sử dụng sơ đồ hoạt động sử dụng trường hợp để lập tài liệu xếp yêu cầu thu trình phân tích giai đoạn Được sử dụng cho loại hoạt động mơ hình hóa quy trình • • • • • Định nghĩa Usecase: Usecase chuỗi hành động mà hệ thống thực mang lại kết quan sát actor Có thể hiểu UseCase chức hệ thống, mang ý nghĩa định người dùng Use case cách thức để biểu diễn, hệ thống kinh doanh tương tác với mơi trường Mơ hình use cases thường coi nhìn bên ngồi chức doanh nghiệp quy trình hiển thị cách người dùng xem quy trình & ghi lại hệ thống hệ thống phát triển Là mơ hình logic (mơ hình mô tả hoạt động lĩnh vực kinh doanh mà không đề xuất cách chúng tiến hành) Sơ đồ hoạt động Usecase mơ hình logic - mơ hình mơ tả hoạt động lĩnh vực kinh doanh mà không đề xuất cách chúng tiến hành Định nghĩa Activity diagrams: Là mơ hình logic dùng để mơ hình hố hoạt động quy trình nghiệp vụ (hay sơ đồ luồng xử lý hệ thống) dùng để mô tả hoạt động chức hệ thống (hay luồng xử lý Use–Case) Mô tả hoạt động mối quan hệ hoạt động quy trình (hay mơ tả luồng xử lý hệ thống bao gồm luồng con, luồng xử lý Use – Case gom lại mà thành) Một mảnh thông tin thu thập dạng giấy qua Web; thông tin đặt tủ đựng hồ sơ sở liệu lớn Các chi tiết gọi chi tiết vật lý xác định q trình thiết kế mơ hình logic chỉnh thành mơ hình vật lý Các mơ hình cung cấp thơng tin cần thiết để cuối xây dựng hệ thống Bằng cách tập trung vào hoạt động logic trước tiên, tập trung vào cách hoạt động doanh nghiệp mà không bị phân tâm chi tiết liên quan Cách thức hoạt động: Bước đầu tiên, nhóm dự án thu thập u cầu từ người dùng II Mơ hình hóa quy trình kinh doanh với sơ đồ hoạt động Mơ hình quy trình kinh doanh mơ tả hoạt động khác nhau, kết hợp với để hỗ trợ quy trình kinh doanh Các quy trình kinh doanh thường tác động (cut across) đến phận chức & từ quan điểm hướng đối tượng, chúng tác động đến nhiều đối tượng → có hướng bỏ qua quy trình kinh doanh làm mẫu, tập trung vào UC & mơ hình hành vi Mơ hình thân quy trình kinh doanh hoạt động mang tính xây dựng sử dụng để thực nhận yêu cầu thu thập Có xu hướng củng cố tư phân rã chức Là công cụ mạnh để truyền đạt hiểu biết nhà phân tích yêu cầu với người dùng Sơ đồ hoạt động gồm ký hiệu đề cập đến việc mô hình hóa hoạt động song song & q trình định phức tạp → sử dụng để mơ hình hóa loại quy trình Các yếu tố sơ đồ hoạt động Action ■ Là hành vi đơn giản, phân hủy ■ Được gắn nhãn theo tên Activity ■ Được sử dụng để đại diện cho tập hợp hành động ■ Được gắn nhãn theo tên Object node: ■ Được sử dụng để biểu diễn đối tượng kết nối với tập hợp luồng đối tượn ■ Được gắn nhãn theo tên lớp Control flow ■ Hiển thị trình tự thực Object flow ■ Hiển thị luồng đối tượng từ hoạt động (hoặc hành động) sang hoạt động khác Fork: sử dụng để chia hành vi quy trình nghiệp vụ thành nhiều luồng song so Join: thể trường hợp phải thực hai hay nhiều hành động trước thực h Initial node ■ Vẽ chân dung phần đầu tập hợp hành động hoạt động Final-activity node ■ Được sử dụng để dừng tất luồng điều khiển luồng đối tượng hoạt động Final-flow node ■ Được sử dụng để dừng luồng điều khiển luồng đối tượng cụ thể Decision node ■ Được sử dụng để đại diện cho điều kiện kiểm tra để đảm bảo luồng điều khiển h xuống đường ■ Được gắn nhãn với tiêu chí định để tiếp tục theo đường cụ thể Merge node ■ Được sử dụng để tập hợp lại đường dẫn định khác tạo cách s Hình 5-2 trình bày sơ đồ hoạt động đại diện cho phần hệ thống đặt hẹn cho phịng khám bác sĩ (Actions and Activities) thể hành vi thủ công máy tính hóa Cho thấy sáu tỷ lệ riêng biệt có liên quan đến hệ thống hẹn điển hình sử dụng phịng khám bác sĩ: Lấy thơng tin bệnh nhân, Tạo bệnh nhân mới, Sắp xếp toán, Tạo hẹn, Cancel Cuộc hẹn Thay đổi hẹn (Object Nodes) Về bản, nút đối tượng đại diện cho luồng thông tin từ hoạt động đến hoạt động khác Hình cho thấy đối tượng từ hoạt động Tạo Cuộc hẹn Thay đổi Cuộc hẹn (Control Flows and Object Flows) Hình 5-2 mơ tả loạt luồng kiểm sốt thơng qua hệ thống hẹn phòng khám bác sĩ Dòng đối tượng mơ hình dịng chảy đối tượng thơng qua quy trình kinh doanh Vì Actions and Activities sửa đổi chuyển đổi đối tượng, luồng đối tượng cần thiết để hiển thị đối tượng chảy vào khỏi Actions and Activities.Một dịng đối tượng mơ tả đường đứt nét với đầu mũi tên hiển thị hướng dòng chảy Một luồng đối tượng riêng lẻ phải gắn với Actions and Activities đầu nút đối tượng đầu Decision Merge Hình 5-2, nút decision bên hoạt động (get patient information) nhận thơng tin có hai đường loại trừ lẫn thực thi: cho bệnh nhân cũ trước đó, cho bệnh nhân Các Merge sử dụng để kết hợp nhiều đường dẫn loại trừ lẫn phân chia dựa định trước Tuy nhiên, đơi khi, mục đích rõ ràng, tốt không nên sử dụng nút hợp Hình 5-3 nút Decision phát nhiệm vụ kép sơ đồ bên phải Nó đóng vai trị nút Merge Nói mặt kỹ thuật, không nên bỏ qua nút Merge, nhiên, mặt kỹ thuật theo quy tắc lập sơ đồ UML thực khiến sơ đồ trở thành hợp Trong Figure 5-4, nút fork sử dụng để hai trình song song, đồng thời thực thi Trong trường hợp này, tiến trình thực thi hai xử lý riêng biệt (Parent) Mục đích nút join tự mục đích nút merge Nút join đơn giản đưa trở lại để tập hợp luồng song song đồng thời riêng biệt quy trình kinh doanh thành luồng (Swimlanes): Hình 5-4 Swimlanes sử dụng để chia parent làm bữa trưa trường bao gồm ăn bánh mì kẹp bơ đậu phộng thạch, đồ uống tráng miệng Trong trường hợp này, sử dụng Swimlanes thẳng đứng Chúng ta vẽ sơ đồ hoạt động cách sử dụng hướng từ trái sang phải nhiều thay hướng từ xuống Trong trường hợp đó, Swimlanes vẽ theo chiều ngang Nguyên tắc tạo sơ đồ hoạt động: Gồm nguyên tắc: - Đặt cho sơ đồ tiêu đề thích hợp Xác định hoạt động, luồng kiểm sốt luồng đối tượng xảy hoạt động Nên xác định định phần q trình mơ hình hóa Bạn nên cố gắng xác định triển vọng cho song song trình Vẽ sơ đồ hoạt động III.Tạo mô tả Use-case Mô tả Use-case: • Mơ tả Use-case mơ tả đơn giản chức hệ thống từ nhìn tổng quan người dùng Biểu đồ use-case sơ đồ chức chúng mơ tả chức hệ thống — nghĩa người dùng làm hệ thống phản hồi hành động người dùng Mô tả use-case chứa tất thông tin cần thiết để tạo sơ đồ use-case Mô tả use-case sơ đồ use-case mặt kỹ thuật, thực không quan trọng Cả hai phải thực để mơ tả đầy đủ u • • • cầu mà hệ thống thông tin phải đáp ứng Một use-case giao tiếp mức cao hệ thống cần phải làm tất kỹ thuật lập sơ đồ UML xây dựng dựa điều cách trình bày chức use cases theo cách khác cho mục đích khác Use-cases nắm bắt tương tác điển hình hệ thống với người dùng hệ thống Những tương tác thể nhìn bên ngồi chức hệ thống từ quan điểm người dùng Mỗi use-case mô tả chức người dùng tương tác với hệ thống, Điều quan trọng cần nhớ use cases sử dụng cho mơ hình hành vi tương lai Nguyên tắc để tạo mô tả Use-case Viết tập hợp dạng chủ ngữ-động từ-tân ngữ trực tiếp Đảm bảo rõ ràng người khởi xướng bước này: người tiếp nhận hành động bước Thông thường, người khởi xướng nên chủ ngữ câu người nhận phải đối tượng trực tiếp câu Viết bước từ quan điểm người quan sát độc lập: bước phải viết trước từ quan điểm người khởi tạo người nhận Viết bước mức độ trừu tượng: Mỗi bước tạo mức độ tiến để hoàn thành Use case bước khác Trên Use case cấp cao, số lượng tiến trình đáng kể, Use case cấp thấp, bước đại diện cho tiến trình gia tăng Đảm bảo use cases có tập hợp bước hợp lý: Mỗi Use case phải đại diện cho giao dịch, Use case nên bao gồm bốn phần: • Tác nhân bắt đầu thực thi Use case cách gửi yêu cầu (và liệu) vào hệ thống • Hệ thống đảm bảo yêu cầu (và liệu) hợp lệ • Hệ thống xử lý yêu cầu (và liệu) thay đổi trạng thái bên • Hệ thống gửi tác nhân kết xử lý Áp dụng ngun tắc KISS cách phóng khống: Nếu Use case trở nên phức tạp / dài, Use case phải phân tách thành tập Use case Hơn nữa, luồng kiện bình thường Use case trở nên phức tạp, nên sử dụng luồng Viết hướng dẫn lặp lại sau tập hợp bước lặp lại: Lặp lại bước đáp ứng số điều kiện sau bước cuối Điều làm cho trường hợp sử dụng dễ đọc người không quen với lập trình Các loại Use-case: • • Overview versus detail: sử dụng phép nhà phân tích người dùng đồng ý tổng quan cấp cao yêu cầu tạo sớm trình hiểu yêu cầu hệ thống ghi lại thông tin use-case Essential versus real: use case mô tả vấn đề thiết yếu tối thiểu cần thiết để hiểu chức cần thiết use cases thiết yếu không phụ thuộc vào việc triển khai, use cases thực mô tả chi tiết cách sử dụng hệ thống sau triển khai IV Sơ đồ Usecase: Một nhà phân tích sử dụng sơ đồ UC để hiểu rõ chức hệ thống mức cao & vẽ sớm SDLC (Software Development Life Cycle) Thu thập xác định yêu cầu cho hệ thống UC khuyến khích người dùng cung cấp yêu cầu bổ sung mà UC viết không phát An Actor: ■ Là cá nhân hệ thống thu lợi ích từ bên ngồi bên ngồi đối tượng ■ Được mơ tả hình gậy (mặc định) Actor khơng phải người có liê ■ Được gắn nhãn với vai trị ■ Có thể liên kết với Actor khác cách sử dụng kết hợp chun mơn hóa / siêu lớp, đượ ■ Được đặt bên ranh giới đối tượng A Use case: ■ Trình bày phần chức hệ thống ■ Có thể mở rộng Use case khác ■ Có thể bao gồm Use case khác ■ Được đặt bên ranh giới hệ thống ■ Được gắn nhãn với cụm động từ - danh từ mô tả Ranh giới chủ đề (A subject boundary) ■ Bao gồm tên đối tượng bên bên ■ Đại diện cho phạm vi chủ đề, ví dụ, hệ thống quy trình kinh doanh riêng lẻ Mối quan hệ kết hợp (An association relationship) ■ Liên kết diễn viên với Use case mà tương tác (An include relationship) Mối quan hệ bao gồm: ■ Đại diện cho việc bao gồm chức Use case Use case khác ■ Có mũi tên vẽ từ Use case gốc đến Use case sử dụng (An extend relationship) Một mối quan hệ mở rộng: ■ Đại diện cho phần mở rộng Use case để bao gồm hành vi tùy chọn ■ Có mũi tên vẽ từ Use case mở rộng đến Use case sở (A generalization relationship) Mối quan hệ tổng quát hóa: ■ Đại diện cho Use case chuyên biệt sang Use case tổng quát ■ Có mũi tên vẽ từ Use case chuyên dụng đến Use case sở Overview Information: xác định use case cung cấp thông tin use case Một Use case có nhiều bên liên quan có lợi ích Use case Như vậy, Use case liệt kê bên liên quan với mối quan tâm bên Use case • • Relationships: giải thích cách Use case liên quan đến Use case người dùng khác Có bốn kiểu quan hệ bản: association, extend, include, and generalization • Association: ghi lại thơng tin liên lạc diễn Use case actor sử dụng Use case Actor đại diện UML cho vai trò người dùng use case • Extend: đại diện cho việc mở rộng chức use- case để kết hợp hành vi tùy chọn • Include: thể bao gồm bắt buộc trường hợp sử dụng khác Mối quan hệ bao gồm cho phép phân tách chức để chia nhỏ use-case phức tạp thành nhiều use-case đơn giản • Generalization: cho phép use-case hỗ trợ tính kế thừa Hành vi chuyên biệt đặt trường hợp sử dụng chuyên biệt thích hợp • Flow of Events: • Normal flow of events: bao gồm bước thường thực use-case Các bước liệt kê theo thứ tự thực • Subflows: Normal flow of events nên phân tách thành tập hợp subflows để giữ cho luồng kiện bình thường đơn giản tốt • Alternate or exceptional flows: luồng có xảy khơng coi chuẩn mực Những điều phải lập thành văn • Optional Characteristics: bao gồm mức độ phức tạp use-case, lượng thời gian ước tính cần thiết để thực use-case, hệ thống liên kết với use-case, luồng liệu cụ thể actor use-case, thuộc tính cụ thể nào, ràng buộc, hoạt động liên quan đến use-case, điều kiện tiên phải thỏa mãn để use-case thực thi Sơ đồ use cases Vẽ ranh giới chủ thể (subject boundary.): Điều tạo thành biên giới chủ đề, ngăn cách trường hợp sử dụng (tức chức chủ thể) khỏi tác nhân (tức vai trị người dùng bên ngồi) Đặt UC sơ đồ: Chúng lấy trực tiếp từ mô tả UC chi tiết Các liên kết UC đặc biệt (include, extend, or generalization) thêm vào mô hình thời điểm Thường phải vẽ lại sơ đồ nhiều lần với UC nhiều nơi khác để dễ đọc sơ đồ Ngồi ra, mục đích dễ hiểu, khơng nên có nhiều ba đến chín UC mơ hình để sơ đồ đơn giản tốt Chúng bao gồm UC tính tốn liên kết với UC khác thông qua mối quan hệ include, extend, generalization Đặt actor sơ đồ: Các actor lấy trực tiếp từ phần tử primary actor mô tả use cases chi tiết Giống vị trí use cases, để giảm thiểu số dịng cắt ngang sơ đồ, actor nên đặt gần use cases mà chúng liên kết Vẽ associations: Sơ đồ không ngụ ý thứ tự mục thêm vào trình thực không cần phải đặt theo thứ tự cụ thể; đó, giúp xếp lại ký hiệu chút để giảm thiểu số lượng đường cắt ngang, làm cho sơ đồ dễ hiểu Các bước tạo sơ đồ use case: - Xác định UC chính: Xem lại sơ đồ hoạt động (activity diagram): giúp nhà phân tích có nhìn tổng quan đầy đủ quy trình kinh doanh mơ hình hóa Tìm ranh giới chủ thể (subject's boundaries.): giúp nhà phân tích xác định phạm vi hệ thống Xác định primary actors mục tiêu: Xác định actor tham gia vào hệ thống đến từ danh sách bên liên quan người dùng Các mục tiêu thể chức mà hệ thống phải cung cấp cho Actor để hệ thống thành công Xác định nhiệm vụ mà Actor phải thực tạo điều kiện thuận lợi Xác định viết tổng quan use case cho phần với thông tin UC, thay nhảy vào UC mơ tả hồn tồn Xem xét cẩn thận UC Sửa đổi cần thiết: Có thể cần phải chia số số chúng thành nhiều UC hợp số chúng thành UC Việc xác định use cases trình lặp lặp lại, với người dùng thường thay đổi suy nghĩ họ use cases bao gồm Rất dễ bị mắc kẹt chi tiết thời điểm này, bạn cần nhớ mục tiêu bước xác định UC bạn tạo UC tổng quan - Mở rộng UC Chọn UC để mở rộng: Sử dụng mức độ quan trọng use cases giúp thực điều Bắt đầu điền thông tin chi tiết UC chọn: liệt kê tất bên liên quan xác định lợi ích họ use cases, mức độ quan trọng use cases, mô tả ngắn gọn use cases, thơng tin kích hoạt cho use cases mối quan hệ use cases tham gia 10 Flow of events bình thường use cases: Các bước tập trung vào quy trình nghiệp vụ thực để hoàn thành use cases bước nên liệt kê theo thứ tự thực hiện, từ đến cuối 4.Flow of events bình thường phức tạp dài, phân rã thành subflows: Mỗi bước phải có kích thước với bước khác Liệt kê possible alternate exceptional flows: Các luồng thay đặc biệt luồng thành công đại diện cho hành vi tùy chọn đặc biệt Chúng có xu hướng xảy khơng thường xun dịng chảy bình thường bị lỗi Chúng phải dán nhãn để khơng có nghi ngờ luồng kiện bình thường mà liên quan Đối với luồng thay đặc biệt (alternate or exceptional flow,), liệt kê cách tác nhân(actor) / hệ thống nên phản ứng: luồng thay đặc biệt thực thi, mô tả phản hồi mà tác nhân hệ thống phải tạo Giống luồng thông thường luồng con, luồng thay đặc biệt phải viết dạng SVDPI - Xác nhận trường hợp dùng UC Xem xét cẩn thận tập hợp use cases Sửa đổi cần thiết :xem xét cẩn thận tập hợp use cases xác nhận use cases viết, có nghĩa xem xét lại use cases với người dùng để đảm bảo bước xác.Việc xem xét nên tìm kiếm hội để đơn giản hóa use cases cách phân tách thành tập hợp use cases nhỏ hơn, hợp với người khác, tìm kiếm khía cạnh chung ngữ nghĩa cú pháp use cases xác định use cases mới.cũng lúc để xem xét thêm mối quan hệ bao gồm, mở rộng tổng quát hóa UC Cách mạnh mẽ để xác nhận use cases yêu cầu người dùng nhập vai thực quy trình bước viết use cases Lặp lại toàn bước: Người dùng thường thay đổi suy nghĩ họ UC bao gồm Tại thời điểm này, dễ bị mắc kẹt chi tiết, nhớ mục tiêu giải UC Do đó, nhà phân tích nên tiếp tục lặp lại bước cô ta người sử dụng tin có đủ số lượng UC để bắt đầu xác định lớp ứng viên cho mơ hình cấu trúc - Tạo sơ đồ Usecase 11 Hồn tất kích thước dự án dự toán lực sử dụng điểm UC25 - Ước tính kích thước nỗ lực cách sử dụng điểm UC, phải tạo tập hợp UC thiết yếu sơ đồ UC - Khi UC sơ đồ UC tạo, tác nhân UC phải phân loại đơn giản, trung bình phức tạp - Các tác nhân đơn giản hệ thống riêng biệt mà hệ thống phải giao tiếp thơng qua giao diện chương trình ứng dụng (API) xác định rõ rang - Các tác nhân trung bình hệ thống riêng biệt tương tác với hệ thống cách sử dụng giao thức truyền thông tiêu chuẩn - Tùy thuộc vào số lượng giao dịch mà UC phải giải quyết,UC phân loại UC đơn giản (1–3), UC trung bình (4–7) UC phức tạp (> 7) Ước tính cách sử dụng điểm Use-Case Những ưu điểm việc sử dụng điểm usecases so với công nghệ kỹ thuật ước tính truyền thống chúng dựa UC phát triển hệ thống hướng đối tượng cách tiếp cận truyền thống để phát triển hệ thống Ví dụ: tạo tập hợp UC cho cấp cao sau quy trình hệ thống nhà khuôn viên trường điều hành dịch vụ V Câu hỏi trắc nghiệm 12 13 ... yêu cầu với người dùng Sơ đồ hoạt động gồm ký hiệu đề cập đến việc mô hình hóa hoạt động song song & q trình định phức tạp → sử dụng để mơ hình hóa loại quy trình Các yếu tố sơ đồ hoạt động Action... doanh với sơ đồ hoạt động Mơ hình quy trình kinh doanh mơ tả hoạt động khác nhau, kết hợp với để hỗ trợ quy trình kinh doanh Các quy trình kinh doanh thường tác động (cut across) đến phận chức... hoạt động doanh nghiệp mà không bị phân tâm chi tiết liên quan Cách thức hoạt động: Bước đầu tiên, nhóm dự án thu thập u cầu từ người dùng II Mơ hình hóa quy trình kinh doanh với sơ đồ hoạt động