1 / 67

A Knowledge Level Software Engineering Methodology for Agent Oriented Programming

A Knowledge Level Software Engineering Methodology for Agent Oriented Programming. The Tropos framework. Fausto Giunchiglia Dept. of Information and Communication Technology University of Trento SRA Division - ITC-irst Trento fausto@itc.it - http://sra.itc .it. Outline. Key ideas

astin
Download Presentation

A Knowledge Level Software Engineering Methodology for Agent Oriented Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Knowledge Level Software Engineering Methodology for Agent Oriented Programming The Tropos framework Fausto Giunchiglia Dept. of Information and Communication TechnologyUniversity of Trento SRA Division - ITC-irstTrento fausto@itc.it - http://sra.itc.it

  2. Outline • Key ideas • Modeling language • case study • metamodel • Transformational approach • case study revisited • tranformational operators • composition of transformations: intuition • Conclusion • Future work • Related work

  3. Key ideas

  4. Key ideas The Tropos framework is a novel approach in Agent Oriented Software Engineering, resting on the following 3 key ideas: • the Tropos approach framework spans the overall software development process, from early requirements down to implementation • we use the notion of agent and all the related mentalistic notions in all phases of software development • we adopt a transformational approach, i.e., we perform refinement steps, inside one phase or between phases, using a set of transformation operators

  5. Key ideas (1.1) The 5 phases of the Tropos framework: • Early requirements • Late requirements • Architectural design • Detailed design • Implementation

  6. Key ideas (1.2) • we adopt a requirements­driven software development approach, exploiting goal analysis and actor dependencies analysis techniques (i* by E. Yu, NFR by Chung et al., Kaos by Dardenne et al.) Model the what, how and the why • the conceptual notions thus introduced are used along the whole development process

  7. Key ideas (1.3) Filling the gap Agent-oriented programming i * Early requirements Late requirements Detailed design Architectural design Implementation

  8. Key ideas (2) • The notion of agent and goal is used along all the phases, therefore the key elements and dependencies describing the organizational setting can be used to justify and motivate each design and implementation choice. • Each artifact (including code) can be retraced back to the analysis performed during requirement phases. • There is a direct and natural correspondence between requirement analysis (social actors) and implemented code (software agents). System behaviour is easier to understand, explain, motivate.

  9. Key ideas (3.1) We adopt a transformational approach: (for early and late requirements, and partially for the architectural design) • start with a limited list of Tropos conceptual elements (actors, goals, softgoals,...) • iteratively and incrementally: • add details • revise dependency relationships Each step corresponds to the introduction/deletion of relationships/elements in the model.

  10. Key ideas (3.2) Advantages of the (transformational) approach : • provides systematic description of the process • allows for processanalysis • provides guidelines to the engineer • provides a sound basis for describing and evaluating requirement acquisition and design strategies

  11. Modeling language

  12. Modeling languagecase study

  13. The eCulture system case study • a web-based broker of cultural information and services for the province of Trentino • usable by a variety of users (e.g.Trentinos, tourists, scholars and students).

  14. The eCulture system case studyFollowing the 5 phases of the Tropos framework down to the implementation • Early requirements • Late requirements • Architectural design • Detailed design • Implementation Tropos social actors Agents

  15. Early requirementsMain activities • We analyze the environment (i.e. existing organizational setting)and model it in terms of relevant actors and their respective dependencies

  16. Early requirementsThe stakeholders of the eCulture domain Citizen Museum PAT Visitor

  17. Early requirementsThe stakeholders of the eCulture domain Citizen get cultural information Museum PAT increase internet use Visitor enjoy visit

  18. Early requirementsThe stakeholders of the eCulture domain Citizen taxes well spent get cultural information Museum PAT increase internet use Visitor enjoy visit

  19. Early requirementsThe stakeholders of the eCulture domain

  20. Early requirementsGoal-decomposition andMeans-ends analysis for PAT

  21. Late requirementsMain activities • We introduce the system actor and analize its dependencies with actors in its environment identifying system’s functional and non-functional requirements

  22. Late requirementsRationale diagram for eCulture System

  23. get cultural information get cultural information eCulture System eCulture sys.available eCulture sys.available Revision of dependencies Early Requirements revised Citizen PAT

  24. Late requirementsdependencies with environmental actors

  25. Architectural designMain activities • 3 steps: • decomposing and refining the system actor diagram • … at three different levels of abstraction • identifying capabilities • from actors to agents

  26. Architectural design: step 1 • a:inclusion of new actors due to delegation of subgoals upon goal analysis of system's goals • a:inclusion of new actors due to delegation of subgoals upon goal analysis of system's goals • b:inclusion of new actors according to the choice of a specific architectural style (design patterns) • c:inclusion of new actors contributing positively to the fulfillment of someNon Functional Requirements

  27. Architectural design(step 1)taking into account functional requirements : eCulture System decomposition into sub-actors

  28. Architectural design: step 1 • a:inclusion of new actors due to delegation of subgoals upon goal analysis of system's goals • b:inclusion of new actors according to the choice of a specific architectural style (design patterns) • c:inclusion of new actors contributing positively to the fulfillment of someNon Functional Requirements

  29. Architectural design(step 1)extending actor diagram taking into account architectural styles - the Info Broker

  30. Architectural designStep 2 • identifying actor capabilities from the analysis of dependencies in the actor diagram • …an intuitive idea of this process

  31. Architectural design(step 2)Actor capabilities

  32. Architectural design(step 2)Actor capabilities

  33. Architectural design(step 2)Actor capabilities

  34. Architectural designStep 3 from actors to agents ….

  35. Architectural design(step 3)from actors to agents

  36. Architectural design(step 3)from actors to agents

  37. Detailed designMain activities Specification of the agents’micro level taking into account the implementation platform. Objective: to perform a design that will map directly to the code. We consider a BDI multiagent platform, so …

  38. Detailed designBDI platform case • We model: • capabilities • capability diagrams (currently AUML activity diagrams)

  39. Detailed designCapability diagram

  40. Detailed designBDI platform case • We model: • capabilities • capability diagrams (currently AUML activity diagrams) • plans • plan diagrams (currently AUML activity diagrams

  41. Detailed designPlan diagram - plan evaluate query

  42. Detailed designBDI platform case • We model: • capabilities • capability diagrams (currently AUML activity diagrams) • plans • plan diagrams (currently AUML activity diagrams • agents interaction • agent interactions diagrams (currently AUML sequence diagrams

  43. Detailed designAgent interaction diagram

  44. Implementation Main activities … follow step by step the detailed design specification … In JACK (BDI multiagent platform)agents are autonomous softwarecomponents that have explicit goals (desires) to achieve or events to handle, beliefs and capabilities. They are programmed with a set of plans that make them capable of achieving goals.

  45. ImplementationJack Intelligent system, AOS

  46. Modeling languagemetamodel

  47. Metamodel A detailed definition is available for the early and late requiremet models. Tropos conceptual entities (actors, goals, softgoals, …) of a tropos model are seen as instances of classes in a metamodel described by UML class diagrams.

  48. Metamodelactors, goals, softgoals, … Actor: the actor is the central primitive notion in Tropos. It corresponds both to human stakeholders (single persons and organizations) and artificial agents (software and hardware systems and components). Goal: actors may depends each other in order to attain some goal. The depending actor is called depender, and the actor that is depended upon is called dependee. The object of the dependency is called dependum. …

  49. MetametamodelEntity

  50. Metametamodel N-ary Relatioship

More Related