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)

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?

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 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.

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.

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.

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.

Centre- rather than left- or fully-justified text

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/...)

Currently, a <<SecurityControl>> is the source of the <<mitigates>>relationship to the target <<SecurityRisk>>. Further research shows that a security control (a type of requirement) in and of itself does not actually mitigate a <<SecurityRisk>>. Rather, the <<ResourceMitigation>> that<<satisfies>> the <<SecurityControl>> requirement is the actual UAFElement that <<mitigates>> the <<SecurityRisk>>.

The only allowable relationship between <<Capability>> and any Requirement element is <<trace>>. In US Department of Defense acquisition processes, stakeholder needs are defined as capabilities within a Capability Description Document. These capabilities are high-level system requirements from which system and sub-system requirements should be derived. The recommended solution is to enable the <<deriveReqt>> to have <<Capability>> as the target and any type of <<AbstractRequirement>> as the source of a <<deriveReqt>> relationship. An alternative would be the <<refine>> requirement relationship.

The method redefinition changes the type from SysML Behavior to SysML String, which limits the usefulness of the UAF viewpoint stereotype unnecessarily without providing any benefit. The description of the method attribute is, "The methods employed in the development of the Viewpoint." Redefining this to a string precludes defining executable methods that generate a view from the viewpoint, while leaving it as a behavior would not preclude defining the method as a string, since the body attribute of UML OpaqueBehavior is a string.

Allowing the definition of the method as a behavior would also allow explicitly defining the types of inputs from the model needed to produce the view from the viewpoint as the types of input parameters to the behavior.