Đị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

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 Cung cấp dịch vụ ăn uống trực tuyến 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 (RSA) của IBM®. 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 cho các nhu cầu phát triển. Phần 2 sẽ mô tả cách cải tiến kiến trúc theo cách lặp bằng cách sử dụng RSA. 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 2011

Giới thiệu

Có nhiều phương pháp luận khác nhau đưa ra một tập các hướng dẫn thực hành tùy chỉnh tốt nhất để giúp các doanh nghiệp cung cấp phần mềm chất lượng một cách tin cậy. Việc phát triển phần mềm linh hoạt hiện nay là xu hướng chủ đạo và một trong các nguyên tắc cốt lõi của nó là chấp nhận các phương pháp lặp và gia tăng. Trọng tâm của bài này là về các hoạt động cụ thể theo một quan điểm của kiến trúc sư phần mềm, với giả định rằng bạn đã thành thạo về các hướng dẫn thực hành linh hoạt và phát triển lặp (xem phần Tài nguyên để biết thêm thông tin về IBM agility@scale, IBM Practices, OpenUP và Rational Unified Process).

Mục đích chính của bài này là minh họa cách Rational Software Architect 8 (sau đây gọi tắt là RSA) có thể hỗ trợ tư duy và tài liệu kiến trúc. RSA là một nền tảng thiết kế hợp tác để cung cấp kiến trúc chất lượng cao. RSA giúp bạn định nghĩa các mô hình ở các mức trừu tượng khác nhau và có thể sử dụng nó để hỗ trợ các hướng dẫn thực hành công nghiệp tốt nhất trong công nghệ phần mềm.


Phân tích kiến trúc: Phác thảo và phát triển kiến trúc

Phân tích kiến trúc là một tập các hoạt động xây dựng và cải thiện kiến trúc phần mềm của một hệ thống. Khi được tiến hành theo cách lặp, tư duy kiến trúc này sẽ giúp phát hiện và giải quyết các vấn đề trong quá trình phát triển phần mềm mà không cần trước các cố gắng kiến trúc đáng kể. Các hoạt động phân tích kiến trúc là quyết định cho mọi hệ thống phần mềm chuyên sâu. Dù các huấn luyện viên phát triển linh hoạt giáo điều có thể nói gì đi nữa, không có sự phát triển phần mềm thành công nào mà lại thiếu phân tích kiến trúc.

Phân tích kiến trúc xảy ra ở hai nơi khác nhau. Đầu tiên vào lúc bắt đầu một dự án, thường được gọi là lần lặp 0, hoặc lần chạy nước rút 0. Trong lần lặp ban đầu này, kiến trúc sư phần mềm cần phác thảo kiến trúc dựa trên các yêu cầu quan trọng đã biết và dựa trên các ràng buộc, các quyết định và các mục tiêu kiến trúc. Việc phác thảo kiến trúc không phải là một hoạt động lâu dài và nặng nề. Tùy thuộc vào sự phức tạp của hệ thống của bạn, việc phác thảo kiến trúc có thể mất hàng giờ hoặc thậm chí nhiều ngày với một quá trình lặp có khung thời gian.

Là kiến trúc sư phần mềm, bạn thường làm theo các bước sau để vạch ra kiến trúc đích của hệ thống phần mềm chuyên sâu của bạn:

  1. Xác định các yêu cầu quan trọng: các yêu cầu có chức năng và không có chức năng quan trọng có một tác động đáng kể đến kiến trúc.
  2. Định nghĩa kiến trúc ứng cử viên: kiến trúc cao cấp của hệ thống dựa trên các ràng buộc và các mục tiêu của kiến trúc.
  3. Định nghĩa mô hình triển khai ban đầu: cấu trúc liên kết biểu diễn các nút triển khai của hệ thống.
  4. Định nghĩa mô hình lĩnh vực: các thực thể nghiệp vụ chính và các mối quan hệ của chúng.

Một khi bạn đã có tầm nhìn kỹ thuật ban đầu này, bạn có thể xây dựng hệ thống của mình trên các cơ sở kiến trúc hợp lý. Trong mỗi lần lặp, nhóm phát triển phát hiện ra những thách thức mới về kỹ thuật và các cơ hội mới để cải thiện. Những điều đó đang đóng vai trò của kiến trúc sư phần mềm cho phép thực hiện các quyết định kiến trúc mới. Đó là lý do tại sao việc cải thiện kiến trúc liên tục là chìa khóa để phát triển hệ thống phần mềm chuyên sâu. Kiến trúc không phải là một cái gì đó bạn tạo trước và để lại một mình. Tư duy kiến trúc là một phần của sự phát triển phần mềm từ đầu đến cuối của một dự án.

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ác hoạt động lặp được mô tả trong phần hai của loạt bài này.

Hình 1. Phân tích kiến trúc lặp và gia tăng
Phân tích kiến trúc, các nhiệm vụ và các hoạt động của nó

Mặc dù chúng tôi không trình bày các hoạt động xem xét lại trong bài này, bất kỳ người học có kinh nghiệm nào đều biết rằng kiến trúc phải được xác nhận hợp lệ thường xuyên để kiểm tra xem nó có phù hợp với các yêu cầu và nhu cầu của nhóm phát triển không. Vì vậy, bạn cần một cơ cấu hiệu quả để lưu giữ và truyền tải kiến trúc tới các bên liên quan khác nhau.


Mô tả các kiến trúc bằng cách sử dụng các khung nhìn

Một cách tiếp cận mô tả kiến trúc đã được chứng minh và được chấp nhận rộng rãi là việc sử dụng các khung nhìn và các quan điểm. Một khung nhìn là một sự biểu diễn của toàn bộ hệ thống từ phối cảnh của một tập các mối quan tâm hoặc các lợi ích. Theo quan điểm của một bên liên quan, một khung nhìn tập trung vào tất cả các khía cạnh quyết định hoặc quan trọng của hệ thống. Do một hệ thống thường có nhiều bên liên quan, nên cần có một số khung nhìn để thể hiện tất cả các mối quan tâm của các bên liên quan.

Năm 1995, Philippe Kruchten đã đề xuất một mô hình để mô tả kiến trúc của các hệ thống phần mềm chuyên sâu: mô hình khung nhìn 4 +1 của kiến trúc phần mềm (Để biết thêm thông tin, hãy xem phần Tài nguyên). Người ta đã đưa hầu hết các khái niệm trong các mô hình "4 +1" vào các quá trình phát triển, ví dụ như IBM Rational Unified Process (RUP) hay OpenUP. Gần đây, IEEE 1471 đã tiêu chuẩn hóa định nghĩa về một khung nhìn để tập trung vào các mối quan tâm của các bên liên quan khác nhau của một kiến trúc phần mềm (Xem phần Tài nguyên để biết thêm thông tin về IEEE 1471-2000 / ISO 42010).

Trong mô hình "4 +1" ban đầu, năm khung nhìn được sử dụng để đưa ra một mô tả toàn diện của một hệ thống, như thể hiện trong Hình 2.

Hình 2. Mô hình khung nhìn kiến trúc 4 +1
Tất cả các khung nhìn có liên quan đến các kịch bản trong mô hình 4 + 1

Trong mô hình 4+1, mỗi khung nhìn tập trung vào các mối quan tâm của một tập cụ thể của các bên liên quan, cho phép các bên liên quan khác nhau tìm ra cái mà họ cần trong kiến trúc phần mềm. Có thể thay đổi mô hình này. Tùy thuộc vào độ phức tạp của dự án của mình, bạn có thể chỉ cần một tập con của các khung nhìn được đề xuất. Mô hình này cũng có khả năng mở rộng, vì vậy bạn có thể muốn thêm các khung nhìn khác để mô tả kiến trúc của bạn theo một quan điểm khác nhau. Lưu ý rằng thường có thể bọc các khung nhìn bổ sung lại trong các khung nhìn hiện tại như là các thể loại con.

Trong Bảng 1, mỗi hàng đại diện cho một khung nhìn với người nghe, vùng và mô hình tương ứng của nó.

Bảng 1. Các khung nhìn kiến trúc
Khung nhìnNgười ngheLĩnh vựcMô hình
Lô-gicCác nhà thiết kếNhận thức tình huống sử dụngMô hình phân tích
Mô hình thiết kế
Quá trìnhCác nhà tích hợpHiệu năng
Khả năng mở rộng
Tính đồng thời
Mô hình triển khai
Mô hình thiết kế
Thực hiệnCác nhà lập trìnhCác thành phần phần mềmMô hình thực hiện
Triển khaiCác nhà quản lý triển khaiCác nút vật lýMô hình triển khai
Các kịch bảnMọi ngườiCác yêu cầu chức năngMô hình tình huống sử dụng
Các câu chuyện người dùng
Các quy trình nghiệp vụ
Data
(khung nhìn tùy chọn hoặc một phần của khung nhìn lô-gic)
Các chuyên gia dữ liệu
Các nhà quản trị dữ liệu
Tính bền vững của dữ liệuMô hình dữ liệu

Lưu ý:
Theo truyền thống, khung nhìn quá trình không phải là khung nhìn quan trọng với một ứng dụng vì nền tảng vốn đã xử lý các khía cạnh luồng. Tuy nhiên, bạn có thể chọn ghi lại một số vấn đề đồng thời trong một mô hình triển khai và một số các cơ chế truyền thông (đồng bộ so với không đồng bộ) trong một mô hình thiết kế.


Chuẩn bị vùng làm việc

Trước khi bạn bắt đầu RSA, hãy chắc chắn rằng bạn đã cài đặt các bộ công cụ tối thiểu để hỗ trợ công việc của kiến trúc sư. Khi sử dụng Installation Manager (Trình quản lý cài đặt), hãy kiểm tra xem đã đánh dấu chọn tùy chọn "Architect – Standard" (Kiến trúc sư - Tiêu chuẩn) chưa, như trong Hình 3. Lược tả định sẵn này cho phép các khả năng mô hình hóa UML và cấu trúc liên kết mà bạn cần để thực hiện các nhiệm vụ được trình bày trong bài này.

Hình 3. Lược tả của Kiến trúc sư tiêu chuẩn
Các tùy chọn lược tả cài đặt trong quá trình cài đặt

Bước tiếp theo là tạo ra một vùng làm việc mới. Để làm điều đó, hãy khởi chạy RSA và chỉ rõ một thư mục lưu trữ (Hình 4).

Hình 4. Cửa sổ Workspace Launcher (Trình khởi chạy Vùng làm việc)
Trình khởi chạy để tạo một vùng làm việc mới: Yummy2011

RSA cung cấp nhiều phối cảnh khác nhau để tùy chỉnh thiết lập ban đầu và bố trí các khung nhìn trong cửa sổ Vùng làm việc (Workbench). Hãy kiểm tra xem đã mở phối cảnh Modeling (Mô hình hóa) chưa trước khi tiếp tục (Hình 5).

Hình 5. Cửa sổ Open Perspective (Phối cảnh mở)
Cửa sổ Open Perspective (Phối cảnh mở)

RSA đi kèm với các khuôn mẫu mô hình UML đã định sẵn khác nhau. Trong Modeling Perspective (Phối cảnh mô hình hóa), bạn có thể thêm nhiều mô hình như như bạn muốn để ghi lại kiến trúc của hệ thống của bạn (Hình 6).

Hình 6. Các khuôn mẫu mô hình UML
Danh mục các khuôn mẫu của mô hình thiết kế và phân tích

Mỗi khuôn mẫu được dành riêng cho một mục đích kiến trúc cụ thể. Thông thường, để định nghĩa từng khía cạnh của hệ thống (hãy nhớ lại mô hình khung nhìn "4 +1"), bạn cần các mô hình Tình huống sử dụng (Use-Case), Phân tích và Thiết kế. Trong ví dụ của mình, chúng ta cũng tạo ra một bản phác thảo tầm nhìn kiến trúc và một cấu trúc liên kết để chỉ rõ môi trường đích triển khai. Vì vậy, vùng làm việc của công ty Yummy Inc. có chứa các mô hình sau (Hình 7). Mỗi mô hình dựa trên một khuôn mẫu RSA khác nhau.

Hình 7. Các mô hình mô tả các khung nhìn kiến trúc cho hệ thống Cung cấp dịch vụ ăn uống trực tuyến
Khung nhìn cây của các mô hình Cung cấp dịch vụ ăn uống trực tuyến

Lưu ý rằng chúng ta có thể đã quyết định sử dụng các kiểu mô hình có sẵn trong các mẫu RSA, như mô hình BPMN (quy trình nghiệp vụ) hoặc mô hình Dịch vụ (SOA).

Bây giờ vùng làm việc RSA của bạn đã sẵn sàng, bạn cần thực hiện một số hoạt động mà chúng ta đã đề cập ở trên. Hãy minh họa cách RSA có thể hỗ trợ bạn trong việc phân tích kiến trúc của bạn theo từng bước.


Phác thảo kiến trúc

Là kiến trúc sư phần mềm, bạn cần phác thảo kiến trúc ban đầu và vạch ra các quyết định kiến trúc để hướng dẫn phát triển và thử nghiệm. Nỗ lực này dựa trên kinh nghiệm đã thu thập được trong các hệ thống tương tự hoặc các vùng vấn đề để ràng buộc và tập trung vào kiến trúc. Các kết luận của bạn sẽ cung cấp thông tin để truyền tải kiến trúc cho nhóm phát triển.

Xác định các yêu cầu quan trọng

Một trong những nhiệm vụ đầu tiên mà bạn sắp thực hiện trong lúc phác thảo kiến trúc là xác định các yêu cầu quan trọng cho kiến trúc. Là một kiến trúc sư, vai trò của bạn là đảm bảo kiến trúc đích thích hợp để thực hiện các nhu cầu của người dùng. Vì vậy, bạn cần xem xét các tình huống sử dụng, các quy trình nghiệp vụ, hay những câu chuyện của người dùng để xác định các yêu cầu có thể có tác động đáng kể đến kiến trúc. Các kiến trúc sư có kinh nghiệm làm việc chặt chẽ với các nhà quản lý dự án hoặc các chủ sở hữu sản phẩm để huấn luyện họ về các tác động của kiến trúc của các mặt hàng trong đống đơn hàng tồn đọng. Họ tác động đến cách ưu tiên đống đơn hàng tồn đọng để giải quyết các bất trắc về kỹ thuật càng sớm càng tốt.

RSA, mô hình tình huống sử dụng có chứa các yêu cầu đã xác định với công ty Yummy Inc. (Hình 8).

Hình 8. Các yêu cầu đối với hệ thống Cung cấp dịch vụ ăn uống trực tuyến
Gói yếu cầu Ordering Menus và các thành phần của nó

Không có quy luật chung nào để xác định các yêu cầu quan trọng cả. Nó phụ thuộc vào môi trường của bạn, khung công tác kỹ thuật của bạn và nhóm dự án của bạn. Các yêu cầu có một tác động rất lớn đến kiến trúc cho một nhóm có thể dường như ít quan trọng đối với nhóm khác. Một yêu cầu để hiển thị một danh sách đơn giản của các mặt hàng có thể sẽ không ảnh hưởng quá nhiều đến kiến trúc của bạn. Nhưng nếu yêu cầu đó là để có được các mặt hàng cho một đối tác kinh doanh thông qua một cuộc gọi dịch vụ không đồng bộ, thì bạn phải chắc chắn rằng bạn có hệ thống đường ống trong kiến trúc của bạn để hỗ trợ nhu cầu đó.

Trong ví dụ về công ty Yummy Inc. của chúng ta, mô hình này được chia thành các gói theo hướng chức năng. Mỗi gói gồm có các tình huống sử dụng và các diễn viên (actor) có liên quan (các diễn viên liên kết được tạo nhóm trong gói linh hoạt). Một sơ đồ tình huống sử dụng minh họa yêu cầu đó (Hình 9). Tất nhiên, thông tin tương tự có thể đã được lưu giữ trong một sơ đồ quy trình nghiệp vụ hay một câu chuyện người dùng.

Hình 9. Sơ đồ tình huống sử dụng Order Menus (Các trình đơn đặt hàng)
Các tình huống sử dụng và các diễn viên của trình đơn đặt hàng đã bao gồm

Định nghĩa kiến trúc ứng cử viên

Sau khi đã xác định được các yêu cầu quan trọng, kiến trúc sư phần mềm tạo ra một tổng quan về kiến trúc. Ngày nay, chúng ta hiếm khi phát triển các hệ thống từ đầu. Chúng ta làm phong phú thêm các ứng dụng hiện có, chúng ta hiện đại hóa các hệ thống di sản và chúng ta tái sử dụng và tập hợp lại các tài sản. Kiến trúc sư tận dụng kinh nghiệm quá khứ với các hệ thống tương tự và đảm bảo xem xét các mục tiêu và các ràng buộc. Kiến trúc ứng cử viên sẽ tính đến không chỉ các yêu cầu chức năng (các tình huống sử dụng, những câu chuyện, các quy trình nghiệp vụ) mà còn cả các yêu cầu phi chức năng (tính sẵn sàng, hiệu năng, khả năng mở rộng ...) của hệ thống.

Trong ví dụ của mình, chúng ta đã chọn một kiến trúc N-tầng (Hình 10) ở đó ứng dụng dựa trên web, nhưng cũng được truy cập thông qua các dịch vụ web từ các kiểu máy khách khác nhau (xem phần Tài nguyên để biết thêm thông tin về các ứng dụng có nhiều tầng).

Lưu ý rằng sơ đồ công nghệ này (Hình 10) được tạo ra trong RSA khá đơn giản ở giai đoạn này và có thể được hoàn thành trong một phiên làm việc động não ngắn. Bản phác thảo này cho thấy các thành phần chính đã có và ngăn xếp công nghệ đã xác định để phát triển giải pháp.

Hình 10. Bản phác thảo kiến trúc N-tầng cho hệ thống Cung cấp dịch vụ ăn uống trực tuyến
Bản phác thảo cho ứng dụng Cung cấp dịch vụ ăn uống trực tuyến tại công ty Yummy Inc.

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

Định nghĩa mô hình triển khai ban đầu

Khi sử dụng tổng quan về kiến trúc đã phác thảo trước đây, lúc này một kiến trúc sư phần mềm có thể vẽ bức tranh lớn về mô hình triển khai. Bức tranh này mô tả các thành phần phần mềm và phần cứng chính và cách chúng tương tác ở mức cao. Sơ đồ triển khai tính đến các ràng buộc của môi trường triển khai và là một phương tiện truyền thông lớn cho các nhóm phát triển và các nhóm cơ sở hạ tầng để chia sẻ thông tin giữa các nhóm.

Các đặc tả UML cung cấp một tập của các phần tử để định nghĩa các mô hình triển khai. Tuy nhiên, phần triển khai của UML đã chứng tỏ bị hạn chế về các khả năng. Kết quả là, nó đã không được ngành công nghiệp phần mềm chấp nhận rộng rãi, ngay cả với những người sử dụng UML chuyên sâu. RSA cung cấp một tập các công cụ phong phú để định nghĩa các cấu trúc liên kết triển khai (các cá thể logic, vật lý và triển khai). Các cấu trúc liên kết RSA thật sự mạnh mẽ ở nơi các mô hình triển khai UML không đạt được: Tính dễ hiểu, tái sử dụng và sự truy tìm nguồn gốc (xem phần Tài nguyên để biết thêm thông tin về cấu trúc liên kết triển khai).

Sơ đồ triển khai (Hình 11) cho thấy các thành phần phần cứng khác nhau cần thiết để cung cấp các ứng dụng trên máy chủ. RSA đi kèm với một ngân hàng các hình ảnh để làm cho sơ đồ của bạn có ý nghĩa hơn và cho phép bạn thêm hình ảnh riêng của mình để biểu diễn các phần tử mô hình cụ thể.

Hình 11. Triển khai các nút cho hệ thống Cung cấp dịch vụ ăn uống trực tuyến
Các chế độ triển khai với ứng dụng Cung cấp dịch vụ ăn uống trực tuyến

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

Định nghĩa mô hình lĩnh vực

Đối với các ứng dụng nghiệp vụ, một mô hình lĩnh vực ban đầu sẽ giúp nhóm phát triển hiểu các thực thể nghiệp vụ quan trọng và các mối quan hệ của chúng. Kiến trúc sư phần mềm có thể thu được thông tin từ nhiều nguồn giống như các yêu cầu chức năng, những câu chuyện hoặc các quy trình nghiệp vụ.

Trong RSA, một cách đơn giản để lưu giữ các thực thể nghiệp vụ là sử dụng lược tả phân tích. Lược tả này có chứa ba bản mẫu mà bạn có thể áp dụng cho các phần tử UML (Hình 12).

Hình 12. Các bản mẫu UML
Ba đại diện trực quan của các bản mẫu phân tích

Bản mẫu Boundary (Ranh giới) được dùng để biểu diễn một lớp hoạt động như một giao diện với hệ thống. Lớp Control (Điều khiển) mô tả một thành phần thực hiện quyền điều khiển các lớp khác. Bản mẫu Entity (Thực thể) chọn một lớp mang dữ liệu.

Ở giai đoạn này, bạn chỉ cần quan tâm đến dữ liệu để chỉ sử dụng bản mẫu thực thể. Điều quan trọng là nắm được bảng từ vựng tổng thể của hệ thống để thực hiện. Nó là điểm bắt đầu của Mô hình Phân tích mà bạn sẽ tạo trong bước tiếp theo.

Khuôn mẫu của Mô hình Phân tích do RSA cung cấp được cấu trúc sẵn và đi kèm với một gói đặc biệt có tên là các tổng quan Phối cảnh (Perspective overviews) để thu thập thông tin liên quan đến các khái niệm chủ yếu (Hình 13).

Hình 13. Các tổng quan Phối cảnh cho hệ thống Cung cấp dịch vụ ăn uống trực tuyến
Các tổng quan Phối cảnh cho hệ thống Cung cấp dịch vụ ăn uống trực tuyến

Gói phân tích cho ứng dụng cung cấp dịch vụ ăn uống trực tuyến

Là kiến trúc sư phần mềm, bạn có thể sử dụng một sơ đồ lớp đơn giản (gồm có các thực thể nghiệp vụ chính) để lấy được dự thảo đầu tiên của mô hình lĩnh vực bằng cách sử dụng các bản mẫu phân tích (Hình 14).

Hình 14. Mô hình lĩnh vực về Cung cấp dịch vụ ăn uống trực tuyến
Các phần tử và các mối quan hệ của chúng trong lĩnh vực Cung cấp dịch vụ ăn uống trực tuyến

Các tùy chọn khác có sẵn để định nghĩa mô hình lĩnh vực của bạn trong RSA. Trước tiên, bạn có thể chọn để tạo ra một bản phác thảo đơn giản biểu diễn các thực thể nghiệp vụ (Hình 15).

Hình 15. Bản phác thảo của mô hình lĩnh vực cho hệ thống Cung cấp dịch vụ ăn uống trực tuyến
Một bản phác thảo đơn giản để mô tả mô hình lĩnh vực Cung cấp dịch vụ ăn uống trực tuyến

Trong RSA, các phần tử của các bản phác thảo có thể được chuyển đổi thành các phần tử UML khi bạn cần một chú giải chính thức hơn và bạn tiếp tục truy tìm nguồn gốc giữa bản phác thảo do UML tạo ra và bản phác thảo ban đầu. Một lựa chọn khác là tạo ra một biểu đồ dữ liệu. Trong RSA, bạn có thể tạo các bảng, các cột và các khóa trong một sơ đồ biểu diễn dữ liệu của bạn, hoặc bạn có thể kết nối đến cơ sở dữ liệu của bạn để nhập khẩu một lược đồ hiện có. Việc bạn chọn tùy chọn nào để định nghĩa mô hình lĩnh vực thực ra phụ thuộc vào môi trường của bạn và cách nhóm dự án làm việc. Không có giải pháp hoàn hảo nào nhưng chắc chắn có một giải pháp tốt nhất cho bạn.


Tóm tắt

Ở giai đoạn này, bạn đã định nghĩa tầm nhìn cho kiến trúc của hệ thống phần mềm chuyên sâu của bạn. Bạn biết khung nhìn nào có ích cho các bên liên quan của bạn, bạn đã xác định được các yêu cầu có tác động đáng kể đến giải pháp kỹ thuật của mình và bạn đã vạch ra kiến trúc đích sao cho phù hợp. Trong một khung thời gian ngắn (lần lặp 0), bạn đã nắm giữ thông tin quan trọng liên quan đến các mô hình công nghệ, triển khai và lĩnh vực trong RSA.

Trong phần 2 của loạt bài này, bạn sẽ xem xét cách sử dụng RSA để cải tiến kiến trúc của hệ thống phần mềm chuyên sâu 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ệ

  • Tải về phiên bản dùng thử IBM Rational Software Architect từ developerWorks.
  • Đá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

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=792750
ArticleTitle=Đị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
publish-date=02102011