1.1 states:- 'UAF Modeling Language (UAFML) (this document formal/22-07-05) provides the modeling language specification for implementing the UAF DMM using UML/SysML'

and 'The UAFML defines a set of stereotypes and model elements and relationships to satisfy the requirements of the UPDM 3.0 RFP and the UAF DMM.'

1) There is no evidence provided wrt how each DMM AD element is implemented i.e. for each DMM AD element what UML or SysML stereotype has been chosen to implement the DMM AD element. A traceability table is needed for the UAFML specifically that a) shows matched (traced elements) and b) shows unmatched SysML/UML stereotypes which might be added for other reasons, for example to add wanted tool behaviours, but which have nothing to do with DMM AD element conformance. Such a traceability table must be required in any case to verify against the DMM and trap potential implementation errors.

2) As the UAFML is an implementation I would expect class inheritcance hierarchies separate from view content. It's almost impossible to use this specification where there are tiny fragments of what must be a unifying model (somewhere)

3) The statement is made 'The UAFML defines a set of stereotypes and model elements and relationships ....'. Given that a UML profile defines a set of UML/SysML stereotypes what then are 'model elements and relationships' - don't the UAFML stereotypes define node and relationship elements? If not what are these other elements, why do they exist? This might be explained or justified by the traceability table in 1) but it's an odd statement that suggests that something is missing. A relationship is a model element i.e. not just nodes.

Type 1 Conformance exempts - 'with the exception of the view specifications in the Architecture Management Viewpoint'.

An (architecture) 'viewpoint' is a specification against which a view is prepared and interpreted etc iaw ISO/IEC/IEEE 42010. It is an error to use 'viewpoint' to mean a collection of architecture viewpoints

1.1 item 5 states 'The approach defined in this Guide is just one way to approach architectures when using UAF' which should be 'The approach defined in this Guide is just one way to approach architecture description when using UAF'

The use of 'architecture' to sometimes refer to 'architecture' and sometimes refer to its description ('architecture description') is a perniscious problem in the UAF. It might be acceptable in casual conversation but technically the terms from 42010 should be used correctly. This is particularly the case since the DMM states that 'The UAF conforms to terms defined in the ISO/IEC/IEEE 42010 standard for architecture description' - it doesn't. See also 'view specification' which is an undefined and unnecessary concept.

1.2 we have 'UAF extends the scope of UPDM and generalizes it to make it applicable to commercial as well as military architectures' which should also be 'architecture description' not 'architectures'

The UAF defines an identifier for each of the UAF diagrams. These are listed, for example, in the Traceability doc Table 2.1.

Instead of using anique identifier each of the 'view specifications' has what looks like a package structure string i.e. 'View Specifications::Resources::Structure::Resources Structure' should have the identifier - 'Rs-sr' so the identifying string is - 'Rs-sr - Resources Structure'

Using a package containment as an identifier isn't correct. If you move a 'view specification' to another package the package string changes. The identifier, however, doesn't and hence this should be what is iused to identify a view specification. Any text string taken from the package containement structure is a beneficial addition but it doesn't identify the view specification.

The identifier used for the traceability document in 7 UAF Grid of 'dtc/21-12-10' is incorrect.

Requirement is not a UAFElement - p133, p103

Figure 8:86 permits UAFElement Trace Requirement and UAFElement Refine Requirement

It isn't therefore possible to present 'Requirement Refine Requirement' nor 'Requirement Trace Requirement' triples in a View Specifications::Motivation:Requirements view.

ServiceArchitecture is defined as 'An element used to denote a model of the Architecture, described from the Services perspective.'

1) This doesn't define what service architecture is
2) ... denote a model ... almost everything in the UAF metamodel is an AD Element i.e. something that describes some real world concept and forms part of an AD (a model). The definition is supposed to define the real world thing that it is used to represent not itself.
3) Architecture is essentially the set of temporal, spatial, functional etc relationships that something has [internally and with anything external]. ServiceArchitecture is not a specialisation of Service ie it is not true to state that 'ServiceArchitecture is a Service'. The class structure is not therefore correct. I suspect what has happened is that this is a bottom-up derivation which enables behaviours and or properties to be inherited that are useful in a UML implementation. That doesn't make it correct however. Occam's razor should apply in these cases.

1) Satisfy, Refine, Verify show an Association to both UAFElement and Requirement and appear to implement a many:many relationship. The Associatioons do not, however, define a direction for the relationships. As this is supposed to be a normative specification are the relationships implemnted as bi-directional, uni-directional? This is a problem in partially defining a (relationship) node 'from node' and 'to node' rather than node - relationship - node with direction on the relationship itself.

2) There are two identical Associations shown between Requirement and Trace - same multiplcities, not labelled. It is impossible to distinguish them apart and all they do is define that there is some unnamed relationship in some (or both) directions. I suspect that what was meant was a UAFElement traces to Requirement and possibly Requirement traces to UAFElement but this isn't what the diagram says. Had a node - connector (with direction) - node style been used the differentiation problem wouldn't arise and errors would be more easily spotted.

Metadata attributes - DCMI

1) category. Refers to DCMI abstract which isn't a category
2) dublinCoreTag refers to 'A metadata category that is a DublinCore tag.' This doesn't define anything. Any DCMI tag? Not all CMI tags are categories. Why not simply list those DCMI tags that you think are essential / useful rather than what looks to be an arbitrary and inconsistent reference?
3) Metadata is defined as 'a conment that can be applied to any element in the architecture'. This is incorrect - it can be applied to any AD element. The DCMI tags only apply to artefacts - video, text, sound, document etc so they don't apply to every AD element (UAFElement) as many/most of these do not represent artefacts. DCMI tags only apply to documents, standards etc.

[The original ticket was misallocated to SysML as SYSML17-649 which can be closed / deleted]

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]

Figure 9:134 – UAFElement shows a single attribute - URI

Don't UAFElements have a name, identifier (other than URI), description etc? According to this they don't.

URI is incorrectly defined - 'Captures Unique identifier for the element.'

assuming that URI = Unifiform Resource Identifier - which a url-form of identifier (W3C define this so the definition ought to be standards-based rather than local). It isn't just an identifier. 'captures' shouldn't be part of the definition - that's how the attribute is used.

Note: this repeats the misallocated https://issues.omg.org/issues/SYSML17-646. Issues SYSML17-645, SYSML17-647, SYSML17-648, SYSML17-649 should also be allocated to the UAF not SysML (problem where drop-down list of Specification doesn't correspond to the OMG document number]

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'?

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>

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

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.

In establishing a mapping there are 3 possible outcomes (gap analysis):

1) Target element is not linked to any UAF element
2) Target element is linked to a UAF element
3) UAF element is not linked to any target element

The Traceability document only considers 2). This is inadequate. For example a statement is made concerning linkage to MODEM but this is only true up to the point where MODEM was released - UAF elements added which are not present in a 'donor AF' such as Requirement will not be linked to MODEM. Without a full list of all of the UAF elements its difficult to do a completeness check and to spot potential errors. It's important for an implementer to understand what might be in the UAF that isn't in a donor AF - particularly where the donor AF is no longer being maintained and over time therefore there will be more new-to-UAF elements.

Missing - Satisfy, Refine, Verify, Trace, Requirement. These are UAF elements (unless it's possible to conform without using them). These should be listed in Table 4.1

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

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.

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.

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

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

missing definition of Cost for BillingItem

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]

The concept of "Concept Role" is missing in the DMN while it is available in the UML profile specification.
As a consequence, ConceptItems (Location and Asset) are owned by HighlevelOperationalConcept which should not be the case.

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.

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

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 Achiever abstraction bundles in the same hierarchy "production agents" (actual resources) and "transformation agents" (actual strategic phases, actual projects).
While both produce effects: the former (actual resources) are about outcomes delivered by the enterprise, while the latter are about change of the enterprise itself.
Shouldn't we distinguish these two kinds of "changes".
In page 39, indeed, the EA guide states that measurements of effect are different for 'transformation effect" versus "ways and means effects":
"A Measure of Effect (MOE) parameter describes qualitative or quantitative states or levels that directly relate to outcomes. Outcomes are sought by stakeholders, whose interests and perspectives are addressed by the actual measurements of effects. These outcome measurements are different from measurements of associated ways and means."

Proposed resolution:
1. Rename "Achiever" in initiative
2. Remove "Actual Resource" as a sub-type of Achiever

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.

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.

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

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.

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

"Enterprise Visions" & "Enterprise Goals" are supposed to be valid for the whole life of the enterprise whereas "Enterprise Objectives" are time time-targeted.

Proposal:
1. Remove "Enterprise Vision" as a sub-type of Phaseable Element. Enterprise Vision is "owned" by a "WholeLifeEnterprise" as a kind of "DesiredResult" (Ends versus Means).

2. Potentially remove "Enterprise Goal" as sub-type of Phaseable Element. "Enterprise Goal" is "owned" by a "WholeLifeEnterprise" as a kind of "DesiredResult" .
This was the original intent in MODAF (see quote below from MODAF Handbook")
"Within the StV-1 view, certain Enterprise Goals are identified. These goals relate to the entire enterprise lifetime, they are not specific to an
Enterprise Phase"

3. Add "Enterprise Objective" to enterprise phases. "Enterprise Objective" is owned by enterprise phases as a kind of "DesiredResult" .

PS: The current "Phases" relationship mixes relationhip to "Ends" (Vision, Goals, Objectives) and relatonship to Means (Capabilities).
The best practice is to separate Ends and Means.

ActivityPerformableUnderCondition bounds "process" (a class) to an individual to individual state (ActualCondition).
This breaks the BORO principle that classes should not be time bounded.

Proposed resolution:
(1) Have actualCondition as a Type
(2) or .. have ActivityPerformableUnderCondition be related to "Condition" instead of "ActualCondition".

Desirer bounds "Class Entities" (Capability, Resource Performer, ..) to individual state (Actual State).
This breaks the BORO principle that classes should not be time bounded.
There is no way to relate Capabilities to Effect (class).

Proposed resolution:
1. Desirer is made deprecated and kept for compatibility
2. A new relationship is added between capability and effect

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

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)

The word ‘realizingArchitecture’ between the [Abstract]Architecture and [Tuple]Implements is misspelled in Figure 8:11 - Summary & Overview. The letter d is redundant.
In addition, thanks to the OMG organization for developing the documentation about UAF, which made me learn a lot.

The description in this section is a copy of View Specifications::Resources::Traceability and View Specifications::Personnel::Traceability. The desciption os also not in accordance with the example problem in section 14.3 of the Sample Problem (dtc/2021-12-12). Also, Ar-Tr is missing from the UAF Grid. In summary, it is difficult to understand the view specification Actual Resources::Traceability. However, we do understand the need for a view specification according to Figure 4:82.

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

The names of Ends on MotivatedBy to not match the EA Guide and the principles establishes by the BMM on which it is grounded.
The EA Guides says that "Enterprise Goals" are "motivated by" Drvers.

Proposal:
Rename "motivatingEnterpriseGoal" in "MotivatedEnterpriseGoal"
Rename "motivatedDriver" in "motivatingDriver".

It is not clear why "Opportunity" and "Challenges" are part of "Motivatedby" as it seems to be a separate topic.

Multiple conflicting [1.1] multiplicities on Implements

Proposed solution:
(1) "Implements" is made abstract
(2) "Implements" relates UAFElement (or better "Class of UAFElement").
(3) Appropriate concrete sub-types are created for Resource, Function, OperationalAgent, etc..

Multiple conflicting [1.1] multiplicities on PerformInContext

Proposed solution:
(1) PerformInContext is made abstract
(2) PerformInContext is relates ProcessUsage to AssetRole
(3) Appropriate concrete sub-types are created for FunctionAction, OperationalActivityAction, etc.

Multiple conflicting [1.1] multiplicities on IsCapabletoPerform.

Each UAF::*Constraint specialization of UAF::Rule has a constrainedElement metaconstraint on SubjectOf*Constraint, none of which include SysML::ConstraintBlock as a specialization. This complicates the use of SysML Parametric analysis using UAF stereotyped UML::Constraints, since ConstraintBlocks can not own them. UAF SubjectOf*Constraint elements that are specializations of UML::Class should be allowed to own ConstraintProperties typed by ConstraintBlocks that have UAF::*Constraints. Need to also allow alternate metaconstraint so that UAF::*Constraint can be owned by ConstraintBlocks that are used as ConstraintProperties by the associated UAF::SubjectOf*Constraint

Suggestion is to add ConstraintBlock as an alternate metaconstraint target for UAF::*Constraints AND a 3rd alternate metaconstraint that allows existing UAF::SubjectOf*Constraint to own ConstraintBlocks that have no or properly stereotyped owned constraints.

LocationHolder.physicalLocation and requiredEnvironment tags could be derived from Asset.properties when those Asset.properties have defaultValue UML::InstanceSpecifications with the ActualLocation and ActualEnvironment stereotype applied, respectively.
This would save UAF modelers time in populating the tags when they also want to leverage SysML parametrics and fUML behavioral simulation capabilities that rely on UML::Class.properties. There are no simulation semantics developed for LocationHolder.physicalLocation ot requiredEnvironment so duplication of effort would be required to both execute simulation and comply with current UAF semantics.

Should be more than indication of ToBe or not ToBe. Should be a timeline of planned/expected evolution of the architecture IAW defined
states and transitions in States view. Versions should correspond to which capabilities, missions, actual measurements, etc. will be achieved for that version.

This should show more than merely “Status”. Should be a view showing the progression of maturity states for the architecture.

Should be more than just identification of a methodology (Besides, a methodology is not a process…). Should allow for capturing a process-like diagram.

One of the AM views shown in the Grid does not have corresponding View Specifications in UAFML: Architecture Taxonomy: Architecture Extensions. Add the necessary view specification in UAFML.

See attached slides

UAF is currently trying to be compliant with ISO 42010. To continue with being compliant, UAF needs to be updated to conform to new term and concepts in the new version of 42010 to be published in 20022.

Since UAF is published as an ISO document, the ISO version must be compliant with the ISO style guide which has specific requirements on structure, formatting and style. Recommend that v1.3 of UAF be restructured and reformatted to be ISO compliant.

In UAF metamodel, Personnel view concepts use the Organizational Resource elements which are specialization of Resource Performers. In other words, Resource Performer is a more "abstract" concept than Organizational Resource "performers".

So, given the general pattern of rows in the grid start with most abstract at the top and most concrete at the bottom, it would be better to swap Personnel and Resources viewpoint rows so that Resources (being more abstract) appear above the Personnel (which are more concrete than resource performers).

Both the Strategic row and the States column are designated as "St" which can sometimes lead to confusion. Suggest changing Strategic viewpoint designator to "Sg" to avoid this confusion. (Similar thing was done in v1.2 when Personnel row was changed from "Pr" to "Ps" to avoid confusion with Process (Pr) column.)

NATO framework grid shows three behavioral like aspects as being grouped by Behavior. Suggest doing same for UAF Grid. Also, Taxonomy, Structure and Connectivity columns are three forms of "structure", so we should group these three columns and call that grouping Structure.

Taxonomy views are about more than "typology" and specialization since they can also include referentialization (i.e., references) and composition. These views are typically captured using SysML Block Definition Diagrams (BDD), so it would be better to call this column "Definitions".

Structure views are really about compositions, so it would be better to call this column "Compositions". Connectivity views are about dependencies, interactions or flows, so would be better to call this column "Interactions".

Actual Resources domain covers more than just instances from the Resources domain. Also covers instances from the Personnel domain (i.e., Post, Organization, Person, Responsibility). Suggest changing name to Actualization. Or perhaps merely “Actuals”?. Or perhaps “Instantiations”?. Better represents what is going on here.

See attached slides

Problem with Using Portfolio element (portfolio kind of Project). The Portfolio (kind of) Project does not have the necessary semantics with the features and relationships enumerated below. Can possibly use Whole Life Configuration (WLC) element to represent a Portfolio but this only gives part of the picture of what is in the Portfolio. (a) Acts as a “collection” of things with an associated Gantt chart for deployment timelines, (b) Does not tell us who “owns” that collection of things in the Management Accountability sense, (c) A Portfolio can consist of multiple Whole Life Configurations.

Portfolio needs to have the following features: a) Things it is delivering (e.g., in its Whole Life Configurations), b) Who runs it (i.e., the Actual Organization), c) Particular programs within it (e.g., actual Projects or project elements), d) Alignment with budget elements, assigned Opportunities and Risks, etc., e) Assigned responsibility for execution of particular Enduring Tasks (and associated Capabilities), f) Accountability towards achieving Effects (e.g., MOE target levels) for a given time period, g) Can be assigned responsibility for certain Missions, Enterprise Goals and Enterprise Phases, h) Can be jointly managed with another Enterprise for shared Operations and Resources.

Might be that Portfolio could be a kind of Whole Life Enterprise (i.e. subtype) that has the features and relationships noted above.

See attached slides.

Two Architectural Descriptions must be able to reference each other which have no containment relationship to each other. Purpose: This supports the ability for architectures to reference each other when they sit in other separate projects and repository locations. Two Architectural Descriptions must be able to reference each other when there is an intervening containment organization.

See attached slides.

UAF specifies three kinds of Actual Measurements: Actual, Required, Estimate. But if only 1 of the 3 kinds is “actual” then the other 2 kinds are “non-actual”. Only one of the three kinds of Actual Measurement is truly an “actual” measurement kind. This is a logical inconsistency, which is a source of confusion for some modelers. Suggest changing the kinds to: Achieved, Required, Estimated (past tense). Suggest adding new kinds: Expected, and Desired.

See attached slides.

There is often a confusion between typical and actual measurements. Causes some modelers to use these elements incorrectly. Modelers sometimes insert the expected or desired “value” of a measurement into the Measurement element rather than in the Actual Measurement element. Does not make sense to allow Measurement to have any values since the Measurement element is intended to be the “standard” for doing the measuring. That would be like having a meter stick and marking 27 cm on the stick itself. For comparison purposes, look at definitions of Measurement and Measure in dictionary.

Definition of measurement: the dimension, quantity or capacity determined by measuring. Which is really what “actual measurement” element is dealing with. Definition of measure: a reference standard or sample used for the quantitative comparison of properties [e.g., a “yard stick” or “meter stick”].

Proposed element name changes to address this issue. Change name of Measurement element to Measure. Change name of Actual Measurement element to Measurement. As noted above, measurement is defined as being the result of measuring. Change Measurement Set to Measure Set (to align with changes above).

See attached slides.

Need to add Use Cases as a modeling construct in UAF

Need to update the EA Guide to correct some errors with respect to v1.2. Also need to update based on changes to be made in v1.3 of the metamodel and modeling language.

Need to update the sample model to finish incorporating new model views for all of v1.2. Also need to update based on changes to be made in v1.3 of the metamodel and modeling language.

NATO has a methodology for capturing NAF compliant architecture models. Instead of changing UAF to include the specialized NAF concepts, create a separate NATO Framework Guide for UAF.

Location concept in dictionary is "determination" of the "place where something is". Would Location be a more accurate term for Location Holder concept? Location in UAF is currently enumerated with *geometric" parameters such as solid volume, surface, line, point, etc. However, Location is a more general concept.

Sometimes the Operational Architecture uses concept of Platform as the "place where something is" rather than describing the location geometrically. A Platform could be thought of a special case of Location. Also, sometimes the "place where something is" will be called an Organizational Node (agnostic to an Organization resource per se).

Make Location abstract with three kinds of Location elements: Physical Location (for current notion of Location), Platform (where something is mounted or situated), and Organizational Location (a place that has a definite purpose or a place that is responsible in an organizational sense).

See attached slides.

Enterprise Mission in UAF is a specialization of Actual Enterprise Phase. But in what sense is a Mission some kind of Phase? Mission is defined in UAF as "captures at a high level what you will do to realize your vision". A Phase is not "what you will do" but rather organizing a collection of things to do to achieves goals assigned to that Phase. Need to put Mission into UAF the way it was done in UPDM. Mission is more like an Enduring Task. In UPDM a Mission was an extension of a Use Case. Need to also add a way to capture a Mission Thread.

See attached slides.

Node was a concept in UPDM but was replaced by Operational Agent in UAF. Needline was a concept in UPDM but was replaced by Operational Connector in UAF. Since Node and Needline are commonly used concepts in the world of operational architectures and mission modeling, add these to UAF as specializations of Operational Agent and Operational Connector, respectively.

See attached slides.

In UPDM there was a Trust Line between Nodes (now called Operational Agents in UAF). There is need to have a Trust Line for security reasons which will help in modeling the security architecture for the enterprise. Add Trust Line concept back into UAF.

There is a need for the concept of Operational Scenario which can perform Operational Activities. Many modelers use an Operational Architecture as the entity to capture notion of a Scenario or Vignette or Use Case. Add Operational Scenario as new kind of Operational Agent. May also need to add Resource Scenario as new kind of Resource Performer.

See attached slides.

An architecture is defined as "fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes" [ISO 42020] An Architecture has no "agency", i.e., an architecture cannot do anything since it is a property of the thing that is being architected. Therefore, Architecture cannot be a kind of Operational Agent since an architecture cannot be "capable to perform" operational activities.

Change Operational Architecture to Operational Configuration. Change Architecture to Configuration. Change Resource Architecture to Resource Configuration. Add Architecture as new separate element and add relationship Configuration <has> Architecture. Architecture is still <described by> Architectural Description. Make Operational Architecture a Capable Element and likewise for Resource Architecture and Service Architecture. Add Service Architecture to Figure 9:130 in DMM since it is missing.

See attached slides.

Capability is defined as an "ability to do something". As such, a capability cannot desire some state or some effect. Only things with "agency" can desire something. Agency is defined as the "means or mode of acting". Operational agents and resource performers have the "means of acting" while a capability does not possess this quality. Only some kind of "action" can lead to effects or state changes. See briefing slides.

Add relationships Operational Activity <leads to> Actual State and Function <leads to> Actual State (and same for Service Function). Remove Capability as a Desirer but link it to Actual State directly with <enables> relationship. Make Capability Configuration <exhibits> Capability.

See attached slides.

To be consistent, a Service should be a kind of Desirer that can desire an Actual State, Actual Effect or Actual Outcome. This would make this parallel to Operational Agent and Resource Performer which are both kinds of Desirers.

See attached slides.

It can be expected that a Service would perform necessary Service Mitigations to deal with expected threats to that Service, similar to what is done by Operational Mitigation and Resource Mitigation for Operational Agents and Resource Performers, respectively. Add Service Mitigation as specialization of Service Architecture.

See attached briefing.

Currently a Service Function can implement an Operational Activity and a Service Interface can implement an Operational Interface. To be consistent, UAF should allow a Service to directly implement an Operational Agent. Add this new relationship Service <implements> Operational Agent.

See attached briefing.

Currently a Resource Service can implement a Service. However, the implementing performer could also be a System, Capability Configuration, Software, Technology, Organization, Person, Post, etc.

Therefore, UAF should allow any kind of Resource Performer to implement a Service. Add new relationship Resource Performer <implements> Service. Also, to be consistent, add new relationship Function <implements> Service Function. Note that a Resource Interface can currently implement a Service Interface.

See attached briefing.

Operational Agent has specializations of Operational Architecture and Operational Performer. To be consistent, UAF should allow a Service to have a specialization of a Service Performer to go along with the specialization of Service Architecture. Add new element of Service Performer.

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.

Since all UAF::Stereotypes that extend UML::Property metaclass are all UAF::MeasurableElement, that means that the UML::Property.defaultValue is an InstanceSpecification that has an ActualPropertySet with a PropertySet as its classifier. If that defaultValue has a ValueSpecification with ActualMeasurementSet applied, then one of the actualMeasurementSet tagged values could be derived from this defaultValue.

This would save time for modelers that use defaultValues for executing SysML parametrics and fUML, as they would not need to also fill in the tag manually. Clearly these defaultValues should be included in the tagged values as intent is the same or subset of.

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.

By constraining UAF ControlFlows to just the associated viewpoint Actions as sources and targets we are preventing users from using the full range of UML::ActivityNodes that they could use in Process Views. Significally, ControlNodes, such as the Initial,Fork,Join,Merge,Final Nodes are all excluded but of major importance to good description and visualization.
Recommendation:
1) Either elevate UAF::*ActivityAction up to UML::ActivityNode and specifically add UML::InterruptingActivityRegion.interruptingEdge
2)or remove .source and .target constraints on UAF::ControlFlows

SysML has very tight constraints on ProxyPorts and InterfaceBlocks that are bypassed by using FullPorts. Specifically the no_behavior and no_part constraints on InterfaceBlocks. By constricting UAF::*Ports to ProxyPorts, it prevents UAF architects from taking full advantage of behaviors and parts on UAF::*Ports. Just like SysML, an alternate method for having ports with parts and/or behaviors should be allowed.
I don't see any perfect specific recommendation, there will probably have to be a change that tool vendors will have to create a mapping for.
Alternate 1: Make UAF::*Port an Abstract Stereotype, removing the Generalization to ProxyPort. Then create 2 new specializations of ResourcePort, one for "ResourcePortProxy" and another "ResourcePortFull" each specializing SysML::ProxyPort or SysML::FullPort respectively.

Alternate 2: Remove/Obsolete the stereotype altogether or remove it's dependence on Proxy or Full and require double stereotype like UPDM l1 compliance. Instead place constraints on *Performer.ownedPort metaproperty based on if it's port is either Proxy (using *Interface type) or Full (using *Performer type).

Alternate 3: Just switch generalization of UAF::*Ports from SysML::ProxyPort to SysML::FullPort. There are no constraint violations as FullPorts can be typed by InterfaceBlocks, so no changes needed for users or UAF::*Interface. Requires update to UAF::*Port.type constraints to allow addition of <<OperationalAgent>>, <<Service>>, or <<ResourcePerformer>> as valid types.

UAF::ProtocolImplementation is really a subset of all UAFElement.conformsTo Standards. Aka if a UAF::ProtocolImplementation implements a UAF::Protocol it should also count as conformingTo it. Recommend making the implements tag a subsetted property of the conformsTo tag. Also, to allow Standards to actually enforce parametric constraints or execute behavioral simulations as part of UAF models, recommend creating a <<ConformsTo>> property stereotype that has <<Standard>> as a target and <<UAFElement>> as a Source (or maybe just limit to PropertySet), and/or add a derived Tag to UAFElement that derives a subset of conformsTo relationships from classifier.properties that have <<Standard>> or stereotypes derived from <<Standard>> as their type.

IsCapableToPerform (ICOP) connects client UML::Classes to supplier UML::Activities. This is the same purpose as UML::Operation, through featuringClassifier and method. While UAF::OperationalMethod, ServiceMethod and ResourceMethod exist, their link to IsCapableToPerform is apparent but absent. Recommend adding ICOP as an extention of not just Abstraction, but also Operation with additional caveats that it can only be applied as a stereotype when the Method is not Empty. An alternate strategy is to add a Tag to ICOP that points to the UAF::*Method that implements it, kind of like the SysML::AdjunctProperty.. Or the reverse, create a tag on UAF::*Method that points to it’s ICOP.

The Implements DMM relationship is primarily used in Traceability views between Viewpoints. While currently encoded in the UAF ML as the Implements element specializing the Allocate relationship, this is not the only way to encode that concept and be consistent with the DMM. According to SysML v1.6 15.1 Allocations Overview "Allocations can be used early in the design as a precursor to more detailed rigorous specifications and implementations."
Given the current set of UAFElements that can participate in Implements relationships I recommend 2 additional ways that the DMM Implements concept can and is given more rigorous specification and implementation in SysML models. These are the UML::Generalization and UML::RedefinableElement concepts.

7 of 11 Implements clients can participate in Generalization relationships, 2 clients can participate in RedefinedElement relationships. Methods should be explored to leverage these as alternate methods of encoding the DMM Implements relationship.

I can't think of a super clean method of doing this, a few come to mind. First is to use a Taxonomy of Implements stereotypes that separately extend Abstraction and Generalization, but that can't solve RedefinableElement since it's a metaproperty that is not reified into a UML::Relationship. So, an alternate method is to make all 11 Implements clients specializations of a common more general stereotype that has a tag that is derived from all 3 UML methods of encoding Implements. The use of tagged values in this way will change the UAF ML::View Specifications where UAFMP::Implements in currently the only method shown. Lastly thought of, force tool vendors to automatically create a UAFMP::Implements when one of the 9 clients participates in a Generalization or RedefinedElement relationship that matches the DMM Implements constraints. The UAF ML can force this by adding constraints on use of Generalization or Redefinition on the 9 and 2 client elements respectively.

Currently there is no constraint that the Classifier of any of the ActualMeasurementSets used in a UAF:MeasureableElement actualMeasurementSet tag be related to the MeasurementSets used in the measurementSet tag. Recommend that the Classifier of any ActualMeasurementSets used as tagged values of a UAF:MeasureableElement actualMeasurementSet tag be used to derive a subset of the measurementSet tagged values.

While UAFML is "intended to be relatively easy to implement for vendors who support UML 2.x and SysML 1.x", it is not as easy for organizations with existing UML 2.x and SysML 1.x models. Organizations are currently faced with adding UAF::Stereotypes to existing UML/SysML models (sometimes not possible for Configuration Management reasons), "copying" UML/SysML elements and adding UAF stereotypes, or not adopting UAF.
I recommend providing a normative default mapping of some UML/SysML model elements without UAF:Stereotypes applied and/or a standard way of "copying" these elements.

Specifically UML and SysML elements, by default, should be allowed to be used in place of Resources Stereotypes. This would mean some Constraints would need to be relaxed on Connectivity, Process, Constraint and other Dependency or metarelationship where the source or target or other role must be a Resource Stereotype.

In addition or alternately, allow the SameAs relationship to explicitly allow the target end to not have to be a UAFElement.

Also, allow SameAs to extend UML::Generalization as well as Dependency. While technically this makes the UAF source of the relationship a specialization, not exactly SameAs, it achieves the intent especially if the UAF element is not further constrained. It also then supports redefinition, subsetting and all other inherited properties that UML::classifiers get from being the source, specific metaproperty/role, of the generalization relationship.

UML has a rich diversity of Actions that are not usable within UAF because the View Specifications for Processes and Connectivity only mention UAF::*Action in the view Specification. First recommendation is that all UML::Actions are explicitly mentioned as allowed in these View Specifications.

Second recommendation is to specifically support the use of UML::CallOperationAction.operation:>UML::Operation.method be used as an alternate to UML::CallBehaviorAction.behavior. This will allow UAF::OperationalMethod, ServiceMethod, ResourceMethod to be used in these View Specifications. Specifically, recommend elevating the UAF::*Action stereotypes from extending UML::CallBehaviorAction to either:
1. Also extend CallOperationAction
2. Or extend CallAction (also supports StartObjectBehaviorAction (aka classifierBehaviors))
3, Or extend InvocationAction (also supports Send/BroadcastSignal as well as SendObjectAction).
4. Or extend UML::ActivityNode or UML::Action (everything)

Also, of minor concern, the constraints that an OperationalExchange must occur over an realizingActivityEdge stereotyped by OperationalActivityEdge that, at least for OperationalControlFlow, have constraints where the source and target must be OperationalActivityAction.