Unified Profile for DoDAF and MODAF Avatar
  1. OMG Specification

Unified Profile for DoDAF and MODAF — All Issues

  • Acronym: UPDM
  • Issues Count: 931
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UPDMRTF-43 Figure number is incorrect in Subpart 1. UPDM 2.1 open
UPDMRTF-45 Objection to scope of UPDM fro ISO UPDM 2.1 open
UPDMRTF-46 missing definition for NAF in glossary of terms 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-52 modify reference to UML 2.3 to UML 2.4.1 UPDM 2.1 open
UPDMRTF-47 Notation on Diagram 2.1 not clear UPDM 2.1 open
UPDMRTF-53 The format of normative references don't meet ISO format UPDM 2.1 open
UPDMRTF-51 The last bullet point is broken. 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-50 Figure is a little grainy. UPDM 2.1 open
UPDMRTF-58 It is much to easy to rely on reference documents UPDM 2.1 open
UPDMRTF-56 Don’t separate the “Normative Reference” clause. UPDM 2.1 open
UPDMRTF-57 Confusing conformance/compliance statements re DoDAF 2.o2 UPDM 2.1 open
UPDMRTF-54 IS0, TC154 should be ISO/TC154. UPDM 2.1 open
UPDMRTF-55 Existing ISO standards should be mentioned. UPDM 2.1 open
UPDMRTF-61 odd reference to UPDM RFC UPDM 2.1 open
UPDMRTF-64 missing class definitions 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-63 pacakge partitioning not clear UPDM 2.1 open
UPDMRTF-65 missing description for associations UPDM 2.1 open
UPDMRTF-66 unify representation style for inheritance UPDM 2.1 open
UPDMRTF-67 lacking clause and number heading UPDM 2.1 open
UPDMRTF-44 UPDM v2.1 is specific to DoD and MOD procedures. 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-68 explain the relevance of this standard to IT and SE in general UPDM 2.1 open
UPDMRTF-5 Use of superSubType, wholePart and WholePartType in DoDAF 2 UPDM 2.1 open
UPDMRTF-6 Desired Effect needs to be a strategic-level model able element 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-1 Specification lacks Hyperlinks for references to Model Element Names UPDM 2.1 open
UPDMRTF-12 PIM Logical Service Specification 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-11 Simplify measurements in UPDM UPDM 2.1 open
UPDMRTF-18 System and PhysicalArchitecture are siblings not descendants UPDM 2.1 open
UPDMRTF-16 UPDM DoDAF lacks a concept for Service Orchestration UPDM 2.1 open
UPDMRTF-17 Integrate SysML Requirements and Constraints UPDM 2.1 open
UPDMRTF-13 Need of Logical and Physical Services 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-19 ProjectSequence is too Restrictive 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-21 MapsToCapability relationship is too Restrictive, and ActivityPartOfCapability is redundant UPDM 2.1 open
UPDMRTF-24 CV6, CV-7 and NSOV-3 UPDM 2.1 open
UPDMRTF-22 use of Generalization to implement Aliasing UPDM 2.1 open
UPDMRTF-23 Use of Actual vs. Type in PV-1 UPDM 2.1 open
UPDMRTF-25 Subject of a State Machine 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-31 For UAFP. Include a Data and Information view (DIV) UPDM 2.1 open
UPDMRTF-29 Information flow instantiation 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-26 Need of Composition between Enterprise Goals UPDM 2.1 open
UPDMRTF-27 Why is EnterprisePhase to EnterpriseVision a one to one relationship UPDM 2.1 open
UPDMRTF-32 Why are rules in OV-6a and SV-10a not parsed? UPDM 2.1 open
UPDMRTF-35 modify the term NodeRole so that is more applicable to a Peformer UPDM 2.1 open
UPDMRTF-33 Why does a user need to build an SOV-3? 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-37 Profile and Tooling should enforce the Proper Specification of Capabilities UPDM 2.1 open
UPDMRTF-38 AV-2 Definitions need Authoritative Source property and Tooling to enforce its Use UPDM 2.1 open
UPDMRTF-39 UPDM Users want to model Test Contexts and Test Cases within UPDM UPDM 2.1 open
UPDMRTF-40 Figure 8.1 Presents InformationAssuranceProperties Twice 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-42 Withdraw UDPM Spec UPDM 2.1 open
UPDMRTF-146 capability element should have a relation to sysml requirement type. UPDM 2.1.1 open
UPDM-778 The element descriptions in Part II have no provision to explain stereotyped relationship UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-777 SOAML missing from figure 2 and figure 3 in UPDM spec UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-776 Annex A should start with the Layers section UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM11-31 Fig 14 & Fig 16 - Consistent Profile Usage UPDM 1.0b1 open
UPDM11-32 Fig19 - More Needed Here UPDM 1.0b1 open
UPDM-775 StrategicMission UPDM 1.0b1 UPDM 1.0 Duplicate or Merged closed
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-771 UPDM XMI documents misnamed UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-770 UPDM XMI contains properties with incorrect lower values UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM2-52 Need to change generalisation section text for all elements to be a specialisation UPDM 1.1 UPDM 2.0 Resolved closed
UPDM2-53 Replace ActivityPerformableUnderCondition with a Tag UPDM 1.1 UPDM 2.0 Resolved closed
UPDM-769 Need to make SubSystemPart part of the DoDAF resources model UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-768 no ability in UPDM to define internal flows to a system or node (inside a swim lane in OV-5 or Sv-4). UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-767 Constraint to be fixed UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-766 miswording on a number of diagram titles for products UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-765 itemFlow stereotype UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-761 <> has tag called carriedExchange that is type of <> UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-763 current UPDM documentation and XMI is not in line with the submitted SOAML XMI and documentation UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-762 <> UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-764 Elements used by UPDM from SOAML are not the actual elements from the submitted SOAML XMI UPDM 1.0 UPDM 1.0.1 Resolved closed
UPDM-760 OV-2 & StV-2 Capabilities & Nodes. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-759 Instances UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-758 Fig118 UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-757 OV-7 UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-756 7.1.1 - Naming of types and individuals. UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-755 All of the derived tags require the derivation documenting. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-754 Exchanges should be extended to allow Software and CapabilityConfigurations to be conveyed as well. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-753 The split between Core, DoDAF and MODAF is not intuitive in certain places. UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-752 element descriptions UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-748 In DODAF, OperationalActivities and Nodes have level identifiers. Should we have a derived property for it? UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-747 Test Enterprise. UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-751 inter-operability Requirements and Work Products Implementation UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-750 create detailed step-by-step examples UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-749 LogicalArchitecture - PhysicalArchitecture UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-746 ResourceRole specializations really need simplifying and made compliant with our naming convention UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-745 SubOrganization and Post should be removed and OrganizationRole made concrete in the core UPDM 1.0b1 UPDM 1.0.1 Resolved closed
UPDM-744 Current navigability is wrong UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-743 UPDM Issue: Derived tag updates UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-742 Constraints between FunctionAction and FunctionEdge are too limiting UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-738 Add DataElement as SubjectOfResourceStateMachine. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-737 Add the ability for Node to own ServiceOperations UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-736 Resource property "actsUpon" needs to be changed UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-741 DMM and Profile are not synchronized UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-740 InformationElement/EntityItem UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-739 SoaML integration UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-730 MODAF Re-Use UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-729 MODAF Definitions UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-728 Performer & Activity UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-727 Required & Actual UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-726 ProtocolImplementation UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-721 Fig134 Artifact [FacilityType?] UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-720 Fig129 UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-719 StV-6 UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-732 SV-2 Missing UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-731 Documentation UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-735 The term Node needs stronger wording in its definition to separate its meaning between DoDAF and MODAF UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-734 InformationTechnologyStandardCategory UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-733 SubjectOfOperationalConstraint UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-723 SV-12 Description UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-722 Fig139 InternalDataModel UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-718 EnterpriseGoal-Capability UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-717 EnterpriseGoal UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-724 Fig141 UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-725 Fig143 FunctionParameter UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-702 Fig45 - NodeChild. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-701 Page 37 - SOA UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-700 Fig44 - NodePort. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-699 Fig44 - ExternalNode. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-706 7.1.4.1.1 Operational Activity Definition UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-705 Fig53 - Logical & Physical UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-704 Fig51 - Mission & States UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-703 Fig51 - Entity SubjectOfOperationalState UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-710 7.1.4.4.10 Mission UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-709 7.1.4.4.6 HighLevelOperationalConcept UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-708 Needlines & Non-Information UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-707 7.1.4.1.1 Tags on OperationalActivity UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-698 Top of Page 37 - "an OV-2 diagram (now OV-2a)" UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-697 Top of Page 37 UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-696 Fig44 - RequiresCapability UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-695 Fig44 - NodeType UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-713 OV-4 - Person UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-712 Fig 91 - OrganizationalExchange UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-711 7.1.4.4.11 Needline UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-716 7.1.5.2.2 Service UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-715 7.1.5.2.1 Request UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-714 Fig104 - ServiceFunction UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-694 Figure 44 - Title UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-693 7.1.2.5.3 - Measures UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-692 7.1.2.5.1 - ActualMeasurement. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-690 Fig21 - SameAs. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-689 Fig20 - AV3? UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-691 Fig27 & Fig28 & Fig29 - Climate, etc. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-676 ensure that constraints are placed on the combination of Project, ProjectMilestone and ProjectThemeStatus UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-675 Rename NeedlineExchange to OperationalExchange UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-674 Association between OperationalActivityEdge and NeedlineExchange should be reversed UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-673 Milestones UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-672 Change InformationElement to extend Class. Review relationship to Entity? UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-671 ServiceInterface currently extends Interface but is also supposed to have provided/required interfaces UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-670 The examples of the SV-9 on the MODAF website don't obviously map to the implementation in MODAF/UPDM UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-669 Page 184, Figure 235 SOV contains composition ownership problems UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-668 Some diagrams are very crowded UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-680 Fig15 - ActualProjectMilestone to Project Status and ProjectStatus to ProjectTheme UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-679 Fig15 - Inheritance Problem UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-678 PhysicalLocation is located in the wrong package/subprofile. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-677 Controls should have the same fixes applied as Commands. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-683 Fig21 - Constraint on StructuralPart is wrong UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-682 AcV - General Comment. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-681 Fig15 - Project whole and part and ownedMilestones UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-667 would be nice to have the actual legend in the second paragraph of Annex A UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-666 Page 175, "Figure 225 - Elements related to the EnduringTask stereotype" overlays the text. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-665 Page 169, 7.1.14.3.2 EnergyExchange, the constraint description contains two extraneous constraints UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-664 Page 169, 7.1.14.3.1 Controls UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-686 Fig19 - Ontology Reference UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-685 Fig18 - ArchitecturalDescription UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-684 Fig18 - Mission. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-688 Fig19 - Use of Ontology & Generalization UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-687 Fig19 - StereotypeExtension UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-661 Page 166, 7.1.14.1.1 ActivitySubject UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-660 Page 158, "Figure 203 - Elements related to the ProjectStatus stereotype" overlays the text UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-659 Page 152, 7.1.11.2.1 DataExchange UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-663 Page 168, "Figure 217 - Elements related to the Controls stereotype" overlays the text UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-662 Page 167, "Figure 214 - Elements related to the StandardOperationalActivity stereotype" overlays the text UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-641 conformance sections from chapter 5 and 6 need to be combined into one single conformance clause UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-640 description of the profile package structure in "6.4 Profile Structure" UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-639 material - materiel UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-644 Figure 34 UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-643 Documentation P2 UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-642 Page 7, 6.6.1 Aliases UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-654 Page 115, 7.1.7.1.1 Function UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-653 Page 91, 7.1.5.2.4 ServiceInterface UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-648 Page 70, 7.1.4.4.19.1.2 ActualOrganizationalResource UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-647 Remove unnecessary constraints UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-652 Page 83, 7.1.5.1.1 ServiceFunction UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-651 Page 79, 7.1.4.4.19.1.14 RequiresCompetence UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-646 Page 55, 7.1.4.4.1 ArbitraryRelationshipConnector UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-645 Page 48, 7.1.4.1.6 SubjectOfOperationalStateMachine UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-650 Page 75, 7.1.4.4.19.1.8 SubOrganization UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-649 Page 74, 7.1.4.4.19.1.7 Post, the two constraint descriptions are over cross UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-656 Page 136, 7.1.7.4.14 ResourceInterface, please verify the constraint descriptions UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-655 Page 117, 7.1.7.1.3 FunctionEdge UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-658 Page 146, 7.1.8.2 ProtocolImplementation, no diagram to help verifying attributes and constraints UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-657 Page 145, 7.1.8.1 Protocol, no diagram here to clarify attributes UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-622 Do we need a place (Node or something else) for OperationalActivities to take place?The same for Functions. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-621 Various properties for InformationExchange (appearing in DoDAF 1.5) should be modelled as Measurements in UPDM UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-628 CommunicationsLink in DoDAF had properties:capacityinfrastructure technology UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-627 Addition of properties UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-626 DoDAF had two levels of SV relations - interface and link. UPDM has only one. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-630 ResourcePart is mentioned in the spec UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-629 Role Is mentioned in the spec, but no such stereotype exists. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-625 Why is the relationship between UPDMElement and Measurements not bi-directional? UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-624 Do we need Consumers/Producers for services as in DoDAF? UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-623 In DoDAF Operational Activity has "cost" property. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-638 ServiceOperation UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-637 InformationElement UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-634 EnvironmentalProperty UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-633 Performs, Two of the constraints do not belong UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-636 SubjectOfOperationalStateMachine UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-635 Measurement UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-632 ResourceInterface and ResourceInteraction. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-631 ResourceConnector>> is mentioned in the spec UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-620 UPDM:ScopeContentlanguageaccuracy UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-619 relationship between NeedlineExchange and ResourceInteraction UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-618 Can NodePort be assigned on NodeRole? Now the constraint says only about Node.The same about ResourcePort UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-617 LocationType is missing, but is mentioned throughout document. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-598 There's no metaConstraint from ResourceInteraction to the source/target of the interaction UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-597 "abstractBehavior" tagged value between ServiceOperation and ServiceFunction should be shown on the SOV-5 diagram UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-596 There doesn't seem much point in showing Service on the SOV-1 UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-595 The "carriedItem" tag between OperationalActivityEdge and NeedlineExchangeItem (NEI) isn't really needed UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-601 It'd be more consistent for the "/subject" to "/affectedFunctions" to have the same names as the OV equivalent UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-600 The "to/from" tagged values for Protocol should have better names UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-599 ProtocolImplementation UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-603 There should be some additional constraints for the DoDAF/MODAF stereotypes UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-602 The SystemsNode stereotype is missing UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-616 Environment is both a DataType and a Class in the spec. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-615 ActualLocation is both a DataType and a Class in the spec UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-614 ExternalTypes UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-609 Responsibility is not covered. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-608 Attributes for Measurements - units of measure, threshold value. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-613 It's not clear on the diagram that we expect people will create Provided/Required Interfaces off a ServiceInterface UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-612 The SOV-1 is inconsistent with other Taxonomy views and should be updated UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-607 Should there be any link between OperationalActivity and Capability? UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-606 Why there is not potential relationship between InformationElement and SystemDataElement? UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-605 Don't we need System/Artifact specializations, like Network, etc? UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-604 Should there be a relationship between Capability and Mission? UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-611 No traceability from Node to SV. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-610 No Rule for SV. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-590 ArchitecturalDescriptions aren't supposed to own Views UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-589 no type for the ProjectTheme so there's no way to define a value UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-588 milestone sequence stereotype should be shown on SV-8 view UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-587 Actual measurement UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-594 metaConstraint between ResourceType and ResourceRole UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-593 metaConstraint between ActualOrganizationPart and ActualOrganization UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-592 PostType should be called Post.Post should be called PostRole UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-591 There's no metaConstraint from NeedlineExchange to the source/target of the exchange UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-586 metaConstraint between EntityRelationship and Attribute UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-585 two ways to allocate Operational Activities/Function to Nodes/Resources UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-584 ArbitraryRelationshipConnector is a bit of a long name UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-572 OperationalActivity UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-571 Climate UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-570 ActualProjectMilestone UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-575 ServiceInteraction UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-574 ActualOrganizationRelationship, UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-573 Mission UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-581 Currently ActualMeasurementSets are not related to time UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-580 Why are the Controls.xxxx constraints listed here UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-579 Page 49, 7.1.4.2.1 Attribute, has a wrong constraint UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-578 abstract stereotypes should not extend UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-577 OntologyReference UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-576 ProjectSequence UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-583 Can a Node host Activities? UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-582 ArbitraryRelationshipConnector UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-551 OperationalActivity/SysFunction consumes/produces exchanges UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-550 Attributes for Organization - code, military service type, etc. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-549 OperationalConstraint/ResourceConstraint UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-548 various identifiers UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-554 Should there be a enumeration property on the RealizesCapability element to indicate the level of the realization? UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-553 ServiceInterfaces should have the ability to have Dependencies between them. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-552 Needline is not realized in SVs. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-560 ServiceParameter needs to have a metaconstraint modelled UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-559 ServiceOperations need to be owned by Resources as well as ServiceInterfaces UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-556 OntologyReference has invalid specializations. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-555 change ArbitraryConnector to a Dependency and change the name to ArbitraryRelationship UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-567 I really don't see the point in Function having a StateMachine UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-566 There should be a stereotype called RealizesNode between Node and Resource UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-565 Commands , This stereotype has extra constraints that do not belong there UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-558 allow ServiceOperationActions to be owned by Functions as well as ServiceFunctions on the SV-4 UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-557 Referred location extends different metatypes than its sub-stereotypes. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-562 A DataType can own attributes and operations but not behaviors UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-561 We aren't consistent about the tag definition names used for storing start and end dates UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-564 Missing stereotype UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-563 A DataType is not a StructuredClassifier so it cannot have parts UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-569 ItemInConcept is an abstract stereotype, but is should not be. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-568 ArbitraryRelationshipConnector UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-527 Imported SysML Stereotypes cannot be applied UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-526 No support for MODAF Problem Domain UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-525 ResourcePort & ResourceType circular inheritance UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-524 Stereotype names collide with UML keywords (meta-types) UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-523 Abstract Stereotypes should not Extend Element UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-540 Stereotyped Dependencies too limiting UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-539 Relationships defined using Property "type" are not intuitive UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-538 Document layout and section numbering hard to read UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-542 Sequence diagrams cannot show exchanges UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-541 Confusing notational conventions used in diagrams UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-534 Attribute stereotype has issues with non-navigable associations UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-533 OperationalActivityEdge constraints too restrictive UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-532 Operational Activity action constraints too restrictive UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-531 ISO8601DateTime should not extend LiteralString UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-530 Measurement can have a circular reference UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-529 ActualMeasurement can have a circular reference UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-528 Both UPDM and SysML profiles must be applied UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-522 Resource subtypes UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-521 The diagram currently shows InformationElements when it should be showing DataElements UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-520 CapabilityConfiguration should be shown on this diagram. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-547 Artifact and Artefact UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-546 ConceptualDataModel just sits in the MODAF package and isn't connected to anything UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-545 ActualProjectMilestone need association link UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-537 Annex C diagrams need fixing UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-536 Annex C Figure 284 has invalid stereotype UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-535 Post constraints are reversed UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-544 UsedConfiguraton is misspelled UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-543 Missing NeedlineExchange meta-constraint UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-496 The ActualOrganizationPart stereotype should be called ActualOrganizationRole. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-495 We shouldn't connect ActualOrganizationRelationship to ResourceInteractions with a realize tag. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-494 ActualOrganizationRelationship UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-500 Currently all UPDM ports have no ability to connect UPDM connectors - Needline, ResourceInterface. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-499 stereotypedRelationship between Function and OperationalActivity UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-498 ActualOrganizationPart stereotype should be connected to OrganizationPart abstract stereotype for the definingFeature UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-497 The OrganizationPart abstract stereotype should be called OrganizationRole UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-503 The metaConstraint between ResourceInterface and ResourceType should have a "/" on the front of "endType" UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-502 Section 5.1 text is out of context UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-501 Issue with SV-9 UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-513 The metaConstraint with the umlRole "ownedElement" is wrong UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-512 The metaConstraint with the umlRole "ownedElement" is wrong UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-511 RealizesCapability used to be a Realization but for some reason has been changed UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-519 CapabilityConfiguration should be shown on this diagram. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-518 The umlRole "conveyedElement" between ResourceInteraction and ResourceInteractionItem is wrong UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-517 We should show ServiceInterface on the SV-1 as the "type" for the Service and Request ports UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-510 ServiceInteraction is currently extending Interface when it should be extending Interaction UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-509 ServiceParameter needs to be shown on this diagram. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-508 The Entity, Attribute and EntityRelationship stereotypes are in the wrong Package UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-516 The stereotypedRelationship "realizesCapability" should be show fully on the diagram UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-515 The metaConstraint to ServiceParameter from ServiceFunction should be shown on diagram UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-514 FunctionEdge should be removed from the diagram as it won't be shown in this view. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-507 Don't see the point in OperationalActivity having a StateMachine UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-506 add the missing metaConstraints UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-505 The metaConstraints from Commands to OrganizationalResource have invalid umlRoles UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-504 The metaConstraint between Commands and DataElement has an incorrect umlRole UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-481 need to change the roles to represent client and supplier UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-480 Project should be called ActualProject as it's an Instance UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-479 OperationalNodeSpecification UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-478 CapabilityRequirementCapability is duplicated UPDM 1.0b1 open
UPDM-489 The Realization relationship between ResourceType and Node should be stereotyped. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-488 ResourceType should be called Resource. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-491 The metaConstraint between Needline and Node should have a "/" on the front of "endType". UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-490 KnownResources as well as NodeRoles should be connectable to Needlines UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-487 ActualLocation should be called PhysicalLocation. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-486 ItemInConcept should be called ConceptRole. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-483 metaConstraint between EnterprisePhase and Mission should have its umlRole set to ownedUseCase UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-482 Enterprise should be called WholeLifeEnterprise. UPDM 1.0b1 UPDM 1.0 Resolved closed
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-493 OrganizationType should be called Organization. UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-492 The diagram should show the relationship between UPDMElement and ActualMeasurementSet UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-485 ItemInConcept shouldn't be abstract UPDM 1.0b1 UPDM 1.0 Resolved closed
UPDM-484 DefinesArchitecture should be a Realization UPDM 1.0b1 UPDM 1.0 Resolved closed
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
UPDM2-50 Remove SystemConnector from Spec UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-49 IndividualPersonRole is missing from the spec, but has references to it UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM-13 SysML stereotype references in the UPDM specification need to be updated UPDM 1.0b1 open
UPDM2-51 Mislabeled Figure B.9 OV-3 should be OV-2. UPDM 2.0 UPDM 2.0.1 Resolved closed
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-32 properties of EnterprisePhase are wrongly named UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-31 Performer is defined both as an alias and a specialization of Node UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-48 Section on GeoPoliticalExtentTypeKind is missing UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-47 Details is missing, even though there are references to it UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-46 Resource has been changed to SystemResource UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-34 Activity is an abstract element, it should be concrete UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-33 By having Exchange Element as a Datatype there is not possible to define the State Machine for it UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-36 DoDAF users are upset using MODAFRoleKind property on the ResourceRole UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-35 Remove model libraries from UPDM 2.0 profile structure UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-39 Conflicting PV-3 diagrams for DMM and Profile UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-38 Missing sequencing capability for DoDAF Project Activities UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-43 ExchangeItem has been deleted from UPDM and should not be in the document UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-42 ActualProperty definition missing from document UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-45 Service message has the wrong graphic UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-44 PropertyValue should be removed from the UPDM Document UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-41 Incorrect SV-4 DMM Diagram UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-40 Incorrect AV-1 DMM Diagram UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-37 Confusion in type for Project status UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-20 Figure 8.8. uses <> incorrectly UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-19 "Include DoDAF 2.02 Conformance Level Three (L3) Statement" UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-13 It's very odd and counter-intuitive to have UPDM L0 buried in UPDM L1 UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-12 Document still references DoDAF v1.5, when it should reference DoDAF V2.02 UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-25 UPDM stereotype name conflict UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-24 Instance value and slot use in all UPDM elements that extend InstanceSpecification UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-23 ResourceConnector.realizedExchange does not have a programmable direction or other context specific data UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-28 change stereotype extensions (base_*) marked as "private" to "public" UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-27 Attribute URI/URL should be renamed and made optional UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-26 some properties are wrongly marked as mandatory UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-22 Need non-nomative profiles for NAF. DODAF and MODAF views and viewpoints UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-21 Concern needs to be added to the AV-1 UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-18 The namespace to use for UPDM is unclear due to inconsistent values UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-17 wrong document reference UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-16 Section 8.2.1 UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-11 Need to add a conforms to relationship for an element of type Interface to be able to associate a standard with it UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-10 Incorrect acknowledgement UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-30 No definition for PhysicalResource UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-29 Missing TOC entries UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-15 Section 2.1.2 UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-14 2.1.1: typo: it has RequiresPoint which does not exist in SoaML and I UPDM 2.0 UPDM 2.0.1 Resolved closed
UPDM2-9 The ISO8601:2004 is probably a normative reference and should be placed in section 3 UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-8 8.2.1.1.3 and 8.2.1.1.3.1 define ISO8601DateTime UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-7 Increment and out of service milestones do not pair UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-4 It's not possible to show that a resource configuration realizes two or more capabilities at different periods of time UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-3 Broken link for issue reporting UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-6 capability to assign actual organizational resources to a project in a particular time frame missing UPDM 1.1 UPDM 2.0.1 Resolved closed
UPDM2-5 Project Sequence should have a tag Sequence Kind UPDM 1.1 UPDM 2.0.1 Resolved closed
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
UPDM11-30 Fix TM symbol in Trademarks UPDM 1.0.1 UPDM 1.1 Resolved closed
UPDM11-29 Need to add contents to DoDAF class library section of the specification UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-28 Add descriptions to a number of subsections UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-25 Add DoDAF class library diagram UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-24 Add Diagrams to show non-normative mapping of UPDM elements to views UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-27 There are two diagrams named project. It affects both Projects: core and the DoDAF one UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-26 Add SWAF and SOPES section to DMM section UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-23 Add Diagrams to show UPDM elements that are scoped to DoDAF 2.0 diagrams UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-8 DoDAF Conformance Level Two. Defer PES & Temporal-Whole-Part UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-1 Update Statements of Support from DoD and MOD UPDM 1.0 UPDM 1.1 Resolved closed
UPDM2-1 Update Annex C for DoDAF 2.02 UPDM 1.0 open
UPDM11-6 Add DM2 DoDAF Meta Model to Abbreviations UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-5 Publish UPDM Domain MetaModel to DoDAF MetaModel Compliance Matrix UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-10 Merge project/milestone concepts in DoDAF/MoDAF to be complementary to each other UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-9 Add DMM-DM2 Matrix to Conformance Statement UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-7 "6.2.2 Organization of this Specification" is OBSOLETE UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-3 format of submitted XMI is proprietary XML UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-2 Unified Profile for the Department of Defense Architecture Framework (DoDAF) and the UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-4 DoDAF Normative Reference and Bibliography UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-12 Simplify resources model UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-11 Combine SOAML. DoD Services and MODAF services properly UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-22 Missing DesiredEffects in UPDM UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-21 Modify relationship between EntityItems and ExchangeElements UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-15 Add cosntructs for naming and representation where required UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-14 Simplify measurements model UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-18 Add NAF to list of ArchitectureFrameworkKind UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-17 Rename “Element” to “UPDMElement” UPDM 1.0 UPDM 1.1 Resolved closed
UPDM2-2 Update L1 and L0 diagram align with current MM UPDM 1.0 UPDM 2.0 Resolved closed
UPDM11-13 Simplify Location model from DM2 UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-19 Added ProjectMilestoneRole UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-20 Update SysML mapping and OCL UPDM 1.0 UPDM 1.1 Resolved closed
UPDM11-16 Missing security attributes group from DM2 UPDM 1.0 UPDM 1.1 Resolved closed

Issues Descriptions

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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 GMT
  • Attachments:

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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 GMT

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: Thu, 11 Apr 2024 13:10 GMT

Figure is a little grainy.

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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 GMT

Mapping to DM2 higher level elements:

  • Key: UPDMRTF-4
  • Legacy Issue Number: 17278
  • Status: open  
  • Source: Syntell AB ( Mr 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 GMT

Figure 7.8: <> should be changed to <>

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

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

  • Reported: UPDM 2.0 — Thu, 1 Mar 2012 05:00 GMT
  • Updated: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 GMT

Use of superSubType, wholePart and WholePartType in DoDAF 2

  • Key: UPDMRTF-5
  • Legacy Issue Number: 17290
  • Status: open  
  • Source: Syntell AB ( Mr 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: Thu, 11 Apr 2024 13:10 GMT

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

  • Key: UPDMRTF-6
  • Legacy Issue Number: 17310
  • Status: open  
  • Source: Dassault Systemes ( Mr. 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 GMT

Specification lacks Hyperlinks for references to Model Element Names

  • Key: UPDMRTF-1
  • Status: open  
  • Source: InterCAX ( Mr. 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 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 ( Mrs. Laura E. 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: Thu, 11 Apr 2024 13:10 GMT

Implements Relationship between Exchange Elements

  • Key: UPDMRTF-14
  • Legacy Issue Number: 18580
  • Status: open  
  • Source: Dassault Systemes ( Dr. 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: Thu, 11 Apr 2024 13:10 GMT

Simplify measurements in UPDM

  • Key: UPDMRTF-11
  • Legacy Issue Number: 18573
  • Status: open  
  • Source: MITRE ( Dr. 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: Thu, 11 Apr 2024 13:10 GMT

System and PhysicalArchitecture are siblings not descendants

  • Key: UPDMRTF-18
  • Legacy Issue Number: 18708
  • Status: open  
  • Source: InterCAX ( Mr. 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: Thu, 11 Apr 2024 13:10 GMT

UPDM DoDAF lacks a concept for Service Orchestration

  • Key: UPDMRTF-16
  • Legacy Issue Number: 18688
  • Status: open  
  • Source: InterCAX ( Mr. 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: Thu, 11 Apr 2024 13:10 GMT

Integrate SysML Requirements and Constraints

  • Key: UPDMRTF-17
  • Legacy Issue Number: 18691
  • Status: open  
  • Source: InterCAX ( Mr. 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: Thu, 11 Apr 2024 13:10 GMT

Need of Logical and Physical Services

  • Key: UPDMRTF-13
  • Legacy Issue Number: 18579
  • Status: open  
  • Source: Dassault Systemes ( Dr. 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: Thu, 11 Apr 2024 13:10 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 ( Mr. 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: Thu, 11 Apr 2024 13:10 GMT

ProjectSequence is too Restrictive

  • Key: UPDMRTF-19
  • Legacy Issue Number: 18718
  • Status: open  
  • Source: InterCAX ( Mr. 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 GMT

The <> stereotype and its properties

  • Key: UPDMRTF-20
  • Legacy Issue Number: 18725
  • Status: open  
  • Source: PTC ( Mr. 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: Thu, 11 Apr 2024 13:10 GMT

MapsToCapability relationship is too Restrictive, and ActivityPartOfCapability is redundant

  • Key: UPDMRTF-21
  • Legacy Issue Number: 18738
  • Status: open  
  • Source: MITRE ( Dr. 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: Thu, 11 Apr 2024 13:10 GMT

CV6, CV-7 and NSOV-3

  • Key: UPDMRTF-24
  • Legacy Issue Number: 18741
  • Status: open  
  • Source: MITRE ( Dr. 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: Thu, 11 Apr 2024 13:10 GMT

use of Generalization to implement Aliasing

  • Key: UPDMRTF-22
  • Legacy Issue Number: 18739
  • Status: open  
  • Source: MITRE ( Dr. 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: Thu, 11 Apr 2024 13:10 GMT

Use of Actual vs. Type in PV-1

  • Key: UPDMRTF-23
  • Legacy Issue Number: 18740
  • Status: open  
  • Source: MITRE ( Dr. 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: Thu, 11 Apr 2024 13:10 GMT

Subject of a State Machine

  • Key: UPDMRTF-25
  • Legacy Issue Number: 18742
  • Status: open  
  • Source: MITRE ( Dr. 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: Thu, 11 Apr 2024 13:10 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 ( Dr. 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: Thu, 11 Apr 2024 13:10 GMT

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

  • Key: UPDMRTF-31
  • Legacy Issue Number: 18843
  • Status: open  
  • Source: MITRE ( Dr. 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: Thu, 11 Apr 2024 13:10 GMT

Information flow instantiation

  • Key: UPDMRTF-29
  • Legacy Issue Number: 18841
  • Status: open  
  • Source: MITRE ( Dr. 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: Thu, 11 Apr 2024 13:10 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 ( Dr. 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: Thu, 11 Apr 2024 13:10 GMT

Need of Composition between Enterprise Goals

  • Key: UPDMRTF-26
  • Legacy Issue Number: 18785
  • Status: open  
  • Source: Dassault Systemes ( Dr. 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: Thu, 11 Apr 2024 13:10 GMT

Why is EnterprisePhase to EnterpriseVision a one to one relationship

  • Key: UPDMRTF-27
  • Legacy Issue Number: 18839
  • Status: open  
  • Source: MITRE ( Dr. 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: Thu, 11 Apr 2024 13:10 GMT

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

  • Key: UPDMRTF-32
  • Legacy Issue Number: 18844
  • Status: open  
  • Source: MITRE ( Dr. 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 GMT

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

  • Key: UPDMRTF-33
  • Legacy Issue Number: 18845
  • Status: open  
  • Source: MITRE ( Dr. 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: Thu, 11 Apr 2024 13:10 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: Thu, 11 Apr 2024 13:10 GMT

Profile and Tooling should enforce the Proper Specification of Capabilities

  • Key: UPDMRTF-37
  • Status: open  
  • Source: InterCAX ( Mr. 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: Thu, 11 Apr 2024 13:10 GMT

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

  • Key: UPDMRTF-38
  • Status: open  
  • Source: InterCAX ( Mr. 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: Thu, 11 Apr 2024 13:10 GMT

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

  • Key: UPDMRTF-39
  • Status: open  
  • Source: InterCAX ( Mr. 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: Thu, 11 Apr 2024 13:10 GMT

Figure 8.1 Presents InformationAssuranceProperties Twice

  • Key: UPDMRTF-40
  • Status: open  
  • Source: InterCAX ( Mr. 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: Thu, 11 Apr 2024 13:10 GMT
  • Attachments:

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: Thu, 11 Apr 2024 13:10 GMT

Withdraw UDPM Spec

  • Key: UPDMRTF-42
  • Status: open  
  • Source: Aerospace Corporation ( Mr. 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: Thu, 11 Apr 2024 13:10 GMT

capability element should have a relation to sysml requirement type.

  • Key: UPDMRTF-146
  • Status: open   Implementation work Blocked
  • Source: MITRE ( Dr. 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

The element descriptions in Part II have no provision to explain stereotyped relationship

  • Key: UPDM-778
  • Legacy Issue Number: 13614
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Sun, 8 Mar 2015 22:06 GMT

SOAML missing from figure 2 and figure 3 in UPDM spec

  • Key: UPDM-777
  • Legacy Issue Number: 13874
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

  • Reported: UPDM 1.0b1 — Wed, 22 Apr 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    issue withdrawn by submitter
  • Updated: Sun, 8 Mar 2015 21:43 GMT

Annex A should start with the Layers section

  • Key: UPDM-776
  • Legacy Issue Number: 13638
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Sat, 7 Mar 2015 20:50 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

StrategicMission

  • Key: UPDM-775
  • Legacy Issue Number: 11974
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — UPDM 1.0
  • Disposition Summary:

    duplicate of 11973
  • Updated: Sat, 7 Mar 2015 20:48 GMT

Section: 7.3.2

  • Key: UPDM-774
  • Legacy Issue Number: 11350
  • Status: open  
  • Source: International Business Machines ( Mr. 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: Adaptive ( Mr. 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: Adaptive ( Mr. 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

UPDM XMI documents misnamed

  • Key: UPDM-771
  • Legacy Issue Number: 15380
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    There are two XMI documents listed for UPDM 1.0:

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

    and

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

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

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

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

  • Reported: UPDM 1.0 — Wed, 21 Jul 2010 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Will ensure XMI is named and submitted correctly

  • Updated: Fri, 6 Mar 2015 23:30 GMT

UPDM XMI contains properties with incorrect lower values

  • Key: UPDM-770
  • Legacy Issue Number: 15379
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

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

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

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

  • Reported: UPDM 1.0 — Wed, 21 Jul 2010 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 23:30 GMT

Need to change generalisation section text for all elements to be a specialisation

  • Key: UPDM2-52
  • Legacy Issue Number: 16222
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Need to change generalisation text for each element from

    original text format
    • Generalizations
    The following are generalization relationships for OrganizationalProjectRelationship:

    To, revised text format

    · Specializations

    The OrganizationalProjectRelationship element is a specialization of:

  • Reported: UPDM 1.1 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0
  • Disposition Summary:

    Rationale Correct text required
    Resolution Change format
  • Updated: Fri, 6 Mar 2015 23:15 GMT

Replace ActivityPerformableUnderCondition with a Tag

  • Key: UPDM2-53
  • Legacy Issue Number: 16223
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Replace ActivityPerformableUnderCondition with a Tag
  • Reported: UPDM 1.1 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0
  • Disposition Summary:

    Rationale Reduces the amount fo drawing required to create the
    tuple
    Resolution Created a tag with the same name on an Activity and
    typed by environment
  • Updated: Fri, 6 Mar 2015 23:15 GMT

Need to make SubSystemPart part of the DoDAF resources model

  • Key: UPDM-769
  • Legacy Issue Number: 15247
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Description:- To get the proper whole part relationship between System and SystemsNode there is a need for the SubSystemPart to be typed by System and made be able to make it a part of a SystemsNode. The current resources model does not support this unless using the MODAF resource elements
  • Reported: UPDM 1.0 — Wed, 5 May 2010 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Added DoDAF only element SystemPart in Profile and added description

  • Updated: Fri, 6 Mar 2015 23:15 GMT

no ability in UPDM to define internal flows to a system or node (inside a swim lane in OV-5 or Sv-4).

  • Key: UPDM-768
  • Legacy Issue Number: 15170
  • Status: closed  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

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

  • Reported: UPDM 1.0 — Fri, 9 Apr 2010 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Add text to OV-5/SV-4 to indicate that ObjectNodes can be used to show information flow between OperationalActivities and SystemFunctions.
  • Updated: Fri, 6 Mar 2015 23:15 GMT

Constraint to be fixed

  • Key: UPDM-767
  • Legacy Issue Number: 15148
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    ServiceOperation can be owned only by Resource or Node, but not by ServiceInterface.
    The constraint should be fixed
  • Reported: UPDM 1.0 — Wed, 24 Mar 2010 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Change constraint text on description of ServiceOperation

  • Updated: Fri, 6 Mar 2015 23:15 GMT

miswording on a number of diagram titles for products

  • Key: UPDM-766
  • Legacy Issue Number: 14987
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

    "elements relating to the XX-xx stereotype "

    to

    "elements relating to the XX-xx product "

    This is a minor issue

  • Reported: UPDM 1.0 — Mon, 18 Jan 2010 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    see pages 27 - 30 of OMG document dtc/2010-12-04
  • Updated: Fri, 6 Mar 2015 23:15 GMT

itemFlow stereotype

  • Key: UPDM-765
  • Legacy Issue Number: 14840
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UPDM 1.0 — Tue, 8 Dec 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 23:15 GMT

<> has tag called carriedExchange that is type of <>

  • Key: UPDM-761
  • Legacy Issue Number: 14624
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: UPDM 1.0 — Fri, 13 Nov 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 23:15 GMT

current UPDM documentation and XMI is not in line with the submitted SOAML XMI and documentation

  • Key: UPDM-763
  • Legacy Issue Number: 14812
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

  • Reported: UPDM 1.0 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 23:15 GMT

<>

  • Key: UPDM-762
  • Legacy Issue Number: 14625
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Dependant on the issue # 1, <<OperationalActivityEdge>> should know both,
    the Operational Exchanges that are realized by the
    <<OperationalActivityEdge>> and the Operational Exchange Items that are
    conveyed by the Operational Exchanges. The same is valid with the
    <<FunctionEdge>>, it should know both, the Resource Interactions that are
    realized by the <<FunctionEdge>> and the Resource Interaction Items that are
    conveyed by the Resource Interactions.
  • Reported: UPDM 1.0 — Fri, 13 Nov 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 23:15 GMT

Elements used by UPDM from SOAML are not the actual elements from the submitted SOAML XMI

  • Key: UPDM-764
  • Legacy Issue Number: 14813
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

  • Reported: UPDM 1.0 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Reference latest SoaML profile in UPDM profile in the model

  • Updated: Fri, 6 Mar 2015 23:15 GMT

OV-2 & StV-2 Capabilities & Nodes.

  • Key: UPDM-760
  • Legacy Issue Number: 13780
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution POTENTIAL SOLUTION:All UPDM Elements support measurements being attached to them - so what's requested in this issue is already supported. This can therefore be rejected.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    duplicate of issue13739, voted on in ballot 9
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Instances

  • Key: UPDM-759
  • Legacy Issue Number: 13773
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution This is a good idea but it doesn't seem to be essential. We will defer this to the next version of UPDM.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

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

Fig118

  • Key: UPDM-758
  • Legacy Issue Number: 13769
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution This isn't essential so we'll defer it to the next version of UPDM.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    This isn't essential so we'll defer it to the next version of UPDM.
    Took into account in UPDM 2.0
    .
    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 22:56 GMT

OV-7

  • Key: UPDM-757
  • Legacy Issue Number: 13754
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

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

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

7.1.1 - Naming of types and individuals.

  • Key: UPDM-756
  • Legacy Issue Number: 13721
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

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

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

All of the derived tags require the derivation documenting.

  • Key: UPDM-755
  • Legacy Issue Number: 13646
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale Currently the implementation isn't complete without it.
    Resolution: We'll add, as a minimum, a detailed description in English but if possible we will also include OCL.
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Add derivation rules next to attributes description
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Exchanges should be extended to allow Software and CapabilityConfigurations to be conveyed as well.

  • Key: UPDM-754
  • Legacy Issue Number: 13645
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale You cannot fully model the logistics of an architecture currently.
    Resolution TBD. Needs discussion
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

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

    The description for ConfigurationExchange will be: "CapabilityConfigurations that are exchanged between Nodes".
  • Updated: Fri, 6 Mar 2015 22:56 GMT

The split between Core, DoDAF and MODAF is not intuitive in certain places.

  • Key: UPDM-753
  • Legacy Issue Number: 13642
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

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

element descriptions

  • Key: UPDM-752
  • Legacy Issue Number: 13612
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

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

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

  • Updated: Fri, 6 Mar 2015 22:56 GMT

In DODAF, OperationalActivities and Nodes have level identifiers. Should we have a derived property for it?

  • Key: UPDM-748
  • Legacy Issue Number: 13583
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution: This would be very complicated to implement and describe as Nodes can now be used in different contexts at different levels. We'll defer this until after the FTF.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    This would be very complicated to implement and describe as Nodes can now be used in different contexts at different levels.
    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Test Enterprise.

  • Key: UPDM-747
  • Legacy Issue Number: 13572
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Rationale Testing in an interoperable environment is a great challenge because of the need to ensure security, compliance with DISA certifications and many other issues that require an architectural view to help execute.
    Resolution: This is outside the scope of UPDM 1.0 and can be looked at for the RFP for the next version of UPDM. Matthew to communicate with Frank and confirm the resolution.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

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

    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 22:56 GMT

inter-operability Requirements and Work Products Implementation

  • Key: UPDM-751
  • Legacy Issue Number: 13606
  • Status: closed  
  • Source: Infinity Technology Incorporated ( Dr. Sumeet S. Malhotra)
  • Summary:

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

    Source Sumeet Malhotra
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Will be considered for UPDM 2.0 documentation as it goes beyond the work of this group.
    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 22:56 GMT

create detailed step-by-step examples

  • Key: UPDM-750
  • Legacy Issue Number: 13605
  • Status: closed  
  • Source: Infinity Technology Incorporated ( Dr. Sumeet S. Malhotra)
  • Summary:

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

    Source Sumeet Malhotra
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

    Supported by proprietary tool training and example models from the tool vendors
    Will be considered for UPDM 2.0
    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 22:56 GMT

LogicalArchitecture - PhysicalArchitecture

  • Key: UPDM-749
  • Legacy Issue Number: 13597
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Resolution: Add an abstract context element, that supertypes LogicalContext, PhysicalContext add StrategicContext in UPDM1.1 Consider tuple for relating physical and logicalAction-Architecture teamDefer to UPDM 1.1
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

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

    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 22:56 GMT

ResourceRole specializations really need simplifying and made compliant with our naming convention

  • Key: UPDM-746
  • Legacy Issue Number: 13557
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale The current implementation is too specific and complicated for the Core package.
    Resolution: Evaluate the complexity of the issue, action on Ron/Wally/Moe to build sample SV-1 structurePotentially should be deferred until after the FTF.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

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

SubOrganization and Post should be removed and OrganizationRole made concrete in the core

  • Key: UPDM-745
  • Legacy Issue Number: 13552
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale This will simplify the profile and help to maintain the naming convention we agreed upon.
    Resolution: Evaluate the complexity of the issue, action on Action-Ron/Wally to build sample Organisation structure in SV-1/OV-4sWe will implement the change identified in the Issue column at the same time as [UPDM_00021].
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0.1
  • Disposition Summary:

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

Current navigability is wrong

  • Key: UPDM-744
  • Legacy Issue Number: 11783
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    closed issue, withdrawn by submitter
  • Updated: Fri, 6 Mar 2015 22:56 GMT

UPDM Issue: Derived tag updates

  • Key: UPDM-743
  • Legacy Issue Number: 13907
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

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

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

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

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

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

    · Remove the ResourceRole.owningResource tag – it’s duplicating a UML role and provides no useful purpose
  • Reported: UPDM 1.0b1 — Wed, 29 Apr 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Make the suggested changes
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Constraints between FunctionAction and FunctionEdge are too limiting

  • Key: UPDM-742
  • Legacy Issue Number: 13906
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Constraints between FunctionAction and FunctionEdge are too limiting
  • Reported: UPDM 1.0b1 — Wed, 29 Apr 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Remove the constraints. Make it consistent with OVs
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add DataElement as SubjectOfResourceStateMachine.

  • Key: UPDM-738
  • Legacy Issue Number: 13877
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com
  • Reported: UPDM 1.0b1 — Tue, 28 Apr 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Make DataElement a specialization of SubjectOfResourceStateMachine
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add the ability for Node to own ServiceOperations

  • Key: UPDM-737
  • Legacy Issue Number: 13876
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com
  • Reported: UPDM 1.0b1 — Tue, 28 Apr 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Add a constraint to ServiceOperation to specify owner. Remove the constraint from Resource, since it was forcing it to be the only owner of ServiceOperation
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Resource property "actsUpon" needs to be changed

  • Key: UPDM-736
  • Legacy Issue Number: 13875
  • Status: closed  
  • Source: Atego ( Paul Whiston)
  • Summary:

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

    Source Andrius Strazdauskas No Magicandriuss@nomagic.com

    Resolution Change the name to functionsUpon.
  • Reported: UPDM 1.0b1 — Tue, 28 Apr 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change the name to functionsUpon
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DMM and Profile are not synchronized

  • Key: UPDM-741
  • Legacy Issue Number: 13887
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    DMM and Profile are not synchronized
  • Reported: UPDM 1.0b1 — Tue, 28 Apr 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    The DMM will be updated to reflect the current profile.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

InformationElement/EntityItem

  • Key: UPDM-740
  • Legacy Issue Number: 13879
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    The current connection between InformationElement and EntityItem is broken (since both a Classes, there is no "represented" anymore)"
  • Reported: UPDM 1.0b1 — Thu, 23 Apr 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Create association between InformationElement and EntityItem.
    Make the association between DataElement and EntityItem bidirectional.
    Change the association end names
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SoaML integration

  • Key: UPDM-739
  • Legacy Issue Number: 13878
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Some Service elements have to be substituted with SoaML elements
  • Reported: UPDM 1.0b1 — Tue, 28 Apr 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Make Capability a specialization of SoaML::Capability
    Make ServiceInterface a specialization of SoaML::ServiceInterface
    Reuse SoaML::ServicePoint instead of Service
    Reuse SoaML::RequestPoint instead of Request
    Reuse SoaML::Expose to link Capabilities to ServiceInterfaces
  • Updated: Fri, 6 Mar 2015 20:59 GMT

MODAF Re-Use

  • Key: UPDM-730
  • Legacy Issue Number: 13783
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

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

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

MODAF Definitions

  • Key: UPDM-729
  • Legacy Issue Number: 13782
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Remove definition of UPDM models and then map to M3 and DoDAF element
    Merge with UPDM_00275/OMG 13784
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Performer & Activity

  • Key: UPDM-728
  • Legacy Issue Number: 13781
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution POTENTIAL SOLUTION:Peformer and Activity are in UPDM as placeholders for the inclusion of DoDAF 2.0 at a later date (i.e. in a new version). If there are constraints already added to Peforms that limits the client and supplier pairs then this issue can be set to rejected. If not, then we need to add the missing constraints.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Required & Actual

  • Key: UPDM-727
  • Legacy Issue Number: 13779
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution POTENTIAL SOLUTION:Within the UPDM group, we understand that the OV is used for defining an abstract representation of the architecture and the SV is used for defining the actual, physical architecture. If the documentation is misleading on this it must be updated. We should ask Ian for some specific examples where he's found the documentation to be misleading.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Within the UPDM group, we understand that the OV is used for defining an abstract representation of the architecture and the SV is used for defining the actual, physical architecture.
    Both OV and SV can be required or actual, As-is or to- be. This needs to be added to the documentation.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ProtocolImplementation

  • Key: UPDM-726
  • Legacy Issue Number: 13778
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution This matches the MODAF 1.2 specification (SystemPortConnector is a specialization of ProtocolImplementation).
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig134 Artifact [FacilityType?]

  • Key: UPDM-721
  • Legacy Issue Number: 13772
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Andrius to investigate where the facilityType tag came from (possibly a DoDAF requirement).
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Resolution:
    facilityType attribute is removed.
    Facility stereotype (subtype of Resource) is added.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig129

  • Key: UPDM-720
  • Legacy Issue Number: 13771
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

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

  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Remove ServiceInterface as possible client for RealizesCapability
  • Updated: Fri, 6 Mar 2015 20:59 GMT

StV-6

  • Key: UPDM-719
  • Legacy Issue Number: 13770
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Remove OperationalActivity from the StV-6 product diagram and change the text for StV-6 to remove all references to OperationalActivities.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Remove OperationalActivity from the StV-6 product diagram and change the text for StV-6 to remove all references to OperationalActivities.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SV-2 Missing

  • Key: UPDM-732
  • Legacy Issue Number: 13785
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Though this is supported in UPDM, it isn't very obvious. We will make the following changes:Add a new ResourceConnector relationship to go between ResourcePorts.Change ResourceInterfaces to only go between Resources/ResourceRoles (i.e. not Ports).Add a tag to ResourceConnector and ResourceInterface to show which ResourceConnectors "realize" which ResourceInterface. (i.e. add a bi-directional association between the stereotypes)
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Add a new ResourceConnector[Connector] relationship to go between ResourcePorts.
    Add a tag to ResourceConnector and ResourceInterface to show which ResourceConnectors "realize" which ResourceInterface. (i.e. add a bi-directional association between the stereotypes)
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Documentation

  • Key: UPDM-731
  • Legacy Issue Number: 13784
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    The descriptions were updated to reflect consistent and coherence definitions.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

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

  • Key: UPDM-735
  • Legacy Issue Number: 13805
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

  • Reported: UPDM 1.0b1 — Thu, 19 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Merge with UPDM_00275/OMG 13784
  • Updated: Fri, 6 Mar 2015 20:59 GMT

InformationTechnologyStandardCategory

  • Key: UPDM-734
  • Legacy Issue Number: 13787
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution It looks like a copy and paste error has occurred so we'll remove it.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    It looks like a copy and paste error has occurred so we'll remove it.
    Remove InformationTechnologyStandardCategory on OperationalConstraint or ResourceConstraint.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SubjectOfOperationalConstraint

  • Key: UPDM-733
  • Legacy Issue Number: 13786
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Tools

    Rationale This is more consistent with SubjectOfResourceConstraint and makes more sense (EntityItems can be OV and SV).
    Resolution POTENTIAL SOLUTION:Remove EntityItem as a specialization of SubjectOfOperationalConstraint and make InformationElement a specialization instead?
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Remove EntityItem as a specialization of SubjectOfOperationalConstraint and make InformationElement a specialization instead.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SV-12 Description

  • Key: UPDM-723
  • Legacy Issue Number: 13775
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Update the description to replace the references to CapabilityConfiguration with references to Resource.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Update the description to replace the references to CapabilityConfiguration with references to Resource.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig139 InternalDataModel

  • Key: UPDM-722
  • Legacy Issue Number: 13774
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution PhysicalDataModel only exists in MODAF, whereas InternalDataModel only exists in DoDAF.We'll rename InternalDataModel to PhysicalDataModel and then create a new DoDAF alias for InternalDataModel.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    PhysicalDataModel only exists in MODAF, whereas InternalDataModel only exists in DoDAF.
    We'll rename InternalDataModel to PhysicalDataModel and then create a new DoDAF alias for InternalDataModel.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

EnterpriseGoal-Capability

  • Key: UPDM-718
  • Legacy Issue Number: 13768
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Sounds sensible but not essential. We will defer this to the next version of UPDM.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

EnterpriseGoal

  • Key: UPDM-717
  • Legacy Issue Number: 13767
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution We will leave it where it is so that EnterpriseGoals can be used as part of multiple EnterpriseVisions.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig141

  • Key: UPDM-724
  • Legacy Issue Number: 13776
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Current thinking is that if Resource/Energy flow is allowed on the SV-1, it should also be allowed on the SV-2 - otherwise you loose the ability to have ports showing non-data flow.Talk to Ian to clarifiy.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Add a constraint for ResourceInteraction, specifying that "realization" property values have to be stereotyped by ResourceInterface.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig143 FunctionParameter

  • Key: UPDM-725
  • Legacy Issue Number: 13777
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution This is a UML implementation stereotype so that the inputs and outputs of Functions can be constrained and therefore mapped to the structural constraints on Ports, etc.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig45 - NodeChild.

  • Key: UPDM-702
  • Legacy Issue Number: 13750
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Limit KnownResource to only be owned by a LogicalArchitecture.This seems very limiting and doesn't support DoDAF - which seems to allow OperationalRoles (the equivalent of KnownResources) inside Nodes. Either KnownResource should be removed altogether, or they should be allowed to be owned by Nodes. Since it's required for DoDAF and seems to be quite an important concept, we will leave it as it is.To support this decision, we'll add some text to KnownResource to make it clear that in MODAF you should limit these to only being owned by LogicalArchitectures (though we should also raise an issue on MODAF to change this too).
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

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

    Documentation updated
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 37 - SOA

  • Key: UPDM-701
  • Legacy Issue Number: 13749
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    We will add Service and Request ports to Nodes.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig44 - NodePort.

  • Key: UPDM-700
  • Legacy Issue Number: 13748
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution NodePorts are required for people trying to use a SysML approach in conjunction with UPDM. We should document that the NodePorts don't have to be used and they're there to provide a more detailed view if it's required.Another reason to include them is that they were specifically requested as a TRADOC requirement.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Node port removed from OV-2
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig44 - ExternalNode.

  • Key: UPDM-699
  • Legacy Issue Number: 13747
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Remove the stereotype as not required by DoDAF or MODAF.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    ExternalNode moved to DoDAF-only elements
  • Updated: Fri, 6 Mar 2015 20:59 GMT

7.1.4.1.1 Operational Activity Definition

  • Key: UPDM-706
  • Legacy Issue Number: 13755
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Update the description as specified.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Update the description as specified.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig53 - Logical & Physical

  • Key: UPDM-705
  • Legacy Issue Number: 13753
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution With the current UPDM implementation, if an Entity created in the OV is exactly the same in the SV, it can be reused (i.e. connected to an InformationElement and a DataElement). If we add subtypes to Entity as suggested, we will be forcing users to create duplicate Entities just because they're in different places. This seems to be too useful to remove at the moment.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig51 - Mission & States

  • Key: UPDM-704
  • Legacy Issue Number: 13752
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Ian BaileyModel Futuresian@modelfutures.com

    Since we are moving Mission into the DoDAF Only section, this doesn't effect a MODAF implementation (see [UPDM_00216 / OMG Issue <tbd>]). For this reason, we'll leave Mission with the ability to have StateMachines.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig51 - Entity SubjectOfOperationalState

  • Key: UPDM-703
  • Legacy Issue Number: 13751
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution POTENTIAL SOLUTION:This is how it's modelled in MODAF 1.2. We'll request clarification from Ian Bailey before we decide to change this or not.The Entity has a continuous lifecycle which can be captured as a State. The current feeling is to leave it as it is.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Remove generalization between Entity and SubjectOfOperationalStateMachine.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

7.1.4.4.10 Mission

  • Key: UPDM-710
  • Legacy Issue Number: 13759
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Ensure that all tags, etc, which relate to Mission have a cardinality that is 0..n, to ensure that they're optional.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Ensure that all tags, etc, which relate to Mission have a cardinality that is 0..n, to ensure that they're optional.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

7.1.4.4.6 HighLevelOperationalConcept

  • Key: UPDM-709
  • Legacy Issue Number: 13758
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution This was deemed to be implementation specific (as each tool vendor will support this in a different way). We should document this somewhere in the specification and remove the reference to the non-existent tag.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    This was deemed to be implementation specific (as each tool vendor will support this in a different way).
    We should document this somewhere in the specification and remove the reference to the non-existent tag.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Needlines & Non-Information

  • Key: UPDM-708
  • Legacy Issue Number: 13757
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution People from the DoD have seen this and haven't come back with any issues about it. People have the option of using them or not using them - processes can be defined by organizations to determine which aspects of UPDM to use.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

7.1.4.1.1 Tags on OperationalActivity

  • Key: UPDM-707
  • Legacy Issue Number: 13756
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution The tags are derived so there's no need for any constraints (they're populated dynamically).
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Top of Page 37 - "an OV-2 diagram (now OV-2a)"

  • Key: UPDM-698
  • Legacy Issue Number: 13746
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Remove the incorrect text.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Remove the incorrect text.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Top of Page 37

  • Key: UPDM-697
  • Legacy Issue Number: 13745
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Remove the incorrect text.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Remove the incorrect text.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig44 - RequiresCapability

  • Key: UPDM-696
  • Legacy Issue Number: 13744
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution POTENTIAL SOLUTION:Change the name of the stereotype (if it doesn't become merged as part of [UPDM_00098 / OMG Issue 13580]).
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change the name of the stereotype

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig44 - NodeType

  • Key: UPDM-695
  • Legacy Issue Number: 13743
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution POTENTIAL SOLUTION:MODAF::Node is equivalent to UPDM::NodeRole and MODAF::NodeType is equivalent to UPDM::Node. We should consider adding a MODAF mapping table or more aliases, as the name changes seem to have thrown some people.We will consult with the other architects, etc.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    MODAF::NodeType is UPDM::Node. Mapping table needs to be updated
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OV-4 - Person

  • Key: UPDM-713
  • Legacy Issue Number: 13763
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution The concept is what I originally thought ActualPost was for - so I can understand why people may want to mode this. However, a Person shouldn't be a part, it should be an Instance - though I've no idea what you'd instantiate (Post wouldn't make sense). This is too complicated to implement now so we should defer to the next version of UPDM.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig 91 - OrganizationalExchange

  • Key: UPDM-712
  • Legacy Issue Number: 13762
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Though the name has changed (i.e. now called MovementOfPeople) the relationship still exists in MODAF 1.2. Also, we don't want to reuse SV flows on the OV-2.We should add an alias called MovementOfPeople (as a specialization of OrganizationalExchange) to be consistent with MODAF though.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

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

7.1.4.4.11 Needline

  • Key: UPDM-711
  • Legacy Issue Number: 13761
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Change the UPDM description as specified.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change the UPDM description as specified.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

7.1.5.2.2 Service

  • Key: UPDM-716
  • Legacy Issue Number: 13766
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution The concept of ServicePort is covered by the SOAML Service, so the description was mapped across. We should tweak the description to make it more obvious that the two are the same.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

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

7.1.5.2.1 Request

  • Key: UPDM-715
  • Legacy Issue Number: 13765
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Change the description to match the SOAML description. We should look at changing this to a summary and a reference to the SOAML specification at a later date.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change the description to match the SOAML description. We should look at changing this to a summary and a reference to the SOAML specification at a later date.
    Merged with issue OMG 13878
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig104 - ServiceFunction

  • Key: UPDM-714
  • Legacy Issue Number: 13764
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Phil to have a more detailed look at this.
  • Reported: UPDM 1.0b1 — Tue, 17 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 44 - Title

  • Key: UPDM-694
  • Legacy Issue Number: 13742
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

7.1.2.5.3 - Measures

  • Key: UPDM-693
  • Legacy Issue Number: 13741
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Talk to Ian to explain the SysML mapping and potentially update the document to make this clearer.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    The sample problem has been updated to make use of Value Types, Units, Dimensions, and SysML Parametrics.
    Revised Text:
    See 13386.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

7.1.2.5.1 - ActualMeasurement.

  • Key: UPDM-692
  • Legacy Issue Number: 13740
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Review and update the description as required.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Merged with UPDM_00275/ OMG 13784
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig21 - SameAs.

  • Key: UPDM-690
  • Legacy Issue Number: 13738
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Resolution This isn't clear in MODAF 1.2 so if we fix this in UPDM we should also raise an issue on MODAF.We'll change the metaConstraint so that the "supplier" role is constrained to ExternalType/ExternalIndividual instead of UPDMElement. The "client " role will stay constrained to UPDMElement.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    This isn't clear in MODAF 1.2 so if we fix this in UPDM we should also raise an issue on MODAF.
    We'll change the metaConstraint so that the "supplier" role is constrained to ExternalType/ExternalIndividual instead of UPDMElement. The "client " role will stay constrained to UPDMElement.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig20 - AV3?

  • Key: UPDM-689
  • Legacy Issue Number: 13737
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    The AV-3 is used to define ActualMeasurementSets/MeasurementSets as it appeared to be missing from MODAF. MODAF supports the addition of custom views and the views in UPDM are non-normative, so this isn't seen as an issue.
    Info from Ian suggests that we will get pushback from US Army,
    Remove term AV-3 and replace with Measurements

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig27 & Fig28 & Fig29 - Climate, etc.

  • Key: UPDM-691
  • Legacy Issue Number: 13739
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution POTENTIAL SOLUTION:Find out what the problem is…
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Add 2 new constraints:
    "ExhibitsCapability"
    For every Capability related "required" ActualMeasurementSet, there must be a matching Node related "estimate"/"result" ActualMeasurementSet. The term "matching" is used to mean the classifier for the ActualMeasurementSets must be the same or a specialization.

    "RealizesCapability"
    For every Capability related "required" ActualMeasurementSet, there must be a matching Resource related "estimate"/"result" ActualMeasurementSet. The term "matching" is used to mean the classifier for the ActualMeasurementSets must be the same or a specialization.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ensure that constraints are placed on the combination of Project, ProjectMilestone and ProjectThemeStatus

  • Key: UPDM-676
  • Legacy Issue Number: 13650
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale The current approach is so loose that nothing useful could be generated from the model data.
    Resolution: Each Project should only have one association to a ProjectMilestone, and each ProjectMilestone should have ProjectThemes that are all connected to the same ProjectThemeStatus. This means that each type of Project will use the same ProjectThemes (e.g. Lines Of Developments) and the same statuses (e.g. colour codes, etc).
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Each Project should only have one association to a ProjectMilestone, and each ProjectMilestone should have ProjectThemes that are all connected to the same ProjectThemeStatus. This means that each type of Project will use the same ProjectThemes (e.g. Lines Of Developments) and the same statuses (e.g. colour codes, etc).
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Rename NeedlineExchange to OperationalExchange

  • Key: UPDM-675
  • Legacy Issue Number: 13649
  • Status: closed  
  • Source: Atego ( Paul Whiston)
  • Summary:

    Rename NeedlineExchange to OperationalExchange

  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    As per the Issue.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Association between OperationalActivityEdge and NeedlineExchange should be reversed

  • Key: UPDM-674
  • Legacy Issue Number: 13648
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Association between OperationalActivityEdge and NeedlineExchange should be reversed.
    It should be connected to OperationalExchange, not InformationExchange
    Diagram
    Document Issue UPDM (OMG Beta) Jan 2009
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Reverse the association between OperationalActivityEdge and InformationExchange. Change the end from InformationExchange to OperationalExchange

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Milestones

  • Key: UPDM-673
  • Legacy Issue Number: 13647
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

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

    Allow milestones to connect to any resource and change the stereotype names and tags appropriately. If [UPDM_00199] gets agreed upon then ActualProjectMilestone should also be related to all Resources too.
    Change names for ConfigurationNoLongerUsed and ConfigurationDeployed to NoLongerUsedMilestone and DeployedMilestone
    Change CapabilityIncrementMilestone to IncrementMilestone
    Add Retirement (DoDAF) Alias to OutOfService
    Action-Architecture team
    Allow milestones to connect to any resource and change the stereotype names and tags appropriately. If [UPDM_00199] gets agreed upon then ActualProjectMilestone should also be related to all Resources too.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Change InformationElement to extend Class. Review relationship to Entity?

  • Key: UPDM-672
  • Legacy Issue Number: 13644
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Resolution: Change InformationElement to extend Class. Review relationship to EntityAction-Architecture teamPOTENTIAL SOLUTION: Change InformationElement to extend Class? Alternatively, change ports to connect to Entities?Metaclass changed to class
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change InformationElement to extend Class relationship to Entity
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ServiceInterface currently extends Interface but is also supposed to have provided/required interfaces

  • Key: UPDM-671
  • Legacy Issue Number: 13643
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale Invalid UML.
    Resolution: Change ServiceInterface to extend Class and communicate with the SOAML team to keep the two profiles in line.
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change ServiceInterface to extend Class and communicate with the SOAML team to keep the two profiles in line.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The examples of the SV-9 on the MODAF website don't obviously map to the implementation in MODAF/UPDM

  • Key: UPDM-670
  • Legacy Issue Number: 13641
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

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

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

    Forecast extends dependency with properties StartTime EndTime. Goes between resources and SubjectOfForecast add Boolean tag to resource for TA

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 184, Figure 235 SOV contains composition ownership problems

  • Key: UPDM-669
  • Legacy Issue Number: 13640
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe

    Resolution DMM Slightly out of synch with profile.
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    DMM Slightly out of synch with profile.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Some diagrams are very crowded

  • Key: UPDM-668
  • Legacy Issue Number: 13639
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Polish the diagrams.
    Part of the resolution (DMM diagram) are solved in issue 13887
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig15 - ActualProjectMilestone to Project Status and ProjectStatus to ProjectTheme

  • Key: UPDM-680
  • Legacy Issue Number: 13727
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution: Further to [UPDM_00204], we will set the cardinality on the relationships to make it clear what the constraints are.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Add a constraint to ProjectMilestone - All of the ProjectThemes, owned by a ProjectMilestone, must be typed by the same ProjectThemeStatus.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig15 - Inheritance Problem

  • Key: UPDM-679
  • Legacy Issue Number: 13726
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    If we leave the inheritance between Project and ProjectMilestone in (as per MODAF) then they both can be linked up with ProjectSequences anyway. The current implementation was seen as a tightening of the constraints. However, this is a little confusing so we will remove the inheritance between Project/ProjectMilestone and ProjectSequence/MilestoneSequence.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

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

PhysicalLocation is located in the wrong package/subprofile.

  • Key: UPDM-678
  • Legacy Issue Number: 13720
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale PhysicalLocation is used on the OV-1a and therefore isn't just an SV element (the name just makes it sound like an SV element).
    Resolution: POTENTIAL SOLUTION:PhysicalLocation will be moved to the AllElements\Environment package/subprofile.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    POTENTIAL SOLUTION:
    PhysicalLocation will be moved to the AllElements\Environment package/subprofile.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Controls should have the same fixes applied as Commands.

  • Key: UPDM-677
  • Legacy Issue Number: 13719
  • Status: closed  
  • Source: verizon.net ( David Putman)
  • Summary:

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

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

    ResolutionThe "informationSource" and "informationTarget" metaConstraints should be changed to "source" and "target". The "conveyedElement" metaConstraint should be changed to "conveyed".
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    The "informationSource" and "informationTarget" metaConstraints should be changed to "source" and "target". The "conveyedElement" metaConstraint should be changed to "conveyed".
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig21 - Constraint on StructuralPart is wrong

  • Key: UPDM-683
  • Legacy Issue Number: 13730
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    The comment on the AV-1 diagram is supposed to read:
    "Cannot be typed by a WholeLifeEnterprise"
    A WholeLifeEnterprise cannot be part of another EnterprisePhase/WholeLifeEnterprise as it represents the whole thing.
    The comment will be updated.
    Remove the constraint so that WholeLife Enterprises can have whole part relationships
    Think this changes back to open
    Resolution: Comment removed
  • Updated: Fri, 6 Mar 2015 20:59 GMT

AcV - General Comment.

  • Key: UPDM-682
  • Legacy Issue Number: 13729
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution: The structure for the ActualPost and ActualOrganization is captured on the OV-4 Actual. We will add the Slot extensions and metaConstraints to the AcV-1 to indicate that the structure can be shown on this product.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    The structure for the ActualPost and ActualOrganization is captured on the OV-4 Actual. We will add the Slot extensions and metaConstraints to the AcV-1 to indicate that the structure can be shown on this product.
    UPDATE: Add the ActualOrganizationalRole stereotype to the AcV-1 and the metaConstraints that go from/to it to the other elements show on the product diagram.
    Use links to show hierarchy based upon associations in OV-4 typical
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig15 - Project whole and part and ownedMilestones

  • Key: UPDM-681
  • Legacy Issue Number: 13728
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Priority High
    Source Ian BaileyModel Futuresian@modelfutures.com

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

    [UPDM_00204] specifies the whole/part relationship between Project and ProjectMilestone (i.e. there should be one Association between them).
    Whole/part relationships don't exist for ActualProjects, as UML doesn't have support for Instances composed (the structured is supposed to be defined by the instantiated class model). There is also no such thing as an Instance Composite Diagram in UML - though it's an idea that various people have had.
    The sample problem has been updated to show decomposition of projects.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

would be nice to have the actual legend in the second paragraph of Annex A

  • Key: UPDM-667
  • Legacy Issue Number: 13637
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Add new chapter for Legend in the introduction in Annex A.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 175, "Figure 225 - Elements related to the EnduringTask stereotype" overlays the text.

  • Key: UPDM-666
  • Legacy Issue Number: 13636
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 169, 7.1.14.3.2 EnergyExchange, the constraint description contains two extraneous constraints

  • Key: UPDM-665
  • Legacy Issue Number: 13635
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Remove constraints that belong to MaterielExchange and OrganizationalExchange.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 169, 7.1.14.3.1 Controls

  • Key: UPDM-664
  • Legacy Issue Number: 13634
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change the <<OrganizationalResource>> to <<DataElement>>
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig19 - Ontology Reference

  • Key: UPDM-686
  • Legacy Issue Number: 13734
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Resolution Update the tag as specified.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Update the tag as specified.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig18 - ArchitecturalDescription

  • Key: UPDM-685
  • Legacy Issue Number: 13732
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution: The ActualPosts and ActualOrganizations can just be partitioned off into a separate part of the model. They also, at some point, may become part of an ontology and therefore become ExternalIndividuals, etc. This isn't seen as a problem.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig18 - Mission.

  • Key: UPDM-684
  • Legacy Issue Number: 13731
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Move Mission out of Core and into DoDAF Only\OperationalElements\Structure.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Move Mission out of Core and into DoDAF Only\OperationalElements\Structure.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig19 - Use of Ontology & Generalization

  • Key: UPDM-688
  • Legacy Issue Number: 13736
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Update the document as specified.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Update the document as specified.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig19 - StereotypeExtension

  • Key: UPDM-687
  • Legacy Issue Number: 13735
  • Status: closed  
  • Source: Model Futures Ltd. ( Ian Bailey)
  • Summary:

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

    Source Ian BaileyModel Futuresian@modelfutures.com

    Resolution Update the StereotypeExtension as specified.
  • Reported: UPDM 1.0b1 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Update the StereotypeExtension as specified.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 166, 7.1.14.1.1 ActivitySubject

  • Key: UPDM-661
  • Legacy Issue Number: 13631
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Mark property as derived
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 158, "Figure 203 - Elements related to the ProjectStatus stereotype" overlays the text

  • Key: UPDM-660
  • Legacy Issue Number: 13630
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 152, 7.1.11.2.1 DataExchange

  • Key: UPDM-659
  • Legacy Issue Number: 13629
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe

    Resolution: This is just a DoDAF alias for ResourceInteraction
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 168, "Figure 217 - Elements related to the Controls stereotype" overlays the text

  • Key: UPDM-663
  • Legacy Issue Number: 13633
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 167, "Figure 214 - Elements related to the StandardOperationalActivity stereotype" overlays the text

  • Key: UPDM-662
  • Legacy Issue Number: 13632
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

conformance sections from chapter 5 and 6 need to be combined into one single conformance clause

  • Key: UPDM-641
  • Legacy Issue Number: 13609
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

description of the profile package structure in "6.4 Profile Structure"

  • Key: UPDM-640
  • Legacy Issue Number: 13608
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change Figure 4 to include SysML and SoaML
  • Updated: Fri, 6 Mar 2015 20:59 GMT

material - materiel

  • Key: UPDM-639
  • Legacy Issue Number: 13607
  • Status: closed  
  • Source: Infinity Technology Incorporated ( Dr. Sumeet S. Malhotra)
  • Summary:

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

    Source Sumeet Malhotra
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change the word materiel to material in Section 1 Scope at the bottom of page 2.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 34

  • Key: UPDM-644
  • Legacy Issue Number: 13613
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Documentation P2

  • Key: UPDM-643
  • Legacy Issue Number: 13611
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 7, 6.6.1 Aliases

  • Key: UPDM-642
  • Legacy Issue Number: 13610
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change the text to "... they are not named the same."
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 115, 7.1.7.1.1 Function

  • Key: UPDM-654
  • Legacy Issue Number: 13624
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe

    Rationale Should be coupled with UPDM_00045
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Constraint removed.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 91, 7.1.5.2.4 ServiceInterface

  • Key: UPDM-653
  • Legacy Issue Number: 13623
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Switch the bodies of the constraints so they match names.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 70, 7.1.4.4.19.1.2 ActualOrganizationalResource

  • Key: UPDM-648
  • Legacy Issue Number: 13618
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe

    Resolution Remove the Constraint
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Remove the Constraint
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Remove unnecessary constraints

  • Key: UPDM-647
  • Legacy Issue Number: 13617
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe

    Resolution Remove unnecessary constraints
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Remove unnecessary constraints:
    o TemporalPart.class - Value for class metaproperty must be stereotyped "EnterprisePhase" or its
    specializations.
    o TemporalPart.type - Value for type metaproperty must be stereotyped "EnterprisePhase" or its
    specializations.
    o StructuralPart.type - Value for type metaproperty must be stereotyped "EnterprisePhase" or its
    specializations.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 83, 7.1.5.1.1 ServiceFunction

  • Key: UPDM-652
  • Legacy Issue Number: 13622
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change "ServiiceParameter" to "ServiceParameter"
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 79, 7.1.4.4.19.1.14 RequiresCompetence

  • Key: UPDM-651
  • Legacy Issue Number: 13621
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Remove
    The following are constraints for RequiresCompetence:
    o CompatibleWith.supplier - Value for the client property must be stereotyped "Node" or its specializations.
    o CompatibleWith.client - Value for the client property must be stereotyped "ReferredLocation" or its
    specializations.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 55, 7.1.4.4.1 ArbitraryRelationshipConnector

  • Key: UPDM-646
  • Legacy Issue Number: 13616
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe

    Resolution Merge constraints into one
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Merge constraints into one
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 48, 7.1.4.1.6 SubjectOfOperationalStateMachine

  • Key: UPDM-645
  • Legacy Issue Number: 13615
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 75, 7.1.4.4.19.1.8 SubOrganization

  • Key: UPDM-650
  • Legacy Issue Number: 13620
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    change text
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 74, 7.1.4.4.19.1.7 Post, the two constraint descriptions are over cross

  • Key: UPDM-649
  • Legacy Issue Number: 13619
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Changed Diag
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 136, 7.1.7.4.14 ResourceInterface, please verify the constraint descriptions

  • Key: UPDM-656
  • Legacy Issue Number: 13626
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe

    Resolution Constraints are fine.

  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 117, 7.1.7.1.3 FunctionEdge

  • Key: UPDM-655
  • Legacy Issue Number: 13625
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe

    Rationale Should be coupled with UPDM_00134
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 146, 7.1.8.2 ProtocolImplementation, no diagram to help verifying attributes and constraints

  • Key: UPDM-658
  • Legacy Issue Number: 13628
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe

    Resolution Diagram added
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Diagram added
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 145, 7.1.8.1 Protocol, no diagram here to clarify attributes

  • Key: UPDM-657
  • Legacy Issue Number: 13627
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe

    Resolution Diagram added
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Diagram added
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Do we need a place (Node or something else) for OperationalActivities to take place?The same for Functions.

  • Key: UPDM-622
  • Legacy Issue Number: 13585
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution This is what the Performs relationship is for.

  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Various properties for InformationExchange (appearing in DoDAF 1.5) should be modelled as Measurements in UPDM

  • Key: UPDM-621
  • Legacy Issue Number: 13582
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution: Since these properties could be different for various implementations, we shouldn't include these on the stereotypes as tagged values. Instead, we'll add a section to the non-normative part of the document that describes a potential class library of MeasurementSets that fulfil the current DoDAF/MODAF requirements.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

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

CommunicationsLink in DoDAF had properties:capacityinfrastructure technology

  • Key: UPDM-628
  • Legacy Issue Number: 13593
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale Should be coupled with UDPM_00100
    Resolution Same resolution as [UPDM_00100].
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Same resolution as [UPDM_00100].
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Addition of properties

  • Key: UPDM-627
  • Legacy Issue Number: 13590
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution: Add those properties to the Standard.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Add those properties to the Standard.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DoDAF had two levels of SV relations - interface and link. UPDM has only one.

  • Key: UPDM-626
  • Legacy Issue Number: 13589
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution: TDB Add description. Update the description, so it is clear that both Interface and Link are merged into ResourceInterface.TBD. Who will do it?
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Update the description, so it is clear that both Interface and Link are merged into ResourceInterface.
    Duplicates UPDM_00276/OMG 13785
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResourcePart is mentioned in the spec

  • Key: UPDM-630
  • Legacy Issue Number: 13595
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale ResourcePart was the old name for the abstract ResourceRole stereotype but the specification didn't get updated.
    Resolution Not found.
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Role Is mentioned in the spec, but no such stereotype exists.

  • Key: UPDM-629
  • Legacy Issue Number: 13594
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale The composite structure between Posts and Organizations was non-UML in MODAF (i.e. the structure was confused). This got resolved in UPDM to be more OO and this looks like it wasn't reflected in the specification correctly.
    Resolution: Remove "Role" from SV-1 diagram description for the profile and DMM.
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Remove "Role" from SV-1 diagram description for the profile and DMM.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Why is the relationship between UPDMElement and Measurements not bi-directional?

  • Key: UPDM-625
  • Legacy Issue Number: 13588
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale The association should be bi-directional. There is no reason to have unidirectional
    Resolution: Change association to bidirectional.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change association to bidirectional.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Do we need Consumers/Producers for services as in DoDAF?

  • Key: UPDM-624
  • Legacy Issue Number: 13587
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution: In UPDM the Consumer is identified through the Resource owning a Request port (the same for Producer and Service ports). We don't really need to add a label to the Resource to indicate this.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

In DoDAF Operational Activity has "cost" property.

  • Key: UPDM-623
  • Legacy Issue Number: 13586
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale Should be coupled with UDPM_00100
    Resolution Same resolution as [UPDM_00100].
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Same resolution as [UPDM_00100].
    Add new class OperationalActivityProperties stereotyped <<MeasurementSet>>, add following attributes:
    cost
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ServiceOperation

  • Key: UPDM-638
  • Legacy Issue Number: 13604
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Source Kevin CornellIBMkcornell@ca.ibm.com

    Resolution: Add tag ConcreteBehavior typed by Function to ServiceOperation Remove metaconstraint method to Function from ServiceOperationAction-Architecture team
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Add tag ConcreteBehavior typed by Function to ServiceOperation
    Remove metaconstraint method to Function from ServiceOperation
    Action-Architecture team
  • Updated: Fri, 6 Mar 2015 20:59 GMT

InformationElement

  • Key: UPDM-637
  • Legacy Issue Number: 13603
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Source Kevin CornellIBMkcornell@ca.ibm.com

    Resolution: This is a problem of UML implementation in specific tool.
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

EnvironmentalProperty

  • Key: UPDM-634
  • Legacy Issue Number: 13600
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Source Kevin CornellIBMkcornell@ca.ibm.com

    Resolution: EnvironmentalType metaclass is changed to DataType
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Performs, Two of the constraints do not belong

  • Key: UPDM-633
  • Legacy Issue Number: 13599
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

    Performs, Two of the constraints do not belong.

    Document Issue UPDM (OMG Beta) Jan 2009

    Source Kevin CornellIBMkcornell@ca.ibm.com

    Resolution: Error in documentation, relates to Realizes Capability
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Remove two constraints:
    o RealizesCapability.supplier - Values for the supplier property must be stereotyped "Capability" or its
    specializations.
    o RealizesCapability.client - Values for the client property must be stereotyped
    "ServiceInterface"/"ResourceType" or its specializations
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SubjectOfOperationalStateMachine

  • Key: UPDM-636
  • Legacy Issue Number: 13602
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Source Kevin CornellIBMkcornell@ca.ibm.com

    Resolution: Change metaclass to BehavioredClassifier
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Measurement

  • Key: UPDM-635
  • Legacy Issue Number: 13601
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Source Kevin CornellIBMkcornell@ca.ibm.com

    Resolution: Valid UML
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    The min and max values are ranges on the measurement itself. The propertyValue should be removed though as the value is specified on the ActualMeasurement not on the Measurement.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResourceInterface and ResourceInteraction.

  • Key: UPDM-632
  • Legacy Issue Number: 13598
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

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

    Rationale Should be coupled with UPDM_00018
    Resolution: Same resolution as for [UPDM_00018].
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Same resolution as for [UPDM_00018].
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResourceConnector>> is mentioned in the spec

  • Key: UPDM-631
  • Legacy Issue Number: 13596
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale ResourceConnector got merged into ResourceInterface but the specification didn't get updated.
    Resolution: Not found.
  • Reported: UPDM 1.0b1 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

UPDM:ScopeContentlanguageaccuracy

  • Key: UPDM-620
  • Legacy Issue Number: 13581
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution: Same resolution as [UPDM_00100].
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Same resolution as [UPDM_00100].
    Add new class InformationElementProperties stereotyped <<MeasurementSet>>, add following attributes:
    scope
    content
    language
    accuracy
  • Updated: Fri, 6 Mar 2015 20:59 GMT

relationship between NeedlineExchange and ResourceInteraction

  • Key: UPDM-619
  • Legacy Issue Number: 13580
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale The current Realization relationship between the NeedlineExchange and the ResourceInteraction is duplicating a built-in UML role. It should also be shown on the SV-6 diagram to indicate that it's used by the view (e.g. as a column in the table).
    Resolution: Examine abstraction type relationships to identify refactoring issues Action-Architecture team
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Add ImplementsOperational (Abstraction) to connect:

    Node-Resource
    Needline-ResourceInterface
    OperationalExchange-ResourceInteraction
    OperationalActivity-Function
    InformationElement-DataElement
    OperationalStatemachine-ResourceStateMachine
    OperationalMessage-ResourceMessage
    OperationalActivityEdge-FunctionEdge
    Remove ContributesTo
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Can NodePort be assigned on NodeRole? Now the constraint says only about Node.The same about ResourcePort

  • Key: UPDM-618
  • Legacy Issue Number: 13579
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution: This isn't an issue as the NodePorts are connected to the NodeRoles via the Nodes that type them.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

LocationType is missing, but is mentioned throughout document.

  • Key: UPDM-617
  • Legacy Issue Number: 13578
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale As elements got renamed LocationType became Location and the document fell out of synchronization.
    Resolution: We'll update the specification to reflect the new name consistently.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll update the specification to reflect the new name consistently.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

There's no metaConstraint from ResourceInteraction to the source/target of the interaction

  • Key: UPDM-598
  • Legacy Issue Number: 13558
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale Required to model the constraints that need to be adhered to.
    Resolution: We need to apply the same fix that we implement for [UPDM_00018].
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We need to apply the same fix that we implement for [UPDM_00018].
  • Updated: Fri, 6 Mar 2015 20:59 GMT

"abstractBehavior" tagged value between ServiceOperation and ServiceFunction should be shown on the SOV-5 diagram

  • Key: UPDM-597
  • Legacy Issue Number: 13556
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale Without it, it's not clear that the relationship exists (i.e. the product views are the important views).
    Resolution: We'll add the missing tag definition to the SOV-5 diagram.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add the missing tag definition to the SOV-5 diagram.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

There doesn't seem much point in showing Service on the SOV-1

  • Key: UPDM-596
  • Legacy Issue Number: 13555
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale There's no point showing this and potentially it could be confusing.
    Resolution: We'll remove the Service stereotype from the SOV-1 view definition diagram (not from the model).
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll remove the Service stereotype from the SOV-1 view definition diagram (not from the model).
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The "carriedItem" tag between OperationalActivityEdge and NeedlineExchangeItem (NEI) isn't really needed

  • Key: UPDM-595
  • Legacy Issue Number: 13554
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale The current implementation seems to duplicate information that's already available in the model.
    Resolution: TDB. Get consensus on resolutionRemove carriedItem tag.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    TDB. Get consensus on resolution
    Remove carriedItem tag.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

It'd be more consistent for the "/subject" to "/affectedFunctions" to have the same names as the OV equivalent

  • Key: UPDM-601
  • Legacy Issue Number: 13561
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale Just to be consistent.
    Resolution: Role name changed to "actsUpon"
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Role name changed to "actsUpon"
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The "to/from" tagged values for Protocol should have better names

  • Key: UPDM-600
  • Legacy Issue Number: 13560
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

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

    We'll add a new stereotype called ProtocolLayer which extends Property. This will be applied to the composite properties that exist between Protocols. The tags will be replaced with metaConstraints for the Protocol's "ownedAttribute" role and the ProtocolLayer's "type" role. Since ownedAttribute is ordered, the higher/lower layer concept is maintained. This will allow people to model protocol stacks on Class/Composite Structure Diagrams.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ProtocolImplementation

  • Key: UPDM-599
  • Legacy Issue Number: 13559
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale The current implementation doesn't map to MODAF and isn't usable.
    Resolution: Implement proposed solutionAction-Architecture team
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Make ProtocolImplementation abstract (i.e. not extend anything) and connect it to Protocol via the tagged value. Make ResourcePort and ResourceInterface to be specializations of the abstract ProtocolImplementation stereotype.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

There should be some additional constraints for the DoDAF/MODAF stereotypes

  • Key: UPDM-603
  • Legacy Issue Number: 13563
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale At the moment it looks like its Core + DoDAF/MODAF stereotypes instead of the DoDAF/MODAF stereotypes replacing some Core stuff…
    Resolution: Implement tag on Architectural Description type by MODAF/DoDAFAdd constraints to Architectural to filter MODAF /DoDAF applicable stereotypes. Relates to alias.Action AndriusWe'll add some text to the document to provide guidance on what the DoDAF/MODAF alias' are and on their usage (i.e. it's recommended to not mix and match terminology).
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Implement tag on Architectural Description type by MODAF/DoDAF
    Add constraints to Architectural to filter MODAF /DoDAF applicable stereotypes. Relates to alias.
    Action Andrius
    We'll add some text to the document to provide guidance on what the DoDAF/MODAF alias' are and on their usage (i.e. it's recommended to not mix and match terminology).
    PULLED FROM VOTE 7 - NEED revote (Enumeration ArchitectureFrameworkKind
    list NAFs as one of its literals

    NAF should be removed from the literals list as NAF is not part of this submission. NAF does use different terms in some places and has some item in it (such as ServiceNeedline for instance) that apparently used in NAF but not MODAF, i think we just open ourselves upto a whole can of worms by allowing people to type an architecture NAF when we do not officially support it and it is outside the scope of the original requirements.)

    Do not include Views/Viewpoints/Requirements in L0, allow it for vendors to implement them as they want to. Do not interchange this part of model as part of UDPM.
    Add SoaML usage to L0.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The SystemsNode stereotype is missing

  • Key: UPDM-602
  • Legacy Issue Number: 13562
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale It's a key component in DoDAF and seems to be missing.
    Resolution: We'll add a new stereotype to the DoDAF SV package and connect it to CapabilityConfiguration with a specialization (as this is the closest match in UPDM).NOTE: We probably need to add some additional constraints to remove the human aspects (e.g. Organizations and Posts) inside the configuration as DoDAF 1.5 doesn't support this concept.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add a new stereotype to the DoDAF SV package and connect it to CapabilityConfiguration with a specialization (as this is the closest match in UPDM).
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Environment is both a DataType and a Class in the spec.

  • Key: UPDM-616
  • Legacy Issue Number: 13577
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution: We'll update the specification document to have the correct diagrams in.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll update the specification document to have the correct diagrams in.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActualLocation is both a DataType and a Class in the spec

  • Key: UPDM-615
  • Legacy Issue Number: 13576
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution: We'll update the specification document to have the correct diagrams in.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll update the specification document to have the correct diagrams in.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ExternalTypes

  • Key: UPDM-614
  • Legacy Issue Number: 13575
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale We're currently not compliant with MODAF (and I assume Ideas too).
    Resolution: We will add a Generalization metarelationship between ExternalTypes and UPDMElement.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We will add a Generalization metarelationship between ExternalTypes and UPDMElement.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Responsibility is not covered.

  • Key: UPDM-609
  • Legacy Issue Number: 13569
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale Required for mapping to DoDAF.
    Resolution: This concept is covered by a combination of Node, ResourceRole specializations and Competencies.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Attributes for Measurements - units of measure, threshold value.

  • Key: UPDM-608
  • Legacy Issue Number: 13568
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale Required for mapping to DoDAF.
    Resolution: TDB. Exact fix. If you're using an L1 implementation, then type the Measurement by a ValueType. If you're using an L0 implementation then customize the profile to add your own tag (should you require it). Phil to update the description on the stereotype.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    TDB. Exact fix.
    If you're using an L1 implementation, then type the Measurement by a ValueType. If you're using an L0 implementation then customize the profile to add your own tag (should you require it). Phil to update the description on the stereotype.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

It's not clear on the diagram that we expect people will create Provided/Required Interfaces off a ServiceInterface

  • Key: UPDM-613
  • Legacy Issue Number: 13574
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale To make it clearer what the view is supposed to show.
    Resolution: TDB. Exact fixWe will add "something" to the SOV-2 diagram to show that ServiceInterface can have provided and required UML interfaces.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We will add a comment to the SOV-2 diagram to show that ServiceInterface can have provided and required UML interfaces.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The SOV-1 is inconsistent with other Taxonomy views and should be updated

  • Key: UPDM-612
  • Legacy Issue Number: 13573
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale To make is more consistent with other taxonomy views in UPDM.
    Resolution: It's not important enough to warrant changing the diagrams in the profile.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Should there be any link between OperationalActivity and Capability?

  • Key: UPDM-607
  • Legacy Issue Number: 13567
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale Required for mapping to DoDAF.
    Resolution: There shouldn't be a direct link between OperationalActivity and Capability as it's implemented via Nodes. Only StandardOperationalActivities are connected to Capabilities and these are imported from a MODAF library and do not require creating in the user model.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Why there is not potential relationship between InformationElement and SystemDataElement?

  • Key: UPDM-606
  • Legacy Issue Number: 13566
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution: There are already relationships between the IOFlows that convey them and the underlying data that the Elements represent. Another relationship would make consistency, etc, more difficult and not add much value.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Don't we need System/Artifact specializations, like Network, etc?

  • Key: UPDM-605
  • Legacy Issue Number: 13565
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

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

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Should there be a relationship between Capability and Mission?

  • Key: UPDM-604
  • Legacy Issue Number: 13564
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale There was an existing link between these in a previous No Magic DoDAF implementation.
    Resolution As the issue is based on proprietary implementation, there is no need to fix it.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

No traceability from Node to SV.

  • Key: UPDM-611
  • Legacy Issue Number: 13571
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale Required for mapping to DoDAF and to provide a complete picture
    Resolution This information is derived as follows:Node à performs an à OperationalActivityOperationalActivity à is supported by a à FunctionFunction à is performed by a à ResourceThere is no need to add anything further as it would complicate the maintenance of the consistency.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13580 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

No Rule for SV.

  • Key: UPDM-610
  • Legacy Issue Number: 13570
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale Required for mapping to DoDAF.
    Resolution: The stereotype is called ResourceConstraint in UPDM.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ArchitecturalDescriptions aren't supposed to own Views

  • Key: UPDM-590
  • Legacy Issue Number: 13548
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

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

  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

no type for the ProjectTheme so there's no way to define a value

  • Key: UPDM-589
  • Legacy Issue Number: 13547
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

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

    A new stereotype called ProjectThemeStatus will be added that extends Enumeration. This will allow users to define their own statuses as required. The mapping between ProjectThemeStatus and a colour (for use on the AcV-2) is deemed an implementation concern and outside the scope of the UPDM specification.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

milestone sequence stereotype should be shown on SV-8 view

  • Key: UPDM-588
  • Legacy Issue Number: 13542
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

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

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

  • Reported: UPDM 1.0b1 — Mon, 23 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    POTENTION SOLUTION:

    Show the Milestone Sequence on the diagram but don't enforce the use of MilestoneSequence between all milestones

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Actual measurement

  • Key: UPDM-587
  • Legacy Issue Number: 13532
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution Adding a time for an actual measurement, i.e. target, future or present. Try to consider pattern matching with SV-9 proposal.Action-Architecture team
  • Reported: UPDM 1.0b1 — Fri, 20 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Adding a time for an actual measurement, i.e. target, future or present.
    Try to consider pattern matching with SV-9 proposal.
    Action-Architecture team
    We'll do two things:
    Add a tag called "date" which will contain the ISO Date Time.
    Add an enumeration tag called "intention" with three literals; "Result", "Required", "Estimate". The purpose of this tag is to identify what the date and values relate to.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

metaConstraint between ResourceType and ResourceRole

  • Key: UPDM-594
  • Legacy Issue Number: 13553
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale Just to be consistent.
    Resolution: It's not important - they both mean pretty much the same thing.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

metaConstraint between ActualOrganizationPart and ActualOrganization

  • Key: UPDM-593
  • Legacy Issue Number: 13551
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale Just to be consistent.
    Resolution: Add the missing metaconstraint
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Add the missing metaconstraint
  • Updated: Fri, 6 Mar 2015 20:59 GMT

PostType should be called Post.Post should be called PostRole

  • Key: UPDM-592
  • Legacy Issue Number: 13550
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale To maintain the naming convention we agreed upon.
    Resolution We'll rename the stereotype.
  • Reported: UPDM 1.0b1 — Thu, 26 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll rename the stereotype.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

There's no metaConstraint from NeedlineExchange to the source/target of the exchange

  • Key: UPDM-591
  • Legacy Issue Number: 13549
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

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

    Add Source-target constraints to NeedlineExchange
    Raise issue to change NeedlineExchange to OperationalExchange
    Action-Fatma to write description of usage
    Fatma's description to be added to the Exchange descriptions in the specification.

    PA 17/2/2009 If we rename NeedlineExchange to OperationalExchange then we also need to rename NeedlineExchangeItem to OperationalExchangeItem.
    Also need to add constraints to OperationalActivityEdge/FunctionEdge that states if the stereotype is applied to an ObjectFlow and the edge is connected to an Exchange, the conveyed item and the pin types need to be consistent/compatible.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

metaConstraint between EntityRelationship and Attribute

  • Key: UPDM-586
  • Legacy Issue Number: 13531
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale The role doesn't exist between the two metaclasses so the OCL will not work.
    Resolution TBD. Exact fix
  • Reported: UPDM 1.0b1 — Fri, 20 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Reconnect the metaConstraint to go between EntityItem and EntityRelationship.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

two ways to allocate Operational Activities/Function to Nodes/Resources

  • Key: UPDM-585
  • Legacy Issue Number: 13530
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale Some users will want to use the UML approach for allocating behaviour and others won't. We should cater for both.
    Most MODAF/System Engineers won't be interested in the UML approach and we should avoid adding confusion by having two approaches for the same thing.
  • Reported: UPDM 1.0b1 — Fri, 20 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ArbitraryRelationshipConnector is a bit of a long name

  • Key: UPDM-584
  • Legacy Issue Number: 13529
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale It will make the diagram very messy should the stereotype be shown on a diagram.
  • Reported: UPDM 1.0b1 — Fri, 20 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalActivity

  • Key: UPDM-572
  • Legacy Issue Number: 13515
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

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

    Resolution: Performs does the allocation or it is defined by a derived tag, not the implicit relationship
  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13530 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Climate

  • Key: UPDM-571
  • Legacy Issue Number: 13514
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Disposition: See issue 13372 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActualProjectMilestone

  • Key: UPDM-570
  • Legacy Issue Number: 13513
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Source Kevin CornellIBMkcornell@ca.ibm.com

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

  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Duplicate. Resolution in UPDM_00130
    OMG Issue 13380
    Disposition: See issue 13380 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ServiceInteraction

  • Key: UPDM-575
  • Legacy Issue Number: 13518
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Source Kevin CornellIBMkcornell@ca.ibm.com

    Resolution Error update document
  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13359 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActualOrganizationRelationship,

  • Key: UPDM-574
  • Legacy Issue Number: 13517
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Source Kevin CornellIBMkcornell@ca.ibm.com
  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13212 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Mission

  • Key: UPDM-573
  • Legacy Issue Number: 13516
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Source Kevin CornellIBMkcornell@ca.ibm.com
    Date 1st October 2008
    Rationale Duplicates UPDM_00007
    Resolution Change the role to useCase
  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13201 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Currently ActualMeasurementSets are not related to time

  • Key: UPDM-581
  • Legacy Issue Number: 13524
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution: Add a new stereotype that specializes ActualMeasurementSet that has the additional properties, etc. The following attributes are potential candidates:Recorded Date (when the measurements were taken) - MUSTValidity Date (how long the measurements are valid for) - MAYBE
  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13532 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Why are the Controls.xxxx constraints listed here

  • Key: UPDM-580
  • Legacy Issue Number: 13523
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Source Manfred Koethe
  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13502 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 49, 7.1.4.2.1 Attribute, has a wrong constraint

  • Key: UPDM-579
  • Legacy Issue Number: 13522
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

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

    Manfred Koethe
  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13531 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

abstract stereotypes should not extend

  • Key: UPDM-578
  • Legacy Issue Number: 13521
  • Status: closed  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

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

    Source Fred MervineIBMfmervine@us.ibm.com
  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13372 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OntologyReference

  • Key: UPDM-577
  • Legacy Issue Number: 13520
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Source Kevin CornellIBMkcornell@ca.ibm.com

    Resolution Update to extend element
  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13493 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ProjectSequence

  • Key: UPDM-576
  • Legacy Issue Number: 13519
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Source Kevin CornellIBMkcornell@ca.ibm.com
  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13199 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Can a Node host Activities?

  • Key: UPDM-583
  • Legacy Issue Number: 13526
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com
  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13530 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ArbitraryRelationshipConnector

  • Key: UPDM-582
  • Legacy Issue Number: 13525
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com
  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalActivity/SysFunction consumes/produces exchanges

  • Key: UPDM-551
  • Legacy Issue Number: 13488
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Summary OperationalActivity/SysFunction consumes/produces exchanges.
    Diagram OV-3, SV-4, OV-5, SV-6
    Document Issue UPDM (OMG Beta) Jan 2009

    Priority High
    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com
    Rationale Required for generating OV-3 and SV-6 diagrams, as well as for information purposes on an OV-5 and SV-4.
    Resolution The tag definitions on OperationalActivity and Function will be removed. New derived tag definitions will be added to NeedlineExchange and ResourceInteraction to derive the consuming and producing OperationalActivities and Functions.
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    The tag definitions on OperationalActivity and Function will be removed. New derived tag definitions will be added to NeedlineExchange and ResourceInteraction to derive the consuming and producing OperationalActivities and Functions.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Attributes for Organization - code, military service type, etc.

  • Key: UPDM-550
  • Legacy Issue Number: 13487
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Rationale Required for mapping to DoDAF.
    Resolution We'll add the missing attributes.
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add the missing attributes.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalConstraint/ResourceConstraint

  • Key: UPDM-549
  • Legacy Issue Number: 13486
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

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

  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add an abstract Constraint stereotype that has an additional enumeration tag definition. OperationalConstraint and ResourceConstraint will be made specializations of this.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

various identifiers

  • Key: UPDM-548
  • Legacy Issue Number: 13485
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Rationale Required to fulfil the requirements of DoDAF/MODAF.
    Resolution Add the missing identifiers to the relevant stereotypes:InformationElementNeedlineExchangeDataElementResourceInteractionNeedline
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Add the missing identifiers to the relevant stereotypes:
    InformationElement
    NeedlineExchange
    DataElement
    ResourceInteraction
    Needline
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Should there be a enumeration property on the RealizesCapability element to indicate the level of the realization?

  • Key: UPDM-554
  • Legacy Issue Number: 13491
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    We'll add the enumerations as a tag definition (called realizationLevel) to the RealizesCapability stereotype as specified in the Issue description.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ServiceInterfaces should have the ability to have Dependencies between them.

  • Key: UPDM-553
  • Legacy Issue Number: 13490
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

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

  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We will add a Dependency metarelationship to/from ServiceInterface to show that dependencies can be created.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Needline is not realized in SVs.

  • Key: UPDM-552
  • Legacy Issue Number: 13489
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Rationale Required for mapping to DoDAF.
    Resolution The information can be derived via Exchanges and does not require a new, direct relationship. We'll add a derived tag to Needline and ResourceInterface to list the related ResourceInterfaces/Needlines.
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13580 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ServiceParameter needs to have a metaconstraint modelled

  • Key: UPDM-560
  • Legacy Issue Number: 13497
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale The ServiceParameter needs to be constrained to make it compatible with FunctionParameters. Without this Functions cannot implement a ServiceOperation safely.
    Resolution We'll add a metaConstraint between ServiceParameter and ResourceInteractionItem (the umlRole will be "type").
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add a metaConstraint between ServiceParameter and ResourceInteractionItem (the umlRole will be "type").
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ServiceOperations need to be owned by Resources as well as ServiceInterfaces

  • Key: UPDM-559
  • Legacy Issue Number: 13496
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    ServiceOperations need to be owned by Resources as well as ServiceInterfaces as otherwise nothing is implementing the operation on the interface. This also means that ServiceOperations need to be connected to Functions via a metaConstraint constraining the method/specification relationship.NOTE: We identified the need to do this before the submission but ran out of time…
    Diagram SV-4
    Document Issue UPDM (OMG Beta) Jan 2009

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
    Rationale ServiceInterfaces specify the operations that need to be implemented by the realizing resource. In order to implement them, they need to be copied to the realizing Resource. They then need a Function connected to them to show how the operation is implemented by the Resource.
    Resolution We'll add a metaConstraint between Resource and ServiceOperation (the same as the one between ServiceInterface and ServiceOperation).
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add a metaConstraint between Resource and ServiceOperation (the same as the one between ServiceInterface and ServiceOperation).
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OntologyReference has invalid specializations.

  • Key: UPDM-556
  • Legacy Issue Number: 13493
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Rationale OntologyReference currently extends Extension yet the two subtypes are Class and InstanceSpecification extensions. Though the extensions aren't inherited this doesn't seem right.
    Resolution OntologyReference should not be extending Extension. Since its abstract, we'll update it to extend Element as we have for all the other abstract stereotypes.
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    OntologyReference should not be extending Extension. Since its abstract, we'll update it to extend Element as we have for all the other abstract stereotypes.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

change ArbitraryConnector to a Dependency and change the name to ArbitraryRelationship

  • Key: UPDM-555
  • Legacy Issue Number: 13492
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
    Date 30th October 2008
    Rationale We need to be able to produce the example diagrams specified in DoDAF/MODAF, or at least be very close to them. Loosing the direction of the relationships will cause the meaning of the OV-1c to be ambiguous.
    Resolution We will change ArbitraryConnector to be called ArbitraryRelationships and change it to extend Dependency instead of Connector.
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We will change ArbitraryConnector to be called ArbitraryRelationships and change it to extend Dependency instead of Connector.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

I really don't see the point in Function having a StateMachine

  • Key: UPDM-567
  • Legacy Issue Number: 13506
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Summary I really don't see the point in Function having a StateMachine… How does that work?
    Diagram SV-10b
    Document Issue UPDM (OMG Beta) Jan 2009
    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
    Rationale I've no idea how or why you'd do this…
  • Reported: UPDM 1.0b1 — Tue, 17 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    See issue 13356 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

There should be a stereotype called RealizesNode between Node and Resource

  • Key: UPDM-566
  • Legacy Issue Number: 13505
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    The group agreed that we should have a stereotyped relationship for things such as this.
  • Reported: UPDM 1.0b1 — Tue, 17 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Commands , This stereotype has extra constraints that do not belong there

  • Key: UPDM-565
  • Legacy Issue Number: 13502
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Source Kevin CornellIBMkcornell@ca.ibm.com
    Resolution Document needs to be updated, Controls and Command combined
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Document needs to be updated, Controls and Command combined
  • Updated: Fri, 6 Mar 2015 20:59 GMT

allow ServiceOperationActions to be owned by Functions as well as ServiceFunctions on the SV-4

  • Key: UPDM-558
  • Legacy Issue Number: 13495
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Rationale Without this we cannot model the invocation of a ServiceOperation from a requesting Resource.
    Resolution We'll add a metaConstraint between ServiceOperationAction and Function (the same as the one between ServiceOperationAction and ServiceFunction).
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add a metaConstraint between ServiceOperationAction and Function (the same as the one between ServiceOperationAction and ServiceFunction).
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Referred location extends different metatypes than its sub-stereotypes.

  • Key: UPDM-557
  • Legacy Issue Number: 13494
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

    Source Andrius StrazdauskasNo Magicandriuss@nomagic.com

    Resolution Change the metaclass to Element.
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change the metaclass to Element.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

A DataType can own attributes and operations but not behaviors

  • Key: UPDM-562
  • Legacy Issue Number: 13499
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Rationale Similar to issue re activities and Statemachines
    Resolution Entity metaclass is changed to Class.
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Entity metaclass is changed to Class.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

We aren't consistent about the tag definition names used for storing start and end dates

  • Key: UPDM-561
  • Legacy Issue Number: 13498
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale It's easier for users if we're as consistent as possible with everything in the profile.
    Resolution We'll make all the date/time tags have the same names (i.e. startDate and endDate). This will make it a lot more consistent.All references changed to startDate, endDate, date.
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll make all the date/time tags have the same names (i.e. startDate and endDate). This will make it a lot more consistent.
    All references changed to startDate, endDate, date.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing stereotype

  • Key: UPDM-564
  • Legacy Issue Number: 13501
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Resolution Error in text document
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Error in text document.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

A DataType is not a StructuredClassifier so it cannot have parts

  • Key: UPDM-563
  • Legacy Issue Number: 13500
  • Status: closed  
  • Source: International Business Machines ( Mr. Kevin Cornell)
  • Summary:

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

    Resolution Environment metaclass is changed to Class.
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Environment metaclass is changed to Class.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ItemInConcept is an abstract stereotype, but is should not be.

  • Key: UPDM-569
  • Legacy Issue Number: 13512
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    ItemInConcept is an abstract stereotype, but is should not be.
    OV-1
    UPDM (OMG Beta) Jan 2009
    Andrius StrazdauskasNo Magicandriuss@nomagic.com
  • Reported: UPDM 1.0b1 — Thu, 19 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13204 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ArbitraryRelationshipConnector

  • Key: UPDM-568
  • Legacy Issue Number: 13507
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Version Beta 1.0

    OMG Document Number: c4i/2008-08-13

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

    figure 64, page 54

  • Reported: UPDM 1.0b1 — Tue, 17 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    As per the Issue
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Imported SysML Stereotypes cannot be applied

  • Key: UPDM-527
  • Legacy Issue Number: 13376
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    According to the UML 2.1 specification, importing elements into the profile simply make them accessible within the profile namespace, meaning other stereotypes can generalize or refer to those imported stereotypes. However, the import does not define those stereotypes in the profile namespace. When the UPDM profile is applied to a model, only those stereotypes in its namespace can be applied to elements in the model. That means the SysML stereotypes imported into the UPDM profile cannot be applied in the model.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Do not include Views/Viewpoints/Requirements in L0, allow it for vendors to implement them as they want to. Do not interchange this part of model as part of UDPM.
    Add SoaML usage to L0.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

No support for MODAF Problem Domain

  • Key: UPDM-526
  • Legacy Issue Number: 13375
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    ProblemDomain exists in MODAF but not in UPDM. This is an important concept and should be captured.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    TradeSpace is the current UPDM version of ProblemDomain - this should be renamed.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResourcePort & ResourceType circular inheritance

  • Key: UPDM-525
  • Legacy Issue Number: 13374
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    There seems to be a circular inheritance between the elements below:
    · A ResourcePort is typed by a ResourceInteractionItem and is owned by a ResourceType
    · A ResourceType inherits from a ResourceInteractionItem
    When you go further down the inheritance tree, the elements that inherit from the ResourceType do not really make sense to be ResourceInteractionItems as you end up with:
    DataElement,Energy,CapabilityConfiguration,PostType,OrganizationType,Artefact,Artifact,Software.
    I think this should only be DataElement and Energy.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Stereotype names collide with UML keywords (meta-types)

  • Key: UPDM-524
  • Legacy Issue Number: 13373
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    We cannot have any stereotypes with the same name as UML keywords. Activity and Component (possibly Part) are…
    The following keywords are conflicting:
    · activity (current abstract so may not be an issue right now)
    · artifact
    · attribute
    · component
    · entity
    · function (to be confirmed)
    · node (this one could be contentious)
    · subsystem
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Change:
    Activity to PerformedActivity
    Artifact to ResourceArtifact
    Attribute to EntityAttribute
    Component to ResourceComponent
    Entity to EntityItem
    Subsystem to SubsystemPart
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Abstract Stereotypes should not Extend Element

  • Key: UPDM-523
  • Legacy Issue Number: 13372
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    A lot of the abstract stereotypes are set to extend Element when they shouldn't be. They're abstract so they don't really need to extend anything (their derived stereotypes will do that). The main problem is that since UPDMElement is set to Element and everything is a specialization of it, the stereotypes appear to inherit the ability to be applied to anything - something we definitely don't want!
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll remove all the extensions from abstract stereotypes.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Stereotyped Dependencies too limiting

  • Key: UPDM-540
  • Legacy Issue Number: 13389
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Relationships defined using Property "type" are not intuitive

  • Key: UPDM-539
  • Legacy Issue Number: 13388
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Document layout and section numbering hard to read

  • Key: UPDM-538
  • Legacy Issue Number: 13387
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The layout of the document is considered to be hard to read and disorganized.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Jim Rice has reformatted the document.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sequence diagrams cannot show exchanges

  • Key: UPDM-542
  • Legacy Issue Number: 13391
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Just been trying to implement the sequence diagram parts and we have a problem
    SDs cannot show information flows, they can show the elements flowing on them, the information items, but only as arguments on an event or an operation.
    I think the solution is to just events with auguments that relate to the various items that can flow.
    It is unworkable as it is at the moment.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Add 3 additional stereotypes that extend message with tag for information flows the message is carried on.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Confusing notational conventions used in diagrams

  • Key: UPDM-541
  • Legacy Issue Number: 13390
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    In many cases, the diagramming indicates an association between stereotypes:
    See example below - UPDMElement.
    UPDMElement -> Standard
    but the documentation does not specify an association, rather it show these as attributes. Is the diagramming correct, or is the document right?
    UPDM/RFC::UPDMElement
    Super type for many of the UPDM elements. It provides a means of extending UPDM elements in a common way. With links to the measurement set, it also allows quantitative metrics to be associated with structural and behavioral elements.

    Figure 1 - Elements related to the abstract UPDMElement stereotype.
    Attributes
    The following are attributes of UPDMElement:
    conformsTo : Standard[*] - Standard that this UPDM element is conforming to.
    URL/URI : String[1] - Unique identifier for the element.
    measurementTypes : MeasurementSet[*] - Types of measurements corresponding to the actual measurements.
    actualMeasurements : ActualMeasurementSet[*] - The actual measurements to which the element must conform.
    Extensions
    The following are extensions for UPDMElement:

    o Element in th esubmission
    UPDM/RFC:: 6.5 Representing stereotype constraints
    This section describes a profile that is applied to the UPDM Profile inorder to specify various relationships. Since this is integral to the definition of the profile, it should be defined as if it were in fact a UML profile in a formal way.
    For example:
    "metarelationship" dependency
    "metarelationship" is a stereotype for dependency, showing that certain domain concepts will be implemented using regular UML relationships.
    For example:
    A Capability may depend on other Capabilities, but this concept cannot be visualized on the diagram:

    Figure 2: Capabilities Generalization
    We are using the "metarelationship" dependency to visualize the dependency concept:

    Figure 3: Visualizing <<metarelationship"
    This diagram should be read as follows:
    Capability may have other Capabilities related to it, using the UML Dependency metaclass.
    The "metarelationship" dependency will appear in only in the specification diagrams, but not the profile XMI.
    In the actual specification:

    There are 3 of these "meta-relationships" shown, but they are not defined anywhere else in the profile. They are part of the normative definition because they are in the diagram, but since they are not in the XMI, then how is that they can be considered as part of the profile?
    We need to have a better understanding what these "notational conventions" used in this submission mean. The explanations in the RFC are not sufficient. We had some difficulty understanding them, and exactly what OCL constraints they imply. A formal definition with resulting OCL would clear it up, and provide guidance to tool vendors as to how to deal with these conventions.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Attribute stereotype has issues with non-navigable associations

  • Key: UPDM-534
  • Legacy Issue Number: 13383
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    This stereotype extends Property and according to the diagram, it must be the value of the "endType" meta-property of an EntityRelationship, which extends Association. This <<Attribute>> stereotype and the implied constraint are fine if the association roles are always navigable. If an association role is non-navigable or if the element at the end of the association cannot own properties, the association end property is owned by the association itself, making it difficult for the user to apply the <<Attribute>> stereotype to that property.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add a constraint to "EntityAttribute" to explain that the stereotype is only applied to Properties that are owned by "EntityItem"s.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalActivityEdge constraints too restrictive

  • Key: UPDM-533
  • Legacy Issue Number: 13382
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The OperationalActivityEdge stereotype extends ActivityEdge and both the source and target actions of this edge are constrained to OperationalActivityActions (CallBehaviorActions). This constraint is too restrictive since you could not create an OperationalActivityEdge from the initial action to the first OperationalActivityAction
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Document text and MM needs to be updated to show that general UML activity constructs can be used.
    TBD. Actioned by
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Operational Activity action constraints too restrictive

  • Key: UPDM-532
  • Legacy Issue Number: 13381
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The first constraint indicates all owned InvocationActions must be OperationalActivityActions (which extends CallBehaviorAction). This will prevent the user from using other invocation actions in the activity such as CallOperationAction, SendSignalAction, etc.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13355 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ISO8601DateTime should not extend LiteralString

  • Key: UPDM-531
  • Legacy Issue Number: 13380
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Measurement can have a circular reference

  • Key: UPDM-530
  • Legacy Issue Number: 13379
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    This stereotype extend Property and generalizes UPDMElement. It should not generalize UPDMElement since it is used in the UPDMElement::actualMeasurments and could result in circular references.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActualMeasurement can have a circular reference

  • Key: UPDM-529
  • Legacy Issue Number: 13378
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Elements that are stereotyped <<UPDMElement>> (indirectly) can have references (actualMeasurements) to instance specifications stereotyped <<ActualMeasurementSet>>. An ActualMeasurementSet instance spec has slots stereotyped ActualMeasurement, which also generalized UPDMElement. This could result in a circular reference. ActualMeasurement should not generalize UPDMElement.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Both UPDM and SysML profiles must be applied

  • Key: UPDM-528
  • Legacy Issue Number: 13377
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Since the UPDM L0 profile refers to imported SysML stereotypes, according to the UML 2.1 specification the SysML profile must be applied to the model before the UPDM profile.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Fix using UML RTF process, involves clarification of PackageImport and SubProfiles.
    Needs to be discussion with Pete Rivett/Architecture team but intended resolution is that text added to spec stating that SysML profile needs to be added first. But I do not think this is the whole issue
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Resource subtypes

  • Key: UPDM-522
  • Legacy Issue Number: 13371
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale This misrepresents the contents of the view and conflicts with MODAF.
    Resolution We'll add the missing Resource specializations.
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add the missing Resource specializations.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The diagram currently shows InformationElements when it should be showing DataElements

  • Key: UPDM-521
  • Legacy Issue Number: 13370
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    This misrepresents the contents of the view and conflicts with DoDAF and MODAF.
    We'll update the diagram to replace InformationElement with DataElement.
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll update the diagram to replace InformationElement with DataElement.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityConfiguration should be shown on this diagram.

  • Key: UPDM-520
  • Legacy Issue Number: 13369
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    It currently looks like all Resources apart from CapabilityConfigurations are displayed in this view but that's not the case.
    We'll add CapabilityConfiguration to the diagram and connect it to Resource with the specialization.
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add CapabilityConfiguration to the diagram and connect it to Resource with the specialization.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Artifact and Artefact

  • Key: UPDM-547
  • Legacy Issue Number: 13484
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    We'll remove the MODAF specialized stereotype as the MOD aren't overly worried about the Americanized spelling.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ConceptualDataModel just sits in the MODAF package and isn't connected to anything

  • Key: UPDM-546
  • Legacy Issue Number: 13483
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Rationale It's pointless having it at the moment.
    Resolution: It doesn't exist in MODAF 1.2 so it will be removed.
  • Reported: UPDM 1.0b1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    It doesn't exist in MODAF 1.2 so it will be removed.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActualProjectMilestone need association link

  • Key: UPDM-545
  • Legacy Issue Number: 13394
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    I think ActualProjectMilestone should have an association link to a CapabilityConfiguration, similar to the relationship CapabilityIncrementMilestone and OutOfServieMilestone have - otherwise it is useless in the DoDAF version of SV-8.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Disposition: See issue 13647 for disposition
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Annex C diagrams need fixing

  • Key: UPDM-537
  • Legacy Issue Number: 13386
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

    Add non-normative product specifications to the documentation
    Use a proper profile definition to define the sample model. The sample model is now updated and consistent.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Annex C Figure 284 has invalid stereotype

  • Key: UPDM-536
  • Legacy Issue Number: 13385
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

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

  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Post constraints are reversed

  • Key: UPDM-535
  • Legacy Issue Number: 13384
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The descriptions for the two constraints are reversed.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Error Update text and Model
  • Updated: Fri, 6 Mar 2015 20:59 GMT

UsedConfiguraton is misspelled

  • Key: UPDM-544
  • Legacy Issue Number: 13393
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    There is an element in the model called "UsedConfiguraton" needs to be changed to UsedConfiguration.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    change text
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing NeedlineExchange meta-constraint

  • Key: UPDM-543
  • Legacy Issue Number: 13392
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    There's a meta-constraint between NeedlineExchange and NeedlineExchangeItem missing for constraining the "conveyed" role.
  • Reported: UPDM 1.0b1 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The ActualOrganizationPart stereotype should be called ActualOrganizationRole.

  • Key: UPDM-496
  • Legacy Issue Number: 13214
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    To maintain the naming convention we agreed upon.
    We'll rename the stereotype.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll rename the stereotype.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

We shouldn't connect ActualOrganizationRelationship to ResourceInteractions with a realize tag.

  • Key: UPDM-495
  • Legacy Issue Number: 13213
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    It's using a tag for something that already exists in UML.
    We will remove the tag definition and use the "realization" role to connect the two InformationFlows together. There should be a constraint that the ends of the ActualOrganizationRelationship must be instances of the ends of the "realized" Commands/Controls relationship.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We will remove the tag definition and use the "realization" role to connect the two InformationFlows together. There should be a constraint that the ends of the ActualOrganizationRelationship must be instances of the ends of the "realized" Commands/Controls relationship.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActualOrganizationRelationship

  • Key: UPDM-494
  • Legacy Issue Number: 13212
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    The current roles don't exist between for InformationFlows so the profile is invalid.
    We will keep the extension to InformationFlow but change the roles from "client/supplier" to "informationSource/informationTarget". We should also add a metaconstraint to the relationship to constrain the "conveyed" data to the same as Commands and Controls.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We will keep the extension to InformationFlow but change the roles from "client/supplier" to "informationSource/informationTarget". We should also add a metaconstraint to the relationship to constrain the "conveyed" data to the same as Commands and Controls.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Currently all UPDM ports have no ability to connect UPDM connectors - Needline, ResourceInterface.

  • Key: UPDM-500
  • Legacy Issue Number: 13224
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Suggested resolution: Improve contraints for connectors, so Ports are allowed as connector end types.
  • Reported: UPDM 1.0b1 — Tue, 13 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Improve contraints for connectors, so Ports are allowed as connector end types.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

stereotypedRelationship between Function and OperationalActivity

  • Key: UPDM-499
  • Legacy Issue Number: 13217
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    It's inconsistent with the other product diagrams and should only be used, if anywhere, on the snippet diagrams.
    Particular stereotyped relationship appears on these diagrams:FunctionOperationalActivityOV-4 TypicalSV-1SV-4SV-5We will change these so that all Product diagrams show the stereotype and metaConstraints. The "element specific" diagrams will still use the stereotypedRelationship notation though.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Particular stereotyped relationship appears on these diagrams:
    Function
    OperationalActivity
    OV-4 Typical
    SV-1
    SV-4
    SV-5
    We will change these so that all Product diagrams show the stereotype and metaConstraints. The "element specific" diagrams will still use the stereotypedRelationship notation though.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActualOrganizationPart stereotype should be connected to OrganizationPart abstract stereotype for the definingFeature

  • Key: UPDM-498
  • Legacy Issue Number: 13216
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Slots can only exist in UML if they have an attached definingFeature. We need to constrain what these features are.
    Information was already in the model. Missing relationship was displayed in OV diagram.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Information was already in the model. Missing relationship was displayed in OV diagram.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The OrganizationPart abstract stereotype should be called OrganizationRole

  • Key: UPDM-497
  • Legacy Issue Number: 13215
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    To maintain the naming convention we agreed upon.
    We'll rename the stereotype.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll rename the stereotype.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The metaConstraint between ResourceInterface and ResourceType should have a "/" on the front of "endType"

  • Key: UPDM-503
  • Legacy Issue Number: 13352
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Section 8.1.1.1.4 Figure 8.36
    Page 63

    Rationale We need to indicate the role we're constraining and with the "/" missing it could be misinterpreted.
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add the missing "/".
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 5.1 text is out of context

  • Key: UPDM-502
  • Legacy Issue Number: 13343
  • Status: closed  
  • Source: EmbeddedPlus Engineering Inc ( Kumar Marimuthu)
  • Summary:

    This text is out of context. Rename the section heading to "UML Constraint Representation" and add it in between Section 7.5 and Section 7.6. Have this as Section 7.6 and move existing Section 7.6 to Section 7.7.
  • Reported: UPDM 1.0b1 — Mon, 26 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    This text is out of context. Rename the section heading to "UML Constraint Representation" and add it in between Section 7.5 and Section 7.6. Have this as Section 7.6 and move existing Section 7.6 to Section 7.7.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Issue with SV-9

  • Key: UPDM-501
  • Legacy Issue Number: 13292
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Description. Forest is not tied to time, and there is no distinct TechnologyArea concept - modeler have to use Resources, which may be confusing.
  • Reported: UPDM 1.0b1 — Fri, 16 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The metaConstraint with the umlRole "ownedElement" is wrong

  • Key: UPDM-513
  • Legacy Issue Number: 13362
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
    23rd October 2008
    Same as above.
    Same as above.
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    same as issue 13361
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The metaConstraint with the umlRole "ownedElement" is wrong

  • Key: UPDM-512
  • Legacy Issue Number: 13361
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    The current metaConstraint stops a ServiceFunction from owning anything other than ServiceFunctionActions, which is completely wrong.
    We'll change the metaConstraint between ServiceFunction and ServiceFunctionAction (very similar to UPDM_00034).
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll change the metaConstraint between ServiceFunction and ServiceFunctionAction (very similar to UPDM_00034).
  • Updated: Fri, 6 Mar 2015 20:59 GMT

RealizesCapability used to be a Realization but for some reason has been changed

  • Key: UPDM-511
  • Legacy Issue Number: 13360
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    RealizesCapability used to be a Realization but for some reason has been changed. This should be changed back unless there's a good reason for it.
    SOV-3
    UPDM (OMG Beta) Jan 2009
    8.1.1.1.5Fig 8.87
    109
    High
    Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
    23rd October 2008
    The name of the stereotype says it all…
    Metaclass for RealizesCapability changed to Realization.
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Metaclass for RealizesCapability changed to Realization.
    WITHDRAWN FROM Vote 2
    Merged with issue OMG 13878
    Revised Text:
    Merged with issue OMG 13878
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityConfiguration should be shown on this diagram.

  • Key: UPDM-519
  • Legacy Issue Number: 13368
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale It currently looks like all Resources apart from CapabilityConfigurations are displayed in this view but that's not the case.
    Resolution We'll add CapabilityConfiguration to the diagram and connect it to Resource with the specialization.
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add CapabilityConfiguration to the diagram and connect it to Resource with the specialization.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The umlRole "conveyedElement" between ResourceInteraction and ResourceInteractionItem is wrong

  • Key: UPDM-518
  • Legacy Issue Number: 13367
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Source Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    Rationale The current role is not valid UML.
    Resolution We'll update the umlRole to the correct name.
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll update the umlRole to the correct name.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

We should show ServiceInterface on the SV-1 as the "type" for the Service and Request ports

  • Key: UPDM-517
  • Legacy Issue Number: 13366
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    To make it obvious what the type is.
    We'll add the unshown "type" metaConstraint between Service/Request and ServiceInterface.
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add the unshown "type" metaConstraint between Service/Request and ServiceInterface.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ServiceInteraction is currently extending Interface when it should be extending Interaction

  • Key: UPDM-510
  • Legacy Issue Number: 13359
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    ServiceInteraction is currently extending Interface when it should be extending Interaction (I think a typo may have slipped in).
    SOV-4c
    UPDM (OMG Beta) Jan 2009
    8.1.1.1.5Fig 8.90
    110
    Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
    The current extension is blatantly wrong and needs resolving for it to fit its purpose.
    Metaclass for ServiceInteraction changed to Interaction
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Metaclass for ServiceInteraction changed to Interaction
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ServiceParameter needs to be shown on this diagram.

  • Key: UPDM-509
  • Legacy Issue Number: 13358
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    By just looking through the product views you wouldn't even know this element exists…
    Service parameter added to SOV-2
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Service parameter added to SOV-2
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The Entity, Attribute and EntityRelationship stereotypes are in the wrong Package

  • Key: UPDM-508
  • Legacy Issue Number: 13357
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com
    It's inconsistent with MODAF/DoDAF and is misleading.
    We'll rescope the stereotypes.
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll rescope the stereotypes.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The stereotypedRelationship "realizesCapability" should be show fully on the diagram

  • Key: UPDM-516
  • Legacy Issue Number: 13365
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Rationale It's confusing in the current form.
    Resolution Diagram updated.
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Diagram updated.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The metaConstraint to ServiceParameter from ServiceFunction should be shown on diagram

  • Key: UPDM-515
  • Legacy Issue Number: 13364
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    We'll add the missing metaConstraint to the SOV-5 diagram.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

FunctionEdge should be removed from the diagram as it won't be shown in this view.

  • Key: UPDM-514
  • Legacy Issue Number: 13363
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    It's misleading and incorrect.
    FunctionEdge was removed from SOV-5 diagram
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    FunctionEdge was removed from SOV-5 diagram
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Don't see the point in OperationalActivity having a StateMachine

  • Key: UPDM-507
  • Legacy Issue Number: 13356
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

    I've no idea how or why you'd do this…
    We will remove ServiceFunction, Function and OperationalActivities from the StateMachineOwner abstract stereotype.
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We will remove ServiceFunction, Function and OperationalActivities from the StateMachineOwner abstract stereotype.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

add the missing metaConstraints

  • Key: UPDM-506
  • Legacy Issue Number: 13355
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Rationale Currently there's no constraint as to who can own the Action.
    Resolution We'll add the missing metaConstraints between FunctionAction and Function, as well as OperationalActivityAction and OperationalActivity.
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Role values changed to "source" and "target".
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The metaConstraints from Commands to OrganizationalResource have invalid umlRoles

  • Key: UPDM-505
  • Legacy Issue Number: 13354
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    The roles don't exist so the profile is invalid.
    Role values changed to "source" and "target".
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Role values changed to "source" and "target".
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The metaConstraint between Commands and DataElement has an incorrect umlRole

  • Key: UPDM-504
  • Legacy Issue Number: 13353
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    Rationale The role doesn't exist so the profile is invalid.
    Resolution "umlRole" value changed to "conveyed".
  • Reported: UPDM 1.0b1 — Thu, 29 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

need to change the roles to represent client and supplier

  • Key: UPDM-481
  • Legacy Issue Number: 13199
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    ProjectSequence is currently set to extend Dependency but has metaConstraints relating back to InformationFlow. We need to change the roles to represent client and supplier.
    The current implementation isn't valid UML.
    Update constraints and diagrams changing them to "client" and "supplier".
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Update constraints and diagrams changing them to "client" and "supplier".
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Project should be called ActualProject as it's an Instance

  • Key: UPDM-480
  • Legacy Issue Number: 13198
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Strictly speaking Project should be called ActualProject as it's an Instance. ProjectType should then be called Project.Rationale To maintain the naming convention we agreed upon.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Rename Project to ActualProject, and ProjectType to Project.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNodeSpecification

  • Key: UPDM-479
  • Legacy Issue Number: 12057
  • Status: closed  
  • Source: Anonymous
  • Summary:

    it is not clear why this is needed – there is no need to
    separate nodes from their behaviour. In fact, operational nodes are little more than
    collections of operational activities, hence this is a strange choice. It becomes stranger still
    when the need to also use Materiel is taken into account, which adds up to a significant and
    not altogether useful level of indirection.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityRequirementCapability is duplicated

  • Key: UPDM-478
  • Legacy Issue Number: 12228
  • Status: open  
  • Source: Dassault Systemes ( Mr. 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

The Realization relationship between ResourceType and Node should be stereotyped.

  • Key: UPDM-489
  • Legacy Issue Number: 13207
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    The group agreed that all of these relationships should be stereotyped for clarity.
    We'll reuse ContributesTo for "Resources to Nodes" as well as "Functions to OperationalActivities". In order to maintain consistency we'll need to add a constraint that Resources can only "contribute to" Nodes, and Functions can only "contribute to" OperationalActivities.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll reuse ContributesTo for "Resources to Nodes" as well as "Functions to OperationalActivities". In order to maintain consistency we'll need to add a constraint that Resources can only "contribute to" Nodes, and Functions can only "contribute to" OperationalActivities.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResourceType should be called Resource.

  • Key: UPDM-488
  • Legacy Issue Number: 13206
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    ResourceType should be called Resource.
    To maintain the naming convention we agreed upon.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll change the name.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The metaConstraint between Needline and Node should have a "/" on the front of "endType".

  • Key: UPDM-491
  • Legacy Issue Number: 13209
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add the missing "/".
  • Updated: Fri, 6 Mar 2015 20:59 GMT

KnownResources as well as NodeRoles should be connectable to Needlines

  • Key: UPDM-490
  • Legacy Issue Number: 13208
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    If we don't have this then the flow of exchanges to KnownResources cannot be modelled.
    We'll add Needlines to NodeChild instead of NodeRole so that the full OV-2 description can be implemented.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll add Needlines to NodeChild instead of NodeRole so that the full OV-2 description can be implemented.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActualLocation should be called PhysicalLocation.

  • Key: UPDM-487
  • Legacy Issue Number: 13205
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    To stop confusion that ActualLocation is an instance of Location and maintain the naming convention we agreed upon.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll change the name.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ItemInConcept should be called ConceptRole.

  • Key: UPDM-486
  • Legacy Issue Number: 13204
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    To maintain the naming convention we agreed upon.
    ItemInConcept renamed to ConceptRole
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    ItemInConcept renamed to ConceptRole
  • Updated: Fri, 6 Mar 2015 20:59 GMT

metaConstraint between EnterprisePhase and Mission should have its umlRole set to ownedUseCase

  • Key: UPDM-483
  • Legacy Issue Number: 13201
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    The current role doesn't exist between a Class and a UseCase so the profile is invalid.
    The constraint changes using "useCase" metaproperty.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    The constraint changes using "useCase" metaproperty.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Enterprise should be called WholeLifeEnterprise.

  • Key: UPDM-482
  • Legacy Issue Number: 13200
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Summary Enterprise should be called WholeLifeEnterprise.

    Rationale It's inconsistent with MODAF and has confused a lot of people in the past.
    Resolution We'll rename Enterprise to WholeLifeEnterprise.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll rename Enterprise to WholeLifeEnterprise.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityOperationalCapability is duplicated

  • Key: UPDM-477
  • Legacy Issue Number: 12227
  • Status: open  
  • Source: Dassault Systemes ( Mr. 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 ( Mr. 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 ( Mr. 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

OrganizationType should be called Organization.

  • Key: UPDM-493
  • Legacy Issue Number: 13211
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    OrganizationType should be called Organization.
    OV-4 - Actual
    To maintain the naming convention we agreed upon.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll rename the stereotype.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The diagram should show the relationship between UPDMElement and ActualMeasurementSet

  • Key: UPDM-492
  • Legacy Issue Number: 13210
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    The generated table will contain the actual values not the types of values.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    We'll update the diagram appropriately.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ItemInConcept shouldn't be abstract

  • Key: UPDM-485
  • Legacy Issue Number: 13203
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    ItemInConcept shouldn't be abstract.

    We need to be able to apply this stereotype and we can't if it's abstract.
    ItemInConcept is no longer abstract.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    ItemInConcept is no longer abstract.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DefinesArchitecture should be a Realization

  • Key: UPDM-484
  • Legacy Issue Number: 13202
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

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

    ArchitecturalDescriptions are the implementations of the EnterprisePhases, which relates better to a Realization. We should always use the best fitting UML element.
    We'll change DefinesArchitecture to extend Realization.
  • Reported: UPDM 1.0b1 — Fri, 9 Jan 2009 05:00 GMT
  • Disposition: Resolved — UPDM 1.0
  • Disposition Summary:

    Extensions
    The following are extensions for DefinesArchitecture:
    o Realization

  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.5

  • Key: UPDM-474
  • Legacy Issue Number: 12122
  • Status: open  
  • Source: International Business Machines ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. Fred Mervine)
  • Summary:

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

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

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

SystemsNode

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

    the relationship to OperationalNode appears to indicate that the op nodes
    are part of the SystemsNode. This is inappropriate, as in both DoDAF and MODAF
    operational nodes are logical entities that perform operational activities. They may be
    realised as SystemsNodes, but to show structure in this way is a misunderstanding of the
    intent behind MODAF and DoDAF. This is a common misunderstanding amongst DoDAF
    users which has been cleared up in the MODAF 1.1 documentation
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemServiceProvider, SystemServiceConsumer

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

    as these are classes, it is unclear
    how they are to be used. Do they represent generic actors in a service orchestration ?
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Standard

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

    There are no major issues with the TV area of UPDM. The definition of Standard would have to be
    broadened for MODAF use. Also, it is not clear how TechnicalStandardsProfile could be used in
    MODAF.
    • Standard – in MODAF, this includes non-technical standards whereas the UPDM definition
    seems to restrict it to systems standards
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemTask

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

    as in the operational views, these are UML operations linking Systems to
    their behaviour. This is not done in MODAF M3, though it is a perfectly reasonable
    approach.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemPort

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

    the definition talks about SystemInterfaces. However, SystemInterface is
    more of an abstract concept. Surely it is CommunicationLink that should connect
    SystemPorts ?
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemInterface

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

    now represented as resource interactions in MODAF v1.1
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemFunction

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

    note that in MODAF 1.1, there are simply functions which are
    performed by functional resources (systems, human roles, or capability configurations).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

System

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

    unclear whether this is a class of system or an individual system
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemGroup

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

    it is not clear whether this is a group of individual systems (i.e. serial
    numbered) or a grouping by type. Without this distinction, there may be semantic
    interoperability issues between different tools and different architectures
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalActivityRealization

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

    this seems to indicate that an OperationalActivity can be
    realised by an event trace or state model, which does not appear to make sense. Is it useful
    to specify anything other than an op activity to system function mapping ? Also, this again
    seems to relate to materiel, which further obscures the semantics of Materiel (if that is
    possible).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location

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

    it is often important to distinguish between an actual location, and a type of
    location (e.g. “in theatre”, “behind enemy lines”, “maritime littoral”, etc.)
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DataExchange

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

    MODAF no longer uses this – it simply has resource interactions that
    carry data elements.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Service

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

    this seems to indicate an implementation of a service by a system. In the NATO
    SOA views, the Service stereotype indicates a type of service which may be implemented by
    many different means (the UPDM equivalent would seem to be ServiceSpecification)
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

RealizedSystemSpecification, SystemFunctionSpecification

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

    this would appear to use an
    interface to define a type of system and classes to deploy those systems. This seems rather
    an unusual and complex approach given that UML now has composite structure models for
    this purpose.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Systems Views

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

    The SV area of UPDM covers MODAF and DoDAF reasonably well. The concern mentioned before
    about lack of a clear logical-physical split from OV-SV is again apparent in the SV section though.
    SystemsNodes can “house” Operational Nodes in UPDM, which is against the original intent of
    DoDAF, and clearly against the rules in MODAF. The remaining concerns about the SV area are
    mostly due to the change in MODAF 1.1 that extends SV-1,SV-4, etc. to cover human factors
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResouceCapabilityConfiguration

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

    see previous comment (issue 12075)
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResourceCapability

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

    the UPDM model has CapabilityConfiguration in it, yet it relates
    capabilities to resources which deliver them – why then have CapabilityConfiguration ?
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityRequirementCapability

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

    again, this would seem to be a misunderstanding of the
    MODAF approach. OperationalCapability seems to link Capabilities to
    CapabilityRequirements, but a capability manager would want to be able to specify capability
    requirements in a broad sense without recourse to operational models.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CommunicationSystem

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

    this is not explicitly defined in MODAF – there was much
    resistance from the MODAF TWG to introducing special types of systems (the argument
    was “where do you stop ?”). Instead, the MODAF Ontology is used to add semantics to the
    basic M3 elements. This also applies to hardware, networks, software, etc.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CommunicationPath

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

    this concept does not exist in MODAF
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CommunicationLink

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

    in MODAF, this is covered in SV-2 as a system port connection and
    requires that ports be defined – this is not required in UPDM
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Capability.isFielded

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

    this Boolean attribute is meant to describe the fielded status of a
    capability. However, the reality is far more complex – the capability may be implemented
    (and therefore fielded) in many possible ways. In addition, there are levels of fielding (IOC,
    FOC). This problem may be related to the UPDM misunderstanding of the concept of
    Capability.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Capability

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

    the UPDM spec states “The Capability is expressed in terms of the Resources
    required to implement the Capability”, which is in clear contradiction to the way capability is
    used in the MOD and the MODAF Stratgic Views. The whole idea of the capability concept is
    for architects to specify their requirements INDEPENDENTLY of how it is to be
    implemented (i.e. the resources to be used are deliberately not stated).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityRequirement

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

    the relationship to Milestone does not appear to follow the
    current MODAF approach. In MODAF 1.0, CapabilityRequirement was a specialisation of
    Capability that had performance metrics. In MODAF 1.1, CapabilityRequirement has been
    removed altogether (Capability itself is sufficient).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityOperationalCapability

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

    this concept does not exist in MODAF (see comment on
    OperationalCapability).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Strategic Views

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

    There are a number of concerns about this package in the UPDM specification. There does not
    seem to be a clear understanding of what a capability is and how it relates to other parts of the
    architecture; the logical (OV) and physical (SV). Capabilities in UPDM have a strong equipment and
    systems focus. In MODAF and M3, capability an ability to do something, which may or may not be
    achieved by procuring / using equipment – e.g. it may be possible to provide a capability increment
    simply by re-training soldiers
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityConfigurationCapabilities

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

    again, this may indicate a misunderstanding of the
    capability approach in UK and US defence acquisition. The statement “Defines the
    association between a CapabilityConfiguration and the Capabilities that are configured by it”
    implies the capability is defined by the resources that realise it. This is not the case (see the
    comment on Capability).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityConfiguration

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

    despite the word “capability” being in the name, a capability
    configuration is firmly in the solution space, and therefore does not belong in the StV
    package of the UPDM profile (this also applies to the related stereotypes).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNode

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

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

OperationalInformationFlow

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

    this represents the flow of information, materiel, or energy
    between activity nodes (typically, these are Actions). MODAF and DoDAF only cover the flow
    of information between activities. If this is an attempt to replicate the MODAF node
    connector concept, it is a misinterpretation – node connectors are only intended to be
    information flows on OV-2 diagrams – they have no behavioural semantics.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalServiceConsumer, Operational ServiceProvider

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

    it seems inappropriate to
    model service consumption in this way. It does not allow the architect to show that a
    particular node is both a consumer and a provider of different services. This approach
    forces the architect to produce two nodes – one for production and one for consumption –
    even when it is clearly the same node producing and consuming. The work done in
    developing SOA views by UK and Sweden would seem to indicate that OV-2 is not
    appropriate in a true SOA approach – most SOA orchestration approaches map the
    services to the activities that use them rather than to nodes. The nodes that produce and
    consume services can then be derived by examining the activities they perform
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalEventTrace

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

    event trace models apply to Materiel which is itself not clearly
    defined, hence it is not clear what the event trace model would represent. In most MODAF
    or DoDAF architectures, an OV-6c shows sequences of messages between operational
    nodes – here it would seem to allow other representations
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalControlFlow

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

    this is defined as the “control of flow of energy from one activity
    node to another”. Further clarification of semantics is required
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalTask

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

    this approach used UML Operations to link nodes to activities (though
    the materiel object also seems to serve this purpose ?) and is not used in MODAF, where
    instead a dependency is used to link nodes to operational activities
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalStateTrace

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

    the definition describes it as the “state machine for OV-5”, yet
    state models belong in OV-6b and typically describe the state transitions of operational
    nodes (OV-2).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Policy

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

    this is not explicitly defined as an element in MODAF. Instead, MODAF architects
    use operational activities, and standards to define policy. It may be worth considering the
    addition of this in a future MODAF release – e.g. as a subtype of standard
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganizationalRole

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

    refers to roles being played by OperationalNodes, which breaks the
    MODAF rule about nodes being logical
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganizationalResource

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

    it is not clear if this is an actual resource (e.g. Ian Bailey) or a
    type of resource (e.g. EW Officer).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganizationalRelationship

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

    an enumeration “LineKind” is used to describe dotted, solid,
    etc. lines. This kind of graphical specification seems inappropriate in a meta-model
    (especially as this only seems to be specified for OrganizationalRelationship).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRoleResource

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

    this would appear to duplicate the functionality of
    the OperationalCapabilityRealization
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRole

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

    as this is a solution specification, it would belong in the SVs in
    MODAF.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalRole

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

    this concept does not exist in MODAF. In addition, it subclasses into
    OperationalServiceConsumer and OperationalServiceProvider which would appear to
    prevent a node from being both a consumer and a provider of different services (this is very
    common in SOA models).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

RealizedOperationalCapability

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

    see issue with OperationalCapabilityRealization (issue 12048)
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNodePort

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

    MODAF does not use UML::Port for nodes
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

MaterielNode

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

    the semantics of this relationship are not explained. The same relationship
    is used to relate Materiel to Operational Nodes, Systems, etc. without explaining the
    semantics for each case.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

MaterielBehavior

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

    this association links Material to UML behavioural elements. It seems
    to allow Materiel to be linked to either operational behaviour elements or system behaviour
    elements, which does not make sense. Without a clear definition for Materiel, it is not clear
    whether the system behaviour or operational behaviour is correct. It is usual in DoDAF that
    an operational node conducts operational activities, and a system conducts system
    functions. Quite what UPDM’s Materiel is or does is something of a mystery.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Materiel

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

    the definition in UPDM does not appear to make sense (possibly as the result of
    cut-and-paste problems ?). Later references to Materiel would seem to suggest that is the
    supertype of all UPDM elements that can have behaviour. This is not apparent from its
    name or from its definition, so cannot be confirmed
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActivityRealization

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

    it is difficult to interpret the purpose of this from the definition (which
    is somewhat Byzantine), but this seems in essence to be a relationship between an Op
    Activity and a System Function to show that the System Function realises the Op Activity. If
    this is the case, it seems strange that UPDM has not used the usual UML approach of a
    dependency. Alternatively, it could be argued that as these are classes (i.e. types of activity),
    then the system function is a special way of conducting an operational activity, so a
    Generalisation relationship might be acceptable. The use of an Association seems very
    unusual.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Operational Views

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

    The Operational Views form the linchpin of a MODAF architecture – they either serve to abstract
    an as-is architecture into a logical structure, or present a logical requirement for a to-be
    architecture. It is not at all clear that UPDM handles this. Of particular concern is the use of the
    Materiel stereotype (see details below) which is not well defined and seems to connect logical and
    physical elements with no clear semantics. The need for Material is also questionable – it seems an
    unnecessary element to create in order to associate other elements
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

UPDMAttributes

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

    this is a simple way to reference external information. To
    accommodate the MODAF Ontology and IDEAS, a more sophisticated mechanism of
    external specialisation, instantiation and equivalence will be required. This could be achieved
    with some additions to the ExternalReferenceType enumeration, however
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Resource

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

    this has two attributes that are probably not specified clearly enough to be
    useful. It has a “value”, which is a string representing its “value to the enterprise”. There is
    no way a simple string like this could be used for any kind of analysis or decision support in a
    repository. In addition, Resource extends class, implying it is a type of resource, yet it has an
    attribute “type”.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

InformationElement

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

    in UPDM, this is a Stereotype of Class, whereas M3 uses
    InformationItem.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

AssetMapping

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

    this seems to be based on a poor understanding of DoDAF and MODAF.
    Operational Nodes are logical “actors” whose functionality may be realised (by systems in
    DoDAF, and by resources in MODAF). To have yet another level of abstraction (if that is
    what this is meant to be) seems to just add confusion. In addition, OV-1 tends to be the last
    view produced in an architecture, so it is unlikely that it will specify anything that is “later
    realised”.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapability

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

    this is a UML Use Case that specifies the requirements for a
    capability. There is no equivalent of this in MODAF or M3, but it does appear to be useful. A
    future MODAF release should consider something similar for the StVs.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Needline

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

    in UPDM, a needline is specified as a requirement to exchange information. In
    an as-is architecture, it would not be a requirement, but a logical representation of an
    existing information exchange. It should be noted that the UPDM definition is probably in line
    with DoDAF in this respect, but not with MODAF
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRealization Definition

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

    This would appear to be the definition for
    OperationalCapability rather than OperationalCapabilityRealization. In addition, it states that
    the OperationalCapability is equivalent to an EnduringTask in MODAF, which is not correct
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRealization

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

    it is not clear why this relates an OperationalCapability
    to the realizing systems, instead of just relating the Capability itself to the capability
    configurations or systems – see also RealizedOperationalCapability
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Enterprise & Vision

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

    MODAF now defines the temporal and physical structure of the
    enterprise – i.e. an enterprise can be decomposed into its parts and into its temporal
    phases. UPDM applies the temporal information to the Vision (and also to other elements),
    which does not allow for quite such a flexible way to “slice and dice” the architecture
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Asset

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

    no equivalent in MODAF for this concept (note this is a very particular use of the
    word “Asset” for OV-1 purposes in UPDM)
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

System views

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

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

Operational views

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

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

Strategic views

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

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

AcV-1: System of Systems Acquisition Clusters

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

    this view is now called “Acquisition
    Clusters” in MODAF
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Acquisition Views

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

    The UPDM specification for the AcVs would appear to be incomplete. It specifies the key
    stereotypes (Project, Milestone, etc.), but not the logic needed to put all these together into a
    sensible programme management view (AcV-2).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Acquisition views

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

    A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
    · There is a very great deal of difference between the MODAF/ NAF Acquisition view entities and the UPDM Acquisition view entities. It is not considered possible to deliver the types of views that MODAF/ NAF requires based on the entities that UPDM contains and this is seen as a major disadvantage.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Technical views

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

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

MilestonePoint

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

    the semantics of this relationship are unclear. In addition, there are four
    relationships using this name in the Milestone section, which is very confusing
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Milestone

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

    capability increment is represented by a string in UPDM. The M3 equivalent
    links to the capability that is met so that there is contiguity through the architecture. Only by
    doing this can StV-3 and SV-8 be derived from the project milestones (essential for
    architectural coherence and contiguity across views).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DLOD Issue Types

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

    as with the DLOD Elements, UPDM hard-wires the possible status
    indicators. MODAF does not specify this, and neither does the M3
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DLOD Elements

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

    the MODAF Meta-Model specifically does not mention the Defence Lines
    of Development (which are a UK only concept) so as to allow a more generic mechanism for
    dealing with other project thread approaches – e.g. the US DoD DOTMLPF approach.
    Furthermore, each line of development is specified in the UPDM profile. MOD has recently
    changed the number of lines of development, and there is no reason to assume this will not
    happen again.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

All views

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

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

General comparison

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

    MODAF/ NAF are felt to be a more connected model than UPDM where no attempt is made to show all entities as a connected meta-model for different purposes. This makes UPDM much harder to assess.
    MODAF/ NAF have a much clearer model of temporal components making it a lot easier to discuss how different parts of the model applies at different points in time.
    The MODAF/ NAF use of UML: property ensures that several types of connections that UPDM defines based on associations are unnecessary in MODAF/ NAF.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

All Views

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

    The AV in UPDM is derived from IEEE1471 (the same goes for MODAF). The interpretation used in
    UPDM is different to that used in M3. The biggest cause for concern is the Resource stereotype. It
    is not clearly defined and attributed. It is not clear whether a resource is an individual resource or a
    type of resource (a key distinction in Enterprise Architecture).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ProjectType specialises from Project

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

    this is possibly a misunderstanding of the two
    MODAF concepts – a type of project cannot be a special case of a project
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Project

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

    the UPDM description of Project confines it to the procurement of systems. The
    MODAF approach says nothing about the type of project. This has been deliberately done in
    MODAF to allow for capability increment projects that achieve the increments through
    other means than equipment – e.g. revised doctrine, re-configuration of battlegroups, etc.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Milestone

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

    · The attributes contained here seem fairly simplistic and it seems doubtful whether they will be enough to manage the information required. By contrast, the meta-model for MODAF/ NAF gives a great deal more.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Acquisition views DLODelements

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

    · This element may well be too specific and subject to change.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemSystemSoftware

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

    By the same argument as that indicated in issue 12010 this association is not seen as required.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ArchitectureView

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

    this is the equivalent of ArchitecturalProduct in M3. However, M3
    takes a different approach; instead of hard-wiring the views into the profile, it allows the
    profile itself to specify the views and the framework used (allowing for NAF, DoDAF, etc. to
    be covered by M3). M3 also specifies the type of product in terms of its nature – i.e.
    structural, behavioural, matrix, etc. UPDM does not.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ArchitectureSummary

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

    a class library approach is used in UPDM, but not in MODAF
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DLODIssueType

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

    · As stated previously, the inclusion of hard-coded enumerations is not considered as a good approach.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Project/ ProjectType

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

    · The fact that a project type should be viewed as a specialisation of project seems very strange. The reverse would be more understandable.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Service

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

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

OperationalActivityRealization

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

    · The description given for this entity would seem to make it difficult to distinguish this and a CapabilityConfiguration (at least from a MODAF/ NAF perspective). Is there a need for this given the existence of the CapabilityConfiguration entity?
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Network/ NetworkPaths

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

    · The only difference that can be seen between CommunicationSystem and Network would seem to be dealing with geographical extension. Is there really a need to maintain two different entities to cover this area?
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalActivity

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

    t is noted that OperationalActivity handling does not seem to consider the entities that are considered as required when creating activity diagrams such as swimlanes, callbehavioraction, pins etc. Such entities exist in MOFAF/ NAF.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Materiel/ MaterielBehavior/ MaterielNode

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

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

OperationalNodePort

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

    · In spite of the fact that no such entity exists in MODAF and NAF, its inclusion is considered a good idea as a means of bridging the gaps between different levels of abstraction in an operational node model.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNode

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

    · As stated before, MODAF/ NAF considers nodes as logical entities that could almost be viewed as instances of a capability. The connection to resources are therefore less than clear and as stated previously associations to effect are not considered appropriate at this point.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRole/ OperationalCapabilityRoleCompetence

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

    · The fact that the first entity is supposed to be a specialisation of operational node is strange. It would also seem to belong squarely within the System View entities. Since the relationship is already there based on MODAF/ NAF entities it is considered questionable whether this is actually required.
    · The association extension seems questionable at least from a MODAF/ NAF perspective.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalServiceConsumer/ OperationalServiceProvider

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

    · The use of service related concepts here would seem to require a complete service handling throughout and this does not seem to be the case in UPDM, possibly due to the fact that OMG is considering other profiles for services. Based on this it would seem better to await developments here.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalRole/ OperationalCapabilityRole/ OrganisationalRole

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

    · The number of roles used here seems to restate much the same thing in different contexts. MODAF/NAF makes use of a single Role concept and that would seem to be enough.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNodeSpecification

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

    · This is also considered a good idea, however, in order to be complete there would seem to be a need to tie required and provided interfaces to a port as well as InformationElements by means of the interfaces to make the handling complete.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganisationalRelationship

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

    · The attributes here would seem to be reconsidered. It may well be appropriate to avoid these altogether since the few entries contained seem unable to capture all aspects of organisational relationships. A brief check within CADM for instance reveals a great deal of different relationships and it would therefore seem better to let the architecture model itself deal with this either internally or through external references.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalTask

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

    · This could be used to tie rather nicely into the handling of interfaces and ports in which case an operation could be a part of an interface associated with a realized interface that forms a part of a port. In all fairness however, if operations are made use of it is felt that signals should also be allowed, especially since a good way of visualising operations would be to allow InformationElements to be conveyed by signals (they could of course also be dealt with as part of the attributes associated with a given operation).
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResultsOfEffect

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

    · As stated above, the use of Effect seems premature and it is therefore felt that this should be removed.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Policy/ Rule

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

    · It seems slightly difficult to distinguish between these two entities and the questions should be asked whether they are both really needed.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganisationalResource

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

    · While it is important to be able to show these entities in the form of an organisation chart it needs to be noted that MODAF/ NAF distinguishes between actual organisational resources or types of resources, something that may well be required depending on the scope of the model.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DataElementSystemFunction

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

    · This association also seems questionable since the relationship will anyway be present as a result of the definition of the system function itself.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

System views

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

    CommPathFromTo/ CommunicationLink/ CommunicationPath/ CommunicationSystem/ CommunicationPathRealization
    · The main items here would seem to be connectors between systems and their aggregation into paths that could also include intervening communications systems. This makes sense, however the CommPathFromTo association seems fairly superfluous. The same can be stated for CommunicationPathRealization.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRealization

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

    · The fact that this is a specialisation of OperationalNode is considered strange as is the relationship it establishes. The crucial relationship would seem to be between capability and CapabilityConfiguration, this is the one that has to be maintained.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapability

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

    · This seems to define an entity in the form of UseCase "above" ordinary capabilities. It is however felt that the name leaves something to be desired (suggestion: CapabilityUseCase) and that it should be part of the StrategicViews rather than the OperationalViews.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

RealizedOperaionalSpecification

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

    · Since the connections between OperationalNode, OperationalNodePort and OperationalNodeSpecification is already established it seems unclear why this relationship would need to be established explicitly.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResultsOfEffect

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

    · As stated above, the use of Effect seems premature and it is therefore felt that this should be removed.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

PerformanceMeasureSet

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

    the purpose of this (and its related stereotypes) is not entirely
    clear. It is defined as being applied to any ConformingElement, but the “semantics” section
    talks about system performance
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemsNode/ SystemsNodeElements

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

    · MODAF/ NAF does not contain a system node concept and the question is whether a more applicable concept here would not be CapabilityConfiguration. The statement that a system node would be equivalent to PhysicalAsset in MODAF is not correct. If however there is a hidden assumption that a systems node has to be in a single location, then Capability configuration is broader since this would not be a requirement.
    · It is considered questionable whether the association extension is really required. A CapabilityConfiguration (to use a MODAF/ NAF term) would be visualised as a composite class diagram and the entities would thus turn up as connected to the surrounding entity without the need of a specific association.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemServiceConsumer/ SystemServiceProvider

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

    · It is considered questionable whether the above entities are really of interest. A service is realized by a CapabilityConfiguration in MODAF/ NAF not just a system and anything other than web services will require more than this to indicate usage as well as provision of services. Being a consumer or provider will depend very highly on the point of view taken.
    · It is noted that in both of these, the text states that they are specialisations from System but the diagram shows them as extensions of class.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ServiceSpecification

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

    · See previous comment. In addition to this the attribute serviceDescription seems to be a link to a formal service description or a description of the service itself. Linking to an external specification is not considered enough for an architecture model intended to describe SOA, neither is a single text description.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

StrategicMission

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

    · This entity also requires further considerations. It seems better placed as either part of the StrategicViews or the OperationalViews. Given the attributes contained it would seem to be very focused on actual operations something that does not actually fit with its name. The fact that the parameters are only strings furthermore makes one question whether it can actually be used to describe something of architectural value.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Concern/ Stakeholder/ StakeholderConcern

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

    · The relationship between these entities seems far from clear. A concern is an extension of UseCase and is associated with a Stakeholder as well as an ArchitectureView. A stakeholder is also associated with an architecture view and the relationship between Stakeholder and concern is stereotypes as StakeholderConcern. It would therefore seem that connections to ArchitectureView exist both through the concern and from the stakeholder directly. Is this really required?
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Resource

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

    · Resource, given the explanation given also seems far better placed elsewhere than as part of AllViews. Given the extension used (Class) it is obviously a Type, but there seems to be some further classification going on since a resourceType parameter in the form of a string has been included. A ResourceType entity seems of interest. The value parameter also seems strange and the use to which this can actually be put seems questionable.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityConfiguration

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

    · This entity would seem to be better positioned within the SystemView elements.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Capability

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

    · Capability is shown as directly tied to resources, something that from a MODAF/ NAF perspective would be OK provided the entity was a CapabilityConfiguration. A Capability is an abstract high-level view of that which an enterprise wants to be able to accomplish during a specific time frame. Some of the attributes shown here are also strange such as type and isFielded which would seem to merit entities all by themselves in order to be usable.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ExternalReferenceType/ InformationAssurance/ Security

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

    · Why do the ExternalReferenceType literals in the table repeat themselves as table entries?
    · While InformationAssurance and Security are of concern to an architect, it is considered highly doubtful whether the parameters shown here will cover the issue. Since these are examples of issues that require management across an entire enterprise it may be more profitable to look into aspect-oriented modelling concepts as a means of covering such issues.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Asset/ AssetMapping

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

    · This seems to be a way of creating entities solely for the use within OV-1. The mapping entity then establishes a relationship between the asset and entities elsewhere. MODAF/ NAF manages this by viewing all the above as ConceptItems and therefore no additional entry is required. However since OV-1 users tend to want to draw lines between entities MODAF/ NAF has added an arbitrary connection element that can be used to indicate this. This has no semantic meaning however other than as an illustration. It is noted that no such feature seems to exist in UPDM.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Operational views - ActivityRealization

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

    · This extension of association is used to tie an OperationalActivity (an operational view element) to an OperationalActivityRealization (a system view element) or a SystemFunction (a system view element) to an OperationalCapabilityRealization (an operational view element). Based on the semantics description this seems to be intended to create one-to-many mappings between OperationalActivity (s) and SystemFunction(s) in both directions. The above seems a very cumbersome approach and is handled in a far simpler but equally functional way in MODAF/ NAF.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Effect/ CausesEffect/ EffectAffectsNode/ NodeCausesEffect/ OperationalCapab

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

    Effect/ CausesEffect/ EffectAffectsNode/ NodeCausesEffect/ OperationalCapabilityEffect
    · Previous versions of MODAF/ NAF contained an effect entity. This has now been removed since it is felt that effect based operations handling require additional consideration before an attempt is made to include it within the architecture framework. The inclusion of effect and associated entities within UPDM seems premature.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityRequirement/ CapabilityRequirementCapability

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

    · This entity has been removed in MODAF/ NAF as unnecessary. The relationships shown also seem strange. As commented upon later the crucial entity is Capability, and the fact that there is no relationship here between capability and a requirement for it therefore seems strange. Essentially all relationships shown for this entity are considered as highly questionable.
    · The need for CapabilityRequirementCapability as an extension of Association is also considered questionable.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNodeCapabilityRequirement

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

    OperationalNodeCapabilityRequirement/ OrganisationalResourceCapabilityConfiguration/ ResourceCapability/ ResourceCapabilityConfiguration
    · The description of OperationalNodeCapabilityRequirement discusses the need for a relationship between capability and operational node whereas the constraints as well as the name talks about a relationship between a CapabilityRequirement and an OperationalNode. The text should, if it is actually to remain be amended.
    · All of the above extensions of association are considered questionable as to need. Using MODAF/ NAF the fact that capability configurations are built by resources are apparent in the model and no additional associations are required.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalNodeCapabilityRequirement

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

    · As commented upon both previously and later, the need for this association seems questionable.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

PerformanceMeasureSet/ PerformanceParameterSet/ PerformanceParameterTyp

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

    · PerformanceMeasureSet also turns up as PerformanceMeasurementSet in a number of places and the correct term therefore needs to be established.
    · The attributes make use of the entity PerformanceMeasurementPeriod which does not appear anywhere else in the document.
    · The descriptions of all of these seem somewhat circular and could do with some modification: PerformanceMeasureSet ="This stereotype (PerformanceMeasureSet) is applied to instances of classes stereotyped PerformanceParameterSet". PerformanceParameterSet = "This stereotype is applied to PerformanceMeasurementSet in the UPDM class library".
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Goal

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

    · This is shown as part of AllViews but would seem much better placed as part of the StrategicViews.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityOperationalCapability

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

    · This entity seems highly questionable and is commented on later as part of comments concerning OperationalCapability.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityConfigurationCapability

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

    · This entity would work better as an extension of Dependency rather than association. It furthermore needs to be noted that capability configurations are defined by the capability they implement not the other way around. This implies that the supplier of the relationship is the capability and that the client is the CapabilityConfiguration of which there may be more than one since different combinations of resources could be used to supply a capability.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Enterprise

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

    · By considering Enterprise as an extension of Package, the ability to use this effectively in a model seems to be severely limited. MODAF/ NAF.
    · MODAF/ NAF provides the ability to consider the enterprise as a set of temporal parts as well as whole-parts, something that will yield an ability to be much more specific as regards the enterprise.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Doctrine

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

    · This entity seems better placed as part of the Strategic or the Operational views. It is furthermore shown as having an association with a SystemTask. This, while potentially the reason for placing in this view group, seems somewhat superfluous.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ArchitectureDescription

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

    · The attribute instances of architecture summary indicate [1] and the constraints talk about zero or more.
    · The constraints seem to indicate a relationship between the architecture enterprise and an Enterprise which is not shown.
    · An architecture summary is shown as a specific class rather than a stereotype. The necessity of this can be questioned.
  • Reported: UPDM 1.0b1 — Fri, 28 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Swedish Armed Forces General Comments

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

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

Ambiguos relation between Forecast and Milestone

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

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

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

    There should be a constraint ensuring that there is at least one Milestone related to the SystemGroup directly and to the Forecast that is related to this SystemGroup. It would not make any sense to have a Forecast at the specific Milestone when a SystemGroup does not even exist.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

GroupForecast metaclass should be Usage or Dependency

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

    Problem

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

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “forecasts”
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ForecastStandardsProfile metaclass should be Usage or Dependency.

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

    Problem

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

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

    Solution #2

    Remove ForecastStandardsProfile
    Change metaclass for TechnicalStandardsProfile to Package
    Use ElementImport or Ownership to link Forecast and TechnicalStandardsProfile
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

EffectAffectsNode metaclass should be Usage or Dependency

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

    Problem

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

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “affects”
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

NodeCausesEffect metaclass should be Usage or Dependency

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

    Problem

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

    OperationalCapabilityEffect.

    Solution

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

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

MilestonePoint metaclass should be Usage or Dependency

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

    Problem

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

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “governs”
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResourceCapability metaclass should be Usage or Dependency

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

    Problem

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

    Solution

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

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

OrganizationalResourceCapabilityConfiguration metaclass

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

    OrganizationalResourceCapabilityConfiguration metaclass should be Usage or Dependency.

    Problem

    Direction is not clear
    Name is not informative and too long

    Solution

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

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

OrganizationalRelationship metaclass should be Usage or Dependency

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

    Problem

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

    Solution

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

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

OperationalNodeCapabilityRequirement metaclass should be Usage or Dependenc

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

    Problem

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

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “requiredBy”
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityRoleResource metaclass should be Usage or Dependency

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

    Problem

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

    Solution

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

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

OperationalCapabilityRoleCompetence metaclass should be Usage or Dependency

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

    Problem

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

    Solution

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

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

ResourceCompetence metaclass should be Usage or Dependency

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

    Problem

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

    Solution

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

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

ResourceCapabilityConfiguration metaclass should be Usage or Dependency

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

    Problem

    Direction is not clear
    Name is not informative

    Solution

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

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

SystemsNodeElements metaclass should be Usage or Dependency

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

    Problem

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

    Solution

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

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

SystemGroupMember metaclass should be Usage or Dependency

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

    Problem

    Direction is not clear.
    Name is not too long.

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “groups”
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OperationalCapabilityEffect should be Usage or Dependency

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

    Problem

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

    Solution

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

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

8.6.37.3 Description

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

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

    UML terms are used. Description should be more about semantics, etc.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.36.3 Description

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

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

    Description should be more informative and clear.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityOperationalCapability metaclass should be Usage or Dependency

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

    Problem

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

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “supportedBy”
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityConfigurationCapabilities metaclass should be Usage or Dependency

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

    Problem

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

    Solution

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

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

DeliveredCapability metaclass should be Usage or Dependency

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

    Problem

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

    Solution

    Change metaclass to Usage or Dependency.
    Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
    Change name to “delivers”
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CapabilityRequirementCapability metaclass should be Usage or Dependency

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

    Problem

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

    Solution

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

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

8.6.35.3 Description

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

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

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

8.6.34.3 Description

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

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

    Description should be more informative - why and where this element should be used.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.15.3 Description

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

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

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

8.6.14.3 Description

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

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

    Description should be more informative - why and where this element should be used.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActivityRealization metaclass should be Realization

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

    Problem

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

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

8.7.2.3 Description

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

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

    Description should be more informative. What "association" means in this context?
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.18.3 Description

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

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

    UML terms are used. Description should be more about semantics, etc.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.17.3 Description

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

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

    Description should be more informative - why and where this element should be used.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.48.3 Description

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

    Specifies these are the elements associated with a SystemsNode."

    Description should be more informative. What "associated" means in this context?
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.39.3 Description

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

    Specifies the System elements configured with a System."

    It should be "Specifies the System elements configured with a SystemGroup". However I'm not sure if such description is enough.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.38.3 Description

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

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

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

8.5.13.3 Description

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

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

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

8.5.10.3 Description

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

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

    UML terms are used. Meaning and usage of this element should be described.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.5.9.3 Description

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

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

    UML terms are used. Meaning and usage of this element should be described.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.5.8.3 Description

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

    Asserts that a CapabilityRequirement is related to an OperationalCapability."

    The description is not clear. It is hard to understand what this relationship means.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.5.3 Description

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

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

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

8.6.3.3 Description

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

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

    The OCL does not allow SystemsNodes to be linked, but description says so.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.12.3 Description

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

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

    Forecast is linked to a SystemsGroup, not a System,
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.9.3 Description

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

    A data element exchanged in between systems."

    The description should be more informative.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.7.3 Description

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

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

    It is not clear what details spec is talking about. The description should be more informative.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.6.3 Description

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

    Asserts that a CommunicationPath realizes a SystemInterface."

    A description should be more informative.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.45.3 Description

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

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

    The description is not clear.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.43.3 Description

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

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

    UML terms are used. Meaning and usage of this element should be described
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.5.17.3 Description

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

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

    The description could provide more information.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.5.16.3 Description

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

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

    There is a big difference between Resource providing Capability and Capability requiring Resources. Which one is it?
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.31.3 Description

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

    OrganizationalRelationship describes the relationship between two OrganizationalResources."

    The description should be more informative"
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.28.3 Description

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

    This is the state machine for OV-5."

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

8.4.47.3 Description

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

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

    UML terms are used. Meaning and usage of this element should be described.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.18.3 Description

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

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

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

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

8.3.16.3 Description

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

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

    The description is not sufficient. It should explain what is the meaning of this element and how it is used.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Description is not sufficient.

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

    Description is not sufficient.
    8.7.2.3 Description
    Asserts that there is an association between a Forecast and a TechnicalStandardsProfile.
  • Reported: UPDM 1.0b1 — Fri, 14 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Text needs to be updated, since DeployedToSystemsNode does not exist

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

    "8.4.32.7 Semantics
    Use the DeployedToSystemsNode association to indicate deployment of
    OrganizationalResource to a SystemsNode.
    Use the OperationalCapabilityRoleResource association to indicate an
    OrganizationalRole played by the OrganizationalResource.
    Use the OrganizationalResourceCapabilityConfiguration association to indicate
    inclusion in a CapabilityConfiguration
    Use the DeployedToSystemsNode association to indicate deployment of
    OrganizationalResource to a SystemsNode.
    Use the DeployedToSystemsNode association to indicate deployment of
    OrganizationalResource to a SystemsNode."
  • Reported: UPDM 1.0b1 — Wed, 12 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.15.3 Description

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

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

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

8.3.14.3 Description

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

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

    Typo "PerformanceMeasurementrSet"
    PerformanceMeasurementSet does not include any PerformanceMeasures, since there is not such element. It includes actual values for each PerformanceParameterType that are owned by linked PerformanceParameterSet.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.23.3 Description

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

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

    If this element is needed only to facilitate UML usage, it is not needed as separate stereotype. If there is some other meaning, it should be defined in the description.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.19.3 Description

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

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

    It is not clear why this elements is needed and how it is used
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.17.3 Description

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

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

    If a OperationalCapabilityRole required Competency, it does not mean that Competency requires OperationalCapabilityRole, but the description says so.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.14.3 Description

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

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

    UML terms should not be used in descriptions.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.6.3 Description

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

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

    It is not clear clear if it is required or provided competency.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.22.3 Description

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

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

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

Stereotype for realization CommunicationsPathRealizesSystemInterface

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

    Stereotype for realization CommunicationsPathRealizesSystemInterface is too long
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Stereotype for realization RealizedOperationalCapability is too long

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

    Stereotype for realization RealizedOperationalCapability is too long
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Stereotype for interface realization RealizedSystemSpecification

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

    Stereotype for interface realization RealizedSystemSpecification is too long
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Stereotype for interface realization RealizedOperationalSpecification

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

    Stereotype for interface realization RealizedOperationalSpecification is too long
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.10.3 Description

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

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

    Conforming element has no connection with Forecast.
  • Reported: UPDM 1.0b1 — Thu, 27 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name ResourceCapability is not intuitive

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

    Sterotype for Association name ResourceCapability is not intuitive. Semantic meaning of the relation should be implied
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name ResourceCompetence is not intuitive

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

    Sterotype for Association name ResourceCompetence is not intuitive. It is not clear if it is provided Competence or required
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name ResourceCapabilityConfiguration

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

    Sterotype for Association name ResourceCapabilityConfiguration is not intuitive. Semantic meaning of the relation should be implied
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name SystemsNodeElements

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

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

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

Sterotype for Association name SystemGroupMember is not intuitive

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

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

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

Stereotype for dependency AssetMapping is not intuitive

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

    Stereotype for dependency AssetMapping is not intuitive. Semantic meaning of the relation should be implied
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Stereotype for dependency CompetenceRelationship is not intuitive

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

    Stereotype for dependency CompetenceRelationship is not intuitive. Semantic meaning of the relation should be implied
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name OrganizationalResourceCapabilityConfiguratio

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

    Sterotype for Association name OrganizationalResourceCapabilityConfiguration is not intuitive. Semantic meaning of the relation should be implied
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name OperationalNodeCapabilityRequirement

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

    Sterotype for Association name OperationalNodeCapabilityRequirement is not intuitive. Semantic meaning of the relation should be implied
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name OperationalCapabilityRoleResource

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

    Sterotype for Association name OperationalCapabilityRoleResource is not intuitive. Semantic meaning of the relation should be implied
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name ForecastStandardsProfile

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

    Sterotype for Association name ForecastStandardsProfile is not intuitive. Semantic meaning of the relation should be implied
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name EffectAffectsNode is not nice

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

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

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

Sterotype for Association name NodeCausesEffect is not nice

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

    Sterotype for Association name NodeCausesEffect is not nice. Should be simplified to "affects
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name MilestonePoint is not intuitive

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

    Sterotype for Association name MilestonePoint is not intuitive. Semantic meaning of the relation should be implied
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name OperationalCapabilityRoleCompetence

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

    Sterotype for Association name OperationalCapabilityRoleCompetence is not intuitive. Semantic meaning of the relation should be implied.
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name OperationalCapabilityEffect

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

    Sterotype for Association name OperationalCapabilityEffect is not intuitive. Semantic meaning of the relation should be implied
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name MaterielBehavior is not intuitive

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

    Sterotype for Association name MaterielBehavior is not intuitive. Semantic meaning of the relation should be implied
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name MaterielNode is not intuitive

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

    Sterotype for Association name MaterielNode is not intuitive. Semantic meaning of the relation should be implied
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.11:Doctrine

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

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

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

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

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

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

8.4.32:OrganizationalResource

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

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

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

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

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

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

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

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

8.3.8:Concern

  • Key: UPDM-223
  • Legacy Issue Number: 11754
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1] Asserts that this Concern links an ArchitecureView to a set of Stakeholders self.architectureView.getAppliedSubstereotypes(self.getApplicableStereotypes()- >any(qualifiedName='UPDM::ArchitectureView'))->notEmpty()

    [1] Asserts that this Concern links an ArchitecureView or one of its specializations to a set of Stakeholders self.architectureView-> forAll(getAppliedStereotype('UPDM::ArchitectureView')- >notEmpty())
    or self.architectureView->forAll(getAppliedStereotypes()> collect(allParents())>any(qualifiedName = 'UPDM::ArchitectureView') -> notEmpty() )

    [2] Asserts that there are zero or more Stakeholders who have this Concern
    self.stakeholders-> forAll(getAppliedStereotype('UPDM::Stakeholder')->notEmpty())

    [2] Asserts that there are zero or more Stakeholders who have this Concern
    self.subject->
  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.3.19:Stakeholder

  • Key: UPDM-222
  • Legacy Issue Number: 11753
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    8.3.19.3 Stakeholder Description
    Fix diagram - remove association between concern and Stakeholder. This is handled by the subject/usecase association.
    Change StakeholderConcern to dependency notation
    8.3.19.3 Stakeholder Associations
    delete concern[]
    8.3.19.6 Stakeholder Constraints

    [1] Asserts that there is at least one ArchitectureView associated with this Stakeholder self.architectureView-> forAll(getAppliedStereotype('UPDM::ArchitectureView')- >notEmpty())

    [1] Asserts that there is at least one ArchitectureView associated with this Stakeholder self.architectureView-> forAll(getAppliedStereotype('UPDM::ArchitectureView')- >notEmpty())
    or self.architectureView->forAll(getAppliedStereotypes()> collect(allParents())>any(qualifiedName = 'UPDM::ArchitectureView') -> notEmpty() )

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

8.4.13.5:OperationalActivity Associations

  • Key: UPDM-217
  • Legacy Issue Number: 11748
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    materiel is listed as an Association, but the diagram does not indicate the association.
    There isn't an association between OperationalActivity and Materiel, but there is a stereotypedAssociation, MaterielBehavior that is bidirectional, so there should be a dependency in the diagram as proposed for the solution for showing stereotyped associations

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

8.4.13.6:OperationalActivity Constratins

  • Key: UPDM-216
  • Legacy Issue Number: 11747
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    :[2] Asserts that for every callOperationAction in an OperationalActivity that refers to an Operation that is stereotyped OperationalTask, then:
    if the OperationalTask that is the operation of a callOperationAction that resides in a partition that represents an OperationalNode or a Property that is typed by an OperationalNode or one of its specializations, then o
    the OperationalTask must be owned by that OperationalNode and the OperationalTask must have at least one method that specifies a corresponding OperationalActivity owned by the OperationalNode, (an OperationalTask could also specify Interactions or StateTraces)
    OR o
    if the OperationalTask that is the operation of a callOperationAction that resides in a partition that represents an OperationalNodeSpecification or a Property that is typed by an OperationalNodeSpecification, then o
    the OperationalNodeSpecification must own the OperationalTask.

    This constraint forces the called operation to be owned by the OperationalActivity that represents the partition in which the callOperationResides and that is not generally the case.
    Resolution:Fix the OCL.
  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.2.11:Project Type

  • Key: UPDM-221
  • Legacy Issue Number: 11752
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    This stereotype doesn't have much use as is. Either delete it, or make it more meaningful
  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.2.10:Project -- 8.2.10.6 Constraints

  • Key: UPDM-220
  • Legacy Issue Number: 11751
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1] Asserts that there is one OrganizationalResource required for this Project

    [1] Asserts that there is one or more OrganizationalResources that own this Project
    Fix diagram to show 1 or more

    [2] Asserts that zero or more Milestones govern this Project through an DOLDElement self.getAllAttributes()>asOrderedSet()> select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::MilestonePoint')> notEmpty())>notEmpty()

    [2] Asserts that one or more Milestones govern this Project
    self.getAllAttributes()>asOrderedSet()> select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::MilestonePoint')> notEmpty())>notEmpty()

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

Reusable libraries cannot be created on order to model a SV-9.

  • Key: UPDM-229
  • Legacy Issue Number: 11760
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Technology does not exist in UPDM, so reusable libraries cannot be created on order to model a SV-9.

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

TimedTechnologyForecast

  • Key: UPDM-228
  • Legacy Issue Number: 11759
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    DoDAF spec says that a TimedTechnologyForecast should be linked to exact system and exact standard. Current profile allows linking a Forecast to a SystemGroup and TechnicalStandardsProfile only. A Forecast could be a relationship, linking Systems (or other entities) with Technologies and Standards
  • Reported: UPDM 1.0b1 — Thu, 6 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

MOD Agreement Issue

  • Key: UPDM-230
  • Legacy Issue Number: 11761
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    This is the agreement we reached with MOD to converge UPDM and MODAF.

    MOD will migrate M3 to a formal Mx (name TBD) data model. This is part of MOD’s intent eventually to migrate to IDEAS
    MOD will define a standard XML format for exchanging data conforming to the Mx data model.
    MOD and UPDM will define a bi-directional algorithmic mapping between UPDM and Mx data model
    An additional UPDM compliance point will be defined by a tool’s ability to export and import data that is compliant to the standard Mx data model according to 3, 4 & 5.
    UPDM will add an optional, normative section that specifies 6.
    A UPDM tool that implements 7 enables a vendor to claim the ability to produce MODAF architectures
  • Reported: UPDM 1.0b1 — Thu, 6 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sterotype for Association name CapabilityConfigurationCapabilities

  • Key: UPDM-232
  • Legacy Issue Number: 11784
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Sterotype for Association name CapabilityConfigurationCapabilities is not intuitive. Semantic meaning of the relation should be implied
  • Reported: UPDM 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Navigability for association

  • Key: UPDM-231
  • Legacy Issue Number: 11782
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

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

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

ProjectType has a generalization link to Project.

  • Key: UPDM-227
  • Legacy Issue Number: 11758
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    ProjectType has a generalization link to Project. This does not make any sense.

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

8.3.13:Goal

  • Key: UPDM-226
  • Legacy Issue Number: 11757
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    :8.3.13.3 Goal Description
    Fix diagram to show 1 or more OperationalCapabilities and 1 or more Visions associated with the Goal.
    8.3.13.3 Goal Associations
    fix multiplicity in both associatione to be [1..*]
  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.2.10:Project

  • Key: UPDM-219
  • Legacy Issue Number: 11750
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Change Milestone and Capability associations to the stereotyped dependency notation

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

8.2.8:Milestone

  • Key: UPDM-218
  • Legacy Issue Number: 11749
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    8.2.8.3 Description
    Change MilestonePoint to <<StereotypedAssociation>> notation in the diagram
    8.2.8.5
    Remove all associations
  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.22:OperationalNode

  • Key: UPDM-213
  • Legacy Issue Number: 11744
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    CapabilityRequirement_rule
    The constraint documentation is:
    [4] Asserts that this Node is required for delivery of an Operational Capability.
    The OCL for the constraint is:

    self.getAllAttributes()>asOrderedSet()>select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::OperationalNodeCapability')> notEmpty())>notEmpty()

    There is no stereotype in UPDM called OperationalNodeCapability. I think it should be OperationalNodeCapabilityRequirement.
    And if so, does the textual description make sense?
    Resolution:
    Revised Text:[4] Asserts that this Node is required for delivery of a CapabilityRequirement.

    self.getAllAttributes()>asOrderedSet()>select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::OperationalNodeCapabilityRequirement)> notEmpty())>notEmpty()
  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.13.3:OperationalActivity

  • Key: UPDM-212
  • Legacy Issue Number: 11743
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    In the description of an Operational Activity, the subsection called ProxyActivity is confusing. Proposed wording:
    Resolution:Proposed wording- A context-free OperationalActivity is defined with no specific context. The OperationalNode that wants to perform that context-free activity defines its own OperationalActivity that will act as a proxy for the context-free one. This proxy OperationalActivity (ProxyActivity) contains at least a callBehaviorAction referring to the context-free OperationalActivity. Optionally, an OperationalTask can be defined on the OperationlNode and the Specification attribute of that ProxyActivity can be set to that OperationalTask. Typically, the OperationalNode that defined the proxy has another OperationalActivity which uses the context-free OperationalActivity by specifying that the ProxyActivity is performed at that OperationalNode. The proxy is referenced using either a callBehaviorAction or a callOperationAction if the OperationalTask was defined for the proxy.
    Using this proxy pattern, multiple Operational Nodes can effectively perform the same context-free OperationalActivity. Instead of defining an OperationalTask on every OperationalNode that defines a proxy for the context-free OperationalActivity, create an OperationalNodeSpecification with an OperationalTask that corresponds to the context-free OperationalActivity. When an OperationalNode defines a ProxyActivity, it sets the Specification attribute on the proxy to the OperationalTask owned by the OperationalNodeSpecification and then the OperationalNode implements (realizes) the OperationalNodeSpecification. Using this pattern, it is easy to determine every OperationalNode that performs that context-free (common) OperationalActivity simply by examining the Method attribute of the corresponding OperationalTask, defined on the OperationalNodeSpecification, which will be a collection of the ProxyActivities.

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

8.6.48:SystemsNodeElements (03)

  • Key: UPDM-211
  • Legacy Issue Number: 11742
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    We need an Objective stereotype associated with Goal. The Objective will include timeboxed and quantitative attributes.

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

8.6.52:SystemTask

  • Key: UPDM-215
  • Legacy Issue Number: 11746
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    SystemTask-Method_rule
    This constraint is supposed to ensure that if the "method" attribute of a System Task (operation) is defined, it must be either a SystemFunction, SystemStateTrace or SystemEventTrace. Two problems: (1) the stereotype references correspond to the operational equivalents and (2) the OCL that should check for an SystemEventTrace casts the behavior to a "uml::StateMachine" but it should be a "uml::Interaction".
  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.29:OperationalTask

  • Key: UPDM-214
  • Legacy Issue Number: 11745
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    OperationalTask::Method_rule
    This constraint ensures that if the "method" attribute of an Operational Task (operation) is defined, it must be either an OperationalActivity, OperationalStateTrace or OperationalEventTrace. The OCL that checks for an OperationalEventTrace casts the behavior to a "uml::StateMachine" but it should be a "uml::Interaction".
  • Reported: UPDM 1.0b1 — Wed, 5 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Why TechnicalStandardsProfile is a ConformingElement.

  • Key: UPDM-204
  • Legacy Issue Number: 11639
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    ConformingElement is used for applying standards or performing measurements. TechnicalStandardsProfile should be just grouping Standards, so it does not need to extend ConformingElement
  • Reported: UPDM 1.0b1 — Sun, 4 Nov 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

System stereotype is lost if the instance of System class is created

  • Key: UPDM-203
  • Legacy Issue Number: 11637
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    System stereotype is lost if the instance of System class is created
  • Reported: UPDM 1.0b1 — Tue, 30 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

getAppliedStereotype OCL construct does not exist

  • Key: UPDM-201
  • Legacy Issue Number: 11635
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    getAppliedStereotype OCL construct does not exist

  • Reported: UPDM 1.0b1 — Tue, 30 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 4.3.4.6

  • Key: UPDM-200
  • Legacy Issue Number: 11611
  • Status: open  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Francis Thom)
  • Summary:

    An ArchitectureView may not conform to a Standard e.g. if the purpose of
    the ArchitectureDescription is to elaborate a new standard (e.g.
    concepts of operation). 'Conform' may need expanding and Constraint [6]
    may be too strict?

  • Reported: UPDM 1.0b1 — Thu, 11 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 4.3.4.5

  • Key: UPDM-199
  • Legacy Issue Number: 11610
  • Status: open  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Francis Thom)
  • Summary:

    Reword (part of the description for a Viewpoint appears under the
    description of the association for a Stakeholder).
  • Reported: UPDM 1.0b1 — Thu, 11 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 4.3.4.3

  • Key: UPDM-198
  • Legacy Issue Number: 11609
  • Status: open  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Francis Thom)
  • Summary:

    If a Concern is modelled as a stereotyped dependency (client being
    Stakeholder and supplier being ArchitectureView) then the notion of
    Stakeholders having concerns which are addressed by the ArchitectureView
    has been resolved.
  • Reported: UPDM 1.0b1 — Thu, 11 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

PerformanceMeasurePeriod or PerformanceMeasurementPeriod

  • Key: UPDM-206
  • Legacy Issue Number: 11641
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    PerformanceMeasurePeriod or PerformanceMeasurementPeriod. Both are used. Name PerformanceMeasurementPeriod should be used. 8.4.51

  • Reported: UPDM 1.0b1 — Sun, 4 Nov 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

TechnicalStandardsProfile should extend a Package

  • Key: UPDM-205
  • Legacy Issue Number: 11640
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    TechnicalStandardsProfile should extend a Package, so UML ownership could be reused for grouping Standards
  • Reported: UPDM 1.0b1 — Sun, 4 Nov 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Rule is in the OperationalView package

  • Key: UPDM-208
  • Legacy Issue Number: 11643
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Rule is in the OperationalView package. Since there is no specific Rule for SystemView, Rule should be moved to AllViews. 8.4.46

  • Reported: UPDM 1.0b1 — Sun, 4 Nov 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

PerformanceMeasurePeriod is in OperationalView package

  • Key: UPDM-207
  • Legacy Issue Number: 11642
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    PerformanceMeasurePeriod is in OperationalView package. It should be moved to AllViews. 8.4.51
  • Reported: UPDM 1.0b1 — Sun, 4 Nov 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6.48:SystemsNodeElements (02)

  • Key: UPDM-210
  • Legacy Issue Number: 11741
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    SystemsNodeElements should include SystemGroup so that we can include whole configurations.

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

8.6.48:SystemsNodeElements (01)

  • Key: UPDM-209
  • Legacy Issue Number: 11740
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    SystemsNodeElements should use Resource instead of OrganizationalResource. SO that SystemsNodes can be nested.

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

View/Viewpoint should be imported from SysML, not redefined

  • Key: UPDM-202
  • Legacy Issue Number: 11636
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    View/Viewpoint should be imported from SysML, not redefined
  • Reported: UPDM 1.0b1 — Tue, 30 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig. 8.31

  • Key: UPDM-184
  • Legacy Issue Number: 11585
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Diagram contains element that are not in the model - PerformanceMeasure and PerformanceMeasurementSet,

  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Goal, Policy, Standard and Doctrine

  • Key: UPDM-183
  • Legacy Issue Number: 11584
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Goal, Policy, Standard and Doctrine should be connected to elements using a stereotyped dependency. This gains SysML compliance, makes integration with Requirements tools easier. It would create atleast one new steretyped dependency similar to <<Satisfy>>.,

  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Technologies should be first class objects

  • Key: UPDM-190
  • Legacy Issue Number: 11594
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    SV-9 talks about forecasted technologies, their impact to the systems, forecast covering services and service areas. In order to facilitate reusability Technologies should be first class objects.

  • Reported: UPDM 1.0b1 — Thu, 4 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.44

  • Key: UPDM-189
  • Legacy Issue Number: 11590
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Description for ResourceCompetence does not explain the difference from CompetenceRelationship. It should be reworked
  • Reported: UPDM 1.0b1 — Fri, 28 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.7.3 Association between Standard and ConformingElement

  • Key: UPDM-182
  • Legacy Issue Number: 11583
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Association between Standard and ConformingElement should be navigable in one direction only. Standard should not be changed if Elements is applied to it., 8.7.3

  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.7.3

  • Key: UPDM-181
  • Legacy Issue Number: 11582
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Standard is too restrictive about linked element. Any element should be able to satisfy Standard, 8.7.3

  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML composite structure should be reused

  • Key: UPDM-188
  • Legacy Issue Number: 11589
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    NetworkPaths, SystemSystemSoftware, SystemNodeElements should be removed and UML composite structure should be reused
  • Reported: UPDM 1.0b1 — Fri, 28 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.5.10

  • Key: UPDM-187
  • Legacy Issue Number: 11588
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Effect could be a regular Activity instead of OpaqueBehavior, which is "A behavior with implementation-specific semantics.",

  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 4.3.3.3

  • Key: UPDM-197
  • Legacy Issue Number: 11608
  • Status: open  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Francis Thom)
  • Summary:

    This description needs to be brought in-line with the description in
    section 4.3.4.3
  • Reported: UPDM 1.0b1 — Thu, 11 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 5.2.1

  • Key: UPDM-196
  • Legacy Issue Number: 11607
  • Status: open  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Francis Thom)
  • Summary:

    DLODIssues Type should be an enumerated list of 'issues' (as opposed to
    colours) and should list 'None Outstanding', 'Manageable', 'Critical',
    'Unknown' and 'Not Required'.
  • Reported: UPDM 1.0b1 — Thu, 11 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 3-3: AcV-2 View Example

  • Key: UPDM-195
  • Legacy Issue Number: 11606
  • Status: open  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Francis Thom)
  • Summary:

    This is not an example of an AcV-2 View See www.modaf.com for an
    example
  • Reported: UPDM 1.0b1 — Thu, 11 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 4.2.4.3

  • Key: UPDM-194
  • Legacy Issue Number: 11605
  • Status: open  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Francis Thom)
  • Summary:

    The reference to CADMID should be removed as this contradicts the
    statement of process neutrality in the Rationale (section 1.7.1)
  • Reported: UPDM 1.0b1 — Thu, 11 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Qualified name in the OCL constraints should be full

  • Key: UPDM-193
  • Legacy Issue Number: 11598
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Qualified name in the OCL constraints should be full, not just "UPDM::StereotypeName"

  • Reported: UPDM 1.0b1 — Thu, 4 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.5.5

  • Key: UPDM-192
  • Legacy Issue Number: 11596
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Why do you need CapabilityDependency. Regular Dependency could be used
  • Reported: UPDM 1.0b1 — Thu, 4 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.32.9

  • Key: UPDM-186
  • Legacy Issue Number: 11587
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    OrganizationalRole has bad chapter number, 8.4.32.9

  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.23 - Why OperationalNodePort is needed

  • Key: UPDM-185
  • Legacy Issue Number: 11586
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Why OperationalNodePort is needed?, 8.4.23

  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.5.4

  • Key: UPDM-191
  • Legacy Issue Number: 11595
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    CapabilityConfigurationCapabilities is plural, while other stereotyped associations are not
  • Reported: UPDM 1.0b1 — Thu, 4 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.11

  • Key: UPDM-180
  • Legacy Issue Number: 11581
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Doctrine is too restrictive about linked element. Any element should be able to satisfy Doctrine, 8.3.11

  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.41

  • Key: UPDM-179
  • Legacy Issue Number: 11580
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Policy is too restrictive about linked element. Any element should be able to satisfy Policy, 8.4.41

  • Reported: UPDM 1.0b1 — Wed, 10 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.5.6

  • Key: UPDM-178
  • Legacy Issue Number: 11579
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    CapabilityOperationalCapability could be replaced by UML metaproperty useCase., 8.5.6
  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CommunicationsLink/Path/System vs CommunicationLink/Path/System

  • Key: UPDM-173
  • Legacy Issue Number: 11574
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    CommunicationsLink/Path/System vs CommunicationLink/Path/System. What is the correct name?,

  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.10

  • Key: UPDM-172
  • Legacy Issue Number: 11573
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    SystemFunction, SystemInterface, CommunicationLink, DataExchange cannot be measured as stated in DoDAF spec:
    "SV-7 builds on SV-1, SV-2, SV-4, and SV-6 by
    specifying performance parameters for systems and system hardware/software items and their
    interfaces (defined in SV-1), communications details (defined in SV-2), their functions (defined
    in SV-4), and their system data exchanges (defined in SV-6).", 8.3.10

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.46

  • Key: UPDM-166
  • Legacy Issue Number: 11567
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    DoDAF spec specifies these Rule types: "One of: Structural Assertion, Action Assertion, Derivation". It is lost in the UPDM., 8.4.46

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

MaterielBehavior is not needed - Section 8.4.10

  • Key: UPDM-165
  • Legacy Issue Number: 11566
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    MaterielBehavior is not needed. OwnedBehavior property for BehavioredClassifier could be reused for linking Materiel and behaviors., 8.4.10

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.14.6

  • Key: UPDM-168
  • Legacy Issue Number: 11569
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    There should be a constraint defining that a Classifier for a PerformanceMeasurementSet should be PerformanceParameterSet, 8.3.14.6

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.47

  • Key: UPDM-167
  • Legacy Issue Number: 11568
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    TaskInvocation is listed in OperationalView packages, however belongs to both Operational and Systems Views., 8.4.47

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Possible conflict between Viewpoint/Stakeholder/Concern in UPDM and SysML

  • Key: UPDM-177
  • Legacy Issue Number: 11578
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Possible conflict between Viewpoint/Stakeholder/Concern in UPDM and SysML. Stakeholder and Concern are String types properties in SysML and they are first class constructs in UPDM
  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.23

  • Key: UPDM-176
  • Legacy Issue Number: 11577
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Name conflict with SysML::Viewpoint,

  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.2

  • Key: UPDM-164
  • Legacy Issue Number: 11565
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    ActivityRealization is Association, while CommunicationPathRealization is a Realization. Seems to be inconsistent., 8.4.2.

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

inconsistencies

  • Key: UPDM-163
  • Legacy Issue Number: 11564
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Some "realizations" are relationships - ActivityRealization, some - objects - OperationalActivityRealization. Seems to be inconsistent and misleading.,

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.11.6

  • Key: UPDM-175
  • Legacy Issue Number: 11576
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    OCL constraint is missing for the DataExchange, constraining that realization should be "Needline" (Association), 8.6.11.6

  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.8.6

  • Key: UPDM-174
  • Legacy Issue Number: 11575
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    OCL constraint is missing for the InformationExchange, constraining that realization should be "Needline" (Association), 8.4.8.6

  • Reported: UPDM 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig. 8.27

  • Key: UPDM-170
  • Legacy Issue Number: 11571
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Diagram for PerformanceParameterSet does not show the association to the ConformingElement.,

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.16.6

  • Key: UPDM-169
  • Legacy Issue Number: 11570
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    There should be a constraint defining that an Owner of PerformanceParameterType should be stereotyped PerformanceParameterSet, 8.3.16.6

  • Reported: UPDM 1.0b1 — Tue, 9 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.10.3

  • Key: UPDM-171
  • Legacy Issue Number: 11572
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Conforming element description: "ConformingElement provides a link from profile elements to specific standards in the context of a forecast." It is not just forecast, but performance measurement as well, 8.3.10.3

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.15

  • Key: UPDM-155
  • Legacy Issue Number: 11556
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    According to DoDAF specification, a Network is "A collection of communications links (and systems nodes and
    systems where applicable)". Current implementation imply that Systems and SystemsNodes are not a part of Network, 8.6.15

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.15.3

  • Key: UPDM-154
  • Legacy Issue Number: 11543
  • Status: open  
  • Source: Anonymous
  • Summary:

    "A Network is a collection of one or more CommunicationPaths. It may contain multiple CommunicationPaths between
    the same pair of Systems. This is typically realized by the Network owning a set of CommunicationPaths." This is not completely true. A network is a System, so it can be composed from other Systems, 8.6.15.3

  • Reported: UPDM 1.0b1 — Sun, 23 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.10

  • Key: UPDM-158
  • Legacy Issue Number: 11559
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    DataElementSystemFunction is not needed, since you can tie SystemFunction and DataElements via activity (SystemFunction) parameters, 8.6.10

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.4

  • Key: UPDM-157
  • Legacy Issue Number: 11558
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    According to DoDAF spec, CommunicationLink is "A communications link connects systems nodes or systems
    (including communications systems)". A CommunicationsPath is "A series of communications links that support an interface (from
    SV-1)". That means that Systems and SystemsNodes may be included in CommunicationsPath. Right now, only CommunicationsSystems are allowed., 8.6.4

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.18.3

  • Key: UPDM-160
  • Legacy Issue Number: 11561
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Description for RealizedSystemSpecification states: "Specifies that a System or one of its sub stereotypes realizes an interface stereotyped SystemFunctionSpecification or one
    of its sub stereotypes." However, there are no sub stereotypes, 8.6.18.3

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.3

  • Key: UPDM-159
  • Legacy Issue Number: 11560
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    According to DoDAF spec CommunicationLink is "A communications link connects systems nodes or systems
    (including communications systems)". Now only Systems are allowed., 8.6.3

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.4.5

  • Key: UPDM-153
  • Legacy Issue Number: 11542
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    CommunicationPath must have a Network assigned. There might be no Networks, 8.6.4.5

  • Reported: UPDM 1.0b1 — Sun, 23 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.5

  • Key: UPDM-152
  • Legacy Issue Number: 11541
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    "CommunicationPath is realized by a CommunicationsSystem". In order to get a sequence of Systems that compose a CommunicationPath we need to use supplierDependency collection. But it is not navigable and not ordered., 8.6.5

  • Reported: UPDM 1.0b1 — Sun, 23 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Why do you need a SystemPort if it does not add any new information, 8.6.44

  • Key: UPDM-148
  • Legacy Issue Number: 11537
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Why do you need a SystemPort if it does not add any new information, 8.6.44

  • Reported: UPDM 1.0b1 — Sun, 23 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.11

  • Key: UPDM-147
  • Legacy Issue Number: 11536
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    It is not described how DataExchange is related to SystemInterface and DataElement, 8.6.11

  • Reported: UPDM 1.0b1 — Sun, 23 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.2

  • Key: UPDM-162
  • Legacy Issue Number: 11563
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    ActivityRealization should be moved to AllViews package from OperationalView, since it talks about both SystemFunctions and OperationalActivities,

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig. 8.142

  • Key: UPDM-161
  • Legacy Issue Number: 11562
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    OperationalActivityRealization, SystemServiceConsumer, SystemServiceProvider should be displayed as System sub stereotype.,

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

How can you show the CommunicationPathRealizesSystemInterface?,

  • Key: UPDM-150
  • Legacy Issue Number: 11539
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    How can you show the CommunicationPathRealizesSystemInterface?,

  • Reported: UPDM 1.0b1 — Sun, 23 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.3

  • Key: UPDM-149
  • Legacy Issue Number: 11538
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    There is no way to provide type (tcp/ip, wireless, etc) for CommunicationLink, 8.6.3

  • Reported: UPDM 1.0b1 — Sun, 23 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.4

  • Key: UPDM-151
  • Legacy Issue Number: 11540
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Network is a collection of Systems and CommunicationLinks, why explicitly define the collection of CommunicationPaths, 8.6.4
  • Reported: UPDM 1.0b1 — Sun, 23 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.48

  • Key: UPDM-156
  • Legacy Issue Number: 11557
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    SystemNodeElements is duplicated by regular UML composite structures, 8.6.48

  • Reported: UPDM 1.0b1 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

CompetenceRelationship

  • Key: UPDM-140
  • Legacy Issue Number: 11486
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Is it OK to have "Relationship" in the stereotype name? This is not common UML practice. Chapter 8.4.6

  • Reported: UPDM 1.0b1 — Wed, 19 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

time/date related attributes

  • Key: UPDM-139
  • Legacy Issue Number: 11485
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Some time/date related attributes are Strings, some TimeInterval. It could be unified
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8..4.22.4

  • Key: UPDM-138
  • Legacy Issue Number: 11484
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Decomposition level for OperationalNode should be a derived property
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.33.3

  • Key: UPDM-146
  • Legacy Issue Number: 11535
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    "A System can be expressed in UML using a variety of
    constructs, for example, a component or a class.". Stereotype <<System>> can be assigned only to the Class., 8.6.33.3

  • Reported: UPDM 1.0b1 — Sun, 23 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

System description should talk about linking to the SystemFunctions

  • Key: UPDM-145
  • Legacy Issue Number: 11534
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    System description should talk about linking to the SystemFunctions - via System Tasks, 8.6.33

  • Reported: UPDM 1.0b1 — Sun, 23 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemTask should have SystemFunction as method property?

  • Key: UPDM-144
  • Legacy Issue Number: 11533
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    SystemTask should have SystemFunction as method property? Not clear from a description, 8.6.52

  • Reported: UPDM 1.0b1 — Sun, 23 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SystemActivityFunction is used in examples., p. 398

  • Key: UPDM-143
  • Legacy Issue Number: 11532
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    SystemActivityFunction is used in examples., p. 398

  • Reported: UPDM 1.0b1 — Sun, 23 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

InterfaceRealization

  • Key: UPDM-142
  • Legacy Issue Number: 11531
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    InterfaceRealization should be the metaclass for RealizedSystemSpecification., 8.6.18

  • Reported: UPDM 1.0b1 — Sun, 23 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OrganizationalRelationship

  • Key: UPDM-141
  • Legacy Issue Number: 11487
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Is it OK to have "Relationship" in the stereotype name? This is not common UML practice. Chapter 8.4.31

  • Reported: UPDM 1.0b1 — Wed, 19 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.163

  • Key: UPDM-134
  • Legacy Issue Number: 11480
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Why SystemTask - Trigger association is navigable to one way only, and OperationalTask - trigger is navigable both ways?
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sections 9.2.2 and 8.2.7

  • Key: UPDM-133
  • Legacy Issue Number: 11479
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    DLOD elements appears as stereotype and as Class in the Class Library
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Table 9.2: Table of enumeration literals contains duplicates

  • Key: UPDM-132
  • Legacy Issue Number: 11478
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Table of enumeration literals contains duplicates
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.22.3

  • Key: UPDM-131
  • Legacy Issue Number: 11477
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    There can be a confusion between ExternalReferences and ExternalReference
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.28.3

  • Key: UPDM-137
  • Legacy Issue Number: 11483
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    OperationalStateTrace description - "This is the state machine for OV-5."
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.43

  • Key: UPDM-136
  • Legacy Issue Number: 11482
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    It will be hard to visualize SystemInterfaceImplementsNeedline because it is a dependency between relationships
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.7.4.4

  • Key: UPDM-130
  • Legacy Issue Number: 11476
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Having service and serviceArea as String properties for Standard prohibits of usage DISR ar model library
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sections 8.6.53 and 8.1

  • Key: UPDM-129
  • Legacy Issue Number: 11475
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    SystemView or Systems View
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figures 8.23 and 8.161

  • Key: UPDM-135
  • Legacy Issue Number: 11481
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Doctrine-SystemTask association contains different multiplicities on different diagrams
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig. 8.120

  • Key: UPDM-116
  • Legacy Issue Number: 11462
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Why DataExchange cannot access DataElements in carries?
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.10

  • Key: UPDM-115
  • Legacy Issue Number: 11461
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    What is the preffered way for visualizing some of the stereotyped associations, for example, DataElementSystemFunction, where connected elements are from different products
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.30.3

  • Key: UPDM-121
  • Legacy Issue Number: 11467
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    SV10 talks about 3 variations (a, b, and c) in the description, but this is information does not appear in the model
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.126

  • Key: UPDM-120
  • Legacy Issue Number: 11466
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Relation between OperationalActivityRealization and System should be generalization, not extension
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig. 8.142: System cannot be decomposed from other systems

  • Key: UPDM-125
  • Legacy Issue Number: 11471
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    System cannot be decomposed from other systems
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.142 SystemGroupMember

  • Key: UPDM-124
  • Legacy Issue Number: 11470
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    SystemGroupMember is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.54 Trigger stereotype conflicts with UML metaclass

  • Key: UPDM-128
  • Legacy Issue Number: 11474
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Trigger stereotype conflicts with UML metaclass
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.156

  • Key: UPDM-127
  • Legacy Issue Number: 11473
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    SystemNodeElements is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.113: Realization between stereotypes has no semantic meaning

  • Key: UPDM-114
  • Legacy Issue Number: 11460
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Realization between stereotypes has no semantic meaning
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.113

  • Key: UPDM-113
  • Legacy Issue Number: 11459
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    CommPathFromTo is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.142 SystemSystemSoftware

  • Key: UPDM-123
  • Legacy Issue Number: 11469
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    SystemSystemSoftware is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.142

  • Key: UPDM-122
  • Legacy Issue Number: 11468
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Realization between stereotypes has no semantic meaning
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.124

  • Key: UPDM-118
  • Legacy Issue Number: 11464
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    NetworkPaths is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig. 8.121

  • Key: UPDM-117
  • Legacy Issue Number: 11463
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    GroupForecast is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.151

  • Key: UPDM-126
  • Legacy Issue Number: 11472
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Dependency between stereotypes has no semantic meaning
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.16

  • Key: UPDM-119
  • Legacy Issue Number: 11465
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Why it is NetworkPaths, not NetworkPath
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8

  • Key: UPDM-107
  • Legacy Issue Number: 11453
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    DeliveredCapability is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.31.3

  • Key: UPDM-106
  • Legacy Issue Number: 11452
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    DoDAF spec says about command, control, coordination, etc organizational relationships. UPDM says about solid and dotted. It is incorrent to have graphical difference as data type.
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.38.3

  • Key: UPDM-105
  • Legacy Issue Number: 11451
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    OV6 talks about 3 variations (a, b, and c) in the description, but this is information does not appear in the model
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.94 OperationalCapabilityEffect

  • Key: UPDM-110
  • Legacy Issue Number: 11456
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    OperationalCapabilityEffect is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.94

  • Key: UPDM-109
  • Legacy Issue Number: 11455
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    EffectAffectsNode is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.59

  • Key: UPDM-108
  • Legacy Issue Number: 11454
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    OperationalNodeCapabilityRequirement is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.8.3

  • Key: UPDM-95
  • Legacy Issue Number: 11441
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Associations between InformationExchange and Needline/SystemInterface are navigable to one direction only, so you cannot "reach" SystemInterface/Needline from InformationExchange. Is this done deliberately?
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.5.3

  • Key: UPDM-94
  • Legacy Issue Number: 11440
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    OperationalCapabilityRoleCompetence is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.6.2

  • Key: UPDM-112
  • Legacy Issue Number: 11458
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    CommPathFromTo stereotype for association will look weird on the diagram
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Extremely long stereotype names for associations will distort diagrams

  • Key: UPDM-111
  • Legacy Issue Number: 11457
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Extremely long stereotype names for associations will distort diagrams. For example OperationalNodeCapabilityRequirement
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.51 CapabilityRequirementCapability

  • Key: UPDM-100
  • Legacy Issue Number: 11446
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    CapabilityRequirementCapability is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.51

  • Key: UPDM-99
  • Legacy Issue Number: 11445
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    CapabilityOperationalCapability is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.22.5

  • Key: UPDM-104
  • Legacy Issue Number: 11450
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Two "effect" association end for OperationalNode
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.59

  • Key: UPDM-103
  • Legacy Issue Number: 11449
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Needline is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.45.6

  • Key: UPDM-102
  • Legacy Issue Number: 11448
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    "NodeCasuseEffect.
    Typo"
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.52

  • Key: UPDM-101
  • Legacy Issue Number: 11447
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Realization between stereotypes has no semantic meaning
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.46 MaterielBehavior

  • Key: UPDM-97
  • Legacy Issue Number: 11443
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    MaterielBehavior is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.46

  • Key: UPDM-96
  • Legacy Issue Number: 11442
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Lot of "MaterieBehavior". Typo
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.50

  • Key: UPDM-98
  • Legacy Issue Number: 11444
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    ActivityRealization is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.14.3

  • Key: UPDM-83
  • Legacy Issue Number: 11429
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    "A PerformanceMeasurementrSet includes a set of PerformanceMeasures for each PerformanceMeasurePeriod. The set is applied to ConformingElements. (See UPDM Class Library). This stereotype is applied to instances of classes stereotyped PerformanceParameterSet.
    ConformingElements are not part of UPDM Class Library anymore"
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.9

  • Key: UPDM-82
  • Legacy Issue Number: 11428
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Possible conflict between Conform stereotype in SysML and UPDM
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.18.3

  • Key: UPDM-91
  • Legacy Issue Number: 11437
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    "Specification is the ancestor of all the stereotypes that extend Instance Specification. It implements the common attribute, description.
    Attribute is missing"
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.17.3 ResourceCapabilityConfiguration

  • Key: UPDM-90
  • Legacy Issue Number: 11436
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    ResourceCapabilityConfiguration is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.16.9 Wrong chapter number for requirements

  • Key: UPDM-86
  • Legacy Issue Number: 11432
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Wrong chapter number for requirements
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.16.9

  • Key: UPDM-85
  • Legacy Issue Number: 11431
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Possible conflict between Requirement stereotype in SysML and UPDM
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.2

  • Key: UPDM-93
  • Legacy Issue Number: 11439
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    ActivityRelazation could be potentially implemented as ownedBehavior
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.24.3

  • Key: UPDM-92
  • Legacy Issue Number: 11438
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Association between Vision and Enterprise is duplicated by UML ownership
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.4.3

  • Key: UPDM-79
  • Legacy Issue Number: 11425
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Dependency "Conform" has no sematic meaning between stereotype and confuses reader.
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.2.10.3 Diagram

  • Key: UPDM-78
  • Legacy Issue Number: 11424
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Diagram is too small
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.17.3 ResourceCompetence

  • Key: UPDM-88
  • Legacy Issue Number: 11434
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    ResourceCompetence is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.17.3

  • Key: UPDM-87
  • Legacy Issue Number: 11433
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    ResourceCapability is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.8.3 StakeholderConcern

  • Key: UPDM-81
  • Legacy Issue Number: 11427
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    StakeholderConcern is duplicated by association between steretype
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.8.3

  • Key: UPDM-80
  • Legacy Issue Number: 11426
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    There are 2 associations between Concern and stakeholder
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.15.3

  • Key: UPDM-84
  • Legacy Issue Number: 11430
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    "This Stereotype is applied to the PerformanceMeasurementSet in the UPDM ClassLibrary.
    PerformanceMeasurementSet is not part of UPDM Class Library"
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.3.17.3 OperationalCapabilityRoleResource

  • Key: UPDM-89
  • Legacy Issue Number: 11435
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    OperationalCapabilityRoleResource is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.5.2 Capability and 8.3.21 StrategicMission

  • Key: UPDM-67
  • Legacy Issue Number: 11394
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Capability and StrategicMission should have an association between them (BMM, where Capability is mapped to Strategy of BMM)
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.6.48.6

  • Key: UPDM-66
  • Legacy Issue Number: 11393
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1] Asserts that the SystemsNodes are required to be deployed to zero or more Locations, have OrganizationalResources, HardwareItems, SoftwareItems, Networks, SystemGroup,or Systems deployed on them, and house OperationalNodes; and that these are the elements associated with this SystemsNode.
    let e1:uml::Class = self.oclAsType(uml::Association).endType-> at(1).oclAsType(uml::Class) in let e2:uml::Class = self.oclAsType(uml::Association).endType-> at(2).oclAsType(uml::Class) in
    (e1.getAppliedStereotype('UPDM::SystemsNode')>notEmpty() and (e2.getAppliedStereotype('UPDM::System')>notEmpty() or e2.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::System') >notEmpty() or e2.getAppliedStereotype('UPDM::OperationalNode')>notEmpty() or e2.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OperationalNode') >notEmpty() or e2.getAppliedStereotype('UPDM::Location')>notEmpty() or e2.getAppliedStereotype('UPDM::OrganizationalResource')->notEmpty()or
    e2.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OrganizationalResource') ->notEmpty() or
    e2.getAppliedStereotype('UPDM::SystemGroup)->notEmpty())
    )<<<Note - I think this is an extra parenthesis here>>>

    or (e2.getAppliedStereotype('UPDM::SystemsNode')>notEmpty() and (e1.getAppliedStereotype('UPDM::System')>notEmpty() or e1.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::System') >notEmpty() or e1.getAppliedStereotype('UPDM::OperationalNode')>notEmpty() or e1.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OperationalNode') >notEmpty() or e1.getAppliedStereotype('UPDM::Location')>notEmpty() or e1.getAppliedStereotype('UPDM::OrganizationalResource')->notEmpty() or
    e1.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OrganizationalResource') ->notEmpty() or
    e1.getAppliedStereotype('UPDM::SystemGroup')->notEmpty())

    SystemsNodeElements should use Resource instead of OrganizationalResource so that SystemsNodes can be nested.

    SystemsNodeElements should include SystemGroup so that we can include whole configurations.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.6.33.6 Constraints

  • Key: UPDM-63
  • Legacy Issue Number: 11390
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    MISSING Documentation, and thus missing a constraint number. [2] inserted and the rest incremented
    [2] "Asserts that there is an association between a System and SystemSoftware."
    self.getAllAttributes().association ->
    any (getAppliedStereotype('UPDM::SystemSystemSoftware')>notEmpty())>notEmpty()
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.6.33.6 Constraints

  • Key: UPDM-62
  • Legacy Issue Number: 11389
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1] [1] If a Needline exists between two OperationalNodes, then there must exist a SystemsNode that hosts each of the OperationalNodes and a SystemInterface must exist between them.
    This OCL only checks for the existence of a SystemInterface it says nothing about the Needline and the Systems nodes.
    The systemsNodes would have to have Systems that are connected by the System Interface, and the SystemInterfaceImplementsNeedline association to associate the Needline and the SystemInterface. The constraint as described in [1] would have to be on SystemsNode, not on an individual system. This constraint may be OK for :"There must be at least one SystemInterface defined on a System".
    self.getAllAttributes()>asOrderedSet()>
    select(association->notEmpty()).association->any
    (getAppliedStereotype('UPDM::SystemInterface')> notEmpty())>notEmpty()
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.15.7 Semantics

  • Key: UPDM-72
  • Legacy Issue Number: 11399
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    We need a usage statement like this:
    Usage: Create a class and stereotype if <<PerformanceParameterSet>>. This Class will be associated with the Conforming Elements to which its instances apply.
    Create attributes that specify the performance measurements that are to be performed
    Create an instance of a the PerformanceParameterSet, and stereotype it <<PerformanceMeasurementSet>> this measurement set will have a PerformanceMeasurementPeriod that is one of Baseline, Target Actual.
    Provide the slot values for each of the attributes specified in the PerformanceParamenter set for this performance period.
    Do the same for the other two performance periods
    Set the conformingElement property to the corresponding element to which the PerformanceParameterSet applies, and set the performanceMeasurements property in the element.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.15.5 Associations

  • Key: UPDM-71
  • Legacy Issue Number: 11398
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    conformingelement : ConformingElement [1]
    multiplicity is wrong - should be [1..*]
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.6.10 DataElementSystemFunction

  • Key: UPDM-65
  • Legacy Issue Number: 11392
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    This association refers to SystemFunction but should refer to System and SystemFunctionSpecification. However, it also appears that this stereotyped association and its constraints is not necessary. If it is, then OperationalNode and OperatoinalNodeSpecification should have an "InformationElementOperationalNode" association.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 4.6.50.6 Constraints

  • Key: UPDM-64
  • Legacy Issue Number: 11391
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1] Asserts that this SystemState models the behavior of a System, one of its specializations or an OperationalActivityRealization
    self.owner.getAppliedStereotype('UPDM::OperationalActivityRealization')->notEmpty() or
    self.owner.getAppliedStereotype('UPDM::System')->notEmpty() or
    self.owner.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::System') ->notEmpty())

    Don't need self.owner.getAppliedStereotype('UPDM::OperationalActivityRealization')->notEmpty() or
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Extensions section should not be empty,ie section 8.2.2.1

  • Key: UPDM-74
  • Legacy Issue Number: 11420
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Even is the stereotype generalizes other stereotype, its Extensions section should not be empty, since extension is inherited. Currently the spec if very hard to read.
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 7.3, 8.1

  • Key: UPDM-73
  • Legacy Issue Number: 11419
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    "UPDM Class Library" or "Class Library". Both names are in the diagrams
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.14.5 Associations

  • Key: UPDM-70
  • Legacy Issue Number: 11397
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    conformingelement : ConformingElement [1]
    multiplicity is wrong - should be [1..*]
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.14 PerformanceMeasureSet

  • Key: UPDM-69
  • Legacy Issue Number: 11396
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    PerformanceMeasureSet should be PerformanceMeasurementSet
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.2.9

  • Key: UPDM-77
  • Legacy Issue Number: 11423
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    MilestonePoint is duplicated by association between stereotypes
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 9.3.7

  • Key: UPDM-76
  • Legacy Issue Number: 11422
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    TimeInterval datatype conflicts with UML metaclass TimeInterval.
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.13 Goal

  • Key: UPDM-68
  • Legacy Issue Number: 11395
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    We need an Objective stereotype associated with Goal. The Objective will include timeboxed and quantitative attributes.
    Since Mission is associated with Vision and vision with Goal, then we can follow the association to Objective to obtain the objectives of the mission. (BMM).
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Association end names should be on the diagrams

  • Key: UPDM-75
  • Legacy Issue Number: 11421
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Association end names should be on the diagrams
  • Reported: UPDM 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.13.6 Constraints

  • Key: UPDM-57
  • Legacy Issue Number: 11384
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [4] Asserts that an OperationalActivity must be owned by an OperationalNode, one of its specializations or an OperationalCapabilityRealization.

    let x:uml::Class = self.owner.oclAsType(uml::Class) in
    x.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty() or
    x.getAppliedStereotype('UPDM::OperationalNode')->notEmpty() or
    x.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty()

    Don't need :
    x.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty() or
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.6.36.6 Constraint

  • Key: UPDM-56
  • Legacy Issue Number: 11383
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [5]
    In an SystemFunction, if a callBeahviorAction that references a stereotyped SystemFunctionbut is NOT contained in a partition that meets the OwnedBehavior_rule constraint, then the constraint fails. It should be valid if the context of the activity referenced in the call behavior action is owned by the context of theSystemFunction that owns the call behavior action.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.44.6 Constraints

  • Key: UPDM-61
  • Legacy Issue Number: 11388
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1] Asserts that there are zero or more Competencies provided by the Resource and that zero or more Resources provide a Competence and that these are the elements associated by this association
    (self.endType-> at(1).getAppliedStereotype('UPDM::Competence')-> notEmpty() and
    self.endType-> at(2).getAppliedStereotype('UPDM::Resource')-> notEmpty() or
    self.base_Association.endType-> at(2).getAppliedStereotypes()> collect(allParents())> any(qualifiedName = 'UPDM::Resource') ->notEmpty()
    ) or
    (self.endType-> at(2).getAppliedStereotype('UPDM::Competence')-> notEmpty() and
    self.endType-> at(1).getAppliedStereotype('UPDM::Resource')-> notEmpty() or
    self.base_Association.endType-> at(1).getAppliedStereotypes()> collect(allParents())> any(qualifiedName = 'UPDM::Resource') ->notEmpty() )

    Don't need 'baseAssociation' clause
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.29.7 Semantics

  • Key: UPDM-60
  • Legacy Issue Number: 11387
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    sematics statement uses terms from am earlier submission - e.g. OrganizationalRole
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.4.4 Attributes

  • Key: UPDM-51
  • Legacy Issue Number: 11378
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    ArchitectureView::variation is missing description
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.5.16.6 Constratints

  • Key: UPDM-50
  • Legacy Issue Number: 11377
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1] Asserts that a ResourceCapability association exists between a Resource and the Capabilities that it provides and that these are the elements associated with this association
    (self.endType-> at(1).owner.getAppliedStereotype('UPDM::Capability')-> notEmpty() and
    self.endType-> at(2).owner.getAppliedStereotype('UPDM::Resource')-> notEmpty()or
    self.base_Association.endType-> at(2).getAppliedStereotypes()>collect(allParents())> any(qualifiedName = 'UPDM::Resource') ->notEmpty() ) or
    (self.endType-> at(2).owner.getAppliedStereotype('UPDM::Capability')-> notEmpty() and
    self.endType-> at(1).owner.getAppliedStereotype('UPDM::Resource')-> notEmpty()or
    self.base_Association.endType-> at(1).getAppliedStereotypes()>collect(allParents())> any(qualifiedName = 'UPDM::Resource') ->notEmpty())

    Don't need .'baseAssociation'clause
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.28.6 Constraints

  • Key: UPDM-59
  • Legacy Issue Number: 11386
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1] Asserts that this StateMachine is owned either by an OperationalNode or an OperationalCapabilityRealization
    self.owner.getAppliedStereotype('UPDM::OperationalNode')->notEmpty() or
    self.owner.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty() or
    self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty()

    Don't need :
    self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty()
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.20.6 Constraints

  • Key: UPDM-58
  • Legacy Issue Number: 11385
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1] Asserts that the owner of the OperationalEventTrace is either an OperationalNode or an OperationalCapabilityRealization.
    self.owner.getAppliedStereotype('UPDM::OperationalNode')->notEmpty() or
    self.owner.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty() or
    self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty()

    Don't need :
    Or self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty()
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.4.6 Constraints

  • Key: UPDM-53
  • Legacy Issue Number: 11380
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [7] Asserts that the element has at least one Standard associated with it.
    self.standards->forAll(getAppliedStereotype('UPDM::Standard')->notEmpty())
    Standard multiplicity relationship to Architecture view should be *, not 1.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.4.6 Constraints

  • Key: UPDM-52
  • Legacy Issue Number: 11379
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1] Asserts that Concerns is not empty
    self.concerns-> forAll(getAppliedStereotype('UPDM::Concern')->notEmpty())
    Rule only checks for ArchitectureView, should check for all of the specializations of ArchitectureView.
    Should be:
    self.client->forAll(getAppliedStereotype('UPDM::ArchitectureView')->notEmpty() or
    getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::ArchitectureView') ->notEmpty()) and
    self.supplier->forAll(getAppliedStereotype('UPDM::Viewpoint')->notEmpty())
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.13. Constraints - OperationalActivity

  • Key: UPDM-55
  • Legacy Issue Number: 11382
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1]
    In an OperationalActivity if a callBeahviorAction that references a stereotyped OperationalActivity but is NOT contained in a partition that meets the OwnedBehavior_rule constraint, then the constraint fails. It should be valid if the context of the activity referenced in the call behavior action is owned by the context of the OperationalActivity that owns the call behavior action.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.4.6 Constraints

  • Key: UPDM-54
  • Legacy Issue Number: 11381
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1] Asserts that Concerns is not empty self.concerns-> forAll(getAppliedStereotype('UPDM::Concern')->notEmpty()

    Concern multiplicity relationship to Architecture view should be *, not 1.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.2 Figure 8.14

  • Key: UPDM-49
  • Legacy Issue Number: 11376
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Fig 8.14 diagram shows AllView - all the names should be AllViews
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.2.6 Constraints

  • Key: UPDM-48
  • Legacy Issue Number: 11375
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1] Asserts that one end of the associaiton is an Activity, either an OperationalActivity or a SystemFunciton and the other is an OperationalActivityRealization if the first end is an OperatinalActivity and an OpertionalCapabilityRealization if the first end is a SystemFunction
    OpertionalCapabilityRealization is misspelled
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.23

  • Key: UPDM-45
  • Legacy Issue Number: 11372
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Description says there is a CustomView along with all the other Viewpoints, but it doesn't exist:
    "The ArchitectureView is an abstract concept that groups the following kinds of views: o All View o Operational View o System View o Technical Standards View o Acquisition View o Strategic View o Custom View "

    "An ArchitectureView is a ConformingElement and thus can be related to Standards. "
    However, it extends Package, and ConformingElement extends class, so it can't be a ConformingElement.

    "In some cases, it is desirable to assemble elements of the model and export them for processing by an external process; perhaps to produce custom presentations or to transform them into different forms. Using the UPDMAttributes, an external URI can be designated as the processing element, and the components within the View can be assembled as needed to complement the external process. "
    "UPDMAttributes" should be "ExternalReferences"
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.4.3 ArchitectureView Description

  • Key: UPDM-44
  • Legacy Issue Number: 11371
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Description is confusing.
    If the ArchitectureViews are Viewpoints, as described in the Viewpoint description:

    "ArchitectureView can be used to implement the Viewpoint/View capability. As a UML Package, ArchitectureView is a nested construct. Using a CustomView, a new Viewpoint can be defined, and custom views can be defined within this new package. "

    then the Views should not be subclasses of them. That is if OperationalView is considered a Viewpoint, then OV-1, a View should not be a specialization.
    On the other hand, <<Vewipoint>> specializes ConformingElement that extends Class, so the ArchitectureViews, OperationalView, etc. can't be Viewpoints. So what is a Viewpoint?
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.2.7 ActivityRealization

  • Key: UPDM-47
  • Legacy Issue Number: 11374
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Diagram 8.39 should be in section 8.4.2.3
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.21 Strategic Mission and 8.3.24 Vision

  • Key: UPDM-46
  • Legacy Issue Number: 11373
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Vision should be related to StrategicMission (BMM)
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.41 Policy

  • Key: UPDM-35
  • Legacy Issue Number: 11362
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Policy needs to be applicable to a much wider range of elements.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.6.39.6 Constraints

  • Key: UPDM-34
  • Legacy Issue Number: 11361
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    SystemGroupMember should include all of System specializations

    8.6.39.6 Constraints
    [1] Asserts that there are zero or more System elements configured on the SystemGroup and that these are the elements associated with this association
    let e1:uml::Class = self.oclAsType(uml::Association).endType-
    >at(1).oclAsType(uml::Class) in
    let e2:uml::Class = self.oclAsType(uml::Association).endType-
    >at(2).oclAsType(uml::Class) in
    (e1.getAppliedStereotype('UPDM::SystemGroup')->notEmpty() and
    (e2.getAppliedStereotype('UPDM::System')->notEmpty() or
    e2.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::System') ->notEmpty()) ))
    or
    (e2.getAppliedStereotype('UPDM::SystemGroup')->notEmpty() and
    (e1.getAppliedStereotype('UPDM::System')->notEmpty() or
    e2.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::System') ->notEmpty()) ))
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.7.5.6 Constraints

  • Key: UPDM-30
  • Legacy Issue Number: 11357
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [3] Asserts that there is a Capability Requirement for this OperationalNode

    OCL for [4] is correct for [3], but need OCL for [4]
    [3] Asserts that there is at least one OperationalNode associated with this CapabilityRequirement
    self.getAllAttributes()>asOrderedSet()>select(association-> notEmpty()).association-> any(getAppliedStereotype('UPDM::OperationalNodeCapabilityRequirement')> notEmpty())>notEmpty()

    [4] Asserts that an association exists between the CapabilityRequirement and at least one OperationalCapability
    self.getAllAttributes()>asOrderedSet()>select(association-> notEmpty()).association-> any(getAppliedStereotype('UPDM::CapabilityRequirementCapability')> notEmpty())>notEmpty()

  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.6.18.1 Extension

  • Key: UPDM-29
  • Legacy Issue Number: 11356
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    RealizedSystemSpecification should extend InterfaceRealization, not just Realization.

    · InterfaceRealization (from UML 2)

  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.16 OperationalCapabilityRole

  • Key: UPDM-32
  • Legacy Issue Number: 11359
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Need an association between OperationalCapabilityRole and Goal so that we can model intent as a link between instance of a goal and an instance of OperationalCapabilityRole . If we define <<Objective>> then this relationship should be between Objective and OperationalCapabilityRole.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.5.7.7 Semantics

  • Key: UPDM-31
  • Legacy Issue Number: 11358
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    "EventTrace" should be "OperationalEventTrace"
    CapabilityRequirement associates an OperationalNode and OperationalCapability. The OperationalCapability is defined as a collaboration among OperationalNodes whose behavior is reflected in an OperationalEventTrace, an OperationalActivity or an OperationalStateTrace. The CapabilityRequirement shows the deliverable requirements - metrics, time period and milestones.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.41 Policy

  • Key: UPDM-43
  • Legacy Issue Number: 11370
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Policy should be in the All Views package
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.28.6 Constraints

  • Key: UPDM-42
  • Legacy Issue Number: 11369
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    [1] Asserts that this StateMachine is owned either by an OperationalNode or an OperationalCapabilityRealization. self.owner.getAppliedStereotype('UPDM::OperationalNode')>notEmpty() or self.owner.getAppliedStereotypes()>collect(allParents())->any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty() or self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') - >notEmpty()

    don't need
    or self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') - >notEmpty()

    because OperationalCapabilityRealization is a specialization of OperationalNode
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.6.26 SV-6

  • Key: UPDM-37
  • Legacy Issue Number: 11364
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Description is wrong - it is the same as SV-5
    Should be:
    "The Systems Data Exchange Matrix specifies the characteristics of the data exchanged between Systems. This product focuses on automated exchange of information (from OV-3) as actually implemented from a variety of data sources. Non-automated exchange of information, such as verbal orders, is captured in the OV products only."
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.6.12.5 Forecast Associations

  • Key: UPDM-36
  • Legacy Issue Number: 11363
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Forecast needs to apply to Capability, OperationalCapability and CapabilityConfiguration
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.14.6 Constraints

  • Key: UPDM-39
  • Legacy Issue Number: 11366
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    PerformanceMeasurementSet needs to have conformingElement instance rule, in addition to the conforming element. The constraint makes sure the link exists.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.10 ConformingElement

  • Key: UPDM-38
  • Legacy Issue Number: 11365
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Need to have a stereotyped association between ConformingElement and PerformanceParameterSet.

  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.43.1 Extension

  • Key: UPDM-28
  • Legacy Issue Number: 11355
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    RealizedOperationalSpecification should extend InterfaceRealization, not just Realization.
    · InterfaceRealization (from UML 2)

  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.6.34.6 Constraints

  • Key: UPDM-27
  • Legacy Issue Number: 11354
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    the 3 items in [1] are in the wrong font.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.28.3 OperationalStateTrace Description

  • Key: UPDM-41
  • Legacy Issue Number: 11368
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Description for OperationalState Trace is incomplete
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.2.11 ProjectType

  • Key: UPDM-40
  • Legacy Issue Number: 11367
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    <<ProjectType>> is superfluous unless it has much more semantics from MODAF.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.3.13.5 Association

  • Key: UPDM-33
  • Legacy Issue Number: 11360
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Need association between Goal and OrgResource that "defines" the Goal (BMM)
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 7.1 Design Principles for the Architecture

  • Key: UPDM-22
  • Legacy Issue Number: 11348
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    This specification used the following design principles that support the domain needs and design rationale described above.

    Change to:
    This specification used the following design principlesthat support the domain needs and design rationale described
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.4.12.8 Notation

  • Key: UPDM-21
  • Legacy Issue Number: 11347
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    The paragraphs:
    Needlines may be generated automatically, derived from InformationExchanges, from ActivityEdges in OperationalActivities, and from Messages in OperationalEventTraces.

    Is a duplicate of the same paragraph in the previous section

    The paragraph:
    In structure diagrams where two OperationalNodes are depicted with a Connector belonging to a message, the Connector should be typed with the appropriate Needline that represent the message in an OperationalEventTrace or control flow in an OperationalActivity.

    Does not make much sense
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Remove SystemConnector from Spec

  • Key: UPDM2-50
  • Legacy Issue Number: 17629
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    SystemConnector has been superceded, but is still in the spec. See section 8.3.1.4.5.1.2 SystemConnector. Remove SystemConnector from Spec
  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Remove SystemConnector from Spec. See pages 86/87 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

IndividualPersonRole is missing from the spec, but has references to it

  • Key: UPDM2-49
  • Legacy Issue Number: 17628
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    IndividualPersonRole is missing from the Official spec. Missing, but referred to in mapping tables. IndividualPerson is replaced by IndividualPersonRole
  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Remove IndividualPerson section and add IndividualPersonRole
    Remove the following section from the specification
    See pages 90/91 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

SysML stereotype references in the UPDM specification need to be updated

  • Key: UPDM-13
  • Legacy Issue Number: 11237
  • Status: open  
  • Source: Caltech CTME ( Mr. Ron C. Williamson, Ph.D.)
  • Summary:

    The SysML stereotype references in the UPDM specification need to be updated to reflect the latest results of the SysML FTF revisions.
  • Reported: UPDM 1.0b1 — Tue, 31 Jul 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Mislabeled Figure B.9 OV-3 should be OV-2.

  • Key: UPDM2-51
  • Legacy Issue Number: 17630
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    igure B.9 is mislabeled. Figure B.9 - OV-3 should be OV-2. Change title.
  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Change title of Figure B.9 - OV-3 to be OV-2.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 5.3.4.2

  • Key: UPDM-15
  • Legacy Issue Number: 11326
  • Status: open  
  • Source: University of Utah ( Mr. Robert Lario)
  • Summary:

    There appears to be a typo in the table. Note that the elements repeat in the table
  • Reported: UPDM 1.0b1 — Wed, 5 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 4.3.3.3

  • Key: UPDM-14
  • Legacy Issue Number: 11325
  • Status: open  
  • Source: University of Utah ( Mr. Robert Lario)
  • Summary:

    Should there be some association between ArchitectureDescription and Enterprise depicted? If not why is the Enterprise Stereotype shown here?
  • Reported: UPDM 1.0b1 — Wed, 5 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 4.2.10.6

  • Key: UPDM-17
  • Legacy Issue Number: 11329
  • Status: open  
  • Source: University of Utah ( Mr. Robert Lario)
  • Summary:

    Constraint 4 documentation does not match OCL shown
  • Reported: UPDM 1.0b1 — Thu, 6 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 4.3.14.4

  • Key: UPDM-16
  • Legacy Issue Number: 11327
  • Status: open  
  • Source: University of Utah ( Mr. Robert Lario)
  • Summary:

    There is a reference to PerformanceMeasurementPeriod, yet PerformanceMeasurementPeriod is not defined in the document.
  • Reported: UPDM 1.0b1 — Wed, 5 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.6.11.6 Data Exchange

  • Key: UPDM-20
  • Legacy Issue Number: 11346
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Need a constraint that asserts that the DataExchange must be realized by at least one of the realizations
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.4.8.6 Constraints

  • Key: UPDM-19
  • Legacy Issue Number: 11345
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Need a constraint that asserts that the InformationExchange must be realized by at least one of the realizations.
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: Part III

  • Key: UPDM-24
  • Legacy Issue Number: 11351
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    9. UPDM Class Library Compliance Level 0
    Change "Class" to "Model"
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: Figure 7.1

  • Key: UPDM-23
  • Legacy Issue Number: 11349
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    "Class Library" should be "Model Library"
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: Figure 8.11

  • Key: UPDM-26
  • Legacy Issue Number: 11353
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Figure is shrunk down
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: Figure 8.1

  • Key: UPDM-25
  • Legacy Issue Number: 11352
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Figure is messed
  • Reported: UPDM 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page: 29 - Image shown is to small to read

  • Key: UPDM-18
  • Legacy Issue Number: 11330
  • Status: open  
  • Source: University of Utah ( Mr. Robert Lario)
  • Summary:

    Image shown is to small to read
  • Reported: UPDM 1.0b1 — Thu, 6 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

properties of EnterprisePhase are wrongly named

  • Key: UPDM2-32
  • Legacy Issue Number: 17551
  • Status: closed  
  • Source: PTC ( Mr. Simon Moore)
  • Summary:

    (on behalf of the MIWG)

    comparing the UPDM spec to the UPDM profile (updated for UPDM 2.0.1):

    spec – profile
    ---------------
    goals – goal
    representedBy – desribedBy (note spelling error)
    visions – vision
    statementTasks – statementTask

    MIWG will use the profile names to allow validation.

  • Reported: UPDM 2.0 — Tue, 14 Aug 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Missed a change in the model, this should be corrected when we update with the new model
    Update the Attributes section for section 8.3.1.3.5.1.4 EnterprisePhase from this

    Attribute
    The following are attributes for EnterprisePhase:
    • endDate : ISO8601DateTime[1] - The time and date at which the Phase ends.
    • fulfills : Mission[*] -
    • goals : EnterpriseGoal[*] - The Goal towards which this Phase is directed and is in support of.
    • RepresentedBy : ArchitecturalDescription[*] -
    • startDate : ISO8601DateTime[1] - The time and date at which the Phase starts.
    • statementTasks : EnduringTask[*] - Collection of statement tasks.
    • visions : EnterpriseVision[1] - The Vision towards which this Phase is directed and is in support of.
    To this
    Attributes

    The following are attributes for EnterprisePhase:

    o desribedBy : ArchitecturalDescription[*] - The EnterprisePhase described by an ArchitecturalDescription.

    o endDate : ISO8601DateTime[0..1] - The time and date at which the Phase ends.

    o fulfills : Mission[*] - EnterprisePhases associated with a Mission.

    o goal : EnterpriseGoal[*] - The Goal towards which this Phase is directed and is in support of.

    o startDate : ISO8601DateTime[0..1] - The time and date at which the Phase starts.

    o statementTask : EnduringTask[*] - Collection of statement tasks.

    o vision : EnterpriseVision[0..1] - The Vision towards which this Phase is directed and is in support of.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Performer is defined both as an alias and a specialization of Node

  • Key: UPDM2-31
  • Legacy Issue Number: 17449
  • Status: closed  
  • Source: CSC ( Peter Kelley)
  • Summary:

    The text relating to Performer in section 8.3.1.4.3.1.1 states that Performer is "An alias for Node in DoDAF" however Figure 8.165 shows it as a specialization of Node and the Generalizations section states that Node is a generalization of Performer.

    These statements are in conflict.

  • Reported: UPDM 2.0 — Tue, 19 Jun 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Modify text by removing reference to performer being an Alias of Node.
    Please not heading indices are likely to change due to the model based nature of the document but they do give an indication of where to find the text

    Change text:

    8.3.1.4.3.1.1 Performer
    MODAF:NA
    DoDAF: Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability. An alias for Node in DoDAF.

    To updated text

    8.2.1.2.3.1.1 Performer
    MODAF:NA
    DoDAF: Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section on GeoPoliticalExtentTypeKind is missing

  • Key: UPDM2-48
  • Legacy Issue Number: 17627
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    Section on GeoPoliticalExtentTypeKind is missing. Should be after GeoPoliticalExtentKind. Missing, although referred to in Table C.1 - DoDAF-DM2, UPDM, and MODAF Mapping.

    Resolution:
    Add the following text after the section on GeoPoliticalExtentKind:

    8.4.2.4.2 GeoPoliticalExtentTypeKind
    Enumeration of kinds of geopolitical extent type, derived from DoDAF, used to support the geoPoliticalExtentTypeKind tag of the GeopoliticalExtentType stereotype.
    • Enumeration Literals
    The following are enumeration literals for Environment:
    CountryType - Powertype Of Country.
    FacilityType - Powertype Of Facility.
    GeoFeatureType - Powertype Of GeoFeature.
    InstallationType - Powertype Of Installation.
    OtherType - Other GeoPoliticalExtentType kind that is not on the enumerated list.
    RegionOfCountryType - Powertype Of RegionOfCountry.
    RegionOfWorldType - Powertype Of RegionOfWorld.
    SiteType - Powertype Of Site.
  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Add the following text after the section on GeoPoliticalExtentKind:

    8.4.2.4.2 GeoPoliticalExtentTypeKind
    Enumeration of kinds of geopolitical extent type, derived from DoDAF, used to support the geoPoliticalExtentTypeKind tag of the GeopoliticalExtentType stereotype.
    • Enumeration Literals
    The following are enumeration literals for Environment:
    CountryType - Powertype Of Country.
    FacilityType - Powertype Of Facility.
    GeoFeatureType - Powertype Of GeoFeature.
    InstallationType - Powertype Of Installation.
    OtherType - Other GeoPoliticalExtentType kind that is not on the enumerated list.
    RegionOfCountryType - Powertype Of RegionOfCountry.
    RegionOfWorldType - Powertype Of RegionOfWorld.
    SiteType - Powertype Of Site
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Details is missing, even though there are references to it

  • Key: UPDM2-47
  • Legacy Issue Number: 17626
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    Details is missing, even though there are references to it. See section 8.3.1.3.7.5.2 EntityItem, which has a reference to it. Details needs to be added to the spec.
  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 88/89 of dtc/2012-1216 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Resource has been changed to SystemResource

  • Key: UPDM2-46
  • Legacy Issue Number: 17625
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    Figure 8.132 Resource is missing class extension.
    Things still refer to Resource in the text in contrast with the diagram See 8.3.1.3.6.4.4 PhysicalArchitecture for an example. There may be others.
  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 83 and 85 of dtc/2012-12-16 for detaiols
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Activity is an abstract element, it should be concrete

  • Key: UPDM2-34
  • Legacy Issue Number: 17575
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The activity element in UPDM is defined as abstract, for DoDAF 2.0 usage it should be concrete
  • Reported: UPDM 2.0 — Thu, 6 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    In UPDM we deployed subtypes of activities to give a context to the activity types. I.e. we can differentiate between Operational, System or project activities. You cannot do this if all activit elements are activities.

    Therefore it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:59 GMT

By having Exchange Element as a Datatype there is not possible to define the State Machine for it

  • Key: UPDM2-33
  • Legacy Issue Number: 17574
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    By having Exchange Element as a Datatype there is not possible to define the State Machine for it. This is a huge issue for a majority of No Magic's customers
  • Reported: UPDM 2.0 — Thu, 6 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Used to represent changes in state of a data element. Action: change Exchange Element to class, block. Need change in Model and also the SysML mapping table and SysML OCL transformation text.

    Original Text:
    8.3.1.3.1.7.1 ExchangeElement
    MODAF: A relationship specifying the need to exchange information between nodes. DoDAF: NA - this is a specialization of OperationalExchange (DoDAF::Interface).
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DoDAF users are upset using MODAFRoleKind property on the ResourceRole

  • Key: UPDM2-36
  • Legacy Issue Number: 17580
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    DoDAF users are upset using MODAFRoleKind property on the ResourceRole.
    They found the name misleading. The suggestion I've been given from
    Lockheed Martin guys is to simply have RoleKind instead of
    MODAFRoleKind. It also affect the enumeration the property is typed by.
  • Reported: UPDM 2.0 — Wed, 12 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 60 through 64 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Remove model libraries from UPDM 2.0 profile structure

  • Key: UPDM2-35
  • Legacy Issue Number: 17578
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Remove model libraries from UPDM 2.0 profile structure, put them in as model libraries and reference them from the UPDM profile. Corrects issues in XMI

  • Reported: UPDM 2.0 — Tue, 11 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Remove model libraries from UPDM 2.0 profile structure, put them in as model libraries and reference them from the UPDM profile. Corrects issues in XMI

    This change is in the XMI and not reflected in any diagrams or text in the specification, with modified XMI being submitted with the specification.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Conflicting PV-3 diagrams for DMM and Profile

  • Key: UPDM2-39
  • Legacy Issue Number: 17618
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    Below, the DMM diagram differs from the profile diagram. The profile diagram reflects solely the elements required for DoDAF, while the DMM diagram reflects a MODAF view and ignores activities
  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 72 through 73 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing sequencing capability for DoDAF Project Activities

  • Key: UPDM2-38
  • Legacy Issue Number: 17617
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    DoDAF projects contain activities, similar to tasks on a MS Project diagram. Currently they do not have a time or sequence associated with them, making them problematic for defining a chronological order or sequence. Consequently I cannot see how the can define a project sequence of tasks. For the MODAF AcV-2 we use the date field of the actual project milestone. MS Project tasks can contain sequence dependencies as well as specific start times and durations. The activities will require either a chronological before/after or the creation of an activity diagram for support.

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 68 through 70 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ExchangeItem has been deleted from UPDM and should not be in the document

  • Key: UPDM2-43
  • Legacy Issue Number: 17622
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    ExchangeItem is in the document in Figure 8.10, page 42. We need to remove ExchangeItem from the spec/model.
  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 79 through 80 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActualProperty definition missing from document

  • Key: UPDM2-42
  • Legacy Issue Number: 17621
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    The definition of the ActualProperty stereotype is missing, although many things reference it. I believe the name was changed to PropertyValue but not updated in the documentation.
  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    This is a duplicate of 17623 regarding PropertyValue.

    Proposed Disposition: Duplicate
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Service message has the wrong graphic

  • Key: UPDM2-45
  • Legacy Issue Number: 17624
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    Service Message is actually shown as ServiceInteraction. The diagram needs to be corrected.
  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 81 and 82 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

PropertyValue should be removed from the UPDM Document

  • Key: UPDM2-44
  • Legacy Issue Number: 17623
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

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

  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    See pages 95 through 101 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Incorrect SV-4 DMM Diagram

  • Key: UPDM2-41
  • Legacy Issue Number: 17620
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    The SV-4 DMM diagram is actually the SV-3. We need to replace it with the proper diagram.
  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 76 and 77 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Incorrect AV-1 DMM Diagram

  • Key: UPDM2-40
  • Legacy Issue Number: 17619
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    The DMM diagram is incorrect in the UPDM specification. This is actually the AcV-1 diagram. We need to replace this with the proper diagram.
  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 74 and 75 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Confusion in type for Project status

  • Key: UPDM2-37
  • Legacy Issue Number: 17616
  • Status: closed  
  • Source: INCOSE ( Mr. Matthew Hause)
  • Summary:

    The AcV-2 is used to report on the timelines of existing «ActualProject» elements and the status of its «ProjectTheme»s. The information for these reports is created mainly on the AcV-3 diagrams.
    The DMM and profile diagrams differ in the naming of the project status type. The DMM calls it ProjectThemeKind and the profile calls it StatusIndicators.

    Modify ProjectThemeKind in DMM to be StatusIndicators
    Replace DMM Acv-2 with modfied version
  • Reported: UPDM 2.0 — Fri, 21 Sep 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Modify ProjectThemeKind in DMM to be StatusIndicators
    Replace DMM Acv-2 with modified version
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 8.8. uses <> incorrectly

  • Key: UPDM2-20
  • Legacy Issue Number: 17207
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Figure 8.8 shows a <<metarelationship>> with metaclass = trace. But trace is a stereotype (coming from UML standard profile L2 via SysML) so this should be a <<stereotyped relationship>>.

  • Reported: UPDM 2.0 — Thu, 1 Mar 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 52 and 53 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

"Include DoDAF 2.02 Conformance Level Three (L3) Statement"

  • Key: UPDM2-19
  • Legacy Issue Number: 17095
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

    "Section 3.3 Department of Defense" (Normative References) and/or "Section 2 Compliance".

    A paragraph needs to be added related to "DoDAF 2.02 Conformance Level Three (DoDAF L3)."

    UPDM 2.0 conforms with Level Three (3) as specified by DoDAF 2.02.
    The DoDAF Levels of conformance are:

    DoDAF Level 1 is conceptual conformance.
    DoDAF Level 2 is logical data model conformance.
    DoDAF Level 3 is physical data model conformance.
    DoDAF Level 4 is syntactic/ontology conformance with a full spatial-temporal (4-dimensional) ontology.

    Note: DoDAF Levels are not to be confused with UPDM Levels.

    Note: DoDAF Levels are cumulative, that is, Level 3 physical data model conformance builds upon Level 2, logical data model conformance.
    One cannot achieve DoDAF Level 3 without achieving DoDAF Levels 1 and 2.

    As evidence of conformance at the logical data model level (DoDAF Level 2), we refer the reader internally to Annex C.1, "DoDAF-DM2, UPDM, and MODAF Mapping". For DoDAF Level 3, we cite the proven exchanges among UPDM 2.0 implementations at the physical layer using the OMG XML Model Interchange (XMI) specification. Tools that conform with UPDM Level 0 or UPDM Level 1 must be able to make this XMI interchange. See internal section 2.1.1 and 2.1.2

    Len Levine for US DoD
  • Reported: UPDM 2.0 — Thu, 2 Feb 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    The text in section 7.7.2 relating to DODAF 2.0.2 conformance is not in an appropriate place in the document so it should be moved to the section 3.3 relating to DoDAF compliance
    Remove section
    7.7.2 DoDAF 2.02 Conformance
    Compliance with UPDM 2.1 Profile including metadata should assist the tool vendor in adhering to DoDAF 2.02 because the UPDM 2.1 Core and DoDAF-specific metadata models in UPDM 2.1 adhere to the metadata model inherent in DoDAF 2.02 Conceptual and Logical data models. In developing the UPDM 2.1, domain meta-modelers have also consulted the corresponding Physical data model in DoDAF 2.02 and to resolve questions of general conformance with enterprise-level architectural elements. Nevertheless, tool vendors are advised to consult DoDAF Version 2.02 (especially Volume I, page 2-6; Volume II, page 2-6; and Volume III, page 1-2) before claiming DoDAF 2.02 conformance. While conformance with UPDM 2.1 Core and DoDAF-specifics should greatly facilitate conformance with DoDAF 2.02, each tool vendor is still responsible for the tool's ultimate conformance with the documented architecture framework.
    Compliance with UPDM 2.1 Profile including metadata should assist the tool vendor in adhering to DoDAF 2.02 because the UPDM 2.1 Core and DoDAF-specific metadata models in UPDM 2.02 adhere to the metadata model inherent in DoDAF 2.02 Conceptual and Logical data models. In developing the UPDM 2.1, domain meta-modelers have also consulted the corresponding Physical data model in DoDAF 2.02 to resolve questions of general conformance with enterprise-level architectural elements. Nevertheless, tool vendors are advised to consult DoDAF Version 2.02 before claiming DoDAF 2.02 compliance.
    The DoD-CIO has clarified in a Decision Brief of 12 Jan 11 that it does not expect UPDM 2.1 to export models in PES, nor to provide an implementation of 4D (geo-spatial-temporal modeling) including a global implementation of Whole-Part and Temporal-Whole-Part for all UPDM elements (classes/objects).
    The UPDM Profile to DoDAF Metamodel Compliance Matrix has been published as non-normative Annex C of the specification to aid tool vendors in their claims to DoDAF Level 2 Conformance. This matrix should also facilitate upgrades to Level 3 and 4 of DoDAF Conformance in future versions of UPDM.

    Append to section 3.3
    7.7.2 DoDAF 2.02 Conformance
    Compliance with UPDM 2.1 Profile including metadata should assist the tool vendor in adhering to DoDAF 2.02 because the UPDM 2.1 Core and DoDAF-specific metadata models in UPDM 2.1 adhere to the metadata model inherent in DoDAF 2.02 Conceptual and Logical data models. In developing the UPDM 2.1, domain meta-modelers have also consulted the corresponding Physical data model in DoDAF 2.02 and to resolve questions of general conformance with enterprise-level architectural elements. Nevertheless, tool vendors are advised to consult DoDAF Version 2.02 (especially Volume I, page 2-6; Volume II, page 2-6; and Volume III, page 1-2) before claiming DoDAF 2.02 conformance. While conformance with UPDM 2.1 Core and DoDAF-specifics should greatly facilitate conformance with DoDAF 2.02, each tool vendor is still responsible for the tool's ultimate conformance with the documented architecture framework.
    Compliance with UPDM 2.1 Profile including metadata should assist the tool vendor in adhering to DoDAF 2.02 because the UPDM 2.1 Core and DoDAF-specific metadata models in UPDM 2.02 adhere to the metadata model inherent in DoDAF 2.02 Conceptual and Logical data models. In developing the UPDM 2.1, domain meta-modelers have also consulted the corresponding Physical data model in DoDAF 2.02 to resolve questions of general conformance with enterprise-level architectural elements. Nevertheless, tool vendors are advised to consult DoDAF Version 2.02 before claiming DoDAF 2.02 compliance.
    The DoD-CIO has clarified in a Decision Brief of 12 Jan 11 that it does not expect UPDM 2.1 to export models in PES, nor to provide an implementation of 4D (geo-spatial-temporal modeling) including a global implementation of Whole-Part and Temporal-Whole-Part for all UPDM elements (classes/objects).
    The UPDM Profile to DoDAF Metamodel Compliance Matrix has been published as non-normative Annex C of the specification to aid tool vendors in their claims to DoDAF Level 2 Conformance. This matrix should also facilitate upgrades to Level 3 and 4 of DoDAF Conformance in future versions of UPDM.

    Append the following addition to section 3.3 after the additions above.

    DoDAF 2.02 Conformance Level Three (DoDAF L3).

    UPDM 2.0 conforms with Level Three (3) as specified by DoDAF 2.02.
    The DoDAF Levels of conformance are:

    DoDAF Level 1 is conceptual conformance.
    DoDAF Level 2 is logical data model conformance.
    DoDAF Level 3 is physical data model conformance.
    DoDAF Level 4 is syntactic/ontology conformance with a full spatial-temporal (4-dimensional) ontology.

    Note: DoDAF Levels are not to be confused with UPDM Levels.

    Note: DoDAF Levels are cumulative, that is, Level 3 physical data model conformance builds upon Level 2, logical data model conformance.
    One cannot achieve DoDAF Level 3 without achieving DoDAF Levels 1 and 2.

    As evidence of conformance at the logical data model level (DoDAF Level 2), we refer the reader internally to Annex C.1, ""DoDAF-DM2, UPDM, and MODAF Mapping"". For DoDAF Level 3, we cite the proven exchanges among UPDM 2.0 implementations at the physical layer using the OMG XML Model Interchange (XMI) specification. Tools that conform with UPDM Level 0 or UPDM Level 1 must be able to make this XMI interchange.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

It's very odd and counter-intuitive to have UPDM L0 buried in UPDM L1

  • Key: UPDM2-13
  • Legacy Issue Number: 17024
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It's very odd and counter-intuitive to have UPDM L0 buried in UPDM L1 -

    I spent ages trying to find it in the contents.
  • Reported: UPDM 2.0 — Fri, 20 Jan 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    This was the result the initial profile structure we used to separate out their use/import of the SysML profile. This was originally based on a similar structure and conventions used in UML and its compliance levels. To change this during the RTF will have a large impact on the structure of the document, the profile and resultant XMI.

    Therefore it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Document still references DoDAF v1.5, when it should reference DoDAF V2.02

  • Key: UPDM2-12
  • Legacy Issue Number: 16912
  • Status: closed  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    See Page 255 of the UPDM,

    “Table B.1 shows the traceability among UPDM stereotypes and DODAF 1.5/MODAF elements”

    The table column heading: “DoDAF 1.5 Model Elements”

    Page 275: “The scenario and modeling was easily updated to include UPDM concepts including US DoDAF 1.5.”

    Do a search and replace on all references to DODAF v1.5 in the UPDM v2.0 spec: dtc/2011-05-07
  • Reported: UPDM 1.1 — Thu, 15 Dec 2011 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    This issue appears to be fixed, but we did a search on other references to DoDAF 1.5 that should be DoDAF 2.0 and we found that the description for the technical standards elements needed to be updated.

    Make the following change:

    "Replace the text of section 8.3.1.3.7 UPDM L1: :UPDM L0: :Core: :TechnicalStandardsElements

    Section 1.4.4 of the DoDAF version 1.5 Definitions and Guidelines (Volume I): Define the purpose of the Technical View as follows:
    “The TV is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements. Its purpose is to ensure that a system satisfies a specified set of operational requirements. The TV provides the technical systems implementation guidelines upon which engineering specifications are based, common building blocks are established, and product lines are developed. It includes a collection of the technical standards, implementation conventions, standards options, rules, and criteria that can be organized into profile(s) that govern systems and system or service elements for a given architecture.”

    With:

    “UPDM 2.0 retains the TV Viewpoint which maps to the new DoDAF 2.02 StdV Standards Viewpoint. DoDAF Version 2.02, “DoDAF Viewpoints and Models: Standards Viewpoint” defines the purpose of the Standards Views. StdV-1 is a wider definition of the concept of “technical standard” than used in previous DoDAF versions. Such standards were restricted, for example, to ISO, OMG, OASIS, and similar standards) and could be found in the DoD IT Standards Registry (DISR). It now includes not only such software (information technology) standards but wider standards including hardware and other technologies. It includes protocols and data standards. It now is expanded to include technical, operational, and business standards defined liberally as well as guidance, policy, regulations, and laws applicable to the architecture being described. The StdV-1 is a set of such standards that applies to one (current) time-period. If emerging standards are addressed for a future period of time, a StdV-2 Standards Forecast should be completed as well. The purpose of StdV is both to specify the standards with which a project must comply as well as to planning for additional or future application of standards. The StdV collates the various systems, services, etc. with the rules (standards) that govern the implementation of the architecture. A typical StdV should reference elements used in the various other System Views (SV) (SV-1, 2, 4, 6), Service Views (SvcV-1, 2, 4, 6) and layers DIV (DIV-2 and DIV-3). Protocols often are Resource Flow descriptions defined in SV-2 and SvcV-2. The degree of compliance to standards may also be addressed in risk assessments."
  • Updated: Fri, 6 Mar 2015 20:59 GMT

UPDM stereotype name conflict

  • Key: UPDM2-25
  • Legacy Issue Number: 17329
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Unified Profile for DoDAF and MODAF (UPDM), Version 2.0 (formal/2012-01-03)

    Subclause: 8.3.1.4.3.1.2.2 Organization

    The profile UPDM L1::UPDM L0::DoDAF::OperationalElements::Structure::Organizational defines a stereotype Organization that specializes ActualOrganization from UPDM L1::UPDM L0::Core::OperationalElements::Structure::Organizational::Actual. There is also a stereotype called Organization defined in UPDM L1::UPDM L0::Core::OperationalElements::Structure::Organizational::Typical.

    This is the only case within the UPDM profile as a whole in which there are two stereotypes with the same simple name. While this does not cause any problem from a technical UML point of view, since the stereotypes are in different UML namespaces, it does have implications for the XMI serialization of UPDM models. Since stereotype applications use the XMI namespace for a profile to disambiguate stereotype names, not UML namespaces, having this one naming conflict makes it impossible to use a single XMI namespace for the UPDM profile and all its subprofiles.

    The DoDAF Organization stereotype does not add any functional capabilities over the Core ActualOrganization stereotype. It would therefore simplify the serialization of UPDM models, by allowing the use of a single XMI namespace, if the Organization stereotype was simply deleted from DoDAF and the ActualOrganization stereotype from Core was used instead in DoDAF models.
  • Reported: UPDM 2.0 — Mon, 23 Apr 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    closed in the urgen issue resolution process
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Instance value and slot use in all UPDM elements that extend InstanceSpecification

  • Key: UPDM2-24
  • Legacy Issue Number: 17277
  • Status: closed  
  • Source: Syntell AB ( Mr Lars-Olof Kihlstrom)
  • Summary:

    It is felt that the utility of the UPDM framewor would be increased if the profile allowed slots and instance values on all elements in the UPDM profile that extends the metaclass InstanceSpecification. Currently this is only done partially.
  • Reported: UPDM 2.0 — Wed, 28 Mar 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    This is basic functionality of UML modeling tools so can be implemented by users if need. There is no specific fix required in UPDM

    Therefore it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:59 GMT

ResourceConnector.realizedExchange does not have a programmable direction or other context specific data

  • Key: UPDM2-23
  • Legacy Issue Number: 17265
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    ResourceConnector.realizedExchange between same role has no direction.

    This causes an issue when there is no natural direction for the exchange, especially when two roles have an identical types. There is also no realization specific measures.

    For example. A a structure of a cat box containing two identical resources of the type Kitty with roles a and b. Kitty has an ResourceInteraction to itself defined. In the context of the cat box composite, the only allows the realization of the exchange, but not the direction (a to b or b to a).

    The proposal would be a complex type for realized exchanges that includes direction, the exchange, and possible instance specific measures. This solves several issues. Less viable are lists for direction.

  • Reported: UPDM 2.0 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    This is a complex issue that goes back to the roots of UML if dealt with correctly. A
    Workaround was determined if you use roles in the swimlanes of the activity diagram, use of flow ports or provide required ports, all give indication of direction. Which allows this information to be derived.

    Therefore it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:59 GMT

change stereotype extensions (base_*) marked as "private" to "public"

  • Key: UPDM2-28
  • Legacy Issue Number: 17400
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Graham Bleakley, graham.bleakley@uk.ibm.com

    status critical

    I see that a huge list of stereotype extensions (base_*) that are marked as "private"
    These "private" extensions are preventing the application of the stereotypes
    For instance on the valid.xmi of testcase B, I cannot apply Perfomer stereotype (line 65) due to the private visibility of the attribute "base_Class"

    Resolution
    change all stereotype extension visibility in the xmi to "public" to enable the application of those steretypes.

  • Reported: UPDM 2.0 — Thu, 31 May 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    closed in the urgen issue resolution process
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Attribute URI/URL should be renamed and made optional

  • Key: UPDM2-27
  • Legacy Issue Number: 17361
  • Status: closed  
  • Source: PTC ( Mr. Simon Moore)
  • Summary:

    On behalf of the OMG MIWG:

    There is an attribute on UPDMElement (which many things derived from) called "URL/URI ". This contains a slash character and space (on the end) which are illegal as an XML name, but no xmiName override is provided. Also it should be optional since not all objects would require them for the model to be valid.

    This is blocking validation of XMI files and therefore requires some kind of urgent solution in UPDM 2.0.1.

    Our proposal would be to change the name to "URI" and make it optional.

  • Reported: UPDM 2.0 — Tue, 8 May 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    closed in the urgen issue resolution process
  • Updated: Fri, 6 Mar 2015 20:59 GMT

some properties are wrongly marked as mandatory

  • Key: UPDM2-26
  • Legacy Issue Number: 17360
  • Status: closed  
  • Source: PTC ( Mr. Simon Moore)
  • Summary:

    This is raised on behalf of the OMG Model Interchange Working Group as it affects validation of XMI files which use UPDM.

    —

    I noticed that the MIWG's current reference xmi for UPDM testing fails some checks on the NIST validator because mandatory string properties are not specified.

    For example, in the UPDM 2.0 spec ArchitecturalDescription's 'recommendations' is defined as:
    • recommendations : String[1] - States the recommendations that have been developed based on the architecture effort. Examples include recommended system implementations, and opportunities for technology insertion.

    Whereas in UPDM 1.1 it was:
    • recommendations : String[*] - States the recommendations that have been developed based on the architecture effort. Examples include recommended system implementations, and opportunities for technology insertion.

    It is not marked with change bars in the UPDM 2.0 spec, which might indicate that this change was not intended, and the example above certainly doesn't have an obvious need to be mandatory. As far as I know, UML and SysML have avoided making properties like this mandatory.

    So, was this and others like it an intended change? Were the ones already in UPDM 1.1 intended to be mandatory?

  • Reported: UPDM 2.0 — Tue, 8 May 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 37 and 38 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Need non-nomative profiles for NAF. DODAF and MODAF views and viewpoints

  • Key: UPDM2-22
  • Legacy Issue Number: 17264
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Views and viewpoint stereotypes do not exist in UPDM at the moment.
    We need to add them so that we can start to interchange sections of information formally and exchange diagrams when DDI for the specification of UML/SysML diagrams is defined.

  • Reported: UPDM 2.0 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Resolution:
    References to view and viewpoint in diagram names are not SysML or 1471 definitions, this is a requirement for standard stereotypes for the diagrams and packaging structures in UPDM as as used in DoDAF and MODAF terminology.

    As stereotypes are not allowed for Diagrams types in UML it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Concern needs to be added to the AV-1

  • Key: UPDM2-21
  • Legacy Issue Number: 17263
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Concern:
    Currently Concern is shown as a tagged value string within the concept ViewPoint element ( a stereotype based on package). This misses the general intent in MODAF where Concern is a stereotype of Usecase and where stakeholders can be associated directly with the usecase to indicate who is interested in what within the architecture model in question. THis is done via the dependency stereotype StakeholderHasConcern where the staekoholder can be an OrganisationalResource in MODAF. I would think that in UPDM the stakeholder should be allowed as either an OrganisationalResource or an actual organisational resource.

    The UPDM elements View and Viewpoint are stereotypes of package and this actually creates something of a browser structuring problem and should in my view be deleted/ changed. In MODAF View is used as an additional reading inststruction for a concern essentially implying that for each view instance created by an architect a proxy is created in AV-1 with the same name based with this proxy being a View stereotype of Class. This can also be connected to Concern in order to indicate in which views within the architecture that a certain concern can be found. All of these elements are essentially reading instructions. The element ArchitectureProduct in MODAF is also missing, it is also tied to concern and contains a list of the architecture elements that a given concern is associated with. Its current counterpart in UPDM would seem to be View ( a stereotyped package and as indicated previously the use of packages here represent a problem). It should be noted that a given concern can apply to more than one instance of an architectural view and that elements may well apply to more than one concern i,e, in both cases there is the possibility of many to many relationships, something that makes the use of packages as a means of structuring things very difficult.

  • Reported: UPDM 2.0 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Lars indicated that concern should be added as first class element based upon Use case.

    There is a large impact due to clash between Concerns tag in SysML from which View/Viewpoint in UPDM are derived and also the inadequacies of the View/Viewpoint specification in SysML.

    Therefore it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The namespace to use for UPDM is unclear due to inconsistent values

  • Key: UPDM2-18
  • Legacy Issue Number: 17042
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The specification document (front page) says:
    Standard document URL: http://www.omg.org/spec/UPDM/2.0 and Associated Schema Files: http://www.omg.org/spec/UPDM/20110601
    The XMI for the profile itself declares:
    xmlns:updm='http://www.omg.org/spec/UPDM/2.0/20110615'
    Aside: including "2.0" in the URI is inconsistent with OMG guidelines: the date-based format was to replace the use of version number
  • Reported: UPDM 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    closed in the urgen issue resolution process
  • Updated: Fri, 6 Mar 2015 20:59 GMT

wrong document reference

  • Key: UPDM2-17
  • Legacy Issue Number: 17041
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The formal XMI file for UPDM http://www.omg.org/spec/UPDM/20110601/dtc-2011-06-15.xml makes several references to SoaML using the following base URL: http://www.omg.org/spec/SoaML/20091101/09-11-15.xmi.
    This is the old document, which is for an older version of UML than used by the UPDM profile, and does not reflect the updated and correct SoaML profile sent by Jim Amsden on Dec 5 (attached), though I'm not sure it has even been allocated a document number or been posted.
  • Reported: UPDM 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    closed in the urgen issue resolution process
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.2.1

  • Key: UPDM2-16
  • Legacy Issue Number: 17027
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    8.2.1 states that UPDM L1 " imports parts of SysML - Requirements and
    ModelElements namely." However that does not seem consistent with section 2.1 or the diagram
  • Reported: UPDM 2.0 — Fri, 20 Jan 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    section 2.1.1 has the following text
    Figure 2.2 illustrates that UPDM 2.0 Compliance Level 0 is an implementation of UPDM extending UML 2 and importing several SoaML stereotypes – namely Expose, Attachment, RequestPoint, ServicePoint, MessageType, Property. In order for a tool to be considered as compliant with L0, the following must be true:

    This is in contradiction to section 8.2.1 which says
    UPDM L0 contains all the Core, DoDAF, and MODAF elements, and imports parts of SysML - Requirements and ModelElements namely. This compliance level is primarily based on UML and reuse of a minimum of SysML elements. This includes Requirements and Views/Viewpoints. As one of the core principles is reuse, cloning/recreating of these existing SysML structures was considered as inappropriate.

    We will change section 8.2.1 to say
    UPDM L0 contains all the Core, DoDAF, and MODAF elements, reuses UML and imports parts of SoaML. This compliance level is primarily based on UML 2 and the import of a minimum of SoaML stereotypes. The SoaML stereotypes imported are Capability, ServiceInterface, Expose, Attachment, Request, Service, MessageType, Property, ServiceChannel and Participant.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

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

  • Key: UPDM2-11
  • Legacy Issue Number: 16718
  • Status: closed  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Need to add a conforms to relationship for an element of type Interface to be able to associate a standard with it
  • Reported: UPDM 1.1 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    We did not want to add any further elements to the UPDM spec and there are potential workarounds for this issue as it is possible to associate a standard using the ConformsTo tag on ResourceInterfaces or ResourcePorts or it could be done using a SysML satisfy between the interface and the standard.

    It was decided to close this issue with no change

    Proposed Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Incorrect acknowledgement

  • Key: UPDM2-10
  • Legacy Issue Number: 16688
  • Status: closed  
  • Source: Logica UK ( Peter Bryant)
  • Summary:

    C.3.2 includes an acknowledgement for the original authors of the SAR model in MODAF, which I believe was included at my request.
    The listing for 'Peter Martin of LogicaCMG' should read 'Peter Bryant of Logica'.

  • Reported: UPDM 1.1 — Wed, 16 Nov 2011 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Think this was done in the Jan 12 revision but we need to note in RTF.

    Current text in OMG 12-01-03 document is the following:
    ________________________________
    D.3.2 Acknowledgements
    The scenario is derived from the UK Search and Rescue framework, which is publicly available on the internet3. The sample problem is based on a concept derived by VEGA under contract for the UK MOD.4 The UPDM Group acknowledges its debt owed to the authors of the original problem:

    • Ian Bailey of Model Futures,
    • Peter Bryant of Logica, and
    • Paul King of Vega
    ____________________________________________________________

    We need to ensure that this change is in version 2.1 as well
  • Updated: Fri, 6 Mar 2015 20:59 GMT

No definition for PhysicalResource

  • Key: UPDM2-30
  • Legacy Issue Number: 17448
  • Status: closed  
  • Source: CSC ( Peter Kelley)
  • Summary:

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

  • Reported: UPDM 2.0 — Tue, 19 Jun 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 55 and 56 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing TOC entries

  • Key: UPDM2-29
  • Legacy Issue Number: 17447
  • Status: closed  
  • Source: CSC ( Peter Kelley)
  • Summary:

    The TOC fails to include references to many of the UPDM entities defined in the document. The PDF bookmarks also omit these entries. The TOC defines ProjectMilestoneRole on page 39 and the next entry is UPDM L1::UPDM l0::DoDAF on page 161. Even though these elements are at similar document heading levels one is an entity definition and the other is a collection of entities. ProjectMilestoneRole actually ends on page 40 and UPDM L1::UPDM::L0::Core::AllElements begins on page 40 with no TOC entry.

    This issue makes the specification extremely difficult to navigate with as there is no overview of the structure and finding a particular element requires searching which can bring up many irrelevant mentions of common words.

    To fix this problem either the TOC needs to be regenerated with entries down to heading level 6 or below or the sections need to be restructured so that heading level corresponds to the level of detail.

  • Reported: UPDM 2.0 — Tue, 19 Jun 2012 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Due to the final edited format of the specification document, we cannot regenerate the table of content entries. It might be possible to complete this change in final editing which is outside the scope of the RTF.

    Therefore it was decided to close this issue with no change.

    Proposed Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 2.1.2

  • Key: UPDM2-15
  • Legacy Issue Number: 17026
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    2.1.2: it's wrong to say that "Figure 2.2 illustrates that UPDM

    Compliance level 1...imports the rest of the SysML sub-profiles". Also
    that it illustrates that it "defines constraints"
  • Reported: UPDM 2.0 — Fri, 20 Jan 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

2.1.1: typo: it has RequiresPoint which does not exist in SoaML and I

  • Key: UPDM2-14
  • Legacy Issue Number: 17025
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    2.1.1: typo: it has RequiresPoint which does not exist in SoaML and I

    believe should be RequestPoint as in the diagram above.
    this has been repaired.
    The text is still inconsistent with the diagram -the text is missing
    Capability, ServiceInterface.
  • Reported: UPDM 2.0 — Fri, 20 Jan 2012 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Update diagram 2.2 ServicePoint, RequestPoint, to be Service and Request.
    Also update associated text in section 2.1.1.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The ISO8601:2004 is probably a normative reference and should be placed in section 3

  • Key: UPDM2-9
  • Legacy Issue Number: 16641
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The ISO8601:2004 is probably a normative reference and should be placed in section 3.

    Recommended text:

    ISO 8601:2004 Data elements and interchange formats – Information interchange – Representation of dates and times”, IS0, TC154
  • Reported: UPDM 1.1 — Fri, 28 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Update the document section 3 as proposed

    Add the following text as an additional bullet point in section 3.2:

    • 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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.2.1.1.3 and 8.2.1.1.3.1 define ISO8601DateTime

  • Key: UPDM2-8
  • Legacy Issue Number: 16640
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The text for the definition in 8.2.1.1.3.1 is not internally consistent, nor consistent with ISO8601

    Current Text

    “MODAF: A date and time specified in the ISO8601 date-time format including timezone designator (TZD):
    YYYY-MMDDThh:mm:ssTZD So, 7:20pm and 30 seconds on 30th July 2005 in the CET timezone would be represented as “2005- 07-30T19:20:30+01 :00.”

    You may notice that the “-“ and “ “ in the pattern definition and in the example are not consistent. The ISO definition is as follows:

    YYYY-MM-DDThh:mm:ssTZD

    Where TZD= Z for Zulu (GMT)

    = or ±NN:NN

    With the example of 7:20 pm and 30 seconds on 30th July 2005 in the CET (Central European)Timezone would be

    “2005-07-30T19:20:30+01:00”

    Suggested Fix.

    a) Correct Pattern definition

    YYYY-MMDDThh:mm:ssTZD à YYYY-MM-DDThh:mm:ssTZD (where TZD=Z or ±NN:NN)

    This adds the – between the MM and DD subfields, and explains the possible values for the TZD field

    b) Correct Example

    2005- 07-30T19:20:30+01 :00 à 2005-07-30T19:20:30+01:00

    This drops the extra space before the month and after the timezone offset hour.
  • Reported: UPDM 1.1 — Fri, 28 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    The current version of the specfiication has the correct definition of IS08601 date time in the spec. Therefore it was decided to close this issue with no change

    Proposed Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Increment and out of service milestones do not pair

  • Key: UPDM2-7
  • Legacy Issue Number: 16580
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    Increment and out of service milestones do not pair. For instance if you have two out of service milestones defined you cannot know which one is the right one for a concrete increment. I'm thinking about solving this issue by using milestone sequence relationship; however project sequence can be used for other purposes as well. The usage of it is somehow ambiguous, especially in a case like this.

  • Reported: UPDM 1.1 — Mon, 3 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    After discussion with Lars, there are some rules that need be made explicit in the spec. I.e capability increments that are related by CapabilityIncrement then ConfigurationDeployed, ConfigurationNoLongerUsed (as configuration is dropped by Actual org) and finally OutOfService when no org is using the configuration.

    Add some descriptive text to the elements above as guidance on usage. This is added in the description of the diagrams that are used to capture Milestones which are AcV-2/PV-2

    Add the following Descriptive text to the following section:

    Updated Text:

    B.1.1.2 AcV-2/PV-2

    IncrementMilestone and OutOfServiceMilestone are both tied to a particular SystemResource, this implies that the connection to a given SystemResource indicates how the pairing should be made.

    All in all there are 4 different milestones for which there is an implied order. This order is however not enforced by the framework and needs to be dealt with by the architect. The rules for this ordering are as follows:
    • IncrementMilestone:
    Has to be associated with a date that precedes all milestones below for a specified uniquely identifiable SystemResource.
    • DeployedMilestone:
    Has to be associated with a date that occurs after the IncrementMilestone and associated the SystemResource with a specific Organization,
    • NoLongerUsedMilestone:
    Has to be associated with a date that occurs after the DeployedMilestone for a specific SystemResource, Organization combination. This milestone cannot exist if the DeployedMilestone does not exist for the same given SystemResource, Organization combination.
    • OutOfServiceMilestone:
    Has to be associated with date that occurs after or at the same time as the latest NoLongerUsedMilestone for the uniquely identifiable SystemResource and requires that no organization still has this system resource deployed (or after the IncrementMilestone if the SystemResource was never deployed to any organization before being put outOfService).

  • Updated: Fri, 6 Mar 2015 20:59 GMT

It's not possible to show that a resource configuration realizes two or more capabilities at different periods of time

  • Key: UPDM2-4
  • Legacy Issue Number: 16577
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    It is not possible to show that a resource configuration realizes two or more capabilities at different periods of time. It is because increment and out of service milestones are not related to capability. By not having this relationship all periods of time that are described by milestones are applicable to both capabilities realized by the same resource. For instance I want to say that my configuration X will realize capability A starting from 2010.01.01 till 2011.02.12 and will realize capability G starting from 2011.03.01 till 2011.04.12. As I've mentioned before milestones that are holding the date values are not related to capabilities, so what I get is capabilities A and G are realized by the resource configuration X in two periods of time (from 2010.01.01 till 2011.02.12 and from 2011.03.01 till 2011.04.12). By not having relationship between capability and a milestone I can say that for instance increment milestone holding date 2011.03.01 is incrementing G capability. But it can increment A capability as well.

  • Reported: UPDM 1.1 — Mon, 3 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Leave it how it is. This information needed to be captured as it is outside the scope of MODAF STV-3

    Add guidance to the spec in the context of the framework that a person is using. Text added to STV-3 description in the model

    Add the following text to section A.1.5.4 StV-3/CV-3 and section B1.5.4 StV-3/CV-3

    The IncrementMilestone and RetirementMilestone in UPDM originate from the MODAF framework. They tie to a PhysicalArchitecture/ CapabilityConfiguration and if the latter is indicated this in turn ties to a Capability since it is a CapableElement that exhibits a Capability. Capabilities are by themselves timeless i.e. it should not be possible to associate Capabilities and time directly. If an IncrementMilestone connects to CapabilityConfiguration X at time T and this configuration realizes Capability A, it cannot at a later time also realize Capability B without something having changed, i.e. there has to be a CapabilityConfiguration X’ that is tied to an IncrementMilestone where capabilities A and B are realized. It is suggested that these two CapabilityConfigurations are treated as versions of a CapabilityConfiguration master (SV-8).
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Broken link for issue reporting

capability to assign actual organizational resources to a project in a particular time frame missing

  • Key: UPDM2-6
  • Legacy Issue Number: 16579
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    . I'm missing a capability to assign actual organizational resources to a project in a particular time frame. There is a relationship called Organizational Project Relationship, however it does not have start and end date properties. By not having this capability I cannot calculate how much time on a project spent one or another employee and compare this value with a number required by typical organizational resources for the same project.
  • Reported: UPDM 1.1 — Mon, 3 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 39 through 44 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Project Sequence should have a tag Sequence Kind

  • Key: UPDM2-5
  • Legacy Issue Number: 16578
  • Status: closed  
  • Source: Dassault Systemes ( Dr. Aurelijus Morkevicius)
  • Summary:

    I would suggest Project Sequence would have a tag Sequence Kind to store values like "start-to-start", "start-to-finish", "finish-to-start", and “finish-to-finish".

  • Reported: UPDM 1.1 — Mon, 3 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    The rationale behind the request is that it keeps alignment with standard project management tools. Aurelijus suggested a text field to describe this relationships, Lars said this is outside the intent of MODAF and there is an implicit understanding that a target project cannot start until source project finishes.

    There is a workaround which is to use measurements applied to project to capture this information.

    Therefore it was decided to close this issue with no change

    Proposed Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:59 GMT

UPDM -- title

  • Key: UPDM-1
  • Legacy Issue Number: 11344
  • Status: open  
  • Source: International Business Machines ( Mr. Fred Mervine)
  • Summary:

    Footer is "Business Maturity Model" should be "UML Profile for DoDAF and MODAF, Beta 1
  • Reported: UPDM 1.0 — Wed, 12 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 10.4.6

  • Key: UPDM-10
  • Legacy Issue Number: 11960
  • Status: open  
  • Source: Unicom Systems ( Mr. Lou Varveris)
  • Summary:

    Is an OrganizationalRole different than an OperationalCapabilityRole? If so, this should be stated. UPDM spec should provide examples of the differences.

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

Section: 10.4.5.3

  • Key: UPDM-9
  • Legacy Issue Number: 11959
  • Status: open  
  • Source: Unicom Systems ( Mr. Lou Varveris)
  • Summary:

    The text says that "The concept of an actor or resource that realizes an OperationalNode has been made explicit by using OrganizationalResource that plays an OperationalCapabilityRole in the context of an OperationalNode." There seems to be two interpretations in the DoDAF field of 'who' does 'what' on an OperationalNode (the 'where'). Some interpretations seem to be that the OperationalNode is conceptual, and can be a 'who' and a 'where'. However, in MITRE’s Activity Based Method, the metamodel specifically states that a Role performs an Operational Activity on an Operational Node. Therefore an Operational Node is a “where”, and a Role is a “who”. DoDAF 1.5 has introduced the concept of OperationalRole but it seems to be a different concept than specifying a 'who' – in other words, DoDAF 1.5 says an OperationalNode plays the OperationalRole of 'service provider', 'service consumer', or 'unanticipated user'. This is different than saying the OperationalRole is the 'who' that can be many different types of roles (besides those three). In this referenced paragraph in the UPDM spec, it would seem that the interpretation is that an OperationalNode can be a 'who', and that 'who' is specified by OperationalCapabilityRole, which can take on values "Service Provider", "Service Consumer", and "Unanticipated User". What of other roles then? Should OrganizationalRole (also in the UPDM domain metamodel) be used to specify 'who' does 'what' on an OperationalNode (the 'where')? All of this should be clearly sorted out in the UPDM domain metamodel and described clearly in the UPDM text.

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

Section: 8.5.3 Add stereotyped association between Milestone and Capability

  • Key: UPDM-4
  • Legacy Issue Number: 11808
  • Status: open  
  • Source: us.ibm.com ( Paul Bahrs)
  • Summary:

    Add stereotyped association between Milestone and Capability Configuration.
  • Reported: UPDM 1.0 — Tue, 11 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page: Page 3 (PDF page 17)

  • Key: UPDM-3
  • Legacy Issue Number: 11684
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Chapter 1, paragraph 1, line 3 "Ministry of Defense" should be "Ministry of Defence" (note UK spelling of "Defence" in the name of the UK ministry concerned). I checked, and as far as I can tell all other instances of "Ministry of Defense" are correctly spelled.

  • Reported: UPDM 1.0 — Fri, 26 Oct 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Refine the L1 compliance example in Section 10

  • Key: UPDM-7
  • Legacy Issue Number: 11894
  • Status: open  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Refine the L1 compliance example in Section 10 that was included in the approved December ballot of the resolution to Issue-11237. The page numbers 8-17 refer to the page numbers in the proposed resolution that was on the ballot.
  • Reported: UPDM 1.0 — Wed, 26 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

UPDM compliance level 1

  • Key: UPDM-6
  • Legacy Issue Number: 11893
  • Status: open  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    resolve how vision, requirements, and view/viewpoint are extended in the UPDM compliance level 1 (SysML)
  • Reported: UPDM 1.0 — Wed, 26 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: B.4.19 OperationalServiceProvider

  • Key: UPDM-12
  • Legacy Issue Number: 11963
  • Status: open  
  • Source: Unicom Systems ( Mr. Lou Varveris)
  • Summary:

    OperationalServiceProvider has been introduced because of DoDAF 1.5. If one is to assign an Operational Node the OperationalCapabilityRole of OperationalServiceProvider, shouldn’t they also specify the Service that the Operational Node is providing? If so, or if not, the text in the Description (paragraph B.4.19.3) should specify how one uses this property value. Right now it seems open to interpretation.
  • Reported: UPDM 1.0 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: B.4.19 OperationalServiceConsumer

  • Key: UPDM-11
  • Legacy Issue Number: 11962
  • Status: open  
  • Source: Unicom Systems ( Mr. Lou Varveris)
  • Summary:

    OperationalServiceConsumer has been introduced because of DoDAF 1.5. If one is to assign an Operational Node the OperationalCapabilityRole of OperationalServiceConsumer, shouldn’t they also specify the Service that the Operational Node is consuming? If so, or if not, the text should specify how one uses this property value. Right now it seems open to interpretation.

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

What UPDM elements/constructs relate to the DLOD elements

  • Key: UPDM-5
  • Legacy Issue Number: 11809
  • Status: open  
  • Source: us.ibm.com ( Paul Bahrs)
  • Summary:

    What UPDM elements/constructs relate to the DLOD elements. I think the first cut is: Training - competence (amplified by organization delivering competence) Equipment - material Logistics - ? Infrastructure - System Node Organization - Organizational Resource Doctrine/concepts - Doctrine Information - ? Personnel - roles/competence

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

Section: 8.4.25.3

  • Key: UPDM-8
  • Legacy Issue Number: 11958
  • Status: open  
  • Source: Unicom Systems ( Mr. Lou Varveris)
  • Summary:

    Text describes three instances of OperationalRole, yet the picture only has two – it is missing “Unanticipated User”. Note: In the DoDAF 1.5 spec, "Unanticipated User" is specified as one of the three types of OperationalRoles that should exist, so the text seems correct
  • Reported: UPDM 1.0 — Mon, 31 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 8.4.13

  • Key: UPDM-2
  • Legacy Issue Number: 11597
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    There is no level identifier property for OperationalActivity
  • Reported: UPDM 1.0 — Fri, 4 Oct 2047 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fix TM symbol in Trademarks

  • Key: UPDM11-30
  • Legacy Issue Number: 16160
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Original

    MDA®, Model Driven Architecture®, UML®, UML Cube logo®, OMG Logo®, CORBA® and XMI® are registered trademarks of the Object Management Group, Inc., and Object Management GroupTM, OMGTM , Unified Modeling LanguageTM, Model Driven Architecture LogoTM, Model Driven Architecture DiagramTM, CORBA logosTM, XMI LogoTM, CWMTM, CWM LogoTM, IIOPTM , MOFTM , OMG Interface Definition Language (IDL)TM, and OMG SysMLTM are trademarks of the Object Management Group. All other products or company names mentioned are used for identification purposes only, and may be trademarks of their respective owners.

    Revised

    MDA®, Model Driven Architecture®, UML®, UML Cube logo®, OMG Logo®, CORBA® and XMI® are registered trademarks of the Object Management Group, Inc., and Object Management Group ™, OMG ™ , Unified Modeling Language ™, Model Driven Architecture Logo ™, Model Driven Architecture DiagramTM, CORBA logosTM, XMI Logo ™, CWM ™, CWM Logo ™, IIOP ™ , MOF ™ , OMG Interface Definition Language (IDL) ™, and OMG SysML ™ are trademarks of the Object Management Group. All other products or company names mentioned are used for identification purposes only, and may be trademarks of their respective owners.
  • Reported: UPDM 1.0.1 — Sat, 23 Apr 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Need correct format
    Resolution Fixed TM
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Need to add contents to DoDAF class library section of the specification

  • Key: UPDM11-29
  • Legacy Issue Number: 16095
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Missing contents of DoDAF class library section, they need to be extracted from the model

  • Reported: UPDM 1.0 — Thu, 24 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Duplicate 16087, 16027, closed issue
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add descriptions to a number of subsections

  • Key: UPDM11-28
  • Legacy Issue Number: 16090
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Diagram Affected sections
    UPDM L1::UPDM L0::Core::AllElements::Structure missing
    description (for example "The structural aspects of the AllElements
    profile").
    UPDM L1::UPDM L0::Core::OperationalElements description should
    be laid out correctly.
    UPDM L1::UPDM L0::DoDAF::AcquisitionElements missing
    description.
    UPDM L1::UPDM L0::DoDAF::AllElements::Behavior missing
    description.
    UPDM L1::UPDM L0::DoDAF::AllElements::Environment missing
    description.
    UPDM L1::UPDM L0::DoDAF::AllElements::Measurements missing
    description.
    UPDM L1::UPDM
    L0::DoDAF::OperationalElements::Structure::Organizational missing
    description.
    UPDM L1::UPDM L0::DoDAF::StrategicElements missing
    description.
    UPDM L1::UPDM L0::DoDAF::TechnicalStandardsElements missing
    description.
    UPDM L1::UPDM L0::DoDAF::TechnicalStandardsElements::Data
    missing description.
    UPDM L1::UPDM L0::MODAF::AllElements::Environment missing
    description.
    UPDM L1::UPDM
    L0::MODAF::OperationalElements::Structure::Organizational missing
    description.
    UPDM L1::UPDM L0::MODAF::TechnicalStandardsElements
    missing description.
    PV-3 DMM diagram missing description.
    Formatted: Normal, Space Before: 0 pt,
    After: 0 pt
    Formatted Table
    Formatted: Font: 14 pt
    Formatted: Normal, Space Before: 0 pt,
    After: 0 pt, Tab stops: Not at 0.5"
    UPDM 2.0 FTF
    Disposition: Resolved
    Missing descriptions
    Document dtc/2011-065-01 Page 313
    SV-5/SvcV-5 - DMM diagram missing description.
    CV-7 - DMM diagram missing description.
  • Reported: UPDM 1.0 — Wed, 23 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Aids readability
    Resolution Add text beneath the section heading indicated in the revised
    text.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add DoDAF class library diagram

  • Key: UPDM11-25
  • Legacy Issue Number: 16087
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Add DoDAF class library diagram and relevant elements to documentation.

  • Reported: UPDM 1.0 — Wed, 23 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Needed to view the supporting elements for DoDAF
    around measurement sets and the security attributes
    group
    Resolution Create DoDAF class library diagram and populate with
    elements from the class library.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add Diagrams to show non-normative mapping of UPDM elements to views

  • Key: UPDM11-24
  • Legacy Issue Number: 16086
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Enables developers and users to understand what elements sensiby appear on the relevant UPDM views

  • Reported: UPDM 1.0 — Wed, 23 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Enables developers and users to understand what
    elements sensibly appear on the relevant UPDM views
    Resolution Add non-normative appendix of UPDM views.
    Add the UPDM views in Annex B Chapter 10
    (wholeModel.doc) into Annex B complete doc
  • Updated: Fri, 6 Mar 2015 20:59 GMT

There are two diagrams named project. It affects both Projects: core and the DoDAF one

  • Key: UPDM11-27
  • Legacy Issue Number: 16089
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:
  • Reported: UPDM 1.0 — Wed, 23 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Need to simplify the profile
    Resolution Replace section 8.3.1.1 Project both diagram and associated text
    that is there now with the diagram and text from section
    8.2.1.1.1.1.5 ProjectType (after revision of class and classifier
    roles).
    Remove section 8.2.1.2.1.1 Project and associated text
    Remove 8.2.1.1.1.1.5 ProjectType
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add SWAF and SOPES section to DMM section

  • Key: UPDM11-26
  • Legacy Issue Number: 16088
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Missing SWAF design rules and SOPEs diagrams from DMM section of documentation

  • Reported: UPDM 1.0 — Wed, 23 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Completeness of the spec
    Resolution Add SOPES section 9.2 from wholemodel doc to end
    of annex A
    ADD SWAF section 9.3 from whole model doc to end of annex
    A after SOPES
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add Diagrams to show UPDM elements that are scoped to DoDAF 2.0 diagrams

  • Key: UPDM11-23
  • Legacy Issue Number: 16085
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:
  • Reported: UPDM 1.0 — Wed, 23 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Enables DoDAF 2.0 users familiar with DM2 to see the
    relatioship between DM2 and UPDM 2
    Resolution Added normative appendix containing diagrams
    Activity, Capability,Goals, Information and data,
    Location, Measure, Naming and Description,
    Performer, Project, Resource flow, Rules, Services,
    Training skill and education.
    Add Section Annex A 9.4 from whole model .doc after the new
    section 9.3 (Swaf section) in the complete model.doc
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DoDAF Conformance Level Two. Defer PES & Temporal-Whole-Part

  • Key: UPDM11-8
  • Legacy Issue Number: 15962
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

    Description:

    1. Strike "DoDAF 2.0" and replace with "DoDAF 2.02" throughout the section.

    2. Add paragraph. "UPDM 2.0 aims to conform with DoDAF 2.02 at Level Two (2). DoDAF has defined four levels of conformance:
    1) Conceptual Conformance;
    2) Logical (Meta Model) Conformance(where there is a mapping to the terms & relationships of DM2 logical data model (LDM);
    3)Physical (Physical Exchange Specification) Conformance; and
    4) full Semantic Conformance.

    3. Add paragraph. The DoD-CIO has clarified in a Decision Brief of 12 Jan 11 that it does not expect UPDM 2.0 to achieve Level 4 conformance. Level 4 may require full implementation of 4D (geo-spatial-temporal modeling)including a global implementation of Whole-Part and Temporal-Whole-Part for all UPDM elements (classes/objects). The discussion of Level 4 Conformance has been deferred until UPDM 3.0.

  • Reported: UPDM 1.0 — Sat, 15 Jan 2011 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Update Statements of Support from DoD and MOD

  • Key: UPDM11-1
  • Legacy Issue Number: 15842
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

    "6.1.1 Statement of support from the DoD representative" (Make Request to Mr. Levine for DoD EA for IT Standards and to Mr. Okon for DoD-CIO) and "6.1.2 Statement of support from the MOD representative" (Request to Mr. Patrick Gorman)

    In re 6.1.1, I expect to respond with U.S. DoD Executive Agent for IT Standards position. Namely, UPDM Version 1.0's status as "MANDATED" for those following DoDAF 1.5; my intent to submit UPDM 2.0 as "EMERGING" as soon as OMG AB approves (anticipated for March 2011). Will note status of DoDAF 2.02 (August 2010) in DoD. Will note that UPDM DMM is aligned with DoDAF MM (DM2) as of DoDAF 2.02 via mapping matrix. Also will note status of constituent specifications UML & SysML & other?. Finally, will note UPDM 1.1 status related to the International Organization for Standardization (ISO) – being submitted AND our expectation that UPDM 2.1 will also be submitted to ISO. If OMG UPDM Group wishes to clarify other areas, please submit with request.

  • Reported: UPDM 1.0 — Wed, 24 Nov 2010 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Helps jsutify UPDM with support from MOD, DOD
    and SWAF
    Resolution working on getting support from authorities
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Update Annex C for DoDAF 2.02

  • Key: UPDM2-1
  • Legacy Issue Number: 15845
  • Status: open  
  • Source: Independent ( Leonard Levine)
  • Summary:

    Update the Sample Problem. Pay particular attention to those MODELS, Elements or items that were still in development by DoD and MOD in the year before DoDAF 2.02 (approx. Sep 09 - Aug 10) with some resolutions between UPDM DMM (domain metamodel), DoDAF Meta Model (DM2), and in part IDEAS group. A critical list should be developed and coordinated with US DM2 Working Group Chair (Mr. McDaniels) and other interested parties. The plain-English scenario must be upgraded to match UPDM 2.0 and DoDAF 2.02.

  • Reported: UPDM 1.0 — Wed, 24 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add DM2 DoDAF Meta Model to Abbreviations

  • Key: UPDM11-6
  • Legacy Issue Number: 15848
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

    5 Symbols/Acronyms

    DM2 DoDAF Meta Model
    DMM UPDM Domain Meta Model
    PES DoDAF Physical Exchange Specification

  • Reported: UPDM 1.0 — Wed, 24 Nov 2010 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Publish UPDM Domain MetaModel to DoDAF MetaModel Compliance Matrix

  • Key: UPDM11-5
  • Legacy Issue Number: 15847
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

    Either as an additional non-normative Annex or as a separte document, please publish the UPDM Domain MetaModel to DoDAF MetaModel Compliance Matrix. This spreadsheet matrix is essential to OMG UPDM Group's claim that UPDM 2.0 specification "conforms" with DoDAF MetaModel (DM2) at the proposed Level 2 (metamodel conformance). Tool vendors will also be able to facilitate their conformance using this as a checklist. Such a published matrix will also facilitate the work of vendors who wish to conform with the DoDAF Physical Exchange Specification (PES) – which is either an alternative or supplement to OMG's MODEL exchange via XMI. PES is DATA oriented and available to non-OMG-UML vendors. A tool that conformed to both DM2 and PES would conform to the proposed Level 3 for DoDAF.

  • Reported: UPDM 1.0 — Wed, 24 Nov 2010 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale I think this relates to the UPDM Profile rather than the
    DMM, the table is updated to cover mappings between
    UPDM, DODAF 2.0 and MODAF 1.2.0.4
    Resolution Replace section Table B1 UPDM Elements to
    DoDF1.5/MODAF with contents of UPDM Element
    mapping to DoDAF 2 V1 doc
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Merge project/milestone concepts in DoDAF/MoDAF to be complementary to each other

  • Key: UPDM11-10
  • Legacy Issue Number: 16021
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Merge MODAF and DODAF concepts for projects to allow Milestones and ProjectActivities to work togther

  • Reported: UPDM 1.0 — Mon, 14 Feb 2011 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale The DoDAF and MODAF ways of dealing with AcV-2
    and PV-2 are different, we need a way to tie them
    together
    Resolution Allow a specialization of Activities to represented as
    ProjectActivities and tied to Projects.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add DMM-DM2 Matrix to Conformance Statement

  • Key: UPDM11-9
  • Legacy Issue Number: 15963
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

    Description:

    Reference:
    "Issue 15847: Publish UPDM Domain MetaModel to DoDAF MetaModel Compliance Matrix (updm-2-0-ftf)"

    Add paragraph or sentence.
    "The UPDM Domain MetaModel to DoDAF MetaModel Compliance Matrix has been published as non-normative Annex [EDIT] of the specification to aid tool vendors in their claims to DoDAF Level 2 Conformance. This matrix should also facilitate upgrades to Level 3 and 4 of DoDAF Conformance in future versions of UPDM."

  • Reported: UPDM 1.0 — Sat, 15 Jan 2011 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    The traceability lies between the DoDAF 2.0.2 metamodel and
    the UPDM profile rather than the DMM. The terms in the DMM
    are similar if not identical to the DoDAF Metamodel. The
    statement will be altered to reflect this
    The UPDM Profile to DoDAF MetaModel
  • Updated: Fri, 6 Mar 2015 20:59 GMT

"6.2.2 Organization of this Specification" is OBSOLETE

  • Key: UPDM11-7
  • Legacy Issue Number: 15961
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

    Description:

    STRIKE in entirely the Old text, "6.2.2 Organization of this Specification
    DoDAF and MODAF are specifically organized around 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.0 abstract and concrete syntax around those viewpoints, so that the discussion is well-connected to their domain expertise. (See Section 1.5 for a more detailed description.)"

    Substitute:
    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. There is also a set of viewpoints and views that address the concerns of a well-defined set of stakeholders. Before DoDAF Version 2.0 and UPDM Version 2.0, these were the organizing factors. This is no longer the case. This specification organizes the presentation of the UPDM 2.0 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 is done so that the discussion is well-connected to the domain experts required to produce these views. (See Section 1.5 for a more detailed description.)"

  • Reported: UPDM 1.0 — Sat, 15 Jan 2011 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    see pages 184 - 185 of issue dtc/2011-06-12
  • Updated: Fri, 6 Mar 2015 20:59 GMT

format of submitted XMI is proprietary XML

  • Key: UPDM11-3
  • Legacy Issue Number: 15844
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    The format of the submitted XMI is XML and in proprietary rich XMI format. This appears to be unreadable by at least two common UML tools RSA and Rhapsody.

  • Reported: UPDM 1.0 — Wed, 24 Nov 2010 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    XMI has been updated to be compliant to the OMG
    standard format
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Unified Profile for the Department of Defense Architecture Framework (DoDAF) and the

  • Key: UPDM11-2
  • Legacy Issue Number: 15843
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

    Update the Sample Problem. Pay particular attention to those MODELS, Elements or items that were still in development by DoD and MOD in the year before DoDAF 2.02 (approx. Sep 09 - Aug 10) with some resolutions between UPDM DMM (domain metamodel), DoDAF Meta Model (DM2), and in part IDEAS group. A critical list should be developed and coordinated with US DM2 Working Group Chair (Mr. McDaniels) and other interested parties.

  • Reported: UPDM 1.0 — Wed, 24 Nov 2010 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:59 GMT

DoDAF Normative Reference and Bibliography

  • Key: UPDM11-4
  • Legacy Issue Number: 15846
  • Status: closed  
  • Source: Independent ( Leonard Levine)
  • Summary:

    3 Normative References. Add reference to DoDAF MetaModel (DM2) Version 2.02 of August 2008 specifically. You may need to use a web citation. Rationale: UPDM 2.0 Domain Meta Model (DMM) MUST conform to the DoDAF Meta Model 2.02 rather than 2.00 for various technical reasons.

    Bibliography, Annex D, Page 431. Citation of DoDAF should be to Version 2.0 for all three 3) volumes. Citations of DoDAF MetaModel specific Version 2.02 as should DoDAF PES Version 2.02 should be added

  • Reported: UPDM 1.0 — Wed, 24 Nov 2010 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Resolution WORKING: Need new Links
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Simplify resources model

  • Key: UPDM11-12
  • Legacy Issue Number: 16023
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Resource simplification (i.e. can we just have one Property stereotype for all Resources and just leave the others as optional aliases for MODAF)?

  • Reported: UPDM 1.0 — Mon, 14 Feb 2011 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    see pages 140 - 163 od dtc/2011-06-12
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Combine SOAML. DoD Services and MODAF services properly

  • Key: UPDM11-11
  • Legacy Issue Number: 16022
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    ServiceAccess completion:
    a. How to make it work with SOAML (e.g. should it be the only thing that can realize a ServiceInterface)?
    b. Stereotypes for owned Properties (and decomposition constraints)?
    SOAML completion:
    a. Final mapping between MODAF and SOAML.
    b. Name changes to make things compatible (or leave as aliases if the proper names are going to confuse things too much)?

  • Reported: UPDM 1.0 — Mon, 14 Feb 2011 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    see pages 109 - 139 of dtc/2011-06-12
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing DesiredEffects in UPDM

  • Key: UPDM11-22
  • Legacy Issue Number: 16084
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Need to show relationship between effects desired the desirer and the desired state that achieve that effect

  • Reported: UPDM 1.0 — Wed, 23 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Need to show relationship between effects desired the
    desirer and the desired state that achieve that effect
    Resolution Added Desirer, DesiredEffect, and Operational and
    ResourceState
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Modify relationship between EntityItems and ExchangeElements

  • Key: UPDM11-21
  • Legacy Issue Number: 16083
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Modify relationship between EntityItems and ExchangeElements to give a more graphical view of the mapping

  • Reported: UPDM 1.0 — Wed, 23 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale More graphical view of the mapping
    Resolution Add dependency “Details” between entityitems and
    exchangeElements
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add cosntructs for naming and representation where required

  • Key: UPDM11-15
  • Legacy Issue Number: 16026
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Add cosntructs for naming and representation where required

  • Reported: UPDM 1.0 — Mon, 14 Feb 2011 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Need to map representations of information into
    UPDM
    Resolution Define Information, SameAs and InformationKind to
    define types of information
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Simplify measurements model

  • Key: UPDM11-14
  • Legacy Issue Number: 16025
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    need to define Measurement enumerations and model library, DM2

  • Reported: UPDM 1.0 — Mon, 14 Feb 2011 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Need to Simplify DoDAF Measures to align with UML
    Resolution Added MeasurementSet, MeasureType and Measure to
    allow synchronisation with DoDAF 2
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add NAF to list of ArchitectureFrameworkKind

  • Key: UPDM11-18
  • Legacy Issue Number: 16080
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Add NAF to list of ArchitectureFrameworkKind

  • Reported: UPDM 1.0 — Wed, 23 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Missing from list of AFs
    Resolution Modify the element ArchitectureFrameworkKind by adding
    NAF to list of ArchitectureFrameworkKind.
    Added ArchitectureFrameworkKind to ArchitecturalDescription
    Diagram for clairification.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Rename “Element” to “UPDMElement”

  • Key: UPDM11-17
  • Legacy Issue Number: 16079
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    UPDMElement has more meaning that Element

  • Reported: UPDM 1.0 — Wed, 23 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    see pages 8 - 108 of dtc/2011-06-12
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Update L1 and L0 diagram align with current MM

  • Key: UPDM2-2
  • Legacy Issue Number: 16078
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Add SOPES and SWAF to the L1 and L0 diagram, L0 Import Participant and ServiceChannel from SOAML,

  • Reported: UPDM 1.0 — Wed, 23 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0
  • Disposition Summary:

    Adapt figure 2.2 to add SOPES and SWAF (note this is also part of one of the XMI changes as the majority of the profiles indicated in this diagram need to be changed to packages), Update figure 8.2, section 7.4 as the profile stucture is now very flat and does not need to be explained

    Remove section 7.4

    7.4 Profile Structure
    7.4.1 Top Level
    See pages 92 through 94 of dtc/2012-12-16 for details
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Simplify Location model from DM2

  • Key: UPDM11-13
  • Legacy Issue Number: 16024
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Suggest enum be used to define locationkinds

  • Reported: UPDM 1.0 — Mon, 14 Feb 2011 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Too many types of location elements location
    taxonomy in DM2, needs to be simplified to reduce
    complexity
    Resolution Added LocationKind, LocationTypeKind,
    GeoPoliticalExtentKind and
    GeopoliticalExtentTypeKind with enumarated literals
    that map to DM2 types of Location and
    GeopoliticalExtent
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Added ProjectMilestoneRole

  • Key: UPDM11-19
  • Legacy Issue Number: 16081
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Needed to change the way that ActualProjects relate to the actualProjectMilestones so that it is more UML like

  • Reported: UPDM 1.0 — Wed, 23 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Needed to change the way that ActualProjects relate to
    the actualProjectMilestones so that it is more UML like
    Resolution Added ProjectMilestoneRole as an
    InstanceSpecification and ActualProjectMilestoneRole
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Update SysML mapping and OCL

  • Key: UPDM11-20
  • Legacy Issue Number: 16082
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Update SysML mapping and OCL to SySML 1.2

  • Reported: UPDM 1.0 — Wed, 23 Mar 2011 04:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale Align mapping of elements to SysML 1.2
    Resolution Changes to SysML mapping table and XMI version
    2.1.1
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing security attributes group from DM2

  • Key: UPDM11-16
  • Legacy Issue Number: 16027
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Add security attributes group as model library to Profile

  • Reported: UPDM 1.0 — Mon, 14 Feb 2011 05:00 GMT
  • Disposition: Resolved — UPDM 1.1
  • Disposition Summary:

    Rationale No SecurityAttributes in UPDM
    Resolution Added SecurityAttributesModel to UPDM
    16027
    Add
  • Updated: Fri, 6 Mar 2015 20:59 GMT