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.


Table 1: The general description of a capacity

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.

This page was last modified on 1 August 2010, at 15:26. This page has been accessed 13,698 times.
Copyright 2010-2018 © IRTES Institute - UPR EA 7274 - Université de Technologie de Belfort-Montbéliard - Privacy policy