Stated: "DoD's doctrine, organization, training material, leadership & education, personnel, and facilities (DOTMLPF)"

Error: "training material"

Corrective Action: Entire acronym, properly stated should read: DOTmLPF-P: Doctrine, Organization, Training, materiel, Leadership and Education, Personnel, Facilities and Policy.

Definitive Source: JCIDS Manual, 31 August 2018

Applicable Proponent: J7/JIB, on behalf of the Joint Staff Director for Joint Force Development (DJ-7)

Actual Resource - Traceability is described as a View Specification on pages 101-102, but that square in the Grid is black.

Within UAF Appendix B - Sample Problem, v1.2, Figure 9-8: Personnel States for SAR Rescue Team represents a number of states with multiple do actions in a list. This may be a tool limitation, but State Machines in Cameo EA and Rhapsody are limited to one do action per state.

The definition for "SubOrganization" does not address its meaning/use; instead it uses the same definition as for "Person".
(see also related reported issue)

Requested to provide a list of deprecated elements for new version in order to note gaps and make necessary refactorizations.

The Domain Metamodel Elements (Section 9.1.1) included Architecture Management::Sequences elements, but the Architecture Management::Sequences diagrams were not included in Domain Metamodel Diagrams (Section 8.1.1) and Figure 7:1- UAF Grid.

The abstract metaclass "Process" in the UAF metamodel is represented by the abstract stereotype "Activity" in the UAF Profile.
This is confusing, The "Activity" stereotype should be renamed to "Process" to achieve consistency.

The UAF specification defines Security Control as a kind of SysML Requirement. However, the specification also references NIST SP 800-53 in the definition of Security Control. NIST SP 800-53 clearly separates Security Controls from Requirement. E.g., in section 2.1 Requirements and Controls of NIST SP 800-53r5 it says "...It is important to understand the relationship between requirements and controls." It goes on to say "...the term requirement is generally used to refer to information security and privacy obligations imposed on organizations." It defines controls as "...descriptions of the safeguards and protection capabilities appropriate
for achieving the particular security and privacy objectives of the organization...". In other words, Security Controls are a kind of capability.

Current implementation of information elements (both Operational and Resource) does not allow for decomposition, which would allow for multiple layers of fidelity to be represented in a model. Most information elements in a real system are "decomposable" in the sense that they can be represented by parts (in the case of a document, multiple data elements may be represented in one Operational element; in the case of a Resource information element, headers and multiple payloads may be represented within a higher level "information" element. The data model is particularly important within the EA reprsenetation of a system.
Generalization is also needed within the information elements; flow properties on intefaces should accept elements of a less generalized implementation.

The EA Guide and the formal UAF documents suggest that UAF can be used to capture non-security risks at various levels of abstraction of the AD. The view specifications and UAFML limit the mitigation of a risk to a security control. It appears that an operational or resource mitigation should be elements that are able to mitigate a risk. The current metamodel only allows risks to affect those elements. Some rework in this area would improve the ability to capture non-security risks for ADs. Please see attached pdf for additional information.

Operational Performer is what does an activity in your model: Person, Organization, Service, and only if-and-only-if fully automated - a System. There's no linkage in UAF between these elements, and will thus cause duplication and/or configuration item bloat when you assert that Operational Performer named CAOC/CAOC Director sends ATO to Wing/Squadron/Mission Planner, when CAOC, Wing, Squadron are all Organization (types), and CAOC Director and Mission Planner are Person (Roles).

View specification for <<Standards>> elements do not allow for directed composition into other <<Standards>>. Specification for <<Standards>> elements do not specify a part property.
This is needed because many ConformsTo relationships conform to only a specific part of a standard, rather than the entire standard. Traceability is enhanced by allowing for a UAF Element to ConformTo a standard at a lower level than the parent.

if one looks at the other *ExchangeItem descriptions...

there is a *Parameter that has a type as an *ExchangeItem which is missing.. (it is in the description of the ServiceParameter)...

also, it is missing the derived relationships between ServiceExchangeItem and ServiceFunction

Signals should be ExchangeItems... since Exchanges are ItemFlows from SysML...
Signals should be included

The description says "A dependency relationship denoting that a Risk is drawn out by an Opportunity." I have tried three different online translators that presents different meaning of "is drawn out by". Can the description be made more crisp and less ambigous for a non-native English speaking audience?

DataElement is obsolete and should change name to ResourceInformation.

ClassificationAttributes all Strings are missing multiplicities

think this is wrong description for BillingItem

Properties indicating the assurance of a piece of information

endDate : ISO8601DateTime[0..1]
End time for this ActualProjectMilestone

should have multiplicity of [0]

missing definition of Cost for BillingItem

The change of name from the UAFP to the UAFML is technically incorrect. The UML or SysML are modelling languages because they can be used to model many real world things and relationships - the UAFML is fixed and it only represents a particular UML (and SysML) representation of the UAF DMM. It is a UML profile as stated in the text - 'It was created by mapping the UAF concepts and relationships to corresponding stereotypes in the UAFML Profile.' So now we have a UAFML profile (aka UAFPP ...)

There is and can only ever one example/individual use of the UAFML. It cannot be used for any other purpose. It is not, therefore, a modelling language and defining it as such does a disservice to the UML et al.

The statement - 'Due to the complexity of managing the multiple viewpoints with overlapping concerns and metamodels' ... needs to be clarified. Concerns never overlap - viewpoints may share concerns. I think what is being described is that donor AFs may have shared concerns - if so the sentence needs to be qualified because within a UAF you woudn't expect shared concerns because it is then poor viewpoint design and leads to inconsistency if the user can't easily select the same viewpoint to use (too much overlap).

It's all the more confusing because Fig-8:2 Architecture Views states that a zero or more Concerns are (framed?) by a single Viewpoint so it's not even possible for viewpoints to share a concern.

Centre- rather than left- or fully-justified text

42010 uses Architecture Description whereas in UAF we have what seems to be the same concept but is 'ArchitecturalDescription'.

The model in Figure 3.21 is missing relationship names between ArchitecturalDescription and View, ArchitecturalDescription and Architecture, ArchitecturalDescription and Viewpoint. These should in accordance with 42010 be 'has part, or is composed of', 'expresses' and 'has part or is composed of'.

It should be noted that architecture descriptions using the UAF do not include architecture viewpoints - the viewpoints used are separate. In old 42010 terminology the UAF uses what is called 'library' viewpoints to save having to include in each and every AD. The relationship is something like 'references' or a form of trace.

It is poor practice not to label relationships and repeating the target stereotype name as a role name on a connector adds no information.

The figure also misses the association with ArchitectureFramework that is mentioned in Associations.

The architectureFramework association doesn't, as stated, indicate the type of architecture framework - it identifies the particular architecture framework.

3.1 lists Normative References, 3.1.1 lists normative OMG references. Non-OMG normative references should still be part of 3.1 and hence should be 3.1.2 not 3.2

There is also a problem in the wholesale application of normative references to any part of the UAF. The DMM is supposed to be implementation-agnostic and therefore ADL references should not be normative for that. Similarly the only place where MODEM and DODAF etc are referenced are in the Traceability document (perhaps the UAFML?) so they are not normative for the DMM itself - particularly as there are elements in the DMM that are not in the MODEM, or DODAF or MODAF [this is also a problem within the Traceability document - it isn't complete].

It would make sense to qualify the scope of the normative references by splitting into sub-sections e.g. general (common to all), DMM, UAFML, Traceability - if you're going to place all of the references in the one place. Alternatively add a References section to each sub-document and only state the normative references that apply to the document being read.

The statement is made 'The following normative documents contain provisions which, through reference in this text, constitute provisions of this specification.'

This isn't true.

UML profile for BPMN isn't normative in the DMM - it might be in the UAFML which defines a UML profile for the UAF but ADLs such as the UML, SysML, BPMN, IEPPV, BMM cannot be normative for the DMM which is supposed to apply to non-UML implementations. The UML spec is only informative for the DMM in as much as it conceivably (impossible in practice) might provide advice on how to read and interpret the notation used.

Any wiki, for example the IDEAS one, cannot be normative. For a start there is no defined baseline date or issue let alone the fact that it doesn't state any requirements. At best this particular one is an informative reference.

The OMG identifier on the front cover is formal/22-07-03 which turns out to be a SysML specification according to the issue tracker.

However using the URL https://www.omg.org/cgi-bin/doc?formal/22-07-03 seems to want to return the UAF specification.

If the OMG identifier for UAF 1.2 DMM is formal/22-07-03 then section 1 and Table 1-1 contain the wrong OMG identifiers (dtc/.... rather than formal/...)

There is no stereotype defined for ResourceInteractionScenario and the other variants of InteractionScenarios (OperationalInteractionScenario and OperationalInteractionScenario).

I expected stereotypes for these concepts in the same way that there are stereotypes defined for the different varieties of StateDescriptions.

ResourceInteractionScenario is defined within chapter Domain MetaModel::Personnel::Sequences in the specification
The correct chapter shall be Domain MetaModel::Resources::Sequences.

On figure 8:79 Standards Taxonomy we appear to have something like UAFElement conformsTo Standard. It is unclear because 'conformsTo' appears to be a role (which is incorrect if so), the multiplicity should be 0..* not *.

What provides the 'conformsTo' relationship required?

Relationships on the diagram aren't named. The multiplicities aren't correct - they should never be * (1 is always permissible). 'ratifiedBy' role is naming a relationship - as the target element is Organization the role name ought to be 'ratifyingOrganization' i.e. characterising the target node.

There appears to be no conformsTo UAF element. The relationship on the diagram isn't named. The other fly in the ointment is that someone has copied SysML for the Requirements diagram which does show a 'Satisfy' relationship. So 'Satisfy' vs 'conformsTo'? This is one of the problems in not separating implementation from the DMM (the DMM shouldn't simply repeat the names of SysML, UML etc elements since there's no reason that they represent the same thing and you need the ability to diconnect as this is supposed to be ADL agnostic.

How is this view specification supposed to be implemented when relationships aren't labelled and there appear to be elements missing?

The use of a '*' multiplicity is incorrect - should be 1 or more Concerns. Similarly an ArchitecturalDescription (name error - should be ArchitectureDescription) should be composed of 1 or more Architecture Views (not *). A Viewpoint may frame only 1 Concern (not *)

The use of a direction indicator is undefined and looks to be incorrect. In the direction from View to Viewpoint what is the relationship? In ISO 42010 there is a 'governs' relationship.

The use solely of role names is incorrect - roles only label the target (source) node - they do not define a relationship. How is anyone supposed to implement a set or relationships where the relationships are not labelled? Figure 8:2 should use the relationship names defined in 42010 i.e. standardise.

Using a role name that simply repeats the name of the source / target element is pointless - it adds no information whatsoever. The other problem with solely using role names is that if the label is offset it isn't clear whether it is a role or a relationship name and therefore whether it applies to the node or relationship.

Inconsistent name wrt ISO 42010 and with its own definition - ArchitecturalDescription vs Architecture Description.

The multiplicities aren't correct. For example we have on Architecture to ArchitecturalDescription we have * on both ends which means that an Architecture has no existance independently of its ArchitectureDescriptions (plural as there have to be many of them). Should be 0..* on ArchitecturalDescription. Similarly with View it ought to be 1..* View and 0..* Viewpoint (otherwise an ArchitecturalDescription is required to include multiple Viewpoints which doesn't allow for a central set of 'library' viewpoints in ISO 42010 terminology).

The relationships with View, Viewpoint, Architecture need to be named.

'expresses' looks like a role but cannot be. If it is a role it needs to qualify the target element e.g. 'describedArchitecture' not the relationship.

Why does ArchitectureMetadata have a multiplicity of 1 on ArchitecturalDescription - is each piece of metadata unique to every ArchitecturalDescription?

What is an ArchitecturalReference? This looks like a relationship. What then is the point of adding a role name to a relationship? Isn't this just 'UAFElement traces to ArchitecturalDescription?

The concerns identified are - 'Concerns: captures activity-based behavior and flows.'

Figure 8:92 only defines a class hierarchy mapping UAF elements to BPMN elements. Ignoring that this is ADL-specific and shouldn't be in the DMM, this doesn't deine how process flows, activities are described and linked together. If such a viewpoint is felt necessary the UAF elements (not the BPMN elements) should show the triples that are permitted to be used in a conforming view.

As defined this, the NIEM etc view specifications are a) not defined and b) impossible to implement in a non-UML ADL.

Within 8.1.15 there are a number of ADL-Specific View Specifications. The DMM is supposed to be (but isn't) ADL-agnostic. It is impossible for any non-UML implementer to use or implement this content. Given that ADL-specific implementation is elsewhere e.g. the UAFML for UML,SysML then if there is a need to define this should be in a separate document and not the DMM.

Within the document there appears to be no usable link or definition of Satisy [another implementation artefact] and no definition of a Requirement element or other relationships linked to Requirement (Trace, Verify, Refine).

Figure 8:86 multiplicities don't look to be consistent - 0..1 on Trace but 1 on Satisfy. Trace looks to be wrong - think someone trying to describe Requirement traces to Requirement, UAFELement traces to UAFElement and UAFElement traces to Requirement but there is no identification of path and its ambigous or wrong.

Why is Requirement not a UAF Element? If it's not why is it even in this specification? Again I suspect this is an implementation artefact - someone thinking of a SysML::Requirement (which is an implementation of the DMM)

8.1.2 View Specifications::Summary & Overview::Summary & Overview

General problem - there is no such thing as 'view specification' - it doesn't exist in the DMM itself (text should only include defined concepts), it seems to be being used as a synonym for ISO 42010::'architecture viewpoint' (if this is the case then 'architecture viewpoint' is the correct and consistent term to use.

Concerns: ''quick overview of an architecture description and summary of analysis. In the initial phases of architecture development, it serves as a planning guide. Upon completion of an architecture, it provides a summary of findings, and any conducted analysis.'

Problems -
1) this is an overview and its application not a list of concerns held be stakeholders
2) Given the common confusion in the UAF between 'architecture' and 'architecture description' - is this 'phases of architecture development' or 'phases of architecture description development'? Since an architecture description may be used to provide comment on architecture this is ambiguous in the UAF contetx where these terms aren't differentiated.
3) 'It isn't completion of architecture - it's not even completion pf 'architecture description' - what the author seems to be stating is completion of the 'architecture task' that produce the architecture description. The description os wrong and possibly more triples need to be defined in the DMM

Defintion
'provides executive-level summary information in a consistent form that allows quick reference and comparison among architectures. The Summary and Overview includes assumptions, constraints, and limitations that may affect high-level decision processes involving the architecture.'

Problems;
4) This is a description not a definition

Figure 8:11 - Summary & Overview

The green elements are relationships - not tuples as defined in the legend. The expectation is that view content consists of triples (node-connector-node).
5) General problem - There is nothing that defines how these views are to be interpreted (ISO 42010 requires this and it would aid consistent development and provide rules for verification of each view).

Anything that doesn't form the basis for a triple shouldn't be in the viewpoint definition i.e.

6) ArchitecturalDescription, ArchitectureMetadata, Metadata as these don't appear to form any triple

7) View, Viewpoint. There are no relationship elements provided to form a triple with ArchitecturalDescription

8) Stakeholder, Concern, OrganizationalResource, ActualOrganizationalResource have no relationship with ArchitecturalDescription

9) There is no relationship element between ArchitecturalReference and Architecture so it is impossible to establish a link between the Architecture, its impacts etc and the ArchitecturalDescription so impossible to describe this.

Triples should be able to be read as sentences and have clear semantics:

'ArchitecturalDescription Architectural Reference Architectural Description'
10) What does this mean? Is this a trace between ArchitecturalDescriptions i.e. 'ArchitecturalDescription traces to / references / etc ArchitecturalDescription'. A currently defined this makes no sense. I suspect that the problem is that elements are added but the triples so-formed are not being read to make sure that they are intelligible i.e. object-focussed rather than relationship-focussed approach.

11) 'Opportunity Phases ActualStrategicPhase' - what does this mean? If the sentence is unclear it either won't be used or be used inconsistently as each individual attempts to try and understand it (not conducive to shared understanding)

[Note - owing to inconsistency in form behaviour between specification and OMG Document number the original was misallocated to SysML as SYSML17-647 which can be deleted]

The definitions of ActualEnterprisePhase, WholeLifeEnterprise and EnterpriseMission are:-

'ActualEnterprisePhase - A time period within which a set of Capabilities are deployed
WholeLifeEnterprise - A WholeLifeEnterprise is a purposeful endeavor of any size involving people, organizations and supporting systems. It is made up of TemporalParts and StructuralParts

EnterpriseMission - Mission captures at a high level what you will do to realize your vision.'

Figure 9:164 defines:-

1) WholeLifeEnterprise (endeavour) is a ActualEnterprisePhase (time period) - this is incorrect
2) EnterpriseMission (what you do) is a ActualEnterprisePhase (time period) - this is incorrect
3) The definition of ActualEnterprisePhase is not atomic - it includes Capabilities. Type definitions should be atomic, not depend on anything else (otherwise you're defining all or part of a triple and if the external element or relationship named changes the definition is invalid)
4) The definition of WholeLifeEnterprise is similarly non-atomic - it should not include reference to any relationship e.g. temporal or structural for example.

UAFElement is defined: 'Abstract super type for all of the UAF elements. It provides a way for all of the UAF elements to have a common set of properties.'

This doesn't define the concept. It simply states what purpose the element serves for a developer. The name tells us nothing. In the metamodel the names are supposed to indicate what they represent.

Do all UAFElements appear in an architecture view and therefore architecture description? if so it might really be 'Architecture Description Element'. This term first appeared in ISO 42010:2011 and in 42010:2022 is an 'identified or named part of an architecture description'. Alternatively it might be 'An individual architecture description object that is used to describe or represent an item of real-world architecture. An architecture description element can appear in an architecture description.' <https://trakmetamodel.sourceforge.io/vocab/TRAK_metamodel.html#Architecture_Description_Element>

This is a consequence of the lack of differentiation within the UAF (and donor AFs) between 'Architecture' and 'Architecture Description'

Fig 9:122 Metadata.
Definition: 'A comment that can be applied to any element in the architecture. The attributes associated with this element details the relationship between the element and its related dublinCoreElement, metaDataScheme, category and name. This allows the element to be referenced using the Semantic Web.'

it is clear that this refers to 'architecture description' not 'architecture' e.g. the application of DCMI elements

It should therefore be 'applied to any element in the architecture description'

If Metadata is already defined as applying to an architecture description, how can ArchitectureMetadata specialise this and also be applied to the architecture description description - this is what Metadata does and as part of an AD which describes an architecture there is no need for 'ArchitectureMetadata'?

Figure 8-14 only shows Capability, CapabilityRole elements.

The definition of the view specification is: 'Definition: shows the relationship between EnterprisePhases and the Capabilities that are intended to be developed during the enterprise phases, and the organizations involved in the enterprise.'

It is impossible to construct a view using Figure 8-14 that satisfies this because:-

a) No EnterprisePhase (should this be ActualEnterprisePhase?) nor element to describe relationship(s) with Capability
b) What has CapabilityRole to do with this view specification? As defined this seems unsolicited and isn't connected to the definition
c) Even with Capability, CapabilityRole elements provided the view specification doesn't include any relationship elements ('tuple') in green to connect Capability to anything else