Unified Architecture Framework Avatar
  1. OMG Specification

Unified Architecture Framework — All Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
UAF11-12 conformsTo is missing UAF 1.0b1 UAF 1.1 Closed; No Change closed
UAF-52 Update headings of the appendix documents to same format and make DMM Normative UAF 1.0b1 UAF 1.0 Resolved closed
UAF-50 Minor modifications on UAF-37 to complete FTF UAF 1.0b1 UAF 1.0 Resolved closed
UAF-8 Capability Definition UAF 1.0b1 UAF 1.0 Resolved closed
UAF-6 three properties called criticiality UAF 1.0b1 UAF 1.0 Resolved closed
UAF-5 Confidentiality missing UAF 1.0b1 UAF 1.0 Duplicate or Merged closed
UAF-47 Class Library Definition UAF 1.0b1 UAF 1.0 Resolved closed
UAF-43 Missing Project Activities from the UAF 1.0 Specification UAF 1.0b1 UAF 1.0 Resolved closed
UAF-42 UAF is missing project activity views UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-20 ActualEnduringTask and ActualRisk are missing from the ActualPropertySet diagram UAF 1.0b1 UAF 1.0 Resolved closed
UAF-19 Operational Nodes and other legacies in the definitions of the views UAF 1.0b1 UAF 1.0 Resolved closed
UAF-37 Type of Security Control Element UAF 1.0b1 UAF 1.0 Resolved closed
UAF-18 Change "process" to "processes" or "transform" in view definitions UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-2 Operational Exchange/Resource Interaction for triggering Transitions in StateMachines UAF 1.0b1 UAF 1.0 Resolved closed
UAF-9 Scope UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-10 small errors in UAF XMI UAF 1.0b1 UAF 1.0 Resolved closed
UAF-4 use of same term. UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-38 The DMM model for Service taxonomy states secific where it should be specific. UAF 1.0b1 UAF 1.0 Resolved closed
UAF-15 Architecture is not needed in the diagram for Exhibits UAF 1.0b1 UAF 1.0 Resolved closed
UAF-14 Implements should be removed from Enduring Task diagram UAF 1.0b1 UAF 1.0 Resolved closed
UAF-12 Taxonomy as stereotypes rather than a class library UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-11 What is a “Person”? UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-36 definition for element Risk includes Information security risk definition. UAF 1.0b1 UAF 1.0 Resolved closed
UAF-7 Multiple broken links in Appendix C section 2.1.1 UAF 1.0b1 UAF 1.0 Resolved closed
UAF-3 Resources Connectivity diagram is missing activity diagram elements UAF 1.0b1 UAF 1.0 Closed; No Change closed
UAF-1 SysML Version UAF 1.0b1 UAF 1.0 Resolved closed

Issues Descriptions

conformsTo is missing

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

    It seems that the stereotype conformsTo is adopted from UPDM since it is still present in many of the diagrams. However, the stereotype (an extesion of a depedency?) is never defined.

  • Reported: UAF 1.0b1 — Tue, 3 Oct 2017 08:13 GMT
  • Disposition: Closed; No Change — UAF 1.1
  • Disposition Summary:

    ConfromsTo is not a stereotype; it is a tag

    Conforms to is a property on the UAF element that is used to connect it to Standard element. It was never a stereotype. Please see Figure 7.209 - UAFElement in the UAF specification.

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

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

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

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

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

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

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

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

Minor modifications on UAF-37 to complete FTF


Capability Definition

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

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

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

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

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

    Capability Definition

    modify Capability definition

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

three properties called criticiality

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

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

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

    three properties called criticiality

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

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

Confidentiality missing

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

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

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

    Duplicates existing Issue

    Duplicates existing Issue

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

Class Library Definition

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

    Class Library Definition needs to be updated from

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

    to

    “A library of Measurements.”

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

    Class Library Definition needs to be updated

    Class Library Definition needs to be updated from

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

    to

    “A library of Measurements.”

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

Missing Project Activities from the UAF 1.0 Specification


UAF is missing project activity views

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

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

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

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

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

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

ActualEnduringTask and ActualRisk are missing from the ActualPropertySet diagram

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

    ActualEnduringTask and ActualRisk are missing from the ActualPropertySet diagram.

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

    ActualEnduringTask and ActualRisk are missing from the ActualPropertySet diagram

    need to add ActualEnduringTask and ActualRisk to ActualPropertySet

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

Operational Nodes and other legacies in the definitions of the views

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

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

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

    Minor modifications to descriptions and some diagrams

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

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

Type of Security Control Element


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

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

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

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

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

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

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

Operational Exchange/Resource Interaction for triggering Transitions in StateMachines


Scope

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

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

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

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

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

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

    Scope

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

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

small errors in UAF XMI

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

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

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

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

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

    small errors in UAF XMI

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

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

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

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

use of same term.

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

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

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

    use of same term.

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

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

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

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

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

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

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

    Cannot find the error in the documentation or model]

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

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

Architecture is not needed in the diagram for Exhibits


Implements should be removed from Enduring Task diagram

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

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

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

    Implements removed from Enduring Task diagram

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

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

Taxonomy as stereotypes rather than a class library

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

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

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

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

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

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

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

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

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

    Taxonomy as stereotypes rather than a class library

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

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

What is a “Person”?

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

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

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

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

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

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

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

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

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

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

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

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

    What is a “Person”?

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

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

definition for element Risk includes Information security risk definition.

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

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

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

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

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

    definition for element Risk includes Information security risk definition.

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

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

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

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

Multiple broken links in Appendix C section 2.1.1


Resources Connectivity diagram is missing activity diagram elements

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

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

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

    Resources Connectivity diagram is missing activity diagram elements

    This was fixed in a previous version of the specification

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

SysML Version

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

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

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

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

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

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

    SysML Version

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

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

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

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

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