## 3 Materials and Methods  
### Metamodeling  
Metamodeling is the backbone methodology from the model-driven development (MDD) paradigm [30; 31]. This paradigm enables the abstraction of the systems' development process's requirements, providing support for moving both data and operations specifications away from lower-level details.  
By abstracting these details, it can be possible to obtain a generic \"skeleton\" of information systems, containing the main structures and relationships among its high-levelcomponents. Meta-models are very useful resources to understand the systems' domain because they ease the identification process of relevant features within the context, separating these features from technical details or specific technologies.  
This methodology increases the reusability of components (thus, decreasing the development time) and the reusability of knowledge because the structures and relationships identified within the systems' domain can evolve to obtain better solutions when instantiating the meta-model.  
The MDD approach can be implemented through the model-driven architecture (MDA), a guideline proposed by the Object Management Group (OMG). This guideline provides an architecture for software development driven by models describing and defining the target system [32]. The OMG proposal also 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).  
In this case, the proposed dashboard meta-model is part of this meta-model architecture proposal [33]. Although the first version of the dashboard meta-model [34; 35] was an instance of MOF, it was finally transformed into an instance of Ecore [36] using Graphical Modelling for Ecore included in Eclipse Modeling Framework (EMF) (Figure 1).  
The transformations between the M2 and M1 levels are currently performed through manual processes: it is necessary to select and define the dashboard configuration manually; however, we are working on automating this process through artificial intelligence (AI) approaches. In [37], we explore this AI-based automation theoretically, and we plan to connect this approach with the M1-to-M0 transformations.  
Figure 1: Location of the dashboard meta-model following the Object Management Group (OMG) architecture. The dashboard generator is in charge of transforming the meta-models’ instances (M1 models) in specific dashboard implementations.  
The M2 meta-model provides the basis to instantiate dashboards in different contexts and domains, and these models will be ultimately implemented as specific dashboards. This transition between this M1 model and the M0 model can be done automatically through the dashboard generator service, which complies with the M2 meta-model's structure and features.  
As seen in the dashboard meta-model, these tools are composed of different sections or aspects, such as the layout, operations, visual marks and even the audience characterization. To adapt this model to an ecosystem proposal, we have divided the sections of the meta-model into the main tasks that can be found during a dashboard design process (user characterization, data transformations, data encoding and visualization design). Separating these phases into services could support the definition of a dashboard design pipeline.