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
lượt xem 13
download
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...
Bình luận(0) Đăng nhập để gửi bình luận!
Nội dung Text: 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
- 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ẹ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 vùng làm việc mặc định hoặc tạo một vùng làm việc mới. 3. 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. 4. Chọn File > Import. 5. 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) 6. Nhấn Browse và trỏ đến vị trí ở đó bạn đã lưu tệp tin DVD_Rental-Part3- ProjectInterchange.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 chuột phải và chọn New > UML Model. 10. 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. 11. 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. 12. 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
- 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ạ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. 3. Chọn tác nhân Member và trong khung nhìn Properties, nhấn vào phiếu Stereotypes. 4. Gõ human vào trong trường Keywords (Hình 7).
- Hình 7. Từ khóa: human 5. 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 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) 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) 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: 6. Chọn Window > Preferences. 7. Trong Preferences, gõ connector vào trường Filter. 8. Nhấn Modeling > Diagrams > Appearance và chọn Connectors (see Figure 11). 9. Bỏ chọn cả hai Show multiplicity và Show roles (Hình 11) và sau đó nhấn vào Apply và OK.
CÓ THỂ BẠN MUỐN DOWNLOAD
-
Mô hình lập trình SOA để triển khai thực hiện các dịch vụ Web, Phần 8: Các dịch vụ Web dựa vào con người
11 p | 144 | 28
-
Thiết kế các dịch vụ SOA với Rational Software Architect, Phần 1
53 p | 141 | 25
-
Viết các dịch vụ REST
36 p | 130 | 24
-
Thiết kế các dịch vụ SOA với Rational Software Architect, Phần 2
45 p | 152 | 24
-
Mô hình hóa SOA: Phần 1
23 p | 118 | 22
-
Thiết kế các dịch vụ SOA với Rational Software Architect, Phần 4
42 p | 129 | 21
-
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 5
6 p | 133 | 19
-
Phân tích thiết kế hệ thống hướng đối tượng dùng UML - Phân tích kiến trúc
36 p | 93 | 16
-
Nghiên cứu kiến trúc hướng dịch vụ và đối tượng - 4
27 p | 115 | 13
-
Mô hình Kiến trúc Hướng- Dịch vụ với Kiến trúc sư phần mềm Rational
5 p | 138 | 12
-
Mô hình kiến trúc hướng dịch vụ với
5 p | 115 | 11
-
Kiến trúc tiến hóa và thiết kế nổi dần: Tái cấu trúc mã nguồn hướng theo thiết kế
22 p | 60 | 7
-
Kiến trúc tiến hóa và thiết kế nổi dần: Thiết kế hướng theo kiểm thử, phần 2 Bàn luận thêm về việc cho phép dùng kiểm thử để định hướng và cải thiện thiết kế của bạn
18 p | 99 | 7
-
Phân tích hiệu năng của kiến trúc Internet Web caching nhờ sử dụng mô hình mạng Petri có màu và thời gian ngẫu nhiên
9 p | 50 | 7
-
Bài giảng Phát triển phần mềm hướng dịch vụ: Phần 2
65 p | 30 | 7
-
Formalizing and checking web service discovery models using B
12 p | 45 | 2
-
Nghiên cứu ứng dụng kiến trúc hướng dịch vụ trong mô hình hóa quy trình nghiệp vụ
4 p | 50 | 2
Chịu trách nhiệm nội dung:
Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA
LIÊN HỆ
Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM
Hotline: 093 303 0098
Email: support@tailieu.vn