![Đóng [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Việc phác thảo kiến trúc là một cách thực hành tốt nhất linh hoạt để vạch ra các quyết định kỹ thuật nhằm hướng dẫn phát triển và thử nghiệm các hệ thống phần mềm chuyên sâu. Một kiến trúc sư phần mềm thường sử dụng các bước sau đây để phác thảo kiến trúc đích của một hệ thống phần mềm chuyên sâu (xem phần Tài nguyên để truy cập phần 1 của loạt bài này):
- Xác định các yêu cầu quan trọng.
- Định nghĩa kiến trúc ứng cử viên.
- Định nghĩa mô hình triển khai ban đầu.
- Định nghĩa mô hình lĩnh vực.
Nhưng tư duy kiến trúc không phải là một hoạt động nhất thời. Đây là một sự nỗ lực liên tục mà các nhóm phát triển linh hoạt có kinh nghiệm tích hợp vào trong công việc phát triển của họ. Khi nhóm phát triển của bạn từng bước xây dựng hệ thống, bạn phát hiện ra các thách thức kỹ thuật mới và bạn cho phép thực hiện các quyết định kiến trúc mới.
Các hoạt động kiến trúc sau đây thường được thực hiện trong các quá trình lặp phát triển:
- Cải tiến các cơ cấu kiến trúc: Các khái niệm kỹ thuật để đáp ứng các yêu cầu kiến trúc quan trọng được xác định trong bước đầu tiên.
- Cải tiến các phần tử thiết kế: Các phần tử thiết kế quan trọng về kiến trúc.
- Cải tiến kiến trúc triển khai: Các đơn vị và cấu trúc liên kết triển khai.
Cải tiến kiến trúc theo cách lặp
Hãy biết rằng thông thường bạn không cần quy định thiết kế cho tất cả các bộ phận trong hệ thống của bạn. Cũng giống như tất cả mọi thứ khác trong một dự án, bạn chỉ làm điều đó nếu nó mang lại giá trị nào đó. Nhưng một số bộ phận của các hệ thống phần mềm chuyên sâu phải được quy định chi tiết lớn hơn những bộ phận khác. Đó có thể là do một số thành phần khó hiểu và khó thực hiện hơn, hoặc do chúng tác động đến các phần tử quyết định của các hệ thống con khác. Một số tổ chức cần các đặc tả chi tiết hơn trước khi họ chuyển giao việc phát triển cho một đối tác kinh doanh hoặc một nhóm phát triển phân tán theo địa lý. Một số nhóm phải quy định và ghi chép lại kiến trúc của họ cẩn thận hơn để đáp ứng các yêu cầu theo quy định.
Khi nhóm phát triển của bạn cần chỉ ra thiết kế của một thành phần, bạn có thể bắt đầu bằng cách định nghĩa các cơ chế kiến trúc để thực hiện nó.
Mục tiêu của giai đoạn này là định nghĩa các lớp phân tích cần thiết để thực hiện các yêu cầu quan trọng của hệ thống của bạn. Nói cách khác, bạn cần xác định tất cả các phần tử cần thiết để đáp ứng một nhu cầu nghiệp vụ cụ thể.
Để biểu diễn trực quan tốt hơn, bạn có thể chọn kết hợp các lớp đó với một bản mẫu phân tích. Sử dụng bản mẫu Boundary để biểu diễn một lớp hoạt động như một giao diện với hệ thống. Sử dụng lớp Control để mô tả một thành phần thực hiện quyền điều khiển các lớp khác. Sử dụng bản mẫu Entity để chọn một lớp mang dữ liệu.
Một biểu diễn đồ họa của các bản mẫu phân tích này được thể hiện trong Hình 1.
Hình 1. Các bản mẫu phân tích
Hình 2 cho thấy bản mẫu phân tích khi nó được áp dụng cho một yêu cầu quan trọng của
hệ thống. Trong ví dụ về công ty Yummy Inc., nhu cầu nghiệp vụ đặt hàng liên quan
đến một số phần tử (các lớp phân tích) ví dụ như một khách hàng, một thực đơn và xử
lý một thanh toán.
Hình 2. Các phần tử phân tích cho gói đặt hàng
Sau khi bạn xác định các lớp phân tích (hình 2), bạn cũng có thể cần định nghĩa các khía cạnh tĩnh và động của một số yêu cầu quan trọng.
Sau đó, với mỗi kịch bản quan trọng, mục đích của bước này là để định nghĩa cả các khía cạnh tĩnh lẫn các khía cạnh động. Rational Software Architect hỗ trợ kiến trúc sư hoàn thành nhiệm vụ này bằng cách cung cấp một khuôn mẫu thực hiện tình huống sử dụng.
Theo mặc định khuôn mẫu (Hình 3) đi kèm với một sơ đồ lớp để ghi lại khía cạnh tĩnh (những người tham gia) và một bộ các sơ đồ tuần tự (Luồng cơ bản - Basic Flow, Luồng thay thế n ... - Alternative Flow n …) cho các hành vi động.
Hình 3. Khuôn mẫu thực hiện tình huống sử dụng cho chức năng Order Menus (Các trình đơn đặt hàng)
Mỗi sơ đồ giải quyết một khía cạnh khác nhau của thành phần. Sơ đồ lớp (Hình 4) mô tả tất cả các lớp có trong việc thực hiện tình huống sử dụng (động) trong khi sơ đồ trình tự (Hình 5) minh họa các tương tác giữa chúng (động).
Hình 4. Sơ đồ lớp cho các chức năng Order Menus
Hình 5. Sơ đồ trình tự cho chức năng Order Menus
Tới cuối của bước này, bạn đã phát triển một số việc thực hiện yêu cầu quan trọng của hệ thống với các mô hình UML. Đây là một phần quan trọng của kiến trúc khi bạn cần mô tả cấu trúc tĩnh và hành vi của một số thành phần của hệ thống phần mềm chuyên sâu của bạn.
Vì Mô hình phân tích (Analysis Model) vẫn còn chưa chắc chắn về công nghệ, bạn có thể sử dụng nó như điểm khởi đầu cho một số công cụ.
Sau khi bạn định nghĩa cách bạn muốn thực hiện các yêu cầu quan trọng trong mô hình phân tích, bạn đã sẵn sàng để đi sâu vào thiết kế cụ thể các thành phần.
Trong khi Mô hình phân tích là trừu tượng, thì Mô hình thiết kế (Design Model) phải gần hơn với việc thực hiện. Kiến trúc sư phần mềm thường xác định một tập các mục tiêu và các ràng buộc liên quan đến công nghệ được sử dụng để thực hiện giải pháp này. Mô hình thiết kế thường không được phát triển từ đầu. Nó là một sự tiến hóa của mô hình phân tích mà bạn đã định nghĩa (Hình 2 và Hình 3).
Trong ví dụ của chúng ta, việc Cung cấp dịch vụ ăn uống trực tuyến của công ty Yummy Inc. được phát triển bằng nền tảng EE của Java. Tính bền vững của dữ liệu sử dụng API Persistence của Java (xem phần Tài nguyên ), logic ứng dụng được thực hiện với Session Beans và việc truy cập vào dịch vụ giao hàng được thực hiện thông qua các dịch vụ web.
Trong kiến trúc và thiết kế, một hướng dẫn thực hành tốt nhất được chấp nhận rộng rãi là định nghĩa các tầng khác nhau của giải pháp và cách chúng liên quan với nhau. Kiến trúc n-tầng EE của Java khuyến khích sự phân tách mối quan tâm giữa các tầng.
Trong phối cảnh Các tầng kiến trúc (Architectural Layers perspective) của Rational Software Architect, khuôn mẫu thiết kế đưa ra một khung nhìn để bạn có thể định nghĩa các phụ thuộc giữa các tầng trong đó (Hình 6).
Hình 6. Khung nhìn Architectural Layer Dependencies (Các phụ thuộc của các tầng kiến trúc) cho hệ thống Cung cấp dịch vụ ăn uống trực tuyến
Với các tầng kiến trúc đã định nghĩa, kiến trúc sư phần mềm đưa ra quá trình lặp
thiết kế đầu tiên. Khuôn mẫu thiết kế của Rational Software Architect cung cấp một
cấu trúc đã định sẵn cho hoạt động này. Đặc tả thành phần thường chứa các giao diện
và dữ liệu được sử dụng để tương tác với thành phần đó (Hình 7). Nó thường là khía
cạnh đầu tiên mà một kiến trúc sư phần mềm định nghĩa. Đối với mỗi thành phần, điều
quan trọng là chỉ rõ dữ liệu mà nó thao tác và giao diện của nó, bao gồm cả các hoạt
động có sẵn.
Hình 7. Các gói thiết kế cho hệ thống Cung cấp dịch vụ ăn uống trực tuyến
Lưu ý rằng do đã chọn nền tảng thực hiện ở giai đoạn này, nên có thể cải thiện mô hình thiết kế với thông tin công nghệ cụ thể. Trong ví dụ của chúng ta, các đối tượng bền vững được đánh dấu bằng một bản mẫu JPA để xác định cách mô hình đối tượng ánh xạ tới cơ sở dữ liệu.
Đối với một số thành phần trong hệ thống phần mềm chuyên sâu của bạn, bạn có thể quyết định chỉ rõ thiết kế thêm một bước nữa. Hãy nhớ rằng bạn thêm thông tin chi tiết cho thiết kế chỉ khi nó giúp nhóm phát triển của bạn thực hiện và cung cấp ứng dụng. Trong Hình 8, một sơ đồ lớp chi tiết đã được tạo ra với một mục tiêu cụ thể trong tâm trí. Nhóm phát triển muốn tạo ra mã Java từ mô hình thiết kế bằng cách sử dụng một số phép chuyển đổi mà Rational Software Architect cung cấp (xem phần Tài nguyên để biết thêm thông tin về các phép chuyển đổi này).
Hình 8. Sơ đồ lớp chi tiết để tạo mã
Việc tạo thiết kế chi tiết cho một số thành phần không phải lúc nào cũng là trách nhiệm của một kiến trúc sư phần mềm. Tùy thuộc vào quy mô và các kỹ năng của nhóm dự án của bạn, vai trò của nhà thiết kế phần mềm có thể được giao cho một hay nhiều người khác nhau, ví dụ như các nhà phát triển cấp cao (ranh giới giữa kiến trúc, thiết kế và phát triển đôi khi không rõ ràng).
Các kiến trúc sư chịu trách nhiệm về tạo các hệ thống để đáp ứng nhu cầu nghiệp vụ. Một khía cạnh quan trọng của hệ thống phần mềm chuyên sâu là cách chúng được triển khai trên kiến trúc vật lý. Mô hình triển khai ban đầu thường được xác định khi bạn phác thảo kiến trúc (xem phần Tài nguyên để truy cập phần 1 của loạt bài này). Khi dự án tiến triển, các kiến trúc sư cải tiến kiến trúc triển khai để kết hợp các yêu cầu phi chức năng và các ràng buộc liên quan đến môi trường sản xuất.
Với các công cụ lập kế hoạch triển khai của Rational Software Architect, bạn có thể tạo ra các cấu trúc liên kết để hiển thị các mối quan hệ giữa các tài nguyên công nghệ thông tin. Bạn cũng có thể lập kế hoạch và xác nhận hợp lệ các kịch bản triển khai (xem phần Tài nguyên để biết thêm thông tin về lập kế hoạch triển khai và tự động hóa với Kiến trúc sư phần mềm Rational).
Rational Software Architect giúp hoàn thành phân tích triển khai ở các mức trừu tượng khác nhau. Bạn có thể tạo ra các cấu trúc liên kết logic ở đó bạn nắm giữ các quyết định về kiến trúc hoạt động của một hệ thống phần mềm chuyên sâu (Hình 9). Trong một cấu trúc liên kết logic, bạn mô tả hệ thống ở mức trừu tượng cao. Bạn chỉ rõ cách tổ chức và kết nối các thành phần của ứng dụng và sẽ đặt và lưu trữ chúng ở đâu. Lưu ý rằng các đơn vị biểu diễn giải pháp không phải lúc nào cũng được tạo ra từ đầu nhưng có nguồn gốc từ các phần tử UML để truy tìm nguồn gốc tốt hơn.
Hình 9. Một ví dụ về cấu trúc liên kết logic cho hệ thống Cung cấp dịch vụ ăn uống trực tuyến
Các kiến trúc sư cũng có thể định nghĩa một cấu trúc liên kết để mô tả cách triển khai ứng dụng. Kiểu mô hình này mô tả một cá thể triển khai đầy đủ, cụ thể của một ứng dụng và cơ sở hạ tầng cụ thể mà trên đó nó được triển khai (Hình 10).
Hình 10. Mẫu của mô hình triển khai chi tiết cho hệ thống Cung cấp dịch vụ ăn uống trực tuyến
Các nhóm phát triển đang làm việc để cung cấp một hệ thống phần mềm chuyên sâu luôn phải ghi nhớ rằng phần mềm làm việc là thước đo chính của sự tiến bộ. Các hoạt động cần thiết để phát triển một ứng dụng nằm ngoài phạm vi của bài này, nhưng điều quan trọng cần nhớ rằng các nhóm phát triển thành công tích hợp kiến trúc và thiết kế vào trong công việc phát triển của họ.
Tư duy kiến trúc đang thực hiện là một phần của nỗ lực phát triển và các nhóm không nên viết mã mới hoặc sửa đổi mã hiện có mà không suy nghĩ xem sự thay đổi đó sẽ ảnh hưởng đến toàn bộ ứng dụng ra sao. Một kỹ thuật phổ biến để thay đổi mã hiện có được gọi là tái cấu trúc (xem phần Tài nguyên để biết thêm thông tin về tái cấu trúc). Rational Software Architect cung cấp một tập các công cụ phong phú để làm cho việc phát triển và tái cấu trúc mã dễ dàng. Bạn có thể thay đổi cấu trúc mã của bạn bằng cách sử dụng trợ giúp tái cấu trúc (Hình 11). Bạn cũng có thể xác định các mẫu và các phản-mẫu trong mã ứng dụng của bạn bằng cách sử dụng khả năng khám phá kiến trúc (Hình 12). Cả hai tính năng sẽ giúp bạn viết mã tốt hơn và phát hiện ra các vấn đề ở giai đoạn đầu phát triển phần mềm.
Hình 11. Sự hỗ trợ tái cấu trúc trong Rational Software Architect
Hình 12. Xác định các mô hình
Nếu bạn đã tạo ra một số mô hình trong các hoạt động tư duy kiến trúc của mình, bạn cũng có thể quyết định chuyển đổi chúng thành mã. Rational Software Architect gắn kèm một bộ các phép chuyển đổi để tạo mã Java, các phần tử EE của Java, hoặc các tạo phẩm của SOA (Hình 13). Bạn cũng có thể tạo ra các mô hình từ mã nguồn hiện có.
Hình 13. Các phép chuyển đổi trong Rational Software Architect
Khi bạn từng bước xây dựng hệ thống, bạn tạo ra phần mềm làm việc phù hợp với các quyết định thiết kế được thực hiện trong các hoạt động tư duy kiến trúc.
Các phương pháp luận linh hoạt thúc đẩy việc chấp nhận các quá trình lặp ngắn để xây dựng một hệ thống theo từng đoạn một. Nếu Big Design Up Front (phương thức thiết kế hoàn hảo trước, viết mã chương trình sau) (xem phần Tài nguyên để biết về BDUF) đã chứng tỏ là một cách tiếp cận không hiệu quả chủ yếu được chấp nhận trong các mô hình thác nước, thì không có nghĩa là các hoạt động kiến trúc và thiết kế phải bị cấm trong các dự án linh hoạt. Thiết kế vừa chủ ý và vừa rõ nét. Chủ ý bởi vì vào lúc bắt đầu một dự án, bạn dự đoán một số các nhu cầu kỹ thuật dựa trên việc tồn đọng sản phẩm (phác thảo kiến trúc). Rõ nét vì trong các quá trình lặp phát triển, bạn thích nghi và làm phong phú thêm thiết kế dựa trên những thách thức kỹ thuật mới mà nhóm của bạn phát hiện ra.
Trong phần 1 của loạt bài, chúng ta tập trung vào các nhiệm vụ điển hình để vạch
ra kiến trúc và điều chỉnh tầm nhìn kỹ thuật theo các nhu cầu phát triển. Trong phần
thứ hai này, chúng ta đã mô tả cách cải tiến kiến trúc trong các quá trình lặp phát
triển. Đối với toàn bộ vòng đời dự án, Rational Software Architect cung cấp các
khuôn mẫu mô hình để chỉ rõ kiến trúc của một hệ thống phần mềm chuyên sâu theo các
quan điểm khác nhau (Hình 14)
Hình 14. Các mô hình với một loạt các khung nhìn kiến trúc
Tư duy kiến trúc là một sự nỗ lực liên tục mà các đội phát triển linh hoạt có kinh nghiệm tích hợp vào trong công việc phát triển của họ. Nó không luôn dẫn đến các sơ đồ chính thức. Hãy nhớ rằng nếu UML không phải là cách tiếp cận phù hợp trong ngữ cảnh của bạn, thì không gì có thể ngăn cản bạn sử dụng các bản phác thảo của Rational Software Architect để thay thế, giống như bạn sẽ làm trên một bảng trắng. Các bản phác thảo của Rational Software Architect không phải là các sơ đồ chính thức như với các sơ đồ UML, nhưng chúng có thể là một sự lựa chọn tốt cho dự án cụ thể của bạn.
| Mô tả | Tên | Kích thước | Phương thức tải |
|---|---|---|---|
| Yummy RSA models | Yummy2011.zip | 84KB | HTTP |
Học tập
-
Định nghĩa các kiến trúc ứng dụng với Rational Software Architect. Phần 1:
Phác thảo kiến trúc
- Mô hình hóa các cấu trúc liên kết triển khai: Một mô đun đào tạo để tìm
hiểu về các cấu trúc liên kết triển khai với Rational Software Architect.
- Tìm hiểu về mô hình hóa với Rational Software
Architect trong việc đào tạo theo khả năng của người học miễn phí này.
- Tìm hiểu về dự án Quản lý thiết kế,
một giải pháp mới để giúp nhóm phát triển hợp tác về các hoạt động kiến trúc và
thiết kế.
- Big Design Up Front
(BDUF): Một trang để tìm hiểu về cách tiếp cận BDUF.
- Java
Persistence API: Một mô hình lập trình đơn giản hơn cho Entity
Persistence.
- Rational
Software Architect wiki: Một wiki sản phẩm ở đó bạn có thể tìm thấy một loạt
các tài nguyên để giúp bạn thiết kế, phát triển, thực hiện và triển khai các ứng
dụng.
- Con đường đào tạo kiến trúc sư phần mềm: Con đường đào tạo để có được các
kỹ năng và nhận được chứng chỉ.
- Các hướng dẫn thực
hành của IBM: Hỗ trợ thông tin về Các hướng dẫn thực hành của
IBM.
- OpenUP: Tìm hiểu về OpenUP, quy trình mã nguồn mở áp dụng các cách tiếp cận
lặp và tăng dần trong một vòng đời có cấu trúc.
- IBM agility@scale: Xem một đoạn video ngắn để tìm hiểu thêm về IBM
agility@scale.
- Hướng dẫn thực
hành theo đề xuất của IEEE để Mô tả kiến trúc cho các hệ thống phần mềm-chuyên
sâu: Tìm hiểu thêm về tiêu chuẩn IEEE 1471.
- Các mẫu về
e-business: Một bộ sưu tập các tài sản có thể tái sử dụng có thể giúp tăng
tốc quá trình phát triển các giải pháp kinh doanh điện tử mới.
- Các cấu trúc liên kết triển khai với: Bài này để cho thấy cách tạo các cấu
trúc mang triển khai với Rational Software Architect.
- Có gì mới trong Phiên bản 8 của Rational Software Architect của IBM: Bài
này là một giới thiệu cơ bản về các tính năng mới trong phiên bản 8 của Rational
Software Architect.
- Trang sản phẩm
phần mềm Rational Software Architect của IBM: Tìm tài liệu kỹ thuật, các bài
hướng dẫn, kinh nghiệm, các tải về và thông tin sản phẩm về Rational Software
Architect.
- Các kế hoạch kiến trúc chi tiết – Mô hình khung nhìn "4 +1" của Kiến trúc phần
mềm: Một bài viết của Philippe Kruchten.
- Trang tài nguyên
UML: Trang web chính thức với thông tin về UML.
Lấy sản phẩm và công nghệ
- Tải về phiên bản một hay cả
hai phiên bản để dùng thử:
- Đánh giá phần mềm của
IBM theo cách phù hợp với bạn nhất: Tải về nó để dùng thử, dùng thử trực
tuyến, sử dụng nó trong một môi trường đám mây, hoặc dành một vài giờ trong SOA
Sandbox để tìm hiểu cách thực hiện kiến trúc hướng dịch vụ có hiệu
quả.
Thảo luận
- Tham gia vào diễn đàn thảo luận. Đặt câu hỏi về Rational Software Architect và sản phẩm
kiến trúc và phát triển khác.
- Đánh giá hoặc xem lại
phần mềm Rational. Thật nhanh chóng và dễ dàng. Thật đấy.
- Chia sẻ kiến thức của bạn và giúp đỡ những người
khác sử dụng phần mềm Rational bằng cách viết một bài báo developerWorks. Bạn sẽ được tiếp xúc với toàn thế giới,
nhận tin RSS, một dòng tên tác giả và tiểu sử và lợi ích của việc chỉnh sửa và sản
xuất chuyên nghiệp trên trang web Rational của developerWorks. Tìm hiểu những gì tạo ra một bài viết tốt trên developerWorks và cách thực
hiện.
- Làm theo phần mềm Rational trên Facebook và Twitter (@ibmrational) và
thêm nhận xét và yêu cầu của bạn.
- Hỏi và trả lời các câu hỏi và nâng cao chuyên môn
của bạn khi bạn dành tâm trí vào các diễn đàn, các quán cà phê và các wiki về
Rational..
- Kết nối với những người khác chia sẻ sở thích của
bạn bằng cách tham gia cộng đồng developerWorks và
đáp ứng với các blog theo hướng nhà phát
triển.
Jean-Louis Maréchaux là một kỹ sư phần mềm cho Rational của IBM ở Canada. Các lĩnh vực quan tâm chính của ông là kiến trúc phần mềm, các công nghệ EE của Java, SOA và các hướng dẫn thực hành phát triển phần mềm Agile. Ông đã công bố nhiều bài báo về các chủ đề này trước đây và đã đóng góp vào Hướng dẫn thực hành cho Scrum phân phối vào năm 2010. Trước khi gia nhập nhóm Rational, Jean-Louis đã là một kiến trúc sư công nghệ thông tin cho nhóm Các dịch vụ toàn cầu của IBM và các tổ chức công nghệ thông tin khác, nơi ông đã tham gia vào việc thiết kế và kiến trúc ứng dụng. Bạn có thể liên lạc với ông tại jl.marechaux@ca.ibm.com.
