Organisation Dependencies Description
In order to maximize its goal achievement expectation, an agent has to be able to estimate the competences of its future partners and to identify the most appropriate collaborators. The Capacity concept allows us to represent the competences of an agent or a set of agents. Capacity is a specialization of the AbstractCapacity element. A Capacity describes what an Agent should be able to do in order to satisfy the requirements it is responsible for. This means that the set of Capacities obtained by refining the AbstractCapacity of the Problem Domain, becomes a part of the specification of the system requirements in the Agency Domain. Capacities describe what the agent is capable of doing at an abstract level, independently of how it does it (this is a concern that may be dealt with the Service concept). Capacity finds an implementation in the Service provided by the role and it is used to model what is done by an AgentTask in order to contribute in providing a service.
A service implements a capacity thus accomplishing a set of functionalities on behalf of its owner, a role (definition inspired from the Web Services Architecture of the W3C7). These functionalities can be effectively implemented by a set of capacities required by the owner role. A role can thus publish several of its capacities and other members of the group can take profit of them by means of a service exchange. Similarly a group, that is able to provide a collective capacity can share it with other groups by providing a service. The relationship between capacity and service is thus crucial in our metamodel.
A capacity is an internal aspect of an organisation or an agent, while the service is designed to be shared between various organisation or entities. A service is created to publish a capacity and thus to allow other entities to benefit from it.
It will be assumed that an organisation is able to provide a service if the service is provided by of one of its roles. A role may provide a service if it manages/supervises a workflow where either:
- the service is implemented in one of its own behaviour, the role owns a capacity with a compatible description.
- the service is obtained from a subset of other roles of the same organisation by interacting with them using a known protocol; this is a service composition scenario where the work plan is a priori known and performance may be someway ensured,
- the service is obtained from the interaction of roles of the same organisation but the work plan is not a priori known and the service results in an emergent way.
In the last case, the management of a service provided by the global organisation behaviour is generally associated to one of the organisation’s roles. It can also be managed by at least one of the representative of the various holons playing roles defined in the corresponding organisation.
This phase aims also at identifying and describing resources that are manipulated by roles. Resources are abstractions of environmental entities accessed by boundary roles; in order to access resources, roles need specific capacities that are now purposefully introduced (and then realized by services if necessary).
The first aim of this activity is to identify resources manipulated by roles; this often implies identifying new capacities devoted to manipulate these resources. Moreover, since organisations depend on each other through service exchanges, services provided by roles (while exploiting their capacities and accessing resources) can be identified in this activity. An AgentRole can be responsible for providing one of more services.
This activity describes the interfaces used by the system to manipulate the used resource. When capacities and services are fully described, a check is necessary to ensure that each capacity is associated with its set of possible service-level realisations. This matching between service and capacity allows the initialization of a repository that may be used to inform agents on how to dynamically obtain a given capacity. Moreover it also verifies that the system hierarchical decomposition is correct. This matching should validate the contribution that organisations acting at a given level give to upper-level organisations.
Another aim of this activity consists in identifying resources of the environment accessed by organisations (through their roles). In this way dependencies of organisations with the real world are made explicit.
Capacities identified during Capacity Identification or Role Behaviour Description activities are described and associated to corresponding implementations (services) in this activity. Solution ontology details concepts associated to roles, and may thus provide elements to refine the knowledge manipulated by roles. This knowledge is an important part of capacity and associated services descriptions.
For each organisation, capacities, services and resources are added to the previously designed Capacity Identification class diagram. A text document is also produced during this activity to report the description of capacities, service interfaces and a table summarizing a possible matching between capacities and services.
MAS Metamodel Elements
Define(Service), Relate(AgentRole, Service), Define(Resource), Define (Capacity), Relate(AgentRole, Resource), Relate(Capacity, Resource), Relate(Capacity, Service).
Work to be done
The first task in this activity consist in identifying resources (database, hardware, etc) manipulated by roles. Giving this set of resources, the set of associatied capacities have to be identified (Probably some of them have been already identified). The second task deals with the identification of services provided roles and organisations. When all these elements have been identified, each of them has to be described. This description is provided using one of the standard of the W3C; XML or RDF are well adopted but WSDL or SOAP can also be used for service description. The final task consists in matching capacities with their possible service implementations.
Service exchange is often a need arising from the beginning of the requirements analysis phase. In the proposed approach, some services can be identified by exploiting relationships among use cases, especially those crossing different organisational packages. If two use cases belonging to two different organisations are related by an “include” or ”extend“ relationship, it is very likely that corresponding organisations will cooperate in a service exchange. Identification of resources can be done by identifying resources that can be accessed and manipulated by different boundary roles: databases, files, hardware devices, etc. Resources are external to the role; a capacity is generally used to interface the boundary role with the new resource. Each capacity needs a realisation in form of a service that is purposefully defined for that.
Figure 22 describes capacities, services and resources in relation with the three organisations involved in the model of the Robot Soccer Simulator case study. Contributions of each organisation to the upper level have been detailed by using a capacity and the associated service, e.g. SimulateTeamBehavior or PlayStrategy. One resource has been identified, it represents a logging file, and the Log capacity has been created to manage it. It is interesting to note that this capacity does not need a service realisation because the corresponding fonctionality is internal to the GameObserver role that does not need to publish it as a service. This capacity does not represent a contribuion between organisation but a competence required by a role to access to one of its dependencies.
|Figure 22: Dependencies of the Team Simulation organisation |