The BRIM™ State Transition Engine (STE) Syntax

A process flow consists of the identification and representation of the processing steps associated with a business event. The business events themselves are represented as classes in the UML model.

The process flows associated with business events are described using a State Transition Engine approach similar in structure to a UML activity diagram. These diagrams are not unlike the old data flow diagrams or even older flowcharts. The process flows use different types of flow elements:

A. States: States represent a particular point in the process flow where an action might occur. Modifying a state implies that the process flow is modified.

B. State Events: Each state may have a number of sub-events associated with it that can trigger various activities

C. Transitions: These transitions represent how a business event changes its state

D. Tasks: Tasks represent traditional program logic, which may be associated with various state events or with the transitions themselves.

BRIM™ states are richer than traditional STE states or flowchart boxes. One BRIM™ state may replace up to 50 states in a traditional design environment.

Traditional OO modelers might be tempted to represent business events as methods for other classes. For example, the “Hire Employee” event could be a method on the Employee class. However, experience has shown that the “Hire Employee” event is itself an item of interest to the organization with its own attributes and associations to other classes. Therefore, “Hire Employee” is best represented as its own class rather than a method on the Employee class.

1. States

States can be divided into two groups: manual and automatic. With manual states, the business event stays in the state after the associated process is performed. It is possible for a business event to remain in a manual state for an indefinite period of time (minutes, hours, days, permanently) until some action occurs to move the event to another state. Events may end up in a termination state indefinitely.

With automatic states, business events only reside in those states long enough for the tasks (code) to be executed before moving to the next state. Automatic states are inherently transient.

There are eight (8) specific types of states that are either structurally or semantically different from one another:

Manual States: Begin, End, Inbox, Wizard, Suspend, Error

Automatic States: Automatic, Auto Begin

1.1 Begin

A Begin state is the usual initial state for a business event. Every time a new business event is created, it is always created in an initial state. Each business event has one and only one Begin or Auto Begin state. If an event subsequently reaches a Begin state (by transitioning from another state), it will automatically close.

The Begin state is where the initial data entry for the event occurs. Depending upon a specific condition, or if significant pre-processing is required for an event, an Auto Begin state may be used (See Auto Begin section).

The Begin state is represented in the process flow diagram as shown below:

1.2. End

An End state is a final resting place or termination point for a business event. A flow for a business event may have any number of end states. When a business event reaches the End state, it will never subsequently change states unless directly forced to by an abnormal system event.

Events close when they reach an end state.

The End state is represented in the process flow diagram as shown below:

1.3. Inbox

The Inbox state is the primary manual state. When a business event lands in an Inbox state, it waits for some manual intervention. A business event may have any number of inbox states. When an event reaches an Inbox state, it automatically closes.

Security measures control who is allowed to open a business event in an Inbox state.

The Inbox state is represented in the process flow diagram as shown below:

1.4. Wizard

A Wizard state is similar to an Inbox state insofar as the business event halts and awaits additional user input. This additional input releases the event for further processing. When an event reaches a Wizard state, it remains open.

Wizard states differ from Inbox states in that a Wizard state is encountered in the context of a single processing session. Therefore, there is no security associated with a Wizard state.

Typically, in the user interface, a business event will land in an Inbox state and wait for a user to open it. While the user is processing the business event, it may pass through several Wizard states before ending up in another Inbox or End state.

A business event may have any number of Wizard states associated with it.

The Wizard State is represented in the process flow diagram as shown below:

1.5. Suspend

A Suspend state is used when the business event waits for something other than a user intervention to occur. The event will either expire or a listener event (not implemented in this version) will trigger it. When an event reaches a Suspend state, it will automatically close.

A suspend state is functionally equivalent to an inbox state.

The Suspend State is represented in the process flow diagram as shown below:

1.6. Error State

Error states occur when there is an abnormal problem in the process flow or the users are unable to determine the appropriate action and perform a Bail operation during a processing session. Under normal circumstances, no business event should ever be in an Error state. When an event reaches an Error state, it will automatically close.

Error states should only be used for two situations:

· Abnormal process flow problem

· User is unable to make the program perform as expected and chooses to abort the business event.

An error state is functionally equivalent to an inbox state.

The Error state is represented in the process flow diagram as shown below:

1.7. Automatic

Automatic states are used to perform automated code functions associated with the business event. When a business event lands in an Automatic state, it performs tasks associated with that state and immediately moves to another state.

A business event will never stay in an automatic state longer than is necessary to execute the code associated with that state.

Automatic states are represented in the process flow diagram as shown below:

1.8. Auto Begin

This state is a specially flagged automatic state that will serve as the initial state when a business event of that type is created. Execution of the business event begins immediately upon creation and continues until the event reaches a non-automatic state.

Auto Begin states are represented in the process flow diagram as shown below:

1.9 Adding States

States are added by right clicking on the STE diagram name in the Navigator. The user interface for adding a state to a diagram is shown in Figure 1

Figure 1:STE User Interface – Add a State

2. Events

As mentioned above, each state may have a number of associated events. Depending upon the type of state, different types of events are applicable. Not all types of events are allowed to be associated with all types of states. Each instance of an event is associated with exactly one state.

The Events/decisions with associated figures in this section are the only ones for which there are graphic representations.

The following event types are listed in the order in which they may occur:

2.1. ON_SET

ON_SET events occur immediately when a business event enters a particular state. Tasks may be associated with an ON_SET event. ON_SET events are applicable for all state types.

There is no visual representation of an ON_SET event.

2.2 EXPIRATION

For manual states (any state where the business event may remain for some time), a state event may need to trigger some activity after a specified period of time. For example, a business event may sit in the Inbox state for a period of time. If no one operates on the business event, after a certain length of time, some automatic action such as moving the business event to another state may occur. Such behavior is triggered by an expiration event. An expiration event is equivalent to attaching a timer with a fixed expiration date and time.

When an expiration business event is created, the rules governing when events reaching the associated state expire must be declared. There are two mechanisms for accomplishing this:

1. Specify the amount of time that should elapse before the expiration event fires. This is done using two values: a unit of measure and a number. Allowable units of measure are: seconds, minutes, hours, calendar days and business days. The second field (number) indicates the amount of the given unit. The number need not be an integer value; however, it must be greater than or equal to zero. (Note that a value of zero indicates that the timer event will fire as soon as the timer process searches for and processes activated timers (not necessarily immediately).

2. Specify the name of a date attribute on the business event with the assumption that the business event will calculate when the timer would fire as part of its flow. In this case, the designer must specify the name of the attribute in the business event. When the timer reaches the state with an EXPIRATION business event, ON_SET tasks will fire first. Next, the value of the field indicated will be examined and set as the date/time when the business event will expire. Calculations for the expiration date of the expiration event can be performed in the ONSET tasks for that state.

NOTE: Setting the expiration date to a particular point in time does not guarantee that the business event will fire at exactly that time. There is a background process that periodically looks for business events that have expired timers in order to execute the appropriate expiration tasks and move events to their new states.

Depending upon the frequency of this process, the time lag within which the business events will be executed after expiration will be indicated. For example, if the system architect directs the system to only search for expired tasks nightly, business events that have expired timers will not be executed until the evening.

Expiration events are indicated as shown in Figure 2.

Figure 2:Graphical representation of Expiration Events

2.3. BEFORE_OPEN

For all manual states, the designer may allow the user to open the business event for viewing or processing. BEFORE_OPEN events occur as the event is being opened and might include logging who is opening the event. There can be tasks associated with BEFORE_OPEN events.

There is no visual representation of a BEFORE_OPEN event.

2.4. MANUAL_PROCESSING

A manual processing event is only associated with manual sates. These events are used to declare the edit privileges for the attributes associated with a particular business event. When a user opens a business event, this determines which variables can be viewed or edited.

There is no visual representation of a MANUAL_PROCESSING event.

2.5. AUTO_BAIL

This event is not implemented in the current version.

This event is triggered by a catastrophic program error not explicitly handled in the called procedures. Auto-bail events may be attached to any type of state.

There is no visual representation of an AUTO_BAIL event.

2.6. BAIL

Bail events may only be attached to manual states. This corresponds to some user interface (perhaps a Cancel button) element, which triggers the Bail event.

Bail events occur when the user has been inadequately trained or a program bug does not allow the user to select the desired alternative and the business event must be terminated.

Bail events are attached to the upper right hand corner of states.

A graphical representation of the Bail state is shown in Figure 3.

Figure 3:Graphical representation of Bail state

2.7. Manual Decision

When a user has finished working with a business event in a particular state (Ex. by clicking on a “Done” or “Process” button) and is presented with a series of alternatives to select from, this is a manual decision event. If no list of alternatives is to be presented, the Automatic Decision event should be used (see below).

If there is no manual processing event, the Manual Decision is triggered immediately after the BEFORE OPEN state event.

A graphical representation of a Manual Decision event is shown in Figure 4.

Figure 4:Graphical representation of Manual Decision state

2.8. Automatic Decision

Automatic decision events may be associated with any state type. This type of event is triggered differently when associated with automatic or manual states.

For automatic states, as soon as the ON_SET event activity associated with the state is completed, the Automatic Decision event is triggered.

For manual states, the Automatic Decision event is triggered by a user interface action such as pressing a button (“Done,” “Next,” “Process”). If there is no manual processing state event, the Auto Decision is triggered automatically, immediately after the BEFORE_OPEN event.

When the automatic decision event is triggered, one of several alternatives is automatically selected and the business event passes to a new state.

A graphical representation of the Automatic Decision state is shown in Figure 5.

Figure 5:Graphical representation of Automatic Decision state

2.9. Listener Events

Listener events are not currently implemented.

2.10 Events Allowed for Specific States

Table 1 below shows which types of business events are allowed for which types of states.

EVENTS STATES	ONSET	EXPIRA-TION	BEFORE_ OPEN	MANUAL PROCESS-ING	AUTO BAIL	BAIL	MANUAL DECISION	AUTO DECISION
BEGIN	X	X	X	X	X	X	X	X
END	X	X	X	X	X	X
INBOX	X	X	X	X	X	X	X	X
WIZARD	X	X		X	X	X	X	X
SUSPEND	X	X	X	X	X	X	X	X
ERROR