Trang 1
Bé m«n C«ng nghÖ phÇn mÒm KHOA CÔNG NGHỆ THÔNG TIN TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI OBJECT-ORIENTED ANALYSIS AND DESIGN WITH UML 2.0 Bài 6. Xác định các phần tử thiết kế ThiNganHang.com
Trang 2
Nội dung 1. Xác định các phần tử thiết kế 2. Hệ thống con (Subsystem) 3. Tính tái sử dụng lại (Reusability) 4. Mô hình phân tầng trong quá trình thiết kế ThiNganHang.com
Trang 3
Mục đích Phân tích sự tương tác của các lớp phân tích và xác định các thành phần trong mô hình thiết kế Lớp thiết kế (design class) Hệ thống con (Subsystem) Giao diện hệ thống con (Subsystem interface) ThiNganHang.com
Trang 4
Xác định các phần tử thiết kế Đặc tả phụ trợ Hướng dẫn dự án Xác định các phần tử thiết kế Mô hình thiết kế Mô hình phân tích ThiNganHang.com
Trang 5
Chuyển đổi lớp phân tích thành các phần tử thiết kế Các lớp phân tích Các phần tử thiết kế <<boundary>> <<control>> <<subsystem>> Subsystem <<entity>> <<boundary>> <<subsystem>> Subsystem Ánh xạ nhiều – nhiều ThiNganHang.com
Trang 6
Tìm kiếm các lớp thiết kế Một lớp phân tích ánh xạ trực tiếp thành một lớp thiết kế nếu Nó là một lớp đơn giản Mức độ trừu tượng hóa đơn giản Các lớp phân tích phức tạp hơn có thể Tách ra thành nhiều lớp Trở thành một package Trở thành một hệ thống con Bất kỳ hình thức kết hợp nào ThiNganHang.com
Trang 7
Nhóm các lớp thiết kế Nhóm các lớp dựa trên nhiều yếu tố: Phân bổ nguồn lực trong các đội phát triển Tương ứng với từng loại người dùng Hệ thống con đại diện cho các sản phẩm và dịch vụ đã có mà hệ thống sử dụng Việc gộp nhóm hiệu quả giúp Package C Quản lý khả năng sử dụng lại Package B Bảo dưỡng hệ thống <<subsystem>> Subsystem C ThiNganHang.com
Trang 8
Nhóm các lớp biên Nếu giao diện của hệ thống Nếu giao diện của hệ thống sẽ chắc chắn có các thay đổi không chắc chắn có các thay đổi đáng kể đáng kể Các lớp biên được đặt Các lớp biên được gom nhóm với trong các package riêng biệt các lớp liên quan về mặt chức năng ThiNganHang.com
Trang 9
Nhóm các lớp liên quan về mặt chức năng Các tiêu chí – liên quan về mặt chức năng: Thay đổi/xóa bỏ một lớp làm ảnh hưởng tới các lớp khác Hai đối tượng tương tác với nhau bằng một lượng lớn thông điệp hoặc có mối giao tiếp phức tạp Lớp biên có thể có liên quan về mặt chức năng đến một lớp thực thể nào đó nếu lớp biên biểu diễn lớp thực thể đó Hai lớp tương tác hoặc cùng bị ảnh hưởng bởi thay đổi trong cùng một tác nhân Một lớp tạo ra thể hiện của lớp khác ThiNganHang.com
Trang 10
Nhóm các lớp liên quan về mặt chức năng Các tiêu chí – KHÔNG nên đặt hai lớp vào cùng một package: Hai lớp liên quan đến các tác nhân khác nhau Một lớp bắt buộc và một lớp không bắt buộc ThiNganHang.com
Trang 11
Sự phụ thuộc package: Element Visibility PackageA A Chỉ có lớp public (+) + Class A1 có thể được tham + Class A2 chiếu bên ngoài package chứa nó + Class A3 Lớp protected (#) chỉ B được truy cập trong PackageB gói chứa nó và gói kế thừa gói chứa nó Public visibility + Class B1 Lớp private (-) chỉ - Class B2 Private visibility được truy cập trong gói chứa nó Quy tắc của OO: Đóng gói (Encapsulation) ThiNganHang.com
Trang 12
Phụ thuộc giữa các package Các package không nên A X B phụ thuộc lẫn nhau (cross-coupling) A Tầng Package ở tầng thấp cao hơn hơn không nên phụ X X thuộc vào các package Tầng B ở tầng trên thấp hơn Nhìn chung, các phụ thuộc không nên bỏ qua C các tầng ở giữa X = Vi phạm móc nối ThiNganHang.com
Trang 13
Ví dụ: Registration Package MainStudentForm MainRegistrarForm 1 1 1 0..10..1 0..10..1 0..10..1 <<boundary>> <<boundary>> <<boundary>> CourseRegistrationForm OpenRegistrationForm CloseRegistrationForm 1 1 1 1 11 1 <<control>> <<control>> <<control>> CourseRegistrationController OpenRegistrationController CloseRegistrationController ThiNganHang.com
Trang 14
Ví dụ: University Artifacts Package <<entity>> <<entity>> CourseRegistrationInfo. Student 1 0..* 0..* 0..* primaryCourses alternateCourses 0..4 0..2 <<entity>> <<entity>> <<entity>> 0..* instructor Lecturer CourseInfo Subject 0..* 0..1 0..* 0..* 1 Prerequisites 0..* 1 CourseInfoList ThiNganHang.com
Trang 15
Nội dung 1. Xác định các phần tử thiết kế 2. Hệ thống con (Subsystem) 3. Tính tái sử dụng lại (Reusability) 4. Mô hình phân tầng trong quá trình thiết kế ThiNganHang.com
Trang 16
Hệ thống con (Subsystems) Đóng gói hoàn chỉnh một hành vi nào đó Thể hiện khả năng độc lập sử dụng các giao diện một cách rõ ràng Có thể có nhiều <<subsystem>> SubsystemA hình thức thực thi ClassA1 ClassA2 <<Interface>> W() X() InterfaceK <<subsystem>> X() SubsystemB W() ClassB1 ClassB2 ClassB3 W() X() Z() Y() ThiNganHang.com
Trang 17
Sử dụng hệ thống con Phân chia hệ thống thành nhiều phần hoạt động tương đối độc lập Thay đổi một phần không ảnh hưởng tới các phần còn lại Hệ thống con trong mô hình thiết kế sẽ trở thành thành phần trong quá trình cài đặt (components) Hệ thống con có thể được sử dụng để thể hiện một sản phẩm có sẵn, hoặc một hệ thống ngoại vi trong quá trình thiết kế ThiNganHang.com
Trang 18
Tìm kiếm hệ thống con Các phân tích có thể trở thành hệ thống con nếu: Cung cấp chức năng phức tạp Các lớp biên (giao diện với hệ thống bên ngoài) Các sản phẩm có sẵn hoặc các hệ thống bên ngoài trong quá trình thiết kế (ví dụ thành phần): Phần mềm giao tiếp <<subsystem>> Hỗ trợ truy cập CSDL Subsystem A Các kiểu và cấu trúc dữ liệu <<subsystem>> Subsystem B Các tiện ích chung <<subsystem>> Các sản phẩm theo ứng dụng Subsystem C ThiNganHang.com
Trang 19
Xác định hệ thống con “Superman Class” <<control>> ClassA X() W() <<Interface>> InterfaceK <<subsystem>> SubsystemA X() ClassA1 ClassA2 W() X() W() ThiNganHang.com
Trang 20
Giao diện cho hệ thống con (Subsystem Interface) Mỗi hệ thống con nên có một hoặc nhiều giao diện Mô hình hóa các giao diện Ánh xạ giao diện vào hệ thống con Chỉ ra sự phụ thuộc của nó tới các lớp khác Chỉ ra các hành động của giao diện Tham số và kết quả Kiểu dữ liệu Đóng gói các giao diện Một giao diện rõ ràng, ổn định là giải pháp tốt cho việc tạo ra một kiến trúc hiệu quả ThiNganHang.com
Hiển thị 20 trang đầu. Tải tài liệu để xem đầy đủ.
Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!