The recommended implementation for Operational Taxonomy should include ibd:s since ConceptRoles are Properties.
Current drescription is "An abstraction relationship relating an ActualOrganization to an ActualEnterprisePhase to denote that the ActualOrganization plays a role or is a stakeholder in an ActualEnterprisePhase."
However, since a stakeholder can also be an OrganizationalResource (see definition in Figure 7.208) maybe the OrganizationInEnterprise could also relate an OrganizationalResource to an ActualEnterprisePhase? Otherwise, only a subset of the stakeholders can be related to an ActualEnterprisePhase.
In the description of Forecast it says "...transition from one Asset,...". However Asset is not a specialization of SubjectOfForecast.
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.
<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.
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 Lar's diagram in the appropriate places in the documentation.
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.
Add a 3-way Resource Traceability Matrix that includes function->Operational Activity->Capability where the matrix intersection displays the associated Capabilities.
"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
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.
The view specifications Operational Structure and Resources Structure should be consistent with each other. Why does the former include OperationalParameter but the latter does not include ResourceParameter? Also, OperationalActivity is included in the former but Function is omitted in the latter.
Two different abstractions are allowed between Capability and ActualEnduringTask. These are: Exhibits and CapabilityForTask. What is the motivation of having two different relationships? Do we need both? Perhaps it is the ActualEnduringTask that should not be a CapableElement (and hence the Exhibits relationship that should go).
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.
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