1. OMG Mailing List
  2. UPDM 2.2 Revision Task Force

Closed Issues

  • Issues resolved by a task force and approved by Board
  • Name: updm-2-0-rtf
  • Issues Count: 49

Issues Summary

Key Issue Reported Fixed Disposition Status
UPDM2-3 Broken link for issue reporting UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-10 Incorrect acknowledgement UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-9 The ISO8601:2004 is probably a normative reference and should be placed in section 3 UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-8 8.2.1.1.3 and 8.2.1.1.3.1 define ISO8601DateTime UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-7 Increment and out of service milestones do not pair UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-6 capability to assign actual organizational resources to a project in a particular time frame missing UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-5 Project Sequence should have a tag Sequence Kind UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-4 It's not possible to show that a resource configuration realizes two or more capabilities at different periods of time UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-18 The namespace to use for UPDM is unclear due to inconsistent values UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-17 wrong document reference UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-16 Section 8.2.1 UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-15 Section 2.1.2 UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-14 2.1.1: typo: it has RequiresPoint which does not exist in SoaML and I UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-13 It's very odd and counter-intuitive to have UPDM L0 buried in UPDM L1 UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-12 Document still references DoDAF v1.5, when it should reference DoDAF V2.02 UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-11 Need to add a conforms to relationship for an element of type Interface to be able to associate a standard with it UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-25 UPDM stereotype name conflict UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-24 Instance value and slot use in all UPDM elements that extend InstanceSpecification UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-23 ResourceConnector.realizedExchange does not have a programmable direction or other context specific data UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-22 Need non-nomative profiles for NAF. DODAF and MODAF views and viewpoints UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-21 Concern needs to be added to the AV-1 UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-20 Figure 8.8. uses <> incorrectly UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-19 "Include DoDAF 2.02 Conformance Level Three (L3) Statement" UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-31 Performer is defined both as an alias and a specialization of Node UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-30 No definition for PhysicalResource UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-29 Missing TOC entries UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-28 change stereotype extensions (base_*) marked as "private" to "public" UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-27 Attribute URI/URL should be renamed and made optional UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-26 some properties are wrongly marked as mandatory UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-37 Confusion in type for Project status UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-36 DoDAF users are upset using MODAFRoleKind property on the ResourceRole UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-35 Remove model libraries from UPDM 2.0 profile structure UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-34 Activity is an abstract element, it should be concrete UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-33 By having Exchange Element as a Datatype there is not possible to define the State Machine for it UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-32 properties of EnterprisePhase are wrongly named UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-49 IndividualPersonRole is missing from the spec, but has references to it UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-48 Section on GeoPoliticalExtentTypeKind is missing UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-47 Details is missing, even though there are references to it UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-46 Resource has been changed to SystemResource UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-45 Service message has the wrong graphic UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-44 PropertyValue should be removed from the UPDM Document UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-43 ExchangeItem has been deleted from UPDM and should not be in the document UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-42 ActualProperty definition missing from document UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-41 Incorrect SV-4 DMM Diagram UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-40 Incorrect AV-1 DMM Diagram UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-39 Conflicting PV-3 diagrams for DMM and Profile UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-38 Missing sequencing capability for DoDAF Project Activities UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-51 Mislabeled Figure B.9 OV-3 should be OV-2. UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-50 Remove SystemConnector from Spec UPDM 2.0 UPDM 2.0.1 Resolved closed

Issues Descriptions

Broken link for issue reporting


Incorrect acknowledgement

  • Key: UPDM2-10
  • Legacy Issue Number: 16688
  • Status: closed  
  • Source: Logica UK ( Peter Bryant)
  • Summary:

    C.3.2 includes an acknowledgement for the original authors of the SAR model in MODAF, which I believe was included at my request.
    The listing for 'Peter Martin of LogicaCMG' should read 'Peter Bryant of Logica'.

  • Reported: UPDM 1.1 — Wed, 16 Nov 2011 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Think this was done in the Jan 12 revision but we need to note in RTF.

    Current text in OMG 12-01-03 document is the following:
    ________________________________
    D.3.2 Acknowledgements
    The scenario is derived from the UK Search and Rescue framework, which is publicly available on the internet3. The sample problem is based on a concept derived by VEGA under contract for the UK MOD.4 The UPDM Group acknowledges its debt owed to the authors of the original problem:

    • Ian Bailey of Model Futures,
    • Peter Bryant of Logica, and
    • Paul King of Vega
    ____________________________________________________________

    We need to ensure that this change is in version 2.1 as well

  • Updated: Fri, 6 Mar 2015 20:59 GMT

The ISO8601:2004 is probably a normative reference and should be placed in section 3

  • Key: UPDM2-9
  • Legacy Issue Number: 16641
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The ISO8601:2004 is probably a normative reference and should be placed in section 3.

    Recommended text:

    ISO 8601:2004 Data elements and interchange formats – Information interchange – Representation of dates and times”, IS0, TC154

  • Reported: UPDM 1.1 — Fri, 28 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Update the document section 3 as proposed

    Add the following text as an additional bullet point in section 3.2:

    • 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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.2.1.1.3 and 8.2.1.1.3.1 define ISO8601DateTime

  • Key: UPDM2-8
  • Legacy Issue Number: 16640
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The text for the definition in 8.2.1.1.3.1 is not internally consistent, nor consistent with ISO8601

    Current Text

    “MODAF: A date and time specified in the ISO8601 date-time format including timezone designator (TZD):
    YYYY-MMDDThh:mm:ssTZD So, 7:20pm and 30 seconds on 30th July 2005 in the CET timezone would be represented as “2005- 07-30T19:20:30+01 :00.”

    You may notice that the “-“ and “ “ in the pattern definition and in the example are not consistent. The ISO definition is as follows:

    YYYY-MM-DDThh:mm:ssTZD

    Where TZD= Z for Zulu (GMT)

    = or ±NN:NN

    With the example of 7:20 pm and 30 seconds on 30th July 2005 in the CET (Central European)Timezone would be

    “2005-07-30T19:20:30+01:00”

    Suggested Fix.

    a) Correct Pattern definition

    YYYY-MMDDThh:mm:ssTZD à YYYY-MM-DDThh:mm:ssTZD (where TZD=Z or ±NN:NN)

    This adds the – between the MM and DD subfields, and explains the possible values for the TZD field

    b) Correct Example

    2005- 07-30T19:20:30+01 :00 à 2005-07-30T19:20:30+01:00

    This drops the extra space before the month and after the timezone offset hour.

  • Reported: UPDM 1.1 — Fri, 28 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    The current version of the specfiication has the correct definition of IS08601 date time in the spec. Therefore it was decided to close this issue with no change

    Proposed Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Increment and out of service milestones do not pair

  • Key: UPDM2-7
  • Legacy Issue Number: 16580
  • Status: closed  
  • Source: No Magic, Inc. ( Aurelijus Morkevicius)
  • Summary:

    Increment and out of service milestones do not pair. For instance if you have two out of service milestones defined you cannot know which one is the right one for a concrete increment. I'm thinking about solving this issue by using milestone sequence relationship; however project sequence can be used for other purposes as well. The usage of it is somehow ambiguous, especially in a case like this.

  • Reported: UPDM 1.1 — Mon, 3 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    After discussion with Lars, there are some rules that need be made explicit in the spec. I.e capability increments that are related by CapabilityIncrement then ConfigurationDeployed, ConfigurationNoLongerUsed (as configuration is dropped by Actual org) and finally OutOfService when no org is using the configuration.

    Add some descriptive text to the elements above as guidance on usage. This is added in the description of the diagrams that are used to capture Milestones which are AcV-2/PV-2

    Add the following Descriptive text to the following section:

    Updated Text:

    B.1.1.2 AcV-2/PV-2

    IncrementMilestone and OutOfServiceMilestone are both tied to a particular SystemResource, this implies that the connection to a given SystemResource indicates how the pairing should be made.

    All in all there are 4 different milestones for which there is an implied order. This order is however not enforced by the framework and needs to be dealt with by the architect. The rules for this ordering are as follows:
    • IncrementMilestone:
    Has to be associated with a date that precedes all milestones below for a specified uniquely identifiable SystemResource.
    • DeployedMilestone:
    Has to be associated with a date that occurs after the IncrementMilestone and associated the SystemResource with a specific Organization,
    • NoLongerUsedMilestone:
    Has to be associated with a date that occurs after the DeployedMilestone for a specific SystemResource, Organization combination. This milestone cannot exist if the DeployedMilestone does not exist for the same given SystemResource, Organization combination.
    • OutOfServiceMilestone:
    Has to be associated with date that occurs after or at the same time as the latest NoLongerUsedMilestone for the uniquely identifiable SystemResource and requires that no organization still has this system resource deployed (or after the IncrementMilestone if the SystemResource was never deployed to any organization before being put outOfService).

  • Updated: Fri, 6 Mar 2015 20:59 GMT

capability to assign actual organizational resources to a project in a particular time frame missing

  • Key: UPDM2-6
  • Legacy Issue Number: 16579
  • Status: closed  
  • Source: No Magic, Inc. ( Aurelijus Morkevicius)
  • Summary:

    . I'm missing a capability to assign actual organizational resources to a project in a particular time frame. There is a relationship called Organizational Project Relationship, however it does not have start and end date properties. By not having this capability I cannot calculate how much time on a project spent one or another employee and compare this value with a number required by typical organizational resources for the same project.

  • Reported: UPDM 1.1 — Mon, 3 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 39 through 44 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Project Sequence should have a tag Sequence Kind

  • Key: UPDM2-5
  • Legacy Issue Number: 16578
  • Status: closed  
  • Source: No Magic, Inc. ( Aurelijus Morkevicius)
  • Summary:

    I would suggest Project Sequence would have a tag Sequence Kind to store values like "start-to-start", "start-to-finish", "finish-to-start", and “finish-to-finish".

  • Reported: UPDM 1.1 — Mon, 3 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    The rationale behind the request is that it keeps alignment with standard project management tools. Aurelijus suggested a text field to describe this relationships, Lars said this is outside the intent of MODAF and there is an implicit understanding that a target project cannot start until source project finishes.

    There is a workaround which is to use measurements applied to project to capture this information.

    Therefore it was decided to close this issue with no change

    Proposed Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

It's not possible to show that a resource configuration realizes two or more capabilities at different periods of time

  • Key: UPDM2-4
  • Legacy Issue Number: 16577
  • Status: closed  
  • Source: No Magic, Inc. ( Aurelijus Morkevicius)
  • Summary:

    It is not possible to show that a resource configuration realizes two or more capabilities at different periods of time. It is because increment and out of service milestones are not related to capability. By not having this relationship all periods of time that are described by milestones are applicable to both capabilities realized by the same resource. For instance I want to say that my configuration X will realize capability A starting from 2010.01.01 till 2011.02.12 and will realize capability G starting from 2011.03.01 till 2011.04.12. As I've mentioned before milestones that are holding the date values are not related to capabilities, so what I get is capabilities A and G are realized by the resource configuration X in two periods of time (from 2010.01.01 till 2011.02.12 and from 2011.03.01 till 2011.04.12). By not having relationship between capability and a milestone I can say that for instance increment milestone holding date 2011.03.01 is incrementing G capability. But it can increment A capability as well.

  • Reported: UPDM 1.1 — Mon, 3 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Leave it how it is. This information needed to be captured as it is outside the scope of MODAF STV-3

    Add guidance to the spec in the context of the framework that a person is using. Text added to STV-3 description in the model

    Add the following text to section A.1.5.4 StV-3/CV-3 and section B1.5.4 StV-3/CV-3

    The IncrementMilestone and RetirementMilestone in UPDM originate from the MODAF framework. They tie to a PhysicalArchitecture/ CapabilityConfiguration and if the latter is indicated this in turn ties to a Capability since it is a CapableElement that exhibits a Capability. Capabilities are by themselves timeless i.e. it should not be possible to associate Capabilities and time directly. If an IncrementMilestone connects to CapabilityConfiguration X at time T and this configuration realizes Capability A, it cannot at a later time also realize Capability B without something having changed, i.e. there has to be a CapabilityConfiguration X’ that is tied to an IncrementMilestone where capabilities A and B are realized. It is suggested that these two CapabilityConfigurations are treated as versions of a CapabilityConfiguration master (SV-8).

  • Updated: Fri, 6 Mar 2015 20:59 GMT

The namespace to use for UPDM is unclear due to inconsistent values

  • Key: UPDM2-18
  • Legacy Issue Number: 17042
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The specification document (front page) says:
    Standard document URL: http://www.omg.org/spec/UPDM/2.0 and Associated Schema Files: http://www.omg.org/spec/UPDM/20110601
    The XMI for the profile itself declares:
    xmlns:updm='http://www.omg.org/spec/UPDM/2.0/20110615'
    Aside: including "2.0" in the URI is inconsistent with OMG guidelines: the date-based format was to replace the use of version number

  • Reported: UPDM 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    closed in the urgen issue resolution process

  • Updated: Fri, 6 Mar 2015 20:59 GMT

wrong document reference

  • Key: UPDM2-17
  • Legacy Issue Number: 17041
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The formal XMI file for UPDM http://www.omg.org/spec/UPDM/20110601/dtc-2011-06-15.xml makes several references to SoaML using the following base URL: http://www.omg.org/spec/SoaML/20091101/09-11-15.xmi.
    This is the old document, which is for an older version of UML than used by the UPDM profile, and does not reflect the updated and correct SoaML profile sent by Jim Amsden on Dec 5 (attached), though I'm not sure it has even been allocated a document number or been posted.

  • Reported: UPDM 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    closed in the urgen issue resolution process

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.2.1

  • Key: UPDM2-16
  • Legacy Issue Number: 17027
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    8.2.1 states that UPDM L1 " imports parts of SysML - Requirements and
    ModelElements namely." However that does not seem consistent with section 2.1 or the diagram

  • Reported: UPDM 2.0 — Fri, 20 Jan 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    section 2.1.1 has the following text
    Figure 2.2 illustrates that UPDM 2.0 Compliance Level 0 is an implementation of UPDM extending UML 2 and importing several SoaML stereotypes – namely Expose, Attachment, RequestPoint, ServicePoint, MessageType, Property. In order for a tool to be considered as compliant with L0, the following must be true:

    This is in contradiction to section 8.2.1 which says
    UPDM L0 contains all the Core, DoDAF, and MODAF elements, and imports parts of SysML - Requirements and ModelElements namely. This compliance level is primarily based on UML and reuse of a minimum of SysML elements. This includes Requirements and Views/Viewpoints. As one of the core principles is reuse, cloning/recreating of these existing SysML structures was considered as inappropriate.

    We will change section 8.2.1 to say
    UPDM L0 contains all the Core, DoDAF, and MODAF elements, reuses UML and imports parts of SoaML. This compliance level is primarily based on UML 2 and the import of a minimum of SoaML stereotypes. The SoaML stereotypes imported are Capability, ServiceInterface, Expose, Attachment, Request, Service, MessageType, Property, ServiceChannel and Participant.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 2.1.2

  • Key: UPDM2-15
  • Legacy Issue Number: 17026
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    2.1.2: it's wrong to say that "Figure 2.2 illustrates that UPDM

    Compliance level 1...imports the rest of the SysML sub-profiles". Also
    that it illustrates that it "defines constraints"

  • Reported: UPDM 2.0 — Fri, 20 Jan 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

2.1.1: typo: it has RequiresPoint which does not exist in SoaML and I

  • Key: UPDM2-14
  • Legacy Issue Number: 17025
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    2.1.1: typo: it has RequiresPoint which does not exist in SoaML and I

    believe should be RequestPoint as in the diagram above.
    this has been repaired.
    The text is still inconsistent with the diagram -the text is missing
    Capability, ServiceInterface.

  • Reported: UPDM 2.0 — Fri, 20 Jan 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Update diagram 2.2 ServicePoint, RequestPoint, to be Service and Request.
    Also update associated text in section 2.1.1.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

It's very odd and counter-intuitive to have UPDM L0 buried in UPDM L1

  • Key: UPDM2-13
  • Legacy Issue Number: 17024
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    It's very odd and counter-intuitive to have UPDM L0 buried in UPDM L1 -

    I spent ages trying to find it in the contents.

  • Reported: UPDM 2.0 — Fri, 20 Jan 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    This was the result the initial profile structure we used to separate out their use/import of the SysML profile. This was originally based on a similar structure and conventions used in UML and its compliance levels. To change this during the RTF will have a large impact on the structure of the document, the profile and resultant XMI.

    Therefore it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Document still references DoDAF v1.5, when it should reference DoDAF V2.02

  • Key: UPDM2-12
  • Legacy Issue Number: 16912
  • Status: closed  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    See Page 255 of the UPDM,

    “Table B.1 shows the traceability among UPDM stereotypes and DODAF 1.5/MODAF elements”

    The table column heading: “DoDAF 1.5 Model Elements”

    Page 275: “The scenario and modeling was easily updated to include UPDM concepts including US DoDAF 1.5.”

    Do a search and replace on all references to DODAF v1.5 in the UPDM v2.0 spec: dtc/2011-05-07

  • Reported: UPDM 1.1 — Thu, 15 Dec 2011 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    This issue appears to be fixed, but we did a search on other references to DoDAF 1.5 that should be DoDAF 2.0 and we found that the description for the technical standards elements needed to be updated.

    Make the following change:

    "Replace the text of section 8.3.1.3.7 UPDM L1: :UPDM L0: :Core: :TechnicalStandardsElements

    Section 1.4.4 of the DoDAF version 1.5 Definitions and Guidelines (Volume I): Define the purpose of the Technical View as follows:
    “The TV is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements. Its purpose is to ensure that a system satisfies a specified set of operational requirements. The TV provides the technical systems implementation guidelines upon which engineering specifications are based, common building blocks are established, and product lines are developed. It includes a collection of the technical standards, implementation conventions, standards options, rules, and criteria that can be organized into profile(s) that govern systems and system or service elements for a given architecture.”

    With:

    “UPDM 2.0 retains the TV Viewpoint which maps to the new DoDAF 2.02 StdV Standards Viewpoint. DoDAF Version 2.02, “DoDAF Viewpoints and Models: Standards Viewpoint” defines the purpose of the Standards Views. StdV-1 is a wider definition of the concept of “technical standard” than used in previous DoDAF versions. Such standards were restricted, for example, to ISO, OMG, OASIS, and similar standards) and could be found in the DoD IT Standards Registry (DISR). It now includes not only such software (information technology) standards but wider standards including hardware and other technologies. It includes protocols and data standards. It now is expanded to include technical, operational, and business standards defined liberally as well as guidance, policy, regulations, and laws applicable to the architecture being described. The StdV-1 is a set of such standards that applies to one (current) time-period. If emerging standards are addressed for a future period of time, a StdV-2 Standards Forecast should be completed as well. The purpose of StdV is both to specify the standards with which a project must comply as well as to planning for additional or future application of standards. The StdV collates the various systems, services, etc. with the rules (standards) that govern the implementation of the architecture. A typical StdV should reference elements used in the various other System Views (SV) (SV-1, 2, 4, 6), Service Views (SvcV-1, 2, 4, 6) and layers DIV (DIV-2 and DIV-3). Protocols often are Resource Flow descriptions defined in SV-2 and SvcV-2. The degree of compliance to standards may also be addressed in risk assessments."

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Need to add a conforms to relationship for an element of type Interface to be able to associate a standard with it

  • Key: UPDM2-11
  • Legacy Issue Number: 16718
  • Status: closed  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    Need to add a conforms to relationship for an element of type Interface to be able to associate a standard with it

  • Reported: UPDM 1.1 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    We did not want to add any further elements to the UPDM spec and there are potential workarounds for this issue as it is possible to associate a standard using the ConformsTo tag on ResourceInterfaces or ResourcePorts or it could be done using a SysML satisfy between the interface and the standard.

    It was decided to close this issue with no change

    Proposed Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UPDM stereotype name conflict

  • Key: UPDM2-25
  • Legacy Issue Number: 17329
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Unified Profile for DoDAF and MODAF (UPDM), Version 2.0 (formal/2012-01-03)

    Subclause: 8.3.1.4.3.1.2.2 Organization

    The profile UPDM L1::UPDM L0::DoDAF::OperationalElements::Structure::Organizational defines a stereotype Organization that specializes ActualOrganization from UPDM L1::UPDM L0::Core::OperationalElements::Structure::Organizational::Actual. There is also a stereotype called Organization defined in UPDM L1::UPDM L0::Core::OperationalElements::Structure::Organizational::Typical.

    This is the only case within the UPDM profile as a whole in which there are two stereotypes with the same simple name. While this does not cause any problem from a technical UML point of view, since the stereotypes are in different UML namespaces, it does have implications for the XMI serialization of UPDM models. Since stereotype applications use the XMI namespace for a profile to disambiguate stereotype names, not UML namespaces, having this one naming conflict makes it impossible to use a single XMI namespace for the UPDM profile and all its subprofiles.

    The DoDAF Organization stereotype does not add any functional capabilities over the Core ActualOrganization stereotype. It would therefore simplify the serialization of UPDM models, by allowing the use of a single XMI namespace, if the Organization stereotype was simply deleted from DoDAF and the ActualOrganization stereotype from Core was used instead in DoDAF models.

  • Reported: UPDM 2.0 — Mon, 23 Apr 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    closed in the urgen issue resolution process

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Instance value and slot use in all UPDM elements that extend InstanceSpecification

  • Key: UPDM2-24
  • Legacy Issue Number: 17277
  • Status: closed  
  • Source: Syntell AB ( Lars-Olof Kihlstrom)
  • Summary:

    It is felt that the utility of the UPDM framewor would be increased if the profile allowed slots and instance values on all elements in the UPDM profile that extends the metaclass InstanceSpecification. Currently this is only done partially.

  • Reported: UPDM 2.0 — Wed, 28 Mar 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    This is basic functionality of UML modeling tools so can be implemented by users if need. There is no specific fix required in UPDM

    Therefore it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResourceConnector.realizedExchange does not have a programmable direction or other context specific data

  • Key: UPDM2-23
  • Legacy Issue Number: 17265
  • Status: closed  
  • Source: Siemens ( Daniel Brookshier)
  • Summary:

    ResourceConnector.realizedExchange between same role has no direction.

    This causes an issue when there is no natural direction for the exchange, especially when two roles have an identical types. There is also no realization specific measures.

    For example. A a structure of a cat box containing two identical resources of the type Kitty with roles a and b. Kitty has an ResourceInteraction to itself defined. In the context of the cat box composite, the only allows the realization of the exchange, but not the direction (a to b or b to a).

    The proposal would be a complex type for realized exchanges that includes direction, the exchange, and possible instance specific measures. This solves several issues. Less viable are lists for direction.

  • Reported: UPDM 2.0 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    This is a complex issue that goes back to the roots of UML if dealt with correctly. A
    Workaround was determined if you use roles in the swimlanes of the activity diagram, use of flow ports or provide required ports, all give indication of direction. Which allows this information to be derived.

    Therefore it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Need non-nomative profiles for NAF. DODAF and MODAF views and viewpoints

  • Key: UPDM2-22
  • Legacy Issue Number: 17264
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Views and viewpoint stereotypes do not exist in UPDM at the moment.
    We need to add them so that we can start to interchange sections of information formally and exchange diagrams when DDI for the specification of UML/SysML diagrams is defined.

  • Reported: UPDM 2.0 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Resolution:
    References to view and viewpoint in diagram names are not SysML or 1471 definitions, this is a requirement for standard stereotypes for the diagrams and packaging structures in UPDM as as used in DoDAF and MODAF terminology.

    As stereotypes are not allowed for Diagrams types in UML it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Concern needs to be added to the AV-1

  • Key: UPDM2-21
  • Legacy Issue Number: 17263
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Concern:
    Currently Concern is shown as a tagged value string within the concept ViewPoint element ( a stereotype based on package). This misses the general intent in MODAF where Concern is a stereotype of Usecase and where stakeholders can be associated directly with the usecase to indicate who is interested in what within the architecture model in question. THis is done via the dependency stereotype StakeholderHasConcern where the staekoholder can be an OrganisationalResource in MODAF. I would think that in UPDM the stakeholder should be allowed as either an OrganisationalResource or an actual organisational resource.

    The UPDM elements View and Viewpoint are stereotypes of package and this actually creates something of a browser structuring problem and should in my view be deleted/ changed. In MODAF View is used as an additional reading inststruction for a concern essentially implying that for each view instance created by an architect a proxy is created in AV-1 with the same name based with this proxy being a View stereotype of Class. This can also be connected to Concern in order to indicate in which views within the architecture that a certain concern can be found. All of these elements are essentially reading instructions. The element ArchitectureProduct in MODAF is also missing, it is also tied to concern and contains a list of the architecture elements that a given concern is associated with. Its current counterpart in UPDM would seem to be View ( a stereotyped package and as indicated previously the use of packages here represent a problem). It should be noted that a given concern can apply to more than one instance of an architectural view and that elements may well apply to more than one concern i,e, in both cases there is the possibility of many to many relationships, something that makes the use of packages as a means of structuring things very difficult.

  • Reported: UPDM 2.0 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Lars indicated that concern should be added as first class element based upon Use case.

    There is a large impact due to clash between Concerns tag in SysML from which View/Viewpoint in UPDM are derived and also the inadequacies of the View/Viewpoint specification in SysML.

    Therefore it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.8. uses <> incorrectly

  • Key: UPDM2-20
  • Legacy Issue Number: 17207
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Figure 8.8 shows a <<metarelationship>> with metaclass = trace. But trace is a stereotype (coming from UML standard profile L2 via SysML) so this should be a <<stereotyped relationship>>.

  • Reported: UPDM 2.0 — Thu, 1 Mar 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 52 and 53 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

"Include DoDAF 2.02 Conformance Level Three (L3) Statement"

  • Key: UPDM2-19
  • Legacy Issue Number: 17095
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Leonard Levine)
  • Summary:

    "Section 3.3 Department of Defense" (Normative References) and/or "Section 2 Compliance".

    A paragraph needs to be added related to "DoDAF 2.02 Conformance Level Three (DoDAF L3)."

    UPDM 2.0 conforms with Level Three (3) as specified by DoDAF 2.02.
    The DoDAF Levels of conformance are:

    DoDAF Level 1 is conceptual conformance.
    DoDAF Level 2 is logical data model conformance.
    DoDAF Level 3 is physical data model conformance.
    DoDAF Level 4 is syntactic/ontology conformance with a full spatial-temporal (4-dimensional) ontology.

    Note: DoDAF Levels are not to be confused with UPDM Levels.

    Note: DoDAF Levels are cumulative, that is, Level 3 physical data model conformance builds upon Level 2, logical data model conformance.
    One cannot achieve DoDAF Level 3 without achieving DoDAF Levels 1 and 2.

    As evidence of conformance at the logical data model level (DoDAF Level 2), we refer the reader internally to Annex C.1, "DoDAF-DM2, UPDM, and MODAF Mapping". For DoDAF Level 3, we cite the proven exchanges among UPDM 2.0 implementations at the physical layer using the OMG XML Model Interchange (XMI) specification. Tools that conform with UPDM Level 0 or UPDM Level 1 must be able to make this XMI interchange. See internal section 2.1.1 and 2.1.2

    Len Levine for US DoD

  • Reported: UPDM 2.0 — Thu, 2 Feb 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    The text in section 7.7.2 relating to DODAF 2.0.2 conformance is not in an appropriate place in the document so it should be moved to the section 3.3 relating to DoDAF compliance
    Remove section
    7.7.2 DoDAF 2.02 Conformance
    Compliance with UPDM 2.1 Profile including metadata should assist the tool vendor in adhering to DoDAF 2.02 because the UPDM 2.1 Core and DoDAF-specific metadata models in UPDM 2.1 adhere to the metadata model inherent in DoDAF 2.02 Conceptual and Logical data models. In developing the UPDM 2.1, domain meta-modelers have also consulted the corresponding Physical data model in DoDAF 2.02 and to resolve questions of general conformance with enterprise-level architectural elements. Nevertheless, tool vendors are advised to consult DoDAF Version 2.02 (especially Volume I, page 2-6; Volume II, page 2-6; and Volume III, page 1-2) before claiming DoDAF 2.02 conformance. While conformance with UPDM 2.1 Core and DoDAF-specifics should greatly facilitate conformance with DoDAF 2.02, each tool vendor is still responsible for the tool's ultimate conformance with the documented architecture framework.
    Compliance with UPDM 2.1 Profile including metadata should assist the tool vendor in adhering to DoDAF 2.02 because the UPDM 2.1 Core and DoDAF-specific metadata models in UPDM 2.02 adhere to the metadata model inherent in DoDAF 2.02 Conceptual and Logical data models. In developing the UPDM 2.1, domain meta-modelers have also consulted the corresponding Physical data model in DoDAF 2.02 to resolve questions of general conformance with enterprise-level architectural elements. Nevertheless, tool vendors are advised to consult DoDAF Version 2.02 before claiming DoDAF 2.02 compliance.
    The DoD-CIO has clarified in a Decision Brief of 12 Jan 11 that it does not expect UPDM 2.1 to export models in PES, nor to provide an implementation of 4D (geo-spatial-temporal modeling) including a global implementation of Whole-Part and Temporal-Whole-Part for all UPDM elements (classes/objects).
    The UPDM Profile to DoDAF Metamodel Compliance Matrix has been published as non-normative Annex C of the specification to aid tool vendors in their claims to DoDAF Level 2 Conformance. This matrix should also facilitate upgrades to Level 3 and 4 of DoDAF Conformance in future versions of UPDM.

    Append to section 3.3
    7.7.2 DoDAF 2.02 Conformance
    Compliance with UPDM 2.1 Profile including metadata should assist the tool vendor in adhering to DoDAF 2.02 because the UPDM 2.1 Core and DoDAF-specific metadata models in UPDM 2.1 adhere to the metadata model inherent in DoDAF 2.02 Conceptual and Logical data models. In developing the UPDM 2.1, domain meta-modelers have also consulted the corresponding Physical data model in DoDAF 2.02 and to resolve questions of general conformance with enterprise-level architectural elements. Nevertheless, tool vendors are advised to consult DoDAF Version 2.02 (especially Volume I, page 2-6; Volume II, page 2-6; and Volume III, page 1-2) before claiming DoDAF 2.02 conformance. While conformance with UPDM 2.1 Core and DoDAF-specifics should greatly facilitate conformance with DoDAF 2.02, each tool vendor is still responsible for the tool's ultimate conformance with the documented architecture framework.
    Compliance with UPDM 2.1 Profile including metadata should assist the tool vendor in adhering to DoDAF 2.02 because the UPDM 2.1 Core and DoDAF-specific metadata models in UPDM 2.02 adhere to the metadata model inherent in DoDAF 2.02 Conceptual and Logical data models. In developing the UPDM 2.1, domain meta-modelers have also consulted the corresponding Physical data model in DoDAF 2.02 to resolve questions of general conformance with enterprise-level architectural elements. Nevertheless, tool vendors are advised to consult DoDAF Version 2.02 before claiming DoDAF 2.02 compliance.
    The DoD-CIO has clarified in a Decision Brief of 12 Jan 11 that it does not expect UPDM 2.1 to export models in PES, nor to provide an implementation of 4D (geo-spatial-temporal modeling) including a global implementation of Whole-Part and Temporal-Whole-Part for all UPDM elements (classes/objects).
    The UPDM Profile to DoDAF Metamodel Compliance Matrix has been published as non-normative Annex C of the specification to aid tool vendors in their claims to DoDAF Level 2 Conformance. This matrix should also facilitate upgrades to Level 3 and 4 of DoDAF Conformance in future versions of UPDM.

    Append the following addition to section 3.3 after the additions above.

    DoDAF 2.02 Conformance Level Three (DoDAF L3).

    UPDM 2.0 conforms with Level Three (3) as specified by DoDAF 2.02.
    The DoDAF Levels of conformance are:

    DoDAF Level 1 is conceptual conformance.
    DoDAF Level 2 is logical data model conformance.
    DoDAF Level 3 is physical data model conformance.
    DoDAF Level 4 is syntactic/ontology conformance with a full spatial-temporal (4-dimensional) ontology.

    Note: DoDAF Levels are not to be confused with UPDM Levels.

    Note: DoDAF Levels are cumulative, that is, Level 3 physical data model conformance builds upon Level 2, logical data model conformance.
    One cannot achieve DoDAF Level 3 without achieving DoDAF Levels 1 and 2.

    As evidence of conformance at the logical data model level (DoDAF Level 2), we refer the reader internally to Annex C.1, ""DoDAF-DM2, UPDM, and MODAF Mapping"". For DoDAF Level 3, we cite the proven exchanges among UPDM 2.0 implementations at the physical layer using the OMG XML Model Interchange (XMI) specification. Tools that conform with UPDM Level 0 or UPDM Level 1 must be able to make this XMI interchange.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Performer is defined both as an alias and a specialization of Node

  • Key: UPDM2-31
  • Legacy Issue Number: 17449
  • Status: closed  
  • Source: CSC ( Peter Kelley)
  • Summary:

    The text relating to Performer in section 8.3.1.4.3.1.1 states that Performer is "An alias for Node in DoDAF" however Figure 8.165 shows it as a specialization of Node and the Generalizations section states that Node is a generalization of Performer.

    These statements are in conflict.

  • Reported: UPDM 2.0 — Tue, 19 Jun 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Modify text by removing reference to performer being an Alias of Node.
    Please not heading indices are likely to change due to the model based nature of the document but they do give an indication of where to find the text

    Change text:

    8.3.1.4.3.1.1 Performer
    MODAF:NA
    DoDAF: Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability. An alias for Node in DoDAF.

    To updated text

    8.2.1.2.3.1.1 Performer
    MODAF:NA
    DoDAF: Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

No definition for PhysicalResource

  • Key: UPDM2-30
  • Legacy Issue Number: 17448
  • Status: closed  
  • Source: CSC ( Peter Kelley)
  • Summary:

    The entity PhysicalResource is mentioned in the text in 2 places and in Figure 8.133 but is not defined anywhere.

  • Reported: UPDM 2.0 — Tue, 19 Jun 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 55 and 56 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing TOC entries

  • Key: UPDM2-29
  • Legacy Issue Number: 17447
  • Status: closed  
  • Source: CSC ( Peter Kelley)
  • Summary:

    The TOC fails to include references to many of the UPDM entities defined in the document. The PDF bookmarks also omit these entries. The TOC defines ProjectMilestoneRole on page 39 and the next entry is UPDM L1::UPDM l0::DoDAF on page 161. Even though these elements are at similar document heading levels one is an entity definition and the other is a collection of entities. ProjectMilestoneRole actually ends on page 40 and UPDM L1::UPDM::L0::Core::AllElements begins on page 40 with no TOC entry.

    This issue makes the specification extremely difficult to navigate with as there is no overview of the structure and finding a particular element requires searching which can bring up many irrelevant mentions of common words.

    To fix this problem either the TOC needs to be regenerated with entries down to heading level 6 or below or the sections need to be restructured so that heading level corresponds to the level of detail.

  • Reported: UPDM 2.0 — Tue, 19 Jun 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Due to the final edited format of the specification document, we cannot regenerate the table of content entries. It might be possible to complete this change in final editing which is outside the scope of the RTF.

    Therefore it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

change stereotype extensions (base_*) marked as "private" to "public"

  • Key: UPDM2-28
  • Legacy Issue Number: 17400
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Graham Bleakley, graham.bleakley@uk.ibm.com

    status critical

    I see that a huge list of stereotype extensions (base_*) that are marked as "private"
    These "private" extensions are preventing the application of the stereotypes
    For instance on the valid.xmi of testcase B, I cannot apply Perfomer stereotype (line 65) due to the private visibility of the attribute "base_Class"

    Resolution
    change all stereotype extension visibility in the xmi to "public" to enable the application of those steretypes.

  • Reported: UPDM 2.0 — Thu, 31 May 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    closed in the urgen issue resolution process

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Attribute URI/URL should be renamed and made optional

  • Key: UPDM2-27
  • Legacy Issue Number: 17361
  • Status: closed  
  • Source: PTC ( Simon Moore)
  • Summary:

    On behalf of the OMG MIWG:

    There is an attribute on UPDMElement (which many things derived from) called "URL/URI ". This contains a slash character and space (on the end) which are illegal as an XML name, but no xmiName override is provided. Also it should be optional since not all objects would require them for the model to be valid.

    This is blocking validation of XMI files and therefore requires some kind of urgent solution in UPDM 2.0.1.

    Our proposal would be to change the name to "URI" and make it optional.

  • Reported: UPDM 2.0 — Tue, 8 May 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    closed in the urgen issue resolution process

  • Updated: Fri, 6 Mar 2015 20:59 GMT

some properties are wrongly marked as mandatory

  • Key: UPDM2-26
  • Legacy Issue Number: 17360
  • Status: closed  
  • Source: PTC ( Simon Moore)
  • Summary:

    This is raised on behalf of the OMG Model Interchange Working Group as it affects validation of XMI files which use UPDM.

    I noticed that the MIWG's current reference xmi for UPDM testing fails some checks on the NIST validator because mandatory string properties are not specified.

    For example, in the UPDM 2.0 spec ArchitecturalDescription's 'recommendations' is defined as:
    • recommendations : String[1] - States the recommendations that have been developed based on the architecture effort. Examples include recommended system implementations, and opportunities for technology insertion.

    Whereas in UPDM 1.1 it was:
    • recommendations : String[*] - States the recommendations that have been developed based on the architecture effort. Examples include recommended system implementations, and opportunities for technology insertion.

    It is not marked with change bars in the UPDM 2.0 spec, which might indicate that this change was not intended, and the example above certainly doesn't have an obvious need to be mandatory. As far as I know, UML and SysML have avoided making properties like this mandatory.

    So, was this and others like it an intended change? Were the ones already in UPDM 1.1 intended to be mandatory?

  • Reported: UPDM 2.0 — Tue, 8 May 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 37 and 38 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Confusion in type for Project status

  • Key: UPDM2-37
  • Legacy Issue Number: 17616
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    The AcV-2 is used to report on the timelines of existing «ActualProject» elements and the status of its «ProjectTheme»s. The information for these reports is created mainly on the AcV-3 diagrams.
    The DMM and profile diagrams differ in the naming of the project status type. The DMM calls it ProjectThemeKind and the profile calls it StatusIndicators.

    Modify ProjectThemeKind in DMM to be StatusIndicators
    Replace DMM Acv-2 with modfied version

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Modify ProjectThemeKind in DMM to be StatusIndicators
    Replace DMM Acv-2 with modified version

  • Updated: Fri, 6 Mar 2015 20:59 GMT

DoDAF users are upset using MODAFRoleKind property on the ResourceRole

  • Key: UPDM2-36
  • Legacy Issue Number: 17580
  • Status: closed  
  • Source: No Magic, Inc. ( Aurelijus Morkevicius)
  • Summary:

    DoDAF users are upset using MODAFRoleKind property on the ResourceRole.
    They found the name misleading. The suggestion I've been given from
    Lockheed Martin guys is to simply have RoleKind instead of
    MODAFRoleKind. It also affect the enumeration the property is typed by.

  • Reported: UPDM 2.0 — Wed, 12 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 60 through 64 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Remove model libraries from UPDM 2.0 profile structure

  • Key: UPDM2-35
  • Legacy Issue Number: 17578
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Remove model libraries from UPDM 2.0 profile structure, put them in as model libraries and reference them from the UPDM profile. Corrects issues in XMI

  • Reported: UPDM 2.0 — Tue, 11 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Remove model libraries from UPDM 2.0 profile structure, put them in as model libraries and reference them from the UPDM profile. Corrects issues in XMI

    This change is in the XMI and not reflected in any diagrams or text in the specification, with modified XMI being submitted with the specification.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Activity is an abstract element, it should be concrete

  • Key: UPDM2-34
  • Legacy Issue Number: 17575
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The activity element in UPDM is defined as abstract, for DoDAF 2.0 usage it should be concrete

  • Reported: UPDM 2.0 — Thu, 6 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    In UPDM we deployed subtypes of activities to give a context to the activity types. I.e. we can differentiate between Operational, System or project activities. You cannot do this if all activit elements are activities.

    Therefore it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

By having Exchange Element as a Datatype there is not possible to define the State Machine for it

  • Key: UPDM2-33
  • Legacy Issue Number: 17574
  • Status: closed  
  • Source: No Magic, Inc. ( Aurelijus Morkevicius)
  • Summary:

    By having Exchange Element as a Datatype there is not possible to define the State Machine for it. This is a huge issue for a majority of No Magic's customers

  • Reported: UPDM 2.0 — Thu, 6 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Used to represent changes in state of a data element. Action: change Exchange Element to class, block. Need change in Model and also the SysML mapping table and SysML OCL transformation text.

    Original Text:
    8.3.1.3.1.7.1 ExchangeElement
    MODAF: A relationship specifying the need to exchange information between nodes. DoDAF: NA - this is a specialization of OperationalExchange (DoDAF::Interface).

  • Updated: Fri, 6 Mar 2015 20:59 GMT

properties of EnterprisePhase are wrongly named

  • Key: UPDM2-32
  • Legacy Issue Number: 17551
  • Status: closed  
  • Source: PTC ( Simon Moore)
  • Summary:

    (on behalf of the MIWG)

    comparing the UPDM spec to the UPDM profile (updated for UPDM 2.0.1):

    spec – profile
    ---------------
    goals – goal
    representedBy – desribedBy (note spelling error)
    visions – vision
    statementTasks – statementTask

    MIWG will use the profile names to allow validation.

  • Reported: UPDM 2.0 — Tue, 14 Aug 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Missed a change in the model, this should be corrected when we update with the new model
    Update the Attributes section for section 8.3.1.3.5.1.4 EnterprisePhase from this

    Attribute
    The following are attributes for EnterprisePhase:
    • endDate : ISO8601DateTime[1] - The time and date at which the Phase ends.
    • fulfills : Mission[*] -
    • goals : EnterpriseGoal[*] - The Goal towards which this Phase is directed and is in support of.
    • RepresentedBy : ArchitecturalDescription[*] -
    • startDate : ISO8601DateTime[1] - The time and date at which the Phase starts.
    • statementTasks : EnduringTask[*] - Collection of statement tasks.
    • visions : EnterpriseVision[1] - The Vision towards which this Phase is directed and is in support of.
    To this
    Attributes

    The following are attributes for EnterprisePhase:

    o desribedBy : ArchitecturalDescription[*] - The EnterprisePhase described by an ArchitecturalDescription.

    o endDate : ISO8601DateTime[0..1] - The time and date at which the Phase ends.

    o fulfills : Mission[*] - EnterprisePhases associated with a Mission.

    o goal : EnterpriseGoal[*] - The Goal towards which this Phase is directed and is in support of.

    o startDate : ISO8601DateTime[0..1] - The time and date at which the Phase starts.

    o statementTask : EnduringTask[*] - Collection of statement tasks.

    o vision : EnterpriseVision[0..1] - The Vision towards which this Phase is directed and is in support of.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

IndividualPersonRole is missing from the spec, but has references to it

  • Key: UPDM2-49
  • Legacy Issue Number: 17628
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    IndividualPersonRole is missing from the Official spec. Missing, but referred to in mapping tables. IndividualPerson is replaced by IndividualPersonRole

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Remove IndividualPerson section and add IndividualPersonRole
    Remove the following section from the specification
    See pages 90/91 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section on GeoPoliticalExtentTypeKind is missing

  • Key: UPDM2-48
  • Legacy Issue Number: 17627
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Section on GeoPoliticalExtentTypeKind is missing. Should be after GeoPoliticalExtentKind. Missing, although referred to in Table C.1 - DoDAF-DM2, UPDM, and MODAF Mapping.

    Resolution:
    Add the following text after the section on GeoPoliticalExtentKind:

    8.4.2.4.2 GeoPoliticalExtentTypeKind
    Enumeration of kinds of geopolitical extent type, derived from DoDAF, used to support the geoPoliticalExtentTypeKind tag of the GeopoliticalExtentType stereotype.
    • Enumeration Literals
    The following are enumeration literals for Environment:
    CountryType - Powertype Of Country.
    FacilityType - Powertype Of Facility.
    GeoFeatureType - Powertype Of GeoFeature.
    InstallationType - Powertype Of Installation.
    OtherType - Other GeoPoliticalExtentType kind that is not on the enumerated list.
    RegionOfCountryType - Powertype Of RegionOfCountry.
    RegionOfWorldType - Powertype Of RegionOfWorld.
    SiteType - Powertype Of Site.

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Add the following text after the section on GeoPoliticalExtentKind:

    8.4.2.4.2 GeoPoliticalExtentTypeKind
    Enumeration of kinds of geopolitical extent type, derived from DoDAF, used to support the geoPoliticalExtentTypeKind tag of the GeopoliticalExtentType stereotype.
    • Enumeration Literals
    The following are enumeration literals for Environment:
    CountryType - Powertype Of Country.
    FacilityType - Powertype Of Facility.
    GeoFeatureType - Powertype Of GeoFeature.
    InstallationType - Powertype Of Installation.
    OtherType - Other GeoPoliticalExtentType kind that is not on the enumerated list.
    RegionOfCountryType - Powertype Of RegionOfCountry.
    RegionOfWorldType - Powertype Of RegionOfWorld.
    SiteType - Powertype Of Site

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Details is missing, even though there are references to it

  • Key: UPDM2-47
  • Legacy Issue Number: 17626
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Details is missing, even though there are references to it. See section 8.3.1.3.7.5.2 EntityItem, which has a reference to it. Details needs to be added to the spec.

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 88/89 of dtc/2012-1216 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Resource has been changed to SystemResource

  • Key: UPDM2-46
  • Legacy Issue Number: 17625
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Figure 8.132 Resource is missing class extension.
    Things still refer to Resource in the text in contrast with the diagram See 8.3.1.3.6.4.4 PhysicalArchitecture for an example. There may be others.

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 83 and 85 of dtc/2012-12-16 for detaiols

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Service message has the wrong graphic

  • Key: UPDM2-45
  • Legacy Issue Number: 17624
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Service Message is actually shown as ServiceInteraction. The diagram needs to be corrected.

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 81 and 82 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

PropertyValue should be removed from the UPDM Document

  • Key: UPDM2-44
  • Legacy Issue Number: 17623
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    PropertyValue have been changed to actualpropertyset. It appears on Page 77 figure 8.27. It should be removed as the name has been changed.

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    See pages 95 through 101 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ExchangeItem has been deleted from UPDM and should not be in the document

  • Key: UPDM2-43
  • Legacy Issue Number: 17622
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    ExchangeItem is in the document in Figure 8.10, page 42. We need to remove ExchangeItem from the spec/model.

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 79 through 80 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActualProperty definition missing from document

  • Key: UPDM2-42
  • Legacy Issue Number: 17621
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    The definition of the ActualProperty stereotype is missing, although many things reference it. I believe the name was changed to PropertyValue but not updated in the documentation.

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    This is a duplicate of 17623 regarding PropertyValue.

    Proposed Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Incorrect SV-4 DMM Diagram

  • Key: UPDM2-41
  • Legacy Issue Number: 17620
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    The SV-4 DMM diagram is actually the SV-3. We need to replace it with the proper diagram.

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 76 and 77 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Incorrect AV-1 DMM Diagram

  • Key: UPDM2-40
  • Legacy Issue Number: 17619
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    The DMM diagram is incorrect in the UPDM specification. This is actually the AcV-1 diagram. We need to replace this with the proper diagram.

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 74 and 75 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Conflicting PV-3 diagrams for DMM and Profile

  • Key: UPDM2-39
  • Legacy Issue Number: 17618
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Below, the DMM diagram differs from the profile diagram. The profile diagram reflects solely the elements required for DoDAF, while the DMM diagram reflects a MODAF view and ignores activities

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 72 through 73 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing sequencing capability for DoDAF Project Activities

  • Key: UPDM2-38
  • Legacy Issue Number: 17617
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    DoDAF projects contain activities, similar to tasks on a MS Project diagram. Currently they do not have a time or sequence associated with them, making them problematic for defining a chronological order or sequence. Consequently I cannot see how the can define a project sequence of tasks. For the MODAF AcV-2 we use the date field of the actual project milestone. MS Project tasks can contain sequence dependencies as well as specific start times and durations. The activities will require either a chronological before/after or the creation of an activity diagram for support.

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 68 through 70 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Mislabeled Figure B.9 OV-3 should be OV-2.

  • Key: UPDM2-51
  • Legacy Issue Number: 17630
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    igure B.9 is mislabeled. Figure B.9 - OV-3 should be OV-2. Change title.

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Change title of Figure B.9 - OV-3 to be OV-2.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Remove SystemConnector from Spec

  • Key: UPDM2-50
  • Legacy Issue Number: 17629
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    SystemConnector has been superceded, but is still in the spec. See section 8.3.1.4.5.1.2 SystemConnector. Remove SystemConnector from Spec

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Remove SystemConnector from Spec. See pages 86/87 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT