The SODA Methodology: Meta-model and Process Documentation

Abstract

The SODA methodology deals with MAS analysis and design, and focuses on critical issues such as agent coordination and MAS-environment interaction. After its first formulation, in order to further meet the needs of complex MAS engineering, SODA was extended to embody both the layering principle and the Agents & Artifacts (A&A) meta-model. As a result, both the SODA meta-model and the SODA process were re-defined, also to include two new phases—Requirement Analysis and Architectural Design. This chapter is then devoted to the documentation of the complete SODA process according to the FIPA standard.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

SODA (Societies in Open and Distributed Agent spaces) [13] is an agent-oriented methodology for the analysis and design of agent-based systems, which adopts the Agents & Artifacts (A&A) meta-model [10], and introduces a layering principle as an effective tool for scaling with system complexity, applied throughout the analysis and design process [2, 3, 9]. Since its first version [9], SODA is not concerned with intra-agent issues: designing a multi-agent system (MAS) with SODA amounts at defining agents in terms of their required observable behaviour as well as their role in the MAS. Then, whichever methodology one may choose to define the structure and inner functionality of individual agents, it could be used in conjunction with SODA. Instead, SODA focus on inter-agent issues, like the engineering of agent societies and MAS environment.

When designing a new system in SODA, three things are to be understood: which activities have to be performed, which functions are available and required, and how activities and functions relate to each other. Accordingly, SODA abstractions are logically divided into three categories: (1) the abstractions for modelling/designing the system’s active part (task, role, agent, etc.); (2) those for the reactive part (function, resource, artifact, etc.); and (3) those for interaction and organisational rules (relation, dependency, interaction, rule, etc.).

Fig. 1

An overview of the SODA process

The SODA process is organised in two phases, each structured in two sub-phases: the Analysis phase, including the Requirements Analysis and the Analysis steps, and the Design phase, including the Architectural Design and the Detailed Design steps. Each sub-phase models the system through a subset of the SODA abstractions: in particular, each subset always includes at least one abstraction for each of the above categories—that is, at least one abstraction for the system’s active part, one for the reactive part, one for interaction and organisational rules.

Figure 1 overviews the methodology by describing each step in terms of a set of relational tables. In the remainder of this chapter, the SODA process is described first as a whole process then through its four steps, following the FIPA standard [1].

Useful references about the SODA methodology and process are the following:

• A. Omicini. SODA:Societies and Infrastructures in the Analysis and Design of Agent-based Systems [9].

• A. Molesini, A. Omicini, A. Ricci, E. Denti. Zooming Multi-Agent Systems [3].

• A. Molesini, A. Omicini, E. Denti, A. Ricci. SODA:A Roadmap to Artefacts [2].

• A. Molesini, E. Denti, A. Omicini. Agent-based Conference Management: A Case Study in SODA [6].

• A. Molesini, E. Nardini, E. Denti, A. Omicini. Advancing Object-Oriented Standards Toward Agent-Oriented Methodologies: SPEM 2.0 on SODA [4].

• A. Molesini, E. Nardini, E. Denti, A. Omicini. Situated Process Engineering for Integrating Processes from Methodologies to Infrastructures [5].

• A. Molesini, A. Omicini. Documenting SODA:An Evaluation of the Process Documentation Template [7].

Fig. 2

Phases of the SODA process

1.1 Process Life Cycle

SODA includes two phases, each structured in two sub-phases: the Analysis phase, which includes the Requirements Analysis and the Analysis steps, and the Design phase, which includes the Architectural Design and the Detailed Design steps. SODA phases and steps are arranged according to an iterative process model (see Fig. 2):

Requirements Analysis :

covers all the phases related to actor identification, requirements elicitation and analysis, and analysis of the existing environment.

Analysis :

investigates all the aspects related to the problem domain trying to understand the tasks satisfying the requirements, their connected functions, the environment topology and all the dependencies among these entities.

Architectural Design :

defines a set of admissible architectures for the final system.

Detailed Design :

determines the best system architecture and designs the environment and the system interactions.

Each step in SODA produces several sets of relational tables, each describing a specific MAS Meta-model Element (MMMElement) and its relationships with other MMMElements. The details of each step will be discussed in the following section.

1.2 Meta-model

Fig. 3

The SODA meta-model

The meta-model adopted by SODA is represented in Fig. 3, where SODA abstract entities are depicted along with their mutual relations, and distributed according to the four SODA steps: Requirements Analysis, Analysis, Architectural Design and Detailed Design.

1.2.1 Requirements Analysis

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 notion of External Environment 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 Relation entities.

1.2.2 Analysis

The Analysis step expresses the abstract requirement representation in terms of more concrete entities such as Tasks and Functions. 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, that is, topological constraints over the environment. Topologies are often derived from functions, but can also constrain/affect task achievement.

1.2.3 Architectural Design

The main goal of this stage is to assign responsibilities to achieve tasks to Roles, and responsibilities to provide 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 represent the acts of the interaction among roles, among resources and between roles and resources; rules, instead, enable and bound the entities’ behaviour. Finally, the topology constraints lead to the definition of Spaces, that is, conceptual places structuring the environment.

1.2.4 Detailed Design

The active and passive parts are expressed in the Detailed Design in terms of individual entities (Agents and Artifacts) as well as of composite entities, such Societies and Aggregates. Agents are intended here as autonomous entities able to play several roles, whereas the resources identified in the previous step are now mapped onto suitable artifacts.

Artifacts have “types” according to the following taxonomy [11]:

• An individual artifact handles the interaction of a single agent within a MAS and essentially works as a mediator between the agent and the MAS itself. Since they can be used to shape admissible interactions of individual agents in MAS, individual artifacts play an essential role in engineering both organisational and security concerns in MAS.

• An environmental artifact brings an external resource within a MAS by mediating agent actions and perceptions over resources. As such, environmental artifacts play an essential role in enabling, disciplining and governing the interaction between agents and MAS environment.

• A social artifact rules social interactions within a MAS by mediating interactions between individual, environmental and possibly other social artifacts. Social artifacts in SODA play the role of the coordination artifacts that embody the rules around which societies of agents can be built.

Interactions between agents and artifacts in SODA take the form of Use (agent to artifact), Manifest (artifact to agent), SpeakTo (agent to agent) and LinkedTo (artifact to artifact).

In SODA, a group of individual entities can be abstracted away as a single composite entity. In particular, a group of interacting agents and artifacts can be seen as a SODA Society when its overall behaviour is essentially an autonomous, proactive one; it can be seen as a SODA Aggregate, instead, when its overall behaviour is essentially a functional, reactive one. Finally, SODA Workspaces take the form of an open set of artifacts and agents: artifacts can be dynamically added to or removed from workspaces, and agents can dynamically enter (join) or exit workspaces (Table 1).

Table 1 The SODA entities definitions

1.3 Guidelines and Techniques

SODA exploits a technique called Layering that can be applied to the overall process before the Detailed Design step. In SODA, during the Analysis phase and the Architectural Design step, the system is described in principle by all the layers defined, and could then be modelled by a number of different—although related—design views. This of course does not hold for the Detailed Design step since the developer should be provided with a single system representation among all the potentially admissible ones based on the Architectural Design layers.

Accordingly, the next section presents the SODA Layering technique.

1.3.1 Layering

Complexity is inherent in real-life systems. While modelling complex systems and understanding their behaviour and dynamics is the most relevant concern in many areas, such as economics, biology or social sciences, also the complexity of construction becomes an interesting challenge in artificial systems like software ones. An integral part of a system development methodology must therefore be devoted to controlling and managing complexity.

To this end, SODA introduces Layering, a conceptual tool to deal with the complexity of system representation. Using Layering, a system in SODA can be represented as composed by different layers of abstraction, with a layering operation to conceptually move between them.

Layering can be represented as a capability pattern [8]—that is, a reusable portion of the process, as shown in Fig. 4, where the layering process is detailed. In particular, the layering process has two activities: (1) the selection of a specific layer for refining/completing the abstractions models in the methodology process (Select Layer activity), and (2) the creation of a new layer in the system by in-zooming—that is, increasing the system detail—or out-zooming—that is, increasing the system abstraction—activities. In the last case, the layering process ends with the projection activity where the abstractions are projected “as they are” from one layer to another so as to maintain the consistency in each layer.

Fig. 4

The layering process

In general, when working with SODA, the reference layer, called core layer, is labelled with C, and is by definition complete—that is, it contains all the entities required to fully describe a given abstract layer. Any other layer—labelled with either C + i, for more detailed layers, where i is the number of in-zoom steps from the C layer, or C − i, for more abstract layers, where i is the number of out-zoom steps from the C layer—contains just the entities (in/out-) zoomed from another layer, along with the entities projected “as they are” from other layers. So, in general, the other (non-core) layers are not required to be complete—though of course they might be so, as in the case of layer C + 1 in Fig. 5. The projected entities are identified by means the prefix “+” if they are projected from a more abstract layer to a more detailed layer (see entity E2 in Fig. 5), with “−” otherwise—see entity E1 in Fig. 5.

Fig. 5

An example of layering

Figure 6 depicts a more detailed view of the Layering capability pattern showing the flow of activities, the process roles involved and the input and work products of each activity.

Fig. 6

The layering flow of activities, roles and work products

1.3.2 Process Roles

One role is involved in the Layering pattern: the Layering Expert. Layering Expert is responsible for

• Selecting the specific abstraction layer

• Either in-zooming or out-zooming the system by creating the specific Zooming table or modifying an existing Zooming table

• Projecting the necessary entities in the new created layer

• Partially filling all the newly created SODA tables

1.3.3 Activity Details

1.3.3.1 In-Zoom Activity

The flow of tasks inside in-zoom activity is reported in Fig. 7; the tasks are detailed in the following table.

Table 2

Fig. 7

The task in the in-zoom activity

Fig. 8

The task in the out-zoom activity

1.3.3.2 Out-Zoom Activity

The flow of tasks inside out-zoom activity is reported in Fig. 8; the tasks are detailed in the following table.

Table 3

1.3.3.3 Select Layer Activity

The flow of tasks inside Select Layer activity is reported in Fig. 9; the tasks are detailed in the following table.

Activity	Task	Task description	Role involved
Select Layer	Select Layer	Allowing the selection of a specific layer in order to either redefine or complete it	Layering Expert (perform)

Fig. 9

The task in the select layer activity

Fig. 10

The task in the projection activity

1.3.3.4 Projection Activity

The flow of tasks Projection activity this activity is reported in Fig. 10; the tasks are detailed in the following table.

Activity	Task	Task description	Role involved
Projection	Projection	Allowing the projection of a non-zoomed entity from a layer to another in order to preserve the layer consistency	Layering Expert (perform)

1.3.4 Work Products

Layering generates one work product: the Zooming table. Its relationships with the MMMElements are described in Fig. 11.

Fig. 11

The layering work products

This diagram represents the Layering in terms of the Work Product and its relationships with the SODA meta-model (Sect. 1.2) elements. Each MMMElement is represented using an UML class icon (yellow) and, in the documents, such elements can be Defined, reFined, Quoted, Related or Relationship Quoted as defined in [12] and briefly reported in the following:

• Defined (D label)—this means that the element is introduced for the first time in the design in this artifact (the MMMElement is instantiated in this artifact)

• reFined (F label)—this means that the MMMElement is refined in the work product (for instance by means of attribute definition)

• Related (R label)—this means that an already defined element is related to another, or, from a different point of view, that one of the MAS meta-model relationships is instantiated in the document

• Quoted (Q label)—this means that the element was already defined, and it is reported in this artifact only to complete its structure, but no work has to be done on it

• Relationship Quoted (RQ label)—this means that the relationship is reported in the work product, but it was defined in another part of the process

1.3.4.1 Kinds of Work Products

Layering is represented by means of a Zooming table ((C)Z _t )—see Fig. 12. The Zooming table formalises the in-zoom of a layer into the more detailed layer; of course, the same table can be used to represent the dual out-zoom process. One column of the table contains the name of the abstraction at layer C, while the other column reports the name of the corresponding zoomed abstractions at the subsequent layer C + 1 (in-zooming) or C − 1 (out-zooming).

In general when in-zooming an entity from layer C to layer C + 1, we obtain a new group of entities, but also a set of relationships among these new entities that allow the entities’ coordination as shown in Fig. 5.

Fig. 12

(L)Z _t

1.3.4.2 Examples of Work Products

Figures 13, 14, and 15 report the Zooming tables modelling the example proposed in Fig. 5. In particular, Fig. 13 shows the relationships between layer C—the core layer—and layer C + 1, where entity E1 is in-zoomed into E4 and E5, and E3 is in-zoomed into E10 and E11. The E2 entity and r1 relationship are projected from C to C + 1: this is reported in the in-zoom table of E1, since the relation between E1 and E2 in layer C has to be maintained also in layer C + 1 in order to maintain consistency. In addition, two new relationships are necessary after the in-zoom operation: r2 comes from the in-zooming of E1 in order to coordinate the E4 and E5; in a similar way r5 comes from the in-zooming of E3.

Fig. 13

(C)Z _t

Figure 14 reports the relation between layer C − 1 and layer C. Here there is an out-zoom operation, E2 and E3 are collapsed in E0, while E1 and r1 are projected for consistency reason.

Fig. 14

(C − 1)Z _t

Finally, Fig. 15 depicts the relation between layer C + 1 and layer C + 2 where E4 is in-zoomed in E6, E7 and r3; E5 is in-zoomed in E8, E9 and r4; and E2, r1 and r2 are projected.

Fig. 15

(C + 1)Z _t

2 Phases of the SODA Process

2.1 The Requirements Analysis

The goals of Requirements Analysis are (1) characterising both the customers’ requirements and the legacy systems with which the system should interact, as well as (2) highlighting the relationships among requirements and legacy systems. Requirements can be categorised in [14]:

• Functional Requirements—statements about which functionalities the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

• Non-Functional Requirements—constraints on the services and functions offered by the system such as timing constraints, constraints on the development process, standards, security, privacy, etc. Non-functional requirements could be more critical than functional requirements. If these are not met, the system is useless.

• Domain Requirement—requirements that come from the application domain of the system, and that reflect features of that domain. Domain requirements could be new functional requirements, constraints on existing requirements or define specific computations. If domain requirements are not satisfied, the system may be unworkable.

In this step, we take into account several abstract entities to model the system’s requirements: actors, requirements, external environment, legacy systems and relations. The Requirements Analysis involves three different process roles, and eight work products, as described in Fig. 16. Figure 17 presents the Requirements Analysis process composed by three main activities—Requirements Modelling, Environment Modelling, and Relations Modelling—and several different layering activities—see Sect. 1.3.1.

Fig. 16

The requirements analysis flow of activities, roles and work products

Fig. 17

The requirements analysis process

2.1.1 Process Roles

Three roles are involved in the Requirements Analysis: the Requirement Analyst, the Environment Analyst and the Domain Analyst.

2.1.1.1 Requirement Analyst

The Requirement Analyst is responsible for

• The identification of the main actors and system stakeholders

• The identification of the system functional and non-functional requirements

• The analysis of the system’s requirements

• The identification of the any kinds of relationship among requirements, and between requirements and legacy systems

2.1.1.2 Environment Analyst

The Environment Analyst is responsible for

• The identification of the legacy systems already present in the environment

• The analysis of the legacy systems

In addition, the Environment Analyst should help the Requirement Analyst in identification of the any kinds of relationship between requirements and legacy systems.

2.1.1.3 Domain Expert

The Domain Expert supports the Requirement Analyst and the Environment Analyst during the description of the application domain.

2.1.2 Activity Details

For the details about the different Layering activities please refer to Sect. 1.3.1.

2.1.2.1 Requirements Modelling Activity

The Requirements Modelling activity is composed of the following tasks:

Activity	Task	Task description	Role involved
Requirements Modelling	Actors Description	Identification of the actors and their description	Requirement Analyst (perform) Domain Expert (assist)
Requirements Modelling	Requirements Description	Identification of the requirements and their description	Requirement Analyst (perform) Domain Expert (assist)

The flow of tasks inside the Requirements Modelling activity is reported in Fig. 18.

Fig. 18

The flow of tasks in the requirements modelling activity

Fig. 19

The flow of tasks in the environment modelling activity

2.1.2.2 Environment Modelling Activity

The Environment Modelling activity is composed of the following tasks:

Activity	Task	Task description	Role involved
Environment Modelling	Legacy Systems Description	Identification of the legacy systems and their description	Environment Analyst (perform) Domain Expert (assist)

The flow of tasks inside the Environment Modelling activity is reported in Fig. 19.

2.1.2.3 Relations Modelling Activity

The Relations Modelling activity is composed by the following tasks:

Activity	Task	Task Description	Role Involved
Relations Modelling	Relations Description	Identification of the relations and their description	Environment Analyst (perform) Domain Expert (assist) Environment Analyst (assist)

The flow of tasks inside the Relations Modelling activity is reported in Fig. 20.

Fig. 20

The flow of tasks in the relations modelling activity

2.1.3 Work Products

The Requirements Analysis step consists of three sets of tables: Requirements Tables, Domain Tables and Relations Tables. Figure 21 reports the relationships among the work products of this step and the MMMElements of the Requirements Analysis. In Fig. 21, the relationships among the Zooming table and the MMMElements of the Requirements Analysis are also reported—see Sect. 1.3.1 for details.

2.1.3.1 Kinds of Work Products

Table 2 describes all the work products of the Requirements Analysis. In particular, the first entry (Requirements Specification) represents the input of the all SODA process, the second set is the outcome of the Requirement Modelling activity, the third set is the outcome of the Environment Modelling activity and the last set is the outcome of the Relation Modelling activity.

Fig. 21

The requirement analysis work products

Table 2 Requirements Analysis work products kinds

Fig. 22

Requirement table (C)Re _t

Fig. 23

Legacy System table (C)LS _t

2.1.3.2 Requirements Tables

Figure 22 provides an example of the Requirements Tables for the conference management case study [6].

2.1.3.3 Domain Tables

In the conference management system case study, there is only one Legacy System, called “WebServer”, which represents the container for the web application of the conference: the reason to include it in the description is that the conference management system will obviously interact with it, and such an interaction should be captured and constrained. Figure 23 presents Legacy System table where the WebServer system is described.

In our system, there is just one relation, called “Web”, which involves all the abstract entities since all requirements need to access the web server to retrieve or store information.

2.1.3.4 Relations Tables

An example of the Relations Tables in illustrated in Fig. 24.

Fig. 24

Relation table (C)Rel _t

2.1.3.5 Requirements Tables at Layer C + 1

In Figs. 25 and 26, we report some examples of the SODA tables modelling the conference management systems at layer C + 1.

Fig. 25

Zooming table ((C)Z _t): paper partitioning in-zoom

Fig. 26

Requirement table (C + 1)Re _t

2.2 The Analysis

In the Analysis step, SODA takes into account four abstract entities to analyse the system: tasks, functions, dependencies and topologies. Figure 27 presents the Analysis process, while Fig. 28 presents the flow of activities, the roles involved and the work products.

Fig. 27

The analysis process

Fig. 28

The analysis flow of activities, roles and work products

2.2.1 Process Roles

One role is involved in the Analysis step: the System Analyst.

2.2.1.1 System Analyst

The System Analyst is responsible for

• Mapping the MMMElements of the Requirements Analysis to the MMMElements of the Analysis

• Identifying new tasks coming from system analysis and description of the all tasks (new tasks and tasks coming from the mapping)

• Identifying new functions coming from system analysis and description of the all functions (new tasks and tasks coming from the mapping)

• Identifying new dependencies coming from system analysis and description of the all dependencies (new dependencies and dependencies coming from the mapping)

• Identifying new topologies coming from system analysis and description of the all topologies (new topologies and topologies coming from the mapping)

2.2.2 Activity Details

For the details about the different Layering activities, please refer to Sect. 1.3.1.

2.2.2.1 Moving from Requirements Activity

The Moving from Requirements activity is composed of the following tasks:

Activity	Task	Task description	Role involved
Moving from Requirements	Map Requirements-Analysis	Mapping of the MMMElements defined in Requirements Analysis to the Analysis MMMElements	System Analyst (perform)

The flow of tasks inside the Moving from Requirements activity is reported in Fig. 29.

Fig. 29

The flow of tasks in the moving from requirements activity

Fig. 30

The flow of tasks in the task analysis activity

2.2.2.2 Task Analysis Activity

The Task Analysis activity is composed of the following tasks:

Activity	Task	Task description	Role involved
Task Analysis	Task Description	Identification of the tasks and their description	System Analyst (perform)

The flow of tasks inside the Task Analysis activity is reported in Fig. 30.

2.2.2.3 Function Analysis Activity

The flow of tasks inside this activity is reported in Fig. 31; the tasks are detailed in the following table.

Fig. 31

The flow of tasks in the function analysis activity

Activity	Task	Task description	Role involved
Function Analysis	Function Description	Identification of the functions and their description	System Analyst (perform)

Fig. 32

The flow of tasks in the dependency analysis activity

Fig. 33

The flow of tasks in the topology analysis activity

2.2.2.4 Dependency Analysis Activity

The flow of tasks inside this activity is reported in Fig. 32, and the tasks are detailed in the following table.

Activity	Task	Task description	Role involved
Dependency Analysis	Dependency Description	Identification of the system dependencies and their description. Identification of relations with tasks, functions and topology	System Analyst (perform)

2.2.2.5 Topology Analysis Activity

The flow of tasks inside this activity is reported in Fig. 33; the tasks are detailed in the following table.

Activity	Task	Task description	Role involved
Topology Analysis	Topology Description	Identification of the topological constraints and their description. Identification of relations with tasks and functions	System Analyst (perform)

2.2.3 Work Products

The Analysis step exploits four sets of tables: Reference Tables, Responsibilities Tables, Dependencies Tables and Topologies Tables. Figure 34 reports the relationships among the work products of this step and the MMMElements of the Analysis. In Fig. 34 are also reported the relationships among the Zooming table and the MMMElements of the Analysis—see Sect. 1.3.1 for details.

Fig. 34

The analysis work products

Table 3 Requirements Analysis work products kinds

2.2.3.1 Kinds of Work Products

Table 3 describes all the work products of the Analysis. In particular, the first set of work products is the outcome of the Moving from Requirements activity, the second set is the outcome of the Task Analysis and Function Analysis activities, the third is the outcome of the Topology Analysis activity and the last set is the outcome of the Dependency Analysis activity.

2.2.3.2 References Tables

Figure 35 represents an example of the References Tables for the conference management case study.

Fig. 35

Reference Requirement-Task table (C)RRT _t

2.2.3.3 Responsibilities Tables

Figure 36 represents an example of the Responsibilities Tables for the conference management case study.

Fig. 36

Task table (C)T _t

Figure 37 represents an example of the Topologies Tables for the conference management case study.

Fig. 37

Topology table (C)Top _t

2.2.3.4 Dependencies Tables

Figure 38 represents an example of the Dependencies Tables for the conference management case study.

Fig. 38

Dependency table (C)D _t

2.2.3.5 Responsibilities Tables at Layer C + 1

Figures 39 and 40 report some examples of the SODA tables modelling the conference management systems at layer C + 1.

Fig. 39

Zooming table (C)Z _t

Fig. 40

Task table (C + 1)T _t

2.3 The Architectural Design

In this step, we take into account several abstract entities in order to design the system’s general architecture: role, resource, action, operation, interaction, environment and place. Figure 41 presents the Architectural Design process, while Fig. 42 presents the flow of activities, the involved roles and the work products.

Fig. 41

The architectural design process

Fig. 42

The architectural design flow of activities, roles, and work products

2.3.1 Process Roles

One role is involved in the Architectural Design: the Architectural Designer.

2.3.1.1 Architectural Designer

The Architectural Designer is responsible for

• Mapping the MMMElements of the Analysis to the MMMElements of the Architectural Design

• Assigning tasks to roles

• Assigning functions to resources

• Identifying new actions coming from system design and describing all the actions (new actions and actions coming from the mapping)

• Identifying operations coming from system design and describing all the operations (new operations and operations coming from the mapping)

• Identifying new interactions coming from system design and describing all the interactions (new interactions and interactions coming from the mapping)

• Identifying new rules coming from system design and describing all the rules (new rules and rules coming from the mapping)

• Identifying new spaces coming from system design and describing all the spaces (new spaces and spaces coming from the mapping)

2.3.2 Activity Details

For the details about the different Layering activities, please refer to Sect. 1.3.1.

2.3.2.1 Transition Activity

The Transition activity is composed of the following tasks:

Activity	Task	Task description	Role involved
Transition	Map Analysis- ArchDes	Mapping of the MMMElements defined in Analysis to the Architectural Design MMMElements so as to generate the initial version of the Architectural Design models	Architectural Designer (perform)

The flow of tasks inside the Transition activity is reported in Fig. 43.

Fig. 43

The flow of tasks in the transition activity

2.3.2.2 Role Design Activity

The Role Design activity is composed by the following tasks:

Activity	Task	Task Description	Role Involved
Role Design	Action Design	Assignment of tasks to roles and identification of the actions necessary in order to achieve each specific task	Architectural Designer (perform)

The flow of tasks inside the Role Design activity is reported in Fig. 44.

Fig. 44

The flow of tasks in the role design activity

Fig. 45

The flow of tasks in the resource design activity

2.3.2.3 Resource Design activity

The Resource Design activity is composed by the following tasks:

Activity	Task	Task Description	Role Involved
Operation Design	Resource Design	Assignment of functions to resources and identification of the operations necessary for providing each specific function	Architectural Designer (perform)

The flow of tasks inside the Resource Design activity is reported in Fig. 45.

2.3.2.4 Constraint Design Activity

The Constraint Design activity is composed by the following tasks:

Activity	Task	Task Description	Role Involved
Constraint Design	Constraint Design	Identification of the rules that enable and bound the entities’ behaviour starting from the dependencies analysed in the previous step	Architectural Designer (perform)

The flow of tasks inside the Constraint Design activity is reported in Fig. 46.

2.3.2.5 Interaction Design Activity

The Interaction Design activity is composed by the following tasks:

Activity	Task	Task Description	Role Involved
Interaction Design	Interaction Design	Identification of the interactions hat represent the acts of the interaction among roles, among resources and between roles and resources starting from the dependencies analysed in the previous step	Architectural Designer (perform)

The flow of tasks inside the Interaction Design activity is reported in Fig. 47.

2.3.2.6 Space Design Activity

The Space Design activity is composed by the following tasks:+

Activity	Task	Task Description	Role Involved
Space Design	Space Design	Identification of the spaces starting from the topology constraints analysed in the previous step	Architectural Designer (perform)

The flow of tasks inside the Space Design activity is reported in Fig. 48.

2.3.3 Work Products

The Architectural Design step consists of five sets of tables: Transition Tables, Entities Tables, Interactions Tables, Constraints Tables and Topological Tables. Figure 49 reports the relationships among the work products of this step and the MMMElements of the Architectural Design step. In Fig. 49 are also reported the relationships among the Zooming table and the MMMElements of the Architectural Design—see Sect. 1.3.1 for details.

Fig. 46

The flow of tasks in the constraint design activity

2.3.3.1 Kinds of Work Products

Table 4 describes all the work products of the Architectural Design. In particular, the first set of work products is the outcome of the Transition activity, the second is the outcome of the Role Design and Resource Design activities, the third is the outcome of the Interaction Design activity, the fourth is the outcome of the Constraint Design activity and the last is the outcome of the Space Design activity.

2.3.3.2 Transition Tables

Figure 50 presents an example of the Transition Tables for the conference management case study.

2.3.3.3 Entities Tables

Figure 51 presents an example of the Entities Tables for the conference management case study.

Fig. 47

The flow of tasks in the interaction design activity

Fig. 48

The flow of tasks in the space design activity

Fig. 49

The architectural design work products

Table 4 Architectural Design work products kinds

2.3.3.4 Interactions Tables

Figure 52 presents an example of the Interactions Tables for the conference management case study.

2.3.3.5 Constraints Tables

Figure 53 presents an example of the Constraints Tables for the conference management case study.

2.3.3.6 Topological Tables

Figure 54 presents an example of the Topological Tables for the conference management case study.

2.4 The Detailed Design

The goal of Detailed Design is to choose the most adequate representation level for each architectural entity, thus leading to depict one (detailed) design from the many potential alternatives outlined in the Architectural Design step. Figure 55 presents the Detailed Design process, while Fig. 56 presents the flow of activities, the involved roles and the work products.

2.4.1 Process Roles

One role is involved in the Detailed Design: the Detailed Designer.

Fig. 50

Transition role-task table (C)TRT _t

Fig. 51

Action table (C)A _t

Fig. 52

Interaction table (C)I _t

Fig. 53

Rule table (C)Ru _t

Fig. 54

Space table (C)S _t

Fig. 55

The detailed design process

Fig. 56

The detailed design flow of activities, roles, and work products

2.4.1.1 Detailed Designer

The Detailed Designer is responsible for

• Mapping the MMMElements of the Architectural Design to the MMMElements of the Detailed Design

• Identifying the most suitable system architecture among all the possibilities provided in the Architectural Design step

• Assigning roles to agents

• Assigning actions to individual artifacts

• Assigning roles to societies

• Assigning resources to environmental artifacts

• Assigning resources to aggregate

• Assigning operations to environmental artifacts

• Assigning rules to artifacts

• Designing artifacts usage interfaces

• Assigning interactions to uses and designing the specific protocols

• Assigning interactions to manifests and designing the specific protocols

• Assigning interactions to speakTo and designing the specific protocols

• Assigning interactions to linkedTo and designing the specific protocols

• Assigning spaces to workspaces and designing them

2.4.2 Activity Details

2.4.2.1 Carving Activity

The Carving activity is composed of the following tasks:

Activity	Task	Task description	Role involved
Carving	Carving	For each entity the appropriate layer of representation is chosen	Detailed Designer (perform)

The flow of tasks inside the Carving activity is reported in Fig. 57.

2.4.2.2 Mapping Activity

The Mapping activity is composed of the following tasks:

Activity	Task	Task description	Role involved
Mapping	Map ArchDes-DetDes	Mapping of the MMMElements defined in Architectural Design to Detailed Design MMMElements so as to generate the initial version of the Detailed Design models	Detailed Designer (perform)

The flow of tasks inside the Mapping activity is reported in Fig. 58.

Fig. 57

The flow of tasks in the carving activity

Fig. 58

The flow of tasks in the mapping activity

2.4.2.3 Agent Design activity

The Agent Design activity is composed of the following tasks:

Activity	Task	Task description	Role involved
Agent Design	Agent/ Society Design	Design of Agents and Societies	Detailed Designer (perform)

The flow of tasks inside the Agent Design activity is reported in Fig. 59.

Fig. 59

The flow of tasks in the agent design activity

Fig. 60

The flow of tasks in the environment design activity

2.4.2.4 Environment Design Activity

The Environment Design activity is composed of the following tasks:

Activity	Task	Task description	Role involved
Environment Design	Environment Design	Design of Artifacts and Aggregates	Detailed Designer (perform)

The flow of tasks inside the Environment Design activity is reported in Fig. 60.

2.4.2.5 Interaction Detailed Design Activity

The Interaction Detailed Design activity is composed of the following tasks:

Activity	Task	Task description	Role involved
Interaction Detailed Design	Interaction Detailed Design	Design of the interaction protocols for Uses, Manifests, SpeakTo and LinkedTo identified in the carving	Detailed Designer (perform)

The flow of tasks inside the Interaction Detailed Design activity is reported in Fig. 61.

Fig. 61

The flow of task in the interaction detailed design activity

Fig. 62

The flow of task in the workspace design activity

Fig. 63

The detailed design work products

2.4.2.6 Workspace Design Activity

The Workspace Design activity is composed by the following tasks:

Activity	Task	Task description	Role involved
Workspace Design	Workspace Design	Design of workspaces starting from spaces identified in the carving	Detailed Designer (perform)

The flow of tasks inside the Workspace Design activity is reported in Fig. 62.

2.4.3 Work Products

The Detailed Design step exploits several sets of tables: namely, Mapping Tables, Agent/Society Design Tables, Environment Design Tables, Interaction Detailed Design Tables and Workspace Design Tables. Figure 63 reports the relationships among the work products and the MMMElements of the Detailed Design step.

2.4.3.1 Kinds of Work Products

Table 5 describes all the work products of the Detailed Design. In particular, the first entry is the outcome of the Carving Activity, the second set of work products is the outcome of the Mapping activity, the third set is the outcome of the Agent Design activity, the fourth set is the outcome of the Environment Design activity, the fifth set is the outcome of the Interaction Detailed Design activity and the last set is the outcome of the Workspace Design activity.

2.4.3.2 Carving Diagram

An example of the Carving Diagram for the conference management system is reported in Fig. 64.

2.4.3.3 Mapping Tables

Figures 65, 66, and 67 present some examples of the Mapping Tables for the conference management case study.

2.4.3.4 Agent/Society Design Tables

Figure 68 presents an example of the Agent/Society Design Tables for the conference management case study.

Table 5 Detailed Design work products kinds

Fig. 64

Carving operation in the conference management system

Fig. 65

Mapping agent-role table MAR _t

Fig. 66

Mapping artifact-resource table MArR _t

Fig. 67

Mapping artifact-rule table MArRu _t

Fig. 68

Agent-artifact table AA _t

2.4.3.5 Environment Design Tables

Figure 69 presents an example of the Environment Design Tables for the conference management case study.

Fig. 69

Artifact-usageInterface table AUI _t

Fig. 70

Use-protocol table UP _t

2.4.3.6 Interaction Detailed Design Tables

Figure 70 presents an example of the Interaction Detailed Design Tables for the conference management case study.

2.4.3.7 Workspace Design Tables

Figure 71 presents an example of the Workspace Design Tables for the conference management case study.

Fig. 71

Workspace-artifact table WA _t

3 Work Products Dependencies

Figure 72 describes the dependencies among the different SODA composite work products.

Fig. 72

The work products dependencies