Ready.
The copycat82 plagiarizes. Such a cut-and-paste is trivial, and could have been a product of a kindergarten kid, because it is only a trivial scissors-and-glue job. It is lacking any sound reasoning/reflection about the appropriateness of the graft.
If not for the exaggerated amount of faultiness, a lollipop could have been appropriate, esp. for a kid, doing that work. But of course, a Ph.D. title is not a lollipop, and the jury is not giving it out of their own pockets.
If reading these pages with kids, or with whomever, whatever the age, the more responsible person(s), should tell/warn the others that the case study we are discussing, is not a role model. This presentation's being step-by-step, is not meant to be any example, for anyone. We are against plagiarism, and our discussion should make that clear, any way.
Pick NN73 (it is the well-known Macro E-nets paper). It presents a visual/graphical net, and a separate, formal text. Write (or, cut-and-paste that formal text, piece by piece, within the net. If a location is for tokens with token-attributes, draw attribute-count parallel paths, between the transitions before and after it, and write the name of each token-attribute, in one of those separate, parallel paths. Next, when you see a transition name, ai, write the text of its transition-procedure, as a rectangle, and paste it. This is all.
To make it appear "something different than E-nets" you may abridge E-net gate-logic, and draw it with SARA (UCLA graphs) looks, with static i/o operator macros, as operator signs, between in/out arcs. With this final bit of make-up, it is precisely copycat82.
If you do this with kids, you may get a few questions, as the, however little, inquiring minds, may want to know. Here is a quick-list of answers:
Yes. The Enets (NN73, and Da80) formalism/text has been presented in SARA'ish looks. But the make-up is rather thin, and copycat82 translates even the trivial i/o control macros so inappropriately that, it has problems even there.
More critically, you should keep in mind that, SARA is a software system. This was its important aspect. For example, in its CFA module, SARA would expand those SARA SL modules, then do a reduction to speed it up, all of these without any further programmer/designer effort. Therefore, we should not compare the softwareless copycat82 with SARA, only because it imitates a few shapes.
VD78 is a self-contained, single paper, coupled with E-nets, or alone, could teach copycat82, about properly reducing subnets as transitions. When you cut-and-paste, the relevance of this may not be apparent, but copycat82 falsely assumes those hodge-podge subnets/macros it presents to be verifiable separately, without first expanding them as macros within a whole graph - somehow. That cannot work. VD78 is the fine comparison.
In summary, E-nets and VD78, together, or even as single papers, both, were already beyond copycat82. i.e: Even what copycat82 attempts, but cannot do, had been already published. The multiple cut-and-pastes have bumped into each other, and disabled each other.
Almost full E-net formalism (except the resolution-locations) have been copied by copycat82 (from NN73, and Da80), in text. But in the graph, it is abridged. The "resolution procedures" have a vague existence. If only words (not procedures/programs) would do, you may write these, imitative of SARA control-nodes, within that bubble/rectangle - instead of the transition-procedure. There are no other/available places, for the "resolution procedures" in the copycat82 graphs, either.
SARA, within its interpretation domain, manages the resolution with the "@output_arcs =" statement. This variable, in SARA, corresponds to the "resolution location" in E-nets. SARA does not manage any input_arcs, like this, though.
The text within a copycat82 resolution procedure, resembles a SARA "@output_arcs=" statement, if not exactly so. The difference is that, it is kept separate, as with E-nets. i.e: It does not modify data, and it refers to the data-value at the entrance (i.e: before the transition-procedure modifies the data) - although it manages only the exit-gate; not the entrance.
It has changed the names. Instead of "E-net", or "system", the new name in copycat82 is "distributed software system" although there is nothing new/different about the system (especially, after Da80 had already discussed networked/distributed systems).
A schema-without-resolution (as with T-, F- and J-transitions) is renamed as "data-independent-control-transfer-specification," a schema-with-resolution (as with Y- and X-transitions) is renamed as "data-dependent-control-transfer-specification." The transition-procedure is renamed as "data-transfer-specification." A subnet/transition and a macro, both, are renamed as "software components," although they are necessarily different.
Only the ordinary Petri net transitions are called "transitions" but they are not seen around, any way - except in a single section, where those trivial-yet-faulty entrance/exit control macros are attempted to be built. Not to mention that, (1) those Petri net transitions are a bit different-than-usual, with their "expected" (zero-wait) timing behavior. This may verify, but with an ordinary Petri net verifier, you would generate a lot of irrelevant states. (2) The verifier must be abandoned, though, in favor of an E-net verifier, if the 1-boundedness is not to mean, "dump/discard whenever a token is blocked/waits by a token before it." (3) It is those vague "component"s that defy any verifying, unless expanded as macros, as NN73 suggests. Otherwise, a Petri net verifier cannot make any sense of a "transition" that fires but only some of the in/out places/locations may be involved.
You could merge VD78 data-graph into its control-graph, to get the same result, visually - except the SARA i/o control macro operators between the arcs. VD78 differs from E-nets with how it manages the subnets. Because it verifies nondeterministically, proper reductions are valuable, to speed up. This is irrelevant for a deterministic simulation (as NN73 does). Otherwise, the representations are mappable to each other. A T-transition of E-nets, corresponds to a VD78 subnet, and through the label associated with each subnet, it is trivial, but undesirable, to merge with the data-graph. They are fine to keep separately, linked through labels, especially if you mean to study distributed systems. To find out what all these papers study, you may visit the review pages, at this site. (NN73, Da80, VD78)
Think of basketball. You let L.A.Lakers, and Chicago Bulls in separate rooms, and you claim to have run a match. That does not count.
In other words, when two entities are supposed to be interacting (in real time) , you cannot do a static reduction, to save time. It is not any "saving of time" then, because it dumps the real thing.
Both. In a single sentence, a copycat82 "component" corresponds to a SARA SL module, the socket(s) of which is/are turned inside-out, such that the i/o control logic, and the data links, would crowd the SARA SL hierarchy. As a result, it is faulty to employ it with more than a single socket, and there should be no socket-calls from it, either. Other wise, that would confuse a Petri net verifier (unless you expand it as a macro, and let see what is inside it). This is the same idea as the nonprimitive Petri net transition idea. VD78 subnets are similar/fitting, too.
Yes. As already discussed, copycat82 plagiarizes the representation from E-nets, while the verifying is in VD78 (Petri nets reachability, with separate subnets) terms. Furthermore, the restrictions are not observed by copycat82 itself. Therefore, its "components" tend to become meaningless. The increased non-determinism exponentially increases the in/out possibilities, when in/out partial-firing is possible.
No. The copycat82 examples, imitative of SARA, even include branchings, similar to SARA SL socket calls. This must be a macro, then, and it must be expanded, before a verifier could make sense of such multiple in/out paths. No discussions, there.
No. A repeated-output ("superscript") is only a dumped idea, without any application demonstrated with it. But whatever the application, even the possibility of a repeated-output, may totally disable a verifier. The verifier must expect any number of tokens, any time, from any transition that was once enabled. Again, as we discussed, all this is relevant, unless all of the non-uniform, non-reduceable macros/subnets are expanded. But there, copycat82 does not provide anything, either. In fact, with the advertised (but not studied, not published) abstract data types, if used, with a net, they must be equated/expanded as a net, too. Otherwise, the total chaos is permanent, for the verifier.
A single "component" may absorb/generate any number of tokens, when/once enabled. This is a problem, especially because when verifying, the resolution procedure is ignored in copycat82.If you acknowledge, but ignore, repeated ("superscript") token-output, this may occur any time, after once enabled. By contrast, Da80 had employed E-nets (in a Petri net context) such that it preserves the expected token in/out unity. An X-transition would not fire zero/five/eight/infinite/unknown times, after a token enables it.
With macros, you may build almost anything. With E-nets representation, even that keeps fine, especially because, even when multiple independent paths may exist in/out of a macro, you may trace where any resource is relevant. These are in the token-attributes. Therefore, the many phases of a communication may refer to different resources/data, and nothing would be confusing. SARA is similar, as it confines the data-links within the particular socket, where it coheres with the in/out control phase in/out of a SARA SL module.
The other problem, as we discussed, is the breaching of representation. If a subnet, when its inner-structure is not visible, has not-so-clear in/out relationships, a human user may not make sense of it, either. This may relate to the application-designer, rather than the representation/formalism, but that is relevant, too. After all, copycat82 has many erroneous examples, too. When tracing what it is supposed to mean, you keep discovering the errors. Even the Ph.D. grantee, has given up, it appears, when a few examples had to be presented.
The quirkiness of the i/o macros may make things meaningless, too, as we discuss in these pages.
For discovering a single-source plagiarism, a simple comparison may suffice. We may trace similarity of content , with possibly different names, and/or with a shuffling of its parts. For a well-read person, a single-source-plagiarism may be recognized more readily.
With multiple-sources, the copied chunks may bump into each other, and may be noticed by anyone, upon closer inspection, as glaring/screaming at the seams in the copy-center, even before locating any of the source papers. That is the case with copycat82, which cuts-and-pastes from a few.
You may read about those tutorial and/or research papers, through the page that points to the similarity, and the non-contribution of copycat82, presenting the prior art, that had been published, by others.