Object - Oriented analysis and design with uml 2.0 - Bài 4: Mô hình hóa yêu cầu sử dụng use case

OBJECT-ORIENTED ANALYSIS AND DESIGN WITH UML 2.0*Bé m«n C«ng nghƯ phÇn mỊmKHOA CƠNG NGHỆ THƠNG TINTRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘIBài 4. Mơ hình hĩa yêu cầu sử dụng use caseNội dungMơ hình hĩa yêu cầuBiểu đồ use caseĐặc tả use caseThuật ngữĐặc tả phụ trợ*1.1. Mục đíchThiế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ệnCung cấp các thơng tin cơ bản để lập kế hoạch phát triển dự án*1.1. Mục đích (2)Cung cấp những cơ sở để ước lượng giá thành và thời gian để phát triển hệ thốngNắm bắt được những yêu cầu và mục đích của người sử dụng*1.1. Mục đích (3)*1.2. Mơ hình hĩa yêu cầuMơ hình hĩa các chức năng mà hệ thống sẽ thực thiMơ hình bao gồm các chức năng định trước của hệ thốngSử dụng khái niệm Use Case*1.2. Mơ hình hĩa yêu cầu (3)Các thành phần chính:*Nội dungMơ hình hĩa yêu cầuBiểu đồ use caseĐặc tả use caseThuật ngữĐặc tả phụ trợ*2.1. Actor và use caseTác nhân (actor) biểu diễn bất cứ thứ gì tương tác với hệ thống.Use case (Chức nă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 tốn chứ khơng phải để THIẾT KẾ phần mềm*ActorUse Case2.1.1. Tác nhân*Tác nhân biểu diễn các vai trị của một người dùng trong hệ thốngCĩ 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ựngVí dụ như các thiết bị ngoại vi, thậm chí là databaseCĩ thể chủ động trao đổi thơng tin với hệ thốngCĩ thể là người đưa thơng tin vào hệ thốngCĩ thể là người nhận thơng tin.Khơng phải là một phần của hệ thốngActors are EXTERNAL.ActorTì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ên tác nhân phải mơ tả vai trị của tác nhân đĩ một cách rõ ràngTên nên là danh từCần mơ tả khái quát khả năng của tác nhân đĩ*Ví dụ về tác nhânTác nhân trao đổi thơng tin với hệ thống:Gửi thơng tin tới hệ thốngNhận thơng tin từ hệ thống*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ác2.1.2. Use case*Use CaseUse case (chức năng) là một trình tự hành động của hệ thống thực hiện nhằm thu được một kết quả dễ thấy tới một tác nhân nào đĩ.Một use case mơ hình hĩa một hội thoại giữa một hoặc nhiều tác nhân với hệ thốngMột use case mơ tả hành động của hệ thống thực hiện nhằm mang đến một giá trị nào đĩ cho tác nhân.Tìm use case của hệ thốngXem 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ốngCá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 tác nhânTên nên là động từMơ tả ngắn gọn về mục đích của UC*Những điều nên tránh khi tạo UCTạ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ịngTạ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”)*2.2. Mối liên hệ (relationship)Mối liên hệ giữa các actor với nhauKhái quát hĩa (Generalization)Giao tiếpMối liên hệ giữa actor và use caseGiao tiếpMối liên hệ giữa các use case với nhauGeneralization: Khái quát hĩaInclude: Bao hàmExtend: Mở rộng*2.2.1. Mối liên hệ giữa các actor với nhauKhá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 chaGiao tiếpXét sự khác nhau giữa hai biểu đồ sau*2.2.2. Mối liên hệ giữa actor với use caseThiết lập quan hệ giữa Tác nhân và Use CaseChúng tương tác bằng cách gửi các tín hiệu cho nhauMộ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ốngMột use case được bắt đầu bởi một tác nhân để gọi một chức năng nào đĩ trong hệ thống.*ActorAssociationUse Case2.2.2. Mối liên hệ giữa actor với use case (2) Chiều của quan hệ chính là chiều của tín hiệu gửi điTừ tác nhân tới Use CaseKích hoạt Use caseHỏi thơng tin nào đĩ trong hệ thốngThay đổi thơng tin nào đĩ trong hệ thốngThơng báo cho UC về một sự kiện đặt biệt nào đĩ xảy ra với hệ thốngTừ 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*2.2.3. Mối liên hệ giữa các use case với nhauGeneralization>always use>sometime use*Quan hệ generalizationĐượ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 UCSử dụng khái niệm kế thừaMơ tả hành vi chung (chia sẻ) trong UC chaMơ tả hành vi riêng trong (các) UC con*Khi nào thì dùng quan hệ generalization?Dùng để mơ tả các hành vi chung, cấu trúc và mục đích trong 2 hay nhiều UCChỉ ra UC con là một thành phần của họ UCTránh mơ tả hành vi (chung) nhiều lầnĐảm bảo hành vi chung được thống nhấtThực thi UC conTheo luồng sự kiện của UC chaChèn thêm hành vi riêng của UC con theo sự mơ tả trong UC conMột số hành vi trong UC cha cĩ thể bị sửa đổi trong UC con*>Cho phép một UC sử dụng chức năng của UC khácChức năng của UC Inclusion sẽ được gọi trong UC BaseSử dụng stereotype là >*Khi nào thì dùng quan hệ >Tách ra hành vi (chức năng) chung của 2 hoặc nhiều UCTránh việc mơ tả hành vi đĩ nhiều lần trong các UCĐảm bảo nhưng hành vi chung đĩ được thống nhấtTách ra hành vi của UC cơ sở nên được đĩng gĩi riêng (encapsulate)Tách hành vi khơng phải là chính của UC đĩ (hành vi ít quan trọng)Giảm thiểu sự phức tạp của luồng sự kiện*>Cho phép mở rộng chức năng của một UCChèn hành vi của UC Extension vào UC BaseChỉ chèn khi điều kiện extend đúng (mở rộng, phát sinh)Chèn vào lớp cơ sở tại điểm phát sinh (extension point)Sử dụng stereotype là >*2.3. Các thành phần khácGhi chú (Notes)Thêm các ghi chú để sơ đồ rõ ràng hơn*2.3. Các thành phần khác (2)Cĩ thể nhĩm các thành phần (Use-Case, Actor, quan hệ hoặc các sơ đồ khác) thành một nhĩm chung (package)Nếu số lượng Use Case quá lớn, nên chia chúng vào các nhĩmDễ hiểu mơ hình tổng thể hơnDễ bảo trì mơ hình Use CaseDễ giao việc cho các thành viênXem xét khả năng gộp nhĩmTương tác với cùng một tác nhânNhĩm Use Case hợp thành một quy trình (module) tương đối hồn thiện*2.4. Biểu đồ use caseBiểu đồ use case (use case diagram)Là tập hợp các actor và các use case lại; bổ sung các mối liên quan (association) giữa chúng và lập thành biểu đồ use case*Đọc biểu đồ use caseTrả lời các câu hỏi sau:Mơ tả các chức năng của hệ thốngSinh viên cĩ thể tác động lên những use-case nào?Giáo viên cĩ thể tác động lên những use-case nào?Nếu A vừa là sinh viên vừa là giáo viên, anh ta cĩ thể thực hiện được những use-case nào?Sơ đồ này khơng nĩi lên được những gì?Những use-case nào cần thiết thực hiện đầu tiên?Sơ đồ Use Case cĩ thể mơ tả được hết khơng?*Nội dungMơ hình hĩa yêu cầuBiểu đồ use caseĐặc tả use caseThuật ngữĐặc tả phụ trợ*Đặc tả Use CaseTên:Tên của Use caseMơ 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Điều kiệnTiền điều kiệnHậu điều kiệnLuồ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-caseBiểu đồ hoạt độngMinh họa luồng sự kiện bằng mơ hìnhCác yêu cầu đặc biệt*Luồng sự kiện của use-caseTrả lời được quá trình từ khi bắt đầu đến khi kết thúc của một use-caseChỉ 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ọnMơ tả dữ liệu được trao đổi giữa tác nhân và use-case đĩ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*Luồng sự kiện của use-case (2)Luồng chính (Basic flow)Luồng lý tưởng mà Use case thường hoạt độngLuồng phát sinh (Alternative flow)Sử dụng nhiều lần trong luồng chínhCá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 thiPhải cĩ lời gọi luồng phát sinh từ luồng chínhTránh viết luồng phát sinh dài hơn luồng chínhTránh viết luồng phát sinh quá dàiTránh tách quá nhiều luồng phát sinh*Luồng sự kiện của use-case (3)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*Ví dụUC Rút tiềnGọi UC “Xác thực KH”Hiển thị menu.KH chọn chức năng “Rút tiền”...UC Xác thực KHĐưa thẻ vào máyKiểm tra thẻKH nhập PINHệ thống kiểm tra PINE1: Thẻ saiE2: Sai PINE3: ...*Ví dụ đặc tả UC Rút tiền mặtLuồng chính:Gọi UC “Xác thực KH” để ktra KHHiển thị menuKH chọn chức năng “Rút tiền”Nhập số tiền cần rútHT gửi giao dịch tới ngân hàng chờ chấp thuậnMáy ATM xuất tiền (tiền giấy)Trả lại thẻIn biên laiLuồng phát sinh:Luồng phát sinh “Rút tiền xu” 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)Nếu KH chọn thể loại tiền xuKH nhập số lượng xuHệ thống tính ra tổng số tiền cần rútKH chấp nhậnKhay tiền xu mở để xuất tiềnUC Rút tiền tiếp tục thực hiện*Biểu đồ hoạt độngBiểu đồ hoạt động trong mơ hình use case được sử dụng để 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ệnBiể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.*Flow of EventsThis use case starts when the Registrar requests that the system close registration.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.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.Activity 1Activity 3Activity 2Biể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ảnCĩ 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*>Boolean constraintActivity 5>Boolean constraintActivity 4Activity 2Biểu đồ hoạt độngĐược sử dụng để minh hoạ luồng sự kiện*Ví dụ*SynchronizationBar (Fork)GuardConditionSynchronizationBar (Join)DecisionConcurrent ThreadsTransitionSelect Course[ add course ] Check ScheduleCheck Pre-requisitesAssign to CourseResolve ConflictsUpdate ScheduleDelete Course[ checks completed ][ checks failed ][ delete course ]Activity/ActionVí dụ về UC Mua hàng trên mạngMơ tả:Giả sử cĩ một hệ thống của hàng ảo trên mạngUC Bán hàng cho phép khách hàng (KH) mua được các mặt hàng mong muốnVí dụ này yêu cầu KH phải thành tốn trực tuyếnTiền điều kiện:KH muốn mua hàng trên cửa hàng ảoKH cĩ thể thanh tốn điện tử tới ngân hàng mà cửa hàng hỗ trợHậu điều kiện:Thành cơng khi KH chấp nhận mua hàng và quá trình thanh tốn với ngân hàng thực hiện thành cơng. Hĩa đơn được lập, hàng hĩa được dành riêng cho KH đĩNếu quá trình thanh tốn với ngân hàng khơng thành cơng, hĩa đơn sẽ khơng được lập, hàng cũng khơng được bán raThực thể:Mặt hàng, Giỏ hàng, Đơn hàngUse case liên quan:Tìm kiếm hàng, quản lý đơn hàng (Giao hàng)*Luồng sự kiện cho Use CaseKH duyệt, tìm kiếm và xem thơng tin các mặt hàng muốn mua (xem UC xem hàng)KH cĩ thể chọn chức năng “Đưa hàng vào giỏ hàng”Hệ thống sẽ đưa mặt hàng này vào giỏKH cĩ thể nhập số lượng muốn mua (mặc định là 1)Hệ thống sẽ tự động cập nhật giá của giỏ hàng hiện tạiKH cĩ thể lặp lại quá trình này để mua tiếp các mặt hàng khác1. Giỏ hàng sẽ khơng mất đi trong quá trình KH tìm/mua mặt hàng khác2. Nếu giỏ hàng đã cĩ mặt hàng này, hệ thống sẽ báo lại cho KHQuản lý giỏ hàngMỗi một KH cĩ một rỏ hàng riêng rẽ và khơng ai nhìn thấy thơng tin của nhauKH cĩ thể chọn chức năng “Xem giỏ hàng” bất kỳ lúc nào cầnHệ thống sẽ hiển thị giỏ hàng với đầy đủ các mặt hàng KH đã chọn, cùng số lượng và giá cả từng loạiKH cĩ thể thay đổi số lượng, hoặc bỏ đi mặt hàng mà KH khơng muốn muaKH cĩ thể chọn chức năng thành tốn, xem luồng phụ “Thanh tốn”*Luồng phụ: Thanh tốnKH cĩ thể chọn chức năng thanh tốnKH được yêu cầu nhập thẻ thanh tốn và địa chỉ giao hàngThơng tin thanh tốn được đưa tới ngân hàng, hệ thống sẽ chờ kết quả từ ngân hàng đĩ(Quá trình xử lý giao dịch là do ngân hàng quyết định)Nếu ngân hàng khơng chập nhận giao dịchHệ thống sẽ thơng báo kết quả tới KH, yêu cầu nhập lại thơng tinNếu ngân hàng chấp nhận(Số tiền tương ứng của KH được chuyển sang tài khoản của cửa hàng)Hệ thống sẽ lập Đơn hàng và lưu lại (xem UC quản lý đơn hàng)Số lượng hàng tồn kho sẽ được giảm tương ứngHệ thống thơng báo thành cơng cho KH trên trang web và gửi thơng tin đơn hàng qua mail của KHGiỏ hàng sẽ bị xĩa đi (nếu mua tiếp, giỏ hàng sẽ được tạo mới)*Nội dungMơ hình hĩa yêu cầuBiểu đồ use caseĐặc tả use caseThuật ngữĐặc tả phụ trợ*4. Thuật ngữ (Glossary)Tài liệu Thuật ngữ định nghĩa các thuật ngữ quan trọng được sử dụng trong dự án.Chỉ có mợt tài liệu Thuật ngữ cho toàn hệ thớng.Quan trọng đới với rất nhiều người phát triển, đặc biệt là khi họ cần để hiểu và sử dụng các thuật ngữ riêng cho dự án.Hỡ trợ các liên lạc giữa những chuyên gia lĩnh vực (nghiệp vụ) với các nhà phát triển. Được phát triển chủ yếu trong các giai đoạn Inception và Elaboration vì cần có sự thớng nhất sớm về các thuật ngữ chung trong dự án.*4. Thuật ngữ (2)Chuyên gia phân tích hệ thớng chịu trách nhiệm trong việc đảm bảo tính toàn vẹn của tài liệuĐược tạo ra đúng thời điểmLiên tục được bảo đảm là nhất quán đới với các kết quả phát triển. Mợt dự án cần thiết lập mẫu cho tài liệu tùy thuợc vào từng dự án:Introduction: Mơ tả ngắn gọn về tài liệu và mục đích của tài liệu Thuật ngữ.Terms: Định nghĩa các thuật ngữ càng chi tiết nếu cần để mơ tả mợt cách đầy đủ và khơng nhập nhằng.*4. Thuật ngữ (3)*GlossaryCourse Registration System Glossary1.        IntroductionThis document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information.2.         DefinitionsThe glossary contains the working definitions for the key concepts in the Course Registration System.2.1       Course: A class offered by the university.2.2       Course Offering: A specific delivery of the course for a specific semester – you could run the same course in parallel sessions in the semester. Includes the days of the week and times it is offered.2.3      Course Catalog: The unabridged catalog of all courses offered by the university.Nội dungMơ hình hĩa yêu cầuBiểu đồ use caseĐặc tả use caseThuật ngữĐặc tả phụ trợ*Đặc tả phụ trợ(Supplementary Specification)Ban đầu được tạo ra trong pha Inception để định nghĩa phạm vi của hệ thớngĐược tinh chỉnh tăng dần trong các pha Elaboration và Construction.*SupplementarySpecificationĐặc tả phụ trợ(Supplementary Specification)Các yêu cầu phi chức năng và chức năng khơng được đưa ra trong bất kỳ use case cụ thể nàoFunctionalityUsabilityReliabilityPerformanceSupportabilityDesign constraints*SupplementarySpecificationĐặc tả phụ trợ (2)Chức năng (Functionality)Các yêu cầu chức năng tởng quan cho tất cả các use caseKhả năng sử dụng (Usability)Ví dụ: các yêu cầu về khả năng sử dụng dễ dàng hoặc yêu cầu về đào tạo người dùng.Đợ tin cậy (Reliability)Các đợ đo định lượng như thời gian trung bình giữa các lần gặp sự cớ hoặc lỡi trên nghìn dòng mã.*Đặc tả phụ trợ (3)Hiệu năng (Performance)Bao gờm thời gian đáp ứng, sớ lượng người sử dụng đờng thời,...Khả năng hỡ trợ (Supportability)Các yêu cầu nhằm tăng cường khả năng hỡ trợ hoặc khả năng bảo trì của hệ thớngCác ràng buợc thiết kế (design constraints)*Tổng kếtĐặc tả yêu cầuĐĩng vai trị như một thỏa thuận giữa khách hàng, người sử dụng và những người phát triển hệ thốngCho phép khách hàng và người sử dụng kiểm tra những chức năng mà họ mong đợi hệ thống sẽ thực hiệnNgười phát triển cĩ thể hiểu được cần phải làm gìCần tuân thủ theo một quy trình hợp lýMột số chú ý khi đặc tả yêu cầu với mơ hình UCSử dụng mẫu tài liệu, hướng dẫnPhát triển các luồng sự kiện đơn giản, rõ ràng về mặt nghiệp vụ (trách đưa ra các thơng tin quá chi tiết, kỹ thuật)Xây dựng biểu đồ hoạt động cho những vấn đề phức tạp*Case study – Course RegistrationActor?Use case?Relationship?*