The notion of capacity was introduced to control and exploit additional behaviours emerging from roles interactions, by considering an organisation as able to provide a capacity. It describes what an organisation is able to do. Organisations used to model role interactions offer a simple way to represent how these capacities are obtained from roles. A role may require that individuals playing it have some specific capacities to properly behave as defined. An individual must know a way of realizing all required capacities to play a role. In other words, the main objective of the Capacity Identification activity (CI) is the definition of generic role behaviours by identifying which know-how a role requires from the individual that will play it; The capacity element constitutes a layer between the role behaviour and the future entities which will want to play this role. Basing the description of role behaviour on capacities, thus gives to the role more genericity and modularity. A complete description of the concepts of capacity and template that describes a capacity can be found in . For the scope of this paper it is worth saying that the capacity is a description of what an organisation (and therefore one of its composing roles) is able to do without any kind of specification on how to do it. This means that the results prescribed by a capacity may be reached by adopting different strategies (the realization of the capacity is a concern of the Agency Domain and will be discussed later). For example if entity’s personal acquaintances influence a particular choice that is required in the role behaviour, i.e. the choose of the best partner to fulfil a task, this choice may be externalized as a capacity. Indeed there are various ways of carrying out a capacity and they depend on data which are strictly related to the entity personality (beliefs, acquaintances, etc). This is often a design choice. This function can be hardly coded in the role behaviour and imposed to the entity which plays the role. Another possibility is to externalize and let each entity free to carry it out in the way it prefers. This depends obviously on the application and the level of generality the designer wants to give to the role.
Capacities are identified thanks to Role and interactions identification that define a first hierarchical structure of the system. Scenarios and role plan by defining the behaviour of the system allow a further refinement of it.
Capacities are described in a Class Diagram using stereotyped classes and they are related to the roles that require them through associations. A capacity contains at least a name identifying the element and the set of its inputs and outputs, which may have default values and are defined according to an ontology. Optional fields are: a set of logical constraints (named Required) on input values that define what should be verified to guarantee the expected result of the capacity; a set of logical constraints (named Ensured) on output fields describing what properties the capacity achieves if the required input is satisfied. Finally we add a textual description to informally describe the behaviour of the capacity. In our model the capacity can thus be described by using the template presented in figure 15 (inspired by  and ).
- Name: the name of the capacity
- Input: the declaration of inputs.
- Output: the declaration of outputs.
- Requires: Logical constraints* defined on inputs defined according to an ontology.
- Ensures: Logical constraints* defined on outputs defined according to an ontology.
- Textual Description: A textual description of the capacity
* By logical constraints we refer to pre/post conditions on operations and invariants on states.
|Figure 15: The general description of a capacity |
MAS Metamodel Elements
Define(AbstractCapacity), Relate(AbstractRole, AbstractCapacity), Relate(Organisation, AbstractCapacity).
Work to be done
This activity thus consists in identifying the generic part of the role behaviour and distinguishing it from all behaviours which could depend on the internal properties and data of the entity which will play the role. The work consists in refining the Interactions and Role Identification diagram by adding new abstract capacities and relating them to roles that require them.
An useful guideline for drawing the Capacity Identification diagram consists in identifying in each role which kind of information, knowledge, resource is manipulated by the role and not provided to the role by another one. The objective is to identify external role dependencies and to define one or more capacities for exploiting them. When capacities have been identified, a new iteration can begin to refine role behaviours and organisation description. Ontology also provides some good guidelines to identify capacities. Each role is associated to a set of actions that it can perform upon ontology concepts. In order to perform this action the role need the internal ability to do that or it requires a capacity that could provide it with the results. Obviously the decision is problem dependent and it is a choice that the designer could adopt according to his solution strategy.
Considering the previous example and specifically the Team Simulation Organisation, it is possible to note that, in this organisation the Strategy Selection role has to identify the best strategy for a given game situation. This choice can typically be implemented under various perspectives, even decomposed using a sub-level organisation. This can be extracted from the role behaviour by creating a specific capacity called ChooseStrategy. In the same way the Game Situation role is able to maintain the information related to state of the game (player and ball positions, score) and to check if game rules are respected. This behaviour thus requires the possibility to observe the game. This observation mechanism can be implemented in different ways and it always requires specific rights. A capacity can also been designed for this aspect. Figure 16 summarizes the different capacities identified in this organisation.
|Figure 16: Scenario of the Team Simulation Organisation |