Action† Architecture† Document† Event† Guidance† InformationExchangeRequirement† InformationTechnologyRequirement† MissionArea† Node OperationalRole† Organization† OrganizationType† ProcessActivity† ProcessEvent† SoaOperation† SoaService† SoaServiceSpecificationTemplate† System† Task† †)
The descriptions of these elements have been provided in the preceding sections
32 In CADM v1.5 the linkage between Node and ProcessActivity is used in the OV-6c to represent the lifeline associated with one or more operational activities. When ProcessActivity is specialized as a system function this same entity is used in SV-10c to represent the lifeline associated with one or more system functions.
4.7 LOGICAL DATA MODEL (OV-7) 4.7.1 OV-7 – Product Description
Product Definition. The OV-7 describes the structure of an architecture domain’s system data types and the structural business process rules (defined in the architecture’s OV) that govern the system data. It provides a definition of architecture domain data types, their attributes or characteristics, and their interrelationships.
Product Purpose. OV-7, including the domain’s system data types or entity definitions, is a key element in supporting interoperability between architectures, since these definitions may be used by other organizations to determine system data compatibility. Often, different organizations may use the same entity name to mean very different kinds of system data with different internal structure. This situation will pose significant interoperability risks, as the system data models may appear to be compatible, each having a Target Track data entity but having different and incompatible interpretations of what Target Track means.
An OV-7 may be necessary for interoperability when shared system data syntax and semantics form the basis for greater degrees of information systems interoperability, or when a shared database is the basis for integration and interoperability among business processes and, at a lower level, among systems.
Product Detailed Description. OV-7 defines the architecture domain’s system data types (or entities) and the relationships among the system data types. For example, if the domain is missile defense, some possible system data types may be trajectory and target with a relationship that associates a target with a certain trajectory. On the other hand, architecture data types for the DoDAF (i.e., DoDAF-defined architecture data elements, AV-2 data types, and CADM entities) are things like an operational node or operational activity. OV-7 defines each kind of system data type associated with the architecture domain, mission, or business as its own entity, with its associated attributes and relationships. These entity definitions correlate to OV-3 information elements and OV-5 inputs, outputs, and controls.
Although they are both called data models, OV-7 should not be confused with the CADM. OV-7 is an architecture product and describes information about a specific architecture domain. The CADM is not an architecture product. The CADM is a database design for a repository of DoDAF products and architecture data. CADM-based repositories can store architecture products, including Logical Data Models, from any DoDAF-based architecture project. Thus, the CADM addresses a structure for storing architecture data (e.g., instances of operational nodes and operational activities), while a Logical Data Model for missile defense, for example, might define architecture domain entities and relationships such as missile tracks and points of impact.
The purpose of a given architecture helps to determine the level of detail needed in this product. A formal data model (e.g., the Integrated Definition for Data Modeling [IDEF1X]) [FIPS 184, 1993] that is detailed down to the level of architecture domain system data, their attributes, and their relationships is required for some purposes, such as when validation of completeness and consistency is required for shared data resources. However, for other purposes, a higher-level conceptual data model of the domain of interest will suffice, such as a subject area model or an entity-relation model without attributes. The term logical data model is used here in this context, regardless of the level of detail the model exhibits.
The architecture data elements for OV-7 include descriptions of entity, attribute, and relationship types. Attributes can be associated with entities and with relationships, depending on the purposes of the architecture.
Figure 4-29 provides a template for OV-7 (with attributes). The format is intentionally generic to avoid implying a specific methodology.
Entity Name Relationship Attributes • ... • ... • ... • ... • ... • ... Relationship Name
Figure 4-29: OV-7 – Template
4.7.2 UML Representation
OV-7 may be modeled in UML using a class diagram. See Figure 4-30. Class diagrams offer all the UML elements needed to produce entity-relationship diagrams. Class diagrams consist of classes, interfaces, collaborations, dependency, generalization, association, and realization relationships. The attributes of these classes can be expanded to include associations and cardinality [Booch, 1999]. Classes that appear in an OV-7 class diagram correlate to OV-3 information elements and OV-5 inputs, outputs, and controls. The OV-7 class diagram is a separate diagram from the class diagrams that may be developed for other products (e.g., OV-4).
Figure 4-30: UML Class Diagram for OV-7 – Template
4.7.3 Net-Centric Guidance for OV-7
Augmented Product Purpose. In the NCE, the OV-7 describes the structure of data types (information elements) for information being made available or being consumed by the OV-5 activities and provides the organization and composition of metadata that can be used to characterize the information exchanged in the NCE.
Net-Centric Product Description. The OV-7 traditionally defines the architecture domain’s system data types (or entities) and the relationships among the system data types. The net-centric OV-7 provides the same, but with an emphasis on two concerns: 1) describing data types for information being exchanged between nodes, and 2) using standards or commonly understood COI guidance for domain vocabularies, taxonomies, and upper-level ontologies. net-centricity relies on the use of commonly understood vocabularies and meanings to facilitate better information sharing in the NCE. A net-centric OV-7 supports data understandability in the NCE by defining the data and its relationships agreed to by a collaborative COI. These agreements may be documented in more detail in the SV-11 as a specific information agreement or schema for use in the NCE.
In the NCE, information and capabilities (provided as services) should be tagged so that they are easily discoverable in the NCE. Accordingly, a specific use of the OV-7 product to support net-centricity may be the documentation of the organization and composition of metadata structures for discovery. This may include the descriptive information and capabilities being
offered as specified by DoD Discovery Metadata Specification (DDMS)33 and any COI
extensions specific to the architecture, or the required and optional metadata that supports the
description of services (i.e., the SST) with which the architecture complies with. The OV-7 metadata may be used to provide the structural constraints for XML data structures described in Data Catalogs (local or enterprise). As information and capability assets are tagged and provided in appropriate repositories (DoD Metadata Registry, data catalogs, or service registries), Service
Consumers and Unanticipated Users can more easily search for and discover these assets to
execute their missions more effectively and efficiently. Like the domain vocabularies documented in the OV-7 product, the metadata structures should be agreed upon by COIs or standards organizations so that they are commonly understood.
4.7.4 CADM Support for OV-7
Figure 4-31 provides a high-level diagram from the CADM showing key entities that are used to store architecture data for OV-7 in a CADM-conformant database.
Figure 4-31: CADM Diagram for OV-7
Each OV-7 is represented as an instance Document with its attribute
ArchitectureProductCategoryCode = LOGICAL-DATA-MODEL. OV-7 cites a specific instance of
ConceptualDataModel (a subtype of InformationAsset). The OV-7 use of the ConceptualDataModel
DoD Data Architecture (DDA) data model. The key entities in this specification include
DataEntity, DataAttribute, and the data domains (all subtypes of InformationAsset). Additional specification of the OV-7 is supported in CADM v1.5 through ObjectByReference, with
CategoryCode values equal to DATA-ENTITY-RELATIONSHIP, CATEGORY-RELATIONSHIP, DATA- DOMAIN-LIST, and DATA-DOMAIN-LIST-VALUE respectively. Each DataEntity can be directly related to an ActivityModelInformationElementRole to establish a link between data models and activity models.
4.7.4.1 OV-7 – Data Element Definitions