Issues for Mailing list of the UPDM RFC Finalization Task Force

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

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

Issue 13198: Project should be called ActualProject as it's an Instance
Issue 13199: need to change the roles to represent client and supplier
Issue 13200: Enterprise should be called WholeLifeEnterprise.
Issue 13201: metaConstraint between EnterprisePhase and Mission should have its umlRole set to ownedUseCase
Issue 13202: DefinesArchitecture should be a Realization
Issue 13203: ItemInConcept shouldn't be abstract
Issue 13204: ItemInConcept should be called ConceptRole.
Issue 13205: ActualLocation should be called PhysicalLocation.
Issue 13206: ResourceType should be called Resource.
Issue 13207: The Realization relationship between ResourceType and Node should be stereotyped.
Issue 13208: KnownResources as well as NodeRoles should be connectable to Needlines
Issue 13209: The metaConstraint between Needline and Node should have a "/" on the front of "endType".
Issue 13210: The diagram should show the relationship between UPDMElement and ActualMeasurementSet
Issue 13211: OrganizationType should be called Organization.
Issue 13212: ActualOrganizationRelationship
Issue 13213: We shouldn't connect ActualOrganizationRelationship to ResourceInteractions with a realize tag.
Issue 13214: The ActualOrganizationPart stereotype should be called ActualOrganizationRole.
Issue 13215: The OrganizationPart abstract stereotype should be called OrganizationRole
Issue 13216: ActualOrganizationPart stereotype should be connected to OrganizationPart abstract stereotype for the definingFeature
Issue 13217: stereotypedRelationship between Function and OperationalActivity
Issue 13224: Currently all UPDM ports have no ability to connect UPDM connectors - Needline, ResourceInterface.
Issue 13292: Issue with SV-9
Issue 13343: Section 5.1 text is out of context
Issue 13352: The metaConstraint between ResourceInterface and ResourceType should have a "/" on the front of "endType"
Issue 13353: The metaConstraint between Commands and DataElement has an incorrect umlRole
Issue 13354: The metaConstraints from Commands to OrganizationalResource have invalid umlRoles
Issue 13355: add the missing metaConstraints
Issue 13356: Don't see the point in OperationalActivity having a StateMachine
Issue 13357: The Entity, Attribute and EntityRelationship stereotypes are in the wrong Package
Issue 13358: ServiceParameter needs to be shown on this diagram.
Issue 13359: ServiceInteraction is currently extending Interface when it should be extending Interaction
Issue 13360: RealizesCapability used to be a Realization but for some reason has been changed
Issue 13361: The metaConstraint with the umlRole "ownedElement" is wrong
Issue 13362: The metaConstraint with the umlRole "ownedElement" is wrong
Issue 13363: FunctionEdge should be removed from the diagram as it won't be shown in this view.
Issue 13364: The metaConstraint to ServiceParameter from ServiceFunction should be shown on diagram
Issue 13365: The stereotypedRelationship "realizesCapability" should be show fully on the diagram
Issue 13366: We should show ServiceInterface on the SV-1 as the "type" for the Service and Request ports
Issue 13367: The umlRole "conveyedElement" between ResourceInteraction and ResourceInteractionItem is wrong
Issue 13368: CapabilityConfiguration should be shown on this diagram.
Issue 13369: CapabilityConfiguration should be shown on this diagram.
Issue 13370: The diagram currently shows InformationElements when it should be showing DataElements
Issue 13371: Resource subtypes
Issue 13372: Abstract Stereotypes should not Extend Element
Issue 13373: Stereotype names collide with UML keywords (meta-types)
Issue 13374: ResourcePort & ResourceType circular inheritance
Issue 13375: No support for MODAF Problem Domain
Issue 13376: Imported SysML Stereotypes cannot be applied
Issue 13377: Both UPDM and SysML profiles must be applied
Issue 13378: ActualMeasurement can have a circular reference
Issue 13379: Measurement can have a circular reference
Issue 13380: ISO8601DateTime should not extend LiteralString
Issue 13381: Operational Activity action constraints too restrictive
Issue 13382: OperationalActivityEdge constraints too restrictive
Issue 13383: Attribute stereotype has issues with non-navigable associations
Issue 13384: Post constraints are reversed
Issue 13385: Annex C Figure 284 has invalid stereotype
Issue 13386: Annex C diagrams need fixing
Issue 13387: Document layout and section numbering hard to read
Issue 13388: Relationships defined using Property "type" are not intuitive
Issue 13389: Stereotyped Dependencies too limiting
Issue 13390: Confusing notational conventions used in diagrams
Issue 13391: Sequence diagrams cannot show exchanges
Issue 13392: Missing NeedlineExchange meta-constraint
Issue 13393: UsedConfiguraton is misspelled
Issue 13394: ActualProjectMilestone need association link
Issue 13483: ConceptualDataModel just sits in the MODAF package and isn't connected to anything
Issue 13484: Artifact and Artefact
Issue 13485: various identifiers
Issue 13486: OperationalConstraint/ResourceConstraint
Issue 13487: Attributes for Organization - code, military service type, etc.
Issue 13488: OperationalActivity/SysFunction consumes/produces exchanges
Issue 13489: Needline is not realized in SVs.
Issue 13490: ServiceInterfaces should have the ability to have Dependencies between them.
Issue 13491: Should there be a enumeration property on the RealizesCapability element to indicate the level of the realization?
Issue 13492: change ArbitraryConnector to a Dependency and change the name to ArbitraryRelationship
Issue 13493: OntologyReference has invalid specializations.
Issue 13494: Referred location extends different metatypes than its sub-stereotypes.
Issue 13495: allow ServiceOperationActions to be owned by Functions as well as ServiceFunctions on the SV-4
Issue 13496: ServiceOperations need to be owned by Resources as well as ServiceInterfaces
Issue 13497: ServiceParameter needs to have a metaconstraint modelled
Issue 13498: We aren't consistent about the tag definition names used for storing start and end dates
Issue 13499: A DataType can own attributes and operations but not behaviors
Issue 13500: A DataType is not a StructuredClassifier so it cannot have parts
Issue 13501: Missing stereotype
Issue 13502: Commands , This stereotype has extra constraints that do not belong there
Issue 13505: There should be a stereotype called RealizesNode between Node and Resource
Issue 13506: I really don't see the point in Function having a StateMachine
Issue 13507: ArbitraryRelationshipConnector
Issue 13512: ItemInConcept is an abstract stereotype, but is should not be.
Issue 13513: ActualProjectMilestone
Issue 13514: Climate
Issue 13515: OperationalActivity
Issue 13516: Mission
Issue 13517: ActualOrganizationRelationship,
Issue 13518: ServiceInteraction
Issue 13519: ProjectSequence
Issue 13520: OntologyReference
Issue 13521: abstract stereotypes should not extend
Issue 13522: Page 49, 7.1.4.2.1 Attribute, has a wrong constraint
Issue 13523: Why are the Controls.xxxx constraints listed here
Issue 13524: Currently ActualMeasurementSets are not related to time
Issue 13525: ArbitraryRelationshipConnector
Issue 13526: Can a Node host Activities?
Issue 13529: ArbitraryRelationshipConnector is a bit of a long name
Issue 13530: two ways to allocate Operational Activities/Function to Nodes/Resources
Issue 13531: metaConstraint between EntityRelationship and Attribute
Issue 13532: Actual measurement
Issue 13542: milestone sequence stereotype should be shown on SV-8 view
Issue 13547: no type for the ProjectTheme so there's no way to define a value
Issue 13548: ArchitecturalDescriptions aren't supposed to own Views
Issue 13549: There's no metaConstraint from NeedlineExchange to the source/target of the exchange
Issue 13550: PostType should be called Post.Post should be called PostRole
Issue 13551: metaConstraint between ActualOrganizationPart and ActualOrganization
Issue 13553: metaConstraint between ResourceType and ResourceRole
Issue 13554: The "carriedItem" tag between OperationalActivityEdge and NeedlineExchangeItem (NEI) isn't really needed
Issue 13555: There doesn't seem much point in showing Service on the SOV-1
Issue 13556: "abstractBehavior" tagged value between ServiceOperation and ServiceFunction should be shown on the SOV-5 diagram
Issue 13558: There's no metaConstraint from ResourceInteraction to the source/target of the interaction
Issue 13559: ProtocolImplementation
Issue 13560: The "to/from" tagged values for Protocol should have better names
Issue 13561: It'd be more consistent for the "/subject" to "/affectedFunctions" to have the same names as the OV equivalent
Issue 13562: The SystemsNode stereotype is missing
Issue 13563: There should be some additional constraints for the DoDAF/MODAF stereotypes
Issue 13564: Should there be a relationship between Capability and Mission?
Issue 13565: Don't we need System/Artifact specializations, like Network, etc?
Issue 13566: Why there is not potential relationship between InformationElement and SystemDataElement?
Issue 13567: Should there be any link between OperationalActivity and Capability?
Issue 13568: Attributes for Measurements - units of measure, threshold value.
Issue 13569: Responsibility is not covered.
Issue 13570: No Rule for SV.
Issue 13571: No traceability from Node to SV.
Issue 13573: The SOV-1 is inconsistent with other Taxonomy views and should be updated
Issue 13574: It's not clear on the diagram that we expect people will create Provided/Required Interfaces off a ServiceInterface
Issue 13575: ExternalTypes
Issue 13576: ActualLocation is both a DataType and a Class in the spec
Issue 13577: Environment is both a DataType and a Class in the spec.
Issue 13578: LocationType is missing, but is mentioned throughout document.
Issue 13579: Can NodePort be assigned on NodeRole? Now the constraint says only about Node.The same about ResourcePort
Issue 13580: relationship between NeedlineExchange and ResourceInteraction
Issue 13581: UPDM:ScopeContentlanguageaccuracy
Issue 13582: Various properties for InformationExchange (appearing in DoDAF 1.5) should be modelled as Measurements in UPDM
Issue 13585: Do we need a place (Node or something else) for OperationalActivities to take place?The same for Functions.
Issue 13586: In DoDAF Operational Activity has "cost" property.
Issue 13587: Do we need Consumers/Producers for services as in DoDAF?
Issue 13588: Why is the relationship between UPDMElement and Measurements not bi-directional?
Issue 13589: DoDAF had two levels of SV relations - interface and link. UPDM has only one.
Issue 13590: Addition of properties
Issue 13593: CommunicationsLink in DoDAF had properties:capacityinfrastructure technology
Issue 13594: Role Is mentioned in the spec, but no such stereotype exists.
Issue 13595: ResourcePart is mentioned in the spec
Issue 13596: ResourceConnector>> is mentioned in the spec
Issue 13598: ResourceInterface and ResourceInteraction.
Issue 13599: Performs, Two of the constraints do not belong
Issue 13600: EnvironmentalProperty
Issue 13601: Measurement
Issue 13602: SubjectOfOperationalStateMachine
Issue 13603: InformationElement
Issue 13604: ServiceOperation
Issue 13607: material - materiel
Issue 13608: description of the profile package structure in "6.4 Profile Structure"
Issue 13609: conformance sections from chapter 5 and 6 need to be combined into one single conformance clause
Issue 13610: Page 7, 6.6.1 Aliases
Issue 13611: Documentation P2
Issue 13613: Figure 34
Issue 13614: The element descriptions in Part II have no provision to explain stereotyped relationship
Issue 13615: Page 48, 7.1.4.1.6 SubjectOfOperationalStateMachine
Issue 13616: Page 55, 7.1.4.4.1 ArbitraryRelationshipConnector
Issue 13617: Remove unnecessary constraints
Issue 13618: Page 70, 7.1.4.4.19.1.2 ActualOrganizationalResource
Issue 13619: Page 74, 7.1.4.4.19.1.7 Post, the two constraint descriptions are over cross
Issue 13620: Page 75, 7.1.4.4.19.1.8 SubOrganization
Issue 13621: Page 79, 7.1.4.4.19.1.14 RequiresCompetence
Issue 13622: Page 83, 7.1.5.1.1 ServiceFunction
Issue 13623: Page 91, 7.1.5.2.4 ServiceInterface
Issue 13624: Page 115, 7.1.7.1.1 Function
Issue 13625: Page 117, 7.1.7.1.3 FunctionEdge
Issue 13626: Page 136, 7.1.7.4.14 ResourceInterface, please verify the constraint descriptions
Issue 13627: Page 145, 7.1.8.1 Protocol, no diagram here to clarify attributes
Issue 13628: Page 146, 7.1.8.2 ProtocolImplementation, no diagram to help verifying attributes and constraints
Issue 13629: Page 152, 7.1.11.2.1 DataExchange
Issue 13630: Page 158, "Figure 203 - Elements related to the ProjectStatus stereotype" overlays the text
Issue 13631: Page 166, 7.1.14.1.1 ActivitySubject
Issue 13632: Page 167, "Figure 214 - Elements related to the StandardOperationalActivity stereotype" overlays the text
Issue 13633: Page 168, "Figure 217 - Elements related to the Controls stereotype" overlays the text
Issue 13634: Page 169, 7.1.14.3.1 Controls
Issue 13635: Page 169, 7.1.14.3.2 EnergyExchange, the constraint description contains two extraneous constraints
Issue 13636: Page 175, "Figure 225 - Elements related to the EnduringTask stereotype" overlays the text.
Issue 13637: would be nice to have the actual legend in the second paragraph of Annex A
Issue 13639: Some diagrams are very crowded
Issue 13640: Page 184, Figure 235 SOV contains composition ownership problems
Issue 13641: The examples of the SV-9 on the MODAF website don't obviously map to the implementation in MODAF/UPDM
Issue 13643: ServiceInterface currently extends Interface but is also supposed to have provided/required interfaces
Issue 13644: Change InformationElement to extend Class. Review relationship to Entity?
Issue 13647: Milestones
Issue 13648: Association between OperationalActivityEdge and NeedlineExchange should be reversed
Issue 13649: Rename NeedlineExchange to OperationalExchange
Issue 13650: ensure that constraints are placed on the combination of Project, ProjectMilestone and ProjectThemeStatus
Issue 13719: Controls should have the same fixes applied as Commands.
Issue 13720: PhysicalLocation is located in the wrong package/subprofile.
Issue 13726: Fig15 - Inheritance Problem
Issue 13727: Fig15 - ActualProjectMilestone to Project Status and ProjectStatus to ProjectTheme
Issue 13728: Fig15 - Project whole and part and ownedMilestones
Issue 13729: AcV - General Comment.
Issue 13730: Fig21 - Constraint on StructuralPart is wrong
Issue 13731: Fig18 - Mission.
Issue 13732: Fig18 - ArchitecturalDescription
Issue 13734: Fig19 - Ontology Reference
Issue 13735: Fig19 - StereotypeExtension
Issue 13736: Fig19 - Use of Ontology & Generalization
Issue 13737: Fig20 - AV3?
Issue 13738: Fig21 - SameAs.
Issue 13739: Fig27 & Fig28 & Fig29 - Climate, etc.
Issue 13740: 7.1.2.5.1 - ActualMeasurement.
Issue 13741: 7.1.2.5.3 - Measures
Issue 13742: Figure 44 - Title
Issue 13743: Fig44 - NodeType
Issue 13744: Fig44 - RequiresCapability
Issue 13745: Top of Page 37
Issue 13746: Top of Page 37 - "an OV-2 diagram (now OV-2a)"
Issue 13747: Fig44 - ExternalNode.
Issue 13748: Fig44 - NodePort.
Issue 13749: Page 37 - SOA
Issue 13750: Fig45 - NodeChild.
Issue 13751: Fig51 - Entity SubjectOfOperationalState
Issue 13752: Fig51 - Mission & States
Issue 13753: Fig53 - Logical & Physical
Issue 13755: 7.1.4.1.1 Operational Activity Definition
Issue 13756: 7.1.4.1.1 Tags on OperationalActivity
Issue 13757: Needlines & Non-Information
Issue 13758: 7.1.4.4.6 HighLevelOperationalConcept
Issue 13759: 7.1.4.4.10 Mission
Issue 13761: 7.1.4.4.11 Needline
Issue 13762: Fig 91 - OrganizationalExchange
Issue 13763: OV-4 - Person
Issue 13764: Fig104 - ServiceFunction
Issue 13765: 7.1.5.2.1 Request
Issue 13766: 7.1.5.2.2 Service
Issue 13767: EnterpriseGoal
Issue 13768: EnterpriseGoal-Capability
Issue 13770: StV-6
Issue 13771: Fig129
Issue 13772: Fig134 Artifact [FacilityType?]
Issue 13774: Fig139 InternalDataModel
Issue 13775: SV-12 Description
Issue 13776: Fig141
Issue 13777: Fig143 FunctionParameter
Issue 13778: ProtocolImplementation
Issue 13779: Required & Actual
Issue 13781: Performer & Activity
Issue 13782: MODAF Definitions
Issue 13783: MODAF Re-Use
Issue 13784: Documentation
Issue 13785: SV-2 Missing
Issue 13786: SubjectOfOperationalConstraint
Issue 13787: InformationTechnologyStandardCategory
Issue 13805: The term Node needs stronger wording in its definition to separate its meaning between DoDAF and MODAF
Issue 13874: SOAML missing from figure 2 and figure 3 in UPDM spec
Issue 13875: Resource property "actsUpon" needs to be changed
Issue 13876: Add the ability for Node to own ServiceOperations
Issue 13877: Add DataElement as SubjectOfResourceStateMachine.
Issue 13878: SoaML integration
Issue 13879: InformationElement/EntityItem
Issue 13887: DMM and Profile are not synchronized
Issue 13906: Constraints between FunctionAction and FunctionEdge are too limiting
Issue 13907: UPDM Issue: Derived tag updates

Issue 13198: Project should be called ActualProject as it's an Instance (updm-rfc-ftf)

Strictly speaking Project should be called ActualProject as it's an Instance.  ProjectType should then be called Project.Rationale	 To maintain the naming convention we agreed upon.

 ProjectSequence is currently set to extend Dependency but has metaConstraints relating back to InformationFlow.  We need to change the roles to represent client and supplier.	
 The current implementation isn't valid UML.
 Update constraints and diagrams changing them to "client" and "supplier".

Summary 	 Enterprise should be called WholeLifeEnterprise.	


Rationale	 It's inconsistent with MODAF and has confused a lot of people in the past.
Resolution	 We'll rename Enterprise to WholeLifeEnterprise.

 The metaConstraint between EnterprisePhase and Mission should have its umlRole set to ownedUseCase not ownedBehavior.	

 The current role doesn't exist between a Class and a UseCase so the profile is invalid.
 The constraint changes using "useCase" metaproperty.

 DefinesArchitecture should be a Realization (I think it was at one point).	

 ArchitecturalDescriptions are the implementations of the EnterprisePhases, which relates better to a Realization.  We should always use the best fitting UML element.
 We'll change DefinesArchitecture to extend Realization.

We'll change DefinesArchitecture to extend Realization.

 ItemInConcept shouldn't be abstract.	

 We need to be able to apply this stereotype and we can't if it's abstract.
 ItemInConcept is no longer abstract.

To maintain the naming convention we agreed upon.
 ItemInConcept renamed to ConceptRole

To stop confusion that ActualLocation is an instance of Location and maintain the naming convention we agreed upon.

 ResourceType should be called Resource.	
 To maintain the naming convention we agreed upon.

The group agreed that all of these relationships should be stereotyped for clarity.
 We'll reuse ContributesTo for "Resources to Nodes" as well as "Functions to OperationalActivities".  In order to maintain consistency we'll need to add a constraint that Resources can only "contribute to" Nodes, and Functions can only "contribute to" OperationalActivities.

 KnownResources as well as NodeRoles should be connectable to Needlines (i.e. it should be connected to NodeChild).	

 If we don't have this then the flow of exchanges to KnownResources cannot be modelled.
 We'll add Needlines to NodeChild instead of NodeRole so that the full OV-2 description can be implemented.

 The metaConstraint between Needline and Node should have a "/" on the front of "endType". We need to indicate the role we're constraining and with the "/" missing it could be misinterpreted	

 The diagram should show the relationship between UPDMElement and ActualMeasurementSet, not MeasurementSet.	
Diagram OV-3

 The generated table will contain the actual values not the types of values.

 OrganizationType should be called Organization.	
 OV-4 - Actual
 To maintain the naming convention we agreed upon.

 ActualOrganizationRelationship extends an InformationFlow but is connected to ActualOrganizationalResource with client and supplier roles (they're for a dependency).  Also since it's an InformatioFlow it has to convey something and it doesn't.  	
 OV-4 - Actual

 The current roles don't exist between for InformationFlows so the profile is invalid.
 We will keep the extension to InformationFlow but change the roles from "client/supplier" to "informationSource/informationTarget".  We should also add a metaconstraint to the relationship to constrain the "conveyed" data to the same as Commands and Controls.

 We shouldn't connect ActualOrganizationRelationship to ResourceInteractions with a realize tag.	
 OV-4 - Actual


 It's using a tag for something that already exists in UML.
 We will remove the tag definition and use the "realization" role to connect the two InformationFlows together.  There should be a constraint that the ends of the ActualOrganizationRelationship must be instances of the ends of the "realized" Commands/Controls relationship.

 The ActualOrganizationPart stereotype should be called ActualOrganizationRole.	
 OV-4 - Actual

 To maintain the naming convention we agreed upon.
 We'll rename the stereotype.

 The OrganizationPart abstract stereotype should be called OrganizationRole.	
 OV-4 - Actual

 To maintain the naming convention we agreed upon.
 We'll rename the stereotype.

 The ActualOrganizationPart stereotype should be connected to the OrganizationPart abstract stereotype for the definingFeature.	
 OV-4 - Actual

 Slots can only exist in UML if they have an attached definingFeature.  We need to constrain what these features are.
 Information was already in the model. Missing relationship was displayed in OV diagram.

 The <<stereotypedRelationship>> between Function and OperationalActivity should be expressed explicitly (i.e. ContributesTo should be shown on the diagram).	
 OV-4 - Typical

 It's inconsistent with the other product diagrams and should only be used, if anywhere, on the snippet diagrams.
 Particular stereotyped relationship appears on these diagrams:FunctionOperationalActivityOV-4 TypicalSV-1SV-4SV-5We will change these so that all Product diagrams show the stereotype and metaConstraints.  The "element specific" diagrams will still use the stereotypedRelationship notation though.

Suggested resolution: Improve contraints for connectors, so Ports are allowed as connector end types.

Description. Forest is not tied to time, and there is no distinct TechnologyArea concept - modeler have to use Resources, which may be confusing.

Disposition:	See issue 13641 for disposition

This text is out of context. Rename the section heading to "UML Constraint Representation" and add it in between Section 7.5 and Section 7.6. Have this as Section 7.6 and move existing Section 7.6 to Section 7.7.

 

The metaConstraint between ResourceInterface and ResourceType should have a "/" on the front of "endType".	
Diagram 	 OV-4 - Typical

Section	8.1.1.1.4 Figure 8.36
Page	63

Rationale	 We need to indicate the role we're constraining and with the "/" missing it could be misinterpreted.

OMG Issue No	
FTF  Number	UPDM_00032
Summary 	 The metaConstraint between Commands and DataElement has an incorrect umlRole.  Instead of "conveyedElement" it should be "conveyed".	
Diagram 	 OV-4 - Typical
Document Issue	UPDM (OMG Beta) Jan 2009
Section	8.1.1.1.4Figure 8.36
Page	63

Rationale	 The role doesn't exist so the profile is invalid.
Resolution	 "umlRole" value changed to "conveyed".

"umlRole" value changed to "conveyed".

 The metaConstraints from Commands to OrganizationalResource have invalid umlRoles.  They should be "source" and "target" not "informationSource" and "informationTarget".	
 OV-4 - Typical
UPDM (OMG Beta) Jan 2009
8.1.1.1.4 Figure 8.36
63


 The roles don't exist so the profile is invalid.
 Role values changed to "source" and "target".

Summary 	 There should be an additional metaConstraint between OperationalActivity and OperationalActivityAction that identifies the ownership via the "activity" role.	
Diagram 	 OV-5 / SV-4
Document Issue	UPDM (OMG Beta) Jan 2009
Section	8.1.1.1.4 Figure 8.378.1.1.1.7 Figure 8.131
Page	64 &145
Priority	 Medium
Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 Currently there's no constraint as to who can own the Action.
Resolution We'll add the missing metaConstraints between FunctionAction and Function, as well as OperationalActivityAction and OperationalActivity.

 I really don't see the point in OperationalActivity having a StateMachine…  How does that work?	
 OV-6b / SOV-4b / SV-10b
UPDM (OMG Beta) Jan 2009

 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

 I've no idea how or why you'd do this…
 We will remove ServiceFunction, Function and OperationalActivities from the StateMachineOwner abstract stereotype.

 The Entity, Attribute and EntityRelationship stereotypes are in the wrong Package.  They should be scoped to the Core::TechnicalStandardsElements Package.	
 OV-7
UPDM (OMG Beta) Jan 2009
8.1.1.1.4Fig 8.41
67

 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
 It's inconsistent with MODAF/DoDAF and is misleading.
 We'll rescope the stereotypes.

 ServiceParameter needs to be shown on this diagram.	
 SOV-2
UPDM (OMG Beta) Jan 2009
8.1.1.1.5 Fig 8.86
109

 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

 By just looking through the product views you wouldn't even know this element exists…
 Service parameter added to SOV-2

 ServiceInteraction is currently extending Interface when it should be extending Interaction (I think a typo may have slipped in).	
 SOV-4c
UPDM (OMG Beta) Jan 2009
8.1.1.1.5Fig 8.90
110
 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
 The current extension is blatantly wrong and needs resolving for it to fit its purpose.
 Metaclass for ServiceInteraction changed to Interaction

 RealizesCapability used to be a Realization but for some reason has been changed.  This should be changed back unless there's a good reason for it.	
 SOV-3
UPDM (OMG Beta) Jan 2009
8.1.1.1.5Fig 8.87
109
 High
 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
 23rd October 2008
 The name of the stereotype says it all…
 Metaclass for RealizesCapability changed to Realization.

 The metaConstraint with the umlRole "ownedElement" is wrong.  The relationship should indicate that the ServiceFunctionActions must be owned by a ServiceFunction (i.e. a metaConstraint from ServiceFunctionAction to ServiceFunction with an umlRole of "activity").	
 SOV-5
UPDM (OMG Beta) Jan 2009
8.1.1.1.5Fig 8.91
111

 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

 The current metaConstraint stops a ServiceFunction from owning anything other than ServiceFunctionActions, which is completely wrong.
 We'll change the metaConstraint between ServiceFunction and ServiceFunctionAction (very similar to UPDM_00034).

 The same as above but between ServiceFunction and ServiceOperationAction.	
 SOV-5
UPDM (OMG Beta) Jan 2009
8.1.1.1.5Fig 8.91
111

 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
 23rd October 2008
 Same as above.
 Same as above.

 FunctionEdge should be removed from the diagram as it won't be shown in this view.	
 SOV-5
UPDM (OMG Beta) Jan 2009
8.1.1.1.5Fig 8.91
111

 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

 It's misleading and incorrect.
 FunctionEdge was removed from SOV-5 diagram

 The metaConstraint to ServiceParameter from ServiceFunction should be shown on diagram.	
 SOV-5
UPDM (OMG Beta) Jan 2009
8.1.1.1.5Fig 8.91
111
 Medium
 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
 23rd October 2008
 Without it, it's not clear that the relationship exists (i.e. the product views are the important views).
 We'll add the missing metaConstraint to the SOV-5 diagram.

Summary 	 The stereotypedRelationship "realizesCapability" should be show fully on the diagram (i.e. as a stereotype with its two metaConstraints shown.	
Diagram 	 StV-3
Document Issue	UPDM (OMG Beta) Jan 2009
Section	8.1.1.1.6Fig 8.107
Page	126
Priority	 Medium
Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 It's confusing in the current form.
Resolution	 Diagram updated.

 We should show ServiceInterface on the SV-1 as the "type" for the Service and Request ports.	
 SV-1
UPDM (OMG Beta) Jan 2009
8.1.1.1.7Fig 8.122
139

 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

  To make it obvious what the type is.
 We'll add the unshown "type" metaConstraint between Service/Request and ServiceInterface.

The umlRole "conveyedElement" between ResourceInteraction and ResourceInteractionItem is wrong.  The umlRole should be "conveyed".	
Diagram 	 SV-1
Document Issue	UPDM (OMG Beta) Jan 2009
Section	8.1.1.1.7Fig 8.122
Page	139

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	  The current role is not valid UML.
Resolution	 We'll update the umlRole to the correct name.

Summary 	 CapabilityConfiguration should be shown on this diagram.	
Diagram 	 SV-9
Document Issue	UPDM (OMG Beta) Jan 2009
Section	8.1.1.1.7Fig 8.136
Page	149

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 It currently looks like all Resources apart from CapabilityConfigurations are displayed in this view but that's not the case.
Resolution	 We'll add CapabilityConfiguration to the diagram and connect it to Resource with the specialization.

 CapabilityConfiguration should be shown on this diagram.	
 SV-10a
UPDM (OMG Beta) Jan 2009
8.1.1.1.7Fig 8.124
141

 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

 It currently looks like all Resources apart from CapabilityConfigurations are displayed in this view but that's not the case.
 We'll add CapabilityConfiguration to the diagram and connect it to Resource with the specialization.

 The diagram currently shows InformationElements when it should be showing DataElements.	
 SV-11
UPDM (OMG Beta) Jan 2009
8.1.1.1.7Fig 8.127
142

 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

 This misrepresents the contents of the view and conflicts with DoDAF and MODAF.
 We'll update the diagram to replace InformationElement with DataElement.

Summary 	 The rest of the Resource subtypes should be shown on this diagram to make it clear that all Resources can provide a Service.	
Diagram 	 SV-12
Document Issue	UPDM (OMG Beta) Jan 2009
Section	8.1.1.1.7Fig 8.128
Page	143

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 This misrepresents the contents of the view and conflicts with MODAF.
Resolution	 We'll add the missing Resource specializations.

A lot of the abstract stereotypes are set to extend Element when they shouldn't be.   They're abstract so they don't really need to extend anything (their derived stereotypes will do that).  The main problem is that since UPDMElement is set to Element and everything is a specialization of it, the stereotypes appear to inherit the ability to be applied to anything - something we definitely don't want!

We cannot have any stereotypes with the same name as UML keywords.  Activity and Component (possibly Part) are…  
The following keywords are conflicting:
·	activity (current abstract so may not be an issue right now)
·	artifact
·	attribute
·	component
·	entity
·	function (to be confirmed)
·	node (this one could be contentious)
·	subsystem
	

There seems to be a circular inheritance between the elements below:
·	A ResourcePort is typed by a ResourceInteractionItem and is owned by a ResourceType 
·	A ResourceType inherits from a ResourceInteractionItem 
When you go further down the inheritance tree, the elements that inherit from the ResourceType do not really make sense to be ResourceInteractionItems as you end up with:
DataElement,Energy,CapabilityConfiguration,PostType,OrganizationType,Artefact,Artifact,Software. 
I think this should only be DataElement and Energy.

This is intentional to allow users to model logistics as well as data flows.
Disposition:	Closed, no change

ProblemDomain exists in MODAF but not in UPDM.  This is an important concept and should be captured.

According to the UML 2.1 specification, importing elements into the profile simply make them accessible within the profile namespace, meaning other stereotypes can generalize or refer to those imported stereotypes. However, the import does not define those stereotypes in the profile namespace. When the UPDM profile is applied to a model, only those stereotypes in its namespace can be applied to elements in the model. That means the SysML stereotypes imported into the UPDM profile cannot be applied in the model.

Since the UPDM L0 profile refers to imported SysML stereotypes, according to the UML 2.1 specification the SysML profile must be applied to the model before the UPDM profile.

Elements that are stereotyped <<UPDMElement>> (indirectly) can have references (actualMeasurements) to instance specifications stereotyped <<ActualMeasurementSet>>. An ActualMeasurementSet instance spec has slots stereotyped ActualMeasurement, which also generalized UPDMElement. This could result in a circular reference. ActualMeasurement should not generalize UPDMElement.

Not an issue, because they are cases where uses may want to link ActualMeasurementSets to other ActualMeasurementSet, also valid UML
Disposition:	Closed, no change

This stereotype extend Property and generalizes UPDMElement. It should not generalize UPDMElement since it is used in the UPDMElement::actualMeasurments and could result in circular references.

Not an issue, because they are cases where users may want to link MeasurementSets to other MeasurementSets, also valid UML
Disposition:	Closed, no change

This stereotype extends LiteralString, which contains a string value. Stereotyping a string value does not make sense. ISO8601DateTime should be defined as a stereotype extending DataType with 2 string properties for date and time. 

ISO 8601 Date Time is expressed as string. In UML, a placeholder for string values is LiteralString. However, as we need specific formatting for this string value, so stereotype is added in order to distinguish it from other LiteralStrings. 
If you change ISO8601DateTime to extend DataType instead of LiteralString you're going to end up with the ability to create multiple DataTypes in the user model that are stereotyped by "ISO8601DateTime".  For example, in a user model you'd end up with:
 
This isn't what you want to do…  What you want is to enforce a strict date/time format on certain metamodel properties (e.g. startTime and endTime).  The current implementation seems to be the best way to do this.
Disposition:	Closed, no change

The first constraint indicates all owned InvocationActions must be OperationalActivityActions (which extends CallBehaviorAction). This will prevent the user from using other invocation actions in the activity such as CallOperationAction, SendSignalAction, etc.

The OperationalActivityEdge stereotype extends ActivityEdge and both the source and target actions of this edge are constrained to OperationalActivityActions (CallBehaviorActions). This constraint is too restrictive since you could not create an OperationalActivityEdge from the initial action to the first OperationalActivityAction

This stereotype extends Property and according to the diagram, it must be the value of the "endType" meta-property of an EntityRelationship, which extends Association. This <<Attribute>> stereotype and the implied constraint are fine if the association roles are always navigable. If an association role is non-navigable or if the element at the end of the association cannot own properties, the association end property is owned by the association itself, making it difficult for the user to apply the <<Attribute>> stereotype to that property.

The descriptions for the two constraints are reversed.

In Annex C-Sample Problem OV-1 diagram, fig 284,the Stereotype ConceptRole does not exist in the profile, it should be an ItemInConcept that has been typed  by one of other elements that contribute to the abstract element ConceptItem.

The example model was correct, but the specification was wrong. 
See  issue UPDM_00011/OMG13204.
Disposition:	Closed, no change

The Annex C example shows the corresponding generated DoDAF/MODAF viewpoint products but it does not show the semantic elements in the model and how they are related in order to produce those diagrams. There is no proof that the UPDM stereotyped elements can actually be used to construct these viewpoint diagrams. In fact, several of the stereotypes used in the diagrams do not appear to be defined in the profile: WholeLifeEnterprise (AV-1), ConceptRole (OV-1), Organization (OV-4), Role (SV-1).

The layout of the document is considered to be hard to read and disorganized.

The profile uses a non-intuitive construct for defining relationships. There are many examples where a stereotype extends Property and the "type" feature of Property is to be set to an element of another stereotype. Although this is legal UML, it is not a very good way to define a relationship between the owner of the Property (say Abc) and the "type" element being referenced (say Def). Because the relationship is defined in this manner and not using one of the UML Relationship types, there is no way to show a line on a diagram that represents this relationship between Abc and Def. The user has to examine the properties and the "type" feature to determine if such a relationship exists. This is a manual process and is not the normal way in UML to define a relationship. In fact, if a stereotyped association was used instead, this property on Abc would be created automatically and the association could be shown on a diagram. Some examples of stereotypes that extend Property in this manner are: EnvironmentalProperty, ItemInConcept, KnownResource, etc

There is a section in the spec that described the intent and motivation for such relationships.
Associations cannot be used, since they add unnecessary properties to the connected stereotypes.
Disposition:	Closed, no change

Practitioner's Perspective: 
Example from SysML: 
16.3.2.7 Verify
Description 
A Verify relationship is a dependency between a requirement and a test case that can determine whether a system fulfills the requirement. As with other dependencies, the arrow direction points from the (client) test case to the (supplier) requirement. 
Constraints
[1]The supplier must be an element stereotyped by "requirement" or one of "requirement" subtypes.
[2]The client must be an element stereotyped by "testCase" or one of the "testCase" subtypes. 
Generally, SysML practitioners (the RFC participants are the developers and implementers of SysML) do not contemplate instance modelling and therefore dependencies suffice when every concept of the domain is modelled at the "Classifier" level. However, if one wanted to create an instance of a TestCase that had specific parameters and a Requirement that had details for that particular instance, then the association between the two specified by the Verify relationship would not be available to the modeller. Certainly a new dependency could be drawn, but that is not related to the dependency between the classifiers. 
This may not seem to be a big problem to modellers who can draw lots of arrows and boxes, but it severely limits the much larger requirement of being able to use the models in decision support activities and producing ad hoc queries and reports. 
Furthermore, using Dependencies to model domain concepts is contrary to the semantics of Dependency and Association expressed UML 2.0 spece. 
Bottom Line: The use of stereotyped dependencies in the RFC proposal based on SysML approach eliminates the power, flexibility and market opportunities that the use of stereotyped association have in UPDM Beta2.

Instance modelling is already used in UPDM where applicable.  Dependencies are the legal UML relationship, providing means of navigating and querying the model. 
An exact case where UPDM prevents modellers to create certain models is needed.
Disposition:	Closed, no change

In many cases, the diagramming indicates an association between stereotypes: 
See example below - UPDMElement. 
UPDMElement -> Standard 
but the documentation does not specify an association, rather it show these as attributes. Is the diagramming correct, or is the document right? 
UPDM/RFC::UPDMElement 
Super type for many of the UPDM elements. It provides a means of extending UPDM elements in a common way. With links to the measurement set, it also allows quantitative metrics to be associated with structural and behavioral elements.
 
Figure 1 - Elements related to the abstract UPDMElement stereotype. 
Attributes 
The following are attributes of UPDMElement: 
conformsTo : Standard[*] - Standard that this UPDM element is conforming to. 
URL/URI : String[1] - Unique identifier for the element. 
measurementTypes : MeasurementSet[*] - Types of measurements corresponding to the actual measurements. 
actualMeasurements : ActualMeasurementSet[*] - The actual measurements to which the element must conform. 
Extensions 
The following are extensions for UPDMElement: 

o Element in th esubmission
UPDM/RFC:: 6.5 Representing stereotype constraints 
This section describes a profile that is applied to the UPDM Profile inorder to specify various relationships. Since this is integral to the definition of the profile, it should be defined as if it were in fact a UML profile in a formal way. 
For example: 
"metarelationship" dependency 
"metarelationship" is a stereotype for dependency, showing that certain domain concepts will be implemented using regular UML relationships. 
For example: 
A Capability may depend on other Capabilities, but this concept cannot be visualized on the diagram: 
 
Figure 2: Capabilities Generalization 
We are using the "metarelationship" dependency to visualize the dependency concept: 
 
Figure 3: Visualizing <<metarelationship" 
This diagram should be read as follows: 
Capability may have other Capabilities related to it, using the UML Dependency metaclass. 
The "metarelationship" dependency will appear in only in the specification diagrams, but not the profile XMI. 
In the actual specification: 
 
There are 3 of these "meta-relationships" shown, but they are not defined anywhere else in the profile. They are part of the normative definition because they are in the diagram, but since they are not in the XMI, then how is that they can be considered as part of the profile? 
We need to have a better understanding what these "notational conventions" used in this submission mean. The explanations in the RFC are not sufficient. We had some difficulty understanding them, and exactly what OCL constraints they imply. A formal definition with resulting OCL would clear it up, and provide guidance to tool vendors as to how to deal with these conventions.

AssociationEnd is a Property stored in a ownedElements of a connected Classifier (if not owned by Association itself, but this is not the case). 
Attribute set subsets features (all Properties of Classifier), which subsets members (all Features of a Classifier), which subset ownedElements (All elements owned by Classifier). Therefore all the association ends owned by a Classifier are attributes.

Disposition:	Closed, no change

Just been trying to implement the sequence diagram parts and we have a problem 
SDs cannot show information flows, they can show the elements flowing on them, the information items, but only as arguments on an event or an operation. 
I think the solution is to just events with auguments that relate to the various items that can flow. 
It is unworkable as it is at the moment.

There's a meta-constraint between NeedlineExchange and NeedlineExchangeItem missing for constraining the "conveyed" role.

The metaconstraints are applied between the specializations of NeedlineExchange and NeedlineExchangeItem - so this isn't required.
Disposition:	Closed, no change

There is an element in the model called "UsedConfiguraton" needs to be changed to UsedConfiguration.

I think ActualProjectMilestone should have an association link to a CapabilityConfiguration, similar to the relationship CapabilityIncrementMilestone and OutOfServieMilestone have - otherwise it is useless in the DoDAF version of SV-8.

 ConceptualDataModel just sits in the MODAF package and isn't connected to anything.  I can't find it in the M3 either…  Should it be removed?	
Diagram 	 MODAF
Document Issue	UPDM (OMG Beta) Jan 2009

Rationale	 It's pointless having it at the moment.
Resolution: It doesn't exist in MODAF 1.2 so it will be removed.
	

 I'm pretty sure it was decided that Artifact and Artefact were similar enough that we didn't need both.  We should remove the one in the MODAF package.	
Diagram 	 MODAF
Document Issue	UPDM (OMG Beta) Jan 2009	
Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
Rationale	 The names are so similar that'd it be more confusing to have both names.
Resolution We'll remove the MODAF specialized stereotype as the MOD aren't overly worried about the Americanized spelling.

Summary 	 What about various identifiers, for example identifier for InformationExchange, ResourceInteraction and Needline, etc.	
Diagram 	 OV-x, SV-x
Document Issue	UPDM (OMG Beta) Jan 2009

Rationale	 Required to fulfil the requirements of DoDAF/MODAF.
Resolution	 Add the missing identifiers to the relevant stereotypes:InformationElementNeedlineExchangeDataElementResourceInteractionNeedline

Summary 	 OperationalConstraint/ResourceConstraint has types in DoDAF - Structural assertions, Action assertions, Derivation.  There should be at least category attribute for the Rule.	
Diagram 	 OV-6a, SV-10a
Document Issue	UPDM (OMG Beta) Jan 2009

Rationale	 We need to provide a mechanism for people to classify their rules otherwise it will quickly become unmanageable.
Resolution	 We'll add an abstract Constraint stereotype that has an additional enumeration tag definition.  OperationalConstraint and ResourceConstraint will be made specializations of this. 

Summary 	 Attributes for Organization - code, military service type, etc.	
Diagram 	 OV-4
Document Issue	UPDM (OMG Beta) Jan 2009

Rationale	 Required for mapping to DoDAF.
Resolution	 We'll add the missing attributes.

Summary 	 OperationalActivity/SysFunction consumes/produces exchanges.	
Diagram 	 OV-3, SV-4, OV-5, SV-6
Document Issue	UPDM (OMG Beta) Jan 2009
	
Priority	 High
Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com
Rationale	 Required for generating OV-3 and SV-6 diagrams, as well as for information purposes on an OV-5 and SV-4.
Resolution	 The tag definitions on OperationalActivity and Function will be removed.  New derived tag definitions will be added to NeedlineExchange and ResourceInteraction to derive the consuming and producing OperationalActivities and Functions.

Summary 	 Needline is not realized in SVs.	
Diagram 	 OV-2, SV-1
Document Issue	UPDM (OMG Beta) Jan 2009
Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 Required for mapping to DoDAF.
Resolution	 The information can be derived via Exchanges and does not require a new, direct relationship.  We'll add a derived tag to Needline and ResourceInterface to list the related ResourceInterfaces/Needlines.

Summary  ServiceInterfaces should have the ability to have Dependencies between them.	
Diagram 	 SOV-2
Document Issue	UPDM (OMG Beta) Jan 2009
Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 It sounds quite plausible that people will want to model the dependencies between ServiceInterfaces.
Resolution  We will add a Dependency metarelationship to/from ServiceInterface to show that dependencies can be created. 
	

Should there be some sort of enumeration property on the RealizesCapability element to indicate the level of the realization?  Something along the lines of:Complete (100%)Partial (around 50 to 75%)Minimal (around 25%)Undefined (default value)	
Diagram 	 SOV-4
Document Issue	UPDM (OMG Beta) Jan 2009
Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
Rationale	 To provide more information regarding the cover of a Capability by a ServiceInterface.  Currently it's all or nothing…
Resolution	 We'll add the enumerations as a tag definition (called realizationLevel) to the RealizesCapability stereotype as specified in the Issue description.

Summary 	 The examples of OV-1c diagrams in MODAF and some of the examples in DoDAF show the relationships between conceptual elements with direction (e.g. an aircraft attacking an enemy target is directed away from the aircraft).  Since MODAF has connectors going between the conceptual items you cannot have navigation.  It seems more sensible to change ArbitraryConnector to a Dependency and change the name to ArbitraryRelationship (conflicts with UPDM_00012).	
Diagram 	 OV-1
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
Date	 30th October 2008
Rationale	 We need to be able to produce the example diagrams specified in DoDAF/MODAF, or at least be very close to them.  Loosing the direction of the relationships will cause the meaning of the OV-1c to be ambiguous.
Resolution	 We will change ArbitraryConnector to be called ArbitraryRelationships and change it to extend Dependency instead of Connector.

Summary 	 OntologyReference has invalid specializations.	
Diagram 	 AV-2
Document Issue	UPDM (OMG Beta) Jan 2009


Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 OntologyReference currently extends Extension yet the two subtypes are Class and InstanceSpecification extensions.  Though the extensions aren't inherited this doesn't seem right.
Resolution OntologyReference should not be extending Extension.  Since its abstract, we'll update it to extend Element as we have for all the other abstract stereotypes.

Summary 	 Referred location extends different metatypes than its sub-stereotypes.	
Diagram 	 OV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com
	
Resolution	 Change the metaclass to Element.

We need to allow ServiceOperationActions to be owned by Functions as well as ServiceFunctions on the SV-4.  This allows a Resource to call a ServiceOperation on a Request port. NOTE: We identified the need to do this before the submission but ran out of time…	
Diagram 	 SV-4
Document Issue	UPDM (OMG Beta) Jan 2009
Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 Without this we cannot model the invocation of a ServiceOperation from a requesting Resource.
Resolution  We'll add a metaConstraint between ServiceOperationAction and Function (the same as the one between ServiceOperationAction and ServiceFunction).

ServiceOperations need to be owned by Resources as well as ServiceInterfaces as otherwise nothing is implementing the operation on the interface.  This also means that ServiceOperations need to be connected to Functions via a metaConstraint constraining the method/specification relationship.NOTE: We identified the need to do this before the submission but ran out of time…	
Diagram 	 SV-4
Document Issue	UPDM (OMG Beta) Jan 2009
	
Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
Rationale	 ServiceInterfaces specify the operations that need to be implemented by the realizing resource.  In order to implement them, they need to be copied to the realizing Resource.  They then need a Function connected to them to show how the operation is implemented by the Resource.
Resolution We'll add a metaConstraint between Resource and ServiceOperation (the same as the one between ServiceInterface and ServiceOperation).

ServiceParameter needs to have a metaconstraint modelled to show that the "type" role is constrained to ResourceInteractionItem.	
Diagram 	 SOV-5
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 The ServiceParameter needs to be constrained to make it compatible with FunctionParameters.  Without this Functions cannot implement a ServiceOperation safely.
Resolution	 We'll add a metaConstraint between ServiceParameter and ResourceInteractionItem (the umlRole will be "type").

We aren't consistent about the tag definition names used for storing start and end dates.  We seem to have a mixture of "startDate/endDate", "fromTime/toTime" and possibly some others.  We should be consistent.	
Diagram 	 Various
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 It's easier for users if we're as consistent as possible with everything in the profile.
Resolution We'll make all the date/time tags have the same names (i.e. startDate and endDate).  This will make it a lot more consistent.All references changed to startDate, endDate, date.

Summary 	 Entity, This stereotype extends DataType and generalizes SubjectOfOperationalStateMachine, which has a StateMachine as owned behavior. A DataType can own attributes and operations but not behaviors.	
Diagram 	 OV-7/SV-11
Document Issue	UPDM (OMG Beta) Jan 2009
Source	 Kevin CornellIBMkcornell@ca.ibm.com

Rationale	 Similar to issue re activities and Statemachines
Resolution Entity metaclass is changed to Class.

Summary 	 EnvironmentExtends DataType but the reference umlRole="ownedAttribute" is called "Part". A DataType is not a StructuredClassifier so it cannot have parts.	
Diagram 	 Environment
Document Issue	UPDM (OMG Beta) Jan 2009
Source	 Kevin CornellIBMkcornell@ca.ibm.com

Resolution Environment metaclass is changed to Class.
	

.	

Operational ActivityThe first constraint indicates all owned parameters are OperationalActivityParameters but that stereotype does not exist (should be OperationalParameter). 	
Diagram 	 OV-5
Document Issue	UPDM (OMG Beta) Jan 2009
Source	 Kevin CornellIBMkcornell@ca.ibm.com

Resolution	 Error in text document

Summary 	 Commands , This stereotype has extra constraints that do not belong.	
Diagram 	 OV-4
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Kevin CornellIBMkcornell@ca.ibm.com
Resolution	 Document needs to be updated, Controls and Command combined

 There should be a stereotype called RealizesNode between Node and Resource, rather than just a normal Realization.	
 SV-1
UPDM (OMG Beta) Jan 2009

 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

  The group agreed that we should have a stereotyped relationship for things such as this.

See issue 13207 for disposition

Summary 	 I really don't see the point in Function having a StateMachine…  How does that work?	
Diagram 	 SV-10b
Document Issue	UPDM (OMG Beta) Jan 2009
Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
Rationale	 I've no idea how or why you'd do this…
	

See issue 13356 for disposition

Version  Beta 1.0 

OMG Document Number:  c4i/2008-08-13 


ArbitraryRelationshipConnector should have end roles/client-Supplier associated with ItemInConcept instead of ConceptItem 
This is linked to Issue 13492 where the relationship is renamed and redefined as dependency. This affects the diagram associated with section 8.1.1.1.4.4.1 
  
figure 64, page 54

 ItemInConcept is an abstract stereotype, but is should not be.	
 OV-1
UPDM (OMG Beta) Jan 2009
 Andrius StrazdauskasNo Magicandriuss@nomagic.com

ActualProjectMilestoneStereotype has an attribute "time" of type ISO8601DateTime, which is a stereotype that extends LiteralString. A literal string is used to store a string value but it is not a type. It cannot be specified as the type for a stereotype property. It also does not make sense to apply a stereotype to a string value.	
Diagram 	 ACV-2
Document Issue	UPDM (OMG Beta) Jan 2009


Source	 Kevin CornellIBMkcornell@ca.ibm.com

Rationale	 Duplicate. Resolution in UPDM_00130
Resolution: We are just applying a stereotype to a string so that it can be used to type a property, 
	

 Climate , This stereotype extends Class and generalizes <<EnvironmentalType>>, which is an abstract stereotype that extends Element. Because of this generalization, Climate can be applied to any UML element (e.g., dependencies, comments, package imports, etc.). This will lead to model inconsistency. There are many other stereotypes that also extend Element and are subclassed: UPDMElement, SubjectOfOperationalStateMachine, ConceptItem, NodeParent, etc.	
 Environment
UPDM (OMG Beta) Jan 2009
Kevin CornellIBMkcornell@ca.ibm.com

Summary 	 OperationalActivity defines an attribute that refers to an ActivitySubject, the element performing the activity. In UML, the performer of a behaviour is typically the element that owns the behavior.	
Diagram 	 OV-5
Document Issue	UPDM (OMG Beta) Jan 2009


Source	 Kevin CornellIBMkcornell@ca.ibm.com
Date	 1st  October 2008

Resolution: Performs does the allocation or it is defined by a derived tag, not the implicit relationship

The Mission stereotype extends UseCase but an EnterprisePhase is supposed to refer to the Mission via the "ownedBehavior" meta-property. However, a UseCase is a BehavioredClassifier (e.g. can own behaviors) but it is not a Behavior, so EnterprisePhase cannot refer to the Mission in the suggested manner.	
Diagram 	 OV-1
Document Issue	UPDM (OMG Beta) Jan 2009


Source	 Kevin CornellIBMkcornell@ca.ibm.com
Date	 1st  October 2008
Rationale	 Duplicates UPDM_00007
Resolution	 Change the role to useCase

 ActualOrganizationRelationship, This stereotype only extends InformationFlow (no generalizations) and it has constraints for its "client" and "supplier" meta-properties. An InformationFlow does not have client/supplier meta-properties (they should be source and target). 	
Diagram 	 OV-4
Document Issue	UPDM (OMG Beta) Jan 2009


Source	 Kevin CornellIBMkcornell@ca.ibm.com


	

This stereotype extends Interface yet the description for ServiceInteraction in section 8.1.5 (paragraph after Figure 103) indicates its purpose is to "specify how a service interacts with external agents, and the sequence and dependencies of those interactions." The stereotype name and this description would seem to indicate it should extend Interaction and not Interface.	
Diagram 	 SOV/ documentation
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Kevin CornellIBMkcornell@ca.ibm.com

Resolution	 Error update document

This stereotype extends Dependency yet the meta-constraints refer to source and target meta-properties. For a Dependency, the meta-properties should be client and supplier.	
Diagram 	 ACV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Kevin CornellIBMkcornell@ca.ibm.com

	

This stereotype extends Extension but the use of the Extension meta-class appears to be limited to UML Profiles. An Extension is a special kind of Association that is used to indicate that the properties of a meta-class are extended through a stereotype (i.e. a stereotype definition in a profile, not a stereotype application in a model). This OntologyReference should probably extend Dependency or Association.	
Diagram 	 AV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Kevin CornellIBMkcornell@ca.ibm.com

Resolution	 Update to extend element

There are many abstract stereotypes in the profile that extend Element. The derived stereotypes also extend the specific meta-class type to which the stereotype can be applied. However, because these derived stereotypes generalize the abstract stereotype, they can be applied to any element in the model and not just the specified meta-class that the derived stereotype extends. These abstract stereotypes should not extend anything (they do not need to since they cannot be applied anyway) 	
Diagram 	 General Comment Abstractions
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Fred MervineIBMfmervine@us.ibm.com

 Page 49, 7.1.4.2.1 Attribute, has a wrong constraint, please delete. (That constraint is from the next item on the same page, EntityRelationship, and has a typo entType ? endType, please correct there.)	
 OV-7
UPDM (OMG Beta) Jan 2009

Manfred Koethe

Page 51, 7.1.4.3.1 Commands. Commands and Controls are both direct specializations of ResourceInteraction. Why are the Controls.xxxx constraints listed here? They shouldn't.	
Diagram 	 DocumentationPart 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Summary 	 Currently ActualMeasurementSets are not related to time. I think, that there might be multiple measures of the resource at certain time points.  Is this an issue?	
Diagram 	 All
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Resolution: Add a new stereotype that specializes ActualMeasurementSet that has the additional properties, etc.  The following attributes are potential candidates:Recorded Date (when the measurements were taken) - MUSTValidity Date (how long the measurements are valid for) - MAYBE

ArbitraryRelationshipConnector - do we need both Relationship and Connector in the name.	
Diagram 	 OV-1
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

	

Disposition:	See issue 13529 for disposition

Summary 	 Can a Node host Activities?	
Diagram 	 OV-5
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Summary 	 ArbitraryRelationshipConnector is a bit of a long name…	
Diagram 	 OV-1
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 It will make the diagram very messy should the stereotype be shown on a diagram.

Superseded by UPDM_00088/OMG Issue 13492
Disposition:	Closed, no change

We agreed that there'd be two ways to allocate Operational Activities/Function to Nodes/Resources.  One is via the Performs relationship and the other is via the ownedBehavior.	
Diagram 	 OV-5 / SV-4
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 Some users will want to use the UML approach for allocating behaviour and others won't.  We should cater for both.
Most MODAF/System Engineers won't be interested in the UML approach and we should avoid adding confusion by having two approaches for the same thing.

Most MODAF/System Engineers won't be interested in the UML approach and we should avoid adding confusion by having two approaches for the same thing.
Disposition:	Closed, no change

The metaConstraint between EntityRelationship and Attribute has an umlRole of "endType".  However, this role is supposed to go to the classes at the end of the Association (via the Role).  The metaConstraint should either of to Entity or the umlRole should be set to "memberEnd".  Ideally both should be used to indicate that the Properties at the end(s) of the Association should be stereotyped as Attibute and can only go between Entities.  Also, "endType" should be "/endType" as it's derived.	
Diagram 	 OV-7
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 The role doesn't exist between the two metaclasses so the OCL will not work.
Resolution	 TBD. Exact fix

DoDAF treats measurements as ACTUAL measurement at some (past) time. UPDM measurements are requirements for future.	
Diagram 	 SV-7
Document Issue	UPDM (OMG Beta) Jan 2009


Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Resolution	 Adding a time for an actual measurement, i.e. target, future  or present. Try to consider pattern matching with SV-9 proposal.Action-Architecture team

OMG Document Number:  c4i/2008-08-13 
Problem definition 
The milestone sequence stereotype is missing from the SV-8 View, the graphical view of this information is unclear. 
Potential resolution 

show the Milestone Sequence on the diagram but don’t enforce the use of MilestoneSequence between all milestones 

 That way people can just rely on the dates or use the dependencies.  

Summary 	 ProjectTheme extends attribute and is used to define the Lines of Development (LOD) relevant to a particular ProjectType.  The problem is that there is no type for the ProjectTheme so there's no way to define a value.  In the MODAF examples they're typed by an enumeration that provides the colours for the various pie sections.  If the enumeration is a fixed thing we might have to introduce the dreaded Class library...NOTE: This also means there's another element missing for the value that goes into the Slot.	
Diagram 	 AcV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 Without this we're missing a key feature in the creation of the AcV-2 Pie Diagram thing.
Resolution A new stereotype called ProjectThemeStatus will be added that extends Enumeration.  This will allow users to define their own statuses as required.  The mapping between ProjectThemeStatus and a colour (for use on the AcV-2) is deemed an implementation concern and outside the scope of the UPDM specification.This requires an update to the AcV-2 profile diagram.Action-Architecture teamGraham raise issue on MODAF (Ian Bailey)Phil to raise issues re constraints on AcV2POTENTIAL SOLUTION: A new stereotype called ProjectThemeStatus will be added that extends Enumeration.  This will allow users to define their own statuses as required.  The mapping between ProjectThemeStatus and a colour (for use on the AcV-2) is deemed an implementation concern and outside the scope of the UPDM specification.This require an update to the AcV-2 profile diagram.

Summary 	 I'm pretty sure that ArchitecturalDescriptions aren't supposed to own Views…	
Diagram 	 AV-1
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 I thought Views existed outside of the Views.
Resolution As Architectural Description is used for AV-1 generation, they have to reference all the Views within this architecture. 

As Architectural Description is used for AV-1 generation, they have to reference all the Views within this architecture. 
Disposition:	Closed, no change

There's no metaConstraint from NeedlineExchange to the source/target of the exchange.  They should be set to Nodes and NodeRoles I assume.	
Diagram 	 OV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 Required to model the constraints that need to be adhered to.
Resolution: Add Source-target constraints to NeedlineExchange  Raise issue to change NeedlineExchange to OperationalExchangeAction-Fatma to write description of usageFatma's description to be added to the Exchange descriptions in the specification.PA 17/2/2009 If we rename NeedlineExchange to OperationalExchange then we also need to rename NeedlineExchangeItem to OperationalExchangeItem.Also need to add constraints to OperationalActivityEdge/FunctionEdge that states if the stereotype is applied to an ObjectFlow and the edge is connected to an Exchange, the conveyed item and the pin types need to be consistent/compatible.

Diagram 	 OV-4 - Actual
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 To maintain the naming convention we agreed upon.
Resolution	 We'll rename the stereotype.

To be consistent with AcV-2, the metaConstraint between ActualOrganizationPart and ActualOrganization should have a umlRole with "slot" and be pointed in the other direction.	
Diagram 	 OV-4 - Actual
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 Just to be consistent.
Resolution: Add the missing metaconstraint

To be consistent with other product diagrams, the metaConstraint between ResourceType and ResourceRole with a umlProperty of "class" should have its direction swapped around and the umlRole set to "ownedAttribute".	
Diagram 	 OV-4 - Typical
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 Just to be consistent.
Resolution:  It's not important - they both mean pretty much the same thing.

Discussion:
It's not important - they both mean the same thing.
Disposition:	Closed, no change

The "carriedItem" tag between OperationalActivityEdge and NeedlineExchangeItem (NEI) isn't really needed.  To model the NEI flow they simply need to show the pins which map to OperationalParameters - as they're typed by the NEI.	
Diagram 	 OV-5
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 The current implementation seems to duplicate information that's already available in the model.
Resolution: TDB. Get consensus on resolutionRemove carriedItem tag.

There doesn't seem much point in showing Service on the SOV-1.  It cannot be shown on a diagram as it's an extension of a Port and the owners of the Ports aren't shown.	
Diagram 	 SOV-1
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 There's no point showing this and potentially it could be confusing.
Resolution: We'll remove the Service stereotype from the SOV-1 view definition diagram (not from the model).

Summary 	 The "abstractBehavior" tagged value between ServiceOperation and ServiceFunction should be shown on the SOV-5 diagram.	
Diagram 	 SOV-5
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 Without it, it's not clear that the relationship exists (i.e. the product views are the important views).
Resolution: We'll add the missing tag definition to the SOV-5 diagram.

.	

There's no metaConstraint from ResourceInteraction to the source/target of the interaction.  They should be set to Resource and ResourceRole I assume.	
Diagram 	 SV-1
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 Required to model the constraints that need to be adhered to.
Resolution: We need to apply the same fix that we implement for [UPDM_00018].

ProtocolImplementation has a few issues.  It should be abstract (i.e. not extend anything) and only be connected to Protocol via the tagged value.  ResourcePort and ResourceInterface should then be specializations of the abstract ProtocolImplementation stereotype.  Any interaction/port on/between resources can implement a protocol - they're not different elements.	
Diagram 	 SV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 The current implementation doesn't map to MODAF and isn't usable.
Resolution: Implement proposed solutionAction-Architecture team

The "to/from" tagged values for Protocol should have better names.  Since we're modelling protocol stacks, lowerLayer and higherLayer seem more appropriate.  It may also help ease confusion.	
Diagram 	 SV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 This should help people to understand what the relationship is for (currently it's a little ambiguous).
Resolution: We'll add a new stereotype called ProtocolLayer which extends Property.  This will be applied to the composite properties that exist between Protocols.  The tags will be replaced with metaConstraints for the Protocol's "ownedAttribute" role and the ProtocolLayer's "type" role.  Since ownedAttribute is ordered, the higher/lower layer concept is maintained.  This will allow people to model protocol stacks on Class/Composite Structure Diagrams.

It'd be more consistent for the "/subject" to "/affectedFunctions" to have the same names as the OV equivalent (i.e. "/subject" to "actsUpon").	
Diagram 	 SV-4
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 Just to be consistent.
Resolution: Role name changed to "actsUpon"

The SystemsNode stereotype is missing.  There should be one that extends CapabilityConfiguration I'd have thought…	
Diagram 	 DoDAF
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 It's a key component in DoDAF and seems to be missing.
Resolution: We'll add a new stereotype to the DoDAF SV package and connect it to CapabilityConfiguration with a specialization (as this is the closest match in UPDM).NOTE: We probably need to add some additional constraints to remove the human aspects (e.g. Organizations and Posts) inside the configuration as DoDAF 1.5 doesn't support this concept.
	

There should be some additional constraints for the DoDAF/MODAF stereotypes to indicate that they're replacements for Core stuff.	
Diagram 	 DoDAF/MODAF
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 At the moment it looks like its Core + DoDAF/MODAF stereotypes instead of the DoDAF/MODAF stereotypes replacing some Core stuff…
Resolution: Implement tag on Architectural Description type by MODAF/DoDAFAdd constraints to Architectural to filter MODAF /DoDAF applicable stereotypes.  Relates to alias.Action AndriusWe'll add some text to the document to provide guidance on what the DoDAF/MODAF alias' are and on their usage (i.e. it's recommended to not mix and match terminology).

Should there be a relationship between Capability and Mission?	
Diagram 	 OV-5
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 There was an existing link between these in a previous No Magic DoDAF implementation.
Resolution	 As the issue is based on proprietary implementation, there is no need to fix it.

As the issue is based on proprietary implementation, there is no need to fix it.
Disposition:	Closed, no change

Don't we need System/Artifact specializations, like Network, etc?	
Diagram 	 SV-x
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 There were previous elements in DoDAF for modelling things such as LAN and MAN, etc.
Resolution: The profile can be customized by end users to add new stereotypes which can either be specializations of an existing UPDM stereotype or can be applied in addition to a UPDM stereotype.  There's no need to add any specific ones to the main profile - they'd only be relevant to certain users.<Insert change document>

The profile can be customized by end users to add new stereotypes which can either be specializations of an existing UPDM stereotype or can be applied in addition to a UPDM stereotype.  There's no need to add any specific ones to the main profile - they'd only be relevant to certain users.
<Insert change document>
Disposition:	Closed, no change

Why there is not potential relationship between InformationElement and SystemDataElement?	
Diagram 	 OV-7, SV-11
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Resolution: There are already relationships between the IOFlows that convey them and the underlying data that the Elements represent.  Another relationship would make consistency, etc, more difficult and not add much value.

There are already relationships between the IOFlows that convey them and the underlying data that the Elements represent.  Another relationship would make consistency, etc, more difficult and not add much value.
Disposition:	Closed, no change

Should there be any link between OperationalActivity and Capability?	
Diagram 	 StV-6, SV-5
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 Required for mapping to DoDAF.
Resolution: There shouldn't be a direct link between OperationalActivity and Capability as it's implemented via Nodes.  Only StandardOperationalActivities are connected to Capabilities and these are imported from a MODAF library and do not require creating in the user model.

There shouldn't be a direct link between OperationalActivity and Capability as it's implemented via Nodes.  Only StandardOperationalActivities are connected to Capabilities and these are imported from a MODAF library and do not require creating in the user model.
Disposition:	Closed, no change

Summary 	 Attributes for Measurements - units of measure, threshold value. 	
Diagram 	 AV-3
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 Required for mapping to DoDAF.
Resolution: TDB. Exact fix. If you're using an L1 implementation, then type the Measurement by a ValueType.  If you're using an L0 implementation then customize the profile to add your own tag (should you require it).  Phil to update the description on the stereotype.

Responsibility is not covered.	
Diagram 	 OV-4, SV-1
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 Required for mapping to DoDAF.
Resolution: This concept is covered by a combination of Node, ResourceRole specializations and Competencies.

This concept is covered by a combination of Node, ResourceRole specializations and Competencies.
Disposition:	Closed, no change

No Rule for SV.	
Diagram 	 SV-10a
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 Required for mapping to DoDAF.
Resolution: The stereotype is called ResourceConstraint in UPDM.

Yes there is, the stereotype is called ResourceConstraint in UPDM.
Disposition:	Closed, no change

No traceability from Node to SV.	
Diagram 	 SV-5
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 Required for mapping to DoDAF and to provide a complete picture
Resolution This information is derived as follows:Node à performs an à OperationalActivityOperationalActivity à is supported by a à FunctionFunction à is performed by a à ResourceThere is no need to add anything further as it would complicate the maintenance of the consistency.

The SOV-1 is inconsistent with other Taxonomy views and should be updated to make it just be ServiceInterfaces and Generalizations that go between them.  ServiceAttributes should be moved to the SOV-2 where the actual specification work is performed.	
Diagram 	 SOV-1, SOV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 To make is more consistent with other taxonomy views in UPDM.
Resolution: It's not important enough to warrant changing the diagrams in the profile.

After consideration the benefit is not felt  enough to warrant changing the diagrams in the profile.
Disposition:	Closed, no change

It's not clear on the diagram that we expect people will create Provided/Required Interfaces off a ServiceInterface.  We should add something to the diagram to make it clearer.	
Diagram 	 SOV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 To make it clearer what the view is supposed to show.
Resolution: TDB. Exact fixWe will add "something" to the SOV-2 diagram to show that ServiceInterface can have provided and required UML interfaces.

ExternalTypes are allowed to be generalizations of things such as Organizations and Artifacts in MODAF, yet in UPDM it isn't mentioned. 	
Diagram 	 AV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 We're currently not compliant with MODAF (and I assume Ideas too).
Resolution: We will add a Generalization metarelationship between ExternalTypes and UPDMElement.

ActualLocation is both a DataType and a Class in the spec.	
Diagram 	 OV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Resolution: We'll update the specification document to have the correct diagrams in.

Environment is both a DataType and a Class in the spec.	
Diagram 	 AV-1
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Resolution: We'll update the specification document to have the correct diagrams in.

LocationType is missing, but is mentioned throughout document.	
Diagram 	 OV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 As elements got renamed LocationType became Location and the document fell out of synchronization.
Resolution: We'll update the specification to reflect the new name consistently.

Can NodePort be assigned on NodeRole? Now the constraint says only about Node.The same about ResourcePort.	
Diagram 	 OV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Resolution: This isn't an issue as the NodePorts are connected to the NodeRoles via the Nodes that type them.

This isn't an issue as the NodePorts are connected to the NodeRoles via the Nodes that type them.
Disposition:	Closed, no change

The relationship between NeedlineExchange and ResourceInteraction is currently implemented using an unstereotyped Realization.  It should be connected using the built in "realization" role that exists as part of the InformationFlow metaclass.  It should also be shown on the SV-6.	
Diagram 	 SV-6
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 The current Realization relationship between the NeedlineExchange and the ResourceInteraction is duplicating a built-in UML role.  It should also be shown on the SV-6 diagram to indicate that it's used by the view (e.g. as a column in the table).
Resolution: Examine abstraction type relationships to identify refactoring issues Action-Architecture team

Information is DoDAF 1.5 has following properties, which are not in UPDM:ScopeContentlanguageaccuracy. The same with SystemDataElement.	
Diagram 	 OV-7
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com


Resolution: Same resolution as [UPDM_00100].

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.

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.  
	

This is what the Performs relationship is for.  
Disposition:	Closed, no change

In DoDAF Operational Activity has "cost" property. 	
Diagram 	 OV-5
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 Should be coupled with UDPM_00100
Resolution	 Same resolution as [UPDM_00100].

Do we need Consumers/Producers for services as in DoDAF?	
Diagram 	 SOV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Resolution: In UPDM the Consumer is identified through the Resource owning a Request port (the same for Producer and Service ports).  We don't really need to add a label to the Resource to indicate this.

In UPDM the Consumer is identified through the Resource owning a Request port (the same for Producer and Service ports).  We don't really need to add a label to the Resource to indicate this.
Disposition:	Closed, no change

Why is the relationship between UPDMElement and Measurements not bi-directional?	
Diagram 	 SV-7
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 The association should be bi-directional. There is no reason to have unidirectional
Resolution: Change association to bidirectional.

DoDAF had two levels of SV relations - interface and link. UPDM has only one.	
Diagram 	 SV-1, 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Resolution: TDB Add description. Update the description, so it is clear that both Interface and Link are merged into ResourceInterface.TBD. Who will do it?

Standards has multiple properties in DoDAF:typeoptionsparametersstart dateend dateversionshort namepublished website	
Diagram 	 TV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Resolution: Add those properties to the Standard.

CommunicationsLink in DoDAF had properties:capacityinfrastructure technology	
Diagram 	 SV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 Should be coupled with UDPM_00100
Resolution Same resolution as [UPDM_00100].
	

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.

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.

Not found.
Disposition:	Closed, no change

ResourceConnector>> is mentioned in the spec	
Diagram 	 SV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 ResourceConnector got merged into ResourceInterface but the specification didn't get updated.
Resolution: Not found.

Not found.
Disposition:	Closed, no change

Summary 	 Related to [UPDM_00018], the same issue exists for ResourceInterface and ResourceInteraction.	
Diagram 	 SV-x
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Graham BleakleyIBMGraham graham.bleakley@uk.ibm.com

Rationale	 Should be coupled with UPDM_00018
Resolution: Same resolution as for [UPDM_00018].

Performs, Two of the constraints do not belong.  	

Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Kevin CornellIBMkcornell@ca.ibm.com

Resolution: Error in documentation, relates to Realizes Capability

EnvironmentalProperty: This stereotype extends Property and its "type" meta- property is supposed to be an element stereotyped by EnvironmentalType, which extends Element. The "type" of a Property can only be an element of the UML type "Type". 	
Diagram 	 Environment
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Kevin CornellIBMkcornell@ca.ibm.com

Resolution: EnvironmentalType metaclass is changed to DataType

EnvironmentalType is an abstract stereotype, so it cannot be applied. All its specializations extend Classifier.
.
Disposition:	Closed, no change

Measurement also has 3 stereotype properties "propertyValue, maxValue and minValue. In the ActualMeasurementSet instance specification, the ActualMeasurement slots that correspond to this Measurement property will not be able to specify alternate values for the stereotype properties. In RSx, a slot can only define values for owned attributes of the corresponding classifier, and not for any stereotype properties associated with that classifier.	
Diagram 	 Measurement
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Kevin CornellIBMkcornell@ca.ibm.com

Resolution: Valid UML

SubjectOfOperationalStateMachine, This stereotype extends Element yet the description indicates an "ownedBehavior" meta-property which refers to a state machine. Only BehavioredClassifiers can own state machines.	
Diagram 	 OV-6
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Kevin CornellIBMkcornell@ca.ibm.com


Resolution: Change metaclass to BehavioredClassifier

SubjectOfOperationalStateMachine is an abstract stereotype, so it cannot be applied. All its specializations extend Classifier..
.
Disposition:	Closed, no change

InformationElement , This stereotype extends InformationItem, which RSx currently does not support (but the open source UML does).	
Diagram 	 OV-1/2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Kevin CornellIBMkcornell@ca.ibm.com

Resolution: This is a problem of UML implementation in specific tool.

InformationElement now extends Class instead of InformationItem.
Disposition:	Closed, no change

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

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

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

At least in the future Beta-1 document, the conformance sections from chapter 5 and 6 need to be combined into one single conformance clause.	
Diagram 	 Conformance definitionDocumentation P1
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Conformance in chapter 5 relates to the conformance of UPDM to DODAF 1.5 whereas the term conformance in Chapter 6 relates to the intended use of the technical views describing how the elements described in an architecture should "conform" to a technical standard. Conformance is used in different contexts.
Disposition:	Closed, no change

Page 7, 6.6.1 Aliases says: "Although there are similar concepts in DoDAF and MODAF, they are named the same." Shouldn't that read "... they are not named the same." ?	
Diagram 	 Documentation P1
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe
	

Part II desperately needs an introduction, maybe showing Figure 3: L0 and L1 from page xxiv and briefly re-introducing the package structure of the profile. It is certainly not a good idea to slam four pages of OCL into the face of the reader as an overture for Part II.... The OCL constraints are actually very good, but should come after an introduction to Part II, when the reader is reminded about the relationships between LO and LI, and L1 and SysML.	
Diagram 	 Documentation P2
Document Issue	UPDM (OMG Beta) Jan 2009


Source	 Manfred Koethe

Figure 34 - Elements related to the abstract ReferredLocation stereotype. explains both Location and ReferredLocation, maybe moving the figure up by one to Location?	
Diagram 	 DocumentationIssues for Part 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Not found
Disposition:	Closed, no change

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

<<Stereotyped relationship>> is explained in "6.5 Representing stereotype constraints"

Disposition:	Closed, no change

Page 48, 7.1.4.1.6 SubjectOfOperationalStateMachine, the constraint contains the text "...have StateMachines ar owned behaviours,..." which should probably read "have StateMachines as owned behaviours,...".	
Diagram 	 DocumentationIssues for Part 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Page 55, 7.1.4.4.1 ArbitraryRelationshipConnector, the connector ends are wrongly enumerated in the constraint descriptions.	
Diagram 	 OV-1/Documentation
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe


Resolution	 Merge constraints into one

Page 66, 7.1.4.4.16 NodeRole, Where are all these constraints coming from?	
Diagram 	 OV-1/2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe


Resolution	 Remove unnecessary constraints

Page 70, 7.1.4.4.19.1.2 ActualOrganizationalResource, a stereotyped relationship is listed as constraint. From the text it is possible to imagine what is intended, even though the formal names ("Owned") does not match the diagram.	
Diagram 	 Documentation/ OV-4 Actual
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Resolution	 Remove the Constraint

Page 74, 7.1.4.4.19.1.7 Post, the two constraint descriptions are over cross.	
Diagram 	 OV-4 Typical
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Page 75, 7.1.4.4.19.1.8 SubOrganization, in the description the constraint "SubOrganization.class1" should be "SubOrganization.type".	
Diagram 	 DocumentationPart 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Page 79, 7.1.4.4.19.1.14 RequiresCompetence, where are these "CompatibleWith.xxx" constraints coming from?	
Diagram 	 OV-4
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Page 83, 7.1.5.1.1 ServiceFunction, in the constraint descriptions, "ServiiceParameter" is misspelled.	
Diagram 	 DocumentationPart 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Page 91, 7.1.5.2.4 ServiceInterface, two constraint descriptions are wrong. ServiceInterface.ownedRule must be stereotyped "ServicePolicy", and ServiceInterface.ownedOperation must be stereotyped "ServiceOperation".	
Diagram 	 DocumentationPart 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Page 115, 7.1.7.1.1 Function, constraint description misspelled: "Function.ownedElements" should be "Function.ownedElement".	
Diagram 	 DocumentationPart 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Rationale	 Should be coupled with UPDM_00045

Page 117, 7.1.7.1.3 FunctionEdge, constraints in diagram and constraint descriptions disagree. It is source vs. supplier and target vs. source.	
Diagram 	 DocumentationPart 2/SV-5
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Rationale	 Should be coupled with UPDM_00134

Problem not found
Disposition:	Closed, no change

Page 136, 7.1.7.4.14 ResourceInterface, please verify the constraint descriptions. I believe there are things missing here.	
Diagram 	 DocumentationPart 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Resolution	 Constraints are fine. 

Constraints are fine. 
Disposition:	Closed, no change

Page 145, 7.1.8.1 Protocol, no diagram here to clarify attributes. Diagram on previous page(s) don't help either.	
Diagram 	 DocumentationPart 2/TVs/SOVs
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Resolution	 Diagram added

Page 146, 7.1.8.2 ProtocolImplementation, no diagram to help verifying attributes and constraints	
Diagram 	 DocumentationPart 2/TVs/SOVs
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Resolution	 Diagram added

Page 152, 7.1.11.2.1 DataExchange, Look at that diagram! It is the ultimate universal model :-)	
Diagram 	 SV-1/SV-11
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Resolution: This is just a DoDAF alias for ResourceInteraction

This is just a DoDAF alias for ResourceInteraction.
Disposition:	Closed, no change

 Page 158, "Figure 203 - Elements related to the ProjectStatus stereotype" overlays the text.	
Diagram 	 DocumentationPart 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Problem not found
Disposition:	Closed, no change

Page 166, 7.1.14.1.1 ActivitySubject, the attribute (in the description) should be flagged as derived.	
Diagram 	 DocumentationPart 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Page 167, "Figure 214 - Elements related to the StandardOperationalActivity stereotype" overlays the text.	
Diagram 	 DocumentationPart 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Problem not found
Disposition:	Closed, no change

Page 168, "Figure 217 - Elements related to the Controls stereotype" overlays the text.	
Diagram 	 DocumentationPart 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Problem not found
Disposition:	Closed, no change

Page 169, 7.1.14.3.1 Controls, constraint description for "Controls.conveyedElement" has wrong stereotype, should be DataElement.
Diagram 	 DocumentationPart 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Page 169, 7.1.14.3.2 EnergyExchange, the constraint description contains two extraneous constraints, "MaterialExchange.conveyed" and "OrganizationalExchange.conveyed".	
Diagram 	 DocumentationPart 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Page 175, "Figure 225 - Elements related to the EnduringTask stereotype" overlays the text.	
Diagram 	 DocumentationPart 2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Problem not found
Disposition:	Closed, no change

Since the color coding is consistent throughout the document, It would be nice to have the actual legend in the second paragraph of Annex A instead of just saying "Please refer to the legend in the various diagrams to understand the specific definitions".	
Diagram 	 DMM Documentation
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Some diagrams are very crowded. And since they are inserted as non-scaling images, they are unreadable. This applies in particular to Figure 234 OV and Figure 237 SV.	
Diagram 	 DMM Documentation/Diagrams
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Page 184, Figure 235 SOV contains composition ownership problems. If the asterisk on the composition ServiceInterface - ServiceOperation belongs to ownedOperation, then it's UML-wise ok but bad diagramming, otherwise it's an UML error. But besides this, ServiceOperation has an ownership conflict (ServiceInterface versus ResourceType). Could be solved with multiplicity [0..1] on the black-diamond.	
Diagram 	 SOVs
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Manfred Koethe

Resolution	 DMM Slightly out of synch with profile.

The examples of the SV-9 on the MODAF website don't obviously map to the implementation in MODAF/UPDM.  TechnologyArea doesn't exist and the cells in the table seem to relate to model items (e.g. "Software") rather than text in the Forecast comment.	
Diagram 	 SV-9
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com---------------------------------------------Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com


Resolution: Forecast extends dependency with properties StartTime EndTime. Goes between resources and SubjectOfForecast  add Boolean  tag to resource for TA Action-Architecture teamPOTENTIAL SOLUTION: The solution that requires the least change is as follows:Add a boolean tag to "Resource" called "isTechnologyArea".Add a constraint to "Resource" to specify that when "isTechnologyArea" is TRUE, "isAbstract" must also be TRUE.To create the example SV-9, shown on the MODAF website, you'd do the following:Create a new "Software" class called "Office Application" and set it's "isTechnologyArea" tag to TRUE.Create three new "Software" classes called "Office 2000", "Office 2005" and "Office Distributed", and make these specializations of "Office Application".Create three new "Forecast" comments with date ranges set to short, medium and long term dates.Connect each "Forecast" to all thee concrete "Software" classes.With this in place you could then derive the information required for the table.  A view option could be added to the view to allow the body text of the comment to be displayed somewhere.

ServiceInterface currently extends Interface but is also supposed to have provided/required interfaces.  This isn't allowed in UML.  In SOAML ServiceInterface extends both Interface and Class but this would be confusing to the end user as they will be able to create provided/required interfaces off some ServiceInterfaces (i.e. those that extend Class) but not to others (i.e. those that extend Interface).	
Diagram 	 SOV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 Invalid UML.
Resolution: Change ServiceInterface to extend Class and communicate with the SOAML team to keep the two profiles in line.

NodePorts are mapped to FlowPorts which limits the elements that can type it.  Since InformationElements are extensions of InformationItem they cannot be linked to a FlowPort and as such UPDM invalidate SysML constraints.  We do, however, need to connect InformationElements to NodePorts so we cannot just remove it.Same issue with ResourcePort and DataElement.	
Diagram 	 OV-2 / SV-2
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Resolution: Change InformationElement to extend Class. Review relationship to EntityAction-Architecture teamPOTENTIAL SOLUTION: Change InformationElement to extend Class?  Alternatively, change ports to connect to Entities?Metaclass changed to class

The intention behind allowing any Resource to realize a Capability was to stop the creation of lots of dummy CapabilityConfigurations with one Resource in.  This makes a lot of sense but unfortunately it hasn't been implemented throughout the rest of MODAF/UPDM.  The milestones (for example CapabilitiyIncrementMilestone and ConfigurationDeployed) are only connected to Configurations instead of all Resources.	
Diagram 	 Milestones
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 Currently, if you've only connected a single Resource to a Capability it looks like you have a shortfall in the StV-3 (as you cannot connect it to any milestones).  Alternatively, you have to create dummy CapabilityConfigurations which then makes connecting other Resources to Capabilities pointless.
Resolution: POTENTIAL SOLUTION: Allow milestones to connect to any resource and change the stereotype names and tags appropriately.  If [UPDM_00199] gets agreed upon then ActualProjectMilestone should also be related to all Resources too.Change names for ConfigurationNoLongerUsed and  ConfigurationDeployed to NoLongerUsedMilestone and DeployedMilestoneChange CapabilityIncrementMilestone to IncrementMilestoneAdd Retirement (DoDAF) Alias to OutOfService Action-Architecture teamPOTENTIAL SOLUTION: Allow milestones to connect to any resource and change the stereotype names and tags appropriately.  If [UPDM_00199] gets agreed upon then ActualProjectMilestone should also be related to all Resources too.

Association between OperationalActivityEdge and NeedlineExchange should be reversed.
It should be connected to OperationalExchange, not InformationExchange	
Diagram 	
Document Issue	UPDM (OMG Beta) Jan 2009

Rename NeedlineExchange to OperationalExchange	

In order to generate a view like the MODAF specified AcV-2, we need to ensure that constraints are placed on the combination of Project, ProjectMilestone and ProjectThemeStatus	
Diagram 	
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 The current approach is so loose that nothing useful could be generated from the model data.
Resolution: Each Project should only have one association to a ProjectMilestone, and each ProjectMilestone should have ProjectThemes that are all connected to the same ProjectThemeStatus.  This means that each type of Project will use the same ProjectThemes (e.g. Lines Of Developments) and the same statuses (e.g. colour codes, etc).

Controls should have the same fixes applied as Commands.
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 David PutnamBAE Systemsdavid.c.putman@baesystems.com

ResolutionThe "informationSource" and "informationTarget" metaConstraints should be changed to "source" and "target".  The "conveyedElement" metaConstraint should be changed to "conveyed".

Summary 	 PhysicalLocation is located in the wrong package/subprofile.	
Diagram 	
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 PhysicalLocation is used on the OV-1a and therefore isn't just an SV element (the name just makes it sound like an SV element).
Resolution: POTENTIAL SOLUTION:PhysicalLocation will be moved to the AllElements\Environment package/subprofile.

 Fig15 - Inheritance Problem. In Fig 15, MilestoneSequence is shown as a subclass of Project Sequence. This makes no sense, especially with the attribute redeclarations which would force a given MilestoneSequence to also relate two projects.	
 AcV
UPDM (OMG Beta) Jan 2009
 Ian BaileyModel Futuresian@modelfutures.com


 If we leave the inheritance between Project and ProjectMilestone in (as per MODAF) then they both can be linked up with ProjectSequences anyway.  The current implementation was seen as a tightening of the constraints.  However, this is a little confusing so we will remove the inheritance between Project/ProjectMilestone and ProjectSequence/MilestoneSequence.

Fig15 - ActualProjectMilestone to Project Status and ProjectStatus to ProjectTheme.The relationships needs to show cardinality so that it is clear that a milestone can carry several statuses, but that each status may be for one and one only theme. Similarly, the ProjectMilestoneType may have several themes.	
Diagram 	 AcV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution: Further to [UPDM_00204], we will set the cardinality on the relationships to make it clear what the constraints are.

Summary 	 Fig15 - Project whole and part and ownedMilestones. A whole-part relationship is shown on Project, but this doesn't seem to be stereotyped as one of the constraints used in the documentation. Does this mean it just becomes a tagged value ? Same goes for ownedMilestones ? Suggest that (at least for the whole-part) whatever UML structure is used for instances is used - that way projects structures can also be presented as instance composite diagrams (not sure what the correct UML term for this is, but you know what I mean - instances shown within instances to represent structure). This would help with producing more UML compliant AV-1s.	
Diagram 	 AcV
Document Issue	UPDM (OMG Beta) Jan 2009

Priority	 High
Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution: specifies the whole/part relationship between Project and ProjectMilestone (i.e. there should be one Association between them).Whole/part relationships don't exist for ActualProjects, as UML doesn't have support for Instances composed (the structured is supposed to be defined by the instantiated class model).  There is also no such thing as an Instance Composite Diagram in UML - though it's an idea that various people have had.FURTHER DISCUSSION REQUIRED WITH IAN

.

AcV - General Comment. Might want to put structural relationships for ActualPost and ActualOrganisation in, otherwise it is not clear how an AcV-1 can be produced.	
Diagram 	 AcV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution: The structure for the ActualPost and ActualOrganization is captured on the OV-4 Actual.  We will add the Slot extensions and metaConstraints to the AcV-1 to indicate that the structure can be shown on this product.

Summary 	 Fig21 - Constraint on StructuralPart is wrong. This would prevent one enterprise being part of another and so be incompatible with MODAF…not to mention complete nonsense.	
Diagram 	 AV
Document Issue	UPDM (OMG Beta) Jan 2009
Section	
Page	
Priority	 High
Source	 Ian BaileyModel Futuresian@modelfutures.com
Date	 3rd March 2009
Rationale	
Resolution	 The comment on the AV-1 diagram is supposed to read:"Cannot be typed by a WholeLifeEnterprise"A WholeLifeEnterprise cannot be part of another EnterprisePhase/WholeLifeEnterprise as it represents the whole thing.  The comment will be updated.

Summary 	 Fig18 - Mission. Suggest this is removed. It was a mistake in MODAF. Missions should be concerned with operational stuff, not the enterprise itself. Better to use Enterprise Goals and Visions.	
Diagram 	 AV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution	 Move Mission out of Core and into DoDAF Only\OperationalElements\Structure.

Fig18 - ArchitecturalDescription. ApprovalAuthority and CreatingOrganisation tags are typed as ActualOrganisationalResource. I can see the logic behind this, but it does raise a problem of putting the architect in the architecture. Need an approach to ensure these don't get mixed up with the elements in the OV-4, for example.	
Diagram 	 AV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com


Resolution: The ActualPosts and ActualOrganizations can just be partitioned off into a separate part of the model.  They also, at some point, may become part of an ontology and therefore become ExternalIndividuals, etc.  This isn't seen as a problem.

The ActualPosts and ActualOrganizations can just be partitioned off into a separate part of the model.  They also, at some point, may become part of an ontology and therefore become ExternalIndividuals, etc.  This isn't seen as a problem.
Disposition:	Closed, no change

Summary 	 Fig19 - Ontology Reference. Can you change the URL to be rdfID (i.e. an RDF:ID, which is a URL, but it's better to be precise). Might also be wise to add an optional [0..1] attribute for UUID (an Open-Group version 4 GUID).	
Diagram 	 AV
Document Issue	UPDM (OMG Beta) Jan 2009
Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution Update the tag as specified.

Fig19 - StereotypeExtension. This only works for ExternalType (it makes no sense for ExternalIndividual). Please point it at externalType (i.e. not OntologyReference). This was a mistake in MODAF.	
Diagram 	 AV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution	 Update the StereotypeExtension as specified.

Summary 	 Fig19 - Use of Ontology & Generalization. It's not clear in MODAF, but you should make it clear here. The ontology can be referenced through the StereotypeExtension mechanism, or simply by importing the ontology element into the architecture as an OntologyReference (actually as a subtype of OntologyReference, as it's abstract).	
Diagram 	 AV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution	 Update the document as specified.

Summary 	 Fig20 - AV3? Is UPDM introducing new views? Strongly suggest you stick to supporting the frameworks and let the MOD and DoD decide what is in those frameworks…don't want a repeat of UPDM 1.	
Diagram 	 AV
Document Issue	UPDM (OMG Beta) Jan 2009
Section	
Page	
Priority	 Low
Source	 Ian BaileyModel Futuresian@modelfutures.com
Date	 3rd March 2009
Rationale	
Resolution	 The AV-3 is used to define ActualMeasurementSets/MeasurementSets as it appeared to be missing from MODAF.  MODAF supports the addition of custom views and the views in UPDM are non-normative, so this isn't seen as an issue.

Summary 	 Fig21 - SameAs. The SameAs trace in MODAF is for referring to external objects. The way it is used here, it can be used to say two things in the architecture are the same. This breaks a major design tenet in MODAF - Use Once, Re-Use Many Times. Redundancy must be prevented in architectural models. This needs fixing.	
Diagram 	 AV
Document Issue	UPDM (OMG Beta) Jan 2009
Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution	 This isn't clear in MODAF 1.2 so if we fix this in UPDM we should also raise an issue on MODAF.We'll change the metaConstraint so that the "supplier" role is constrained to ExternalType/ExternalIndividual instead of UPDMElement.  The "client " role will stay constrained to UPDMElement.

Fig27 & Fig28 & Fig29 - Climate, etc. Bit of a problem with this…and with capability usage in general. See later (StV-2 & OV-2) comments on capability metrics and MoEs. Recommend we talk this stuff through face-to-face or over telecon.	
Diagram 	 AV
Document Issue	UPDM (OMG Beta) Jan 2009
	
Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution	 POTENTIAL SOLUTION:Find out what the problem is…

7.1.2.5.1 - ActualMeasurement. Definition makes no sense. "Friendly" ? Also, if Actual____ is meant to be an individual instance of something, is this really an actual measurement ? If so, of what?	
Diagram 	 AV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution	 Review and update the description as required.

Summary 	 7.1.2.5.3 - Measures. I assumed the SysML measure model would be used here rather than MODAF's. We need to be able to represent types of measure (e.g. velocity, weight, etc.), units, required property values (actually all this needs be is a property in a to-be enterprise) and actual property values (i.e. a property on an element in an as-is architecture). Think we need to talk about this.	
Diagram 	 AV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution	 Talk to Ian to explain the SysML mapping and potentially update the document to make this clearer.

Summary 	 Figure 44 - Title. The stereotyping of specific views was a major comment on UPDM1. Assumed it was not in this UPDM for that reason.	
Diagram 	 OV
Document Issue	UPDM (OMG Beta) Jan 2009
Section	
Page	
Priority	 Low
Source	 Ian BaileyModel Futuresian@modelfutures.com
Date	 3rd March 2009
Rationale	
Resolution	 The Views are left as non-normative and all the SysML elements have been removed from UPDM L0.  A lot of tools don't support the View/Import mechanism in the same way (if at all) so we removed it to keep conformance more flexible.Assuming the issue is about them being missing from the specification and requiring adding, this issue can be set to rejected.

The Views are left as non-normative and all the SysML elements have been removed from UPDM L0.  A lot of tools don't support the View/Import mechanism in the same way (if at all) so we removed it to keep conformance more flexible.
Assuming the issue is about them being missing from the specification and requiring adding, this issue can be set to rejected.
Disposition:	Closed, no change

Fig44 - NodeType. Don't see NodeType in here ! The concept has been used on a number of UK projects, so if it's not in UPDM it will be a problem for MOD. Remember, an OV-2 may contain several nodes of the same type. Each might be performing different operational activities. If we could start again with MODAF, we would get rid of NodeTypes. If you've got rid of the idea here, then it needs to be documented VERY clearly how a MODAF architecture with multiple nodes of the same type will map onto UPDM. I would suggest that a new UPDM:Node (Class) be created for every MODAF:Node(property).	
Diagram 	 OV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution	 POTENTIAL SOLUTION:MODAF::Node is equivalent to UPDM::NodeRole and MODAF::NodeType is equivalent to UPDM::Node.  We should consider adding a MODAF mapping table or more aliases, as the name changes seem to have thrown some people.We will consult with the other architects, etc.

Fig44 - RequiresCapability. This does not make sense. An OV-2 may be depicting a simplified representation of an as-is architecture - hence it is not a requirement. Please change this to "ExhibitsCapability"	
Diagram 	 OV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com


Resolution	 POTENTIAL SOLUTION:Change the name of the stereotype (if it doesn't become merged as part of [UPDM_00098 / OMG Issue 13580]).

Summary 	 Top of Page 37 - "OV-2 does not depict the connectivity between the nodes". Oh yes it does, hence the name of OV-2 being "operational node relationship description".	
Diagram 	 OV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution	 Remove the incorrect text.

No such thing as OV-2a. It's really important to get OV-2 right, as it's a pivotal view in MODAF. Suggest we discuss this.	
Diagram 	 OV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution	 Remove the incorrect text.

Fig44 - ExternalNode. This concept is (probably) represented by things outside the ProblemDomain (TradeSpace in UPDM) in MODAF - there is no need for a new node for this. The definition is very unclear - "outside the architecture" is clearly nonsense, as it's in the architecture the minute you drop it on the page.If this remains in UPDM it is likely to get a MODAF non-compliance. Remember, this is enterprise architecture, NOT systems engineering. Nothing is out of scope in EA if it relates to the problem being examined.	
Diagram 	 OV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution	 Remove the stereotype as not required by DoDAF or MODAF.

Fig44 - NodePort. There is no need for this in OV-2. I realise it's here because a number of UML tools can't do composite class diagrams without ports. One of the main purposes of OV-2 is to communicate a logical architecture in a simple, uncluttered manner. Ports are not likely to help with this (the main users of OV-2 don't tend to be UML fans anyway).	
Diagram 	 OV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com

Resolution	 NodePorts are required for people trying to use a SysML approach in conjunction with UPDM.  We should document that the NodePorts don't have to be used and they're there to provide a more detailed view if it's required.Another reason to include them is that they were specifically requested as a TRADOC requirement.

Summary 	 Page 37 - SOA. The documentation says; "In addition, MoDAF permits service-oriented architectures.Instead of needlines between nodes, it is possible simply to show which services the nodes provide and consume." But…there's nothing in fig44 to show how this might be done.	
Diagram 	 OV
Document Issue	UPDM (OMG Beta) Jan 2009
Section	
Page	
Priority	 High
Source	 Ian BaileyModel Futuresian@modelfutures.com
Date	 3rd March 2009
Rationale	
Resolution	 We will add Service and Request ports to Nodes.

Summary 	 Fig45 - NodeChild. This is quite hard to understand, but seems to imply that a KnownResource can be part of a Node…which it can't. This must be fixed.	
Diagram 	 OV
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Ian BaileyModel Futuresian@modelfutures.com
	
Resolution	 Limit KnownResource to only be owned by a LogicalArchitecture.This seems very limiting and doesn't support DoDAF - which seems to allow OperationalRoles (the equivalent of KnownResources) inside Nodes.  Either KnownResource should be removed altogether, or they should be allowed to be owned by Nodes.  Since it's required for DoDAF and seems to be quite an important concept, we will leave it as it is.To support this decision, we'll add some text to KnownResource to make it clear that in MODAF you should limit these to only being owned by LogicalArchitectures (though we should also raise an issue on MODAF to change this too).

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.

 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.

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.
Disposition:	Closed, no change

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.
	

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.
Disposition:	Closed, no change

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.

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

The tags are derived so there's no need for any constraints (they're populated dynamically).
Disposition:	Closed, no change

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.
	

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.
Disposition:	Closed, no change

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.

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.

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.
	

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.

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.

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.

The reason that the ServiceInterface to ServiceFunction relationship isn't via "Performs" is because a ServiceInterface doesn't perform anything.  The ServiceFunction is used to describe the abstract behaviour of the interface to give users/implementers of the service an idea of what the interface is for. 
Disposition:	Closed, no change

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.

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.
	

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.
	

We will leave it where it is so that EnterpriseGoals can be used as part of multiple EnterpriseVisions.
Example of Goals and vision required in Doc. 
The current implementation is consistent with MODAF 1.2 and as such there is no issue.
Disposition:	Closed, no change

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.

Sounds sensible but not essential.  We will defer this to the next version of UPDM.
Covered in L1 by satisfy or refine etc from SysML or trace from UML
Disposition:	Closed, no change

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.

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

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

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.

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.

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.

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.

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.
Disposition:	Closed, no change

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

This matches the MODAF 1.2 specification (SystemPortConnector is a specialization of ProtocolImplementation).
Disposition:	Closed, no change

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.

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.

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.

Need to add the missing contraints decide where they need to be applied i.e. on the dependencies or on the ends
Currently only one end,

Constraints already exist on Node and Resource. In combination with constraints on Performs, they will ensure that correct pairs are connected.
Disposition:	Closed, no change

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

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.
	

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

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)

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?

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.

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

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. 

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.

Summary 	 Add the ability for Node to own ServiceOperations	
Diagram 	
Document Issue	UPDM (OMG Beta) Jan 2009
	
Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com
	

Summary 	 Add DataElement as SubjectOfResourceStateMachine. Consistence with OVs is needed	
Diagram 	
Document Issue	UPDM (OMG Beta) Jan 2009
	
Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Some Service elements have to be substituted with SoaML elements

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

DMM and Profile are not synchronized

Constraints between FunctionAction and FunctionEdge are too limiting

In order to keep the profile useable and consistent between OV/SV, there’s a number of derived tags that require removing/renaming or adding.  The following changes need to be made:

·         Remove the ResourceInterface.contributesTo tag – it’s duplicating one that’s inherited from SystemsElement.

·         Remove the Needline.implementedBy tag – it’s duplicating one that’s inherited from OperationalElement.

·         Remove the NodeChild.owningNode tag – it’s duplicating a UML role and provides no useful purpose.

·         Rename Needline.exchangedItem to Needline.realizedExchange – the current name is misleading.

·         Add a realizedExchange tag (typed by ResourceInteraction) to ResourceInterface and ResourceConnector – to mirror the functionality of a Needline.

·         Remove the ResourceRole.owningResource tag – it’s duplicating a UML role and provides no useful purpose