Mô hình Kiến trúc Hướng- Dịch vụ với Kiến trúc sư phần mềm Rational: Tạo mô hình của hệ thống bên ngoài

Hướng dẫn thứ ba trong loại bài này trình bày cách làm thế nào để bạn có thể sử dụng mô hình các hệ thống bên ngoài như là một phần trong đoạn đường từ dưới lên của cách tiếp cận “gặp ở giữa chừng” (meet-in-the-middle). Nó tiếp tục sử dụng nghiên cứu tình huống của một công ty cho thuê DVD trực tuyến tưởng tượng đã giới thiệu trong hai 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 các hệ thống bên ngoài dựa vào nghiên cứu tình huống đó.

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



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



20 05 2009

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

Hãy tìm xem hiểu 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 công cụ 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, nhưng hướng dẫn này cũng rất có ích cho các chuyên viên làm những nhiệm vụ khác trong quá trình phát triển phần mềm. Đó có thể là các nhà phân tích nghiệp vụ (nhất là Phần 1), hoặc các nhà thiết kế và phát triển phần mềm, những người sẽ sử dụng kiến trúc này làm đầu vào cho các hoạt động của mình (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, có ích cho nhiều độc giả.

Loạt bài hướng dẫn này tập trung vào việc dạy bạn cách làm thế nào để thực hiện ba việc sau:

  • Kiến trúc: Mô tả kiến trúc 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ụ: Tạo ra kiến trúc cho một hệ thống SOA (các dịch vụ là trung tâm của kiến trúc này).
  • Các dịch vụ: 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) theo đặ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 liên quan đến SOA- và kiến trúc- của nó. Thông qua nghiên cứu tình huống của một công ty cho thuê DVD trực tuyến tưởng tượng, loạt bài này làm các việc sau:

  • 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 các 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 (nguyên tử) 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ủ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 Quy trình thống nhất Rational (RUP - Rational Unified Process) của IBM 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 vật phẩm làm việc ấy: 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 này, chúng ta sẽ trình bày cách làm thế nào để bạn có thể sử dụng một mô hình các hệ thống bên ngoài như là một phần trong đoạn đường từ dưới lên của cách tiếp cận “gặp ở giữa chừng” (meet-in-the-middle).

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ả mô hình một hệ thống bên ngoài được sử dụng để mô hình hóa các hệ thống phần mềm bên ngoài như thế nào.
  • Tạo một mô hình hệ thống bên ngoài cho một nghiên cứu tình huống cụ thể.

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, nên (nhưng không nhất thiết) làm quen trước với:

Chúng tôi cũng khuyến cáo bạn nên đọc hai phần đầu tiên của loạt bài hướng dẫn trước khi đọc phần này.

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 003) hoặc mới hơn.


Xác định vị trí của các hệ thống bên ngoài và phân tích từ dưới lên

Phần 1 của loạt hướng dẫn này đã đề cập đến mô hình các hệ thống bên ngoài như là một đầu vào cho các hoạt động kiến trúc dịch vụ . Nó cũng đưa ra mô tả ngắn như sau: Chúng (các hệ thống bên ngoài) là các hệ thống không phải-SOA mà bạn có thể sử dụng. Như chúng ta đã lưu ý trước đó, mô hình các hệ thống bên ngoài có thể được sử dụng như là một phần trong đoạn đường từ dưới lên của cách tiếp cận gặp ở giữa chừng.

Tiếp theo, chúng tôi giải thích tại sao việc có một khung nhìn về các hệ thống không phải-SOA được bạn sử dụng như là một phần của giải pháp là rất quan trọng trong một dự án tích hợp kiểu SOA, cùng với cách đạt được điều này như thế nào khi sử dụng mô hình các hệ thống bên ngoài.

Xác định vị trí của mô hình hệ thống bên ngoài

Mô hình các hệ thống bên ngoài không chính thức tồn tại trong RUP. Tuy nhiên nó được ánh xạ tương ứng với một vật phẩm làm việc của RUP hiện có: Mô hình thiết kế. Hình 1 nhằm minh họa cách ánh xạ này hoạt động.

Hình 1. Ánh xạ tương ứng mô hình hệ thống bên ngoài với mô hình thiết kế
Sơ đồ cho thấy ánh xạ của mô hình hệ thống bên ngoài cho mô hình thiết kế

Tham khảo Hình 1, chúng ta nêu định nghĩa sau đây về mô hình hệ thống bên ngoài:

  • Nó nắm bắt, ở mức thiết kế, một cách mô tả các phần mềm không hướng dịch vụ cấu thành nên một phần của giải pháp.
  • Phần mềm mà nó mô tả có thể bao gồm cả hai loại phần mềm hoàn toàn mới cho nghiệp vụ (ví dụ, các gói phần mềm mới được mua và yêu cầu tích hợp thêm), cũng như phần mềm hiện có được doanh nghiệp sử dụng (thường được gọi là phần mềm thừa kế), mặc dù vẫn tập trung vào phần mềm không hướng dịch vụ.
  • Mục đích của nó là để nắm bắt định dạng và các ràng buộc của phần mềm ở bên ngoài, nhưng được tích hợp vào trong các hệ thống phần mềm hướng-dịch vụ.
  • Vì nó ánh xạ với mô hình thiết kế, chúng ta cho nó thuộc "sở hữu" của lĩnh vực Phân tích và Thiết kế RUP.
  • Vai chủ sở hữu là người thiết kế, người sẽ tạo ra hoặc khởi nguồn (nhận) hầu hết các mô hình trong giai đoạn Khởi đầu trong một dự án dựa trên RUP. Chúng ta nói, "tạo ra hoặc khởi nguồn", vì các nhà thiết kế có thể tạo ra những cái mới hoặc sử dụng các phần tử mô hình và các sơ đồ đang có.
  • Chúng ta coi mô hình hệ thống bên ngoài như là một trong những vật phẩm làm việc được tạo ra như là một phần trong đoạn đường từ dưới lên của cách tiếp cận gặp ở giữa chừng.

Mô hình dịch vụ cũng là một mô hình mức-thiết kế. Khi cần phân biệt giữa một mô hình dịch vụ và một mô hình thiết kế, mô hình dịch vụ sẽ chứa các đặc tả kỹ thuật của bản thiết kế ở một mức độ trừu tượng cao hơn và chỉ sử dụng các phần tử SOA (ví dụ, nhà cung cấp dịch vụ, dịch vụ, người dùng dịch vụ, đặc tả kỹ thuật của dịch vụ). Sau đó, mô hình thiết kế đóng vai trò như là một mô hình thiết kế chi tiết và có chứa cả các tạo phẩm SOA và các tạo phẩm không phải SOA.

Theo ngôn ngữ thực hành, mô hình hệ thống bên ngoài có thể được xem hoặc như một tập hợp các gói trong mô hình thiết kế có chứa các thông tin thuộc phạm vi như vẽ trong Hình 1, hoặc hoàn toàn tách biệt khỏi mô hình thiết kế nhưng ở cùng một mức độ trừu tượng.

Lưu ý:
Chúng ta sử dụng thuật ngữ hệ thống với ý nghĩa như được định nghĩa trong Quy trình thống nhất Rational (xem phần Tài nguyên để biết thêm thông tin): "Một tập hợp các đơn vị liên kết với nhau, được tổ chức để thực một mục đích cụ thể". Bất cứ ở đâu chúng ta sử dụng từ hệ thống, bạn đều có thể thay thế nó bằng hệ thống con, giải pháp, ứng dụng, ứng dụng hỗn hợp hoặc ứng dụng nghiệp vụ.

Phân tích từ dưới lên trong một dự án SOA hoặc dự án tích hợp

Trong SOA, cách tiếp cận từ dưới lên là nói về cách phân tích các tài sản CNTT hiện có (ví dụ như các ứng dụng và hệ thống thừa kế) và tìm ra các chức năng có thể được trưng bày như là các dịch vụ để tái sử dụng cho nhiều mục đích khác nhau. Ví dụ, cách tiếp cận từ dưới lên phân tích các giao tác của Hệ thống Quản lý Thông tin hiện có (IMS) hoặc các chương trình COBOL.

Việc tái sử dụng là một phần quan trọng của SOA và là thiết yếu đối với sự thành công của nó. Như bạn có lẽ đã biết, các ứng dụng thừa kế của bạn (đó là những ứng dụng đã được triển khai) là tài sản có giá trị nhất của công ty của bạn, như vậy, điều quan trọng là phải tận dụng lợi ích của chúng bất cứ khi nào và bất cứ cách nào có thể.

Lưu ý:
IBM cung cấp các phương pháp, các kỹ thuật và các mô hình sử dụng đặc biệt dành cho "di sản thừa kế để biến đổi SOA". Ngoài ra, việc sử dụng các công cụ phân tích tài sản hiện có, như bộ phân tích tài sản WebSphere Studio (WebSphere Studio Asset Analyzer) của IBM, là quan trọng, bởi vì thường không ai biết chính xác những gì được triển khai và đang chạy! Tuy nhiên, điều này không phải là chủ đề của bài viết này. Ở đây, chúng ta chỉ muốn chỉ ra cách làm thế nào để bạn sẽ nắm bắt được các kết quả của một cách tiếp cận từ dưới lên bằng cách sử dụng bản Kiến trúc sư phần mềm Rational.

Cách tiếp cận từ dưới lên thường sử dụng các dự án tích hợp, khi một số phần mềm cần được tích hợp thành một giải pháp tổng thể và phần mềm này chưa được thiết kế và xây dựng như là một phần mềm hướng-dịch vụ. Khi nói thế, chúng ta muốn nói phần mềm mà ở đó các bộ phận của kiến trúc đã không được thiết kế đặc biệt như là sự tương tác giữa những người dùng dịch vụ và nhà cung cấp dịch vụ. Điều này cũng kéo theo nhiều thứ khác hơn là chỉ đơn giản bổ sung thêm dịch vụ vào các bộ phận phần mềm của bạn. Nhất là một giải pháp hướng dịch vụ cần có logic hoạt động của nó được cấu trúc sao cho các phần riêng lẻ có thể được tích hợp vào một số các hệ thống hướng dịch vụ.

Việc phân tích từ dưới lên thực sự là công việc điều tra nghiên cứu hình dáng bên ngoài của phần mềm được tích hợp vào trong giải pháp của bạn, sao cho bạn hiểu rõ hai điều then chốt:

  • Các chức năng được phần mềm ấy cung cấp.
  • Mọi ràng buộc mà điều này đặt ra đối với giải pháp đang xét.

Công việc phân tích này được thực hiện trong giai đoạn Khởi đầu của RUP đối với các dự án tích hợp, bởi vì thông tin này có thể có ý nghĩa quan trọng liên quan tới chi phí và lịch trình của dự án.

Một vài ví dụ:

  • Bạn có thể khám phá ra rằng có phần mềm cần phải được tích hợp vào trong giải pháp nhưng lại có độ phức tạp đáng kể trong các giao diện lập trình ứng dụng của nó (API) đã đưa ra.
  • Có thể có chức năng cần phải được tích hợp mà lại không xuất hiện trong khi làm việc từ trên xuống (nói cách khác, khi xem xét các quy trình nghiệp vụ).
  • Khi hứa hẹn với các chuyên gia hệ thống về các hệ thống bên ngoài này, bạn có thể phát hiện ra rằng đã có nhiều thay đổi với các API mà chúng đưa ra, những thay đổi này sẽ ảnh hưởng đến tính thời sự của dự án của bạn.
  • Có thể có sự trùng lặp dữ liệu giữa các hệ thống cần phải được giải quyết bởi kiến trúc của giải pháp.
  • Khi các hệ thống bên ngoài được các bên thứ ba cung cấp và chúng là mới đối với tổ chức, các phân tích từ dưới lên có thể đặt dấu hỏi đối với các khẳng định mức cao của bên thứ ba về tính tiếp cận được, tính trọn vẹn, và tính ổn định phiên bản của các API mà hệ thống của họ đưa ra.

Chú ý quan trọng:
Điều quan trọng là các rủi ro "ẩn số" này liên quan đến việc tích hợp với một hệ thống bên ngoài được giảm bớt trong giai đoạn Khởi đầu, trước khi ngân sách và các ràng buộc về thời gian cho dự án được thỏa thuận. Nếu không, có thể có một số điều bất ngờ đáng bực mình đợi sẵn!


Mô hình hoá hệ thống bên ngoài và các giao diện của chúng

Tạo một mô hình các hệ thống bên ngoài bằng Kiến trúc sư phần mềm Rational

Điểm khởi đầu ở đây là dự án hướng dẫn SOA là kết quả của Phần 2, trong đó có chứa mô hình miền của chúng ta. Hãy tải về tệp tin (từ phần Tải về ở đây) và sau đó làm theo các hướng dẫn để nhập khẩu dự án vào vùng làm việc của bạn.

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

  1. Khởi động bản Rational Software Architect. Sử dụng vùng làm việc mặc định hoặc tạo một vùng mới.
  2. Sau khi Kiến trúc sư phần mềm Rational đã 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 Import wizard, gõ project vào trong trường 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
Nhập khẩu bắt giữ màn hình trao đổi dự án
  1. Nhấn vào Browse và trỏ đến vị trí nơi bạn đã lưu tệp tin DVD-Rental-DomainModel-RSA-ProjectInterchange.zip.
  2. Chọn SOA Tutorial và nhấn vào Finish (Hình 3).
Hình 3. Nhập khẩu dự án hướng dẫn SOA
Nhập khẩu bắt giữ màn hình dự án hướng dẫn SOA
  1. Chọn Window > Open Perspective > Modeling để chuyển sang phối cảnh Modeling.
  2. Mở rộng SOA Tutorial > Models và nhấn đúp chuột vào Domain Model để mở nó. Nhấn OK, nếu được nhắc nhở rằng các mô hình tham chiếu không có sẵn.
  3. Bạn sẽ thấy có gì đó 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 khung nhìn Project Explorer đầu tiên

Chúng ta sẽ sử dụng một phần mô hình thiết kế của chúng ta làm mô hình hệ thống bên ngoài của chúng ta. Vì vậy, để bắt đầu, bạn cần phải tạo ra một mô hình UML mới của mô hình thiết kế.

  1. Chọn dự án SOA Tutorial. Nhấn chuột phải vào nó và sau đó nhấn vào New > UML Model.
  2. Từ hộp thoại New UML Model, để nguyên Standard template đã đánh dấu chọn và nhấn vào Next.
  3. Nhập tên tệp tin là Design Model và bỏ chọn Create a default diagram trong mô hình.
  4. Nhấn Finish.

Bây giờ bạn sẽ có một mô hình thiết kế rỗng trong dự án hướng dẫn SOA của bạn.

  1. Chọn Design Model, nhấn chuột phải vào nó và sau đó nhấn vào Add UML > Package.
  2. Đặt tên nó là External Systems.
  3. Nhấn chuột phải trên nó để xoá Main diagram trong gói này và sau đó nhấn chuột vào Delete from Model. Điều này dẫn đến một mô hình mới, như được hiển thị trong Hình 5.
Hình 5. Gói các hệ thống bên ngoài mới (trong mô hình thiết kế)
Bắt giữ màn hình của gói các hệ thống bên ngoài mới

Nhận biết các hệ thống bên ngoài

Bây giờ chúng ta cần phải hiểu các hệ thống bên ngoài nào sẽ là một phần của giải pháp của chúng ta. Khi mô hình hóa quá trình nghiệp vụ trả lại băng Video, chúng ta đã lưu ý rằng tác vụ tự động lấy ra vị thế của thành viên cần phải được thực hiện bằng cách tích hợp với một hệ thống Quản lý Quan hệ Khách hàng (CRM) hiện có. Giả sử rằng cuộc thảo luận với các chủ sở hữu quy trình nghiệp vụ kinh doanh đã dẫn đến việc bạn được tiếp xúc với một nhà phát triển lâu năm, người chịu trách nhiệm về hệ thống CRM. Ông ta đã cho bạn các thông tin sau:

  • Hệ thống này là một gói phần mềm bán lẻ đã được mua từ một nhà cung cấp CRM nhỏ trong vài năm trước đây.
  • Các phần mềm chạy trên một nền tảng .NET nhưng nó có đưa ra một API các dịch vụ Web.
  • Có các ghi chú trong một tài liệu PDF được gọi là "Tích hợp với API của hệ thống CRM" được cung cấp kèm với phần mềm. Nó mô tả các khuôn dạng của API các dịch vụ Web, cùng với các hướng dẫn về cách thức gọi nó.

Điều này là tốt, vì cần có đủ thông tin trong tài liệu PDF để điền vào mô hình các hệ thống bên ngoài của chúng ta. Tuy nhiên, vẫn còn nhiều thứ phải xem xét.

  1. Tạo một gói phần mềm mới ở trong External Systems dành cho hệ thống Quản lý Quan hệ Khách hàng của chúng ta. Gọi nó là CustomerRelationshipMgt.
  2. Nhấn chuột phải vào gói trong khung nhìn Project Explorer và chọn Add UML > Subsystem. Đặt tên nó cũng là CustomerRelationshipMgt. (Hãy chắc chắn rằng bạn giữ bản mẫu <<subsystem>> khi bạn đổi tên nó).
  3. Đổi tên sơ đồ mặc định đã được tạo ra trong gói thành CustomerRelationshipMgt ExternalSystemSpec.
  4. Hãy chắc chắn rằng sơ đồ đã mở và kéo hệ thống con mới lên trên nó.

Kết quả của tất cả những điều này được hiển thị trong Hình 6.

Hình 6. Hệ thống bên ngoài CustomerRelationshipMgt
Bắt giữ màn hình của hệ thống bên ngoài CustomerRelationshipMgt

Bây giờ chúng ta đã sẵn sàng để mô hình hóa hệ thống bên ngòai của chúng ta.

Nhận biết các giao diện được cung cấp

Khi đọc tài liệu "Tích hợp với API của hệ thống CRM", chúng ta thấy rằng rằng hệ thống có một số API dựa trên dịch vụ Web, mỗi một trong số các API trưng ra một tập chức năng khác nhau liên quan đến CRM. Tuy nhiên, chúng ta cũng tìm thấy một API cụ thể có tên là gọi là API Các chức năng Khách hàng (Customer Functions API) cho phép truy cập vào thông tin CRM mà chúng ta cần. Thay vì tạo mô hình cho tất cả các API được trình bày, chúng ta sẽ chỉ tập trung vào việc tạo mô hình API mà chúng ta yêu cầu. Dựa vào thông tin trong tài liệu, chúng ta tạo ra một giao diện cho API này trong mô hình của chúng ta:

  1. Tạo một gói trong gói CustomerRelationshipMgt. Đặt tên nó là Provided Interfaces và xóa sơ đồ mặc định.
  2. Tạo một gói dưới gói Provided Interfaces. Đặt tên nó là CustomerFunctionsAPI. Đổi tên sơ đồ mặc định thành CustomerFunctionsAPI InterfaceSpec.
  3. Nhấn chuột phải vào gói CustomerFunctionsAPI và sau đó chọn Add UML > Interface. Đặt tên nó là CustomerFunctionsAPI.
  4. Sơ đồ CustomerFunctionsAPI InterfaceSpec sẽ mở ra. Kéo giao diện mới lên trên nó.

Sơ đồ sẽ xuất hiện như trong Hình 7.

Hình 7. Sơ đồ CustomerFunctionsAPI InterfaceSpec
Sơ đồ CustomerFunctionsAPI InterfaceSpec

Chúng ta sẽ xem xét chi tiết giao diện này sau (lưu ý rằng, đối với hệ thống này chúng ta chỉ có một giao diện cung cấp ra --- không có giao diện yêu cầu vào). Bây giờ chúng ta sẽ liên kết nó vào đặc tả kỹ thuật của hệ thống bên ngoài:

  1. Mở sơ đồ CustomerRelationshipMgt ExternalSystemSpec.
  2. Chọn giao diện CustomerFunctionsAPI trong khung nhìn Project Explorer và kéo nó lên trên sơ đồ mà chúng ta vừa mới mở.
  3. Từ Palette, tìm mục Realization ở dưới phần Class. Nhấn vào nó và sau đó nhấn vào hệ thống con CustomerRelationshipMgt trên sơ đồ và kéo một realization tới CustomerFunctionsAPI vừa mới được đặt trên sơ đồ.

Sơ đồ bây giờ trông giống như Hình 8.

Hình 8. Sơ đồ CustomerRelationshipMgt ExternalSystemSpec
Sơ đồ CustomerRelationshipMgt ExternalSystemSpec

Chúng ta sẽ thay đổi cách sơ đồ này xuất hiện ngay bây giờ và thêm vào một liên kết đến sơ đồ đặc tả kỹ thuật của giao diện:

  1. Nhấn chuột phải vào CustomerRelationshipMgt, Filters > Show External View.

Khung nhìn bên ngoài hiển thị giao diện được cung cấp, sử dụng cái thường được gọi là ký hiệu biển tròn (hay lollypop), vì hình tượng của nó.

  1. Để loại bỏ CustomerFunctionsAPI khỏi sơ đồ, nhấn chuột phải vào nó trong sơ đồ và chọn Delete from diagram.
  2. Chọn sơ đồ CustomerFunctionsAPI InterfaceSpec từ khung nhìn Project Explorer. Kéo nó lên trên sơ đồ CustomerRelationshipMgt ExternalSystemSpec Kéo nó lên trên sơ đồ

Mẹo:
Thêm các biểu tượng sơ đồ làm cho mô hình dễ dàng dẫn hướng hơn. Điều này đặc biệt có ích khi mô hình được công bố theo định dạng HTML.

  1. Nhấn vào Note Attachment trong Palette (xem Hình 9) và kéo một tệp tin ghi chú đính kèm giữa một biểu tượng của sơ đồ mới mà chúng ta đã tạo ra và biểu tượng biển tròn thể hiện CustomerFunctionsAPI trên hệ thống con CustomerRelationshipMgt.
Hình 9. Tạo ra một tệp tin ghi chú đính kèm
Tạo ra một tệp tin ghi chú đính kèm

Sơ đồ bây giờ xuất hiện như trong hình 10.

Hình 10. Sơ đồ CustomerRelationshipMgt ExternalSystemSpec đã hoàn tất
Sơ đồ CustomerRelationshipMgt ExternalSystemSpec đã hoàn tất

Mô hình hóa thông tin hệ thống bên ngoài và các giao diện

Như chúng ta đã tìm hiểu trước đó trong phần 2, mô hình miền của chúng ta cung cấp một khung nhìn có cấu trúc về các thông tin có trong miền nghiệp vụ kinh doanh. Điều này là vô cùng có lợi khi giao tiếp nội bộ bên trong hệ thống CNTT, cũng như khi hệ thống CNTT cần cần giao tiếp về nghiệp vụ kinh doanh. Tuy nhiên điều quan trọng cần lưu ý là mặc dù mô hình miền sẽ ảnh hưởng đến hình thức của giải pháp phần mềm, nhưng nó không ảnh hưởng trực tiếp đến mô hình hóa phần mềm.

Tuy nhiên, thật có ích khi có một khung nhìn kiểu mô hình miền về các thông tin được một hệ thống cụ thể quản lý. Thay vì cấu trúc các giới hạn ngữ nghĩa (các kiểu miền) được dùng trong nghiệp vụ kinh doanh, nó sẽ cấu trúc các giới hạn ngữ nghĩa được các giao diện (cung cấp ra và yêu cầu vào) của hệ thống bên ngoài sử dụng. Nó sẽ đặc biệt tập trung vào những kiểu nào được hệ thống bên ngoài lưu trữ và quản lý.

Khung nhìn kiểu mô hình miền này được gọi là một mô hình thông tin. Chúng ta tạo ra một mô hình thông tin cho mỗi hệ thống bên ngoài vẫn còn lưu một số thông tin (hầu hết các hệ thống đều thế). (Chúng ta cũng có thể sử dụng các mô hình thông tin trong mô hình dịch vụ của chúng ta – trong phần sau của loạt bài này sẽ nói nhiều hơn).

Tạo mô hình khung nhìn thông tin

Một mô hình thông tin trông rất giống như một mô hình miền. Sự khác biệt chính là ở chỗ mô hình này chứa các kiểu thông tin (info types) chứ không phải là các kiểu miền. Về nhiều khía cạnh, một kiểu thông tin trông giống hệt như một kiểu miền. Sự khác biệt chỉ là một kiểu thông tin mô tả một kiểu cấu trúc thông tin có trong một miền phần mềm (hệ thống bên ngoài hoặc một phần kiến trúc); trong khi đó, một kiểu miền mô tả một kiểu thông tin có cấu trúc tồn tại trong một miền nghiệp vụ kinh doanh.

Xem lại tài liệu "Tích hợp với API của hệ thống CRM" một lần nữa, chúng ta phát hiện ra rằng các kiểu thông tin được lưu trữ bởi hệ thống Quản lý Quan hệ Khách hàng có liên quan đến API Chức năng Khách hàng là khách hàng và loại khách hàng. Chúng ta cũng lưu ý một mô tả về các thuộc tính của cả hai kiểu thông tin này và cũng lưu ý rằng một khách hàng liên quan đến chỉ một loại khách hàng.

Hãy thêm thông tin này vào mô hình của chúng ta.

  1. Tạo một gói mới trong gói CustomerRelationshipMgt. Đặt tên nó là Info Types.
  2. Xoá sơ đồ mặc định và tạo ra một sơ đồ lớp mới. Đặt tên nó là CustomerRelationshipMgt InfoTypes.
  3. Tạo ra các phần tử mô hình sau đây:
  • Một <<infoType>> Customer Class có các thuộc tính sau:
    • customerId: String
    • name: String
    • address: String
    • telephoneNumber: String [0..1]
  • Một <<infoType>> CustomerCategory có tên là String attribute
  • Một quan hệ kết hợp * đến [0..1] giữa Customer CustomerCategory

Kết quả được hiển thị trong Hình 11.

Nếu bạn cần trợ giúp để làm điều này, hãy xem Phần 2. Mô hình hóa miền nghiệp vụ, về việc tạo mô hình miền. Lưu ý rằng <<infoType>> là một từ khóa.

Hình 11. Sơ đồ CustomerRelationshipMgt InfoTypes
Sơ đồ CustomerRelationshipMgt InfoTypes

Giống như với một mô hình miền, một mô hình thông tin có thể có các bảng kê và các ràng buộc, mặc dù chúng ta đã không tạo bất cứ cái nào trong ví dụ này.

Cuối cùng điều mà chúng ta sẽ làm với mô hình thông tin của chúng ta là thêm một biểu tượng sơ đồ cho sơ đồ CustomerRelationshipMgt ExternalSystemSpec của chúng ta (xem Hình 12).

Hình 12. Thêm một biểu tượng sơ đồ cho mô hình thông tin
Thêm một biểu tượng sơ đồ cho mô hình thông tin

Chi tiết hóa các giao diện

Những gì mà chúng ta đã tạo mô hình trong tiểu mục trên là đại diện cho các thông tin vẫn còn được tiếp tục duy trì bởi hệ thống bên ngoài. Chúng ta cũng cần phải thêm da thịt cho đặc tả kỹ thuật các giao diện mà chúng ta đã tạo ra trước đó. Chúng ta làm điều này bằng cách chi tiết hóa các hoạt động hiện có trên giao diện. Dấu hiệu đặc trưng (signature) của một hoạt động được biểu diễn qua các tham số và không bắt buộc, qua một kiểu trả về. các tham số này dựa vào một dạng kiểu khác: kiểu tham số. Hãy xem xét một ví dụ.

Lại xem tài liệu "Tích hợp với API của hệ thống CRM" một lần nữa, chúng ta tìm thấy một mô tả về các hoạt động mà dịch vụ Web cung cấp. Chúng ta sẽ thêm các thông tin này vào mô hình của chúng ta.

  1. Mở sơ đồ CustomerFunctionsAPI InterfaceSpec.
  2. Nhấn chuột phải vào CustomerFunctionsAPI Add UML > Operation. Đặt tên nó là retrieveCustomer.

Trước tiên hãy xem xét các tham số của hoạt động.

  1. Nhấn vào hoạt động retrieveCustomer.
  2. Trong phần Parameters của khung nhìn Properties, nhấn chuột phải vào danh sách rỗng Insert New Parameter (Hình 13).
Hình 13. Chèn tham số mới
Bắt giữ màn hình chèn tham số mới
  1. Đổi Name thành customerId và đặt Type thành String.

Bây giờ chúng ta sẽ thay đổi sơ đồ để cho các thông tin này được hiển thị.

  1. Nhấn chuột phải vào CustomerFunctionsAPI trong sơ đồ và chọn Filters > Show Signature.

CustomerFunctionsAPI InterfaceSpec sẽ xuất hiện như trong hình 14.

Hình 14. Hoạt động retrieveCustomer với một tham số đã thêm vào
Bắt giữ màn hình các phần tử

Bây giờ chúng ta sẽ xác định kiểu trả về của hoạt động đó. Điều này sẽ cần phải dựa vào một kiểu tham số. Lưu ý rằng, trong ví dụ của chúng ta ở đây, chúng ta sử dụng một kiểu tham số cho kiểu trả về. Tuy nhiên, các tham số có thể được mô tả bằng các kiểu tham số ở mọi nơi cần thiết.

  1. Tạo một gói mới trong gói CustomerRelationshipMgt và đặt tên nó là Parameter Types.
  2. Đổi tên sơ đồ mặc định thành CustomerRelationshipMgt ParameterTypes.
  3. Tạo một lớp mới có tên là Customer và thêm từ khoá parameterType vào nó.
  4. Thêm các thuộc tính như được hiển thị phía dưới trong Hình 15.
Hình 15. Gói các kiểu tham số mới
Bắt giữ màn hình gói các kiểu tham số mới của các phần tử
  1. Mở sơ đồ CustomerFunctionsAPI InterfaceSpec.
  2. Kéo kiểu tham số Customer lên trên sơ đồ.
  3. Chọn hoạt động retrieveCustomer.
  4. Trong phần General của khung nhìn Properties, hãy nhấn vào Set return type.
  5. Đặt kiểu trả về thành Customer, do đó đảm bảo rằng bạn chọn kiểu tham số Customer thuộc sở hữu của hệ thống bên ngoài CustomerRelationshipMgt.

Sơ đồ bây giờ xuất hiện như trong Hình16.

Hình 16. Hoạt động retrieveCustomer với kiểu trả về đã định nghĩa
Hoạt động retrieveCustomer với kiểu trả về đã định nghĩa

Bây giờ chúng ta đã đạt đến điểm mà tại đây ta có một khung nhìn cụ thể về hệ thống bên ngoài mà chúng ta cần phải tích hợp (dù chỉ là một ví dụ hết sức đơn giản cho hướng dẫn này). Chúng ta có một khung nhìn chắc chắn về giao diện mà chúng ta sẽ tích hợp trông như thế nào và chúng ta cũng hiểu những thông tin mà chúng ta đang sử dụng từ hệ thống là gì và nó được cấu trúc như thế nào. Mặc dù đây chỉ là một ví dụ đơn giản, cũng những nguyên tắc ấy sẽ đóng vai trò thiết yếu khi giải quyết các hệ thống bên ngoài lớn hơn và quản lý độ phức tạp của chúng.


Phần tiếp theo có gì

Trong phần này của loạt hướng dẫn, chúng ta xem xét đoạn đường từ dưới lên của cách tiếp cận "gặp ở giữa chừng" và cụ thể hơn là các hệ thống bên ngoài không phải-SOA là trọng tâm xem xét. 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 đó chúng ta xem xét một cách chi tiết cách làm thế nào để tạo ra một mô hình hệ thống bên ngoài bằng cách sử dụng Kiến trúc sư phần mềm Rational. Cụ thể hơn, chúng ta xem xét việc mô hình hóa các giao diện cung cấp ra và các mô hình thông tin. Trong các phần tiếp theo của loạt bài này, chúng ta sẽ đi vào phần cốt lõi của việc tạo mô hình SOA: Tạo mô hình dịch vụ.


Các tải về

Mô tảTênKích thước
projectDVD-Rental-DomainModel-RSA-ProjectInterchange.zip9KB
projectDVD_Rental-ExternalSystemModeling-RSA-ProjectInterchange.zip13KB

Tài nguyên

Học tập

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

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Rational, SOA và dịch vụ Web
ArticleID=385653
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: Tạo mô hình của hệ thống bên ngoài
publish-date=05202009