CN109902434B - REST architecture style oriented service data visual modeling and matching method in cloud computing environment - Google Patents

Abstract

A REST architecture style oriented service data visualization modeling and matching method in a cloud computing environment comprises the following steps: the first step is as follows: constructing a framework of a service data visual modeling and matching method; the second step is that: defining a metadata tree (MDT); the third step: reading JSON data returned by the called REST API, and performing tree structure modeling on the ds; the fourth step: through a pruning method, basic data structure information is reserved; the fifth step: classifying the visual graphs, summarizing and summarizing the attributes and structural characteristics of various graphs, and creating a visual model tree VT through modeling to formally express various graph information; and a sixth step: and matching and querying the visual model tree VT and the MDT, searching the MDT for the fragments matched with each structModel of the VT, and performing data Mapping according to Mapping information to generate a visual graph. The invention realizes automatic visualization of data.

Description

REST architecture style oriented service data visualization modeling and matching method in cloud computing environment

Technical Field

The invention relates to a REST architecture style oriented service data visualization modeling and matching method in a cloud computing environment.

Background

Cloud Computing (Cloud Computing) is an internet-based Computing model that is now well-established as defined by the National Institute of Standards and Technology (NIST) -Cloud Computing is a pay-per-use model that provides available, convenient, on-demand network access into a configurable shared pool of Computing resources (resources including networks, servers, storage, applications, services) that can be provisioned quickly, with little administrative effort, or with little interaction with service providers. "among them, saaS (software as a service) is an important mode of cloud computing, and delivers data resources and functions to users through cloud service encapsulation. Currently, the REST (Representational State Transfer) architecture style is an important implementation technology architecture of software as a service.

The REST architectural style was released in 2000 at ICSE, an abstract model of the Web architecture for guiding the redesign and definition of hypertext transfer protocols and uniform resource identifiers. The working mode and principle of the world wide web can still be known according to the application of the architecture style, which is significant for understanding and developing large-scale software architecture. Doctor of fire proposed the REST architecture style paper that has been cited more than 7000 times in google academic statistics, and the paper published in ICSE/TOIT was cited more than 2000 times.

The popularity of REST services has led to the emergence of a large number of lightweight data services on the network, and has continued to keep explosive exponential growth, and a large number of service providers have also emerged on international websites, dedicated to the centralized supply and quality assurance of network services. The large online web service website programammable Web gathers a large amount of API information in various fields, the number of the collected APIs is more than twenty thousand at present, and REST framework style service accounts for more than 80%; each major network technology company also has its own API publishing platform, such as: google, youTube, facebook, hundredths, acriba; there are also a number of APIs that individuals develop published on GitHub and personal BLOG.

Among services collected by programable web, response formats are various, and among them, JSON and XML formats are mainly used. XML (extensible markup language) is one of the oldest data formats. It is defined by the W3C (world wide web consortium) and is based on the older SGML (standard generalized markup language) format. In XML, data is structured using elements and attributes. JSON (JavaScript Object Notification) is a lightweight data exchange format. The method is easy to read and write by human, and is also easy to analyze and generate by a machine. JSON is an ideal data exchange language, using a text format that is completely language independent. In contrast, XML has a large number of redundant elements, and repeated element names result in an increased volume of data. JSON has no data redundancy caused by repeated element names, the data transmission rate is higher, and the analysis efficiency and the searching efficiency are higher than those of XML. Developers have in recent years been more inclined to use JSON as a data response format. Among REST services collected by progrmmablebetws, a response format supporting JSON accounts for 90% or more.

Diversified cloud services have promoted huge amounts of data information, and the real value of data information creation lies in data analysis. Data visualization may assist a user in the analytical understanding of data through an interactive visualization interface and data-image conversion techniques. Wilkinson proposes a deep-influence graph Grammar (the Grammar of Graphics) that describes the rules for generating graphs in a standardized language. The Polaris system designed by Stolte provides a concise visual specification for describing tabular visualization of relational data; the Prefuse tool proposed by heir implements a more compact visualization specification by abstracting low-level graphics rendering operations. To alleviate the burden on users, these frameworks have introduced inheritable visual widgets and composable components. Li-highlighted ECharts implement configuration functionality that maps data directly to visual elements without computational detail, which reduces the required limitations on programming skills. On the basis of the visualization tool, researchers develop various visualization platforms to try to realize automatic or semi-automatic visualization of data. SAGE proposed by Roth is a classical visualization design system, and can automatically generate visualization according to the characteristics of data under the condition that a user specifies relevant constraints; after a data area is selected in a data pipeline by a Lyra system proposed by Satyanarayan, data visualization is realized according to a visualization graph and parameters selected by a user; the iVisDesigner system proposed by Ren provides a unified interface for interactive visual creation and editing operation, and a data set defined by a fixed mode is used for visual mapping after being converted into an internal element; after uploading data by a user, man Eyes designed by Viegas firstly appoints a visualization method, and performs various configurations on the basis of the method to finally generate an interactive visualization result. In the visualization tool and the visualization system, although the data visualization operation is simplified to different degrees, the user is still required to participate in guidance, and particularly, the complex data needs to be manually arranged to ensure a better visualization effect.

Disclosure of Invention

In order to realize automatic visualization of data as much as possible, the invention provides a REST architecture style-oriented service data visualization modeling and matching method in a cloud computing environment.

The technical scheme adopted by the invention is as follows:

a REST architecture style oriented service data visualization modeling and matching method in a cloud computing environment comprises the following steps:

the first step is as follows: the architecture for constructing the service data visual modeling and matching method comprises three modules: data Modeling (Data Modeling), graphic Modeling (Graphics Modeling), and Matching engine (Matching Processor);

1.1, data modeling: REST Service acquired from Internet is analyzed by an analyzer (REST Service Parser) and then registered, the REST Service is stored in a cache or a Database, the acquired REST Service Data based on JSON is automatically called, the Service Data is converted into a standardized model through Service Data Modeling (Service Data Modeling), and a main Data structure is extracted to generate a metadata tree (MDT);

1.2, graphical modeling: carrying out data structure Analysis and induction (Structural Analysis) on graphs supported by various configuration type visualization tools (such as ECharts, highCHharts, D3.Js and Chart. Js), sorting out a general data structure and a data mapping relation of a main graph, carrying out Visual graph Modeling (Visual Graphics Modeling) according to the information, and creating a descriptive Visual model, namely Visual model Tree (VT for short);

1.3, matching engine: calling MDT generated by data modeling, searching a data structure segment matched with a graph structure model in VT from the MDT to inquire the graph type which can be generated by source data, and automatically generating Visual graphs (Visual Graphics) according to mapping relation information (Mpping);

the second step is that: defining a metadata tree MDT, including a root node TRoot, an index node INode and a data node DNode, and simultaneously using depth to express the number of layers of the nodes in the tree structure, wherein the root node defaults to be a first layer, namely level =1;

2.1, root node: a root node of the MDT, namely a starting node of the MDT;

2.2, index node: representing each KEY KEY in the JSON data, but not including KEYs of 'KEY-value' pairs in the innermost layer of the JSON data, wherein the index nodes are non-root nodes and non-leaf nodes;

2.3, data node: representing the key-value pair of the innermost layer in JSON data and storing the key-value pair as a leaf node;

the third step: reading JSON data returned by the called REST API, taking a JSON data set ds as the input of a modeling algorithm, and performing tree structure modeling on ds, wherein the steps are as follows:

3.1, creating an MDT with a root node as a root node, wherein the root node is a starting node, and the depth level of the root node is regarded as 1 by default;

3.2, reading a JSON data set ds, if the ds is read for the first time, setting a first element of the ds as a current element, wherein the element comprises a keyword KEY and a VALUE VALUE thereof; otherwise, setting the next element of the ds as the current element; if the outermost layer of the JSON data is ARRAY, the ismask of TRoot =1, and the element number arrayNum is the number of ARRAY elements;

the fourth step: through a pruning method, basic data structure information is reserved, the same repeated data structure is pruned, the size of the model is reduced, the basic data structure is reserved, and the query cost caused by a JSON data structure is reduced;

the fifth step: classifying the visual graphs, summarizing and summarizing the attributes and structural features of various graphs, and creating a visual model Tree (VT for short) through modeling to formally express various graph information;

and a sixth step: and matching and querying the visual model tree VT and the MDT, searching the MDT for the fragments matched with each structModel of the VT, and performing data Mapping according to Mapping information to generate a visual graph.

Further, the processing procedure of the fourth step includes the following steps;

4.1, traversing the root node and the index node of the MDT layer by layer from the trunk with level =1 according to the breadth first strategy; the breadth-first strategy is to traverse the MDT layer by layer according to the level, traverse is started from the first layer with the level =1, and after the node traverse of the level layer is finished, the node of the level +1 layer is continuously traversed;

4.2, storing the TRoot of the MDT into a traversal queue;

4.3, reading the ismask attribute of each node according to the sequence of the traversal queue;

4.4, stopping traversing when all the data nodes exist in the traversal queue or the traversal queue is empty, and ending the method;

and 4.5, outputting the MDT after pruning.

Still further, the processing procedure of step 4.3 is as follows:

4.3.1, if the isMark attribute value of the traversed node is 1, retaining the first child node of the current node, cutting off the rest child nodes and the sub-tree structures of the child nodes, and jumping to the step 4.3.4;

4.3.2, if the attribute value of the ismask of the traversed node is 0, not performing any operation, and jumping to the step 4.3.4;

4.3.3, if the traversed node is a data node, deleting the current node from the traversal queue, and jumping to the step 4.3;

4.3.4, adding the child nodes of the currently traversed node into the traversal queue, deleting the current node from the traversal queue, and then jumping to the step 4.3.

The fifth step includes the steps of:

5.1, defining VT including basic attribute (basic) and visual structure (DVSCHEMA) two parts, formalized definition as (11), wherein basic attribute holds general information of graphic title, subtitle and other text style;

(11)、VisualModel::＝<BASICATTRIBUTE><DVSCHEMA>

5.2, BASICATTRIBUTE includes three attributes: title (title), subtitle (subtitle) and attributes (attributes), wherein the formal definitions are as shown in (12), the title is used for storing the title of the finally generated visual graph, the subtitle is used for storing the subtitle of the finally generated visual graph, and the attributes are used for storing the setting parameters of the position, the color combination, the font and the font size of the finally generated visual graph;

(12)、BASICATTRIBUTE::＝<title><subtitle><attributes>

5.3, the basic visualization graph can be generalized into four basic categories according to the data type, the graph data structure and the graph dimension required by the graph: general graph (General), topological graph (Topology), map (Map), text graph (Text), formal definition as (13);

(13)、DVSCHEMA::＝<General><Topology><Map><Text>

5.4, the four basic categories of the step 5.3 respectively comprise two attributes: the method comprises the steps of determining a graph type (VType) and a graph structure (structModel), wherein the VType stores a graph type to which the class belongs, the structModel stores a basic visual structure of a graph to which the class belongs, the formalized definition is (14), and the graph type (VType) and the graph structure (structModel) indicate that the graph to which the class belongs contains an attribute B;

(14)、DVSCHEMA::＝<General><Topology><Map><Text>::<VType><StructModel>

5.5, in the step 5.4, the four basic categories have respective Mapping relations (Mapping), and describe data structures, data dimensions, graph structure relations and data Mapping position information of various graphs; and abstracting a basic visual structure structModel of various graphs according to Mapping information and by combining a graph data structure, and matching the MDT generated in the third step with the structModel to judge which visual graph can be generated by the returned data of the REST API.

Further, the processing procedure of the sixth step includes the following steps:

6.1, resolving the structModels of four basic categories in VT, extracting a temporary root node and a substructure thereof in each structModel, taking a tree structure segment formed by each temporary root node and the substructure thereof as a query subgraph, and extracting six query subgraphs according to the steps 5.5.1 to 5.5.4: the substructure with the Root of the General type structModel as the starting point, the two substructures with the Root1 and the Root2 as the starting points respectively for the subordinate of the Topology type structModel, the two substructures with the Root1 and the Root2 as the starting points respectively for the subordinate of the Map type structModel, and the substructure with the Root of the Text type structModel as the starting point;

6.2, taking the MDT as a target graph, taking the six query subgraphs in the 6.1 as input in sequence, traversing the MDT once when inputting one query subgraph, and searching for an MDT segment matched with the currently input query subgraph;

6.3, traversing the MDT layer by layer according to the breadth first strategy;

6.4, storing the nodes of the MDT into a traversal queue Q from the TRoot in the sequence of the number of layers from small to large;

6.5, according to the sequence of traversing the queue Q, the currently traversed node N _i Putting the set S1 and putting the temporary root node M of the query subgraph into a set S2;

6.6, comparing whether the structures of the nodes in the S1 and the S2 are consistent, namely whether the parent-child relationship of each corresponding node in the S1 and the S2 is consistent; if the structures of the nodes in the S1 and the S2 are consistent, sequentially adding the nodes in the set L2 of the child nodes of the M into the set S2; skipping to step 6.8;

6.7, if the structures of the nodes in the S1 and the S2 are not consistent, setting i = i +1, clearing the S1 and the S2, and jumping to the step 6.5;

6.8, adding a node L2 in S2 every time _k Then, go to step 6.9;

6.9 reading node N _i The nodes in the set L1 of the child nodes are sequentially added into the set S1, and each node L1 is added into the set S1 _j Performing primary structure matching with S2;

6.10, if the nodes in the L1 and the L2 are traversed, clearing the L1 and the L2, then finding out original nodes corresponding to the leaf nodes in the S1 in the MDT, and regenerating the child nodes of the original nodes into the L1; original nodes corresponding to the leaf child nodes in the S2 are found out in the query subgraph, the child nodes of the original nodes are regenerated into L2, and the step 6.6 is skipped;

6.11, if the nodes of the query subgraph are all added into the set R2, storing the structure in the set R1, clearing the set R1, the set S2, the set L1 and the set L2, setting i = i +1, and jumping to the step 6.5;

6.12, after the nodes in the traversal queue Q are traversed, inputting a next query subgraph, and repeating the steps 6.5 to 6.12;

6.13, completing the query of all six query subgraphs, and Mapping the data in the MDT into a graph structure of a corresponding type according to a Mapping structure according to an output matching result set R, thereby generating a visual graph.

Still further, the processing procedure of step 6.8 is:

6.9.1, if S1 and S2 are successfully matched, setting k = k +1, and adding a node L2 to S2 _K Skipping to step 6.8;

6.9.2, if the matching of S1 and S2 fails, removing the node L1 which is just added in S1 _j Setting j = j +1, adding node L1 to S1 _j Jumping to step 6.9;

in the 2.1, the root node includes the following information:

2.1.1, star mark isMark: recording whether the outermost layer structure in the JSON data is of an array type, if so, marking with 1, and if not, marking with 0; the isomark formalized definition is expressed as (1) (2), the data type of the isomark is NUMBER, if the VALUE in the key-VALUE pair in the JSON data is ARRAY ARRAY, the isomark =1, otherwise, the isomark =0; "#" is a data type delimiter, ":" = "is an assignor," A → condition ≦ B ": < C >," C "-" indicates that if A satisfies the condition, the formula value is B, otherwise the formula value is C;

(1)、“isMark”#<NUMBER>

(2)、“isMark”::＝〖“VALUE”→ARRAY⊕<1>:<0>〗

2.1.2, number of elements arrayNum: if the ismask of the current node is 1, recording the number of array elements, and if the ismask of the current node is 0, marking by 0; the formalized definition of arrayNum is expressed as (3) (4), the attribute VALUE of arrayNum is a NUMBER NUMBER type, if the VALUE VALUE in the key-VALUE pair in JSON data is ARRAY, the arrayNum is equal to the length of the VALUE ARRAY, otherwise, the arrayNum =0;

(3)、“arrayNum”#<NUMBER>

(4)、“arrayNum”::＝〖“VALUE”→ARRAY⊕<ARRAY.length>:<0>〗。

in the 2.2, the index node includes the following information:

2.2.1, node name: the name data type is STRING STRING, and the name attribute value is a keyword KEY in a KEY-value pair in JSON data; name formalization definition expression is (5) (6);

(5)、“name”#<STRING>

(6)、“name”::＝<KEY>

2.2.2, node value type vType: the vType is the data type of a VALUE VALUE in a key-VALUE pair in JSON data, and the attribute VALUE is one of an OBJECT, an ARRAY, a character STRING, a NUMBER, a TRUE and a FALSE; the vType formalization definition is expressed as (7);

(7)、“vType”::＝[OBJECT|ARRAY|STRING|NUMBER|TRUE|FALSE]

2.2.3, star (isMark): recording whether a VALUE VALUE in a key-VALUE pair with the name of the current node as a keyword in JSON data is an array type, if so, marking by 1, and if not, marking by 0; the isMark formalized definition is expressed as (1) (2) in step 2.1.1;

2.2.4, number of elements arrayNum: if the isMark of the current node is 1, recording the number of array elements of a VALUE VALUE in a key-VALUE pair, and if the isMark of the current node is 0, marking by 0; the formalized definition of arrayNum is expressed in the same steps as (3) (4) in step 2.1.2.

In the 2.3, the data node includes the following information:

2.3.1, node name: saving a KEY in a KEY-value pair in JSON data, wherein the data type is a character STRING STRING; the name formalization definition is expressed in the same way as (5) (6) in the step 2.2.1;

2.3.2, node value nValue: the data type of the nValue is STRING, and the attribute VALUE is VALUE VALUE in a key-VALUE pair in JSON data; the nValue formal definition expression is shown as (8) (9);

(8)、“nValue”#<STRING>

(9)、“nValue”::＝<VALUE>

2.3.3, node type: saving the data type of a VALUE VALUE in a key-VALUE pair in JSON data as 'str', 'num' or NULL, wherein the 'str' represents that the data type of a type is STRING, the 'num' represents that the data type of the type is NUBER, and the NULL represents that the attribute VALUE of the type is NULL; the type formalization definition is expressed as (10);

(10)、“type”::＝[“str”|“num”|NULL]。

the processing procedure of the step 3.2 is as follows:

3.2.1, if the data type of the VALUE is not OBJECT and is not ARRAY, creating a data node with the depth of level +1, wherein the name of the node is a KEY, the VALUE nValue is the VALUE, and the type of the node is the data type of the VALUE; after the completion, skipping to the step 3.2;

3.2.2, if the data type of the VALUE is ARRAY, creating an index node with the depth of' = level +1, wherein the name of the node is a KEY, the type vType of the node is ARRAY, isMark =1, and the number of elements, arrayNum, is the number of elements in the current VALUE ARRAY;

3.2.3, if the data type of the VALUE is OBJECT, creating an index node with depth' = level +1, wherein the name of the node is a KEY in each OBJECT element, and the type of the node VALUE vType is the data type of the VALUE VALUE in each OBJECT element; if the current vType is ARRAY, the isMark =1, and the element number arrayNum is the element number in the current VALUE ARRAY; if the current vType is not ARRAY, then isMark =0, arrayNum =0;

3.2.4, taking the VALUE array in the step 3.2.3 as a new JSON data set ds', and skipping to the step 3.2.

The treatment process of 3.2.2 comprises the following steps:

3.2.2.1, if the element of the VALUE array in said 3.2.2 is not of the OBJECT type, creating a data node with level "= level' +1, the name of the node is a KEY, the VALUE nValue is a VALUE VALUE, and the type of the node is a data type of the VALUE VALUE; after the completion, skipping to the step 3.2;

3.2.2.2, if an element of the VALUE ARRAY in the 3.2.2 is an OBJECT type, creating an index node with level "= level' +1, where the node name is a KEY in each OBJECT element, the node VALUE type vType is a data type of the VALUE in each OBJECT element, if the current vType is ARRAY, isMark =1, and the element number arrayNum is the number of elements in the current VALUE ARRAY; if the current vType is not ARRAY, then isMark =0, arrayNum =0;

3.2.2.3, taking the VALUE array in the step 3.2.2.2 as a new JSON data set ds', and skipping to the step 3.2.

In the 5.4, the graphs of the VType attributes of the four basic categories are as follows:

5.4.1 General includes bar chart (BarChart), line chart (LineChart), pie chart (PieChart), radar chart (RadarChart), scatter chart (ScatterChart);

5.4.2, topology includes network map (NetworkChart), tree map (TreeMap), area tree map (TreeMapcart);

5.4.3 Map includes area Map (AreaMapChart), country Map (CountryMapChart), world Map (WorldMapChart);

5.4.4, text includes word cloud (WorldCloudChart);

in the 5.5, mapping relationships Mapping and basic visual structure StructModel of various graphs are defined as follows:

5.5.1, graphics in General type, commonly used to represent two-dimensional or three-dimensional data, information can be represented by tuples (XAxis, YAxis) or triples (XAxis, YAxis, ZAxis), mapping structures of such graphics are as (15), where Legendname represents legend name, storing each grouping information in ARRAY type; according to the Mapping structure, the structure of the basic structModel can be abstracted as (16), the child node of the structModel is a temporary Root node Root, and the Root comprises two child nodes: a key-value pair K _ V and a legend node Legendnode;

(15)、Mapping::＝<XAxis,YAxis,[ZAxis]><LegendName>

(16)、StructModel::＝<Root::<K_V><LegendNode>>

5.5.2, graphs in Topology type are commonly used to represent topological relation data, tree and area tree graphs can represent attribute structures with nested key value pairs { key: value, child: { key: value } }, mapping structures such as (17); the network graph can be represented by a node set (Nodes) and an edge set (Links), wherein the Mapping structure is as shown in (18), wherein source represents a starting node of an edge link, and target represents a pointing node of the edge link; according to the Mapping structure, the structure of the basic structModel can be abstracted as (19), the structModel has two substructures, root1 and Root2 are temporary Root nodes of the two substructures respectively, and Root1 comprises two substructures: the child node child is a child node child, and the child structure of child node child is a key value pair K _ V; root2 contains two child nodes: node sets and edge sets, wherein child Nodes of the node sets are keywords and values, the values may be null, and the child Nodes of the edge sets are a starting source and a target;

(17)、Mapping::＝<K_V><children::<K_V>>

(18)、Mapping::＝<Nodes::<key,[value]><Links::<source><target>>

(19)、StructModel::＝<Root1::<K_V><children::<K_V>>><Root2::<Nodes::<key,[value]>,<Links::<source><target>>>

5.5.3, maps of the type Map are commonly used to represent Map information, represented by a key-value pair array [ { PlaceName: value } ] or a triple array [ { lng, lat, value } ], such maps having a structure as (20), where PlaceName represents place name, lng represents latitude, and lat represents longitude; the structure of a basic structModel can be abstracted according to the Mapping structure, wherein the structModel has two substructures, root1 and Root2 are temporary Root nodes of the two substructures respectively, and the Root1 comprises a child-node key-value pair K _ V; root2 contains three child nodes: longitude lat, latitude lng, value;

(20)、Mapping::＝<Data1::<PlaceName><value>><Data2::<lng><lat><value>>

(21)、StructModel::＝<Root1::<K_V>>,<Root2::<lng>,<lat>,<value>>

5.5.4, graphics in the Text type commonly use binary (Keyword, frequency) to represent the Keyword frequency, and the Mapping structure of such graphics is as (22), wherein the Keyword is a word extracted from a Text, and the frequency represents the occurrence frequency of the word in the Text; the structure of the basic structModel can be abstracted according to the Mapping structure, for example, (23), the child node of the structModel is a temporary Root node Root, and the Root contains a key-value pair K _ V;

(22)、Mapping::＝<Keyword><frequency>

(23)、StructModel::＝<Root::<K_V>>。

the beneficial effects of the invention are as follows: after calling REST API, a user can intelligently understand the JSON data structure of the service response through the method, tree structure modeling is carried out on the JSON data structure, a standardized data structure is generated, the internal data relevance of the data is convenient to find, the JSON data structure is matched with a common visual graph model, namely a visual model tree VT, a matching structure is automatically searched, various graphs are generated, meanwhile, manual editing operation can be reduced in the automatic visualization process, and the data visualization process is simplified.

Drawings

FIG. 1 shows an architecture diagram of a service data visualization modeling and matching method.

FIG. 2 shows a JSON data structure diagram returned by the 2018 world cup REST API.

Fig. 3 shows a tree structure diagram of JSON data conversion.

Fig. 4 shows a tree structure diagram after JSON data pruning.

Fig. 5 shows a block diagram of the visual model tree VT.

Detailed Description

The invention is further described below with reference to the accompanying drawings.

Referring to fig. 1 to 5, a method for visual modeling and matching REST architecture style-oriented service data in a cloud computing environment includes the following steps:

the first step is as follows: the architecture for constructing the service data visualization modeling and matching method, referring to fig. 1, comprises three modules: data Modeling (Data Modeling), graph Modeling (Graphics Modeling), and Matching engine (Matching Processor);

1.1, data modeling: REST Service acquired from Internet is analyzed by an analyzer (REST Service Parser) and then registered, the REST Service is stored in a cache or a Database, the acquired REST Service Data based on JSON is automatically called, the Service Data is converted into a standardized model through Service Data Modeling (Service Data Modeling), and a main Data structure is extracted to generate a metadata tree (MDT);

1.2, graphical modeling: carrying out data structure Analysis and induction (structured Analysis) on graphs supported by various configuration visualization tools (such as ECharts, highCharts, D3.Js and Chart. Js), sorting out a general data structure and a data mapping relation of a main graph, carrying out Visual graph Modeling (Visual Graphics Modeling) according to the information, and creating a descriptive Visual model, namely Visual model Tree (VT for short);

1.3, matching engine: calling MDT generated by data modeling, searching a data structure segment matched with a graph structure model in VT from the MDT to inquire the graph type which can be generated by source data, and automatically generating Visual graphs (Visual Graphics) according to mapping relation information (Mpping);

the second step is that: defining a metadata Tree (MDT), which comprises a Root Node (Tree _ Root, abbreviated as "Root"), an Index Node (Index _ Node, abbreviated as "INode"), and a Data Node (Data _ Node, abbreviated as "DNode"), and simultaneously, the number of layers of the Node in the Tree structure is represented by a depth (level), and the Root Node defaults to the first layer, i.e., level =1;

2.1, root node: a root node of the MDT, namely a starting node of the MDT;

2.2, index node: representing each KEY (KEY) in the JSON data, but not including KEYs of 'KEY-value' pairs at the innermost layer in the JSON data, wherein the index nodes are non-root nodes and non-leaf nodes;

2.3, data node: representing the key-value pair of the innermost layer in JSON data and storing the key-value pair as a leaf node;

in the 2.1, the root node includes the following information:

2.1.1, star (isMark): recording whether the outermost layer structure in the JSON data is an array type, if so, marking by 1, and if not, marking by 0; the isomark formalization definition is expressed as (1) (2), the data type of the isomark is NUMBER (NUMBER), if the VALUE (VALUE) in the key-VALUE pair in the JSON data is ARRAY (ARRAY), the isomark =1, otherwise, the isomark =0; "#" is a data type delimiter, ":" = "is an assignor," A → condition ≦ B ": < C >," C "-" indicates that if A satisfies the condition, the formula value is B, otherwise the formula value is C;

(1)、“isMark”#<NUMBER>

(2)、“isMark”::＝〖“VALUE”→ARRAY⊕<1>:<0>〗

2.1.2, number of elements (arrayNum): if the isMark of the current node is 1, recording the number of the array elements, and if the isMark of the current node is 0, marking by 0; the formalized definition of arrayNum is expressed as (3) (4), the VALUE of the arrayNum attribute is a NUMBER (NUMBER) type, if the VALUE (VALUE) in the key-VALUE pair in the JSON data is ARRAY, the arrayNum is equal to the length of the VALUE ARRAY, otherwise, the arrayNum =0;

(3)、“arrayNum”#<NUMBER>

(4)、“arrayNum”::＝〖“VALUE”→ARRAY⊕<ARRAY.length>:<0>〗

in the 2.2, the index node includes the following information:

2.2.1, node name (name): the name has a data type of character STRING (STRING), and the name attribute value is a KEY (KEY) in a KEY-value pair in JSON data; name formalization definition expression is (5) (6);

(5)、“name”#<STRING>

(6)、“name”::＝<KEY>

2.2.2, node value type (vType): the vType is a data type of a VALUE (VALUE) in a key-VALUE pair in JSON data, and the attribute VALUE is one of an OBJECT (OBJECT), an ARRAY (ARRAY), a character STRING (STRING), a NUMBER (NUMBER), TRUE and FALSE; the vType formalization definition is expressed as (7);

(7)、“vType”::＝[OBJECT|ARRAY|STRING|NUMBER|TRUE|FALSE]

2.2.3, star (isMark): recording whether a VALUE (VALUE) in a key-VALUE pair with a current node name (name) as a keyword in JSON data is an array type, if so, marking by 1, and if not, marking by 0; the isMark formalization definition is expressed in the same way as (1) (2) in step 2.1.1;

2.2.4, number of elements (arrayNum): if the ismask of the current node is 1, recording the number of array elements of a VALUE (VALUE) in a key-VALUE pair, and if the ismask of the current node is 0, marking by 0; the formalized definition of arrayNum is expressed in the same manner as (3) (4) in step 2.1.2

In the 2.3, the data node includes the following information:

2.3.1, node name (name): saving a KEY (KEY) in a KEY-value pair in JSON data, wherein the data type is a character STRING (STRING); the name formalization definition is expressed in the same way as (5) (6) in the step 2.2.1;

2.3.2, node value (nValue): the nValue has a data type of STRING and an attribute VALUE of a VALUE (VALUE) in a key-VALUE pair in JSON data; the nValue formal definition expression is shown as (8) (9);

(8)、“nValue”#<STRING>

(9)、“nValue”::＝<VALUE>

2.3.3, node type (type): saving the data type of a VALUE (VALUE) in a key-VALUE pair in JSON data as 'str', 'num' or NULL, wherein the 'str' represents that the data type of the type is STRING, the 'num' represents that the data type of the type is NUMBER, and the NULL represents that the attribute VALUE of the type is NULL; the type formalization definition is expressed as (10);

(10)、“type”::＝[“str”|“num”|NULL]

the third step: reading JSON data returned by the called REST API, taking a JSON data set ds as the input of a modeling algorithm, and carrying out tree structure modeling on ds, wherein the steps are as follows:

3.1, creating an MDT with a root node as a root node, wherein the root node is a starting node, and the depth (level) of the root node is 1 by default;

3.2, reading a JSON data set ds, if the ds is read for the first time, setting a first element of the ds as a current element, wherein the element comprises a KEY (KEY) and a VALUE (VALUE) thereof; otherwise, setting the next element of the ds as the current element; if the outermost layer of the JSON data is ARRAY, the isMark =1 of TRoot, and the element number (arrayNum) is the ARRAY element number;

3.2.1, if the data type of the VALUE is not OBJECT and is not ARRAY, creating a data node with the depth of level +1, wherein the node name (name) is a KEY (KEY), the node VALUE (nValue) is a VALUE (VALUE), and the node type (type) is the data type of the VALUE (VALUE); after the completion, skipping to the step 3.2;

3.2.2, if the data type of the VALUE is ARRAY, creating an index node with depth' = level +1, wherein the node name (name) is a KEY (KEY), the node VALUE type (vType) is ARRAY, isMark =1, and the element number (arrayNum) is the element number in the current VALUE ARRAY;

3.2.2.1, if the element of the VALUE array in the 3.2.2 is not an OBJECT type, creating a data node with level "= level' +1, where the node name (name) is a KEY (KEY), the node VALUE (nValue) is a VALUE (VALUE), and the node type (type) is a data type of the VALUE (VALUE); after the completion, skipping to the step 3.2;

3.2.2.2, if the element of the VALUE array in the 3.2.2 is an OBJECT type, creating an index node with level "= level' +1, where the node name (name) is a KEY (KEY) in each OBJECT element, and the node VALUE type (vType) is a data type of a VALUE (VALUE) in each OBJECT element. If the current vType is ARRAY, isMark =1, and the element number (arrayNum) is the element number in the current VALUE ARRAY; if the current vType is not ARRAY, then isMark =0, arrayNum =0;

3.2.2.3, taking the VALUE array in the step 3.2.2.2 as a new JSON data set ds', and skipping to the step 3.2;

3.2.3, if the data type of the VALUE is OBJECT, creating an index node with depth' = level +1, wherein the node name (name) is a KEY (KEY) in each OBJECT element, and the node VALUE type (vType) is the data type of the VALUE (VALUE) in each OBJECT element. If the current vType is ARRAY, the isMark =1, and the element number (arrayNum) is the element number in the current VALUE ARRAY; if the current vType is not ARRAY, then isMark =0, arrayNum =0;

3.2.4, taking the VALUE array in the step 3.2.3 as a new JSON data set ds', and skipping to the step 3.2.

The fourth step: batch data may exist in the JSON data set, the batch data usually exist in the same data structure form, and are expressed in the form of a common array in the data set; if the user focuses on the JSON data analysis not on the positioning and query of data but on the analysis of a data structure, based on the JSON data analysis modeling method, basic data structure information can be retained through a pruning method, the same repeated data structure is pruned, the size of a model is reduced, the basic data structure is still retained, and the query expense brought by the JSON data structure is reduced, wherein the method comprises the following steps:

4.1, traversing the root node and the index node of the MDT layer by layer from the trunk with level =1 according to the breadth first strategy; the breadth-first strategy is to traverse the MDT layer by layer according to the level, traverse is started from the first layer with the level =1, and after the node traverse of the level layer is finished, the node of the level +1 layer is continuously traversed;

4.2, storing the TRoot of the MDT into a traversal queue;

4.3, reading the ismask attribute of each node according to the sequence of the traversal queue;

4.3.1, if the isMark attribute value of the traversed node is 1, retaining the first child node of the current node, cutting off the rest child nodes and the sub-tree structures of the child nodes, and jumping to the step 4.3.4;

4.3.2, if the attribute value of the ismask of the traversed node is 0, not performing any operation, and jumping to the step 4.3.4;

4.3.3, if the traversed node is a data node, deleting the current node from the traversal queue, and jumping to the step 4.3;

4.3.4, adding the child nodes of the currently traversed node into the traversal queue, deleting the current node from the traversal queue, and then jumping to the step 4.3;

4.4, stopping traversing when all the data nodes are in the traversing queue or the traversing queue is empty, and ending the method;

and 4.5, outputting the MDT after pruning.

The fifth step: referring to fig. 5, the visual graphs are classified, attributes and structural features of the graphs are summarized and summarized, and a visual model Tree (VT for short) is created through modeling to formally represent information of the graphs;

5.1, defining VT comprises two parts of basic attribute (basic) and visual structure (DVSCHEMA), formalized definition is (11), wherein the basic attribute stores general information of graphic titles, subtitles and other text styles;

(11)、VisualModel::＝<BASICATTRIBUTE><DVSCHEMA>

5.2, BASICATTRIBUTE includes three attributes: title (title), subtitle (subtitle) and attributes (attributes), wherein the formal definitions are as shown in (12), the title is used for storing the title of the finally generated visual graph, the subtitle is used for storing the subtitle of the finally generated visual graph, and the attributes are used for storing the setting parameters of the position, the color combination, the font and the font size of the finally generated visual graph;

(12)、BASICATTRIBUTE::＝<title><subtitle><attributes>

5.3, the basic visualization graph can be generalized into four basic categories according to the data type, the graph data structure and the graph dimension required by the graph: general graph (General), topological graph (Topology), map (Map), text graph (Text), formal definition as (13);

(13)、DVSCHEMA::＝<General><Topology><Map><Text>

5.4, the four basic categories subordinate in step 5.3 respectively comprise two attributes: the method comprises the steps of determining a graph type (VType) and a graph structure (structModel), wherein the VType stores a graph type to which the class belongs, the structModel stores a basic visual structure of a graph to which the class belongs, the formalized definition is (14), and the graph type (VType) and the graph structure (structModel) indicate that the graph to which the class belongs contains an attribute B;

(14)、DVSCHEMA::＝<General><Topology><Map><Text>::<VType><StructModel>

in the 5.4, the graphs of the VType attributes of the four basic categories are as follows:

5.4.1 General includes bar chart (BarChart), line chart (LineChart), pie chart (PieChart), radar chart (RadarChart), scatter chart (ScatterChart);

5.4.2, topology includes network map (NetworkChart), tree map (TreeMap), area tree map (TreeMapcart);

5.4.3 Map includes area Map (AreaMapChart), country Map (CountryMapChart), world Map (WorldMapChart);

5.4.4, text includes word cloud (WorldCloudChart);

5.5, in the step 5.4, the four basic categories have respective Mapping relations (Mapping), and describe data structures, data dimensions, graph structure relations and data Mapping position information of various graphs; according to Mapping information and by combining with a data structure of a graph, a basic visual structure structModel of various graphs can be abstracted, and the MDT generated in the third step is matched with the structModel to judge which visual graph can be generated by returned data of the REST API;

5.5.1, graphics in General type, commonly used to represent two-dimensional data or three-dimensional data, information can be represented by a binary (XAxis, YAxis) or triple (XAxis, YAxis, ZAxis), mapping structure of such graphics is as (15), where Legendname represents the name of the legend, storing each packet information in ARRAY type; according to the Mapping structure, the structure of the basic structModel can be abstracted as (16), the child node of the structModel is a temporary Root node Root, and the Root comprises two child nodes: the key-value pair K _ V and the legend node LegendNode;

(15)、Mapping::＝<XAxis,YAxis,[ZAxis]><LegendName>

(16)、StructModel::＝<Root::<K_V><LegendNode>>

5.5.2, graphs in Topology type are usually used to represent topological relation data, and the tree graph and the area tree graph can represent attribute structures by nested key-value pairs { key: value, child: { key: value } }, mapping structures such as (17); the network graph can be represented by a node set (Nodes) and an edge set (Links), wherein the Mapping structure is as shown in (18), wherein source represents a starting node of an edge link, and target represents a pointing node of the edge link; according to the Mapping structure, the structure of the basic structModel can be abstracted as (19), the structModel has two substructures, root1 and Root2 are temporary Root nodes of the two substructures respectively, and Root1 comprises two substructures: the child node child is a child node child, and the child structure of child node child is a key value pair K _ V; root2 contains two child nodes: node sets and edge sets Links, wherein child Nodes of the node sets are key words and values, the values can be empty, and the child Nodes of the edge sets are a starting point source and a target;

(17)、Mapping::＝<K_V><children::<K_V>>

(18)、Mapping::＝<Nodes::<key,[value]><Links::<source><target>>

(19)、StructModel::＝<Root1::<K_V><children::<K_V>>><Root2::<Nodes::<key,[value]>,<Links::<source><target>>>

5.5.3, maps of the type Map are commonly used to represent Map information, represented by a key-value pair array [ { PlaceName: value } ] or a triple array [ { lng, lat, value } ], such maps having a structure as (20), where PlaceName represents place name, lng represents latitude, and lat represents longitude; the structure of a basic structModel can be abstracted according to the Mapping structure, wherein the structModel has two substructures, root1 and Root2 are temporary Root nodes of the two substructures respectively, and the Root1 comprises a child-node key-value pair K _ V; root2 contains three child nodes: longitude lat, latitude lng, value;

(20)、Mapping::＝<Data1::<PlaceName><value>><Data2::<lng><lat><value>>

(21)、StructModel::＝<Root1::<K_V>>,<Root2::<lng>,<lat>,<value>>

5.5.4, graphics in the Text type commonly use a binary (Keyword, frequency) to represent the Keyword frequency, and the Mapping structure of such graphics is as (22), wherein the Keyword is a word extracted from a Text, and the frequency represents the occurrence frequency of the word in the Text; the structure of the basic structModel can be abstracted according to the Mapping structure, for example, (23), the child node of the structModel is a temporary Root node Root, and the Root contains a key-value pair K _ V;

(22)、Mapping::＝<Keyword><frequency>

(23)、StructModel::＝<Root::<K_V>>

and a sixth step: matching and inquiring the visual model tree VT and the MDT, searching fragments matched with each structModel of the VT in the MDT, and performing data Mapping according to Mapping information to generate a visual graph;

6.1, resolving the structModels of four basic categories in VT, extracting a temporary root node and a substructure thereof in each structModel, taking a tree structure segment formed by each temporary root node and the substructure thereof as a query subgraph, and extracting six query subgraphs according to the steps 5.5.1 to 5.5.4: the substructure with Root as a starting point of the subordinate of the General type structModel, the two substructures with Root1 and Root2 as starting points of the subordinate of the Topology type structModel, the two substructures with Root1 and Root2 as starting points of the subordinate of the Map type structModel and the substructure with Root1 and Root2 as starting points of the subordinate of the Text type structModel;

6.2, taking the MDT as a target graph, taking the six query subgraphs in the 6.1 as input in sequence, traversing the MDT once when inputting one query subgraph, and searching for an MDT segment matched with the currently input query subgraph;

6.3, traversing the MDT layer by layer according to the breadth first strategy;

6.4, storing nodes of the MDT into a traversal queue Q from the root in a sequence of the number of layers from small to large;

6.5, according to the sequence of the traversal queue Q, the currently traversed node N _i Putting the set S1, and putting the temporary root node M of the query subgraph into a set S2;

6.6, comparing whether the structures of the nodes in the S1 and the S2 are consistent, namely whether the parent-child relationship of each corresponding node in the S1 and the S2 is consistent; if the structures of the nodes in the S1 and the S2 are consistent, sequentially adding the nodes in the set L2 of the child nodes of the M into the set S2; skipping to step 6.8;

6.7, if the structures of the nodes in the S1 and the S2 are inconsistent, setting i = i +1, emptying the S1 and the S2, and jumping to the step 6.5;

6.8, adding a node L2 in S2 every time _k Then, go to step 6.9;

6.9 reading node N _i The nodes in the set L1 of the child nodes are sequentially added into the set S1, and each node L1 is added into the set S1 _j Performing primary structure matching with S2;

6.9.1, if S1 and S2 are successfully matched, setting k = k +1, and adding a node L2 to S2 _K Skipping to step 6.8;

6.9.2, if the matching of S1 and S2 fails, removing the node L1 which is just added in S1 _j Setting j = j +1, adding node L1 to S1 _j Skipping to step 6.9;

6.10, if the nodes in the L1 and the L2 are traversed, clearing the L1 and the L2, then finding out original nodes corresponding to the leaf nodes in the S1 in the MDT, and regenerating the child nodes of the original nodes into the L1; original nodes corresponding to the leaf child nodes in the S2 are found out in the query subgraph, the child nodes of the original nodes are regenerated into L2, and the step 6.6 is skipped;

6.11, if the nodes of the query subgraph are added into S2, storing the structure in S1 in a set R, emptying S1, S2, L1 and L2, setting i = i +1, and jumping to the step 6.5;

6.12, after the nodes in the traversal queue Q are traversed, inputting a next query subgraph, and repeating the steps 6.5 to 6.12;

6.13, until the six query subgraphs complete the query, mapping the data in the MDT to a graph structure of a corresponding type according to the Mapping structure according to the output matching result set R, thereby generating a visual graph.

Example (c): FIG. 2 shows a JSON data structure diagram returned by the 2018 world cup REST API. The supplier of the World Cup in JSON API is Software For Good, which is a sports API, the publishing homepage of which is http:// World cup.sfg.io, and the document homepage URL is https:// github.com/estiens/World Cup JSON. 2018 world cup first game information is shown in the JSON data structure, fifa _ ID marks ID of the game, weather contains weather information of a game area on the day of the game, attendence shows audience number of the game, office contains a staff list of the game, home _ team and away _ team introduce information of two battle arrays of the game, home _ team _ events and away _ team _ events contain judgment and penalty events of two battle arrays in the game, and home _ team _ statistics and away _ team _ statistics contain game data statistics of battle arrays in the game.

Fig. 3 is a tree structure diagram based on JSON data transformation obtained in step two of our method. In the figure, tree _ root is a root node (root) of the MDT, index _ node is an index node (INode), and data _ node is a data node (DNode). Under a root node TRoot with a level of 1, each INode with a level =2 contains information of a game, and each node of the lower layer represents an attribute and a value thereof. If the home _ team _ statistics attribute of level =3 includes the attributes of on _ target, off _ target, block and offsets, then the nodes of on _ target, off _ target, block and offsets of level =4 are created under the home _ team _ statistics node as DNode. In the MDT of fig. 2, the attribute isMark =1 of the TRoot, because 64 game information of the 2018 world cup is returned in array form; except for the root node, the nodes with child nodes are index nodes, namely in JSON data, the nodes with VALUE of ARRAY type or OBJECT type are index nodes; the leaf nodes in the MDT are data nodes, namely, in JSON data, nodes of which the VALUE is not of an ARRAY type and is not of an OBJECT type are all data nodes. FIG. 2 shows a tree model of the JSON data of the 2018 world cup.

Fig. 4 shows a tree structure diagram after JSON data pruning. The information of "race 1" to "race 64" is returned in array form, i.e., isMark attribute value of TRoot is 1. Each match data contains the same attribute, namely the substructures of each match data are consistent, and the information structures of all matches can be known only by keeping the information structure of one match, so that the branch of 'match 1' is kept, and the information of other branches is cut. In the attribute of home _ team _ event under the branch of "race 1", each event is used as an array element, each event contains four attributes of id, type _ of _ event, player and time, and the information structure of all events can be known only by reserving one array element, so that the branch of the first event is reserved, and the information of the rest branches is cut. The simplified MDT can be obtained by pruning as in step three for all isMark =1 nodes in turn.

By using the method, various graphs of 2018 world cup data can be generated, such as a histogram of a first round of group competition information summary: the horizontal axis is attempts _ on _ good, on _ target, off _ target, blocked, wookwork, corners, offsets, ball _ solicitation, pass _ access, distance _ covered, ball _ retrieved, tracks, clearages, yellow _ cards, red _ cards and result _ committed, the vertical axis is a numerical value, the legend is the names of 32 countries participating in the game, and the bar chart can show the representation of each country team in each index and can obviously compare the levels among the countries; a pie chart summarizing the semi-finals information can also be generated: the legends are france, england, belgium, and crodilia participating in semi-finals, where the comparative indices for the eight pie charts are: shooting times, ball feeding times, ball shoveling times, breaking times, ball passing accuracy and gate keeping success times, wherein the performance of each team in the aspect can be known according to the proportion of legend colors corresponding to countries in each graph; a radar map of a conclusion summary can also be generated: polar axes are attempts _ on _ good, on _ target, off _ target, blocked, offsets, horns, ball _ stress, pass _ access, distance _ covered, ball _ retrieved, tags, clearages, and fog _ committed, and the diagrams are France and Crohn, the radar map can show the capability distribution of two teams in each index, the goalkeeper of the French team is very excellent in defense, and the Crohn team is very violent in attack.

Claims (10)

1. A REST architecture style oriented service data visualization modeling and matching method in a cloud computing environment is characterized by comprising the following steps:

the first step is as follows: the architecture for constructing the service data visual modeling and matching method comprises three modules: a data modeling, graph modeling and matching engine;

1.1, data modeling: REST service acquired from Internet is analyzed by an analyzer and then registered, the REST service is stored in a cache or a Database, the acquired REST service data based on JSON is automatically called, the service data is converted into a standardized model through service data modeling, and a main data structure is extracted to generate a metadata tree (MDT);

1.2, graphical modeling: carrying out data structure analysis and induction on graphs supported by various configuration type visualization tools, sorting out a general data structure and a data mapping relation of a main graph, carrying out visualization graph modeling according to the information, and creating a descriptive visual model VT;

1.3, matching engine: calling MDT generated by data modeling, searching data structure fragments matched with a graph structure model in VT from the MDT to inquire the graph type which can be generated by source data, and automatically generating a visual graph according to mapping relation information;

the second step is that: defining a metadata tree MDT, including a root node TRoot, an index node INode and a data node DNode, and simultaneously using depth level to represent the number of layers of the nodes in the tree structure, wherein the root node defaults to be the first layer, namely level =1, and the steps are as follows:

2.1, root node: a root node of the MDT, namely a starting node of the MDT;

2.2, index node: representing each KEY KEY in the JSON data, but not including KEYs of 'KEY-value' pairs in the innermost layer of the JSON data, wherein the index nodes are non-root nodes and non-leaf nodes;

2.3, data node: representing the key-value pair of the innermost layer in JSON data and storing the key-value pair as a leaf node;

the third step: reading JSON data returned by the called REST API, taking a JSON data set ds as the input of a modeling algorithm, and carrying out tree structure modeling on ds, wherein the steps are as follows:

3.1, creating an MDT with a root node as a root node, wherein the root node is a starting node, and the depth level of the root node is defaulted to be 1;

3.2, reading a JSON data set ds, if the ds is read for the first time, setting a first element of the ds as a current element, wherein the element comprises a keyword KEY and a VALUE VALUE thereof; otherwise, setting the next element of the ds as the current element; if the outermost layer of the JSON data is ARRAY, the isMark =1 of TRoot, and the ARRAY Num of the element number is the ARRAY element number;

the fourth step: through a pruning method, basic data structure information is reserved, the same repeated data structure is pruned, the size of the model is reduced, the basic data structure is reserved, and the query overhead caused by the JSON data structure is reduced;

the fifth step: classifying the visual graphs, summarizing and summarizing the attributes and structural features of various graphs, and creating a visual model tree VT through modeling to formally express various graph information;

and a sixth step: and matching and querying the visual model tree VT and the MDT, searching the MDT for the fragments matched with each structModel of the VT, and performing data Mapping according to Mapping information to generate a visual graph.

2. The REST architecture style-oriented service data visualization modeling and matching method in a cloud computing environment as claimed in claim 1, wherein the processing procedure of the fourth step includes the following steps;

4.1, traversing the root node and the index node of the MDT layer by layer according to a breadth-first strategy from the TRoot with level =1; the breadth-first strategy is to traverse the MDT layer by layer according to the level, traverse is started from the first layer with the level =1, and after the node traverse of the level layer is finished, the node of the level +1 layer is continuously traversed;

4.2, storing the TRoot of the MDT into a traversal queue;

4.3, reading the ismask attribute of each node according to the sequence of the traversal queue;

4.4, stopping traversing when all the data nodes are in the traversing queue or the traversing queue is empty, and ending the method;

and 4.5, outputting the MDT after pruning.

3. The REST architecture style-oriented service data visualization modeling and matching method in the cloud computing environment according to claim 2, wherein the processing procedure of the step 4.3 is as follows:

4.3.1, if the isMark attribute value of the traversed node is 1, reserving the first child node of the current node, cutting off the rest child nodes and the sub-tree structures of the child nodes, and jumping to the step 4.3.4;

4.3.2, if the isMark attribute value of the traversed node is 0, no operation is carried out, and the step 4.3.4 is skipped;

4.3.3, if the traversed node is a data node, deleting the current node from the traversal queue, and jumping to the step 4.3;

4.3.4, adding the child nodes of the currently traversed node into the traversal queue, deleting the current node from the traversal queue, and then jumping to the step 4.3.

4. The REST architecture style oriented service data visualization modeling and matching method in the cloud computing environment according to one of claims 1 to 3, wherein the fifth step comprises the following steps:

5.1, the definition VT comprises two parts of basic attribute BASICATTRIBUTE and visual structure DVSCHEMA, and the formalized definition is as (11), wherein the BASICATTRIBUTE stores a graphic title and a subtitle;

(11)、VisualModel::＝<BASICATTRIBUTE><DVSCHEMA>

5.2, BASICATTRIBUTE includes three attributes: title, subtitle and attribute attributes, wherein the formal definition is as shown in (12), the title is used for storing a title of a finally generated visual graph, the subtitle is used for storing a subtitle of the finally generated visual graph, and the attribute is used for storing setting parameters of a position, a color combination, a font and a font size of the finally generated visual graph;

(12)、BASICATTRIBUTE::＝<title><subtitle><attributes>

5.3, the basic visualization graph can be generalized into four basic categories according to the data type, the graph data structure and the graph dimension required by the graph: general graph General, topology Map, map, text graph Text, formal definition as (13);

(13)、DVSCHEMA::＝<General><Topology><Map><Text>

5.4, the four basic categories subordinate in step 5.3 respectively comprise two attributes: the graphic type and the graphic structure, VType stores the category of the graphic, the structModel stores the basic visual structure of the graphic, the formal definition is (14), A:: B' represents that A contains attribute B;

(14)、DVSCHEMA::＝<General><Topology><Map><Text>::<VType><StructModel>

5.5, in the step 5.4, the four basic categories have respective mapping relations, and describe data structures, data dimensions, graph structure relations and data mapping position information of various graphs; and abstracting a basic visual structure structModel of various graphs according to Mapping information and by combining a data structure of the graph, and matching the MDT generated in the third step with the structModel to judge which visual graph can be generated by the returned data of the REST API.

5. The REST architecture style-oriented service data visualization modeling and matching method in the cloud computing environment according to claim 4, wherein the processing procedure of the sixth step includes the steps of:

6.1, resolving the four basic types of structModels in VT, extracting a temporary root node and a substructure thereof in each structModel, taking a tree structure segment formed by each temporary root node and the substructure thereof as a query subgraph, and extracting six query subgraphs according to the steps 5.1 to 5.4: the substructure with the Root of the General type structModel as the starting point, the two substructures with the Root1 and the Root2 as the starting points respectively for the subordinate of the Topology type structModel, the two substructures with the Root1 and the Root2 as the starting points respectively for the subordinate of the Map type structModel, and the substructure with the Root of the Text type structModel as the starting point;

6.2, taking the MDT as a target graph, taking six query subgraphs in the 6.1 as input in sequence, traversing the MDT once when inputting one query subgraph, and searching for an MDT segment matched with the currently input query subgraph;

6.3, traversing the MDT layer by layer according to the breadth first strategy;

6.4, storing the nodes of the MDT into a traversal queue Q from the TRoot in the sequence of the number of layers from small to large;

6.5, according to the sequence of traversing the queue Q, the currently traversed node N _i Putting the set S1, and putting the temporary root node M of the query subgraph into a set S2;

6.6, comparing whether the structures of the nodes in the S1 and the S2 are consistent, namely whether the parent-child relationship of each corresponding node in the S1 and the S2 is consistent; if the structures of the nodes in the S1 and the S2 are consistent, sequentially adding the nodes in the set L2 of the child nodes of the M into the set S2; skipping to step 6.8;

6.7, if the structures of the nodes in the S1 and the S2 are not consistent, setting i = i +1, clearing the S1 and the S2, and jumping to the step 6.5;

6.8, adding a node L2 in S2 every time _k Then, go to step 6.9;

6.9 reading node N _i The nodes in the set L1 of the child nodes are sequentially added into the set S1, and each node L1 is added into the set S1 _j Performing primary structure matching with S2;

6.10, if the nodes in the L1 and the L2 are traversed, clearing the L1 and the L2, then finding out original nodes corresponding to the leaf nodes in the S1 in the MDT, and regenerating the child nodes of the original nodes into the L1; original nodes corresponding to the leaf child nodes in the S2 are found out in the query subgraph, the child nodes of the original nodes are regenerated into L2, and the step 6.6 is skipped;

6.11, if the nodes of the query subgraph are all added into the set R2, storing the structure in the set R1, clearing the set R1, the set S2, the set L1 and the set L2, setting i = i +1, and jumping to the step 6.5;

6.12, after the nodes in the traversal queue Q are traversed, inputting a next query subgraph, and repeating the steps 6.5 to 6.12;

6.13, until the six query subgraphs complete the query, mapping the data in the MDT to a graph structure of a corresponding type according to the Mapping structure according to the output matching result set R, thereby generating a visual graph.

6. The REST architecture style-oriented service data visualization modeling and matching method in the cloud computing environment according to claim 5, wherein the processing procedure of the step 6.9 is as follows:

6.9.1, if S1 and S2 are successfully matched, setting k = k +1, and adding a node L2 to S2 _K Skipping to step 6.8;

6.9.2, if the matching of S1 and S2 fails, removing the node L1 which is just added in S1 _j Setting j = j +1, adding node L1 to S1 _j And jumping to step 6.9.

7. The REST architecture style oriented service data visualization modeling and matching method in the cloud computing environment according to one of claims 1 to 3, wherein in the step 2.1, the root node contains the following information:

2.1.1, star mark isMark: recording whether the outermost layer structure in the JSON data is an array type, if so, marking by 1, and if not, marking by 0; the isomark formalization definition is expressed as (1) (2), the data type of the isomark is a NUMBER, if the VALUE in the key-VALUE pair in the JSON data is an ARRAY, the isomark =1, otherwise, the isomark =0; "#" is a data type delimiter, ":" = "is an assignor," A → condition ≦ B ": < C >," C "-" indicates that if A satisfies the condition, the formula value is B, otherwise the formula value is C;

(1)、“isMark”#<NUMBER>

(2)、“isMark”::＝〖“VALUE”→ARRAY⊕<1>:<0>〗

2.1.2, number of elements arrayNum: if the ismask of the current node is 1, recording the number of array elements, and if the ismask of the current node is 0, marking by 0; the formalized definition of arrayNum is expressed as (3) (4), the attribute VALUE of arrayNum is a NUMBER NUMBER type, if the VALUE VALUE in the key-VALUE pair in JSON data is ARRAY, the arrayNum is equal to the length of the VALUE ARRAY, otherwise, the arrayNum =0;

(3)、“arrayNum”#<NUMBER>

(4)、“arrayNum”::＝〖“VALUE”→ARRAY⊕<ARRAY.length>:<0>〗。

8. the REST architecture style oriented service data visualization modeling and matching method in the cloud computing environment according to one of claims 1 to 3, wherein in the step 2.2, the index node contains the following information:

2.2.1, node name: the name data type is STRING STRING, and the name attribute value is a keyword KEY in a KEY-value pair in JSON data; name formalization definition expression is (5) (6);

(5)、“name”#<STRING>

(6)、“name”::＝<KEY>

2.2.2, node value type vType: the vType is the data type of a VALUE VALUE in a key-VALUE pair in JSON data, and the attribute VALUE is one of an OBJECT, an ARRAY, a character STRING, a NUMBER, a TRUE and a FALSE; the vType formalization definition is expressed as (7);

(7)、“vType”::＝[OBJECT|ARRAY|STRING|NUMBER|TRUE|FALSE]

2.2.3, star mark isMark: recording whether a VALUE VALUE in a key-VALUE pair with the name of the current node as a keyword in JSON data is an array type, if so, marking by 1, and if not, marking by 0; the isMark formalized definition is expressed as (1) (2) in step 2.1.1;

2.2.4, number of elements arrayNum: if the ismask of the current node is 1, recording the number of array elements of the VALUE VALUE in the key-VALUE pair, and if the ismask of the current node is 0, marking by 0; the formalized definition of arrayNum is expressed in the same steps as (3) (4) in step 2.1.2.

9. The REST architecture style oriented service data visualization modeling and matching method in the cloud computing environment according to one of claims 1 to 3, wherein in the step 2.3, the data nodes contain the following information:

2.3.1, node name: saving a KEY in a KEY-value pair in JSON data, wherein the data type is a character STRING STRING; the name formalization definition is expressed in the same way as (5) (6) in the step 2.2.1;

2.3.2, node value nValue: the data type of the nValue is STRING, and the attribute VALUE is VALUE VALUE in a key-VALUE pair in JSON data; the nValue formal definition expression is shown as (8) (9);

(8)、“nValue”#<STRING>

(9)、“nValue”::＝<VALUE>

2.3.3, node type: saving the data type of a VALUE VALUE in a key-VALUE pair in JSON data as 'str', 'num' or NULL, wherein the 'str' represents that the data type of a type is STRING, the 'num' represents that the data type of the type is NUBER, and the NULL represents that the attribute VALUE of the type is NULL; the type formalization definition is expressed as (10);

(10)、“type”::＝[“str”|“num”|NULL]。

10. the REST architecture style oriented service data visualization modeling and matching method in the cloud computing environment according to one of claims 1 to 3, wherein the processing procedure of the step 3.2 is as follows:

3.2.1, if the data type of the VALUE is not OBJECT and is not ARRAY, creating a data node with the depth of level +1, wherein the name of the node is a keyword KEY, the VALUE nValue of the node is the VALUE, and the type of the node is the data type of the VALUE; after the completion, skipping to the step 3.2;

3.2.2, if the data type of the VALUE is ARRAY, creating an index node with the depth of' = level +1, wherein the name of the node is a KEY, the type vType of the node is ARRAY, isMark =1, and the number of elements, arrayNum, is the number of elements in the current VALUE ARRAY;

3.2.3, if the data type of the VALUE is OBJECT, creating an index node with depth' = level +1, wherein the name of the node is a KEY in each OBJECT element, and the type of the node VALUE vType is the data type of the VALUE VALUE in each OBJECT element; if the current vType is ARRAY, the isMark =1, and the element number arrayNum is the element number in the current VALUE ARRAY; if the current vType is not ARRAY, then isMark =0, arrayNum =0;

3.2.4, taking the VALUE array in the step 3.2.3 as a new JSON data set ds', and skipping to the step 3.2.

Images