Bài giảng phân tích và thiết kế hướng đối tượng mô hình hóa yêu cầu đỗ ngọc như loan

Mơ hình hố u cầu Đỗ Ngọc GV: Phan ThịNhư KimLoan Loan Nội dung trước  Hệ thống hướng chức vs Hệ thống hướng đối tượng  Các đặc điểm hệ thống hướng đối tượng  Giới thiệu UML – UML 2.0  Phân tích thiết kế hướng đối tượng với UML 2.0 3- Mơ hình hố u cầu Nội dung Mơ hình hóa u cầu:  Lược đồ Use-case  Khái niệm Actor Usecase  Ví dụ Mơ hình hóa dịng liệu Use-case  Giới thiệu Mơ hình DFD  Sử dụng mơ hình DFD để mơ hình hóa u cầu lưu trữ, tra cứu, tính tốn, kết xuất 3- Mơ hình hố u cầu Mục tiêu Tìm hiểu khái niệm xác định yêu cầu người dùng tác dụng chúng lên Phân tích Thiết kế Tìm hiểu cách ghi nhận diễn dịch yêu cầu người dùng, thơng tin dùng để bắt đầu việc phân tích thiết kế 3- Mơ hình hố u cầu Các yêu cầu người dùng ngữ cảnh IBM _ Rational Unified Process 3- Mơ hình hố u cầu Các yêu cầu người dùng ngữ cảnh Mục đích bước xác định yêu cầu người dùng là: • Ði đến thỏa thuận với khách hàng chức hệ thống (những hệ thống phải thực hiện) • Cho phép nhà phát triển hệ thống (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 IBM _ Rational Unified Process • Xác định giao diện người dùng cho hệ thống 3- Mơ hình hố u cầu Các dạng thông yêu cầu người dùng  Use case Model  Các Use Case  Use Case Report Bảng giải Các đặc tả bổ sung 3- Mơ hình hoá yêu cầu Mở đầu Đặt vấn đề:  Các mô tả yêu cầu giai đoạn xác định u cầu: • Chỉ mơ tả chủ yếu thông tin liên quan đến việc thực nghiệp vụ giới thực, chưa thể rõ nét việc thực nghiệp vụ máy tính • Mô tả thông văn dễ gây nhầm lẫn khơng trực quan  Mơ hình hóa u cầu 3- Mơ hình hố u cầu Khái niệm Actor Tác nhân BÊN NGỒI hệ thống Có tương tác với hệ thống Con người Tên Actor Phần mềm Phần cứng 3- Mơ hình hố u cầu Phần mềm khác Actor Tác nhân bất kỳ thứ tương tác với hệ thống, có trao đổi liệu với hệ thống Không phải phần hệ thống Tác nhân là: Người dùng, Thiết bị phần cứng, Hệ thống phần mềm khác Tác nhân trao đổi thông tin với hệ thống: ▫Gửi thông tin tới hệ thống ▫Nhận thông tin từ hệ thống 3- Mơ hình hố u cầu 10 Sơ đồ tổng qt cho Yêu cầu báo biểu  Xử lý báo biểu  Nhận thông tin D1, D5 (nếu cần)  Đọc D3 để lấy liệu cần thiết cho việc lập báo biểu Người dùng  Nếu có D4 tính tốn theo quy định Ghi kết D4  Hiển thị thông tin báo biểu D2 D1 Thiết bị nhập D5 Xử lý BB Thiết bị xuất D6 kết xuất D6 D3 3- Mơ hình hố u cầu D2 D4 56 Sơ đồ tổng quát cho Yêu cầu báo biểu  Ghi chú:  D1 thường có chứa yếu tố thời gian báo biểu  Có nhiều mức độ khác xác định D1 xử lý tính tốn (để tăng tính tiện dụng) Người dùng D1 D2  D4 có hay khơng có => Khi cần D4? Thiết bị nhập D5 Xử lý BB Thiết bị xuất D6  Thông thường D2 D6 bao gồm D3 D4 D3 3- Mô hình hố u cầu D4 57 Thực hành Đỗ Ngọc GV: Phan ThịNhư KimLoan Loan 58 Tài liệu giai đoạn xác định yêu cầu      Phát biểu toán (Problem Statement) Bảng giải Use-Case Model Các đặc tả bổ sung Checkpoints 3- Mơ hình hoá yêu cầu 59 Thực hành  Làm việc với công cụ Rational Rose  Case Study – Quản lý đăng ký học phần 3- Mơ hình hố u cầu 60 Phát biểu toán  Bài toán  Tên tốn: Course Registration  1-PhatBieuBaiToan_V1_TenDeTai.doc 3- Mơ hình hố u cầu 61 3- Mơ hình hố u cầu 62 Glossary  Từ điển thuật ngữ (Glossary)  2-BangChuGiai_V1_TenDeTai.doc Bảng giải Use-Case Diagram 3- Mơ hình hố u cầu 63 Đặc tả use-case Ðiểm lại đặc tả use-case hoàn chỉnh cung cấp tài liệu, mô tả yêu cầu ứng dụng “Course Registration” 3- Mơ hình hố yêu cầu 64 Các đặc tả bổ sung Functionality Tính khả dụng (Usability) Tính tin cậy (Reliability) Tính hiệu (Perfromance) Tính hỗ trợ (Supportability) Các ràng buộc thiết kế       Supplementary Specification 4-DacTaBoSung_V1_TenDeTai.doc 3- Mơ hình hố yêu cầu 65 Checkpoints: Requirement: Use-Case Model  Use-case model hiểu khơng?  Sau nghiên cứu use-case model, bạn có hình thành ý tuởng ràng chức hệ thống cách thức mà chúng liên hệ với ?  Đã xác định hết tất actor? Tất yêu cầu chức thỏa hay chưa?  Use-case model có chứa hành vi vơ dụng khơng?  Việc chia model thành use-case package có xác đáng? 3- Mơ hình hố u cầu 66 Checkpoints: : Requirements: Actors  Ðã xác định hết tất actor?  Mỗi actor có tham gia vào use case?  Mỗi actor thật có vai trị (role)? Có cần ghép tách actor khơng?  Có tồn actor dùng vai trị use case khơng?  Tên actor có gợi nhớ khơng? Users customers có hiểu tên chúng? 3- Mơ hình hố u cầu 67 Checkpoints : Requirements: Use-Cases  Mỗi use case có actor tương tác?  Các use case có độc lập với nhau?  Tồn use case có luồng kiện hành vi tương tự khơng?  Liệu use case có tên nhất, gợi nhớ, dễ hiểu để chúng không bị nhầm lẫm giai đoạn sau?  Các khách hàng người dùng có hiểu tên mơ tả use case khơng? 3- Mơ hình hoá yêu cầu 68 Checkpoints: Đặc tả Use-Case  Use case có đủ rõ ràng người muốn hiên thực?  Mục đích use-case có rõ ràng?  Mơ tả sơ lược (Brief description) có cho ta hình ảnh trung thực use-case?  Có xác định rõ luồng kiện use-case bắt đầu kết thúc?  Chuỗi giao tiếp actor use-case có tiện nghi khơng (từ góc nhìn người dùng)?  Các tương tác thơng tin trao đổi actor có rõ ràng?  Có use-case q phức tạp khơng?  Các luồng kiện (basic alternative) mơ hình đắn? 3- Mơ hình hố u cầu 69 Checkpoints: Requirements: Glossary  Các thuật ngữ có định nghĩa rõ ràng súc tích?  Mỗi thuật ngữ có dùng mơ tả usecase?  Các thuật ngữ có sử dụng hợp lý mơ tả ngắn actor use case? 3- Mô hình hố u cầu 70 ... thống hướng chức vs Hệ thống hướng đối tượng  Các đặc điểm hệ thống hướng đối tượng  Giới thiệu UML – UML 2.0  Phân tích thiết kế hướng đối tượng với UML 2.0 3- Mơ hình hố u cầu Nội dung Mơ hình. .. đầu việc phân tích thiết kế 3- Mơ hình hố u cầu Các u cầu người dùng ngữ cảnh IBM _ Rational Unified Process 3- Mơ hình hố u cầu Các u cầu người dùng ngữ cảnh Mục đích bước xác định yêu cầu người... cứu, tính tốn, kết xuất 3- Mơ hình hố u cầu Mục tiêu Tìm hiểu khái niệm xác định yêu cầu người dùng tác dụng chúng lên Phân tích Thiết kế Tìm hiểu cách ghi nhận diễn dịch yêu cầu người dùng,