1. VERSION 15 DARS User’s Group / DoDAF Vendor’s Day 11 February 2009
6/1/ :37
DoDAF 2.0 Meta Model (DM2)
Overview
DARS User’s Group / DoDAF Vendor’s Day
11 February 2009

2. Briefing Outline DoDAF 2 Objectives and Method DM2 as a part of DoDAF
Top-Level Executive Overview Diagram
DM2 Development and Life-Cycle Methodology
Data Groups Overviews

3. DoDAF 2 Goals Support the department’s 6 core processes:
Capabilities Integration and Development (JCIDS)
Acquisition System (DAS)
Budgeting and Planning (PPBE)
Systems Engineering
Operations Planning
Capabilities Portfolio Management (CPM)
Establish guidance for architecture content as a function of purpose – “fit for purpose” (see cover logo)
Increase precision of architectures by defining architectures principally in terms of data with diagrams (presentations) related to the data – the DoDAF Meta Model (DM2)

4. DoDAF 2 Development Method
Requirements collection workshops for the 6 core processes
Three technical working groups:
Data – requirements driven, leveraging IDEAS, UPDM, others
Methods – descriptive, not prescriptive
Presentation – guidance on presentation types
Internal Development Team
Core Management Group with lead representatives from each service and agency

5. DoDAF Meta Model (DM2) Purposes:
The vocabulary for description and discourse about DoDAF models (formerly “products”) and core process usage
The basis for generation of the “physical” exchange specification for exchange of data between architecture tools and databases.
Supports discovery and understandability of architecture datasets:
Discovery thru abstraction levels and super-subtype taxonomies
Understandability thru precise semantics augmented with linguistic traceability
Form:
VOLUME I, DoDAF Conceptual Data Model (CDM)
Core concepts, definitions (with examples, sources, aliases)
Relationships (with some typing)
VOLUME II, DoDAF Logical Data Model (LDM)
The DoDAF Logical Data Model (LDM) is the Conceptual Data Model described in Volume I with attributes, specializations, and association reifications (made explicit) added
VOLUME III, DoDAF Physical Exchange Specification (PES)
The Logical Data Model generated as a set of XSD’s, one schema per model (product) described in Volume II.

6. Volume II Organization
Vol II
Perspectives
Metamodel Data Groups
Views
 Metamodel Data Groups
Performer
Resource Flow
Information & Data
Activity
Training / Skill / Education
Capability
Services
Project
Goals
Rules
Measures
Location
x.y.1 Data – what are the concepts and how are they related
Diagram and definitions from DM2
Discussion
x.y.2 Method – how is such information collected and assembled
x.y.3 Usage in Core Processes – how is such information used in budgeting, acquisition, capabilities integration and development, systems engineering, capabilities portfolio management, and operations planning
x.y.4 Presentation – what are the ways this information can be presented
for each:

7. Top-Level Overviews

8. Single-slide overview
PRE-DECISIONAL WORKING DRAFT
Visions
Objectives
Effects
Goals
Goals
Visions
Objectives
Effects
Rules
Rules
Measures
Measures
Capabilities
Capabilities
Activities
Metrics
Effects
Conditions
Activities
Metrics
Effects
Conditions
Guidance
Agreements
Constraints
Standards
IA/Security
Guidance
Agreements
Constraints
Standards
IA/Security
Performance
Needs Satisfaction
Organizational
Maintainability
Adaptability
Performance
Needs Satisfaction
Organizational
Maintainability
Adaptability
Services
Services
Projects
Descriptions
Ports & Channels
Service Functions
QoS Metrics
Service Policies
Service Contracts
Activities
Resources
Cost / Schedule / Metrics
Organizations / Performers
Descriptions
Ports & Channels
Service Functions
QoS Metrics
Service Policies
Service Contracts
Training / Skills / Education
Realization - implementation
Performers
Performers
Flows
Personnel
Materiel
Personnel
Materiel
Information & Data
Materiel
Performers
Temporal
Service
System
Organization
Service
System
Organization
Environmental
Socio-political
Military
Environmental
Socio-political
Military
Conditions
Conditions
Activities
Activities
Functions
Processes
Tasks
Functions
Processes
Tasks
Locations
Locations
Points / Areas / Volumes
Regions
Real Property
Facilities
Addresses
Points / Areas / Volumes
Regions
Real Property
Facilities
Addresses
Ontologic Foundation (IDEAS)
Ontologic Foundation (IDEAS)
Parts, types, temporal parts, states, overlaps
Parts, types, temporal parts, states, overlaps
PRE-DECISIONAL WORKING DRAFT

9. Modeling Methodology

10. Top-Down / Bottom-Up Development
DoDAF 2.0:
Conceptual Data Model (Vol I)
Logical Data Model (Vol II)
Physical Exchange Model (Vol III)
Existing / Emerging Schema, Models, and Databases
Data Model Development
COI1
COIn
COI Coordination
PPBE Process Information Requirements
JCIDS Process Information Requirements
Ops Planning Process Information Requirements
SE Process Information Requirements
DoD Core Process Information Requirements Collection
UCORE
DAS Process Information Requirements
CPfm Process Information Requirements

11. Sources Models CADM 1.5 IDEAS UPDM BMM Hay/Zachman ASM CRIS
Conceptual CADM in DoDAF 1.0 / prototype CADM 2.0 M3
NAF Meta Model
DoI Meta Model
JC3IEDM
GML
UCORE 1.1
GEIA 927
AP233
SUMO and ISO (via IDEAS)
FEA Reference Models
JFCOM JACAE
Definitions
IEEE
ISO
W3C
OMG
EIA
DODD & DODI
JCS Pubs, especially CJCSI's
Models in the Source_Candidates_ ppt
DoDAF
Other frameworks: Zachman, MODAF, TOGAF, NAF, ...
FEA
BMM
Wordnet
Wikipedia
English dictionaries
DoDAF Glossary
On the left are the model sources we considered to date; on the right, additional sources for definitions.
Note that as a result of the Ops Planning workshop at JFCOM last week, we now can add JACAE as source. That metadata is being parsed into the spreadsheet this week.
Note also, that we considered sereral non-AF sources, e.g., JCS Pub 1-02, the DoD Dictionary of Military Terms, and English dictionaries.

12. Team and Weekly Sessions
Collaboration Site:
pre- & post- meeting updates
UML file
Excel file (defs and AI’s)
HTML version of UML file
Reference and Research folders updated as material is submitted

13. Modeling Principles
Model Core Process (PPBE, DAS, JCIDS, CPM, SE, Ops) business objects
Terms enter model through thorough semantic research:
Assignment to a researcher
Collection of authoritative definitions, documenting source
Assessment of redundant (alias) or composite terms
Formulation / selection of definition based on authoritative definitions
Examples
Outbrief to team
Recording of research and decision rationale
No need to distinguish / label concepts that differ only in level of aggregation – e.g., subfunction – function. Whole-part relationship covers the need without different names for different types of wholes and parts. When a user has need to label, the naming pattern accommodates.
Typed Relationships, e.g., using IDEAS
No commitment to an implementation type. Support RDBMS, XSD, Java, etc. from core model
Goal is a core that can be extended by user communities, not to try to cover all user detail. Extenders should be careful to not create redundant representations.
Model will enter a CM process

14. Definitions and Aliases Record Excerpt
PRE-DECISIONAL WORKING DRAFT
Definitions and Aliases Record Excerpt
PRE-DECISIONAL WORKING DRAFT

15. Definitions and Aliases Record Excerpt
PRE-DECISIONAL WORKING DRAFT
Definitions and Aliases Record Excerpt
PRE-DECISIONAL WORKING DRAFT

16. Coordination with many related activities
Examples:
OMG UPDM & SYSML teams
DM2 Coordination with teams in mutual telecons, OMG meetings, …
BTA Primitives and Lexicon
Core Enterprise Services – to – Tactical Edge (CES2TE)
ASN RDA and JFCOM Modeling and Simulation
JTEM
DoD MDWG
SPAWAR / ASN RDA Naval Architecture Elements Requirements Group (NAERG)
JFCOM JACAE
MODAF and NAF (via IDEAS)
DoDAF Plenary, Vendor’s Days, and weekly data model telecons
UPDM “architect” access to DM2 workgroup site with weekly updates
Comment acceptance into working group system
UPDM Team Coordination with DoDAF
UPDM weekly telecons, OMG technical meetings, and UPDM “face-to-face” meetings
Regular distribution of UPDM “Domain Meta Model”
Their DoDAF baseline is 1.5 but they want the “heads-up” on 2.0 to better support the UPDM mod for DoDAF 2 when it is finalized

17. Model Overview

18. Leveraged IDEAS for Formal Foundation
IDEAS is more than OWL:
Based on mathematics
set & 4D meronymy theory
Deals with issues of states, powertypes, measures, space -- what is truly knowable vs. what is assumed
Domain concepts are extensions to the formal foundation
Rigorously worked-out common patterns are reused
Saved a lot of repetitive work – “ontologic free lunch”
Result is higher quality and consistency throughout

19. BORO book is downloadable from DM2 site

20. Why Formal Ontology? Corresponds to the real world being modeled:
Physical objects that have parts, can be aggregated into larger wholes – both spatially and temporally
The parts don’t have to be contiguous, e.g., parts of a squadron
The objects have a lifetime (temporal extent) that can be broken into temporal states
Only one object can occupy the same spatio-temporal extent
Examples:
Things are categorized
Multiply
Categorization should follow the rules to set theory, e.g.,

21. Why Formal Ontology (cont’d)
Why is this better? “is-a” example:
Not mathematically rigorous:
More precise:
“Has” – the basis of fields and attributes is flawed too
Does this really matter – all the time – fouls queries, analysis algorithms, and interoperability
Why did this happen? Database design had in origins in form automation, not mathematical analysis – good for storing stuff to be processed by humans – terrible for automated processing as in data fusion

22. Diagram Conventions and Use of UML
The IDEAS Model has been developed using a UML Profile. The IDEAS Foundation specifies the fundamental types that define the profile stereotypes. The following stereotyped classes, with their colour-coding are used in the model:
<<Individual>> An instance of an Individual - something with spatio-temporal extent [Black]
<<Type>> The specification of a Type [Cyan]
<<IndividualType>> The specification of a Type whose members are Individuals [Orange]
<<TupleType>> The specification of a Type whose members are tuples [Green]
<<Name>> The specification of a name, with the examplar text provided as a tagged value [Light Yellow]
<<NameType>> The specification of a Type whose members are names [Dark Yellow]
The following stereotyped relationships are used in the model:
<<typeInstance>> a relationship between a type and one of its instances (UML:Dependency) [Red]
<<powertypeInstance>> a relationship between a type and its powerset (UML:Dependency) [Dark Red]
<<nameTypeInstance>> a relationship between a name and its NameType (UML:Dependency) [Red]
<<superSubtype>> a relationship between a type and one of its subtypes (UML:Generalisation) [Blue]
<<wholePart>> a relationship between an individual and one of its parts (UML:Aggregation) [Dark Green]
<<tuple>>/<<couple> a relationship between a things (UML:n-ary relationship diamond) [White]

23. Super/Sub Type, e.g.,
F-15 is type of Fighter
Whole Part, e.g.,
AEGIS radar is part-of the AEGIS ship
Overlaps, particularly Interface Type, e.g.,
Asset data collection activities produce data for audit reporting
Before-After, e.g.,
The collection task takes place before the posting and exploitation tasks

24. DoDAF Domain Concepts are Specializations
Next slide is a zoom-in

25. Sample zoom-in

26. There are some common attributes too
Everything has a classification marking – a “portion mark”
Everything has a pedigree – who, how,… it came into being
Names (formal, nick, acronym, ID / UID / GUID, etc.) done via naming pattern (an association). Very flexible allowing multiple names, typed by NameType.
Descriptions too.
Time periods via Measure model.

27. Naming and Description Pattern
For example, NameType = Mil-Std 6016, Mil-Std 2525, Nickname, GUID, …
For example, InformationType = “to-be architecture description”, “as-is architecture description”

28. Capability Oriented towards Desired Effects (measurable)
Manifested by Performers (including Performer configurations – remember whole-part)
Activities, Rules, Conditions, …

29. Activity

30. Performer
System – defined generally (i.e., not just a DoD Program of Record)
Can include humans
Animals too
At a location
Tied to Measures

31. Resource Flow Not just information and data (e.g., IER and SV-6)
Materiel, Personnel Type (training, the “T” and “L &e” in DOTMLPF), other Performers (e.g., in the Project views)
The Activity does the production and consumption, not the Performer, even if you choose not to show the Activities on a diagram
Measures and Rules apply throughout

32. Goals

33. Rules

34. Measure All kinds of measures and metrics
The measure values are related to measure types, e.g., BAUD, max speed, probability of kill, accuracy, …
Those measure types have rules associated with them, e..g, the rule that Target Location Error is a 90% probability area

35. Location Not trying to re-create GML
Addresses are ways to get to physical locations, e.g., a URL gets you to a server, a postal address gets you to a mailbox
There NameTypes for Address names, e.g., “postal”, “URL”, “TADIL link address”, etc.

36. Activity Model in this Conceptualization
Measures and metrics
Performer A
Performer B
Activity 1A
Activity 1B
Resources
a, b, c
Resources
x, y, z
Activity 11A
Activity 11B
Performers to which applicable
Conditions in which applicable
Rules, constraints, standards, …

37. IER “Matrix” in this Conceptualization

38. Information and Data
Information describes something; things can have multiple descriptions, e.g., by different sources, by different times, by different levels of detail
No intent to replicate a full metamodel – that would be in the DoD Metadata Registry
This is for support of the 6 core processes

39. Services Not just software, also business
OASIS definition adopted by DoD
Services are self describing
Service users interact with the accessed Performers via the Service Port
Rules (service policies, contracts)
Measures (QoS)

40. Project Presentation TWG recommended – based on NAF
Can be any kind of project, not just acquisition
Can be used as architecture metadata to describe the architecture project, i.e., structured AV-1

41. Information Pedigree
Requirement in the DoD Net-Centric Data Strategy (NCDS)
Similar to Open Provenance Model
Describes the workflow that led to the production of the information
Pedigree is the immediate link – provenance further back in the production chain
Activities, Performers, Performer states, resources used, rules abided by, measures conformed to

42. Physical Exchange Specification
XSD’s
One per DoDAF model (51) with necessary and optional parts
1 comprehensive with all optional for “fit for purpose” models
2 reference – Foundation and Security
Basic structure:
ArchitectureDescriptions
Manifest
Models

43. Mapping of Models Basis for XSDs
PRE-DECISIONAL WORKING DRAFT
Mapping of Models Basis for XSDs
In DoDAF Vol II
PRE-DECISIONAL WORKING DRAFT

44. DM2 Provides a Neutral Exchange Specification for Many Kinds of Architecture Data
XMI / MOF Conversant (e.g., UPDM / SysML)
Analysis Software
DM2 PES
XSD
neutral
implementation
EA / ITA Tools
Authoritative Data
Sources
EA Domain Concepts
Common
Patterns
4D Mereology
Set Theory
Naming
Pedigree
M&S
Tools EA
DBMS’
Ontic Foundation
Reporting Tools and Formats
Federal, Coalition, and other EA exchanges

45. Questions?

46. Training / Skill / Education

47. Security
This is the Intel Community Information Security Markings (IC-ISM, pronounced icky-sim.) We lifted from UCORE 1.1.

48. XSD’s are generated from UML model