Gnosys has developed a
behaviors are extended not by specialized computer programmers but
military subject matter experts or intelligent computer programs alone. With the appropriate technology, new
behavior building blocks can be created and reused by subject matter
using a Graphical User Interface (GUI) or by intelligent computer
using a sort of semi-automated programming of semi-automated force
systems. New behaviors for new
echelons will be
reused, compositionally, for even newer echelons and newer behaviors,
increasing CGF capability. Inevitably,
CGF technology can grow automatically or with the help of the User to
wider and deeper, incrementally building on its strengths.
The Gnosys Behavior Design Tool is written in Java (see Fig. 1) and uses a “look and feel” made popular by the Windows Explorer program and thus should be familiar to computer users. A large but not so obvious part of its function is to aid the user in navigating amongst predefined behaviors. The Explorer metaphor helps the user manage a large volume of data.
Fig. 1 Initial View of the Behavior Design Tool
Behaviors are organized in taxonomies. This organization helps in its management. Currently, there exist 3 high level categories: ground, air and misc. These are adequate for the purposes of the prototype. However, in an actual implementation, addition categories may be added such as joint operations, peacekeeping operations, etc. Clicking on one of the categories in the left pane will produce the Gnoframes that are part of the category on the right pane as shown in Fig 2. Successive navigation will bring the browser into the desired location in the behavior taxonomy. There, the user can elect to create a new Gnoframe by using the right mouse button, or explore an existing one by using the left mouse button (see Fig. 2).
Fig 2. Ground category of behaviors has only the Occupation Process behavior listed in standard Gnoframe format
A behavior is displayed in the Gnoframe standard structure. It has a name, a preconditions section, a side-effects section, a main procedure and a postconditions section. Each is color coded to indicate status of completion; white/gray means code exists for the section, yellow means code does not exist of the section. In this example (see Fig. 2), the behavior Occupation Process is the sole member of this category. It is a company armor standard task for occupying an assembly area (AA) as transcribed from an algorithm chart provided by Army standard documentation (manual 71-2-0325).
The row of buttons above the Gnoframe provides the complete set functionality needed to develop a Gnoframe. Its appearance at this level lets the user to start developing a behavior without worrying where to place it in the overall taxonomy. Once completed, a behavior can then be positioned in the hierarchy. Each button on the top bar represents a syntax element that can be created and inserted into the behavior. Note the New Gnoframe button. With it, new Gnoframes can be created in a nested fashion here. This menu bar will be discussed below.
Fig. 3: The Main Procedure section is the only one color-coded as complete
Selection of the Occupation Process will show each of the sections in the color-coded scheme (see Fig 3). This approach functions in the spirit of structure editors- it helps the user keep track of all the components that must be completed before the process of defining a behavior is finished. In Fig. 3, only the Main Procedure is color-coded as complete. All sections depicted are mouse sensitive. Clicking on a section will invoke an editor. Note that all sections are completed in the same manner and by using the same editor.
Fig. 4: The Main Procedure of the Occupation Process behavior with the Editing Menu
After selecting the Main Procedure section of the behavior, the editing menu appears on the right pane thus “opening” the entire behavior for editing. On the left pane, all the sections including the Main Procedure are listed under the Occupation Process behavior. This allows the user to navigate amongst the different sections of the frame.
The menu buttons create icons that represent a statement’s BFR syntax and semantics graphically. When selected, menu items create icons on the right pane and positions them in a default location. The user can drag them into place and connect them with other statements using direction arrows so as to signify flow of control. This has been done already for the Main Procedure section in Fig. 4.
Some graphical icons require further input from the user. This is elicited by way of property menus. The assignment statement, for example, brings up a menu so that the user can type in or select from a list of predefined entries, values to modify the statement (Fig.5).
Fig. 5: Property Menu to elicit further information from the user needed to modify the assignment statement.
The user selects a left-hand-side value from a predefined list of valid variables or enters one by typing. Likewise, a set of predefined functions is available for selection for the right-hand-side. Again the user may type the right-hand-side in directly.
A similar scheme is available for the if-then-else statement (Fig 6). To enter a test condition a property menu is popped up. The user can again select a value from a predefined set or type in a test condition. Gnosys will have predefined a set of CGF functions that are relevant for selection at these menus. Only those with the appropriate type will be offered at any time.
Fig. 6: The if-the-else test clause property menu
Once the definition of the behavior is complete, the user can select the Generate Code Button available at the root level screen on the right pane. This will generate code in BFR syntax and save it to a predefined file. This file will be processed automatically from the Backend which will itself generate a C++ file ready to be linked with OneSAF.