Bài giảng Thiết kế hệ thống thông tin - Chương IV: Phân tích và thiết kế hướng đối tượng

179 trang phuongnguyen 8840

Download

Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Thiết kế hệ thống thông tin - Chương IV: Phân tích và thiết kế hướng đối tượng", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

bai_giang_thiet_ke_he_thong_thong_tin_chuong_iv_phan_tich_va.pdf

Nội dung text: Bài giảng Thiết kế hệ thống thông tin - Chương IV: Phân tích và thiết kế hướng đối tượng

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM KHOA CÔNG NGHỆ THÔNG TIN Chương IV Trần Thị Kim Chi 1
NỘI DUNG 1. Tổng quan về phân tích và thiết kế 2. Mục đích của phân tích 3. Qui trình phân tích yêu cầu 4. Các bước phân tích theo hướng đối tượng 5. Mục đích của thiết kế 6. Qui trình thiết kế 7. Phương pháp phân tích và thiết kế hướng đối tượng 8. Phân tích Use case 9. Đặc tả Use Case 10. Phân tích Use case nghiệp vụ Trần Thị Kim Chi 2
MỤC ĐÍCH CỦA PHÂN TÍCH VÀ THIẾT KẾ The purposes of Analysis and Design are to: Transform the requirements into a design of the system-to-be. Evolve a robust architecture for the system. Adapt the design to match the implementation environment, designing it for performance. Trần Thị Kim Chi 3
TỔNG QUAN VỀ PHÂN TÍCH VÀ THIẾT KẾ Design Model Use-Case Model Analysis and Design Architecture Document Glossary Supplementary Specification Data Model Trần Thị Kim Chi 4
ANALYSIS VERSUS DESIGN Analysis Design . Focus on understanding . Focus on understanding the problem the solution . Idealized design . Operations and attributes . Behavior . Performance . System structure . Close to real code . Functional requirements . Object lifecycles . A small model . Nonfunctional requirements . A large model Trần Thị Kim Chi 5
Analysis and Design Are Not Top-Down or Bottom-Up Analysis and Design Top Down Subsystems Use Cases Analysis Classes (Define a Bottom middle level) Up Design Classes Trần Thị Kim Chi 6
Mục đích của phân tích yêu cầu • Mục đích của hoạt động phân tích yêu cầu là xây dựng mô hình phân tích với các đặc điểm sau : . dùng ngôn ngữ của nhà phát triển để miêu tả mô hình. . thể hiện góc nhìn từ bên trong của hệ thống. . được cấu trúc từ các class phân tích và các package phân tích. . được dùng chủ yếu bởi nhà phát triển để hiểu cách thức tạo hình dạng hệ thống. . loại trừ mọi chi tiết dư thừa, không nhất quán. . phát họa các hiện thực cho các chức năng bên trong hệ thống. . định nghĩa các dẫn xuất use-case, mỗi dẫn xuất use-case cấp phân tích miêu tả sự phân tích 1 use-case. Trần Thị Kim Chi 7
CÁC BƯỚC CHÍNH CỦA PHÂN TÍCH • Phân tích yêu cầu – Phân tích nghiệp vụ – Phân tích các yêu cầu theo quy trình xử lý – Bổ sung các quy trình cho phù hợp với máy tính – Yêu cầu bổ sung các thông tin • Xác lập tính năng hệ thống – Xác lập các chức năng mà hệ thống sẽ bao gồm – Xác lập các điều kiện và môi trường hoạt động • Xác thực tính năng hệ thống – Xác thực với người dùng về tính hợp lý và đầy đủ của các tính năng – Xác thực các quy trình nghiệp vụ – Xác thực các ràng buộc Trần Thị Kim Chi 8
PHÂN TÍCH NGHIỆP VỤ Mô hình nghiệp vụ mô tả: • các chức năng nghiệp vụ của một tổ chức • mối quan hệ bên trong giữa các chức năng đó cũng như các mối quan hệ của chúng với môi trường bên ngoài Mô hình phân rã chức năng • Là mô hình nghiệp vụ của hệ thống • Mô tả sự phân chia các chức năng nghiệp vụ của tổ chức thành các chức năng nhỏ hơn theo một thứ bậc xác định. Chức năng nghiệp vụ: • Tập hợp các công việc mà tổ chức cần thực hiện trong hoạt động của nó. Trần Thị Kim Chi 9
PHÂN TÍCH NGHIỆP VỤ • Chức năng được xem xét ở các mức độ từ tổng hợp đến chi tiết: – Một lĩnh vực hoạt động (area of activites) – Một hoạt động (activity) – Một nhiệm vụ (task) – Một hành động (action) Trần Thị Kim Chi 10
PHÂN TÍCH NGHIỆP VỤ Quy tắc phân rã • Mỗi chức năng được phân rã phải là một bộ phận thực sự tham gia thực hiện chức năng đã phân rã ra nó • Việc thực hiện tất cả các chức năng ở mức dưới phải đảm bảo thực hiện chức năng ở mức trên đã phân rã ra chúng Bố trí mô hình • Ở mỗi mức, các chức năng cùng mức sắp xếp trên cùng một hàng. Riêng mức cuối cùng có thểsắp xếp theo hàng dọc. • Bố trí cân đối, rõ ràng đểdễ kiểm tra, theo dõi Trần Thị Kim Chi 11
PHÂN TÍCH NGHIỆP VỤ Đặt tên chức năng • Mỗi chức năng có một tên duy nhất • Công thức Mô tả chi tiết chức năng ở mức cuối • Tên chức năng • Các sự kiện kích hoạt • Quy trình thực hiện • Dữ liệu vào, ra • Công thức tính toán sử dụng (nếu có) • Quy tắc nghiệp vụ cần tuân thủ Trần Thị Kim Chi 12
PHÂN TÍCH NGHIỆP VỤ Ma trận thực thể - chứcnăng • Nhằm xác định mối liên hệ giữa các chức năng và thực thể trong hệ thống • Bao gồm các dòng là các chức năng ở mức tương đối chi tiết, các cột là thực thể • Mỗi ô giao giữa dòng và cột có thểlà – C (Create - chức năng tạo ra dữ liệu mới trong thực thể) – R (Read - chức năng đọc dữ liệu trong thực thể) – U (Update - chức năng cập nhật dữ liệu trong thực thể) • Cho phép xem xét, phát hiện ra những khiếm khuyết trong khảo sát, loại bỏ những chức năng và thực thểthừa Trần Thị Kim Chi 13
PHÂN TÍCH NGHIỆP VỤ Ma trận thực thể - chứcnăng Trần Thị Kim Chi 14
PHÂN TÍCH NGHIỆP VỤ Các bước xây dựng mô hình nghiệp vụ • Mô tả bài toán • Lập bảng phân tích: – Lập danh sách các danh từ và các nhóm động từ+bổ ngữ – Cột nhận xét: • Bỏ qua danh từ chỉ khái niệm hay vật thể • Đánh dấu các danh từ là tác nhân và vật mang tin (thực thể dữ liệu) Trần Thị Kim Chi 15
PHÂN TÍCH NGHIỆP VỤ Các bước xây dựng mô hình nghiệp vụ • Lập danh sách các công việc và các hồ sơ dữ liệu sử dụng • Lập biểu đồ phân rã chức năng • Lập ma trận thực thểdữ liệu - chức năng • Trần Thị Kim Chi 16
PHÂN TÍCH NGHIỆP VỤ Ví dụ : Xây dựng mô hình nghiệp vụ cho bài toán • Một bãi gửi xe có 2 cổng: một cổng xe vào, một cổng xe ra. Người ta chia bãi thành 4 khu dành cho 4 loại xe khác nhau: xe máy, xe buýt, xe tải và công-ten-nơ. • Khi khách đến gửi xe, người coi xe nhận dạng xe theo bảng phân loại, sau đó kiểm tra chỗ trống trong bãi. Nếu chỗ dành cho loại xe đó đã hết thì thông báo cho khách. Ngược lại thì ghi vé đưa cho khách và hướng dẫn xe vào bãi, đồng thời ghi những thông tin trên vé vào sổ xe vào. Trần Thị Kim Chi 17
PHÂN TÍCH NGHIỆP VỤ Ví dụ : Xây dựng mô hình nghiệp vụ cho bài toán • Khi khách lấy xe, người coi xe kiểm tra vé xem vé là thật hay giả, đối chiếu vé với xe. Nếu vé giả hay không đúng xe thì không cho nhận xe. Ngược lại thì viết phiếu thanh toán và thu tiền của khách, đồng thời ghi các thông tin cần thiết vào sổ xe ra. • Khi khách đến báo cáo có sự cố thì kiểm tra xe trong sổ xe vào và sổ xe ra để xác minh xe có gửi hay không và đã lấy ra chưa. Nếu không đúng như vậy thì không giải quyết. Trong trường hợp ngược lại tiến hành kiểm tra xe ở hiện trường. Nếu đúng như sự việc xảy ra thì tiến hành lập biên bản giải quyết và trong trường hợp cần thiết thì viết phiếu chi bồi thường cho khách. Trần Thị Kim Chi 18
PHÂN TÍCH NGHIỆP VỤ Ví dụ : Mô tả bài toán Trần Thị Kim Chi 19
PHÂN TÍCH NGHIỆP VỤ Ví dụ : Lập bảng phân tích Trần Thị Kim Chi 20
PHÂN TÍCH NGHIỆP VỤ Ví dụ : Lập bảng phân tích Trần Thị Kim Chi 21
PHÂN TÍCH NGHIỆP VỤ Cách nhóm các chức năng theo phuơng pháp từ dưới lên Trần Thị Kim Chi 22
PHÂN TÍCH NGHIỆP VỤ Cách nhóm các chức năng theo phuơng pháp từ dưới lên Mô hình phân rã chức năng quản lý trông gửi xe Trần Thị Kim Chi 23
PHÂN TÍCH NGHIỆP VỤ • Danh sách hồ sơ dữ liệu Trần Thị Kim Chi 24
PHÂN TÍCH NGHIỆP VỤ Ma trận thực thể - chứcnăng Trần Thị Kim Chi 25
PHÂN TÍCH NGHIỆP VỤ Ma trận thực thể - chứcnăng Trần Thị Kim Chi 26
PHÂN TÍCH NGHIỆP VỤ Ma trận thực thể - chứcnăng Trần Thị Kim Chi 27
PHÂN TÍCH NGHIỆP VỤ Ma trận thực thể - chứcnăng Trần Thị Kim Chi 28
CÁC ARTIFACTS CẦN TẠO RA TRONG PHÂN TÍCH YÊU CẦU Mô hình phân tích = hệ thống phân tích : . các class phân tích – boundary class – entity class. – control class . các dẫn xuất use-case cấp phân tích : – các lược đồ class phân tích – các lược đồ tương tác (cộng tác, ). – 'flow of events' ở cấp phân tích – các yêu cầu đặc biệt của use-case . các package phân tích . đặc tả kiến trúc (view of analysis model) Trần Thị Kim Chi 29
CÁC WORKERS TRONG PHÂN TÍCH YÊU CẦU Component Architect Use-Case Engineer Engineer chịu trách nhiệm về chịu trách nhiệm về chịu trách nhiệm về Analysis Architecture Use-Case Analysis Analysis Model Description Realization - class package Analysis Trần Thị Kim Chi 30
QUI TRÌNH PHÂN TÍCH YÊU CẦU Architect Architectural Analysis Use-Case Analyze a Engineer Use-Case Analyze a Component Analyze a Engineer Class Package Trần Thị Kim Chi 31
Phân tích kiến trúc : nhận dạng các package phân tích Supplementary Glossary Software Reference Vision Specification Architecture Doc Architecture Document Architectural Analysis Project-Specific Design Model Guidelines Use-Case Model Deployment Model Trần Thị Kim Chi 32
Phân tích kiến trúc : nhận dạng các package phân tích • Mục đích của phân tích kiến trúc là phát họa mô hình phân tích và kiến trúc hệ thống bằng cách nhận dạng các package phân tích, các class phân tích dễ thấy và các yêu cầu đặc biệt chung cho hệ thống. • Các package phân tích giúp tổ chức hệ thống thành những đơn vị nhỏ dễ quản lý. Mỗi package chứa 1 số use-case với tính chất sau : . các use-case hỗ trợ cho cùng 1 qui trình nghiệp vụ. . các use-case hỗ trợ cho cùng 1 actor. . các use-case có quan hệ lẫn nhau : tổng quát hóa, include và extend. • Theo thời gian, khi việc phân tích tiến triển, sự tinh chế cấu trúc các package sẽ tiến triển theo. Trần Thị Kim Chi 33
Phân tích kiến trúc : nhận dạng các class thực thể dễ thấy • Từ các class lĩnh vực hay các class nghiệp vụ nắm bắt yêu cầu, đề nghị 1 số class thực thể quan trọng nhất (từ 10-20). • Các class phân tích còn lại sẽ được nhận dạng trong hoạt động phân tích use-case. • Các yêu cầu đặc biệt cũng được nhận dạng để được xử lý trong các bước sau, chúng gồm : . tính bền vững. Code . sự phân tán & đồng thời. Implementation . các tính chất an toàn dữ liệu. Design . đề kháng với lỗi. Architecture . quản lý giao tác. • Tính chất của mỗi yêu cầu đặc biệt sẽ được cân nhắc sau trong từng class và từng dẫn xuất use-case. Trần Thị Kim Chi 34
Phân tích use-case Logical View Implementation View Analysts/Designers Programmers Structure Software management Use-Case View End-user Functionality Process View Deployment View System engineering System integrators System topology, delivery, Performance, scalability, throughput installation, communication Trần Thị Kim Chi 35
Phân tích use-case Phân tích use-case là để : . nhận dạng các class phân tích có đối tượng của chúng tham gia vào việc thực hiện 'flow of events' của use-case. . phân phối hành vi của use- case bằng cách cho các đối tượng phân tích tương tác nhau. . nắm bắt 1 số yêu cầu đặc biệt cho dẫn xuất use-case. Trần Thị Kim Chi 36
Phân tích use-case : nhận dạng các class phân tích • Trong bước này ta nhận dạng các class điều khiển, biên, thực thể cần thiết để hiện thực use-case và phát họa tên, trách nhiệm, thuộc tính và các mối quan hệ giữa chúng. • Cách nhận dạng các thành phần : . nhận dạng các class thực thể bằng cách chú ý các thông tin trong đặc tả use-case và trong mô hình lĩnh vực. . nhận dạng class biên cơ sở cho mỗi class thực thể vừa tìm được. . nhận dạng class biên trung tâm cho mỗi actor là con người. . nhận dạng class biên trung tâm cho mỗi actor là hệ thống ngoại hay thiết bị I/O. . nhận dạng class điều khiển có trách nhiệm xử lý trong dẫn xuất use-case. • Tập hợp các class phân tích tham gia vào dẫn xuất use-case thành 1 (hay nhiều) lược đồ class. Trần Thị Kim Chi 37
Phân tích use-case : nhận dạng các class phân tích Trần Thị Kim Chi 38
Phân tích use-case : Hiện thực hóa use case (Use-Case Realization) Trần Thị Kim Chi 39
Thí dụ về lược đồ class phân tích cho use-case Pay Invoice Order Configmation Order Handler Invoice Buyer Payment Request UI (from Use-Case Model) Payment Scheduler Payment Request Trần Thị Kim Chi 40
Phân tích use-case : miêu tả sự tương tác giữa các đối tượng phân tích Các bước phân tích Use Case: 1. Bổ sung vào đặc tả use case 2. Hiện thực hóa use case (UC realization) – Tìm các lớp từ hành vi của use case – Phân phối hành vi của use case vào các lớp 3. Phân tích lớp (analysis class) – Mô tả thuộc tính và sự kết hợp – Mô tả nhiệm vụ – Gán cơ chế phân tích 4. Hợp nhất các lớp phân tích Trần Thị Kim Chi 41
Phân tích class • Mục đích của việc phân tích class là : . nhận dạng và duy trì các nghĩa vụ, trách nhiệm của class phân tích dựa vào vai trò của nó trong dẫn xuất use-case. . nhận dạng và duy trì các thuộc tính và các mối quan hệ của class phân tích. . nắm bắt các yêu cầu đặc biệt liên quan đến việc hiện thực class phân tích . Tổ hợp các vai trò mà class đóng trong các dẫn xuất use-case khác nhau sẽ cho ta 1 số nghĩa vụ của class. . Nghiên cứu các lược đồ class và lược đồ tương tác trong các dẫn xuất use-case có class tham gia. . Đôi khi cần nghiên cứu 'flow of events cấp phân tích' của dẫn xuất use-case để tìm thêm các nghĩa vụ các class Trần Thị Kim Chi 42
Phân tích class Trần Thị Kim Chi 43
Phân tích class : nhận dạng mối quan hệ giữa các class • Các đối tượng tương tác nhau thông qua các lược đồ cộng tác. • Mối quan hệ gộp nên được dùng khi các đối tượng miêu tả : . các khái niệm chứa vật lý khái niệm khác (xe chứa tài xế và khách) . các khái niệm được xây dựng từ các khái niệm khác (xe gồm các bánh xe và động cơ). . các khái niệm tạo thành tập hợp ý niệm nhiều đối tượng (gia đình gồm cha, mẹ và con). • Để rút trích các hành vi chung của nhiều class phân tích, ta có thể dùng class tổng quát hóa, nhưng chỉ nên ở cấp ý niệm. Trần Thị Kim Chi 44
Phân tích class : nhận dạng mối quan hệ giữa các class > > System System System Systemboundary information boundary information > > System Use-case System Use-case boundary behavior boundary behaviorcoordination coordination > System Systeminformation information Trần Thị Kim Chi 45
LỚP GIAO DIỆN -BOUNDARY CLASS • Thực hiện chức năng giao tiếp với actor • Thường chứa các phần tử giao diện hoặc điều khiển giao diện người dùng( button, listbox, option group, menu ) • Trong UML được gán stereotype là > • Khó nhận biết các thuộc tính và tác vụ trong mô hình phân tích • Ví dụ: đối với hệ thống quản lý thư viện, các đối tượng biên như: TheMuonForm, BanDocForm, Form_DangNhap Trần Thị Kim Chi 46
LỚP GIAO DIỆN -BOUNDARY CLASS • Là lớp trung gian giữa giao diện và hệ thống bên ngoài • Phân loại – User interface classes – System interface classes – Device interface classes • Cách xác định lớp boundary: • One boundary class per actor/use-case pair Trần Thị Kim Chi 47
LỚP THỰC THỂ • Biểu diễn cho các thực thể xuất hiện một cách tự nhiên trong hệ thống • Thông tin về các đối tượng thực thể có thể phải được lưu trữ lâu dài (database,file ) • Trong UML được gán stereotype là > • Dễ nhận diện các thuộc tính của chúng • Ví dụ: đối với hệ thống quản lý thư viện đã mô tả ở phần trước, nhận diện các đối tượng thực thể như: – Sách, Bạn đọc, Thẻ mượn, Thủ thư. Trần Thị Kim Chi 48
LỚP THỰC THỂ Analysis class stereotype Business-Domain Use Case Model Architectural Analysis Abstractions Glossary Environment independent. Trần Thị Kim Chi 49
LỚP ĐIỀU KHIỂN • Có nhiệm vụ điều khiển các lớp khác hoặc những lớp không phải lớp thực thể và lớp biên • Trong UML, được gán stereotype là > • Lớp biên thường có quan hệ liên kết hoặc phụ thuộc với các lớp khác • Dùng điều phối hành vi use case • Use case phức tạp sẽ yêu cầu nhiều hơn một lớp điều khiển Analysis class Use Case stereotype Trần Thị Kim Chi 50
Phân tích package • Một gói (Package) là một cơ chế có mục đích tổ chức các yếu tố thành các nhóm. Một gói chứa các phần tử mô hình khác. University Artifacts • Một gói có thể được sử dụng: – Để tổ chức các mô hình phát triển. – Là một đơn vị quản lý cấu hình. Dependency relationship Client Package Supplier Package Trần Thị Kim Chi 51
Phân tích package • Mục đích của phân tích package là : . đảm bảo từng package độc lập với các package khác . đảm bảo package hoàn thành mục đích của nó là hiện thực 1 số class lĩnh vực hoặc 1 số use-case. . miêu tả các phụ thuộc sao cho có thể ước lượng ảnh hưởng của các thay đổi trong tương lai. • Cách phân tích: . đảm bảo package chứa các class đúng, cố gắng cho tính kết dính cao bằng cách gộp các class có mối quan hệ chức năng. . hạn chế tối đa sự phụ thuộc giữa các package, phân phối lại các class quá phụ thuộc vào package khác. Trần Thị Kim Chi 52
Phân tích package A A Hierarchy B should be B acyclic A C B A' C Circular dependencies make it impossible to reuse one package without the other. Trần Thị Kim Chi 53
MỤC ĐÍCH CỦA THIẾT KẾ • Giai đoạn thiết kế quan tâm đến HOW: – Thứ tự các thông điệp trao đổi, thông số của thông điệp – Thuật giải của tác vụ đáp ứng – Cấu trúc dữ liệu cho các thuộc tính – Framework(console, document/view ) • Thiết kế cũng chịu ảnh hưởng từ: – Ngôn ngữ lập trình và thư viện lập trình(Vector, List, Map ) – Kiến trúc hệ thống (COM,CORBA, EJB ) thiết lập mô hình động và chi tiết hóa mô hình tĩnh Trần Thị Kim Chi 54
QUI TRÌNH THIẾT KẾ • THIẾT KẾ HÀNH VI – Khái niệm mô hình động – Tương tác giữa các đối tượng – Sự cộng tác – Miêu tả trình tự – Lược đồ trạng thái – Lược đồ hoạt động • HOÀN CHỈNH ĐẶC TẢ TĨNH – Nhận diện thêm một số lớp thiết kế – Đặc tả chi tiết các thuộc tính – Nhận diện chính xác các tác vụ – Hoàn chỉnh lược đồ lớpTrần Thị Kim Chi 55
Summary:Analysis and Design Workflow Analysis Design Trần Thị Kim Chi 56
Analysis and Design Activity Overview Architect Designer Trần Thị Kim Chi 57
Software Architect’s Responsibilities • The Software Architect leads and coordinates Analysis Model Architect technical activities and artifacts. Design Model Software Reference Architecture Implementation Model Deployment Model Architecture Document Trần Thị Kim Chi 58
Designer’s Responsibilities • The designer must know use-case modeling Use-Case techniques, system Designer Realization requirements, and software design techniques. Package Class/Subsystems Trần Thị Kim Chi 59
Analysis and Design in an Iterative Process Start of iteration Use Case A Use Case B Scenarios 1 & 2 Scenario 1 Use Case A Scenario 3 Use-Case Realization A Use-Case Realization A Use-Case Realization B End of iteration Iteration n Iteration n + 1 Trần Thị Kim Chi 60
Review: Analysis and Design Overview • What is the purpose of the Analysis and Design Discipline? • What are the input and output artifacts? • Name and briefly describe the 4+1 Views of Architecture. • What is the difference between Analysis and Design? • What is architecture? Trần Thị Kim Chi 61
PHƯƠNG PHÁP PHÂN TÍCH THIẾT KẾ THEO HƯỚNG ĐỐI TƯỢNG Trần Thị Kim Chi 62
CÁC BƯỚC PHÂN TÍCH VÀ THIẾT KẾ THEO HƯỚNG ĐỐI TƯỢNG Problem statement Create Use case model Draw Activity Diagram (If reqd.) Draw the interaction(sequence) diagrams Draw the class diagram Draw the state chart,object diagram(If required) Draw component &Deployment Diagram Design Document Trần Thị Kim Chi 63
MÔ HÌNH USE CASE • Use case diagram chỉ sự tương tác giữa phần mềm với người dùng hay môi trường bên ngoài • Use case diagram cho biết hệ thống có những chức năng nào, actor nào và chúng liên quan với nhau như thế nào Trần Thị Kim Chi 64
Use Case và yêu cầu chức năng • Use case chính là yêu cầu chức năng, chỉ ra những gì mà hệ thống sẽ làm. • Nên tập trung vào use case ở mức xử lý nghiệp vụ cơ bản (elementary business processes -EBP) • Nhiệm vụ do 1 người thực hiện để đáp ứng 1 sự kiện nghiệp vụ, tạo ra 1 giá trị nghiệp vụ và dữ liệu xác thực Trần Thị Kim Chi 65
Use Cases và mục tiêu người dùng • Use case ở mức EBP được xem là mục tiêu của người dùng • Mục tiêu ở mức thấp hơn được gọi là mục tiêu con (subfunction goal) – Mục tiêu con có chức năng hỗ trợ các mục tiêu chính của người dùng Trần Thị Kim Chi 66
Lợi ích của mô hình Use Cases • Communication • Identification • Verification Use Case Communication Verification Identification End User Domain Expert Users Trần Thị Kim Chi 67
LƯỢC ĐỒ USE CASE • Lược đồ use case là một tập hợp các use case mô tả nhiệm vụ cơ bản (elemental task) mà hệ thống sẽ phải thực thi và mối quan hệ giữa các nhiệm vụ này với thế giới bên ngoài. Hệ thống POS Trần Thị Kim Chi 68
Quy trình xây dựng lược đồ use case 1. Xác định phạm vi hệ thống 2. Xác định các actor chính 3. Xác định các mục tiêu cho mỗi actor 4. Xác định use case đáp ứng mục tiêu của actor. Trần Thị Kim Chi 69
Xác định phạm vi hệ thống • Phân biệt đường biên: xác định đối tượng nào bên ngoài hệ thống – Xác định actor chính và actor hỗ trợ • Ví dụ: Trần Thị Kim Chi 70
Nhận diện các tác nhân (actor) • Khái niệm: Là một đối tượng bên ngoài hệ thống giao tiếp với hệ thống theo một trong các hình thức sau: – Tương tác, trao đổi thông tin với hệ thống hoặc sử dụng chức năng của hệ thống – Cung cấp đầu vào hoặc nhận dữ liệu đầu ra từ hệ thống – Không điều khiển hoạt động của hệ thống Trần Thị Kim Chi 71
Nhận diện các tác nhân (actor) • Việc tìm các actor phụ thuộc vào điểm xuất phát : nếu xuất phát từ mô hình nghiệp vụ hay mô hình lĩnh vực thì việc tìm actor rất đơn giản. Còn nếu xuất phát từ các ý niệm mơ hồ thì hãy trả lời các câu hỏi sau : . Ai là người bắt đầu , kết thúc và sử dụng chức năng của hệ thống? . Ai cần sự hỗ trợ từ hệ thống để thực hiện công việc thường nhật của họ? . Ai phải thực hiện công việc bảo dưỡng, quản trị, quản lý bảo mật và giữ cho hệ thống hoạt động? . Hệ thống sẽ kiểm soát thiết bị phần cứng nào . Hệ thống đang xây dựng cần tương tác với những hệ thống khác không? Hệ thống nào? . Ai hoặc vật thể nào quan tâm đến hoặc chịu ảnh hưởng bởi kết quả mà hệ thống phần mềm tạo ra? • Thường xác định actor trước rồi xác định mục tiêu của actor sau. Đôi khi từ mục tiêu phát hiện ra actor. Trần Thị Kim Chi 72
Actor trong uml • Tên: được mô tả bằng danh từ – VD: Khách hàng, Sinh viên, Web Client, Hệ thống thanh toán • Ký hiệu: • Có thể sử dụng một số icon riêng cho một số actor không phải là người như: Trần Thị Kim Chi 73
Actor trong uml • Phân loại Actor: – Chủ yếu/thứ yếu (Primary/Secondary) – Tích cực/ thụ động(Active/Passive) • Quan hệ giữa các Actor – Tổng quát hóa (generalization) Một dạng của tính kế thừa – Chuyên biệt hóa(Specialization Trần Thị Kim Chi 74
Actor trong uml • Tác nhân chính (primary actor): Ai đang sử dụng hệ thống? Hoặc ai được tác động bởi hệ thống? Hoặc nhóm đối tượng nào cần hệ thống trợ giúp để làm công việc? Trong hệ thống ATM Khách hàng Trong hệ thư viện Thủ thư Trần Thị Kim Chi 75
Actor trong uml • Tác nhân hỗ trợ (secondary actor): những nhóm đối tượng nào hệ thống cần để thực hiện hoạt động của nó (vd: quản trị, dọn dẹp, ) Trong hệ thống ATM Trong hệ thư viện Nhân viên Quản trị hệ vận hành thống • Những phần cứng hoặc hệ thống bên ngoài nào sử dụng hệ thống? Bán hàng Hệ thống thanh toán Trần Thị Kim Chi 76
Actor là thời gian (time) • Thời gian sẽ trở thành actor của hệ thống nếu sau 1 khoảng thời gian nào đó thì nó kích khởi (trigger) một số sự kiện (event). Ví du: • Hệ thống POS, cứ vào 5 giờ chiều ngày thứ bảy thì hệ thống sẽ tự động thống kê tình hình bán hàng trong tuần và in phiếu đặt hàng mới. • Hệ thống đặt vé tự động, cứ 3 giờ chiều mỗi ngày, hệ thống sẽ tự động chọn ngẫu nhiên 1 khách hàng để tặng vé khuyến mãi Trần Thị Kim Chi 77
Actor trong uml • Tác nhân trừu tượng (abstract actor) • Business actor(tác nhân nghiệp vụ): chỉ có trong mô hình RUP, không phải là chuẩn của UML • Lưu ý: Business actor (tác nhân nghiệp vụ) phải liên quan đến business use case Trần Thị Kim Chi 78
Actor trong uml • Quan hệ giữa các Actor Customers – Tổng quát hóa (generalization) Một dạng của tính kế thừa – Chuyên biệt hóa(Specialization Customer Retail Store Online Customer Customer Telephone Customer Trần Thị Kim Chi 79
VÍ DỤ - MÔ TẢ BÀI TOÁN Trần Thị Kim Chi 80
VÍ DỤ - MÔ TẢ BÀI TOÁN • Hệ thống POS (Point-Of-Sale) là một ứng dụng máy tính tự động hóa được dùng để lưu trữ lại hồ sơ bán hàng và quản lý việc thanh toán. Hệ thống được dùng cho các cửa hàng bán lẻ. • Yêu cầu phần cứng chỉ gồm máy tính và máy quét mã vạch (bar code scanner). • Phần mềm có thể liên kết được với các ứng dụng khác như tính thuế, quản lý kho, Hệ thống cũng cần có khả năng hoạt động ngay cả khi có lỗi kết nối với các dịch vụ khác chẳng hạn như khi hệ thống quản lý kho hay dịch vụ thanh toán từ xa, tạm thời không kết nối được thì hệ thống POS vẫn có thể quản lý việc bán hàng và thanh toán bằng tiền mặt. Trần Thị Kim Chi 81
VÍ DỤ - MÔ TẢ BÀI TOÁN Xác định Phạm vi hệ thống: • Ví dụ: Case study POS • Việc thanh toán có được hoàn thành bên trong phạm vi hệ thống không? • Không, cần có 1 actor “ payment authorization service actor” bên ngoài hệ thống Trần Thị Kim Chi 82
VÍ DỤ - MÔ TẢ BÀI TOÁN Trần Thị Kim Chi 83
VÍ DỤ - MÔ TẢ BÀI TOÁN Actor chính và mục tiêu phụ thuộc vào đường biên hệ thống • Tại sao actor chính của use case “Process Sale” là cashier mà không phải là customer? • Tại sao customer hầu như không xuất hiện trong danh sách actor-goal? depends on the system boundary of the system under design Trần Thị Kim Chi 84
VÍ DỤ - MÔ TẢ BÀI TOÁN Bài tập quản lý thư viện, vé tàu, sinh viên Trần Thị Kim Chi 85
USE CASE • Use case: biểu diễn một chức năng của hệ thống phần mềm • Use case được biểu diễn bằng một chuỗi các thông điệp trao đổi bên trong hệ thống và/hoặc một số thông điệp trao đổi với Actor • Quy ước: – Use case luôn được bắt đầu từ thông điệp đến từ actor – Use case phải hoàn tất: chuỗi thông điệp phải được kết thúc bằng kết quả cụ thể – Lỗi hay gặp: chia nhỏ use case thành các chức năng vụn vặt. • Điểm mở rộng là một vị trí trong use case mà tại đó có thể chèn chuỗi sự kiện của một use case khác Trần Thị Kim Chi 86
USE CASE • Use case có thể chứa điều kiện rẽ nhánh, xử lý lỗi, ngoại lệ • Kịch bản (scenario): miêu tả trình tự các sự kiện xảy ra khi use case được thực hiện Trần Thị Kim Chi 87
TÌM USE CASE Việc tìm các use-case phụ thuộc vào điểm xuất phát : nếu xuất phát từ mô hình nghiệp vụ hay mô hình lĩnh vực thì việc tìm use- case rất đơn giản. Còn nếu xuất phát từ các ý niệm mơ hồ thì hãy trả lời các câu hỏi sau : . Actor yêu cầu chức năng gì của hệ thống? . Actor cần phải đọc, tạo, xóa, sửa đổi hoặc lưu trữ thông tin nào của hệ thống? . Actor cần thiết phải được cảnh báo về những sự kiện trong hệ thống, hay actor cần phải báo hiệu cho hệ thống về vấn đề nào đó không? . Hệ thống có thể hỗ trợ một số công việc thường nhật của actor nào đó không? • Một số câu hỏi lưu ý: – Hệ thống cần dữ liệu input/ output nào? Dữ liệu đến từ đâu? – Những khó khăn liên quanTrần đến Thị hiện Kim Chithực của hệ thống? 88
TÌM USE CASE • Đặt tên: dùng động từ + danh từ • Biểu diễn: hình ellipse Tên use case Tên use case • Use case nghiệp vụ (Business Usecase) (RUP) – Phải quan hệ với Business Actor Trần Thị Kim Chi 89
TÌM USE CASE Ví dụ: Ngân hàngABC đưa ra các yêu cầu sau: • Một khách hàng có thể muốn gửi tiền vào, rút tiền ra hoặc đơn giản kiểm tra lại số tiền trong tài khoản của anh ta qua máy tự động rút tiền (ATM). Khi đưa tiền vào hoặc rút tiền ra, cần phải in ra giấy kết quả những giao dịch đã thực hiện cho khách hàng. a) Xác định các actor và use case b) Vẽ lược đồ Use case Bài tập quản lý thư viện, vé tàu,Trần sinh Thị Kimviên Chi Các Use case trong hệ thống90 ATM
CÁC MỐI QUAN HỆ - RELATIONSHIP • Các mối quan hệ: – Giữa actor với actor – Actor với use case – Use case với use case • Các ký hiệu quan hệ và tính chất – Tổng quát hóa (Generalization) – Kết hợp (Associtaion) – Mở rộng (Extend) – Bao gộp (Include) Trần Thị Kim Chi 91
QUAN HỆ TỔNG QUÁT HÓA (Generalization) • Khi một số các Use Case cùng xử lý các chức năng tương tự hoặc có thể liên quan đến nhau theo một phương thức nào đó. • Nhiều use case là trường hợp cụ thể của use case trừu tượng • Kí hiệu: Authenticate WithPassword Authenticate Authenticate WithCard Trần Thị Kim Chi 92
QUAN HỆ KẾT HỢP(Association) • Chỉ ra mối quan hệ có ý nghĩa giữa 2 bên – VD:??? • Một số tính chất liên quan: – Tên của liên kết – Một chiều hay 2 chiều – Bậc: số lượng thực thể tham gia vào liên kết mỗi bên • Biểu diễn trong UML: – Đoạn thẳng (2 chiều) hoặc mũi tên (1 chiều) • Áp dụng các stereotype: – > – > – > – . Trần Thị Kim Chi 93
QUAN HỆ LIÊN KẾT - ASSOCIATION • Liên kết là quan hệ duy nhất giữa Actor và Use case • Có thể một chiều hoặc2 chiều – Actor kích hoạt use case và nhận kết quả trả về: 2 chiều – Actor kích hoạt use case và không quan tâm kết quả trả về: 1 chiều • VD: Trần Thị Kim Chi 94
QUAN HỆ GIAO TIẾP - COMMUNICATE • Là dạng Association mà có stereotype là > • Dùng để liên kết giữa use case và actor mà nó kích hoạt • Ví dụ Trần Thị Kim Chi 95
QUAN HỆ GỘP - INCLUDE • Là dạng association có stereotype là > • Dùng để liên kết giữa2 use cases • Trong use case nguồn có một đ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 nguồn lại tiếp tục. • Ví dụ Giao dịch Đăng nhập > Khách hàng Hệ thống ATM Trần Thị Kim Chi 96
QUAN HỆ MỞ RỘNG - extend • Là dạng association có stereotype là > • Dùng để liên kết giữa 2 use cases • Trong use case nguồn có một điểm mở rộng mà tại đó có thể (hoặc không) chèn use case đích vào • Chèn thêm use case hay không phụ thuộc vào điều kiện rẽ nhánh hoặc tương tác từ actor. • Tại điểm mở rộng, nếu được mở rộng thì diễn tiến của use case nguồn tạm thời dừ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 • VD: Xử lý mượn sách > > Mượn sách từ thư Xử lý từ chối viện thành viên mượn sách Trần Thị Kim Chi 97 Hệ thống thư viện
Ví dụ: Use Case Diagram • The owner of the local video rental store wants to radically change how his video rental business works. Currently, he has the Actor? traditional video rental store where customers become members, come into the video rental store to rent a video, and return the video. With his new business plan, he hopes to increase his profit margin by increasing video sales and reducing staff. Trần Thị Kim Chi 98
Use Case Diagram • In his new business plan, he wants to have the customers do everything online but the picking up and returning the videos. He wants a VRS website that allows the customers to become members or search the video inventory (by video name, actor name, director name, type of video (new release, western, mystery(bí ẩn), drama(truyền hình), comedy(phim hài), children, etc.), or video rating). The VRS website also allows members to log on as a member, search the video inventory (as before), select videos to rent (videos must be located at the store location where the member wants to pick up the videos), modify membership information, and check out the videos. Trần Thị Kim Chi 99
Use Case Diagram • The member can also pay late fees online since videos cannot be rented by a member with outstanding late fees. The paying of late fees and the rental of videos is to be charged to a credit card number provided by the customer in the membership application process. Provided with each rental is a video rental form which lists, for each video rented, the video ID, video name, and the due date and the rental charges charged to the member’s credit card. Rented videos can be returned to any of the owner’s video stores. Rented videos that are not picked up Actor? within 24 hours are returned to the available inventory; however, the rental charged is not removed from the member’s credit card. Trần Thị Kim Chi 100
Use Case Diagram • On the day before a rented video is due to be returned, the VRS will email members with due notices which reminds them that the video is due. This due email will be sent to the member every 3 days after the video’s due date. After 60 days of being past its due date, a $30 charge for each overdue video is processed on the member’s credit card, and an email is sent to the member to notify them of this charge. The length of rental is 5 days. • The pick-up and return of rented videos is only done through a drive-through facility at the video store. The ability for the customer to come into the video rental store to search for and rent videos is no longer available with this new business plan. Trần Thị Kim Chi 101
Use Case Diagram Actor?• The owner of the video store also wants to automate his inventory processing. He can now get newly ordered videos with a video ID (via a bar code) on the video packaging. When new videos arrive at a store, the owner wants to simply scan the video ID which then retrieves the video information from the video distributor via the Internet (the video distributors provide this feature on their websites). All the video information (i.e., its name, rating (e.g., G, PG, R), director, length in minutes, actors) are automatically stored in the store’s video inventory. TrầnThe Thị owner Kim Chi then indicates the store102 location where the video will be placed. When he wants to
Use Case Diagram • Note on rental fees: the amount of the rental fee is determined by its type. New releases are at a rental fee of $3.00. All the remaining types except children’s are at a rental fee of $2.00. Children’s videos are at a rental fee of $1.00. Once a video is no longer considered a new release, the owner changes its type from new release to the appropriate type (western, mystery, drama, comedy, etc.). Trần Thị Kim Chi 103
Use Case Diagram Build use case diagram for a video rental system Potential ACTORS Customers Owner Member Trần Thị Kim Chi 104
Use Case Diagram • Build use case diagram for a video rental system Register Membership Search Potential USE CASES Videos become members select videos Rent rent a video Video pay late fees return videos Pay Late charge to a credit card Fee email member of due notice email member of charge for overdues Return Video Trần Thị Kim Chi 105
Use Case Diagram • Build use case diagram Email Due Potential USE CASES Notices become members rent a video Add New select videos Video modify membership information pay late fees Remove charge to a credit card Video email member of due notice email member of charge for overdues remove videos Modify add videos VideoLocal Trần Thị Kim Chi 106
Use Case Diagram Register as Member Search Customer Videos Trần Thị Kim Chi 107
Use Case Diagram Register as Member Search Customer Videos Rent Videos Pay Late Fee Member Return Clerk Video Trần Thị Kim Chi 108
Use Case Diagram Register as Member Search Customer Videos Rent Videos Pay Late Fee Member Return Clerk Video Add New Distributor Video Remove Video Modify Owner Trần VideoThị Kim Chi 109
Use Case Diagram Register as Member Search Customer Videos Rent Videos Pay Late Fee Member Return Clerk Video Email Due Notices Add New Timer Distributor Video Remove Video Modify Owner Trần VideoThị Kim Chi 110
Use Case Diagram Register as Member Search Customer Videos Login Rent Videos Pay Late Fee Member Return Clerk Video Email Due Notices Add New Timer Distributor Video Remove Video Modify Owner Trần VideoThị Kim Chi 111
Use Case Diagram Print Rental Register as Form Member Search Customer Videos Login Rent Videos Pay Late Fee Member Return Clerk Video Email Due Notices Add New Timer Distributor Video Remove Video Modify Owner Trần VideoThị Kim Chi 112
Use Case Diagram Print Rental Register as Form Member Search Customer Videos Login Rent Videos Pay Late Fee Member Return Clerk Video Email 60 Day Notice Email Due > Notices Add New Timer Distributor Video Remove Video Modify Owner Trần VideoThị Kim Chi 113
Case Study 1 - safe home access system BàiTrần Thị tập Kim quản Chi lý thư viện, vé tàu, sinh114 viên
Case Study 1 - safe home access system Trần Thị Kim Chi 115
Case Study 1 - safe home access system actor và use case của case study Trần Thị Kim Chi 116
Case Study 1 - safe home access system actor và use case của case study Trần Thị Kim Chi 117
Case Study 1 - safe home access system actor và use case của case study Trần Thị Kim Chi 118
Case Study 2- Limited ATM Corp • A Bank wishes to introduce ATM service to provide limited facilities to her customers. Customers may get ATM cards on request. Users may only view their balance or withdraw money using these cards. Cards are given for only one account, but an account may be accessed using different cards. A card may be blocked temporarily or permanently by the Bank (e.g. If it is lost). A PIN is associated with each card to verify the authenticity of the user. There is an Over Draft (OD) limit associated with each checking account. Theoretically, any amount may be withdrawn from a checking account at any time (provided it is less than the balance + OD limit and assume always enough money is left in the machine), but there is a withdrawal limit (for a day) for each savings account. There is no OD facility for a savings account. Trần Thị Kim Chi 119
Case Study 2- Limited ATM Corp • The personal information of the customers and their account details are already maintained by the Bank’s main system. A subsystem is required to handle the ATM’s functionality. There will be two hardware systems Card reader and Money dispenser communicating with this subsystem. The card reader reads the Card-No and passes it to the system. It is also able to eject the card when an eject signal is received from the system. Similarly the money dispenser is able to dispense the required amount of money. Trần Thị Kim Chi 120
Case Study - Limited ATM Corp • The Limited ATM system is required to provide at least the following operations. – Enter a new card detail – Modify the validity of card – Check the validity of the card – Check the authenticity of the user – View the balance of the account – Withdraw money from the account – Withdrawal information will be stored for later use – (Includes date, time, machineNo, cardNo, and amount) – Change the PIN of a card – Here the first two operations are to be carried out by the Bank and the rest by the user. Trần Thị Kim Chi 121
BÀI TẬP - MÔ TẢ BÀI TOÁN Xây dựng mô hình nghiệp vụ cho bài toán • Một bãi gửi xe có 2 cổng: một cổng xe vào, một cổng xe ra. Người ta chia bãi thành 4 khu dành cho 4 loại xe khác nhau: xe máy, xe buýt, xe tải và công-ten-nơ. • Khi khách đến gửi xe, người coi xe nhận dạng xe theo bảng phân loại, sau đó kiểm tra chỗ trống trong bãi. Nếu chỗ dành cho loại xe đó đã hết thì thông báo cho khách. Ngược lại thì ghi vé đưa cho khách và hướng dẫn xe vào bãi, đồng thời ghi những thông tin trên vé vào sổ xe vào. Trần Thị Kim Chi 122
BÀI TẬP - MÔ TẢ BÀI TOÁN • Khi khách lấy xe, người coi xe kiểm tra vé xem vé là thật hay giả, đối chiếu vé với xe. Nếu vé giả hay không đúng xe thì không cho nhận xe. Ngược lại thì viết phiếu thanh toán và thu tiền của khách, đồng thời ghi các thông tin cần thiết vào sổ xe ra. • Khi khách đến báo cáo có sự cố thì kiểm tra xe trong sổ xe vào và sổ xe ra để xác minh xe có gửi hay không và đã lấy ra chưa. Nếu không đúng như vậy thì không giải quyết. Trong trường hợp ngược lại tiến hành kiểm tra xe ở hiện trường. Nếu đúng như sự việc xảy ra thì tiến hành lập biên bản giải quyết và trong trường hợp cần thiết thì viết phiếu chi bồi thường cho khách. Yêu cầu: Vẽ biểu đồ usecase Trần Thị Kim Chi 123
ĐẶC TẢ USE CASE (Use case specification) • Use caselà 1tập hợp các scenario thành công cũng như thất bại có liên quan đến các actor khi sử dụng hệ thống. Tên use case – Số thứ tự use case (nếu có) Miêu tả ngắn gọn use case Dòng chảy sự kiện (dòng logic chung) Dòng hành động chính (dòng logic chi tiết, các hoạt động bình thường) Dòng hành động thay thế (chuỗi logic hay thế, các hoạt động bất thường) Điều kiện thoát (Use case kết thúc như thế nào) Các yêu cầu đặc biệt Điều kiện trước (điều xảy ra trước khi use thực hiện) Điều kiện sau (điều xảy ra sauTrần Thị khi Kim use Chi case thực hiện) 124
ĐẶC TẢ USE CASE (Use case specification) Trần Thị Kim Chi 125
ĐẶC TẢ USE CASE (Use case specification) Trần Thị Kim Chi 126
ĐẶC TẢ USE CASE (Use case specification) Trần Thị Kim Chi 127
ĐẶC TẢ USE CASE Để viết đặc tả use case hiệu quả Nên dùng câu chủ động (active) và viết theo quan điểm của người dùng. .“The capability is provided for users to log in, using a password- protected authorization scheme” Dạng passive voice .“The user enters her username and password, and then clicks the Login button. The system looks up the user profile using the username and checks the password. The system then logs in the user” Dạng active Trần Thị Kim Chi 128
ĐẶC TẢ USE CASE Để viết đặc tả use case hiệu quả • UC mô tả sự tương tác 2 chiều bao gồm: system’s behavior + user’s behavior. • Một UC chứa nhiều bước (step) khác nhau, mỗi bước liên quan đến 1sự kiện (event) và 1đáp ứng (response): the user’s action and the system’s reaction, or vice versa So a use case really describes a dialogue between a user and the system. Trần Thị Kim Chi 129
ĐẶC TẢ USE CASE Để viết đặc tả use case hiệu quả • Nên phác họa kịch bản của UC bằng hình vẽ (storyboard) hay bằng text • The user clicks the Edit Shopping Cart button, and the system shows the Edit Shopping Cart page with a list of books in the user’s shopping cart. The user selects one of the books, changes the quantity, and clicks the Update button. The system shows the page with the quantitiesTrần Thị Kim Chiand price totals updated130.
Use Case Specification: Natural Language Example Use Case 1. Withdraw Money The system displays the account types available to be withdrawn from and the user indicates the desired type. The system asks for the amount to be withdrawn and the user specifies it. Next, the system debits the user’s account and dispenses the money. The user removes the money, the system prints a receipt, and the user removes the receipt. Then the system displays a closing message and dispenses the user’s ATM card. After the user removes his card, the system displays the welcome message. Trần Thị Kim Chi 131
system name ATM system boundary System primary actor 1 Withdraw secondary actor Money 2 Bank Deposit Customer Money Customer Accounts role 3 Database Transfer Money association > use case Balance alternative actor notation stereotype Trần Thị132 Kim Chi
Use Case Specification Template* Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main Scenario Step Action Extensions Step Branching Action Open Issues Trần Thị136 Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template* Number Unique use case number Name Brief verb-noun phrase Summary Brief summary of use case major actions Priority 1-5 (1 = lowest priority, 5 = highest priority) Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main Scenario Step Action Extensions Step Branching Action Open Issues Trần Thị137 Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template* Number Name Summary Priority Preconditions What needs to be true before the use case “executes” Postconditions What will be true after the use case successfully “executes” Primary Actor(s) Precondition:Secondary Actor(s) y != 0 Precondition: None Trigger Postcondition:Main Scenario x /Step y Action Postcondition: if y==0 “Illegal”, else x / y double divide(double x, double y) { double divide(double x, double y) { Extensionsreturn (x / y); Step Branching Action if (y == 0) cout << } Open Issues Trần Thị138“Illegal Kim Chi \n”; *Adapted from A. Cockburn, “Basic Use Case Template” else return (x / y);
Actor Use Case Specification Template* Number • Anyone or anything with Name behavior Summary • May be a person or system Priority Preconditions • Primary: The stakeholder Postconditions who or which initiates an Primary Actor(s) Primary actor name(s) interaction with the system to Secondary Actor(s) Secondary actor name(s)achieve a goal. Is generally a Trigger category of individuals (a Main Scenario Step Action role). • Secondary: Provides a service to the system. Is Extensions Step Branching Actionalmost never a person. Open Issues Trần Thị139 Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template* Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger The action that caused the use case to be invoked Main Scenario Step Action Step # This is the “main success scenario” or “happy path” Step # Description of steps in successful use case “execution” Step # This should be in a “system-user-system, etc.” format Extensions Step Branching Action Open Issues Trần Thị140 Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template* Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Extension Trigger • Could be an optional path(s) Main Scenario Step Action • Could be an error path(s) • Denoted in use case Extensions Step Branching Actiondiagrams (UML) by Step # Alternative paths > that the use case may take Open Issues Trần Thị141 Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template* Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main Scenario Step Action Extensions Step Branching Action Open Issues Issue # Issues regarding the use case that need resolution Trần Thị142 Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template* Number Unique use case number Name Brief noun-verb phrase Summary Brief summary of use case major actions Priority 1-5 (1 = lowest priority, 5 = highest priority) Preconditions What needs to be true before use case “executes” Postconditions What will be true after the use case successfully “executes” Primary Actor(s) Primary actor name(s) Secondary Actor(s) Secondary actor name(s) Trigger The action that causes this use case to begin Main Scenario Step Action Step # This is the “main success scenario” or “happy path.” Description of steps in successful use case “execution” This should be in a “system-user-system, etc.” format. Extensions Step Branching Action Step # Alternative paths that the use case may take Open Issues Issue # Issues regarding the use case that need resolution Trần Thị143 Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template Example Number 1 Name Withdraw Money Summary User withdraws money from one of his/her accounts Priority 5 Preconditions User has logged into ATM Postconditions User has withdrawn money and received a receipt Primary Actor(s) Bank Customer Secondary Actor(s) Customer Accounts Database Continued Trần Thị Kim Chi 144
Trigger User has chosen to withdraw money Main Scenario Step Action 1 System displays account types 2 User chooses account type 3 System asks for amount to withdraw 4 User enters amount 5 System debits user’s account and dispenses money 6 User removes money 7 System prints and dispenses receipt 8 User removes receipt 9 System displays closing message and dispenses user’s ATM card 11 User removes card 10 System displays welcome message Extensions Step Branching Action 5a System notifies user that account funds are insufficient 5b System gives current account balance 5c System exits option Open Issues 1 Should the system ask if the user wants to see the balance? Trần Thị145 Kim Chi
BÀI TẬP USE CASE 1. Với hệ thống đặt vé máy bay, người dùng có thể đặt vé, thay đổi hay huỷ vé. Use case của hệ thống là gì?? 2. Nếu cần xây dựng hệ thống quản lý máy ATM, thì use case “withdrawing cash” có những scenario nào? Trần Thị Kim Chi 146
Phân tích package • Một gói (Package) là một cơ chế có mục đích tổ chức các yếu tố thành các nhóm. Một gói chứa các phần tử mô hình khác. University Artifacts • Một gói có thể được sử dụng: – Để tổ chức các mô hình phát triển. – Là một đơn vị quản lý cấu hình. Dependency relationship Client Package Supplier Package Trần Thị Kim Chi 147
Phân tích package • Mục đích của phân tích package là : . đảm bảo từng package độc lập với các package khác . đảm bảo package hoàn thành mục đích của nó là hiện thực 1 số class lĩnh vực hoặc 1 số use-case. . miêu tả các phụ thuộc sao cho có thể ước lượng ảnh hưởng của các thay đổi trong tương lai. • Cách phân tích: . đảm bảo package chứa các class đúng, cố gắng cho tính kết dính cao bằng cách gộp các class có mối quan hệ chức năng. . hạn chế tối đa sự phụ thuộc giữa các package, phân phối lại các class quá phụ thuộc vào package khác. Trần Thị Kim Chi 148
Phân tích package A A Hierarchy B should be B acyclic A C B A' C Circular dependencies make it impossible to reuse one package without the other. Trần Thị Kim Chi 149
PACKAGE USE CASE • Khi nào dùng: – Khi hệ thống lớn,sơ đồ use case phức tạp – Package: gom một số use case liên quan tạo nên một sub system của hệ thống • Ký hiệu: Tên • Ví dụ: hệ thống ATM gồm các package Trần Thị Kim Chi 150
PACKAGE USE CASE Trần Thị Kim Chi 151
MÔ HÌNH HÓA NGHIỆP VỤ-TỔNG QUAN • Mô hình hóa nghiệp vụ (Business Modeling) – Là kỹ thuật mô hình hóa tiến trình nghiệp vụ – Mô hình hóa các chức năng của tổ chức – Quan tâm đến góc nhìn chức năng. Không phân biệt các tiến trình nghiệp vụ sẽ được tự động hóa hay thực hiện thủ công • Biểu diễn mô hình nghiệp vụ bằng biểu đồ nghiệp vụ – Chỉ ra tương tác giữa các tiến trình nghiệp vụ với các vai trò (roles) thực hiện nghiệp vụ như customers hay vendors – Biểu diễn vai trò bên ngoài nghiệp vụ • Hai lĩnh vực của mô hình hóa nghiệp vụ – Biên của tổ chức và nó cần giao tiếp với ai? – Luồng công việc bên trong tổ chức và tối ưu nó như thế nào? Trần Thị Kim Chi 152
MÔ HÌNH HÓA NGHIỆP VỤ-TỔNG QUAN • Không tập trung vào mô hình hóa hệ thống sẽ xây dựng • Tập trung vào nghiệp vụ trên hệ thống – Mục tiêu là để hiểu rõ môi trường nghiệp vụ trước khi xây dựng hệ thống • Mô hình hóa nghiệp vụ – Nghiên cứu về tổ chức – Khảo sát cấu trúc tổ chức, quan sát các vai trò trong tổ chức và quan hệ của chúng với nhau như thế nào. – Khảo sát luồng công việc trong tổ chức • Tiến trình chính, họ làm việc thế nào • Tính hiệu quả • Các hạn chế • Nghiên cứu các tổ chức bên ngoài và quan hệ với chúng? • Làm tài liệu về các thông tin bằng mô hình nghiệp vụ của UML Trần Thị Kim Chi 153
MÔ HÌNH HÓA NGHIỆP VỤ-TỔNG QUAN • Khi nào không cần mô hình hóa nghiệp vụ? – Khi đã hiểu biết rõ ràng cấu trúc, mục đích tác nghiệp, stackholders của tổ chức – Khi xây dựng phần mềm sử dụng cho một phần nhỏ của tổ chức, không ảnh hưởng đến nghiệp vụ khác – Luồng công việc khá rõ ràng và có tài liệu đầy đủ – Khi không có đủ thời gian!!!!???? Trần Thị Kim Chi 154
CÁC KHÁI NIỆM CƠ BẢN CỦA MÔ HÌNH HÓA NGHIỆP VỤ (Business Modeling) • Các khái niệm cơ bản bao gồm – Business actors – Business workers – Business use case – Biểu đồ Business use case – Quan hệ giao tiếp giữa Business use case và Business actor – Thực thể Business – Các biểu đồ hoạt động Trần Thị Kim Chi 155
TÁC NHÂN NGHIỆP VỤ • Ai đó, cái gì đó bên ngoài tổ chức nhưng tương tác với nó – Customers, Investors, Suppliers – Có thể là nguời hay nhóm nguời • Tìm kiếm tác nhân nghiệp vụ? – Quan sát phạm vi dự án để tìm ra những gì nằm ngoài dự án – Những gì (ai, cái gì) nằm ngoài dự án có liên quan đến nghiệp vụ • Nghiên cứu tài liệu mô tả dự án, thị trường tổ chức, mục tiêu nghiệp vụ để xác định thực thể bên ngoài liên quan – Thí dụ: Hãng hàng không liên quan đến nhà sản xuất máy bay, nhà sản xuất đồ ăn uống cho khách, khách hàng, hiệp hội hàng không • Có 2 loại: tác nhân thực hiện các công việc bên trong hệ thống và các tác nhân tương tác trực tiếp với các tác nhân bên ngoài hệ thống. Trần Thị Kim Chi 156
WORKER NGHIỆP VỤ • Là vai trò (role) trong tổ chức – Một người có thể có nhiều vai trò – không phải là chức vụ • Mô tả worker – Có trách nhiệm gì? – Kỹ năng cần có để thực hiện trách nhiệm? – Tương tác với worker nào? – Tham gia vào luồng công việc nào? – Trách nhiệm của worker trong luồng công việc • Tìm kiếm worker nghiệp vụ – Quan sát phạm vi dự án – bắt đầu từ biểu đồ tổ chức – Khi đã có danh sách worker thì làm tài liệu cho chúng • Thí dụ worker nghiệp vụ trong công ty hàng không – Phi công, người dẫn đường,Trần thợ Thị máy,Kim Chi tiếp viên, nhân viên an ninh 157
USE CASE NGHIỆP VỤ • Business use case là nhóm các luồng công việc liên quan có ý nghĩa với tác nhân nghiệp vụ – Cho biết tổ chức làm gì – Tập các ca nghiệp vụ mô tả đầy đủ nghiệp vụ của tổ chức • Ðặt tên: Theo hình thức “ ”: VD: “Price Products” • Làm tài liệu luồng công việc – Thí dụ với use case nghiệp vụ Price Products • Nhân viên yêu nguời cầu quản lý cung cấp danh sách các mặt hàng mới cần định giá • Nhân viên kiểm tra hóa đơn kho để biết phải trả cho kho bao nhiêu kho hàng bán • Nhân viên cộng thêm 10% để có giá bán • Nhân viên trình giá để nguời quản lý phê duyệt • Nhân viên làm các thẻ sảnTrần phẩm Thị Kim Chi 158 • Gắn thẻ giá sản phẩm vào từng sản phẩ
TƯƠNG TÁC GIỮA CÁC PHẦN TỬ • Biểu diễn tương tác – Quan hệ association: • giữa tác nhân nghiệp vụ, worker nghiệp vụ với use case nghiệp vụ • mũi tên cho biết ai khởi xướng tiến trình – Quan hệ generalization • chỉ ra cấu trúc kế thừa giữa các phần tử mô hình nghiệp vụ  áp dụng cho hai hay nhiều phần  tử tương tự nhau Trần Thị Kim Chi 159
BIỂU ĐỒ USE CASE NGHIỆP VỤ • Chỉ ra mô hình đầy đủ – cái công ty làm – ai ở trong công ty – ai ở ngoài công ty • Cho biết phạm vi của tổ chức • Nếu có nhiều use case nghiệp vụ có thể tạo nhiều biểu đồ UC nghiệp vụ và mỗi biểu dồ chứa tập các UC nghiệp vụ • Mũi tên đi từ tác nhân nghiệp vụ và worker nghiệp vụ đến • UC nghiệp vụ cho thấy ai khởi động tiến trình nghiệp vụ. Trần Thị Kim Chi 160
THỰC THỂ NGHIỆP VỤ • Business entity là đối tuợng mà tổ chức sử dụng để điều hành tác nghiệp hay sản xuất. • Thực thể bao gồm tất cả những gì mà worker nghiệp vụ có liên quan hàng ngày – Thí dụ: Sales Order, Account, Shiping Box, Contract, Ghim giấy • Trả lời các câu hỏi sau để tìm thực thể nghiệp vụ: – Sản phẩm của công ty? – Công ty có các dịch vụ? – Công ty phải mua vật liệu gì để sản xuất? – Khách hàng cung cấp/nhận gì từ công ty? – Các worker nghiệp vụ trao đổi nhau cái gì khi sản xuất? • Tìm kiếm thực thể nghiệp vụ ở nơi khác – Các danh từ trong use case nghiệp vụ Trần Thị Kim Chi 161
THỰC THỂ NGHIỆP VỤ • Ví dụ: • Bổ sung các thuộc tính cho thực thể nghiệp vụ – Thí dụ, thực thể nghiệp vụ Account có các thuộc tính account number, account type, balance, date opened, status – Chú ý rằng chưa có thiết kế CSDL ở đây – Chỉ bổ sung các thuộc tính để dễ hiểu nghiệp vụ Trần Thị Kim Chi 162
ÐƠN VỊ TỔ CHỨC • Ðơn vị tổ chức (Organization Unit) là tập hợp các worker nghiệp vụ, thực thể nghiệp vụ và các phần tử mô hình nghiệp vụ khác • Là cơ chế đuợc sử dụng để tổ chức mô hình nghiệp vụ • Nhiều công ty tổ chức theo phòng, ban, đơn vị – Mỗi chúng được mô hình hóa như đơn vị tổ chức – Mỗi đơn vị tổ chức sẽ bao gồm các worker nghiệp vụ bên trong phòng, ban, đơn vị đó. • Biểu tượng Trần Thị Kim Chi 163
BIỂU ĐỒ USE CASE NGHIỆP VỤ • Thực tế: luồng công việc (Workflow) không đơn giản mà có nhiều logíc điều kiện – worker nghiệp vụ có thể thực hiện một vài actions khi điều kiện A xảy ra và thực hiện một vài actions khác khi điều kiện B xảy ra – hãy sử dụng biểu đồ hoạt động (Activity Diagram) để mô hình hóa các luồng công việc • Nếu trong biểu đồ UC nghiệp vụ có nhiều UC nghiệp vụ, tác nhân nghiệp vụ và worker nghiệp vụ thì có thể nhóm chúng thành các đơn vị tổ chức (Organizational Units) – tổ chức lại mô hình để dễ dọc và dễ hiểu – sau đó xây dựng biểu đồ UC nghiệp vụ cho từng đơn vị tổ chức Trần Thị Kim Chi 164
BIỂU ĐỒ USE CASE NGHIỆP VỤ Ví dụ: các loại use case nghiệp vụ của một tổ chức nhà hàng Trần Thị Kim Chi 165
BIỂU ĐỒ USE CASE NGHIỆP VỤ Ví dụ: mô hình use case mô tả nghiệp vụ của siêu thị Co-op Mart Trần Thị Kim Chi 166
CÂU HỎI VÀ BÀI TẬP 1. Hỏi: Một tác nhân (Actor) trong một Use Case luôn là một con người Đáp: Sai, tác nhân là một người hoặc một vật nào đó tương tác với hệ thống. 2. Hỏi: Hệ thống khác cũng có thể đóng vai trò tác nhân trong một Use Case? Đáp: Đúng 3. Hỏi: Mỗi hệ thống chỉ có một Use Case? Đáp: Sai 4. Hỏi: Biểu đồ Use case mô tả chức năng hệ thống? Đáp: Đúng Trần Thị Kim Chi 167
CÂU HỎI VÀ BÀI TẬP Trần Thị Kim Chi 168
CÂU HỎI VÀ BÀI TẬP • Đặc tả Use case cho các bài toán nghiệp vụ trên Trần Thị Kim Chi 169
CÂU HỎI VÀ BÀI TẬP • Là trưởng ban It của trường ĐH KHTN, bạn được yêu cầu phát triển một hệ thống đăng ký học phần mới hệ thống mới cho phép sinh viên đăng ký học phần và xem phiếu điểm từ máy tính cá nhân được kết nối vào mạng nội bộ của trường. Các giảng viên cũng có thể truy cập hệ thống này để đăng ký lớp dạy và nhập điểm cho các môn học. • Trường sẽ giữ lại CSDL sẵn có về danh mục học phần mà trong đó lưu trữ toàn bộ thông tin về học phần. Đây là CSDL quan hệ và có thể truy cập bằng các câu lệnh SQL thông qua các server của trường. Hệ thống mới sẽ đọc các thông tin học phần trên CSDL cũ nhưng sẽ không cập nhập chúng. Phòng đào tạo sẽ tiếp tục duy trì các thông tin học phần thông qua hệ thống khác. Trần Thị Kim Chi 170
CÂU HỎI VÀ BÀI TẬP • Ở đầu mỗi học kỳ, sinh viên có thể yêu cầu danh sách các học phần được mở trong học kỳ đó. Thông tin về mỗi học phần, ví dụ như là tên giáo sư, khoa, và các môn học phần tiên quyết sẽ được cung cấp để giúp sinh viên chọn lựa. • Hệ thống mới cho phép sinh viên được chọn 4 học phần được mở cho học kỳ tới. Mỗi sinh viên có thể đưa ra hai môn học thay thế trong trường hợp không thể đăng ký theo nguyện vọng chính. Các học phần được mở tối đa là 100 và tối thiểu là 30 sinh viên. Các học phần có ít hơn 30 sinh viên sẽ bị hủy bỏ. • Đầu mỗi học kỳ, sinh viên có một khoảng thời gian để thay đổi các học phần đã đăng ký. Sinh viên chỉ có thể thêm hay hủy các học phần đăng kí trong khoảng thời gian này. Trần Thị Kim Chi 171
CÂU HỎI VÀ BÀI TẬP • Khi quá trình đăng ký đã hoàn tất cho mỗi sinh viên, hệ thống đăng kí sẽ gửi thông tin tới hệ thống thanh toán (billing system) để sinh viên có thể đóng học phí. Nếu một lớp bị hết chỗ trong quá trình đăng ký, sinh viên sẽ được thông báo về sự thay đổi trước khi xác nhận việc đăng ký học • Ở cuối học kỳ, sinh viên có thể truy cập vào hệ thống để xem phiếu điểm. Vì thông tin về điểm của sinh viên phải được giữ kín, nên hệ thống cần có cơ chế bảo mật để ngăn cản việc truy cập không hợp lệ • Các giảng viên có thể truy cập vào hệ thống để đăng ký những học phần mà họ sẽ dạy. Họ có thể xem danh sách các sinh viên đã đăng ký vào lớp của họ, cũng như nhập điểm sau mỗi khóa học. Trần Thị Kim Chi 172
CÂU HỎI VÀ BÀI TẬP Lập bảng chú giải (Glossary) của ứng dụng Course Registration: • Course (Học phần): Một môn học được dạy trong trường. • Course Offering (Lớp): Một lớp học cụ thể được mở trong mỗi học kỳ cụ thể cùng một học phần cụ thể được mở song song nhiều lớp trong mỗi học kỳ. Thông tin gồm cả ngày học trong tuần và giờ học. • Course Catalog (Danh mục học phần): Danh mục đầy đủ của tất cả các học phần được dạy trong trường. • Faculty: Toàn bộ cán bộ giảng dạy của trường. • Finance System (Hệ thống thanh toán): Hệ thống dùng để xử lý các thông tin thanh toán học phí. Trần Thị Kim Chi 173
CÂU HỎI VÀ BÀI TẬP Lập bảng chú giải (Glossary) của ứng dụng Course Registration: • Grade (Điểm số): Điểm của mỗi sinh viên trong một lớp cụ thể. • Professor (Giáo sư): Người giảng dạy trong trường. • Report Card (Phiếu điểm): Toàn bộ điểm số cho tất cả học phần một sinh viên đã học trong một học kỳ xác định. • Roster (Danh sách sinh viên đăng ký): Tất cả sinh viên đăng ký vào một lớp học cụ thể. • Student (Sinh viên): Người đăng ký học các lớp của trường. • Schedule (Lịch học): Các học phần mà sinh viên đã chọn học trong học kỳ hiện tại. • Transcript (Bản sao học bạ): Bản sao tất cả điểm cho tất cả các học phần của một sinh viên cụ thể được chuyển cho hệ thống thanh toán để hệ thốngTrần Thị Kimnày Chi lấp hóa đơn cho mỗi sinh174 viên.
CÂU HỎI VÀ BÀI TẬP • Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán nghiệp vụ trên Trần Thị Kim Chi 175
CÂU HỎI VÀ BÀI TẬP • Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán nghiệp vụ trên Trần Thị Kim Chi 176
CÂU HỎI VÀ BÀI TẬP • Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán nghiệp vụ trên Trần Thị Kim Chi 177
CÂU HỎI VÀ BÀI TẬP • Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán nghiệp vụ trên Lap BC Trần Thị Kim Chi 178
CÂU HỎI VÀ BÀI TẬP • Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán nghiệp vụ trên Trần Thị Kim Chi 179
CÂU HỎI VÀ BÀI TẬP • Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán nghiệp vụ trên Trần Thị Kim Chi 180
CÂU HỎI VÀ BÀI TẬP • Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán nghiệp vụ trên Trần Thị Kim Chi 181
182 Trần Thị Kim Chi