Chng 7 XC NH PHN T THIT K

Chương 7 XÁC ĐỊNH PHẦN TỬ THIẾT KẾ (Identify Design Elements) GV: Từ Thị Xuân Hiền 1

Mục tiêu q. Xác định vị trí của xác định phần tử thiết kế trong tiết trình RUP q. 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

Tổng quan xác định phần tử thiết kế GV: Từ Thị Xuân Hiền 3

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

Xác định các lớp và hệ thống con q. Mục đích: �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. q. Lớp phân tích có thể thay đổi qua gia đoạn thiết kế GV: Từ Thị Xuân Hiền 5

Ánh xạ từ lớp phân tích thành các phần tử thiết kế GV: Từ Thị Xuân Hiền 6

Ánh xạ từ lớp phân tích thành các phần tử thiết kế q. 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. q. 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. qÁnh xạ từ Analysis Class sang design elements 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ế. GV: Từ Thị Xuân Hiền 7

Xác định lớp thiết kế q. 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 q. 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) �Hoặc một tổ hợp từ các thành phần trên GV: Từ Thị Xuân Hiền 8

Xác định lớp thiết kế q. 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ổ q. 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ế. q. 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ế q. 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ế q. 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ế q. 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ế.

Nhắc lại: Class and Package q. 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 Name Package Name q. Một 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 q. 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. Package A Package B Package C

Nhóm các lớp thiết kế vào Package q. 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. q. 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. q. 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 các Boundary Classes GV: Từ Thị Xuân Hiền 15

Đóng gói các lớp có chức năng liên quan q. 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. �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ể GV: Từ Thị Xuân Hiền 16

Đóng gói các lớp có chức năng liên quan q. Tiêu chí xác định các lớp có chức năng liên quan: �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ệ (associations, aggregations, …) �Một lớp tạo thể hiện của một lớp khác GV: Từ Thị Xuân Hiền 17

Đóng gói các lớp có chức năng liên quan q. 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). GV: Từ Thị Xuân Hiền 18

Phạm vi của các phần tử trong Package GV: Từ Thị Xuân Hiền 19

Phạm vi của các phần tử trong Package q. 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. q. 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. GV: Từ Thị Xuân Hiền 20

Phạm vi của các phần tử trong Package q. 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: q. Có 3 loại phạm vi: �Public (+): các lớp có thể được truy cập từ bên ngoài package. �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. �Private (-): các lớp private chỉ có thể được truy cập bởi các lớp trong package chứa nó. GV: Từ Thị Xuân Hiền 21

Phạm vi của các phần tử trong Package q. 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 q. Phạm vi của Package cung cấp nguyên tắc đóng gói trong hướng đối tượng. GV: Từ Thị Xuân Hiền 22

Package Coupling GV: Từ Thị Xuân Hiền 23

Package Coupling q. 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

Ví dụ: Registration Package GV: Từ Thị Xuân Hiền 25

Ví dụ: University Artifacts Package: Generalization GV: Từ Thị Xuân Hiền 26

Ví dụ: University Artifacts Package: Associations GV: Từ Thị Xuân Hiền 27

External System Interfaces Package q. 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 GV: Từ Thị Xuân Hiền 28

Subsystems và Interfaces q. 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. q. 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 Hiện thực một hoặc nhiều interface mà xác định rõ hành vi của nó GV: Từ Thị Xuân Hiền 30

Subsystems và Interfaces q. Hiện thực một hoặc nhiều interface mà định that định rõ hành vi của nó <<interface>> Interface Name Interface <<subsystem>> Subsystem Name Realization (Canonical form) Interface Name <<subsystem>> Subsystem Name Realization (Elided form) Subsystem

Subsystems và Interfaces q. Subsystems: �Đóng gói (encapsulate) đầy đủ 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 GV: Từ Thị Xuân Hiền 33

Subsystems và Interfaces q. Subsystem đóng gói sự hiện thực của nó phía sau một hoặc nhiều interface. q. Interface cô lập với phần còn lại của kiến trúc q. Hoạt động của interface được hiện thực bởi một hoặc nhiều phần tử trong subsytem q. 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 GV: Từ Thị Xuân Hiền 34

So sánh Packages và Subsystems q. Một subsystem cung cấp interfaces mà các hành vi bên trong nó có thể được truy cập. q. 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. q. 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. q. Package: không thể thay thế các gói cho nhau

So sánh Packages và Subsystems GV: Từ Thị Xuân Hiền 36

Sử dụng Subsystem q 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 q 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ế. q Subsystem nâng cao mức độ trừu tượng

Xác định Subsystems q. 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 �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ể

Xác định Subsystems q. Căn cứ vào các yếu tố: �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. �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 q 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 q Các hệ thống bên ngoài � Communication software � Database access support � Types and data structures � Common utilities � Application-specific products GV: Từ Thị Xuân Hiền 40

Xác định các Interface q. Mục tiêu: �Xác định interface của subsystems dựa trên trách nhiệm của subsystem q. 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 GV: Từ Thị Xuân Hiền 41

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

Ví dụ: Thiết kế Subsystem và Interface GV: Từ Thị Xuân Hiền 43

Ví dụ: ánh xạ Analysis-Class Design-Element GV: Từ Thị Xuân Hiền 44

Qui ước: Subsystems và Interfaces GV: Từ Thị Xuân Hiền 45

Ví dụ: Subsystem Context: Course. Catalog. System GV: Từ Thị Xuân Hiền 46

Ví dụ: Subsystem Context: Billing System GV: Từ Thị Xuân Hiền 47

Xác định khả năng tái sử dụng q. 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ó. q. 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 GV: Từ Thị Xuân Hiền 48

Những khả năng tái sử dụng q. 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. q. 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. Software

Tái sử dụng bên trong hệ thống GV: Từ Thị Xuân Hiền 50

Cập nhật việc tổ chức các mô hình thiết kế q. Thêm các thành phần mới vào các mô hình thiết kế và đóng gói lại các thành phần q. Thêm các thàn phần mớ vào hệ thống ở một package có sẳn, package này có thể chia ra thành nhiều package GV: Từ Thị Xuân Hiền 51

Cách tiếp cận điển hình GV: Từ Thị Xuân Hiền 52

Cách tiếp cận điển hình q. 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 businessspecific ) q. 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 GV: Từ Thị Xuân Hiền 53

Cân nhắc khi phân tầng (Layer) q. 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. q. Tính biến động (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…)

Cân nhắc khi phân tầng (layer) q. 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. q. Số tầng (Number of layers) �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 GV: Từ Thị Xuân Hiền 56

Ví dụ: Architectural Layers GV: Từ Thị Xuân Hiền 57

Cân nhắc đến sự phân chia (Partitioning) q. Coupling và 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ớ nhau khi thực hiện một chức năng nào đó q. User organization q. Competency (năng lực) và skill (kỹ năng) areas q. System distribution (sự phân tán hệ thống) q. Secrecy (bảo mật) q. Variability (sự thay đổi) GV: Từ Thị Xuân Hiền 58

Ví dụ: Partitioning GV: Từ Thị Xuân Hiền 59

Ví dụ: Application Layer GV: Từ Thị Xuân Hiền 60

Ví dụ: Application Layer Context GV: Từ Thị Xuân Hiền 61

Ví dụ: Business Services Layer GV: Từ Thị Xuân Hiền 62

Ví dụ: Business Services Layer Context GV: Từ Thị Xuân Hiền 63

Ví dụ: Middleware Layer GV: Từ Thị Xuân Hiền 64