intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE

Thiết kế các dịch vụ SOA với Rational Software Architect, Phần 3

Chia sẻ: Nguyen Nhi | Ngày: | Loại File: PDF | Số trang:43

137
lượt xem
21
download
 
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

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 Bertrand Portier, Kiến trúc sư IT, IBM Lee Ackerman, Giám đốc tiếp thị, IBM Tóm tắt: Tìm hiểu cách làm thế nào để tạo ra thiết kế dịch vụ của serviceoriented 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)...

Chủ đề:
Lưu

Nội dung Text: Thiết kế các dịch vụ SOA với Rational Software Architect, Phần 3

  1. 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 Bertrand Portier, Kiến trúc sư IT, IBM Lee Ackerman, Giám đốc tiếp thị, IBM Tóm tắt: 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. 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.
  2. 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
  3. 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ề đầu trang 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. Về đầu trang 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
  4. 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. Về đầu trang 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. Về đầu trang 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 •
  5. 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
  6. 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.
  7. Đừ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.
  8. 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.
  9. Đặ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.
  10. 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. Về đầu trang 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).
  11. Hình 1. 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.
  12. Hình 2. Mở một phối cảnh mới 3. 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. 4. 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.
  13. Hình 3. Mở 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.
  14. 2. Chọn Internet > Proxy Settings. 3. Nhập các thông tin cần thiết. 4. Nhấn Apply và OK. 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 4. 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).
  15. Hình 5. Kho lưu trữ RAS của developerWorks 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
  16. 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 2. Trong trường Keyword, gõ: UML WSDL. 3. Nhấn vào Search. 4. 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.
  17. Hình 7. Các kết quả tìm kiếm tài sản 5. Trong khung nhìn Asset Explorer, mở rộng thư mục phân tích trong kho lưu trữ IBM Rational developerWorks. 6. Chọn UML to WSDL Transform. 7. 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.
  18. 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.
  19. Hình 8. 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).
  20. 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 2. Để 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. 3. 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
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

 

Đồng bộ tài khoản
2=>2