Computer Science Changes    |    Index    |    Search
::: MessageMethodology :::
Parents: WebHome > AgentMethodologies
 
  ACM . Agent . MessageMethodology # Edit # Attach # Diffs # Printable # More :::

Main
• Register
• Users
• Site Map

Curriculum

Agent Web
• projects

Algorithms

Web Learn

Image Kit

ProgTech

Publishing

MESSAGE - Methodology for Engineering Systems of Software Agents

1. INTRODUCTION

1.1 Agent Oriented Software Engineering

Most recent software engineering methodologies are designed for an object-oriented approach. Engineering of commercial MAS (multi-agent system) requires the availability of agent oriented software engineering (AOSE) methodologies. Most MAS systems will be implemented with object and component based technology in the near future unless a widely accepted agent programming language emerges. In this case, viewed at a detailed level, an agent is a relatively complex object or component. However, this is like considering that a house is a pile of bricks, but it is more convenient to view a house in terms of higher level concepts such as living room, kitchen and bedroom. When an agent is viewed at a more abstract level, structures come into focus that are not found in conventional objects or components. Agent-orientation is thus a paradigm for analysis, design and system organisation. An agentoriented modelling language must provide primitives for describing these higher-level structures, the inspiration for which derives from cognitive psychology and social modelling via artificial intelligence.

MESSAGE (Methodology for Engineering Systems of Software Agents) is an AOSE methodology which builds upon current software engineering best practices covering analysis and design of MAS which is appropriate for use in mainstream software engineering departments. It has well defined concepts and a notation that is based on UML whenever appropriate.

1.2 Comparison to Other Approaches

Work toward an AOSE methodology can be divided into two broad categories. The first category aims to apply existing software engineering methodologies to AOSE. AgentUML (AUML) for example defines extensions to UML with notations suited for agent concepts. AUML has extended UML’s interaction diagrams to handle agent interaction protocols. Although this notation is useful and has been adopted within MESSAGE, it does not have the concept of agent at its centre, i.e. specifying an object’s behaviour in terms of interaction protocols does not make it an agent. The second category of work aims at developing a methodology from agent theory, mainly covering analysis and design. Typically these methodologies define a number of models for both analysis and design such as Gaia and MAS-CommonKads. The Gaia methodology has two analysis models and three design models. While the analysis models are based on well-defined concepts, these only represent a subset of the concepts required for agent oriented analysis. The design models are not clearly explained and the authors envisage OO methods being used for detailed design. Mas-Common-Kads has six models for analysis, and three for design. While these models are comprehensive, the method lacks a unifying semantic framework and notation. In addition to this work, goal analysis techniques have been shown to be very useful. The techniques range from informal to formal analysis and cover functional and non-functional goal analysis. MESSAGE combines the best features of the above approaches.

1.3 Contributions

The MESSAGE/UML methodology covers MAS analysis and design and is designed for use in mainstream software engineering departments.

The contributions of MESSAGE are the agent knowledge level concepts, and the diagrams for viewing these concepts in the analysis model that have been added to UML. The case-study focuses on illustrating these new agent related concepts and the new diagrams to visualise them. A complete case study would also involve using existing UML notation in addition to the new notation.

2. MESSAGE DESCRIPTION

2.1 Extending UML for Agent Modelling

UML is a convenient starting point for an agent-oriented modelling language for the following reasons:

  • UML is widely accepted as a de facto standard for objectoriented modelling, many software engineers are trained in its use, and commercial software tools are available to support it (some of which are extendable).
  • The object- and agent-oriented paradigms are highly compatible. Agent-oriented concepts can readily be defined in terms of object-oriented ones.
  • UML is based on a meta-model (UML uses the MOF metamodelling language), which makes it extendable.

The MESSAGE modelling language is related to UML as follows:

  1. It shares a common metamodelling language (metametamodel)with UML and MOF
  2. It extends the UML metamodel with 'knowledge level' agentoriented concepts.

2.2 Main MESSAGE Concepts

2.2.1 Foundations
UML concepts are used to model MESSAGE entities at a detailed (or micro) level. That is, from a structural standpoint they are objects with attributes and operations realised by methods; from a behavioural point of view they are state machines. The main UML behavioural concepts that are used to define the 'physics' of the MESSAGE worldview are: Action, Event and State. The world is seen as a collection of StateMachines. A full description of a world state consists of a description of the state of every StateMachine within it at a point in time. The evolution of the world in time can be described fully by a description of the world state at a specific point in time and a list of all the Events in which the world participates before and after that time. This full description is referred to as the world history. A Situation is a knowledge (or macro) level analogue of a world state.

2.2.2 Knowledge-level concepts
Most of the MESSAGE knowledge level entity concepts fall into the main categories: ConcreteEntity, Activity, and MentalStateEntity. The main types of ConcreteEntity are:

Agent: An Agent is an atomic autonomous entity that is capable of performing some (potentially) useful function. The functional capability is captured as the agent's services. A service is the knowledge level analogue of an object's operation. The quality of autonomy means that an agent's actions are not solely dictated by external events or interactions, but also by its own motivation. We capture this motivation in an attribute named purpose. The purpose will, for example, influence whether an agent agrees to a request to perform a service and also the way it provides the service. SoftwareAgent and HumanAgent are specialisations of Agent.

Organisation: An Organisation is a group of Agents working together to a common purpose. It is a virtual entity in the sense that the system has no individual computational entity corresponding to an organisation; its services are provided and purpose achieved collectively by its constituent agents. It has structure expressed through power relationships (e.g. superiorsubordinate relationships) between constituents, and behaviour/co-ordination mechanisms expressed through Interactions between constituents.

Role: The distinction between Role and Agent is analogous to that between Interface and (object) Class: a Role describes the external characteristics of an Agent in a particular context. An Agent may be capable of playing several roles, and multiple Agents may be able to play the same Role. Roles can also be used as indirect references to Agents. This is useful in defining reusable patterns.

Resource: Resource is used to represent non-autonomous entities such as databases or external programs used by Agents. Standard object-oriented concepts are adequate for modelling Resources.

The main types of Activity are:

Task: A Task is a knowledge-level unit of activity with a single prime performer. A task has a set of pairs of Situations describing pre- and post-conditions. If the Task is performed when a precondition is valid, then one can expect the associated postcondition to hold when the Task is completed. Composite Tasks can be expressed in terms of causally linked sub-tasks (which may have different performers from the parent Task). Tasks are StateMachines, so that e.g. UML activity diagrams can be used to show temporal dependencies of sub-tasks.

Interaction and InteractionProtocol: The MESSAGE concept of Interaction borrows heavily from the Gaia methodology. An Interaction by definition has more than one participant, and a purpose which the participants collectively must aim to achieve. The purpose typically is to reach a consistent view of some aspect of the problem domain, to agree terms of a service or to exchange to results of one or more services. An InteractionProtocol defines a pattern of Message exchange associated with an Interaction.

The internal architecture of an agent typically is based on one of several models derived from cognitive psychology. MESSAGE is intended to be applicable to a variety of agent cognitive architectures. However, without some basic abstract reference model it is difficult to say anything meaningful. We suppose that the architecture separates an inference mechanism from a knowledge base and a working memory. The knowledge base contains fixed or slowly changing domain or problem-solving knowledge in a declarative form. The working memory contains more transient sensed or derived information. We view this working memory as an abstract database holding instances of MentalStateEntities, and its contents define the Agent’s mental state For present purposes we focus on one type of MentalStateEntity: Goal.

Goal: A Goal associates an Agent with a Situation. If a Goal instance is present in the Agent’s working memory, then the Agent intends to bring about the Situation referenced by the Goal. Some Goals are intrinsic to the agent’s identity, and are derived from its purpose. These persist throughout the life of the Agent. Others are transient tactical Goals. It is often useful to express the purpose in terms of a utility function that associates ’goodness values’ with Situations. The target situation of the Goal is then the one that is estimated to maximise utility (determined dynamically). Note that the agent’s knowledge base needs to include ’rules’ governing assertion and deletion of (tactical) Goals. One fairly standard rule would be to assert a Goal to provide a given service whenever the Agent agrees with another Agent to do so.

Two other simple but important concepts used in MESSAGE are: InformationEntity (an object encapsulating a chunk of information) and Message. The agent-oriented concept of Message differs from the object-orient one in a number of respects. In UML, a Message is a causal link in a chain of behaviour, indicating that an Action performed by one object triggers an Action by another object. In MESSAGE, a Message is an object communicated between Agents. Transmission of a Message takes finite time and requires an Action to be performed by the Sender and also the receiver. The attributes of a Message specify the sender, receiver, a speech act (categorising the Message in terms of the intent of the sender) and the content (an InformationEntity). Figure 1 MESSAGE Concepts gives an informal agent-centric overview of how these concepts are interrelated.

concepts.gif

Figure 1 MESSAGE Concepts

2.3 Analysis Model Views

An analysis model is a complex network of inter-related classes and instances derived from concepts defined in the MESSAGE/UML metamodel. MESSAGE defines a number of views that focus on overlapping sub-sets of entity and relationship concepts.

Organisation view (OV) - This shows ConcreteEntities (Agents, Organisations, Roles, Resources) in the system and its environment and coarse-grained relationships between them (aggregation, power, and acquaintance relationships). An acquaintance relationship indicates the existence of at least one Interaction involving the entities concerned.

Goal/Task view (GTV) - This shows Goals, Tasks, Situations and the dependencies among them. Goals and Tasks both have attributes of type Situation, so that they can be linked by logical dependencies to form graphs that show e.g. decomposition of high-level Goals into sub-goals, and how Tasks can be performed to achieve Goals. Graphs showing temporal dependencies can also be drawn, and we have found UML Activity Diagram notation useful here.

Agent/Role view (AV) - This focuses on the individual Agents and Roles. For each agent/role it uses schemata supported by diagrams to its characteristics such as what Goals it is responsible for, what events it needs to sense, what resources it controls, what Tasks it knows how to perform, 'behaviour rules', etc.

Interaction view (IV) - For each interaction among agents/roles, shows the initiator, the collaborators, the motivator (generally a goal the initiator is responsible for), the relevant information supplied/achieved by each participant, the events that trigger the interaction, other relevant effects of the interaction (e.g. an agent becomes responsible for a new goal). Larger chains of interaction across the system (e.g. corresponding to uses cases) can also be considered.

Domain view (DV) - Shows the domain specific concepts and relations that are relevant for the system under development (e.g. for a system dealing with making travel arrangements, this view will show concepts like trip, flight, ticket, hotel...).

3. ANALYSIS PROCESS

The purpose of Analysis is to produce a model (or collection of models) of the system to be developed and its environment, that is agreed between the analyst and the customer (and other stakeholders). It aids communication between the development team and the customer, and provides a basis from which design can proceed with confidence. The analysis models are produced by stepwise refinement.

Refinement Approach: The top level of decomposition is referred to as level 0. This initial level is concerned with defining the system to be developed with respect to its stakeholders and environment. The system is viewed as a set of organisations that interact with resources, actors, or other organisations. Actors may be human users or other existing agents. Subsequent stages of refinement result in the creation of models at level 1, level 2 and so on.

At level 0 the modelling process starts building the Organisation and the Goal/Task views. These views then act as inputs to creating the Agent/Role and the Domain Views. Finally the Interaction view is built using input from the other models. The level 0 model gives an overall view of the system, its environment, and its global functionality. The granularity of level 0 focuses on the identification of entities, and their relationships according to the metamodel. More details about the internal structure and the behaviour of these entities are progressively added in the next levels.

In level 1 the structure and the behaviour of entities such as organisation, agents, tasks, goals domain entities are defined Additional levels might be defined for analysing specific aspects of the system dealing with functional requirements and non functional requirements such as performance, distribution, fault tolerance, security. There must be consistency between subsequent levels. In the MESSAGE project only level 0 and level 1 have been considered.

Analysis Refinement strategies: Several strategies are possible for refining level 0 models. Organisation-centred approaches focus on analysing overall properties such as system structure, the services offered, global tasks and goals, main roles, resources. The agents needed for achieving the goals appear naturally during the refinement process. Then co-operation, possible conflicts and conflict resolution may be analysed.

Agent centred approaches focus on the identification of agents needed for providing the system functionality. The most suitable organisation is identified according to system requirements. Interaction oriented approaches suggest progressive refinement of interaction scenarios which characterise the internal and external behaviour of the organisation and agents. These scenarios are the source for characterising task, goal, messages, protocols and domain entities.

Goal/task decomposition approaches are based on functional decomposition. System roles, goals and tasks are systematically analysed in order to determine the resolution conditions, problemsolving methods, decomposition and failure treatment. Task preconditions, task structures, task output and task post-condition may determine what Domain Entities are needed. Goals and tasks must be performed by agents playing certain roles. Consequently looking at the overall structure of goal and tasks in the Goal/task view decisions can be made on the most appropriate agents and organisation structure for achieving those goals/tasks.

The experience in MESSAGE shows that the different views of the system leave the analyst free to choose the most appropriate strategy. In practice a combination of refinement strategies with frequent loop-backs among them are used. The analysis process might start with the OV, then switch to the AV and continue with the IV. The results of the analysis of specific interaction scenarios may lead to reconsider part of OV, and starting again refining and adapting OV constituents.

(C) Giovanni Caire, Francisco Leal, Richard Evans "Agent Oriented Analysis using MESSAGE/UML"

-- NadejdaLukasheva? - 26 Apr 2004


Attachment sort Action Size Date Who Comment
concepts.gif manage 4.1 K 26 Apr 2004 - 17:50 NadejdaLukasheva?  

Rambler's Top100 Rambler's Top100


# Edit menu  

Topic revision r1.4 - 25 May 2004 - 08:34 GMT - AndreyUstyuzhanin
Topic parents: WebHome > AgentMethodologies
Copyright © 2003-2017 by the contributing authors.