The goal of the Organization Identification activity is to bind each requirement to a global behavior, embodied by an organization. Each requirement is then associated to an unique organization in charge of fulfilling it. As already said, an organization is defined by a set of 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. Organization and Role identifications are probably the two most important activities in our analysis process, because these two aspects are the basis of the whole methodological process and occur quite early in the workflow.


Starting from use cases presented in the DRD activity, different approaches could be used to cluster them and identify organizations. We advocate the use of a combination between a structural (or ontological) approach mainly based on the analysis of the problem structure described in the POD and a functional approach based on requirement clustering. Further details about that are provided below:


Structural/Ontological: structural analysis focuses on the identification of the system structure. It is mainly based on the association between use cases and related ontological concept. In structural organization identification, use cases that deal with the same ontological concepts are often put together in the same organization. This approach assumes that the same knowledge is probably shared or managed by the different members of the organization. The structure of the ontology itself can often constitute a good guideline to identify organizations, their composition relationships, and later roles.


Functional/Behavioral: The behavioral analysis aims at identifying a global behavior for the organization intended to fulfill the requirements described in the corresponding use case diagram. The set of organization roles and their interactions have to “generate” this higher-level behavior. For this task, the use of Organizational Design Patterns [1] may be useful to the designer. In behavioral organization identification, use cases dealing with related pieces of the system behavior are grouped (for instance an use case and another related to it by an include relationship). This means that members of the same organization share similar goals.


Contents

Goal

The goal of the Organization Identification activity is to identify for each requirement a global behavior, embodied by an organization able to fulfill it. Organization 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.


Input

Organization 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 if Organizational Design Pattern is also encouraged to favor re-usability and validate obtained solution.


Output

In the first iteration, the result of this activity is thus a set of organizations, each one associated with at least one use case. Each use case is associated with at most one organization. To describe these associations, we directly add organization in forms of package into the diagram, This kind of diagram is called Organizational Use Case Diagram. In following iterations, the result of this activity is a set of organizations that contributes to a part of the behavior of previously identified organizations. This aspect is described using constraints in a class diagram.


Work to be done

Organization Identification is based on the functional and behavioral 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 organization.


To help the designer and reuse well known solutions, the use of Organizational Design Patterns is particularly useful during this activity. An Organizational Design Pattern (ODP) constitutes a standard solution based on the organizational 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 organization 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 organization and (iii) its meta-description : the set of capacities to which it provides an implementation, the set of services that it provides, and the associated required conditions. An organization is considered as generic if the behavior of its roles is specified without making any assumptions on the architecture of the entities that may play them. Organizations may also be identified by using the behavioral decomposition of another organization during iterations. This decomposition may stop when the designer considers that the behavior of each role has a sufficiently fine granularity to be implemented. These successive decomposition can be done by looking at the structure of the ontology in order to find elements that suggest some hierarchical structure (see guidelines).


MAS Meta-Model Elements

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


Methodological Guidelines

To identify organizations 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 organization defined by the associated use case. In structural organizations identification, use cases that deal with the same ontological concepts are often put together in the same organization. This approach assumes that the same knowledge is probably shared or managed by the different members of the same organization. The association between organizational concept like organization and then role with concept of this ontology is a very important relation in our process. It often provides guidelines in many activities.
    The structure of the ontology itself can often constitute a good guideline to identify roles and organization. The principle consist in looking into the ontology in order to find elements that suggest some hierarchical structure like composition relationship. More details on this aspect are given in the following section.
  • Behavioral/Functional The behavioral analysis aims at identifying a global behavior for the organization intended to fulfill the use case(s). The set of future roles of the organization and their interactions have to be able to ”generate” this higher-level behavior. In this aspect the use of Organizational Design Pattern may be useful to the designer. In behavioral organizations identification, use cases dealing with related pieces of the system behavior are grouped (for instance an use case and another included in the first one). It means that members of the same organization share similar goals.


These two aspects also correspond to the two overlapping aspects of the notion of holon. These two different guidelines may be mixed together for identifying organizations. The complete approach consist in using in parallel the two previous approaches and comparing results to finally obtain a model being the compromise between a structure-oriented and a behavior-oriented model. These third approach is described as an holonic approach, because it merges the various points of view on the system.


Suggested notation

Organizations are represented in use cases and class diagrams by packages stereotyped by << organization >>.


References

[1] Agent Oriented Design Patterns: a Case Study
In AAMAS’04, pages 1496–1497. IEEE Computer Society. Washington, DC, USA, 2004.
This page was last modified on 1 August 2010, at 15:19. This page has been accessed 16,577 times.
Copyright 2010-2018 © IRTES Institute - UPR EA 7274 - Université de Technologie de Belfort-Montbéliard - Privacy policy