ModelViz: A Model-Driven Engineering Approach for Visual Analytics System Design

Visual analytics systems should be able to consolidate data from disparate sources, conduct exploratory analysis, create visualizations that suit different users, and integrate seamlessly with decision-making activities to support data-driven decision-making. However, current mainstream visual analytics solutions often lack support for all these requirements. To address this gap, we propose the use of model-driven engineering to design visual analytics systems. To demonstrate the feasibility of this approach, we developed a Domain-Specific Modeling Language (DSML) named ModelViz to design visual analytics systems for consumer goods supply chain applications. Furthermore, we present the work of our DSML, using data from a manufacturing company as a case study. Finally, we evaluated ModelViz quantitatively by comparing it with other similar works from the literature. Our results demonstrate that this approach meets the requirements and provides a promising direction for designing visual analytics systems by considering domain-specific aspects to help achieve business goals.


I. INTRODUCTION
In recent years, the information systems community has designed many Visual Analytics (VA) systems [1], [2], [3], [4], [5].However, they are either general-purpose systems that do not meet specific domain requirements or are tailored exclusively to one application area, making them unsuitable for other domains.
On the other hand, VA requires specific skills and knowledge to develop the most effective visualizations for specific application domain requirements.However, users are typically either application domain experts who lack beneficial skills for VA tasks, such as programming [6], or VA experts who lack the necessary domain knowledge [7], such as sales forecasting.In this context, an appropriate VA system should support various user groups with varying levels of The associate editor coordinating the review of this manuscript and approving it for publication was Asad Waqar Malik .
expertise.In addition, a successful VA may support various decision-making activities and align with the activity and goals of the application domain [8].This provides a goal-oriented VA that can contribute to improving the analytical results [9].
For example, supply chain VA includes conducting an exploratory analysis of data collected from heterogeneous data sources with the aim of supporting the business goals and decisions of various supply chain partners.Based on the study presented by Khakpour et al. [10], a VA system should be able to fulfill the following requirements: 1) The ability to streamline exploratory analysis, including unknown analytics tasks.2) Consolidating data from disparate sources, 3) Assisting with creating optimal visual encodings for diverse users, and 4) Integrating into decision-making activities to achieve relevant business objectives.
In general, data analysis can be categorized as either exploratory or directed [11].Exploratory analysis involves investigating data to gain insights that may not be apparent to data scientists [12].For instance, identifying hidden periodic patterns within data variables can help diagnose certain inconsistencies [13].On the other hand, directed analysis typically aims to answer known questions through data analytics, such as analyzing the sales data to understand the sales variations in a year.Direct analysis also includes examining data to prove some known beliefs, such as analyzing market data to show why adding a product feature increased customer satisfaction.This type of analysis is termed direct because the analyst has a hypothesis or answer in mind and seeks evidence in the data to support it.This involves examining how data change within specific variables of interest.The example of supply chain VA involves unknown exploratory analysis tasks, mainly due to uncertainties associated with the nature of the supply chain.For example, an unexpected social phenomenon can affect the flow of supply and may only be identified through exploratory analysis.Moreover, supply chain processes generate data through the work and collaboration of various partners, such as manufacturers, warehouses, distributors, and retailers.Therefore, data collected by various organizations should be gathered and consolidated for an effective VA.However, the nature of the data varies and each supply chain partner handles them differently.For example, retailers collect sales data from their customers' transactions and use it for sales forecasting [14].By contrast, warehouses collect data on products moving out from their facilities to make decisions regarding their warehouse locations [15].Therefore, supply chain VA should be flexible in collecting data from different sources and analyzing it for various purposes.
From a software engineering perspective, the process of designing a software system customized for a specific domain is referred to as domain engineering [16].In this regard, Domain-Specific Modeling Languages (DSML) are used to abstract domain knowledge when designing a software system to meet the specific needs of that domain.Simultaneously, this approach can be applied to other domains to develop similar systems.In this paper, we propose an approach to model-driven engineering that supports the development of domain-specific VA systems.In order to demonstrate the feasibility of this approach, we designed a prototype, called ModelViz.ModelViz is a graphical DSML based on the metamodeling technique that supports the development of a supply chain VA.For this purpose, we examined VA as a comprehensive modeling activity in which VA architects can create VA models for various supply chain applications.Moreover, we developed a graphical workbench as a tool to aid users in interacting with the DSML and creating VA dashboards without the need to write code.
In the remainder of this paper, we first present the background and related work of this study.We then present the methods used to implement our proposal.Subsequently, we introduce the tool that was created and demonstrate its usage through a case study.We will then evaluate the proposal by discussing how it meets the system requirements and a quantitative comparison with similar works from the literature.Finally, we conclude the study and discuss potential future research directions.

II. BACKGROUND AND RELATED WORK
In this section, we investigate previous utilizations of Model-driven Engineering (MDE) for VA applications.We also briefly explain what supply chain visual analytics means, which is the focus of our case studies.

A. MODEL-DRIVEN ENGINEERING FOR VISUAL ANALYTICS
In recent years, VA has been widely applied in various fields, and developers have utilized various techniques to create an optimal system for each specific application.For example, a study presented by González-Torres et al. [17] developed a VA system for software project management using a Javabased architecture.While the proposed system provided specific capabilities to end-users, changing user requirements necessitated extensive modifications of the architecture of the system.Logre and Déry-Pinna [18] proposed the use of MDE to facilitate the design of VA systems by employing Domain-Specific Languages (DSL) for modeling and prototyping.In order to support the designers in choosing the correct visualization, the authors proposed using the Software Product Line (SPL) paradigm.A feature model is created for each visualization type that guides the designer in choosing the relevant visuals based on the visualization library in use and the corresponding analytics concern.In our proposal, we have developed a catalog based on the developed framework for decision areas, visualization goals and tasks, and their corresponding visualization types.In this way, the analyst's thinking process, from the targeted decision area to the choice of data and visualization type, can be captured.
Smart cities are another application domain that utilize VA systems to leverage the potential of data.However, existing visualization systems often have a predefined set of capabilities developed based on the requirements gathered before system development [19], [20].This renders them unsuitable for similar domains.To address this issue, Rojas et al. [20] proposed a DSL for creating smart-city dashboards.This DSL can be utilized for any city by integrating domain concepts into the system-development process.
Despite its generality, this approach may not be suitable for other IoT applications that require domain-specific VA systems, such as industrial sensor analytics.To achieve this goal, Logre et al. [21] utilized DSLs to incorporate domain-specific variability and simplicity, thereby enhancing the reusability.Both of the proposed DSLs in [20] and [21] can only be used to create visualization dashboards for specific information and do not support the analytics activity.In our proposal, we provide a guide for analytics activity by integrating the decision-making process into the abstract syntax of the DSL.
In conclusion, previous attempts to use MDE for VA have focused on addressing only some of the challenges related to VA without considering the interconnectedness of these challenges.These attempts have addressed specific domain requirements to facilitate VA design or domain variability separately.However, there is still a gap in the literature regarding a comprehensive approach that considers all aspects of using an MDE for VA system design.This implies that there is a need for further research that considers all of these aspects to develop a more effective approach to using MDE for VA system design.

B. SUPPLY CHAIN VISUAL ANALYTICS
Supply chain activities are data rich and require an integrated VA system to fully leverage their data potential.For instance, supply chain partners in the fast-moving consumer goods industry, such as manufacturers, distributors, and retailers, generate and collect enormous amounts of data from their daily operations in production, logistics, and sales.These data contain hidden insights and information that are challenging to reveal without a proper VA system in place [10].
Moreover, to effectively relate and utilize the analysis in operations and decision support, the VA system should be customized and integrated to meet specific domain requirements [22].Previously, various studies have explored the application of VA in decision support systems for supply chain management [10].These studies often focus on specific application domains such as warehousing [23], manufacturing [24], and retail [25].Alternatively, they may explore generic VA systems, as presented by Bostock and Heer [1], and Satyanarayan et al. [5].In general, studies have considered three main aspects that a supply chain VA system tends to address: 1) business-driven analytics, 2) data handling, and 3) visualization recommendations.Therefore, we aimed to address these issues using a unified approach.
Moreover, data-driven decision-making is a timeconstrained task, and decision-makers must respond rapidly to different situations to have a sustainable business process [26].In this regard, Teruel et al. [26] suggest using goal-oriented decision-making based on business processes.Other previous works explored how VA can be used to support decision-making activities [27], [28].Our focus in this study is the integration of the decision-making process into the VA system development, which we discuss next.

III. METHODS AND MATERIALS
In this section, we first present the VA development framework, which serves as the basis for this study.We then discuss how we adapted the MDE approach as the methodology for our study.

A. VISUAL ANALYTICS DEVELOPMENT FRAMEWORK
In a recent study [29] regarding the development of VA systems, the authors argued that designing VA systems for decision support systems requires addressing the following significant questions: 1) What is the specific VA task, and how does it support a decision area?This question explores the connection between VA and business problems.2) What data is required, and where does this data come from?This question investigates the available data assets.3) What is the most suitable visualization design, and how can we effectively design it?This question identifies the technology to be used for creating visualizations.To address these questions, the authors propose a development framework for VA based on three distinct perspectives of the problem domain.They also suggested using an MDE methodology to implement these perspectives.Fig. 1 presents an overview of the framework that consists of different views:1) the Business View, 2) the Asset View, and 3) the Technology View.The Business View primarily focuses on answering the initial question by identifying the decision area that the VA aims to support, the specific VA task that aligns with the corresponding decision, and information goals.The Asset View addresses the second question by identifying the available data sources and finding a way to consolidate the required data from various sources.The Technology View deals with identifying the optimal visualization design for a given task and implementing it into a VA dashboard.
The MDE methodology addresses these views through multiple approaches, including, 1) characterizing and abstracting the decision areas, goals, and tasks of the VA, 2) incorporating data ingestion and VA design into the modeling activity, and 3) automating the design and implementation of a VA dashboard.In this case, we consider the VA system development framework as a blueprint or template for creating VA systems, and the MDE serves as an instantiation of the framework as it offers specific guidelines and practices for implementing it.

B. MODEL-DRIVEN ENGINEERING METHODOLOGY
MDE is an approach to system development that utilizes multiple layers of abstraction to facilitate the modeling of interactions between design logic and implementation [30].
We instantiated the MDE process and created a multi-layered approach for VA system development that begins with domain analysis to identify domain-specific concepts that form the basis for the design logic of the VA system.However, there is a significant gap between the high-level domain concepts that the domain experts use to define their requirements and the low-level VA tasks.Considering the dynamic nature of the requirements, it would be challenging to overcome this gap without a suitable method [31].MDE addresses this challenge by employing a modeling technique that facilitates the separation of domain concepts and the automatic generation of key system elements [32], such as visualization artifacts (in the case of using MDE for VA), directly from the models.
Adding to that, MDE approaches the VA as a modeling activity that provides the following advantages to the VA development: 1) Modeling VA provides guidance for VA development.
2) Using domain-specific modeling can create a balance between generalization and specificity.
3) The created VA model can be used as a way of describing the analytical activity for future traceability and communication.4) Metamodeling provides scalability for the VA system.
Scalability can be achieved by adding more domain elements to the decision-making catalog or adding more visual specifications to the visualization catalog.
In the first layer of the appraoch, the domain-specific concepts provide design logic to the next layer to guide VA design modeling.For example, if a specific decision area that the VA aims to support is a key concept, it can be incorporated into the VA design model.The VA design model provides guidance for design choices, such as selecting a bar chart for the dashboard, and it is implemented in the final layer using a specific programming language.By employing this multi-layered approach, we can develop VA systems that are customized to meet the specific requirements of the domain, leading to improved effectiveness and efficiency in system design.Fig. 2 depicts the adapted multi-layer approach.Fig. 3 demonstrates the process of VA dashboard development using the MDE.First, the metamodeling technique is used to characterize the domain elements, and a DSML is defined to provide the corresponding model notations.Domain analysis is the first step in defining the abstract syntax of DSML [33].On the other hand, a graphical modeling workbench was created based on visual modeling to simplify the interaction with the metamodel, serving as the concrete syntax of the DSML.The workbench simplifies the interaction with the metamodel for creating a Domain-Specific Model (DSM).Once a model is created, a model-to-text transformer is developed based on a code template to transform the DSMs into the source code of a dashboard.Finally, source codes were deployed using a deployment environment.In the following section, we demonstrate the implementation of this approach by creating a prototype version of a VA system.

IV. DESIGN OF MODELVIZ
In this section, we present an implementation of the above approach using a prototype called ModelViz.The prototype was used to evaluate the feasibility of the approach in a case study.Based on the presented method, the prototype includes the following four parts: 1. Metamodel, 2. Graphical Modeling workbench, 3. Model-to-text transformers and 4. Deployer.The source code for ModelViz is available in the GitHub repository [34].Next, we describe the implementation of the components.

A. METAMODEL
ModelViz contains a metamodel that is created based on captured concepts of the domain.The metamodel is created using class diagrams following the Ecore format of the Eclipse Modeling Framework (EMF) [35].Fowler [36] discussed the importance of perspectives when designing a model.He describes three modeling perspectives.Conceptual perspective that represents concepts within the domain.A specification perspective considers the type or interface of a class, whereas an implementation perspective manifests the implementation of a class.In what follows, we described the structure of the ModelViz metamodel considering these perspectives.Fig. 4 shows the proposed metamodel for a supply chain VA application.
Each class of the metamodel has a data-type catalog that provides a perspective on the specifications.Based on the previously described framework, the meta-model conceptually defines a dashboard based on three main classes: 1) A ''visualization class'' that describes the types of visual encodings and their specifications, such as mark and channel (or encoding) types, 2) A ''decision area class'' that describes the decision-making elements, including the decision area that the VA seeks to support, the visualization goal that the VA seeks to achieve, and the corresponding VA task that should be carried out in that regard, and 3) A ''data class'' that identifies the required data sources.
Every DecisionArea class can contain only one visualization ([1..1] bounds) that tends to achieve 1 to many ([1.. * ] bounds) visualization goals.That is, achieving different visualization goals through one visualization and supporting a single decision area.Following that, every visualization goal 42670 VOLUME 12, 2024 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.can contain 1 to many VATask, depicting that multiple VA tasks may need to be performed to achieve a single goal.The relation between the visualization class and data class is 1 to many, which provides the ability to have different data sources for different visualizations in a single dashboard.
The visualization specification catalogs, including Visual-FormatList, ChannelTypeList, FilterTypeList, VariableType-List, and AggregateTypeList are based on the Vega-lite visualization library.Vega-Lite provides a simple visualization grammar that simplifies the process of generating and deploying target dashboard source code [5].The Mark class has a catalog of visual types based on various visual formats implemented in Vega-Lite, such as bars, lines, and circle charts.The Encoding class is an instantiation of the visual properties of the marks through the channel class.Every mark class contains 2 to 4 encodings, given that each mark should have a minimum of two encoding channels, such as x and y, and a maximum of four encoding channels, including color and size.The Channel class defines the specifications of a channel, including the axis definitions, variable types, and variable aggregations and filterings.
Furthermore, the decision-making specification catalogs are based on a previous study in the supply chain VA domain [10].Various decision areas within supply chain activities fulfill the user variability requirements of a supply chain VA system.For example, sales management decision areas can provide insights into customer behavior that are useful for marketing departments.Similarly, demand management decision areas can help anticipate changes in demand patterns in the manufacturing planning department.Similarly, network integration and visibility decision areas can be utilized to offer real-time information on the status of products and shipments throughout the supply chain for the logistics department.A VA goal-type list defines various types of VA goals, such as identifying underlying patterns and exploring dimensions, to ensure a goal-oriented analysis.A VA task-type list provides various visualization tasks to assist with the exploratory analysis of unknown VA tasks.The decision-making catalog presented in [10] provides different goalTypes based on the decision area, and different taskTypes based on the goalType.Based on this, the four lists regarding the decision-making process and data collection, including DecisionAreaList, VAGoalTypeList, VATaskTypeList, and DataTypeList, are created.The authors in [10] conducted a study regarding the use of VA in supply chain analytics and provided different VA goals and tasks based on different decision areas of the supply chain environments.
These catalogs are not exhaustive and can be expanded.For the purpose of the prototype, we included a representative set of options only.

B. GRAPHICAL MODELING WORKBENCH
To simplify the modeling activity and enhance the interaction with the metamodel, we utilized Eclipse Sirius [37] and create a graphical DSL.Sirius is an open-source platform used to create a modeling workbench through which users can generate various VA models based on the metamodel.Fig. 5 shows the workbench.The workbench can be used to interact with the DSML to create a model.The workbench has four sections, numbered in Fig. 4, and is explained as follows.
1) The canvas allows users to easily drag and drop model entities from a palette located on the right side of the workbench.The palette also contained different sections for the tools.2) A section for creating dashboards where users can define the visualization frames, select a specific chart type, specify corresponding encodings, and select data sources.
3) The decision support tool offers a method for defining the decision-making process.It allows users to choose a decision area based on which the tool suggests a visualization goal and provides guidance for the visualization task.The tool uses a conditional branching logic based on the decision-making catalog to show the relevant goalTypes based on the user selection of decision area, and the corresponding taskTypes based on the selected goalType.The choices can be made in the property panel located under the canvas that will pop-up immediately after an element is created.4) Finally, a link tool helps specify the relationship between different model entities, such as the connection between a data source and a chart.
The tool provides a validation feature, where the user can check the conformance of the created model with the metamodel, and a small red cross mark by each of the model elements shows the errors.Additionally, there are well-formedness constraints that do not allow the user to create wrong models.For example, if the user wants to connect a database to a visualization frame instead of its corresponding visual encoding, the tool does not allow it.
Additionally, a brief description of each tool element is provided along with the tool in the documentation section of the workbench.The user sees the description of each component by hovering the mouse over their notations, which guides the user to work with the tool.

C. MODEL TO TEXT TRANSFORMER
After creating the model, users can simply right-click on the model and choose the ''Generate Dashboard Code'' button to create an HTML file containing a Vega-Lite specification for the target dashboard source code.The file can then be opened and viewed on a browser.Vega-Lite provides a high-level grammar that enables a specification for interactive data visualization.Vega-Lite grammar includes a unit specification that outlines an individual Cartesian plot, encompassing a corresponding dataset, a specified mark type, and a collection of one or more encoding definitions for visual channels like position (x, y), color, size, etc. [5].
To create the automatic code generation, a code template is created using the Eclipse Acceleo [38] code generator to con-  vert the model into source code.Acceleo is an open-source code generator development framework from the Eclipse Foundation that utilizes Object Constraint Language (OCL) to generate code templates.Fig. 6 shows a part of the code template function that generated visual marks JSON specification for the dashboard.

D. DEPLOYER
The generated code is an HTML file containing the Vega-Lite [5] JSON specification.Vega-Lite has a library called Vega-Embed, which makes it extremely simple to load Vega-Lite specifications into web-pages.For our prototype, we utilized this library to display our output dashboard on a web browser.The Sirius Workbench also has a built-in that can be used to view the dashboard alongside the created model.

V. DEMONSTRATION OF MODELVIZ: A CASE STUDY
In order to demonstrate the working and feasibility of Mod-elViz, we design a couple of case studies with a real-world company and the data from its business processes.The intended users of ModelViz for the following case studies are the domain expert analysts from the supply chain environment who have the knowledge of their domain data attributes and want to create VA for their decision support applications.In what follows, we refer to them simply as ''analysts.''

A. CASE STUDY DESIGN AND DATA
For the case study, we utilized the ModelViz prototype to provide decision support for a confectionery production company based in Norway.The company is part of a food supply chain that has collaboration with a number of retail stores across Norway.One of their most important datasets is Point-of-Sales (PoS) data that are collected from their partner retail chains.Additionally, they store their monthly sales to different stores along with information about each store in their business information system.We aggregated, cleaned and preprocessed these datasets in order to have one structured tabular data to use for visualization.The final dataset consist of more than 1.4 million rows corresponding to 3 years of product sales.Table 1 presents the aggregated attributes from different datasets along with their descriptions.To preserve confidentiality, we anonymized the name of the company and the partner retail stores from the data.
The case study consisted of two cases that were considered to demonstrate the feasibility of ModelViz.First, a case regarding sales management supports decisions related to sales, for example, during negotiations between a company's sales representatives and retail stores.Second is a production planning case that supports production decisions, such as prioritizing production orders based on customer demand volume.In the following section, we describe both cases in detail.

B. CASE 1: SALES MANAGEMENT
The company is interested in analyzing the data to understand its sales trends in different locations and periods.For this purpose, we used the prototype to design a dashboard to visualize sales data and conduct sales analytics to investigate 1) sales by store and 2) sales by region.
1) Sales by retail store: Sales by store refers to the number of sales made by each retail store that sells the company's product.Obtaining insights into this metric facilitates distinguishing key retailers with the highest sales within the market and can be used in negotiations with stores.In Norway, the company sells its products through various retail chains.The analyst must know the sales figures for each retail chain's product within a specific time frame.This information can be visualized in different time units.In this regard, we aim to visualize the data for retail sales performance on a monthly and weekday basis.2) Sales by region: Sales by region indicate the number of sales in various geographical locations.The data include sales at both municipality and county levels.These analytics can help the company determine where its product is selling best and plan its marketing efforts accordingly.The analyst uses county and municipality identification numbers to investigate the performance of the company in different counties and municipalities.
For this purpose, the user interacts with the designed metamodel and instantiates it with the help of the modeling workbench to create a dashboard model.Table 2 presents the instantiation of the metamodel for each case.
Based on these requirements, as depicted in Fig. 7, the decision area selected for the analysis is sales management (The green box).Next, the user must identify the goal of the analysis.Since the attempt is to analyze the correlation between the total amount of sales and various variables in the dataset (The green data source icon), among the various options provided in the properties section of the tool, user selects the VA goal (The blue box) of ''Finding the relation between data records.''Number of sales is a numerical variable, whereas retail chain names are categorical variables.Therefore, the appropriate VA task (The red box) would be ''Visualizing a categorical dimension against a numerical dimension.''Based on these selections, the tool suggests three different chart types: ''bar,'' ''line,'' and ''force-directed.''The user decides to utilize stacked bar charts for sales by store per month and a multi-series colored line chart to show the changes in sales during a weekday for various stores (The chart icons).Moreover, two stacked bar charts are used to 42674 VOLUME 12, 2024 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.visualize sales in each municipality and county.The analyst decides to filter the data to show the sum of total sales above 500 units in each municipality and 1000 units in each county to identify significant sales locations.The last column in Table 2 displays the channels (The yellow boxes) used for various dataset variables.
The model depicted in Fig. 7 was created based on the above instantiation.The model serves as a documentation of the entire design process.Once the model is created, we generate the target dashboard source code using the code generator command found in the menu items of tool.The generated code can then be opened in a browser that displays the output dashboard.Fig. 8 shows the dashboard generated for the sales analytics model depicted in Fig. 7.

C. CASE 2: PRODUCTION PLANNING
As mentioned, the company sells its products through retail stores in Norway.Three different analyses were performed for this purpose.1) top-selling customer segment, 2) individual product performance, and 3) correlation between sales and product unit prices.

1) Top-selling customer segment: The company aims to
analyze the demands of its top-selling customer segment and plan its production accordingly.The goal of the analyst is to analyze sales data by customer segment over time.This is known as time-dependent multivariate analysis and involves investigating the relationship between multiple variables that change over time.Additionally, identifying weekdays with the highest sales for high-selling products helps the production department plan their daily production.2) Individual product performance: Individual product performance can indicate best-selling products and prioritize resource allocation for production.The analyst uses the filter feature of the tool to identify products with sales above a certain limit, and demonstrates their sales performance.3) Correlation between sales and product unit price: The goal is to identify whether there is a correlation between total sales and the product unit price, such as products with higher unit prices that have higher total sales.For this purpose, the analyst uses the aggregate feature of the tool to calculate the average unit price for each product and observe the total sales of such products.
We want to demonstrate how ModelViz can be used to design a dashboard for these objectives.The process starts by selecting the decision area and obtaining suggestions for visualization goals and tasks.In addition, suitable chart types are suggested to the analysts.Finally, the target dashboard source code is created automatically and can be opened in a browser.Following the Fig. 10 (Analysis 1), to identify the top-selling customer segment, analyst: 1) Creates an instance of a decision area (The green box) and selects ''production planning and distribution'' as the decision area that needs to be supported.2) Uses the toolbox to add an instance of the visualization goal (The blue box) to the decision area and selects ''Exploring time-dependent multivariate data'' in the properties panel.3) Within the decision-making process, adds a visualization task (The red box) that suggests ''showing the dependency of an attribute on time.''4) In the next stage, the analyst creates a new visualization frame (The orange box).5) Adds the data source (The green data source icon) and selects the sales data as the data source.6) Associate it with the link to ingest the data (The dotted arrow).7) Eventually, a new chart is added to the frame (The chart icon).The tool suggests choosing from a variety of potentially useful chart types.One way to visualize time-dependent multivariate data is through stacked area charts.This type of chart allows for the visualization of total sales over time, broken down by different customer segments.The analyst then selects a stacked area chart.In addition, the analyst creates a stacked bar chart to show weekdays with the highest sales for product sales higher than 2000 units per weekday.8) Adds necessary channel encodings (The yellow boxes).
For the stacked area chart, the x-axis representing ''month,'' the y-axis representing ''total sales,'' and different retail store names represented by color encoding will be added.For the bar chart, the x-axis represents weekdays, the y-axis represents the total sales of products selling higher than 2000 units, and the color encoding will be different product identification numbers.
Following Fig. 10 (Analysis 2), the steps to observe the individual product performance will be as follows: 1) Creating a new instance of a decision area (The green Box) and selecting ''production planning and distribution'' as the decision area that needs to be supported.

2) Choosing ''Finding relations between data records''
for the visualization goal (The blue box).3) Adding a visualization task (The red box) that suggests ''Visualizing a categorical dimension against a numerical.''

4)
Adds a new chart (The chart icon) to the frame, and selects the circle chart from the suggested charts.5) Associates the chart with a link (The dotted line) to the data source.6) Adds the necessary channel encodings (The yellow boxes).The x-axis represents the ''sum of total sales'' for the products with sales higher than 5000 units, the y-axis represents ''average product unit price,'' and the color encoding represents different products.
Fig. 9 shows the final model created as a result of these steps in a screenshot of ModelViz.Finally, the analyst simply right-clicks on the model and chooses the generate code option that produces the visualization and can be opened in the browser, as shown in Fig. 10.Overall, ModelViz supported the decision-making process in the VA.As mentioned earlier, the aim was to support the user in the analytical process and to record this process for future reference.Next, we discuss how this approach satisfies the desired requirements.

VI. EVALUATION OF MODELVIZ
This study aimed to demonstrate the feasibility of the framework.Therefore, we developed a prototype to validate the framework by verifying whether the proposal meets the desired requirements.Prototyping is a well-known method for representing a system and validating it according to predefined requirements.Therefore, we begin by discussing the extent to which these requirements are met.Moreover, we conducted a comparative analysis of the developed prototype with some similar research prototypes from the literature.

A. DISCUSSION OVER REQUIREMENTS VALIDATION
At the beginning of this study, we identified four requirements that must be satisfied for the development of a VA system.Those requirements formed the basis for the three views of the VA development framework presented in [29] and Fig. 1.In order to support the three views, we proposed and developed a graphical DSML for designing VA systems using the metamodeling technique based on the requirements.Therefore, the metamodel consists of three main classes: 1) a visualization class that handles the visual encodings along with their relevant descriptions, such as marks and channels; 2) a decision class that supports the integration of the decision-making process into the VA activity, which consists of decision areas, VA goals, and VA tasks; and 3) a data class that handles data ingestion.We also conducted a case study with a confectionery manufacturing company.This case study demonstrates how sales and demand data can be utilized to create VA dashboards for sales management and production planning.The proposed system satisfies the design requirements by offering the following capabilities:

4) Integration with decision-making activities:
The decision-making process is integrated into the VA process, ensuring that the data analytics is aligned with the business objectives.
To conclude, the case study with the confectionery manufacturing company demonstrates how the system meets these requirements.The company utilized sales and demand data to generate tailored visualizations that effectively conveyed insights, aiding sales management and production planning decisions.Additionally, the modeling approach has been shown to be feasible in defining decision areas, VA goals, and VA tasks, ensuring that VA activity is aligned with the company's business goals.Overall, the case study demonstrates how the system's capabilities can be applied to real-world supply chain applications, streamlining the exploratory analysis process, and enabling informed decision-making.

B. QUANTITATIVE COMPARATIVE EVALUATION
ModelViz was developed using a DSL based on the metamodeling technique.To be efficient and useful, DSLs should be comprehensive and correlated with the corresponding domains.In this context, Guizzardi et al. [39] proposed a framework for evaluating the design of modeling languages by comparing their metamodel components with another reference language.The authors proposed four metrics for comparison of the metamodels.They argued that DSLs could be compared by their metamodels to check their truthfulness to the domain, as well as their pragmatic efficiency to support communication, understanding, and reasoning in the domain.
The four metrics are defined as follows: 1) Lucidity: A modeling language is lucid compared with a reference language if and only if there is a mapping between each concept of the model and at most one of the concepts within the other language.Lucidity was used to evaluate the clarity of the modeling language.Lucidity can be calculated as the number of concepts from the proposed DSL with only one equivalent concept in the reference language divided by the total number of concepts from the proposed DSL. 2) Soundness: A modeling language is sound compared with a reference language if and only if there is a mapping between every concept of the model and at least one of the concepts within the other language.Soundness checks the degree of correlation between the modeling language and the reference model.Soundness can be calculated as the number of concepts from the proposed DSL with at least one equivalent concept in the reference language divided by the total number of concepts from the proposed DSL. 3) Laconicity: A modeling language is laconic compared with a reference language if and only if there is a mapping between each concept of the reference model and at most one of the concepts of the modeling language.Laconicity checks how concise or redundant concepts are defined in the modeling language.Laconicity can be calculated as the number of concepts from the reference DSL with only one equivalent concept in the proposed language divided by the total number of concepts from the reference DSL. 4) Completeness: A modeling language is complete compared to a reference language if and only if there is a mapping between each concept of the reference language and at least one of the concepts of the modeling language.Completeness validates the expressiveness of the modeling language.Completeness can be calculated as the number of concepts from the reference DSL with at least one equivalent concept in the proposed language divided by the total number of concepts from the reference DSL.From the literature, there are three similar modeling languages, namely MetaViz [40], ReqViz [9], and Cities-Board [20], which can be used as reference languages.All three are modeling languages for VA, although they have different application domains.MetaViz is a generic modeling language used to create visualization dashboards.ReqViz is a modeling language for requirement-driven visualization, and the Cities-board is a modeling language for creating visualization dashboards for smart cities.In order to calculate the corresponding values for the metrics, we have reviewed all three DSLs along with the ModelViz and identified all of the concepts defined in each.The concepts were listed in an Excel document, and the values were calculated by counting the concepts based on the provided formulas for each metric definition.We first considered the main classes of the metamodels, and if a main class was not present, we also excluded all child classes.Table 3 presents the results of the analysis.
Although the proposal showed high soundness and laconicity, its lucidity and completeness were relatively low.The reason for this is the difference between the domains of the modeling languages.While MetaViz and ReqViz are used for generic VA, ModelViz is a prototype for the supply chain domain.Therefore, there is less focus on visualizationspecific concepts, such as the positioning of graphs on the screen or legends of axes.

VII. CONCLUSION AND FUTURE WORK
Data-driven decision-making involves the challenging task of conducting an exploratory visual analysis of the data generated and collected from various sources.For example, supply chain management encompasses a range of business activities and decision-making processes throughout the various stages of the chain, including procurement, manufacturing, warehousing, distribution, logistics, and retail.The amount of data generated and collected at each stage supports data-driven decision-making.The diversity of business activities within the supply chain makes VA a challenging task.To effectively support this task, VA systems should satisfy specific requirements.These requirements include the ability to conduct exploratory analysis, consolidate data from disparate sources, create visual encodings that suit different users, and integrate seamlessly with decision-making activities to achieve business objectives.
In this study, we proposed a graphical DSML, named ModelViz, to address the outlined requirements.Within the software engineering discipline, DSMLs utilize abstract domain concepts to develop software systems.We harness this potential to utilize supply chain domain concepts in the development of VA systems.In this way, abstract domain aspects simplify the design of a VA that aligns with business objectives and can be used by different users across a supply chain.Simultaneously, simplifying the creation of visual encodings for non-programmer domain experts can be achieved by treating the generation of VA dashboards as a modeling activity.Moreover, consolidation of data can be integrated into the VA design process by incorporating it as a component of the model.
In this regard, a metamodel for VA development includes classes related to both automated dashboard creation and decision-making.The metamodel is then used as an abstract syntax for DSML.Furthermore, a graphical workbench tool simplifies the interaction with the metamodel and facilitates the creation of dashboards through graphical modeling.We utilized various Eclipse software tools, including Ecore, Sirius, and Acceleo, at different stages of the process, which facilitated the implementation of DSML.Consequently, users can use the metamodel concept to generate VA dashboards.
To present our proposal better, we conducted a case study involving the development of a dashboard for sales management and production planning in a confectionery production company.The focal company is part of a Norwegian fast-moving consumer goods supply chain and owns the necessary data for our analysis.As a result, the tool simplifies the interaction with the metamodel and uses various domain concepts to create a goal-oriented VA dashboard.
Finally, after validating ModelViz for the desired requirements, we evaluated the proposed DSML by comparing it with three similar modeling languages from the literature.These evaluation results can be used to improve ModelViz in later versions.Based on the evaluation results presented in Section VI-B., although the proposed DSL demonstrates soundness and lanconicity, it requires improvements regarding its completeness and lucidity.We argued that since ModelViz is a prototype for the supply chain domain, we had less focus on the design of visual encodings.Therefore, future versions of ModelViz can be improved in terms of these concepts, such as the positioning of graphs on the screen or customizing the legends based on user needs.Additionally, to improve ModelViz in terms of laconicity or the clarity of the DSL, we can create new classes from the attributes of some of the defined classes.For example, the attribute ''filterType'' from the ''channelType'' class can be separated and form a new class.This will add to the clarity of the ModelViz in later versions.
For future work, we plan to conduct a validation study with the help of experts to verify the applicability and validity of both the metamodel and tool.The tool was developed as a research prototype and may not include all the necessary functionalities for usability testing.However, validating the metamodel helps to verify the coherence between the metamodel and the graphical tool.Additionally, future work can include a long-term user study to explore user experience and performance evaluation of the method.Moreover, although the objective of the ModelViz prototype was to demonstrate the applicability of the proposed framework, future work can explore adding new features regarding its analytics capabilities.In this regard, machine learning based predictive analytics can provide the support for advanced analytics.
ModelViz was developed based on a domain-specific approach focused on the supply chain domain.Nevertheless, the approach can be used for different application domains as an area for future work to examine its generalizability.Finnaly, the system should be employed in a real-world setting to inspect its ability to integrate with other business intelligence systems.We believe that this method can be further developed into a fully functional application that will be useful for supply chain partners, facilitating their decision-making activities with the help of VA.

FIGURE 2 .
FIGURE 2.Multi-layer approach for VA system design.

FIGURE 3 .
FIGURE 3. Process of VA dashboard development using MDE.

FIGURE 5 .
FIGURE 5. Sirius workbench for the graphical domain-specific language.

FIGURE 6 .
FIGURE 6. Main function of the model to JSON code template.

FIGURE 7 .
FIGURE 7.Sales VA dashboard model within the workbench.

4 )
Adding a new chart (The chart icon) to the frame and selecting the bar charts based on the suggested charts.5) Associating the chart with a link (The dotted arrow) to the data source to ingest the data.6) Adding the necessary channel encodings (The yellow boxes).The x-axis represents ''ProductID'' and the y-axis represents ''total sales.''Finally, following Fig. 10 (Analysis 3), to identify the correlation between sales and product unit price the analyst, 1) Creates a new instance of a decision area (The green Box) and selects ''production planning and distribution'' as the decision area that needs to be supported.2) Chooses ''Finding relations between data records'' for the visualization goal (The blue box).3) Adds a visualization task (The red box) that suggests ''Visualizing two numerical dimensions.''

FIGURE 8 .
FIGURE 8. Generated sales management dashboard from the model in Fig. 7.

FIGURE 10 .
FIGURE 10.Generated production planning dashboard from the model in Fig. 9.

TABLE 1 .
Aggregated data attributes from different datasets.

TABLE 2 .
Instantiation of the metamodel for the case study.

TABLE 3 .
Results of the quantitative comparison.