The scope of this phase is modeling the lifecycle of each agent, looking at the roles it can play, at the collaboration that it needs, and the communications in which it participates. The R.D. diagram is also where we introduce all the rules of the society (organizational rules), laws of the society and the domain in which the agent operates (e.g. trade laws) and the behavioral laws considered by Newell in his "social level". Although these rules could be expressed in plain text we prefer OCL in order to have a more precise, formal description.
The Role Description diagram for our scenario
The R.D. phase yields a collection of class diagram in which classes are used to represent roles. Agent is symbolized by a package containing roles' classes (see figure above). Each role is obtained composing several tasks in a resulting behaviour. This is the reason why we put tasks in the operation compartment of the related role's class. This makes clear what a role is able to and it can be helpful in the identification of reusable patterns. A R.D. diagram can also show connections between roles of the same agent, representing a changes of role (dashed line with the name [ROLE CHANGE]). This connection is depicted as a dependency relationship because we want to signify the dependency of the second role on the first. Sometime the trigger condition is not explicitly generated by the first role but its precedent appearance in the scenario justifies the consideration that it is necessary to prepare the situation that allows the second role to start. Conversations between roles are indicated by solid lines as we have done in the Communication Ontology Diagram of the previous phase, using exactly the same relationships names.
We have also considered dependencies between agents. Agents are autonomous, so they could refuse to provide a service or a resource. For this reason, the design needs a schema that expresses such matters so as to explore alternative ways to achieve the goals. In order to realize such a schema, we have introduced in Role Description diagram some additional relationships that express the following kinds of dependency:
In the example of the Figure, the dependency between the BooksProvider role and the Consultant role is named (softresource) as the BooksProvider would be happy to get an advice from the Consultant. But, if the Consultant somehow can not satisfy the query the BooksProvider will do without.
Next phase: Protocol Description
Previous phase: Ontology Description
Home: PASSI homepage