A Model-Driven Approach for System Administration Marco Centurión, Maximiliano Kotvinsky, Daniel Calegari, Andrea Delgado Instituto de Computación, Facultad de Ingeniería Universidad de la República Montevideo, Uruguay, 11300 {mcenturion, maximiliano.kotvinsky, dcalegar, adelgado}@fing.edu.uy Abstract—System administration requires maintaining net- The configuration process in either context (local, global) work infrastructure and the software running on it. Within an is usually done through a low-level script coding process that IoT context, it also integrates different devices, communication becomes repetitive and often chaotic. Moreover, documenta- protocols, and layers. The configuration process is usually carried out by system administrators which perform the configuration tion is usually scarce and outdated, and thus, CM becomes manually or through the definition of low-level scripts. Config- an expensive and error-prone process due to the continuous uration manager tools, such as Puppet, improve this aspect, by evolution and diversity of network components. In this context, adding a level of abstraction from the infrastructure and allowing Model-Driven Engineering (MDE) [7] techniques can support a better systematization and automation of the configuration many CM needs, e.g., domain-specific modeling languages can process. However, they do not provide a visualization of the whole infrastructure. In this paper, we present a model-driven provide a way to represent different aspects of the network, approach linking visualization and automation needs for system leveraging a heterogeneous software and hardware infrastruc- administration. We defined a modeling language for a network ture, and to generate the configuration scripts to be deployed infrastructure linking hardware, software and configurations, on it. This improves the global comprehension of the IT specified as a UML profile of deployment diagrams and ex- infrastructure among sysadmins and potentially eliminates the tendable for IoT elements. We generate configuration scripts for Puppet and provide a functional prototype and a case study need for setting configuration scripts manually. demonstrating the technical feasibility of the ideas. There are previous works related to both visualization and Index Terms—System administration, IoT, Model-Driven En- automation aspects. Some tools allow to visualize general gineering (MDE), UML profile, Puppet information of a network (e.g., LanFlow) but without any connection with CM needs. There also are automated configu- I. I NTRODUCTION ration tools [8] (e.g., Puppet) which leverage the specification A system administrator, or sysadmin [1], is responsible for of system configurations and provide a way of applying the installation, configuration, monitoring and assurance of an such configurations against the target network components. IT infrastructure. This infrastructure is usually composed of Nevertheless, the two aspects have not been completely linked. computer networks with hardware, such as switches, routers, In this work, we present a proposal that relates both aspects. servers and workstations, and software running on them, such In particular, we define a UML profile of deployment diagrams as firewalls, databases and web servers. In the context of the for the specification of aspects of a computer network that Internet of Things (IoT) [2], [3], [4], as the network of physical links hardware, software, and configurations. We also define things and virtual elements that communicate and interact with model transformations experimenting with the automatic gen- each other, other devices have been increasingly integrated eration of configuration scripts in Puppet. We implemented such as RFID tags, sensors, actuators, mobile phones, etc. [2]. these aspects within a functional prototype (available at [9]) Configuration management (CM) [5] ensures that the con- of a configuration tool, and we developed a case study that puts figuration of the IT infrastructure keeps known, updated, into practice our solution and shows the technical feasibility stable and trusted. Each component has his state, which may of the ideas. Although we are experimenting with system range from a simple network configuration to ensuring that a administration in general, our proposal lays the foundations program is installed or a configuration file is present. In this for its application in a more general context for IoT configu- context, sysadmins need not only to configure each component ration management, extending the proposal with IoT specific but also to document the whole network configuration. elements and configuration challenges. In IoT architectures [3] several layers, objects, protocols, The rest of this paper is structured as follows. In Section and configurations are needed to provide IoT key elements II we present related work concerning basic system admin- such as identification and tracking technologies, wired and istration and MDE. In Section III we present a requirement wireless sensor and actuator networks, enhanced communi- analysis and refine the scope of this work. Then, in Section IV cation protocols, and distributed intelligence for smart objects we introduce our solution and in Section V we describe a [2]. A hierarchical network is also defined for easing data pro- functional prototype and a case study. In Section VI we discuss cessing at different levels: Edge (network edge, i.e., devices), how our basic approach can be extended for considering a Fog (local cloud services) and Cloud (global services), which more general context for IoT. Finally, in Section VII we also needs configuration and monitoring [4], [6]. provide some conclusions and an outlook of future work. Copyright c 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). 7 II. R ELATED W ORK It also needs to be flexible enough to allow changes or the There are several tools for the generation of network topolo- introduction of new devices. On the network structure model, gies and their simulation, e.g., [10]. These tools, however, are we also need to be able to specify the desired configuration for focused on the structure of the topology at a high level and each component, which will define the configuration model. they do not differentiate particular network devices. There are 2) RQ2: Standardization of models: The modeling lan- also tools for the visualization of a network topology, such as guage should follow standards and/or existing agreements on LanFlow1 and SolarWinds2 . The later also allows the detection networks elements definitions and modeling, to be understood, of a network, including its topology, network devices, servers, used and integrated with existing models and/or network and virtual hosts. Although automatic detection is of interest, descriptions. these tools do not provide means for configuring the network. 3) RQ3: Scripts generation: From the configuration model, The use of MDE was explored in the context of computer the configuration scripts should be derived which can be used networks. In [11] the authors present an approach for wireless to configure the devices. To generate the configuration scripts sensor networks modeling. The proposal introduces three an M2T transformation will be provided, in which knowledge levels of abstraction to build: specific domain models, descrip- regarding mappings between configuration model elements tions of component-based architecture, and platform-specific and script configuration elements is explicit. The generated models. Transformations are also defined between these three scripts could be in different formats, i.e., the tool should levels. In [12] the authors present YANG, a data modeling provide options to generate different types of scripts (e.g., language for the network configuration protocol (NETCONF), XML, text, specific format for different CMT, etc.) allowing a complete description of all data sent between a NETCONF client and server. In [13] the authors develop a B. Tool support requirements tool to standardize network administration to configure any Several aspects should be covered: protocol independently of the provider. They define a domain- 1) RQ4: Model editor: The editor will implement the mod- specific language for the configuration of network devices, eling language to obtain network structure and configuration without considering the configuration of computers or servers. diagrams, which can be edited and modified. It will store However, it does not define any form of integration with models in a standard format and provide export functionalities another tool. for different formats, to allow integration with existing tools. Configuration management was also studied in the context 2) RQ5: Application of the generated configuration: After of MDE [14], [15] as a general discipline. Moreover, there the configuration files are generated from the model, it should are many model-driven proposals for the automation of in- be applied in an automated and centralized way to be able to frastructure configurations [8]. Puppet3 provides a declarative install and implement the desired configuration over the target domain-specific language to describe system configuration network. This functionality can be achieved by integrating (resources and their state), abstract from platform-specific already existing tool support (CMT). aspects. A configuration can be either applied directly to the 3) RQ6: Distribution of configuration scripts into nodes: system or compiled into a catalog and distributed to the target Another desirable characteristic is the capacity of sending system in which an agent enforces the configuration. It also the generated configuration scripts into the corresponding allows centralizing the configuration providing versioning and nodes and devices, to support the centralized configuration of synchronization features. devices. CMTs already provide a centralized server which is III. R EQUIREMENTS FOR SYSTEM ADMINISTRATION in charge of carrying out the necessary actions to configure network nodes, thus we need to integrate our tool with them. We identified a set of requirements to apply a model-driven 4) RQ7: Existing network detection: The capacity to detect approach for system administration, which we organized in the structure of an existing network and generate a model to two categories regarding i) the modeling language and gener- represent it could be useful to help in creating the initial model. ation, and ii) the tool support for the approach. This functionality becomes more important as the size of the A. Modeling language and generation requirements initial topology grows, and could even be essential in cases where the target system or network is of the order of hundreds These requirements are summarized in the following: of devices (especially on an IoT context). Some tools already 1) RQ1: Modeling language: The modeling language needs provide this functionality. to express the elements comprising the network to be con- 5) RQ8: Detection of network changes: The detection of figured, including different types of nodes such as PCs, network and/or device changes could also be important to auto- servers, devices (routers, switches), among others. The lan- matically update the corresponding model. Updating the model guage should include these concepts and the corresponding in an automated way helps speed up the process of changing relationships between them, to be able to model the network. the model to reflect changes in the real world, and rapidly 1 LanFlow Net Diagrammer: http://www.pacestar.com/lanflow/ generate the necessary scripts to update the corresponding 2 SolarWinds: https://www.solarwinds.com/es/network-topology-mapper configuration. As with the previous requirement, some tools 3 Puppet: https://puppet.com/ already provide this functionality. 8 IV. P ROPOSED SOLUTION We describe a solution and implementation covering re- quirements RQ1 to RQ6 (presented in Section III). Full solu- tion is available at [9]. Requirements referring to automatically detect a network (RQ7) and its changes (RQ8), as well as an extension of the ideas for a more general IoT context, were left for future work and discussed in Section VI. A. Modeling language For the definition of the modeling language we faced two Figure 1: Main concepts and relationships in the solution main challenges: i) to analyze the specific domain in order to identify key concepts and relationships that we need to model the network structure, devices, and their configuration, and ii) 2) Domain Modeling Language: We decided to extend to decide between developing a DSL or an extension of UML UML with specific concepts for our domain, based on the by means of a UML profile. The solution we present in this following reasons. UML is a standard language, which is subsection satisfies requirements RQ1, RQ2, and RQ4. understood and used by many software professionals, provides 1) Specific domain analysis: To model the network topol- a base syntax and corresponding semantics that help to under- ogy, nodes and their connections should be specified. Nodes stand the extension elements and several tools already exist can be of two types: physical and logical nodes. Once the that provide support for it. Also, the deployment diagrams fit physical and logical topology is modeled, the configuration the domain analysis we presented earlier. This kind of diagram on the desired elements can be specified. shows how different nodes are interconnected in a distributed Physical nodes to be modeled include network devices system, which components are located in which nodes, and such as routers and switches, servers, personal computers implemented by artifacts. Nodes are specialized in two el- (PC or workstation), and other devices that can be connected ements: Device which represents physical machines, and to a network such as printers, scanners, etc. These will ExecutionEnvironment which are assigned to Device be modeled with the generic term "devices". Router and nodes. Artifact elements can be deployed into nodes, Switch, as network devices, is essential to define the network and Deployment elements represent relationships between topology, connecting its elements. Server and PC must be artifacts and nodes, as well as characteristics assigned to these differentiated since they provide different functions. In the relations. Communication links model system connections case of logical nodes, i.e., logical elements corresponding between elements. to components in physical nodes, key elements to be in- 3) UML profile definition: To define the UML pro- cluded are: Operating system of Servers, and PC, file we extended concepts already provided in the de- the Firmware of network devices Router and Switch. ployment diagram that we presented earlier. Extending Also, the software installed on each node is of interest, in Device element we represent Physical nodes, and ex- particular: Firewall component, Runtime (e.g., Java), tending ExecutionEnvironment we represent Logical Application Server (e.g., Tomcat), HTTP Server nodes, each with corresponding stereotypes. The parent (e.g., Apache), Database Engines (e.g., MySQL). element Node is not extended since the base element Modeling the desired configuration is a key element in already provides the information needed. To represent a our proposal.We identified three main configuration scenarios. Configuration component we extend the Artifact Software configuration refers to configuring logi- component with the corresponding stereotype. This extension cal nodes, where each type of the component (OS, ap- with main concepts from the UML profile is shown in Fig. 2. plication server, database, etc.) present specific configura- tion elements representing their configurable aspects. Files configuration refers to specific actions over system files, i.e., verify existence or content, copy and delete files, etc. This configuration is key to detect if a manual configuration of files is required. Free configuration is defined to be able to register any type of configuration that cannot be automatically applied by a tool, but can help in manually configuring elements. A configuration can also be applied to a set of nodes when devices are of the same type and applying the configuration individually requires more effort, so a configuration can be applied to one or many devices. In Fig. 1 we present the main concepts and relationships in the proposed solution. Figure 2: Physical, Logical and Configuration stereotypes 9 B. Generation of configuration scripts We use an existing CMT as a target of the configuration scripts generated, instead of using yet another new language, since generating for a specific tool will allow us to validate the scripts. To select the CMT we review several existing ones, from which we took an in-depth look at Puppet, Chef, and Ansible, since they stood up from the rest, selecting Puppet since we already worked with it. The solution we present in this subsection satisfies requirements RQ3, RQ5, and RQ6. 1) Mappings for the generation: We defined mappings between the network and configuration profile we have defined (a) Physical nodes (extends Physical from Fig. 2) and the configuration scripts to be generated. For each element in the specific domain, we generate a file, and these files are organized in a directory hierarchy which is consistent with the target CMT, so it can be used to apply the configuration. The mappings are the following ones: • two main folders are defined at root level: manifests and modules, and within the last one, there are two folders, one that includes the information of the physi- cal and logical nodes called device, and another that corresponds to the configuration of these nodes, called configurations. These directories have their own manifests directory (this is exemplified in Fig. 7). • a site.pp file (within the manifests folder, is gen- erated with a list of the physical nodes to be configured (b) Logical nodes (extends Logical from Fig. 2) (this is depicted in Fig. 4). • for each Physical node a file is generated with includes to the files generated for the logical nodes belonging to it, under the device directory. Also, a directory is created for each Physical node which will contain the files for the corresponding Logical nodes. • for each Logical node a file is generated with basic values regarding its installation, and includes to the configuration files generated for it, under the directory created for the Physical node. A directory is also created for each Logical node in the configurations directory, which will contain its configuration scripts. • for each configuration, a file is generated and located in the directory of the Logical node. • for any element for which does not correspond to create (c) Specific configurations (extends Configuration from Fig. 2) a configuration script, a text file with its information is Figure 3: Stereotype definitions (excerpt) created and located in the directory of the corresponding Physical node in a Information directory. 2) M2T transformation: The mdcms2puppet transforma- Then for each defined element within the three main con- tion takes as input a model defined with the UML profile and cepts of Physical, Logical and Configuration we generates the configuration scripts in the Puppet format file, included them into the metamodel as specialization of the which will be imported in Puppet to configure the network. parent one. Due to space reasons, in Fig. 3 we only include a The transformation was implemented using Acceleo and inte- couple of examples of each kind. grated with the modeling tool. Complete information can be We implemented this extension as an Eclipse plug-in, based found at [9]. on Papyrus4 , an Eclipse-based UML modeling tool which The output of the transformation is organized in the direc- already has extension capabilities. tory hierarchy we described, generating also a Puppet file that includes the modules to be installed, and the file site.pp (manifests/site.pp) which includes information about nodes 4 Papyrus Modelling Environment: https://www.eclipse.org/papyrus/ in the topology, to be used by Puppet to declare nodes 10 Figure 4: Example of a source model, the M2T transformation and the file generated and their configuration. This file is the starting point of the servers. Within the PC’s subnet, depicted in Fig. 5, there are configuration, information regarding each node, either physical two switches (SwitchWin and SwitchUnix) that separate or logical, will be generated under modules/device/manifests, the Windows-based computers from Unix-based computers and configuration elements will be generated under mod- (and a printer Printer). Notice how the different devices are ules/configurations/manifests. represented with their corresponding stereotypes. In particular, Basic knowledge of Puppet is still needed to be able to PCUnix2 is a PC (a physical device) with two logical make use of the generated code, is that it is necessary to run components installed within: Ubuntu, a logical operative it in each one of the components that need to be configured. system, and mydb2, a logical PostgreSQL db engine. There However, since a model contains all the information of the is also a configuration PCUnix2DB which is a «PSQLDB» infrastructure, it could be possible to include the execution of configuration applied to the logical node mydb2. the scripts as part of the generation process (or later on). The visualization of the network is partitioned: its topology C. Final Remarks together with an identification of the hardware, software and configurations within are depicted using deployment diagrams, The language covers most types of regular hardware and as well as specific properties of their components are visual- software components within a network for which a configu- ized in a properties view, as depicted in Fig. 6. ration is needed. There are many possible improvements, as discussed in Section VI. Also, the profile design could be The generation process takes the network configuration improved to be more strict enforcing correct by construction model and generates every configuration file in a concrete modeling with strong typing of properties. directory structure (as depicted in Fig. 7) required by Puppet. Unlike Puppet, our approach provides a generic approach A Puppetfile is generated containing the modules that based on topology models and a corresponding graphical need to be installed for use in Puppet, and also a site.pp notation, both aspects provide some benefits. First, the lan- file with the information of the existing nodes in the topology. guage is independent of any specific CMT, which seems to If the configuration of the network is defined correctly, the be more interesting for a heterogeneous IoT environment. In generated files will be executable without modifications. fact, Puppet is used just as a proof of concepts. Second, a Within the modules/device directory there is a con- graphic notation favors understanding when it comes to aspects figuration file for each configurable device component. In of a topology, which Puppet does not represent. Nevertheless, the example, we have a directory for the PCUnix2 physical the visualization we provide is only a default concrete syntax device, and a Puppet file PCUnix2.pp with its configuration provided for deployment diagrams. Future work could be to defined in Fig. 6a. The generated file is depicted in Fig. explore other advanced and scalable alternatives. 8a. Within this directory, there is a Puppet file for each V. C ASE S TUDY logical node, e.g., mydb2.pp depicted in Fig. 8b which was generated from the configuration in Fig. 6b. The case study validates the approach for basic system administration: unification of configuration and network el- Within the modules/configurations directory there ements, topology visualization and automatic configuration. is another directory for each component class, e.g., db for However, as will be discussed in Section VI the whole databases and the corresponding files generated from the approach can be extended in a more general context of IoT. configuration artifacts, e.g., PCUnix2DB configuration for For space reasons we present an excerpt of the case study. the mydb2 database. The corresponding Puppet file for this The whole case study (available at [9]) comprises two routers configuration is depicted in Fig. 8c. Notice that within the connected to each other. On the one hand there is a subnet configuration file for the mydb2 database (depicted in Fig. corresponding to the PCs and, on the other, there are the 8b) there is an import of the PCUnix2DB configuration. 11 Figure 5: Case Study: network configuration VI. T OWARDS I OT C ONFIGURATION M ANAGEMENT databases, so the language itself needs to change for adding new technologies. To improve language evolution, it could be IoT poses a more general context than what we have interesting to essay a multi-level approach, such as in [16], presented, with a wide range of different devices and inter- providing means for metamodel extensibility. connection requirements. Our proposal can be considered the first step towards this context, at least for some IoT scenarios. We also claimed in Section III (RQ2) that we need to As reviewed in [6], there are specific challenges for MDE, and provide a common way of modeling both hardware and from a CM perspective, we can discuss the following aspects. software aspects to improve communication and interoper- 1) Configuration and Control: Devices are usually pro- ability. We need to analyze how to relate our work with the vided with generic configurations which require to be further Modeling and Analysis of Real-time and Embedded systems refined with specific settings. It is also required to remotely (MARTE) [17] proposal since it provides a more specific configure the devices for recovering and maintenance issues. view on the specification, design, and verification/validation As claimed in Section IV-C, it is useful to have a more abstract aspects of this kind of systems. Also, the OASIS Topology and language, such as the one proposed, which links devices Orchestration Specification for Cloud Applications (TOSCA), together with configurations, that can also be easily applied to a domain-specific language for defining portable deployment many of them. The aid of a CMT is also beneficial, especially and automated management of services on a wide variety of when it is possible to automatically generate scripts. infrastructure platforms, was analyzed for the automatic de- Heterogeneity is also an issue. Up to now, some technical ployment of IoT environments [18]. Like ours, it also provides aspects are fixed in the metamodel, e.g., concrete types of topology models and a corresponding graphical notation. 12 (a) PCUnix2 properties Figure 7: Case Study: configuration files organization (b) mydb2 properties we used the basic concrete syntax provided by deployment diagrams, but other notations could be considered to balance understanding and scalability. 3) Maintenance and Adaptation: Device heterogeneity poses a challenge for maintenance since not every device can be configured using the same CMT, e.g.: resource-constrained devices cannot execute a CMT client. As claimed before, it is convenient to generate different target languages from a more abstract model, even with uncertainty aspects (e.g., partial configuration). Cloud services and middleware typically play an important role. Several proposals can be integrated into this (c) PCUnix2DB properties context, e.g., WSO2 Application Server Puppet Module 5 . Figure 6: Case Study: properties configuration Adaptation requirements are related to the models@runtime approach [21] which extends the applicability of models produced in MDE approaches to the runtime environment. 2) Discovery and Monitoring: We already claimed, in In particular, sometimes IoT devices are required to adapt Section III, that desirable requirement are the discovery of their behavior at runtime with little or no human intervention. a network configuration (RQ7) and the monitoring of such Further work is needed in this sense. configuration to automatically detect changes (RQ8). It could 4) Security: As a final issue concerning configuration man- be useful to dynamically discover newly added devices and agement, the administrator may meet problems of access con- service processes. As presented in Section II, tools such as trol trying to reach a good balance between smooth execution SolarWinds help in this direction. In previous work [19] we and the proper protection for security and privacy. In this have dealt with the automated generation of Quality of Service sense, it could be interesting to consider other models, such (QoS) configurations for software services specified in the as SecureUML [22] which provides a modeling language for SoaML UML profile [20] which we can also integrate for the development of secure, distributed systems based on Role- a complete view of IoT services monitoring. Based Access Control (RBAC) with additional support for Concerning visualization, our language can be improved to specifying authorization constraints. support a more succinct concrete syntax in the way of existing network visualization tools. As discussed in Section IV-C 5 WSO2 App Server Puppet Module: https://github.com/wso2/puppet-iot 13 ment of the tool with respect to its visualization features and the automatic discovery of the network configuration. R EFERENCES [1] T. Limoncelli, C. Hogan, and S. Chalup, The Practice of System and (a) PCUnix2 generated script Network Administration. Addison-Wesley Professional, 2007. [2] L. Atzori, A. Iera, and G. Morabito, “The internet of things: A survey,” Comput. Netw., vol. 54, no. 15, pp. 2787–2805, 2010. [3] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and M. Ayyash, “Internet of things: A survey on enabling technologies, protocols, and applications,” IEEE Communications Surveys Tutorials, vol. 17, no. 4, pp. 2347–2376, 2015. [4] J. Lin, W. Yu, N. Zhang, X. Yang, H. Zhang, and W. Zhao, “A survey on internet of things: Architecture, enabling technologies, security and privacy, and applications,” IEEE Internet of Things Journal, vol. 4, no. 5, pp. 1125–1142, 2017. [5] J. Quigley and K. Robertson, Configuration Management: Theory, Practice, and Application. Addison-Wesley Professional, 2003. [6] S. Wolny, A. Mazak, and B. Wally, “An initial mapping study on mde4iot,” in Proc. of MODELS 2018 Workshop: MDE4IoT, ser. CEUR Workshop Proceedings, vol. 2245. CEUR-WS.org, 2018, pp. 524–529. [7] S. Kent, “Model driven engineering,” in International Conference on (b) mydb2 generated script Integrated Formal Methods. Springer, 2002. [8] F. Research, “The forrester wave: Configuration management software for infrastructure automation, q4 2018,” 2018. [9] M. Centurion, M. Kotvinsky, D. Calegari, and A. Delgado, “MdNetConf: Model-driven Network Configuration software,” 2019. [Online]. Available: https://gitlab.fing.edu.uy/open-coal/mdnetconf [10] H. Tangmunarunkit, R. Govindan, S. Jamin, S. Shenker, and W. Will- inger, “Network topology generators: Degree-based vs. structural,” in ACM SIGCOMM Computer Communication Review, vol. 32, no. 4. ACM, 2002, pp. 147–159. [11] F. Essaadi, Y. B. Maissa, and M. Dahchour, “Mde-based languages for wireless sensor networks modeling: A systematic mapping study,” in Advances in Ubiquitous Networking 2. Springer, 2017, pp. 331–346. [12] M. Bjorklund, “Yang-a data modeling language for the network config- (c) PCUnix2DB generated script uration protocol,” Internet Engineering Task Force, Standard, 2010. [13] G. A. H. Castro, “Metamodelo para configuraciones en dispositivos de Figure 8: Case Study: generated configuration scripts redes como estándar soportado en la ingeniería dirigida por modelos,” Master’s thesis, Universidad "Francisco José de Caldas", 2016. [14] T. Buchmann, A. Dotor, and B. Westfechtel, “Model-driven development of software configuration management systems - A case study in model- VII. C ONCLUSIONS & F UTURE W ORK driven engineering,” in Proc. of the 4th Intl. Conf. on Software and Data Technologies (ICSOFT), Volume 1. INSTICC Press, 2009, pp. 309–316. We experimented with a model-driven approach for system [15] H. Giese, A. Seibel, and T. Vogel, “A model-driven configuration management system for advanced it service management,” in Proc. of administration linking visualization and automation needs. A 4th Intl. Workshop on Models@run.time, vol. 509, 10 2009, pp. 61–70. domain-specific language (a UML profile of deployment dia- [16] S. Jácome and J. de Lara, “Controlling meta-model extensibility in grams) links hardware, software and configuration aspects of model-driven engineering,” IEEE Access, vol. 6, pp. 19 923–19 939, 2018. network infrastructure, and a model transformation generates [17] Object Management Group, “A uml profile for marte: Modeling and Puppet configuration scripts based on these models. analysis of real-time embedded systems,” 2015. [Online]. Available: A common language for the whole network configuration https://www.omg.org/omgmarte/ [18] A. C. F. da Silva, U. Breitenbücher, P. Hirmer, K. Képes, O. Kopp, simplifies the communication between members of a team, F. Leymann, B. Mitschang, and R. Steinke, “Internet of things out of the which reduces the problems associated with it. Moreover, the box: Using TOSCA for automating the deployment of iot environments,” use of a visual editor and a language with known semantics in Proc. of 7th Intl. Conf. CLOSER. SciTePress, 2017, pp. 330–339. [19] A. Delgado, “Qos modeling and automatic generation from soaml ser- (UML deployment diagrams) considerably reduces the access vice models for business process execution,” in 2015 IEEE International barrier to the use of configuration management systems. Conference on Services Computing, 2015, pp. 522–529. The proposal is currently being evaluated in a real context [20] A. Delgado and L. González, “Eclipse SoaML: A tool for engineering service oriented applications,” in Joint Proc. of the CAiSE 2014 Forum, associated with the management of the basic infrastructure ser. CEUR Workshop Proceedings, vol. 1164. CEUR-WS.org, 2014, configuration for electronic government. pp. 201–208. Although it is as exploratory work, it lays the foundations [21] G. S. Blair, N. Bencomo, and R. B. France, “Models@ run.time,” IEEE Computer, vol. 42, no. 10, pp. 22–27, 2009. for its application in a more general context of IoT. In this [22] T. Lodderstedt, D. Basin, and J. Doser, “SecureUML: A uml-based context, there are many open issues for its improvement, as modeling language for model-driven security,” in Proc. of Intl. Conf. presented in Sections III and VI, ranging from the extension on the Unified Modeling Language. Springer, 2002, pp. 426–441. of the language with the support of new components in an IoT environment and the definition of transformations to other configuration management tools and platforms, to the improve- 14