DoD Architecture Framework Version 1.0, Volume 2 - AcqNotes.com

More documents

Recommendations

Info

TABLELIST OF TABLES (Cont)PAGE5-13 Data Element Definitions for Systems State Transition Description(SV-10b) ............................................................................................................5-725-14 Data Element Definitions for Systems Event-Trace Description(SV-10c).............................................................................................................5-765-15 Data Element Definitions for Physical Schema (SV-11)...............................5-806-1 Technical Standards Profile (TV-1) Template ................................................6-26-2 TV-1 Te mplate with Corresponding System Elements ..................................6-46-3 TV-1 Template for Systems with Corresponding Time Periods ...................6-56-4 Data Element Definitions for Technical Standards Profile (TV-1) ...............6-66-5 Data Element Definitions for Technical Standards Forecast (TV-2)..........6-157-1 Detailed Architecture Data Element Relationships ........................................7-9xv
1 INTRODUCTION1.1 OVERVIEWThe Department of Defense (DoD) Architecture Framework (DoDAF), Version 1.0,defines a common approach for DoD architecture 1 description development, presentation, andintegration for both warfighting operations and business operations and processes. TheFramework is intended to ensure that architecture descriptions can be compared and relatedacross organizational boundaries, including Joint and multinational boundaries.An architecture description is a representation of a defined domain, as of a current or futurepoint in time, in terms of its constituent parts, what those parts do, how the parts relate to eachother and to the environment, and the rules and constraints governing them. Within the DoDAF,architectures are described in terms of three views: Operational View (OV), Systems View(SV), and Technical Standards View (TV). An architecture description is composed ofarchitecture products that are interrelated within each view and are interrelated across views.Architecture products are those graphical, textual, and tabular items that are developed in thecourse of gathering architecture data, identifying their composition into related architecturecomponents or composites, and modeling the relationships among those composites to describecharacteristics pertinent to the architecture’s intended use. Underlying the products is the All-DoD Core Architecture Data Model (CADM), which defines a standard set of architecture dataentities and relationships of architecture data.The term integrated architecture refers to an architecture description that has integratedOVs, SVs, and TVs (i.e., there are common points of reference linking the OV and SV and alsolinking the SV and TV). The Operational Activity to Systems Function Traceability Matrix(SV-5), for example, relates operational activities from the Operational Activity Model (OV-5)to system functions from the Systems Functionality Description (SV-4); the SV-4 systemfunctions are related to systems in the Systems Interface Description (SV-1), thus bridging theOV and SV. An architecture is defined to be an integrated architecture when products and theirconstituent architecture data elements are developed such that architecture data elements definedin one view are the same (i.e., same names, definitions, and values) as architecture data elementsreferenced in another view.The term architecture is generally used both to refer to an architecture description and anarchitecture implementation. An architecture description is a representation of a current orpostulated real-world configuration of resources, rules, and relationships. Once therepresentation enters the design, development, and acquisition portion of the systemdevelopment life-cycle process, the architecture description is then transformed into a realimplementation of capabilities and assets in the field. The Framework itself does not address thisrepresentation-to-implementation transformation process but references policies that are relevantto that process.1 “An architecture is the fundamental organization of a system embodied in its components, their relationships toeach other, and to the environment, and the principles guiding its design and evolution.” [IEEE STD 1471, 2000]1-1
Page 2 and 3: SECTIONTABLE OF CONTENTSPAGE1 INTRO
Page 4 and 5: SECTIONTABLE OF CONTENTS (Cont)PAGE
Page 10 and 11: SECTIONANNEXTABLE OF CONTENTS (Cont
Page 12 and 13: FIGURELIST OF FIGURES (Cont)PAGE4-1
Page 14 and 15: FIGURELIST OF FIGURES (Cont)PAGE5-3
Page 18 and 19: Hereafter in this document, the ter
Page 20 and 21: architecture that should be capture
Page 22: 2.1.2 Definition of the Systems Vie
Page 25 and 26: The following legend is used in the
Page 27 and 28: 2.3 ARCHITECTURE DATA ELEMENTSAs st
Page 29 and 30: Within each perspective, all produc
Page 31: software systems, as well as for bu
Page 34 and 35: Figure 2-5. CADM Distinctions for A
Page 36 and 37: Tools and File Formats Used identif
Page 38 and 39: Data Elements Attributes Example V
Page 40 and 41: Data Elements Attributes Example V
Page 42 and 43: • TASK and ARCHITECTURE-TASK (whi
Page 44 and 45: 3.2.2 TaxonomiesAV-2 defines the ar
Page 46 and 47: TAXONOMY TYPES STRUCTURE AVOperatio
Page 48 and 49: Taxonomies relate two instances, of
Page 50 and 51: • INFORMATION-ELEMENT-DOCUMENT•
Page 52 and 53: geographical distribution of assets
Page 54 and 55: Data Elements Attributes Example Va
Page 56 and 57: Figure 4-3. CADM ER Diagram for Hig
Page 58 and 59: and their attributes (such as perio
Page 60 and 61: GenericSubscriber NodeRequiringServ
Page 62 and 63: Hierarchy ChartConnectorReferenced
Page 64 and 65: • Information content of IERs (or
Page 66 and 67:
4.3 OPERATIONAL INFORMATION EXCHANG
Page 68 and 69:
4.3.2 UML RepresentationThere is no
Page 70 and 71:
DataElementsInformationExchange has
Page 72 and 73:
• INFORMATION-EXCHANGE-REQUIREMEN
Page 74 and 75:
AGREEMENT IDENTIFIER in INFORMATION
Page 76 and 77:
Figure 4-10. CADM ER Diagram for Op
Page 78 and 79:
WorkingGroupTop-LevelOrganizationCo
Page 80 and 81:
4.4.4 CADM Support for Organization
Page 82 and 83:
OV-5 is a key product for describin
Page 84 and 85:
Flow 1$A1Activity 1Node ANode CFlow
Page 86 and 87:
ExternalSourceNode ANode BNode CNod
Page 88 and 89:
Data Elements Attributes Example Va
Page 90 and 91:
Page 92 and 93:
Page 94 and 95:
Threads of activities are specified
Page 96 and 97:
• Action Assertions: These rules
Page 98 and 99:
Table 4-6. Data Element Definitions
Page 100 and 101:
model element. Behavior is modeled
Page 102 and 103:
Processes receiving multiple inputs
Page 104 and 105:
Page 106 and 107:
of the activities, and includes the
Page 108 and 109:
Precedence linkindicatesorder betwe
Page 110 and 111:
Page 112 and 113:
4.7 LOGICAL DATA MODEL (OV-7)4.7.1
Page 114 and 115:
4.7.3 Logical Data Model (OV-7) - D
Page 116 and 117:
DATA-DOMAIN (all subtypes of INFORM
Page 118 and 119:
nodes. The term system in the frame
Page 120 and 121:
second, logically distinct interfac
Page 122 and 123:
Interface 1Node ASystem 1Node BSyst
Page 124 and 125:
Page 126 and 127:
• ORGANIZATION-TYPE-ESTABLISHMENT
Page 128 and 129:
5.2 SYSTEMS COMMUNICATIONS DESCRIPT
Page 130 and 131:
SV-2 intranodal perspective may be
Page 132 and 133:
Page 134 and 135:
• NETWORK-DETAIL• NETWORK-NODE
Page 136 and 137:
Figure 5-11. CADM ER Diagram for Sy
Page 138 and 139:
Page 140 and 141:
Page 142 and 143:
FUNCTION 1SUBFUNCTION11SUBFUNCTION1
Page 144 and 145:
The systems use cases and classes a
Page 146 and 147:
Page 148 and 149:
used to identify an external source
Page 150 and 151:
Page 152 and 153:
Operational ActivitiesSystem Functi
Page 154 and 155:
Page 156 and 157:
Page 158 and 159:
InterfaceIdentifierDataExchangeIden
Page 160 and 161:
Page 162 and 163:
Using these references, all the att
Page 164 and 165:
Page 166 and 167:
System NameHardware Element 1Mainta
Page 168 and 169:
Data Elements Attributes Example va
Page 170 and 171:
5.8 SYSTEMS EVOLUTION DESCRIPTION (
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
A template for SV-9 is shown in Tab
Page 178 and 179:
Page 180 and 181:
Page 182 and 183:
Page 184 and 185:
Because the structural assertion ru
Page 186 and 187:
Page 188 and 189:
terms of triggers or events (genera
Page 190 and 191:
Page 192 and 193:
Table 5-14. Data Element Definition
Page 194 and 195:
5.11 PHYSICAL SCHEMA (SV-11)5.11.1
Page 196 and 197:
Object classes defined here should
Page 198 and 199:
Figure 5-42. CADM ER Diagram for Ph
Page 200 and 201:
documents are used, then the relati
Page 202 and 203:
Table 6-2. TV-1 Template with Corre
Page 204 and 205:
Table 6-4. Data Element Definitions
Page 206 and 207:
Page 208 and 209:
Figure 6-3. INFORMATION-TECHNOLOGY-
Page 210 and 211:
Figure 6-5 provides a high-level di
Page 212 and 213:
6.2 TECHNICAL STANDARDS FORECAST (T
Page 214 and 215:
Page 216 and 217:
7 FRAMEWORK ARCHITECTURE DATA ELEME
Page 218 and 219:
• The Technical Standards Profile
Page 220 and 221:
• Events in the Operational State
Page 222 and 223:
• Rules in the Systems Rules Mode
Page 224 and 225:
7.6 SUMMARY OF ARCHITECTURE DATA EL
Page 226 and 227:
LINK TO… BY:SV-4 System data flow
Page 228 and 229:
ANNEX AGLOSSARYA&IA&TACCACLAFWGAMSA
Page 230 and 231:
FIPSFNAFOCFoSFPIFRPFSAGCCSGIGGUIHCI
Page 232 and 233:
OAOASDOIEMOMBOMGONCDOOOPLANOSDOVPMP
Page 234 and 235:
ANNEX BDICTIONARY OF TERMSThe terms
Page 236 and 237:
Initial CapabilitiesDocumentIntegra
Page 238 and 239:
SystemSystem Data ElementAny organi
Page 240 and 241:
AssociationAttributeBuildingBlocksC
Page 242 and 243:
NotesObjectObject DiagramOperations
Page 244 and 245:
Use Case Model A model that describ
Page 246 and 247:
COST-BASISCOUNTRYDATA-ITEM-TYPEDECI
Page 248 and 249:
NETWORK-TYPENODEMODELING-AND-SIMULA
Page 250 and 251:
INTERFACE-TYPETECHNICAL-SERVICETECH
Page 252 and 253:
[DEB, 2000][DeMarco, 1979][Departme
Page 254:
[OMG, 2000][OMG, 2001][Rumbaugh, 19
show all

DoD Architecture Framework Version 1.0, Volume 2 - AcqNotes.com

Create successful ePaper yourself

Delete template?

Save as template?