Unified Architecture Framework Avatar
  1. OMG Specification

Unified Architecture Framework — Closed Issues

  • Acronym: UAF
  • Issues Count: 191
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
UAF12-11 Achiever cannot be the same as Desirer UAF 1.0 UAF 1.2 Resolved closed
UAF12-10 Inconsistency between spec and implementation UAF 1.0 UAF 1.2 Resolved closed
UAF12-6 Add the UAF Metamodel on a page UAF 1.0 UAF 1.2 Resolved closed
UAF12-16 Inconsistencies in view specifications UAF 1.0 UAF 1.2 Resolved closed
UAF12-12 Should SubjectOfForecast be an Asset instead of ResourcePerformer? UAF 1.0 UAF 1.2 Resolved closed
UAF12-9 The View definition in Annex A are missing stereotypes from the Elements list UAF 1.0 UAF 1.2 Closed; No Change closed
UAF12-5 Actual Risk should be captured in Security Parameters rather than Security Constraints UAF 1.0b2 UAF 1.2 Resolved closed
UAF12-14 Recommended Implementation should include ibd UAF 1.0 UAF 1.2 Closed; No Change closed
UAF12-15 CapabilityForTask, is it redundant? UAF 1.0 UAF 1.2 Resolved closed
UAF12-8 Stereotypes for flowProperties UAF 1.0b2 UAF 1.2 Deferred closed
UAF12-7 Conceptual mapping between UAF DMM and Archimate elements UAF 1.0 UAF 1.2 Closed; No Change closed
UAF12-4 Add a 3-way Resource Traceability Matrix as a standard view UAF 1.0 UAF 1.2 Closed; No Change closed
UAF12-3 Increase DoDAF Conformance – PES Implementation; LFL Issue #2 (11 September 2017). UAF 1.0 UAF 1.2 Closed; No Change closed
UAF12-2 Provide Vendor Neutral exchange format of the UAF DMM UAF 1.0 UAF 1.2 Closed; Out Of Scope closed
UAF12-1 Add the element ResourceRoleKinds to the relevant diagrams in the UAF DMM UAF 1.0 UAF 1.2 Closed; No Change closed
UAF12-13 Is OrganizationInEnterprise to restrained? UAF 1.0 UAF 1.2 Deferred closed
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
UAF-52 Update headings of the appendix documents to same format and make DMM Normative UAF 1.0b1 UAF 1.0 Resolved closed
UAF-50 Minor modifications on UAF-37 to complete FTF UAF 1.0b1 UAF 1.0 Resolved closed
UAF-8 Capability Definition UAF 1.0b1 UAF 1.0 Resolved closed
UAF-6 three properties called criticiality UAF 1.0b1 UAF 1.0 Resolved closed
UAF-5 Confidentiality missing UAF 1.0b1 UAF 1.0 Duplicate or Merged closed
UAF-47 Class Library Definition UAF 1.0b1 UAF 1.0 Resolved closed
UAF-43 Missing Project Activities from the UAF 1.0 Specification UAF 1.0b1 UAF 1.0 Resolved closed
UAF-42 UAF is missing project activity views UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-20 ActualEnduringTask and ActualRisk are missing from the ActualPropertySet diagram UAF 1.0b1 UAF 1.0 Resolved closed
UAF-19 Operational Nodes and other legacies in the definitions of the views UAF 1.0b1 UAF 1.0 Resolved closed
UAF-37 Type of Security Control Element UAF 1.0b1 UAF 1.0 Resolved closed
UAF-18 Change "process" to "processes" or "transform" in view definitions UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-2 Operational Exchange/Resource Interaction for triggering Transitions in StateMachines UAF 1.0b1 UAF 1.0 Resolved closed
UAF-9 Scope UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-10 small errors in UAF XMI UAF 1.0b1 UAF 1.0 Resolved closed
UAF-4 use of same term. UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-38 The DMM model for Service taxonomy states secific where it should be specific. UAF 1.0b1 UAF 1.0 Resolved closed
UAF-15 Architecture is not needed in the diagram for Exhibits UAF 1.0b1 UAF 1.0 Resolved closed
UAF-14 Implements should be removed from Enduring Task diagram UAF 1.0b1 UAF 1.0 Resolved closed
UAF-12 Taxonomy as stereotypes rather than a class library UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-11 What is a “Person”? UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-36 definition for element Risk includes Information security risk definition. UAF 1.0b1 UAF 1.0 Resolved closed
UAF-7 Multiple broken links in Appendix C section 2.1.1 UAF 1.0b1 UAF 1.0 Resolved closed
UAF-3 Resources Connectivity diagram is missing activity diagram elements UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-1 SysML Version UAF 1.0b1 UAF 1.0 Resolved closed

Issues Descriptions

Achiever cannot be the same as Desirer


Inconsistency between spec and implementation

  • Key: UAF12-10
  • 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: Resolved — UAF 1.2
  • Disposition Summary:

    ServiceControlFlow and ServiceObjectFlow added

    ServiceControlFlow and ServiceObjectFlow added to the UAF profile to support ServiceProcesses viewspec and make the ServiceProcess view specification consistent with OperationalProcesses and ResourceProcesses.

  • Updated: Thu, 31 Mar 2022 19:31 GMT
  • Attachments:

Add the UAF Metamodel on a page

  • Key: UAF12-6
  • 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: Resolved — UAF 1.2
  • Disposition Summary:

    Metamodel on the page developed and added to the UAF Guide document

    The full scope of the Domain Metamodel in UAF was difficult to understand, so a higher level "conceptual schema" was created as a single view that captures the top sixty elements of the DMM in a manner that is more readily understandable by architects, engineers and managers. This "metmodel on a page" is included in the EA Guide for UAF document which is a non-normative component of the UAF spec.

  • Updated: Thu, 31 Mar 2022 19:31 GMT

Inconsistencies in view specifications

  • Key: UAF12-16
  • Status: closed  
  • Source: Akademiska sjukhuset ( Hans Natvig)
  • Summary:

    The view specifications Operational Structure and Resources Structure should be consistent with each other. Why does the former include OperationalParameter but the latter does not include ResourceParameter? Also, OperationalActivity is included in the former but Function is omitted in the latter.

  • Reported: UAF 1.0 — Mon, 26 Aug 2019 09:44 GMT
  • Disposition: Resolved — UAF 1.2
  • Disposition Summary:

    ResourcesStructure diagram made consistent with OperationStructure diagram

    ResourcesStructure diagram made consistent with OperationStructure diagram by adding Function and IsCapableToPerform.

  • Updated: Thu, 31 Mar 2022 19:31 GMT
  • Attachments:

Should SubjectOfForecast be an Asset instead of ResourcePerformer?

  • Key: UAF12-12
  • 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: Resolved — UAF 1.2
  • Disposition Summary:

    Forecast definition changed

    Definition of the Forecast Meta Model Class and the Stereotype has been changed to:
    A dependency relationship that specifies a transition from one Resource Performer, Standard, Competence to another future one. It is related to an ActualStrategicPhase to give it a temporal context.

  • Updated: Thu, 31 Mar 2022 19:31 GMT

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

  • Key: UAF12-9
  • 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: Closed; No Change — UAF 1.2
  • Disposition Summary:

    Issue not found

    According to the page and figure numbers specified issues has not been found.

  • Updated: Thu, 31 Mar 2022 19:31 GMT

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

  • Key: UAF12-5
  • 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: Resolved — UAF 1.2
  • Disposition Summary:

    Risk removed from SecurityConstraints view specification

    Risk removed from SecurityConstraints view specification and as a part of resolution of another issue added to a new cross-domain Parameters:Risk viewspec.

  • Updated: Thu, 31 Mar 2022 19:31 GMT
  • Attachments:

Recommended Implementation should include ibd

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

    The recommended implementation for Operational Taxonomy should include ibd:s since ConceptRoles are Properties.

  • Reported: UAF 1.0 — Thu, 4 Jul 2019 07:46 GMT
  • Disposition: Closed; No Change — UAF 1.2
  • Disposition Summary:

    Resolved in the previous version of the specification

    The issue dos not exist in formal/19-11-05 and formal/19-11-07.

  • Updated: Thu, 31 Mar 2022 19:31 GMT

CapabilityForTask, is it redundant?


Stereotypes for flowProperties

  • Key: UAF12-8
  • 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.2
  • Disposition Summary:

    Out of scope for this release

    The issue requires more investigation and has a huge impact on the specification. It is out of scope to the UAF v1.1 and will be addressed in the future releases of UAF.

  • Updated: Thu, 31 Mar 2022 19:31 GMT

Conceptual mapping between UAF DMM and Archimate elements

  • Key: UAF12-7
  • 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: Closed; No Change — UAF 1.2
  • Disposition Summary:

    The mapping will be taken as defined by NATO

    The NATO is working on to provide mapping between specifications. To not duplicate the effort we will reference the NATO mapping as opposed to working on a new one.

  • Updated: Thu, 31 Mar 2022 19:31 GMT

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

  • Key: UAF12-4
  • 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: Closed; No Change — UAF 1.2
  • Disposition Summary:

    Tool vendor issue

    This is related to the way UAF specification is implemented rather than specification it self.

  • Updated: Thu, 31 Mar 2022 19:31 GMT
  • Attachments:
    • Example.xlsx 30 kB (application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)

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

  • Key: UAF12-3
  • 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: Closed; No Change — UAF 1.2
  • Disposition Summary:

    The conformance to DM2 is already provided and recognised in DISR

    The conformance to DM2 is already provided in the UAF 1.1 and recognised in DISR. Conformance to PES is not planned and will not be implemented. The only supported exchange specification for UAF models and DoDAF models modelled in UAFP will remain XMI standard.

  • Updated: Thu, 31 Mar 2022 19:31 GMT
  • Attachments:

Provide Vendor Neutral exchange format of the UAF DMM

  • Key: UAF12-2
  • 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: Closed; Out Of Scope — UAF 1.2
  • Disposition Summary:

    Out of scope for UAF. A new RFP is needed.

    Exchange format is out of scope for UAF RTF specification. A new RFP is needed to support it.

  • Updated: Thu, 31 Mar 2022 19:31 GMT

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

  • Key: UAF12-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

    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: Closed; No Change — UAF 1.2
  • Disposition Summary:

    Derivation of RoleKind names is up to the tool vendors

    RoleKinds and how they are notated on the diagrams is solely tool vendor issue. UAF specification defines only the list of possible kinds where tool vendor can define how they appear on the diagrams.

  • Updated: Thu, 31 Mar 2022 19:31 GMT

Is OrganizationInEnterprise to restrained?

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

    Current drescription is "An abstraction relationship relating an ActualOrganization to an ActualEnterprisePhase to denote that the ActualOrganization plays a role or is a stakeholder in an ActualEnterprisePhase."

    However, since a stakeholder can also be an OrganizationalResource (see definition in Figure 7.208) maybe the OrganizationInEnterprise could also relate an OrganizationalResource to an ActualEnterprisePhase? Otherwise, only a subset of the stakeholders can be related to an ActualEnterprisePhase.

  • Reported: UAF 1.0 — Tue, 2 Jul 2019 08:58 GMT
  • Disposition: Deferred — UAF 1.2
  • Disposition Summary:

    Due to the scope of impact deferred to the next release

    Will be resolved in the next version of the specification.

  • Updated: Thu, 31 Mar 2022 19:31 GMT

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

Update headings of the appendix documents to same format and make DMM Normative

  • Key: UAF-52
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Update headings of the DMM title page and make Normative, also align heading of appendix C to be Informative

  • Reported: UAF 1.0b1 — Thu, 18 May 2017 09:16 GMT
  • Disposition: Resolved — UAF 1.0
  • Disposition Summary:

    Update headings of the DMM title page and make Normative, also align heading of appendix C to be Informative

    "modify tile page dtc-17-04-07 with the appropriate fonts and
    add (Normative) to the title page
    centre justify title
    moved appendix a, down to left justify and modify font
    modify text on dtc-17-04-08 from Non-normative to Informative

  • Updated: Mon, 16 Oct 2017 15:16 GMT

Minor modifications on UAF-37 to complete FTF


Capability Definition

  • Key: UAF-8
  • Status: closed  
  • Source: Neil Kemp & Associates Inc ( Neil Kemp)
  • Summary:

    I see capability is defined as “A high level specification of the enterprise's ability to execute a specified course of action.” Not sure I like it. If you said ‘A high level specification of something that enables the enterprise's ability to execute a specified course of action I would be a whole lot happier.

    The DODAF definition of capability is “The ability to achieve a Desired Effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities.” I think this is a better definition, but again, the way its represented in their meta model it would be better described as “A thing that adds to The ability to achieve a Desired Effect under specified (performance) standards

    The way both “official” definitions are worded I don’t think there is anything that is “countable” and therefore there is nothing that exists as an item to be captured in a structured model. I would argue that the chanes is needed to make the items countable and to then appear in a UML model and also question why competing definitions are necessary.

  • Reported: UAF 1.0b1 — Thu, 2 Feb 2017 20:24 GMT
  • Disposition: Resolved — UAF 1.0
  • Disposition Summary:

    Capability Definition

    modify Capability definition

  • Updated: Mon, 16 Oct 2017 15:16 GMT

three properties called criticiality

  • Key: UAF-6
  • Status: closed  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    these are all the same, define once. profile: class library, elements called ExchangeProperties, SecurityCategoryProperties, SecurityControlProperties all have properties called criticality.

  • Reported: UAF 1.0b1 — Thu, 8 Dec 2016 22:06 GMT
  • Disposition: Resolved — UAF 1.0
  • Disposition Summary:

    three properties called criticiality

    a) criticality and interoperabilityLevelAchievable needs to be removed from ExchangeProperties. Need to think about backward compatibility.
    b) rename criticality : String[1] to priorityofControl for SecurityControlProperties
    c) update Security Taxonomy diagram by adding information and data elements
    d) remove ClassificationType enumerated list
    e) ExchangeProperties - remove: classificationCaveat, criticality, interoperabilityLevelAchievable, protectionDuration, protectionDurationCode, protectionSuspenseCalendarDate, protectionTypeName, releasability, Taxonomy,
    f) remove InformationAssuranceProperties
    g) rename SecurityCategoryProperties to SecurityImpactProperties
    h) SecurityAttributes rename to Classification Attributes
    i) Check if SecurityAttributes are up to date
    j) Review definitions

  • Updated: Mon, 16 Oct 2017 15:16 GMT
  • Attachments:

Confidentiality missing

  • Key: UAF-5
  • Status: closed  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Security Confidentiality missing from UAF-DMM see package Security, DMM has availability and integrity but not confidentiality.

  • Reported: UAF 1.0b1 — Thu, 8 Dec 2016 21:30 GMT
  • Disposition: Duplicate or Merged — UAF 1.0
  • Disposition Summary:

    Duplicates existing Issue

    Duplicates existing Issue

  • Updated: Mon, 16 Oct 2017 15:16 GMT

Class Library Definition

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

    Class Library Definition needs to be updated from

    “A library of Measurements, MeasurementSets and SecurityAttributesGroup, derived from DoDAF.”

    to

    “A library of Measurements.”

  • Reported: UAF 1.0b1 — Fri, 21 Apr 2017 06:54 GMT
  • Disposition: Resolved — UAF 1.0
  • Disposition Summary:

    Class Library Definition needs to be updated

    Class Library Definition needs to be updated from

    “A library of Measurements, MeasurementSets and SecurityAttributesGroup, derived from DoDAF.”

    to

    “A library of Measurements.”

  • Updated: Mon, 16 Oct 2017 15:16 GMT

Missing Project Activities from the UAF 1.0 Specification


UAF is missing project activity views

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

    The Project activity views were left out of the UAF 1.0 specification. There were in the section 8.3.1.2.1.3 ProjectActivity of the UPDM 2.1 specification.

  • Reported: UAF 1.0b1 — Mon, 10 Apr 2017 22:55 GMT
  • Disposition: Closed; No Change — UAF 1.0
  • Disposition Summary:

    this is a duplicate of UAF43 but creating it as duplicate is causing problems

    this is a duplicate of UAF43 but creating it as duplicate is causing problems

  • Updated: Mon, 16 Oct 2017 15:16 GMT

ActualEnduringTask and ActualRisk are missing from the ActualPropertySet diagram

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

    ActualEnduringTask and ActualRisk are missing from the ActualPropertySet diagram.

  • Reported: UAF 1.0b1 — Thu, 30 Mar 2017 16:18 GMT
  • Disposition: Resolved — UAF 1.0
  • Disposition Summary:

    ActualEnduringTask and ActualRisk are missing from the ActualPropertySet diagram

    need to add ActualEnduringTask and ActualRisk to ActualPropertySet

  • Updated: Mon, 16 Oct 2017 15:16 GMT
  • Attachments:

Operational Nodes and other legacies in the definitions of the views

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

    There multiple occurrences of legacy terms in the spec.
    1. Strategic Structure has a completely wrong definition (copy/paste) error. - 147
    2. Operational Taxonomy definition needs to be reviewed - 152
    3. OperationalPerformer Owners added as a stakeholder on page 151
    4. "identifies the operational exchange requirements between NODES" - 151
    5. "logical nodes" - 155
    6. Operational Connectivity - "nodes"- 155
    7. Information Element definition - "are capable of performing" change to "are Capable to perform" - 70
    8. Resource structure BDD is missing from implementation methods - 181
    9. Function definition p. 98 "of" to "to"
    10. Figure 176 – ActualProject is missing relationship

  • Reported: UAF 1.0b1 — Thu, 23 Mar 2017 20:07 GMT
  • Disposition: Resolved — UAF 1.0
  • Disposition Summary:

    Minor modifications to descriptions and some diagrams

    There multiple occurrences of legacy terms in the spec.
    1. Strategic Structure has a completely wrong definition (copy/paste) error. - 147
    2. Operational Taxonomy definition needs to be reviewed - 152
    3. OperationalPerformer Owners added as a stakeholder on page 151
    4. "identifies the operational exchange requirements between NODES" - 151
    5. "logical nodes" - 155
    6. Operational Connectivity - "nodes"- 155
    7. Information Element definition - "are capable of performing" change to "are Capable to perform" - 70
    8. Resource structure BDD is missing from implementation methods - 181
    9. Function definition p. 98 "of" to "to"
    10. Figure 176 – ActualProject is missing relationship

  • Updated: Mon, 16 Oct 2017 15:16 GMT
  • Attachments:

Type of Security Control Element


Change "process" to "processes" or "transform" in view definitions

  • Key: UAF-18
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Change "process" to "processes" or "transform" in view definitions for Op-Sr and probably Rs-Sr

  • Reported: UAF 1.0b1 — Thu, 23 Mar 2017 18:09 GMT
  • Disposition: Closed; No Change — UAF 1.0
  • Disposition Summary:

    Change "process" to "processes" or "transform" in view definitions

    Change "process" to "processes" or "transform" in view definitions for Op-Sr and probably Rs-Sr

  • Updated: Mon, 16 Oct 2017 15:16 GMT

Operational Exchange/Resource Interaction for triggering Transitions in StateMachines


Scope

  • Key: UAF-9
  • Status: closed  
  • Source: Neil Kemp & Associates Inc ( Neil Kemp)
  • Summary:

    The Scope of the work does not fulfil the requirements of the Scope statement at the start of the document. In integrated architecture can only exist if the full context of the organization/business/enterprise is described. This necessitates understanding Purpose, the strategic environment, (not just operational things like weather, light, but political, social, economic ), their associated forces and drivers and the role of value. Everything in this document is dependant on this context and all of it is ignored.

    Based on a list of the participants I understand why these shortfalls exist, NATO does not create strategy, either does Canada DND, US DOD, strategy is created in Brussels, in the White House. These are the Board of Governors for their organizations.

    An integrated architecture description requires that that a Systems View that concerns an understanding of a system by examining the linkages and interactions between the components that comprise the entirety of that defined system, it cannot be done by working just with the pieces. I am a business architect. I am concerned with the form and nature of the enterprise system, with mergers and acquisitions and their impact on capability, value creation and deliver, control (also completely missing from the framework), and none of these things are represented.

    Also a huge disappoint is that the integration between process and information (BPMN and ERD) is not achieved. This is critical to execution

  • Reported: UAF 1.0b1 — Thu, 2 Feb 2017 20:37 GMT
  • Disposition: Closed; No Change — UAF 1.0
  • Disposition Summary:

    Scope

    a) Strategic Domain allows to capture strategy, e.g. Enterprise Goals, Vision, Capabilities, Enduring Tasks, etc. UAF also allows to model Requirements and associate any UAF element to them.
    b) Mergers and acquisitions can be captured in Operational Domain
    c) BPMN compliance mode allows BPMN to be used to capture Operational Processes. Data objects in BPMN can be typed by Information Elements that can be further detailed in ERDs.
    d) Most of the questions can be addressed using BMM. Combining BMM to UAF was not a requirement for UAF 1.0. This might be considered in the future versions of the standard.

  • Updated: Mon, 16 Oct 2017 15:16 GMT

small errors in UAF XMI

  • Key: UAF-10
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    needs a space in the header line
    <?xml version="1.0" encoding="UTF-8"standalone="yes"?>

    note the space between 8" standalone, below
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

    Missing an XMI version
    needs a second line that looks like this
    <xmi:XMI xmi:version="2.xx" where xx is the precises xmi version

  • Reported: UAF 1.0b1 — Mon, 6 Feb 2017 18:30 GMT
  • Disposition: Resolved — UAF 1.0
  • Disposition Summary:

    small errors in UAF XMI

    needs a space in the header line
    <?xml version="1.0" encoding="UTF-8"standalone="yes"?>

    note the space between 8" standalone, below
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

    Missing an XMI version
    needs a second line that looks like this
    <xmi:XMI xmi:version="2.xx" where xx is the precises xmi version

  • Updated: Mon, 16 Oct 2017 15:16 GMT

use of same term.

  • Key: UAF-4
  • Status: closed  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    You have a package called information for data model (perspective or domain). you have another package also called information under metadata package (and others). Should rename the second one to information metadata just to make them distinguishable.

  • Reported: UAF 1.0b1 — Thu, 8 Dec 2016 21:20 GMT
  • Disposition: Closed; No Change — UAF 1.0
  • Disposition Summary:

    use of same term.

    Does not affect the specification,
    Package Information set by the namespace context of the owning package.

  • Updated: Mon, 16 Oct 2017 15:16 GMT

The DMM model for Service taxonomy states secific where it should be specific.

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

    Typo: the DMM model for Service taxonomy states secific where it should be specific.

  • Reported: UAF 1.0b1 — Thu, 6 Apr 2017 08:00 GMT
  • Disposition: Resolved — UAF 1.0
  • Disposition Summary:

    The DMM model for Service Taxonomy states secific where it should be specific

    Cannot find the error in the documentation or model]

    Found it in the model the following day and modified it.

  • Updated: Mon, 16 Oct 2017 15:16 GMT
  • Attachments:

Architecture is not needed in the diagram for Exhibits


Implements should be removed from Enduring Task diagram

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

    It is Actual Enduring Task that is implemented by Operational Activities. Not the Enduring Task.

  • Reported: UAF 1.0b1 — Thu, 23 Mar 2017 13:06 GMT
  • Disposition: Resolved — UAF 1.0
  • Disposition Summary:

    Implements removed from Enduring Task diagram

    Implements relationship links Operational Activity to Actual Enduring Task not the Enduring task as it is depicted in diagrams for Enduring Task and Implements. As a resolution Enduring Task is removed from Implements diagram and Implements is removed from Enduring Task diagram.

  • Updated: Mon, 16 Oct 2017 15:16 GMT
  • Attachments:

Taxonomy as stereotypes rather than a class library

  • Key: UAF-12
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    This issue is related to multiple UAF classes and stereotypes but will be illustrated with “Organization” and “ActualOrganization”.

    UAF contains a taxonomic structure defining useful concepts such as person and organization. These are then represented in UML & SysML and the UAF Profile. Other concepts (e.g. CommunicationsLinkProperties) are represented in a library of concepts. Our recommendation is to use the library of concepts approach more consistently and to have a much smaller profile.

    There are multiple ways concepts like “Person” or “Organization” can be represented in UML/SysML: as classes, instances or stereotypes. UAF has chosen stereotypes.
    The most common way to use UML would be to define a class (Or sysML Block) “Organization”. Instances of that class would be instance specifications such as “International Maritime Organization:Organizaiton”. Particular kinds of organizations would subclass “Organization”, for example “Corporation” may subclass “Organization”. Thus concepts like people and organizations are contained in UML models as classes. Such models may be standardized, reused and extended. This part of UML is well understood and quite functional. For an instance model, such a type is easily used as in “Object Management Group:Organzation”.

    UAF has chosen to make each such concept into a pair of stereotypes e.g. <<Organization>> and <<Actual Organization>>. This makes “Organization” and even “Actual Organization” essentially metatypes instead of Supertypes and instances as one would expect in a UML class model. Another interpretation of a stereotype is as a “archetype” which is essentially a distinguished supertype – everything marked with such a archetype is a subtype of the archetype. However UAF stereotypes seem to represent metatypes, not Supertypes or archetypes.

    The representation of the UAF taxonomy as stereotypes rather than a class model of Supertypes does not seem to have any clear advantage in terms of defining the concepts. Potential reasons would be: 1) To make the UAF concept appear in the class box, eg, "<<Organization>> Civil Defense Organization". Another may be to allow tools to apply special rules to these types. Both of these effects could be achieved with tooling enhancements referencing a class model. Disadvantage of using stereotypes are: 1) That it makes the taxonomy harder to extend & more brittle. 2) That it makes the UAF profile much larger 3) It requires special UAF tooling. 4) It ends up replicating some built-in UML concepts. 5) Complexity 6) Increased learning curve.

    Recommendation: The UAF taxonomy should be represented as a normal UML class hierarchy that is part of the UAF standard – a library of concepts. User models may subclass these concepts as needed – this is simple and semantically clear. The “Non Actual” taxonomy may be removed as the classes are types (non actual) and instances of these classes would be “actual”. Having a class hierarchy for UAF concepts would be reusable with no dependence of any other part of UAF or SysML.

    Option: If additional tooling help is required, stereotypes may be defined for distinguished classes in the taxonomy, with the same name. These stereotypes would simply mean that the user defined class is a (direct or indirect) subtype of the UAF defined class. Such stereotypes are sometimes thought of as “Archetypes”. Using this mechanism, there is no reason to define both “Organization” and “ActualOrganization” as UML already has a mechanism to define an instance for any class. Archetype stereotypes would retain more compatibility with Beta UAF.

  • Reported: UAF 1.0b1 — Thu, 23 Feb 2017 23:38 GMT
  • Disposition: Closed; No Change — UAF 1.0
  • Disposition Summary:

    Taxonomy as stereotypes rather than a class library

    Not in the scope of FTF.
    1. We cannot redefine the foundation in the scope of the FTF
    2. The change in foundation would destroy compatibility with previous versions of the standard
    3. Hard for modelers to understand and use

  • Updated: Mon, 16 Oct 2017 15:16 GMT

What is a “Person”?

  • Key: UAF-11
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    This issue applies to several UAF classes & stereotypes but will be illustrated with two – “Person” and “ActualPerson” as defined in UAF…
    UAF::Person: A type of a human being used to define the characteristics that need to be described for ActualPersons (e.g. properties such as address, telephone number, nationality, etc).
    UAF::ActualPerson: An individual human being.
    We also note a common definition (dictionary.com): 1. a human being, whether an adult or child: 2. a human being as distinguished from an animal or a thing.

    Therefor the common concept for the term “Person” is what is defined in UAF as “ActualPerson”. This pattern is consistent in UAF. While consistent it would seem confusing to most.

    What then, is a UAF::Person? What is a “Type of human being”? Nationality? Age? Capability? These are things one would expect as properties of a person type. We don’t normally recognize subtypes of people.

    Perhaps UAF::Person is a role or phase of a person like “Policeman” or “Teenager”? If so, this would seem to conflate the concept of person with roles they play, and UAF already provides for roles?

    Perhaps it is an extension mechanism, just there to add properties or relationships not in UAF? If so, would not a simple subclass suffice?

    Consulting the example for guidance we see “<<Person>> Marine Radio Operator”, <<Person>> Qualified Lifeboat Driver”. These are clearly roles of a person. Clearly separating what an entity is (A person) from roles they play (Marine Radio Operator) is fundamental to good architecture at any level.

    Recommendation 1: UAF should clearly distinguish rigid(a) types (like “Person”) from non-rigid(a) roles and phases. Name the classes and stereotypes appropriately using terms like role and phase. Have a unifying concept of “A role of something”, add “Role of a person” only if clarifying.

    Recommendation 2: UAF should use the common term for entities – e.g. “UAF::Person” should correspond to what is currently UAF::ActualPerson. If there is a necessity for a metaconcept, that concept should have a specialized prefix or suffix such as “Type”, “Kind” or “Role”.

    Recommendation 3: Should it be required to add properties to a type like “actual person”, just use generalization – no additional mechanism should be required.

    (a): Terms referenced are defined in: http://doc.utwente.nl/50826/

  • Reported: UAF 1.0b1 — Thu, 23 Feb 2017 19:37 GMT
  • Disposition: Closed; No Change — UAF 1.0
  • Disposition Summary:

    What is a “Person”?

    The agreed naming convention in UAF is to name all instances as "Actual something", e.g. "Actual Person". And to name types just simply like Person. We are not using "Type" to name types.
    Changing naming convention would destroy compatibility with previous versions of the standard and would confuse current users.

  • Updated: Mon, 16 Oct 2017 15:16 GMT

definition for element Risk includes Information security risk definition.

  • Key: UAF-36
  • Status: closed  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Old Definition:
    “A statement of the impact of an event on Assets. It represents a constraint on an Asset in terms of adverse effects, with an associated measure. The measure is used to capture the extent to which an entity is threatened by a potential circumstance or event. Risk is typically a function of: the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Software related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems.”

    New Definition:
    “A statement of the impact of an event on Assets. It represents a constraint on an Asset in terms of adverse effects, with an associated measure. The measure is used to capture the extent to which an entity is threatened by a potential circumstance or event. Risk is typically a function of: the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. "

    A type of risk is Information security risk: "Those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (i.e., mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.”
    users can define subtypes of risk to include Information security risk, cost risk, schedule risk, etc. UAF will define only Risk.

  • Reported: UAF 1.0b1 — Tue, 21 Mar 2017 17:42 GMT
  • Disposition: Resolved — UAF 1.0
  • Disposition Summary:

    definition for element Risk includes Information security risk definition.

    Old Definition:
    “A statement of the impact of an event on Assets. It represents a constraint on an Asset in terms of adverse effects, with an associated measure. The measure is used to capture the extent to which an entity is threatened by a potential circumstance or event. Risk is typically a function of: the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Software related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems.”

    New Definition:
    “A statement of the impact of an event on Assets. It represents a constraint on an Asset in terms of adverse effects, with an associated measure. The measure is used to capture the extent to which an entity is threatened by a potential circumstance or event. Risk is typically a function of: the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. "

    A type of risk is Information security risk: "Those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (i.e., mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.”
    users can define subtypes of risk to include Information security risk, cost risk, schedule risk, etc. UAF will define only Risk.

  • Updated: Mon, 16 Oct 2017 15:16 GMT

Multiple broken links in Appendix C section 2.1.1


Resources Connectivity diagram is missing activity diagram elements

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

    Resources Connectivity diagram is missing Function, Function action, Function control flow, Function object flow.
    Diagram needs to be updated and aligned to Operational Connectivity diagram

  • Reported: UAF 1.0b1 — Mon, 5 Dec 2016 21:50 GMT
  • Disposition: Closed; No Change — UAF 1.0
  • Disposition Summary:

    Resources Connectivity diagram is missing activity diagram elements

    This was fixed in a previous version of the specification

  • Updated: Mon, 16 Oct 2017 15:16 GMT

SysML Version

  • Key: UAF-1
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

    Make all specific references to SysML comply with the specification's normative reference to SysML 1.4 (see Section 3.2).

    The following three (3) sections and four (4) errors refer to SysML 1.3. They should refer to SysML 1.4

    (1) Section 1.2 Intended Users (page 3) has one (1) error. It says,
    "This document specifies a SysML v1.3 profile to enable practitioners to express architectural model elements and organize them in a
    set of specified viewpoints and views that support the specific needs of systems engineers in the defense and manufacturing
    industries."
    AND
    (2) Section 2.Conformance (page 5) has one (1) error. It says,
    "UAFP 1.0 specifies one level of compliance corresponding to supporting a SysML TM profile using SysML v 1.3."
    AND
    (3). Section 6.2 Language Architecture (page 11) has two (2) errors. It says,
    " The UAFP specification reuses a subset of UML 2 and SysML 1.3...
    This specification documents the language architecture in terms of the UML 2 and SysML 1.3 parts..."

    All sections and page numbers refer to: http://www.omg.org/members/cgi-bin/doc?c4i/16-05-01.pdf

  • Reported: UAF 1.0b1 — Fri, 19 Aug 2016 15:16 GMT
  • Disposition: Resolved — UAF 1.0
  • Disposition Summary:

    SysML Version

    Make all specific references to SysML comply with the specification's normative reference to SysML 1.4 (see Section 3.2).

    The following three (3) sections and four (4) errors refer to SysML 1.3. They should refer to SysML 1.4

    (1) Section 1.2 Intended Users (page 3) has one (1) error. It says,
    "This document specifies a SysML v1.3 profile to enable practitioners to express architectural model elements and organize them in a
    set of specified viewpoints and views that support the specific needs of systems engineers in the defense and manufacturing
    industries."
    AND
    (2) Section 2.Conformance (page 5) has one (1) error. It says,
    "UAFP 1.0 specifies one level of compliance corresponding to supporting a SysML TM profile using SysML v 1.3."
    AND
    (3). Section 6.2 Language Architecture (page 11) has two (2) errors. It says,
    " The UAFP specification reuses a subset of UML 2 and SysML 1.3...
    This specification documents the language architecture in terms of the UML 2 and SysML 1.3 parts..."

    All sections and page numbers refer to: http://www.omg.org/members/cgi-bin/doc?c4i/16-05-01.pdf

  • Updated: Mon, 16 Oct 2017 15:16 GMT