In the Department of Defense (DoD) world, the Command, Communications, Control, Computers, Intelligence, and Reconnaissance Architecture Framework (C4ISR-AF) specifies a unifying set of views of architecture. However, this architecture was published about the same time as the original UML specification and so did not use the UML notations or semantics. This chapter shows you how to represent the C4ISR products using the UML.
Notations and Topics Discussed | ||
|---|---|---|
C4ISR | Operational View | Systems View |
Technical View | Required Products | Supporting Products |
The UML is particularly adept at clearly showing architectures, system structures, and behavior—all vital aspects of any C4ISR-compliant product. Besides being useful and appropriate for creating C4ISR products, the UML has a number of other significant advantages for architectural description. First, it is a widely used standard that is taught in many universities. There are over a hundred books available about the UML, and there are easily over a dozen different commercial tools available. The UML is in widespread use by systems and software engineers in the real-time and embedded domain. The UML can be used all the way through the development process, from specifying the operational architecture (via C4ISR products) to systems engineering and software development—they can all use the same language for specification and design. This minimizes confusion and error-prone translation among discipline-specific languages.
The C4ISR Architecture Framework (C4ISR-AF) is a semantic framework for representing architectures in a consistent way [1]. It was conceived as a way of providing a common means to specify systems for the Department of Defense (DoD) in its many facets and programs. It is being updated by the DoD Architecture Framework Working Group (AFWG) into a new standard called the DoD Architecture Framework (DAF) [3,4]. As stated in the C4ISR-AF specification:
Architectures provide a mechanism for understanding and managing complexity. The purpose of C4ISR architectures is to improve capabilities by enabling the quick synthesis of “go-to-war” requirements with sound investments leading to the rapid employment of improved operational capabilities, and enabling the efficient engineering of warrior systems. The ability to compare, analyze, and integrate architectures developed by the geographical and functional, unified Commands, Military Services, and Defense Agencies (hereinafter also referred to as Commands, Services, and Agencies, or C/S/As) from a cross-organizational perspective is critical to achieving these objectives.
The C4ISR Architecture Framework is intended to ensure that the architecture descriptions developed by the Commands, Services, and Agencies are interrelatable between and among each organization's operational, systems, and technical architecture views, and are comparable and integratable across Joint and combined organizational boundaries.
The purpose of the C4ISR-AF is to provide assistance in the specification of architectures. Architecture itself has a number of definitions. The C4ISR-AF uses the definition of IEEE 610.12 [2]:
The structure of components, their relationships, and the principles and guidelines governing their design and evolution over time.
Architectures in the C4ISR-AF have three fundamental views: operational, systems, and technical. The emphasis in each of these views is, of course, different and distinct, but they overlap to a significant degree.
The operational view is a description of the tasks and activities, operational elements, and information flows required to accomplish or support a military operation. This view includes doctrine (which in another environment might be called business rules), activities, and assignment of these activities to operational elements and the sequences and time frames of the execution of the activities. Operational architectures are usually independent of the systems used to implement them.
The systems view is a description of the systems and their interconnections providing for, or supporting, war-fighting functions. The systems view includes the large-scale elements and objects that interact to achieve the operational goals as well as their locations, interconnections, and so on. The systems involved may include key nodes (including materiel), networks (as well as interconnections and interfaces), war-fighting platforms, weapons systems, and so on, as well as their various qualities of service such as mean time between failures (MTBF), maintainability, speed, capacity, and availability. Systems described in the systems view can be used to achieve many different operational architectures, organizations, and missions. The systems view does depend on the underlying technology described in the technical view and is constrained by its limitations.
The technical view provides the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements, whose purpose is to ensure that a conformant system satisfies a specified set of requirements. The technical view provides the basis for engineering specification of the systems in the systems view and includes technical standards. Put another way, the technical view is the engineering infrastructure that supports the systems view.
Within each of these architectural areas, the standard defines work products. The list of these products is given in Table 11-1. Each of these products will be discussed and in most cases a UML view that meets both the needs and intent of the product will be shown.
Table 11-1. DAF (C4ISR) Work Products[1]
Applicable View | Framework Product | UML Views | Framework Product Name | General Description |
|---|---|---|---|---|
All Views | AV-1 | Descriptions, notes, text | Overview and Summary Information | Scope, purpose, intended users, environment depicted, analytical findings. |
All Views | AV-2 | Model repository, reports | Integrated Dictionary | Data repository with definitions of all terms used in all products. |
Operational | OV-1 | Class diagram, deployment diagram | High-Level Operational Concept Graphic | High-level graphical/ textual description of operational concept. |
Operational | OV-2 | Class diagram, deployment diagram | Operational Node Connectivity Description | Operational nodes, operationalactivities performed at each node, connectivity and information exchange need lines between nodes. |
Operational | OV-3 | Report from model repository | Operational Information Exchange Matrix | Information exchanged between nodes and the relevant attributes of that exchange. |
Operational | OV-4 | Class diagram | Command Relationships Chart | Organizational, role, or other relationships among organizations. |
Operational | OV-5 | Activity diagram, statechart, class diagram with flows | Operational Activity Model | Operational activities, relationships among activities, inputs and outputs. Overlays can show cost, performing nodes, or other pertinent information. |
Operational | OV-6a | Sequence diagram, activity diagram, statechart | Operational Rules Model | One of the three products used to describe operational activity sequence and timing. Identifies business rules that constrain operation. |
Operational | OV-6b | Statechart, activity diagram | Operational State Transition Description | One of three products used to describe operational activity sequence and timing. Identifies business process responses to events. |
Operational | OV-6c | Sequence diagram, statechart, activity diagram | Operational Event-Trace Description | One of three products used to describe operational activity sequence and timing. Traces actions in a scenario or sequence of events and specifies timing of events. |
Operational | OV-7 | Class diagram | Logical Data Model | Documentation of the data requirements and structural business process rules of the operational view. |
Systems | SV-1 | Class diagram Text in descriptions | Systems Interface Description | Identification of systems and system components and their interconnections, within and between nodes. |
Systems | SV-2 | Class diagram | Systems Communications Description | Systems nodes and their related communications lay-downs. |
Systems | SV-3 | Class diagram, report on model | Systems-Systems Matrix | Relationships among systems in a given architecture; can be designed to show relationships of interest, e.g., system-type interfaces, planned vs. existing interfaces, etc. |
Systems | SV-4 | Use case diagram, class diagram with flows | Systems Functionality Description | Functions performed by systems and the information flow among system functions. |
Systems | SV-5 | Class diagram with dependencies, DOORS traceability matrix | Operational Activity to Systems Function Traceability Matrix | Mapping of systems back to operational capabilities or of system functions back to operational activities. |
Systems | SV-6 | Data flow on class diagram | Systems Data Exchange Matrix | Provides details of systems data being exchanged between systems. |
Systems | SV-7 | Class diagram with constraints for performance quality of service | Systems Performance Parameters Matrix | Performance characteristics of each system(s) hardware and software elements, for the appropriate timeframe(s). |
Systems | SV-8 | Activity diagram | Systems Evolution Description | Planned incremental steps toward migrating a suite of systems to a more efficient suite or toward evolving a current system to a future implementation. |
Systems | SV-9 | Text | Systems Technology Forecast | Emerging technologies and software/hardware products that are expected to be available in a given set of timeframes and that will affect future development of the architecture. |
Systems | SV-10a | Statechart, activity diagram, sequence diagram | Systems Rules Model | One of three products used to describe systems activity sequence and timing. Constraints that are imposed on systems functionality due to some aspect of systems design or implementation. |
Systems | SV-10b | Statechart | Systems State Transition Description | One of three products used to describe systems activity sequence and timing. Responses of a system to events. |
Systems | SV-10c | Sequence diagram | Systems Event-Trace Description | One of three products used to describe systems activity sequence and timing. System-specific refinements of critical sequences of events and the timing of these events. |
Systems | SV-11 | Deployment diagram, class diagram | Physical Schema | Physical implementation of the information of the logical data model, e.g., message formats, file structures, physical schema. |
Technical | TV-1 | Hyperlinks in model, text | Technical Standards Profile | Extraction of standards that apply to the given architecture. |
Technical | TV-2 | Text | Technical Standards Forecast | Description of emerging standards that are expected to apply to the given architecture, within an appropriate set of timeframes. |
[1] There are a number of ways to map C4ISR products to the UML. This table represents one way proposed by the author. | ||||
The C4ISR-AF identifies a large number of artifacts, called products, that are used in the description of the various architecture views. Some of these are required for compliance to the C4ISR-AF, but most are optional and can be used when appropriate. These are referred to as supporting products. In this section, we discuss the required products listed in Table 11-1.
The Overview and Summary Information product is an essential artifact for making projects compliant with C4ISR-AF. [1] provides a list of the required contents of this artifact as well as a sample format. This information may be directly entered into the model in the model description field, as shown in Figure 11-1, or it may be created in a separate textual document and hyperlinked in the Rhapsody model.
The Integrated Dictionary product defines the metadata of the product and is normally provided in a textual output. This metadata is maintained for you automatically by Rhapsody and may be viewed in the Rhapsody browser or used to generate reports and details as desired. This is illustrated in Figure 11-2. Besides the built-in report-on model, which can generate reports, Rhapsody has a powerful reporting facility known as ReporterPLUS, which allows you to generate reports in customizable formats and templates.
This is a very general architectural picture of the architecture-description products. It is used to facilitate human-human communication, especially among high-level decision makers. Commonly, it graphically depicts the coordinated deployment of systems to achieve the operational objectives. This is easily done in a class or deployment diagram, using stereotypes to identify the various kinds of systems involved in the operational concept. Figure 11-3 shows an example operational concept diagram as a class diagram using standard UML elements—classes with appropriate stereotypes and dependency relations.
Figure 11-4 shows the same diagram using meaningful bitmap icons to represent the operational elements. This is very simple to do with Rhapsody and simplifies the interpretation of the graphic.
The Operation Node Connectivity Description identifies the operational nodes, their connections, and the information shared among them. In the UML, operational nodes may be represented as classes on class diagrams or as nodes on deployment diagrams. In Figure 11-5,[2] operational nodes and subnodes are shown as classes; the interfaces among the operational nodes are mediated via the associations. The actual information content transmitted along these associations is captured in constraints (the notes with the curly braces), and supporting information is shown in either free text or comments within note boxes.
The same information is shown in the diagram in Figure 11-6, except that the operational nodes are shown as nodes on a deployment diagram. In general, classes have richer semantics than nodes on deployment diagrams and so are usually preferred for that reason.
The Operational Information Exchange Matrix expresses the relationship between activities, operational elements, and information flow, focusing on the latter. The UML doesn't have a matrix notation, but this can be cast as a specialized format of a report constructed from the model repository held by Rhapsody.
Alternatively, the data flow notation of the UML 2.0 can easily depict the information exchange among operational elements. In the UML diagram in Figure 11-7, icons are used to represent operational elements (modeled with UML classes) with information flows among these elements.
The System Interface Description shows the structural elements of the systems architecture and the informational interfaces among them.
Sometimes it is important to show the large-scale deployment of the elements into the systems rather than their categories, as is shown in Figure 11-8. Figure 11-9 shows the deployed systems as structured classes with the internal subsystems as classes. These elements may have stereotypes attached, if desired. This more detailed view shows the subsystems and their interconnections within the systems as well as between systems.
The Technical Architecture Profile is a description of the technologies to be included in the system, normally as references to application standards documents, such as [1] or the POSIX standard. These may be specified in a textual document (most common) or they may be added as constraints to the model elements.
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.
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.
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.
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-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.
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.
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
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
The C4ISR (and the upcoming DAF) standard defines a number of work products, some of which are identified as required for a system to be compliant; others are identified as supporting and are recommended but not required. The 1997 standard [1] came out at about the same time as the UML standard and therefore doesn't take advantage of the rich semantics and clear notation provided by the UML. Since then, the UML has been widely adopted in the specification of software and systems within the DoD and other environments. This chapter discusses each product required by the C4ISR and shows how standard UML views and semantics can be used to represent them. Clearly, the unifying nature of the UML meets the needs of the C4ISR very well, now and into the future.
The aircraft weapon systems diagrams were taken or adapted from the ADMS model by Andy Lapping of I-Logix. Some of the other examples were adapted from [1].