Chng 7 Xc nh phn t thit k

Chương 7 Xác định phần tử thiết kế

Nội dung Mục đích của việc xác định phần tử thiết kế, vị trí của xác định phần tử thiết kế trong tiết trình RUP Phân tích tương tác của các lớp phân tích và các phần tử trong mô hình thiết kế Design classes Subsystem interfaces

Vai trò của xác định phần tử thiết kế trong RUP Phân tích kiến trúc định nghĩa các lớp của hệ thống. Tập trung vào lớp trên. Phân tích use case: tập trung vào phân tích yêu cầu, và phân bổ trách nhiệm cho lớp phân tích. Xác định phần tử thiết kế: Tinh chỉnh các chi tiết của công việc kiến trúc. Các lớp phân tích được tinh chỉnh thành các phần tử thiết kế (design classes and subsystems)

Xác định phần tử thiết kế

Xác định phần tử thiết kế Input Artifacts Resulting Artifacts • Supplementary Specifications • Design Model elements • Project Specific Guidelines • Classes • Software Architecture Document • Packages • Analysis Classes • Subsystems • Analysis Model • Design Model

Các bước xác định phần tử thiết kế Xác định các lớp và hệ thống con (classes & subsystems) Xác định giao diện của hệ thống con (subsystem interfaces) Cập nhật tổ chức của mô hình thiết kế (Design Model) Checkpoints

Xác định các lớp và hệ thống con (classes & subsystems) Mục đích của việc xác định lớp và hệ thống con là tinh chỉnh các lớp phân tích thành các phần tử của mô hình thiết kế phù hợp. Lớp phân tích có thể thay đổi qua gia đoạn thiết kế

Ánh ạ từ lớp phân tích thành các phần tử thiết kế

Ánh xạ từ lớp phân tích thành các phần tử thiết kế Lớp phân tích (Analysis classes) xử lý các yêu cầu chức năng chính, và mô hình đối tượng từ “vấn đề” domain. Phần tử thiết kế (design elements) xử lý các yêu cầu phi chức năng và mô hình đói tượng từ “giải pháp” domain.

Ánh xạ từ lớp phân tích thành các phần tử thiết kế Ánh xạ từ lớp phân tích (analysis class) sang phần tử thiết kế là ánh xạ many – to – many vì một lớp phân tích có thể hiện thực nhiều lớp thiết kế.

Xác định lớp thiết kế Một lớp phân tích ánh xạ đến một lớp thiết kế nếu: Nó là một lớp đơn Nó biểu diễn một sự trừu tượng logic đơn Nhiều lớp phân tích phức tạp có thể Tách thành nhiều lớp Trở thành một package Trở thành một subsystem (discussed later)

Xác định lớp thiết kế Ví dụ: Một lớp giao diện thể hiện một giao diện người dùng có thể có nhiều lớp, mỗi lớp trên một cửa sổ Lớp điều khiển có thể trở thành một lớp thiết kế hoặc một phương thức trong lớp thiết kế. Một lớp thực thể đơn có thể trở thành nhiều lớp (Lớp tổng hợp chứa các lớp khác)

Xác định lớp thiết kế Một lớp phân tích có thể trở thành một trong các thành phần sau đây trong mô hình thiết kế Một lớp đơn. Một phần của lớp Một lớp tổng hợp (aggregate) Một nhóm của các lớp kế thừa cùng một lớp. Một nhóm các lớp có chức năng liên quan. Một subsystem. Một quan hệ (relationship).

Xác định lớp thiết kế Một quan hệ giữa các lớp phân tích có thể trở thành một lớp trong mô hình thiết kế Một phần của lớp phân tích có thể được hiện thực bởi phần cứng và không mô hình hóa trong mô hình thiết kế.

Class and Package Class Mô tả một tập các đối tượng có cùng trách nhiệm (responsibilities), các mối quan hệ (relationships), hoạt động (operations), thuộc tính (attributes), và ngữ cảnh (semantics)

Class and Package Cơ chế tổ chức các phần tử có cùng mục đích thành một nhóm. Một phần tử mô hình có thể chứa các phần tử mô hình khác.

Nhóm các lớp thiết kế vào Package Tiêu chí đóng gói dựa trên các yếu tố sau: Đơn vị cấu hình Phân bổ nguồn lực giữa các nhóm phát triển Phản ánh loại người dùng Đại diện cho những sản phẩm hiện có và dịch vụ sử dụng hệ thống.

Nhóm các lớp thiết kế vào Package Khi xác định lớp, nên nhóm chúng thành các package với mục đích tổ chức và quản lý cấu hình. Mô hình thiết kế có thể được cấu trúc thành những đơn vị nhỏ hơn bằng cách nhóm các phần tử của mô hình thiết kế thành các packages và subsystems, và thiết lập mối quan hệ giữa các nhóm. Package giúp cấu trúc tổng thể của mô hình trở nên dễ hiểu hơn.

Đóng gói lớp giao diện

Đóng gói các lớp có chức năng liên quan Tiêu chí xác định các lớp có chức năng liên quan Khi thay đổi hành vi hoặc cấu trúc của lớp này đòi hỏi phải thay đổi hành vi và cấu trúc của lớp kia Loại bỏ tác động của một lớp đến lớp khác Hai đối tượng tương tác qua một số lượng lớn các thông báo hoặc có mối liên quan phức tạp.

Đóng gói các lớp có chức năng liên quan Lớp giao diện có chức năng liên quan đến lớp thực thể, nếu chức năng của lớp giao diện được thể hiện trong lớp thực thể. Hai lớp tương tác với nhau hoặc bị ảnh hưởng bởi cùng một actor. Hai lớp có quan hệ giữa mỗi lớp khác (associations, aggregations, …) Một lớp tạo thể hiện của một lớp khác.

Đóng gói các lớp có chức năng liên quan Tiêu chí để xác định hai lớp không đặt trong cùng một package Hai lớp quan hệ với các actor khác nhau Một lớp là tùy chọn (optional) và một lớp là bắt buộc (mandatory).

Phạm vi của các phần tử package

Phạm vi của các phần tử package Phạm vi (visibility) của các phần tử package được xác định tương tự như cách xác định phương thức và thuộc tính của lớp. Phạm vi của phần tử package xác định cách mà các package có thể truy cập vào các phần tử của một package khác.

Phạm vi của các phần tử package Phạm vi của phần tử package được biểu diễn bằng ký hiệu tiền tố của tên phần tử package: Có 3 loại phạm vi: Public: các lớp có thể được truy cập từ bên ngoài package. (biểu tượng +) Protected: các lớp chỉ được truy cập bởi package chứa nó và các package kế thừa từ package này. (biểu tượng #)

Phạm vi của các phần tử package

Phạm vi của các phần tử package Private: các lớp private chỉ có thể được truy cập bởi các lớp trong package chứa nó. (biểu tượng -) Các phần tử public của một package tạo thành giao diện của gói. Tất cả những phụ thuộc vào package nên phụ thuộc vào các phần tử public Phạm vi của package cung cấp nguyên tắc đóng gói trong hướng đối tượng.

Package Coupling

Package Coupling Ghép cặp (Coupling) giữa các package. Ưu điểm: thể hiện khả năng tái sử dụng Nhược điểm: làm cho hệ thống khó thay đổi và phát triển.

VD: Registration Package

University Artifacts Package: Generalization

VD: University Artifacts Package: Associations

VD: External System Interfaces Package Lớp truy cập hệ thống từ bên ngoài được chia thành các gói giao diện hệ thống.

Subsystems và Interfaces Subsystem là một phần tử mô hình, chứa các phần tử mô hình khác và lớp, do đó có hành vi. Subsystem hiện thực một hoặc nhiều interface để xác định hành vi mà nó thực hiện.

Subsystems và Interfaces

Subsystems và Interfaces Subsystems: Đóng gói đầy đủ các hành vi Đại diện cho một khả năng độc lập với giao diện rõ ràng (có tiềm năng để tái sử dụng) Nhiều biến thể triển khai thực hiện mô hình

Subsystems và Interfaces

Subsystems và Interfaces Subsystem đóng gói sự hiện thực của nó phía sau một hoặc nhiều interface. Interface cô lập với phần còn lại của kiến trúc Hoạt động của interface được hiện thực bởi một hoặc nhiều phần tử trong subsytem

Subsystems và Interfaces Bất kỳ 2 subsystem hiện thực cùng interface thì có thể thay thế cho nhau, điều này có nghĩa là nội dung và hành vi của subsystem có thể thay đổi chỉ cần interface của subsystem là không đổi

So sánh subsystem và package Một subsystem cung cấp interfaces mà các hành vi bên trong nó có thể được truy cập. Package chứa những gì có hành vi, chỉ dùng cho việc tổ chức mô hình và quản lý cấu hình. Với subsystem, nội dung và hành vi bên trong có thể thay đổi, chỉ cần giao diện không đổi. Package: không thể thay thế các gói cho nhau

So sánh subsystem và package

Subsystem Usage Subsystem được dùng để phân hoạch hệ thống thành các phần có thể thực hiện các hoạt động sau đây một cách độc lập: Tổ chức, cấu hình, hoặc chuyển giao Triển khai, với giao diện không thay đổi Triển khai trên hệ thống phân tán Thay đổi không vi phạm các bộ phận khác của hệ thống

Subsystem Usage Subsystems có thể được sử dụng để: Phân hoạch hệ thống thành những đơn vị có thể bảo mật nguồn tài nguyên chính Biểu diễn các sản phẩm sẵn có hoặc các hệ thống bên ngoài trong việc thiết kế. Subsystem nâng cao mức độ trừu tượng

Xác định subsystem Căn cứ vào các yếu tố: Sự tương tác của đối tượng: nếu 1 lớp chỉ tương tác với một lớp khác tạo ra một tập kết quả rõ ràng thì đóng gói thành một subsystem. Optionality: Nếu hành vi tùy chọn của mô hình tương tác, hoặc các tính năng mà có thể được gỡ bỏ, nâng cấp hoặc thay thế thì đóng gói chúng thành một subsystem

Xác định subsystem User interface: tạo subsystem phụ thuộc vào việc ghép cặp (coupling) giao dien người dùng và lớp thực thể Actor: chức năng phân hoạch được sử dụng bởi 2 actor khác nhau, mỗi actor có thể phụ thuộc vào các yêu cầu thay đổi.

Xác định subsystem Class coupling and cohesion: Tổ chức các lớp gắn kết chặt vào cùng subsystem, tách các lớp có gắn kết yếu Substitution(thay thế): Biểu diễn các mức dịch vụ khác nhau cho một khả năng đặc biệt như một subsystem hiện thực trên cùng interface. Distribution: Nếu chức năng đặc biệt nằm trên một node cụ thể thì đảm bảo rằng chức năng của subsystem ánh xạ vào một node duy nhất.

Subsystem ứng viên Các lớp phân tích có thể phát triển thành subsystems: Các lớp có dịch vụ và ứng dụng phức tạp Lớp giao diện Các hệ thống bên ngoài Communication software Database access support Types and data structures Common utilities Application-specific products

Xác định Interfaces Mục đích: Xác định interface của subsystems dựa trên trách nhiệm của subsystem Các bước Xác định interfaces ứng viên cho tất cả subsystems. Tìm điểm tương đồng giữa các giao diện. Xác định sự phụ thuộc của giao diện. Lập bản đồ giao diện cho hệ thống con. Xác định các hành vi quy định bởi các giao diện. Đóng gói giao diện

Interface Guidelines Interface name Phản ánh vai trò của nó trong hệ thống Interface description Truyền tải trách nhiệm Operation definition Tên phản ánh được kết quả của hoạt động Mô tả hoạt động làm gì, tất cả tham số và kết quả.

VD: thiết kế Subsystems và Interfaces

VD: thiết kế Subsystems và Interfaces Trong phân tích use case: Có 2 lớp giao diện: Billing. System Course. Catalog. System Subsystem được xác định để đóng gói các trách nhiệm và cung cấp giao diện cho việc truy cập của các hệ thống bên ngoài.

VD: Analysis-Class-To-Design-Element Map

Qui ước mô hình hóa: Subsystems & Interfaces

Qui ước mô hình hóa: Subsystems & Interfaces Biểu diễn một subsystem như ba phần tử trong mô hình Package <<subsystem>> (Package với ký hiệu <<subsystem>>), Class<<subsystem proxy>> (class với kí hiệu <<subsystem proxy>>) Interface subsystem (class <<interface>>. Bắt đầu với ‘I’. với ký hiệu

Qui ước mô hình hóa: Subsystems & Interfaces <<subsystem>> package chứa các phần tử bao gồm: Subsystem Các sơ đồ giao tiếp mô tả tương tác giữa các phần tử của subsystem để hiện thực hoạt động của subsystem Subsystem hiện thực interface

Qui ước mô hình hóa: Subsystems & Interfaces Lớp <<subsystem proxy>> hiện thực interface, sắp xếp việc thực hiện hoạt động của giao diện của subsystem.

VD: Subsystem Context: Course. Catalog. System

VD: Subsystem Context: Billing System

Xác định khả năng tái sử dụng Mục đích: Xác định subsystems, components đã tồn tại có thể sử dụng lại dựa vào interfaces của nó. Các bước: Tìm các interface tương tự Hiệu chỉnh các interface mới nâng cao tính phù hợp Thay thế interface ứng viên bằng interface hiện tại Ánh xạ subsystem ứng viên bằng các component có sẵn

Những khả năng tái sử dụng Bên trong những hệ thống đang phát triển Những component phổ biến cung cấp các cơ chế kiến trúc cho hệ thống mới. Cần kiểm tra khả năng tương thích và tính phù hợp. Bên ngoài những hệ thống đang phát triển Các component có sẵn trên thị trường Các component từ những ứng dụng trước đây.

Cách tiếp cận lớp điển hình Specific functionality Application Business-Specific Middleware General functionality System Software chứa các hệ thống con, dịch vụ ứng dụng cụ thể. chứa các thành phần nghiệp vụ cụ thể được sử dụng trong nhiều ứng dụng. . chứa các thành phần như: Giao diện người xây dựng GUI, Giao diện hệ quản trị CSDL, Các dịch vụ hệ điều hành nền tảng độc lập, và các thành phần như bảng tính và trình biên tập sơ đồ Phần mềm hệ thống - có chứa các phần mềm cho các cơ sở hạ tầng thực tế như: hệ điều hành, giao diện cho phần cứng cụ thể, trình điều khiển thiết bị, vv

Cách tiếp cận lớp điển hình Trong phân tích kiến trúc: Tập trung vào các lớp mức trên (the application and business-specific ) Trong xác định phần tử thiết kế: Tập trung vào các lớp mức dưới. Các nguyên tắc phân lớp cho package cũng áp dụng cho subsystem

Những cân nhắc khi phân lớp Phạm vi (Visibility) Các phần tử chỉ nên phụ thuộc vào các phần tử trong cùng lớp (layer) và lớp thấp hơn. Volatility Trong lớp cao nhất, đặt những phần tử thay đổi khi yêu cầu người dùng thay đổi Lớp thấp nhất, đặt những phần tử thay đổi khi nến tảng hiện thực thay đổi (phần cứng, hệ điều hành…)

Những cân nhắc khi phân lớp Nguyên tắc (Generality) Các phần tử mô hình trừu tượng có xu hướng đặt ở lớp thấp. Số lớp Hệ thống nhỏ: 3 -4 layers Hệ thống phức tạp: 5 -7 layers

Các phần tử thiết kế và kiến trúc Các phần tử thiết kế được xác định cần phải được phân bổ vào các lớp cụ thể trong kiến trúc

VD: Các lớp kiến trúc

VD: Các lớp kiến trúc Các lớp được xây dựng trên các lớp kiến trúc ban đầu đã xác định trong phân tích kiến trúc. Lớp Middleware và các gói cơ sở tái sử dụng được thêm vào trong hoạt động này, cung cấp các tiện ích và dịch vụ nền tảng độc lập. Các gói Base Reuse chứa các phần tử thiết kế tái sử dụng chung và các mẫu (pattern).

Partitioning Coupling and cohesion Cohesion: tập trung vào nhiệm vụ của từng module Coupling: chỉ độ phụ thuộc giữa các module với nhau khi thực hiện một chức năng nào đó. User organization Competency(năng lực) và skill (kỹ năng) areas System distribution (sự phân tán hệ thống) Secrecy areas Variability areas Try to avoid cyclic dependencies.

VD: Partitioning

VD: Partitioning • Maximum coupling and cohesion within packages versus minimal coupling between packages. • The dependencies between packages reflect the dependencies between the classes contained within the packages

VD: Application Layer Lớp Application chứa các phần tử thiết kế của một ứng dụng cụ thể

VD: Application Layer Context

VD: Application Layer Context Registration package phụ thuộc vào University Artifacts package. External System Interface đóng gói các giao diện hệ thống bên ngoài GUI Framework và Security Interfaces đóng gói thành security framework

VD: Business Services Layer

VD: Business Services Layer Context

VD: Middleware Layer

Checkpoints Tổng quát Có cung cấp bức tranh toàn cục về các dịch vụ của các gói khác nhau? Có tìm ra một giải pháp tương tự được sử dụng rộng rãi trong vấn đề domain? Layers Có nhiều hơn 7 layers? Subsystems Phân vùng cho subsystem có được thực hiện một cách logic và nhất quán trong toàn bộ mô hình không?

Checkpoints Packages Tên của package có phù hợp với trách nhiệm của các lớp chứa bên trong package không? Sự phụ thuộc của package có tương ứng với mối quan hễ giữa các lớp chứa bên trong gói khong? Các lớp chứa bên trong package có đáp ứng tiêu chí phân chia package không?

Checkpoints Các lớp hoặc sự cộng tác của các lớp trong một gói có thể được tách ra thành một gói phần mềm độc lập không? Tỷ lệ giữa số lượng của các gói và số lượng các lớp có phù hợp không?

Checkpoints Classes Tên của không? mỗi lớp có phản ánh được vai trò của lớp Is the class cohesive (i. e. , are all parts functionally coupled)? Tất cả phần tử lớp đều cần thiết bởi hiện thực use case không? Tên của aggregations và associations có mô tả được mối quan hệ không? Quan hệ multiplicities có chính xác không?

Review: Identify Design Elements What is the purpose of Identify Design Elements? What is an interface? What is a subsystem? How does it differ from a package? What is a subsystem used for, and how do you identify them? What are some considerations? layering and partitioning