Bài giảng Tác tử - Công nghệ phần mềm dựa tác tử: Hệ dựa tác tử và mở rộng AUML

Phát triển hệ thống phần mềm<br /> <br /> Lesion 10 Agent Based and A-UML<br /> Hệ dựa tác tử và mở rộng AUML<br /> <br /> Độ phức tạp<br /> Có một số lượng lớn các thành<br /> phần với nhiều tương tác<br /> Có nhiều mô hình được đưa ra<br /> để làm cho việc phát triển phần<br /> mềm dễ dàng hơn<br /> OO, Component-ware,……<br /> được phát triển theo chiều tăng<br /> của độ phức tạp của phần<br /> mềm.<br /> <br /> hunglt@it-hut.edu.vn<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> 1<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> Phần mềm hướng agent<br /> <br /> 2<br /> <br /> Hệ thống dựa agent<br /> Hệ đa agent như là một cộng đồng các agent, nơi<br /> mà tương tác qua lại giữa các agent và với môi<br /> trường của chúng đưa tới một hành vi toàn thể hữu<br /> ích.<br /> Một hệ đa agent bao gồm:<br /> Các agent, được xem như các cá thể<br /> Tương tác giữa các agent<br /> Sự phụ thuộc qua lại giữa agent và các quan hệ<br /> cộng đồng, hay là các quan hệ tổ chức<br /> <br /> Sự phát triển các hệ đa agent phức<br /> tạp yêu cầu không chỉ các mô hình<br /> và kĩ thuật<br /> Phương pháp luận mới hỗ trợ cách<br /> tiếp cận được công nghệ hoá phân<br /> tích và thiết kế hệ thống.<br /> Công nghệ phần mềm hướng agent:<br /> phân rã bài toán thành nhiều thành<br /> phần tương tác và tự trị (agents) mà<br /> có các mục tiêu cụ thể để đạt tới<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> Mô hình<br /> – sub-routines;<br /> – procedures & functions;<br /> – abstract data types;<br /> – objects;<br /> to agents.<br /> <br /> 3<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> Phân tích và thiết kế hướng agent<br /> <br /> Thiết kế phần mềm hướng agent<br /> <br /> Phân tích hướng agent bắt đầu từ việc định<br /> nghĩa các yêu cầu và mục đích của hệ<br /> thống.<br /> các mục đích toàn thể của ứng dụng được<br /> phân rã thành những mục tiêu con nhỏ hơn,<br /> cho tới khi có thể quản lí được chúng.<br /> Việc phân tích hướng agent phải nhận ra<br /> trách nhiệm của một agent<br /> <br /> 4<br /> <br /> Mỗi agent trong hệ thống được giao một hoặc một<br /> số nhiệm vụ riêng<br /> agent phải nắm được đầy đủ trách nhiệm đối với<br /> việc hoàn thành nhiệm vụ được giao.<br /> Các nhiệm vụ cộng đồng biểu diễn các chức năng<br /> toàn cục của hệ thống agent.<br /> Thiết kế quan tâm tới sự biểu diễn các mô hình<br /> trừu tượng lấy từ pha phân tích.<br /> Trách nhiệm, nhiệm vụ và giao thức tương tác cần<br /> được ánh xạ lên agent, các tương tác và tổ chức<br /> cấp cao<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> 5<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> 6<br /> <br /> 1<br /> <br /> Gaia - Overview<br /> <br /> Lý thuyết Gaia<br /> <br /> Motivation behind Gaia<br /> <br /> Gaia là một lý thuyết dùng trong phân tích<br /> và thiết kế hướng agent.<br /> Phân tích hướng tới việc phát triển để hiểu<br /> rõ hệ thống và cấu trúc của nó, mà không<br /> tham chiếu tới việc thực hiện chi tiết.<br /> <br /> Tồn tại nhiều phương pháp nhưng không có phương pháp nào<br /> hỗ trợ Agnet. Cụ thể trong tương tác và tổ chức<br /> <br /> Mô hình Gaia Supports Hỗ trợ phân tích thiết kế mức<br /> vi mô Micro-level<br /> Agent Structure<br /> <br /> Hỗ trợ phân tích thiết kế mức cao vĩ mô Macro-level<br /> Agent Society and Organizational Structure<br /> <br /> Inter-agent relationships and agent abilities<br /> Static at runtime<br /> ⇒<br /> <br /> 7<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> Find Roles in the system<br /> •<br /> <br /> Xác định các vai trò trong hệ thống và định nghĩa một dãy<br /> các vai trò chính bằng ngôn ngữ miêu tả phi hình thức.<br /> Với mỗi vai trò xác định các giao thức liên kết.<br /> Xem xét lại các mô hình.<br /> <br /> Similar to finding (natural) objects and classes in<br /> OOA<br /> <br /> Model interactions between roles<br /> <br /> 2.<br /> •<br /> <br /> Responsibilities<br /> •<br /> •<br /> <br /> •<br /> •<br /> •<br /> <br /> •<br /> <br /> Liveness Properties – what good the agent does for the<br /> system<br /> Safety Properties – ”safety-net” for the system<br /> <br /> Permissions – what the role is allowed to do<br /> Activities – the roles own tasks (doesn’t require<br /> interaction)<br /> Protocols – particular patterns of interaction (e.g.<br /> (c) SE/FIT/HUT 2005<br /> Auction)<br /> <br /> •<br /> <br /> Đầu ra của pha phân tích là mô hình hoàn thiện<br /> của các vai trò – mô tả về trách nhiệm, quyền hạn,<br /> các giao thức tương tác, hoạt động và mô hình<br /> tương tác<br /> mỗi giao thức được mô tả về sự chuyển đổi dữ liệu<br /> và các thành phần có liên quan.<br /> <br /> 9<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> 10<br /> <br /> Pha thiết kế<br /> <br /> Gaia Design Process<br /> Ánh xạ vai trò vào các loại Agent và tạo ra các<br /> thực thể<br /> Similar to define classes in OOD<br /> Similar to instantiate (right number of) objects in<br /> OOD<br /> <br /> Định nghĩa mô hình dịch vụ<br /> How to fulfill a role in one or several agents<br /> <br /> Tạo mô hình sơ bộ<br /> Representation of communication between agents<br /> (c) SE/FIT/HUT 2005<br /> <br /> 8<br /> <br /> Pha phân tích<br /> <br /> Gaia Analysis Process<br /> 1.<br /> <br /> Most useful in closed systems<br /> <br /> 11<br /> <br /> Pha thiết kế tập trung vào việc định nghĩa hệ thống agent để nó<br /> có thể hoạt động.<br /> Các giai đoạn:<br /> Xác định mô hình agent, kết hợp vai trò vào các loại agent. =><br /> xây dựng hệ thống phân cấp các loại agent và ước lượng số<br /> lượng các instance được yêu cầu đối với mỗi lớp.<br /> Xác định các dịch vụ mà agent phải cung cấp để hoàn thành<br /> các nhiệm vụ mà chúng được giao bằng cách phân tích các<br /> nhiệm vụ và hoạt động. Đó là các giao thức được định nghĩa<br /> cho mỗi vai trò.<br /> Phát triển các mô hình thích hợp để xác định các khả năng<br /> thiếu sót trong thiết kế.<br /> • Đầu ra của pha thiết kế là kiến trúc thực tế của hệ thống agent.<br /> •<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> 12<br /> <br /> 2<br /> <br /> Các khái niệm cơ bản của lý thuyết<br /> GAIA<br /> <br /> Giới hạn của GAIA<br /> Không có các hệ thống mở: Gaia yêu cầu phải<br /> <br /> biết các agent trong hệ thống, cũng như các giao thức<br /> tương tác giữa chúng<br /> <br /> Không có các agent tư lợi: Gaia không giải quyết<br /> rõ ràng các trường hợp trong đó bản chất của các tương<br /> tác là không hợp tác<br /> <br /> Không có các luật cộng tác: Do thiếu sự trừu<br /> tượng hoá các nhiệm vụ chung nên Gaia không mô hình<br /> hoá rõ ràng các luật cộng tác và kết quả là gây thiếu sót<br /> hoặc bỏ qua hoàn toàn chúng trong các định nghĩa về agent<br /> (c) SE/FIT/HUT 2005<br /> <br /> 13<br /> <br /> Mô hình cộng tác<br /> <br /> Coordinables: các thực thể mà tương tác qua lại của chúng được thực hiện<br /> theo mô hình. VD: các agent trong hệ thống đa agent<br /> Coordination media: sự trừu tượng hoá khả năng tương tác của agent và là<br /> hạt nhân xung quanh các thành phần được tổ chức. VD như cờ hiệu, các điều<br /> khiển, kênh và các phương tiện phức tạp khác …<br /> Coordination laws:định nghĩa các behaviour của Coordination media để đáp<br /> ứng các sự kiện tương tác.<br /> <br /> 15<br /> <br /> Bằng cách làm trung gian cho tất cả tương tác của<br /> các agent, phương tiện cộng tác về bản chất có thể<br /> kiểm soát và ảnh hưởng tới tất cả các tương tác.<br /> Phương tiện cộng tác có thể ép buộc behaviour của<br /> các agent tuân theo các tương tác của chúng bằng<br /> cách:<br /> Ngăn cản việc truy nhập của các agent tới phương tiện cộng<br /> tác.<br /> Sửa đổi ngữ nghĩa của các tương tác của agent<br /> (c) SE/FIT/HUT 2005<br /> <br /> 14<br /> <br /> Mô hình cộng tác<br /> <br /> Mô hình cộng tác giải quyết các vấn đề về tạo/huỷ, truyền thông,<br /> phân tán, di động trong không gian cũng như đồng bộ theo thời<br /> gian của một tập các thực thể, các quá trình, các đối tượng hoặc các<br /> agent.<br /> Mô hình cộng tác có thể bao gồm 3 thành phần sau:<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> 17<br /> <br /> chia thành 2 lớp data-driven và control-driven:<br /> Trong mô hình cộng tác control-driven, các agent có khả năng cộng tác tương tác với<br /> các agent khác và với thế giới bên ngoài thông qua cổng vào/ra được định nghĩa từ<br /> trước<br /> Trong mô hình data-driven, các agent có khả năng cộng tác tương tác với thế giới bên<br /> ngoài bằng cách chuyển đổi cấu trúc dữ liệu thông qua phương tiện cộng tác.<br /> <br /> Khi mô hình cộng tác được sử dụng, thì phương tiện cộng tác sẽ<br /> làm trung gian cho tất cả các tương tác của các agent và ảnh<br /> hưởng đến kết quả của các sự kiện tương tác theo các quy tắc<br /> cộng tác của chúng.<br /> 2 agent có thể tương tác với nhau thậm chí chúng không biết gì<br /> về nhau, phương tiện cộng tác hầu như chỉ quan tâm đến việc kết<br /> nối giữa các agent bằng cách gửi thông điệp.<br /> (c) SE/FIT/HUT 2005<br /> <br /> 16<br /> <br /> Việc chấp nhận mô hình cộng tác dẫn tới quan niệm<br /> hệ thống đa agent như một cộng đồng, trong đó các<br /> nhiệm vụ riêng lẻ của các agent phải được mô hình<br /> hoá một cách riêng biệt với các nhiệm vụ của cộng<br /> đồng.<br /> Hệ thống đa agent nên được xây dựng dựa trên một<br /> hạ tầng truyền thông phổ biến, hoạt động thực tế của<br /> hệ thống nên bao gồm hoạt động của cơ sở hạ tầng<br /> cần thiết làm cho tất cả các tương tác đều tuân theo<br /> behaviour của phương tiện cộng tác.<br /> (c) SE/FIT/HUT 2005<br /> <br /> 18<br /> <br /> 3<br /> <br /> Multiagent Systems Engineering<br /> Methodology (MaSE)<br /> <br /> Mô hình cộng tác<br /> <br /> Motivation behind MaSE<br /> Lack of proven methodologies for agent-systems<br /> Lack of industrial-strength software tools<br /> <br /> Similar to Gaia with respect to<br /> Generality<br /> Application Domain (closed systems)<br /> <br /> MaSE’s differences from Gaia<br /> Supports automatic code creation<br /> <br /> Scott DeLoach<br /> (c) SE/FIT/HUT 2005<br /> <br /> 19<br /> <br /> The MaSE Process – I<br /> <br /> •<br /> <br /> Creating Agent Classes<br /> <br /> 4.<br /> <br /> initial system specification ⇒ struct. hierarchy of goals<br /> i.e. similar to requirement specification<br /> <br /> •<br /> <br /> •<br /> •<br /> <br /> Applying Use Cases (i.e. UML)<br /> <br /> 2.<br /> •<br /> •<br /> <br /> •<br /> <br /> •<br /> <br /> Creates roles corresponding to the goals (or a set of goals)<br /> Creates tasks – how to solve goals related to the role<br /> <br /> •<br /> •<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> •<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> 22<br /> <br /> Design Patterns<br /> <br /> System Design<br /> •<br /> <br /> Internal functionalities of classes created<br /> Based on either BDI, reactive, planning, knowledge-based and<br /> user-defined architecture.<br /> <br /> 21<br /> <br /> The MaSE Process – III<br /> 7.<br /> <br /> Defines coordination protocols for interaction with state<br /> diagrams<br /> <br /> Assembling Agent Classes<br /> <br /> 6.<br /> <br /> Refining Roles<br /> <br /> 3.<br /> <br /> Maps roles to agent classes in an agent class diagram<br /> Resemble object class diagrams, but semantics is high-level<br /> conversation versus inheritance (and encapsulation)<br /> <br /> Constructing Conversations<br /> <br /> 5.<br /> <br /> Use cases and sequence diagrams based on spec.<br /> Use cases – represent logical interaction path<br /> Sequence diagrams – number of messages needed<br /> <br /> •<br /> <br /> 20<br /> <br /> The MaSE Process – II<br /> <br /> Capturing Goals<br /> <br /> 1.<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> •<br /> <br /> ”a pattern embodies a complete idea within a<br /> program, and thus it can sometimes appear at the<br /> analysis phase or high-level design phase” Bruce<br /> Eckel, ”Thinking in Patterns with Java”<br /> <br /> •<br /> <br /> Types of patterns<br /> <br /> Create instances of the agent classes presented in a<br /> deployment diagram<br /> <br /> Future vision of MaSE<br /> Support automatic code generation based on deployment<br /> diagram<br /> <br /> Creational<br /> •<br /> <br /> How an object can be created (e.g. Factory, Prototype)<br /> <br /> Structural<br /> •<br /> <br /> Design to satisfy project constraints (e.g. Iterator)<br /> <br /> Behavioral<br /> •<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> 23<br /> <br /> Objects handling particular types of actions (e.g. Interpreter)<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> 24<br /> <br /> 4<br /> <br /> Design Patterns for Agents<br /> <br /> Design Patterns for Mobile Agents<br /> <br /> 7-layer architecture<br /> 1.<br /> 2.<br /> 3.<br /> 4.<br /> 5.<br /> 6.<br /> 7.<br /> <br /> Classification scheme – 3 classes<br /> <br /> Mobility – mobile agents<br /> Translation – communication/language<br /> Collaboration – multi-agent issues<br /> Actions – what agents should do<br /> Reasoning – ”intelligence”<br /> Beliefs – what the agent beliefs<br /> Sensory – stimulus/response<br /> Elisabeth A. Kendall<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> 1.<br /> <br /> 2.<br /> <br /> 25<br /> <br /> 26<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> Formal Methodologies in AOSE<br /> Concurrent MetateM<br /> Temporal logic-based programming language for agents<br /> Summary: future can found (calculated) based on the present<br /> and past state.<br /> <br /> Specification of a system<br /> I.e. Requirement specification<br /> <br /> Directly (automatically) programming a system<br /> <br /> Formal Verification<br /> <br /> I.e. Automatic code generation<br /> <br /> Axiomatic approach – Deductive Verification<br /> <br /> Verification of a system<br /> •<br /> <br /> Interaction class<br /> Danny B. Lange<br /> <br /> A formal methodology is usually logic-based<br /> It can be used for<br /> <br /> •<br /> <br /> Task class<br /> <br /> 3.<br /> <br /> Formal Methodologies in Software<br /> Engineering<br /> <br /> •<br /> <br /> Travelling class<br /> <br /> •<br /> <br /> Prove that a system is/behaves correct (according to its<br /> specifications)<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> Prove using logical deduction that an agent system is correct<br /> (powerful but can have exponential runtime)<br /> <br /> Semantic approach - Model Checking<br /> •<br /> <br /> 27<br /> <br /> Reverse engineer program to create a logic model, then check if the<br /> (formal) specification is valid in this model<br /> <br /> 28<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> Conclusions of Lecture<br /> <br /> AUML<br /> <br /> Agent-Methodologies are close to existing Software<br /> Engineering (e.g. OO) methodologies<br /> Main difference is focus on interaction and behavior<br /> There is currently a lack of (industrial-strength)<br /> methodologies (e.g. UML) and software tools supporting<br /> agents.<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> 29<br /> <br /> (c) SE/FIT/HUT 2005<br /> <br /> 30<br /> <br /> 5<br /> <br />