Unified Profile for DoDAF and MODAF Avatar
  1. OMG Specification

Unified Profile for DoDAF and MODAF — All Issues

  • Acronym: UPDM
  • Issues Count: 24
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UPDM-771 UPDM XMI documents misnamed UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-770 UPDM XMI contains properties with incorrect lower values UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-769 Need to make SubSystemPart part of the DoDAF resources model UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-768 no ability in UPDM to define internal flows to a system or node (inside a swim lane in OV-5 or Sv-4). UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-767 Constraint to be fixed UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-766 miswording on a number of diagram titles for products UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-765 itemFlow stereotype UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-761 <> has tag called carriedExchange that is type of <> UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-763 current UPDM documentation and XMI is not in line with the submitted SOAML XMI and documentation UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-762 <> UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-764 Elements used by UPDM from SOAML are not the actual elements from the submitted SOAML XMI UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-759 Instances UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-758 Fig118 UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-757 OV-7 UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-756 7.1.1 - Naming of types and individuals. UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-753 The split between Core, DoDAF and MODAF is not intuitive in certain places. UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-752 element descriptions UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-748 In DODAF, OperationalActivities and Nodes have level identifiers. Should we have a derived property for it? UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-747 Test Enterprise. UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-751 inter-operability Requirements and Work Products Implementation UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-750 create detailed step-by-step examples UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-749 LogicalArchitecture - PhysicalArchitecture UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-746 ResourceRole specializations really need simplifying and made compliant with our naming convention UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-745 SubOrganization and Post should be removed and OrganizationRole made concrete in the core UPDM 1.0b1 UPDM 1.0.1 Resolved closed

Issues Descriptions

UPDM XMI documents misnamed

  • Key: UPDM-771
  • Legacy Issue Number: 15380
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    There are two XMI documents listed for UPDM 1.0:

    http://www.omg.org/spec/UPDM/20090501/UPDM-model-library.xmi

    and

    http://www.omg.org/spec/UPDM/20090501/UPDM-profile.xmi

    These are linked incorrectly, that is, UPDM-model-library.xmi appears to contain the profile and UPDM-profile.xmi appears to contain the model library.

    This is significant because the model library references the profile document in a profile application, but because of the misnaming actually references itself making it invalid.

    Also note that the spec PDF, formal/2009-09-01, the above files are listed incorrectly as updm-profile.xmi and model-library.xmi.

  • Reported: UPDM 1.0 — Wed, 21 Jul 2010 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Will ensure XMI is named and submitted correctly

  • Updated: Fri, 6 Mar 2015 23:30 GMT

UPDM XMI contains properties with incorrect lower values

  • Key: UPDM-770
  • Legacy Issue Number: 15379
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    There are a number of properties and possibly extension ends in both the model library xmi and the profile xmi that contain the following:

    <lowerValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="..." visibility="public" value="*"/>

    This isn't valid. Lower values need to be integers and clearly it also doesn't make sense for the lower bound to be unlimited. Almost certainly these ought to be uml:LiteralInteger instances with value="0".

  • Reported: UPDM 1.0 — Wed, 21 Jul 2010 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Remove the line relating to the lower value in the XMI if it is 0, if default vaue is not 0 then make appropriate changes. Parser needs to be tweaked. Aurelijus/Tomas needs to be checked when regenerating XMI

  • Updated: Fri, 6 Mar 2015 23:30 GMT

Need to make SubSystemPart part of the DoDAF resources model

  • Key: UPDM-769
  • Legacy Issue Number: 15247
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Description:- To get the proper whole part relationship between System and SystemsNode there is a need for the SubSystemPart to be typed by System and made be able to make it a part of a SystemsNode. The current resources model does not support this unless using the MODAF resource elements

  • Reported: UPDM 1.0 — Wed, 5 May 2010 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Added DoDAF only element SystemPart in Profile and added description

  • Updated: Fri, 6 Mar 2015 23:15 GMT

no ability in UPDM to define internal flows to a system or node (inside a swim lane in OV-5 or Sv-4).

  • Key: UPDM-768
  • Legacy Issue Number: 15170
  • Status: closed  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    There is currently no ability in UPDM to define internal flows (inform elements and data elements internal to a system or node (inside a swim lane in OV-5 or Sv-4). there should be an ability to define such things and to assoc them with the sequence flow inside a swim lane, even though these internal flows are NOT exchanges and do not show up on OV-3 and SV-6

  • Reported: UPDM 1.0 — Fri, 9 Apr 2010 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Add text to OV-5/SV-4 to indicate that ObjectNodes can be used to show information flow between OperationalActivities and SystemFunctions.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Constraint to be fixed

  • Key: UPDM-767
  • Legacy Issue Number: 15148
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    ServiceOperation can be owned only by Resource or Node, but not by ServiceInterface.
    The constraint should be fixed

  • Reported: UPDM 1.0 — Wed, 24 Mar 2010 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Change constraint text on description of ServiceOperation

  • Updated: Fri, 6 Mar 2015 23:15 GMT

miswording on a number of diagram titles for products

  • Key: UPDM-766
  • Legacy Issue Number: 14987
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    title miswording on a number of diagram titles for products
    summary
    a number of the titles for the products in the UPDM documentation need to be changed from

    "elements relating to the XX-xx stereotype "

    to

    "elements relating to the XX-xx product "

    This is a minor issue

  • Reported: UPDM 1.0 — Mon, 18 Jan 2010 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    see pages 27 - 30 of OMG document dtc/2010-12-04

  • Updated: Fri, 6 Mar 2015 23:15 GMT

itemFlow stereotype

  • Key: UPDM-765
  • Legacy Issue Number: 14840
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to UPDM specification, itemFlow stereotype should be applied to
    OperationalExchanges and ResourceInteractions in the UPDM compliance Level
    1. According to SysML, itemFlow conveys flowProperties. SysML specification
    has constraint defined for a flowProperty "A FlowProperty is typed by a
    ValueType, DataType, Block, or Signal." Unfortunately InformationElement,
    Energy and DataElement, according to UPDM specification, do not have L1
    compliant SysML stereotypes defined. So the result is always failing
    constraint.

  • Reported: UPDM 1.0 — Tue, 8 Dec 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

<> has tag called carriedExchange that is type of <>

  • Key: UPDM-761
  • Legacy Issue Number: 14624
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. <<OperationalActivityEdge>> has tag called carriedExchange that is type
    of <<OperationalExchange>>. In contrast to <<OperationalActivityEdge>>,
    <<Function Edge>> has tag called carriedItem that is type of
    <<ResourceInteraction>> Item. Both of Edges (<<OperationalActivityEdge>> and
    <<FunctionEdge>>) should represent the same kind of data, either Exchanged
    Items or Exchanges.

  • Reported: UPDM 1.0 — Fri, 13 Nov 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

current UPDM documentation and XMI is not in line with the submitted SOAML XMI and documentation

  • Key: UPDM-763
  • Legacy Issue Number: 14812
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The current UPDM documentation and XMI is not in line with the submitted SOAML XMI and documentation.
    Service and Request are the terms used in the SOAML submission, UPDM is using RequestPoint and ServicePoint
    This probably affects a number of diagrams

  • Reported: UPDM 1.0 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

<>

  • Key: UPDM-762
  • Legacy Issue Number: 14625
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Dependant on the issue # 1, <<OperationalActivityEdge>> should know both,
    the Operational Exchanges that are realized by the
    <<OperationalActivityEdge>> and the Operational Exchange Items that are
    conveyed by the Operational Exchanges. The same is valid with the
    <<FunctionEdge>>, it should know both, the Resource Interactions that are
    realized by the <<FunctionEdge>> and the Resource Interaction Items that are
    conveyed by the Resource Interactions.

  • Reported: UPDM 1.0 — Fri, 13 Nov 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Elements used by UPDM from SOAML are not the actual elements from the submitted SOAML XMI

  • Key: UPDM-764
  • Legacy Issue Number: 14813
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Elements used by UPDM from SOAML are not the actual elements from the submitted SOAML XMI these need to be the correct SOAML elements once the SOAML is XMI is submitted.

  • Reported: UPDM 1.0 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Reference latest SoaML profile in UPDM profile in the model

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Instances

  • Key: UPDM-759
  • Legacy Issue Number: 13773
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

    Instances: Starting to find requirements for individual facilities, pieces of equipment etc. on quite a few projects now. We have actual location, post, fielded capability, etc. Would be very useful to have instances for artefact as well.
    Diagram SV
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution This is a good idea but it doesn't seem to be essential. We will defer this to the next version of UPDM.

  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    This is a good idea but it doesn't seem to be essential. We will defer this to the next version of UPDM.
    Outside scope of MODAF and DoDAF specs
    Considered in UPDM 2.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Fig118

  • Key: UPDM-758
  • Legacy Issue Number: 13769
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

    Fig118: Probably a good idea to remove all the environment stuff from EnterprisePhase and capability. It doesn't make sense in MODAF, and won't here either. In particular, if you make the changes for MoE as suggested in the General Issues section, this is not needed at all.
    Diagram StV
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution This isn't essential so we'll defer it to the next version of UPDM.

  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    This isn't essential so we'll defer it to the next version of UPDM.
    Took into account in UPDM 2.0
    .
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 22:56 GMT

OV-7

  • Key: UPDM-757
  • Legacy Issue Number: 13754
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

    OV-7. There have been several comments on MODAF OV-7 that it should be possible to relate entities to the things in the real world that they refer to. Might be a good idea to add a dependency called "refersTo" that relates to a ResourceType.
    Diagram OV
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution This is an interesting idea and might be quite useful. I don't know if we have time to add this now though so we will want to defer it to the next version of UPDM.Though this sounds like a simple idea, there could be a lot of additional work required to support this fully. For example, a matrix showing the mapping, decisions to be made about composite Entities and whether Resources are the only thing that should be related, etc.

  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    This is an interesting idea and might be quite useful. I don't know if we have time to add this now though so we will want to defer it to the next version of UPDM. Though this sounds like a simple idea, there could be a lot of additional work required to support this fully. For example, a matrix showing the mapping, decisions to be made about composite Entities and whether Resources are the only thing that should be related, etc.
    Considered in UPDM 2.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 22:56 GMT

7.1.1 - Naming of types and individuals.

  • Key: UPDM-756
  • Legacy Issue Number: 13721
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

    7.1.1 - Naming of types and individuals. Strongly recommend that a consistent naming policy is used for when there are stereotypes representing types and individuals - e.g. Project & ProjectType, ActualOrganisation and OrganisationType. In the second case, the word "actual" is used (this is also the case in MODAF). Strongly recommend following the pattern used in Project & ProjectType, as this is also the naming convention used in IDEAS and DoDAF 2.0.
    Diagram AcV
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution After discussions within the UPDM group, we decided that the important element should be named the most simply - which in most cases is the Class extensions (e.g. Node, Software, Capability, etc). This left us with an Actual prefix for all individuals and a Role suffix for parts. Though all of the name changes weren't in the original submission, once they've all been made consistent it should be more understandable.The MODAF approach didn't seem to be applied consistently. For example, if it's ProjectType and Project, it should be CapabilityType, SoftwareType, CompetenceType, etc, which wouldn't be as intuitive anyway.We should talk to Ian about this.

  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    After discussions within the UPDM group, we decided that the important element should be named the most simply - which in most cases is the Class extensions (e.g. Node, Software, Capability, etc). This left us with an Actual prefix for all individuals and a Role suffix for parts. Though all of the name changes weren't in the original submission, once they've all been made consistent it should be more understandable. The MODAF approach didn't seem to be applied consistently. For example, if it's ProjectType and Project, it should be CapabilityType, SoftwareType, CompetenceType, etc, which wouldn't be as intuitive anyway.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 22:56 GMT

The split between Core, DoDAF and MODAF is not intuitive in certain places.

  • Key: UPDM-753
  • Legacy Issue Number: 13642
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    The split between Core, DoDAF and MODAF is not intuitive in certain places. Some elements in Core required elements from DoDAF/MODAF to be of any use… Some rationalisation is required…TBD - Add specific examples.
    Diagram GENERAL
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    All the elements and constructs should be moved to Core and only aliases kept in the DoDAF/MODAF Only sections. This makes UPDM a more complete profile and keeps the purpose of Core, DoDAF Only and MODAF Only simple. Also, due to feedback from various DoDAF users, it has become apparent that people would like the option to use MODAF concepts in their DoDAF models - ideally with aliases to make the terminology fit with their domains. Unfortunately this is a big change and the impact needs to be investigated thoroughly - therefore this will have to be deferred
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 22:56 GMT

element descriptions

  • Key: UPDM-752
  • Legacy Issue Number: 13612
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

    Summary Throughout all element descriptions: Apparently a lot of text was generated (either by machine or cut-and-paste). However, one size does not fit all! The lead-in text of "Extensions" suggests the wrong (opposite) direction of extension. The current text reads for exmple "The following are extensions for MilestoneSequence:" but should read "The following metaclasses are extended by MilestoneSequence:" This needs to be corrected for all element descriptions in Part II.Similar, the lead-in text for Generalizations is not strictly wrong, but certainly sub-optimal. The current text is rather useless since it doesn't give a clue what is the general and what the specialized element. Maybe some text like: "The following elements are specialized by xyz:" is more adequate.Page 21, 7.1.2.2.4 Performs: The constraints "RealizesCapability.supplier" and "RealizesCapability.client" are not shown in the diagram.In general, Part II suffers from several formatting flaws (due to its generated nature?):Lines like "Generalizations", etc., stand much more out than section headers.Discriminators like "MODAF:" are flowing into the next word without space. For example on Page 24, 7.1.2.4.4 EnvironmentProperty: "MODAF:Asserts that...", should be "MODAF: Asserts that..." Some lines are stretched almost beyond readability.In many constraint descriptions, the initial character of the role name is wrongly capitalized.
    Diagram GeneralDocumentationIssues for Part 2
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Manfred Koethe

  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Changes will be made to the template that is used to produce the document so that the text regarding extensions will be changed from
    The following are extensions for ElementX :
    To
    The following metaclasses are extended by
    ElementX

    A similar approach will be taken with generalizations where they currently read.
    The following are generalization relationships for Element X:
    ElementY
    This will be changed to
    The ElementYZ is a specialization of elements:
    ElementX
    The heading section will change from Generalizations to Specialisations

  • Updated: Fri, 6 Mar 2015 22:56 GMT

In DODAF, OperationalActivities and Nodes have level identifiers. Should we have a derived property for it?

  • Key: UPDM-748
  • Legacy Issue Number: 13583
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    In DODAF, OperationalActivities and Nodes have level identifiers. Should we have a derived property for it?
    Diagram OV-5
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution: This would be very complicated to implement and describe as Nodes can now be used in different contexts at different levels. We'll defer this until after the FTF.

  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    This would be very complicated to implement and describe as Nodes can now be used in different contexts at different levels.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Test Enterprise.

  • Key: UPDM-747
  • Legacy Issue Number: 13572
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I am reviewing the latest announcement on the UPDM. Looks like the OMG is doing a fine job of getting their hands around the problem. There is one glaring omission, and that's of the Test Enterprise. We have finally dealt with the concept of the acquisition viewpoint, the services viewpoint, etc., but test is noticeably missing. Has there been any discussion of including the test viewpoint? Testing is as important as acquisition and development of system of systems and is often missing in the planning which in turn has presented problems to both acquisition and development professionals. Testing incorporates all levels of planning including strategic, operation and technical.
    Diagram N/A
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Frank C. AlvidrezEdwards Air Forcefrank.alvidrez.ctr@edwards.af.mil

    Rationale Testing in an interoperable environment is a great challenge because of the need to ensure security, compliance with DISA certifications and many other issues that require an architectural view to help execute.
    Resolution: This is outside the scope of UPDM 1.0 and can be looked at for the RFP for the next version of UPDM. Matthew to communicate with Frank and confirm the resolution.

  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Testing in an interoperable environment is a great challenge because of the need to ensure security, compliance with DISA certifications and many other issues that require an architectural view to help execute.
    This is outside the scope of UPDM 1.0 and can be looked at for the RFP for the next version of UPDM. Matthew to communicate with Frank and confirm the resolution.

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 22:56 GMT

inter-operability Requirements and Work Products Implementation

  • Key: UPDM-751
  • Legacy Issue Number: 13606
  • Status: closed  
  • Source: Infinity Technology Incorporated ( Dr. Sumeet S. Malhotra)
  • Summary:

    The key to long-term interoperability can reside in the accuracy and clarity of definitions architectural data and meta-data provided in AV-2. As requested in the RFP, I am not sure the granularity and specificity of these definitions have been mandated properly within this UPDM doc (for textual definitions in the form ofa glossary, a repository of architecture data, their taxonomies, and their metadata (i.e., data about architecture data)), including metadata for tailored products, associated with the architecture products developed. It's the same with OC-7 also. However, I feel this issue can be resolved in an FTF.
    Diagram Inter-operability Requirements and Work Products Implementation
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Sumeet Malhotra

  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Will be considered for UPDM 2.0 documentation as it goes beyond the work of this group.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 22:56 GMT

create detailed step-by-step examples

  • Key: UPDM-750
  • Legacy Issue Number: 13605
  • Status: closed  
  • Source: Infinity Technology Incorporated ( Dr. Sumeet S. Malhotra)
  • Summary:

    Learning from past experiences here at the OMG, I would like to recommend that in order to mitigate the learning curve associated with business end users coming up to speed with the complexities of UPDM, we create detailed step-by-step examples and documentation for the reference implementation that we are using as part of this submission. AN overarching guideline and reference manual such as DoDAF volume I ("Department of Defense Architecture Framework Working Group, "Department of Defense Architecture Framework Version 1.0." Volume I: Definitions and Guidelines, February 9th, 2004." would also do the trick. The UPDM spec is a spec that needs to be adopted by domain users and having clear guidelines established will go a long way in making this a defacto success (as opposed to just a spec released by the OMG).
    Diagram Ease of Adoption and User Friendliness:
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Sumeet Malhotra

  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Supported by proprietary tool training and example models from the tool vendors
    Will be considered for UPDM 2.0
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 22:56 GMT

LogicalArchitecture - PhysicalArchitecture

  • Key: UPDM-749
  • Legacy Issue Number: 13597
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    In UPDM there's something called a LogicalArchitecture which acts as the top item in a Composite OV-2 if you want to model Needlines in a context that's higher than the highest Node. In MODAF (and I think DoDAF) there's also something called a PhysicalArchitecture which is used for the same reason in the SV. Should we add this to remain consistent or does a CapabilityConfiguration cover this well enough that we don't need it?
    Diagram SV-x
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Resolution: Add an abstract context element, that supertypes LogicalContext, PhysicalContext add StrategicContext in UPDM1.1 Consider tuple for relating physical and logicalAction-Architecture teamDefer to UPDM 1.1

  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Add an abstract context element, that supertypes LogicalContext, PhysicalContext add StrategicContext in UPDM1.1 Consider tuple for relating physical and logicalAction-Architecture teamDefer to UPDM 1.1
    Implemented in UPDM 2.0

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 22:56 GMT

ResourceRole specializations really need simplifying and made compliant with our naming convention

  • Key: UPDM-746
  • Legacy Issue Number: 13557
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    The ResourceRole specializations really need simplifying and made compliant with our naming convention. The simplest route is to make a specialized ResourceRole for each Resource specialization and then make the current specializations (e.g. HostedSoftware) a MODAF specialization of the new ones. For example, Artifacts have ArtifactRoles (which is a specialization or ResourceRole) which can be specialized as HostedSoftware in a MODAF model (when typed by Software).
    Diagram SV-1
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale The current implementation is too specific and complicated for the Core package.
    Resolution: Evaluate the complexity of the issue, action on Ron/Wally/Moe to build sample SV-1 structurePotentially should be deferred until after the FTF.

  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    The current implementation is too specific and complicated for the Core package.
    Resolution: Evaluate the complexity of the issue, action on Ron/Wally/Moe to build sample SV-1 structurePotentially should be deferred until after the RTF.
    Not fixed dues to large changes in the MM naming required.
    Consider for UPDM 2.0
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 22:56 GMT

SubOrganization and Post should be removed and OrganizationRole made concrete in the core

  • Key: UPDM-745
  • Legacy Issue Number: 13552
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    SubOrganization and Post should be removed and OrganizationRole made concrete in the core. We should consider adding a couple of aliases to MODAF to capture OrganizationRoles typed by Organizations/Posts.
    Diagram OV-4 - Actual
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale This will simplify the profile and help to maintain the naming convention we agreed upon.
    Resolution: Evaluate the complexity of the issue, action on Action-Ron/Wally to build sample Organisation structure in SV-1/OV-4sWe will implement the change identified in the Issue column at the same time as [UPDM_00021].

  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Discussion:
    Evaluate the complexity of the issue, action on Action-Ron/Wally to build sample Organisation structure in SV-1/OV-4s. We will implement the change identified in the Issue column at the same time as [UPDM_00021].
    Not fixed due to larger changes in the MM required to implement the change
    Consider for UPDM 2.0
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 22:56 GMT