Innovation is often a matter of combining several well-known ideas into a synergistic configuration. All of the features that we mention below have probably been manifested in other frameworks. We list them as break-through features, not because they are original, but because they each have an important synergistic effect.
The essential break-through of the Hum framework is the fact that the system allows the programmer to focus their attention on capturing business process knowledge. In older 3GL and 4GL frameworks, the programmer is distracted by the mechanics of data processing. In the Hum framework, we eliminate as many distractions as possible.
Here is a list of the features we believe to be most effective in allowing the programmer to capture business process knowledge quickly and in a ready-to-use form.
Of course, the most visible feature of Hum is that the syntax of the programming language is very close to the natural syntax of written English. The main effect of this feature is that modules are human-readable. The statements of the language are easy to type because they contain very few special characters. In fact, the statements can even be entered via verbal dictation. English-speaking programmers should be able to learn the language quite quickly.
We call the programming language "Hum"; and it is a dialect of written English. While it has many of the features of natural language, it is still an artificial language. The syntax conventions are only slightly different from those found in written English. But the rigid syntax and algebraic forms associated with computer programming languages are absent.
There are only a few statement types and a small number of key words and punctuation tricks.
Sentences: Sentences end with a period. This is the same convention as written English. If a statement is continued from line to line, the interpreter finds the end of the statement by looking for the terminating period. Another convention is that each sentence starts on a separate line. This convention is optional in many programming languages. In Hum, it is manditory.
Comments: One punctuation trick is that comments are enclosed in parends. (The convention of enclosing comments in parends is borrowed from written English.) In general, comments are treated as white-space by the interpreters.
Indentation: The structure of Hum programs is indicated by indenting statements. This is conceptually similar to the Python programming language. The indentation indicates where statement-blocks (blocks of statements) begin and end. A major difference is that indentation is created by typing periods at the left margin. A recommended practice is to create indentation by typing period, space, period, space. However, what matters to the interpreter is the number of periods preceeding the line. This is probably the most visible feature of Hum programs.
Statements in Hum are collected into "frames". The frames provide a way of "chunking" the process descriptions. People working away from a computer may write the frames on index cards.
Task frames and role frames create high-level, readable descriptions. They are relatively natural modules for thinking out loud about processes.
Dialog frames and view frames use a simple mark-up notation to express ideas about document format. This wiki-like mark-up notation is the most esoteric of Hum notations. Yet it is a far simpler notation than HTML, RTF, and XSLT. We designed it to stay as close to written English conventions and "what you see is close to what you get" as we could.
Data frames use a simple "name-value" notation to store data. The structure of a data frame is hierarchic like XML but without the verbosity and esoteric notation. To be fair, XML is meant to serve many purposes, while a data frame has only one purpose.
In Hum, the "ontology" of a world is defined as a collection of frames. The relative meaning of a word is defined in Dictionary frames. Dictionary frames provide a way of advising how a word is related to other words. The usage of a word is shown in the other frames where the word is used in statements. Task frames define the states and state-transitions in a system. Role frames define the capablities of various roles. Instructions define the interfaces between the system and the actors assigned to roles.
Most software applications are business applications. The Hum framework understands the fundamental semantics of business processes. It contains built-in, well-integrated features for managing resources of every type. The framework does most of the accounting needed in a business application automatically and additional special accounting is easily added.
The essence of business is staging and allocating a set of resources and adding value beyond the original cost of the resources. Hum is a business system and provides built-in mechanism for tracking, allocating, and accounting for resources.
The steps in a business process are performed by actors assigned to roles. These actors are resources and may be involved in the utilization and/or consumption of other resources. The system automatically keeps cost accounts and inventory accounts as the steps are performed.
The system includes a integrated accounting system. Additional accounting, beyond the cost and inventory accounting provided by the system, may be added by adding task steps directed to the Book-Keeper role.
It is worth noting that this book-keeping function is also usable in some multi-person games. Cost-accounting can keep track of health and damage accounts. Inventory accounting can keep track of the objects and qualities carried by a player.
The framework does not attempt to warp real-life arithmetic into the limited system used by computers. The framework tracks the actual precision of its arithmetic and does not produce spurious precision. It understands the nature of the numbers given it because it knows which are measures, which are counts, and which are probabilities.
To help you understand the problem with computer arithmetic, allow me to pose a simple question: "What is .111 times .20 and what is 111. times .20 ? You know that .022 and 22. are the correct answers because the precision of the inputs constrains the precision of the outputs. But a computer might tell you the answers are .02219999999999999 and 22.1999999999999 respectively - which is the decimal equivalent of the results it is holding internally in its binary equivalent of scientific floating-point format.
If you try to fix the problem by setting the decimal display format to display two decimal places, you would get .02 and 22.20 - These answers may look better but they are still not correct. The .02 is not correct because it truncates part of the data. The 22.20 is not correct because it provides spurious precision.
The framework uses a variation on fixed-point arithmetic and tracks the precisions of the inputs to assure that the precision of the output is not over-stated.
Because persistance is managed by the system, programmers can focus their attention on capturing business process knowledge. The system automatically assures that needed data is remembered, that process metrics are collected, that events are logged, that accounts are kept.
Sometimes business people do not want records to be maintained indefinitely.
"Records Retention Rules" define when records should be deleted.
Q: Where and how might we enter records retention rules?
. To make that work we need to define a "type" of record.
. An event message signature is sufficient to define a type of record. Also, an event has a specific date and so date-based rules make sense.
. Entity data could be deleted when some rule determines that the data is probably no longer relevant. For example, customer data might be irrelevant if the customer has not purchased anything for some duration of time.
Actually running a process is a necessary part of discovering what is wrong with it. However, for initial validations of the knowledge capture or process design, it is sufficient to run the process in a simulated world. The test team will very quickly discover many of the missing bits.
Eventually, the business process will have to be run in a lab or pilot setting to assure that the instructions given to real-world actors are complete and correct. To faciliate this kind of testing, the testers may configure the system so that some actors are simulated while others are real-world actors.
This virtual world capability is very similar to the virtual world seen in a multi-person game. If you think about it, business is a kind of multi-person game. The difference might be that the visual world of a game is a fantasy while the visual world of a business is more or less real. Most of the computing cycles in games goes into creating a visualization of the fantasy world.
This section has gotten a little mixed-up and needs to be re-written. But it will serve for now.
Each business process will involve a number of actors. When the actors are robots or sim-bots, the communication channel is relatively simple (in computer terms). When the actors are humans, a human-interface bot (Speaker) acts as an intermediary. In either case, the interface is not part of the business process. It is handled separately and the details of the interface will not clutter the description of the business process.
When a plan-tree is built from task-frames, there will be a number of run-time parameters in the plan. (The parameters [variables] are identified by nouns which have yet to be assigned to specific instances) Some of these parameters can be provided by the environment from data already known to the system, others will need to be provided by the client. In a web environment, the user may be asked to "fill in the blanks" on an HTML form. In a voice-response environment, an interactive question and answer session may provide the specifics needed.
While Hum has the ability to simulate the operation of a business process in a kind of virtual world, the more important ability is to facilitate the operation of a real-world business process. The most important actors in a business process are the workers and the clients. In the virtual world, these actors are simulated by sim-bots and the interface between the Supervisor and the sim-bots is relatively simple (for a computer).
Human Interfaces: In the real world, many of the workers and clients of the business process are human beings. The business process needs to gather information from clients and workers. It also needs to give instructions to the workers (and sometimes, to the clients). These human-interface channels are handled by a human interface bot. (The human-interface bot is an actor assigned the Speaker role)
The capabilities of the bot will be task specific. In some implemenations, it may present a fill-in-the-blacks form to the human as a way of gathering data. In other implementations, it may use text-to-voice or voice-to-text technology to communicate with humans who are wearing head-sets. When the interface system presents a virtual world, the bot might present as an avatar with a synthetic personality.