Bài giảng Phân tích thiết kế hướng đối tượng: Chương 1 - Lê Thị Minh Nguyện

8/30/2017<br /> <br /> Nội dung<br /> <br /> Chương 1.<br /> Tổng quan về phân tích<br /> thiết kế hệ thống thông tin<br /> <br /> 1. Dẫn nhập<br /> 2. Mô tả chu trình phát triển phần mềm<br /> 3. Phương pháp hướng chức năng và phương pháp hướng đối<br /> tượng<br /> 4. Mô hình RUP<br /> <br /> GV: Lê Thị Minh Nguyện<br /> Email: nguyenltm@huflit.edu.vn<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 1<br /> <br /> 1. Dẫn nhập<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 2<br /> <br /> 1.1. Đặc điểm của phần mềm<br /> <br /> 1.1. Đặc điểm của phần mềm<br /> 1.2. Tính trực quan<br /> 1.3. Mô hình trừu tượng<br /> 1.4. Mô hình hóa trực quan<br /> <br /> Một phần mềm tốt cần mang lại:<br /> Chức năng<br /> (Functionality)<br /> <br /> Hiệu năng<br /> (Performance)<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 3<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 4<br /> <br /> 1<br /> <br /> 8/30/2017<br /> <br /> 1.1. Đặc điểm của phần mềm<br /> <br /> 1.1. Đặc điểm của phần mềm<br /> <br /> Một phần mềm tốt cần đảm bảo<br /> <br /> Một phần mềm tốt cần đảm bảo<br /> <br /> Usability<br /> <br /> Maintainability<br /> <br /> Efficiency<br /> <br /> Khả năng phát<br /> triển/tiến hóa để có thể<br /> đáp ứng được các yêu<br /> cầu thay đổi của<br /> khách hàng<br /> <br /> Maintainability<br /> Portability<br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 5<br /> <br /> 1.1. Đặc điểm của phần mềm<br /> <br /> 6<br /> <br /> 1.1. Đặc điểm của phần mềm<br /> Một phần mềm tốt cần đảm bảo<br /> <br /> Một phần mềm tốt cần đảm bảo<br /> <br /> Efficiency<br /> <br /> Dependability<br /> <br /> Không được lãng phí<br /> tài nguyên hệ thống.<br /> Bao gồm: khả năng<br /> đáp ứng, thời gian xử<br /> lý và quản lý vùng nhớ<br /> <br /> Đảm bảo được tính ổn<br /> định, độ tin cậy và bảo<br /> mật.<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 7<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 8<br /> <br /> 2<br /> <br /> 8/30/2017<br /> <br /> 1.1. Đặc điểm của phần mềm<br /> <br /> 1.2. Tính trực quan<br /> Số<br /> mẫu tin<br /> 11000<br /> 22000<br /> 33000<br /> 44000<br /> 55000<br /> 66000<br /> 77000<br /> 88000<br /> 99000<br /> 110000<br /> 220000<br /> 330000<br /> 440000<br /> 2458285<br /> <br /> Một phần mềm tốt cần đảm bảo<br /> Acceptability<br /> <br /> Phù hợp với loại người<br /> dùng mà phần mềm<br /> hướng đến<br /> Dễ sử dụng, dễ hiểu và<br /> tương thích với hệ<br /> thống hiện tại<br /> Phân tích thiết kế hướng đối tượng<br /> <br /> Số lần Thời gian<br /> lặp<br /> tuần tự<br /> 12<br /> 14<br /> 16<br /> 52<br /> 15<br /> 93<br /> 20<br /> 219<br /> 17<br /> 305<br /> 17<br /> 555<br /> 25<br /> 1318<br /> 19<br /> 1045<br /> 20<br /> 1959<br /> 20<br /> 2304<br /> 29<br /> 19526<br /> 21<br /> 37891<br /> 22<br /> 88506<br /> 25<br /> Treo máy<br /> <br /> Thời gian<br /> song song<br /> 25<br /> 50<br /> 62<br /> 102<br /> 107<br /> 124<br /> 286<br /> 183<br /> 210<br /> 234<br /> 654<br /> 692<br /> 981<br /> 6236<br /> <br /> "Một số tập hợp dữ liệu phức tạp nhất định khi được trình bày bằng đồ thị<br /> sẽ truyền tải đến người đọc nhiều thông tin hơn so với các dữ liệu thô".<br /> Sự trình bày trực quan mang tính cốt yếu đối với quá trình phát triển<br /> các hệ thống phức tạp<br /> 9<br /> <br /> 1.3. Mô hình trừu tượng<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 10<br /> <br /> 1.4. Mô hình hóa trực quan<br /> <br /> "Cuộc khủng hoảng phần mềm"<br /> <br /> Mô hình hoá trực quan là một phương thức tư duy về vấn đề sử<br /> dụng các mô hình được tổ chức xoay quanh các khái niệm đời thực<br /> <br /> phần mềm không thể sản sinh ra những hệ thống thoả mãn<br /> đòi hỏi và nhu cầu của khách hàng, mà còn vượt quá ngân<br /> sách và thời hạn<br /> <br /> Để xây dựng các hệ thống phức tạp tức là trừu tượng hóa nhiều<br /> hướng nhìn khác nhau của hệ thống, sử dụng ký hiệu chính xác để<br /> xây dựng mô hình<br /> <br /> Các công nghệ mới như lập trình hướng đối tượng,<br /> lập trình trực quan<br /> <br /> Xây dựng mô hình tập trung vào bức tranh lớn về sự tương tác<br /> giữa các thành phần trong phần mềm<br /> <br /> Chỉ hướng tới tầng thấp nhất của việc phát triển phần<br /> mềm: phần viết lệnh (coding).<br /> <br /> Ban quản trị thiếu hiểu biết về quy trình phát triển<br /> phần mềm<br /> <br /> Mô hình giúp chúng ta tổ chức, trình bày trực quan, thấu hiểu và<br /> tạo nên các hệ thống phức tạp.<br /> <br /> Cần xây dựng các mô hình trừu tượng cho hệ thống<br /> <br /> Mô hình hóa giúp đáp ứng các thách thức của việc phát triển<br /> phần mềm, hôm nay cũng như ngày mai<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 11<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 12<br /> <br /> 3<br /> <br /> 8/30/2017<br /> <br /> 2. Mô tả chu trình phát triển phần mềm<br /> <br /> 2.1. Một bài toán phức tạp<br /> <br /> 2.1. Software Development – một bài toán phức tạp<br /> <br /> Những người phát triển phần mềm rất khó hiểu cho<br /> <br /> 2.2. Chu Trình Phát Triển Phần Mềm (Software<br /> <br /> Yêu cầu của người dùng thường thay đổi trong thời<br /> gian phát triển.<br /> <br /> đúng những gì người dùng cần<br /> <br /> Development Life Cycle)<br /> <br /> Yêu cầu thường được miêu tả bằng văn bản, dài dòng,<br /> khó hiểu<br /> Khả năng nắm bắt các dữ liệu phức tạp của con người<br /> (tại cùng một thời điểm) là có hạn<br /> Khó định lượng chính xác hiệu suất của thành phẩm và<br /> thỏa mãn chính xác sự mong chờ từ phía người dùng.<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 13<br /> <br /> 2.1. Một bài toán phức tạp<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 14<br /> <br /> 2.2. Chu Trình Phát Triển Phần Mềm<br /> <br /> Các khiếm khuyết thường gặp trong phát triển phần mềm<br /> Hiểu không đúng những gì người dùng cần<br /> Không thể thích ứng cho phù hợp với những thay đổi<br /> về yêu cầu đối với hệ thống<br /> Các Module không khớp với nhau<br /> Phần mềm khó bảo trì và nâng cấp, mở rộng<br /> Phát hiện trễ các lỗ hổng của dự án<br /> Hiệu năng của phần mềm thấp<br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 15<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 16<br /> <br /> 4<br /> <br /> 8/30/2017<br /> <br /> 2.2. Chu Trình Phát Triển Phần Mềm<br /> <br /> 2.2. Chu Trình Phát Triển Phần Mềm<br /> <br /> • Chu Trình Phát Triển Phần Mềm là một chuỗi các hoạt<br /> động của nhà:<br /> • Nhà phân tích (Analyst):<br /> • Nhà thiết kế (Designer):<br /> • Chuyên gia lĩnh vực (Domain Experts)<br /> • Lập trình viên (Programmer)<br /> • Lập trình viên (Programmer<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 17<br /> <br /> 2.2. Chu Trình Phát Triển Phần Mềm<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 18<br /> <br /> 2.2. Chu Trình Phát Triển Phần Mềm<br /> Nghiên cứu sơ bộ (Preliminary Investigation hay còn gọi là<br /> Feasibility Study):<br /> • Các hoạt động: thu thập các ý tưởng, nhận biết rủi ro, nhận biết các giao<br /> diện bên ngoài, nhận biết các các chức năng chính mà hệ thống cần cung<br /> cấp, và có thể tạo một vài nguyên mẫu dùng để “minh chứng các khái<br /> niệm của hệ thống”.<br /> • Ý tưởng có thể đến từ nhiều nguồn khác nhau: khách hàng, chuyên gia<br /> lĩnh vực, các nhà phát triển khác, chuyên gia về kỹ nghệ, các bản nghiên<br /> cứu tính khả thi cũng như việc xem xét các hệ thống khác đang tồn tại<br /> • Nhóm phát triển hệ thống cần xem xét các yêu cầu của doanh nghiệp (cần<br /> dùng hệ thống), những nguồn tài nguyên có thể sử dụng, công nghệ<br /> cũng như cộng đồng người dùng cùng các ý tưởng của họ đối với hệ<br /> thống mới.<br /> Kết quả của giai đoạn này là: Báo cáo kết quả nghiên cứu tính khả thi<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 19<br /> <br /> Phân tích thiết kế hướng đối tượng<br /> <br /> 20<br /> <br /> 5<br /> <br />