Need to change generalisation text for each element from

original text format
• Generalizations
The following are generalization relationships for OrganizationalProjectRelationship:

To, revised text format

· Specializations

The OrganizationalProjectRelationship element is a specialization of:

Rationale Correct text required
Resolution Change format

Replace ActivityPerformableUnderCondition with a Tag

Rationale Reduces the amount fo drawing required to create the
tuple
Resolution Created a tag with the same name on an Activity and
typed by environment

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

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

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

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

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

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

(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.

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.

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.

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.

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.

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

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.

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

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.

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

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

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

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

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).

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.

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

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

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.

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

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

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.

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

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

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

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.

This is a duplicate of 17623 regarding PropertyValue.

Proposed Disposition: Duplicate

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

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

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

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

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

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

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.

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

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

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

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>>.

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

"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

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.

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.

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

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

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."

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.

closed in the urgen issue resolution process

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.

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

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.

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

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

status critical

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

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

closed in the urgen issue resolution process

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.

closed in the urgen issue resolution process

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?

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

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:
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

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.

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

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

closed in the urgen issue resolution process

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

closed in the urgen issue resolution process

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

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.

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

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

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'.

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

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

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

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.

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

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"

No Data Available

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.

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

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

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

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.

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

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.

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).

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.

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).

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 http://www.omg.org/technology/agree-ment.htm and should be http://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.

This issue was raised against UPDM 1.1 2011-05-01 but issue is still relevant change reference to http://www.omg.org/report_issue.htm
Change description in model.

. 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.

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

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".

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

Add SOPES and SWAF to the L1 and L0 diagram, L0 Import Participant and ServiceChannel from SOAML,

Adapt figure 2.2 to add SOPES and SWAF (note this is also part of one of the XMI changes as the majority of the profiles indicated in this diagram need to be changed to packages), Update figure 8.2, section 7.4 as the profile stucture is now very flat and does not need to be explained

Remove section 7.4

7.4 Profile Structure
7.4.1 Top Level
See pages 92 through 94 of dtc/2012-12-16 for details