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
29 07 2008
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.
Xem thêm bài trong loạt bài này
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ã.
© Copyright IBM Corporation 2008
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
Nhẫn hiệu đăng ký
Trang 1 của 14
developerWorks®
ibm.com/developerWorks/vn/
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.
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ế.
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.
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
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
Trang 2 của 14
ibm.com/developerWorks/vn/
developerWorks®
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….
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
Trang 3 của 14
developerWorks®
ibm.com/developerWorks/vn/
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.
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
Trang 4 của 14
ibm.com/developerWorks/vn/
developerWorks®
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
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
Trang 5 của 14
developerWorks®
ibm.com/developerWorks/vn/
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
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
Trang 6 của 14
ibm.com/developerWorks/vn/
developerWorks®
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
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
Trang 7 của 14
developerWorks®
ibm.com/developerWorks/vn/
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.
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
Trang 8 của 14
ibm.com/developerWorks/vn/
developerWorks®
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ầntươ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.
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
Trang 9 của 14
developerWorks®
ibm.com/developerWorks/vn/
Ở 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ả.
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ể
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
Trang 10 của 14
ibm.com/developerWorks/vn/
developerWorks®
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
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
Trang 11 của 14
developerWorks®
ibm.com/developerWorks/vn/
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ế.
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.
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
Trang 12 của 14
ibm.com/developerWorks/vn/
developerWorks®
Tài nguyên
Học tập
• Xem các phần khác của loạt bài này:
• Phần 1, "Kiến trúc phần mềm là gì, và tại sao việc viết tư liệu nó lại là quan trọng".
• Phần 2, "Phát triển ngữ cảnh hệ thống".
•
•
•
•
•
•
•
• Phần 3, "Phát triển tổng quan kiến trúc"
Nhận một đường cung cấp RSS cho loạt bài này.
Tìm hiểu thêm về SOA trong Thực hiện SOA: Một Hướng dẫn Thực hành về Kiến trúc Hướng
Dịch vụ, một cuốn sách về loạt bài developerWorks được xuất bản gần đây mà Tilak là đồng
tác giả. Sử dụng mã phiếu IBM3748 để nhận chiết khấu 35%.
Đọc nội dung tóm tắt của các định nghĩa kiến trúc phần mềm đã xuất bản.
Quy trình Phát triển Phần mềm Thống nhất của Jacobson, và cộng sự đưa ra một cách xử lý
trội hơn hẳn về cách Quy trình Hợp nhất Rational (RUP) được sử dụng để viết tư liệu các tạo
tác phần mềm.
Một Ngôn ngữ Mẫu Phát triển Dựa trên Thành phần, Arsanjani A., Hội nghị Châu Âu về Các
Ngôn ngữ Mẫu của Lập trình, 2001.
Trong Khu vực kiến trúc trên developerWorks, nhận các tài nguyên bạn cần để nâng cao các
kỹ năng của bạn trong vũ đài kiến trúc.
Duyệt nhà sách công nghệ để có các sách về chủ đề này và các kỹ thuật khác.
Lấy sản phẩm và công nghệ
• Tải về các bản phần mềm đánh giá sản phẩm IBM và bắt tay vào các công cụ phát triển ứng
dụng và các sản phẩm phần sụn từ DB2®, Lotus®, Rational®, Tivoli® và WebSphere®.
Thảo luận
• Xem các blog developerWorks và tham gia vào cộng đồng developerWorks.
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
Trang 13 của 14
developerWorks®
ibm.com/developerWorks/vn/
Đôi nét về tác giả
Tilak Mitra
Tilak Mitra là một Kiến trúc sư cấp cao về Công nghệ Thông tin được công nhận của
IBM. Ông chuyên về các SOA, giúp IBM về chiến lược và định hướng kinh doanh của
nó trong SOA. Ông cũng làm việc như một chuyên gia về chủ đề SOA, giúp các khách
hàng trong việc chuyển đổi kinh doanh dựa trên SOA của họ, với sự tập trung vào các
kiến trúc doanh nghiệp lớn và phức tạp. Trọng tâm hiện tại của ông là xây dựng các tài
sản tái sử dụng được xung quanh Các dịch vụ Kinh doanh Đa hợp (CBS), có khả năng
chạy trên nhiều nền tảng như các vùng nhớ SOA cho IBM, SAP v.v… Ông sống ở vùng
Nam Florida có nhiều nắng, và trong lúc không làm việc thì dành hết thời gian vào các
trò crickê và bóng bàn. Tilak có các bằng cử nhân về Vật lý của Đại học Presidency,
Calcutta, Ấn Độ, và các bằng Cử nhân và Thạc sĩ Tích hợp về EE của Viện Khoa học
Ấn Độ, Bangalore, Ấn Độ. Phát hiện nhiều hơn về SOA tại blog của Tilak về SOA và
kiến trúc. Xem tiểu sử sơ lược của Tilak Mitra trên LinkedIn hoặc gửi thư điện tử cho
ông về các đề nghị của bạn tại [email protected]
© Copyright IBM Corporation 2008
(www.ibm.com/legal/copytrade.shtml)
Nhẫn hiệu đăng ký
(www.ibm.com/developerworks/vn/ibm/trademarks/)
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
Trang 14 của 14