copycat82 is a Ph.D. dissertation which plagiarizes. This page is about the immense faultiness of copycat82/83. (copycat83 is the associated, published paper.) The precise commentary, are in the forms of links to the page-by-page raw dumps section. Here, we will specialize on the varieties of faultiness in copycat82. Another article specializes in discussing the self-contradictions of copycat82, which may be considered a subset of the error category, and may be taken as more direct evidence for its plagiarism.
copycat82 is unoriginal. No original questions, no original answers. What is left, then, is a fault-prone method that cannot manage those cut-and-pasted ideas, together - when they bump at each other. And further un-credible is the immense amount of errors in the examples of copycat82. In other words, not only the method claimed by copycat82 cannot really work, in general, but even the examples in those trivial figures are not correct. There are a lot of such faulty examples, both with unmodified Petri nets, and with the "modified" (imitative of the prior art).
This comes very especially surprising because, after all, copycat82 claims to be a method-proposal in the field of designing and analyzing software. If even the Ph.D. recipient cannot show us any major examples, and even among the smallest, there are a lot of errors, who would care to use that method?
How did the jury, who must have been composed of professors in the field of design and/or analysis, granted a Ph.D. for a text, that is full of errors? (Not to mention the unoriginality, and other lack of achievement.) The suggested method is very obviously not working, and he/they did not even care to; Otherwise, copycat82 would analyze and correct its own errors, at least in the examples with Petri nets, even if not those that come out of an ignorance of the programming process, or of the computer science, in general. The situation of the jury is awkward, and I felt obliged to include an article that discusses standing against manipulations when making decisions.
copycat82 increases the crowdedness of the figures, by collapsing together what the other researchers had finely identified, and separately-placed. It is useless-duplication, in most cases. The text (program fragments) in the rectangles, get duplicated in the form of arrows to/from rectangles that have data-item and data-type names in them. The set of data-item names traveling with a token, each get their names listed as a separate "data-item" rectangle. etc. etc.
All of such appear to be only commentary for the human reader; no machine-processability with it. Not to mention the confusion that the crowdedness may lead to, when two different concepts of event-sequencing, and the (shared) data-hierarchy get collapsed into one - when the separately-standing, internal, data-hierarchy/network is shown within the same graph.
E-nets keep them within token-attributes, and environment variables, out of visibility, although readily implicated, within the program fragments. VD78, as LOGOS, keeps two separate graphs, control- versus data-graphs, that have their points of one-to-one correspondence, through transition-to-operator labels. They are mergable at points where the nodes are one-to-one (in the examples, but in general, they are possibly many-to-many. This would explode the collapsed single-graph.
And furthermore, if the human writer, because of finding that process tedious, gets sloppy, the human reader does not benefit, at all. Even the very copycat82 is an example, itself. Even the Ph.D. grantee himself does not follow his own figure-drawing requirements, as evidenced by many examples of copycat82 that breach its own figure-drawing requirements.
At this point, we may consider the acknowledgement on page iii of copycat82, where it expresses "Thanks are also due to Dr. _pqr_ for his patience in drawing most of the figures." But such a comment cannot relieve the responsibility of the Ph.D. nominee. We do expect the Ph.D. nominee to have first prepared the figures with his hand-drawing, then Dr. _pqr_ put them into a cleaner form, and of course then, the Ph.D. nominee must have surely looked at the results. Right? Or, is it too boring? Are we expecting too much from a Ph.D. grantee? And what does all this suggest for the whole utility of drawing all those rectangles, and crowding the figures?
Please notice that, there are at least three Ph.D.s there - save the jury. The nominee, the (acknowledged) figure-drawing person, and then, the next year (1983), after the Ph.D. degree is granted, there gets even a paper published, late in that year, in the november issue of a journal. The name of the advisor also passes as an author. How could such errors still persist? How would you use that, for example, for flight control in airlines, or in earthquake-time management of city electricity? Could it be for verifying anything worthwhile? Would you trust your life to it?
Editing this page is not finished, yet. I may later discuss/organize about the fault-groups, through this page, too, but it is sufficient to point at the pages, in the page-by-page, raw dumps section, because most of those pages, almost, if not exactly, by definition, discuss the faults, anyway.
If there were any fresh ideas, and/or any full grasp, then republishing parts from such previously published literature, would not be a problem - if they were, appropriately cited, though. In fact, in such a case, like many other researchers, copycat82 would have provided some incremental work, even if not all-new. Among the (prior art) papers we discuss, Danthine (1980) is most like that. With that strategy, a researcher may cite previous research by others, while integrating and/or contrasting his/her own contributions with them - as long as it is not trivial cut-and-pastes, and not self-contradicting. Plagiarism (not citing of others's previous work, where it is due), is only an indicator excessive-greed-but-low-achievement. This was, then, especially a duty for the Ph.D. jury to detect, before licensing that Ph.D. nominee with a title.
Let alone any original work for a Ph.D. The problem is even worse with copycat82. It does not fulfill even the requirements for an undergraduate project, which do include, making sure the thing works. Neither the faulty examples for a project/dissertation no other than about design-and-verifying of systems, nor the cut-and-paste presented as a (fault-prone) method. Neither would do.
The term faulty (errorful) refers to the errors that have been observed. The term gotchaful (error/fault-prone), is different, but relevant. The fault-proneness of the "method"(s) is not only a problem when providing a few examples for the publication. In fact, providing a few toy examples that may work correctly with any given method could have been trivial, but certainly not sufficient in the field of analysis, and not even in the general field of design, because any potential user, whether a practical programmer, or some academician, he/she would like to apply the method within a suggested range of applicability - not only with the hand-picked examples, but copycat82 is vague about it, and even its own examples are faulty. With such a fault-prone "method"(s), copycat82 is not employable. You have to go to the original, prior art, to find out what had been working. Period.
The plurality of the term "method"(s) is in the sense of multiple-personality-disorder, with-respect-to the source papers that have been unreflectingly pasted. Otherwise, no new method exists.
Unable to verify, unusable for design, and full of faulty examples.
Instead of waiting till the last punctuation mark was put, for this case study, I submit it incrementally. This is fine with my publishing strategy. Especially fine, when the readers may have questions, too.
If at any point, you have questions, please, ask me. Asking may also speed up the publishing of further content for this page. This site as a whole, is in its start-up release phase. Therefore, reader requests may mean a lot in the page-release-timing.
If you think what this page tells, is important, or simply a good-reading, then please keep visiting again, to find out about new content. And you may also tell your friends with similar interests.