11.4 Supporting Products

There are a large number of optional supporting products defined in [1], [3], and [4], most of which can be easily and productively represented in the UML.

11.4.1 OV-4 Command Relationships Chart

The OV-4 diagram is used primarily for the command structure of some unit or units of battle. The UML view for this is a class diagram, using aggregation to show ownership. Other relations may be added; for significant communications between subunits or individuals, associations should be used. For less obvious relations, dependencies may be used. Figure 11-10 shows a relation set, including ownership and assignment relations, when a person is assigned to one unit or individual but commanded by another.

Figure 11-10. OV-4 Command Relationship Chart

11.4.2 OV-5 Operational Activity Model

The Operational Activity Model specifies the flow of execution among activities, possibly with the generation of artifacts such as reports and OP orders. Figure 11-11 uses the UML activity diagram to show the primary activities and their subactivities to achieve a Joint Force Targeting activity. The nesting depicts the whole-part nature of the activities (i.e., activities may be divided into smaller subactivities). The arrows depict the flow of execution as the activities complete over time. The bars indicate forks or joins; a fork indicates a branching into concurrent (simultaneously executing) activities while a join indicates a merging together of previously concurrent activities.

Figure 11-11. OV-5 Operational Activity Model

Often, activities are performed by a set of collaborating operational or system elements. This can be indicated using swim lanes to divide the activities into activities done by a single operational and those done by a systems entity. An abstract example is shown in Figure 11-12, with swim lanes for external elements, special OPs, CIC, battalion commander, and air support. This diagram shows forks and joins as well as branch points (indicated with a diamond). A fork differs from a branch in that all transitions from a fork become simultaneously active while only a single transition from a branch is taken.

Figure 11-12. OV-5 Operational Activity Model with Swim Lanes

Figure 11-13 shows a concrete example. Two entities, OTC CWC and FLTCINC, are shown executing a set of activities. The structure of their collaboration becomes clear in this diagram. Diagram connectors are used to beautify the diagram.

Figure 11-13. OV-5 Operational Activity Model with Two Agencies

11.4.3 OV-6a Operational Rules Model, SV-10a Systems Rules Model

The operational rules model shows the relationship among the activities. This can be done using any of the behavioral diagrams of the UML:

• An activity diagram is preferred when the activities flow from one activity to the next upon completion, but may have forks and joins (concurrently executing activities) or branching (alternatives), or may be assigned to different system or operational elements (via swim lanes).

• A statechart is preferred when the states or conditions of existence persist until some event of interest occurs, such as an incoming asynchronous event (e.g., a hostile missile launch), a synchronous service request (e.g., the requester waits until the service is completed before moving forward), or a timeout (e.g., a delayed launch). Behaviors are executed during the change of state or within a state when such an event is received.

• A sequence diagram is preferred when a particular operational scenario is to be shown, that is, a collaborative behavior of system or operational elements, beginning with specific preconditions and with a specific event sequence, ignoring other possibilities.

In this case (see Figure 11-14), we show only a class diagram for the logical data model and describe some business rules. In the later OV-6 diagrams we present a statechart for the OV-6b example and a sequence diagram for the OV-6c example.

Figure 11-14. OV-6a Logical Data Model for Operational Rules

Business rules can be applied to the logical data model (taken from [1]):

 For Each MISSILE TRACK entity instance     If MISSILE TRACK boost phase code > 0,          Then MISSILE TRACK acceleration rate is          non-null     Else MISSILE TRACK drag effect rate is non-null          And          There Exists a MISSILE TRACK POINT            entity instance Such          That                       MISSILE TRACK.SOURCE TRACK                         identifier =                       MISSILE TRACK POINT.SOURCE TRACK                       identifier          And                       MISSILE TRACK POINT.SOURCE                         identifier          End If End For 

11.4.4 OV-6b Operational State Transition Description, SV-10b Systems State Transition Description

The Operational State Transition Description is best described by a state chart. In Figure 11-15, the AIDSystem shows the states it goes through in selecting and destroying a target.

Figure 11-15. OV-6b Statechart for Operation State Transition Description

11.4.5 OV-6c Operational Event-Trace Description, SV-10c Systems Event Trace Description

OV-6c, the Event-Trace Description, is used to show the specific flow or sequence of messages and events during a very specific scenario or example execution of the system. Branch points are typically not shown. Emphasis is on a specific execution given a specific set of preconditions and a specific sequencing of incoming events and messages. It is common to produce dozens of such operational scenarios, each on a separate diagram, to explore variations of system behavior. Figure 11-16 shows a typical example of an event trace description shown with a UML sequence diagram.

Figure 11-16. OV-6c Event-Trace Description with Sequence Diagram

Figure 11-17. OV-7 Logical Data Model

11.4.6 OV-7 Logical Data Model

The logical data model focuses on the information known to or processed by the system during its execution. In the UML, this is modeled with class diagrams. Class diagrams can depict system structure as well as information content, so to achieve the OV-7 goals, the class diagrams focus on the informational content of the system and the relationships among those data, and not on the processing of this information.

11.4.7 SV-3 Systems-Systems Matrix

The Systems-Systems Matrix shows the relationships among the set of large-scale entities (systems). As mentioned previously, the UML does not have a matrix view. However, the information can be shown easily on a class diagram (also a two-dimensional view), as has been done in Figure 11-18. It is also possible to construct a matrix from the data held in the model repository.

Figure 11-18. SV-3 Systems-Systems Matrix with Class Diagram

11.4.8 SV-4 Systems Functionality Description

The Systems Functionality Description (SV-4) shows the functionality of a system or set of systems at a high-level view. The natural view in the UML is the use case diagram. Of course, using just the names of the use cases is insufficient, so Rhapsody has description fields that can hold text (and/or hyperlinks to other documents in other tools such as Word or Framemaker) to more fully explain the functionality represented by the use case. It is common to detail the use case with a combination of text, statecharts, activity diagrams, and sequence diagrams. Figure 11-19 shows a use case diagram with the description field for one of the use cases.

Figure 11-19. SV-4 Systems Functionality Description

11.4.9 SV-5 Operational Activity to Systems Function Traceability Matrix

The purpose of the Operational Activity to Systems Function Traceability Matrix (SV-5) is to allow mapping from operational activities defined in OV-5, OV-6a, PV-6b, and OV-6c into systems functions. This can be done in UML using dependencies if desired, but the most common way in the UML to achieve this goal is with the swim lanes in the activity diagrams. The swim lanes can represent system elements or functions while the activities in the diagram are the operational activities. See Figure 11-12 and Figure 11-13 for examples.

Another common approach to traceability is to use third-party requirements traceability tools, such as DOORS, to define the mapping between the operational activities and the system use cases or system elements.

11.4.10 SV-6 Systems Data Exchange Matrix

The Systems Data Exchange Matrix (SV-6) shows how information is exchanged among system elements. Although the name of the product includes the word matrix, it may be met by any visualization that shows the information flow among system elements. The most natural view in the UML is to show the system elements as classes connected with data flows, as defined in the UML 2.0 specification. Figure 11-20 shows elements of an aircraft weapons management system with information flows among the elements. An information flow is shown as a «flow» stereotype of dependency, with information items attached. These information items may be rich and complex, and so may themselves be classes with their structure depicted on the diagram(s).

Figure 11-20. SV-6 Data Flow on Class Diagram

11.4.11 SV-7 Systems Performance Parameters Matrix

Performance is, of course, a crucial aspect of military and other real-time and embedded systems. In the UML, performance is a rather large subclass of the more general concept of QoS. Performance-related QoS properties include worst-case execution time, throughput, average execution time, capacity, and so on. The OMG provides a standard set of performance-related property tags in [5]. In the UML, QoS properties may be attached to just about any element. However, whether standard or custom properties are used, the usage model is the same. The system elements are stereotyped to have the appropriate properties (tags) and then these properties are assigned values in constraints. These constraints can be shown on the class diagrams with the elements they constrain, such as in Figure 11-21, or they may be view in the model browser and in reports, as shown in Figure 11-22.

Figure 11-21. SV-7 Systems Performance on Class Diagram

Figure 11-22. SV-7 Systems Performance in Reports and Browser

11.4.12 SV-8 Systems Evolution Description

The Systems Evolution Description (SV-8) is logically a map of development activities leading to successive releases and versions of one or more systems. The UML activity diagram represents such processes clearly and distinctly. In Figure 11-23, the development activities are shown in the rounded rectangles while the artifacts are shown in the rectangles. Such evolution descriptions may be as complex as needed to describe the development plans for any system element or set of system elements.

Figure 11-23. SV-8 Systems Evolution Description

11.4.13 SV-9 Systems Technology Forecast

As with TV-2, Systems Technology Forecast (SV-9) is almost exclusively a textual document. There is no UML representation, although text can be represented in the description fields of a tool such as Rhapsody. Additionally, external documents may be linked to with hyperlinks in Rhapsody so that selecting them executes the appropriate application to read, view, or modify the document.

11.4.14 SV-11 Physical Schema

The Physical Schema shows how the logical data model (OV-7) is to be physically realized that is, how the information maps onto artifacts, devices, and other elements in the systems architecture view. This is most commonly done with a deployment diagram, where the nodes represent the hardware devices and the components represent the software or informational elements. It can also be done in a component diagram in which the logical elements (classes) are mapped into the components. A class diagram is yet another possibility, where some classes represent the physical items and others represent the logical elements.

Figure 11-24 shows the mapping of components onto the deployment nodes (hardware elements) using a standard UML deployment diagram.

Figure 11-24. SV-11 Physical Schema with Deployment

Physical Schema may also refer entirely to the organization of software elements into component artifacts, such as documents, link libraries, executables, and so on. Figure 11-25 shows an example of this. The stereotypes «Executable», «Library», and «Hardware» show the kind of component being represented.

Figure 11-25. SV-11 Physical Schema with Components