Định nghĩa các kiến trúc ứng dụng với Rational Software Architect, Phần 2: Cải tiến kiến trúc theo cách lặp

Loạt bài này trình bày các kỹ thuật để tạo các mô hình xác định và truyền tải kiến trúc của các hệ thống phần mềm chuyên sâu. Nó minh họa việc xây dựng kiến trúc phần mềm cho một công ty hư cấu, Yummy Inc. Khi sử dụng một cách tiếp cận lặp, bài này mô tả các hoạt động kiến trúc quan trọng cần thiết để xác định một hệ thống phần mềm chuyên sâu bằng Rational® Software Architect của IBM®. Phần 1 của loạt bài này đã giải thích cách tạo tầm nhìn cho kiến trúc này trong giai đoạn đầu của dự án của bạn. Trong phần 2, chúng ta mô tả kiến trúc được cải tiến theo cách lặp bằng cách sử dụng Rational Software Architect. Cả hai bài đều giả định rằng các độc giả đã quen thuộc với các phương pháp luận dựa trên việc phát triển lặp.

Jean-Louis Maréchaux, Kỹ sư phần mềm, IBM

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.



10 02 2012

Giới thiệu

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):

  1. Xác định các yêu cầu quan trọng.
  2. Định nghĩa kiến trúc ứng cử viên.
  3. Định nghĩa mô hình triển khai ban đầu.
  4. Đị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:

  1. 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.
  2. 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.
  3. 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.

Cải tiến các cơ chế kiến trúc

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
Ba bản mẫu phân tích khác nhau

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
Gói Ordering và các thành phần của nó trong khung nhìn cây

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)
Gói Order Menus

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
Các lớp và các mối quan hệ
Hình 5. Sơ đồ trình tự cho chức năng Order Menus
luồng các hoạt động cho các trình đơn đặt hàng

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.

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

Cải tiến Mô hình thiết kế

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
các tầng của ứng dụ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
các thuộc tính và các hoạt động

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ã
các bản mẫu để cho phép 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ải tiến kiến trúc triển khai

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 vị trí và các nút

Xem ảnh lớn hơn của Hình 9.

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 thành phần và các dịch vụ

Xem ảnh lớn hơn của Hình 10.


Từng bước xây dựng hệ thống

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
Trình đơn tái cấu trúc và các tùy chọn tái cấu trúc
Hình 12. Xác định các mô hình
Các tùy chọn khám phá kiến trúc khác nhau

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
Các tùy chọn chuyển đổi khác nhau

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.


Tóm tắt

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
Các khung nhìn kiến trúc và các mô hình tương ứng

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.


Tải về

Mô tảTênKích thước
Yummy RSA modelsYummy2011.zip84KB

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

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=790917
ArticleTitle=Định nghĩa các kiến trúc ứng dụng với Rational Software Architect, Phần 2: Cải tiến kiến trúc theo cách lặp
publish-date=02102012