Mô hình hóa hướng quy trình cho SOA, Phần 3: Mô hình hóa ca sử dụng

Làm thế nào để định nghĩa các ca sử dụng phù hợp với SOA

Học làm cách nào các nhà phân tích nghiệp vụ và kiến trúc sư có thể xác định các ca sử dụng phù hợp với kiến trúc hướng dịch vụ (Service-Oriented Architecture - SOA). Bài này mô tả một kỹ thuật mô hình hóa ca sử dụng dựa trên kỹ thuật mô hình hóa xử lý đã được mô tả ở phần 1. Trong loạt bài này, việc học về một kỹ thuật phân rã quy trình nghiệp vụ mới có thể giúp bạn xác định các quy trình nghiệp vụ phù hợp với kiến trúc hướng dịch vụ (SOA).

Mike Evans, Tư vấn cao cấp về quy trình kinh doanh, IBM

Photo of Mike EvansMike là một nhà phân tích nghiệp vụ của IBM Global Business Services Anh quốc. Ông ta làm việc với các khách hàng về các chương trình tích hợp hệ thống để giúp họ phát triển các yêu cầu để hỗ trợ điều kiện để hỗ trợ nghiệp vụ của họ và xác định các giải pháp phù hợp



Ruud Schoonderwoerd, Tư vấn, IBM

Ruud Schoonderwoerd photoRuud Schoonderwoerd là một cố vấn quản trị và kiến trúc sư công nghệ thông tin (IT) của IBM Global Business Services ở Anh Quốc. Ông ta làm về các chương trình công nghệ thông tin lớn ở phía khách hàng IBM, tập trung vào BPM, SOA và các phương thức phân phối



12 06 2009

Giới thiệu

Phần 4 sẽ dùng một ca sử dụng ví dụ để minh họa các khái niệm trong ba phần đầu tiên.

Trong các phần 1 và 2 của loạt bài này, bạn đã học một phương pháp để xác định các mô hình xử lý gần phù hợp với kiến trúc hướng dịch vụ (SOA) mà dựa trên kiến trúc đích. Các mô hình đó tỏ ra có độ chính xác tốt hơn để triển khai giải pháp thực tế. Bài viết này mở rộng nguyên tắc cho định nghĩa các mô hình ca sử dụng (use case). Học về một kỹ thuật phân rã ca sử dụng dựa trên mô hình hóa quy trình, làm cho các ca sử dụng gần phù hợp với kiến trúc đích.

Tại sao chúng ta cần SOA phù hợp với các mô hình ca sử dụng

Công việc mô hình hóa ca sử dụng được dùng trong các dự án công nghệ thông tin để nắm bắt các yêu cầu của một hệ thống. Các mô hình ca sử dụng dựa trên các mẫu có thể tái sử dụng, các mấu này nên chuyển một cách tỉ mỉ sang một kiến trúc nào đó chẳng hạn như SOA vốn hỗ trợ tốt tính tái sử dụng. Không may thay, hầu hết các kỹ thuật mô hình hóa ca sử dụng được dùng ngày nay đều dựa trên các khái niệm trước SOA và quản lý quy trình nghiệp vụ (business process management - BPM), do vậy chúng có các hệ quả sau:

  • Các ca sử dụng thường xuyên được dịch quá thiên thành các thành phần kỹ thuật (chẳng hạn như các luồng và các dịch vụ), điều này dẫn đến các hệ thống được thiết kế kém nên không cho phép thể hiện được các lợi ích của SOA.
  • Ngoài sự cần thiết, các thiết kế thường bao gồm cả sự làm lại cấu trúc ban đầu được định nghĩa trong mô hình ca sử dụng, các hệ thống mềm dẻo mà triển khai các chức năng không thể dễ dàng lần vết lại theo các yêu cầu. Thời gian sống và lợi ích của các ca sử dụng ban đầu bị giảm đi. Quản lý mong muốn khách hàng, sự hiệu quả của quy trình phân phối IT, khả năng lần vết đầu cuối, kiểm thử và tái sử dụng trong tương lai cũng cần phải bàn đến.

Một mô hình chức năng gần với với kiến trúc hơn có nhiều lợi ích. Nó thuận tiện hóa giao tiếp giữa những người nắm nghiệp vụ với các kỹ sư công nghệ, tăng tốc thời gian giao dự án, tăng đáng kể khả năng tái sử dụng. Tái sử dụng yêu cầu có thể trực tiếp dẫn đến tái sử dụng trong kiến trúc.

Các mô hình bạn phát triển với kỹ thuật được mô tả trong bài này có thể vẫn có giá trị và hữu dụng sau khi khi bàn giao sản phẩm. Chúng sẽ tương ứng với các thành phẩm hệ thống thực sẽ được giao, chẳng hạn như các dịch vụ, các quy trình hoặc các thành phần giao diện người dùng. Các mô hình ca sử dụng có thể được dùng tham khảo cho các dự án mới để tìm sự tái sử dụng ngoài vòng đời của một dự án đơn lẻ. Thông thường, các ca sử dụng kết quả tương tự các dịch vụ, vì vậy đặc tả của các ca sử dụng là bước đầu tiên trong đặc tả các dịch vụ

SOA phù hợp với mô hình hóa ca sử dụng.

Hình 1 biểu diễn cấu trúc phân rã quy trình đưa ra trong phần 1. Mỗi quy trình (process) thuộc một trong các lớp (layer). Các quy trình chỉ có thể gọi hoặc nhìn thấy (subcrible) các sự kiện của các quy trình con trong các lớp phía dưới, như là được chỉ ra bởi các mũi tên. Mỗi quy trình không thể biết các quy trình khác trong các lớp bên trên.

Hình 1. Khung làm việc phân rã quy trình
Khung làm việc phân rã quy trình

Các quy trình sử dụng (xử lý sự kiện - consumer process) và tất cả các quy trình trong các lớp phía dưới được triển khai trong giải pháp công nghệ. Lớp quy trình làm bằng tay hoặc "kinh nghiệm (trải nghiệm) khách hàng" - "customer experience" là một lớp ảo biểu diễn tất cả các hành động không tự động của nghiệp vụ, nó thể hiện làm cách nào các quy trình hỗ trợ hệ thống phù hợp với nội dung này.

Các mối quan hệ "bao gồm - Includes" và "Mở rộng - Extends"

Có nhiều sự mơ hồ xung quanh những khác biệt giữa quan hệ Include và Extend trong mô hình ca sử dụng, chúng có nghĩa là gì và nên sử dụng thế nào. Điểm khác biệt cơ bản giữa chúng là ở chỗ ý nghĩa nằm bên trong của quan hệ, và thật là khác biệt khi xác định dùng cái nào thì đúng hơn trong một tình huống được đưa ra.

Include (Bao gồm)

Ca sử dụng A bao gồm ca sử dụng B có nghĩa là A "biết về" B. Ca sử dụng B không biết về ca sử dụng nào bao gồm nó. Trong luồng của ca sử dụng A, ca sử dụng B được thực thi trọn vẹn trước khi ca sử dụng A tiếp tục (mặc dù chúng ta có thể thấy khác biệt một chút trong trường hợp gọi kiểu "thực thi rồi quên đi") ca sử dụng A sau đó phải giải quyết chính xác các đầu ra (output) và các hậu điều kiện của ca sử dụng B (kể cả khi nó thành công hay thất bại). Quan hệ Include nên được dùng để tránh lặp cùng nội dung trong các ca sử dụng - hay nói cách khác là để trích các chức năng thông dụng và cho phép nó được tái sử dụng.

Extends (Mở rộng)

Khi ca sử dụng B mở rộng ca sử dụng A, có nghĩa là B "biết về" A. Ca sử dụng A không có hiểu biết gì về các ca sử dụng mở rộng nó. Tuy nhiên ca sử dụng A phải định nghĩa một hoặc nhiều "điểm mở rộng" trong luồng của nó. Ca sử dụng mở rộng B 'lắng nghe" ca sử dụng A và được gọi ở một điểm mở rộng xác định. Đối lập với quan hệ "Include", ca sử dụng A bây giờ tiếp tục mà không đợi ca sử dụng B hoàn thành (vì nó không để ý lời gọi của nó), và tương tự không giải quyết bất cứ hậu điều kiện thành công hay thất bại. Quan hệ Extend được sử dụng ít thông dụng hơn, nhưng nó có thể rất hữu ích khi định nghĩa chức năng để thêm vào một hệ thống sẵn có, hoặc quan trọng hơn trong ngữ cảnh của cách tiếp cận này, định nghĩa một quy trình được định hướng bằng sự kiện.

Bây giờ bạn có thể dùng cấu trúc phân rã quy trình để điều khiển việc xác định các yêu cầu (requirement) như thế nào. Mỗi quy trình trong mô hình được xác định rõ dưới dạng ca sử dụng -- cấu trúc ca sử dụng kết quả phản ánh cấu trúc phân rã quy trình.

  • Mỗi quy trình sẽ đáp lại một ca sử dụng hệ thống (trừ các quy trình bằng tay và kinh nghiệm khách hàng nằm ngoài biên hệ thống).
  • Lời gọi một quy trình con tương tự như các liên kết include (xem khung bên cạnh), nó cho phép quy trình con được định nghĩa trong một ca sử dụng tách rời mà có thể được tái sử dụng bởi các quy trình khác trong các lớp ở trên.
  • Các liên kết extend ca sử dụng có thể thích hợp để hỗ trợ các khái niệm kiến trúc điều khiển sự kiện (event-driven)

    Ví dụ, một quy trình ngắn sinh ra một sự kiện ảnh hưởng đến việc khởi chạy quy trình dài. Quy trình dài mở rộng (extend) quy trình ngắn và quy trình ngắn không biết về quy trình dài (xem SOA dựa trên sự kiện ở Phần 1).

  • Các activity (hành động) tự động tương đương với các bước trong các ca sử dụng trong các lớp cao hơn, thông qua đó có thể có các ngoại lệ (được mô tả sau).

Hình 2 thể hiện việc áp dụng những kết quả cơ bản này trong một cấu trúc ca sử dụng cũng được phân lớp tương tự như mô hình hóa quy trình.

Hình 2. Mô hình ca sử dụng được phân lớp
Mô hình ca sử dụng được phân lớp

Mỗi ca sử dụng định nghĩa một quy trình tương ứng ở mức chi tiết hơn. Nó cũng định nghĩa các đặc điểm của dịch vụ sẽ được sử dụng để gọi quy trình đó. Ví dụ, tiền và hậu điều kiện, các đầu vào (input) và đầu ra (output) của ca sử dụng định nghĩa các phụ thuộc dịch vụ, biên và các yêu cầu dữ liệu.

Các quy trình bằng tay (manual process) và các quy trình kinh nghiệm khách hàng (customer-experience process)

Lớp "Các quy trình bằng tay (manual) và các quy trình kinh nghiệm khách hàng" ở phần trên cùng của hình 1 được dùng để thiết lập ngữ cảnh cho các quy trình trong các lớp thấp hơn. Nó cũng được dùng để biểu diễn làm thế nào các ca sử dụng hệ thống phù hợp với quy trình nghiệp vụ tổng thể. Các quy trình trong lớp này nằm ngoài biên hệ thống và không mô tả các chức năng hệ thống, bởi vậy không cần thiết phải có ca sử dụng hệ thống cho nó.

Tóm tắt quy trình

Cùng với các quy trình bằng tay (manual) và kinh nghiệm khách hàng và các mô hình cả sử dụng, một công cụ giao tiếp hữu ích khác có thể nói đến là bản tóm lược quy trình đầu cuối để chỉ ra trình tự ca sử dụng tổng thể. Bản tóm lược hữu ích bởi vì:

  • Mô hình ca sử dụng mang tính chất tĩnh; nó không hiển thị trình tự các ca sử dụng thực thi. Nó chỉ đơn giản là mô hình hóa thứ tự có thể thường xuyên được tham chiếu nhưng nó không thể dùng trong trường hợp các mô hình phức tạp hơn.
  • Các quy trình kinh nghiệm khách hàng tuân theo nguyên lý xếp lớp nên không hiển thị bất cứ các quy trình nào ở dưới lớp tiêu dùng. Giá trị của nó hiển thị các đối tượng tiêu dùng bên ngoài "nhìn" thấy gì, nhưng nó không có tác dụng như là một bản tóm tắt cho những người liên quan là những người sẽ xem lại mô hình dưới dạng tổng thể.

Ký hiệu được chọn để tóm tắt có thể khác nhau, vì thế bạn nên cẩn thận khi dùng BPMN để diễn tả sự chính xác không mà nằm ở đó. Ví dụ, một ký hiệu kiểu chuỗi có thể được dùng.

Các ca sử dụng quy trình tiêu dùng

Các quy trình tiêu dùng (xem Hình 1) chuyển một cách tiện lợi sang khung nhìn truyền thống của ca sử dụng vì chúng không được tập trung vào các tương tác giữa cá tác nhân (những người dùng cuối hoặc các hệ thống ngoài) và hệ thống. Các ca sử dụng này bao gồm các tiến trình nghiệp vụ có thể tái sử dụng (chạy thời gian ngắn hoặc dài) trong các lớp dưới đây.

Các ca sử dụng chạy thời gian ngắn hoặc dài.

Phần 1 đã giải thích rằng các tiến trình chạy thời gian ngắn hoặc dài được thực thi trong lớp quy trình nghiệp vụ của kiến trúc, một cách tiềm năng bởi các cơ chế phối hợp quy trình nghiệp vụ. Đối với cả các ca sử dụng quy trình chạy ngắn hay dài, không có các tác nhân chính (Primary Actor); chúng luôn được gây ra bởi các ca sử dụng khác và không bao gồm trực tiếp vào các tương tác người dùng nào. Tất cả các bước sẽ mô tả xử lý hệ thống, hoặc bao gồm các ca sử dụng khác (ví dụ, một ca sử dụng quy trình dài có thể bao gồm một ca sử dụng hành vi con người).

Các ca sử dụng quy trình ngắn cũng có thể được mở rộng bởi một ca sử dụng quy trình dài như là một kết quả của một sự kiện chung sinh ra. Bạn nên chú ý rằng, trong biểu đồ quy trình và luồng ca sử dụng, nơi mà một quy trình được gọi trong chế độ chạy-và-quên, vì một quan hệ include truyền thống chỉ ra rằng ca sử dụng cần phải hoàn thành trước khi tiếp tục.

Phối hợp quy trình so với việc nối kết (chaining)

Một lỗi thường gặp trong mô hình hóa ca sử dụng là định nghĩa các quan hệ giữa các ca sử dụng để mô tả trình tự chúng được thực thi. Ví dụ, bạn phải đăng nhập vào hệ thống trước khi gửi (submit) một đơn hàng. Sự phụ thuộc giữa các ca sử dụng nên được mô tả bằng các tiền và hậu điều kiện ca sử dụng hơn là mô hình hóa dưới dạng một quan hệ (Đăng nhập không nên bao gồm gửi đơn hàng). Việc liên kết các ca sử dụng với nhau để mô tả quy trình nghiệp vụ thỉnh thoảng được gọi là kết nối (chaining). Nó không phản ảnh hành vi hệ thống thực sự, nó dẫn tới các mô hình ca sử dụng khó mà hiểu và bảo trì, và nó ẩn giấu các khu vực nơi hệ thống thực sự phối hợp các quy trình

Nơi mà hệ thống tích cực quản lý phụ thuộc giữa các ca sử dụng bằng cách gọi chúng theo thứ tự (ví dụ: trong một quy trình luồng công việc), có thể và nên được mô hình hóa như là một ca sử dụng bao gồm các ca sử dụng khác trong một trình tự được chỉ ra. Hệ thống hoạt động như là một bộ điều khiển quy trình tổng quát chứ không phải là người dùng cuối.

Một ca sử dụng tương đương một quy trình chạy dài đối lập với các luật truyền thống của xác định ca sử dụng (một tác nhân, một địa điểm, hoặc một thời điểm). Bạn có thể nghĩ về một quy trình dài như là một quy trình luồng công việc; nó có thể đợi một sự kiện bên ngoài xảy ra, hoặc gọi dựa trên một hoặc nhiều người để thực thi một ca sử dụng. Tuy nhiên, thông tin cần được xác định cho một quy trình dài cũng tương tự như chúng được yêu cầu trong việc xác định các đặc tả ca sử dụng khác. Bằng cách biểu diễn quy trình dài như là một ca sử dụng, mô hình ca sử dụng rõ ràng biểu diễn các hành động khác được phối hợp bởi quy trình chạy dài (xem khung bên cạnh).

Một quy trình chạy dài gây ra bởi một sự kiện được mô tả với quan hệ mở rộng (extend). Thêm vào đó, để thiết lập sự bắt đầu của một quy trình dài, hoặc một sự kiện cũng có thể nhắc một quy trình chạy thời gian dài mà đợi tiếp tục. Chú ý rằng quan hệ mở rộng (extend)cũng nên được dùng để biểu diễn liên kết tiếp theo. Bằng cách này, tất cả các phụ thuộc dựa trên sự kiện được biểu diễn trong mô hình ca sử dụng. Hình 3 thể hiện các ví dụ về các cách dùng khác nhau của quan hệ mở rộng (extend).

Hình 3. Các cách dùng quan hệ mở rộng
Các ví dụ sử dụng khác nhau của quan hệ extend

Đây là biến thể nhỏ về ngữ nghĩa truyền thống của quan hệ extend, điều này cần thiết bởi vì các quy trình dài phá vỡ luật "một tác nhân, một địa điểm, một thời gian" thông dụng. Có lẽ, một thuật ngữ có nghĩa hơn trong trường hợp này đó là "được nắm thông tin bởi" hoặc "đợi", tuy nhiên nên dừng việc đề xuất stereotype mới ở đây.

Các ca sử dụng hành động con người

Giống với các quy trình tiêu thụ, các ca sử dụng hành động con người mô tả các tương tác giữa một người dùng và hệ thống. Một hành động con người, thỉnh thoảng có thể gọi là một hành vi luồng công việc, được thiết lập bởi một quy trình thời gian dài và thường bắt đầu bằng việc người dùng chọn một hành động từ danh sách hành động (worklist). Một khi người dùng đã hoàn thành công việc, tất cả các quy trình nghiệp vụ theo sau nên được xử lý bởi các quy trình dài. Phạm vi của hành động con người nên được giới hạn trong tương tác người dùng. Đầu ra của ca sử dụng hành động con người (thành công hay không) phải được phát hiện và xử lý bởi các ca sử dụng có quy trình dài mà được bao gồm bên trong nó.

Các ca sử dụng hành động tự động

Các luật nghiệp vụ
Các luật nghiệp vụ được định nghĩa cùng với các ca sử dụng nhằm cung cấp cơ chế mạnh mẽ để định nghĩa các logic nghiệp vụ thông qua mô hình ca sử dụng. Các luật nghiệp vụ biểu diễn logic hệ thống, thường để thực thi một trong những thứ sau:

  • Sự thừa kế của dữ liệu (chẳng hạn tính tiền thù lao)
  • Ra các quyết định tự động (kiểm tra sự thích hợp hoặc xác minh một giao tác)

Các luật nghiệp vụ được làm tài liệu tách rời các ca sử dụng (để tái sử dụng), với mỗi luật tham chiếu chéo từ các bước ca sử dụng mà dùng nó.

Với tiếp cận này, các luật nghiệp vụ tương ứng với các hành động tự động trong mô hình xử lý.

Về tổng thể, các hành động (acitivity) tự động tương ứng với các bước trong luồng ca sử dụng (ngữ cảnh chính và các luồng chuyển đổi). Các hành động tự động có thể tương ứng với các luật nghiệp vụ được tham chiếu trong các ca sử dụng được tái sử dụng hoặc các thao tác dữ liệu. Các hành động tự động như vậy thường được "nghiền nhỏ" thật tốt để chứng thực một ca sử dụng của họ.

Tuy nhiên trong vài trường hợp, có thể có ích khi định nghĩa một hành động tự động dưới dạng một ca sử dụng tách rời. Ví dụ, một giao diện với một hệ thống ngoài mà bao gồm các tương tác phức tạp có thể phải yêu cầu một số bước hoặc các luồng (flow) chuyển để định nghĩa. Những điều đó cần phải được làm tài liệu dưới dạng các ca sử dụng tách rời để dễ dàng tái sử dụng giao diện.

Từ các mô hình xử lý và ca sử dụng tới các mô hình dịch vụ

Như là bạn đã thấy ở phần 1, các quy trình dài ngắn và các hành động tự động đều được gọi bởi một dịch vụ. Các quy trình tiêu dùng thường là được gọi (chúng dùng các dịch vụ), trừ khi quy trình được thể hiện ra cho một quy trình dùng bên ngoài, như là một đối tác nghiệp vụ dùng một giao diện Nghiệp vụ tới Nghiệp vụ.

Nếu bạn áp dụng kỹ thuật mô hình hóa ca sử dụng được mô tả trong bài này, các ca sử dụng (trừ ca sử dụng tiêu thụ) sẽ đáp lại các dịch vụ theo cùng cách. Nói cách dễ hiểu hơn, các đặc tả ca sử dụng có chung các đặc điểm với các đặc tả dịch vụ; các đặc tả ca sử dụng có thể được xem như là một phiên bản trước đó của đặc tả dịch vụ. Cả hai có:

  • Một cái tên duy nhất
  • Một mục tiêu
  • Các đầu vào đầu ra
  • Các tiền và hậu điều kiện
  • Mộ luồng xử lý liên kết
  • Các phụ thuộc vào các ca sử dụng khác hoặc các dịch vụ khác

Tư tưởng tổng hợp

Các quy trình, các dịch vụ và các thao tác dịch vụ

Các thuật ngữ "quy trình" và "dịch vụ" thường được dùng thay thế cho nhau: cả hai đều đáp ứng mục tiêu đặc thù và có các đầu vào đầu ra được định nghĩa rõ ràng. Tuy nhiên chúng có những sự khác biệt rõ ràng về định nghĩa:

  • Một dịch vụ định nghĩa cái gì được cung cấp và ẩn đi làm thế nào. Nó tập trung vào mục đích và việc thể hiện giao diện ra ngoài thay vì cách cài đặt.
  • Một quy trình (nghiệp vụ) định nghĩa các bước và luồng cần được cung cấp cho một dịch vụ. Một mô hình quy trình có thể được dùng để định nghĩa làm thế nào một dịch vụ có thể được cung cấp. Các bước đơn lẻ trong một quy trình có thể quay sang gọi các dịch vụ khác (lớp thấp hơn).

Tài liệu SOA thường đề cập thuật ngữ "thao tác dịch vụ - service operation”. Nói một cách chính xác, khi gắn vào chuẩn Web services WSDL, một dịch vụ là một nhóm các thao tác dịch vụ. Trong bài viết của chúng ta, chúng ta không áp dụng định nghĩa nghiêm ngặt nào: bất kỳ khi nào chúng tao đề cập đến từ dịch vụ, cũng có thể chuyển sang các thao tác dịch vụ; tuy nhiên điều này có nghĩa là một bước thêm để định nghĩa sự phân rã của các dịch vụ bên trong các định nghĩa dịch vụ vẫn cần thiết.

Trong bài này bạn đã học về cách làm thế nào kỹ thuật phân rã quy trình trong phần 1 và 2 của loạt bài này có thể được mở rộng ra các ca sử dụng. Việc xác định các ca sử dụng được điều khiển bởi các mô hình quy trình nằm trong khuôn khổ của một SOA. Các yêu cầu, như là được chỉ ra rõ ràng trong các ca sử dụng, được đem gần đến cài đặt hơn trong dạng của các dịch vụ của một SOA.

Phân tích nghiệp vụ và kiến trúc CNTT

Nếu mô hình hóa ca sử dụng hướng quy trình phạm vi SOA tốt thì kết quả thu được sẽ là đặc tả yêu cầu chính xác hơn cho giải pháp thực tế. Bởi liên kết gần nên tốt nhất là được cùng làm bởi nhà phân tích nghiệp vụ và một kiến trúc sư, hoặc bởi những người có kỹ năng tốt về cả hai mảng. Chúng ta dự đoán rằng áp dụng các kỹ thuật giống như vậy sẽ làm mờ đi ranh giới giữa vai trò của phân tích nghiệp vụ và kiến trúc. Những người có cả hai kỹ năng sẽ "đắt hàng hơn"

Top-down (trên xuống) và bottom-up (dưới lên)

Cách tiếp cận mô hình hóa ca sử dụng có thể coi như là tiếp cận top-down trong thiết kế SOA, trong khi đó các thao tác dịch vụ được xác định dựa trên nơi nào họ cần. Trong ngữ cảnh phương pháp của IBM cho mô hình hóa và kiến trúc hướng dịch vụ (SOMA), nó có thể là một phần của bước phân rã miền (Domain Decomposition).

Nhà phân tích nghiệp vụ hoặc kiến trúc sư đưa ra lựa chọn đúng về các dịch vụ phụ thuộc vào các nhân tố khác, chẳng hạn như các dịch vụ được hỗ trợ bởi các hệ thống đã tồn tại của một tổ chức. Trong một môi trường SOA thực thụ, thông tin về các dịch vụ luôn sẵn sàng trong kho dịch vụ và có thể được bao gồm trong các mô hình yêu cầu chức năng. Trong các môi trường ít nghiêm túc hơn, cần phải có một phép phân tích hệ thống để hiểu đầy đủ về những dịch vụ gì đã sẵn sàng. Trong SOMA, điều này có thể được thực hiện bởi phép phân tích hệ thống có sẵn (Existing System Analysis).

Quay trở lại Phần 4: phần này sẽ sử dụng một ca sử dụng để minh họa các kỹ thuật trong ba phần đầu tiên.


Lời cảm ơn.

Các tác giả gửi lời cảm ơn tới Richard Solly, Pete Cripps, Bruce Anderson và Sunny Shah vì những phản hồi mang tính xây dựng đối với những phiên bản đầu tiên của bài viết này.

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=SOA và dịch vụ Web
ArticleID=395576
ArticleTitle=Mô hình hóa hướng quy trình cho SOA, Phần 3: Mô hình hóa ca sử dụng
publish-date=06122009