MỤC LỤC
MỞ ĐẦU 4
CHƯƠNG 1 GIỚI THIỆU VỀ CƠ SỞ THỰC TẬP .6
1.1 Lịch sử thành lập và phát triển của công ty qua các giai đoạn 6
1.2 Tổ chức bộ máy quản lý của công ty .7
1.3 Các sản phẩm - Dịch vụ chính của Công ty Điện toán và truyền số liệu 9
1.4 Định hướng phát triển 9
CHƯƠNG 2 CÔNG NGHỆ TÁC TỬ .12
2.1 Khái niệm về tác tử 12
2.2 Các đặc điểm của tác tử .13
2.3 Các thành phần cơ bản của tác tử 14
2.3.1 Kiến trúc của đơn tác tử 14
2.3.2 Cảm nhận và tác động .15
2.3.2.1 Cảm nhận 15
2.3.2.2 Tác động .17
2.3.3 Cơ chế ra quyết định .17
2.3.3.1 Mô hình chung 17
2.3.3.2 Tác tử phản xạ 18
2.3.3.3 Tác tử có trạng thái .19
2.3.3.4 Tác tử hành động có mục đích 21
2.3.3.5 Tác tử với cơ chế suy diễn logic . 23
2.3.4 Hệ đa tác tử-Phối hợp trong hệ đa tác tử .26
2.3.4.1 Phối hợp và tầm quan trọng đối với hệ đa tác tử 26
2.3.4.2 Chia sẻ công việc 29
2.3.4.3 Chia sẻ kết quả 31
2.3.4.4 Phối hợp nhờ cấu trúc .32
2.3.4.5 Phối hợp nhờ quy tắc và luật 33
2.3.4.5.1 Hình thành quy tắc và luật lệ .33
2.3.4.5.2 Quy tắc dựng sẵn .35
2.3.4.6 Phối hợp thông qua ý định chung .36
2.3.4.7 Phối hợp nhờ lập kế hoạch .39
2.5 Các lĩnh vực ứng dụng .40
2.5.1 Ứng dụng trong quản lý sản xuất 40
2.5.2 Tác tử quản lý quá trình và luồng công việc(workflow) .40
2.5.3 Tác tử thu thập và quản lý thông tin .41
2.5.4 Tác tử phục vụ thương mại điện tử 41
2.6 Ưu nhược điểm của tác tử và công nghệ tác tử .42
CHƯƠNG 3 CÔNG NGHỆ PHẦN MỀM HƯỚNG TÁC TỬ .45
3.1 Tiếp cận hướng tác tử cho công nghệ phần mềm 45
3.2 Phần mềm hướng tác tử là gì? .47
3.3 Tiếp cận hướng tác tử cho các hệ thống phần mềm 50
3.3.1 Các phân rã hướng tác tử 50
3.3.2 Các trừu tượng hoá hướng tác tử cho các hệ thống phần mềm phức tạp 52
3.3.3 Sự thay đổi các cấu trúc trong tổ chức tạo quản lý mềm dẻo .53
3.4 Vòng đời phần mềm hướng tác tử .54
3.4.1 Đặc tả (Specification) 54
3.4.2 Thực hiện (Implementation) .56
3.4.2.1 Làm mịn (Refinement) .57
3.4.2.2 Việc thực hiện trực tiếp các đặc tả tác tử 57
3.4.2.3 Việc biên dịch các đặc tả tác tử 59
3.4.2.4 Sự xác minh 61
3.4.3 Các hướng tiếp cận tiêu đề (axiomatic) 61
3.4.3.1 Sự tiên đề hoá hai ngôn ngữ đa tác tử 62
3.4.3.2 Các hướng tiếp cận ngữ nghĩa: kiểm tra mô hình 62
3.5 Phương pháp luận hướng tác tử .64
3.5.1 Phương pháp Prometheus .64
3.5.2 Phương pháp Tropos .65
3.5.3 Phương pháp Gaia .66
3.6 Một số ví dụ về ứng dụng công nghệ tác tử . .68
Kết luận và đánh giá 74
Tài liệu tham khảo .75
75 trang |
Chia sẻ: banmai | Lượt xem: 2208 | Lượt tải: 0
Bạn đang xem trước 20 trang tài liệu Tác tử - Công nghệ phần mềm hướng tác tử, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
ôi trường và có khả năng hành động mềm dẻo, tự trị trong môi trường đó để đạt được các mục tiêu thiết kế của nó”.
Có một số vấn đề định nghĩa này cần giải thích rõ hơn. Các tác tử là: các thực thể có thể nhận dạng rõ ràng của bài toán đang được giải quyết với các giao diện và ranh giới rõ ràng; được đặt trong một môi trường cụ thể- chúng nhận các đầu vào từ trạng thái của môi trường thông qua các bộ cảm nhận của chúng và tác động lên môi trường thông qua cơ quan cảm ứng của chúng; được thiết kế để thực hiện một vai trò cụ thể- chúng có các mục tiêu cụ thể cần đạt đến, có thể rõ ràng hay không rõ ràng trong các tác tử; tự trị-chúng kiểm soát qua trạng thái trong và các hành vi của chúng; Có khả năng thể hiện hành vi giải quyết vấn đề mềm dẻo (phụ thuộc ngữ cảnh)- chúng cần reactive (có thể phản ứng ngay lập tức với những thay đổi của môi trường để thoả mãn các mục tiêu thiết kế của chúng) và proactive (có khả năng cập nhật các mục đích mới và nắm thế chủ động để thoả mãn mục tiêu thiết kế của chúng).
Khi nhìn nhận thế giới theo kiểu hướng tác tử, sẽ sớm rõ ràng rằng một tác tử đơn lẻ là không đủ. Hầu hết các bài toán đòi hỏi hoặc là liên quan đến đa tác tử: để thực hiện tính chất phân quyền của bài toán, đa quỹ tích của điều khiển, đa viễn cảnh hay các quan tâm cạnh tranh. Hơn nữa, các tác tử sẽ cần để tương tác với các tác tử khác, để đạt được các mục tiêu riêng của chúng hoặc để điều khiển các phụ thuộc sinh ra từ các trạng thái trong môi trường chung. Các tương tác này xuyên suốt từ các thao tác ngữ nghĩa đơn giản (khả năng thay đổi các giao tiếp toàn diện) qua các tương tác kiểu client-server truyền thống (khả năng yêu cầu một hành động cụ thể được thực hiện), tới các tương tác xã hội (khả năng phối hợp, điều phối và thương thuyết về cách thức của hành động). Tuy nhiên, bất cứ tính chất nào của quá trình xã hội cũng có hai điểm tương tác tác tử khác biệt định tính mà từ đó xuất hiện ở các mô hình công nghệ phần mềm khác. Thứ nhất, các tương tác hướng tác tử thường xảy ra ở ngôn ngữ giao tiếp tác tử bậc cao (điển hình dựa vào lý thuyết hành vi ngôn ngữ). Do đó, các tương tác thường là được điều khiển ở mức tri thức: trong các giới hạn mà các mục đích nên theo. Thứ hai, vì tác tử là giải pháp mềm dẻo cho bài toán, việc thao tác trên một môi trường mà qua đó chúng chỉ có quan sát và điều khiển cục bộ, các tương tác cần được xử lý trong một kiểu mềm dẻo tương tự, bởi vậy các tác tử cần dụng cụ tính toán để đưa ra các quyết định phụ thuộc vào ngữ cảnh về tính chất và phạm vi của các tương tác của chúng và để bắt đầu (hoặc đáp ứng) các tương tác mà không cần thiết được dự đoán trước ở giai đoạn thiết kế.
Trong hầu hết các trường hợp, các tác tử hành động để đạt đến mục tiêu đại diện cho các thành phần riêng lẻ hay các hệ thống. Vì vậy, khi các tác tử tương tác, thường có một số ngữ cảnh cơ bản thuộc tổ chức. Ngữ cảnh này trợ giúp việc định nghĩa tính chất của mối quan hệ giữa các tác tử. Ví dụ, chúng có thể hoạt động ngang hàng trong một nhóm, một tác tử có thể là ông chủ của các tác tử khác, hoặc chúng có thể được bao hàm trong một loạt các mối quan hệ chủ-tớ. Để giành được các liên kết đó, các hệ thống tác tử thường có cấu trúc rõ ràng cho việc mô hình các mối quan hệ tổ chức (chẳng hạn như peer,boss,..) và các cấu trúc tổ chức(chẳng hạn như là teams,groups,...). Nên lưu ý rằng trong nhiều trường hợp, các mối quan hệ này có thể thay đổi trong khi hệ thống hoạt động. Tương tác xã hội có nghĩa là sự tồn tại các mối quan hệ tiến hoá (chẳng hạn một tác tử quyết định một giao dịch mới) và các mối liên hệ mới được tạo ra (chẳng hạn như một số tác tử có thể hình thành một nhóm để đưa ra một dịch vụ cụ thể mà không một cá nhân nào có thể đề nghị). Phạm vi thời gian của các mối quan hệ đó có thể được thay đổi nhiều: từ chỗ chỉ đủ dài để đưa ra một dịch vụ cụ thể một lần tới một liên kết lâu dài. Để đương đầu với sự thay đổi về biến động này, các nhà nghiên cứu tác tử đã có những nỗ lực đáng kể: phát minh ra các giao thức mà cho phép các nhóm tổ chức được hình thành và giải tán, chỉ rõ cac cơ chế để bảo đảm các nhóm hoạt động cùng nhau trong mô hình kết dính, và phát triển các cấu trúc để mô tả đặc điểm các hành vi vĩ mô của các tập hợp.
Hình 3.2 Quan điểm kinh điển hệ thống đa-tác tử
Bằng cách vẽ các vấn đề trên cùng nhau, ta có thể thấy việc chấp nhận một hướng tiếp cận hướng tác tử với công nghệ phần mềm có nghĩa là việc phân rã bài toán thành nhiều thành phần tương tác và tự trị (tác tử) mà có các mục tiêu cụ thể đạt tới. Các mô hình trừu tượng chủ yếu định nghĩa “agent-oriented mindset” là các tác tử, các tương tác và các tổ chức. Cuối cùng, các cấu trúc và cơ chế rõ ràng thường là có sẵn cho việc mô tả và điểu khiển sự phức tạp và thay đổi một mạng các mối quan hệ tổ chức mà tồn tại giữa các tác tử.
3.3 TIẾP CẬN HƯỚNG TÁC TỬ CHO CÁC HỆ THỐNG PHẦN MỀM
Từ các mô tả về các hệ thống phức tạp và phần mềm hướng tác tử ở trên, chúng ta xem xét tại sao các kỹ thuật hướng tác tử lại phù hợp với việc phát triển các hệ thống phần mềm này. Vấn đề có 3 phần:
Chỉ ra rằng các phân rã hướng tác tử là một cách hiệu quả để phân chia không gian bài toán của một hệ thống phức tạp.
Chỉ ra rằng các sự trừu tượng chủ yếu của mindset hướng tác tử là một cách tự nhiên để mô hình hoá các hệ thống phức tạp.
Chỉ ra rằng triết lý hướng tác tử cho việc nhận dạng và điều khiển các mối quan hệ là thích hợp cho việc xử lý với các phụ thuộc và tương tác tồn tại trong một hệ thống phức tạp.
Để làm cho công nghệ phần mềm hướng tác tử thuyết phục hơn, bước cuối cùng là chứng tỏ rằng các kỹ thuật hướng tác tử thể hiện một sự tiến bộ thật sự qua tình trạng hiện thời của kỹ thuật. Với mục đích này, tiếp cận hướng tác tử sẽ được so sánh với các kỹ thuật hướng lề (leding-adge) từ công nghệ phần mềm xu hướng chính. Đặc biệt, nó bao hàm các sự so sánh với phân tích và thiết kế hướng đối tượng (hệ thống được xây dựng bằng các đối tượng tương tác mà đóng gói cả dữ liệu và thủ tục thao tác trên dữ liệu) và với cpmponent-ware (hệ thống được xây dựng bởi việc tập hợp các thành phần tồn tại sẵn vào một số cấu trúc tổng thể).
3.3.1 Các phân rã hướng tác tử
Các hệ thống phức tạp bao gồm các hệ thống con có liên quan được tổ chức lại với nhau trong một mô hình phân cấp (hình 3.1). Ở một mức độ nào đó, các hệ thống con hoạt động cùng nhau để đạt đến chức năng của hệ thống cha của chúng. Hơn nữa, trong một hệ thống con, các thành phần hợp thành hoạt động cùng nhau để đưa ra chức năng tổng thể. Bởi vậy, mô hình cơ bản tương tự của các thành phần tương tác hoạt động cùng nhau để đạt tới các mục tiêu cụ thể xuất hiện trong hệ thống.
Từ trạng thái được đưa ra trên đây, việc modul hoá các thành phần là hoàn toàn tự nhiên trong giới hạn các mục tiêu mà chúng cần đạt đến. Nói cách khác, mỗi thành phần có thể được nghĩ về như là việc đạt tới một hay nhiều mục tiêu. Một quan sát quan trọng thứ hai là các hướng công nghệ phần mềm hiện tại đang tăng mức độ của cục bộ hoá và gói gọn trong các phân rã bài toán. Việc ứng dụng triết lý này vào các phân rã các mục tiêu đạt tới có nghĩa là các thành phần đơn lẻ nên có một thành phần điều khiển riêng của chúng (tức là các thành phần nên chủ động) và chúng nên gói gọn thông tin và cần khả năng giải quyết vấn đề để đạt được các mục tiêu này. Vì các thành phần thường là phải thao tác trong một môi trường mà trong đó chúng chỉ có một phần thông tin, chúng phải có khả năng quyết định ở thời gian chạy hành động nào nên thực hiện để đuổi theo các mục tiêu của chúng. Tóm lại, các thành phần cần tự trị qua các lựa chọn hành động của chúng.
Với các thành phần chủ động và tự trị để thực hiện các mục tiêu cá nhân và tập thể, chúng cần phải tương tác với nhau (lưu ý rằng các hệ thống phức tạp là có thể được phân rã). Tuy nhiên sự phức tạp của hệ thống là vốn có, nghĩa là nó không thể biết về tất cả các liên hệ trong tương lai: tương tác sẽ xảy ra ở một thời điểm không thể đoán, với các lý do không thể đoán được, giữa các thành phần không thể dự đoán. Vì lý do này, việc cố gắng để dự đoán hoặc phân tích tất cả khả năng trong giai đoạn thiết kế là vô ích. Thực tế hơn là cung cấp cho các thành phần một khả nằng đưa ra các quyết định về tính chất và phạm vi của các tương tác ở thời gian chay. Từ đó dẫn đến các thành phần cần một khả năng để khởi sướng (và đáp ứng) các tương tác một cách mềm dẻo.
Cách giải quyết làm theo các quyết định thi hành về các tương tác thành phần làm cho việc thực hiện các hệ thống phức tạp một cách dễ dàng trong hai cách. Thứ nhất, các vấn đề liên quan đến sự kết nối của các thành phần giảm một cách đáng kể (bằng việc xử lý chúng theo cách mềm dẻo và khai báo). Cách thành phần được thiết đặc biệt để giải quyết với các yêu cầu không thể đoán trước và có thể đưa ra các yêu cầu hỗ trợ nếu chúng gặp khó khăn. Hơn nữa, vì các tương tác này được đưa ra qua một mức ngôn ngữ giao tiếp bậc cao, sự kết nối trở thành một vấn đề mức tri thức. Điều này lần lượt loại bỏ những quan tâm ở mức cú pháp từ các kiểu của lỗi được gây ra bởi các tương tác không mong đợi. Thứ hai, vấn đề kiểm soát điều khiển các mối quan hệ giữa các thành phần phần mềm bị giảm một cách đáng kể. Tất cả tác tử liên tục hoạt động và một số điều phối hoặc sự đồng bộ hoá được yêu cầu được điều khiển qua tương tác trong tác tử. Vì vậy trật tự của các mục đích mức đỉnh của hệ thống không phải được quy định một cách cứng nhắc ở giai đoạn thiết kế. Đúng hơn, nó thể xử lý theo các tác động của ngữ cảnh ở thời gian chạy.
Từ lý do này, một cách tự nhiên để modul hóa một hệ thống phức tạp trong một giới hạn của nhiều thành phần tương tác, tự trị có các mục tiêu cụ thể đạt tới là đã rõ ràng. Tóm lại, các phân rã hướng tác tử làm cho việc phát triển các hệ thống phức tạp dễ dàng hơn.
3.3.2 Các trừu tượng hoá hướng tác tử cho các hệ thống phần mềm phức tạp
Tất cả các nỗ lực thiết kế chủ yếu là để tìm ra các mô hình mô tả bài toán. Nhìn chung, sẽ có nhiều ứng cử viên và nhiệm vụ khó khăn là chọn ra ứng cử viên thích hợp nhất. Trở lại với trường hợp cụ thể của việc thiết kế phần mềm, các trìu tượng hoá mạnh nhất giảm thiểu được các thiếu sót về ngữ nghĩa giữa các đơn vị của phân tích mà được sử dụng bởi trực giác để khái niệm hoá một vấn đề và các cấu trúc thể hiện trong mô hình giải quyết. Trong trường hợp này, vấn đề được mô tả bao gồm các hệ thống con, các tương tác và các mối quan hệ thuộc tổ chức. Lần lượt như sau:
Trường hợp quan sát các thành phần hệ thống con như là tác tử được tạo ra ở trên.
Sự ảnh hưởng lẫn nhau giữa các hệ thống con và giữa các thành phần tạo thành các hệ thống con được coi là cơ bản nhất trong giới hạn của các tương tác xã hội mức cao: “Ở một mức độ trừu tượng cho trước, ta tìm thấy tập hợp các đối tượng mà cộng tác với nhau để đạt được các quan điểm mức cao hơn”. Quan điểm này phù hợp với cách quản lý mức tri thức (hoặc thậm chí mức xã hội) của tương tác được đưa ra bởi tiếp cận hướng tác tử. Các hệ thống tác tử được mô tả cố định trong giới hạn của “sự phối hợp để đạt được các mục đích chung”, “sự điều phối các hành động của chúng” hoặc “sự thương lượng để giải quyết xung đột”. Vì vậy, mindset hướng tác tử là hoàn toàn phù hợp cho việc kiểm soát các kiểu tương tác xảy ra trong các hệ thống phức tạp.
Các hệ thống phức tạp bao gồm sự thay đổi các mạng quan hệ giữa các thành phần khác nhau. Chúng cũng yêu cầu các tập hợp các thành phần được xử lý như là một đơn vị khái niệm đơn lẻ khi được quan sát từ một mức độ trừu tượng khác. Một lần nữa, quan điểm này phù hợp với sự trừu tượng hoá được cung cấp bởi mindset hướng tác tử. Vì vậy, các phương tiện thường là được cung cấp cho việc biểu diễn rõ ràng các mối quan hệ thuộc tổ chức. Các giao thức tương tác được phát triển để hình thành các nhóm mới và huỷ những nhóm không cần thiết. Cuối cùng, các cấu trúc là sẵn có cho việc mô hình hoá các tập hợp. Điểm sau đó là đặc biết co ích trong mối quan hệ với việc biểu diễn các hệ thống con vì chúng chỉ là một nhóm các thành phần hoạt động cùng nhau để đạt đến một mục đích chung.
3.3.3 Sự thay đổi các cấu trúc trong tổ chức tạo quản lý mềm dẻo
Các hệ thống phức tạp có các mối quan hệ tổ chức đa dạng phong phú, xuyên suốt từ các thành phần ngang hàng tới việc điều khiển các cây phân cấp, từ ngắn hạn đến liên tục. Các mối quan hệ này là quan trọng vì hai lý do. Thứ nhất, chúng cho phép một số các thành phần riêng lẻ được gom nhóm lại với nhau và xử lý như là một thực thể khái niệm đơn lẻ. Thứ hai, chúng cho phép mô tả đặc điểm các mối liên kết mức cao giữa các thực thể khác nhau. Sự ảnh hưởng và tác động đã biết về các mối quan hệ và các cấu trúc tổ chức trên hành vi của hệ thống, sự quan trọng của việc cung cấp hỗ trợ rõ ràng cho việc chỉ rõ và điều khiển mềm dẻo là bản thân một bằng chứng. Hơn nữa, các mối quan hệ thì liên tục thay đổi, khả năng để thích nghi một cách linh động để nắm ưu thế các hoàn cảnh cũng là cần thiết.
Như đã đưa ra ở trên, các tổ chức là các thực thể ở lớp đầu tiên trong các hệ thống tác tử. Vì vậy, các cấu trúc rõ ràng và các cơ chế mềm dẻo là trung tâm cho mô hình tác tử. Khả năng biểu diễn này khi được liên kết với các cơ chế tính toán hỗ trợ, cho phép các hệ thống hướng tác tử phân rã thành hai khía cạnh của tính chất các hệ thống phức tạp.Thứ nhất, khái niệm của thành phần nguyên thuỷ có thể thay đổi theo nhu cầu của người quan sát. Do đó ở mức 1, các hệ thống còn lại có thể được coi như là một singleton (một thực thể duy nhất), các nhóm hay tập hợp thay thế của các tác tử có thể được coi như là các thành phần nguyên thuỷ và cứ như vậy cho đến khi hệ thống cuối cùng được phân rã hết. Thứ hai, các cấu trúc này cung cấp một sự đa dạng các forms trung gian ổn định cần thiết cho sự phát triển nhanh các hệ thống phức tạp. Tính sẵn có của chúng có nghĩa là các tác tử đơn lẻ hoặc nhóm tổ chức có thể được phát triển trong sự cô lập về quan hệ và sau đó được thêm vào hệ thống theo cách thức tăng trưởng. Điều này lần lượt đảm bảo rằng có một sự làm mịn chức năng.
3.4 VÒNG ĐỜI PHẦN MỀM HƯỚNG TÁC TỬ
Chúng ta đã hiểu tại sao các kỹ thuật hướng tác tử thể hiện một cách tiếp cận đầy hứa hẹn cho việc xây dựng các hệ thống phức tạp, chúng ta có thể đi vào chi tiết của công nghệ phần mềm hướng tác tử, thảo luận về cách thực hiện các đặc tả này và khảo sát tỉ mỉ cách xác nhận các hệ thống đã được thực hiện trong thực tế là thoả mãn các đặc tả của chúng.
3.4.1 Đặc tả (Specification)
Trong phần này chúng ta xem xét bài toán đặc tả một hệ thống tác tử. Các yêu cầu cho một khung đặc tả tác tử. Các kiểu thuộc tính có thể được thể hiện. Theo cách nhìn các tác tử được thảo luận ở trên, cách tiếp cận nổi bật để đặc tả các tác tử bao gồm cả việc xử lý chúng như là các hệ thống có mục đích có thể được hiểu bằng cách quy cho chúng các trạng thái tri thức chẳng hạn như lòng tin, mong muốn và mục đích. Dựa vào ý tưởng này, một số cách tiếp cận cho việc đặc tả một cách hình thức các tác tử đã được phát triển, có khả năng thể hiện các hướng sau đây của một hệ thống tác tử:
Beliefs: thông tin mà các tác tử có về môi trường xung quanh nó, có thể không đầy đủ hoặc không chính xác.
Goals: là các mục đích mà các tác tử cố gắng đạt đến;
Action: các hành động mà các tác tử thực hiện và các ảnh hưởng của các hành động đó
Ongoing interaction: cách mà tác tử tương tác với cá tác tử khác trong môi trường của chúng qua thời gian.
Ta gọi lý thuyết giải thích các hướng tương tác kiểu tác tử để đạt đến ánh xạ từ đầu vào và đầu ra là một lý thuyết tác tử. Lý thuyết về tác tử thành công nhất là ứng dụng của một temporal modal logic (các giới hạn không gian ngăn chặn sự thảo luận kỹ thuật chi tiết trên các logic-see, chẳng hạn như cho các tham khảo rộng rãi). Hai trong số các khung logic nổi tiếng nhất là lý thuyết Cohen-Levesque về mục đích và mô hình Rao-Georgeff belief-desire-intention. Mô hình Cohen-Levesque về lúc đầu chỉ có hai quan điểm: belief và goals. Các quan điểm khác (cụ thể là khái niệm intention) được xây dựng từ đó. Ngược lại, Rao-Georgeff lại coi intention là cơ bản ban đầu, thêm vào đó là belief và goals. Vấn đề kỹ thuật chính của các nhà lý thuyết tác tử là việc phát triển một mô hình chính thức có thể đưa ra một lời giải thích phù hợp cho các mối quan hệ bên trong giữa các quan điểm khác nhau tạo nên một tác tử. Các nỗ lực tương đối ít quan trọng hơn được đưa ra nhằm chỉ rõ các hệ thống tác tử thực sự sử dụng logics-see.
Một khung đặc tả tác tử modal temporal điển hình bao gồm:
Các kết nối logic hình thức chuẩn cho việc thể hiện các beliefs của tác tử;
Các kết nối logic thời gian cho việc thể hiện về xử lý động của hệ thống-các hành vi được phát triển liên tục của nó;
Các kết nối logic hình thức chuẩn cho việc thể hiện các mục đích (chẳn hạn như desires, intention, obligations);
Một số các bộ phận quan trọng cho việc thể hiện các hành động mà các tác tử thực hiện.
Từ các yêu cầu đã cho này, có nhiều chiều hướng mà một khung đặc tả tác tử có thể thay đổi, một số hướng được tổng hợp trong bảng sau:
Các khía cạnh thông tin:
Tri thức
Lòng tin
Tập hợp các quan điểm thông tin
Các khía cạnh thời gian:
Tuyến tính đối với phân nhánh
Dày đặc đối với rời rạc
Tham khảo trực tiếp đối với cá thao tác căng thẳng
Dựa điểm đối với dựa vào khoảng
Các khía cạnh mục đích:
Mong muốn
Mục đích
Nghĩa vụ
Lựa chọn
Tập các quan điểm thay thế
Các hành động
Biểu diễn trực tiếp
Biểu diễn ẩn
3.4.2 Thực hiện (Implementation)
Một khi đã có một đặc tả, ta phải thực hiện một hệ thống đúng đắn với đặc tả này. Vấn đề tiếp theo là sự chuyển đổi từ một đặc tả trừu tượng sang một hệ thống tính toán cụ thể. Ở đây ta xem xét hai khả năng để thực hiện sự chuyển đổi này:
Làm mịn thủ công đặc tả thành một form có thể thực hiện được theo các nguyên lý nào đó, nhưng không phải là một quá trình làm mịn chính thức (như trong hầu hêt sự phát triển phần mềm hiện nay).
Bằng cách nào đó thực hiện trực tiếp hoặc hoạt hoá đặc tả trừu tượng;
Hoặc bằng cách nào đó chuyển đổi hoặc biên dịch đặc tả thành mẫu tính toán cụ thể sử dụng một kỹ thuật chuyển đổi tự động.
3.4.2.1 Làm mịn (Refinement)
Hầu hết các nhà phát triển phần mềm sử dụng các kỹ thuật cấu trúc không chính thức để chuyển các đặc tả thành các thực hiện cụ thể. Hầu hết các kỹ thuật được ứng dụng rộng rãi dựa vào ý tưởng làm mịn top-down. Trong cách tiếp cận này, một đặc tả hệ thống trừu tượng được làm mịn thành các đặc tả hệ thống con nhỏ hơn và ít trừu tượng hơn mà cùng nhau thoả mãn đặc tả ban đầu. Nếu các hệ thống con này vẫn còn quá trừu tượng cho việc thực hiện trực tiếp thì chúng vẫn tiếp tục được làm mịn. Tù đầu đến cuối, ta bị bắt buộc phải chứng minh rằng mỗi bước thể hiện một sự làm mịn đúng đắn của đặc tả trừu tượng hơn được đặt trước nó. Sự chưng minh này có thể đưa ra form chứng minh hình thức nếu như đặc tả của ta được thể hiện trong đó gọi là Z hoặc là VDM. Sự chứng minh bằng tham số không chính thức là thường dùng hơn.
Với các hệ thống chức năng, quá trình làm mịn được hiểu rõ và tương đối dễ hiểu. Tồn tại các công thức làm mịn cho phép người phát triển hệ thống đưa ra các đặc tả trước và sau điều kiện mà mô tả đặc điểm các cấu trúc thao tác và chương trình được yêu cầu để thực hiện.
Với các hệ thống phản xạ, việc làm mịn là không quá dễ dàng, vì các hệ thống phản xạ phải được chỉ rõ trong giới hạn của hành vi đang phát triển của chúng. Ngược lại, với các cơ chế hình thức trước và sau điều kiện thì không dễ để quyết định các cấu trúc chương trình nào được yêu cầu thực hiện các đặc tả này. Bài toán làm mịn cho các hệ thống hướng tác tử có các đặc tả có thể được đánh giá là thậm chí trừu tượng hơn với các hệ thống phản xạ là khó khăn. Từ đó, các nhà nghiên cứu chỉ mới bắt đầu khảo sát cách làm mịn các hệ thống dựa tác tử.
Một phương pháp luận cho các tác tử BDI
Mô hình BDI như đã nói ở trên là một trong những khung thành công nhất cho tác tử. Kiny và các đồng nghiệp đã giả sử một phương pháp thiết kế bốn giai đoạn cho các hệ thống các tác tử BDI. Phương pháp này liên kết gần gũi với một sự thực hiện cụ thể của mô hình BDI: kiến trúc PRS. Có thể tổng hợp phương pháp này theo các bước sau:
Nhận ra các vai trò liên quan trong lĩnh vực ứng dụng và từ đó phát triển một cây phân cấp lớp tác tử. Một vai trò ví dụ có thể là theo dõi thời tiết, trong đó tác tử I được yêu cầu để làm cho tác tử J biết được điều kiện thời tiết trong từng giờ.
Xác định các trách nhiệm liên quan vỡi mỗi vai trò, các dịch vụ được yêu cầu và được cung cấp bởi vai trò đó và sau đó quyết định mục đích liên quan với mỗi dịch vụ. Từ đó các mục đích có thể để tìm ra tình trạng thời tiết hiện tại và làm cho tác tử j biết được các thông tin này.
Với mỗi mục đích, quyết định các kế hoạch có thể được sử dụng để đạt được nó và dưới các điều kiện ngữ cảnh mà mỗi kế hoạch thoả mãn. Từ đó, một kế hoạch cho mục đích làm cho tác tử j hiểu được các điều kiện thời tiết có thể bao gồm việc gửi một thông điệp tới j.
Xác định cấu trúc niềm tin của hệ thống-các yêu cầu thông tin cho mỗi kế hoạch và mục đích. Từ đó ta có thể đưa ra một hàm dự đoán windspeed(x) để biểu diễn tốc độ gió hiện tại là x. Một kế hoạch cho việc xác định các điều kiện thời tiết hiện tại có thể cần thiết để biểu diễn thông tin này.
Lưu ý rằng qúa trình phân tích sẽ được lặp đi lặp lại như trong các phương pháp truyền thống hơn. Đầu ra sẽ là một mô hình gần tương đương với kiến trúc của tác tử PRS. Từ đó, việc chuyển từ bản thiết kế cuối cùng tới việc thực hiện sử dụng PRS là tương đối đơn giản.
Kinny và các cộng sự minh hoạ phương pháp của họ bằng việc ứng dụng nó vào việc thực hiện hệ thống quản lý giao thông trên không OASIS.
3.4.2.2 Việc thực hiện trực tiếp các đặc tả tác tử
Giả sư rằng chúng ta có một đặc tả hệ thống được biểu diễn trong một số ngôn ngữ logic L. Một cách để đạt được một hệ thống cụ thể từ là coi nó như là một đặc tả có thể thực hiện được, và thông dịch đặc tả một cách trực tiếp để tạo ra hành vi của tác tử. Việc thông dịch một đặc tả tác tử có thể được xem như là một kiểu chứng minh suy diễn của sự thoả mãn, nhờ đó ta thấy được đặc tảlà thoả mãn việc xây dựng một mô hình (về ý nghĩa logic) cho nó. Nếu các mô hình với ngôn ngữ đặc tả L có thể được đưa ra một sự thông dịch tính toán, sau đó việc xây dựng mô hình có thể được coi như là việc thực hiện đặc tả. Để làm rõ hơn vấn đề này, ta xem xét ngôn ngữ lập trình Cocurent Metate M. Trong ngôn ngữ này, các tác tử được lập trình bằng cách trao cho chúng một đặc tả logic thời gian của hành vi, chúng được lưu ý là nên thể hiện; đặc tả này được thực hiện trực tiếp để tạo ra mỗi hành vi của tác tử. Vì vậy, các mô hình cho logic thời gian trong đó đặc tả tác tử MetateM hiện tại là quá trình của việc xây dựn một chuỗi các trạng thái. Do đó chuỗi các trạng thái có thể được coi như là các lịch sử được xác định bằng các chương trình khi chúng thực hiện, logic thời gian dựa vào Concurrent MetateM có một sự thông dịch tính toán.
Lưu ý rằng việc thực hiện các đặc tả tác tử Concurrent MetateM có thể là cơ bản vì các mô hình theo logic thời gian có nền tảng tương đối đơn giản, với một sự thông dịch tính toán rõ ràng và thuộc về trực giác. Tuy nhiên các ngôn ngữ đặc tả tác tử nhìn chung là được dựa trên các logic phức tạp hơn (chẳng hạn như cơ chế hình thức BDI của Rao và Georgeff). Đặc biệt chúng thường dựa trên một khung ngữ nghĩa được coi như là possible worlds.
3.4.2.3 Việc biên dịch các đặc tả tác tử
Một sự thay đổi cho việc thực hiện trực tiếplà sự biên dịch (compilation). Theo ý đồ này, ta biết được đặc tả trừu tượng và chuyển đổi chúng thành một mô hình tính toán cụ thể qua một số quá trình tổng hợp tự động. Có thể nhận thấy các ưu điểm của sự biên dịch qua việc thực hiện trực tiếp trong hiệu xuất thi hành. Việc thực hiện trực tiếp của một đặc tả tác tử, chẳng hạn như trong Concurrent MetateM ở trên điển hình bao gồm sự thực hiện một biểu diễn tượng trưng của đặc tả ở thời gian chạy. Sự thực hiện này tương đương với việc suy diễn của một số mẫu đáng giá tính toán. Các hướng tiếp cận biên dịch giúp giảm bớt các đặc tả trừu tượng thành một mô hình tính toán đơn giản hơn mà không yêu cầu sự biểu diễn tượng trưng. Việc suy diễn bởi vậy được thực hiện off-line ở thời điểm biên dịch; việc thực hiện của hệ thống được biên dịch sau đó có thể được thực hiện với rất ít hoặc không có suy diễn tượng trưng ở thời điểm thi hành.
Stituated Automata: Các máy tự động trạng thái
Các hướng tiếp cận biên dịch thường dựa vào mối quan hệ thân thiết giữa các mô hình logic thời gian/hình thức, và các máy trạng thái giống các máy tự động. Ví dụ, Pnueli và Rosner tổng hợp các hệ thống phản xạ từ việc phân chia các đặc tả logic thời gian. Các kỹ thuật tương tự cũng đã được sử dụng để phát triển các nhân hệ thống trùng hợp từ các đặc tả logic thời gian. Có thể ví dụ điển hình nhất cho hướng tiếp cận này của việc phát triển tác tử là mô hình các máy tự động trạng thái (stituated automata). Họ sử dụng một logic thuộc tri thức (tức là một logic của nhận thức) để chỉ rõ thành phần nhận thức của các hệ thống tác tử thông minh. Sau đó họ sử dụng một kỹ thuật dựa vào chứng minh suy diễn để tổng hợp trực tiếp các máy tự động từ các đặc tả này.
Trong hướng tiếp cận các máy tự động trạng thái, một tác tử có 2 thành phần chính:
Một bộ phận tri giác (perception) có trách nhiệm quan sát môi trường và cập nhật trạng thái trong của tác tử.
Một bộ phận hành động (action) có trách nhiệm quyết định các hành động để thực hiện, dựa trên trạng thái bên trong của tác tử.
Rosenschein và Kaelbling đã phát triển hai chương trình tương ứng để hỗ trợ sự phát triển của các thành phần tri giác và hành động của tác tử.
Hướng tiếp cận chung của sự tổng hợp tự động, mặc dù hấp dẫn về lý thuyết nhưng lại bị giới hạn trong một số lượng của các mối quan hệ quan trọng. Thứ nhất, khi ngôn ngữ đặc tả tác tử trở nên ý nghĩa hơn, sau đó thậm chí suy diễn off-line được thực hiện. Thứ hai, các hệ thộng được tạo ra theo cách này là không có khả năng học, (chẳng hạn, chúng không có khả năng thích nghi chương trình của chúng ở thời gian thi hành). Cuối cùng như với các hướng tiếp cận thực hiện trực tiếp, các khung đặc tả tác tử có khuynh hướng không có thông dịch tính toán cụ thể, dẫn đến không thể tổng hợp.
3.4.2.4 Sự xác minh
Khi phát triển một hệ thống cụ thể, ta cần phải chỉ ra rằng hệ thống này là đúng đắn với những gì đã có trong đặc tả ban đầu. Quá trình này được gọi là sự xác minh, và nó đặc biệt quan trọng nếu ta đã giới thiệu một cách không chính thức vào quá trình phát triển. Chúng ta có thể chia các hướng tiếp cận theo sự xác minh của các hệ thống thành hai lớp: (1) axiomatic; và (2) sematic (kiểm tra mô hình).
3.4.3 Các hướng tiếp cận tiêu đề (axiomatic)
Các hướng tiếp cận tiêu đề cho việc xác minh chương trình đã đưa vào xu hướng chính của khoa học máy tính. Việc xác minh tiên đề yêu cầu ta có thể nắm được chương trình cụ thể của mình và từ chương trình đó tìm ra được một cách ngữ nghĩa một lý thuyết logic mà thể hiện hành vi của chương trình. Ta gọi nó là lý thuyết chương trình. Nếu như lý thuyết chương trình được biểu diễn trong một ngôn ngữ logic giống như của đặc tả ban đầu thì việc xác minh giảm tới một bài toán xác minh: chỉ ra rằng đặc tả là một định lý của lý thuyết chương trình.
Sự phát triển của một lý thuyết chương trình được tạo ra khả thi bằng cách tiên đề hoá ngôn ngữ lập trình trong đó hệ thống được thực hiện. Ví dụ, logic Hoare cho chúng ta ít hoặc nhiều hơn một tiên đề cho mỗi loại câu lệnh trong một ngôn ngữ giống Pascal đơn giản. Từ sự tiên đề hoá đã cho, lý thuyết chườn trình có thể đựơc đưa ra từ nguyên bản chương trình theo cách ngữ nghĩa.
Có thể nghiên cứu liên quan nhất từ xu hướng chung của khoa học máy tính là đặc tả và xác minh các hệ thống phản xạ sử dụng logic thời gian, được mở đường bơi pnueli, Manna và các đồng nghiệp. Ý tưởng là các việc tính toán của hệ thống phản xạ là các chuỗi không giới hạn mà tương đương với các mô hình cho logic thời gian tuyến tính. Logic thời gian có thể được sử dụng để phát triển một đặc tả hệ thống và để tiên đề hoá một ngôn ngữ lập trình. Sự tiên đề hoá này sau đó có thể được sử dụng để đưa ra một cách ngữ nghĩa lý thuyết của một chương trình từ nguyên bản chương trình. Các đặc tả và lý thuyết chương trình sau đó sẽ được mã hoá trong logic thời gian, và việc xác minh sau đó trở thành một bài toán chứng minh trong logic thời gian.
3.4.3.1 Sự tiên đề hoá hai ngôn ngữ đa tác tử
Một nghiên cứu tương đối nhỏ đã được thực hiện trong nhóm các hệ thống dựa tác tử trên sự tiên đề hoá các môi trường đa tác tử. Ta sẽ xem lại chỉ một hướng tiếp cận. Một tiếp cận tiên đề về việc xác minh của hệ thống đa tác tử được đề xuất. Về bản chất, ý tưởng là để sử dụng một logic belief thời gian để tiên đề hoá các thuộc tính của hai ngôn ngữ lập trình đa tác tử. Từ một sự tiên đề hoá đã biết, một lý thuyết chương trình thể hiện các thuộc tính của hệ thống có thể được đưa ra một cách hệ thống theo cách đã chỉ ra ở trên. Một logic belief thời gian đã được sử dụng vì hai lý do.
Trước hết, một thành phần thời gian được yêu cầu vì như đã quan sát ở trên, chúng ta cần nắm bắt hành vi đang xả ra của hệ thống đa tác tử. Một thành phần belief đã được sử dụng bởi vì các tác tử chúng ta muốn xác minh là mỗi hệ thống trí tuệ nhân tạo (AI) tượng trưng trong quyền của chính nó. Điều đó có nghĩa là mỗi tác tử là một hệ thống suy diễn tượng trưng bao gồm một sự biểu diễn môi trường của nó và hành vi mong ước. Một thành phần belief về mặt logic cho phép nắm bắt các biểu diễn tượng trưng thể hiện trong mỗi tác tử. Lưu ý rắng hướng tiếp cận này dựa vào thao tác của các tác tử là đơn giản một cách thoả đáng rằng các thuộc tính của chúng có thể được tiên đề hoá về mặt logic. Với các tác tử phức tạp hơn, một sự tiên đề hoá là không quá phức tạp. Hơn nữa, việc nắm bắt ngữ nghĩa của việc thực hiện đồng thời của các tác tử là không dễ dàng.
3.4.3.2 Các hướng tiếp cận ngữ nghĩa: kiểm tra mô hình
Sau cùng, sự xác minh tiên đề giảm chỉ còn là một bài toán chứng minh. Cách tiếp cận tiên đề để xác minh vốn đã bị giới hạn bởi sự phức tạp của bài toán chứng minh này. Các sự chứng minh là đủ phức tạp, thậm chí trong logic cổ điển; các kết nối hình thức hoặc thời gian đến một logic làm cho bài toán phức tạp hơn đáng kể. Vì lý do này, các hướng tiếp cận hiệu quả cho việc xác minh đã được yêu cầu. Một hướng tiếp cận thành công đặc biệt là kiểm tra mô hình (model checking). Như tên gọi đã gợi ý, trong khi tiếp cận tiên đề thường là dựa vào sự chứng minh cú pháp, cách tiếp cận kiểm tra mô hình được dựa trên ngữ nghĩa của ngôn ngữ đặc tả.
Về mặt lý thuyết, bài toán kiểm tra mô hình hoàn toàn đơn giản: một công thứccủa ngôn ngữ L được biết trước, mô hình của L, xác định cho dùcó hợp lệ trong M hay không, tứclà. Sự xác minh dựa trên việc kiểm tra mô hình đã được nghiên cứu có liên quan tới logic thời gian. Kỹ thuật này lần nữa được dựa vào mối quan hệ gần gũi giữa các mô hình logic thời gian và các máy trạng thái giói hạn. Giả sử rănglà đặc tả cho hệ thống nào đó vàlà một chương trình thực hiện. Sau đó, để xác minh xemcó phải là thực hiện đúng đắnhay không, ta lựa chọnrồi từ đó sinh ra một mô hìnhtương ứng với, với ý nghĩa rằngmã hóa tất cả các tính toán có thể của. Để xác định xemhay không, tức là đặc tả công thứclà hợp lệ trong; chương trìnhthỏa mãn đặc tảchỉ trong trường hợp câu trả lời là “yes”. Thuận lợi chính của kiểm tra mô hình qua sự xác minh tiên đề là sự phức tạp: kiểm tra mô hình sử dụng việc phân nhánh thời gian logic thời gian CTL có thể được thực hiện trong thời gian đa thức, ngược lại bài toán chứng minh cho hầu hết các logic hình thức là hoàn toàn thích hợp.
Kiểm tra mô hình các hệ thống BDI
Rao và Georgeff đưa ra một thuật toán cho việc kiểm tra mô hình các hệ thống tác tử. Chính xác hơn họ đưa ramộ thuật toán cho việc lựa chọn một mô hình logic cho ngôn ngữ đặc tả tác tử BDI của họ, một thể thức của ngôn ngữ và việc quyết định thể thức đó có hiệu lực lên mô hình hay không. Kỹ thuật gần như là dựa trên giải thuật kiểm tra mô hình cho các logic hình tức chuẩn. Họ chỉ ra rằng mặc dù kết luận của ba thể thức đặc biêt (beliefs,desires,intentions) vào việc phân nhánh khung thời gian, thuật toán vẫn hoàn toàn hiệu quả khi chạy trong thời gian đa thức. Bởi vậy bước thứ hai của quá trình kiểm tra hai giai đoạn được mô tả ở trên có thể vẫn được thực hiện một cách hiệu quả. Tuy nhiên, cách mà bước đầu tiên thực hiện cho logic BDI là vẫn không rõ ràng. Ở đâu thì mô hình logic mô tả đặc điểm một tác tử thực tế có thể được xuất phát từ một chương trình π bất kỳ, như ở trong một xu hướng chủ đạo của khoa họcmáy tinh? Để thực hiện điều này, ta cần lựa chọn một chương trình được thựch hiện bởi Pascal và từ đó sinh ra các mối quan hệ có thể truy cập belief, desire, intention mà đước sử dụng để đưa ra một ngữ nghĩa cho thành phần BDI của logic. Như ta đã lưu ý ở trên, bởi vì không có một mối quan hệ rõ ràng giữa logic BDI và các mô hình tính toán cụ thể được sử dụng để thực hiện các tác tử, cách mà một mô hình có thể được đề xuất cũng là không rõ ràng.
3.5 Phương pháp luận hướng tác tử
Công nghệ phần mềm hướng tác tử đã trở thành một lĩnh vực nóng hổi của nghiên cứu trong những năm gần đây. Đã rất nhiểu phương pháp luận được đưa ra. Trong phần này chúng ta sẽ xem xét một số phương pháp phân tích thiết kế hướng tác tử, và xem xem chúng thỏa mãn những yêu cầu của phân tích thiết kế hướng tác tử như thế nào.
3.5.1 Phương pháp Prometheus
Pha phân tích của phương pháp Prometheus bao gồm:
Xác định môi trường của hệ thống trong những điều kiện của: nhận thức (nhưng thông tin đi từ môi trường), những hành động (những hành động mà một tác tử dùng để tác động lên môi trường của nó), và dữ liệu bên ngoài.
Xác định những mục đích, những chức năng và kịch bản use-case của hệ thống
Những mục đích xác định những gì mà hệ thống sẽ làm.
Những chức năng tương tự như vai trò trong những phương pháp khác (Gaia). Việc định nghĩa chức năng để hoàn thành những mục đích đã được xác định.
Kịch bản use-case miêu tả hệ thống đang được sử dụng. Bao gồm cả tri thức gì được thừa nhận, những thông điệp nào được gửi đi, và những hành động nào được thực hiện bởi tác tử.
Những chức năng Prometheus được miêu tả dưới đây:
-Tên
-Những miieu tả ngôn ngữ tự nhiên ngắn gọn
-Danh sách những hành động
-Danh sách những tri thức thích hợp
-Dữ liệu được sử dụng.
-Dữ liệu được tạo ra
-Những tương tác với những chức năng khac.
Miêu tả của “những tương tác với những chức năng khác” xác định thông điệp nào mà vai trò gửi và nhận từ những vai trò khác. Điều này ràng buộc cách mà vai trò tương tác với những tác tử khác, và ràng buộc về việc một vai trò tương tác với những vai trò khác. Tuy nhiên, những chức năng của Prometheus lại không xác định chi tiết cách mà những chức năng được hoàn thành như thế nào. Bởi vậy, trong khi pha phân tích của Prometheus bắt đầu xác định cách mà những chức năng liên hệ tới những chức năng khác, thì những chức năng Prometheus lại có xu hướng ít thực hiện được hơn là vai trò trong Gaia. Nó nắm bắt những mục tiêu của hệ thống, tri thức về phạm vi ứng dụng, những yêu cầu trên môi trường, và những yêu cầu trên hệ thống máy tính. Những mô hình được tạo ra miêu tả những yêu cầu của hệ thống và tránh gồm quá nhiều những chi tiết về cách mà hệ thống được thực hiện ra sao.
3.5.2 Phương pháp Tropos
Phương pháp tropos được thiết kế bao gồm tất cả các pha trong phát triển phần mềm. Nó bao gồm những pha cho yêu cầu sớm, yêu cầu muộn, thiết kế kiến trúc, thiết kế chi tiết và thực hiện. Những pha phân tích phần mềm là những pha yêu cầu sớm và yêu cầu muộn. Những khái niệm và ký hiệu tương tự được sử dụng trong cả hai pha. Những khái niệm trong phương pháp.
-Mục đích:Biểu diễn những quan tâm chiến lược của người thực hiện. Tropos miêu tả những mục đích cứng và mềm. Những mục đích cứng miêu tả chức năng mà hệ thống sẽ hoàn thành. Những mục đích mềm miêu tả những yêu cầu phi chức năng như là bảo mật, sự thực hiện và khả năng bảo trì.
-Ràng buộc:Mối quan hệ ràng buộ giữa những người thực hiện miêu tả những trường hợp ở đó một người thực hiện phụ thuộc vào người khác để đạt được một mục đích thực hiện một kế hoạch, hoặc chuyển giao tài nguyên.
-Kế hoạch:Là một cách đặc biệt để đạt được một mục đích.
-Tài nguyên:Những tài nguyên vật lý hay dữ liệu mà một người thực hiện có thể cần hoặc người khác cung cấp.
-Năng lực:Khả năng của một con người thực hiện để định nghĩa, chọn lựa và thực hiện một kế hoạch để hoàn thành mục đích.
-Tri thức:Biểu diễn những tri thức của người thực hiện.
Trong pha yêu cầu sớm, chúng ta mô hình hoá và phân tích những mục đích và những ý định của nhà đầu tư. Thông qua phân tích, phương pháp Tropos xây dựng những mô hình yêu cầu chức năng và phi chức năng. Những mô hình này bao gồm thực hiện, mục đích của chúng, và những ràng buộc của chúng.
3.5.3 Phương pháp Gaia
Gaia mục đích là cho phép một nhà phân tích đi theo một cách hệ thống từ những yêu cầu đến một thiết kế mà đã được mô tả đầy đủ đến mức nó có thể thực hiện được một cách trực tiếp. Ghi nhớ rằng chúng ta xem xét những yêu cầu nắm bắt các pha như thể độc lập với các mô hình được sử dụng cho phân tích và thiết kế. Trong khi áp dụng Gaia, người phân tích đi từ trừu tượng đến dần khai niệm cụ thể. Mỗi bước tiến kế tiếp sẽ đưa ra xu hướng thực hiện lớn hơn, và giảm không gian những hệ thống có thể mà có thể được thực hiện để thoả mãn những yêu cầu ban đầu. Phân tích và thiết kế có thể được xem như là một tiến trình của việc phát triển những mô hình được chi tiết hoá hơn của hệ thống được xây dựng. Những mô hình chính được sử dụng trong phương pháp Gaia được tổng kết lại trong hình 5.3, Gaia đã mượn một số những kỹ thuật và ký hiệu của phân tích và thiết kế hướng đối tượng.
Tuy nhiên, đây không phải là một cố gắng vô ích để áp dụng những phương pháp như vậy cho phát triển hướng tác tử. Hơn nữa nó cung cấp một tập hợp những tác tử riêng biệt của những khái niệm mà thông qua đó một kỹ sư phần mềm có thể hiểu và mô hình lên được một hệ thống phức tạp. Trong trường hợp cụ thể, Gaia khuyến khích những nhà phát triển nghĩ đến việc xây dựng những hệ thống dựa trên tác tử như là một công việc thiết kế tổ chức. Những khái niệm chính của Gaia có thể được chia thành hai loại: trừu tượng và cụ thể; những khái niệm trừu tượng và cụ thể được đúc kết trong bảng 2. Những thực thể trừu tượng được sử dụng trong quá trình phân tích để mô hình hoá hệ thống, nhưng lại không cần thiết phải được sự thực hiện trực tiếp trong hệ thống. Những thực thể cụ thể, ngược lại được sử dụng trong quá trình thiết kế và sẽ có những bản sao trong khi thực thi hệ thống.
Phân tích
Những yêu cầu
Mô hình vai trò
Mô hình tương tác
Mô hình Agent
Mô hình của dịch vụ
Mô hình sự hiểu biết
Thiết kế
Hình 3.3 Mối quan hệ giữa những mô hình Gaia
Những khái niệm trừu tượng
Những khái niệm cụ thể
Vai trò
Quyền
Trách nhiệm
Giao thức
Hoạt động
Những tính chất về dòng đời
Những tính chất về sự an toàn
Các kiểu Agent
Các dịch vụ
Sự hiểu biết
Bảng 3.1 Những khái niệm trừu tượng và cụ thể trong Gaia
Hệ thống
Các vai trò
Các trách nhiệm
Những tính chất về sự an toàn
Các tương tác
Các quyền
Những tính chất về vòng đời
Hình 3.4 Những khái niệm trừu tượng
3.6 Một số ví dụ về ứng dụng công nghệ tác tử
3.6.1 Ví dụ về cách thức di chuyển của robot áp dụng tác tử
Một tác tử Robot có nhiệm vụ hút bụi trong một căn phòng. Tác tử được trang bị một máy hút bụi và một cảm biến cho phép phát hiện tại vị trí robot đang đứng có bụi hay không; máy hút bụi chỉ có khả năng hút bụi tại vị trí hiện thời của robot. Robot có khả năng di chuyển về phía trước và có khả năng quay sang phải(để đơn giản ta không xét khả năng quay trái của tác tử). Bằng cách quay phải, robot có thể thay đổi hướng chính diện của mình bao gồm đông, tây, nam, bắc. Để đơn giản hóa việc định vị, căn phòng hút bụi được chia thành các ô vuông, chuyển động của robot được chia thành từng đơn vị, mỗi đơn vị chuyển động cho cho phép robot di chuyển sang ô bên cạnh, nếu ô đó không phải là tường. Ví dụ này kích thước phòng là 33 ô như hình vẽ. Ta giả thiết vị trí xuất phát là ô(0,0) và hướng về phía bắc.
Như vậy cảm nhận của robot bao gồm: vị trí hiện tại có bụi hay không;hành động của tác tử bao gồm: tiến lên (theo hướng chính diện), quay (phải) và hút (bụi). Nhiệm vụ của robot là di chuyển trong phòng và hút bụi từ những ô có bụi.
Để lưu giữ thông tin môi trường và suy diễn, tác tử duy trì trạng thái bên trong dưới dạng biểu thức logic. Thông tin về môi trường được biểu diễn bởi những vị từ sau:
vị_trí (x,y) robot đang ở ô (x,y)
có_bụi (x,y) tại ô (x,y) có bụi
hướng (d) hướng chính diện của tác tử là d
Hành vi của tác tử được quy định bởi luật suy diễn:
vị_trí (x,y)có_bụi (x,y)thực_hiện (hút) (2.1)
Trong ví dụ đang xét, hành động này có mức ưu tiên cao nhất, tức là khi robot có thể hoặc hút hoặc di chuyển, tác tử phải ưu tiên hút trước và di chuyển sau. Đây là đảm bảo tác tử sẽ hút bụi chứ không di chuyển đơn thuần. Để đơn giản ta quy định sẵn quỹ đạo chuyển động của tác tử là (0,0), (0,1), (0,2), (1,2), (1,1), (1,0), (2,0), (2,1), (2,2). Chuyển động của robot được xác định bởi một số luật đơn giản:
Vị_trí(0,0)^Hướng(bắc)^Có_bụi(0,0)Thực_hiện (tiến_lên) (2.2)
Vị_trí(0,1)^Hướng(bắc)^Có_bụi(0,1)Thực_hiện (tiến_lên) (2.2)
Vị_trí(0,2)^Hướng(bắc)^Có_bụi(0,2)Thực_hiện (quay) (2.4)
Vị_trí(0,2)^Hướng(đông)Thực_hiện (tiến lên) (2.5)
…..
Các luật cho phép tác tử di chuyển tiếp đến ô (2,2) được xây dựn tương tự. Biểu thứcCó_bụi(x,y) được thêm vào các luật trên đảm bảo tác tử chỉ chuyển động khỏi một ô khi chắc chắn ô đó không có bụi, nhờ vậy thao tác hút bụi luôn có mức ưu tiên cao hơn thao tác di chuyển.
0.2
1,2
2.2
0,1
1,1
2,1
0,0
1,0
1,1
Hình 3.5 Tác tử robot hút bụi trong ô 33
Để trạng thái phản ánh đúng thông tin về môi trường, ta cần xác định hàm Cập_nhật. Hàm cập nhật thông tin do cảm biến đưa vào (một trong hai giá trị có_bui hoặc không_bui) để thay đổi giá trị vị từ Có_bụi(x,y). Ngoài ra dựa trên hành động vừa thực hiện, hàm cập nhật thay đổi sự kiện về vị trí và hướng chính diện chứa trong trạng thái tác tử. Hàm cập nhật có thể cho như sau:
Có_bui(x,y) nếu giá trị cảm biến tại (x,y) là có_bụi
Có_bụi(x,y) nếu ngược lại
Kết_quả(Vị_trí(0,0), Thực_hiện(tiến_lên))=Vị_trí(0,0)
Kết_quả(Vị_trí(0,2), Thực_hiện(quay))=Vị_trí(1,2)
……….
Như vậy ta đã hoàn thành mô hình tác tử hút bụi bao gồm tri thức, hàm Cập_nhật và hàm Hành_động để di chuyển robot với yêu cầu của bài tóan.
3.6.2 Ví dụ về đấu thầu sử dụng tác tử
Đấu thầu được sử dụng trong nhiều ứng dụng khác nhau. Một trong những ứng dụng đó là thiết lập mạng cảm biến phân tán. Mạng cảm biến phân tán bao gômg một số nút được bố trí phân tán trong một khu vực rộng với nhiệm vụ theo dõi sự di chuyển của xe cộ trong khu vực đó. Mỗi nút được đặt tại một vị trí cố định và không biết trước vị trí của nút khác. Các nút được chia làm hai loại: loại 1 (kí hiệu S) được trang bị cảm biến âm thanh và có khả năng phát hiện xe trong phạm vi hoạt động của mình; loại thứ 2 kí hiệu P chỉ có khả năng xử lý thông tin. Ngoài ra còn có một nút M có nhiệm vụ tổng hợp kết quả cảm biến và gửi cho người ra quyết định. Tổ chức hệ thống cảm biến phân tán được minh họa như hình ve(). Vòng tròn quanh các nút là phạm vi hoạt động của cảm biến. Đường thẳng chạy ngang qua là quỹ đạo chuyển động của một xe. Do khu vực cần theo dõi rộng hơn phạm vi hoạt động của từng nút, không nút nào có khả năng theo dõi toàn bộ khu vực một cách độc lập. Nếu coi mỗi nút là một tác tử thì đây là một ví dụ hệ đa tác tử trong đó trong từng tác tử không đủ khả năng giải quyết công việc một mình.
Nhiệm vụ của hệ thống là tổng hợp một số lượng lớn dữ liệu cảm biến được, lọc bớt dữ liệu trùng lặp và biến đổi thành dạn thích hợp cho người sử dụng. Dữ liệu và công việc được phân cấp như hình vẽ. Ở mức thấp nhất, dữ liệu có dạng tín hiệu thô. Các tín hiệu liên quan đến nhau tạo thành các nhóm (mức thứ hai từ dưới lên). Tín hiệu ở mức cao hơn tương ứng với xe. Mỗi xe được mô tả bởi một số nhóm tín hiệu liên quan và bao gồm các đặc điểm như: vị trí, tốc độ, hướng chuyển động, loại xe (do động cơ từng loại xe có tần số âm thanh phát ra khác nhau nên việc phân tích tín hiệu âm cho phép xác định âm thanh đó là thuộc loại xe nào). Vị trí xe được xác định bằng cách phân tích tín hiệu thu được từ một số cảm biến lân cận, tốc độ và hướng chuyển động có thể xác đinh bằng cách theo dõi vị trí xe theo thời gian. Sơ đồ khu vực là mức tiếp theo trong phân cấp dữ liệu. Mức này bao gồm thông tin về chuyển động của xe trong một khu vực nhỏ. Thông tin từ tất cả các khu vực nhỏ tọa thành sơ đồ toàn khu vực và được xử lý bở nút M.
Phân cấp công việc được tạo thành từ phân cấp dữ liệu. Tác tử tại nút M quả lý một số nhà thầu khu vực. Mỗi nhà thầu loại này chịu trách nhiệm lập sơ đồ xe trong khu vực của mình. Mỗi nhà thầu khu vực lại quản lý một số nhà thầu tín hiệu và nhà thầu xe. Nhà thầu tín hiệu tổng hợp tín hiệu từ các nút cảm biến và cung cấp cho nhà thầu khu vực trong khi nhà thầu xe chịu trách nhiệm theo dõi và cung cấp thông tin về xe của mình. Mỗi nhà thầu xe, để thực hiện nhiệm vụ của mình, lại quản lý ba nhà thầu làm các công việc phân loại, định vị và theo dõi.
Hoạt động của hệ thống được chia thành hai giai đoạn: khởi tạo và thực hiện. Tác tử M chịu trách nhiệm khởi tạo hệ thống và tổng hợp sơ đồ toàn khu vực. Khởi đầu, M chọn trong số nút P một số nhà thầu khu vực và phân chia khu vực cho các nhà thầu này. Do đặc điểm hệ thống, lúc đầu, M chỉ biết tên các nút P mà không biết vị trí. M gửi thông báo mời thầu cho các nút P. Thông báo chứa yêu cầu về khả năng mới thầu-có vị trí phù hợp-và yêu cầu đối với đề nghị bỏ thầu-ở đây là mô tả khu vực sẽ giám sát. Cần nhắc lại yêu cầu với đề nghị bỏ thầu mô tả thông tin cần có trong đề nghị để tác tử quản lý có thể lựa chọn trong số đề nghị nhận được.
Sau khi nhận được thông báo, tác tử P gửi lại đề nghị bỏ thầu có chứa thông tin về vị trí và khu vực giám sát dự kiến của mình. Trên cơ sở thông tin này, M phân chia khu vực thành khu vực con lựa chọn một số nhà thầu khu vực. Thông báo được gửi cho những nút P thắng thầu.
Sau khi được giao nhiệm vụ, nhà thầu khu vực tổng hợp dữ liệu về xe để hình thành sơ đồ khu vực của mình. Để có được dữ liệu, nhà thầu khu vực cần thu thập từ những nút khác. Do không biết nút nào có khả năng cung cấp các dữ liệu này, nhà thầu khu vực thông báo về nhiệm vụ đế các nút khác. Thông báo bao gồm thông tin về khu vực cần giám sát. Đề nghị bỏ thầu bao gồm vị trí các nút trong khu vực. Các nút thắng thầu trở thành nhà thầu nhóm tín hiệu và nhà thầu xe.
Quá trình chia sẻ công việc được tiếp diễn liên tục cho đến khi tìm được nhà thầu ở mức thấp nhất: mức tín hiệu, định vị, phân loại và theo dõi.
Sử dụng giao thức đấu thầu trong ví dụ trên cho phép chia sẻ công việc một cách mềm dẻo cho các ứng dụng trong đó cấu trúc nhiệm vụ không được biết từ trước và có thể thay đổi trong quá trình hoạt động. Các phần việc còn quá lớn có thể phân rã thành phần việc nhỏ hơn và phân chia tiếp tới những tác tử thích hợp. Mỗi tác tử đều có thể đóng vai trò người giao việc hoặc người thực hiện.
Toàn khu vực
Sơ đồ toàn khu vực
Khu vực
Sơ đồ khu vực
Xe
Xe
Nhóm
Nhóm tín hiệu
Phân loại
Tín hiệu
Tín hiệu
Định vị
(a)
Theo dõi
(b)
Hình 3.6 Phân cấp dữ liệu (a) và phân cấp công việc
3.6.2 Ví dụ về việc lập kế hoạch phân tán của tác tử
Cho hai robot với nhiệm vụ di chuyển giữa hai phòng như trên hình vẽ. Để di chuyển đồ vật, robot phải chuyển động liên tục từ phòng này sang phòng khác. Đường đi ngắn nhất đối với cả hai robot đều đi qua cùng một cửa (cửa trên) do đó có thể xung đột với nhau. Sau khi trao đổi kế hoạch, hai robot phát hiện ra mâu thuẫn này. Robot có thể giải quyết mâu thuẫn ở mức trừu tượng cao bằng cách phân chia cố định cho mỗi robot một không gian riêng (cửa riêng). Cách này dẫn tới việc phân chia không gian như hình vẽ. Mặc dù đơn giản, cách giải quyết như vậy là không hiệu quả do R2 luôn sử dụng đoạn đường dài hơn.
Nếu xem xét chuyển động của mình chi tiết hơn, robot có thể tìm ra giải pháp khác. Giải pháp ở đây là xem xét kết hợp nhu cầu sử dụng không gian với thời gian.R2 có thể đợi cho đến khi R1 sử dụng xong cửa trên trước khi sử dụng cửa này. Ở đây robot có thể thay đổi ở những mức chi tiết khác nhau. Ở mức cao nhất, R2 đợi cho R1 hoàn thành công việc trước khi bắt đầu sử dụng cửa trên. Ở mức trung gian, R2 bắt đầu chuyển động khi R1 rời khỏi cửa. Ở mức chi tiết nhất, R2 có thể chuyển động cùng R1 và chỉ dừng lại ở gần cửa để nhường R1 đi qua trước.
R1
R2
R1
R2
Hình 3.7 Giải pháp mâu thuẫn nhờ phân chia không gian
Kết luận và đánh giá
Qua tìm hiểu đã giúp cho ta thấy được tổng quan về tác tử là gì? Đặc điểm và thành phần của tác tử, sự phối hợp của tác tử trong hệ đa tác tử để xử lý các vấn đề trong thực tế. Tác tử rõ ràng đã giải quyết được những vấn đề phức tạp mà các công nghệ trước chưa giải quyết tốt hay chưa giải quyết được. Tác tử có những ưu điểm vượt trội so với các công nghệ khác đó là tính thông minh, cũng như khả năng tự chủ hành động mà không cần có sự can thiệp trực tiếp của con người, tự động hành động để đạt được mục tiêu mà không cần phải lập trình trước đó- thể hiện khả năng có thể thích nghi với mọi điều kiện môi trường và tác động lại vào môi trường có lợi cho con người.
Dù công nghệ tác tử còn mới mẻ đối với chúng ta nhưng những gì mà công nghệ này mang trong nó sẽ được nghiên cứu nhiều và phát triển trong tương lai. Tác tử đã có những ứng dụng để giải quyết các bái toán trong thương mại điện tử, trong quản lý sản xuất,… Trong thời đại công nghệ thông tin thì những ứng dụng của tác tư trong xã hội là rất cần thiết để giảm sức lao động của con người đồng thời nâng cao được hiệu quả lao động. Từ những lý do trên có thể đánh giá công nghệ tác tử là công nghệ hữu ích và là giải pháp để giải quyết nhiều vấn đề trong xã hội và triển vọng của công nghệ này là rất sáng sủa.
Tài Liệu Tham Khảo
-Tác tử-Công nghệ phần mềm hướng tác tử
của Lê Tấn Hùng, Từ Minh Phương, Huỳnh Quyết Thắng
-Công nghệ Agent trong quản lý mạng internet
của Biện Văn Quang (quantrimang.com)
www.bcs.Org
www. W3.org
www.dse.su.se
Các file đính kèm theo tài liệu này:
- DA6.docx