The element descriptions in Part II have no provision to explain stereotyped relationship. See for example page 30, 7.1.2.6.1 ArchitecturalDescription
Diagram DocumentationIssues for Part 2
Document Issue UPDM (OMG Beta) Jan 2009

Source Manfred Koethe

No Data Available

The SOAML profile is missing from the venn diagram showing how the UPDM L0 and L1 work with respect to UML and SysML
Also SOAML is missing from the package diagram in figure 3 showing how the various profiles are imported and work together.

issue withdrawn by submitter

OMG specifications traditionally list element descriptions in alphabetical order. However, the major sections are kept in a logical order corresponding to the subject of the specification. Unfortunately Annex A (DMM) is alphabetical throughout all levels, which makes it very hard to read. Logically related items are teared apart and presented in a non-logical order. Example: Annex A starts context-less with AcV-1 and AcV-2, while the overarching AcV is introduced pages later under Layers.For the benefit of the reader, Annex A should start with the Layers section, internally ordered in a logical order (i.e. starting with AV), then it is probably ok to keep the detailed sections sorted alphabetically. A repetition of "Figure 1: UPDM Viewpoint Support Illustration" in the intro of Annex A might be helpful for the reader.
Diagram DMM Documentation
Document Issue UPDM (OMG Beta) Jan 2009

Source Manfred Koethe

No Data Available

· This entity also requires further considerations. It seems better placed as either part of the StrategicViews or the OperationalViews. Given the attributes contained it would seem to be very focused on actual operations something that does not actually fit with its name. The fact that the parameters are only strings furthermore makes one question whether it can actually be used to describe something of architectural value.

duplicate of 11973

There are two XMI documents listed for UPDM 1.0:

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

and

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

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

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

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

Will ensure XMI is named and submitted correctly

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

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

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

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

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

Added DoDAF only element SystemPart in Profile and added description

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

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

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

Change constraint text on description of ServiceOperation

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

"elements relating to the XX-xx stereotype "

to

"elements relating to the XX-xx product "

This is a minor issue

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

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

No Data Available

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

Reference latest SoaML profile in UPDM profile in the model

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

No Data Available

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

No Data Available

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

No Data Available

OV-2 & StV-2 Capabilities & Nodes: MODAF was designed with capabilities to have metrics. This forces a number of capabilities to be added at leaf level in StV-2. It has become apparent that this is somewhat unwieldy in real architectures. Strongly recommend that you re-model capabilities to have Measure of Effectiveness attributes (property types - e.g. "max speed", "range", etc.") but no property values in the capability itself. Then, when a node traces to a capability, the tracing relationship can specify the required or actual level of capability for the node. Similarly a CapabilityConfiguration would also specify the level it achieves on it's tracing to the capability. This makes StV-2s much more practical to use and also better reflects a Systems Engineering MoE approach. Although this is not in MODAF, it should be - the current approach in MODAF is quite impractical on larger architectures. If you go this route, it also provides you with a much better way to express environmental conditions that capabilities are expected to deliver under - you can show the environmental conditions against the node, not the capability - i.e. "this node is in the desert and we need it to have these levels of capability in its environment".
Diagram OV-2 / StV-2
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution POTENTIAL SOLUTION:All UPDM Elements support measurements being attached to them - so what's requested in this issue is already supported. This can therefore be rejected.

duplicate of issue13739, voted on in ballot 9

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

Source Ian BaileyModel Futuresian@modelfutures.com

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

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

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

Source Ian BaileyModel Futuresian@modelfutures.com

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

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

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

Source Ian BaileyModel Futuresian@modelfutures.com

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

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

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

Source Ian BaileyModel Futuresian@modelfutures.com

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

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

All of the derived tags require the derivation documenting.
Diagram OV-5 + others
Document Issue UPDM (OMG Beta) Jan 2009

Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale Currently the implementation isn't complete without it.
Resolution: We'll add, as a minimum, a detailed description in English but if possible we will also include OCL.

Add derivation rules next to attributes description

Exchanges should be extended to allow Software and CapabilityConfigurations to be conveyed as well.
Diagram OV-2 / SV-1
Document Issue UPDM (OMG Beta) Jan 2009

Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale You cannot fully model the logistics of an architecture currently.
Resolution TBD. Needs discussion

MaterialExchange will be updated to allow Software and ResourceArtifacts to be attached in the "conveyed" role. A new stereotype, called "ConfigurationExchange" will be added as a specialization of OperationalExchange, with it's "conveyed" role linked to CapabilityConfiguration. This new stereotype will be displayed in all the places that the other OperationalExchanges are.

The description for ConfigurationExchange will be: "CapabilityConfigurations that are exchanged between Nodes".

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

Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

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

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

Source Manfred Koethe

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

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

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

Source Sumeet Malhotra

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

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

Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

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

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

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

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

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

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

Disposition: Closed, no change

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

Source Sumeet Malhotra

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

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

Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

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

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

Disposition: Closed, no change

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

Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

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

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

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

Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

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

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

Current navigability is wrong, same PerformanceMeasurementSet can be applied for only one ConformingElement. It should be 1..*.

closed issue, withdrawn by submitter

7.1.5.2.1 Request: MODAF definition is given as "The mechanism by which a Service communicates." This doesn't exist in MODAF, so no idea where this definition has come from or even what "request" is meant to be. The UPDM definition of "A Request port provides an interaction point for accessing a Resource's capabilities, as defined by the ServiceInterface typing the port. It includes the specification of the work required from another, and the request to perform work by another. The Request is basically a conjugated version of a Service port and as such can use the same ServiceInterface. By adding the Request port to the consumer of the Service, the implementation of a service is kept transparent."…is frankly incomprehensible, which doesn't help.
Diagram SOV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution Change the description to match the SOAML description. We should look at changing this to a summary and a reference to the SOAML specification at a later date.

Change the description to match the SOAML description. We should look at changing this to a summary and a reference to the SOAML specification at a later date.
Merged with issue OMG 13878

Fig104 - ServiceFunction: Not sure why the behaviour approach used before for Op Activity and Function (fig 22) doesn't include ServiceFunction also ?
Diagram SOV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution Phil to have a more detailed look at this.

No Data Available

OV-4 - Person: This was always disallowed by a particularly vocal representative on the MODAF user committee. However, time and time again the need to use it comes up. Sometimes, you want to refer to a specific person (all the time when doing an org chart, in fact, and OV-4 is supposed to do org charts). Suggest this is added and allowed as a possible part under Post - i.e. to show that "Fred" is in the post "President".
Diagram OV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution The concept is what I originally thought ActualPost was for - so I can understand why people may want to mode this. However, a Person shouldn't be a part, it should be an Instance - though I've no idea what you'd instantiate (Post wouldn't make sense). This is too complicated to implement now so we should defer to the next version of UPDM.

Add new element [InstanceSpecification] ActualPerson
Add new element [Class] Person
Add new relationship [Dependency] FillsPost to link ActualPerson and ActualPost.
Add new derived attribute for ActualPost to indicate ActualPersons filling this post.
It makes sense to add this as it gives us a complete mapping to IDEAS. We'll look at incorporating this into the next version of UPDM.

Needlines & Non-Information. There is a potential DoDAF non-compliance here. DoDAF OV-2, 3, 5 show information flows ONLY. No material, energy, etc. If DoD is happy then there is no MOD problem with this.
Diagram OV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution People from the DoD have seen this and haven't come back with any issues about it. People have the option of using them or not using them - processes can be defined by organizations to determine which aspects of UPDM to use.

No Data Available

7.1.4.1.1 Tags on OperationalActivity. Is there a constraint to keep these synched with the activity flows and the nodes? For example, if I move an activity from one node to another, will a UPDM compliant tool flag that the consumed and produced needline elements is no longer valid?
Diagram OV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution The tags are derived so there's no need for any constraints (they're populated dynamically).

No Data Available

7.1.4.1.1 Operational Activity Definition. This definition is wrong. Should be "A logical process, specified independently of how the process is carried out. Note: an OperationalActivity may only be carried out by a logical Node."
Diagram OV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution Update the description as specified.

Update the description as specified.

Fig53 - Logical & Physical. Might be worth subtyping entity into LogicalDataModelEntity and PhysicalDataModelEntity. Should have done this in MODAF, as it seems to confuse people as it is.
Diagram OV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution With the current UPDM implementation, if an Entity created in the OV is exactly the same in the SV, it can be reused (i.e. connected to an InformationElement and a DataElement). If we add subtypes to Entity as suggested, we will be forcing users to create duplicate Entities just because they're in different places. This seems to be too useful to remove at the moment.

No Data Available

Fig51 - Mission & States. Mission is hardly used in MODAF. Not sure we need to describe its states, and even if we did, we could do nothing about them, so seems pointless. Also would be incompatible with MODAF.
OV
UPDM (OMG Beta) Jan 2009

Ian BaileyModel Futuresian@modelfutures.com

Since we are moving Mission into the DoDAF Only section, this doesn't effect a MODAF implementation (see [UPDM_00216 / OMG Issue <tbd>]). For this reason, we'll leave Mission with the ability to have StateMachines.

No Data Available

Fig51 - Entity SubjectOfOperationalState… This is not really correct - an element in a data model cannot be subject to state transitions. Individual InformationElements in the architecture, maybe, but not entities.
Diagram OV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution POTENTIAL SOLUTION:This is how it's modelled in MODAF 1.2. We'll request clarification from Ian Bailey before we decide to change this or not.The Entity has a continuous lifecycle which can be captured as a State. The current feeling is to leave it as it is.

Remove generalization between Entity and SubjectOfOperationalStateMachine.

7.1.4.4.10 Mission: Great care needs to be taken here. DoDAF and MODAF architectures very rarely depict a mission. Mission is coupled into UPDM much more strongly than in MODAF or DoDAF. Suggest it is made completely optional in all cases, or even better, completely removed. It should not be a subject of OV-6 constraints or states either.
Diagram OV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution Ensure that all tags, etc, which relate to Mission have a cardinality that is 0..n, to ensure that they're optional.

Ensure that all tags, etc, which relate to Mission have a cardinality that is 0..n, to ensure that they're optional.

7.1.4.4.6 HighLevelOperationalConceptIt says "Note: a background image may be associated with the HLOC, which is referred to by the backgroundImageURL attribute." This is borrowed from MODAF, but unfortunately UPDM didn't borrow the attribute itself.
Diagram OV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution This was deemed to be implementation specific (as each tool vendor will support this in a different way). We should document this somewhere in the specification and remove the reference to the non-existent tag.

This was deemed to be implementation specific (as each tool vendor will support this in a different way).
We should document this somewhere in the specification and remove the reference to the non-existent tag.

Fig 91 - OrganizationalExchange: Not used anymore in MODAF. This should be ResourceInteraction.
Diagram OV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution Though the name has changed (i.e. now called MovementOfPeople) the relationship still exists in MODAF 1.2. Also, we don't want to reuse SV flows on the OV-2.We should add an alias called MovementOfPeople (as a specialization of OrganizationalExchange) to be consistent with MODAF though.

Though the name has changed (i.e. now called MovementOfPeople) the relationship still exists in MODAF 1.2. Also, we don't want to reuse SV flows on the OV-2.
We should add an alias called MovementOfPeople (as a specialization of OrganizationalExchange) to be consistent with MODAF though.
Graham to check it out

7.1.4.4.11 Needline: Defined as "A requirement that is the logical expression of the need to transfer information among nodes"…which is wrong. A needline is not a requirement - it may represent an existing information exchange capability in an as-is architecture. Also, in UPDM, your needlines don't just carry information. Suggest definition is changed to "The logical expression of the need to transfer information, materiel, people or energy between nodes".
Diagram OV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution Change the UPDM description as specified.

Change the UPDM description as specified.

SV-12 Description: SV12 doesn't mention CapabilityConfigurations and services. Neither does M3. Services are implemented by resources - they need not be CapabilityConfigurations. This is mentioned under Fig140.
Diagram SV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution Update the description to replace the references to CapabilityConfiguration with references to Resource.

Update the description to replace the references to CapabilityConfiguration with references to Resource.

Fig139 InternalDataModel: The physical data model may not be internal (in fact, it usually isn't, as we're talking about military messages mostly). It is known as physical in DoDAF and MODAF and UPDM should reflect this.
Diagram SV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution PhysicalDataModel only exists in MODAF, whereas InternalDataModel only exists in DoDAF.We'll rename InternalDataModel to PhysicalDataModel and then create a new DoDAF alias for InternalDataModel.

PhysicalDataModel only exists in MODAF, whereas InternalDataModel only exists in DoDAF.
We'll rename InternalDataModel to PhysicalDataModel and then create a new DoDAF alias for InternalDataModel.

Fig134 Artifact [FacilityType?]: Can't really tell what this is, as its definition seems to just define it in terms of itself, then nowhere else does it define what is meant by facility. Nor is there a facility element in the model. If it is meant to show when an artefact is a facility, then by all means create a subtype of artefact called facility (in fact this would be quite a good idea).
Diagram SV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution Andrius to investigate where the facilityType tag came from (possibly a DoDAF requirement).

Resolution:
facilityType attribute is removed.
Facility stereotype (subtype of Resource) is added.

Fig129: Shows ServiceInterface realizing capability. This is wrong and needs fixing.
Diagram StV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution Add a new stereotype called AimsToAchieve which extends Abstraction. This will be used to connect ServiceInterfaces and Capabilities together (with ServiceInterface in the Client role and Capability in the Supplier role).

Remove ServiceInterface as possible client for RealizesCapability

EnterpriseGoal: This used to be a part of the EnterpriseVision in MODAF, and we changed it in v1.1. You might want to put it back under EnterpriseVision in UPDM, as it made more sense there.
Diagram StV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution We will leave it where it is so that EnterpriseGoals can be used as part of multiple EnterpriseVisions.

No Data Available

7.1.5.2.2 Service: Under the section title, it says MODAF: "The mechanism by which a Service communicates." Which appears to be a definition for ServicePort, not Service.
Diagram SOV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution The concept of ServicePort is covered by the SOAML Service, so the description was mapped across. We should tweak the description to make it more obvious that the two are the same.

The concept of ServicePort is covered by the SOAML Service, so the description was mapped across. We should tweak the description to make it more obvious that the two are the same.
Merged with issue OMG 13878
Revised Text:
N/A See 13878.

StV-6: There is a problem (MODAF's fault) with the description for StV-6. It is supposed to be a mapping between capabilities and doctrinal tasks (StandardOperationalActivity). UPDM should reflect the true intent of StV-6. OperationalActivities which are not StandardOperationalActivities are not allowed in StV-6.
Diagram StV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution Remove OperationalActivity from the StV-6 product diagram and change the text for StV-6 to remove all references to OperationalActivities.

Remove OperationalActivity from the StV-6 product diagram and change the text for StV-6 to remove all references to OperationalActivities.

EnterpriseGoal-Capability: Useful to have a tracing from the goal to the capabilities that help deliver that goal.
Diagram StV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution Sounds sensible but not essential. We will defer this to the next version of UPDM.

No Data Available

Do we need a place (Node or something else) for OperationalActivities to take place?The same for Functions.
Diagram OV-5
Document Issue UPDM (OMG Beta) Jan 2009

Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

Resolution This is what the Performs relationship is for.

No Data Available

Various properties for InformationExchange (appearing in DoDAF 1.5) should be modelled as Measurements in UPDM. Is it really done intuitively or should we create a class library of some kind?
Diagram OV-3
Document Issue UPDM (OMG Beta) Jan 2009

Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

Resolution: Since these properties could be different for various implementations, we shouldn't include these on the stereotypes as tagged values. Instead, we'll add a section to the non-normative part of the document that describes a potential class library of MeasurementSets that fulfil the current DoDAF/MODAF requirements.

Since these properties could be different for various implementations, we shouldn't include these on the stereotypes as tagged values. Instead, we'll add a section to the non-normative part of the document that describes a potential class library of MeasurementSets that fulfil the current DoDAF/MODAF requirements.
Add new class ExchangeProperties stereotyped <<MeasurementSet>>, add following attributes:
accountability
interoperabilityLevelAchievable
classification
classificationCaveat
criticality
periodicity
protectionDuration
protectionSuspenseCalendarDate
protectionTypeName
timeliness
transactionType
protectionDurationCode
releasability
size
throughput
Add new class InformationAssuranceProperties stereotyped <<MeasurementSet>>, add following attributes:
accessControl
availability
confidentiality
disseminationControl
integrity
nonRepudiationConsumer
nonRepudiationProducer

MODAF Re-Use: In general, this version of UPDM re-uses large swathes of MODAF, and in particular the M3. It needs to be made clear that UPDM is not an entirely original work. In public presentations, features that have existed for a long time in M3 (such as re-use of resources, nodes, etc. in OV-1) have been passed off as innovations made in UPDM, when they are not.
Diagram General
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution POTENTIAL SOLUTION:UPDM is a UML implementation of the MODAF and DoDAF frameworks, and as such it could not have been produced without taking concepts, structures and descriptions, etc, from them. Though it is therefore inferred that MODAF and DoDAF are huge contributors to the submission, it should be made clearer in the documentation.This hi-lights a more general issue that we should ensure that contributing organizations are referenced/acknowledged in the UPDM specification.

UPDM is a UML implementation of the MODAF and DoDAF frameworks, and as such it could not have been produced without taking concepts, structures and descriptions, etc, from them. Though it is therefore inferred that MODAF and DoDAF are huge contributors to the submission, it should be made clearer in the documentation.
We have now ensured that contributing organizations are referenced/acknowledged in the UPDM specification.

Summary MODAF DefinitionsWhere MODAF definitions are given for elements (e.g. OperationalActivity), very old (sometimes even MODAF 1.0) definitions are being used. Each MODAF definition in the document needs to be brought up to date.
Diagram General
Document Issue UPDM (OMG Beta) Jan 2009
Section
Page
Priority High
Source Ian BaileyModel Futuresian@modelfutures.com

Remove definition of UPDM models and then map to M3 and DoDAF element
Merge with UPDM_00275/OMG 13784

Required & Actual: Although not explicitly stated in the UPDM documentation, there is a strong feeling that the UPDM team understand that OV represents requirements and SV solutions in MODAF. This is not the case. MODAF works on a temporal basis. If an architecture is of some future EnterprisePhase then its OV represents a requirement. If it is an as-is architecture, then the OV (esp. OV-2) is used to provide a logicalised representation of an underlying physical architecture. Its purpose is to abstract out any underlying complexity for non-technical stakeholders. An as-is OV-2 is often used to accentuate any problem areas - i.e. to show them in "sharp relief" to stakeholders.
Diagram General
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution POTENTIAL SOLUTION:Within the UPDM group, we understand that the OV is used for defining an abstract representation of the architecture and the SV is used for defining the actual, physical architecture. If the documentation is misleading on this it must be updated. We should ask Ian for some specific examples where he's found the documentation to be misleading.

Within the UPDM group, we understand that the OV is used for defining an abstract representation of the architecture and the SV is used for defining the actual, physical architecture.
Both OV and SV can be required or actual, As-is or to- be. This needs to be added to the documentation.

SV-2 Missing: For all intents and purposes UPDM does not cover SV-2 as it is specified in MODAF, and probably not in DoDAF either. It is important to understand that SV-2 adds a layer of detail below SV-1 - it is not simply a re-drawing of SV-1. A given resource interaction shown in an SV-1 may be implemented using several system port connections in SV-2b.
Diagram SV-2
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution Though this is supported in UPDM, it isn't very obvious. We will make the following changes:Add a new ResourceConnector relationship to go between ResourcePorts.Change ResourceInterfaces to only go between Resources/ResourceRoles (i.e. not Ports).Add a tag to ResourceConnector and ResourceInterface to show which ResourceConnectors "realize" which ResourceInterface. (i.e. add a bi-directional association between the stereotypes)

Add a new ResourceConnector[Connector] relationship to go between ResourcePorts.
Add a tag to ResourceConnector and ResourceInterface to show which ResourceConnectors "realize" which ResourceInterface. (i.e. add a bi-directional association between the stereotypes)

Documentation: The documentation in the spec is pretty inconsistent. Sometimes it tries to document the frameworks (DoDAF and MODAF). Sometimes it documents the profile. Sometimes it tries to document both together…very badly. Suggest UPDM sticks to just defining the profile and refers to the appropriate DoDAF and MODAF documentation. Re-using bits of (often out of date) MODAF documentation in the UPDM spec is confusing and runs the risk of MODAF and UPDM getting out of synch. The previous UPDM spec attempted to "know better" than MODAF and DoDAF, and was binned as a result. Although this version does not, it should avoid trying to specify the usage of the framework and stick to defining the stereotypes.
Diagram General
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

The descriptions were updated to reflect consistent and coherence definitions.

Summary Add the ability for Node to own ServiceOperations
Diagram
Document Issue UPDM (OMG Beta) Jan 2009

Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

Add a constraint to ServiceOperation to specify owner. Remove the constraint from Resource, since it was forcing it to be the only owner of ServiceOperation

FTF Number UPDM_00280
Summary Resource property "actsUpon" needs to be changed, because of the name clash with actsUpon in activity subject.
Diagram
Document Issue UPDM (OMG Beta) Jan 2009

Source Andrius Strazdauskas No Magicandriuss@nomagic.com

Resolution Change the name to functionsUpon.

Change the name to functionsUpon

The term Node needs stronger wording in its definition to separate its meaning between DoDAF and MODAF

Merge with UPDM_00275/OMG 13784

The current connection between InformationElement and EntityItem is broken (since both a Classes, there is no "represented" anymore)"

Create association between InformationElement and EntityItem.
Make the association between DataElement and EntityItem bidirectional.
Change the association end names

Some Service elements have to be substituted with SoaML elements

Make Capability a specialization of SoaML::Capability
Make ServiceInterface a specialization of SoaML::ServiceInterface
Reuse SoaML::ServicePoint instead of Service
Reuse SoaML::RequestPoint instead of Request
Reuse SoaML::Expose to link Capabilities to ServiceInterfaces

Summary Add DataElement as SubjectOfResourceStateMachine. Consistence with OVs is needed
Diagram
Document Issue UPDM (OMG Beta) Jan 2009

Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

Make DataElement a specialization of SubjectOfResourceStateMachine

Fig143 FunctionParameter: This seems to be new. Is this a DoDAF 2.0 feature?
Diagram SV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution This is a UML implementation stereotype so that the inputs and outputs of Functions can be constrained and therefore mapped to the structural constraints on Ports, etc.

No Data Available

Fig141: SV-2 is really just for systems and software, but this diagram shows all resources. It's also just supposed to be about data, not matter and energy. Also, compare with Fig 142, which then goes back to the MODAF approach.
Diagram SV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution Current thinking is that if Resource/Energy flow is allowed on the SV-1, it should also be allowed on the SV-2 - otherwise you loose the ability to have ports showing non-data flow.Talk to Ian to clarifiy.

Add a constraint for ResourceInteraction, specifying that "realization" property values have to be stereotyped by ResourceInterface.

InformationTechnologyStandardCategory shouldn't exist on OperationalConstraint or ResourceConstraint.
Diagram OV-6a / SV-10a
Document Issue UPDM (OMG Beta) Jan 2009

Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

Resolution It looks like a copy and paste error has occurred so we'll remove it.

It looks like a copy and paste error has occurred so we'll remove it.
Remove InformationTechnologyStandardCategory on OperationalConstraint or ResourceConstraint.

SubjectOfOperationalConstraint shouldn't be linked to EntityItem, it should be linked to InformationElement.
Diagram OV-6a
Document Issue UPDM (OMG Beta) Jan 2009

Source Phillip AstleArtisan Software Tools

Rationale This is more consistent with SubjectOfResourceConstraint and makes more sense (EntityItems can be OV and SV).
Resolution POTENTIAL SOLUTION:Remove EntityItem as a specialization of SubjectOfOperationalConstraint and make InformationElement a specialization instead?

Remove EntityItem as a specialization of SubjectOfOperationalConstraint and make InformationElement a specialization instead.

Performer & Activity: Although it is sensible to divide structure and behaviour like this, it is important to specify that only resources can perform functions and only nodes can perform operational activities. Although this is all a bit artificial and arbitrary, it's the way MODAF is structured.
Diagram General
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution POTENTIAL SOLUTION:Peformer and Activity are in UPDM as placeholders for the inclusion of DoDAF 2.0 at a later date (i.e. in a new version). If there are constraints already added to Peforms that limits the client and supplier pairs then this issue can be set to rejected. If not, then we need to add the missing constraints.

No Data Available

ProtocolImplementation: Surely it's the ports on the systems that implement the protocols? At least that's the bit an enterprise architect is interested in. Overall, UPDM seems pretty weak on SV-2.
Diagram SV
Document Issue UPDM (OMG Beta) Jan 2009

Source Ian BaileyModel Futuresian@modelfutures.com

Resolution This matches the MODAF 1.2 specification (SystemPortConnector is a specialization of ProtocolImplementation).

No Data Available

While the description of the profile package structure in "6.4 Profile Structure" is correct, it lacks to explain the combination with SysML for UPDM L1. A diagram in the same style as the L0 package diagrams, showing the connection to SysML is needed to make the context for L1 clear. At present the reader might become confused by Figure 3: L0 and L1 on page xxiv, versus chapter 6.4 Profile Structure, versus Part II, which on the first glance may appear to talk about L1 only.
Diagram Compliance LevelsDefinitionDocumentation P1
Document Issue UPDM (OMG Beta) Jan 2009

Source Manfred Koethe

Change Figure 4 to include SysML and SoaML

Although the word "materiel" is used appropriately in many different locations within the document, in a few places the word "material" needs to be used. For example on Page 21, line 7, the word "material" needs to be used instead of the mis-typed word "materiel".
Diagram Documentation
Document Issue UPDM (OMG Beta) Jan 2009

Source Sumeet Malhotra

Change the word materiel to material in Section 1 Scope at the bottom of page 2.

ServiceOperation, According to the diagram, a ServiceOperation must be owned by one of the derived types of ResourceType, and the "method" meta-property of the operation is a Function (an activity). According to the UML specification, the owner of the behavior specified in the "method" meta-property of an operation must be the same element that owns the operation. The profile descriptions for Function and ResourceType do not discuss the relationship between them, so these relationships that involve a ServiceOperation may not be possible.
Diagram SOV
Document Issue UPDM (OMG Beta) Jan 2009

Source Kevin CornellIBMkcornell@ca.ibm.com

Resolution: Add tag ConcreteBehavior typed by Function to ServiceOperation Remove metaconstraint method to Function from ServiceOperationAction-Architecture team

Add tag ConcreteBehavior typed by Function to ServiceOperation
Remove metaconstraint method to Function from ServiceOperation
Action-Architecture team

ResourcePart is mentioned in the spec
Diagram SV-1
Document Issue UPDM (OMG Beta) Jan 2009

Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale ResourcePart was the old name for the abstract ResourceRole stereotype but the specification didn't get updated.
Resolution Not found.

No Data Available

Role Is mentioned in the spec, but no such stereotype exists.
Diagram OV-4
Document Issue UPDM (OMG Beta) Jan 2009

Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale The composite structure between Posts and Organizations was non-UML in MODAF (i.e. the structure was confused). This got resolved in UPDM to be more OO and this looks like it wasn't reflected in the specification correctly.
Resolution: Remove "Role" from SV-1 diagram description for the profile and DMM.

Remove "Role" from SV-1 diagram description for the profile and DMM.