diff --git a/experiment.tex b/experiment.tex index b08ff5f..51e3a4c 100644 --- a/experiment.tex +++ b/experiment.tex @@ -5,10 +5,10 @@ % \cref{subsec:experiments_infrastructure} presents the simulator and testing infrastructure adopted in our experiments, as well as the complete experimental settings; \cref{subsec:experiments_performance} analyses the performance of our solution in terms of execution time; \cref{subsec:experiments_quality} presents the quality of our heuristic algorithm in terms of the metrics in \cref{subsec:metrics}. % \subsection{Testing Infrastructure and Experimental Settings}\label{subsec:experiments_infrastructure} -% Our testing infrastructure is a Swift-based simulator of a service-based ecosystem, including service execution, comparison, and composition. The simulator first defines the pipeline template as a sequence of nodes in the range \hl{x-y}. We recall that alternative nodes are modeled in different pipeline templates, while parallel nodes only add a fixed execution time that is negligible and do not affect the quality of our approach. Each node is associated with a (set of) policy with transformations varying in three classes: \hl{a,b,c}. A set of functionally-equivalent candidate services is randomly generated, each service having a profile...\hl{to conclude}. -% Upon setting up the pipeline template, the sliding window size is configured and our methodology for pipeline instance generation starts. %The simulator selects a subset of nodes along with their corresponding candidate services. -% The simulator calculates all possible pipeline instances, that is, it instantiates all nodes with a service according to the selected window size. For each node, the simulator calculates a quality metric, selecting the first service from the optimal combination in the sliding window, then shifting the window by step 1. -% When the end of the node list is reached, or when the window size equals the node count, the simulator computes the optimal service combination for the remaining nodes and the pipeline instance is generated. +% Our testing infrastructure is a Swift-based simulator of a service-based ecosystem, including service execution, comparison, and composition. The simulator first defines the pipeline template as a sequence of vertexes in the range \hl{x-y}. We recall that alternative vertexes are modeled in different pipeline templates, while parallel vertexes only add a fixed execution time that is negligible and do not affect the quality of our approach. Each node is associated with a (set of) policy with transformations varying in three classes: \hl{a,b,c}. A set of functionally-equivalent candidate services is randomly generated, each service having a profile...\hl{to conclude}. +% Upon setting up the pipeline template, the sliding window size is configured and our methodology for pipeline instance generation starts. %The simulator selects a subset of vertexes along with their corresponding candidate services. +% The simulator calculates all possible pipeline instances, that is, it instantiates all vertexes with a service according to the selected window size. For each node, the simulator calculates a quality metric, selecting the first service from the optimal combination in the sliding window, then shifting the window by step 1. +% When the end of the node list is reached, or when the window size equals the node count, the simulator computes the optimal service combination for the remaining vertexes and the pipeline instance is generated. % \hl{NON MI E' CHIARISSIMA To ensure that each service is interdependent within a combination, a hash function is employed. This function generates weights that services use to simulate transformations (data removal) mandated by the specified policies.} % ======= @@ -20,11 +20,27 @@ \subsection{Testing Infrastructure and Experimental Settings}\label{subsec:experiments_infrastructure} Our testing infrastructure is a Swift-based simulator of a service-based ecosystem, including service execution, comparison, and composition. -Upon setting the sliding window size, the simulator selects a subset of nodes along with their corresponding candidate services. -It then generates all possible service combinations for the chosen nodes. +The simulator first defines the pipeline template as a sequence of vertexes in the range $3-7$. +We recall that alternative vertexes are modeled in different pipeline templates, +while parallel vertexes only add a fixed execution time that is negligible and do not affect the quality of our approach. +Each node is associated with a (set of) policy with transformations varying in three classes: + +\begin{itemize*}[label=roman*] + \item \textit{Confident}: Adjusts data removal to a percentage within $[0.8,1]$. + \item \textit{Diffident}: Sets data removal percentage to $[0.2,0.5]$. + \item \textit{Average}: Modifies data removal percentage within $[0.2,1]$. +\end{itemize*} +set of functionally-equivalent candidate services is randomly generated. + +Upon setting the sliding window size, the simulator selects a subset of vertexes along with their corresponding candidate services. +It then generates all possible service combinations for the chosen vertexes. For each combination, the simulator calculates a metric, selecting the first service from the optimal combination before shifting the sliding window. -When the end of the node list is reached, or when the window size equals the node count, the simulator computes the optimal service combination for the remaining nodes. -To ensure that each service is interdependent within a combination, a hash function is employed. This function generates weights that services use to simulate data removal due to an anonymization process. +When the end of the node list is reached, or when the window size equals the node count, the simulator computes the optimal service combination for the remaining vertexes. + +An hash function is to simulate the natural interdependence between services. +This is particularly important when the removal of data by one service may impact another. +By assigning weights to the services using this function, the system aims to reflect the interconnected dynamics among the services. + The simulator is used to assess the performance and quality of our sliding window heuristic in Section \ref{sec:heuristics} for the generation of the best pipeline instance (Section \ref{sec:instance}). % Performance measures the heuristics execution time in different settings, while quality compares the results provided by our heuristics in terms of selected services with the optimal solution retrieved using the exhaustive approach. %We note that the exhaustive approach generates the best pipeline instance by executing all possible combinations of candidate services. @@ -106,16 +122,16 @@ \subsection{Perfomance}\label{subsec:experiments_performance} % \end{itemize} % \subsection{Metriche/Euristiche} We first calculated the execution time required by our exhaustive solution. -We incrementally varied the number of nodes and the number of services per node. +We incrementally varied the number of vertexes and the number of services per node. The results of these evaluations are presented in \cref{fig:perf_exhaustive}. As anticipated, the trend in execution times is exponential. \cref{fig:perf_exhaustive} displays the execution time plots, -clearly showing that as the number of nodes increases, the execution time grows exponentially. -Execution times for up to 5 nodes and 6 services were computed directly, +clearly showing that as the number of vertexes increases, the execution time grows exponentially. +Execution times for up to 5 vertexes and 6 services were computed directly, while the remaining data points were obtained through interpolation. Subsequently, the logical extension of this empirical inquiry involves evaluating the execution time efficiency attributable to the implementation of the sliding window heuristic. We then evaluated our heuristics to quantify the execution time reduction achieved through the application of heuristics. -In this context, the number of nodes and services per node was incrementally increased, +In this context, the number of vertexes and services per node was incrementally increased, with the addition of a sliding window whose size was progressively enlarged in each experiment. The outcomes are depicted in \cref{fig:perf_window}, and as expected, we observed a marked reduction in execution times with the implementation of the sliding window heuristic. @@ -126,7 +142,7 @@ \subsection{Perfomance}\label{subsec:experiments_performance} \subsection{Quality}\label{subsec:experiments_quality} -We finally evaluated the quality of our heuristic comparing, where possible, its results with the optimal solution retrieved by executing the exhaustive approach. The latter executes with window size equals to the number of nodes and provides the best, among all possible, solution. +We finally evaluated the quality of our heuristic comparing, where possible, its results with the optimal solution retrieved by executing the exhaustive approach. The latter executes with window size equals to the number of vertexes and provides the best, among all possible, solution. We recall that we considered three different setting, confident, diffident, average, varying the policy transformations, that is, the amount of data removal at each node. Setting confident assigns to each policy a transformation that changes the amount of data removal in the interval [x,y] (Jaccard coefficient) or decreases the probability distribution dissimilarity in the interval [x,y] (Jensen-Shannon Divergence). Setting diffident assigns to each policy a transformation that changes the amount of data removal in the interval [x,y] (Jaccard coefficient) or decreases the probability distribution dissimilarity in the interval [x,y] (Jensen-Shannon Divergence). Setting average assigns to each policy a transformation that changes the amount of data removal in the interval [x,y] (Jaccard coefficient) or decreases the probability distribution dissimilarity in the interval [x,y] (Jensen-Shannon Divergence). We finally evaluated the quality of our heuristic comparing, where possible, @@ -134,7 +150,7 @@ \subsection{Quality}\label{subsec:experiments_quality} The latter executes with window size equals to the number of services per node and provides the best, among all possible, solution. -The number of nodes has been varied from 3 to 7, while the number of services per node has been set from 2 to 6. +The number of vertexes has been varied from 3 to 7, while the number of services per node has been set from 2 to 6. The experiments have been conducted with different service data pruning profiles. % \hl{DOBBIAMO SPIEGARE COSA ABBIAMO VARIATO NEGLI ESPERIMENTI E COME, WINDOW SIZE, NODI, ETC. @@ -142,9 +158,9 @@ \subsection{Quality}\label{subsec:experiments_quality} % LE IMMAGINI CHE ABBIAMO SONO SOLO QUELLE 5? POSSIAMO ANCHE INVERTIRE GLI ASSI E AGGIUNGERE VISUALI DIVERSE} % <<<<<<< HEAD -% \cref{fig:quality_window} presents our results with setting \hl{confident} and metric Jaccard coefficient. \cref{fig:quality_window}(a)--(e) \hl{aggiungere le lettere e uniformare l'asse y} present the retrieved quality varying the number of nodes in [3, 7], respectively. Each figure in \cref{fig:quality_window}(a)--(e) varies the number of candidate services at each node in the range [2, 6] and the window size W in the range [1, $|$nodes$|$]. +% \cref{fig:quality_window} presents our results with setting \hl{confident} and metric Jaccard coefficient. \cref{fig:quality_window}(a)--(e) \hl{aggiungere le lettere e uniformare l'asse y} present the retrieved quality varying the number of vertexes in [3, 7], respectively. Each figure in \cref{fig:quality_window}(a)--(e) varies the number of candidate services at each node in the range [2, 6] and the window size W in the range [1, $|$vertexes$|$]. % \hl{aggiungiamo i numeri piu significativi (asse y).} -% From the results, some clear trends emerge. As the number of nodes increases, the metric values tend to decrease (better data quality) as the window size increases across different node configurations. +% From the results, some clear trends emerge. As the number of vertexes increases, the metric values tend to decrease (better data quality) as the window size increases across different node configurations. % This suggests that the heuristic performs better when it has a broader perspective of the data and services. The trend is consistent across all node cardinalities (from three to seven), indicating that the heuristic's enhanced performance with larger window sizes is not confined to a specific setup but rather a general characteristic of its behavior. % Finally, the data suggest that while larger window sizes generally lead to better performance, % there might exist a point where the balance between window size and performance is optimized. \hl{For instance, ...} @@ -173,7 +189,7 @@ \subsection{Quality}\label{subsec:experiments_quality} % \end{figure} %======= \cref{fig:quality_window} presents our results -In the figure each chart represents a configuration with a specific number of nodes, ranging from 3 to 7. +In the figure each chart represents a configuration with a specific number of vertexes, ranging from 3 to 7. On the x-axis of each chart, the number of services is plotted, which ranges from 2 to 6. The y-axis represents the metric value, which varies across the charts. Each chart shows different window sizes, labeled as W Size 1, W Size 2, and so on, corresponding to various metric values. @@ -189,10 +205,10 @@ \subsection{Quality}\label{subsec:experiments_quality} Lastly, the fifth chart, presenting a 7-node configuration, indicates that metric values start at 0.28 and reduce to 0.10 as the number of services escalates. The difference in metric values for a window size of one is pronounced, while values for window sizes three to six are lower, with overlapping occurrences similar to those in the 6-node setup. Metric values for window sizes two and three fluctuate between 0.25 and 0.12, while those for window sizes four and five oscillate between 0.22 and 0.1. It's worth noting -As the number of nodes increases in each subsequent chart, the relationship between the window size and metric value is depicted, +As the number of vertexes increases in each subsequent chart, the relationship between the window size and metric value is depicted, showing how metric values tend to decrease (better data preservation) as the window size increases across different node configurations. This suggests that the heuristic performs better when it has a broader perspective of the data it is analyzing. -The trend is consistent across various numbers of nodes, from three to seven, indicating that the heuristic's enhanced +The trend is consistent across various numbers of vertexes, from three to seven, indicating that the heuristic's enhanced performance with larger window sizes is not confined to a specific setup but rather a general characteristic of its behavior. Finally, the data suggest that while larger window sizes generally lead to better performance, there might exist a point where the balance between window size and performance is optimized. diff --git a/main.pdf b/main.pdf index e0d327e..b9ba2f5 100644 Binary files a/main.pdf and b/main.pdf differ diff --git a/metrics.tex b/metrics.tex index 93dd3fe..6dd2c75 100644 --- a/metrics.tex +++ b/metrics.tex @@ -2,7 +2,7 @@ \section{Maximizing the Pipeline Instance Quality}\label{sec:heuristics} % % %Ovviamente non รจ sufficiente scegliere il best service per ogni vertice, ma diventa un problema complesso dove si devono calcolare/valutare tutte le possibili combinazioni dei servizi disponibili, tra le quali scegliere la migliore. Our goal is to generate a pipeline instance with maximum quality, which addresses data protection requirements with the minimum amount of information loss across the pipeline execution. To this aim, we first discuss the role of some metrics (\cref{sec:metrics}) to specify and measure data quality, and describe the ones used in the paper. -Then, we prove that the problem of generating a pipeline instance with maximum quality is NP-hard (\cref{sec:nphard}). Finally, we present a parametric heuristic (\cref{subsec:heuristics}) tailored to address the computational complexity associated with enumerating all possible combinations within a given set. The primary aim of the heuristic is to approximate the optimal path for service interactions and transformations, particularly within the landscape of more complex pipelines composed of numerous nodes and candidate services. Our focus extends beyond identifying optimal combinations, encompassing an understanding of the quality changes introduced during the transformation processes. +Then, we prove that the problem of generating a pipeline instance with maximum quality is NP-hard (\cref{sec:nphard}). Finally, we present a parametric heuristic (\cref{subsec:heuristics}) tailored to address the computational complexity associated with enumerating all possible combinations within a given set. The primary aim of the heuristic is to approximate the optimal path for service interactions and transformations, particularly within the landscape of more complex pipelines composed of numerous vertexes and candidate services. Our focus extends beyond identifying optimal combinations, encompassing an understanding of the quality changes introduced during the transformation processes. %Inspired by existing literature, these metrics, categorized as quantitative and statistical, play a pivotal role in quantifying the impact of policy-driven transformations on the original dataset. @@ -92,7 +92,7 @@ \subsection{NP-Hardness of the Max Quality Pipeline Instantiation Process}\label %The computational challenge posed by the enumeration of all possible combinations within a given set is a well-established NP-hard problem.} %The exhaustive exploration of such combinations swiftly becomes impractical in terms of computational time and resources, particularly when dealing with the analysis of complex pipelines. %In response to this computational complexity, the incorporation of heuristic emerges as a strategy to try to efficiently address the problem. - \hl{HO RIVISTO IL PARAGRAFO VELOCEMENTE GIUSTO PER DARE UN'INDICAZIONE. DOBBIAMO USARE LA FORMALIZZAZIONE E MAGARI FORMALIZZARE ANCHE LO PSEUDOCODICE.} We design and implement a heuristic algorithm for computing the pipeline instance maximizing data quality. Our heuristic is built on a \emph{sliding window} and aims to minimize information loss according to quality metrics. At each step, a set of nodes in the pipeline template $\tChartFunction$ is selected according to a specific window w=[i,j], where $i$ and $j$ are the starting and ending depth of window w. Service filtering and selection in Section~\ref{sec:instance} are then executed to minimize information loss in window w. The heuristic returns as output the list of services instantiating nodes at depth $i$. A new window w=[i+1,j+1] is considered until $j$+1 is equal to the max depth of $\tChartFunction$, that is the window reaches the end of the template. + \hl{HO RIVISTO IL PARAGRAFO VELOCEMENTE GIUSTO PER DARE UN'INDICAZIONE. DOBBIAMO USARE LA FORMALIZZAZIONE E MAGARI FORMALIZZARE ANCHE LO PSEUDOCODICE.} We design and implement a heuristic algorithm for computing the pipeline instance maximizing data quality. Our heuristic is built on a \emph{sliding window} and aims to minimize information loss according to quality metrics. At each step, a set of vertexes in the pipeline template $\tChartFunction$ is selected according to a specific window w=[i,j], where $i$ and $j$ are the starting and ending depth of window w. Service filtering and selection in Section~\ref{sec:instance} are then executed to minimize information loss in window w. The heuristic returns as output the list of services instantiating vertexes at depth $i$. A new window w=[i+1,j+1] is considered until $j$+1 is equal to the max depth of $\tChartFunction$, that is the window reaches the end of the template. %For example, in our service selection problem where the quantity of information lost needs to be minimized, the sliding window algorithm can be used to select services composition that have the lowest information loss within a fixed-size window. This strategy ensures that only services with low information loss are selected at each step, minimizing the overall information loss. Pseudo-code for the sliding window algorithm is presented in Algorithm 1. @@ -147,9 +147,9 @@ \subsection{NP-Hardness of the Max Quality Pipeline Instantiation Process}\label \end{lstlisting} -The pseudocode implemets function {\em SlidingWindowHeuristic}, which takes a sequence of nodes and a window size as input and returns a set of selected nodes as output. The function starts by initializing an empty set of selected nodes (line 3). Then, for each node in the sequence (lines 4--12), the algorithm iterates over the nodes in the window (lines 7--11) and selects the node with the lowest metric value (lines 9-11). The selected node is then added to the set of selected nodes (line 12). Finally, the set of selected nodes is returned as output (line 13). +The pseudocode implemets function {\em SlidingWindowHeuristic}, which takes a sequence of vertexes and a window size as input and returns a set of selected vertexes as output. The function starts by initializing an empty set of selected vertexes (line 3). Then, for each node in the sequence (lines 4--12), the algorithm iterates over the vertexes in the window (lines 7--11) and selects the node with the lowest metric value (lines 9-11). The selected node is then added to the set of selected vertexes (line 12). Finally, the set of selected vertexes is returned as output (line 13). -We note that a window of size 1 corresponds to the \emph{greedy} approach, while a window of size N, where N represents the total number of nodes, corresponds to the \emph{exhaustive} method. +We note that a window of size 1 corresponds to the \emph{greedy} approach, while a window of size N, where N represents the total number of vertexes, corresponds to the \emph{exhaustive} method. The utilization of heuristic in service selection can be enhanced through the incorporation of techniques derived from other algorithms, such as Ant Colony Optimization or Tabu Search. By integrating these approaches, it becomes feasible to achieve a more effective and efficient selection of services, with a specific focus on eliminating paths that have previously been deemed unfavorable. diff --git a/motivations.tex b/motivations.tex index d7e761a..0688101 100644 --- a/motivations.tex +++ b/motivations.tex @@ -41,4 +41,4 @@ \subsection{Data Processing} Deep Learning copes well with the distribution of computations reaching excellent performances thanks to the work done in the parallelization of machine learning processing \cite{verbraeken2020survey, Goodfellow-et-al-2016,wu2022survey}. At the same time, substantial research and development effort has been put on the infrastructures supporting data analysis, which underwent a gradual evolution starting from a monolithic model towards a model based on micro and nano services \cite{kratzke2018brief}. The spread of the cloud computing and containerized systems allowed these systems to be more resilient, easier to develop, and adaptive, while increasing their complexity.\footnote{Today the Apache big data ecosystem counts more than 50 tools.} -With the spread of big data, new tools and infrastructures have been developed for data ingestion, storage, and analysis. The main challenge to be addressed was the inability for a single system to handle such huge amount of data; this resulted in the spread of solutions based on a distributed file system \cite{blomer2015survey}, a system that permits to share data across multiple machines (made in general of commodity hardware), making possible for the user to read and write data without perceiving this distribution. Over the years these systems have seen more and more refinements and expansions, such as, resource managers to manage the distribution of resources in the network of nodes (YARN) \cite{kulkarni2014survey}, SQL-Like systems that support access following standard RDBMS (HIVE, Presto, Trino) \cite{thusoo2009hive,sethi2019presto}. Finally, other software components (for example Apache Spark \cite{salloum2016big}) have been created to meet the ever increasing needs for data access and analysis requested by machine learning technologies. +With the spread of big data, new tools and infrastructures have been developed for data ingestion, storage, and analysis. The main challenge to be addressed was the inability for a single system to handle such huge amount of data; this resulted in the spread of solutions based on a distributed file system \cite{blomer2015survey}, a system that permits to share data across multiple machines (made in general of commodity hardware), making possible for the user to read and write data without perceiving this distribution. Over the years these systems have seen more and more refinements and expansions, such as, resource managers to manage the distribution of resources in the network of vertexes (YARN) \cite{kulkarni2014survey}, SQL-Like systems that support access following standard RDBMS (HIVE, Presto, Trino) \cite{thusoo2009hive,sethi2019presto}. Finally, other software components (for example Apache Spark \cite{salloum2016big}) have been created to meet the ever increasing needs for data access and analysis requested by machine learning technologies. diff --git a/pipeline_instance.tex b/pipeline_instance.tex index 9467430..5feda75 100644 --- a/pipeline_instance.tex +++ b/pipeline_instance.tex @@ -35,7 +35,7 @@ \section{Pipeline Instance}\label{sec:instance} \centering \newcommand{\function}{$\instanceChartAnnotation{}$} \begin{tikzpicture}[scale=0.7] - % Nodes + % vertexes \node[draw, circle, fill,text=white,minimum size=1 ] (sr) at (0,0) {}; % \node[draw, circle] (node2) at (1,0) {$\s{1}$}; @@ -171,7 +171,7 @@ \subsection{Example}\label{sec:example} TBD (mettere un esempio in cui non sia s % \centering % \newcommand{\function}{$\instanceChartAnnotation{}$} % \begin{tikzpicture}[scale=0.7] -% % Nodes +% % vertexes % \node[draw, circle] (sr) at (0,0) {$\vi{r}$}; % % \node[draw, circle] (node2) at (1,0) {$\s{1}$}; % \node[draw, circle, plus,minimum size=1.5em] (plus) at (1.5,0) {}; diff --git a/pipeline_template.tex b/pipeline_template.tex index d5ce510..d22f918 100644 --- a/pipeline_template.tex +++ b/pipeline_template.tex @@ -34,7 +34,7 @@ \subsection{Pipeline Template Definition}\label{sec:templatedefinition} \centering \newcommand{\function}{$\templateChartAnnotation$} \begin{tikzpicture}[scale=0.9] - % Nodes + % vertexes \node[draw, circle, fill,text=white,minimum size=1 ] (sr) at (0,0) {}; % \node[draw, circle] (node2) at (1,0) {$\s{1}$}; \node[draw, circle, plus,minimum size=1.5em] (plus) at (1.5,0) {}; diff --git a/system_model.tex b/system_model.tex index 49ae265..d7d0392 100644 --- a/system_model.tex +++ b/system_model.tex @@ -83,7 +83,7 @@ \subsection{Service Pipeline and Reference Scenario}\label{sec:service_definitio \begin{figure}[ht!] \centering \begin{tikzpicture}[scale=0.9,y=-1cm] - % Nodes + % vertexes \node[draw, circle, fill,text=white,minimum size=1 ] (root) at (0,0) {}; \node[draw, circle, plus , below = 1em, minimum size=1.5em] (split) at (root.south) {}; diff --git a/text.tex b/text.tex index c9168ee..821d37d 100644 --- a/text.tex +++ b/text.tex @@ -1,64 +1,64 @@ \documentclass[tikz]{standalone} \begin{document} \begin{figure}[ht!] - \centering + \centering - \tikzset{ - do path picture/.style={% - path picture={% - \pgfpointdiff{\pgfpointanchor{path picture bounding box}{south west}}% - {\pgfpointanchor{path picture bounding box}{north east}}% - \pgfgetlastxy\x\y% - \tikzset{x=\x/2,y=\y/2}% - #1 - } - }, - cross/.style={do path picture={ - \draw [line cap=round] (-1,-1) -- (1,1) (-1,1) -- (1,-1); - }}, - plus/.style={do path picture={ - \draw [line cap=round] (-3/4,0) -- (3/4,0) (0,-3/4) -- (0,3/4); - }} - } + \tikzset{ + do path picture/.style={% + path picture={% + \pgfpointdiff{\pgfpointanchor{path picture bounding box}{south west}}% + {\pgfpointanchor{path picture bounding box}{north east}}% + \pgfgetlastxy\x\y% + \tikzset{x=\x/2,y=\y/2}% + #1 + } + }, + cross/.style={do path picture={ + \draw [line cap=round] (-1,-1) -- (1,1) (-1,1) -- (1,-1); + }}, + plus/.style={do path picture={ + \draw [line cap=round] (-3/4,0) -- (3/4,0) (0,-3/4) -- (0,3/4); + }} + } - \begin{tikzpicture}[scale=0.9,y=-1cm] - % Nodes + \begin{tikzpicture}[scale=0.9,y=-1cm] + % vertexes - \node[draw, circle ] (node1) at (0,0) {$\vi{r}$}; + \node[draw, circle ] (node1) at (0,0) {$\vi{r}$}; - \node[draw, circle, plus , below = 1em, minimum size=1.5em] (node2) at (node1.south) {}; + \node[draw, circle, plus , below = 1em, minimum size=1.5em] (node2) at (node1.south) {}; - \node[draw, circle,below =1em] (node3) at (node2.south) {$\vi{2}$}; - \node[draw, circle,left=1em] (node5) at (node3.west) {$\vi{1}$}; - \node[draw, circle,right=1em] (node4) at (node3.east) {$\vi{3}$}; + \node[draw, circle,below =1em] (node3) at (node2.south) {$\vi{2}$}; + \node[draw, circle,left=1em] (node5) at (node3.west) {$\vi{1}$}; + \node[draw, circle,right=1em] (node4) at (node3.east) {$\vi{3}$}; - \node[draw, circle,below=1em] (merge) at (node3.south) {$M$}; + \node[draw, circle,below=1em] (merge) at (node3.south) {$M$}; - \node[draw, circle, plus , minimum size=1.5em,below=1em] (node7) at (merge.south) {}; - \node[draw, circle,below =1em] () at (node7.south) {$\vi{2}$}; + \node[draw, circle, plus , minimum size=1.5em,below=1em] (node7) at (merge.south) {}; + \node[draw, circle,below =1em] () at (node7.south) {$\vi{2}$}; - \node[right] at (node1.east) { $$}; - \node[right] at (node2.east) { $parallel$}; + \node[right] at (node1.east) { $$}; + \node[right] at (node2.east) { $parallel$}; - % Connection + % Connection - \draw[->] (node1) -- (node2); - \draw[->] (node2) -- (node3); - \draw[->] (node2) -- (node4); - \draw[->] (node2) -- (node5); + \draw[->] (node1) -- (node2); + \draw[->] (node2) -- (node3); + \draw[->] (node2) -- (node4); + \draw[->] (node2) -- (node5); - \draw[->] (node3) -- (node6); - \draw[->] (node4) -- (node6); - \draw[->] (node5) -- (node6); - \draw[->] (node6) -- (node7); + \draw[->] (node3) -- (node6); + \draw[->] (node4) -- (node6); + \draw[->] (node5) -- (node6); + \draw[->] (node6) -- (node7); - \end{tikzpicture} - \caption{Reference Scenario} - \label{fig:reference_scenario} + \end{tikzpicture} + \caption{Reference Scenario} + \label{fig:reference_scenario} \end{figure}