Lecture 4.4: DoDAF Overview (Vol. II, Chs 1 & 2)

1. Lecture 4.4: DoDAF Overview (Vol. II, Chs 1 & 2) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006

2. Agenda • Overview

3. DoDAF provides a “common approach for DoD architecture description development, presentation, and integration” Supports Requirements Development Complete Consistent Allocated to Components Supports Design Development Complete Consistent Meets Requirements Definitions Architecture refers to both: An architecture description An architecture implementation Architecture Description is “a representation of a defined domain … in terms of constituent parts, what those parts do, how the parts relate to each other and to the environment and the rules and constraints governing them” Architecture Implementation is “a real implementation of capabilities and assets in the field” Integrated Architecture is “an architecture description that ahs integrated OVs, SVs and TVs” Overview (1.1) and Purpose (1.2)

4. Architecture Views (2.1) • The Framework defines three views: • Operational View (OV): describes tasks, activities, operational elements, and information exchanges required to accomplish DoD Missions, i.e., “enterprise” mission aspects. • System View (SV): describes systems and interconnections providing for, or supporting, DoD functions. It associates systems resources to the OV. • Technical Standards View (TV): provides the technical systems implementation guidelines upon which engineering specifications are based, common building blocks are established, and product lines are developed, e.g., policies and technical standards. • “All View (AV)” products are those provide overarching information describing the architecture plans, scope, and definitions • Each View is composed of sets of architecture data elements that are depicted via graphic, tabular, and textual products. • The Core Architecture Data Model (CADM) defines the entities and relationships for architecture data. • DoDAF recognizes that the term “Architecture” is overloaded. As such, it divides the term into different views and products (for each view).

5. Architecture Products (2.2)

6. Architecture Products (2.2): All Views, Operational Views and Technical Views

7. Architecture Products (2.2): Systems Views

8. Architecture Data Elements (ADEs) are the underlying basic elements that comprise the architecture (examples will be provided later) These ADEs are captured in the a Architecture Data Model that is specific to each AV, OV, SV, or TV graphics (examples will be provided later) The All-DoD Core Architecture Data Model (CADM) specifies the ADE fields for each View Architecture Data Elements (2.3)

9. Architecture Product Development (2.4) • Supports both Structured Analysis (IDEF) and UML methodologies • Most products may be decomposed to multiple levels • Decomposition should be to the level required for the stated objective (user) • Products should be developed iteratively (per SE Process) • Templates should be developed

10. Entry Types: Operational Node (ON) Operational Element (OE) System (Sys) Subsystem Element (SE) Actor (Actor) External System (ES) External Subsystem Element (ESE) Function/Activity (Fnc) Rule Model (RM) State (State) Data Entity (DE) Data Attribute (DA) Reference ID: Function/Activity: A1.X.y System/Subsystem Element: C1.X.y External System/Subsystem Element: ESX.Y Rule Model: RM1.X.y Data Entity (DE): DEX.y Acronym Term Definitions Functions should indicate I/O Des and Rule Models System/Subsystem Elements should include alllocated Functions DEs should include list of DAs DAs should include data type, visibility, and ranges. RMs should include reference to functions and DEs Integrated Dictionary Legend

11. AV-2: Integrated Dictionary -WBRS Example

12. Conclusions • AV-1 and AV-2 are essential products for every architecture • AV-1 is usually developed in a Word document • Initially one may want to develop the AV-2 in Word or Excel until you figure out the desired format or until a CASE Architecture Tool is selected.