=Paper=
{{Paper
|id=Vol-2442/paper2
|storemode=property
|title=A Model-Driven Approach for System Administration
|pdfUrl=https://ceur-ws.org/Vol-2442/paper2.pdf
|volume=Vol-2442
|authors=Marco Centurión,Maximiliano Kotvinsky,Daniel Calegari,Andrea Delgado
|dblpUrl=https://dblp.org/rec/conf/models/CenturionKCD19
}}
==A Model-Driven Approach for System Administration==
https://ceur-ws.org/Vol-2442/paper2.pdf
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