# A Survey on Modeling Languages for Applications Hosted on Cloud-Edge Computing Environments
## 3 Results
### Relationships, Dependencies and Environment Values
By leveraging these GUI-based tools, developers can enhance their ability to accurately and efficiently express the intricate connections between various components and resources. Furthermore, apart from the relationships between components, there are also dependencies among them. If a model indicates that one component depends on another, the cloud platform should prioritize the deployment of the component that has no dependencies. In TOSCA, dependencies between components can be found under the requirements section. This means that TOSCA models dependencies in the same manner as relationships. In the same manner, the EDDM syntax [7] is a dependency relationship that indicates which component is dependent on another component. TOSCA Light [30], which combines the semantic rules of both above-mentioned languages, provides support for a DependsOn relationship that allows the expression of dependencies between components. Moreover, developers can extend this relationship to create custom relationships. The SMADA-Fog [12] deployment model includes a relationship type called 'dependsOn' between application components. This relationship indicates that a component can depend on another, enabling the output of one task to serve as the input for another, thus forming a service chain. In a similar approach, MoDMaCAO [23] incorporates the Dependency link, derived from the ComponentLink, to effectively depict dependencies between components. ComponentLink is constructed with specific grammatical rules that facilitate the establishment of connections between dependent Component entities. The authors emphasize the flexibility provided to developers in extending the functionality of the Dependency link, enabling the expression of custom dependencies associated with installation, execution, and other relevant aspects. Installation dependency signifies that the deployment of the target component only proceeds if the source component is successfully deployed beforehand. On the other hand, execution dependency indicates that the source component can only be initiated when the target component is already in the active/running state. While in HOT, developers can specify dependencies between resources, such as one virtual machine instance depending on another. It is worth noting that TOSCA and HOT depict dependencies differently from each other, as they have different scopes of usage. Similarly, CAMEL [1] also offers the capability to define dependencies in the deployment description. Describing dependencies is crucial in CMLs as they involve properties that ensure proper functionality, such as a frontend application requiring the IP address of a back-end database. Hence, it is vital for CMLs to offer the capability to describe inputs or environmental variables that can capture and manage these dependencies. TOSCA incorporates the input section, which permits users to tailor deployments by providing input parameters rather than hardcoded values in a template. This feature is enabled for every node type, allowing for adaptable and dynamic configurations in cloud deployments. Similarly, EDDM [7] can depict inputs in a more abstract manner and utilize them when mapping to a specific technology or platform technical deployment file. While TOSCA Light [30] may have additional limitations, it is capable of incorporating input descriptions similar to those found in both TOSCA and EDDM. MiCADO [17] introduces a TOSCA extension, adding the environment property to the custom entity for container description. This property is an array that can hold multiple environment values, following the format utilized by Kubernetes and Docker Compose for handling environment values. In their work, [PERSON] et al. [20] present a TOSCA extension that enables developers to indicate environmental variables in either the docker_cloud or docker_edge sections of the fragment entity.