Thiết kế các dịch vụ SOA với Rational Software Architect, Phần 3: Sử dụng các tài sản và các mẫu trong thiết kế của bạn

Tìm hiểu cách làm thế nào để tạo ra thiết kế dịch vụ của service-oriented architecture (SOA - kiến trúc hướng-dịch vụ) khi sử dụng IBM® Rational® Software Architect (Kiến trúc sư phần mềm Rational của IBM), các tài sản có thể dùng lại và Đặc tả kỹ thuật của tài sản có thể dùng lại (Reusable Asset Specification-RAS) và các mẫu và mẫu thiết kế phức hợp của bộ tứ (Gang of Four-GoF). Tìm hiểu cách làm thế nào để truy tìm nguồn gốc các quyết định thiết kế đến các yêu cầu trong IBM Rational RequisitePro®. Tìm hiểu cách làm thế nào để xuất bản các báo cáo về mô hình thiết kế dịch vụ của bạn.

Bertrand Portier, Kiến trúc sư IT, IBM

Bertrand Portier, kiến trúc sư CNTT, làm việc trong bộ phận các giải pháp tích hợp Doanh nghiệp (EIS) của Tập đoàn Phần mềm IBM. Ông làm việc trong lĩnh vực về các dự án chuyển đổi sang chiến lược SOA và dựa trên những kinh nghiệm này, ông rất thích hợp với các nhóm phát triển của Tập đoàn phần mềm IBM. Nền tảng của ông là J2EE và các dịch vụ web và hiện nay ông tham gia nhiều vào việc phát triển dựa theo-mô hình và dựa vào-tài sản.



Lee Ackerman, Giám đốc tiếp thị, IBM

Lee AckermanLee Ackerman là một nhà quản lý sản phẩm cao cấp của đội các giải pháp và các dịch vụ học tập của Rational, IBM. Ông tập trung vào việc tạo ra các tài sản vốn trí thức, cho phép những người sử dụng bộ công cụ phát triển dựa theo mô hình của Rational thành công trong việc tạo ra các giải pháp J2EE và SOA


Cấp độ đóng góp cho developerWorks của
        tác giả

28 08 2009

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

Hãy xem bạn 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ác 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 theo 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ý: Môi trường phát triển luôn luôn cung cấp hướng dẫn tùy bối cảnh cho các phương pháp hay các quy trì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 khớp với các nhu cầu của họ.
  • Tự động hóa: Các ánh xạ và siêu mô hình ở 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, cầ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ả những điều trên là các đặc tính của IBM® Rational® Software Development Platform (SDP - Nền phát triển phần mền Rational IBM) và cụ thể hơn là của IBM Rational Software Architect. 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 Rational và các khả năng của nó để thiết kế các giải pháp SOA.

Hướng dẫn này 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ừ Quy trình nghiệp vụ (Business Process), 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. Nó cũng 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 Phần 1 của loạt bài viết, bạn đã làm quen với Rational Software Architect và cách nó tích hợp với các công cụ khác mà bạn sử dụng trong các giai đoạn khác nhau của vòng đời SOA như thế nào. Trong Phần 2, bạn đã tìm hiểu cách sử dụng Rational Software Architect, UML và Định dạng UML 2.0 cho Các dịch vụ phần mềm như thế nào để thiết kế các dịch vụ. Trong hướng dẫn này, Phần 3 của loạt bài, bạn sẽ tìm hiểu về các mẫu và các tài sản phần mềm có thể sử dụng lại và bạn sẽ sử dụng các mẫu thiết kế để giải quyết các yêu cầu. Bạn cũng sẽ liên kết các quyết định thiết kế với các yêu cầu trong một dự án IBM Rational® RequisitePro® (khả năng truy vết nguồn gốc). Cuối cùng, bạn sẽ xuất bản các báo cáo về thiết kế dịch vụ của bạn.

Các mục tiêu

Sau khi hoàn tất hướng dẫn này, bạn sẽ có một sự hiểu biết tốt hơn về giá trị của các biểu diễn trực quan như là một phần của MDD.Ngoài ra, bạn cũng sẽ hiểu các mẫu và các tài sản phần mềm có thể dùng lại là gì và làm thế nào để bạn sử dụng Rational Software Architect để đưa chúng vào trong thiết kế của bạn. Bạn cũng có khả năng truy tìm nguồn gốc các quyết định thiết kế tới các yêu cầu và xuất bản các báo cáo về thiết kế của bạn.

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

Để nhận được nhiều giá trị hơn từ hướng dẫn này, bạn rất nên nhưng không bắt buộc 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 (Trình mô hình hóa phần mềm Rational).
  • RequisitePro, sản phẩm quản lý các yêu cầu Rational của IBM.
  • SOA, service-oriented architecture (kiến trúc hướng-dịch vụ).

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

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

Để hoàn thành hướng dẫn này, bạn cần cài đặt các phần mềm sau đây:

  • Rational Software Architect
  • Rational RequisitePro

Các tài sản và các mẫu

Trong suốt tiến trình của loạt bài viết này, bạn sẽ sử dụng một số tài sản. Một số tài sản đi kèm với sản phẩm Rational Software Architect, trong khi những tài sản khác được bổ sung thêm vào môi trường của bạn (ví dụ, UML 2.0 Profile for Software Services - Lược tả UML 2.0 cho Các dịch vụ phần mềm được sử dụng trong Phần 2. Ngoài những tài sản mà bạn sử dụng cho hướng dẫn này, bạn cũng có thể tìm thấy tài sản có sẵn để tải về từ một IBM® developerWorks® RAS (đặc tả tài sản sử dụng lại) Repository (Kho lưu trữ RAS của developerWorks của IBM) -- xem vùng các giải pháp mẫu (Pattern Solutions) trên developerWorks để biết thêm thông tin về những tài sản và Repository (Kho lưu trữ) RAS.

Trong phần này, trước tiên bạn sẽ tìm hiểu các tài sản và các mẫu là gì. Sau đó, bạn sẽ tìm hiểu về RAS. Cuối cùng, bạn sẽ thiết lập môi trường Rational Software Architect của bạn để khám phá Repository RAS.

Các tài sản, các mẫu và các đặc tả kỹ thuật của RAS

Tài sản hay dịch vụ?

Các tài sản (Assets) và các dịch vụ (services) chia sẻ các đặc điểm chung, chẳng hạn như đều cần một sự mô tả, tiềm năng sử dụng lại của chúng và độ chi tiết của chúng (mịn hơn so với thô hơn). Một dịch vụ có thể được xem như một loại tài sản, loại tài sản mà để có thể biểu diễn có hiệu quả cần đến nhiều tài sản khác. Một số các phần tử của các tài sản dịch vụ được sử dụng nhiều hơn trong thời gian phát triển (ví dụ, các mô hình quy trình nghiệp vụ hoặc các trường hợp thử nghiệm), trong khi các phần tử khác của các tài sản dịch vụ này được áp dụng nhiều hơn khi chạy thực (ví dụ, WSDL, XSD và EAR). Là một phần của Quản trị SOA, các tổ chức sẽ định nghĩa các quy tắc liên quan đến vòng đời của các dịch vụ và các tài sản như vậy (ví dụ, đã đầu tư kinh phí, đã phê duyệt, đã triển khai hoặc đã thôi sử dụng).

Các tài sản và các mẫu là chìa khóa cho sự thành công của SOA, vì chúng cho phép sử dụng lại. Trong thực tế, các doanh nghiệp có chấp nhận một mô hình nghiệp vụ dựa trên tài sản sẽ có khả năng tăng trưởng hết sức to lớn. Họ sẽ không còn bị giới hạn bởi năng suất hay số lượng nhân viên của họ, như trong mô hình nghiệp vụ dựa trên lao động truyền thống. Việc sử dụng đúng các tài sản có thể thay đổi đáng kể các yêu cầu đầu tư phần mềm. Tuy nhiên, bất cứ ai đã chấp nhận mô hình này đều có thể bảo bạn rằng nó không phải là hoàn toàn đơn giản và đòi hỏi quản lý, thúc đẩy nhân viên và hỗ trợ cơ sở hạ tầng thích hợp.

Sự sáng tạo có thể là phản tác dụng với SOA. Hãy suy nghĩ về ví dụ của những người phát minh lại cái bánh xe với mỗi dự án mới. Các tài sản và các mẫu hiện diện ở đó và cho phép một mức độ sáng tạo thích hợp: bạn sử dụng lại các giải pháp đã được kiểm chứng ở bất cứ nơi nào có thể và sau đó tập trung tất cả thời gian và công sức của bạn vào những gì cần phải được phát minh.

Các tài sản

Một tài sản là một tập hợp các tạo phẩm (artifacts) cung cấp một giải pháp cho một vấn đề theo bối cảnh.

Trong bối cảnh này, các tạo phẩm có thể là bất cứ thứ gì. Ví dụ, nó có thể là một yêu cầu, một mô hình thiết kế, một số mã triển khai thực hiện hoặc một trường hợp thử nghiệm. Hãy suy nghĩ về một tạo phẩm như là một tệp tin trên hệ thống tệp tin của bạn.

Các tài sản bao gồm các chỉ dẫn về cách sử dụng, tùy chỉnh và mở rộng chúng như thế nào. Đây là điều quyết định đối với sự thành công của chúng.

Đừng lo lắng nếu bạn không cảm thấy mình đã biết mọi thứ về các tài sản; đây chỉ là một lời giới thiệu ngắn. Bạn sẽ tìm hiểu nhiều hơn về những gì tạo nên một tài sản trong phần RAS tiếp theo.

Các mẫu

Tài sản hay là mẫu?

Các tài sản và các mẫu cả hai đều cung cấp một giải pháp đã được kiểm chứng cho một vấn đề theo bối cảnh. Vì thế sự khác nhau là gì? Dưới đây là các gợi ý để giúp cho bạn suy nghĩ về các sự khác biệt rất khó thấy này.

  • Một tài sản có thể chứa tạo phẩm của loại bất kỳ (ví dụ, một bộ phim), nhưng cũng bao gồm các mẫu.
  • Một mẫu có thể được xem như một loại tài sản đặc biệt.
  • Các tài sản được sao lưu với mô hình (RAS) tiêu chuẩn hóa về việc làm thế nào để mô tả và cấu trúc chúng, một mô hình có thể được mở rộng với các lược tả.
  • Bạn có thể suy nghĩ về một mẫu như là đặc tả kỹ thuật và việc triển khai thực hiện của nó.

Một mẫu là một giải pháp theo một vấn đề tuần hoàn trong một bối cảnh đã cho.

Một mẫu có thể được xem như một kiểu tài sản sử dụng lại.

Bạn có thể tạo ra sự khác biệt giữa các đặc tả kỹ thuật của một mẫu (một sự mô tả của vấn đề, bối cảnh, các ảnh hưởng và giải pháp) và các việc triển khai thực hiện của nó (ví dụ, một thành phần JavaBeans™). Có thể có nhiều việc triển khai một đặc tả kỹ thuật của một mẫu.

Các mẫu được chia thành các thể loại khác nhau, tùy thuộc vào việc chúng khớp với giai đoạn nào trong quá trình phát triển. Ví dụ, các mẫu của IBM cho kinh doanh điện tử (eBusiness) đã phân loại các mẫu theo các thể loại sau:

  • Kinh doanh.
  • Tích hợp.
  • Phức hợp.
  • Ứng dụng.
  • Chạy thực.

Một nhóm các mẫu nổi tiếng khác là bốn mẫu thiết kế kinh điển (Gang of Four patterns - GoF).

Một điểm quan trọng cần nhấn mạnh về các mẫu là tính hữu dụng và tính đúng đắn của các giải pháp mà chúng cung cấp đã được xác thực.

Tuy nhiên, như với bất kỳ loại tài sản có thể dùng lại nào, sẽ chỉ có thể chấp nhận nếu đã cho trước một bối cảnh và phương pháp để xem xét khi nào, tại sao và làm thế nào để sử dụng các mẫu đó. Như bạn có thể thấy, có rất nhiều mẫu ở đó và bối cảnh ấy sẽ là cần thiết để bắt đầu.

Các mẫu cho eBusiness chẳng hạn, được trình bày với một quá trình, dựa trên các kỹ năng và môi trường, sẽ giúp bạn nhận biết các mẫu có liên quan sẽ giải quyết được các vấn đề kinh doanh của bạn.

Cuối cùng, một trong những mục tiêu của các mẫu là để cung cấp tính nhất quán: dựa trên cùng một bộ các yêu cầu, bạn sẽ đi đến cùng một kiến trúc, bởi vì bạn đang sử dụng các mẫu trong thiết kế của bạn.

Đặc tả kỹ thuật của tài sản có thể dùng lại (RAS)

Được thông qua vào năm 2005, RAS là một chuẩn của Nhóm quản lý đối tượng (Object Management Group - OMG) được sử dụng để mô tả cấu trúc, các nội dung và sự mô tả tài sản phần mềm có thể dùng lại. Mục tiêu của RAS là cung cấp các cách làm thực tế tốt nhất, liên quan đến cách làm thế nào để đóng gói các tài sản theo một cách nhất quán và đúng tiêu chuẩn.

Như được định nghĩa trong đặc tả kỹ thuật, các đặc điểm cốt lõi của một tài sản RAS bao gồm:

  • Phân loại: bối cảnh trong đó tài sản này có liên quan.
  • Giải pháp: các tạo phẩm chứa trong tài sản này.
  • Cách sử dụng: các quy tắc để cài đặt, sử dụng và tùy chỉnh tài sản này.
  • Các tài sản có liên quan: tài sản này liên quan đến tài sản khác như thế nào.

Các tạo phẩm có thể có một kiểu, được xác định hoặc bằng hậu tố của tên tệp (ví dụ, .xml, .txt, .doc hoặc .java) hoặc theo mục đích của chúng (mô hình trường hợp sử dụng hay mô hình phân tích).

Do các tài sản phần mềm (software assets) là một thuật ngữ rất rộng, RAS cũng cung cấp các lược tả được sử dụng để mô tả các kiểu tài sản cụ thể. Đây cũng là cùng một ý tưởng như các lược tả UML. Bạn đã thấy trong Phần 2 rằng có các lược tả UML được sử dụng để mở rộng UML độc lập với lĩnh vực ứng dụng. Theo cùng kiểu này, có các lược tả RAS riêng cho lĩnh vực cụ thể (ví dụ, các dịch vụ Web) được sử dụng để mở rộng RAS độc lập với lĩnh vực ứng dụng.

Các tài sản RAS có phần mở rộng là .ras và được đóng gói như các tệp tin nén (chúng có một bảng kê và có thể mở được bằng WinZip).

Hãy tham khảo phần Tài nguyên để tìm một liên kết đến một bài viết chi tiết của developerWorks về các tài sản có thể dùng lại, công thức pha chế và các mẫu.

Bây giờ bạn hiểu các tài sản và các mẫu có thể sử dụng lại là gì và những lợi ích mà chúng đem lại, các bạn cần có một nền tảng để hỗ trợ cho việc tiêu dùng hoặc đóng gói các tài sản như vậy. Trong phần kế tiếp, bạn sẽ thấy Rational Software Architect hỗ trợ RAS như thế nào.

Hỗ trợ RAS trong Rational Software Architect

Phối cảnh RAS

Như được mô tả trong Phần 1, các phối cảnh cung cấp một bộ các khung nhìn được bố trí ban đầu. Như tên của nó ngụ ý, phối cảnh RAS được thiết kế để làm việc với các tài sản. Như bạn có thể nhìn thấy trong Hình 1, nó cung cấp một vùng soạn thảo (1) và các khung nhìn sau đây: Trình thám hiểm tài sản-Asset Explorer (2), Chuyển hướng-Navigator (3), Phác thảo-Outline (4) và Các thuộc tính- Properties (5).

Hình 1. Phối cảnh RAS
Phối cảnh RAS
  1. Nếu chưa khởi động, hãy khởi động Rational Software Architect. Theo mặc định, bạn sẽ ở trong phối cảnh Mô hình hóa (Modeling perspective).
  2. Nhấn vào Mở một phối cảnh (Open a perspective) và sau đó nhấn Other, như được hiển thị trong Hình 2.
Hình 2. Mở một phối cảnh mới
một phối cảnh mới
  1. Chọn phối cảnh RAS (Các tài sản có khả năng dùng lại) và nhấn OK.
  2. Nếu bạn không nhìn thấy phối cảnh RAS, chọn Show all (Hiển thị tất cả), như được chỉ ra trong Hình 3.
Hình 3. Mở phối cảnh RAS
một phối cảnh RAS

Phối cảnh RAS bây giờ đã được mở và bạn sẽ có thể nhìn thấy một cái gì đó giống như Hình 1.

Kho lưu trữ RAS của developerWorks

Bạn ở sau một bức tường lửa?

Trong phần này, bạn sẽ truy cập vào kho lưu trữ (Repository) RAS của developerWorks trên internet. Bạn có thể cần phải đặt cấu hình các giá trị thiết lập máy chủ ủy quyền (proxy) của bạn để có thể truy cập được.

  1. Nếu cần thiết, chọn Preferences trong cửa sổ trình đơn Window.
  2. Chọn Internet > Proxy Settings.
  3. Nhập các thông tin cần thiết.
  4. Nhấn ApplyOK.

Trong phần này, bạn sẽ tìm hiểu làm thế nào để tiêu dùng một tài sản RAS với Rational Software Architect. Trong một phần khác của loạt bài viết này, bạn sẽ tìm hiểu làm thế nào để đóng gói một tài sản RAS.

  1. Trong Asset Explorer, nhấn chuột phải và chọn New > Repository
  2. Trong hộp thoại Kết nối kho lưu trữ mới (New Repository Connection), chọn developerWorks Repository và nhấn vào Next.
  3. Các giá trị sẽ được điền vào tự động cho bạn. Nhấn Finish (Hình 4).
Hình 4. Kết nối đến Kho lưu trữ RAS của developerWorks
Kết nối đến Kho lưu trữ RAS
  1. Trong Asset Explorer, mở rộng Kho lưu trữ developerWorks Rational của IBM và xem xét các tài sản có sẵn có để sử dụng lại (Hình 5).
Hình 5. Kho lưu trữ RAS của developerWorks
Kho lưu trữ RAS

Kho lưu trữ RAS của developerWorks được IBM lưu trữ trên máy chủ và có chứa các tài sản mô hình hóa mới mà không phải là một phần của các sản phẩm.

Phiên bản 6 của Rational Software Architect không cung cấp một phép biến đổi UML thành WSDL. Bây giờ bạn sẽ tìm kiếm kho lưu trữ RAS của developerWorks để tìm một phép biến đổi như vậy. Lưu ý rằng bạn có thể tìm kiếm (và tìm thấy!) các tài sản bởi vì những người đã đóng gói chúng cung cấp các thông tin phù hợp, được lưu giữ trong các bảng kê của các tài sản này.

  1. Từ trong khung nhìn Asset Explorer, hãy nhấn vào Mở hộp thoại tìm kiếm (Open Search dialog) (Hình 6).
Hình 6. Mở hộp thoại tìm kiếm tài sản
Hộp thoại tìm kiếm tài sản
  1. Trong trường Keyword, gõ: UML WSDL.
  2. Nhấn vào Search.
  3. Quá trình tìm kiếm sẽ chạy và sau một vài giây, bạn sẽ thấy các kết quả trong khung nhìn Search ở phía dưới. Kết quả đầu tiên là phép biến đổi UML thành WSDL, như được hiển thị trong Hình 7.
Hình 7. Các kết quả tìm kiếm tài sản
Tìm kiếm tài sản
  1. Trong khung nhìn Asset Explorer, mở rộng thư mục phân tích trong kho lưu trữ IBM Rational developerWorks.
  2. Chọn UML to WSDL Transform.
  3. Nhấn chuột phải và chọn View > Documentation.

Một trang HTML sẽ mở ra trong trình duyệt Web yêu thích của bạn, hiển thị bảng kê của tài sản này theo định dạng Web. Ví dụ, bạn có thể xem mô tả ngắn gọn, phiên bản, lược tả đi kèm và mô tả dài của tài sản đó.

Bây giờ, bạn sẽ sử dụng các tài sản (các mẫu) đã được bao gồm trong sản phẩm của Rational Software Architect.


Sử dụng các mẫu thiết kế

Trong phần này, bạn sẽ nhận biết rằng mẫu thiết kế Phức hợp của bộ tứ (GoF) có thể được dùng để giải quyết một yêu cầu xác nhận hợp lệ yêu sách.

Hiểu rõ các yêu cầu và các mẫu

Phân tích yêu cầu

Trong Phần 1 của loạt bài viết này, bạn thấy rằng thiết kế của bạn phải thỏa mãn một yêu cầu về tính khả dụng với mức ưu tiên cao đối với một đơn đệ trình xác nhận hiệu lực yêu sách bồi thường đơn lẻ. Văn bản của yêu cầu này (SR8 Usability) là 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.

Bây giờ bạn sẽ phân tích yêu cầu này. Ví dụ, giả sử rằng sau hỏa hoạn, một bên muốn xác nhận tính hợp lệ các chi tiết về một yêu sách bồi thường cho một thuyền, xe hơi và nhà ở. Yêu cầu này ngụ ý rằng bên đó phải có khả năng xác nhận hợp lệ các chi tiết bằng cách gọi dịch vụ đó chỉ một lần chứ không phải ba lần (mỗi lần cho một thứ là thuyền, xe hơi và nhà ở).

Hiện nay, hoạt động xác nhận tính hợp lệ của đặc tả dịch vụ IClaimValidator, được thiết kế trong Phần 2, sẽ nhận một Yêu sách (Claim) làm đầu vào, như được hiển thị trong Hình 8.

Hình 8. IClaimValidator
Đặc tả dịch vụ IClaimValidator

Thiết kế hiện tại không giải quyết yêu cầu tính khả dụng, do hoạt động xác nhận tính hợp lệ chỉ nhận một Claim duy nhất như là thông báo yêu cầu của nó.

Sau đây, bạn sẽ xem xét một mẫu thiết kế để tập trung vào yêu cầu này.

Các mẫu thiết kế GoF

Trong bối cảnh này, GoF không phải nói về Harry Potter và Chiếc cốc lửa (Goblet of Fire) (!), mà là nói về bốn nhà thiết kế phần mềm, chuyên gia về lĩnh vực hướng-đối tượng, những người đề xuất các giải pháp cho các vấn đề chung trong thiết kế phần mềm (nói cách khác, các mẫu thiết kế). Họ xuất bản một cuốn sách (xem phần Tài nguyên để biết thêm chi tiết) có trình bày các mẫu thiết kế là gì, cũng như một danh sách 23 mẫu thiết kế (bao gồm đặc tả và thực hiện). Các mẫu thiết kế GoF được phân thành các thể loại sau đây:

  • Sáng tác (Creational): ví dụ, Singleton
  • Cấu trúc (Structural): ví dụ, Facade, Proxy
  • Hành vi (Behavioral): ví dụ, Command

Rational Software Architect bao gồm tất cả các mẫu thiết kế GoF. Bây giờ bạn sẽ tìm hiểu chúng, bằng cách sử dụng Pattern Explorer.

  1. Quay trở về phối cảnh Mô hình hóa (Modeling perspective).

Theo mặc định, Pattern Explorer sẽ được hiển thị trong chế độ xem nhanh, như được hiển thị trong Hình 9. Nếu không như thế, hãy tham khảo thanh bên.

Hiển thị Asset Explorer trong Chế độ xem nhanh

Nếu bạn không thể nhìn thấy khung nhìn Pattern Explorer, hãy làm theo những hướng dẫn này.

  1. Chọn Show view > Pattern Explorer, từ trong trình đơn Window.
  2. Khung nhìn Pattern Explorer bây giờ được bố trí ở phía dưới đáy.
  3. Để sử dụng nó trong chế độ xem nhanh, kéo khung nhìn từ dưới đáy lên sát bên phải, gần với vùng trình soạn thảo (Hình 9).
Hình 9. Pattern Explorer trong chế độ Xem nhanh
Xem nhanh
  1. Để duyệt qua các mẫu, hãy nhấn vào biểu tượng Trình thám hiểm mẫu (pattern explorer), cũng được hiển thị trong Hình 9.
  2. Mở rộng các thể loại Behavioral, Creational và Structural để xem 23 mẫu thiết kế.

Trình thám hiểm mẫu hiện cung cấp các khả năng tìm kiếm, nhưng trong trường hợp này bạn sẽ chỉ cần chọn Mẫu thiết kế (Design Pattern) và xem xét các mô tả của chúng. Để giải quyết yêu cầu của bạn, bạn sẽ cấu trúc thông báo đầu vào xác nhận tính hợp lệ để nó hỗ trợ việc xác nhận tính hợp lệ đơn lẻ cho các yêu sách kiểu khác nhau. Hãy nhìn vào thể loại Structural.

Phức hợp (Composite) là một ứng cử viên có khả năng...

Mẫu thiết kế phức hợp

  1. Chọn mẫu Phức hợp (Composite) như được hiển thị trong Hình 10.
Hình 10. Chọn Mẫu Phức hợp
Mẫu Phức hợp

Như đã nêu trong mô tả ngắn, mẫu Phức hợp (được hiển thị trong Hình 11) phối hợp các đối tượng thành các cấu trúc cây để biểu diễn hệ thống phân cấp toàn phần. Mẫu Phức hợp cho phép các máy khách xử lý các đối tượng riêng lẻ và các cấu thành nhiều đối tượng giống nhau.

  1. Chọn tab Overview.
Hình 11. Mẫu phức hợp
Mẫu phức hợp

Bạn sẽ thấy rằng những thứ tham gia vào mẫu này bao gồm:

  • Thành phần (Component): Một thành phần khai báo giao diện cho các đối tượng trong kết cấu. Nó triển khai thực hiện hành vi mặc định cho giao diện chung cho tất cả các lớp, nếu thích hợp. Nó khai báo một giao diện để truy cập và quản lý các thành phần con của nó. Nó có thể (như một tùy chọn) định nghĩa một giao diện để truy cập cha mẹ của thành phần trong cấu trúc đệ quy và triển khai thực hiện nó nếu điều đó là thích hợp.
  • Hoạt động (Operation): Một hoạt động là một giao diện thành phần để truy cập và quản lý các thành phần con của nó.
  • Lá (Leaf): Một lá biểu diễn các đối tượng lá trong kết cấu. Một lá không có thành phần con. Nó định nghĩa hành vi cho các đối tượng nguyên thủy trong kết cấu.
  • Phức hợp (Composite): Một phức hợp là hành vi cho các thành phần có thành phần con. Nó lưu trữ các thành phần con. Nó triển khai thực hiện các hoạt động có liên quan đến thành phần con trong giao diện Component.

Lưu ý rằng các mô tả này được sao chép từ tab Mô tả ngắn (Short Description) cho mỗi thành phần.

Liên hệ mẫu Phức hợp (Composite) được áp dụng cho yêu sách bồi thường

Bây giờ hãy xem xét mẫu Composite được áp dụng cho Claim. Trong bối cảnh này, các bên tham gia Composite được gọi là ClaimFolder, Leaf Elementary Claim và Component Claim, như được hiển thị trong Hình 12.

Hình 12. Mẫu Phức hợp được áp dụng cho Claim
Mẫu Phức hợp được áp dụng cho Claim

Bằng cách thay đổi thông báo xác nhận tính hợp lệ đầu vào để cho nó nhận một ClaimFolder (thay vì một Claim), bạn cho phép một bên (Party) truy cập vào hoạt động xác nhận tính hợp lệ chỉ một lần và gửi một ClaimFolder có chứa tất cả ba yêu sách bồi thường về thuyền, xe hơi và nhà ở. Ngoài ra, một bên muốn gửi một yêu sách bồi thường duy nhất (ví dụ, xe ô tô) vẫn có thể làm như vậy.

Khi sử dụng các mô hình công nghiệp từ IBM (ví dụ, Insurance Application Architecture hoặc IAA-Kiến trúc ứng dụng bảo hiểm, được mô tả trong Phần 1), bạn không cần phải lo lắng về việc áp dụng các mẫu, vì các mẫu đã có trong thiết kế. Đặc biệt, mẫu thiết kế Composite được sử dụng rộng rãi trong IAA và ví dụ ClaimFolder đến từ IAA.

Bây giờ bạn sẽ tạo ra cấu trúc ClaimFolder. Sau đó, bạn sẽ sửa đổi đặc tả dịch vụ IClaimValidator để sử dụng ClaimFolder.

Sử dụng mẫu trong việc thiết kế

Áp dụng mẫu cho mô hình

  1. Trong Model Explorer, nhấn đúp chuột vào sơ đồ Main trong mô hình Messages (Các thông báo) để mở nó.

Để sử dụng các mẫu trong Rational Software Architect, bạn cần phải tạo ra các cá thể của chúng. Một cách để tạo ra các cá thể là bằng cách kéo các mẫu từ Pattern Explorer.

  1. Kéo mẫu Composite từ Pattern Explorer tới sơ đồ đó.
  2. Một cá thể mẫu (Pattern Instance) sẽ phải được thêm vào mô hình của bạn. Đặt tên nó là CompositeClaim, như được hiển thị trong Hình 13.

Các cá thể mẫu được biểu diễn như là các sự hợp tác, các trình phân loại (classifiers) có cấu trúc với các vai trò và các thuộc tính được sử dụng để định nghĩa một cấu trúc. Có thể có nhiều cá thể độc lập của cùng một mẫu.

  1. Trên cá thể mẫu, đổi tên Composite mặc định thành CompositeClaim. Lưu ý từ khóa Pattern Instance.
Hình 13. Tạo CompositeClaim
CompositeClaim

Cá thể mẫu CompositeClaim có các tham số như là Component, Composite và Leaf như được định nghĩa bởi mẫu Composite. Khi cá thể mẫu được tạo ra, các tham số của nó không có giá trị nào. Quá trình thiết lập các giá trị này được gọi là kết buộc (binding). Rational Software Architect cho phép kết buộc dễ dàng các tham số bằng cách sử dụng các động tác kéo và thả.

Bây giờ bạn sẽ kết buộc các tham số của cá thể mẫu CompositeClaim.

  1. Kéo Claim vào tham số Component để kết buộc nó, như được hiển thị trong Hình 14.
Hình 14. Kết buộc Claim với Component
Kết buộc Claim với Component

Claim bây giờ sẽ có từ khóa Component và cá thể mẫu CompositeClaim sẽ có tham số Component của nó được chỉ rõ (Hình 15).

Như với các bản mẫu (stereotypes), các từ khóa được sử dụng để chỉ ra sự kết buộc các phần tử với các tham số mẫu (Composite, Component và Leaf).

Hình 15. Claim đã kết buộc
Các tham số thành phần cụ thể

Cũng có thể tạo ra phần tử mới trực tiếp từ cá thể mẫu trong quá trình kết buộc. Điều này rất có ích khi không có phần tử nào đã tồn tại để kết buộc các tham số với nó.

Không có các phần tử hiện có để kết buộc các tham số Composite và Leaf. Bây giờ bạn sẽ kết buộc các tham số này bằng cách tạo ra các phần tử mới trực tiếp từ cá thể mẫu CompositeClaim.

  1. Đặt con trỏ tới tham số Leaf và sau đó nhấn vào Tạo đối số mới của kiểu Class (Create new argument of type Class) khi thanh hành động xuất hiện (Hình 16).

Áp dụng, Thôi áp dụng và Áp dụng lại các mẫu

Nếu bạn muốn thôi áp dụng hoặc áp dụng lại các mẫu, chọn cá thể mẫu từ Model Explorer hoặc một sơ đồ mà nó xuất hiện trong đó, nhấn chuột phải vào và sau đó chọn Patterns > Unapply/Reapply.

Hình 16. Kết buộc Lá
Kết buộc Lá
  1. Trong Model Explorer, đổi tên lớp mới được tạo ra thành ElementaryClaim. Hãy chắc chắn rằng bạn duy trì từ khóa Leaf.
  2. Tương tự, kết buộc giá trị Component vào một lớp mới có tên là ClaimFolder
  3. Kéo hai lớp mới từ Model Explorer tới sơ đồ Messages.
  4. Nhấn chuột phải vào một nơi nào đó trong vùng trống của sơ đồ và chọn Filters > Show / Hide Relationships.
  5. Vì chúng ta muốn hiển thị tất cả các mối quan hệ, nhấn OK trong cửa sổ Show / Hide Relationship.
  6. Các mối quan hệ bây giờ sẽ được hiển thị giữa cá thể mẫu CompositeClaim và ba lớp mà bạn vừa mới kết buộc. Bố trí lại các phần tử để làm cho sơ đồ dễ đọc hơn.
  7. Để bố trí các phần tử của một sơ đồ, lưu ý rằng khi một quan hệ kết hợp được chọn, bạn có thể nhấn chuột phải vào và sau đó chọn Format > Line Style > Rectilinear Style Routing. Điều này được hiển thị trên Hình 17 cho kết hợp cách sử dụng giữa Claim và Claim Folder và tập hợp giữa ClaimFolder và Claim.
  8. Sơ đồ Message của bạn bây giờ trông giống như Hình 17. Lưu tất cả (Ctrl+Shift+S).
Hình 17. Thiết kế Thông báo
Thiết kế Thông báo

Lưu ý rằng ở giai đoạn này, bạn có thể sửa đổi thông báo RecordClaimRequest để bây giờ nó có chứa một ClaimFolder thay vì một Claim. Lợi ích của việc làm như thế chứ không thay đổi số bội của kết cấu giữa RecordClaimRequest và Claim là ở chỗ, nếu API đó đã được xuất bản và các nhà phát triển đã bắt đầu mã hóa với thiết kế trước đó, mã của họ sẽ vẫn hoạt động vì ClaimFolder là một Claim, trong khi một mảng hoặc danh sách các yêu sách không phải là một Claim. Trong thế giới SOA, bạn nên luôn luôn nghĩ về những tác động mà một sự thay đổi có thể gây ra với những nơi khác và giảm thiểu tác động đó.

Trong phần kế tiếp, bạn sẽ sửa đổi thiết kế đặc tả dịch vụ để cho hoạt động xác nhận hợp lệ của IClaimValidator sử dụng ClaimFolder thay cho Claim.

Sửa đổi Thiết kế Đặc tả dịch vụ

  1. Trong Model Explorer, chọn phương thức xác nhận tính hợp lệ của IClaimValidator (trong gói Các đặc tả dịch vụ- Service Specifications).
  2. Chọn thẻ Parameters trong khung nhìn Properties.
  3. Trong Type, nhấn vào ô Class Claim.
  4. Nhấn vào nút ... để chọn một kiểu khác. Trong cửa sổ bật lên, chọn ClaimFolder trong gói Messages.
  5. Sửa đổi tên của tham số từ claim thành claimFolder. Lưu lại tất cả (Ctrl+Shift+S).
  6. Trong sơ đồ chính của Service Specifications, đặc tả dịch vụ IClaimValidator bây giờ trông giống như Hình 18. Nếu bạn không nhìn thấy chữ ký của phương thức xác nhận tính hợp lệ, hãy chọn IClaimValidator, nhấn chuột phải vào và sau đó chọn Filters > Show signature.
Hình 18. IClaimValidator
IClaimValidator

Lưu ý rằng sự thay đổi này sẽ được phản ánh trong các phần khác của thiết kế, nơi phương thức xác nhận tính hợp lệ xuất hiện (ví dụ, dưới các giao diện ClaimProcessor Service Provider đã được cung cấp).

Đặc tả dịch vụ của bạn đã thay đổi và phương thức xác nhận tính hợp lệ bây giờ nhận một ClaimFolder thay cho một Claim làm đầu vào. May mắn thay, sự thay đổi này không quá gây cản trở cho các nhà phát triển, những người có thể đã bắt đầu mã hóa, vì bản chất của mẫu Composite (ở đây một ClaimFolder vẫn là một Claim). Tuy nhiên, lưu ý rằng không phải tất cả các mẫu thiết kế này sẽ có thuộc tính đó và bạn nên luôn luôn suy nghĩ về tác động mà việc sử dụng một mẫu thiết kế gây ra với các phần khác của thiết kế đó.

Trong phần kế tiếp, bạn sẽ truy tìm nguồn gốc các quyết định thiết kế tới tận các yêu cầu.


Khả năng truy theo vết và xuất bản

Truy tìm nguồn gốc quyết định thiết kế cho yêu cầu

Trong Phần 1 của loạt bài viết này, bạn đã tìm hiểu về sự tích hợp Rational Software Architect cung cấp RequisitePro (sản phẩm quản lý các yêu cầu). Bây giờ bạn đã đưa ra quyết định thiết kế là sử dụng mẫu phức hợp để giải quyết yêu cầu SR8 Usability, bạn sẽ ghi lại quyết định này bằng cách thêm một vết (liên kết) giữa CompositeClaim Pattern Instance và yêu cầu SR8 Usability.

Tham khảo phần Tài nguyên nếu bạn cần tải về và cài đặt một phiên bản dùng thử của Rational RequisitePro.

  1. Đầu tiên, trích xuất zipped-up RequisitePro project vào vị trí mà bạn chọn.
  2. Để mở phối cảnh yêu cầu (Requirement perspective), hãy nhấn vào Open Perspective > Other từ trình đơn Window. Sau đó chọn Requirement và nhấn OK.
  3. Từ Requirement Explorer, nhấn vào Mở một dự án RequisitePro (Open a RequisitePro Project) (Hình 19).
Hình 19. Mở một dự án RequisitePro Project
Dự án RequisitePro Project
  1. Đặt con trỏ tới tệp tin .rqs trong dự án mà bạn vừa trích xuất. Nhấn vào Open. Khi cửa sổ Đăng nhập dự án (Project Logon) xuất hiện, nhấn OK.
  2. Dự án Claims Processing Requirements bây giờ sẽ mở ra. Mở rộng nó và sau đó mở rộng Software Requirements.
  3. Chọn SR8 Usability, như được hiển thị trong Hình 20.
Hình 20. Yêu cầu SR8 Usability
Yêu cầu SR8 Usability
  1. Trong Properties, bạn có thể xem các thuộc tính của yêu cầu (ví dụ, trạng thái được phê duyệt và mức ưu tiên cao) và cả các văn bản của nó.
  2. Trong Model Explorer, chọn CompositeClaim Pattern Instance (trong gói Messages).
  3. Kéo CompositeClaim tới SR8 Usability, như được hiển thị trong Hình 21.
Hình 21. Kết hợp Phần tử mô hình (Model Element) với Yêu cầu (Requirement)
Phần tử mô hình kết hợp với Requirement

Lưu ý rằng bây giờ mối liên kết (khả năng truy vết) đã được biểu diễn trong mô hình (Hình 22):

  • Phần tử CompositeClaim Pattern Instance được vẽ thêm một mũi tên.
  • Yêu cầu SR8 Usability được vẽ thêm một mũi tên.
  • Trong khung nhìn Vết yêu cầu (Requirement Trace), có một vết từ CompositeClaim trong SR8 Usability.
Hình 22. Vết yêu cầu
Vết yêu cầu

Bạn đã liên kết một phần tử mô hình hiện có đến một yêu cầu. Lưu ý rằng cũng có thể tạo ra các phần tử mô hình trực tiếp từ các yêu cầu (ví dụ, bằng cách kéo một yêu cầu tới một gói trong model explorer).

Xuất bản mô hình

Một khía cạnh quan trọng của việc sử dụng UML là ở chỗ nó cung cấp một phương tiện để bạn có thể giao tiếp với những người khác theo một cách một chuẩn hóa, không mập mờ. Tuy nhiên, bạn có thể gặp tình huống mà ở đó không phải tất cả mọi người trong nhóm (hoặc nhóm mở rộng) đều có Rational Software Architect. Trong phần này, bạn sẽ tạo ra các tài liệu dựa trên các thông tin được nắm giữ trong các mô hình mà bạn đã tạo ra. Chúng tôi sẽ mô tả hai tùy chọn có sẵn để xuất bản thông tin:

  • Xuất bản trang Web.
  • Báo cáo sơ đồ

Quay trở lại phối cảnh mô hình hóa. Mô hình của bạn bây giờ trông giống như Hình 23 trong Model Explorer.

Hình 23. Mô hình thiết kế dịch vụ
Mô hình thiết kế dịch vụ

Các thay đổi dễ nhận thấy đối với mô hình kể từ khi bạn bắt đầu là:

  • Có một cá thể mẫu CompositeClaim trong Messages, cũng như các lớp ClaimFolder và ElementaryClaim. Ba lớp có các từ khóa từ mẫu Composite.
  • Cá thể mẫu CompositeClaim được liên kết đến một yêu cầu (biểu tượng mũi tên).
  • Hoạt động IClaimValidator, trong các đặc tả dịch vụ, bây giờ nhận một tham số có tên là claimFolder làm tham số đầu vào.

Xuất bản trang Web

  1. Trong Model Explorer, hãy chắc chắn rằng Claims Processing Service Design Model.emx được chọn.
  2. Nhấn vào Publish > Web trong trình đơn Modeling.
  3. Trong hộp thoại Publish to Web, chọn Tự động hiển thị kết quả đầu ra đã xuất bản (Automatically display published output) và duyệt để chọn một thư mục để xuất bản tới đó.
  4. Nhấn vào OK (Hình 24).
Hình 24. Hộp thoại Xuất bản trang Web
Hộp thoại Xuất bản trang Web

Sau một vài giây, các tài liệu sẽ được tạo ra và một trang web sẽ mở ra trong trình duyệt Web yêu thích của bạn.

  1. Nhấn vào liên kết Claims Processing Service Design Model. Bạn sẽ thấy giống như Hình 25.
Hình 25. Xuất bản trang Web
Xuất bản trang Web

Nếu bạn chọn một gói cụ thể trong ô của đỉnh bên trái, sau đó chỉ các phần tử thuộc gói này sẽ hiển thị ở ô dưới đáy bên trái.

Duyệt các tài liệu đã tạo ra tùy ý bạn.

Báo cáo sơ đồ

  1. Quay trở lại Rational Software Architect, trong Model Explorer, hãy chắc chắn rằng Claims Processing Service Design Model.emx được chọn.
  2. Nhấn vào Publish > Web trong trình đơn Modeling.
  3. Trong hộp thoại Generate Report, chọn Model Diagram Report khi báo cáo tạo ra.
  4. Chọn Luôn luôn hiển thị kết quả đầu ra đã xuất bản (Always display published output) và duyệt để chọn một thư mục để xuất bản vào thư mục này.
  5. Nhấn vào OK (Hình 26).
Hình 26. Hộp thoại Diagram Report
Hộp thoại Diagram Report

Sau một vài giây, các tài liệu sẽ được tạo ra và một trang Web sẽ mở ra trong trình duyệt Web yêu thích của bạn.

  1. Nhấn vào liên kết Model Diagram Report và chắc chắn rằng bạn mở tệp tin pdf.
  2. Bản báo cáo này sẽ chỉ chứa các sơ đồ (Hình 27). Duyệt tài liệu đã tạo ra tùy ý bạn.
Hình 27. Báo cáo sơ đồ
Báo cáo sơ đồ

Tóm tắt

Kết luận

Xin chúc mừng, bạn đã hoàn thành hướng dẫn này!

Mô hình của bạn bây giờ sẽ trông giống như Hình 23.

Trong hướng dẫn này bạn đã sử dụng Rational Software Architect để giải quyết các yêu cầu bằng cách sử dụng các mẫu thiết kế. Bạn đã khởi đầu với một mô hình thiết kế dịch vụ và bạn đã kết thúc với một mô hình thiết kế dịch vụ được cải tiến nâng cao.

Tiếp theo từ Phần 2, nơi mà bạn đã tìm hiểu về UML và UML 2 Profile (Lược tả UML 2) cho Các dịch vụ phần mềm, trước hết bạn đã tìm hiểu về các tài sản phần mềm có thể dùng lại, đặc tả Reusable Software Asset (RAS) và các mẫu. Sau đó, bạn đã duyệt qua kho lưu trữ các tài sản có thể dùng lại của developerWorks IBM. Sau đó, bạn nâng cao mô hình thiết kế từ Phần 2 bằng cách sử dụng mẫu thiết kế phức hợp Gang of Four. Rồi, bạn truy tìm nguồn gốc quyết định thiết kế theo yêu cầu mà bạn đã sử dụng mẫu. Cuối cùng, bạn xuất bản mô hình thiết kế dịch vụ của bạn.

Lời cảm ơn

Các tác giả muốn cảm ơn Grant Larsen và Eoin Lane về việc đóng góp các hiểu biết sâu sắc có giá trị của họ vào định nghĩa về các tài sản và các mẫu.

Các bước tiếp theo

Mô hình dịch vụ của bạn bây giờ trông đã rất chỉnh trang ở mức thiết kế trừu tượng hóa của UML. Trong Phần 4 của loạt bài viết này, bạn sẽ tìm hiểu làm thế nào để biến đổi mô hình này thành các mô hình với mức trừu tượng hóa khác, trước tiên là Web Services Description Language (WSDL) và lược đồ XML (XSD) và sau đó là dịch vụ Web Java™ 2 Platform, Enterprise Edition (J2EE™ Platform).

Cũng có thể tạo ra các tài sản phần mềm có thể dùng lại của riêng bạn với Rational Software Architect, khi chúng ta sẽ thảo luận trong một phần khác của loạt bài viết này.


Các tải về

Mô tảTênKích thước
Part 2. Rational Project InterchangeSOA-Design-Part2-Intrchng.zip6 KB
Part 3. Rational Project InterchangeSOA-Design-Part3-Intrchng.zip10 KB
RequisitePro ProjectClaimsProcessingRequirements.zip154 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=423455
ArticleTitle=Thiết kế các dịch vụ SOA với Rational Software Architect, Phần 3: Sử dụng các tài sản và các mẫu trong thiết kế của bạn
publish-date=08282009