Issues for Mailing list of the Unified Profile for DoDAF and MODAF (UPDM 2.0) Revision Task Force

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

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

Issue 16557: Broken link for issue reporting
Issue 16577: It's not possible to show that a resource configuration realizes two or more capabilities at different periods of time
Issue 16578: Project Sequence should have a tag Sequence Kind
Issue 16579: capability to assign actual organizational resources to a project in a particular time frame missing
Issue 16580: Increment and out of service milestones do not pair
Issue 16640: 8.2.1.1.3 and 8.2.1.1.3.1 define ISO8601DateTime
Issue 16641: The ISO8601:2004 is probably a normative reference and should be placed in section 3
Issue 16688: Incorrect acknowledgement
Issue 16718: Need to add a conforms to relationship for an element of type Interface to be able to associate a standard with it
Issue 16912: Document still references DoDAF v1.5, when it should reference DoDAF V2.02
Issue 17024: It's very odd and counter-intuitive to have UPDM L0 buried in UPDM L1
Issue 17025: 2.1.1: typo: it has RequiresPoint which does not exist in SoaML and I
Issue 17026: Section 2.1.2
Issue 17027: Section 8.2.1
Issue 17041: wrong document reference
Issue 17042: The namespace to use for UPDM is unclear due to inconsistent values
Issue 17095: "Include DoDAF 2.02 Conformance Level Three (L3) Statement"
Issue 17206: Figure 7.8: <<metaproperty>> should be changed to <<metaconstraint>>
Issue 17207: Figure 8.8. uses <<metarelationship>> incorrectly
Issue 17259: Need for ServiceInterfaces to be represented as an instance to capture specific ServiceAttributes
Issue 17263: Concern needs to be added to the AV-1
Issue 17264: Need non-nomative profiles for NAF. DODAF and MODAF views and viewpoints
Issue 17265: ResourceConnector.realizedExchange does not have a programmable direction or other context specific data
Issue 17277: Instance value and slot use in all UPDM elements that extend InstanceSpecification
Issue 17278: Mapping to DM2 higher level elements:
Issue 17290: Use of superSubType, wholePart and WholePartType in DoDAF 2
Issue 17310: Desired Effect needs to be a strategic-level model able element
Issue 17329: UPDM stereotype name conflict
Issue 17360: some properties are wrongly marked as mandatory
Issue 17361: Attribute URI/URL should be renamed and made optional
Issue 17400: change stereotype extensions (base_*) marked as "private" to "public"
Issue 17401: The Model library in the UPDM profile should be external to the UPDM profile
Issue 17430: Views should be Normative
Issue 17447: Missing TOC entries
Issue 17448: No definition for PhysicalResource
Issue 17449: Performer is defined both as an alias and a specialization of Node
Issue 17551: properties of EnterprisePhase are wrongly named
Issue 17574: By having Exchange Element as a Datatype there is not possible to define the State Machine for it
Issue 17575: Activity is an abstract element, it should be concrete
Issue 17578: Remove model libraries from UPDM 2.0 profile structure
Issue 17580: DoDAF users are upset using MODAFRoleKind property on the ResourceRole
Issue 17616: Confusion in type for Project status
Issue 17617: Missing sequencing capability for DoDAF Project Activities
Issue 17618: Conflicting PV-3 diagrams for DMM and Profile
Issue 17619: Incorrect AV-1 DMM Diagram
Issue 17620: Incorrect SV-4 DMM Diagram
Issue 17621: ActualProperty definition missing from document
Issue 17622: ExchangeItem has been deleted from UPDM and should not be in the document
Issue 17623: PropertyValue should be removed from the UPDM Document
Issue 17624: Service message has the wrong graphic
Issue 17625: Resource has been changed to SystemResource
Issue 17626: Details is missing, even though there are references to it
Issue 17627: Section on GeoPoliticalExtentTypeKind is missing
Issue 17628: IndividualPersonRole is missing from the spec, but has references to it
Issue 17629: Remove SystemConnector from Spec
Issue 17630: Mislabeled Figure B.9 OV-3 should be OV-2.

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

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.

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. 

 

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

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

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.  

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

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

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

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

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.

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.

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"

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

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.

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

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

"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

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

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

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

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. 

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. 

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.

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.

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.

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.

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

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.

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?

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.

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. 

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

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.  

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.

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

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.

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

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

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

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 

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.

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

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.

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

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:
Replace current ACV-1 diagram in Spec with updated version

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

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.

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

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

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

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.

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.

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.

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

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

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