Revenir à la page d'accueil
Plan du site   |   Plan d’accès   |   UTBM
  
Projets Européens
Réseaux d'Excellence
Projets Nationaux
Contrats Industriels
Projets thématiques
    ASPECS Methodology
       Introduction
       A quick overview of ASPECS
       System Requirements Analysis
          Domain Requirements Description
          Problem Ontology Description
          Organisation Identification
          Interactions and Role Identification
          Scenario Description
          Role Plan
          Capacity Identification
       Agent Society Design
       Implementation
       Deployment
       References
       Comparisons with existing Agent-Oriented Methodologies
Conférences
Séminaires
Accueil > Activités et projets > Projets thématiques > ASPECS Methodology > System Requirements Analysis > Organisation Identification
Organisation Identification

Organisation Identification

Goal

The goal of the Organisation Identification activity is to identify for each requirement a global behaviour, embodied by an organisation. Each requirement is so associated to an unique organisation (see figure 1) in charge of fulfilling it. An organisation is defined by a set of Abstract Roles, their Interactions and a common context. The associated context is defined according to a part of the Problem Ontology, described in the previous activity. Organisation and Role identification are two key activities and probably the two most difficult ones in our process, because these two aspects are the basis of the whole methodological process and occur quite early in the workflow.


Input

Organisations are identified by studying use cases and the structure of the ontology and the association between use cases and the associated concepts in the ontology. The use of Organisational Design Pattern is also encouraged to favour reusability and validate enhance the quality of the obtained solution.


Output

In the first iteration, the result of this activity is thus a set of organisations, each one associated with at least one use case. Each use case is associated with at most one organisation. To describe these associations, we directly add each organisation in forms of a package into the DRD use case diagram, this kind of diagram is called Organisational Use Case Diagram. In successive iterations, first level organisations can be decomposed in smaller ones in order to obtain an organisational hierarchy. The result of this work is a set of organisations that contribute to a part of the behaviour of previously identified (first level) organisations. This aspect is described using constraints in a class diagram. Organisations are represented in use cases and class diagrams by packages stereotyped by therefore organisations identification is usually done by adding packages to a copy of the previously designed use case description of the system. The output of this activity also includes an informal text document describing the associations among organisations and functional and non-functional requirements in form of a table.


Work to be done

The first task of this activity consists in identifying the parts of the systems that will be realized by using an agent-oriented approach and putting out of scope of the current design all the parts that will be implemented by other technologies (usually this part will be represented by actors in order to model their interactions with agents). Of course this is just a first attempt that can be refined in successive iterations. The next task consists in identifying organisations. Organisation Identification is based on the functional and behavioural decomposition of use cases. Starting from a detailed diagram of the system functionalities, we group one or more use cases into stereotyped packages so as to form a new diagram. In so doing, each package defines the objectives that have to be fulfilled by the organisation. To help the designer in reusing well known solutions, the use of Organisational Design Patterns [15] is particularly useful during this activity. An Organisational Design Pattern (ODP) constitutes a standard solution based on the organisational MAS paradigm to solve a set of recurrent problems. It provides a guide that should be adapted to the particular case of a given problem. This step requires a set of refinements of the ODP to obtain a classical organisation that is well suited to the studied problem. It contains at least :

(i) The description of the class of solved problems, and the associated set of fulfilled requirements.
(ii) A generic organisation and
(iii) its meta-description : the set of capacities to which it provides an implementation and the associated required conditions.

An organisation is considered generic if the behaviour of its roles is specified without making any assumptions on the architecture of the entities that may play them. Organisations may also be identified by adopting a behavioural decomposition of another organisation during further iterations. This decomposition may stop when the designer considers that organisation identification and their relationships to functionalities have a sufficiently fine granularity to be implemented.

Successive decompositions can also be done by looking at the structure of the ontology in order to find elements that suggest some hierarchical structure (see guidelines).

This process will finally generate a complete hierarchy of organisations where the global behaviour of an organisation O1 at level n will contribute to a part of the behaviour of a role R of an organisation O2 at level n + 1. This contribution is based on the relation between capacity and service, and will be detailed in the following (see sub-sections 4.7 and 5.5); shortly it can be said that organisation O1 provides a service that implements a capacity required by the role R (see figure 7).

Figure 7: Organisation Hierarchical Decomposition, Class Diagram

MAS Metamodel Elements

Define(Organisation), Quote(Functional Requirement), Quote(Non Functional Requirement), Relate(Organisation, Functional Requirement), Relate(Organisation, Non-Functional Requirement).


Methodological Guidelines

To identify organisations we propose to exploit the different points of view we can adopt on a system:

  • Structural: The structural analysis aims at identifying a structure of the system, i.e. how to decompose it into sub-elements. This analysis and the resulting structure depends on the objective of the organisation defined by the associated use case. In structural organisations identification, use cases that deal with the same ontological concepts are often put together in the same organisation. This approach assumes that the same knowledge is probably shared or managed by the different members of the organisation. The association between organisational concepts like organisation and role with concepts from the ontology is very important in our approach. It often provides guidelines in many activities. The structure of the ontology itself can often constitute a good guideline to identify organisations and later roles. The principle consists in looking into the ontology in order to find elements that suggest some hierarchical structure like a composition relationship. More details on this aspect are given in the following section.
  • Behavioural/Functional: The behavioural analysis aims at identifying a global behaviour for the organisation intended to fulfil the use case(s). The set of future roles of the organisation and their interactions have to be able to ”generate” this higher-level behaviour. In this aspect the use of Organisational Design Pattern may be useful to the designer. In behavioural organisations identification, use cases dealing with related pieces of the system behaviour are grouped (for instance an use case and another related to it by an include relationship). It means that members of the same organisation share similar goals.

These two different guidelines may also be mixed together while identifying organisations. An interesting way of obtaining a good organisation identification can consist in using the two previously discussed approaches in parallel and, after that, comparing results to finally obtain a model being the compromise between a structure-oriented and a behaviour-oriented model.


Example

From the use cases presented in the DRD activity different approaches could be used to group use cases and identify organisations. The first task consists in identifying which functionalities will be designed using an agent-oriented approach and which ones with a traditional object-oriented approach. In this example, we have decided to design functionalities of use case 2 with an OO approach (see figure 5). In this situation, we extract this use case from the agent-oriented part of the system, and we represent it as a new actor, called Tuning interface. The part of the system corresponding to this use case will be designed separately using a classical object-oriented software process like for instance RUP [51]. Concerning the other use cases, three possible partitions can be studied, each one corresponding to a different point of view on the system:

  • Functional approach: Three main functional areas are identified, and an organisation is associated to each one. Firstly the global system is itself associated to an organisation Game Simulation managing use case 1 (see Fig. 8). The behaviour simulation is associated to a second organisation called Team Simulation and in charge of use cases 3 and 5. And finally strategy determination is associated to an organisation called Strategy Decision grouping use cases 4,6,7 et 8. The result of the organisation identification with a such approach is described in figure 8.
  • Ontological approach: This partition is based on the hierarchical decomposition of the ontology. Uses cases referring to ontological concepts of the same level are grouped. At the top level of the hierarchy, an organisation named Game Simulation grouping use case 1 is defined and it is related to the highest concept in the ontology, Match. Then use cases 3 and 4, referring to Team and Strategy are assigned to a unique organisation and at the third level the organisation Player Simulation is introduced to deal with use cases 5,6,7 and 8, attached to sub-concepts of Player in the ontology. It is interesting to note that this approach introduced a nice hierarchy of organisations. This case is detailed in figure 9.
  • Multiview approach: The multiview approach consists in merging the various points of view we can have on the system (including the two previous ones). This approach respects the hierarchical nature of the system revealed by the ontological approach but it clearly separates use cases attached to different system functionalities. We have leaned for the last solution where granularity of functionalities and the different levels of abstraction present in the system are best respected. This case is detailed in figure 10.

Organisation identification using the functional approach
Figure 8: Organisation identification using the functional approach

Organisation identification using the ontological approach
Figure 9: Organisation identification using the ontological approach

Organisation identification using the multiview approach
Figure 10: Organisation identification using the multiview approach

  90010 Belfort cedex - Tél : +33 (0)3 84 58 33 19 - Fax : +33 (0)3 84 58 33 42 - Mentions légales