CHƯƠNG 4 TỔNG QUAN VỀ OWL-S
4.3 Mô hình dịch vụ thành các tiến trình
4.3.1 Ontology tiến trình
Một tiến trình có thể có nhiều đầu vào, mô tảthông tin dưới dạng các điều kiện, cần thiết để thực thi tiến trình. Nó có thể cũng có nhiều đầu ra, thông tin mà tiến trình cung cấp, có điều kiện, sau khi nó chạy. Bên cạnh đầu vào và đầu ra, có một tham số quan trọng quy định các thành phần tham gia trong một tiến trình. Trong một tiến trình cũng có thể có nhiều tiền điều kiện và nhiều hiệu ứng. Các kết quảđầu ra và hiệu ứng có thểcó các điều kiện liên kết giữa chúng.
Đầu vào được đặc tả trong OWL-S như sau: <owl:ObjectProperty rdf:ID="hasInput">
<rdfs:subPropertyOf rdf:resource="#hasParameter"/>
<rdfs:range rdf:resource="#Input"/>
</owl:ObjectProperty>
Đầu ra là loại tham số và là một thuộc tính của một hồsơ. Một đầu ra chỉ rõ cái gì là kết quả của toán tử của dịch vụ, nó được biểu diễn:
<owl:ObjectProperty rdf:ID="hasOutput">
<rdfs:subPropertyOf rdf:resource="#hasParameter"/>
<rdfs:range rdf:resource="#Output"/>
</owl:ObjectProperty>
Tiền điều kiện trình bày một điều kiện được mong đợi từ dịch vụ làm việc thích hợp. Ví dụ, một tiền điều kiện nói rằng một ít tiền là đủđể trả cho một ít hàng hóa hoặc hàng hóa có thể mua được, … Tiền điều kiện được mô tả theo mẫu sau:
<owl:ObjectProperty rdf:ID="hasPrecondition">
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range rdf:resource="&expr;#Condition"/>
</owl:ObjectProperty>
Hiệu quả chỉ các điều kiện được mong đợi thành kết quả sau khi thực thi dịch vụ. Ví dụ, một thẻđược nạp, hàng được giao,… Mô tả hiệu quảnhư sau:
<owl:ObjectProperty rdf:ID="hasEffect">
<rdfs:label>hasEffect</rdfs:label>
<rdfs:domain rdf:resource="#Result"/>
<rdfs:range rdf:resource="&expr;#Expression"/>
</owl:ObjectProperty>
Mức độ chất lượng của một dịch vụ sẽ là một vấn đề rất quan trọng trong việc lựa chọn dịch vụ. Mức độ chất lượng dịch vụ có 2 trường: ratingName và
rating; ratingName chỉ tên của mức độ dịch vụ; rating chỉ mức độđược gán cho dịch vụ. Ví dụ: <profile:qualityRating> <profile:QualityRating rdf:ID="Provider-Rating"> <profile:ratingName> SomeRating </profile:ratingName> <profile:rating rdf:resource="#GoodsRating"/> </profile:QualityRating> </profile:qualityRating> 4.3.2 Tiến trình nguyên tử
Tiến trình nguyên tửđược gọi một cách trực tiếp thông qua các thông điệp thích hợp. Các tiến trình nguyên tử không có các tiến trình con, và thực thi trong một bước duy nhất, từ quan điểm của người yêu cầu dịch vụ. Tức là, chúng lấy một thông báo đầu vào, thực thi, sau đó trả lại một thông báo đầu ra. Và người yêu cầu dịch vụ không thấy được sự thực thi của dịch vụ. Với mỗi tiến trình
nguyên tử, phải cung cấp một nền đểcho phép người yêu cầu dịch vụ xây dựng các thông báo. Ví dụ về một tiến trình nguyên tử:
<owl:Class rdf:ID="AtomicProcess">
<owl:subClassOf rdf:resource="#Process"/>
</owl:Class>
4.3.3 Tiến trình đơn
Các tiến trình đơn không có khả năng gọi và không được kiết hợp với một nền, nhưng, giống như các tiến trình đơn giản, chúng được xem như là thực thi đơn bước. Các tiến trình đơn được dùng như các phần tử của sự trừu tượng, nó được dùng để cung cấp một khung nhìn hoặc là các mô tảđơn giản của một vài tiến trình nguyên tử. Ví dụ về một tiến trình đơn: <owl:Class rdf:ID="SimpleProcess"> <rdfs:subClassOf rdf:resource="#Process"/> </owl:Class> <rdf:Property rdf:ID="realizedBy"> <rdfs:domain rdf:resource="#SimpleProcess"/> <rdfs:range rdf:resource="#AtomicProcess"/> <owl:inverseOf rdf:resource="#realizes"/> </rdf:Property> <rdf:Property rdf:ID="expandsTo"> <rdfs:domain rdf:resource="#SimpleProcess"/> <rdfs:range rdf:resource="#CompositeProcess"/> <owl:inverseOf rdf:resource="#collapsesTo"/> </rdf:Property>
4.3.4 Tiến trình tổng hợp
Tiến trình tổng hợp là khả năng triển khai thành các tiến trình khác (tổng hợp hoặc phi tổng hợp). Sự triển khai này có thểđược mô tả bằng cách dùng các cấu trúc điều khiển như tuần tự và nếu thì. Ví dụ về một tiến trình tổng hợp:
<owl:Class rdf:ID="CompositeProcess"> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Process"/> <owl:Restriction owl:cardinality="1"> <owl:onProperty rdf:resource="#composedOf"/> </owl:Restriction> </owl:intersectionOf> </owl:Class>
CHƯƠNG 5. KIỂM CHỨNG SỰ PHÙ HỢP CHỨC NĂNG
TRONG MÔ HÌNH WSD
5.1 Phương pháp kiểm chứng
Trong mô hình WSD, các chức năng cung cấp bởi bất kỳ một dịch vụ đã quảng bá nào sẽ được đem so sánh với các chức năng mà người yêu cầu cần. Mục đích của việc này là tìm ra nhà cung cấp dịch vụ có chức năng phù hợp với yêu cầu của bên yêu cầu dịch vụ.
Cốt để đơn giản hóa việc phát triển hệ thống, phương pháp B dùng ký hiệu tương tự cho tất cả các giai đoạn phát triển, tiếp tục lần lượt cải tiến từng bước. B cải tiến cung cấp một cách để xây dựng các bất biến tốt hơn và cũng để thêm chi tiết cho mô hình. Nó cũng được dùng để chuyển một mô hình trừu tượng thành một phiên bản đúng hơn bằng cách thay đổi trạng thái mô tả. Hơn nữa, các bước chứng minh định nghĩa trong B cải tiến liên quan cho phép chúng ta kiểm tra các tiền điều kiện và hậu điều kiện của các toán tử mức thấp cho phù hợp với các tiền và hậu điều kiện của các toán tử mức cao hơn. Như chúng ta đã biết, các biến trạng thái trừu tượng, xx, và cụ thể là xx’, được liên kết với nhau thông qua một bất biến gắn kết InvM’, đã định nghĩa trong máy cải tiến.
Hình thức hóa mô hình WSD dùng B cải tiến, cho phép chúng ta kiểm tra sự đồng nhất của tên, đầu vào và đầu ra của người yêu cầu dịch vụ web và nhà cung cấp dịch vụ. Hơn nữa, theo [15] thì mức độ phù hợp có thể có sự khác biệt giữa 4 mức: exact, plugin, subsumes, fail. Tùy thuộc vào mức độ phù hợp, chúng ta có thể kiểm tra sự tương quan giữa các tiền điều kiện, hiệu quả và chất lượng dịch vụ giữa các yêu cầu của người yêu cầu dịch vụ web và các chức năng của nhà cung cấp. Theo [15] thì mức phù hợp exact là tốt nhất, thích hợp cho mọi trường hợp; mức phù hợp plugin là mức tốt tiếp theo vì đầu ra trả lại có thể chắc chắn được dùng thay cho những gì người yêu cầu mong muốn; mức phù
hợp subsumes là mức tốt thứba, khi đó các yêu cầu của người yêu cầu chỉ được đáp ứng một phần: dịch vụđã quảng bá có thể chỉ cung cấp một vài trường hợp cụ thể mà người yêu cầu cần; mức phù hợp fail là mức thấp nhất, nó mô tả một kết quả không thể chấp nhận được.
Để kiểm chứng sự phù hợp chức năng trong mô hình WSD, luận văn đề xuất một hướng tiếp cận như sau:
i. Các yêu cầu của người yêu cầu dịch vụ web sẽ được mô hình hóa thành máy trừu tượng B như được trình bày trong Hình 5.1. Theo đó:
a. Tên của dịch vụ, đầu vào, đầu ra được chuyển thành tên của toán tử, các tham sốđầu vào và ra tương ứng.
b. Tiền điều kiện và hiệu quả của dịch vụ web được chuyển thành tiền điều kiện và thân của toán tử trong máy trừu tượng B.
c. Các QoS mong muốn của dịch vụweb được chuyển thành một toán tử gọi là serviceQuality.
ii. Các khả năng của nhà cung cấp dịch vụ được hình thức hóa thành một máy cải tiến B như trình bày trong Hình 5.2. Theo đó:
a. Đầu vào, đầu ra trong OWL-S Profile được biểu diễn bởi tham số vào và ra của toán tử trong máy cải tiến B tương ứng.
b. Tiền điều kiện, các kết quả của dịch vụ web được biểu diễn bởi tiền điều kiện và thân của toán tử trong máy cải tiến.
c. QoS của nhà cung cấp dịch vụ web được biểu diễn bằng một toán tử gọi là serviceQuanlity trong máy cải tiến.
iii. Sự phù hợp giữa các yêu cầu mong muốn của người yêu cầu dịch vụ và các khả năng của nhà cung cấp dịch vụ web sẽ được phân tích và kiểm chứng bằng công cụ hỗ trợ B, mà cụ thể là Atelier B.
Hình 5.1 Hình thức hóa các yêu cầu thành máy trừu tượng B
Hình 5.2 Hình thức hóa các chức năng của nhà cung cấp thành một máy cải tiến B
WS_provider contactInformation name phone email webURL serviceName textDescription hasProcess serviceCategory serviceParameter quanlityRating output input precondition effects Refinement machine OPERATIONS ServiceQuality=…; oo serviceName(in1,in2)= PRE P THEN S END; WS_requester serviceName input output precondition effects serviceQuality timeRespond availability… B abtract machine OPERATIONS oo serviceName(in1,in2)= PRE P THEN S END; ServiceQuality = …
5.2 Ví dụ minh họa
Để minh họa cho hướng tiếp cận của luận văn, chúng ta hãy xem xét một hệ thống đơn giản về dịch vụ web tính tiền phí thay đổi loại vé máy bay mà khách hàng đã mua. Tức là, khi khách hàng đăng ký mua vé máy bay, khác hàng phải chọn loại vé (FareTypes) của mình là: Business, Eco, Saver hay Super_Saver. Sau đó vì các lý do cá nhân, khách hàng có thể thay đổi lại loại vé của mình. Tất nhiên, khách hàng sẽ phải chịu một khoản phí thay đổi (ChangeFee), nó được tính theo qui định của hãng hàng không mà khách hàng chọn. Ứng dụng được phát triển theo hướng xử lý dữ liệu dựa trên các nguồn tài nguyên trên Internet, dịch vụ tính tiền phí thay đổi loại vé máy bay sẽ dùng thẻ tín dụng để thanh toán.
Dịch vụweb này được mô tảnhư dưới đây. Việc gọi ứng dụng phải cung cấp một kiểu hợp lệ cũng như sốlượng các vé muốn thay đổi (seat). Kết quả trả lại là tổng số tiền (TotalChangeFee) khách hàng phải trả dựa trên các quy tắc tính phí của hãng hàng không. Bảng dưới đây đưa ra mô tả chức năng của nhà cung cấp dịch vụ web Change Fee Calculation:
Context: Change Fee Calculation;
Types: FareTypes={Business, Eco, Saver, Super_Saver};
Money=real;
Input: FareType: FareTypes;
seat:interger;
Output: TotalChangeFee:Money;
Precondition: seat>0;
Effect: TotalChangeFee = ChangeFeeOf(FareType)*seat;
TextDescription: Calculating total change fee for booked tickets.
Như đã trình bày trong Chương 4, các dịch vụ web ngữ nghĩa được mô tả bằng OWL-S là một OWL ontology với 3 ontology con tương đương nhau là: ServiceProfile, ServiceModel và ServiceGrounding. Tóm lại, ServiceProfile được dùng để cho biết “dịch vụ làm cái gì”, với mục đích là quảng bá, xây dựng các yêu cầu dịch vụ và làm cầu nối; ServiceModel mô tả “cách nó làm việc”,
cho phép yêu cầu, ban hành, tổng hợp, kiểm tra và phục hồi; và ServiceGrounding ánh xạ các thành phần của ServiceModel theo các đặc tả chi tiết của khuôn dạng thông điệp, giao thức, … (thường được chỉ ra trong WSDL). Do sự mô tảtương đương trong OWL-S giữa nhà cung cấp và người yêu cầu dịch vụ web, chúng ta chỉ xem xét mô tả của Change Fee Calculation đối với nhà cung cấp dịch vụ. Luận văn trình bày đầu vào, đầu ra, tiền điều kiện và hiệu quả của trong OWL-S Profile và sau đó được tham chiếu tới OWL-S Process như sau:
<process:AtomicProcess rdf:ID=" ChangeFeeCalculation ">
<process:hasInput>
<process:Input rdf:ID=" FareType"/>
</process:hasInput> <process:hasInput> <process:Input rdf:ID="seat"/> </process:hasInput> <process:hasOutput> <process:Output rdf:ID="TotalChangeFee"/> </process:hasOutput> <process:hasPrecondition> <expr:KIF-Condition> <expr:expressionBody>
(and (member ? FareType ? FareTypes)
(and (member ? seat ?Integer)
(> (?seat 0)))) </expr:expressionBody> </expr:KIF-Condition> </process:hasPrecondition> <process:hasEffect> <expr:KIF-Condition> <expr:expressionBody> (= ?TotalChangeFee
( * (value ? ChangeFeeOf ? FareType) ? seat)) </expr:expressionBody> </expr:KIF-Condition> </process:hasEffect> .. </process:AtomicProcess>
Trong mô tả trên, tiền điều kiện và hiệu quả của dịch vụ web được mô tả bằng KIF (Knowledge Interchange Format – Khuôn dạng trao đổi tri thức).
FareTypes là một tập chứa tên của các loại vé mà khách hàng muốn thay đổi,
ChangeFeeOf là một hàm ánh xạ từ tập FareTypes tới tập Money với mục đích là từ tên của loại vé, chúng ta sẽ tính được tổng số tiền phí mà khách hàng phải trả cho việc thay đổi loại vé của mình theo quy định của hãng hàng không (chẳng hạn đổi từ loại vé Business sang loại Eco, khách hàng phải trả một khoản phí là 2%). Chúng được mô tả trong OWL-S như sau:
<owl:Class rdf:ID="FareTypes"> ... <FareTypes rdf:ID="Business" /> <FareTypes rdf:ID="Eco" /> <FareTypes rdf:ID="Saver" /> <FareTypes rdf:ID="Super_Saver" /> </owl:Class> <owl:ObjectProperty rdf:ID="ChangeFeeOf"> <rdfs:domain rdf:resource="#FareTypes" /> <rdfs:range rdf:resource="#Money" /> </owl:ObjectProperty>
5.3 Hình thức hóa và kiểm chứng
5.3.1 Hình thức hóa
Áp dụng các quy tắc chuyển đổi đã trình bày trong mục 5.1, chúng ta hình thức hóa mô tả về nhà cung cấp và người yêu cầu dịch vụ web Change Fee Calculation như trong hình 5.4. Người yêu cầu được mô tả bởi máy trừu tượng WS_Requester và nhà cung cấp được trình bày bằng máy cải tiến WS_Provider, nó cải tiến máy WS_Requester. Các máy này sử dụng máy Types để biểu thị các tập hợp được sử dụng trong mô hình (Hình 5.3).
Hình 5.3 Máy Types
Trong mô hình này, hệ thống đánh giá sẽ sử dụng 100 mức. Mỗi thành phần QoS của dịch vụ web sẽ lấy giá trị từ 1 (thấp nhất) tới 100 (cao nhất) (Hình 5.3). Các thành phần QoS ở đây bao gồm: Tính sẵn sàng (AVAILABILITY), tính tin cậy (RELIABILITY). Hiệu quả mang lại trong phương pháp đã dùng đơn giản là hàm tính tổng số tiền phải trả của người yêu cầu dịch vụ (calcul_ChangeFee) nhận giá trị trả lại là thuộc kiểu Money. Hàm đó thuộc nhà cung cấp dịch vụ có nhiệm vụ tính tổng số tiền phí phải trả cho việc đổi các vé máy bay mà khách hàng đã mua.
MACHINE Types
SETS FARETYPES = {Business, Eco, Saver, Super_Saver}
CONCRETE CONSTANTS MONEY, AVAILABILITY, RELIABILITY, ... PROPERTIES MONEY INT
AVAILABILITY NAT AVAILABILITY = 1..100 RELIABILITY NAT RELIABILITY = 1..100 ...
Hình 5.4 Hình thức hóa mô hình WSD của hệ thống ChangeFee bởi B SEES Types VARIABLES availabilityR, maxResTimeR, reliabilityR …. INVARIANT availabilityR AVAILABILITY maxResTimeR INT reliabilityR RELIABILITY …. INITIALISATION …. OPERATION TotalChangeFee calcul_ChangeFee( FareType,seat)= PRE FareType FARETYPES
seat INT seat >0
THEN TotalChangeFee: MONEY END; serviceQuality= BEGIN availabilityR:=98|| maxResTimeR:=10|| reliabilityR:=98… END END SEES Types REFINE Requirements VARIABLES ChangeFeeOf,availabilityP, maxResTimeP, reliabilityP …. INVARIANT
ChangeFeeOf FARETYPES MONEY
availabilityP AVAILABILITY maxResTimeP INT reliabilityP RELIABILITY availabilityR availabilityP maxResTimeP maxResTimeR reliabilityR reliabilityP …. INITIALISATION …. OPERATION TotalChangeFee calcul_ChangeFee( FareType,seat)= PRE FareType FARETYPES
seat INT seat >0
THEN TotalChangeFee:= ChangeFeeOf(FareType) * seat END; serviceQuality= BEGIN availabilityP:=99|| maxResTimeP:=8|| reliabilityP:=98… END END
5.3.2 Kiểm chứng bằng công cụ hỗ trợ B
Các công cụ hỗ trợ của B sẽ kiểm tra giá trị trả lại của hàm trong máy cải tiến có thuộc kiểu Money hay không, có phù hợp với giá trị đầu ra của phương thức calcul_ChangeFee trong máy trừu tượng hay không. Điều này thực hiện được dựa trên các bước chứng minh của cải tiến B. Theo cách này có thể kiểm tra được sựtương quan giá trị giữa QoS của người yêu cầu dịch vụ và nhà cung cấp dịch vụ, đã định nghĩa trong bất biến gắn kết của máy cải tiến.
Atelier B được phát triển bởi ClearSy [11,12], là một công cụ xây dựng ứng dụng dùng phương pháp B. Nó cung cấp nhiều chức năng để quản lý các dự án theo ngôn ngữ B trong một môi trường rõ ràng, mạch lạc. Các chức năng này có thể gộp lại thành ba nhóm chính:
Nhóm hỗ trợ chứng minh: Dùng để kiểm chứng các bước chứng minh bằng các công cụ chứng minh phù hợp.
Nhóm hỗ trợ phát triển: Quản lý tự động sự phụ thuộc giữa các thành phần B.
Nhóm các công cụ thân thiện với người dùng: Các dự án được trình bày dưới dạng đồ họa, hiển thị các trạng thái cũng như số liệu thống kê của dự án, các dựán lưu trữ.
Atelier B có thể được sử dụng thông qua giao diện đồ họa hoặc sử dụng dòng lệnh trực tiếp (chế độ lệnh). Atelier B là đa người dùng, các nhiệm vụ có thểđược làm tựđộng trong suốt quá trình phát triển dựán như sau:
Thẩm tra cú pháp của các thành phần.
Tựđộng sinh các bước chứng minh.
Tựđộng chứng minh
Tựđộng biên dịch các cài đặt B thành ngôn ngữ C hoặc Ada
Hiện nay, Atelier B có các phiên bản dùng trên Windows, Linux, Mac và Solaris.
Để sử dụng Atelier B, chúng ta vào trang http://www.atelierb.eu tải bản Atelier B 4.0 vềmáy. Đây là bản hoàn toàn miễn phí, và tùy vào hệđiều hành sử dụng chúng ta chọn loại dùng cho Windows, Linux, Mac hay Solaris. Trong luận văn trình bày là bản Atelierb-4.0 dùng cho Windows. Sau khi tải về máy chúng ta chạy file atelierb-4.0-win32-free.exe để cài đặt như các phần mềm thông thường.
Sau khi cài đặt chúng ta có màn hình chào của Atelier B như trong Hình 5.5 và màn hình quản lý dựán như trong Hình 5.6. Với Atelier B chúng ta có thể thực hiện các chức năng cụ thểnhư sau:
Quản lý dự án.
Quản lý các thành phần trong dự án.
Thẩm tra cú pháp của các thành phần TC (Types Check).
Tựđộng sinh các bước chứng minh PO (Generated POs).
Tựđộng chứng minh mức 0 F0 (Automatic Proved Force 0).
Tựđộng chứng minh mức 1 F1 (Automatic Proved Force 1).
Tựđộng chứng minh lại Fr (Proof Replay).