## 3 Materials and Methods  
### Metamodeling  
The model-driven development (MDD) paradigm [15; 37] enables the abstraction of the requirements involved in the development process of information systems, moving both data and operations specifications away from concrete and lower-level details. The main benefit of abstracting these details is to obtain a meta-model that holds a set of structures and rules shared by any system from the modeled domain. In other words, the meta-model can be employed to drive the development of different systems by instantiating abstract features into specific features. This methodology increases the reuse of components (thus, decreasing the development time), but also the reuse of knowledge because the structures and relationships identified during the development of the meta-model can evolve to obtain better solutions. The Object Management Group (OMG) proposes the model-driven architecture (MDA) as a guideline to implement the MDD approach. This architecture provides a framework for software development in which the process is driven by models that describe and define the target system [38]. The main difference between MDD and MDA is that MDA determines a set of standards to develop the approach, such as meta-object facility (MOF), unified modeling language (UML), XML (Extensible Markup Language) metadata interchange (XMI), and query/view/transformation (QVT). The dashboard meta-model is also part of the four-layer meta-model architecture proposed by the OMG, in which a model at one layer is used to specify models in the layer below [39]. In particular, the first version of the dashboard meta-model [20] was an instance of MOF (i.e., an M2-model), so it can be instantiated to obtain M1-models. This meta-model was transformed in an instance of Ecore [40] using Graphical Modelling for Ecore included in Eclipse Modeling Framework (EMF), in order to leverage the different features of this modeling framework (Figure 1). This meta-model was developed using a domain engineering approach [41; 42], in which similarities and variability points were identified to obtain an abstract picture of the dashboards' domain in terms of these tools' elements and features. The goal of the dashboard meta-model is to develop and deploy information dashboards in a variety of real-world contexts. Figure 2 shows a reduced version of the mentioned dashboard meta-model, which can be decomposed in three main elements: the user, the layout, and the components. Figure 3 shows the detailed view of the components' section that was omitted in Figure 2 due to legibility reasons (the whole high-resolution meta-model is available at [[https://doi.org/10.5281/zenodo.3561320](https://doi.org/10.5281/zenodo.3561320)]([https://doi.org/10.5281/zenodo.3561320](https://doi.org/10.5281/zenodo.3561320))). As can be seen, the dashboard is composed of different pages, which, in turn, is composed of a set of containers that can be organized in rows and columns. These containers hold the dashboard components. Figure 1: Location of the dashboard meta-model following the OMG architecture. Figure 2: Overview of the dashboard meta-model, including the user, the layout, and the components. This image is available in high resolution at [[https://doi.org/10.5281/zenodo.3561320](https://doi.org/10.5281/zenodo.3561320)]([https://doi.org/10.5281/zenodo.3561320](https://doi.org/10.5281/zenodo.3561320)). Licensed under CC BY 4.0. On the other hand, the user is modeled as an entity with two main elements that define her behavior: goals and characteristics. Goals refer to the purposes of the user regarding the displayed data, and they can be broken down into different lower-level analytic tasks that must be supported by the dashboard components in order to reach the identified goals. Finally, users have different characteristics that also influence the components that form the dashboard. These characteristics include preferences, disabilities, knowledge about the data domain, visualization literacy (or graphicacy [8]), and bias.