Object - Oriented analysis and design with uml 2.0 - Bài 6: Xác định các phần tử thiết kế

OBJECT-ORIENTED ANALYSIS AND DESIGN WITH UML 2.0Bé m«n C«ng nghƯ phÇn mỊmKHOA CƠNG NGHỆ THƠNG TINTRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘIBài 6. Xác định các phần tử thiết kếNội dungXác định các phần tử thiết kếHệ thống con (Subsystem)Tính tái sử dụng lại (Reusability)Mơ hình phân tầng trong quá trình thiết kếMục đíchPhâ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)Đặc tả phụ trợXác định các phần tử thiết kếMơ hình thiết kếMơ hình phân tíchHướng dẫn dự ánXác định các phần tử thiết kế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íchCác phần tử thiết kế>>>>Ánh xạ nhiều – nhiềuSubsystem>Subsystem>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ếuNĩ là một lớp đơn giảnMức độ trừu tượng hĩa đơn giảnCác lớp phân tích phức tạp hơn cĩ thểTách ra thành nhiều lớpTrở thành một packageTrở thành một hệ thống conBất kỳ hình thức kết hợp nàoNhĩ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ểnTương ứng với từng loại người dùngHệ thống con đại diện cho các sản phẩm và dịch vụ đã cĩ mà hệ thống sử dụngViệc gộp nhĩm hiệu quả giúpQuản lý khả năng sử dụng lạiBảo dưỡng hệ thốngPackage C Nhĩm các lớp thiết kếPackage BSubsystem C>Nhĩm các lớp biênNếu giao diện của hệ thống sẽ chắc chắn cĩ các thay đổi đáng kểCác lớp biên được đặt trong các package riêng biệtNếu giao diện của hệ thống khơng chắc chắn cĩ các thay đổi đáng kểCác lớp biên được gom nhĩm với các lớp liên quan về mặt chức năngNhĩm các lớp liên quan về mặt chức năngCá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ácHai đố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ạpLớ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ânMột lớp tạo ra thể hiện của lớp khácCá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 nhauMột lớp bắt buộc và một lớp khơng bắt buộcNhĩm các lớp liên quan về mặt chức năngPackageBPackageAPublic visibilityPrivate visibilityChỉ cĩ lớp public (+) cĩ thể được tham chiếu bên ngồi package chứa nĩQuy tắc của OO: Đĩng gĩi (Encapsulation)Sự phụ thuộc package: Element VisibilityAB+ Class A1+ Class A2+ Class A3+ Class B1 - Class B2Lớp protected (#) chỉ được truy cập trong gĩi chứa nĩ và gĩi kế thừa gĩi chứa nĩLớp private (-) chỉ được truy cập trong gĩi chứa nĩABXPhụ thuộc giữa các packageCác package khơng nên phụ thuộc lẫn nhau (cross-coupling)Package ở tầng thấp hơn khơng nên phụ thuộc vào các package ở tầng trênNhìn chung, các phụ thuộc khơng nên bỏ qua các tầng ở giữaABTầng cao hơnTầng thấp hơnCXX = Vi phạm mĩc nốiXVí dụ: Registration PackageMainRegistrarForm111MainStudentForm1CourseRegistrationForm>0..10..111OpenRegistrationForm>0..10..1OpenRegistrationController>CourseRegistrationController>111CloseRegistrationForm>0..10..1CloseRegistrationController>1Student>Lecturer>CourseRegistrationInfo.>CourseInfo>CourseInfoList1Prerequisites0..*Subject>0..*1instructor0..10..*0..*0..*0..*0..4primaryCourses0..*0..2alternateCourses0..*1Ví dụ: University Artifacts PackageNội dungXác định các phần tử thiết kếHệ thống con (Subsystem)Tính tái sử dụng lại (Reusability)Mơ hình phân tầng trong quá trình thiết kếHệ thống con (Subsystems)Đĩng gĩi hồ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àngCĩ thể cĩ nhiều hình thức thực thiInterfaceKX()W()>SubsystemA>SubsystemB>ClassA1W()ClassA2X()ClassB1W()Y()ClassB2X()ClassB3Z()Sử dụng hệ thống conPhân chia hệ thống thành nhiều phần hoạt động tương đối độc lậpThay đổi một phần khơng ảnh hưởng tới các phần cịn lạiHệ 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ế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ạpCác lớp biên (giao diện với hệ thống bên ngồi)Các sản phẩm cĩ sẵn hoặc các hệ thống bên ngồi trong quá trình thiết kế (ví dụ thành phần):Phần mềm giao tiếpHỗ trợ truy cập CSDLCác kiểu và cấu trúc dữ liệuCác tiện ích chungCác sản phẩm theo ứng dụngTìm kiếm hệ thống conSubsystem A>Subsystem C>Subsystem B>Xác định hệ thống con>ClassAX()W()X()W()>“SupermanClass”InterfaceKSubsystemA>ClassA1X()ClassA2W()Package và hệ thống conHệ thống conCung cấp hành viĐĩng gĩi hồn chỉnh nội dung Dễ dàng thay thếSubsystem A>Package BClassB1ClassB2PackageKhơng cung cấp hành viKhơng hồn tồn đĩng gĩi nội dung Cĩ thể khơng dễ dàng thay thếClient ClassGiao 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ệnMơ hình hĩa các giao diệnÁnh xạ giao diện vào hệ thống conChỉ ra sự phụ thuộc của nĩ tới các lớp khácChỉ ra các hành động của giao diệnTham số và kết quảKiểu dữ liệuĐĩng gĩi các giao diệnMột giao diện rõ ràng, ổn địnhlà giải pháp tốt cho việc tạo ra một kiến trúc hiệu quảAll other analysis classes map directly to design classes.AnalysisDesignVí dụ: Hệ thống con và giao diệnBillingSystem//submit bill()>Billing System>IBillingSystemsubmitBill(forTuition : Double, forStudent : Student)Nếu hệ thống Course Registration cĩ tương tác với BillingSystemMơ hình hĩa hệ thống con và giao diện: Billing System IBillingSystem+ submitBill(forStudent : Student, forTuition : double)>10..1+ Biller1Student>CloseRegistrationController+ // is registration open?()+ // close registration()>BillingSystem>+ submitBill(forStudent : Student, forTuition : double)BillingSystem>IBillingSystemsubmitBill(forTuition : Double, forStudent : Student)Nội dungXác định các phần tử thiết kếHệ thống con (Subsystem)Tính tái sử dụng lại (Reusability)Mơ hình phân tầng trong quá trình thiết kế3. Tính sử dụng lạiMục đíchSử dụng các giao diện để tìm cách sử dụng lại các hệ thống con hoặc các thành phần sẵn cĩ trong hệ thốngHướng dẫnTìm kiếm các gần giao diện giống nhauSửa giao diện cho phù hợp với giao diện sẽ sử dụng lạiThay thế giao diện cĩ khả năng sử dụng lại với giao diện sẵn cĩ (sử dụng lại)Ánh xạ hệ thống con của giao diện vừa bị thay thế vào thành phần cĩ sẵn đĩ để sử dụng lạiCác khả năng sử dụng lạiBên trong hệ thốngTìm ra những điểm chung giữa các gĩi hoặc hệ thống conBên ngồi hệ thốngSử dụng các thành phần sẵn cĩ (thương mại, miễn phí)Thành phần từ hệ thống phát triển trước đâyPhát triển lại một thành phần cĩ sẵn (sử dụng lại thiết kế)Khả năng sử dụng lại bên trong hệ thốngAnalysis ClassDesign ElementBillingSystemTất cả các lớp phân tích khác ánh xạ trực tiếp sang các lớp thiết kếBillingSystem SubsystemVí dụ: Bảng ánh xạ các lớp phân tích thành các phần tử thiết kếCourseInfoCourseInfo, SubjectInfo, ScheduleNội dungXác định các phần tử thiết kếHệ thống con (Subsystem)Tính tái sử dụng lại (Reusability)Mơ hình phân tầng trong quá trình thiết kếHướng tiếp cận phân tầng điển hìnhGeneral functionalitySpecific functionalityDistinct application subsystems that make up an application — contains the value adding software developed by the organization.Business specific — contains a number of reusable subsystems specific to the type of business.Middleware — offers subsystems for utility classes and platform-independent services for distributed object computing in heterogeneous environments and so on.System software — contains the software for the actual infrastructure such as operating systems, interfaces to specific hardware, device drivers, and so on.ApplicationBusiness-SpecificMiddlewareSystem SoftwareVí dụ: Các tầng kiến trúcMiddleware>Base ReuseglobalApplication>Business Services>Necessary because the Application Layer must have access to the core distribution mechanisms provided with Java RMI.Quan hệ giữa các lớp tạo nên sự phụ thuộcBAPackage APackage BRegistration>ApplicationVí dụ: Tầng ứng dụngSecurityGUI FrameworkSecure InterfacesApplication>Business Services>>Application>Business ServicesVí dụ: Ngữ cảnh của tầng ứng dụngUniversity ArtifactsRegistrationExternal System InterfacesVí dụ tầng Business ServiceCourseCatalogSystem>External System InterfacesUniversity ArtifactsObjectStore Support>Business ServicesGUIFrameworkSecureInterfacesSecurity>SecurityManagerBillingSystem>Middleware>Business Services>Ví dụ: Ngữ cảnh tầng Business Servicejava.sqlcom.odi>MiddlewareBillingSystem>CourseCatalogSystem>External System InterfacesUniversity ArtifactsObjectStore Support>Business ServicesGUIFrameworkSecureInterfacesSecurity>SecurityManagercom.odiDatabase(from com.odi)Session(from com.odi)Transaction(from com.odi)Map(from com.odi)java.sqlResultSet(from com.odi)Connection(from com.odi)Statement(from com.odi)DriverManager(from com.odi)Ví dụ tầng Middle Layer>MiddlewareMơ hình phân tầng với Hệ thống Đăng ký họcMơ hình phân tầng với Hệ thống Đăng ký học (2)Mơ hình phân tầng với Hệ thống Đăng ký học (3)Tổng kếtCác mơ hình thiết kế được xây dựng trực tiếp từ các mơ hình phân tíchLà hình thức chi tiết hĩa từ các lớp trừu tượng hĩa trong mơ hình phân tíchÁnh xạ 1-1 cho những lớp phân tích đơn giảnÁnhxạ thành nhiều lớp thiết kế nếu lớp phân tích đĩ quá phức tạpLớp phân tích cĩ mức độ phức tạp cao cĩ thể được phát triển thành hệ thống con (subsystem)Sử dụng các giao diệnĐảm bảo hệ thống con cĩ tính độc lập tối đa với các thành phần cịn lạiTìm cách sử dụng lại các hệ thống con, gĩi hoặc các thư viện cĩ sẵn