1 NOMBRE DEL PROPIETARIO:
PLANO DE SECTORES CATASTRALES
AV-2 defines the architecture data and their common terms of reference used in creating, maintaining, and using architecture products. The OV, SV, and TV products are interrelated, sometimes very extensively. Because of this inter-relationship among products and across architecture efforts, it is useful to define common terminology with common definitions (referred to as taxonomies) in the development of the architecture products. These taxonomies are the building blocks for architecture products. The need for standard taxonomies derives from lessons learned from early DoD architecture development issues, including the independent development of multiple operational architectures that could not be integrated. Integration was impeded because of the use of different terminology to represent the same architecture data. Use of taxonomies to build architecture products has the following benefits over free-text labeling:
• Provides consistency across products
• Provides consistency across architectures
• Facilitates architecture development, validation, maintenance, and re-use
• Traces architecture data to authoritative data sources
The following are critical taxonomies requiring concurrence and standardization for integrated architectures:
• Operational Nodes that represent Organizations, Organization Types, and Occupational Specialties. The taxonomy minimally consists of names, descriptions, and breakdowns into the parts of the organization, organization type, or human role.
• Operational Activities (or Tasks).15 The taxonomy minimally consists of names, descriptions, and decomposition into the constituent parts that comprise a process activity.
• Information Elements. The taxonomy minimally consists of names of
information elements exchanged, descriptions, decomposition into constituent parts and subtypes, and mapping to system data elements exchanged.
• Systems Nodes that represent facilities, platforms, units, and locations. The taxonomy minimally consists of names, descriptions, breakdowns into constituent parts of the node, and categorizations of types of facilities, platforms, units, and locations.
• Systems consisting of family of systems (FoSs), system of systems (SoSs), networks of systems, individual systems, and items (e.g., equipment hardware and software). The taxonomy minimally consists of names, descriptions, and breakdowns into the constituent parts of the system and categorization of types of systems. Typing may also address variations across time and systems node installation.
• System Functions. The taxonomy minimally consists of names, descriptions, and decomposition into the constituent parts that comprise a system function.
15 Operational Activities defined and standardized by the Joint Staff are in the form of Mission Essential Tasks [CJCSM 3500.04D, 01 AUGUST 2005]. Operational Activities are also specified (and sometimes standardized) in the form of process activities arising from process modeling. It is sometimes convenient to merge these sets, either as activities or tasks.
• Triggers/Events. The taxonomy minimally consists of names, descriptions, and breakdown into constituent parts of the event or trigger and categorization of types of events or triggers.
• Performance Parameters. The taxonomy minimally consists of names,
descriptions, units of measure, and conditions that may be applicable to performance parameters.
• Technical Standards. The taxonomy minimally consists of categories of
standards (e.g., DISR’s Service Areas).
• Technology Areas. The taxonomy minimally consists of names, descriptions, and categories of technologies into which individual science and technology initiatives and programs can be categorized.
These taxonomies are used to construct various architecture products as shown in Figure 3-3. In the table, taxonomy refers to a set of relationships among pairs of instances, often hierarchical. Composition refers to the use of one instance to represent and include as a subset or group of instances. The symbols in the table represent the potential role played by the taxonomy and not by the architecture data elements themselves (e.g., Operational Nodes are important to OV-1, but taxonomies of these nodes are important for products OV-2 through OV-6). The table shows that taxonomies potentially have a strong role to play in AV-2 as well as many of the OV, SV, and TV products.
Note: Not all architecture data in a given taxonomy is useful in every architectural development. However, given the ongoing evolutionary change in organizations, systems, and processes, the value of using established, validated taxonomic structures that can be expanded or contracted as needed becomes obvious. Moreover, the development of new products over time is greatly simplified as understanding of the taxonomies is increased. Standard taxonomies, like DISR Service Categories, become building blocks for more comprehensive, quality architectural products. The DoD Extensible Markup Language (XML) Registry and Clearinghouse and the Net-Centric Implementation Document (NCID) are potential sources for taxonomies.
In some cases, a specific community may have its own operational vocabulary. This local operational vocabulary may use the same terms in radically different ways from other operational communities. (For example, the use of the term track refers to very different concepts in the carrier battle group community than in the mine-sweeper community. Yet both of these communities are Navy operational groups and may participate together in littoral warfare task forces.) In these cases, the internal community versions of the architecture products should use the vocabulary of the local operational community in order to achieve community cooperation and buy-in. These architecture products should include notes on any unique definitions used and provide a mapping to standard definitions, where possible.
1 2 1 2 3 4 5 6 7 1 2 3 4 5 6 7 8 9 10 11 1 2
Operational Nodes
Organizations, Types of Organizations, and Occupational Specialties
Taxonomy & Composition
Operational Activities and Tasks Taxonomy &
Composition
Information Elements
and mappings to Systems Data Elements
Taxonomy & Composition
System Functions Composition
Performance Parameters Taxonomy &
Composition
Technical Standards
Info Processing, Info Transfer, Data, Security, and Human Factors
Taxonomy & Composition
Technology Areas
Systems and Standards
Taxonomy & Composition
Triggers / Events Taxonomy & Composition
z= Taxonomy element plays a primary role = Secondary role blank = Element not part of this product
TAXONOMY TYPES STRUCTURE Operational View (OV) System View (SV) ARCHITECTURE PRODUCTS AV TV z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z Systems Nodes
Facilities, Platforms, Units, and Locations Taxonomy & Composition
Systems
Family of Systems, System of Systems, Networks, Applications, Software, and Equipment
Taxonomy & Composition z z z z z z z z z z z z z z 1 2 1 2 3 4 5 6 7 1 2 3 4 5 6 7 8 9 10 11 1 2 Operational Nodes
Organizations, Types of Organizations, and Occupational Specialties
Taxonomy & Composition
Operational Activities and Tasks Taxonomy &
Composition
Information Elements
and mappings to Systems Data Elements
Taxonomy & Composition
System Functions Composition
Performance Parameters Taxonomy &
Composition
Technical Standards
Info Processing, Info Transfer, Data, Security, and Human Factors
Taxonomy & Composition
Technology Areas
Systems and Standards
Taxonomy & Composition
Triggers / Events Taxonomy & Composition
z= Taxonomy element plays a primary role = Secondary role blank = Element not part of this product
TAXONOMY TYPES STRUCTURE Operational View (OV) System View (SV) ARCHITECTURE PRODUCTS AV TV z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z Systems Nodes
Facilities, Platforms, Units, and Locations Taxonomy & Composition
Systems
Family of Systems, System of Systems, Networks, Applications, Software, and Equipment
Taxonomy & Composition z z z z z z z z z z z z z z
Figure 3-3: Taxonomies Used in Products
3.2.3 UML Representation
The UML tool(s) being used for analysis and design usually include a data dictionary facility that generates a data dictionary or glossary of terms from the annotated definitions entered by users as they build Framework products. In addition, the collection of products for a specific architecture as stored in the tool comprises the repository of architecture data and the metadata specification.
3.2.4 Net-Centric Guidance for AV-2
Augmented Product Purpose. In the NCE, the AV-2 contains descriptions of architecture terms and conventions for their use in the architecture project.
Net-Centric Product Description. The AV-2 traditionally serves as a glossary that defines terms used in an architecture. Architecture products are constituted of architecture data elements. Architecture data elements can be used in multiple views, where a data element defined in one view is consistently referenced in other views. The names and definitions of the architecture data elements contribute to the AV-2 Taxonomy of terms. Accordingly, in the NCE, the AV-2 will define net-centric elements and associated metadata, i.e., the source of the definition.
The net-centric AV-2 will capture new terms and definitions across all products used to describe the NCE. Because the OV, SV, and TV products are interrelated, it is important to define common terminology with common definitions, referred to as taxonomies, in the development of the architecture products. The net-centric AV-2 may include the following taxonomy:
Services consisting of family of services, individual services, and hardware and software items. The taxonomy minimally consists of service name, service specification, and decomposition into the constituent service operations. The taxonomies in the AV-2 will be used to categorize service functionality (system functions taxonomy), information provided by a service (information elements taxonomy), service performance categories (performance attributes taxonomy), service technical standards categories (technical standards taxonomy), service technology area dependencies (technology taxonomy), and service operational node consumers and providers (operational nodes taxonomy). The use of taxonomies standardized within a COI will help disambiguate service discovery. Documenting these various aspects of net-centricity in the AV-2 products is a key step to enabling the creation of net-centric architectures across the DoD enterprise. As various tools support the net-centric paradigm for architecture development, the AV-2 becomes increasingly important to enable federation of architectures and the use of architecture products to manage capability portfolios.
3.2.5 CADM Support for AV-2
AV-2 may consist of a CADM-conformant database or repository, specifically in reference tables like Materiel, MaterielType, Organization, OrganizationType, InformationElement, and
ProcessActivity that are developed within an architecture or set of architectures. More than one dictionary can be maintained, but only one is needed for each architecture. Each dictionary is stored as an instance of Document with a category code designating it as a DATA-DICTIONARY- SPECIFICATION.
When an architecture database or repository is not provided or deemed adequate, two additional types of data dictionaries are possible:
• An offline dictionary whose terms are stored in a document. Reference to it is stored in Document with the name of the instance storing the filename and the attribute UniversalResourceLocatorText to store its URL.
• An online dictionary whose terms are included in a CADM-structured database. The identity of the dictionary is stored in DataDictionary (a subtype of
InformationAsset); each term can be identified, named, and described via
ObjectByReference. The relationship to Document is accomplished via
ObjectVersionAssociation; the relation to the pertinent instance of Architecture is also recorded in ObjectVersionAssociation.
Figure 3-4 provides a high-level diagram from the CADM showing key entities that are used to store architecture data in the form of glossaries, documents, and data dictionaries for this architecture product in a CADM-conformant database.
Figure 3-4: CADM Diagram for AV-2
Taxonomies relate two instances, often hierarchically (tree diagram); they may be viewed as a set of folders and subfolders. In CADM v1.5, all hierarchical decompositions can be expressed via ObjectVersionAssociation. The following identifies the types of taxonomic decompositions that can be expressed in CADM v1.5 using this approach:
• Operational Nodes:
− Associations among Organization(s);Associations among
OrganizationType(s) for various kinds of operational elements
− Associations amongNode(s)(for specific nodes, each of which could represent an operational unit, a command post, a command post cell, an operational facility, a command element, etc.)
• System and Other Physical Nodes:
− Associations amongNode(s)(for specific nodes, each of which represents a platform, system, etc.)
− Associations amongMilitaryPlatform(s)
− Associations amongFacility(s)
− Associations amongOrganization(s)(each organizational unit is assigned a unique ORGANIZATION IDENTIFIER and an ORGANIZATION VERSION INDEX)
− Associations amongNode(s)(when Nodedenotes specific location)
− Associations amongFeature(s)(when Featuredenotes a specific geospatial feature)
• Systems:
− Associations amongSystemType(s)(i.e., among general classes of systems)
− Associations among System(i.e., among versions of a System)
− Associations amonginstances System(s)at a specific Node(s)
• SOA Services:
− Associations among SoaService(s) (i.e., among a main class of a SOA Service representing a family of services and its components)
− Associations among SoaService(s) indicating relations other than being a component of a family of services (e.g., replacement, equivalence)
− Associations showing the decomposition of a SoaService into finer granularity
• Operational (Process) Activities and Tasks:
− Associations among ProcessActivity(s)
− Associations among Task(s)(e.g., in UJTL);in the Global Information Grid [GIG] and the Department of the Navy Integrated Architecture Database [DIAD]), each Taskcorresponds to a unique ProcessActivity
and their linkage can be expressed as well
− Associations among Action(s)
− Associations amongActivityModel(s)(e.g., for IDEF0 node trees)
In addition, in CADM v1.5, ObjectVersionAssociation allows the linkage of instances of
Document to all the entities mentioned above, i.e., Action, Agreement, Capability, Event, Feature,
Guidance, InformationAsset, MaterielType, MissionArea, Network, Node, ProcessActivity, System, etc. (See Volume III for a complete description.)
3.2.5.1 AV-2 – Data Element Definitions