Viết tư liệu kiến trúc phần mềm, 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

Kiến trúc phần mềm đã ngày càng trở nên quan trọng đối với việc phát triển các hệ thống thời gian thực phức tạp. Trong loạt bài mới này, hãy tìm hiểu lý do và cách bạn phải làm thế nào để viết tư liệu kiến trúc phần mềm. Bạn sẽ tìm hiểu về năm quan điểm hay khía cạnh khác nhau mà bạn phải viết tư liệu đối với bất kỳ dự án phát triển phần mềm cỡ từ trung bình đến lớn. Bài đầu tiên này trong loạt bài viết giới thiệu kiến trúc phần mềm và tầm quan trọng của việc viết tư liệu. Bạn cũng sẽ nhận được một tổng quan về các quan điểm kiến trúc có trong các bài viết sắp tới.

Tilak Mitra, Kiến trúc sư IT cao cấp, IBM

Author photoTilak 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 tmitra@us.ibm.com


Cấp độ đóng góp cho developerWorks của
        tác giả

30 10 2009

Giới thiệu

Kiến trúc phần mềm là một chuyên ngành bắt đầu từ những năm 70 của thế kỷ trước. Với việc gia tăng độ phức tạp và áp lực về việc phát triển các hệ thống thời gian thực phức tạp, kiến trúc phần mềm nổi lên như là một kiến trúc cơ sở của việc phát triển phần mềm và công nghệ hệ thống chủ lực.

Như bất kỳ lĩnh vực nghiên cứu nào khác, kiến trúc phần mềm cũng có những thách thức ban đầu của nó. Một kiến trúc phần mềm thể hiện các phương diện cấu trúc và hành vi của một hệ thống. Các giải thích bằng văn bản và biểu đồ được sử dụng trong thời gian của cố gắng ban đầu để viết tư liệu các kiến trúc phần mềm thường không đủ và không chính xác. Cái cần tới là một siêu ngôn ngữ hoặc giả ngôn ngữ nhất quán và được hiểu rất rõ ràng để thống nhất tất cả các cách khác nhau của việc trình bày và viết tư liệu kiến trúc phần mềm. Các cộng đồng công nghệ và khoa học máy tính, được các nghiên cứu hàm lâm ủng hộ, đã có những bước tiến lớn trong việc phát triển các thực tiễn và nguyên tắc tốt nhất đối với việc viết tư liệu kiến trúc phần mềm.

Trong loạt bài này, bạn sẽ tìm hiểu về viết tư liệu kiến trúc phần mềm. Hãy khám phá các khía cạnh khác nhau mà bạn có thể viết tư liệu: ngữ cảnh hệ thống, tổng quan kiến trúc, kiến trúc chức năng, kiến trúc hoạt động, và các quyết định về kiến trúc.

Trong bài viết đầu tiên này, hãy tìm hiểu kiến trúc phần mềm là gì và tầm quan trọng của việc viết tư liệu về các khía cạnh khác nhau của ngành nghiên cứu này.


Kiến trúc phần mềm

Nhiều nhà nghiên cứu đã giải thích về kiến trúc phần mềm, và họ có các quan điểm khác nhau về cách trình bày tốt nhất về kiến trúc của hệ thống phần mềm. Không có cách giải thích nào là sai; mỗi kiến trúc có giá trị riêng. Định nghĩa của Bass L, và cộng sự nắm giữ được điểm cốt yếu của cái mà kiến trúc phần mềm đòi hỏi:

“Kiến trúc phần mềm của một chương trình hoặc hệ thống tính toán là cấu trúc hoặc các cấu trúc của hệ thống đó, gồm các thành phần của phần mềm, các thuộc tính có thể trông thấy được từ bên ngoài của các thành phần này, và các mối quan hệ giữa chúng.”

Định nghĩa này tập trung vào kiến trúc đã tạo nên các bản dựng thô (coarse-grained constructs) (tức các thành phần của phần mềm) mà có thể được coi là các bộ phận cơ bản của kiến trúc/các khối xây dựng nên kiến trúc (building blocks of the architecture). Mỗi thành phần của phần mềm, hay bộ phận kiến trúc cơ bản, có một số nhất định các thuộc tính có thể nhìn thấy từ bên ngoài mà nó thông báo đến các bộ phận kiến trúc cơ bản còn lại. Các chi tiết bên trong của sự thiết kế và cài đặt thành phần phần mềm không liên quan đến phần còn lại của hệ thống, xem xét một phần mềm đặc biệt chỉ như một hộp đen. Hộp đen này có các thuộc tính nhất định mà nó biểu lộ, cái mà các thành phần phần mềm còn lại có thể sử dụng để thực hiện chung các đích nghiệp vụ hoặc công nghệ thông tin. Kiến trúc phần mềm xác định các khối kiến trúc cơ bản, với một mức độ chi tiết thích hợp. Nó cũng xác định và viết tư liệu việc các bộ phận cơ bản liên quan lẫn nhau như thế nào.

Kiến trúc khi nó liên quan đến công nghệ phần mềm là việc phân tích hoặc phân vùng một hệ thống đơn lẻ sang một tập các bộ phận mà có thể được xây dựng theo kiểu lặp lại, gia tăng, và độc lập. Các bộ phận riêng lẻ có các mối quan hệ hiện với nhau. Khi đan xen vào nhau, các bộ phận riêng lẻ đó tạo nên kiến trúc của hệ thống, tổ chức, hoặc ứng dụng.

Có một số nhầm lẫn về sự khác nhau giữa kiến trúc với thiết kế. Như Clements P, và cộng sự chỉ ra, tất cả các kiến trúc là thiết kế nhưng không phải tất cả các thiết kế là kiến trúc. Các thiết kế mà cần phải ràng buộc, về mặt hệ thống, để đáp ứng các nhu cầu chức năng và phi chức năng và các mục tiêu của nó, là có tính kiến trúc về bản chất. Trong khi kiến trúc coi một bộ phận kiến trúc cơ bản là một hộp đen, thì thiết kế xử lý cấu hình, tuỳ biến, và các công việc bên trong của một bộ phận kiến trúc cơ bản. Kiến trúc ràng buộc một thành phần phần mềm với các thuộc tính bên ngoài của nó. Thiết kế thường lỏng hơn nhiều so với kiến trúc, vì nó cho phép nhiều cách gắn kết các thuộc tính bên ngoài của thành phần này. Thiết kế cũng cân nhắc các cách khác nhau để thực hiện các chi tiết bên trong của thành phần.

Kiến trúc phần mềm có thể được sử dụng một cách đệ quy. Hãy xem xét một thành phần phần mềm (C1) mà là một bộ phận của một kiến trúc phần mềm của một hệ thống. Kiến trúc sư phần mềm chuyển thành phần này đến nhà thiết kế hệ thống, cùng với các thuộc tính của nó, các khả năng về chức năng và phi chức năng nó phải thể hiện, và mối quan hệ của nó với các bộ phận phần mềm khác. Nhà thiết kế sau khi phân tích thành phần phần mềm C1, quyết định nó sẽ được phân tích thành các thành phần chi tiết hơn (C11, C12, và C13), mỗi cái cung cấp một chức năng có thể dùng lại được mà sẽ được sử dụng để thực thi các thuộc tính đã gán cho C1. Nhà thiết kế chi tiết hoá C11, C12, C13 và các giao diện của chúng.

Tại điểm này, đối với nhà thiết kế, C11, C12, và C13 là các bản dựng kiến trúc (hoặc các thành phần); mỗi cái đều có các giao diện bên ngoài được xác định rõ ràng. Đối với nhà thiết kế, C11, C12, và C13 là kiến trúc của thành phần phần mềm C1, và các bản dựng cần được soạn thảo và thiết kế công phu hơn nữa để nhằm đến các cài đặt bên trong của chúng. Kiến trúc có thể được sử dụng một cách đệ quy bằng cách phân chia hệ thống lớn, phức tạp thành các bộ phận nhỏ, và tập trung vào từng bộ phận.

Kiến trúc ràng buộc hệ thống bằng cách sử dụng các bộ phận kiến trúc cơ bản mà thoả mãn chung các mục tiêu hành vi và chất lượng. Các cổ đông phải có khả năng hiểu được kiến trúc. Như vậy điều cốt yếu là một kiến trúc phải được viết tư liệu thoả đáng, như được thảo luận trong phần kế tiếp.


Tầm quan trọng của việc viết tư liệu một kiến trúc

Cổ đông (Stakeholder): Một người sử dụng kiến trúc dùng để thiết kế và cài đặt xuôi chiều. Một người tài trợ cho việc định nghĩa, duy trì, và tăng cường kiến trúc.

Chìa khoá để giao tiếp với các cổ đông mà kế hoạch chi tiết của hệ thống bạn đang xây dựng là viết tư liệu kiến trúc phần mềm. Các kiến trúc phần mềm được đại diện qua các khung nhìn (views) khác nhau — về chức năng, hoạt động, quyết định, v.v… Không một khung nhìn đơn lẻ nào có thể trình bày được toàn bộ kiến trúc. Không phải tất cả các khung nhìn là cần cho thể hiện kiến trúc của một hệ thống đối với một tổ chức riêng hoặc lĩnh vực bài toán (problem domain). Kiến trúc xác định tập các khung nhìn thể hiện đầy đủ kích thước đòi hỏi của kiến trúc phần mềm.

Bằng cách viết tư liệu các khung nhìn khác nhau và nắm bắt sự phát triển của mỗi bộ phận, bạn có thể truyền đạt thông tin về hệ thống đang tiến triển đến nhóm phát triển, và đến các cổ đông kinh doanh và công nghệ thông tin. Một kiến trúc phần mềm có một tập các đích kinh doanh và công nghệ mà nó mong được đáp ứng. Việc viết tư liệu của kiến trúc truyền đạt cho các cổ đông biết cách mà các đích sẽ đạt được.

Việc viết tư liệu các khía cạnh khác nhau của một kiến trúc phần mềm giúp kiến trúc đó làm cầu nối hố ngăn cách ngôn ngữ giữa việc viết bằng bảng giải pháp đó (bằng cách sử dụng cách tiếp cận bằng hình khối và đường nét) và thể hiện giải pháp đó với một cách mà có ý nghĩa đối với thiết kế xuôi chiều và các nhóm cài đặt. Các lược đồ khối và đường nét của kiến trúc để lại rất nhiều chỗ trống để diễn dịch. Các chi tiết vụn vặt mà cần được đẩy ra là thường được để ẩn, và gây rắc rối ngầm, sau các hình khối và đường nét.

Việc viết tư liệu cũng khuyến khích tạo ra các tạo tác kiến trúc vô hình và có thể được phát triển theo kiểu phương pháp luận, chẳng hạn như sau một khuôn mẫu chuẩn. Kiến trúc phần mềm, với tư cách là một ngành nghiên cứu, đã đến giai đoạn hoàn thiện. Bạn có thể tận dụng các thực hành và nguyên tắc để tạo ra các khuôn mẫu chuẩn cho từng khung nhìn để thể hiện một bộ phận hoặc kích thước nhất định của kiến trúc. Các khuôn mẫu có thể gợi ý kiến trúc sư về cái thực sự cần có được tạo ra. Và chúng sẽ giúp cho kiến trúc đi theo một quan hệ chi phối (regimen) — ngoài kỹ thuật hình khối và đường nét. Các khuôn mẫu xác định kiến trúc theo các thuật ngữ cụ thể hơn nên nó có thể được lần theo trực tiếp đến các đích kinh doanh và công nghệ thông tin mà giải pháp đó mong được đáp ứng.

Vì tính phức tạp của chúng, các sáng kiến phát triển hệ thống có thể mất khoảng 18 tháng. Sự mòn mỏi là phổ biến trên các nhóm thiết kế và phát triển, gây ra một cuộc tranh đấu quyết liệt để tìm ra các thay thế thích đáng. Các thành viên mới của nhóm thường là các tác nhân gây cản trở đối với tiến độ, vì họ phải tìm một đường cong nhận thức trước khi họ có thể trở thành những người đóng góp vào việc sản xuất. Một kiến trúc phần mềm mà có các tạo tác được viết tư liệu tốt sẽ cung cấp:

  • Một nền tảng hoàn thiện để giáo dục các thành viên mới của nhóm về cái mà giải pháp đòi hỏi.
  • Sự giải thích về cách mà giải pháp đó đáp ứng các đích kinh doanh và công nghệ.
  • Các khung nhìn khác nhau về kiến trúc riêng cho phạm vi bài toán.
  • Tập trung vào khung nhìn mà cá nhân sẽ làm việc tiếp.

Xem xét một tạo tác giả định có tên là “các quyết định kiến trúc” (cũng được bàn luận trong một phần tiếp theo). Tạo tác này xác định một bài toán được giải và đánh giá các cơ chế khác nhau để nhằm đến bài toán đó. Nó đưa ra sự điều chỉnh về lý do một phương án riêng được chọn trong số nhiều phương án.

Một bài toán được nhận biết liên quan đến cơ chế truy cập các bảng của DB2® trên máy tính mainframe của IBM. Hai phương án được thẩm định: Sử dụng IBM MQSeries®, hoặc sử dụng một bộ điều hợp NEON Shadow Direct (một bộ điều hợp đại lý). Mặc dù MQSeries có các tính năng và rẻ hơn, phương án sau là một sản phẩm có điểm mạnh về công nghệ và ổn định hơn nhiều vào lúc ra quyết định. Bây giờ hãy hình dung rằng kiến trúc gốc đã để lại dự án sau một năm, và một kiến trúc mới lại đã xuất hiện. Kiến trúc mới thách thức nhóm về nguyên nhân tại sao nó không sử dụng IBM MQSeries để truy cập các bảng DB2 trên máy mainframe. Nhóm này nhanh chóng phục hồi lại tạo tác quyết định kiến trúc, và chỉ ra lý do cho sự lựa chọn đó. Do IBM MQSeries đã được thử nghiệm vào năm vừa qua theo giá danh định với giải pháp khác, và vì nó có một nhãn giá nhỏ hơn, quyết định được xem lại và thay đổi để phản ánh giải pháp được cập nhật.

Ví dụ này minh hoạ lý do tại sao các khía cạnh viết tư liệu khác nhau của một kiến trúc phần mềm hệ thống là bắt buộc để giáo dục các thành viên mới của nhóm và sẽ giúp họ bắt đầu với thời gian ngừng máy nhỏ nhất.


Các khung nhìn khác nhau của kiến trúc

Bạn đã tìm hiểu được rằng một kiến trúc có thể được trình bày qua nhiều khung nhìn, mỗi cái tập trung vào một khía cạnh và kích thước riêng của kiến trúc. Như Bass L, và cộng sự chỉ ra, một khung nhìn là một tập các phần tử kiến trúc hoặc các bản dựng cùng với các mối quan hệ giữa chúng, khi được viết bởi và đọc bởi các cổ đông hệ thống.

Một khung nhìn chức năng của kiến trúc lên danh sách các khối kiến trúc cơ bản khác nhau, mối quan hệ giữa chúng, và cách chúng được phân bổ trong các lớp khác nhau trong kiến trúc. Khung nhìn tác nghiệp (cũng gọi là khung nhìn công nghệ) liệt kê các cơ sở hạ tầng khác nhau và các thành phần phần mềm trung gian (middleware software), cung cấp nền tảng khi chạy cho các thành phần kiến trúc chức năng triển khai trên nó. Đối với một kiến trúc ứng dụng, khung nhìn chức năng đảm đương phần quan trọng nhất. Đối với kiến trúc cơ sở hạ tầng, khung nhìn tác nghiệp là cái để tập trung vào.

Cả hai khung nhìn đều có cách tiếp cận khác nhau để giải quyết cùng một vấn đề, và cả hai đều đòi hỏi phải được chuyển từ một kiến trúc khái niệm thành một sự thực hiện thật sự. Khung nhìn được sử dụng để nhấn mạnh vào kích thước riêng của kiến trúc trong khi cố ý kìm lại các thứ khác.

Từ những năm 90 của thế kỷ trước đã có nhiều tập khung nhìn khác nhau. Perry và Wolf đề xuất rằng có một vài điểm rất thú vị về kiến trúc xây dựng, gồm cả kiến trúc phần mềm, với nhiều khung nhìn. Kruchten, người đưa ra khung nhìn 4 + 1 của các kiến trúc phần mềm, đề nghị có năm khung nhìn, mà khi kết hợp với nhau, thể hiện một kiến trúc phần mềm. Bốn khung nhìn đầu tiên được mô tả dưới đây.

Khung nhìnMô tả
Khung nhìn logicNhằm vào mô hình thiết kế tĩnh
Khung nhìn qui trình Nhằm vào mô hình thiết kế động
Khung nhìn vật lýNhằm vào cách các thành phần phần mềm được ánh xạ lên cơ sở hạ tầng phần cứng
Khung nhìn phát triểnTrình bày sự tổ chức tĩnh của các thành phần phần mềm trong môi trường thời gian phát triển

Khung nhìn thứ năm là kiểu khung nhìn có tính thử nghiệm kiểu giấy quỳ (litmus test) nhiều hơn. Nó lấy một tập hợp các ca sử dụng có ý nghĩa về mặt kiến trúc (các kịch bản kinh doanh) và chỉ ra cách mà tập hợp các phần tử kiến trúc từng khung nhìn trong số 4 khung nhìn, cùng với các ràng buộc kiến trúc quanh các phần tử đó, có thể được sử dụng để nhận ra các ca sử dụng.

Một khung nhìn khác, do Soni, và cộng sự xuất bản trong Kiến trúc Phần mềm Ứng dụng (Applied Software Architecture), gồm bốn khung nhìn chính, chứa một kiến trúc phần mềm:

Khung nhìnMô tả
Khung nhìn kiến trúc khái niệmMô tả hệ thống theo thuật ngữ của các phần tử thiết kế chính của nó và các mối quan hệ giữa chúng
Khung nhìn kiến trúc nối kết môđunMô tả sự phân chia chức năng và cách các môđun phần mềm được sắp xếp như thế nào trong các lớp khác nhau
Khung nhìn kiến trúc thực hiệnMô tả cấu trúc động của các hệ thống
Khung nhìn kiến trúc mãMô tả cách mã nguồn, các nhị phân và thư viện được sắp xếp như thế nào trong một môi trường phát triển

Nhiều khung nhìn khác được mô tả trong các ấn phẩm kiến trúc phần mềm, nhưng nó nằm ngoài phạm vi bài viết này để bao trùm lên toàn bộ chúng. Một phân tích thận trọng về các khung nhìn khác nhau của kiến trúc phần mềm cho thấy có nhiều tương đồng giữa các kết quả nghiên cứu khác nhau. Chúng ta có một bộ khung nhìn tốt nhất mà thường được sử dụng nhiều nhất để thể hiện kiến trúc phần mềm của một hệ thống.

Phần tiếp theo cung cấp một tổng quan về các tạo tác mà được khuyến cáo như một tập cực tiểu của các tư liệu kiến trúc mà bạn có thể tạo ra trong giai đoạn kiến trúc của một vòng đời phát triển phần mềm.


Viết tư liệu những gì

Có nhiều quan điểm, hoặc khía cạnh khác nhau, của một kiến trúc phần mềm mà bạn có thể làm tư liệu. Đối với bất kỳ dự án phát triển phần mềm cỡ vừa đến lớn nào, khuyên bạn nên viết tư liệu ra, ở mức độ nhỏ nhất, tập hợp sau đây của các tạo tác kiến trúc:

Ngữ cảnh hệ thống
Ngữ cảnh hệ thống cho biết cách mà toàn bộ hệ thống, thể hiện như một hộp đen, tương tác với các thực thể bên ngoài (các hệ thống và người sử dụng cuối). Nó cũng xác định các luồng thông tin và điều khiển giữa hệ thống và các thực thể bên ngoài.

Nó được sử dụng để làm rõ, xác nhận, và viết tư liệu môi trường trong đó hệ thống hoạt động. Tính chất của các hệ thống bên ngoài, các giao diện của chúng, và các luồng thông tin và điều khiển trợ giúp đặc tả của các tạo tác kỹ thuật xuôi chiều trong kiến trúc.
Tổng quan kiến trúc
Tổng quan kiến trúc minh hoạ các phần tử khái niệm và các mối quan hệ trong một kiến trúc thông qua các thể hiện lược đồ đơn giản. Bạn có thể tạo ra các sơ đồ tổng quan kiến trúc bao gồm một khung nhìn tổ chức và một khung nhìn hệ thống công nghệ thông tin. Tổng quan giúp trình bày các khả năng kinh doanh và công nghệ thông tin mà tổ chức đó đòi hỏi.

Một kiến trúc tổng quan cũng cung cấp các lược đồ cấp cao hơn mà được chi tiết hoá và viết tư liệu theo các kiến trúc tác nghiệp và kiến trúc chức năng. Và nó miêu tả đường lối chiến lược mà doanh nghiệp đang nắm khi nó liên quan đến các hệ thống công nghệ thông tin.
Kiến trúc chức năng
Còn gọi là kiến trúc thành phần, hoặc mô hình, tạo tác kiến trúc chức năng được sử dụng để viết tư liệu cách kiến trúc được phân tách thành các hệ thống công nghệ thông tin con mà cung cấp một nhóm logic của các thành phần phần mềm.

Nó mô tả cấu trúc của một hệ thống công nghệ thông tin theo các thành phần phần mềm của nó với các nghĩa vụ, giao diện, các mối quan hệ tĩnh của chúng, và cách chúng cộng tác để phân phát chức năng đòi hỏi từ thành phần này. Tạo tác này được phát triển lặp qua các giai đoạn làm việc đa dạng.
Kiến trúc tác nghiệp
Tạo tác kiến trúc tác nghiệp trình bày một mạng lưới các hệ thống máy tính, hỗ trợ một vài yêu cầu về hiệu năng, mở rộng, và sửa lỗi (giữa chúng) của giải pháp. Nó cũng phân chia phần mềm theo phần trung gian, phần mềm hệ thống, và ứng dụng.

Tạo tác này được phát triển lặp qua các giai đoạn làm việc đa dạng.
Các quyết định kiến trúc
Tạo tác các quyết định kiến trúc đảm bảo địa điểm đơn, mà tất cả các quyết định thích đáng về mặt kiến trúc được viết tư liệu. Các quyết định điển hình hướng về, nhưng không giới hạn ở:
  • Cấu trúc của các hệ thống.
  • Sự nhận biết về các thành phần phần giữa để hỗ trợ các yêu cầu về tích hợp.
  • Phân bổ các chức năng cho từng thành phần kiến trúc (khối kiến trúc cơ bản).
  • Phân bổ các khối kiến trúc cơ bản đến các lớp khác nhau trong kiến trúc.
  • Tuân thủ các tiêu chuẩn.
  • Sự lựa chọn về công nghệ để thực hiện một khối kiến trúc cụ thể hoặc thành phần chức năng riêng.
Bất kỳ quyết định nào được xét đến liên quan về mặt cấu trúc đến sự thoả mãn các đích kinh doanh và công nghệ đều được viết tư liệu. Việc viết tư liệu thường bao gồm:
  • Việc nhận biết vấn đề.
  • Đánh giá, gồm thuận và chống, của các giải pháp khác nhau.
  • Giải pháp được chọn, gồm các biện minh đầy đủ và các chi tiết liên quan khác mà sẽ giúp việc thiết kế và thực thi xuôi chiều.

Phần còn lại của loạt bài này sẽ bàn luận về cách viết tư liệu cho năm tạo tác này trong một kiến trúc phần mềm..


Kết luận

Kiến trúc phần mềm ra đời khoảng hơn 30 năm. Vài thập niên trước, người ta đã thấy nó là công việc có ý nghĩa trong công nghệ phần mềm. Kiến trúc sư phần mềm đóng vai trò quan trọng trong việc hình thành một giải pháp nhằm vào các đích kinh doanh, công nghệ, và công nghệ thông tin của một doanh nghiệp. Việc viết tư liệu một kiến trúc phần mềm là vô cùng quan trọng. Bạn có thể sử dụng việc viết tư liệu để giao tiếp với các cổ đông về một hệ thống đang tiến triển. Việc viết tư liệu cũng rất hữu ích để cho phép các thành viên mới của nhóm thành công một cách nhanh chóng, vì họ có thể sử dụng các viễn cảnh kiến trúc như tiên đề bao bọc và ngữ cảnh khi thực hiện một giải pháp.

Có nhiều nhầm lẫn về việc cái có tính kiến trúc và cái không có tính kiến trúc về bản chất, và các khía cạnh nào của một hệ thống sẽ được viết tư liệu. Các khuôn mẫu kiến trúc, mà xác định và chuẩn hóa các nội dung trong mỗi kiểu tạo tác, cho phép cách tiếp cận bền vững cho việc viết tư liệu kiến trúc phần mềm.

Trong bài viết này, bạn đã tìm hiểu được về kiến trúc phần mềm như một ngành nghiên cứu và về tầm quan trọng của việc viết tư liệu các phần tử cốt lõi của kiến trúc. Bạn cũng đã được đọc một tổng quan về các tạo tác kiến trúc mà được khuyến cáo như một tập nhỏ nhất để viết tư liệu. Hãy đợi phần còn lại của loạt bài này, chúng sẽ chi tiết hoá bằng cách sử dụng một tập hợp các nguyên tắc và cách viết tư liệu cho từng tạo tác.

Tài nguyên

Học tập

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Rational
ArticleID=441851
ArticleTitle=Viết tư liệu kiến trúc phần mềm, 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
publish-date=10302009