Bài giảng Phân tích thiết kế hướng đối tượng - Chương 1: Tổng quan về phân tích thiết kế hệ thống thông tin - Lê Thị Minh Nguyên

8/30/2017 1 Chương 1. Tổng quan về phân tích thiết kế hệ thống thông tin GV: Lê Thị Minh Nguyện Email: nguyenltm@huflit.edu.vn Phân tích thiết kế hướng đối tượng 1 Nội dung 1. Dẫn nhập 2. Mô tả chu trình phát triển phần mềm 3. Phương pháp hướng chức năng và phương pháp hướng đối tượng 4. Mô hình RUP Phân tích thiết kế hướng đối tượng 2 1. Dẫn nhập 1.1. Đặc điểm của phần mềm 1.2. Tính trực quan 1.3. Mô hình trừu tượng 1.4. Mô hình hóa trực quan Phân tích thiết kế hướng đối tượng 3 1.1. Đặc điểm của phần mềm Phân tích thiết kế hướng đối tượng 4 Chức năng (Functionality) Hiệu năng (Performance) Một phần mềm tốt cần mang lại: 8/30/2017 2 1.1. Đặc điểm của phần mềm Phân tích thiết kế hướng đối tượng 5 Usability Efficiency Một phần mềm tốt cần đảm bảo Maintainability Portability 1.1. Đặc điểm của phần mềm Phân tích thiết kế hướng đối tượng 6 Maintainability Một phần mềm tốt cần đảm bảo Khả năng phát triển/tiến hóa để có thể đáp ứng được các yêu cầu thay đổi của khách hàng 1.1. Đặc điểm của phần mềm Phân tích thiết kế hướng đối tượng 7 Dependability Một phần mềm tốt cần đảm bảo Đảm bảo được tính ổn định, độ tin cậy và bảo mật. 1.1. Đặc điểm của phần mềm Phân tích thiết kế hướng đối tượng 8 Efficiency Một phần mềm tốt cần đảm bảo Không được lãng phí tài nguyên hệ thống. Bao gồm: khả năng đáp ứng, thời gian xử lý và quản lý vùng nhớ 8/30/2017 3 1.1. Đặc điểm của phần mềm Phân tích thiết kế hướng đối tượng 9 Acceptability Một phần mềm tốt cần đảm bảo Phù hợp với loại người dùng mà phần mềm hướng đến Dễ sử dụng, dễ hiểu và tương thích với hệ thống hiện tại 1.2. Tính trực quan Phân tích thiết kế hướng đối tượng 10 "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ị 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ô". 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 các hệ thống phức tạp Số mẫu tin Số lần lặp Thời gian tuần tự Thời gian song song 11000 12 14 25 22000 16 52 50 33000 15 93 62 44000 20 219 102 55000 17 305 107 66000 17 555 124 77000 25 1318 286 88000 19 1045 183 99000 20 1959 210 110000 20 2304 234 220000 29 19526 654 330000 21 37891 692 440000 22 88506 981 2458285 25 Treo máy 6236 1.3. Mô hình trừu tượng Phân tích thiết kế hướng đối tượng 11 "Cuộc khủng hoảng phần mềm" phần mềm không thể sản sinh ra những hệ thống thoả mãn đòi hỏi và nhu cầu của khách hàng, mà còn vượt quá ngân sách và thời hạn Các công nghệ mới như lập trình hướng đối tượng, lập trình trực quan Chỉ hướng tới tầng thấp nhất của việc phát triển phần mềm: phần viết lệnh (coding). Ban quản trị thiếu hiểu biết về quy trình phát triển phần mềm Cần xây dựng các mô hình trừu tượng cho hệ thống 1.4. Mô hình hóa trực quan Phân tích thiết kế hướng đối tượng 12 Mô hình hoá trực quan là một phương thức tư duy về vấn đề sử dụng các mô hình được tổ chức xoay quanh các khái niệm đời thực Để xây dựng các hệ thống phức tạp tức là trừu tượng hóa nhiều hướng nhìn khác nhau của hệ thống, sử dụng ký hiệu chính xác để xây dựng mô hình Xây dựng mô hình tập trung vào bức tranh lớn về sự tương tác giữa các thành phần trong phần mềm Mô hình giúp chúng ta tổ chức, trình bày trực quan, thấu hiểu và tạo nên các hệ thống phức tạp. Mô hình hóa giúp đáp ứng các thách thức của việc phát triển phần mềm, hôm nay cũng như ngày mai 8/30/2017 4 2. Mô tả chu trình phát triển phần mềm 2.1. Software Development – một bài toán phức tạp 2.2. Chu Trình Phát Triển Phần Mềm (Software Development Life Cycle) Phân tích thiết kế hướng đối tượng 13 2.1. Một bài toán phức tạp Phân tích thiết kế hướng đối tượng 14 Những người phát triển phần mềm rất khó hiểu cho đúng những gì người dùng cần Yêu cầu của người dùng thường thay đổi trong thời gian phát triển. Yêu cầu thường được miêu tả bằng văn bản, dài dòng, khó hiểu Khả năng nắm bắt các dữ liệu phức tạp của con người (tại cùng một thời điểm) là có hạn Khó định lượng chính xác hiệu suất của thành phẩm và thỏa mãn chính xác sự mong chờ từ phía người dùng. 2.1. Một bài toán phức tạp Phân tích thiết kế hướng đối tượng 15 Các khiếm khuyết thường gặp trong phát triển phần mềm Hiểu không đúng những gì người dùng cần Không thể thích ứng cho phù hợp với những thay đổi về yêu cầu đối với hệ thống Các Module không khớp với nhau Phần mềm khó bảo trì và nâng cấp, mở rộng Phát hiện trễ các lỗ hổng của dự án Hiệu năng của phần mềm thấp 2.2. Chu Trình Phát Triển Phần Mềm Phân tích thiết kế hướng đối tượng 16 8/30/2017 5 2.2. Chu Trình Phát Triển Phần Mềm • Chu Trình Phát Triển Phần Mềm là một chuỗi các hoạt động của nhà: • Nhà phân tích (Analyst): • Nhà thiết kế (Designer): • Chuyên gia lĩnh vực (Domain Experts) • Lập trình viên (Programmer) • Lập trình viên (Programmer Phân tích thiết kế hướng đối tượng 17 2.2. Chu Trình Phát Triển Phần Mềm Phân tích thiết kế hướng đối tượng 18 2.2. Chu Trình Phát Triển Phần Mềm Phân tích thiết kế hướng đối tượng 19 2.2. Chu Trình Phát Triển Phần Mềm Phân tích thiết kế hướng đối tượng 20 Nghiên cứu sơ bộ (Preliminary Investigation hay còn gọi là Feasibility Study): • 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 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 cấp, và có thể tạo một vài nguyên mẫu dùng để “minh chứng các khái niệm của hệ thống”. • Ý tưởng có thể đến từ nhiều nguồn khác nhau: khách hàng, chuyên gia 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 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 • 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 dùng hệ thống), những nguồn tài nguyên có thể sử dụng, công nghệ cũng như cộng đồng người dùng cùng các ý tưởng của họ đối với hệ thống mới. 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 8/30/2017 6 2.2. Chu Trình Phát Triển Phần Mềm Phân tích thiết kế hướng đối tượng 21 Nghiên cứu sơ bộ (Preliminary Investigation hay còn gọi là Feasibility Study): • 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 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 cấp, và có thể tạo một vài nguyên mẫu dùng để “minh chứng các khái niệm của hệ thống”. • Ý tưởng có thể đến từ nhiều nguồn khác nhau: khách hàng, chuyên gia 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 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 • 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 dùng hệ thống), những nguồn tài nguyên có thể sử dụng, công nghệ cũng như cộng đồng người dùng cùng các ý tưởng của họ đối với hệ thống mới. 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 2.2. Chu Trình Phát Triển Phần Mềm Phân tích thiết kế hướng đối tượng 22 Phân tích yêu cầu (Analysis): • Mục tiêu: hình thành tài liệu đặc tả yêu cầu (Requirements Specifications) gồm nội dung sau: • Xác định hệ thống cần phải làm gì. • Nghiên cứu thấu đáo tất cả các chức năng cần cung cấp và những yếu tố liên quan. • Xây dựng một mô hình nêu bật bản chất vấn đề từ một hướng nhìn có thực. • Định nghĩa vấn đề cho chuyên gia lĩnh vực để nhận sự đánh giá, góp ý. • Tài liệu này được xem: • Cam kết giữa khách hàng và tổ chức phát triển hệ thống về cái mà hệ thống có thể làm (và cái mà hệ thống không thể làm) • Cơ sở để đội ngũ phát triển phát triển hệ thống • Mô hình tương đối đầy đủ về những gì hệ thống đòi hỏi 2.2. Chu Trình Phát Triển Phần Mềm Phân tích thiết kế hướng đối tượng 23 Thiết kế hệ thống (Design of the System): • Các hoạt động thường được thực hiện trong giai đoạn thiết kế: • Nhận biết form nhập liệu tùy theo các thành phần dữ liệu cần nhập. • Nhận biết reports và những output mà hệ thống mới phải sản sinh. • Thiết kế forms • Nhận biết các thành phần dữ liệu và bảng để tạo database. • Ước tính các thủ tục giải thích quá trình xử lý từ input đến output. Kết quả của giai đoạn thiết kế là Đặc tả thiết kế (Designer Specifications) mô tả: • Chức năng của mỗi thành phần • Giao diện của mỗi thành phần 2.2. Chu Trình Phát Triển Phần Mềm Phân tích thiết kế hướng đối tượng 24 Xây dựng phần mềm Đây là giai đoạn viết lệnh (code) thực sự, tạo hệ thống. Từng người viết code thực hiện những yêu cầu đã được nhà thiết kế định sẵn. Cũng chính người viết code chịu trách nhiệm viết tài liệu liên quan đến chương trình, giải thích thủ tục (procedure) mà anh ta tạo nên được viết như thế nào và lý do cho việc này Người viết code cũng đồng thời phải tiến hành thử nghiệm phần chương trình của mình. - Thử nghiệm đơn vị - Thử nghiệm độc lập 8/30/2017 7 2.2. Chu Trình Phát Triển Phần Mềm Phân tích thiết kế hướng đối tượng 25 Thử nghiệm hệ thống: • Tổ hợp các module chương trình thành hệ thống • Kiểm thử hệ thống chương trình để đảm bảo đáp ứng đầy đủ yêu cầu • Khi người phát triển thỏa mãn với sản phẩm: khách hàng kiểm thử hệ thống • Kết thúc khi khách hàng chấp nhận sản phẩm 2.2. Chu Trình Phát Triển Phần Mềm Phân tích thiết kế hướng đối tượng 26 Bảo trì hệ thống: • Bắt đầu khi hệ thống được cài đặt sử dụng thực tế, sau khi đã cấp phát sản phẩm cho khách hàng • Bảo trì bao gồm mọi thay đổi sản phẩm để khách hàng đồng ý rằng họ đã thỏa mãn với sản phẩm. • Bảo trì bao gồm: • sửa phần mềm • loại bỏ các lỗi mà không phát hiện trong các pha truớc dó • nâng cấp phần mềm • Hiệu năng: Bổ sung chức năng, tăng tốc độ thực hiện chương trình • Thích nghi: Các thay đổi cho phù hợp với môi truờng phần mềm • Thời gian trung bình: • sửa lỗi 17,5%, hiệu năng 60%, thích nghi 18%. 3. Các phương pháp xây dựng phần mềm 3.1. Phương pháp chức năng 3.2. Phương pháp hướng đối tượng Phân tích thiết kế hướng đối tượng 27 3.1. Phương pháp chức năng • Đây là lối tiếp cận truyền thống chủ yếu quan tâm chủ yếu tới những thông tin mà hệ thống sẽ gìn giữ. • Người dùng họ cần những thông tin nào, rồi thiết kế ngân hàng dữ liệu để chứa những thông tin đó. • Đây là lối tiệm cận xoay quanh dữ liệu và đã được áp dụng để tạo nên hàng ngàn hệ thống trong suốt nhiều năm. • Ưu điểm Hệ thống xoay quanh dữ liệu có thể dễ dàng xử lý việc thay đổi ngân hàng dữ liệu • Khuyết điểm Khó thực thi những thay đổi trong nguyên tắc nghiệp vụ hay cách hoạt động của hệ thống Phân tích thiết kế hướng đối tượng 28 8/30/2017 8 3.1. Phương pháp hướng đối tượng • Lối tiếp cận hướng đối tượng là một lối tư duy về vấn đề theo lối ánh xạ các thành phần trong bài toán vào các đối tượng ngoài đời thực. • Chia ứng dụng thành các thành phần nhỏ, gọi là các đối tượng, chúng tương đối độc lập với nhau. Sau đó ta có thể xây dựng ứng dụng bằng cách chắp các đối tượng đó lại với nhau. • Đối tượng = chức năng + dữ liệu • Hệ thống = tập hợp các đối tượng + quan hệ giữa các đối tượng Phân tích thiết kế hướng đối tượng 29 3.1. Phương pháp hướng đối tượng • Ưu điểm • Gần gũi với thế giới thực • Tái sử dụng dễ dàng • Đóng gói, che dấu thông tin làm cho hệ thống tin cậy hơn • Thừa kế giảm chi phí, hệ thống có tính mở cao • Phù hợp với hệ thống lớn và phức tạp Phân tích thiết kế hướng đối tượng 30 4. Mô hình RUP Phân tích thiết kế hướng đối tượng 31 Mô hình RUP- Rational Unified Process • Do hãng Rational sản xuất • Là quy trình phát triển phần mềm hợp nhất Rational (Rational Unified Process hay RUP) là một quy trình phát triển phần mềm. • Nó cung cấp các phương pháp, các nguyên tắc phân công nhiệm vụ và trách nhiệm trong các tổ chức phát triển phần mềm. • Nó là phương pháp dùng để tạo ra một sản phẩm phần mềm có chất lượng cao đảm bảo các dự thảo về thời gian và và kinh phí với khách hàng 4. Mô hình RUP Phân tích thiết kế hướng đối tượng 32 Quy trình RUP bao gồm 4 phases và 9 workflow, được thể hiện như sau: 32 8/30/2017 9 4. Mô hình RUP Phân tích thiết kế hướng đối tượng 33 33  Khởi đầu (inception) Cho một cái nhìn tổng quát về hệ thống sẽ xây dựng và về dự án sẽ triển khai.  Xác định phạm vi dự án  Chi phí, thời gian  Rũi ro, môi trường  Phác thảo (elaboration) Bao gồm sự phân tích chi tiết hơn về hệ thống, cả về chức năng lẫn cấu trúc tĩnh.  Phác thảo kiến trúc, yêu cầu  Đánh giá độ rũi ro, các thành phần sử dụng  Xây dựng (construction) Tập trung vào việc thiết kế và thực thi hệ thống.  Chuyển giao (transition) Nhằm chuyển hệ thống đã xây dựng cho người dùng cuối  Cài đặt; kiểm thử  Tiếp nhận ý kiến  Bảo trì 4. Mô hình RUP Phân tích thiết kế hướng đối tượng 34 34 Thời gian dành cho các giai đoạn này được ước tính như sau: 4. Mô hình RUP Phân tích thiết kế hướng đối tượng 35 35 - Luồng công việc chính: - Business modeling - Requirement - Analysis & Design - Implemention - Test - Deployment - Luồng công việc hỗ trợ: - Project Management - Configuration and Change Management - Enviroment 4. Mô hình RUP Phân tích thiết kế hướng đối tượng 36 36 Mô hình hoá nghiệp vụ (Business modeling) - Hiểu được vấn đề đang tồn tại trong tổ chức và đề xuất cải tiến - Để đảm bảo khách hàng, người dùng cuối, người phát triển có sự hiểu biết thống nhất về hệ thống - Để tìm ra những yêu cầu hệ thống cần thiết 8/30/2017 10 4. Mô hình RUP Phân tích thiết kế hướng đối tượng 37 37 Quản lý yêu cầu (Requirements management) Mô tả nghiệp vụ bằng phương pháp “tình huống sử dụng” (use case base method). Mục tiêu của luồng công việc này là: - Thiết lập và duy trì sự đúng đắn về yêu cầu của khách hàng hoặc các nhân tố khác về những gì mà hệ thống sẽ thực hiện - Giúp cho người phát triển hiểu rõ hơn về những yêu cầu của hệ thống - Xác định giới hạn của hệ thống - Giúp cho việc ước lượng thời gian và chi phí phát triển hệ thống Các yêu cầu của hệ thống bao gồm yêu cầu về chức năng và yêu cầu ngoài chức năng (độ tin cậy, hiêu suất, sự hỗ trợ,..). 4. Mô hình RUP Phân tích thiết kế hướng đối tượng 38 38 Phân tích và thiết kế (Analysis and design) Mô tả kiến trúc hệ thống thông qua các sơ đồ phân tích thiết kế. Mục đích của luồng công việc này là chuyển các yêu cầu sang đặc tả để mô tả cách thực cài đặt hệ thống. 4. Mô hình RUP Phân tích thiết kế hướng đối tượng 39 39 Cài đặt (Implementation) Thực hiện các việc xây dựng chương trình bằng ngôn ngữ lập trình. Mụch đích của luồng công việc này là: - Xác định cách thức viết mã cài đặt - Cài đặt các lớp và đối tượng như là các thành phần - Tích hợp vào trong một hệ thống có thể thực thi được 4. Mô hình RUP Phân tích thiết kế hướng đối tượng 40 40 Kiểm thử (Test) Mục đích của kiểm thử là để đảm bảo chất lượng. Luồng công việc này liên quan đến: - Xét duyệt sự tương tác giữa các thành phần trong hệ thống - Xét duyệt sự tích hợp đúng đắn các thành phần - Xét duyệt tất cả các yêu cầu đã được cài đặt - Đảm bảo rằng phát hiện các lỗi trước khi triển khai hệ thống Các bước kiểm thử: - Kiểm thử đơn vị - Kiểm thử tích hợp - Kiểm thử hệ thống - Kiểm thử sự chấp nhận 8/30/2017 11 4. Mô hình RUP Phân tích thiết kế hướng đối tượng 41 41 Triển khai ứng dụng (Deployment) Mục đích của Sự triển khai là đưa sản phẩm phần mềm đến người sử dụng. Luồng này bao gồm các hoạt động: - Kiểm thử phần mềm trong môi trường sử dụng cuối cùng - Đóng gói phần mềm để chuyển giao - Cài đặt phần mềm - Huấn luyện người sử dụng 4. Mô hình RUP Phân tích thiết kế hướng đối tượng 42 42 Triển khai ứng dụng (Deployment) Mục đích của Sự triển khai là đưa sản phẩm phần mềm đến người sử dụng. Luồng này bao gồm các hoạt động: - Kiểm thử phần mềm trong môi trường sử dụng cuối cùng - Đóng gói phần mềm để chuyển giao - Cài đặt phần mềm - Huấn luyện người sử dụng Phân tích thiết kế hướng đối tượng 43