Mô hình Kiến trúc Hướng Dịch vụ với Kiến trúc sư Phần mềm Rational: Phần 4. Các mô hình tình huống sử dụng

Hướng dẫn thứ tư trong loại bài này trình bày mô hình tình huống sử dụng. Nó vẫn tiếp tục sử dụng nghiên cứu tình huống cụ thể của một công ty cho thuê DVD trực tuyến tưởng tượng đã giới thiệu trong ba phần trước và bạn sẽ sử dụng bản Kiến trúc sư Phần mềm Rational® của IBM® để tạo ra mô hình tình huống sử dụng dựa vào việc nghiên cứu tình huống cụ thể đó.

Bertrand Portier, Kiến trúc IT, IBM Software Group Services

Bertrand Portier làm việc cho các công nghệ nâng cao SOA SWAG của IBM (trước đây là EIS). Ông đã tham gia rất nhiều vào việc phát triển kiến trúc hướng dịch vụ, phát triển dựa vào-mô hình và phát triển dựa trên tài sản. Là diễn giả thường xuyên tại các hội nghị và là tác giả của một số bài viết về kỹ thuật, ông cũng là đồng tác giả của cuốn sách đỏ của IBM về các giải pháp SOA


Tác giả chuyên nghiệp của
        developerWorks

Gregory Hodgkinson, Đầu ngành SOA, Prolifics

Gregory HodgkinsonGregory Hodgkinson là người sáng lập, giám đốc và người lãnh đạo SOA tại 7irene, một đối tác kinh doanh bậc 1 của IBM tại Vương quốc Anh (www.7irene.com). Ông đã có 10 năm kinh nghiệm trong kiến trúc phần mềm, đầu tiên nổi tiếng về lĩnh vực phát triển dựa trên-thành phần (CBD), sau đó dễ dàng chuyển sang kiến trúc hướng-dịch vụ (SOA). Lĩnh vực chuyên môn mở rộng của ông là quá trình phát triển phần mềm và ông trợ giúp các khách hàng của 7irene và IBM trong việc theo đuổi các quá trình phát triển nhanh chóng dựa trên khung công tác RUP và phương pháp SOA. Ông vẫn chính là một nhà thực hànhvà chịu trách nhiệm về các kiến trúc dịch vụ cho một số các công ty 100 FTSE. Ông đã trình bày về quá trình và các phương pháp SOA nhanh ở cả hai sự kiện Rational và WebSphere của IBM và các sự kiện khác. Ông cũng là đồng tác giả của cuốn sách đỏ về các giải pháp SOA



21 05 2009

Trước khi bạn bắt đầu

Hãy tìm hiểu xem hướng dẫn này mang lại những gì và làm thế nào để sử dụng nó tốt nhất.

Về loạt bài này

Loạt bài này cung cấp một cái nhìn chi tiết về mô hình hóa các kiến trúc hướng dịch vụ (SOA) bằng cách sử dụng Kiến trúc sư phần mềm Rational® của IBM®. Mặc dù mục tiêu chủ yếu là nhằm vào các kiến trúc sư phần mềm và các hoạt động mà họ thực hiện, nhưng hướng dẫn này cũng rất có ích cho những người đảm nhiệm các vai trò khác trong quá trình phát triển phần mềm, bao gồm cả những người cung cấp đầu vào cho kiến trúc phần mềm, ví dụ như các nhà phân tích nghiệp vụ và cả những người sử dụng kiến trúc phần mềm làm đầu vào để thực hiện các hoạt động của mình, ví dụ như là các nhà thiết kế và phát triển phần mềm (hiểu rõ nó, thiết kế, và thực thi). Loạt bài này cũng trình bày nhiều khái niệm SOA cốt lõi mà nhiều người khác quan tâm.

Bạn sẽ tìm hiểu cách làm thế nào để thực hiện ba điều này, trong các lĩnh vực sau:

  • Kiến trúc. Mô tả SOA bao gồm những gì và nó thể hiện ở đâu trong toàn bộ quá trình phát triển phần mềm.
  • Các dịch vụ. Thiết kế kiến trúc dịch vụ cho một giải pháp có sử dụng SOA.
  • Các mô hình. Giới thiệu cách công cụ Kiến trúc sư Phần mềm Rational hỗ trợ một phương pháp tiếp cận phát triển dựa vào-mô hình (MDD) đối với đặc tả kỹ thuật kiến trúc hướng dịch vụ như thế nào.

Sau khi mô tả kiến trúc phần mềm và xác định vị trí của các dịch vụ trong kiến trúc phần mềm, loạt bài này giới thiệu Kiến trúc sư Phần mềm Rational và các đặc tính có liên quan đến SOA- và kiến trúc-của nó.

Các hướng dẫn này sử dụng nghiên cứu tình huống cụ thể của một công ty cho thuê DVD trực tuyến tưởng tượng với ba mục đích chính:

  • Mô tả các vật phẩm làm việc được sử dụng như là đầu vào cho các hoạt động kiến trúc dịch vụ, bao gồm mô hình thành phần nghiệp vụ, mô hình quy trình nghiệp vụ, mô hình tình huống sử dụng hệ thống, phần hệ thống bên ngoài của mô hình thiết kế.
  • Mô tả từng bước cách thức một mô hình dịch vụ thể hiện kiến trúc hệ thống sẽ được xác định rõ trong Kiến trúc sư phần mềm Rational như thế nào, bao gồm những người sử dụng dịch vụ, các đặc tả kỹ thuật của dịch vụ, các phân vùng của dịch vụ, các nhà cung cấp dịch vụ không phân chia và phức hợp, các dịch vụ, các hợp tác dịch vụ, các tương tác dịch vụ và các kênh dịch vụ.
  • Giải thích cách thức mô hình dịch vụ được sử dụng sau đó trong các hoạt động tiếp theo của quá trình phát triển phần mềm như thế nào, với sự quan tâm đặc biệt đến việc thiết kế và thực thi.

Về hướng dẫn này

Trong Phần 1, chúng ta đã giới thiệu một nghiên cứu tình huống cụ thể của một công ty cho thuê video được dùng làm ví dụ trong suốt loạt bài hướng dẫn này. Sau đó chúng ta đã đặt kiến trúc dịch vụ trong khung công tác của Rational Unified Process và đã giới thiệu chồng giải pháp SOA (SOA Solution Stack) của IBM để tham khảo. Chúng ta đã lưu ý các vật phẩm làm việc khác nhau được dùng làm đầu vào cho một kiến trúc dịch vụ và sau đó sử dụng nghiên cứu tình huống cụ thể để đưa ra các ví dụ về hai mô hình: mô hình kiến trúc nghiệp vụ (đã mô tả trong Phần 1 dưới dạng một mô hình thành phần nghiệp vụ) và mô hình quy trình nghiệp vụ.

Trong Phần 2, chúng ta đã xem xét chi tiết mô hình miền là gì và làm thế nào để biểu diễn nó trong Kiến trúc sư Phần mềm Rational. Bạn đã bắt đầu có được kinh nghiệm thực hành với công cụ và tạo ra mô hình miền được sử dụng trong loạt bài này.

Trong Phần 3, chúng ta đã giải thích làm thế nào để tạo mô hình các hệ thống bên ngoài nằm trong bối cảnh của kiến trúc hướng dịch vụ. Chúng ta đã bàn về việc phân tích từ dưới lên và việc mô hình hóa các giao diện và các thành phần.

Trong phần này, chúng ta trình bày mô hình tình huống sử dụng. Chúng ta bắt đầu bằng cách xác định vị trí và mô tả mô hình tình huống sử dụng bằng các đầu vào của nó và mô tả cách nó đóng góp vào mô hình hóa SOA của bạn như thế nào. Sau đó, chúng ta mô tả cách làm thế nào để tạo mô hình trong Kiến trúc sư phần mềm Rational và cách trình bày chi tiết nó như thế nào khi sử dụng các phần tử của mô hình tình huống sử dụng.

Mục tiêu

Sau khi hoàn thành phần này của loạt bài hướng dẫn, bạn sẽ có khả năng:

  • Mô tả giá trị của một mô hình tình huống sử dụng.
  • Tạo một mô hình tình huống sử dụng để chỉ rõ các tác nhân, các tình huống sử dụng và các luồng trong tình huống sử dụng.

Các điều kiện cần có trước

Để thu được kết quả tốt nhất từ hướng dẫn này, bạn nên (nhưng không nhất thiết) làm quen trước với:

  • Kiến trúc hướng-dịch vụ (SOA-Service-oriented architecture).
  • Kiến trúc sư Phần mềm Rational của IBM.
  • Ngôn ngữ mô hình hóa thống nhất (UML-Unified Modeling Language).
  • Quy trình thống nhất Rational của IBM (IBM Rational Unified Process®-RUP®)

Chú ý quan trọng:
Chúng tôi rất khuyến cáo bạn nên đọc ba phần đầu tiên của loạt bài hướng dẫn này trước khi đọc phần này (nhấn vào đường liên kết "Nhiều hơn nữa về các loại bài này", ở góc trên bên trái).

Các yêu cầu hệ thống

Bản Kiến trúc sư Phần mềm Rational V7 (với bản sửa 005 hoặc mới hơn).


Tạo mô hình tình huống sử dụng

Có một mô hình cuối cùng mà chúng ta sẽ xem lại trước khi bắt đầu thực hiện mô hình Dịch vụ, đó là mô hình Tình huống sử dụng. Nó sẽ là một đầu vào quan trọng sau này, khi tạo mô hình các tương tác và các hợp tác dịch vụ trong mô hình dịch vụ.

Giới thiệu về mô hình Tình huống sử dụng

Các mô hình như là Mô hình Thành phần Nghiệp vụ™ của IBM®, mô hình quy trình nghiệp vụ và mô hình miền là các mô hình mức nghiệp vụ. Tuy nhiên, mô hình Tình huống sử dụng của hệ thống (thường được gọi tắt là mô hình Tình huống sử dụng) là mô hình ở mức CNTT chứ không phải ở mức nghiệp vụ. Mặc dù nghiệp vụ vẫn còn là trọng tâm xem xét của chúng ta, bây giờ chúng ta sẽ mô hình hóa nhiều hơn những thứ chỉ có trong nghiệp vụ. Cụ thể, chúng ta đang mở rộng tầm nhìn của chúng ta để xem xét các vấn đề CNTT (cụ thể hơn là các hệ thống phần mềm).

Mô hình tình huống sử dụng là mô hình mức CNTT trừu tượng cao nhất của chúng ta. Nó xem xét giải pháp từ quan điểm của các yêu cầu, do đó chúng ta có thể đặt câu hỏi: Giải pháp này cần hỗ trợ hành vi nào? Nó thường dùng để xác định rõ hộp đen hành vi của giải pháp bằng cách mô tả các yêu cầu như là một tập hợp các tương tác giữa các tác nhân bên ngoài với hệ thống. Trong khi mô hình Quy trình nghiệp vụ cung cấp một khung nhìn tuần tự trực tiếp (end-to-end) về các bước nghiệp vụ, mà các bước này trong một số trường hợp có thể bao gồm các tương tác với hệ thống, thì mô hình Tình huống sử dụng chỉ tập trung vào các tương tác này và do đó cung cấp một khung nhìn dựa trên-tương tác về các yêu cầu hệ thống.

Một mô hình tình huống sử dụng định nghĩa hai điều, chủ yếu là:

  • Định nghĩa về các tác nhân bên ngoài, là người tương tác với hệ thống.
  • Một danh sách các tình huống sử dụng mà chúng có tương tác với chúng.

Hơn nữa mỗi đặc tả tình huống sử dụng sẽ bao gồm thông tin về các sự kiện châm ngòi thao tác nghiệp vụ, các điều kiện cần có trước và các điều kiện cần có sau. Tuy nhiên điều quan trọng nhất là sự mô tả từng bước, có chi tiết, về hành vi được diễn tả bởi tình huống sử dụng sẽ được chứa trong luồng các sự kiện cơ sở, cùng với một tập hợp các luồng thay thế có khả năng (thay thế cho luồng các sự kiện cơ sở).

Việc tạo mô hình tình huống sử dụng là rất có ích khi bạn muốn tạo ra một khung nhìn có cấu trúc về phạm vi của hệ thống. Mỗi tình huống sử dụng tạo thành một gói các đặc tả yêu cầu rồi các đặc tả này sẽ được tiếp tục đưa vào luồng công việc của dự án (ví dụ, thiết kế và thực thi). Do đó, bằng cách thêm một tình huống sử dụng vào mô hình, bạn bổ sung thêm công việc thiết kế và thực thi.

Việc phân tích các tương tác tác nhân-hệ thống giúp đỡ rất nhiều khi một ứng dụng phần lớn là dựa vào một giao diện người dùng (UI, màn hình). Ví dụ, trong nghiên cứu tình huống cụ thể của công ty DVD2U của chúng ta, chúng ta sẽ mô hình tình huống sử dụng Thông báo Trả lại, ở đây các thành viên của DV2DU sử dụng một giao diện Web để thông báo cho công ty DVD2U rằng họ đã gửi trả lại đĩa DVD qua đường bưu điện. Các chi tiết của tình huống sử dụng Thông báo trả lại (thông tin do người sử dụng cung cấp) sau đó sẽ được sử dụng để thiết kế trang Web Thông báo Trả lại.

Tuy nhiên, các mô hình Tình huống sử dụng không chỉ gồm các tương tác dựa vào UI. Trong trường hợp khi có một tương tác hệ thống bên ngoài với hệ thống mà bạn đang xác định phạm vi hoạt động, tác nhân sẽ là một tác nhân hệ thống, chứ không phải là một tác nhân con người và phần còn lại của các ý tưởng cơ bản dùng để đặc tả hành vi ở mức các yêu cầu cũng sẽ giống như trong các tương tác dựa vào-UI.

Đối với mỗi một trong hai kiểu tương tác khác nhau ấy, bạn có thể có một tập hợp khác nhau của các vật phẩm làm việc của đặc tả bổ sung thêm, thích hợp với kiểu tương tác cụ thể đó. Ví dụ, tình huống sử dụng hướng đến tác nhân con người luôn có thể lợi dụng các mô hình màn hình đơn giản bổ sung thêm, các đặc tả luồng dẫn hướng và các đặc tả các trường. Theo cùng một cách đó, bạn có thể bổ sung thêm cho các tình huống sử dụng hướng đến tác nhân hệ thống với một ánh xạ đến đặc tả kỹ thuật của hệ thống bên ngoài mà Phần 3 của loạt bài này đã mô tả (xem đường liên kết "Nhiều hơn nữa về các loại bài này" ở góc trên bên trái của màn hình).

Các đầu vào để mô hình hóa tình huống sử dụng

Việc tạo mô hình tình huống sử dụng là một phần của lĩnh vực Các yêu cầu và nó sử dụng các vật phẩm làm việc do các hoạt động dự án trước đó sinh ra. Nói chung, chúng ta chia chúng thành các đầu vào từ trên xuống và từ dưới lên:

  • Các ví dụ về các vật phẩm làm việc từ trên xuống mà chúng ta đã đề cập trong loạt bài này cho đến nay là mô hình thành phần nghiệp vụ (xem Phần 1), mô hình Quy trình Nghiệp vụ (vẫn ở Phần 1) và mô hình Miền (xem Phần 2).
  • Chúng ta đã xem xét một vật phẩm làm việc từ dưới lên: mô hình Hệ thống Bên ngoài (xem Phần 3).

Có một luồng nữa của các vật phẩm làm việc từ trên xuống nằm ngoài phạm vi của loạt bài này, nhưng vẫn rất có ích để ghi lại đối với nhận biết tình huống sử dụng. Luồng này bao gồm các nhu cầu kinh doanh, các đặc tính hệ thống và các đặc tả kỹ thuật bổ sung thêm. Các vật phẩm làm việc này, cùng với những vật phẩm đã đề cập ở trên, được tóm tắt dưới đây trong Hình 1.

Hình 1. Đầu vào cho mô hình tình huống sử dụng
Sơ đồ mô hình tình huống sử dụng

Sau đây là mô tả ngắn gọn về bản chất của các đầu vào này:

  • Mô hình Quy trình Nghiệp vụ. Nó được sử dụng để nhận biết các tác nhiệm nghiệp vụ cần phải được mô tả với các tình huống sử dụng (các tình huống sử dụng đó bao gồm tương tác tác nhân-hệ thống).
  • Mô hình Thành phần Nghiệp vụ. Các lĩnh vực chức năng nghiệp vụ được định nghĩa trong mô hình Thành phần Nghiệp vụ và có thể được sử dụng để làm nên các đường ranh giới của các gói tình huống sử dụng, có nghĩa là các đường ranh giới của các hệ thống sở hữu từng tình huống sử dụng.
  • Mô hình Miền. Khi đặt tên và mô tả các tình huống sử dụng, chúng ta sử dụng bảng từ vựng của các nghiệp vụ được định nghĩa trong mô hình miền.
  • Các đặc tính. Nếu một danh sách các đặc tính được sử dụng như là một cơ chế gọn nhẹ để xác định phạm vi của các yêu cầu của hệ thống, thì đây là một khung nhìn yêu cầu có ích dùng để nhận biết các tình huống sử dụng. Mỗi đặc tính cần theo vết đến ít nhất một tình huống sử dụng hoặc ít nhất đến một đặc tả bổ sung.
  • Mô hình Hệ thống bên ngoài. Hệ thống bên ngoài đã định nghĩa trong mô hình này sẽ trở thành các tác nhân hệ thống trong mô hình Tình huống sử dụng.

Mô hình tình huống sử dụng được dùng như thế nào trong hoạt động tạo mô hình SOA

Như đã nói trước đây, mô hình tình huống sử dụng là một khung nhìn cấu trúc rất có ích về phạm vi của một dự án. Bạn có thể sử dụng chúng như các gói của các yêu cầu thông tin và sắp xếp các thiết kế màn hình dựa theo chúng, bởi vì chúng cung cấp một gói các tương tác con người-UI có liên quan.

Cũng giống như thế, khi SOA là phong cách kiến trúc thì các tình huống sử dụng cung cấp các gói yêu cầu về các tương tác sau đó sẽ được thực hiện với các dịch vụ. Chúng ta sử dụng một kỹ thuật mà, với mỗi tình huống sử dụng trong mô hình Tình huống sử dụng, chúng ta chỉ rõ một sự hợp tác dịch vụ trong mô hình Dịch vụ. Sau đó, với mỗi luồng trong mô hình Tình huống sử dụng (luồng cơ sở và mỗi luồng thay thế), chúng ta chỉ rõ một sự tương tác dịch vụ (một tương tác UML) trong hợp tác dịch vụ. Bằng cách này, chúng ta sử dụng các nội dung của mô hình tình huống sử dụng để đóng gói các đặc tả động trong mô hình dịch vụ.

Tạo mô hình tình huống sử dụng UML trong Kiến trúc sư Phần mềm Rational

Mẹo:
Điểm khởi đầu cho phần này là dự án hướng dẫn SOA, là kết quả của Phần 3 của loạt bài này.

  1. Tải về tệp tin DVD_Rental-Part3-ProjectInterchange.zip (xem Tải về) và sau đó làm theo các hướng dẫn này để nhập khẩu dự án vào trong vùng làm việc của bạn.

Lưu ý:
Nếu bạn vẫn còn có sẵn vùng làm việc từ Phần 3, hãy bỏ qua các bước này và chuyển sang Bước 8.

  1. Khởi động Kiến trúc sư phần mềm Rational. Sử dụng vùng làm việc mặc định hoặc tạo một vùng làm việc mới.
  2. Sau khi nó đã chạy, đóng màn hình Chào đón nếu bạn đang ở trong một vùng làm việc mới.
  3. Chọn File > Import.
  4. Trong trình thủ thuật Import, gõ project vào trong trường có nhãn là Select an import source filter và sau đó chọn Project Interchange và nhấn Next (Hình 2).
Hình 2. Nhập khẩu trao đổi dự án (Import the Project Interchange)
Bắt giữ màn hình của việc trao đổi dự án
  1. Nhấn Browse và trỏ đến vị trí ở đó bạn đã lưu tệp tin DVD_Rental-Part3-ProjectInterchange.zip.
  2. Chọn SOA Tutorial và nhấn Finish (Hình 3).
Hình 3. Nhập khẩu dự án hướng dẫn SOA
Bắt giữ màn hình của của dự án hướng dẫn SOA
  1. Chọn Window > Open Perspective > Modeling để chuyển sang phối cảnh mô hình hóa (nếu bạn chưa ở trong nó).

Nếu bạn mở rộng dự án hướng dẫn SOA, bạn sẽ thấy giống như Hình 4 trong khung nhìn Project Explorer.

Hình 4. Khung nhìn của Project Explorer đầu tiên
Bắt giữ màn hình của Project Explorer đầu tiên
  1. Chọn dự án SOA Tutorial, nhấn chuột phải và chọn New > UML Model.
  2. Trong trình thủ thuật New UML Model, nhấn Next để sử dụng các khuôn mẫu tiêu chuẩn.
  3. Trong màn hình kế tiếp, chỉ rõ tên tệp tin là Use Case Model. Ngoài ra, hãy chắc chắn rằng Create a default diagram in the model được chọn, và sau đó chọn Use Case Diagram cho kiểu sơ đồ mặc định.
  4. Nhấn Finish.

Lưu ý:
Trong hướng dẫn này, mô hình tình huống sử dụng đơn giản đến mức mà chúng ta không cần phải sử dụng khuôn mẫu mô hình tình huống sử dụng đã được cung cấp. Chúng ta chỉ đơn giản sử dụng một khuôn mẫu mô hình rỗng (Blank Model).

Dự án Hướng dẫn SOA của bạn bây giờ trông giống như Hình 5.

Hình 5. Mô hình tình huống sử dụng đầu tiên
Bắt giữ màn hình của mô hình tình huống sử dụng đầu tiên

Chỉ rõ các phần tử của mô hình Tình huống sử dụng

Bây giờ, chỉ rõ các phần tử sau đây của mô hình Tình huống sử dụng: các tác nhân, danh sách các tình huống sử dụng, các phân loại tình huống sử dụng và các luồng trong tình huống sử dụng.

Các tác nhân

Trong mô hình Quy trình nghiệp vụ, chúng ta đã xác định một vai trò có tên là Member (thành viên của DVD2U) và một vai trò khác có tên là Receiving Clerk (nhân viên làm việc tại kho hàng DVD2U). Ngoài ra, trong mô hình Thiết kế (phần các hệ thống bên ngoài), chúng ta đã xác định một hệ thống đang tồn tại để Quản lý Quan hệ Khách hàng (Customer Relationship Management). Tất cả đều là các ứng cử viên trở thành các tác nhân trong mô hình tình huống sử dụng này, vì vậy bây giờ bạn sẽ tạo ra các tác nhân của tình huống sử dụng để đại diện cho các vai trò mà họ sẽ đóng trong các tình huống sử dụng ấy (một tác nhân của tình huống sử dụng định nghĩa một vai trò có thể được đóng khi tương tác với hệ thống).

  1. Trong sơ đồ Main, chọn Actor trong palette và nhấn vào một nơi nào đó trong sơ đồ. Thao tác này sẽ tạo ra một tác nhân mới. Đặt tên nó là Member.
  2. Lặp lại các bước trên cho Receiving Clerk and Customer Relationship Management.

Sơ đồ của bạn bây giờ trông giống như Hình 6.

Hình 6. Các tác nhân của tình huống sử dụng
Bắt giữ màn hình của các tác nhân của tình huống sử dụng

Bạn biết rằng Member và Receiving Clerk là các tác nhân con người, trong khi Quản lý Quan hệ Khách hàng là một hệ thống. Bây giờ bạn sẽ sử dụng các từ khóa để phân biệt giữa các tác nhân con người và tác nhân hệ thống.

  1. Chọn tác nhân Member và trong khung nhìn Properties, nhấn vào phiếu Stereotypes.
  2. human vào trong trường Keywords (Hình 7).
Hình 7. Từ khóa: human
Bắt giữ màn hình của mã trong trường từ khóa
  1. Lặp lại hai bước trên đây cho hai tác nhân còn lại (chỉ rõ là system cho tác nhân Customer Relationship Management).

Mô hình tình huống sử dụng của bạn trong Project Explorer sẽ giống như Hình 8.

Hình 8. Các tác nhân của mô hình Tình huống sử dụng
Bắt giữ màn hình của mô hình Tình huồng sử dụng

Xác định các tình huống sử dụng

Trong mô hình Quy trình Nghiệp vụ, chúng ta đã xác định một tác nhiệm nghiệp vụ có tên là Thông báo trả lại (Notify of return) do Thành viên (Member) thực hiện và được phân loại là tương tác Con người-Hệ thống (Hình 9). Tiếp theo, bạn sẽ tạo ra một tình huống sử dụng cho việc này.

Như một quy tắc chung, hãy coi phạm vi của một tình huống sử dụng hệ thống là ở mức một giao dịch hệ thống nguyên tử (không phân chia) như tác nhân đã trải qua. Điều này có nghĩa là, thay vì trở thành các tình huống sử dụng mới, hai tác nhiệm tiếp theo chỉ có hệ thống thực hiện (vị thế của thành viên lấy ra và gửi đi băng Video kế tiếp) được coi là một phần trong phạm vi của cùng một tình huống sử dụng hệ thống.

Hình 9. Mô hình Quy trình Nghiệp vụ Trả lại băng Video (1/2)
Bắt giữ màn hình của mô hình Quy trình Nghiệp vụ

Ngoài ra, chúng ta đã xác định một tác nhiệm nghiệp vụ khác có tên là Record receipt (Ghi biên nhận) được Receiving Clerk (nhân viên tiếp nhận) thực hiện và được phân loại là tương tác con người-hệ thống (Hình 10). Bạn sẽ tạo ra một tình huống sử dụng nữa cho tác nhiệm này. Theo quy tắc chung đã nói ở trên, việc trả lại bản sao cho kho cấp hàng được coi là một phần của cùng một tình huống sử dụng.

Hình 10. Mô hình Quy trình Nghiệp vụ Trả lại băngVideo (2/2)
Bắt giữ màn hình của mô hình Quy trình Nghiệp vụ

Lưu ý rằng các nhà phân tích nghiệp vụ đã làm một việc rất tốt khi phân loại các tác nhiệm nghiệp vụ trong mô hình Quy trình Nghiệp vụ (mã màu da cam dành cho tác nhiệm chỉ con người làm, màu xám dành cho chỉ hệ thống làm và màu xanh dương dành cho con người và hệ thống). Như bạn có thể thấy, hai tác nhiệm nghiệp vụ mà chúng ta đã dùng để xác định các tình huống sử dụng, được hiển thị màu xanh dương để nói lên rằng chúng là tác nhiệm do con người và hệ thống cùng làm. Vậy thì đó là các ứng cử viên hoàn hảo cho các tình huống sử dụng. Tuy nhiên, một số tình huống sử dụng sẽ chỉ dựa vào các tác nhiệm chỉ do hệ thống làm. Trường hợp này, hoặc sẽ có một tác nhân hệ thống hoặc Thời gian sẽ là một tác nhân nếu chúng được bắt đầu bởi kiểu xử lý theo bó (batch). Cũng lưu ý rằng các tác nhiệm chỉ con người làm không có bất kỳ tình huống sử dụng hệ thống tương ứng nào, bởi vì chúng hoàn toàn thực hiện bằng tay (mặc dù chúng có thể đem lại các kết quả mà các tác nhiệm hướng xuống chỉ con người làm hoặc chỉ hệ thống làm sẽ sử dụng).

Đối với hướng dẫn này, bạn không cần phải xem chi tiết về các đầu nối (số bội và vai trò) trên các sơ đồ UML của tình huống sử dụng. Hãy thay đổi các lựa chọn Ưa thích (Preferences) của bạn ngay bây giờ để Kiến trúc sư Phần mềm Rational không hiển thị chúng theo mặc định:

  1. Chọn Window > Preferences.
  2. Trong Preferences, gõ connector vào trường Filter.
  3. Nhấn Modeling > Diagrams > Appearance và chọn Connectors (see Figure 11).
  4. Bỏ chọn cả hai Show multiplicityShow roles (Hình 11) và sau đó nhấn vào ApplyOK.
Hình 11. Lựa chọn ưa thích đối với connectors
Bắt giữ màn hình của connector
  1. Trong sơ đồ Main, chọn Use Case trong palette, và nhấn vào một vùng trống của sơ đồ tình huống sử dụng. Điều này sẽ tạo ra một tình huống sử dụng mới. Hãy đặt tên nó là Notify of Return.
  2. Lặp lại các bước trên cho tình huống sử dụng Record Receipt.
  3. Member là một vai trò đối với Notify of Return. Hãy đặt con trỏ chuột của bạn lên trên Member. Khi đầu nối (connector) đi ra xuất hiện (Hình 12), nhấn chuột và kéo nó lên trên Notify of Return.
Hình 12. Đầu nối đi ra của một vai trò
Sơ đồ đầu nối đi ra
  1. Lặp lại các bước trên để kết nối Customer Relationship Management đến Notify of Return và để kết nối Receiving Clerk đến Record Receipt.

Sơ đồ của bạn bây giờ trông giống như Hình 13.

Hình 13. Các tình huống sử dụng và các tác nhân
Sơ đồ của tình huống sử dụng

Tổ chức các tình huống sử dụng

Với các mô hình tình huống sử dụng lớn hơn (ví dụ, những mô hình có chứa một tá các tình huống sử dụng), thì phân loại các tình huống sử dụng là một cách làm tốt. Có nhiều cách tiếp cận phân loại khác nhau mà bạn có thể làm theo. Một cách là phân loại các tình huống sử dụng theo các lĩnh vực chức năng nghiệp vụ mà các tình huống sử dụng nằm trong đó. Bạn sẽ làm điều đó với ví dụ mô hình Tình huống sử dụng này, mặc dù nó chứa chỉ có hai tình huống sử dụng. Trong trường hợp này, các lĩnh vực chức năng nghiệp vụ là các thành phần nghiệp vụ của Mô hình Thành phần Nghiệp vụ (Hình 14).

Hình 14. Bản đồ Mô hình Thành phần Nghiệp vụ cho DVD2U
Bản đồ của Mô hình Thành phần Nghiệp vụ

Trong nghiên cứu tình huống cụ thể DVD2U này, có hai thành phần nghiệp vụ thích hợp: Online Rentals (đối với Notify of Return và các tác nhân của nó) và Tracking (đối với Record Receipt và các tác nhân của nó). Bây giờ bạn sẽ phân loại hai tình huống sử dụng cho phù hợp.

  1. Từ Project Explorer, chọn Use Case Model, nhấn chuột phải vào và chọn Add UML > Package.Đặt tên gói là Online Rentals.
  2. Từ Project Explorer, kéo các phần tử Notify of Return, Customer Relationship ManagementMember lên trên gói Online Rentals.
  3. Mở sơ đồ đã được tự động tạo ra trong gói Online Rentals và kéo ba phần tử mô hình lên trên nó. Đổi tên sơ đồ thành Online Rentals Use Cases.
  4. Lặp lại ba bước trên để di chuyển Record Receipt Receiving Clerk vào một gói Tracking. Dùng Tracking Use Cases làm tên sơ đồ.
  5. Lưu mô hình của bạn (CTRL + S).

Mô hình tình huống sử dụng của bạn trong Project Explorer bây giờ trông giống như Hình 15.

Hình 15. Các mô hình tình huống sử dụng trong Project Explorer
Bắt giữ màn hình của mô hình trong Project Explorer

Lưu ý:
Trong hoạt động tạo mô hình tình huống sử dụng điển hình, kiến trúc sư sẽ duyệt tính hợp lệ các tình huống sử dụng để loại bỏ bất kỳ mục nào không quan trọng về mặt kiến trúc và để đảm bảo rằng chúng được phân chia một cách thích hợp. Trong ví dụ DVD2U đơn giản này, chúng ta tiếp tục sử dụng hai tình huống sử dụng và chúng ta sẽ đảm bảo chắc chắn rằng thiết kế của chúng ta đáp ứng các yêu cầu mà chúng mô tả.

Luồng của tình huống sử dụng

Xác định tập hợp các tình huống sử dụng để mô tả phạm vi của dự án luôn được thực hiện bằng cách sử dụng một mô hình tình huống sử dụng, nhưng điều này chỉ là một phần nhỏ của toàn bộ đặc tả của tình huống sử dụng. Nhiều sự nỗ lực đã dành cho việc mô tả chi tiết từng đặc tả của tình huống sử dụng. Đây là nơi các yêu cầu chính xác được chỉ rõ. Đây là nơi phân tích các yêu cầu được thực hiện, do một nhà phân tích hệ thống tiến hành. Nhiều vật phẩm làm việc khác sẽ được sử dụng làm đầu vào có ích, như được mô tả ở trên.

Đối với mỗi tình huống sử dụng, các thông tin sau đây cần được nắm bắt (ngoài lĩnh vực chức năng và các tác nhân của nó):

  • Tổng quan. Một mô tả mức cao về mục tiêu của tình huống sử dụng trong một hoặc hai câu.
  • Sự kiện nghiệp vụ. Điều gì châm ngòi tình huống sử dụng.
  • Các điều kiện cần có trước. Các điều kiện phải được thỏa mãn để cho tình huống sử dụng xảy ra.
  • Các điều kiện cần có sau. Những gì đã được thay đổi như là kết quả thực hiện tình huống sử dụng.

Tình huống sử dụng Notify of Return có thể trông giống như ví dụ này:

Tổng quan: Tình huống sử dụng này mô tả cách làm thế nào để một thành viên DVD2U có thể sử dụng giao diện người dùng DVD2U để thông báo cho DVD2U rằng họ đã trả lại DVD qua bưu điện.

Sự kiện nghiệp vụ: Thành viên muốn thông báo cho DVD2U về việc đã trả lại một hay nhiều đĩa DVD.

Các điều kiện cần có trước: Thành viên đã đăng nhập vào hệ thống. Thành viên đã xem các phần thuê (Member Rentals) của họ.

Các điều kiện cần có sau: Đối với mỗi tên phim video được trả lại, trạng thái của nó được thay đổi thành ĐÃ TRẢ LẠI (RETURNED).

Lưu ý:
Kiểu thông tin này (cũng như văn bản mô tả các luồng) thường được nắm bắt để tăng năng suất làm tài liệu phần mềm (như Microsoft® Word®). Ví dụ, bạn có thể sử dụng một khuôn mẫu với một phần cho mỗi của tình huống sử dụng, với thông tin cụ thể trong các bảng.

Trong hướng dẫn này, bạn đơn giản sẽ nắm bắt những thông tin này trong trường tài liệu của tình huống sử dụng UML:

  1. Từ Project Explorer, chọn tình huống sử dụng Notify of Return.
  2. Từ khung nhìn Properties, chọn phiếu Documentation sao chép và dán thông tin mà Listing 1 hiển thị.
Listing 1. Tài liệu tình huống sử dụng Notify of Return
Tổng quan:
Tình huống sử dụng này mô tả cách làm thế nào để  một thành viên DVD2U có thể 
sử dụng giao diện người dùng DVD2U để thông báo cho DVD2U rằng họ đã trả lại 
(các) đĩa DVD qua bưu điện.

Sự kiện nghiệp vụ:
Thành viên muốn thông báo cho DVD2U về việc trả lại một hay nhiều đĩa DVD.

Các điều kiện cần có trước:
* Thành viên đã đăng nhập vào hệ thống. 
* Thành viên đã xem phần thuê của họ.

Các điều kiện cần có sau:
Đối với mỗi tên phim video được trả lại, trạng thái của nó được thay đổi thành 
RETURNED.

Phần chủ yếu của đặc tả của một tình huống sử dụng chứa trong các luồng của tình huống sử dụng. Một luồng của tình huống sử dụng mô tả cách làm thế nào để đạt được kết quả của tình huống sử dụng đó (ví dụ, Thành viên đã có thông báo trả lại), thông qua một chuỗi các tương tác tác nhân-hệ thống và các hoạt động hệ thống. Đối với mỗi tình huống sử dụng, bạn cần ít nhất một luồng cơ bản ("ngày nắng đẹp" hoặc "con đường hạnh phúc" xảy ra trong điều kiện bình thường) và tùy chọn, một hoặc nhiều luồng thay thế (các kịch bản "ngày mưa" hay "con đường không may mắn").

Với DVD2U, việc khai báo đã gửi trả lại cho phép các thành viên có vị thế tốt nhận được tên phim tiếp theo của họ đã được gửi đi trước khi tên phim trước đó (mà họ đã báo trả lại) đến kho tiếp nhận. Điều này mang lại cho các thành viên một động cơ để thông báo cho DVD2U rằng họ đã trả lại video của mình. Ngoài ra, điều này cho phép DVD2U quản lý tốt hơn nguồn cung cấp đĩa DVD và có thể biết được khi nào một đĩa DVD bị mất. Đối với Notify of Return, chúng ta xác định một luồng cơ bản và một luồng thay thế cho các thành viên được đánh giá:

Listing 2. Luồng cơ bản của Notify of Return
1. Thành viên chỉ rõ họ đã trả lại các phần thuê nào.

Lặp lại các bước 2-5 cho mỗi phần thuê của thành viên được chỉ rõ là đã trả lại: 

2. Hệ thống cập nhật dấu thời gian thông báo trả lại của phần thuê này.
3. Hệ thống lấy ra trạng thái băng video của phần thuê này.
4. Hệ thống cập nhật trạng thái băng video là TRÊN_ĐƯỜNG_TRỞ_VỀ (ON_THE_WAY_BACK).
5. Hệ thống lấy ra tên phim trong danh sách video của phần thuê này.
6. Hệ thống cập nhật trạng thái tên phim trong danh sách video thành RETURNED.
7. Hệ thống lấy ra thành viên ứng với phần thuê này 
    và kiểm tra vị thế thành viên ấy.

Lưu ý cách thức mô tả luồng đã sử dụng rất nhiều các đặc tả thông tin nghiệp vụ có chứa trong mô hình Miền ví dụ, để mô tả thay đổi về trạng thái của các phần tử miền.

Listing 3. Luồng thay thế của Notify of Return
7a. Thành viên được đánh giá vị thế thành viên:
7a.1 Hệ thống lấy ra danh sách phim video của thành viên. 
7a.2 Hệ thống thiết lập isNextVideoRequired của danh sách phim video của 
thành viên thành ĐÚNG (TRUE). 
7a.3 Hệ thống thông báo cho Thành viên rằng phim video tiếp theo sẽ được gửi đi.
  1. Thêm thông tin luồng vào trường Documentation của Notify of Return.

Tài liệu hướng dẫn cho Thông báo Trả lại bây giờ được hiển thị như Listing 4.

Listing 4. Tài liệu hướng dẫn của Notify of Return đã sửa lại
Tổng quan:
Tình huống sử dụng  này mô tả cách làm thế nào để  một thành viên DVD2U có thể 
sử dụng giao diện người dùng DVD2U để thông báo cho DVD2U rằng họ đã trả lại 
(các) đĩa DVD qua bưu điện.

Sự kiện nghiệp vụ:
Thành viên muốn thông báo cho DVD2U về việc trả lại một hay nhiều đĩa DVD.

Các điều kiện cần có trước:
* Thành viên đã đăng nhập vào hệ thống.
* Thành viên đã xem các phần thuê của họ.

Các điều kiện cần có sau:
Đối với mỗi tên phim video được trả lại, trạng thái của nó được thay đổi 
thành RETURNED.

Luồng cơ bản:
1. Thành viên chỉ rõ các phần thuê nào của thành viên đã được gửi trả lại.

Lặp lại các bước 2-5 cho mỗi phần thuê của thành viên được chỉ rõ là đã gửi trả: 
2. Hệ thống cập nhật dấu thời gian thông báo trả lại của phần thuê này.
3. Hệ thống lấy ra trạng thái băng video với phần thuê này.
4. Hệ thống cập nhật trạng thái băng video là ON_THE_WAY_BACK.
5. Hệ thống lấy ra trạng thái phim trong danh sách video của phần thuê này.
6. Hệ thống cập nhật trạng thái tên phim trong danh sách video thành RETURNED.
7. Hệ thống lấy ra thành viên ứng với phần thuê này 
    và kiểm tra vị thế thành viên ấy.

Các luồng thay thế:
7a. Thành viên được đánh giá vị thế thành viên:
7a.1 Hệ thống lấy ra danh sách phim video của thành viên.
7a.2 Hệ thống thiết lập isNextVideoRequired của danh sách phim video của thành viên 
thành TRUE.
7a.3 Hệ thống thông báo cho Thành viên rằng phim video tiếp theo sẽ được gửi đi.

Lời khuyên về cách dùng công cụ

Các tiểu mục tiếp theo đưa ra các nhận xét hữu ích về cách làm sao có thể sử dụng nhiều công cụ khác nhau để tạo mô hình Tình huống sử dụng.

Tạo các sơ đồ mô tả các luồng

Trong Kiến trúc sư Phần mềm Rational, bạn có thể sử dụng các Hoạt động UML để chỉ rõ các luồng trong tình huống sử dụng theo các bước sau:

  1. Từ Project Explorer, chọn một tình huống sử dụng, nhấn chuột phải vào và chọn Add UML > Activity.
  2. Sau đó, bên trong sơ đồ Activity, sử dụng các phân vùng (các tác nhân), các hành động và các luồng để chỉ rõ điều gì sẽ xảy ra.
  3. Lặp lại cho từng luồng.

Chúng ta đã không làm điều đó trong hướng dẫn này, bởi vì chúng ta muốn giữ cho mô hình tình huống sử dụng đơn giản và chỉ hiển thị mô tả luồng bằng lời văn. Một điều bất lợi trong cách tiếp cận này là các luồng được mô tả đơn thuần bằng lời văn và vì vậy không thể sử dụng được như là một phần của cách tiếp cận phát triển hướng mô hình (xác nhận tính hợp lệ, tự động hóa). Ví dụ, làm thế nào để bạn có thể tự động nói ngay được rằng mỗi tình huống sử dụng có ít nhất một luồng cơ bản gắn với nó hay là không? Trình bày chi tiết đặc tả kỹ thuật này là vượt ra ngoài phạm vi của hướng dẫn này. Mặc dù chúng tôi đã khuyến cáo rằng bạn nên xem xét việc sử dụng các hoạt động UML để tạo mô hình các luồng tình huống sử dụng, nhưng chúng ta cần thừa nhận rằng kỹ thuật này có thể không phù hợp với tất cả mọi người.

Sử dụng Requisite Pro

Rational® RequisitePro® của IBM® là sản phẩm mà chúng ta đã sử dụng để quản lý tất cả các yêu cầu, bao gồm cả các tình huống sử dụng. Hãy nhớ lại rằng chúng ta đã nói thông tin về tình huống sử dụng có thể nắm giữ trong các tài liệu Word. Trong trường hợp này, bạn có thể sử dụng RequisitePro và một công cụ tích hợp Word để đưa thông tin tình huống sử dụng vào trong cơ sở dữ liệu của RequisitePro. Sau đó, bằng cách sử dụng đặc tính tích hợp của Kiến trúc sư Phần mềm Rational và RequisitePro, bạn có thể theo vết các phần tử của mô hình tình huống sử dụng UML đến các phần tử của dự án Requisite Pro. Chúng ta đã không trình bày điều này ở đây, bởi vì nó đã được đề cập trong các bài viết khác của developerWorks.

Bảo đảm khả năng theo vết

Trong những đoạn trước, chúng ta nói về khả năng theo vết từ mô hình UML của Kiến trúc sư Phần mềm Rational đến dự án các yêu cầu của RequisitePro. Một đường theo vết khác đi từ mô hình UML của Kiến trúc sư Phần mềm Rational đến mô hình Quy trình nghiệp vụ của bộ tạo Mô hình nghiệp vụ WebSphere® của IBM®. Chúng ta đã xác định các tình huống sử dụng từ các tác nhiệm trong mô hình Quy trình nghiệp vụ và chúng ta có thể bao gồm cả việc theo vết này giữa các mô hình của chúng ta. Chúng ta đã không trình bày điều này ở đây, bởi vì Phần 2 đã thảo luận việc tích hợp của Kiến trúc sư Phần mềm Rational và bộ tạo Mô hình nghiệp vụ WebSphere.


Phần tiếp theo có gì

Phần này trong loạt bài hướng dẫn giải thích việc sử dụng mô hình tình huống sử dụng để mô tả phạm vi của dự án bằng các tình huống sử dụng, là cốt lõi của lĩnh vực đặc tả yêu cầu. Chúng ta đã thảo luận về tầm quan trọng của hoạt động này trong một dự án SOA và sau đó phác thảo cách tạo một mô hình tình huống sử dụng trong Kiến trúc sư Phần mềm Rational. Chúng ta sau đó xem xét việc mô hình hóa nhiều phần tử khác nhau của mô hình này (các tác nhân, các tình huống sử dụng) và chi tiết hóa từng đặc tả của tình huống sử dụng. Trong các phần tiếp theo của loạt bài này, chúng ta sẽ trình bày một mô hình, là cốt lõi của kiến trúc hướng dịch vụ: Service model.


Các tải về

Mô tảTênKích thước
dự ánDVD_Rental-Part3-ProjectInterchange.zip13KB
dự ánDVD_Rental-Part4-ProjectInterchange.zip17KB

Tài nguyên

Học tập

  • Đọc phần 1 của loạt bài này, "Model Service-Oriented Architectures with Rational Software Architect: Part 1. Case study, tools, and the business view ".
  • Đọc phần 2 của loạt bài này, "Model Service-Oriented Architectures with Rational Software Architect: Part 2. Modeling the business domain ".
  • Đọc phần 3 của loạt bài này, "Model Service-Oriented Architectures with Rational Software Architect: Part 3. External system modeling ".
  • Đọc bài viết giới thiệu trong developerWorks, "The Rational UML profile for business modeling" của Simon Johnston (tháng tư năm 2004). Lược tả UML Rational dành cho việc tạo mô hình nghiệp vụ là một thành phần của Quy trình thống nhất Rational (RUP). Nó trình bày một ngôn ngữ UML để nắm bắt các mô hình nghiệp vụ và được hỗ trợ bởi lĩnh vực mô hình hóa nghiệp vụ trong RUP.
  • Đọc các loạt bài viết mức-trung cấp trong developerWorks, "Modeling SOA" của Jim Amsden (10. 2007). Một loạt năm bài viết về việc phát triển phần mềm dựa trên kiến trúc hướng-dịch vụ (SOA). Nó chỉ ra cách làm thế nào để sử dụng các mô hình UML được mở rộng với lược tả Dịch vụ Phần mềm của IBM để thiết kế một giải pháp SOA được kết nối với các yêu cầu nghiệp vụ kinh doanh, nhưng vẫn độc lập về việc triển khai thực hiện giải pháp. Tác giả mô tả các mục đích và mục tiêu kinh doanh và các quy trình nghiệp vụ được thực thi để đáp ứng các mục tiêu đó, và sau đó giải thích cách sử dụng các quá trình xử lý như thế nào để nhận dạng các dịch vụ liên quan đến nghiệp vụ cần phải có để đáp ứng các yêu cầu mà chúng mô tả.
  • Truy cập Rational software area on developerWorks để tìm các nguồn tài nguyên kỹ thuật và các cách thực hành tốt nhất đối với sản phẩm Rational Software Delivery Platform.
  • Đăng ký vào developerWorks Rational zone newsletter. Theo sát các nội dung của developerWorks Rational. Mỗi tuần, bạn sẽ nhận được cập nhật về các nguồn tài nguyên kỹ thuật mới nhất và các cách thực hành tốt nhất cho Rational Software Delivery Platform.
  • Đăng ký vào Rational Edge newsletter để tìm các bài viết về các khái niệm phía sau việc phát triển phần mềm có hiệu quả.
  • Duyệt qua technology bookstore để tìm các sách về chủ đề kỹ thuật này và các chủ đề khác.

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, SOA và dịch vụ Web
ArticleID=385703
ArticleTitle=Mô hình Kiến trúc Hướng Dịch vụ với Kiến trúc sư Phần mềm Rational: Phần 4. Các mô hình tình huống sử dụng
publish-date=05212009