Unified Architecture Framework Avatar
  1. OMG Specification

Unified Architecture Framework — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
UAF13-88 Security Control should be a kind of Capability not a kind of Requirement UAF 1.2 open
UAF13-82 PhaseableElement - Enterprise Vision & Enterprise Goal should not be phaseable UAF 1.2 open
UAF13-78 BORO Compliance - ActivityPerformableUnderCondition UAF 1.2 open
UAF13-84 Achiever - production versus transformation UAF 1.2 open
UAF13-76 BORO Compliance - Desirer UAF 1.2 open
UAF13-95 Incorrect definition for SubOrganization UAF 1.2 open
UAF13-94 incorrect acronym definition UAF 1.2 open
UAF13-93 Spelling errors UAF 1.2 open
UAF13-92 Operational Performer not linked to the Operational Performers in the model UAF 1.2 open
UAF13-91 Incosistent terminology between profile and metamodel UAF 1.2 open
UAF13-90 The description in Ar-Tr is misaligned with picture 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
UAF13-87 Architecture Management Sequences UAF 1.2 open
UAF13-86 DataElement is mentioned UAF 1.2 open
UAF13-85 EvokedBy, ambigous description UAF 1.2 open
UAF13-83 ConceptRole is missing in the DMN 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-77 Abstract Multiplicity Issue - IsCapableToPerform UAF 1.2 open
UAF13-21 UAF::*Constraint can’t be used with SysML::ConstraintBlocks UAF 1.2 open
UAF13-24 LocationHolder.physicalLocation and requiredEnvironment as properties of Assets 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-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-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-55 Mission and Mission Threads 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-23 Support UML::Property.defaultValue as part of UAF::MeasurableElement.actualMeasurementSet UAF 1.2 open
UAF13-40 UAFML should not redefine SysML method attribute of the Viewpoint Stereotype. UAF 1.2b1 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-25 UAFElement.conformsTo and ProtocolImplementation.implements alignment and reification with fUML UAF 1.2 open
UAF13-22 Alignment of UAF::*Method with IsCapableToPerform 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-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

Issues Descriptions

Security Control should be a kind of Capability not a kind of Requirement

  • Key: UAF13-88
  • Status: open  
  • Source: Auxilium Technology Group ( John 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: Tue, 26 Sep 2023 22:01 GMT

PhaseableElement - Enterprise Vision & Enterprise Goal should not be phaseable

  • Key: UAF13-82
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( 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: Tue, 26 Sep 2023 21:19 GMT

BORO Compliance - ActivityPerformableUnderCondition

  • Key: UAF13-78
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( 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: Tue, 26 Sep 2023 21:07 GMT

Achiever - production versus transformation

  • Key: UAF13-84
  • Status: open  
  • Source: MEGA International ( 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: Tue, 26 Sep 2023 20:39 GMT
  • Attachments:

BORO Compliance - Desirer

  • Key: UAF13-76
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( 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: Tue, 26 Sep 2023 20:25 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

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: Thu, 13 Apr 2023 15:32 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: Fri, 31 Mar 2023 18:25 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, 12 Jan 2023 20:45 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: Thu, 3 Nov 2022 17:36 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

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: Fri, 14 Oct 2022 15: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: Wed, 5 Oct 2022 15:08 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: Wed, 5 Oct 2022 15:08 GMT

ConceptRole is missing in the DMN

  • Key: UAF13-83
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( 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: Wed, 20 Jul 2022 13:39 GMT

Motivation - MotivatedBy - Wrong AssociationEndNames

  • Key: UAF13-81
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( 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: Fri, 8 Jul 2022 16:01 GMT

Abstract Multiplicity Issue - Implements

  • Key: UAF13-80
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( 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: Thu, 7 Jul 2022 15:27 GMT

Abstract Multiplicity Issue - PerformInContext

  • Key: UAF13-79
  • Status: open   Implementation work Blocked
  • Source: MEGA International ( 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: Thu, 7 Jul 2022 14:02 GMT

Abstract Multiplicity Issue - IsCapableToPerform

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

    Multiple conflicting [1.1] multiplicities on IsCapabletoPerform.

  • Reported: UAF 1.2 — Thu, 7 Jul 2022 12:53 GMT
  • Updated: Thu, 7 Jul 2022 12:53 GMT

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

  • Key: UAF13-21
  • Status: open  
  • Source: Department of Navy ( 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: Fri, 3 Jun 2022 13:34 GMT

LocationHolder.physicalLocation and requiredEnvironment as properties of Assets

  • Key: UAF13-24
  • Status: open  
  • Source: Department of Navy ( 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: Fri, 3 Jun 2022 13:31 GMT

Arch Mgmt Roadmaps View

  • Key: UAF13-68
  • Status: open  
  • Source: Aerospace Corporation ( 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: Thu, 2 Jun 2022 14:22 GMT
  • Attachments:

Arch Mgmt States View

  • Key: UAF13-67
  • Status: open  
  • Source: Aerospace Corporation ( 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: Thu, 2 Jun 2022 14:22 GMT
  • Attachments:

Arch Mgmt Processes View

  • Key: UAF13-66
  • Status: open  
  • Source: Aerospace Corporation ( 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: Thu, 2 Jun 2022 14:22 GMT
  • Attachments:

Architecture Management Taxonomy View

  • Key: UAF13-65
  • Status: open  
  • Source: Aerospace Corporation ( 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: Thu, 2 Jun 2022 14:21 GMT
  • Attachments:

Alignment with ISO 42010 concepts and terminology

  • Key: UAF13-74
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:48 GMT

Adopting ISO document structure, formatting and style

  • Key: UAF13-73
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:48 GMT

Swap Personnel and Resources rows in UAF grid

  • Key: UAF13-72
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:47 GMT

Strategic Viewpoint Designator (St --> Sg)

  • Key: UAF13-71
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:47 GMT

Structural and Behavioral Column Grouping in the Grid

  • Key: UAF13-70
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:46 GMT

Actualization Viewpoint and Views

  • Key: UAF13-69
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:42 GMT
  • Attachments:

Portfolio as Enduring Object

  • Key: UAF13-64
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:33 GMT
  • Attachments:

Architectural Description Referencing

  • Key: UAF13-63
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:33 GMT
  • Attachments:

Measurement Kinds in UAF

  • Key: UAF13-62
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:32 GMT
  • Attachments:

Measurements Typical and Actual

  • Key: UAF13-61
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:31 GMT
  • Attachments:

Use Cases

  • Key: UAF13-60
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:30 GMT

EA Guide Updates

  • Key: UAF13-59
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:30 GMT

Sample Model Updates

  • Key: UAF13-58
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:29 GMT

NATO Framework Guide for UAF

  • Key: UAF13-57
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:29 GMT

Location Types

  • Key: UAF13-56
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:28 GMT
  • Attachments:

Mission and Mission Threads

  • Key: UAF13-55
  • Status: open  
  • Source: Aerospace Corporation ( 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.

  • Reported: UAF 1.2 — Wed, 1 Jun 2022 13:27 GMT
  • Updated: Wed, 1 Jun 2022 13:27 GMT
  • Attachments:

Operational Nodes and Needlines

  • Key: UAF13-54
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:27 GMT
  • Attachments:

Trust Lines between Operational Performers

  • Key: UAF13-53
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:25 GMT
  • Attachments:

Operational Scenarios as Agents

  • Key: UAF13-52
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:24 GMT
  • Attachments:

Architecture is not an Agent nor a Performer

  • Key: UAF13-51
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:23 GMT
  • Attachments:

Capability has no agency, therefore cannot desire a state

  • Key: UAF13-50
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:22 GMT
  • Attachments:

Service as Desirer

  • Key: UAF13-49
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:21 GMT
  • Attachments:

Service Mitigation to perform Security Process and satisfy Security Control

  • Key: UAF13-48
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:19 GMT
  • Attachments:

Service implementing an Operational Agent

  • Key: UAF13-47
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:17 GMT
  • Attachments:

Resource Performer implementing a Service

  • Key: UAF13-46
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:16 GMT
  • Attachments:

Service Performer as special case of Service

  • Key: UAF13-45
  • Status: open  
  • Source: Aerospace Corporation ( 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: Wed, 1 Jun 2022 13:15 GMT
  • Attachments:

Change <> relationship source to <> element

  • Key: UAF13-44
  • Status: open  
  • Source: MITRE ( 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: Tue, 31 May 2022 14:23 GMT

Enable a Requirement Relationship between AbstractReqirement and Capability

  • Key: UAF13-43
  • Status: open  
  • Source: MITRE ( 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: Tue, 31 May 2022 14:23 GMT

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

  • Key: UAF13-23
  • Status: open  
  • Source: Department of Navy ( 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: Fri, 22 Apr 2022 14:01 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: Thu, 21 Apr 2022 16:10 GMT

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

  • Key: UAF13-17
  • Status: open  
  • Source: Department of Navy ( 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: Fri, 8 Apr 2022 13:41 GMT

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

  • Key: UAF13-16
  • Status: open  
  • Source: Department of Navy ( 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: Fri, 8 Apr 2022 13:16 GMT

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

  • Key: UAF13-25
  • Status: open  
  • Source: Department of Navy ( 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: Thu, 17 Mar 2022 20:35 GMT

Alignment of UAF::*Method with IsCapableToPerform

  • Key: UAF13-22
  • Status: open  
  • Source: Department of Navy ( 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: Thu, 17 Mar 2022 20:34 GMT

Refine the DMM Impliments implementation in ML

  • Key: UAF13-20
  • Status: open  
  • Source: Department of Navy ( 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: Wed, 16 Mar 2022 16:37 GMT

measurementSet tag derivation from actualMeasurementSets

  • Key: UAF13-19
  • Status: open  
  • Source: Department of Navy ( 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: Tue, 15 Mar 2022 18:34 GMT

Interoperability with UML and SysML elements

  • Key: UAF13-15
  • Status: open  
  • Source: Department of Navy ( 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: Fri, 14 Jan 2022 21: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 ( 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: Fri, 14 Jan 2022 21:16 GMT