Bài giảng phân tích và thiết kế hướng đối tượng bài giảng 3 TS đào nam anh

54 132 0
Bài giảng phân tích và thiết kế hướng đối tượng bài giảng 3   TS  đào nam anh

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

PHÂN TÍCH THIẾT KẾ HƯỚNG ĐỐI TƯỢNG OBJECT ORIENTED ANALYSIS AND DESIGN DR DAO NAM ANH Bài giảng 3: BIỂU ĐỒ USE CASE PHÂN TÍCH YÊU CẦU HỆ THỐNG RESOURCE - REFERENCE Ian Sommerville, Software Engineering, Ninth Edition, 2011 Bernd Bruegge & Allen H Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java, Third Edition, Prentice Hall, 2010 Russell C Bjork, ATM Simulation Links, Gordon College Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David Fado, UML Toolkit, John Wiley & Sons Inc, 2003 Dương Kiều Hoa – Tơn Thất Hồ An, Phân tích thiết kế Hệ thống thơng tin với UML, 2006 Đào Nam Anh, Giáo Trình Phân Tích Thiết Kế Hướng Đối Tượng, Đại học Điện lực, 2013 CONTENT – NỘI DUNG Phương pháp hướng đối tượng trình phát triển hệ thống phần mềm Giới thiệu hệ thống phần mềm Sự phát triển hệ thống Các cách tiếp cận phát triển phần mềm Quá trình phát triển phần mềm hợp Nội dung Biểu đồ Use Case phân tích yêu cầu hệ thống Tập hợp u cầu hệ thống Biểu đồ Use Case Mơ hình hóa với Use Case Giới thiệu   Yêu cầu chức mà hệ thống phải có điều kiện mà hệ thống phải đáp ứng theo đề nghị khách hàng Để xác định yêu cầu hệ thống cần làm hai việc: tập hợp yêu cầu, mà kết tài liệu đặc tả hệ thống viết cho khách hàng hiểu được; việc phân tích, mà kết mơ hình phân tích với Use Case giải thích rõ ràng cho lập trình viên Tập hợp yêu cầu hệ thống Tập hợp yêu cầu có nhiều thách thức cần có cộng tác nhiều người tham gia với tảng nghiệp vụ khác  Một mặt, khách hàng người sử dụng chuyên gia phạm vi họ họ có ý tưởng chung hệ thống cần làm gì, họ thường có kinh nghiệm phát triển phần mềm  Mặt khác, nhà phát triển có kinh nghiệm việc xây dựng hệ thống, thường có kiến thức mơi trường nghiệp vụ người sử dụng  Tập hợp yêu cầu hệ thống   Cảnh kịch (scenario) Use Case để lấp khoảng trống Cảnh kịch mơ tả ví dụ sử dụng hệ thống loạt tương tác người dùng hệ thống Use Case mơ hình trìu tượng cảnh kịch Cảnh kịch viết ngôn ngữ tự nhiên, dễ hiểu cho người dùng Nhà phát triển tìm yêu cầu cách quan sát vấn người sử dụng Nhà phát triển trình bày quy trình cơng việc người sử dụng dạng cảnh kịch, sau phát triển cảnh kịch thể chức hệ thống tương lai ngôn ngữ khách hàng Tập hợp yêu cầu hệ thống Use Case công cụ xuất sắc để khuyến khích người sử dụng tiềm nói hệ thống từ hướng nhìn họ Đối với người dùng, mô tả ý định việc sử dụng hệ thống việc không dễ dàng  Người sử dụng thường biết nhiều mà họ diễn tả ra: Cơng cụ Use Case giúp cho nhóm phát triển phá "lớp băng"  Tập hợp yêu cầu hệ thống   Ý tưởng chủ đạo lôi người dùng tham gia vào giai đoạn q trình phân tích thiết kế hệ thống Việc nâng cao xác suất cho việc hệ thống xây dựng trở thành công cụ quen thuộc người dùng – thay tập hợp khó hiểu rối rắm khái niệm máy tính mà người dùng nghiệp vụ có cảm giác khơng hiểu làm việc Tập hợp yêu cầu hệ thống Ví dụ ATM: scenarios Hệ thống ngân hàng tự động ATM  Phần mềm thiết kế kiểm sốt máy rút tiền tự động (ATM) có đầu đọc thẻ ATM, giao diện với khách hàng gồm có bàn phím hình, khe trả phong bì, khay tiền tiền mặt (bội số 20$), máy in biên lai, phím để khởi động dừng máy ATM giao tiếp với máy tính ngân hàng thơng qua đường truyền thông  ATM phục vụ khách hàng thời điểm Một khách hàng yêu cầu nạp thẻ ATM nhập mã số cá nhân (PIN) - hai gửi đến ngân hàng để xác nhận Các khách hàng sau thực nhiều giao dịch 10 Biểu đồ Use Case 2.5 Use Case kiểm thử    Một mục đích Use Case kiểm thử (testing) Có hai loại kiểm thử khác thực đây: kiểm tra (verification) phê duyệt xác nhận (validation) Kiểm tra đảm bảo hệ thống phát triển đắn phù hợp với đặc tả tạo Phê duyệt xác nhận đảm bảo hệ thống phát triển thứ mà khách hàng người sử dụng cuối thật cần đến 40 Biểu đồ Use Case 2.5 Use Case kiểm thử   Use Case đóng phần khơng thể thiếu việc giúp đội kiểm thử lập tổ chức việc kiểm thử Các Test Case tạo từ Use Case Giá trị đầu vào khác kiểm thử điều kiện biên Dòng chảy Use Case có ích cho Test Case 41 Biểu đồ Use Case 2.6 Thực Use Case   Use Case lời miêu tả độc lập với thực thi chức hệ thống Điều có nghĩa Use Case thực (thực thể hóa) hệ thống, trách nhiệm để thực thi hành động miêu tả tài liệu Use Case phân bổ cho đối tượng cộng tác thực thi chức 42 Biểu đồ Use Case 2.6 Thực Use Case Jacobson sử dụng phương pháp định nghĩa ba loại đối tượng (có nghĩa ba loại lớp):  đối tượng biên (boundary objects) ,  đối tượng huy (control objects)  đối tượng thực thể (entity objects) Đối với Use Case, loại đối tượng sử dụng để miêu tả cộng tác thực thi Use Case  43 Biểu đồ Use Case 2.6 Thực Use Case  Đối tượng biên: loại đối tượng nằm gần đường ranh giới hệ thống nằm bên hệ thống Chúng tương tác với tác nhân nằm bên ngồi hệ thống nhận thơng điệp gửi thông điệp đến loại đối tượng khác nằm bên hệ thống 44 Biểu đồ Use Case 2.6 Thực Use Case  Đối tượng huy: loại đối tượng huy tương tác nhóm đối tượng Một đối tượng đóng vai trò "bộ phận điều khiển” cho toàn Use Case hoàn tất, hay thực thi chuỗi hành động chung nhiều Use Case Thường đối tượng tồn trình thực thi Use Case 45 Biểu đồ Use Case 2.6 Thực Use Case  Đối tượng thực thể: loại đối tượng đại diện cho thực thể toán nằm phạm vi mà hệ thống xử lý Thường chúng mang tính thụ động, theo khái niệm chúng không tự gây nên tương tác chúng Trong hệ thống thông tin, đối tượng thực thể thường mang tính trường tồn (persistent) lưu trữ hệ ngân hàng liệu Các đối tượng thực thể thường tham gia vào nhiều Use Case khác 46 Biểu đồ Use Case 2.6 Thực Use Case 47 Mơ hình hóa với Use Case    Trong kỹ thuật mô hình hóa Use Case, hệ thống có hình dạng "hộp đen" cung cấp Use Case Hệ thống làm điều nào, Use Case thực thi sao, khía cạnh chưa đề cập tới giai đoạn Trong thực tế, mơ hình hóa Use Case thực giai đoạn đầu dự án thường nhà phát triển khơng biết Use Case sau thực thi (tức biến thành dòng code thật sự) 48 Mơ hình hóa với Use Case Mục tiêu yếu Use Case để:  Mô tả yêu cầu chức hệ thống, kết rút từ thỏa thuận khách hàng, người sử dụng cuối) nhóm phát triển phần mềm  Tạo nên mô tả rõ ràng quán việc hệ thống cần phải làm gì, để mơ hình sử dụng qn suốt tồn q trình phát triển, sử dụng làm công cụ giao tiếp cho tất người tham gia để tạo nên tảng cho mơ hình thiết kế chức  Tạo nên tảng cho việc kiểm thử hệ thống, đảm bảo hệ thống thỏa mãn yêu cầu người sử dụng đưa 49 Mơ hình hóa với Use Case Mục tiêu yếu Use Case để:  Cung cấp khả theo dõi yêu cầu mặt chức chuyển thành lớp cụ thể thủ tục cụ thể hệ thống  Đơn giản hóa việc thay đổi mở rộng hệ thống qua việc thay đổi mở rộng mơ hình Use Case, sau theo dõi riêng Use Case bị thay đổi hiệu ứng chúng thiết kế hệ thống xây dựng hệ thống 50 Mơ hình hóa với Use Case Những cơng việc cụ thể cần thiết để tạo nên mô hình Use Case bao gồm: Định nghĩa hệ thống (xác định phạm vi hệ thống) Tìm tác nhân Use Case Mô tả Use Case Định nghĩa mối quan hệ Use Case Kiểm tra phê chuẩn mơ hình 51 Tạo lập biểu đồ Use Case Rational Rose 52 Tóm tắt Biểu đồ Use Case phân tích yêu cầu hệ thống Tập hợp u cầu hệ thống Biểu đồ Use Case Mơ hình hóa với Use Case 53 DISCUSSION – CÂU HỎI https://sites.google.com/site/daonamanhedu/teac hing/objectorientedanalysisanddesign 54 ... thông tin với UML, 2006 Đào Nam Anh, Giáo Trình Phân Tích Và Thiết Kế Hướng Đối Tượng, Đại học Điện lực, 20 13 CONTENT – NỘI DUNG Phương pháp hướng đối tượng trình phát triển hệ thống phần mềm Giới... Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David Fado, UML Toolkit, John Wiley & Sons Inc, 20 03 Dương Kiều Hoa – Tơn Thất Hồ An, Phân tích thiết kế Hệ thống thông tin với UML, 2006 Đào Nam Anh, ... hệ thống cần làm hai việc: tập hợp yêu cầu, mà kết tài liệu đặc tả hệ thống viết cho khách hàng hiểu được; việc phân tích, mà kết mơ hình phân tích với Use Case giải thích rõ ràng cho lập trình

Ngày đăng: 06/11/2017, 12:24

Từ khóa liên quan

Tài liệu cùng người dùng

Tài liệu liên quan