Nhiệm vụ của bước này là thiết kế chi tiết kiến trúc bên trong của các phiên hội thoại đã xác định được trong bước trước.
Mỗi phiên hội thoại bao gồm hai sơ đồ lớp truyền thông (Communication class diagram), một cho bên khởi xướng và một cho bên đáp ứng phiên hội thoại. Thông thường, mỗi sơ đồ nhiệm vụ sẽ tương ứng với một sơ đồ phiên hội thoại cho bên tham gia tương ứng.
Trước hết ta xem xét sơ đồ phiên hội thoại Negotiation của UserAgent. Tại trạng thái Check, nhiệm vụ của agent là phải kiểm tra xem mặt hàng có thoả mãn yêu cầu hiện tại của Buyer hay không:
− Nếu thoả mãn, trả lại một biến boolean có giá trị true
− Nếu không thì phải trả lại thông tin các thuộc tính không thoả mãn để gửi yêu cầu lại cho bên đối tác.
Nghĩa là cần một biến là satisfy có kiểu boolean và một biến có thể lưu các cặp thuộc tính – giá trị của mặt hàng đang thương lượng. Dựa vào các nhiệm vụ này, trong sơ đồ phiên hội thoại hàm checkHotel() được thiết kế như sau: Chỉ cần trả về một biến có kiểu là Tupe, kiểu này đã được xác định trong bước xây dựng ontology cho hệ thống:
− Nếu giá trị này là NULL thì có nghĩa là khách sạn thoả mãn yêu cầu (không có thuộc tính nào bị vi phạm)
− Nếu giá trị này khác NULL thì có nghĩa là có yêu cầu không thoả mãn và giá trị của biến này đã xác định được tên và giá trị các thuộc tính để yêu cầu lại cho bên đối tác.
Về thiết kế các tham số cho hàm này, tham số đầu vào phải là một giá trị có kiểu Hotel đã được định nghĩa trong ontology. Như vậy trong trạng thái Check này chỉ cần một hàm checkHotel(Hotel): Tupe là đủ. Các hàm trong các trạng thái khác được thiết kế một cách tương tự. Sơ đồ phiên hội thoại cho UserAgent được mô tả trong Hình 6.2.
- Tại trạng thái Check có hàm checkHotel(Hotel):Tupe. Nếu Tupe khác NULL thì gửi đi thông điệp find và quay lại trạng thái Wait. Nếu Tupe là NULL thì chuyển sang trạng thái Accept.
- Tại trạng thái Accept có hàm acceptHotel(): boolean. Nếu trả về TRUE thì chấp nhận khách sạn và gửi đi thông điệp deal. Nếu trả về FALSE thì không chấp nhận khách sạn, gửi đi thông điệp refind và chuyển vào trạng thái Wait2.
- Tại trạng thái Recheck có hàm recheckHotel(HotelReward): boolean. Nếu trả về TRUE thì chấp nhận khách sạn, gửi đi thông điệp deal và chuyển vào trạng thái
Wait3. Nếu trả về FALSE thì không chấp nhận khách sạn, gửi yêu cầu refind và chuyển về trạng thái Wait2.
- Tại trạng thái Relax có hàm relaxHotel():Tupe. Nếu Tupe khác NULL thì vẫn còn nhượng bộ được, gửi đi yêu cầu find và quay lại trạng thái Wait. Nếu Tupe
bằng NULL thì không thể nhượng bộ thêm, gửi thông báo fail và kết thúc thất bại.
- Tại trạng thái Redeal có hàm redealHotel(Hotelfull). Lưu lại toàn bộ thông tin về khách sạn đã thương lượng được.
Thiết kế được thực hiện tương tự cho phiên hội thoại Trainneg giữa UserAgent
và StationAgent. Tuy nhiên, có một điểm khác biệt giữa thương lượng với HotelAgent
và thương lượng với StationAgent. UserAgent có thể thương lượng đồng thời với hai
StationAgent khác nhau cho các chuyến tàu đi và về; do đó, để xác định được đang thương lượng với StationAgent cho chuyến đi hay chuyến về, các hàm trong tất cả các trạng thái của phiên hội thoại này, về phía UserAgent phải có thêm một tham số đầu vào là id để xác định chuyến tàu đang thương lượng là đi hay về. Sơ đồ cho phiên hội thoại này được mô tả trong Hình 6.3.
Đối với các sơ đồ phiên hội thoại cho HotelAgent hoặc StationAgent cũng được thiết kế từ các nhiệm vụ Negotiation của các role tương ứng. Tuy nhiên, cũng phải bổ sung thêm một tham số đầu vào là userName, có kiểu String để xác định xem hiện tại nó đang thương lượng với khách hàng nào. Sơ đồ tương ứng cho các phiên hội thoại này được mô tả trong Hình 6.3.
Đối với phiên hội thoại của HotelAgent:
- Tại trạng thái Find có hàm find(User, Tupe): Hotel. Nếu Hotel bằng NULL thì không có khách sạn nào thoả mãn yêu cầu; nó gửi đi thông báo relax và chuyển vào trạng thái Wait2. Nếu Hotel khác NULL thì có khách sạn thoả mãn, nó gửi thông báo check và chuyển vào trạng thái Wait.
- Tại trạng thái Refind có hàm refind(User): Hotel. Nếu Hotel là NULL thì không có khách sạn thoả mãn; nó chuyển sang trạng thái Reward. Nếu Hotel khác NULL thì có khách sạn thoả mãn, nó gửi đi thông báo check và chuyển sang trạng thái Wait.
- Tại trạng thái Reward có hàm reward(User): HotelReward. Nếu trả về NULL thì không có khuyến mại, nó gửi thông báo yêu cầu relax và chuyển sang trạng thái Wait2. Nếu trả về khác NULL thì có khuyến mại, nó gửi thông báo recheck
và chuyển sang trạng thái Wait3.
- Tại trạng thái Deal có hàm deal(User): Hotelfull. Trả về thông tin đầy đủ mà khách hàng vừa đồng ý, nó gửi đi thông điệp redeal và kết thúc.
Tại các chuyển tiếp của sơ đồ phiên hội thoại, người thiết kế cũng phải chi tiết hoá dựa trên các chuyển tiếp trong sơ đồ nhiệm vụ tương ứng. Trong phiên hội thoại
HotelNeg của UserAgent, chuyển tiếp từ trạng thái Check sang trạng thái Wait được miêu tả bằng cú pháp
[Tupe not Null] ^ find(Tupe)
Nghĩa là sau khi kiểm tra bằng hàm checkHotel(Hotel), nếu có vi phạm thì giá trị trả về Tupe khác NULL, tức là điều kiện [Tupe not Null] có giá trị true, nên
UserAgent sẽ gửi đi một thông điệp có performative là “find” và nội dung thông điệp có kiểu là Tupe. Sơ đồ phiên hội thoại hoàn chỉnh cho mỗi bên được mô tả như các Hình 6.2 và 6.3.
Sau khi các thông tin từ sơ đồ concurrent task được ánh xạ vào như một phần của phiên hội thoại, người thiết kế phải kiểm tra lại để đảm bảo các điều kiện khả thi cho phiên hội thoại: mỗi message gửi đi phải có ít nhất một bên nhận và xử lí, không có vòng lặp vô hạn trong các sơ đồ trạng thái... Việc kiểm tra các điều kiện này có thể tiến hành một cách thủ công hoặc bán tự động với sự trợ giúp của agentTool. Chẳng hạn kiểm tra theo phương pháp thủ công điều kiện một với phiên hội thoại HotelNeg, xuất hiện chu trình
(Wait – Check – Accept – Wait2 – Relax - Wait)
của bên UserAgent (bên khởi tạo phiên hội thoại này). Sau mỗi vòng lặp này, yêu cầu về các thuộc tính đều bị giảm đi một mức do UserAgent tự nhượng bộ, nên dãy yêu cầu của UserAgent là “đơn điệu giảm”. Hơn nữa, sự nhượng bộ sẽ dừng lại khi độ thoả mãn các thuộc tính thấp hơn ngưỡng nhượng bộ (relaxThreshold), ngưỡng này được ước lượng khi mô hình hoá sở thích người dùng. Do vậy, dãy yêu cầu của UserAgent sẽ đơn điệu giảm và bị chặn dưới nên sẽ dừng, nghĩa là vòng lặp không vô hạn.