Sơ đồ tiến trình thiết kế

Một khi vấn đề đã đƣợc xác định là đã đạt đƣợc mức độ chi tiết cần thiết, thì sẽ chuyển từ giai đoạn phân tích sang thiết kế nhằm xây dựng giải pháp. Ranh giới giữa hai giai đoạn không quá rõ ràng, và có thể lặp đi lặp lại các bƣớc phân tích hay thiết kế, một bƣớc có thể di chuyển giữa cả hai giai đoạn này. Bởi vì bắt đầu từ điểm này, phƣơng pháp luận đã đƣợc đƣa ra tập trung vào nền tảng phát triển tác tƣ̉ JADE ( và bắt đầu từ đó, những cấu trúc đƣợc JADE cung cấp sẽ đƣợc sử dụng), nó có thể không thích hợp cho việc áp dụng cho các ứng dụng vào các nền tảng phát triển các hệ thống đa tác tử khác. Việc thực hiện buớc thiết kế sẽ phải đạt đƣợc mức độ chi tiết đủ để có thể có chuyển thẳng sang bƣớc thực hiện cài đặt, với triển vọng là một lƣợng lớn mã đƣợc tạo ra bằng các công cụ tự động.

Giống nhƣ trong giai đoạn phân tích, giai đoạn thiết kế đƣợc thực hiện bởi một số bƣớc logic sau đây, với một mức độ chồng lấp nhất định. Nhƣ đã đề cập ở trên, ngƣời thiết kế không bị yêu cầu phải dập khuôn y nguyên những bƣớc này, và có thể bỏ đi một số bƣớc và một số chi tiết đặc tả tƣơng ứng khác nếu họ muốn

Việc thiết kế phải làm nhƣ thế nào để cài đặt hệ thống, hoạt động và đƣa ra đƣợc một kết quả nhƣ mong đợi nhƣ đã đƣợc xác định trong bƣớc phân tích. Việc thiết kế bắt đầu bằng việc xác định việc phân quyền cho các nơi cƣ trú. Sau đó các máy trạng thái cho tác tử , các nơi cƣ trú và các lớp đƣợc xây dựng. Tiếp theo mô hình vòng đời sẽ đƣợc xây dựng cho từng nhiệm vụ chính. Các nơi cƣ trú có mối quan hệ sẽ đƣợc nhóm lại thành hàng xóm. Bƣớc tiếp theo là mô tả các hành vi động của hệ thống bằng cách định nghĩa kế hoạch hành trình của các tác tử và sửa đổi các mô hình tƣơng tác. Bƣớc thiết kế kết thúc bằng việc thiết kế chi tiết các phƣơng thức và các thuộc tính cho các lớp, các tác tử và các nơi cƣ trú. Cuối cùng sẽ cập nhật từ điển dữ liệu.

3.4.2. Các bƣớc của tiến trình thiết kế

a) Bước 1 - Phân tách, ghép nối và đặt lại tên tác tử

Đây là bƣớc quan trọng để quyết định độ phức tạp cũng nhƣ hiệu suất của hệ thống. Ở bƣớc này, chúng ta phải quyết định xem những loại tác tử nào sẽ đƣợc tách ra, những loại tác tử nào sẽ đƣợc ghép lại. Việc tách hay gộp dựa trên cơ sở là những quy tắc sau đây:

1. Giải quyết vấn đề trùng lặp dữ liệu. Nếu có hai hoặc nhiều tác tử cùng chia

sẻ một lƣợng lớn các thông tin chính khi thƣ̣c hiê ̣n nhiệm vụ của chúng thì nên gộp chúng lại thành một loại tác tử.

2. Không trùng lặp mã truy nhập tài nguyên. Nếu có hai hoặc nhiều tác tử

cùng có nhu cầu truy xuất những tài nguyên giống nhau thì cũng có thể gộp chúng lại.

3. Không nên tách tác tử trừ khi nó có những lý do xác đáng. Chia ra thành

nhiều tác tử sẽ tăng độ phức tạp chung của toàn hệ thống và giảm khả năng của hệ thống khi phải tổ chức các giao tiếp không cần thiết giữa các tác tử.

Tách/gô ̣p các tác tử

Đặc tả tƣơng tác Xây dƣ̣ng mẫu thông điê ̣p Thiết kế giao diện và phƣơng thức chi tiết Đặc tả hành vi của tác tƣ̉

Hình 3.6. Sơ đồ tiến trình thiết kế Danh sách tác tử Lƣ̣a cho ̣n ngôn ngƣ̃ và xây dƣ̣ng ontology Bảng tƣơng tác Các mẫu thông điê ̣p Giao diê ̣n của tác tử

Đặc tả hành vi của các tác

tƣ̉

Ngôn ngƣ̃ truyền thông và ontology

4. Mỗi tác tử đƣợc đặt trên một máy đơn. Nhân tố chính định hƣớng cho việc phân tách các tác tử là các vấn đề triển khai (dựa trên lƣợc đồ triển khai). Nếu có hai mảng chức năng phải đƣợc các máy khác nhau cung cấp thì các mảng này phải đuợc bởi các tác tử khác nhau cung cấp.

5. Nên tránh việc có các tác tử quá lớn và phức tạp. Các tác tử phức tạp sẽ khó

thiết kế và duy trì.

6. Trong một số trƣờng hợp phƣơng pháp bộ bao sẽ đƣợc sử dụng, Trong các

trƣờng hợp này, có thể việc gộp hoặc tách các tác tử sẽ gặp khó khăn. Đây là một lý do tốt để chấp nhận phƣơng pháp bộ chuyển đổi.

Chúng ta có thể thấy dƣờng nhƣ có sự mâu thuẫn khi nhìn vào quy tắc thứ ba và thứ tƣ. Ở đây cần cân nhắc đến mối quan hệ cân bằng giữa số lƣợng lớn các tác tƣ̉ đơn giản và một số lƣợng nhỏ các tác tử lớn và phức tạp. Vấn đề bảo mật hết sức quan trọng khi xây dựng một hệ thống tác tử nên các khái niệm quyền truy cập cho các nơi cƣ trú cần đƣợc đề cập đến bởi. Quyền truy cập cho chỉ định tác tử nào có thể di trú tới nơi cƣ trú nào. Các mẫu nơi cƣ trú sẽ cập nhật các ghi nhớ.

b) Bước 2 - Đặc tả các tương tác của các tác tử

Trong bƣớc này, với từng kiểu tác tử, tất cả các trách nhiệm có liên quan tới các mối liên quan đã biết với các tác tử khác sẽ đƣợc đƣa vào bảng tƣơng tác cho mỗi loại tác tử. Mỗi dòng trong bảng sẽ biểu diễn một tƣơng tác bao gồm:

 Một cái tên mô tả cho tƣơng tác.

 Trách nhiệm mà đã phát sinh ra tƣơng tác này.

 Phƣơng thức tƣơng tác thích hợp đƣợc chọn để cài đặt tƣơng tác. Các

phƣơng thức tƣơng tác FIPA chuẩn đƣợc gợi ý là nên xem xét đầu tiên. Nếu không có phƣơng pháp nào trong số chúng thoả mãn, thì một phƣơng

thức mở rộng sẽ đƣợc khai báo giống nhƣ mô tả trong bƣớc 3 của quá trình phân tích.

 Vai trò sẽ thực hiện của tác tử trong phƣơng thức tƣơng tác. Nó có thể là I -

ngƣời khởi tạo hay là R - ngƣời trả lời. Các vai trò khác có thể thêm vào nếu đòi hỏi.

 Kiểu và tên của các tác tử của các vai trò bổ sung.

 Điều kiện phát sinh nhƣ là khi nào thì tƣơng tác đƣợc tạo ra. Các điều kiện

này nên đƣợc giải thích theo cách nói tự nhiên bằng phƣơng pháp hình học. Dƣới đây là bảng tƣơng tác của bài toán giao dịch thƣơng ma ̣i điê ̣n tƣ̉.

Tƣơng tác Trách nhiệm

Giao thức Vai trò Với Khi nào

Đăng ký bán 1 Contract Net I Handy Terminal System Đăng ký mua. 5 Contract Net

R Quản lý công việc

Nhận danh sách dịch vụ sẵn sàng 8 FIPA Request I Xác nhận tính xác thực của ngƣời cung cấp 9 FIPA Subcrible I Cung cấp thông tin. 10 FIPA Request I

c) Bước 3 - Định nghĩa giao thức tương tác

Bất kỳ khi nào có thể, nên chọn những giao thức tƣơng tác có sẵn đƣợc định nghĩa bởi FIPA. Tuy nhiên, trong rất nhiều trƣờng hợp, một tƣơng tác yêu cầu một giao thức tƣơng tác tình thế phải đƣợc định nghĩa (nghĩa là, khi không một giao thức tƣơng tác đƣợc định nghĩa bởi FIPA nào đƣợc cho là phù hợp). Trong những trƣờng hợp nhƣ thế, giao thức tƣơng tác đó nên đƣợc định nghĩa bằng các cách của một giao thức cơ sở hợp lý. Có hai hƣớng lựa chọn đƣợc đề xuất:

1. Các giao thức tƣơng tác hình thức là các giao thức tƣơng tác đƣợc định

nghĩa trong AUML.

2. Các giao thức tƣơng tác khác (có thể là “định nghĩa bởi ngƣời sử dụng nhƣ

FSM,… dựa trên cơ sở là các giao thức tƣơng tác hình thức).

Lý do cho việc thêm vào rất nhiều các giao thức tƣơng tác khác ngoài AUML là, mặc dù AUML thích hợp cho những hội thoại đơn giản nhƣng nó không thực tế khi muốn biểu đạt các trình tự tƣơng tác phức tạp. Trong trƣờng hợp một giao thức tƣơng tác tình thế đƣợc yêu cầu, một lƣợc đồ nên đƣợc cung cấp với định nghĩa của nó. Giản đồ này nên tuân theo AUML, hoặc, trong tƣơng lai, tuân theo FSM.

d) Bước 4 – Xây dựng các mẫu thông điệp

Tất cả các vai trò của giao thức tƣơng tác đƣợc định nghĩa trong bƣớc trƣớc đƣợc thực hiện nhƣ các hành vi trong JADE. Trong bƣớc này, các đối tƣợng mẫu thông điệp thích hợp đƣợc đặc tả để đƣợc sử dụng với hành vi này để nhận đƣợc các thông điệp đang đến, và những mẫu này đƣợc thêm vào các hàng của bảng tƣơng tác. Các quy tắc sau đây nên đƣợc áp dụng trong bƣớc này:

1. Sử dụng các mẫu thông điệp dựa trên cơ sở là mã các cuộc hội thoại trong

các hành vi đƣợc các tác tử thực hiện vai trò ngƣời khởi tạo. Hãy chắc chắn các mã hội thoại đƣợc tạo ra trong một tác tử là duy nhất.

2. Sử dụng những mẫu thông điệp trên cơ sở là sự kết hợp của các thông điệp khởi tạo, ontology, và ngôn ngữ ở trên trong những hành vi “luôn hoạt động” để thực hiện vai trò ngƣời trả lời.

3. Phân tích các mâu thuẫn có thể đƣợc thực hiện bằng các công cụ tự động.

Nếu các xung đột không đƣợc giải quyết, hãy xem xét đến việc áp dụng các kiểu, mẫu động.

Chú ý rằng, ở giai đoạn này, một số giả định đƣợc tạo ra trên ngôn ngữ giao

tiếp của tác tử đƣợc sử dụng trong hệ thống khi đặc tả các mẫu. Điều này khiến cho các cải tiến trở nên cần thiết ở các bƣớc sau. Dựa trên các quy tắc trên, bảng tƣơng tác đƣợc đƣa ra ở bƣớc trƣớc có thể đƣợc nâng cấp thành bảng đƣợc chỉ ra một phần dƣới đây.

Tƣơng tác T/nhiệm IP Vtrò Với ai Khi nào Mẫu

Đăng ký các loại hàng hóa đƣợc bán 1 Mạng hợp đồng

R Tác tử bán Ngƣời sử dụng đăng ký bán.

Conv-id

…

Các kiểu mẫu động

Các nền tảng hỗ trợ việc phát triển các hệ thống tác tử thƣờng xây dựng sẵn các kiểu mẫu động nhằm đơn giản hóa quá trình thiết kế. Các mẫu động này đƣợc khuyến khích sử dụng để tạo ra sự nhất quán trong cả hệ thống.

Với môi trƣờ ng phát triển JADE, kiểu mẫu động đƣa ra dựa trên đối tƣợng

jade.lang.acl.ConversationList bên trong tác tử. Tất cả các hành vi khởi tạo đăng ký vào ConversationList bằng phƣơng thức onStart ( ) và hủy đăng ký bằng phƣơng thức onEnd ( ) của chúng. Do đó mà ConservationList có thể theo dõi đƣợc tất cả

các tƣơng tác đƣợc khởi xƣớng bởi tác tử và có thể cung cấp một mẫu thông điệp phù hợp với tất cả các thông điệp không thuộc vào bất cứ cuộc hội thoại nào trong số này. Bởi vậy, các hành vi trả lời có các mẫu xung đột có thể sử dụng các mẫu đƣợc cung cấp bới ConservationList để tránh những xung đột với tất cả các đối tƣợng khởi tạo khác.

e) Bước 5 - Đăng ký, tìm kiếm và quản lý danh mục

Trong bƣớc này, những quy ƣớc đặt tên và các dịch vụ đƣợc đăng ký/tìm kiếm

bởi các tác tử trong danh sách các trang vàng đƣợc duy trì bởi bộ tiê ̣n ích quản lý

thƣ mục JADE. Các quy ƣớc đặt tên hầu hết phụ thuộc vào một vùng nào đó và nên dùng ngôn ngữ tự nhiên để đặc tả chúng. Hơn nữa, một biểu mẫu sơ đồ phân lớp đƣợc đƣa ra để mô tả các đăng ký, tìm kiếm dịch vụ.

f) Bước 6 – Tương tác giữa tác tử và các nguồn tài nguyên bên ngoài

Thƣờng xảy ra trƣờng hợp một hay nhiều tác tử trong hệ thống phải tƣơng tác với các nguồn tài nguyên bên ngoài nhƣ các cơ sở dữ liệu, các file lƣu trữ thông tin, hoặc các phần mềm di sản. Trong một số trƣờng hợp, một số thiết bị phần cứng phải đƣợc điều khiển hoặc giám sát, nhƣng điều này luôn xảy ra qua một vài phần mềm

chuyên dụng mà các phần mềm này đƣợc nhúng sẵn trong các tài nguyên phần

cứng. Các tác tử tƣơng tác với các nguồn tài nguyên bên ngoài đã đƣợc xác định trong giai đoạn phân tích, và đƣợc thể hiện trong sơ đồ tác tử bởi các mối quan hệ quen biết với một phần từ chính các nguồn tài nguyên đó. Những nguồn tài nguyên nhƣ thế có thể đƣợc phân loại thành hai loại chính:

1. Các nguồn tài nguyên thụ động: là những tài nguyên mà chỉ thay đổi tình trạng của chúng nhƣ là kết quả của một vài kích thích bị gây ra bởi các tác tƣ̉ đang tự nó điều khiển các nguồn tài nguyên đó.

2. Các nguồn chủ động: là những nguồn tài nguyên mà có thể thay đổi tình trạng của chúng một cách độc lập với tác tử điều khiển.

Các nguồn tài nguyên thụ động

Các nguồn tài nguyên thụ động, ví dụ nhƣ một cơ sở dữ liệu bị điều khiển hoàn toàn bởi tác tử tƣơng tác, một file dữ liệu trong hệ thống file cục bộ hoặc một thƣ viện C cung cấp các chức năng điện toán. Việc tƣơng tác với các nguồn bị động nằm ngoài phạm vi của phƣơng pháp luận này . Hơn nữa, một tác tử trên nền tảng JADE, về mặt hiệu quả , là một bộ phận của mã Java và những kỹ thuật Java chuẩn có thể đƣợc sử dụng để xử lý những trƣờng hợp nhƣ thế này.

Trong trƣờng hợp của một cơ sở dữ liệu, JDBC nên đƣợc sử dụng, trong trƣờng hợp của một file dữ liệu nên sử dụng java.io, và trong trƣờng hợp của một thƣ viện C, nên sử dụng JNI. Đây là các kỹ thuật Java chuẩn và những giải thích của chúng nằm ngoài phạm vi phƣơng pháp luận đã đƣợc đƣa ra.

Các nguồn tài nguyên chủ động

Các nguồn tài nguyên chủ động, ví dụ nhƣ một cơ sở dữ liệu nơi một ngƣời điều hành (hay một chƣơng trình ngoài) có thể thêm vào hoặc sửa đổi dữ liệu, một log file đƣợc liên tục điền vào, cập nhật bởi một chƣơng trình ngoài, một thiết bị có thể cảnh báo và các phần mềm điều khiển, các cảm biến có thể dò thấy những thay đổi trong môi trƣờng cục bộ.

Các nguồn tài nguyên chủ động có thể cung cấp một giao diện dựa trên ngƣời nghe sao cho tác tử điều khiển có thể ngay lập tức phát hiện ra những thay đổi bên trong nội tại tài nguyên đó. Trong những trƣờng hợp khác, nguồn có thể cung cấp một giao diện với những phƣơng thức mà sẽ chặn sự kiện cho tới khi một sự thay đổi bị phát hiện ra. Ví dụ nhƣ, network socket, nơi mà ngƣời ta hy vọng sẽ nhận đƣợc một số dữ liệu ở đó. Cuối cùng, trong một số trƣờng hợp nhất định, cách duy nhất để có thể dò ra những thay đổi thích đáng trong một nguồn tài nguyên chủ động là thăm dò định kỳ chính nguồn đó.

Mặc dù một số phƣơng pháp có thể xử lý những nguồn tài nguyên chủ động, một phƣơng pháp đƣợc đƣa ra cố gắng để đồng nhất tất cả những tổ hợp của các

trƣờng hợp có thể đƣợc mô tả ở trên. Một số nguyên tắc nên đƣợc áp dụng trong bƣớc này:

1. Nếu không có sẵn các bộ nghe, hãy sử dụng một luồng Java chuyên dụng,

hoặc một tập các luồng mô phỏng lại hoạt động của một Bộ nghe để phát hiện ra những thay đổi thích hợp bên trong nguồn tài nguyên và hành động nhƣ một bộ nhận biết.

2. Cung cấp cho bộ nhận biết một bộ nghe để cho mỗi cuộc gọi từ phía ngƣời

thông báo sẽ mang lại kết quả là hành vi thích hợp theo các tình huống.

3. Khi triển khai nên sử dụng đối tƣợng jade.util.Event và phƣơng thức

waitUntilProcessed( ) của nó và các phƣơng thức notifyProcessed( ) để đồng bộ hóa các bộ nghe và các hành vi. Khi kết quả đƣợc tạo ra bởi hành vi phải đƣợc trả lại cho bộ nghe nhƣ là giá trị trả về của phƣơng thức thuộc bộ nghe.

Phƣơng pháp đã đƣợc đƣa ra khá linh hoạt và tránh đƣợc các vấn đề về đồng bộ hóa giữa các luồng ngƣời thông báo và chuỗi tác tử bởi vì tất cả các quá trình hoạt động thích hợp đƣợc thực hiện bởi chuỗi tác tử bên trong những hành vi đƣợc thêm vào. Hơn nữa, việc sử dụng những hành vi khác nhau để phục vụ các sự kiện đƣợc