The Problem Domain meta-model includes elements (Figure 1) that are used to catch the problem requirements and perform their initial analysis: Requirements (both functional and non functional) are related to the organization that fulfills them. An organization is composed of Roles interacting within scenarios while executing their Role plans. An organization has a context that is described in terms of an ontology. Roles participate to the achievement of organization's goals by means of their Capacities. In this subsection we will discuss the three most important elements of this domain: organization, role, capacity. Table 1 presents the major Problem Domain concepts.
| Concept | Definition |
|---|---|
| Functional Requirement | A function that the software has to exhibit or the behaviour of the system in terms of interactions perceived by the user; see SWEBOK |
| Non-Functional Requirement | A constrainst on the solution. Non-functional requirements are sometimes known as constraints or quality requirements; see SWEBOK |
| Ontology | An explicit specification of a conceptualization of a knowledge domain. An ontology is composed of abstract ontology elements having three possible concrete types: Concept, Predicate or Action. |
| Concept | A category, an abstraction that shortens and summarizes a variety/multiplicity of objects by generalizing common identifiable properties. |
| Predicate | Assertions on concepts properties. |
| Action | A change realized by an entity that modifies one or more properties of one or more concepts. |
| Organization | An organization is defined by a collection of roles that take part in systematic institutionalized patterns of interactions with other roles in a common context. This context consists in shared knowledge and social rules/norms, social feelings, etc and is defined according to an ontology. The aim of an organization is to fulfill some requirements. |
| Role | An expected behavior (a set of role tasks ordered by a plan) and a set of rights and obligations in the organization context. The goal of each Role is to contribute to the fulfillment of (a part of) the requirements of the organization within which it is defined. A role can be instantiated either as a Common Role or Boundary Role. A Common Role is a role located inside the designed system and interacting with either Common or Boundary Roles. A Boundary Role is a role located at the boundary between the system and its outside and it is responsible for interactions happening at this border (i.e. GUI, Database, etc). |
| Interaction | A dynamic, not a priori known sequence of events (a specification of some occurrence that may potentially trigger effects on the system) exchanged among roles, or between roles and entities outside the agent system to be designed. Roles may react to the events according to theirs behaviors. |
| Capacity | A specification of a transformation of a part of the designed system or its environment. This transformation guarantees resulting properties if the system before the transformation satisfies a set of constraints. It may be considered as a specification of the pre- and post-conditions of a goal achievement. |
| Role Task | An activity that defines a part of a role behavior. A Role Task may be atomic or composed by a coordinated sequence of subordinate Role Tasks. The definition of these Role Tasks can be based on capacities, required by roles. |
| Role plan | The behavior of a Role is specified within a Role plan. It is the description of how to combine and order Role Tasks and interactions to fulfill a (part of a) requirement. |
| Scenario | Describes a sequence of role interactions which a (part of) requirement. |
An organization is defined by a collection of roles that take part in systematic institutionalized patterns of interactions with other roles in a common context. This context consists in shared knowledge and social rules/norms, social feelings, etc. and it is defined according to an ontology. The aim of an organization is to fulfill some requirements. An organization can be seen as a tool to decompose a system and it is structured as an aggregate of several disjoint partitions, each organization aggregates several roles and it may itself be decomposed into sub-organizations.
In our approach, a Role defines an expected behavior (a set of role tasks ordered by a plan) and a set of rights and obligations in the organization context. The goal of each Role is to contribute to the fulfillment of (a part of) the requirements of the organization within which it is defined. Just to exemplify the concepts of Organization and Role we can consider the example of the Project Management organization that is depicted in Figure 2 and composed of two roles: Manager and Participant, and two interactions.
In order to cope with the need of modeling system boundaries and system interactions with the external environment, we introduced two different types of roles: Common Role and Boundary Role. A Common Role is located inside the designed system and interacts with either Common or Boundary Roles. A Boundary Role is located at the boundary between the system and its outside and it is responsible for interactions happening at this border (i.e. GUI, Database wrappers, etc).
Roles use their capacities for participating to organizational goals fulfillment; a Capacity is a specification of a transformation of a part of the designed system or its environment. This transformation guarantees resulting properties if the system satisfies a set of constraints before the transformation. It may be considered as a specification of the pre- and post-conditions of a goal achievement. This concept is a high level abstraction that proved to be very useful for modeling a portion of the system capabilities without making any assumption about their implementations as it should be at the initial analysis stage.
A Capacity describes what a behavior is able to do or what a behavior may require to be defined. As a consequence, there are two main ways of using this concept:
- it can specify the result of some role interactions, and consequently the results that an organization as a whole may achieve with its behavior. In this sense, it is possible to say that an organization may exhibit a capacity.
- Capacities may also be used to decompose complex role behaviors by abstracting and externalizing a part of their tasks into capacities (for instance by delegating these tasks to other roles). In this case the capacity may be considered as a behavioral building block that increases modularity and re-usability.
To better illustrate this dual aspect of the concept of capacity, let’s consider an example: the capacity to find the shortest path in a weighted directed acyclic graph (N,E), from a s source node to a d destination node.
This capacity may be realized in various ways. Dijkstra [4] or Bellman-Ford [2] algorithms may be used if we consider the know-how of a single entity. Besides other realizations may be found, especially if we consider the know-how of a group of entities modeled by an organization. The Ant Colony is a well-known organization able to find a solution to the problem of finding the shortest path in a graph [1]. The solution (the shortest path) emerges from interactions among Ants in their environment. Let us suppose the environment represent the graph, the s source node is mapped to the ant hill and the d destination to a food source. Figure 3 represents the design of a portion of a system composed of several levels of abstractions. In the example we are concerned with level n + 1 where the RouteChoice organization is responsible for providing the best choice to another organization not represented in the diagram (for instance the Motion Control organization responsible to control the movement of a robot). The request of finding the route is done by the Route Requester role (possibly played by a member of the Motion Control organization) responsible to obtain the required information. The route is chosen by the Route Provider role that is, indeed, not able to do that by itself, it requires the implementation of the FindShortestPath capacity that actually provides the result. This capacity solves a problem that is located at a lower level of abstraction (level n). Figure 3 proposes one possible implementation of the capacity realized by means of an ant colony in the Ant Colony organization that is located at a lower level in the organizational hierarchy. The capacity concept thus allows to define how an organization at level n may contribute to the behavior of a role at level n + 1.
In order to complete the description of the possibilities offered by the application of our definitions of Organization, Roles and Capacity, we would like to highlight the duality that is inherent the concept of organization: an organization is either the medium (support) and the way to satisfy a goal/need, it may be considered as the description of an overall behavior. Let us consider the need of modeling a complex system behavior. We assume it is possible to decompose it from a functional point of view, and in this way we obtain a set of more finer grained (less complex) behaviors. Depending on the considered level of abstraction, an organization can be seen either as a unitary behavior or as a set of interacting behaviors. The concept of organization is inherently a recursive one [5]. The same duality is also present in the concept of holon as it will be shown later in this article. Both are often illustrated by the same analogy: the composition of the human body. The human body, from a certain point of view, can be seen as a single entity with an identity, its own behavior and personal emotions. Besides, it may also be regarded as a cluster/aggregate of organs, which are themselves made up of cells, and so on. At each level of this composition hierarchy, specific behaviors emerge [3]. The body has an identity and a behavior that is unique for each individual. Each organ has a specific mission: filtration for kidneys, extraction of oxygen for lungs or blood circulation for the heart. An organization is either an aggregation of interacting behaviors, and a single behavior composing an organization at an upper level of abstraction; the resulting whole constitutes a hierarchy of behaviors that has specific goals to be met at each level. This recursive definition of organization will form the basis of the analysis activities performed within ASPECS. The system global behavior is recursively decomposed into a set of interacting sub-behaviors, each of these latter being in turn decomposed until we reach some lowest level of elementary sub-behaviors. At a given level, composed behaviors are modeled by using organizations (that being collection of roles exhibit their composed behavior), and the associated elementary sub-behaviors using roles. In most systems, it is somewhat arbitrary as to where we leave off the partitioning and what subsystems we take as elementary (cf. [6]). This choice remains a pure design choice.
References
- [1] A Running Time Analysis of an Ant Colony Optimization Algorithm for Shortest Paths in Directed Acyclic Graphs
- N. Attiratanasunthron, J. Fakcharoenphol.
Inf. Process. Lett., 105(3):88–92, 2008.
- [2] On a Routing Problem
- R. Bellman.
Quarterly of Applied Mathematics, 16(1):87–90, 1958.
- [3] La vie dans la nature
- G. Chauvet.
Flammarion, 1998.
- [4] A Note on Two Problems in Connexion with Graphs
- E. Dijkstra.
Numerische Mathematik, 1(1):269–271, December, 1959.
- [5] Multi-Agent Systems. an Introduction to Distributed Artificial Intelligence
- J. Ferber.
Addison Wesley, London, 1999.
- [6] The Science of Artificial
- H. Simon.
MIT Press, Cambridge, Massachusetts, 3rd edition, 1996.
