## 5 Contribution  
Domain specificity (MO) in our situation is represented by concepts/operations and constraints that are generally represented by a meta-model of Domain-Specific Language (DSL) [48]. Information systems are modeled and described using a modeling language that is provided by a meta-model. It includes the language's abstract syntax, which explains its constraints in terms of the concrete syntax that the design tool can use. Two views comprise our previous proposed ArchiMo meta-model ([16] (Figure 3): one for the application layer and another for the business layer. In order to connect the information system with the core network at the technological layer, we rely on a meta-model for IMS that offers an underlying platform in [16]. In this section, we present our contribution to extend the ArchiMO meta-model that we previously developed and published in [2; 3; 16]. Our previous contribution ArchiMO is presented in (Figures 3 and 4). The ArchiMO meta-model represents the domain specifications of MO. It enables us to generate a specific design tool that is coherent with Archi tool [17] but contains additional concepts, elements, constraints, and relations that are specific to the MeDON/MO domain and for data fusion concepts [10]. Briefly, the generated design tool ArchiMO helps the SSN designers to model information systems such as MeDON and avoid syntax errors that may be made during the design activity. Our primary goal in writing this article is to improve ArchiMO's intelligence by increasing its ability to identify mistakes that SSN designers may have made when creating and developing MO models. Additionally, we aim to keep the entire deployed SSN operating at peak performance and avoid any malfunction. To reach this goal, we have extended the ArchiMO meta-model (abstract syntax), concrete syntax, and the design tool by incorporating new Underwater Environmental Constraints (UECs). This extended ArchiMO represents the specificity of the SSN domain in terms of certain UECs that are required for the proper deployment of USSNs to ensure the appropriate performance and functioning of SSNs [6; 7; 11; 12; 34; 35]. Additionally, it enables us to generate a new and an updated version of our ArchiMO design tool that is consistent with Archi and includes the new UECs. Relying on [6; 7; 34] and according to MeDON project [13] (Figure 2), SSN information systems must meet certain UEC requirements in order to be deployed properly. This implies that every physical component of SSNs, including Smart Sensors (SSs) and Smart Fusion Servers (SFSs), must comply with these UECs. Otherwise, inadequate service quality on each deployed component level (e.g., inaccurate/useless detected data by the underwater SS) and overall SSN performance (e.g., erroneous/useless gathered, analyzed, and treated data that are provided by underwater SFSs after receiving data from different underwater SSs) may result from this. As a result, we identify the following UECs that are interrelated, depend on each other, and need to be taken into account when deploying underwater SSSs/SFss to ensure the appropriate performance and functioning of SSN [11]: (1) architecture (2D or 3D); (2) salinity level; and (3) operable depth. SSN designers need to be aware of the various ways in which these UECs are inter-dependencies and related in terms of values [6] such as the two following scenarios: (1) If the experts want to deal with 3D architecture, they should be aware of the salinity level (e.g., sea or shallow water) at which they wish to install the physical components of the USSNs (e.g., SSSs/SFss). The deployment of SSs/SFs should be carried out at a depth of 10,920 m underwater if the salinity level is sea. However, the deployment of SSs/SFs should be carried out at a depth of 3000 m underwater if the salinity level is shallow water. (2) If the experts want to deal with sea salinity level, they should be aware of architecture type (e.g., 2D or 3D) of which they wish to install the physical components of the USSNs.