Operational Rules Model (OV-6a)

Product Definition. The OV-6a specifies operational or business rules that are constraints on an enterprise, a mission, operation, business, or an architecture. While other OV products (e.g., OV-1, OV-2, and OV-5) describe the structure of a business—what the business can do—for the most part, they do not describe what the business must do, or what it cannot do.

At the mission level, OV-6a may consist of doctrine, guidance, rules of engagement, and so forth. At the operation level, rules may include such things as a military Operational Plan (OPLAN). At lower levels, OV-6a describes the rules under which the architecture or its nodes behave under specified conditions. Such rules can be expressed in a textual form, for example, “If (these conditions) exist, and (this event) occurs, then (perform these actions).”

Product Purpose. At a top level, rules should at least embody the concepts of operations defined in OV-1, and should provide guidelines for the development and definition of more detailed rules and behavioral definitions that will occur later in the architecture definition process.

Product Detailed Description. Rules are statements that define or constrain some aspect of the mission, or the architecture. It is intended to assert operational structure or to control or influence the mission thread. As the product name implies, the rules captured in OV-6a are operational (i.e., mission-oriented), not systems-oriented. These rules can include such guidance as the conditions under which operational control passes from one entity to another, or the conditions under which a human role is authorized to proceed with a specific activity.

OV-6a can be associated with the appropriate activities in OV-5. For example, a rule might prescribe the specific set of inputs required to produce a given output. OV-6a can also be used to extend the capture of business requirements by constraining the structure and validity of OV-7 elements.

Detailed rules can become quite complex, and the structuring of the rules themselves can often be challenging. OV-6a extends the representation of business requirements and concept of operations by capturing, in the form of operational rules expressed in a formal language, both action assertions and derivations. Examples of formal languages include structured English, LDL [Naqvi, 1989], and the Object Constraint Language (OCL) [Warmer, 1999]. Action assertions are constraints on the results that actions produce, such as if-then and integrity constraints. Derivations are algorithmically derived facts based on other terms, facts, derivations, and/or action assertions.

Operational rules can be grouped into the following categories:

• Structural Assertions: These rules concern mission or business domain terms and facts that are usually captured by the entities and relationships of Entity- Relationship models. They reflect static aspects of business rules that may also be captured in the OV-7.

− Terms: Entities

• Action Assertions: These rules concern some dynamic aspects of the business and specify constraints on the results that actions produce. There are three types of action assertions:

− Condition: This is a guard or if portion of an if-then statement. If the condition is true, it may signal the need to enforce or test additional action assertions.

− Integrity Constraint: These must always be true (e.g., a declarative statement).

− Authorization: This restricts certain actions to certain human roles or users.

• Derivations: These rules concern algorithms used to compute a derivable fact from other terms, facts, derivations, or action assertions.

OV-6a can concentrate on the more dynamic Action Assertions and Derivations rules, because the Structural Assertion rules are usually captured in OV-7. Operational rules are:

• Independent of the modeling paradigm used

• Declarative (non-procedural)

• Atomic (indivisible yet inclusive)

• Expressed in a formal language such as:

− Decision trees and tables

− Structured English

− Mathematical logic

• Distinct, independent constructs

• Mission/business-oriented

Each architecture may select the formal language in which to record its OV-6a. The formal language selected should be referenced and well documented.

Figure 4-19 illustrates an example Action Assertion that might be part of OV-6a. The example is given in a form of structured English.

A base fact could be:

“Battle Damage Assessment consists of three activities: Conduct Battle Damage, Conduct Munitions Effects Assessment, and Recommend Restrike”

Derived facts could be:

“Recommend Restrike activity cannot be completed before a Battle Damage Assessment Report has been completed.”

“Recommend Restrike activity cannot be completed before a Munitions Effects Assessment Report has been completed.”

A derivation used to derive this derived fact above would be:

A Restrike Recommendation is based on facts contained in Battle Damage Assessment Reports, and Munitions Effects Assessment Reports

4.6.4 UML Representation

There is no equivalent diagram in UML. OV-6a is a text-oriented product. It comprises business rules that apply to operational activities and entities of the Logical Model written in structured English. OV-6a extends the capture of business requirements and concept of operations for the use cases and activities of OV-5. If one considers Operational Rules to be equivalent to complex, nested If-Then-Else and CASE statements, then these statements can be unambiguously derived from UML statechart diagrams. Guard conditions can be specified for state transitions. Consequently, OV-6a may be generated via the use of adornments, and the inclusion of pre- and post-conditions on the use cases of OV-5 (or guard conditions in statechart diagrams). Operational Rules should trace to the constraint relationships identified in OV-5 and to the statechart diagrams for the relevant object classes, if they have been defined. There is no UML diagram to be produced, but the AV-2 will contain these rules and constraints, if they are incorporated into the model as pre- and post-conditions or other adornments in the UML diagrams, where applicable.