${taskforce.name} Avatar
  1. OMG Task Force

Unified Architecture Framework (UAF) 1.1 RTF — Closed Issues

  • Key: UAF11
  • Issues Count: 150
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
UAF11-11 Add a 3-way Resource Traceability Matrix as a standard view UAF 1.0 UAF 1.1 Deferred closed
UAF11-48 ResourceInteractionKind should really be called ResourceExchangeKind. UAF 1.0 UAF 1.1 Resolved closed
UAF11-276 Improve quality of DMM diagrams UAF 1.0 UAF 1.1 Resolved closed
UAF11-294 modify title and text for DMM diagram legend UAF 1.0 UAF 1.1 Resolved closed
UAF11-86 Sv-Pr implementation should be BDD and Activity diagram and table UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-82 Mapping for UAF views to DoDAF/MODAF Views problem UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-99 Sc-Tx should be mapped to BDD UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-98 Implementation for Sv-Tr should be tabular. UAF 1.0 UAF 1.1 Resolved closed
UAF11-94 Pr-Ct mapping should include the OV-4 Actual as a potential mapping. UAF 1.0 UAF 1.1 Resolved closed
UAF11-93 Inconsistent naming for State Diagrams UAF 1.0 UAF 1.1 Resolved closed
UAF11-87 Ov-Ct and Sv-Ct recommended implementation should both be BDD UAF 1.0 UAF 1.1 Resolved closed
UAF11-106 OV-1a should not be mapped as Op-Sr and SmOV UAF 1.0 UAF 1.1 Resolved closed
UAF11-105 OV-1b should be mapped to the SmOV UAF 1.0 UAF 1.1 Resolved closed
UAF11-103 Sd mappings are wrong in Annex B: UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-102 Pj mappings are wrong in Annex B UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-110 The changes to KnownResource don’t make any sense to me. UAF 1.0 UAF 1.1 Resolved closed
UAF11-107 OV-1c and SV-7 are better fits for Pm-Me. UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-124 Document inconsistency between EnterprisePhase and CapableElement UAF 1.0 UAF 1.1 Resolved closed
UAF11-123 Document inconsistency between AssetRole and SecurityProperty UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-121 Inconsistency between text/figure for ResponsibleRoleKind UAF 1.0 UAF 1.1 Resolved closed
UAF11-128 Inclusion of additional CapableElements UAF 1.0 UAF 1.1 Resolved closed
UAF11-53 InformationElements and DataElements location and constraints. UAF 1.0 UAF 1.1 Resolved closed
UAF11-49 OperationalExchange.trustlevel should be called OperationalExchange.trustLevel UAF 1.0 UAF 1.1 Resolved closed
UAF11-46 ResponsibleFor.ResponsibleRoleKind tag wrong. UAF 1.0 UAF 1.1 Resolved closed
UAF11-77 UAFP Inheritance from SysML issues. UAF 1.0 UAF 1.1 Resolved closed
UAF11-76 Operational agent should own operational operation. UAF 1.0 UAF 1.1 Resolved closed
UAF11-63 Figure 179 for ActualProjectMilestone error UAF 1.0 UAF 1.1 Resolved closed
UAF11-59 SubjectOfSecurityConstraint doesn’t allow you to constrain any elements from the SecurityDomain UAF 1.0 UAF 1.1 Resolved closed
UAF11-57 SecurityControlFamily has a constraint for annotedElement UAF 1.0 UAF 1.1 Resolved closed
UAF11-73 CapabIlityProperty should be shown with Dependencies UAF 1.0 UAF 1.1 Resolved closed
UAF11-70 Figure 260 for Security Processes issues. UAF 1.0 UAF 1.1 Resolved closed
UAF11-69 Should have an IBD version for the Operational Taxonomy view UAF 1.0 UAF 1.1 Resolved closed
UAF11-300 Update DMM sections on UAF grid, Domain interelatiohips and descriptions UAF 1.0 UAF 1.1 Resolved closed
UAF11-298 Update and add sections 1 through 6.4 from UAFP and move to UAF DMM document UAF 1.0 UAF 1.1 Resolved closed
UAF11-80 Op-Cn should be mapped to OV-2 and OV-3 UAF 1.0 UAF 1.1 Resolved closed
UAF11-15 Required Environment needs to be individual as opposed to type UAF 1.0b2 UAF 1.1 Resolved closed
UAF11-16 Security Property name change UAF 1.0b2 UAF 1.1 Resolved closed
UAF11-21 Add 3D representation of domain connectivity UAF 1.0 UAF 1.1 Resolved closed
UAF11-20 Update UAF Grid UAF 1.0 UAF 1.1 Resolved closed
UAF11-30 UAF is not considered DoDAF 2.02 compliant UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-25 NAF 4 conformance UAF 1.0 UAF 1.1 Resolved closed
UAF11-7 Proof of DoDAF Conformance – Meta Model – DM2; LFL Issue #1 (11 September 2017). UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-43 Figure 53 for Achiever shows AchievedEffect twice. UAF 1.0 UAF 1.1 Resolved closed
UAF11-39 EnterpriseVision.statement should be derived or removed. UAF 1.0 UAF 1.1 Resolved closed
UAF11-36 Actual Enterprise Phase: Concern.systemConcern incorrect name. UAF 1.0 UAF 1.1 Resolved closed
UAF11-35 Multiplicity wrong for Actual Enterprise Phase: forecastPeriod tag UAF 1.0 UAF 1.1 Resolved closed
UAF11-33 Constraints [c] and [d] for Implements.supplier should be merged UAF 1.0 UAF 1.1 Resolved closed
UAF11-160 There should be a depiction for ServiceObjectFlow and ServiceControlFlow, UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-157 Multiple diagrams show inconsistencies between themselves UAF 1.0 UAF 1.1 Resolved closed
UAF11-85 There is no example of an Op-Tr. UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-84 Worked example should have all diagrams. UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-83 Worked example structure needs changing UAF 1.0 UAF 1.1 Resolved closed
UAF11-81 Inconsistency between example and specification UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-100 Sc-Pr example doesn’t match the specification. UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-92 Pr-Sr should be OV-4 typical UAF 1.0 UAF 1.1 Resolved closed
UAF11-89 There’s no example of the Sv-Rm view. UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-104 Ar-Sr should be mapped to BDD. UAF 1.0 UAF 1.1 Resolved closed
UAF11-111 OwnsProcess should be shown on Figure 76. UAF 1.0 UAF 1.1 Resolved closed
UAF11-114 ServiceOperation should be shown on Figure 89. UAF 1.0 UAF 1.1 Resolved closed
UAF11-112 ProtocolImplementation should be shown on Figure 182. UAF 1.0 UAF 1.1 Resolved closed
UAF11-204 Operational Architecture cannot own Operational Port UAF 1.0 UAF 1.1 Resolved closed
UAF11-148 2) The ServiceFunction diagram (Figure 96) is depicted different then the Operational Activity diagram Figure 78) and the Function diagram (Figure 132) UAF 1.0 UAF 1.1 Resolved closed
UAF11-147 The UAFElement stereotype has multiple child stereotypes but none appear on the diagram. UAF 1.0 UAF 1.1 Resolved closed
UAF11-156 ActualOrganizationalResource (Figure 194) has no Metaclass UAF 1.0 UAF 1.1 Resolved closed
UAF11-155 Text for ActualMilestoneKind refers to ActualMeasurements instead of ActualProjectMilestone UAF 1.0 UAF 1.1 Resolved closed
UAF11-154 On Figure 186, there is no line between ActualOrganizationalResource and ActualProjectMilestone UAF 1.0 UAF 1.1 Resolved closed
UAF11-153 ProjectRole (Figure 177) does not show as a child of ResourceRole (Figure125) UAF 1.0 UAF 1.1 Resolved closed
UAF11-152 Inconsistent depiction of VisionStatement UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-150 CapabilityForTask is duplicated on the Capability diagram (Figure 40) UAF 1.0 UAF 1.1 Resolved closed
UAF11-149 Diagram Consistency UAF 1.0 UAF 1.1 Resolved closed
UAF11-118 Doc inconsistency between ActualOrganizationalResource & ActuralResponsibility UAF 1.0 UAF 1.1 Resolved closed
UAF11-125 Dual inheritance for ActualService is confusing UAF 1.0 UAF 1.1 Resolved closed
UAF11-122 Unclear relationship between ActualProject and ActualPropertySet UAF 1.0 UAF 1.1 Resolved closed
UAF11-38 Figure 40 – Capability, shows CapabilityForTask twice UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-55 Figure 163 for Risk doesn’t show a specialization to Block UAF 1.0 UAF 1.1 Resolved closed
UAF11-52 Figure 140 for DataModel doesn’t show an extension to a UML type. UAF 1.0 UAF 1.1 Resolved closed
UAF11-47 The ResourceRole.RoleKind tag should start with a lowercase letter. UAF 1.0 UAF 1.1 Resolved closed
UAF11-45 Figure103 for OrganizationalResource is missing some relationships. UAF 1.0 UAF 1.1 Resolved closed
UAF11-75 Figure 277 for Services Connectivity should show ServiceSpecificationRole UAF 1.0 UAF 1.1 Resolved closed
UAF11-65 ActualService doesn’t need to directly inherit from ActualPropertySet UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-64 Figure 182 for Protocol should show the relationship to implementers. UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-60 SubjectOfSecurityConstraint is specialized by Asset but not AssetRole UAF 1.0 UAF 1.1 Resolved closed
UAF11-56 SecurityControl can't be a specialization of PropertySet and Requirement UAF 1.0 UAF 1.1 Resolved closed
UAF11-74 Figure 277 for Services Connectivity should show provided/required interfaces UAF 1.0 UAF 1.1 Resolved closed
UAF11-66 Figure 76 for OperationalActivity is missing OwnsProcess. UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-95 Pr-Tx should not show structure, just generalizations. UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-101 Tx and Sr views overlap. UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-108 The OwnsRiskInContext has the wrong constraint text UAF 1.0 UAF 1.1 Resolved closed
UAF11-5 Make the relationship between the definition Statemachines (currently implicitly related to UML statemachines) and the definition of ResourceStateMachines more explicit for readers of the UAF. UAF 1.0 UAF 1.1 Resolved closed
UAF11-3 Make the relationship between UML composition and aggregation (for the information model) and the use of whole/part in the UAF more explicit for readers of the UAF specification document. UAF 1.0 UAF 1.1 Resolved closed
UAF11-23 Update descriptions for MetaData row of Grid UAF 1.0 UAF 1.1 Resolved closed
UAF11-13 Constraint uses wrong name UAF 1.0b2 UAF 1.1 Duplicate or Merged closed
UAF11-151 AchievedEffect is duplicated on the Achiever diagram (Figure 53) UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-117 Identify all MeasurableElements in a comprehensive list or table UAF 1.0 UAF 1.1 Resolved closed
UAF11-116 Provided complete list of UAF PropertySets in table UAF 1.0 UAF 1.1 Resolved closed
UAF11-44 Figure 88 for ServiceMethod inconsistent UAF 1.0 UAF 1.1 Resolved closed
UAF11-41 Problem with Figure 214 for Strategic Roadmap UAF 1.0 UAF 1.1 Duplicate or Merged closed
UAF11-40 Problems with Figure 49 UAF 1.0 UAF 1.1 Resolved closed
UAF11-32 Constraint text for Figure 34 is incorrect. UAF 1.0 UAF 1.1 Resolved closed
UAF11-78 Energy should be restored to the UAF. UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-62 ActualProject specialization wrong UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-72 Security Constraints inconsistency UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-71 Figure 262 shows an invalid relationship UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-68 Abstract stereotypes in the Elements list within Annex A UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-159 The diagram for OperationalObjectFlow does not show links to OperationalActivityAction UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-158 The diagram for FunctionObjectFlow does not show links to FunctionAction UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-79 Op-Tx should be IBD UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-97 Rs-Rm implementations should be matrix/tabular and BDD. UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-91 Typo in the figure 235 text. UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-90 Sv-Tr should be matrix/tabular and BDD. UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-88 St-Rm should be mapped to an Object Diagram UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-109 XMI has ProjectActivityAction and CallBehaviourAction – shouldn’t include Activity. UAF 1.0 UAF 1.1 Resolved closed
UAF11-115 Problem with ServiceMessageHandler UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-113 ProvidesCompetence should also be an abstraction. UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-2 Make the relationship between UML and the decomposition of Activity based elements more explicit for readers of the UAF specification document. UAF 1.0 UAF 1.1 Resolved closed
UAF11-1 Make the relationship between UML and BPMN for the representation the BPMN Start Event and End Event more explicit for readers of the UAF specification document. UAF 1.0 UAF 1.1 Resolved closed
UAF11-19 ResponsibleFor relationship from Actual Responsible Resource to Actual Project Milestone is missing in the Responsible For diagram UAF 1.0b2 UAF 1.1 Duplicate or Merged closed
UAF11-18 Unified Architecture Framework (UAF), The Domain Metamodel document should not be marked as Appendix A for UAFP specification UAF 1.0b2 UAF 1.1 Resolved closed
UAF11-28 Enteprise Phase should not be a subtype of capable element UAF 1.0b2 UAF 1.1 Resolved closed
UAF11-120 Missing Metaclass designation in documentation UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-119 No diagram representation exists for some model elements UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-127 Inconsistency between spec and implementation UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-129 Capabilty generalization should be Use Case UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-42 Figure 51 for EnduringTask is missing inheritance to SysML::Block UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-37 Actual Enterprise Phase: Concern.systemConcern should be 0..1 UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-34 Inconsistency with Constraint [e] for Implements.supplier UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-54 Problem with EnhancedSecurityControl inheritance UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-51 Inconsistency with SecurityProcess and ProjectActivity UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-50 Constraints for ResourceInteractionKind.ResourceEnergyFlow don’t make sense UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-61 Inconsistency with Project UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-58 Abstract stereotypes shouldn't have extensions. UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-12 conformsTo is missing UAF 1.0b1 UAF 1.1 Closed; No Change closed
UAF11-96 OrganizationalResources should not be on a Rs-Tx UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-14 Ovierview picture (UAF Grid Overview) UAF 1.0b2 UAF 1.1 Closed; Out Of Scope closed
UAF11-6 Provide Vendor Neutral exchange format of the UAF DMM UAF 1.0 UAF 1.1 Deferred closed
UAF11-4 Add the element ResourceRoleKinds to the relevant diagrams in the UAF DMM UAF 1.0 UAF 1.1 Deferred closed
UAF11-17 Actual Risk should be captured in Security Parameters rather than Security Constraints UAF 1.0b2 UAF 1.1 Deferred closed
UAF11-24 UAF compliance criteria for Toolvendors UAF 1.0 UAF 1.1 Closed; Out Of Scope closed
UAF11-22 Add the UAF Metamodel on a page UAF 1.0 UAF 1.1 Deferred closed
UAF11-31 Definition of FunctionAction is too tight UAF 1.0b2 UAF 1.1 Closed; No Change closed
UAF11-29 Consumes relationship is facing wrong direction UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-27 Stereotypes for flowProperties UAF 1.0b2 UAF 1.1 Deferred closed
UAF11-26 Concpetual mapping between UAF DMM and Archimate elements UAF 1.0 UAF 1.1 Deferred closed
UAF11-10 Interoperability and Interchange Testing; LFL Issue #4 (11 September 2017) UAF 1.0 UAF 1.1 Closed; Out Of Scope closed
UAF11-9 Support Extensibility and Specialization of Architectures (Inheritance and Extension of Architectures; LFL Issue #3 (11 September 2017) UAF 1.0 UAF 1.1 Closed; No Change closed
UAF11-8 Increase DoDAF Conformance – PES Implementation; LFL Issue #2 (11 September 2017). UAF 1.0 UAF 1.1 Deferred closed
UAF11-67 The View definition in Annex A are missing stereotypes from the Elements list UAF 1.0 UAF 1.1 Deferred closed
UAF11-296 Should SubjectOfForecast be an Asset instead of ResourcePerformer? UAF 1.0 UAF 1.1 Deferred closed
UAF11-227 Achiever cannot be the same as Desirer UAF 1.0 UAF 1.1 Deferred closed
UAF11-126 Inconsistency between spec and implementation UAF 1.0 UAF 1.1 Deferred closed

Issues Descriptions

Add a 3-way Resource Traceability Matrix as a standard view

  • Key: UAF11-11
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

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

  • Reported: UAF 1.0 — Mon, 25 Sep 2017 19:59 GMT
  • Disposition: Deferred — UAF 1.1
  • Disposition Summary:

    Deferred to future versions of UAF

    Deferred to future versions of UAF

  • Updated: Tue, 10 Dec 2019 23:24 GMT
  • Attachments:
    • Example.xlsx 30 kB (application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)

ResourceInteractionKind should really be called ResourceExchangeKind.

  • Key: UAF11-48
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    ResourceInteractionKind should really be called ResourceExchangeKind.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 07:13 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    ResourceIntercationKind renamed to ResourceExchangeKind

    ResourceIntercationKind renamed to ResourceExchangeKind

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Improve quality of DMM diagrams

  • Key: UAF11-276
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 17 Jan 2019 14:45 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Multiple diagram changes were done to improve readability of the document

    Multiple diagram changes were done to improve readability of the document. At the same time cosmetic adjustments were done on Profile document diagrams.

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

modify title and text for DMM diagram legend

  • Key: UAF11-294
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    modify title and text for DMM diagram legend

  • Reported: UAF 1.0 — Tue, 30 Apr 2019 20:48 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    modify title and text for DMM diagram legend

    modify title and text for DMM diagram legend

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Sv-Pr implementation should be BDD and Activity diagram and table

  • Key: UAF11-86
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:23 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Update and modify desccription text for Sv-Pr MM and Profile

    Update and modify desccription text for Sv-Pr MM and Profile
    not required

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Mapping for UAF views to DoDAF/MODAF Views problem

  • Key: UAF11-82
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:03 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    StV-6 is now only mapped to Operational Traceability

    StV-6 is now only mapped to Operational Traceability
    Looks ok to me

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Sc-Tx should be mapped to BDD

  • Key: UAF11-99
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 03:16 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Update and modify desccription text for Sc Tx MM and Profile

    Update and modify desccription text for Sc Tx MM and Profile so it is implemented as BDD

    Not an issue as far as i can i see

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Implementation for Sv-Tr should be tabular.

  • Key: UAF11-98
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 03:13 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Recommended Implementations updated for Sv-Tr

    Changed from:
    "Recommended Implementation: timeline, SysML Block Definition Diagram, SysML Internal Block Diagram"
    to
    "Recommended Implementation: tabular or matrix format."

  • Updated: Tue, 8 Oct 2019 17:49 GMT

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

  • Key: UAF11-94
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:54 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

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

    Update text

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Inconsistent naming for State Diagrams

  • Key: UAF11-93
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:51 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    SysML State Diagram replaced with SysML State Machine Diagram

    SysML State Diagram replaced with SysML State Machine Diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Ov-Ct and Sv-Ct recommended implementation should both be BDD

  • Key: UAF11-87
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:28 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Update and modify desccription text for Op-Ct, Rs-Ct and Sc-Ct MM and Profile

    Update and modify desccription text for Op-Ct, Rs-Ct and Sc-Ct MM and Profile to be implemented as either IBD or Table(s)

  • Updated: Tue, 8 Oct 2019 17:49 GMT

OV-1a should not be mapped as Op-Sr and SmOV

  • Key: UAF11-106
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 04:30 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    *OV-1a should not be mapped as Op-Sr and SmOV *

    Update traceability matrix, but yes OV1-a should be mapped to SM Ov as is it can be overview of scenario

  • Updated: Tue, 8 Oct 2019 17:49 GMT

OV-1b should be mapped to the SmOV

  • Key: UAF11-105
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 04:28 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    OV-1b should be mapped to the SmOV

    Update tracreability matrix

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Sd mappings are wrong in Annex B:

  • Key: UAF11-103
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 03:32 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Sd mappings are wrong in Annex B:

    Not an issue

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Pj mappings are wrong in Annex B

  • Key: UAF11-102
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 03:30 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Pj mappings are wrong in Annex B

    Not an issue

  • Updated: Tue, 8 Oct 2019 17:49 GMT

The changes to KnownResource don’t make any sense to me.

  • Key: UAF11-110
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 04:38 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Definition for Known Resource revised

    Definition for Known Resource revised

  • Updated: Tue, 8 Oct 2019 17:49 GMT

OV-1c and SV-7 are better fits for Pm-Me.

  • Key: UAF11-107
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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: UAF 1.0 — Sat, 13 Jan 2018 04:33 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    OV-1c and SV-7 are better fits for Pm-Me

    Looking into UAF traceability document it is exactly the same mapping as requested. However, there is a problem with Figure 6.3 - Overlay of MODAF Views onto UAF/P Grid that needs to be updated.

    the table looks ok to me GJB

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Document inconsistency between EnterprisePhase and CapableElement

  • Key: UAF11-124
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

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

  • Reported: UAF 1.0 — Fri, 2 Feb 2018 14:57 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Capable Element shown in Enterprise Phase Diagram

    Capable Element is added to Capable Element Diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Document inconsistency between AssetRole and SecurityProperty

  • Key: UAF11-123
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

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

  • Reported: UAF 1.0 — Fri, 2 Feb 2018 14:53 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Security Property does not exist anymore

    SecurityProperty was removed from the profile as a result of solving UAF11-16 issue. This issue is no longer relevant.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Inconsistency between text/figure for ResponsibleRoleKind

  • Key: UAF11-121
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

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

  • Reported: UAF 1.0 — Fri, 2 Feb 2018 14:48 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Text updated

    Text changed for Resource Role Kind. Instead of "ResposibleRole"it is now "ResponsibleFor". Also typo corrected on ResponsibleFor documentation.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Inclusion of additional CapableElements

  • Key: UAF11-128
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

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

  • Reported: UAF 1.0 — Fri, 2 Feb 2018 15:17 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Actual Resource and Actual Service are now Capable Elements

    It makes perfect sense to allow Exhibits relationship to be drawn between Actual Resource and Capability. The same applies to Actual Service as the Service Specification is Capable element. However, in case of Actual Project, we do not agree. Actual Project as well as project cannot directly exhibit capability. As for Achiever, all subtypes of achiever are already Capable elements except Actual Project. As for Desirer it would not make sense to have it as Capable Element because one of its subtypes is Capability. Capability cannot exhibit Capability.

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

InformationElements and DataElements location and constraints.

  • Key: UAF11-53
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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?

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 07:26 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Data Model moved to Metadata and made a specialization of Subject of Resource Constraint

    Data Model and Data Model Kind moved to Metadata and made a specialization of Subject of Resource Constraint

  • Updated: Tue, 8 Oct 2019 17:49 GMT

OperationalExchange.trustlevel should be called OperationalExchange.trustLevel

  • Key: UAF11-49
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 07:15 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    trustlevel changed to trustLevel

    trustlevel changed to trustLevel

  • Updated: Tue, 8 Oct 2019 17:49 GMT

ResponsibleFor.ResponsibleRoleKind tag wrong.

  • Key: UAF11-46
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 07:09 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    ResponsibleRoleKind tag now starts from lowercase

    ResponsibleRoleKind tag now starts from lowercase to be consistent with other tags. The same is done with projectKind tag name in DMM.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

UAFP Inheritance from SysML issues.

  • Key: UAF11-77
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:41 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    The text is updated (see description)

    Replace:
    "UAFP imports the entire SysML profile and contains a set of constraints that specify which SysML stereotypes are applied to the UAFP elements. This is intended to provide more seamless integration with system modeling using SysML and to be able to fully leverage the capabilities of SysML in UAFP. An example of this is the integration of Requirements into the UAFP and also the use of Parametric Diagrams and integration of elements based upon instance specifications to allow the assessment of measures within an architecture developed using UAFP."
    with
    "UAFP imports the entire SysML profile and a number of UAFP stereotypes inherit from SysML stereotypes. This is intended to provide more seamless integration with system modeling using SysML and to be able to fully leverage the capabilities of SysML in UAFP. An example of this is the integration of Requirements into the UAFP and also the use of Parametric Diagrams and integration of elements based upon instance specifications to allow the assessment of measures within an architecture developed using UAFP."

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Operational agent should own operational operation.

  • Key: UAF11-76
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:38 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Operational Method needs to be owned by Operational Agent

    Operational Method ownership changed from Operational Performer to Operational Agent. Operational Performer inherits ownership of Operational Methods from Operational Agent. This appeared to be an issue in the profile only.

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Figure 179 for ActualProjectMilestone error

  • Key: UAF11-63
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:07 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Actual Organizational Resource removed from Diagram

    Actual Organizational Resource removed from Diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT

SubjectOfSecurityConstraint doesn’t allow you to constrain any elements from the SecurityDomain

  • Key: UAF11-59
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 18:59 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Security Process added as a subtype of Subject of Security Constraint

    Most of Security Domain elements are indirect subtypes of Subject of Security Constraint. The only really missing part was Security Process, which was added as a subtype of Subject of Security Constraint.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

SecurityControlFamily has a constraint for annotedElement

  • Key: UAF11-57
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 18:54 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Incorrect constraint removed

    Incorrect constraint removed from SecurityControlFamily

  • Updated: Tue, 8 Oct 2019 17:49 GMT

CapabIlityProperty should be shown with Dependencies

  • Key: UAF11-73
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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?

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:26 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Role Dependency added to Strategic Connectivity

    Role Dependency added to Strategic Connectivity. CapabilityProperty renamed to CapabilityRole to reflect DMM

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Figure 260 for Security Processes issues.

  • Key: UAF11-70
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:20 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Security Control Properties removed from Security Processes Diagram

    Most of the comments are already addressed except for Security Control Properties that needs to be removed from Diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Should have an IBD version for the Operational Taxonomy view

  • Key: UAF11-69
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:18 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Recommended implementations of Operational Taxonomy now includes SysML ibd

    Recommended implementations of Operational Taxonomy now includes SysML ibd

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Update DMM sections on UAF grid, Domain interelatiohips and descriptions

  • Key: UAF11-300
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Diagrams and text out of date.

  • Reported: UAF 1.0 — Fri, 10 May 2019 17:47 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Update DMM sections on UAF grid, Domain interelatiohips and descriptions

    delete original section 1 in DMM 17-12-02 and add content of UAF 11 DMM 7-9. docx

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Update and add sections 1 through 6.4 from UAFP and move to UAF DMM document

  • Key: UAF11-298
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Update OMG boiler plate and add new sections describing UAF background, conformance, references, terms and definitions and symbols

  • Reported: UAF 1.0 — Fri, 10 May 2019 16:42 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Update and add sections 1 through 6.5 from UAFP and move to UAF DMM document

    delete and update sections 1-6.5 from 17-12-01
    add text in UAF 11 DMM sect 1-6.4.docx to front of UAF DMM document
    Should cover sections 1-6.4
    add text in UAFP introduction.docx to front UAFP document

    Will need to renumber the CB document

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Op-Cn should be mapped to OV-2 and OV-3

  • Key: UAF11-80
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 01:53 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Operational Connectivity is mapped to OV-2 and OV-3

    Operational Connectivity is mapped to OV-2 and OV-3 as both capture Operational Exchanges between OperationalPerformers.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Required Environment needs to be individual as opposed to type

  • Key: UAF11-15
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    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.

  • Reported: UAF 1.0b2 — Mon, 4 Dec 2017 20:03 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Required Environment changed to Actual Environment

    Required Environment changed to Actual Environment

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Security Property name change

  • Key: UAF11-16
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

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

  • Reported: UAF 1.0b2 — Mon, 4 Dec 2017 23:51 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Information Role and Data Role elements introduced to substitute Security Property

    Security Property was introduced in UAF to capture whole-part between Operational Performers and Information Elements and Resource Performers and Data Elements. The name of the Security Property was misleading and it had to be changed.

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Add 3D representation of domain connectivity

  • Key: UAF11-21
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    From UAF patterns presentation.

  • Reported: UAF 1.0 — Wed, 6 Dec 2017 19:29 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Add 3D UAF representation

    Needed to give an overview of the logical relationships between the UAF Aspects

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Update UAF Grid

  • Key: UAF11-20
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

  • Reported: UAF 1.0 — Wed, 6 Dec 2017 19:28 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Update UAF Grid

    Update grid to take into account NAF 4

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

UAF is not considered DoDAF 2.02 compliant

  • Key: UAF11-30
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 7 Dec 2017 00:20 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Duplicates UAF11-7

    Duplicates UAF11-7

  • Updated: Tue, 8 Oct 2019 17:49 GMT

NAF 4 conformance

  • Key: UAF11-25
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

  • Reported: UAF 1.0 — Wed, 6 Dec 2017 19:35 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Updated NAF 4 Grid Graphic and Table

    Updated Grid and Table

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Proof of DoDAF Conformance – Meta Model – DM2; LFL Issue #1 (11 September 2017).

  • Key: UAF11-7
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 9 Sep 2017 23:30 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Proof of DoDAF conformance

    We have mappings in the UAF documentation (Appendix B, formal/17-12-03) that map UAFP elements to DODAF 2 elements and also to map UAF/P Viewpoints/Views to DODAF 2 Viewpoints/Views.

    This mapping is complete and shows that UAF/P can implement the development of DODAF 2 architectures and also fulfill the need for fit for purpose views.

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Figure 53 for Achiever shows AchievedEffect twice.

  • Key: UAF11-43
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    Figure 53 for Achiever shows AchievedEffect twice.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 07:02 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Diagram updated to show Achieved Effect once

    Duplication of Achieved Effect shape removed from the Achieved Effect diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

EnterpriseVision.statement should be derived or removed.

  • Key: UAF11-39
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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…

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 06:47 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Vision Statement is made derived

    Vision Statement is made derived

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Actual Enterprise Phase: Concern.systemConcern incorrect name.

  • Key: UAF11-36
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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…

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 06:39 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Name of the association end changed on both sides of the association

    Name of the role change on both sides of the association:
    -systemConcern changed to enterprisePhase
    -concern role name added on the other side of association
    -association made navigable on both ends
    -multiplicity set to many to many

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Multiplicity wrong for Actual Enterprise Phase: forecastPeriod tag

  • Key: UAF11-35
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 06:36 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Multiplicity changed to 0..1

    One or zero Actual Enterprise Phases can be associated with one Forecast.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Constraints [c] and [d] for Implements.supplier should be merged

  • Key: UAF11-33
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 06:18 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Constraint body updated

    Constraints [c] and [d] for implements supplier merged.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

There should be a depiction for ServiceObjectFlow and ServiceControlFlow,

  • Key: UAF11-160
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

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

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 15:08 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Duplicates UAF11-126

    Duplicates UAF11-126

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Multiple diagrams show inconsistencies between themselves

  • Key: UAF11-157
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

    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

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 15:06 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    All comments resolved

    The list of actions taken:
    UAFElement Diagram now shows link to Metadata
    Resource Connector Diagram now shows links to ResourceMessage and Implements
    Responsible For removed from Actual Enduring Task Diagram
    ConceptRole added to HighLevelOperationalConcept Diagram
    OperationalStateDescription added to OperationalAgent Diagram
    ServiceSpecification added to ServiceInterface Diagram
    ServiceParameter added to OperationalExchange Diagram
    Consumes added to OperationalActivity Diagram
    Command and Control added to DataElement diagram
    CompetenceForRole added to Competence diagram
    ResourceRole added to ActualOrganizationalRole diagram
    Resource connector added to Environment diagram
    VersionedElement added to ActualProjectMilestone Diagram
    Asset added to MeasurementSet Diagram
    ActualRisk added to ActualResponsibleResource Diagram
    ActualResourceRole added to ResourceRole Diagram

    Other issues were duplicates and were already resolved by solving other issues.

    Affected Diagrams:
    Profile
    UAFElement
    ResourceConnector
    ActualEnduringTask
    HighLevelOperationalConcept
    OperationalAgent
    ServiceInterface
    OperationalExchange
    OperationalActivity
    DataElement
    Competence
    ActualOrganizationalRole
    Environment
    ActualProjectMilestone
    MeasurementSet
    ActualResponsibleResource
    ResourceRole

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

There is no example of an Op-Tr.

  • Key: UAF11-85
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    There is no example of an Op-Tr.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:20 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Merged with UAF11-83

    Merged with UAF11-83

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Worked example should have all diagrams.

  • Key: UAF11-84
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:18 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Merged with UAF11-83

    Merged with UAF11-83

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Worked example structure needs changing

  • Key: UAF11-83
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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…

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:16 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Refactor example model

    Refactor example model

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Inconsistency between example and specification

  • Key: UAF11-81
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 01:57 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Merged with UAF11-83

    Update descriptions in document

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Sc-Pr example doesn’t match the specification.

  • Key: UAF11-100
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 03:19 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Merged with UAF11-83

    Merged with UAF11-83

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Pr-Sr should be OV-4 typical

  • Key: UAF11-92
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:50 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Personnel Structure is now mapped to OV-4 Typical only

    Personnel Structure is now mapped to OV-4 Typical only
    In UAF Traceability doc.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

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

  • Key: UAF11-89
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:35 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Merged with UAF11-83

    Merged with UAF11-83

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Ar-Sr should be mapped to BDD.

  • Key: UAF11-104
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 03:34 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Ar-Sr recommended implementation is now BDD only

    In UAFP 17-12-01
    A.2.9 View Specifications::Actual Resources
    Text changed from
    "Recommended Implementation: SysML Block Definition Diagram, SysML Internal Block Diagram."
    to
    "Recommended Implementation: SysML Block Definition Diagram."

  • Updated: Tue, 8 Oct 2019 17:49 GMT

OwnsProcess should be shown on Figure 76.

  • Key: UAF11-111
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    OwnsProcess should be shown on Figure 76.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 04:40 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Owns Process added to Operational Activity diagram

    Owns Process added to Operational Activity diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

ServiceOperation should be shown on Figure 89.

  • Key: UAF11-114
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    ServiceOperation should be shown on Figure 89.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 04:46 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Service Method added to Service Parameter diagram

    Service Method added to Service Parameter diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

ProtocolImplementation should be shown on Figure 182.

  • Key: UAF11-112
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    ProtocolImplementation should be shown on Figure 182.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 04:42 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Protocol Implementation added to Protocol diagram

    Protocol Implementation added to Protocol diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Operational Architecture cannot own Operational Port


2) The ServiceFunction diagram (Figure 96) is depicted different then the Operational Activity diagram Figure 78) and the Function diagram (Figure 132)

  • Key: UAF11-148
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

    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.

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 15:01 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Service Function Diagram updated to be consistent with Operational Activity and Function Diagrams

    Service Function Diagram updated to be consistent with Operational Activity and Function Diagrams.

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

The UAFElement stereotype has multiple child stereotypes but none appear on the diagram.

  • Key: UAF11-147
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

    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

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 14:59 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Subtypes of UAF element are added to the UAFElement diagram

    Subtypes of UAF element are added to the UAFElement diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

ActualOrganizationalResource (Figure 194) has no Metaclass

  • Key: UAF11-156
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

    ActualOrganizationalResource (Figure 194) has no Metaclass

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 15:05 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Metaclass Displayed

    Metaclass for ActualOrganizationalResource displayed in ActualOrganizationalResource diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Text for ActualMilestoneKind refers to ActualMeasurements instead of ActualProjectMilestone

  • Key: UAF11-155
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

    Text for ActualMilestoneKind refers to ActualMeasurements instead of ActualProjectMilestone

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 15:04 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Actual Milestone Kind Description Changed

    Actual Milestone Kind Description Changed to "Enumeration of the possible kinds of ActualProjectMilestone."

  • Updated: Tue, 8 Oct 2019 17:49 GMT

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

  • Key: UAF11-154
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

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

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 15:04 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Actual Organizational Resource removed from Actual Project Milestone Diagram

    Actual Organizational Resource removed from Actual Project Milestone Diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

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

  • Key: UAF11-153
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

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

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 15:03 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Project Role added to Resource Role Diagram

    Project Role added to Resource Role Diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Inconsistent depiction of VisionStatement

  • Key: UAF11-152
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

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

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 15:02 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Duplicates UAF11-39

    Duplicates UAF11-39

  • Updated: Tue, 8 Oct 2019 17:49 GMT

CapabilityForTask is duplicated on the Capability diagram (Figure 40)

  • Key: UAF11-150
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

    CapabilityForTask is duplicated on the Capability diagram (Figure 40)

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 15:01 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Duplication Removed

    Duplication of CapabilityForTask removed

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Diagram Consistency

  • Key: UAF11-149
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

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

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 15:01 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    OperationalExchange Diagram is now consistent with other diagrams

    Implements relationship displayed on the diagram like in other diagrams

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Doc inconsistency between ActualOrganizationalResource & ActuralResponsibility

  • Key: UAF11-118
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

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

  • Reported: UAF 1.0 — Fri, 2 Feb 2018 14:32 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Actual Responsibility shown on the Actual Organizational Resource Diagram

    Actual Responsibility shown on the Actual Organizational Resource Diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Dual inheritance for ActualService is confusing

  • Key: UAF11-125
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

    <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

  • Reported: UAF 1.0 — Fri, 2 Feb 2018 15:04 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Generalisation to ActualPropertySet removed

    Actual Service transitively Inherits from Actual Property Set via Actual Measurement Set. Direct Generalisation to Actual Property Set was redundant and has been removed.

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Unclear relationship between ActualProject and ActualPropertySet

  • Key: UAF11-122
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

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

  • Reported: UAF 1.0 — Fri, 2 Feb 2018 14:51 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    ActualProject removed from ActualPropertySet diagram

    ActualProject indirectly inherits from Actual Property Set. ActualProject removed from ActualPropertySet diagram.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Figure 40 – Capability, shows CapabilityForTask twice

  • Key: UAF11-38
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    Figure 40 – Capability, shows CapabilityForTask twice.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 06:44 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Duplicates UAF11-150

    Duplicates UAF11-150

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Figure 163 for Risk doesn’t show a specialization to Block

  • Key: UAF11-55
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 18:49 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Block is now shown on the Risk diagram

    Block is now shown on the Risk diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

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

  • Key: UAF11-52
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 07:22 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Data Model extension added to Data Model diagram

    Data Model extension added to Data Model diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

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

  • Key: UAF11-47
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 07:11 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    *RoleKind tag name starts with lowercase r *

    RoleKind tag name starts with lowercase r

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Figure103 for OrganizationalResource is missing some relationships.

  • Key: UAF11-45
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 07:06 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Diagram updated adding missing elements

    Missing elements added to the OrganizationalResource diagram:
    Project,
    OwnsRisk,
    RequiresCompetence

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Figure 277 for Services Connectivity should show ServiceSpecificationRole

  • Key: UAF11-75
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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…

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:29 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Services Connectivity updated to show Service Specification Roles

    Services Connectivity updated to show Service Specification Roles

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

ActualService doesn’t need to directly inherit from ActualPropertySet

  • Key: UAF11-65
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:10 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Duplicates UAF11-125

    Duplicates UAF11-125

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Figure 182 for Protocol should show the relationship to implementers.

  • Key: UAF11-64
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    Figure 182 for Protocol should show the relationship to implementers.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:08 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Duplicates UAF11-112

    Duplicates UAF11-112

  • Updated: Tue, 8 Oct 2019 17:49 GMT

SubjectOfSecurityConstraint is specialized by Asset but not AssetRole

  • Key: UAF11-60
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:00 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    *Asset role is now a subtype of Subject of Security Constraint *

    Asset role is now a subtype of Subject of Security Constraint

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

SecurityControl can't be a specialization of PropertySet and Requirement

  • Key: UAF11-56
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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…

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 18:52 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Security Control inherits from MeasurableElement.

    SecurityControl updated to inherit from MeasurableElement rather PropertySet.
    Affected Diagrams:
    Profile:
    -SecurityControl
    -PropertySet
    -MeasurableElement

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Figure 277 for Services Connectivity should show provided/required interfaces

  • Key: UAF11-74
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:27 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Description of the Service Connectivity is updated

    Description of the Service Connectivity is updated

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Figure 76 for OperationalActivity is missing OwnsProcess.

  • Key: UAF11-66
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    Figure 76 for OperationalActivity is missing OwnsProcess.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:12 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Duplicates UAF11-111

    Duplicates UAF11-111

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Pr-Tx should not show structure, just generalizations.

  • Key: UAF11-95
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:59 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Helps to show structure on taxonomy diagrams

    Gudiance from NATO is that they are allowing mix of structure and generalization on taxonomy diagrams, UAF Group also feels that this is acceptable practice

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Tx and Sr views overlap.

  • Key: UAF11-101
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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…

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 03:29 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Helps to show structure on taxonomy diagrams

    UAF Group allows this overlap. As it can reduce the number of views required to express an archtecture.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

The OwnsRiskInContext has the wrong constraint text

  • Key: UAF11-108
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 04:34 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Owns Risk in Context constraint text updated

    Owns Risk in Context constraint text updated from OwnsProcess to OwnsRiskInContext

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Make the relationship between the definition Statemachines (currently implicitly related to UML statemachines) and the definition of ResourceStateMachines more explicit for readers of the UAF.

  • Key: UAF11-5
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    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.

  • Reported: UAF 1.0 — Mon, 26 Jun 2017 11:06 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    modify relevant diagrams to show relationship to UML semantics

    modify state machines diagrams in MM

    Operational States
    Resource States
    Services States
    Personnel States

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Make the relationship between UML composition and aggregation (for the information model) and the use of whole/part in the UAF more explicit for readers of the UAF specification document.

  • Key: UAF11-3
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    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.

  • Reported: UAF 1.0 — Mon, 26 Jun 2017 11:00 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Update Information model MM and profile diagrams

    Modified information models diagrams in MM and Profile diagram to show data aggregation.

    Information Model MM Shows WholePart
    Information Model Profile Shows Class, Type on role

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Update descriptions for MetaData row of Grid

  • Key: UAF11-23
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    need to add descriptions to Metada row

  • Reported: UAF 1.0 — Wed, 6 Dec 2017 19:31 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Update descriptions for MetaData row of Grid

    Update descriptions for MetaData row of Grid

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Constraint uses wrong name

  • Key: UAF11-13
  • Status: closed  
  • Source: Akademiska sjukhuset ( Hans Natvig)
  • Summary:

    Constraints OwnsProcess.* should be renamed to OwnsRiskInContext.*

  • Reported: UAF 1.0b2 — Sun, 29 Oct 2017 15:08 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Duplicates UAF11-108

    Duplicates UAF11-108

  • Updated: Tue, 8 Oct 2019 17:49 GMT

AchievedEffect is duplicated on the Achiever diagram (Figure 53)

  • Key: UAF11-151
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

    AchievedEffect is duplicated on the Achiever diagram (Figure 53)

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 15:02 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Duplicates UAF11-43

    Duplicates UAF11-43

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Identify all MeasurableElements in a comprehensive list or table

  • Key: UAF11-117
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

    <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

  • Reported: UAF 1.0 — Fri, 2 Feb 2018 14:23 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    All subtypes of MeasurableElement displayed on the diagram

    All missing subtypes visualized on the diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Provided complete list of UAF PropertySets in table

  • Key: UAF11-116
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

    <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

  • Reported: UAF 1.0 — Fri, 2 Feb 2018 14:01 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    All subtypes of Property Set are displayed in Property Set diagram

    All subtypes of Property Set are displayed in Property Set diagram.

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Figure 88 for ServiceMethod inconsistent

  • Key: UAF11-44
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 07:04 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Owner metaconstraint changed to ownedOperation metaconstraint

    Direction of metaconstraint connecting ServiceMethod and Service Specification reversed and uml role changed to ownedOperation. This makes diagram consistent with the generic style of specification.

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Problem with Figure 214 for Strategic Roadmap

  • Key: UAF11-41
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 06:53 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Duplicates UAF11-40

    Duplicates UAF11-40

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Problems with Figure 49

  • Key: UAF11-40
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 06:50 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    ResponsibleFor is removed from ActualEnduringTask diagram and added to ActualProjectMilestone diagram

    ResponsibleFor is removed from ActualEnduringTask diagram and added to ActualProjectMilestone diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Constraint text for Figure 34 is incorrect.

  • Key: UAF11-32
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 06:14 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Constraint text changed to align with Diagram

    Information's Annotated element constraint text changed to be aligned with Information Diagram

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Energy should be restored to the UAF.

  • Key: UAF11-78
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:43 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    ResourceArtifact or NaturalResource can be used to capture Energy

    Resource Artifact can be used to capture human converted Energy, e.g. Electricity
    Natural Resource can be used to capture natural energy, e.g. Solar Power
    Having Energy would be confusing to distinguish the origin of the energy.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

ActualProject specialization wrong

  • Key: UAF11-62
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:05 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Both Text and Diagram are aligned in UAFP spec. formal/17-12-01

    Both Text and Diagram are aligned in UAFP spec. formal/17-12-01

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Security Constraints inconsistency

  • Key: UAF11-72
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:24 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Security Control and Enhanced Security control are in both Diagram and List

    Security Control and Enhanced Security control are in both Diagram and List in UAF 1.0 spec.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Figure 262 shows an invalid relationship

  • Key: UAF11-71
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:21 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    In the UAF 1.0 spec. the issue does not exist

    In the UAF 1.0 spec. the issue does not exist.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Abstract stereotypes in the Elements list within Annex A

  • Key: UAF11-68
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:17 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Abstract Elements should be in the list

    Abstract Elements should be in the list because you need to be able to easily navigate to them to check what is underneath them.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

The diagram for OperationalObjectFlow does not show links to OperationalActivityAction

  • Key: UAF11-159
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

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

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 15:07 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Links to action are not shown because object flow does not connect actions

    Links to action are not shown because object flow does not connect actions. It connects object nodes, like pins, parameters, etc. In UAF there are no stereotyped object nodes to show this connection.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

The diagram for FunctionObjectFlow does not show links to FunctionAction

  • Key: UAF11-158
  • Status: closed  
  • Source: Peraton ( Mr. Andre Kiebuzinski)
  • Summary:

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

  • Reported: UAF 1.0 — Mon, 26 Mar 2018 15:07 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    *Links to action are not shown because object flow does not connect actions *

    Links to action are not shown because object flow does not connect actions. It connects object nodes, like pins, parameters, etc. In UAF there are no stereotyped object nodes to show this connection.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Op-Tx should be IBD

  • Key: UAF11-79
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 01:51 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    It is already captured in the description of the view specification

    It is already captured in the description of the view specification

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Rs-Rm implementations should be matrix/tabular and BDD.

  • Key: UAF11-97
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 03:06 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Correct as is

    Correct as is

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Typo in the figure 235 text.

  • Key: UAF11-91
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    Typo in the figure 235 text.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:46 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    No Typo found

    No Typo found

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Sv-Tr should be matrix/tabular and BDD.

  • Key: UAF11-90
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:37 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Refers to issue in old spec

    Refers to issue in old spec, fixed in FTF

  • Updated: Tue, 8 Oct 2019 17:49 GMT

St-Rm should be mapped to an Object Diagram

  • Key: UAF11-88
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 02:34 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Refers to issue in old spec

    Refers to issue in old spec, issue was corrected in FTF

  • Updated: Tue, 8 Oct 2019 17:49 GMT

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

  • Key: UAF11-109
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 04:37 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    *Extension removed. *

    Project Activity Action is only Extending Call Behavior Action

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Problem with ServiceMessageHandler

  • Key: UAF11-115
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 04:49 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    There is no need to add additional stereotypes

    There is no need to create stereotypes for signal receptions. UML signal receptions can be successfully used for this purpose as they can be associated with Operational and Resource Signals.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

ProvidesCompetence should also be an abstraction.

  • Key: UAF11-113
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 04:44 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Provides Competence is dependency

    Provides Competence connects Competence to Actual Organizational Resource which is an instance spec. The only reason to change it to abstraction would be inheritance from SysML Allocate. However, as Actual Organizational Resource is Instance Specification the use of Allocate doesn't make sense.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Make the relationship between UML and the decomposition of Activity based elements more explicit for readers of the UAF specification document.

  • Key: UAF11-2
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    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.

  • Reported: UAF 1.0 — Mon, 26 Jun 2017 10:57 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Modified relevant diagrams to relfect relationship with UML semantics

    Added UML elements to relevant diagrams to capture relationship to UML MM Semantics

    Operational Processes,
    Resource Processes,
    Services Processes,
    Operational Interaction Scenarios
    Resource Interaction Scenarios
    Services Interaction Scenarios

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Make the relationship between UML and BPMN for the representation the BPMN Start Event and End Event more explicit for readers of the UAF specification document.

  • Key: UAF11-1
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    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

  • Reported: UAF 1.0 — Mon, 26 Jun 2017 10:52 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Added BPMN elements to relevant diagrams to capture BPMN Semantics

    Added BPMN elements to relevant diagrams to capture BPMN Semantics

    Operational Processes, BPMN Semantics
    Resoruce Processes, BPMN Semantics
    Services Processes, BPMN Semantics

    Minor updates to textual desccriptions and also
    Security processes and project processes

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

ResponsibleFor relationship from Actual Responsible Resource to Actual Project Milestone is missing in the Responsible For diagram

  • Key: UAF11-19
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    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.

  • Reported: UAF 1.0b2 — Tue, 5 Dec 2017 00:51 GMT
  • Disposition: Duplicate or Merged — UAF 1.1
  • Disposition Summary:

    Duplicates UAF11-40

    Duplicates UAF11-40

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Unified Architecture Framework (UAF), The Domain Metamodel document should not be marked as Appendix A for UAFP specification

  • Key: UAF11-18
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    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.

  • Reported: UAF 1.0b2 — Tue, 5 Dec 2017 00:34 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Modify document structure

    This is to improve readability of the profile and semantic understanding.

    Add diagrams explaining eacch metamodel element to the DMM documentation.

    Add doc generated from Profile to doc generated from MM and compile to gether with TOC.

    MM doc first followed by profile.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Enteprise Phase should not be a subtype of capable element

  • Key: UAF11-28
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

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

  • Reported: UAF 1.0b2 — Wed, 6 Dec 2017 19:51 GMT
  • Disposition: Resolved — UAF 1.1
  • Disposition Summary:

    Enterprise Phase is no longer a Capable Element

    Generalisation from EnteprisePhase to CapableElement removed

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Missing Metaclass designation in documentation

  • Key: UAF11-120
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

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

  • Reported: UAF 1.0 — Fri, 2 Feb 2018 14:42 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Extensions are at the top of the inheritance hierarchy

    Both Operational Exchange Item and Resource Exchange Item have metaclass which is Element. To locate it in the spec. you need to go all up the inheritance hierarchy. In this case to Resource diagram.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

No diagram representation exists for some model elements

  • Key: UAF11-119
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

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

  • Reported: UAF 1.0 — Fri, 2 Feb 2018 14:39 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Enumerations are depicted where they are applied

    Enumerations in UAF spec do not have specific diagrams. They are depicted in diagrams where they are applied. We think there is no need for enumeration diagrams as they do not provide any additional information to the one given in text.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Inconsistency between spec and implementation

  • Key: UAF11-127
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

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

  • Reported: UAF 1.0 — Fri, 2 Feb 2018 15:13 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Tool Issue

    This is tool implementation issue. It is not affecting UAF specification.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Capabilty generalization should be Use Case

  • Key: UAF11-129
  • Status: closed  
  • Source: Vencore ( John Gilbert)
  • Summary:

    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.

  • Reported: UAF 1.0 — Mon, 5 Feb 2018 18:02 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Capability cannot be made a “SysML Use Case”.

    Use-Case in UML is a BehavioredClassifier.
    Capabilities are “non-behavioral concepts”. They are “operational qualities” (emerging properties) belong to the “requirement side” of architecture description. Hence Capability cannot be made a “SysML Use Case”.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Figure 51 for EnduringTask is missing inheritance to SysML::Block

  • Key: UAF11-42
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 07:00 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Inheritance from SysML block is shown in the final version of the specification

    Inheritance from SysML block is shown in the final version of the specification

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Actual Enterprise Phase: Concern.systemConcern should be 0..1

  • Key: UAF11-37
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 06:42 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    *It needs to be many to many *

    It is changed to many to many when resolving UAF11-36. This issue is no longer relevant.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Inconsistency with Constraint [e] for Implements.supplier

  • Key: UAF11-34
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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?

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 06:30 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Needed to support DoDAF SV-2

    Resource Connector implementing another Resource Connector is needed to support DoDAF SV-2. Connectors in DoDAF SV-2 are considered to be physical. Connectors in SV-1 are considered to be logical. To show how physical connectors in the SV-2 realise logical connectors in the SV-1 implements relationship is used.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Problem with EnhancedSecurityControl inheritance

  • Key: UAF11-54
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 18:48 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Security Control and Enhanced Security Control are both specific SysML Requirements

    Security Control and Enhanced Security Control are both specific SysML Requirements. It means Enhances relationship can inherit from DeriveReqt and can connect both.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Inconsistency with SecurityProcess and ProjectActivity

  • Key: UAF11-51
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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…

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 07:20 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Guidance is clearly defined by view specification diagrams provided in the spec

    Project Activity and Security Process are subtypes of Function, however, they are not to be used when defining Resource Processes. Project Activities are used to model Project Processes and Security Process is used to model Security Processes views. This is indicated in view specification diagrams for Resources Processes, Project Processes and Security Processes.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Constraints for ResourceInteractionKind.ResourceEnergyFlow don’t make sense

  • Key: UAF11-50
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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…

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 07:17 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Energy falls under NaturalResources and we do not see a need to have it as separate element

    Energy falls under NaturalResources and we do not see a need to have it as separate element in UAF profile and DMM. Energy can be added as a domain specific extension if there is a need.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Inconsistency with Project

  • Key: UAF11-61
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:03 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    *In the formal/17-12-01 Diagram matches XMI. *

    In the formal/17-12-01 Diagram matches XMI.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Abstract stereotypes shouldn't have extensions.

  • Key: UAF11-58
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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…

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 18:56 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Displaying metaclass on the abstract element gives better feeling what kind of subtypes element has

    Displaying metaclass on the abstract element gives better feeling what kind of subtypes element has

  • Updated: Tue, 8 Oct 2019 17:49 GMT

conformsTo is missing

  • Key: UAF11-12
  • Status: closed  
  • Source: Akademiska sjukhuset ( Hans Natvig)
  • Summary:

    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.

  • Reported: UAF 1.0b1 — Tue, 3 Oct 2017 08:13 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    ConfromsTo is not a stereotype; it is a tag

    Conforms to is a property on the UAF element that is used to connect it to Standard element. It was never a stereotype. Please see Figure 7.209 - UAFElement in the UAF specification.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

OrganizationalResources should not be on a Rs-Tx

  • Key: UAF11-96
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 13 Jan 2018 03:04 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Organizations can be shown on RS-TX

    Organizations can be shown on RS-TX as they are resources i their own right and can be used in the context of other resources.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Ovierview picture (UAF Grid Overview)

  • Key: UAF11-14
  • Status: closed  
  • Source: Akademiska sjukhuset ( Hans Natvig)
  • Summary:

    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.

  • Reported: UAF 1.0b2 — Fri, 3 Nov 2017 10:51 GMT
  • Disposition: Closed; Out Of Scope — UAF 1.1
  • Disposition Summary:

    This issue is raised against UAF beta 2

    This issue is raised against UAF beta 2. It has nothing to do with UAF 1.1 RTF

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Provide Vendor Neutral exchange format of the UAF DMM

  • Key: UAF11-6
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Entered on behalf of Torsten Graeber

  • Reported: UAF 1.0 — Mon, 26 Jun 2017 11:09 GMT
  • Disposition: Deferred — UAF 1.1
  • Disposition Summary:

    Deferred to UAF 1.2

    Will be solved in UAF 1.2

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Add the element ResourceRoleKinds to the relevant diagrams in the UAF DMM

  • Key: UAF11-4
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    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.

  • Reported: UAF 1.0 — Mon, 26 Jun 2017 11:03 GMT
  • Disposition: Deferred — UAF 1.1
  • Disposition Summary:

    Deferred to UAF 1.2

    Deferred to UAF 1.2

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Actual Risk should be captured in Security Parameters rather than Security Constraints

  • Key: UAF11-17
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    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.

  • Reported: UAF 1.0b2 — Tue, 5 Dec 2017 00:05 GMT
  • Disposition: Deferred — UAF 1.1
  • Disposition Summary:

    This issue has a big impact on how parameter vies are currently organised. The scope of change is to big for RTF 1.1

    This issue has a big impact on how parameter vies are currently organised. The scope of change is to big for RTF 1.1

  • Updated: Tue, 8 Oct 2019 17:49 GMT

UAF compliance criteria for Toolvendors

  • Key: UAF11-24
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Add UAF compliance criteria for Toolvendors

  • Reported: UAF 1.0 — Wed, 6 Dec 2017 19:33 GMT
  • Disposition: Closed; Out Of Scope — UAF 1.1
  • Disposition Summary:

    There is no organization in place

    There is no organization in place to set and later verify any tool compliance levels that we can come up with.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Add the UAF Metamodel on a page

  • Key: UAF11-22
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

  • Reported: UAF 1.0 — Wed, 6 Dec 2017 19:30 GMT
  • Disposition: Deferred — UAF 1.1
  • Disposition Summary:

    Add the UAF on a page diagram

    Provides a high level overview of the major elements and relationships in the UAF DMM

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Definition of FunctionAction is too tight

  • Key: UAF11-31
  • Status: closed  
  • Source: Akademiska sjukhuset ( Hans Natvig)
  • Summary:

    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?

  • Reported: UAF 1.0b2 — Fri, 8 Dec 2017 11:48 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    No need to over-stereotype elements

    As UAFP is extension of SysML and SysML is extension of UML, all types of actions are allowed to be used to construct UAF processes views. Extending call Behaviour action in particular has a specific purpose to constraint its behaviour. Function Action for example is constrained to only Function to be used as its Behaviour. There is no need to extend elements if they do not have any modifications compared to the base class in UML. However, they can be used in the model and have the same semantics as UML defines.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Consumes relationship is facing wrong direction

  • Key: UAF11-29
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    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.

  • Reported: UAF 1.0 — Wed, 6 Dec 2017 21:19 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Agreed that Operational Scenarios are dependent on Service and not vice versa

    Agreed that Operational Scenarios are dependent on Services and not vice versa. This means that the current implementation is correct and no change is needed.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Stereotypes for flowProperties

  • Key: UAF11-27
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    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

  • Reported: UAF 1.0b2 — Wed, 6 Dec 2017 19:44 GMT
  • Disposition: Deferred — UAF 1.1
  • Disposition Summary:

    Deferred to the future versions of UAF

    Deferred to the future versions of UAF. The impact of the change is too significant to solve it in this particular version.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Concpetual mapping between UAF DMM and Archimate elements

  • Key: UAF11-26
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    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

  • Reported: UAF 1.0 — Wed, 6 Dec 2017 19:37 GMT
  • Disposition: Deferred — UAF 1.1
  • Disposition Summary:

    Deferred to future versions of UAF

    This is not a simple task to solve in the RTF 1.1.

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Interoperability and Interchange Testing; LFL Issue #4 (11 September 2017)

  • Key: UAF11-10
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 9 Sep 2017 23:36 GMT
  • Disposition: Closed; Out Of Scope — UAF 1.1
  • Disposition Summary:

    This is a task for MIWG

    This is a task for MIWG that tool vendors participate in and work together to test interoperability.

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Support Extensibility and Specialization of Architectures (Inheritance and Extension of Architectures; LFL Issue #3 (11 September 2017)

  • Key: UAF11-9
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

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

  • Reported: UAF 1.0 — Sat, 9 Sep 2017 23:34 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    Support Extensibility and Specialization of Architectures (Inheritance and Extension of Architectures; LFL Issue #3 (11 September 2017)

    All the infrastruture exists in the current DMM to enable architectures to inherit and reference one another.
    We have an element based upon dependency called ArchitecturalReference that allows different Arhitectures to be related.
    Also any element at the type level within the DMM is allowed to be inherited from (SuperSubType) and the resultant architeture an be redefined.
    All this is contained in the metadata layer of the UAF.

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

Increase DoDAF Conformance – PES Implementation; LFL Issue #2 (11 September 2017).

  • Key: UAF11-8
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

    "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

  • Reported: UAF 1.0 — Sat, 9 Sep 2017 23:32 GMT
  • Disposition: Deferred — UAF 1.1
  • Disposition Summary:

    Deferred to future versions of UAF

    Deferred to future versions of UAF

  • Updated: Tue, 8 Oct 2019 17:49 GMT
  • Attachments:

The View definition in Annex A are missing stereotypes from the Elements list

  • Key: UAF11-67
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    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.

  • Reported: UAF 1.0 — Thu, 11 Jan 2018 19:14 GMT
  • Disposition: Deferred — UAF 1.1
  • Disposition Summary:

    Deferred to the future versions of UAF

    Deferred to the future versions of UAF

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Should SubjectOfForecast be an Asset instead of ResourcePerformer?

  • Key: UAF11-296
  • Status: closed  
  • Source: Akademiska sjukhuset ( Hans Natvig)
  • Summary:

    In the description of Forecast it says "...transition from one Asset,...". However Asset is not a specialization of SubjectOfForecast.

  • Reported: UAF 1.0 — Thu, 2 May 2019 08:45 GMT
  • Disposition: Deferred — UAF 1.1
  • Disposition Summary:

    Should SubjectOfForecast be an Asset instead of ResourcePerformer

    Should SubjectOfForecast be an Asset instead of ResourcePerformer

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Achiever cannot be the same as Desirer

  • Key: UAF11-227
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    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.

  • Reported: UAF 1.0 — Fri, 31 Aug 2018 13:57 GMT
  • Disposition: Deferred — UAF 1.1
  • Disposition Summary:

    Defer to later version of UAF

    Defer to later version of UAF

  • Updated: Tue, 8 Oct 2019 17:49 GMT

Inconsistency between spec and implementation

  • Key: UAF11-126
  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

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

  • Reported: UAF 1.0 — Fri, 2 Feb 2018 15:10 GMT
  • Disposition: Deferred — UAF 1.1
  • Disposition Summary:

    Deferred to future versions of UAF

    Service Function Edges and Service Exchanges needs to be added to the specification. However, the scope of this change is too big to be dealt with in UAF 1.1 RTF

  • Updated: Tue, 8 Oct 2019 17:49 GMT