1 / 14

A Data Exchange Standard for the DoD EA COI

A Data Exchange Standard for the DoD EA COI. Dave McDaniel 28 March 2011. UPDM PES Issues and the DoDAF Configuration Management Process. The DoDAF development team and 400-member Working Group (including many non-UPDM vendors) is unaware of UPDM PES issues

jelton
Download Presentation

A Data Exchange Standard for the DoD EA COI

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. A Data Exchange Standard for the DoD EA COI Dave McDaniel 28 March 2011

  2. UPDM PES Issues and the DoDAF Configuration Management Process • The DoDAF development team and 400-member Working Group (including many non-UPDM vendors) is unaware of UPDM PES issues • There are only 6 PES Change Requests before the DoDAF-DM2 WG out of ~250 open CRs • None are high priority • None have been submitted by UPDM • The UPDM team has been a member of the WG for over two years • They can turn in CR’s via web or email • They have turned in many CR’s on the DoDAF and DM2 Logical Data Model (LDM) • ~75, of which ~50 were resolved in 2.01 and 2.02 • None have been submitted on PES • The UPDM team knows Greg Schaefer, that he is the development team’s PES expert, and that he was available to assist them with questions, samples, and even queries and code snippets • He has not been contacted once by the UPDM team on PES over the past ~ two years since he was made available • When the UPDM PES white paper is written and submitted, the established procedure will be to parse individual issues into the CR system for peer review and work by the WG and then Component review via the FAC • Why would UPDM be exempted from the usual peer and Component review? • Unfair to competitors • Unfair to WG experts • Unfair to Components • Violates FAC / ASRG rules • Why can’t UPDM play by same rules as everyone else?

  3. Lay of DoDAF Land • Model specifications (AV-1  SV-10c) • Intent was to specify using data dictionary terms • Unfortunately too much legacy committee language was preserved • Estimate 75% of the terminology is undefined and inconsistent • This ambiguous specification, accumulated since 1994, has led to the evolution of an EA community disconnected from DoD’s 6 core processes • DM2 • Conceptual Data Model is a one-slide ppt and a handful of definitions – very simple • Logical Data Model is in a UML tool but modified to be an IDEAS tool. • Because of IDEAS there are only ~250 total data elements compared to the less-expressive CADM that had ~16,000! • But IDEAS is hard to learn – it’s mathematical • Physical Exchange Specification is automatically generated from the LDM • It is just a slightly-dumbed-down LDM in XML so if you know the LDM, PES is simple • MITRE on the UPDM Team has been opposed to the idea of PES since it’s inception 3 years ago • The DM2 and the 52 DoDAF models are related via a matrix • 52 DoDAF models X 250 DM2 data elements

  4. PES sample (SAR example) <IdeasEnvelope OriginatingNationISO3166TwoLetterCode="String" ism:ownerProducer="NMTOKEN" ism:classification="U" xsi:noNamespaceSchemaLocation="DM2_PES_v2.01.XSD" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ism="urn:us:gov:ic:ism:v2" xmlns:ideas="http://www.ideasgroup.org/xsd" xmlns:dm2="http://www.ideasgroup.org/dm2"> <IdeasData XMLTagsBoundToNamingScheme="DM2Names" ontologyVersion="2.01" ontology="DM2"> <NamingScheme ideas:FoundationCategory="NamingScheme" id="ns1"> <ideas:Name namingScheme="n0" id="n0" exemplarText="DM2Names"/> </NamingScheme> <Activity ideas:FoundationCategory="IndividualType" id="a1"> <ideas:Name exemplarText="Search" namingScheme="ns1" id="n1"/> </Activity> <Activity ideas:FoundationCategory="IndividualType" id="a4"> <ideas:Name exemplarText="Receive Distress Signal" namingScheme="ns1" id="n11"/> </Activity> <Activity ideas:FoundationCategory="IndividualType" id="a10"> <ideas:Name exemplarText="Control SAR Assets" namingScheme="ns1" id="n2"/> </Activity> <Activity ideas:FoundationCategory="IndividualType" id="a5"> <ideas:Name exemplarText="Send Warning Order" namingScheme="ns1" id="n12"/> </Activity> <Activity ideas:FoundationCategory="IndividualType" id="a11"> <ideas:Name exemplarText="Provide Safety" namingScheme="ns1" id="n3"/> </Activity> <Activity ideas:FoundationCategory="IndividualType" id="a12"> <ideas:Name exemplarText="Perform Tactical C2" namingScheme="ns1" id="n4"/> </Activity> <Activity ideas:FoundationCategory="IndividualType" id="a13"> <ideas:Name exemplarText="Be Distressed" namingScheme="ns1" id="n5"/> There are many samples on the DoDAF Journal site. GFE software on the WG site can generate PES easily.

  5. PES StructureMade for future interoperability with IDEAS-based data • E.g., overall classification marking • Extra goodies for Dublin Core • Actual architecture data – tag names and definitions are exactly from DM2 LDM • Where you say what views the data corresponds to • One PES file can have multiple view • A single piece of data can be in multiple views We suspect this is a part UPDM has issues with but the PES merely encodes the “monster matrix” which is actually part of the data dictionary and the DoDAF model specifications, i.e., it exists even if the PES didn’t to relate the DM2 to the DoDAF models. BTW, this matrix is the only hope for fixing the massive model specification problems which we estimate at 75% inconsistent and undefined terms.

  6. Why would a DoD architect exchange data? • Across • For reuse • Might be convenient but often more trouble than it’s worth • Downward • To bootstrap a refinement • Might be convenient • Upward • To integrate and analyze • Otherwise it’s “wet” information fusion and ad-hoc analysis Most DoD architecture “exchanges” today are pdf, ppt, doc, xls, html, SA encyclopedias, …

  7. XMI • Very complicated – has taken years for a very limited set of like-functioned CASE tools to exchange • The UML meta model carries a lot of early Object Oriented programming baggage and was designed by committee. • Consequently, it is badly suited to EA. • This was the biggest problem in using UML in M3. • Specific to UML software engineering tools – 5 out of 50 identified by the A&I team – only 10% • We have not yet found any DoDAF XMI files in DARS or NARS • Sweden estimated UML tools used for less than 1% of their EA’s • Most architecture tools we have identified are not UML • There will probably never be a business case for them to implement XMI, esp. given how costly it has been for the tools in the CASE market • There are other modeling language standards, e.g., BPMN, Archimate • In many cases it is not even possible because they are not software engineering tools • OMG represents a sliver of the tools and standards relevant to architectures • An IEEE, INCOSE, or ISO standard would be broader

  8. XMI sample (same SAR example) <XMI xmi.version="1.1" xmlns:UML="omg.org/UML1.3" timestamp="2011-03-26 11:55:12"> <XMI.header> <XMI.documentation> <XMI.exporter>Enterprise Architect</XMI.exporter> <XMI.exporterVersion>2.5</XMI.exporterVersion> </XMI.documentation> </XMI.header> <XMI.content> <UML:Model name="EA Model" xmi.id="MX_EAID_9A8A193B_EA6A_42ce_8614_67A3A970F86A"> <UML:Namespace.ownedElement> <UML:Class name="EARootClass" xmi.id="EAID_11111111_5487_4080_A7F4_41526CB0AA00" isRoot="true" isLeaf="false" isAbstract="false"/> <UML:Package name="OV-2" xmi.id="EAPK_9A8A193B_EA6A_42ce_8614_67A3A970F86A" isRoot="false" isLeaf="false" isAbstract="false" visibility="public"> <UML:ModelElement.taggedValue> <UML:TaggedValue tag="parent" value="EAPK_AAF0CA9A_2B4C_4bbf_9AAF_2FA2B592A6E5"/> <UML:TaggedValue tag="ea_package_id" value="2"/> <UML:TaggedValue tag="created" value="2009-08-03 00:00:00"/> <UML:TaggedValue tag="modified" value="2009-08-03 00:00:00"/> <UML:TaggedValue tag="iscontrolled" value="FALSE"/> <UML:TaggedValue tag="lastloaddate" value="2011-03-26 10:44:34"/> <UML:TaggedValue tag="lastsavedate" value="2011-03-26 10:44:34"/> <UML:TaggedValue tag="version" value="1.0"/> <UML:TaggedValue tag="isprotected" value="FALSE"/> <UML:TaggedValue tag="usedtd" value="FALSE"/> <UML:TaggedValue tag="logxml" value="FALSE"/> <UML:TaggedValue tag="tpos" value="0"/> <UML:TaggedValue tag="packageFlags" value="CRC=0;"/> <UML:TaggedValue tag="batchsave" value="0"/> <UML:TaggedValue tag="batchload" value="0"/> <UML:TaggedValue tag="phase" value="1.0"/> <UML:TaggedValue tag="status" value="Proposed"/> <UML:TaggedValue tag="complexity" value="1"/> <UML:TaggedValue tag="ea_stype" value="Public"/> <UML:TaggedValue tag="tpos" value="0"/> <UML:TaggedValue tag="gentype" value="Java"/> </UML:ModelElement.taggedValue> <UML:Namespace.ownedElement> <UML:Class name="SAR Asset Controller" xmi.id="EAID_0B0EFC89_5DC0_4706_88CD_627B34E96CEA" visibility="public" namespace="EAPK_9A8A193B_EA6A_42ce_8614_67A3A970F86A" isRoot="false" isLeaf="false" isAbstract="false" isActive="false"> <UML:ModelElement.stereotype> <UML:Stereotype name="Node"/> </UML:ModelElement.stereotype>

  9. Levels Conceptually conformant Uses DoDAF terms and aliases (from DM2 CDM) to categorize its concepts DoDAF views (AV-1 thru DIV-3) have correct information according to “monster matrix”).  Logically conformant Level 1 + adheres to terms and relationships from DM2 LDM and aliases Physically conformant Level 2 + expressed as DoDAF – DM2 PES that can be consumed by others Semantically conformant Level 3 + IDEAS semantics are correct Confirmation method Inspection Inspection Test of XML files against standard schema validator TBD, but would mostly likely be a test of the OWL/RDFS files DoDAF-DM2 Conformance(proposed to FAC as change for v2.03)

  10. COTS Architecture ToolsVendor’s Day 14 March 2011 + Follow-up (page 1 of 2)

  11. COTS Architecture ToolsVendor’s Day 14 March 2011 + Follow-up (page 2 of 2) We have just started looking into relevant Govt-developed tools and ADS

  12. Conclusion • PES is not a CADM-type problem • PES is just a way to exchange DM2 data via XML • DM2 is the only solid part of DoDAF 2.0 • The DoDAF model descriptions have massive quality problems which will be a drag on any framework consolidation efforts -- Federal, Coalition, NATO, … • Using DM2 is the only hope of fixing these problems. • DM2 CDM is being used by IC • DM2 OWL is being used by Business Mission Area • DM2 PES has been developed and exchanged in a few pilots and examples, e.g., JACAE, CADIE, MCAE, NARS • There is currently no broad-based commercial standard for architecture data exchange • XMI is not it • Most (90%) tools cannot support • Recommend proposing to vendor’s list and at vendor’s day to get non-UML tool reactions to being told they must implement XMI to sell to DoD • Most ADS would not be able to import or export XMI • If a single commercial standard is desired, a broader base is needed, e.g., IEEE, INCOSE, ISO, IDEAS, and NATO

  13. XMI Pro’s Commercial UPDM tools (Atego, MagicDraw, Sparx, Rhapsody?) implement The standard for leading CASE tools Con’s 90% of architecting tools won’t or can’t implement OMG controlled; those 90% aren’t and won’t be OMG Could be considered a pre-selection of vendors without proper source selection The “commercial” is too small a segment Won’t interface to GOTS tools and ADS’ Was originally designed as a CASE tool, not a tool to support the 6 core processes Very few people use UML for EA so all the UML metamodel baggage is pointless. Uncertain if can ever match DM2 semantics precisely, esp WRT IDEAS and CUDEAM UML semantics are a constraint An illogical MDR namespace wherein the CDM and LDM are DM2 and the physical is XMI PES Pro’s Matches DM2 LDM and OWL exactly IDEAS methodology can be used to resolve differences mathematically A DM2 database can import and export easily DM2  IDEAS  MODEM and CUDEAM interoperable Was designed specifically to support the 6 core processes Any tool or database can implement once they relate to DM2 Not specific to a set of vendors so fair and open competition Planned for implementation by a broad set of tools Con’s Government developed Resources to maintain are limited It is taking a while to implement But so is DoDAF 2 overall – still not in any approved governance If you must have an EA COI data exchange standard

  14. Recommendations • Continue work with IDEAS Group and NATO to develop CUDEAM with goal to move into a broad-based standards body, e.g., ISO • At the DoD level, use the 400+ DoDAF WG members – includes all vendors and UPDM team • Moving to international, remember AP-233 and Eurostep • IDEAS methodology will help • Support of all vendors • Do not mandate a small segment standard • Define a Level 3.5 conformance: PES generation only • Remind vendors Level 2 may be sufficient in some cases • Encourage use of XMI, BPMN, Archimate, etc. for specialized exchange between appropriate tools • DoDAF WG peer review the UPDM PES white paper when it becomes available

More Related