You do not really program the Hum system. Instead you tell the system what it needs to know to write its own programs. Accordingly, authoring an application mainly involves identifying the goals of the application and then providing the knowledge required by the system to achieve each goal.
In general, the system determines what is missing by examining what you have told it so far and identifying things you have mentioned but not yet explained. Thus, the system might not know that a goal is missing, but, it will know when the plan for a known goal is incomplete.
The Hum framework is designed, from the ground up, to implement and simulate business processes. The framework can be used for other purposes, but it is easiest to understand when viewed in the context of a business process.
The fundamental business process is fulfilling an order. An order is the triggering event. Fulfilling the order is the goal of the business system. Everything else flows from the order. Resources are marshaled, allocated, assigned, used, and accounted. The customer is billed for the service performed or product delivered, funds are collected. The metrics of the enterprise are continuously monitored.
To illustrate how the system works, consider the following scenario: Our enterprise is operating a donut shop. Customers buy donuts and coffee. We offer a variety of donuts and coffees. We will describe our business processes from the top down. Along the way, we will note the different entities involved - the roles, the resources, the products. This scenario is partially described in the top-level task frame shown in Figure 1.
Figure 1: The top-level task frame - identifies the primary goal.--- Task: Serve the customer. Post: Customer is served. Pre: . Customer has entered an order. . Customer has paid for order. Actions: . Coffee-Mixer: Prepare the coffee items in the order. . Donut-Fetcher: Fetch the donut items in the order. . Order-assembler: Assemble order items into packages. . Order-checker: Give packages to the customer. --- Dictionary: . A donut is a product. . A donut item is an order item. . A carrier is a delivery package. --- |
This is not the time to worry about the realism or efficiency of this business process or the related business policies. This example is for illustration. In fact, it contains some deliberate errors. Later, we will show how processes get refined and how policies are changed.
Read the following paragraph carefully.
It contains a dense description of the main concepts of Hum.
The top-level task frame defines the goal of the plan in its post-condition. The post-condition is labeled "Post" in the frame. However, before the work of serving the customer can begin, we need to know what the customer wants. Therefore, a precondition is that the customer has entered an order. It is also our policy to collect payment in advance. So, that is one of the preconditions also. Once the preconditions (labeled "Pre" in the task frame) are satisfied, we perform a sequence of actions with the end result being that the post-condition, the goal, is achieved. Each action is a procedure performed by a specific role. The actions performed by a role are detailed in a role frame.
Now that the primary goal and its prerequisites and transitional actions are identified, we can define the prerequisite sub-processes indicated by the preconditions. We will write more task frames to show how the preconditions are satisfied. We will also write role frames (sets of procedures) to define the actions performed by various roles.
Assume for now that we always have actors on hand that can understand the instructions in the role frame. When the system is running, the roles are assigned to humans, robots, or simulated actors (sim-bots).
Here is an action procedure:
Figure 2: Role Frame - Provide detailed instructions for actors assigned to a role.Role: Coffee-Mixer. (Coffee-Mixer is the name of a role.) Action: Prepare the coffee-items in the order. . Get a coffee-tray from the coffee-tray-stacker. . For each coffee-item in order: . . Prepare the coffee-item. . . Add coffee-item to coffee-tray. . . Bookkeeper: Add coffee-item value to coffee-tray inventory. . Move coffee-tray to outgoing-coffee-queue. To: Prepare the coffee-item. . Fetch recipe's cup from cup-dispenser. . Execute coffee-item's assembly-process. . (The assembly-process is the coffee-item recipe.) . (The assembly-process will account for materials and equipment costs.) To: Get container from stacker. . Move to stacker's location. . Remove container from stacker. |
Here are some of the points of interest in the action procedure shown in Figure 2:
Figure 3: Dictionary Frame - add new words to the vocabulary.--- Dictionary: Donut-Shop Equipment. . A coffee-tray is a container. . A coffee-tray-stacker is a stacker. --- |
Since the procedures are written in Hum, they can be understood equally well by humans, robots, and sim-bots. When we run the actual business, the procedures are executed by humans and/or robots. When we simulate the operation of the business, the procedure actions are performed by sim-bots. The same system can be used to operate the business in the real world or in a virtual world. In fact, we may want to test our business processes in the virtual world before running them in the real-world.
If you are a programmer, you may be wondering how the variables are indicated in the procedures. In a natural language sentence, the nouns denote variables. Nouns are almost always abstract concepts whose meaning depends on context. Only proper nouns denote a specific instance of an object.
Variables in a programming language are essentially blanks (slots) to be filled-in at run-time. Using the language of math, we would say that the system substitutes specific values for the variables in the formulae.
When humans are given procedures, they map the nouns to specific objects in their environment based on context and experience. But sim-bots are just bots and they need a little help with the mapping. There are two things involved here: mapping and context.
Mapping:
Nouns refer to entities and the attributes of entities.
Dictionary entries map nouns to built-in concepts.
In Hum, the dictionary entries identify which nouns are entities
and which are attributes.
In addition to data-level concepts like entity and attribute,
the framework contains higher level concepts including:
- role
- resource
- resource pool
- location
- measure
Context: At run time, the nouns in the statements are mapped to specific objects. A plan is assembled to satisfy a specific goal. All of the nouns in that plan are then interpreted in the context of that goal and the world in which the plan is operating. Some objects are defined in the goal. For example, a specific order (product) and customer (client, person) might be referenced in the post-condition of the top-most task frame. Other nouns may refer to the environment. For example, they may refer to specific resources including equipment, materials, workspaces, and actors.
When a Hum system wakes up, its memory of the world is read from a kind of database that we call a world-base. The memory of the world changes as the instructions in the frames are executed by various actors. The world-base maintains records of what-is and what-happened.
Consider the instruction:
. Add flavors shown in item recipe.
The nouns are "flavors", "item", and "recipe".
The system already knows that "item" refers to an "order item"
and that an order item will refer to a product
and that a product may have a bill-of-material
and an assembly-process.
We need to explain "flavors" and "recipe".
The relevant dictionary entries are:
--- Dictionary: . A flavor is a material. . Recipe is a synonyn for assembly-process. ---
These dictionary entries map the nouns to lower-level concepts that are "understood" by the system. In this case, the item is in the order that is referenced in the original goal. The item, in turn, implicitly references a recipe. The recipe is an assembly-process defined by a task frame in the ontology. The sim-bots will read the bill-of-materials and draw "flavor" material from appropriate resource pools.
--- Dictionary: Bill-of-Materials concepts. . Product is described by name, bill-of-materials, assembly-process. . . (The "assembly-process" names a task-frame in the ontology.) . A bill-of-materials contains a list of component-quantities. . A component-quantity is described by a component and a quantity. . A part is a component. . A material is a component. ---
A version "0.1" elaboration of the Donut Shop's business process is in the "DonutShopV01" listing. This is a good time to examine the listing. The elaboration is fairly detailed, but there are still some inconsistencies and some missing bits. That will help us show how the system catches errors.
In Running the Business, we will explain how the system operates (or simulates) a business.