| ORMSware Programming Examples |
Click names of programs below (subheadings) to view logical network diagrams of each program. Some pages for the programs may contain snippets of sample code behind select nodes and arcs.
Avoiding Clutter: Notice that arcs (arrows/links/connectors) in ORMSware programming diagrams do not cross. They are similar to etches on circuit boards. Not that arcs are not allowed to cross, but the rule of thumb here is that if there is no way not to cross an arc over another in a diagram, the logic is too complex to be on just that page. Break things down, rethink, reorganize, restructure, simplify.
Node/Arc Similarities: Most properties of ORMSware arcs and nodes are same (see images below). An obvious difference is that while a node can have many predecessor arcs coming into it and successor arcs going out of it, an arc can have only one predecessor node and one successor node (one origin and one destination). However, ORMSware arcs are not just connectors. They can contain logic/code just as nodes do, and logical networks can be nested under them just as they can be nested under network nodes, to create hierarchical queuing networks.
 |
 |
Execution Threads: ASP Classic implementations of ORMSware programming capability are limited to single logical execution thread as of now. Multi-threaded implementation relies on certain queuing-related functions/routines in modeler's/programmer's/customer's preferred scripting language (readily available, or easily written, in modern programming languages).
Gray-dashed [support role] nodes in ORMSware ASP diagrams are typically used to indicate presentation of a dialog box to a customer. In normal ASP programming, response from customer would then be sent to another ASP file for further processing. In ORMSware ASP programming control can return to any of the arcs leading out of the dialog box node depending on customer response. Recall that instead of a Normal node to contain a dialog box, a Network node can be used instead to handle complex control logic for dialog box presentation/view.
Gray-dashed [support role] arcs in ORMSware ASP diagrams are typically used to indicate a point to which execution control is to be returned (re-entry) when a customer provides a response in a dialog box. Such an arc is usually a successor arc from a gray-dashed node containing a dialog box. Support role arcs are also used to indicate precedence of nodes.
Illustrates benefits of programming with visual hierarchical network diagrams in testing software logic, comparing brute force exhaustive testing to surgical precision testing. Discrete-event-simulation-powered programming dramatically reduces exhaustive testing burden (down to 9 from 128 in this case) while increasing reliability.
Pedal Magic Presales Process ASP
Program for having a potential customer unlock and play a test clip and provide feedback before making order form available. If the customer can indeed view and hear the clip, pathway to order full-length video is opened, customer order is processed, and upon successful financial transaction at credit card processor, customer is routed to the licensing path. A customer cannot get to the order form until and unless the test clip can be seen and heard on their computer. The process was helpful to both customers and us to avoid having to go through the refund process.
This is a later, streamlined version of Pedal Magic sales and licensing/unlocking process, leveraging better technology that became available from our digital rights management provider, and some parts of older Pedal Magic Presales Process ASP above.
Utility for conditionally compiling all routines in a program whose source codes have changed since previous bulk compilation and building of the program.
Automated auditor for analyzing quantitative models that use the "Leviathan" paradigm. Leviathan models have very predictable patterns and structures, which made it easy to develop an automated process to analyze them for auditing/doing due diligence. Certain node descriptions in the subnet for automated unit derivation of calculated results (e.g. instructors per day, dollars per student, students per class, etc.) are intentionally hidden here from public exposure due to proprietary value.
Program performs several functions for helping a large Sunday school class of elderly couples remember each other (class also contains single members). Members and potential members of the group play a memory game that helps them associate names to pictures of faces of others in class, who is married to whom, who is single, etc. Program also allows members to select a subset of the class they want to focus on, optionally form game sets from their focus group set, and if they so wish, keep private prayer notes for any members on whom they especially want to focus their prayers. It also allows as many members of a class as desired to record attendance/retrieve the presence of themselves and others at group events.
Network diagrams included here were used strictly for communication purposes. They were never implemented to create an executable to be tested and put into production. The logic in the diagrams reflect logic in a conventional program [that was] in production for routinely scoring and maintaining required records of educational testing candidates for state certification purposes.