OOAD - Phân tích hướng đối tượng
Trong giai đoạn phân tích hệ thống hoặc phân tích hướng đối tượng của phát triển phần mềm, các yêu cầu hệ thống được xác định, các lớp được xác định và mối quan hệ giữa các lớp được xác định.
Ba kỹ thuật phân tích được sử dụng kết hợp với nhau để phân tích hướng đối tượng là mô hình hóa đối tượng, mô hình động và mô hình chức năng.
Mô hình hóa đối tượng
Mô hình hóa đối tượng phát triển cấu trúc tĩnh của hệ thống phần mềm về các đối tượng. Nó xác định các đối tượng, các lớp mà các đối tượng có thể được nhóm vào và mối quan hệ giữa các đối tượng. Nó cũng xác định các thuộc tính và hoạt động chính đặc trưng cho mỗi lớp.
Quá trình mô hình hóa đối tượng có thể được hình dung theo các bước sau:
- Xác định các đối tượng và nhóm thành các lớp
- Xác định mối quan hệ giữa các lớp
- Tạo sơ đồ mô hình đối tượng người dùng
- Xác định thuộc tính đối tượng người dùng
- Xác định các hoạt động sẽ được thực hiện trên các lớp
- Xem lại bảng thuật ngữ
Mô hình động
Sau khi hành vi tĩnh của hệ thống được phân tích, hành vi của nó đối với thời gian và các thay đổi bên ngoài cần được kiểm tra. Đây là mục đích của mô hình động.
Mô hình động có thể được định nghĩa là “một cách mô tả cách một đối tượng riêng lẻ phản ứng với các sự kiện, các sự kiện bên trong do các đối tượng khác kích hoạt hoặc các sự kiện bên ngoài được kích hoạt bởi thế giới bên ngoài”.
Quá trình mô hình hóa động có thể được hình dung theo các bước sau:
- Xác định trạng thái của từng đối tượng
- Xác định các sự kiện và phân tích khả năng áp dụng của các hành động
- Xây dựng sơ đồ mô hình động, bao gồm các sơ đồ chuyển đổi trạng thái
- Thể hiện từng trạng thái dưới dạng thuộc tính đối tượng
- Xác thực các sơ đồ chuyển đổi trạng thái đã vẽ
Mô hình hóa chức năng
Mô hình hóa chức năng là thành phần cuối cùng của phân tích hướng đối tượng. Mô hình chức năng cho thấy các quá trình được thực hiện trong một đối tượng và cách dữ liệu thay đổi khi nó di chuyển giữa các phương thức. Nó chỉ rõ ý nghĩa của các hoạt động của mô hình đối tượng và các hoạt động của mô hình động. Mô hình chức năng tương ứng với sơ đồ luồng dữ liệu của phân tích có cấu trúc truyền thống.
Quá trình mô hình hóa chức năng có thể được hình dung theo các bước sau:
- Xác định tất cả các đầu vào và đầu ra
- Xây dựng sơ đồ luồng dữ liệu hiển thị các phụ thuộc chức năng
- Nêu mục đích của từng chức năng
- Xác định các ràng buộc
- Chỉ định tiêu chí tối ưu hóa
Phân tích có cấu trúc so với Phân tích hướng đối tượng
Cách tiếp cận Phân tích có cấu trúc / Thiết kế có cấu trúc (SASD) là cách tiếp cận truyền thống của phát triển phần mềm dựa trên mô hình thác nước. Các giai đoạn phát triển của một hệ thống sử dụng SASD là:
- Nghiên cứu khả thi
- Phân tích yêu cầu và đặc điểm kỹ thuật
- Thiết kế hệ thống
- Implementation
- Đánh giá sau khi triển khai
Bây giờ, chúng ta sẽ xem xét những ưu và nhược điểm tương đối của phương pháp phân tích cấu trúc và phương pháp phân tích hướng đối tượng.
Ưu điểm / Nhược điểm của Phân tích Hướng đối tượng
Ưu điểm | Nhược điểm |
---|---|
Tập trung vào dữ liệu hơn là các thủ tục như trong Phân tích có cấu trúc. | Chức năng bị hạn chế trong các đối tượng. Điều này có thể gây ra vấn đề cho các hệ thống về bản chất là thủ tục hoặc tính toán. |
Các nguyên tắc đóng gói và ẩn dữ liệu giúp nhà phát triển phát triển hệ thống mà các phần khác của hệ thống không thể giả mạo được. | Nó không thể xác định đối tượng nào sẽ tạo ra một thiết kế hệ thống tối ưu. |
Các nguyên tắc đóng gói và ẩn dữ liệu giúp nhà phát triển phát triển hệ thống mà các phần khác của hệ thống không thể giả mạo được. | Các mô hình hướng đối tượng không dễ dàng hiển thị các giao tiếp giữa các đối tượng trong hệ thống. |
Nó cho phép quản lý hiệu quả độ phức tạp của phần mềm nhờ tính mô đun. | Tất cả các giao diện giữa các đối tượng không thể được biểu diễn trong một sơ đồ duy nhất. |
Nó có thể được nâng cấp từ hệ thống nhỏ lên hệ thống lớn một cách dễ dàng hơn so với các hệ thống theo phân tích cấu trúc. |
Ưu điểm / Nhược điểm của Phân tích có cấu trúc
Ưu điểm | Nhược điểm |
---|---|
Vì nó theo cách tiếp cận từ trên xuống trái ngược với cách tiếp cận từ dưới lên của phân tích hướng đối tượng, nó có thể dễ hiểu hơn OOA. | Trong các mô hình phân tích có cấu trúc truyền thống, một giai đoạn nên được hoàn thành trước giai đoạn tiếp theo. Điều này đặt ra một vấn đề trong thiết kế, đặc biệt nếu lỗi xuất hiện hoặc các yêu cầu thay đổi. |
Nó dựa trên chức năng. Mục đích tổng thể được xác định và sau đó phân rã chức năng được thực hiện để phát triển phần mềm. Sự nhấn mạnh không chỉ giúp hiểu rõ hơn về hệ thống mà còn tạo ra các hệ thống hoàn thiện hơn. | Chi phí xây dựng hệ thống ban đầu cao, vì toàn bộ hệ thống cần được thiết kế cùng một lúc nên rất ít tùy chọn để bổ sung chức năng sau này. |
Các thông số kỹ thuật trong đó được viết bằng ngôn ngữ tiếng Anh đơn giản và do đó, nhân viên không chuyên về kỹ thuật có thể dễ dàng phân tích hơn. | Nó không hỗ trợ khả năng tái sử dụng của mã. Vì vậy, thời gian và chi phí phát triển vốn đã cao. |