The main objective of the Capacity Identification activity (CI) is the definition of generic role behaviors by identifying which know-how a role requires from the individual that will play it. For the scope of this paper it is worth to say that the capacity is a description of what an organization (and therefore one of its composing roles) is able to do without any kind of specification on how to do it. It means that the results described 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 instance, if an entity’s personal acquaintances influence a particular choice
that is required in the role behavior, e.g. the choice of the best partner to fulfill 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 behavior and imposed to the entity
which plays the role. This depends obviously on the application and the level of generality the designer wants to give to the role. The final result of this activity is performing a revision of the already designed IRI diagram by adding
capacities (represented by classes) and relating them to the roles that require them.
Contents |
Goal
The main objective of the Capacity identification activity is the creation of generic role behaviors; The capacity constitute a layer between the role behavior and the future entities that who will want to play this role.
This activity thus consist in identifying the generic part of the role behavior and and to distinguish it from all behaviors which could depend on the internal properties and data of the entity which will play the role. For example if personal acquaintances of the entity will influence a particular choice that is required in the role behavior, i.e. choose the best partner to fulfill this task. This choice may be externalized as a capacity, because there will be necessary various ways of carrying it out and because it depends on data which are strictly personal with the entity (beliefs, acquaintances, etc). This is often a design choice, this function can be hardly coded in the role behavior and to impose on the entity which plays it to carry out it in the way described in the role. Or it may be externalized to let free each entity to carry out it in the way in which it wishes it. This depends obviously on the application and the level of generic the designer wants to give to the role.
Input
Capacities are identified thanks to Role and interactions identification that defines a first hierarchical structure of the system. Scenarios and role plan defining the behavior of the system allows to refine it.
Output
A capacity contains at least a name identifying the capacity 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 the input values that define what should be verified to guarantee the expected result of the capacity; a set of logical constraints on the output fields describe what properties (named Ensured) the capacity achieves if the required input is satisfied. Finally we add a textual description to informally describe the behavior of the capacity. In our model the capacity can thus be described using the template presented in Table 1.
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 a ontology. |
Ensures: Logical constraints* defined on outputs defined according to a ontology. |
Textual Description: A textual description of the capacity |
*By logical constraints we refer to pre/post conditions on operations and invariants on
states. |
MAS Meta-Model Elements
Define(AbstractCapacity), Relate(AbstractRole, AbstractCapacity), Relate(Organization, AbstractCapacity).
Methodological Guidelines
One of the objective of the capacity identification is to clearly separate role knowledge from the knowledge that will be associated to entities playing the role (by knowledge we refer to concepts in the ontology). If the role need to access to internal entity knowledge or to concepts different from ones with which it was previously associated, this often reveal the need of a capacity.
Moreover if the role deals with concept that are associated with actions in
the ontology. The relation between action and capacity is very strong. If the role
manipulates concepts through action defined in the ontology, this also reveal the
need of a capacity. Reciprocally if you have identify a capacity that requires some
knowledge, this probably signify that actions should be added in the corresponding
ontology.
A 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 it is 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 behaviors and organization description.
The ontology also provide good guidelines to identify capacities. Each role is
associated to a set of concept inside the ontology, this aspect has been used for
organization and role identification. This correspond to the knowledge manipulate
by the role. Actions and predicates defined on concepts belonging to this knowledge
often mean that the role should probably have a capacity equivalent to these
actions to access to its knowledge, especially if these data will be stored in the
entity which will play the role.
Suggested notations
Capacities are described in a Class Diagram using stereotyped class and they are related to the roles that require them through associations.