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

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

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài 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 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. [...]... 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ế... 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... 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... đọ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ả •... 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... 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. .. 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... 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... 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... 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 . 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. 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. 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

Ngày đăng: 08/08/2014, 14:20

Từ khóa liên quan

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan