The INGENIAS Methodology and Tools

Transcription

1 236 Pavón, Gómez-Sanz & Fuentes Chapter IX The INGENIAS Methodology and Tools Juan Pavón Universidad Complutense de Madrid, Spain Jorge J. Gómez-Sanz Universidad Complutense de Madrid, Spain Rubén Fuentes Universidad Complutense de Madrid, Spain Abstract INGENIAS provides a notation for modeling multi-agent systems (MAS) and a well-defined collection of activities to guide the development process of an MAS in the tasks of analysis, design, verification, and code generation, supported by an integrated set of tools the INGENIAS Development Kit (IDK). These tools, as well as the INGENIAS notation, are based on five meta-models that define the different views and concepts from which a multi-agent system can be described. Using meta-models has the advantage of flexibility for evolving the methodology and adopting changes to the notation. In fact, one of the purposes in the conception of this methodology is to integrate progressive advances in agent technology, towards a standard for agent-based systems modeling that could facilitate the adoption of the agent approach by the software industry. The chapter presents a summary of the INGENIAS notation, development process, and support tools. The use of INGENIAS is demonstrated in an e-business case study. This case study includes concerns about the development process, modeling with agent concepts, and implementation with automated code generation facilities.

2 The MESSAGE Methodology for Agent-Oriented Analysis and Design 235 Wooldridge, M., Jennings, N. R., & Kinny, D. (2000). The Gaia methodology for agent-oriented analysis and design. Journal of Autonomous Agents and Multi-Agent Systems, 3(3), Zambonelli, F., Jennings, N. R., & Wooldridge, M. (2001). Organisational abstractions for the analysis and design of multi-agent systems. In Proceedings of the Agent-Oriented Software Engineering, LNCS, Vol (pp ). Berlin: Springer-Verlag. Endnote 1 Ed. This is a known weakness of UML. See, for example, Barbier, Henderson-Sellers, Le Parc-Lacayrelle, and Bruel (2003) and Cook (2005).

3 The INGENIAS Methodology and Tools ). The difference with this proposal compared to existing ones is how these viewpoints are defined and built, and how they are integrated into the MAS development process. INGENIAS viewpoints can be complemented with extensions of known notations, such as UML use case diagrams or UML collaboration diagrams. The extension consists of introducing new non-uml elements and associating them with UML entities. In the case study, readers can find use case diagrams used to depict roles (Figure 12), while interaction entities (Figure 18) appear linked to use cases. Viewpoint Definition Each viewpoint is described using a meta-modeling language, in our case GOPRR (Lyytinen & Rossi, 1996). GOPRR stands for Graph, Object, Property, Role, and Relationship, which are the primitives for describing the meta-models. We could have used MOF (OMG, 2000), but it turned out to be too complex for our needs. With this meta-modeling language, we specify how to generate a particular view of the system. The result of applying a meta-modeling language is a meta-model. Meta-models are also instantiated to form the concrete problem-domain views (readers can check OMG [2000] to have a more accurate perspective on what is meta-modeling). In INGENIAS, for each generic entity in the meta-model (e.g., meta-classes), the engineer looks for specific types of entities (e.g., classes) in the current problem domain that share the features specified in the meta-model (relationships with other entities and related attributes). The final result is a view of the system under development that is compliant with the meta-model. This section presents a simplified version of these meta-models by showing the entities with their graphical representation and their relationships informally, in order to make figures easier to understand. Readers interested in the meta-model specification can download it from the INGENIAS site at The meta-models that we defined are the result of experience gained in several projects, each one validated with the development of an agent-based application: MESSAGE (Caire et al., 2001) defined the general framework for MAS specification and the initial identification of five viewpoints; Communications Management Process Integration Using Software Agents (Gomez-Sanz, Garijo, & Pavón, 2000) tested the application of BDI architecture for agent behaviour; and Personalized Services for Integrated Internet Information (Gómez-Sanz, Pavón, & Díaz-Carrasco, 2003) made insights in the organization and scalability issues of MAS. Also, we have extensively used the viewpoints specification to build tools that support the development activities more

4 The INGENIAS Methodology and Tools 237 Introduction As can be seen in this book, there are several methodologies proposed to support a systematic way of developing an MAS. Each one of them starts by assuming its own model of agents and proposing a convenient method of realizing the MAS. This diversity, in principle, benefits agent research by providing different points of view and, therefore, promoting experimentation with agent concepts. On the other hand, this diversity may be a constraint to facilitate the adoption of agent technology by the software industry and to integrate advances in the field. New methodologies try to deal with this multiplicity of solutions by metamodeling techniques applied to the development process and to the specification method. The goal is to finish with a set of agreed-upon concepts and MASbuilding methods as a common framework to focus agent research. However, achieving this goal will take time and experimentation. Therefore, today, we are working with notations in contact evolution, support tools to cope with these changes, and development methods that have to be applied and verified in a short time. INGENIAS assumes the need of evolving in order to adopt or change concepts as agent technology progresses and to incorporate this ongoing research into a stable body of knowledge. This approach is based on: Open source CASE tools. These tools are available freely to the community, so that the development method can be validated and replicated, which is the nature of software engineering. A notation that can be extended and refined. Meta-modeling primitives allow us to generalize or specialize concepts, aggregate new ones, or refine existing ones. There has been a significant effort to integrate results of agent research into a coherent recipe of how to define an MAS. Consequently, this is not just a personal view of MAS-building but an integrative approach. There is a detailed and experimented development process. A development process is usually misunderstood in this area as a guideline. In INGENIAS, a developer will find concrete activities to be executed, an account of the results to be obtained, support tools to produce these results, and a lifecycle to organize all of them. Implementation concerns. The methodology dedicates an important effort to consider how to translate specifications into code automatically. INGENIAS proposes to include the development of a customized code generation procedure as one of the development tasks.

5 238 Pavón, Gómez-Sanz & Fuentes The presentation of INGENIAS here follows the basic structure of other chapters in this book. We first present the principles of the methodology, with focus on the INGENIAS constructs for modeling an MAS. There is also a brief description of the INGENIAS Development Kit (IDK) tools. The third section illustrates the use of INGENIAS in terms of a software process that follows the Unified Software Development Process model (Jacobson, Booch, & Rumbaugh, 1999) for the development of a case study of a bookshop expanding its business to the Web. Finally, we evaluate the methodology, taking into account our experience in the development of different MAS applications. The Methodology This part explains how to generate a specification of the MAS and its implementation. We built the specification of the MAS considering several viewpoints. The concepts for describing each viewpoint are detailed in the next section. Reading that section is important because it clarifies the graphical notation that will be used throughout the case study. The instantiation of these viewpoints with concrete problem entities is addressed with a development process, which is explained in the section on the INGENIAS process. Implementation of the resulting specification is detailed in the same section and demonstrated later on in the case study. Modeling MAS with INGENIAS The object-oriented software developer has to deal with classes, interfaces, objects, inheritance, and the like; the agent-oriented software developer can use those concepts and others such as agent, organization, goal, task, mental state, resource, and so forth. In INGENIAS, we want to promote the use of these concepts from analysis to implementation. So as to manage the complexity of the MAS specification, we propose organizing these concepts in five viewpoints: organization, agent, goals/tasks, interactions, and environment. These viewpoints basically correspond to those already defined in MESSAGE concepts and views, as our previous work was in that project. In INGENIAS, we have refined MESSAGE concepts and views, established relationships among them, and identified activities in the development process to generate MAS specifications. The use of views to specify a system has been used also in the works of Vowel engineering (Demazeau, 2001), MAS-CommonKADS (Iglesias, Mercedes Garijo, Gonzalez, & Velasco, 1998), and Gaia (Wooldridge, Jennings, & Kinny,

6 240 Pavón, Gómez-Sanz & Fuentes specifically, graphical model editors, documentation generation, and code generation for different target platforms and validation tools. Organization Viewpoint The organization describes the framework where agents, resources, tasks, and goals coexist. It is defined by its structure, functionality, and social relationships. From a structural viewpoint, the organization is a set of entities with relationships of aggregation and inheritance. The organization structure defines a decomposition of the MAS in groups and workflows (see Figure 1). Groups may contain agents, roles, resources, or applications. Groups are useful when the number of elements in an MAS increases. Assignment of such elements to a group obeys some organizational purpose, because the grouping facilitates the definition of workflows or because its members have some common characteristics. The functionality of the organization is defined by its purpose and tasks. An organization has one or more goals and depends upon its agents to perform the necessary tasks to achieve them. How these tasks are related and who is responsible of their execution are defined in workflows. Figure 1. Elements of the organization viewpoint (Structural description of a MAS organization) Goal pursues Organization decomposes Group workflow Agent plays Role Application Resource decomposes

7 The INGENIAS Methodology and Tools 241 Figure 2. Elements of the organization viewpoint (Workflow definition) workflow task connect responsible uses task Consumes/produces Agent Application Role Resource Interaction Workflows define associations among tasks and general information about their execution (Figure 2). For instance, for each task, a workflow defines its results, the agent or role responsible for its execution, and the resources that are required. This is useful to gain knowledge on the relationships between agents through tasks, and the assignment and availability of resources in an organization. Social relationships can be established at different levels between organizations, groups, agents, or roles. There are service relationships (for instance, client-server relationship), conditional or unconditional subordination, and so on. Social rules state restrictions on the interactions between entities in the organization. Agent Viewpoint An agent here is a program that follows the rationality principle (Newell, 1982) and that processes knowledge. The rationality principle says that an agent will execute those actions that make it achieve its goals. The agent viewpoint (Figure 3) is concerned with the functionality of each agent: purpose (what goals an agent is committed to pursue), responsibilities (what tasks it has to execute), and capabilities (what roles it plays). The behaviour of the agent is defined through three components:

8 242 Pavón, Gómez-Sanz & Fuentes Figure 3. Elements of the agent viewpoint pursues plays Goal Agent Role has responsible Concrete Agent has Mental State M P task Fact Belief Event modifies Mental state: an aggregation of mental entities such as goals, believes, facts, and compromises. Each agent has an initial mental state represented by an association of the agent to a mental state entity. There can be only one such association. To express mental states over the lifetime of an agent, we use another concept, the concrete agent, associated with mental state entities (e.g., Figure 24). Mental state manager: which provides for operations to create, destroy, and modify mental entities. Mental state processor: which determines how the mental state evolves, described in terms of rules, planning, and so forth. The mental state can be seen as all the information that allows the agent to make decisions. This information is managed and processed in order to produce agent decisions and actions made by the mental state manager (M) and processor (P). The mental state processor makes the decision of which task to execute, while the mental state manager provides the operations to create, destroy, and modify the elements of the mental state and their relationships. Tasks/Goals Viewpoint The tasks/goals viewpoint (Figure 4) considers the decomposition of goals and tasks, and describes the consequences of performing a task and why it should be

9 The INGENIAS Methodology and Tools 243 Figure 4. Elements of the tasks/goals viewpoint Preconditions Fact A F Fact B F consumes consumes uses Task produces uses produces Modifies/affects Postconditions Fact C F Application Application <<Environment>> <<Internal>> - method - method Resource goal Interaction Depends/decomposes into performed (i.e., it justifies the execution of tasks as a way to satisfy goals). For each task, it determines what elements are required and what outputs are expected. To identify which goals are influenced by a task execution, there are satisfaction and failure relationships. Finally, the tasks/goals viewpoint explains how a solved goal affects other existing goals by using decomposition and dependency relationships. It is useful to know that in solving a subgoal, a supergoal can be solved too. Diagrams from this view can be used to explain how the mental state processor and manager work. In INGENIAS, how a task affects the mental state of an agent can be represented within a goal/task view. Therefore, a developer can define special tasks expressing what to do when new elements appear in the mental state (tasks defining mental state management functionality) or tasks that produce special entities representing the next task to execute (tasks for mental state processor functionality description). Interaction Viewpoint The interaction viewpoint addresses the exchange of information or requests between agents, or between agents and human users. The definition of an interaction requires the identification of:

10 248 Pavón, Gómez-Sanz & Fuentes any assistance is possible when the size of the development is small. When it is bigger, satisfying dependencies may consume most of the development effort. To alleviate those dependencies, we propose to generate the specification in a stepwise refinement following a conventional software engineering development process. This process has been customized to produce the elements that our MAS specification needs. Initially, INGENIAS considers the Unified Software Development Process (USDP) (Jacobson, Booch, & Rumbaugh, 1999) as its software development process and defines a set of interrelated activities (around one hundred) that can lead the developer to the final MAS specification. These activities are organized in UML activity diagrams showing the dependencies between them. Instead of presenting all of these activities here, this section focuses on the expected results throughout the development. Readers interested in the details can consult the original work in (Gomez-Sanz, 2002), available only in Spanish, or consult the Web site Figure 8 summarizes the results obtained in each phase of the USDP for analysis and design activities, applied to INGENIAS MAS specification. Details about how to apply analysis and design activities will be provided in this section. Throughout the chapter, references to specific parts of the development process will follow the pattern workflow-phase (for instance, design-elaboration). Figure 8. Results of analysis and design phases of the development process PHASES Inception Elaboration Construction WORKFLOWS A N A L Y S I S D E S I G N Generate use cases and identify their actors Sketch a system architecture with an organization model. Generate enviroment models to represent results from requirement gathering stage Generate prototypes perhaps with rapid application development tool such as ZEUS or Agent Tool or code generators from the IDK. Sometimes this prototyping limits to concrete aspects and uses a more conventional technology Refined use cases and interactions associated to them Agent models that detail elements of the system architecture. Workflows and tasks in organization models Models of tasks and goals to highlight control constraints (main goals, goal decomposition) Refinements of environment model to include new environment elements Refinements in workflows Interaction models that show how tasks are executed. Models of tasks and goals that reflect dependencies and needs identified in workflows and how system goals are achieved Agent models to show required mental state patterns Refinements on existing models to cover use cases Generate new models Social relationships that regulate organizational behavior

11 244 Pavón, Gómez-Sanz & Fuentes Actors in the interaction: who plays the role of initiator and who are the collaborators. There should be at least one collaborator and only one initiator. Interaction specification: a specification should detail how the interaction is constructed at runtime. This refers to the protocol followed along the interaction, but it also may include the mental attitudes that agents should observe and actions triggered on delivering or receiving a message. Context of the interaction: the goals the interaction pursued and the mental states its participants go through when the interaction starts, during its execution, and at the end. Goals of the interaction and its participants do not need to be the same, but they should have something in common (e.g., the goals pursued by agents are subgoals of the interaction goal). Commonalities may be represented by means of a goal/task diagram (see Figure 4). Nature of the interaction: the nature of the interaction refers to the attitude of interaction participants: do they negotiate, cooperate, perform distributed planning, and so forth. This nature is detailed in the hierarchy defined by Huhns and Stephens (2000). Knowing the nature in advance may help in locating a proper protocol or in identifying control constraints. Figure 5 shows the elements participating in the interaction viewpoint. For each interaction, there is an associated interaction specification that can be specialized as the developer needs. INGENIAS does not use a single formalism for interaction specification. It admits different notations for specifying interactions, Figure 5. Elements of the interaction viewpoint Goal Pursues Pursues Is detailed with SPECIFICATION Pursues Interaction Intiated by Collaborates in Pursues GRASIA Spec UML Collaboration diagram AUML Protocol diagram Agent Role

12 The INGENIAS Methodology and Tools 245 Figure 6. Elements of a GRASIA interaction specification Task Interaction unit Task Initiates Speech act Colaborates Agent Interaction unit Colaborates Initiates Agent Iterates Interaction unit Role Speech act Role Precedes Interaction unit Interaction unit Interaction unit Precedes Precedes Speech act Speech act such as Agent UML ( protocol diagrams, UML collaboration diagrams, or our own GRASIA diagrams (detailed in Figure 6). Different specifications are linked with the interaction. There are some aspects of the interaction that are not explained properly by UML or AUML, especially the intentional stance of each agent. For this purpose, we developed our own version of UML collaboration diagrams and named them GRASIA interaction diagrams (see Figure 6). These diagrams explain the interaction in terms of a set of interaction units. An interaction unit may be a message passing action, a shared-space tuple reading or writing, a remote procedure call, or just a reference to another interaction. By making these interaction units explicit, we can detail how they are ordered (a unit precedes another or there is an iteration of several of them, for instance), who starts the communication act (initiates), and who is supposed to attend this message (collaborates). This distinction also allows the discussion of what mental states are required in order to decide to send a message or to accept an incoming one. These mental states can be expressed in many ways, but we tend to use more frequently agent diagrams (Figure 3) to represent one. Figure 6 also denotes that when receiving and/or sending a message, the agent can perform a task.

13 246 Pavón, Gómez-Sanz & Fuentes Environment Viewpoint Finally, the environment viewpoint (Figure 7) defines the entities with which the MAS interacts, which can be: Resources: the elements required by tasks that do not provide a concrete API. Examples of resources are the CPU, File descriptors, or memory. Resources are assigned to agents or groups in the current system. Other agents (from other existing organizations) that satisfy the rationality principle (Newell, 1982). The agents in the MAS interact with these agents to satisfy system goals. Applications: normally, they offer some (local or remote) API. Their main use is to express the perception and action of the agents; applications produce events that can be observed. Agents define their perception indicating to which events they listen. In addition, agents act on the environment by invoking the methods or procedures that applications define. An application can be labelled as environment (the application wraps an existing software in the target system) or as internal (the application wraps software developed for the current system). Figure 7. Elements of the environment viewpoint Group Is assigned Is assigned Application Application Application <<Environment>> <<Internal>> - method - method Resource Perceives environment through Is assigned Is assigned Role Agent Agent

14 The INGENIAS Methodology and Tools 247 Figure 7 shows that an agent defines its perception through applications. Perception can be conceived as the notification of events occurring in the application or as the polling of the application state through its methods in order to look for concrete changes. More complex systems may need other types of perception, but so far we found that our case studies use only these two. Applications and resources may be handled by groups, roles, or agents. When a resource or an application is assigned to an agent, group, or role, these are responsible by controlling its use and access. In the case of the group, the access is granted for any agent or role belonging to the same group. Externals may require interacting with some group role or agent in other to gain access. Dependencies Among Viewpoints Developers should be aware that there are elements that may appear in different views in a specification. This repetition of entities across different views induces dependencies among views. This feature is a consequence of the definition of system views and may be a source of inconsistency in a specification. For instance, the same task entity can appear in an agent view, a task/goal view, an organization view, and an interaction view. Therefore, to completely define a task, creating different diagrams for different views is required. If the developer fails to create all of these diagrams, the system specification may be incomplete. On the other hand, if the developer creates all required diagrams, and a task is assigned to one role in an organization view and another, different role in an agent view, it could be interpreted that the specification is not consistent. In order to deal with those dependencies, the original work of INGENIAS (Gomez-Sanz, 2002) suggested that some tests to be manually applied for each view. These tests were formulated as rules, showing for each element which other views may be used to complement its definition. These tests were incorporated inside of INGENIAS development process in the form of validation activities and can be consulted at The INGENIAS Process The INGENIAS Process helps developers to produce an MAS specification and its implementation. In a simple development, generating a specification would be a matter of identifying valid domain-problem entities, taking into account the elements that each view needs and that have been described in the previous section. This approach would be limited by the inherent dependencies among different views. Adding a new piece of information would imply creating diagrams for the different views or modifying existing ones. Doing this without

15 The INGENIAS Methodology and Tools 249 Despite having a well-defined collection of products, in a real system, there are a considerable number of diagrams to describe an MAS. Figure 8 serves as a guide to establish what elements to produce first and which later. The products themselves are generated through a set of activities organized into activity diagrams, one for each viewpoint in the analysis and design. These diagrams turned out to be a useful tool to deal with the iterative features of the USDP. At the beginning of an iteration, a developer would start from the initial state of the activity diagram, executing the activities in order, and producing elements until the final state. The level of detail would be indicated by the current stage according to the results referred to in Figure 8. Readers may have noticed that Figure 8 deals mainly with modeling. Implementation in INGENIAS is considered a translation of a specification to operational code, that is, an automated code generation process. This code generation process is not a piece of software that the INGENIAS Development Kit (IDK) includes by default. INGENIAS intends to enable a customizable code generation process (detailed in following sections). Development Process Activities Each viewpoint in INGENIAS is constructed following two sets of activities structured into activity diagrams. One set aims at elaborating the view at the analysis level, whereas the other focuses on the design. In total, a developer has ten activity diagrams that propose around one hundred activities to follow. These activities have been numbered to help developers in applying them. Their enumeration is unique within a viewpoint. This means that there are five activities numbered as activity number 1, one for each viewpoint. In general, identified activities are coarse grained and later exploded into more fine- grained activities. Figure 9 shows those that will lead to an analysis viewpoint of agents. Starting from the initial state, the developer consults the information of each activity to know which elements should be produced and how. For instance, activity 2 aims at identifying the agent functionality according to the tasks it can execute, the roles it plays, and the goals it pursues. At the end of the workflow, the resulting model will have to be validated, since many of the elements of this viewpoint may also appear in other viewpoints as well. So, a goal in this viewpoint may trigger further research with associated tasks in a task/goal viewpoint. Figure 10 shows fine-grained activities for the activity number 2, where the developer has to decide whether discovering tasks or goals first is most useful. If tasks are identified first, then goals could be the states achieved by these tasks and each task would have a single goal associated. Later, there should be

16 252 Pavón, Gómez-Sanz & Fuentes study, and assume that the rest is feasible. Naturally, in a more realistic case, more aspects should be tested and some comparatives should be made in order to make a decision. According to the USDP, this kind of task is needed in the inception stage, which is dedicated to the verification of the feasibility of the development. Implementation Only a few agent-oriented methodologies discuss implementation issues. This is almost limited to those that have tool support (e.g., MaSE [DeLoach, 2001], Zeus [Nwana, Ndumu, Lee, & Collis, 1999], ADELFE [Picard & Gleizes, 2004]). INGENIAS bases its implementation proposal on facilities from the IDK that map specification elements into computational entities. In the agent domain, relevant computational entities could be agent architectures, MAS architectures, or agent platforms. This mapping is performed in the IDK by modules. A module in INGENIAS is responsible for generating code from the specification. This specification can be taken directly from the specification editor (see the support tool section) or from an XML file. A module takes as input a set of templates of code and fills them in with information extracted from an INGENIAS specification. A module, then, is built of: A set of templates. Usually, they are templates of code that are made concrete with data from the specification. These templates are XML documents so they can be applied to different programming languages. The DTD of these documents aims at highlighting the pieces of code that will be replaced with information from the diagrams. Basic tags in the DTD are: repeat, which means that a portion of code has to be duplicated and instantiated with different data, and v, which means that it has to be replaced with a concrete piece of information. A graph traversal algorithm. The MAS specification is viewed as a set of graphs that can be traversed using a customized API. This API considers graphs as containers of entities that are interconnected through n-ary relationships. A data structure to be filled. During graph traversal, the developer has to extract meaningful information from the specification and put it into a special data structure required by the code generation framework. This data structure is based on the DTD that defined the template, so that the replacement is easier to program.

17 The INGENIAS Methodology and Tools 251 Figure 10. Details of the activities involved in determining functionality that will help the agent to achieve its goals 2. Associate tasks or roles to the agent to enable goal achievement 2.a Identify the goals of each agent 2.b Identify main functionality 2.c Associate goals with functionality [NO] [ ] Is there a way of satisfying each goal? [YES] [ ] Analysis and Design During analysis-inception (analysis workflow and inception phase), the focus is on defining an organization model that sketches the structure of the MAS and identifies its main components. This result, equivalent to an initial MAS architecture, is later refined in the analysis-elaboration phase to identify the goals of the organization and relevant tasks with respect to these goals, to be performed by each agent in the organization. Task execution has to be justified in terms of organizational goals or an agent s goals (with task-goal models). This leads to identifying the results needed to consider a goal as being satisfied or not. In the design-elaboration phase, more detail is added by defining workflows between the different agents (with organization models), completing workflow definition with agent interactions (with interaction models), and refining the agent s mental state as a consequence (with agent models). According to the USDP, the goal of the elaboration phase is to generate a stable architecture. This architecture arises from the study, during the elaboration phase, of a subset of initial use cases. Remaining use cases, which are supposed to deal with special situations but do not provide changes in the system architecture, are left to the construction phase. Design-Inception has no activity-based assistance. According to Figure 8, it deals with technology issues related to the feasibility of the development. It is hard to establish what to test or what to prototype. In our experience, it is better to focus on concrete aspects, communications, and user interaction in our case

18 254 Pavón, Gómez-Sanz & Fuentes algorithms that work with meta-models. Finally, analysts generate specifications and use the modules to test their correctness using the prototype as a model. Validation and Verification Currently, INGENIAS supports validation using modules with further work under way on verification and validation using Activity Theory (AT) (Fuentes, Gómez, & Pavón, 2003); only verification is included in the standard IDK distribution. In general, any module can provide verification capabilities if a developer follows the basic instructions for module construction. Modules have to traverse a specification looking for elements indicated in the templates used. If these elements do not appear, or appear differently from the way the template requires, then the module should stop and produce error messages. These error messages should indicate what error triggered it and suggest some solution, such as adding specific information, defining responsibilities for agents, or removing some elements, like duplicated tasks. The experience, when following guidelines for module construction, is that modules support the developer in completing the specification. Validation and Verification results with Activity Theory (AT) (Leontiev, 1978) establish the suitability of social theories to study MASs. AT is a framework for the study of human societies that considers all labor as simultaneously individual and social. The social component includes the actual society in which a subject carries out the activity and also the historical development of those activities. Evolution is the result of changes introduced by organizations in their activities to solve contradictions. A contradiction in AT is a tension between elements in the activity and can be caused by several reasons, such as different objectives, ways of use, or needs. AT helps in requirements elicitation (Fuentes, Gómez-Sanz, & Pavón, 2004) and the analysis of contradictions ( Fuentes, Gómez-Sanz, & Pavón, 2003). In both cases, the idea is to use UML-based representations of AT concepts to represent contradiction patterns and requirements. These techniques are currently being tested within this methodology, incorporating these concepts into the INGENIAS process in future releases. Support Tools The INGENIAS Development Kit (IDK) is a set of tools that supports the development process in INGENIAS. The IDK offers two kind of tools: a visual editor and modules. The visual editor works as a modeling tool (Figure 11) that

19 250 Pavón, Gómez-Sanz & Fuentes Figure 9. Activities to produce an agent viewpoint for analysis 1. Identify agents using the rationality principple principle 3. Identify relevant intelligence or autonomy concerns with respect current problem domain 2. Associate tasks or roles to the agent to enable goal achievement 4. Determine requirements to observe for the mental state manager and mental processor Analysis agent viewpoint complete 8. Check that the model is coherent and perform appropriate modifications if not End discussion about whether resulting goals do influence each other or not. On the other hand, if goals are discovered first, it should be studied how to achieve the state identified by the goal. If the goal is too generic, there could be many candidate tasks or none. In the latter case, a refinement of the generic goal would be needed. In the former case, a task-selection criterion should be described. Achieving a goal may also involve the collaboration of other agents. This would be represented by playing a role involved in an interaction or by executing a task that produces an interaction, for instance. Activity 2.c in Figure 10 tests the appropriateness of identified tasks and goals. In principle, tasks can satisfy goals, make them fail, modify them, create them, or destroy them. In addition, a goal may be indirectly satisfied due to the success of its subgoals. It may be that a new goal is already subsumed by another preexisting one or that the execution of certain tasks already satisfies more than one goal, including the new one. Such situations may lead to the conclusion that the new goal does not improve the design.

20 The INGENIAS Methodology and Tools 253 Module development starts in the design-inception stage with the development of a prototype. It follows an iterative prototype generation process that runs in parallel with the main stream. Using IDK tools, developers grow the initial prototype, incorporating new specification elements at each iteration: 1. Initial prototype. Every iteration starts with a prototype candidate that implements a part of a concrete aspect of the specification. For instance, if the aspect is communication, it can support agents that implement a simple protocol. From here, the prototype solution can be reused to implement all the interactions defined in the specification the same way, but automatically. 2. Integrate with code generation facilities. The prototype is converted into code templates. This way of implementation provides a double feedback: from specification to implementation by providing information to generate the code, and from implementation to specification by providing a computational model that can be used to verify the code. a. Validate the module with the specification. Initial effort is invested in checking that the specification is traversed properly and that the module extracts the information it should. b. Verifying the specification with the module. Once the prototype is integrated with the IDK facilities, it is possible to state whether the specification is correct according to the information that the template needs. It would not be correct if the graph traversal that the module needs cannot be executed due to lack of information in the specification (missing elements or relationships, missing fields in the entities, and the like). It would not be correct either if the graph traversal is successful but the information extracted was not correct (for instance, a number was expected and a string was found). 3. Generate another prototype. When the module is operative, it is applied to the complete specification to produce a new prototype. This prototype is modified again to partially incorporate other aspects. In this case, it would be the execution of tasks on receiving or sending a message. The result would be the initial prototype of the next iteration. As a result, the IDK has influenced our initial version of the INGENIAS development process. It has induced some new roles: module developer, prototype developers, and analysts. Prototype developers produce the initial versions of small parts of the system according to the identified needs. Module developers adapt these prototypes to modules, generating templates and the

21 The INGENIAS Methodology and Tools 255 Figure 11. INGENIAS visual editor supports analysis and design of an MAS. This tool permits packaging diagrams, cut & paste, zoom, automatic layout, editing properties of components, taking snapshots, and navigating through the specification, among others. Also, there are special components that link one diagram to other, and text notes to clarify diagrams. Finally, developers can save or load their projects, which are stored in XML format. supports the notation presented in the second section of this chapter. Modules have been presented already as the core of the code generation facilities. The IDK is associated with the definition of the views, the meta-models, through a XML representation of meta-model concepts, relationships, diagrams, and graphical representation. Therefore, it is easy to make changes in the metamodels without affecting the functionality of the IDK. This feature enables the decoupling between the methodology and these tools, and, at the same time, it facilitates experimentation with agent concepts. The IDK is fully implemented in Java and distributed under GNU General Public License and can be downloaded from It is distributed together with a reference manual that includes detailed information about how to develop a module, how to create and modify diagrams, and a description of the meta-models that implement the tool.

22 256 Pavón, Gómez-Sanz & Fuentes Applying the Development Process As in other methodologies, the first steps have a great importance since they bias the rest of the development. Here, first steps imply deciding what kind of diagrams to be created first and, therefore, which are the first identified concepts. In Figure 8, it is suggested to start with an organization model, a UML use case model, and an environment model. These diagrams were selected because they represent a counterpart in the agent domain to the diagrams needed in the USDP inception phase. However, developers have the freedom to select others, taking into account their backgrounds. Though activities would remain the same, selecting other diagrams determines other different development processes where activities are executed in a different order and whose products follow different abstraction levels. To assist developers in that situation, we include a subsection here. That section indicates briefly what other diagrams should be detailed according to how the process is started. When following the instructions from Figure 8, the process is quite straightforward. Developers should determine the kind of product to generate (i.e., an agent diagram), the phase involved (i.e., inception), and the workflow stage (i.e., analysis). With this information, the developer consults one of the ten activity diagrams and applies the activities in order to obtain the requested result. Sometimes, especially at the beginning of the process, the activity diagram produces too much information. In our experience, the best advice is to use Figure 8 as a guideline and avoid executing those activities that lead to information not needed in the current stage. Therefore, Figure 8 controls the level of abstraction and the activity diagram indicates how to obtain the required information. To give readers a feeling of how the development process works, we have added references to the activities along the experiment. These are explained briefly. Providing full details of all existing activities is not possible here because of space constraints. For more information, readers are invited to visit ingenias.sourceforge.net. Activities are executed within the USDP. The USDP states that it may be necessary to iterate over different phases until the system is finalized. Hence, several analyses may occur along the development. In our methodology, the process ends when there is a functional system that satisfies user requirements. These are identified with use cases at the beginning.

23 The INGENIAS Methodology and Tools 259 Analysis-Inception Stage In this stage, the analyst has to demonstrate the feasibility and convenience of building the system. This implies the definition of key functionality, first. This is achieved by identifying use cases (Figure 12), four in our case. The main functionality deals with how to sell a book to the customer, how to obtain new books from publishers, how to know in advance which books should include a discount, and informing students of the availability of these books. These use cases are associated with role entities by means of participates relationships. We could try to organize these roles with organization diagrams, but these diagrams would show little information at this moment. We preferred to leave this to the end of the section where more entities can be integrated. Nevertheless, three main organizations can be identified: the publisher, the bookshop, and the business school. Next, it should be determined what existing resources and applications should be reused by the new system. We obtain this information by elaborating on the environment diagrams (Figure 13) that describe the existing system, according Figure 12. Initial set of use cases and participating roles

24 260 Pavón, Gómez-Sanz & Fuentes Figure 13. Initial elements identified in the environment of the MAS (To check notation, see Figure 7) to the activities defined in Figure 14. In the same diagrams, the identified applications will determine the perception of the agent. To better understand the kind of perception, we have allowed ourselves to propose the existence of three types of agents. Figure 13 shows that agents are connected with proprietary applications to obtain information about their users. In this case, the analyst decides that interaction with users will be realized with Web technology, so an application server is needed. This application server is represented by an environment application entity. This entity captures the operations that a user may request to its agent and vice versa. Figure 14. Activities to produce environment models in the analysisinception stage (Results of these activities are shown in Figure 13) Activity Identify applications from the environment (1.a) Associate operations on the applications (2) Determine perception of the agents (6) Result A set of applications Operations on the applications Associations between agents and applications

25 The INGENIAS Methodology and Tools 261 It is assumed that organizations participating in the case study own databases. We represent these databases as application entities. By connecting databases with agents, we enable agents to detect, for instance, when one item from the stock is running out. Databases could provide events that trigger agent actions or else agents could poll the database to obtain relevant information about the current state. The next step is to organize identified applications, resources, and roles into organizations. These organizations are produced with a similar set of activities, which are described in Figure 15. Figure 16 shows the organization that represents the Juul bookshop. This bookshop has two main roles: the buyer and the sales responsible. These roles were identified in Figure 12. Figure 15. Activities to produce an organization model in the analysisinception stage Activity Identify groups (1.a) Generate members (1.b) Identify goals (2c) Result A set of groups Elements that constitute groups Goals associated to organizations Figure 16. Initial representation of Juul Bookshop organization (To check notation, see Figure 1)

26 The INGENIAS Methodology and Tools 257 Starting the Process: Recommendations Though the INGENIAS methodology defines deliverables and activities to produce an MAS model for each viewpoint, there may be five different starting points for the development. Each one deserves special consideration: Environment. If the MAS to be developed will coexist with other software usually non-agent based software identifying this software in the first place is recommended. By using environment models, the developer can consider dependencies with legacy and proprietary software from the beginning. We tend to include elements like application servers or databases, which are very common in today s developments. Once these elements have been identified, the developer can determine how the agent s perception can be defined in terms of these applications and what functionality these applications can provide. Interaction. Researchers used to the object-oriented paradigm may prefer to use interactions and use cases. Interactions in this approach are similar to those in UML, but they include direct associations with tasks and agent mental states, so these interactions can enable further refinements with agent views or tasks and goal views. Organization. The organization of an MAS defines its system architecture. Top-down system-subsystem identification is a traditional technique in software engineering that could be applied using this view. The system could be the organization, and the subsystems each group in the organization. Interfaces of subsystems and system would be the roles belonging to each group. Interface operations would be the tasks and workflows belonging to the organization, and they would be assigned to roles with responsibility relationships. Agents. Initially determining system agents is a risky decision. Our experience is that it is very easy to fall into a situation where everything is an agent. Instead, we think it is better to start with roles and, later on, assign them to agents. However, if the MAS has to interact with already existing agents, perhaps it is a good idea to determine what can be expected from these agents before doing anything else. In such situations, there is a high risk of duplicating functionality already present in these agents; hence, the need to know first what they can do. Tasks and goals. This may reflect a functional approach. The developer identifies a set of tasks (and their expected output) that the system must execute. However, this approach may make it difficult to justify system goals, because they would be identified by asking why should the agent

27 258 Pavón, Gómez-Sanz & Fuentes execute this task?, which is not intuitive and compliant with a rational approach (an agent executes a task because it wants to satisfy one of its goals). An alternative is to identify the states that the system must reach by determining the system goals. Case Study: An E-Business Application As a case study to illustrate the INGENIAS methodology, we present here the Juul Møller Bokhandel A/S described by Anderson (1997), because it deals with some interesting agent features and applications, such as supply chain management, negotiation, workflows, enterprise modelling, and user modelling. It describes a bookshop that sells books to university students. The company has an agreement with professors and students to obtain a list of books used in their courses and sell them at special prices. The bookseller is considered as an organization in which there are departments in charge of sales and departments in charge of logistics. This organization has to negotiate with other organizations and publishers to acquire books at the best prices and within specific timing constraints. It can also negotiate for special arrangements for certain books that are needed for specific courses. Sales can be conventional or through the Internet. In this case study, the goal is to define an electronic sales system. Figure 16 shows a first approach to the organization of the bookshop. The Juul Møller Bokhandel A/S bookshop (from now on, the Juul bookstore) is modelled initially as two departments: Logistics and ESales. The first is responsible for delivering goods to customers and receiving books from publishers. The second is responsible for interacting with customers and providing representatives that interact with other publishers. During the case study, the reader will find references to different activities. These come from the development activity diagrams and can be accessed at The notation of each diagram has been noted in the caption of each figure and is detailed on the INGENIAS Web site. The construction phase, according to the USDP, deals mainly with the development of those use cases not considered in the elaboration phase. These remaining use cases should correspond to concrete situations that do not modify the key functionality. Therefore, and also due to space limitations, we omit the construction phase here, though we may make this information available in our Web site.

28 262 Pavón, Gómez-Sanz & Fuentes According to the specifications, there are other organizations as well: a publisher and a business school. They would be represented as the example from Figure 16: defining groups, associating goals, and existing resources. Design-Inception Stage There are no activities applicable here, since it is a very domain-specific stage. Figure 8 declares that in this stage a developer builds some prototypes with a rapid application tool or explores concrete aspects of the problem to test different technologies. In this case study, we dedicate this stage to start the development of the code generation module and to create some example Web pages to illustrate user interaction. Code generation module development starts by exploring how a session-oriented communication mechanism could be implemented with our target platform, JADE. The goal was constructing a small prototype that implemented a simple protocol in JADE, such as three message exchanges among three agents. This system is intended to test how communication management could take place and, later, how BDI concepts could be translated to the prototype. The prototype development took some time and was not finished in this stage. As mentioned in the implementation section, its development runs in parallel with the main stream of the case study, the generation of the system specification. In the end, the effort resulted in asimple agent architecture able to manage different conversations with different agents at the same time. This architecture will be introduced later, along with its role in the code generation module. The Web pages are aimed at showing the functionality to be implemented. This effort served to clarify what each kind of user expected from the system. We were more interested in the workflow of actions in the system than in the data itself. We wanted to create pages where users executed the actions they were supposed to and where we could examine the outputs. These initial experiments were used later in our servlet based workflow simulator, a module able to reproduce the workflow of activities from the specification in a servlet. Analysis-Elaboration Stage In the elaboration stage, in each iteration, the analyst reorganizes use cases, putting together related cases and discovering new ones. Though new use cases may appear, this process converges, according to the USDP, to a point where few use cases appear. In fact, use cases that represent key functionality constitute a small percentage of the whole application. Here we just consider those already presented in Figure 12.

29 The INGENIAS Methodology and Tools 263 Figure 17. Activities for generating initial specification of interactions in the analysis-elaboration stage Activity Result Identify goals for performing an interaction (1) Identify nature of interaction (3) Identify participants in interaction (2c) Generate an initial specification (4) A set of goals Category of interaction A set of participants Collaboration diagrams In the refinement, we show an extension of UML use case diagrams that introduces interaction entities into these diagrams. For each use case, a new interaction entity is created (Figure 18) and associated with it. Each interaction is considered independently, studying the goals it pursues and the actors involved. As an example, the interaction in Figure 19 has as its goal that the bookseller knows which book titles are more interesting to the school. This goal was identified by asking what state should I reach by executing this interaction. In the interaction, a professor will start the process and the sales representative of the bookshop will collaborate. The professor and the representative will each Figure 18. Result of a refinement of initial use cases and their association with interactions. It is a UML use case with associated interactions. (The meaning of the interaction symbol is given in Figure 5.)

30 264 Pavón, Gómez-Sanz & Fuentes Figure 19. Initial description of the interaction obtain book list (To check notation, see Figure 5) have different reasons to participate in this interaction. This will be discussed soon. The interaction is first detailed using a collaboration diagram, not shown here, with three messages: the professor offers a list of interesting books, the representative filters this list, taking into account the prices it can obtain in the sales market, and then the professor provides a final list of the filtered books. Later, this initial collaboration diagram will be transformed into a GRASIA diagram (Figure 6). Now it is time to think about two things: what goals justify the participation of these roles in the interaction, and what tasks will satisfy these goals. These questions are answered by the activities from Figure 21. Starting from the goal Bookshop knows what material is required, we refine the goal discovered in the interaction definition and create tasks to satisfy it. In this case, we assume that the goal identified in the interaction is a subgoal of two goals pursued by participating roles. These goals are collected into a separate diagram, organizing them with goal decomposition relationships and establishing dependencies among them. New goals may appear, but, as also with use cases, our experience says that there is a convergence point where no more goals appear. In other diagrams, goals are related with tasks representing plans for goal satisfaction (Figure 20). Figure 20 shows an initial assignment of tasks to a previous goal identified in Figure 19. The first task assignment is relatively intuitive. Elaborate University Book List produces a first draft of the list of books used in the school. To elaborate this list, it seems natural to access the school database and see what books are being used in each subject. This list is filtered by the bookshop, in the task Evaluate Interest Of Books, to produce a ranking of books according to the price it can get from other publishers and current stock. Here we assume that

31 266 Pavón, Gómez-Sanz & Fuentes all the information can be obtained from the bookshop database, but we could also say that a negotiation should be started with some publishers to see what prices they offer. This could be done by saying that the task produces an interaction. Filter books takes the book evaluation and produces a preprocessed book list. Later, Elaborate Book List would produce the final list of books to be bought. Again, the bookshop database may be required to generate a detailed list of the prices and books. Readers should be aware that, in determining the role of these tasks, we need to elaborate other diagrams, such as organization diagrams and agent diagrams, in order to determine who is responsible for executing these tasks. Later, in the design, these tasks will be composed into workflows. After identifying tasks, new resources, roles, and applications tend to appear. As in the analysis-inception, we collect them into a refinement of the organization, as shown in Figure 22. Figure 22 shows that the organization has several workflows, one per interaction. These workflows will collect tasks identified previously in diagrams such as Figure 20. The Obtains books from Publisher workflow details how the bookshop contacts the publisher, negotiates a price, and arranges a delivery. The Provide book list workflow details the tasks involved in obtaining the discount book list. The Organization Management workflow describes the tasks that Figure 22. Refinement of the Juul organization to include new items discovered (To check notation, see Figure 1)

32 The INGENIAS Methodology and Tools 265 Figure 20. Goal-task relationships. These relationships will be refined later to determine their nature (To check notation, see Figure 4) Figure 21. Activities to refine task and goals in the analysis-elaboration stage Activity Identify tasks and goals (1) Decompose goals (4) Associate goals and tasks (2) Decompose tasks (3) Determine relationships amongs goals (5). Associate tasks and interactions(6.a) Relate tasks with its products (6.c) and inputs (6.b) Associate tasks and applications (6.d). Result A set of goals and tasks Goal decomposition relationships Relationships among tasks and goals Task decomposition relationships Dependency relationships among goals Instances of WFProduce connecting task and Interaction entities Instances of WFProduce and WFConsume Instances of WFUse connecting applications and tasks

33 The INGENIAS Methodology and Tools 267 coordinate internal work within an organization. The Sell books through Internet workflow collects the tasks needed to get the order from the user, create a bill, and deliver a book. By executing these workflows, the organization will be able to achieve its main goal: sell books. Design-Elaboration Stage The design-elaboration stage adds another level of detail by describing how interactions occur, why, and what is the relationship between interactions, tasks, and the mental state of each agent. Also, in the design, the developer tries to describe aspects of its mental state management with the same notation. This way, a developer may say that a task produces the goals that direct the behaviour of an agent, or that old facts should be removed. Our recommendation in the design is to refine goals and workflows at the same time. Workflows clarify the relationships among tasks into different participants Figure 23. GRASIA interaction diagram detailing tasks and interaction units to elaborate a list of discounts on books (To check notation, see Figure 6)

34 268 Pavón, Gómez-Sanz & Fuentes of an interaction. The interaction, on the other hand, highlights when tasks are executed and the mental states required from the agents to start and continue interactions. Goals are refined by determining when a goal is satisfied and when it has failed. Figure 23 shows a more elaborate view of the interaction from Figure 19 using interaction units to abstract the communication technology and to include details about the speech act (FIPA, 2001) inform in this case, which is used in addition to mental attitudes of participants. These will be explained later. Also, the interaction allocates tasks, determining when the tasks from Figure 20 are started. The initial mental attitude of the professor (Figure 24) is referred to in an attribute in the UIInitiates relationship. In this case, the mental attitude appears. Figure 24 shows that, in order to obtain a book list, there should be an event indicating that there is a new book in the school database and a goal in the pending state. Pending state means that this goal has no assigned task yet and has not yet been refined into subgoals. The event would appear because there is a perception relationship between the agent playing the role professor and the business school database, similar to those identified in Figure 13 between the bookshop agent and the bookshop database. Proceeding in the same way with each actor of the interaction, we obtain a list of mental states to be achieved in runtime from an initial one. These mental states are the result of executing tasks. Therefore, the study of mental states and associated tasks could be continued within the goal/task view. Tasks could be examined also from the point of view of workflows. Figure 25 shows a workflow created with the tasks identified in the interaction view and the goal/task view. This workflow explains how to obtain a list of books from the business school. Figure 24. Mental state required to start a obtain book list interaction (To check notation, see Figure 3)

35 270 Pavón, Gómez-Sanz & Fuentes Figure 26. JADE-based agent architecture. It reuses JADE behaviours to implement protocols. SimpleBehavior (from behaviors) Agent (from co... AddNewConv ersation creates StateBehavior manages JADEAgent (from jade) creates RemoveFinished Conversations CyclicBehavior (from behaviors) sends a message with 0..* SyncSender 0..* receives a message with SyncRe ceiver creates DetectNotProcess edmessages modifies current state <<Interface>> StateUpdater modifies current state triggers changes in the mental state MentalState Internally, this agent has three basic behaviours: Detect messages not being processed and allocate them into a data structure. Create behaviours to deal with messages not processed and that are known to the agent. Remove behaviours to handle protocols that are already finished. The idea is to add State behaviour as demanded by internal processes of the agent, as a result of initiating an interaction, or by external processes, as a result of receiving a request to start an interaction. A benefit of this approach is a better use of resources and the introduction of the concept of conversation management that makes an agent able to handle several conversations at the same time. This architecture was created ad hoc, taking these requirements as a guideline and trying to implement one protocol with three states and three participants. Once the prototype worked, we translated the code into templates, such as that in Figure 27. The translation process, basically, traverses an interaction diagram determining in which interaction units a concrete actor participates. With these units, it generates a state machine that takes into account a subset of the states considered in the global interaction. The template from Figre 27 is instantiated for each interaction that the agent can start. The data used in this instantiation

36 The INGENIAS Methodology and Tools 269 Figure 25. Workflow interconnecting tasks identified in Figure 20 (To check notation, see Figure 2) Finally, again, new pieces of information that affect the analysis model of the organization should be reconsidered. It is unlikely that new workflows will appear, although there could be new goals, resources, or applications. Implementation Implementation of different elements from the specification leads us to develop some of the current modules that are included in the current IDK distribution. In this chapter, we focus on how a JADE-based communication is generated automatically from the specification. This effort was initiated in the designinception stage as a set of experiments aimed at obtaining an agent architecture. The result is shown in Figure 26. The architecture is biased by JADE components, since it necessitates using special classes to send or receive messages. This architecture uses State behaviour as a customized implementation of a state machine. This state machine can start two kinds of behaviours, which are responsible for sending and receiving messages. Each instance of a state machine can handle a kind of protocol, and the agent can handle several instances of the same state machine at the same time. Also, the agent can start these state machines on demand.

37 The INGENIAS Methodology and Tools 271 Figure 27. Part of the template responsible for sending messages in a State behaviour id="sendaction"@ if (sequence.equals("@v@iud@/v@")&& options.length>0) { int id="nextstates"@ if (options[count].equals("@v@possibleiu@/v@")){ boolean id="condfacts"@ @repeat id="condevents"@ @repeat id="condgoals"@ if (alldefined sb.setstate(options[count]); } } processed = true; are those of the interaction itself (obtained from Figure 23), the next interaction unit to be executed, and the mental attitude required in the agent in order to execute the task (which are obtained from Figure 24). So agents in the interaction have a partial knowledge of its current state, which makes interaction more efficient than having a global state shared among several agents. Just as an example, Figure 28 shows the result of instantiating the template with data from Figure 27 and Figure 24. At present, Figure 28 says that the interaction will not be started until there is a goal labeled Bookshop_knows_what_ material_is_required and an event labelled ThereIsANewBookInSubject. With respect to the verification of the specification, this template forces the specification to define mental states for agents initiating an interaction and to identify a condition or/and some mental entities, such as Goals or Facts. It could do even more, such as determining if the goal can appear in the mental state of the agent in the future. Instead of applying temporal logics, what this module does

38 272 Pavón, Gómez-Sanz & Fuentes Figure 28. Instantiated template from the Figure 27 (Source code shown here is only a part of the whole program) if (options[count].equals("inform_library_of_book_list")){ Boolean alldefined=true; Event newbookevent=getagent().getevent("thereisanewbookinschooldatabase"); alldefined=alldefined && fact!=null; StateGoal goal=getagent().getgoal("bookshop_knows_what_material_is_required"); alldefined=alldefined && goal!=null; if (alldefined && true){ sb.setstate(options[count]); } } count++; processed=true Figure 29. Failures in the specification detected with the JADE module is detect instances of this goal in the initial mental state of the agent (described in another diagram) or if the agent is responsible for a task producing it. Figure 29 shows an example of the errors that produce the current JADE module included in the distribution. This is not as precise as formal methods, although it is more intuitive for developers of average skill. Also, performing this kind of verification does not prevent the application of formal methods to perform further checking of the system and ensuring that the agent will have a determined mental state in the future. Conclusions The INGENIAS methodology is the result of experience in developing agentbased applications during the last five years. We have found that the use of a methodology is the key to the control and management of the development