Unified Profile for DoDAF and MODAF Avatar
  1. OMG Specification

Unified Profile for DoDAF and MODAF — Open Issues

  • Acronym: UPDM
  • Issues Count: 65
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
UPDMRTF-43 Figure number is incorrect in Subpart 1. UPDM 2.1 open
UPDMRTF-45 Objection to scope of UPDM fro ISO UPDM 2.1 open
UPDMRTF-46 missing definition for NAF in glossary of terms UPDM 2.1 open
UPDMRTF-48 The scope of this standard focused too much on the use of DoD and MOD area. UPDM 2.1 open
UPDMRTF-52 modify reference to UML 2.3 to UML 2.4.1 UPDM 2.1 open
UPDMRTF-47 Notation on Diagram 2.1 not clear UPDM 2.1 open
UPDMRTF-53 The format of normative references don't meet ISO format UPDM 2.1 open
UPDMRTF-51 The last bullet point is broken. UPDM 2.1 open
UPDMRTF-49 The first sentence may invite misunderstand that “UPDM 2.1” and this standard are different. UPDM 2.1 open
UPDMRTF-50 Figure is a little grainy. UPDM 2.1 open
UPDMRTF-58 It is much to easy to rely on reference documents UPDM 2.1 open
UPDMRTF-56 Don’t separate the “Normative Reference” clause. UPDM 2.1 open
UPDMRTF-57 Confusing conformance/compliance statements re DoDAF 2.o2 UPDM 2.1 open
UPDMRTF-54 IS0, TC154 should be ISO/TC154. UPDM 2.1 open
UPDMRTF-55 Existing ISO standards should be mentioned. UPDM 2.1 open
UPDMRTF-61 odd reference to UPDM RFC UPDM 2.1 open
UPDMRTF-64 missing class definitions UPDM 2.1 open
UPDMRTF-60 Some of text should be merged into the scope Clause 1. UPDM 2.1 open
UPDMRTF-62 DMM is non-normative but appears to be nomative UPDM 2.1 open
UPDMRTF-59 DOTMLP should be DOTMLPF. UPDM 2.1 open
UPDMRTF-63 pacakge partitioning not clear UPDM 2.1 open
UPDMRTF-65 missing description for associations UPDM 2.1 open
UPDMRTF-66 unify representation style for inheritance UPDM 2.1 open
UPDMRTF-67 lacking clause and number heading UPDM 2.1 open
UPDMRTF-44 UPDM v2.1 is specific to DoD and MOD procedures. UPDM 2.1 open
UPDMRTF-4 Mapping to DM2 higher level elements: UPDM 2.1 open
UPDMRTF-3 Need for ServiceInterfaces to be represented as an instance to capture specific ServiceAttributes UPDM 2.1 open
UPDMRTF-68 explain the relevance of this standard to IT and SE in general UPDM 2.1 open
UPDMRTF-5 Use of superSubType, wholePart and WholePartType in DoDAF 2 UPDM 2.1 open
UPDMRTF-6 Desired Effect needs to be a strategic-level model able element UPDM 2.1 open
UPDMRTF-7 The Model library in the UPDM profile should be external to the UPDM profile UPDM 2.1 open
UPDMRTF-1 Specification lacks Hyperlinks for references to Model Element Names UPDM 2.1 open
UPDMRTF-12 PIM Logical Service Specification UPDM 2.1 open
UPDMRTF-10 Expand general activity modeling for all UPDM constructs to include representation by action, callBehaviorAction and UPDM 2.1 open
UPDMRTF-14 Implements Relationship between Exchange Elements UPDM 2.1 open
UPDMRTF-11 Simplify measurements in UPDM UPDM 2.1 open
UPDMRTF-18 System and PhysicalArchitecture are siblings not descendants UPDM 2.1 open
UPDMRTF-16 UPDM DoDAF lacks a concept for Service Orchestration UPDM 2.1 open
UPDMRTF-17 Integrate SysML Requirements and Constraints UPDM 2.1 open
UPDMRTF-13 Need of Logical and Physical Services UPDM 2.1 open
UPDMRTF-15 Future Increments of UPDM should not preclude using SBVR for Modeling Vocabularies and Rules UPDM 2.1 open
UPDMRTF-19 ProjectSequence is too Restrictive UPDM 2.1 open
UPDMRTF-20 The <> stereotype and its properties UPDM 2.1 open
UPDMRTF-21 MapsToCapability relationship is too Restrictive, and ActivityPartOfCapability is redundant UPDM 2.1 open
UPDMRTF-24 CV6, CV-7 and NSOV-3 UPDM 2.1 open
UPDMRTF-22 use of Generalization to implement Aliasing UPDM 2.1 open
UPDMRTF-23 Use of Actual vs. Type in PV-1 UPDM 2.1 open
UPDMRTF-25 Subject of a State Machine UPDM 2.1 open
UPDMRTF-30 There needs to be a distinction between Operational View IEs and Systems View Exchange elements UPDM 2.1 open
UPDMRTF-31 For UAFP. Include a Data and Information view (DIV) UPDM 2.1 open
UPDMRTF-29 Information flow instantiation UPDM 2.1 open
UPDMRTF-28 Introduce roles in SV-1 and allow them to relate back to OV-4 organizations that will provide them UPDM 2.1 open
UPDMRTF-26 Need of Composition between Enterprise Goals UPDM 2.1 open
UPDMRTF-27 Why is EnterprisePhase to EnterpriseVision a one to one relationship UPDM 2.1 open
UPDMRTF-32 Why are rules in OV-6a and SV-10a not parsed? UPDM 2.1 open
UPDMRTF-35 modify the term NodeRole so that is more applicable to a Peformer UPDM 2.1 open
UPDMRTF-33 Why does a user need to build an SOV-3? UPDM 2.1 open
UPDMRTF-34 Need to change target of desiredEffect from a state to a new element called effect UPDM 2.1 open
UPDMRTF-37 Profile and Tooling should enforce the Proper Specification of Capabilities UPDM 2.1 open
UPDMRTF-38 AV-2 Definitions need Authoritative Source property and Tooling to enforce its Use UPDM 2.1 open
UPDMRTF-39 UPDM Users want to model Test Contexts and Test Cases within UPDM UPDM 2.1 open
UPDMRTF-40 Figure 8.1 Presents InformationAssuranceProperties Twice UPDM 2.1 open
UPDMRTF-36 DoDAF elements need to be identified and added to the various diagrams that represent the views UPDM 2.1 open
UPDMRTF-42 Withdraw UDPM Spec UPDM 2.1 open
UPDMRTF-146 capability element should have a relation to sysml requirement type. UPDM 2.1.1 open

Issues Descriptions

Figure number is incorrect in Subpart 1.

  • Key: UPDMRTF-43
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Figure 2.1 page 4 should be Figure 1.1
    Figure 2.2 page 4 should be Figure 2.1
    Figure 2.3 page 5 should be Figure 2.2
    References to the original figure numbering in the text need to be modified
    Table on page 9-10 should have title
    Table 5.1 Glossary of Abbreviations and Acronyms
    Table on page 11-12 should have title
    Table 6.1 Additional Materials

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:15 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Objection to scope of UPDM fro ISO

  • Key: UPDMRTF-45
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    As stated in the clause 6.2, this standard intends to facilitate end user who want to communicate with DoD and MOD.
    If so, this standards need not to be an ISO or ISO/IEC standard.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:20 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

missing definition for NAF in glossary of terms

  • Key: UPDMRTF-46
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Add the definition for NAF in clause 5.

    Action:- Added NAF and its definition to the appropriate place in table 5.1

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:21 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

The scope of this standard focused too much on the use of DoD and MOD area.

  • Key: UPDMRTF-48
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Action:- We modified text in the scope section.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:25 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

modify reference to UML 2.3 to UML 2.4.1

  • Key: UPDMRTF-52
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    UML2.3 should be changed to UML 2.4.1unless there is inevitable reason, since UML2.4.1 has been standardized as IS.

    Response:- At the time the standard was published UML 2.3 was the current version of UML. A change to UML 2.4.1 would invalidate the references to UML in the XMI resulting in a major change to the standard. It is envisaged that a major release i.e. UPDM 3.0 aka UAF 1 would update the references to the latest versions of UML and SysML available.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:29 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Notation on Diagram 2.1 not clear

  • Key: UPDMRTF-47
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    What allows (arrows) in the diagram do mean? Are they support or consist of UPDM?

    Action:- New diagram created using UML notation to replace original

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:24 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT
  • Attachments:

The format of normative references don't meet ISO format

  • Key: UPDMRTF-53
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Designate references like as other OMG PAS documents
    See UML2.4.1

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:30 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

The last bullet point is broken.

  • Key: UPDMRTF-51
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Action:- Modified the bullet

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:28 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

The first sentence may invite misunderstand that “UPDM 2.1” and this standard are different.

  • Key: UPDMRTF-49
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The title should be mentioned like;
    Information technology - Object Management Group Unified Profile for DoDAF and MODAF (UPDM 2.1)

    Action:-Added (UPDM 2.1) to the end of the title on page 3

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:26 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Figure is a little grainy.


It is much to easy to rely on reference documents

  • Key: UPDMRTF-58
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    from section 4 delete the sentences
    No new terms and definitions have been required to create this International Standard. All terms should be available in the normative references or bibliographic citations for detailed explanation.
    And add the sentence

    Any additional terms created to implement UPDM have been defined within this standard.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:38 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Don’t separate the “Normative Reference” clause.

  • Key: UPDMRTF-56
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    GB remove title sections for 3.3 and 3.4
    Delete section 3.4 completely
    Add reference to
    DoD Architecture Framework 2.02 http://dodcio.defense.gov/Library/DoDArchitectureFramework.aspx

    References
    • ISO 8601:2004 Data elements and interchange formats- Information interchange-Representation of dates and times, IS0/TC154
    • ISO/IEC 19505-1 , Information technology — OMG Unified Modeling Language (OMG UML) Version 2.4.1 — Part 1: Infrastructure; pas/2011-08-05
    • ISO/IEC 19505-2 , Information technology — OMG Unified Modeling Language (OMG UML) Version 2.4.1 — Part 2: Superstructure; pas/2011-08-06
    • OMG Specification formal/ 2010-05-03, UML Infrastructure, v2.3
    • OMG Specification formal/ 2010-05-05, UML Superstructure, v2.3
    • OMG Specification formal/ 2005-09-01, XML Metadata Interchange (XMI), v2.1

    • OMG Specification formal/2006-05-01, Object Constraint Language, v2. 0
    • OMG Specification formal/2012-03-01, SoaML, v1.0
    • OMG Specification formal/2010-06-01, SysML, v1.2

    • The MOD Architectural Framework (MODAF) Version 1.2.002 (https://www.gov.uk/guidance/mod-architecture-framework)
    • The DoD Architecture Framework (DoDAF) Version 2.02 (http://dodcio.defense.gov/Library/DoDArchitectureFramework.aspx)

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:34 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Confusing conformance/compliance statements re DoDAF 2.o2

  • Key: UPDMRTF-57
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The clause 3.4 describes the DoDAF 2.02 Conformance. However, the “Compliance” is already described in clause 2. The structure is confusing.

    Delete the section entitled 3.4.1 DoDAF 2.02 Conformance
    Create section in section 2, 2.2 Compliance to DoDAF 2.02
    Add text
    UPDM 2.1 conforms with DoDAF 2.02

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:37 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

IS0, TC154 should be ISO/TC154.

  • Key: UPDMRTF-54
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    text should be

    ISO 8601:2004 Data elements and interchange formats - Information interchange - Representation of dates and times, IS0/TC154 (http://www.iso.org/iso/home/store/catalogue_ics/ catalogue_detail_ics.htm?ics1=01&ics2=140&ics3=30&csnumber=40874)

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:32 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Existing ISO standards should be mentioned.

  • Key: UPDMRTF-55
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Add these references to section 3

    ISO/IEC 19505-1: 2012(UML 2.4.1 Infrastructure), ISO/IEC 19505-2: 2012 (UML 2.4.1 Superstructure), ISO/IEC 19507:2012 (OCL )

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:33 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

odd reference to UPDM RFC

  • Key: UPDMRTF-61
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The “UPDM RFC” suddenly appears without a definition or a reference. It seems that this RFC is meaningless. This sentence is informative. It is obvious matter to follow the RFC.

    Remove the description which mentions the “RFC”. Or if the RFC is inevitable, it is necessary to reference to RFC or remove the RFC.

    Delete RFC from the paragraph
    This International Standard reuses a subset of UML 2 and provides additional extensions needed to address the requirements of developing UPDM. We have used those requirements as the basis for this International Standard.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:41 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

missing class definitions

  • Key: UPDMRTF-64
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    This clause describes the class library using class diagram. However, there is no class definition for each, that is, there is no attributes description and association description.

    UPDM Group response
    The OMG architecture board did not require this level of detail in the documentation so it was not added.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:02 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Some of text should be merged into the scope Clause 1.

  • Key: UPDMRTF-60
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Modified the scope and sections 6.2.1 and 6.2.2 replace the original sections with this text

    6.2.1 Intended Audience
    This specification will be of interest to end users, military, industrial and commercial, who expect to use this profile, and to tool vendors interested in developing tool support for the development of enterprise and system of systems architectures.
    Section 6.2.2 Organization of this specification
    DoDAF and MODAF are formally expressed as domain-specific meta-models known as the DoDAF Meta Model (DM2) and the MODAF Meta Model (M3) respectively, this provides the foundation for the UPDM domain metamodel and profile. There is also a set of viewpoints and views that address the concerns of a well-defined set of stakeholders. This specification organizes the presentation of the UPDM 2.1 abstract and concrete syntax around the meta-models, with effort made to establish a maximum set of common Core models and a minimum set of DoDAF DM2 or MODAF M3 specific models. Significant effort has also been made to continue to support the now over 50 viewpoints that can be derived from these meta-models as well as "user-defined views". This allows tool-vendors to specify views, based upon a common metamodel that are more applicable to industrial and commercial concerns than just military, it also ensures that the discussion is well-connected to the domain experts required to produce these views. (See Section 1.5 for a more detailed description.)"The rest of this document contains the technical content of this specification. As background for this specification, readers may wish to review the UML, OMG SysML, and SoaML specifications that complement this specification.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:39 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

DMM is non-normative but appears to be nomative

  • Key: UPDMRTF-62
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    This document refers to “DMM” which is defined as non-normative Annex A. However, it seems to be Normative. Besides, according to the text, it is necessary to refer to the colour legend. However, I couldn’t find the legend.

    Clarify this sentence. If those were Normative, move DMM to the body parts.

    Response,
    add colour coding legend and explanations.

    The DMM is intended to be informative and was used to develop an understanding of the foundational concepts from which the UPDM profile evolved. It remains useful for understanding the architectural concepts required to implement UPDM. It is expected that UML and SysML tool vendors who implement UPDM would implement this profile rather than the DMM; however, it is possible non-UML tool vendors may wish to implement UPDM in their by tool by following the DMM.
    In annex A delete the second paragraph starting “Note that the” and replace with the text and diagrams below.
    Note that the diagrams rely on color to aid the reader in understanding the model. Please refer to the legend below to understand the diagrams.
    The following is the legend of element colors used in the DMM and what they denote.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:43 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT
  • Attachments:

DOTMLP should be DOTMLPF.

  • Key: UPDMRTF-59
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Table 5.1 modify DOTMLP to DOTMLPF

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:39 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

pacakge partitioning not clear

  • Key: UPDMRTF-63
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    According to the explanation, the “Partitioning” is the package. However, I couldn’t find the packaged diagrams except for the “Aliases”. It seems that it is necessary to define UPDM using Package diagrams.

    Replace the Pertitioning section 7.3 with the following.
    Partitioning: The UPDM profile is organized as a number of hierarchical packages that are used to group elements, and to provide a namespace for those grouped elements. The top level structure of these packages can be seen in Figure 2.2.(Packages are represented in the diagram by a rectangle with a tab in the upper left hand corner).

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:45 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

missing description for associations

  • Key: UPDMRTF-65
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The UPDM classes are defined using class diagram and those descriptions. Some class diagrams specify association link. However, there is no description for association as text..

    UPDM Group response
    The OMG Architecture board did not require this level of detail in the documentation so it was not added.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:04 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

unify representation style for inheritance

  • Key: UPDMRTF-66
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    In case of UML, inheritance is described as “Generalization” in texts. However, in this document, inheritance is described as “Specializations”. It is confusing.

    Unify the representation style for the inheritance, that is, decide which representation is taken.

    UPDM Group response
    Although the relationship is called generalization in UML, the term is dependent upon the direction from which the relationship is being viewed. If taken from the perspective of the element which is the is focus of a specific diagram (which is the case in this specification), the term used is specialization.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:05 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

lacking clause and number heading

  • Key: UPDMRTF-67
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    There is no clause number & heading on the first paragraph right after “Subpart”. It is a hanging paragraph

    Action:-These subheadings are in the OMG template and from reviewing other PAS submissions it reveals that these documents have been submitted to ISO using the same format.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:08 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

UPDM v2.1 is specific to DoD and MOD procedures.

  • Key: UPDMRTF-44
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    "UAF" written in the explanatory report should be made an international standard.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:18 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Mapping to DM2 higher level elements:

  • Key: UPDMRTF-4
  • Legacy Issue Number: 17278
  • Status: open  
  • Source: Syntell AB ( Mr Lars-Olof Kihlstrom)
  • Summary:

    Currently UPDM does not map a numer of elements that exist in DM2, namely those above the Type level, for example CapabilityType since UML does not support elements at higher type levels. There is however a possibility of doing this by recognising that a set of capabilities (as an example) contains a given capability instance but capability categoreis are really a larger subset of available capabilities. This would make it possible by allowing the elements to contain a tagged value that indicates whether they are to be considered at a higher type level. This would make it possible to provide a mapping between more DM2 elements and UPDM elements than currently possible. It is assumed that a tagged value would be easier to handle than the introduction of additional stereotypes since categories would imply elements with different stereotypes inheriting from one another.

  • Reported: UPDM 2.1 — Wed, 28 Mar 2012 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Need for ServiceInterfaces to be represented as an instance to capture specific ServiceAttributes

  • Key: UPDMRTF-3
  • Legacy Issue Number: 17259
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    ActualServiceInterface:
    This would be an element that is the equivalent of the MODAF element ServiceLevel and would contain slots and instance values for the properties that have been defined for ServiceInterface. There would be a need to provide a tagged value to any usage of the ServiceInterface as a port either on a NodeRole or ResourceRole where the actual service interface would be indicated that is to be viewed as a requirement for this particular context. For the port used on the ResourceRole there would also be a need to indicate how many instances of the actualServiceInterface that the ResourceRole would need to accomodate, at least if a complete mapping to between MODAF and UPDM is to be achieved. (All of this actually exists already as part of the MODAF model that UPDM is supposed to implement).

  • Reported: UPDM 2.1 — Tue, 20 Mar 2012 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

explain the relevance of this standard to IT and SE in general

  • Key: UPDMRTF-68
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    For IT and systems engineering experts who are not familiar with military matters it is unreasonably difficult to understand the title of this standard and its significance for IT and systems engineering in general.

    Add, immediately under the heading “Subpart I – Introduction” on page 1, an introductory paragraph e.g. as follows: “This international standard provides a specification language, UPDM, that is readily understandable not only by the community of architects of information technology systems but also by a wide range of end users including executives and enterprise management that sponsor such systems, program managers that oversee their development, developers of supporting hardware and software (design, implementation, and testing), subject matter experts, and end users. UPDM bridges the gap from setting of requirements to high level system design and to visualization for practitioners. While designed in the context of military organisations and their procurement processes, UPDM can also be applied in entirely civilian industrial and service organisation contexts.”

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:09 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Use of superSubType, wholePart and WholePartType in DoDAF 2

  • Key: UPDMRTF-5
  • Legacy Issue Number: 17290
  • Status: open  
  • Source: Syntell AB ( Mr Lars-Olof Kihlstrom)
  • Summary:

    Use of superSubType, wholePart and WholePartType in DoDAF 2
    DoDAF 2 contains rules that indicate that superSubtype relationships can be formed between any type elements of the same kind. The same rule applies for wholePart (betwen individuals of the same type) and WholePartType (between types of the same kind). In UPDM terms this would correspond to Generalization as well as property handling. There are not enough stereotypes defined within UPDM 2 to allow these rules to be followed. This either needs to be rectified or a general statement made within UPDM that allows the use of the appropriate UML relationships to accomplish this.

  • Reported: UPDM 2.1 — Sun, 1 Apr 2012 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Desired Effect needs to be a strategic-level model able element

  • Key: UPDMRTF-6
  • Legacy Issue Number: 17310
  • Status: open  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    I really need "Desired Effect" reinstated. This will act as the "Objective" in my strategy models. This was available in UPDM 1.0 now it's gone. This is actually very important to modeling a strategy.

    However, when or if you can bring it back, it previously provided the output link of "Realizes Vision". That is wrong. It needs to "Realizes Enterprise Goal". It's the Enterprise Goals that realize the Mission. And it's the Mission(s) that realizes the Vision.

    The sequence is as follows:

    CAPABILITY-->DESIRED EFFECT->ENTERPRISE GOAL->MISSION-->VISION

  • Reported: UPDM 2.1 — Fri, 13 Apr 2012 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

The Model library in the UPDM profile should be external to the UPDM profile

  • Key: UPDMRTF-7
  • Legacy Issue Number: 17401
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The Model library in the UPDM profile should be external to the UPDM profile

  • Reported: UPDM 2.1 — Mon, 4 Jun 2012 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Specification lacks Hyperlinks for references to Model Element Names

  • Key: UPDMRTF-1
  • Status: open  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    When the specification is generated, the generator should emit cross-references for references to model elements throughout the text.

  • Reported: UPDM 2.1 — Mon, 9 Dec 2013 22:49 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

PIM Logical Service Specification

  • Key: UPDMRTF-12
  • Legacy Issue Number: 18577
  • Status: open  
  • Source: General Dynamics ( Kent Laursen)
  • Summary:

    An import use of architecture is to provide sufficient information to guide the design and implementation that realizes the architecture in the actual solution space. By definition, architecture dictates neither the design nor the implementation that realizes it, though this boundary is often blurred to a certain degree by a particular organizations methodology or pragmatic need of a projects.

    As SOA is an a widely employed architectural pattern where by systems interact with each other, it would seem important that the expression of SOA in UPDM be fit for purpose, sufficiently accurate and information complete to reduce the conceptual gap between architecture and design+implementation. Further, the rendering or specification of SOA interfaces and used datatypes should be sufficiently fine grained to allow such possibilities as:

    Transformation into constructs used in design and implementation workflows, e.g. Code Skeletons, XML Schema, etc.

    Supporting the expression of test cases and declarative expressions of architectural instrumentation for such purposes as monitoring and analytics.

    In this particular issue we focus on the SvcV-1 and SvcV-2, which would be the natural place to specify the actual SOA related elements. The following diagram provides a context from an external, classifier derived perspective.

    Focusing on the services themselves, the diagram below shows an intended

    The SvcV-1 that illustrate the specification down to the actual operations is shown in the following diagram

    The issue submitter acknowledges that there are arguably some other ways to represent services, given such constructs as ServiceFunction, etc., but the method depicted above “feels” more accurate and aligned with downstream design and implementation, especially in the context of UML that might be used by teams independent of UPDM.

    In conclusion, the issue submitter, along with project colleagues, wish to have a useful set of mechanisms/metamodel constructs that allow the expression on services, their interactions and the flow of data between them at the PIM/Logical level using, logical data captured as EntityItem that details conceptual data captured as ExchangeElement. This would allow direct traceablity from conceptual interchange expressed at the OV level with how it is addressed at the SV level. In simpler terms, when two activities exchange information at the business process level, we can easily find how this conceptual interaction is realized as SOA services. Once establishing this in the model we can then hand it off to design and implementation workflows in a more accurate, traceable and useful architectural specification form. Significantly, such and architecture might prove much more fit-for-purpose for model related practices, transformations and automations involving the instrumentation, simulation and observation of the architecture in its solution realized forms. Also tests might be expressed more tightly.

    Resolution:
    Part of the resolution would be related to the fact that and ExchangeElement is subtyped from ResourceInteractionItem whereas EntityItem is subtyped from Class. The result is that a logical data structure captured as an EntityItem cannot be the conveyed item in a ResourceInteraction. We would either need to revise the metamodel related to ResoureInteractionItem or add some new construct, say something like DataInteractionItem and DataInteraction that could be used to express the flow of logical data, which the issue submitter models using EntityItem in DIV-2 package structures.

    On the profile diagram below, one can observe the absence of EntityItem

    There are related traceablity issues that will the subject of further submissions, however, this submission focuses on the essential part of expressing the set of SOA ports, interfaces and data flows in an architecture.

  • Reported: UPDM 2.1 — Sat, 23 Mar 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Expand general activity modeling for all UPDM constructs to include representation by action, callBehaviorAction and

  • Key: UPDMRTF-10
  • Legacy Issue Number: 18571
  • Status: open  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

    Expand general activity modeling for all UPDM constructs to include representation by action, callBehaviorAction and callOperationAction. Please enter issue against UPDM RTF 2.2.
    Allow ( OperationalActivityAction, ServiceFunctionAction, ProjectActivityAction and FunctionAction ) to be represented as either CallBehaviorAction, CallOperationAction or Actions. Currently only CallBehaviorAction is allowed.

  • Reported: UPDM 2.1 — Wed, 20 Mar 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Implements Relationship between Exchange Elements

  • Key: UPDMRTF-14
  • Legacy Issue Number: 18580
  • Status: open  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    In UPDM 2.0 Exchange Elements emerged from Information and Data Elements used in UPDM 1.x. They can still be classified into information and data indicating different levels of abstraction. However, one cannot be connected to another as it used to be in UPDM 1.x. In other words there is no way to relate data to information.

  • Reported: UPDM 2.1 — Tue, 26 Mar 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Simplify measurements in UPDM

  • Key: UPDMRTF-11
  • Legacy Issue Number: 18573
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Please enter this issue against UPDM RTF 2.2.
    Simplify measurements in UPDM and make measurement compatible with SysML unit, value, and parametric constraint.
    See diagrams below. No need for measurement set.

  • Reported: UPDM 2.1 — Wed, 20 Mar 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

System and PhysicalArchitecture are siblings not descendants

  • Key: UPDMRTF-18
  • Legacy Issue Number: 18708
  • Status: open  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    As shown in Figure 8.127 for CapabilityConfiguration to PhysicalArchitecture and Figure 8.130 for PhysicalArchitecture to SystemResource and in Figure 8.178 for System to ResourceArtifact, Figure 8.132 for ResourceArtifact to PhysicalResource, Figure 8.131 for PhysicalResource to SystemResource, one can see that System and PhysicalArchitecture are sibling concepts.

    Now, FieldedCapability has this constraint: "Value for the classifier property must be stereotyped «CapabilityConfiguration» or its specializations." (see Page 172)

    The consequence of this is that a self-contained System cannot be the Classifier of a FieldedCapability. That is, a FieldedCapability cannot be an instance of a System.

    I claim that it is convenient to be able to specify that a FieldedCapability is an instance of a self-contained System. Having to model a separate CapabilityConfiguration to wrap just the System so that one can instantiate a FieldedCapability that is an instance of the System seems onerous.

    The recommended remedy is to allow a System to be a proper CapabilityConfiguration in addition to being a property of a CapabilityConfiguration.

  • Reported: UPDM 2.1 — Mon, 13 May 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

UPDM DoDAF lacks a concept for Service Orchestration

  • Key: UPDMRTF-16
  • Legacy Issue Number: 18688
  • Status: open  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    Of the available DoDAF Service concepts, neither ServiceAccess nor ServiceDescription is an adequate concept for expressing collaborations of multiple Services such as one does in a SOA ServiceArchitecture.

    The lack of a concept like HighLevelOperationalConcept, say "ServicesOrchestration" or "ServicesCollaboration", for the SvcV-1 makes it difficult in UPDM DoDAF to model SOA Service Architectures. One has to borrow an instance of concept called "ServiceAccess"-which is poorly named and which suggests the means of accessing a single entity-and then claim that the borrowed ServiceAccess instance is really only an abstraction for representing a particular instance of an orchestration of multiple Services. One names it with its type as, say, "Service Orchestration for Situation X : ServiceAccess", and then uses its StructuredClassifier and its BehavioredClassifier natures in order to draw the orchestration of multiple ServiceAccess properties just as one uses UML's composite structures metamodel to model similar collaborations for Highlevel Operational Concepts, Systems Internal Interface Descriptions for systems collaboration in CapabilityConfigurations, SysML IBDs, and etc.

    ServiceDescription is a derivation of ArchitectureDescription that is, itself, an extension of Package. The intended purpose of ServiceDescription is for the documentation of the purpose and of the elements of a Service. Because of this documentary intention and because Package is not intended to be a suitable metaclass for the modeling of composition hierarchies, ServiceDescription, too, is not appropriate for the concept here called "ServicesCollaboration".

    Recommendation: either add <<SOAML::ServiceArchitecture [Collaboration]>> directly into UPDM or add <<UPDM::ServicesCollaboration [Class]>> to UPDM so that one can model Services in Composite hierarchies like they can model conceptually similar collections of parts in contexts in other notations.

  • Reported: UPDM 2.1 — Thu, 25 Apr 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Integrate SysML Requirements and Constraints

  • Key: UPDMRTF-17
  • Legacy Issue Number: 18691
  • Status: open  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    Constraints and Parametric Blocks in the SysML notation have proven their value in enabling the use of models as parameters for discipline-specific analysis and simulation. Likewise, SysML Requirements have proven their usability for annotating models with Requirements and with Requirements Traceabilities (such as Satisfaction, Derivation, etc.)

    The user community (including MITRE, Raytheon, Intercax, and professional services architects such as No Magic staff) requests that UPDM integrate the Requirements, Constraints, and Parametric Blocks into UPDM. Then, Enterprise Architects using UPDM can perform their systems and econometric analyses and their requirements engineering with their UPDM models that they can perform today in SysML modeling.

    (How and Where such integration is accomplished is a topic worthy of deliberation but is beyond the scope of a customer-centric requirement request.)

  • Reported: UPDM 2.1 — Wed, 1 May 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Need of Logical and Physical Services

  • Key: UPDMRTF-13
  • Legacy Issue Number: 18579
  • Status: open  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    In UPDM we are missing capability to differentiate between Logical and Physical Services. Note that this capability is already supported in DoDAF. It is also supported in other frameworks such as TOGAF etc.
    In UPDM it is mixed up and not clear enough what kind of services we are allowing to define. If we use services in SVs, we suppose to have physical services. If we are using services in OVs, we suppose to have Logical (Business) services. Having a normal logical/physical pattern we are already using in UPDM, we should be able to have traces between the two. Unfortunately we cannot differentiate between logical and physical services. It implies we cannot have two different levels of details when we are dealing with services. And we are forced to do services in either Operational or System viewpoint, but not in both.
    UPDM should:
    • Enable user to model logical services
    • Enable user to model physical services
    • Allow traces between logical and physical services
    • Provide means to integrate logical services to OVs
    • Provide means to integrate physical services to SVs

  • Reported: UPDM 2.1 — Tue, 26 Mar 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Future Increments of UPDM should not preclude using SBVR for Modeling Vocabularies and Rules

  • Key: UPDMRTF-15
  • Legacy Issue Number: 18686
  • Status: open  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    SBVR, the Semantics of Business Vocabularies and Business Rules, provides a formal logical foundation for the expression of enterprise ontologies and rule constraints applicable to enterprise elements. SBVR also offers informative, non-normative notations for these vocabularies and rules.

    Future increments of UPDM (i.e. UAFP v1) should not preclude an enterprise architect from using SBVR and its metaclass elements for the expression of ontologies and rules within their UPDM (to be known as UAFP) models.

    These enterprise ontologies and enterprise rules appear throughout a traditional UPDM architecture description in the structural elements of the respective views (e.g. Performers, Operational Activities, Systems, Services, etc) and in the constraints on those elements.

  • Reported: UPDM 2.1 — Wed, 24 Apr 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

ProjectSequence is too Restrictive

  • Key: UPDMRTF-19
  • Legacy Issue Number: 18718
  • Status: open  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    According to the definition of ProjectSequence, "MODAF: Asserts that one ActualProject (MODAF::Project) follows from another - i.e. the target ActualProject cannot start until the source ActualProject has ended. DoDAF: NA".

    The restriction "...cannot start until the source ActualProject has ended..." precludes practical project management.

    In practice, projects can have a partial ordering yet not be strictly sequential. Projects can overlap each other in time, occurring partially contemporaneously.

    One sees, in a common tool such as Microsoft Project, the ability to specify Start to Start, Finish to Finish, Start to Finish, and Finish to Start offsets.

    Recommended Remedy: Enhance Project Sequencing to support SS, FF, SF, and FS offsets between prior and next ActualProjects. The kind of offset and the duration of the offset would each be Tag Values of ProjectSequence.

  • Reported: UPDM 2.1 — Wed, 15 May 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

The <> stereotype and its properties

  • Key: UPDMRTF-20
  • Legacy Issue Number: 18725
  • Status: open  
  • Source: PTC ( Mr. Simon Moore)
  • Summary:

    UPDM includes a <<Property>> stereotype with properties maxValue, minValue and defaultValue. <<CapabilityProperty>> specializes the Property stereotype and extends the Property metatype.

    1. could you rename the Property stereotype to avoid confusion with the UML metatype of the same name?

    2. since the UML metatype Property already has a defaultValue, could the UPDM one be removed?

    3. the min/max/defaultValue properties have no multiplicity specified in the spec or XMI, so it defaults to 1. If these were intended to be optional they should be specified as [0..1]

    These impact XMI (see MIWG TC22).

  • Reported: UPDM 2.1 — Mon, 20 May 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

MapsToCapability relationship is too Restrictive, and ActivityPartOfCapability is redundant

  • Key: UPDMRTF-21
  • Legacy Issue Number: 18738
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    There is a constraint stated in Figure A.30 of the dtc/12-12-17 specification such that in MODAF (and therefore NAF), the MapsToCapability relationship is precluded from using OperationalActivities and is prescribed to only use StandardOperationalActivities.
    This has resulted in defining another relationship in the spec called ActivityPartOfCapability for DODAF, that creeps into MODAF and NAF in vendor implementations, to allow one to associate an activity with a capability for the purposes of generating traceability diagrams and for generating NPV-2: Program to Capability Mapping (through Activity is part of project, and Activity is part of Capability). There is no need for both and it is redundant and a possible source of model inconsistencies to request the architect to define both MapsToCapability and another called ActivityPartOfCapability. Further, the MODAF constraint to use only StandardOperationalActivities when mapping to capabilities for the purposes of (MODAF policy?) can be accommodated in another manner.

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

CV6, CV-7 and NSOV-3

  • Key: UPDMRTF-24
  • Legacy Issue Number: 18741
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    In UPDM it seems that the Service to OperationalActivity matrix is non-editable. The relations are established after one creates capability to OpAct relations and capability to service relations (in CV-6 and CV-7/NSOV-3 respectively). This may be how it is explained in DODAF/ MODAF? (no direct relation between ServiceInterface and OperationalActivity:

    But it is not how it should be. Here is why: CV-7 is useful when considering how services that may already be available (internally to subject architecture scope, or provided by third party entities) can be leveraged to enable the required capabilities. However, a true model-based approach to capability development and analysis will include an operational view model that further delineates the capability (stated as a term and a definition) and describes the ways and means needed or provided to enable the capability. Such an analysis usually uncovers issues with the defined capability taxonomy such as overlapping or non-mutually exclusive capabilities, and will lead to a better formulation of the capability taxonomy. The operational model is also used as a guide to develop or identify needed services in a service model. Thus, it is good SE discipline not to try and develop CV-7 starting with two sets of taxonomies, one for capabilities and another for services, without conducting the necessary modelling of operational and service artifacts needed, conducting the analysis, and “discovering” the relationships between capabilities and the services needed to enable them. So I propose that the order is like this:
    1. develop a Capability taxonomy (CV-2);
    2. develop Operational views (especially the behavior diagrams)
    3. iterate on capability taxonomy and op behavior until one is somewhat satisfied that the capability taxonomy and operational elements (as modeled) are consistent and capabilities are well delineated. At this time a CV-6, (Capabilities x Operational Activities) matrix may be generated;
    4. develop a service view model that supports the operational model and evaluate the ability of the enterprise to offer each Capability and make a Build versus Buy/Outsource decision. Some more iterations on elements in CV, OV, and SOV may take place again, especially as the services taxonomy and service orchestration diagrams are developed. That is, the service model may cause Operational Activities as well as capability taxonomy to change again. Once things stabilize, an SvcV-5/NSOV-3 (Services x Operational Activities) matrix may be generated;
    a. For those Capabilities that will continue to use existing systems within the Enterprise, model their As-Is Systems Views;
    b. For those that are to be Built, or are to be Bought, model the the Services Views to identify (conduct an analysis on what is available within and outside enterprise), and identify the contractual Service-Level Agreements and indicate the Service orchestration with the Enterprise's Performers.
    i. For services to be built, proceed to detail in systems view
    ii. For services to be outsourced stop detail here (services view) but show they are used in systems view (via service request interfaces for system components.
    5. when one feels that the operational and services models satisfy the updated capability taxonomy, one can generate (from the relationships already established), the Capabilities x Services (CV-7) matrix
    6. Develop Systems Views and then map (system) Functions to Services and Functions to Operational Activities.

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

use of Generalization to implement Aliasing

  • Key: UPDMRTF-22
  • Legacy Issue Number: 18739
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Issue 18739:
    Name: Fatma Dandashi
    Employer: Mitre Corp.
    mailFrom: dandashi@mitre.org
    Terms_Agreement: I agree
    Specification: UPDM Profile
    Section:
    FormalNumber: dtc/12-12-17
    Version: 2.1
    Doc_Year: 2012
    Doc_Month: December
    Doc_Day: 17
    Page: 218
    Title: use of Generalization to implement Aliasing
    Nature: Enhancement
    Severity: Significant
    CODE:
    B1: Report Issue
    Remote Name:
    Remote User:
    Time:

    Description:
    DMM defines system as a DoDAF-only alias for ResourceArtifact:

    Profile then defines the following: (this is probably true for all elements that are aliases).

    Using generalization in this manner means that vendor implementations allow one to use both System as well as ResourceArtifact in the same model, regardless if one is using DoDAF or MODAF. System is an alias for MODAF’s ResourceArtifact in DODAF only. That is, System should not be available as a choice in MODAF/NAF. More importantly: generalization is really not the best UML construct to implement aliasing. If you choose System in NAF, you will not be able to use composition and aggregation relationships on SV-1. One should be able to use System in exactly the same manner as a ResourceArtifact, especially the a

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Use of Actual vs. Type in PV-1

  • Key: UPDMRTF-23
  • Legacy Issue Number: 18740
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Currently, one has to use ActualProject and ActualOrganization to get an organizational to project mapping. Why not organization and project types? Understand this theoretically, (only a “real” organization can undertake a “real” project), however what if the architecture description itself was all a pattern? I should be able to associate classes of organizations (a type) with classes of projects.

    Profile:

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Subject of a State Machine

  • Key: UPDMRTF-25
  • Legacy Issue Number: 18742
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Issue State machine issue: UML states the subject of a state machine can be behavior or structural: “The StateMachines package defines a set of concepts that can be used for modeling discrete event-driven Behaviors using a finite state-machine formalism. In addition to expressing the Behavior of parts of a system …, state machines can also be used to express the valid interaction sequences, called protocols, for parts of a system. These two kinds of StateMachines are referred to as behavior state machines and protocol state machines respectively.”
    MODAF specifies both node and activity, DODAF says activity only:
    Short Name DODAF DODAF MODAF/NAF MODAF/NAF
    OV-6b OV-6b State Transition Description DoDAF: The Operational State Transition Description (OV-6b) DoDAF-described View is a graphical method of describing how an Operational Activity responds to various events by changing its state. The diagram represents the sets of events to which the Architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action. OV-6b Operational State Transition Description MODAF: OV-6b: The Operational State Transition Description is a graphical method of describing how an Operational Node or activity responds to various events by changing its state. The diagram represents the sets of events to which the Architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action.
    UPDM states node only?

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

There needs to be a distinction between Operational View IEs and Systems View Exchange elements

  • Key: UPDMRTF-30
  • Legacy Issue Number: 18842
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Information Exchange (IEs) item or element: Currently all IEs are defined as elements of package AllView. This should not be the case. There needs to be a distinction between Operational View IEs and Systems View Exchange elements.
    Discussed Resolution: Currently in MODEM, only InformationElement flows are allowed in OVs (see below). MODEM will use FlowedElement instead. Will consider changing its current type from abstract to make it a typed generic flow defined in OVs. An abstract ResourceType is defined for SVs. It will have as subtypes: human, non-human etc. as shown below. In addition, subtype InformationElement will be moved from current location to be a NonHumanResourceType defined in SVs. Allow any of the SV ResourceType leaf level elements (e.g. NaturalResourceType) to trace back to OV flows.

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

For UAFP. Include a Data and Information view (DIV)

  • Key: UPDMRTF-31
  • Legacy Issue Number: 18843
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    For UAFP. Include a Data and Information view (DIV). This view is to be used for domains where a DB is needed. Remove DIV-3/ SV-11 physical schema as a supported model/Diagram type. Make it an external reference only, either a physical schema in another tool, or an XML flat file etc. Change DIV-1 and DIV-2 to be defined/associated with Systems View elements only, since you only specify data conceptual and logical models at the solution level. In SV, the InformationElement will be a NonHumanResourceType that is associated with entities defined in DIV-1 and DIV-2, since only information can be stored in a database

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Information flow instantiation

  • Key: UPDMRTF-29
  • Legacy Issue Number: 18841
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Information flow instantiation. There is no UML construct to define flow and then to instantiate flows to use flow types and then flow instances that flow between two instances of two things.
    Discussed Resolution: See simple exchange example in MODEM

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Introduce roles in SV-1 and allow them to relate back to OV-4 organizations that will provide them

  • Key: UPDMRTF-28
  • Legacy Issue Number: 18840
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Typical and actual posts, etc. should be introduced and defined in SV-1 as they are the human equivalent of systems, capability configurations, etc. It is in SV that we provide a PSM/white box/logical design model where we introduce elements (human as well as materiel) that are to be allocated to the problem domain described in OV.
    Resolution discussed: introduce roles in SV-1 and allow them to relate back to OV-4 organizations that will provide them. Checked this in MODEM. Below is how it is currently defined.

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Need of Composition between Enterprise Goals

  • Key: UPDMRTF-26
  • Legacy Issue Number: 18785
  • Status: open  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    Please enter this issue against UPDM RTF 2.2.

    In UPDM 2.1 we are missing capability to decompose Enterprise Goals, e.g. goal, objective pattern supported by BMM. This capability is already available in MODAF 1.3 witch UPDM claims to support.

  • Reported: UPDM 2.1 — Thu, 20 Jun 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Why is EnterprisePhase to EnterpriseVision a one to one relationship

  • Key: UPDMRTF-27
  • Legacy Issue Number: 18839
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Why is EnterprisePhase to EnterpriseVision a one to one relationship? Composition relationship is also not needed.
    Discussed resolution:
    • change relationship to: one to many on EnterprisePhase end and 0..1 on EnterpriseVision end.
    • delete composition relationship

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Why are rules in OV-6a and SV-10a not parsed?

  • Key: UPDMRTF-32
  • Legacy Issue Number: 18844
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Why are rules in OV-6a and SV-10a not parsed? They need to be specified as OCL constraints. Similarly for SOVs, use OCL to define performance level supported by each provider to each type of consumer as in a Service Level Agreement (SLA).

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

modify the term NodeRole so that is more applicable to a Peformer

  • Key: UPDMRTF-35
  • Legacy Issue Number: 18957
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The term NodeRole is more applicable to MODAF than DoDAF and does not derive from Performer, Ron Williamson sugested PerformerRole.
    There are other terms that could be affected in the this way like NodeOperation.

    Even though I understand the need, I am against creating more Stereotypes that are Aliases for DODAF. It becomes harder to maintain and more problematic for implement. I would suggest that we rationalise the name of the stereotype for instances of Nodes/Performers to be aligned with both MODAF and DoDAF, i.e. OperationalNode.

  • Reported: UPDM 2.1 — Thu, 26 Sep 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Why does a user need to build an SOV-3?

  • Key: UPDMRTF-33
  • Legacy Issue Number: 18845
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Why does a user need to build an SOV-3? The relationship from services to capabilities should be transitive. Once a user establishes traceability from operational activity to capability and from ServiceFunction to Operational Activity, then there is already a trace from owning service (service that owns that ServiceFunction) to a capability and SOV should b au-populated. Further, a service(Interface) should map to a node and not to an OperationalActivity or to SystemFunction. This change is to be discussed with respective requirements representatives.

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Need to change target of desiredEffect from a state to a new element called effect

  • Key: UPDMRTF-34
  • Legacy Issue Number: 18956
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Desired affect targets "state" in UPDM 2.1, states must have a context and this causes the architects to think too low down in the model (at the OV and SV level) where implementation exists. Desired affect needs to be tied to something in the CV/Stv that is not a "state", called Effect in the CV/StV.

  • Reported: UPDM 2.1 — Thu, 26 Sep 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Profile and Tooling should enforce the Proper Specification of Capabilities

  • Key: UPDMRTF-37
  • Status: open  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    It would help if the tools flagged or restricted Capability definition to encourage the definition of:

    • Effects and metrics
    • Activities involved
    • Conditions under which conducted
    • Performer (optional – often not known during pre-MS A)
    • Desirer of the Effect (optional)

    Rationale from Dave McDaniels:

    Capabilities vs Activities. As you know, the DM2 Capability model is built about the JCIDS definition and centers around effects (resource states) that are measureable (have metrics so you can tell if they've happened) and is produced by ways (Activities) and means (Performers) under specified Conditions (i.e., PMESII, DIME). Thus they are quite a bit different from Activities which transform inputs to outputs or change their state. Many comments are being generated and much argument and rework because many CV's are missing pieces or are clearly Activities being described, not Capabilities. For example, I just turned in a comment on the IdAM RA on their CV in which they defined the Capabilities in terms of their Inputs, Controls, Outputs, and Mechanisms – ICOM – the exact prescription for Activities in IDEF0.

    Note that a PES file that did not have the required pieces and that claimed to contain CV information would fail validation. Also note the DoDAF-DM2 formulation of CV's fits the JCIDS-DAS-SE processes by linking ICD threshold and objective attributes and CDD/CPD KPP/KSA/OSA to the CV's and to the T&E process by aligning the architecture and JCIDS documents to test metrics. This method was also designed to allow flow down of operational metrics (MOEs) to SV/SvcV (e.g., SV-7) metrics (MOPs). It also aligns with training since UJTL tasks have measure types (several defined per task), UJTLs map to JCAs, and JCAs are the organizing construct for ICD attributes and are also required in CDD/CPD. There are probably many other elements of architecture and systems engineering that align by defining Capabilities the way we did in DoDAF. DoD CIO A&I and Joint Staff J6 are in very close agreement on all this.

  • Reported: UPDM 2.1 — Sat, 14 Dec 2013 20:50 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

AV-2 Definitions need Authoritative Source property and Tooling to enforce its Use

  • Key: UPDMRTF-38
  • Status: open  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    A tool that is DoDAF conformant should encourage the user to fill in the Authoritative Source field whenever they define a new architecture element (AV-2). The Authoritative Source should provide specific locator for the source of the term and definition. Multiple AS may be occur.

    Rationale from Dave McDaniels:

    Almost every JIE architecture gets a comment from JS J6 that the AV-2 is missing the Authoritative Source for the term and definition which they say is a DoDAF conformance requirement. The problem they’re really getting at is the proliferation of inconsistent AV-2 terms even in a single project like JIE, even worse across all the mission areas. The number of AV-2 terms in the WMA repository is in the tens of thousands if not more by now. Mapping, reconciling, adjudicating, etc. is impractical. Their approach is to encourage reuse of terms to encourage standardization, e.g., the Joint Common System Functions List (JCSFL), JCAs, UJTLs, … Everyone agrees but the AV-2 Authoritative Source fields remain blank – once the toothpaste is out the tube, very hard to get back in.

  • Reported: UPDM 2.1 — Sat, 14 Dec 2013 22:37 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

UPDM Users want to model Test Contexts and Test Cases within UPDM

  • Key: UPDMRTF-39
  • Status: open  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    One or more clients of No Magic Professional Services seek to be able to model the systems, services, test case behaviors, test data, and so forth of the verification and validation of their UPDM-specified Systems and Services.

    These clients are already using SysML within UPDM for their Requirements engineering and for their Systems Viewpoint modeling.

    SysML delegates Verification concerns to the UML Testing Profile via SysML's <<verify>> Relationship between Requirements and Test Case activities.

    These clients of No Magic ask that No Magic champion the integration of the UML Testing Profile-or any other standardized set of concepts-into UPDM.

  • Reported: UPDM 2.1 — Fri, 20 Dec 2013 19:36 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Figure 8.1 Presents InformationAssuranceProperties Twice

  • Key: UPDMRTF-40
  • Status: open  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    Figure 8.1 on page 23 has two symbols for the same element: InformationAssuranceProperties appear twice on the diagram.

    One instance of the symbol would suffice.

  • Reported: UPDM 2.1 — Tue, 21 Jan 2014 03:58 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT
  • Attachments:

DoDAF elements need to be identified and added to the various diagrams that represent the views

  • Key: UPDMRTF-36
  • Legacy Issue Number: 18958
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    This issue relates to the readability of the specification on the various "view diagrams", DoDAF elements are left of off these diagrams it becomes hard to recognise which diagrams use specific DODAF elements, it is only through understanding what things have DoDAF aliases that you can see what needs to be added to the correct diagram.

    These elements need to be added to the diagrams that they can participate in by showing the MODAF elements that they alias/inherit properties from.

  • Reported: UPDM 2.1 — Thu, 26 Sep 2013 04:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

Withdraw UDPM Spec

  • Key: UPDMRTF-42
  • Status: open  
  • Source: Aerospace Corporation ( Mr. John Reeves)
  • Summary:

    There is no support for the specification. The DoD CIO is not updating or supporting DoDAF documentation. The IDEAS group is defunct. No one is maintaining DM2. The website udpmgroup.org is for sale. See http://www.omg.org/syseng/UPDM.htm. The specification appears to be generated from a model, and is way below the quality standards for other OMG specifications.

  • Reported: UPDM 2.1 — Wed, 24 Aug 2016 22:34 GMT
  • Updated: Thu, 11 Apr 2024 13:10 GMT

capability element should have a relation to sysml requirement type.

  • Status: open   Implementation work Blocked
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    we need to be able to add requirements in UPDM, define test cases and use requirement relations (refine, verify). by adding stereotype <<requirement>> to current class-type capability, we can do all of the above. or at least add in profile a defined relation to relate requirements to capabilities.

  • Reported: UPDM 2.1.1 — Fri, 4 Dec 2020 16:19 GMT
  • Updated: Mon, 28 Dec 2020 17:05 GMT