1. Overview DoDAF 2.0 Meta Model (DM2)
VERSION 15
9/6/ :37
DoDAF 2.0 Meta Model (DM2)
Overview
Briefing to the Software Engineering Institute (SEI) Army Strategic Software Improvement Program (ASSIP) Action Group (AAG)
18 Nov 2009
Mr. David McDaniel
Enterprise Architecture & Standards
Office of the DoD Deputy Chief Information Officer

2. Briefing Outline DM2 Purposes DM2 Modeling Conventions
Foundation Ontology
Partial walkthrough of a sample of DM2 LDM data groups
Thoughts as to how this could aid software intensive PEO’s

3. Map of DM2 Description Documents and Briefings
Today, you are getting bits of several

4. The Purpose of DoDAF: 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)

5. What is the DM2
Architectural descriptions are models of aspect(s) of the enterprise
Common model types are described in DoDAF: AV-1 through DIV-3
Other models are called “fit-for-purpose”
The DM2 is a model of those models, hence “meta”
The DM2 has several levels, each of which is important to a particular viewer of Departmental processes.

6. DoDAF Meta Model (DM2) Purposes
Establish the constrained vocabulary for description and discourse about DoDAF models and their usage in DoD’s six core processes
Specify a way for federated EA data exchange between:
architecture development and analysis tools
architecture databases
other EA-relevant ADS’
Support discovery and understandability of EA data:
Discovery using DM2 categories of information
Understandability via DM2’s precise semantics augmented with linguistics (defs and aliases)
Increase the utility and effectiveness of architectural descriptions via a mathematical data model so they can be:
Integrated and cross-walked
Analyzed, evaluated, and assessed quantitatively

7. DM2 LDM Conventions
A&D 7

8. DM2 Development and Maintenance Business Rules
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 IDEAS Foundation (International Defence Enterprise Architecture Specification)
Developed by an international group of computer scientists, engineers, mathematicians, and philosophers under defense sponsorship
None of these foundation properties are unusual; they are all used in reasoning everyday:

10. Basic Concepts: three types of Things
Individuals, Things that exist in 3D space and time, i.e., have 4D spatial-temporal extent.
Types, similar to sets of Things.
Tuples, ordered relations between Things, e.g., ordered pairs in 2D analytic geometry, rows in relational database tables, and subject-verb-object triples in Resource Description Framework.
Individuals, things that exist in 3D space and time, i.e., have spatial-temporal extent.
Types, sets of things.
Tuples, ordered relations between things, e.g., ordered pairs in 2D analytic geometry, rows in relational database tables, and subject-verb-object triples in Resource Description Framework.

11. Basic Concepts: relationship types formalize important properties of the real world being modeled
Set theoretic:
Super-subtype (categorization of Things); e.g., a type of system or service, capability, materiel, organization, or condition.
Type-instance, similar to “element of” in set theory
Spatio-temporal parts and wholes (4D mereology):
Whole-part; e.g., components of a service or system, parts of the data, materiel parts, subdivisions of an activity, and elements of a measure.
Temporal whole-part (temporal states); e.g., the states or phases of a performer, the increments of a capability or projects, the sequence of a process (activity).
Spatio-temporal boundaries and overlaps (4D mereotopology:
Overlap
Before-after (sequences)
Things can be in many categories
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

12. The IDEAS Foundation is:
Formal, higher-order, 4D, based on four dimensionalism
Extensional (see Extension [metaphysics])
Using physical existence as its criterion for identity
Deals with issues of states, powertypes, measures, space -- what is truly knowable vs. what is assumed
signs and representations are separated from referents
The advantage of this methodology is that names are separated from things and so there is no possibility of confusion about what is being discussed.
Well suited to managing change-over time
Identifies elements with a degree of precision that is not possible using names alone
Comparing two Individuals, if they occupy precisely the same space at the same time, they are the same.
For two Types to be the same, they must have the same members
If those members are Individuals, their physical extents can be compared.
If the members are Types, then the analysis continues until Individuals are reached, then they can be compared.

13. DoDAF Domain Concepts are Specializations
Thing
Type
Individual
Individual Type
A&D
So you take all the DM2 domain concepts and classify them into the IDEAS foundation classes.
So they inherit associations (can occupy association place positions)

14. All Associations are Typed
Before-after
Whole-part for Types
Overlap for Types
Before-after for Types
Description and naming
Instance-of-type
Instance-of-powertype
A&D
Similarly, we type the associations by classifying them under their IDEAS foundation class.
So their mathematical meaning is formally modeled

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

16. Benefits of adopting the IDEAS formal foundation and common patterns
Model compactness through inheritance of superclass properties and rigorously worked-out common patterns.
Saved a lot of repetitive work – “ontologic free lunch”
Economizes implementations
Concentration of effort on a few common patterns results in higher quality and consistency throughout
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
Depends on near-universal mathematics and science that all learn very similarly
As we started figuring out relationships, we realized we were doing the same relationships over and over again. Decided to look into leveraging work we had been doing for several years with the international community on a formal .ontology. IDEAS foundation concepts are inherited into all the DM2 concepts. Saved us a lot of work – ontologic free lunch -- and part of the reason why the model is so small to this day –
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
Then domain concepts inherit several important properties.

17. Formal Ontology Mathematics
Set theory
4-D (xyzt) mereology (and mereotopology)
Whole-part
Spatial
Temporal
Before-after
Overlap
Predicate Calculus
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
These types of logics, calculii, theorems, etc. can be applied against datasets founded on formal ontologies such as the IDEAS Foundation
Making a distinction between things and the ways in which they are represented (e.g. their names, identifiers, etc.). This may seem like an obvious distinction, but most software systems do not do this - i.e. they conflate the object and its name.
By separating representation from extent, this allows any given Thing to have more than one representation. For example, the set of all tables might be called "Table" and also called "Tisch". A given car could be identified both by its VIN number and its manufacturer serial number (note that the vehicle registration number only identifies a state of the vehicle from when it is manufactured to when it is unregistered).
This allows great precision about the extent of things whilst still allowing a great deal of flexibility in representation.
Set theory – categories of things
Meronymy – spatial relationships between things
Tuples – ordered relationships between things
Logic – deductive, monotonic, non-monotonic, …
Inference – probabilistic, evidential, …
Lexical semantics, mathematical linguistics, …
Mereology a collection of axiomatic first-order theories dealing with parts and their respective wholes. In contrast to set theory, which takes the set–member relationship as fundamental, the core notion of mereology is the part–whole relationship. Mereology is both an application of predicate logic and a branch of formal ontology.
Like all complex systems, made up of many pieces
The pieces interact through data
Originally, piece makers (engineers, programmers) worked pair-wise (e.g., at design meetings, telephone, test sites) to figure out the interaction – involved much human interaction
With network “bus” architectures, easier to make interaction possible because the data is available
But understandable only by much human interaction1
The number of pieces continues to grow2
The number that need to interact continues to grow3
The scope of data they would like to use continues to grow4
XML provides documentation with the data, but humans still have to read and understand it.
e.g., Smart Ship, Integrated Bridge System, BMD
Continuing C4I – Combat System integration, Joint systems, OA and CANES SoA componentization
e.g., reference data such as ECDIS-N charts and GCCS-I3 use in Combat System
Provides for Relationships that aid Higher Level Command and Control Fusion Functions (ID, activity, intent, mission-related groups, etc.) with ISR context information
Uses taxonomies to allow detailed but interoperable extensions for sub-domains
Taxonomies again, to allow detailed but interoperable extensions
Allows aggregation of any object sets
Supports multiple hypotheses about any particular belief
Can represent uncertainty for ANYTHING – hostiles, neutrals, and even friendlies.
Parametrically (e.g., kinematic covariance matrices) and some discretely (e.g., ID “confusion matrices”)
Multiple hypotheses about any particular belief
Represents “pedigree” – what was used and how in coming up with some belief, including Context in which the belief was formulated (environmental and mission)-Beyond “Track History and Special Indicators”
Models true meaning (e.g., not just “indicators”), cause-effects (e.g., observation / measurement caused-by some object)

18. Why math? a spectrum of information sharing
Human-interpretable only
Human-interpretable but with a predictable organized arrangement
Applicable mathematics:
Set or type theory
Mereology
Mereotopology
4 dimensionalism
Predicate calculus
Logics: modal, Kripke, …
Rules, operators:
Commutative, reflexive, transitive, …
Member-of, subset-of, part-of, …
Databases are semantically weaker than commonly understood, e.g., the fundamental concepts of Entity-Relationship and Class Models:
Let's start generally:  "unstructured data", e.g., free text, might be considered one end of spectrum and math (numeric or symbolic) another.
But even so-called unstructured free text can have structure, e.g., the OMG RFP template. 
Why do we do semi-structured text?  There's a step to understanding what we’re doing. 
Why do we do databases?  There's another step.
The shortcoming of databases is that they usually have little more semantic structure than structured text -- named records (or tables or classes if you wish) that are some sort of container for named fields (or attributes or columns).  Via associations and relationships, containers can point to information in other containers.  Because of the labeling, you can tie the information together and query them.  A SQL query is just fundamentally a selection of the information.  I don't think there's much going on besides that.  As for referential integrity, data validation, cardinality rules, etc., it's handy to go back to the semi-structured analogy and see that they just tell you what parts of the form or template have to be filled in, with what choices, what the rules are for cross-references, etc.
Normally little more semantic structure than structured text
Named records (or tables or classes) that are some sort of container for named fields (or attributes or columns). 
Associations and relationships, containers can point to information in other containers
Because of the labeling, you can tie the information together and query them.  A SQL query is just fundamentally a selection of the information. 
Referential integrity, data validation, cardinality rules, etc.
Built-in’s:
predicate “has”
Plural, singular notions (cardinality)
Sufficiency and completeness notions (e.g., no-nulls)
Math does a lot more.  Let's just talk about logical entailment in this .  Given, "I have a headache", how do you entail, "I have pain", unless you have a categorization of headache as a type of pain?  You won't get that from unstructured or semi-structured text, or database structure or SQL.  It's "common sense" to you but computers have no more common sense than a light switch (or even a few million light switches).
Let's make this more relevant to EA. 
"F-16C has a speed capability of Mach x" ==> some F-16's have a speed capability of Mach x
"F-16's can fly at least Mach y" ==> F-16C's can fly at least Mach y
"Ship's Self Defense System can parse and generate TADIL-J messages" and "SSDS is-part-of all CVNs" ==> CVN's can parse and generate TADIL-J messages
I could go on and on.  Without the "intelligence" to perform entailment, data integrations, queries, and analysis algorithms miss connections.  I cannot even remember all the EA data integration and analysis routines I've seen over the years that flopped for this reason -- it is a real problem.  I'd bet Ian has lotsa examples too.  The C4ISR community has problems with semantic imprecision too.
My basic point is that we computer scientists think we're doing a lot with computers when we use databases but it's really just storage and retrieval with connections only for exactly matching pieces of information (e.g., "keys" or exactly matching strings).  Reasoning requires a lot more and entailment is an important part.  IDEAS supports entailment and other sorts of mathematical understanding of the data with membership (~ set theory) and 4D mereotopology (parts and boundaries).  It only seems academic at first because it's so fundamental in human reasoning that it's hard to see that computers don't have it at all and that they need it if we want to use them for something more than just storage and retrieval.  We have to encode it into them with formal methods like IDEAS.
It's a hard question because it's related to many questions that have been going on for a long time about AI, the "meaning of meaning", semantics vs syntax, types, set theory, categories, mereonomy, etc. I think now that we've got some of the "accidental" problems (e.g., when I had to write assembly language on green tablets or when we couldn't even run RDBMS' because they were too slow) behind us in computer science, we can start chipping away at some of these "essential" questions now. 
predicate
subject
object
i.e., structured sentences => language-based

19. Compare DM2’s Predesessor, a classic E-R model
CADM had 687 entities, 3,914 attributes, 11,911 domain values, and 1,249 associations = 17,762 data elements
DM2 has 217 foundation and domain data elements, 37 IC-ISM's, and 4 metadata for a total of 258 data elements
CADM had 687 entities, 3,914 attributes, 11,911 domain values, and 1,249 associations = 17,762 data elements
DM2 has 217 foundation and domain data elements, 37 IC-ISM's, and 4 metadata for a total of 258 data elements

20. Sample for today’s overview
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
Sample for today’s overview

21. Performer Data Group Central to the description of architecture
Performers are the “Who”
the “How” are assigned to Performers
Assignment involves tradeoffs, e.g., for performance and cost/benefit
Assignment results in allocated baseline and initial work breakdown structures
Performers
Types: Organizations / Org Types, Person Types, Systems (humans and machines), and Services – or any combination thereof
Follow Rules
Are at locations
Have measures 21

22. Performer 22

23. Performer Data Group Notes
Performer subtypes:
Person Type e.g., Military Occupational Specialties (MOS)
MOS describe Skills and their measurement (not shown in this diagram).
Person Type includes Materiel assigned and necessary for the performance of activities
e.g., as per Army CTA-50.
Note that Person Types have temporal whole-parts (states) such as in-garrison or deployed that may have different Materiel compositions and other associations such as applicable Rules.
An Organization (type or actual Individual Organization) meaning a mission chartered organization
Not limited just collections of people or locations
e.g., the Federal Bureau of Investigation (FBI) has a chartered mission and it chooses the locations, people, etc., to accomplish such.
A System in the general sense of an assemblage of components – machine, human – that accomplish a function
anything from small pieces of equipment to FoS and SoS
Systems are made up of Materiel (e.g., equipment, aircraft, and vessels) and Personnel Types, and organizational elements.
A Service, from a software service to a business service such as Search and Rescue.
Any combination of the above.
What it means for a Performer to perform an Activity:
The performance of an Activity by a Performer occurs in physical space and time.
Two ways in which a Performer spatial-temporally overlaps an Activity:
In the act of performing the Activity
Sometimes called “assigned to” for the purposes of traceability.
As part of a larger process (aggregated Activity)
Sometimes called “allocated to”
Not all architecture modeling standards explicitly provide for allocation. For example, the Systems Modeling Language (SysML) extensions to the UML modeling standard have added this feature. 23

24. Resource Flow Data Group
Resource Flows are used to model the flow of Resources – Materiel, Information (and Data), Geo-Spatial Extents, Performers, or any combination thereof.
Resource Flows are key modeling techniques used in the definition of Interfaces and assurance of Interoperability between Activities and their performing Performers (e.g., Systems and Personnel.)
Resource Flow models and associated analysis techniques reveal behavior such as:
a. The connectivity between resources.
b. Resource Flow modeling provides an explicit means to describe the behavior of activities, systems, organizations and their composite effects on the overall enterprise.
c. The content of the information flowing between resources (e.g., interface definition).
d. The order or sequential behavior (parallel or serial) of the resources in relation to one another (e.g., project task execution and critical path).
e. The behavior of Resource Flow between or within organizations (e.g., work flow, information flow, etc.).
f. The changes in state during the spatial and/or temporal existence of the resource.
g. The rules that modify the behavior of the Resource Flow (e.g., business rules, controls, decisions, etc.).
h. The measures that define the quality, constraints, timing, etc. of the Resource Flow (e.g., Quality of Service (QoS), measures of performance, measures of effectiveness, etc.).
i. The flow of control orchestrating the behavior of the Resource Flow. 24

25. Resource Flow
Whereas prior versions of DoDAF modeled only information and data exchanges and flows, this version also allows modeling of other flows, such as:
Materiel flows such as ammunition, fuel, etc. important for modeling the fire rate, logistics, etc. aspects of a Capability solution so it can be compared with other alternative solutions
Personnel Types such as Military Occupational Specialty (MOS) that allow representation of the Training and Education “pipeline” aspects of DOTMLPF.
Performer such as Services, Systems, or Organizations that might be the “output” or result of a Project’s design and production process (activities). This allows modeling of, for instance, an acquisition project.
Another difference from prior versions of DoDAF is that all exchanges and flows are by virtue of a producing or consuming Activity. That is, a Performer can only provide or consume by conducting an activity of production or consumption. For instance, publication and subscription are modeled as an interaction between the publishing Activity, the subscribing Activity, and the information or data Resource. Note that publication is typically not at the same time as subscription but the subscriber does have to go to the publication place to retrieve the Resource. For example, data might be published at 2:00 GMT on server located at some URL and the subscriber may not “overlap” until 10:00 GMT. Also note in the diagram the “overlap” is a triple – the producing Activity, the Consuming Activity, and the Resource.
The exchange or flow triple may have standards (Rules) associated with it such as IA/Security rules or, for data publication or subscription, data COI and web services standards.
The exchange or flow triple may have Measures associated with it such as timeliness, throughput, reliability, or QoS. 25

26. Resource Flow Data Group Notes
The term flow implies that something (e.g., materiel, information) is moving from point A to point B, hence the use of the foundation concept of “overlap”.
Resource Flows are Activity-based, not Performer based since a Performer cannot produce or consume a resource other than by conduct of a production or consumption activity.
Whereas prior versions of DoDAF modeled only information and data exchanges and flows, this version also allows modeling of other flows, such as:
Materiel flows such as ammunition, fuel, etc. important for modeling the fire rate, logistics, etc., aspects of a Capability solution so it can be compared with other alternative solutions.
Personnel Types such as Military Occupational Specialty (MOS) that allow representation of the Training and Education pipeline aspects of Doctrine, Organization, Training, Material, Leadership and Education, Personnel, and Facilities (DOTMLPF).
Performers such as Services, Systems, or Organizations that might be the output or result of a Project’s design and production process (activities). This allows modeling of, for instance, an acquisition project.
The exchange or flow triple may have standards (Rules) associated with it such as Information Assurance (IA)/Security rules or, for data publication or subscription, data COI and web services standards.
The exchange or flow triple may have Measures associated with it such as timeliness, throughput, reliability, or QoS.
Resource Flow modeling can be performed at varying levels of detail and fidelity depending on the areas of concern being analyzed and the solutions being sought. The upper-level aggregations have been termed need lines in previous versions DoDAF. Other terminology expressing levels of aggregation are used depending on the community of interest (e.g., The SysML modeling standard uses lifeline). 26

27. Capability Data Group
The Capability Data Group provides information on the collection and integration of activities that combine to respond to a specific requirement.
A capability, as defined here is “the ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks.”
This definition is consistent with that contained in the JCIDS Instruction published by the Joint Staff 27

28. Oriented towards Desired Effects (measurable)
Manifested by Performers (including Performer configurations – remember whole-part)
Activities, Rules, Conditions, …
Capabilities link to Measures (“Metrics”) through the Activities they entail and the Desired Effects sought. 28

29. Capability Data Group Notes
“Ways and means” are interpreted in DM2 language to be Activities and Resources
Because a Desired Effect is a desired state of a Resource (see Goals data group), a Capability is about states (persistence of current ones, or changes to future ones) of Resources.
Capabilities link to Measures (Metrics) through the Activities they entail and the Desired Effects sought. (see next slide)
Capabilities relate to Services via the realization of the Capability by a Performer that is a Service. In general, a Service would not provide the Desired Effect(s) but, rather, access to ways and means (Activities and Resources) that would. 29

30. Services Data Group
A Service, in its broadest sense, is a well-defined way to provide a unit of work, through which a provider provides a useful result to a consumer.
Services do not necessarily equate to web-based technology or functions, although their use in the net-centric environment generally involves the use of web-based, or network-based, resources.
Services form a pool that can be orchestrated in support of operational activities, and the operational activities define the level of quality at which the Services are offered. 30

31. Services Services 31 OASIS definition adopted by DoD
Capabilities and Services are related in two ways. One, the realization or implementation of a Capability by a Performer (configuration, including Location) may be by a Service (or collection of Services). Conversely, the realization or implementation of a Capability by a Performer (configuration, including Location) may be the means by which a Service (or collection of Services) is accomplished.
Unlike DoDAF 1.5, Services in DoDAF 2 include business services, such as Search and Rescue. This is important to keep in mind because much of the SOA literature is IT-oriented.
Although, in principal, anything has a description, the importance of self-description for discovery and use of Services merits its call-out as a class. Further, because only a public-facing side is described, the Service description needs to represent that it describes the Service Port, not the entire Service. A Service Port is a special type of Port that is self-describing and visible. The Service Description of the Service Port is of all aspects necessary to utilize the Service and no more. As such, it may include visible functionality, QoS, interface descriptions, data descriptions, references to Standards or other Rules (Service Policy), etc. The inner workings of the Service are not described in a Service Description.
Since Service inherits whole-part, temporal whole-part (and with it before-after), Service may refer to an orchestrated or choreographed Service, as well as individual Service components.
Since Service Ports are types of Ports and Ports are types of Performers, they inherit all of Performer’s properties, including Measures associated with the Performer, performance of Activities (Service Functions) with associated Measures, and provision of objects (Materiel, Data, Information, Performers, Geopolitical Extents).
Any Performer that consumes a Service may have a Service Port that is described in the service request. This description indicates how the Service provider should provide or respond back to the Service consumer. That is, Service Ports are parts of Performers that may or may not be Services themselves.
Service users interact with the accessed Performers via the Service Port. The Service Port is a special type of Port that is the part of a Performer that provides access to the Performer capabilities. Note that the Performer capabilities provided access to can be an aggregate, e.g,. an orchestration, of Performer components. The Service Port is the service consumer facing part of the Service and so has a Service Description, a type of Information. This Thing described by this type of Information is the Service Port.
Rules (service policies, contracts)
Measures (QoS) 31

32. Services Data Group Notes
A Service is a type of Performer which means that it executes an activity and provides a capability.
Unlike DoDAF V1.5, Services in DoDAF V2.0 include business services, such as Search and Rescue. This is important to keep in mind because much of the SOA literature is IT-oriented.
Capabilities and Services are related in two ways. One, the realization or implementation of a Capability by a Performer (usually a configuration of Performers, including Locations) may include within the configuration Services (or Service compositions) to access other Performers within the overall Performer configuration. Conversely, the realization or implementation of a Capability by a Performer (configuration, including Location) may provide the Performers that are accessed by a Service (or Service composition).
Since Service inherits whole-part, temporal whole-part (and with it before-after), Service may refer to an orchestrated or choreographed Service, as well as individual Service components.
Any Performer that consumes a Service may have a Service Port that is described in the service request. 32

33. Services Data Group Notes
A Service Port is a special type of Port that is
Self-describing and visible. The Service Description of the Service Port is of all aspects necessary to utilize the Service and no more.
As such, it may include visible functionality, QoS, interface descriptions, data descriptions, references to Standards or other Rules (Service Policy), etc.
The inner workings of the Service are not described in a Service Description.
Part of a Performer that provides access to the Performer capabilities and the consumer that participates in the service.
Note that the Performer capabilities provided access to can be an aggregate, e.g., an orchestration, of Performer components.
The Service Port is the service consumer facing part of the Service and so has a Service Description, a type of Information.
Since Service Ports are types of Ports and Ports are types of Performers, they inherit all of Performer’s properties, including Measures associated with the Performer, performance of Activities (Service Functions) with associated Measures, and provision of objects (Materiel, Data, Information, Performers, Geopolitical Extents). 33

34. Information Pedigree – workflow model
2. Resources Used, e.g., other Information
6. Where done
5. Measures in the production, e.g., QoS, uncertainties
1. Information Production Activity
~ Open Provenance Model (provenance = linked together pedigrees)
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
4. Rules followed in the production
3. Who did the production

35. Requirements Traceability and Design Levels in DM2
describes
describes
describes
Thing
describes
describes
Pedigree
(requirements)
Pedigree
(requirements)
Pedigree
(requirements)
Pedigree
(requirements)
Architecture Description
Pedigree
(requirements)
Architecture Description
Architecture Description
Architecture Description
Architecture Description
Rules
Rules
Zachman’s “Reification Transforms” Successive refinement of the architecture description. For any phase, it is traceable to the prior (pedigree). The prior phase becomes the rules that constrain the activities of the next performer – adherence to requirements baseline.
They’re all aiming at the same future Thing, just describing it in more detail and in different ways as you go along.
Rules
constrain
Rules
constrain
Rules
constrain
constrain
constrain
Worker
Technician
Engineer
Architect
Executive
Strategic
JCD
IOC
time

36. DM2 Possible Interest for Software Intensive PEOs: (1) As it makes DoDAF work better
SoS Engineering and Integration
Upgrade orchestration – no more “ATO in the Gulf”
Interoperability
Specification for – comms, data, processing, procedures, …
Assessment during acquisition
Solutions that fit Capability objectives
Traceability through design refinement
Data Strategy / Data Sharing
Information sharing requirements modeling
COI DMWG’s and interactions, ADS strategies,
Derivation of data schemas from information requirements -> conceptual models -> logical -> physical schema
Network consolidation
Connectivity requirements – rules, metrics, business processes, …
• Skills and Training
• Policy
• The Acquisition Organization
• Metrics
• Process
• Commercial Off-the-Shelf (COTS) Products
• Facilities and Tools
Software Architecture
System of Systems Integration
Capability Engineering Framework (CEF)
Software Metrics
Network Service Center This is an Army effort to reduce the number of networks and the
number of access points. While the goal is to get to a single network, this is not realistic. We
do think we can reduce the number of access points from 400 to 5, which supports integration
with DoD security infrastructure.
DoD Security and Identity Management This is a joint service effort necessary to support
sharing data across services within DoD.
Data Strategy This element comprises many programs, inside the services, across DoD,
and includes industry. Where do I get what I need, what is the format, who has access to it?
This includes the unsolved problem of how to enforce need-to-know. Current architectures
based only on clearance level do not provide the granularity needed for authorization decisions.

37. DM2 Possible Interest for Software Intensive PEOs: (2) the mathematical foundation itself
The mathematical foundation itself, as an input to new ways for PEO’s to architect software data structures supporting, e.g.,
Componentization
Interoperability of independently acquired systems and components
Integration scaling
SoA orchestration
Unanticipated data use
• Skills and Training
• Policy
• The Acquisition Organization
• Metrics
• Process
• Commercial Off-the-Shelf (COTS) Products
• Facilities and Tools
Software Architecture
System of Systems Integration
Capability Engineering Framework (CEF)
Software Metrics
Network Service Center This is an Army effort to reduce the number of networks and the
number of access points. While the goal is to get to a single network, this is not realistic. We
do think we can reduce the number of access points from 400 to 5, which supports integration
with DoD security infrastructure.
DoD Security and Identity Management This is a joint service effort necessary to support
sharing data across services within DoD.
Data Strategy This element comprises many programs, inside the services, across DoD,
and includes industry. Where do I get what I need, what is the format, who has access to it?
This includes the unsolved problem of how to enforce need-to-know. Current architectures
based only on clearance level do not provide the granularity needed for authorization decisions.

38. Questions?

39. Backup

40. LDM Diagramming and Use of UML as an Ontology Diagramming Tool
Individual -- An instance of an Individual - something with spatio-temporal extent
Type -- The specification of a Type
IndividualType -- The specification of a Type whose members are Individuals
TupleType -- The specification of a Type whose members are tuples
Powertype -- The specification of a Type that is the set of all subsets of a given Type
Name -- The specification of a name, with the examplar text provided as a tagged value
NamingScheme -- The specification of a Type whose members are names
Note: tuples have place positions, just like FK’s in ER models
A&D
The IDEAS Model is represented in UML. The UML language is not ideally suited to ontology specification in its native form. The UML language can be extended through the use of profiles. The IDEAS Model has been developed using a UML Profile - any UML elements that are not stereotyped by one of the IDEAS foundation elements will not be considered part of an IDEAS ontology. The IDEAS Foundation specifies the fundamental types that define the profile stereotypes. The super-subtype structure in IDEAS is quite comprehensive, and showing the super-type relationships on some diagrams can result in a number of crossed lines. In these cases, supertypes of a given type will be listed in italic text in the top-right-hand corner of the UML element box.
The stereotype of an element in an IDEAS UML model is a shorthand for the element being an instance of the type referred to by the Stereotype, though the type must be one that has been defined in the root package of the foundation. Hence, if the stereotype is Individual then the element is an instance of an Individual. The following stereotyped classes, with their color-coding are used in the model:
Individual An instance of an Individual - something with spatio-temporal extent [Grey(80%) R40G40B40]
Type The specification of a Type [Pale Blue R153 G204 B255]
IndividualType The specification of a Type whose members are Individuals [Light Orange R255 G173 B91]
TupleType The specification of a Type whose members are tuples [Light Green R204 G255 B204]
Powertype The specification of a Type that is the set of all subsets of a given Type [Lavender R204 G153 B255]
Name The specification of a name, with the examplar text provided as a tagged value [Tan R255 G254 B153]
NamingScheme The specification of a Type whose members are names [Yellow R255 G255 B0]
The following stereotyped relationships are used in the model:
typeInstance a relationship between a type and one of its instances (UML:Dependency) [Red R255 G0 B0]
powertypeInstance a relationship between a type and its powerset (UML:Dependency) [Red R255 G0 B0]
nameTypeInstance a relationship between a name and its NameType (UML:Dependency) [Red R255 G0 B0]
superSubtype a relationship between a type and one of its subtypes (UML:Generalisation) [Blue R0 G0 B255]
wholePart a relationship between an individual and one of its parts (UML:Aggregation) [Green R0 G147 B0]
namedBy a relationship between a name and the thing it names [Black R0 G0 B0]
tuple/couple> a relationship between a things (UML:n-ary relationship diamond) [Grey(80%) R40G40B40] 40

41. Some points about the foundation:
Types include sets of Tuples and sets of sets.
Tuples can have other Tuples in their tuple places.
There are three subtypes of Type: 1) Individual Type, sets whose members are Individuals (Things with spatio-temporal extent); Power Types, sets whose members are generated from a powerset on some other set; and 3) Tuples, sets of ordered relations between Things.
The participants in a super-subtype relationship can be from the same class, e.g., the supertype can be an instance of Measure Type as well as the subtype. This allows for representation of as much of a super-subtype taxonomy as is needed.

42. Powertypes
Power Type members are generated from some Type by taking all the possible subsets of the members of the Type. For example consider the Type whose members are a, b, c. The powerset would be:
Some of these subsets are not used by anyone, e.g., the full set, the null set, or just some random subset.

43. Interesting Instances of Powertypes
Take the Individual Type AIRCRAFT, whose members include all the aircraft of the world. The powerset generated from this set would have:
The first two are not very interesting
The second one, which might be name F-15 Type, is quite useful.
The last example is not useful to most unless you are interested in the first (assuming the subscript 1 means first) of any particular aircraft type, e.g., if you were doing a study of first-off-the-line aircraft production lessons-learned.
The usefulness of Power Types
they allow for multiple categorization schemes with traceability back to the common elements so that the relationships between multiple categorization schemes are known
multiple categorization schemes or taxonomies in EA because across a large enterprise it is not possible to employ a single categorization scheme, rather schemes vary depending on function.
For example, a weaponeer’s classifies ordnance is naturally different from a logistician’s, the former concerned with delivery means, lethality, etc. and the latter with weight, size, and other transportation issues.
Note also that a powerset can then be taken of the powerset