Thiết kế kiến trúc - nhuloan.weebly.com · Mô hình hoá use case hiện thực hoá dùng...

7 – Thiết kế kiến trúc: Use-case & Class Diag.

Thiết kế kiến trúc

7 – Thiết kế kiến trúc: Use-case & Class Diag. 2

Nội dung trước

Các biểu đồ

Activity Diagram

State Diagram

Component Diagram

Deployment Diagram

7 – Thiết kế kiến trúc: Use-case & Class Diag. 3

Nội dung

Thiết kế kiến trúc:

Tìm hiểu mục đích Thiết kế kiến trúc

Diễn giải về các cơ chế thiết kế, cài đặt và gán chúng

từ giai đoạn phân tích.

Subsystems và interfaces

Thiết kế Use-Case

Kiểm tra tính nhất quán trong Use- case

Tinh chỉnh Use-case realization

Thiết kế Class


Các loại cơ chế kiến trúc

Các cơ chế phân tích (conceptual)

Các cơ chế thiết kế (concrete)

Các cơ chế cài đặt (actual)

4


Các cơ chế phân tích mẫu

Persistency: Cơ chế bền vững tồn tại lâu dài

Communication: Cơ chế trao đổi dữ liệu

Message routing: Cơ chế trao đổi thông điệp

Distribution: Cơ chế xử lý dữ liệu phân tán

Transaction management: Cơ chế quản lý giao tác

Process control and synchronization (resource contention): quản lý các tiến trình

Information exchange, format coversion: trao đổi dữ liệu với các phần mềm khác, chuyển đổi định dạng của dữ liệu

Security: cơ chế bảo mật

Error detection/ handling /reporting: cơ chế xử lý lỗi

Redundancy: cơ chế xử lý thông tin dư thừa

Legacy Interface: cơ chế giao tiếp với hệ thống đã tồn tại

5


Ví dụ

Các cơ chế phân tích sử dụng trong ứng dụng “Đăng ký học phần:

Persistency

Security

Distribution

Legacy Interface

6


Ví dụ

Ánh xạ các Analysis-Class với các cơ chế kiến trúc có từ

bước phân tích Use-case

7


Cơ chế thiết kế và cài đặt

8


Cơ chế Persistence

Mô tả các hành vi liên quan đến cơ chế

Persistence

Mô hình hóa các Transaction

Lưu (ghi) các Persistent Object

Đọc các Persistent Object

Hủy các Persistent Object

9


Thiết kế kiến trúc

Thiết kế lớp: thiết kế thuộc tính, method và mối kết hợp

Kiến trúc ba tầng trong thiết kế phần mềm

Thiết kế use case

Quá trình thiết kế các lớp tầng truy cập dữ liệu: xác định các lớp,

thuộc tính, method và mối kết hợp qua việc phân tích use case

Thiết kề các lớp tầng giao diện: xác định các lớp, xây dựng bản mẫu

(prototype), xác định thuộc tính và method qua việc phân tích use

case

Mô hình hoá use case hiện thực hoá dùng sơ đồ lớp, sơ đồ tương tác

Nâng cấp kiến trúc bằng việc phân chia hệ thống thành các

gói (package)

10


Kiến trúc 3 tầng

11

Tầng giao diện người dùng

(user interface layer),

Tầng tác nghiệp

(business layer),

Tầng truy cập dữ liệu

(data layer).


Kiến trúc mở rộng

12

Tầng Middleware: chứa các thành phần

xây dựng giao diện với các CSDL

(ODBC/JDBC driver)

Tầng System software: chứa các thành

phần về hệ điều hành, giao diện tới các

phần cứng (ví dụ: các driver phần cứng cụ

thể), v.v…


Xác định lớp ở tầng tác nghiệp

Các class ở tầng tác nghiệp không nên quan tâm đến cách

thức nó được hiển thị và được hiển thị bởi ai. Các đối tượng

này được thiết kế để độc lập với bất kỳ một giao diện cụ

thể, và vì vậy cách thức chi tiết để hiển thị một đối tượng

nên tồn tại trong tầng giao diện thay vì trong tầng tác

nghiệp.

Các đối tượng ở tầng tác nghiệp cũng không nên quan tâm

đến nguồn gốc của nó hình thành. Có nghĩa là các đối

tượng này sẽ độc lập về dữ liệu của nó được lấy từ truy cập

CSDL hay là từ truy xuất tập tin.

13


Ví dụ

14

Sơ

đồ lớ

p c

ủa h

ệ t

hống A

TM

tầng n

ghiệ

p v

ụ


User interface layer

Các class ở tầng này đảm nhận hai công việc chính:

Trả lời tương tác người dùng: các đối tượng mức này

phải được thiết kế để chuyển dịch những hành động

của người dùng tới một tình huống xử ly ́ phù hợp. Có

thể là mở hoặc đóng một giao diện khác, hoặc gởi

một thông điệp xuống tầng tác nghiệp hoặc khởi động

một vài tiến trình ở tầng tác nghiệp

Hiển thị các đối tượng tác nghiệp: tầng này phải trình

bày một hình ảnh tốt nhất các đối tượng tác nghiệp

tới người dùng trong một giao diện. Điều này có

nghĩa là một hình ảnh trực quan thao tác được có thể

bao gồm: các textbox, listbox, commbobox, page,

form, menu, toolbar, ….

15


User interface layer

Xác định các lớp tầng giao diện:

Xây dựng sơ đồ lớp mô tả các đối tượng giao

diện

Tạo bản mẫu giao diện (prototype)

Xác định hành vi và thuộc tính cho các lớp

giao diện

Yêu cầu đọc thêm tài liệu về thiết kế giao diện

16


Xác định lớp ở tầng truy cập dữ liệu

Đối tượng tầng này phải truy cập vật lý CSDL ở các vị trí

(CSDL quan hệ, tập tin, internet,…) và xử lý nó. Hai nhiệm

vụ chính của tầng này là:

Chuyển dịch các yêu cầu: chuyển dịch tất cả các yêu cầu

liên quan đến dữ liệu từ tầng tác nghiệp đến một phương

thức truy cập dữ liệu thích hợp (dạng SQL, truy xuất

file,…)

Chuyển dịch kết quả: chuyển dịch tất cả dữ liệu truy cập

được tới các đối tượng tác nghiệp thích hợp.

17


Xác định các đối tượng lưu trữ và persistence

Mỗi dữ liệu sẽ có một thời gian sống (lifetime) khác nhau phân loại:

Là kết quả tạm thời để đánh giá một biểu thức

Các biến trong quá trình thực thi một thủ tục (các tham

số và biến trong phạm vi cục bộ)

Các biến toàn cục và các biết cấp phát một cách tự

động

Dữ liệu tồn tại giữa các lần thực thi một chương trình

Dữ liệu tồn tại giữa các phiên bản của một chương

trình

Dữ liệu tồn tại vượt ngoài phạm vi sống của một

chương trình

18


Xác định các đối tượng lưu trữ và persistence

Các loại dữ liệu persistent sẽ được quản lý bởi hệ

quản trị cơ sở dữ liệu hoặc hệ thống lưu trữ tập

tin. (3 loại sau)

Ba loại dữ liệu đầu tiên đều gọi là dữ liệu tạm thời

(transient data). Là dữ liệu có thời gian sống phụ

thuộc vào thời gian sống của tiến trình sử dụng

nó. Khi tiến trình kết thúc thì dữ liệu này bị giải

phóng

19


Chuyển đổi các đối tượng RDBMS

Các thành phần tương ứng như sau:

Một cột ứng với một thuộc tính (persistent) lớp

Một dòng của bảng ứng với một đối tượng (thể

hiện của một lớp)

Một thủ tục lưu trữ nội (stored procedure) có

thể tương ứng với một method.

20


Ví dụ

Các bước được thiết kế

Tạo các DBClass cần thiết

• DBClass / persistent class

Tích hợp các DBClass vào thiết kế

• Xếp đặt vào package/layer

• Thêm các mối quan hệ từ các persistency client

Tạo/cập nhật interaction diagram để diễn tả:

• Database initialization

• Persistent class access: Create, Read, Update, Delete

21


Persistency: RDBMS: JDBC

22


Persistency: RDBMS: JDBC: Khởi tạo

23


Persistency: RDBMS: JDBC: Create

24


Persistency: RDBMS: JDBC: Read

25


Persistency: RDBMS: JDBC: Update

26


Persistency: RDBMS: JDBC: Delete

27


Nâng cấp kiến trúc

Các analysis class phức :

Tách thành nhiều class

Trở thành một package

Trở thành một subsystem (phức tạp).

Các analysis class đơn giản có thể trở

thành một design class

28


Package: Tính khả kiến của các phần tử

29

Chỉ các public class

mới được tham

chiếu từ bên ngoài

package sở hữu nó

Nguyên lý OO: Encapsulation


Subsystem

Một dạng trung gian giữa package (có thể chứa các phần tử

khác) và class (có hành vi)

Hiện thực hoá 1 hoặc nhiều interface, định nghĩa hành vi của

nó

30


Subsystem & Interface

Hoàn toàn đóng gói hành vi

Thể hiện một khả năng hoàn toàn độc lập, với các

interface rõ ràng (có tiềm năng tái sử dụng)

Mô hình hoá nhiều phương án cài đặt khác nhau

31


Package & Subsystem

Subsystem cung cấp hành vi, package không

Subsystem hoàn toàn đóng gói nội dung của nó,

package thì không

Subsystem dễ dàng được thay thế

32


Subsystem

Subsystem có thể dùng để chia system thành các phần độc

lập về:

Thứ tự, cấu hình, hoặc vận chuyển

Phát triển, chừng nào mà interface còn chưa thay đổi

Triển khai trên các node tính toán phân tán

Thay đổi mà không phá vỡ các phần khác của system

Subsystem còn có thể dùng để:

Phần chia system thành các đơn vị cung cấp độ bảo mật

cao đối với các tài nguyên then chốt

Biểu diễn các sản phẩm có sẵn hoặc các system nằm

ngoài bản thiết kế (chẳng hạn như các component)

33


Xác định subsystem

Tìm kiếm sự cộng tác giữa các đối tượng

Chú ý user interface của system

Chú ý các Actor

Tìm kiếm sự kết dính giữa các class

Xem xét sự phân bố

34


Tìm kiếm các subsystem

Các Analysis classes có thể tiến hoá thành các subsystem

Các Class cung cấp các dịch vụ và/hoặc các tiện ích trọn vẹn

Các Boundary class (user interface và external system interface)

Các sản phẩm sẵn có hoặc các system nằm ngoài thiết kế

Communication software

Database access support

Các kiểu và cấu trúc dữ liệu

Các tiện ích dùng chung

Các sản phẩm ứng dụng đặc thù

35


Identifying Interface

Dựa vào nhiệm vụ của các subsystem

Xác định một tập các interface tiềm năng cho tất

cả các subsystem

Tìm kiếm sự tương tự giữa các interface

Định nghĩa các phụ thuộc của interface

Ánh xạ các interface đến các subsystem

Định nghĩa hành vi được mô tả bới interface

Đóng gói các interface

36


Interface Guidelines

Đặt tên cho Interface

Thể hiện vai trò trong system

Mô tả Interface

Chuyển tải các nhiệm vụ

Định nghĩa Operation

Tên phải phản ánh đúng kết quả của operation

Mô tả operation được thực hiện, tất cả các tham số và

kết quả

Interface documentation

Package các thông tin hỗ trợ: sequence và state

diagrams, kế hoạch kiểm chứng, .

37


Ví dụ: Design Subsystem

38

Design Analysis

Tất cả các analysis class khác đều chuyển thành design class


Mô hình hóa: Subsystem & Interface

39


Subsystem Context

40


Subsystem Context

41


Re-use

Mục đích

Để xác định nơi đâu có thể dùng lại các subsystem hay các

component đã xây dựng dựa trên interface của chúng.

Các bước

Tìm kiếm các interface tương tự nhau

Hiệu chỉnh các interface mới để phù hợp hơn

Thay thế các interface cần có bằng các interface có sẵn

Ánh xạ các subsystem cần có với các component có sẵn

42


Re-use

Bên trong hệ thống đang xây dựng:

Nhận biết sự giống nhau giữa các package và các

subsystem

Bên ngoài hệ thống đang xây dựng:

Các component thương mại

Các component từ các ứng dụng đã xây dựng trước đó

Các component đã được áp dụng kỹ thuật ngược

(reverse engineering)

43


Tinh chỉnh use-case realization

Tinh chỉnh Use-case Realization

Xác định các object có tham gia vào Use-Case

Phân công trách nhiệm cho các object

Mô hình hóa các thông điệp giữa các object

Mô tả các kết quả xử lý từ các thông điệp

Mô hình hóa quan hệ giữa các class liên quan

44


Tinh chỉnh Use-case Realization

Thay thế các class khả dụng bằng các subsystem interface

kết hợp với chúng

Từng bước tích hợp các cơ chế kiến trúc khả dụng

Hiệu chỉnh use-case realization

Các Interaction diagram

View of participating classes (VOPC) diagram(s)

45


Tích hợp subsystem Interface

46

Tất cả các analysis class khác được ánh xạ thành các design class

Analysis Classes Design Elements


Subsystem Interface

47


Tích hợp subsystem interface

48


Đóng gói Subsystem Interactions

Các Subsystem phải được biểu diễn với các interface

của chúng trong interaction diagrams

Các thông điệp đến subsystems được mô hình như

các thông điệp đến subsystem interface

Các thông điệp đến subsystems tương ứng với các

operation của subsystem interface

Các tương tác trong subsystems được mô hình trong

Subsystem Design

49


Tinh chỉnh các Flow & Event

50

Annotate the interaction diagrams


Tổng quan về thiết kế Class

51


Các bước thiết kế Class

Tạo các Design Class ban đầu

Xác định các Persistent Class

Định nghĩa các Operation

Định nghĩa Class Visibility

Định nghĩa các Method

Định nghĩa các trạng thái

Định nghĩa các thuộc tính

Định nghĩa các phụ thuộc

Định nghĩa các mỗi kết hợp

Định nghĩa các quan hệ tổng quát hóa

Giải quyết đụng độ giữa các Use-Case

Xử lý các yêu cầu phi chức năng nói chung

52


Khảo sát khi thiết kế class

Class stereotype

Boundary

Entity

Control

Các design pattern khả dụng

Các cơ chế kiến trúc

Persistence

Distribution

53


Thiết kế các Boundary Class

Các user interface (UI) boundary class

Công cụ xây dựng UI nào sẽ được dùng

Bao nhiêu giao diện được xây dựng

54


Thiết kế các Entity Class

Các Entity object thường thụ động và persistent

Các yêu cầu về hiệu năng có thể buộc ta phải tái xây dựng

Xem thêm bước xác định Persistent Class

55

Analysis Design


Control Class

Chuyện gì xảy ra với các Control Class?

Chúng thật sự cần thiết?

Có phải tách chúng ra không?

Dựa vào đâu để quyết định?

Độ phức tạp

Khả năng thay đổi

Tính phân tán và hiệu năng

Transaction management

56


Xác định Persistent Class

Mọi thể hiện của class đều đòi hỏi phải lưu giữ

trạng thái của nó

Các Persistent class được gán với cơ chế

persistence

Database Design

Chiến lược Persistence phải nhất quán

Ở đây, nhớ rằng các class đều persistent

57


Operation

Mục đích

Ánh xạ các nhiệm vụ đã xác định ơ mức phân

tích thành các operation thực hiện chúng

Những cái cần xem xét:

Tên Operation, signature, và mô tả

Operation visibility

Tầm vực Operation

• Class operation hay instance operation

58


Ví dụ

CourseOffering

59


Tìm kiếm Operation

Các thông điệp trong các Interaction Diag.

60


Đặt tên và mô tả các Operation

Các tên thích hợp cho operation

Chỉ rõ kết quả của operation

Đứng dưới góc nhìn của client

Nhất quán qua tất cả các class

Định nghĩa operation signature

operationName(parameter : class,..) : returnType

Cung cấp một mô tả ngắn, bao gồm ý nghĩa của tất

cả các tham số

61


Operation Signatures

Khi thiết kế operation signatures phải bảo đảm

hàm chứa:

Các tham số truyền theo giá trị hay tham số?

Các tham số có bị thay đổi bởi operation?

Các tham số là optional?

Tham số có giá trị mặc định?

Miền tham số hợp lệ?

Càng ít tham số càng tốt

Truyền các object thay vì “data bits”

62


Additional classes & Relationshops

Additional classes và relationships có thể được

thêm vào để hỗ trợ signature

63


Operation Visibility

Tính khả kiến được dùng để cung cấp tính đóng gói

Giá trị có thể là public, protected, hay private

64

Private operations

Protected operations

Public operation

Ký hiệu tính khả kiến?


Package Element Visibility

Ôn lại:

65

Chỉ các public class

mới được tham

chiếu từ bên ngoài

package sở hữu nó

Nguyên lý OO: Encapsulation


Utility Class

Thế nào là một Utility Class?

Utility là một class stereotype

Dùng để chỉ các class chứa một bộ các chương trình con

miễn phí

Tại sao lại dùng chúng?

Để cung cấp các dịch vụ có thể hữu dụng trong các ngữ

cảnh khác nhau

Để gói các hàm thư viện hay các ứng dụng phi đối tượng

66


Ví dụ

67


Method

Method là gì ?

Mô tả cài đặt của operation

Mục đích

Định nghĩa các khía cạnh đặc biệt của operation

implementation

Những gì cần xem xét:

Các thuật toán đặc biệt

Các object và các operation khác cần sử dụng

Cách cài đặt, sử dụng các attribute và các tham số

Cách cài đặt và sử dụng các mối quan hệ

68


Định nghĩa các trạng thái

Mục đích

Thiết kế ảnh hưởng của trạng thái đối tượng lên hành vi

của nó

Phát triển state-diagram để mô hình các hành vi này

Những gì cần xem xét:

Những object nào có trạng thái đáng kể?

Cách xác định các trạng thái của một object?

Cách ánh xạ state-diagram với phần còn lại của mô hình?

69


Thiết kế và tinh chỉnh State – diag.

70

Mô tả lịch sử đời sống đối tượng

Nhắc lại : xem bài giảng trước về State-Diagram


Attribute

Cần xem xét:

Persistency

Visibility

Name, Type, Default value

71


Tìm và biểu diễn Attribute

Khảo sát mô tả của các method

Khảo sát các trạng thái

Bất kỳ thông tin nào mà class cần duy trì

Mô tả name, type, và giá trị mặc định

attributeName : Type = Default

Tuân thủ qui ước đặt tên của NNLT và dự án

Type phải là KDL cơ sở trong NNLT cài đặt

Các KDL định sẵn, người dùng đ/n

Mô tả tình khả kiến: Public, Private, Protected

72


Các Derived Attribute

Thế nào là derived attribute?

Một attribute mà giá trị co thể tính từ giá trị

của các attribute khác

Khi nào dùng chúng?

Khi không đủ thời gian để tính lại giá trị mỗi

khi cần thiết

Dung hòa giữa thời gian thực hiện và bộ nhớ

sử dụng

73


Quan hệ: dependency

Là một loại quan hệ giữa hai object

Xác định những nơi KHÔNG cần đến các mối

quan hệ cấu trúc

Xem xét: Những gì buộc supplier trở nên nhìn thấy

được bởi client

74


Dependency & Association

Association là quan hệ cấu trúc

Dependency là quan hệ phi cấu trúc

Để .nói chuyện. được, object phải khả kiến

Tham chiếu đến biến cục bộ

Tham chiếu đến tham số

Tham chiếu toàn cục

Tham chiếu đến trường dữ liệu (Field)

75


Local variable visibility

Operation op1() chứa một biến cục bộ có

kiểu ClassB

76


Parameter Visibility

Thể hiện của ClassB được truyền đến cho

thể hiện của ClassA

77


Global Visibility

Thể hiện của Class Utility khả kiến với mọi

đối tượng vì nó là toàn cục (global)

78


Dependency hay Association

Bám vào các quan hệ trong thế giới thực

Bám vào các quan hệ yếu nhất (dependency)

Quan hệ là .thường trực.? Dùng association (field visibility)

Quan hệ là .nhất thời.? Dùng dependency

Nhiều object chia sẻ chung 1 instance

• Truyền instance như tham số (parameter visibility)

• Đặt instance là global (global visibility)

Các object không chia sẻ cùng 1 instance (local visibility)

Cần bao nhiêu thời gian để create/destroy?

Chi phí ? Dùng field, parameter, hoặc global visibility

Chọn lựa nào đúng? CÒN TÙY

79


Tinh chỉnh các mối quan hệ

Xem xét lại

Cân nhắc giữa Association và Aggregation

Cân nhắc giữa Aggregation và Composition

Cân nhắc giữa Attribute và Association

Chiều của quan hệ (Navigability)

Thiết kế Association class

Thiết kế bản số (Multiplicity design)

80

Xem lại bài giảng về phân tích class và các quan hệ giữa class


Parameterized Class (template) là gì?

Là một class dùng để định nghĩa các class khác

Thường dùng cho các container class

Một số container class thông dụng:

• Set, list, dictionary, stack, queue, …

81


Thể hiện của Parameterized Class

Kết buộc tường minh Kết buộc ẩn

82


Ví dụ

83


Optionality

Nếu một link là tùy chọn, hãy chèn thêm

một operation để kiểm tra sự tồn tại của

link

84


Nhắc lại quan hệ tổng quát hóa

Rất dễ nhầm lẫm giữa Generalization và aggregation

Generalization biểu diễn quan hệ “là một” hay

“dạng của”

Aggregation biểu diễn quan hệ “một bộ phận của”

85

?????


Tinh chỉnh quan hệ

86

Một WindowWithScrollbar ”là một” Window

Một WindowWithScrollbar “chứa một” Scrollbar


Sử dụng quan hệ tổng quát hóa

Chia sẻ các thuộc tính và hành vi chung

Chia sẻ cài đặt

Cài đặt cơ chế Polymorphism

…

87


Thực hành

88


Thực hành

Làm việc với công cụ Rational Rose

Thiết kế Use-case & Class

Tinh chỉnh lại các sơ đồ

Chuẩn bị hoàn tất đồ án.

89

Thiết kế kiến trúc - nhuloan.weebly.com · Mô hình hoá use case hiện thực hoá dùng...

Documents

Transcript of Thiết kế kiến trúc - nhuloan.weebly.com · Mô hình hoá use case hiện thực hoá dùng...