${taskforce.name} Avatar
  1. OMG Task Force

UPDM FTF — All Issues

  • Key: UPDM
  • Issues Count: 778
Create Issue
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
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
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
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
UPDM-13 SysML stereotype references in the UPDM specification need to be updated UPDM 1.0b1 open
UPDM-15 Section: 5.3.4.2 UPDM 1.0b1 open
UPDM-14 Section: 4.3.3.3 UPDM 1.0b1 open
UPDM-17 Section: 4.2.10.6 UPDM 1.0b1 open
UPDM-16 Section: 4.3.14.4 UPDM 1.0b1 open
UPDM-20 Section: 8.6.11.6 Data Exchange UPDM 1.0b1 open
UPDM-19 8.4.8.6 Constraints UPDM 1.0b1 open
UPDM-24 Section: Part III UPDM 1.0b1 open
UPDM-23 Section: Figure 7.1 UPDM 1.0b1 open
UPDM-26 Section: Figure 8.11 UPDM 1.0b1 open
UPDM-25 Section: Figure 8.1 UPDM 1.0b1 open
UPDM-18 Page: 29 - Image shown is to small to read UPDM 1.0b1 open
UPDM-1 UPDM -- title UPDM 1.0 open
UPDM-10 Section: 10.4.6 UPDM 1.0 open
UPDM-9 Section: 10.4.5.3 UPDM 1.0 open
UPDM-4 Section: 8.5.3 Add stereotyped association between Milestone and Capability UPDM 1.0 open
UPDM-3 Page: Page 3 (PDF page 17) UPDM 1.0 open
UPDM-7 Refine the L1 compliance example in Section 10 UPDM 1.0 open
UPDM-6 UPDM compliance level 1 UPDM 1.0 open
UPDM-12 Section: B.4.19 OperationalServiceProvider UPDM 1.0 open
UPDM-11 Section: B.4.19 OperationalServiceConsumer UPDM 1.0 open
UPDM-5 What UPDM elements/constructs relate to the DLOD elements UPDM 1.0 open
UPDM-8 Section: 8.4.25.3 UPDM 1.0 open
UPDM-2 Section 8.4.13 UPDM 1.0 open

Issues Descriptions

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

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 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
    • <