Viết tư liệu kiến trúc phần mềm, Phần 4 pdf

Viết tư liệu kiến trúc phần mềm, Phần 4: Phát triển mô hình chức năng
Chuyển từ tóm tắt sang các cấu trúc nhiều chi tiết hơn
Tilak Mitra, Kiến trúc sư IT cao cấp, IBM
Tóm tắt: Trong loạt bài này, hãy tìm hiểu lý do và cách bạn sẽ viết tư liệu kiến
trúc phần mềm. Trong bài viết này, ta hãy tìm hiểu cách phát triển và viết tư liệu
các tạo tác thiết kế mức vĩ mô của các khía cạnh chức năng củ
a hệ thống kiến trúc
của bạn. Khung nhìn mô hình chức năng nhằm vào các kỹ thuật mà bạn có thể sử
dụng để phân tách phạm vi bài toán thành một tập các tạo tác kiến trúc. Hãy tìm
hiểu cách xây dựng trên chúng hơn nữa để tạo ra các cấu trúc chi tiết nhiều hơn
nữa. Ba mức phổ biến của việc chế tạo — mức logic, mức đặc tả, và mức vật lý —
cũng được thảo lu
ận.
Giới thiệu
Trong Phần 1 của loạt bài này, bạn đã tìm hiểu về tầm quan trọng của một cách
tiếp cận có nguyên tắc để viết tư liệu kiến trúc phần mềm và về các cơ chế mà có
thể nắm bắt các tạo tác kiến trúc sử dụng trong một quy trình phát triển điển hình.
Phần 2 tập trung vào ngữ cảnh hệ thống, nó là tạo tác kiến trúc quan trọng đầu tiên,
và cách viết tư liệu thông tin ngữ cảnh hệ thống với các sơ đồ và luồng thông tin.
Trong Phần 3 bạn đã tìm hiểu cách phát triển và viết tư liệu tổng quan kiến trúc
cho hệ thống hoặc ứng dụng của bạn.
Bài viết này tập trung vào các thành phần kiến trúc chức năng của hệ thống. Hãy
tìm hiểu cách các khối cơ bản của kiến trúc được phân tách như thế nào thành các
hình dựng mứ
c thiết kế mà cùng thực hiện các yêu cầu chức năng của ứng dụng
hoặc hệ thống sẽ được xây dựng.
Mỗi khối cơ bản của kiến trúc mô tả, ở một mức cao, các tính năng của một thành
phần trong ngữ cảnh của giải pháp toàn thể. Các thành phần giúp xác định kế
hoạch kiến trúc chi tiết và được đặc trưng rộng rãi như chức năng hoặc tác nghiệp
về bản chất. Nhưng chúng cũng quá thô thiển chưa thể chuyển ngay sang nhóm
phát triển để chuyển đổi chúng thành mã.

Bài viế
t này cũng cung cấp các lời khuyên về cách chuyển đổi các thành phần
chức năng sang các tạo tác thiết kế mức vĩ mô. Tiêu điểm là nhằm vào việc viết tư
liệu các tạo tác thiết kế vĩ mô, còn gọi là mô hình chức năng. Hãy tìm hiểu về các
mức khác nhau của một mô hình thiết kế chức năng, đi từ chung đến riêng nhiều
hơn, và cách viết tư liệu các mức kỹ năng khác nhau.

Về đầu trang
Tổng quan mô hình chức năng
Mô hình chức năng, còn gọi là mô hình thành phần, tập trung vào xây dựng nên
kiến trúc chức năng của hệ thống bằng cách phân tách phạm vi bài toán thành một
tập các thành phần không chồng chéo và cộng tác với nhau. IBM Rational®
Unified Process® (RUP®) phát biểu rằng việc mô hình hoá phải được thực hiện ít
nhất ở hai mức khác nhau: mức phân tích và mức thiết kế. Khác biệt chủ yếu giữa
hai mức là mức độ
đặc trưng mà chúng minh họa. Các mô hình thiết kế xây dựng
trên các mô hình phân tích bằng cách bổ sung các chi tiết chứa đủ thông tin để
thuận tiện cho mức mô hình hoá thứ ba — tức mô hình thực hiện. Các mô hình
phân tích và thiết kế có thể được gọi là thiết kế vĩ mô, trong khi mô hình hoá thực
hiện là thiết kế vi mô.
Bài viết này bàn luận về các phần tử của thiết kế vĩ mô, mà có thể được coi là một
bộ phận của một khung nhìn chứ
c năng của kiến trúc. Nó xây dựng trên nguyên
tắc mà mô hình hoá phân tích và mô hình hoá thiết kế nằm trong phạm vi kiến trúc.
Mô tả chi tiết mức cao hơn của các mô hình thiết kế và mô hình thực hiện nằm
trong phạm vi thiết kế.

Về đầu trang
Viết tư liệu mô hình chức năng
Mô hình chức năng được xây dựng thành ba bước lặp, với các thiết kế ở:

• Mức logic.
• Mức đặc tả.
• Mức vật lý.
Với mỗi bước kế tiếp nhau, bạn chuyển từ các mức trừu tượng cao hơn sang các
tạo tác thiết kế và thực hiện riêng hơn. Phần còn lại của bài viết này bàn luận về ba
bước.


Về đầu trang
Thiết kế ở mức logic
Một số trường phái muốn để mức logic của thiết kế ở các quan niệm, với các
thông tin chỉ theo thuật ngữ về khái niệm nghiệp vụ, không có trong công nghệ
thông tin. Mức khái niệm hoá đó là có thể chấp nhận được, nhưng hiện nay có một
nguyên lí gọi là “kiến trúc nghiệp vụ”, mà tập trung vào việc xác định phạm vi
kinh doanh thông qua một tập các khái niệm và phác thảo hướng kinh doanh. Kiến
trúc kinh doanh đang trở thành một kỹ thuật phổ biến để xác định các khía cạnh
kinh doanh của một kiến trúc doanh nghiệp. Bài viết này sẽ không nhằm tới các
cấu trúc khái niệm trong thiết kế mức logic của kiến trúc chức năng.
Trước khi tìm hiểu về các hình dựng logic của mô hình chức nă
ng, trước tiên bạn
phải hiểu được khả năng tạo vết của các tạo tác trong phạm vi kinh doanh. Khả
năng dò theo được các hình dựng kiến trúc công nghệ thông tin cho phạm vi kinh
doanh là rất quan trọng. Bạn có thể sau đó đảm bảo rằng các tư liệu kiến trúc là
gắn kết, thẳng hàng so với các tác động điều hướng kinh doanh (business drivers),
các đích, và các bài toán mà kiến trúc đó sẽ giải. Các nhà phân tích kinh doanh sẽ
phân tích phạm vi kinh doanh và nắm bắt các yêu c
ầu kinh doanh ở một định dạng
độc lập với công nghệ (technology-neutral). Họ cố gắng nắm bắt “những gì” sẽ
được xây dựng, và để “cách làm thế nào” cho các kiến trúc sư công nghệ thông tin,
các nhà thiết kế, và nhóm thực hiện.

Thường thì, các nhà phân tích kinh doanh định tên tập các phạm vi kinh doanh mà
mô hình nghiệp vụ của kinh doanh doanh nghiệp được phủ hoặc động chạm bài
toán cần giải. Mỗi phạm vi kinh doanh, chẳng hạn như kế toán, hoàn thiệ
n đơn
hàng, v.v…, được phân tách sâu hơn thành tập các vùng chức năng. Phạm vi của
sự phân tích vùng chức năng yêu cầu nhà phân tích kinh doanh định danh tập các
chức năng kinh doanh trong một phạm vi kinh doanh, mà nó gắn kết về mặt logic
đủ để làm thành một đơn vị chức năng đơn. Nhà phân tích kinh doanh phân loại
theo vùng chức năng các yêu cầu trong phạm vi của sáng kiến đó và cái mà sau đó
được chuyển đến nhóm công nghệ thông tin.
Thiết kế hệ thống con
Một hệ thống con là hình dựng công nghệ thông tin hạng nhất, là một biểu diễn
trực tiếp của các vùng chức năng. Một vùng chức năng trong phạm vi kinh doanh
có thể được thể hiện và thực hiện bởi một hoặc nhiều hệ thống công nghệ thông tin
con. Một hệ thống con là một nhóm các thành phần gắn kết mà có xu hướng thay
đổi cho nhau, nên các thay đổi (dưới dạng cải tiến hoặc sửa chữa) có thể được
kiểm soát sao cho hiệu quả của chúng được cục bộ hoá trong biên hệ thống con.
Đúng như các vùng chức năng được ánh xạ đến và phân tách thành các hệ thống
công nghệ thông tin con, các chức năng kinh doanh được thực hiện bởi một hoặc
nhiều các chức năng công nghệ thông tin. Các chức năng công nghệ thông tin này
về mặt logic được nhóm với nhau, bao gói, và thực hiện như một đơn vị đơn l
ẻ.
Đơn vị đó là hệ thống công nghệ thông tin con. Bạn có thể thực hiện các chức
năng công nghệ thông tin bằng cách sử dụng một nhóm các thành phần phần mềm,
như vậy một hệ thống con là một nhóm các thành phần phần mềm.
Các chức năng công nghệ thông tin được để lộ ra bởi một tập các giao diện ở mức
hệ thống con. Một hoặc nhiều thành phần phầ
n mềm bên trong hệ thống con cài
đặt một giao diện. Các hệ thống con nhóm lại cùng với các thành phần mà có xu
hướng thay đổi, như vậy các thay đổi (dưới dạng cải tiến hoặc sửa chữa) được

kiểm soát và hiệu quả của chúng được cục bộ hoá trong biên hệ thống con. Các hệ
thống con nuôi dưỡng sự phát triển song song, với các hệ thống con và giao diện
của chúng được thiết kế trước. Các đội cài
đặt phát triển các chi tiết bên trong của
hệ thống con, khi vẫn tuân thủ các ràng buộc với giao diện bên ngoài.
Hoạt động đầu tiên trong giai đoạn này là xác định được các hệ thống công nghệ
thông tin con, để sau đó chúng có thể được viết tư liệu. Đối với mỗi hệ thống con,
giao diện cấp cao nào của nó cũng đều cần được định tên và viết tư liệu. Tôi
khuyên bạn nên viết tư liệu các t
ạo tác sau đây đối với mỗi hệ thống con:
Mã nhận dạng hệ thống con (Subsystem ID)
Cung cấp một mã nhận dạng duy nhất đối với mỗi hệ thống con để dễ tham
chiếu đến chúng trong thiết kế.
Tên hệ thống con
Cung cấp một tên cho mỗi hệ thống con, chẳng hạn như quản trị tài khoản,
quản trị giao dịch, v.v….
Các chức năng
Một danh sách các chức năng công nghệ thông tin mà hệ thống con lộ ra
qua cài đặt bên trong của nó. Tôi khuyên rằng nên xác định tậ
p này bằng
cách phân tích các ca sử dụng hệ thống, nhóm chúng theo logic, và gán
chúng cho hệ thống con đã có tên.
Các giao diện
Một danh sách các giao diện mà hệ thống con hỗ trợ hoặc để lộ. Ví dụ,
trong một hệ thống con quản trị tài khoản, một giao diện có thể gọi là “rút
tiền.” Ở mức này, một mô tả dạng văn bản về giao diện và các tác nghiệp
của nó sẽ là đủ.
Khuôn mẫu của bạ
n sẽ trông giống như thế này:
Bộ định danh tạo tác Ví dụ

Mã nhận dạng hệ thống con
SUBSYS-01
Tên hệ thống con
My Subsystem
Chức năng
F1,F2
Giao diện
I11, I12, I21

Bạn phải tạo ra thể hiện UML của các hệ thống con và các mối phụ thuộc
(interdependencies) của chúng như là một phần tư liệu cho các tạo tác thiết kế ở
mức logic. Hình 1 trình bày một ví dụ.

Figure 1. Các hệ thống con và các phụ thuộc của chúng

Thiết kế thành phần (mức logic)
Sau khi bạn đã định tên các hệ thống con và các nhiệm vụ đã tư liệu hóa của chúng,
bước tiếp theo là xác định một tập các thành phần phần mềm mức cao mà cùng
thực hiện các giao diện được hệ thống con để lộ ra. Một hệ thống công nghệ thông
tin con là một biểu hiện cao cấp nhất của vùng chức năng đối với phạm vi công
nghệ thông tin. Như vậy, các chức năng công nghệ thông tin trong một hệ thống
con có thể được phân đoạn dựa trên thực thể kinh doanh cốt lõi mà chúng nhằm
đến. Ví dụ, đối với hệ thống con quản trị tài khoản có thể có một thành phần phần
mềm mà cung cấp các tài khoản tiết kiệm, trong khi một cái khác tập trung vào
thực hiện các tính năng của tài khoản séc.
Sau khi các thành phần được định danh ở một m
ức logic, bạn cần định danh được
các ca sử dụng có ý nghĩa kiến trúc. Phân tích các ca sử dụng, sau đó chọn các
nhóm phụ mà có nghĩa từ quan điểm kiến trúc. Đối với mỗi ca sử dụng có ý nghĩa
kiến trúc, bạn có thể sử dụng các sơ đồ thành phần-tương tác để chi tiết hoá về

cách ca sử dụng có thể được định danh như thế nào qua các chức năng mà được để
l
ộ ra bởi các thành phần mà bạn đã định tên.
Một sơ đồ cộng tác cho thấy cách các thành phần tương tác bằng cách tạo ra các
liên kết giữa các thành phần, và bằng cách đính kèm các thông điệp vào các liên
kết này. Tên của thông điệp biểu thị ý định gọi thành phần khi nó tương tác với
thành phần liên quan. Ở mức logic này, bạn có thể nghĩ rằng các thông điệp là các
phép toán giả trên các thành phần. Các phép toán giả này biểu hiện chính chúng
như
là các trách nhiệm của thành phần đó. Hình 2 giới thiệu một sơ đồ cộng tác
mẫu.

Hình 2. Tương tác thành phần cao cấp

Tôi khuyên bạn nên viết tư liệu các thông tin sau đây đối với mỗi thành phần và hệ
thống con:
Mã nhận dạng hệ thống con
Biểu thị định danh duy nhất của hệ thống con mà thành phần được nhắm
đến thuộc về nó.
Mã nhận dạng thành phần
Cung cấp một định danh duy nhất (ID) cho thành phần.
Tên thành phần
Cung cấp tên cho thành phần. Tên phải theo dễ hiểu, dựa trên các thực thể

kinh doanh mà thành phần tập trung vào.
Các trách nhiệm của thành phần
Một mô tả dạng văn tự về một tập các trách nhiệm được gán cho thành
phần và mong được thực hiện.
Khuôn mẫu của bạn sẽ trông giống như thế này:
Bộ định danh tạo tác Ví dụ

Mã nhận dạng hệ thống con
SUBSYS-01
Mã nhận dạng thành phần
COMP-01
Tên thành phần
My Component
Trách nhiệm của thành phần
F1, F2, F3


Về đầu trang
Thiết kế mức đặc tả
Thiết kế mức đặc tả là tên gọi khác của thiết kế chi tiết. Bạn xây dựng trên các
hình dựng mức logic, và bổ sung các chi tiết cho từng thành phần đến khi nào:
• Các giao diện cho mỗi thành phần là xác định tốt.
• Các phần tử dữ liệu do các hệ thống con sở hữu được định danh và được
chi tiết hóa.
• Các trách nhiệm của các thành phần được bổ sung chi tiết hơn.
Tôi khuyên bạn nên tiến hành bốn bước chính trong thực hành thiết kế đặc tả.
Đoạn còn lại của phần này bàn luận về từng bước.
1. Bảng ma trận trách nhiệm của thành phần
Ở bước này, bạn xây dựng lên bảng ma trận ban đầu, được phát triển trong
lúc thiết kế ở mức logic. Các bổ sung chủ yếu vào bảng matrix hiện tại là
một tập nhiều chi tiết hơn và gạn l
ọc hơn của các trách nhiệm của thành
phần.
Các trách nhiệm hiện thời đã được định danh dựa trên các đặc tả chức năng
(thu được bằng cách phân tích các ca sử dụng). Các yêu cầu phi chức năng
NFR (nonfunctional requirements) đã được lấy ra khỏi ứng dụng. Các NFR
thường được viết tư liệu trong một tạo tác tư liệu riêng rẽ. Bạn nên tiến

hành phân tích cẩn thận mỗi NFR, xác định ra một thành phầ
n, và gán việc
thi hành trách nhiệm đó cho thành phần được xác định.
Các luật nghiệp vụ hiện đã trở thành một thành phần chủ đạo của bất kỳ
ứng dụng nào. Các luật nghiệp vụ là một biểu hiện của các quyết định kinh
doanh trong lĩnh vực lập trình công nghệ thông tin. Các luật và chính sách
kinh doanh thay đổi thường xuyên đến nỗi các doanh nghiệp phải cảm nhận
được và phản hồi các thay đổi trên thị tr
ường và nhanh chóng thích ứng với
các hệ thống công nghệ thông tin của chúng để duy trì một lợi thế cạnh
tranh và nổi bật.
Các luật nghiệp vụ không thể nhúng vào logic lập trình lõi. Việc nhúng vào
các luật nghiệp vụ sẽ làm cho các hệ thống hợp lệ khó thay đổi. Các luật
nghiệp vụ cần được đưa ra ngoài để chúng có thể được thay đổi vào thời
gian chạy. Tuy nhiên, các nguyên tắc như vậy cần được định danh và chỉ

định như một trách nhiệm của một thành phần. Các thành phần như vậy có
thể tận dụng các tính năng của một phương tiện các luật nghiệp vụ để định
danh các phần trách nhiệm, được xác định từ danh mục các luật nghiệp vụ.
Trong một vài trường hợp, một thành phần tổng thể có thể được dùng làm
giao diện với các API, thể hiện qua hệ thống luật (rule engine).
Lúc này, bảng ma trận trách nhiệm của thành phần được tăng lên với các
chi tiết được viết tư liệu trước đó. Một trích xuất tin (snippet) của khuôn
mẫu có thể trông giống như thế
này:
Bộ định danh tạo tác Ví dụ
Mã nhận dạng hệ
thống con
SUBSYS-01
Mã nhận dạng thành

phần
COMP-01
Tên thành phần
My Component
Trách nhiệm của
thành phần
F1, F2, F3
NFR 001 - Mô tả và liên kết đến tài liệu NFR
NFR 005
BRC 001 - Mô tả và liên kết đến tài liệu danh mục các
luật nghiệp vụ (BRC)
BRC 005

2. Đặc tả giao diện đối với các thành phần
Trong lúc thiết kế ở mức logic, bạn đã định tên các giao diện và liên kết
chúng với các hệ thống con. Bây giờ bạn đã có mô tả chi tiết các trách
nhiệm mà mỗi thành phần mong được thực hiện, bạn có thể tập trung vào
xác định và thiết kế giao diện.
Một giao diện là cơ chế mà qua đó một thành phần để lộ các chức n
ăng của
nó ra thế giới bên ngoài. Về mặt kỹ thuật, giao diện là tập các phép toán
hoặc phương thức. Đặc tả giao diện đòi hỏi thách thức tới việc định tên các
phép toán và nhóm chúng trong biên giao diện.
Để bắt đầu, bạn phải phân tích từng ca sử dụng mà một thành phần sở hữu,
giữ trong đầu các nhân tố chủ yếu về độ phức tạp và sự gắn kết. Các ca sử
d
ụng hệ thống mà rất nhỏ về bản chất, chẳng hạn việc lấy một hồ sơ khách
hàng, sẽ được xếp là một phép toán (trên một giao diện).
Mặc dù vậy, các ca sử dụng thường được viết tư liệu ở các mức khác nhau
và đôi khi ở các mức không nhất quán về mức độ chi tiết. Một vài ca sử

dụng được viết ra sao cho luồng chính là để tạo ra mộ
t thực thể riêng, nơi
mà các luồng chọn lựa thay thế của nó là để cập nhật hoặc xoá thực thể đó.
Các ca sử dụng như vậy cần được xử lý bằng một trong hai cách:
• Thay đổi lại (refactor) ca sử dụng, và tách nó để các hoạt động chính
trên thực thể nằm trong các ca sử dụng riêng của chúng.
• Xử lý ca sử dụng ở mức một giao diện, nơi mà giao diện là tổng tập
các phép toán gắn kết về mặt logic.
Sau khi bạn đã định danh các phép toán qua việc phân tích ca sử dụng, giao
diện phải được xác định chính thức. Cách tiếp cận mà tôi khuyên bạn, như
đã nói trên đây, là nhóm các phép toán mà đang có sự cố kết về mặt logic,
tác động đến cùng một tập các thực thể kinh doanh, và bị loại trừ lẫn nhau
từ phần còn lại của tập phép toán đó. Một việc nhóm logic của các phép
toán như vậy được định nghĩa như là một giao diện, nó là một cấu trúc hạng
cao cấp nhất trong Lập trình Hướng Đối tượng. Bài tập này xác định một
tập các giao di
ện như vậy mà sau đó được để lộ bởi một thành phần cho
trước.
Bước đầu tiên của thiết kế giao diện là viết tư liệu và mô hình hoá các giao
diện và các phép toán của chúng với danh sách các tham số và ký hiệu
riêng thích hợp. Ví dụ:
Bộ định danh tạo tác Ví dụ
Mã nhận dạng thành phần
(nó thuộc về)
COMP-01
Tên và mã nhận dạng giao
diện
My Interface, INT-001
Phép toán giao diện
Cung cấp các ký hiệu riêng cho mỗi phép toán cùng

với các mô tả của chúng

Phần thứ hai của nhiệm vụ này là xác định cách giao diện phụ thuộc vào
các giao diện khác. Có hai kiểu phụ thuộc của giao diện: khi chúng miêu tả
các phụ thuộc về giao diện mà nằm trong một ranh giới hệ thống con, và
khi chúng miêu tả các phụ thuộc về giao diện mà được để lộ ra bởi các hệ
thống con khác. Sự phụ thuộc thường ở dạng tư liệu như một sơ đồ lớp
UML, nơi mỗi lớp được rập khuôn như là một giao diện, và các đường liên
hợp (association lines) được sử dụng để miêu tả rõ ràng các phụ thuộc.
Tư liệu đầy đủ tạo ra một bước ti
ến xa hơn và cung cấp một mô tả bằng văn
bản mà có đủ tư cách và chi tiết hoá về tính chính xác của sự phụ thuộc. Ví
dụ, Interface1::Operation11 có một sự phụ thuộc hậu điều kiện (post-
condition dependency) về Interface2::Operation21. Đây là được cách tiếp
cận nên tiến hành, nhưng các thực tế về thời gian và chi phí có thể đôi khi
hạn chế sự tự do của chúng ta khi làm như vậy.
Hình 3 trình bày một sơ đồ
điển hình của sự phụ thuộc giao diện. Các ranh
giới hệ thống con cho giao diện cũng được thể hiện.

Hình 3. Sự phụ thuộc giao diện bên trong và giữa các hệ thống con

3. Xác định và liên kết dữ liệu đến các hệ thống con
Đến bây giờ, trọng tâm là các trách nhiệm của thành phần. Một trong những
nguyên lý quan trọng của thành phần thiết kế là định danh các thực thể dữ
liệu được sở hữu bởi một hệ thống con và cách chúng được sử dụng bởi các
thành phần trong hệ thống con để thực hiện các trách nhiệm của chúng.
Mô hình dữ liệu logic được s
ử dụng như một đầu vào cho nhiệm vụ này.
Mô hình dữ liệu logic định tên các thực thể kinh doanh cốt lõi, trong phạm

vi của hệ thống sẽ được xây dựng. Một hệ thống con có một tập các trách
nhiệm cần hoàn thành, được cài đặt nhờ các thành phần được gói trong hệ
thống con. Các thành phần hiện các trách nhiệm thông qua các giao diện, và
cụ thể hơn là qua các phép toán giao diện.
Mỗi phép toán giao diện đòi hỏi dữ liệu được tính để thực hiện các chức
năng. Các tham số về các phép toán giao diện là có tính gợi mở của một
nhóm của các thực thể dữ liệu mà được sử dụng trong các kết hợp đóng. Sử
dụng nguyên tắc chỉ đạo đơn giản này để giúp định danh các thực thể dữ
liệu và liên kết chúng với các hệ thống con:
1.
Phân tích danh sách tham số về các giao diện.
2. Ánh xạ các tham số đến các thực thể kinh doanh gần nhất hoặc kiểu
dữ liệu trong mô hình dữ liệu logic.
3. Lặp lại bước 1 và 2 đối với mỗi giao diện trên một thành phần.
4. Giữ một danh sách chạy của các kiểu dữ liệu mà được xác định.
5. Lặp lại bước 1 - 4 đối với các thành phần trong một hệ thống con.
6.
Hợp nhất danh sách các kiểu dữ liệu đã xác định trong bước 1 - 5.
Hãy vẽ một ranh giới quanh kiểu dữ liệu đã có tên từ mô hình dữ liệu logic,
và liên kết các kiểu dữ liệu với hệ thống con. Sau khi bạn làm việc này đối
với tất cả các hệ thống con, bạn có thể gặp một tình huống phổ biến mà một
vài kiểu dữ liệu được định tên đôi khi thuộ
c về hơn một hệ thống con. Đối
với các kiểu dữ liệu như vậy, việc hợp lý hoá kiến trúc đòi hỏi phải:
• Phân tích và đánh giá hệ thống con nào thực hiện các phép toán ban
đầu về kiểu dữ liệu.
• Xác định hệ thống con mà sẽ chủ yếu chịu trách nhiệm sở hữu kiểu
dữ liệu.
Với việc sở hữu dữ liệu được xác định, các tham số giao diện bây giờ được
tinh chỉnh để sử dụng kiểu dữ liệu thực để xác định các đầu vào và đầu ra.

Bạn phải vẽ một khung nhìn về phụ thuộc giao diện, bằng cách sử dụng các
chú giải UML chuẩn, nó xác định rõ ràng các phụ thuộc về giao diện đến
các kiểu dữ liệu. Một bức tranh thực sự đáng giá hàng nghìn lần từ khi viết
tư liệu các tạo tác kiến trúc phần mềm. Trong trường hợp này, tốt hơn là sử
dụng các tạo tác mô hình UML để miêu tả hệ thống con và sự sở hữu thành
phần của các thực thể dữ liệu. Thường không đòi hỏi phải cung cấp các mô
tả văn bản đối với mỗi kiểu dữ liệu. Bạn sẽ tham chiếu tư liệu mô hình dữ
liệu logic để có các mô tả chi tiết.
4. Sơ đồ Tương tác-thành phần
Trong khi thiết kế ở mức logic, bạn đã phát triển và viết tư liệu một sơ đồ
tương tác-thành phần mức cao cấp. Ở mức độ đó, các thành phần đã được
gọi chỉ qua các phép toán giả. Từ đó cho đến nay, nhiều đặc tả chi tiết đã
được phát tri
ển, bảng ma trận trách nhiệm của thành phần đã được xây
dựng, các giao diện đã được quy định, và các kiểu dữ liệu đã được xác định
và sự sở hữu được gán cho các hệ thống con.
Các ca sử dụng được chọn mà khai thác từng phép toán trên các giao diện
mà các thành phần để lộ ra. Các ca sử dụng có ý nghĩa kiến trúc có thể cần
được bổ sung các ca sử dụng khác để cung cấp độ bao phủ đố
i với tất cả
các phép toán trên mỗi giao diện. Đối với mỗi ca sử dụng, sử dụng các sơ
đồ chuỗi UML để vẽ ra sơ đồ thành phần-tương tác. Mỗi sơ đồ thành phần-
tương tác bắt đầu từ một bên yêu cầu nguồn (originating requester) (tác
nhân), gọi các phép toán riêng trên một loạt các thành phần mà cùng thực
hiện ca sử dụng, và trả lại kết quả cho bên yêu cầu nguồn. Hình 4 trình bày
một ví dụ
.
Đối với mỗi sơ đồ chuỗi UML, một mô tả dạng văn bản về việc gọi từng
bước các phép toán trên các thành phần cũng được viết tư liệu.
Ở giai đoạn này, mỗi hệ thống con đều được xác định chính xác, với mỗi

thành phần có một tập các trách nhiệm mà đến lượt mình được lộ ra qua
một hoặc nhiều giao diện. Mỗi giao diện được xác định b
ằng một tập các
phép toán, và mỗi phép toán được xác định thông qua một danh sách các
tham số vào và ra. Mỗi tham số được ánh xạ đến một kiểu dữ liệu mà được
hệ thống con sở hữu.
Các hệ thống con cũng đòi hỏi việc tinh lọc (refinement) và thay đổi lại
(refactoring). Nếu một hệ thống con đã phát triển để đảm nhận quá nhiều
trách nhiệm, có thể nó sẽ quá phức tạp để thự
c hiện. Nếu xem nó là quá
mỏng manh về các đặc tính, bạn có thể cần hợp nhất lại và trộn nó vào hệ
thống con liên quan khác. Và, không phải tất cả các hệ thống con đều được
tạo ra theo đơn hàng riêng. Một số thể hiện các tài sản hoặc sản phẩm hiện
hành (chẳng hạn hệ thống luật nghiệp vụ), và việc sử dụng các hệ thống con
như vậy là một cơ
hội đẩy mạnh tái sử dụng.

Hình 4. Sơ đồ Cộng tác-thành phần đối với ca sử dụng “Rút tiền từ ATM”

Việc này hoàn tất các bước được khuyên tiến hành để viết tư liệu các tạo tác thiết
kế ở mức đặc tả.

Về đầu trang
Thiết kế ở mức vật lý
Thiết kế ở mức vật lý về bản chất xoay quanh việc phân phối ứng dụng và các hệ
thống con trên các nút sơ bộ, như vậy chúng có thể được cài đặt và chạy trên các
nút phần cứng vật lí, mà cùng thể hiện topo hạ tầng của hệ thống. Thiết kế ở mức
vật lý cũng được sử dụng để tác động đến hạ tầng kỹ thuật và các thành phầ
n phần
đệm và các hệ thống con khác.

Các hệ thống con cần được triển khai trên một tập các các nút phần cứng. Cấu
hình phần cứng của hệ thống có các đặc tính và đặc tả khác nhau đối với mỗi nút.
• Một số có thể được điều chỉnh đối với tương tác khách hàng thông qua giao
diện người sử dụng tân tiến.
• Số khác có thể được điều chỉnh đối với các hệ thống giao dịch khối lượng
cao.
• Một số đòi hỏi an ninh ở mức phần cứng.
Các NFR cần đến tính sẵn sàng, hiệu năng, độ tin cậy, và các phẩm chất khác có
ảnh hưởng lớn đến việc lựa chọn phần cứng và phần đệm mà phải hỗ trợ các ứng
dụng thường trú trên đỉnh của chúng. Các hệ thống con mới cũng có thể phải được
định tên dựa trên lựa chọn công nghệ. Ví dụ,
để hỗ trợ các đối tượng phân tán, bạn
có thể sử dụng DCOM, nếu nó dựa trên công nghệ .NET, hoặc Gọi Phương thức
Từ xa (RMI) trên IIOP nếu nó dựa trên Java™ 2 Bản Doanh nghiệp (J2EE). Các
nguyên lý đặc thù công nghệ như vậy cũng có thể được định danh như chính các
hệ thống con của chúng. Khi các hệ thống con mới được định danh theo cách này,
một giao diện chưa rõ ràng về công nghệ (technology agnostic interface) được
định nghĩa, thông qua cái mà các hệ thống con khác trong ph
ạm vi ứng dụng nhận
để tương tác. Việc này cung cấp một mặt tiền (facade) trên các cài đặt đặc thù
công nghệ (technology-specific implementations) và đưa ra khả năng tái sử dụng
được tăng cường trong thiết kế của hệ thống. Bạn nên cố gắng để thu được khả
năng tái sử dụng tại mỗi lớp của kiến trúc (xem Phần 3 của loạt bài này).
Một khi bạn đã phân tích và hiểu được các đặc tính của nút, và đã xác định được
các hệ thống con mới (nếu yêu cầu), hoạt động chính là kết hợp các hệ thống con
(dựa trên các đặc tính chức năng và kỹ thuật và các yêu cầu NFR) với nút phần
cứng mà là ứng cử viên tốt nhất để định danh các tính năng của hệ thống con. Sau
phân tích này, mỗi hệ thống con có thể được đặt lên một nút trong cấu trúc liên kết
hoạt động của hệ thống. Một nút có thể thường là một thùng chứa của nhiều hệ
thống con, mặc dù có thể có các nút được chuyên môn hoá mà được tinh chỉnh đối

với chỉ một kiểu hệ thống con đặc biệt.
Một sự xử lý chi tiết của các nút, việc mô tả, cấu hình, sự phụ thuộc vào các nút
khác của chúng, và các giao thức sử dụng đối với khả n
ăng kết nối giữa các nút
nằm trong phạm trù khác của khung nhìn tác nghiệp. Điều này sẽ được đề cập đến
trong một bài viết sắp tới.
Có một vài chồng chéo của các tạo tác thiết kế vật lý với khung nhìn mô hình hoạt
động của kiến trúc phần mềm.
Có các trường phái khác nhau cố gắng định nghĩa và viết tư liệu kiến trúc phần
mềm theo các cách khác nhau. Có một thuyết cho rằng thiết k
ế mức vật lý là thiên
về vi thiết kế (micro design) của các thành phần. Vi thiết kế là phạm vi trong đó
một thành phần được xem là mức cao nhất của sự trừu tượng. Mỗi thành phần
được phân tích thành một tập các lớp tham gia mà cùng thực hiện các phép toán,
mà thành phần lộ ra thông qua các giao diện của nó. Nhà thiết kế áp dụng các mẫu
thiết kế nổi tiếng và đã được thử thách để giải quyết một mô hình riêng củ
a một
bài toán/vấn đề. Các mẫu có thể kết hợp với nhau để phát triển các mẫu thiết kế
phức hợp mà cùng giải một phạm vi bài toán đã cho trong thành phần. Các sơ đồ
chuỗi chi tiết được sử dụng để chi tiết hoá bản chất động của cách mà mỗi phép
toán (trên giao diện đó) được thực hiện, qua các lớp tham gia trong mô hình lớp.
Thiết kế chi tiết như vậy được thự
c hiện đối với mỗi thành phần trong phạm vi
ứng dụng.
Tôi coi các hoạt động thiết kế chi tiết này là nằm dưới quy tắc thiết kế rộng hơn,
và không nhất thiết phải có tính kiến trúc về bản chất. Loạt bài này không chủ ý
việc cố gắng minh họa tư liệu của các tạo tác ở mức thiết kế.

Về đầu trang
Kết luận

Mô hình chức năng là một trong những lĩnh vực quan trọng nhất của kiến trúc
phần mềm. Một vài kiến trúc sư tập trung vào lĩnh vực này và coi nó là kiến trúc
phần mềm của họ. Khung nhìn mô hình chức năng nhằm đến các kỹ thuật kiến
trúc dùng để:
• Phân tách phạm vi bài toán thành một tập các tạo tác kiến trúc.
• Xây dựng lên dần các tạo tác bằng cách gia tăng việc chuyển hình dựng
kiến trúc từ tóm tắt sang chi tiết.
Bài viết này bàn luận về khung nhìn mô hình chức năng của kiến trúc phần mềm.
Bạn đã tìm hiểu về ba mức độ chi tiết hoá thường sử dụng nhất: thiết kế ở mức
logic, mức đặc tả, và mức vật lý. Bạn đã tìm hiểu những gì phải viết tư
liệu và
cách viết tư liệu các tạo tác ở mỗi mức trừu tượng.
Tôi khuyên bạn nên đọc một vài bài viết đầu tiên trong loạt bài để tìm hiểu về bản
chất của kiến trúc phần mềm, nguyên nhân và cách viết tư liệu, và kích thước của
kiến trúc mà các khung nhìn khác nhằm tới. Hãy đợi các bài viết sắp tới sẽ tập
trung vào các kích thước mà chưa được đề cấp đến.

Mục lục

• Giới thiệu
• Tổng quan mô hình chức năng
• Viết tư liệu mô hình chức năng
• Thiết kế ở mức logic
• Thiết kế mức đặc tả
• Thiết kế ở mức vật lý
• Kết luận