Bài giảng Phân tích và thiết kế hướng đối tượng - Bài 1: Phương pháp hướng đối tượng và quá trình phát triển hệ thống phần mềm - Đào Nam Anh

PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG OBJECT ORIENTED ANALYSIS AND DESIGN DR. DAO NAM ANH Bài giảng 1: Phương pháp hướng đối tượng và quá trình phát triển hệ thống phần mềm 1 RESOURCE - REFERENCE 1. Ian Sommerville, Software Engineering, Ninth Edition, 2011 2. Bernd Bruegge & Allen H. Dutoit. Object-Oriented Software Engineering: Using UML, Patterns, and Java, Third Edition, Prentice Hall, 2010 3. Russell C. Bjork, ATM Simulation Links, Gordon College 4. Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David Fado, UML 2 Toolkit, John Wiley & Sons Inc, 2003 5. Dương Kiều Hoa – Tôn Thất Hoà An, Phân tích và thiết kế Hệ thống thông tin với UML, 2006 6. Đà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, 2013 2 CONTENT – NỘI DUNG Phương pháp hướng đối tượng và quá trình phát triển hệ thống phần mềm 1. Giới thiệu về hệ thống phần mềm 2. Sự phát triển hệ thống 3. Các cách tiếp cận trong phát triển phần mềm 4. Quá trình phát triển phần mềm hợp nhất 3 Công nghệ phần mềm 1. Công việc lập mô hình (modeling) Giải quyết sự phức tạp thông qua các mô hình, bằng cách tập trung vào các chi tiết có liên quan tại một thời điểm và bỏ qua tất cả chi tiết khác. 2. Việc giải quyết vấn đề (problem-solving) Các mô hình được sử dụng để tìm ra một giải pháp có thể chấp nhận được. 3. Việc thu thập kiến thức (knowledge acquisition) Trong khi lập mô hình cho các ứng dụng và lĩnh vực liên quan, kỹ sư phần mềm thu thập dữ liệu, tổ chức thành thông tin, và tổng hợp thành kiến thức. 4. Hoạt động hướng hợp lý (rationale-driven) Khi thu thập kiến ​​thức và đưa ra các quyết định về hệ thống, kỹ sư phần mềm cũng cần phải hiểu bối cảnh thực hiện các quyết định, lý do đằng sau những quyết định này. 4 Lập mô hình  Mô hình là kết quả của sự trừu tượng, nhằm miêu tả các thành phần cốt yếu của một vấn đề hay một cấu trúc phức tạp, qua việc lọc bớt các chi tiết không quan trọng và làm cho vấn đề dễ hiểu hơn.  Lập mô hình rất có ích với các hệ thống quá lớn, phức tạp, hoặc quá đắt để có thể trực tiếp trải nghiệm. Lập mô hình cũng cho phép ta hình dung và hiểu hệ thống, cho dù nó không còn tồn tại hoặc mới chỉ là ý tưởng.  Trong dự án có các khách hàng, chuyên gia của lĩnh vực liên quan, phân tích viên, người thiết kế. Mô hình hoá giúp mọi người trong dự án trao đổi, hiểu hệ thống. Các mô hình giúp hiểu các yêu cầu của hệ thống tốt hơn, tạo các thiết kế rõ ràng hơn và xây dựng các hệ thống có khả năng dễ bảo trì hơn. 5 Mô hình lĩnh vực ứng dụng  Mô tả những khía cạnh của hệ thống thực tế có liên quan đến các vấn đề đang được xem xét.  Kỹ sư phần mềm cần phải hiểu môi trường trong đó hệ thống hoạt động.  Với hệ thống điều khiển giao thông đường sắt, kỹ sư phần mềm cần biết các thủ tục báo hiệu tàu.  Với hệ thống giao dịch ngân hàng, kỹ sư phần mềm cần phải biết các quy tắc giao dịch ngân hàng. 6 Mô hình lĩnh vực các giải pháp  Kỹ sư phần mềm cần phải hiểu những hệ thống họ sẽ xây dựng, để đánh giá được các giải pháp khác nhau và lựa chọn giải pháp.  Hầu hết các hệ thống quá phức tạp để có thể hiểu được hết, và hầu hết các hệ thống quá đắt để xây dựng.  Với những thách thức này, kỹ sư phần mềm tìm hiểu và mô tả các khía cạnh quan trọng của những hệ thống thay thế. 7 Phương pháp hướng đối tượng kết hợp việc mô hình  Lĩnh vực ứng dụng được mô hình hóa bằng một tập các đối tượng và các liên kết. Sau đó sử dụng mô hình này để mô tả các hoạt động của hệ thống.  Lĩnh vực giải pháp cũng được mô hình hóa bằng các đối tượng. 8 Giải quyết vấn đề Công nghệ chính là một hoạt động giải quyết vấn đề (problem solving) 1. Phát biểu vấn đề, 2. Phân tích vấn đề, 3. Tìm kiếm các giải pháp, 4. Quyết định giải pháp thích hợp, 5. Đặc tả giải pháp. 9 Giải quyết vấn đề  Phát triển phần mềm hướng đối tượng thường có 6 hoạt động: 1. Lấy yêu cầu, 2. Phân tích, 3. Thiết kế hệ thống, 4. Thiết kế đối tượng, 5. Lập trình, và 6. Kiểm thử. 10 Thu thập Kiến thức  Sai lầm phổ biến khi cho rằng việc thu thập kiến thức (knowledge acquisition) là một tiến trình tuần tự. Thực tế đó là một tiến trình không tuần tự.  Việc bổ sung một đoạn mới của thông tin có thể làm mất hiệu lực tất cả các kiến ​​thức đã có từ trước. 11 Thu thập Kiến thức  Tránh sự tuần tự của mô hình thác nước  Mô hình phát triển dựa trên rủi ro (risk- based development)  Mô hình phát triển dựa trên sự cố (issue- based development) 12 Sự hợp lý  Phát triển phần mềm hay gặp các hệ thống thay đổi liên tục. Thay đổi hệ thống có thể là việc khách hàng áp dụng thêm công nghệ mới.  Việc bổ sung kiến ​​thức này được gọi là sự hợp lý (rationale) của hệ thống. 13 Sự phát triển hệ thống  Trong quá trình phát triển hệ thống có sự tham gia của nhiều người với các vai trò khác nhau.  Quá trình phát triển được diễn ra trong một chu kỳ. 14 Vai trò  Chu trình phát triển phần mềm (Software Development Life Cycle - SDLC) cần sự cộng tác của nhiều người với các nhiệm vụ và lợi ích khác nhau: nhà phân tích (Analyst), thiết kế viên (Designer), người phát triển (Developer) và người dùng (User).  Những người tham gia vào dự án như vậy được xếp vào các vai trò (role) để thể hiện các nhiệm vụ của mình trong dự án. 15 Vai trò  Nhà phân tích (Analyst)  Thiết kế viên (Designer)  Nhà phân tích (Analyst)  Thiết kế viên (Designer)  Người dùng (User) 16 Giai đoạn của Chu trình phát triển phần mềm  Tập hợp yêu cầu (Requirement capture)  Phân tích yêu cầu (Analysis)  Thiết kế hệ thống (System design)  Thiết kế đối tượng (Object design)  Thực hiện, triển khai (Implementation)  Kiểm thử (Testing) 17 Giai đoạn của Chu trình phát triển phần mềm Tập hợp yêu cầu  Khách hàng và các nhà phát triển xác định mục đích của hệ thống.  Kết quả của hoạt động này là tài liệu mô tả của hệ thống về các tác nhân (actor) và các Use Case.  Tác nhân đại diện cho các thực thể bên ngoài tương tác với hệ thống. Tác nhân bao gồm vai trò người dùng cuối, các máy tính khác mà hệ thống cần phải kết nối, và môi trường tương tác.  Use Case mô tả trình tự các các hành động có thể xảy ra giữa tác nhân và hệ thống cho một nhóm các chức năng. 18 Giai đoạn của Chu trình phát triển phần mềm Phân tích hệ thống  Xây dựng một mô hình của hệ thống chính xác, đầy đủ, phù hợp, và rõ ràng.  Các thiết kế viên chuyển đổi các Use Case có được từ bước tập hợp yêu cầu, thành một mô hình các đối tượng (object model) mô tả toàn bộ hệ thống.  Thiết kế viên có thể phát hiện ra một số điều không rõ ràng và thiếu nhất quán ở các Use Case, họ sẽ thảo luận với khách hàng để làm rõ.  Kết quả việc phân tích là một mô hình hệ thống (system model) với các diễn giải các thuộc tính, hoạt động, và các liên kết. 19 Giai đoạn của Chu trình phát triển phần mềm Thiết kế hệ thống  Xác định các mục tiêu thiết kế của dự án và phân rã hệ thống vào các hệ thống con nhỏ.  Lựa chọn chiến lược để xây dựng hệ thống, chẳng hạn như xác định môi trường của hệ thống về phần cứng / phần mềm, chiến lược quản lý dữ liệu, kiểm soát luồng thông tin, chính sách kiểm soát truy cập, và xử lý các điều kiện biên.  Kết quả của việc thiết kế hệ thống là một mô tả rõ ràng của từng chiến lược này, hệ thống phân rã, và biểu đồ triển khai thể hiện quan hệ phần cứng / phần mềm của hệ thống. 20 Giai đoạn của Chu trình phát triển phần mềm Thiết kế đối tượng  Thiết kế viên xác định các đối tượng trong lĩnh vực giải pháp.  Bước này khai báo các đối tượng, giao diện giữa các hệ thống con, cơ cấu lại mô hình đối tượng để đạt các mục tiêu thiết kế như khả năng mở rộng hệ thống hoặc dễ hiểu, và tối ưu hóa mô hình đối tượng để tăng tốc độ thực hiện.  Kết quả của các bước này là một mô hình đối tượng chi tiết với mô tả chính xác cho từng phần tử. 21 Giai đoạn của Chu trình phát triển phần mềm Xây dựng  Trong quá trình triển khai lập trình, lập trình viên viết mã theo mô hình lĩnh vực giải pháp.  Lập trình viên cũng có trách nhiệm viết tài liệu liên quan đến chương trình, chú giải các thủ tục (procedure) trong chương trình. 22 Giai đoạn của Chu trình phát triển phần mềm Kiểm thử  Để đảm bảo chương trình được viết phải thoả mãn mọi yêu cầu đã nêu trong các tài liệu thiết kế.  Người kiểm thử tìm thấy sự khác biệt giữa hệ thống và mô hình thiết kế của nó bằng cách chạy hệ thống với các bộ dữ liệu đầu vào.  Kiểm thử đơn vị (unit test), lập trình viên đối chiếu chương trình với từng đối tượng và hệ thống con trong mô hình thiết kế đối tượng.  Kiểm thử kết nối (integration test), các hệ thống con được tích hợp với nhau và so sánh với các mô hình thiết kế hệ thống.  Kiểm thử hệ thống (system testing), các trường hợp điển hình và ngoại lệ được chạy qua hệ thống và so sánh với mô hình yêu cầu. 23 Các cách tiếp cận trong phát triển phần mềm Có nhiều chiến lược và kỹ thuật để phát triển phần mềm:  Phát triển hướng chức năng,  Kỹ nghệ thông tin,  Tạo mẫu và  Phát triển hướng đối tượng. Những chiến lược này có thể được kết hợp, bổ sung cho nhau trong thực tế. 24 Các cách tiếp cận trong phát triển phần mềm Phát triển phần mềm hướng chức năng  Là một trong những phương pháp chính được áp dụng rộng rãi cho các hệ thống thông tin và các ứng dụng máy tính.  Đó là phương pháp lấy QUI TRÌNH làm trung tâm, được sử dụng để mô hình các yêu cầu nghiệp vụ cho một hệ thống 25 Các cách tiếp cận trong phát triển phần mềm Phát triển phần mềm hướng chức năng  Đó là phương pháp lấy QUI TRÌNH làm trung tâm, được sử dụng để mô hình các yêu cầu nghiệp vụ cho một hệ thống 26 Các cách tiếp cận trong phát triển phần mềm Phát triển phần mềm hướng chức năng  Phương pháp này luôn coi qui trình làm trung tâm, xây dựng các khối QUI TRÌNH (process block) cho hệ thống thông tin. Phương pháp này cũng xây khối DỮ LIỆU (data block) có tầm quan trọng thứ hai. 27 Các cách tiếp cận trong phát triển phần mềm Phát triển phần mềm hướng chức năng  Phương pháp phân tích cấu trúc hiện đại có chiến lược đơn giản.  Các nhà phân tích vẽ các mô hình qui trình, được gọi là Mô hình dòng dữ liệu (data flow diagrams), mô tả các qui trình cần thiết của một hệ thống, kèm theo các yếu tố đầu vào, đầu ra, và các tập tin.  Bởi vì những hình vẽ thể hiện các yêu cầu nghiệp vụ của hệ thống về mặt logic, độc lập với các giải pháp vật lý, nên các mô hình này được gọi là thiết kế logic của hệ thống. 28 Các cách tiếp cận trong phát triển phần mềm Phát triển phần mềm hướng đối tượng  Biểu diễn các đối tượng ngoài đời thực bằng các đối tượng trong các mô hình.  Chia ứng dụng thành các thành phần nhỏ tương đối độc lập với nhau, gọi là các đối tượng.  Sau đó ta có thể xây dựng ứng dụng bằng cách sắp xếp các đối tượng đó lại với nhau. 29 Các cách tiếp cận trong phát triển phần mềm Phát triển phần mềm hướng đối tượng  Ưu điểm: tính tái sử dụng hoặc khả năng điều chỉnh phù hợp các đối tượng cho việc sử dụng mới. Ta có thể tạo các đối tượng một lần và dùng chúng nhiều lần sau đó.  Vì các đối tượng đã được kiểm thử kỹ càng trong lần dùng trước đó, nên khả năng tái sử dụng đối tượng có tác dụng giảm thiểu lỗi và các khó khăn trong việc bảo trì, giúp tăng tốc độ thiết kế và phát triển phần mềm. 30 Các cách tiếp cận trong phát triển phần mềm Phát triển phần mềm hướng đối tượng  Trong phương pháp phát triển phần mềm hướng đối tượng có khả năng kết hợp các đối tượng trong một nghiệp vụ tính toán hữu ích. Ví dụ các giao diện ứng dụng có thể được dựa trên các đối tượng đồ hoạ từ thư viện đồ họa có sẵn. 31 Các cách tiếp cận trong phát triển phần mềm Phân tích hướng đối tượng (Object-Oriented Analysis – OOA).  Dữ liệu và các qui trình thao tác trên dữ liệu đó được kết hợp hoặc đóng gói vào đối tượng.  Với một vấn đề, nhà phân tích cần ánh xạ các đối tượng hay thực thể có thực như khách hàng, người bán hàng, mô hình thiết kế để tạo ra được bản thiết kế gần cận với tình huống thực.  Mô hình thiết kế sẽ có các thực thể của một vấn đề thực và giữ nguyên các mẫu hình về cấu trúc, quan hệ cũng như hành vi của chúng.  32 Các cách tiếp cận trong phát triển phần mềm Thiết kế hướng đối tượng (Object Oriented Design - OOD) là tổ chức chương trình thành các tập hợp đối tượng cộng tác, mỗi đối tượng trong đó là thực thể của một lớp.  Các lớp là thành viên của một cây cấu trúc với mối quan hệ thừa kế.  Tạo thiết kế dựa trên kết quả của giai đoạn OOA, là những quy định phi chức năng, những yêu cầu về môi trường, những yêu cầu về khả năng thực thi.  OOD tập trung vào việc cải thiện kết quả của OOA, tối ưu hóa giải pháp đã được cung cấp trong khi vẫn đảm bảo thỏa mãn các yêu cầu đã được định trước đây 33 Các cách tiếp cận trong phát triển phần mềm Lập trình hướng đối tượng (Object Oriented Programming - OOP).  Thực hiện thiết kế hướng đối tượng qua việc sử dụng một ngôn ngữ lập trình có hỗ trợ các tính năng hướng đối tượng.  Ngôn ngữ hướng đối tượng thường được nhắc tới là C++ và Java.  Kết quả của giai đoạn này là bộ code chạy được, chỉ được đưa vào sử dụng sau khi đã trải qua nhiều vòng kiểm thử khác nhau.  34 Quá trình phát triển phần mềm hợp nhất Việc quản lý một dự án công nghệ phần mềm. Hoạt động quản lý tập trung vào việc lập kế hoạch dự án, theo dõi tình trạng dự án, theo dõi thay đổi, và điều phối các nguồn lực để bàn giao sản phẩm chất lượng cao đứng thời hạn và trong phạm vi ngân sách. Hoạt động quản lý bao gồm 1. Trao đổi thông tin 2. Quản lý hợp lý 3. Quản lý Cấu hình Phần mềm 4. Quản lý dự án 5. Vòng đời phần mềm 6. Bảo trì phần mềm 35 Quá trình phát triển phần mềm hợp nhất Trao đổi thông tin (Communication ) là hoạt động quan trọng và tốn thời gian nhất trong công nghệ phần mềm.  Hiểu lầm và thiếu thông tin thường dẫn đến lỗi và sự chậm trễ, tạo nên sửa chữa tốn kém về sau.  Trao đổi thông tin bao gồm việc trao đổi các mô hình và các tài liệu về hệ thống và lĩnh vực dụng của hệ thống, báo cáo tình trạng của các sản phẩm dự án, cung cấp thông tin phản hồi về chất lượng của các sản phẩm, thiết lập các vấn đề và đàm phán các vấn đề, và thông báo các quyết định. 36 Quá trình phát triển phần mềm hợp nhất Quản lý cấu hình phần mềm (Software configuration management) là quá trình theo dõi và kiểm soát những thay đổi trong các sản phẩm.  Các thay đổi tràn ngập trong quá trình phát triển phần mềm. Yêu cầu thay đổi khi khách hàng cần có các tính năng mới và khi các nhà phát triển giúp họ hiểu rõ hơn về lĩnh vực ứng dụng. Môi trường phần cứng / phần mềm có thay đổi khi tổ chức áp dụng một công nghệ mới. 37 Quá trình phát triển phần mềm hợp nhất Quản lý cấu hình phần mềm  Theo dõi các thay đổi. Hệ thống được mô tả như là một cấu hình các phần tử độc lập. Sự tiến hóa của cấu hình được theo dõi như một tập hợp các phiên bản cấu hình. Khi có thay đổi không tốt, nhà phát triển có thể đặt lại hệ thống vào một cấu hình cũ có tình trạng ổn định trước đây.  Kiểm soát sự thay đổi. Mọi thay đổi cần được đánh giá và chấp thuận trước khi được thực hiện. Điều này đảm bảo cho hệ thống phát triển theo đúng mục tiêu dự án và hạn chế được số lượng các lỗi hệ thống. 38 Quá trình phát triển phần mềm hợp nhất Quản lý sự hợp lý  Hợp lý (Rationale) là sự biện minh cho quyết định. Với một quyết định, sự hợp lý của nó bao gồm các vấn đề mà nó đề cập đến, các lựa chọn thay thế mà các nhà phát triển xem xét  Sự hợp lý là các thông tin quan trọng nhất các nhà phát triển cần khi có thay đổi hệ thống. Nếu một tiêu chuẩn thay đổi, các nhà phát triển có thể đánh giá lại tất cả các quyết định có sự phụ thuộc vào tiêu chuẩn này.  Nếu có thêm một lựa chọn, các nhà phát triển có thể đánh giá lại các lựa chọn dựa vào các tiêu chí đã có. Nếu một quyết định cần xem xét lại, ta có thể xem lại các sự hợp lý để biện minh cho nó. 39 Quá trình phát triển phần mềm hợp nhất Quản lý dự án (Project Management) không tạo ra sản phẩm nào trong quá trình phát triển phần mềm.  Quản lý dự án bao gồm các hoạt động giám sát để đảm bảo tạo ra một hệ thống chất lượng cao, đúng thời gian và trong phạm vi ngân sách.  Điều này bao gồm việc quản lý kế hoạch và quản lý ngân sách dự án trong quá trình đàm phán với khách hàng, thuê các nhà phát triển và tổ chức thành các đội phát triển, theo dõi tình trạng của dự án, và can thiệp khi có sai lệch. 40 Quá trình phát triển phần mềm hợp nhất Vòng đời phần mềm  Hoạt động quản lý dự án có phần việc xây dựng kế hoạch phát triển theo vòng đời phần mềm, triển khai và kiểm soát việc thực hiện kế hoạch 41 Quá trình phát triển phần mềm hợp nhất Bảo trì phần mềm  là các hoạt động sau khi bàn giao các hệ thống cho khách hàng.  Bảo trì phần mềm khác biệt với các hoạt động phát triển khác vì nó hay có thay đổi và được thực hiện bởi một đội ngũ, khác với nhóm phát triển ban đầu. Khi các dự án công nghệ phần mềm có định hướng về sự thay đổi (change driven), sự khác biệt giữa các hoạt động xây dựng và các hoạt động bảo trì sẽ lu mờ. 42 DISCUSSION – CÂU HỎI https://sites.google.com/site/daonamanhedu/teac hing/objectorientedanalysisanddesign 43