Operational Activity (A0)
Flow 1 Flow 2 Flow 3 Flow 4A1
Activity 1A2
Activity 2A3
Activity 3Level 1 Flow Diagram For
Operational Activity (A0)
Flow 1 Flow 2 Flow 3 Flow 4
A1
Activity 1A2
Activity 2A3
Activity 3 A1 Activity 1 A2 Activity 2 A3 Activity 3 A1.2 Activity 5 A3.1 Activity 6 A3.2 Activity 7 A1.1 Activity 4 A3.2.1 Activity 8 A3.2.2 Activity 9 A0High-Level Operational Activity
Activity
Hierarchy
A1 Activity 1 A2 Activity 2 A3 Activity 3 A1.2 Activity 5 A3.1 Activity 6 A3.2 Activity 7 A1.1 Activity 4 A3.2.1 Activity 8 A3.2.2 Activity 9 A0High-Level Operational Activity
Activity
Hierarchy
Figure 4-14: Operational Activity Hierarchy Chart and Operational Activity Diagram (OV-5) – Templates
Figure 4-15 is a process-oriented OV-5 template showing how some additional architecture data could be added as annotations to the original template. For example, activities may be annotated with information concerning the operational nodes that conduct them, the materiel that supports them, the cost of conducting the activity, and so forth. (The types of additional architecture data are notional.)
$
Node A
Node B
Node A
Node B
Node A
Node C
Node A
Node C
Node D
Node D
$
$
A3
Activity 3A1
Activity 1 Flow 1A2
Activity 2 Flow 2 Flow 3 Flow 4Figure 4-15: OV-5 – Template with Notional Annotations
4.5.2 UML Representation
The UML version of an OV-5 is much different from the IDEF implementation (Figure 4-16). The UML OV-5 presents multiple abstractions, each with more detail. The use case diagram represents OV-5 from a scope perspective. The use case diagram provides a visual means to establish the scope (observable result of value) with the stakeholder and the relevant net-centric interfaces that collaborate with the process. These actor interfaces are potentially operator interfaces or system interfaces – sometimes an actor can represent both depending on the level of abstraction modeled. The activity diagram provides the business rules and flow of control for each instance of the use case. A use case instance is a specific "end-to-end" concrete path through a use case, specific values, and responses; only a single path through one or more possible flows of the use case are given. This concept is important to understand when developing OV-6c, because diagramming instance establishment is important to communicate a specific thread through a use case. Finally, the activities on the activity diagram each have their perspective sequence diagram.
Determine Mission Processing Needs
Present Alerts and Notifications [ alert not required ]
[ message not required ] [ alert required ]
[ message distribution required ] : ObjectUpdate <<trigger>> stored : ObjectUpdate : CombatPower : Alert : DisseminationRule : AlertEstablishment : TrackedTypeList Informati on Source Informati on Recipient
Process Mission Updates
CombatPower : Information Source : Information Source : DDS : DDS
1: update object item (ObjectUpdate) 2: update object item (ObjectUpdate)
4: determine dissemination needs (ObjectUpdate) 3: determine alerts (ObjectUpdate)
: Information Recipient : Information Recipient : DDS : DDS
1: present alerts and notifi actions (A lert, CombatPower)
Activity Diagram
Activity Diagram
Use Case Diagram
Use Case Diagram
Sequence Diagram
Sequence Diagram
Sequence Diagram
Sequence Diagram
Determine Mission Processing Needs
Present Alerts and Notifications
Figure 4-16: UML Example OV-5
When modeling UML business use cases (operational view) the architect should render the system as a black box with the overall system name. When this is the modeling approach, the architect should not use swimlanes on activity diagrams. This is an important concept to understand, because the activity is a shared collaboration between the interfaces and the system. Alternately, the DoDAF architect may wish to develop activity models using swimlanes to understand and vet through stakeholders the business process to determine automation opportunities. These “business” activity diagrams are useful in identifying use cases to model system behavior (net-centric service responsibility). Activity diagrams using systems as swimlanes may be useful for system design and implementation. The sequence diagram is the most important view from a net-centric viewpoint, because these diagrams establish service responsibility. Service responsibilities (UML messages on sequence diagrams) identify external and internal interface dependencies of the evolving system. The DoDAF architect places emphasis on the sequence diagram as they provide visibility into patterns of behavior depicted as activities on the activity diagram.
4.5.3 Net-Centric Guidance for OV-5
Augmented Product Purpose. In the NCE, the OV-5 describes operations, identifies activities, and may capture the inputs and outputs between nodes that enable programs to operate in a net-centric manner.
Net-Centric Product Description. The OV-5 traditionally describes capabilities, operational activities (or tasks), and information flows between internal and external activities. Accordingly, in the NCE, the OV-5 should capture the capabilities, activities, and information flows for
posting information and data as soon as possible to encourage discovery and multiple uses as described in the net-centric OV-2. The net-centric OV-5 may highlight multiple inputs and outputs from a particular activity to depict the posting of information in various states of processing (raw, pre-processed, fused, etc). The various states of processing should be readily identified by analyzing key events within the involved processes that change the state of critical information objects.
A central tenet of the NCE is that information and capabilities are obtained from, and contributed to, the netted environment. In operational terms, it is important to identify external sources that may provide information or capabilities within the architecture, so that its mission is more effectively executed. It is also equally as important to make capabilities available to external sources so that they, in turn, may more effectively complete their missions. Accordingly, the net-centric OV-5 places special significance on the I/O flows between activities internal to the architecture and those activities external to the architecture. It highlights both internal activities where information is made available to external activities, and internal activities which result in information being consumed from external activities.
The net-centric OV-5 may be used in the following ways:
• Delineate lines of dependency on external activities when coupled with OV-2.
• Highlight information flows to depict the status of the information's refinement (raw, pre-processed, fused, etc.).
• Provide the critical foundation for depicting Task, Post, Process, and Use (TPPU) activity sequencing and timing in the OV-6a, OV-6b, and OV-6c.
• Identify critical mission threads and operational information exchanges by annotating which activities are critical, i.e., identify the activities in the model that are critical.
The decomposition levels and the amount of detail shown on the OV-5 should be aligned with the operational nodes that are responsible for conducting the operational activities (shown on corresponding OV-2 products). It is important to note that OV-5 is intended to be only as exhaustive as necessary to attain the objectives for the architecture as stated in AV-1.
4.5.4 CADM Support for OV-5
Each OV-5 is stored as an instance of Document with its attribute
ArchitectureProductCategoryCode = ACTIVITY-MODEL-SPECIFICATION. The structure and content specification of the activity model is stored as an instance of InformationAsset with its attribute
TypeCode = ACTIVITY-MODEL.
An OV-5 can, in principle, apply to many architectures. All the Architecture instances to which that instance of Documentcan be linked, are done via ObjectVersionAssociation.
As depicted in Figure 4-17, each activity and subactivity cited in the OV-5 is stored as an instance of ProcessActivity, and its occurrence in the activity model is captured in CADM v1.5 through the corresponding entry in ObjectVersionAssociation. Similarly, the specific hierarchical breakdown of the activities in a given OV-5 is expressed by the appropriate entries in
ObjectVersionAssociation.27 Note that different activity models can depict different hierarchical breakdowns of the same activities; thus, the direct associations among instances of
ProcessActivity are not used for this purpose. Where applicable, instances of Capability can be linked to the desired instances of ProcessActivity and used to document specific capabilities underlying an operational activity.
The information flows and their component information flows cited in the OV-5 are stored in CADM v1.5 as instances of InformationElement, and their occurrences in the activity model are linked to the OV-5 through ActivityModelInformationElementRole. The decomposition of an
InformationElement into its components is specified by relating the instances in
ObjectVersionAssociation. (Note that in CADM v1.5, such decompositions are not necessarily dependent on any activity model or operational activity within the OV-5. Therefore, when capturing this type of information for use in more than one OV-5, one should ensure that it is consistent across all of them.)
Each InformationElement may occur in an IDEF0 activity model for a specific activity with four roles: input, control, output, and mechanism. CADM v1.5 specifies this via the entity
ActivityModelInformationElementRole. Note that these roles are for the use of the
InformationElement in relation to a specific OV-5 and do not depend semantically from the
InformationElement itself.28 The four roles are specified through the attribute CategoryCode in the entity ActivityModelInformationElementRole.
27 In CADM the Node Tree Diagram from IDEF0, which graphically depicts the activity hierarchy in a specific activity model is specified as an instance of Document with its attributeArchitectureProductTypeCode = NODE-TREE, and its contents specified via associations of Node
implemented through ObjectVersionAssociation. By linking each Node in the hierarchical nodal decomposition to a specific instance of
ProcessActivity it is possible to capture the content of the Node Tree Diagram.
28 It is for this reason that the DoD data standard for the entity listing information flows, formerly ICOM, has been changed to be
InformationElement. The new name (ActivityModelInformationElementRole) for the entity ACTIVITY-ICOM has also been approved as a change to the DoD data standards.
Figure 4-17: CADM Diagram for OV-5
Mechanisms can be very important for characterizing how elements of an activity model are, or are to be, supported in carrying out the underlying requirement. In general, mechanisms can include organizations, classes of organizations, systems, classes of materiel, persons with specific skills, and facilities. However, OV-5 focuses on requirements and therefore may intentionally omit references to materiel types, systems, and facilities. The (optional) linkage of those instances that are conceptualized as mechanisms for an OV-5 in CADM can be expressed
by the appropriate entries in ObjectVersionAssociation (see Volume III for details). In CADM v1.5, it is possible to assign instances of the following entities as the mechanisms in an OV-5:
• Organization • OrganizationType • OperationalRole • MaterielType • System • Facility • FacilityType
It is optional to incorporate some or all of the details of an activity model into a CADM- structured database. At a minimum, both InformationElement and ProcessActivity should be populated, so that the information flows and operational activities required for OV-3 and SV-5, respectively, are available for cross reference. Note that in CADM v1.5, system functions are specifically viewed as a subtype of ProcessActivity. This allows the cross reference of instances of system functions to other instances of ProcessActivity (i.e., operational activities or other system functions) through ObjectVersionAssociation. Note also that depending on the level of granularity specified, system functions may map to single SOA services.
A key element of operational requirement traceability is the relation of instances of
ProcessActivity to Taskinstances such as those included in (a) UJTL [CJCSM 3500.04C, 2002], (b) the UJTL extensions for tactical tasks, and (c) the mission essential tasks. In CADM v1.5, this traceability is supported by establishing the appropriate links between ProcessActivity(s) and
Task(s) through ObjectVersionAssociation. The same approach is used in CADM v1.5 to relate
Document(s) cited for details of an OV-5 (or other subtypes of InformationAsset) to instances of
InformationAsset.
4.5.4.1 OV-5 – Data Element Definitions