Unified Architecture Framework Avatar
  1. OMG Specification

Unified Architecture Framework — Open Issues

  • Acronym: UAF
  • Issues Count: 17
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
UAF13-292 Fig 3.38 UAF 1.2b1 open
UAF13-301 missing Element CourseOfAction UAF 1.2b1 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-40 UAFML should not redefine SysML method attribute of the Viewpoint Stereotype. UAF 1.2b1 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

Issues Descriptions

Fig 3.38


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

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

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

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