Unified Profile for DoDAF and MODAF Avatar
  1. OMG Specification

Unified Profile for DoDAF and MODAF — Open Issues

  • Acronym: UPDM
  • Issues Count: 471
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
UPDM11-31 Fig 14 & Fig 16 - Consistent Profile Usage UPDM 1.0b1 open
UPDM11-32 Fig19 - More Needed Here UPDM 1.0b1 open
UPDM-774 Section: 7.3.2 UPDM 1.0b1 open
UPDM-773 Section 6: 'Class Library' should be 'Model Library' UPDM 1.0b1 open
UPDM-772 Section 6: list of XMI files for the compliance levels UPDM 1.0b1 open
UPDM-478 CapabilityRequirementCapability is duplicated UPDM 1.0b1 open
UPDM-477 CapabilityOperationalCapability is duplicated UPDM 1.0b1 open
UPDM-476 Connection between OperationalActivity and SystemFunction is not traceable UPDM 1.0b1 open
UPDM-475 Stereotyped Associations Notation UPDM 1.0b1 open
UPDM-474 8.4.5 UPDM 1.0b1 open
UPDM-473 CapabilityComposition UPDM 1.0b1 open
UPDM-472 Competence, Actual Competence UPDM 1.0b1 open
UPDM-471 OrganizationType, ActualOrganization UPDM 1.0b1 open
UPDM-470 PostType, Actual Post UPDM 1.0b1 open
UPDM-465 8.6.20:ServiceSpecification UPDM 1.0b1 open
UPDM-464 Conforming Element UPDM 1.0b1 open
UPDM-460 8.4.29:OperationalTask UPDM 1.0b1 open
UPDM-459 8.4.21.6 :Constraints UPDM 1.0b1 open
UPDM-461 8.4.29.6:OperationalTask Constraints UPDM 1.0b1 open
UPDM-458 8.4.19:OperationalControlFlow UPDM 1.0b1 open
UPDM-457 8.4.14.5:OperationalCapability Associations UPDM 1.0b1 open
UPDM-463 AllViews UPDM 1.0b1 open
UPDM-462 8.4.41.5 :Associations oPolicy UPDM 1.0b1 open
UPDM-456 8.4.13.6 :OperationalActivity Constraints UPDM 1.0b1 open
UPDM-455 8.4.13.5:OperationalActivity Associations UPDM 1.0b1 open
UPDM-469 ActualLocation UPDM 1.0b1 open
UPDM-468 8.5.4:Capability UPDM 1.0b1 open
UPDM-467 UPDM Package Structure UPDM 1.0b1 open
UPDM-466 7.2 UPDM Architecture Figure UPDM 1.0b1 open
UPDM-449 8.3.17.68:Resource Constraints UPDM 1.0b1 open
UPDM-448 Missing instance stereotype for compatibility with MODAF UPDM 1.0b1 open
UPDM-447 TechnicalStandardsProfile UPDM 1.0b1 open
UPDM-452 8.4.3:Asset UPDM 1.0b1 open
UPDM-451 8.3.24.3:Vision Description UPDM 1.0b1 open
UPDM-450 8.3.21.6 :Strategic Mission Constraints UPDM 1.0b1 open
UPDM-454 8.4.12.6: Needline Constraints UPDM 1.0b1 open
UPDM-453 8.4.7.6: InformationElement Constraints UPDM 1.0b1 open
UPDM-444 SystemsNode UPDM 1.0b1 open
UPDM-443 SystemServiceProvider, SystemServiceConsumer UPDM 1.0b1 open
UPDM-446 Standard UPDM 1.0b1 open
UPDM-445 SystemTask UPDM 1.0b1 open
UPDM-442 SystemPort UPDM 1.0b1 open
UPDM-441 SystemInterface UPDM 1.0b1 open
UPDM-439 SystemFunction UPDM 1.0b1 open
UPDM-438 System UPDM 1.0b1 open
UPDM-440 SystemGroup UPDM 1.0b1 open
UPDM-435 OperationalActivityRealization UPDM 1.0b1 open
UPDM-434 Location UPDM 1.0b1 open
UPDM-433 DataExchange UPDM 1.0b1 open
UPDM-437 Service UPDM 1.0b1 open
UPDM-436 RealizedSystemSpecification, SystemFunctionSpecification UPDM 1.0b1 open
UPDM-429 Systems Views UPDM 1.0b1 open
UPDM-428 ResouceCapabilityConfiguration UPDM 1.0b1 open
UPDM-427 ResourceCapability UPDM 1.0b1 open
UPDM-426 CapabilityRequirementCapability UPDM 1.0b1 open
UPDM-432 CommunicationSystem UPDM 1.0b1 open
UPDM-431 CommunicationPath UPDM 1.0b1 open
UPDM-430 CommunicationLink UPDM 1.0b1 open
UPDM-421 Capability.isFielded UPDM 1.0b1 open
UPDM-420 Capability UPDM 1.0b1 open
UPDM-425 CapabilityRequirement UPDM 1.0b1 open
UPDM-424 CapabilityOperationalCapability UPDM 1.0b1 open
UPDM-419 Strategic Views UPDM 1.0b1 open
UPDM-423 CapabilityConfigurationCapabilities UPDM 1.0b1 open
UPDM-422 CapabilityConfiguration UPDM 1.0b1 open
UPDM-408 OperationalNode UPDM 1.0b1 open
UPDM-407 OperationalInformationFlow UPDM 1.0b1 open
UPDM-411 OperationalServiceConsumer, Operational ServiceProvider UPDM 1.0b1 open
UPDM-406 OperationalEventTrace UPDM 1.0b1 open
UPDM-405 OperationalControlFlow UPDM 1.0b1 open
UPDM-413 OperationalTask UPDM 1.0b1 open
UPDM-412 OperationalStateTrace UPDM 1.0b1 open
UPDM-417 Policy UPDM 1.0b1 open
UPDM-416 OrganizationalRole UPDM 1.0b1 open
UPDM-415 OrganizationalResource UPDM 1.0b1 open
UPDM-414 OrganizationalRelationship UPDM 1.0b1 open
UPDM-404 OperationalCapabilityRoleResource UPDM 1.0b1 open
UPDM-403 OperationalCapabilityRole UPDM 1.0b1 open
UPDM-410 OperationalRole UPDM 1.0b1 open
UPDM-418 RealizedOperationalCapability UPDM 1.0b1 open
UPDM-409 OperationalNodePort UPDM 1.0b1 open
UPDM-398 MaterielNode UPDM 1.0b1 open
UPDM-397 MaterielBehavior UPDM 1.0b1 open
UPDM-396 Materiel UPDM 1.0b1 open
UPDM-392 ActivityRealization UPDM 1.0b1 open
UPDM-391 Operational Views UPDM 1.0b1 open
UPDM-389 UPDMAttributes UPDM 1.0b1 open
UPDM-388 Resource UPDM 1.0b1 open
UPDM-395 InformationElement UPDM 1.0b1 open
UPDM-394 AssetMapping UPDM 1.0b1 open
UPDM-400 OperationalCapability UPDM 1.0b1 open
UPDM-399 Needline UPDM 1.0b1 open
UPDM-402 OperationalCapabilityRealization Definition UPDM 1.0b1 open
UPDM-401 OperationalCapabilityRealization UPDM 1.0b1 open
UPDM-390 Enterprise & Vision UPDM 1.0b1 open
UPDM-393 Asset UPDM 1.0b1 open
UPDM-373 System views UPDM 1.0b1 open
UPDM-372 Operational views UPDM 1.0b1 open
UPDM-371 Strategic views UPDM 1.0b1 open
UPDM-377 AcV-1: System of Systems Acquisition Clusters UPDM 1.0b1 open
UPDM-376 Acquisition Views UPDM 1.0b1 open
UPDM-375 Acquisition views UPDM 1.0b1 open
UPDM-374 Technical views UPDM 1.0b1 open
UPDM-381 MilestonePoint UPDM 1.0b1 open
UPDM-380 Milestone UPDM 1.0b1 open
UPDM-379 DLOD Issue Types UPDM 1.0b1 open
UPDM-378 DLOD Elements UPDM 1.0b1 open
UPDM-370 All views UPDM 1.0b1 open
UPDM-369 General comparison UPDM 1.0b1 open
UPDM-384 All Views UPDM 1.0b1 open
UPDM-383 ProjectType specialises from Project UPDM 1.0b1 open
UPDM-382 Project UPDM 1.0b1 open
UPDM-366 Milestone UPDM 1.0b1 open
UPDM-365 Acquisition views DLODelements UPDM 1.0b1 open
UPDM-364 SystemSystemSoftware UPDM 1.0b1 open
UPDM-386 ArchitectureView UPDM 1.0b1 open
UPDM-385 ArchitectureSummary UPDM 1.0b1 open
UPDM-368 DLODIssueType UPDM 1.0b1 open
UPDM-367 Project/ ProjectType UPDM 1.0b1 open
UPDM-360 Service UPDM 1.0b1 open
UPDM-359 OperationalActivityRealization UPDM 1.0b1 open
UPDM-358 Network/ NetworkPaths UPDM 1.0b1 open
UPDM-340 OperationalActivity UPDM 1.0b1 open
UPDM-339 Materiel/ MaterielBehavior/ MaterielNode UPDM 1.0b1 open
UPDM-345 OperationalNodePort UPDM 1.0b1 open
UPDM-344 OperationalNode UPDM 1.0b1 open
UPDM-343 OperationalCapabilityRole/ OperationalCapabilityRoleCompetence UPDM 1.0b1 open
UPDM-348 OperationalServiceConsumer/ OperationalServiceProvider UPDM 1.0b1 open
UPDM-347 OperationalRole/ OperationalCapabilityRole/ OrganisationalRole UPDM 1.0b1 open
UPDM-346 OperationalNodeSpecification UPDM 1.0b1 open
UPDM-350 OrganisationalRelationship UPDM 1.0b1 open
UPDM-349 OperationalTask UPDM 1.0b1 open
UPDM-353 ResultsOfEffect UPDM 1.0b1 open
UPDM-352 Policy/ Rule UPDM 1.0b1 open
UPDM-351 OrganisationalResource UPDM 1.0b1 open
UPDM-357 DataElementSystemFunction UPDM 1.0b1 open
UPDM-356 System views UPDM 1.0b1 open
UPDM-342 OperationalCapabilityRealization UPDM 1.0b1 open
UPDM-341 OperationalCapability UPDM 1.0b1 open
UPDM-355 RealizedOperaionalSpecification UPDM 1.0b1 open
UPDM-354 ResultsOfEffect UPDM 1.0b1 open
UPDM-387 PerformanceMeasureSet UPDM 1.0b1 open
UPDM-363 SystemsNode/ SystemsNodeElements UPDM 1.0b1 open
UPDM-362 SystemServiceConsumer/ SystemServiceProvider UPDM 1.0b1 open
UPDM-361 ServiceSpecification UPDM 1.0b1 open
UPDM-327 StrategicMission UPDM 1.0b1 open
UPDM-326 Concern/ Stakeholder/ StakeholderConcern UPDM 1.0b1 open
UPDM-325 Resource UPDM 1.0b1 open
UPDM-330 CapabilityConfiguration UPDM 1.0b1 open
UPDM-329 Capability UPDM 1.0b1 open
UPDM-328 ExternalReferenceType/ InformationAssurance/ Security UPDM 1.0b1 open
UPDM-338 Asset/ AssetMapping UPDM 1.0b1 open
UPDM-337 Operational views - ActivityRealization UPDM 1.0b1 open
UPDM-334 Effect/ CausesEffect/ EffectAffectsNode/ NodeCausesEffect/ OperationalCapab UPDM 1.0b1 open
UPDM-333 CapabilityRequirement/ CapabilityRequirementCapability UPDM 1.0b1 open
UPDM-336 OperationalNodeCapabilityRequirement UPDM 1.0b1 open
UPDM-335 OperationalNodeCapabilityRequirement UPDM 1.0b1 open
UPDM-324 PerformanceMeasureSet/ PerformanceParameterSet/ PerformanceParameterTyp UPDM 1.0b1 open
UPDM-323 Goal UPDM 1.0b1 open
UPDM-332 CapabilityOperationalCapability UPDM 1.0b1 open
UPDM-331 CapabilityConfigurationCapability UPDM 1.0b1 open
UPDM-322 Enterprise UPDM 1.0b1 open
UPDM-321 Doctrine UPDM 1.0b1 open
UPDM-320 ArchitectureDescription UPDM 1.0b1 open
UPDM-319 Swedish Armed Forces General Comments UPDM 1.0b1 open
UPDM-318 Ambiguos relation between Forecast and Milestone UPDM 1.0b1 open
UPDM-304 GroupForecast metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-303 ForecastStandardsProfile metaclass should be Usage or Dependency. UPDM 1.0b1 open
UPDM-302 EffectAffectsNode metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-306 NodeCausesEffect metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-305 MilestonePoint metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-313 ResourceCapability metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-312 OrganizationalResourceCapabilityConfiguration metaclass UPDM 1.0b1 open
UPDM-311 OrganizationalRelationship metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-310 OperationalNodeCapabilityRequirement metaclass should be Usage or Dependenc UPDM 1.0b1 open
UPDM-309 OperationalCapabilityRoleResource metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-308 OperationalCapabilityRoleCompetence metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-315 ResourceCompetence metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-314 ResourceCapabilityConfiguration metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-317 SystemsNodeElements metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-316 SystemGroupMember metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-307 OperationalCapabilityEffect should be Usage or Dependency UPDM 1.0b1 open
UPDM-292 8.6.37.3 Description UPDM 1.0b1 open
UPDM-291 8.6.36.3 Description UPDM 1.0b1 open
UPDM-299 CapabilityOperationalCapability metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-298 CapabilityConfigurationCapabilities metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-301 DeliveredCapability metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-300 CapabilityRequirementCapability metaclass should be Usage or Dependency UPDM 1.0b1 open
UPDM-290 8.6.35.3 Description UPDM 1.0b1 open
UPDM-289 8.6.34.3 Description UPDM 1.0b1 open
UPDM-286 8.6.15.3 Description UPDM 1.0b1 open
UPDM-285 8.6.14.3 Description UPDM 1.0b1 open
UPDM-297 ActivityRealization metaclass should be Realization UPDM 1.0b1 open
UPDM-296 8.7.2.3 Description UPDM 1.0b1 open
UPDM-288 8.6.18.3 Description UPDM 1.0b1 open
UPDM-287 8.6.17.3 Description UPDM 1.0b1 open
UPDM-295 8.6.48.3 Description UPDM 1.0b1 open
UPDM-294 8.6.39.3 Description UPDM 1.0b1 open
UPDM-293 8.6.38.3 Description UPDM 1.0b1 open
UPDM-276 8.5.13.3 Description UPDM 1.0b1 open
UPDM-275 8.5.10.3 Description UPDM 1.0b1 open
UPDM-274 8.5.9.3 Description UPDM 1.0b1 open
UPDM-273 8.5.8.3 Description UPDM 1.0b1 open
UPDM-280 8.6.5.3 Description UPDM 1.0b1 open
UPDM-279 8.6.3.3 Description UPDM 1.0b1 open
UPDM-284 8.6.12.3 Description UPDM 1.0b1 open
UPDM-283 8.6.9.3 Description UPDM 1.0b1 open
UPDM-282 8.6.7.3 Description UPDM 1.0b1 open
UPDM-281 8.6.6.3 Description UPDM 1.0b1 open
UPDM-271 8.4.45.3 Description UPDM 1.0b1 open
UPDM-270 8.4.43.3 Description UPDM 1.0b1 open
UPDM-278 8.5.17.3 Description UPDM 1.0b1 open
UPDM-277 8.5.16.3 Description UPDM 1.0b1 open
UPDM-269 8.4.31.3 Description UPDM 1.0b1 open
UPDM-268 8.4.28.3 Description UPDM 1.0b1 open
UPDM-272 8.4.47.3 Description UPDM 1.0b1 open
UPDM-261 8.3.18.3 Description UPDM 1.0b1 open
UPDM-260 8.3.16.3 Description UPDM 1.0b1 open
UPDM-256 Description is not sufficient. UPDM 1.0b1 open
UPDM-255 Text needs to be updated, since DeployedToSystemsNode does not exist UPDM 1.0b1 open
UPDM-259 8.3.15.3 Description UPDM 1.0b1 open
UPDM-258 8.3.14.3 Description UPDM 1.0b1 open
UPDM-267 8.4.23.3 Description UPDM 1.0b1 open
UPDM-266 8.4.19.3 Description UPDM 1.0b1 open
UPDM-265 8.4.17.3 Description UPDM 1.0b1 open
UPDM-264 8.4.14.3 Description UPDM 1.0b1 open
UPDM-263 8.4.6.3 Description UPDM 1.0b1 open
UPDM-262 8.3.22.3 Description UPDM 1.0b1 open
UPDM-252 Stereotype for realization CommunicationsPathRealizesSystemInterface UPDM 1.0b1 open
UPDM-251 Stereotype for realization RealizedOperationalCapability is too long UPDM 1.0b1 open
UPDM-254 Stereotype for interface realization RealizedSystemSpecification UPDM 1.0b1 open
UPDM-253 Stereotype for interface realization RealizedOperationalSpecification UPDM 1.0b1 open
UPDM-257 8.3.10.3 Description UPDM 1.0b1 open
UPDM-244 Sterotype for Association name ResourceCapability is not intuitive UPDM 1.0b1 open
UPDM-246 Sterotype for Association name ResourceCompetence is not intuitive UPDM 1.0b1 open
UPDM-245 Sterotype for Association name ResourceCapabilityConfiguration UPDM 1.0b1 open
UPDM-248 Sterotype for Association name SystemsNodeElements UPDM 1.0b1 open
UPDM-247 Sterotype for Association name SystemGroupMember is not intuitive UPDM 1.0b1 open
UPDM-250 Stereotype for dependency AssetMapping is not intuitive UPDM 1.0b1 open
UPDM-249 Stereotype for dependency CompetenceRelationship is not intuitive UPDM 1.0b1 open
UPDM-243 Sterotype for Association name OrganizationalResourceCapabilityConfiguratio UPDM 1.0b1 open
UPDM-242 Sterotype for Association name OperationalNodeCapabilityRequirement UPDM 1.0b1 open
UPDM-241 Sterotype for Association name OperationalCapabilityRoleResource UPDM 1.0b1 open
UPDM-234 Sterotype for Association name ForecastStandardsProfile UPDM 1.0b1 open
UPDM-233 Sterotype for Association name EffectAffectsNode is not nice UPDM 1.0b1 open
UPDM-238 Sterotype for Association name NodeCausesEffect is not nice UPDM 1.0b1 open
UPDM-237 Sterotype for Association name MilestonePoint is not intuitive UPDM 1.0b1 open
UPDM-240 Sterotype for Association name OperationalCapabilityRoleCompetence UPDM 1.0b1 open
UPDM-239 Sterotype for Association name OperationalCapabilityEffect UPDM 1.0b1 open
UPDM-236 Sterotype for Association name MaterielBehavior is not intuitive UPDM 1.0b1 open
UPDM-235 Sterotype for Association name MaterielNode is not intuitive UPDM 1.0b1 open
UPDM-225 8.3.11:Doctrine UPDM 1.0b1 open
UPDM-224 8.4.32:OrganizationalResource UPDM 1.0b1 open
UPDM-223 8.3.8:Concern UPDM 1.0b1 open
UPDM-222 8.3.19:Stakeholder UPDM 1.0b1 open
UPDM-217 8.4.13.5:OperationalActivity Associations UPDM 1.0b1 open
UPDM-216 8.4.13.6:OperationalActivity Constratins UPDM 1.0b1 open
UPDM-221 8.2.11:Project Type UPDM 1.0b1 open
UPDM-220 8.2.10:Project -- 8.2.10.6 Constraints UPDM 1.0b1 open
UPDM-229 Reusable libraries cannot be created on order to model a SV-9. UPDM 1.0b1 open
UPDM-228 TimedTechnologyForecast UPDM 1.0b1 open
UPDM-230 MOD Agreement Issue UPDM 1.0b1 open
UPDM-232 Sterotype for Association name CapabilityConfigurationCapabilities UPDM 1.0b1 open
UPDM-231 Navigability for association UPDM 1.0b1 open
UPDM-227 ProjectType has a generalization link to Project. UPDM 1.0b1 open
UPDM-226 8.3.13:Goal UPDM 1.0b1 open
UPDM-219 8.2.10:Project UPDM 1.0b1 open
UPDM-218 8.2.8:Milestone UPDM 1.0b1 open
UPDM-213 8.4.22:OperationalNode UPDM 1.0b1 open
UPDM-212 8.4.13.3:OperationalActivity UPDM 1.0b1 open
UPDM-211 8.6.48:SystemsNodeElements (03) UPDM 1.0b1 open
UPDM-215 8.6.52:SystemTask UPDM 1.0b1 open
UPDM-214 8.4.29:OperationalTask UPDM 1.0b1 open
UPDM-204 Why TechnicalStandardsProfile is a ConformingElement. UPDM 1.0b1 open
UPDM-203 System stereotype is lost if the instance of System class is created UPDM 1.0b1 open
UPDM-201 getAppliedStereotype OCL construct does not exist UPDM 1.0b1 open
UPDM-200 Section 4.3.4.6 UPDM 1.0b1 open
UPDM-199 Section 4.3.4.5 UPDM 1.0b1 open
UPDM-198 Section 4.3.4.3 UPDM 1.0b1 open
UPDM-206 PerformanceMeasurePeriod or PerformanceMeasurementPeriod UPDM 1.0b1 open
UPDM-205 TechnicalStandardsProfile should extend a Package UPDM 1.0b1 open
UPDM-208 Rule is in the OperationalView package UPDM 1.0b1 open
UPDM-207 PerformanceMeasurePeriod is in OperationalView package UPDM 1.0b1 open
UPDM-210 8.6.48:SystemsNodeElements (02) UPDM 1.0b1 open
UPDM-209 8.6.48:SystemsNodeElements (01) UPDM 1.0b1 open
UPDM-202 View/Viewpoint should be imported from SysML, not redefined UPDM 1.0b1 open
UPDM-184 Fig. 8.31 UPDM 1.0b1 open
UPDM-183 Goal, Policy, Standard and Doctrine UPDM 1.0b1 open
UPDM-190 Technologies should be first class objects UPDM 1.0b1 open
UPDM-189 Section 8.4.44 UPDM 1.0b1 open
UPDM-182 Section 8.7.3 Association between Standard and ConformingElement UPDM 1.0b1 open
UPDM-181 Section 8.7.3 UPDM 1.0b1 open
UPDM-188 UML composite structure should be reused UPDM 1.0b1 open
UPDM-187 Section 8.5.10 UPDM 1.0b1 open
UPDM-197 Section 4.3.3.3 UPDM 1.0b1 open
UPDM-196 Section 5.2.1 UPDM 1.0b1 open
UPDM-195 Figure 3-3: AcV-2 View Example UPDM 1.0b1 open
UPDM-194 Section 4.2.4.3 UPDM 1.0b1 open
UPDM-193 Qualified name in the OCL constraints should be full UPDM 1.0b1 open
UPDM-192 Section 8.5.5 UPDM 1.0b1 open
UPDM-186 Section 8.4.32.9 UPDM 1.0b1 open
UPDM-185 Section 8.4.23 - Why OperationalNodePort is needed UPDM 1.0b1 open
UPDM-191 Section 8.5.4 UPDM 1.0b1 open
UPDM-180 Section 8.3.11 UPDM 1.0b1 open
UPDM-179 Section 8.4.41 UPDM 1.0b1 open
UPDM-178 Section 8.5.6 UPDM 1.0b1 open
UPDM-173 CommunicationsLink/Path/System vs CommunicationLink/Path/System UPDM 1.0b1 open
UPDM-172 Section 8.3.10 UPDM 1.0b1 open
UPDM-166 Section 8.4.46 UPDM 1.0b1 open
UPDM-165 MaterielBehavior is not needed - Section 8.4.10 UPDM 1.0b1 open
UPDM-168 Section 8.3.14.6 UPDM 1.0b1 open
UPDM-167 Section 8.4.47 UPDM 1.0b1 open
UPDM-177 Possible conflict between Viewpoint/Stakeholder/Concern in UPDM and SysML UPDM 1.0b1 open
UPDM-176 Section 8.3.23 UPDM 1.0b1 open
UPDM-164 Section 8.4.2 UPDM 1.0b1 open
UPDM-163 inconsistencies UPDM 1.0b1 open
UPDM-175 Section 8.6.11.6 UPDM 1.0b1 open
UPDM-174 Section 8.4.8.6 UPDM 1.0b1 open
UPDM-170 Fig. 8.27 UPDM 1.0b1 open
UPDM-169 Section 8.3.16.6 UPDM 1.0b1 open
UPDM-171 Section 8.3.10.3 UPDM 1.0b1 open
UPDM-155 Section 8.6.15 UPDM 1.0b1 open
UPDM-154 Section 8.6.15.3 UPDM 1.0b1 open
UPDM-158 Section 8.6.10 UPDM 1.0b1 open
UPDM-157 Section 8.6.4 UPDM 1.0b1 open
UPDM-160 Section 8.6.18.3 UPDM 1.0b1 open
UPDM-159 Section 8.6.3 UPDM 1.0b1 open
UPDM-153 Section 8.6.4.5 UPDM 1.0b1 open
UPDM-152 Section 8.6.5 UPDM 1.0b1 open
UPDM-148 Why do you need a SystemPort if it does not add any new information, 8.6.44 UPDM 1.0b1 open
UPDM-147 Section 8.6.11 UPDM 1.0b1 open
UPDM-162 Section 8.4.2 UPDM 1.0b1 open
UPDM-161 Fig. 8.142 UPDM 1.0b1 open
UPDM-150 How can you show the CommunicationPathRealizesSystemInterface?, UPDM 1.0b1 open
UPDM-149 Section 8.6.3 UPDM 1.0b1 open
UPDM-151 Section 8.6.4 UPDM 1.0b1 open
UPDM-156 Section 8.6.48 UPDM 1.0b1 open
UPDM-140 CompetenceRelationship UPDM 1.0b1 open
UPDM-139 time/date related attributes UPDM 1.0b1 open
UPDM-138 Section 8..4.22.4 UPDM 1.0b1 open
UPDM-146 Section 8.6.33.3 UPDM 1.0b1 open
UPDM-145 System description should talk about linking to the SystemFunctions UPDM 1.0b1 open
UPDM-144 SystemTask should have SystemFunction as method property? UPDM 1.0b1 open
UPDM-143 SystemActivityFunction is used in examples., p. 398 UPDM 1.0b1 open
UPDM-142 InterfaceRealization UPDM 1.0b1 open
UPDM-141 OrganizationalRelationship UPDM 1.0b1 open
UPDM-134 Figure 8.163 UPDM 1.0b1 open
UPDM-133 Sections 9.2.2 and 8.2.7 UPDM 1.0b1 open
UPDM-132 Table 9.2: Table of enumeration literals contains duplicates UPDM 1.0b1 open
UPDM-131 Section 8.3.22.3 UPDM 1.0b1 open
UPDM-137 Section 8.4.28.3 UPDM 1.0b1 open
UPDM-136 Section 8.6.43 UPDM 1.0b1 open
UPDM-130 Section 8.7.4.4 UPDM 1.0b1 open
UPDM-129 Sections 8.6.53 and 8.1 UPDM 1.0b1 open
UPDM-135 Figures 8.23 and 8.161 UPDM 1.0b1 open
UPDM-116 Fig. 8.120 UPDM 1.0b1 open
UPDM-115 Section 8.6.10 UPDM 1.0b1 open
UPDM-121 Section 8.6.30.3 UPDM 1.0b1 open
UPDM-120 Figure 8.126 UPDM 1.0b1 open
UPDM-125 Fig. 8.142: System cannot be decomposed from other systems UPDM 1.0b1 open
UPDM-124 Figure 8.142 SystemGroupMember UPDM 1.0b1 open
UPDM-128 Section 8.6.54 Trigger stereotype conflicts with UML metaclass UPDM 1.0b1 open
UPDM-127 Figure 8.156 UPDM 1.0b1 open
UPDM-114 Figure 8.113: Realization between stereotypes has no semantic meaning UPDM 1.0b1 open
UPDM-113 Figure 8.113 UPDM 1.0b1 open
UPDM-123 Figure 8.142 SystemSystemSoftware UPDM 1.0b1 open
UPDM-122 Figure 8.142 UPDM 1.0b1 open
UPDM-118 Figure 8.124 UPDM 1.0b1 open
UPDM-117 Fig. 8.121 UPDM 1.0b1 open
UPDM-126 Figure 8.151 UPDM 1.0b1 open
UPDM-119 Section 8.6.16 UPDM 1.0b1 open
UPDM-107 Figure 8 UPDM 1.0b1 open
UPDM-106 Section 8.4.31.3 UPDM 1.0b1 open
UPDM-105 Section 8.4.38.3 UPDM 1.0b1 open
UPDM-110 Figure 8.94 OperationalCapabilityEffect UPDM 1.0b1 open
UPDM-109 Figure 8.94 UPDM 1.0b1 open
UPDM-108 Figure 8.59 UPDM 1.0b1 open
UPDM-95 Section 8.4.8.3 UPDM 1.0b1 open
UPDM-94 Section 8.4.5.3 UPDM 1.0b1 open
UPDM-112 Section 8.6.2 UPDM 1.0b1 open
UPDM-111 Extremely long stereotype names for associations will distort diagrams UPDM 1.0b1 open
UPDM-100 Figure 8.51 CapabilityRequirementCapability UPDM 1.0b1 open
UPDM-99 Figure 8.51 UPDM 1.0b1 open
UPDM-104 Section 8.4.22.5 UPDM 1.0b1 open
UPDM-103 Figure 8.59 UPDM 1.0b1 open
UPDM-102 Section 8.4.45.6 UPDM 1.0b1 open
UPDM-101 Figure 8.52 UPDM 1.0b1 open
UPDM-97 Figure 8.46 MaterielBehavior UPDM 1.0b1 open
UPDM-96 Figure 8.46 UPDM 1.0b1 open
UPDM-98 Figure 8.50 UPDM 1.0b1 open
UPDM-83 Section 8.3.14.3 UPDM 1.0b1 open
UPDM-82 Section 8.3.9 UPDM 1.0b1 open
UPDM-91 Section 8.3.18.3 UPDM 1.0b1 open
UPDM-90 Section 8.3.17.3 ResourceCapabilityConfiguration UPDM 1.0b1 open
UPDM-86 Section 8.3.16.9 Wrong chapter number for requirements UPDM 1.0b1 open
UPDM-85 Section 8.3.16.9 UPDM 1.0b1 open
UPDM-93 Section 8.4.2 UPDM 1.0b1 open
UPDM-92 Section 8.3.24.3 UPDM 1.0b1 open
UPDM-79 Section 8.3.4.3 UPDM 1.0b1 open
UPDM-78 Section 8.2.10.3 Diagram UPDM 1.0b1 open
UPDM-88 Section 8.3.17.3 ResourceCompetence UPDM 1.0b1 open
UPDM-87 Section 8.3.17.3 UPDM 1.0b1 open
UPDM-81 Section 8.3.8.3 StakeholderConcern UPDM 1.0b1 open
UPDM-80 Section 8.3.8.3 UPDM 1.0b1 open
UPDM-84 Section 8.3.15.3 UPDM 1.0b1 open
UPDM-89 Section 8.3.17.3 OperationalCapabilityRoleResource UPDM 1.0b1 open
UPDM-67 Section: 8.5.2 Capability and 8.3.21 StrategicMission UPDM 1.0b1 open
UPDM-66 Section: 8.6.48.6 UPDM 1.0b1 open
UPDM-63 Section: 8.6.33.6 Constraints UPDM 1.0b1 open
UPDM-62 Section: 8.6.33.6 Constraints UPDM 1.0b1 open
UPDM-72 Section: 8.3.15.7 Semantics UPDM 1.0b1 open
UPDM-71 Section: 8.3.15.5 Associations UPDM 1.0b1 open
UPDM-65 Section: 8.6.10 DataElementSystemFunction UPDM 1.0b1 open
UPDM-64 Section: 4.6.50.6 Constraints UPDM 1.0b1 open
UPDM-74 Extensions section should not be empty,ie section 8.2.2.1 UPDM 1.0b1 open
UPDM-73 Section 7.3, 8.1 UPDM 1.0b1 open
UPDM-70 Section: 8.3.14.5 Associations UPDM 1.0b1 open
UPDM-69 Section: 8.3.14 PerformanceMeasureSet UPDM 1.0b1 open
UPDM-77 Section 8.2.9 UPDM 1.0b1 open
UPDM-76 Section 9.3.7 UPDM 1.0b1 open
UPDM-68 Section: 8.3.13 Goal UPDM 1.0b1 open
UPDM-75 Association end names should be on the diagrams UPDM 1.0b1 open
UPDM-57 Section: 8.4.13.6 Constraints UPDM 1.0b1 open
UPDM-56 Section: 8.6.36.6 Constraint UPDM 1.0b1 open
UPDM-61 Section: 8.4.44.6 Constraints UPDM 1.0b1 open
UPDM-60 Section: 8.4.29.7 Semantics UPDM 1.0b1 open
UPDM-51 Section: 8.3.4.4 Attributes UPDM 1.0b1 open
UPDM-50 Section: 8.5.16.6 Constratints UPDM 1.0b1 open
UPDM-59 Section: 8.4.28.6 Constraints UPDM 1.0b1 open
UPDM-58 Section: 8.4.20.6 Constraints UPDM 1.0b1 open
UPDM-53 Section: 8.3.4.6 Constraints UPDM 1.0b1 open
UPDM-52 Section: 8.3.4.6 Constraints UPDM 1.0b1 open
UPDM-55 Section: 8.4.13. Constraints - OperationalActivity UPDM 1.0b1 open
UPDM-54 Section: 8.3.4.6 Constraints UPDM 1.0b1 open
UPDM-49 Section: 8.3.2 Figure 8.14 UPDM 1.0b1 open
UPDM-48 Section: 8.4.2.6 Constraints UPDM 1.0b1 open
UPDM-45 Section: 8.3.23 UPDM 1.0b1 open
UPDM-44 Section: 8.3.4.3 ArchitectureView Description UPDM 1.0b1 open
UPDM-47 Section: 8.4.2.7 ActivityRealization UPDM 1.0b1 open
UPDM-46 Section: 8.3.21 Strategic Mission and 8.3.24 Vision UPDM 1.0b1 open
UPDM-35 Section: 8.4.41 Policy UPDM 1.0b1 open
UPDM-34 Section: 8.6.39.6 Constraints UPDM 1.0b1 open
UPDM-30 Section: 8.7.5.6 Constraints UPDM 1.0b1 open
UPDM-29 Section: 8.6.18.1 Extension UPDM 1.0b1 open
UPDM-32 Section: 8.4.16 OperationalCapabilityRole UPDM 1.0b1 open
UPDM-31 Section: 8.5.7.7 Semantics UPDM 1.0b1 open
UPDM-43 Section: 8.4.41 Policy UPDM 1.0b1 open
UPDM-42 Section: 8.4.28.6 Constraints UPDM 1.0b1 open
UPDM-37 Section: 8.6.26 SV-6 UPDM 1.0b1 open
UPDM-36 Section: 8.6.12.5 Forecast Associations UPDM 1.0b1 open
UPDM-39 Section: 8.3.14.6 Constraints UPDM 1.0b1 open
UPDM-38 Section: 8.3.10 ConformingElement UPDM 1.0b1 open
UPDM-28 Section: 8.4.43.1 Extension UPDM 1.0b1 open
UPDM-27 Section: 8.6.34.6 Constraints UPDM 1.0b1 open
UPDM-41 Section: 8.4.28.3 OperationalStateTrace Description UPDM 1.0b1 open
UPDM-40 Section: 8.2.11 ProjectType UPDM 1.0b1 open
UPDM-33 Section: 8.3.13.5 Association UPDM 1.0b1 open
UPDM-22 Section: 7.1 Design Principles for the Architecture UPDM 1.0b1 open
UPDM-21 Section: 8.4.12.8 Notation UPDM 1.0b1 open
UPDM-13 SysML stereotype references in the UPDM specification need to be updated UPDM 1.0b1 open
UPDM-15 Section: 5.3.4.2 UPDM 1.0b1 open
UPDM-14 Section: 4.3.3.3 UPDM 1.0b1 open
UPDM-17 Section: 4.2.10.6 UPDM 1.0b1 open
UPDM-16 Section: 4.3.14.4 UPDM 1.0b1 open
UPDM-20 Section: 8.6.11.6 Data Exchange UPDM 1.0b1 open
UPDM-19 8.4.8.6 Constraints UPDM 1.0b1 open
UPDM-24 Section: Part III UPDM 1.0b1 open
UPDM-23 Section: Figure 7.1 UPDM 1.0b1 open
UPDM-26 Section: Figure 8.11 UPDM 1.0b1 open
UPDM-25 Section: Figure 8.1 UPDM 1.0b1 open
UPDM-18 Page: 29 - Image shown is to small to read UPDM 1.0b1 open

Issues Descriptions

Fig 14 & Fig 16 - Consistent Profile Usage

  • Key: UPDM11-31
  • Legacy Issue Number: 13722
  • Status: open  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

    Summary Fig 14 & Fig 16 - Consistent Profile Usage. Fig 16 shows which Metaclass is being extended. Figure 14 does not. Suggest metaclasses be shown (even at the cost of making the diagrams busy).
    Diagram All
    Document Issue UPDM (OMG Beta) Jan 2009
    Section
    Page
    Priority Low
    Source Ian BaileyModel Futuresian@modelfutures.com
    Date 3rd March 2009
    Rationale
    Resolution POTENTIAL SOLUTION:If supported by MagicDraw, we should add a compartment to each of the symbols to indicate the extended element (where the extension is not shown on the diagram). Adding the extensions to all of the diagrams would make it pretty much unreadable.Andrius to confirm whether this is possible.

  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Updated: Sat, 7 Mar 2015 20:49 GMT

Fig19 - More Needed Here

  • Key: UPDM11-32
  • Legacy Issue Number: 13733
  • Status: open  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

    Fig19 - More Needed Here. Can you also add ExternalTuple (under OntologyReference), and ExternalTupleType (under ExternalType)? This is to allow references to relationships defined in the ontology. We missed this in MODAF, and is now causing us problems. Would be really great if you could fix it in UPDM. Thanks.
    Diagram AV
    Document Issue UPDM (OMG Beta) Jan 2009

    Resolution It makes sense to add this as it gives us a complete mapping to IDEAS. We'll look at incorporating this into the next version of UPDM.

  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Updated: Sat, 7 Mar 2015 20:49 GMT

Section: 7.3.2

  • Key: UPDM-774
  • Legacy Issue Number: 11350
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    pages are blank

  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Sat, 7 Mar 2015 20:48 GMT

Section 6: 'Class Library' should be 'Model Library'

  • Key: UPDM-773
  • Legacy Issue Number: 11166
  • Status: open  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    in section 6 and elsewhere I think 'Class Library' (which does not exist as a UML concept) should be 'Model Library' (which does).

  • Reported: UPDM 1.0b1 — Thu, 19 Jul 2007 04:00 GMT
  • Updated: Sat, 7 Mar 2015 20:48 GMT

Section 6: list of XMI files for the compliance levels

  • Key: UPDM-772
  • Legacy Issue Number: 11165
  • Status: open  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    Section 6 lists the XMI files 'for the compliance levels' which include those for the 'formal metamodel'. However the formal metamodel is currently in a non-normative Annex. Personally I would like to make the metamodel a proper compliance point.

  • Reported: UPDM 1.0b1 — Thu, 19 Jul 2007 04:00 GMT
  • Updated: Sat, 7 Mar 2015 20:48 GMT

CapabilityRequirementCapability is duplicated

  • Key: UPDM-478
  • Legacy Issue Number: 12228
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    CapabilityRequirementCapability is duplicated by stereotyped association and relation via subject/usecase metaproperties (as implied by OCL constraints)

  • Reported: UPDM 1.0b1 — Fri, 15 Feb 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityOperationalCapability is duplicated

  • Key: UPDM-477
  • Legacy Issue Number: 12227
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    CapabilityOperationalCapability is duplicated by stereotyped association and relation via subject/usecase metaproperties (as implied by OCL constraints)

  • Reported: UPDM 1.0b1 — Fri, 15 Feb 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Connection between OperationalActivity and SystemFunction is not traceable

  • Key: UPDM-476
  • Legacy Issue Number: 12226
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Connection between OperationalActivity and SystemFunction is not clearly traceable. This has effect on SV-5 generation.

  • Reported: UPDM 1.0b1 — Fri, 15 Feb 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Stereotyped Associations Notation

  • Key: UPDM-475
  • Legacy Issue Number: 12208
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Stereotyped associations do not speicfy their end types. Stereotypes that are related to other stereotypes through stereotyepd relationships are specified in their diagrams with association to the other stereotypes and redundantly in their Associations section. Apply the agreed upon diagram notation using steretyped dependencies - non normatinve notation used i the profile specificaton and remove all redundant associations.

  • Reported: UPDM 1.0b1 — Mon, 4 Feb 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.5

  • Key: UPDM-474
  • Legacy Issue Number: 12122
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Attribute for compatibility with MODAF. Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityComposition

  • Key: UPDM-473
  • Legacy Issue Number: 12121
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Missing stereotype for compatibility with MODAF. Resolution:Add stereotype extending Association to model composition of Capabilities both ends constrained to be Capability

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Competence, Actual Competence

  • Key: UPDM-472
  • Legacy Issue Number: 12120
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Missing instance stereotype for compatibility with MODAF. Summary:We need a correspoinding instance stereotype,
    Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of Competence

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganizationType, ActualOrganization

  • Key: UPDM-471
  • Legacy Issue Number: 12119
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Missing instance stereotype for compatibility with MODAF. Summary:OrganizationType closely corresponds to OrganizationalResource in UPDM, but we need an instance stereotype corresponding to OrganizationalResource
    Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of OrganizationalResource

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

PostType, Actual Post

  • Key: UPDM-470
  • Legacy Issue Number: 12118
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Missing instance stereotype for compatibility with MODAF. Summary:PostType is very similar to OperationalCapabilityRole in UPDM, but we don't have a corresponding instance stereotype.
    Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of OperationalCapabilityRole

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.20:ServiceSpecification

  • Key: UPDM-465
  • Legacy Issue Number: 12113
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Service Specification can be either an interface or a class. It only extends interface. Resolution:Add Class extension
    Revised Text:
    8.6.20.1 Extension
    o Interface (from UML2)
    · Class (from UML2)

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Conforming Element

  • Key: UPDM-464
  • Legacy Issue Number: 12112
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    These Elements should also specialize ConformingElement
    Summary:Goal - p
    · Competence-p,s
    · Capability-p,s
    · OerationalNode-p,s
    · Service-p,s
    · OperationalNodePort-p,s
    · SystemPort-p,s
    · CapabilityConfiguration-p,s
    · Effect-p
    · OperationalActivity-p
    · CommunicationPort-p,s
    · SystemTask-p
    · OperationalTask-p
    · SystemsNode-p

    · CapabilityRequirement-p
    · CommunicationsPath-p
    · CommunicationsLink-p,s
    · DataElement-p
    · DataExchange-p
    · Information Element-p
    · InformationExchange-p
    · System-p,s
    · SystemFunction-p,s
    · SystemInterface-p,s
    · Technical Standards Profile

    Resolution:Add check for zero

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.29:OperationalTask

  • Key: UPDM-460
  • Legacy Issue Number: 12108
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    8.4.29.3 Description - Missing association to Rule - fix diagram. :8.4.29.3 Associations
    <<add>>
    adheresToRules : Rule [*] Rules to which this OperationalTask adheres
    Resolution:Add check for zero
    Revised Text: adheresToRules : Rule [*] Rules to which this OperationalTask adheres

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.21.6 :Constraints

  • Key: UPDM-459
  • Legacy Issue Number: 12107
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Typo input pin and output pin. Resolution:Fix text
    Revised Text: [1] Asserts that if the source of the object flow is an outputpin, OutputPin then if the owner of the output pin is a CallBehaviorAction then its behavior is an OperationalActivity, or a CallOperationAction then its operation is an OperationalTask.
    [2] Asserts that if the target of the object flow is an Input Pin, InputPin then the owner of the Input pin must be an OperationalAction - a CallBehaviorAction whose behavior is an OperationalActivity, or a CallOperationAction whose operation is an OperationalTask.

    [3] The type of the input or output pin InputPin or OutputPin must be an InformationElement.

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.29.6:OperationalTask Constraints

  • Key: UPDM-461
  • Legacy Issue Number: 12109
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Constraints [1],[2],[3],[4],[5] OCL doesn't check for zero or more. Resolution:Add check for zero
    Revised Text: [1] Asserts that this OperationalTask adheres to zero or more Rules
    self.adheresToRules ->notEmpty() implies
    self.adheresToRules > forAll(getAppliedStereotype('UPDM::Rule')>notEmpty())

    [2] Asserts that this OperationalTask adheres to zero or more Policies
    self.adheresToPolicy->notEmpty() implies
    self.adheresToPolicy-> forAll(getAppliedStereotype('UPDM::Policy')->notEmpty())

    3] Asserts that there are zero or more Doctrines that govern this OperationalTask self.governedByDoctrine->notEmpty() implies
    self.governedByDoctrine->forAll(getAppliedStereotype('UPDM::Doctrine')- >notEmpty())

    [4] Asserts that Materiel is utilized by this OperationalTask
    self.utilizesMateriel->notEmpty() implies
    self.utilizesMateriel-> forAll(getAppliedStereotype('UPDM::Materiel')->notEmpty())

    [5] Asserts that the Triggers of this OperationalTask can be stereotyped Trigger, a callEventAction
    self.triggeredByEvents->notEmpty() implies
    self.triggeredByEvents->forAll(getAppliedStereotype('UPDM::Trigger') -> notEmpty())

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.19:OperationalControlFlow

  • Key: UPDM-458
  • Legacy Issue Number: 12106
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Typo -of should be or. Fix text
    Revised Text: 8.4.19.3 Description A flow of control of or energy from one activity node to another.

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.14.5:OperationalCapability Associations

  • Key: UPDM-457
  • Legacy Issue Number: 12105
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Multiplicity and description for goals and StrategicMission are wrong. Summary:o goals : Goal [*] The Goals that are to be realized by the Strategic Mission and this capability
    o strategicMission : StrategicMission [*] The Strategic Missions supported by this OperationalCapability o
    Resolution:Add check for zero
    Revised Text: o goals : Goal [1..*] The Goals that are to be realized by the Strategic Mission and this OperationalCapability
    strategicMission : StrategicMission [1..*] The Strategic Missions supported by this OperationalCapability

    remove Materiel,CapabilityRequirement and Capability

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

AllViews

  • Key: UPDM-463
  • Legacy Issue Number: 12111
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Missing stereotype for ArchitectureSummary. Summary:The classifier for ArchitectureDescription::architectureSummary is constrained to be ArchitectureSummary which means we have to have an instance of the Class ArchitectureSummary, but there is no stereotype for that.
    Resolution: There should be a stereotype "ArchitectureSummary" that specializes InstanceSpecification.

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.41.5 :Associations oPolicy

  • Key: UPDM-462
  • Legacy Issue Number: 12110
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    typos in association names. Resolution:fix text
    Revised Text: activity : OperationalActivity [*] This policy governs these Activities o
    operationaltask operationalTask: OperationalTask [*] OperationalTasks governed by this Policy o
    SystemFunction systemFunction: SystemFunction [*] SystemFunctions governed by this Policy o
    systemtasksystemTask : SystemTask [*] SystemTasks governed by this Policy

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.13.6 :OperationalActivity Constraints

  • Key: UPDM-456
  • Legacy Issue Number: 12104
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    OCL doesn't check for zero or more. Resolution:Add check for zero
    Revised Text: [3] Asserts that the entries in policy are typed Policy
    self.policy->notEmpty() implies
    self.policy->forAll(getAppliedStereotype('UPDM::Policy')->notEmpty())

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.13.5:OperationalActivity Associations

  • Key: UPDM-455
  • Legacy Issue Number: 12103
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    :materiel is listed as an association, but doesn't show up on the diagram. Resolution:It is actually a MaterielNode association, and should be removed.

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActualLocation

  • Key: UPDM-469
  • Legacy Issue Number: 12117
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Missing stereotype for compatibility with MODAF. Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of Location

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.5.4:Capability

  • Key: UPDM-468
  • Legacy Issue Number: 12116
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    isFielded is unnecessary, since "FieldedCapability" is defined as an instance of CapabilityConfigureatoin from MODAF

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

UPDM Package Structure

  • Key: UPDM-467
  • Legacy Issue Number: 12115
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    The package structure does not lend itself to reuse. Resolution:Add the following packages and move appropriate stereotypes to these packages
    · Standards
    · Viewpoint
    · Requirement
    · BMM
    · Services
    · Communications
    · Parametrics
    · ResourceCompetence
    Existing Packages remain
    · Acquisition
    · Strategic
    · Operational
    · System
    · TechnicalStandards

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

7.2 UPDM Architecture Figure

  • Key: UPDM-466
  • Legacy Issue Number: 12114
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Figure is obsolete

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.17.68:Resource Constraints

  • Key: UPDM-449
  • Legacy Issue Number: 12097
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    OCL doesn't check for zero or more. Constraint[5] is unnecessary. [1] Asserts that zero or more effects affect this resource.
    self.effect-> forAll(getAppliedStereotype('UPDM::Effect')->notEmpty())
    Resolution:Add check for zero, delete [5]
    Revised Text:
    [1] Asserts that zero or more effects affect this resource.
    self.effect->notEmpty() implies
    self.effect-> forAll(getAppliedStereotype('UPDM::Effect')->notEmpty())
    [5] Asserts that there is an association between a Competence and the OperationalCapabilityRole that requires it.
    self.getAllAttributes()>asOrderedSet()>select(association->notEmpty() ).association->any (getAppliedStereotype('UPDM::OperationalCapabilityRoleResource')> notEmpty())>notEmpty()

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing instance stereotype for compatibility with MODAF

  • Key: UPDM-448
  • Legacy Issue Number: 12096
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Summary:
    Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

TechnicalStandardsProfile

  • Key: UPDM-447
  • Legacy Issue Number: 12095
  • Status: open  
  • Source: Anonymous
  • Summary:

    this concept does not exist in MODAF

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.3:Asset

  • Key: UPDM-452
  • Legacy Issue Number: 12100
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    This stereotype is useless - delete. Delete Asset and AssetMapping stereotypes

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.24.3:Vision Description

  • Key: UPDM-451
  • Legacy Issue Number: 12099
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Multiplicity wrong for goals - should be [1..*] fix diagram to show 1..* Goals required by vision and 1..* visions by goal. In 8.3.24.5 fix multiplicity and add a descriptionj for goals
    Revised Text: o goals : Goal [1..*] The Goals that contribute to realizing the Vision

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.21.6 :Strategic Mission Constraints

  • Key: UPDM-450
  • Legacy Issue Number: 12098
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    OCL doesn't check for zero or more. [1] Asserts that zero or more OperationalCapabilities have been designated as instrumental in achieving the StrategicMission.

    self.operationalCapabilities-> forAll(getAppliedStereotype ('UPDM::OperationalCapability')->notEmpty())
    Resolution:Add check for zero
    Revised Text: self.operationalCapabilities->notEmpty() implies
    self.operationalCapabilities-> forAll(getAppliedStereotype ('UPDM::OperationalCapability')->notEmpty())

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.12.6: Needline Constraints

  • Key: UPDM-454
  • Legacy Issue Number: 12102
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    constraint [5] OCL doesn't check for zero or more. Resolution:Add check for zero
    Revised Text: [5] Asserts that the elements in the operationalInformationFlow are stereotyped OperationalInformationFlow
    self.operationalInformationFlow->notEmpty() implies
    self.operationalInformationFlow-> forAll(getAppliedStereotype('UPDM::OperationalInformationFlow')->notEmpty())

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.7.6: InformationElement Constraints

  • Key: UPDM-453
  • Legacy Issue Number: 12101
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Constraints [1], [2] OCL doesn’t check for zero or more. Resolution:Add check for zero
    Revised Text: [1] Asserts that this InformationElement is associated with an OperationalActivityFlow. self.operationalCapabilities->notEmpty() implies
    self.operationalInformationFlow.getAppliedStereotype ('UPDM::OperationalInformationFlow')->notEmpty()

    [2] Asserts that there are zero or more InformationExchanges that utilize this InformationElement self.operationalCapabilities->notEmpty() implies
    self.informationExchange-> forAll(getAppliedStereotype ('UPDM::InformationExchange')->notEmpty())

  • Reported: UPDM 1.0b1 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemsNode

  • Key: UPDM-444
  • Legacy Issue Number: 12092
  • Status: open  
  • Source: Anonymous
  • Summary:

    the relationship to OperationalNode appears to indicate that the op nodes
    are part of the SystemsNode. This is inappropriate, as in both DoDAF and MODAF
    operational nodes are logical entities that perform operational activities. They may be
    realised as SystemsNodes, but to show structure in this way is a misunderstanding of the
    intent behind MODAF and DoDAF. This is a common misunderstanding amongst DoDAF
    users which has been cleared up in the MODAF 1.1 documentation

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemServiceProvider, SystemServiceConsumer

  • Key: UPDM-443
  • Legacy Issue Number: 12091
  • Status: open  
  • Source: Anonymous
  • Summary:

    as these are classes, it is unclear
    how they are to be used. Do they represent generic actors in a service orchestration ?

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Standard

  • Key: UPDM-446
  • Legacy Issue Number: 12094
  • Status: open  
  • Source: Anonymous
  • Summary:

    There are no major issues with the TV area of UPDM. The definition of Standard would have to be
    broadened for MODAF use. Also, it is not clear how TechnicalStandardsProfile could be used in
    MODAF.
    • Standard – in MODAF, this includes non-technical standards whereas the UPDM definition
    seems to restrict it to systems standards

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemTask

  • Key: UPDM-445
  • Legacy Issue Number: 12093
  • Status: open  
  • Source: Anonymous
  • Summary:

    as in the operational views, these are UML operations linking Systems to
    their behaviour. This is not done in MODAF M3, though it is a perfectly reasonable
    approach.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemPort

  • Key: UPDM-442
  • Legacy Issue Number: 12090
  • Status: open  
  • Source: Anonymous
  • Summary:

    the definition talks about SystemInterfaces. However, SystemInterface is
    more of an abstract concept. Surely it is CommunicationLink that should connect
    SystemPorts ?

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemInterface

  • Key: UPDM-441
  • Legacy Issue Number: 12089
  • Status: open  
  • Source: Anonymous
  • Summary:

    now represented as resource interactions in MODAF v1.1

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemFunction

  • Key: UPDM-439
  • Legacy Issue Number: 12087
  • Status: open  
  • Source: Anonymous
  • Summary:

    note that in MODAF 1.1, there are simply functions which are
    performed by functional resources (systems, human roles, or capability configurations).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

System

  • Key: UPDM-438
  • Legacy Issue Number: 12086
  • Status: open  
  • Source: Anonymous
  • Summary:

    unclear whether this is a class of system or an individual system

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemGroup

  • Key: UPDM-440
  • Legacy Issue Number: 12088
  • Status: open  
  • Source: Anonymous
  • Summary:

    it is not clear whether this is a group of individual systems (i.e. serial
    numbered) or a grouping by type. Without this distinction, there may be semantic
    interoperability issues between different tools and different architectures

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalActivityRealization

  • Key: UPDM-435
  • Legacy Issue Number: 12083
  • Status: open  
  • Source: Anonymous
  • Summary:

    this seems to indicate that an OperationalActivity can be
    realised by an event trace or state model, which does not appear to make sense. Is it useful
    to specify anything other than an op activity to system function mapping ? Also, this again
    seems to relate to materiel, which further obscures the semantics of Materiel (if that is
    possible).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location

  • Key: UPDM-434
  • Legacy Issue Number: 12082
  • Status: open  
  • Source: Anonymous
  • Summary:

    it is often important to distinguish between an actual location, and a type of
    location (e.g. “in theatre”, “behind enemy lines”, “maritime littoral”, etc.)

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DataExchange

  • Key: UPDM-433
  • Legacy Issue Number: 12081
  • Status: open  
  • Source: Anonymous
  • Summary:

    MODAF no longer uses this – it simply has resource interactions that
    carry data elements.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Service

  • Key: UPDM-437
  • Legacy Issue Number: 12085
  • Status: open  
  • Source: Anonymous
  • Summary:

    this seems to indicate an implementation of a service by a system. In the NATO
    SOA views, the Service stereotype indicates a type of service which may be implemented by
    many different means (the UPDM equivalent would seem to be ServiceSpecification)

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

RealizedSystemSpecification, SystemFunctionSpecification

  • Key: UPDM-436
  • Legacy Issue Number: 12084
  • Status: open  
  • Source: Anonymous
  • Summary:

    this would appear to use an
    interface to define a type of system and classes to deploy those systems. This seems rather
    an unusual and complex approach given that UML now has composite structure models for
    this purpose.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Systems Views

  • Key: UPDM-429
  • Legacy Issue Number: 12077
  • Status: open  
  • Source: Anonymous
  • Summary:

    The SV area of UPDM covers MODAF and DoDAF reasonably well. The concern mentioned before
    about lack of a clear logical-physical split from OV-SV is again apparent in the SV section though.
    SystemsNodes can “house” Operational Nodes in UPDM, which is against the original intent of
    DoDAF, and clearly against the rules in MODAF. The remaining concerns about the SV area are
    mostly due to the change in MODAF 1.1 that extends SV-1,SV-4, etc. to cover human factors

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResouceCapabilityConfiguration

  • Key: UPDM-428
  • Legacy Issue Number: 12076
  • Status: open  
  • Source: Anonymous
  • Summary:

    see previous comment (issue 12075)

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResourceCapability

  • Key: UPDM-427
  • Legacy Issue Number: 12075
  • Status: open  
  • Source: Anonymous
  • Summary:

    the UPDM model has CapabilityConfiguration in it, yet it relates
    capabilities to resources which deliver them – why then have CapabilityConfiguration ?

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityRequirementCapability

  • Key: UPDM-426
  • Legacy Issue Number: 12074
  • Status: open  
  • Source: Anonymous
  • Summary:

    again, this would seem to be a misunderstanding of the
    MODAF approach. OperationalCapability seems to link Capabilities to
    CapabilityRequirements, but a capability manager would want to be able to specify capability
    requirements in a broad sense without recourse to operational models.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CommunicationSystem

  • Key: UPDM-432
  • Legacy Issue Number: 12080
  • Status: open  
  • Source: Anonymous
  • Summary:

    this is not explicitly defined in MODAF – there was much
    resistance from the MODAF TWG to introducing special types of systems (the argument
    was “where do you stop ?”). Instead, the MODAF Ontology is used to add semantics to the
    basic M3 elements. This also applies to hardware, networks, software, etc.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CommunicationPath

  • Key: UPDM-431
  • Legacy Issue Number: 12079
  • Status: open  
  • Source: Anonymous
  • Summary:

    this concept does not exist in MODAF

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CommunicationLink

  • Key: UPDM-430
  • Legacy Issue Number: 12078
  • Status: open  
  • Source: Anonymous
  • Summary:

    in MODAF, this is covered in SV-2 as a system port connection and
    requires that ports be defined – this is not required in UPDM

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Capability.isFielded

  • Key: UPDM-421
  • Legacy Issue Number: 12069
  • Status: open  
  • Source: Anonymous
  • Summary:

    this Boolean attribute is meant to describe the fielded status of a
    capability. However, the reality is far more complex – the capability may be implemented
    (and therefore fielded) in many possible ways. In addition, there are levels of fielding (IOC,
    FOC). This problem may be related to the UPDM misunderstanding of the concept of
    Capability.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Capability

  • Key: UPDM-420
  • Legacy Issue Number: 12068
  • Status: open  
  • Source: Anonymous
  • Summary:

    the UPDM spec states “The Capability is expressed in terms of the Resources
    required to implement the Capability”, which is in clear contradiction to the way capability is
    used in the MOD and the MODAF Stratgic Views. The whole idea of the capability concept is
    for architects to specify their requirements INDEPENDENTLY of how it is to be
    implemented (i.e. the resources to be used are deliberately not stated).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityRequirement

  • Key: UPDM-425
  • Legacy Issue Number: 12073
  • Status: open  
  • Source: Anonymous
  • Summary:

    the relationship to Milestone does not appear to follow the
    current MODAF approach. In MODAF 1.0, CapabilityRequirement was a specialisation of
    Capability that had performance metrics. In MODAF 1.1, CapabilityRequirement has been
    removed altogether (Capability itself is sufficient).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityOperationalCapability

  • Key: UPDM-424
  • Legacy Issue Number: 12072
  • Status: open  
  • Source: Anonymous
  • Summary:

    this concept does not exist in MODAF (see comment on
    OperationalCapability).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Strategic Views

  • Key: UPDM-419
  • Legacy Issue Number: 12067
  • Status: open  
  • Source: Anonymous
  • Summary:

    There are a number of concerns about this package in the UPDM specification. There does not
    seem to be a clear understanding of what a capability is and how it relates to other parts of the
    architecture; the logical (OV) and physical (SV). Capabilities in UPDM have a strong equipment and
    systems focus. In MODAF and M3, capability an ability to do something, which may or may not be
    achieved by procuring / using equipment – e.g. it may be possible to provide a capability increment
    simply by re-training soldiers

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityConfigurationCapabilities

  • Key: UPDM-423
  • Legacy Issue Number: 12071
  • Status: open  
  • Source: Anonymous
  • Summary:

    again, this may indicate a misunderstanding of the
    capability approach in UK and US defence acquisition. The statement “Defines the
    association between a CapabilityConfiguration and the Capabilities that are configured by it”
    implies the capability is defined by the resources that realise it. This is not the case (see the
    comment on Capability).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityConfiguration

  • Key: UPDM-422
  • Legacy Issue Number: 12070
  • Status: open  
  • Source: Anonymous
  • Summary:

    despite the word “capability” being in the name, a capability
    configuration is firmly in the solution space, and therefore does not belong in the StV
    package of the UPDM profile (this also applies to the related stereotypes).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNode

  • Key: UPDM-408
  • Legacy Issue Number: 12055
  • Status: open  
  • Source: Anonymous
  • Summary:

    the description suggests that an operational node “realises” capability,
    which tends to give a rather physical slant to nodes. In MODAF (and DoDAF) operational
    nodes are logical representations of the usage (or requirement for) capability in an
    architecture. The realising systems are shown in the SVs (in MODAF, people and
    organizations may also be part of the realisation). The physical aspect of UPDM’s
    OperationalNode is reinforced by the enumeration NodeType, which allows an
    OperationalNode to be an organization or type of organization. This is strictly against the
    rules in MODAF, and probably against the original intent of DoDAF (though CADM does
    allow it, and it is commonly found in DoDAF architectures).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalInformationFlow

  • Key: UPDM-407
  • Legacy Issue Number: 12054
  • Status: open  
  • Source: Anonymous
  • Summary:

    this represents the flow of information, materiel, or energy
    between activity nodes (typically, these are Actions). MODAF and DoDAF only cover the flow
    of information between activities. If this is an attempt to replicate the MODAF node
    connector concept, it is a misinterpretation – node connectors are only intended to be
    information flows on OV-2 diagrams – they have no behavioural semantics.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalServiceConsumer, Operational ServiceProvider

  • Key: UPDM-411
  • Legacy Issue Number: 12059
  • Status: open  
  • Source: Anonymous
  • Summary:

    it seems inappropriate to
    model service consumption in this way. It does not allow the architect to show that a
    particular node is both a consumer and a provider of different services. This approach
    forces the architect to produce two nodes – one for production and one for consumption –
    even when it is clearly the same node producing and consuming. The work done in
    developing SOA views by UK and Sweden would seem to indicate that OV-2 is not
    appropriate in a true SOA approach – most SOA orchestration approaches map the
    services to the activities that use them rather than to nodes. The nodes that produce and
    consume services can then be derived by examining the activities they perform

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalEventTrace

  • Key: UPDM-406
  • Legacy Issue Number: 12053
  • Status: open  
  • Source: Anonymous
  • Summary:

    event trace models apply to Materiel which is itself not clearly
    defined, hence it is not clear what the event trace model would represent. In most MODAF
    or DoDAF architectures, an OV-6c shows sequences of messages between operational
    nodes – here it would seem to allow other representations

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalControlFlow

  • Key: UPDM-405
  • Legacy Issue Number: 12052
  • Status: open  
  • Source: Anonymous
  • Summary:

    this is defined as the “control of flow of energy from one activity
    node to another”. Further clarification of semantics is required

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalTask

  • Key: UPDM-413
  • Legacy Issue Number: 12061
  • Status: open  
  • Source: Anonymous
  • Summary:

    this approach used UML Operations to link nodes to activities (though
    the materiel object also seems to serve this purpose ?) and is not used in MODAF, where
    instead a dependency is used to link nodes to operational activities

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalStateTrace

  • Key: UPDM-412
  • Legacy Issue Number: 12060
  • Status: open  
  • Source: Anonymous
  • Summary:

    the definition describes it as the “state machine for OV-5”, yet
    state models belong in OV-6b and typically describe the state transitions of operational
    nodes (OV-2).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Policy

  • Key: UPDM-417
  • Legacy Issue Number: 12065
  • Status: open  
  • Source: Anonymous
  • Summary:

    this is not explicitly defined as an element in MODAF. Instead, MODAF architects
    use operational activities, and standards to define policy. It may be worth considering the
    addition of this in a future MODAF release – e.g. as a subtype of standard

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganizationalRole

  • Key: UPDM-416
  • Legacy Issue Number: 12064
  • Status: open  
  • Source: Anonymous
  • Summary:

    refers to roles being played by OperationalNodes, which breaks the
    MODAF rule about nodes being logical

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganizationalResource

  • Key: UPDM-415
  • Legacy Issue Number: 12063
  • Status: open  
  • Source: Anonymous
  • Summary:

    it is not clear if this is an actual resource (e.g. Ian Bailey) or a
    type of resource (e.g. EW Officer).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganizationalRelationship

  • Key: UPDM-414
  • Legacy Issue Number: 12062
  • Status: open  
  • Source: Anonymous
  • Summary:

    an enumeration “LineKind” is used to describe dotted, solid,
    etc. lines. This kind of graphical specification seems inappropriate in a meta-model
    (especially as this only seems to be specified for OrganizationalRelationship).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRoleResource

  • Key: UPDM-404
  • Legacy Issue Number: 12051
  • Status: open  
  • Source: Anonymous
  • Summary:

    this would appear to duplicate the functionality of
    the OperationalCapabilityRealization

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRole

  • Key: UPDM-403
  • Legacy Issue Number: 12050
  • Status: open  
  • Source: Anonymous
  • Summary:

    as this is a solution specification, it would belong in the SVs in
    MODAF.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalRole

  • Key: UPDM-410
  • Legacy Issue Number: 12058
  • Status: open  
  • Source: Anonymous
  • Summary:

    this concept does not exist in MODAF. In addition, it subclasses into
    OperationalServiceConsumer and OperationalServiceProvider which would appear to
    prevent a node from being both a consumer and a provider of different services (this is very
    common in SOA models).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

RealizedOperationalCapability

  • Key: UPDM-418
  • Legacy Issue Number: 12066
  • Status: open  
  • Source: Anonymous
  • Summary:

    see issue with OperationalCapabilityRealization (issue 12048)

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNodePort

  • Key: UPDM-409
  • Legacy Issue Number: 12056
  • Status: open  
  • Source: Anonymous
  • Summary:

    MODAF does not use UML::Port for nodes

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

MaterielNode

  • Key: UPDM-398
  • Legacy Issue Number: 12045
  • Status: open  
  • Source: Anonymous
  • Summary:

    the semantics of this relationship are not explained. The same relationship
    is used to relate Materiel to Operational Nodes, Systems, etc. without explaining the
    semantics for each case.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

MaterielBehavior

  • Key: UPDM-397
  • Legacy Issue Number: 12044
  • Status: open  
  • Source: Anonymous
  • Summary:

    this association links Material to UML behavioural elements. It seems
    to allow Materiel to be linked to either operational behaviour elements or system behaviour
    elements, which does not make sense. Without a clear definition for Materiel, it is not clear
    whether the system behaviour or operational behaviour is correct. It is usual in DoDAF that
    an operational node conducts operational activities, and a system conducts system
    functions. Quite what UPDM’s Materiel is or does is something of a mystery.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Materiel

  • Key: UPDM-396
  • Legacy Issue Number: 12043
  • Status: open  
  • Source: Anonymous
  • Summary:

    the definition in UPDM does not appear to make sense (possibly as the result of
    cut-and-paste problems ?). Later references to Materiel would seem to suggest that is the
    supertype of all UPDM elements that can have behaviour. This is not apparent from its
    name or from its definition, so cannot be confirmed

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActivityRealization

  • Key: UPDM-392
  • Legacy Issue Number: 12039
  • Status: open  
  • Source: Anonymous
  • Summary:

    it is difficult to interpret the purpose of this from the definition (which
    is somewhat Byzantine), but this seems in essence to be a relationship between an Op
    Activity and a System Function to show that the System Function realises the Op Activity. If
    this is the case, it seems strange that UPDM has not used the usual UML approach of a
    dependency. Alternatively, it could be argued that as these are classes (i.e. types of activity),
    then the system function is a special way of conducting an operational activity, so a
    Generalisation relationship might be acceptable. The use of an Association seems very
    unusual.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Operational Views

  • Key: UPDM-391
  • Legacy Issue Number: 12038
  • Status: open  
  • Source: Anonymous
  • Summary:

    The Operational Views form the linchpin of a MODAF architecture – they either serve to abstract
    an as-is architecture into a logical structure, or present a logical requirement for a to-be
    architecture. It is not at all clear that UPDM handles this. Of particular concern is the use of the
    Materiel stereotype (see details below) which is not well defined and seems to connect logical and
    physical elements with no clear semantics. The need for Material is also questionable – it seems an
    unnecessary element to create in order to associate other elements

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

UPDMAttributes

  • Key: UPDM-389
  • Legacy Issue Number: 12036
  • Status: open  
  • Source: Anonymous
  • Summary:

    this is a simple way to reference external information. To
    accommodate the MODAF Ontology and IDEAS, a more sophisticated mechanism of
    external specialisation, instantiation and equivalence will be required. This could be achieved
    with some additions to the ExternalReferenceType enumeration, however

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Resource

  • Key: UPDM-388
  • Legacy Issue Number: 12035
  • Status: open  
  • Source: Anonymous
  • Summary:

    this has two attributes that are probably not specified clearly enough to be
    useful. It has a “value”, which is a string representing its “value to the enterprise”. There is
    no way a simple string like this could be used for any kind of analysis or decision support in a
    repository. In addition, Resource extends class, implying it is a type of resource, yet it has an
    attribute “type”.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

InformationElement

  • Key: UPDM-395
  • Legacy Issue Number: 12042
  • Status: open  
  • Source: Anonymous
  • Summary:

    in UPDM, this is a Stereotype of Class, whereas M3 uses
    InformationItem.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

AssetMapping

  • Key: UPDM-394
  • Legacy Issue Number: 12041
  • Status: open  
  • Source: Anonymous
  • Summary:

    this seems to be based on a poor understanding of DoDAF and MODAF.
    Operational Nodes are logical “actors” whose functionality may be realised (by systems in
    DoDAF, and by resources in MODAF). To have yet another level of abstraction (if that is
    what this is meant to be) seems to just add confusion. In addition, OV-1 tends to be the last
    view produced in an architecture, so it is unlikely that it will specify anything that is “later
    realised”.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapability

  • Key: UPDM-400
  • Legacy Issue Number: 12047
  • Status: open  
  • Source: Anonymous
  • Summary:

    this is a UML Use Case that specifies the requirements for a
    capability. There is no equivalent of this in MODAF or M3, but it does appear to be useful. A
    future MODAF release should consider something similar for the StVs.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Needline

  • Key: UPDM-399
  • Legacy Issue Number: 12046
  • Status: open  
  • Source: Anonymous
  • Summary:

    in UPDM, a needline is specified as a requirement to exchange information. In
    an as-is architecture, it would not be a requirement, but a logical representation of an
    existing information exchange. It should be noted that the UPDM definition is probably in line
    with DoDAF in this respect, but not with MODAF

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRealization Definition

  • Key: UPDM-402
  • Legacy Issue Number: 12049
  • Status: open  
  • Source: Anonymous
  • Summary:

    This would appear to be the definition for
    OperationalCapability rather than OperationalCapabilityRealization. In addition, it states that
    the OperationalCapability is equivalent to an EnduringTask in MODAF, which is not correct

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRealization

  • Key: UPDM-401
  • Legacy Issue Number: 12048
  • Status: open  
  • Source: Anonymous
  • Summary:

    it is not clear why this relates an OperationalCapability
    to the realizing systems, instead of just relating the Capability itself to the capability
    configurations or systems – see also RealizedOperationalCapability

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Enterprise & Vision

  • Key: UPDM-390
  • Legacy Issue Number: 12037
  • Status: open  
  • Source: Anonymous
  • Summary:

    MODAF now defines the temporal and physical structure of the
    enterprise – i.e. an enterprise can be decomposed into its parts and into its temporal
    phases. UPDM applies the temporal information to the Vision (and also to other elements),
    which does not allow for quite such a flexible way to “slice and dice” the architecture

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Asset

  • Key: UPDM-393
  • Legacy Issue Number: 12040
  • Status: open  
  • Source: Anonymous
  • Summary:

    no equivalent in MODAF for this concept (note this is a very particular use of the
    word “Asset” for OV-1 purposes in UPDM)

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

System views

  • Key: UPDM-373
  • Legacy Issue Number: 12020
  • Status: open  
  • Source: Anonymous
  • Summary:

    A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
    · MODAF/ NAF places all of its solution based entities within the system view something that is not the case for UPDM which presents a much more convoluted picture. This is seen as a major advantage for MODAF/ NAF in comparison.
    · MODAF/ NAF enables discussions about bandwidth and spectrum utilisation, something that is not a part of UPDM. UPDM differentiates between different types of communication systems and networks however but here the distinction between different entities is far less clear. NAF makes use of Network as an add-on to MODAF but this has primarily been included as a means of stating something in the architecture relating to spectrum and bandwidth.
    · Both in the operational views as well as system views there are a couple of entities that deal with services in UPDM. This handling is seen as very inadequate. MODAF/ NAF contain a lot more in this area than UPDM and this is considered a major issue. In UPDM it also seems unclear whether a service description/ specification is being considered or if an implementation of a service is being described.
    · The extremely large use of extensions of associations that are used by UPDM seems unnecessary and is seen as a problem.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Operational views

  • Key: UPDM-372
  • Legacy Issue Number: 12019
  • Status: open  
  • Source: Anonymous
  • Summary:

    A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
    · MODAF/ NAF attempts to ensure that the modelling taking place as part of the operational views is logical and it uses the concept of ProblemDomain to distinguish between entities that are inside or outside of the trade space of the architecture. This is seen as a great advantage. UPDM has no equivalent concepts and the inclusion of the Materiel entity within the Operational view diminishes the logical handling within the operational views.
    · MODAF/ NAF contains a lot more stereotypes devoted to activity handling within the model than UPDM and while certain simplifications may be possible in this area, the area is still felt to be better covered in MODAF/ NAF than in UPDM
    · UPDM does contain port handling within the operational views, something that can be used to ensure a proper semantic bridging between different levels of abstraction and this is seen as a UPDM advantage. There seems to be some need to complement this model also in UPDM however.
    · The extremely large use of extensions of associations that are used by UPDM seems unnecessary and is seen as a problem.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Strategic views

  • Key: UPDM-371
  • Legacy Issue Number: 12018
  • Status: open  
  • Source: Anonymous
  • Summary:

    A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
    · MODAF/ NAF ensure the ability to indicate capabilities composed of other capabilities. Whether this ability exists in UPDM is much less clear. In the same fashion MODAF/ NAF supports inheritance hierarchies between capabilities. This does not seem to be discussed within UPDM making it difficult to establish proper capability categorisation. The use of a type: String[1] within UPDM: Capability is not considered to be a valid substitute.
    · As stated previously, the inclusion of Effect based entities within UPDM seems pre-mature and the fact that this has been avoided within MODAF/ NAF is perceived as strength.
    · The field-trials and modelling that has been carried out based on MODAF/ NAF indicates that the MODAF/ NAF treatment of capability is valid.
    · The MODAF/ NAF entity dealing named StandardOperationalActivity has proven to be very useful during modelling. No equivalent entity exists as part of UPDM.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

AcV-1: System of Systems Acquisition Clusters

  • Key: UPDM-377
  • Legacy Issue Number: 12024
  • Status: open  
  • Source: Anonymous
  • Summary:

    this view is now called “Acquisition
    Clusters” in MODAF

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Acquisition Views

  • Key: UPDM-376
  • Legacy Issue Number: 12023
  • Status: open  
  • Source: Anonymous
  • Summary:

    The UPDM specification for the AcVs would appear to be incomplete. It specifies the key
    stereotypes (Project, Milestone, etc.), but not the logic needed to put all these together into a
    sensible programme management view (AcV-2).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Acquisition views

  • Key: UPDM-375
  • Legacy Issue Number: 12022
  • Status: open  
  • Source: Anonymous
  • Summary:

    A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
    · There is a very great deal of difference between the MODAF/ NAF Acquisition view entities and the UPDM Acquisition view entities. It is not considered possible to deliver the types of views that MODAF/ NAF requires based on the entities that UPDM contains and this is seen as a major disadvantage.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Technical views

  • Key: UPDM-374
  • Legacy Issue Number: 12021
  • Status: open  
  • Source: Anonymous
  • Summary:

    A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
    · There is a major difference between MODAF/ NAF and UPDM as regards the handling of InformationElement and DataElement. In MODAF/ NAF these are atomic and tied in the data model to a standard where an entity within the standard can go into detail as regards their internal contents. UPDM does not seem to have a data model entity at all making it difficult to assess what should actually be shown as an OV-7 or SV-11 view should this view be desirable. The lack in this area is seen as a UPDM disadvantage.
    · MODAF/ NAF contain various specialisations of standard the support the handling of bandwidth and spectrum handling and this is considered an advantage for MODAF/ NAF in comparison with UPDM.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

MilestonePoint

  • Key: UPDM-381
  • Legacy Issue Number: 12028
  • Status: open  
  • Source: Anonymous
  • Summary:

    the semantics of this relationship are unclear. In addition, there are four
    relationships using this name in the Milestone section, which is very confusing

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Milestone

  • Key: UPDM-380
  • Legacy Issue Number: 12027
  • Status: open  
  • Source: Anonymous
  • Summary:

    capability increment is represented by a string in UPDM. The M3 equivalent
    links to the capability that is met so that there is contiguity through the architecture. Only by
    doing this can StV-3 and SV-8 be derived from the project milestones (essential for
    architectural coherence and contiguity across views).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DLOD Issue Types

  • Key: UPDM-379
  • Legacy Issue Number: 12026
  • Status: open  
  • Source: Anonymous
  • Summary:

    as with the DLOD Elements, UPDM hard-wires the possible status
    indicators. MODAF does not specify this, and neither does the M3

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DLOD Elements

  • Key: UPDM-378
  • Legacy Issue Number: 12025
  • Status: open  
  • Source: Anonymous
  • Summary:

    the MODAF Meta-Model specifically does not mention the Defence Lines
    of Development (which are a UK only concept) so as to allow a more generic mechanism for
    dealing with other project thread approaches – e.g. the US DoD DOTMLPF approach.
    Furthermore, each line of development is specified in the UPDM profile. MOD has recently
    changed the number of lines of development, and there is no reason to assume this will not
    happen again.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

All views

  • Key: UPDM-370
  • Legacy Issue Number: 12017
  • Status: open  
  • Source: Anonymous
  • Summary:

    A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
    · MODAF/ NAF contain environmental entities that can be used to qualify different parts of a MODAF/ NAF model. This has been found to be a necessity during the modelling field trials that have been performed in Sweden. UPDM has no such entities.
    · The handling of the Enterprise entities in MODAF/ NAF gives a much clearer picture of the temporal aspects and can be used to subdivide the enterprise into constituent parts that can be handled separately. No such handling is contained within UPDM.
    · MeasurableProperty handling as well as ontology references in MODAF/ NAF ensure that hard-coded enumerations and classes are not required. Hard-coded enumerations and classes are made use of within UPDM.
    · The handling within MODAF/ NAF of external references and Ontology is also much clearer that external reference handling within UPDM.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

General comparison

  • Key: UPDM-369
  • Legacy Issue Number: 12016
  • Status: open  
  • Source: Anonymous
  • Summary:

    MODAF/ NAF are felt to be a more connected model than UPDM where no attempt is made to show all entities as a connected meta-model for different purposes. This makes UPDM much harder to assess.
    MODAF/ NAF have a much clearer model of temporal components making it a lot easier to discuss how different parts of the model applies at different points in time.
    The MODAF/ NAF use of UML: property ensures that several types of connections that UPDM defines based on associations are unnecessary in MODAF/ NAF.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

All Views

  • Key: UPDM-384
  • Legacy Issue Number: 12031
  • Status: open  
  • Source: Anonymous
  • Summary:

    The AV in UPDM is derived from IEEE1471 (the same goes for MODAF). The interpretation used in
    UPDM is different to that used in M3. The biggest cause for concern is the Resource stereotype. It
    is not clearly defined and attributed. It is not clear whether a resource is an individual resource or a
    type of resource (a key distinction in Enterprise Architecture).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ProjectType specialises from Project

  • Key: UPDM-383
  • Legacy Issue Number: 12030
  • Status: open  
  • Source: Anonymous
  • Summary:

    this is possibly a misunderstanding of the two
    MODAF concepts – a type of project cannot be a special case of a project

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Project

  • Key: UPDM-382
  • Legacy Issue Number: 12029
  • Status: open  
  • Source: Anonymous
  • Summary:

    the UPDM description of Project confines it to the procurement of systems. The
    MODAF approach says nothing about the type of project. This has been deliberately done in
    MODAF to allow for capability increment projects that achieve the increments through
    other means than equipment – e.g. revised doctrine, re-configuration of battlegroups, etc.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Milestone

  • Key: UPDM-366
  • Legacy Issue Number: 12013
  • Status: open  
  • Source: Anonymous
  • Summary:

    · The attributes contained here seem fairly simplistic and it seems doubtful whether they will be enough to manage the information required. By contrast, the meta-model for MODAF/ NAF gives a great deal more.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Acquisition views DLODelements

  • Key: UPDM-365
  • Legacy Issue Number: 12012
  • Status: open  
  • Source: Anonymous
  • Summary:

    · This element may well be too specific and subject to change.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemSystemSoftware

  • Key: UPDM-364
  • Legacy Issue Number: 12011
  • Status: open  
  • Source: Anonymous
  • Summary:

    By the same argument as that indicated in issue 12010 this association is not seen as required.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ArchitectureView

  • Key: UPDM-386
  • Legacy Issue Number: 12033
  • Status: open  
  • Source: Anonymous
  • Summary:

    this is the equivalent of ArchitecturalProduct in M3. However, M3
    takes a different approach; instead of hard-wiring the views into the profile, it allows the
    profile itself to specify the views and the framework used (allowing for NAF, DoDAF, etc. to
    be covered by M3). M3 also specifies the type of product in terms of its nature – i.e.
    structural, behavioural, matrix, etc. UPDM does not.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ArchitectureSummary

  • Key: UPDM-385
  • Legacy Issue Number: 12032
  • Status: open  
  • Source: Anonymous
  • Summary:

    a class library approach is used in UPDM, but not in MODAF

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DLODIssueType

  • Key: UPDM-368
  • Legacy Issue Number: 12015
  • Status: open  
  • Source: Anonymous
  • Summary:

    · As stated previously, the inclusion of hard-coded enumerations is not considered as a good approach.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Project/ ProjectType

  • Key: UPDM-367
  • Legacy Issue Number: 12014
  • Status: open  
  • Source: Anonymous
  • Summary:

    · The fact that a project type should be viewed as a specialisation of project seems very strange. The reverse would be more understandable.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Service

  • Key: UPDM-360
  • Legacy Issue Number: 12007
  • Status: open  
  • Source: Anonymous
  • Summary:

    · It is difficult to see the difference between a service as it is being implemented as well as a service as it is being described. Using an extension of Port also seems strange if is to be possible to actually describe a service functionality in an implementation independent manner. The proposed MODAF/ accepted NAF views for services make distinguishes between the description of a service and how it could be implemented. The description of a service is however much more than a single port. The exposed service port containing the service interface is important. A service taxonomy as well as classification is equally important. Composition as well as description of the service achievement is equally important. It is therefore felt that the parts dealing with services in UPDM might well await further definition of a meta-model for services once this is adopted by OMG.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalActivityRealization

  • Key: UPDM-359
  • Legacy Issue Number: 12006
  • Status: open  
  • Source: Anonymous
  • Summary:

    · The description given for this entity would seem to make it difficult to distinguish this and a CapabilityConfiguration (at least from a MODAF/ NAF perspective). Is there a need for this given the existence of the CapabilityConfiguration entity?

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Network/ NetworkPaths

  • Key: UPDM-358
  • Legacy Issue Number: 12005
  • Status: open  
  • Source: Anonymous
  • Summary:

    · The only difference that can be seen between CommunicationSystem and Network would seem to be dealing with geographical extension. Is there really a need to maintain two different entities to cover this area?

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalActivity

  • Key: UPDM-340
  • Legacy Issue Number: 11987
  • Status: open  
  • Source: Anonymous
  • Summary:

    t is noted that OperationalActivity handling does not seem to consider the entities that are considered as required when creating activity diagrams such as swimlanes, callbehavioraction, pins etc. Such entities exist in MOFAF/ NAF.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Materiel/ MaterielBehavior/ MaterielNode

  • Key: UPDM-339
  • Legacy Issue Number: 11986
  • Status: open  
  • Source: Anonymous
  • Summary:

    · Materiel is a very broadly defined entity that seems to relate to almost everything. At first glance the MODAF/ NAF equivalent would seem to be PhysicalAsset but given the concept of MaterielBehaviour this does not seem to be the case. First of all Materiel does not seem to need to be related to anything inside the OperationalViews and provided it is to be retained it should be confined to the SystemViews. The reason for this is twofold:
    o The operational views deal with logical operations not with solutions and by introducing materiel solutions are being discussed something that should be done in the system views.
    o In cases where entities in the operational views need to be made physical, something that happens when they do not belong to the trade-space as such, there is no need to go to a level of detail that needs materiel. MODAF/ NAF deals with a distinction between the two types of entities by stating by the use of a problem domain entity, a very useful concept.
    The association entities therefore also seem questionable.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNodePort

  • Key: UPDM-345
  • Legacy Issue Number: 11992
  • Status: open  
  • Source: Anonymous
  • Summary:

    · In spite of the fact that no such entity exists in MODAF and NAF, its inclusion is considered a good idea as a means of bridging the gaps between different levels of abstraction in an operational node model.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNode

  • Key: UPDM-344
  • Legacy Issue Number: 11991
  • Status: open  
  • Source: Anonymous
  • Summary:

    · As stated before, MODAF/ NAF considers nodes as logical entities that could almost be viewed as instances of a capability. The connection to resources are therefore less than clear and as stated previously associations to effect are not considered appropriate at this point.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRole/ OperationalCapabilityRoleCompetence

  • Key: UPDM-343
  • Legacy Issue Number: 11990
  • Status: open  
  • Source: Anonymous
  • Summary:

    · The fact that the first entity is supposed to be a specialisation of operational node is strange. It would also seem to belong squarely within the System View entities. Since the relationship is already there based on MODAF/ NAF entities it is considered questionable whether this is actually required.
    · The association extension seems questionable at least from a MODAF/ NAF perspective.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalServiceConsumer/ OperationalServiceProvider

  • Key: UPDM-348
  • Legacy Issue Number: 11995
  • Status: open  
  • Source: Anonymous
  • Summary:

    · The use of service related concepts here would seem to require a complete service handling throughout and this does not seem to be the case in UPDM, possibly due to the fact that OMG is considering other profiles for services. Based on this it would seem better to await developments here.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalRole/ OperationalCapabilityRole/ OrganisationalRole

  • Key: UPDM-347
  • Legacy Issue Number: 11994
  • Status: open  
  • Source: Anonymous
  • Summary:

    · The number of roles used here seems to restate much the same thing in different contexts. MODAF/NAF makes use of a single Role concept and that would seem to be enough.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNodeSpecification

  • Key: UPDM-346
  • Legacy Issue Number: 11993
  • Status: open  
  • Source: Anonymous
  • Summary:

    · This is also considered a good idea, however, in order to be complete there would seem to be a need to tie required and provided interfaces to a port as well as InformationElements by means of the interfaces to make the handling complete.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganisationalRelationship

  • Key: UPDM-350
  • Legacy Issue Number: 11997
  • Status: open  
  • Source: Anonymous
  • Summary:

    · The attributes here would seem to be reconsidered. It may well be appropriate to avoid these altogether since the few entries contained seem unable to capture all aspects of organisational relationships. A brief check within CADM for instance reveals a great deal of different relationships and it would therefore seem better to let the architecture model itself deal with this either internally or through external references.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalTask

  • Key: UPDM-349
  • Legacy Issue Number: 11996
  • Status: open  
  • Source: Anonymous
  • Summary:

    · This could be used to tie rather nicely into the handling of interfaces and ports in which case an operation could be a part of an interface associated with a realized interface that forms a part of a port. In all fairness however, if operations are made use of it is felt that signals should also be allowed, especially since a good way of visualising operations would be to allow InformationElements to be conveyed by signals (they could of course also be dealt with as part of the attributes associated with a given operation).

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResultsOfEffect

  • Key: UPDM-353
  • Legacy Issue Number: 12000
  • Status: open  
  • Source: Anonymous
  • Summary:

    · As stated above, the use of Effect seems premature and it is therefore felt that this should be removed.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Policy/ Rule

  • Key: UPDM-352
  • Legacy Issue Number: 11999
  • Status: open  
  • Source: Anonymous
  • Summary:

    · It seems slightly difficult to distinguish between these two entities and the questions should be asked whether they are both really needed.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganisationalResource

  • Key: UPDM-351
  • Legacy Issue Number: 11998
  • Status: open  
  • Source: Anonymous
  • Summary:

    · While it is important to be able to show these entities in the form of an organisation chart it needs to be noted that MODAF/ NAF distinguishes between actual organisational resources or types of resources, something that may well be required depending on the scope of the model.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DataElementSystemFunction

  • Key: UPDM-357
  • Legacy Issue Number: 12004
  • Status: open  
  • Source: Anonymous
  • Summary:

    · This association also seems questionable since the relationship will anyway be present as a result of the definition of the system function itself.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

System views

  • Key: UPDM-356
  • Legacy Issue Number: 12003
  • Status: open  
  • Source: Anonymous
  • Summary:

    CommPathFromTo/ CommunicationLink/ CommunicationPath/ CommunicationSystem/ CommunicationPathRealization
    · The main items here would seem to be connectors between systems and their aggregation into paths that could also include intervening communications systems. This makes sense, however the CommPathFromTo association seems fairly superfluous. The same can be stated for CommunicationPathRealization.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRealization

  • Key: UPDM-342
  • Legacy Issue Number: 11989
  • Status: open  
  • Source: Anonymous
  • Summary:

    · The fact that this is a specialisation of OperationalNode is considered strange as is the relationship it establishes. The crucial relationship would seem to be between capability and CapabilityConfiguration, this is the one that has to be maintained.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapability

  • Key: UPDM-341
  • Legacy Issue Number: 11988
  • Status: open  
  • Source: Anonymous
  • Summary:

    · This seems to define an entity in the form of UseCase "above" ordinary capabilities. It is however felt that the name leaves something to be desired (suggestion: CapabilityUseCase) and that it should be part of the StrategicViews rather than the OperationalViews.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

RealizedOperaionalSpecification

  • Key: UPDM-355
  • Legacy Issue Number: 12002
  • Status: open  
  • Source: Anonymous
  • Summary:

    · Since the connections between OperationalNode, OperationalNodePort and OperationalNodeSpecification is already established it seems unclear why this relationship would need to be established explicitly.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResultsOfEffect

  • Key: UPDM-354
  • Legacy Issue Number: 12001
  • Status: open  
  • Source: Anonymous
  • Summary:

    · As stated above, the use of Effect seems premature and it is therefore felt that this should be removed.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

PerformanceMeasureSet

  • Key: UPDM-387
  • Legacy Issue Number: 12034
  • Status: open  
  • Source: Anonymous
  • Summary:

    the purpose of this (and its related stereotypes) is not entirely
    clear. It is defined as being applied to any ConformingElement, but the “semantics” section
    talks about system performance

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemsNode/ SystemsNodeElements

  • Key: UPDM-363
  • Legacy Issue Number: 12010
  • Status: open  
  • Source: Anonymous
  • Summary:

    · MODAF/ NAF does not contain a system node concept and the question is whether a more applicable concept here would not be CapabilityConfiguration. The statement that a system node would be equivalent to PhysicalAsset in MODAF is not correct. If however there is a hidden assumption that a systems node has to be in a single location, then Capability configuration is broader since this would not be a requirement.
    · It is considered questionable whether the association extension is really required. A CapabilityConfiguration (to use a MODAF/ NAF term) would be visualised as a composite class diagram and the entities would thus turn up as connected to the surrounding entity without the need of a specific association.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemServiceConsumer/ SystemServiceProvider

  • Key: UPDM-362
  • Legacy Issue Number: 12009
  • Status: open  
  • Source: Anonymous
  • Summary:

    · It is considered questionable whether the above entities are really of interest. A service is realized by a CapabilityConfiguration in MODAF/ NAF not just a system and anything other than web services will require more than this to indicate usage as well as provision of services. Being a consumer or provider will depend very highly on the point of view taken.
    · It is noted that in both of these, the text states that they are specialisations from System but the diagram shows them as extensions of class.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ServiceSpecification

  • Key: UPDM-361
  • Legacy Issue Number: 12008
  • Status: open  
  • Source: Anonymous
  • Summary:

    · See previous comment. In addition to this the attribute serviceDescription seems to be a link to a formal service description or a description of the service itself. Linking to an external specification is not considered enough for an architecture model intended to describe SOA, neither is a single text description.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

StrategicMission

  • Key: UPDM-327
  • Legacy Issue Number: 11973
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Concern/ Stakeholder/ StakeholderConcern

  • Key: UPDM-326
  • Legacy Issue Number: 11972
  • Status: open  
  • Source: Anonymous
  • Summary:

    · The relationship between these entities seems far from clear. A concern is an extension of UseCase and is associated with a Stakeholder as well as an ArchitectureView. A stakeholder is also associated with an architecture view and the relationship between Stakeholder and concern is stereotypes as StakeholderConcern. It would therefore seem that connections to ArchitectureView exist both through the concern and from the stakeholder directly. Is this really required?

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Resource

  • Key: UPDM-325
  • Legacy Issue Number: 11971
  • Status: open  
  • Source: Anonymous
  • Summary:

    · Resource, given the explanation given also seems far better placed elsewhere than as part of AllViews. Given the extension used (Class) it is obviously a Type, but there seems to be some further classification going on since a resourceType parameter in the form of a string has been included. A ResourceType entity seems of interest. The value parameter also seems strange and the use to which this can actually be put seems questionable.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityConfiguration

  • Key: UPDM-330
  • Legacy Issue Number: 11977
  • Status: open  
  • Source: Anonymous
  • Summary:

    · This entity would seem to be better positioned within the SystemView elements.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Capability

  • Key: UPDM-329
  • Legacy Issue Number: 11976
  • Status: open  
  • Source: Anonymous
  • Summary:

    · Capability is shown as directly tied to resources, something that from a MODAF/ NAF perspective would be OK provided the entity was a CapabilityConfiguration. A Capability is an abstract high-level view of that which an enterprise wants to be able to accomplish during a specific time frame. Some of the attributes shown here are also strange such as type and isFielded which would seem to merit entities all by themselves in order to be usable.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ExternalReferenceType/ InformationAssurance/ Security

  • Key: UPDM-328
  • Legacy Issue Number: 11975
  • Status: open  
  • Source: Anonymous
  • Summary:

    · Why do the ExternalReferenceType literals in the table repeat themselves as table entries?
    · While InformationAssurance and Security are of concern to an architect, it is considered highly doubtful whether the parameters shown here will cover the issue. Since these are examples of issues that require management across an entire enterprise it may be more profitable to look into aspect-oriented modelling concepts as a means of covering such issues.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Asset/ AssetMapping

  • Key: UPDM-338
  • Legacy Issue Number: 11985
  • Status: open  
  • Source: Anonymous
  • Summary:

    · This seems to be a way of creating entities solely for the use within OV-1. The mapping entity then establishes a relationship between the asset and entities elsewhere. MODAF/ NAF manages this by viewing all the above as ConceptItems and therefore no additional entry is required. However since OV-1 users tend to want to draw lines between entities MODAF/ NAF has added an arbitrary connection element that can be used to indicate this. This has no semantic meaning however other than as an illustration. It is noted that no such feature seems to exist in UPDM.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Operational views - ActivityRealization

  • Key: UPDM-337
  • Legacy Issue Number: 11984
  • Status: open  
  • Source: Anonymous
  • Summary:

    · This extension of association is used to tie an OperationalActivity (an operational view element) to an OperationalActivityRealization (a system view element) or a SystemFunction (a system view element) to an OperationalCapabilityRealization (an operational view element). Based on the semantics description this seems to be intended to create one-to-many mappings between OperationalActivity (s) and SystemFunction(s) in both directions. The above seems a very cumbersome approach and is handled in a far simpler but equally functional way in MODAF/ NAF.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Effect/ CausesEffect/ EffectAffectsNode/ NodeCausesEffect/ OperationalCapab

  • Key: UPDM-334
  • Legacy Issue Number: 11981
  • Status: open  
  • Source: Anonymous
  • Summary:

    Effect/ CausesEffect/ EffectAffectsNode/ NodeCausesEffect/ OperationalCapabilityEffect
    · Previous versions of MODAF/ NAF contained an effect entity. This has now been removed since it is felt that effect based operations handling require additional consideration before an attempt is made to include it within the architecture framework. The inclusion of effect and associated entities within UPDM seems premature.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityRequirement/ CapabilityRequirementCapability

  • Key: UPDM-333
  • Legacy Issue Number: 11980
  • Status: open  
  • Source: Anonymous
  • Summary:

    · This entity has been removed in MODAF/ NAF as unnecessary. The relationships shown also seem strange. As commented upon later the crucial entity is Capability, and the fact that there is no relationship here between capability and a requirement for it therefore seems strange. Essentially all relationships shown for this entity are considered as highly questionable.
    · The need for CapabilityRequirementCapability as an extension of Association is also considered questionable.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNodeCapabilityRequirement

  • Key: UPDM-336
  • Legacy Issue Number: 11983
  • Status: open  
  • Source: Anonymous
  • Summary:

    OperationalNodeCapabilityRequirement/ OrganisationalResourceCapabilityConfiguration/ ResourceCapability/ ResourceCapabilityConfiguration
    · The description of OperationalNodeCapabilityRequirement discusses the need for a relationship between capability and operational node whereas the constraints as well as the name talks about a relationship between a CapabilityRequirement and an OperationalNode. The text should, if it is actually to remain be amended.
    · All of the above extensions of association are considered questionable as to need. Using MODAF/ NAF the fact that capability configurations are built by resources are apparent in the model and no additional associations are required.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNodeCapabilityRequirement

  • Key: UPDM-335
  • Legacy Issue Number: 11982
  • Status: open  
  • Source: Anonymous
  • Summary:

    · As commented upon both previously and later, the need for this association seems questionable.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

PerformanceMeasureSet/ PerformanceParameterSet/ PerformanceParameterTyp

  • Key: UPDM-324
  • Legacy Issue Number: 11970
  • Status: open  
  • Source: Anonymous
  • Summary:

    · PerformanceMeasureSet also turns up as PerformanceMeasurementSet in a number of places and the correct term therefore needs to be established.
    · The attributes make use of the entity PerformanceMeasurementPeriod which does not appear anywhere else in the document.
    · The descriptions of all of these seem somewhat circular and could do with some modification: PerformanceMeasureSet ="This stereotype (PerformanceMeasureSet) is applied to instances of classes stereotyped PerformanceParameterSet". PerformanceParameterSet = "This stereotype is applied to PerformanceMeasurementSet in the UPDM class library".

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Goal

  • Key: UPDM-323
  • Legacy Issue Number: 11969
  • Status: open  
  • Source: Anonymous
  • Summary:

    · This is shown as part of AllViews but would seem much better placed as part of the StrategicViews.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityOperationalCapability

  • Key: UPDM-332
  • Legacy Issue Number: 11979
  • Status: open  
  • Source: Anonymous
  • Summary:

    · This entity seems highly questionable and is commented on later as part of comments concerning OperationalCapability.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityConfigurationCapability

  • Key: UPDM-331
  • Legacy Issue Number: 11978
  • Status: open  
  • Source: Anonymous
  • Summary:

    · This entity would work better as an extension of Dependency rather than association. It furthermore needs to be noted that capability configurations are defined by the capability they implement not the other way around. This implies that the supplier of the relationship is the capability and that the client is the CapabilityConfiguration of which there may be more than one since different combinations of resources could be used to supply a capability.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Enterprise

  • Key: UPDM-322
  • Legacy Issue Number: 11968
  • Status: open  
  • Source: Anonymous
  • Summary:

    · By considering Enterprise as an extension of Package, the ability to use this effectively in a model seems to be severely limited. MODAF/ NAF.
    · MODAF/ NAF provides the ability to consider the enterprise as a set of temporal parts as well as whole-parts, something that will yield an ability to be much more specific as regards the enterprise.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Doctrine

  • Key: UPDM-321
  • Legacy Issue Number: 11967
  • Status: open  
  • Source: Anonymous
  • Summary:

    · This entity seems better placed as part of the Strategic or the Operational views. It is furthermore shown as having an association with a SystemTask. This, while potentially the reason for placing in this view group, seems somewhat superfluous.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ArchitectureDescription

  • Key: UPDM-320
  • Legacy Issue Number: 11966
  • Status: open  
  • Source: Anonymous
  • Summary:

    · The attribute instances of architecture summary indicate [1] and the constraints talk about zero or more.
    · The constraints seem to indicate a relationship between the architecture enterprise and an Enterprise which is not shown.
    · An architecture summary is shown as a specific class rather than a stereotype. The necessity of this can be questioned.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Swedish Armed Forces General Comments

  • Key: UPDM-319
  • Legacy Issue Number: 11965
  • Status: open  
  • Source: Anonymous
  • Summary:

    · UPDM uses extensions of associations to a very large degree, in most cases first showing entities as having named associations to other entities and then defining stereotypes for these associations. It is the view of the author that this should have been dealt with by making use of the association extensions within the meta-model itself rather than having them as separate entities. The latter is the approach adopted by MODAF.
    · A set of different entities have been hard-coded into UPDM in the form of classes as well as enumeration entities. This is considered fairly dangerous since this can very well change over time making UPDM difficult to maintain. Its use could also well pose national problems since the values may not be applicable everywhere. MODAF/ NAF have avoided the use of any such entities and left them to be part of the model or referred to as externally defined entities, something that seems to be a better approach.
    · It is difficult to understand why the different views should be stereotyped at all. The whole point of a modern architecture framework would seem to be to get away from strict adherence to a set of views. The main utility is the meta-model itself and how different entities tie together. How a user elects to visualise this is much less important. The addition of the Custom view is not felt to adequately deal with this.
    · It is noted that as UPDM contains different compliance levels, exchanges between tools operating at different UPDM compliance levels will require recognition of these differences as well as translations if the exchange is to be successful.

  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Ambiguos relation between Forecast and Milestone

  • Key: UPDM-318
  • Legacy Issue Number: 11957
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    From 8.6.12
    "8.6.12.3 Description
    A Forecast describes the actual or predicted status of a System at a Project Milestone - i.e., a point in the lifecycle of the
    system. It can be a statement about the future state of one or more types of System or TechnicalStandardsForecast.
    The Forecast is effective for a given timePeriod."

    SystemGroup is also related to the Milestone (from 8.6.38).

    There should be a constraint ensuring that there is at least one Milestone related to the SystemGroup directly and to the Forecast that is related to this SystemGroup. It would not make any sense to have a Forecast at the specific Milestone when a SystemGroup does not even exist.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

GroupForecast metaclass should be Usage or Dependency

  • Key: UPDM-304
  • Legacy Issue Number: 11943
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Unnecessary properties (association ends) are created.
    Name is not informative

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “forecasts”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ForecastStandardsProfile metaclass should be Usage or Dependency.

  • Key: UPDM-303
  • Legacy Issue Number: 11942
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Unnecessary properties (association ends) are created.
    Name is not informative and too long
    Solution #1

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “groups” or “owns”

    Solution #2

    Remove ForecastStandardsProfile
    Change metaclass for TechnicalStandardsProfile to Package
    Use ElementImport or Ownership to link Forecast and TechnicalStandardsProfile

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

EffectAffectsNode metaclass should be Usage or Dependency

  • Key: UPDM-302
  • Legacy Issue Number: 11941
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Unnecessary properties (association ends) are created.
    Name is not informative and too long

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “affects”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

NodeCausesEffect metaclass should be Usage or Dependency

  • Key: UPDM-306
  • Legacy Issue Number: 11945
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Unnecessary properties (association ends) are created.
    Name is not informative and too long
    Node cannot cause Effect, it should be Node’s behavior that does it. This relation is somewhat duplicated by

    OperationalCapabilityEffect.

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “causes”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

MilestonePoint metaclass should be Usage or Dependency

  • Key: UPDM-305
  • Legacy Issue Number: 11944
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Unnecessary properties (association ends) are created.
    Name is not informative

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “governs”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResourceCapability metaclass should be Usage or Dependency

  • Key: UPDM-313
  • Legacy Issue Number: 11952
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Semantics is not clear. Is it Capabilities provided by Resource or Resources needed by Capability.
    Direction is not clear
    Name is not informative

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “requiredBy” or “providedBy (depending on sematics)

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganizationalResourceCapabilityConfiguration metaclass

  • Key: UPDM-312
  • Legacy Issue Number: 11951
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    OrganizationalResourceCapabilityConfiguration metaclass should be Usage or Dependency.

    Problem

    Direction is not clear
    Name is not informative and too long

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “configuredBy”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganizationalRelationship metaclass should be Usage or Dependency

  • Key: UPDM-311
  • Legacy Issue Number: 11950
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear. Very important in this case.
    Name is too long

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Multiple stereotypes could be introduced – “direct”, “indirect”, “back-up”, etc.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNodeCapabilityRequirement metaclass should be Usage or Dependenc

  • Key: UPDM-310
  • Legacy Issue Number: 11949
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Unnecessary properties (association ends) are created.
    Name is not informative and too long

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “requiredBy”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRoleResource metaclass should be Usage or Dependency

  • Key: UPDM-309
  • Legacy Issue Number: 11948
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Unnecessary properties (association ends) are created.
    Name is not informative and too long

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “playsRole” or “plays”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRoleCompetence metaclass should be Usage or Dependency

  • Key: UPDM-308
  • Legacy Issue Number: 11947
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Unnecessary properties (association ends) are created.
    Name is not informative and too long

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “requiredCompetency” or “requires”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResourceCompetence metaclass should be Usage or Dependency

  • Key: UPDM-315
  • Legacy Issue Number: 11954
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Name is not informative
    There might be a read-only library of Competencies, so modification is not wanted.

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “providedBy”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResourceCapabilityConfiguration metaclass should be Usage or Dependency

  • Key: UPDM-314
  • Legacy Issue Number: 11953
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Name is not informative

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “includedIn”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemsNodeElements metaclass should be Usage or Dependency

  • Key: UPDM-317
  • Legacy Issue Number: 11956
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Description could be more informative.
    Name is not too long.

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “hosts”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemGroupMember metaclass should be Usage or Dependency

  • Key: UPDM-316
  • Legacy Issue Number: 11955
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear.
    Name is not too long.

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “groups”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityEffect should be Usage or Dependency

  • Key: UPDM-307
  • Legacy Issue Number: 11946
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Unnecessary properties (association ends) are created.
    Name is not informative and too long
    Different semantics in case of different ends.

    Solution

    Create one relationship for realization and one for delivery.
    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.37.3 Description

  • Key: UPDM-292
  • Legacy Issue Number: 11931
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    SystemFunctionSpecifications are abstract Systems modeled as Interfaces. They are not limited to internal system
    functions and can include Human Computer Interface (HCI) and Graphical User Interface (GUI) functions or functions
    that consume or produce DataElements from/to SystemFunctionSpecifications that belong to external systems. The
    external system data sources and/or sinks can be used to represent the humans that interact with the system or external
    systems. The SystemInformationFlows between the external system data source/sink (representing the human or system)
    and the HCI, GUI, or SystemFunctionSpecification can be used to represent human-system interactions, or system-system
    interfaces. Standards that apply to system functions, such as HCI and GUI standards, are also specified in this product
    through the ConformingElement relationship.
    The relationship between OperationalActivities and SystemFunctions can also be expected to be many-to- many."

    UML terms are used. Description should be more about semantics, etc.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.36.3 Description

  • Key: UPDM-291
  • Legacy Issue Number: 11930
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Defines the behavior of a System or OperationalActivityRealization as an activity in terms of invocations of
    SystemFunctions connected by SystemControlFlows and the flow of objects through the System with
    SystemInformationFlows."

    Description should be more informative and clear.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityOperationalCapability metaclass should be Usage or Dependency

  • Key: UPDM-299
  • Legacy Issue Number: 11938
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Unnecessary properties (association ends) are created.
    Name is not informative

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “supportedBy”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityConfigurationCapabilities metaclass should be Usage or Dependency

  • Key: UPDM-298
  • Legacy Issue Number: 11937
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Unnecessary properties (association ends) are created.
    Name is not informative

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “configuredBy”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DeliveredCapability metaclass should be Usage or Dependency

  • Key: UPDM-301
  • Legacy Issue Number: 11940
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Unnecessary properties (association ends) are created.
    Name is not informative

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “delivers”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityRequirementCapability metaclass should be Usage or Dependency

  • Key: UPDM-300
  • Legacy Issue Number: 11939
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Direction is not clear
    Unnecessary properties (association ends) are created.
    Name is not informative

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “relatedTo”

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.35.3 Description

  • Key: UPDM-290
  • Legacy Issue Number: 11929
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Specifies the behavior of a System or OperationalActivityRealization as an Interaction - by depicting the sequence of
    events between Systems and the invocation (TaskInvocation) of SystemTasks. The behavior of an interaction is depicted
    in a sequence diagram that shows the ordered exchange of information between Systems through the activation of their
    SystemTasks that participate in the interaction."

    UML terms are used.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.34.3 Description

  • Key: UPDM-289
  • Legacy Issue Number: 11928
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    A flow of control, energy from one activity node to another."

    Description should be more informative - why and where this element should be used.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.15.3 Description

  • Key: UPDM-286
  • Legacy Issue Number: 11925
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    A Network is a collection of one or more CommunicationPaths. It may contain multiple CommunicationPaths between
    the same pair of Systems. This is typically realized by the Network owning a set of CommunicationPaths.

    Description is wrong.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.14.3 Description

  • Key: UPDM-285
  • Legacy Issue Number: 11924
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    A Location is anywhere that can be specified. The means of describing the location is a string (locationDescription). The
    information contained in that string is governed by the locationType."

    Description should be more informative - why and where this element should be used.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActivityRealization metaclass should be Realization

  • Key: UPDM-297
  • Legacy Issue Number: 11936
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Problem

    Unnecessary properties (association ends) are created.
    Direction is not clear
    Solution
    Change metaclass to Realization.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability (if needed).

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.7.2.3 Description

  • Key: UPDM-296
  • Legacy Issue Number: 11935
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Asserts that there is an association between a Forecast and a TechnicalStandardsProfile."

    Description should be more informative. What "association" means in this context?

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.18.3 Description

  • Key: UPDM-288
  • Legacy Issue Number: 11927
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Specifies that a System or one of its sub stereotypes realizes an interface stereotyped SystemFunctionSpecification or one
    of its sub stereotypes."

    UML terms are used. Description should be more about semantics, etc.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.17.3 Description

  • Key: UPDM-287
  • Legacy Issue Number: 11926
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    OperationalActivityRealization is a collaboration among Systems or SystemFunctionSpecifications that realize an
    OperationalCapabilityRealization or other System capability."

    Description should be more informative - why and where this element should be used.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.48.3 Description

  • Key: UPDM-295
  • Legacy Issue Number: 11934
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Specifies these are the elements associated with a SystemsNode."

    Description should be more informative. What "associated" means in this context?

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.39.3 Description

  • Key: UPDM-294
  • Legacy Issue Number: 11933
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Specifies the System elements configured with a System."

    It should be "Specifies the System elements configured with a SystemGroup". However I'm not sure if such description is enough.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.38.3 Description

  • Key: UPDM-293
  • Legacy Issue Number: 11932
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    The SystemGroup is a collection that includes instances of System, SystemHardware and SystemSoftware that forms a
    unit for tracking and assessment purposes."

    Description is wrong.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.5.13.3 Description

  • Key: UPDM-276
  • Legacy Issue Number: 11915
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Specifies that an OperationalCapabilityRealization delivers the Effect, or that an OperationalActivityRealization realizes
    an Effect."

    The description is not sufficient

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.5.10.3 Description

  • Key: UPDM-275
  • Legacy Issue Number: 11914
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    An Effect is an action that brings about a change in the state of something. The event that initiates the action is a Trigger.
    The action is the result of an OperationalTask. An Effect is caused by collaborating OperationalNodes that bring about the
    Effect as a result of their OperationalTasks. The collaboration, an OperationalCapabilityRealization, can be described in
    terms of the Effect that it has. This Effect can be observed in an EventTrace from the perspective of the sequence of OperationalTasks. It can be seen in a StateTrace as a transition that CausesEffect showing the Trigger, the Effect, and the
    desired ResultOfEffect, the end state. The OperationalActivity can show the Events that are Triggered and the receiving
    Action that includes the OperationalTask in callOperationActions.
    An Effect is the central player in all of these scenarios unifying the OperationalCapabilityRealization with the Effect,
    viewed from the perspective of the collaborating OperationalNodes, the Triggers, States, and Activities."

    UML terms are used. Meaning and usage of this element should be described.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.5.9.3 Description

  • Key: UPDM-274
  • Legacy Issue Number: 11913
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    A transition from one state to another Causes an Effect. The Effect is the call event that invokes an OperationalActivity
    on the receiving OperationalNode. The affected OperationalNode is the receiver of the InformationExchange while the
    causing OperationalNode is the originator of the InformationExchange. The change in state is the Effect of the
    InformationExchange. (See Effect)."

    UML terms are used. Meaning and usage of this element should be described.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.5.8.3 Description

  • Key: UPDM-273
  • Legacy Issue Number: 11912
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Asserts that a CapabilityRequirement is related to an OperationalCapability."

    The description is not clear. It is hard to understand what this relationship means.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.5.3 Description

  • Key: UPDM-280
  • Legacy Issue Number: 11919
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Asserts that the CommunicationPath is realized by a CommunicationsSystem described in terms of
    CommunicationsSystems and Systems connected by CommunicationLinks."

    Description is wrong

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.3.3 Description

  • Key: UPDM-279
  • Legacy Issue Number: 11918
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    A communications link is a single physical connection from one system (or node) to another. A communications path is a
    (connected) sequence of communications systems and communications links originating from one system (or node) and
    terminating at another systems (or node)."

    The OCL does not allow SystemsNodes to be linked, but description says so.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.12.3 Description

  • Key: UPDM-284
  • Legacy Issue Number: 11923
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    A Forecast describes the actual or predicted status of a System at a Project Milestone - i.e., a point in the lifecycle of the
    system. It can be a statement about the future state of one or more types of System or TechnicalStandardsForecast.
    The Forecast is effective for a given timePeriod."

    Forecast is linked to a SystemsGroup, not a System,

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.9.3 Description

  • Key: UPDM-283
  • Legacy Issue Number: 11922
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    A data element exchanged in between systems."

    The description should be more informative.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.7.3 Description

  • Key: UPDM-282
  • Legacy Issue Number: 11921
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    A CommunicationPort occurs at the end of CommunicationLinks when it is necessary to provide details on the actual
    connection. CommunicationPort may implement a PortType, though there is no requirement to be typed."

    It is not clear what details spec is talking about. The description should be more informative.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.6.3 Description

  • Key: UPDM-281
  • Legacy Issue Number: 11920
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Asserts that a CommunicationPath realizes a SystemInterface."

    A description should be more informative.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.45.3 Description

  • Key: UPDM-271
  • Legacy Issue Number: 11910
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    In effects based planning, the focus is on the outcome of an Effect. This is that end state, the ResultsOfEffect."

    The description is not clear.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.43.3 Description

  • Key: UPDM-270
  • Legacy Issue Number: 11909
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Specifies that a OperationalNode or one of its sub stereotypes realizes an interface stereotyed
    OperationalNodeSpecification or one of its sub stereotypes."

    UML terms are used. Meaning and usage of this element should be described

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.5.17.3 Description

  • Key: UPDM-278
  • Legacy Issue Number: 11917
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Defines the association between a CapabilityConfiguration and the all of Resources that are included in it."

    The description could provide more information.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.5.16.3 Description

  • Key: UPDM-277
  • Legacy Issue Number: 11916
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Specifies an association exists between a Resource and the Capabilities that it provides, that is, the Resources required for
    a Capability."

    There is a big difference between Resource providing Capability and Capability requiring Resources. Which one is it?

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.31.3 Description

  • Key: UPDM-269
  • Legacy Issue Number: 11908
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    OrganizationalRelationship describes the relationship between two OrganizationalResources."

    The description should be more informative"

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.28.3 Description

  • Key: UPDM-268
  • Legacy Issue Number: 11907
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    This is the state machine for OV-5."

    Wrong and not informative

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.47.3 Description

  • Key: UPDM-272
  • Legacy Issue Number: 11911
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    The event that invokes either an OperationalTask or a SystemTask in the EventTrace.
    The ends of the connector associated with the message are the source and target of the information flow and the argument
    is the information element. If there is no argument, then the invocation, itself, is the information element - i.e., a
    command."

    UML terms are used. Meaning and usage of this element should be described.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.18.3 Description

  • Key: UPDM-261
  • Legacy Issue Number: 11900
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Specification is the ancestor of all the stereotypes that extend Instance Specification. It implements the common attribute,
    description.
    In general, any of the classes supplied in the class library as the type for instance specifications can be extended to
    include additional attributes to be used in custom instance specifications.
    Instances are created from classes that are defined in the UPDM ModelLibrary. The values of the attributes of the parent
    class are set in the slots of the instance. Associations among instances of classes that reside in the Model Library are
    specified by creating a link that is an instance of an association that is defined on the classes in the Model Library. In
    addition, the stereotyped instance may have stereotype properties that define relationships to other stereotyped classes."

    There is no description attribute.
    It is not clear why this stereotype exists and how it should be used.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.16.3 Description

  • Key: UPDM-260
  • Legacy Issue Number: 11899
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    PerformanceParameterType provides details for the type of attribute for PerformanceParameterSet."

    The description is not sufficient. It should explain what is the meaning of this element and how it is used.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Description is not sufficient.

  • Key: UPDM-256
  • Legacy Issue Number: 11824
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Description is not sufficient.
    8.7.2.3 Description
    Asserts that there is an association between a Forecast and a TechnicalStandardsProfile.

  • Reported: UPDM 1.0b1 — Fri, 14 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Text needs to be updated, since DeployedToSystemsNode does not exist

  • Key: UPDM-255
  • Legacy Issue Number: 11813
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    "8.4.32.7 Semantics
    Use the DeployedToSystemsNode association to indicate deployment of
    OrganizationalResource to a SystemsNode.
    Use the OperationalCapabilityRoleResource association to indicate an
    OrganizationalRole played by the OrganizationalResource.
    Use the OrganizationalResourceCapabilityConfiguration association to indicate
    inclusion in a CapabilityConfiguration
    Use the DeployedToSystemsNode association to indicate deployment of
    OrganizationalResource to a SystemsNode.
    Use the DeployedToSystemsNode association to indicate deployment of
    OrganizationalResource to a SystemsNode."

  • Reported: UPDM 1.0b1 — Wed, 12 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.15.3 Description

  • Key: UPDM-259
  • Legacy Issue Number: 11898
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    This Stereotype is applied to the PerformanceMeasurementSet in the UPDM ClassLibrary."

    Does not make any sense

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.14.3 Description

  • Key: UPDM-258
  • Legacy Issue Number: 11897
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    A PerformanceMeasurementrSet includes a set of PerformanceMeasures for each PerformanceMeasurePeriod. The set is
    applied to ConformingElements. (See UPDM Class Library). This stereotype is applied to instances of classes stereotyped
    PerformanceParameterSet."

    Typo "PerformanceMeasurementrSet"
    PerformanceMeasurementSet does not include any PerformanceMeasures, since there is not such element. It includes actual values for each PerformanceParameterType that are owned by linked PerformanceParameterSet.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.23.3 Description

  • Key: UPDM-267
  • Legacy Issue Number: 11906
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    An OperationalNodePort is used to model details of Node connections when a Needline is modeled as a connector."

    If this element is needed only to facilitate UML usage, it is not needed as separate stereotype. If there is some other meaning, it should be defined in the description.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.19.3 Description

  • Key: UPDM-266
  • Legacy Issue Number: 11905
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    A flow of control of energy from one activity node to another."

    It is not clear why this elements is needed and how it is used

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.17.3 Description

  • Key: UPDM-265
  • Legacy Issue Number: 11904
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Specifies that an OperationalCapabilityRole requires zero or more Competencies and a Competence is required by zero or
    more OperationalCapabilityRole and that these are the elements associated with this association."

    If a OperationalCapabilityRole required Competency, it does not mean that Competency requires OperationalCapabilityRole, but the description says so.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.14.3 Description

  • Key: UPDM-264
  • Legacy Issue Number: 11903
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    An OperationalCapability is a Use Case that specifies the requirements for a Capability."

    UML terms should not be used in descriptions.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.6.3 Description

  • Key: UPDM-263
  • Legacy Issue Number: 11902
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    A Resource or OrganizationalRole can have a set of related Competencies that are required or provided to meet their
    declared responsibilities and perform their OperationalTasks."

    It is not clear clear if it is required or provided competency.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.22.3 Description

  • Key: UPDM-262
  • Legacy Issue Number: 11901
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    A general stereotype that can be applied to any element in a model that applies the profile."

    The description is not sufficient

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Stereotype for realization CommunicationsPathRealizesSystemInterface

  • Key: UPDM-252
  • Legacy Issue Number: 11804
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Stereotype for realization CommunicationsPathRealizesSystemInterface is too long

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Stereotype for realization RealizedOperationalCapability is too long

  • Key: UPDM-251
  • Legacy Issue Number: 11803
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Stereotype for realization RealizedOperationalCapability is too long

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Stereotype for interface realization RealizedSystemSpecification

  • Key: UPDM-254
  • Legacy Issue Number: 11806
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Stereotype for interface realization RealizedSystemSpecification is too long

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Stereotype for interface realization RealizedOperationalSpecification

  • Key: UPDM-253
  • Legacy Issue Number: 11805
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Stereotype for interface realization RealizedOperationalSpecification is too long

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.10.3 Description

  • Key: UPDM-257
  • Legacy Issue Number: 11896
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    ConformingElement provides a link from profile elements to specific standards in the context of a forecast."

    Conforming element has no connection with Forecast.

  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name ResourceCapability is not intuitive

  • Key: UPDM-244
  • Legacy Issue Number: 11796
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name ResourceCapability is not intuitive. Semantic meaning of the relation should be implied

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name ResourceCompetence is not intuitive

  • Key: UPDM-246
  • Legacy Issue Number: 11798
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name ResourceCompetence is not intuitive. It is not clear if it is provided Competence or required

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name ResourceCapabilityConfiguration

  • Key: UPDM-245
  • Legacy Issue Number: 11797
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name ResourceCapabilityConfiguration is not intuitive. Semantic meaning of the relation should be implied

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name SystemsNodeElements

  • Key: UPDM-248
  • Legacy Issue Number: 11800
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name SystemsNodeElements is plural and not intuitive. Should be something like "hostedOn"

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name SystemGroupMember is not intuitive

  • Key: UPDM-247
  • Legacy Issue Number: 11799
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name SystemGroupMember is not intuitive. Should be something like "groupedBy"

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Stereotype for dependency AssetMapping is not intuitive

  • Key: UPDM-250
  • Legacy Issue Number: 11802
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Stereotype for dependency AssetMapping is not intuitive. Semantic meaning of the relation should be implied

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Stereotype for dependency CompetenceRelationship is not intuitive

  • Key: UPDM-249
  • Legacy Issue Number: 11801
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Stereotype for dependency CompetenceRelationship is not intuitive. Semantic meaning of the relation should be implied

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name OrganizationalResourceCapabilityConfiguratio

  • Key: UPDM-243
  • Legacy Issue Number: 11795
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name OrganizationalResourceCapabilityConfiguration is not intuitive. Semantic meaning of the relation should be implied

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name OperationalNodeCapabilityRequirement

  • Key: UPDM-242
  • Legacy Issue Number: 11794
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name OperationalNodeCapabilityRequirement is not intuitive. Semantic meaning of the relation should be implied

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name OperationalCapabilityRoleResource

  • Key: UPDM-241
  • Legacy Issue Number: 11793
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name OperationalCapabilityRoleResource is not intuitive. Semantic meaning of the relation should be implied

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name ForecastStandardsProfile

  • Key: UPDM-234
  • Legacy Issue Number: 11786
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name ForecastStandardsProfile is not intuitive. Semantic meaning of the relation should be implied

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name EffectAffectsNode is not nice

  • Key: UPDM-233
  • Legacy Issue Number: 11785
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name EffectAffectsNode is not nice. Should be simplified to "affects"

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name NodeCausesEffect is not nice

  • Key: UPDM-238
  • Legacy Issue Number: 11790
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name NodeCausesEffect is not nice. Should be simplified to "affects

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name MilestonePoint is not intuitive

  • Key: UPDM-237
  • Legacy Issue Number: 11789
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name MilestonePoint is not intuitive. Semantic meaning of the relation should be implied

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name OperationalCapabilityRoleCompetence

  • Key: UPDM-240
  • Legacy Issue Number: 11792
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name OperationalCapabilityRoleCompetence is not intuitive. Semantic meaning of the relation should be implied.

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name OperationalCapabilityEffect

  • Key: UPDM-239
  • Legacy Issue Number: 11791
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name OperationalCapabilityEffect is not intuitive. Semantic meaning of the relation should be implied

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name MaterielBehavior is not intuitive

  • Key: UPDM-236
  • Legacy Issue Number: 11788
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name MaterielBehavior is not intuitive. Semantic meaning of the relation should be implied

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name MaterielNode is not intuitive

  • Key: UPDM-235
  • Legacy Issue Number: 11787
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name MaterielNode is not intuitive. Semantic meaning of the relation should be implied

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.11:Doctrine

  • Key: UPDM-225
  • Legacy Issue Number: 11756
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    Diagram should show an association to Operation instead of OpertionalTask and SystemTask. It should be named "tasks". The association has to be unidirectional with a multiplicity of zero or more.

    8.3.11.6 Constraints
    [1] Asserts that there are SystemTasks or OperationalTasks governed by this Doctrine self.tasks-> forAll(getAppliedStereotype('UPDM::OperationalTask')>notEmpty() or getAppliedStereotype('UPDM::SystemTask')>notEmpty())
    [1] Asserts that there are zero or more SystemTasks or OperationalTasks governed by this Doctrine
    self.tasks->notEmpty() implies
    self.tasks-> forAll(getAppliedStereotype('UPDM::OperationalTask')
    ->notEmpty() or
    getAppliedStereotype('UPDM::SystemTask')->notEmpty())

    [3] Asserts that this Doctrine governs zero or more CapabilityConfigurations self.capabilityConfigurations-> forAll(getAppliedStereotype ('UPDM::CapabilityConfiguration')->notEmpty())

    [3] Asserts that this Doctrine governs zero or more CapabilityConfigurations
    self.capabilityConfigurations->notEmpty() implies
    self.capabilityConfigurations-> forAll(getAppliedStereotype ('UPDM::CapabilityConfiguration')->notEmpty())

  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.32:OrganizationalResource

  • Key: UPDM-224
  • Legacy Issue Number: 11755
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    8.4.32.6 OrganizationalResource Constraints
    Project has zero or more - not 1 or more.
    [1] Asserts that there is at least one Project owned by this OrganizationalResource. self.projects.getAppliedStereotype('UPDM::Project')->notEmpty()

    [1] Asserts that there is zero or more Projects owned by this OrganizationalResource.
    Self.projects -> notEmpty() implies
    self.projects.getAppliedStereotype('UPDM::Project')->notEmpty()

    [3] Asserts that there is an association between the OperationalNode and a SystemsNode that houses the OperationalNodes. self.getAllAttributes()>asOrderedSet()>select(association- >notEmpty()).association->any (getAppliedStereotype('UPDM::SystemsNodeElements')> notEmpty())>notEmpty()

    [3] Asserts that there is an association between the OrganizationalResource and a SystemsNode that requires this resource.
    self.getAllAttributes()>asOrderedSet()>select(association- >notEmpty()).association->any (getAppliedStereotype('UPDM::SystemsNodeElements')> notEmpty())>notEmpty()

    [3] should be deleted, this association is not a required resource.

    8.4.32.7 OrganizationalResource Semantics
    Use the DeployedToSystemsNode SystemsNodeElements association to indicate deployment of OrganizationalResource to a SystemsNode.
    Use the OperationalCapabilityRoleResource association to indicate an OrganizationalRole played by the OrganizationalResource.
    Use the OrganizationalResourceCapabilityConfiguration association to indicate inclusion in a CapabilityConfiguration
    Use the DeployedToSystemsNode association to indicate deployment of OrganizationalResource to a SystemsNode.
    Use the DeployedToSystemsNode association to indicate deployment of OrganizationalResource to a SystemsNode.

  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.8:Concern

  • Key: UPDM-223
  • Legacy Issue Number: 11754
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    [1] Asserts that this Concern links an ArchitecureView to a set of Stakeholders self.architectureView.getAppliedSubstereotypes(self.getApplicableStereotypes()- >any(qualifiedName='UPDM::ArchitectureView'))->notEmpty()

    [1] Asserts that this Concern links an ArchitecureView or one of its specializations to a set of Stakeholders self.architectureView-> forAll(getAppliedStereotype('UPDM::ArchitectureView')- >notEmpty())
    or self.architectureView->forAll(getAppliedStereotypes()> collect(allParents())>any(qualifiedName = 'UPDM::ArchitectureView') -> notEmpty() )

    [2] Asserts that there are zero or more Stakeholders who have this Concern
    self.stakeholders-> forAll(getAppliedStereotype('UPDM::Stakeholder')->notEmpty())

    [2] Asserts that there are zero or more Stakeholders who have this Concern
    self.subject->

  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.19:Stakeholder

  • Key: UPDM-222
  • Legacy Issue Number: 11753
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    8.3.19.3 Stakeholder Description
    Fix diagram - remove association between concern and Stakeholder. This is handled by the subject/usecase association.
    Change StakeholderConcern to dependency notation
    8.3.19.3 Stakeholder Associations
    delete concern[]
    8.3.19.6 Stakeholder Constraints

    [1] Asserts that there is at least one ArchitectureView associated with this Stakeholder self.architectureView-> forAll(getAppliedStereotype('UPDM::ArchitectureView')- >notEmpty())

    [1] Asserts that there is at least one ArchitectureView associated with this Stakeholder self.architectureView-> forAll(getAppliedStereotype('UPDM::ArchitectureView')- >notEmpty())
    or self.architectureView->forAll(getAppliedStereotypes()> collect(allParents())>any(qualifiedName = 'UPDM::ArchitectureView') -> notEmpty() )

  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.13.5:OperationalActivity Associations

  • Key: UPDM-217
  • Legacy Issue Number: 11748
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    materiel is listed as an Association, but the diagram does not indicate the association.
    There isn't an association between OperationalActivity and Materiel, but there is a stereotypedAssociation, MaterielBehavior that is bidirectional, so there should be a dependency in the diagram as proposed for the solution for showing stereotyped associations

  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.13.6:OperationalActivity Constratins

  • Key: UPDM-216
  • Legacy Issue Number: 11747
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    :[2] Asserts that for every callOperationAction in an OperationalActivity that refers to an Operation that is stereotyped OperationalTask, then:
    if the OperationalTask that is the operation of a callOperationAction that resides in a partition that represents an OperationalNode or a Property that is typed by an OperationalNode or one of its specializations, then o
    the OperationalTask must be owned by that OperationalNode and the OperationalTask must have at least one method that specifies a corresponding OperationalActivity owned by the OperationalNode, (an OperationalTask could also specify Interactions or StateTraces)
    OR o
    if the OperationalTask that is the operation of a callOperationAction that resides in a partition that represents an OperationalNodeSpecification or a Property that is typed by an OperationalNodeSpecification, then o
    the OperationalNodeSpecification must own the OperationalTask.

    This constraint forces the called operation to be owned by the OperationalActivity that represents the partition in which the callOperationResides and that is not generally the case.
    Resolution:Fix the OCL.

  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.2.11:Project Type

  • Key: UPDM-221
  • Legacy Issue Number: 11752
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    This stereotype doesn't have much use as is. Either delete it, or make it more meaningful

  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.2.10:Project -- 8.2.10.6 Constraints

  • Key: UPDM-220
  • Legacy Issue Number: 11751
  • Status: open  
  • Source: International Business Machines ( Fred Mervine)
  • Summary:

    [1] Asserts that there is one OrganizationalResource required for this Project

    [1] Asserts that there is one or more OrganizationalResources that own this Project
    Fix diagram to show 1 or more

    [2] Asserts that zero or more Milestones govern this Project through an DOLDElement self.getAllAttributes()>asOrderedSet()> select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::MilestonePoint')> notEmpty())>notEmpty()

    [2] Asserts that one or more Milestones govern this Project
    self.getAllAttributes()>asOrderedSet()> select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::MilestonePoint')> notEmpty())>notEmpty()

  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Reusable libraries cannot be created on order to model a SV-9.

  • Key: UPDM-229
  • Legacy Issue Number: 11760
  • Status: open  
  • Source: Dassault Systemes ( Andrius Strazdauskas)
  • Summary:

    Technology does not exist in UPDM, so reusable libraries cannot be created on order to model a SV-9.

  • Reported: <