Operational State Transition Description (OV-6b)

Product Definition. The OV-6b is a graphical method of describing how an operational node or activity responds to various events by changing its state. The diagram represents the sets of events to which the architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action.

Product Purpose. The explicit sequencing of activities in response to external and internal events is not fully expressed in OV-5. An OV-6b can be used to describe the explicit sequencing of the operational activities. Alternatively, OV-6b can be used to reflect the explicit sequencing of actions internal to a single operational activity or the sequencing of operational activities with respect to a specific operational node.

Product Detailed Description. OV-6b is based on the statechart diagram. A state machine is defined as “a specification that describes all possible behaviors of some dynamic model element. Behavior is modeled as a traversal of a graph of state nodes interconnected by one or more joined transition arcs that are triggered by the dispatching of a series of event instances. During this traversal, the state machine executes a series of actions associated with various elements of the state machine.” [OMG, 2003]

The product relates states, events, and actions. A state and its associated action(s) specify the response of an operational activity to events. When an event occurs, the next state may vary depending on the current state (and its associated action), the event, and the rule set or guard conditions. A change of state is called a transition. Each transition specifies the response based on a specific event and the current state. Actions may be associated with a given state or with the transition between states.

Statechart diagrams can be unambiguously converted to structured textual rules that specify timing aspects of operational events and the responses to these events, with no loss of meaning. However, the graphical form of the state diagrams can often allow quick analysis of the completeness of the rule set, and the detection of dead ends or missing conditions. These errors, if not detected early during the operational analysis phase, can often lead to serious behavioral errors in fielded systems or to expensive correction efforts.

Figure 4-21 provides a template for a simple OV-6b. The black dot and incoming arrow point to initial states (usually one per diagram), while terminal states are identified by an outgoing arrow pointing to a black dot with a circle around it. States are indicated by rounded corner box icons and labeled by name or number and, optionally, any actions associated with that state. Transitions between states are indicated by one-way arrows labeled with an event/action

notation that indicates an event-action pair, and which semantically translates to: when an event occurs, the corresponding action is executed. This notation identifies the event that causes the transition and the ensuing action (if any) associated with the transition.

State 2

State 1 Event / Guard Condition / Action State 2

State 1 Event / Guard Condition / Action State 2

State 1 Event / Guard Condition / Action

Figure 4-21: OV-6b – High-Level Template

Another dynamic behavior modeling technique is Colored PetriNet (CPN) [Kristensen, 1998]. A CPN can be used as an executable operational architectural model or a business workflow model. CPN executable models provide a description of the activity event sequencing (concurrent or consecutive) and can be used to dynamically simulate an OV-5. With a CPN simulation engine or a discrete event workflow simulation engine, parallel event processing and decision support can be achieved.

The most important reason for using both modeling and simulation tools is to show complex, dynamic organizational interactions that cannot be identified or properly understood using static models. Simulation provides insight into how processes in an enterprise add to the overall cost of a mission thread or scenario and can make it possible to animate, analyze, and validate these complex relationships. This information can then be used to create new alternatives or it can be used to compare multiple alternatives until an optimal solution is found. Most importantly, simulation takes information that traditionally was collected in static reports, and makes this information dynamic.

Dynamic analysis is able to assess time-dependent process behavior and shared time- dependent resources, discover ways to efficiently allocate human and system resources to perform those processes, check overall performance, identify bottlenecks and human resource overloads caused by insufficient resources or faulty information flows, and discover and eliminate duplication of effort. Measures of Effectiveness (MOE) relative to mission objectives being evaluated and Measures of Operational Outcomes (MOO) relative to how operational requirements contribute to end results can be determined.

In addition to examining behavior over time, one can also assess an overall dynamic mission cost over time in terms of human and system/network resource dollar costs and their processes dollar costs. Analysis of dollar costs in executable architectures is a first step in an architecture- based investment strategy, where we eventually need to align architectures to funding decisions to ensure that investment decisions are directly linked to mission objectives and their outcomes. Figure 4-22 illustrates the anatomy of one such dynamic model.

Organization Chart Organization Chart

Resources

Resources ContainersContainersInfoInfo Activities

Activities

Information

Information Applications, Applications,

Databases, Databases, Servers, Servers, Networks Networks Process Model Process Model Job Titles

Job Titles Business EntitiesBusiness Entities

Human Roles, Jobs:

Human Roles, Jobs:

-

-Wing Cdr, S3, XO,Wing Cdr, S3, XO,

VP, clerk

VP, clerk

Organizational Structure

Organizational Structure

-

-BN, Wing, Fleet,BN, Wing, Fleet,

Finance Dept Finance Dept Systems, W/S, Systems, W/S, Satellites, Satellites, Equipment, Equipment, Techniques, Tools, Techniques, Tools, ATM, Networks ATM, Networks Inputs/Outputs Inputs/Outputs Triggers Triggers Inputs/Outputs Inputs/Outputs

Call for Fire, Produce ATO

Call for Fire, Produce ATO

Conduct Mission Planning,

Conduct Mission Planning,

Process Loan Application

Process Loan Application Actual Organization Unit - 1-8 Armor BN, Widget Fin Dept

Organization Chart Organization Chart

Resources

Resources ContainersContainersInfoInfo Activities

Activities

Information

Information Applications, Applications,

Databases, Databases, Servers, Servers, Networks Networks Process Model Process Model Job Titles

Job Titles Business EntitiesBusiness Entities

Human Roles, Jobs:

Human Roles, Jobs:

-

-Wing Cdr, S3, XO,Wing Cdr, S3, XO,

VP, clerk

VP, clerk

Organizational Structure

Organizational Structure

-

-BN, Wing, Fleet,BN, Wing, Fleet,

Finance Dept Finance Dept Systems, W/S, Systems, W/S, Satellites, Satellites, Equipment, Equipment, Techniques, Tools, Techniques, Tools, ATM, Networks ATM, Networks Inputs/Outputs Inputs/Outputs Triggers Triggers Inputs/Outputs Inputs/Outputs

Call for Fire, Produce ATO

Call for Fire, Produce ATO

Conduct Mission Planning,

Conduct Mission Planning,

Process Loan Application

Process Loan Application Actual Organization Unit - 1-8 Armor BN, Widget Fin Dept

Figure 4-22: Anatomy of an Executable Operational Architecture

State transitions in executable operational architectural models provide for descriptions of conditions that control the behavior of process events in responding to inputs and in producing outputs. A state specifies the response of a process to events. The response may vary depending on the current state and the rule set or conditions. Distribution settings determine process time executions. Examples of distribution strategies include: constant values, event list, constant interval spacing, normal distribution, exponential distribution, and so forth. Priority determines the processing strategy if two inputs reach a process at the same time. Higher priority inputs are usually processed before lower priority inputs.

Processes receiving multiple inputs need to define how to respond. Examples of responses include: process each input in the order of arrival independent of each other, process only when all inputs are available, or process as soon as any input is detected. Processes producing multiple outputs can include probabilities (totaling 100 percent), under which each output would be produced.

Histograms are examples of generated timing descriptions. They are graphic representations of processes, human and system resources, and their used capacity over time during a simulation run. These histograms are used to perform dynamic impact analysis of the behavior of the executable architecture. Figure 4-23 is an example showing the results of a simulation run of human resource capacity.

Figure 4-23: Sample Histograms Showing Results of a Simulation Run

4.6.8 UML Representation

OV-6b may be produced in UML using statechart diagrams that contain simple states and composite states. They also contain transitions, which are described in terms of triggers or events (generated as a result of an action) and guard conditions associated with the events, and an action or sequence of actions that are executed as a result of the event taking place. Statechart diagrams specify the reaction of an object to stimuli as a function of its internal state. Guard conditions of a statechart diagram map to the pre-conditions of an OV-5 use case. Activities in an activity diagram (OV-5) should correlate to states of the relevant object classes (operational nodes) and match to the statechart diagram states for the same object classes, where a state is defined in UML 1.4 as “A condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.” Transitions on the activity diagrams should correlate to the transitions on the state diagrams. In essence, an activity diagram for multiple operational nodes (or objects using swimlanes) should be mappable to a set of statechart diagrams for those operational nodes, and to a set of sequence diagrams (where each sequence diagram correlates to a specific use case scenario). Events or triggers associated with the transitions on the state diagrams correlate to the triggering events documented in OV-3 and are the same events shown on the sequence diagrams of OV-6c.