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

All Issues

  • All Issues
  • Name: updm-2-0-rtf
  • Issues Count: 116

Issues Summary

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

Withdraw UDPM Spec

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

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

  • Reported: UPDM 2.1 — Wed, 24 Aug 2016 22:34 GMT
  • Updated: Tue, 4 Jul 2017 13:09 GMT

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

  • Key: UPDMRTF-39
  • Status: open  
  • Source: Thematix Partners LLC ( Lonnie VanZandt)
  • Summary:

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

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

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

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

  • Reported: UPDM 2.1 — Fri, 20 Dec 2013 19:36 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Figure 8.1 Presents InformationAssuranceProperties Twice

  • Key: UPDMRTF-40
  • Status: open  
  • Source: Thematix Partners LLC ( Lonnie VanZandt)
  • Summary:

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

    One instance of the symbol would suffice.

  • Reported: UPDM 2.1 — Tue, 21 Jan 2014 03:58 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT
  • Attachments:

Profile and Tooling should enforce the Proper Specification of Capabilities

  • Key: UPDMRTF-37
  • Status: open  
  • Source: Thematix Partners LLC ( Lonnie VanZandt)
  • Summary:

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

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

    Rationale from Dave McDaniels:

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

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

  • Reported: UPDM 2.1 — Sat, 14 Dec 2013 20:50 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

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

  • Key: UPDMRTF-38
  • Status: open  
  • Source: Thematix Partners LLC ( Lonnie VanZandt)
  • Summary:

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

    Rationale from Dave McDaniels:

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

  • Reported: UPDM 2.1 — Sat, 14 Dec 2013 22:37 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

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

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

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

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

  • Reported: UPDM 2.1 — Thu, 26 Sep 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

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

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

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

  • Reported: UPDM 2.1 — Thu, 26 Sep 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

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

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

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

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

  • Reported: UPDM 2.1 — Thu, 26 Sep 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

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

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

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

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

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

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

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

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

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

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

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

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Information flow instantiation

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

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

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

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

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

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

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Need of Composition between Enterprise Goals

  • Key: UPDMRTF-26
  • Legacy Issue Number: 18785
  • Status: open  
  • Source: No Magic, Inc. ( Aurelijus Morkevicius)
  • Summary:

    Please enter this issue against UPDM RTF 2.2.

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

  • Reported: UPDM 2.1 — Thu, 20 Jun 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

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

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

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

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Why is EnterprisePhase to EnterpriseVision a one to one relationship

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

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

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

CV6, CV-7 and NSOV-3

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

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

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

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Subject of a State Machine

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

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

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

use of Generalization to implement Aliasing

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

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

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

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

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

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

MapsToCapability relationship is too Restrictive, and ActivityPartOfCapability is redundant

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

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

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Use of Actual vs. Type in PV-1

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

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

    Profile:

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

PV1 (DoDAF) Attributes Needed

  • Key: UPDMRTF-9
  • Legacy Issue Number: 18509
  • Status: open  
  • Source: omg.org ( OMG System User)
  • Summary:

    In the current DoDAF Project Viewpoints (PV1) the project element has a start date and an end date. Those attributes are not sufficient for the US JCIDS process. In the incremental development process described by JCIDS, we have increments, blocks and spirals. In the main we don't measure our programs in absolute start and stop dates but rather where they fall in the relative JCIDS process, priority and lifecycle. Start dates are usefull but with a 20-30 year lifecylce, the stop date is not as useful. Having these attributes (increment:string, block: int and spiral:int) in the Project Element would allow us to trace requirements and capability sets to the proper increment, block or spiral.

  • Reported: UPDM 2.0.1 — Wed, 27 Feb 2013 05:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

ProjectSequence is too Restrictive

  • Key: UPDMRTF-19
  • Legacy Issue Number: 18718
  • Status: open  
  • Source: Thematix Partners LLC ( Lonnie VanZandt)
  • Summary:

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

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

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

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

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

  • Reported: UPDM 2.1 — Wed, 15 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

The <> stereotype and its properties

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

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

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

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

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

    These impact XMI (see MIWG TC22).

  • Reported: UPDM 2.1 — Mon, 20 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

System and PhysicalArchitecture are siblings not descendants

  • Key: UPDMRTF-18
  • Legacy Issue Number: 18708
  • Status: open  
  • Source: Thematix Partners LLC ( Lonnie VanZandt)
  • Summary:

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

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

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

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

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

  • Reported: UPDM 2.1 — Mon, 13 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Integrate SysML Requirements and Constraints

  • Key: UPDMRTF-17
  • Legacy Issue Number: 18691
  • Status: open  
  • Source: Thematix Partners LLC ( Lonnie VanZandt)
  • Summary:

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

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

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

  • Reported: UPDM 2.1 — Wed, 1 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

UPDM DoDAF lacks a concept for Service Orchestration

  • Key: UPDMRTF-16
  • Legacy Issue Number: 18688
  • Status: open  
  • Source: Thematix Partners LLC ( Lonnie VanZandt)
  • Summary:

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

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

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

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

  • Reported: UPDM 2.1 — Thu, 25 Apr 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

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

  • Key: UPDMRTF-15
  • Legacy Issue Number: 18686
  • Status: open  
  • Source: Thematix Partners LLC ( Lonnie VanZandt)
  • Summary:

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

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

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

  • Reported: UPDM 2.1 — Wed, 24 Apr 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Implements Relationship between Exchange Elements

  • Key: UPDMRTF-14
  • Legacy Issue Number: 18580
  • Status: open  
  • Source: No Magic, Inc. ( Aurelijus Morkevicius)
  • Summary:

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

  • Reported: UPDM 2.1 — Tue, 26 Mar 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Need of Logical and Physical Services

  • Key: UPDMRTF-13
  • Legacy Issue Number: 18579
  • Status: open  
  • Source: No Magic, Inc. ( Aurelijus Morkevicius)
  • Summary:

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

  • Reported: UPDM 2.1 — Tue, 26 Mar 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

PIM Logical Service Specification

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Reported: UPDM 2.1 — Sat, 23 Mar 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Simplify measurements in UPDM

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

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

  • Reported: UPDM 2.1 — Wed, 20 Mar 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

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

  • Key: UPDMRTF-10
  • Legacy Issue Number: 18571
  • Status: open  
  • Source: MITRE ( Laura Hart)
  • Summary:

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

  • Reported: UPDM 2.1 — Wed, 20 Mar 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Views should be Normative

  • Key: UPDMRTF-8
  • Legacy Issue Number: 17430
  • Status: open  
  • Source: Office of the Secretary of Defense ( Leonard Levine)
  • Summary:

    While the proper implementation of a UPDM 2.0 Profile assures successful exchange of data models, the exact content of the VIEWS remain non-normative. There needs to be a definition of the minimum data elements to support each view as well as optional data elements. The UPDM RTF Group needs to discuss whether all (52?) Views need to be made NORMATIVE, how to support Optional data, and how to support the required USER-DEFINED VIEWS.

  • Reported: UPDM 2.0 — Thu, 14 Jun 2012 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

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

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

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

  • Reported: UPDM 2.1 — Mon, 4 Jun 2012 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

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

  • Key: UPDMRTF-6
  • Legacy Issue Number: 17310
  • Status: open  
  • Source: Siemens ( Daniel Brookshier)
  • Summary:

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

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

    The sequence is as follows:

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

  • Reported: UPDM 2.1 — Fri, 13 Apr 2012 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Use of superSubType, wholePart and WholePartType in DoDAF 2

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

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

  • Reported: UPDM 2.1 — Sun, 1 Apr 2012 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Mapping to DM2 higher level elements:

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

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

  • Reported: UPDM 2.1 — Wed, 28 Mar 2012 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

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

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

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

  • Reported: UPDM 2.1 — Tue, 20 Mar 2012 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Figure 7.8: <> should be changed to <>

  • Key: UPDMRTF-2
  • Legacy Issue Number: 17206
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Figure 7.8 uses <<metaproperty>> where it means <<metaconstraint>>

  • Reported: UPDM 2.0 — Thu, 1 Mar 2012 05:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Specification lacks Hyperlinks for references to Model Element Names

  • Key: UPDMRTF-1
  • Status: open  
  • Source: Thematix Partners LLC ( Lonnie VanZandt)
  • Summary:

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

  • Reported: UPDM 2.1 — Mon, 9 Dec 2013 22:49 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:18 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

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

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:09 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

lacking clause and number heading

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:08 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

unify representation style for inheritance

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

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:05 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

missing description for associations

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:04 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

missing class definitions

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:02 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

pacakge partitioning not clear

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:45 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

DMM is non-normative but appears to be nomative

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

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

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

    Response,
    add colour coding legend and explanations.

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:43 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT
  • Attachments:

odd reference to UPDM RFC

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

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:41 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

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

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:39 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

DOTMLP should be DOTMLPF.

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

    Table 5.1 modify DOTMLP to DOTMLPF

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:39 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

It is much to easy to rely on reference documents

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:38 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

Confusing conformance/compliance statements re DoDAF 2.o2

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:37 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

Don’t separate the “Normative Reference” clause.

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

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

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:34 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

Existing ISO standards should be mentioned.

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

    Add these references to section 3

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:33 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

IS0, TC154 should be ISO/TC154.

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

    text should be

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:32 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

The format of normative references don't meet ISO format

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:30 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

modify reference to UML 2.3 to UML 2.4.1

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:29 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

The last bullet point is broken.

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

    Action:- Modified the bullet

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:28 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

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

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

    Action:- We modified text in the scope section.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:25 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

Notation on Diagram 2.1 not clear

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:24 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT
  • Attachments:

Figure is a little grainy.


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

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

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:26 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

missing definition for NAF in glossary of terms

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

    Add the definition for NAF in clause 5.

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:21 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

Objection to scope of UPDM fro ISO

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:20 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

Figure number is incorrect in Subpart 1.

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

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

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:15 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

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