Ready.
The so-called "single" graph of copycat82, ignores any ADT structure, although copycat82 claims to introduce ADTs. Where would copycat82 show ADTs, if at all? The worse than trivial, quirky plagiarism of copycat82 leaves it as a subset of each of those (prior art) papers it attempts to copy. VD78 is one of those sources. (SARA is another such source, w.r.t. the association of control- and (LOGOS)data-graphs.)
copycat82 advertises ADTs, but does not even provide a single [complete] example of it. No type studies by copycat82, at all. The data-types, in a sense of data-operators to refer to data, already had existed, e.g: with data-graph of VD78 (after LOGOS). VD78 links that with the control-graph, through labels. Next, although copycat82 translocates those data-item names to the control-graph, through the one-to-one links of transitions, to the (already used) data-operators, the rest of the functionality is lost. To represent the data-types, such a second graph is still needed.
Va76, the Ph.D. work, associated with VD78, is referrable for the third-level of the analysis, in VD78 methodology. It is the assertional-proofs, with first-order predicates. Next, copycat82 adopts the E-net (Nu72,NN73,Da80) formalism, and also appears to attempt to achieve the VD78 functionality. But it is only plagiarism. The advertised ADTs, scream their extra needs. A trivial assumption to supplement such needs, would only arrive at (the unabridged) VD78, or similar. That means, it is part of the story of the plagiarism of copycat82, the un-credible Ph.D. - esp. the data, and resolution.
Must a data-type-operator wait for the event-orders to be fixed? e.g: If an example net does not refer to any FIFO-remove operator, would that data-type only contain push, pop, etc.? A collapsed "single graph," which mentions ADTs but without a separate graph for data (or, data-types), would only mean that.
NN73, as a prior art, with a single-graph, does not do the data-modeling, other than the localization of the data between two subnets - at the token-attributes. The environment-variables (global data) are modelable with any available tool. The E-net formalism minds only the results. The procedures/predicates are listed, and when they run, they set a specia location, referred-to as the resolution-location, to manage the token-flow preferences. It is possible to shunt it for a constant preference/value, too.
copycat82's fake-claims about the ADTs, post only text-labels, without any of the referred.
Textual commentary, other than the "single" graph, still essential. Without captions, and the accompanying text, if any, the examples may not make sense.
ADTs would need their own separate graph (cf. VD78), (if ADT-dependency networks are (visibly) represented, at all. The variable/ADT name serves only as a label, similar to VD78 control-transition to data-operator labels. If VD78 was not a single-graph, how is copycat82? By its ignoring that ADT-dependencies graph?)
Forget about the abstract data types. There is a single example, the end-of-the-Ph.D. example, with two relatively complex variables (although, still a boolean array, and a binary semaphore variable), and for example, It is only stated to be such, in the text: "sv: Binary semaphore to control access to all of above data objects, except the first two." This is all it says! No abstract-data-type, and/or any integration of the behavior of "sv" to the Petri net graph. It is only a name in a rectangle. There are no hints how other complex (non-boolean) variables would be handled, either. Deals only with the very most trivial, in its examples, and it is still faulty.
No type studies, whatsoever, in copycat82. It would puzzle a reader who credits benefit-of-doubt, to the un-credible Ph.D. If no need to study ADTs in any examples, why bother mention them? Only to divert attention, to camouflage the plagiarism?
If a "type" exists only when instantiated, if it cannot represent yet-unused features, then why even mention the "data-items" and "data-types," at all? They are redundant because the code-fragments in the control-node rectangles (similar to SARA/UCLA graphs) already tell what happens with the data.
Even if the code-fragment is not implemented, yet, if the data-relationships are known, a simple textual note could again be placed. After all, the figures are insufficient, and you have to read the commentary in the text also, to learn what each data-item stands for. You keep shuffling between those crowded/cluttered graph chunks, and also read the commentary in the texts. Is this a "single-data showing everything?" Or is it a haphazard merger, without citing the sources, where due?
The fake claim of copycat82 about ADTs, was presumably, an attempt to do what VD78-methodology does in its second and especially the third levels. But we may only guess such, because copycat82 does not present any type-studies, and/or any simulation-and/or-proof examples. It is only incomplete figures, with vagueness.
Even the data-graph of VD78 might qualify as a sort of data-type graph, because it associates data-operators with data-items, as a repository, where we may study a type, whether or not any (or many) of the data-operators are referred by the control-graph. The control-graph does not have to know the (internal) validity-criteria of a data-operator, or to how many data-items it refers to. VD78 does state its reasons to keep those graphs separate. Data and Petri nets come together only when relevant.
i.e: copycat82 collapses the data-operators/predicates, with control-transitions. VD78 had already associated the link, through labels. So, it is only a worse than trivial idea to collapse them, as a "single" graph which both explodes the graph size, and cannot represent the studied-but-uninstantiated-yet data-operators/predicates, anywhere. VD78 and SARA keep them separate. That is for a good reason. Although there are cases, where control-and-data may get tightly together, such cases more readily, fit the E-net token-attributes, as they travel with the token. A data-collapse is a nightmare.
In the example Fig.3 of VD78, the associations were one-to-one. To merge that would only mean clutter, as it is to merge, two entities, with their separate-logic. And it ignores (i.e: cannot represent) any data-operators or data-predicates, unless they were already associated with a control-transition. The case is even worse, if copycat82 attempts to merge the likes of VD78 Fig.7, where the data-predicate QA is referred-to, in three labels. That is one-to-many relationship, and its merged size, explodes. It also means that, unless it is kept as a module, elsewhere, the same chunk would appear at several places, around a net. These problems were already known, in 1970s, as the problems of the unnormalized database tables (or, relationships, graphs).
Likewise, for NN73, as resolution-locations of E-nets, standardized only the data-interface - with everything-else kept within procedures-text. (Replaceable with any machine-processable procedures/predicates, as far as the interface-standard is kept.)
In E-nets, the resolution-location is the resolution-report central. The modeler may associate any sort of abstract-data-type, with that architecture, as far as the resolution-report is in the form of a path-preference index, i.e: The resolution-token.
Although copycat82 figures resemble E-nets, the machinery of copycat82 is vague. It is plagiarism - but stops one step less of a verbatim copy, and it loses workability, right there. It appears, copycat82 would not reflect to think these questions:
Both (Macro) E-nets, and SARA SL, keep data isolated. This keeps the macro-hierarchy, uncluttered. The intricacies of data, and control-preferences, are within the E-net token-attributes and procedures (listed in the listings), and SARA SL module sockets (as kept in a repository, by the SARA software system).
copycat82 both collapses everything, and next, still claims postponeability of data. It is ignorance, one way, or another.
Similar to VD78, control-transition to data-operator correspondence.
That points out the absurdity of the fake claim of copycat82 about a "single graph," too. Emphatically, the ADTs must have their own type-based organization, somewhere, very probably, in another sort of graph, but copycat82 thinks only a type-name-label, by itself, would suffice. That is especially noticeable, because when copycat82 imitates E-nets, it has already imitated the transition- and resolution-procedures. Therefore, when it also mentions the ADTs, we must ask about, what it is intended for. (It is probably some false-interpretation, about Da80.)
How to integrate control-transfer specs with data-transfer specs? Only a procedureness means the ADTs have some altogether separate existence by themselves. (a separate graph, or not. Isn't that a separate existence?) No other way appears possible. Yet, that is not enough either. If we grant benefit-of-doubt, and assume the UnPhD, had thought something, what may that be? The closest approaches are both employed by E-nets and VD78, namely standardizing the return values, so that control graph would make sense of the results (like with E-nets). Or, there will be a separate data-graph, that does all the handling itself, and only the operators correspond to the transitions in the control graph. Given that we see no such operators (the ADTs have notbeen discussed), that is also only a guess, and unlike in their case, the UnPhD' specifically mentioning a specific ADT, instead of ad hoc predicates, complicates the matter. The resemblence to VD78 would be that, they use predicates, and also let assertion-based verification with them. The UnPhD may be attempting to import the ADTs for that reason, but fails to provide anything.
In either case, either by standardizing the output, or with the suggestion (but not bringing-in) of ADTs, for assertions, in both cases, the guessing only leads to the previous literature - but the UnPhD has fallen short even in the cpying. It has left some crucial elements/discussion out.
copycat82 advertises ADTs. It also attempts to merge prior art to obtain a so-called "single"-graph.
The lack of any new ideas, points out the plagiarism of copycat82. Its immense faultfullness, and its fault-prone "method", may be the crop of the kindergarten-grade plagiarism of copycat82, the cut-and-paste monster.