## 2 Related Work  
We provide the relevant work in relation to the design tools in this section. We are interested in the following concerns, which we will define and examine in this section in relation to the concept of Architectural Description Languages (ADLs) [22; 23; 24; 25] and their design tools: (C1) utilizing a language's syntax or language structure to prevent errors at the design level; (C2) various points of view (a viewpoint is a work product establishing the conventions for the construction, interpretation, and use of architecture views to frame specific system concerns) that are reflected in the architectural description [26]; (C3) design tool extensibility; (C4) the variability of components; and (C5) a platform for execution and testing. Regarding the concern of preventing errors, the expanded design tool works to stop problems before they happen, saving the designer the trouble of fixing them later. The sources for this error prevention strategy include [27; 28; 29]. Similar to our methodology, it is circumvented by utilizing the abstract syntax (our suggested concepts), in which we have established and included our particular concepts, constraints, and relations. Regarding the concern of many viewpoints, the extended design tool offers the designers a variety of viewpoints based on their domains of experience. The design tool in [27; 28; 29] offers only one viewpoint to suit software development activities. It is not possible for various designers to share a design created with this design tool. This is because there is no architectural framework that produces a design tool that complies completely with the aforementioned ooncer [30]. Our approach takes this into account because of the several EA standard layers that distinguish between different points of view. As for the extensibility concern, adding new concepts and restrictions to an existing design tool is made possible through the extension of a meta-model [27; 28]. As demonstrated in [31; 32], our method achieves this by adding additional constraints to the ArchiMate meta-model and creating a new design tool that incorporates these constraints. Regarding the heterogeneity concern, which is the presence of various components and communications associated with various activities and contexts, in [27; 28; 29], we encounter this heterogeneity in the software components and models. The diversity of components in our approach is seen in our MO model, which has several Smart Sensors linked to numerous Data Fusion Servers. Concerning the platform for the execution test, we may find an integration between two distinct platforms, as shown in [33], to provide an automated execution test of a given complex model. Additionally, as shown in [27; 28; 29], there are platforms on which the designer is unable to test and validate his models or instances. Nevertheless, as per [31], our approach enables us to verify the generated models on an executable platform that is integrated inside the same framework that facilitates model construction (see to Section 6). For instance, messages can be sent and received between Smart Sensors and Fusion Servers using the IMS. Actually, we should evaluate the detrimental effects of mistakes or sub-optimal sensor network designs on the overall performance of USSNs in order to further elucidate C1. According to C1, these mistakes should be avoided since they may arise from the following outcomes [7; 11; 12]: (1) Inaccurate and incomplete data collection: this undermines the project's ability to gather reliable information about the underwater environment, including the quality of services provided such as the movement patterns of marine mammals/underwater moving objects and the state of the ecosystem. (2) Operational inefficiencies: this can introduce an increased energy consumption, high maintenance costs, and reduced sensor network lifespan. These inefficiencies can strain project resources and hinder its long-term sustainability.