Bài giảng Phân tích và thiết kế hệ thống - Chương 4: Phân tích và thiết kế hướng đối tượng - Trần Thị Kim Chi

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Ế Supplementary Specification Use-Case Model Data Model Architecture Document Analysis and Design Glossary Design Model Trần Thị Kim Chi 4 ANALYSIS VERSUS DESIGN Analysis Design  Focus on understanding the problem  Idealized design  Behavior  System structure  Functional requirements  A small model  Focus on understanding the solution  Operations and attributes  Performance  Close to real code  Object lifecycles  Nonfunctional requirements  A large model Trần Thị Kim Chi 5 Analysis and Design Are Not Top-Down or Bottom-Up Design Classes Subsystems Use Cases Bottom Up Top Down (Define a middle level) Analysis and Design Analysis Classes Trần Thị Kim Chi 6 • 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. Mục đích của phân tích yêu cầu 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ức nă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ức nă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ức năng Trần Thị Kim Chi 25 PHÂN TÍCH NGHIỆP VỤ Ma trận thực thể - chức năng Trần Thị Kim Chi 26 PHÂN TÍCH NGHIỆP VỤ Ma trận thực thể - chức năng Trần Thị Kim Chi 27 PHÂN TÍCH NGHIỆP VỤ Ma trận thực thể - chức nă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 Engineer Analysis Model Use-Case Engineer Architect Architecture Description Use-Case Realization - Analysis Analysis class Analysis package chịu trách nhiệm về chịu trách nhiệm về chịu trách nhiệm về Trần Thị Kim Chi 30 QUI TRÌNH PHÂN TÍCH YÊU CẦU Architect Use-Case Engineer Architectural Analysis Analyze a Use-Case Analyze a Class Analyze a Package Component Engineer 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 Specification Glossary Use-Case Model Architectural Analysis Design Model Reference Architecture Deployment Model Vision Document Software Architecture Doc Project-Specific Guidelines 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.  sự phân tán & đồng thời.  các tính chất an toàn dữ liệu.  đề kháng với lỗi.  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. Architecture Design Implementation Code Trần Thị Kim Chi 34 Phân tích use-case Process View Deployment View Logical View Use-Case View Implementation View End-user Functionality Programmers Software management Performance, scalability, throughput System integrators System topology, delivery, installation, communication System engineering Analysts/Designers Structure 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 Payment Request UI Order Configmation Order Handler Payment Request Payment Scheduler Invoice Buyer (f rom Use-Case Model) 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 boundary Use-case behavior coordination System information > > > System information > System boundary > System boundary Use-case behavior coordination System information System information System boundary 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Ể Glossary Business-Domain Model Environment independent. Analysis class stereotype Use Case Architectural Analysis Abstractions 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 Use Case Analysis class 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. • 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. University Artifacts Client Package Supplier Package Dependency relationship 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 C A B Hierarchy should be acyclic A B C A' Circular dependencies make it impossible to reuse one package without the other. A B 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 Architect Software Architecture Document • The Software Architect leads and coordinates technical activities and artifacts. Reference Architecture Analysis Model Design Model Deployment ModelImplementation Model Trần Thị Kim Chi 58 Designer’s Responsibilities Designer Use-Case Realization Package Class/Subsystems • The designer must know use-case modeling techniques, system requirements, and software design techniques. Trần Thị Kim Chi 59 Analysis and Design in an Iterative Process Iteration n Iteration n + 1 Use Case A Scenarios 1 & 2 Use-Case Realization A Start of iteration End of iteration Use Case B Scenario 1 Use-Case Realization A Use Case A Scenario 3 Use-Case Realization B 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 dù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 dùng • Use case ở mức EBP được xem là mục tiêu của người dùng • Mục tiêu ở