Overview

SODA (Societies in Open and Distributed Agent spaces) is an agent-oriented methodology for the analysis and design of agent-based systems. Recently a new and extended version of the methodology has been proposed, which takes into account both the Agents and Artifacts (#aea()) meta-model, and a mechanism to manage the complexity of system description. SODA is organised in two phases(see figure), each structured in two sub-phases: the Analysis phase, which is composed of the Requirements Analysis and the Analysis steps, and the Design phase, which is composed of the Architectural Design and the Detailed Design steps.

Since the original version of 2001, SODA has always focused on inter-agent issues, like the engineering of agents' societies and the environment for MASs. In addition, SODA introduces a layering principle as an effective tool for scaling with the system complexity: this tool is applied throughout the SODA Analysis & Design process. The layering principle consists of two mechanisms, zoom and projection: zoom makes it possible to pass from an abstract layer to another, while projection projects the entities of a layer into another. Zoom is the only mechanism relating layers to each other: more precisely, in-zooming the entities of a (more abstract) layer leads to a more detailed layer, while out-zooming the entities of a (more detailed) layer leads back to a more abstract layer.

Of course, not all the entities of a layer should be in-zoomed in another (more detailed) layer at the same time, since this could easily lead to mistakes; so, in order to preserve the internal consistency of each layer, the entities of the more abstract layer that are not in-zoomed are projected (i.e, made available) in the more detailed layer "as they are" by the projection mechanism (see Figure below).

In general, when working with SODA, the starting layer, called core layer, is labelled with "C" and is always complete - that is, contains all the entities required to fully describe a given abstract layer. Any other layer contains just i) the entities that have been possibly (in/out-) zoomed from another layer, as well as ii) the entities possibly projected "as they are" from other layers: so, in general, these layers are not necessarily complete - though of course they might be so, as in the case of layer C+2. In the figure below is reporte the meta-model of the layering principle.

The SODA meta-model

Requirements Analysis
The goal of Requirements Analysis is the characterisation of both the customers' requirements and the legacy systems with which the system should interact, as well as to highlight the relationships among requirements and legacy systems. Several abstract entities are introduced for requirement modelling: in particular, requirement and actor are used for modelling the customers' requirements and the requirement sources, respectively, while the external-environment notion is used as a container of the legacy-systems that represent the legacy resources of the environment.The relationships between requirements and legacy systems are then modelled in terms of suitable relation entities.

Analysis
The Analysis step expresses the abstract requirement representation in terms of more concrete entities such as tasks, functions and topologies. Tasks are activities requiring one or more competences, while functions are reactive activities aimed at supporting tasks. The relations highlighted in the previous step are now the starting point for the definition of dependencies (interactions, constraints, etc.) among the abstract entities. The structure of the environment is also modelled in terms of topologies, i.e. topological constraints over the environment. Topologies are often derived from legacy-systems and requirements, but also functions and tasks could induct some topological constraints.

Architectural Design
The main goal of this stage is to assign responsibilities of achieving tasks to roles, and responsibilities of providing functions to resources. To this end, roles should be able to perform actions, and resources should be able to execute operations providing one or more functions. The dependencies identified in the previous phase become here interactions and rules. Interactions represents the act of the interaction among roles, among resources and between roles and resources, while rules enable and bound the entities' behaviour. Finally, the topology constraints lead to the definition of space, i.e. conceptual places structuring the environment. The result of this step is conceptually the set of all the possible choices for the system design: more precisely, each complete layer represents one possible system design, while incomplete layers represent partial designs - i.e., zoomed sections of the system, usable in the Detailed Design step in conjunction with other layers.

Detailed Design
The goal of this step is to choose the most adequate representation level for each architectural entity, thus leading to depict one (detailed) design from the several potential alternatives outlined above. For the sake of concreteness, let us refer to Figure below (left), where we made the hypothesis that the Architectural Design phase outlined roles R1, R2 at the core layer C, roles R4, R5 and the projection of R2 at layer C+1, and roles R6, R7, R8 and R9 at layer C+2. Turning this conceptual view into a real design view means to choose one representation (i.e., zoom) level for each entity, starting from the core layer: so, for instance, we could decide to zoom only R1, keeping R2 at the basic (core) representation level. Moreover, we could choose to further in-zoom R4 as the set of (sub)roles R6,R7, while keeping R5 as is. The result can be graphically expressed by carving out the roles R1, R2, R4, R5, R6 and R7 from the Architectural Design view, as shown with the curbed line in Figure below (centre) . This "carving operation" represents the boundary between Architectural Design - expressed in terms of roles, services, resources and workspaces - and Detailed Design - expressed in terms of agents, agent societies, artifacts and artifact compositions. More precisely, agents are intended here autonomous entities able to play several roles, while a society can be seen as a  group of interacting agents and artifacts when its overall behaviour is essentially an autonomous, proactive one.

So, completing the Detailed Design step now amounts at mapping each un-zoomed role included in the carving onto an individual agent, and each in-zoomed role onto a suitable society of agents. In the case of our example (see Figure above (right)), role R1 is to be mapped onto an agent society (A1), while role R2 is to be mapped onto an individual agent (A2). Going further, the agent society A1 is composed of two entities, representing roles R4 and R5: again, the first is to be mapped onto an agent society (A4), since role R4 is in-zoomed in the carving, while R5 is to be mapped onto an individual agent (A5); the same process applies to A4, which turns out to be composed of agents A6 and A7, mapping roles R6 and R7, respectively. A similar approach is adopted for the environmental entities: the un-zoomed resources identified in the previous step are now mapped onto artifacts (intended as entities providing some services), while in-zoomed resource are mapped onto a suitable aggregation of artifacts. An aggregate can be seen as a group of interacting agents and artifacts when its overall behaviour is essentially a functional, reactive one. The workspaces take the form of an open set of artifacts and agents -- that is, artifacts can be dynamically added to or removed from workspaces, as well as agents can dynamically enter (join) or exit workspaces. As a result, workspaces make possible to define topologies to structure agents and artifacts organisation and interaction - including, in particular, scopes for event generation and perception. Finally the interactions defined in the previous step are here expressed by means of "uses", "manifests", "speaks to" and "links to" concepts.