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 pdf

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 Bertrand Portier, Kiến trúc IT, IBM Software Group Services Gregory Hodgkinson, Đầu ngành SOA, Prolifics Tóm tắt: 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ể đó. 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ề đầu trang 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. Về đầu trang 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. Về đầu trang 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). Về đầu trang 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 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ô 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ư. .. 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 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... 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 ... 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... 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 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... đồ 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 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... 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... 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 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,...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 2 Khởi động Kiến trúc sư phần mềm Rational Sử dụng... DVD_Rental-Part3ProjectInterchange.zip 7 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 8 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 9 Chọn dự án SOA Tutorial, nhấn . 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 Bertrand Portier, Kiến trúc IT, IBM Software Group Services. 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. 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