Issues for UPDM 2.2 Revision Task Force

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 16557: Broken link for issue reporting (updm-2-0-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In the section "OMG�s Issue Reporting Procedure" at the beginning of the UPDM spec, there is a broken link for issue reporting. It is https://www.omg.org/technology/agree-ment.htm and should be https://www.omg.org/technology/agreement.htm (without the dash). There are several other cases where URLs get broken across line boundaries. URLs should be set not to break.

Resolution: This issue was raised against UPDM 1.1 2011-05-01 but issue is still relevant change reference to https://www.omg.org/report_issue.htm Change description in model.
Revised Text: Original Text: OMG�s Issue Reporting Procedure All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page http:// www.omg.org, under Documents, Report a Bug/Issue (https://www.omg.org/technology/agree�ment. htm). Updated Text OMG�s Issue Reporting Procedure All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page https://www.omg.org, under Documents, Report a Bug/Issue (https://www.omg.org/technology/agreement.htm)
Actions taken:
September 17, 2011: received issue
April 1, 2013: closed issue

Issue 16577: It's not possible to show that a resource configuration realizes two or more capabilities at different periods of time (updm-2-0-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Aurelijus Morkevicius, aurelijus.morkevicius(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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).
Revised Text:
Actions taken:
October 3, 2011: received issue
April 1, 2013: closed issue

Issue 16578: Project Sequence should have a tag Sequence Kind (updm-2-0-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Aurelijus Morkevicius, aurelijus.morkevicius(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
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".

Resolution: 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
Revised Text:
Actions taken:
October 3, 2011: received issue
April 1, 2013: closed issue

Issue 16579: capability to assign actual organizational resources to a project in a particular time frame missing (updm-2-0-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Aurelijus Morkevicius, aurelijus.morkevicius(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: see pages 39 through 44 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
October 3, 2011: received issue
April 1, 2013: closed issue

Issue 16580: Increment and out of service milestones do not pair (updm-2-0-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Aurelijus Morkevicius, aurelijus.morkevicius(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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).
Revised Text:
Actions taken:
October 3, 2011: received issue
April 1, 2013: closed issue

Issue 16640: 8.2.1.1.3 and 8.2.1.1.3.1 define ISO8601DateTime (updm-2-0-rtf)

Click here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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
Revised Text:
Actions taken:
October 28, 2011: received issue
April 1, 2013: closed issue

Issue 16641: The ISO8601:2004 is probably a normative reference and should be placed in section 3 (updm-2-0-rtf)

Click here for this issue's archive.
Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com)
Nature: Uncategorized Issue
Severity:
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

Resolution: 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
Revised Text:
Actions taken:
October 28, 2011: received issue
April 1, 2013: closed issue

Issue 16688: Incorrect acknowledgement (updm-2-0-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
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'.

Resolution: 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
Revised Text:
Actions taken:
November 16, 2011: received issue
April 1, 2013: closed issue

Issue 16718: Need to add a conforms to relationship for an element of type Interface to be able to associate a standard with it (updm-2-0-rtf)

Click here for this issue's archive.
Source: MITRE (Dr. Fatma Dandashi, dandashi(at)mitre.org)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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
Revised Text:
Actions taken:
November 18, 2011: received issue
April 1, 2013: closed issue

Issue 16912: Document still references DoDAF v1.5, when it should reference DoDAF V2.02 (updm-2-0-rtf)

Click here for this issue's archive.
Source: MITRE (Dr. Fatma Dandashi, dandashi(at)mitre.org)
Nature: Uncategorized Issue
Severity:
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

Resolution: 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."
Revised Text:
Actions taken:
December 15, 2011: received issue
April 1, 2013: closed issue

Issue 17024: It's very odd and counter-intuitive to have UPDM L0 buried in UPDM L1 (updm-2-0-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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
Revised Text:
Actions taken:
January 20, 2012: received issue
April 1, 2013: closed issue

Issue 17025: 2.1.1: typo: it has RequiresPoint which does not exist in SoaML and I (updm-2-0-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: Update diagram 2.2 ServicePoint, RequestPoint, to be Service and Request. Also update associated text in section 2.1.1.
Revised Text: see pages 25 through 27 of dtc/2012012016 for details
Actions taken:
January 20, 2012: received issue
April 1, 2013: closed issue

Issue 17026: Section 2.1.2 (updm-2-0-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
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"

Resolution:
Revised Text: Change the beginning of section 2.1.2 from Figure 2.2 illustrates that UPDM 2.0 Compliance Level 1 includes everything in Level 0, imports the rest of the SysML sub-profiles and defines constraints that pair together the application of SysML and UPDM 2.0 stereotypes. to Figure 2.2 illustrates that UPDM Compliance level 1 includes everything in Level 0 and imports the SysML profile (with all its subprofiles). As part of UPDM compliance level 1, constraints are defined in UPDM L1 that pair together the application of SysML and UPDM 2.0 stereotypes
Actions taken:
January 20, 2012: received issue
April 1, 2013: closed issue

Issue 17027: Section 8.2.1 (updm-2-0-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
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

Resolution: 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.
Revised Text:
Actions taken:
January 20, 2012: received issue
April 1, 2013: closed issue

Issue 17041: wrong document reference (updm-2-0-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The formal XMI file for UPDM https://www.omg.org/spec/UPDM/20110601/dtc-2011-06-15.xml makes several references to SoaML using the following base URL: https://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.

Resolution: closed in the urgen issue resolution process
Revised Text:
Actions taken:
January 24, 2012: received issue
July 30, 2013: closed issue

Discussion:

ptc/2012-01-15 and ptc/2012-01-16 have been assigned for the missing XMI files

Issue 17042: The namespace to use for UPDM is unclear due to inconsistent values (updm-2-0-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The specification document (front page) says:                  Standard document URL: https://www.omg.org/spec/UPDM/2.0 and Associated Schema Files: https://www.omg.org/spec/UPDM/20110601          The XMI for the profile itself declares:                  xmlns:updm='https://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

Resolution: closed in the urgen issue resolution process
Revised Text:
Actions taken:
January 24, 2012: received issue
July 30, 2013: closed issue

Issue 17095: "Include DoDAF 2.02 Conformance Level Three (L3) Statement" (updm-2-0-rtf)

Click here for this issue's archive.
Source: Independent (Mr. Leonard F. Levine, llvienna2(at)aol.com)
Nature: Uncategorized Issue
Severity:
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

Resolution: 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.
Revised Text:
Actions taken:
February 2, 2012: received issue
April 1, 2013: closed issue

Issue 17206: Figure 7.8: <<metaproperty>> should be changed to <<metaconstraint>> (updm-2-0-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 1, 2012: received issue

Issue 17207: Figure 8.8. uses <<metarelationship>> incorrectly (updm-2-0-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Clarification
Severity: Minor
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>>.

Resolution: see pages 52 and 53 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
March 1, 2012: received issue
April 1, 2013: closed issue

Issue 17259: Need for ServiceInterfaces to be represented as an instance to capture specific ServiceAttributes (updm-2-0-rtf)

Click here for this issue's archive.
Source: International Business Machines (Dr. Graham Bleakley, Ph.D., graham.bleakley(at)uk.ibm.com)
Nature: Uncategorized Issue
Severity:
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).

Resolution:
Revised Text:
Actions taken:
March 20, 2012: received issue

Discussion:

Users are currently creating instances of ServiceInterfaces to define actual ServiceAttibutes.   Another workaround is to use IDEAS concepts of types and individuals for ServiceInterfaces  Another workaround is to use MeasurementSets and ActualMeasurementSet    Proposed Disposition:	Defer

Issue 17263: Concern needs to be added to the AV-1 (updm-2-0-rtf)

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.

Resolution: 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
Revised Text:
Actions taken:
March 20, 2012: received issue
April 1, 2013: closed issue

Issue 17264: Need non-nomative profiles for NAF. DODAF and MODAF views and viewpoints (updm-2-0-rtf)

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.

Resolution: 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
Revised Text:
Actions taken:
March 20, 2012: received issue
April 1, 2013: closed issue

Issue 17265: ResourceConnector.realizedExchange does not have a programmable direction or other context specific data (updm-2-0-rtf)

Click here for this issue's archive.
Source: Siemens (Mr. Daniel Brookshier, daniel.brookshier(at)siemens.com)
Nature: Clarification
Severity: Minor
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.

Resolution: 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
Revised Text:
Actions taken:
March 20, 2012: received issue
April 1, 2013: closed issue

Issue 17277: Instance value and slot use in all UPDM elements that extend InstanceSpecification (updm-2-0-rtf)

Click here for this issue's archive.
Source: Syntell AB (Mr Lars-Olof Kihlstrom, lars-olof.kihlstrom(at)syntell.se)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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
Revised Text:
Actions taken:
March 28, 2012: received issue
April 1, 2013: closed issue

Issue 17278: Mapping to DM2 higher level elements: (updm-2-0-rtf)

Click here for this issue's archive.
Source: Syntell AB (Mr Lars-Olof Kihlstrom, lars-olof.kihlstrom(at)syntell.se)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
March 28, 2012: received issue

Discussion:

Potential need for a capability category tag to capture the powertypes.   It was felt that this should be rejected for this version of UPDM due to the developments going in with respect to the  unification of the various frameworks    Therefore it was decided to defer this issue.     Proposed Disposition:	Deferred

Issue 17290: Use of superSubType, wholePart and WholePartType in DoDAF 2 (updm-2-0-rtf)

Click here for this issue's archive.
Source: Syntell AB (Mr Lars-Olof Kihlstrom, lars-olof.kihlstrom(at)syntell.se)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
April 1, 2012: received issue

Discussion:

We have subset of these rules already in embedded in UPDM.      It was decided to defer this issue based upon developments with the unification of the various frameworks    Proposed Disposition:	Deferred

Issue 17310: Desired Effect needs to be a strategic-level model able element (updm-2-0-rtf)

Click here for this issue's archive.
Source: Siemens (Mr. Daniel Brookshier, daniel.brookshier(at)siemens.com)
Nature: Uncategorized Issue
Severity:
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

Resolution: This is DoDAF 1.5 behavior and is not represented in the same way in DoDAF 2.0. Also if we did do this as a fix it would be quite large and given the timescales involved it was decided to defer it. Proposed Disposition: Deferred
Revised Text:
Actions taken:
April 13, 2012: received issue

Issue 17329: UPDM stereotype name conflict (updm-2-0-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: closed in the urgen issue resolution process
Revised Text:
Actions taken:
April 23, 2012: received issue
July 30, 2013: closed issue

Issue 17360: some properties are wrongly marked as mandatory (updm-2-0-rtf)

Click here for this issue's archive.
Source: PTC (Mr. Simon Moore, simoore(at)ptc.com)
Nature: Revision
Severity: Significant
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?

Resolution: see pages 37 and 38 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
May 8, 2012: received issue
April 1, 2013: closed issue

Issue 17361: Attribute URI/URL should be renamed and made optional (updm-2-0-rtf)

Click here for this issue's archive.
Source: PTC (Mr. Simon Moore, simoore(at)ptc.com)
Nature: Revision
Severity: Critical
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.

Resolution: closed in the urgen issue resolution process
Revised Text:
Actions taken:
May 8, 2012: received issue
July 30, 2013: closed issue

Issue 17400: change stereotype extensions (base_*) marked as "private" to "public" (updm-2-0-rtf)

Click here for this issue's archive.
Source: International Business Machines (Dr. Graham Bleakley, Ph.D., graham.bleakley(at)uk.ibm.com)
Nature: Revision
Severity: Critical
Summary:

Graham Bleakley, [email protected]     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.

Resolution: closed in the urgen issue resolution process
Revised Text:
Actions taken:
May 31, 2012: received issue
July 30, 2013: closed issue

Issue 17401: The Model library in the UPDM profile should be external to the UPDM profile (updm-2-0-rtf)

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

Resolution:
Revised Text:
Actions taken:
June 4, 2012: received issue

Issue 17430: Views should be Normative (updm-2-0-rtf)

Click here for this issue's archive.
Source: Independent (Mr. Leonard F. Levine, llvienna2(at)aol.com)
Nature: Enhancement
Severity: Critical
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.

Resolution: Views and viewpoints are contraversial in terms of how they are defined and there practicality in usage. There is also a lot of conflict with how XMI works what would be required to support this practically, at the moment View and Viewpoint in SysML are impractical to use and the do not relate to how the terms View and Viewpoint are used in DoDAF 2.0/MODAF. This confusion is added to when PES is considered. This issue was deferred on the ground that this issue requires a lot of discussion that goes beyond our current time frame for UPDM 2.1 RTF. Although we have made a start on it. Proposed Disposition: Deferred
Revised Text:
Actions taken:
June 14, 2012: received issue

Issue 17447: Missing TOC entries (updm-2-0-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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.

Resolution: 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
Revised Text:
Actions taken:
June 19, 2012: received issue
April 1, 2013: closed issue

Issue 17448: No definition for PhysicalResource (updm-2-0-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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

Resolution: see pages 55 and 56 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
June 19, 2012: received issue
April 1, 2013: closed issue

Issue 17449: Performer is defined both as an alias and a specialization of Node (updm-2-0-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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.

Resolution: 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.
Revised Text:
Actions taken:
June 19, 2012: received issue
April 1, 2013: closed issue

Issue 17551: properties of EnterprisePhase are wrongly named (updm-2-0-rtf)

Click here for this issue's archive.
Source: PTC (Mr. Simon Moore, simoore(at)ptc.com)
Nature: Revision
Severity: Significant
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.

Resolution: 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.
Revised Text:
Actions taken:
August 14, 2012: received issue
April 1, 2013: closed issue

Issue 17574: By having Exchange Element as a Datatype there is not possible to define the State Machine for it (updm-2-0-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Aurelijus Morkevicius, aurelijus.morkevicius(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
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

Resolution: 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).
Revised Text: see pages 104 and 104 of dtc/2012-12-16 for details
Actions taken:
September 6, 2012: received issue
April 1, 2013: closed issue

Issue 17575: Activity is an abstract element, it should be concrete (updm-2-0-rtf)

Click here for this issue's archive.
Source: International Business Machines (Dr. Graham Bleakley, Ph.D., graham.bleakley(at)uk.ibm.com)
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution: 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
Revised Text:
Actions taken:
September 6, 2012: received issue
April 1, 2013: closed issue

Issue 17578: Remove model libraries from UPDM 2.0 profile structure (updm-2-0-rtf)

Click here for this issue's archive.
Source: International Business Machines (Dr. Graham Bleakley, Ph.D., graham.bleakley(at)uk.ibm.com)
Nature: Revision
Severity:
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

Resolution: 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.
Revised Text:
Actions taken:
September 11, 2012: received issue
April 1, 2013: closed issue

Issue 17580: DoDAF users are upset using MODAFRoleKind property on the ResourceRole (updm-2-0-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Aurelijus Morkevicius, aurelijus.morkevicius(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: see pages 60 through 64 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
September 12, 2012: received issue
April 1, 2013: closed issue

Issue 17616: Confusion in type for Project status (updm-2-0-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Revision
Severity:
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

Resolution: Modify ProjectThemeKind in DMM to be StatusIndicators Replace DMM Acv-2 with modified version
Revised Text: see page 67 of dtc/2012-12-16 for details
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Discussion:

Issue 17617: Missing sequencing capability for DoDAF Project Activities (updm-2-0-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Revision
Severity:
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.

Resolution: see pages 68 through 70 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Issue 17618: Conflicting PV-3 diagrams for DMM and Profile (updm-2-0-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Revision
Severity:
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

Resolution: see pages 72 through 73 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Issue 17619: Incorrect AV-1 DMM Diagram (updm-2-0-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Revision
Severity:
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.

Resolution: see pages 74 and 75 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Discussion:

Resolution:  Replace current ACV-1 diagram in Spec with updated version

Issue 17620: Incorrect SV-4 DMM Diagram (updm-2-0-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Revision
Severity:
Summary:

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

Resolution: see pages 76 and 77 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Discussion:

Issue 17621: ActualProperty definition missing from document (updm-2-0-rtf)

Click here for this issue's archive.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: This is a duplicate of 17623 regarding PropertyValue. Proposed Disposition: Duplicate
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Issue 17622: ExchangeItem has been deleted from UPDM and should not be in the document (updm-2-0-rtf)

Click here for this issue's archive.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: see pages 79 through 80 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Issue 17623: PropertyValue should be removed from the UPDM Document (updm-2-0-rtf)

Click here for this issue's archive.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: See pages 95 through 101 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Issue 17624: Service message has the wrong graphic (updm-2-0-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: see pages 81 and 82 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Issue 17625: Resource has been changed to SystemResource (updm-2-0-rtf)

Click here for this issue's archive.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: see pages 83 and 85 of dtc/2012-12-16 for detaiols
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Issue 17626: Details is missing, even though there are references to it (updm-2-0-rtf)

Click here for this issue's archive.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: see pages 88/89 of dtc/2012-1216 for details
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Issue 17627: Section on GeoPoliticalExtentTypeKind is missing (updm-2-0-rtf)

Click here for this issue's archive.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Uncategorized Issue
Severity:
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.

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
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Issue 17628: IndividualPersonRole is missing from the spec, but has references to it (updm-2-0-rtf)

Click here for this issue's archive.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Remove IndividualPerson section and add IndividualPersonRole Remove the following section from the specification See pages 90/91 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Issue 17629: Remove SystemConnector from Spec (updm-2-0-rtf)

Click here for this issue's archive.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Uncategorized Issue
Severity:
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

Resolution: Remove SystemConnector from Spec. See pages 86/87 of dtc/2012-12-16 for details
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Issue 17630: Mislabeled Figure B.9 OV-3 should be OV-2. (updm-2-0-rtf)

Click here for this issue's archive.
Source: PTC (Mr. Matthew Hause, mhause(at)ptc.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Change title of Figure B.9 - OV-3 to be OV-2.
Revised Text:
Actions taken:
September 21, 2012: received issue
April 1, 2013: closed issue

Issue 18509: PV1 (DoDAF) Attributes Needed (updm-2-0-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
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.

Resolution:
Revised Text:
Actions taken:
February 27, 2013: received issue

Issue 18571: Expand general activity modeling for all UPDM constructs to include representation by action, callBehaviorAction and (updm-2-0-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: MITRE (Ms. Laura E. Hart, lhart(at)mitre.org)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
March 20, 2013: received issue

Issue 18573: Simplify measurements in UPDM (updm-2-0-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: MITRE (Dr. Fatma Dandashi, dandashi(at)mitre.org)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
March 20, 2013: received issue

Issue 18577: PIM Logical Service Specification (updm-2-0-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: nMeta (Mr. Kent Laursen, kent(at)nmeta.us)
Nature: Revision
Severity:
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.

Resolution:
Revised Text:
Actions taken:
March 23, 2013: received issue

Issue 18579: Need of Logical and Physical Services (updm-2-0-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Aurelijus Morkevicius, aurelijus.morkevicius(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
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

Resolution:
Revised Text:
Actions taken:
March 26, 2013: received issue

Issue 18580: Implements Relationship between Exchange Elements (updm-2-0-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Aurelijus Morkevicius, aurelijus.morkevicius(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
March 26, 2013: received issue

Issue 18686: Future Increments of UPDM should not preclude using SBVR for Modeling Vocabularies and Rules (updm-2-0-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mr. Lonnie VanZandt, lonniev(at)gmail.com)
Nature: Enhancement
Severity: Significant
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.

Resolution:
Revised Text:
Actions taken:
April 24, 2013: received issue

Issue 18688: UPDM DoDAF lacks a concept for Service Orchestration (updm-2-0-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mr. Lonnie VanZandt, lonniev(at)gmail.com)
Nature: Enhancement
Severity: Significant
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.

Resolution:
Revised Text:
Actions taken:
April 25, 2013: received issue

Issue 18691: Integrate SysML Requirements and Constraints (updm-2-0-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mr. Lonnie VanZandt, lonniev(at)gmail.com)
Nature: Enhancement
Severity: Significant
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.)

Resolution:
Revised Text:
Actions taken:
May 1, 2013: received issue

Issue 18708: System and PhysicalArchitecture are siblings not descendants (updm-2-0-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mr. Lonnie VanZandt, lonniev(at)gmail.com)
Nature: Revision
Severity: Significant
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.

Resolution:
Revised Text:
Actions taken:
May 13, 2013: received issue

Issue 18718: ProjectSequence is too Restrictive (updm-2-0-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mr. Lonnie VanZandt, lonniev(at)gmail.com)
Nature: Enhancement
Severity: Significant
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.

Resolution:
Revised Text:
Actions taken:
May 15, 2013: received issue

Issue 18725: The <<Property>> stereotype and its properties (updm-2-0-rtf)

Click here for this issue's archive.
Source: PTC (Mr. Simon Moore, simoore(at)ptc.com)
Nature: Revision
Severity: Significant
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).

Resolution:
Revised Text:
Actions taken:
May 20, 2013: received issue

Issue 18738: MapsToCapability relationship is too Restrictive, and ActivityPartOfCapability is redundant (updm-2-0-rtf)

Click here for this issue's archive.
Source: MITRE (Dr. Fatma Dandashi, dandashi(at)mitre.org)
Nature: Enhancement
Severity: Significant
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.

Resolution:
Revised Text:
Actions taken:
May 29, 2013: received issue

Issue 18739: use of Generalization to implement Aliasing (updm-2-0-rtf)

Click here for this issue's archive.
Source: MITRE (Dr. Fatma Dandashi, dandashi(at)mitre.org)
Nature: Enhancement
Severity: Significant
Summary:

Issue 18739:  Name: Fatma Dandashi  Employer: Mitre Corp.  mailFrom: [email protected]  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

Resolution:
Revised Text:
Actions taken:
May 29, 2013: received issue

Issue 18740: Use of Actual vs. Type in PV-1 (updm-2-0-rtf)

Click here for this issue's archive.
Source: MITRE (Dr. Fatma Dandashi, dandashi(at)mitre.org)
Nature: Enhancement
Severity: Significant
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:

Resolution:
Revised Text:
Actions taken:
May 29, 2013: received issue

Issue 18741: CV6, CV-7 and NSOV-3 (updm-2-0-rtf)

Click here for this issue's archive.
Source: MITRE (Dr. Fatma Dandashi, dandashi(at)mitre.org)
Nature: Enhancement
Severity: Significant
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.

Resolution: CV6, CV-7 and NSOV-3, define direct Service to OperationalActivity relationship, enable indirect (transitive) service to capability relationship
Revised Text:
Actions taken:
May 29, 2013: received issue

Issue 18742: Subject of a State Machine (updm-2-0-rtf)

Click here for this issue's archive.
Source: MITRE (Dr. Fatma Dandashi, dandashi(at)mitre.org)
Nature: Enhancement
Severity: Significant
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?

Resolution:
Revised Text:
Actions taken:
May 29, 2013: received issue

Issue 18785: Need of Composition between Enterprise Goals (updm-2-0-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Aurelijus Morkevicius, aurelijus.morkevicius(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
June 20, 2013: received issue

Issue 18839: Why is EnterprisePhase to EnterpriseVision a one to one relationship (updm-2-0-rtf)

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

Resolution:
Revised Text:
Actions taken:
July 31, 2013: received issue

Issue 18840: Introduce roles in SV-1 and allow them to relate back to OV-4 organizations that will provide them (updm-2-0-rtf)

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.

Resolution:
Revised Text:
Actions taken:
July 31, 2013: received issue

Issue 18841: Information flow instantiation (updm-2-0-rtf)

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

Resolution:
Revised Text:
Actions taken:
July 31, 2013: received issue

Issue 18842: There needs to be a distinction between Operational View IEs and Systems View Exchange elements (updm-2-0-rtf)

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.

Resolution:
Revised Text:
Actions taken:
July 31, 2013: received issue

Discussion:

Issue 18843: For UAFP. Include a Data and Information view (DIV) (updm-2-0-rtf)

Click here for this issue's archive.
Source: MITRE (Dr. Fatma Dandashi, dandashi(at)mitre.org)
Nature: Uncategorized Issue
Severity:
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

Resolution:
Revised Text:
Actions taken:
July 31, 2013: received issue

Issue 18844: Why are rules in OV-6a and SV-10a not parsed? (updm-2-0-rtf)

Click here for this issue's archive.
Source: MITRE (Dr. Fatma Dandashi, dandashi(at)mitre.org)
Nature: Uncategorized Issue
Severity:
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).

Resolution:
Revised Text:
Actions taken:
July 31, 2013: received issue

Issue 18845: Why does a user need to build an SOV-3? (updm-2-0-rtf)

Click here for this issue's archive.
Source: MITRE (Dr. Fatma Dandashi, dandashi(at)mitre.org)
Nature:
Severity:
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.

Resolution:
Revised Text:
Actions taken:
July 31, 2013: received issue

Issue 18956: Need to change target of desiredEffect from a state to a new element called effect (updm-2-0-rtf)

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.

Resolution:
Revised Text:
Actions taken:
September 26, 2013: received issue

Issue 18957: modify the term NodeRole so that is more applicable to a Peformer (updm-2-0-rtf)

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.

Resolution:
Revised Text:
Actions taken:
September 26, 2013: received issue

Issue 18958: DoDAF elements need to be identified and added to the various diagrams that represent the views (updm-2-0-rtf)

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.

Resolution:
Revised Text:
Actions taken:
September 26, 2013: received issue