Figure 88 for ServiceMethod shows a ServiceMethod having its owner constrained from two different directions. It shows the ownership being constrained using the ownedOperation role from ServiceInterface and via the owner role to ServiceSpecification. It should be consistent.

<Submitted on behalf of James Johnson>
Diagram for UAF Specification for PropertySet (Figure 21) only identifies 13 UAF Elements that are considered PropertySets (Asset, ProjectMilestone, Capability, Resource, Competence, Servicelnterface, Condition, ServiceSpecification, EnterprisePhase, WholeLifeConfiguration, MeasurementSet, Resourcelnterface, Risk). However, when going through the specification an additional 10 UAF Elements are identified as PropertySets. lf representing all 23 PropertySets in the PropertySet diagram is too cumbersome, suggest adding a table identifying all PropertySets.
PropertySets not depicted in diagram include:
a. Concern (p 158-159)
b. EnduringTask (p 52)
c. EnterpriseGoal (p 45-46)
d. EnterpriseVision to (p47)
e HighLevelOperationalConcept (p 59)
f Operationallnterface
g. SecurityControl
h. Standard
i. View
j. Viewpoint

In quite a few places the Tx and Sr views overlap. My understanding was that the taxonomy views provide somewhere to get a list of all the items and the inheritance between them, with the structure views providing somewhere to show the structure. However, the Tx views quite often contain composite structure as well, which makes no sense to me…

<Submitted on behalf of James Johnson>
Diagram for UAF Specification for MeasurableElement (Figure 21) only identifies 13 UAF Elements that are considered MeasurableElements (Exchange, OperationalConnector, OperatlonalRole, OperationalActivityAction, ProvidesCompetence, Rule, ServiceParameter, Activity, FunctionAction, ResourceRole, ServicePort, OperationaISignalProperty, ResourceSignalProperty). However, when going through the specification an additional 68 UAF Elements are identified as MeasurableElements. If representing all 81 MeasurableElements in
MeasurableElements diagrams too cumbersome, suggest adding a table identifying all MeasurableElements. MeasurableElements not depicted in diagram include:
1. Achieved Effect
2. Affects
3. AffectsInContext
4. Alias
5. ArbitraryConnector
6. ArchitecturaIDescription
7. ArchitecturalReference
8. CapabilityForTask
9. CapabilityProperty
10. CompetenceForRole
11. CompetenceToConduct
12. ConceptRole
13. Consumes
14. Definition
15. DesiredEffect
16. Enhances
17. EnvironmentProperty
18. Exhibits
19. FillsPost
20. Forecast
21. FunctionEdge
22. Implements
23. Information
24. IsCapabIeToPerform
25. MapsToCapability
26. Measurement
27. Metadata
28. MilestoneDependency
29. Mitigates
30. OperationalActivityEdge
31. OperationalMessage
32. OperationalMethod
33. OperationaIParameter
34. OperationalPort
35. OperationaIStateDescription
36. OrganizationlnEnterprise
37. OwnsProcess
38. OwnsRisk
39. OwnsRisklnContext
40. PerformslnContext
41. ProjectMiIestoneRole
42. ProjectSequence
43. ProjectTheme
44. Protects
45. ProtectslnContext
46. ProtocolLayer
47. RequiresCompetence
48. ResourceConnector
49. ResourceMessage
50. ResourceMethod
51. ResourceParameter
52. ResourcePort
53. ResourceStateDescription
54. ResponsibleFor
55. SameAs
56. SecurityProperty
57. ServiceConnector
58. ServiceFunctionAction
59. ServiceMessage
60. ServiceMethod
61. ServiceSpecificationRole
62. ServiceStateDescription
63. Statuslndicators
64. StructuralPart
65. TemporalPart
66. VersionOfConfiguration
67. VersionSuccession
68. VisionStatement

<Submitted on behalf of James Johnson>
ActualOrganizationalResource (Figure 148) does not list
ActualResponsibility as an ActualOrganizationaIResource. The diagram for ActualResponsibility (Figure 198, p 150) designates ActualResponsibility as an ActuaIOrganizationalResource. UAFSpecification needs to resolve this discrepancy.

<submitted on behalf of James Johnson>
Text for ResponsibleRoleKind refers to ResponsibleRole. However, ResponsibleRoleKind is identified as an enumeration for ResponsibleFor (Figure 113). text and figure don't match. (p 92-93)

<submitted on behalf of James Johnson>
In Figure 14 of the UAF Specification, the line between ActualProject and ActualPropertySet is missing. This relationship is also not reflected in Figure 185 (ActualProject). Not certain whether ActualProject is or is not an ActualPropertySet. Please clarify.

<submitted on behalf of James Johnson>
The diagram for AssetRole (Figure 155) identifies SecurityProperty as an
AssetRole. The diagram for SecurityProperty (Figure 156) does not show this relationship.

<submission on behalf of James Johnson>
In the UAF Specification, the diagram for CapableElement (Figure 30) identifies EnterprisePhase as a CapableElement. The diagram for EnterprisePhase(Figure 42) does not show this relationship.
However, the specification for EnterprisePhase does identify CapableElement.

<submission on behalf of James Johnson>
ActualService (Figure 205) should not appear as both ActualPropertySet (Figure 14) and ActualMeasurementSet (figure 13) The dual inheritance is confusing. Please clarify

<submission on behalf of James Johnson>
For completeness, consider listing ActualProject and ActualResource as CapableElements. Additionally, Achiever and Desirer should be listed as CapableElements. Please investigate and add if deemed appropriate.

Figure 34: The constraint text for Information’s annotatedElement role does not match the diagram. The text says it can only annotate ConceptItems but the diagram shows UAFElement. I believe the diagram is correct.

Figure 39: Actual Enterprise Phase: The forecastPeriod tag is set to 0..*, but it should be (I think) set to 0..1. This assumption is based on the textual description of forecast (which says “an EnterprisePhase”) and my understanding of what this is for.

Figure 40 – Capability, shows CapabilityForTask twice.

Figure 43: EnterpriseVision.statement should be derived or removed. EntepriseVision is connected to VisionStatements through the fact they annotate them (as shown on Figure 44) so a non-derived tag as well seems superfluous…

Figure 49 for ActualEnduringTask shows that it is a valid supplier for the ResponsibleFor Abstraction. However, the definition for ResponsibleFor states (textually and diagrammatically) that only ActualProject and ActualResponsibility can be the supplier. I’m assuming Figure 49 is incorrect. We also don’t have ActualProjectMilestone in the text.

Figure 214 for Strategic Roadmap – Deployment shows a ResponsibleFor Abstraction going between an ActualResponsibleResource and an ActualProjectMilestone. Similar to the previous issue, this doesn’t appear to be allowed. Also, this is (as far as I can tell) so you can define who the Resources from the Milestone are being deployed to/removed from, but the name ResponsibleFor really doesn’t work and neither do any of the ResponsibleForKind literals. I think a new, different relationship should probably be added. At the moment, I can’t see a way to fulfil the requirements of this view.

Figure103 for OrganizationalResource is missing some relationships. For example, RequiresCompetence.

The ResponsibleFor.ResponsibleRoleKind tag should start with a lowercase letter like all of the others appear to be and, to be even more consistent, should probably just be called kind.

The ResourceRole.RoleKind tag should start with a lowercase letter.

ResourceInteractionKind should really be called ResourceExchangeKind.

OperationalExchange.trustlevel should be called OperationalExchange.trustLevel, as “trustlevel” isn’t a word.

Figure 140 for DataModel doesn’t show an extension to a UML type.

If DataModel contains InformationElements as well as DataElements, should it really be part of the Resource domain? Similarly, if DataModel can be the subject of an OperationalConstraint, shouldn’t it also be subject of a ResourceConstraint too?

Figure 163 for Risk doesn’t show a specialization to Block but the text above the figure states that Risk does specialize Block.

SecurityControlFamily has a constraint for annotedElement – this doesn’t belong to a Class…

SubjectOfSecurityConstraint doesn’t allow you to constrain any elements from the SecurityDomain – is this correct?

SubjectOfSecurityConstraint is specialized by Asset but not AssetRole – is this correct? (probably related to the previous question)

Figure 179 for ActualProjectMilestone has ActualOrganizationalResource shown but it isn’t attached to anything…

Figure 182 for Protocol should show the relationship to implementers.

ActualService doesn’t need to directly inherit from ActualPropertySet - is already indirectly inheriting via ActualMeasurementSet.

Figure 260 for Security Processes contains additional items to those list in the elements list below it. Also, part of the description for the view mentions SecurityControls, which aren’t shown on the figure. I’m assuming the diagram is correct, as things like Security Process aren’t listed and the element list is wrong, as things like Security Control are shown on the Constraints diagram.

Figure 211 for Strategic Connectivity shows a Capability with a Dependency, which is fine. However, the recommended implementations mention IBD, which doesn’t make sense with this subset of views. Should CapabIlityProperty be shown with Dependencies too – like we used to have in UPDM?

Figure 277 for Services Connectivity doesn’t show anything related to provided/required interfaces, as mentioned in the description for the view…

Figure 277 for Services Connectivity doesn’t show ServiceSpecificationRole, so you’re very unlikely to ever be able to show ServiceConnectors as part of this view…

Operational Activities can be performed by any Operational Agent but only Operational Performers can own Operational Methods. This seems pretty inconsistent and means there’s some gaps in what you can model on things like a Sequence Diagram. Either Operational Methods should be owned by Operational Agents or only Operational Performers should be able to perform Operational Activities. I’m assuming that Operational Agents should be able to own Operational Methods.

Inconsistent naming for State Diagrams – sometimes called State Machine Diagram (correct) but other times just called State Diagram (incorrect but matches our metamodel atm).

Sc-Tx mapped to IBD doesn’t make sense – it doesn’t show any parts.

The Sc-Pr example doesn’t seem to match the specification. It’s showing SecurityControls related to Resources via Protects relationships, with Resources being related to SecurityControls with IsCapableToPerform relationships. There’s a few issues with this:
a. Protects isn’t on the list of items to show in the view (though it probably should be as it isn’t listed anywhere).
b. You can’t connect IsCapableToPerform relationships between Resources and SecurityControls – it goes from Resources to SecurityProcesses.
c. You should be showing some SecurityProcess composition.

The OwnsRiskInContext has the wrong constraint text (looks like it was copied and pasted from OwnsProcess).

The changes to KnownResource don’t make any sense to me. Why change it to a Class? What does it mean now? The text is the same as it was when KnownResource was used to show a Resource inside the context of a Node, but makes no sense now it’s not a part and can’t be used in the same way.

OwnsProcess should be shown on Figure 76.

ProtocolImplementation should be shown on Figure 182.

ServiceOperation should be shown on Figure 89.

Required environment on the LocationHolder is currently linked to Environment which is a type. It does not make sense to link it to a type. Required environment needs to be linked to ActualEnvironment.

Security Property name does not reflect the meaning of the concept. It needs to be renamed.

ResponsibleFor relationship from Actual Responsible Resource to Actual Project Milestone is captured in Figure 222 - Strategic Roadmap: Deployment. It is required to build Strategic Roadmap: Deployment view. However, ResponsibleFor relationship from Actual Responsible Resource to Actual Project Milestone is not depicted in the following figures: Figure 113 - ResponsibleFor and Figure 186 - ActualProjectMilestone.

Actual Enterprise Phase is capable to exhibit capabilities. Enteprise Phase should not be capable doing that.

Page 43, under Figure 38: Constraints [c] and [d] for Implements.supplier should be merged together like the one above.

Figure 39: Actual Enterprise Phase: Concern.systemConcern seems like the inverse name of what the tag should be. I’d expect it to be something like addressingPhase/addressedBy for Concern > EnterprisePhase and systemConcern (if we really must use that name) for EnteprisePhase > Concern…

Figure 53 for Achiever shows AchievedEffect twice.

SecurityControl cannot be a specialization of PropertySet and a specialization of Requirement. The SysML 1.4 specification states Requirements can’t have ownedAttributes or be involved in Associations. This conflicts with PropertySet that has Measurements (Property). Also, Requirements can’t be used to “type any other element”, which is very vague, but could be read as it can’t be (amongst other things) the classifier for an InstanceSpecification (i.e. ActualPropertySet). Either SecurityControl shouldn’t be a Requirement or it can’t be a PropertySet…

Figure 76 for OperationalActivity is missing OwnsProcess.

OV-1c and SV-7 are better fits for Pm-Me, rather than Pm-En. The UPDM views were responsible for showing performance attributes, which doesn’t really have anything to do with defining environments (though the performance attributes would contain environmental properties as well as other properties).

Reported in behalf of NATO ACaT group.
DMM diagrams readability needs to improved:
-missing association role names need to be added;
-hidden attributes need to be shown;
-BPMN aliases need to be hidden;
-missing multiplicities needs to be shown.

OV-1a is mapped as Op-Sr and SmOV – it should probably only be SmOV, as it’s an overview more than an operational structure.

OV-1b is not mapped to anything – I’m guessing it should be mapped to the SmOV?

IBD mapped to Ar-Sr doesn’t make sense – you can’t show InstanceSpecifications on an IBD…

The worked example is still structured as if it was UPDM – not UAF. It’s got Personnel Views listed under Operational Views, All Views with a mishmash of things under it (with All Views not even being a view in UAF). It’s massively out of date and confusing…

Sd mappings are wrong in Annex B:
a. Tx = TV-2 BDD
b. Sr = TV-2 IBD

Pj mappings are wrong in Annex B:
a. Tx = AcV-3 BDD (typical)
b. Sr = AcV-3 BDD (actual)
c. Cn = AcV-3 BDD (actual & typical)
d. Pr = AcV-2 AD (missing completely, even though ProjectActivities were added back in)
e. Rm = AcV-2 Timeline & AcV-1 Tabular

Timeline as a recommended implementation for Sv-Tr doesn’t make sense – I think this should be tabular.

Pr-Ct mapping looks like it should include the OV-4 Actual as a potential mapping.

Pr-Sr is not equivalent to OV-4 Actual – it doesn’t show any instances (i.e. Actual things)… I’m guessing the Pr-Sr should be equivalent to the OV-4 Typical and Actual, but the list of shown elements is wrong, as well as the mapping.

There’s no example of the Sv-Rm view.

Ov-Ct has BDD as a recommended implementation but Sv-Ct (which is basically the same) doesn’t. Seems like one of them should be changed.

Sv-Pr has recommended implementations for BDD, IBD and Tabular format. This is for showing ServiceFunctions (i.e. Activities) so IBD isn’t going to work and Activity Diagram (the most obvious choice) is missing.

There is no example of an Op-Tr.

There should ideally be an example of every recommended implementation for a diagram, so implementers have an idea of what is required – not just one of them.

Op-Cn is mapped to OV-3 and OV-6, but only OV-3 would seem to make sense (especially since OV-6a/b/c are mapped to other diagram types).

In the mapping tables for UAF views to DoDAF/MODAF Views, you just have StV-6 mapped to St-Tr, but StV-6 (at least in part) would seem to be a good fit for Op-Tr as well.

There are inconsistencies between the worked example and the specification. Here are some examples:
a. St-Tr Strategic Traceability
i. States that the recommended implementation includes timeline, but the specification only states tabular and BDD.
ii. It doesn’t include anything connecting things to ActualEnduringTasks.

Section 7 says “UAFP imports the entire SysML profile and contains a set of constraints that specify which SysML stereotypes are applied to the UAFP elements.”. This isn’t true. UPDM was done this way but UAF was done by inheriting from SysML stereotypes instead, so no dual stereotyping and constraints exist.

Should have an IBD version for the Operational Taxonomy view – it is for showing ConceptRoles after all…

Due to the missing mandate that UAF support DoDAF 2.02 views and viewpoints, for presenting content, UAF is considered non-compliant to DoDAF 2.02 by some. Require the implementation of the DoDAF perspective using UAF to provide DoDAF 2.02 Views for compliance.

Describe how UAF conforms to NAF 4 (when it is released).

need to add descriptions to Metada row

Add Lar's diagram in the appropriate places in the documentation.

From UAF patterns presentation.

Move requirements row to be a column.
Add recommended visulizations.

Unified Architecture Framework (UAF), The Domain Metamodel document needs to be primary UAF specification. Unified Architecture Framework Profile (UAFP) document needs to be Appendix for it.

Submitted on behalf of Torsten Graeber in response to comments made by UAF group to queries previously submitted queries made by Torsten Graeber, June 2017

ResourceStateDescription can be assigned to ResourcePerformer and all subtypes. It is considered to be a state machine. However, no definition of state machine given

Yes, the definition of Statemachines is derived from the UML MM.

Submitted on behalf of Torsten Graeber in response to comments made by UAF group to queries previously submitted queries made by Torsten Graeber, June 2017

No evidence found to show structure of InformationElement, or any of its superclasses. However, Figure 6-14 of the example shows InformationElements with relationships. What is the UAF concept for this?

Yes. Aggregation and composition relationships of types are implicitly derived from UML MM.

Submitted on behalf of Torsten Graeber in response to comments made by UAF group to queries previously submitted queries made by Torsten Graeber, June 2017

No evidence found in UAF M2 that supports decomposition of activities. Reviewed elements: OperationalActivity->Activity->MeasurableElement->UAFElement. Potentially OperationalActivityAction is the intended concept (see e.g. Figure 11-20 in the UAF example).

Yes, it is implicitly derived from the UML Metamodel which allows the decomposition and reuse of Operational Activities as OperationalActivityActions.

Submitted on behalf of Torsten Graeber in response to comments made by UAF group to queries previously submitted queries made by Torsten Graeber, June 2017

Not clear how end and start point are identified. However, Figure 6-10 shows a BPMN example with events. What is the UAF concept used here?

Yes, it is implicitly derived from the UML metamodel (Initial Node and Final Node) and the BPMN Metamodel (Start Event and End Event) upon which the UAF M2 for operational process is based. If required we can make It explicit in the UAF M2

Think it also affects sample model doc, dtc/2017-05-13

The diagram for OperationalObjectFlow (Figure 82) does not show links to OperationalActivityAction as does OperationalControlFlow (Figure 81). These should be consistent.

Let me describe the situation.
1. I create Capability as a desirer
2. I draw desiredEffect relationship from Capability to fielded capability with specific measures applied to it.
3. I want to verify if my analysis results meets the desired configuration, however, I cannot link achieved results with the same capability using AchievedEffect relationship.

To be able to compare desired with achieved, first both needs to be paired. Second, I want to see both related to my Capability not only what is desired but more importantly what is achieved. This needs to be improved in UAF spec.

The diagram for FunctionObjectFlow (Figure 136) does not show links to FunctionAction as does FunctionControlFlow (Figure 134). These should be consistent.

Capability is currently a specialization of a SysML Block, but should be a specialization of a SysML Use Case — because the definition of a UAF Capability and a SysML Use Case both describe "what" can be achieved.

Note1: Currently NOTHING in UAF is mapped to a SysML Use Case — and as a result, a core metamodel element in SysML cannot be mapped to UAF models.

Note2: Combining different SysML metaclasses (eg: Use Cases and Blocks) in the UAFP, creates difficulties in numbering elements in a UAF model — when using tools where automatic numbering is managed at the metaclass level.

<submission on behalf of James Johnson>
Cameo includes representations for OperationalAction, ResourceAction, SecurityControlAction and ServiceAction. The UAF Specification does not show these items. Please clarify whether the specification is correct and notify No Magic to remove these items, or update the UAF Specification to include these items.

<submission on behalf of James Johnson>
Cameo includes representations for ServiceFunctionEdge, along with its corresponding flows, ServiceControlFlow and ServiceObjectFlow. The UAF Specification does not show these items, even though it includes a specification for FunctionEdge, along with its corresponding flows,
FunctionControlFlow and FunctionObjectFlow. Please clarify whether the specification is correct and notify No Magic to remove ServiceFunctionEdge, or update the UAF Specification to include these items.

<submitted on behalf of James Johnson>
In the UAF Specification, OperationalExchangeltem and ResourceExchangeltem do not belong to a Metaclass. All UAF elements should belong to a Metaclass.

<Submitted on behalf of James Johnson>
No diagram exists in the UAF Specification for ActualMeasurementKind, LocationKind,ActualMiIestoneKind, RoleKind, LocationTypeKind, OperationalExchangeKind, ResourcelnteractionKind, InformationKind, ResponsibleRoleKind, RuleKind,GeoPoliticalExtentTypeKind, ProjectKind, or WholeLifeConfigurationKind. This is inconsistent with providing diagrams for all other UAF Elements.

ServiceMessageHandler looks to have been removed because AsynchronousMessage is no longer being used. However, now that OperationalSignal, etc, have been added, we need Receptions to link the Signals to the Performers that can handle them. Looks like something important has been missed.

RequiresCompetence has been changed to an Abstraction and set to specialize Allocate but ProvidesCompetence hasn’t. Is that a mistake?

The XMI has ProjectActivityAction extending Activity and CallBehaviourAction – shouldn’t include Activity.

Rs-Rm looks to have a copy and paste error. It shouldn’t have recommended implementations as timeline, IBD and BDD – it should be matrix/tabular and BDD.

It doesn’t make sense to show OrganizationalResources on a Rs-Tx, as there’s a specific Pr-Tx view for that.

The example for the Pr-Tx is incorrect. It’s only supposed to show generalizations, not structure. Structure is supposed to be shown on the Pr-Sr.

Typo in the figure 235 text.

Sv-Tr looks to have a copy and paste error. It shouldn’t have recommended implementations as timeline, IBD and BDD – it should be matrix/tabular and BDD.

St-Rm mapped to IBD doesn’t make sense. It doesn’t show parts anywhere, just instances. This should be mapped to an Object Diagram instead.

Op-Tx has a recommended implementation of BDD – it should be IBD, as it’s for showing ArbitraryConnector relationships (Dependencies) between ConceptRoles (Properties), which you can’t do on a BDD.

Energy is mentioned in a few places in the UAF specification, in particular around Exchanges. However, the Energy stereotype no longer exists and doesn’t appear to have been replaced by anything. I’m think this is a mistake.

Figure 261 for Security Constraints shows SecurityContol and EnhancedSecurityControl, etc, but the elements list does not. I’m assuming the diagram is correct.

Figure 262 shows an invalid relationship. OwnsRisk is shown going between ResourceRole and Risk, when it should go between ResourcePerformer and Risk. OwnsRiskInContext goes between ResourceRole and Risk though… Same for Affects, etc, too.

Listing abstract stereotypes in the Elements list within Annex A, when they’re only shown in the figure to get inherited features is potentially misleading. For example, Figure 128 for Operational Structure lists Asset, but I’m imagining you wouldn’t want every kind of Asset displayed for this View, just the specific specializations that are also listed (e.g. OperationalPerformer, etc).

The View definition sections in Annex A are missing stereotypes from the Elements list if they are shown as “stereotyped relationship” links. For example, Exhibits and IsCapableToPerform are missing from Elements list under figure 218.

Figure 178 for ActualProject shows it specializing ActualOrganizationalResource and Achiever, but the text states ActualPropertySet and Achiever. Based on the XMI, I believe the figure is correct and the text is wrong.

Project is still documenting (both textually and diagrammatically) the UAF Beta 1 version of Project – not the UAF Beta 2 version. In the XMI, Project specializes Block and OrganizationalResource, but in the spec, it still shows Block, Desirer and PropertySet… I’m assuming the XMI is correct, as other ProjectMilestoneRole would be wrong (since that specializes ResourceRole).

More of a question than an issue, but why have extensions for abstract stereotypes? You’re never going to apply them to anything so why bother? If anything, it confuses things as some people argue extensions are inherited…

Enhance is set to subtype DeriveReqt and goes between SecurityControl and EnhancedSecurityControl. This is not allowed in SysML as DeriveReqt is constrained to go between Requirements only (i.e. Classes), but EnhancedSecurityControl extends Activity. Even if the whole extension/inheritance are/aren’t inherited by sub Stereotypes, it doesn’t make sense that EnhancedSecurityControl has a different metatype. I think EnchancedSecurityControl was just not updated when SecurityControl was (i.e. it was left as it was in Beta 1).

Since SecurityProcess and ProjectActivity are subtypes of Function, this would seem to imply that you can use them both wherever you use a Function. It isn’t clear if this is deliberate or an accident… If it’s deliberate, it might be worth mentioning them on things like the view definitions for things like the Op-Pr and Rs-Pr…

The constraints for ResourceInteractionKind.ResourceEnergyFlow doesn’t make sense, as NaturalResource could be (according to the specification) any resource that occurs in nature such as oil, water, gas or coal. Saying that a ResourceExchange that conveys water is not saying it conveys energy… Plus, I’d argue that energy (in terms of an architecture) isn’t something that occurs in nature – it’s “power derived from the utilization of physical or chemical resources, especially to provide light and heat or to work machines”. This takes me back to saying that it seems like Energy should have been left in UAF again…

Figure 51 for EnduringTask is missing inheritance to SysML::Block.
Hmmm. It is in our version. Please check.
I think I know what’s happened here. I’ve been using the UAF Beta 2 spec with change bars. However, that seems to have a few differences to the version of the spec without changebars (just re-downloaded both and checked).

Figure 39: Actual Enterprise Phase: Should Concern.systemConcern be 0..1 like the text implies?

Page 43, under Figure 38: Constraint [e] for Implements.supplier says a ResourceConnector implements an OperationalConnector or ResourceConnector? Why? I understand Resource to Operational but why Resource to Resource? If it’s to show different levels of abstraction, then shouldn’t the same be available for Operational to Operational?

Is it necessary for the definition of FunctionAction (and other actions as well) to extend CallBehaviorAction. What about other actions such as accept event action and wait time action? Could the stereotypes in UAFP which today extend the call behaviour action, be changed to extend the more general action instead?

Consumes relationship direction needs to be reversed ant renamed to "Supports". This change was discussed and agreed some time ago, but for some reason it did not get into UAF 1.0.

Flow properties needs to be stereotyped in the profile to better integrate interfaces to exchanges and signals. Stereotypes are needed for Operational, Service, and Resource Interfaces

Add mapping and text to describe how UAF DMM can be used to represent or transform an archimate architecture into UAF.

Rationale to show how we can conform to NAF via Archimate

Add UAF compliance criteria for Toolvendors

Actual Risk as well as Security Measurements needs to captured in Security Parameters.
Currently Actual Risk is captured as a part of Security Constraints and Security Measurements are are captured as part of Security Taxonomy. It is not following the UAF pattern.

The Ovierview picture (UAF Grid Overview) indocated that two view specifications (Op-Tr and Sc-Tr) have been removed between the beta 1 and beta 2 issues. However, in the actual specification both views are still present.

It seems that the stereotype conformsTo is adopted from UPDM since it is still present in many of the diagrams. However, the stereotype (an extesion of a depedency?) is never defined.

Add a 3-way Resource Traceability Matrix that includes function->Operational Activity->Capability where the matrix intersection displays the associated Capabilities.

"UAF 1.0 has not been subjected to interoperability and interchange testing ..." See attachment for details

"Dean Ristani [KONSTANDIN.RISTANI@forces.gc.ca], the Canadian Co-Chair of the North Atlantic Treaty Organization Architecture Capabilities Team (NATO ACaT), also Canada Chief Architect DND, suggested that UAF architectures would be much more useful if there were a standardized way to build a very general architecture in a specific domain/area (possibly a Reference Architecture), to “inherit” it, and to specialize it as the context or occasion demands...." See attachment for details.

"A. Theory and Level Two DoDAF Conformance. The Unified Architecture Framework (UAF) is required to conform to the Department of Defense Architecture Framework Version 2.02 (DoDAF 2.02) . References include OMG UPDM 3.0 RFP as well as internal UAF 1.0 References. DoDAF 2.02 defines two criteria for conformance (1) DoDAF Meta Model (DM2) and (2) the Physical Exchange Specification (PES).... ". See attachment for details

"A. The Unified Architecture Framework (UAF) is required to conform to the Department of Defense Architecture Framework Version 2.02 (DoDAF 2.02). ..." See attachment for details.

Entered on behalf of Torsten Graeber

Submitted on behalf of Torsten Graeber in response to comments made by UAF group to queries previously submitted queries made by Torsten Graeber, June 2017

System (specialisation of resource architecture) and Software, Hardware (specialisation of physical resource) are disjoint. No whole/part relationship for common superclass ResourcePerformer (or its superclasses) found. Or is ResourceRole to be used for this? UAFP describes ResourceRoleKinds, but they are not included in the DM2.

Yes, Whole-Part is derived from the UML MM. Resource Roles are contextualised usage of ResourcePeformer and there is an Enumerated Type, ResourceRole Kind(Part, Component, Used Configuration,Used Physical Architecture,Human Resource, Platform, System, Sub Organization,Post Role, Responsibility Role,Equipment, Sub System Part,Hosted Software,Artifact Component,Natural Resource Component, Other) in the MM but this is not shown on the diagram. An issue will be raised to reference and show this on the diagram.

CapabilityForTask is duplicated on the Capability diagram (Figure 40)

There should be a depiction for ServiceObjectFlow and ServiceControlFlow, tied to ServiceFunctionAction, to be consistent with OperationalActivityAction and FunctionAction

There is an inconsistent depiction of VisionStatement between the VisionStatement diagram (Figure 44) and the EnterpriseVision diagram (Figure 43)

Class for Operational Port is constrained to be Operational Performer, which means that Operational Architecture cannot own it. Class for Operational Port meeds to be Operational Agent.

1) The UAFElement stereotype has multiple child stereotypes but none appear on the diagram. UAFElement children include:
a. LocationHolder
b. MeasureableElement
c. PropertySet
d. ActualState
e. ISO8601DateTime
f. CapableElement
g. Achiever
h. Desirer
i. ConceptItem
j. SubjectOfOperationalConstraint
k. SubjectOfResourceConstraint
l. SubjectOfSecurityConstraint
m. SubjectOfForecast
n. VersionedElement
o. ProtocolImplementation
p. AssetRole
q. ProjectStatus
r. ActualResourceRole
s. ActualResourceRelationship
t. Architecture
u. Stakeholder

The ServiceFunction diagram (Figure 96) is depicted different then the Operational Activity diagram Figure 78) and the Function diagram (Figure 132). For OperationalActivity and Function the Implements and IsCapableToPerform relationships is depicted with a stereotype while for the ServiceFunction these same relationships ae depicted as stereotyped relationships. There should be some consistency between the three diagrams.

The OperationalExchange diagram (Figure 73) uses Implements as a stereotyped relationship, not as a stereotype There should be some consistency for all diagrams.

AchievedEffect is duplicated on the Achiever diagram (Figure 53)

ProjectRole (Figure 177) does not show as a child of ResourceRole (Figure125)

On Figure 186, there is no line between ActualOrganizationalResource and ActualProjectMilestone

Text for ActualMilestoneKind refers to ActualMeasurements instead of ActualProjectMilestone

ActualOrganizationalResource (Figure 194) has no Metaclass

Multiple diagrams show inconsistencies between themselves, including
a. Metadata (Figure 35) shows a link to UAFElement, but UAFElement (Figure 214) does not show link to Metadata
b. Implements (Figure 38) shows a link to ResourceConnector, but ResourceConnector (Figure 126) does not show link to Implements
c. CapableElement (Figure 30) shows a link to EnterprisePhase, but EnterprisePhase (Figure 42) does not show link to CapableElement
d. ActualEnduringTask (Figure 49) shows a link to ResponsibleFor, but ResponsibleFor (Figure 113) does not show link to ActualEnduringTask
e. ConceptRole (Figure 61) shows a link to HighLevelOperationalConcept, but HighLevelOperationalConcept (Figure 62) does not show link to ConceptRole
f. OperationalStateDescription (Figure 84) shows a link to OperationalAgent, but OperationalAgent (Figure 64) does not show link to OperationalStateDescription
g. ServiceSpecification (Figure 89) shows a link to ServiceInterface, but ServiceInterface (Figure 95) does not show link to ServiceSpecification
h. ServiceMethod (Figure 90) shows a link to ServiceParameter, but ServiceParameter (Figure 91) does not show link to ServiceMethod
i. ServiceParameter (Figure 91) shows a link to OperationalExchange, but OperationalExchange (Figure 74) does not show link to ServiceParameter
j. Consumes (Figure 101) shows a link to OperationalActivity, but OperationalActivity (Figure 78) does not show link to Consumes
k. Command (Figure 107) and Control (Figure 108) show a link to DataElement, but DataElement (Figure 139) does not show links to Command or Control
l. CompetenceForRole (Figure 111) shows a link to Competence, but Competence (Figure 110) does not show link to CompetenceForRole
m. RequiresCompetence (Figure 112) shows a link to OrganizationalResource, but OrganizationalResource (Figure 103) does not show link to RequiresCompetence
n. ResponsibleFor (Figure 113) shows a link to ActualProject, but ActualProject (Figure 185) does not show link to ResponsibleFor
o. ResourceRole (Figure 125) shows a link to ActualOrganizationRole, but ActualOrganizationRole (Figure 201) does not show link to ResourceRole
p. ResourceConnector (Figure 126) shows a link to Environment, but Environment (Figure 15) does not show link to ResourceConnector
q. VersionedElement (Figure 146) shows a link to ActualProjectMilestone, but ActualProjectMilestone (Figure 186) does not show link to VersionedElement
r. ProtocolImplementation (Figure 150) shows a link to Protocol, but Protocol (Figure 189) does not show link to ProtocolImplementation
s. Asset (Figure 151) shows a link to MeasurementSet, but MeasurementSet (Figure 23) does not show link to Asset
t. SecurityProperty (Figure 156) shows a link to AssetRole, but AssetRole (Figure 170) does not show link to SecurityProperty
u. ActualRisk (Figure 163) shows a link to ActualResponsibleResource, but ActualResponsibleResource (Figure 199) does not show link to ActualRisk
v. OwnsRisk (Figure 172) shows a link to OrganizationalResource, but OrganizationalResource (Figure 103) does not show link to OwnsRisk
w. Project (Figure 174) shows a link to OrganizationalResource, but OrganizationalResource (Figure 103) does not show link to Project
x. ActualProject (Figure 184) shows a link to ActualResponsibleResource, but ActualResponsibleResource (Figure 199) does not show link to ActualProject
y. ActualProjectMilestone (Figure 186) shows a link to ActualOrganizationalResource, but ActualOrganizationalResource (Figure 194) does not show link to ActualProjectMilestone
z. ActualResponsibility (Figure 198) shows a link to ActualOrganizationalResource, but ActualOrganizationalResource (Figure 194) does not show link to ActualResponsibility
aa. ActualResourceRole (Figure 202) shows a link to ResourceRole, but ResourceRole (Figure 125) does not show link to ActualResourceRole
bb. OwnsProcess (Figure 209) shows a link to OperationalActivity, but OperationalActivity (Figure 78) does not show link to OwnsProcess

Constraints OwnsProcess.* should be renamed to OwnsRiskInContext.*