1 / 20

Overview

Overview. UCORE Conference 23 Sep 2009. DoDAF 2.0 Meta Model (DM2). Briefing Outline. DM2 Purposes What is DM2 Development and Maintenance Principles Foundation Ontology Pedigree DM2 Data Exchange Notional Use Cases. DoDAF 2 Goals. Support DoD’s core processes:

michaelbarber
Download Presentation

Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Overview UCORE Conference 23 Sep 2009 DoDAF 2.0 Meta Model (DM2)

  2. Briefing Outline • DM2 Purposes • What is DM2 • Development and Maintenance Principles • Foundation Ontology • Pedigree • DM2 Data Exchange Notional Use Cases

  3. DoDAF 2 Goals • Support DoD’s core processes: • Capabilities Integration and Development (JCIDS) • Planning, Programming, Budgeting, and Execution (PPBE) • Acquisition System (DAS) • Systems Engineering (SE) • Operations Planning • Capabilities Portfolio Management (CPM) • Establish guidance for architecture content as a function of purpose – “fit for purpose” • Increase utility and effectiveness of architectures via a rigorous data model – the DoDAF Meta Model (DM2) -- so the architectures can be integrated, analyzed, and evaluated to mathematical precision.

  4. DoDAF Meta Model (DM2) Purposes • The constrained vocabulary for description and discourse about DoDAF models (formerly “products”) and their usage in the 6 core processes • Specification for federated EA data exchange between: • architecture development and analysis tools • architecture databases • other authoritative data sources • Support discovery and understandability of EA data: • Discovery of EA data using DM2 categories of information • Understandability of EA data using DM2’s precise semantics augmented with linguistic traceability (aliases)

  5. What is the DM2 • The DM2 has three levels, . • A conceptual level or Conceptual Data Model (CDM) defines the high-level data constructs from which Architectural Descriptions are created in non-technical terms, so that executives and managers at all levels can understand the data basis of Architectural Description. • A Logical Data Model (LDM) adds technical information, such as attributes to the CDM and, when necessary, clarifies relationships into an unambiguous usage definition. • A Physical Exchange Specification (PES) consists of the LDM with general data types specified and implementation attributes (e.g., source, date) added, and then generated as a set of XSD’s, one schema per DoDAF-described Model.

  6. What is the DM2 • The DM2 consists of the following data items:

  7. DM2 LDM Data Groups • The DM2 LDM is presented in 12 semantically-related clusters or data groups • Activities • Performer • Resource Flows • Information and Data • Rules • Measures • Locations • Goals • Capability • Services • Project • Training/Skill/Education • For each group: • Diagram, Definitions, and Aliases • Notes • Method of collection and construction • Usage in Core Process

  8. DM2 Development and Maintenance Principles • Scope • Information Pedigree • Security classification marking • Term entry • Aggregation rule • Typed Relationships • Implementation neutrality • Definitions • Aliases • Extensions • Research and reference information • DM2 work share site • Configuration Management • Pilot and early adopter support

  9. Leveraged Ongoing IDEAS Foundation • IDEAS: • Mathematics • type (~set) theory • 4D mereotopology • Deals with issues of states, powertypes, measures, space -- what is truly knowable vs. what is assumed • Separates signs and representations from referents • DM2 domain concepts are extensions to the formal foundation • Rigorously worked-out common patterns are reused: • Super-subtype, whole-part, temporal whole-part, type-instance, before-after, overlap • Saved a lot of repetitive work – “ontologic free lunch” • Result is higher quality and consistency throughout http://en.wikipedia.org/wiki/IDEAS_Group • Three types of Things: • Individuals – Things with spatio-temporal extent (not people) • Types – similar to sets • Tuples – ordered relations between Things

  10. Benefits of adopting the IDEAS formal foundation and common patterns • Model compactness through inheritance of superclass properties and common patterns. • Agreed-upon analysis principles that provide a principled basis for issue analysis • Improved ability to integrate and analyze multiple heterogeneous EA datasets to fulfill EA purposes

  11. Why Formal Ontology? • Formalizes important properties of the real world being modeled • Categorization of things (type (~set) theory) • Things can be in many categories • Parts and wholes (mereology) • The parts don’t have to be contiguous, e.g., parts of a squadron • Temporal states (4D mereology) • The objects have a lifetime (temporal extent) that can be broken into temporal states • Overlaps, spatial relationships (mereotopology) • Sequences, before-after (4D mereotopology) • Establishes a criterion of identity -- If something has the same spatio-temporal extent as something else, they are the same • Enables mathematical analysis of EA datasets using well-established set theoretic, geometric, and topologic mathematic “laws” and theorems, e.g., • Commutivity and anti-commutivity, e.g., • Symmetry and anti-symetry • Reflexivity and irreflexivity • Associativity • Transitivity • Many others

  12. Information Pedigree – workflow model~ Open Provenance Model (provenance = linked together pedigrees) Information Production Activity Resources Used, e.g., other Information Who Rules followed in the production Measures in the production, e.g., QoS, uncertainties Where done

  13. Use Cases Identification / RequirementsWhy do I exchange EA data? • JCIDS • JCD / ICD / CPD / CDD / FNA / FSA / FNA / AoA / TDS Evaluator – overlap and best value comparison • ISP / TISP Evaluator – interoperability comparison • Tester – “derive” / trace TEMP to • Preparer -- reuse • DAS • Milestone Reviews • Gate reviews • Functional Control Boards (FCB) • PPBE • Investment Review Boards (IRB) • OMB 300 • Determine & defend FYDP • CPM / CPIC • Functional alignment of portfolio • PPBE support • Systems Engineering • Spec development • Ops Planning • Plans development • Interoperability Assurance

  14. Interrogatives Relationship to DM2 CDMUCORE 2.0 Who, What, When, Where WHEN WHY HOW WHAT WHO WHERE

  15. Questions?

  16. Backup

  17. Conceptual Data Model 1 2 3 4 5 6 7 8 9 10 11 12 13 14 20 16 17 18 19 21 22 15 26 23 27 25 24 28 29 31 30 (see “DM2 CDM Description document” for definitions) 23 (+ 24 &25) 20 (+ 21 & 22) 30 33 34 • Green lines are super-subtype. Read in direction of arrow, “is a type of” • Blue lines are associations. See notes for key descriptions and examples. Read key in direction of arrow. • Crows feet are associations between the association at the foot and the arrow, read according to the key. 32 36 Person Type 35 37

  18. DoDAF Domain Concepts are Specializations Thing • So they inherit associations (can occupy association place positions) Type Individual Individual Type (zoom-in to read or see handout)

  19. All Associations are Typed • So their mathematical meaning is formally modeled – a first in DoDAF meta models Before-after Description and naming Whole-part for Types Before-after for Types Overlap for Types Instance-of-type Instance-of-powertype (zoom-in to read or see handout)

  20. Naming and Description Pattern • Multiple names for same thing (aliases) – must tell Naming Scheme • Information (formerly Information Element) linked to the Things it describes

More Related