Tropos: Process Meta-model

The Tropos process modelled by SPEM is composed of five disciplines: early requirements, late requirements, architectural design, detailed design and implementation [121]. In Figure 6.14 the Tropos process is shown in terms of the composing phases and their workproducts.

Figure 6.13: Tropos: concepts of goal diagram

Figure 6.14: Tropos Process

The early requirements discipline shows stakeholders and their goals, dependencies and resources (Figure 6.15).

Figure 6.15: Tropos: early requirement

The late requirements discipline shows the “system-to-be” as new actor and its goals, dependencies and resources (Figure 6.16).

Figure 6.16: Tropos: late requirement

The architectural design discipline defines the system architecture in terms of sub- actors and their relatives goals, dependencies and relations. In addition the software agents related to sub-actors are defined (Figure 6.17).

Figure 6.17: Tropos: architectural design

The detailed design discipline covers the agent design in terms of capabilities, beliefs, goals and plans (Figure 6.18).

Figure 6.18: Tropos: detailed design

The implementation discipline creates a code skeleton of the detailed design specifica- tions (Figure 6.19).

Figure 6.19: Tropos: implementation

6.4

Gaia

This section provides a description of the Gaia concept meta-model. The process meta- model is not reported because it is currently not available for the new version of 2003 [229]. The process meta-model of the previous version [225] could be found in [121].

The meta-model of GAIA taken is depicted in Figure 6.20.

Organisations are viewed in GAIA as collections of roles, which are defined in terms of responsibilities, permissions, activities and protocols. Responsibilities define the func- tionality of the role, while permissions are the “rights” which allow the role to perform its responsibilities. Activities are computations that can be executed by the role along, and protocols define the interaction between roles. As soon as the complexity of systems increases, modularity and encapsulation principles suggest dividing the system into dif- ferent sub-organisations, with a subset of the agents being possibly involved in multiple organisations.

In each organisation, an agent can play one or more roles, which defines what it is expected to do in the organisation, both in concert with other agents and in respect to the organisation itself. To accomplish their roles, agents typically need to interact with each other to exchange knowledge and coordinate their activities. These interactions occur according to patterns and protocols dictated by the nature of the role itself. In addition, a MAS is typically immersed in an environment with which the agents may need to interact in order to accomplish their roles. That portion of the environment that agents can sense and effect is determined by the agent’s specific role, as well as by its current status. Identifying and modelling the environment involves determining all the

entities and resources that the MAS can exploit, control, or consume when it is working towards the achievement of the organisational goal.

Figure 6.20: Gaia: concept meta-model

However, although role and interaction models can be useful to fully describe an exist- ing organisation, they are of limited value in building an organisation. The organisational structure is not implicitly defined via the role model, instead the identification of the roles is explicitly derived from an analysis of the chosen organisational structure. As a con- sequence the role model and the related interaction model will be completely defined in the design phase when an accurate identification of the organisational structure will take place. This motivates the introduction of the notions of organisational rules and organi- sational structures. It is possible to distinguish between safety and liveness organisational rules. The former refer to the invariants that must be respected by the organisation for it to work coherently; the latter express the dynamics of the organisation. A role model implicitly defines the topology of the interaction patterns and the control regime of the organisations activities. That is, it implicitly defines the overall architecture of the MAS organisation, i.e. its organisational structure.

6.5

Summing up

This chapter has presented the meta-models of some most known AO methodologies. As mentioned above a meta-model addresses all of the different aspects of methodologies – i.e., the process to follow and the abstractions adopted by methodologies – and it is necessary for studying the completeness and the expressiveness of a methodology, and when comparing different methodologies. These characteristics are important and make meta-modelling techniques very appealing in the the context of AOSE where there is a incredible proliferation of methodologies.

However, the power of the meta-modelling is not only limited to the study and the comparison of the methodologies. In fact, the use of meta-modelling techniques allows de- signers to combine fragments [36] – i.e., pieces of methodologies – of existing AO method- ologies for obtaining a new methodology that satisfies the requirements of a specific ap- plication domain (Subsection 4.3.3). This method is called Method Engineering [15, 16] that is the engineering discipline to design, construct and adapt methodologies, techniques and tools for the development of information systems. Similarly as software engineering is concerned with all aspects of software production, method engineering deals with all engineering activities related to methodologies, techniques and tools.

The assembly of a new methodology starting from the fragments of the existing methodologies – or fragments built ad hoc – is not a new idea. The study started in the early nineties in the object-oriented field [16, 84, 185] and then it was introduced in the agent-oriented field in 2003 by the IEEE-FIPA Methodology Technical Committee (FIPA Foundation for Intelligent Physical Agents) [121]. This group have both defined the method fragments for AO methodologies and developed a technique for the fragments integration [36] and its relative tool [18].

So the study of the existing methodologies’s meta-models – for abstractions and for processes – becomes the key tool for enabling the construction of new methodologies.

7

The Agents & Artifacts Meta-Model

This chapter presents a new conceptual framework – called Agents&Artifacts – for mod- elling and designing agent-oriented systems. According to social / psychological theories like Activity Theory (AT) [137], artifacts plays a fundamental role in the context of human organisations for supporting cooperative work and, more generally, complex collaboration activities. Artifacts are either physical or cognitive tools that are shared and exploited by the collectivity of individuals for achieving individual as well as global objectives. The conceptual framework of artifacts for MAS is meant to bring the same sort of approach to MAS. The adoption of artifacts in the MAS context changes the traditional view of the MAS environment: from a simple deployment context MAS environment is transformed to a new MAS design dimension.

Then agents and artifacts become the new “ingredients” for engineering agent-oriented systems. More precisely, agents are the basic abstractions to represent active, task-/goal- oriented components, designed to pro-actively carry out one or more activities towards the achievement of an objective, requiring different levels of skill and reasoning capabilities. On the other hand, artifacts are the basic abstractions to represent passive, function- oriented building blocks, which are constructed and used by agents, either individually or cooperatively, during their working activities. So agents can be used to model indi- vidual activities, while artifacts can be well suited for mediating the interaction between individual components and their environment (including the other components), and for embodying the portion of the environment that is explicitly designed to support agents’ activities [146].

The reminder of this chapter is organised as follows: Section 7.1 presents the general view of the A&A meta-model, Section 7.2 presents artifacts and their characteristics / features, and Section 7.3 presents the concept of workspace, the third ingredient of the A&A meta-model. Finally Section 7.4 summarises the chapter.

7.1

A&A Meta-Model

Agents&Artifacts (A&A) is a novel conceptual framework introduced in the context of AOSE for modelling and designing agent-based software systems [146, 152, 153]. A&A

introduces three basic kinds of general-purpose abstractions to understand and model complex systems [130]:

• agents: pro-active components of the systems, encapsulating the autonomous exe- cution of some kind of activity inside some sort of environment.

• artifacts: passive components of the systems such as resources and media that are intentionally constructed, shared, manipulated and used by agents to support their activities, either cooperatively or competitively (Section 7.2).

• workspaces: logical containers of agents and artifacts, useful for defining the topol- ogy for the environment and providing a way to define a notion of locality (Sec- tion 7.3).

So one fundamental difference with respect to existing agent-based models is the adop- tion of artifacts as a first-class abstraction also to model and design those parts of the MAS which are function-oriented, i.e. designed to provide some kind of functions [130].

One of the key issues of in the A&A approach is how artifacts can be effectively exploited to improve agent ability to achieve individual as well as social goals [152]. The main questions to be answered are then: How should agents reason to use artifacts in the best way, making their life simpler and their action more effective? How can agents reason to select artifacts to use? How can agents reason to construct or adapt artifact behaviour in order to fit their goals?

On the one hand, the simplest case concerns agents directly programmed to use specific artifacts, with usage protocols directly defined by the programmer either as part of the procedural knowledge / plans of the agent for goal-governed systems, or as part of agent behaviour in goal-oriented system. In spite of its simplicity, this case can bring several advantages for MAS engineers, exploiting separation of concerns for programming simpler agents, by imposing some burden upon specifically-designed artifacts. On the other hand, the intuition is that in the case of fully-open systems, the capability of the artifact to describe itself, its function, interface, structure and behaviour could be the key for building open MASs where intelligent agents dynamically look for and select artifacts to use, and then exploit them for their own goals.

At first glance, it seems possible to frame the agent ability to use artifacts in a hier- archy, according to five different cognitive levels at which the agent can use an artifact [152, 153]:

unaware use at this level, both agents and agent designers exploit artifacts without being aware of it: the artifact is used implicitly, since it is not denoted explicitly. In other words, the representation of agent actions never refers explicitly to the execution of operation on some kind of artifact.

embedded / programmed use at this level, agents use some artifacts according to what has been explicitly programmed by the designer: so, the artifact selection is explicitly made by the designer, and the knowledge about its use is implicitly encoded by the designer in the agent. In the case of cognitive agents, for instance, agent designers can specify usage protocols directly as part of the agent plan. From the agent point of view, there is no need to understand explicitly artifact operating instructions or function: the only requirement is that the agent model adopted could be expressive enough to model in some way the execution of external actions and the perception of external events.

cognitive use at this level, the agent designer directly embeds in the agent knowledge about what artifacts to use, but how to exploit the artifacts is dynamically discov- ered by the agent, reading the operating instructions. Artifact selection is still a designer affair, while how to use it is delegated to the agent’s rational capabilities. So, generally speaking the agent must be able to discover the artifact function, and the way to use it and to make it fit the agent goals. An obvious way to enable agent discovery is to make the artifact explicitly represent their function, interface, structure and behaviour.

cognitive selection and use at this level, agents autonomously select artifacts to use, understand how to make them work, and then use them: as a result, both artifact selection and use are in the hands of the agents. It is worth noting that such a selection process could also concern sets of cooperative agents, for instance interested in using a coordination artifact for their social activities.

construction and manipulation at this level, agents are lifted to the role of designers of artifacts. Here, agents are supposed to understand how artifacts work, and how to adapt their behaviour (or to build new ones from scratch) in order to devise a better course of actions toward the agent goals. For its complexity, this level more often concerns humans: however, not-so-complex agents can be adopted to change artifact behaviour according to some schema explicitly pre-defined by the agent designers.

To enable such scenarios, proper models, theories and then supporting frameworks are needed, making artifacts first-class entities from design to runtime.

7.2

Artifacts

The sources for a theory of artifacts can be found in a number of different research fields, ranging from organisational / psychological theories – such as Activity Theory (AT) [137] – to anthropology [75, 89], and obviously including the area of coordination models [159]. In particular, AT is based on a structured model that constitutes an activity, and on the

mediating role of artifacts. Any activity is characterised by a subject, an object and by one or more mediating artifacts:

• a subject is an agent or group engaged in an activity;

• an object (in the sense of objective) is held by the subject and motivates the activity, giving it a specific direction (the objective of the activity); the object of activity can be a wide variety of things, from mental objectives (e.g., making a plan) as well as physical ones (e.g., writing a paper);

• the mediation artifacts, which are the tools that enable and mediate subject actions toward the object of the activity. The mediating artifacts can be either physical or abstract / cognitive; examples are: symbols, rules, operating procedures, heuristics, scripts, individual / collective experiences, and languages.

According to AT, mediating tools have both an enabling and a constraining function: on the one hand, they expand out possibilities to manipulate and transform different objects, but on the other hand the object is perceived and manipulated not ’as such’ but within the limitations set by the tool. Mediating artifacts shape the way human beings interact with reality [176]. Given this definition, artifacts could be fruitfully adopted as enabling and constraining tools also in the agent paradigm, where MASs are built around the concepts of society of agents. So, two basic aims can be immediately identified in the artifact abstraction:

• social (constructive): an artifact is an abstraction essential for constructing social activities, creating the agent interaction space;

• normative (regulatory): an artifact is an abstraction essential for ruling social ac- tivities, ruling the agent interaction space.

So, artifacts functions as media enabling agent interaction (such as coordination ar- tifacts [153]) play a key role in MAS, being what actually shapes the interaction space among the agent. So, changing the behaviour of an artifact working as medium could have a strong impact on the overall system behaviour.

In particular artifacts allow agents to use the same cognitive level when they inter- act with other agents and with environment. Usually, agents speak with each other via languages like FIPA-ACL (agent communication language) [62], while exploiting the en- vironmental resources as a means for lower-level interaction. So, the agents’ interaction space spans over different cognitive levels, because agents cannot interact with the other components (agents and resources) of the MAS in a uniform way [188]. Artifacts, instead, make it possible to wrap the resources of a MAS and bring them to the cognitive level of agents, so that both the interaction among agents (on the one side) and between agents and artifacts (on the other) can occur at the same cognitive level, exploiting the high-level

Figure 7.1: An abstract model of the artifact [180]

language that describes artifacts’ services as the common language. In order to make this possible, the language should be standard enough to support both the MAS openness and agent mobility, allowing heterogeneous agents to join a MAS, discover and use the services provided by the artifacts. By the way, this choice also simplifies the design of the MAS interaction space, since engineers no longer need to design ad-hoc protocols for each resource in the environment (the relationship between each resource and the artifact that wraps it concerns the internal design of the artifact and does not affect the interaction space of the MAS).

A more detailed characterisation of the artifact abstraction, in terms of fundamental properties and features, can be found in Subsection 7.2.1, while Subsection 7.2.2 outlines a possible taxonomy for artifacts.

7.2.1

Features

According to [180], each artifact type is to be equipped by the artifact designer with a manual composed essentially by the (i) a usage interface, (ii) operating instructions, and (iii) a function description (Figure 7.1).

Usage Interface — One of the core differences between artifacts and agents, as com- putational entities populating a MAS, lies in the concept of operation, which is the

means by which an artifact provides for a function [152]. An agent executes an action over an artifact by invoking an artifact operation. Execution possibly ter- minates with an operation completion, typically representing the outcome of the invocation, which the agent comes to be aware of in terms of perception. The set of operations provided by an artifact defines what is called its usage interface, which (intentionally) resembles interfaces of services, components or objects in the object- oriented sense of the term. In MASs, this interaction schema is peculiar to artifacts, and makes them intrinsically different from agents. While an agent has no interface, acts and senses the environment, encapsulates its control, and brings about its goals proactively and autonomously, an artifact has instead a usage interface, is used by agents (and never the opposite), is driven by their control, and automates a specific service in a predictable way without the blessing of autonomy. Hence, owning an interface strongly clearly differentiates agents and artifacts, and is therefore to be used by the MAS engineer as a basic discriminative property between them (Figure 7.1).

Operating Instructions — Coupled with a usage interface, an artifact could provide agents with operating instructions [152]. Operating instructions are a description of the procedure an agent has to follow to meaningfully interact with an artifact over time. Most remarkably, one such description is history dependent, so that actions and perceptions occurring at a given time may influence the remainder of the interaction with the artifact. Therefore, operating instructions are basically seen as an exploitation protocol of actions / perceptions. This protocol is possibly furthermore annotated with information on the intended preconditions and effects on the agent mental state, which a rational agent should read and exploit to give a meaning to operating instructions. Artifacts being conceptually similar to devices used by humans, operating instructions play a role similar to a manual, which a human reads to know how to use the device on a step-by-step basis, and depending on the expected outcomes he/she needs to achieve (Figure 7.1).

Function Description — Finally, an artifact could be characterised by a function de- scription [152]. This is a description of the functionality provided by the artifact, which agents can use essentially for artifact selection. In fact, differently from oper- ating instructions, which describe how to exploit an artifact, a function description describes what to obtain from an artifact. Clearly, function description is an abstrac- tion over the actual implementation of the artifact: it hides inessential details over