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

Chia sẻ: Nguyen Nhi | Ngày: | Loại File: PDF | Số trang:24

Thêm vào BST

Báo xấu

163
lượt xem 27
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Viết tư liệu kiến trúc phần mềm, Phần 4

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ụ SUBSYS-01 Mã nhận dạng hệ thống con My Subsystem Tên hệ thống con
F1,F2 Chức năng I11, I12, I21 Giao diện 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ụ SUBSYS-01 Mã nhận dạng hệ thống con COMP-01 Mã nhận dạng thành phần My Component Tên thành phần F1, F2, F3 Trách nhiệm của thành phần 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ệ SUBSYS-01 thống con Mã nhận dạng thành COMP-01 phần My Component Tên thành phần F1, F2, F3 NFR 001 - Mô tả và liên kết đến tài liệu NFR NFR 005 Trách nhiệm của BRC 001 - Mô tả và liên kết đến tài liệu danh mục các thành phần 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 COMP-01 (nó thuộc về) Tên và mã nhận dạng giao My Interface, INT-001 diện Cung cấp các ký hiệu riêng cho mỗi phép toán cùng Phép toán giao diện 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ý