Thiết kế các dịch vụ SOA với Rational Software Architect, Phần 1: Khởi đầu bằng các yêu cầu, quy trình và mô hình hóa

Trong hướng dẫn này, Phần 1 của một loạt bài viết, bạn sẽ tìm hiểu về mối quan hệ giữa một bộ các công cụ trong IBM Rational Software Development Platform (Nền tảng phát triển phần mềm Rational của IBM) mà bạn sẽ sử dụng khi bạn thiết kế một dịch vụ dựa trên - SOA bằng cách sử dụng MDD. Bạn sẽ thấy làm thế nào để truy cập vào các yêu cầu từ nhiều nguồn khác nhau, sử dụng một quá trình phát triển phần mềm có tùy chỉnh và sau đó bắt đầu mô hình hóa một thiết kế cho các dịch vụ cần thiết. Các công cụ được sử dụng bao gồm IBM® Rational® Software Architect (Kiến trúc sư phần mềm Rational của IBM), IBM® Rational® Software Modeler (Trình mô hình hóa phần mềm Rational của IBM), IBM® WebShpere® Business Modeler (Trình mô hình hóa nghiệp vụ WebShpere của IBM), IBM® Rational® RequisitePro® và phương pháp luận của IBM® Rational Unified Process® (RUP®-Quy trình thống nhất Rational của IBM).

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



07 08 2009

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

Hãy tìm hiểu có thể mong đợi những gì từ hướng dẫn này và làm thế nào để học được nhiều nhất từ nó.

Về loạt bài viết này

Để thu được những lợi ích của Service-Oriented Architecture (SOA - Kiến trúc hướng-dịch vụ) và Model-Driven Development (MDD- Phát triển dựa theo mô hình), môi trường thiết kế và phát triển của bạn cần có các đặc điểm sau:

  • Cách làm thực tế tốt nhất: mọi người sẽ có thể sử dụng lại các giải pháp đã được kiểm chứng để giải quyết các vấn đề xảy ra nhiều lần và cũng cung cấp các giải pháp cho những người khác sử dụng lại.
  • Dựa trên vai trò: Các công cụ cần được nhắm đến nhiệm vụ sắp tới và đến vai trò thực hiện nhiệm vụ đó (ví dụ, nhà phân tích nghiệp vụ hoặc Kiến trúc sư CNTT).
  • Hỗ trợ và hướng dẫn quy trình xử lý: Nên luôn luôn có phương pháp hoặc hướng dẫn quy trình xử lý theo bối cảnh.
  • Nền tảng mở rộng được: Các nhóm sẽ có thể mở rộng hoặc tùy chỉnh môi trường sao cho nó ăn khớp với các nhu cầu của họ.
  • Cho phép tự động hóa: Các ánh xạ và siêu mô hình bên dưới khung công tác sẽ cho phép chuyển đổi bán tự động các mô hình, từ các mức trừu tượng hóa cao hơn đến thấp hơn và cuối cùng thành mã có thể chạy được. Ngoài ra, nó có khả năng truy ngược lại từ các mức trừu tượng hóa thấp hơn đến cao hơn.

Tất cả danh sách đã liệt kê ở trên là các đặc tính của IBM Rational Software Development Platform (Nền phát triển phần mềm Rational IBM) và cụ thể hơn là của IBM Rational Software Architect (Kiến trúc sư phần mềm Ratonal IBM). Trong loạt bài viết của hướng dẫn này, bạn sẽ tìm hiểu làm thế nào để sử dụng nền tảng đó và các khả năng của nó để thiết kế các giải pháp SOA.

Chúng tôi mô tả một cách tiếp cận MDD từ trên xuống dưới để mô hình hóa các dịch vụ bằng cách sử dụng Rational Software Architect. Chúng tôi cũng chỉ ra các mô hình dịch vụ có thể được mô tả theo các mức trừu tượng hóa khác nhau như thế nào, từ Business Process (Quy trình nghiệp vụ), Unified Modeling Language (UML - Ngôn ngữ mô hình hóa thống nhất), Web Services Description Language (WSDL - Ngôn ngữ mô tả dịch vụ Web), đến mã lệnh Java™ và làm thế nào để Rational Software Architect hỗ trợ hiển thị trực quan và chuyển đổi từ một mức trừu tượng hóa này tới mức trừu tượng hóa khác.

Ngoài ra, chúng tôi thảo luận về việc sử dụng các lược tả UML (UML profiles) cho các ngôn ngữ đặc thù miền như Hướng-dịch vụ. Chìa khóa để thu được các lợi ích của SOA là việc tái sử dụng các tài sản hiện có. Chúng tôi chỉ ra cách làm thế nào để sử dụng các mẫu thiết kế hiện có để giải quyết các yêu cầu về các dịch vụ của bạn. Sau khi tìm hiểu hết loạt bài viết này, bạn sẽ có khả năng thiết kế các dịch vụ bằng Rational Software Architect và sử dụng các khả năng bạn được cung cấp xoay quanh các lược tả UML, các mẫu thiết kế, các tài sản có khả năng sử dụng lại, các phép chuyển đổi và các dịch vụ web.

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

Trong hướng dẫn này, Phần 1 của loạt bài viết, chúng tôi bắt đầu bằng cách đưa ra một cái nhìn tổng quan về dòng chảy công việc sẽ được trình bày thông qua loạt bài viết này. Sau đó chúng tôi sẽ giới thiệu những công cụ được sử dụng, chủ yếu là Rational Software Architect, nhưng cũng có cả IBM WebSphere® Business Modeler và IBM Rational Requisite Pro. Chúng tôi cũng sẽ xem xét cách thức chúng ta có thể sử dụng IBM Rational Unified Process® (RUP®-Quy trình thống nhất Rational) để hướng dẫn cho chúng ta trải qua việc thiết kế. Sau đó, chúng ta sẽ trải qua các giai đoạn đầu tiên của dòng chảy công việc, xem xét các quy trình nghiệp vụ như đã chỉ rõ trong WebSphere Business Modeler (Trình mô hình hóa nghiệp vụ WebSphere), tùy chỉnh quy trình sẽ được sử dụng, kết nối công việc của chúng ta với các yêu cầu từ RequisitePro và cũng khởi đầu bằng cách sử dụng Rational Software Architect.

Các mục tiêu

Sau khi hoàn tất hướng dẫn này, bạn sẽ có hiểu biết tốt hơn về cách:

  • Các quy trình nghiệp vụ được biểu diễn trong WebSphere Business Modeler như thế nào.
  • Thông tin về quy trình nghiệp vụ từ WebSphere Business Modeler có thể được truy cập từ bên trong Rational Software Architect như thế nào.
  • Nội dung của quá trình phát triển phần mềm có tùy chỉnh có thể được truy cập từ bên trong Rational Software Architect như thế nào.
  • Các yêu cầu, khi được bắt giữ trong RequisitePro, có thể được truy cập từ bên trong Rational Software Architect như thế nào.

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

Để tiếp thu được những giá trị tốt nhất của hướng dẫn này, bạn không nhất thiết phải nhưng rất nên quen thuộc với:

  • UML, Unified Modeling Language (Ngôn ngữ mô hình hóa thống nhất).
  • Rational Software Architect hay IBM Rational Software Modeler.
  • SOA, Service-Oriented Architecture.
  • WebSphere Business Modeler.

Tham khảo phần Tài nguyên để có được các đường liên kết có ích đến các chủ đề này.


Phần mở đầu về hướng dẫn này

Bối cảnh

Nền tảng SOA

Các công cụ và các kỹ thuật mà chúng ta sẽ sử dụng trong loạt bài viết này tất cả nằm trong Nền tảng SOA (SOA Foundation) của IBM.

"Nền tảng SOA của IBM là một bộ phần mềm của IBM dựa trên các tiêu chuẩn mở, tích hợp chặt chẽ, các cách làm thực tế tốt nhất, các mẫu được thiết kế để cung cấp những gì bạn cần để khởi đầu với SOA từ một phối cảnh kiến trúc. Các phần tử chủ chốt của Nền tảng SOA của IBM là vòng đời SOA (mô hình, lắp ráp, triển khai, quản lý), kiến trúc tham khảo và các kịch bản SOA".

Vòng đời SOA được mô tả trong Hình 1, trong đó chỉ ra các giai đoạn then chốt được áp dụng cho tất cả các dự án SOA.

Hình 1. Nền tảng SOA
Nền tảng

Loạt bài viết này chủ yếu tập trung vào giai đoạn Mô hình hóa của Nền tảng SOA của IBM. Chúng ta đang quan tâm đến việc xác định nhu cầu của hoạt động kinh doanh, tối ưu hóa các quy trình xử lý cần được hỗ trợ bởi công việc kinh doanh và sau đó thiết kế một giải pháp để thực hiện các định nghĩa quy trình và đáp ứng các yêu cầu chất lượng dịch vụ (QoS). Khi doanh nghiệp và đối tác kinh doanh của bạn tiến xa hơn nữa trên con đường SOA, sẽ có một bộ các dịch vụ có sẵn, chỉ cần phải hòa phối chúng lại với nhau. Tuy nhiên, hướng dẫn này vẫn sẽ tập trung vào kịch bản ở đó các dịch vụ cần phải hoàn thành các quy trình nghiệp vụ hãy còn chưa có.

Kiến trúc ứng dụng bảo hiểm của IBM

Loạt hướng dẫn này sử dụng một mô hình mẫu từ các mô hình công nghiệp IBM, đó là IBM Industry Models Insurance Application Architecture (Kiến trúc ứng dụng bảo hiểm - IAA của các mô hình công nghiệp IBM). Như đã được nêu rõ trong Tổng quan của IAA:

" Insurance Application Architecture (IAA - Kiến trúc ứng dụng bảo hiểm) là một bộ đầy đủ các mô hình đặc thù bảo hiểm, mô tả các cách làm thực tiễn tốt nhất trong bảo hiểm và là một phần mở rộng tự nhiên của Component Business Model (Mô hình nghiệp vụ thành phần). Các mô hình IAA cung cấp nội dung nghiệp vụ đặc thù bảo hiểm để đẩy nhanh các dự án là kết quả từ việc chuyển biến thành một hoạt động kinh doanh theo yêu cầu và lấy ra định nghĩa của các thành phần sẽ dẫn bạn đến đó.[LA1]"

IBM đã dành nhiều năm làm việc với ngành công nghiệp bảo hiểm để xây dựng lên một bộ các mô hình và trang bị các công cụ có tác động như một bộ tăng tốc cho việc thiết kế và kiến trúc logic để xây dựng chức năng mới.

Lưu ý:IAA Poster cung cấp một tổng quan về tài sản.

Vài điều cần lưu ý về mẫu này:

  • Mô hình mà chúng ta đang làm việc với nó là một bản trình diễn về IAA, một tập con rất nhỏ của những gì đang có sẵn trong IAA.
  • Mặc dù loạt bài viết này làm việc dựa trên ngành công nghiệp bảo hiểm, các bước phải theo, các công cụ thường dùng và các hướng dẫn đã cung cấp là cũng có giá trị trên toàn bộ phạm vi các ngành công nghiệp.

Các chỉ dẫn trỏ đến nhiều thông tin hơn về IAA có thể được tìm thấy trong phần Tài nguyên của hướng dẫn này.

Các mục tiêu của loạt các bài viết

Thông qua loạt các bài hướng dẫn này, chúng tôi sẽ chỉ cho bạn thấy bộ công cụ của IBM có thể được sử dụng để thiết kế các dịch vụ trong một giải pháp SOA như thế nào. Sau khi hoàn thành loạt bài này, bạn sẽ có khả năng:

  • Truy cập thông tin từ WebSphere Business Modeler trong Rational Software Architect dẫn tới một đặc tả kỹ thuật về các dịch vụ kinh doanh sẽ được thực hiện như thế nào.
  • Sử dụng Rational Software Architect để tạo ra các mô hình thiết kế dịch vụ bằng cách sử dụng UML.
  • Truy cập và bám sát các yêu cầu từ Rational Software Architect.
  • Sử dụng các bản mẫu và các phép chuyển đổi để tự động hóa việc tạo ra một đặc tả dịch vụ.
  • Xác định tác động của một sự thay đổi yêu cầu đối với một đặc tả dịch vụ.
  • Tái sử dụng Các tài sản hiện có được đóng gói như là đặc tả của Reusable Asset Specification (RAS - Đặc tả tài sản có khả năng sử dụng lại) trong Rational Software Architect.
  • Tạo ra các báo cáo từ các mô hình này.

Mô tả kịch bản

Hình 2 cung cấp toàn cảnh về các vai trò, các công cụ và các tạo phẩm (artifact) được tập hợp lại trong một dự án SOA. Trong loạt các bài viết này, chúng ta chủ yếu tập trung vào phía bên tay trái của sơ đồ.

Hình 2. Các vai trò, các công cụ chuyên biệt và các tạo phẩm cho SOA
Các tạo phẩm cho SOA

Như đã nêu ra trước đó, chúng ta đã đang sử dụng một bản trình diễn từ IAA, mà WebSphere Business Modeler đã nắm bắt được, làm điểm khởi đầu cho loạt bài viết này. Bạn có thể ánh xạ tạo phẩm này và công việc xung quanh nó vào phần phía trên bên tay trái của sơ đồ. Bạn có thể thấy rằng chính là một nhà phân tích đang thực hiện công việc tại điểm này, tập trung vào nghiệp vụ và các quy trình mà nghiệp vụ đó cần phải thực hiện. Chúng ta sẽ chỉ dành một khoảng thời gian ngắn xem xét tạo phẩm này, bởi vì trọng tâm của chúng ta là việc thiết kế và chuyển dịch một số các quy trình đã được nhận biết thành các dịch vụ.

Phần lớn trong loạt bài viết này sẽ tập trung vào phần phía dưới bên tay trái của sơ đồ. Hãy nhìn vào cách một kiến trúc sư và một nhà phát triển Java 2 Platform, Enterprise Edition (J2EE™ - Nền tảng Java 2, Ấn bản doanh nghiệp) có thể sử dụng Rational Software Architect như thế nào để thiết kế, tạo ra và thử nghiệm các dịch vụ dựa trên các yêu cầu được đưa ra.

Đồng thời dọc đường chúng ta sẽ xem xét làm thế nào để sử dụng các tài sản có khả năng sử dụng lại -- đặc biệt là các mẫu thiết kế -- như là một phần của thiết kế của chúng ta. Trong trường hợp này, chúng ta sẽ sử dụng các tài sản có khả năng sử dụng lại để đáp ứng các yêu cầu phi chức năng và liên kết quyết định đó quay trở lại các yêu cầu cho dự án.

Chúng ta sẽ gói ghém loạt các bài viết này với việc xem xét sâu hơn về các tài sản có khả năng sử dụng lại. Hướng dẫn cuối cùng trong loạt bài viết này sẽ xem xét các cơ hội khác để sử dụng các tài sản có khả năng sử dụng lại và làm thế nào để xây dựng chúng bằng Rational Software Architect.


Khởi đầu với Rational Software Architect

Tổng quan

Rational Software Architect là một công cụ then chốt mà chúng ta sẽ sử dụng trong cách tiếp cận từ trên xuống này để thiết kế dịch vụ. Nếu bạn là người mới bắt đầu với Rational Software Architect, phần tiếp sau đây sẽ giúp bạn thích nghi với môi trường này. Nếu bạn đã thành thạo với cách sử dụng cơ bản của Rational Software Architect, xin hãy tự nhiên chuyển tới phần kế tiếp, trình bày phương pháp luận RUP, Rational Software Architect và SOA.

Rational Software Architect là một công cụ mạnh mẽ và linh hoạt, có thể được sử dụng cho việc thiết kế và xây dựng các giải pháp SOA. Trong loạt bài viết này, chúng ta sẽ xem xét cách làm thế nào để có thể sử dụng Rational Software Architect để:

  • Thiết kế một dịch vụ.
  • Trao đổi thông tin các chi tiết của thiết kế với những người khác (cả bên trong nội bộ tổ chức lẫn giữa các tổ chức).
  • Sử dụng thiết kế để tạo ra các tạo phẩm mã lệnh, có thể được sử dụng trong việc thực hiện các dịch vụ cần thiết cho giải pháp SOA đang được xây dựng.

Eclipse

Một nơi thích hợp để bắt đầu tìm hiểu về Rational Software Architect là lưu ý rằng nó được xây dựng trên đỉnh của nền tảng Eclipse. Những người đã thành thạo với Eclipse ngay lập tức sẽ cảm thấy quen thuộc như ở nhà với các tương tác được Rational Software Architect cung cấp. Như được hiển thị trong Hình 3, sau đây, Rational Software Architect có một phối cảnh Mô hình hóa (Modeling perspective) để bạn sẽ sử dụng khi tạo ra thiết kế dịch vụ ban đầu.

Một phối cảnh chỉ đơn giản là một tập hợp các khung nhìn và các trình soạn thảo phục vụ cho một mục đích chuyên dùng phổ biến (trong trường hợp này, chuyên biệt vào trợ giúp tạo ra các mô hình dựa trên-UML). Trong Rational Software Architect, bạn cũng sẽ gặp các phối cảnh được đo cắt phù hợp cho việc phát triển Web, phát triển J2EE, các tài sản có khả năng sử dụng lại, làm việc với các yêu cầu, thử nghiệm và v.v. .

Trong phối cảnh Mô hình hóa, có một số các khung nhìn mà bạn có thể sử dụng khi bạn thiết kế đặc tả kỹ thuật:

  1. Trình thám hiểm mô hình (Model Explorer): Sử dụng trình thám hiểm mô hình này để quản lý các phần tử trong mô hình của bạn – những thứ như là các lớp, các thành phần, các giao diện, các gói phần mềm và các sơ đồ.
  2. Trình soạn thảo sơ đồ (Diagram Editor): Đây là nơi bạn có thể tạo và sửa đổi các sơ đồ UML.
  3. Phác thảo (Outline): Trong trường hợp ở nơi sơ đồ của bạn trở nên quá lớn để vừa với một màn hình trong trình soạn thảo sơ đồ, bạn có thể sử dụng khung nhìn Phác thảo (Outline) để có được một cái nhìn tổng quan về toàn bộ sơ đồ và để chuyển hướng tới các phần khác của sơ đồ.
  4. Các thuộc tính (Properties): Sử dụng khung nhìn này để thêm vào và xem xét lại các chi tiết liên quan đến các phần tử mô hình cụ thể. Điều này có thể bao gồm việc kết nối các phần tử của mô hình tới các lược tả, việc áp dụng các bản mẫu rập khuôn, việc chỉ rõ các kiểu thuộc tính và v.v..
Hình 3. Phối cảnh Mô hình hóa
Phối cảnh Mô hình hóa trong Rational Software Architect

Các mô hình UML

Khi làm việc với các mô hình UML, điều quan trọng là phải tập trung vào công việc của bạn với mức độ trừu tượng thích hợp. Khi bạn bắt đầu làm việc với thiết kế các dịch vụ, bạn sẽ tập trung vào cách làm thế nào để làm việc với và liên hệ đến các yêu cầu nghiệp vụ. Tại thời điểm này, sẽ không cần thiết phải dành nhiều thời gian để mô hình hóa các bộ mô tả triển khai và nhiều kết cấu Java mức thấp. Thay vào đó, tập trung vào các quy trình, các vai trò, các phần tử nghiệp vụ và v.v.

Khi bạn tiếp tục công việc của bạn và dự án tiến triển lên, bạn sẽ tạo thêm các mô hình bổ sung khi cần thiết để đạt đến một điểm mà ở đó bạn đã có đủ mức chi tiết. Không có một số lượng bắt buộc hay định trước của các mô hình sẽ cần phải được tạo ra.

Khi tạo các mô hình UML, bạn sẽ sử dụng các mô hình cho ba mục đích riêng biệt sau:

  • Thiết kế (Design): Tạo mô hình ở một mức trừu tượng hóa thích hợp sao cho nó cho phép bạn che dấu các chi tiết không cần thiết, cho phép bạn tập trung vào vấn đề. Điều này cho phép bạn suy nghĩ đầy đủ về giải pháp của bạn và đi đến các quyết định tối ưu.
  • Trao đổi thông tin (Communication): Như tục ngữ cổ có câu, "Một bức tranh có giá trị 1000 từ". Như vậy, bạn sẽ sử dụng các sơ đồ trong mô hình như một cách để trao đổi thông tin với các bên liên quan khác trong dự án. UML là một cách biểu diễn được sử dụng rộng rãi, tiêu chuẩn hóa và có thể cho phép bạn dễ dàng chia sẻ và trao đổi ý tưởng của bạn với những người khác.
  • Tạo ra (Generation): Việc tạo các mô hình và các sơ đồ trong Rational Software Architect là nhiều hơn nhiều so với việc chỉ tạo ra một "bức tranh đẹp". Chúng ta đã tạo ra một biểu diễn phong phú, có cấu trúc và có thể truy cập của giải pháp của chúng ta. Chúng ta có các API và trang bị công cụ cho phép chúng ta truy cập vào biểu diễn này và chuyển đổi nó thành các tài sản khác. Trong trường hợp cụ thể này, bạn sẽ xem xét cách làm thế nào để bạn có thể sử dụng các mô hình để sinh ra WSDL; nó sẽ là nền tảng để triển khai thực hiện các dịch vụ đã xác định rõ.

Nếu bạn muốn tìm hiểu thêm về Rational Software Architect, hãy xem các liên kết được cung cấp trong phần Tài nguyên .

Bây giờ chúng ta có một số nền tảng cơ bản về Rational Software Architect, hãy bắt đầu khám phá môi trường này.

Khám phá Rational Software Architect

Lưu ý: Nếu bạn còn chưa làm, chúng tôi khuyến khích bạn tải về và cài đặt một bản sao của Rational Software Architect. Một liên kết đến một phiên bản dùng thử được cung cấp trong phần Tài nguyên. Như một thói quen thực tiễn chung, khi bạn đã cài đặt sản phẩm hãy chắc chắn rằng bạn chạy IBM Rational Product Updater (trình cập nhật sản phẩm Rational của IBM) để đảm bảo rằng bạn đã cài đặt phiên bản hiện tại mới nhất. Hướng dẫn này được dựa trên việc sử dụng phiên bản 6.0.1.1 IresourcesFix 002.

Trong phần này, bạn sẽ khởi chạy Rational Software Architect và đặt cấu hình nó cho các vai trò sẽ được quan tâm cho hướng dẫn này. Các vai trò và các khả năng là một đặc tính của Rational Software Architect, cho phép bạn ra lệnh cho công cụ rằng các đặc tính nào bạn đang quan tâm sử dụng nhiều nhất. Như đã đề cập ở trên, Rational Software Architect chứa một danh sách rất dài các đặc tính.

Các vai trò và các khả năng cung cấp cho bạn một cơ chế để cân bằng sức mạnh và sự linh hoạt với sự đơn giản và dễ sử dụng. Nếu một vai trò hoặc khả năng bị tắt đi, thì Rational Software Architect sẽ ẩn các đặc tính có liên quan. Nếu bạn bắt đầu một quy trình cần các đặc tính đó, môi trường này sẽ nhắc nhở bạn trước khi bật chúng lên.

Bắt đầu bằng cách khởi chạy IBM Rational Software Architect:

  1. Bắt đầu từ trình đơn Start, chọn Start > Programs > IBM Rational > IBM Rational Software Architect v6.0 > Rational Software Architect.
  2. Nhấn vào OK trong trình khởi chạy vùng làm việc (Workspace) để chấp nhận vùng làm việc mặc định.
  3. Trong màn hình Chào mừng (Welcome), hãy nhấn vào biểu tượng Roles, được làm nổi bật trong Hình 4, sau đây.
Hình 4. Màn hình Welcome
Khung nhìn Java Beans
  1. Bảo đảm rằng những vai trò sau đây được phép:
    1. Trình mô hình hóa (Modeler).
    2. J2EE nâng cao (Advanced J2EE).
    3. Quản lý tài sản có khả năng sử dụng lại (Reusable Asset Management).
    4. Quản lý yêu cầu (Requirement Management).

Một số vai trò, ví dụ như là như J2EE nâng cao, có các phụ thuộc ở các vai trò khác. Khi bạn cho phép một vai trò như vậy, nó cũng sẽ cho phép các vai trò khác theo sự phụ thuộc. Lưu ý rằng trong ảnh chụp màn hình được hiển thị trong Hình 5, bạn kết thúc với 7 vai trò được bật lên, dựa trên 4 vai trò mà bạn đã chọn.

Hình 5. Các vai trò được phép
Bảy vai trò được phép
  1. Để đi đến bàn làm việc (Workbench), khu vực chính được sử dụng cho công việc của bạn, hãy nhấn vào mũi tên trên đỉnh góc trên bên phải.

Phương pháp này sẽ dẫn đến việc duy trì màn hình chào mừng như là một cửa sổ riêng biệt trong Workbench. Bạn cũng có thể đóng màn hình chào mừng bằng cách nhấn vào X trên thẻ Welcome , thao tác này sẽ đưa bạn đến bàn làm việc.

Dựa trên các vai trò đã chọn, một số các khả năng đã được bật lên trong Rational Software Architect. Để kiểm tra các khả năng đã được cho phép bởi Các vai trò (Roles) mà bạn đã lựa chọn, thực hiện theo các bước sau:

  1. Trên trình đơn, chọn Windows > Preferences.
  2. Mở rộng Workbench và chọn Capabilities.
  3. Xem xét lại các khả năng.

Lưu ý rằng bất kỳ các khả năng nào khác cần thiết khi bạn tiếp tục hướng dẫn này đều có thể được bật lên khi cần đến chúng.

Tại thời điểm này, bạn đã khởi chạy Rational Software Architect, đã tạo ra một vùng làm việc sẽ được dùng để chứa các tạo phẩm có liên quan đến thiết kế của bạn và đã đặt cấu hình Rational Software Architect dành cho kiểu công việc mà bạn quan tâm thực hiện.

Khi bạn học theo hướng dẫn này, chúng ta sẽ tiếp tục khám phá Rational Software Architect và bộ đặc tính phong phú mà nó cung cấp. Tuy nhiên, thay vì chỉ cung cấp một danh sách dài các đặc tính, chúng ta sẽ thảo luận về các đặc tính đó khi chúng được sử dụng trong việc tạo ra thiết kế dịch vụ của bạn.


RUP, Rational Software Architect và SOA

Tổng quan về RUP

Khi xây dựng một giải pháp SOA, điều bắt buộc phải có là làm rõ đối với nhóm phát triển các trách nhiệm của họ là gì, các tạo phẩm và kết quả sẽ chuyển giao nào cần phải được tạo ra và các công cụ nào sẽ được sử dụng, cũng như làm thế nào để tất cả những điều này ánh xạ tương ứng tới các nhu cầu nghiệp vụ. Khi độ lớn của nhóm phát triển, độ lớn của giải pháp và độ phức tạp tổng thể của giải pháp tăng lên, càng ngày càng trở nên khó khăn để hướng dẫn một dự án tới chuyển giao thành công. Hướng dẫn này dùng khá nhiều thời gian để xem xét các công cụ, các tạo phẩm, công nghệ và các yêu cầu nghiệp vụ của một dự án.

Tuy nhiên, công việc đang được thực hiện không tồn tại trong chân không. Khi sử dụng bộ công cụ IBM, phương pháp luận RUP là một tài nguyên có giá trị sẵn có để bạn sử dụng. Việc sử dụng phương pháp luận RUP cho dự án của bạn có thể gia tăng đáng kể tỷ lệ đánh cược cho dự án SOA của bạn sẽ thành công.

Một khái niệm quan trọng cần nhớ về phương pháp luận RUP là ở chỗ nó là một khung công tác quy trình và không nhằm để trở thành một giải pháp kiểu một cỡ chung-vừa với-tất cả. Nó có thể đặt cấu hình và tùy chỉnh theo tổ chức và các dự án sắp tới. Tùy chỉnh này không chỉ là một quá trình một chiều, qua đó bạn lấy một tập con các cấu hình mặc định của RUP. Nội dung bên trong RUP có thể được tăng thêm bằng các trình cắm thêm (plug-in) tùy chỉnh được viết bởi IBM, tổ chức của bạn hay một bên thứ ba khác.

IBM Rational Method Composer (Trình soạn thảo phương thức Rational) là một sản phẩm đi kèm, được sử dụng để hỗ trợ bạn trong việc tạo ra một cấu hình RUP tùy chỉnh. Với Rational Method Composer, bạn có thể bắt đầu với nội dung do Rational của IBM cung cấp, tải về và thêm các trình cắm thêm nội dung hoặc soạn ra nội dung của riêng bạn -- dẫn đến việc sinh ra quy trình tùy chỉnh của riêng bạn. Để biết thêm thông tin về RUP và Rational Method Composer, xem phần Tài nguyên ở phần cuối hướng dẫn này.

Liên quan đến SOA, có hai trình cắm thêm đáng quan tâm:

  • Các trình cắm thêm RUP cho SOA.
  • Trình cắm thêm Rational Method Composer dành cho việc Cai quản SOA (SOA Governance).

Trình cắm thêm Rational Method Composer để cai quản SOA tăng thêm cấu hình RUP của bạn, hướng dẫn bạn cai quản thành công các triển khai thực hiện SOA của bạn:

"Phương pháp luận được cung cấp trong trình cắm thêm này là rất rộng lớn, bao trùm toàn bộ vòng đời cai quản SOA và nhiều quá trình chủ yếu khác. Sử dụng trình cắm thêm này để nhận biết các cách làm thực tiễn tốt nhất thích hợp, hòa nhập với các quy trình CNTT hiện tại của bạn, để mang lại sự cai quản đúng đắn các khả năng được SOA đưa vào thêm. Kết quả cuối cùng là một kế hoạch dự án để tạo ra khung công tác cai quản SOA duy nhất của tổ chức của bạn".

Để biết thêm chi tiết về cai quản SOA (SOA Governance), chúng tôi khuyên bạn xem xét Trình cắm thêm của Rational Method Composer để Cai quản SOA, cũng như các bài viết trong phần Tài nguyên.

Bài viết này sẽ tập trung chủ yếu vào Trình cắm thêm RUP cho SOA, trong đó cung cấp hướng dẫn quy trình về việc làm thế nào để xây dựng các giải pháp SOA, tập trung vào Phân tích dịch vụ (Nhận biết) và Thiết kế dịch vụ. Hướng dẫn này bao gồm phần bổ sung thêm của nội dung mới này, như được hiển thị trong Hình 6:

  • Chi tiết dòng chảy công việc.
  • Các hoạt động.
  • Các trang khái niệm.
  • Ví dụ từng bước một.
  • Các hướng dẫn.
  • Các trình cố vấn cho công cụ.
Hình 6. Nội dung được trình cắm thêm RUP bổ sung thêm cho SOA
Nội dung được trình cắm thêm RUP bổ sung thêm

Trình cắm thêm này cũng bao gồm Lược tả UML2 cho Các dịch vụ phần mềm. Bạn sẽ sử dụng lược tả này trong phần 2 của hướng dẫn này.

Tùy chỉnh và truy cập hướng dẫn quy trình trong Rational Software Architect

Sửa đổi Cấu hình quy trình

Rational Software Architect được gửi cho bạn với một cấu hình của RUP. Tuy nhiên, theo mặc định nó không bao gồm nội dung SOA. May mắn thay, bạn có thể chỉ rõ rằng Rational Software Architect sử dụng cấu hình tùy chỉnh để thay thế. Với hướng dẫn này, chúng tôi đã tạo ra một cấu hình RUP mới có bổ sung thêm Trình cắm thêm RUP cho SOA.

Trong phần này, chúng tôi sẽ chỉ ra cho bạn thấy làm thế nào để cập nhật Rational Software Architect để cho nó sử dụng cấu hình RUP mà chúng tôi đã xây dựng. Ngoài ra, chúng tôi sẽ cho bạn thấy các cách khác nhau để bạn có thể truy cập hướng dẫn RUP từ bên trong Rational Software Architect. Việc này tạo ra một kết nối rất chặt chẽ giữa cấu hình quy trình cho một tổ chức và bộ công cụ mà họ sử dụng để xây dựng các giải pháp.

Từ trong Rational Software Architect, bạn cần phải thực hiện theo các bước sau để truy cập vào các giá trị cài đặt RUP:

  1. Trên trình đơn Windows, nhấn vào Preferences.
  2. Chọn nút Process trong hộp thoại Preferences.
  3. Đảm bảo rằng đã đánh dấu chọn Advanced.
  4. Cấu hình các giá trị cài đặt Process Advisor Filter của bạn như được hiển thị trong Hình 7.
Hình 7. Các lựa chọn ưu tiên của quy trình
Các lựa chọn ưu tiên

Lưu ý: Bạn có thể sử dụng trường Location (Vị trí) để định rõ một cấu hình khác của RUP so với cấu hình Rational Software Architect đã gửi đến. Bạn có thể muốn làm điều này trong trường hợp ở nơi mà bạn đã tạo ra một cấu hình tùy chỉnh của RUP cho tổ chức của bạn, hoặc trong trường hợp mà bạn đã cài đặt trình cắm thêm RUP bổ sung.

Khi sử dụng Rational Method Composer, chúng ta đã xuất bản một cấu hình RUP tùy chỉnh bao gồm trình cắm thêm RUP cho SOA. Như một phần của quá trình xuất bản, chúng ta đã tạo ra một cấu hình RUP và lưu trữ nó vào một thư mục có tên là MyCustomRUPConfiguration. Vì vậy trong khi bạn đang ở trong hộp thoại Process preferences, bạn cần phải:

  1. Nhấn vào Browse sau đó chọn C: \ MyCustomRUPConfiguration, như được hiển thị trong Hình 8.
Hình 8. Duyệt tìm cấu hình RUP tuỳ chỉnh
cấu hình RUP tuỳ chỉnh
  1. Hoàn thành việc tuỳ chỉnh bằng cách nhấn chuột vào OK để chấp nhận cấu hình mới.
  2. Cuối cùng, nhấn OK lần nữa để chấp nhận các thay đổi đối với các lựa chọn ưu tiên.

Bây giờ bạn đã đặt cấu hình Rational Software Architect để sử dụng một cấu hình RUP tùy chỉnh. Tiếp theo chúng ta hãy xem xét làm thế nào để bạn có thể truy cập tới hướng dẫn này bên trong Rational Software Architect.

Lưu ý: Trình cắm thêm RUP cho SOA gửi đến cùng với bản Rational Method Composer. Nếu bạn đang sử dụng phiên bản 2003 của Rational Unified Process (Quy trình thống nhất Rational), bạn sẽ cần phải tải về Trình cắm thêm RUP cho SOA trước khi bạn có thể tạo một cấu hình tùy chỉnh như là một cấu hình mà chúng ta vừa mô tả. Một liên kết tới Trình cắm thêm này được cung cấp trong phần Tài nguyên.

Truy cập Hướng dẫn quy trình

Phần này sẽ thảo luận hai biện pháp chính mà bạn có thể truy cập nội dung RUP: Trình cố vấn quy trình (Process Advisor) và Trình duyệt quy trình (Process Browser).

Trình cố vấn quy trình

Trình cố vấn quy trình là một khung nhìn có thể được thêm vào một phối cảnh. Khung nhìn này theo dõi công việc mà bạn đang thực hiện trong Rational Software Architect và hiển thị nội dung RUP có liên quan tới nhiệm vụ sắp tới.

Để truy cập vào Trình cố vấn quy trình, thực hiện theo các bước sau.

  1. Chuyển sang phối cảnh mô hình hóa (Modeling).
  2. Thêm khung nhìn Trình cố vấn quy trình vào phối cảnh đó bằng cách chọn Window > Show View > Other.
  3. Mở rộng thư mục Process và nhấn vào Process Advisor
  4. Nhấn OK.

Lưu ý: Đầu tiên bạn tiến hành tìm kiếm, sẽ có một sự chậm trễ do nội dung RUP được lập chỉ mục.

Một khi bạn đã thêm khung nhìn này vào phối cảnh, bạn có thể bắt đầu cảm nhận được cách thức nội dung được hiển thị phụ thuộc vào công việc mà bạn đang làm như thế nào ở trong Rational Software Architect. Ví dụ, nếu bạn đang làm việc trên một sơ đồ ca sử dụng (Use Case), Process Advisor sẽ hiển thị nội dung có liên quan, như thấy trong Hình 9.

Hình 9. Nội dung có liên quan đến trường hợp sử dụng trong Process Advisor
Nội dung có liên quan đến trường hợp sử dụng trong Process Advisor

Khi bạn đang sử dụng một sản phẩm dựa trên Eclipse, bạn thấy sự linh hoạt cao trong dáng vẻ bên ngoài của môi trường làm việc. Bạn có thể tùy chỉnh sắp xếp các khung nhìn trong một phối cảnh để cho nó phù hợp với phong cách làm việc của bạn. Bạn cũng có thể tùy chỉnh cách bố trí của phối cảnh mô hình hóa (modeling perspective) như mong muốn bằng cách chọn tab Process Advisor và kéo nó tới một vị trí khác trên màn hình.

Một khi bạn có một cách bố trí mà bạn đang cảm thấy thoải mái với nó, bạn có thể lưu trữ các giá trị thiết lập để dùng cho lần sau khi bạn sử dụng Rational Software Architect, phối cảnh mô hình hóa được thiết lập theo tuỳ biến của bạn. Để làm được như vậy, hãy theo các bước sau:

  1. Đi đến trình đơn Window và chọn Save Perspective As.
  2. Ghi đè lên cách bố trí phối cảnh mô hình hóa mặc định bằng cách nhấn vào OK.

Trình duyệt quy trình

Một tùy chọn khác để truy cập nội dung RUP trong Software Architect (Kiến trúc sư phần mềm) là thông qua Trình duyệt quy trình (Process Browser). Trình duyệt quy trình là một cửa sổ đặc biệt, cho phép bạn chuyển hướng, tìm kiếm và xem nội dung RUP.

Để truy cập vào Trình duyệt quy trình, chọn Help > Process Browser. Trình duyệt quy trình xuất hiện như thấy trong hình 10.

Hình 10. Trình duyệt quy trình RUP
Trình duyệt quy trình

Như đã đề cập ở trên, bạn cũng có thể tìm kiếm nội dung được cung cấp trong Trình duyệt quy trình. Trong nhiều trường hợp, có khá nhiều nội dung trong cấu hình RUP mà bạn đang sử dụng. Nên cấu hình RUP để thu hẹp lại lượng tư liệu tham gia trong một truy vấn. Để làm như vậy, thực hiện theo các bước sau:

  1. Nhấn vào nút Scope.
  2. Thu hẹp lại phạm vi tìm kiếm bằng cách xóa Topics và rút bớt các kiểu nội dung, như được hiển thị trong Hình 11.
Hình 11. Chỉ rõ phạm vi tìm kiếm (Search Scope) của Trình duyệt quy trình RUP
Phạm vi tìm kiếm của Trình duyệt quy trình RUP
  1. Một khi bạn đã hoàn thành tuỳ chỉnh của mình, hãy nhấn vào OK để lưu các thay đổi.

Khi sử dụng cấu hình tuỳ chỉnh của bạn (trong đó có bao gồm Trình cắm thêm RUP cho SOA), bạn có thể thực hiện một việc tìm kiếm và xem nội dung có liên quan đến công việc mà bạn sắp làm trong hướng dẫn này.

  1. Trong Process Browser, gõ Service vào trường truy vấn và sau đó nhấn vào Search.
  2. Xem lại các kết quả tìm kiếm như được hiển thị trong Hình 12. Như bạn có thể thấy, bạn đã tìm thấy một trong những hoạt động đã được thêm vào cấu hình RUP tùy chỉnh này thông qua việc bao hàm Trình cắm thêm RUP cho SOA.
Hình 12. Các kết quả tìm kiếm của Trình duyệt quy trình
Các kết quả tìm kiếm

Xem lại các yêu cầu

Trong phần này, bạn sẽ tìm hiểu làm thế nào để truy cập vào các yêu cầu từ Rational Software Architect. Cụ thể là, bạn sẽ tìm hiểu làm thế nào để xem xét một dự án WebSphere Business Modeler (Trình mô hình hóa nghiệp vụ WebSphere) trong Rational Software Architect và làm thế nào để làm việc với các dự án đặc tả yêu cầu RequisitePro từ bên trong Rational Software Architect.

Lưu ý: Các liên kết đến phiên bản dùng thử của cả WebSphere Business Modeler lẫn RequisitePro được liệt kê trong phần Tài nguyên của hướng dẫn này.

Xem xét lại các yêu cầu trong WebSphere Business Modeler

Đối với ví dụ SOA này, chúng ta hãy giả thiết rằng có một số yêu cầu được mô tả dưới dạng các quy trình nghiệp vụ trong WebSphere Business Modeler (các quy trình nghiệp vụ TO-BE).

Rational Software Architect cho phép các Kiến trúc sư và các nhà phát triển J2EE xem xét một dự án WebSphere Business Modeler, do các nhà Phân tích tạo ra, như UML.

Khi một dự án WebSphere Business Modeler như vậy được mở ra, Rational Software Architect sẽ ánh xạ động các phần tử của quy trình nghiệp vụ tới các phần tử UML. Ví dụ, một vai trò (Role) của WebSphere Business Modeler được ánh xạ đến một tác nhân nghiệp vụ (Business Actor) UML. Một quy trình nghiệp vụ (Business Process) của WebSphere Business Modeler được ánh xạ đến cả Ca sử dụng nghiệp vụ (Business Use Case) (nhìn bên ngoài hộp đen) và một Hợp đồng thực hiện ca sử dụng nghiệp vụ (Business Use-Case Realization Contract) (nhìn bên trong hộp trắng).

Khung nhìn UML này của các phần tử WebSphere Business Modeler được gọi là một hợp đồng (contract) vì nó là cái mà những người kinh doanh đã tạo ra và cái mà những người làm công nghệ thông tin (CNTT) phải thiết kế và triển khai thực hiện tiếp. Nó chỉ cho phép đọc (không được phép thay đổi) đối với những người sử dụng Rational Software Architect vì đã quy định là CNTT không được sửa đổi hợp đồng do công việc kinh doanh bắt buộc..

Lưu ý: Nếu những người thiết kế CNTT muốn thực hiện một thay đổi cho mô hình nghiệp vụ, họ thông báo cho các nhà phân tích nghiệp vụ, những người thực hiện các sửa đổi với dự án WebSphere Business Modeler. Những người thiết kế Dịch vụ CNTT sau đó sẽ có thể xem thay đổi đó bằng thao tác làm mới mô hình.

Trước tiên, chúng ta hãy xem xét mô hình bên trong WebSphere Business Modeler. Là một kiến trúc sư hoặc nhà phát triển, chúng ta cần phải quen thuộc với WebSphere Business Modeler và có thể thảo luận các yêu cầu nghiệp vụ bằng cách sử dụng thuật ngữ và các công cụ mà doanh nghiệp thường hay sử dụng.

Xem dự án WebSphere Business Modeler

Bắt đầu bằng cách khởi động WebSphere Business Modeler v6.0.0 Advanced Edition (WebSphere Business Modeler v6.0.0 Ấn bản nâng cao). Để làm được như vậy, hãy làm theo các bước sau:

  1. Chọn Start > All Programs > WebSphere Business Modeler > WebSphere Business Modeler.
  2. Khi cửa sổ khởi chạy vùng làm việc (workspace) mở ra, nhấn vào OK để chấp nhận vị trí vùng làm việc mặc định.

Lưu ý: Nếu bạn không có một bản sao của WebSphere Business Modeler, một đường liên kết đến một phiên bản dùng thử được cung cấp trong phần Tài nguyên của hướng dẫn này. Mô hình WebSphere Business Modeler mà chúng ta sắp làm việc với nó hiện có sẵn để tải về từ phần Tải về của hướng dẫn này.

Sau đó, bạn sẽ cần phải nhập khẩu mô hình mẫu mà chúng ta sẽ sử dụng như là nền tảng cho hướng dẫn này.

  1. Chọn File > Import.
  2. Chọn WebSphere Business Modeler Import và nhấn vào Next.
  3. Chọn WebSphere Business Modeler XML (.xml) và sau đó nhấn vào Next.
  4. Nhấn vào Browse sau đó chỉ rõ thư mục nơi bạn lưu trữ tệp tin ClaimManagementDemoDesign.xml. Sau khi đã chỉ rõ, nhấn OK.
  5. Chọn ClaimManagementDemoDesign.xml.
  6. Nhấn vào New để tạo ra một Target Project (dự án đích) mới.
  7. Chỉ rõ ClaimManagementDemoDesign là tên dự án mới (New project name). Nhấn vào Finish.
  8. Nhấn vào Finish.
  9. Nhấn vào OK nếu có một thông báo cảnh báo xuất hiện.

Bây giờ bạn có mô hình như được tạo bởi nhà phân tích trong WebSphere Business Modeler, hãy khảo sát dự án này. Như một phần của cuộc khảo sát, bạn sẽ tìm thấy các quy trình sẽ được sử dụng như là một nền tảng hay các dịch vụ mà chúng ta sẽ thiết kế.

  1. Trong khung nhìn Project Tree (Cây dự án), mở rộng dự án.
  2. Chuyển hướng đến Processes > Claims Management > Claim Recording.
  3. Nhấn đúp chuột vào Record Claim (Ghi yêu sách) để mở sơ đồ Record Claim.
  4. Theo mặc định sơ đồ này sẽ xuất hiện như được hiển thị trong Hình 13.
Hình 13. Sơ đồ quy trình mặc định cho Record Claim
Sơ đồ quy trình mặc định

Hãy xem xét chi tiết hơn cách bạn sẽ làm việc với các thông tin cần thiết cho quy trình này như thế nào:

  1. Nhấn vào dấu + trên phần tử vòng lặp của Vòng lặp để hoàn tất thông tin (Loop for Information Complete).
  2. Sơ đồ được hiển thị trong Hình 14 sẽ xuất hiện.
Hình 14. Ghi yêu sách/Vòng lặp để hoàn tất thông tin
Ghi yêu sách/Vòng lặp

Ghi lại các chi tiết của yêu sách (Record Claim Details) và Xác nhận hợp lệ ghi yêu sách (Validate Claim Recording) đã được xác định như là các quy trình là các ứng viên tốt để tự động hóa. Khi bạn học theo loạt hướng dẫn này, công việc của bạn sẽ dựa vào các quy trình ấy.

Hãy thoải mái khám phá tiếp mô hình WebSphere Business Modeler. Một điều thú vị cần lưu ý là nếu bạn xem các tài nguyên đã được gán cho các quy trình này, chỉ có quy trình Record Claim Details được ghi chú là đang được tự động hóa. Trong trường hợp cụ thể này, hãy tiếp tục các cuộc thảo luận đã được tiến hành với chủ sở hữu quy trình nghiệp vụ và đã đi đến quyết định rằng mặc dù Validate Claim Recording ban đầu được xác định như là một quy trình thủ công, cũng nên xét việc tự động hoá nó. Như vậy, bạn cũng sẽ tạo ra một đặc tả dịch vụ cho quy trình này.

Tại thời điểm này, công việc của bạn trong WebSphere Business Modeler đã hoàn tất. Đóng WebSphere Business Modeler và hãy đi tiếp lên phía trước.

Như đã thảo luận khi chúng ta bắt đầu phần này, với vai trò một kiến trúc sư hoặc nhà phát triển bạn cũng có thể xem các thông tin này từ bên trong Rational Software Architect. Điều này cho phép những người chịu trách nhiệm về công việc kinh doanh làm việc trong công cụ thích hợp nhất cho công việc của họ và cũng cho phép các kiến trúc sư và các nhà thiết kế làm việc trong công cụ thích hợp nhất cho công việc của họ. Ngay bây giờ hãy xem xét làm thế nào để bạn có thể truy cập các thông tin này từ bên trong Rational Software Architect.

Xem Dự án WebSphere Business Modeler từ bên trong Rational Software Architect

Trong phần này, bạn sẽ nhập khẩu dự án WebSphere Business Modeler vào trong Rational Software Architect và đội cho nó cái mũ CNTT của bạn. Hãy bắt đầu quy trình tạo ra một thiết kế dịch vụ để đáp ứng đầy đủ các yêu cầu mà công việc kinh doanh đã nêu ra.

Để bắt đầu, mở chính dự án WebSphere Business Modeler đó, nhưng lần này từ trong Rational Software Architect:

  1. Từ Rational Software Architect, trong phối cảnh Modeling, chọn File > Import.
  2. Trong trình thủ thuật Import, chọn Existing Project Into Workspace (dự án hiện tại trong Vùng làm việc). Nhấn Next.
  3. Đối với trường Project Contents, nhấn vào Browse và trỏ đến vị trí vùng làm việc (workspace) của WebSphere Business Modeler của bạn.
  4. Chọn thư mục ClaimManagementDemoDesign, sau đó nhấn OK.
  5. Nhấn vào Finish.

Bây giờ dự án đã được nhập khẩu, Hãy dành một chút thời gian để mở dự án đó và khám phá nội dung của nó.

  1. Mở rộng dự án ClaimManagementDemoDesign như được hiển thị trong Hình 15.
Hình 15. Dự án ClaimManagementDemoDesign
Dự án
  1. Nhấn đúp chuột vào phần tử ClaimManagementDemoDesign có mặt trong dự án này (Hình 16).
Hình 16. Nhấn đúp chuột vào phần tử ClaimManagementDemoDesign trong Trình thám hiểm mô hình (Model Explorer)
Phần tử ClaimManagementDemoDesign trong Trình thám hiểm mô hình
  1. Rational Software Architect sẽ tự động ánh xạ các phần tử của dự án WebSphere Business Modeler thành UML. Hãy dành một chút thời gian để khảo sát dự án này trong Model Explorer, như được hiển thị trong Hình 17.
Hình 17. Hợp đồng nghiệp vụ trong Rational Software Architect
Hợp đồng nghiệp vụ

Lưu ý: Điều này sẽ mang lại cho bạn một điểm khởi đầu cho đặc tả kỹ thuật dịch vụ CNTT của bạn. Ví dụ, bạn không cần phải định nghĩa hoặc đặt tên các tác nhân nghiệp vụ.

Tiếp theo, bạn sẽ tạo ra một dự án và mô hình UML mới -- trong đó sẽ sử dụng một số các phần tử đến từ việc nhập khẩu WebSphere Business Modeler vào UML -- như một điểm khởi đầu cho thiết kế của bạn. Điều này sẽ cho phép bạn duy trì khả năng truy vết ngược tới các yêu cầu đang dẫn đường cho thiết kế.

Tạo ra dự án UML và mô hình Ca sử dụng

Trong nhiệm vụ này, bạn sẽ tạo ra một dự án UML có chứa một mô hình Ca sử dụng UML (Use Case Model). Khi sử dụng Rational Software Architect cho các mô hình của bạn, bạn sẽ thường có nhiều mô hình liên quan đến chỉ một dự án mà bạn hiện đang làm việc với nó. Rational Software Architect hỗ trợ dòng chảy công việc tự nhiên này bằng cách cho phép bạn thêm nhiều mô hình UML vào một dự án.

Trong trường hợp này, bạn sẽ bắt đầu bằng cách thêm một mô hình Ca sử dụng vào dự án mới được tạo ra của bạn. Kết quả là, bạn sẽ có cả mô hình WebSphere Business Modeler đã nhập khẩu lẫn mô hình Ca sử dụng của bạn trong cùng một dự án.

  1. Trong Model Explorer, chọn dự án ClaimManagementDemoDesign.
  2. Nhấn chuột phải vào nó và chọn New > UML Model, như thấy trong Hình 18.
Hình 18. Thêm một mô hình UML mới cho dự án
Mô hình UML mới cho dự án
  1. Trong trình thủ thuật Dự án Mô hình hóa UML (UML Modeling Project), chỉ rõ những mục sau đây như được hiển thị trong Hình 19.
    1. Chọn khuôn mẫu Blank Model.

Lưu ý: Một số khuôn mẫu mô hình khác cũng có sẵn để sử dụng. Trong trường hợp này, chúng tôi đang cố gắng giữ cho mọi thứ đơn giản, điều này sẽ cho phép bạn tập trung vào các phần tử mà chúng ta đang bổ sung thêm vào mô hình đó. Trong thực tế mô hình hóa, nhiều khả năng là chúng ta chọn khuôn mẫu Use Case Model (hoặc khuôn mẫu đã định nghĩa theo tùy chỉnh) làm điểm bắt đầu.

    1. Chỉ rõ tên tệp là Claim Management Use Case Model.
    2. Xoá mục Create a default diagram (tạo một sơ đồ mặc định) trong mô hình.
    Nhấn vào Finish.
Hình 19. Chỉ rõ các thuộc tính cho mô hình mới
các thuộc tính cho mô hình mới

Sau khi bạn tạo mô hình UML, khung nhìn Model Explorer đã mở rộng của bạn sẽ xuất hiện như được hiển thị trong Hình 20.

Hình 20. Model Explorer đã cập nhật
Model Explorer

Lưu ý rằng bạn có cả phần tử Claim Management Use Case Model.emx lẫn Claim Management Use Case Model. Phần tử kết thúc bằng .emx là tệp tin vật lý biểu diễn mô hình của bạn. Phần tử không có đuôi .emx là biểu diễn logic, trong đó sẽ chứa tất cả các sơ đồ và các phần tử UML mà bạn sẽ tạo ra.

Tái sử dụng các phần tử hiện có trong mô hình mới

Bây giờ bạn có một Mô hình Ca sử dụng, bạn có thể thêm các phần tử từ dự án WebSphere Business Modeler vào một sơ đồ Ca sử dụng. Mục đích là để sử dụng kết quả công việc đã được các nhà phân tích hoàn thành và cũng để cung cấp khả năng truy vết ngược tới các yêu cầu.

Trước tiên, thêm một sơ đồ Ca sử dụng vào mô hình:

  1. Chọn Claim Management Use Case Model. Nhấn chuột phải vào nó và sau đó chọn Add Diagram > Use Case Diagram.
  2. Chấp nhận tên mặc định là Diagram1.
  3. Trong dự án ClaimManagementDemoDesign, chọn ca sử dụng Record Claim như được hiển thị trong Hình 21.
Hình 21. Trường hợp sử dụng Record Claim
Record Claim
  1. Kéo nó lên trên sơ đồ Ca sử dụng mới được tạo ra (Diagram1), đã được mở theo mặc định sau khi nó đã được tạo ra.
  2. Bây giờ chọn tác nhân nghiệp vụ của trình xử lý yêu sách (Claim Processor business actor) và cũng kéo nó lên trên sơ đồ Ca sử dụng.
  3. Lưu tất cả (CTRL + Shift + s).

Sơ đồ ca sử dụng nghiệp vụ của bạn trông giống như được hiển thị trong Hình 22.

Hình 22. Sơ đồ Trường hợp sử dụng
Sơ đồ
Lưu ý: Sự liên kết giữa tác nhân nghiệp vụ trình xử lý yêu sách (Claim Processor Business Actor) và trường hợp sử dụng nghiệp vụ Ghi lại yêu sách (Record Claim Business Use Case) được tự động thêm vào sơ đồ đó vì nó đã được định nghĩa trong mô hình dự án WebSphere Business Modeler.
Trong khung nhìn Model Explorer, bạn sẽ thấy rằng không có phần tử UML nào đã được tạo ra trong Mô hình ca sử dụng.
Biểu diễn đồ họa của các phần tử này có bao gồm một mũi tên chéo nhỏ để chỉ ra rằng các phần tử được định nghĩa trong mô hình WebSphere Business Modeler chứ không phải từ mô hình Ca sử dụng hiện tại. Nếu nhà phân tích nghiệp vụ sửa đổi tên của tác nhân hoặc ca sử dụng, việc thay đổi này sẽ được phản ánh trong sơ đồ Ca sử dụng.

Bạn sẽ sử dụng Record Claim Use Case này để dẫn đường cho đặc tả kỹ thuật của thiết kế dịch vụ đó. Tuy nhiên, nó sẽ không có mặt cho đến khi bạn tới Phần 2 của loạt bài viết này, hướng dẫn bạn về khía cạnh này của việc mô hình hóa.

Trong phần kế tiếp, chúng ta sẽ xem xét làm thế nào để bạn cũng có thể truy cập tới các yêu cầu RequisitePro từ bên trong Rational Software Architect.

Xem xét lại các yêu cầu trong RequisitePro

Trong phần trước, chúng ta đã xem xét cách làm thế nào để bạn có thể truy cập được các yêu cầu đã được định rõ trong một mô hình WebSphere Business Modeler. Trong phần này, bạn sẽ truy cập tới các yêu cầu như được định rõ trong RequisitePro khi sử dụng Rational Software Architect.

Lưu ý: Thông tin để nhận được một phiên bản dùng thử của RequisitePro được cung cấp trong phần Tài nguyên của hướng dẫn này. Lưu ý rằng đối với hướng dẫn này, bạn có thể sử dụng Rational Software Architect như là trình khách của RequisitePro của bạn, do đó bạn không cần phải cài đặt RequisitePro. Tuy nhiên, bạn sẽ yêu cầu một giấy phép RequisitePro hợp lệ để có thể sử dụng Phối cảnh yêu cầu (Requirement Perspective) từ bên trong Rational Software Architect. Ngoài ra, phần này của hướng dẫn vẫn đang sử dụng tệp tin ClaimsProcessingRequirements.zip, có sẵn để tải về từ phần Tải về của hướng dẫn này. Một khi bạn đã tải nó về, hãy giải nén tệp vào một vị trí có thể tham chiếu được khi bạn thực hiện tiếp phần còn lại của mục này.

Bước đầu tiên là chuyển sang phối cảnh yêu cầu (Requirement perspective), như được hiển thị trong Hình 23.

Hình 23. Chuyển sang Requirement perspective
Requirements Perspective

Vùng làm việc của Rational Software Architect của bạn bây giờ trông giống như trong Hình 24.

Hình 24. Requirement perspective không có dự án nào đang mở
without an open project
  1. Nhấn vào Open a Requisite Pro Project (mở một dự án Requisite Pro) như được hiển thị trong Hình 25.
Hình 25. Mở một dự án Requisite Pro
Dự án RequisitePro
  1. Chọn tệp tin ClaimsProcessingRequirements.rqs có trong tệp nén ClaimsProcessingRequirements.zip, sau đó nhấn vào Open.
  2. Nhấn vào OK khi cửa sổ Đăng nhập dự án (Project Logon) mở ra, như được hiển thị trong Hình 26.
Hình 26. Đăng nhập dự án
Cửa sổ đăng nhập dự án
  1. Trong Requirement Explorer, mở rộng dự án Claims Processing Requirements, như được hiển thị trong Hình 27.
Hình 27. Dự án các yêu cầu của Quy trình yêu sách
Dự án Quy trình yêu sách
  1. Mở rộng Các yêu cầu phần mềm (Software Requirements) và sau đó nhấn đúp chuột vào All Software Requirements. Quan sát kết quả trong khung nhìn kết quả truy vấn các yêu cầu (Requirement Query Result) được hiển thị trong Hình 28.
Hình 28. Các kết quả truy vấn
Khung nhìn kết quả truy vấn

Với mục đích của hướng dẫn này, chỉ có chín yêu cầu, tất cả trong Software Requirements.

Để xem thông tin chi tiết về một trong những yêu cầu này, chọn yêu cầu trong Requirement Explorer và sau đó xem xét các thuộc tính văn bản trong khung nhìn Properties. Ví dụ, nếu bạn quan tâm đến những chi tiết đằng sau yêu cầu SR8 Usability:

  1. Chọn yêu cầu đó trong Requirement Explorer.
  2. Xem trường Text trên thẻ Properties, như được hiển thị trong Hình 29.
Hình 29. Các chi tiết yêu cầu
Các chi tiết yêu cầu của trường Văn bản trên tab Properties

Khi bạn tiếp tục thực hiện theo loạt hướng dẫn này, bạn sẽ đặc biệt chú ý đến yêu cầu SR8 - Usability, đã được gán một mức ưu tiên cao. Sự mô tả đầy đủ cho yêu cầu này đọc được như sau:

"Việc xác nhận hiệu lực của thông báo đầu tiên về thiệt hại (First Notice Of Loss) phải được hoàn tất trong chỉ một đơn vị công việc, bất kể kích cỡ của thiệt hại, số lượng các mục có liên quan hoặc tầm bao trùm của các mục có liên quan".

Trong Phần 3 của loạt bài viết này, bạn sẽ phân tích yêu cầu này chi tiết hơn và sau đó sử dụng một mẫu thiết kế để giải quyết nó. Ngoài ra, chúng ta sẽ xem xét làm thế nào để bạn có thể thiết lập khả năng truy vết giữa các yêu cầu và các phần tử được tạo ra trong bản thiết kế.

Lưu ý: Các đặc tính của phối cảnh Yêu cầu của Rational Software Architect cũng giống như của "trình khách dày" RequisitePro của Rational, trừ các nhiệm vụ quản trị. (N.D: "trình khách dày" dịch từ nguyên văn là “thick client” – nghĩa là một trình khách có nhiều chức năng phong phú, đối lập với “thin client” là một trình khách sơ sài rất ít chức năng). Ví dụ, bạn có thể chỉnh sửa, thêm hoặc xóa các yêu cầu từ bên trong Rational Software Architect. Hiện nay, bạn không thể tạo ra một dự án RequisitePro từ bên trong Rational Software Architect.

Điều này gói ghém lại quá trình tìm hiểu nhanh của chúng ta về phối cảnh Yêu cầu trong Rational Software Architect. Chúng ta sẽ trở lại phối cảnh này sau khi đề cập đến SR-8.

Để hoàn tất:

  1. Đóng dự án bằng cách nhấn chuột phải vào dự án Claims Processing Requirements trong Requirement Explorer và chọn Close Project (Đóng dự án).
  2. Tiếp theo, đóng phối cảnh Yêu cầu bằng cách nhấn chuột phải vào biểu tượng Perspective và chọn Close, như được hiển thị trong Hình 30.
Hình 30. Đóng phối cảnh
Đóng phối cảnh Các yêu cầu

Tóm tắt

Kết luận

Đến điểm này, chúng ta đã trình bày kha khá tư liệu, nhưng chúng ta chỉ vừa mới khởi đầu với việc mô hình hóa các dịch vụ của bạn. Tuy nhiên -- ngoài việc đem lại cho bạn một cái nhìn tổng quát về một số các công cụ mà bạn sẽ sử dụng và giới thiệu về dòng chảy công việc mà bạn sẽ đi theo -- một phần rất quan trọng trong những gì mà chúng ta đã làm là để cho thấy cách làm thế nào để bạn có thể giữ cho giải pháp kỹ thuật của bạn luôn được kết nối đến các khía cạnh nghiệp vụ sẽ dẫn bạn tiến lên phía trước (và thực vậy, nếu không có một công việc nghiệp vụ kinh doanh, những cái bạn làm phỏng có nghĩa gì?). Khi chúng ta nói về SOA, chúng ta xem xét việc tạo ra sự linh hoạt nghiệp vụ: cung cấp cho doanh nghiệp các giải pháp được điều khiển bởi hoạt động nghiệp vụ (được gọi là Phát triển dựa theo nghiệp vụ- Business-Driven Development).

Là một kiến trúc sư hay nhà thiết kế, bạn có thể không dành nhiều thời gian của bạn để tạo ra các yêu cầu nghiệp vụ kết hợp với một giải pháp. Tuy nhiên, bạn cần phải biết tìm ra các thông tin này ở đâu, làm thế nào để làm việc với nó và làm thế nào để đưa nó vào trong các công cụ mà bạn cần phải hoàn thành phần việc của bạn trong quá trình sản xuất này. Chúng ta đã thấy rằng Rational Software Architect cung cấp cho bạn các cầu nối cần thiết để bước vào trong thế giới của các yêu cầu và rằng các cầu nối này cho phép bạn kết nối công việc của bạn với các yêu cầu.

Các bước tiếp theo

Bạn đã nhận được một số bước nền tảng, nhưng rất quan trọng, trong việc tìm tòi để mô hình hóa các đặc tả kỹ thuật dịch vụ theo kiểu từ trên xuống. Trước mắt, chúng ta cần phải xây dựng tiếp dựa trên các kết quả làm việc này, lấy các yêu cầu đã được xác định và bắt đầu dịch chuyển chúng thành một giải pháp kỹ thuật. Trong phần tiếp theo của loạt bài viết này, chúng ta sẽ xem xét làm thế nào để bạn có thể thiết kế các dịch vụ của bạn bằng cách sử dụng UML, cùng với một lược tả chuyên biệt sẽ đo cắt lại UML để nắm bắt được các thông tin cụ thể cho các dịch vụ.


Các tải về

Mô tảTênKích thước
WebSphere Business Modeler ProjectClaimManagementDemoDesign.zip8 KB
RequisitePro ProjectClaimsProcessingRequirements.zip154 KB
Rational Software Architect Project InterchangePart1-Intrchg.zip285 KB

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=418449
ArticleTitle=Thiết kế các dịch vụ SOA với Rational Software Architect, Phần 1: Khởi đầu bằng các yêu cầu, quy trình và mô hình hóa
publish-date=08072009