Bài giảng Phân tích và thiết kế hệ thống thông tin: Chương 3 Phân tích và thiết kế hệ thống thông tin theo hướng đối tượng cung cấp cho người học những kiến thức như: Phân tích yêu cầu hệ thống; Đặc tả các yêu cầu của hệ thống; Thiết kế hướng đối tượng; Các nhóm mẫu thiết kế nội dung; Quá trình phát triển phần mềm hướng đối tượng; Thiết kế giao diện, báo biểu, an toàn hệ thống. Mời các bạn cùng tham khảo!
CHƯƠNG PHÂN TÍCH VÀ THIẾT KẾ HTTT THEO HƯỚNG ĐỐI TƯỢNG ANALYSIS AND DESIGN INFORMATION SYSTEMS IN OBJECT ORIENTED PGS.TS Nguyễn Mậu Hân Khoa CNTT-ĐHKH HUẾ nmhan2005@yahoo.com 196 NỘI DUNG 3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 3.2 PHÂN TÍCH YÊU CẦU HỆ THỐNG 3.3 ĐẶC TẢ CÁC YÊU CẦU CỦA HT 3.4 THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 3.5 CÁC NHÓM MẪU THIẾT KẾ 3.6 THIẾT KẾ GIAO DIỆN, BÁO BIỂU, AN TOÀN HỆ THỐNG 3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT Nhận xét: Quá trình xây dựng sản phẩm phần mềm nâng cấp sản phẩm có gọi trình phát triển phần mềm (Software Development Process) Quá trình phát triển phần mềm trình xác định: làm (WHAT?), làm đâu (WHERE?) làm (WHEN?) làm (HOW?) 198 3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT Có bước cần thực q trình phát triển phần mềm theo hướng đối tượng: Nghiên cứu trạng xác định yêu cầu Phân tích hệ thống Thiết kế hệ thống Lập trình kiểm thử hệ thống Vận hành bảo trì hệ thống 199 3.1 Q TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT 3.1.1 Nghiên cứu trạng xác định yêu cầu Từ yêu cầu khách hàng xác định mục tiêu phần mềm cần phát triển Thường yêu cầu chức mà hệ thống phải thực Ở giai đoạn chưa cần chức thực Việc xác định đầy đủ yêu cầu tốn nhiệm vụ quan trọng, làm sở cho bước Do đó, phải đặc tả yêu cầu hệ thống (Sử dụng Use Case để đặc tả yêu cầu) 200 3.1.1 Nghiên cứu trạng xác định yêu cầu Các công việc cần phải làm giai đoạn này: Hiểu rõ miền xác định toán (Domain Understanding) Nắm bắt yêu cầu khách hàng/người sử dụng Phân loại (Classification): theo tầm quan trọng hay theo chức người sử dụng Thẩm định (Validation): Kiểm tra xem yêu cầu có thống với đầy đủ không, đồng thời tìm cách giải mối mâu thuẫn yêu cầu có 201 3.1.1 Nghiên cứu trạng xác định yêu cầu Nghiên cứu khả thi (Feasibility Study): Tính khả thi dự án tin học phải thực dựa yếu tố bao gồm khía cạnh: tài chiến lược thị trường người, đối tác kỹ thuật cơng nghệ phương pháp mơ hình hoá, v.v 202 3.1.1 Nghiên cứu trạng xác định yêu cầu Tóm lại, giai đọan nghiên cứu sơ bộ, cần xem xét: Các yêu cầu NSD, nguồn tài ngun sử dụng, cơng nghệ, ý tưởng người sử dụng hệ thống Có thể thực thảo luận, nghiên cứu, xem xét khía cạnh thương mại, phân tích khả lời-lỗ Thường giai đoạn người ta tiến hành tạo phiên thơ lịch trình kế hoạch sử dụng tài nguyên Kết giai đoạn nghiên cứu sơ Báo Cáo Kết Quả Nghiên Cứu Tính Khả Thi Khi hệ thống tương lai chấp nhận dựa báo cáo lúc giai đoạn Phân tích bắt 203 đầu 3.1.1 Nghiên cứu trạng xác định yêu cầu Mục đích cụ thể bước xác định yêu cầu: Đi đến thỏa thuận với khách hàng người dùng chức hệ thống-Những mà hệ thống phải thực Cho phép System Developer hiểu rõ yêu cầu hệ thống Phân định ranh giới hệ thống Cung cấp sở để hoạch định nội dung kỹ thuật vòng lặp Xác định giao diện người dùng cho hệ thống 204 3.1.1 Nghiên cứu trạng xác định yêu cầu Khi kết thúc giai đoạn này? Khách hàng/người sử dụng (NSD) người phát triển hiểu hoàn toàn hệ thống chưa? Đã nêu đầy đủ yêu cầu chức (dịch vụ), đầu vào/ra liệu cần thiết chưa? 205 Mẫu Chain of Responsibility Ý nghĩa: Mẫu thiết lập chuỗi bên hệ thống, nơi mà thơng điệp thực mức nơi mà nhận lần đầu chuyển đến đối tượng mà thực điều đóTạo giao diện trung gian để gắn kết vào hệ thống lớp đối tượng mong muốn Cấu trúc mẫu: 315 Mẫu Chain of Responsibility Trong đó: o Handler: giao tiếp định nghĩa phương thức sử dụng để chuyển thông điệp qua lần thực o ConcreteHandler: thực thi giao tiếp Handler Nó giữ tham chiếu đến Handler Việc thực thi phương thức handleMessage xác định làm để thực phương thức gọi handlerMethod, chuyển tiếp thông điệp đến cho Handler kết hợp hai 316 Mẫu Chain of Responsibility Tình áp dụng Có nhóm đối tượng hệ thống đáp ứng tất loại thông điệp giống Các thông điệp phải thực vài đối tượng hệ thống Các thông điệp theo mô hình “thực – chuyển tiếp”, vài kiện thực mức mà chúng nhận ra, số khác phải chuyển tiếp đến vài đối tượng khác 317 Mẫu Chain of Responsibility Ví dụ: Hệ thống quản lý thơng tin cá nhân sử dụng để quản lý dự án liên hệ Ta hình dung cấu trúc sau; đỉnh dự án, đỉnh tác vụ dự án đó, vậy, đỉnh tác vụ lại có tập đỉnh tác vụ khác Để quản lý cấu trúc ta thực sau: -Ở đỉnh ta lưu thông tin sau: tên tác vụ, đỉnh cha, tập đỉnh -Ta xét thông điệp sau: duyệt từ đỉnh gốc (project cở sở) in thông tin -Như với thông điệp này, việc in thông tin đỉnh chưa đủ, ta phải chuyển tiếp đến in thông tin đỉnh đỉnh gốc chuyển tiếp khơng cịn đỉnh dừng 318 Mẫu Chain of Responsibility 319 Mẫu Command Ý nghĩa: Gói mệnh lệnh vào đối tượng mà lưu trữ, chuyển vào phương thức trả vài đối tượng khác Cấu trúc mẫu: Trong đó: o Command: giao tiếp định nghĩa phương thức cho Invoker sử dụng o Invoker: lớp thực phương thức đối tượng Command o Receiver: đích đến Command đối tượng thực hồn tất u cầu, có tất thông tin cần thiết để thực điều o ConcreteCommand: thực thi giao tiếp Command Nó lưu tham chiếu Receiver mong muốn 320 Mẫu Command Luồng thực thi mẫu Command sau: 321 Mẫu Command Client gửi yêu cầu đến GUI ứng dụng Ứng dụng khởi tạo đối tượng Command thích hợp cho yêu cầu (đối tượng ConcreteCommand) Sau ứng dụng gọi phương thức executeCommand() với tham số đối tượng Command vừa khởi tạo Invoker gọi thông qua phương thức executeCommand() thực gọi phương thức execute() đối tượng Command tham số Đối tượng Command gọi tiếp phương thức doAction() thành phần Receiver nó, khởi tạo từ đầu, doAction() phương thức để hoàn tất yêu cầu Client 322 Mẫu Command Tình áp dụng Hỗ trợ undo, logging transaction Thực hàng đợi lệnh thực lệnh thời điểm khác Hạn chế chặt chẽ yêu cầu với đối tượng thực hoàn tất yêu cầu 323 Mẫu Interpreter Ý nghĩa: Ý tưởng Interpreter triển khai ngơn ngữ máy tính đặc tả để giải nhanh lớp vấn đề định nghĩa Ngôn ngữ đặc tả thường làm cho vấn đề giải nhanh ngôn ngữ thông thường từ vài trăm lần Ý tưởng tương tự biểu diễn biểu thức tính tốn theo cú pháp Ba Lan Cấu trúc mẫu: 324 Mẫu Command Trong đó: Expression: giao tiếp mà thơng qua nó, client tương tác với biểu thức o TerminalExpression: thực thi giao tiếp Expression, đại diện cho nốt cuối cú pháp o NonterminalExpression: thực thi khác giao tiếp Expression, đại diện cho nút chưa kết thúc cấu trúc cú pháp Nó lưu trữ tham chiếu đến Expression triệu gọi phương thức diễn giải cho phần tử o Context: chứa thông tin cần thiết cho vài vị trí diễn giải Nó phục vụ kênh truyền thông cho thể Expression o Client: xây dựng nhận thể cú pháp ảo Cây cú pháp bao gồm thể TerminalExpression NoterminalExpression để tạo nên câu đặc tả Client triệu gọi phương thức 325 diễn giải với ngữ cảnh thích hợp cần thiết Mẫu Interpreter Tình áp dụng Có ngơn ngữ đơn giản để diễn giải vấn đề Các vấn đề lặp lại diễn giải nhanh ngơn ngữ Ví dụ: Xét biểu thức + x + 6, với tóan ta chia thành các tóan nhỏ -Tính x = a -Sau tính + a = b -Sau tính b + Ta biểu diễn tóan thành cấu trúc duyệt theo Ba Lan 326 Mẫu Interpreter 327 References http://www.uml.org.cn/c++/pdf/DesignPatterns.pdf http://duydo.com/design-patterns-l%E1%BA%ADp-trinhvien-c%E1%BA%A7n-ph%E1%BA%A3i-bi%E1%BA%BFt/ Giới thiệu mẫu thiết kế hướng đối tượng (Design Pattern) http://duriangroup.wordpress.com/2007/10/27/gi%E1%BB% 9Bi-thi%E1%BB%87u-cac-m%E1%BA%AButhi%E1%BA%BFt-k%E1%BA%BFh%C6%B0%E1%BB%9Bng-d%E1%BB%91it%C6%B0%E1%BB%A3ng-design-pattern/ 328 HẾT CHƯƠNG 329 ...NỘI DUNG 3. 1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 3. 2 PHÂN TÍCH YÊU CẦU HỆ THỐNG 3. 3 ĐẶC TẢ CÁC YÊU CẦU CỦA HT 3. 4 THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 3. 5 CÁC NHÓM MẪU THIẾT KẾ 3. 6 THIẾT KẾ GIAO... trúc cấu hình hệ thống nào? 209 3. 1 .3 Thiết kế hướng đối tượng Tóm lại, nhiệm vụ thiết kế hệ thống là: Xây dựng thiết kế chi tiết mô tả thành phần hệ thống mức cao (khâu phân tích) để phục vụ... tả xác ? ?Phân tích hướng đối tượng tập trung vào việc tìm kiếm đối tượng, khái niệm lĩnh vực toán xác định mối quan hệ chúng hệ thống ? ?Phân tích hệ thống cần trả lời câu hỏi sau: Hệ thống gồm