93
Hình 3-13: Đồ thị biểu diễn tiến trình BPMN và kết quả của phép duyệt theo chiều sâu (DFS). Ở bước 1, DFS được sử dụng để phát hiện các vùng chu trình và vùng bất chu trình.
Hình 3-14: Các vùng đã phát hiện được sau bước 1. Ở đây phát hiện được ba vùng: R2 là vùng chu trình, còn R1 và R3 là hai vùng bất chu trình.
94
Hình 3-15: Các vùng đã phát hiện được sau bước 2 (một số nhãn cho các nút từ các hình trước đã cố tình được bỏ bớt từ hình này trở đi nhằm làm cho các hình vẽ đỡ rắc rối
hơn)
Hình 3-16: Vùng cuối cùng được trả về R sau các bước cuối 3, 4 và 5
Định lý 3-8: Giải thuật 3-2 là đúng đắn và đầy đủ.
Chứng minh:
Ta cần chứng minh tính đúng đắn và chứng minh tính đầy đủ.
Tính đúng đắn: Chúng ta sẽ chỉ ra rằng giải thuật trên sẽ phát hiện đúng bất kỳ mẫu có cấu trúc đầy đủ nào và nó trả về đúng vùng cần phát hiện.
Để tìm kiếm các vùng (cả chu trình và bất chu trình), giải thuật dựa trên hai giải thuật nổi tiếng, nên tính đúng đắn của chúng được xem là hệ quả trực tiếp.
Từ mô tả giải thuật, chúng ta có thể thấy rằng sau bước 2 và trước bước 3, ngoại trừ hai nút start và end, thì tất cả các nút còn lại đều nằm trong các vùng (bao gồm vùng chu trình,
95
bất chu trình và vùng tầm thường). Hơn nữa, mỗi nút chỉ nằm trong đúng một vùng. Theo Định lý 3-5, với mọi cặp vùng R1 và R2, một trong hai trường hợp sau có thể xảy ra:
1. Nếu R1 nằm trong R2 hoặc ngược lại: thì bước 4 sẽ được áp dụng, và một trong hai vùng sẽ được di chuyển vào trong vùng kia.
2. Nếu R1 và R2 không có nút chung: thì một trong ba tình huống sau có thể xảy ra: a. Nếu R1 và R2 nằm trong danh sách các nút khả tuần tự thì bước 3 sẽ được áp
dụng.
b. Nếu R1 và R2 cùng nằm trong một vùng khác: thì bước 4 sẽ được áp dụng. c. Nếu R1 và R2 thuộc hai vùng khác nhau: thì bước 4 sẽ được áp dụng.
Do đó, sau bước 2, hoặc bước 3 hoặc bước 4 sẽ được thay nhau áp dụng lặp lại nhiều lần. Do số lượng vùng sau bước 2 là cố định và sau bước 3 hoặc bước 4, số vùng luôn giảm, nên giải thuật phải kết thúc và trả về một vùng cuối cùng. Tính đúng đắn của giải thuật đã được chứng minh.
Tính đầy đủ (Completeness): Chúng ta sẽ chỉ ra rằng giải thuật có thể xác định được toàn bộ các mẫu có cấu trúc đầy đủ trong tiến trình BPMN.
Như đã được chỉ ra trong phần chứng minh tính đúng đắn của giải thuật, ngoại trừ hai nút start và end, sau bước 2 không có nút nào khác nằm ngoài các vùng. Do đó, hiển nhiên là không thể có mẫu nào bị bỏ sót sau quá trình thực hiện giải thuật. Tính đầy đủ của giải thuật đã được chứng minh.
Định lý 3-9: Độ phức tạp của Giải thuật 3-2 áp dụng cho một đồ thị G (với số lượng các đỉnh, các cạnh và các vùng lần lượt là n, e và r) là O((n + e).(rc + 1) + e.logn + 2r2); trong đó rc là số lượng các vùng chu trình (circle regions).
Chứng minh:
Gọi C là độ phức tạp của giải thuật, và Ci là độ phức tạp của giải thuật tính được sau bước thứ i. Điều này có nghĩa là C=C5. Do có hai loại vùng là vùng chu trình và vùng bất chu trình, nên nếu giả sử chúng ta gọi số lượng các vùng chu trình và bất chu trình tương ứng là rc và rn, thì ta sẽ có r=rc + rn.
Sau bước 1, ta có độ phức tạp của giải thuật (sử dụng các công thức tính độ phức tạp trong [57] [48]):
C1 = O((n + e).(rc + 1)) + O(e.logn);
Độ phức tạp của giải thuật ở bước 2 là: O(nt + ne); trong đó nt và ne tương ứng là số lượng các task và event. Do đó sau bước 2 ta có:
C2 = C1 + O(nt + ne);
Do (nt + ne) < n, nên ta suy ra: C2 = C1.
Để xây dựng các vùng Sequence trong bước 3, ta nên sắp xếp các vùng tìm thấy trong các bước trước. Độ phức tạp của thao tác sắp xếp này là O(r2), với r là số lượng vùng. Do đó, sau bước 3 ta có:
96
C3 = C2 + O(r2) = O((n + e).(rc + 1) + e.logn + r2);
Độ phức tạp của bước 4 cũng tương tự như của bước 3, bởi vì việc kiểm tra quan hệ bao hàm cũng tương tự như kiểm tra thứ tự tuần tự. Do đó sau bước 4 ta có:
C4 = C3 + O(r2) = O((n + e).(rc + 1) + e.logn + 2r2); Cuối cùng, ta có:
C5 = C4 = O((n + e).(rc + 1) + e.logn + 2r2) □
3.2.5 Các nghiên cứu liên quan
Trong [3], các tác giả trình bày và cài đặt một công cụ dịch từ BPMN sang BPEL, được gọi là BPMN2BPEL. Tuy nhiên, như đã nói ở trên, chi tiết kỹ thuật của việc cài đặt không được đề cập. Do đó, nghiên cứu của luận án sẽ giúp làm rõ hơn kỹ thuật cài đặt này.
Trong [28], việc dịch từ BPMN sang BPEL lại áp dụng một cách tiếp cận khác so với đa số cách tiếp cận trước đó, sử dụng một ngôn ngữ chuyển đổi khái quát và khai báo, được gọi là AtlanMod Transformation Language (ATL). Ngôn ngữ này được dùng để chuyển đổi từ mô hình nguồn sang mô hình đích bằng cách định nghĩa các quy tắc chuyển đổi (transformation rules).
Tuy nhiên, khả năng mô hình hóa các mẫu và định nghĩa các quy tắc chuyển đổi vẫn chưa được đề cập đến. Hơn nữa, phần chuyển từ ngữ nghĩa dịch sang các quy tắc chuyển đổi cũng không rõ ràng, nên không dễ áp dụng trong thực tế.
97
KẾT LUẬN CHƯƠNG
Chương này giới thiệu tóm tắt và khái quát các kỹ thuật hiện nay dùng để làm mịn kế hoạch, với hai phương pháp: chi tiết hóa và chuyển đổi ngôn ngữ biểu diễn hoạt động. Cả hai phương pháp đều giúp làm tăng cường tính khả thi của kế hoạch, nhưng lại đi theo các cách tiếp cận khác nhau. Trong khi chi tiết hóa giúp xác định thêm các hoạt động mới nhằm làm rõ hơn các phần còn trừu tượng trong các hoạt động cũ, chuyển đổi ngôn ngữ biểu diễn hoạt động không bổ sung thêm hoạt động mới, thay đổi cách biểu diễn hoạt động, từ ngôn ngữ trừu tượng chưa thực thi được (BPMN), sang ngôn ngữ thực thi được (BPEL). Kế thừa các kỹ thuật chuyển đổi ngôn ngữ luồng liên quan đến các kỹ thuật dịch ngôn ngữ hướng đồ thị (như BPMN) sang ngôn ngữ có cấu trúc (hay hướng khối cấu trúc, như BPEL) trước đây, luận án bổ sung thêm một giải thuật nhằm khắc phục một số vấn đề còn tồn tại trong việc phát hiện và xây dựng các mẫu có cấu trúc đầy đủ.
Các biện pháp được trình bày trong chương này giúp hoàn thiện hơn các yêu cầu của khung lưới cộng tác đa dụng, giúp chuẩn bị sẵn sàng cho các bước thiết kế và cài đặt sẽ được trình bày trong Chương 4.
98
CHƯƠNG 4: THIẾT KẾ VÀ CÀI ĐẶT KHUNG LƯỚI
CỘNG TÁC ĐA DỤNG
Chương này sẽ trình bày phần thiết kế và cài đặt của khung cộng tác đa dụng với các yêu cầu như đã được trình bày trong phần 2.2. Kết quả phần thiết kế của luận án đã được công bố trong [12][10].
Ở phần cài đặt, do khối lượng cần cài đặt của khung cộng tác đa dụng này là khá lớn, nên luận án mới tập trung vào cài đặt một số thành phần chính như sau:
- Giải pháp gọi Dịch vụ lưới từ tiến trình BPEL, với kết quả đã được công bố trong [13][9]. Tuy nhiên, giải pháp còn hạn chế là mới chỉ gọi được các dịch vụ lưới không an toàn, chứ chưa gọi được các dịch vụ lưới an toàn. Hạn chế này được khắc phục trong một giải pháp được nói đến ngay sau đây.
- Giải pháp mở rộng mô hình điều khiển truy nhập cho các hệ thống luồng công việc trong môi trường lưới. Giải pháp sẽ giúp hoàn thiện hơn giải pháp gọi dịch vụ lưới ở trên, và cho phép gọi các dịch vụ lưới an toàn.
- Giải pháp tự động hóa khai thác tiến trình BPEL. Giải pháp này đã được công bố trong [11].
Trong chương này, để ngắn gọn, khung lưới cộng tác đa dụng sẽ được gọi là khung.
4.1 Các yêu cầu của khung
Mục tiêu chính của kiến trúc này được dùng như một khung lưới có hỗ trợ kế hoạch cho một phạm vi rộng các ứng dụng cộng tác. Theo Mô hình Kế hoạch, mỗi kế hoạch bao gồm các hoạt động được xác định thông qua quá trình làm mịn kế hoạch (đã được trình bày trong Chương 3). Trong quá trình này, nhiều người sử dụng có thể phối hợp với nhau để cập nhật kế hoạch thông qua các biện pháp làm mịn kế hoạch như chi tiết hóa và chuyển đổi cách biểu diễn hoạt động. Khi các hoạt động trong kế hoạch đủ mịn, người dùng cũng có thể cho phép chạy và giám sát tình trạng của các hoạt động nhằm kiểm chứng tính khả thi của chúng.
Các yêu cầu của khung đã được xác định sơ bộ ở phần 2.2.1, bao gồm:
- Định nghĩa các hoạt động: cho phép sử dụng một ngôn ngữ luồng công việc (như BPMN hoặc BPEL) để định nghĩa các hoạt động.
- Quản lý kế hoạch: do mỗi kế hoạch được biểu diễn dưới dạng một đồ thị VÀ/HOẶC, nên có thể sử dụng một trong các cách cài đặt đồ thị trong Lý thuyết đồ thị để cài đặt cho cho kế hoạch. Trong cài đặt đó, cần có các thao tác cho phép cập nhật kế hoạch, như thêm/bớt hoạt động, thêm/bớt các phụ thuộc khả thi (chi tiết hóa kế hoạch); các phép tìm kiếm hoạt động và phụ thuộc khả thi; chuyển đổi các hoạt động của kế hoạch từ BPMN sang BPEL để chuẩn bị cho quá trình thực thi chúng trong môi trường tính toán thích hợp (môi trường lưới là một trong số được chọn).
99
- Thực thi các hoạt động của kế hoạch: người dùng sẽ chọn các engine thực thi hay hạ tầng tính toán nào đó để thực thi các hoạt động trong kế hoạch. Việc thực thi sẽ giúp kiểm chứng tính khả thi của các hoạt động, từ đó suy ra tính khả thi của kế hoạch.
Tổng quan về các yêu cầu trên của khung đã được minh họa ở Hình 2-23. Để đáp ứng được các yêu cầu quản lý kế hoạch và thực thi các hoạt động ở trên, khung cần có thêm một số yêu cầu khác như sau:
˗ Cộng tác phân tán về mặt địa lý: Khung hỗ trợ việc cộng tác phân tán về mặt địa lý, cho phép các thành viên tham gia (hoặc nhóm thành viên) ở các vị trí địa lý khác nhau có thể cộng tác với nhau.
˗ Sự không đồng nhất của các hệ thống thực thi bên dưới: Khung hỗ trợ các công cụ và các hệ thống thực thi khác nhau bởi các thành viên tham gia tại các vị trí khác nhau. Trong luận án, hai hệ thống tính toán: môi trường tính toán lưới và môi trường Web được dùng để xây dựng khung.
Hai yêu cầu mới này có thể đạt được bằng việc sử dụng cơ sở hạ tầng lưới hiện nay. Do đó, nhờ khả năng hỗ trợ lập kế hoạch và khả năng cộng tác phân tán trong môi trường lưới, khung được xây dựng trở thành một khung lưới cộng tác đa dụng.
4.2 Thiết kế khung 4.2.1 Kiến trúc khung 4.2.1 Kiến trúc khung
Kiến trúc của khung sẽ bao gồm hai tầng (xem Hình 4-1):
1. Tầng Hoạt động Tập thể (Collective Activity Layer): tầng này cho phép nhiều người dùng hợp tác để xây dựng một kế hoạch làm việc, soạn thảo kịch bản công việc, sau đó chạy và giám sát công việc đã được soạn thảo đó. Các thành phần chính của tầng này gồm có :