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

Unified Architecture Framework (UAF) 1.3 RTF — Open Issues

  • Key: UAF13
  • Issues Count: 220
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
UAF13-55 Mission and Mission Threads UAF 1.2 open
UAF13-206 Add Standards Processes UAF 1.2 open
UAF13-207 Traceability between Views, Viewpoints, and Stakeholder Concerns UAF 1.2 open
UAF13-208 Wrong mappings between UAF and DoDAF UAF 1.2 open
UAF13-292 Fig 3.38 UAF 1.2b1 open
UAF13-293 MilestoneDependency UAF 1.2 open
UAF13-294 No Statement of Before and After UAF 1.2 open
UAF13-295 VersionSuccession does not tell which is the successor UAF 1.2 open
UAF13-296 architectureFramework UAF 1.2 open
UAF13-297 Forecast is ambigous UAF 1.2 open
UAF13-298 ComparesTo is ambiguous UAF 1.2 open
UAF13-299 Forecast is ambigous UAF 1.2 open
UAF13-300 ProjectSequence is ambiguous UAF 1.2 open
UAF13-301 missing Element CourseOfAction UAF 1.2b1 open
UAF13-302 ActualService is italics UAF 1.2 open
UAF13-304 ActualService inconsistent UAF 1.2 open
UAF13-303 is it Projects or Project UAF 1.2 open
UAF13-305 MilestoneDependency UAF 1.2 open
UAF13-306 non-named constraint UAF 1.2 open
UAF13-93 Spelling errors UAF 1.2 open
UAF13-90 The description in Ar-Tr is misaligned with picture UAF 1.2 open
UAF13-307 endDate in Attributes wrong UAF 1.2 open
UAF13-84 Achiever - production versus transformation UAF 1.2 open
UAF13-83 ConceptRole is missing in the DMN UAF 1.2 open
UAF13-82 PhaseableElement - Enterprise Vision & Enterprise Goal should not be phaseable UAF 1.2 open
UAF13-81 Motivation - MotivatedBy - Wrong AssociationEndNames UAF 1.2 open
UAF13-80 Abstract Multiplicity Issue - Implements UAF 1.2 open
UAF13-79 Abstract Multiplicity Issue - PerformInContext UAF 1.2 open
UAF13-78 BORO Compliance - ActivityPerformableUnderCondition UAF 1.2 open
UAF13-77 Abstract Multiplicity Issue - IsCapableToPerform UAF 1.2 open
UAF13-76 BORO Compliance - Desirer UAF 1.2 open
UAF13-75 Tags to relationships UAF 1.1 open
UAF13-74 Alignment with ISO 42010 concepts and terminology UAF 1.2 open
UAF13-73 Adopting ISO document structure, formatting and style UAF 1.2 open
UAF13-72 Swap Personnel and Resources rows in UAF grid UAF 1.2 open
UAF13-71 Strategic Viewpoint Designator (St --> Sg) UAF 1.2 open
UAF13-70 Structural and Behavioral Column Grouping in the Grid UAF 1.2 open
UAF13-69 Actualization Viewpoint and Views UAF 1.2 open
UAF13-68 Arch Mgmt Roadmaps View UAF 1.2 open
UAF13-67 Arch Mgmt States View UAF 1.2 open
UAF13-66 Arch Mgmt Processes View UAF 1.2 open
UAF13-65 Architecture Management Taxonomy View UAF 1.2 open
UAF13-64 Portfolio as Enduring Object UAF 1.2 open
UAF13-63 Architectural Description Referencing UAF 1.2 open
UAF13-62 Measurement Kinds in UAF UAF 1.2 open
UAF13-61 Measurements Typical and Actual UAF 1.2 open
UAF13-60 Use Cases UAF 1.2 open
UAF13-59 EA Guide Updates UAF 1.2 open
UAF13-58 Sample Model Updates UAF 1.2 open
UAF13-57 NATO Framework Guide for UAF UAF 1.2 open
UAF13-56 Location Types UAF 1.2 open
UAF13-54 Operational Nodes and Needlines UAF 1.2 open
UAF13-53 Trust Lines between Operational Performers UAF 1.2 open
UAF13-52 Operational Scenarios as Agents UAF 1.2 open
UAF13-51 Architecture is not an Agent nor a Performer UAF 1.2 open
UAF13-50 Capability has no agency, therefore cannot desire a state UAF 1.2 open
UAF13-49 Service as Desirer UAF 1.2 open
UAF13-48 Service Mitigation to perform Security Process and satisfy Security Control UAF 1.2 open
UAF13-47 Service implementing an Operational Agent UAF 1.2 open
UAF13-46 Resource Performer implementing a Service UAF 1.2 open
UAF13-45 Service Performer as special case of Service UAF 1.2 open
UAF13-44 Change <> relationship source to <> element UAF 1.2b1 open
UAF13-43 Enable a Requirement Relationship between AbstractReqirement and Capability UAF 1.2b1 open
UAF13-42 UAF dtc-21-12-07 issue UAF 1.1 open
UAF13-41 UAF dtc-21-12-07 issue UML 2.5b2 open
UAF13-40 UAFML should not redefine SysML method attribute of the Viewpoint Stereotype. UAF 1.2b1 open
UAF13-39 Viewpoint Definition Incomplete, Doesn't Conform to ISO42010 and Cardinalities UAF 1.1 open
UAF13-38 Multiple Use of 'Viewpoint' In Different (ISO 42010 Non-Conforming) Sense with No Definition / Differentiation UAF 1.1 open
UAF13-37 'View Specification' Is Not Defined and Seems Indistinguishable in use from 'Architecture Viewpoint' UAF 1.1 open
UAF13-36 As Defined CapabilityConfiguration is More of a System than System Element Itself UAF 1.1 open
UAF13-35 Claim That No New Terms is Incorrect. Any Terms Need to Be Clearly Defined with Traceability to Source / Master Definition UAF 1.1 open
UAF13-34 subOrganization is Neither a Type Nor a Type of Human Being UAF 1.1 open
UAF13-33 Definition of Tuple is that for a Relationship (Not a Tuple) UAF 1.1 open
UAF13-32 UAF or ISO 42010 Terms Do Not Form Correspondence Rules UAF 1.1 open
UAF13-31 EnterprisePhase Definition Defines a State Not a Phase UAF 1.1 open
UAF13-30 toBe Attribute is an Attribute of the Architecture Not the Architecture Description UAF 1.1 open
UAF13-29 Definition of Concern is Incorrect And Doesn't Conform to ISO 42010. Relationships Don't Match ISO 42010 Conceptual Model UAF 1.1 open
UAF13-28 ResourceArchitecture Definition is that for an Architecture Description Not Architecture UAF 1.1 open
UAF13-27 Lack of Differentiation Between 'Architecture' and 'Architecture Description' UAF 1.1 open
UAF13-26 Ambiguity regarding Stakeholder role expectations UAF 1.1 open
UAF13-25 UAFElement.conformsTo and ProtocolImplementation.implements alignment and reification with fUML UAF 1.2 open
UAF13-24 LocationHolder.physicalLocation and requiredEnvironment as properties of Assets UAF 1.2 open
UAF13-23 Support UML::Property.defaultValue as part of UAF::MeasurableElement.actualMeasurementSet UAF 1.2 open
UAF13-22 Alignment of UAF::*Method with IsCapableToPerform UAF 1.2 open
UAF13-21 UAF::*Constraint can’t be used with SysML::ConstraintBlocks UAF 1.2 open
UAF13-20 Refine the DMM Impliments implementation in ML UAF 1.2 open
UAF13-19 measurementSet tag derivation from actualMeasurementSets UAF 1.2 open
UAF13-18 UML::Property.defaultValue has upper multiplicity of 1 even though Property is a MultiplicityElement UML 2.5.1 open
UAF13-17 UAF::*ControlFlow not possible from most UML::ActivityNodes UAF 1.2 open
UAF13-16 Support for SysML::FullPort as alternate for UAF::*Ports UAF 1.2 open
UAF13-15 Interoperability with UML and SysML elements UAF 1.2 open
UAF13-14 Extention of UAF "Action"s from UML::CallBehaviorAction does not support usage of UAF::"Method"s in Process and Connectivity Views UAF 1.2 open
UAF13-13 XMI file with outdated UML 1.x version UAF 1.1 open
UAF13-12 Error UAF 1.1 open
UAF13-11 Reference to "Services Sequences" view in traceability tables UAF 1.1 open
UAF13-10 Error in table numbering UAF 1.1 open
UAF13-9 UAF DMM PDF - Table of Contents is out-of-sync with chapter numbering UAF 1.1 open
UAF13-8 UAF extensions of CallBehaviorAction should also support CallOperationAction UAF 1.1b1 open
UAF13-7 Actual Resource Relationship description incorrect UAF 1.1 open
UAF13-6 Actual Resources domain name change UAF 1.1 open
UAF13-5 Group architecture items into portfolios and portfolio segments UAF 1.1 open
UAF13-4 Need to identify addtional concept to support Acquistion Ref Model Usage UAF 1.1 open
UAF13-3 ISO Date Time needs to be refactored UAF 1.1 open
UAF13-2 Is OrganizationInEnterprise to restrained? UAF 1.0 open
UAF13-1 Stereotypes for flowProperties UAF 1.0b2 open
UAF13-205 Definition of Standard Operational Activity clarified UAF 1.2 open
UAF13-204 *ActivityAction UAF 1.2 open
UAF13-203 Decision Nodes not a UAF element UAF 1.2 open
UAF13-183 For Exchanges UAF 1.2 open
UAF13-184 Missing ServiceParameter UAF 1.2 open
UAF13-185 Missing Service on ServiceExchangeItem? UAF 1.2 open
UAF13-186 View Specification - Rs-Sr - Undefined Concerns, Missing Elements, Shouldn't Describe Function, Missing Triples - Measurement, Protocol UAF 1.2 open
UAF13-187 PropertySet should extend <> Classifier UAF 1.2 open
UAF13-190 'View Specification' Rs-Sr Resources Structure - Every ResourcePerformer Requires One or More Measurements. Asset is a PropertySet Semantically Incorrect UAF 1.2 open
UAF13-188 Need to be specific when extending things UAF 1.2 open
UAF13-189 No Added Extensions UAF 1.2 open
UAF13-191 PropertySet - Incorrect Definition, Specialisation Short Circuits Metamodel - 'System PropertySetGeneralization Viewpoint' etc. Triples Not in any UAF Architecture View UAF 1.2 open
UAF13-192 CompetenceToConduct in two places UAF 1.2 open
UAF13-193 CompetenceToConduct in two places UAF 1.2 open
UAF13-194 Function in some places instead of Activity UAF 1.2 open
UAF13-195 InteractionMessage has no metamodel UAF 1.2 open
UAF13-196 No Description for CapabilityRoleDependency UAF 1.2 open
UAF13-197 no metamodel for StrategicExchangeItem UAF 1.2 open
UAF13-198 Missing metamodel for StrategicInformation UAF 1.2 open
UAF13-182 Method is wrong semantics UAF 1.2 open
UAF13-181 Sm is not defined UAF 1.2 open
UAF13-180 the two UAF Grids are different UAF 1.2 open
UAF13-179 Ar-Tr is missing UAF 1.2 open
UAF13-178 View Specification Rs-Tx Resources Taxonomy - ResourceExchanges, Measurements Do Not form Part of a Resource Taxonomy UAF 1.2 open
UAF13-177 OperationalArchitecture - an AD by Definition Specialises OperationalAgent and Architecture? UAF 1.2 open
UAF13-176 8.1.10 View Specifications::Standards::Traceability - Sd-Tr - Incorrect Concerns. No Triples Provided to Match Concerns. Unclear Whether Trace or Conformance UAF 1.2 open
UAF13-175 View Specification Op-Pr Operational Processes BPMN Semantics - Invalid Concern, Representation in an Agnostic Metamodel UAF 1.2 open
UAF13-174 OperationalActivityEdge is a UML (Activity Diagram) Implementation of OperationalExchange - Shouldn't be in Agnostic DMM [Not Required] UAF 1.2 open
UAF13-173 mismatch Concerns UAF 1.2 open
UAF13-172 Appendix B - Glossary - Change of ISO 42010 'Architecture Viewpoint' to 'Viewpoint'. UAF Actually 'Viewpoint' Has at Least 2 Meanings, Only 1 Defined UAF 1.2 open
UAF13-171 3.1 Architecture Management Concepts - 'UAF Meaning' - Any Semantic Difference from ISO/IEC/IEEE 42010 Invalidates Any Claim of Conformance UAF 1.2 open
UAF13-170 Invalid Version of ISO/IEC/IEEE 42010 - '2021' - Correct Year is 2022 UAF 1.2 open
UAF13-169 2.2 Core Principles - Compliance Levels - Doesn't Define Compliance Levels. Not Consistent With UAF DMM Conformance Types. OMG Define UML Profile ... UAF 1.2 open
UAF13-168 9.1.1 ArchitecturalReference - Incorrect Name (Not a Reference to Architecture), Not a Tuple, Incorrect Definition. Not Needed - Use a Trace UAF 1.2 open
UAF13-167 Am-Mv Architecture Principles View Specification Doesn't Provide the Elements to Address the Concerns Identified. No Triples Defined. UAF 1.2 open
UAF13-166 7.2 Viewpoint Interraltionships - Incorrect Termininology, Doesn't Show Any Relationships. (MODAF) Viewpoints Do Not Have any Abstraction UAF 1.2 open
UAF13-165 7.3 DMM Legend - 'External Type' Shouldn't Be Present in an Agnostic Spec (the DMM is Not a UML Profile) UAF 1.2 open
UAF13-164 UAF Grid - Inaccurate Text. Gaps Don't Indicate Donor AF Coverage. Non- View Specification Content. Needs Donor AF to UAF Mapping in this Document UAF 1.2 open
UAF13-163 The UML Profile for the UAF Does Not Specify UAF Architecture Views or View Content - No Mechanism Within the XML UAF 1.2 open
UAF13-162 Incorrect Title '1.4 Layered Progression of Architecture Definition' - Should be 1.4 Layered Progression of Architecture Description' UAF 1.2 open
UAF13-161 Consistency/Lack of Standardisation - 'stakeholder viewpoint', vs MODAF::viewpoint vs ISO 42010 Architecture Viewpoint UAF 1.2 open
UAF13-160 The Master / Root Normative Specification to Which the EA Guide Conforms is the UAF DMM Not a UML Profile Implementation (UAFML) UAF 1.2 open
UAF13-159 A Repository Does Not Store Architecture - It Stores Architecture Description(s) - Differentiation of Duck vs Photo of Duck UAF 1.2 open
UAF13-158 Consistency - 'ISO420:Architecture Description' vs 'UAF:ArchitecturalDescription' UAF 1.2 open
UAF13-157 'Reference Architecture' Should be 'Reference Architecture Description' UAF 1.2 open
UAF13-156 Consistency - 'Cross Cutting Viewpoints' Are Not ISO42010:Architecture Viewpoints - They're MODAF::Viewpoints - Same Word, Different Meaning UAF 1.2 open
UAF13-155 Incorrect of the Term 'Modelling Language' As Synonym for a UML Profile UAF 1.2 open
UAF13-154 User Guide - The User Cannot Use the UAFML - they Use a Modelling Tool with Added Behaviours. Incorrect Claims for UAFML. UAFML benefits / features unclear UAF 1.2 open
UAF13-153 Incorrect Use of MODAF::Viewpoint in Grid UAF 1.2 open
UAF13-152 Incorrect Inclusion of UAF Architecture Viewpoints in an AD. Inconsistent and Incorrect Definition of 'Concern'. A StrategicPhase is Not a System UAF 1.2 open
UAF13-151 Inconsistent Definition of 'Architecture'. Unintelligable Note. Incorrect Reference. Step Name Should be 'Define Architecture Description Drivers and Challenges' UAF 1.2 open
UAF13-150 'Definition' Seems to be an Attribute of Any UAFElement - It Shouldn't Be a Separate Element (Inconsistent Representation of Attributes) UAF 1.2 open
UAF13-149 Figure 9:118 Caption ' ArchitectureMetadataDefinition' Includes the Following Metamodel Element Title ('Definition') UAF 1.2 open
UAF13-148 View Specification - Am-Pr Architecture Development Method Name Doesn't Match Subject. Missing (No) Triples to Address Concerns UAF 1.2 open
UAF13-147 Tables Refer to a View Specification Am-Tx Architecture Extensions that Doesn't Exist + Table Numbering Error Table 1:2 UAF 1.2 open
UAF13-146 UAF Grid and text refers to 'Architecture Extensions' View Specification - View Specification Doesn't Exist UAF 1.2 open
UAF13-145 View Specification Am-Tr Architecture Traceability - Only 1 Relationship Element Provided, Unable to Describe Traces to External Sources UAF 1.2 open
UAF13-144 ActualPerson is not a Distinct Type. Inconsistent Representation of Individual vs Type/Class wrt Other Metamodel Elements (ActualXXX Elements Contradict Class Mechanism)) UAF 1.2 open
UAF13-143 ServiceRole is Neither a Type of Nor Part of a Service UAF 1.2 open
UAF13-142 'Usage of + 'Whole:Part' - ProtocolLayer is Not a Distinct Metamodel Concept - It is a Reflexive Whole:Part Relationship on Protocol UAF 1.2 open
UAF13-141 8.1.4 View Specifications::Operational::Sequences::Operational Sequences View Specification Doesn't Provide Any Sequencing Triples to Address Its Concerns UAF 1.2 open
UAF13-140 8.1.4 View Specifications::Operational::Sequences::Operational Sequences View Spec Includes UML Metaclasses UAF 1.2 open
UAF13-139 Operational Structure Viewpoint Identifier Should Be 'Op-Sr' Not 'Op-St' (which duplicates Operational States Viewpoint Identifier) UAF 1.2 open
UAF13-138 8.1.1 View Specifications::Architecture Management::States::Architecture Status has Nothing to Do with 'Architecture' - It Describes the State of the Architecture Description UAF 1.2 open
UAF13-137 Missing Traceability and Evidence to Support Claim of Implementation of DMM by the UAFP (UAFML) UAF 1.2 open
UAF13-136 Type 1 Conformance Incorrectly Uses MODAF::Viewpoint Term as Collection of ISO42010::Architecture Viewpoiint Definitions UAF 1.2 open
UAF13-135 1.1 Introduction, 1.2 UAF Background Incorrectly Uses 'Architecture', 'Architectures' to Refer to Architecture Description UAF 1.2 open
UAF13-134 UAF View Specifications Don't Use UAF Identifiers and Depend on Package Striucture + Incorrect Traceability Doc Identifier UAF 1.2 open
UAF13-133 View Specifications::Motivation:Requirements Doesn't Permit Requirement traces to Requirement, Requirement refines Requirement UAF 1.2 open
UAF13-132 ServiceArchitecture Defined as AD, ServiceArchitecture Is not a Service as Stated UAF 1.2 open
UAF13-131 View Specifications::Motivation::Motivation: Requirements - No Direction for Satisy, Refine, Verify + Duplicate Trace - Requirement Relationship UAF 1.2 open
UAF13-130 Metadata - category refers to DCMI abstract (not a category) / dublinCoreTag. DCMI Only Applies to Artefacts (Documents, Sound, Video, Text) Not any UAFElement UAF 1.2 open
UAF13-129 View Specifications::Summary & Overview::Summary & Overview - Missing Relationships and Triples, Concerns Not Defined UAF 1.2 open
UAF13-128 UAFElement - Attributes Missing. URI incorrectly defined UAF 1.2 open
UAF13-127 Metadata, ArchitectureMetadata Not Defined Correctly. ArchitectureMetadata duplicates Metadata - Both Define Metadata for an AD UAF 1.2 open
UAF13-126 UAFElement Definition Doesn't Define Concept - Is This Really 'Architecture Description Element'? UAF 1.2 open
UAF13-125 Figure 8-14 Strategic Structure Does Not Provide Elements to match definition of View Specifications::Strategic::Structure::Strategic Structure UAF 1.2 open
UAF13-124 Figure 9:164 - ActualEnterprisePhase Class Hierarchy Incorrect & Doesn't Match Definitions of Types - An Endeavour etc Isn't a Time Period UAF 1.2 open
UAF13-123 Appendix A. Traceability. Mapping Results Should Show Unmapped Elements - on UAF Side and on Target Side UAF 1.2 open
UAF13-122 UAF Elements Missing from SysML Mapping in Table 4.1 UAF 1.2 open
UAF13-121 Figure 9:134 / 8:86 Undefined DMM Elements - Refine, Trace, Refine, Verifiy, Requirement. Requirement not a UAF Element? UAF 1.2b1 open
UAF13-120 Figure 9:129 ArchitecturalDescription - Multiplicities Incorrect UAF 1.2b1 open
UAF13-119 Standards Taxonomy Missing conformsTo Element? UAF 1.2b1 open
UAF13-118 Figure 8:92, 8:93, 8:94 Do Not define the UAF Triples Needed to Address the Concerns Framed by the View Specifications::Other::BPMN View Spec UAF 1.2b1 open
UAF13-117 BPMN and Other ADLs Should Not be in the Agnostic DMM - Should be in Either UAFML or a Similar ADL-Specific Specification UAF 1.2b1 open
UAF13-116 Figure 8:2 Architecture Views Does Not Conform to ISO/IEC/IEEE 42010 - Multiplicities, Naming, Direction [repeat - Tracker Now Using Correct OMG Identifiers] UAF 1.2b1 open
UAF13-115 Consistency - Overlapping Concerns UAF 1.2b1 open
UAF13-114 The UAFML is a UML Profile Not Itself a Modelling Language - Only the One Individual Use UAF 1.2b1 open
UAF13-113 Centre Justification of Text UAF 1.2b1 open
UAF13-112 Structure of References Section is Incorrect wrt Normative Docs. It also Needs to Identify Which Normative Documents Apply to What Parts of the UAF UAF 1.2b1 open
UAF13-111 Many Normative References Are Not Sources of Requirements Against Which Conformance Assessed and Hence Not Normative UAF 1.2b1 open
UAF13-110 Issue Tracker Using Incorrect OMG Identifier? dtc/21-12-06 Required for Ticket But formal/22-07-02 on Front Cover of DMM Specification UAF 1.2b1 open
UAF13-109 Alignment of Terminology to 42010, Relationships Not Labelled UAF 1.2 open
UAF13-108 Stereotype for ResourceInteractionScenario is missing UAF 1.2 open
UAF13-107 ResourceInteractionScenario in wrong chapter in the domain metamodel specification UAF 1.2 open
UAF13-106 Signals should be ExchangeItems UAF 1.2 open
UAF13-105 ServiceExchangeItem missing things UAF 1.2 open
UAF13-104 missing definition of Cost UAF 1.2 open
UAF13-103 ClassificationAttributes all Strings are missing multiplicities UAF 1.2 open
UAF13-102 BillingItem wrong description UAF 1.2 open
UAF13-101 should have multiplicity of [0] UAF 1.2 open
UAF13-85 EvokedBy, ambigous description UAF 1.2 open
UAF13-86 DataElement is mentioned UAF 1.2 open
UAF13-87 Architecture Management Sequences UAF 1.2 open
UAF13-91 Incosistent terminology between profile and metamodel UAF 1.2 open
UAF13-99 Non-Security Risks UAF 1.2 open
UAF13-97 Information elements require better definition of relationships UAF 1.2 open
UAF13-96 Standards need to be decomposable UAF 1.2 open
UAF13-88 Security Control should be a kind of Capability not a kind of Requirement UAF 1.2 open
UAF13-92 Operational Performer not linked to the Operational Performers in the model UAF 1.2 open
UAF13-100 Personnel::States example error UAF 1.2 open
UAF13-98 List of deprecated elements UAF 1.2 open
UAF13-95 Incorrect definition for SubOrganization UAF 1.2 open
UAF13-94 incorrect acronym definition UAF 1.2 open
UAF13-89 There is a View Description for Ar-Tr , but that square of the Grid is blank UAF 1.2 open

Issues Descriptions

Mission and Mission Threads

  • Key: UAF13-55
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

    See attached slides.

    The UAF Modeling Language (UAFML) especially suited for modeling an enterprise and as such it is appropriate for modeling a large and complex mission architecture along with its variety of scenarios, vignettes, MTs, METs, etc. The following extensions to UAF will provide support for Mission Engineering and alignment with best practice.
    The following elements need to be added to UAF to support Mission Engineering.
    1 Mission The task, together with the purpose, that clearly indicates the action to be taken and the reasoning behind the mission. (JP 1-02)
    2 MissionThread A sequence of end-to-end mission tasks, activities, and events presented as a series of steps to achieve a mission. (OUSD(R&E))
    3 ActualMission A particular mission to accomplish assigned mission objectives
    4 ActualMissionPhase A particular phase in the accomplishment of an overall actual mission
    5 MissionScenario Description of the geographical location and timeframe of the overall conflict. A scenario includes information such as threat and friendly politico-military contexts and backgrounds, assumptions, constraints, limitations, strategic objectives, and other planning considerations. (OUSD(R&E))
    6 MissionVignette Same contents as a MissionScenario except that it can represent small, ideally self-contained parts of a scenario. (OUSD(R&E))
    7 ActualMissionScenario A particular mission scenario within which an actual mission is to be accomplished
    8 ActualMissionVignette A particular mission vignette within which an actual mission is to be accomplished
    9 MissionTask A clearly defined action or activity specifically assigned to a system, individual or organization that must be completed. (MEG 2.0).
    10 MissionTaskAction The usage of a MissionTask within a MissionThread.
    11 MissionEngineeringThread A sequence of end-to-end mission-related resources, functions, actions, states, and events presented as a series of steps that supports a mission thread
    12 ConflictsWith Tuple that indicates elements acting against or in opposition to each other. This means that there are elements in the model that disagree about something important or are incompatible with each other in some way
    13 Opposes Tuple that indicates an open clash between two opposing groups (or individuals). This means that elements in the model are fighting against each other or are providing strong resistance to progress towards some goals
    14 OpposableElement Type of element that is categorized to allow for it to have an Opposes relationship to some other opposable element.
    15 DesignationKind Defines the type of structural element with respect to purpose, intent and capabilities of that element.
    16 Doctrine A formal expression of military knowledge and thought, accepted as being relevant at a given time, which covers the nature of conflict, the preparation of the military forces for conflict, and the method of engaging in conflict to achieve success... it is descriptive rather than prescriptive, requiring judgement in application.
    17 Defines A tuple that links the Mission and the Activity that implements it.
    18 MissionKind An enumerated list of kinds of missions. These include:
    19 Battle A hostile encounter between opposing military forces
    20 Campaign A series of related major operations aimed at achieving strategic and operational objectives within a given time and space. (JP 5-0)
    21 Engagement A tactical conflict, usually between opposing lower echelons maneuver forces. See also battle; campaign. (JP 3-0)
    22 MajorOperation A series of tactical actions (battles, engagements, strikes) conducted by combat forces, coordinated in time and place, to achieve strategic or operational objectives in an operational area. (JP 3-0)
    23 NationalPolicy A broad course of action or statements of guidance adopted by the government at the national level in pursuit of national objectives. (JP 1)
    24 Other A different kind of mission.
    25 SmallUnitAndCrewAction Small unit and Crew Action is the combat deployment of platoons and smaller units in a particular strategic and logistic environment
    26 TheaterStrategy An overarching construct outlining a combatant commander’s vision for integrating and synchronizing military activities and operations with the other instruments of national power in order to achieve national strategic objectives. See also national military strategy; national security strategy; strategy. (JP 3-0)
    27 ForceDesignation Indicates whether the structural element is an enemy, ally, neutral or other force. The colors may vary according to country so can be replaced as required. These include:
    28 BlueForce Structural elements corresponding to the instigating or friendly force.
    29 RedForce The structural element is an enemy force.
    30 GreenForce The structural element is an ally.
    31 GrayForce The structural element is a third party force.
    32 Unknown The structural element is unknown.
    33 WhiteForce The structural element is neutral.
    For support of Doctrine, a new element will need to be created called Doctrine which is a subtype of both requirement and standard. It will contain the following fields:
    1 createdBy The organization or creator of the standard or doctrine.
    2 publishedBy An entity responsible for making the resource available.
    3 createdStandards A relationship between an actual organization and the standards created by that organization.
    4 publishedStandards A relationship between an actual organization and the standards published by that organization.
    For enterprise architectures and mission engineering we need to be able to define a new type of a constraint which is an assumption.
    Assumption EnumerationLiteral added to RuleKind Enumeration indicating that the element is accepted as true or as certain to happen, without proof.
    The following Diagrams will need to be created to support modeling of Missions:
    1 Resources Processes: Mission Engineering Threads
    Stakeholders: Solution Providers, Systems Engineers, IT Architects.
    Concerns: captures activity based behavior and flows performed by resources and organizational assets.
    Definition: describes the functions that are normally conducted in the course of implementing operational activity(ies) in support of capability(ies). It describes the functions, their Inputs/Outputs, function actions and flows between them.
    Recommended Implementation: SysML Activity Diagram, SysML Block Definition Diagram."
    2 Operational Processes: Mission Threads "[Need a new description according to the template below]
    Stakeholders: Business Architect, Systems Engineers, Enterprise Architects
    Concerns: captures activity based behavior and flows performed by mission actors and related operational and strategic assets.
    Definition: describes the activities that are normally conducted in the course of achieving business goals that support a capability. It describes operational activities, their Inputs/Outputs, operational activity actions and flows between them.
    Recommended Implementation: SysML Activity Diagram, SysML Block Definition Diagram, BPMN Process Diagram."
    3 Strategic Processes: Mission "[Need a new description according to the template below]
    Stakeholders: Program/Project Managers, Portfolio Managers, Enterprise Architects, Executives.
    Concerns: capability phasing.
    Definition: shows the relationship between strategic phases and the Capabilities that are intended to be developed during the strategic phases, and the actual organizations involved.
    Recommended Implementation: SysML Block Definition Diagram."
    4 Parameters: Mission Vignette and Scenario "[Need a new description according to the template below]
    Stakeholders: Capability owners, Systems Engineers, Solution Providers.
    Concerns: defines the environments and conditions for execution of mission(s)+C10
    Definition: shows the elements and relationships that are involved in defining the environments and conditions applicable to capability, operational concept or set of systems.
    Recommended Implementation: SysML Block Definition Diagram."

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:27 GMT
  • Updated: Mon, 28 Oct 2024 16:09 GMT
  • Attachments:

Add Standards Processes

  • Key: UAF13-206
  • Status: open  
  • Source: Boeing ( Ms. Sharon Fitzsimmons)
  • Summary:

    Many Standards prescribe particular processes (such as ISO 15288, DO-356A, etc). Having a Standards Activity with Standards Process Flows would allow us to model the Standards as processes with inputs and outputs, then show how Operational processes ConformTo the Standards Process.

  • Reported: UAF 1.2 — Fri, 21 Jun 2024 13:40 GMT
  • Updated: Tue, 10 Sep 2024 22:04 GMT

Traceability between Views, Viewpoints, and Stakeholder Concerns

  • Key: UAF13-207
  • Status: open  
  • Source: Boeing ( Ms. Sharon Fitzsimmons)
  • Summary:

    Viewpoints are defined as a convention for creation, interpretation, and use of an architecture to frame one or more stakeholder concerns.
    Views are defined as the information item governed by the Viewpoint that communicates some aspect of an architecture.
    Stakeholder Concerns relate to a Viewpoint, and to a View only through its "governed by" relationship to the Viewpoint.
    Views may only be governed by one Viewpoint, but Viewpoints can govern many Views.

    The problem is that the traceability for a Stakeholder Concern only comes through the Viewpoint (not the View itself) and thus every View that is governed by the Viewpoint is said to relate to every Stakeholder Concern framed by the Viewpoint. This may not be true.

    For instance, I will use Resource Connectivity diagrams as an example for a Viewpoint. I have multiple stakeholders that may want to see a Resources Connectivity diagram. One might want to understand the internal connectors of the system. One might want to understand the flow properties of the system. One might want to understand the external connections to the system. If I make three views (one that shows internal connections, one that shows flow properties, and one that shows external connections), then all three Views are governed by the Resource Connectivity Viewpoint, and every stakeholder Concern can be addressed by Resource Connectivity, but not every View does address every stakeholder Concern. Further, I can't use the model relationships to filter my Views by Stakeholder Concern because the traceability provides every view that is governed by the Viewpoint.

    I can solve this by further specifying my Viewpoints. I can specialize Resource Connectivity Viewpoint and require external connections, or internal connections, as related to the Stakeholder Concern. This requires a very high degree of specificity in my viewpoints to ensure that a query across one Stakeholder Concern does not return Views intended for other Stakeholder Concerns.

    It may be better to trace Stakeholder Concerns to the Views themselves (having an "answers" or some other relationship) to allow for limitation on this query.

  • Reported: UAF 1.2 — Tue, 25 Jun 2024 18:40 GMT
  • Updated: Tue, 10 Sep 2024 21:52 GMT

Wrong mappings between UAF and DoDAF

  • Key: UAF13-208
  • Status: open  
  • Source: Booz Allen ( Charlie Zhang)
  • Summary:

    Op-If is mapped with DIV-1, and Rs-If is mapped with DIV-2.

    According to Appendix A the correct mappings should be: Op-If <-> DIV-2, Rs-If <-> DIV-3

  • Reported: UAF 1.2 — Thu, 11 Jul 2024 19:36 GMT
  • Updated: Tue, 10 Sep 2024 21:45 GMT

Fig 3.38


MilestoneDependency

  • Key: UAF13-293
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    MilestoneDependency should be renamed MilestoneSequence to
    be consistent with the definition and consistent with ProjectSequence

    Dependency is too overloaded

  • Reported: UAF 1.2 — Sat, 17 Aug 2024 20:13 GMT
  • Updated: Tue, 10 Sep 2024 21:40 GMT

No Statement of Before and After

  • Key: UAF13-294
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    in the standard there is no statement for Sequence about whether the client is assumed to be before or after the supplier... one could
    reason it either way... clients should always be dependent on suppliers... and because suppliers should have to finish before
    clients can proceed it is assumed that the suppliers are the before and the clients are the after... but this should be made explicit

  • Reported: UAF 1.2 — Sun, 18 Aug 2024 01:17 GMT
  • Updated: Tue, 10 Sep 2024 21:30 GMT

VersionSuccession does not tell which is the successor

  • Key: UAF13-295
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    VersionSuccession does not tell which is the successor in the documentation does not explain which is the successor to whom... the client or the supplier... I am presuming that the client is dependent on the supplier so the client is the newer version and the supplier is the older version... needs to be explicit in the standard

  • Reported: UAF 1.2 — Sun, 18 Aug 2024 01:34 GMT
  • Updated: Tue, 10 Sep 2024 21:07 GMT

architectureFramework

  • Key: UAF13-296
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    architectureFramework as a String should be in the Attributes... and shown as such in the diagram and the text below needs to be altered

  • Reported: UAF 1.2 — Sun, 18 Aug 2024 01:49 GMT
  • Updated: Tue, 10 Sep 2024 21:04 GMT

Forecast is ambigous

  • Key: UAF13-297
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Forcast needs to specify explicitly in the documentation that the supplier end is the older subject and the client end is the newer subject

  • Reported: UAF 1.2 — Sun, 18 Aug 2024 02:00 GMT
  • Updated: Tue, 10 Sep 2024 20:58 GMT

ComparesTo is ambiguous

  • Key: UAF13-298
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    ComparesTo is ambiguous ... which is the desired, which is the achieved... presuming desired is the supplier and achieved is the client but should be made explicit in the standard

  • Reported: UAF 1.2 — Sun, 18 Aug 2024 02:05 GMT
  • Updated: Tue, 10 Sep 2024 20:57 GMT

Forecast is ambigous

  • Key: UAF13-299
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Forcast needs to specify explicitly in the documentation that the supplier end is the older subject and the client end is the newer subject

  • Reported: UAF 1.2 — Sun, 18 Aug 2024 13:47 GMT
  • Updated: Tue, 10 Sep 2024 20:56 GMT

ProjectSequence is ambiguous

  • Key: UAF13-300
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    ProjectSequence is ambiguous ... needs to specify before and after with supplier and client

  • Reported: UAF 1.2 — Sun, 18 Aug 2024 13:49 GMT
  • Updated: Tue, 10 Sep 2024 20:54 GMT

missing Element CourseOfAction

  • Key: UAF13-301
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    UAF is missing a CourseOfAction element... would suggest looking at ArchiMate's version of CourseOfAction as an example

  • Reported: UAF 1.2b1 — Mon, 19 Aug 2024 13:45 GMT
  • Updated: Tue, 10 Sep 2024 20:48 GMT

ActualService is italics

  • Key: UAF13-302
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Figure 9:336 – ActualService is italics yet it is not abstract... need to change

  • Reported: UAF 1.2 — Thu, 22 Aug 2024 15:31 GMT
  • Updated: Tue, 10 Sep 2024 20:47 GMT

ActualService inconsistent

  • Key: UAF13-304
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    ActualService in Metamodel is abstract... it is not in profile... need to fix

  • Reported: UAF 1.2 — Thu, 29 Aug 2024 22:20 GMT
  • Updated: Tue, 10 Sep 2024 20:46 GMT

is it Projects or Project

  • Key: UAF13-303
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    some places are Project some place are Projects

    e.g.
    View Specifications::Projects::Roadmap::Project Roadmap

  • Reported: UAF 1.2 — Thu, 29 Aug 2024 22:18 GMT
  • Updated: Tue, 10 Sep 2024 20:42 GMT

MilestoneDependency

  • Key: UAF13-305
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    need to have a separate MilestoneSequence from MilestoneDependency

    and should add a ProjectDepdency as well

  • Reported: UAF 1.2 — Thu, 29 Aug 2024 22:21 GMT
  • Updated: Tue, 10 Sep 2024 20:39 GMT

non-named constraint

  • Key: UAF13-306
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Figure 9:321 – ActualProjectMilestone
    Constraints
    [1] unnamed1
    startTime=endTime

    non-named constraint

    also ActualState has attributes startDate and endDate... not startTime and endTime

  • Reported: UAF 1.2 — Thu, 29 Aug 2024 22:25 GMT
  • Updated: Tue, 10 Sep 2024 20:30 GMT

Spelling errors

  • Key: UAF13-93
  • Status: open  
  • Source: Northwestern Polytechnical University ( Qiucen Fan)
  • Summary:

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

  • Reported: UAF 1.2 — Thu, 13 Apr 2023 15:09 GMT
  • Updated: Tue, 10 Sep 2024 20:22 GMT

The description in Ar-Tr is misaligned with picture

  • Key: UAF13-90
  • Status: open  
  • Source: Akademiska sjukhuset ( Hans Natvig)
  • Summary:

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

  • Reported: UAF 1.2 — Mon, 31 Oct 2022 13:13 GMT
  • Updated: Tue, 10 Sep 2024 20:22 GMT

endDate in Attributes wrong


Achiever - production versus transformation

  • Key: UAF13-84
  • Status: open  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

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

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

  • Reported: UAF 1.2 — Mon, 25 Jul 2022 07:19 GMT
  • Updated: Mon, 2 Sep 2024 01:01 GMT
  • Attachments:

ConceptRole is missing in the DMN

  • Key: UAF13-83
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

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

  • Reported: UAF 1.2 — Wed, 20 Jul 2022 13:39 GMT
  • Updated: Mon, 2 Sep 2024 01:01 GMT

PhaseableElement - Enterprise Vision & Enterprise Goal should not be phaseable

  • Key: UAF13-82
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

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

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

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

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

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

  • Reported: UAF 1.2 — Wed, 13 Jul 2022 16:08 GMT
  • Updated: Mon, 2 Sep 2024 01:01 GMT

Motivation - MotivatedBy - Wrong AssociationEndNames

  • Key: UAF13-81
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

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

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

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

  • Reported: UAF 1.2 — Fri, 8 Jul 2022 16:01 GMT
  • Updated: Mon, 2 Sep 2024 01:01 GMT

Abstract Multiplicity Issue - Implements

  • Key: UAF13-80
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Multiple conflicting [1.1] multiplicities on Implements

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

  • Reported: UAF 1.2 — Thu, 7 Jul 2022 15:27 GMT
  • Updated: Mon, 2 Sep 2024 01:01 GMT

Abstract Multiplicity Issue - PerformInContext

  • Key: UAF13-79
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Multiple conflicting [1.1] multiplicities on PerformInContext

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

  • Reported: UAF 1.2 — Thu, 7 Jul 2022 14:02 GMT
  • Updated: Mon, 2 Sep 2024 01:01 GMT

BORO Compliance - ActivityPerformableUnderCondition

  • Key: UAF13-78
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

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

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

  • Reported: UAF 1.2 — Thu, 7 Jul 2022 13:23 GMT
  • Updated: Mon, 2 Sep 2024 01:01 GMT

Abstract Multiplicity Issue - IsCapableToPerform

  • Key: UAF13-77
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Multiple conflicting [1.1] multiplicities on IsCapabletoPerform.

  • Reported: UAF 1.2 — Thu, 7 Jul 2022 12:53 GMT
  • Updated: Mon, 2 Sep 2024 01:01 GMT

BORO Compliance - Desirer

  • Key: UAF13-76
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

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

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

  • Reported: UAF 1.2 — Thu, 7 Jul 2022 11:01 GMT
  • Updated: Mon, 2 Sep 2024 01:01 GMT

Tags to relationships

  • Key: UAF13-75
  • Status: open  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    Reported in behalf of Boeing.

    Continuing the progress we have been doing on getting rid of tag properties and replacing them by dependency type of relationships, there are still some tag properties to be replaced between the view, viewpoint, concern, architecture description, and stakeholder. Having tags, they cannot be properly displayed on the diagram, where dependencies can.

  • Reported: UAF 1.1 — Tue, 7 Jun 2022 14:25 GMT
  • Updated: Mon, 2 Sep 2024 01:01 GMT

Alignment with ISO 42010 concepts and terminology

  • Key: UAF13-74
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:48 GMT
  • Updated: Mon, 2 Sep 2024 01:01 GMT

Adopting ISO document structure, formatting and style

  • Key: UAF13-73
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:48 GMT
  • Updated: Mon, 2 Sep 2024 01:01 GMT

Swap Personnel and Resources rows in UAF grid

  • Key: UAF13-72
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

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

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:47 GMT
  • Updated: Mon, 2 Sep 2024 01:01 GMT

Strategic Viewpoint Designator (St --> Sg)

  • Key: UAF13-71
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:47 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

Structural and Behavioral Column Grouping in the Grid

  • Key: UAF13-70
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

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

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

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:46 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

Actualization Viewpoint and Views

  • Key: UAF13-69
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

    See attached slides

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:42 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Arch Mgmt Roadmaps View

  • Key: UAF13-68
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:39 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Arch Mgmt States View

  • Key: UAF13-67
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:38 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Arch Mgmt Processes View

  • Key: UAF13-66
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:35 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Architecture Management Taxonomy View

  • Key: UAF13-65
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

    See attached slides

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:35 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Portfolio as Enduring Object

  • Key: UAF13-64
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

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

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

    See attached slides.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:33 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Architectural Description Referencing

  • Key: UAF13-63
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

    See attached slides.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:33 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Measurement Kinds in UAF

  • Key: UAF13-62
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

    See attached slides.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:32 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Measurements Typical and Actual

  • Key: UAF13-61
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

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

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

    See attached slides.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:31 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Use Cases

  • Key: UAF13-60
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

    Need to add Use Cases as a modeling construct in UAF

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:30 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

EA Guide Updates

  • Key: UAF13-59
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:30 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

Sample Model Updates

  • Key: UAF13-58
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:29 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

NATO Framework Guide for UAF

  • Key: UAF13-57
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:29 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

Location Types

  • Key: UAF13-56
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

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

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

    See attached slides.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:28 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Operational Nodes and Needlines

  • Key: UAF13-54
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

    See attached slides.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:27 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Trust Lines between Operational Performers

  • Key: UAF13-53
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:25 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Operational Scenarios as Agents

  • Key: UAF13-52
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

    See attached slides.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:24 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Architecture is not an Agent nor a Performer

  • Key: UAF13-51
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

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

    See attached slides.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:23 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Capability has no agency, therefore cannot desire a state

  • Key: UAF13-50
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

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

    See attached slides.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:22 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Service as Desirer

  • Key: UAF13-49
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

    See attached slides.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:21 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Service Mitigation to perform Security Process and satisfy Security Control

  • Key: UAF13-48
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

    See attached briefing.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:19 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Service implementing an Operational Agent

  • Key: UAF13-47
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

    See attached briefing.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:13 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Resource Performer implementing a Service

  • Key: UAF13-46
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

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

    See attached briefing.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:13 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Service Performer as special case of Service

  • Key: UAF13-45
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

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

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:09 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT
  • Attachments:

Change <> relationship source to <> element

  • Key: UAF13-44
  • Status: open  
  • Source: MITRE ( Ms. Rae Anderson)
  • Summary:

    Currently, a <<SecurityControl>> is the source of the <<mitigates>>relationship to the target <<SecurityRisk>>. Further research shows that a security control (a type of requirement) in and of itself does not actually mitigate a <<SecurityRisk>>. Rather, the <<ResourceMitigation>> that<<satisfies>> the <<SecurityControl>> requirement is the actual UAFElement that <<mitigates>> the <<SecurityRisk>>.

  • Reported: UAF 1.2b1 — Sun, 29 May 2022 20:50 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

Enable a Requirement Relationship between AbstractReqirement and Capability

  • Key: UAF13-43
  • Status: open  
  • Source: MITRE ( Ms. Rae Anderson)
  • Summary:

    The only allowable relationship between <<Capability>> and any Requirement element is <<trace>>. In US Department of Defense acquisition processes, stakeholder needs are defined as capabilities within a Capability Description Document. These capabilities are high-level system requirements from which system and sub-system requirements should be derived. The recommended solution is to enable the <<deriveReqt>> to have <<Capability>> as the target and any type of <<AbstractRequirement>> as the source of a <<deriveReqt>> relationship. An alternative would be the <<refine>> requirement relationship.

  • Reported: UAF 1.2b1 — Sun, 29 May 2022 20:33 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

UAF dtc-21-12-07 issue

  • Key: UAF13-42
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    the term DataElement is no longer used. should update definition of ResourceExchange.conveyed from:
    "ResourceCommunication, the conveyed element must be stereotyped «DataElement» or its specializations,"
    to
    "ResourceCommunication, the conveyed element must be stereotyped «ResourceInformation» or its specializations,"

  • Reported: UAF 1.1 — Wed, 4 May 2022 18:15 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

UAF dtc-21-12-07 issue

  • Key: UAF13-41
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    page 263. you still have a reference to "CommunicationsLink" which is no longer anywhere else in spec.
    Further, the properties defined here:
    "1. capacity : String[] Details how much information can be passed on the Communications Link.
    2. infrastructureTechnology : String[] Details the technology to be used to provide the communications infrastructure. "
    should be defined for ResourceConnector instead.

  • Reported: UML 2.5b2 — Wed, 4 May 2022 17:29 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

UAFML should not redefine SysML method attribute of the Viewpoint Stereotype.

  • Key: UAF13-40
  • Status: open  
  • Source: Ball aerospace ( John C Kha)
  • Summary:

    The method redefinition changes the type from SysML Behavior to SysML String, which limits the usefulness of the UAF viewpoint stereotype unnecessarily without providing any benefit. The description of the method attribute is, "The methods employed in the development of the Viewpoint." Redefining this to a string precludes defining executable methods that generate a view from the viewpoint, while leaving it as a behavior would not preclude defining the method as a string, since the body attribute of UML OpaqueBehavior is a string.

    Allowing the definition of the method as a behavior would also allow explicitly defining the types of inputs from the model needed to produce the view from the viewpoint as the types of input parameters to the behavior.

  • Reported: UAF 1.2b1 — Thu, 14 Apr 2022 16:32 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

Viewpoint Definition Incomplete, Doesn't Conform to ISO42010 and Cardinalities

  • Key: UAF13-39
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    p213 Viewpoint is defined as 'An architecture viewpoint frames (to formulate or construct in a particular style or language) one or more concerns.'

    1) Doesn't conform to ISO 42010 'work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns'
    2) This definition doesn't define what an Architecture Viewpoint is - only one of the relationships with Concern. Definitions should be atomic and not include related elements otherwise a change in model structure invalidates the definition. Also, semantically, they have to be standalone.

    3) The element should be named 'Architecture Viewpoint' as the definition states. This is important as pointed out earlier to differentiate it from the casual use of 'Viewpoint' and anchor it to ISO 42010.

    4)There is a general problem with diagrams where role names are used which have the same name/label as an adjacent element - see Fig 9:215.
    The role names provide no additional information and in effect you have unlabelled relationships. In this particular case the relationships should take the names from the 42010 conceptual model. 'language' should be 'architecture description language'. Unclear why 'purpose' is there as distinct from framing one or more concerns i.e is the purpose different from framing the concerns, if so, how?

    5) 'View' should be 'Architecture View' to differentiate it from other meanings e.g. as a collection of view definitions.

    6) The cardinality between View and Viewpoint is wrong if conforming with 42010 - it should be 1:1 between an Architecture View and its governing Architecture Viewpoint.
    7) To conform with ISO 42010 the relationships should take the same names i.e. Viewpoint governs View, Viewpoint frames Concern (and should show Stakeholder has Concern)

    8) There is an error in ISO 42010 conceptual model replicated - the requirement for an Architecture Description to contain one or more Architecture Viewpoints - Architecture Viewpoints may be held externally as what used to be termed Library Architecture Viewpoints.

  • Reported: UAF 1.1 — Fri, 8 Apr 2022 11:02 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

Multiple Use of 'Viewpoint' In Different (ISO 42010 Non-Conforming) Sense with No Definition / Differentiation

  • Key: UAF13-38
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    On page 4 the document states 'The UAF conforms to terms defined in the ISO/IEC/IEEE 42010 standard for architecture description'. It also states in section 4 Terms and Conditions 'No new terms and definitions have been required to create this specification. All terms are available in the normative references or bibliographic citations for detailed explanation'

    Despite these claims the document frequently uses 'viewpoint' with a different meaning from that of ISO 42010 i.e. not as a specification against which an architecture view is prepared and interpreted but:-
    1) 'viewpoint' = collection of architecture view definitions having a common subject area (e.g MODAF::Viewpoint)

    It does this with no identification of any difference in meaning and nor any definition. It often uses the different senses of 'viewpoint' in the same sentnce and paragraph:

    'The aligned and renamed viewpoints from the various frameworks provide a common generic name for each viewpoint. It should be noted that the term viewpoint is in the context of ISO 42010 where a viewpoint is the specification of a view. The UAF viewpoints are mapped to the corresponding viewpoint in the relevant contributing framework. It is the viewpoints described in the DMM that provides the basis for the Unified Architecture Framework (UAF)...'

    It looks like the 'viewpoints' and 'UAF viewpoints' are collections of view definitons which is confusingly and erroneously compared with the ISO 42010 definition wjhich is not the same thing at all. It also looks like the last use of 'viewpoints' might be a collection but by this point it's impossible to tell because the authors do not define the terms that they use.

    In 7.2 UAF Grid it presents what seems like MODAF::viewpoint, ISO::architecture viewpoint and UAF::view specification in the same place/graphic.

    p5 Type 1 Conformance 'Type 1 Conformance: - UAF View specification conformance. A tool demonstrating view specification conformance shall implement a version of all the view specifications defined in the UAF Grid, with the exception of the view specifications in the Metadata Domain. Optionally the tool vendor can implement other donor framework viewpoints, for instance DoDAF, MODAF or NAF ..'

    Here 'viewpoint' = collection not a single specification. 'view specification' appears to be indistinguishable from ISO 42010:architecture viewpoint

    It is extremely confusing and far from clear and non-ambiguous which are key qualities of any good requirement.

  • Reported: UAF 1.1 — Fri, 8 Apr 2022 10:52 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

'View Specification' Is Not Defined and Seems Indistinguishable in use from 'Architecture Viewpoint'

  • Key: UAF13-37
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    No where in the document is 'view specification' defined despite it being used in 7.2 and as a package name in the metamodel.

    In ISO 42010:2011 an 'Architecture Viewpoint' is defined as 'work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns' and in the ISO 42010 conceptual model is has a 'governs' relationship with Architecture View i.e. an Architecture Viewpoint is a specification containing a set of requirements against which an Architecture View is prepared and interpreted. How then is 'View Specification' different? This is particularly the case as 'View Specification' seems not to merit a UAF metamodel element.

  • Reported: UAF 1.1 — Fri, 8 Apr 2022 10:30 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

As Defined CapabilityConfiguration is More of a System than System Element Itself

  • Key: UAF13-36
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    'CapabilityConfiguration. A composite structure representing the physical and human resources (and their interactions) in an enterprise, assembled to meet a capability'

    'System. An integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements (INCOSE SE Handbook V4, 2015).'

    1) As defined CapabilityConfiguration in including interactions and providing a capability is closer to being able to represent a System than the System element itself
    2) CapabilityConfiguration is a legacy MODAF element. In the early days of MODAF in the MOD Architectures Lab it was common place to use the CapabilityConfiguration element to represent a system. The MoD never really addressed the problem and left the two distinct elements. There seems to be no good reason to have both or, if there is, what is the differentiation [remembering that the definitition shouldn't refer to any other metamodel element as it must be atomic and self-contained. Being connected to different other metamodel elements doesn't mean that the type is distinct - this can be corrected by changing the metamodel wiring to the CapabilityConfiguration or System element.

  • Reported: UAF 1.1 — Fri, 8 Apr 2022 10:23 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

Claim That No New Terms is Incorrect. Any Terms Need to Be Clearly Defined with Traceability to Source / Master Definition

  • Key: UAF13-35
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    'No new terms and definitions have been required to create this specification. All terms are available in the normative references or bibliographic citations for detailed explanation'

    This is clearly untrue - there are terms, such as 'View Specification', which if distinct from Architecture Viewpoint needs to be defined to differentiate it.

    As an authorative standard that claims to have semantic underpinnings this is wholly unacceptable - what is the master source to be used/referenced in an implementation? There is no traceability. From an engineering perspective any design implementation must be provided with the means to create full traceability to the UAF spec and, where appropriate, the particular source definition.

  • Reported: UAF 1.1 — Fri, 8 Apr 2022 10:07 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

subOrganization is Neither a Type Nor a Type of Human Being

  • Key: UAF13-34
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Definition: '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.).'

    1) 'sub-' anything is never a type. The 'sub' simply indicates a position in a hierarchy but the type is the same.

    2) An Organization is not a Human Being

    3) The definition of a type should be atomic and self-contained - it cannot depend on any other element such as 'ActualPersons'

    Organization is defined as 'A group of OrganizationalResources (Persons, Posts, Organizations and Responsibilities) associated for a particular purpose'. This shouldn't include other metamodel elements for the same reason i..e not OrghanizationalResource etc.

  • Reported: UAF 1.1 — Fri, 8 Apr 2022 09:55 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

Definition of Tuple is that for a Relationship (Not a Tuple)

  • Key: UAF13-33
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Fig 7:3
    Definition - 'A Tuple denotes a relationship that exists between elements.'

    This is incorrect - it defines a relationship (as it says). A tuple has to also include the start and finish nodes as well to form the smallest tuple - a triple.

    Looking at the diagrams it is the legend definition that is incorrect because the green coloured elements are relationships not triples. A clue is in Fig 8:28 on p49 ActualResourceRelationship is identified in green and is clearly just a relationship.

  • Reported: UAF 1.1 — Fri, 8 Apr 2022 09:46 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

UAF or ISO 42010 Terms Do Not Form Correspondence Rules

  • Key: UAF13-32
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    'Further, The UAF conforms to terms defined in the ISO/IEC/IEEE 42010 standard for architecture description, where the terms .... form correspondence rules specified as constraints on UAF.'

    This is incorrect. Terms / definitions cannot form correpondence rules.

    It isn't obvious whether there are any correpondence rules in the UAF given that it is the definition of the individual AF that defines the rules for the content of any particular view - the UAF just provides the "kit of parts" to enable the user to create them. If the UAF does itself define its own correspondence rules this would need to specified separately and somehow deal with potential inconsistencies wrt what does conformance etc then mean.

  • Reported: UAF 1.1 — Fri, 8 Apr 2022 09:22 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

EnterprisePhase Definition Defines a State Not a Phase

  • Key: UAF13-31
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Definition: 'A type of a current or future state of the enterprise.'

    This looks as thought it's a legacy MODAF 1.2.003 definition.

    1) A state is an abstract reference to a set of property values or conditions. A phase is a reference to a duration. This would be better defined as a distinct stage in the life? of an Enterprise. The problem is otherwise that there is no connection between the element name and definition.
    2) 'current' or 'future' is irrelevant and incomplete - if it occurs in the past is it therefore no longer an EnterprisePhase? The definition shouldn't depend on a particular time value.
    3) 'type of' shouldn't be in the definition. All the elements in a metamodel are types so it cannot form part of any differentiating feature.

  • Reported: UAF 1.1 — Fri, 8 Apr 2022 09:15 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

toBe Attribute is an Attribute of the Architecture Not the Architecture Description

  • Key: UAF13-30
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    toBe: Boolean[1] Indicates whether the ArchitecturalDescription represents an Architecture that exists or will exist in the future.

    This is incorrect. This is a property of the Architecture not the ArchitectureDescription i.e. an ArchitectureDescription of a future Architecture not a future ArchitectureDescription of an Architecture.

    This is another consequence of not differentiating properly between 'architecture' and 'architecture description'.

  • Reported: UAF 1.1 — Fri, 8 Apr 2022 08:57 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

Definition of Concern is Incorrect And Doesn't Conform to ISO 42010. Relationships Don't Match ISO 42010 Conceptual Model

  • Key: UAF13-29
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Definition
    'Interest in an EnterprisePhase (EnterprisePhase is synonym for System in ISO 42010) relevant to one or more of its stakeholders'

    1) This doesn't conform to the ISO 42010 definition of a Concern and hence invalidates claim to be compliant
    2) An EnterprisePhase is not a synonym for System, and certainly not in ISO 42010

    In Fig 9:211

    1) the 'concern' role name placed against Concern on the Viewpoint - Concern relationship is meaningless - using the same label as the name of the adjacent node element is in effect leaving the relationship with no name whatsoever - it proviode no information about that relationship. In ISO 42010 this relationship is named 'frames' - this should be . The cardinality is incorrect - it should be 1..*.

    2) the relationship between Stakeholder and Concern should be named 'has'. The cardinality is incorrect - it should be 1..*

    3) There should be no relationship between ActualEnterprisePhase and Concern

  • Reported: UAF 1.1 — Fri, 8 Apr 2022 08:48 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

ResourceArchitecture Definition is that for an Architecture Description Not Architecture

  • Key: UAF13-28
  • Status: open   Implementation work Blocked
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    'A type used to denote a model of the Architecture, described from the ResourcePerformer perspective.'

    A model is not an architecture - it might, however, describe an architecture description. The definition is therefore that for a type of architecture description not architecture. The definition is wrong and needs to be changed - suggestion is to base on the ISO 42010 conceptual model - 'architecture'.

    It is also an error to include in any definition any relationship - definitions of elements should be atomic / self-congtained and not depend on any other element or relationship otherwisse a) you're not defining the element - it might be a triple b) if the structure/ relationships change then the element definition no longer holds.

  • Reported: UAF 1.1 — Fri, 8 Apr 2022 08:34 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

Lack of Differentiation Between 'Architecture' and 'Architecture Description'

  • Key: UAF13-27
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    'The UAFP can be used to develop architectures compliant with:
    • Department of Defense Architecture Framework (DoDAF) version 2.02'

    This is incorrect. Architecture Descriptions might be compliant with an AF such as the DoDAF but architectures them selves are certainly not. This is a general problem - the lack of differentiation between 'architecture' (the thing being described) and 'architecture description' (the description). It probably isn't helped by loose casual everyday talk but in a document with defined semantics it is an error - it's the equivalent of confusing the 'duck' with the 'photo of the duck'.

    It also looks as though this has affected some of the metamodel element definitions e.g. ResourceArchitecture

  • Reported: UAF 1.1 — Fri, 8 Apr 2022 08:24 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

Ambiguity regarding Stakeholder role expectations

  • Key: UAF13-26
  • Status: open  
  • Source: Air Force Institute of Technology ( Steve Glazewski)
  • Summary:

    (typo) Page 72, View Specifications::Resources::Roadmap::Resources Roadmap: Evolution has a Stakeholder named "Implements" and I think you mean "Implementers" as is used in other areas.
    (typo) Page 83, View Specifications::Projects::Taxonomy::Project Taxonomy doesn't put the Stakeholders, Concerns, Definition, and Recommended Implementation on separate lines like every other View Specification does.

    Page 31, View Specifications::Operational::Connectivity::Operational Connectivity and Page 37, View Specifications::Operational::Constraints::Operational Constraints both have a Stakeholder named "Architects" whereas all other View Specifications specify one or several types of Architects. Are all other named types of Architects assumed?

    In general, what are your definitions/assumptions for Business Architects versus Enterprise Architects versus IT Architects, all of which are used as Stakeholders in various View Specifications?
    What are your definitions/assumptions for Solution Providers versus Implementers, both of which are used as Stakeholders?
    What are your definitions/assumptions for Decision Makers versus Executives versus Owners Responsible for Operational Agents, all of which are used as Stakeholders in various View Specifications?

    Page 37, View Specifications::Operational::Constraints::Operational Constraints contains a Stakeholder called Program Sponsor. What is your definition for "Program" or that overall Stakeholder?

  • Reported: UAF 1.1 — Tue, 5 Apr 2022 18:59 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

UAFElement.conformsTo and ProtocolImplementation.implements alignment and reification with fUML

  • Key: UAF13-25
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

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

  • Reported: UAF 1.2 — Thu, 17 Mar 2022 20:30 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

LocationHolder.physicalLocation and requiredEnvironment as properties of Assets

  • Key: UAF13-24
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

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

  • Reported: UAF 1.2 — Thu, 17 Mar 2022 17:19 GMT
  • Updated: Mon, 2 Sep 2024 01:00 GMT

Support UML::Property.defaultValue as part of UAF::MeasurableElement.actualMeasurementSet

  • Key: UAF13-23
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

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

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

  • Reported: UAF 1.2 — Thu, 17 Mar 2022 15:59 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Alignment of UAF::*Method with IsCapableToPerform

  • Key: UAF13-22
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

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

  • Reported: UAF 1.2 — Thu, 17 Mar 2022 14:54 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

UAF::*Constraint can’t be used with SysML::ConstraintBlocks

  • Key: UAF13-21
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

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

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

  • Reported: UAF 1.2 — Thu, 17 Mar 2022 14:12 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Refine the DMM Impliments implementation in ML

  • Key: UAF13-20
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

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

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

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

  • Reported: UAF 1.2 — Tue, 15 Mar 2022 21:57 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

measurementSet tag derivation from actualMeasurementSets

  • Key: UAF13-19
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

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

  • Reported: UAF 1.2 — Tue, 15 Feb 2022 21:18 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

UML::Property.defaultValue has upper multiplicity of 1 even though Property is a MultiplicityElement

  • Key: UAF13-18
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

    UML makes it hard/impossible to provide defaultValues for properties that have upper multiplicity higher than 1 since the defaultValue is limited to 1 ValueSpecification. While an OpaqueExpression could be used to provide a result of more than 1 element, this still requires execution of extra metaclass associations and the digital trail to Literals or InstanceValue's. Recommend changing the multiplicity to 0 .. *.

  • Reported: UML 2.5.1 — Mon, 31 Jan 2022 21:17 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

UAF::*ControlFlow not possible from most UML::ActivityNodes

  • Key: UAF13-17
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

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

  • Reported: UAF 1.2 — Wed, 19 Jan 2022 17:12 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Support for SysML::FullPort as alternate for UAF::*Ports

  • Key: UAF13-16
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

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

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

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

  • Reported: UAF 1.2 — Fri, 14 Jan 2022 21:55 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Interoperability with UML and SysML elements

  • Key: UAF13-15
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

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

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

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

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

  • Reported: UAF 1.2 — Fri, 14 Jan 2022 21:07 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Extention of UAF "Action"s from UML::CallBehaviorAction does not support usage of UAF::"Method"s in Process and Connectivity Views

  • Key: UAF13-14
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

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

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

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

  • Reported: UAF 1.2 — Fri, 14 Jan 2022 20:20 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

XMI file with outdated UML 1.x version

  • Key: UAF13-13
  • Status: open   Implementation work Blocked
  • Source: Army ( Hossana H Aberra)
  • Summary:

    I learned that the OMG has deprecated UML 1.x XMI 1.x well over 10 years ago when it was replaced by UML 2.x XMI 2.x.

    Also learned that the OMG UAF.xmi file is in UML XMI version 1.x. Probably generated from a tool like Sparx Enterprise. Because UML 1.x is an outdated version it is not possible to import the current UAF.xmi file posted on your site for analysis, causing import errors.

    This requires providing the UAF.xmi files using the current UML 2.x XMI 2.x version.

    Please provide/replace the UAF.xmi files posted on your site with UML 2.x XMI 2.x version to import the specification in to a modeling tool for analysis.

  • Reported: UAF 1.1 — Wed, 22 Dec 2021 22:11 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Error

  • Key: UAF13-12
  • Status: open   Implementation work Blocked
  • Source: Army ( Hossana H Aberra)
  • Summary:

    We keep getting error while importing. It tries to load the file and fails when trying to read the first character, with a "invalid byte" message. Not sure if this has been reported before. If so would it be possible to share updated UAF.xmi? If not, would it be possible to share the name of the tool it was created with?

  • Reported: UAF 1.1 — Tue, 21 Dec 2021 17:05 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Reference to "Services Sequences" view in traceability tables

  • Key: UAF13-11
  • Status: open  
  • Source: n/a ( Gregory King)
  • Summary:

    In the traceability appendix, the undefined "Services Sequences" view is referenced in the DoDAF and MODAF tables, mapping to the SvcV-10c and SOV-4c, respectively. I assume this should be "Services Interaction Scenarios".

  • Reported: UAF 1.1 — Fri, 26 Mar 2021 15:19 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Error in table numbering

  • Key: UAF13-10
  • Status: open  
  • Source: n/a ( Gregory King)
  • Summary:

    The view traceability tables in the body of Appendix A are not numbered in a logical order. They're shown as Table 2:1,1:2, 2:2, 2:3, 2:5. The numbers in the List of Tables (p. v) appear to be correct.

  • Reported: UAF 1.1 — Fri, 26 Mar 2021 15:29 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

UAF DMM PDF - Table of Contents is out-of-sync with chapter numbering

  • Key: UAF13-9
  • Status: open  
  • Source: Boeing ( Dan Brzozowski)
  • Summary:

    In the UAF DMM document (https://www.omg.org/spec/UAF/1.1/DMM/PDF), starting right after "7.2 Domain Interrelationships", there seems to be an error causing the Table of Contents (TOC) to incorrectly "Domain Metamodel Diagram Legend" as Chapter 8 insead of section 7.3. This offset continued through TOC the document such that Chapters 8 and 9 are mislabeled.

  • Reported: UAF 1.1 — Sun, 18 Apr 2021 04:12 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

UAF extensions of CallBehaviorAction should also support CallOperationAction

  • Key: UAF13-8
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

    SysML allows the use of CallOperationAction as an alternate means of mapping Behaviors (via Operation->Method metaproperty).
    UAF 1.1 includes OperationalActivityAction, ProjectActivityAction, ServiceFunctionAction, FunctionAction or SecurityProcessAction which all extend CallBehaviorAction.
    UAF 1.1 also includes OperationalMethod, ServiceMethod, ResourceMethod, which extend Operation, and even has metaconstraints requiring appropriately UAF stereotyped Activity used as the Method.

    We recommend allowing CallOperationAction to also be stereotyped by the UAF extensions to CallBehaviorAction listed above.
    We also recommend creating ProjectMethod and SecurityMethod as extentions to Operation to be consistent with other Domains.
    This would facilitate it's use in Operational::Connectivity, Operational::Processes and Security Processes, Project Processes, Personnel Processes, Resource Processes and Resources Connectivity Diagrams and Tables.
    This is especially useful to visualize and take advantage of CallOperationAction target pin and method resolution per UML 2.5 13.2.3.5 Behavioral Features and Methods. It is also useful for fUML 1.2.1 Polymorphic Operation Dispatching ability to execute method resolution during simulation and analysis. Thus a tighter integration of UAF with UML method resolution semantics and executability can be achieved both visually and from a simulation and analysis perspective.

  • Reported: UAF 1.1b1 — Wed, 2 Jun 2021 17:08 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Actual Resource Relationship description incorrect

  • Key: UAF13-7
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

    Actual Resource Relationship is described as: An abstract element that details the ActualOrganizationalResources that are able to carry out an ActualResponsibility.

    This appears to be incorrect. First, this element is not abstract. Second, it should not be restricted to Organizational Resources since it should apply to any Actual Resource. Third, it does not help understand responsibilities of organizational resources.

    Description of this element should be changed to read something like: An element that details the ActualResources that are involved in exchanging resources through a realized ResourceExchange.

  • Reported: UAF 1.1 — Sun, 31 Oct 2021 13:28 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Actual Resources domain name change

  • Key: UAF13-6
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

    The elements in the Actual Resources views are instances of the "definitional" elements in other domains. For example, Actual Resource (classified by Resource Performer element types in Resources domain); Actual Post, Actual Person, Actual Organization (<all classified by elements from Personnel domain); Actual Resource for a Resource Mitigation (from Security domain). The new Resource Service element will be classified by a Service in the Services domain.

    Notice that not all the elements shown in Actual Resources views come from the Resources domain views (ie, they also come from Personnel, Security, and Service domains). So, the name "Actual Resources" is somewhat misleading in this respect. Therefore, it would better if this domain is renamed to more accurately reflect its intended content. Suggest the name be changed to "Actualization" (Az) domain.

  • Reported: UAF 1.1 — Tue, 17 Nov 2020 23:28 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Group architecture items into portfolios and portfolio segments

  • Key: UAF13-5
  • Status: open  
  • Source: Aerospace Corporation ( Dr. James Martin)
  • Summary:

    Portfolio management involves changes to the future plans and current deployments.When to add new capabilities? When and where to change operations or change resources?. When to retire legacy resources, or re-purpose them?

    Overall “score” for alternative portfolio configuration is extent to which Outcomes are achieved for the enterprise as a whole. Possibilities for change come from identified Opportunities and their associated Risks. Also these come from identified new/modified Capabilities and their associated Effects.

    Portfolio is normally divided into Portfolio Segments
    -Could be divided by timeframe (eg, “epochs” such as near, mid, far term)
    -Could be divided by “color of money” (eg, R&D, acquisition, operations)
    -Could be divided by mission area

    Currently using Whole Life Configuration as the Portfolio elements in EA model. WLC is a “set of Versioned Elements”. But would be more convenient to have a different model element for “Portfolio”.
    -Alternative Portfolios would be examined for most cost-effective combinations
    -Each Portfolio option is a provisional “set of Versioned Elements”
    -Then the selected combination gets promoted to a new Whole Life Configuration (becoming the new “baseline” for program planning and scheduling)

    Portfolio (kind of) Project does not have the necessary semantics with the features and relationships enumerated below.

    WLC element only gives part of the picture of what is in the Portfolio.
    -Acts as a “collection” of things with an associated Gantt chart for deployment timelines
    -Does not tell us who “owns” that collection of things in the Management Accountability sense
    -A Portfolio can consist of multiple Whole Life Configurations

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

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

  • Reported: UAF 1.1 — Thu, 2 Jul 2020 16:07 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Need to identify addtional concept to support Acquistion Ref Model Usage

  • Key: UAF13-4
  • Status: open  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

    Identify and update the DMM to reflect new concepts and relationships to existing concepts. Additionally, identify all impact to existing diagrams.

  • Reported: UAF 1.1 — Mon, 22 Jun 2020 13:43 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

ISO Date Time needs to be refactored

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

    ISODateTime is currently mapped to literal string. In my opinion it does not make sense. This mapping does not allow to reuse dates in the easy way. Plus we also have the same approach with milestones implemented very differently. I do believe that both approaches need to be aligned. Dates should be easily reusable all over model.

  • Reported: UAF 1.1 — Mon, 9 Dec 2019 19:01 GMT
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Is OrganizationInEnterprise to restrained?

  • Key: UAF13-2
  • Status: open  
  • 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
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Stereotypes for flowProperties

  • Key: UAF13-1
  • Status: open  
  • 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
  • Updated: Mon, 2 Sep 2024 00:59 GMT

Definition of Standard Operational Activity clarified

  • Key: UAF13-205
  • Status: open  
  • Source: Boeing ( Ms. Sharon Fitzsimmons)
  • Summary:

    The Standard Operational Activity definition is not clear ("standard operating procedure" is fairly ambiguous). Would be important to clarify where it should be used instead of an Operational Activity. It is also listed as a Doctrine of the Capability Configuration, which should be checked against the doctrine elements being added to UAF 1.3 to support mission engineering.

  • Reported: UAF 1.2 — Fri, 21 Jun 2024 13:37 GMT
  • Updated: Mon, 1 Jul 2024 15:19 GMT

*ActivityAction

  • Key: UAF13-204
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    all the *ActivityAction's extend CallBehaviorAction... but there are other Actions one might want to have in the Activity ... e.g. we have people that just want an OpaqueAction...
    so would like OperationalActivityAction, ProjectActivityAction, FunctionAction, SecurityProcessAction, ServiceFunctionAction should all extend Action (not CallBehaviorAction)

  • Reported: UAF 1.2 — Wed, 5 Jun 2024 20:28 GMT
  • Updated: Mon, 1 Jul 2024 15:13 GMT

Decision Nodes not a UAF element

  • Key: UAF13-203
  • Status: open  
  • Source: Boeing ( Ms. Sharon Fitzsimmons)
  • Summary:

    Decisions within a process often conform to standards and require measurements to determine the quality of the decision. However, because the DecisionNode element is inherited without modification from SysML/UML, the <<ConformsTo>> relationship and <<MeasurableElement>> are not available on decision nodes. Adding a UAF DecisionNode as a MeasurableElement would improve traceability in the model.

  • Reported: UAF 1.2 — Wed, 5 Jun 2024 13:00 GMT
  • Updated: Mon, 1 Jul 2024 15:11 GMT

For Exchanges

  • Key: UAF13-183
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    So UAF should remind people using Exchanges that in SysML the standard says...

    "A Connector or an Association, or an inherited Association shall exist between the source and the target of the InformationFlow"

    not that I like this or think it is correct... but for an ItemFlow this is the restriction given in the standard...

    exchanges across ActivityEdges and Messages need to have this...

  • Reported: UAF 1.2 — Thu, 25 Apr 2024 05:54 GMT
  • Updated: Fri, 21 Jun 2024 14:27 GMT

Missing ServiceParameter

  • Key: UAF13-184
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    notice on fig 3.107 ServiceParameter relates to ServiceExchangeItem

    but on serviceEchangeItem fig 3.112 it is missing the ServiceParameter

  • Reported: UAF 1.2 — Thu, 25 Apr 2024 06:14 GMT
  • Updated: Fri, 21 Jun 2024 14:20 GMT

Missing Service on ServiceExchangeItem?

  • Key: UAF13-185
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    should Service relate to ServiceExchangeItem
    similar to how OperationalActivity
    relates to OperationalExchangeItem?

  • Reported: UAF 1.2 — Thu, 25 Apr 2024 06:21 GMT
  • Updated: Fri, 21 Jun 2024 14:16 GMT

View Specification - Rs-Sr - Undefined Concerns, Missing Elements, Shouldn't Describe Function, Missing Triples - Measurement, Protocol

  • Key: UAF13-186
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    p74 8.1.7 View Specifications::Resources::Structure

    1) identifier - Rs-Sr, missing'

    Definition: defines the physical resources, e.g. capability configuration(s)/system(s) and interactions necessary to implement a specific set of OperationalPerformer(s).'

    2) CapabilityConfiguration and System are not physical resources (as Figure 8:56 shows)

    3) ResourceArchitecture specialised elements - System, SecurityEnclave allowed but missing from Fig 8:56. All elements of a taxonomy tree should be shown. If not then the parent should not be shown and particular individual child elements shown.

    'Concerns: reference the resource structure, connectors and interfaces in a specific context.'
    4) Meaningless - what does 'reference the ...' mean? 'In a specific context'? Back inAbitraryConnector territroy. How can you possibly determine that these elements represent the allowed view content when there is no clear set of concerns which triples formed from the elements should address?

    5) Is nothing carried by a ResourceExchange? If so elements are needed on Fig 8:56 to describe this.

    6) Protocol is not involved in any triple. There appears to be a triple involving ProtocolImplementation but not Protocol. If there is a triple involving Protocol expected then additional elements are required. If there is no triple involving Protocol delete it.

    7) Similarly there is no triple involving Measurement - again define one including a relationship element or remove.

    8) The 'ResourcePerformer IsCapableToPerform Function' triple has no connection to the structural and interface concerns. It makes no sense to try and describe functional, interfaces and structure on the one architecture view. Function should be the subject of e behaviour-oriented 'view specification' e.g. Resources Process - Rs-Pr. The IsCapableToPerform and Function elements should be remoed from Fig 8:56

  • Reported: UAF 1.2 — Fri, 26 Apr 2024 07:09 GMT
  • Updated: Fri, 21 Jun 2024 14:04 GMT

PropertySet should extend <> Classifier

  • Key: UAF13-187
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    since PropertySet types things... one can be tighter about what it extends... it should extend Classifier rather than Element

  • Reported: UAF 1.2 — Fri, 26 Apr 2024 17:51 GMT
  • Updated: Fri, 21 Jun 2024 13:26 GMT

'View Specification' Rs-Sr Resources Structure - Every ResourcePerformer Requires One or More Measurements. Asset is a PropertySet Semantically Incorrect

  • Key: UAF13-190
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    p72 8.1.7 View Specifications::Resources::Structure Rs-Sr Fig 8:56

    'Concerns: reference the resource structure, connectors and interfaces in a specific context.'

    1) Fig 8:56 requires 1 or more Measurement for each ResourcePerformer i.e. have to show Measurement(s)?
    2) No triples provided to describe applicable measurements
    3) No concerns require Meaurements to be shown - so the elements shown are surplus to requirements for the architecture view
    4) The semantics of Asset is a PropertySet are incorrect. An Asset property or characteristic might be quantified by one or more Measurements. This does not mean, however, that a set of measurements is an asset - it's a meaningless and incorrect assertion. How can the UAF claim any semantic rigour?

  • Reported: UAF 1.2 — Sun, 28 Apr 2024 08:35 GMT
  • Updated: Fri, 21 Jun 2024 13:22 GMT

Need to be specific when extending things

  • Key: UAF13-188
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Even thought the UML Standard does not explicitly state this, extends are inherited by specializations of Stereotypes...

    1. The UML standard show examples of specializations of stereotypes that do not extend metaclasses indicating that extends are inherited see Fig. 12.21
    2. ExtendEnds are forms of Association Ends which are inherited normally (and there is nothing to the contrary in the standard that they are treated any differently)
    3. SysML also uses this... e.g. see Fig. 8.8 of SysML 1.7 where BoundReference does not show an extends (but gets it from EndPathMultiplicity)...

    so given UAF... I think most everything that extends Element is wrong... because for example, you do not want to be able to put the stereotype
    <<OperationalActivity>> on anything but a UML/SysML Activity... but Activity is MeasureableElement which is a UAFElement which extends Element, so therefore <<OperationalActivity>> can be put technically on anything (e.g. a Comment)... so this is wrong and needs to be fixed

  • Reported: UAF 1.2 — Fri, 26 Apr 2024 18:43 GMT
  • Updated: Wed, 12 Jun 2024 23:58 GMT

No Added Extensions

  • Key: UAF13-189
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    For Protocol it extends Class which is redundant and probably unhelpful...

    since Protocol is a specialization of Block (which extends Class) this is not helpful, because one needs to know that this stereotype
    would be used instead of <<Block>> (since one can not have both a generalization and specialization of a stereotype on the same element)...

    Block here is the more fundamental than the metaclass Class... but neither should be specified redundantly in the model...
    it is just not helpful... what would be helpful is defining the fundamental thing in the definition of the UAF elements

  • Reported: UAF 1.2 — Fri, 26 Apr 2024 19:16 GMT
  • Updated: Wed, 12 Jun 2024 23:56 GMT

PropertySet - Incorrect Definition, Specialisation Short Circuits Metamodel - 'System PropertySetGeneralization Viewpoint' etc. Triples Not in any UAF Architecture View

  • Key: UAF13-191
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    p245 9.1.12 Domain Metamodel::Parameters - PropertySet & Fig 9:363

    PropertySet is defined as 'An abstract type grouping architectural elements that can own Measurements.'

    1) Incorrect. The definition is not atomic - refers to 'owns' which implies a relationship that isn't present with PropertySet in the metamodel. 'Architectural Element' is actually an AD element (cf ArchitecturalReference). Things don't own measurements - they have characteristics that are quantified by measurements. The definition should only define the concept not the use or application of the element - this would then highlight the problem wrt what the concept actually represents. It appears to be an implementation artefact that has nothing to do with the fundamental metamodel concepts.

    2) Figure 9:363 shows that many metamodel elements specialise PropertySet, most of which are semantically incorrect. We have, for example, 'System is a PropertySet', 'Viewpoint is a PropertySet', 'StrategicPhase is a PropertySet', 'OperationalInterface is a PropertySet'. The full class hierarchy needs to be shown including all types of Asset, Resource and MotiovationalElement otherwise the sense (or error) of what is being asserted cannot be verified. The only assertion that is probably correct is 'MeasurementSet is a PropertySet'

    3) There is a reflexive PropertySetGeneralization on PropertySet - presumably to assert a specialisation of successive PropertySets. However, because it is on PropertySet - the parent - and because the child elements inherit this relationship with any PropertySet element it therefore asserts that 'System PropertySetGeneralization Viewpoint', 'EnterpriseGoal PropertySetGeneralization Service' i.e. the child PropertySet elements can be connected together using PropertySetGeneralization which is semantically meaningless.

    4) There are several elements - possibly many - where a triple including PropertySetGeneralization can never appear in any architecture view (doesn't appear in the definition of allowed content of any 'view specification'). For example the View, Viewpoint elements. You might expect these particular triples to appear in the Summary & Overview 'view specification' if valid - but there is nothing shown in 8.1.2 and doesn't address the concerns. If triples do not address concerns and do not appear in any 'view specification' they should be deleted from the metamodel - they serve no defined purpose.

    5) There is no defined relationship between Measurement and PropertySet that can be used in any 'view specification' - this would require a relationship element to be shown and there is only the reflexive PropertySetGeneralization

  • Reported: UAF 1.2 — Sun, 28 Apr 2024 09:16 GMT
  • Updated: Wed, 12 Jun 2024 23:23 GMT

CompetenceToConduct in two places

  • Key: UAF13-192
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    CompetenceToConduct in the metamodel is in traceability
    and in the profile is in Process

    should they not be in the same place?

  • Reported: UAF 1.2 — Tue, 30 Apr 2024 00:07 GMT
  • Updated: Wed, 12 Jun 2024 23:13 GMT

CompetenceToConduct in two places

  • Key: UAF13-193
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    CompetenceToConduct in the metamodel is in traceability
    and in the profile is in Process

    should they not be in the same place?

  • Reported: UAF 1.2 — Tue, 30 Apr 2024 21:45 GMT
  • Updated: Wed, 12 Jun 2024 23:11 GMT

Function in some places instead of Activity

  • Key: UAF13-194
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    used "Function" in some places and "Activity" in others... e.g. OperationActivity and Function in Resources

  • Reported: UAF 1.2 — Tue, 30 Apr 2024 22:52 GMT
  • Updated: Wed, 12 Jun 2024 23:07 GMT

InteractionMessage has no metamodel

  • Key: UAF13-195
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Domain MetaModel::Architecture Management::Sequences::InteractionMessage has no metamodel

  • Reported: UAF 1.2 — Wed, 1 May 2024 00:58 GMT
  • Updated: Wed, 12 Jun 2024 23:05 GMT

No Description for CapabilityRoleDependency

  • Key: UAF13-196
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    No Description for CapabilityRoleDependency

  • Reported: UAF 1.2 — Wed, 1 May 2024 02:33 GMT
  • Updated: Wed, 12 Jun 2024 23:03 GMT

no metamodel for StrategicExchangeItem

  • Key: UAF13-197
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    no metamodel for StrategicExchangeItem

  • Reported: UAF 1.2 — Wed, 1 May 2024 02:35 GMT
  • Updated: Wed, 12 Jun 2024 23:01 GMT

Missing metamodel for StrategicInformation

  • Key: UAF13-198
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Missing metamodel for StrategicInformation

  • Reported: UAF 1.2 — Wed, 1 May 2024 02:53 GMT
  • Updated: Wed, 12 Jun 2024 22:59 GMT

Method is wrong semantics

  • Key: UAF13-182
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    What is called a Method in UAF is really an Operation... this is confusing as the semantics for Method and Operations are set in
    SysML via UML

  • Reported: UAF 1.2 — Thu, 25 Apr 2024 05:13 GMT
  • Updated: Thu, 25 Apr 2024 18:36 GMT

Sm is not defined


the two UAF Grids are different

  • Key: UAF13-180
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Fig 7.1 in the DMM and the UAF Grid in Appendix C are different...

    for example... one has Am-St and the other one does not... there are other differences

  • Reported: UAF 1.2 — Thu, 25 Apr 2024 01:59 GMT
  • Updated: Thu, 25 Apr 2024 18:36 GMT

Ar-Tr is missing

  • Key: UAF13-179
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Ar-Tr is missing on both Graphics of the UAF Grid

  • Reported: UAF 1.2 — Thu, 25 Apr 2024 01:55 GMT
  • Updated: Thu, 25 Apr 2024 18:35 GMT

View Specification Rs-Tx Resources Taxonomy - ResourceExchanges, Measurements Do Not form Part of a Resource Taxonomy

  • Key: UAF13-178
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    p71 8.1.7 View Specification - Rs-Tx Resources Taxonomy, Fig 8:55

    states
    'Concerns: resource types.
    Definition: shows the taxonomy of types of resources.'

    1) Architecture viewpoint has no identifier (a package containment isn't a unique identifier) - should be Rs-Tx according to the Traceability document.

    2) Figure 8:55 shows ResourceExchange - this is a connector. It isn't used in the architecture viewpoint - a taxonomy uses 'is a' (specialises / generalises). This shouldn't be in the diagram

    3) The Measurement element isn't a Resource and also isn't involved with taxonomy - it doesn't address the concerns of the architecture viewpoint and should be removed.

    4) The realisation of an OperationalPerformer by a ResourcePerformer doesn't involve taxonomy and doesn't address any of the concerns. This should be removed.

  • Reported: UAF 1.2 — Wed, 24 Apr 2024 12:30 GMT
  • Updated: Wed, 24 Apr 2024 14:08 GMT

OperationalArchitecture - an AD by Definition Specialises OperationalAgent and Architecture?

  • Key: UAF13-177
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    p158 9.1.4 Domain Metamodel::Operational - Operational Architecture, Figure 9:187

    OperationalArchitecture is defined as:
    'A type used to denote a model of the Architecture, described from the Operational perspective.'

    1) We incorrectly have a model of the architecture being a type of architecture (OperationalArchitecture specialises Architecture).

    2) The description of the 'operational architecture' is the set of operational node elements and relationships (forming triples), perhaps augmented by some standards - it is incorrect then to have a concrete single element representing the same thing.

    It isn't really any different as a type from Architecture - it seems to be purely a mechanism to show relationships with different operational elements. It isn't a distinct concept in what is supposed to be an abstract metamodel.

    So what then is the relationship between 'OperationalArchitecture' and the description of an operational architecture (if the element really is 'architecture' and not 'architecture description'? It ought to conform to ISO 42010 ie something like 'expresses' or in the reverse sense 'is described by'

  • Reported: UAF 1.2 — Wed, 24 Apr 2024 12:04 GMT
  • Updated: Wed, 24 Apr 2024 14:08 GMT

8.1.10 View Specifications::Standards::Traceability - Sd-Tr - Incorrect Concerns. No Triples Provided to Match Concerns. Unclear Whether Trace or Conformance

  • Key: UAF13-176
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    p99 8.1.10 View Specifications::Standards::Traceability

    The concern for the 'UAF::view specification' is:-
    'Concerns: standards that need to be taken in account to ensure the interoperability of the implementation of architectural elements.'

    1) Why is a view needed to describe the standards affecting the interoperability of an architecture description?
    2) 'implementation of architectural elements' is meaningless - do mean the standards that affect the system of interest? Standards don't just affect implementation

    'Definition: shows the applicability of standards to specific elements in the architecture'

    3) Difficult to make sense of given the endemic conflation of 'architecture' to mean both 'architecture' and 'architecture description'. Standards apply to the system of interest. 'elements' is too much like 'architecture description element' used to form an AD.

    Figure 8:82 Standards Traceability

    This shows Standard, Protocol elements and the generic UAFElement.

    4) There are no relationship elements provided to establish what looks like a 'conforms to' relationship between a UAFElement and a Standard or Protocol

    5) Either the diagram doesn't provide the elements to address the concerns or the concerns are incorrect. The diagram describes conformance not a trace ('standards that need to be taken in account'). Which is it? The concerns and the triples shown in the diagram need to be consistent with each other.

  • Reported: UAF 1.2 — Wed, 24 Apr 2024 08:56 GMT
  • Updated: Wed, 24 Apr 2024 14:07 GMT

View Specification Op-Pr Operational Processes BPMN Semantics - Invalid Concern, Representation in an Agnostic Metamodel

  • Key: UAF13-175
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    p40, 41 - 8.1.4 View Specifications::Operational::Processes - View Specification Op-Pr Operational Processes BPMN Semantics

    The DMM is supposed to be an agnostic specification. This clearly shows the bottom-up derivation of the DMM by chopping bits out of the UML profile.

    1) The title is invalid - no architecture viewpoint should be named after a particular ADL implementation - the name ought to be 'Operational Processes' if that reflects the purpose/ concern not the means of realising this.

    'Concerns: captures activity-based behavior and flows using BPMN notation.'
    2) This is invalid - the ADL or method is never part of a valid concern. The stakeholders presumably only care about the processes not how they are represented.

    'Definition: describes the BPMN processes that are normally conducted in the course of achieving business goals that support a capability. It describes operational activities, their Inputs/Outputs, operational activity actions and flows between them using BPMN notation.'

    3) This is invalid. It should describe processes. It shouldn't contain any reference to any particular ADL, UML or SysML element names et al

    Recommended Implementation: BPMN Process Diagram.

    4) It shouldn't make reference to any technology or ADL. In any case why can't processes be described using a UML ACtivity Diagram? What's so special that this has to be BPMN?

    5) Figure 8:27 shows many BPMN elements. Delete them - they have no valid place in the DMM

  • Reported: UAF 1.2 — Wed, 24 Apr 2024 08:28 GMT
  • Updated: Wed, 24 Apr 2024 14:07 GMT

OperationalActivityEdge is a UML (Activity Diagram) Implementation of OperationalExchange - Shouldn't be in Agnostic DMM [Not Required]

  • Key: UAF13-174
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    p38 8.1.4 View Specifications:Operational - Operational Connectivity, Figure 8:25, p165 9.1.4 Domain Metamodel::Operational - OperationalActivityEdge Figure 9:202

    The OperationalActivityEdge element is defined as :-

    'A tuple that shows the flow of Resources (objects/information) between OperationalActivityActions'

    Figure 8:25 shows that this element realises the OperationalExchange element (indicated by the realizedByActivityEdge role name on OperationalActivityEdge and the realizes role name on OperationalExchange).

    An ActivityEdge is a particular UML method to provider a connector to join two Activity node elements on a UML Activity Diagram. This is a particular UML implementation. It should be in the UML profile for the UAF but not in an agnostic metamodel or architecture viewpoints in the DMM. How someone chooses to implement an OperationalExchange is up to them - it isn't the subject of the DMM.

  • Reported: UAF 1.2 — Wed, 24 Apr 2024 08:03 GMT
  • Updated: Wed, 24 Apr 2024 14:07 GMT

mismatch Concerns

  • Key: UAF13-173
  • Status: open  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    in UAFML Operational::Structure concern is
    identifies the operational exchange requirements between OperationalPerformers

    where as in UAF DMM Operational::Structure concern is:
    identifies the operational exchange requirements between nodes

    so need to replace nodes with OperationalPerformers

  • Reported: UAF 1.2 — Tue, 23 Apr 2024 22:34 GMT
  • Updated: Wed, 24 Apr 2024 14:06 GMT

Appendix B - Glossary - Change of ISO 42010 'Architecture Viewpoint' to 'Viewpoint'. UAF Actually 'Viewpoint' Has at Least 2 Meanings, Only 1 Defined

  • Key: UAF13-172
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    EA guide p 136 - Appendix B - Glossary - Viewpoint

    This states that the ISO 42010 term 'Viewpoint is '“conventions for the creation, interpretation and use of an architecture view to frame one or more concerns” [ISO 42010] that governs the creation of views'

    It then states that the UAF term 'viewpoint' is 'frames (to formulate or construct in a particular style or language) one or more Concerns. A Concern can be framed by more than one Viewpoint.'

    1) the ISO 42010 term is 'Architecture Viewpoint' not 'Viewpoint' - this distinguises it from incorrect casual uses of 'viewpoint'.
    2) If anyone sees 'Viewpoint' how will they know whether it's the ISO 42010 'viewpoint', the first meaning of UAF 'viewpoint' defined above or indeed the MODAF viewpoint which is used within the documents bit not defined anywhere?
    3) If you modify the ISO 42010:2022 definition by appending anything it isn't then the ISO 42010 definition and shouldn't be labelled as such because it misleads. If you need to add notes use a footnote so that there is clear physical separation of what is a local annotation. Adding a description of relationships etc shouldn't be part of the definition of any concept - it should be atomic - it is an element in the 42010 conceptual model and describing the conceptual model shouldn't be in the table itself. Or create an additional 'Comments' column and move the non standard text there.
    4) Until all references to (MODAF) viewpoint are removed the UAF cannot claim and a 'viewpoint' = ISO 42010:: architecture viewpoint because in many places in the text it isn't

    Simnilarly for 'View' above - there is not such thing in ISO 42010 as 'View' - the correct term is 'Architecture View' because there are many casual and incorrect meanings of 'View' (as the UAF element is named)

    This is a self-inflicted error - if the UAF stuck to the name and definition defined by ISO 42010 it wouldn't arise - there wouldn't be 2 (actually) 3 uses of 'viewpoint' with different meanings. That's the point of standardisation - only 1 term, 'architecture viewpoint', used throughout with the one consistent meaning.

  • Reported: UAF 1.2 — Tue, 23 Apr 2024 14:39 GMT
  • Updated: Wed, 24 Apr 2024 14:06 GMT

3.1 Architecture Management Concepts - 'UAF Meaning' - Any Semantic Difference from ISO/IEC/IEEE 42010 Invalidates Any Claim of Conformance

  • Key: UAF13-171
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    EA Guide p17 - 3.1 Architecture Management Concepts (more correctly, 'Architecture Description Management Concepts' as the subject is 'Architecture Description' not 'Architecture'

    States:
    'illustrated in the conceptual schema shown in Figure 3:1. These key concepts are highlighted in italics within the Narrative and some of the less obvious concepts are listed with the associated ISO-42010 2 meaning or the UAF meaning of that concept'

    The DMM 1.3 states - 'Further, The UAF conforms to terms defined in the ISO/IEC/IEEE 42010 standard for architecture description'

    1) If any definitions differ in the UAF vs ISO/IEC/IEEE 42010 then the UAF does not conform to the standard and any such claims need to be removed.
    2) Any references should be at the beginning of the document as other UAF documents not spread throughout the document on footnotes

  • Reported: UAF 1.2 — Tue, 23 Apr 2024 13:48 GMT
  • Updated: Wed, 24 Apr 2024 14:06 GMT

Invalid Version of ISO/IEC/IEEE 42010 - '2021' - Correct Year is 2022

  • Key: UAF13-170
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    p117 of A.4.1 Standards and Practices in the EA guide:-

    states - 'ISO/IEC/IEEE 42010:2021 – Software, systems and enterprise – Architecture description: provides core terms, definitions and relationships for architecture descriptions'

    1) The correct version is ISO/IEC/IEEE 42010:2022 - see https://www.iso.org/standard/74393.html
    2) The DMM refers to the 2011 version under Normative references. Not incorrect but likely inconsistent with any claims of conformance by the UAF

  • Reported: UAF 1.2 — Tue, 23 Apr 2024 13:21 GMT
  • Updated: Wed, 24 Apr 2024 14:05 GMT

2.2 Core Principles - Compliance Levels - Doesn't Define Compliance Levels. Not Consistent With UAF DMM Conformance Types. OMG Define UML Profile ...

  • Key: UAF13-169
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    2.2 Core Principles - Compliance Levels p 5 states:

    'Compliance levels: UAFML has a single compliance level based upon a combination of the reuse of UML and SysML elements. It is expected that the views that are created as result of this profile have frames that reflect the underlying SysML diagram type that is used as the basis for the view. It is also expected that the graphical notation used to display elements within those views correspond to the standard SysML graphical notation of the SysML/UML metaclass that the stereotype extends.'

    1) What does 'the UAFML has a single compliance level' actually mean?

    2) This makes no sense. The UAFML must conform to the DMM - the DMM defines the concepts, their meaning etc with which the UML + SysML implementation in this profile is required to conform. The DMM essentially defines the set of input requirements which any implementation, including the OMG's own UML + SysML profile, must meet

    3) Where is the traceability mapping to the DMM? This is missing and is required as part of the evidence of conformance to the DMM.

    4) This conformance is local to this UML profile. Given that there is a normative profile file what does conformance mean? The OMG define both so either the UML profile that the OMG also produces either conforms or it doesn't . If the OMG are stating that in order to conform some extra requirements have to be met which are not defined by the UML profile these requirements must be identified to enable a fully-traceable conformance assessment i.e. to UML profile + to other atomic requirements. At the moment this is incomplete - where is the evidence that the OMG with their UML profile for the UAF + 'something else' conform to the DMM?

    5) There is no reference to and this might be inconsistent with the conformance types stated in the UAF DMM section 2 (Type 1 to Type 3). The UAF DMM defines conformance levels for an implementation which have nothing to do with this local conformance and vice versa.

  • Reported: UAF 1.2 — Tue, 23 Apr 2024 12:25 GMT
  • Updated: Wed, 24 Apr 2024 14:05 GMT

9.1.1 ArchitecturalReference - Incorrect Name (Not a Reference to Architecture), Not a Tuple, Incorrect Definition. Not Needed - Use a Trace

  • Key: UAF13-168
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    9.1.1 Domain Metamodel::Architecture Management - Architectural Reference. p128 , Fig 9:125

    ArchitecturalReference defined as 'A tuple that specifies that one architectural description refers to another.'

    1) The name of the element should be 'ArchitectureDescriptionReference' as it isn't 'architecture' that's being referred to - it's an ArchitectureDescription element
    2) ArchitecturalReference isn't a tuple. The shortest possible tuple, a triple, is either node - relationship - node or node - relationship - (same) node if reflexicve. ArchitecturalReference is a relationship.
    3) The definition of a metamodel element must define the concept itself. This must be atomic. The 'one architectural description refers to another' defines how it may be connected - it doesn't define what 'ArchitecturalReference' is. If the element were defined you'd probably correctly decided that it isn't a concept for a metamodel because there is no atomic definition other than 'undefined' because it's semantically equivalent to the other "universal stuff" releationship, ArbitraryConnector. This sort of error would be much easier to trap if there was rigour in the definition of individual metamodel elements.
    4) A 'tuple' does not specify anything. This connector element is purely a description or assertion that there is some unknown relationship between 2 ArchitecturalDescription elements
    5) If a reference is required why isn't a trace relationship used? Then we'd have one less arbitrary metamodel element.

  • Reported: UAF 1.2 — Tue, 23 Apr 2024 11:36 GMT
  • Updated: Wed, 24 Apr 2024 14:05 GMT

Am-Mv Architecture Principles View Specification Doesn't Provide the Elements to Address the Concerns Identified. No Triples Defined.

  • Key: UAF13-167
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    View Specifications::Architecture Management::Motivation

    Am-Mv Architecture Principles 'View Specification' p19, Figure 8:1

    States: 'Concerns: alignment of architecture with architecture heuristics, guidelines, and principles.
    Definition: identifies relevant architectural principles and other guidelines to be used in architecture development and evaluation.'

    1) What does 'alignment of..' 'with' mean? Do you mean identification of the reference sources? Do you mean identification of input requirements? Do you mean conformance with requirements (process, technical etc)? The current is unspecific and will therefore yield inconsistent results. Should be 'alignment of architecture description' ('architecture description' not 'architecture')

    2) Fig 8:1 only provides a 'Driver' element and possibly typed by DriverKind (this isn't clear because of the notation. Is this a normative value - if so this needs to be made clear. At the moment it looks like an error of ommission. ''Architecture Principle' should be 'Architecture Description Principle'.

    3) Is the notation supposed to indicate that Driver has an attribute 'DriverKind' which has a set of enumerated values? Even in the UML you'd show an attribute on Driver and link this to the enumeration so this notation doesn't look to be complete. It could be interpreted as a form of specialisation of Driver

    4) There are no means to describe the 'alignment of architecture (description) with architecture heuristics, guidelines, and principles' - no relationships provided, no target elements to link Driver to etc. As shown a compliant architecture view wouldn't even constitute architecture desctiption since it'd be pemissible to provide a single Driver element not linked to anything - an orphan or soliton - which isn't describing anything.

    5) The multiplicity on DriverKind is incorrect - shows 0..1 which allows Driver to take an empty undefined value. This not only fails to address the architecture viewpoint concerns but is indeterminate. Should be '1'.

    6) The enumeration shown for DriverKind and on Fig 9:138 has no default value specified.

  • Reported: UAF 1.2 — Mon, 22 Apr 2024 11:56 GMT
  • Updated: Mon, 22 Apr 2024 16:09 GMT

7.2 Viewpoint Interraltionships - Incorrect Termininology, Doesn't Show Any Relationships. (MODAF) Viewpoints Do Not Have any Abstraction

  • Key: UAF13-166
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    7.2 Viewpoint Interrealtionships p 16

    The errors in this section are:-
    1) title - consistency 'Viewpoint' here is MODAF::Viewpoint NOT ISO42010::Architecture Viewpoint (or indeed the casual meaning of 'viewpoint'). None of this is clear. This is the UAF not the MoDAF - there is no need to use MODAF::Viewpoint and it's confuysing when the text uses 'viewpoint' to mean different things without defining terms. The section doesn't identify relationships between (MODAF) Viewpoints either.

    2) '...relationship between the Viewpoints, Aspects and View Specifications,' should be 'Architecture Perspectives, Aspects and Architecture Viewpoints'. There is no such thing as 'view specification' - if you mean the mechanism to specify an architecture view content etc the standard term is 'architecture viewpoint'.

    'two-dimensional nature it is not adequate to explain the abstract interrelationships that exist between the viewpoints. The following diagram is an indication of the how the viewpoints are interrelated'

    3) Figure 7:2 has no axis into the page - it has just as much '2-dimensional nature' (whatever this means) as the grid.

    4) Figure 7:2 neither shows nor explains any relationships between 'MODAF::viewpoints' in the UAF. It describes a set of levels with no explanation or rationale in terms of the order. In any case this ordering seems to be more associated with an order of describing things i.e. process and therefore shouldn't be in the DMM at all. The DMM isn't a process document - it defines metamodel elements, the triples formed and is supposed then to define the which architecture views (via ISO 42010::architecture viewpoints) allow the triples to be shown. Why, for example, is 'Projects' at the bottom? Why is 'Standards' on its own on the right hand side?

    5) '...the Viewpoint is a cross cutting concern' - is not true a (MODAF) Viewpoint is not a concern. No (MODAF) viewpoint is a concern. Do you mean than any element in the 'Architecture Management' (MODAF) Viewpoint may appear in any other 'viewpoint'? Probably not. I suspect it means that architecture views within the Architecture Management Perspective may be developed throughout the process of creating an AD. This isn't clear and it's not the correct document.

    6) 'the Viewpoint exists in a layer of abstraction between the Viewpoints above and below it' - (MODAF) viewpoints are not abstractions of each other. At best you can say that the metamodel elements in a particular 'viewpoint' represent concepts that are more abstract than ... but it is incorrect to say that a Viewpoint has any abstraction - it hasn't.

    The idea that this diagram describes any relationships is simply not true. The easiest solution is to delete section 7.2 - it isn't used anywhere within the DMM. All you need is 'the grid'.

  • Reported: UAF 1.2 — Mon, 22 Apr 2024 11:17 GMT
  • Updated: Mon, 22 Apr 2024 16:09 GMT

7.3 DMM Legend - 'External Type' Shouldn't Be Present in an Agnostic Spec (the DMM is Not a UML Profile)

  • Key: UAF13-165
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    7.3 Domain Metamodel Diagram Legend - Figure 7:3 Legend of color codes for element types defined in UAF

    This shows 'External Type' defined as 'An External Type is an element that exists outside of the core DMM but is referenceable by elements in the DMM'

    1) Consistency - What is a type? The term 'element' or metamodel element' is used

    2) There should be nothing external. The DMM is agnostic. It is also not a UML profile. it is not a SysML profile. The purpose of the DMM is to define an abstract metamodel (complete) and the ISO 42010::architecture viewpoint content using these metamodel elements.

  • Reported: UAF 1.2 — Mon, 22 Apr 2024 09:14 GMT
  • Updated: Mon, 22 Apr 2024 16:08 GMT

UAF Grid - Inaccurate Text. Gaps Don't Indicate Donor AF Coverage. Non- View Specification Content. Needs Donor AF to UAF Mapping in this Document

  • Key: UAF13-164
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    7 UAF Grid states:

    'Due to the complexity of managing the multiple viewpoints with overlapping concerns and metamodels, the standard viewpoints are refactored as described in the donor frameworks into a more manageable format. This decision led to the development of the UAF grid which is described below.'

    1) This isn't accurate or really correct. All AFs have multiple overlapping viewpoints - that's the basis of architectures description and the basis for ISO/IEC/IEEE 42010. The particular problem that the UAF had - not anyone else, including each donor AF, was a mechanism to classify and compare donor AF view subject area/purpose to support the creation of a common encompassing view set of 'view specifications' (in UAF speak). It has nothing therefore to do with overlapping viewpoints - it's a problmen caused by trying to represent multiple AFs using a single implementation. This is a UAF-management problem not a user- one.

    The text then states 'The intent of the grid is not to be complete, but to capture the information that is present in the frameworks that contributes to the UAF, consequently, some gaps are evident.'

    2) This isn't accurate either. The UAF defines 'view specifications' that are unique to the UAF and which are not present in any of the donor AFs - the grid therefore shows content that has nothing whatsoever to do with the donor AFs.

    3) The grid shows 'Simulation' and 'Parametric Execution/Simulation'. The subject matter of the grid is the set of 'view specifications' The fact that someone may choose to do some form of simulation is irrelevant to the DMM which is supposed to be a specification of the metamodel and view content. It mustn't include process. The grid is supposed to show architecture view coverage - these cells do not correcpond to view specifications and do not belong in the table or document. It misleads the reader into thinking that there are more view specifications than there are.

    4) This section keeps referring to donor AFs. It is almost impossible to figure out how they map to UAF 'view specifications'. The reader has to open the traceability document (which uses view specification identifiers not present in the DMM, find the table for the particular AF (or an appendix) and then switch back to the DMM. There should be another grid which simply places the donor AF view identifiers in each cell (and the DMM needs to eliminate 'view specification' and use the UAF identifiers for each definition.

  • Reported: UAF 1.2 — Mon, 22 Apr 2024 08:58 GMT
  • Updated: Mon, 22 Apr 2024 16:08 GMT

The UML Profile for the UAF Does Not Specify UAF Architecture Views or View Content - No Mechanism Within the XML

  • Key: UAF13-163
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    It states:
    'UAF provides a complete set of stakeholder viewpoints as the basis for defining the variety of necessary architecture views of an Enterprise and these views are specified in the UAFML.'

    1) 'stakeholder viewpoints' should be 'architecture viewpoints' in accordance with ISO/IEC/IEEE 42010
    2) a UML profile such as the UAFP does not specify architecture views nor view content. There is no standardised mechainsm within the UML to do so. The normative UML profile for the UAF - dtc/21-12-14 - contains no stereotypes to represent any UAF architecture view nor does it contain any definition of UAF architecture view content. [ The statement that 'these views are specified in the UAFML' is flat out untrue ]. Do the UAF authors not understand the architecture of the UML profile for the UAF?

  • Reported: UAF 1.2 — Fri, 19 Apr 2024 07:37 GMT
  • Updated: Mon, 22 Apr 2024 15:56 GMT

Incorrect Title '1.4 Layered Progression of Architecture Definition' - Should be 1.4 Layered Progression of Architecture Description'

  • Key: UAF13-162
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Incorrect section title - '1.4 Layered Progression of Architecture Definition'

    As it states: 'The viewpoints allow for a logical and systematic flow of architecting activities'. This has nothing to do with 'architecture definition' - it's the evolution of 'architecture description'

    The accurate title is therefore '1.4 Layered Progression of Architecture Description'.

  • Reported: UAF 1.2 — Fri, 19 Apr 2024 07:27 GMT
  • Updated: Mon, 22 Apr 2024 15:55 GMT

Consistency/Lack of Standardisation - 'stakeholder viewpoint', vs MODAF::viewpoint vs ISO 42010 Architecture Viewpoint

  • Key: UAF13-161
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The UAF is supposed to be a technical standard. The effectiveness of standardisation requires the use of the correct standard terms consistently. ISO/IEC/EEEE 42010 provides the correct terms needed for architecture description - both their names and the meanings - but the UAF mixes and matches terms, changes their names and intoroduces its own non-standard new ones. The use of 'viewpoint' is inconsistent and incorrect and there is nothing provided to the reader so that they can understand the different meanings of the same term. This wouldn't be a problem if the UAF used the term 'architecture viewpoint' (not 'viewpoint') as defined by ISO/IEC/IEEE 42010 for the meaning defined by the ISO.

    The abstract states:
    'The nine steps of the workflow are laid out in alignment with the stakeholder viewpoints in UAF for producing the requisite architecture views in each of those viewpoints'

    1) 'stakeholder viewpoints' should be 'architecture viewpoints' (viewpoints and views do not record something when "viewed from a particular direction"). The problem here, though is that these 'stakeholder viewpoints' are incorrectly termed 'view specifications' both in the UAF grid and the DMM package structure.

    2) 'architecture views in each of those viewpoints' - an architecture viewpoint is a specification for an architecture view not a containing mechanism - this use of 'viewpoint' is actually MODAF::viewpoint - a different thing and undefined

    3) wherever 'view' appears it should correctly be 'architecture view' in accordance with ISO/IEC/IEEE 42010 so that that the meaning is uambiguously tied to the ISO concept not the various casual uses of the term.

  • Reported: UAF 1.2 — Fri, 19 Apr 2024 07:07 GMT
  • Updated: Mon, 22 Apr 2024 15:55 GMT

The Master / Root Normative Specification to Which the EA Guide Conforms is the UAF DMM Not a UML Profile Implementation (UAFML)

  • Key: UAF13-160
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The abstract states:
    'This document describes a workflow for creating Enterprise Architecture (EA) views in accordance with the Unified Architecture Framework (UAF) Modeling Language (UAFML).'

    The traceability is incorrect. No process conforms to a UML profile - this makes no sense.

    A UML profile, the UAFML, is not the root / master / defining specification for the UAF - it is the agnostic UAF DMM specification. Unless you are stating that the EA guide is only applicable to one specific implementation and not any implementation of the UAF. If this is true the statement should be qualified to state that it only applies to the particular UML + SysML implementation provided by the UML profile (UAFML).

    Presumably since SysML has its own normative UML profile this profile should be renamed the SysML Modelling Language (SysMLML) ....

  • Reported: UAF 1.2 — Fri, 19 Apr 2024 06:52 GMT
  • Updated: Mon, 22 Apr 2024 15:55 GMT

A Repository Does Not Store Architecture - It Stores Architecture Description(s) - Differentiation of Duck vs Photo of Duck

  • Key: UAF13-159
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Figure 1:4 - Architecture Views and Models are Used in Other Architecture Processes shows a box labelled 'Architecture Repository'.

    This is incorrect. Using the ISO 42010 conceptual model the (real world) 'architecture' and 'architecture description' (an artefact) are separate concepts. You do not store the real world thing on a hard drive - you store its description.

    I would recommend checking and issuing the following as guidance to the UAF authors to avoid keep making this error - [1] ‘The Treachery of Images, 1929 by Rene Magritte’, Rene Magritte - Biography, Paintings, and Quotes. [Online]. Available: https://www.renemagritte.org/the-treachery-of-images.jsp

    It might seem trivial but it makes reading hard work particularly where you legilimately use an 'architecture description' to make comment on an 'architecture'. Because this error is so widesperead it's impossible for the reader to understand Figure 1.4 because anywhere 'architecture' appears it could really mean 'architecture description'

    If someone told you that they were storing a duck on a hard drive you'd question their sanity. If they instead correctly said they were storing a photo of a duck on a hard drive it'd be a perfectly understandable and reasonable thing to say. This persisant and endemic confusion of the two terms is that wrong.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 13:46 GMT
  • Updated: Mon, 22 Apr 2024 15:54 GMT

Consistency - 'ISO420:Architecture Description' vs 'UAF:ArchitecturalDescription'

  • Key: UAF13-158
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    A.4.3 Architecture Description Organization and Relationships p 119. 120

    The problem in not using the terms defined by ISO 42010 is that inconsistency results:

    'As the enterprise architecture description is built in those steps, it....'
    'Some architectural descriptions may represent generalizations or elements intended to convey guidance and patterns for reuse'

    'Architectural Description – a work product used to express the Architecture of some System Of Interest.It provides executive-level summary information about the architecture description in a consistent form to allow quick reference and comparison between architecture descriptions – It includes assumptions, constraints, and limitations that may affect high-level decisions relating to an architecture-based work program. (Note: architectural description is a UAF model element and “architecture description” is simultaneously a concept used in ISO 42010 that is defined as a collection of architecture views)'

    The Note is meaningless - what does ' simultaneously a concept used in ISO 42010 that is defined as a collection of architecture views' and how somehow does 'architectural description' differ?

    The definition deceives the reader into thinking that this is ISO 42010 definition. The first part has indeed been taken from ISO 42010 - reference needed and then has been added to starting with 'It includes...' which is not part of the ISO 42010 definition of 'architecture description'

    and in the DMM 9.1.2 p 130 we have 'Architectural Description' defined as 'An Architecture Description is a work product used to express the Architecture of some System Of Interest.'

    If it's an (ISO 42010) Architecture Description use the term Architecture Description.

    'to federate multiple architectural descriptions in a structured manner or as a set of associations or usages within an organization’s architecture description repository ...' - 'architecture description repository' (correct) storing 'architectural descriptions' (incorrect)

    'so that architecture description elements may be directly translated into model ...' - 'architecture description element' (correct) - not 'architectural description elements'. Interstingly the UAF DMM has no such thing as an Architecture Description Element.

    Later on we have:

    View – an “information item..' - this is incorrect the ISO 42010 term is 'architecture view' since 'view' has many other meanings.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 13:37 GMT
  • Updated: Mon, 22 Apr 2024 15:54 GMT

'Reference Architecture' Should be 'Reference Architecture Description'

  • Key: UAF13-157
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    In 3.3 Establishing the Purpose and Scope of the Architecting Effort we have :-

    'The enterprise architecture description is used by stakeholders to improve communication and cooperation among affected parties and enable them to work together in a more integrated, coherent fashion. This will, in turn, help the enterprise more effectively achieve its goals. This can be facilitated by creating a “reference architecture” that guides development of the rest of the enterprise architecture in Steps 3-7, as well as using an architecture framework that defines the views to be used.'

    The subject is an enterprise architecture descriptiuon.

    "Reference architecture" is incorrect - it should be "reference architecture description" that guides development of ... the 'enterprise architecture description' (not enterprise architecture)

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 13:19 GMT
  • Updated: Mon, 22 Apr 2024 15:54 GMT

Consistency - 'Cross Cutting Viewpoints' Are Not ISO42010:Architecture Viewpoints - They're MODAF::Viewpoints - Same Word, Different Meaning

  • Key: UAF13-156
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    1.6 Cross Cutting Viewpoints and Figure 1:5 - Cross-Cutting Viewpoints in UAF

    These are not 'Viewpoints' in the sense of either ISO/IEC/IEEE 42010 or even the UAF's own DMM - 9.1.2 Summary & Overview - Viewpoint p134 - Viewpoint.

    This inconsistency needs to be removed. Terms should not be incosistent with international standards. Any term used in the text should also be consistent with the underlying metamodel.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 13:11 GMT
  • Updated: Mon, 22 Apr 2024 15:54 GMT

Incorrect of the Term 'Modelling Language' As Synonym for a UML Profile

  • Key: UAF13-155
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Puzzled why the UML profile for the UAF, the UAFP, is now incorrectly termed the UAF Modelling Language as this introduces yet another unwanted term for a UML Profile that is in use for the SysML and the UML yet somehow confusing or not good enough for the UAF requiring it to invent its own bespoke term for the same concept.

    Looking at closed issue UAF-29 - https://issues.omg.org/issues/UAF12-29

    The argument then made:
    'Misunderstanding about whether the UAF Profile can be used in modeling an enterprise architecture. Not uncommon for managers to think that they must use SysML to model their EA since they don't realize that the UAFP is already designed with the semantics for modeling enterprise constructs such as capability, enterprise phase, processes, personnel, operations, services, portfolios, etc. This misunderstanding is largely due to fact that UAFP is called a "profile" and many don't understand what is meant by profile. '

    1) The UAFP is as is explained at length in the EA User Guide - an implementatoion of SysML so, yes, SysML is used for the UAF views. Are you stating that the UAF views can be produced in a UML modelling tool without the UAFP and without the SysML (non SysML users Don't Care About the this as it is irrelevant)
    2) The UAFP is a UML profile. If it isn't please explian why - there does seem to be an XML file that is a UML profile
    3) No users should be concerned with UML profiles - if they are it is because the OMG unnecesarily include this in user-facing documentation. The solution is to remove references to it from the EA User Guide

    The disposition on closing then states:

    'The decision has been taken by the group to rename the profile part of the specification to the modelling language following the naming convention of OMG, e.g. UML, SysML, SoaML, RAAML, etc. The change will improve clarity of the purpose of the document as the term "Profile" is not so well understood in non UML modellers community. Plus it is more than just profile. It also brings notation. '

    4) The UAFML is not distinct from the SysML - is every model using the SYSML now its own modelling language? Of course not.
    5) '"Profile" is not so well understood in non UML modellers ' - why does any non-UML modeller care about a profile - it's completely irrelevant because it's an implementation mechanism for a UML modelling tool. Non-UML modellers use the DMM which is supposed to be - but isn't quite yet - UML free / agnostic. This is invalid.
    6) The SysML and the UML are UML profiles. They also have 'notation' - whatever 'notation' means since this doesn't form part of any specification of the UAF DMM.
    7) The DMM correctly identifies the UAFML as a profile : 'The Unified Architecture Framework Modeling Language (UAFML) is the standard implementation of the UAF DMM. It was created by mapping the UAF concepts and relationships to corresponding stereotypes in the UAFML Profile.'
    8) The user cannot use the UAFML to create views - the XML profile does not content elements to represent the UAF architecture views nor define what is allowed in each `UAF architecture view - this is done in the UML modelling tool. The users cannot therefore use the UAFML without this extra hidden 'magic' (technical debt). They can, however, open a UML modelling tool and use the tool to create a UAF view of a particular flavour (with no mention or reference to the UAFML in sight).

    It is this casual creation of new terms to refer to existing terms that is one of the root causes of inconsistency within the UAF. The point of standardisation is sticking to the terms not constantly rolling your own.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 12:33 GMT
  • Updated: Mon, 22 Apr 2024 15:53 GMT

User Guide - The User Cannot Use the UAFML - they Use a Modelling Tool with Added Behaviours. Incorrect Claims for UAFML. UAFML benefits / features unclear

  • Key: UAF13-154
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    1.1 Overview of the Unified Architecture Framework - Modelling Using the UAF. states:-
    'Modeling Using UAF. The UAF Modeling Language 1 (UAFML) is an implementation of the DMM that specifies how the UAF views can be modeled using the SysML notation and semantics. Even though the UAFML is based on SysML, there are some significant differences that should be noted. SysML is great for doing the following activities:
    (a) modeling systems and for doing systems engineering,
    (b) defining and tracing between levels of abstraction within a system,
    (c) defining the logical and physical attributes for a system and the mapping of requirements and functions to these attributes. The UAF Modeling Language provides all this, plus more:
    a) Capability and Enterprise Concepts: defines the “why” and “what” and “when” before the “how”
    b) Services Concepts: definition of enterprise services (producing and consuming) and traceability to capabilities, operations and implementing resources
    c) Human Factors: How people and systems interact, and their expected knowledge & skills
    d) Security: Identifying risk, its mitigation, and integrating security into the architecture
    e) Standards: definition of and compliance with standards in the architecture
    f) Project Deliveries: phased milestone approach to capability deployment
    g) System Configuration Over Time: deployment and changes in roadmaps and timelines
    h) Tie-in to Non-System Elements in the Architecture: Easy way to link the entire Architecture to Requirements
    i) Built-in Traceability Between Multiple Views: Between Layers and Across Layers'

    The problems with this are:-
    1) The title is modelling using the UAF but most of the subject matter seems to be the UAFML
    2) This is a user guide - the user will never use the UAFML directly. The UAFML, more correctly the UAF (UML) Profile XML (), contains only UML and SysML implementations of the DMM elements. It does not contain any UAF architecture views nor does it define what triples appear in each UAF architecture view. This is implemented by the respective tool vendor. If the user did load the profile they would see a large set of UML/SDysML elements and they'd have to figure out which to use to produce a conforming UAF architecture view. The UAFML does not 'specifies how the UAF views can be modeled' - it simply defines which UML and SysML elements are used to implement the DMM elements needed.
    3) The UAFML isn't a modelling language - it's a single use of a modelling language (UML and SysML). It cannot be used as a modelling language by the user. It is a UML profile so new terms shouldn't be created for well defined and understood concepts. Are the OMG now renaming UML profile to 'Modelling Language'? This just adds inconsistency and shows a lack of the importance of standardisation. The language being used is still the UMNL or the SysML not the UAFML.
    4) d), e), h) incorrectly use 'Architecture' which should be 'Architecture Description'
    5) h) is meaningless - what is a 'tie-in to Non System Elements'? The subject seems to be traceability / conformance to requirements which can be described. And what does 'entire architecture' mean? Do you mean 'any Architecture Description Element can be linked to one or more Requirements'? Why 'Non-System'? Don't you allow a System element to be linked to Requirements?
    6) f) is titled 'Project Deliveries' but then describes 'capability deployment' - projects always deliver tangible things, which may include Systems. The sentence should be modify to describe what the UAF can describe wrt project delivery [how this affects capability is the subject of a))
    7) c) Human Factors - 'expected competences and skills' should be 'competences' (the text needs to use the terms in the DMM so cross-comparison is possible)
    8 e) h) Standards - 'Requirement' isn't a UAFElement or indeed a DMM element (DMM Figure 9:134) - it doesn't exist within the UAF
    9) Built-in Traceability. What does this mean? What DMM elements are automatically linked to what other DMM elements? The UAF Grid doesn't define layers so what is a 'layer'? This could be a liability if the user has no control.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 11:17 GMT
  • Updated: Mon, 22 Apr 2024 15:53 GMT

Incorrect Use of MODAF::Viewpoint in Grid

  • Key: UAF13-153
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    1.1 Overview of the Unified Architecture Framework p2 states:-

    'The UAF Grid (Figure 1:2) has rows that represent typical stakeholder domains (or viewpoints as they are called in UAF)'

    Figure 1:2 shows a left hand column which the callout labels as 'Viewpoints'. The cells identifiy 'View Specifications'

    This is clearly wrong and inconsistent with ISO/IEC/IEEE 42010. It looks as though the authors have not appreciated that 'viewpoint' for the leftmost column derives from the MODAF use of the term to collect together a group of architecture view definitions with a common theme. In the old ISO/IEC/IEEE 42010:2011 text this was referred to as an (architecture) perspective. In misusing 'viewpoint' this then left a problem of how to refer to the things that specify architecture view content (ISO42010:Architecture Viewpoint) and therefore another undefined term was added - 'view specification' which seems to mean the same thing as ISO42010:Architecture Viewpoint.

    The use of 'view specification' is further muddied by the DMM Figure 7-1 p13 which states that 'view specifications (cells) correspond to viewpoints'. This could be read a view specifications is a synonym for viewpoint.

    It's a mess. The easiest solution is to consistently use the ISO 42010 definitions and the names of the ISO 42010 concepts without alteration

    1) Eliminate any mention of 'view specification' where this refers to an artefact that specifies architecture view content. The correct term is 'Architecture Viewpoint' not 'Viewpoint' (as this is otherwise easily confused with other uses of the term).
    2) The use of Viewpoint in reference to the left hand column of the UAF Grid is incorrect - that is an inconsistent and incorrect and doesn't (as claimed) conform to ISO/IEC/IEEE 42010. The suggestion is 'Architecture Perspective'. 'Domain' often refers to other things. Whatever term is used it needs to be prefixed with 'Architecture' to separate it from the casual use of the term.
    3) Correct the names of the metamodel elements in the DMM. If you can't or won't, produce a mapping table that demonstrates the mapping and the equivalence to the standard.

    4) A viewpoint is not a 'stakeholder domain'. This seems to be using 'viewpoint' in another sense. It is also not a synonm for 'domain'. The cells identifiy 'architecture viewpoints' - specifications against which architecture views are created and interpreted.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 09:01 GMT
  • Updated: Mon, 22 Apr 2024 15:52 GMT

Incorrect Inclusion of UAF Architecture Viewpoints in an AD. Inconsistent and Incorrect Definition of 'Concern'. A StrategicPhase is Not a System

  • Key: UAF13-152
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    4.1.3 Architectural Description Structure p26 states:

    'Each architectural description is either decomposed into, or synthesizes, views and viewpoints, which may be laid out in dashboards and other fit-for-purpose perspectives to aid in understanding an architectural plan. Each planned viewpoint should address specific concerns held by relevant stakeholders'

    1) Simply 'decomposes into or synthesizes' to 'formed from' - the aim should be to have as short a document and as short as sentences as possible.
    2) 'decomposes into ... viewpoints' is incorrect for the UAF. Users are not going to include the UAF viewpoints in each of their architecture descriptions. Even in ISO/IEC/IEEE 42010 where it got less clear in the 2022 edition owing to removal of multiplicities the inclusion of architecture viewpoints is a 'may' not 'shall'
    3) What's a 'planned viewpoint' ? Architecture Viewpoints don't address concerns - iaw ISO/IEC/IEEE 42010 they frame concerns. It is not 'should' - Architecture Viewpoints always frame at least one Concern - mandatory i.e. don't misquote the standard. In following the guide the user should reasonably expect to conform to the standard. This process step seems to be the inverse of what the standard says - you first establish what the architecture description task stakeholders concerns are, then you select the architecture viewpoints that most closely frame those concerns.

    Later on we have:

    'Concern – interest in a Strategic Phase (Strategic Phase is synonym for System in ISO 42010) relevant to one or more of its stakeholders. (Note: a concern may be a “matter of relevance or importance to a stakeholder regarding an entity of interest” [ISO 42010] that will be addressed in an architecture)'

    4) A Concern is not an interest in a Strategic Phase. In ISO/IEC/IEEE 42010 it's 'matter of relevance or importance to a stakeholder'. In the DMM p131 it's 'A matter of relevance or importance to a stakeholder regarding an entity of interest.' which is more restrictive that the standard - you can only raise a concern about the entity of interest. It's definitely NOT 'interest in a Strategic Phase'. Suggest that you adopt the ISO definition consistently and without additions.
    5) Strategic Phase is NOT a synonym for System in ISO 42010 - a duration or time period is not equivalent to a System
    6) a Concern is addressed in an 'architecture description' NOT 'architecture' via the content of the architecture views produced.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 08:26 GMT
  • Updated: Mon, 22 Apr 2024 15:51 GMT

Inconsistent Definition of 'Architecture'. Unintelligable Note. Incorrect Reference. Step Name Should be 'Define Architecture Description Drivers and Challenges'

  • Key: UAF13-151
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    4.1 Step 1 Define Architecture Drivers and Challenges p22

    1) The subject isn't 'architecture' - it's 'architecture description' - reference materials, the AD effort. The name should therefore be 'Define Architecture Drivers and Challenges'
    2) It incorrectly states 'The Summary and Overview architecture view defines the overall architecture'. It doesn't. It defines the architecture description. If you look at p25 in the DMM - View Specifications::Summary & Overview::Summary & Overview - states 'Concerns: quick overview of an architecture description and summary of analysis.' i.e. 'architecture description' not 'architecture'

    p23 we have a definition of 'architecture':
    'Architecture – fundamental concepts and properties related to an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes [ISO/IEC/IEEE 42020:2019] (Note: This architecture entity can be an enterprise or system or some other kind of thing. These fundamental concepts and properties can be about key entities and relationships, along with associated behaviors, which are characterized in an architectural description.)'

    3) The source for the definition should be ISO/IEC/IEEE 42010 not ISO/IEC/IEEE 42020
    4) There is an additional note which isn't part of the original source - this incorrectly states 'This architecture entity can be an enterprise or system or some other kind of thing'. This cannot be true. In ISO/IEC/IEEE 42010:2022 we have in the conceptual model 'Entity of Interest has Architecture' therefore Architecture cannot be the same as Entity of Interest or System.

    In the DMM 9.1.2 Domain MetaModel::Summary & Overview p 131 we have a definition for the Architecture metamodel element:

    'An abstract type that represents a generic architecture. Subtypes are OperationalArchitecture, Service Architecture, and ResourceArchitecture.'

    5) Ignoring the fact that the DMM doesn't define the Architecture concept - it only defines its use in representing a real world thing (as all AD elements do) - we have 2 different definitions of Architecture. The DMM one is incorrect. The suggestion is to use the ISO/IEC/IEEE 42010 one unaltered - the UAF incorrectly claims that it conforms to ISO/IEC/IEEE 42010 so why wouldn't it use the definitions and relationships from the standard?

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 07:51 GMT
  • Updated: Mon, 22 Apr 2024 15:51 GMT

'Definition' Seems to be an Attribute of Any UAFElement - It Shouldn't Be a Separate Element (Inconsistent Representation of Attributes)

  • Key: UAF13-150
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The metamodel element Definition is defined 'A comment containing a description of an element in the architecture.' and Figure 9:119 shows that there is some unnamed relationship between UAFElement and Definition (impossible to extract any meaning from this).

    1) The definition of Definition is wrong - 'a comment containing a description' - is this Comment, Description or, as the element name says,a definition?
    2) Every UAFElement presumably has a 'description' - if Definition is an attribute of every UAFElement why not show it as such on the UAFElement (as has been done with the 'author' element of Definition - inconsistent representation of attributes). If this isn't an attribute there needs to be something in the text of the document to explain how to interpret. All relationships should be named - any unnamed relationship, excepting specialisation, is an error as it leaves the interpretation to guesswork . Role names are a bonus.
    3) The 'author' element name needs to be qualified to 'definition author' or 'comment author' to separate it from the DCMI creator tag (= author). It isn't clear in the UAF whether there is an 'element author' - the person who created the element. It would make more sense for the element creator to be captured since they presumably define the element on creation - simply capturing the definition author and not the element author makes little sense.

  • Reported: UAF 1.2 — Wed, 17 Apr 2024 07:47 GMT
  • Updated: Mon, 22 Apr 2024 15:51 GMT

Figure 9:118 Caption ' ArchitectureMetadataDefinition' Includes the Following Metamodel Element Title ('Definition')

  • Key: UAF13-149
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    9.1.1 Domain Metamodel::Architecture Management - Definition / Figure 9:118

    The 'Definition' metamodel element title has somehow got merged into the preceding Figire 9:118 caption - 'Figure 9:118 – ArchitectureMetadataDefinition'

  • Reported: UAF 1.2 — Wed, 17 Apr 2024 07:20 GMT
  • Updated: Mon, 22 Apr 2024 15:50 GMT

View Specification - Am-Pr Architecture Development Method Name Doesn't Match Subject. Missing (No) Triples to Address Concerns

  • Key: UAF13-148
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    8.1.1 View Specification - Am-Pr Architecture Development Method is defined:

    'Stakeholders: Enterprise Architects, Model Managers, Modelers, Enterprise Systems Engineers. Concerns: development sequence of models and views and how they are related to each other. Definition: defines workflow or process steps used in managing the architecture development. Recommended Implementation: SysML Activity Diagram, text.'

    Figure 8.4 shows a single element - ArchitecturalDescription. No relationship elements. No architecture views,

    1) The subject description of views, their sequence etc is not 'architecture' it's 'architecture description'. The view specification name is therefore not correct - the subject doesn't appear within the view specification name - it should be 'Architecture Description Method'
    2) There are no elements / triples provided to describe the sequence of models, views and how they relate to each other hence Fig 8.4 does not provide the means to address the concerns. Presumably there should be at least the means to describe a trace. To describe a sequence of views you need something like 'View follows View'
    3) Figure 8.4 only shows a single attribute for ArchitecturalDescription - see Figure 9:129. It ought also to include purpose, assumptionandConstraint etc (all of the ISO/IEC/IEEE 42010 required properties)
    4) It suggests using a SysML Activity Diagram but provides no triples to describe Activities or their sequence.
    5) If models and their sequence are expected you need to provide the means to describe them.
    6) This view specification does so little that there seems to be little point in its existance - it would be easy to incorporate the concerns into another Am view specification.

  • Reported: UAF 1.2 — Tue, 16 Apr 2024 11:13 GMT
  • Updated: Mon, 22 Apr 2024 15:50 GMT

Tables Refer to a View Specification Am-Tx Architecture Extensions that Doesn't Exist + Table Numbering Error Table 1:2

  • Key: UAF13-147
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The tables Table 2:1, 1:2, 2:2, 2:3 mapping the various AF viewpoints to the UAF view specifications show a Am-Tx Architecture Extensions view specification that doesn't exist. Until the view specification has been defined these rows should be deleted.

    Table 1:2 has a table number that doesn't fit with the previous 2:1 table and the following Table 2:2 identifier. The identifiers for the tables 1:2, 2:2 and 2:3 need to be corrected.

  • Reported: UAF 1.2 — Tue, 16 Apr 2024 10:51 GMT
  • Updated: Mon, 22 Apr 2024 15:50 GMT

UAF Grid and text refers to 'Architecture Extensions' View Specification - View Specification Doesn't Exist

  • Key: UAF13-146
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Section 7 UAF Grid. Fig 7-1 and note e) refer to a 'Architecture Extensions' view specification:
    'The Architecture Extensions view specification provides a means to extend the framework to other domains'

    1) There is no 'Architecture Extensions' view specification in 8.1 View Specifications
    2) The name 'Architecture Extensions' is incorrect - the subject is not the architecture but the architecture description (it describes means to extend the architecture framework not the architecture'. The name should more accurately be 'Architecture Description Extensions' or 'Architecture Framework Extensions'.

  • Reported: UAF 1.2 — Tue, 16 Apr 2024 10:35 GMT
  • Updated: Mon, 22 Apr 2024 15:49 GMT

View Specification Am-Tr Architecture Traceability - Only 1 Relationship Element Provided, Unable to Describe Traces to External Sources

  • Key: UAF13-145
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Figure 8:10 - Architecture Traceability.

    The (Am-Tr) Architecture Traceability view specification has a number of problems:-
    1) Figure 8-10 only allows one relationship (in green) - ...Architecture implements ...Phase - what is this supposed to mean - there is no direction ? How does this address the understanding of 'the impact of change'?
    2) Under stakeholders - 'people who want to understand impact of change across the architecture supporting assets,' is a concern not a role
    3) Under concerns - 'reuse of architectures' - given the widespread conflation of 'architecture' and 'architecture description' does 'architecture' here mean 'architecture'?
    4) ArchitecturalDescription is show yet there is no allowed relationship with it. As it does not contribute any tripes that are allowed it should not be shown in the Figure
    5) Under definition we have 'shows references to ... external sources, e.g. documents'. There are no relationships or artefact elements shown to enable these references to be described
    6) Typo on role on Architecture - 'realizingArchitedcture'

  • Reported: UAF 1.2 — Tue, 16 Apr 2024 08:24 GMT
  • Updated: Mon, 22 Apr 2024 15:49 GMT

ActualPerson is not a Distinct Type. Inconsistent Representation of Individual vs Type/Class wrt Other Metamodel Elements (ActualXXX Elements Contradict Class Mechanism))

  • Key: UAF13-144
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    9.1.6 Domain Metamodel::Personnel - Person, Figure 9:234

    Person is defined as '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).'

    1) This doesn't define what the 'Person' concept is - it only defines how it is used for an implementation that seeks to be able to represent a real world person. Every Class/Type defines properties applied to an individual - this is not an identifying feature.

    2) In most modelling languages such the UML etc we have a means to represent a type (Class) e.g. UML Class and an individual (instance of a UML Class). The individual / instance automatically takes on the propertties of the type / Class.

    If, for example, I instantiate a UML Class named 'Car' that has a property, 'manufacturer' the resulting element is an individual which we understand to represent a real world thing, Car. I can then allocated the manufacter's name to the 'manufacturer' property. None of this requires an ActualCar - all of the Class/Type properties are defined as part of the Class/Type - there is no new type or stereotype needed to define Class properties.

    For example if I have a model element of Type/Class = Standard and then give it a DCMIIdentifier = 'ISO/IEC/IEEE 42010' and DCMITitle = 'Interational Standard - Systems and Software - Architecture Description' everyone understands that this is a representation of the real world artefact - ISO/IEC/IEEE 42010. There is only the one Class/Type which defines the properties that make the Class unique from all other types. Class definitions have to be unique - if they depend on another Class then they're not. There is no ActualStandard required.

    ActualPerson is not a type of Person - as defined it only exists to hold a set of properties that can be applied to an individual or instance of the Person Class/Type.

    This separation is completely inconsistent with every other UAF metamodel element - we don't have ActualArchitecturalDescription, ActualArchitectureViewpoint, ActualStandard et al. This looks to be an old error inherited from early MODAF days where someone was thinking of abstractly representing instantiation but made the mistake of embedding this in what was a UML implementation (the M3).

    The 'Actualxxx' construct isn't needed in the UAF. Nor is it needed by any implementation of the UAF in any other ADL. On p288 we have ActualPerson = 'An individual human being.' - it isn't - it's supposed to be a type of Person. This makes no sense since the metamodel presents types.

    It adds more elements, relationships, complicates implementation, adds inconsistencies and increases the cost of maintenance for no good reason.

    From a practical means to define properties of individuals there is no technical need for ActualPerson, Actual-anything.

    The DMM looks to be a bottom-up merging of donor AF metamodels warts and all rather than a top-down what-do-I need-to-address-each-viewpoint-concern. This has not only not preserved errors but does not produce the smallest metamodel needed (very much like constructing programme task logic from the start/left rather than starting with the end deliverable and working to the left).

  • Reported: UAF 1.2 — Mon, 15 Apr 2024 13:36 GMT
  • Updated: Mon, 22 Apr 2024 15:48 GMT

ServiceRole is Neither a Type of Nor Part of a Service

  • Key: UAF13-143
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    9.1.5 Domain Metamodel::Services - ServiceRole , Figure 9:215 - ServiceRole

    'A behavioral feature of a Service whose behaviour is specified in a ServiceFunction'

    a Role is something that is played by typically an Actor. i.e. the relationship is something like Service plays ServiceRole (if the metamodel names are accurate).

    Instead what is shown is:-
    1) a role name of 'type' on Service - Service is a type of ServiceRole?
    2) whole:part relationship - ServiceRole is a part of Service - it shouldn't be a whole:part if a role is played by the element
    3) How does anyone in a non-UML or even UML ADL implement this view specification - the only 3 green relationship elements provided are ServiceMessage from/to ServiceRole, ServiceConnector from/to ServiceRole, the other end of PerformsInContext isn't shown. There are many possibilities (OperationalRole, OperationalActivityAction, FunctionAction, ResourceRole, ServiceFunctionAction, ServiceRole) - Figure 9:107 - which one or ones are permitted for this view specification? This is a problem in not presenting whole triples i.e. there should be no case where both the from and to node elements aren't also shown.
    4) role names on ServiceMessage should be on ServiceRole not the ServiceMessage connector element
    5) The definition of ServiceRole is not atomic and hence incorrect - in depends on the existence of a relationship with a ServiceFunction element hence is not independent and defines a triple.

  • Reported: UAF 1.2 — Mon, 15 Apr 2024 08:52 GMT
  • Updated: Mon, 22 Apr 2024 15:47 GMT

'Usage of + 'Whole:Part' - ProtocolLayer is Not a Distinct Metamodel Concept - It is a Reflexive Whole:Part Relationship on Protocol

  • Key: UAF13-142
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    9.1.10 Domain Metamodel::Standards::Structure , Fig 9:236 ProtocolLayer

    ProtocolLayer is defined as 'Usage of a Protocol in the context of another Protocol. Creates a whole-part relationship.'

    1) ProtocolLayer (as identified by 'another' and 'usage') is not therefore distinct from Protocol and shouldn't therefore be a metamodel element - it should be represented by a whole:part relationship on Protocol.

    2) ProtocolLayer is not a type of Protocol - which I what I think the incorrect role name on the Association from ProtocolLayer to Protocol is stating. whole:part + type = ?

    3) Any metamodel element including 'usage' is likely to be invalid. Usage is a particular UML implementation and often a fudge. No metamodel element is a usage of any other. An elementis its own thing - if usage is involved it is not a distinct concept.

  • Reported: UAF 1.2 — Mon, 15 Apr 2024 08:19 GMT
  • Updated: Mon, 22 Apr 2024 15:47 GMT

8.1.4 View Specifications::Operational::Sequences::Operational Sequences View Specification Doesn't Provide Any Sequencing Triples to Address Its Concerns

  • Key: UAF13-141
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    View Specifications::Operational::Sequences::Operational Sequences View Specification:

    'Concerns: express a time ordered examination of the operational exchanges as a result of a particular operational scenario.

    Definition: provides a time-ordered examination of the operational exchanges between participating nodes (OperationalPerformer roles) as a result of a particular operational scenario'

    1) Figure 8:29 includes no triples to define the order of exchanges of operational messages. Even the incorrectly included UML Lifeline does not define an order - it is inferred by visual presentation reading from, say, top to bottom or annotating with a sequence number. There are no formal semantics that define the order of a sequence. In any case the UML shouldn't be in this document - it is a specific implementation. The missing part in this view specification is something that semantically describes order or=f exchanges (which the UML etc is then able to implement) i.e. something like' OperationalExchange follows OperationalExchange'

    2) The concern isn't 'time-ordered examination' - it is something like 'in what order ....'

    3) The definition should be phrased in terms of real world things not the metamodel representing the real world. It might include the application of the viewpoint to real world situations. Simply describing the metamodel provides no utility.

  • Reported: UAF 1.2 — Mon, 15 Apr 2024 06:56 GMT
  • Updated: Mon, 22 Apr 2024 15:47 GMT

8.1.4 View Specifications::Operational::Sequences::Operational Sequences View Spec Includes UML Metaclasses

  • Key: UAF13-140
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Figure 8:29 Operational Sequences shows 3 UML Metaclasses - Message, Interaction and Lifeline.

    The DMM is supposed to be agnostic and therefore should include no UML, SysML, BPMN et al ADL elements. The UML/SysML implementation is supposed to be in formal/22-07-05 UAF Modelling Language

  • Reported: UAF 1.2 — Mon, 15 Apr 2024 06:40 GMT
  • Updated: Mon, 22 Apr 2024 15:46 GMT

Operational Structure Viewpoint Identifier Should Be 'Op-Sr' Not 'Op-St' (which duplicates Operational States Viewpoint Identifier)

  • Key: UAF13-139
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Table 2:1 - UAF 1.2 to DoDAF 2.02 Mapping at the bottom. The Operational Structure viewpoint identifier is shown as 'Op-St' which duplicates the Operational States Viewpoint identifier. it should be 'Op-Sr'

  • Reported: UAF 1.2 — Sat, 13 Apr 2024 20:09 GMT
  • Updated: Mon, 22 Apr 2024 15:46 GMT

8.1.1 View Specifications::Architecture Management::States::Architecture Status has Nothing to Do with 'Architecture' - It Describes the State of the Architecture Description

  • Key: UAF13-138
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Another consequence of the failure within the UAF to distinguish between 'Architecture' and 'Architecture Description' concepts.

    The title of the viewpoint (not 'View Specification') is ' - View Specifications::Architecture Management::States::Architecture Status

    'Stakeholders: Enterprise Architects, people who want to understand the architecture governance, Technical Managers. Concerns: architecture status.

    Definition: captures version number and approval workflow of the architecture. Recommended Implementation: SysML State Machine Diagram, state table, text.

    ArchitecturalDescription

    status : String [*]

    ...

    Figure 8:5 - Architecture Status'

    Figure 8.5 shows the ArchitectureDescription element - NOT any ...Architecture element. It is clear that the viewpoint describes the state of the architecture description not architecture.

    Hence NOT 'architecture governance' - should be 'architecture description governance', 'approval workflow of the architecture description', The name of the viewpoint should be 'Architecture Description State' since 'St' = state and the subject is 'Architecture Description' not 'Architecture'

  • Reported: UAF 1.2 — Sat, 13 Apr 2024 19:50 GMT
  • Updated: Mon, 22 Apr 2024 15:46 GMT

Missing Traceability and Evidence to Support Claim of Implementation of DMM by the UAFP (UAFML)

  • Key: UAF13-137
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

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

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

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

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

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

  • Reported: UAF 1.2 — Fri, 12 Apr 2024 09:41 GMT
  • Updated: Fri, 12 Apr 2024 19:28 GMT

Type 1 Conformance Incorrectly Uses MODAF::Viewpoint Term as Collection of ISO42010::Architecture Viewpoiint Definitions

  • Key: UAF13-136
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

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

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

  • Reported: UAF 1.2 — Thu, 11 Apr 2024 14:50 GMT
  • Updated: Fri, 12 Apr 2024 19:26 GMT

1.1 Introduction, 1.2 UAF Background Incorrectly Uses 'Architecture', 'Architectures' to Refer to Architecture Description

  • Key: UAF13-135
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

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

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

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

  • Reported: UAF 1.2 — Thu, 11 Apr 2024 14:39 GMT
  • Updated: Fri, 12 Apr 2024 19:26 GMT

UAF View Specifications Don't Use UAF Identifiers and Depend on Package Striucture + Incorrect Traceability Doc Identifier

  • Key: UAF13-134
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

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

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

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

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

  • Reported: UAF 1.2 — Wed, 10 Apr 2024 11:01 GMT
  • Updated: Wed, 10 Apr 2024 13:38 GMT

View Specifications::Motivation:Requirements Doesn't Permit Requirement traces to Requirement, Requirement refines Requirement

  • Key: UAF13-133
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Requirement is not a UAFElement - p133, p103

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

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

  • Reported: UAF 1.2 — Wed, 10 Apr 2024 10:40 GMT
  • Updated: Wed, 10 Apr 2024 13:37 GMT

ServiceArchitecture Defined as AD, ServiceArchitecture Is not a Service as Stated

  • Key: UAF13-132
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

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

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

  • Reported: UAF 1.2 — Wed, 10 Apr 2024 10:08 GMT
  • Updated: Wed, 10 Apr 2024 13:37 GMT

View Specifications::Motivation::Motivation: Requirements - No Direction for Satisy, Refine, Verify + Duplicate Trace - Requirement Relationship

  • Key: UAF13-131
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

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

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

  • Reported: UAF 1.2 — Wed, 10 Apr 2024 09:42 GMT
  • Updated: Wed, 10 Apr 2024 13:36 GMT

Metadata - category refers to DCMI abstract (not a category) / dublinCoreTag. DCMI Only Applies to Artefacts (Documents, Sound, Video, Text) Not any UAFElement

  • Key: UAF13-130
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Metadata attributes - DCMI

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

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

  • Reported: UAF 1.2 — Tue, 9 Apr 2024 08:05 GMT
  • Updated: Wed, 10 Apr 2024 13:35 GMT

View Specifications::Summary & Overview::Summary & Overview - Missing Relationships and Triples, Concerns Not Defined

  • Key: UAF13-129
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    8.1.2 View Specifications::Summary & Overview::Summary & Overview

    General problem - there is no such thing as 'view specification' - it doesn't exist in the DMM itself (text should only include defined concepts), it seems to be being used as a synonym for ISO 42010::'architecture viewpoint' (if this is the case then 'architecture viewpoint' is the correct and consistent term to use.

    Concerns: ''quick overview of an architecture description and summary of analysis. In the initial phases of architecture development, it serves as a planning guide. Upon completion of an architecture, it provides a summary of findings, and any conducted analysis.'

    Problems -
    1) this is an overview and its application not a list of concerns held be stakeholders
    2) Given the common confusion in the UAF between 'architecture' and 'architecture description' - is this 'phases of architecture development' or 'phases of architecture description development'? Since an architecture description may be used to provide comment on architecture this is ambiguous in the UAF contetx where these terms aren't differentiated.
    3) 'It isn't completion of architecture - it's not even completion pf 'architecture description' - what the author seems to be stating is completion of the 'architecture task' that produce the architecture description. The description os wrong and possibly more triples need to be defined in the DMM

    Defintion
    'provides executive-level summary information in a consistent form that allows quick reference and comparison among architectures. The Summary and Overview includes assumptions, constraints, and limitations that may affect high-level decision processes involving the architecture.'

    Problems;
    4) This is a description not a definition

    Figure 8:11 - Summary & Overview

    The green elements are relationships - not tuples as defined in the legend. The expectation is that view content consists of triples (node-connector-node).
    5) General problem - There is nothing that defines how these views are to be interpreted (ISO 42010 requires this and it would aid consistent development and provide rules for verification of each view).

    Anything that doesn't form the basis for a triple shouldn't be in the viewpoint definition i.e.

    6) ArchitecturalDescription, ArchitectureMetadata, Metadata as these don't appear to form any triple

    7) View, Viewpoint. There are no relationship elements provided to form a triple with ArchitecturalDescription

    8) Stakeholder, Concern, OrganizationalResource, ActualOrganizationalResource have no relationship with ArchitecturalDescription

    9) There is no relationship element between ArchitecturalReference and Architecture so it is impossible to establish a link between the Architecture, its impacts etc and the ArchitecturalDescription so impossible to describe this.

    Triples should be able to be read as sentences and have clear semantics:

    'ArchitecturalDescription Architectural Reference Architectural Description'
    10) What does this mean? Is this a trace between ArchitecturalDescriptions i.e. 'ArchitecturalDescription traces to / references / etc ArchitecturalDescription'. A currently defined this makes no sense. I suspect that the problem is that elements are added but the triples so-formed are not being read to make sure that they are intelligible i.e. object-focussed rather than relationship-focussed approach.

    11) 'Opportunity Phases ActualStrategicPhase' - what does this mean? If the sentence is unclear it either won't be used or be used inconsistently as each individual attempts to try and understand it (not conducive to shared understanding)

    [Note - owing to inconsistency in form behaviour between specification and OMG Document number the original was misallocated to SysML as SYSML17-647 which can be deleted]

  • Reported: UAF 1.2 — Tue, 9 Apr 2024 07:55 GMT
  • Updated: Wed, 10 Apr 2024 13:35 GMT

UAFElement - Attributes Missing. URI incorrectly defined

  • Key: UAF13-128
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

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

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

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

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

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

  • Reported: UAF 1.2 — Mon, 8 Apr 2024 15:53 GMT
  • Updated: Wed, 10 Apr 2024 13:34 GMT

Metadata, ArchitectureMetadata Not Defined Correctly. ArchitectureMetadata duplicates Metadata - Both Define Metadata for an AD

  • Key: UAF13-127
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    This is a consequence of the lack of differentiation within the UAF (and donor AFs) between 'Architecture' and 'Architecture Description'

    Fig 9:122 Metadata.
    Definition: 'A comment that can be applied to any element in the architecture. The attributes associated with this element details the relationship between the element and its related dublinCoreElement, metaDataScheme, category and name. This allows the element to be referenced using the Semantic Web.'

    it is clear that this refers to 'architecture description' not 'architecture' e.g. the application of DCMI elements

    It should therefore be 'applied to any element in the architecture description'

    If Metadata is already defined as applying to an architecture description, how can ArchitectureMetadata specialise this and also be applied to the architecture description description - this is what Metadata does and as part of an AD which describes an architecture there is no need for 'ArchitectureMetadata'?

  • Reported: UAF 1.2 — Mon, 8 Apr 2024 11:00 GMT
  • Updated: Mon, 8 Apr 2024 14:22 GMT

UAFElement Definition Doesn't Define Concept - Is This Really 'Architecture Description Element'?

  • Key: UAF13-126
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    UAFElement is defined: 'Abstract super type for all of the UAF elements. It provides a way for all of the UAF elements to have a common set of properties.'

    This doesn't define the concept. It simply states what purpose the element serves for a developer. The name tells us nothing. In the metamodel the names are supposed to indicate what they represent.

    Do all UAFElements appear in an architecture view and therefore architecture description? if so it might really be 'Architecture Description Element'. This term first appeared in ISO 42010:2011 and in 42010:2022 is an 'identified or named part of an architecture description'. Alternatively it might be 'An individual architecture description object that is used to describe or represent an item of real-world architecture. An architecture description element can appear in an architecture description.' <https://trakmetamodel.sourceforge.io/vocab/TRAK_metamodel.html#Architecture_Description_Element>

  • Reported: UAF 1.2 — Sun, 7 Apr 2024 14:53 GMT
  • Updated: Mon, 8 Apr 2024 14:21 GMT

Figure 8-14 Strategic Structure Does Not Provide Elements to match definition of View Specifications::Strategic::Structure::Strategic Structure

  • Key: UAF13-125
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Figure 8-14 only shows Capability, CapabilityRole elements.

    The definition of the view specification is: 'Definition: shows the relationship between EnterprisePhases and the Capabilities that are intended to be developed during the enterprise phases, and the organizations involved in the enterprise.'

    It is impossible to construct a view using Figure 8-14 that satisfies this because:-

    a) No EnterprisePhase (should this be ActualEnterprisePhase?) nor element to describe relationship(s) with Capability
    b) What has CapabilityRole to do with this view specification? As defined this seems unsolicited and isn't connected to the definition
    c) Even with Capability, CapabilityRole elements provided the view specification doesn't include any relationship elements ('tuple') in green to connect Capability to anything else

  • Reported: UAF 1.2 — Sun, 7 Apr 2024 10:29 GMT
  • Updated: Mon, 8 Apr 2024 14:20 GMT

Figure 9:164 - ActualEnterprisePhase Class Hierarchy Incorrect & Doesn't Match Definitions of Types - An Endeavour etc Isn't a Time Period

  • Key: UAF13-124
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The definitions of ActualEnterprisePhase, WholeLifeEnterprise and EnterpriseMission are:-

    'ActualEnterprisePhase - A time period within which a set of Capabilities are deployed
    WholeLifeEnterprise - A WholeLifeEnterprise is a purposeful endeavor of any size involving people, organizations and supporting systems. It is made up of TemporalParts and StructuralParts

    EnterpriseMission - Mission captures at a high level what you will do to realize your vision.'

    Figure 9:164 defines:-

    1) WholeLifeEnterprise (endeavour) is a ActualEnterprisePhase (time period) - this is incorrect
    2) EnterpriseMission (what you do) is a ActualEnterprisePhase (time period) - this is incorrect
    3) The definition of ActualEnterprisePhase is not atomic - it includes Capabilities. Type definitions should be atomic, not depend on anything else (otherwise you're defining all or part of a triple and if the external element or relationship named changes the definition is invalid)
    4) The definition of WholeLifeEnterprise is similarly non-atomic - it should not include reference to any relationship e.g. temporal or structural for example.

  • Reported: UAF 1.2 — Sun, 7 Apr 2024 10:20 GMT
  • Updated: Mon, 8 Apr 2024 14:19 GMT

Appendix A. Traceability. Mapping Results Should Show Unmapped Elements - on UAF Side and on Target Side

  • Key: UAF13-123
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

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

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

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

  • Reported: UAF 1.2 — Thu, 4 Apr 2024 14:50 GMT
  • Updated: Thu, 4 Apr 2024 15:22 GMT

UAF Elements Missing from SysML Mapping in Table 4.1

  • Key: UAF13-122
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

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

  • Reported: UAF 1.2 — Thu, 4 Apr 2024 14:41 GMT
  • Updated: Thu, 4 Apr 2024 15:21 GMT

Figure 9:134 / 8:86 Undefined DMM Elements - Refine, Trace, Refine, Verifiy, Requirement. Requirement not a UAF Element?

  • Key: UAF13-121
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Within the document there appears to be no usable link or definition of Satisy [another implementation artefact] and no definition of a Requirement element or other relationships linked to Requirement (Trace, Verify, Refine).

    Figure 8:86 multiplicities don't look to be consistent - 0..1 on Trace but 1 on Satisfy. Trace looks to be wrong - think someone trying to describe Requirement traces to Requirement, UAFELement traces to UAFElement and UAFElement traces to Requirement but there is no identification of path and its ambigous or wrong.

    Why is Requirement not a UAF Element? If it's not why is it even in this specification? Again I suspect this is an implementation artefact - someone thinking of a SysML::Requirement (which is an implementation of the DMM)

  • Reported: UAF 1.2b1 — Thu, 4 Apr 2024 14:31 GMT
  • Updated: Thu, 4 Apr 2024 15:21 GMT

Figure 9:129 ArchitecturalDescription - Multiplicities Incorrect

  • Key: UAF13-120
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Inconsistent name wrt ISO 42010 and with its own definition - ArchitecturalDescription vs Architecture Description.

    The multiplicities aren't correct. For example we have on Architecture to ArchitecturalDescription we have * on both ends which means that an Architecture has no existance independently of its ArchitectureDescriptions (plural as there have to be many of them). Should be 0..* on ArchitecturalDescription. Similarly with View it ought to be 1..* View and 0..* Viewpoint (otherwise an ArchitecturalDescription is required to include multiple Viewpoints which doesn't allow for a central set of 'library' viewpoints in ISO 42010 terminology).

    The relationships with View, Viewpoint, Architecture need to be named.

    'expresses' looks like a role but cannot be. If it is a role it needs to qualify the target element e.g. 'describedArchitecture' not the relationship.

    Why does ArchitectureMetadata have a multiplicity of 1 on ArchitecturalDescription - is each piece of metadata unique to every ArchitecturalDescription?

    What is an ArchitecturalReference? This looks like a relationship. What then is the point of adding a role name to a relationship? Isn't this just 'UAFElement traces to ArchitecturalDescription?

  • Reported: UAF 1.2b1 — Thu, 4 Apr 2024 14:11 GMT
  • Updated: Thu, 4 Apr 2024 15:20 GMT

Standards Taxonomy Missing conformsTo Element?

  • Key: UAF13-119
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    On figure 8:79 Standards Taxonomy we appear to have something like UAFElement conformsTo Standard. It is unclear because 'conformsTo' appears to be a role (which is incorrect if so), the multiplicity should be 0..* not *.

    What provides the 'conformsTo' relationship required?

    Relationships on the diagram aren't named. The multiplicities aren't correct - they should never be * (1 is always permissible). 'ratifiedBy' role is naming a relationship - as the target element is Organization the role name ought to be 'ratifyingOrganization' i.e. characterising the target node.

    There appears to be no conformsTo UAF element. The relationship on the diagram isn't named. The other fly in the ointment is that someone has copied SysML for the Requirements diagram which does show a 'Satisfy' relationship. So 'Satisfy' vs 'conformsTo'? This is one of the problems in not separating implementation from the DMM (the DMM shouldn't simply repeat the names of SysML, UML etc elements since there's no reason that they represent the same thing and you need the ability to diconnect as this is supposed to be ADL agnostic.

    How is this view specification supposed to be implemented when relationships aren't labelled and there appear to be elements missing?

  • Reported: UAF 1.2b1 — Thu, 4 Apr 2024 13:50 GMT
  • Updated: Thu, 4 Apr 2024 15:19 GMT

Figure 8:92, 8:93, 8:94 Do Not define the UAF Triples Needed to Address the Concerns Framed by the View Specifications::Other::BPMN View Spec

  • Key: UAF13-118
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The concerns identified are - 'Concerns: captures activity-based behavior and flows.'

    Figure 8:92 only defines a class hierarchy mapping UAF elements to BPMN elements. Ignoring that this is ADL-specific and shouldn't be in the DMM, this doesn't deine how process flows, activities are described and linked together. If such a viewpoint is felt necessary the UAF elements (not the BPMN elements) should show the triples that are permitted to be used in a conforming view.

    As defined this, the NIEM etc view specifications are a) not defined and b) impossible to implement in a non-UML ADL.

  • Reported: UAF 1.2b1 — Thu, 4 Apr 2024 13:35 GMT
  • Updated: Thu, 4 Apr 2024 15:19 GMT

BPMN and Other ADLs Should Not be in the Agnostic DMM - Should be in Either UAFML or a Similar ADL-Specific Specification

  • Key: UAF13-117
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Within 8.1.15 there are a number of ADL-Specific View Specifications. The DMM is supposed to be (but isn't) ADL-agnostic. It is impossible for any non-UML implementer to use or implement this content. Given that ADL-specific implementation is elsewhere e.g. the UAFML for UML,SysML then if there is a need to define this should be in a separate document and not the DMM.

  • Reported: UAF 1.2b1 — Thu, 4 Apr 2024 13:29 GMT
  • Updated: Thu, 4 Apr 2024 15:18 GMT

Figure 8:2 Architecture Views Does Not Conform to ISO/IEC/IEEE 42010 - Multiplicities, Naming, Direction [repeat - Tracker Now Using Correct OMG Identifiers]

  • Key: UAF13-116
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The use of a '*' multiplicity is incorrect - should be 1 or more Concerns. Similarly an ArchitecturalDescription (name error - should be ArchitectureDescription) should be composed of 1 or more Architecture Views (not *). A Viewpoint may frame only 1 Concern (not *)

    The use of a direction indicator is undefined and looks to be incorrect. In the direction from View to Viewpoint what is the relationship? In ISO 42010 there is a 'governs' relationship.

    The use solely of role names is incorrect - roles only label the target (source) node - they do not define a relationship. How is anyone supposed to implement a set or relationships where the relationships are not labelled? Figure 8:2 should use the relationship names defined in 42010 i.e. standardise.

    Using a role name that simply repeats the name of the source / target element is pointless - it adds no information whatsoever. The other problem with solely using role names is that if the label is offset it isn't clear whether it is a role or a relationship name and therefore whether it applies to the node or relationship.

  • Reported: UAF 1.2b1 — Thu, 4 Apr 2024 13:23 GMT
  • Updated: Thu, 4 Apr 2024 15:18 GMT

Consistency - Overlapping Concerns

  • Key: UAF13-115
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The statement - 'Due to the complexity of managing the multiple viewpoints with overlapping concerns and metamodels' ... needs to be clarified. Concerns never overlap - viewpoints may share concerns. I think what is being described is that donor AFs may have shared concerns - if so the sentence needs to be qualified because within a UAF you woudn't expect shared concerns because it is then poor viewpoint design and leads to inconsistency if the user can't easily select the same viewpoint to use (too much overlap).

    It's all the more confusing because Fig-8:2 Architecture Views states that a zero or more Concerns are (framed?) by a single Viewpoint so it's not even possible for viewpoints to share a concern.

  • Reported: UAF 1.2b1 — Thu, 4 Apr 2024 13:06 GMT
  • Updated: Thu, 4 Apr 2024 15:15 GMT

The UAFML is a UML Profile Not Itself a Modelling Language - Only the One Individual Use

  • Key: UAF13-114
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The change of name from the UAFP to the UAFML is technically incorrect. The UML or SysML are modelling languages because they can be used to model many real world things and relationships - the UAFML is fixed and it only represents a particular UML (and SysML) representation of the UAF DMM. It is a UML profile as stated in the text - 'It was created by mapping the UAF concepts and relationships to corresponding stereotypes in the UAFML Profile.' So now we have a UAFML profile (aka UAFPP ...)

    There is and can only ever one example/individual use of the UAFML. It cannot be used for any other purpose. It is not, therefore, a modelling language and defining it as such does a disservice to the UML et al.

  • Reported: UAF 1.2b1 — Thu, 4 Apr 2024 12:56 GMT
  • Updated: Thu, 4 Apr 2024 15:15 GMT

Centre Justification of Text

  • Key: UAF13-113
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Centre- rather than left- or fully-justified text

  • Reported: UAF 1.2b1 — Thu, 4 Apr 2024 12:50 GMT
  • Updated: Thu, 4 Apr 2024 15:14 GMT

Structure of References Section is Incorrect wrt Normative Docs. It also Needs to Identify Which Normative Documents Apply to What Parts of the UAF

  • Key: UAF13-112
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    3.1 lists Normative References, 3.1.1 lists normative OMG references. Non-OMG normative references should still be part of 3.1 and hence should be 3.1.2 not 3.2

    There is also a problem in the wholesale application of normative references to any part of the UAF. The DMM is supposed to be implementation-agnostic and therefore ADL references should not be normative for that. Similarly the only place where MODEM and DODAF etc are referenced are in the Traceability document (perhaps the UAFML?) so they are not normative for the DMM itself - particularly as there are elements in the DMM that are not in the MODEM, or DODAF or MODAF [this is also a problem within the Traceability document - it isn't complete].

    It would make sense to qualify the scope of the normative references by splitting into sub-sections e.g. general (common to all), DMM, UAFML, Traceability - if you're going to place all of the references in the one place. Alternatively add a References section to each sub-document and only state the normative references that apply to the document being read.

  • Reported: UAF 1.2b1 — Thu, 4 Apr 2024 12:45 GMT
  • Updated: Thu, 4 Apr 2024 15:13 GMT

Many Normative References Are Not Sources of Requirements Against Which Conformance Assessed and Hence Not Normative

  • Key: UAF13-111
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The statement is made 'The following normative documents contain provisions which, through reference in this text, constitute provisions of this specification.'

    This isn't true.

    UML profile for BPMN isn't normative in the DMM - it might be in the UAFML which defines a UML profile for the UAF but ADLs such as the UML, SysML, BPMN, IEPPV, BMM cannot be normative for the DMM which is supposed to apply to non-UML implementations. The UML spec is only informative for the DMM in as much as it conceivably (impossible in practice) might provide advice on how to read and interpret the notation used.

    Any wiki, for example the IDEAS one, cannot be normative. For a start there is no defined baseline date or issue let alone the fact that it doesn't state any requirements. At best this particular one is an informative reference.

  • Reported: UAF 1.2b1 — Thu, 4 Apr 2024 12:35 GMT
  • Updated: Thu, 4 Apr 2024 15:13 GMT

Issue Tracker Using Incorrect OMG Identifier? dtc/21-12-06 Required for Ticket But formal/22-07-02 on Front Cover of DMM Specification

  • Key: UAF13-110
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The OMG identifier on the front cover is formal/22-07-03 which turns out to be a SysML specification according to the issue tracker.

    However using the URL https://www.omg.org/cgi-bin/doc?formal/22-07-03 seems to want to return the UAF specification.

    If the OMG identifier for UAF 1.2 DMM is formal/22-07-03 then section 1 and Table 1-1 contain the wrong OMG identifiers (dtc/.... rather than formal/...)

  • Reported: UAF 1.2b1 — Thu, 4 Apr 2024 12:26 GMT
  • Updated: Thu, 4 Apr 2024 15:13 GMT

Alignment of Terminology to 42010, Relationships Not Labelled

  • Key: UAF13-109
  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    42010 uses Architecture Description whereas in UAF we have what seems to be the same concept but is 'ArchitecturalDescription'.

    The model in Figure 3.21 is missing relationship names between ArchitecturalDescription and View, ArchitecturalDescription and Architecture, ArchitecturalDescription and Viewpoint. These should in accordance with 42010 be 'has part, or is composed of', 'expresses' and 'has part or is composed of'.

    It should be noted that architecture descriptions using the UAF do not include architecture viewpoints - the viewpoints used are separate. In old 42010 terminology the UAF uses what is called 'library' viewpoints to save having to include in each and every AD. The relationship is something like 'references' or a form of trace.

    It is poor practice not to label relationships and repeating the target stereotype name as a role name on a connector adds no information.

    The figure also misses the association with ArchitectureFramework that is mentioned in Associations.

    The architectureFramework association doesn't, as stated, indicate the type of architecture framework - it identifies the particular architecture framework.

  • Reported: UAF 1.2 — Mon, 18 Mar 2024 11:22 GMT
  • Updated: Thu, 4 Apr 2024 15:06 GMT

Stereotype for ResourceInteractionScenario is missing

  • Key: UAF13-108
  • Status: open  
  • Source: Adocus ( Thomas Wiman)
  • Summary:

    There is no stereotype defined for ResourceInteractionScenario and the other variants of InteractionScenarios (OperationalInteractionScenario and OperationalInteractionScenario).

    I expected stereotypes for these concepts in the same way that there are stereotypes defined for the different varieties of StateDescriptions.

  • Reported: UAF 1.2 — Mon, 4 Mar 2024 07:55 GMT
  • Updated: Mon, 4 Mar 2024 18:02 GMT

ResourceInteractionScenario in wrong chapter in the domain metamodel specification

  • Key: UAF13-107
  • Status: open  
  • Source: Adocus ( Thomas Wiman)
  • Summary:

    ResourceInteractionScenario is defined within chapter Domain MetaModel::Personnel::Sequences in the specification
    The correct chapter shall be Domain MetaModel::Resources::Sequences.

  • Reported: UAF 1.2 — Mon, 4 Mar 2024 07:37 GMT
  • Updated: Mon, 4 Mar 2024 18:02 GMT

Signals should be ExchangeItems

  • Key: UAF13-106
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

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

  • Reported: UAF 1.2 — Sat, 10 Feb 2024 16:43 GMT
  • Updated: Thu, 15 Feb 2024 19:38 GMT

ServiceExchangeItem missing things

  • Key: UAF13-105
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    if one looks at the other *ExchangeItem descriptions...

    there is a *Parameter that has a type as an *ExchangeItem which is missing.. (it is in the description of the ServiceParameter)...

    also, it is missing the derived relationships between ServiceExchangeItem and ServiceFunction

  • Reported: UAF 1.2 — Sat, 10 Feb 2024 13:53 GMT
  • Updated: Thu, 15 Feb 2024 19:37 GMT

missing definition of Cost

  • Key: UAF13-104
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    missing definition of Cost for BillingItem

  • Reported: UAF 1.2 — Fri, 9 Feb 2024 21:07 GMT
  • Updated: Fri, 9 Feb 2024 21:37 GMT

ClassificationAttributes all Strings are missing multiplicities

  • Key: UAF13-103
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    ClassificationAttributes all Strings are missing multiplicities

  • Reported: UAF 1.2 — Fri, 9 Feb 2024 20:41 GMT
  • Updated: Fri, 9 Feb 2024 21:36 GMT

BillingItem wrong description

  • Key: UAF13-102
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    think this is wrong description for BillingItem

    Properties indicating the assurance of a piece of information

  • Reported: UAF 1.2 — Fri, 9 Feb 2024 20:27 GMT
  • Updated: Fri, 9 Feb 2024 21:36 GMT

should have multiplicity of [0]

  • Key: UAF13-101
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    endDate : ISO8601DateTime[0..1]
    End time for this ActualProjectMilestone

    should have multiplicity of [0]

  • Reported: UAF 1.2 — Fri, 9 Feb 2024 16:49 GMT
  • Updated: Fri, 9 Feb 2024 21:35 GMT

EvokedBy, ambigous description

  • Key: UAF13-85
  • Status: open  
  • Source: Akademiska sjukhuset ( Hans Natvig)
  • Summary:

    The description says "A dependency relationship denoting that a Risk is drawn out by an Opportunity." I have tried three different online translators that presents different meaning of "is drawn out by". Can the description be made more crisp and less ambigous for a non-native English speaking audience?

  • Reported: UAF 1.2 — Wed, 21 Sep 2022 13:32 GMT
  • Updated: Thu, 7 Dec 2023 16:58 GMT

DataElement is mentioned

  • Key: UAF13-86
  • Status: open  
  • Source: Akademiska sjukhuset ( Hans Natvig)
  • Summary:

    DataElement is obsolete and should change name to ResourceInformation.

  • Reported: UAF 1.2 — Wed, 21 Sep 2022 13:36 GMT
  • Updated: Thu, 7 Dec 2023 16:53 GMT

Architecture Management Sequences

  • Key: UAF13-87
  • Status: open  
  • Source: Federal Aviation Administration ( Shubin Yu)
  • Summary:

    The Domain Metamodel Elements (Section 9.1.1) included Architecture Management::Sequences elements, but the Architecture Management::Sequences diagrams were not included in Domain Metamodel Diagrams (Section 8.1.1) and Figure 7:1- UAF Grid.

  • Reported: UAF 1.2 — Thu, 13 Oct 2022 18:19 GMT
  • Updated: Thu, 7 Dec 2023 16:48 GMT

Incosistent terminology between profile and metamodel

  • Key: UAF13-91
  • Status: open  
  • Source: Adocus ( Thomas Wiman)
  • Summary:

    The abstract metaclass "Process" in the UAF metamodel is represented by the abstract stereotype "Activity" in the UAF Profile.
    This is confusing, The "Activity" stereotype should be renamed to "Process" to achieve consistency.

  • Reported: UAF 1.2 — Wed, 4 Jan 2023 08:28 GMT
  • Updated: Thu, 7 Dec 2023 16:44 GMT

Non-Security Risks

  • Key: UAF13-99
  • Status: open  
  • Source: RTX ( Mr. Sam Biller)
  • Summary:

    The EA Guide and the formal UAF documents suggest that UAF can be used to capture non-security risks at various levels of abstraction of the AD. The view specifications and UAFML limit the mitigation of a risk to a security control. It appears that an operational or resource mitigation should be elements that are able to mitigate a risk. The current metamodel only allows risks to affect those elements. Some rework in this area would improve the ability to capture non-security risks for ADs. Please see attached pdf for additional information.

  • Reported: UAF 1.2 — Wed, 8 Nov 2023 21:44 GMT
  • Updated: Sat, 2 Dec 2023 15:11 GMT
  • Attachments:

Information elements require better definition of relationships

  • Key: UAF13-97
  • Status: open   Implementation work Blocked
  • Source: Boeing ( Ms. Sharon Fitzsimmons)
  • Summary:

    Current implementation of information elements (both Operational and Resource) does not allow for decomposition, which would allow for multiple layers of fidelity to be represented in a model. Most information elements in a real system are "decomposable" in the sense that they can be represented by parts (in the case of a document, multiple data elements may be represented in one Operational element; in the case of a Resource information element, headers and multiple payloads may be represented within a higher level "information" element. The data model is particularly important within the EA reprsenetation of a system.
    Generalization is also needed within the information elements; flow properties on intefaces should accept elements of a less generalized implementation.

  • Reported: UAF 1.2 — Mon, 25 Sep 2023 10:26 GMT
  • Updated: Sat, 2 Dec 2023 15:08 GMT

Standards need to be decomposable

  • Key: UAF13-96
  • Status: open   Implementation work Blocked
  • Source: Boeing ( Ms. Sharon Fitzsimmons)
  • Summary:

    View specification for <<Standards>> elements do not allow for directed composition into other <<Standards>>. Specification for <<Standards>> elements do not specify a part property.
    This is needed because many ConformsTo relationships conform to only a specific part of a standard, rather than the entire standard. Traceability is enhanced by allowing for a UAF Element to ConformTo a standard at a lower level than the parent.

  • Reported: UAF 1.2 — Mon, 25 Sep 2023 10:21 GMT
  • Updated: Sat, 2 Dec 2023 14:44 GMT

Security Control should be a kind of Capability not a kind of Requirement

  • Key: UAF13-88
  • Status: open  
  • Source: Auxilium Technology Group ( Mr. John C. Butler)
  • Summary:

    The UAF specification defines Security Control as a kind of SysML Requirement. However, the specification also references NIST SP 800-53 in the definition of Security Control. NIST SP 800-53 clearly separates Security Controls from Requirement. E.g., in section 2.1 Requirements and Controls of NIST SP 800-53r5 it says "...It is important to understand the relationship between requirements and controls." It goes on to say "...the term requirement is generally used to refer to information security and privacy obligations imposed on organizations." It defines controls as "...descriptions of the safeguards and protection capabilities appropriate
    for achieving the particular security and privacy objectives of the organization...". In other words, Security Controls are a kind of capability.

  • Reported: UAF 1.2 — Wed, 19 Oct 2022 15:20 GMT
  • Updated: Sat, 2 Dec 2023 14:42 GMT

Operational Performer not linked to the Operational Performers in the model

  • Key: UAF13-92
  • Status: open  
  • Source: LinQuest Corporation ( Lawrence McCaskill)
  • Summary:

    Operational Performer is what does an activity in your model: Person, Organization, Service, and only if-and-only-if fully automated - a System. There's no linkage in UAF between these elements, and will thus cause duplication and/or configuration item bloat when you assert that Operational Performer named CAOC/CAOC Director sends ATO to Wing/Squadron/Mission Planner, when CAOC, Wing, Squadron are all Organization (types), and CAOC Director and Mission Planner are Person (Roles).

  • Reported: UAF 1.2 — Tue, 28 Mar 2023 21:07 GMT
  • Updated: Sat, 2 Dec 2023 14:33 GMT

Personnel::States example error

  • Key: UAF13-100
  • Status: open  
  • Source: RTX ( Mr. Sam Biller)
  • Summary:

    Within UAF Appendix B - Sample Problem, v1.2, Figure 9-8: Personnel States for SAR Rescue Team represents a number of states with multiple do actions in a list. This may be a tool limitation, but State Machines in Cameo EA and Rhapsody are limited to one do action per state.

  • Reported: UAF 1.2 — Tue, 21 Nov 2023 17:54 GMT
  • Updated: Tue, 21 Nov 2023 17:54 GMT

List of deprecated elements

  • Key: UAF13-98
  • Status: open  
  • Source: Boeing ( Ms. Sharon Fitzsimmons)
  • Summary:

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

  • Reported: UAF 1.2 — Tue, 7 Nov 2023 21:23 GMT
  • Updated: Tue, 7 Nov 2023 21:23 GMT

Incorrect definition for SubOrganization

  • Key: UAF13-95
  • Status: open  
  • Source: IBM ( Hans Kooi)
  • Summary:

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

  • Reported: UAF 1.2 — Tue, 23 May 2023 14:23 GMT
  • Updated: Thu, 25 May 2023 19:21 GMT

incorrect acronym definition

  • Key: UAF13-94
  • Status: open  
  • Source: LM Space ( Samuel Irizarry III)
  • Summary:

    Stated: "DoD's doctrine, organization, training material, leadership & education, personnel, and facilities (DOTMLPF)"

    Error: "training material"

    Corrective Action: Entire acronym, properly stated should read: DOTmLPF-P: Doctrine, Organization, Training, materiel, Leadership and Education, Personnel, Facilities and Policy.

    Definitive Source: JCIDS Manual, 31 August 2018

    Applicable Proponent: J7/JIB, on behalf of the Joint Staff Director for Joint Force Development (DJ-7)

  • Reported: UAF 1.2 — Fri, 14 Apr 2023 16:47 GMT
  • Updated: Fri, 14 Apr 2023 16:57 GMT

There is a View Description for Ar-Tr , but that square of the Grid is blank

  • Key: UAF13-89
  • Status: open  
  • Source: Air Force Institute of Technology ( Steve Glazewski)
  • Summary:

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

  • Reported: UAF 1.2 — Thu, 20 Oct 2022 19:28 GMT
  • Updated: Wed, 26 Oct 2022 15:55 GMT