Team. With the "advent" of JAVA technology plus the modern generation of "universal" virtual-machine languages and platforms during the early-1990s, the acronym "WORM" became a common computerese "buzz-word". "WORM" is a statement of one of the most obvious principles of the modern software industry and computing.
When a software engineering team at a Microsoft or an Oracle creates a new product, they build a logical model of a real world process. This logical model is "ephemeral"; and, it is eventually rendered in the physical form of "high" and "low" electronic signals on a secondary storage device. Yet, once person-hours are spent producing the first verified and validated instance of the software, replicating it becomes rather easy. This is the first of a pair of "bi-stable" concepts in the philosophy of WORM as used in JAVA parlance. The second is the most commonly spoken concept associated with "universal" virtual machine use. One can "write" a singular instance of a program in a modern high-level language like JAVA, compile it producing a object file, and "run" duplicates of that object on numerous computing nodes, wherever the appropriate "virtual" machine is available.
So, WORM is a notion closely and intricately linked with the language translation process, compilation and interpretation. And, in a sense it is a byproduct of the "bootstrapping" of modern compilers which occurred decades ago. One compiler was produced in a "base" language that permitted the production of new language translation tools for "new" languages from that "first" compiler produced in that "primitive" computing dialect.
And, it is unthinkable in this modern era that one should "write" a compiler each time that one is need in a software development process. Such would be costly and error-prone. The use of "well-designed", "formally-verified and -validated" compilers ensures uniformity among the object files produced and helps guarantee the reliability and robustness of these files when they are generated from a "correct" source file. In other words, a language translation tool was written once and checked for fidelity. Then, it was widely used.
Contrast this with the modern era of web-development which sprouted up in the mid-1990s. The generation of software development has yet fully blossomed. Much of the "core" functionality found in common gateway processes was frequently rewritten for each instance of a web-process needed. This counters a few fundamental principles of programming learnt by many college freshman and high school students studying computing. That "basic" rules is this, "If one writes a module once and well, he can place it in a single place within his system and reuse it often. This promotes the concept of a singular place of modification. Which enhances testability and product maintenance tasks."
So, why rewrite the same behavioral characteristics found within the "process" control mechanism commonly used throughout web development?
Hence, the modern era of "pre-written" controllers surfaced in the late-1990s with products like Struts and Spring for the JAVA Enterprise Edition and, in recent years, Laravel for PHP. Also, Microsoft and Oracle at a couple of large software corporation that offer a standard, reusable Model-View-Controller product.
Yet, these avatars of control are found in every software product, including those "hokey toy" examples written for introductory programming fundamental courses. They are found among the "old" text-based, menu-driven systems that were commonplace from the late-1970s, throughout the 1980s, and in the early-1990s. They are found among JAVA's Swing and FX applications plus those created with packages like Tkinter found in Python and other graphical user interface (GUI) libraries.
Although simplistic, this model of development, that uses storyboard templates which represent a description of the output views and a module of behaviors that fill-in hotspots on the "stencil" which describes the view in conjunction with a "pre-written" instance of this controller pattern, provides a WORM-like component.
It is extensible through the module of "bespoke" behaviors which supports the "general-purpose" controller and is a pattern which can be used throughout computing without the need for "recreating this wheel" each time.
Below is our diagram of interactions found among a system which uses the CABOOSE pattern and a general-purpose controller (GPC). This diagram is from the JAVA implementation which does not "currently" include an ICEMODE global with a "IceMode.java" file produced from an "Icy,java" code generator.
In our Python instance, the directory file that contains the architectural control language (ACL) does not use an eXtensible Markup Language (XML) format. Instead, it uses a sectional comma separated values file (SCSV). And, our behaviors are not part of Python classes. They are simply "user-defined" functions.
And, of course, overseeing it all is Boonie, our mascot!
Although one can spin his own controller in a few person-hours, it is this author's sincere hope that this pattern of development becomes as ubiquitous a modern language translation tools, compiler and interpreters.
It also supports the templating of "client-side" scripts and web components which also might hold replaceable "hotspots".
No comments:
Post a Comment