Unified Architecture Framework Avatar
  1. OMG Specification

Unified Architecture Framework — All Issues

  • Acronym: UAF
  • Issues Count: 13
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

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

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

    Actual Risk as well as Security Measurements needs to captured in Security Parameters.
    Currently Actual Risk is captured as a part of Security Constraints and Security Measurements are are captured as part of Security Taxonomy. It is not following the UAF pattern.

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

    Risk removed from SecurityConstraints view specification

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

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

Stereotypes for flowProperties

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

    Flow properties needs to be stereotyped in the profile to better integrate interfaces to exchanges and signals. Stereotypes are needed for Operational, Service, and Resource Interfaces

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

    Out of scope for this release

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

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

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: Wed, 15 Dec 2021 21:27 GMT

Required Environment needs to be individual as opposed to type

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

    Required environment on the LocationHolder is currently linked to Environment which is a type. It does not make sense to link it to a type. Required environment needs to be linked to ActualEnvironment.

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

    Required Environment changed to Actual Environment

    Required Environment changed to Actual Environment

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

Security Property name change

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

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

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

    Information Role and Data Role elements introduced to substitute Security Property

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

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

Constraint uses wrong name

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

    Constraints OwnsProcess.* should be renamed to OwnsRiskInContext.*

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

    Duplicates UAF11-108

    Duplicates UAF11-108

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

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

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

    ResponsibleFor relationship from Actual Responsible Resource to Actual Project Milestone is captured in Figure 222 - Strategic Roadmap: Deployment. It is required to build Strategic Roadmap: Deployment view. However, ResponsibleFor relationship from Actual Responsible Resource to Actual Project Milestone is not depicted in the following figures: Figure 113 - ResponsibleFor and Figure 186 - ActualProjectMilestone.

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

    Duplicates UAF11-40

    Duplicates UAF11-40

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

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

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

    Unified Architecture Framework (UAF), The Domain Metamodel document needs to be primary UAF specification. Unified Architecture Framework Profile (UAFP) document needs to be Appendix for it.

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

    Modify document structure

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

    Add diagrams explaining eacch metamodel element to the DMM documentation.

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

    MM doc first followed by profile.

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

Enteprise Phase should not be a subtype of capable element

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

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

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

    Enterprise Phase is no longer a Capable Element

    Generalisation from EnteprisePhase to CapableElement removed

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

Ovierview picture (UAF Grid Overview)

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

    The Ovierview picture (UAF Grid Overview) indocated that two view specifications (Op-Tr and Sc-Tr) have been removed between the beta 1 and beta 2 issues. However, in the actual specification both views are still present.

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

    This issue is raised against UAF beta 2

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

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

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

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

    Actual Risk as well as Security Measurements needs to captured in Security Parameters.
    Currently Actual Risk is captured as a part of Security Constraints and Security Measurements are are captured as part of Security Taxonomy. It is not following the UAF pattern.

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

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

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

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

Definition of FunctionAction is too tight

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

    Is it necessary for the definition of FunctionAction (and other actions as well) to extend CallBehaviorAction. What about other actions such as accept event action and wait time action? Could the stereotypes in UAFP which today extend the call behaviour action, be changed to extend the more general action instead?

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

    No need to over-stereotype elements

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

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

Stereotypes for flowProperties

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

    Flow properties needs to be stereotyped in the profile to better integrate interfaces to exchanges and signals. Stereotypes are needed for Operational, Service, and Resource Interfaces

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

    Deferred to the future versions of UAF

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

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