Unified Profile for DoDAF and MODAF Avatar
  1. OMG Specification

Unified Profile for DoDAF and MODAF — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
UPDMRTF-146 capability element should have a relation to sysml requirement type. UPDM 2.1.1 open
UPDMRTF-42 Withdraw UDPM Spec UPDM 2.1 open
UPDMRTF-40 Figure 8.1 Presents InformationAssuranceProperties Twice UPDM 2.1 open
UPDMRTF-39 UPDM Users want to model Test Contexts and Test Cases within UPDM UPDM 2.1 open
UPDMRTF-36 DoDAF elements need to be identified and added to the various diagrams that represent the views UPDM 2.1 open
UPDMRTF-38 AV-2 Definitions need Authoritative Source property and Tooling to enforce its Use UPDM 2.1 open
UPDMRTF-37 Profile and Tooling should enforce the Proper Specification of Capabilities UPDM 2.1 open
UPDMRTF-35 modify the term NodeRole so that is more applicable to a Peformer UPDM 2.1 open
UPDMRTF-34 Need to change target of desiredEffect from a state to a new element called effect UPDM 2.1 open
UPDMRTF-33 Why does a user need to build an SOV-3? UPDM 2.1 open
UPDMRTF-32 Why are rules in OV-6a and SV-10a not parsed? UPDM 2.1 open
UPDMRTF-29 Information flow instantiation UPDM 2.1 open
UPDMRTF-31 For UAFP. Include a Data and Information view (DIV) UPDM 2.1 open
UPDMRTF-30 There needs to be a distinction between Operational View IEs and Systems View Exchange elements UPDM 2.1 open
UPDMRTF-28 Introduce roles in SV-1 and allow them to relate back to OV-4 organizations that will provide them UPDM 2.1 open
UPDMRTF-27 Why is EnterprisePhase to EnterpriseVision a one to one relationship UPDM 2.1 open
UPDMRTF-26 Need of Composition between Enterprise Goals UPDM 2.1 open
UPDMRTF-25 Subject of a State Machine UPDM 2.1 open
UPDMRTF-24 CV6, CV-7 and NSOV-3 UPDM 2.1 open
UPDMRTF-23 Use of Actual vs. Type in PV-1 UPDM 2.1 open
UPDMRTF-22 use of Generalization to implement Aliasing UPDM 2.1 open
UPDMRTF-21 MapsToCapability relationship is too Restrictive, and ActivityPartOfCapability is redundant UPDM 2.1 open
UPDMRTF-9 PV1 (DoDAF) Attributes Needed UPDM 2.0.1 open
UPDMRTF-20 The <> stereotype and its properties UPDM 2.1 open
UPDMRTF-19 ProjectSequence is too Restrictive UPDM 2.1 open
UPDMRTF-18 System and PhysicalArchitecture are siblings not descendants UPDM 2.1 open
UPDMRTF-17 Integrate SysML Requirements and Constraints UPDM 2.1 open
UPDMRTF-16 UPDM DoDAF lacks a concept for Service Orchestration UPDM 2.1 open
UPDMRTF-15 Future Increments of UPDM should not preclude using SBVR for Modeling Vocabularies and Rules UPDM 2.1 open
UPDMRTF-13 Need of Logical and Physical Services UPDM 2.1 open
UPDMRTF-12 PIM Logical Service Specification UPDM 2.1 open
UPDMRTF-11 Simplify measurements in UPDM UPDM 2.1 open
UPDMRTF-10 Expand general activity modeling for all UPDM constructs to include representation by action, callBehaviorAction and UPDM 2.1 open
UPDMRTF-14 Implements Relationship between Exchange Elements UPDM 2.1 open
UPDMRTF-8 Views should be Normative UPDM 2.0 open
UPDMRTF-7 The Model library in the UPDM profile should be external to the UPDM profile UPDM 2.1 open
UPDMRTF-6 Desired Effect needs to be a strategic-level model able element UPDM 2.1 open
UPDMRTF-5 Use of superSubType, wholePart and WholePartType in DoDAF 2 UPDM 2.1 open
UPDMRTF-4 Mapping to DM2 higher level elements: UPDM 2.1 open
UPDMRTF-3 Need for ServiceInterfaces to be represented as an instance to capture specific ServiceAttributes UPDM 2.1 open
UPDMRTF-2 Figure 7.8: <> should be changed to <> UPDM 2.0 open
UPDMRTF-1 Specification lacks Hyperlinks for references to Model Element Names UPDM 2.1 open
UPDMRTF-68 explain the relevance of this standard to IT and SE in general UPDM 2.1 open
UPDMRTF-67 lacking clause and number heading UPDM 2.1 open
UPDMRTF-66 unify representation style for inheritance UPDM 2.1 open
UPDMRTF-44 UPDM v2.1 is specific to DoD and MOD procedures. UPDM 2.1 open
UPDMRTF-63 pacakge partitioning not clear UPDM 2.1 open
UPDMRTF-65 missing description for associations UPDM 2.1 open
UPDMRTF-64 missing class definitions UPDM 2.1 open
UPDMRTF-61 odd reference to UPDM RFC UPDM 2.1 open
UPDMRTF-60 Some of text should be merged into the scope Clause 1. UPDM 2.1 open
UPDMRTF-62 DMM is non-normative but appears to be nomative UPDM 2.1 open
UPDMRTF-59 DOTMLP should be DOTMLPF. UPDM 2.1 open
UPDMRTF-58 It is much to easy to rely on reference documents UPDM 2.1 open
UPDMRTF-57 Confusing conformance/compliance statements re DoDAF 2.o2 UPDM 2.1 open
UPDMRTF-56 Don’t separate the “Normative Reference” clause. UPDM 2.1 open
UPDMRTF-55 Existing ISO standards should be mentioned. UPDM 2.1 open
UPDMRTF-54 IS0, TC154 should be ISO/TC154. UPDM 2.1 open
UPDMRTF-53 The format of normative references don't meet ISO format UPDM 2.1 open
UPDMRTF-52 modify reference to UML 2.3 to UML 2.4.1 UPDM 2.1 open
UPDMRTF-51 The last bullet point is broken. UPDM 2.1 open
UPDMRTF-47 Notation on Diagram 2.1 not clear UPDM 2.1 open
UPDMRTF-50 Figure is a little grainy. UPDM 2.1 open
UPDMRTF-49 The first sentence may invite misunderstand that “UPDM 2.1” and this standard are different. UPDM 2.1 open
UPDMRTF-48 The scope of this standard focused too much on the use of DoD and MOD area. UPDM 2.1 open
UPDMRTF-46 missing definition for NAF in glossary of terms UPDM 2.1 open
UPDMRTF-45 Objection to scope of UPDM fro ISO UPDM 2.1 open
UPDMRTF-43 Figure number is incorrect in Subpart 1. UPDM 2.1 open
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
UPDM2-1 Update Annex C for DoDAF 2.02 UPDM 1.0 open
UPDM-1 UPDM -- title UPDM 1.0 open
UPDM-10 Section: 10.4.6 UPDM 1.0 open
UPDM-9 Section: 10.4.5.3 UPDM 1.0 open
UPDM-4 Section: 8.5.3 Add stereotyped association between Milestone and Capability UPDM 1.0 open
UPDM-3 Page: Page 3 (PDF page 17) UPDM 1.0 open
UPDM-7 Refine the L1 compliance example in Section 10 UPDM 1.0 open
UPDM-6 UPDM compliance level 1 UPDM 1.0 open
UPDM-12 Section: B.4.19 OperationalServiceProvider UPDM 1.0 open
UPDM-11 Section: B.4.19 OperationalServiceConsumer UPDM 1.0 open
UPDM-5 What UPDM elements/constructs relate to the DLOD elements UPDM 1.0 open
UPDM-8 Section: 8.4.25.3 UPDM 1.0 open
UPDM-2 Section 8.4.13 UPDM 1.0 open

Issues Descriptions

capability element should have a relation to sysml requirement type.

  • Status: open   Implementation work Blocked
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    we need to be able to add requirements in UPDM, define test cases and use requirement relations (refine, verify). by adding stereotype <<requirement>> to current class-type capability, we can do all of the above. or at least add in profile a defined relation to relate requirements to capabilities.

  • Reported: UPDM 2.1.1 — Fri, 4 Dec 2020 16:19 GMT
  • Updated: Mon, 28 Dec 2020 17:05 GMT

Withdraw UDPM Spec

  • Key: UPDMRTF-42
  • Status: open  
  • Source: Aerospace Corporation ( John Reeves)
  • Summary:

    There is no support for the specification. The DoD CIO is not updating or supporting DoDAF documentation. The IDEAS group is defunct. No one is maintaining DM2. The website udpmgroup.org is for sale. See http://www.omg.org/syseng/UPDM.htm. The specification appears to be generated from a model, and is way below the quality standards for other OMG specifications.

  • Reported: UPDM 2.1 — Wed, 24 Aug 2016 22:34 GMT
  • Updated: Tue, 4 Jul 2017 13:09 GMT

Figure 8.1 Presents InformationAssuranceProperties Twice

  • Key: UPDMRTF-40
  • Status: open  
  • Source: InterCAX ( Lonnie VanZandt)
  • Summary:

    Figure 8.1 on page 23 has two symbols for the same element: InformationAssuranceProperties appear twice on the diagram.

    One instance of the symbol would suffice.

  • Reported: UPDM 2.1 — Tue, 21 Jan 2014 03:58 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT
  • Attachments:

UPDM Users want to model Test Contexts and Test Cases within UPDM

  • Key: UPDMRTF-39
  • Status: open  
  • Source: InterCAX ( Lonnie VanZandt)
  • Summary:

    One or more clients of No Magic Professional Services seek to be able to model the systems, services, test case behaviors, test data, and so forth of the verification and validation of their UPDM-specified Systems and Services.

    These clients are already using SysML within UPDM for their Requirements engineering and for their Systems Viewpoint modeling.

    SysML delegates Verification concerns to the UML Testing Profile via SysML's <<verify>> Relationship between Requirements and Test Case activities.

    These clients of No Magic ask that No Magic champion the integration of the UML Testing Profile-or any other standardized set of concepts-into UPDM.

  • Reported: UPDM 2.1 — Fri, 20 Dec 2013 19:36 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

DoDAF elements need to be identified and added to the various diagrams that represent the views

  • Key: UPDMRTF-36
  • Legacy Issue Number: 18958
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    This issue relates to the readability of the specification on the various "view diagrams", DoDAF elements are left of off these diagrams it becomes hard to recognise which diagrams use specific DODAF elements, it is only through understanding what things have DoDAF aliases that you can see what needs to be added to the correct diagram.

    These elements need to be added to the diagrams that they can participate in by showing the MODAF elements that they alias/inherit properties from.

  • Reported: UPDM 2.1 — Thu, 26 Sep 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

AV-2 Definitions need Authoritative Source property and Tooling to enforce its Use

  • Key: UPDMRTF-38
  • Status: open  
  • Source: InterCAX ( Lonnie VanZandt)
  • Summary:

    A tool that is DoDAF conformant should encourage the user to fill in the Authoritative Source field whenever they define a new architecture element (AV-2). The Authoritative Source should provide specific locator for the source of the term and definition. Multiple AS may be occur.

    Rationale from Dave McDaniels:

    Almost every JIE architecture gets a comment from JS J6 that the AV-2 is missing the Authoritative Source for the term and definition which they say is a DoDAF conformance requirement. The problem they’re really getting at is the proliferation of inconsistent AV-2 terms even in a single project like JIE, even worse across all the mission areas. The number of AV-2 terms in the WMA repository is in the tens of thousands if not more by now. Mapping, reconciling, adjudicating, etc. is impractical. Their approach is to encourage reuse of terms to encourage standardization, e.g., the Joint Common System Functions List (JCSFL), JCAs, UJTLs, … Everyone agrees but the AV-2 Authoritative Source fields remain blank – once the toothpaste is out the tube, very hard to get back in.

  • Reported: UPDM 2.1 — Sat, 14 Dec 2013 22:37 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Profile and Tooling should enforce the Proper Specification of Capabilities

  • Key: UPDMRTF-37
  • Status: open  
  • Source: InterCAX ( Lonnie VanZandt)
  • Summary:

    It would help if the tools flagged or restricted Capability definition to encourage the definition of:

    • Effects and metrics
    • Activities involved
    • Conditions under which conducted
    • Performer (optional – often not known during pre-MS A)
    • Desirer of the Effect (optional)

    Rationale from Dave McDaniels:

    Capabilities vs Activities. As you know, the DM2 Capability model is built about the JCIDS definition and centers around effects (resource states) that are measureable (have metrics so you can tell if they've happened) and is produced by ways (Activities) and means (Performers) under specified Conditions (i.e., PMESII, DIME). Thus they are quite a bit different from Activities which transform inputs to outputs or change their state. Many comments are being generated and much argument and rework because many CV's are missing pieces or are clearly Activities being described, not Capabilities. For example, I just turned in a comment on the IdAM RA on their CV in which they defined the Capabilities in terms of their Inputs, Controls, Outputs, and Mechanisms – ICOM – the exact prescription for Activities in IDEF0.

    Note that a PES file that did not have the required pieces and that claimed to contain CV information would fail validation. Also note the DoDAF-DM2 formulation of CV's fits the JCIDS-DAS-SE processes by linking ICD threshold and objective attributes and CDD/CPD KPP/KSA/OSA to the CV's and to the T&E process by aligning the architecture and JCIDS documents to test metrics. This method was also designed to allow flow down of operational metrics (MOEs) to SV/SvcV (e.g., SV-7) metrics (MOPs). It also aligns with training since UJTL tasks have measure types (several defined per task), UJTLs map to JCAs, and JCAs are the organizing construct for ICD attributes and are also required in CDD/CPD. There are probably many other elements of architecture and systems engineering that align by defining Capabilities the way we did in DoDAF. DoD CIO A&I and Joint Staff J6 are in very close agreement on all this.

  • Reported: UPDM 2.1 — Sat, 14 Dec 2013 20:50 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

modify the term NodeRole so that is more applicable to a Peformer

  • Key: UPDMRTF-35
  • Legacy Issue Number: 18957
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The term NodeRole is more applicable to MODAF than DoDAF and does not derive from Performer, Ron Williamson sugested PerformerRole.
    There are other terms that could be affected in the this way like NodeOperation.

    Even though I understand the need, I am against creating more Stereotypes that are Aliases for DODAF. It becomes harder to maintain and more problematic for implement. I would suggest that we rationalise the name of the stereotype for instances of Nodes/Performers to be aligned with both MODAF and DoDAF, i.e. OperationalNode.

  • Reported: UPDM 2.1 — Thu, 26 Sep 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Need to change target of desiredEffect from a state to a new element called effect

  • Key: UPDMRTF-34
  • Legacy Issue Number: 18956
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Desired affect targets "state" in UPDM 2.1, states must have a context and this causes the architects to think too low down in the model (at the OV and SV level) where implementation exists. Desired affect needs to be tied to something in the CV/Stv that is not a "state", called Effect in the CV/StV.

  • Reported: UPDM 2.1 — Thu, 26 Sep 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Why does a user need to build an SOV-3?

  • Key: UPDMRTF-33
  • Legacy Issue Number: 18845
  • Status: open  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    Why does a user need to build an SOV-3? The relationship from services to capabilities should be transitive. Once a user establishes traceability from operational activity to capability and from ServiceFunction to Operational Activity, then there is already a trace from owning service (service that owns that ServiceFunction) to a capability and SOV should b au-populated. Further, a service(Interface) should map to a node and not to an OperationalActivity or to SystemFunction. This change is to be discussed with respective requirements representatives.

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Why are rules in OV-6a and SV-10a not parsed?

  • Key: UPDMRTF-32
  • Legacy Issue Number: 18844
  • Status: open  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    Why are rules in OV-6a and SV-10a not parsed? They need to be specified as OCL constraints. Similarly for SOVs, use OCL to define performance level supported by each provider to each type of consumer as in a Service Level Agreement (SLA).

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Information flow instantiation

  • Key: UPDMRTF-29
  • Legacy Issue Number: 18841
  • Status: open  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    Information flow instantiation. There is no UML construct to define flow and then to instantiate flows to use flow types and then flow instances that flow between two instances of two things.
    Discussed Resolution: See simple exchange example in MODEM

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

For UAFP. Include a Data and Information view (DIV)

  • Key: UPDMRTF-31
  • Legacy Issue Number: 18843
  • Status: open  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    For UAFP. Include a Data and Information view (DIV). This view is to be used for domains where a DB is needed. Remove DIV-3/ SV-11 physical schema as a supported model/Diagram type. Make it an external reference only, either a physical schema in another tool, or an XML flat file etc. Change DIV-1 and DIV-2 to be defined/associated with Systems View elements only, since you only specify data conceptual and logical models at the solution level. In SV, the InformationElement will be a NonHumanResourceType that is associated with entities defined in DIV-1 and DIV-2, since only information can be stored in a database

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

There needs to be a distinction between Operational View IEs and Systems View Exchange elements

  • Key: UPDMRTF-30
  • Legacy Issue Number: 18842
  • Status: open  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    Information Exchange (IEs) item or element: Currently all IEs are defined as elements of package AllView. This should not be the case. There needs to be a distinction between Operational View IEs and Systems View Exchange elements.
    Discussed Resolution: Currently in MODEM, only InformationElement flows are allowed in OVs (see below). MODEM will use FlowedElement instead. Will consider changing its current type from abstract to make it a typed generic flow defined in OVs. An abstract ResourceType is defined for SVs. It will have as subtypes: human, non-human etc. as shown below. In addition, subtype InformationElement will be moved from current location to be a NonHumanResourceType defined in SVs. Allow any of the SV ResourceType leaf level elements (e.g. NaturalResourceType) to trace back to OV flows.

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Introduce roles in SV-1 and allow them to relate back to OV-4 organizations that will provide them

  • Key: UPDMRTF-28
  • Legacy Issue Number: 18840
  • Status: open  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    Typical and actual posts, etc. should be introduced and defined in SV-1 as they are the human equivalent of systems, capability configurations, etc. It is in SV that we provide a PSM/white box/logical design model where we introduce elements (human as well as materiel) that are to be allocated to the problem domain described in OV.
    Resolution discussed: introduce roles in SV-1 and allow them to relate back to OV-4 organizations that will provide them. Checked this in MODEM. Below is how it is currently defined.

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Why is EnterprisePhase to EnterpriseVision a one to one relationship

  • Key: UPDMRTF-27
  • Legacy Issue Number: 18839
  • Status: open  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    Why is EnterprisePhase to EnterpriseVision a one to one relationship? Composition relationship is also not needed.
    Discussed resolution:
    • change relationship to: one to many on EnterprisePhase end and 0..1 on EnterpriseVision end.
    • delete composition relationship

  • Reported: UPDM 2.1 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Need of Composition between Enterprise Goals

  • Key: UPDMRTF-26
  • Legacy Issue Number: 18785
  • Status: open  
  • Source: Dassault Systemes ( Aurelijus Morkevicius)
  • Summary:

    Please enter this issue against UPDM RTF 2.2.

    In UPDM 2.1 we are missing capability to decompose Enterprise Goals, e.g. goal, objective pattern supported by BMM. This capability is already available in MODAF 1.3 witch UPDM claims to support.

  • Reported: UPDM 2.1 — Thu, 20 Jun 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Subject of a State Machine

  • Key: UPDMRTF-25
  • Legacy Issue Number: 18742
  • Status: open  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    Issue State machine issue: UML states the subject of a state machine can be behavior or structural: “The StateMachines package defines a set of concepts that can be used for modeling discrete event-driven Behaviors using a finite state-machine formalism. In addition to expressing the Behavior of parts of a system …, state machines can also be used to express the valid interaction sequences, called protocols, for parts of a system. These two kinds of StateMachines are referred to as behavior state machines and protocol state machines respectively.”
    MODAF specifies both node and activity, DODAF says activity only:
    Short Name DODAF DODAF MODAF/NAF MODAF/NAF
    OV-6b OV-6b State Transition Description DoDAF: The Operational State Transition Description (OV-6b) DoDAF-described View is a graphical method of describing how an Operational Activity responds to various events by changing its state. The diagram represents the sets of events to which the Architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action. OV-6b Operational State Transition Description MODAF: OV-6b: The Operational State Transition Description is a graphical method of describing how an Operational Node or activity responds to various events by changing its state. The diagram represents the sets of events to which the Architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action.
    UPDM states node only?

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

CV6, CV-7 and NSOV-3

  • Key: UPDMRTF-24
  • Legacy Issue Number: 18741
  • Status: open  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    In UPDM it seems that the Service to OperationalActivity matrix is non-editable. The relations are established after one creates capability to OpAct relations and capability to service relations (in CV-6 and CV-7/NSOV-3 respectively). This may be how it is explained in DODAF/ MODAF? (no direct relation between ServiceInterface and OperationalActivity:

    But it is not how it should be. Here is why: CV-7 is useful when considering how services that may already be available (internally to subject architecture scope, or provided by third party entities) can be leveraged to enable the required capabilities. However, a true model-based approach to capability development and analysis will include an operational view model that further delineates the capability (stated as a term and a definition) and describes the ways and means needed or provided to enable the capability. Such an analysis usually uncovers issues with the defined capability taxonomy such as overlapping or non-mutually exclusive capabilities, and will lead to a better formulation of the capability taxonomy. The operational model is also used as a guide to develop or identify needed services in a service model. Thus, it is good SE discipline not to try and develop CV-7 starting with two sets of taxonomies, one for capabilities and another for services, without conducting the necessary modelling of operational and service artifacts needed, conducting the analysis, and “discovering” the relationships between capabilities and the services needed to enable them. So I propose that the order is like this:
    1. develop a Capability taxonomy (CV-2);
    2. develop Operational views (especially the behavior diagrams)
    3. iterate on capability taxonomy and op behavior until one is somewhat satisfied that the capability taxonomy and operational elements (as modeled) are consistent and capabilities are well delineated. At this time a CV-6, (Capabilities x Operational Activities) matrix may be generated;
    4. develop a service view model that supports the operational model and evaluate the ability of the enterprise to offer each Capability and make a Build versus Buy/Outsource decision. Some more iterations on elements in CV, OV, and SOV may take place again, especially as the services taxonomy and service orchestration diagrams are developed. That is, the service model may cause Operational Activities as well as capability taxonomy to change again. Once things stabilize, an SvcV-5/NSOV-3 (Services x Operational Activities) matrix may be generated;
    a. For those Capabilities that will continue to use existing systems within the Enterprise, model their As-Is Systems Views;
    b. For those that are to be Built, or are to be Bought, model the the Services Views to identify (conduct an analysis on what is available within and outside enterprise), and identify the contractual Service-Level Agreements and indicate the Service orchestration with the Enterprise's Performers.
    i. For services to be built, proceed to detail in systems view
    ii. For services to be outsourced stop detail here (services view) but show they are used in systems view (via service request interfaces for system components.
    5. when one feels that the operational and services models satisfy the updated capability taxonomy, one can generate (from the relationships already established), the Capabilities x Services (CV-7) matrix
    6. Develop Systems Views and then map (system) Functions to Services and Functions to Operational Activities.

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Use of Actual vs. Type in PV-1

  • Key: UPDMRTF-23
  • Legacy Issue Number: 18740
  • Status: open  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    Currently, one has to use ActualProject and ActualOrganization to get an organizational to project mapping. Why not organization and project types? Understand this theoretically, (only a “real” organization can undertake a “real” project), however what if the architecture description itself was all a pattern? I should be able to associate classes of organizations (a type) with classes of projects.

    Profile:

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

use of Generalization to implement Aliasing

  • Key: UPDMRTF-22
  • Legacy Issue Number: 18739
  • Status: open  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    Issue 18739:
    Name: Fatma Dandashi
    Employer: Mitre Corp.
    mailFrom: dandashi@mitre.org
    Terms_Agreement: I agree
    Specification: UPDM Profile
    Section:
    FormalNumber: dtc/12-12-17
    Version: 2.1
    Doc_Year: 2012
    Doc_Month: December
    Doc_Day: 17
    Page: 218
    Title: use of Generalization to implement Aliasing
    Nature: Enhancement
    Severity: Significant
    CODE:
    B1: Report Issue
    Remote Name:
    Remote User:
    Time:

    Description:
    DMM defines system as a DoDAF-only alias for ResourceArtifact:

    Profile then defines the following: (this is probably true for all elements that are aliases).

    Using generalization in this manner means that vendor implementations allow one to use both System as well as ResourceArtifact in the same model, regardless if one is using DoDAF or MODAF. System is an alias for MODAF’s ResourceArtifact in DODAF only. That is, System should not be available as a choice in MODAF/NAF. More importantly: generalization is really not the best UML construct to implement aliasing. If you choose System in NAF, you will not be able to use composition and aggregation relationships on SV-1. One should be able to use System in exactly the same manner as a ResourceArtifact, especially the a

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

MapsToCapability relationship is too Restrictive, and ActivityPartOfCapability is redundant

  • Key: UPDMRTF-21
  • Legacy Issue Number: 18738
  • Status: open  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    There is a constraint stated in Figure A.30 of the dtc/12-12-17 specification such that in MODAF (and therefore NAF), the MapsToCapability relationship is precluded from using OperationalActivities and is prescribed to only use StandardOperationalActivities.
    This has resulted in defining another relationship in the spec called ActivityPartOfCapability for DODAF, that creeps into MODAF and NAF in vendor implementations, to allow one to associate an activity with a capability for the purposes of generating traceability diagrams and for generating NPV-2: Program to Capability Mapping (through Activity is part of project, and Activity is part of Capability). There is no need for both and it is redundant and a possible source of model inconsistencies to request the architect to define both MapsToCapability and another called ActivityPartOfCapability. Further, the MODAF constraint to use only StandardOperationalActivities when mapping to capabilities for the purposes of (MODAF policy?) can be accommodated in another manner.

  • Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

PV1 (DoDAF) Attributes Needed

  • Key: UPDMRTF-9
  • Legacy Issue Number: 18509
  • Status: open  
  • Source: omg.org ( OMG System User)
  • Summary:

    In the current DoDAF Project Viewpoints (PV1) the project element has a start date and an end date. Those attributes are not sufficient for the US JCIDS process. In the incremental development process described by JCIDS, we have increments, blocks and spirals. In the main we don't measure our programs in absolute start and stop dates but rather where they fall in the relative JCIDS process, priority and lifecycle. Start dates are usefull but with a 20-30 year lifecylce, the stop date is not as useful. Having these attributes (increment:string, block: int and spiral:int) in the Project Element would allow us to trace requirements and capability sets to the proper increment, block or spiral.

  • Reported: UPDM 2.0.1 — Wed, 27 Feb 2013 05:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

The <> stereotype and its properties

  • Key: UPDMRTF-20
  • Legacy Issue Number: 18725
  • Status: open  
  • Source: PTC ( Simon Moore)
  • Summary:

    UPDM includes a <<Property>> stereotype with properties maxValue, minValue and defaultValue. <<CapabilityProperty>> specializes the Property stereotype and extends the Property metatype.

    1. could you rename the Property stereotype to avoid confusion with the UML metatype of the same name?

    2. since the UML metatype Property already has a defaultValue, could the UPDM one be removed?

    3. the min/max/defaultValue properties have no multiplicity specified in the spec or XMI, so it defaults to 1. If these were intended to be optional they should be specified as [0..1]

    These impact XMI (see MIWG TC22).

  • Reported: UPDM 2.1 — Mon, 20 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

ProjectSequence is too Restrictive

  • Key: UPDMRTF-19
  • Legacy Issue Number: 18718
  • Status: open  
  • Source: InterCAX ( Lonnie VanZandt)
  • Summary:

    According to the definition of ProjectSequence, "MODAF: Asserts that one ActualProject (MODAF::Project) follows from another - i.e. the target ActualProject cannot start until the source ActualProject has ended. DoDAF: NA".

    The restriction "...cannot start until the source ActualProject has ended..." precludes practical project management.

    In practice, projects can have a partial ordering yet not be strictly sequential. Projects can overlap each other in time, occurring partially contemporaneously.

    One sees, in a common tool such as Microsoft Project, the ability to specify Start to Start, Finish to Finish, Start to Finish, and Finish to Start offsets.

    Recommended Remedy: Enhance Project Sequencing to support SS, FF, SF, and FS offsets between prior and next ActualProjects. The kind of offset and the duration of the offset would each be Tag Values of ProjectSequence.

  • Reported: UPDM 2.1 — Wed, 15 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

System and PhysicalArchitecture are siblings not descendants

  • Key: UPDMRTF-18
  • Legacy Issue Number: 18708
  • Status: open  
  • Source: InterCAX ( Lonnie VanZandt)
  • Summary:

    As shown in Figure 8.127 for CapabilityConfiguration to PhysicalArchitecture and Figure 8.130 for PhysicalArchitecture to SystemResource and in Figure 8.178 for System to ResourceArtifact, Figure 8.132 for ResourceArtifact to PhysicalResource, Figure 8.131 for PhysicalResource to SystemResource, one can see that System and PhysicalArchitecture are sibling concepts.

    Now, FieldedCapability has this constraint: "Value for the classifier property must be stereotyped «CapabilityConfiguration» or its specializations." (see Page 172)

    The consequence of this is that a self-contained System cannot be the Classifier of a FieldedCapability. That is, a FieldedCapability cannot be an instance of a System.

    I claim that it is convenient to be able to specify that a FieldedCapability is an instance of a self-contained System. Having to model a separate CapabilityConfiguration to wrap just the System so that one can instantiate a FieldedCapability that is an instance of the System seems onerous.

    The recommended remedy is to allow a System to be a proper CapabilityConfiguration in addition to being a property of a CapabilityConfiguration.

  • Reported: UPDM 2.1 — Mon, 13 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

Integrate SysML Requirements and Constraints

  • Key: UPDMRTF-17
  • Legacy Issue Number: 18691
  • Status: open  
  • Source: InterCAX ( Lonnie VanZandt)
  • Summary:

    Constraints and Parametric Blocks in the SysML notation have proven their value in enabling the use of models as parameters for discipline-specific analysis and simulation. Likewise, SysML Requirements have proven their usability for annotating models with Requirements and with Requirements Traceabilities (such as Satisfaction, Derivation, etc.)

    The user community (including MITRE, Raytheon, Intercax, and professional services architects such as No Magic staff) requests that UPDM integrate the Requirements, Constraints, and Parametric Blocks into UPDM. Then, Enterprise Architects using UPDM can perform their systems and econometric analyses and their requirements engineering with their UPDM models that they can perform today in SysML modeling.

    (How and Where such integration is accomplished is a topic worthy of deliberation but is beyond the scope of a customer-centric requirement request.)

  • Reported: UPDM 2.1 — Wed, 1 May 2013 04:00 GMT
  • Updated: Mon, 27 Mar 2017 00:28 GMT

UPDM DoDAF lacks a concept for Service Orchestration

  • Key: UPDMRTF-16
  • Legacy Issue Number: 18688
  • Status: open  
  • Source: InterCAX ( Lonnie VanZandt)
  • Summary:

    Of the available DoDAF Service concepts, neither ServiceAccess nor ServiceDescription is an adequate concept for expressing collaborations of multiple Services such as one does in a SOA ServiceArchitecture.

    The lack of a concept like HighLevelOperationalConcept, say "ServicesOrchestration" or "ServicesCollaboration", for the SvcV-1 makes it difficult in UPDM DoDAF to model SOA Service Architectures. One has to borrow an instance of concept called "ServiceAccess"-which is poorly named and which suggests the means of accessing a single entity-and then claim that the borrowed ServiceAccess instance is really only an abstraction for representing a particular instance of an orchestration of multiple Services. One names it with its type as, say, "Service Orchestration for Situation X : ServiceAccess", and then uses its StructuredClassifier and its BehavioredClassifier natures in order to draw the orchestration of multiple ServiceAccess properties just as one uses UML's composite structures metamodel to model similar collaborations for Highlevel Operational Concepts, Systems Internal Interface Descriptions for systems collaboration in CapabilityConfigurations, SysML IBDs, and etc.

    ServiceDescription is a derivation of ArchitectureDescription that is, itself, an extension of Package. The intended purpose of ServiceDescription is for the documentation of the purpose and of the elements of a Service. Because of this documentary intention and because Package is not intended to be a suitable metaclass for the modeling of composition hierarchies, ServiceDescription, too, is not appropriate for the concept here called "ServicesCollaboration".

    Recommendation: either add <<SOAML::ServiceArchitecture [Collaboration]>> directly into UPDM or add <<UPDM::ServicesCollaboration [Class]>> to UPDM so that one can model Services in Composite hierarchies like they can model conceptually similar collections of parts in contexts in other notations.

  • Reported: UPDM 2.1 — Thu, 25 Apr 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Future Increments of UPDM should not preclude using SBVR for Modeling Vocabularies and Rules

  • Key: UPDMRTF-15
  • Legacy Issue Number: 18686
  • Status: open  
  • Source: InterCAX ( Lonnie VanZandt)
  • Summary:

    SBVR, the Semantics of Business Vocabularies and Business Rules, provides a formal logical foundation for the expression of enterprise ontologies and rule constraints applicable to enterprise elements. SBVR also offers informative, non-normative notations for these vocabularies and rules.

    Future increments of UPDM (i.e. UAFP v1) should not preclude an enterprise architect from using SBVR and its metaclass elements for the expression of ontologies and rules within their UPDM (to be known as UAFP) models.

    These enterprise ontologies and enterprise rules appear throughout a traditional UPDM architecture description in the structural elements of the respective views (e.g. Performers, Operational Activities, Systems, Services, etc) and in the constraints on those elements.

  • Reported: UPDM 2.1 — Wed, 24 Apr 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Need of Logical and Physical Services

  • Key: UPDMRTF-13
  • Legacy Issue Number: 18579
  • Status: open  
  • Source: Dassault Systemes ( Aurelijus Morkevicius)
  • Summary:

    In UPDM we are missing capability to differentiate between Logical and Physical Services. Note that this capability is already supported in DoDAF. It is also supported in other frameworks such as TOGAF etc.
    In UPDM it is mixed up and not clear enough what kind of services we are allowing to define. If we use services in SVs, we suppose to have physical services. If we are using services in OVs, we suppose to have Logical (Business) services. Having a normal logical/physical pattern we are already using in UPDM, we should be able to have traces between the two. Unfortunately we cannot differentiate between logical and physical services. It implies we cannot have two different levels of details when we are dealing with services. And we are forced to do services in either Operational or System viewpoint, but not in both.
    UPDM should:
    • Enable user to model logical services
    • Enable user to model physical services
    • Allow traces between logical and physical services
    • Provide means to integrate logical services to OVs
    • Provide means to integrate physical services to SVs

  • Reported: UPDM 2.1 — Tue, 26 Mar 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

PIM Logical Service Specification

  • Key: UPDMRTF-12
  • Legacy Issue Number: 18577
  • Status: open  
  • Source: General Dynamics ( Kent Laursen)
  • Summary:

    An import use of architecture is to provide sufficient information to guide the design and implementation that realizes the architecture in the actual solution space. By definition, architecture dictates neither the design nor the implementation that realizes it, though this boundary is often blurred to a certain degree by a particular organizations methodology or pragmatic need of a projects.

    As SOA is an a widely employed architectural pattern where by systems interact with each other, it would seem important that the expression of SOA in UPDM be fit for purpose, sufficiently accurate and information complete to reduce the conceptual gap between architecture and design+implementation. Further, the rendering or specification of SOA interfaces and used datatypes should be sufficiently fine grained to allow such possibilities as:

    Transformation into constructs used in design and implementation workflows, e.g. Code Skeletons, XML Schema, etc.

    Supporting the expression of test cases and declarative expressions of architectural instrumentation for such purposes as monitoring and analytics.

    In this particular issue we focus on the SvcV-1 and SvcV-2, which would be the natural place to specify the actual SOA related elements. The following diagram provides a context from an external, classifier derived perspective.

    Focusing on the services themselves, the diagram below shows an intended

    The SvcV-1 that illustrate the specification down to the actual operations is shown in the following diagram

    The issue submitter acknowledges that there are arguably some other ways to represent services, given such constructs as ServiceFunction, etc., but the method depicted above “feels” more accurate and aligned with downstream design and implementation, especially in the context of UML that might be used by teams independent of UPDM.

    In conclusion, the issue submitter, along with project colleagues, wish to have a useful set of mechanisms/metamodel constructs that allow the expression on services, their interactions and the flow of data between them at the PIM/Logical level using, logical data captured as EntityItem that details conceptual data captured as ExchangeElement. This would allow direct traceablity from conceptual interchange expressed at the OV level with how it is addressed at the SV level. In simpler terms, when two activities exchange information at the business process level, we can easily find how this conceptual interaction is realized as SOA services. Once establishing this in the model we can then hand it off to design and implementation workflows in a more accurate, traceable and useful architectural specification form. Significantly, such and architecture might prove much more fit-for-purpose for model related practices, transformations and automations involving the instrumentation, simulation and observation of the architecture in its solution realized forms. Also tests might be expressed more tightly.

    Resolution:
    Part of the resolution would be related to the fact that and ExchangeElement is subtyped from ResourceInteractionItem whereas EntityItem is subtyped from Class. The result is that a logical data structure captured as an EntityItem cannot be the conveyed item in a ResourceInteraction. We would either need to revise the metamodel related to ResoureInteractionItem or add some new construct, say something like DataInteractionItem and DataInteraction that could be used to express the flow of logical data, which the issue submitter models using EntityItem in DIV-2 package structures.

    On the profile diagram below, one can observe the absence of EntityItem

    There are related traceablity issues that will the subject of further submissions, however, this submission focuses on the essential part of expressing the set of SOA ports, interfaces and data flows in an architecture.

  • Reported: UPDM 2.1 — Sat, 23 Mar 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Simplify measurements in UPDM

  • Key: UPDMRTF-11
  • Legacy Issue Number: 18573
  • Status: open  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    Please enter this issue against UPDM RTF 2.2.
    Simplify measurements in UPDM and make measurement compatible with SysML unit, value, and parametric constraint.
    See diagrams below. No need for measurement set.

  • Reported: UPDM 2.1 — Wed, 20 Mar 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Expand general activity modeling for all UPDM constructs to include representation by action, callBehaviorAction and

  • Key: UPDMRTF-10
  • Legacy Issue Number: 18571
  • Status: open  
  • Source: Lockheed Martin ( Laura Hart)
  • Summary:

    Expand general activity modeling for all UPDM constructs to include representation by action, callBehaviorAction and callOperationAction. Please enter issue against UPDM RTF 2.2.
    Allow ( OperationalActivityAction, ServiceFunctionAction, ProjectActivityAction and FunctionAction ) to be represented as either CallBehaviorAction, CallOperationAction or Actions. Currently only CallBehaviorAction is allowed.

  • Reported: UPDM 2.1 — Wed, 20 Mar 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Implements Relationship between Exchange Elements

  • Key: UPDMRTF-14
  • Legacy Issue Number: 18580
  • Status: open  
  • Source: Dassault Systemes ( Aurelijus Morkevicius)
  • Summary:

    In UPDM 2.0 Exchange Elements emerged from Information and Data Elements used in UPDM 1.x. They can still be classified into information and data indicating different levels of abstraction. However, one cannot be connected to another as it used to be in UPDM 1.x. In other words there is no way to relate data to information.

  • Reported: UPDM 2.1 — Tue, 26 Mar 2013 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Views should be Normative

  • Key: UPDMRTF-8
  • Legacy Issue Number: 17430
  • Status: open  
  • Source: Independent ( Leonard Levine)
  • Summary:

    While the proper implementation of a UPDM 2.0 Profile assures successful exchange of data models, the exact content of the VIEWS remain non-normative. There needs to be a definition of the minimum data elements to support each view as well as optional data elements. The UPDM RTF Group needs to discuss whether all (52?) Views need to be made NORMATIVE, how to support Optional data, and how to support the required USER-DEFINED VIEWS.

  • Reported: UPDM 2.0 — Thu, 14 Jun 2012 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

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

  • Key: UPDMRTF-7
  • Legacy Issue Number: 17401
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

  • Reported: UPDM 2.1 — Mon, 4 Jun 2012 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Desired Effect needs to be a strategic-level model able element

  • Key: UPDMRTF-6
  • Legacy Issue Number: 17310
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    I really need "Desired Effect" reinstated. This will act as the "Objective" in my strategy models. This was available in UPDM 1.0 now it's gone. This is actually very important to modeling a strategy.

    However, when or if you can bring it back, it previously provided the output link of "Realizes Vision". That is wrong. It needs to "Realizes Enterprise Goal". It's the Enterprise Goals that realize the Mission. And it's the Mission(s) that realizes the Vision.

    The sequence is as follows:

    CAPABILITY-->DESIRED EFFECT->ENTERPRISE GOAL->MISSION-->VISION

  • Reported: UPDM 2.1 — Fri, 13 Apr 2012 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Use of superSubType, wholePart and WholePartType in DoDAF 2

  • Key: UPDMRTF-5
  • Legacy Issue Number: 17290
  • Status: open  
  • Source: Syntell AB ( Lars-Olof Kihlstrom)
  • Summary:

    Use of superSubType, wholePart and WholePartType in DoDAF 2
    DoDAF 2 contains rules that indicate that superSubtype relationships can be formed between any type elements of the same kind. The same rule applies for wholePart (betwen individuals of the same type) and WholePartType (between types of the same kind). In UPDM terms this would correspond to Generalization as well as property handling. There are not enough stereotypes defined within UPDM 2 to allow these rules to be followed. This either needs to be rectified or a general statement made within UPDM that allows the use of the appropriate UML relationships to accomplish this.

  • Reported: UPDM 2.1 — Sun, 1 Apr 2012 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Mapping to DM2 higher level elements:

  • Key: UPDMRTF-4
  • Legacy Issue Number: 17278
  • Status: open  
  • Source: Syntell AB ( Lars-Olof Kihlstrom)
  • Summary:

    Currently UPDM does not map a numer of elements that exist in DM2, namely those above the Type level, for example CapabilityType since UML does not support elements at higher type levels. There is however a possibility of doing this by recognising that a set of capabilities (as an example) contains a given capability instance but capability categoreis are really a larger subset of available capabilities. This would make it possible by allowing the elements to contain a tagged value that indicates whether they are to be considered at a higher type level. This would make it possible to provide a mapping between more DM2 elements and UPDM elements than currently possible. It is assumed that a tagged value would be easier to handle than the introduction of additional stereotypes since categories would imply elements with different stereotypes inheriting from one another.

  • Reported: UPDM 2.1 — Wed, 28 Mar 2012 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Need for ServiceInterfaces to be represented as an instance to capture specific ServiceAttributes

  • Key: UPDMRTF-3
  • Legacy Issue Number: 17259
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    ActualServiceInterface:
    This would be an element that is the equivalent of the MODAF element ServiceLevel and would contain slots and instance values for the properties that have been defined for ServiceInterface. There would be a need to provide a tagged value to any usage of the ServiceInterface as a port either on a NodeRole or ResourceRole where the actual service interface would be indicated that is to be viewed as a requirement for this particular context. For the port used on the ResourceRole there would also be a need to indicate how many instances of the actualServiceInterface that the ResourceRole would need to accomodate, at least if a complete mapping to between MODAF and UPDM is to be achieved. (All of this actually exists already as part of the MODAF model that UPDM is supposed to implement).

  • Reported: UPDM 2.1 — Tue, 20 Mar 2012 04:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Figure 7.8: <> should be changed to <>

  • Key: UPDMRTF-2
  • Legacy Issue Number: 17206
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

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

  • Reported: UPDM 2.0 — Thu, 1 Mar 2012 05:00 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

Specification lacks Hyperlinks for references to Model Element Names

  • Key: UPDMRTF-1
  • Status: open  
  • Source: InterCAX ( Lonnie VanZandt)
  • Summary:

    When the specification is generated, the generator should emit cross-references for references to model elements throughout the text.

  • Reported: UPDM 2.1 — Mon, 9 Dec 2013 22:49 GMT
  • Updated: Tue, 28 Feb 2017 00:42 GMT

explain the relevance of this standard to IT and SE in general

  • Key: UPDMRTF-68
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    For IT and systems engineering experts who are not familiar with military matters it is unreasonably difficult to understand the title of this standard and its significance for IT and systems engineering in general.

    Add, immediately under the heading “Subpart I – Introduction” on page 1, an introductory paragraph e.g. as follows: “This international standard provides a specification language, UPDM, that is readily understandable not only by the community of architects of information technology systems but also by a wide range of end users including executives and enterprise management that sponsor such systems, program managers that oversee their development, developers of supporting hardware and software (design, implementation, and testing), subject matter experts, and end users. UPDM bridges the gap from setting of requirements to high level system design and to visualization for practitioners. While designed in the context of military organisations and their procurement processes, UPDM can also be applied in entirely civilian industrial and service organisation contexts.”

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:09 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

lacking clause and number heading

  • Key: UPDMRTF-67
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    There is no clause number & heading on the first paragraph right after “Subpart”. It is a hanging paragraph

    Action:-These subheadings are in the OMG template and from reviewing other PAS submissions it reveals that these documents have been submitted to ISO using the same format.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:08 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

unify representation style for inheritance

  • Key: UPDMRTF-66
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    In case of UML, inheritance is described as “Generalization” in texts. However, in this document, inheritance is described as “Specializations”. It is confusing.

    Unify the representation style for the inheritance, that is, decide which representation is taken.

    UPDM Group response
    Although the relationship is called generalization in UML, the term is dependent upon the direction from which the relationship is being viewed. If taken from the perspective of the element which is the is focus of a specific diagram (which is the case in this specification), the term used is specialization.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:05 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

UPDM v2.1 is specific to DoD and MOD procedures.

  • Key: UPDMRTF-44
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    "UAF" written in the explanatory report should be made an international standard.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:18 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

pacakge partitioning not clear

  • Key: UPDMRTF-63
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    According to the explanation, the “Partitioning” is the package. However, I couldn’t find the packaged diagrams except for the “Aliases”. It seems that it is necessary to define UPDM using Package diagrams.

    Replace the Pertitioning section 7.3 with the following.
    Partitioning: The UPDM profile is organized as a number of hierarchical packages that are used to group elements, and to provide a namespace for those grouped elements. The top level structure of these packages can be seen in Figure 2.2.(Packages are represented in the diagram by a rectangle with a tab in the upper left hand corner).

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:45 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

missing description for associations

  • Key: UPDMRTF-65
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The UPDM classes are defined using class diagram and those descriptions. Some class diagrams specify association link. However, there is no description for association as text..

    UPDM Group response
    The OMG Architecture board did not require this level of detail in the documentation so it was not added.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:04 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

missing class definitions

  • Key: UPDMRTF-64
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    This clause describes the class library using class diagram. However, there is no class definition for each, that is, there is no attributes description and association description.

    UPDM Group response
    The OMG architecture board did not require this level of detail in the documentation so it was not added.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 20:02 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

odd reference to UPDM RFC

  • Key: UPDMRTF-61
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The “UPDM RFC” suddenly appears without a definition or a reference. It seems that this RFC is meaningless. This sentence is informative. It is obvious matter to follow the RFC.

    Remove the description which mentions the “RFC”. Or if the RFC is inevitable, it is necessary to reference to RFC or remove the RFC.

    Delete RFC from the paragraph
    This International Standard reuses a subset of UML 2 and provides additional extensions needed to address the requirements of developing UPDM. We have used those requirements as the basis for this International Standard.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:41 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

Some of text should be merged into the scope Clause 1.

  • Key: UPDMRTF-60
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Modified the scope and sections 6.2.1 and 6.2.2 replace the original sections with this text

    6.2.1 Intended Audience
    This specification will be of interest to end users, military, industrial and commercial, who expect to use this profile, and to tool vendors interested in developing tool support for the development of enterprise and system of systems architectures.
    Section 6.2.2 Organization of this specification
    DoDAF and MODAF are formally expressed as domain-specific meta-models known as the DoDAF Meta Model (DM2) and the MODAF Meta Model (M3) respectively, this provides the foundation for the UPDM domain metamodel and profile. There is also a set of viewpoints and views that address the concerns of a well-defined set of stakeholders. This specification organizes the presentation of the UPDM 2.1 abstract and concrete syntax around the meta-models, with effort made to establish a maximum set of common Core models and a minimum set of DoDAF DM2 or MODAF M3 specific models. Significant effort has also been made to continue to support the now over 50 viewpoints that can be derived from these meta-models as well as "user-defined views". This allows tool-vendors to specify views, based upon a common metamodel that are more applicable to industrial and commercial concerns than just military, it also ensures that the discussion is well-connected to the domain experts required to produce these views. (See Section 1.5 for a more detailed description.)"The rest of this document contains the technical content of this specification. As background for this specification, readers may wish to review the UML, OMG SysML, and SoaML specifications that complement this specification.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:39 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

DMM is non-normative but appears to be nomative

  • Key: UPDMRTF-62
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    This document refers to “DMM” which is defined as non-normative Annex A. However, it seems to be Normative. Besides, according to the text, it is necessary to refer to the colour legend. However, I couldn’t find the legend.

    Clarify this sentence. If those were Normative, move DMM to the body parts.

    Response,
    add colour coding legend and explanations.

    The DMM is intended to be informative and was used to develop an understanding of the foundational concepts from which the UPDM profile evolved. It remains useful for understanding the architectural concepts required to implement UPDM. It is expected that UML and SysML tool vendors who implement UPDM would implement this profile rather than the DMM; however, it is possible non-UML tool vendors may wish to implement UPDM in their by tool by following the DMM.
    In annex A delete the second paragraph starting “Note that the” and replace with the text and diagrams below.
    Note that the diagrams rely on color to aid the reader in understanding the model. Please refer to the legend below to understand the diagrams.
    The following is the legend of element colors used in the DMM and what they denote.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:43 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT
  • Attachments:

DOTMLP should be DOTMLPF.

  • Key: UPDMRTF-59
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Table 5.1 modify DOTMLP to DOTMLPF

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:39 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

It is much to easy to rely on reference documents

  • Key: UPDMRTF-58
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    from section 4 delete the sentences
    No new terms and definitions have been required to create this International Standard. All terms should be available in the normative references or bibliographic citations for detailed explanation.
    And add the sentence

    Any additional terms created to implement UPDM have been defined within this standard.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:38 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

Confusing conformance/compliance statements re DoDAF 2.o2

  • Key: UPDMRTF-57
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The clause 3.4 describes the DoDAF 2.02 Conformance. However, the “Compliance” is already described in clause 2. The structure is confusing.

    Delete the section entitled 3.4.1 DoDAF 2.02 Conformance
    Create section in section 2, 2.2 Compliance to DoDAF 2.02
    Add text
    UPDM 2.1 conforms with DoDAF 2.02

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:37 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

Don’t separate the “Normative Reference” clause.

  • Key: UPDMRTF-56
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    GB remove title sections for 3.3 and 3.4
    Delete section 3.4 completely
    Add reference to
    DoD Architecture Framework 2.02 http://dodcio.defense.gov/Library/DoDArchitectureFramework.aspx

    References
    • ISO 8601:2004 Data elements and interchange formats- Information interchange-Representation of dates and times, IS0/TC154
    • ISO/IEC 19505-1 , Information technology — OMG Unified Modeling Language (OMG UML) Version 2.4.1 — Part 1: Infrastructure; pas/2011-08-05
    • ISO/IEC 19505-2 , Information technology — OMG Unified Modeling Language (OMG UML) Version 2.4.1 — Part 2: Superstructure; pas/2011-08-06
    • OMG Specification formal/ 2010-05-03, UML Infrastructure, v2.3
    • OMG Specification formal/ 2010-05-05, UML Superstructure, v2.3
    • OMG Specification formal/ 2005-09-01, XML Metadata Interchange (XMI), v2.1

    • OMG Specification formal/2006-05-01, Object Constraint Language, v2. 0
    • OMG Specification formal/2012-03-01, SoaML, v1.0
    • OMG Specification formal/2010-06-01, SysML, v1.2

    • The MOD Architectural Framework (MODAF) Version 1.2.002 (https://www.gov.uk/guidance/mod-architecture-framework)
    • The DoD Architecture Framework (DoDAF) Version 2.02 (http://dodcio.defense.gov/Library/DoDArchitectureFramework.aspx)

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:34 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

Existing ISO standards should be mentioned.

  • Key: UPDMRTF-55
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Add these references to section 3

    ISO/IEC 19505-1: 2012(UML 2.4.1 Infrastructure), ISO/IEC 19505-2: 2012 (UML 2.4.1 Superstructure), ISO/IEC 19507:2012 (OCL )

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:33 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

IS0, TC154 should be ISO/TC154.

  • Key: UPDMRTF-54
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    text should be

    ISO 8601:2004 Data elements and interchange formats - Information interchange - Representation of dates and times, IS0/TC154 (http://www.iso.org/iso/home/store/catalogue_ics/ catalogue_detail_ics.htm?ics1=01&ics2=140&ics3=30&csnumber=40874)

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:32 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

The format of normative references don't meet ISO format

  • Key: UPDMRTF-53
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Designate references like as other OMG PAS documents
    See UML2.4.1

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:30 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

modify reference to UML 2.3 to UML 2.4.1

  • Key: UPDMRTF-52
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    UML2.3 should be changed to UML 2.4.1unless there is inevitable reason, since UML2.4.1 has been standardized as IS.

    Response:- At the time the standard was published UML 2.3 was the current version of UML. A change to UML 2.4.1 would invalidate the references to UML in the XMI resulting in a major change to the standard. It is envisaged that a major release i.e. UPDM 3.0 aka UAF 1 would update the references to the latest versions of UML and SysML available.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:29 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

The last bullet point is broken.

  • Key: UPDMRTF-51
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Action:- Modified the bullet

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:28 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

Notation on Diagram 2.1 not clear

  • Key: UPDMRTF-47
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    What allows (arrows) in the diagram do mean? Are they support or consist of UPDM?

    Action:- New diagram created using UML notation to replace original

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:24 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT
  • Attachments:

Figure is a little grainy.


The first sentence may invite misunderstand that “UPDM 2.1” and this standard are different.

  • Key: UPDMRTF-49
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The title should be mentioned like;
    Information technology - Object Management Group Unified Profile for DoDAF and MODAF (UPDM 2.1)

    Action:-Added (UPDM 2.1) to the end of the title on page 3

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:26 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

The scope of this standard focused too much on the use of DoD and MOD area.

  • Key: UPDMRTF-48
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Action:- We modified text in the scope section.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:25 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

missing definition for NAF in glossary of terms

  • Key: UPDMRTF-46
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Add the definition for NAF in clause 5.

    Action:- Added NAF and its definition to the appropriate place in table 5.1

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:21 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

Objection to scope of UPDM fro ISO

  • Key: UPDMRTF-45
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    As stated in the clause 6.2, this standard intends to facilitate end user who want to communicate with DoD and MOD.
    If so, this standards need not to be an ISO or ISO/IEC standard.

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:20 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

Figure number is incorrect in Subpart 1.

  • Key: UPDMRTF-43
  • Status: open  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Figure 2.1 page 4 should be Figure 1.1
    Figure 2.2 page 4 should be Figure 2.1
    Figure 2.3 page 5 should be Figure 2.2
    References to the original figure numbering in the text need to be modified
    Table on page 9-10 should have title
    Table 5.1 Glossary of Abbreviations and Acronyms
    Table on page 11-12 should have title
    Table 6.1 Additional Materials

  • Reported: UPDM 2.1 — Tue, 13 Sep 2016 19:15 GMT
  • Updated: Mon, 31 Oct 2016 00:04 GMT

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: agnos.ai UK Ltd ( 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: agnos.ai UK Ltd ( 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: