OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — Open Issues

  • Acronym: SysML
  • Issues Count: 908
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML2_-424 Adopted resolution SYSML2_-403 has impact on the v1 to v2 Transformation SysML 2.0b2 open
SYSML2_-422 Properties typed by a Signal are not mapped SysML 2.0b2 open
SYSML2_-173 Flow connections are incorrectly both structure and behavior SysML 2.0b1 open
SYSML2_-417 Remove "Connection" from the names "FlowConnectionDefinition", "FlowConnectionUsage", and "SuccessionFlowConnectionUsage" SysML 2.0b2 open
SYSML2_-416 Cross features for connection definitions and connection usages SysML 2.0b2 open
SYSML2_-256 Inconsistent and/or incomplete graphical notation for standard reference-subsetted usages SysML 2.0b2 open
SYSML2_-226 Description and examples for message notation are wrong SysML 2.0b2 open
SYSML2_-407 Language description of messages is incorrect SysML 2.0b2 open
SYSML2_-405 Messages cannot have explicit flow connection definitions SysML 2.0b2 open
SYSML2_-394 deriveItemUsageItemDefinition is incorrect SysML 2.0b2 open
SYSML2_-392 TestCaseVerifyObjectiveRequirementUsage_Mapping has no general mapping SysML 2.0b2 open
SYSML2_-4 Incomplete description of TestCaseVerifyObjectiveMembership_Mapping SysML 2.0a1 open
SYSML2_-389 Incorrect graphical BNF production item-name-compartment SysML 2.0b2 open
SYSML2_-385 The operation RICOAOutputPin_Mapping::filter() should redefine Pin_Mapping::filter() SysML 2.0b2 open
SYSML2_-382 Subclause 7.7.5.3.7 Trigger_Mapping is empty SysML 2.0b2 open
SYSML2_-379 Incorrect graphical notation of nested items in item parameter SysML 2.0b2 open
SYSML2_-351 Incorrect graphical notation for parameters with nested items in example "Flow as Node" SysML 2.0b2 open
SYSML2_-378 Entry, do and exit actions compartment should be named "state actions" SysML 2.0b2 open
SYSML2_-376 Specification of Helper::getScalarValueType() uses unknown OCL function SysML 2.0b2 open
SYSML2_-374 COAPin_Mapping is not correctly specified SysML 2.0b2 open
SYSML2_-372 ValuePin_Mapping is not correctly specified SysML 2.0b2 open
SYSML2_-370 Mapping class description AEAChangeParameterFeatureMembership_Mapping is missing SysML 2.0b2 open
SYSML2_-368 Graphical notation examples violate GBNF and contain typo SysML 2.0b2 open
SYSML2_-367 Mistakes in various occurrence examples SysML 2.0b2 open
SYSML2_-366 No else branch for a decision node SysML 2.0b2 open
SYSML2_-362 Alignment of selected graphical symbols in states and actions. SysML 2.0b2 open
SYSML2_-354 Not possible to show inherited symbol in name compartment SysML 2.0b2 open
SYSML2_-323 There is no production for general-view SysML 2.0b2 open
SYSML2_-304 Diagram frame production not properly integrated into graphical BNF SysML 2.0b2 open
SYSML2_-294 Send action examples in representative notation tables wrong SysML 2.0b2 open
SYSML2_-268 Incorrect declaration of parameters on actions SysML 2.0b2 open
SYSML2_-260 Accept action in representative notation tables is confusing and needs cleanup SysML 2.0b2 open
SYSML2_-224 State machine graphical notation for entry/exit/do actions inconsistent SysML 2.0b2 open
SYSML2_-159 Textual notation for send actions is too limited SysML 2.0b1 open
SYSML2_-27 Missing graphical notation for Flows Compartment SysML 2.0a1 open
SYSML2_-15 Graphical BNF production proxy should be contextualized SysML 2.0a1 open
SYSML2_-14 Graphical BNF production sq-ev-occurrence has inconsistent proxy notation SysML 2.0a1 open
SYSML2_-359 SysMLv2 Metadata Annotation Capabilities do Not Hide enough Implementation Details in Textual Representation SysML 2.0b2 open
SYSML2_-311 Fix errors in resolution of issue SYSML2_-203 (InitialState mapping) SysML 2.0b2 open
SYSML2_-415 All redefinitions of mapping features should be visible in the generated document SysML 2.0b2 open
SYSML2_-409 Notation should be more formally tied with Abstract Syntax SysML 2.0b2 open
SYSML2_-410 Definitions of View Usage are Too Restricted SysML 2.0b2 open
SYSML2_-411 Accept after guard causes errors in IDE SysML 2.0b2 open
SYSML2_-412 Apparent use of an overly-generic notation entry in subsetting or redefinition notation specification for Connection end SysML 2.0b2 open
SYSML2_-413 ownedParameterMember should be ownedMemberParameter SysML 2.0b2 open
SYSML2_-414 flow-label definition cut short SysML 2.0b2 open
SYSML2_-30 Graphical notation for variant inheritance from variation requires improvement SysML 2.0a1 open
SYSML2_-245 Multiple vs Single Trigger/Guard/Effect for State Transitions Contradiction SysML 2.0b2 open
SYSML2_-132 TimeEvent should be mapped to an accept action instead of TextualRepresentation SysML 2.0b1 open
SYSML2_-131 ChangeEvent should be mapped to an accept action instead of TextualRepresentation SysML 2.0b1 open
SYSML2_-44 Transformation of UML4SysML::ActivityFinalNode is not specified yet SysML 2.0a1 open
SYSML2_-360 Each FlowConnectionUsage owned by PartUsage subsets 3 features SysML 2.0b2 open
SYSML2_-401 proxy connection points are not contextualized in sequence diagrams SysML 2.0b2 open
SYSML2_-363 Flow Connection Payload modeling - Different models created for definition through sytactic sugar vs fully expanded definition SysML 2.0b2 open
SYSML2_-364 Syntactic Sugar Notation to Define Payload for Flow Def SysML 2.0b2 open
SYSML2_-365 Flow Connection End modeling - Different models created for definition through sytactic sugar vs fully expanded definition SysML 2.0b2 open
SYSML2_-369 Library description of Duration of is truncated SysML 2.0b2 open
SYSML2_-280 Header description of unowned elements does not align with textual notation SysML 2.0b2 open
SYSML2_-398 Stakeholder_Mapping should map from Classifier to PartDefinition SysML 2.0b2 open
SYSML2_-283 Table 5 Attributes Compartment Graphical Notation and Textual Notation does not match SysML 2.0b2 open
SYSML2_-282 P8 import textual notation may have errors SysML 2.0b2 open
SYSML2_-222 TransitionUsage source and target properties do not support feature chains SysML 2.0b2 open
SYSML2_-285 Multiple textual notation issues SysML 2.0b2 open
SYSML2_-352 Error in specification of library model UUIDs SysML 2.0b2 open
SYSML2_-346 Chapter 7.8.7.3.4 is empty SysML 2.0b2 open
SYSML2_-345 Chapter 7.8.7.3.3 FeatureDirectionKind is empty SysML 2.0b2 open
SYSML2_-330 Typo - "calculation" instead of "constraint" SysML 2.0b2 open
SYSML2_-314 Actor should be mapped to a PartDefinition SysML 2.0b2 open
SYSML2_-305 SysMLv1Tov2.xmi contains temporary mapping classes SysML 2.0b2 open
SYSML2_-300 Weak check of input parameter in Helper::getScalarValueType SysML 2.0b2 open
SYSML2_-291 Typo in definition of RenderingDefinition SysML 2.0b2 open
SYSML2_-288 Missing word in description of view usage SysML 2.0b2 open
SYSML2_-286 Misspelling in Table 16 / graphical and textual notation do not match SysML 2.0b2 open
SYSML2_-281 Error in textual notation on this page ("comment Comment 2") SysML 2.0b2 open
SYSML2_-279 Presuming missing word in sentence describing implicit annotation. SysML 2.0b2 open
SYSML2_-267 Invalid use of "loop" as merge action name SysML 2.0b2 open
SYSML2_-220 Replace Generic mapping classes by Initializers SysML 2.0b2 open
SYSML2_-206 Editorial errors in constraints SysML 2.0b2 open
SYSML2_-171 Helper::getScalarValueType operation is not robust enough SysML 2.0a1 open
SYSML2_-361 Support SysML stereotypes applied to specialized metaclasses SysML 2.0b2 open
SYSML17-650 Directed Composition SysML 1.6 open
SYSML2_-357 Incosistency between notation tables and BNF related to package nodes SysML 2.0b2 open
SYSML2_-356 Graphical Notation does not specify else-condition for decision nodes SysML 2.0b2 open
SYSML2_-259 Operation should not be mapped to perform action SysML 2.0b2 open
SYSML2_-350 Incorrect GBNF production relationship-name SysML 2.0b2 open
SYSML2_-349 Inconsistent compartment labels SysML 2.0b2 open
SYSML2_-232 two haves SysML 2.0b1 open
SYSML2_-278 Row headers not descriptive enough SysML 2.0b2 open
SYSML2_-284 Differentiate Row Headers that say "Interface" SysML 2.0b2 open
SYSML2_-287 Why does View Definition specialise Part Definition? SysML 2.0b2 open
SYSML2_-289 Filter condition or view condition? SysML 2.0b2 open
SYSML2_-290 Is view the same as view usage? SysML 2.0b2 open
SYSML2_-292 Examples of Nested View Usages SysML 2.0b2 open
SYSML2_-293 Definition of view artifact SysML 2.0b2 open
SYSML2_-297 Proxy connection points should be applicable more broadly then currently supported by the GBNF SysML 2.0b2 open
SYSML2_-326 Use Cases should have stakeholderParameters SysML 2.0b2 open
SYSML2_-155 Comment_Mapping is missing a default rule SysML 2.0a1 open
SYSML2_-329 Mapping overview tables are wrong SysML 2.0b2 open
SYSML2_-180 Reuse of KerML textual notation productions in the SysML grammar SysML 2.0b1 open
SYSML2_-327 Transformation does not cover the deprecated elements FlowSpecification SysML 2.0b2 open
SYSML2_-325 Transformation does not cover the deprecated elements FlowPort SysML 2.0b2 open
SYSML2_-324 Representative notation example for allocation confusing/wrong? SysML 2.0b2 open
SYSML2_-136 Transformation of UML4SysML::State does not consider entry, do, and exit behavior SysML 2.0b1 open
SYSML2_-197 Inconsistent use of guillemets in graphical notation for metamodel aspects SysML 2.0b2 open
SYSML2_-321 state-flow GBNF issues SysML 2.0b2 open
SYSML2_-227 Name expressions in GBNF are too constraining SysML 2.0b2 open
SYSML2_-25 Source and target on binary ConnectionDefinition symbol missing SysML 2.0a1 open
SYSML2_-165 Semantic constraints missing for shorthand succession notation SysML 2.0b1 open
SYSML2_-200 Structured actions not properly covered by GBNF and notation tables SysML 2.0b2 open
SYSML2_-41 Semantics of a conditional succession using "else" are missing SysML 2.0a1 open
SYSML2_-113 Mapping of ObjectFlows with DecisionNodes SysML 2.0b1 open
SYSML2_-320 Specification lacks precision in multiple sentences that begin with the word 'however' SysML 2.0b2 open
SYSML2_-274 Map UML4SysML::Constraint to ConstraintUsage only SysML 2.0b2 open
SYSML2_-318 Transformation does not cover UML4SysML::ProfileApplication SysML 2.0b2 open
SYSML2_-317 Transformation does not cover SysMLv1::ConnectorProperty SysML 2.0b2 open
SYSML2_-150 OccurrenceUsage missing portioningFeature SysML 2.0b1 open
SYSML2_-310 ObjectFlow with guards outgoing from DecisionNodes are not mapped correctly SysML 2.0b2 open
SYSML2_-309 CallBehaviorAction mapping does not consider the pins SysML 2.0b2 open
SYSML2_-308 Mapping of ObjectFlow should not consider the type of the objects that flow SysML 2.0b2 open
SYSML2_-307 ActivityParameterNodes should be mapped SysML 2.0b2 open
SYSML2_-303 ConnectionPointReference_Mapping should create a Redefinition SysML 2.0b2 open
SYSML2_-272 Typos in graphical metadata representative notation SysML 2.0b2 open
SYSML2_-249 RICOAOutputPin_Mapping should specialized Pin_Mapping SysML 2.0b2 open
SYSML2_-230 Inconsistent graphical notation for view frame SysML 2.0b2 open
SYSML2_-214 Mapping of State does not consider orthogonal states SysML 2.0b2 open
SYSML2_-203 InitialState is mapped to StateUsage, but should be an empty ActionUsage SysML 2.0b2 open
SYSML2_-199 InterfaceBlock mapped to PortDefinition, but ConjugatedPortDefinition is not generated SysML 2.0b2 open
SYSML2_-112 Mapping of ObjectFlows with JoinNodes SysML 2.0b1 open
SYSML2_-111 Mapping of ObjectFlows with ForkNodes SysML 2.0b1 open
SYSML2_-23 Missing graphical notation for n-ary connection def and usage SysML 2.0a1 open
SYSML2_-302 Chapter Trigger_Mapping is empty SysML 2.0b2 open
SYSML2_-301 Mapping for UML4SysML::CallEvent and UML4SysML::AcceptCallAction are missing SysML 2.0b2 open
SYSML2_-296 Need to add terminate action node to action flow and state flow views SysML 2.0b2 open
SYSML2_-295 send and accept actions name compartment productions inconsistent SysML 2.0b2 open
SYSML2_-277 Mapping of UseCase does not consider more than one subject SysML 2.0b2 open
SYSML2_-276 Property typed by an Actor should be mapped to a PartUsage SysML 2.0b2 open
SYSML2_-275 Mapping of UML4SysML::Constraint: Bind the result parameter SysML 2.0b2 open
SYSML2_-262 Flows cannot connect ControlNodes SysML 2.0b2 open
SYSML2_-261 Graphical notation action names need to be aligned SysML 2.0b2 open
SYSML2_-207 Update language description and concrete syntax related to imports SysML 2.0b2 open
SYSML2_-187 There is no need for AnalysisAction SysML 2.0b2 open
SYSML2_-271 Mappings from the "Common" package SysML 2.0b2 open
SYSML2_-270 Type of the ReferenceUsage created for the client of a Satisfy relationship SysML 2.0b2 open
SYSML2_-269 ReferenceUsage creation in case of a Satisfy relationship transformation SysML 2.0b2 open
SYSML2_-29 Graphical BNF mapping to abstract syntax is missing SysML 2.0a1 open
SYSML2_-266 ObjectFlow mappings limited to non-streaming parameters SysML 2.0b2 open
SYSML2_-263 There is no checkSatisfyRequirementUsageSpecialization constraint SysML 2.0b2 open
SYSML2_-265 Missing semantic constraints related to features of Part SysML 2.0b2 open
SYSML2_-264 Interface usage cannot redefine inherited attributes in textual syntax SysML 2.0b2 open
SYSML2_-126 Decision/MergeNode SuccessionSpecialization checks missing some constraints SysML 2.0b1 open
SYSML2_-254 No way to expose non-membership and non-namespace elements SysML 2.0b2 open
SYSML2_-255 Name misplaced on action symbol parameter SysML 2.0b2 open
SYSML2_-221 Default multiplicities are not formally specified SysML 2.0b2 open
SYSML2_-158 timeslice/snapshot featuring types required to specialize or be same as types SysML 2.0a1 open
SYSML2_-39 Semantics of transfers across interfaces SysML 2.0a1 open
SYSML2_-253 Mapping of ClearStructuralFeatureAction is not defined yet SysML 2.0b2 open
SYSML2_-252 Mapping of RemoveStructuralFeatureValueAction is not defined yet SysML 2.0b2 open
SYSML2_-251 AddStructuralFeatureValueAction Mapping does not consider the names of the input and output pins SysML 2.0b2 open
SYSML2_-246 Ordering of guards and accepts in transitions is inconsistent SysML 2.0b2 open
SYSML2_-248 Evaluation problem with TradeStudyObjectives SysML 2.0b2 open
SYSML2_-247 Graphical BNF for n-ary ConnectionDefinition is missing SysML 2.0b2 open
SYSML2_-11 Missing explicit explanation of compartments as views SysML 2.0a1 open
SYSML2_-184 StateAction::substates has an implied subsetting of exclusiveStates SysML 2.0b2 open
SYSML2_-233 Table 6 Duplicate Row Titles SysML 2.0b1 open
SYSML2_-234 Table 16 has misspelling issue SysML 2.0b1 open
SYSML2_-235 Table 16 Graphical Notation does not match Textual Notation SysML 2.0b1 open
SYSML2_-236 Missing Complete concept SysML 2.0b2 open
SYSML2_-237 Missing Final concept SysML 2.0b2 open
SYSML2_-238 Missing isLeaf concept SysML 2.0b2 open
SYSML2_-239 Missing Element Import Alias SysML 2.0b2 open
SYSML2_-240 ShapeItems have radius feature bound SysML 2.0b2 open
SYSML2_-76 Transformation does not cover SysMLv1::FlowProperty SysML 2.0a1 open
SYSML2_-229 Invalid values can be assigned to an enum SysML 2.0b2 open
SYSML2_-40 Port transfer semantics SysML 2.0a1 open
SYSML2_-212 Inconsistencies in the graphical notation for "expose" SysML 2.0b2 open
SYSML2_-209 isOrdered and isUnique are missing from the reflective abstract mapping SysML 2.0b2 open
SYSML2_-202 Missing guidance on highlighting keywords SysML 2.0b2 open
SYSML2_-191 Error in the specification of "connections" SysML 2.0b2 open
SYSML2_-189 Incorrect enumeration example SysML 2.0b2 open
SYSML2_-183 checkStateUsageExclusiveStateSpecialization and checkStateUsageSubstateSpecialization have problems SysML 2.0b2 open
SYSML2_-177 Guillemets should not be used on keywords in textual notation snippets used in the graphical notation SysML 2.0a1 open
SYSML2_-144 Missing production for use case actors and subject SysML 2.0a1 open
SYSML2_-142 GBNF for flow connection not mapped to semantics SysML 2.0a1 open
SYSML2_-114 Symbol for metadata def is missing SysML 2.0b1 open
SYSML2_-18 No support for metadata definition in graphical notation SysML 2.0a1 open
SYSML2_-3 incorrect naming of * character SysML 2.0b1 open
SYSML2_-2 incorrect naming of * character SysML 2.0b1 open
SYSML2_-1 Issues with SysML/KerML grammar SysML 2.0b1 open
SYSML2-480 Missing production for use case actors and subject SysML 2.0a1 open
SYSML2-557 Need to complete and align flow and message notations in GBNF SysML 2.0a1 open
SYSML2_-201 Confusing send/accept examples in notation tables SysML 2.0b2 open
SYSML2-629 Guillemets are not used on keywords in textual notation snippets used in the graphical notation SysML 2.0a1 open
SYSML2-686 Reuse of KerML textual notation productions in the SysML grammar SysML 2.0b1 open
SYSML2-632 Long-form notation for bindings and successions SysML 2.0b1 open
SYSML2-639 Change graphical notation for use cases to elliptic elements SysML 2.0b1 open
SYSML2_-178 Long-form notation for bindings and successions SysML 2.0b1 open
SYSML2_-179 Change graphical notation for use cases to elliptic elements SysML 2.0b1 open
SYSML2-593 Enumerations not specializable SysML 2.0b1 open
SYSML2-591 Transformation fails on Enumerations that are ValueTypes SysML 2.0a1 open
SYSML2-594 PortUsage direction SysML 2.0b1 open
SYSML2-601 Proxy nodes are missing from states SysML 2.0a1 open
SYSML2-592 Flow connections are incorrectly both structure and behavior SysML 2.0b1 open
SYSML2_-174 Enumerations not specializable SysML 2.0b1 open
SYSML2_-176 Proxy nodes are missing from states SysML 2.0a1 open
SYSML2_-175 PortUsage direction SysML 2.0b1 open
SYSML2_-172 Transformation fails on Enumerations that are ValueTypes SysML 2.0a1 open
SYSML2-588 ObjectFlowItemFlowEndReferenceUsage_Mapping::ownedRelationship is not reliable SysML 2.0a1 open
SYSML2-589 SatisfyReferenceUsageFeatureTyping_Mapping::type() is wrong SysML 2.0a1 open
SYSML2-586 Literal factories are missing operation for their value SysML 2.0a1 open
SYSML2-590 Helper::getScalarValueType operation is not robust enough SysML 2.0a1 open
SYSML2_-170 SatisfyReferenceUsageFeatureTyping_Mapping::type() is wrong SysML 2.0a1 open
SYSML2_-168 Literal factories are missing operation for their value SysML 2.0a1 open
SYSML2_-169 ObjectFlowItemFlowEndReferenceUsage_Mapping::ownedRelationship is not reliable SysML 2.0a1 open
SYSML2-546 Add a distinguished attribute to capture the textual body of a requirement SysML 2.0b1 open
SYSML2-584 Default multiplicities are not managed correctly SysML 2.0a1 open
SYSML2-576 Semantic constraints missing for shorthand succession notation SysML 2.0b1 open
SYSML2-535 ObjectFlowItemFlowEndReferenceUsage_Mapping::ownedRelationship() is wrong SysML 2.0a1 open
SYSML2-585 Factories specified for Literal specification shall be optimized SysML 2.0a1 open
SYSML2_-167 Factories specified for Literal specification shall be optimized SysML 2.0a1 open
SYSML2_-163 ObjectFlowItemFlowEndReferenceUsage_Mapping::ownedRelationship() is wrong SysML 2.0a1 open
SYSML2_-166 Default multiplicities are not managed correctly SysML 2.0a1 open
SYSML2_-164 Add a distinguished attribute to capture the textual body of a requirement SysML 2.0b1 open
SYSML2-532 OpaqueBehavior shall be transformed even if they are not owned by a Package SysML 2.0a1 open
SYSML2-526 Textual notation for send actions is too limited SysML 2.0b1 open
SYSML2-533 Properties typed by Actors SysML 2.0a1 open
SYSML2-524 timeslice/snapshot featuring types required to specialize or be same as types SysML 2.0a1 open
SYSML2-534 Most SysML::Blocks are owned by a package SysML 2.0a1 open
SYSML2_-162 Most SysML::Blocks are owned by a package SysML 2.0a1 open
SYSML2_-160 OpaqueBehavior shall be transformed even if they are not owned by a Package SysML 2.0a1 open
SYSML2_-161 Properties typed by Actors SysML 2.0a1 open
SYSML2-506 GenericToStateUsage_Mapping is missing a default rule SysML 2.0a1 open
SYSML2-507 GenericToElement_Mapping is missing default rules SysML 2.0a1 open
SYSML2-516 Namespace_Mapping shall redefine ownedRelationship() SysML 2.0a1 open
SYSML2-508 Comment_Mapping is missing a default rule SysML 2.0a1 open
SYSML2-515 Relationship_Mapping::ownedRelatedElement() is wrong SysML 2.0a1 open
SYSML2_-156 Relationship_Mapping::ownedRelatedElement() is wrong SysML 2.0a1 open
SYSML2_-153 GenericToStateUsage_Mapping is missing a default rule SysML 2.0a1 open
SYSML2_-157 Namespace_Mapping shall redefine ownedRelationship() SysML 2.0a1 open
SYSML2_-154 GenericToElement_Mapping is missing default rules SysML 2.0a1 open
SYSML2-504 GenericToRelationship_Mapping is missing default rules SysML 2.0a1 open
SYSML2-486 Graphical notation unclear on optionality of keywords on edges SysML 2.0a1 open
SYSML2-487 Graphical notation unclear about user-defined keywords for library extensions SysML 2.0a1 open
SYSML2-503 OccurrenceUsage missing portioningFeature SysML 2.0b1 open
SYSML2-502 Control nodes missing from concrete syntax for states SysML 2.0a1 open
SYSML2-505 GenericToRequirementUsage_Mapping is missing a default rule SysML 2.0a1 open
SYSML2_-147 Graphical notation unclear on optionality of keywords on edges SysML 2.0a1 open
SYSML2_-151 GenericToRelationship_Mapping is missing default rules SysML 2.0a1 open
SYSML2_-148 Graphical notation unclear about user-defined keywords for library extensions SysML 2.0a1 open
SYSML2_-152 GenericToRequirementUsage_Mapping is missing a default rule SysML 2.0a1 open
SYSML2_-149 Control nodes missing from concrete syntax for states SysML 2.0a1 open
SYSML2-485 Clarify bolding of keywords in concrete graphical syntax SysML 2.0a1 open
SYSML2-483 Incorrect definition elements in interconnection-element SysML 2.0b1 open
SYSML2-479 Missalignment between interface graphical production and notation table SysML 2.0a1 open
SYSML2-482 Missing production for use case actors and subject SysML 2.0a1 open
SYSML2_-143 Missalignment between interface graphical production and notation table SysML 2.0a1 open
SYSML2_-145 Incorrect definition elements in interconnection-element SysML 2.0b1 open
SYSML2_-146 Clarify bolding of keywords in concrete graphical syntax SysML 2.0a1 open
SYSML2-476 Initializer classes have to be rationalized SysML 2.0b1 open
SYSML2-477 AssociationClass_Mapping is uncomplete SysML 2.0b1 open
SYSML2-475 missing graphical bnf for events and event occurrences SysML 2.0a1 open
SYSML2-478 GBNF for flow connection not mapped to semantics SysML 2.0a1 open
SYSML2_-139 missing graphical bnf for events and event occurrences SysML 2.0a1 open
SYSML2_-140 Initializer classes have to be rationalized SysML 2.0b1 open
SYSML2_-141 AssociationClass_Mapping is uncomplete SysML 2.0b1 open
SYSML2-472 Optional language for documentation SysML 2.0b1 open
SYSML2-463 Transformation of UML4SysML::State does not consider entry, do, and exit behavior SysML 2.0b1 open
SYSML2-462 element-node not defined SysML 2.0a1 open
SYSML2-473 ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless SysML 2.0b1 open
SYSML2_-138 ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless SysML 2.0b1 open
SYSML2_-137 Optional language for documentation SysML 2.0b1 open
SYSML2_-135 element-node not defined SysML 2.0a1 open
SYSML2-445 ConstraintProperty should be mapped to a AssertConstraintUsage SysML 2.0b1 open
SYSML2-397 TransitionUsage requires binding to succession with mandatory end multiplicities SysML 2.0b1 open
SYSML2-456 Missing production for n-ary connection definition graphical SysML 2.0a1 open
SYSML2-448 ChangeEvent should be mapped to an accept action instead of TextualRepresentation SysML 2.0b1 open
SYSML2-449 TimeEvent should be mapped to an accept action instead of TextualRepresentation SysML 2.0b1 open
SYSML2-450 Fork/JoinNode succession "other" end multiplicity validations missing SysML 2.0b1 open
SYSML2_-130 ConstraintProperty should be mapped to a AssertConstraintUsage SysML 2.0b1 open
SYSML2_-134 Missing production for n-ary connection definition graphical SysML 2.0a1 open
SYSML2_-133 Fork/JoinNode succession "other" end multiplicity validations missing SysML 2.0b1 open
SYSML2_-129 TransitionUsage requires binding to succession with mandatory end multiplicities SysML 2.0b1 open
SYSML2-385 CommentAnnotation_Mapping shall be a "unique" mapping SysML 2.0a1 open
SYSML2-353 Feature modifiers missing in Portion Membership examples SysML 2.0b1 open
SYSML2-357 Representative example "Package with members" to be improved SysML 2.0b1 open
SYSML2-390 Actor and subject parameter notation not effective SysML 2.0a1 open
SYSML2-383 Decision/MergeNode SuccessionSpecialization checks missing some constraints SysML 2.0b1 open
SYSML2_-127 CommentAnnotation_Mapping shall be a "unique" mapping SysML 2.0a1 open
SYSML2_-124 Feature modifiers missing in Portion Membership examples SysML 2.0b1 open
SYSML2_-128 Actor and subject parameter notation not effective SysML 2.0a1 open
SYSML2_-125 Representative example "Package with members" to be improved SysML 2.0b1 open
SYSML2-352 Feature modefiers missing in Feature Membership examples SysML 2.0b1 open
SYSML2-326 Wrong imported package notation SysML 2.0b1 open
SYSML2-329 Representative notation for filtered package import missing SysML 2.0b1 open
SYSML2-337 Incomplete example "Individual Occurrence" SysML 2.0b1 open
SYSML2-327 Package import wildcard is missing SysML 2.0b1 open
SYSML2_-119 Wrong imported package notation SysML 2.0b1 open
SYSML2_-123 Feature modefiers missing in Feature Membership examples SysML 2.0b1 open
SYSML2_-122 Incomplete example "Individual Occurrence" SysML 2.0b1 open
SYSML2_-120 Package import wildcard is missing SysML 2.0b1 open
SYSML2_-121 Representative notation for filtered package import missing SysML 2.0b1 open
SYSML2-320 Binding between action parameters and directed features on ports missing SysML 2.0b1 open
SYSML2-317 Metadata declaration needs clarification SysML 2.0b1 open
SYSML2-324 Missing representative notation for causation and requirements derivation SysML 2.0b1 open
SYSML2-323 Nesting parameter symbol is missing optional nested parameter SysML 2.0b1 open
SYSML2_-118 Missing representative notation for causation and requirements derivation SysML 2.0b1 open
SYSML2_-115 Metadata declaration needs clarification SysML 2.0b1 open
SYSML2_-116 Binding between action parameters and directed features on ports missing SysML 2.0b1 open
SYSML2_-117 Nesting parameter symbol is missing optional nested parameter SysML 2.0b1 open
SYSML2-313 Mapping of ObjectFlows with ForkNodes SysML 2.0b1 open
SYSML2-315 Mapping of ObjectFlows with DecisionNodes SysML 2.0b1 open
SYSML2-314 Mapping of ObjectFlows with JoinNodes SysML 2.0b1 open
SYSML2-316 Symbol for metadata def is missing SysML 2.0b1 open
SYSML2-311 Transformation does not cover the mapping of Unit and QuantityKind SysML 2.0b1 open
SYSML2-297 SysML Libraries' elements shall have an elementId defined SysML 2.0a1 open
SYSML2-286 the getMapped operation cannot be called on ElementOwnership_Mapping SysML 2.0a1 open
SYSML2-307 Various constraints need to take feature chaining into account SysML 2.0b1 open
SYSML2-309 Transformation does not cover mapping of Parameter::isStreaming=true SysML 2.0b1 open
SYSML2_-109 Transformation does not cover mapping of Parameter::isStreaming=true SysML 2.0b1 open
SYSML2_-107 SysML Libraries' elements shall have an elementId defined SysML 2.0a1 open
SYSML2_-110 Transformation does not cover the mapping of Unit and QuantityKind SysML 2.0b1 open
SYSML2_-106 the getMapped operation cannot be called on ElementOwnership_Mapping SysML 2.0a1 open
SYSML2_-108 Various constraints need to take feature chaining into account SysML 2.0b1 open
SYSML2-272 Transformation does not cover UML4SysML::ReadLinkAction SysML 2.0a1 open
SYSML2-274 Transformation does not cover UML4SysML::DestroyLinkAction SysML 2.0a1 open
SYSML2-283 Transformation of UML4SysML::AcceptEventAction with more than one triggers not covered yet SysML 2.0a1 open
SYSML2-284 Transformation does not cover UML4SysML::FunctionBehavior SysML 2.0a1 open
SYSML2-273 Transformation does not cover UML4SysML::CreateLinkAction SysML 2.0a1 open
SYSML2_-105 Transformation does not cover UML4SysML::FunctionBehavior SysML 2.0a1 open
SYSML2_-102 Transformation does not cover UML4SysML::CreateLinkAction SysML 2.0a1 open
SYSML2_-101 Transformation does not cover UML4SysML::ReadLinkAction SysML 2.0a1 open
SYSML2_-104 Transformation of UML4SysML::AcceptEventAction with more than one triggers not covered yet SysML 2.0a1 open
SYSML2_-103 Transformation does not cover UML4SysML::DestroyLinkAction SysML 2.0a1 open
SYSML2_-100 Transformation does not cover UML4SysML::SignalEvent SysML 2.0a1 open
SYSML2-271 Transformation does not cover UML4SysML::SignalEvent SysML 2.0a1 open
SYSML2-187 Transformation does not cover the different UML4SysML::PseudoStates SysML 2.0a1 open
SYSML2-225 Some Standard View Definitions should be filtered specializations of General View SysML 2.0a1 open
SYSML2-188 Transformation of UML4SysML::InterruptibleActivityRegion is not specified yet SysML 2.0a1 open
SYSML2-199 Graphical notation of State Definition not consistent with other submission documents SysML 2.0a1 open
SYSML2_-99 Some Standard View Definitions should be filtered specializations of General View SysML 2.0a1 open
SYSML2_-97 Transformation of UML4SysML::InterruptibleActivityRegion is not specified yet SysML 2.0a1 open
SYSML2_-96 Transformation does not cover the different UML4SysML::PseudoStates SysML 2.0a1 open
SYSML2_-98 Graphical notation of State Definition not consistent with other submission documents SysML 2.0a1 open
SYSML2-183 Some package-level features are mandatory SysML 2.0a1 open
SYSML2-186 ConstraintBlock mapping parameters to input attributes SysML 2.0a1 open
SYSML2-160 Machine readable project interchange file(s) for language description examples SysML 2.0a1 open
SYSML2-161 XMI and JSON for example model SysML 2.0a1 open
SYSML2-177 Assignment action usages do not specify when their expressions are evaluated SysML 2.0a1 open
SYSML2_-91 Machine readable project interchange file(s) for language description examples SysML 2.0a1 open
SYSML2_-92 XMI and JSON for example model SysML 2.0a1 open
SYSML2_-93 Assignment action usages do not specify when their expressions are evaluated SysML 2.0a1 open
SYSML2_-95 ConstraintBlock mapping parameters to input attributes SysML 2.0a1 open
SYSML2_-94 Some package-level features are mandatory SysML 2.0a1 open
SYSML2-151 Transformation does not cover SysMLv1::NoBuffer SysML 2.0a1 open
SYSML2-152 Accepters on transition usages from entry actions SysML 2.0a1 open
SYSML2-154 Subject of an include use case usage SysML 2.0a1 open
SYSML2-150 Transformation does not cover SysMLv1::Overwrite SysML 2.0a1 open
SYSML2_-89 Accepters on transition usages from entry actions SysML 2.0a1 open
SYSML2_-90 Subject of an include use case usage SysML 2.0a1 open
SYSML2_-88 Transformation does not cover SysMLv1::NoBuffer SysML 2.0a1 open
SYSML2_-87 Transformation does not cover SysMLv1::Overwrite SysML 2.0a1 open
SYSML2-145 Transformation does not cover SysMLv1::BoundReference SysML 2.0a1 open
SYSML2-147 Transformation does not cover SysMLv1::EndPathMultiplicity SysML 2.0a1 open
SYSML2-146 Transformation does not cover SysMLv1::ParticipantProperty SysML 2.0a1 open
SYSML2-148 Transformation does not cover SysMLv1::PropertySpecificType SysML 2.0a1 open
SYSML2-149 Transformation does not cover SysMLv1::AllocateActivitiyPartition SysML 2.0a1 open
SYSML2_-83 Transformation does not cover SysMLv1::ParticipantProperty SysML 2.0a1 open
SYSML2_-85 Transformation does not cover SysMLv1::PropertySpecificType SysML 2.0a1 open
SYSML2_-86 Transformation does not cover SysMLv1::AllocateActivitiyPartition SysML 2.0a1 open
SYSML2_-84 Transformation does not cover SysMLv1::EndPathMultiplicity SysML 2.0a1 open
SYSML2_-82 Transformation does not cover SysMLv1::BoundReference SysML 2.0a1 open
SYSML2-140 Transformation does not cover SysMLv1::InvocationOnNestedPortAction SysML 2.0a1 open
SYSML2-142 Transformation does not cover SysMLv1::Conform SysML 2.0a1 open
SYSML2-144 Transformation does not cover SysMLv1::DistributedProperty SysML 2.0a1 open
SYSML2-143 Transformation does not cover SysMLv1::Expose SysML 2.0a1 open
SYSML2-141 Transformation does not cover SysMLv1::View SysML 2.0a1 open
SYSML2_-78 Transformation does not cover SysMLv1::View SysML 2.0a1 open
SYSML2_-77 Transformation does not cover SysMLv1::InvocationOnNestedPortAction SysML 2.0a1 open
SYSML2_-79 Transformation does not cover SysMLv1::Conform SysML 2.0a1 open
SYSML2_-81 Transformation does not cover SysMLv1::DistributedProperty SysML 2.0a1 open
SYSML2_-80 Transformation does not cover SysMLv1::Expose SysML 2.0a1 open
SYSML2-135 Transformation does not cover SysMLv1::TriggerOnNestedPort SysML 2.0a1 open
SYSML2-134 Transformation does not cover UML4SysML::UnmarshallAction SysML 2.0a1 open
SYSML2-136 Transformation does not cover SysMLv1::ChangeStructuralFeatureEvent SysML 2.0a1 open
SYSML2-137 Transformation does not cover SysMLv1::AddFlowPropertyValueOnNestedPortAction SysML 2.0a1 open
SYSML2-138 Transformation does not cover SysMLv1::FlowProperty SysML 2.0a1 open
SYSML2_-75 Transformation does not cover SysMLv1::AddFlowPropertyValueOnNestedPortAction SysML 2.0a1 open
SYSML2_-73 Transformation does not cover SysMLv1::TriggerOnNestedPort SysML 2.0a1 open
SYSML2_-72 Transformation does not cover UML4SysML::UnmarshallAction SysML 2.0a1 open
SYSML2_-74 Transformation does not cover SysMLv1::ChangeStructuralFeatureEvent SysML 2.0a1 open
SYSML2-129 Transformation does not cover UML4SysML::Clause SysML 2.0a1 open
SYSML2-133 Transformation does not cover UML4SysML::LinkEndData SysML 2.0a1 open
SYSML2-131 Transformation does not cover UML4SysML::LinkEndCreationData SysML 2.0a1 open
SYSML2-132 Transformation does not cover UML4SysML::LinkEndDestructionData SysML 2.0a1 open
SYSML2-128 Transformation does not cover UML4SysML::ActivityPartition SysML 2.0a1 open
SYSML2-130 Transformation does not cover UML4SysML::ConditionalNode SysML 2.0a1 open
SYSML2_-71 Transformation does not cover UML4SysML::LinkEndData SysML 2.0a1 open
SYSML2_-66 Transformation does not cover UML4SysML::ActivityPartition SysML 2.0a1 open
SYSML2_-67 Transformation does not cover UML4SysML::Clause SysML 2.0a1 open
SYSML2_-70 Transformation does not cover UML4SysML::LinkEndDestructionData SysML 2.0a1 open
SYSML2_-68 Transformation does not cover UML4SysML::ConditionalNode SysML 2.0a1 open
SYSML2_-69 Transformation does not cover UML4SysML::LinkEndCreationData SysML 2.0a1 open
SYSML2-124 Transformation does not cover UML4SysML::ExecutionOccurrenceSpecification SysML 2.0a1 open
SYSML2-125 Transformation does not cover UML4SysML::Gate SysML 2.0a1 open
SYSML2-126 Transformation does not cover UML4SysML::OccurrenceSpecification SysML 2.0a1 open
SYSML2-127 Transformation does not cover UML4SysML::InteractionConstraint SysML 2.0a1 open
SYSML2_-65 Transformation does not cover UML4SysML::InteractionConstraint SysML 2.0a1 open
SYSML2_-63 Transformation does not cover UML4SysML::Gate SysML 2.0a1 open
SYSML2_-62 Transformation does not cover UML4SysML::ExecutionOccurrenceSpecification SysML 2.0a1 open
SYSML2_-64 Transformation does not cover UML4SysML::OccurrenceSpecification SysML 2.0a1 open
SYSML2-120 Transformation does not cover UML4SysML::Continuation SysML 2.0a1 open
SYSML2-121 Transformation does not cover UML4SysML::GeneralOrdering SysML 2.0a1 open
SYSML2-122 Transformation does not cover UML4SysML::PartDecomposition SysML 2.0a1 open
SYSML2-123 Transformation does not cover UML4SysML::ConsiderIgnoreFragment SysML 2.0a1 open
SYSML2_-58 Transformation does not cover UML4SysML::Continuation SysML 2.0a1 open
SYSML2_-60 Transformation does not cover UML4SysML::PartDecomposition SysML 2.0a1 open
SYSML2_-59 Transformation does not cover UML4SysML::GeneralOrdering SysML 2.0a1 open
SYSML2_-61 Transformation does not cover UML4SysML::ConsiderIgnoreFragment SysML 2.0a1 open
SYSML2-116 Transformation does not cover UML4SysML::TimeConstraint SysML 2.0a1 open
SYSML2-119 Transformation does not cover UML4SysML::DestructionOccurrenceSpecification SysML 2.0a1 open
SYSML2-117 Transformation does not cover UML4SysML::Interval SysML 2.0a1 open
SYSML2-115 Transformation does not cover UML4SysML::DurationInterval SysML 2.0a1 open
SYSML2-118 Transformation does not cover UML4SysML::Image SysML 2.0a1 open
SYSML2_-54 Transformation does not cover UML4SysML::TimeConstraint SysML 2.0a1 open
SYSML2_-56 Transformation does not cover UML4SysML::Image SysML 2.0a1 open
SYSML2_-57 Transformation does not cover UML4SysML::DestructionOccurrenceSpecification SysML 2.0a1 open
SYSML2_-53 Transformation does not cover UML4SysML::DurationInterval SysML 2.0a1 open
SYSML2_-55 Transformation does not cover UML4SysML::Interval SysML 2.0a1 open
SYSML2-112 Transformation does not cover UML4SysML::IntervalConstraint SysML 2.0a1 open
SYSML2-113 Transformation does not cover UML4SysML::DurationObservation SysML 2.0a1 open
SYSML2-111 Transformation does not cover UML4SysML::TimeObservation SysML 2.0a1 open
SYSML2-114 Transformation does not cover UML4SysML::StringExpression SysML 2.0a1 open
SYSML2-110 Transformation does not cover UML4SysML::Duration SysML 2.0a1 open
SYSML2_-52 Transformation does not cover UML4SysML::StringExpression SysML 2.0a1 open
SYSML2_-51 Transformation does not cover UML4SysML::DurationObservation SysML 2.0a1 open
SYSML2_-49 Transformation does not cover UML4SysML::TimeObservation SysML 2.0a1 open
SYSML2_-50 Transformation does not cover UML4SysML::IntervalConstraint SysML 2.0a1 open
SYSML2_-48 Transformation does not cover UML4SysML::Duration SysML 2.0a1 open
SYSML2-107 Transformation does not cover UML4SysML::Extend SysML 2.0a1 open
SYSML2-106 Transformation of UML4SysML::ActivityFinalNode is not specified yet SysML 2.0a1 open
SYSML2-105 Transformation of UML4SysML::DataStoreNode and UML4SysML::CentralBufferNode is not complete SysML 2.0a1 open
SYSML2-109 Transformation does not cover UML4SysML::DurationConstraint SysML 2.0a1 open
SYSML2-108 Transformation does not cover UML4SysML::TimeInterval SysML 2.0a1 open
SYSML2_-43 Transformation of UML4SysML::DataStoreNode and UML4SysML::CentralBufferNode is not complete SysML 2.0a1 open
SYSML2_-47 Transformation does not cover UML4SysML::DurationConstraint SysML 2.0a1 open
SYSML2_-45 Transformation does not cover UML4SysML::Extend SysML 2.0a1 open
SYSML2_-46 Transformation does not cover UML4SysML::TimeInterval SysML 2.0a1 open
SYSML2-97 Semantics of transfers across interfaces SysML 2.0a1 open
SYSML2-104 Transformation does not cover UML4SysML::GeneralizationSet SysML 2.0a1 open
SYSML2-100 Semantics of a conditional succession using "else" are missing SysML 2.0a1 open
SYSML2-98 Port transfer semantics SysML 2.0a1 open
SYSML2_-42 Transformation does not cover UML4SysML::GeneralizationSet SysML 2.0a1 open
SYSML2-87 Add standard domain libraries for mathematical and physical constants SysML 2.0a1 open
SYSML2-86 Add capability to specify accuracy, uncertainty or tolerance for numerical values SysML 2.0a1 open
SYSML2-90 Redefining feature information missing from specification document SysML 2.0a1 open
SYSML2-91 XMI and JSON for model libraries SysML 2.0a1 open
SYSML2-96 Incorrect action name in graphical notation example SysML 2.0a1 open
SYSML2_-35 Add standard domain libraries for mathematical and physical constants SysML 2.0a1 open
SYSML2_-34 Add capability to specify accuracy, uncertainty or tolerance for numerical values SysML 2.0a1 open
SYSML2_-36 Redefining feature information missing from specification document SysML 2.0a1 open
SYSML2_-37 XMI and JSON for model libraries SysML 2.0a1 open
SYSML2_-38 Incorrect action name in graphical notation example SysML 2.0a1 open
SYSML2-77 Resolve "TODO" in domain library model Time SysML 2.0a1 open
SYSML2-82 Extend ISQ with missing quantity and unit types for US Customary Units SysML 2.0a1 open
SYSML2-71 Graphical BNF for grid rendering is missing SysML 2.0a1 open
SYSML2-70 Graphical notation for variant inheritance from variation requires improvement SysML 2.0a1 open
SYSML2_-31 Graphical BNF for grid rendering is missing SysML 2.0a1 open
SYSML2_-32 Resolve "TODO" in domain library model Time SysML 2.0a1 open
SYSML2_-33 Extend ISQ with missing quantity and unit types for US Customary Units SysML 2.0a1 open
SYSML2-61 Special graphical notation for distinguished parameters in name compartment SysML 2.0a1 open
SYSML2-64 Missing graphical notation for Flows Compartment SysML 2.0a1 open
SYSML2-60 Source and target on binary ConnectionDefinition symbol missing SysML 2.0a1 open
SYSML2-67 Graphical BNF mapping to abstract syntax is missing SysML 2.0a1 open
SYSML2-65 Graphical BNF defines lifeline elements incorrectly SysML 2.0a1 open
SYSML2_-26 Special graphical notation for distinguished parameters in name compartment SysML 2.0a1 open
SYSML2_-28 Graphical BNF defines lifeline elements incorrectly SysML 2.0a1 open
SYSML2-57 Port symbol notation (arrows) needs improvement SysML 2.0a1 open
SYSML2-53 Parameter symbol notation needs improvement SysML 2.0a1 open
SYSML2-56 Missing graphical notation for n-ary connection def and usage SysML 2.0a1 open
SYSML2-55 Quantity and unit for ratio and fraction SysML 2.0a1 open
SYSML2_-21 Parameter symbol notation needs improvement SysML 2.0a1 open
SYSML2_-24 Port symbol notation (arrows) needs improvement SysML 2.0a1 open
SYSML2_-22 Quantity and unit for ratio and fraction SysML 2.0a1 open
SYSML2-51 Loop examples incomplete in representative notation table SysML 2.0a1 open
SYSML2-49 Specification of standard geometric view missing SysML 2.0a1 open
SYSML2-48 Consider production for standard case view vs filtered general view SysML 2.0a1 open
SYSML2-50 No support for metadata in graphical notation SysML 2.0a1 open
SYSML2-41 Graphical BNF production proxy refers to wrong label SysML 2.0a1 open
SYSML2-52 Examples requirement derivation, cause effect, and refinement missing SysML 2.0a1 open
SYSML2_-20 Examples requirement derivation, cause effect, and refinement missing SysML 2.0a1 open
SYSML2_-17 Specification of standard geometric view missing SysML 2.0a1 open
SYSML2_-19 Loop examples incomplete in representative notation table SysML 2.0a1 open
SYSML2_-16 Consider production for standard case view vs filtered general view SysML 2.0a1 open
SYSML2-37 Identify the owning context in a graphical view SysML 2.0a1 open
SYSML2-40 Graphical BNF production sq-ev-occurrence has inconsistent proxy notation SysML 2.0a1 open
SYSML2-36 Regularization of textual notation for loops SysML 2.0a1 open
SYSML2_-12 Regularization of textual notation for loops SysML 2.0a1 open
SYSML2_-13 Identify the owning context in a graphical view SysML 2.0a1 open
SYSML2-33 Identify impact views on model organization SysML 2.0a1 open
SYSML2-32 Clarify query using view SysML 2.0a1 open
SYSML2-34 Missing graphical notation allocating flow to connection SysML 2.0a1 open
SYSML2-35 Missing explicit explanation of compartments as views SysML 2.0a1 open
SYSML2-31 Icons for standard view definitions missing SysML 2.0a1 open
SYSML2_-7 Icons for standard view definitions missing SysML 2.0a1 open
SYSML2_-9 Identify impact views on model organization SysML 2.0a1 open
SYSML2_-10 Missing graphical notation allocating flow to connection SysML 2.0a1 open
SYSML2_-8 Clarify query using view SysML 2.0a1 open
SYSML2-17 Incomplete description of TestCaseVerifyObjectiveMembership_Mapping SysML 2.0a1 open
SYSML2-25 Standard view filters incomplete SysML 2.0a1 open
SYSML2-18 Mapping of UML4SysML::RemoveVariableValueAction::isRemoveDuplicates is not covered SysML 2.0a1 open
SYSML2_-6 Standard view filters incomplete SysML 2.0a1 open
SYSML2_-5 Mapping of UML4SysML::RemoveVariableValueAction::isRemoveDuplicates is not covered SysML 2.0a1 open
KERML-245 KerML should have syntax for enumerations SysML 2.0b1 open
KERML_-53 KerML should have syntax for enumerations SysML 2.0b1 open
SYSML2-5 UntypedPin_Mapping::filter: property src should be from SysML 2.0a1 open
SYSML2-7 Pin_Mapping::filter: property src should be from SysML 2.0a1 open
SYSML2-1 "Elements not mapped" table sections are empty SysML 2.0a1 open
SYSML2-75 Spatial links can be occurrences SysML 2.0a1 open
SYSML2-69 Inefficient graphical notation specification tooling SysML 2.0a1 open
SYSML2-54 Error in InterfaceUsage semantics subclause SysML 2.0a1 open
SYSML2-78 The .project.json file for the Cause and Effect Domain Library is misnamed SysML 2.0a1 open
SYSML2-26 Standard view filters incomplete SysML 2.0a1 open
SYSML2-81 Association end name " /usageWithDirectedUsage" has a typo SysML 2.0a1 open
SYSML2-153 Error in assert constraint example SysML 2.0a1 open
SYSML2-92 Packages can also have compartments SysML 2.0a1 open
SYSML2-156 Errors in textual BNF for RequirementDefinition and ConcernDefinition SysML 2.0a1 open
SYSML2-23 Transformation of UML4SysML::AddStructuralFeatureValueAction is not correct SysML 2.0a1 open
SYSML2-103 Editoral corrections in 7.16.11 SysML 2.0a1 open
SYSML2-2 ItemFlowEnds of ObjectFlow transformation target are not defined correctly SysML 2.0a1 open
SYSML2-14 UML4SysML::ClearVariableAction transformation does not include a ReturnParameter SysML 2.0a1 open
SYSML2-4 Transformation of UML4SysML::AddVariableValueAction is not correct SysML 2.0a1 open
SYSML2-16 Subsections for mapping classes in section 7.7.2.3.9 should be ordered alphabetically SysML 2.0a1 open
SYSML2-173 Mapping of ValueSpecificationActions does not work for untyped pins SysML 2.0a1 open
SYSML2-19 REAOutputPin_Mapping should specialize OutputPin_Mapping SysML 2.0a1 open
SYSML2-88 Mapping of allocation between usage elements is not specified yet SysML 2.0a1 open
SYSML2-171 Optimize Pin mapping class generalization hierarchy SysML 2.0a1 open
SYSML2-200 Description of Subsetting mapping classes is not correct SysML 2.0a1 open
SYSML2-189 ControlFlowSuccessionAsUsage_Mapping uses non existing mapping class ActivityEdgeInitialNodeSourceEndFeatureMembership_Mapping SysML 2.0a1 open
SYSML2-178 ClassifierBehaviorFeatureMembership_Mapping does not exist SysML 2.0a1 open
SYSML2-174 EmptyReturnParameterFeatureMembership_Mapping does not exist SysML 2.0a1 open
SYSML2-195 GenericToEndFeatureMembership_Mapping::to property redefines itself SysML 2.0a1 open
SYSML2-193 ControlFlowSuccessionAsUsage_Mapping uses non existing mapping class SysML 2.0a1 open
SYSML2-215 ControlFlow transformation target ends are not defined correctly SysML 2.0a1 open
SYSML2-208 A ConnectionUsage should be owned by a FeatureMembership relationship SysML 2.0a1 open
SYSML2-197 ControlFlow target SuccessionAsUsage should have end feature with reference subsetting SysML 2.0a1 open
SYSML2-211 Introduce GenericToTransitionUsage_Mapping class SysML 2.0a1 open
SYSML2-204 Mapping of SysMLv1::ItemFlow does not consider the itemProperty SysML 2.0a1 open
SYSML2-202 Filter for mapping class Behavior_Mapping is useless SysML 2.0a1 open
SYSML2-43 Graphical BNF sq-message reference incorrect SysML 2.0a1 open
SYSML2-42 Textual production for sq-proxy-label incorrect SysML 2.0a1 open
SYSML2-213 Typo in section 7.6.3 and section 7.6.4: mappingsto SysML 2.0a1 open
SYSML2-39 Graphical BNF production sq-part refers to wrong port SysML 2.0a1 open
SYSML2-45 Graphical BNF interconnection view production incorrect SysML 2.0a1 open
SYSML2-155 Limitation on specifying view renderings SysML 2.0a1 open
SYSML2-62 Incorrect production for attributes-compartment-element SysML 2.0a1 open
SYSML2-44 Graphical BNF sq-message-label usage incorrect SysML 2.0a1 open
SYSML2-84 Connection declaration does not allow a feature value SysML 2.0a1 open
SYSML2-46 Graphical BNF flow-label and interface-label productions missing SysML 2.0a1 open
SYSML2-224 Number missing from table listing Standard View Definitions SysML 2.0a1 open
SYSML2-255 Error in textual BNF for MessageDeclaration SysML 2.0a1 open
SYSML2-223 Table 38 "Standard View Definitions" redundant SysML 2.0a1 open
SYSML2-291 Case View is not a standard view SysML 2.0a1 open
SYSML2-261 Error in textual BNF for TargetSuccession SysML 2.0a1 open
SYSML2-181 Mapping of SysMLv1::ItemFlow does not consider the itemProperty SysML 2.0a1 open
SYSML2-206 Mapping of UML4SysML::InformationFlow with a realizing connector is not supported SysML 2.0a1 open
SYSML2-180 Mapping of UML4SysML::InformationFlow between definition elements is not supported SysML 2.0a1 open
SYSML2-228 Helpers::activityOwnedRelationships mixes up FinalNodes and FlowFinalNodes SysML 2.0a1 open
SYSML2-232 TIAOperatorExpression_Mapping uses non-existing mapping class EqualOperatorExpressionOperand_Mapping SysML 2.0a1 open
SYSML2-234 RSFAReferenceUsageFeatureMembership_Mapping uses non-existing mapping class SysML 2.0a1 open
SYSML2-236 Resolution of approved issue SYSML2-23 uses outdated mapping classes SysML 2.0a1 open
SYSML2-244 RVVAVariable_Mapping uses CommonAssignmentActionOwningMembership_Mapping, but should be a factory class SysML 2.0a1 open
SYSML2-238 ObjectFlows targeting a final node or a activity parameter node cannot be mapped SysML 2.0a1 open
SYSML2-240 TestCaseActivity_Mapping uses non-existing mapping classes SysML 2.0a1 open
SYSML2-229 ControlFlowSuccessionAsUsage_Mapping uses non-existing mapping class SysML 2.0a1 open
SYSML2-248 CreateLinkObjectAction_Mapping should specialize CreateLinkAction_Mapping SysML 2.0a1 open
SYSML2-258 Mapping of allcation between usage and definition or definition and usage elements does not work SysML 2.0a1 open
SYSML2-246 AEAParameterMembership_Mapping::ownedMemberParameter cannot return OclUndefined SysML 2.0a1 open
SYSML2-281 Map OpqueBehavior always to ActionDefinition SysML 2.0a1 open
SYSML2-250 Typo in AEAReceiverFeatureValue_Mapping::value() SysML 2.0a1 open
SYSML2-304 Mapping of ActivityEdge does not consider ActivityParameterNodes SysML 2.0b1 open
SYSML2-278 UntypedPin_Mapping redefines operation without any changes SysML 2.0a1 open
SYSML2-157 Incorrect font in descriptions of AttributeUsage and TransitionUsage SysML 2.0a1 open
SYSML2-221 UML4SysML::Activities and StateMachines owned by blocks should be mapped to definition elements SysML 2.0a1 open
SYSML2-312 Typo: Table 19 - requirres SysML 2.0b1 open
SYSML2-47 Graphical BNF productions missing for connections SysML 2.0a1 open
SYSML2-328 Incorrect private keyword notation SysML 2.0b1 open
SYSML2-322 Nesting parameter symbols should use rounded rectangles SysML 2.0b1 open
SYSML2-330 Incorrect entry name representative notation SysML 2.0b1 open
SYSML2-287 sq-port-label and sq-ev-occurrence-label productions use Usage SysML 2.0a1 open
SYSML2-319 Wrong line style on action flow succession SysML 2.0b1 open
SYSML2-321 Nesting port symbols should use rounded rectangles SysML 2.0a1 open
SYSML2-335 Incorrect keyword in example "Attributes Compartment" SysML 2.0b1 open
SYSML2-334 Incorrect example "Relationships Compartment" SysML 2.0b1 open
SYSML2-339 Unnecessarily complicated examples "Timeslices Compartment" and "Snapshots Compartment" SysML 2.0b1 open
SYSML2-338 Incomplete example "Occurrences Compartment" SysML 2.0b1 open
SYSML2-332 Incorrect example "Variant Membership" SysML 2.0b1 open
SYSML2-341 Compartments still show nested feature notation SysML 2.0b1 open
SYSML2-344 Missing «perform action» in example "Part with Graphical Compartment with perform actions ..." SysML 2.0b1 open
SYSML2-340 Examples "Timeslices Compartment" and "Snapshots Compartment" incorrectly declare state feature SysML 2.0b1 open
SYSML2-342 Misleading port name in example "Part with Ports" SysML 2.0b1 open
SYSML2-347 Wrong reference usage notation SysML 2.0b1 open
SYSML2-345 Incorrect inherited notation in example "Connection" SysML 2.0b1 open
SYSML2-325 Wrong compartment name: documentation SysML 2.0b1 open
SYSML2-93 Keyword for documentation is "doc" SysML 2.0a1 open
SYSML2-348 Incorrect item flow notation in example "Message" SysML 2.0b1 open
SYSML2-190 The description and derivation of ForLoopActionUsage::seqArgument is wrong SysML 2.0a1 open
SYSML2-99 Incorrect notation in action examples SysML 2.0a1 open
SYSML2-101 Time triggers are relative to "localClock", not "defaultClock" SysML 2.0a1 open
SYSML2-300 validateDefinitionNonVariationMembership and validateUsageNonVariationMembership are redundant with validateVariantMembershipOwningNamespace SysML 2.0b1 open
SYSML2-218 Errors in TransitionUsage semantic constraints SysML 2.0a1 open
SYSML2-298 validateDefinitionVariationMembership and validateUsageVariationMembership are too strict SysML 2.0b1 open
SYSML2-296 validateFramedConcernUsageConstraintKind constraint is misnamed SysML 2.0b1 open
SYSML2-254 Redundant numbered list in language description of usage SysML 2.0a1 open
SYSML2-191 deriveForLoopActionUsageBodyAction is misnamed SysML 2.0a1 open
SYSML2-302 validateOccurrenceUsageIndividualDefinition OCL is wrong SysML 2.0b1 open
SYSML2-301 validateUsageOwningType constraint is too restrictive SysML 2.0b1 open
SYSML2-356 The OCL for the body of ConstraintUsage::namingFeature is incorrect SysML 2.0b1 open
SYSML2-306 validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization constraints are too restrictive SysML 2.0b1 open
SYSML2-303 validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization OCL is wrong SysML 2.0b1 open
SYSML2-414 checkTransitionUsageSourceBindingConnector text and OCL are different SysML 2.0b1 open
SYSML2-398 TransitionUsage effectAction attribute text and constraint are different SysML 2.0a1 open
SYSML2-424 WhileLoopsActionusage title typos SysML 2.0b1 open
SYSML2-423 checkIfActionUsageSpecialization OCL specifiesFromLibrary typo SysML 2.0b1 open
SYSML2-66 Graphical BNF for n-ary connections missing SysML 2.0a1 open
SYSML2-418 Description of TimeEvent_Mapping is a note SysML 2.0b1 open
SYSML2-437 The transformation specification does not explicitly specify how to map a ValueType SysML 2.0b1 open
SYSML2-416 Description of ChangeEvent_Mapping is a note SysML 2.0b1 open
SYSML2-420 InformationFlow mapping classes should use GenericTo mapping classes SysML 2.0b1 open
SYSML2-432 Part properties with AggregationKind::none or shared are not mapped to PartUsage with isComposite=false SysML 2.0b1 open
SYSML2-446 Document how SysML v1 properties are mapped to SysML v2 SysML 2.0b1 open
SYSML2-299 validateDefinitionVariationSpecialization and validateUsageVariationSpecialization OCL is wrong SysML 2.0b1 open
SYSML2-443 Property_Mapping should map to ItemUsage and the class name is misleading SysML 2.0b1 open
SYSML2-441 Change the table header of the overview tables in the mapping class specification chapters SysML 2.0b1 open
SYSML2-439 UML4SysML::Class should be mapped to ItemDefinition SysML 2.0b1 open
SYSML2-252 Graphical BNF opaque "text block" productions SysML 2.0a1 open
SYSML2-425 LoopActionUsage descriptions refer to property not in metamodel SysML 2.0b1 open
SYSML2-343 Mistake in example "Part performs a reference action (action1) that references ..." SysML 2.0b1 open
SYSML2-63 Various incorrect Graphical BNF productions SysML 2.0a1 open
SYSML2-331 Incomplete textual notation in example "Subsetting" SysML 2.0b1 open
SYSML2-139 Transformation does not cover SysMLv1::~InterfaceBlock SysML 2.0a1 open
SYSML2-58 Representative notation table uses deprecated «equal» SysML 2.0a1 open
SYSML2-21 RSAOutputPin_Mapping should specialize OutputPin_Mapping SysML 2.0a1 open
SYSML2-95 Flows Compartment example graphical notation missing SysML 2.0a1 open
SYSML2-280 ElementMain_Mapping::ownedRelationship is wrong SysML 2.0a1 open
SYSML2-422 GenericToItemDefinition_Mapping should specialize GenericToOccurrenceDefinition_Mapping SysML 2.0b1 open
SYSML2-346 Incorrect notation in example "Binding Connection" SysML 2.0b1 open
SYSML2-349 Incorrect item flow notation in example "Interface as Node" SysML 2.0b1 open
SYSML2-333 Incomplete textual notation in example "Variants Compartment" SysML 2.0b1 open
SYSML2-350 Incomplete flow notation in example "Flow as Node" SysML 2.0b1 open
SYSML2-412 SYSML2-180 uses non-existing general mapping class GenericToItemUsage_Mapping SysML 2.0b1 open
SYSML2-453 Text error in List property construction SysML 2.0b1 open
SYSML2-451 Missing production for ConjugatePortTyping SysML 2.0b1 open
SYSML2-452 misspelled ConjugatePortTyping should be ConjugatedPortTyping SysML 2.0b1 open
SYSML2-431 Incorrect EBNF specification SysML 2.0b1 open
SYSML2-454 PrefixComment should not be a production for AnnotatingElement SysML 2.0b1 open
SYSML2-79 View::viewpointSatisfactions should subset viewpointChecks and checkedConstraints SysML 2.0a1 open
SYSML2-467 RequirementConstraintUsage should not have a RequirementBody SysML 2.0b1 open
SYSML2-513 Missing text in some main mapping sections SysML 2.0b1 open
SYSML2-241 TestCaseVerifyRequirementUsage_Mapping uses non-existing mapping classes SysML 2.0a1 open
SYSML2-511 Remove sentence in StateMachines overview section SysML 2.0b1 open
SYSML2-509 Remove sentence in Classification overview section SysML 2.0b1 open
SYSML2-83 Narrow down return types of SpatialItem::PositionOf and ::CurrentPositionOf SysML 2.0a1 open
SYSML2-295 Causation end features need to redefine source and target SysML 2.0a1 open
SYSML2-488 Constraints missing to enforce variations being abstract SysML 2.0b1 open
SYSML2-393 Documentation of Time::defaultClock is missing SysML 2.0b1 open
SYSML2-378 Sample::calculation has an incorrect type SysML 2.0b1 open
SYSML2-253 Additional cases when usages are required to be referential SysML 2.0a1 open
SYSML2-490 Actions::acceptSubactions and sendSubactions should subset acceptActions and sendActions SysML 2.0b1 open
SYSML2-28 Validation constraints are missing in the SysML abstract syntax SysML 2.0a1 open
SYSML2-500 The derivation of AssignmentActionUsage::referent is wrong SysML 2.0b1 open
SYSML2-305 Message and flow connection ends should be occurrence usages SysML 2.0b1 open
SYSML2-497 validateTriggerInvocationExpressionAfterArgument constraint is too strong SysML 2.0b1 open
SYSML2-491 KerML constraint requires updates to Systems Library models SysML 2.0b1 open
SYSML2-468 binding connector production overly constraining SysML 2.0a1 open
SYSML2-498 validateTriggerInvocationExpressionWhenArgument constraint is wrong SysML 2.0b1 open
SYSML2-458 Missing production for connections with an edge on one or both ends SysML 2.0a1 open
SYSML2-492 KerML constraint requires updates to Domain Library models SysML 2.0a1 open
SYSML2-457 Missing graphical BNF production for keyword extension using #key word in guillemet in compartments SysML 2.0a1 open
SYSML2-68 Graphical notation for nested reference usage needs resolution SysML 2.0a1 open
SYSML2-495 Textual notation BNF for TriggerExpression is wrong SysML 2.0b1 open
SYSML2-94 Confusing naming in Individual Occurrence example SysML 2.0a1 open
SYSML2-102 Semantic constraint for target of AssignmentActionUsage is missing SysML 2.0a1 open
SYSML2-80 Reflective SysML abstract syntax model has inconsistencies SysML 2.0a1 open
SYSML2-227 Subsections of section 7.7.2.3.7 should be ordered alphabetically SysML 2.0a1 open
SYSML2-38 Textual and graphical notations for flow on connection unclear SysML 2.0a1 open
SYSML2-336 Incorrect notation in example "Individual Occurrence" SysML 2.0b1 open
SYSML2-499 Assignments parsed without a target will fail validateAssignmentActionUsageArguments SysML 2.0b1 open
SYSML2-351 Unnecessary event declaration in example "Message" SysML 2.0b1 open
SYSML2-459 Resolution of approved issue SYSML2-241 is not considered by merged issue SYSML2-240 SysML 2.0b1 open
SYSML2-556 Typos in Quantities and Units Domain Library SysML 2.0b1 open
SYSML2-481 Use of the term 'Feature' SysML 2.0b1 open
SYSML2-536 TestCaseVerifyRequirementUsage_Mapping.ownedRelationship() SysML 2.0a1 open
SYSML2-578 Incorrect graphical notation for message between ports SysML 2.0b1 open
SYSML2-560 Add note on FlowFeature direction to textual notation grammar SysML 2.0b1 open
SYSML2-566 Section containing tables about elements not mapped should get an introductory text SysML 2.0b1 open
SYSML2-577 Incorrect graphical notation for flow connection SysML 2.0b1 open
SYSML2-582 Incorrect graphical notation for flow between actions SysML 2.0b1 open
SYSML2-579 Incorrect graphical notation for flow connections in Flow as Node SysML 2.0b1 open
SYSML2-583 Incorrect graphical notation for successions examples with actions SysML 2.0b1 open
SYSML2-581 Mistakes in example Interface as Node (with flow) SysML 2.0b1 open
SYSML2-611 OCL rule deriveDefinitionOwnedFlow references non-existent class called FlowUsage SysML 2.0b1 open
SYSML2-580 Incorrect and incomplete sequence view with message SysML 2.0b1 open
SYSML2-612 OCL rule deriveUsageNestedFlow references non-existent class called FlowUsage SysML 2.0b1 open
SYSML2-620 Textual notation production for Comment is wrong SysML 2.0b1 open
SYSML2-226 Incorrect reference to SysML v1 to SysML v2 Transformation SysML 2.0a1 open
SYSML2-616 User-defined keywords are not allowed on control nodes SysML 2.0b1 open
SYSML2-219 Action::decisionTransitions should subset Action::transitions SysML 2.0a1 open
SYSML2-599 Wrong production for adding state-def as a definition node SysML 2.0a1 open
SYSML2-558 checkStateUsageSpecialization constraint is incorrect SysML 2.0b1 open
SYSML2-529 OCL for deriveViewDefinitionViewCondition and deriveViewUsageViewCondition are wrong SysML 2.0b1 open
SYSML2-597 checkFlowConnectionUsageSpecialization is too restrictive about FlowConnections SysML 2.0b1 open
SYSML2-552 Errors in the TradeStudy domain model SysML 2.0b1 open
SYSML2-182 Universal features can have many values SysML 2.0a1 open
SYSML2-430 Subsetting of subjectParameter properties is wrong SysML 2.0b1 open
SYSML2-318 Adornments on ends missing in graphical syntax SysML 2.0b1 open
SYSML2-554 Enumeration definitions VerdictKind and VerificationMethodKind are missing from specification document SysML 2.0b1 open
SYSML2-29 Name all associations in the SysML abstract syntax SysML 2.0a1 open
SYSML2-30 Follow typographical conventions in the SysML Metamodel clause SysML 2.0a1 open
SYSML2-158 Example FrontAxle definition SysML 2.0a1 open
SYSML2-159 Example analysis case fuelEconomyAnalysis SysML 2.0a1 open
SYSML2-426 specializesFromLibrary arguments use inconsistent notation for strings SysML 2.0b1 open
SYSML2-626 Incorrect textual notation for TextualRepresentation SysML 2.0b1 open
SYSML2-484 Incorrect textual notation for rep annotation SysML 2.0a1 open
SYSML2-527 The XMI versions of standard libraries should be delivered SysML 2.0a1 open
SYSML2-561 Intersection missing for some multiple specializations SysML 2.0b1 open
SYSML2-562 Tables in overview sections have empty cells SysML v2 column SysML 2.0b1 open
SYSML2-564 Mapping tables in the overview sections show duplicates in the SysML v2 column SysML 2.0b1 open
SYSML2-569 Rename ~InterfaceBlock_Mapping SysML 2.0b1 open
SYSML2-587 The mapping name "~InterfaceBlock_Mapping" is not convenient SysML 2.0a1 open
SYSML2-613 Constraint on Definition variation memberships is too restrictive SysML 2.0b1 open
SYSML2-615 Constraint on Usage variation memberships is too restrictive SysML 2.0b1 open
SYSML2-640 Find a better way to differ between definition and instance elements in graphical notation SysML 2.0b1 open
SYSML2-636 package View and Viewpoint TBD should not be included in the xmi file SysML 2.0b1 open
SYSML2-634 VerificationCase::subVerificationCases is typed incorrectly SysML 2.0b1 open
SYSML2-641 Do not use abbreviations for key word in SysML v2/KerML textual concrete syntax SysML 2.0b1 open
SYSML2-844 Annotation diagram needs to be updated SysML 2.0b1 open
SYSML2-631 User-defined keywords are not allowed on metadata SysML 2.0b1 open
SYSML2-642 Make orthogonal and rounded corners the default connector style for architectural drawings SysML 2.0b1 open
SYSML2-185 ISQ in specification and libraries not aligned SysML 2.0a1 open
SYSML2-85 Effective name is not correct for a redefined perform action usage SysML 2.0a1 open
SYSML2-635 Issues with SysML grammar SysML 2.0b1 open
SYSML2-553 checkRequirementUsageObjectiveRedefinition is incorrect SysML 2.0b1 open
SYSML2-783 Parsing KerML Feature elements from SysML textual notation SysML 2.0b1 open
SYSML2-637 User-defined keywords are not allowed on enumeration definitions SysML 2.0b1 open
SYSML2-643 Comment locale not in textual notation SysML 2.0b1 open
SYSML2-59 Inconsistent graphical notation for succession, message and flow edges SysML 2.0a1 open
SYSML17-649 Metadata - category refers to DCMI abstract (not a category) / dublinCoreTag. Dublin Core Should Only Apply to Artefacts (Documents, Sound, Video, Text) Not any AD Element SysML 1.5 open
SYSML17-648 Metadata, ArchitectureMetadata Incorrect - Metadata Applies to Architecture Description Not Architecture. ArchitectureMetadata duplicates Metadata in application to an AD SysML 1.5 open
SYSML17-647 View Specifications::Summary & Overview::Summary & Overview - Missing Relationships and Triples, Concerns Not Defined SysML 1.5 open
SYSML17-646 UAFElement - Attributes Missing. URI incorrectly defined SysML 1.5 open
SYSML17-645 Figure 9:134 / 8:86 Undefined DMM Elements - Refine, Trace, Refine, Verifiy, Requirement. Requirement not a UAF Element? SysML 1.5 open
SYSML17-644 Figure 9:129 ArchitecturalDescription - Multiplicities Incorrect SysML 1.5 open
SYSML17-643 Figure 8:2 Architecture Views Does Not Conform to ISO/IEC/IEEE 42010 - Multiplicities, Naming, Direction [repeat - Tracker Now Using Correct OMG Identifiers] SysML 1.5 open
SYSML17-642 Figure 8:2 Architecture Views Does Not Conform to ISO/IEC/IEEE 42010 - Multiplicities, Naming, Direction SysML 1.5 open
SYSML17-641 1.1 Introduction - Normative + Informative Identifies Wrong OMG Specifications SysML 1.5 open
SYSML17-640 Typo in brief description about Activity Diagram SysML 1.6 open
SYSML17-639 Element Name Incorrectly Shown as InternalBlockDiagram - Should be Dependency SysML 1.6 open
SYSML17-636 Conform as a Generalization is Incorrect - A View is Not a Viewpoint / 'is a' Does Not Equate to Conform SysML 1.5 open
SYSML17-637 View is not a Viewpoint SysML 1.5 open
SYSML17-500 Artifacts and «document» SysML 1.6 open
SYSML17-638 UML::Artifact is Excluded But Specification Doesn't State With What Documents/Artifacts Are to Be Represented with Instead SysML 1.7b1 open
SYSML17-635 Risk, Source and Verification Method Are Attributes of Any / All Requirements Not Just an Extended Requirement SysML 1.5 open
SYSML17-634 Issues with SysML 1.7 XMI SysML 1.6 open
SYSML17-536 Typo: Constraint name 8 of Adjunct Property (again) SysML 1.6 open
SYSML17-515 Statement about UML semantics of ActivityPartitions is wrong SysML 1.6 open
SYSML17-494 wrong statement about UML semantics of partitions SysML 1.6 open
SYSML17-463 QUDV: Specification of PrefixedUnit should have a QuantityKind SysML 1.6 open
SYSML17-512 Added BehavioralFeatures to AdjuctProperty SysML 1.6 open
SYSML17-365 Meta-ticket: SysML-1.6: Specification body (only) figure inconsistencies and errors and related text inconsistencies SysML 1.6 open
SYSML17-252 ConstraintBlock: abstract syntax consistency SysML 1.6 open
SYSML17-507 wrong name on Figure 9-6 SysML 1.6 open
SYSML17-504 Why are FlowProperties not included in FlowDirectionKind SysML 1.6 open
SYSML17-505 The FeatureDirectionKind to which the constraint belongs is wrong SysML 1.6 open
SYSML17-502 FlowProperties as aggregations SysML 1.6 open
SYSML17-498 NoBuffer: Clarify when a token is considered "refused" SysML 1.6 open
SYSML17-233 Comments in the XMI have no annotated elements SysML 1.6b1 open
SYSML17-265 Stereotype Rate extends ObjectNode in the XMI, but not in the abstract syntax in the specification SysML 1.6 open
SYSML17-490 no longer existing "primaryQuantityKind" shown in diagram E.8 SysML 1.6 open
SYSML17-489 Removes references to UML4SYSML from the SysML diagrams SysML 1.6 open
SYSML17-485 Mentioned stereotype «distributedDefinition» does not exist SysML 1.6 open
SYSML17-488 FinalState should be an exitPoint Pseudostate SysML 1.6 open
SYSML17-487 connector properties should be in compartment SysML 1.6 open
SYSML17-486 Behavioral Ports and Nesting SysML 1.6 open
SYSML17-483 DistributedProperty definition has to be reveiwed SysML 1.6 open
SYSML17-482 The circle plus notation is for members, not ownedElements SysML 1.6 open
SYSML17-481 Consistency with Effects and Ports SysML 1.6 open
SYSML17-479 Association Rules SysML 1.6 open
SYSML17-227 About Block constraint "3" removed by SysML v1.6 SysML 1.6 open
SYSML17-480 Problems with Flows SysML 1.6 open
SYSML17-478 AcceptChangeStructuralFeatureEventAction SysML 1.6 open
SYSML17-467 Implementation of non-normative extensions cannot be used in other OMG specifications SysML 1.6 open
SYSML17-475 move to SystemOfQuantities SysML 1.6 open
SYSML17-474 rename getKindOfQuantitiesForMeasurementUnit SysML 1.6 open
SYSML17-473 OCL is not syntatically correct see ->allUnits() SysML 1.6 open
SYSML17-472 wrongfully copied SysML 1.6 open
SYSML17-471 OCL with SpecializedQuantityKind needs to be changed SysML 1.6 open
SYSML17-469 ControlValue to ControlValueKind SysML 1.6 open
SYSML17-468 Changes to Annex D sample problem figures may impact on some specification body figures SysML 1.6 open
SYSML17-366 Need constraint for inverted provided/required Interfaces (InterfaceRealization and Usage) on ~InterfaceBlock SysML 1.6 open
SYSML17-464 Constraint Typos SysML 1.6 open
SYSML17-454 QUDV: Unknown property primaryQuantityKind SysML 1.6 open
SYSML17-462 SysML model URI in the specification document SysML 1.6 open
SYSML17-455 Suggest capability to list :features on Pin symbols and on elided Pin "ObjectNode" rectangle symbol SysML 1.6 open
SYSML17-456 Suggest capability to list :features on ItemFlows in a rectangle symbol over a Connector or Association line SysML 1.6 open
SYSML17-357 Suggest introduce strict diagram policy: avoid "elided Pin" ObjectNode notation in Activity Diagrams in all revised and future specification figures SysML 1.6 open
SYSML17-438 Body conditions of operation in QUDV model should be Boolean expressions SysML 1.6 open
SYSML17-437 QUDV::PrefixedUnit: Redefinition of quantityKind SysML 1.6 open
SYSML17-430 Issues in figure E-7 SysML 1.6 open
SYSML17-414 7_composition_acyclic wrong SysML 1.6 open
SYSML17-351 If there is no «port» keyword in UML-2.5.1 or SysML-1.6 it should be removed from Figure 9-8 SysML 1.6 open
SYSML17-408 orderedMember in ElementGroup should be {ordered} SysML 1.6 open
SYSML17-406 AbstractRequirement needs to be consistent SysML 1.6 open
SYSML17-405 Description for getSatisfies SysML 1.6 open
SYSML17-404 Parameter names mismatch in ~InterfaceBlock::areConjugated(Property, Property) SysML 1.6 open
SYSML17-401 Suggest introduce an operation to obtain the magnitude of a value property in a given compatible Unit (to afford equality comparison) SysML 1.6 open
SYSML17-399 Taken literally the text and OCL of constraint '6_valueproperties_composite' imply that every FlowProperty typed by a ValueType should have AggregationKind 'composite' SysML 1.6 open
SYSML17-400 Property types 'Four general categories of properties of blocks are recognized in SysML ...' does not cover FlowProperty SysML 1.6 open
SYSML17-367 InterfaceBlock: OCL constraint 2_no_part is missing FlowProperty check for cases where a FlowProperty is not typed by a ValueType SysML 1.6 open
SYSML17-395 Compartments for Connectors and Participants SysML 1.6 open
SYSML17-394 Suggest not allow an AssociationBlock to type a BindingConnector used for pure proxying SysML 1.6 open
SYSML17-386 All kinds of errors in Fig. 8-17 SysML 1.6 open
SYSML17-348 Figure 8-17: Vehicle specialization: multiple inconsistencies SysML 1.6 open
SYSML17-388 constraint needed SysML 1.6 open
SYSML17-393 Relationship should be specified for Stakeholder to a View SysML 1.6 open
SYSML17-392 Adjunct allows for additional notation on CallBehaviorActions SysML 1.6 open
SYSML17-391 What are redefined BoundReferences SysML 1.6 open
SYSML17-390 EndPathMultiplicity and BoundReference Ordered and Unique SysML 1.6 open
SYSML17-389 Lower and Upper Explained SysML 1.6 open
SYSML17-387 Lower and Upper are constrained SysML 1.6 open
SYSML17-385 Statement about EndPathMultiplicity SysML 1.6 open
SYSML17-384 BoundReference Specificity SysML 1.6 open
SYSML17-383 BoundReference Diagram is wrong SysML 1.6 open
SYSML17-382 Unclear English Statement SysML 1.6 open
SYSML17-377 Make Annex E Optional but Normative SysML 1.6 open
SYSML17-372 Figure E.6 QUDV Units Diagram display exactly the same content as Figure E.5 QUDV Concepts Diagram SysML 1.6 open
SYSML17-347 The 'initialValues' compartment needs to be renamed 'contextValues' and they need to be referred to as 'context-specific values' SysML 1.6 open
SYSML17-371 Suggest primary/replica as alternative to master/slave terminology for Copy relationship SysML 1.6 open
SYSML17-370 SysML-1.6: Refers to both 'composite requirement' and 'compound requirement' SysML 1.6 open
SYSML17-369 BindingConnector constraint 1_compatible_types: Use of OCL conformsTo contradicts definition of compatibility of connected ProxyPort, does not admit per Feature compatibility or compatibility via a union of connected features SysML 1.6 open
SYSML17-368 9.3.2.13 ProxyPort 'When a proxy port is connected to a single internal part ...' extend to include ' or port on an internal part' SysML 1.6 open
SYSML17-361 SysML-1.6: text on Requirement 'Test and procedure conditions' is mangled in 'Figure 16-2: Requirements Derivation' (was OK in SysML-1.5) [also affects Figure 16-6] SysML 1.6 open
SYSML17-362 'Figure 16-2: Requirements Derivation' indeed shows DeriveReqt but spec text refers to it as 'an example of a compound requirement' SysML 1.6 open
SYSML17-349 'Figure 9-6: Usage example of ports with provided and required features' does not expose any directed features SysML 1.6 open
SYSML17-350 SysML-1.6 does not leverage redefinition of 'sp:Surface' on 'Figure 9-7: Usage example of proxy and full ports'. And does not show direction of flows on Ports symbols SysML 1.6 open
SYSML17-352 Figure 9-16 and Figure 9-17 'Usage example of item flow decomposition': multiple inconsistencies SysML 1.6 open
SYSML17-353 The ControlValue input to Monitor Traction without a Pin is invalid in 'Figure 11-10: Continuous system example 1' and multiple issues with ControlOperator SysML 1.6 open
SYSML17-354 Edge for [else] in 'Figure 11-11: Continuous system example 2' should be an ObjectFlow not a ControlFlow SysML 1.6 open
SYSML17-364 Suggest additional main body figure illustrating context-specific values (initialValues) compartment used for deep system configuration SysML 1.6 open
SYSML17-329 Inconsistent incoming ObjectFlow and outgoing ControlFlows on the DecisionNode in Figure 11.12 - Continuous system example 3 'Enable on Brake Pressure > 0' SysML 1.6 open
SYSML17-356 'Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty' does not allocate to a FlowProperty and multiple other minor issues SysML 1.6 open
SYSML17-360 Fig D.41 should be bdd with instance specs & slot values, not ibd with default values SysML 1.6 open
SYSML17-363 SysML-1.6: DeriveReqt: OCL constraint directions client vs supplier SysML 1.6 open
SYSML17-358 Trivial: consistency: Either show the [metaclass] on all Stereotype symbols or none in 'Figure 16-1: Abstract Syntax for Requirements Stereotypes' SysML 1.6 open
SYSML17-339 Figure D.24 Parametric Diagram does not explicitly show «equal» keyword or '=' on BindingConnectors SysML 1.6 open
SYSML17-344 Typo: 'not' should be 'nor' in '... not is this always even desirable' SysML 1.6 open
SYSML17-343 Typo: references to FuelTankAssy should be FuelTankAssembly for consistency with Figure D.25 SysML 1.6 open
SYSML17-334 Typo: 'Various other model elements may be necessary to help develop a derived requirement, and these model element' plural missing SysML 1.6 open
SYSML17-336 Typo: Missing end parentheses bracket: '(described in D.4.3 Elaborating Behavior (Sequence and State Machine Diagrams)' SysML 1.6 open
SYSML17-330 Typo: 'with is owned by the AutomotiveDomain block.' SysML 1.6 open
SYSML17-342 Need Connector from fuel:Fuel to :FuelPump in 'Figure D.25 Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram)' SysML 1.6 open
SYSML17-341 Naming inconsistencies 'Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties.' SysML 1.6 open
SYSML17-338 Figure D.23 has FuelFlow stereotyped by the DEPRECATED «flowSpecification» SysML 1.6 open
SYSML17-332 'Figure D.7 - Elaborating Black Box Behavior' some OCL missing, State names in oclInState() should be capital first letter, and display of name of alt fragment SysML 1.6 open
SYSML17-345 SysML-1.6: Figure D.25 has the type Fuel for both an in Port and an out Port on FuelTankAssembly (and it is not ideal to have same name as the Classifier that flows) SysML 1.6 open
SYSML17-346 7.3.2.3 Expose refers to 'The method' without referencing Viewpoint SysML 1.6 open
SYSML17-340 Typo: 'Binding connectors, as defined in Clause 8 are used ...' missing comma SysML 1.6 open
SYSML17-333 Typo: 'Deleting the container requirement deleted the nested requirements, a functionality inherited from UML.' should be 'deletes' SysML 1.6 open
SYSML17-337 Typo: 9.3.2.8 FlowProperty 'A flow propertys values' SysML 1.6 open
SYSML17-335 For Connectors in IBD Figure D.4 to be typed by implied anonymous Associations need define them in BDD Figure D.15 between 'HybridSUV' and: 'Driver', 'Maintainer', 'Passenger', 'Baggage', 'Environment' SysML 1.6 open
SYSML17-331 In Figure D.2 Real appears to be owned by the Automotive Value Types ModelLibrary (with no explicit ElementImport) SysML 1.6 open
SYSML17-307 Lots of ControlValues that should be ControlValueKinds SysML 1.6 open
SYSML17-319 It should not be allowed to modify an AdjunctProperty SysML 1.6 open
SYSML17-316 Duplicated sentence SysML 1.6 open
SYSML17-315 Unexpected word 'Figure' in Figure 4-2 name SysML 1.6 open
SYSML17-314 Unexpected section number SysML 1.6 open
SYSML17-313 Clarify that contraint parameters are value properties SysML 1.6 open
SYSML17-308 7_cannot_redefine_boundreference is too constrained SysML 1.6 open
SYSML17-306 Aggregation multiplicities not correct SysML 1.6 open
SYSML17-300 SysML 1.6 statement is too strong SysML 1.6 open
SYSML17-299 Caveat is not specific for UseCases SysML 1.6 open
SYSML17-293 Introduction to 9.1.3 Proxy Ports and Full Ports might be interpreted as SysML only permitting Full and Proxy Ports (not standard ports) SysML 1.6 open
SYSML17-298 Continuous and Discrete need to be on FlowProperties as well SysML 1.6 open
SYSML17-296 No Creation and Destruction Event in Current UML SysML 1.6 open
SYSML17-295 Figure 9.5 missing, duplicates 9.4 SysML 1.6 open
SYSML17-290 Remove reference to non-existing properties allocatedFrom and allocatedTo SysML 1.6 open
SYSML17-286 Remove notation form ActorPart SysML 1.6 open
SYSML17-284 Conjugation Stereotype SysML 1.6 open
SYSML17-285 is the stereotype <<~InterfaceBlock>> SysML 1.6 open
SYSML17-283 Need Bound References Compartment SysML 1.6 open
SYSML17-274 Parameters and Variables don't make sense SysML 1.6 open
SYSML17-248 The definition of AdjunctProperty SysML 1.6 open
SYSML17-234 QUDV library inconsistently uses SysML::Libraries::PrimitiveValueTypes SysML 1.6b1 open
SYSML17-278 AbstractRequirement: direction of /tracedTo wrong in Attributes description SysML 1.6 open
SYSML17-277 Description of getRefines() has typo and inconsistent singular vs plural SysML 1.6 open
SYSML17-276 Description of getRefines() restricts returned elements to AbstractRequirement [0..*] but the OCL static query does not (effectively NamedElement [0..*]) SysML 1.6 open
SYSML17-275 Parts is too restrictive SysML 1.6 open
SYSML17-273 Missing guard brackets in example activity diagram 11-12 SysML 1.6 open
SYSML17-261 How to interpret non-Navigation SysML 1.6b1 open
SYSML17-258 No changebars in SysML 1.6b1 open
SYSML17-257 Proposal: patent-friendly part/element numbering system with compliant solid line SysML 1.6b1 open
SYSML17-250 Should <> have a capital V? SysML 1.6b1 open
SYSML17-249 Duplicate Elements in Table SysML 1.6b1 open
SYSML17-243 Refine / Trace relationship operations are too restrictive SysML 1.6b1 open
SYSML17-242 VerdictKind should also have the literal none SysML 1.6b1 open
SYSML17-231 ProxyPort property "matching" SysML 1.6 open
SYSML17-229 cannot model and validate physical connections SysML 1.4 open
UMLR-104 Section: Chapter: 7.3.2.4 View SysML 1.0 open
UMLR-140 Section: Activities SysML 1.0 open
UMLR-141 Callout notation for many clients/suppliers SysML 1.0 open

Issues Descriptions

Adopted resolution SYSML2_-403 has impact on the v1 to v2 Transformation

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    SYSML2_-403 change semantics and the class hierarchy for FlowConnectionUsage and therefor impact the specification of the transformation that is related to that class

  • Reported: SysML 2.0b2 — Fri, 20 Dec 2024 17:43 GMT
  • Updated: Fri, 20 Dec 2024 17:43 GMT

Properties typed by a Signal are not mapped

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    There is no rule that maps a property typed by a Signal. It should be mapped to an item usage.

  • Reported: SysML 2.0b2 — Fri, 20 Dec 2024 08:08 GMT
  • Updated: Fri, 20 Dec 2024 08:08 GMT

Flow connections are incorrectly both structure and behavior

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    According to the KerML specification, "Structures and behaviors do not overlap". Consistent with this, the approved resolution to KERML-43 added validations to disallow a structure from specializing a behavior and vice versa.

    ConnectionDefinitions in SysML are kinds of PartDefinitions, which are (indirectly) kinds of KerML Structures. But FlowConnectionDefinitions are both ConnectionDefinitions and ActionDefinitions, and ActionDefinitions are kinds of KerML Behaviors. This means that FlowConnectionDefinitions are both Structures and Behaviors, violating the restrictions of KerML.

    As a result, the specializations in the declarations of MessageConnection and FlowConnection in the Systems Library model Connections now violate the new validateStructureSpecialization and validateBehaviorSpecialization constraints added by the resolution to KERML-43.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 17:04 GMT
  • Updated: Thu, 19 Dec 2024 23:58 GMT
  • Attachments:

Remove "Connection" from the names "FlowConnectionDefinition", "FlowConnectionUsage", and "SuccessionFlowConnectionUsage"

  • Status: open  
  • Source: Ansys Government Initiatives ( Mr. Richard Page)
  • Summary:

    After resolution SYSML2_-403 to issue SYSML2_-173, FlowConnectionDefinition no longer specializes ConnectionDefinition (now specializing only ActionDefinition and KerML Interaction), and FlowConnectionUsage no longer specializes ConnectionUsage (now only specializing ActionUsage, ConnectorAsUsage and KerML ItemFlow. As a result of SYSML2_-403, having "Connection" in the name of the "Flow" classes causesconfusion among users that don't see the distinction between structure and behavior.

    Renaming FlowConnectionDefinition to FlowDefinition and FlowConnectionUsage to FlowUsage would avoid confusion going forward. Not making this change prior to finalization of SysML v2 runs the risk of having confusion that would require complex deprecation steps to correct later.

    Similarly for SuccessionFlowConnectionUsage, which specializes FlowConnectionUsage.

  • Reported: SysML 2.0b2 — Wed, 11 Dec 2024 21:29 GMT
  • Updated: Wed, 18 Dec 2024 17:32 GMT

Cross features for connection definitions and connection usages

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Resolution KERML_-87 to issue KERML_-18, which has been approved by the KerML FTF, adds a new `CrossSubsetting` relationship and introduces the concept of cross features for end features of associations and connectors. These changes in KerML require corresponding updates to the concrete syntax, abstract syntax and semantics of connections and connection definitions in SysML, which are based on KerML associations and connectors.

  • Reported: SysML 2.0b2 — Tue, 10 Dec 2024 07:56 GMT
  • Updated: Tue, 17 Dec 2024 22:55 GMT

Inconsistent and/or incomplete graphical notation for standard reference-subsetted usages

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.20.1, Table 19, example "Requirement" the compartment labels "require constraints" and "assume constraints" and their content are misleading and inconsistent. Besides pure "require ConstraintUsage" statements a "require constraints" compartment may also contain "require RequirementUsage" statements. A "require RequirementUsage" has the same semantics as a RequirementUsage contained (isComposite==true) by a containing RequirementUsage (see explanation in subclause 7.20.2). Therefore a better compartment name is possibly "requires".

    The same problem applies to other compartments for shorthand textual notation for particular reference-subsetted usages following a similar pattern. The full list of patterns to be made consistent is:

    • assert (constraint)
    • assume (constraint)
    • exhibit (state)
    • frame (concern)
    • include use case
    • perform (action)
    • require (constraint)
    • satisfy (requirement)
    • verify (requirement)

    In addition a mix of verb forms are used: some use the infinitive (exhibit states, satisfy requirements), some use third person singular form (exhibits, satisfies). This is confusing and should be regularized in a consistent way, following a single rule.

    Finally, graphical edges that represent the above reference-subsetted relationships between usage nodes are inconsistently specified in the representative notation tables in clause 7, and the graphical BNF in subclause 8.2.3.

  • Reported: SysML 2.0b2 — Wed, 24 Jul 2024 14:06 GMT
  • Updated: Tue, 17 Dec 2024 22:13 GMT

Description and examples for message notation are wrong

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The description of message declarations in 7.13.6 Flow Connection Usages and Messages is incorrect. It states that a message declaration "may or may not include identification of source and target related features. If they are included, then they follow the payload specification (if any), with the source related feature identified after the keyword from, followed by the target related feature after the keyword to." However, the from and to features of a message are not the related features of the message as a flow connection usage. Rather, they are the values of the sourceEvent and targetEvent parameters of the MessageConnection (see parsing in 8.2.2.13.4 Message and Flow Connections and semantics in 8.4.9.6 Flow Connection Usages).

    In light of this, the message declaration example in 7.13.6 is also incorrect, as is the textual notation for the first "Messages" example in Table 11 Connections – Representative Notation (showing a message between ports). However, the graphical notation in this example seems to be acceptable, as are both the graphical and textual notations in the second "Message" example (showing a message on a sequence diagram).

  • Reported: SysML 2.0b2 — Mon, 24 Jun 2024 04:43 GMT
  • Updated: Tue, 17 Dec 2024 16:32 GMT

Language description of messages is incorrect

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.13.6 Flow Connection Usages and Messages, a message declaration is described as identifying the "source and target related features", and the associated example shows a message declared as being between controller and engine parts. This is not correct. Messages are actually declared between source and target events that are within the source and target related features, with the actual ends of the transfer remaining implicit.

  • Reported: SysML 2.0b2 — Mon, 2 Dec 2024 06:55 GMT
  • Updated: Tue, 17 Dec 2024 00:26 GMT

Messages cannot have explicit flow connection definitions

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    As for other flow connection usages, the syntax for a message declaration allows for explicit typing by flow connection definitions. However:

    • The constraint checkFlowConnectionDefinitionSpecialization requires that a flow connection definition specialize the base type MessageConnection. MessageConnection has source and target ends that redefines corresponding ends from BinaryConnection and Transfer. So, any flow connection definition must be binary, with exactly two ends, either inherited from or redefining the ends of MessageConnection.
    • The constraint checkFlowConnectionUsageSpecialization requires that a message (with no owned end features) specialize the base feature messageConnections, which also has source and target ends that redefine the corresponding ends from MessageConnection, binaryConnections and transfers.
    • This means that a message declaration with explicit typing by flow connection definitions inherits ends from both the flow connection definitions and its subsetting of messageConnections. Since a message declaration by definition has no owned end features, this cannot be resolve by redefining the inherited end features. The message declaration therefore results in a flow connection usage with more than two ends, which violates the (KerML) constraint validateConnectorBinarySpecialization.
  • Reported: SysML 2.0b2 — Mon, 2 Dec 2024 06:04 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT

deriveItemUsageItemDefinition is incorrect

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 8.3.10.3 ItemUsage, under "Attributes", the type of the attribute itemDefinition is Structure and the attribute description states

    The Structures that are the definitions of this ItemUsage. Nominally, these are ItemDefinitions, but other kinds of Kernel Structures are also allowed, to permit use of Structures from the Kernel Library.

    However, under "Constraints" the constraint deriveItemUsageItemDefinition has the following description and OCL:

    The itemDefinitions of an ItemUsage are those occurrenceDefinitions that are ItemDefinitions.

    itemDefinition = occurrenceDefinition->selectByKind(ItemDefinition)
    

    This only allows itemDefinitions that are ItemDefinitions, filtering out all other kinds of Structures.

  • Reported: SysML 2.0b2 — Tue, 19 Nov 2024 23:11 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT

TestCaseVerifyObjectiveRequirementUsage_Mapping has no general mapping

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Each mapping class needs at least one general mapping. There is none defined for TestCaseVerifyObjectiveRequirementUsage_Mapping.

  • Reported: SysML 2.0b2 — Tue, 19 Nov 2024 10:52 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT

Incomplete description of TestCaseVerifyObjectiveMembership_Mapping

  • Key: SYSML2_-4
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The section describing the mapping class TestCaseVerifyObjectiveMembership_Mapping is incomplete. The subsections Description, General Mappings, Mapping Source, Mapping Target, and Owned Mappings are missing.

  • Reported: SysML 2.0a1 — Wed, 19 Apr 2023 17:16 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT

Incorrect graphical BNF production item-name-compartment

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 8.2.3.10 the production item-name-compartment is out-of-date. In line with other usage name-compartment productions it should read:

    item-name-compartment =
          '«' OccurrenceUsagePrefix 'item' '»'
          usage-name-with-alias
    
  • Reported: SysML 2.0b2 — Mon, 18 Nov 2024 23:01 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT

The operation RICOAOutputPin_Mapping::filter() should redefine Pin_Mapping::filter()

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Operation RICOAOutputPin_Mapping::filter() does not redefine Pin_Mapping::filter(). The issue is not visible in the specification document but in the model resp. XMI.

  • Reported: SysML 2.0b2 — Mon, 18 Nov 2024 17:53 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT

Subclause 7.7.5.3.7 Trigger_Mapping is empty

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The subclause 7.7.5.3.7 Trigger_Mapping contains no text.

  • Reported: SysML 2.0b2 — Mon, 18 Nov 2024 08:37 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT

Incorrect graphical notation of nested items in item parameter

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.13.1, Table 11, example "Flow as node" in the «flow» elaboration symbol the subItems of source.item1 and target.item2 are depicted with parameter symbols. This is incorrect because the subItems are undirected features and therefore should be depicted as parameters, but rather as nested items inside the containing item1 and item2 rounded rectangles.

  • Reported: SysML 2.0b2 — Thu, 14 Nov 2024 15:47 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT

Incorrect graphical notation for parameters with nested items in example "Flow as Node"

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    In subclause 7.13.1, Table 11, example "Flow as Node" the subitems of parameters item1 and item2 of the flow between action1 and action2 are depicted in the elaborated flow node with parameter symbols subItem1, subItem2, subItem3. The current graphical notation is as follows:

    Currently parameter nodes can only show nested parameters and direction. They need to be able to show owned features such as item usages.

  • Reported: SysML 2.0b2 — Mon, 21 Oct 2024 13:09 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT
  • Attachments:

Entry, do and exit actions compartment should be named "state actions"

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.17.1, Table 16, example row "State with entry, do and exit actions", the compartment label is "actions".

    In subclause 8.2.3.17 in production state-actions-compartment the compartment label is "states".

    To be explicit and unambiguous, in both places the label should be "state actions".

  • Reported: SysML 2.0b2 — Thu, 14 Nov 2024 15:35 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT

Specification of Helper::getScalarValueType() uses unknown OCL function

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The specification of Helper::getScalarValueType() uses the unknown OCL String function includes:

    t.qualifiedName.includes('PrimitiveTypes::UnlimitedNatural')
    

    To check if a string is part of another string, the function indexOf() should be used instead.

    The issue was accidentally introduced by SYSML2_-300 in ballot #3.

  • Reported: SysML 2.0b2 — Wed, 13 Nov 2024 19:45 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT

COAPin_Mapping is not correctly specified

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The COAPin_Mapping class should specialize directly or indirectly a mapping class from the mapping framework. Very likely, it should specialize Pin_Mapping.

  • Reported: SysML 2.0b2 — Wed, 13 Nov 2024 14:58 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT

ValuePin_Mapping is not correctly specified

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The ValuePin_Mapping class should specialize directly or indirectly a mapping class from the mapping framework. Very likely, it should specialize Pin_Mapping.

  • Reported: SysML 2.0b2 — Wed, 13 Nov 2024 13:11 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT

Mapping class description AEAChangeParameterFeatureMembership_Mapping is missing

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping class AEAChangeParameterFeatureMembership_Mapping is in the transformation model, i.e., the XMI and is referenced by the mapping class AEAChangeParameterTrigger_Mapping, but the description is missing in the document.

  • Reported: SysML 2.0b2 — Wed, 13 Nov 2024 11:14 GMT
  • Updated: Tue, 17 Dec 2024 00:25 GMT

Graphical notation examples violate GBNF and contain typo

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.9.1., Table 7, examples "Individual Occurrence" and "Portion Membership" the graphical notations incorrectly show «individual» as a separate keyword in guillemets. In line with the Graphical BNF specification, they should be put together with the main element keyword, i.e. «individual occurrence» and «individual part» respectively.

    The first example also contains a typo: 'OccurenceDef1-1' should read 'OccurrenceDef1-1'. The second contains typo: indvidual1 should read individual1.

  • Reported: SysML 2.0b2 — Wed, 6 Nov 2024 22:11 GMT
  • Updated: Tue, 17 Dec 2024 00:24 GMT
  • Attachments:

Mistakes in various occurrence examples

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.9.1, Table 7, example "Individual Occurrence Definition", in the graphical notation, the name 'OccurenceDef1-1' is an UNRESTRICTED_NAME and should be written between two single quotation marks as it contains a character (the hyphen) outside the valid character set for BASIC_NAME (see KerML clause 8.2.2.3).

    There are also many typos in the spelling of "occurrence":

    • Example "Occurrence Definition": in graphical notation OccurenceDef1 should read OccurrenceDef1.
    • Example "Occurrence": in graphical notation OccurenceDef1 should read OccurrenceDef1.
    • Example "Individual Occurrence Definition": In graphical notation: OccurenceDef should read OccurrenceDef (2x missing r), and in the textual notation: OcurrenceDef should read OccurrenceDef (1x missing c).
    • Example "Individual Occurrence": in graphical notation OccurenceDef1-1 should read OccurrenceDef1-1.
    • Example "Timeslice": in graphical notation OccurenceDef1 should read OccurrenceDef1.
    • Example "Snapshot": in graphical notation OccurenceDef1 should read OccurrenceDef1.
  • Reported: SysML 2.0b2 — Wed, 6 Nov 2024 22:00 GMT
  • Updated: Tue, 17 Dec 2024 00:24 GMT

No else branch for a decision node

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    The graphical BNF and representative notation do not support an else branch originating from a decision node.

  • Reported: SysML 2.0b2 — Wed, 6 Nov 2024 15:25 GMT
  • Updated: Tue, 17 Dec 2024 00:24 GMT
  • Attachments:

Alignment of selected graphical symbols in states and actions.

  • Status: open  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    Some graphical symbols used in state machine diagrams and activity diagrams in SysML v1 have been informally carried over to SysML v2. However, there are inconsistencies in how the symbols are used in SysML v2 actions and states. The intent is to align the symbols shown in the attachment that include the graphical SysML v2 symbols in action flow views that correspond to the initial node, flow final, and activity final with the SysML v2 graphical symbols in state transition views that correspond to the initial pseudo state, final state, and terminal node pseudo state. This will also require addressing the symbols for entry action which is currently informally depicted in SysML v2 with a solid filled circle like the initial pseudo state.

  • Reported: SysML 2.0b2 — Sat, 2 Nov 2024 15:22 GMT
  • Updated: Tue, 17 Dec 2024 00:24 GMT
  • Attachments:

Not possible to show inherited symbol in name compartment

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    Graphical notation uses a caret symbol "^" to show inherited properties. This is currently only possible for textual compartments, it also needs to be enabled for name compartments.

  • Reported: SysML 2.0b2 — Wed, 23 Oct 2024 09:27 GMT
  • Updated: Tue, 17 Dec 2024 00:24 GMT

There is no production for general-view

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    general-view is used but not specified. The definition should probably be

    general-view = 
        definition-node*  definition-edge * usage-node* usage-edge*
    

    Also, need to add a production for definition-edge and account for namespace symbols (e.g., packages)

  • Reported: SysML 2.0b2 — Wed, 18 Sep 2024 13:49 GMT
  • Updated: Tue, 17 Dec 2024 00:24 GMT

Diagram frame production not properly integrated into graphical BNF

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    While there is a production for a diagram frame, it is not used by the graphical BNF, other than by "usage-node".
    There is a need to specify how diagram frames are integrated into the various view productions, such as general-view, interconnection-view etc

  • Reported: SysML 2.0b2 — Tue, 20 Aug 2024 10:07 GMT
  • Updated: Tue, 17 Dec 2024 00:24 GMT
  • Attachments:

Send action examples in representative notation tables wrong

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    In clause 7.16.1, the examples provided for send action are confusing and erratic. 5 alternative graphical examples for a single textual reference shown all of them have issues.

    • First example might be correct, if payload is indeed a parameter
    • Second example simply partial and lacks information such as picture
    • 3rd example use guiileimets in the textual expression and has redundant parameter symbols
    • 4th example Show(shoot.picture) misaligned with textual example
    • 5th example is partial and ot equivalent to the textual reference
  • Reported: SysML 2.0b2 — Wed, 14 Aug 2024 07:41 GMT
  • Updated: Tue, 17 Dec 2024 00:24 GMT
  • Attachments:

Incorrect declaration of parameters on actions


Accept action in representative notation tables is confusing and needs cleanup

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    Clause 7.16.1 (rep. notation for actions) shows a graphical notation example of an accept action corresponding to the following textual notation:

    action trigger1 : Trigger 
    accept scene : Scene via viewPort;
    

    It shows 3 alternative graphical notations which are confusing and inconsistent.
    That graphical representative example needs to be corrected. Here are few issues:

    • it shows an unbound parameter "receiver" in 2nd and 3rd examples
    • first example uses the type Trigger instead of Trigger1
    • 3rd example uses guillemets in the wrong way
    • too many options instead of one "canonical" way to do this
    • it uses a parameter that in 2nd example called scene and in 3rd example called payload
  • Reported: SysML 2.0b2 — Mon, 29 Jul 2024 07:03 GMT
  • Updated: Tue, 17 Dec 2024 00:24 GMT
  • Attachments:

State machine graphical notation for entry/exit/do actions inconsistent

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    Current GBNF uses the textual notation to represent state entry/do/exit actions within a "state actions" compartment.
    This does not allow to describe state actions in a graphical way and also requires the graphical modeler to use more extended textual syntax.

  • Reported: SysML 2.0b2 — Thu, 20 Jun 2024 12:44 GMT
  • Updated: Tue, 17 Dec 2024 00:24 GMT
  • Attachments:

Textual notation for send actions is too limited

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    According to the SysML Specification, 8.2.2.16.4 Send and Accept Actions, the general textual notation for a send action has the form

    send payloadExpression via senderExpression to receiverExpression

    In this syntax, the via and to parts are optional, but the payloadExpression is not. Since the result of the required payloadExpression is bound to the payload parameter of the send action, this makes it difficult to model a case in which, e.g., it is desired use a flow to provide the value of the payload, rather than the result of an expression. It also makes it difficult to model a general send action with the payload not specified (or defaulted), with the actual payload bound in a specialization of the general action.

    While it is possible to get around these limitations by modeling the send action using a regular action usage typed by Actions::SendAction, this is no longer syntactically a send action usage and so, e.g., would not be rendered as such in the graphical notation. It would be better if the textual notation allowed the payloadExpression to be optional, while still declaring syntactic send action usage.

  • Reported: SysML 2.0b1 — Wed, 8 Nov 2023 17:26 GMT
  • Updated: Tue, 17 Dec 2024 00:23 GMT

Missing graphical notation for Flows Compartment

  • Key: SYSML2_-27
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.13.1, Table 15, in example "Flows Compartment" the graphical notation is missing. Graphical notation corresponding to the example expressed in textual notation should be added. Also, the corresponding graphical BNF production for flows-compartment is missing in subclause 8.2.3.13, so that should be added too.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 14:55 GMT
  • Updated: Tue, 17 Dec 2024 00:23 GMT

Graphical BNF production proxy should be contextualized

  • Key: SYSML2_-15
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    proxy refers to proxy-label should be sq-proxy-label
    The BNF attempted to reuse the proxy graphics and productions across all three contexts where a proxy may appear (lifeline, ports, and parameters), but all these need to be replaced by proxy graphics specific to each context, including connector line segments above and below, or left and right, in each specific graphic context where a proxy dot may appear.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 20:40 GMT
  • Updated: Tue, 17 Dec 2024 00:23 GMT
  • Attachments:

Graphical BNF production sq-ev-occurrence has inconsistent proxy notation


SysMLv2 Metadata Annotation Capabilities do Not Hide enough Implementation Details in Textual Representation

  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    When metadata is defined with keyword textual notation allows short syntax of metadata application with #keyword. Example from the spec:

    occurrence def Situation;
    occurrence situations : Situation[0..*] nonunique;
    metadata def <situation> SituationMetadata :> SemanticMetadata {
    :>> baseType = situations meta SysML::Usage;
    }
    
    // batteryLow is an OccurrenceUsage that implicitly subsets situations.
    #situation occurrence batteryLow;
    

    Unfortunately, the end user still needs to know underlying model element flavor (occurrence in the example above). This knowledge is difficult to learn for the users of the particular specialized domain. It could be considered an "implementation detail" of the domain specific modeling provider.

    Ideally, when metadata is defined 1) with keyword 2) with annotatedElement fixed to a single variant, the end user should not need to specify the model element flavor ("metaclass") in the textual notation and just state the keyword; like this:

    #situation batteryLow;
    

    This would be very handy for UAF and other domains.

  • Reported: SysML 2.0b2 — Mon, 28 Oct 2024 07:58 GMT
  • Updated: Wed, 11 Dec 2024 15:57 GMT

Fix errors in resolution of issue SYSML2_-203 (InitialState mapping)

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Unfortunately, a small error has crept into the resolution of SYSML2_-203.

    The mapping class InitialStateMembership_Mapping should be named InitialStateSubactionMembership_Mapping and the general mapping of the mapping class should be GenericToSubactionMembership_Mapping.

    Accordingly, change InitialStateMembership_Mapping in Helper::stateOwnedRelationship() to InitialStateSubactionMembership_Mapping.

  • Reported: SysML 2.0b2 — Sat, 24 Aug 2024 11:29 GMT
  • Updated: Tue, 10 Dec 2024 16:34 GMT

All redefinitions of mapping features should be visible in the generated document

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    All feature redefinitions specified in the transformation model, whether they affect properties or operations, should appear in the specification document

  • Reported: SysML 2.0b2 — Tue, 10 Dec 2024 07:12 GMT
  • Updated: Tue, 10 Dec 2024 15:43 GMT

Notation should be more formally tied with Abstract Syntax

  • Status: open  
  • Source: UNICOM Systems ( Mark Gregory)
  • Summary:

    Each section describing a particular thing e.g. Usage needs a notation subsection which should show all new possible notation relevant to that section where not described elsewhere and how it ties in with abstract syntax in terms of which properties, item types and values are involved.

    Graphical lines which connect items should be described in terms what attributes of what item should refer to which other items.

    Such information should not be buried in a sea of descriptive text, it should be clear and concise.

    An example: 7.10 deals with Items and only lists a couple of symbols and one compartment (displayable property) called 'items'.
    There is no specification of what this compartment is presenting in terms of a) the property or properties to be checked or b) what is referenced.
    Point a can sometimes be answered where they have property name = ... but not in this case.
    Point b can sometimes be answered by following the chain of notation specifications because they sometimes have notationname : type of element = ... - this does point to Usage types.
    I guessed that the nestedItem attribute should be the source of this information.

    The Graphical syntax section identifies another symbol, an item reference, which I guess is the presentation to be used when the Usage is a ReferenceUsage. I say guess because again there is no specification.

    Trying to understand 18: Connections with respect to abstract syntax when each pictured symbol's abstract type is not named is very difficult.

  • Reported: SysML 2.0b2 — Fri, 15 Nov 2024 16:21 GMT
  • Updated: Tue, 10 Dec 2024 08:12 GMT

Definitions of View Usage are Too Restricted

  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    View usage is restricted to have at most one definition which must be a view definition:

          /viewDefinition : ViewDefinition [0..1] {redefines partDefinition}
    

    With this passage viewDefinition field redefines partDefinition field - this makes constraints on what partDefinition field values can be - namely (at most) one definition which must be a view definition.

    This is too restrictive and precludes some valid use cases; For example, additional "instrumentation" of the view with additional properties to implement diagram properties
    e.g.:

    part def VendorSpecificDiagramProperties {
       attribute showGrid:Boolean;
       //other diagram style attributes here
    }
    //.......
    view usage usersDiagram: InterconnectionView, VendorSpecificDiagramProperties {
     :>>showGrid = true;
    }
    

    This restriction could be relaxed to e.g. viewDefinition subsetting partDefinition instead of redefining, allowing more flexible use of views (just like partDefinition only subsets itemDefinition).

  • Reported: SysML 2.0b2 — Mon, 18 Nov 2024 08:20 GMT
  • Updated: Tue, 10 Dec 2024 08:10 GMT

Accept after guard causes errors in IDE

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    The specification states in 7.17.3:

    "The accepter action for a transition usage is placed after the guard expression and notated using the accept keyword..."

    The examples in 7.17.3 also show "accept" after the "if' statement.

    However, the implementation (specifically, Eclipse) will not instantiate a transition that has the accept after the guard. It will recognize the accept before the guard.

    For example:

        item def TurnOn;
        state def OffOn {
        	state off;
        	state on;
        	in attribute enabled;
        	transition off_on3 first off accept TurnOn if enabled then on;//This declaration parses
        	transition off_on4 first off if enabled accept TurnOn then on;//This declaration does not parse.
        }
    
  • Reported: SysML 2.0b2 — Tue, 19 Nov 2024 17:20 GMT
  • Updated: Tue, 10 Dec 2024 08:08 GMT

Apparent use of an overly-generic notation entry in subsetting or redefinition notation specification for Connection end

  • Status: open  
  • Source: UNICOM Systems ( Mark Gregory)
  • Summary:

    I think these specifications in section 8 are too generic.

    a-subsetting =
    '«subsets»' ownedRelationship (',' ownedRelationship)*
    a-redefinition =
    '«redefines»' ownedRelationship (',' ownedRelationship)*
    

    There is no single ownedRelationship = or ownedRelationship : but several ownedRelationship += which I interpret to mean that this is the property that would be added to when parsing.
    The first of these would surely be OwnedSubsetting which has a OwnedSubsetting : specification.

  • Reported: SysML 2.0b2 — Fri, 22 Nov 2024 17:25 GMT
  • Updated: Tue, 10 Dec 2024 08:07 GMT

ownedParameterMember should be ownedMemberParameter

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    typo in OCL, also on page 184

  • Reported: SysML 2.0b2 — Sat, 23 Nov 2024 10:48 GMT
  • Updated: Tue, 10 Dec 2024 08:02 GMT

flow-label definition cut short

  • Status: open  
  • Source: UNICOM Systems ( Mark Gregory)
  • Summary:

    Definition is given as

    flow-label =
    UsageDeclaration? ('«of»' FlowPayloadFeatureMember)? | FlowPayloadF
    
  • Reported: SysML 2.0b2 — Tue, 26 Nov 2024 10:34 GMT
  • Updated: Tue, 10 Dec 2024 08:00 GMT

Graphical notation for variant inheritance from variation requires improvement

  • Key: SYSML2_-30
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    A variant is an owned member of its variation and is also a specialization of its variation. As a result, the variant inherits the owned member relationships from its variation.

    This appears in the diagram in the attached example (file name: variant_inheritance_from_variation_issue_sf_2023-04-12). The transmissionAutomatic has an inherited ownedMembership to the transmissionManual and to itself. This applies to the transmissionManual as well.

    Refer to the spec clauses as 8.2.3.5 Namespaces and Packages Graphical Notation and 8.2.3.6 for Definition and Usage Graphical Notation (where variation is introduced).

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 15:33 GMT
  • Updated: Mon, 9 Dec 2024 02:07 GMT

Multiple vs Single Trigger/Guard/Effect for State Transitions Contradiction

  • Status: open   Implementation work Blocked
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    On one hand abstract syntax chapters for the transitions between states stipulate (Figure 32 in 8.3.17.1@page316, text in 8.3.17.9@page325)
    that transition can have multiple triggers, multiple guards and multiple effects
    by specifying multiplicities [0..*] for TransitionUsage::triggerAction, TransitionUsage::guardExpression, TransitionUsage::effectAction

    On the other hand, semantics and textual syntax chapters for the transitions between states stipulate (8.4.13.3@page424, 8.2.2.17.3@page178)
    that transition can have at most one of each trigger, guard and effect
    by stating:
    "A TransitionUsage is parsed as having the following ownedMemberships
    ....
    Zero to three TransitionFeatureMemberships for up to one each of a triggerAction, guardExpression, and effectAction."

    and by using "?" marks (which has a meaning of [0..1] multiplicity) in the BNF
    "TransitionUsage =
    ...
    ownedRelationship += TriggerActionMember )?
    ( ownedRelationship += GuardExpressionMember )?
    ( ownedRelationship += EffectBehaviorMember )?"

    -----------------------
    This contradiction should be resolved in one direction or another - by stipulating either [0..1] or [0..*] everywhere.

    We suggest that the variant with singular multiplicity be adopted as this seems to be closer to the original intent of standard builders.
    This was also the convention of previous standards (UML)

    Therefore the abstract syntax chapters - Figure 32 in chapter 8.3.17.1@page316, and specification in chapter 8.3.17.9@page325 -
    should be updated with multiplicity [0..1] for the aforementioned 3 fields.

  • Reported: SysML 2.0b2 — Wed, 10 Jul 2024 11:46 GMT
  • Updated: Fri, 6 Dec 2024 19:20 GMT

TimeEvent should be mapped to an accept action instead of TextualRepresentation

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In the textual notation, a time event can be represented by an accept action with an at or after condition. The example below is from the vehicle model.
    transition normal_To_maintenance
    first normal
    accept at maintenanceTime
    then maintenance;

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 11:42 GMT
  • Updated: Fri, 6 Dec 2024 16:36 GMT

ChangeEvent should be mapped to an accept action instead of TextualRepresentation

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In the textual notation, a change event can be represented by an accept action with a when condition. The example below is from the vehicle model.
    transition normal_To_degraded
    first normal
    accept when senseTemperature.temp > Tmax
    do send OverTemp() via targetPort
    then degraded;

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 11:35 GMT
  • Updated: Fri, 6 Dec 2024 16:32 GMT

Transformation of UML4SysML::ActivityFinalNode is not specified yet

  • Key: SYSML2_-44
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of a UML4SysML::ActivityFinalNode is not covered by the transformation rules.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:04 GMT
  • Updated: Thu, 5 Dec 2024 05:53 GMT
  • Attachments:

Each FlowConnectionUsage owned by PartUsage subsets 3 features

  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    In current implementation each FlowConnectionUsage owned by PartUsage subsets (automatically) 3 features:

    1. FlowConnectionUsage::flowConnections
    2. PartUsage::subparts
    3. ActionUsage::ownedActions

    This could be optimized for the sake of model size. Maybe it would be better idea to introduce

        Part::Part::ownedFlows :> ownedActions, subparts, flowConections
    

    and define something like CheckFlowConnectionSubFlowSpecialization constraint?

  • Reported: SysML 2.0b2 — Mon, 28 Oct 2024 08:27 GMT
  • Updated: Mon, 2 Dec 2024 06:41 GMT

proxy connection points are not contextualized in sequence diagrams

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    proxy connection in sequence views should be contextualized on lifelines.
    Right now they just float as nodes.

  • Reported: SysML 2.0b2 — Wed, 27 Nov 2024 11:11 GMT
  • Updated: Wed, 27 Nov 2024 11:11 GMT

Flow Connection Payload modeling - Different models created for definition through sytactic sugar vs fully expanded definition

  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    It is possible to define flow connection usage in several ways.

    One - use the simple/nice notation where syntactic sugar hides the underlying complexity:

       flow of SomeItemDefinition from firstEndCon to secondEndCon;
    

    Second- use full available detailed notation allowing precise definition of the characteristics of the payload

       flow {
          :>>payload: SomeItemDef; //note more characteristics for payload can be modeled here - especially useful when flows are inherited
          end ::> firstEndCon;
          end ::> secondEndCon;
       }
    

    Sometimes the second, detailed way is the only way to define characteristics of the payload in the more complex cases (especially when the flows are inherited/specialized in the hierarcy).

    Now the problem is that two different models are created for these two cases. ItemFeature is created for the first/nice/short case while simple ReferenceUsage is created for the full/complete case.

    It seems that ItemFeature (meta)type is mostly a syntactic marker. So perhaps it would be possible to get rid of it entirely and make the two cases equivalent from the abstract syntax/model standpoint?

    This non-uniformity causes several technical problems down the line.

    • It does not allow to have other kind of features (for example ReferenceUsage in SysML) as item features on FlowConnections. ReferenceUsage is not inherited from ItemFeature
    • ItemFlow::itemFeature derived property returns only owned flow item feature, but in practice actual (owned or inherited) one should be returned.

    The second problem could perhaps be solved by e.g. changing the definition of the itemFeature property in the abstract syntax to be the feature that specializes `Transfer::item`, whether or not it is owned or inherited, and whether or not it is an ItemFeature. The derivation would not be as simple as the current one, but it would be a reasonable suggestion.

  • Reported: SysML 2.0b2 — Mon, 4 Nov 2024 07:26 GMT
  • Updated: Sun, 24 Nov 2024 04:44 GMT

Syntactic Sugar Notation to Define Payload for Flow Def

  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    Currently, the only way to create payload for flow def is to redefine it explicitly:

    flow def SomeFD {
       :>>payload: SomeData;
       end :FirstEndType;
       end :SecondEndType;
    }
    

    it would be nice for the same syntactic sugar "of TypeOfPayload" to be available for flow defs as is now available for flow usages:

    flow def SomeFD  of SomeData {
       end :FirstEndType;
       end :SecondEndType;
    }
    
  • Reported: SysML 2.0b2 — Mon, 4 Nov 2024 08:13 GMT
  • Updated: Sun, 24 Nov 2024 04:41 GMT

Flow Connection End modeling - Different models created for definition through sytactic sugar vs fully expanded definition

  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    It is possible to define flow connection usage in several ways.

    One - use the simple/nice notation where syntactic sugar hides the underlying complexity:

    flow of SomeItemDefinition from firstEndCon to secondEndCon;
    

    Second- use full available detailed notation allowing precise definition of the characteristics of the flow ends:

    flow of SomeItemDefinition {
        end ::> firstEndCon {
           //more end characteristics can be specified here:
           :>>sourceOutput, someFlowPropertyofEnd1;
        }
        end ::> secondEndCon {
           :>>targetInput, someFlowPropertyofEnd2;
        }
    }
    

    Sometimes the second, detailed way is the only way to define characteristics of the ends in the more complex cases. Now the problem is that two different models are created for these two cases. ItemFlowEnd is created for the first/nice/short case while simple ReferenceUsage is created for the full/complete case

    It seems that ItemFlowEnd (meta)type is mostly a syntactic marker.So perhaps it would be possible to get rid of it entirely and make the two cases equivalent from the abstract syntax/model standpoint (by using just ReferenceUsage)?

  • Reported: SysML 2.0b2 — Mon, 4 Nov 2024 08:29 GMT
  • Updated: Sun, 24 Nov 2024 04:39 GMT

Library description of Duration of is truncated

  • Status: open  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    The description in clause 9.8.8.2.4 is missing the three words at the end of the sentence.
    'its start snapshot.'
    The above description in the SysML specification should align with corresponding clause 9.2.12.2.5 in the KerML specification to read as follows:
    DurationOf returns the duration of a given Occurrence relative to a given Clock, which is equal to the TimeOf the end snapshot of the Occurrence minus the TimeOf its start snapshot.

  • Reported: SysML 2.0b2 — Fri, 8 Nov 2024 01:01 GMT
  • Updated: Sun, 24 Nov 2024 04:36 GMT

Header description of unowned elements does not align with textual notation

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    The following row headers describe unowned elements, but the textual notation illustrates that the elements are owned.

    Package with alias member (unowned)
    Package with alias member (unowned)
    Membership (unowned member with alias name)

    The simplest resolution, if the desire to emphasize "unowned" is maintained, may be to use textual notation for each which declare the packages to be aliased in the next higher namespaces.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 18:41 GMT
  • Updated: Fri, 22 Nov 2024 23:07 GMT

Stakeholder_Mapping should map from Classifier to PartDefinition

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The SysML v1 stereotype Stakeholder is applied to Classifiers. Therefore, it could also be other model elements than Class which represent stakeholders. The usage of Actor is quite common.

    Actors are mapped to PartDefinition. Therefore, Stakeholders should also be mapped to PartDefinition which makes it more consistent. Stakeholders and Actors are different concepts, but there seems to be no reason to map them differently to parts and items.

  • Reported: SysML 2.0b2 — Fri, 22 Nov 2024 08:24 GMT
  • Updated: Fri, 22 Nov 2024 08:24 GMT

Table 5 Attributes Compartment Graphical Notation and Textual Notation does not match

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    Readers should expect that the textual notation and graphical notation should match as much as possible, including element names.
    The attributes compartment row should at least align on the attribute1 declaration (the definition is different between the graphical and textual notations. I would like to make the case that all of the graphical notation examples should be shown in textual notation, too. If it is worth it to show the graphical notation expectation in the table, it is worth it to show the corresponding textual notation.

    Example of minimum correction in textual notation:
    change:
    attribute attribute1 : Attribute1Def
    to:
    attribute attribute1 : AttributeDef1

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 19:31 GMT
  • Updated: Thu, 21 Nov 2024 18:26 GMT

P8 import textual notation may have errors

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    I suspect that there are two errors near the top of page 30 in the P8 namespace textual notation:
    1. Import Annotations::*; should be import ApprovalMetadata::*;
    import Annotations::* does not seem to serve a purpose here, and ApprovalMetadata elements would be needed to support the following code (when corrected).
    2. import NA::*[@Approved]; should be import NA::*[@Approval and approved]; or import NA::*[@approved]; or another version of this depending on interpretation of preceding commentary.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 19:21 GMT
  • Updated: Thu, 21 Nov 2024 18:24 GMT

TransitionUsage source and target properties do not support feature chains

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    According to the SysML abstract syntax (8.3.17.9 TransitionUsage), the source and target of a TransitionUsage must be ActionUsages. However, the textual notation (8.2.2.17.3 Transition Usages) allows sources and targets to be feature chains, which are parsed as a KerML Feature with FeatureChaining relationships to the chained Features, which are not ActionUsages.

  • Reported: SysML 2.0b2 — Sun, 16 Jun 2024 22:17 GMT
  • Updated: Thu, 21 Nov 2024 16:57 GMT

Multiple textual notation issues

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    Issue 1: the following notation found in the middle of the page has a comma instead of a semicolon for the declaration of an "in".

    action def B { in b1, out b2; }
    should be
    action def B { in b1; out b2; }

    Issue 2: The following notation found in the middle of the page has the wrong kind of closing bracket, followed by a semi-colon, following the declaration of an action definition. I.e., a closed parenthesis and semi-colon should be replaced by a closed curly bracket.

    action def B1 :> B { in b1; out b2; inout b3); // Redefinitions are implicit.
    should be
    action def B1 :> B { in b1; out b2; inout b3} // Redefinitions are implicit.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 19:43 GMT
  • Updated: Tue, 5 Nov 2024 16:34 GMT

Error in specification of library model UUIDs

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 9.1 Model Libraries Overview, in the last paragraph, it states that "the prefix https://www.omg.org/SysML/" should be used "when constructing the URL for a standard library package" as part of the generation of model library element UUIDs. The URL used here should instead be the standard OMG base URI https://www.omg.org/spec/SysML/ (which was what was actually used when generating the UUIDs in the normative XMI for the library models).

  • Reported: SysML 2.0b2 — Mon, 21 Oct 2024 18:56 GMT
  • Updated: Tue, 5 Nov 2024 00:03 GMT

Chapter 7.8.7.3.4 is empty

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The chapter 7.8.7.3.4 has no content.

  • Reported: SysML 2.0b2 — Wed, 16 Oct 2024 08:56 GMT
  • Updated: Tue, 5 Nov 2024 00:03 GMT

Chapter 7.8.7.3.3 FeatureDirectionKind is empty

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The chapter 7.8.7.3.3 has no content.

  • Reported: SysML 2.0b2 — Wed, 16 Oct 2024 08:56 GMT
  • Updated: Tue, 5 Nov 2024 00:02 GMT

Typo - "calculation" instead of "constraint"

  • Status: open  
  • Source: Arcfield ( Mr. Alex Whittier)
  • Summary:

    The phrase "As such, any directed usages declared in the body of a calculation definition or usage are considered to be owned parameters of the calculation."
    Should be corrected to say "As such, any directed usages declared in the body of a constraint definition or usage are considered to be owned parameters of the constraint."

  • Reported: SysML 2.0b2 — Mon, 7 Oct 2024 15:55 GMT
  • Updated: Tue, 5 Nov 2024 00:02 GMT

Actor should be mapped to a PartDefinition

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    An Actor is mapped to an ItemDefinition, but it should be a PartDefinition.

  • Reported: SysML 2.0b2 — Tue, 27 Aug 2024 07:00 GMT
  • Updated: Tue, 5 Nov 2024 00:02 GMT

SysMLv1Tov2.xmi contains temporary mapping classes

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The temporary mapping classes

    _InitialState_Mapping and _InitialStateMembership_Mapping

    should be removed from the SysMLv1Tov2.xmi.

    They are not part of the specification document.

  • Reported: SysML 2.0b2 — Wed, 21 Aug 2024 09:57 GMT
  • Updated: Tue, 5 Nov 2024 00:02 GMT

Weak check of input parameter in Helper::getScalarValueType

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Helper::getScalarValueType checks only the name of the input parameter and does not consider the fully qualified name to check if it is part of the SysML v1 library. Any DataType of name "UnlimitedNatural" is mapped to ScalarValues::Natural.

  • Reported: SysML 2.0b2 — Sat, 17 Aug 2024 11:54 GMT
  • Updated: Tue, 5 Nov 2024 00:02 GMT

Typo in definition of RenderingDefinition

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    "A RenderingDefinition is a kind of PartDefinition. As such, all the general semantic constraints for a PartDefinition (see 8.4.7.1) also apply to a ViewDefinition."

    Should be "RenderingDefinition" not "ViewDefinition"

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:14 GMT
  • Updated: Tue, 5 Nov 2024 00:02 GMT

Missing word in description of view usage

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    spec: "A view definition or usage is declared as a kind of part definition or usage (see 7.11.2 ), using the kind keyword view. A view usage must be defined by a single view."

    Should this be "single view definition"?

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:07 GMT
  • Updated: Tue, 5 Nov 2024 00:02 GMT

Misspelling in Table 16 / graphical and textual notation do not match

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    Issue 1: textual notation does not include a state definition, but the graphical notation does. Change to match.
    Issue 2: textual notation has an assumed spelling error, also causing a mismatch to graphical notation. In the following notation, "actio1" should likely be "action1".

    state state1

    { entry actio1; do action2; exit action3; }
  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 19:47 GMT
  • Updated: Tue, 5 Nov 2024 00:02 GMT

Error in textual notation on this page ("comment Comment 2")

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    There is an error in the last example on this page and in this section. One line calls out "comment Comment 2", which is likely intended to be "comment Comment2".
    Suggest change from original: comment Comment 2
    to: comment Comment2

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 18:48 GMT
  • Updated: Tue, 5 Nov 2024 00:02 GMT

Presuming missing word in sentence describing implicit annotation.

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    A sentence is missing a word indicating that an owned comment is implicitly about the element owning the namespace, if it is about nothing else:

    Original: "If the comment is an owned member of a namespace (see 7.5 ), then the explicit identification of annotated elements can be omitted, in which case the annotated element is implicitly the containing namespace."
    Should be:"...the annotated element is implicitly about the containing namespace."

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 18:31 GMT
  • Updated: Tue, 5 Nov 2024 00:02 GMT

Invalid use of "loop" as merge action name

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In two SysML textual notation example snippets, (1) clause 7.16.4 third snippet, (2) clause 7.16.5 last snippet, a merge node is named loop. This is not allowed as loop is a keyword.

    Suggest to rename the merge node to something like loopBegin, beginLoop or loopEntry.

  • Reported: SysML 2.0b2 — Wed, 31 Jul 2024 08:48 GMT
  • Updated: Tue, 5 Nov 2024 00:02 GMT

Replace Generic mapping classes by Initializers

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The coexistence of both the "GenericTo*_Mapping" classes and the Initializer classes generates a significant number of redundancies in the model, and make it harder to understand and to maintain.

    More specifically it makes the management of redefinitions much more complex with a very negative impact on the clarity of the specification.

    In order to fix that, all the GenericTo*_Mapping classes shall be removed and replaced par their Initializer class equivalent in an appropriate way.

  • Reported: SysML 2.0b2 — Sat, 15 Jun 2024 10:33 GMT
  • Updated: Tue, 5 Nov 2024 00:01 GMT

Editorial errors in constraints

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:
    1. In 8.3.6.4 Usage, the name of valideaUsageVariationIsAbstract should be validateUsageVariationIsAbstract.
  • Reported: SysML 2.0b2 — Wed, 22 May 2024 19:31 GMT
  • Updated: Tue, 5 Nov 2024 00:01 GMT

Helper::getScalarValueType operation is not robust enough

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The current algorithm crashes if the data type provided has no name defined or if the type is not defined

  • Reported: SysML 2.0a1 — Wed, 6 Dec 2023 16:53 GMT
  • Updated: Tue, 5 Nov 2024 00:01 GMT

Support SysML stereotypes applied to specialized metaclasses

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    If permitted, the transformation must also enable the mapping of SysML stereotypes that extend specialized metaclasses. For example, Satisfy based on Realization or Block based on Activity.

  • Reported: SysML 2.0b2 — Sat, 2 Nov 2024 10:03 GMT
  • Updated: Sat, 2 Nov 2024 10:03 GMT

Directed Composition

  • Status: open  
  • Source: GE Aerospace ( Chandramouli Jambunathan)
  • Summary:

    Please clarify what is the significance of Directed on the composition line. In the section 8.4.5, the directed line is used, whereas in other sections the direction is not used e.g. in section 11.3.1.1.1.
    Also I referenced in SysML 2.0 beta and I could see directed composition in one of the example. If there is no significance, will it be removed in SysML 2.0?

  • Reported: SysML 1.6 — Fri, 18 Oct 2024 12:31 GMT
  • Updated: Mon, 28 Oct 2024 16:54 GMT

Incosistency between notation tables and BNF related to package nodes

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    These issues reported by Dovile.ZIAUKIENE from Dassault.
    See 2 attachments.
    1. Name compartment of a package does not support guilements modifiers

    • a GBNF issue

    2. Unowned member alias notation

    • looks like a notation tables issue
  • Reported: SysML 2.0b2 — Fri, 25 Oct 2024 09:34 GMT
  • Updated: Fri, 25 Oct 2024 10:07 GMT
  • Attachments:

Graphical Notation does not specify else-condition for decision nodes

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The specification does not describe the else-condition for an outgoing succession of a decision node.

  • Reported: SysML 2.0b2 — Thu, 24 Oct 2024 18:35 GMT
  • Updated: Thu, 24 Oct 2024 18:35 GMT

Operation should not be mapped to perform action

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    An Operation should not be mapped to perform action, but an owned action.

  • Reported: SysML 2.0b2 — Fri, 26 Jul 2024 18:02 GMT
  • Updated: Fri, 18 Oct 2024 15:04 GMT
  • Attachments:

Incorrect GBNF production relationship-name

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In clause 8.2.3.5 graphical BNF production relationship-name has an incorrect body of comma-separated terminals.

    It should use the pipe symbol as a separator instead of comma, i.e.:

    relationship-name = 'defines' | 'defined by' | 'specializes' | 'specialized by' | 'connect to'
        | 'subsets' | 'subsetted by' | 'performs' | 'performed by' | 'allocated' | 'allocated to'
        | 'satisfy' | 'satisfied by'
    
  • Reported: SysML 2.0b2 — Wed, 16 Oct 2024 15:06 GMT
  • Updated: Wed, 16 Oct 2024 15:07 GMT

Inconsistent compartment labels

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    There are a number of compartments in graphical notation that have misleading labels. For example, a "require constraints" compartment may contain besides pure "require ConstraintUsage" also "require RequirementUsage" statements. Similary, a "assume constraints" compartment may contain besides "assume ConstraintUsage" also "assume RequirementUsage". A "require RequirementUsage" has the same semantics as a RequirementUsage contained (isComposite==true) by a containing RequirementUsage (see explanation in subclause 7.20.2).

    This is a wider problem that potentially also applies to other qualified compartment labels. The full list of affected compartment label qualifiers is:

    • assert
    • assume
    • exhibit
    • include use cases
    • perform
    • require
    • satisfy
    • verify

    In addition a mix of verb forms are used in compartment labels, some use the infinitive (satisfy requirements), some use third person singular form (satisfies). This is confusing and should be regularized in a consistent way, following a single rule.

  • Reported: SysML 2.0b2 — Wed, 16 Oct 2024 14:07 GMT
  • Updated: Wed, 16 Oct 2024 15:01 GMT

two haves

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Certain primitive data types have have specified extents of values

    two "have"s remove one

  • Reported: SysML 2.0b1 — Sun, 9 Jun 2024 17:37 GMT
  • Updated: Tue, 15 Oct 2024 23:07 GMT

Row headers not descriptive enough

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    To be more consistent across the section 7 tables in the specification, make the row headers of table 2 unique. From:
    Comment
    Comment
    Documentation
    Documentation

    to something like:

    Comment (stereotype hidden)
    Comment (stereotype, name shown)
    Documentation
    Documentation with Name

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 18:25 GMT
  • Updated: Tue, 15 Oct 2024 22:52 GMT

Differentiate Row Headers that say "Interface"

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    There are two row headers which says "Interface". One of these showed more of a general/compartment view (no declared connection), while another shows more of an interfaces view (including a declared connection). Please make the headers more clear regarding what the reader should find.

    E.g.:
    Interface Usage
    Interface with connection

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 19:37 GMT
  • Updated: Tue, 15 Oct 2024 22:11 GMT

Why does View Definition specialise Part Definition?

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    This seems an odd choice and at least needs more explanation of how the various features of part definitions, like ports, are used

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:04 GMT
  • Updated: Tue, 15 Oct 2024 21:57 GMT

Filter condition or view condition?

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The spec says "A view definition includes filter conditions on what kinds of elements can be included in a view" here but elsewhere in 7.25.1 says "view conditions". are these the same?

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:09 GMT
  • Updated: Tue, 15 Oct 2024 21:49 GMT

Is view the same as view usage?

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    For example, here "A view definition includes filter conditions on what kinds of elements can be included in a view". can this be interpreted as view usage?

    The term view is used a lot and I'm wondering whether it always means "view usage".

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:12 GMT
  • Updated: Tue, 15 Oct 2024 21:48 GMT

Examples of Nested View Usages

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Didn't know quite where to put this so filed against examples.

    There are no examples of nested view usages, either within view usages or view definitions. As such it is not clear how view usage hierarchies work – in particular, how do nested view usages in view definitions establish their set of exposed elements.

    I can't see anything in the syntax pages that shed any light on this either, and without more guidance I don't understand how to build view usage hierarchies.

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:20 GMT
  • Updated: Tue, 15 Oct 2024 21:44 GMT

Definition of view artifact

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In 7.25.2 the spec says "A view artifact is an individual view usage where the model content is rendered in a compartment of the view usage"
    View artifact is italicized so it is presumably significant but I don’t understand the sentence.

    In section 7.25.1 on page 137, view artifact is defined thus: “A view artifact is a rendering of information that addresses some aspect of a system or domain of
    interest of concern to one or more stakeholders”

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:45 GMT
  • Updated: Tue, 15 Oct 2024 21:44 GMT

Proxy connection points should be applicable more broadly then currently supported by the GBNF

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    Currently proxy connection points are supported by GBNF only for interconnection, action-flow, and sequence views. They should also be applicable in state-flow and possibly other views such as case and general views for additional usage nodes.

  • Reported: SysML 2.0b2 — Wed, 14 Aug 2024 09:31 GMT
  • Updated: Tue, 15 Oct 2024 21:42 GMT

Use Cases should have stakeholderParameters

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The UML specifies that a use case yields a

    "result that is of value for Actors or other stakeholders".

    In SysML 2 it now says

    "The objective is to yield an observable result that is of value to one or more of the actors".

    Stakeholders are no longer allowed. I think this would be necessary.

    There are use cases, whose result is not of value for any of the actors. For example a prison cell. The inmate interacts with the cell, observes the result, but is most likely not seeing a value in it. The result is of value for the society, which is not an actor of the prison cell.

    I suggest to add stakeholderParameter to the properties of UseCaseDefinition and UseCaseUsage.

    Additionally, it should be possible to identify the actors or stakeholders, for whom the result is of value. It is from their view, that the objective is to be described. This information whould guide the documentation of the objective.

  • Reported: SysML 2.0b2 — Tue, 17 Sep 2024 16:47 GMT
  • Updated: Tue, 15 Oct 2024 21:41 GMT

Comment_Mapping is missing a default rule

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Comment_Mapping is missing a default rule locale

  • Reported: SysML 2.0a1 — Thu, 2 Nov 2023 18:23 GMT
  • Updated: Sat, 12 Oct 2024 10:15 GMT

Mapping overview tables are wrong

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The Mappings overview tables presented in the specification document of the v1 to v2 transformations includes many consistency errors with regard to the mappings actually specified in other parts of the document. This in particular true for the overview tables in the "UML4SYSML" part.

    The content of those tables is generated, so there are obviously issues in the corresponding algorithm.

    Note that, since, the specification of the transformation itself is not the point here, and then will not be modified by the resolution, this issue can be considered editorial.

  • Reported: SysML 2.0b2 — Thu, 10 Oct 2024 15:47 GMT
  • Updated: Thu, 10 Oct 2024 15:47 GMT

Reuse of KerML textual notation productions in the SysML grammar


Transformation does not cover the deprecated elements FlowSpecification

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Although deprecated, FlowSpecifications are still part of SysML v1 and there should be a defined mapping for the element.

  • Reported: SysML 2.0b2 — Sat, 28 Sep 2024 06:42 GMT
  • Updated: Sat, 28 Sep 2024 06:42 GMT

Transformation does not cover the deprecated elements FlowPort

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Although deprecated, FlowPorts are still part of SysML v1 and there should be a defined mapping for the element.

  • Reported: SysML 2.0b2 — Thu, 26 Sep 2024 10:48 GMT
  • Updated: Thu, 26 Sep 2024 10:48 GMT

Representative notation example for allocation confusing/wrong?

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    Table 13 shows an example of a composite allocation. Part allocation owns an allocation between performed actions.
    The graphical notation shows an allocation edge between perform edges, owned by an allocation edge between parts.
    It is for sure confusing, and not sure if the textual notation that says

     allocate part1.action1 to part2.action2; 
    

    is correct, provided that action1 and action2 are performed but not owned actions.
    Even if technically correct, it would be better to present a clearer and simpler example of composite allocations.

  • Reported: SysML 2.0b2 — Mon, 23 Sep 2024 08:54 GMT
  • Updated: Mon, 23 Sep 2024 09:36 GMT

Transformation of UML4SysML::State does not consider entry, do, and exit behavior

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation ignores the entry, do, and exit behavior of a state.

  • Reported: SysML 2.0b1 — Wed, 27 Sep 2023 21:38 GMT
  • Updated: Wed, 18 Sep 2024 22:49 GMT

Inconsistent use of guillemets in graphical notation for metamodel aspects


state-flow GBNF issues

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    1. The GBNF production for a transition is wrong, it does not account for nodes which are not states (e.g. control nodes)

    2. The production for states actions compartment is incorrect, the compartment name is currently named "states" while it should be named "state actions".

  • Reported: SysML 2.0b2 — Tue, 17 Sep 2024 09:57 GMT
  • Updated: Tue, 17 Sep 2024 09:57 GMT

Name expressions in GBNF are too constraining

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    Name textual expressions in GBNF for definition and usage names,exclude various characteristics such as specializations, redefinitions multiplicity etc. Name expressions denoted definition-name-with-alias and usage-name-with-alias in the graphical BNF should reuse the textual syntax productions DefinitionDeclaration and UsageDeclaration.

  • Reported: SysML 2.0b2 — Mon, 24 Jun 2024 13:59 GMT
  • Updated: Sun, 15 Sep 2024 10:08 GMT

Source and target on binary ConnectionDefinition symbol missing


Semantic constraints missing for shorthand succession notation

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The following cases in the textual notation allow "shorthand" then notations for SuccessionAsUsages:

    1. In 8.2.2.9.3 Occurrence Successions, the production SourceSuccession creates a SuccessionAsUsage that has a source end with no related feature and no target end.
    2. In 8.2.2.16.7 Action Successions, the production TargetSuccession creates a SuccessionAsUsage that has a source end as in SourceSuccession, but it has a full ConnectorEndMember for its target end, including an explicit related element.

    In both cases, the intent is that the implied related feature of the source end of the SuccessionAsUsage is a feature lexically previous to the declaration of the SuccessionAsUsage. In the first case, the implied related feature for the target end of the SuccessionAsUsage is a feature lexically following the SuccessionAsUsage. However, there are no semantic constraints given in 8.3.13.8 SuccessionAsUsage to enforce these implied relationships.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 17:12 GMT
  • Updated: Fri, 13 Sep 2024 19:09 GMT

Structured actions not properly covered by GBNF and notation tables


Semantics of a conditional succession using "else" are missing

  • Key: SYSML2_-41
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.16.5 Conditional Successions, in the second paragraph, it states:

    Further, the keyword else may be used in place of a guard expression to indicate a succession to be taken if the guards evaluate to false on all of an immediately preceding set of conditional successions.

    In 8.2.2.16.7, a conditional succession with the else keyword is parsed as a TransitionUsage that simply does not have a guard condition:

    DefaultTargetSuccession : TransitionUsage =
        'else' ownedRelationship += TransitionSuccessionMember
    

    However, the semantics of such a TransitionUsage would seem to be that it can be taken unconditionally, not that it can only be taken if preceding conditional successions have guards that evaluate to false. The else case is not mentioned at all in 8.4.12.3 Decision Transition Usages, which covers the semantics of conditional successions.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 22:10 GMT
  • Updated: Tue, 10 Sep 2024 16:35 GMT

Mapping of ObjectFlows with DecisionNodes

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of ObjectFlow in combination with DecisionNodes including the decisionInput is not covered yet by the transformation.

  • Reported: SysML 2.0b1 — Mon, 24 Jul 2023 14:47 GMT
  • Updated: Tue, 10 Sep 2024 16:35 GMT

Specification lacks precision in multiple sentences that begin with the word 'however'

  • Status: open  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    There are 94 uses of the word 'however' in the specification, usually starting a sentence. In many cases, the word injects unnecessary text that further confuses and obfuscates the intent. In most cases, what follows is not an exception, rather just another option of the language. In many cases the word can be replaced with ‘if’ or ‘when’ but I also found many cases where a rewrite is necessary.

    Here are the first 45ish specific examples and rewrites. I stopped at page 119 as there is enough evidence to show simple rewriting of the offending test can greatly improved the text. I have also added comments to point to the issue and any further wordsmithing that seems to be required.
    This seems like a minor or even a style issue, ‘however’ the point of this issue is that the use of the word muddles the descriptive intent of the text when it should be precise as possible.

    2. conformance:
    Original:
    However, a tool demonstrating Concrete Syntax Conformance need not represent a model internally in exactly the form modeled for the abstract syntax in this specification.
    Replacement:
    A tool demonstrating Concrete Syntax Conformance need not represent a model internally in exactly the form modeled for the abstract syntax in this specification.

    6.2 Document Organization
    Original:
    However, this clause does not cover details of the Kernel metamodel, which are included by normative reference to the KerML specification [KerML].
    Replacement:
    This clause does not cover details of the Kernel metamodel, which are included by normative reference to the KerML specification [KerML].
    Comment:
    Optionally delete the sentence as it is already assumed that KerML is where the reader finds the details of the details.

    6.3 Acknowlegements
    Original:
    However, work on the specification was also supported by over 200 people in over 80 organizations that participated in the SysML v2 Submission Team (SST), by contributing use cases, providing critical review and comment, and validating the language design.
    Replacement:
    Over 200 people from over 80 organizations participated in the SysML v2 Submission Team (SST), contributing to the specifics and providing reviews and comments.

    7.2.1 Elements and Relationships Overview
    Original:
    However, in some cases, additional shapes may be attached to relationship lines in order to present additional information.
    Replacement:
    Additional shapes may be attached to relationship lines in order to present additional information.

    7.2.2 Elements
    Original:
    Various specific kinds of model elements in SysML are described in subsequent subclauses. However, there are certain concepts that apply to all model elements.
    eplacement:
    Key model elements in SysML are described in subsequent subclauses. Some of the concepts apply to all model elements.
    comments: The opening statement like this are without value to the spec.

    Original:
    The SysML notation does not have any provision for specifying element or alias IDs, since these are expected to be managed by the underlying modeling tooling. Instead, an element can be given a name and/or a short name, and it can also have any number of alias names relative to one or more namespaces (see 7.5).
    Replacement:
    The SysML notation does not have any provision for specifying element or alias IDs because these are expected to be managed by the underlying modeling tooling. Instead of using an ID, an element has a given name and/or a short name that can also have any number of alias names relative to one or more namespaces (see 7.5).

    Original:
    However, unless at least one of these is given, it is not possible to reference the element using the textual notation (though it is still possible to show it in relationships on graphical diagrams).
    Replacement:
    It is not possible to reference the element using the textual notation unless a name or short name is given, though it is still possible to show it in relationships on graphical diagrams.

    Original:
    However, a reserved word may not be used as a name, even though it has the form of a basic name (see 8.2.2.1.2 for the list of the reserved words in SysML).
    Replacement:
    A reserved word may not be used as a name (see 8.2.2.1.2 for the list of the reserved words in SysML).

    Original:
    However, these characters may be included as part of the name itself through use of an escape sequence.
    Replacement:
    Non-printable characters may be included as part of the name itself through use of an escape sequence.

    7.4.2 Comments and Documentation
    Original:
    However, marked up "rich text" for a comment is stored in the comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules referenced above.
    Replacement:
    Marked up "rich text" for a comment is stored in the comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules referenced above.
    Original:
    However, for any other language than "sysml", the SysML specification does not define how the body text is to be semantically interpreted as part of the model being represented
    Replacement:
    For any other language than "sysml", the SysML specification does not define how the body text is to be semantically interpreted as part of the model being represented

    7.5.4 Import Filtering
    Original:
    comments. Namespaces other than packages cannot have filter conditions (except for their special use in view definitions and usages – see 7.25). However, any kind of namespaces may have filtered imports.
    Replacement:
    Namespaces other than packages cannot have filter conditions, except for their special use in view definitions and usages – see 7.25. All kinds of namespaces may have filtered imports.
    comments: It is strange that this is a note as these are very specific semantics rather than an aside as would be described in a note.

    7.6.1 Definition and Usage Overview
    Original:
    However, truck can instead redefine fuel to restrict its definition to DieselFuel, a subclassification of Fuel.
    Replacement:
    Alternatively the Truck could redefine fuel to restrict its definition to DieselFuel, a subclassification of Fuel.
    comments: The paragraphs are rather confusing without a textual language or graphical examples. At least you could refer to an example in the annex. It is also odd to get into alternatives without an example of the alternative.
    Original:
    However, it is expected that if Vehicle is baselined in a configuration management tool, then a change to Vehicle is a new revision, and it is up to the modelers to determine whether to retain the previous version of Vehicle or move to the next revision.
    Replacement:
    If Vehicle is baselined in a configuration management tool, then a change to Vehicle is a new revision, and it is up to the modelers to determine whether to retain the previous version of Vehicle or move to the next revision.

    7.6.3 Usages
    Original:
    However, a tighter default of [1..1] is implicitly declared for the usage if all of the following conditions hold
    Replacement:
    A tighter default of [1..1] is implicitly declared for the usage if all of the following conditions are true:
    Comment: Is there a reference to where this is described in the standard?

    7.6.4 Reference Usages
    Original:
    However, a reference usage is always, by definition, referential. A reference usage is otherwise declared like any other usage, as given above.
    Replacement:
    Reference usages are always referential. A reference usage is declared like any other usage, as given above.
    Comment:
    Once the ‘however’ was removed, the changes to the following sentence is also required to improve the explanation of the concept.

    7.6.5 Effective Names
    Original:
    However, if neither a name or a short name are given in the declaration of a usage with an owned redefinition, then its effective name and short name are implicitly determined by the name and short name of the redefining usage of its first owned redefinition (which may itself be an implicit name, if the redefined usage is itself a redefining usage).
    Replacement:
    When neither a name or a short name are given in the declaration of a usage with an owned redefinition, then its effective name and short name are implicitly determined by the name and short name of the redefining usage of its first owned redefinition (which may itself be an implicit name, if the redefined usage is itself a redefining usage).
    Comment:
    The use of ‘however’ muddled the original explanation. Imagine Java or some other computer language with ‘however’ as a key word.

    7.6.6 Feature Chains
    Original:
    However, their use is particularly important when specifying the related features of a connection usage that are more deeply nested than the connection usage itself (see 7.13). (See also [KerML, 7.3.4.6].)
    Replacement:
    Feature chains are particularly important when specifying the related features of a connection usage that are more deeply nested than the connection usage itself (see 7.13). (See also [KerML, 7.3.4.6].)

    7.6.8 Implicit Specialization
    Comment:
    This may be a good use of however, but look at it anyway and see if it can be avoided,

    7.7.1 Attributes Overview
    Original:
    However, the owner of an attribute usage may be an occurrence definition or usage (or a specialized kind of occurrence, such as an item, part or action). In this case, the value of the attribute usage may vary over the lifetime of its owning occurrence, in the sense that it can have different values at different points in time, reflecting the changing condition of the occurrence over time.
    Replacement:
    The owner of an attribute usage may be an occurrence definition or usage (or a specialized kind of occurrence, such as an item, part or action). When the attribute owner is a usage is an occurrence definition or usage, the value of the attribute usage may vary over the lifetime of its owning occurrence, in the sense that it can have different values at different points in time, reflecting the changing condition of the occurrence over time.
    Comment:
    This is still confusing. It again screams out for a textual/graphical language example.

    7.8.1 Enumerations Overview
    Original:
    However, if the enumeration definition specializes an attribute definition with nested usages, then those nested usages will be inherited by the enumeration definition, and they may be bound to specific values within each enumerated value of the enumeration definition.
    Replacement:
    If the enumeration definition specializes an attribute definition with nested usages, then those nested usages will be inherited by the enumeration definition, and they may be bound to specific values within each enumerated value of the enumeration definition.
    Original:
    The enumerated values defined in an enumeration definition, however, would add to the set of enumerated values allowed by any enumeration definition it specialized, which is inconsistent with the semantics of specialization.
    Replacement:
    The reason for this constraint is that enumerated values defined in an enumeration definition would add to the set of enumerated values, which is inconsistent with the semantics of specialization.
    Comment:
    This is a definite improvement over the original text, which is very confusing. It is very strange that given you are creating a new language to get around issues with UML you have not fixed this glaring issue of the inability to specialize enumerations.

    7.8.2 Enumeration Definitions and Usages
    Original:
    However, an enumeration definition must not subclassify another enumeration definition. An enumeration usage is declared as described in 7.6.3, using the kind keyword enum.
    Replacement:
    An enumeration definition must not subclassify another enumeration definition. An enumeration usage is declared as described in 7.6.3, using the kind keyword enum.
    Comment:
    This paragraph seems like a repeat of the previous change request. Suggest choosing one and deleting the other to reduce confusion and need to maintain both statements.

    7.9.1 Occurrences Overview
    Original:
    However, if a composite suboccurrence is removed from its containing occurrence before the end of the lifetime of the containing occurrence, then the former suboccurrence can continue to exist.
    Replacement:
    If a composite suboccurrence is removed from its containing occurrence before the end of the lifetime of the containing occurrence, then the former suboccurrence can continue to exist.
    Original:
    However, if the wheel is removed before the car is destroyed, then the wheel can continue to exist even after the car is destroyed. (See also 7.6 on referential and composite usages.)
    Replacement:
    If the wheel is removed before the car is destroyed, then the wheel can continue to exist even after the car is destroyed. (See also 7.6 on referential and composite usages.)

    Original:
    However, it could also be realized as the start and end of an explicitly modeled flow connection (see 7.13 on flow connections and messages).
    Replacement:
    These events can also be realized as a modeled flow connection (see 7.13 on flow connections and messages).
    Comment:
    This is another statement that becomes more muddled when treating it as an exception when in fact this is not an exeption, but just realkized by another possible construct.

    7.9.3 Time Slices and Snapshots
    Original:
    However, if such an occurrence usage has no explicitly declared definition, but is declared in the body of an occurrence definition, then it is considered to implicitly represent a portion of instances of the containing occurrence definition.
    Replacement:
    If an occurrence usage has no explicitly declared definition, but is declared in the body of an occurrence definition, then it is considered to implicitly represent a portion of instances of the containing occurrence definition.

    7.10.1 Items Overview
    Original:
    However, once the engine assembly is completed, the engine can be considered to be a part that may be installed into a car, where it is expected to perform the action providing power to propel the car. But later it may be removed from the car and again be considered only an inactive item in a junkyard.
    Replacement:
    Once the engine assembly is completed (e.g. the engine has completed manufacturing and exists as a whole), the engine can be considered to be a part that may be installed into a car, where it is expected to perform the action providing power to propel the car. Later in time, the engine may be removed from the car and again be considered only an inactive item in a junkyard.
    Comment:
    This is a weird example. There are many parts to an engine that are added and removed. For example, spark plugs. A spark plug could be a better example as these are assembled of pieces that are not individually replaceable and junked as a whole.

    7.13.1 Connections Overview
    Original:
    However, the values of connection ends (i.e., the things that are actually connected) do not change over time (though they can potentially be occurrences that themselves have features whose values change over time).
    Replacement:
    The values of connection ends (i.e., the things that are actually connected) do not change over time (though they can potentially be occurrences that themselves have features whose values change over time).
    Original:
    However, a message does not specify how the payload is to be obtained from the source or delivered to the target.
    Replacement:
    A message does not specify how the payload is to be obtained from the source or delivered to the target.
    Comment:
    So how do we specify how it obtained? This needs further clarification.

    7.13.2 Connection Definitions and Usages
    Original:
    However, if it declares any owned end features, then each of these must redefine an end feature of the general connection definition, in order, up to the number of end features of the general connection definition.
    Replacement:
    If a connection definition declares any owned end features, then each of these must redefine an end feature of the general connection definition, in order, up to the number of end features of the general connection definition.

    7.13.4 Feature Values
    Original:
    However, for a default, bound feature value, the symbol = may be elided.
    Replacement:
    Optionally. a default, bound feature value, the symbol = may be elided (as shown in the default ‘mass’ in the following example).
    Comment:
    This a capricious and confusing option. Please choose one and delete the other. This adds a complication to the reading of the language that is unnecessary.

    7.13.6 Flow Connection Usages and Messages
    Original:
    A streaming flow is declared similarly to a message, but with the kind keyword flow. However, instead of identifying the source and target features of the flow, such a flow declaration must identify (after the keyword from) the output feature of the source from which the flow receives its payload and (after the keyword to) the input feature of the target to which the flow delivers the payload.
    Replacement:
    A streaming flow has the kind keyword flow and must identify, after the keyword from, the output feature of the source from which the flow receives its payload and, after the keyword to, the input feature of the target to which the flow delivers the payload.
    Comment:
    The use of ‘however’ has created language of no value. The streaming flow is totally different than a message in its form. The rewrite hopefully fixes the first mistake, however the sentence is still rather obtuse and still needs some wordsmithing.

    7.14.2 Interface Definitions and Usages
    Original:
    However, if the declaration part of an interface usage is empty, then the interface keyword is still included, but the connect keyword may be omitted.
    Replacement:
    If the declaration part of an interface usage is empty, then the connect keyword may be omitted.

    7.16.1 Actions Overview
    Original:
    However, if the owner of the perform action usage is an occurrence, then the referenced action performance must be carried out entirely within the lifetime of the performing occurrence.
    Replacement:
    If the owner of the perform action usage is an occurrence, then the referenced action performance must be carried out entirely within the lifetime of the performing occurrence.

    Original:
    However, a succession between action usages may, additionally, have a guard condition, represented as a Boolean expression (see 7.18).
    Replacement:
    A succession between action usages may have an additional guard condition, represented as a Boolean expression (see 7.18).

    7.16.5 Conditional Successions
    Original:
    However, the target of a conditional succession must be specified as a qualified name or feature chain and cannot be a full action usage declaration, even when the shorthand notation is used.
    Replacement:
    The target of a conditional succession must be specified as a qualified name or feature chain and cannot be a full action usage declaration, even when the shorthand notation is used.

    7.17.1 States Overview
    Original:
    However, if the owner of the exhibit state usage is an occurrence, then the referenced state performance must be carried out entirely within the lifetime of the performing occurrence.
    Replacement:
    If the owner of the exhibit state usage is an occurrence, then the referenced state performance must be carried out entirely within the lifetime of the performing occurrence.

    7.17.2 State Definitions and Usages
    Original:
    However, if the keyword parallel is added to a state definition or usage, just before the body part, then the containing state definition or usage becomes a parallel state, and its contained state usages can be performed in parallel. (However, no transitions are allowed between concurrent states; see 7.17.3.)
    Replacement:
    If the keyword parallel is added to a state definition or usage, just before the body part, then the containing state definition or usage becomes a parallel state, and its contained state usages can be performed in parallel. In this case, no transitions are allowed between concurrent states; see 7.17.3.

    Original:
    (However, no transitions are allowed between concurrent states; see 7.17.3.)
    Replacement:
    No transitions are allowed between concurrent states; see 7.17.3.

    7.19.1 Constraints Overview
    Original:
    In general, a constraint may be satisfied sometimes and violated other times. However, an assert constraint usage asserts that the result of a given constraint must be always true at all times.
    Replacement:
    When an assert constraint usage asserts exists, the result of that constraint must be always true at all times. This is compared to a simple constraint may be satisfied sometimes and violated other times.
    Comment:
    This another example of the ‘however’ causing a confusion in the semantics. The spec should say what is true before saying what is true is an exception. In this case, there is no exception, just a differing kind of constraint than one already discussed.

  • Reported: SysML 2.0b2 — Thu, 15 Aug 2024 23:57 GMT
  • Updated: Thu, 5 Sep 2024 20:56 GMT

Map UML4SysML::Constraint to ConstraintUsage only

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation maps a constraint to a constraint definition and a constraint usage. The ConstraintDefinition should be defined as ConstraintUsage and the previously generated ConstraintUsage can be removed.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 07:22 GMT
  • Updated: Mon, 2 Sep 2024 22:18 GMT

Transformation does not cover UML4SysML::ProfileApplication

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of a ProfileApplication is not covered by the transformation.

  • Reported: SysML 2.0b2 — Sat, 31 Aug 2024 06:11 GMT
  • Updated: Sat, 31 Aug 2024 06:11 GMT

Transformation does not cover SysMLv1::ConnectorProperty

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    ConnectorProperty is deprecated but still part of SysML v1.7. So, the transformation should provide a mapping for it.

  • Reported: SysML 2.0b2 — Fri, 30 Aug 2024 16:05 GMT
  • Updated: Fri, 30 Aug 2024 16:05 GMT

OccurrenceUsage missing portioningFeature

  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.4.5.2 (Occurrence Usages) says

    If an OccurrenceUsage has a non-null portionKind, then it is also required to have a portioningFeature with the same portionKind. The following semantic constraints apply to a PortioningFeature:
    ...

    and the code example at the end of 8.4.5.2 has comments identifying some features as "Portioning", with text below it referring to portioningFeature

    However, portioningFeature doesn't appear in Figure 12 (Occurrence Definition and Usage) or anywhere else in the document.

  • Reported: SysML 2.0b1 — Thu, 2 Nov 2023 14:26 GMT
  • Updated: Sun, 25 Aug 2024 14:53 GMT

ObjectFlow with guards outgoing from DecisionNodes are not mapped correctly

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    An object flow with a guard is mapped to a conditional succession and a succession flow. Conditional succession targets the succession flow. Both have the decision node as the source element. However, only one succession outgoing decision node can be taken.

    Change the mapping to:

    first sourceNode if guardCondition.result then objectFlow {
      constraint guardCondition {
        bind result = guardCondition.result;
        calc guardCondition {
          language "English"
          /*
           * guard says ok
           */
        }
    }
    flow objectFlow from sourceNode to targetNode;
    first source then target;
    

    The source and target of the flow succession are parameters (the target elements of the corresponding SysML v1 ObjectNodes). The source and target of the succession are the owner of the object nodes. Exceptional cases are control nodes.

  • Reported: SysML 2.0b2 — Sat, 24 Aug 2024 07:11 GMT
  • Updated: Sat, 24 Aug 2024 14:48 GMT

CallBehaviorAction mapping does not consider the pins

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The pins of a CallBehaviorAction are not mapped. Although the parameters of the action usage are inherited from the action definition, the pins must be mapped since they can have different names than the behavior parameters, different types, etc.

  • Reported: SysML 2.0b2 — Thu, 22 Aug 2024 06:56 GMT
  • Updated: Thu, 22 Aug 2024 06:56 GMT

Mapping of ObjectFlow should not consider the type of the objects that flow

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    An ObjectFlow is mapped to a succession flow including the specification of the payload: "...of <type>".

    The type of the flowing objects cannot be precisely determined (for example, if the source of the object flow is a merge node). Additionally, the ObjectFlow in SysML v1 also has no relationship to the type of the flowing objects.

  • Reported: SysML 2.0b2 — Wed, 21 Aug 2024 16:57 GMT
  • Updated: Wed, 21 Aug 2024 16:57 GMT

ActivityParameterNodes should be mapped

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Currently, ActivityParameterNodes are not mapped to v2. Instead, only the Parameter of the Activity is mapped to a parameter of the ActionDefinition. However, it is not possible to connect the parameter by a succession flow with a parameter of an action usage, for example.

    Instead, map an ActivityParameterNode to an ActionUsage with corresponding input and output parameters and bind the ActionDefinition parameter with the corresponding ActionUsage parameter. For example:

    action def {
      in inputParameter: Integer;
      bind inputParameter = __inputParameter.outbound;
      action __inputParameter {
        in ref outbound;
        out ref inbound: Integer;
      }
    }
    
  • Reported: SysML 2.0b2 — Wed, 21 Aug 2024 15:48 GMT
  • Updated: Wed, 21 Aug 2024 15:48 GMT

ConnectionPointReference_Mapping should create a Redefinition

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A ConnectionPointReference is mapped to a StateUsage. In addition, the state usage shoud redefine the corresponding pseudostate.

  • Reported: SysML 2.0b2 — Tue, 20 Aug 2024 06:09 GMT
  • Updated: Tue, 20 Aug 2024 06:09 GMT

Typos in graphical metadata representative notation

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.26.1, Table 25, two typos appear in examples "Metadata" and "Metadata Compartment". In the graphical notation for both, AttributeDef1 should be replaced with MetadataDef1, in line with the textual notation.

  • Reported: SysML 2.0b2 — Fri, 2 Aug 2024 19:27 GMT
  • Updated: Tue, 20 Aug 2024 00:22 GMT
  • Attachments:

RICOAOutputPin_Mapping should specialized Pin_Mapping

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping class RICOAOutputPin_Mapping has no general mappings but should have Pin_Mapping

  • Reported: SysML 2.0b2 — Fri, 19 Jul 2024 17:06 GMT
  • Updated: Tue, 20 Aug 2024 00:22 GMT

Inconsistent graphical notation for view frame


Mapping of State does not consider orthogonal states

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A state with several regions should be mapped to a parallel state.

  • Reported: SysML 2.0b2 — Thu, 30 May 2024 16:07 GMT
  • Updated: Tue, 20 Aug 2024 00:22 GMT

InitialState is mapped to StateUsage, but should be an empty ActionUsage

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The InitialState should be mapped to an empty ActionUsage owned by a StateSubactionMembership relationship.

  • Reported: SysML 2.0b2 — Tue, 21 May 2024 05:40 GMT
  • Updated: Tue, 20 Aug 2024 00:22 GMT

InterfaceBlock mapped to PortDefinition, but ConjugatedPortDefinition is not generated

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A SysMLv1::InterfaceBlock is mapped to a SysMLv2::PortDefinition, but the owned SysMLv2::ConjugatedPortDefinition is not generated.

  • Reported: SysML 2.0b2 — Fri, 10 May 2024 16:26 GMT
  • Updated: Tue, 20 Aug 2024 00:22 GMT

Mapping of ObjectFlows with JoinNodes

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of ObjectFlow in combination with JoinNodes is not covered yet by the transformation.

  • Reported: SysML 2.0b1 — Mon, 24 Jul 2023 14:30 GMT
  • Updated: Tue, 20 Aug 2024 00:22 GMT

Mapping of ObjectFlows with ForkNodes

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In SysML v1, an output value of an action that is an input value of more than one action, is often modeled by an object flow and fork node which create object tokens pointing to the value.

    The mapping of ObjectFlow in combination with ForkNodes is not covered yet by the transformation.

  • Reported: SysML 2.0b1 — Mon, 24 Jul 2023 13:16 GMT
  • Updated: Tue, 20 Aug 2024 00:22 GMT
  • Attachments:

Missing graphical notation for n-ary connection def and usage

  • Key: SYSML2_-23
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    BNF production is missing for n-ary connection def and connection usage as in examples shown in the representative notation table in 7.13.1 Connections Overview. Must be fixed in 8.2.3.13.

    Check all examples of n-ary connections (including causation and requirements derivation) to replace arrowheads with bolded end names. Connections of 3 or more ends only have target ends, no source ends, see KerML spec clause 7.4.5.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 12:19 GMT
  • Updated: Tue, 20 Aug 2024 00:22 GMT

Chapter Trigger_Mapping is empty

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The chapter 7.7.5.3.7 Trigger_Mapping is empty.

  • Reported: SysML 2.0b2 — Mon, 19 Aug 2024 14:33 GMT
  • Updated: Mon, 19 Aug 2024 14:33 GMT

Mapping for UML4SysML::CallEvent and UML4SysML::AcceptCallAction are missing

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The specification incorrectly mentions that CallEvent is not part of the SysML v1.7 specification, which is why no transformation is offered for either CallEvent or AcceptCallAction.

    According to Table 4.2 about the included UML metaclasses in the SysML v1.7 specification, CallEvent and AcceptCallAction are part of SysML v1.7. A mapping must be specified accordingly.

  • Reported: SysML 2.0b2 — Mon, 19 Aug 2024 11:04 GMT
  • Updated: Mon, 19 Aug 2024 11:04 GMT

Need to add terminate action node to action flow and state flow views

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    Terminate node is about to be introduced to the language, need to assure it is covered by the graphical bnf

  • Reported: SysML 2.0b2 — Wed, 14 Aug 2024 09:18 GMT
  • Updated: Wed, 14 Aug 2024 09:18 GMT

send and accept actions name compartment productions inconsistent

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    name compartment productions for send and accept actions are not reusing the textual productions for usage declarations and misaligned with the rest of the graphical BNF

  • Reported: SysML 2.0b2 — Wed, 14 Aug 2024 08:00 GMT
  • Updated: Wed, 14 Aug 2024 08:00 GMT

Mapping of UseCase does not consider more than one subject

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A use case can have many subjects. The transformation considers only one. If there are more subjects specified, it only takes the first one in the list.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 15:52 GMT
  • Updated: Sat, 10 Aug 2024 15:52 GMT

Property typed by an Actor should be mapped to a PartUsage

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not consider the mapping of a property typed by an Actor. It should be mapped to a usage defined by the target element of the Actor.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 07:33 GMT
  • Updated: Sat, 10 Aug 2024 07:33 GMT

Mapping of UML4SysML::Constraint: Bind the result parameter

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping creates a calc inside a constraint definition. The result parameter of the calc should be bound to the result parameter of the constraint.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 07:24 GMT
  • Updated: Sat, 10 Aug 2024 07:24 GMT

Flows cannot connect ControlNodes

  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Armonas)
  • Summary:

    Allow flows to connect ControlNodes because, currently, this limitation makes it impossible to pass payloads from one ActionUsage to another ActionUsage if a DecisionNode is in between.
    This issue is a showstopper for the UAF v2 development.

  • Reported: SysML 2.0b2 — Mon, 29 Jul 2024 13:03 GMT
  • Updated: Tue, 6 Aug 2024 05:41 GMT

Graphical notation action names need to be aligned

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    Currently two conventions are used for graphical action names e.g. send action vs. assign, so issue is whether the action postfix is used or not. Note that the textual notation does not use the postfix action. Regardless, this needs to be aligned along the GBNF and representative notation tables.

  • Reported: SysML 2.0b2 — Mon, 29 Jul 2024 07:30 GMT
  • Updated: Tue, 6 Aug 2024 05:37 GMT

Update language description and concrete syntax related to imports

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The resolutions by the KerML FTF to the following issues make restrictions to the functionality of imports in KerML and hence, by reference, in SysML, also:

    • KERML_-73 Disallow public imports at root level
    • KERML_-74 Make imports private by default
    • KERML_-75 Restrict the functionality of recursive import

    The discussion of imports in Clause 7 Language Description need to be updated to reflect these changes (particularly in 7.5.3 Imports). In addition, adopting the requirement to always show visibility of imports in the concrete syntax, consistent with KERML_-74, requires changes in

    • 8.2.2.5.1 Packages (textual notation)
    • 8.2.3.5 Namespaces and Packages Graphical Notation
    • 8.3.5 Namespaces and Packages Abstract Syntax, Figure 5 Namespaces
  • Reported: SysML 2.0b2 — Sun, 26 May 2024 21:27 GMT
  • Updated: Fri, 2 Aug 2024 05:18 GMT
  • Attachments:

There is no need for AnalysisAction

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The Systems Library model AnalysisCases includes a declaration for AnalysisAction as a specialization of Actions::Action. In the abstract syntax, ActionDefinition::analysisSteps and ActionUsage::analysisSteps are derived to be the subactions that are AnalysisActions.

    However, no special semantics are specified for AnalysisActions and no special concrete syntax for defining analysisSteps. So they are never used in practice within user models of analysis caes, so they seem pointless.

  • Reported: SysML 2.0b2 — Wed, 1 May 2024 22:44 GMT
  • Updated: Fri, 2 Aug 2024 05:11 GMT

Mappings from the "Common" package

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    There is a bunch of mapping defined in the "GenericMappings::Common" package. However, they are not used very much in by other mappings while multiple more specific versions of them have been created without a good rationale. Defining reusable mappings is a good idea and could greatly simplify the specification of the transformation by reducing the number of classes it contains... Assuming they are actually used!

    I do think it deserves a global review and optimization.

    Note that some of those "common" mappings shall be fixed with regard to either their source type, the body condition of some of their rules or both.

  • Reported: SysML 2.0b2 — Thu, 1 Aug 2024 16:37 GMT
  • Updated: Thu, 1 Aug 2024 16:37 GMT

Type of the ReferenceUsage created for the client of a Satisfy relationship

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    In case the client of the client of the Satisfy relationship is a block, a ReferenceUsage will have to be generated. The type of that ReferenceUsage shall be the Definition corresponding to that block.

  • Reported: SysML 2.0b2 — Thu, 1 Aug 2024 16:07 GMT
  • Updated: Thu, 1 Aug 2024 16:07 GMT

ReferenceUsage creation in case of a Satisfy relationship transformation

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    It is necessary to create a reference usage if and only if the client of the Satisfy relationship is a block. Instead, the current version of the Satisfy_Mapping create it if and only if the client is a property

  • Reported: SysML 2.0b2 — Thu, 1 Aug 2024 16:01 GMT
  • Updated: Thu, 1 Aug 2024 16:01 GMT

Graphical BNF mapping to abstract syntax is missing

  • Key: SYSML2_-29
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    A mapping of the Graphical BNF productions to the abstract syntax has not been addressed.

    If no specific proposal is considered by the FTF, it may be worth including some discussion notes in the spec in place of any detailed mapping.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 15:09 GMT
  • Updated: Wed, 31 Jul 2024 16:58 GMT

ObjectFlow mappings limited to non-streaming parameters

  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 7.7.3.3.17 (CommonActivityEdgeSuccessionAsUsage_Mapping), Description says

    The mapping class provides a common mapping of a UML4SysML::ActivityEdge to a SysMLv2 SucessionAsUsage.

    Clause 7.7.3.3.35 (ObjectFlow_Mapping), Description, says

    A UML4SysML::ObjectFlowFlow without a guard condition is mapped to a SysMLv2SuccessionFlowConnectionUsage.

    This seems to say all ActivityEdges, including ObjectFlows are mapped to v2 Successions, is that right? This prevents mapping of object flows from/to streaming parameters, which enable actions to provide output and take input while they are executing, with object flows between the respective pins potentially defining guards to filter which items move across which object flows, per UML 2.5, Clause 15.2.3.3 (Activity Edges), second paragraph.

    The above isn't mentioned, AFAICT, in the various "not mapped" tables, and the term "stream" doesn't appear anywhere in the Transformation specification.

  • Reported: SysML 2.0b2 — Tue, 30 Jul 2024 15:41 GMT
  • Updated: Tue, 30 Jul 2024 15:45 GMT

There is no checkSatisfyRequirementUsageSpecialization constraint

  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Armonas)
  • Summary:

    SatisfyRequirementUsage subsets Requirements::notSatisfiedRequirementChecks or Requirements::satisfiedRequirementChecks in pilot implementation.

    checkSatisfyRequirementUsageSpecialization constraint should be defined in the specification.

  • Reported: SysML 2.0b2 — Mon, 29 Jul 2024 13:14 GMT
  • Updated: Mon, 29 Jul 2024 19:01 GMT

Missing semantic constraints related to features of Part

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the Systems Library model Parts, the base part definition Part is declared to have the features ownedPorts, ownedActions and ownedStates. These features are described in 8.4.7 Parts Semantics, noting that the are covered further in 8.4.8 Ports Semantics, 8.4.12 Actions Semantics and 8.4.13 States Semantics, respectively. More specifically, 8.4.8.2 Port Usages, 8.4.12.2 Action Usages and 8.4.13.2 State Usages state that the semantic constraints checkPortUsageOwnedPortSpecialization, checkActionUsageOwnedActionSpecialization and checkStateUsageOwnedStateSpecialization determine the required specialization of the relevant Part features. However, of these, checkActionUsageOwnedActionSpecialization is defined in the abstract syntax, but the other two are not.

  • Reported: SysML 2.0b2 — Mon, 29 Jul 2024 18:59 GMT
  • Updated: Mon, 29 Jul 2024 18:59 GMT

Interface usage cannot redefine inherited attributes in textual syntax

  • Status: open  
  • Source: Budapest University of Technology and Economics ( Dr. Vince Molnar)
  • Summary:

    For some reason, the textual syntax for interface usage limits the set of elements allowed in its body (see InterfaceBody in clause 8.2.2.14.1). This prevents users from redefining inherited attributes in the usage:

    interface myInterface : MyInterfaceDef // MyInterfaceDef defines attribute x
      connect end1 ::> end1InOuterScope
      to end2 ::> end2InOuterScope {
        redefines x = 5; // syntax error
      }
    
  • Reported: SysML 2.0b2 — Mon, 29 Jul 2024 14:39 GMT
  • Updated: Mon, 29 Jul 2024 17:31 GMT

Decision/MergeNode SuccessionSpecialization checks missing some constraints

  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Decision/MergeNodes are (indirectly) typed by KerML:Decision/MergePerformance (via specialization of Actions::Action::decisions/merges), which KerML Clause 9.2.9.1 (Control Performances Overview) requires:

    Successions going out of Steps typed by DecisionPerformance or its specializations must:
    • ...
    • be included in a Feature of its featuringBehavior that unions (see 7.3.2.7) all the outgoing Successions, and is bound to the outgoingHBLink of the Step (see 7.3.4.6 on feature chaining).

    Successions coming into Steps typed by MergePerformance or its specializations must:
    • ...
    • subset a Feature of its featuringBehavior that unions all the incoming Successions, and is bound to the incomingHBLink of the Step.

    while constraints in 8.3.16.7 (DecisionNode) and 8.3.16.13 (MergeNode) say

    checkDecisionNodeOutgoingSuccessionSpecialization
    All outgoing Successions from a DecisionNode must subset the inherited outgoingHBLink feature of the DecisionNode.
    sourceConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
    resolveGlobal("ControlPerformances::MergePerformance::outgoingHBLink")))

    checkMergeNodeIncomingSuccessionSpecialization
    All incoming Successions to a MergeNode must subset the inherited incomingHBLink feature of the MergeNode.
    targetConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
    resolveGlobal("ControlPerformances::MergePerformance::incomingHBLink")))

    with similar text in 7.16.1 (Actions Overview), under Sequencing of Actions, 7.16.3 (Control Nodes), and 8.4.12.4 (Control Nodes) under Decision / Merge Nodes. These constraints allow outgoing/incomingHBLink to have values that are not identified by outgoing/incoming successions when none of the successions is traversed. The KerML pattern above introduces a feature unioning the successions and binding it to a chain through decision/merge to outgoing/incomingHBLink, ensuring the HB links are identified by the successions. See Annex A.3.7 (Timing for behaviors, Decisions and merges) for an example, at the end of the model to be executed (first code listing), under "Decision and merge timing constraints".

  • Reported: SysML 2.0b1 — Wed, 16 Aug 2023 17:21 GMT
  • Updated: Mon, 29 Jul 2024 13:51 GMT

No way to expose non-membership and non-namespace elements

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    Expose relationship is used to map a view usage element to a model element. In case of elements such as featureTyping, Subsetting and others, since they are not namespaces and not memberships, it is not possible to use it for views of such elements.
    That creates a problem for consistency using expose for graphical view representations, and requires a "workaround" to capture the relationship between view usages and such elements.

  • Reported: SysML 2.0b2 — Wed, 24 Jul 2024 11:34 GMT
  • Updated: Fri, 26 Jul 2024 22:17 GMT

Name misplaced on action symbol parameter

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In clause 7.16.1, Table 14, example "Action with Parameters", the name "param2 : ItemDef2" of the out parameter on the righthand side should be placed outside the action1 rectangle.

  • Reported: SysML 2.0b2 — Wed, 24 Jul 2024 13:50 GMT
  • Updated: Wed, 24 Jul 2024 13:50 GMT

Default multiplicities are not formally specified

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the SysML Specification, in non-normative Language Description subclause 7.6.3 Usages, it describes several conditions that, if met, require a usage to have default multiplicity 1..1. However, there is no formal specification of this in the normative Clause 8 Metamodel.

  • Reported: SysML 2.0b2 — Sat, 15 Jun 2024 17:52 GMT
  • Updated: Tue, 23 Jul 2024 21:04 GMT

timeslice/snapshot featuring types required to specialize or be same as types

  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.3.9.5 (OccurrenceUsage), Constraints, says

    checkOccurrenceUsageTypeFeaturing
    If the portionKind of an OccurrenceUsage is not empty, then, for each occurrenceDefinition of the OccurrenceUsage, there must be a featuringType of the OccurrenceUsage which either is the occurrenceDefinition or directly or indirectly specializes it.

    portionKind <> null implies
      occurrenceDefinition->forAll(occ |
        featuringType->exists(specializes(occ)))
    

    For example, adapted from 7.13.5 (Successions as Usages):

    occurrence def Flight {
      timeslice preflight : Preflight [1];
      then timeslice inflight : Inflight [1];
      then timeslice postflight : Postflight[1];
    

    checkOccurrenceUsageTypeFeaturing requires Flight to specialize each of Pre/In/Postflight, even though these would typically be disjoint with Flight, leading to:

    • all features defined in Pre/In/Postflight "inheriting" to Flight, eg, PreFlight::refuel, would inherit to Flight, with a separate value potentially unconstrained in time from the one happening in preflight.
    • valid traces where all the pre/in/postflight values are instances of Flight, which are all required to have pre/in/postflight timeslices.

    which probably aren't intended in this exampie.

  • Reported: SysML 2.0a1 — Mon, 6 Nov 2023 14:05 GMT
  • Updated: Mon, 22 Jul 2024 16:01 GMT

Semantics of transfers across interfaces

  • Key: SYSML2_-39
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.16.1 Actions Overview, in the "Bindings and Flows Between Actions" section, it states in the last paragraph (italics added):

    A send action usage includes an expression that is evaluated to provide the values to be transferred, and it specifies the destination to which those values are to be sent (possibly delegated through a port and across one or more interfaces – see also 7.12 and 7.14 on interfaces between ports).

    However, the semantics of "delagation across an interface", per the italicized part above, are not described in 7.12 or 7.14, nor are they specified in 8.4.10 Interfaces Semantics.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 21:23 GMT
  • Updated: Mon, 22 Jul 2024 15:59 GMT

Mapping of ClearStructuralFeatureAction is not defined yet

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    As mentioned in section "7.7.2.3.7.20 ClearStructuralFeatureAction_Mapping": The details of the mapping are not defined yet.

  • Reported: SysML 2.0b2 — Mon, 22 Jul 2024 14:34 GMT
  • Updated: Mon, 22 Jul 2024 14:34 GMT

Mapping of RemoveStructuralFeatureValueAction is not defined yet

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    As mentioned in section "7.7.2.3.7.34 RemoveStructuralFeatureValueAction_Mapping": The details of
    the mapping are not defined yet.

  • Reported: SysML 2.0b2 — Mon, 22 Jul 2024 14:20 GMT
  • Updated: Mon, 22 Jul 2024 14:20 GMT

AddStructuralFeatureValueAction Mapping does not consider the names of the input and output pins

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping AddStructuralFeatureValueAction ignores the names of the input and output pins and uses the names defined in the SysMLv1Library::AddStructuralFeatureValueAction element.

  • Reported: SysML 2.0b2 — Mon, 22 Jul 2024 13:39 GMT
  • Updated: Mon, 22 Jul 2024 13:39 GMT

Ordering of guards and accepts in transitions is inconsistent

  • Status: open  
  • Source: Commonwealth Center for Advanced Manufacturing ( Nicholas Thompson)
  • Summary:

    The fourth and sixth rows of "Table 16. States – Representative Notation" each give an example of a transition statement that contains both an if statement and an accept statement, with the accept before the if.

    ...
    transition
       first state1
       accept trigger1
       if guard1
    ...
    

    However, page 110 and the subsequent examples seem to contradict this:

    A transition usage can also have an accepter, which is an accept action usage use to trigger the transition. The accepter action for a transition usage is placed after the guard expression and notated using the accept keyword, with its payload and receiver parameters specified exactly as discussed in 7.16.8 .

    If an accept before an if has a different meaning than an if before accept, the specification document does not make this obvious.
    The Jupyter Kernel in release 2024-05 of the SysML-v2-Release repository treats an if before an accept as a syntax error.

  • Reported: SysML 2.0b2 — Thu, 11 Jul 2024 14:42 GMT
  • Updated: Wed, 17 Jul 2024 23:07 GMT

Evaluation problem with TradeStudyObjectives

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The Analysis Domain Library model TradeStudies includes the following definition:

    	requirement def MinimizeObjective :> TradeStudyObjective {
    		doc
    		/*
    		 * A MinimizeObjective is a TradeStudyObjective that requires that the 
    		 * selectedAlternative have the minimum ObjectiveFunction value of all the
    		 * given alternatives.
    		 */
    		 
    		subject :>> selectedAlternative;
    		in ref :>> alternatives;
    		in calc :>>fn;
    	
    		out attribute :>> best = alternatives->minimize {
    			doc
    			/*
    			 * For a MinimizeObjective, the best value is the minimum one.
    			 */
    		
    			in x; fn(x)
    		};
    	}
    

    (and there is a similar definition for MaximizeObjective that uses maximize instead of minimize). Unfortunately, in the definition minimize in the Kernel Function Library model ControlFunctions, the functional argument to minimized is named fn, and, in the expression fn(x), the name fn gets bound to this parameter, instead of to MinimizeObjective::fn. This means that an evaluation of the invocation of minimize as given will result in an infinite recursion (and similarly for the call to maximize in MaximizeObjective).

  • Reported: SysML 2.0b2 — Wed, 17 Jul 2024 23:06 GMT
  • Updated: Wed, 17 Jul 2024 23:06 GMT

Graphical BNF for n-ary ConnectionDefinition is missing

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 8.2.3.13 productions for n-ary ConnectionDefinition should be added, similar to the existing production n-ary-connection for n-ary ConnectionUsage.

    An n-ary ConnectionDefinition example is given in 7.13.1 Table 11 in row "Connection Definition (n-ary with 3 ends)", like so:

  • Reported: SysML 2.0b2 — Fri, 12 Jul 2024 20:28 GMT
  • Updated: Fri, 12 Jul 2024 20:30 GMT
  • Attachments:

Missing explicit explanation of compartments as views

  • Key: SYSML2_-11
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    There should be explicit specification and explanation, that a diagram and a compartment are views, as well as clarification on how the filter notation can be applied to a view compartment and to a diagram. Consider an extension to the filter notation.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 12:01 GMT
  • Updated: Mon, 8 Jul 2024 19:31 GMT

StateAction::substates has an implied subsetting of exclusiveStates

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    According to the constraint checkStateUsageExclusiveStateSpecialization (in 8.3.17.6), a substate of a non-parallel owning state definition or usage must specialize StateAction::exclusiveStates (at least according to the description of the constraint; the OCL is wrong, see SYSML2_-183). However, the feature StateAction::substates actually meets the requirements for the application of checkStateUsageExclusiveSpecialization, which means that it has an implied specialization of exclusiveStates. But exclusiveStates already subsets substates (at least according to the library model in States.sysml; the feature exclusiveStates seems to be missing from subclause 9.2.10.2.1 StateAction), so this would mean that all substates are exclusiveStates, which is, of course, incorrect for the semantics of parallel states.

  • Reported: SysML 2.0b2 — Wed, 1 May 2024 20:57 GMT
  • Updated: Sun, 7 Jul 2024 23:19 GMT

Table 6 Duplicate Row Titles

  • Status: open  
  • Source: Arcfield ( Matthew Johnson)
  • Summary:

    This table has two rows where the Element Column states Enums Compartment. Recommend adding information to the row titles to indicate what aspect of the compartment is important. E.g., Enums Compartment (enumeration usage names) and Enums Compartment (enumeration values). Alternatively, combine these into one row.

  • Reported: SysML 2.0b1 — Tue, 11 Jun 2024 19:41 GMT
  • Updated: Tue, 2 Jul 2024 11:36 GMT

Table 16 has misspelling issue

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    "State with entry, do and exit actions." - code shows "entry actio1" instead of "entry action1"

  • Reported: SysML 2.0b1 — Tue, 11 Jun 2024 21:48 GMT
  • Updated: Tue, 2 Jul 2024 11:35 GMT

Table 16 Graphical Notation does not match Textual Notation

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    "State with entry, do and exit actions": image showns definition by StateDef1, textual notation does not show this.

  • Reported: SysML 2.0b1 — Tue, 11 Jun 2024 22:01 GMT
  • Updated: Tue, 2 Jul 2024 11:34 GMT

Missing Complete concept

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    in SysML v1 there is a concept of Complete in terms of Specialization of a GeneralizationSet... that concept seems to be missing in SysML v2

  • Reported: SysML 2.0b2 — Wed, 19 Jun 2024 16:26 GMT
  • Updated: Tue, 2 Jul 2024 11:33 GMT

Missing Final concept

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    a classifier in SysML v1 can have isFinalSpecialization:Boolean ... that concept is missing in SysML v2

  • Reported: SysML 2.0b2 — Wed, 19 Jun 2024 16:28 GMT
  • Updated: Tue, 2 Jul 2024 11:33 GMT

Missing isLeaf concept

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    in SysML v1 a RedefinableElement can have a isLeaf:Boolean... this concept seems to be missing in SysMLv2

  • Reported: SysML 2.0b2 — Wed, 19 Jun 2024 16:29 GMT
  • Updated: Tue, 2 Jul 2024 11:32 GMT

Missing Element Import Alias

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    in SysMLv1 for an ElementImport one can supply an Alias... That seems to be missing in SysMLv2

  • Reported: SysML 2.0b2 — Wed, 19 Jun 2024 16:31 GMT
  • Updated: Tue, 2 Jul 2024 11:32 GMT

ShapeItems have radius feature bound

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the Geometry Domain Library model ShapeItems, in the item definitions CircularDisc, Sphere, CircularCone and CircularCylinder, the radius feature is bound to semiMajorAxis (or semiAxis1 for Sphere). However, because of the constraint featureValueOverriding, this means that the radius features cannot be re-bound to specific values in user-model usages of these definitions, as would be expected. (Note that this can only be seen in the ShapeItems.sysml file, not in the description in the specification document.)

  • Reported: SysML 2.0b2 — Tue, 2 Jul 2024 11:31 GMT
  • Updated: Tue, 2 Jul 2024 11:31 GMT

Transformation does not cover SysMLv1::FlowProperty

  • Key: SYSML2_-76
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::FlowProperty.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:49 GMT
  • Updated: Fri, 28 Jun 2024 13:16 GMT

Invalid values can be assigned to an enum

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In the following example:

    enum def Enum2 :> ScalarValues::Integer {a=1; b=2;}
    attribute x1 : Enum2 = Enum2::a;
    attribute x2 : Enum2 = 1;
    attribute x3 : Enum2 = 42;
    

    x3 is invalid, but currently, there is no validation for it.

    Mr. Ed Seidewitz wrote:
    x3 is semantically invalid, since 42 is not a legal value for Enum2, but there is currently no static validation check for it. This cannot be checked statically in general, because the bound value could be any expression returning an Integer, the value of which may not be determinable without doing a complete execution/evaluation of the model (we don’t currently have a general way to report “runtime” semantic errors like this, other than that the model will be formally “unsatisfiable”). It might be possible to add a validation constraint for the case in which the both the enumerated values and the bound value in the attribute usage are model-level evaluable expressions (which would catch the case of your x3), though the OCL could be a bit complicated. If you think it is worth it, you could file a SysML v2 Jira issue for this, though it probably not be addressed in the FTF (though we could possibly address it on the KerML side when resolving KERML_-245 to add enumeration syntax to KerML).

  • Reported: SysML 2.0b2 — Wed, 26 Jun 2024 09:58 GMT
  • Updated: Wed, 26 Jun 2024 09:58 GMT

Port transfer semantics

  • Key: SYSML2_-40
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.12.1 Ports Overview, at the end of the third paragraph, it states

    A transfer can occur from the out features of one port usage to the matching in features of connected port usages. Transfers can occur in both directions between matching inout features.

    It is unclear whether this is intended to mean that such transfers happen automatically in some way, or if it just means that it is possible to have such transfers by adding explicit flows to the model. If the former is intended, then this does not seem to be currently supported by port semantics (8.4.8). If the latter is intended, this should be made more clear.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 21:28 GMT
  • Updated: Tue, 25 Jun 2024 20:28 GMT

Inconsistencies in the graphical notation for "expose"

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:
    1. In 7.25.1 Views and Viewpoints Overview, Table 23. Views and Viewpoints – Representative Notation, the example for "Expose" renders the expose relationship using a dashed arrow. However, in 8.2.3.25 Views and Viewpoints Graphical Notation, the graphical BNF production expose-relationship shows the arrow as being solid.
    2. An expose relationship is a kind of import and, as such, can expose a single membership or the content of a namespace, and can optionally be recursive. The textual BNF production Expose in 8.2.2.25.2 View Usages allows all these options, as does the graphical BNF production expose-compartment-element (for showing an expose declaration in a compartment) in 8.2.3.25 Views and Viewpoints Graphical Notation. However, the graphical graphical BNF production expose-relationship does not.
    3. The textual BNF production Expose allows a VisibilityIndicator on an expose declaration, as does the graphical BNF production expose-compartment-element. However, the graphical BNF production expose-relationship does not.
  • Reported: SysML 2.0b2 — Thu, 30 May 2024 14:46 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT
  • Attachments:

isOrdered and isUnique are missing from the reflective abstract mapping

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The mapping given in 9.2.21 from the MOF abstract syntax model to the reflective SysML abstract syntax model is missing instructions for what to do if a property is ordered or non-unique. Therefore, appropriate annotations for these are missing from the normative SysML.sysml file.

  • Reported: SysML 2.0b2 — Mon, 27 May 2024 19:34 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

Missing guidance on highlighting keywords

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The KerML specification contains guidance for tooling to highlight keywords in concrete textual notation. KerML subclause 8.2.2.6 specifically says:

    Tooling for the KerML textual notation should generally highlight keywords relative to other text, for example by using boldface and/or distinctive coloring. However, while keywords are shown in boldface in this specification, the specification does not require any specific highlighting (or any highlighting at all), and KerML textual notation documents are expected to be interchanged as plain text (see also Clause 10 on Model Interchange).

    A similar statement, modified for SysML, should be added, probably as a last paragraph under subclause 8.2.2.1.2, including a cross-reference to KerML. For SysML the same guidance applies to textual snippets used in the Graphical Notation.

  • Reported: SysML 2.0b2 — Mon, 20 May 2024 09:37 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

Error in the specification of "connections"

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the SysML Specification, 9.2.6.2.4 connections, the base connection usage connections is specified as being a ConcernUsage under "Elements". This should, instead, be ConnectionUsage. (Note that this error is only in the document, and connections is declared correctly in the Connections.sysml model file.

  • Reported: SysML 2.0b2 — Sat, 4 May 2024 20:16 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

Incorrect enumeration example

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The following example appears in 7.8.2 Enumeration Definitions and Usages:

    enum def ConditionColor { red; green; yellow; } 
    attribute def ConditionLevel {
        attribute color : ConditionColor; 
    }
    enum def RiskLevel :> ConditionLevel {
        enum low { color = ConditionColor::green; } 
        enum medium { color = ConditionColor::yellow; } 
        enum high { color = ConditionColor::red; }
    }
    

    This is example is not valid, because the color features defined in the enumerated values will have name conflicts with the color feature inherited from ConditionLevel. The intent was probably to have the color features in the enumerated values redefine ConditionLevel::color, but that is currently missing from the example.

  • Reported: SysML 2.0b2 — Thu, 2 May 2024 21:34 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

checkStateUsageExclusiveStateSpecialization and checkStateUsageSubstateSpecialization have problems

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 8.3.17.6 StateUsage:

    1. The constraint checkStateUsageExclusiveStateSpecialization has the description

      A StateUsage that is a substate usage with a non-parallel owning StateDefinition or StateUsage must directly or indirectly specialize the StateUsage States::State::exclusiveStates from the Systems Model Library.

      However, the OCL for the constraint actually checks for the owning state being parallel (rather than non-parallel) and requires specialization of substates rather than exclusiveStates.

    2. The constraint checkStateUsageSubstateSpecialization has the description

      A StateUsage that is a substate usage with a owning StateDefinition or StateUsage that is parallel must directly or indirectly specialize the StateUsage States::State::substates from the Systems Model Library.

      However, the OCL for the constraint actually checks for the owning state being non-parallel (rather than parallel).

    3. The operation isSubstateUsage used in the above constraints has the description

      Check if this StateUsage is composite and has an owningType that is an StateDefinition or StateUsage with the given value of isParallel, but is not an entryAction or exitAction. If so, then it represents a StateAction that is a substate or exclusiveState (for isParallel = false) of another StateAction.

      However, the OCL for the operation actually does not check if the state usage is composite and also excludes do actions (in addition to entry and exit actions).

  • Reported: SysML 2.0b2 — Wed, 1 May 2024 20:43 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

Guillemets should not be used on keywords in textual notation snippets used in the graphical notation

  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Keywords introduced in the graphical notation BNF are surrounded by guillemets («...»). However, the graphical notation also uses snippets of textual notation in many places, often by referencing productions from the textual notation BNF, which does not put guillemets around keywords. In some cases, though, the graphical BNF will include productions for text that introduce keywords that parallel the textual notation, but don't directly use textual notation BNF productions. The resolution to SYSML2-59 includes such productions for message-label and flow-label that include the «of» keyword surrounded by guillemets, but other such productions in the graphical BNF do not put guillemets around keywords. There needs to be a consistent rule on how guillemets are to be used in the graphical notation.

  • Reported: SysML 2.0a1 — Fri, 22 Dec 2023 23:11 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

Missing production for use case actors and subject

  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Right now use-case nodes cannot be associated with actors and subjects. They need to be made subject/actor stakeholders

  • Reported: SysML 2.0a1 — Wed, 18 Oct 2023 12:20 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

GBNF for flow connection not mapped to semantics

  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Graphical BNF specifies a flow connection. It is not clearly mapped to a semantic language concept. Should it be merged with a message specified as part of occurences?

  • Reported: SysML 2.0a1 — Wed, 18 Oct 2023 11:15 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

Symbol for metadata def is missing

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add support for defining a metadata definition using the normal definition symbol (e.g., key word metadata def with metadata def name in name compartment). Separate compartment for attribute declarations. Add compartment redefined the annotated elements so they are constrained to be of a certain metaclass. (Note that MetadataDefinition is a kind of ItemDefinition but MetadataFeature (and therefore MetadataUsage) is a kind of AnnotatingElement.)

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:09 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT
  • Attachments:

No support for metadata definition in graphical notation


incorrect naming of * character

  • Key: SYSML2_-3
  • Status: open  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Throughout the document, we need consistent and formal language; for the * character, use 'asterisk' instead of 'star' for the character *.

  • Reported: SysML 2.0b1 — Thu, 8 Feb 2024 18:14 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

incorrect naming of * character

  • Key: SYSML2_-2
  • Status: open  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Throughout the document, need consistent and formal language; for the * character, use 'asterisk' instead of 'star' for the character *.

  • Reported: SysML 2.0b1 — Thu, 8 Feb 2024 18:16 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

Issues with SysML/KerML grammar

  • Key: SYSML2_-1
  • Status: open  
  • Source: itemis AG ( David Akehurst)
  • Summary:

    I raised a number of issues previously with regards to detailed/specific problems with the KerML textual syntax grammar.
    A more general issue is that I find the grammar (as written) hard to digest.
    It is not modular, and the chapters don't seem to relate fully to the Abstract Syntax packages.

    I have created an alternative grammar, using a different grammar-syntax, that allows for modular definition of grammars.
    I would like to offer you this.
    However, I cannot attach files to this issue!
    feel free to contact me if you would like me to provide them.

    In summary, one can modularise the KerML grammar into a Kernel, Core, Root (groups/packages)
    with each group/package containing 3-5 grammar modules and extension relationships to combine them.

    I plan to do the same for the full SysML grammar (later).

  • Reported: SysML 2.0b1 — Wed, 14 Feb 2024 11:32 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

Missing production for use case actors and subject


Need to complete and align flow and message notations in GBNF

  • Key: SYSML2-557
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    The graphical notation lacks clear differentiation between the various types of flows in the language: flow, succession flows, and message flow (see also SYSML2-59).
    In addition, the BNF was overly restrictive and did not allow flow connections on structural diagrams, except for flows on connections.
    Flows on connections also need to include messages and succession flows.
    It needs to be corrected in the BNF in the relevant clauses
    8.2.3.9 - Occurrences (SD notation)
    8.2.3.13 - Connections
    8.2.3.14 - Interfaces
    8.2.3.16 - Actions

  • Reported: SysML 2.0a1 — Wed, 29 Nov 2023 15:00 GMT
  • Updated: Sat, 25 May 2024 21:02 GMT

Confusing send/accept examples in notation tables

  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    The notation tables show various permutations of send/receive actions with various parameter options. They are all shown against a single simple textual example. It is unclear what is the purpose of rationale each permutation.
    Graphical Examples need to align with corresponding text examples.

  • Reported: SysML 2.0b2 — Mon, 13 May 2024 13:29 GMT
  • Updated: Wed, 22 May 2024 19:20 GMT

Guillemets are not used on keywords in textual notation snippets used in the graphical notation

  • Key: SYSML2-629
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Keywords introduced in the graphical notation BNF are surrounded by guillemets («...»). However, the graphical notation also uses snippets of textual notation in many places, often by referencing productions from the textual notation BNF, which does not put guillemets around keywords. In some cases, though, the graphical BNF will include productions for text that introduce keywords that parallel the textual notation, but don't directly use textual notation BNF productions. The resolution to SYSML2-59 includes such productions for message-label and flow-label that include the «of» keyword surrounded by guillemets, but other such productions in the graphical BNF do not put guillemets around keywords. There needs to be a consistent rule on how guillemets are to be used in the graphical notation.

  • Reported: SysML 2.0a1 — Fri, 22 Dec 2023 23:11 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Reuse of KerML textual notation productions in the SysML grammar

  • Key: SYSML2-686
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The reuse of KerML BNF productions in the SysML textual notation grammar is not described sufficiently. It is not clear which productions are reused and which not. Reused productions are simply missing from the SysML definitions.

    (This issue was originally reported as part of SYSML2-635.)

  • Reported: SysML 2.0b1 — Fri, 19 Jan 2024 23:51 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Long-form notation for bindings and successions

  • Key: SYSML2-632
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The genera textual notation for (binary) connections (see 8.2.2.13.1 Connection Definition and Usage) allows for both a "short form" (connect...to...;) and a "long form", in which the ends are explicitly declared within the connection body. The notations for binding connections (see 8.2.2.13.2 Binding Connectors) and successions (see 8.2.2.13.3 Successions) also have their own "short forms" (bind...=...; and first...then...;)). However, even though both notations allow for connection bodies, the short-form part is required, so it is not possible to declare the ends within the bodies. (Note that the corresponding KerML notations do allow fully "long form" declarations for bindings and successions; see 8.2.5.5.2 and 8.2.5.5.3 in the KerML specification.)

  • Reported: SysML 2.0b1 — Tue, 2 Jan 2024 20:04 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Change graphical notation for use cases to elliptic elements

  • Key: SYSML2-639
  • Status: open  
  • Source: MDD4All ( Dr. Oliver Alt)
  • Summary:

    In the SysML v2 the graphical notation for use cases is a box with rounded corners containing the stereotype "use case" and the use case name.
    From the very beginning of UML and SysML v1.x use cases are visualized as elliptic elements. Nearly all people that have ever used or seen UML or SysML in the past are familiar with that notation. So why change it for SysML v2 here? It is not necessary from my perspective.
    A box with many textual things inside is not a good idea for a graphical language. Graphical languages should use as less text as possible. Instead they should use different graphical shapes, different stroke widths, stroke types and icons to express the semantics and what is modeled.
    A user should be able to recognize a diagram element on a first side, looking at a diagram drawing form far away. It should not be necessary to read all details to recognize that is a use case diagram and not any other diagram by reading the stereotype text elements first!

  • Reported: SysML 2.0b1 — Tue, 16 Jan 2024 11:46 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Long-form notation for bindings and successions

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The genera textual notation for (binary) connections (see 8.2.2.13.1 Connection Definition and Usage) allows for both a "short form" (connect...to...;) and a "long form", in which the ends are explicitly declared within the connection body. The notations for binding connections (see 8.2.2.13.2 Binding Connectors) and successions (see 8.2.2.13.3 Successions) also have their own "short forms" (bind...=...; and first...then...;)). However, even though both notations allow for connection bodies, the short-form part is required, so it is not possible to declare the ends within the bodies. (Note that the corresponding KerML notations do allow fully "long form" declarations for bindings and successions; see 8.2.5.5.2 and 8.2.5.5.3 in the KerML specification.)

  • Reported: SysML 2.0b1 — Tue, 2 Jan 2024 20:04 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Change graphical notation for use cases to elliptic elements

  • Status: open  
  • Source: MDD4All ( Dr. Oliver Alt)
  • Summary:

    In the SysML v2 the graphical notation for use cases is a box with rounded corners containing the stereotype "use case" and the use case name.
    From the very beginning of UML and SysML v1.x use cases are visualized as elliptic elements. Nearly all people that have ever used or seen UML or SysML in the past are familiar with that notation. So why change it for SysML v2 here? It is not necessary from my perspective.
    A box with many textual things inside is not a good idea for a graphical language. Graphical languages should use as less text as possible. Instead they should use different graphical shapes, different stroke widths, stroke types and icons to express the semantics and what is modeled.
    A user should be able to recognize a diagram element on a first side, looking at a diagram drawing form far away. It should not be necessary to read all details to recognize that is a use case diagram and not any other diagram by reading the stereotype text elements first!

  • Reported: SysML 2.0b1 — Tue, 16 Jan 2024 11:46 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Enumerations not specializable

  • Key: SYSML2-593
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [From Mr. Ryan Noguchi] In the SysML v2 spec, section 7.8.1:

    An enumeration definition may not specialize another enumeration definition. This is because the semantics of specialization require that the set of instances classified by a definition be a subset of the instances of classified by any definition it specializes. The enumerated values defined in an enumeration definition, however, would add to the set of enumerated values allowed by any enumeration definition it specialized, which is inconsistent with the semantics of specialization.

    To comply with the Liskov Substitution Principle, a specialization of an enumeration definition should only remove literals, not add them. Why can’t the specialization’s definition either simply remove existing literals from the general definition or list the applicable literals—resulting in a syntax error if this list includes anything not present in the general definition? As a concrete example:

    enum def ClassificationLevel {
       enum unclassified;
       enum cui;
       enum secret;
       enum top_secret;
    }
    
    enum def ClassificationLevelClassified :> ClassificationLevel {
        enum secret;
        enum top_secret;
    }
    
  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 17:49 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Transformation fails on Enumerations that are ValueTypes

  • Key: SYSML2-591
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Both Enumeration and ValueType have main mappings and their specified filters do prevent a double match

  • Reported: SysML 2.0a1 — Wed, 6 Dec 2023 20:41 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

PortUsage direction

  • Key: SYSML2-594
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The direction of a PortUsage can be specified like that of any other feature. However, this does not really seem to make sense. The direction of a PortUsage should be determined by the direction of features within it, consistent with the visualization of directions on ports shown, e.g., in the Representative Notation table in 7.11.1 Parts Overview.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 18:15 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Proxy nodes are missing from states

  • Key: SYSML2-601
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    State shall be able to have proxy nodes on their boundaries. Currently not covered by the GBNF

  • Reported: SysML 2.0a1 — Sun, 17 Dec 2023 16:03 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Flow connections are incorrectly both structure and behavior

  • Key: SYSML2-592
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    According to the KerML specification, "Structures and behaviors do not overlap". Consistent with this, the approved resolution to KERML-43 added validations to disallow a structure from specializing a behavior and vice versa.

    ConnectionDefinitions in SysML are kinds of PartDefinitions, which are (indirectly) kinds of KerML Structures. But FlowConnectionDefinitions are both ConnectionDefinitions and ActionDefinitions, and ActionDefinitions are kinds of KerML Behaviors. This means that FlowConnectionDefinitions are both Structures and Behaviors, violating the restrictions of KerML.

    As a result, the specializations in the declarations of MessageConnection and FlowConnection in the Systems Library model Connections now violate the new validateStructureSpecialization and validateBehaviorSpecialization constraints added by the resolution to KERML-43.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 17:04 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Enumerations not specializable

  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [From Mr. Ryan Noguchi] In the SysML v2 spec, section 7.8.1:

    An enumeration definition may not specialize another enumeration definition. This is because the semantics of specialization require that the set of instances classified by a definition be a subset of the instances of classified by any definition it specializes. The enumerated values defined in an enumeration definition, however, would add to the set of enumerated values allowed by any enumeration definition it specialized, which is inconsistent with the semantics of specialization.

    To comply with the Liskov Substitution Principle, a specialization of an enumeration definition should only remove literals, not add them. Why can’t the specialization’s definition either simply remove existing literals from the general definition or list the applicable literals—resulting in a syntax error if this list includes anything not present in the general definition? As a concrete example:

    enum def ClassificationLevel {
       enum unclassified;
       enum cui;
       enum secret;
       enum top_secret;
    }
    
    enum def ClassificationLevelClassified :> ClassificationLevel {
        enum secret;
        enum top_secret;
    }
    
  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 17:49 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Proxy nodes are missing from states

  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    State shall be able to have proxy nodes on their boundaries. Currently not covered by the GBNF

  • Reported: SysML 2.0a1 — Sun, 17 Dec 2023 16:03 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

PortUsage direction

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The direction of a PortUsage can be specified like that of any other feature. However, this does not really seem to make sense. The direction of a PortUsage should be determined by the direction of features within it, consistent with the visualization of directions on ports shown, e.g., in the Representative Notation table in 7.11.1 Parts Overview.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 18:15 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Transformation fails on Enumerations that are ValueTypes

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Both Enumeration and ValueType have main mappings and their specified filters do prevent a double match

  • Reported: SysML 2.0a1 — Wed, 6 Dec 2023 20:41 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

ObjectFlowItemFlowEndReferenceUsage_Mapping::ownedRelationship is not reliable

  • Key: SYSML2-588
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The current specification is not computable in some cases (where the "any" OCL iterator find no value). E.g. : MIWG Test Case#27

  • Reported: SysML 2.0a1 — Tue, 5 Dec 2023 22:21 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

SatisfyReferenceUsageFeatureTyping_Mapping::type() is wrong

  • Key: SYSML2-589
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    In some cases (e.g. MIWG test case #11) it is unable to compute the requested type.

  • Reported: SysML 2.0a1 — Tue, 5 Dec 2023 22:24 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Literal factories are missing operation for their value

  • Key: SYSML2-586
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    As a consequence SysMLv literals generated by the transformation have no value defined

  • Reported: SysML 2.0a1 — Tue, 5 Dec 2023 22:14 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Helper::getScalarValueType operation is not robust enough

  • Key: SYSML2-590
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The current algorithm crashes if the data type provided has no name defined or if the type is not defined

  • Reported: SysML 2.0a1 — Wed, 6 Dec 2023 16:53 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

SatisfyReferenceUsageFeatureTyping_Mapping::type() is wrong

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    In some cases (e.g. MIWG test case #11) it is unable to compute the requested type.

  • Reported: SysML 2.0a1 — Tue, 5 Dec 2023 22:24 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Literal factories are missing operation for their value

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    As a consequence SysMLv literals generated by the transformation have no value defined

  • Reported: SysML 2.0a1 — Tue, 5 Dec 2023 22:14 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

ObjectFlowItemFlowEndReferenceUsage_Mapping::ownedRelationship is not reliable

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The current specification is not computable in some cases (where the "any" OCL iterator find no value). E.g. : MIWG Test Case#27

  • Reported: SysML 2.0a1 — Tue, 5 Dec 2023 22:21 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Add a distinguished attribute to capture the textual body of a requirement

  • Key: SYSML2-546
  • Status: open  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    A requirement should include a text body to capture the shall statement or other human readable requirement statement. The doc annotating element is one way to accomplish this. However, a doc element on a requirement definition is inherited by its requirement usages, but it cannot be redefined on its usage. (Note: The texts of a RequirementUsage are the bodies of the documentation of the RequirementUsage.)

    The proposal is to add a distinguished attribute to capture the text body of a requirement that would replace the derived text attribute/documentation. This distinguished attribute can be redefined. This avoids a requirement usage from having both the original text in the requirement definition and the modified text in the usage.

    The concrete syntax should be updated accordingly.

  • Reported: SysML 2.0b1 — Wed, 15 Nov 2023 17:41 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Default multiplicities are not managed correctly

  • Key: SYSML2-584
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The multiplicities that the transformation specifies are wrong when the source element has the default multiplicity in the source model.
    Shall be fixed: MultiplicityUpperBoundOwningMembership_Mapping and MultiplicityLowerBoundOwningMembership_Mapping
    Shall be removed : DefaultLowerBound_Mapping and DefaultUpperBound_Mapping

    Factories for LiteralInteger, LiteralInfinity are required

  • Reported: SysML 2.0a1 — Tue, 5 Dec 2023 22:09 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Semantic constraints missing for shorthand succession notation

  • Key: SYSML2-576
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The following cases in the textual notation allow "shorthand" then notations for SuccessionAsUsages:

    1. In 8.2.2.9.3 Occurrence Successions, the production SourceSuccession creates a SuccessionAsUsage that has a source end with no related feature and no target end.
    2. In 8.2.2.16.7 Action Successions, the production TargetSuccession creates a SuccessionAsUsage that has a source end as in SourceSuccession, but it has a full ConnectorEndMember for its target end, including an explicit related element.

    In both cases, the intent is that the implied related feature of the source end of the SuccessionAsUsage is a feature lexically previous to the declaration of the SuccessionAsUsage. In the first case, the implied related feature for the target end of the SuccessionAsUsage is a feature lexically following the SuccessionAsUsage. However, there are no semantic constraints given in 8.3.13.8 SuccessionAsUsage to enforce these implied relationships.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 17:12 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

ObjectFlowItemFlowEndReferenceUsage_Mapping::ownedRelationship() is wrong

  • Key: SYSML2-535
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    ownedRelationship() operation. There is the following code:

       else if from.oclIsTypeOf(UML::FlowFinalNode) then
           ObjectFlowItemFlowEndRedefinition_Factory.create(ElementMain_Mapping.getMapped(SysMLv2::ActionUsage.allInstances()->any(e | e.qualifiedName =  'Actions::Action::done')))
    

    The point is that the parameter of a getMapped operation shall be an element form the source model, while the code above povide a SysMLv2 element from a library. This makes the MIWIG test case #27 failing

  • Reported: SysML 2.0a1 — Mon, 13 Nov 2023 21:02 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Factories specified for Literal specification shall be optimized

  • Key: SYSML2-585
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Duplicated operations can be removed by adding a common abstract root class. This will simplify the model and ease the maintenance

  • Reported: SysML 2.0a1 — Tue, 5 Dec 2023 22:12 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Factories specified for Literal specification shall be optimized

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Duplicated operations can be removed by adding a common abstract root class. This will simplify the model and ease the maintenance

  • Reported: SysML 2.0a1 — Tue, 5 Dec 2023 22:12 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

ObjectFlowItemFlowEndReferenceUsage_Mapping::ownedRelationship() is wrong

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    ownedRelationship() operation. There is the following code:

       else if from.oclIsTypeOf(UML::FlowFinalNode) then
           ObjectFlowItemFlowEndRedefinition_Factory.create(ElementMain_Mapping.getMapped(SysMLv2::ActionUsage.allInstances()->any(e | e.qualifiedName =  'Actions::Action::done')))
    

    The point is that the parameter of a getMapped operation shall be an element form the source model, while the code above povide a SysMLv2 element from a library. This makes the MIWIG test case #27 failing

  • Reported: SysML 2.0a1 — Mon, 13 Nov 2023 21:02 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Default multiplicities are not managed correctly

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The multiplicities that the transformation specifies are wrong when the source element has the default multiplicity in the source model.
    Shall be fixed: MultiplicityUpperBoundOwningMembership_Mapping and MultiplicityLowerBoundOwningMembership_Mapping
    Shall be removed : DefaultLowerBound_Mapping and DefaultUpperBound_Mapping

    Factories for LiteralInteger, LiteralInfinity are required

  • Reported: SysML 2.0a1 — Tue, 5 Dec 2023 22:09 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Add a distinguished attribute to capture the textual body of a requirement

  • Status: open  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    A requirement should include a text body to capture the shall statement or other human readable requirement statement. The doc annotating element is one way to accomplish this. However, a doc element on a requirement definition is inherited by its requirement usages, but it cannot be redefined on its usage. (Note: The texts of a RequirementUsage are the bodies of the documentation of the RequirementUsage.)

    The proposal is to add a distinguished attribute to capture the text body of a requirement that would replace the derived text attribute/documentation. This distinguished attribute can be redefined. This avoids a requirement usage from having both the original text in the requirement definition and the modified text in the usage.

    The concrete syntax should be updated accordingly.

  • Reported: SysML 2.0b1 — Wed, 15 Nov 2023 17:41 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

OpaqueBehavior shall be transformed even if they are not owned by a Package

  • Key: SYSML2-532
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The filter operations defined for the mapping specified from an OpaqueBehavior prevent those owned by another kind of element to be transformed, like in MWIG test cases 7 and 35

  • Reported: SysML 2.0a1 — Mon, 13 Nov 2023 20:38 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Textual notation for send actions is too limited

  • Key: SYSML2-526
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    According to the SysML Specification, 8.2.2.16.4 Send and Accept Actions, the general textual notation for a send action has the form

    send payloadExpression via senderExpression to receiverExpression

    In this syntax, the via and to parts are optional, but the payloadExpression is not. Since the result of the required payloadExpression is bound to the payload parameter of the send action, this makes it difficult to model a case in which, e.g., it is desired use a flow to provide the value of the payload, rather than the result of an expression. It also makes it difficult to model a general send action with the payload not specified (or defaulted), with the actual payload bound in a specialization of the general action.

    While it is possible to get around these limitations by modeling the send action using a regular action usage typed by Actions::SendAction, this is no longer syntactically a send action usage and so, e.g., would not be rendered as such in the graphical notation. It would be better if the textual notation allowed the payloadExpression to be optional, while still declaring syntactic send action usage.

  • Reported: SysML 2.0b1 — Wed, 8 Nov 2023 17:26 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Properties typed by Actors

  • Key: SYSML2-533
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The MWIG test case #8 fails because it contains a property that is typed by an Actor while the transformatiosn currently defined do not support it

  • Reported: SysML 2.0a1 — Mon, 13 Nov 2023 20:53 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

timeslice/snapshot featuring types required to specialize or be same as types

  • Key: SYSML2-524
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.3.9.5 (OccurrenceUsage), Constraints, says

    checkOccurrenceUsageTypeFeaturing
    If the portionKind of an OccurrenceUsage is not empty, then, for each occurrenceDefinition of the OccurrenceUsage, there must be a featuringType of the OccurrenceUsage which either is the occurrenceDefinition or directly or indirectly specializes it.

    portionKind <> null implies
      occurrenceDefinition->forAll(occ |
        featuringType->exists(specializes(occ)))
    

    For example, adapted from 7.13.5 (Successions as Usages):

    occurrence def Flight {
      timeslice preflight : Preflight [1];
      then timeslice inflight : Inflight [1];
      then timeslice postflight : Postflight[1];
    

    checkOccurrenceUsageTypeFeaturing requires Flight to specialize each of Pre/In/Postflight, even though these would typically be disjoint with Flight, leading to:

    • all features defined in Pre/In/Postflight "inheriting" to Flight, eg, PreFlight::refuel, would inherit to Flight, with a separate value potentially unconstrained in time from the one happening in preflight.
    • valid traces where all the pre/in/postflight values are instances of Flight, which are all required to have pre/in/postflight timeslices.

    which probably aren't intended in this exampe.

  • Reported: SysML 2.0a1 — Mon, 6 Nov 2023 14:05 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Most SysML::Blocks are owned by a package

  • Key: SYSML2-534
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The MIWIG test case #11 fails because it assumes that the client of a SysML::Satisfy relationship, that is a Block, is owned by something that is mapped to a SysMLv2 Type.

    This is unlikely to happen since in most cases (like in this test case) Blocks are owned by Packages

  • Reported: SysML 2.0a1 — Mon, 13 Nov 2023 20:58 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Most SysML::Blocks are owned by a package

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The MIWIG test case #11 fails because it assumes that the client of a SysML::Satisfy relationship, that is a Block, is owned by something that is mapped to a SysMLv2 Type.

    This is unlikely to happen since in most cases (like in this test case) Blocks are owned by Packages

  • Reported: SysML 2.0a1 — Mon, 13 Nov 2023 20:58 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

OpaqueBehavior shall be transformed even if they are not owned by a Package

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The filter operations defined for the mapping specified from an OpaqueBehavior prevent those owned by another kind of element to be transformed, like in MWIG test cases 7 and 35

  • Reported: SysML 2.0a1 — Mon, 13 Nov 2023 20:38 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Properties typed by Actors

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The MWIG test case #8 fails because it contains a property that is typed by an Actor while the transformatiosn currently defined do not support it

  • Reported: SysML 2.0a1 — Mon, 13 Nov 2023 20:53 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

GenericToStateUsage_Mapping is missing a default rule

  • Key: SYSML2-506
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    GenericToStateUsage_Mapping is missing a default rule for isParallel

  • Reported: SysML 2.0a1 — Thu, 2 Nov 2023 17:42 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

GenericToElement_Mapping is missing default rules

  • Key: SYSML2-507
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    GenericToElement_Mapping is missing default rules for:

    • owningRelationship
    • aliasIds
    • declaredShortName
    • isImpliedIncluded
  • Reported: SysML 2.0a1 — Thu, 2 Nov 2023 18:07 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Namespace_Mapping shall redefine ownedRelationship()

  • Key: SYSML2-516
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    A Namespace shall own the relationships that defined its members (either owned or not) and its import relationships.
    Instead the ownedImport() operation is useless since Namespace::ownedImport is a derived property

  • Reported: SysML 2.0a1 — Fri, 3 Nov 2023 18:21 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Comment_Mapping is missing a default rule

  • Key: SYSML2-508
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Comment_Mapping is missing a default rule locale

  • Reported: SysML 2.0a1 — Thu, 2 Nov 2023 18:23 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Relationship_Mapping::ownedRelatedElement() is wrong

  • Key: SYSML2-515
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The body condition specified for this operation is wrong. It should be an empty set.

  • Reported: SysML 2.0a1 — Fri, 3 Nov 2023 17:58 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Relationship_Mapping::ownedRelatedElement() is wrong

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The body condition specified for this operation is wrong. It should be an empty set.

  • Reported: SysML 2.0a1 — Fri, 3 Nov 2023 17:58 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

GenericToStateUsage_Mapping is missing a default rule

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    GenericToStateUsage_Mapping is missing a default rule for isParallel

  • Reported: SysML 2.0a1 — Thu, 2 Nov 2023 17:42 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Namespace_Mapping shall redefine ownedRelationship()

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    A Namespace shall own the relationships that defined its members (either owned or not) and its import relationships.
    Instead the ownedImport() operation is useless since Namespace::ownedImport is a derived property

  • Reported: SysML 2.0a1 — Fri, 3 Nov 2023 18:21 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

GenericToElement_Mapping is missing default rules

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    GenericToElement_Mapping is missing default rules for:

    • owningRelationship
    • aliasIds
    • declaredShortName
    • isImpliedIncluded
  • Reported: SysML 2.0a1 — Thu, 2 Nov 2023 18:07 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

GenericToRelationship_Mapping is missing default rules

  • Key: SYSML2-504
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    GenericToRelationship_Mapping should provide default rules for

    • owningRelatedElement
    • isImplied
  • Reported: SysML 2.0a1 — Thu, 2 Nov 2023 17:34 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Graphical notation unclear on optionality of keywords on edges

  • Key: SYSML2-486
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    A graphical BNF production should be added that specifies that keywords may optionally be included on edges.

  • Reported: SysML 2.0a1 — Wed, 18 Oct 2023 13:51 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Graphical notation unclear about user-defined keywords for library extensions

  • Key: SYSML2-487
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    A graphical BNF production should be added that specifies that it is mandatory to include the applicable user-defined keyword in the notation for a library extension element.

  • Reported: SysML 2.0a1 — Wed, 18 Oct 2023 13:52 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

OccurrenceUsage missing portioningFeature

  • Key: SYSML2-503
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.4.5.2 (Occurrence Usages) says

    If an OccurrenceUsage has a non-null portionKind, then it is also required to have a portioningFeature with the same portionKind. The following semantic constraints apply to a PortioningFeature:
    ...

    and the code example at the end of 8.4.5.2 has comments identifying some features as "Portioning", with text below it referring to portioningFeature

    However, portioningFeature doesn't appear in Figure 12 (Occurrence Definition and Usage) or anywhere else in the document.

  • Reported: SysML 2.0b1 — Thu, 2 Nov 2023 14:26 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Control nodes missing from concrete syntax for states

  • Key: SYSML2-502
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Currently it is not possible to use action control nodes (Fork/Join/Decision/Merge) as sources/targets of a transition in a state definition or usage.

  • Reported: SysML 2.0a1 — Wed, 1 Nov 2023 13:19 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

GenericToRequirementUsage_Mapping is missing a default rule

  • Key: SYSML2-505
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    GenericToRequirementUsage_Mapping is missing a default rule for reqId

  • Reported: SysML 2.0a1 — Thu, 2 Nov 2023 17:39 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Graphical notation unclear on optionality of keywords on edges

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    A graphical BNF production should be added that specifies that keywords may optionally be included on edges.

  • Reported: SysML 2.0a1 — Wed, 18 Oct 2023 13:51 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

GenericToRelationship_Mapping is missing default rules

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    GenericToRelationship_Mapping should provide default rules for

    • owningRelatedElement
    • isImplied
  • Reported: SysML 2.0a1 — Thu, 2 Nov 2023 17:34 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Graphical notation unclear about user-defined keywords for library extensions

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    A graphical BNF production should be added that specifies that it is mandatory to include the applicable user-defined keyword in the notation for a library extension element.

  • Reported: SysML 2.0a1 — Wed, 18 Oct 2023 13:52 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

GenericToRequirementUsage_Mapping is missing a default rule

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    GenericToRequirementUsage_Mapping is missing a default rule for reqId

  • Reported: SysML 2.0a1 — Thu, 2 Nov 2023 17:39 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Control nodes missing from concrete syntax for states

  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Currently it is not possible to use action control nodes (Fork/Join/Decision/Merge) as sources/targets of a transition in a state definition or usage.

  • Reported: SysML 2.0a1 — Wed, 1 Nov 2023 13:19 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Clarify bolding of keywords in concrete graphical syntax

  • Key: SYSML2-485
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Documentation should be added that bolding of keywords in the graphical notation is optional, and may be used for visual prominence. For example, in representative notation table 16 in subclause 7.17.1 in the actions compartment of a state the keywords entry, do and exit are bolded.

  • Reported: SysML 2.0a1 — Wed, 18 Oct 2023 13:50 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Incorrect definition elements in interconnection-element

  • Key: SYSML2-483
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Definition elements incorrectly appear in graphical BNF productions for interconnection-element. Remove the following from interconnection-element productions: part-def in 8.2.3.11, port-def in 8.2.3.12, connection-def in 8.2.3.13, constraint-def in 8.2.3.19, requirement-def and concern-def in 8.2.3.20, viewpoint-def and view-def in 8.2.3.25.

  • Reported: SysML 2.0b1 — Wed, 18 Oct 2023 13:46 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Missalignment between interface graphical production and notation table

  • Key: SYSML2-479
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Notation table shows item flows on interface connections. This is not enabled by the graphical BNF

  • Reported: SysML 2.0a1 — Wed, 18 Oct 2023 11:24 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Missing production for use case actors and subject

  • Key: SYSML2-482
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Right now use-case nodes cannot be associated with actors and subjects. They need to be made subject/actor stakeholders

  • Reported: SysML 2.0a1 — Wed, 18 Oct 2023 12:20 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Missalignment between interface graphical production and notation table

  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Notation table shows item flows on interface connections. This is not enabled by the graphical BNF

  • Reported: SysML 2.0a1 — Wed, 18 Oct 2023 11:24 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Incorrect definition elements in interconnection-element

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Definition elements incorrectly appear in graphical BNF productions for interconnection-element. Remove the following from interconnection-element productions: part-def in 8.2.3.11, port-def in 8.2.3.12, connection-def in 8.2.3.13, constraint-def in 8.2.3.19, requirement-def and concern-def in 8.2.3.20, viewpoint-def and view-def in 8.2.3.25.

  • Reported: SysML 2.0b1 — Wed, 18 Oct 2023 13:46 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Clarify bolding of keywords in concrete graphical syntax

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Documentation should be added that bolding of keywords in the graphical notation is optional, and may be used for visual prominence. For example, in representative notation table 16 in subclause 7.17.1 in the actions compartment of a state the keywords entry, do and exit are bolded.

  • Reported: SysML 2.0a1 — Wed, 18 Oct 2023 13:50 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Initializer classes have to be rationalized

  • Key: SYSML2-476
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The intent of "initializer" classes is to factorize the opeations that provide default values for the properties of a target class so that it can be used for both mapping and factory classes. Initializers that do not generalize both a mapping and a factory class are useless and should be remove for clarity

  • Reported: SysML 2.0b1 — Mon, 25 Sep 2023 18:28 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

AssociationClass_Mapping is uncomplete

  • Key: SYSML2-477
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The redefinition of ownedRelationship() is missing the "class" part, i.e. what is defined in its Class aspect

  • Reported: SysML 2.0b1 — Mon, 25 Sep 2023 19:16 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

missing graphical bnf for events and event occurrences

  • Key: SYSML2-475
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Events and event occurrences are supported by the textual syntax, but not by the graphical syntax.
    It is also not mentioned in the representative notation tables

  • Reported: SysML 2.0a1 — Mon, 16 Oct 2023 12:57 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

GBNF for flow connection not mapped to semantics

  • Key: SYSML2-478
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Graphical BNF specifies a flow connection. It is not clearly mapped to a semantic language concept. Should it be merged with a message specified as part of occurences?

  • Reported: SysML 2.0a1 — Wed, 18 Oct 2023 11:15 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

missing graphical bnf for events and event occurrences

  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Events and event occurrences are supported by the textual syntax, but not by the graphical syntax.
    It is also not mentioned in the representative notation tables

  • Reported: SysML 2.0a1 — Mon, 16 Oct 2023 12:57 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Initializer classes have to be rationalized

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The intent of "initializer" classes is to factorize the opeations that provide default values for the properties of a target class so that it can be used for both mapping and factory classes. Initializers that do not generalize both a mapping and a factory class are useless and should be remove for clarity

  • Reported: SysML 2.0b1 — Mon, 25 Sep 2023 18:28 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

AssociationClass_Mapping is uncomplete

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The redefinition of ownedRelationship() is missing the "class" part, i.e. what is defined in its Class aspect

  • Reported: SysML 2.0b1 — Mon, 25 Sep 2023 19:16 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Optional language for documentation

  • Key: SYSML2-472
  • Status: open  
  • Source: Robert Bosch GmbH ( Florian Beer)
  • Summary:

    Informal specification of requirements is realized as body of the documentation.
    Informal requirement specification often contains text formatting and images as illustrations. To facilitate exchange of requirements between different organizations and proper rendering, the used formatting language, the relative root path for included images and their allowed formats have to be aligned.

    • add optional 'language' keyword to doc
    • define the folder containing the sysml file as root for references made from documentation elements within this file

    To provide guidance for users on common formatting

    • reference jpg and png as suggested image formats
    • reference markdown "md" or other low-complex language as suggested formatting language

    example:
    requirement def SomeRequirement

    { doc language="md" /* The imprint of the serial number shall be positioned as shown in the illustration ![PositionOfSerialNumber](/images/PositionOfSerialNumber.png) */ }
  • Reported: SysML 2.0b1 — Mon, 2 Oct 2023 10:36 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Transformation of UML4SysML::State does not consider entry, do, and exit behavior

  • Key: SYSML2-463
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation ignores the entry, do, and exit behavior of a state.

  • Reported: SysML 2.0b1 — Wed, 27 Sep 2023 21:38 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

element-node not defined

  • Key: SYSML2-462
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Sub-clause 8.2.3.3 (dependencies) uses element-node as the source and target of a dependency.
    element-node is not defined anywhere

  • Reported: SysML 2.0a1 — Wed, 27 Sep 2023 10:09 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless

  • Key: SYSML2-473
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Concern_Mapping is a main mapping that calls ConcernOwningMemberships_Mapping in its ownedRelationship() operation, which itself calls ConcernDocumentation_Mapping. However, the one defined in its ancestor Comment_Mapping should do the job without them.
    The redefinition should then be removed and both ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless and should be replace by a simpler version of the ownedRelationship() operation.

  • Reported: SysML 2.0b1 — Thu, 14 Sep 2023 16:56 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Concern_Mapping is a main mapping that calls ConcernOwningMemberships_Mapping in its ownedRelationship() operation, which itself calls ConcernDocumentation_Mapping. However, the one defined in its ancestor Comment_Mapping should do the job without them.
    The redefinition should then be removed and both ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless and should be replace by a simpler version of the ownedRelationship() operation.

  • Reported: SysML 2.0b1 — Thu, 14 Sep 2023 16:56 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Optional language for documentation

  • Status: open  
  • Source: Robert Bosch GmbH ( Florian Beer)
  • Summary:

    Informal specification of requirements is realized as body of the documentation.
    Informal requirement specification often contains text formatting and images as illustrations. To facilitate exchange of requirements between different organizations and proper rendering, the used formatting language, the relative root path for included images and their allowed formats have to be aligned.

    • add optional 'language' keyword to doc
    • define the folder containing the sysml file as root for references made from documentation elements within this file

    To provide guidance for users on common formatting

    • reference jpg and png as suggested image formats
    • reference markdown "md" or other low-complex language as suggested formatting language

    example:
    requirement def SomeRequirement

    { doc language="md" /* The imprint of the serial number shall be positioned as shown in the illustration ![PositionOfSerialNumber](/images/PositionOfSerialNumber.png) */ }
  • Reported: SysML 2.0b1 — Mon, 2 Oct 2023 10:36 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

element-node not defined

  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Sub-clause 8.2.3.3 (dependencies) uses element-node as the source and target of a dependency.
    element-node is not defined anywhere

  • Reported: SysML 2.0a1 — Wed, 27 Sep 2023 10:09 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

ConstraintProperty should be mapped to a AssertConstraintUsage

  • Key: SYSML2-445
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A UML4SysML::ConstraintProperty is currently mapped to a ItemUsage, but should be an AssertConstraintUsage.

  • Reported: SysML 2.0b1 — Sun, 10 Sep 2023 16:27 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

TransitionUsage requires binding to succession with mandatory end multiplicities

  • Key: SYSML2-397
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 7.13.3 (Bindings as Usages) says

    The end features of a binding always have multiplicity [1..1].

    and Clause 8.3.17.9 (TransitionUsage) includes a constraint requiring a (1 to 1) binding between its succession and transitionLink:

    checkTransitionUsageSuccessionBindingConnector
    A TransitionUsage must have an ownedMember that is a BindingConnector between its succession and the
    inherited Feature TransitionPerformances::TransitionPerformance::transitionLink.
    ownedMember->selectByKind(BindingConnector)->exists(b |
    b.relatedFeatures->includes(succession) and
    b.relatedFeatures->includes(resolveGlobal(
    'TransitionPerformances::TransitionPerformance::transitionLink')))

    with similar text in 8.4.13.3 (Transition Usages). A succession will typically have fewer values than its transition usage, because the succession won't be traversed for every value (occurrence) of its source feature, while its transition usage will have the same number of values as the source feature, conflicting with the 1-1 end multiplicities. Compare to the modeling pattern in KerML Clause 9.2.10.1 (Transition Performances Overview), excerpted in KERML-157.

  • Reported: SysML 2.0b1 — Fri, 25 Aug 2023 19:22 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Missing production for n-ary connection definition graphical

  • Key: SYSML2-456
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Subclause 8.2.3.13, specifies the productions for connections. Ballot 3 added a production for n-ary connection usage, but n-ary connection definition (graphical) is still missing

  • Reported: SysML 2.0a1 — Fri, 22 Sep 2023 12:11 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

ChangeEvent should be mapped to an accept action instead of TextualRepresentation

  • Key: SYSML2-448
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In the textual notation, a change event can be represented by an accept action with a when condition. The example below is from the vehicle model.
    transition normal_To_degraded
    first normal
    accept when senseTemperature.temp > Tmax
    do send OverTemp() via targetPort
    then degraded;

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 11:35 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

TimeEvent should be mapped to an accept action instead of TextualRepresentation

  • Key: SYSML2-449
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In the textual notation, a time event can be represented by an accept action with an at or after condition. The example below is from the vehicle model.
    transition normal_To_maintenance
    first normal
    accept at maintenanceTime
    then maintenance;

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 11:42 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Fork/JoinNode succession "other" end multiplicity validations missing

  • Key: SYSML2-450
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.4.12.4 (Control Nodes), under the Join and Fork headings says:

    validateJoinNodeIncomingSuccessions constraint requires that all incoming Successions to a JoinNode have source multiplicity 1..1.

    validateForkNodeOutgoingSuccessions requires that all outgoing Successions from a ForkNode have target multiplicity 1..1.

    but the validation rules are missing from 8.3.16.11 (JoinNode) and 8.3.16.8 (ForkNode), respectively.

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 15:26 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

ConstraintProperty should be mapped to a AssertConstraintUsage

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A UML4SysML::ConstraintProperty is currently mapped to a ItemUsage, but should be an AssertConstraintUsage.

  • Reported: SysML 2.0b1 — Sun, 10 Sep 2023 16:27 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Missing production for n-ary connection definition graphical

  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Subclause 8.2.3.13, specifies the productions for connections. Ballot 3 added a production for n-ary connection usage, but n-ary connection definition (graphical) is still missing

  • Reported: SysML 2.0a1 — Fri, 22 Sep 2023 12:11 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Fork/JoinNode succession "other" end multiplicity validations missing

  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.4.12.4 (Control Nodes), under the Join and Fork headings says:

    validateJoinNodeIncomingSuccessions constraint requires that all incoming Successions to a JoinNode have source multiplicity 1..1.

    validateForkNodeOutgoingSuccessions requires that all outgoing Successions from a ForkNode have target multiplicity 1..1.

    but the validation rules are missing from 8.3.16.11 (JoinNode) and 8.3.16.8 (ForkNode), respectively.

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 15:26 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

TransitionUsage requires binding to succession with mandatory end multiplicities

  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 7.13.3 (Bindings as Usages) says

    The end features of a binding always have multiplicity [1..1].

    and Clause 8.3.17.9 (TransitionUsage) includes a constraint requiring a (1 to 1) binding between its succession and transitionLink:

    checkTransitionUsageSuccessionBindingConnector
    A TransitionUsage must have an ownedMember that is a BindingConnector between its succession and the
    inherited Feature TransitionPerformances::TransitionPerformance::transitionLink.
    ownedMember->selectByKind(BindingConnector)->exists(b |
    b.relatedFeatures->includes(succession) and
    b.relatedFeatures->includes(resolveGlobal(
    'TransitionPerformances::TransitionPerformance::transitionLink')))

    with similar text in 8.4.13.3 (Transition Usages). A succession will typically have fewer values than its transition usage, because the succession won't be traversed for every value (occurrence) of its source feature, while its transition usage will have the same number of values as the source feature, conflicting with the 1-1 end multiplicities. Compare to the modeling pattern in KerML Clause 9.2.10.1 (Transition Performances Overview), excerpted in KERML-157.

  • Reported: SysML 2.0b1 — Fri, 25 Aug 2023 19:22 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

CommentAnnotation_Mapping shall be a "unique" mapping

  • Key: SYSML2-385
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Any execution of the CommentAnnotation_Mapping transformation rule shall result in the same instance of SysMLv2 Annotation for a given (Comment, annotatedElement) pair provided. I.e. it should specialize the Foundations::UniqueMapping class.

  • Reported: SysML 2.0a1 — Sun, 20 Aug 2023 15:12 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Feature modifiers missing in Portion Membership examples

  • Key: SYSML2-353
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add feature modifiers (e.g. ordered for [1..*] timestamps) to "Portion Membership" examples in representative notation tables for Occurrences.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 15:37 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Representative example "Package with members" to be improved

  • Key: SYSML2-357
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The representative notation example "Package with members compartment" shows the members compartment which is the default compartment and does not require a compartment label. Change members compartment label to the requirements compartment label and adjust the package content and textual notation accordingly, i.e. with requirement elements.

  • Reported: SysML 2.0b1 — Thu, 3 Aug 2023 20:39 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Actor and subject parameter notation not effective

  • Key: SYSML2-390
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Actor and subject are parameters of a use case (and also requirement in case of subject). The current notation suggests symbols completely outside the contour of the use case/requirements linked by a line segment. This is different from V1 where actors and subjects were not parameters. Ultimately the modeler is interested to see the binding of those parameters being the concrete occurrences standing for them. The parameter bindings can be graphically represented by binding connections to those external symbols. Would be more effective to treat those predefined parameters using on contour symbols like ports and parameters and bind to those.

  • Reported: SysML 2.0a1 — Thu, 24 Aug 2023 12:11 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Decision/MergeNode SuccessionSpecialization checks missing some constraints

  • Key: SYSML2-383
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Decision/MergeNodes are (indirectly) typed by KerML:Decision/MergePerformance (via specialization of Actions::Action::decisions/merges), which KerML Clause 9.2.9.1 (Control Performances Overview) requires:

    Successions going out of Steps typed by DecisionPerformance or its specializations must:
    • ...
    • be included in a Feature of its featuringBehavior that unions (see 7.3.2.7) all the outgoing Successions, and is bound to the outgoingHBLink of the Step (see 7.3.4.6 on feature chaining).

    Successions coming into Steps typed by MergePerformance or its specializations must:
    • ...
    • subset a Feature of its featuringBehavior that unions all the incoming Successions, and is bound to the incomingHBLink of the Step.

    while constraints in 8.3.16.7 (DecisionNode) and 8.3.16.13 (MergeNode) say

    checkDecisionNodeOutgoingSuccessionSpecialization
    All outgoing Successions from a DecisionNode must subset the inherited outgoingHBLink feature of the DecisionNode.
    sourceConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
    resolveGlobal("ControlPerformances::MergePerformance::outgoingHBLink")))

    checkMergeNodeIncomingSuccessionSpecialization
    All incoming Successions to a MergeNode must subset the inherited incomingHBLink feature of the MergeNode.
    targetConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
    resolveGlobal("ControlPerformances::MergePerformance::incomingHBLink")))

    with similar text in 8.4.12.4 (Control Nodes) under Decision / Merge Nodes. These constraints allow outgoing/incomingHBLink to have values that are not identified by outgoing/incoming successions when none of the successions is traversed. The KerML pattern above introduces a feature unioning the successions and binds it to a chain through decision/merge to outgoing/incomingHBLink, ensuring the HB links are identified by the successions. See Annex A.3.7 (Timing for behaviors, Decisions and merges) for an example, at the end of the model to be executed (first code listing), under "Decision and merge timing constraints".

  • Reported: SysML 2.0b1 — Wed, 16 Aug 2023 17:21 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

CommentAnnotation_Mapping shall be a "unique" mapping

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Any execution of the CommentAnnotation_Mapping transformation rule shall result in the same instance of SysMLv2 Annotation for a given (Comment, annotatedElement) pair provided. I.e. it should specialize the Foundations::UniqueMapping class.

  • Reported: SysML 2.0a1 — Sun, 20 Aug 2023 15:12 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Feature modifiers missing in Portion Membership examples

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add feature modifiers (e.g. ordered for [1..*] timestamps) to "Portion Membership" examples in representative notation tables for Occurrences.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 15:37 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Actor and subject parameter notation not effective

  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Actor and subject are parameters of a use case (and also requirement in case of subject). The current notation suggests symbols completely outside the contour of the use case/requirements linked by a line segment. This is different from V1 where actors and subjects were not parameters. Ultimately the modeler is interested to see the binding of those parameters being the concrete occurrences standing for them. The parameter bindings can be graphically represented by binding connections to those external symbols. Would be more effective to treat those predefined parameters using on contour symbols like ports and parameters and bind to those.

  • Reported: SysML 2.0a1 — Thu, 24 Aug 2023 12:11 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Representative example "Package with members" to be improved

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The representative notation example "Package with members compartment" shows the members compartment which is the default compartment and does not require a compartment label. Change members compartment label to the requirements compartment label and adjust the package content and textual notation accordingly, i.e. with requirement elements.

  • Reported: SysML 2.0b1 — Thu, 3 Aug 2023 20:39 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Feature modefiers missing in Feature Membership examples

  • Key: SYSML2-352
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add feature modifiers (e.g. ordered, nonunique) to "Feature Membership" examples in representative notation tables for Definitions and Usage.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 15:35 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Wrong imported package notation

  • Key: SYSML2-326
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Example "Package with imported packages (nested packages)" should use dotted instead of dashed outline

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:57 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Representative notation for filtered package import missing

  • Key: SYSML2-329
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add example package with filter in 7.5.1. The filter should be one of the filters defined in 9.2.19.2.4. Good choice is filter for Requirement.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:10 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Incomplete example "Individual Occurrence"

  • Key: SYSML2-337
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In examples "Individual Occurrence", "Timeslice", "Snapshot", add attribute to «individual» «occurrence» and redefine the attribute with value in «timeslice» and «snapshot».

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:17 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Package import wildcard is missing

  • Key: SYSML2-327
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add import qualifier text (* or **) to upper right corner of imported Package

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:58 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Wrong imported package notation

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Example "Package with imported packages (nested packages)" should use dotted instead of dashed outline

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:57 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Feature modefiers missing in Feature Membership examples

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add feature modifiers (e.g. ordered, nonunique) to "Feature Membership" examples in representative notation tables for Definitions and Usage.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 15:35 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Incomplete example "Individual Occurrence"

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In examples "Individual Occurrence", "Timeslice", "Snapshot", add attribute to «individual» «occurrence» and redefine the attribute with value in «timeslice» and «snapshot».

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:17 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Package import wildcard is missing

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add import qualifier text (* or **) to upper right corner of imported Package

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:58 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Representative notation for filtered package import missing

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add example package with filter in 7.5.1. The filter should be one of the filters defined in 9.2.19.2.4. Good choice is filter for Requirement.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:10 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Binding between action parameters and directed features on ports missing

  • Key: SYSML2-320
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add graphical notation to represent binding between action inputs and outputs and directed features on ports.

    The request is to add a representative notation example to Table 11 that shows how directed features of performed actions in parts can be connected to directed features of ports.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:14 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Metadata declaration needs clarification

  • Key: SYSML2-317
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Clarify that the identifier for the metadata declaration is the metadata definition name.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:11 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Missing representative notation for causation and requirements derivation

  • Key: SYSML2-324
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add representative notation for causation (9.5.2.1) and requirements derivation (9.6.2.1) including n-arys. This (and other representative notation examples for domain library models) should probably go into the respective 9.x Overview subclauses, rather than in Clause 7.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:33 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Nesting parameter symbol is missing optional nested parameter

  • Key: SYSML2-323
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In the param-t production the nesting parameter pdv is missing an optional nested param-t* element.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:30 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Missing representative notation for causation and requirements derivation

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add representative notation for causation (9.5.2.1) and requirements derivation (9.6.2.1) including n-arys. This (and other representative notation examples for domain library models) should probably go into the respective 9.x Overview subclauses, rather than in Clause 7.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:33 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Metadata declaration needs clarification

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Clarify that the identifier for the metadata declaration is the metadata definition name.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:11 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Binding between action parameters and directed features on ports missing

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add graphical notation to represent binding between action inputs and outputs and directed features on ports.

    The request is to add a representative notation example to Table 11 that shows how directed features of performed actions in parts can be connected to directed features of ports.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:14 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Nesting parameter symbol is missing optional nested parameter

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In the param-t production the nesting parameter pdv is missing an optional nested param-t* element.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:30 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Mapping of ObjectFlows with ForkNodes

  • Key: SYSML2-313
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In SysML v1, an output value of an action that is an input value of more than one action, is often modeled by an object flow and fork node which create object tokens pointing to the value.

    The mapping of ObjectFlow in combination with ForkNodes is not covered yet by the transformation.

  • Reported: SysML 2.0b1 — Mon, 24 Jul 2023 13:16 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Mapping of ObjectFlows with DecisionNodes

  • Key: SYSML2-315
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of ObjectFlow in combination with DecisionNodes including the decisionInput is not covered yet by the transformation.

  • Reported: SysML 2.0b1 — Mon, 24 Jul 2023 14:47 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Mapping of ObjectFlows with JoinNodes

  • Key: SYSML2-314
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of ObjectFlow in combination with JoinNodes is not covered yet by the transformation.

  • Reported: SysML 2.0b1 — Mon, 24 Jul 2023 14:30 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Symbol for metadata def is missing

  • Key: SYSML2-316
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add support for defining a metadata definition using the normal definition symbol (e.g., key word metadata def with metadata def name in name compartment). Separate compartment for attribute declarations. Add compartment redefined the annotated elements so they are constrained to be of a certain metaclass. (Note that MetadataDefinition is a kind of ItemDefinition but MetadataFeature (and therefore MetadataUsage) is a kind of AnnotatingElement.)

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:09 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover the mapping of Unit and QuantityKind

  • Key: SYSML2-311
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of a Unit and a QuantityKind is not covered by the transformation yet.

  • Reported: SysML 2.0b1 — Thu, 20 Jul 2023 15:04 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT
  • Attachments:

SysML Libraries' elements shall have an elementId defined

  • Key: SYSML2-297
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The way SysML libraries are provided relies on textual notation files on which element declarations do not include the specification of their elementId property.

    As consequence, if the elementId is actually generated by the tool, as written in the KerML specification (p226), it is very likely to have a different value from one computer to another and even from one loading to another on the same computer.

    Hence, it is impossible to make sure it will "not change during the lifetime of the Element", as required by in the same paragraph of that specification.

    Linked to a similar issue raised on KerML

  • Reported: SysML 2.0a1 — Thu, 13 Jul 2023 06:51 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

the getMapped operation cannot be called on ElementOwnership_Mapping

  • Key: SYSML2-286
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Since Relationship is now an abstract class, ElementOwnership_Mapping has been made abstract as well. A consequence of this, because it is not a "MainMapping", is that it is not possible to invoke the getMapped operation directly on this mapping class.
    However there are many body conditions that still that. They have to be fixed.

  • Reported: SysML 2.0a1 — Tue, 4 Jul 2023 20:16 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Various constraints need to take feature chaining into account

  • Key: SYSML2-307
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    There are a number of cases in which derived properties require that a referenced feature by of a certain metaclass. For example, the EventOccurrenceUsage::eventOccurrence property is derived as the referencedFeature of the ownedReferenceSubsetting EventOccurrenceUsage (if it has one), but the property is typed as an OccurrenceUsage, so the referencedFeature must be an OccurrenceUsage. This is enforced by the validateEventOccurrenceUsageReference constraint.

    Unfortunately, this does not take feature chaining into account. If the referencedFeature has a feature chain, it will be parsed as a plain Feature, not an OccurrenceUsage. However, the last Feature in the chain should be an OccurrenceUsage, and this OccurrenceUsage is what should be the eventOccurrence of the EventOccurrenceUsage, and what is check by validateEventOccurrenceUsageReference.

    There are similar problems with at least the "reference" derivation and validation constraints for all the subtypes of EventOccurrenceUsage, and perhaps in other cases, too.

  • Reported: SysML 2.0b1 — Sun, 16 Jul 2023 21:30 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover mapping of Parameter::isStreaming=true

  • Key: SYSML2-309
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not map the Parameter::isStreaming.

  • Reported: SysML 2.0b1 — Tue, 18 Jul 2023 17:12 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover mapping of Parameter::isStreaming=true

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not map the Parameter::isStreaming.

  • Reported: SysML 2.0b1 — Tue, 18 Jul 2023 17:12 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

SysML Libraries' elements shall have an elementId defined

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The way SysML libraries are provided relies on textual notation files on which element declarations do not include the specification of their elementId property.

    As consequence, if the elementId is actually generated by the tool, as written in the KerML specification (p226), it is very likely to have a different value from one computer to another and even from one loading to another on the same computer.

    Hence, it is impossible to make sure it will "not change during the lifetime of the Element", as required by in the same paragraph of that specification.

    Linked to a similar issue raised on KerML

  • Reported: SysML 2.0a1 — Thu, 13 Jul 2023 06:51 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover the mapping of Unit and QuantityKind

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of a Unit and a QuantityKind is not covered by the transformation yet.

  • Reported: SysML 2.0b1 — Thu, 20 Jul 2023 15:04 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT
  • Attachments:

the getMapped operation cannot be called on ElementOwnership_Mapping

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Since Relationship is now an abstract class, ElementOwnership_Mapping has been made abstract as well. A consequence of this, because it is not a "MainMapping", is that it is not possible to invoke the getMapped operation directly on this mapping class.
    However there are many body conditions that still that. They have to be fixed.

  • Reported: SysML 2.0a1 — Tue, 4 Jul 2023 20:16 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Various constraints need to take feature chaining into account

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    There are a number of cases in which derived properties require that a referenced feature by of a certain metaclass. For example, the EventOccurrenceUsage::eventOccurrence property is derived as the referencedFeature of the ownedReferenceSubsetting EventOccurrenceUsage (if it has one), but the property is typed as an OccurrenceUsage, so the referencedFeature must be an OccurrenceUsage. This is enforced by the validateEventOccurrenceUsageReference constraint.

    Unfortunately, this does not take feature chaining into account. If the referencedFeature has a feature chain, it will be parsed as a plain Feature, not an OccurrenceUsage. However, the last Feature in the chain should be an OccurrenceUsage, and this OccurrenceUsage is what should be the eventOccurrence of the EventOccurrenceUsage, and what is check by validateEventOccurrenceUsageReference.

    There are similar problems with at least the "reference" derivation and validation constraints for all the subtypes of EventOccurrenceUsage, and perhaps in other cases, too.

  • Reported: SysML 2.0b1 — Sun, 16 Jul 2023 21:30 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::ReadLinkAction

  • Key: SYSML2-272
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::ReadLinkAction.

  • Reported: SysML 2.0a1 — Fri, 30 Jun 2023 18:56 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::DestroyLinkAction

  • Key: SYSML2-274
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::DestroyLinkAction.

  • Reported: SysML 2.0a1 — Fri, 30 Jun 2023 18:59 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation of UML4SysML::AcceptEventAction with more than one triggers not covered yet

  • Key: SYSML2-283
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Currently, the transformation supports only AcceptEventActions with one trigger, but it could be many.

  • Reported: SysML 2.0a1 — Mon, 3 Jul 2023 16:34 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::FunctionBehavior

  • Key: SYSML2-284
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::FunctionBehavior.

  • Reported: SysML 2.0a1 — Tue, 4 Jul 2023 10:30 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::CreateLinkAction

  • Key: SYSML2-273
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::CreateLinkAction.

  • Reported: SysML 2.0a1 — Fri, 30 Jun 2023 18:58 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::FunctionBehavior

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::FunctionBehavior.

  • Reported: SysML 2.0a1 — Tue, 4 Jul 2023 10:30 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::CreateLinkAction

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::CreateLinkAction.

  • Reported: SysML 2.0a1 — Fri, 30 Jun 2023 18:58 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::ReadLinkAction

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::ReadLinkAction.

  • Reported: SysML 2.0a1 — Fri, 30 Jun 2023 18:56 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation of UML4SysML::AcceptEventAction with more than one triggers not covered yet

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Currently, the transformation supports only AcceptEventActions with one trigger, but it could be many.

  • Reported: SysML 2.0a1 — Mon, 3 Jul 2023 16:34 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::DestroyLinkAction

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::DestroyLinkAction.

  • Reported: SysML 2.0a1 — Fri, 30 Jun 2023 18:59 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::SignalEvent

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::SignalEvent.

  • Reported: SysML 2.0a1 — Fri, 30 Jun 2023 18:53 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::SignalEvent

  • Key: SYSML2-271
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::SignalEvent.

  • Reported: SysML 2.0a1 — Fri, 30 Jun 2023 18:53 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover the different UML4SysML::PseudoStates

  • Key: SYSML2-187
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation generally maps a PseudoState, but does not distinguish between the different kinds of pseudostates.

  • Reported: SysML 2.0a1 — Sat, 6 May 2023 12:22 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Some Standard View Definitions should be filtered specializations of General View

  • Key: SYSML2-225
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Some Standard View Definitions, like Case View, are not a self-standing view, but are effectively a General View with a specific filter applied.

    Add filtered views as specializations of General View into the first table "Standard View Definitions" of clause 9.2.19.1, in particular Case View, with an explicit filter declaration.

  • Reported: SysML 2.0a1 — Wed, 14 Jun 2023 10:44 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation of UML4SysML::InterruptibleActivityRegion is not specified yet


Graphical notation of State Definition not consistent with other submission documents

  • Key: SYSML2-199
  • Status: open  
  • Source: CARIAD SE ( Zahir Ismail)
  • Summary:

    There are different implementations of the SysML v2 graphical notation in the various release documents

    Documents checked:
    2-OMG_Systems_Modeling_Language.pdf Version 2.0 Release 2023-02
    Intro to the SysML v2 Language-Graphical Notation.pdf (2023 03 07)
    Intro to the SysML v2 Language-Textual Notation.pdf Release: 2023-02

    Example of difference, on page 218 of "2-OMG_Systems_Modeling_Language.pdf", the stereotype identifier (<<state>>) is not displayed for State1 and State2, in the "Intro to the SysML v2 Language-Graphical Notation.pdf", the "<<state>>" is displayed.

    If you then take a look at the "Intro to the SysML v2 Language-Textual Notation.pdf" document, there is again a different graphical notation.

    What is the correct standard notation? Does the "2-OMG_Systems_Modeling_Language.pdf" take precedence here?

  • Reported: SysML 2.0a1 — Fri, 12 May 2023 08:13 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Some Standard View Definitions should be filtered specializations of General View

  • Key: SYSML2_-99
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Some Standard View Definitions, like Case View, are not a self-standing view, but are effectively a General View with a specific filter applied.

    Add filtered views as specializations of General View into the first table "Standard View Definitions" of clause 9.2.19.1, in particular Case View, with an explicit filter declaration.

  • Reported: SysML 2.0a1 — Wed, 14 Jun 2023 10:44 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation of UML4SysML::InterruptibleActivityRegion is not specified yet


Transformation does not cover the different UML4SysML::PseudoStates

  • Key: SYSML2_-96
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation generally maps a PseudoState, but does not distinguish between the different kinds of pseudostates.

  • Reported: SysML 2.0a1 — Sat, 6 May 2023 12:22 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Graphical notation of State Definition not consistent with other submission documents

  • Key: SYSML2_-98
  • Status: open  
  • Source: CARIAD SE ( Zahir Ismail)
  • Summary:

    There are different implementations of the SysML v2 graphical notation in the various release documents

    Documents checked:
    2-OMG_Systems_Modeling_Language.pdf Version 2.0 Release 2023-02
    Intro to the SysML v2 Language-Graphical Notation.pdf (2023 03 07)
    Intro to the SysML v2 Language-Textual Notation.pdf Release: 2023-02

    Example of difference, on page 218 of "2-OMG_Systems_Modeling_Language.pdf", the stereotype identifier (<<state>>) is not displayed for State1 and State2, in the "Intro to the SysML v2 Language-Graphical Notation.pdf", the "<<state>>" is displayed.

    If you then take a look at the "Intro to the SysML v2 Language-Textual Notation.pdf" document, there is again a different graphical notation.

    What is the correct standard notation? Does the "2-OMG_Systems_Modeling_Language.pdf" take precedence here?

  • Reported: SysML 2.0a1 — Fri, 12 May 2023 08:13 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Some package-level features are mandatory

  • Key: SYSML2-183
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Package-level features do not give featuring types, and some have lower multiplicity greater than zero, meaning everything in the universe (instances of Anything), including every data value, is required to give at least that number of values to them (see KERML-56). For example, the libraries include:

    Time::universalClock[1] {...} 
    Observation::defaultMonitor[1] : ChangeMonitor[1] {...}
    SpatialFrames::defaultFrame : SpatialFrame[1] {...}
    

    Might be others.

  • Reported: SysML 2.0a1 — Wed, 3 May 2023 15:17 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

ConstraintBlock mapping parameters to input attributes

  • Key: SYSML2-186
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In SysML 1.7, Clause 10.1 (Overview, Constraint Blocks) and 10.3.2.1 (ConstraintBlock) say:

    Constraint blocks define generic forms of constraints that can be used in multiple contexts. For example, a definition for Newton’s Laws may be used to specify these constraints in many different contexts. Constraint blocks can be used to specify a network of constraints that represent mathematical expressions such as {F=m*a} and {a=dv/dt}, which constrain the physical properties of a system.

    A constraint block is a block that packages the statement of a constraint so it may be applied in a reusable way to constrain properties of other blocks. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used.

    enabling an equation to "calculate" any of its variables (constraint parameters), to the extent it's reversible, depending on its usage. For example a constraint block for F=m*a can calculate any on of its variables given the other two by where it's used. But in SysML v1 to SysML v2 Transformation, 7.8.5.2.1 (ConstraintBlock_Mapping) says

    A SysML::ConstraintBlocks::ConstraintBlock is mapped to a SysML v2 ConstraintDefinition. The following shows an example of what the textual SysML v2 syntax of the result of the transformation may look like.

    onstraint def SysMLv1ConstraintBlock {
    in attribute a : ScalarValues::Integer;
    in attribute b : ScalarValues::Integer;
    in attribute c : ScalarValues::Integer;
    constraint constraintExpression {
      language "OCL2.0"  /* c == a + b */ } }
    

    suggests constraint parameters are mapped to attributes with direction in, preventing them from being "calculated" from within the constraint (see KERML-10).

    Not sure if the above is encoded in the mapping rules, but perhaps related is 7.8.5.2.2 (ConstraintParameter_Mapping), under Mapping Rules, says

    The mapping class only has inherited rules. See the mapping classes in the general mapping section for details.

    which means nothing specific is required for mapping constraint parameters. I couldn't find a "general mapping section".

  • Reported: SysML 2.0a1 — Thu, 4 May 2023 15:26 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Machine readable project interchange file(s) for language description examples

  • Key: SYSML2-160
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Clause 7 Language Description includes a large number of example models and snippets, in textual and graphical notation. However, no machine-readable interchange file was submitted for these models. Project interchange files should be provided for them, including textual notation, XMI and JSON versions.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 20:33 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

XMI and JSON for example model

  • Key: SYSML2-161
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    There is a machine-readable file containing the example model described in Annex A, but only in the textual notation. There should also be machine-readable versions of this model represented in XMI and JSON.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 20:37 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Assignment action usages do not specify when their expressions are evaluated

  • Key: SYSML2-177
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.3.16.5 (AssignmentActionUsage), Description, says:

    An AssignmentActionUsage is an ActionUsage that is defined, directly or indirectly, by the ActionDefinition AssignmentAction from the Systems Model Library. It specifies that the value of the referent Feature, relative to the target given by the result of the targetArgument Expression, should be set to the result of the valueExpression.

    but does not require the model to specify when the expression is evaluated (or its owner, AFAICT).

  • Reported: SysML 2.0a1 — Tue, 2 May 2023 20:38 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Machine readable project interchange file(s) for language description examples

  • Key: SYSML2_-91
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Clause 7 Language Description includes a large number of example models and snippets, in textual and graphical notation. However, no machine-readable interchange file was submitted for these models. Project interchange files should be provided for them, including textual notation, XMI and JSON versions.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 20:33 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

XMI and JSON for example model

  • Key: SYSML2_-92
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    There is a machine-readable file containing the example model described in Annex A, but only in the textual notation. There should also be machine-readable versions of this model represented in XMI and JSON.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 20:37 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Assignment action usages do not specify when their expressions are evaluated

  • Key: SYSML2_-93
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.3.16.5 (AssignmentActionUsage), Description, says:

    An AssignmentActionUsage is an ActionUsage that is defined, directly or indirectly, by the ActionDefinition AssignmentAction from the Systems Model Library. It specifies that the value of the referent Feature, relative to the target given by the result of the targetArgument Expression, should be set to the result of the valueExpression.

    but does not require the model to specify when the expression is evaluated (or its owner, AFAICT).

  • Reported: SysML 2.0a1 — Tue, 2 May 2023 20:38 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

ConstraintBlock mapping parameters to input attributes

  • Key: SYSML2_-95
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In SysML 1.7, Clause 10.1 (Overview, Constraint Blocks) and 10.3.2.1 (ConstraintBlock) say:

    Constraint blocks define generic forms of constraints that can be used in multiple contexts. For example, a definition for Newton’s Laws may be used to specify these constraints in many different contexts. Constraint blocks can be used to specify a network of constraints that represent mathematical expressions such as {F=m*a} and {a=dv/dt}, which constrain the physical properties of a system.

    A constraint block is a block that packages the statement of a constraint so it may be applied in a reusable way to constrain properties of other blocks. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used.

    enabling an equation to "calculate" any of its variables (constraint parameters), to the extent it's reversible, depending on its usage. For example a constraint block for F=m*a can calculate any on of its variables given the other two by where it's used. But in SysML v1 to SysML v2 Transformation, 7.8.5.2.1 (ConstraintBlock_Mapping) says

    A SysML::ConstraintBlocks::ConstraintBlock is mapped to a SysML v2 ConstraintDefinition. The following shows an example of what the textual SysML v2 syntax of the result of the transformation may look like.

    onstraint def SysMLv1ConstraintBlock {
    in attribute a : ScalarValues::Integer;
    in attribute b : ScalarValues::Integer;
    in attribute c : ScalarValues::Integer;
    constraint constraintExpression {
      language "OCL2.0"  /* c == a + b */ } }
    

    suggests constraint parameters are mapped to attributes with direction in, preventing them from being "calculated" from within the constraint (see KERML-10).

    Not sure if the above is encoded in the mapping rules, but perhaps related is 7.8.5.2.2 (ConstraintParameter_Mapping), under Mapping Rules, says

    The mapping class only has inherited rules. See the mapping classes in the general mapping section for details.

    which means nothing specific is required for mapping constraint parameters. I couldn't find a "general mapping section".

  • Reported: SysML 2.0a1 — Thu, 4 May 2023 15:26 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Some package-level features are mandatory

  • Key: SYSML2_-94
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Package-level features do not give featuring types, and some have lower multiplicity greater than zero, meaning everything in the universe (instances of Anything), including every data value, is required to give at least that number of values to them (see KERML-56). For example, the libraries include:

    Time::universalClock[1] {...} 
    Observation::defaultMonitor[1] : ChangeMonitor[1] {...}
    SpatialFrames::defaultFrame : SpatialFrame[1] {...}
    

    Might be others.

  • Reported: SysML 2.0a1 — Wed, 3 May 2023 15:17 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::NoBuffer

  • Key: SYSML2-151
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::NoBuffer.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 08:03 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Accepters on transition usages from entry actions

  • Key: SYSML2-152
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.17.3 Transition Usages, in the fourth text paragraph, it states:

    Transition usages from the entry action are not allowed to have accepters.

    There is no validation constraint for this in the abstract syntax.

    Is this constraint necessary? If so, a validation constraint should be added. If not, the statement in 7.17.3 should be removed.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 19:29 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Subject of an include use case usage

  • Key: SYSML2-154
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.24.1 Use Cases Overview, in the third paragraph, it states:

    The subject of the included use case is the same as the subject of the containing use case...

    In 7.24.3 Include Use Case Usages, in the third paragraph, it also states:

    The subject of an included use case usage is bound by default to the subject of its containing use case definition or usage.

    However, there is no semantic constraint in the abstract syntax to enforce this.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 19:40 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::Overwrite

  • Key: SYSML2-150
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::Overwrite.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 08:02 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Accepters on transition usages from entry actions

  • Key: SYSML2_-89
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.17.3 Transition Usages, in the fourth text paragraph, it states:

    Transition usages from the entry action are not allowed to have accepters.

    There is no validation constraint for this in the abstract syntax.

    Is this constraint necessary? If so, a validation constraint should be added. If not, the statement in 7.17.3 should be removed.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 19:29 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Subject of an include use case usage

  • Key: SYSML2_-90
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.24.1 Use Cases Overview, in the third paragraph, it states:

    The subject of the included use case is the same as the subject of the containing use case...

    In 7.24.3 Include Use Case Usages, in the third paragraph, it also states:

    The subject of an included use case usage is bound by default to the subject of its containing use case definition or usage.

    However, there is no semantic constraint in the abstract syntax to enforce this.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 19:40 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::NoBuffer

  • Key: SYSML2_-88
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::NoBuffer.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 08:03 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::Overwrite

  • Key: SYSML2_-87
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::Overwrite.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 08:02 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::BoundReference

  • Key: SYSML2-145
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::BoundReference.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:57 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::EndPathMultiplicity

  • Key: SYSML2-147
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::EndPathMultiplicity.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 08:00 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::ParticipantProperty

  • Key: SYSML2-146
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::ParticipantProperty.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:57 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::PropertySpecificType

  • Key: SYSML2-148
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::PropertySpecificType.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 08:01 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::AllocateActivitiyPartition

  • Key: SYSML2-149
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::AllocateActivityPartition.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 08:02 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::ParticipantProperty

  • Key: SYSML2_-83
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::ParticipantProperty.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:57 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::PropertySpecificType

  • Key: SYSML2_-85
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::PropertySpecificType.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 08:01 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::AllocateActivitiyPartition

  • Key: SYSML2_-86
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::AllocateActivityPartition.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 08:02 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::EndPathMultiplicity

  • Key: SYSML2_-84
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::EndPathMultiplicity.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 08:00 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::BoundReference

  • Key: SYSML2_-82
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::BoundReference.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:57 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::InvocationOnNestedPortAction

  • Key: SYSML2-140
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::InvocationOnNestedPortAction.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:51 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::Conform

  • Key: SYSML2-142
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::Conform.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:54 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::DistributedProperty

  • Key: SYSML2-144
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::DistributedProperty.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:55 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::Expose

  • Key: SYSML2-143
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::Expose.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:54 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::View

  • Key: SYSML2-141
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::View.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:53 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::View

  • Key: SYSML2_-78
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::View.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:53 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::InvocationOnNestedPortAction

  • Key: SYSML2_-77
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::InvocationOnNestedPortAction.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:51 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::Conform

  • Key: SYSML2_-79
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::Conform.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:54 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::DistributedProperty

  • Key: SYSML2_-81
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::DistributedProperty.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:55 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::Expose

  • Key: SYSML2_-80
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::Expose.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:54 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::TriggerOnNestedPort

  • Key: SYSML2-135
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::TriggerOnNestedPort.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:46 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::UnmarshallAction

  • Key: SYSML2-134
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::UnmarshallAction.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:45 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::ChangeStructuralFeatureEvent

  • Key: SYSML2-136
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::ChangeStructuralFeatureEvent.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:47 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::AddFlowPropertyValueOnNestedPortAction

  • Key: SYSML2-137
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::AddFlowPropertyValueOnNestedPortAction.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:48 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::FlowProperty

  • Key: SYSML2-138
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::FlowProperty.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:49 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::AddFlowPropertyValueOnNestedPortAction

  • Key: SYSML2_-75
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::AddFlowPropertyValueOnNestedPortAction.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:48 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::TriggerOnNestedPort

  • Key: SYSML2_-73
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::TriggerOnNestedPort.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:46 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::UnmarshallAction

  • Key: SYSML2_-72
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::UnmarshallAction.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:45 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover SysMLv1::ChangeStructuralFeatureEvent

  • Key: SYSML2_-74
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::ChangeStructuralFeatureEvent.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:47 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Clause

  • Key: SYSML2-129
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::Clause.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:42 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::LinkEndData

  • Key: SYSML2-133
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::LinkEndData.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:45 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::LinkEndCreationData

  • Key: SYSML2-131
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::LinkEndCreationData.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:43 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::LinkEndDestructionData

  • Key: SYSML2-132
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::LinkEndDestructionData.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:44 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::ActivityPartition

  • Key: SYSML2-128
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::ActivityPartition.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:41 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::ConditionalNode

  • Key: SYSML2-130
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::ConditionalNode.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:42 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::LinkEndData

  • Key: SYSML2_-71
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::LinkEndData.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:45 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::ActivityPartition

  • Key: SYSML2_-66
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::ActivityPartition.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:41 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Clause

  • Key: SYSML2_-67
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::Clause.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:42 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::LinkEndDestructionData

  • Key: SYSML2_-70
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::LinkEndDestructionData.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:44 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::ConditionalNode

  • Key: SYSML2_-68
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::ConditionalNode.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:42 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::LinkEndCreationData

  • Key: SYSML2_-69
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::LinkEndCreationData.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:43 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::ExecutionOccurrenceSpecification

  • Key: SYSML2-124
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::ExecutionOccurrenceSpecification.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:22 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Gate

  • Key: SYSML2-125
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::Gate.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:37 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::OccurrenceSpecification

  • Key: SYSML2-126
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::OccurrenceSpecification.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:38 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::InteractionConstraint

  • Key: SYSML2-127
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::InteractionConstraint.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:39 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::InteractionConstraint

  • Key: SYSML2_-65
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::InteractionConstraint.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:39 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Gate

  • Key: SYSML2_-63
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::Gate.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:37 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::ExecutionOccurrenceSpecification

  • Key: SYSML2_-62
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::ExecutionOccurrenceSpecification.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:22 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::OccurrenceSpecification

  • Key: SYSML2_-64
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::OccurrenceSpecification.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:38 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Continuation

  • Key: SYSML2-120
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::Continuation.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:18 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::GeneralOrdering

  • Key: SYSML2-121
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::GeneralOrdering.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:19 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::PartDecomposition

  • Key: SYSML2-122
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::PartDecomposition.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:21 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::ConsiderIgnoreFragment

  • Key: SYSML2-123
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::ConsiderIgnoreFragment.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:21 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Continuation

  • Key: SYSML2_-58
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::Continuation.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:18 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::PartDecomposition

  • Key: SYSML2_-60
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::PartDecomposition.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:21 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::GeneralOrdering

  • Key: SYSML2_-59
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::GeneralOrdering.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:19 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::ConsiderIgnoreFragment

  • Key: SYSML2_-61
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::ConsiderIgnoreFragment.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:21 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::TimeConstraint

  • Key: SYSML2-116
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::TimeConstraint.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:15 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::DestructionOccurrenceSpecification

  • Key: SYSML2-119
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::DestructionOccurrenceSpecification.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:18 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Interval

  • Key: SYSML2-117
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::Interval.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:16 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::DurationInterval

  • Key: SYSML2-115
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::DurationInterval.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:15 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Image

  • Key: SYSML2-118
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::Image.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:17 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::TimeConstraint

  • Key: SYSML2_-54
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::TimeConstraint.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:15 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Image

  • Key: SYSML2_-56
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::Image.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:17 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::DestructionOccurrenceSpecification

  • Key: SYSML2_-57
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::DestructionOccurrenceSpecification.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:18 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::DurationInterval

  • Key: SYSML2_-53
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::DurationInterval.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:15 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Interval

  • Key: SYSML2_-55
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::Interval.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:16 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::IntervalConstraint

  • Key: SYSML2-112
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::IntervalConstraint.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:12 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::DurationObservation

  • Key: SYSML2-113
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::DurationObservation.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:13 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::TimeObservation

  • Key: SYSML2-111
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::TimeObservation.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:12 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::StringExpression

  • Key: SYSML2-114
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::StringExpression.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:14 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Duration

  • Key: SYSML2-110
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::Duration.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:11 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::StringExpression

  • Key: SYSML2_-52
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::StringExpression.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:14 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::DurationObservation

  • Key: SYSML2_-51
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::DurationObservation.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:13 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::TimeObservation

  • Key: SYSML2_-49
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::TimeObservation.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:12 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::IntervalConstraint

  • Key: SYSML2_-50
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::IntervalConstraint.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:12 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Duration

  • Key: SYSML2_-48
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::Duration.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:11 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Extend

  • Key: SYSML2-107
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The extend relationship between use cases is not covered by the transformation.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:07 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation of UML4SysML::ActivityFinalNode is not specified yet

  • Key: SYSML2-106
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of a UML4SysML::ActivityFinalNode is not covered by the transformation rules.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:04 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation of UML4SysML::DataStoreNode and UML4SysML::CentralBufferNode is not complete

  • Key: SYSML2-105
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The details of the mapping of UML4SysML::DataStoreNode and UML4SysML::CentralBufferNode are not specified.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:01 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::DurationConstraint

  • Key: SYSML2-109
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::DurationConstraint.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:10 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::TimeInterval

  • Key: SYSML2-108
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::TimeInterval.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:09 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation of UML4SysML::DataStoreNode and UML4SysML::CentralBufferNode is not complete

  • Key: SYSML2_-43
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The details of the mapping of UML4SysML::DataStoreNode and UML4SysML::CentralBufferNode are not specified.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:01 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::DurationConstraint

  • Key: SYSML2_-47
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::DurationConstraint.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:10 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::Extend

  • Key: SYSML2_-45
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The extend relationship between use cases is not covered by the transformation.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:07 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::TimeInterval

  • Key: SYSML2_-46
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for UML4SysML::TimeInterval.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:09 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Semantics of transfers across interfaces

  • Key: SYSML2-97
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.16.1 Actions Overview, in the "Bindings and Flows Between Actions" section, it states in the last paragraph (italics added):

    A send action usage includes an expression that is evaluated to provide the values to be transferred, and it specifies the destination to which those values are to be sent (possibly delegated through a port and across one or more interfaces – see also 7.12 and 7.14 on interfaces between ports).

    However, the semantics of "delagation across an interface", per the italicized part above, are not described in 7.12 or 7.14, nor are they specified in 8.4.10 Interfaces Semantics.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 21:23 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::GeneralizationSet

  • Key: SYSML2-104
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not include a mapping for UML4SysML::GeneralizationSet.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 06:56 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Semantics of a conditional succession using "else" are missing

  • Key: SYSML2-100
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.16.5 Conditional Successions, in the second paragraph, it states:

    Further, the keyword else may be used in place of a guard expression to indicate a succession to be taken if the guards evaluate to false on all of an immediately preceding set of conditional successions.

    In 8.2.2.16.7, a conditional succession with the else keyword is parsed as a TransitionUsage that simply does not have a guard condition:

    DefaultTargetSuccession : TransitionUsage =
        'else' ownedRelationship += TransitionSuccessionMember
    

    However, the semantics of such a TransitionUsage would seem to be that it can be taken unconditionally, not that it can only be taken if preceding conditional successions have guards that evaluate to false. The else case is not mentioned at all in 8.4.12.3 Decision Transition Usages, which covers the semantics of conditional successions.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 22:10 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Port transfer semantics

  • Key: SYSML2-98
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.12.1 Ports Overview, at the end of the third paragraph, it states

    A transfer can occur from the out features of one port usage to the matching in features of connected port usages. Transfers can occur in both directions between matching inout features.

    It is unclear whether this is intended to mean that such transfers happen automatically in some way, or if it just means that it is possible to have such transfers by adding explicit flows to the model. If the former is intended, then this does not seem to be currently supported by port semantics (8.4.8). If the latter is intended, this should be made more clear.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 21:28 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover UML4SysML::GeneralizationSet

  • Key: SYSML2_-42
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not include a mapping for UML4SysML::GeneralizationSet.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 06:56 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Add standard domain libraries for mathematical and physical constants


Add capability to specify accuracy, uncertainty or tolerance for numerical values

  • Key: SYSML2-86
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The SysML v2 RFP included Requirement PRP 1.15 “Probabilistic Value Distributions", which stated:

    Proposals for SysML v2 shall include a capability to represent the value of a quantity with a probabilistic value distribution, including an extensible mechanism to detail the kind of distribution, i.e. the probability density function for continuous random variables, or the probability mass function for discrete random variables.

    This requirement was not satisfied in the SysML specification as submitted. A capability should be added that covers this requirement. It should at least be possible to represent a numerical value as a symmetric or asymmetric accuracy, uncertainty or tolerance, with a uniform (i.e., rectangular) distribution.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 21:53 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Redefining feature information missing from specification document

  • Key: SYSML2-90
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Multiplicities and bound values of redefining features don't seem to show up in the specification. For example, Clause 9.7.3.2.40 (Toroid) redefines edges, faces, and genus, but does not show the redefining multiplicities or bound values that appear in ShapeItems.kerml and the repository from which this part of the spec was generated. Might be other kinds of information missing on other redefining features.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 19:33 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

XMI and JSON for model libraries

  • Key: SYSML2-91
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Project interchange files (.kpar) were submitted for all model libraries. However, in all cases, these archives only included textual notation model interchange files (.sysml). There should also be normative model library project interchange files in which the models are formatted in XMI and JSON.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 19:54 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Incorrect action name in graphical notation example

  • Key: SYSML2-96
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.15.1 Allocations Overview, Table 17, entry for "Allocation (with sub allocation)", the name acton1 in the graphical notation should be action1.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 21:07 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Add standard domain libraries for mathematical and physical constants


Add capability to specify accuracy, uncertainty or tolerance for numerical values

  • Key: SYSML2_-34
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The SysML v2 RFP included Requirement PRP 1.15 “Probabilistic Value Distributions", which stated:

    Proposals for SysML v2 shall include a capability to represent the value of a quantity with a probabilistic value distribution, including an extensible mechanism to detail the kind of distribution, i.e. the probability density function for continuous random variables, or the probability mass function for discrete random variables.

    This requirement was not satisfied in the SysML specification as submitted. A capability should be added that covers this requirement. It should at least be possible to represent a numerical value as a symmetric or asymmetric accuracy, uncertainty or tolerance, with a uniform (i.e., rectangular) distribution.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 21:53 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Redefining feature information missing from specification document

  • Key: SYSML2_-36
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Multiplicities and bound values of redefining features don't seem to show up in the specification. For example, Clause 9.7.3.2.40 (Toroid) redefines edges, faces, and genus, but does not show the redefining multiplicities or bound values that appear in ShapeItems.kerml and the repository from which this part of the spec was generated. Might be other kinds of information missing on other redefining features.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 19:33 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

XMI and JSON for model libraries

  • Key: SYSML2_-37
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Project interchange files (.kpar) were submitted for all model libraries. However, in all cases, these archives only included textual notation model interchange files (.sysml). There should also be normative model library project interchange files in which the models are formatted in XMI and JSON.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 19:54 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Incorrect action name in graphical notation example

  • Key: SYSML2_-38
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.15.1 Allocations Overview, Table 17, entry for "Allocation (with sub allocation)", the name acton1 in the graphical notation should be action1.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 21:07 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Resolve "TODO" in domain library model Time

  • Key: SYSML2-77
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The declaration of attribute def Iso860DateTimeEncoding in the Quantities and Units Domain Library model Time.sysml still has a TODO comment (line 199):

     * TODO: Add constraint to verify ISO 8691 extended string encoding.
    
  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 18:47 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Extend ISQ with missing quantity and unit types for US Customary Units

  • Key: SYSML2-82
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The US Customary Units as specified in NIST SP811 Annex B include a number of units for which the corresponding quantity is not defined in ISO/IEC 80000, the International System of Quantities (ISQ). These units are currently commented out in Quantities and Units Domain Library USCustomaryUnits. Examples are:

    //attribute <'Btu_IT/ft³'> 'British thermal unit (IT) per cubic foot' : EnergyDensityUnit = Btu_IT/ft^3;
    //attribute <'gal/(hp⋅h)'> 'gallon (US) per horsepower hour' : EnergySpecificVolumeUnit = gal/(hp*h);
    //attribute <'mi/gal'> 'mile per gallon (US)' : FuelEconomyUnit = mi/gal;
    //attribute <'lb/(hp⋅h)'> 'pound per horsepower hour' : FuelConsumptionUnit = lb/(hp*h);
    

    An additional extension package for ISQ is needed that declares the attribute definitions for the missing quantity and measurement unit types, e.g.:

    • EnergyDensityValue and EnergyDensityUnit
    • EnergySpecificVolumeValue and EnergySpecificVolumeUnit
    • FuelEconomyValue and FuelEconomyUnit
    • FuelConsumptionValue and FuelConsumptionUnit

    It should be considered whether or not to include the new library package inside ISQ, as formally these quantity and unit types are not part of ISO/IEC 800000.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 21:14 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Graphical BNF for grid rendering is missing

  • Key: SYSML2-71
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    There is no Graphical BNF for grid rendering, required by the Grid View Standard View Definition.

    This should be added.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 15:36 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Graphical notation for variant inheritance from variation requires improvement

  • Key: SYSML2-70
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    A variant is an owned member of its variation and is also a specialization of its variation. As a result, the variant inherits the owned member relationships from its variation.

    This appears in the diagram in the attached example (file name: variant_inheritance_from_variation_issue_sf_2023-04-12). The transmissionAutomatic has an inherited ownedMembership to the transmissionManual and to itself. This applies to the transmissionManual as well.

    Refer to the spec clauses as 8.2.3.5 Namespaces and Packages Graphical Notation and 8.2.3.6 for Definition and Usage Graphical Notation (where variation is introduced).

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 15:33 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Graphical BNF for grid rendering is missing

  • Key: SYSML2_-31
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    There is no Graphical BNF for grid rendering, required by the Grid View Standard View Definition.

    This should be added.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 15:36 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Resolve "TODO" in domain library model Time

  • Key: SYSML2_-32
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The declaration of attribute def Iso860DateTimeEncoding in the Quantities and Units Domain Library model Time.sysml still has a TODO comment (line 199):

     * TODO: Add constraint to verify ISO 8691 extended string encoding.
    
  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 18:47 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Extend ISQ with missing quantity and unit types for US Customary Units

  • Key: SYSML2_-33
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The US Customary Units as specified in NIST SP811 Annex B include a number of units for which the corresponding quantity is not defined in ISO/IEC 80000, the International System of Quantities (ISQ). These units are currently commented out in Quantities and Units Domain Library USCustomaryUnits. Examples are:

    //attribute <'Btu_IT/ft³'> 'British thermal unit (IT) per cubic foot' : EnergyDensityUnit = Btu_IT/ft^3;
    //attribute <'gal/(hp⋅h)'> 'gallon (US) per horsepower hour' : EnergySpecificVolumeUnit = gal/(hp*h);
    //attribute <'mi/gal'> 'mile per gallon (US)' : FuelEconomyUnit = mi/gal;
    //attribute <'lb/(hp⋅h)'> 'pound per horsepower hour' : FuelConsumptionUnit = lb/(hp*h);
    

    An additional extension package for ISQ is needed that declares the attribute definitions for the missing quantity and measurement unit types, e.g.:

    • EnergyDensityValue and EnergyDensityUnit
    • EnergySpecificVolumeValue and EnergySpecificVolumeUnit
    • FuelEconomyValue and FuelEconomyUnit
    • FuelConsumptionValue and FuelConsumptionUnit

    It should be considered whether or not to include the new library package inside ISQ, as formally these quantity and unit types are not part of ISO/IEC 800000.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 21:14 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Special graphical notation for distinguished parameters in name compartment

  • Key: SYSML2-61
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Currently, distinguished parameters like subject, actor, stakeholder, do not stand out in the graphical notation for symbols that use them.

    Consider allowing distinguished parameters in the name compartment of elements that use them, such as RequirementDefinition, RequirementUsage, UseCaseDefinition, UseCaseUsage, etc.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 13:01 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Missing graphical notation for Flows Compartment

  • Key: SYSML2-64
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.13.1, Table 15, in example "Flows Compartment" the graphical notation is missing. Graphical notation corresponding to the example expressed in textual notation should be added. Also, the corresponding graphical BNF production for flows-compartment is missing in subclause 8.2.3.13, so that should be added too.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 14:55 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Source and target on binary ConnectionDefinition symbol missing

  • Key: SYSML2-60
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The graphical BNF for binary ConnectionDefinition does not clearly indicate the source and target ends.
    The graphical BNF should provide the optional ability to include source and target notation, with arrow head or source and target keywords.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 12:57 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Graphical BNF mapping to abstract syntax is missing

  • Key: SYSML2-67
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    A mapping of the Graphical BNF productions to the abstract syntax has not been addressed.

    If no specific proposal is considered by the FTF, it may be worth including some discussion notes in the spec in place of any detailed mapping.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 15:09 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Graphical BNF defines lifeline elements incorrectly

  • Key: SYSML2-65
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Lifeline elements need to be included within the lifeline itself, with connector segments above and below, and occurrences of * within the lifeline, similar to boundary elements.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 14:58 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Special graphical notation for distinguished parameters in name compartment

  • Key: SYSML2_-26
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Currently, distinguished parameters like subject, actor, stakeholder, do not stand out in the graphical notation for symbols that use them.

    Consider allowing distinguished parameters in the name compartment of elements that use them, such as RequirementDefinition, RequirementUsage, UseCaseDefinition, UseCaseUsage, etc.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 13:01 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Graphical BNF defines lifeline elements incorrectly

  • Key: SYSML2_-28
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Lifeline elements need to be included within the lifeline itself, with connector segments above and below, and occurrences of * within the lifeline, similar to boundary elements.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 14:58 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Port symbol notation (arrows) needs improvement

  • Key: SYSML2-57
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The line-arrows in the current graphical notation for ports with directional features are badly readable in large, busy diagrams.

    The same solid triangular arrow symbols as for parameters should be used on ports with directional features.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 12:21 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Parameter symbol notation needs improvement

  • Key: SYSML2-53
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The current graphical notation for parameters is similar to SysML v1, i.e. a (rounded) square attached to outside of the border of an action symbol. A directional parameter has a line arrow indicating in, out or inout direction. The notation is inconsistently depicted: both full squares outside the border and half squares outside the border (like in SysML v1) are used. See e.g., Representative Notation Table in section 7.16.1 page 194.

    There should be a single standard notation that is clearly differentiated from port symbols. Also, the direction arrows should be clearly readable in large and busy diagrams with many parameters (nested and non-nested).

    Alternative parameter symbol notation has been developed that uses a circular shape that straddles the border of the owning action (definition or usage), and has solid triangular arrow symbols.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 22:32 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Missing graphical notation for n-ary connection def and usage

  • Key: SYSML2-56
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    BNF production is missing for n-ary connection def and connection usage as in examples shown in the representative notation table in 7.13.1 Connections Overview. Must be fixed in 8.2.3.13.

    Check all examples of n-ary connections (including causation and requirements derivation) to replace arrowheads with bolded end names. Connections of 3 or more ends only have target ends, no source ends, see KerML spec clause 7.4.5.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 12:19 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Quantity and unit for ratio and fraction

  • Key: SYSML2-55
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Explicit concepts for ratio, RatioValue and RatioUnit are missing from ISQ and SI, although they are highly relevant and often used.

    Similarly fraction, FractionValue and FractionUnit would be useful.

    Add these concepts as specializations of DimensionOneValue and DimensionOneUnit.

    Also add units <'%'> percent, <ppm> 'parts per million', <pbm> 'parts per billion'. For parts per billion it is important to explicitly chose the US or UK billion (10^9 vs 10^12).

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 23:17 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Parameter symbol notation needs improvement

  • Key: SYSML2_-21
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The current graphical notation for parameters is similar to SysML v1, i.e. a (rounded) square attached to outside of the border of an action symbol. A directional parameter has a line arrow indicating in, out or inout direction. The notation is inconsistently depicted: both full squares outside the border and half squares outside the border (like in SysML v1) are used. See e.g., Representative Notation Table in section 7.16.1 page 194.

    There should be a single standard notation that is clearly differentiated from port symbols. Also, the direction arrows should be clearly readable in large and busy diagrams with many parameters (nested and non-nested).

    Alternative parameter symbol notation has been developed that uses a circular shape that straddles the border of the owning action (definition or usage), and has solid triangular arrow symbols.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 22:32 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Port symbol notation (arrows) needs improvement

  • Key: SYSML2_-24
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The line-arrows in the current graphical notation for ports with directional features are badly readable in large, busy diagrams.

    The same solid triangular arrow symbols as for parameters should be used on ports with directional features.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 12:21 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Quantity and unit for ratio and fraction

  • Key: SYSML2_-22
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Explicit concepts for ratio, RatioValue and RatioUnit are missing from ISQ and SI, although they are highly relevant and often used.

    Similarly fraction, FractionValue and FractionUnit would be useful.

    Add these concepts as specializations of DimensionOneValue and DimensionOneUnit.

    Also add units <'%'> percent, <ppm> 'parts per million', <pbm> 'parts per billion'. For parts per billion it is important to explicitly chose the US or UK billion (10^9 vs 10^12).

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 23:17 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Loop examples incomplete in representative notation table

  • Key: SYSML2-51
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The loop examples in representative notation table for section 7.16 are incomplete, only two until-loops are shown.

    Add while-loop and for-loop action examples in the representative notation table for Actions (after until-loops).

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 22:04 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Specification of standard geometric view missing

  • Key: SYSML2-49
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Standard geometric view is identified, but contents are not specified yet. An initial description is given in the doc comment in 9.2.19 library element <gev> GeometricView.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 21:00 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Consider production for standard case view vs filtered general view

  • Key: SYSML2-48
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    No productions for case view. All case-related productions were included in general view, since no specific subset was finalized during discussions. Consider defining as a subset view, like other general view subsets. Incorrect reference to 9.2.19.1.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 20:54 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

No support for metadata in graphical notation


Graphical BNF production proxy refers to wrong label

  • Key: SYSML2-41
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    proxy refers to proxy-label should be sq-proxy-label
    The BNF attempted to reuse the proxy graphics and productions across all three contexts where a proxy may appear (lifeline, ports, and parameters), but all these need to be replaced by proxy graphics specific to each context, including connector line segments above and below, or left and right, in each specific graphic context where a proxy dot may appear.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 20:40 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Examples requirement derivation, cause effect, and refinement missing

  • Key: SYSML2-52
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Requirement derivation, cause effect, and refinement are missing in the representative notation tables.

    Add examples in both graphical and textual notation for requirement derivation, cause effect, and refinement.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 22:13 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Examples requirement derivation, cause effect, and refinement missing

  • Key: SYSML2_-20
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Requirement derivation, cause effect, and refinement are missing in the representative notation tables.

    Add examples in both graphical and textual notation for requirement derivation, cause effect, and refinement.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 22:13 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Specification of standard geometric view missing

  • Key: SYSML2_-17
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Standard geometric view is identified, but contents are not specified yet. An initial description is given in the doc comment in 9.2.19 library element <gev> GeometricView.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 21:00 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Loop examples incomplete in representative notation table

  • Key: SYSML2_-19
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The loop examples in representative notation table for section 7.16 are incomplete, only two until-loops are shown.

    Add while-loop and for-loop action examples in the representative notation table for Actions (after until-loops).

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 22:04 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Consider production for standard case view vs filtered general view

  • Key: SYSML2_-16
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    No productions for case view. All case-related productions were included in general view, since no specific subset was finalized during discussions. Consider defining as a subset view, like other general view subsets. Incorrect reference to 9.2.19.1.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 20:54 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Identify the owning context in a graphical view

  • Key: SYSML2-37
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Clarify how to show the owning context for a nested feature in a graphical view such as a state transition view (Proposed solution: consider 'exhibited by vehicle' for state transition view of vehicleStates).

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 12:08 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Graphical BNF production sq-ev-occurrence has inconsistent proxy notation

  • Key: SYSML2-40
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Currently sq-ev-occurrence is denoted as an "X", which is not used anywhere else. Should it be rather the proxy notation, i.e., a black dot?

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 12:28 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Regularization of textual notation for loops

  • Key: SYSML2-36
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The textual notation should be regularized between the until loop and while loop.

    The proposed update is loop while action actionName where action and actionName are optional.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 12:02 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Regularization of textual notation for loops

  • Key: SYSML2_-12
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The textual notation should be regularized between the until loop and while loop.

    The proposed update is loop while action actionName where action and actionName are optional.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 12:02 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Identify the owning context in a graphical view

  • Key: SYSML2_-13
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Clarify how to show the owning context for a nested feature in a graphical view such as a state transition view (Proposed solution: consider 'exhibited by vehicle' for state transition view of vehicleStates).

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 12:08 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Identify impact views on model organization

  • Key: SYSML2-33
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Identify the implications of views on the model organization and how to mitigate circular dependencies.

    Approaches to representing nested views

    • Case 1: Specify view rendering for each element in the view (e.g., show nested parts as a tree view for some parts and interconnection view for others)
    • Case 2: View exposes packages with views
    • Case 3: View contains nested views

    Example (representing nested parts tree). The default case is to apply the same rendering method to each element. In effect, the rendering method and filter is inherited by all elements in the view.

    Case 1. Specify view rendering for each element in the view (e.g., show nested parts as a tree view for some parts and interconnection view for others)

    Case 2. View exposes packages with views

    Case 3. View contains nested views

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 11:55 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT
  • Attachments:

Clarify query using view

  • Key: SYSML2-32
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    How a view/query is performed when using a view as an input mode is unspecified.

    This should be clarified and added.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 11:53 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Missing graphical notation allocating flow to connection

  • Key: SYSML2-34
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The graphical notation for allocating a flow to a connection, that is consistent with textual notation, is missing.

    This should be added.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 11:58 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Missing explicit explanation of compartments as views

  • Key: SYSML2-35
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    There should be explicit specification and explanation, that a diagram and a compartment are views, as well as clarification on how the filter notation can be applied to a view compartment and to a diagram. Consider an extension to the filter notation.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 12:01 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Icons for standard view definitions missing

  • Key: SYSML2-31
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add standardized element icons and standard view definition icons as they should appear in a browser or on diagrams.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 11:50 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Icons for standard view definitions missing

  • Key: SYSML2_-7
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add standardized element icons and standard view definition icons as they should appear in a browser or on diagrams.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 11:50 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Identify impact views on model organization

  • Key: SYSML2_-9
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Identify the implications of views on the model organization and how to mitigate circular dependencies.

    Approaches to representing nested views

    • Case 1: Specify view rendering for each element in the view (e.g., show nested parts as a tree view for some parts and interconnection view for others)
    • Case 2: View exposes packages with views
    • Case 3: View contains nested views

    Example (representing nested parts tree). The default case is to apply the same rendering method to each element. In effect, the rendering method and filter is inherited by all elements in the view.

    Case 1. Specify view rendering for each element in the view (e.g., show nested parts as a tree view for some parts and interconnection view for others)

    Case 2. View exposes packages with views

    Case 3. View contains nested views

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 11:55 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT
  • Attachments:

Missing graphical notation allocating flow to connection

  • Key: SYSML2_-10
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The graphical notation for allocating a flow to a connection, that is consistent with textual notation, is missing.

    This should be added.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 11:58 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Clarify query using view

  • Key: SYSML2_-8
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    How a view/query is performed when using a view as an input mode is unspecified.

    This should be clarified and added.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 11:53 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Incomplete description of TestCaseVerifyObjectiveMembership_Mapping

  • Key: SYSML2-17
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The section describing the mapping class TestCaseVerifyObjectiveMembership_Mapping is incomplete. The subsections Description, General Mappings, Mapping Source, Mapping Target, and Owned Mappings are missing.

  • Reported: SysML 2.0a1 — Wed, 19 Apr 2023 17:16 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Standard view filters incomplete

  • Key: SYSML2-25
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Specifications of the standard views in library StandardViewDefinitions.sysml are incomplete, i.e. they are not all formally specified with a filter expression.

    Specify valid Definitions as a filter expression for each ViewDefinition. Initial specifications are in textual descriptions in clauses 9.2.19.2.x.

  • Reported: SysML 2.0a1 — Sun, 23 Apr 2023 18:07 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Mapping of UML4SysML::RemoveVariableValueAction::isRemoveDuplicates is not covered

  • Key: SYSML2-18
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not consider the property UML4SysML::RemoveVariableValueAction::isRemoveDuplicates.

  • Reported: SysML 2.0a1 — Wed, 19 Apr 2023 17:29 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Standard view filters incomplete

  • Key: SYSML2_-6
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Specifications of the standard views in library StandardViewDefinitions.sysml are incomplete, i.e. they are not all formally specified with a filter expression.

    Specify valid Definitions as a filter expression for each ViewDefinition. Initial specifications are in textual descriptions in clauses 9.2.19.2.x.

  • Reported: SysML 2.0a1 — Sun, 23 Apr 2023 18:07 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Mapping of UML4SysML::RemoveVariableValueAction::isRemoveDuplicates is not covered

  • Key: SYSML2_-5
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not consider the property UML4SysML::RemoveVariableValueAction::isRemoveDuplicates.

  • Reported: SysML 2.0a1 — Wed, 19 Apr 2023 17:29 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

KerML should have syntax for enumerations

  • Key: KERML-245
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    SysML v2 includes syntax for enumeration definitions and usages. The semantics for enumerations are based on the general variation/variant semantics in SysML v2, which is itself based on KerML semantics. However, there currently is no syntax for enumerations in KerML. In particular, this leads to an awkward mapping in 9.2.17 KerML of MOF enumerations to KerML data types without specific syntax for enumeration.

    Enumerations are the only modeling element in the CMOF subset of UML that does not have a clear mapping to a KerML element. Especially as KerML is considered further for use as the basis of other languages, including their reflective abstract syntaxes, it would be better if enumeration syntax was codified in KerML. This would also make it easier to incorporate enumerations consistently into SysML v2 and future KerML-based languages themselves.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 16:02 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

KerML should have syntax for enumerations

  • Key: KERML_-53
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    SysML v2 includes syntax for enumeration definitions and usages. The semantics for enumerations are based on the general variation/variant semantics in SysML v2, which is itself based on KerML semantics. However, there currently is no syntax for enumerations in KerML. In particular, this leads to an awkward mapping in 9.2.17 KerML of MOF enumerations to KerML data types without specific syntax for enumeration.

    Enumerations are the only modeling element in the CMOF subset of UML that does not have a clear mapping to a KerML element. Especially as KerML is considered further for use as the basis of other languages, including their reflective abstract syntaxes, it would be better if enumeration syntax was codified in KerML. This would also make it easier to incorporate enumerations consistently into SysML v2 and future KerML-based languages themselves.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 16:02 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

UntypedPin_Mapping::filter: property src should be from

  • Key: SYSML2-5
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The src property in the filter condition should be from.

  • Reported: SysML 2.0a1 — Sat, 15 Apr 2023 17:58 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Pin_Mapping::filter: property src should be from

  • Key: SYSML2-7
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The src property in the filter condition should be from.

  • Reported: SysML 2.0a1 — Sat, 15 Apr 2023 18:03 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

"Elements not mapped" table sections are empty

  • Key: SYSML2-1
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    All sections in the specification that end with "elements not mapped" should list tables of elements that are not considered by the transformation including a rationale. The tables are listed in the List of Tables of the document.

    As a table or in an alternative presentation form, the information about unmapped elements should be described in the appropriate sections of the specification.

  • Reported: SysML 2.0a1 — Tue, 11 Apr 2023 06:02 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Spatial links can be occurrences

  • Key: SYSML2-75
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 9.2.4.1 (Occurrences Overview), under Temporal and Spatial Associations, describes temporal/spatial relations between occurrences, such as HappensBefore/Outside and HappensDuring/InsideOf, then says:

    The Links above to do not take up time or space, they are temporal and spatial relations between things that do (they are disjoint with LinkObject, see 9.2.5.1).

    but

    • Some links can be occurrences without being link objects (LinkObject specializes of Link and Object, but does not intersect them).
    • Spatial links are not disjoint with LinkObject or Occurrence in the libraries.
  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 18:31 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Inefficient graphical notation specification tooling

  • Key: SYSML2-69
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Note: this is not an issue with the SysML v2 specification itself, but rather with the tooling to produce it.

    Currently, the graphical notation in the representative notation tables (and for Graphical BNF) is created using an adapted version of the open source tool diagrams.net (https:// www.diagrams.net) in .drawio format. The production workflow is very labor-intensive, cumbersome and therefore error-prone.

    A new, efficient and maintainable workflow using improved tooling should be considered. Preferably, the produced graphical artifacts should in SVG format. The workflow shall also be compatible with the KerML and SysML v2 specification authoring environment.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 15:28 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Error in InterfaceUsage semantics subclause

  • Key: SYSML2-54
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In subclause 8.4.10.2, at the beginning of the second bullet, checkInterfaceDefinitionBinarySpecialization should be checkInterfaceUsageBinarySpecialization ("...Usage..." instead of "...Definition...").

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 22:47 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

The .project.json file for the Cause and Effect Domain Library is misnamed

  • Key: SYSML2-78
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The Model Interchange Project file in the Cause and Effect Domain Library Project Interchange File is named .proj.json. It should be .project.json.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 19:36 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Standard view filters incomplete

  • Key: SYSML2-26
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Specifications of the standard views in library `StandardViewDefinitions.sysml` are incomplete, i.e. they are not all formally specified with a filter expression.

    Identify valid element kinds as filter expression for each ViewDefinition. Initial set is specified in clause 9.2.19. Elaborate remaining filter expressions from initial description in comments.

    (Derived from GSWG ID#01).

  • Reported: SysML 2.0a1 — Sun, 23 Apr 2023 17:52 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Association end name " /usageWithDirectedUsage" has a typo

  • Key: SYSML2-81
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In Figure 8. Definition and Usage (subclause 8.3.6.1), the opposite association end to Usage::directedUsage appears on the diagram as /usageWithDirectedUsage, where the slash indicates it is derived, and the property name is usageWithDirectedUsage. However, in the normative XMI for the abstract syntax, the property is not derived an it has the name  /usageWithDirectedUsage (it starts with a space and a slash).

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 21:08 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Error in assert constraint example

  • Key: SYSML2-153
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.19.3 Assert Constraint Usages, in the last example, the assert constraint usage nested in the part usage alienObject is incorrect (and inconsistent with the preceding comment). The name of the constraint should be negativeMass, not nonNegativeMass, and the value bound to mass should be antiMass, not computeMass.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 19:34 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Packages can also have compartments

  • Key: SYSML2-92
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.2.2 Elements, at the end of the last paragraph, in the sentence "In the graphical notation, owned elements may be shown in compartments within the symbol representing the owning element, particularly when the owning element is a definition or usage (see 7.6.1).", it should say "...when the owing element is a package, definition or usage (see 7.5 and 7.6.1)."

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 20:57 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Errors in textual BNF for RequirementDefinition and ConcernDefinition

  • Key: SYSML2-156
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the BNF production for RequirementDefinition in 8.2.2.20.1:

    RequirementDefinition =
        OccurrenceDefinitionPrefix 'requirement' 'def'
        DefinitionDeclaration RequirementBody?
    

    and the BNF production for ConcernDefinition in 8.2.2.20.3:

    ConcernDefinition =
        OccurrenceDefinitionPrefix 'concern' 'def'
        DefinitionDeclaration RequirementBody?
    

    the final ? after RequirementBody is incorrect and should be removed.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 19:55 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Transformation of UML4SysML::AddStructuralFeatureValueAction is not correct

  • Key: SYSML2-23
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:
    • The example of a target SysML v2 textual syntax is not correct. The parameters target and object should be redefined. The others are defined in the library and directly connected by target elements of an object flow mapping.
      Update description: action thisIsAAddStructuralFeatureValueAction : SysMLv1Library::AddStructuralFeatureValueAction {
      :>> target := object.thisIsAnAttribute;
      :>> object : ThisIsABlock;
      }
    • The pins of the action should not be transformed, because their target elements are already defined in the SysMLv1Library.
    • The mapping of an object flow to pins of the action does not work. The target element is defined in the SysMLv1lLbrary.
    • Remove ASFVATargetReferenceUsage_Mapping::declaredName(), because the name must not be set. It is already defined in the SysMLv1Library
    • Redefinition of parameter SysMLv1Library::AddActionValue::target is missing
    • Redefinition of parameter SysMLv1Library::AddStructuralFeatureValueActionValue::object is missing
    • Usage of ASFVATargetFeatureValueExpressionMembership_Mapping in ASFVATargetFeatureChainExpression_Mapping should be ASFVATargetParameterExpressionMembership_Mapping
    • Use the AssignmentAction factory classes from SYSML2-4 instead of ASFVATargetAsignmentActionUsage_Mapping
    • Transformation links the object to the target but should be the structural feature
    • ASFVATargetParameterExpressionFeature_Mapping has no ownedRelationships, therefore remove the operation ownedRelationship()
    • Update ObjectFlowItemFlowEndReferenceUsage_Mapping to properly set the targets of object flows to pins of the AddStructuralFeatureValueAction
    • ASFVAObjectReferenceUsage_Mapping should specialize UniqueMapping, because the mapping class is used twice, but should generate only one element.
  • Reported: SysML 2.0a1 — Sat, 22 Apr 2023 14:34 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Editoral corrections in 7.16.11

  • Key: SYSML2-103
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.16.11 Loop Action Usages, in the section on "While Loops", in the last paragraph, in the first sentence, "true" should be bold.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 23:04 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

ItemFlowEnds of ObjectFlow transformation target are not defined correctly

  • Key: SYSML2-2
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The subsetting of the ItemFlowEnd should be a ReferenceSubsetting instead of a Subsetting.

    The value of the isEnd property of the ItemFlowEnd is false, but should be true.

    It is misleading that the names of the mapping classes for the ItemFlowEnd mapping contain the string ItemFlow. It should be ItemFlowEnd.

  • Reported: SysML 2.0a1 — Sat, 15 Apr 2023 09:08 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

UML4SysML::ClearVariableAction transformation does not include a ReturnParameter

  • Key: SYSML2-14
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The assignment of LiteralNull should include a ReturnParameterMembership element with a feature that is not there. It should be part of the mapping class CVAReferenceUsageFeatureValue_Mapping.

  • Reported: SysML 2.0a1 — Tue, 18 Apr 2023 20:46 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Transformation of UML4SysML::AddVariableValueAction is not correct

  • Key: SYSML2-4
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation of UML4SysML::AddVariableValueAction contains several issues:

    • AVVAFeatureValue_Mapping uses unknown mapping class AddValueActionValueFeatureReferenceExpression_Mapping; should be AVVAValueFeatureReferenceExpression_Mapping
    • The CommonAssignmentActionUsageReferenceFeatureMembership_Mapping and dependent mapping classes are independent of the mapping source and should be defined as factories
    • The mapping does not consider the isReplaceAll property
    • In SysMLv1Library::AddValueAction, the "if isReplaceAll" statement should be "if not isReplaceAll"
    • The mapping class AVVAValueExpressionMembership_Mapping defines the action as the memberElement. It should be the variable.
    • The source of the mapping classes for AddVariableValueAction should be "AddVariableValueAction" instead of "Action".
    • Remove the mapping of the pins "value" and "insertAt", because they are part of the SysMLv1Library::AddValueAction action definition
    • The mapping of an ObjectFlow to the pins "value" and "insertAt" does not work
  • Reported: SysML 2.0a1 — Sat, 15 Apr 2023 17:04 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Subsections for mapping classes in section 7.7.2.3.9 should be ordered alphabetically

  • Key: SYSML2-16
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The subsections for mapping specification in the document are ordered alphabetically. The alphabetically order is not fully followed in section 7.7.2.3.9.

  • Reported: SysML 2.0a1 — Wed, 19 Apr 2023 12:39 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Mapping of ValueSpecificationActions does not work for untyped pins

  • Key: SYSML2-173
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping class ValueSpecificationAction_Mapping uses a mapping class for the output pin that only considers typed pins.

  • Reported: SysML 2.0a1 — Mon, 1 May 2023 14:10 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

REAOutputPin_Mapping should specialize OutputPin_Mapping

  • Key: SYSML2-19
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping class REAOutputPin_Mapping should specialize OutputPin_Mapping instead of Pin_Mapping. The result pin of a ReadExtentAction is always an output pin with a defined type.

  • Reported: SysML 2.0a1 — Thu, 20 Apr 2023 06:39 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Mapping of allocation between usage elements is not specified yet

  • Key: SYSML2-88
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of an allocation relationship between usage elements is not specified yet (see section 7.8.3.3.8).

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 11:23 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Optimize Pin mapping class generalization hierarchy

  • Key: SYSML2-171
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The separation of typed and untyped pin mapping classes leads to the same separation for each specialized mapping class for InputPin and OutputPin and for further specializations. This leads to many mapping classes and thus redundancies in the operations.

    It can be simplified if the distinction of whether the pin has a type or not is not implemented via specialized mapping classes but within the rules.

  • Reported: SysML 2.0a1 — Mon, 1 May 2023 14:02 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Description of Subsetting mapping classes is not correct

  • Key: SYSML2-200
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The description of mapping classes creating a subsetting element states: "Creates a subsetting relationship for the subsettingFeature() and the subsettedFeature()."

    The operation subsettingFeature() is not defined in the mapping class. Sometimes also the subsettedFeature() operation is also not specified.

    The description should be simply:
    "Creates a subsetting relationship."

  • Reported: SysML 2.0a1 — Mon, 15 May 2023 15:53 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

ControlFlowSuccessionAsUsage_Mapping uses non existing mapping class ActivityEdgeInitialNodeSourceEndFeatureMembership_Mapping

  • Key: SYSML2-189
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The ownedRelationship() operation of ControlFlowSuccessionAsUsage_Mapping uses the mapping class ActivityEdgeInitialNodeSourceEndFeatureMembership_Mapping which is not defined.

  • Reported: SysML 2.0a1 — Mon, 8 May 2023 17:40 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

ClassifierBehaviorFeatureMembership_Mapping does not exist

  • Key: SYSML2-178
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping class ClassifierBehaviorFeatureMembership_Mapping is used in several operations, but it does not exist. It seems that the class was renamed to BehavioredClassifierFeatureMembership_Mapping.

    The wrong name is used in sections 7.3.1, 7.7.13.3.4, 7.8.4.3.4, 7.8.6.3.25, and 7.8.6.3.33

  • Reported: SysML 2.0a1 — Wed, 3 May 2023 04:54 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

EmptyReturnParameterFeatureMembership_Mapping does not exist

  • Key: SYSML2-174
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Section 7.7.2.3.9.22 RVVAVariableFeatureReferenceExpression_Mapping and section 7.7.14.3.23 OpaqueExpressionFeatureValueExpression_Mapping use the mapping class EmptyReturnParameterFeatureMembership_Mapping, but it does not exist.

    Instead, it should be ReturnParameterFeatureMembership_Factory.

  • Reported: SysML 2.0a1 — Tue, 2 May 2023 17:51 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

GenericToEndFeatureMembership_Mapping::to property redefines itself

  • Key: SYSML2-195
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The to property of GenericToEndFeatureMembership_Mapping redefines itself, but should redefine the inherited to property from GenericToFeatureMembership_Mapping.

  • Reported: SysML 2.0a1 — Thu, 11 May 2023 06:16 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

ControlFlowSuccessionAsUsage_Mapping uses non existing mapping class

  • Key: SYSML2-193
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The ownedRelationship() operation of ControlFlowSuccessionAsUsage_Mapping uses the mapping class ControlFlowTargetEndFeatureMembership_Mapping, which is not defined.

  • Reported: SysML 2.0a1 — Wed, 10 May 2023 15:45 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

ControlFlow transformation target ends are not defined correctly

  • Key: SYSML2-215
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The ends of a control flow mapping target have a subsetting relationship, but it should be a reference subsetting relationship.

  • Reported: SysML 2.0a1 — Tue, 23 May 2023 12:52 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

A ConnectionUsage should be owned by a FeatureMembership relationship

  • Key: SYSML2-208
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The BehavioredClassifier_Mapping::ownedRelationship() operation creates a OwningMembership relationship for ConnectionUsages, but should be a FeatureMembership relationship

  • Reported: SysML 2.0a1 — Thu, 18 May 2023 06:33 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

ControlFlow target SuccessionAsUsage should have end feature with reference subsetting

  • Key: SYSML2-197
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The end features of the the UML4SysML::ControlFlow target element SuccessionAsUsage should have end feature with reference subsetting instead of a subsetting.

  • Reported: SysML 2.0a1 — Thu, 11 May 2023 06:48 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Introduce GenericToTransitionUsage_Mapping class

  • Key: SYSML2-211
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Several mapping classes map to a transition usage. A GenericToTransitionUsage_Mapping class could be introduced to simplify the mapping model and reduce redundancies.

  • Reported: SysML 2.0a1 — Mon, 22 May 2023 15:22 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Mapping of SysMLv1::ItemFlow does not consider the itemProperty

  • Key: SYSML2-204
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of ItemFlow does not consider the itemProperty. For the case that the itemProperty is not used, it could reuse the mapping of InformationFlow.

  • Reported: SysML 2.0a1 — Wed, 17 May 2023 14:34 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Filter for mapping class Behavior_Mapping is useless

  • Key: SYSML2-202
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The filter condition of the mapping class Behavior_Mapping is just "true". The filter can be removed.

  • Reported: SysML 2.0a1 — Tue, 16 May 2023 08:52 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Graphical BNF sq-message reference incorrect

  • Key: SYSML2-43
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    sq-message refers to message-label instead of sq-message-label

    Resolution:
    Change the production rule

    sq-message = &sq-l-node message-label &sq-l-node
    ------------------->
    to:

    sq-message = &sq-l-node sq-message-label &sq-l-node
    ------------------->

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 20:49 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Textual production for sq-proxy-label incorrect

  • Key: SYSML2-42
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    sq-proxy-label refers to Usage from textual grammar - needs to be corrected

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 20:48 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Typo in section 7.6.3 and section 7.6.4: mappingsto

  • Key: SYSML2-213
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The descriptions of all mapping classes in sections 7.6.3 and 7.6.4 contain the text "mappingsto" which should be "mappings to".

  • Reported: SysML 2.0a1 — Mon, 22 May 2023 15:50 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Graphical BNF production sq-part refers to wrong port

  • Key: SYSML2-39
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    "sq-part refers to portNode* instead of sq-port
    Replace portNode by sq-port but also update sq-port graphics to show horizontal connector segments like other boundary elements"

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 12:25 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Graphical BNF interconnection view production incorrect

  • Key: SYSML2-45
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    interconnection view production missing interfaces

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 20:51 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Limitation on specifying view renderings

  • Key: SYSML2-155
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.25.2 View Definitions and Usages, the third paragraph includes the parenthetical comment:

    (Note that, in the textual notation, it is only possible to specify a view rendering using reference subsetting.)

    This correctly reflects the following textual notation BNF in 8.2.2.25.1 View Definitions:

    ViewRenderingMember : ViewRenderingMembership =
        MemberPrefix 'render'
        ownedRelatedElement += ViewRenderingUsage
    
    ViewRenderingUsage : RenderingUsage =
        ownedRelationship += OwnedReferenceSubsetting
        FeatureSpecializationPart?
        UsageBody
    

    However, neither the abstract syntax (see 8.3.25) nor the semantics (see 8.4.21) of view rendering require this restriction. The textual notation should be updated to allow a more general declaration of a view rendering usage, consistent with what is representable in the abstract syntax.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 19:51 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect production for attributes-compartment-element

  • Key: SYSML2-62
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The production for attributes-compartment-element is incorrectly referencing "UsagePrefix UsageDeclaration".

    It should reference "UsagePrefix Usage".

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 13:15 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Graphical BNF sq-message-label usage incorrect

  • Key: SYSML2-44
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    sq-message-label uses Usage from textual production, needs to be corrected

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 20:50 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Connection declaration does not allow a feature value

  • Key: SYSML2-84
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The second line of the following does not parse:

    abstract connection c1;
    abstract connection c2 = c3; // Error: No viable alternative at input '='
    

    The reason for this is that the ConnectionUsage production uses UsageDeclaration (see subclause 8.2.2.13.1):

    ConnectionUsage =
        OccurrenceUsagePrefix
        ( 'connection' UsageDeclaration
          ( 'connect' ConnectorPart )?
        | 'connect' ConnectorPart )
        UsageBody
    

    However, UsageDeclaration does not include ValuePart, which provides the syntax for feature values (see 8.2.2.6.2):

    Usage =
        UsageDeclaration UsageCompletion
    UsageDeclaration : Usage =
        Identification FeatureSpecializationPart?
    UsageCompletion : Usage =
        ValuePart? UsageBody
    

    On the other hand, 7.13.2 states that “A connection definition or usage (that is not of a more specialized kind) is declared as a kind of occurrence definition or usage (see 7.9.2), using the kind keyword connection”, and an occurrence declaration (in the informal sense) can, in general, include a feature value, so it would be expected to be allowable for a connection, too.

    Note that this is also a problem for interactions, but not for messages or flow connections, which explicitly allow a ValuePart (see 8.2.2.13.4):

    MessageDeclaration : FlowConnectionUsage =
          UsageDeclaration ValuePart?
          ( 'of' ownedRelationship += ItemFeatureMember )?
          ( 'from' ownedRelationship += MessageEventMember
            'to' ownedRelationship += MessageEventMember
          )?
        | ownedRelationship += MessageEventMember 'to'
          ownedRelationship += MessageEventMember
    
    FlowConnectionDeclaration : FlowConnectionUsage =
          UsageDeclaration ValuePart?
          ( 'of'  ownedRelationship += FlowPayloadFeatureMember )?
          ( 'from' ownedRelationship += FlowEndMember
            'to'   ownedRelationship += FlowEndMember )?
        | ownedRelationship += FlowEndMember 'to'
          ownedRelationship += FlowEndMember
    
  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 21:30 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Graphical BNF flow-label and interface-label productions missing

  • Key: SYSML2-46
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The Graphical BNF flow-label and interface-label productions are missing and should be added.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 20:52 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Number missing from table listing Standard View Definitions

  • Key: SYSML2-224
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The first table in clause 9.2.19.1 that lists the Standard View Definitions does not have a number nor a caption. Table number 38 and caption should be added.

  • Reported: SysML 2.0a1 — Wed, 14 Jun 2023 10:29 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Error in textual BNF for MessageDeclaration

  • Key: SYSML2-255
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The textual BNF production for MessageDeclaration includes a reference to ItemFeatureMember, which does not exist. This reference should instead be to FlowPayloadFeatureMember.

  • Reported: SysML 2.0a1 — Tue, 27 Jun 2023 17:14 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Table 38 "Standard View Definitions" redundant

  • Key: SYSML2-223
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Remove existing Table 38 "Standard View Definitions", as well as the immediately preceding paragraph, from subclause 9.2.19.1, since this information is redundant and potentially inconsistent with the graphical BNF in subclause 8.2.3.

  • Reported: SysML 2.0a1 — Wed, 14 Jun 2023 10:23 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Case View is not a standard view

  • Key: SYSML2-291
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The Case View that is listed in the first table in clause 9.2.19.1 and defined in clause 9.2.19.2.3 is not one of the standard views and should be removed.
    Note: The intent is to respecify the Case View as a specialization of the (standard) General View with a suitable filter.

  • Reported: SysML 2.0a1 — Wed, 12 Jul 2023 14:28 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Error in textual BNF for TargetSuccession

  • Key: SYSML2-261
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The textual BNF production for the TargetSuccession is missing the keyword then.

  • Reported: SysML 2.0a1 — Thu, 29 Jun 2023 14:36 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Mapping of SysMLv1::ItemFlow does not consider the itemProperty

  • Key: SYSML2-181
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of ItemFlow only covers the flow of classifiers, but not of items specified by ItemFlow::itemProperty.

  • Reported: SysML 2.0a1 — Wed, 3 May 2023 12:48 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Mapping of UML4SysML::InformationFlow with a realizing connector is not supported

  • Key: SYSML2-206
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The SysMLv1::ItemFlow mapping supports the flow with a realizing connector. Move this capability to the mapping of UML4SysML::InformationFlow and reuse it to map an ItemFlow. The ItemFlow mapping must only add the special handling of an itemProperty.

  • Reported: SysML 2.0a1 — Wed, 17 May 2023 17:53 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Mapping of UML4SysML::InformationFlow between definition elements is not supported

  • Key: SYSML2-180
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of UML4SysML::InformationFlow and therefore also SysMLv1::ItemFlow between definition elements is not supported yet.

  • Reported: SysML 2.0a1 — Wed, 3 May 2023 05:35 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Helpers::activityOwnedRelationships mixes up FinalNodes and FlowFinalNodes

  • Key: SYSML2-228
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The Helper operation activityOwnedRelationships calls the mapping class FlowFinalNode_Mapping with a set of final nodes including activity final nodes, but should only be final nodes.

    Activity final nodes are currently excluded from the transformation (see SYSML2-106).

  • Reported: SysML 2.0a1 — Wed, 21 Jun 2023 17:53 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

TIAOperatorExpression_Mapping uses non-existing mapping class EqualOperatorExpressionOperand_Mapping

  • Key: SYSML2-232
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The operation TIAOperatorExpression_Mapping::ownedRelationship() uses mapping class EqualOperatorExpressionOperand_Mapping, but it does not exist.

  • Reported: SysML 2.0a1 — Wed, 21 Jun 2023 20:38 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

RSFAReferenceUsageFeatureMembership_Mapping uses non-existing mapping class

  • Key: SYSML2-234
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    RSFAReferenceUsageFeatureMembership_Mapping uses the non-existing mapping class ReadStructuralFeatureActionReferenceUsage_Mapping, but it should be RSFAReferenceUsage_Mapping

  • Reported: SysML 2.0a1 — Thu, 22 Jun 2023 01:24 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Resolution of approved issue SYSML2-23 uses outdated mapping classes

  • Key: SYSML2-236
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The resolution forgot to update two usages of the mapping class ObjectFlowItemFlowEndRedefinition_Mapping which is now a factory ObjectFlowItemFlowEndRedefinition_Factory class.

    The error is in the OCL code of ObjectFlowItemFlowEndReferenceUsage_Mapping::ownedRelationships().

  • Reported: SysML 2.0a1 — Thu, 22 Jun 2023 12:48 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

RVVAVariable_Mapping uses CommonAssignmentActionOwningMembership_Mapping, but should be a factory class

  • Key: SYSML2-244
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    RVVAVariable_Mapping uses CommonAssignmentActionOwningMembership_Mapping, but it should be the factory class AssignmentActionUsageOwningMembership_Factory.

    The resolution SYSML2-4 changed CommonAssignmentActionOwningMembership_Mapping to AssignmentActionUsageOwningMembership_Factory, but oversaw the usages of the mapping class in RVVAVariable_Mapping.

  • Reported: SysML 2.0a1 — Sun, 25 Jun 2023 13:03 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

ObjectFlows targeting a final node or a activity parameter node cannot be mapped

  • Key: SYSML2-238
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    All target nodes of object flows are handled the same, but activity final nodes are not covered yet, flow final nodes are mapped to a library element, and activity parameter nodes are ignored by the transformation and replaced by the parameter. The object flow mapping must consider the handling of these cases.

  • Reported: SysML 2.0a1 — Thu, 22 Jun 2023 16:13 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

TestCaseActivity_Mapping uses non-existing mapping classes

  • Key: SYSML2-240
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    TestCaseActivity_Mapping::ownedRelationships() uses the mapping classes CaseSubjectMembership_Mapping and CaseObjectiveMembership_Mapping, which do not exist.

    They existed in a previous version but were removed without updating TestCaseActivity_Mapping.

  • Reported: SysML 2.0a1 — Sat, 24 Jun 2023 09:42 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

ControlFlowSuccessionAsUsage_Mapping uses non-existing mapping class

  • Key: SYSML2-229
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    ownedRelationship() calls the mapping class ControlFlowFinalNodeTargetEndFeatureMembership_Mapping, but it does exist. Instead it should be ControlFlowFinalNodeFeatureMembership_Mapping.

  • Reported: SysML 2.0a1 — Wed, 21 Jun 2023 18:30 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

CreateLinkObjectAction_Mapping should specialize CreateLinkAction_Mapping

  • Key: SYSML2-248
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The UML4SysML::CreateLinkObjectAction is a specialization of UML4SysML::CreateLinkAction. Accordingly, the CreateLinkObjectAction_Mapping should specialize CreateLinkAction_Mapping.

  • Reported: SysML 2.0a1 — Mon, 26 Jun 2023 06:31 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Mapping of allcation between usage and definition or definition and usage elements does not work

  • Key: SYSML2-258
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of the allocation relationship only considers allocations from definition to definition and usage to usage elements, but not a mixed allocation.

  • Reported: SysML 2.0a1 — Thu, 29 Jun 2023 06:09 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

AEAParameterMembership_Mapping::ownedMemberParameter cannot return OclUndefined

  • Key: SYSML2-246
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The ownedMemberParameter must return an element and not OclUndefined. The case where the if-statement leads to OclUndefined must be checked before AEAParameterMembership_Mapping::ownedMemberParameter is called.

  • Reported: SysML 2.0a1 — Mon, 26 Jun 2023 05:41 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Map OpqueBehavior always to ActionDefinition

  • Key: SYSML2-281
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    OpaqueBehavior not owned by a package is mapped to a ActionUsage. Since a UML4SysML::OpaqueBehavior is also a type it should be mapped to a conforming element in SysML v2, i.e., only to ActiobDefinition.

  • Reported: SysML 2.0a1 — Mon, 3 Jul 2023 15:45 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Typo in AEAReceiverFeatureValue_Mapping::value()

  • Key: SYSML2-250
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    ACAReceiverFeatureReferenceExpression_Mapping should be AEAReceiverFeatureReferenceExpression_Mapping

  • Reported: SysML 2.0a1 — Mon, 26 Jun 2023 07:16 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Mapping of ActivityEdge does not consider ActivityParameterNodes

  • Key: SYSML2-304
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The SysML v1 to v2 transformation does not map ActivityParameterNode, but only the references Parameter. The mapping of ActivityEdge must map the ends of the edge, which are connected to an ActivityParameterNode to the target element of the mapping of the Parameter.

  • Reported: SysML 2.0b1 — Sun, 16 Jul 2023 10:57 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

UntypedPin_Mapping redefines operation without any changes

  • Key: SYSML2-278
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    UntypedPin_Mapping (SYSML2-171 renamed it to Pin_Mapping) redefines ownedRelationship(), but does not change anything. Remove the redefined operation.

  • Reported: SysML 2.0a1 — Sun, 2 Jul 2023 06:30 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect font in descriptions of AttributeUsage and TransitionUsage

  • Key: SYSML2-157
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Most of the text of the description of AttributeUsage (8.3.7.2) and TransitionUsage (8.3.17.9) is incorrectly in the "code" font, probably due to a missing HTML tag.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 20:01 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

UML4SysML::Activities and StateMachines owned by blocks should be mapped to definition elements

  • Key: SYSML2-221
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Activities owned by blocks are mapped to ActionUsage, but should be ActionDefinition. Same for StateMachines

  • Reported: SysML 2.0a1 — Thu, 8 Jun 2023 19:02 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Typo: Table 19 - requirres

  • Key: SYSML2-312
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Table 19, Requirement, compartment for require constraints:

    Typo in compartment headline should be "require constraints" => "requirre"

  • Reported: SysML 2.0b1 — Sun, 23 Jul 2023 19:11 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Graphical BNF productions missing for connections


Incorrect private keyword notation

  • Key: SYSML2-328
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Example "Package with imported packages (nested packages)" should have «private» enclosed by guillemets

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Nesting parameter symbols should use rounded rectangles


Incorrect entry name representative notation

  • Key: SYSML2-330
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Example "Usage Definition" should be labeled "Part defined by Part Definition"

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:11 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

sq-port-label and sq-ev-occurrence-label productions use Usage

  • Key: SYSML2-287
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 8.2.3.9, the sq-port-port-label and sq-ev-occurrence-label use Usage from the textual BNF. But Usage includes UsageBody, which was not intended to be included in this graphical notation.

  • Reported: SysML 2.0a1 — Sun, 9 Jul 2023 22:57 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Wrong line style on action flow succession

  • Key: SYSML2-319
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    A succession relationship on an action flow should be a solid line with an open arrow head. In 7.16.1 in example "Accept and Send Action Flow". Check for other locations.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:13 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:


Incorrect keyword in example "Attributes Compartment"

  • Key: SYSML2-335
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Attributes Compartment" textual notation should use nonunique instead of unique.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:16 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect example "Relationships Compartment"


Unnecessarily complicated examples "Timeslices Compartment" and "Snapshots Compartment"



Incorrect example "Variant Membership"

  • Key: SYSML2-332
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Variant Membership" the variants should be defined by Part1a and Part1b respectively. Currently they are both defined by Part1.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:12 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Compartments still show nested feature notation

  • Key: SYSML2-341
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Remove nested features (textual) notation from compartments in graphical symbols in all Representative Notation tables where they occur. This capability was discarded.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:24 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Missing «perform action» in example "Part with Graphical Compartment with perform actions ..."


Examples "Timeslices Compartment" and "Snapshots Compartment" incorrectly declare state feature

  • Key: SYSML2-340
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In examples "Timeslices Compartment" and "Snapshots Compartment" remove state state1 feature, since it is confusing, and potentially incorrect.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:20 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Misleading port name in example "Part with Ports"


Wrong reference usage notation

  • Key: SYSML2-347
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Replace nested reference usage notation with dotted outline notation. Add BNF production for this notation.
    Reference usage notation is used in interconnection diagrams, and potentially action flow diagram. The solution is to add explicit production for dotted usages of parts, constraints, and requirements references and include those production in interconnection diagrams. Create productions of action usage references and add them to action flow.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:37 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect inherited notation in example "Connection"

  • Key: SYSML2-345
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Connection" (1) remove circumflex on end1 and end2, since they are (implicitly) redefinitions of the ends from the connection definition, not inherited features.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:29 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Wrong compartment name: documentation

  • Key: SYSML2-325
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Documentation Compartment", the documentation keyword should read doc

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:56 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Keyword for documentation is "doc"

  • Key: SYSML2-93
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.4.1 Annotation Overview, Table 7, in the "Documentation Component" entry, the keyword in the graphical symbol should be doc, not documentation.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 20:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT


The description and derivation of ForLoopActionUsage::seqArgument is wrong

  • Key: SYSML2-190
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The description of ForLoopActionUsage::seqArgument is (see 8.3.16.9 ForLoopActionUsage):

    The Expression whose result provides the sequence of values to which the loopVariable is set for each iterative performance of the bodyAction. It is the owned parameter that redefines ForLoopAction::body.

    The second sentence is clearly wrong. It should instead be

    It is the Expression whose result is bound to the seq input parameter of this ForLoopActionUsage.

    Similarly, the description of the constraint deriveForLoopActionUsageSeqArgument should be

    The seqArgument of a ForLoopActionUsage is its first argument Expression.

    and with the OCL

    seqArgument = argument(1)

  • Reported: SysML 2.0a1 — Mon, 8 May 2023 21:50 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect notation in action examples

  • Key: SYSML2-99
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.16.2 Action Definitions, the action definition example TakePicture contains two declarations with incorrect textual notation:

    action focus : Focus (in scene, out image);

    and

    action shoot : Shoot (in image, out picture);

    These should be

    action focus : Focus {in scene; out image;}

    and

    action shoot : Shoot {in image; out picture;}

    In 7.16.10 If Action Usages, the nested action declarations in the last example all have incorrect textual notation:

    if threat.level == high then {
        action soundAlarm(threat);
    } else if threat.level == medium then {
        action sendNotification(threat);
    } else {
        action beginMonitoring(threat);
    }

    This should instead be something like:

    if threat.level == high then {
        action soundAlarm {in cause=threat;}
    } else if threat.level == medium then {
        action sendNotification {in cause = threat;}
    } else {
        action beginMonitoring {in cause = threat;}
    }

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 21:33 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Time triggers are relative to "localClock", not "defaultClock"

  • Key: SYSML2-101
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.16.8 Accept Action Usages, it states that the "current time" for time triggers is "relative to the defaultClock". This is incorrect, the time used for triggers is actually the localClock, which defaults to the defaultClock, but can be overridden locally.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 22:22 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateDefinitionNonVariationMembership and validateUsageNonVariationMembership are redundant with validateVariantMembershipOwningNamespace

  • Key: SYSML2-300
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The constraints validateDefinitionNonVariationMembership and validateUsageNonVariationMembership check that a non-variation Definition or Usage owns no VariantMemberships. However, validateVariantMembershipOwningNamespace already checks that the membershipOwningNamespace of a VariantMembership is a variation, so the other constraints are redundant.

  • Reported: SysML 2.0b1 — Fri, 14 Jul 2023 16:23 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Errors in TransitionUsage semantic constraints

  • Key: SYSML2-218
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    There are errors in the specification of the following constraints for TransitionUsage:

    checkTransitionUsageSpecialization

    • The feature Actions::transitions named in the description should be Actions::transitionActions
    • In the OCL, "Actions::actions::transitionActions" should be "Actions::transitionActions".

    checkTransitionUsageActionSpecialization

    • In the OCL, "Actions::Action::decisionTransitionActions" should be "Actions::Action::decisionTransitions".
  • Reported: SysML 2.0a1 — Sat, 27 May 2023 18:30 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateDefinitionVariationMembership and validateUsageVariationMembership are too strict

  • Key: SYSML2-298
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The constraints validateDefinitionVariationMembership and validationUsageVariationMembership require that all the owned members of a variation definition or usage be variant members. This is too strong:

    • It disallows any variation Usage from having a Multiplicity, because that is a non-variant owned member of the Usage.
    • It disallows a variation PortDefinition from having a required ConjugatedPortDefinition, because that is a non-variant owned member of the definition.
  • Reported: SysML 2.0b1 — Thu, 13 Jul 2023 20:20 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateFramedConcernUsageConstraintKind constraint is misnamed

  • Key: SYSML2-296
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The constraint validateFramedConcernUsageConstraintKind is owned by FramedConcernMembership, not FramedConcernUsage (which doesn't exist). Therefore, the constraint should be named validateFramedConcernMembershipConstraintKind.

  • Reported: SysML 2.0b1 — Thu, 13 Jul 2023 02:38 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Redundant numbered list in language description of usage

  • Key: SYSML2-254
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Toward the end of subclause 7.6.3 Usage of the SysML v2 specification, there is a numbered list describing additional keywords that can be used in a usage declaration. However, this list is repeated twice (sequentially, one right after the other). The two lists are consistent, but the second one is more complete, so the first list is redundant.

  • Reported: SysML 2.0a1 — Mon, 26 Jun 2023 17:18 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

deriveForLoopActionUsageBodyAction is misnamed

  • Key: SYSML2-191
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The constraint deriveForLoopActionUsageBodyAction is owned by LoopAction, not ForLoopActionUsage, and, so, should be called deriveLoopActionUsageBodyAction.

  • Reported: SysML 2.0a1 — Mon, 8 May 2023 21:53 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateOccurrenceUsageIndividualDefinition OCL is wrong

  • Key: SYSML2-302
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The OCL for the constraint validateOccurrenceUsageIndividualDefinition is

    occurrenceDefinition->select(isIndividual).size() <= 1
    

    However, the type of OccurrenceUsage::occurrenceDefinition is actually Class, not OccurrenceDefinition, but the property isIndividual is only defined on OccurrenceDefinition.

  • Reported: SysML 2.0b1 — Fri, 14 Jul 2023 18:26 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateUsageOwningType constraint is too restrictive

  • Key: SYSML2-301
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The constraint validateUsageOwningType constrains the owningType of a Usage to be a Definition or Usage. However, this is two restrictive, because it prevents, e.g., a Usage from being declared within a body expression (as used with collect, select, etc.), which is a KerML Expression.

  • Reported: SysML 2.0b1 — Fri, 14 Jul 2023 16:26 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

The OCL for the body of ConstraintUsage::namingFeature is incorrect

  • Key: SYSML2-356
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The body OCL for the namingFeature operation of ConstraintUsage references ownedFeatureMembership. This should instead be owningFeatureMembership.

  • Reported: SysML 2.0b1 — Thu, 3 Aug 2023 14:22 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization constraints are too restrictive

  • Key: SYSML2-306
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization prohibit parallel state definitions and usages from owning specializations of non-parallel state definitions and usages (and vice versa). However, this would prevent even, e.g., an empty non-parallel state definition from having a usage that was parallel, for example:

    state def S;
    state s : S parallel {  // validation error!
        state s1;
        state s2;
    }
    

    Further, it is also a validation error for a parallel state definition to explicitly specialized the base state definition StateAction (which is not parallel), even though an implicit specialization is not checked:

    state def S1 parallel { } // legal, implicitly specializes StateAction
    state def S2 :> States::StateAction parallel { } // validation error!
    

    For consistency, it would seem that, at least, a parallel state definition or usage should be able to explicitly specialize a non-parallel one. But perhaps the constraints are really not semantically necessary at all.

  • Reported: SysML 2.0b1 — Sun, 16 Jul 2023 21:17 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization OCL is wrong

  • Key: SYSML2-303
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The OCL for the constraints validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization both use ownedGeneralization (which doesn't exist) instead of ownedSpecialization.

  • Reported: SysML 2.0b1 — Fri, 14 Jul 2023 19:23 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

checkTransitionUsageSourceBindingConnector text and OCL are different

  • Key: SYSML2-414
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In 8.3.17.9 (TransitionUsage), the text for checkTransitionUsageSourceBindingConnector requires binding of the first input parameter

    A TransitionUsage must have an ownedMember that is a BindingConnector between its source and its first input parameter (which redefines Actions::TransitionAction::transitionLinkSource).

    while the OCL gives it as binding the second parameter

    ownedMember->selectByKind(BindingConnector)->exists(b |
    b.relatedFeatures->includes(source) and
    b.relatedFeatures->includes(inputParameter(2)))

  • Reported: SysML 2.0b1 — Tue, 29 Aug 2023 18:07 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

TransitionUsage effectAction attribute text and constraint are different

  • Key: SYSML2-398
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Clause 8.3.17.9 (TransitionUsage), the Attributes section says effectAction are expressions:

    Attributes
    /effectAction : ActionUsage [0..*] {subsets feature}
    The ActionUsages that define the effects of this TransitionUsage, which are the ownedFeatures of the TransitionUsage related to it by TransitionFeatureMemberships with kind = effect, which must all be Expressions.

    but a constraint says they're action usages

    deriveTransitionUsageEffectAction
    The effectActions of a TransitionUsage are the transitionFeatures of the ownedFeatureMemberships of the TransitionUsage with kind = effect, which must all be ActionUsages.
    triggerAction = ownedFeatureMembership->
    selectByKind(TransitionFeatureMembership)->
    select(kind = TransitionFeatureKind::trigger).transitionFeatures->
    selectByKind(AcceptActionUsage)

  • Reported: SysML 2.0a1 — Fri, 25 Aug 2023 19:39 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

WhileLoopsActionusage title typos

  • Key: SYSML2-424
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The title of 8.3.16.18 is WhileLoopsActionusage, with plural "Loops" and lower case "u", but in Figure 28 (Structured Control Actions) these are singular and capitalized, respectively.

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 14:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

checkIfActionUsageSpecialization OCL specifiesFromLibrary typo

  • Key: SYSML2-423
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In 8.3.16.10 (IfActionUsage), the OCL for checkIfActionUsageSpecialization refers to specifiesFromLibrary instead of specializesFromLibrary.

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 14:51 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Graphical BNF for n-ary connections missing


Description of TimeEvent_Mapping is a note

  • Key: SYSML2-418
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The description of the TimeEvent_Mapping class is a note from the development team instead of a description text.

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 10:34 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

The transformation specification does not explicitly specify how to map a ValueType

  • Key: SYSML2-437
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of a ValueType is identical to the mapping of a DataType. Therefore, there is no explicit mapping class for ValueType. However, that hides the information of the mapping of ValueTypes in the transformation specification.

  • Reported: SysML 2.0b1 — Fri, 8 Sep 2023 16:08 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Description of ChangeEvent_Mapping is a note

  • Key: SYSML2-416
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The description of the ChangeEvent_Mapping class is a note from the development team instead of a description text.

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 10:31 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

InformationFlow mapping classes should use GenericTo mapping classes

  • Key: SYSML2-420
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping classes InformationFlowEnd_Mapping, InformationFlowFeatureTyping_Mapping, and InformationFlowEndFeatureMembership_Mapping updated by SYSML2-180 should use more specialized GenericTo mapping classes instead of the GenericToElement_Mapping class:

    InformationFlowEnd_Mapping => GenericToFeature_Mapping
    InformationFlowFeatureTyping_Mapping => GenericToFeatureTyping_Mapping
    InformationFlowEndFeatureMembership_Mapping => GenericToFeatureMembership_Mapping

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 11:32 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Part properties with AggregationKind::none or shared are not mapped to PartUsage with isComposite=false

  • Key: SYSML2-432
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Part properties with AggregationKind::none or shared are mapped to Feature, but should be a PartUsage with isComposite=false.

  • Reported: SysML 2.0b1 — Fri, 8 Sep 2023 15:23 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Document how SysML v1 properties are mapped to SysML v2

  • Key: SYSML2-446
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The SysML v1 properties like part property, are concepts, but not stereotypes or metamodel elements. Therefore, they are explicitly covered by a mapping class or are listed in the overview tables.

    Add a documentation in section 7.8.4.1 that describes how the different SysML v1 property concepts are mapped to SysML v2.

  • Reported: SysML 2.0b1 — Sun, 10 Sep 2023 16:32 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateDefinitionVariationSpecialization and validateUsageVariationSpecialization OCL is wrong

  • Key: SYSML2-299
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The OCL for both of the constraints validateDefinitionVariationSpecialization and validateUsageVariationSpecialization is:

    isVariation implies
        not ownedSpecialization.specific->exists(isVariation)
    

    These constraints should be checking Specialization::general, not Specialization::specific. In addition, the type of both specific and general is Type, which doesn't have an isVariation property. Only Definition and Usage types have such a property.

  • Reported: SysML 2.0b1 — Fri, 14 Jul 2023 15:50 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Property_Mapping should map to ItemUsage and the class name is misleading

  • Key: SYSML2-443
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Property_Mapping maps properties typed by a Class or Interface. The target element should be ItemUsage instead of Feature.

    The name of the mapping class is misleading. It creates the impression that it maps all kinds of properties, but it only covers the cases where a Class or Interface types properties. Rename the mapping class to PropertyTypedByClassInterface_Mapping.

    The specialized mapping classes ConstraintParameter_Mapping, Port_Mapping, and Part_Mapping should specialize PropertyCommon_Mapping instead of Property_Mapping.

  • Reported: SysML 2.0b1 — Sun, 10 Sep 2023 10:33 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Change the table header of the overview tables in the mapping class specification chapters

  • Key: SYSML2-441
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The table headers state that the rows list SysML v1 and v2 concepts. Actually, they only list stereotype and metamodel elements but not all the concepts. For example, the part property is not listed because it is not a SysML v1 stereotype but only a concept.

  • Reported: SysML 2.0b1 — Sat, 9 Sep 2023 11:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

UML4SysML::Class should be mapped to ItemDefinition

  • Key: SYSML2-439
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    UML4SysML::Class is currently mapped to OccurrenceDefinition, but should be ItemDefinition.

  • Reported: SysML 2.0b1 — Fri, 8 Sep 2023 17:45 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Graphical BNF opaque "text block" productions

  • Key: SYSML2-252
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    In the graphical BNF there is a set of textual productions related to compartments that are currently mapped to a "text block" placeholder. They need to be replaced with concrete textual productions.

    1. In 8.2.3.24, production use-cases-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: use-cases-compartment-contents = (use-cases-compartment-element)* '…'? and use-cases-compartment-element = el-prefix? OccurrenceUsagePrefix CalculationUsageDeclaration CaseBody '…'
    2. In 8.2.3.5, production packages-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: packages-compartment-contents = (packages-compartment-element)* '…'? and packages-compartment-element = el-prefix? TBD
    3. In 8.2.3.5, production members-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: members-compartment-contents = (members-compartment-element)* '…'? and members-compartment-element = el-prefix? TBD
    4. In 8.2.3.5, production relationships-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: relationships-compartment-contents = (relationships-compartment-element)* '…'? and relationships-compartment-element = el-prefix? TBD
    5. In 8.2.3.6, production variants-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: variants-compartment-contents = (variants-compartment-element)* '…'? and variants-compartment-element = el-prefix? TBD
    6. In 8.2.3.6, production variant-elementusages-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: variant-elementusages-compartment-contents = (variant-elementusages-compartment-element)* '…'? and variant-elementusages-compartment-element = el-prefix? TBD
    7. In 8.2.3.16, production performed-by-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: performed-by-compartment-contents = (performed-by-compartment-element)* '…'? and performed-by-compartment-element = el-prefix? TBD
    8. In 8.2.3.17, production succession-compartment-contents incorrectly equates to text-block placeholder. It should be renamed to successions-compartment-contents, and it should be replaced with two productions: successions-compartment-contents = (successions-compartment-element)* '…'? and successions-compartment-element = el-prefix? TBD
    9. In 8.2.3.18, production calcs-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: calcs-compartment-contents = (calcs-compartment-element)* '…'? and calcs-compartment-element = el-prefix? TBD
    10. In 8.2.3.18, production result-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: result-compartment-contents = result-compartment-element? and result-compartment-element = el-prefix? TBD
    11. In 8.2.3.20, production require-constraints-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: require-constraints-compartment-contents = (require-constraints-compartment-element)* '…'? and require-constraints-compartment-element = el-prefix? TBD
    12. In 8.2.3.20, production assume-constraints-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: assume-constraints-compartment-contents = (assume-constraints-compartment-element)* '…'? and assume-constraints-compartment-element = el-prefix? TBD
    13. In 8.2.3.20, production satisfies-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: satisfies-compartment-contents = (satisfies-compartment-element)* '…'? and satisfies-compartment-element = el-prefix? TBD
    14. In 8.2.3.25, production exposes-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: exposes-compartment-contents = (exposes-compartment-element)* '…'? and exposes-compartment-element = el-prefix? TBD
    15. In 8.2.3.25, production rendering-compartment-contents incorrectly equates to text-block placeholder. It should be replaced with two productions: rendering-compartment-contents = (rendering-compartment-element)* '…'? and rendering-compartment-element = el-prefix? TBD
  • Reported: SysML 2.0a1 — Mon, 26 Jun 2023 17:07 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

LoopActionUsage descriptions refer to property not in metamodel

  • Key: SYSML2-425
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The descriptions in 8.3.16.9 (ForLoopActionUsage) and 8.3.16.18 (WhileLoopsActionusage) refer to "bodyClause", but in Figure 28 (Structured Control Actions) the association end for this (presumably) is called "bodyAction".

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 15:09 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Mistake in example "Part performs a reference action (action1) that references ..."

  • Key: SYSML2-343
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Part performs a reference action (action1) that reference subsets another action (action3)" replace «perform action» action1 with «perform» action2, and «action» action3 : Action3 with «action» action2 : Action2, and adapt the textual notation accordingly. This also makes it consistent with the preceding example.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:26 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Various incorrect Graphical BNF productions

  • Key: SYSML2-63
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The Graphical BNF productions in section 8.2.3 contain a number of minor mistakes

    In order to be efficient, the mistakes and corrections are recorded as an enumerated list hereafter.

    1. In 8.2.3.9, production occurrences-compartment-element incorrectly uses DefinitionBodyItem. DefinitionBodyItem should be removed.
    2. In 8.2.3.10, production items-compartment-element incorrectly uses DefinitionBodyItem. DefinitionBodyItem should be removed.
    3. In 8.2.3.11, production parts-compartment-element incorrectly uses OccurrenceUsagePrefix UsageDeclaration. It should be OccurrenceUsagePrefix Usage.
    4. In 8.2.3.12, production ports-compartment-element incorrectly uses OccurrenceUsagePrefix UsageDeclaration. It should be OccurrenceUsagePrefix Usage.
    5. In 8.2.3.13, production connections-compartment-element incorrectly uses OccurrenceUsagePrefix UsageDeclaration ConnectorPart+ DefinitionBodyItem*. It should be OccurrenceUsagePrefix UsageDeclaration ( 'connect' ConnectorPart )? | 'connect' ConnectorPart ) UsageBody.
    6. In 8.2.3.14, production interfaces-compartment-element incorrectly uses InterfaceUsageDeclaration InterfaceBodyDefinition*. It should be OccurrenceUsagePrefix InterfaceUsageDeclaration InterfaceBody.
    7. In 8.2.3.16, production actions-compartment-element incorrectly uses OccurrenceUsagePrefix ActionUsageDeclaration ActionBodyItem*. It should be OccurrenceUsagePrefix ActionUsageDeclaration.
    8. In 8.2.3.16, production perform-actions-compartment-element incorrectly uses PerformActionUsageDeclaration ActionBodyItem*. It should be OccurrenceUsagePrefix PerformActionUsageDeclaration.
    9. In 8.2.3.17, production states-compartment-element incorrectly uses UsageDeclaration. It should be OccurrenceUsagePrefix ActionUsageDeclaration.
  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 13:17 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incomplete textual notation in example "Subsetting"

  • Key: SYSML2-331
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Example "Subsetting" is missing specification of the perform action action1 : Action1 that is shown as inherited in the graphical notation. Add part def Part1 in textual notation from preceding example "Usage Definition".

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:12 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Transformation does not cover SysMLv1::~InterfaceBlock

  • Key: SYSML2-139
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not specify mapping rules for SysMLv1::~InterfaceBlock.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 07:50 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Representative notation table uses deprecated «equal»

  • Key: SYSML2-58
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Representative notation table, in 7.13 Connections, uses the deprecated «equal» notation instead of the standard "=" notation for a binding connector.

    All «equal» notations should be replaced with = notation.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 12:33 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

RSAOutputPin_Mapping should specialize OutputPin_Mapping

  • Key: SYSML2-21
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping class RSAOutputPin_Mapping should specialize OutputPin_Mapping instead of Pin_Mapping. The result pin of a ReadExtentAction is always an output pin with a defined type.

  • Reported: SysML 2.0a1 — Thu, 20 Apr 2023 07:07 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Flows Compartment example graphical notation missing

  • Key: SYSML2-95
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.13.1 Connections Overview, Table 15, entry for "Flows Compartment", the graphical notation is missing.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 21:04 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

ElementMain_Mapping::ownedRelationship is wrong

  • Key: SYSML2-280
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    ElementMain_Mapping::ownedRelationship deals with owned comments and tries to create an ownership relationship thanks to ElementOwnership_Mapping.
    Instead, this is an Annotation relationship that shall be used here. We can get it thanks to the CommentAnnotation_Mapping.

    However, CommentAnnotation_Mapping misses the computation of ownedRelatedElement that is left to its default value, meaning that the ownership of a comment is never set.

  • Reported: SysML 2.0a1 — Sun, 2 Jul 2023 06:46 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

GenericToItemDefinition_Mapping should specialize GenericToOccurrenceDefinition_Mapping

  • Key: SYSML2-422
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The generic mapping class GenericToItemDefinition_Mapping specializes GenericToDefinition_Mapping. However, it should specialize GenericToOccurrenceDefinition_Mapping which is a subclass of GenericToDefinition_Mapping as well as ItemDefinition specializes OccurrenceDefinition.

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 13:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect notation in example "Binding Connection"

  • Key: SYSML2-346
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Binding Connection" «ref part» part4R should use the graphical notation as specified in the graphical BNF in subclause 8.2.3.11.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:31 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Incorrect item flow notation in example "Interface as Node"

  • Key: SYSML2-349
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Interface as Node" remove arrow heads from the nested connections, and move arrow head between pa and pb to end of line, add message of item1:Item1 from pa to pb to the interface2 usage in the textual notation. Also add open curly bracket directly after interface2, and closing curly bracket after the ellipsis.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:42 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Incomplete textual notation in example "Variants Compartment"


Incomplete flow notation in example "Flow as Node"

  • Key: SYSML2-350
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Flow as Node" check whether flow from source :> action1.item1 should be reference subsetting? Add keyword from to the nested flows.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:43 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

SYSML2-180 uses non-existing general mapping class GenericToItemUsage_Mapping

  • Key: SYSML2-412
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The approved resolution for issue SYSML2-180 uses the mapping class GenericToItemUsage_Mapping which does not exist. It seems that it was overseen to add the creation of the mapping class to the revised text of the resolution.

  • Reported: SysML 2.0b1 — Tue, 29 Aug 2023 13:22 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Text error in List property construction

  • Key: SYSML2-453
  • Status: open  
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

    The production for <SourceSuccessionMember > has "+" and it should be "+="

    SourceSuccessionMember : FeatureMembership =
    'then' ownedRelatedElement + SourceSuccession
    

    The production for <SourceEndMember> has "+" and it should be "+="

    SourceEndMember : EndFeatureMembership =
    ownedRelatedElement + SourceEnd
    
  • Reported: SysML 2.0b1 — Wed, 13 Sep 2023 18:02 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Missing production for ConjugatePortTyping

  • Key: SYSML2-451
  • Status: open   Implementation work Blocked
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

    In the production:

    FeatureTyping = OwnedFeatureTyping | ConjugatePortTyping
    

    There is no corresponding production for the non-terminal <ConjugatePortTyping>.
    <ConjugatedPortDefinitionMember> or <ConjugatedPortDefinition> may be correct for <FeatureTyping>.

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 21:01 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

misspelled ConjugatePortTyping should be ConjugatedPortTyping

  • Key: SYSML2-452
  • Status: open  
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

    Prior error report on this production can be replaced with this error report.

    The issue is with the production:

    FeatureTyping = OwnedFeatureTyping | ConjugatePortTyping
    

    The correct conjugate nonterminal should be <ConjugatedPortTyping>

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 21:27 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect EBNF specification

  • Key: SYSML2-431
  • Status: open  
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

    The current specification:

    SourceSuccessionMember : FeatureMembership =
        'then' ownedRelatedElement + SourceSuccession
    
    SourceSuccession : SuccessionAsUsage =
        ownedRelationship += SourceEndMember
    
        SourceEndMember : EndFeatureMembership =
    ownedRelatedElement + SourceEnd
    

    is incorrect. It should be:

    SourceSuccessionMember : FeatureMembership =
        'then' ownedRelatedElement += SourceSuccession
    
    SourceSuccession : SuccessionAsUsage =
        ownedRelationship += SourceEndMember
    
        SourceEndMember : EndFeatureMembership =
    ownedRelatedElement += SourceEnd
    
  • Reported: SysML 2.0b1 — Sat, 2 Sep 2023 13:29 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

PrefixComment should not be a production for AnnotatingElement

  • Key: SYSML2-454
  • Status: open  
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

    The option for <PrefixComment> has been deprecated, but is still an option for AnnotatingElement. Remove PrefixComment.

    AnnotatingElement =
      Comment
    | PrefixComment
    | Documentation
    | TextualRepresentation
    | MetadataUsage
    
  • Reported: SysML 2.0b1 — Wed, 13 Sep 2023 20:34 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

View::viewpointSatisfactions should subset viewpointChecks and checkedConstraints

  • Key: SYSML2-79
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the Views::View model as submitted, viewpointSatisfactions was accidentally declared as redefining viewpointChecks. This should be changed to subsetting, so that there can be (non-composite) viewpoint references within a view that subset viewpointChecks but not viewpointSatisfactions.

    Further, because View is a kind of Part, viewpointSatisfactions also has an implied specialization of Item::checkedConstraints. It would be better if this was explicit, to make it clear that any declaration in a View subsetting viewpointSatisfactions automatically satisfies the requirement to subset checkedConstraints, so that this does not require an additional implied specialization.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 20:48 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

RequirementConstraintUsage should not have a RequirementBody

  • Key: SYSML2-467
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the textual notation grammar, RequirementConstraintUsage produces a ConstraintUsage, but the first alternative in the production allows the ConstraintUsage to have a RequirementBody. The RequirementBody production allows kinds of declarations (such as subjects and actors) that are not valid in the body of a ConstraintUsage (because of validation constraints such as validateSubjectMembershipOwningType, validateActorMembershipOwningType, etc.). There is no point in syntactically allowing owned members that are then invalid, so the first alternative in RequirementConstraintUsage should have a CalculationBody (like the second alternative) rather than a RequirementBody.

  • Reported: SysML 2.0b1 — Wed, 4 Oct 2023 09:19 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Missing text in some main mapping sections

  • Key: SYSML2-513
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Sections 7.7.4 - 7.7.14 and Section 7.8.5 should contain the introductory sentence:

    This chapter lists all mapping specifications of <namespace> model elements.

    For example, as in Section 7.7.3:

    This chapter lists all mapping specifications of UML4SysML::Activities model elements.

  • Reported: SysML 2.0b1 — Fri, 3 Nov 2023 10:20 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

TestCaseVerifyRequirementUsage_Mapping uses non-existing mapping classes

  • Key: SYSML2-241
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    TestCaseVerifyRequirementUsage_Mapping ::ownedRelationships() uses the mapping classes CaseSubjectMembership_Mapping, which do not exist.

    It existed in a previous version but was removed without updating TestCaseVerifyRequirementUsage_Mapping .

  • Reported: SysML 2.0a1 — Sat, 24 Jun 2023 11:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Remove sentence in StateMachines overview section

  • Key: SYSML2-511
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The sentence "The justifications for the elements without mapping are given in view link does not exist" in the State Machines overview sentence does not make sense and should be removed.

  • Reported: SysML 2.0b1 — Fri, 3 Nov 2023 10:15 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Remove sentence in Classification overview section

  • Key: SYSML2-509
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The sentence "The justifications for the elements without mapping are given in view link does not exist" in the Classification overview sentence does not make sense and should be removed.

  • Reported: SysML 2.0b1 — Fri, 3 Nov 2023 06:45 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Narrow down return types of SpatialItem::PositionOf and ::CurrentPositionOf

  • Key: SYSML2-83
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Currently, in the Geometry Domain Library model SpatialItems, the calculation definitions PositionOf and CurrentPositionOf return vectors defined by the generic definition VectorQuantityValue. These should be specialized more narrowly to ISQ::Position3dVector.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 21:19 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Causation end features need to redefine source and target

  • Key: SYSML2-295
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The connection definition Causation in the CausationConnections library package has two ends that redefine the non-end features causes and effects from Multicausation.

    However, in the normative CausationConnections.sysml file from the Cause and Effect Domain Library project, these ends are declared to only subset the source and target ends inherited from BinaryConnection. As a result, the connection definition ends up having four ends rather than two, which is incorrect. Its ends need to redefine source and target, rather than just subsetting them.

    In subclause 9.5.2.2.1 of the specification document, on the other hand, Causation is not shown as specializing BinaryConnection at all, and the ends are shown as only redefining the non-end features from Multicausation.

  • Reported: SysML 2.0a1 — Wed, 12 Jul 2023 21:50 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Constraints missing to enforce variations being abstract

  • Key: SYSML2-488
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the SysML Specification, 7.6.7 Variations and Usages states “A variation is always abstract, so the abstract keyword is not used on a variation.” And, indeed, the textual notation BNF in 8.2.2.6.1 Definitions and 8.2.2.6.2 Usages allows either the abstract or variation keyword to be applied to a definition or usage declaration, but not both. However, there are no constraints in the abstract syntax subclauses 8.3.6.2 Definition or 8.3.6.4 Usage to enforce this.

  • Reported: SysML 2.0b1 — Thu, 19 Oct 2023 16:30 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Documentation of Time::defaultClock is missing

  • Key: SYSML2-393
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Subclause 9.8.8 on the Time package in the Quantities and Units Domain Library does not include documentation of defaultClock, which is in the normative library model.

  • Reported: SysML 2.0b1 — Thu, 24 Aug 2023 14:55 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Sample::calculation has an incorrect type

  • Key: SYSML2-378
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 9.4.3.2.5 Sample (in the Sampled Function model in the Analysis Domain LIbrary), the feature calculation has type CalculationUsage. However, in the actual library model, calculation is a CalculationUsage, which means it should have the base library definition Calculation as its type, not the abstract syntax element CalculationUsage

  • Reported: SysML 2.0b1 — Thu, 10 Aug 2023 02:35 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Additional cases when usages are required to be referential

  • Key: SYSML2-253
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The following statements are made in Clause 7 (Language Description) of the SysML v2 specification:

    • Subclause 7.6.3 (Usages): "Note also that a directed usage is always referential, whether or not the keyword ref is also given explicitly in its declaration."
    • Subclause 7.13.2 (Connection Definitions and Usages): "The end features of a connection definition or usage are always considered referential (non-composite), whether or not their declaration explicitly includes the ref keyword."

    However, there are currently no constraints on the Usage class in the abstract syntax to enforce these rules (see 8.3.6.4).

    In addition, a usage that is not explicitly declared as a feature of a type is, by default, considered to be a feature of the base type Anything. However, since Anything is not a kind of Occurrence, its features cannot be composite. Therefore, such usages should be always referential.

  • Reported: SysML 2.0a1 — Mon, 26 Jun 2023 17:15 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Actions::acceptSubactions and sendSubactions should subset acceptActions and sendActions

  • Key: SYSML2-490
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the Systems Model Library, the features Actions::Action::acceptSubactions and Actions::Action::sendSubactions should subset Actions::acceptActions and Actions::sendActions, respectively.

  • Reported: SysML 2.0b1 — Fri, 20 Oct 2023 14:07 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Validation constraints are missing in the SysML abstract syntax

  • Key: SYSML2-28
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The following validation constraints are implied by textual descriptions in the specification, but are missing in the abstract syntax. They should be added, along with appropriate OCL.

    8.3.16.5 AssignmentActionUsage

    validateAssignmentActionUsageArguments – An AssignmentActionUsage must have two argument Expressions.

    validateAssignmentActionUsageReferent – An AssignmentActionUsage must have an ownedMembership that is not an OwningMembership whose memberElement is a Feature.

    8.3.16.9 ForLoopActionUsage

    validateForLoopActionUsageLoopVariable – The first ownedFeature of a ForLoopActionUsage must be a ReferenceUsage.

    validateForLoopActionUsageParameters – A ForLoopActionUsage must have two owned input parameters.

    8.3.16.10 IfActionUsage

    validateIfActionUsageParameters – An IfActionUsage must have at least two owned input parameters.

    8.3.16.16 TriggerInvocationExpression

    validateTriggerInvocationExpressionAfterArgument – If a TriggerInvocationExpression has kind = after, then it must have an argument Expression with a result that conforms to the type ISQ::DurationValue.

    validateTriggerInvocationExpressionAtArgument – If a TriggerInvocationExpression has kind = at, then it must have an argument Expression with a result that conforms to the type Time::TimeInstantValue.

    validateTriggerInvocationExpressionWhenArgument – If a TriggerInvocationExpression has kind = when, then it must have an argument Expression with a result that conforms to the type ScalarValues::Boolean.

    8.3.16.18 WhileLoopActionUsage

    validateWhileLoopActionUsageParameters – A WhileLoopActionUsage must have at least two owned input parameters.

    8.3.17.2 ExhibitStateUsage

    validateExhibitStateUsageReference – If an ExhibitStateUsage has an ownedReferenceSubsetting, then its referencedFeature must be a StateUsage.

    8.3.19.2 AssertConstraintUsage

    validateAssertConstraintUsageReference – If an AssertConstraintUsage has an ownedReferenceSubsetting, then its referencedFeature must be a ConstraintUsage.

    8.3.20.10 SatisfyRequirementUsage

    validateSatisfyRequirementUsageReference – If a SatisfyRequirementUsage has an ownedReferenceSubsetting, then its referencedFeature must be a RequirementUsage.

    8.3.24.2 IncludeUseCaseUsage

    validateIncludeUseCaseUsageReference – If an IncludeUseCaseUsage has an ownedReferenceSubsetting, then its referencedFeature must be a UseCaseUsage.

  • Reported: SysML 2.0a1 — Tue, 25 Apr 2023 20:50 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

The derivation of AssignmentActionUsage::referent is wrong

  • Key: SYSML2-500
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the SysML Specification, 8.3.16.5 AssignmentActionUsage, the constraint deriveAssignmentActionUsageReferent states that "The referent of an AssignmentActionUsage is the first Feature that is the memberElement of a ownedMembership that is not an OwningMembership." However, according to the BNF in 8.2.2.16.5 Assignment Action Usages, the intended referent of an assignment is parsed as a FeatureChainMember, and, for an actual chain of more than one Feature, the chaining Feature is owned by the AssignmentActionUsage via OwningMembership. Therefore, it will not be identified as the referent of the assignment according to the current derivation.

  • Reported: SysML 2.0b1 — Sat, 28 Oct 2023 10:57 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Message and flow connection ends should be occurrence usages

  • Key: SYSML2-305
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The end features of MessageConnection, FlowConnection and SuccessionFlowConnection in the standard library package Connections are typed as Occurrences, but they are currently syntactically reference usages, not occurrence usages. However, the abstract syntax for EventOccurrenceUsage requires that its referenced eventOccurrence must actually be an OccurrenceUsage. This means that the source and target ends of, e.g., a message, if inherited from MessageConnection and not redefined, cannot be referenced by EventOccurrenceUsages, which prevents an intended use in "sequence diagram" modeling.

  • Reported: SysML 2.0b1 — Sun, 16 Jul 2023 20:35 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateTriggerInvocationExpressionAfterArgument constraint is too strong

  • Key: SYSML2-497
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The approved resolution to SYSML2-28 includes adding the constraint validateTriggerInvocationExpressionAfterArgument, which requires:

    If a TriggerInvocationExpression has kind = after, then it must have an argument Expression with a result that conforms to the type ISQ::DurationValue.

    However, in a typical relative time trigger such as, e.g., after 10[SI::s], the result of the expression 10[SI::s] is not a DurationValue. Rather it is a ScalarQuantityValue whose mRef is the DurationUnit SI::s. Therefore, this example time trigger violates validateTriggerInvocationExpressionAfterArgument as specified in the resolution to SYSML2-28.

  • Reported: SysML 2.0b1 — Fri, 27 Oct 2023 09:31 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

KerML constraint requires updates to Systems Library models

  • Key: SYSML2-491
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The approved resolution to KERML-20 adds the validation constraint validateFeatureValueOverriding that "All Features directly or indirectly redefined by the featureWithValue of a FeatureValue must have only default FeatureValues." This constraint causes problems for two models in the Systems Model Library. These library models do not actually violate the constraint, but using the models as intended my violate the constraint.

    1. In the action definition Actions::AcceptAction, the inout paramater payload is redefined with a feature value binding it to aState.aTransition.aPayload. However, when an accept action is parsed with a change or time trigger, the payload is implicitly bound to the generated change or time signal, and this violates the validateFeatureValueOverriding constraint.
    2. In the analysis case definition AnalysisCases::AnalysisCase:
      • The subject of the objective of AnalysisCase is bound to the result parameter of the AnalysisCase. However, when specifying an analysis case, it is sometimes convenient to compute a check of the case objective by evaluating it on a given subject value. However, the binding of such an subject argument then violates the validateFeatureValueOverring constraint.
      • The result parameter is bound to the result of the AnalysisCase::resultEvaluation calculation feature. However, when defining an analysis case in a user model, it is natural to bind the computation of the result of the case to the result parameter as a feature value. But this then violates the validateFeatureValueOverriding constraint.
  • Reported: SysML 2.0b1 — Tue, 24 Oct 2023 14:00 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

binding connector production overly constraining

  • Key: SYSML2-468
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Currently binding connector graphical production overly constraining the possible permutations to two specific cases. it needs to be generalized to bind usage-nodes in general where they have to be of consistent types.

  • Reported: SysML 2.0a1 — Wed, 4 Oct 2023 15:26 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

validateTriggerInvocationExpressionWhenArgument constraint is wrong

  • Key: SYSML2-498
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The approved resolution to SYSML2-28 included adding the constraint validateTriggerInvocationExpressionWhenArgument, which requires:

    If a TriggerInvocationExpression has kind = when, then it must have an argument Expression with a result that conforms to the type ScalarValues::Boolean.

    However, the argument to a when trigger is not supposed to be an Expression with a Boolean result. Rather, it is an Expression whose result is the Evaluation of an Expression whose result is Boolean. That is, a trigger like when x > 0 is parsed as TriggerWhen({x > 0}), not as TriggerWhen(x > 0). So all properly parsed when triggers will violate validateTriggerInvocationExpressionWhenArgument as specified in the resolution to SYSML2-28.

  • Reported: SysML 2.0b1 — Fri, 27 Oct 2023 09:39 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Missing production for connections with an edge on one or both ends

  • Key: SYSML2-458
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Graphical BNF should allow for graphical relationships such as causation connection from a state (i.e. cause) to a transition (i.e. effect) or from one transition (i.e., cause) to another transition (i.e., effect). These should be supported in the general view.

  • Reported: SysML 2.0a1 — Fri, 22 Sep 2023 16:57 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

KerML constraint requires updates to Domain Library models

  • Key: SYSML2-492
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The approved resolution to KERML-20 adds the validation constraint validateFeatureValueOverriding that "All Features directly or indirectly redefined by the featureWithValue of a FeatureValue must have only default FeatureValues." There are a number of cases of models in the Domain Libraries that violate this constraint.

    1. Analysis Domain Library – TradeStudy.sysml, argument in the invocation of tradeStudyObjective (see also SYSML2-491).
    2. Geometry Domain Library
      • SpatialIttems::SpatialItem::componentItems::coordinateFrame::transformation::target is given a default, but is already bound
      • ShapeItems::Circle::radius is bound, but needs to be overridable
    3. Quantities and Units Domain Library
      • Quantities::TensorQuantityValue::order redefines rank and is bound to mRef.order, but rank is already bound for an Array.
      • ISQSpaceTime::CartesianSpatial3dCoordinateFrame::mRef is bound, but needs to be overridable.
      • Several cases in ISQ models of dimensions = 3 even though, for a quantity value, dimensions is already bound to mRef.dimensions.
      • Time::Iso8601DateTimeStructure::mRef is bound to UTC, but it is already bound to UTC for a UTCInstanceValue.
      • VectorCalculations::transform::targetVector::dimensions is bound, but it is already bound for a VectorQuantityValue.
  • Reported: SysML 2.0a1 — Tue, 24 Oct 2023 16:50 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Missing graphical BNF production for keyword extension using #key word in guillemet in compartments

  • Key: SYSML2-457
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    Current Graphical BNF needs to have a production for a keyword notation with and without the base class enabled for all name compartments.

  • Reported: SysML 2.0a1 — Fri, 22 Sep 2023 16:46 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Graphical notation for nested reference usage needs resolution

  • Key: SYSML2-68
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    According to the Graphical BNF, the notation for a nested reference usage is now a white diamond in the upper-right hand corner of the usage shape (or optionally a black diamond for a non-reference usage, which is the default). In the Graphical BNF productions this is represented by rd = (reference-diamond)? as defined in clause 8.2.3.6. This is a change from the previous dashed-outline shape as also used in SysML v1.

    There are arguments pro and con for which notation might be the more usable, including the affinity of the white diamond with a feature membership, but also continuity with SysML v1 and its visibility of the distinction around the whole shape.

    The new notation was proposed primarily to avoid the practical difficulties providing dashed-outline versions of every usage shape in the BNF, but the notation should be properly decided on its own merits, not to make things easier for the BNF. An informal comment could be provided in the BNF simply stating that a dashed-outline version is available for each shape according to whether it is a reference usage. An additional alternative is to use dotted-outline, with the advantage that it more closely follows non-right-angled shapes, such as rounded rectangles used for usages.

    After discussion the Graphical Specification WG recommends to replace the upper-right-hand corner reference-diamond notation with a dotted-outline for reference usage, and stay with a solid-outline for composite usage.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 15:16 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Textual notation BNF for TriggerExpression is wrong

  • Key: SYSML2-495
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Time and change triggers for an accept action are supposed to be parsed as a TriggerInvocationExpression with a single argument: for a time trigger, the argument is a duration or time instant, while for a change trigger it is a boolean expression. However, the textual notation BNF for TriggerExpression in 8.2.2.16.4 is not properly parsing the textual notation as an invocation with arguments. As a result, the intended argument expression for the TriggerInocationExpression will not actually be recognized as an argument of the invocation.

  • Reported: SysML 2.0b1 — Thu, 26 Oct 2023 13:33 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Confusing naming in Individual Occurrence example

  • Key: SYSML2-94
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.9.1 Occurrences Overview, Table 11, entry for Individual Occurrence, the subsetted occurrence and the subsetting individual are both named occurrence1. It would be better to give the individual occurrence a different name.

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 21:02 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Semantic constraint for target of AssignmentActionUsage is missing

  • Key: SYSML2-102
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.16.9 Assignment Action Usages, at the beginning of the second text paragraph, it states

    If the target expression of an assignment action usage is omitted, then the target is implicitly the occurrence owning the assignment action usage.

    However, there is no semantic constraint to enforce this (see 8.3.16.5).

  • Reported: SysML 2.0a1 — Fri, 28 Apr 2023 22:28 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Reflective SysML abstract syntax model has inconsistencies

  • Key: SYSML2-80
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The reflective SysML model in the SysML Systems Library has the following inconsistencies with the normative SysML abstract syntax:

    1. The feature AnalysisCaseUsage::analysisAction should subset usage, not feature.

    2. The features of Definition, RequirementDefinition and Usage should have the same order as the properties of the corresponding metaclasses in the abstract syntax.

    3. The feature ViewDefinition::satisfiedViewpoint should subset ownedRequirement, not ownedUsage.

    4. The feature ViewDefinition::viewRendering should not subset ownedUsage.

    5. The feature ViewUsage::satisfiedViewpoint should subset ownedRequirement, not ownedUsage.

    6. The feature ViewUsage::viewRendering should not subset ownedUsage.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 20:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Subsections of section 7.7.2.3.7 should be ordered alphabetically

  • Key: SYSML2-227
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The subsections of section 7.7.2.3.7 should be ordered alphabetically.

  • Reported: SysML 2.0a1 — Tue, 20 Jun 2023 18:30 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Textual and graphical notations for flow on connection unclear

  • Key: SYSML2-38
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Clarify the various textual notations and corresponding graphical notations for representing a flow on a connection.

  • Reported: SysML 2.0a1 — Wed, 26 Apr 2023 12:19 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect notation in example "Individual Occurrence"

  • Key: SYSML2-336
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Example "Individual Occurrence" should include individual def from preceding example, and rename occurrence1 to occurrence1-1.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:16 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Assignments parsed without a target will fail validateAssignmentActionUsageArguments

  • Key: SYSML2-499
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The approved resolution to SYSML2-28 included the adding of the constraint validateAssignmentActionUsageArguments, which requires that an AssignmentActionUsage have two arguments. However, in the SysML Specification, 8.2.2.16.5 Assignment Action Usages, the AssignmentTargetParameter is optional for an AssignmentNodeDeclaration. An AssignmentActionUsage parsed without a target parameter argument will then fail the validateAssignmentActionUsageArguments.

    In 7.16.9 Assignment Action Usages it states that "If the target expression of an assignment action usage is omitted, then the target is implicitly the occurrence owning the assignment action usage." However, there is no semantic constraint enforcing this, so it is not clear how the informal statement is supposed to be realized.

  • Reported: SysML 2.0b1 — Fri, 27 Oct 2023 16:30 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Unnecessary event declaration in example "Message"

  • Key: SYSML2-351
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In (the second) example "Message" the event details should be removed from textual notation. The message becomes message msg1 from a1 to a2 in textual notation.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:44 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Resolution of approved issue SYSML2-241 is not considered by merged issue SYSML2-240


Typos in Quantities and Units Domain Library

  • Key: SYSML2-556
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    1. Subclause 9.8.1 paragraph 2 sentence 2, contains a typo: "The library also provides enables the specification ..." should read "The library also enables the specification ...", i.e. delete "provides".
    2. Subclause 9.8.2.1 example 1 under Free versus Bound Quantities and Vector Spaces, contains a typo: "Displacement vector (free) and the position vector (bound), ..." should read "Displacement vector (free) and position vector (bound), ...", i.e. delete "the".

  • Reported: SysML 2.0b1 — Sun, 26 Nov 2023 13:32 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Use of the term 'Feature'

  • Key: SYSML2-481
  • Status: open  
  • Source: itemis AG ( Dr. David Akehurst)
  • Summary:

    The use of the term feature in the document is inconsistent with the ISO standard definition

    Feature - ISO/IEC/IEEE 29148:2018
    A feature is an externally desired service by the system that may require a sequence of inputs to effect the desired result.

    • For example, in a telephone system, features include
      • local call,
      • call forwarding and
      • conference call.
    • Each feature is generally described in a sequence of stimulus response pairs.

    I.e. a feature of a system is about externally visible system behaviour

    Feature is a generic term and has many different meanings in different fields/contexts.
    However in System Engineering, the word is usually used as defined by the ISO standard (above).

    The use of the term 'feature' in the SysML 2 document is definitely NOT consistent with the ISO definition.
    Suggestion for a better term in the SysML 2 would be something like Member, Attribute, Aspect, Detail.

  • Reported: SysML 2.0b1 — Wed, 18 Oct 2023 07:26 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

TestCaseVerifyRequirementUsage_Mapping.ownedRelationship()

  • Key: SYSML2-536
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    TestCaseVerifyRequirementUsage_Mapping.ownedRelationship() contains the following code:

    CaseSubjectMembership_Mapping.getMapped(from.client),
    

    Since from.client is a collection the code specified cannot work. This makes MIWIG test case #37 failing

  • Reported: SysML 2.0a1 — Mon, 13 Nov 2023 21:06 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect graphical notation for message between ports

  • Key: SYSML2-578
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.13.1, Table 11, in example "Message" the message symbol between two ports of parts should use the message open arrow head. Also the text above the message edge should read «message» «of» item1 : Item1.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:52 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Add note on FlowFeature direction to textual notation grammar

  • Key: SYSML2-560
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The approved resolution to KERML-195 adds a note to the ItemFlowFeature production in the KerML concrete syntax grammar on properly setting the direction of the synthesized feature. A similar note should be added to the FlowFeature production in subclause 8.2.2.13.4 of the SysML textual notation grammar.

  • Reported: SysML 2.0b1 — Fri, 1 Dec 2023 04:14 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Section containing tables about elements not mapped should get an introductory text

  • Key: SYSML2-566
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The section containing the tables about the elements that have no mapping defined should start with a text that briefly describes the purpose of the section.

  • Reported: SysML 2.0b1 — Mon, 4 Dec 2023 17:15 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect graphical notation for flow connection

  • Key: SYSML2-577
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.13.1, Table 11, in example "Flow" the flow connection between directed features of two actions should use the filled black arrow head. Also, the rounded square symbols for the parameters (directed features) should be placed adjacent to the action box outlines.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:48 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect graphical notation for flow between actions

  • Key: SYSML2-582
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.16.1, Table 14, in example "Action with Graphical Compartment showing standard action flow view" the flow between the actions should use a black filled arrow head.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect graphical notation for flow connections in Flow as Node

  • Key: SYSML2-579
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.13.1, Table 11, in example "Flow as Node" the 3 flow connections in the «flow» node should use the black filled arrow head for flow connection.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:53 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect graphical notation for successions examples with actions

  • Key: SYSML2-583
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.16.1, Table 14, in the 7 examples "Perform Actions Swimlanes", "Actions with and without Conditional Succession", "Actions with and without Conditional Succession", "Actions with Control Nodes", "Action with Loop (body in textual notation)", "Action with Loop (body in graphical notation)", "Accept and Send Action Flow", the successions should be represented as dashed lines. The arrow heads are correct.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Mistakes in example Interface as Node (with flow)

  • Key: SYSML2-581
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Subclause 7.14.1, Table 12, example "Interface as Node (with flow)" has the following mistakes: (1) label item1 : Item1 near the flow arrow head on interface2 should be prepended with «flow» «of». (2) the message flows in the interface2 node should use the open message arrow heads. (3) . (4) The textual and graphical notation should use reference-subsetting in the specification of interface2, i.e. replace :> with ::> (two times in graphical notation, and two times in textual notation). It is also recommended to use shorter names in the example to make it more compact.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:58 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

OCL rule deriveDefinitionOwnedFlow references non-existent class called FlowUsage

  • Key: SYSML2-611
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The description indicates that this should be FlowConnectionUsage.

  • Reported: SysML 2.0b1 — Wed, 20 Dec 2023 09:02 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect and incomplete sequence view with message

  • Key: SYSML2-580
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.13.1, Table 11, in example "Message" the message transfer between the life lines should use the open arrow head for message.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:57 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

OCL rule deriveUsageNestedFlow references non-existent class called FlowUsage

  • Key: SYSML2-612
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The description indicates that it should be FlowConnectionUsage

  • Reported: SysML 2.0b1 — Wed, 20 Dec 2023 09:04 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Textual notation production for Comment is wrong

  • Key: SYSML2-620
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the textual notation grammar, the BNF production for Comment requires that a Comment always include the keyword comment. This is inconsistent with the description in 7.4.2 Comments and Documentation, which allows comments of the form /* ... */, without the keyword.

  • Reported: SysML 2.0b1 — Thu, 21 Dec 2023 04:44 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect reference to SysML v1 to SysML v2 Transformation

  • Key: SYSML2-226
  • Status: open  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    Clause 6.1 Document Overview contains an incorrect reference to the SysML v1 to SysML v2 Transformation Specification. The last line of the second paragraph refers to Annex C, which is no longer a correct reference.

  • Reported: SysML 2.0a1 — Wed, 14 Jun 2023 22:00 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

User-defined keywords are not allowed on control nodes

  • Key: SYSML2-616
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the textual notation grammar, in 8.2.2.16.3 Control Nodes, the ControlNodePrefix production does not allow the use of user-defined keywords in the prefix of control-node declarations in the body of an action. There is no real reason why this should not be allowed. It seems to be simply an oversight in the BNF.

  • Reported: SysML 2.0b1 — Wed, 20 Dec 2023 22:05 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Action::decisionTransitions should subset Action::transitions

  • Key: SYSML2-219
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the SysML specification document, in 9.2.9.2.4 Action, the feature decisionActions is stated as subsetting transitions. However, in the normative Actions.sysml library model, Action::decisionTransitions currently subsets transitionActions. It should instead subset Action::transitions, as given in the specification.

  • Reported: SysML 2.0a1 — Sun, 28 May 2023 19:32 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Wrong production for adding state-def as a definition node

  • Key: SYSML2-599
  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    In subclause 8.2.3.17 - states gbnf definition-node is being augmented with action-def instead of state-def

  • Reported: SysML 2.0a1 — Sun, 17 Dec 2023 15:25 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

checkStateUsageSpecialization constraint is incorrect

  • Key: SYSML2-558
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 8.3.17.6 StateUsage, the description of checkStateUsageSpecialization is

    A StateUsage must directly or indirectly specialize the StateUsage States::stateActions from the Systems Model Library.

    but the OCL is

    specializesFromLibrary('States::StateAction')
    

    which requires specialization of StateAction, not stateActions.

  • Reported: SysML 2.0b1 — Wed, 29 Nov 2023 21:10 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

OCL for deriveViewDefinitionViewCondition and deriveViewUsageViewCondition are wrong

  • Key: SYSML2-529
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The OCL for the constraints deriveViewDefinitionViewCondition and deriveViewUsageViewCondition are both

    viewCondition = featureMembership->
        selectByKind(ElementFilterMembership).
        condition
    

    This is clearly wrong, since ElementFilterMemberships are not featureMemberships.

    In addition, the description of the deriveViewUsageViewCondition constraint refers to ViewDefinition instead of ViewUsage, as do the descriptions of deriveViewUsageSatsifiedViewpoint, deriveViewUsageViewRendering and validateViewUsageOnlyOneViewRendering. (And the description of deriveViewUsageExposedElement is missing.)

  • Reported: SysML 2.0b1 — Sat, 11 Nov 2023 22:19 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

checkFlowConnectionUsageSpecialization is too restrictive about FlowConnections

  • Key: SYSML2-597
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 8.3.13.7 FlowConnectionUsage, the constraint checkFlowConnectionUsageSpecialization states that

    If a FlowConnectionUsage has no itemFlowEnds, then it must directly or indirectly specialize the base FlowConnectionUsage Connections::messageConnections from the Systems Library model. Otherwise, it must directly or indirectly specialize the FlowConnectionUsage Connections::flowConnections.

    The property itemFlowEnds is derived as all connectorEnds that are ItemFlowEnds. The (Kernel) metaclass ItemFlowEnd is used when a FlowConnectionUsage is parsed from the special flow notation. However, a FlowConnectionUsage can also be written using regular connection notation, which will not have ItemFlowEnds, e.g.,

    flow {
        end ::>> operator {
            out cmd : Command :>> sourceOutput;
        }
        end ::>> device {
            in cmd  : Command :>> targetInput;
        }
    }
    

    But, currently, this will implicitly specialize messageConnections, not flowConnections, which seems unexpected, since this is structurally a complete flow declaration.

  • Reported: SysML 2.0b1 — Thu, 14 Dec 2023 21:46 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Errors in the TradeStudy domain model

  • Key: SYSML2-552
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the Analysis Domain Library model TradeStudies::TradeStudy, the requirement definitions MinimizeObjective and MaximizeObjective explicitly redefine the parameter best from the TradeStudyObjective definition they specialize, but do not declare any other parameters. However, this violates the checkFeatureParameterRedefinition constraint, which requires that parameters be redefined in order. And, if the implied redefinition is added to the actual first parameter selectedAlternative, then this also violates the validateRedefinitionDirectionConformance constraint (add by the approved resolution to KERML-20), because best is an out parameter, while selectedAlternative is an in parameter.

  • Reported: SysML 2.0b1 — Tue, 21 Nov 2023 22:35 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Universal features can have many values

  • Key: SYSML2-182
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 9.8.8.2.13 (universalClock), Description, says

    universalClock is a single Clock that can be used as a default universal time reference.

    but the Time library shows it as a package-level feature, enabling everything in the universe (instances of Anything) to identify its own universal clock (see KERML-56).

    The phrase "universalClock is a single Clock" above is worded as if universalClock were a part def, rather than a part usage, giving the impression of exactly one value for universalClock across all things, but there is no constraint for this. Similarly, Clause 8.4.12.6 (Accept Action Usages) says

    In particular, the Occurrences::Occurrence::localClock itself defaults to the singleton universalClock (see 9.8.8.2.13 and [KerML, 9.2.12]).

    and 9.7.2.2.5 (SpatialItem) says its localClock is

    A local Clock to be used as the corresponding time reference within this SpatialItem. By default this is the singleton Time::universalClock.

    The term "singleton" usually refers to instances of a class, rather than values of a feature, giving the impression of exactly one value for universalClock across all things.

    Might be other features like this. For example, from the library:

        ISQSpaceTime::universalCartesianSpatial3dCoordinateFrame : CartesianSpatial3dCoordinateFrame[1] {
      /* A singleton CartesianSpatial3dCoordinateFrame that can be used as a default universal Cartesian 3D coordinate frame. */ }
    

    This is also a top-level feature that seems intended to be "universal" in the sense above.

  • Reported: SysML 2.0a1 — Wed, 3 May 2023 15:13 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Subsetting of subjectParameter properties is wrong

  • Key: SYSML2-430
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The properties RequirementUsage::subjectParameter and CaseUsage::subjectParameter in the abstract syntax SysML.xmi currently subset Behavior::parameter. However, neither RequirementUsage nor CaseUsage specialize Behavior. Rather they (indirectly) specialize Step, so the subjectParameter properties should be subsetting Step::parameter rather than Behavior::parameter.

    (Note that this error is not apparent in the specification document, because, in the annotation for subsetting, the subsetted parameter is shown without qualification – e.g., just parameter, not Behavior::parameter.)

  • Reported: SysML 2.0b1 — Mon, 4 Sep 2023 18:27 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Adornments on ends missing in graphical syntax

  • Key: SYSML2-318
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Graphical notation is missing support for adornments on ends of ConnectionDefinitions, such as ordered, nonunique, readonly, subsets, and redefines. This is needed for information modeling and compatibility with UML and SysML v1. In UML (and SysML v1) these adornments are called 'property modifiers'. Analogously, in KerML and SysML v2 the term 'feature modifiers' would seem appropriate.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:12 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Enumeration definitions VerdictKind and VerificationMethodKind are missing from specification document

  • Key: SYSML2-554
  • Status: open  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    The enumeration definitions VerdictKind and VerificationMethodKind, which are in the normative Systems Model Library package VerificationCases, are missing from Systems Model Library subclause 9.2.16 Verification Cases in the SysML Specification.

  • Reported: SysML 2.0b1 — Wed, 22 Nov 2023 18:58 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Name all associations in the SysML abstract syntax

  • Key: SYSML2-29
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    MOF constraints require that all associations be named. But none of the associations in the SysML abstract syntax model are currently named. They should all be given generated names.

  • Reported: SysML 2.0a1 — Tue, 25 Apr 2023 23:08 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Follow typographical conventions in the SysML Metamodel clause

  • Key: SYSML2-30
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Subclause 8.1 defines typographical conventions to be used in the KerML metamodel. However, these are not being followed consistently throughout Clause 8 and Clause 9.

    Also, subclause 6.3 is inconsistent with 8.1 and should be removed.

  • Reported: SysML 2.0a1 — Tue, 25 Apr 2023 23:11 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Example FrontAxle definition

  • Key: SYSML2-158
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In A.3 Definitions, in the diagram in Figure 58, the feature FrontAxle::steeringAngle is shown subsetting ISQSpaceTime::angularMeasure. However, in the corresponding textual notation representation, steeringAngle is shown as subsetting ISQ::planeAngle. Now, ISQ::planeAngle is actually an alias for ISQSpaceTime::angularMeasure, so the representations as shown are technically correct. But the difference will be likely be confusing to the reader. Perhaps, at least, the ISQ::planeAngle should be changed to ISQ::angularMeasure in the textual representation.

  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 20:08 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Example analysis case fuelEconomyAnalysis

  • Key: SYSML2-159
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In A.9 Analysis, in the diagram in Figure 70 Analysis Case fuelEconomyAnalysis, the following need to be addressed:

    1. The compartment title subjects should be subject.
    2. The compartment title documentations should be doc.
    3. The empty subject compartment under fuelEconomyAnalysisObjective should be removed.
    4. The notation for the objective using an edge labeled <<objective>> needs to be confirmed. This notation is not shown in Table 24 Analysis Cases – Representative Notation in 7.22, nor does it seem to be supported by the graphical BNF in 8.2.3.22.
  • Reported: SysML 2.0a1 — Sat, 29 Apr 2023 20:20 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

specializesFromLibrary arguments use inconsistent notation for strings

  • Key: SYSML2-426
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The arguments for specializesFromLibrary are sometimes single quoted and sometimes double quoted. Search on specializesFromLibrary(' and specializesFromLibrary(" to find them.

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 15:35 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Incorrect textual notation for TextualRepresentation

  • Key: SYSML2-626
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The textual notation for example "Annotation-Textual Representation" in clause 7.4.1 Table 2 is incorrect. A TextualRepresentation is always owned by its represented element, so the keyword about should not be used.

  • Reported: SysML 2.0b1 — Fri, 22 Dec 2023 16:04 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Incorrect textual notation for rep annotation

  • Key: SYSML2-484
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In Table 2, example "Annotation-Textual Representation", the textual notation incorrectly uses "rep about" syntax, while any textual representation element should be owned by, and therefore inside the body of, the element being represented. The upper textual notation fragment must be removed, and the lower fragment kept as is.

  • Reported: SysML 2.0a1 — Wed, 18 Oct 2023 13:49 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

The XMI versions of standard libraries should be delivered

  • Key: SYSML2-527
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The 2023-10 version of SysML2 still not include the XMI version of the standard libraries but only the textual syntax version.

    Because of this, model elements from those libraries have no stable identifiers

  • Reported: SysML 2.0a1 — Thu, 9 Nov 2023 15:45 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Intersection missing for some multiple specializations

  • Key: SYSML2-561
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Some multiple specializations in the libraries might be intended to be intersections, including feature specializations. For example, from SYSML2-490, under Actions::Actions

    action sendSubactions: SendAction[0..*] :> subactions, sendActions {
      doc /* 
          * The subactions of this Action that are SendActions. 
          */ 
    }
    
    action acceptSubactions: AcceptAction[0..*] :> subactions, acceptActions {
      doc /* 
          * The subactions of this Action that are AcceptActions. 
          */ 
    }
    
  • Reported: SysML 2.0b1 — Fri, 1 Dec 2023 15:34 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Tables in overview sections have empty cells SysML v2 column

  • Key: SYSML2-562
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The table in the mapping chapters' overview sections sometimes has no information about the SysML v2 target element. There should be a target element or a note that the rationale for not having a target element can be found in the following section that lists the elements that are not mapped with a justification.

  • Reported: SysML 2.0b1 — Mon, 4 Dec 2023 15:11 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Mapping tables in the overview sections show duplicates in the SysML v2 column

  • Key: SYSML2-564
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Some entries in the mapping overview tables show duplicate entries in the SysML v2 column.

  • Reported: SysML 2.0b1 — Mon, 4 Dec 2023 16:47 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Rename ~InterfaceBlock_Mapping

  • Key: SYSML2-569
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The special symbol ~ at the beginning is allowed, but it could lead to issues in mapping implementations because most script and programming languages do not allow it.

    The mapping class was introduced by SYSML2-139.

  • Reported: SysML 2.0b1 — Mon, 4 Dec 2023 21:14 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

The mapping name "~InterfaceBlock_Mapping" is not convenient

  • Key: SYSML2-587
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The tilde character is not accepted in a name by most of the progarmming languages. So, it's not convenient to use it in a mapping name that is intended for software implementation

  • Reported: SysML 2.0a1 — Tue, 5 Dec 2023 22:18 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Constraint on Definition variation memberships is too restrictive

  • Key: SYSML2-613
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    with these two part defs:

    part def Source {
      part B;
    }
    
    part def Target{
      part C;
    }
    

    I want to define a variation of an allocation definition thus:

    variation allocation def theSet {
        end s:Source;
        end t:Target;
        variant allocation Scenario1:theSet {
            allocate s.B to t.C;
        }
    }
    

    and then use it thus:

    part Top {
        part b:Source;
        part a:Target;
    }
    
    allocation alloc1:theSet allocate Top.b to Top.a {
        assert constraint {alloc1 == Scenario1}
    }
    

    However, it seems that variations can only contain variants as members and hence I need to create another allocation definition to hold the ends, thus:

    allocation def theOtherSet {
        end s:Source;
        end t:Target;
    }
    

    and have the variation specialise this new definition thus:

    variation allocation def theSet:>theOtherSet {
        end s:Source;
        end t:Target;
        variant allocation Scenario1:theSet allocate s to t{
            allocate s.B to t.C;
        }
    }
    

    This seems unnecessarily restrictive and I can find no rationale in the spec for this.

  • Reported: SysML 2.0b1 — Wed, 20 Dec 2023 09:31 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Constraint on Usage variation memberships is too restrictive

  • Key: SYSML2-615
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    with these two part defs:

    part def Source {
      part B;
    }
    
    part def Target{
      part C;
    }
    

    I want to define a variation of an allocation definition thus:

    variation allocation def theSet {
        end s:Source;
        end t:Target;
        variant allocation Scenario1:theSet {
            allocate s.B to t.C;
        }
    }
    

    and then use it thus:

    part Top {
        part b:Source;
        part a:Target;
    }
    
    allocation alloc1:theSet allocate Top.b to Top.a {
        assert constraint {alloc1 == Scenario1}
    }
    

    However, it seems that variations can only contain variants as members and hence I need to create another allocation definition to hold the ends, thus:

    allocation def theOtherSet {
        end s:Source;
        end t:Target;
    }
    

    and have the variation specialise this new definition thus:

    variation allocation def theSet:>theOtherSet {
        end s:Source;
        end t:Target;
        variant allocation Scenario1:theSet allocate s to t{
            allocate s.B to t.C;
        }
    }
    

    This seems unnecessarily restrictive and I can find no rationale in the spec for this.

  • Reported: SysML 2.0b1 — Wed, 20 Dec 2023 09:50 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Find a better way to differ between definition and instance elements in graphical notation

  • Key: SYSML2-640
  • Status: open  
  • Source: MDD4All ( Dr. Oliver Alt)
  • Summary:

    In SysML v2 parts are drawn in the graphical notation with rounded corners. In UML and and also in SysML v1.x there is a clear graphical language paradigm to use rounded corners only for behavioral elements like activities, states and use cases and all elements showing static aspects of a system like data structures, architectural things etc. are defining elements that have no rounded corners (e.g. classes, objects, blocks, parts, nodes etc.).
    Would it not be possible to find a better graphical notation to differ between definition elements and their instances? What about using different shapes or different stroke widths? Also icons could be used in graphical elements to express a what kind of element it is - like it is done in BPMN for example.
    I think following the rule, that behavioral aspects are modeled with rounded elements and static aspects with not-rounded elements would provide a better compatibility to still existing and well known standards like UML, SysML v1.x, BPMN etc.
    Many people are still trained with high effort in using this notations in their daily work and I think they will be very confused when the should use SysML v2 in the future with that big paradigm shift in the graphical notation.

  • Reported: SysML 2.0b1 — Tue, 16 Jan 2024 12:01 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

package View and Viewpoint TBD should not be included in the xmi file

  • Key: SYSML2-636
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    package x View and Viewpoint TBD should not be included in the SysML.xmi file.

  • Reported: SysML 2.0b1 — Fri, 12 Jan 2024 17:59 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

VerificationCase::subVerificationCases is typed incorrectly

  • Key: SYSML2-634
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the Systems Model Library file VerificationCases.sysml, the feature VerificationCase::subVerificationCases is declared as having the type Case. It should instead be VerificationCase. (Note that this is actually specified correctly in the SysML Specification document, 9.2.16.2.2 VerificationCase.)

  • Reported: SysML 2.0b1 — Tue, 9 Jan 2024 00:04 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Do not use abbreviations for key word in SysML v2/KerML textual concrete syntax

  • Key: SYSML2-641
  • Status: open  
  • Source: MDD4All ( Dr. Oliver Alt)
  • Summary:

    I would like to recommend, that abbreviations are not used in key words for the SysML v2 textual notation (resp. KerML). A good example is the key word "def" instead of "definition".
    Why it is here an abbreviation and other (longer) key words are not?
    To make the textual notation more consistent for users, eliminate all abbreviations and write it out.

  • Reported: SysML 2.0b1 — Tue, 16 Jan 2024 12:09 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Annotation diagram needs to be updated

  • Key: SYSML2-844
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The kernel abstract syntax diagram in Figure 4. Annotations (in 8.3.4 Annotations Abstract Syntax) needs to be updated consistent with the resolution to KERML-21 approved by the KerML FTF.

  • Reported: SysML 2.0b1 — Tue, 23 Jan 2024 23:09 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT
  • Attachments:

User-defined keywords are not allowed on metadata

  • Key: SYSML2-631
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The productions for MetadataDefinition and MetadataUsage in 8.2.2.26 Metadata Textual Notation do not provide for the use of user-defined keywords, even though it is allowable to have nested metadata usages in both cases.

  • Reported: SysML 2.0b1 — Tue, 2 Jan 2024 19:50 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Make orthogonal and rounded corners the default connector style for architectural drawings

  • Key: SYSML2-642
  • Status: open  
  • Source: MDD4All ( Dr. Oliver Alt)
  • Summary:

    In UML and SysML v1 a connector that is used to connect two ports can be a direct connection what is drawn vertically between one port and another.
    The semantics does not differ if it is a direct connection or an orthogonal bented line. SysML user are often electrical or mechanical engineers and they are trained to draw connections between inputs and outputs in an orthogonal way. So why not make this the default connector shape in SysML for all connectors use to connect two ports together?
    Another advice would be to round the corner where the connector is bented. This would avoid misunderstandings when you zoom into a diagram. You can directly recognize that this a connector and not a corner of a component for example. Such a connector style is used as default in the BPMN 2.0 notation and it produces very readable diagrams.

  • Reported: SysML 2.0b1 — Tue, 16 Jan 2024 12:22 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

ISQ in specification and libraries not aligned

  • Key: SYSML2-185
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    For example, comparing Clause 9.8.4 (ISQ) to ISQSpaceTime library,

    • universalCartesianSpatial3dCoordinateFrame is missing from the spec
    • In Clause (9.8.4.2.5),
      • Title is Cartesian3dSpatialCoordinateSystem, but the library and the rest of the spec has it as Cartesian3dSpatialCoordinateFrame.
      • General is VectorMeasurementReference, but the library specializes it from Spatial3dCoordinateFrame, which isn't in the spec.

    Might be others.

  • Reported: SysML 2.0a1 — Wed, 3 May 2023 15:29 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Effective name is not correct for a redefined perform action usage

  • Key: SYSML2-85
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The PerformActionUsage::namingFeature operation documentation states that "The naming Feature of a PerformActionUsage is its performedAction." However the body of the operation is specified as exhibitedState. This should instead be performedAction.

    Further, this specification means that that, if a PerformActionUsage redefines another ActionUsage and doesn't have a reference usage, then it will not have any effective name. One would instead expect that its effective name in this case be the same as the name of the action it is redefining, as for a regular ActionUsage.

  • Reported: SysML 2.0a1 — Thu, 27 Apr 2023 21:49 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Issues with SysML grammar

  • Key: SYSML2-635
  • Status: open   Implementation work Blocked
  • Source: itemis AG ( David Akehurst)
  • Summary:

    Reuse of KerML rules in SysML grammar is not described sufficiently.
    Not clear which rules are reused and which not.
    Reused rules are simply missing from the SysML definitions.

    Additionally,
    1. AnnotatingElement defined twice: In 8.2.2.4.1 and in 8.2.2.5.2
    2. Extra ')' in 8.2.2.15 AllocationUsageDeclaration
    3. MetadataUsageDeclaration not defined, used in 8.2.2.26 in MetadataUsage
    4. PerformActionDeclaration not defined, used in 8.2.2.17.3 in TransitionPerformActionUsage - should this be PerformActionUsageDeclaration?
    5. StakeholderDefinition not defined, used in 8.2.2.5.2 in DefinitionElement
    6. BindingConnector not defined, used in 8.2.2.6.4 in VariantUsageElement and 8.2.2.14.1 in InterfaceNonOccurrenceUsageElement - should this be BindingConnectorAsUsage
    7. Succession not defined, used in 8.2.2.6.4 in VariantUsageElement and 8.2.2.14.1 in InterfaceNonOccurrenceUsageElement - should this be SuccessionAsUsage
    8. AnnotatingMember defined twice, in 8.2.2.8 and in 8.2.2.4.1
    9. MessageEvent not defined, used in 8.2.2.13.4 in MessageEventMember - should the definition of MessageEnd (after it) be named MessageEvent?
    10. ItemFeature not defined, used in 8.2.2.13.4 in FlowPayloadFeatureMember - should it be FlowPayloadFeature
    11. ItemFlowEnd not defined, used in 8.2.2.13.4 in FlowEndMember - should it be FlowEnd
    12. InterfaceNonOccurrenceUsageMember not defined, used in 8.2.2.14.1 in InterfaceBodyItem - should it be InterfaceNonOccurrenceMember
    13. FeatureChain not defined, used in 8.2.2.16.5 in OwnedFeatureChainMember - should this be OwnedFeatureChain

  • Reported: SysML 2.0b1 — Wed, 10 Jan 2024 18:48 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

checkRequirementUsageObjectiveRedefinition is incorrect

  • Key: SYSML2-553
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 8.3.20.9 RequirementUsage, the checkRequirementUsageObjectiveRedefinition constraint requires that "A RequirementUsage whose owningFeatureMembership is a ObjectiveMembership must redefine the objectiveRequirement of each CaseDefinition or CaseUsage that is specialized by the owningType of the RequirementUsage." However, the objectiveRequirement property of a CaseDefinition (see 8.3.21.2) or a CaseUsage (see 8.3.21.3) is derived to be only the owned objective of the case. This means that, if a case declares an owned objective, but specializes a case with an inherited objective, then checkRequirementUsageObjectiveRedefinition will actually not be satisfiable.

  • Reported: SysML 2.0b1 — Wed, 22 Nov 2023 04:58 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Parsing KerML Feature elements from SysML textual notation

  • Key: SYSML2-783
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In some cases, parsing certain short-hand SysML notations results in the creation of KerML Feature elements. In particular, according to 8.2.2.13.1 Connection Definition and Usage, shorthand connection notation such as

    connection connect x to y;
    

    is parsed into a ConnectionUsage with two end features that are KerML Features. However, it is not possible to create ends that are KerML Features in "long hand" SysML notations. For example, in the notation

    connection {
        end references x;
        end references y;
    }
    

    the two ends are parsed as SysML ReferenceUsages, not KerML Features.

    This means that these two examples, while semantically equivalent, are not actually just different surface notations for the same underlying abstract syntax representation. it would be better to have the shorthand notations parse to fully SysML abstract syntax, as much as possible, so that the shorthand notation is just a different surface representation of a certain abstract syntax pattern that can also be equally represented in the full notation.

  • Reported: SysML 2.0b1 — Mon, 22 Jan 2024 04:35 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

User-defined keywords are not allowed on enumeration definitions

  • Key: SYSML2-637
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The BNF in 8.2.2.8 Enumerations Textual Notation does not allow user-defined keywords on EnumerationDefinitions, even though nested metadata feature annotations are allowed in both cases. (Note that the syntax for EnumerationUsages does allow for user-defined keywords.)

  • Reported: SysML 2.0b1 — Mon, 15 Jan 2024 22:42 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Comment locale not in textual notation

  • Key: SYSML2-643
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 8.3.4 Annotations Abstract Syntax, in Figure 4 Annotation (from KerML), Comment is shown as having a locale attribute. However, the is no provision for specifying this in the concrete syntax for Comments, neither the textual (8.2.2.4.2 Comments and Documentation) nor graphical (8.2.3.4 Annotations Graphical Notation).

  • Reported: SysML 2.0b1 — Thu, 18 Jan 2024 23:25 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT
  • Attachments:

Inconsistent graphical notation for succession, message and flow edges


Metadata - category refers to DCMI abstract (not a category) / dublinCoreTag. Dublin Core Should Only Apply to Artefacts (Documents, Sound, Video, Text) Not any AD Element

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Metadata attributes

    1) category. Refers to DCMI abstract which isn't a category
    2) dublinCoreTag refers to 'A metadata category that is a DublinCore tag.' This doesn't define anything. Any DCMI tag? Not all CMI tags are categories. Why not simply list those DCMI tags that you think are essential / useful rather than what looks to be an arbitrary and inconsistent reference?
    3) Metadata is defined as 'a conment that can be applied to any element in the architecture'. This is incorrect - it can be applied to any AD element. The DCMI tags only apply to artefacts - video, text, sound, document etc so they don't apply to every AD element as many/most of these do not represent artefacts. DCMI tags only apply to documents, standards etc.

  • Reported: SysML 1.5 — Mon, 8 Apr 2024 11:31 GMT
  • Updated: Mon, 8 Apr 2024 14:23 GMT

Metadata, ArchitectureMetadata Incorrect - Metadata Applies to Architecture Description Not Architecture. ArchitectureMetadata duplicates Metadata in application to an AD

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    This is a consequence of the lack of differentiation within the UAF (and donor AFs) between 'Architecture' and 'Architecture Description'

    Fig 9:122 Metadata.
    Definition: 'A comment that can be applied to any element in the architecture. The attributes associated with this element details the relationship between the element and its related dublinCoreElement, metaDataScheme, category and name. This allows the element to be referenced using the Semantic Web.'

    it is clear that this refers to 'architecture description' not 'architecture' e.g. the application of DCMI elements

    It should therefore be 'applied to any element in the architecture description'

    If Metadata is already defined as applying to an architecture description, how can ArchitectureMetadata specialise this and also be applied to the architecture description description - this is what Metadata does and as part of an AD which describes an architecture there is no need for 'ArchitectureMetadata'?

  • Reported: SysML 1.5 — Mon, 8 Apr 2024 10:58 GMT
  • Updated: Mon, 8 Apr 2024 14:22 GMT

View Specifications::Summary & Overview::Summary & Overview - Missing Relationships and Triples, Concerns Not Defined

  • Status: open   Implementation work Blocked
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    8.1.2 View Specifications::Summary & Overview::Summary & Overview

    General problem - there is no such thing as 'view specification' - it doesn't exist in the DMM itself (text should only include defined concepts), it seems to be being used as a synonym for ISO 42010::'architecture viewpoint' (if this is the case then 'architecture viewpoint' is the correct and consistent term to use.

    Concerns: ''quick overview of an architecture description and summary of analysis. In the initial phases of architecture development, it serves as a planning guide. Upon completion of an architecture, it provides a summary of findings, and any conducted analysis.'

    Problems -
    1) this is an overview and its application not a list of concerns held be stakeholders
    2) Given the common confusion in the UAF between 'architecture' and 'architecture description' - is this 'phases of architecture development' or 'phases of architecture description development'? Since an architecture description may be used to provide comment on architecture this is ambiguous in the UAF contetx where these terms aren't differentiated.
    3) 'It isn't completion of architecture - it's not even completion pf 'architecture description' - what the author seems to be stating is completion of the 'architecture task' that produce the architecture description. The description os wrong and possibly more triples need to be defined in the DMM

    Defintion
    'provides executive-level summary information in a consistent form that allows quick reference and comparison among architectures. The Summary and Overview includes assumptions, constraints, and limitations that may affect high-level decision processes involving the architecture.'

    Problems;
    4) This is a description not a definition

    Figure 8:11 - Summary & Overview

    The green elements are relationships - not tuples as defined in the legend. The expectation is that view content consists of triples (node-connector-node).
    5) General problem - There is nothing that defines how these views are to be interpreted (ISO 42010 requires this and it would aid consistent development and provide rules for verification of each view).

    Anything that doesn't form the basis for a triple shouldn't be in the viewpoint definition i.e.

    6) ArchitecturalDescription, ArchitectureMetadata, Metadata as these don't appear to form any triple

    7) View, Viewpoint. There are no relationship elements provided to form a triple with ArchitecturalDescription

    8) Stakeholder, Concern, OrganizationalResource, ActualOrganizationalResource have no relationship with ArchitecturalDescription

    9) There is no relationship element between ArchitecturalReference and Architecture so it is impossible to establish a link between the Architecture, its impacts etc and the ArchitecturalDescription so impossible to describe this.

    Triples should be able to be read as sentences and have clear semantics:

    'ArchitecturalDescription Architectural Reference Architectural Description'
    10) What does this mean? Is this a trace between ArchitecturalDescriptions i.e. 'ArchitecturalDescription traces to / references / etc ArchitecturalDescription'. A currently defined this makes no sense. I suspect that the problem is that elements are added but the triples so-formed are not being read to make sure that they are intelligible i.e. object-focussed rather than relationship-focussed approach.

    11) 'Opportunity Phases ActualStrategicPhase' - what does this mean? If the sentence is unclear it either won't be used or be used inconsistently as each individual attempts to try and understand it (not conducive to shared understanding)

  • Reported: SysML 1.5 — Mon, 8 Apr 2024 10:39 GMT
  • Updated: Mon, 8 Apr 2024 14:21 GMT

UAFElement - Attributes Missing. URI incorrectly defined

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Figure 9:134 – UAFElement shows a single attribute - URI

    Don't UAFElements have a name, identifier (other than URI), description etc? According to this they don't.

    URI is incorrectly defined - 'Captures Unique identifier for the element.'

    assuming that URI = Unifiform Resource Identifier - which a url-form of identifier (W3C define this so the definition ought to be standards-based rather than local). It isn't just an identifier. 'captures' shouldn't be part of the definition - that's how the attribute is used.

  • Reported: SysML 1.5 — Sun, 7 Apr 2024 14:30 GMT
  • Updated: Mon, 8 Apr 2024 14:20 GMT

Figure 9:134 / 8:86 Undefined DMM Elements - Refine, Trace, Refine, Verifiy, Requirement. Requirement not a UAF Element?

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Within the document there appears to be no usable link or definition of Satisy [another implementation artefact] and no definition of a Requirement element or other relationships linked to Requirement (Trace, Verify, Refine).

    Figure 8:86 multiplicities don't look to be consistent - 0..1 on Trace but 1 on Satisfy. Trace looks to be wrong - think someone trying to describe Requirement traces to Requirement, UAFELement traces to UAFElement and UAFElement traces to Requirement but there is no identification of path and its ambigous or wrong.

    Why is Requirement not a UAF Element? If it's not why is it even in this specification? Again I suspect this is an implementation artefact - someone thinking of a SysML::Requirement (which is an implementation of the DMM)

  • Reported: SysML 1.5 — Thu, 4 Apr 2024 14:29 GMT
  • Updated: Thu, 4 Apr 2024 15:21 GMT

Figure 9:129 ArchitecturalDescription - Multiplicities Incorrect

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Inconsistent name wrt ISO 42010 and with its own definition - ArchitecturalDescription vs Architecture Description.

    The multiplicities aren't correct. For example we have on Architecture to ArchitecturalDescription we have * on both ends which means that an Architecture has no existance independently of its ArchitectureDescriptions (plural as there have to be many of them). Should be 0..* on ArchitecturalDescription. Similarly with View it ought to be 1..* View and 0..* Viewpoint (otherwise an ArchitecturalDescription is required to include multiple Viewpoints which doesn't allow for a central set of 'library' viewpoints in ISO 42010 terminology).

    The relationships with View, Viewpoint, Architecture need to be named.

    'expresses' looks like a role but cannot be. If it is a role it needs to qualify the target element e.g. 'describedArchitecture' not the relationship.

    Why does ArchitectureMetadata have a multiplicity of 1 on ArchitecturalDescription - is each piece of metadata unique to every ArchitecturalDescription?

    What is an ArchitecturalReference? This looks like a relationship. What then is the point of adding a role name to a relationship? Isn't this just 'UAFElement traces to ArchitecturalDescription?

  • Reported: SysML 1.5 — Thu, 4 Apr 2024 14:08 GMT
  • Updated: Thu, 4 Apr 2024 15:19 GMT

Figure 8:2 Architecture Views Does Not Conform to ISO/IEC/IEEE 42010 - Multiplicities, Naming, Direction [repeat - Tracker Now Using Correct OMG Identifiers]

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The use of a '*' multiplicity is incorrect - should be 1 or more Concerns. Similarly an ArchitecturalDescription (name error - should be ArchitectureDescription) should be composed of 1 or more Architecture Views (not *). A Viewpoint may frame only 1 Concern (not *)

    The use of a direction indicator is undefined and looks to be incorrect. In the direction from View to Viewpoint what is the relationship? In ISO 42010 there is a 'governs' relationship.

    The use solely of role names is incorrect - roles only label the target (source) node - they do not define a relationship. How is anyone supposed to implement a set or relationships where the relationships are not labelled? Figure 8:2 should use the relationship names defined in 42010 i.e. standardise.

    Using a role name that simply repeats the name of the source / target element is pointless - it adds no information whatsoever. The other problem with solely using role names is that if the label is offset it isn't clear whether it is a role or a relationship name and therefore whether it applies to the node or relationship.

  • Reported: SysML 1.5 — Thu, 4 Apr 2024 13:20 GMT
  • Updated: Thu, 4 Apr 2024 15:17 GMT

Figure 8:2 Architecture Views Does Not Conform to ISO/IEC/IEEE 42010 - Multiplicities, Naming, Direction

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The use of a '*' multiplicity is incorrect - should be 1 or more Concerns. Similarly an ArchitecturalDescription (name error - should be ArchitectureDescription) should be composed of 1 or more Architecture Views (not *). A Viewpoint may frame only 1 Concern (not *)

    The use of a direction indicator is undefined and looks to be incorrect. In the direction from View to Viewpoint what is the relationship? In ISO 42010 there is a 'governs' relationship.

    The use solely of role names is incorrect - roles only label the target (source) node - they do not define a relationship. How is anyone supposed to implement a set or relationships where the relationships are not labelled? Figure 8:2 should use the relationship names defined in 42010 i.e. standardise.

    Using a role name that simply repeats the name of the source / target element is pointless - it adds no information whatsoever. The other problem with solely using role names is that if the label is offset it isn't clear whether it is a role or a relationship name and therefore whether it applies to the node or relationship.

  • Reported: SysML 1.5 — Thu, 4 Apr 2024 13:17 GMT
  • Updated: Thu, 4 Apr 2024 15:17 GMT

1.1 Introduction - Normative + Informative Identifies Wrong OMG Specifications

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    incorrect identifiers for OMG documents

    1. 'The UAF Domain Metamodel (DMM) (this document dtc/21-12-06)' - incorrect - should be - formal/22-07-03
    2. 'The UAF Modeling Language (UAFML) (document dtc/21-12-07)' - incorrect - should be - formal/22-07-05
    3. 'The UAF Traceability, Appendix A (document dtc/21-12-10)' - incorrect - should be - formal/22-07-07

    Errors also in Table 1-1 Table of Related Documents

  • Reported: SysML 1.5 — Thu, 4 Apr 2024 12:14 GMT
  • Updated: Thu, 4 Apr 2024 15:12 GMT

Typo in brief description about Activity Diagram

  • Status: open  
  • Source: OTIS Elevator Company ( pradeep miriyala)
  • Summary:

    In 3.2.1, the statement "11 Activities - Defines the extensions to UML 2 activities, which represent the basic unit of behavior that is used in activity, sequence, and state machine diagrams. The activity diagram is used to describe the slow of control and flow of inputs and outputs among actions." mentions "slow of control".
    It should have been "flow of control".

    After correction, it shall be,
    "11 Activities - Defines the extensions to UML 2 activities, which represent the basic unit of behavior that is used in activity, sequence, and state machine diagrams. The activity diagram is used to describe the flow of control and flow of inputs and outputs among actions."

  • Reported: SysML 1.6 — Wed, 25 Oct 2023 13:09 GMT
  • Updated: Tue, 7 Nov 2023 15:59 GMT

Element Name Incorrectly Shown as InternalBlockDiagram - Should be Dependency

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The first row of Table 8-4 shows element InternalBlockDiagram - for a connector whose Abstract Syntax ref is UML4SysML::Dependency.

    This is incorrect - it should be a Dependency connector element - identical to first row in Table 8-2

  • Reported: SysML 1.6 — Tue, 29 Aug 2023 13:23 GMT
  • Updated: Wed, 30 Aug 2023 15:28 GMT

Conform as a Generalization is Incorrect - A View is Not a Viewpoint / 'is a' Does Not Equate to Conform

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    A Conform relationship is a generalization between a view and a viewpoint.

    This is semantically incorrect. Assuming that viewpoint is being used in ISO 42010 sense (no stated anywhere within the specification so this is an error if true as the common use of 'viewpoint' is not the same as that in the standard) - a viewpoint is a specification against which a view is prepared (and interpreted). A view is not a viewpoint. What's has effectively been said is that a design that conforms to a requirement document is a requirement document.

    In the reverse sense if I want to define that an oak (tree) is an oak I wouldn't then state an Oak (tree) conforms to a Tree.

    If you need to state the conformance relationship between view and viewpoint SysML provides somewhere a 'satisfy' stereotype.

    The history of the OMG misrepresenting or misunderstanding what a 42010::viewpoint is in their documents over the years is woeful.

  • Reported: SysML 1.5 — Sun, 4 Jun 2023 09:16 GMT
  • Updated: Fri, 14 Jul 2023 20:07 GMT

View is not a Viewpoint

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The View conform Viewpoint relationship is shown as a Generalization. This then states that a View is a Viewpoint which is incorrect. A Viewpoint in ISO/IEC/IEEE 42010 terms is a specification against which a View is prepared and interpreted.

    I suspect that this is another example of a long held error where View was described as an instance of a Viewpoint. It isn’t. This has never been true in the international standard.

  • Reported: SysML 1.5 — Tue, 20 Jun 2023 11:15 GMT
  • Updated: Fri, 14 Jul 2023 20:07 GMT

Artifacts and «document»

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    the statement from v. 1.5 (section A.2)

    SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. Properties of the artifact can capture information about the document. Use a «trace» abstraction to relate the document to model elements. The document can represent text that is contained in the related model elements.

    was removed from 1.6... but 1.6 retained Artifact in its UML4SYSML set...

    I think, either remove Artifact or put the statement back in

  • Reported: SysML 1.6 — Thu, 4 Nov 2021 16:13 GMT
  • Updated: Fri, 14 Jul 2023 19:59 GMT

UML::Artifact is Excluded But Specification Doesn't State With What Documents/Artifacts Are to Be Represented with Instead

  • Status: open   Implementation work Blocked
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    In Table 4.2 UML::Artifact is defined as excluded.

    In previous versions there was a paragraph Figure A.4 - 'SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. '

    This, whilst contradicting the exclusion of Artifact from SysML did at least define how artifacts/documents were to be represented. Now there is absolutely nothing other than we can't use Artifact.

    How are we supposed to represent a document? As there are few to no specialisation hierarchies in the specification it's almost impossible to see the thinking and, say, where / how deployedDocument fits into a taxonomy.

    I'm trying to create a SysML profile and I need to represent a Document, Standard, Contract etc - all artifacts in the UML sense but no idea what I should now be using in a SysML profile.

  • Reported: SysML 1.7b1 — Sat, 24 Jun 2023 11:11 GMT
  • Updated: Fri, 14 Jul 2023 19:56 GMT

Risk, Source and Verification Method Are Attributes of Any / All Requirements Not Just an Extended Requirement

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The verifyMethod, source and risk attributes are only available for extended requirements i.e. a straight vanilla Requirement has no associated verification method or risk. This doesn't reflect reality / the actual taxonomy and has nothing to do with the sub-classification of a requirement as physical, functional etc. i.e. these are attributes of the parent Requirement not the child extended requirement. It also then requires that a SE has to subclassify before they can ascribe a risk level or verification method.

    Even looking at the definiton of extendedRequirements this definition has nothing to do differentiation in terms of an ontology - only the means to do things. 'A mix-in stereotype that contains generally useful attributes for requirements'

    It also means that if the SE has a requirement that doesn't fit into the OMG classification schema i.e. none of the existing categories then they cannot easily assign these attributes (e.g. a requirement to conform to a standard isn't a design constraint, isn't functional etc). These common attributes should be present without forcing the SE to subclassify before they are available.

  • Reported: SysML 1.5 — Fri, 26 May 2023 11:10 GMT
  • Updated: Thu, 15 Jun 2023 12:48 GMT

Issues with SysML 1.7 XMI


Typo: Constraint name 8 of Adjunct Property (again)

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Duplicate of SYSML17-222 for which the resolution does not resolve anything!

  • Reported: SysML 1.6 — Wed, 29 Jun 2022 15:15 GMT
  • Updated: Wed, 29 Jun 2022 15:16 GMT

Statement about UML semantics of ActivityPartitions is wrong

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    Classifiers or Properties represented by an «AllocateActivityPartition» do not have any direct responsibility for invoking behavior depicted within the partition boundaries. To depict this kind of direct responsibility, the modeler is directed to the UML 2 standard, sub clause 12.3.10, "ActivityPartition," Semantics topic.

    However, the UML says in clause 15.6.3.1 (which is the current number of the referenced section):

    Behaviors invoked within the partition are the responsibility of instances of the Classifier that the partition represents.

    Let me paraphrase this:
    SysML: "UML says Classifiers are responsible for invoking behaviors"
    UML: "Classifiers are responsible for behaviors"

    I guess invoking a behavior was confused with carrying out a behavior.

    My suggestion: It is not necessary to restate UML semantics in SysML. Since it cannot be expressed in ocl anyway, the complete constraint can be removed.

  • Reported: SysML 1.6 — Wed, 6 Apr 2022 18:44 GMT
  • Updated: Wed, 20 Apr 2022 16:04 GMT

wrong statement about UML semantics of partitions

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    Contraints 2_not_uml_semantics [...]. Classifiers or Properties represented by an «AllocateActivityPartition» do not have any direct responsibility for invoking behavior depicted within the partition boundaries. To depict this kind of direct responsibility, the modeler is directed to the UML 2 standard, sub clause 12.3.10, "ActivityPartition," Semantics topic.

    This is not what UML specifies. Instead it says in "ActivityPartition", Semantics topic:

    Behaviors invoked within the partition are the responsibility of instances of the Classifier that the partition represents.

    That means, the instances of the represented element are responsible for carrying out the Behavior, not for invoking it. The context of the Activity owning the action is doing that - partitions have no effect on this.

  • Reported: SysML 1.6 — Tue, 28 Sep 2021 12:15 GMT
  • Updated: Wed, 20 Apr 2022 16:04 GMT

QUDV: Specification of PrefixedUnit should have a QuantityKind

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The redefinition of Unit::quantityKind property by PrefixeUnit::noQuantityKind with multiplicity 0 is wrong.

    The ConversionBasedUnit class should redefine quantityKind so that it is derived from the one defined by its referenceUnit.

  • Reported: SysML 1.6 — Thu, 29 Apr 2021 15:47 GMT
  • Updated: Sun, 10 Apr 2022 07:34 GMT

Added BehavioralFeatures to AdjuctProperty

  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

    Add UML::BehavioralFeature (UML::Operation or UML::SignalReception) to the allowed list of UML metaclasses of SysML::AdjunctProperty.principal, thus allowing a visual symbol (association) as well as fUML implementable way of accessing runtime instances of these behaviors through the structures that have them as their context. You could add them to the same constraint as CallAction, using the UML::BehavioralFeature.method as the constraining metaproperty . Also add an “or” to the constraint to allow SignalReception to get to it’s Signal metaproperty instead, or just create a new constraint separate for SignalReceptions.

  • Reported: SysML 1.6 — Mon, 14 Mar 2022 21:39 GMT
  • Updated: Thu, 17 Mar 2022 15:02 GMT

Meta-ticket: SysML-1.6: Specification body (only) figure inconsistencies and errors and related text inconsistencies

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    For issues with figures and diagrams and directly related text in the main specification body (only).

    Excludes diagrams from Annex D (but includes those diagrams in the text body that should be consistent with the Hybrid SUV sample problem).

    Includes diagrams that are not related to the Hybrid SUV sample problem.

    To prevent issue explosion, please report minor issues as single comments here.

    Please link more substantial issues related to main spec body figures and related text to this meta-ticket.

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 12:54 GMT
  • Updated: Thu, 3 Mar 2022 17:55 GMT

ConstraintBlock: abstract syntax consistency

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Even if their respective specified semantics indicate that UML::Constraint::constrainedElement and the constraint parameters of a ConstraintBlock are similar, there is currently no constraint enforcing their consistency

  • Reported: SysML 1.6 — Thu, 5 Sep 2019 14:37 GMT
  • Updated: Sat, 12 Feb 2022 00:17 GMT
  • Attachments:

wrong name on Figure 9-6

  • Status: open  
  • Source: Performant Data LLC ( Mike)
  • Summary:

    The port on the ecu:PowerControlUnit of type ~ICE that links to the InternalCombustionEngine should be named "ice", not "ctrl", in order to match the text description of the figure.

  • Reported: SysML 1.6 — Fri, 7 Jan 2022 07:18 GMT
  • Updated: Mon, 10 Jan 2022 15:38 GMT

Why are FlowProperties not included in FlowDirectionKind

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Why can I not create something that requires a flow of
    fuel to operate?... this would require me to do something
    like

    flow properties
    reqd out gas:Gasoline

    Why would we exclude this?

  • Reported: SysML 1.6 — Tue, 9 Nov 2021 14:03 GMT
  • Updated: Thu, 25 Nov 2021 19:02 GMT

The FeatureDirectionKind to which the constraint belongs is wrong

  • Status: open  
  • Source: digiproto ( wuyanwen)
  • Summary:

    2_specializations_are_constraintblocks in FeatureDirectionKind should belong to 10.3.2.1 ConstraintBlock。

  • Reported: SysML 1.6 — Wed, 10 Nov 2021 02:55 GMT
  • Updated: Wed, 24 Nov 2021 15:31 GMT

FlowProperties as aggregations

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    2_no_part Interface blocks composite properties are either ports, value properties or flow properties.
    self.base_Class.ownedAttribute->select(a|a.isComposite)->forAll(a | a.oclIsKindOf(UML::Port) or a.oclIsKindOf(ValueType))

    This OCL does not cover all of FlowProperties... FlowProperties can be typed by ValueTypes, Signals, or Blocks... so it does not cover Signals or Blocks (so presumably Signal and Block typed FlowProperties can only be aggregates, which I think is wrong)

    Presumably, an AggregationKind=shared of FlowProperties means that the block does not own the Flow but has a reference to that flow... (this is not really specified well or talked about in the standard)...

    But the issue is that if you want a FlowProperty that is typed by Block or Signal... you can not because of this OCL... it has to be a ValueType... I think this is wrong

  • Reported: SysML 1.6 — Thu, 4 Nov 2021 16:29 GMT
  • Updated: Thu, 4 Nov 2021 17:45 GMT

NoBuffer: Clarify when a token is considered "refused"

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The SysML specification says (section 11.3.2.4, description sub-clause):
    "tokens arriving at the node are discarded if they are refused by outgoing edges"

    But the condition fro considering that a token is "refused" is specified neither in that specification nor in the UML specification.

    Proposal:
    Assume that a token is refused when its availability has been checked by an action that has an edge incoming from the node where this token is stored but not accepted by this action, whatever the reason.

  • Reported: SysML 1.6 — Wed, 3 Nov 2021 16:38 GMT
  • Updated: Thu, 4 Nov 2021 16:31 GMT

Comments in the XMI have no annotated elements

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The comments in the XMI that specify the documentation of the stereotypes and stereotype attributes do not annotate the elements they document.

  • Reported: SysML 1.6b1 — Fri, 7 Jun 2019 06:50 GMT
  • Updated: Thu, 21 Oct 2021 14:58 GMT

Stereotype Rate extends ObjectNode in the XMI, but not in the abstract syntax in the specification

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    According to figure 11.8, the stereotype Rate extends UML4SysML::Parameter and UML4SysML::ActivityEdge.

    In SysML.xmi, you can find a third extension of UML4SysML::ObjectNode. The Association Ends section in the specification also lists the ObjectNode extension:

    Association Ends
    • base_ActivityEdge : ActivityEdge [0..1]
    • base_ObjectNode : ObjectNode [0..1]
    • base_Parameter : Parameter [0..1]

    The diagram table in the activity chapter provides a concrete syntax for object nodes with stereotype Rate applied.

    Besides that, the extension of ObjectNode is not mentioned in the specification.

    If it is correct, that Rate extends ObjectNode:

    • Add extension in figure 11.8.
    • Provide semantic

    If it is not correct:

    • Remove extension from XMI and association ends section
    • Remove concrete syntax from diagram table
  • Reported: SysML 1.6 — Thu, 14 Nov 2019 16:26 GMT
  • Updated: Thu, 21 Oct 2021 14:55 GMT

no longer existing "primaryQuantityKind" shown in diagram E.8

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    SYSML14-36 removed the attribute primaryQuantityKind. In Figures E.8 - E.10 it is still shown. Additionally there is a constraint that uses it: SystemofUnits constraint 1 on page 296.

  • Reported: SysML 1.6 — Thu, 23 Sep 2021 12:27 GMT
  • Updated: Thu, 23 Sep 2021 14:11 GMT

Removes references to UML4SYSML from the SysML diagrams

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Discussed by the RTF on Sep 9, 2021:

    The notation showing UML4SYSML as the namespace of metaclasses imported from UML does not conform to the UML definition of a qualified name.

    The simple name of the metaclasses shall be used instead

  • Reported: SysML 1.6 — Thu, 9 Sep 2021 17:19 GMT
  • Updated: Thu, 9 Sep 2021 17:19 GMT

Mentioned stereotype «distributedDefinition» does not exist

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    This has already been an issue of the first version and is marked as beeing resolved in SYSML-112. I checked all versions and found it everywhere. Obviously the change was forgotten.

    It also affects table 11.1 on page 133 which shows "rate=constant, rate=distribution". While you can argue, that these are just names of InstanceSpecifications, the names suggest that they are meant to be values with this non existing stereotype. I think they should be changed to a rate value like "10/s". This table is also subject to changes in SYSML17-270. These changes should be coordinated.

  • Reported: SysML 1.6 — Fri, 20 Aug 2021 15:43 GMT
  • Updated: Thu, 9 Sep 2021 15:10 GMT

FinalState should be an exitPoint Pseudostate

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The Statemachine ReadAmountSM is shown with an EndState on its border. This is not possible. The diagram is a partial copy of figure 14.13 in the UML-specification, where it is an exitPoint Pseudostate.

  • Reported: SysML 1.6 — Mon, 30 Aug 2021 10:03 GMT
  • Updated: Wed, 8 Sep 2021 13:50 GMT

connector properties should be in compartment

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    Connector properties must be composite (there is a constraint) and therefore are to be shown in the "parts" compartment. In table 8.2 they are shown in the "references" compartment.

  • Reported: SysML 1.6 — Tue, 24 Aug 2021 13:30 GMT
  • Updated: Wed, 8 Sep 2021 13:49 GMT

Behavioral Ports and Nesting

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    If you have multiple nested ports and one is a behavioral port... does that mean that all the path of ports is behavioral?... the standard should have some statement concerning this

  • Reported: SysML 1.6 — Sun, 22 Aug 2021 14:45 GMT
  • Updated: Wed, 8 Sep 2021 13:48 GMT

DistributedProperty definition has to be reveiwed

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    There are issues in the referenced sections

  • Reported: SysML 1.6 — Wed, 25 Aug 2021 15:30 GMT
  • Updated: Wed, 25 Aug 2021 15:30 GMT

The circle plus notation is for members, not ownedElements

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    In table 7-2 the circle plus notation is noted as referencing the abstract syntax UML4SysML::Package::ownedElement. Actually, according to the UML specification, it refers to Package::member. Conformant tools can optionally limit it to packagedElements, which is a subset of ownedMember. This excludes comments,which could be ownedElements but not ownedMembers.

  • Reported: SysML 1.6 — Tue, 17 Aug 2021 12:37 GMT
  • Updated: Tue, 17 Aug 2021 22:17 GMT

Consistency with Effects and Ports

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    There is the fact that a Trigger can define a port (or nested ports in SysML)... Activities add the ability to do Call/Sends using "via <port>" (and SysML adds in how to do it with nested ports)... there is nothing in StateMachines that allow Effects to be sent through specific ports... this needs to be added in for consistency

  • Reported: SysML 1.6 — Mon, 16 Aug 2021 14:07 GMT
  • Updated: Mon, 16 Aug 2021 15:37 GMT

Association Rules

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Taking the rules in SysML...
    "SysML excludes variations of associations in UML in which navigable ends can be owned directly by the association. In SysML, navigation is equivalent to a named property owned directly by a block. The only form of an association end that SysML allows an association to own directly is an unnamed end used to carry an inverse multiplicity of a reference property. This unnamed end provides a metamodel element to record an inverse multiplicity, to cover the specific case of a unidirectional reference that defines no named property for navigation in the inverse direction. SysML enforces its equivalence of navigation and ownership by means of constraints that the block stereotype enforces on the existing UML metamodel."

    and the fact that if you can navigate to something you also own it in SysML... then one can derive a rule...

    "if it does not have a navigation on the end, it can not be named"

    context: Association
    inv: memberEnd→ forAll(m |  a.navigableOwnedEnd.excludes(m) implies m.name = null)

    I think this needs to be in the Standard

  • Reported: SysML 1.6 — Wed, 11 Aug 2021 17:47 GMT
  • Updated: Mon, 16 Aug 2021 15:19 GMT

About Block constraint "3" removed by SysML v1.6

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Mr. Ed Seidewitz caught this:
    While researching a question forwarded to me by Sandy, I noticed what seems to be an inconsistency in the SysML 1.6 specification. SysML 1.5 included the following constraint under the Block stereotype:

    [3] In the UML metamodel on which SysML is built, any instance of the Property metaclass that is typed by a block (a Class with the «block» stereotype applied) and which is owned by an Association must [sic] not have a name and may not be defined as a navigable owned end of the association. (While the Property has a “name” property as defined by its NamedElement superclass, the value of the “name” property, which is optional, must be missing.)

    However, this constraint has been removed from the SysML 1.6 spec (and it is not included in the XMI).

    Issue SYSML16-310, which was merged into the resolution of SYSML16-274, addresses this constraint. In the comments on 310, Yves made a suggestion to remove the constraint, but then added a subsequent comment that reads: “Discussed during RTF weekly meeting on Sep 21: Ok for deleting the fits part of the sentence: "In the UML metamodel on which SysML is built" but any other change requires a separate issue” (SYSM16-310 - comment-17892, 21/Sep/17). There is also an earlier comment on the resolution to SYSML16-295 that notes “We had a discussion about constraint[3]. It seems the be not correct. Yves or Conrad will file an issue about that.” (SYSML16-295/SYSML16-297 - comment-17815, 31/Aug/17])

    But I cannot find any separate issue that was actually filed to remove constraint 3. The constraint was simply not included in the revised text in the resolution of SYSML16-274, and hence ended up being left out of the SysML 1.7 beta spec.

    So, there does not seem to be an apparent intent of the RTF to remove this constraint in SysML 1.6. Indeed, the following paragraph remains in the description section of subclause 8.3.2.3 Block in the 1.6 spec:

    “SysML excludes variations of associations in UML in which navigable ends can be owned directly by the association. In SysML, navigation is equivalent to a named property owned directly by a block. The only form of an association end that SysML allows an association to own directly is an unnamed end used to carry an inverse multiplicity of a reference property. This unnamed end provides a metamodel element to record an inverse multiplicity, to cover the specific case of a unidirectional reference that defines no named property for navigation in the inverse direction. SysML enforces its equivalence of navigation and ownership by means of constraints that the block stereotype enforces on the existing UML metamodel.”

    This is text certainly no longer true without constraint 3, and I would have expected it to have been removed or updated if there had actually been an affirmative resolution to remove the constraint.

  • Reported: SysML 1.6 — Thu, 11 Apr 2019 13:24 GMT
  • Updated: Mon, 16 Aug 2021 15:19 GMT


AcceptChangeStructuralFeatureEventAction

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The two pins are not named... so there is no standard way of defining which is the before pin and which is the after.... would suggest you standardize the names "before" and "after"

  • Reported: SysML 1.6 — Fri, 6 Aug 2021 00:24 GMT
  • Updated: Mon, 9 Aug 2021 14:57 GMT

Implementation of non-normative extensions cannot be used in other OMG specifications

  • Status: open   Implementation work Blocked
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    The extensions for SysML are of value to the general community, however, because they are not delivered in a machine readable and refrencable way, they cannot be used as a basis either for making normative to another specification and/or extended by another specification. There are issues as well for model interchange because of the lack of a normative form.

    It is suggested that SysML specification change the extensions to normative but optional profile and to further describe a compliance in which if the non-normative extensions are used, the whole profile shall be used and only changed by extension of that profile. There should also be recommendations for migrating from vendor implementation of extensions to the new normative version.

    The reason for this request is that the CubeSat System Reference Mode Profile (CSRM Profile)l used the non-normative extensions as a basis to further extend into the CubeSat domain. Unfortunately the use of the vendor supplied extensions were not from a compliant profile. The CSRM Profile team was forced to copy the extensions into the CSRM Profile in order to extend and use the extensions. This creates the danger that the CSRM Profile adds copies of the extension into a vendor's SysML implementation implementation and can cause interoperability issues.

    At this time, the CSRM Profile is pre-finalization and we could convert to a compliant version rather than the copy of the extensions we created. We would like this treated as a priority fix to allow for the creation of an XMI for refere3nce by our specification.

  • Reported: SysML 1.6 — Thu, 17 Jun 2021 13:30 GMT
  • Updated: Thu, 29 Jul 2021 16:09 GMT

move to SystemOfQuantities

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    this
    [1] The query accessibleQuantityKinds() gives all the QuantityKinds directly defined in the SystemOfQuantities or transitively in any included or used SystemOfQuantities.
    allAccessibleQuantityKinds() : QuantityKind[0..*]

    {unique}

    body: allAccessibleSystemOfQuantities()>collect(quantityKind)>flatten()->asSet() inv SoU3_3: getEffectiveSystemOfQuantities() = null or let aqk : Set(QuantityKind) = getEffectiveSystemOfQuantities().allQuantityKinds() in ->allUnits() ->forAll(u | aqk>includesAll (getKindOfQuantitiesForMeasurementUnit(u)))

    should be under SystemOfQuanties

  • Reported: SysML 1.6 — Tue, 20 Jul 2021 17:23 GMT
  • Updated: Wed, 21 Jul 2021 14:06 GMT

rename getKindOfQuantitiesForMeasurementUnit

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    getKindOfQuantitiesForMeasurementUnit should be renamed getQuantityKindsForMeasurementUnit

  • Reported: SysML 1.6 — Tue, 20 Jul 2021 17:11 GMT
  • Updated: Wed, 21 Jul 2021 14:05 GMT

OCL is not syntatically correct see ->allUnits()

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    inv SoU3_3: getEffectiveSystemOfQuantities() = null or let aqk : Set(QuantityKind) = getEffectiveSystemOfQuantities().allQuantityKinds() in ->allUnits() ->forAll(u | aqk>includesAll (getKindOfQuantitiesForMeasurementUnit(u)))

  • Reported: SysML 1.6 — Tue, 20 Jul 2021 16:13 GMT
  • Updated: Wed, 21 Jul 2021 14:05 GMT

wrongfully copied

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    this statement

    includedSystemOfUnits: SystemOfUnits[0..*] Including a SystemOfQuantities means including all of the QuantityKind it defines and includes from other SystemOfQuantities

    should reflect Units rather than SystemOfQuantities

  • Reported: SysML 1.6 — Mon, 19 Jul 2021 21:33 GMT
  • Updated: Tue, 20 Jul 2021 13:21 GMT

OCL with SpecializedQuantityKind needs to be changed

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    OCL with SpecializedQuantityKind needs to be changed

  • Reported: SysML 1.6 — Sun, 18 Jul 2021 16:15 GMT
  • Updated: Tue, 20 Jul 2021 13:20 GMT

ControlValue to ControlValueKind

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    UML::Behavior.allInstances()>forAll(b | not (ControlOperator.allInstances().base_Behavior>includes(b) xor b.ownedParameter >exists(p | p.type=SysML::Libraries::ControlValues::ControlValue))) and UML::Operation.allInstances()>forAll(o | not (ControlOperator.allInstances().base_Operation->includes(o) xor o.ownedParameter ->exists(p | p.type=SysML::Libraries::ControlValues::ControlValue)))

    TO

    UML::Behavior.allInstances()>forAll(b | not (ControlOperator.allInstances().base_Behavior>includes(b) xor b.ownedParameter >exists(p | p.type=SysML::Libraries::ControlValues::ControlValueKind))) and UML::Operation.allInstances()>forAll(o | not (ControlOperator.allInstances().base_Operation->includes(o) xor o.ownedParameter ->exists(p | p.type=SysML::Libraries::ControlValues::ControlValueKind)))

  • Reported: SysML 1.6 — Fri, 18 Jun 2021 13:02 GMT
  • Updated: Wed, 23 Jun 2021 15:43 GMT

Changes to Annex D sample problem figures may impact on some specification body figures

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Changes to Annex D sample problem model (since SysML1.6) may impact on some spec body figures. Possibly impacted diagrams include:

    Figure 8-12 - Block diagram for the Wheel Package (WheelHubAssembly)

    Figure 8-13: Internal Block Diagram for WheelHubAssembly

    Figure 8-15: Vehicle decomposition

    Figure 8-16: Vehicle internal structure (BoundReference example)

    Figure 8-17: Vehicle specialization

    Figure 9-6: Usage example of ports with provided and required features

    Figure 11-11: Continuous system example

    Figure 11-13: Example block definition diagram for activity decomposition

    Figure 11-14: Example block definition diagram for object node types

    Figure 15-9: Allocation Matrix showing Allocation for Hybrid SUV Accelerate Example

    Figure 16-2: Requirements Derivation

    Figure 16-3: Links between requirements and design

    Figure 16.4: Requirement satisfaction in an internal block diagram

    Figure 16-5: Use of the copy dependency to facilitate reuse

    Figure 16-6: Linkage of a Test Case to a requirement (and Figure 16-7)

    In some cases this may also impact text that refers to these examples.

  • Reported: SysML 1.6 — Thu, 17 Jun 2021 14:54 GMT
  • Updated: Thu, 17 Jun 2021 14:55 GMT

Need constraint for inverted provided/required Interfaces (InterfaceRealization and Usage) on ~InterfaceBlock

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    SysML-1.6 supports Interfaces provided/required (InterfaceRealization and Usage) by a Block, including an InterfaceBlock.

    Given that UML-style Port conjugation is not supported in SysML-1.6, a mechanism for inversion of provided/required Interfaces is needed.

    While Figure D.19 does not show the Port types, it does show provided/required Interfaces on Ports, and it is implied by other diagrams in the sample problem that those Ports that have inverted provided/required Interfaces are typed by ~InterfaceBlocks.

    A constraint should be added to 9.3.2.15 ~InterfaceBlock corresponding to the inversion of any required/provided Interfaces on the original InterfaceBlock.

  • Reported: SysML 1.6 — Fri, 3 Jul 2020 09:25 GMT
  • Updated: Thu, 17 Jun 2021 14:40 GMT

Constraint Typos

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    allAccessibleQuantityKinds() : QuantityKind[0..*]

    {unique}

    body: allAccessibleSystemOfQuantities()>collect(quantityKind)>flatten()->asSet() inv SoU3_3: getEffectiveSystemOfQuantities() = null or let aqk : Set(QuantityKind) = getEffectiveSystemOfQuantities().allQuantityKinds() in ->allUnits() ->forAll(u | aqk>includesAll (getKindOfQuantitiesForMeasurementUnit(u)))

    notice the "in ->allUnits()" ... something wrong here

  • Reported: SysML 1.6 — Tue, 20 Apr 2021 19:38 GMT
  • Updated: Fri, 30 Apr 2021 13:33 GMT

QUDV: Unknown property primaryQuantityKind

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The operation SystemOfUnits::isCoherent() and the figure E.8 uses a property "primaryQuantityKind" which is not defined in E.5.

  • Reported: SysML 1.6 — Tue, 20 Apr 2021 14:33 GMT
  • Updated: Thu, 29 Apr 2021 17:17 GMT

SysML model URI in the specification document

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Section §2 of the SysML specification should mention the URI of all the models (normative and non-normative) that are produced as part of a SysML version (i.e. those for which the URL is given on the front page)

  • Reported: SysML 1.6 — Thu, 29 Apr 2021 15:31 GMT
  • Updated: Thu, 29 Apr 2021 15:31 GMT

Suggest capability to list :features on Pin symbols and on elided Pin "ObjectNode" rectangle symbol

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    SysML already has the capability to list :features (such as :values, :operations etc.) in compartments on Property and Port symbols in IBDs.

    The same capability could be introduced for Pin symbols in Activity Diagrams to reveal :features of the types of Pins.

    UML2.5.1 describes also an elided Pin notation where a single rectangular "ObjectNode" symbol along with two arrows (not edges) represents two Pins of identical type and a single ObjectFlow edge (in the underlying model). This notation does not have good support in all tools. It could however also benefit from the ability to list :features on that "ObjectNode" symbol (where the type is the type of the 2 Pins it actually represents).

  • Reported: SysML 1.6 — Wed, 21 Apr 2021 03:41 GMT
  • Updated: Wed, 21 Apr 2021 16:28 GMT

Suggest capability to list :features on ItemFlows in a rectangle symbol over a Connector or Association line

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    This ticket is a re-imagining of (partial resurrection of) a proposal from Michael Chonoles that I strongly supported:

    https://issues.omg.org/browse/SYSML17-103

    https://issues.omg.org/browse/SYSML17-208

    If the RTF chairs truly consider any new features out-of-scope this can be bumped to SysMLv2, but as Conrad wrote under SYSML17-208:

    I think SysML 1.x should address this. It will be a long time before SysML2 is a finalized OMG spec. We should be supporting modelers in the meantime with small upgrades like this.


    SysML already has the capability to list :features (such as :values, :operations etc.) in compartments on Property and Port symbols in IBDs. Indeed, this notation has proved one of the most popular advantages of SysML over UML.

    The same capability could be introduced for ItemFlows, which could be extended to optionally support representation as a rectangle symbol on Connectors lines and Associations lines (or wherever ItemFlows may be shown), with compartments for listing :features.

    In the case where the ItemFlow does not have an itemProperty, the rectangle could appear much like a Block symbol (but over a relevant line).

    In the case where the ItemFlow has an itemProperty, the rectangle could appear much like a Property symbol (but over a relevant line).

    In both cases the header of the rectangle could show the direction arrow for the ItemFlow.

    In both cases the ability to display defaults for value properties would be extremely useful.

    (Variations on the notation would have to cope with situations where there is more than one applied ItemFlow.)

  • Reported: SysML 1.6 — Wed, 21 Apr 2021 04:11 GMT
  • Updated: Wed, 21 Apr 2021 04:12 GMT

Suggest introduce strict diagram policy: avoid "elided Pin" ObjectNode notation in Activity Diagrams in all revised and future specification figures

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    I suggest that diagram submitters never ever again use the infamous "elided Pin notation" for ObjectNode anywhere in the spec, as it is widely misunderstood and the tool support for it is poor (broken).

    This concerns not only the Annex D sample problem, but all other Activity Diagrams in all figures in the spec.

    The problematic "elided Pin" notation as described in UML-2.5.1 :

    'An object flow is notated by an arrowed line. In Figure 15.9, upper right, the two object flow arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure.'

    The relevant UML-2.5.1 Figure 15.9 ObjectFlow notations is attached.

    Please note how it describes the notation as two object flow arrows (notational symbols that do not correspond one-to-one to ActivityEdge elements, but rather to one ObjectFlow edge). Note also how it says there are two Pins in the underlying model.

    At least one tool implements this notation incorrectly and uses 2 ObjectFlows and a CentralBufferNode instead of two arrows and a rectangular symbol representing any ObjectNode sub-type.

    I appreciate the OMG JIRA is not intended for personal remarks, but I can't begin to explain how much time wrangling with broken "elided Pin" ObjectNode notation in one tool has cost me, time which could be better used contributing to the specification. I ask you all to please vote yes for this in a ballot soon so that I can contribute more.

    DK

  • Reported: SysML 1.6 — Wed, 1 Jul 2020 11:31 GMT
  • Updated: Wed, 21 Apr 2021 03:47 GMT
  • Attachments:

Body conditions of operation in QUDV model should be Boolean expressions

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The body conditions of the QUDV operations in section E.5.2 are not specified as Boolean expressions. They specify only the computation of the return value.

    If the return parameter is named "result" they should be stated as

    result = <computation of return value>

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 06:36 GMT
  • Updated: Mon, 19 Apr 2021 06:36 GMT

QUDV::PrefixedUnit: Redefinition of quantityKind

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    QUDV::PrefixedUnit redefines quantityKind to set the multiplicity to 0:

    noQuantityKind : QuantityKind [0]

    It would be better to define a constraint instead:
    self.quantityKind = null

    The property noQuantityKind is specified in the XMI, but not mentioned in the PDF.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 05:42 GMT
  • Updated: Mon, 19 Apr 2021 05:42 GMT

Issues in figure E-7

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Figure E-7: QUDV QuantityKinds has the following issues:

    • Should be a bdd instead of pkg
    • Remove diagram number and icon from header
    • Remove owner from blocks
    • Association between Dimension and SystemOfQuantities: Multiplicity end systemOfQuantities is 1..* in SysML 1.6 and 0..* in SysML 1.5. There is no documented change between SysML 1.5 and SysML 1.6.
    • Association between QuantityKind and QuantityKindFactor: Multiplicity end quantityKind is 1 in SysML 1.6 and 0..* in SysML 1.5. There is no documented change between SysML 1.5 and SysML 1.6.
    • Association between DerivedQuantityKind and QuantityKindFactor: Multiplicity end DerivedQuantityKind is 1 in SysML 1.6 and 0..* in SysML 1.5. There is no documented change between SysML 1.5 and SysML 1.6.
  • Reported: SysML 1.6 — Sat, 17 Apr 2021 18:14 GMT
  • Updated: Sat, 17 Apr 2021 18:14 GMT

7_composition_acyclic wrong

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    I agree with this that this should be the intent... "Within an instance of a SysML Block, the instances of properties with composite aggregation shall form an acyclic graph"... but I believe the OCL statement restricts the types and not the instances... I will give an example... it should restrict an instance from being a part of itself... but is should not restrict a Type having a part of the same type (which I believe this does)... take for example something that says System has a composition to itself whose navigation end is named "subSystem"... this says that a System can contain other Systems as a part "subsystem"... this should be legal... but a system1:System cannot contain itself as a subsystem of itself... that should be illegal... I believe that your constraint, constrains the Type (which it should not) and therefore the instance... but it should only constrain the instance and not the type...

  • Reported: SysML 1.6 — Sat, 27 Mar 2021 13:33 GMT
  • Updated: Thu, 1 Apr 2021 17:19 GMT

If there is no «port» keyword in UML-2.5.1 or SysML-1.6 it should be removed from Figure 9-8

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    If there is no «port» keyword in UML-2.5.1 or SysML-1.6 it should be removed from Figure 9-8: Water Delivery association block

    Although it is explained in the text, I have had many clients and training customer unnecessarily imitate it.

    It [EDIT: the «port» keyword] is introduced in Figure 9-8, and then never used in any of diagrams that follow.

    If it must stay, it should be made clear that it is a user-defined stereotype keyword.

    BTW: I address this in my own models by using conventions for Port type naming: I_Contract, F_FlowStuff etc.

  • Reported: SysML 1.6 — Mon, 29 Jun 2020 07:45 GMT
  • Updated: Tue, 16 Mar 2021 07:50 GMT

orderedMember in ElementGroup should be {ordered}

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    orderedMember in ElementGroup should be

    {ordered}
  • Reported: SysML 1.6 — Wed, 24 Feb 2021 14:05 GMT
  • Updated: Mon, 1 Mar 2021 11:27 GMT

AbstractRequirement needs to be consistent

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The pattern used through out the standard is with an Association End so Attribute base_NamedElement should be an association end and not an attribute

  • Reported: SysML 1.6 — Wed, 24 Feb 2021 15:22 GMT
  • Updated: Wed, 24 Feb 2021 17:20 GMT

Description for getSatisfies

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The Description for getSatisfies should be similar to that of getVerifies

    The query getSatisfies() gives all the requirements that are suppliers ( "to" end of the concrete syntax ) of a «Satisfy» relationships whose client is the element in parameter. This is a static query.

  • Reported: SysML 1.6 — Wed, 24 Feb 2021 15:04 GMT
  • Updated: Wed, 24 Feb 2021 15:15 GMT

Parameter names mismatch in ~InterfaceBlock::areConjugated(Property, Property)

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The parameter names in the signature of that operation are "p1" and "p2" respectively while "a1" and "a2" are used in the statement of the body condition

  • Reported: SysML 1.6 — Mon, 22 Feb 2021 09:58 GMT
  • Updated: Mon, 22 Feb 2021 09:58 GMT

Suggest introduce an operation to obtain the magnitude of a value property in a given compatible Unit (to afford equality comparison)

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Spawned from SYSML17-31 to help support comparisons for BindingConnector.

    Suggest introduce an operation to obtain the magnitude of a value property in a given compatible Unit (to afford equality comparison)

    A compatible Unit is any Unit that has the same fundamental Dimensions as the Unit of the value property for which the magnitude is to be obtained. It need not be (but typically would be) from the same Unit system.

    [EDIT: See attached Wolfram Mathematica example with CompatibleUnitQ example]

    Equality of values of value properties at the ends of a BindingConnector can be compared via the proposed operation:

    • The case where the two value properties have the same Unit from the same system is trivial.
    • In the case where the two value properties have compatible Units (same fundamental Dimensions) from the same system but different scaling factors (say g vs kg), a simple scaling must be performed.
    • In the case where the two value properties have compatible Units (same fundamental Dimensions) from different systems (say ft vs km), a conversion and possibly also a scaling must be performed.

    This proposal does not restrict tools to use any particular choice of Unit when performing equality comparisons.

    This proposal specifically only supports comparison of values of value properties with compatible fundamental Dimensions, but does not involve quantity kind.

  • Reported: SysML 1.6 — Thu, 14 Jan 2021 22:25 GMT
  • Updated: Fri, 15 Jan 2021 06:29 GMT
  • Attachments:

Taken literally the text and OCL of constraint '6_valueproperties_composite' imply that every FlowProperty typed by a ValueType should have AggregationKind 'composite'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Although the name of the constraint 6_valueproperties_composite suggests it is only intended for value properties, the text and OCL of the constraint imply that a FlowProperty typed by a ValueType should also have AggregationKind composite:

    ‘If a property owned by a SysML Block or SysML ValueType is typed by a SysML ValueType, then the aggregation attribute of the property shall be "composite."’

    self.base_Class.ownedAttribute->select(a| ValueType.allInstances().base_DataType ->includes(a.type))->forAll(a|a.isComposite())
    

    Note also that the following specification text on p.53 under 8.3.2.4 Block if taken literally would mean that any FlowProperty typed by a ValueType is a value property:

    'A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation.'

  • Reported: SysML 1.6 — Thu, 14 Jan 2021 01:58 GMT
  • Updated: Thu, 14 Jan 2021 21:38 GMT

Property types 'Four general categories of properties of blocks are recognized in SysML ...' does not cover FlowProperty

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    From SysML-1.6 8.3.1.2.1 Property types p.43 :

    'Four general categories of properties of blocks are recognized in SysML: parts, references, value properties, and constraint properties. (See 8.3.2.4 for definitions of these property types.)'

    Elsewhere 'parts' and 'references' are described as being typed by Blocks, but a FlowProperty typed by a Block is not typically listed in the corresponding compartments.

    A FlowProperty need not be typed by a ValueType, and is not typically understood to be a value property so is not covered by 'value properties' (see however SYSML17-399).

    The same issue arises on p.53 under 8.3.2.4 Block:

    SysML establishes four basic classifications of properties belonging to a SysML Block or ValueType. A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. Constraint properties are further defined in Clause 10. A port is another category of property, as further defined in Section 9. A property typed by a Block that does not have composite aggregation is classified as a reference property. A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. Part, reference, value, and constraint properties may be shown in block definition compartments with the labels "parts," "references," "values," and "constraints" respectively. Properties of any type may be shown in a "properties" compartment or in additional compartments with user-defined labels.

    Because FlowProperty can be typed by ValueType, Block or Signal it is not covered well by the above; every attempt to handle the cases applied to any of the above results in "definition whack-a-mole"

  • Reported: SysML 1.6 — Thu, 14 Jan 2021 06:34 GMT
  • Updated: Thu, 14 Jan 2021 06:34 GMT

InterfaceBlock: OCL constraint 2_no_part is missing FlowProperty check for cases where a FlowProperty is not typed by a ValueType

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.99

    2_no_part

    Interface blocks composite properties are either ports, value properties or flow properties.

    self.base_Class.ownedAttribute->select(a|a.isComposite)->forAll(a |
    a.oclIsKindOf(UML::Port) or a.oclIsKindOf(ValueType))

    EDIT: Needs to also check whether is a FlowProperty of a valid type other than ValueType, noting from SysML-1.6 FlowProperty:

    '1_restricted_types A FlowProperty shall be typed by a ValueType, Block, or Signal.'

  • Reported: SysML 1.6 — Sat, 4 Jul 2020 14:50 GMT
  • Updated: Thu, 14 Jan 2021 06:05 GMT

Compartments for Connectors and Participants

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The Standard is not clear about compartments for Connectors and Participants... it is presumed that since Connectors has a OwnedConnectors in the metamodel in UML... that a "connectors" compartment is implied (but the standard should probably state as much to make sure tools are consistent)... there could also be a <<connector>> compartment according to the standard... so this needs to be consistent... there is nothing about Participants... so presumably they go into "properties" compartment... or a <<participants>> compartment... they are could be references (because they are composite) but one may not want to mix them in with references (I would not want to, but the standard may want to grant a compartment called "participants" for the purpose)

  • Reported: SysML 1.6 — Sat, 31 Oct 2020 16:26 GMT
  • Updated: Tue, 17 Nov 2020 16:50 GMT

Suggest not allow an AssociationBlock to type a BindingConnector used for pure proxying

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    This issue report illustrates two separate (but apparently related) issues:

    DISCLAIMER: The example shown for modelling an electronics jack or socket in electronics is not an approach advocated by this reporter. It is however a frequently used or attempted approach.

    Primary issue: When a BindingConnector used to indicate pure proxying is typed by an AssociationBlock, the AssociationBlock can be used to undermine the claimed equality of the proxy, at least when nested Ports are involved.

    In the attached example, the L and R channels of a stereo system have been swapped by the AssociationBlock (which swapping is invisible at the level of the BindingConnector it types).

    It is proposed that constraint(s) be introduced for BindingConnector and/or AssociationBlocks, along with improved explanations for ParticipantProperty, to prevent the typing of BindingConnectors by AssociationBlocks used for pure proxying.

    (AssociationBlocks are otherwise very useful, it is not suggested here that their use should be otherwise prevented.)

    A 2nd issue was identified by John Brush of 7Sigma. In the situation as modelled, tools report that the innermost BindingConnectors (owned by the AssociationBlock) between the nested Ports have invalid flow directions.

    That issue can be avoided by instead using a non-behavioral Port or a FullPort with additional inner-facing nested Ports to model the jack/socket, however that 2nd issue may be a valid concern for some other modelling cases.

  • Reported: SysML 1.6 — Tue, 10 Nov 2020 02:32 GMT
  • Updated: Tue, 10 Nov 2020 02:44 GMT

All kinds of errors in Fig. 8-17

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    1. Vehicle should have a compartment labeled "bound references" rather than just "references"
    2. According to constraint 7 in BoundReference
    "BoundReferences shall not be applied to properties that are related by redefinition to other properties with BoundReference applied"
    so Vehicle Model 2 should not have <<boundReference>>, endPathMultiplicity is ok... but should have lower and upper defined for the example
    3. This diagram should be an example of how multiplicity on the property and lower and upper can differ

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 13:36 GMT
  • Updated: Sat, 7 Nov 2020 00:45 GMT
  • Attachments:

Figure 8-17: Vehicle specialization: multiple inconsistencies

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    From SysML-1.6:

    'The specialization on the lower left restricts the number of cylinders to four, requires a light roll bar, and a total of 24 lug bolts over all the wheels. '

    In block Vehicle Model 1:

    • The multiplicity of cylinderBR should be [4] not [*]
    • Multiplicity of rollBarBR should be [1] not [*] and it has no redefined type for the 'light roll bar' (it would also help if the parent block Vehicle and the sub-blocks all showed the types on their properties).
    • Multiplicity of lugBoltBR in the spec figure is [6..8], it should be [6]

    'The specialization on the lower right restricts the number of cylinders to between six and eight, rules out any roll bar, and limits lug bolts per wheel to between 6 and 7, by giving the end path upper and lower values.'

    In block Vehicle Model 1:

    • Multiplicity of rollBarBR should be [0] not [*]
    • EndPathMultiplicity is applied to rollBarBR instead of lugBoltBR
    • It's also not entirely clear (to me) whether the multiplicity of lugBoltBR should be [*].

    The annotated attachment shows an attempt at improving it (but is not offered as a resolution figure).

  • Reported: SysML 1.6 — Sun, 28 Jun 2020 13:55 GMT
  • Updated: Sat, 7 Nov 2020 00:37 GMT
  • Attachments:

constraint needed

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    perhaps a specification is needed that says that lower and upper are the same as lower and upper of the multiplicity if they are not specified or not initialized... that way, if tools are asking what is lower and upper they will get something relevant

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 13:42 GMT
  • Updated: Wed, 28 Oct 2020 16:29 GMT

Relationship should be specified for Stakeholder to a View

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:
    • How do you tie a view to a stakeholder, should specify a type of relationship
  • Reported: SysML 1.6 — Tue, 27 Oct 2020 19:17 GMT
  • Updated: Wed, 28 Oct 2020 16:26 GMT

Adjunct allows for additional notation on CallBehaviorActions

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Currently with CallBehaviorActions there is no way to specify that there are only so many instance that can be executed if one has an instance of an Activity... if that action is marked as isReentrant=true.. but with adjuncts one can specify that an adjunct property has multiplicity (which restricts min/max number of instances)... it would be nice if that could also be shown on an Activity diagram by allowing multiplicities in the upper right corner of an appropriate Action that specifies these multiplicities

  • Reported: SysML 1.6 — Mon, 26 Oct 2020 21:18 GMT
  • Updated: Tue, 27 Oct 2020 19:39 GMT

What are redefined BoundReferences

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    What compartment does a property go into that redefines a BoundReference... note that such a property can not be stereotyped as BoundReference so presumably, it can not go into that compartment... so is it a reference? (but it does not fit the definition because it is not the end of an association)... there is just the properties compartment...

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 18:57 GMT
  • Updated: Tue, 27 Oct 2020 19:39 GMT

EndPathMultiplicity and BoundReference Ordered and Unique

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    BoundReference is ordered and nonunique... this is not the default and should be shown in the diagrams...
    Since EndPathMultiplicity is a redefine of BoundReference if it is applied by itself... then each
    EndPathMultiplicity has to also be ordered and nonunique... this should be explained... and should be a constraint in EndPathMultiplicity

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 15:07 GMT
  • Updated: Tue, 27 Oct 2020 19:38 GMT

Lower and Upper Explained

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    I believe the reason Lower and Upper were added into the standard was to allow for multiplicities that did not follow the multiplicity rules of the standard... I have an example... and I think an example should be in the standard to clarify this mystifying need for lower and upper... because it is not clear really why they are needed...

    suppose I have the following
    part1[3..4]
    part2[3..7]
    part3[4..6]

    and I want to bind a BoundReferece x to part1.part2.part3 in block y... now I can take several approaches...
    1. <<boundReference>> x:Part3 [*[ - this removes the double maintenance problem when multiplicities of the paths change does not restrict anything
    2. <<boundReference>> x:Part3 [36..168] - this mimics the multiplicities of the path, so really no restriction
    3. <<boundReference>> x:Part3 [2..10] - this restricts the number of part3s that there can be at the end of that path

    option 3 could have also been specified as
    <<boundReference>> x:Part3 [*]

    {lower=2,upper=10}

    now block z specializes block x and I have another property a such that
    <<endPathMultiplicity>> a:Part3[*[

    {redefines x,lower=5,upper=20}

    but this only works if x has multiplicity * otherwise
    <<endPathMultiplicity>> a:Part3 [5..20[

    {redefines x}

    if x is <<boundReference>> x:Part3 [2..10] does not work
    because 5..20 is not a restriction of 2..10

    This is why lower and upper can be different (but constrained by) the multiplicity

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 14:00 GMT
  • Updated: Tue, 27 Oct 2020 19:38 GMT

Lower and Upper are constrained

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    There should be a constraint in EndPathMultiplicity which states that Lower is no less than the lower on the multiplicity and that upper is no greater than the upper on the multiplicity

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 13:38 GMT
  • Updated: Tue, 27 Oct 2020 19:37 GMT

Statement about EndPathMultiplicity

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    constraint 1 in EndPathMultipliticity
    "Properties to which EndPathMultiplicity is applied shall be related by redefinition to a property to which BoundReference is applied."
    and constraint 7 in BoundReference says
    "BoundReferences shall not be applied to properties that are related by redefinition to other properties with BoundReference applied"

    so if there is a endPathMultiplicity applied... it must be to a property, not a BoundReference, but to one redefining a boundReference
    ... this should be explicitly stated in the standard... otherwise it is not obvious

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 13:29 GMT
  • Updated: Tue, 27 Oct 2020 19:36 GMT

BoundReference Specificity

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    A BoundReferrence must be more general in multiplicity than the property it binds to... but there is nothing in the constraints that specify this... the lower and upper limit the number in that specific Type

    Also, the best practice for BoundReference is to make its multiplicity * so there is not the double maintenance issue if any multiplicity changes along the path it is bound to... this should be specified

    Also, specify that lower, upper of BoundReference restricts the multiplicity of the property it is bound to... and there should be example showing how the multiplicity of BoundReference can be different than the values of lower,upper and why

    also, the statement "Properties to which BoundReference is applied shall be the role of a connector end of at least one binding connector, or generalized by such a property through redefinition" especially "or generalized by such a property through redefinition" is not clear as to what is being generalized

    also, an example of when nonuniqueness would come into play would be good in the standard

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 13:26 GMT
  • Updated: Tue, 27 Oct 2020 19:36 GMT

BoundReference Diagram is wrong

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Block1 should have two compartments one reference and one bound reference (for property11)... property11 in Block2 is not correct as a redefine because it widens rather than restricts the multiplicity of property11 in Block1...property11 in block1 would need to have a multiplicity of *

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 13:12 GMT
  • Updated: Tue, 27 Oct 2020 19:35 GMT

Unclear English Statement

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The OCL is probably clear but the English is not...

    4_same_owner
    Properties with AdjunctProperty applied shall be owned by an element that owns the principal, at least indirectly, or one of that elements specializations.

    could be read as "Properties with AdjunctProperty applied shall be owned by a specialization of the element that owns the principal"

    or "Properties with AdjunctProperty applied shall be owned by an element whose specialization owns the principal"

  • Reported: SysML 1.6 — Thu, 1 Oct 2020 23:37 GMT
  • Updated: Tue, 27 Oct 2020 19:30 GMT

Make Annex E Optional but Normative

  • Status: open  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

    Currently Annex E of the SysML spec is called "Non-Normative Extensions" and marked "Informative". However, the content of Annex E is widely implemented and used, and recently also referred to by other submissions as normative reference. It would therefore make much sense to make the Annex E normative, but optional (via a Compliance clause). This would still leave implementers the freedom to implement Annex E, or to ignore it. However, if implemented, then it must precisely follow the specification. This would improve interoperability and exchangeability of the Annex E items, and would make the content of Annex E referable by other submission.

    To achieve this change, the Annex E title and Overview sub-clause need to be changed, and an additional bullet point inserted into Clause 5.2:

    "Optional extension conformance. A tool may implement the specifications of Annex E in its entirety, or implement selected specifications from Annex E at the discretion of the tool implementer. If so, then any implementation must follow the specifications provided by Annex E exactly."

  • Reported: SysML 1.6 — Tue, 29 Sep 2020 23:10 GMT
  • Updated: Thu, 8 Oct 2020 00:44 GMT

Figure E.6 QUDV Units Diagram display exactly the same content as Figure E.5 QUDV Concepts Diagram

  • Status: open  
  • Source: KARL STORZ SE & Co. KG ( Marting Bohring)
  • Summary:

    In Version SysML 1.5 the QUDV Units diagram presented the other Unit Types. In Version SysML 1.6 the Units Diagram displays the same content as the Concepts Diagram.
    AS a result the Units Diagram of SysML Version 1.5 has disappeared

  • Reported: SysML 1.6 — Wed, 15 Jul 2020 11:50 GMT
  • Updated: Tue, 21 Jul 2020 20:50 GMT

The 'initialValues' compartment needs to be renamed 'contextValues' and they need to be referred to as 'context-specific values'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    I have never liked the term 'initial values' or the compartment name 'initialValues' for what were originally called 'context-specific values'.

    I propose instead they be called 'context-specific values' because that is what they in fact are (values within the context of a top-level configuration block), and a compartment 'contextValues'.

    In most cases the values as used have nothing to do with "initial". Even the spec example Figure D.41 has nothing to do with initial, it is about a test configuration.

    I helped supervise development and testing of this feature many years ago in the MagicDraw tool (along with Nerijus at No Magic). It was the first tool to implement the feature. Back then we referred to the feature as context-specific values (and it used to be called that in the tool menu).

    I have been using this feature a lot for some years with real world clients. Nearly all of them find the term 'initialValues' completely confusing, especially after just having been introduced to the 'defaultValue' concept.

    Case: Am using SysML for a construction group. They use initialValues to describe multiple "deep" configurations of buildings in different modes and customer configurations. They find the term initialValues completely confusing.

    Case: The mobile phone initialValues sample available for MagicDraw/Cameo is in fact a "deep" configuration example (and an excellent one) and has nothing to do with "initial values".

    I also have a course session dedicated to how to use this feature for "deep" configuration of systems. Attendees find the term 'initialValues' completely confusing, I tell them to call it 'contextValues' instead.

    And as for time? If you want to use the feature to show the value state of a system at different times: t0, t1, t2, t3 in different block contexts you can't; because the compartment name 'initialValues' makes it sound like every time slice is the initial time t0.

    It truly has to go. It does not work. The compartment name 'contextValues' works for all cases.

    I have even taken to "painting over" the term 'initialValues' in some diagrams.

    This SysML feature/capability itself is extremely important and useful; it's an absolutely critical extension over UML.

  • Reported: SysML 1.6 — Sun, 28 Jun 2020 00:41 GMT
  • Updated: Mon, 6 Jul 2020 17:11 GMT

Suggest primary/replica as alternative to master/slave terminology for Copy relationship

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Suggest primary/replica as alternative to master/slave terminology for Copy relationship.

    The term 'slave' appears on p.181:

    The use of namespace containment to specify requirements hierarchies precludes reusing requirements in different contexts since a given model element can only exist in one namespace. Since the concept of requirements reuse is very important in many applications, SysML introduces the concept of a slave requirement. A slave requirement is a requirement whose text property is a read-only copy of the text property of a master requirement. The text property of the slave requirement is constrained to be the same as the text property of the related master requirement. The master/slave relationship is indicated by the use of the copy relationship.

    And p.188:

    getMaster () : AbstractRequirement [0..*]
    bodyCondition: Copy.allInstances()->select(base_Abstraction.client=self).base_Abstraction.supplier

    p.189

    A Copy dependency created between two requirements maintains a master/slave relationship between the two elements for the purpose of requirements re-use in different contexts.

    The change would also require changing all references to '/master' to '/primary'.

    In 2014 Drupal CMS adopted the term primary/replica.

    The terminology master/slave has recently been removed from the Python language.

    There are some other options recently adopted by technology companies, but they do not play as nicely with the Copy relationship as 'primary/replica'.

  • Reported: SysML 1.6 — Mon, 6 Jul 2020 09:24 GMT
  • Updated: Mon, 6 Jul 2020 09:24 GMT

SysML-1.6: Refers to both 'composite requirement' and 'compound requirement'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.181

    16.1 Overview
    ...
    A composite requirement can contain subrequirements in terms of a requirements hierarchy, specified using the UML namespace containment mechanism. This relationship enables a complex requirement to be decomposed into its containing child requirements. A composite requirement ..

    p.191

    16.3.2.5 Requirement
    ...

    Compound requirements can be created by using the nesting capability of the class definition mechanism. The default interpretation of a compound requirement, unless stated differently by the compound requirement itself, is that all its subrequirements shall be satisfied for the compound requirement to be satisfied.
    ...

    Might be best to choose just one term 'compound requirement' or 'composite requirement

  • Reported: SysML 1.6 — Sun, 5 Jul 2020 14:00 GMT
  • Updated: Sun, 5 Jul 2020 14:01 GMT

BindingConnector constraint 1_compatible_types: Use of OCL conformsTo contradicts definition of compatibility of connected ProxyPort, does not admit per Feature compatibility or compatibility via a union of connected features

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    EDIT: from SysML-1.6 p.52:

    A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values.'

    SysML-1.6 p.52 states:

    1_compatible_types

    The two ends of a binding connector shall have either the same type or types that are compatible so that equality of their values can be defined.

    self.base_Connector.end->at(1).role.type.conformsTo(self.base_Connector.end
     ->at(2).role.type) or self.base_Connector.end
     ->at(2).role.type.conformsTo(self.base_Connector.end->at(1).role.type)
    

    OCL-1.4 states concerning conformsTo:

    8.2.1 Type Conformance

    The type conformance rules are formally underpinned in the Semantics sub clause of the specification. To ensure that the rules are accessible to UML modelers they are specified in this sub clause using OCL. For this, the additional operation conformsTo(c : Classifier) : Boolean is defined on Classifier. It evaluates to true, if the self Classifier conforms to the
    argument c.

    ...

    [2] Classes conform to superclasses and interfaces that they realize.
    context Class
    inv : self.generalization.general->forAll (p |
    (p.oclIsKindOf(Class) or p.oclIsKindOf(Interface)) implies
    self.conformsTo(p.oclAsType(Classifier)))
    

    As far as this submitter can tell, there is no sense in which OCL conformsTo is not Type-based at the level of a Classifier.

    This renders numerous desirable ProxyPort connection scenarios invalid.

    Case: A ProxyPort of InterfaceBlock type PP1 and an internal part property of block type Standalone, where PP1 and StandalonePart have identical Feature signatures, but do not share a Type relationship.

    From SysML-1.6 p.52:

    9.3.2.13 ProxyPort

    ...

    When a proxy port is connected to a single internal part, the connector shall be a binding connector, or have the same semantics as a binding connector (the value of the proxy port and the connected internal part are the same; links of associations typing the connector are between all objects and themselves, and no others).

    Whether one uses a BindingConnector or a Connector with the same semantics, the reported constraint renders the Connection from proxy port :PP1 to internal part :Standalone invalid, even though all Features match, because there is no type "value" equivalence.

    Consider now from p.103:

    When a proxy port is connected to multiple internal parts, the connectors have the same semantics as a single binding connector to an aggregate of those parts, supporting all their features, and treating flows and invocations from outside the aggregate as if they were to those parts, and flows and invocations it receives from those parts as if they were to the outside.

    ASIDE: The spec could make clearer in the above whether the Connectors that are used for such multiple connections are NOT BindingConnectors

    An attempt to work around it using multiple Connectors from the proxy port :PP1 to at least all of the Property features of internal part :Standalone - which are themselves 'parts' in the UML sense - also leads to a contradiction w.r.t:

    the connectors have the same semantics as a single binding connector to an aggregate of those parts, supporting all their features ..

    The attempt was to aggregate the Property features themselves, not their features.

    And even if the above were to work, it does not address the compatibility with Operations, and is also highly impractical in tools when there are many Properties to bind (collect).

    The complexity and number of possible contradictions explodes when indeed connections are made to multiple parts.

    What is needed is a completely different definition of compatibility that is not bound in any way to types, but primarily to matching Features (including Operations, Receptions and Properties) by "collecting" the Features via Connectors to their owners.

    This would then support common engineering scenarios where subsets of Features of internal parts are aggregated and then "exported" via a single exposed Port.

    This would greatly reduce the number of Connectors needed, and would make validation in tools much easier. Type-based compatibility can still be kept, but it is just a special case of Feature-wise compatibility.

    The Property features of internal part :Standalone clearly count as 'multiple internal parts'. Assuming regular Connectors are used (but not BindingConnectors) from proxy port :PP1 to every Property of internal part :Standalone

  • Reported: SysML 1.6 — Sun, 5 Jul 2020 09:28 GMT
  • Updated: Sun, 5 Jul 2020 11:34 GMT

9.3.2.13 ProxyPort 'When a proxy port is connected to a single internal part ...' extend to include ' or port on an internal part'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.103

    Proxy ports can be connected to internal parts or ports on internal parts, identifying features on those parts or ports that are available to external blocks.

    And:

    When a proxy port is connected to a single internal part, the connector shall be a binding connector, or have the same semantics as a binding connector ...

    The 2nd sentence would more consistent if it included ' or port on an internal part' thus:

    When a proxy port is connected to a single internal part or port on an internal part, the connector shall be a binding connector, or have the same semantics as a binding connector ...

  • Reported: SysML 1.6 — Sun, 5 Jul 2020 08:45 GMT
  • Updated: Sun, 5 Jul 2020 08:45 GMT

SysML-1.6: text on Requirement 'Test and procedure conditions' is mangled in 'Figure 16-2: Requirements Derivation' (was OK in SysML-1.5) [also affects Figure 16-6]

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Figure 16-2: Requirements Derivation

    In SysML-1.5 Requirement text was:

    (a) IBT: <= 65 °C (149 °F), <= 100 °C (212 °F). (b) Test surface: PFC of at least 0.9.

    In SysML-1.6 p.195 Requirement text does not have comparison operators.

    Tested in Adobe Reader and Mac Preview on a Mac.

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 08:54 GMT
  • Updated: Thu, 2 Jul 2020 13:16 GMT
  • Attachments:

'Figure 16-2: Requirements Derivation' indeed shows DeriveReqt but spec text refers to it as 'an example of a compound requirement'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.195

    SysML-1.6: Figure 16-2: Requirements Derivation indeed shows DeriveReqt examples, but the spec text refers to it as 'an example of a compound requirement'.

    Either: The spec text needs to say is also an example of DeriveReqt

    Or: The figure needs to be renamed to something like: Figure 16-2: Requirements Derivation and compound requirements

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 09:05 GMT
  • Updated: Thu, 2 Jul 2020 13:15 GMT

'Figure 9-6: Usage example of ports with provided and required features' does not expose any directed features

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    All the diagram shows is some port types and their conjugated types.

    It would be more instructive if the ports on the diagram used the capability to show the underlying directed features of the blocks that type the ports.

  • Reported: SysML 1.6 — Mon, 29 Jun 2020 05:54 GMT
  • Updated: Thu, 2 Jul 2020 13:04 GMT

SysML-1.6 does not leverage redefinition of 'sp:Surface' on 'Figure 9-7: Usage example of proxy and full ports'. And does not show direction of flows on Ports symbols

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    SysML-1.6 spec figure 'Figure 9.7 - Usage example of proxy and full ports'.

    Does not leverage redefinition of sp:Surface, which is shown as redefined in many blocks but nothing is actually redefined.

    Some earlier spec versions did leverage the redefinition, see also the attachment for similar done in a tool.

    Also, it does not show direction of flows on the ports (but this notation is optional).

  • Reported: SysML 1.6 — Mon, 29 Jun 2020 06:36 GMT
  • Updated: Thu, 2 Jul 2020 13:04 GMT

Figure 9-16 and Figure 9-17 'Usage example of item flow decomposition': multiple inconsistencies

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.115:

    Figures 9.16 and 9.17 are examples of item flow decomposition that modelers might choose...

    Should be 'Figures 9-16 and 9-17'

    p.115:

    In Figure 9-16, the item flow classifier (EnginePart) is a supertype of the classifiers of the item flows in the decomposition. The flow properties are all in the types of the nested ports ...

    But it does not show those flow properties in the lower BDD (compare with attachment 1).

    It would make sense to show the flow property direction indicators in the structure compartment of A1 in the lower BDD.

    Minor/optional: If the parent ports do not have any flow properties in this example, it might be better to not show the flow direction indicator in the parent port in Figure 9-16, even though the flow direction for each nested port within each parent port is in the same direction. Then, for contrast, the flow direction indicators can be shown on the parent ports of Figure 9-17, noting they have explicit flow properties.

    p.115 and p.116:

    In Figure 9-17, the item flow classifier (Engine) composes the classifiers of the items flows in the decomposition from Figure 9-17.

    This should probably be 'from Figure 9-16'.

  • Reported: SysML 1.6 — Tue, 30 Jun 2020 00:29 GMT
  • Updated: Thu, 2 Jul 2020 13:04 GMT

The ControlValue input to Monitor Traction without a Pin is invalid in 'Figure 11-10: Continuous system example 1' and multiple issues with ControlOperator

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.147 Figure 11-10: Continuous system example 1 shows an object flow with an object token of type ControlValue (should probably be ControlValueKind) from a ControlOperator Enable on Brake Pressure > 0 to Monitor Traction.

    The notation shown is consistent with UML-2.5.1 "elided Pin" notation:

    'An object flow is notated by an arrowed line. In Figure 15.9, upper right, the two object flow arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure.'

    The relevant UML-2.5.1 Figure 15.9 ObjectFlow notations is attached.

    Please note how it describes the notation as two object flow arrows (notational symbols that do not correspond one-to-one to ActivityEdge elements, but rather to one ObjectFlow edge). Note also how it says there are two Pins in the underlying model.

    At least one tool implements this notation incorrectly and uses 2 ObjectFlows and a CentralBufferNode instead of two arrows and a rectangular symbol representing any ObjectNode sub-type

    SysML-1.6 p.146 states:

    Brake pressure information also flows to a control operator that outputs a control value to enable or disable the Monitor Traction behavior. No pins are used on Monitor Traction, so once it is enabled, the continuously arriving enable control values from the control operator have no effect, per UML semantics.

    It is not permissible in UML-2.5.1 to have 'No pins used on Monitor Traction'. And if there were no Pins, it is not clear how {contro\l} is indicated in Figure 11-10, because, from UML-2.5.1:

    Control Pins are shown with the textual annotation {control} placed near the Pin symbol.

    If there are 'No pins used on Monitor Traction' the {control} notation can't be supported.

    Further: SysML-1.6 p.127 states:

    A control value is an input or output of a control operator ..

    If there is any sense in which it can be "input" to another type of Action (the controlled one), this should also be stated.

    On SysML-1.6 p.140 it is not made clear what 'control parameters' are:

    Pins for control parameters are regular pins, not UML control pins.

    If they are parameters of a Behavior with the ControlOperator stereotype applied this should be clearly stated. Otherwise, the (necesssary) {control} input Pin required on Monitor Traction in Figure 11-10 could be considered to have an underlying "control parameter" that contradicts the above rule.

    A partial solution (apart from suggested expansions of the explanatory text) would be to at least use an explicit {control} Pin on Monitor Traction and remove the claim that it has no Pins.

  • Reported: SysML 1.6 — Tue, 30 Jun 2020 10:09 GMT
  • Updated: Thu, 2 Jul 2020 13:03 GMT
  • Attachments:

Edge for [else] in 'Figure 11-11: Continuous system example 2' should be an ObjectFlow not a ControlFlow

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The edge for the [else] in 'Figure 11-11: Continuous system example 2' should be an ObjectFlow not a ControlFlow (it is currently dashed):

    From UML-2.5.1:

    edges

    The ActivityEdges incoming to and outgoing from a DecisionNode, other than the decisionInputFlow (if any), must be either all ObjectFlows or all ControlFlows.

  • Reported: SysML 1.6 — Tue, 30 Jun 2020 11:49 GMT
  • Updated: Thu, 2 Jul 2020 13:03 GMT

Suggest additional main body figure illustrating context-specific values (initialValues) compartment used for deep system configuration

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    It has been suggested that sample Figure D.41 should not be an IBD but a BDD with objects (instances).

    A new spec example (not related to Annex D Hybrid SUV problem) is then required.

    Suggest use mobile phone camera configuration example (known to me and a tool vendor).

    Submitter willing to provide spec-friendly diagram(s) and supporting spec text.

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 11:18 GMT
  • Updated: Thu, 2 Jul 2020 13:01 GMT

Inconsistent incoming ObjectFlow and outgoing ControlFlows on the DecisionNode in Figure 11.12 - Continuous system example 3 'Enable on Brake Pressure > 0'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The 'Figure 11.12 - Continuous system example 3' for the Activity 'Enable on Brake Pressure > 0' shows a single incoming ObjectFlow from the ActivityParameterNode pressure : Brake Pressure to a DecisionNode with two outgoing ControlFlows (shown dashed) with guards vs Brake Pressure.

    It is not indicated whether the incoming ObjectFlow is a DecisionNode::decisionInputFlow. Assuming it is or is not both lead to contradictions vs the UML-2.5.1 spec.

    First, assume that is it not a decisionInputFlow. Then according to UML-2.5.1 it is then the primary incoming edge:

    A DecisionNode shall have at least one and at most two incoming ActivityEdges, and at least one outgoing ActivityEdge. If it has two incoming edges, then one shall be identified as the decisionInputFlow, the other being called the primary incoming edge. If the DecisionNode has only one incoming edge, then it is the primary incoming edge.

    But this means the reported figure immediately contradicts:

    If the primary incoming edge of a DecisionNode is a ControlFlow, then all outgoing edges shall be ControlFlows and, if the primary incoming edge is an ObjectFlow, then all outgoing edges shall be ObjectFlows.

    Because in the reported figure clearly there is a mix of a single incoming ObjectFlow and 2 outgoing ControlFlows.

    Let us then instead assume that the incoming ObjectFlow is a decisionInputFlow. The UML spec then seems to require that there be an additional ControlFlow (that is not present in the reported figure).

    Some related UML-2.5.1 spec quotes and constraints:

    edges
    The ActivityEdges incoming to and outgoing from a DecisionNode, other than the decisionInputFlow (if any), must be either all ObjectFlows or all ControlFlows.

    incoming_outgoing_edges
    A DecisionNode has one or two incoming ActivityEdges and at least one outgoing ActivityEdge.

    decisionInputFlow : ObjectFlow [0..1] (opposite A_decisionInputFlow_decisionNode::decisionNode)
    An additional ActivityEdge incoming to the DecisionNode that provides a decision input value for the guards ValueSpecifications on ActivityEdges outgoing from the DecisionNode.

    If the primary incoming edge of a DecisionNode is an ObjectFlow, and the DecisionNode does not have a decisionInput or decisionInputFlow, then the value contained in an incoming object token may be used in the evaluation of the guards on outgoing ObjectFlows.

    This is clearly not consistent with the reported figure, which has outgoing ControlFlows.

    The following seems to imply that decisionInputFlow is always accompanied by another incoming edge, but this is not (as far as I can tell) made explicit elsewhere as a constraint:

    If a DecisionNode has a decisionInputFlow, then a token must be offered on both the primary incoming edge and the decisionInputFlow before the token from the primary incoming edge is offered to the outgoing edges.

    [ASIDE: The UML-2.5.1 might be inconsistent when referring to 'incoming' w.r.t. decisionInputFlow (but this does not explain away the inconsistency in the reported SysML spec figure). The DecisionNode::decisionInputFlow does not subset ActivityNode::incoming:ActivityEdge[0..*], but it is sometimes referred to as an incoming edge.]

    An additional consideration is why outgoing ControlFlows are being used in the first place. The UML-2.5.1 does not seem to explicitly reject the use of incoming ObjectFlows on a ValueSpecification (although at least one tools declares InputPins on them to be invalid). It is not clear to this reporter that ObjectFlows with Probability could not be used to activate the ValueSpecifications for enable/disable (even though the reported spec figure for this version seems to have been changed to used dashed-line ControlFlows, compared with previous SysML spec versions).

    [EDIT:DK: Axel explained: 'ValueSpecificationActions can in fact have no InputPins (the attribute input is a derived union and ValueSpecificationActions don't define a subset of it).']

    It seems to this reporter that there are 2 solutions to the reported inconsistency:

    1. Somehow use an additional ControlFlow to the DecisionNode, and declare the existing Brake Pressure incoming ObjectFlow to be a decisionInputFlow.

    2. "Revert" the outgoing edges to be ObjectFlows [NOT permitted]

  • Reported: SysML 1.6 — Mon, 15 Jun 2020 04:47 GMT
  • Updated: Thu, 2 Jul 2020 12:58 GMT

'Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty' does not allocate to a FlowProperty and multiple other minor issues

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    In SysML-1.6 p.179: Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty

    The diagram does not show any allocation to a FlowProperty.

    Also:

    • It does not show the allocatedFrom for 'Action2' on Block7
    • It does not make sense naming the BDD 'Block0' if that block is not shown in the diagram

    There are allocations from Actions (usage level) to Blocks (definition level); whether that is an error is a matter of opinion, as it would seem SysML permits it. I suggest, however, that the spec figures completely avoid such "cross-level" allocations in the spec figures.

    May I once again suggest (plead, beg) diagram submitters to not (never ever again) use the infamous "elided Pin notation" for ObjectNode anywhere in the spec, as it is widely misunderstood and the tool support for it is poor (broken).

    An example diagram in the MagicDraw tool including explicit Pins is included. The naming conventions is different from the spec figures.

  • Reported: SysML 1.6 — Wed, 1 Jul 2020 11:20 GMT
  • Updated: Thu, 2 Jul 2020 12:57 GMT

Fig D.41 should be bdd with instance specs & slot values, not ibd with default values

  • Status: open  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    Figure D.41 is unchanged from SysML 1.0. The purpose of the figure was to illustrate how part serial numbers can be handled in SysML, but it was created without any practical experience in instance specification slot values. Instance slot values provide a more concrete representation of instance-level values such as serial numbers. A serial number should never be treated as a default value, because each serial number needs to be unique.

  • Reported: SysML 1.6 — Wed, 1 Jul 2020 17:13 GMT
  • Updated: Thu, 2 Jul 2020 11:19 GMT

SysML-1.6: DeriveReqt: OCL constraint directions client vs supplier

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.190: please check OCL directions:

    1_supplier_is_requirement

    The supplier shall be an element stereotyped by a subtype of
    AbstractRequirement.AbstractRequirement.allInstances().base_NamedElement->includesAll(self.base_Abstraction.client)

    2_client_is_requirement

    The client shall be an element stereotyped by a subtype of
    AbstractRequirement.AbstractRequirement.allInstances().base_NamedElement->includesAll(self.base_Abstraction.supplier)

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 09:45 GMT
  • Updated: Thu, 2 Jul 2020 09:45 GMT

Trivial: consistency: Either show the [metaclass] on all Stereotype symbols or none in 'Figure 16-1: Abstract Syntax for Requirements Stereotypes'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The Stereotype symbols for AbstractRequirement and Requirement show their [metaclass], the others do not.

  • Reported: SysML 1.6 — Wed, 1 Jul 2020 13:39 GMT
  • Updated: Wed, 1 Jul 2020 13:39 GMT

Figure D.24 Parametric Diagram does not explicitly show «equal» keyword or '=' on BindingConnectors

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    If the Connectors in the Figure D.24 'Defining Fuel Flow Constraints (Parametric Diagram)' are BindingConnectors suggest explicitly show «equal» keyword or '='.

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 00:13 GMT
  • Updated: Wed, 24 Jun 2020 07:04 GMT

Typo: 'not' should be 'nor' in '... not is this always even desirable'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    From p.174:

    It is acknowledged that this concept does not support a standard object-oriented paradigm, not is this always even desirable.

    The 'not' should probably be 'nor'

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 04:24 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Typo: references to FuelTankAssy should be FuelTankAssembly for consistency with Figure D.25

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.254:

    The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine.

    Figure D.25 has FuelTankAssembly.

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 04:03 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Typo: 'Various other model elements may be necessary to help develop a derived requirement, and these model element' plural missing

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Plural missing in:

    'Various other model elements may be necessary to help develop a derived requirement, and these model element may be related by a «refinedBy» relationship.'

    Should be:

    'Various other model elements may be necessary to help develop a derived requirement, and these model element*s* may be related by a «refinedBy» relationship.'

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 22:22 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Typo: Missing end parentheses bracket: '(described in D.4.3 Elaborating Behavior (Sequence and State Machine Diagrams)'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    SysML-1.6 p.249:

    Note that the interactions DriveBlackBox and Stac4rtVehicleBlackBox (described in D.4.3 Elaborating Behavior (Sequence and State Machine Diagrams), are depicted as owned by the AutomotiveDomain block.

    There is a missing end ')'

    (The issue with 'Stac4rtVehicleBlackBox' already caught under SYSML17-271)

  • Reported: SysML 1.6 — Sun, 21 Jun 2020 02:57 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Typo: 'with is owned by the AutomotiveDomain block.'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    This diagram represents the “DriveBlackBox” interaction, with is owned by the AutomotiveDomain block.

    Should be:

    This diagram represents the “DriveBlackBox” interaction, which is owned by the AutomotiveDomain block.

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 00:11 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Need Connector from fuel:Fuel to :FuelPump in 'Figure D.25 Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram)'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Need Connector from fuel:Fuel to :FuelPump in 'Figure D.25 Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram)'

    This is implied by p.254:

    The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine ...

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 03:41 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Naming inconsistencies 'Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties.'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    From SysML-1.6 p.254:

    Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties.

    The Figure D.24 shows these value properties: 'fuelFlowRate', 'fuelDemand' and 'fuelPressure' (all lowerCamelCase). The text does not match those value property names.

    The Figure D.24 shows these bound constraint parameters: 'flow rate' (with a space), 'injectorDemand' and 'press'. Suggest also constraint parameter 'flow rate' should be consistently named in the diagram 'flowRate' (no space and lowerCamelCase).

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 02:10 GMT
  • Updated: Wed, 24 Jun 2020 06:45 GMT

Figure D.23 has FuelFlow stereotyped by the DEPRECATED «flowSpecification»

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Figure D.23 has FuelFlow stereotyped by the DEPRECATED «flowSpecification»

    Known already to Marlin and Rick

  • Reported: SysML 1.6 — Mon, 22 Jun 2020 07:40 GMT
  • Updated: Wed, 24 Jun 2020 06:45 GMT

'Figure D.7 - Elaborating Black Box Behavior' some OCL missing, State names in oclInState() should be capital first letter, and display of name of alt fragment

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Figure D.7 Elaborating Black Box Behavior for the “Drive the Vehicle” Use Case (Sequence Diagram)

    The OCL for the ref fragment for Idle appears to be missing in the SysML 1.6 figure version (was present in the SysML 1.5 version).

    The referenced State name should have capital first letters to match the States in Figure D.1. From OCL-1.4:

    The operation oclIsInState(s) results in true if the object is in the state s. Possible states for the operation oclIsInState(s) are all states of the statemachine that defines the classifier's behavior. ...

    [EDIT: Actually, SysML-1.6 makes explicit that the Interaction DriveBlackBox is owned by the AutomotiveDomain block,
    so the ‘self’ won’t be the same context as for the StateMachine (so it might not be able to reference those States directly).]

    The name of the alt fragment 'controlSpeed' does not appear in the SysML-1.6 figure (it did in SysML-1.5 ). This may be deliberate. And it can't (as far as I can tell) be shown in MagicDraw/Cameo anyway. But it's a bit confusing when referenced here:

    The conditions for each alternative in the alt controlSpeed sub clause are expressed in OCL, and relate to the states of the HybridSUV block, as shown in Figure D.8.

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 01:25 GMT
  • Updated: Wed, 24 Jun 2020 06:45 GMT

SysML-1.6: Figure D.25 has the type Fuel for both an in Port and an out Port on FuelTankAssembly (and it is not ideal to have same name as the Classifier that flows)

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Figure D.25 Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram)

    Has the type Fuel for both an in Port and an out Port on FuelTankAssembly

    And it is not ideal to have same name Fuel as the Classifier Fuel that flows.

    I happen to use the prefix convention F_ for Ports that have flows (only) of one Classifier, so in this case F_Fuel and ~F_Fuel

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 06:36 GMT
  • Updated: Wed, 24 Jun 2020 06:44 GMT

7.3.2.3 Expose refers to 'The method' without referencing Viewpoint

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    7.3.2.3 Expose

    ...
    The view and the model elements related to the view are passed to the constructor when it is invoked. The method describes how the exposed elements are navigated to extract the desired information.

    Although it is explained (somewhat) under 7.1.1. View and Viewpoint, it would be clearer if it said something like:

    The method of the Viewpoint the View conforms to describes how the exposed ...

    Otherwise it reads like a View has a method.

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 12:20 GMT
  • Updated: Tue, 23 Jun 2020 12:20 GMT

Typo: 'Binding connectors, as defined in Clause 8 are used ...' missing comma

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.123 Has:

    Binding connectors, as defined in Clause 8 are used ...

    Should probably be (note comma after 'Clause 8,'):

    Binding connectors, as defined in Clause 8, are used ...

    This is the pattern used in UML-2.5.1.

    Hope this one is not too trivial to raise as a ticket. Worth establishing a convention/policy

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 00:54 GMT
  • Updated: Tue, 23 Jun 2020 01:02 GMT

Typo: 'Deleting the container requirement deleted the nested requirements, a functionality inherited from UML.' should be 'deletes'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    'Deleting the container requirement deleted the nested requirements, a functionality inherited from UML.'

    Should probably be:

    'Deleting the container requirement deletes the nested requirements, a functionality inherited from UML.'

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 21:58 GMT
  • Updated: Tue, 23 Jun 2020 01:02 GMT

Typo: 9.3.2.8 FlowProperty 'A flow propertys values'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    A flow propertys values

    Should be:

    A flow property's values

  • Reported: SysML 1.6 — Mon, 22 Jun 2020 07:07 GMT
  • Updated: Mon, 22 Jun 2020 07:07 GMT

For Connectors in IBD Figure D.4 to be typed by implied anonymous Associations need define them in BDD Figure D.15 between 'HybridSUV' and: 'Driver', 'Maintainer', 'Passenger', 'Baggage', 'Environment'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The SysML-1.6 spec states:

    'The associations among the classes may represent abstract conceptual relationships among the entities, which would be refined in subsequent diagrams.'

    'Note how the relationships in this diagram are also reflected in the Automotive Domain Model Block Definition Diagram, Figure D.15.'

    Actually, they aren't, the BDD Figure D.15 only shows non-navigable composition Associations between the Automotive Domain block and the owned Properties, which appear in the IBD Figure D.4 as Property symbols.

    The Connectors in the spec figure have labels like 'x1:', 'x2:', etc. This seems to imply the existence of anonymous Assocations (between 'HybridSUV' and 'Driver', 'Maintainer', 'Passenger', 'Baggage', 'Environment'), but they are not defined in Figure D.15.

  • Reported: SysML 1.6 — Sun, 21 Jun 2020 01:41 GMT
  • Updated: Sun, 21 Jun 2020 03:26 GMT
  • Attachments:

In Figure D.2 Real appears to be owned by the Automotive Value Types ModelLibrary (with no explicit ElementImport)

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    In 'Figure D.2: Defining value Types and units to be used in the Sample Problem' the Real appears to be owned by the Automotive Value Types ModelLibrary.

    This might be intended (it might intend to imply there is an ElementImport); if this is the case maybe it should be made explicit somewhere (in a diagram or in text).

    Otherwise, it should be drawn outside the ModelLibrary.

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 00:17 GMT
  • Updated: Wed, 17 Jun 2020 00:17 GMT

Lots of ControlValues that should be ControlValueKinds

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Lots of ControlValues that should be ControlValueKinds

  • Reported: SysML 1.6 — Fri, 28 Feb 2020 05:06 GMT
  • Updated: Mon, 15 Jun 2020 05:11 GMT

It should not be allowed to modify an AdjunctProperty

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    As described in the specification, AdjunctProperties are clearly intended for representing as properties things that should have been defined as such but that are not for historical reasons.

    However, even if it can actually be convenient to use read actions adjunct properties, it is not clear what is the semantics of using write actions on them. In addition, per its description, it is clear that and an adjunct property is derived from its principal.

    Base on the above, constraints shall be added in order to: (1) require an adjunct property to be derived, and (2) prevent using a adjunct property as the target of write action

  • Reported: SysML 1.6 — Thu, 30 Apr 2020 12:42 GMT
  • Updated: Thu, 30 Apr 2020 15:32 GMT

Duplicated sentence

  • Status: open  
  • Source: Mentor, a Siemens Business ( Fabien Launay)
  • Summary:

    The following sentence appears both before the bullet items list and as the first item in the bullet items list.

    "In the context of the definition of a SysML Stereotype, the name refers to the definition of a UML::PrimitiveType in the UML 2 PrimitiveTypes library"

  • Reported: SysML 1.6 — Wed, 25 Mar 2020 04:51 GMT
  • Updated: Fri, 3 Apr 2020 18:51 GMT

Unexpected word 'Figure' in Figure 4-2 name

  • Status: open  
  • Source: Mentor, a Siemens Business ( Fabien Launay)
  • Summary:

    Figure 4-2 name is "SysML Extension of UMLFigure".
    The word "Figure" at the end of the legend is not expected.

  • Reported: SysML 1.6 — Wed, 25 Mar 2020 04:47 GMT
  • Updated: Fri, 3 Apr 2020 18:51 GMT

Unexpected section number

  • Status: open  
  • Source: Mentor, a Siemens Business ( Fabien Launay)
  • Summary:

    Section number 17.2.1.1 is used whereas section 17.2.1 does not exist

  • Reported: SysML 1.6 — Wed, 25 Mar 2020 02:36 GMT
  • Updated: Fri, 3 Apr 2020 18:50 GMT

Clarify that contraint parameters are value properties

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The description given for ConstraintBlock makes it implicit that constraint parameter are value properties but there is no formal constraint about it.

  • Reported: SysML 1.6 — Thu, 12 Mar 2020 14:38 GMT
  • Updated: Thu, 12 Mar 2020 14:38 GMT

7_cannot_redefine_boundreference is too constrained

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Standard says.... "BoundReferences shall not be applied to properties that are related by redefinition to other properties with BoundReference applied"

    This constraint seems very arbitrary... BoundReference could be used akin to an alias... which allows one to use it as another layer of indirection... BoundReferences should be allowed to refer to other BoundReferences so if the "other BoundReference" changes one does not have to change the first one which refers to it

  • Reported: SysML 1.6 — Sun, 1 Mar 2020 16:36 GMT
  • Updated: Mon, 2 Mar 2020 15:58 GMT

Aggregation multiplicities not correct

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Statement... "That is: "0..1" if the attribute has a composite aggregation and "0..*" otherwise"

    The standard specifies that...
    "8.3.1.1.10 Default multiplicities
    SysML defines defaults for multiplicities on the ends of specific types of associations. A part or shared association has a default multiplicity of [0..1] on the black or white diamond end. A unidirectional association has a default multiplicity of 1 on its target end. These multiplicities may be assumed if not shown on a diagram. To avoid confusion, any multiplicity other than the default should always be shown on a diagram."

    so the assumption would be 0..1 not 0..* on the otherwise part... UML has the same thing

  • Reported: SysML 1.6 — Thu, 27 Feb 2020 18:21 GMT
  • Updated: Mon, 2 Mar 2020 15:57 GMT

SysML 1.6 statement is too strong

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    SysML says...
    “Unless a type of diagram element is shown in some form in one of the SysML diagram elements tables, or in a usage example in one of the normative SysML clauses, it is not considered to be part of the subset of UML included within SysML, even if the UML metamodel packages support additional constructs. For example, SysML imports the entire Dependencies package from UML, but it includes diagram elements for only a subset of the dependency types defined in this package.”

    so does that mean all of the actions in common behavior are not there (even though they are explicit included in the tables in the first chapter?)

    I think the statement above in SysML does not include everything... if this is what is wanted then UML4SysML needs to be changed to be only the things in the diagrams in the standard...

  • Reported: SysML 1.6 — Tue, 25 Feb 2020 03:18 GMT
  • Updated: Tue, 25 Feb 2020 14:52 GMT

Caveat is not specific for UseCases

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The current standard says:

    "The only form of an association end that SysML allows an association to own directly is an unnamed end used to carry an inverse multiplicity of a reference property."

    But this is not totally true... the Communication Path in Use Cases is modeled as an Association and it has no navigability shown, which means it is navigable on both ends, which means ownership on both ends, but the ends are UseCases and Actors which are BehavioredClassifiers which do not have attributes, so this statement in the standard must be added to, to

    (this should go in a sentence in the standard after the sentence cited)
    allow Association to own both end of the association ends if one end is either an Actor or a UseCase.

    I state either because SysML deriving most of its UseCase semantics from UML... an Actor can be associated to a Classifier in a UseCase per UML... and a UseCase can be associated to another UseCase in UML provided that UseCase is not specifying the same Subject... this is specified in UML 2.5.1 in section 18.1.4

    "UseCases may have other Associations and Dependencies to other Classifiers"

    also 18.2.1.4 says "An Actor can only have Associations to UseCases, Components, and Classes. Furthermore these Associations
    must be binary."

    and 18.2.5.6 "UseCases cannot have Associations to UseCases specifying the same subject"

  • Reported: SysML 1.6 — Fri, 21 Feb 2020 14:40 GMT
  • Updated: Tue, 25 Feb 2020 14:51 GMT

Introduction to 9.1.3 Proxy Ports and Full Ports might be interpreted as SysML only permitting Full and Proxy Ports (not standard ports)

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The following sentence under 9.1.3 Proxy Ports and Full Ports can cause confusion:

    SysML identifies two usage patterns for ports, one where ports act as proxies for their owning blocks or its internal parts (proxy ports), and another where ports specify separate elements of the system (full ports).

    It may be read as SysML only permitting Proxy Port and Full Port.

    I suggest it could be improved by adding the one word 'additional':

    SysML identifies two additional usage patterns for ports, one where ports act as proxies for their owning blocks or its internal parts (proxy ports), and another where ports specify separate elements of the system (full ports).

    Or more verbosely, something like:

    Apart from standard UML port usage, SysML identifies two additional usage patterns for ports, one where ports act as proxies for their owning blocks or its internal parts (proxy ports), and another where ports specify separate elements of the system (full ports).

    My experience is that some new SysML users (in part because of the way some tool menus work) get the impression that one somehow should not being standard ports at all in SysML, which is completely wrong.

    Some tools seem to assume (incorrectly) that just because SysML introduces Proxy and Full Port that one is always supposed to use one of them instead of a standard port, and they hide standard ports from some menus.

    I absolutely advocate the use (where appropriate) of standard ports still, especially early on during modelling. External clients of a port are not supposed to care ("know") anyway, it's ultimately an implementation detail.

    The SysML spec itself (as of SysML 1.6) is currently very clear on this:

    • 'Ports that are not specified as proxy or full are simply called "ports."'
    • 'Proxy and full ports support the capabilities of ports in general, but these capabilities are also available on ports that are not declared as proxy or full.'
    • 'Modelers can choose between proxy or full ports at any time in the development lifecycle, or not at all, depending on their methodology.'
    • 'Modelers have the option of applying stereotypes for proxy and full ports to indicate whether ports are specifying features of their owners and internal parts (proxy), or for themselves separately (full).'
    • 'Using existing blocks with ports only requires knowing the port types ...'
    • 'Modelers can apply stereotypes for proxy and full ports at any stage of model development, or not all if the stereotype constraints are not needed.'
    • 'Figure 9-7 happens to use unstereotyped ports on a general block distributed to users, and stereotyped ports on its specializations for implementation, but the modelers might have not used stereotypes at all ...'
    • 'Unstereotyped ports do not commit to whether they are proxy or full, and do not prevent or dictate future application of the stereotypes'

    etc.

    (There are also considerations when using Ports from readonly libraries.)

  • Reported: SysML 1.6 — Sat, 15 Feb 2020 01:10 GMT
  • Updated: Mon, 24 Feb 2020 03:17 GMT

Continuous and Discrete need to be on FlowProperties as well

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Continuous and Discrete need to be on FlowProperties as well as Parameters and ActivityEdge

  • Reported: SysML 1.6 — Thu, 20 Feb 2020 20:03 GMT
  • Updated: Thu, 20 Feb 2020 20:08 GMT

No Creation and Destruction Event in Current UML

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    UML4SysML::CreationEvent
    UML4SysML::DestructionEvent

    There is no Creation or Destruction Event in the current UML

  • Reported: SysML 1.6 — Thu, 20 Feb 2020 15:10 GMT
  • Updated: Thu, 20 Feb 2020 17:26 GMT

Figure 9.5 missing, duplicates 9.4

  • Status: open  
  • Source: Georgia Institute of Technology ( Mr. Marlin Ballard)
  • Summary:

    In this version of the spec, "Figure 9-5: Item Flow Stereotype" is a duplicate of "Figure 9-4: Provided and Required Features" and does not show the ItemFlow stereotype. The correct figure is present in 1.5 (pp85) and the 1.6beta (pp92) versions of the spec.

  • Reported: SysML 1.6 — Mon, 17 Feb 2020 21:34 GMT
  • Updated: Tue, 18 Feb 2020 15:55 GMT

Remove reference to non-existing properties allocatedFrom and allocatedTo

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Section 15.3.1.5 states:
    "For brevity, the «elementType» portion of the allocatedFrom or allocatedTo property may be elided from the diagram."

    The properties "allocatedFrom" and "allocatedTo" do not exist. Change the sentence to:

    "For brevity, the «elementType» portion of the allocatedFrom or allocatedTo section may be elided from the diagram."

  • Reported: SysML 1.6 — Thu, 13 Feb 2020 16:21 GMT
  • Updated: Thu, 13 Feb 2020 16:21 GMT

Remove notation form ActorPart

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Table 8.3 has a row giving notation for an "Part Property typed by an actor". However since actors cannot have the Block stereotype applied, properties they type cannot be part properties as defined in the SysML specification Clause 8.3.2.4 Block, (p53)). So, this row shall be removed

  • Reported: SysML 1.6 — Thu, 6 Feb 2020 16:59 GMT
  • Updated: Thu, 6 Feb 2020 16:59 GMT

Conjugation Stereotype

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    in the Algorithm given in section C.7, they refer to a stereotype named Conjugation (<<conjugates>>) which is also referred to in the resolution information... but that Stereotype does not appear in the standard

  • Reported: SysML 1.6 — Tue, 4 Feb 2020 13:25 GMT
  • Updated: Wed, 5 Feb 2020 20:03 GMT

is the stereotype <<~InterfaceBlock>>

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    is the stereotype on a conjugate block <<~InterfaceBlock>> or <<InterfaceBlock>> not specified in the Standard and very confusing from what information is given in the standard

    I find the whole thing wrong... one should have a stereotype <<InterfaceBlock>> that has the attribute original in it... and remove <<~InterfaceBlock>> ... it works just the same without the confusion... one would need to make original [0..1]... or better yet, one could say that every InterfaceBlock must have an implicitly (possibly created by tool) or explicitly created by the modeler conjugate InterfaceBlock which is in the Model

    one could instead add in the stereotype <<conjugates>> which keeps that information as well... but then there needs to be a constraint in the standard that keeps conjugates and original in sync.. but this would be acceptable to be able to show this in a model

    by the way, there are places in the standard (examples) where it is not original as the attribute

  • Reported: SysML 1.6 — Tue, 4 Feb 2020 13:39 GMT
  • Updated: Wed, 5 Feb 2020 19:51 GMT

Need Bound References Compartment

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    in Block1 and Block2, compartments need to be Bound References

  • Reported: SysML 1.6 — Wed, 29 Jan 2020 20:37 GMT
  • Updated: Mon, 3 Feb 2020 16:45 GMT

Parameters and Variables don't make sense

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:
    • diagram was lifted it looks like from UML... the header is UML not SysML needs to be fixed
    • the semantics are unknown, what message can be sent between an in and an inout primitve... would suggest that these are standardized, like set,get messages
    • this shows Parameters and Arguments, but does not show Variables which should be added
  • Reported: SysML 1.6 — Wed, 22 Jan 2020 13:17 GMT
  • Updated: Mon, 27 Jan 2020 10:51 GMT

The definition of AdjunctProperty

  • Status: open  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    The definition of AdjunctProperty states that "The AdjunctProperty stereotype can be applied to properties to constrain their values to the values of connectors typed by association blocks, call actions, object nodes, variables, parameters, interaction uses, and submachine states." However, the practical application to a modeler of these different types of adjunct properties is not made explicit in the text.

    For example, adjuncts of behavior parameters allows a block's behavior to be bound to its value properties, or those in its ports, and thus solves a long standing problem in the language prior to SysML 1.4.

    But when it comes to adjunct properties of activity object nodes the practical application is hard to determine and at the same time it breaks encapsulation by making the behavior's internal state visible and may have a significant impact on the efficiency of model simulation and generated code. The same concerns apply to activity variables.

    I am also mystified about the practical application for adjunct properties of interaction uses and sub-machine states (but not a state machine's states). It would be very useful to have a block property that enumerates the current state of an associated state-machine, but as it stands this is not possible by any means that I am aware of (other then by doing it explicitly inside the state-machine's model).

    Discuss.

  • Reported: SysML 1.6 — Wed, 21 Aug 2019 16:30 GMT
  • Updated: Mon, 27 Jan 2020 00:16 GMT

QUDV library inconsistently uses SysML::Libraries::PrimitiveValueTypes

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I also realized that the QUDV library inconsistently uses in a few places SysML::Libraries::PrimitiveValueTypes when in fact it should use UML's PrimitiveTypes.

    I believe that this is a new issue for SysML 1.3.

  • Reported: SysML 1.6b1 — Thu, 13 Jun 2019 14:34 GMT
  • Updated: Mon, 27 Jan 2020 00:16 GMT

AbstractRequirement: direction of /tracedTo wrong in Attributes description

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    This is the wrong way round:

    /tracedTo : NamedElement [0..*]
    Derived from all elements that are the client of a «trace» relationship for which this requirement is a supplier.(derived)

    However the operation statement is correct:

    getTracedTo () : NamedElement [0..*]
    bodyCondition:Trace.allInstances()->select(base_Abstraction.client=self).base_Abstraction.supplier
    

    See also attached image in a tool.

    Compare with consistent verifiedBy, satisfiedBy:

    /satisfiedBy : NamedElement [0..*]
    Derived from all elements that are the client of a «satisfy» relationship for which this requirement is a supplier.(derived)

    getSatisfiedBy () : NamedElement [0..*]
    bodyCondition:Satisfy.allInstances()->select(base_Abstraction.supplier=self).base_Abstraction.client
    

    /verifiedBy : NamedElement [0..*]
    Derived from all elements that are the client of a «verify» relationship for which this requirement is a supplier.(derived)

    getVerifiedBy () : NamedElement [0..*]
    bodyCondition:Verify.allInstances()->select(base_Abstraction.supplier=self).base_Abstraction.client
    

    It seems it was correct in SysML1.4:

    /tracedTo: NamedElement [*]
    Derived from all elements that are the supplier of a «trace» relationship for which this requirement is a client.

    The error may have been introduced during other changes.

  • Reported: SysML 1.6 — Thu, 23 Jan 2020 02:37 GMT
  • Updated: Thu, 23 Jan 2020 02:41 GMT
  • Attachments:

Description of getRefines() has typo and inconsistent singular vs plural

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    In the statement of getRefines():

    getRefines (in ref : NamedElement) : AbstractRequirement [0..*]

    The query getRefines() gives all the requirements that are suppliers ("to"end of the concrete syntax) of a «Refine» relationships whose client is the element in parameter. This is a static query.

    There should be a space in:

    "to"end

    So:

    "to" end

    There are mistakes in the use of singular vs plural, the operation description should read:

    The query getRefines() gives all the requirements that are suppliers ("to" end of the concrete syntax) of «Refine» relationships whose clients are the element in parameter. This is a static query.

    If the suggestion SYSML17-276 is adopted the above could be rewritten to state:

    The query getRefines() gives all the named elements that are suppliers ("to" end of the concrete syntax) of «Refine» relationships whose clients are the named element in parameter.

  • Reported: SysML 1.6 — Thu, 23 Jan 2020 02:03 GMT
  • Updated: Thu, 23 Jan 2020 02:05 GMT

Description of getRefines() restricts returned elements to AbstractRequirement [0..*] but the OCL static query does not (effectively NamedElement [0..*])

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The attached image was initially for analysis of SYSML17-57

    In UML2.5.1 the client(s) and supplier(s) of an Abstraction (including Trace stereotype) are always NamedElements.

    There are no additional constraints placed on the type of the client or supplier of the SysML Refines.

    The description of the operation getRefines() restricts the return elements to AbstractRequirement[0..*]

    getRefines (in ref : NamedElement) : AbstractRequirement [0..*]

    The query getRefines() gives all the requirements that are suppliers ("to"end of the concrete syntax) of a «Refine» relationships whose client is the element in parameter. This is a static query.

    (Typos in the above are addressed in a separate issue report.)

    But the OCL static query does not, and effectively returns NamedElement [0..*]

    bodyCondition:
         Refine.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier
    

    As examined under SYSML17-15, all of the following are currently valid (see also attached image):

    • Any NamedElement refines a Requirement.
    • A Requirement refines another Requirement.
    • A Requirement refines any NamedElement.
    • Any NamedElement refines another NamedElement.

    Tools correctly implementing the static OCL query permit display (or callout) of getRefined() on any NamedElement.

    It has to be decided whether:

    Option1: The static OCL query should have the return type filtered to only AbstractRequirement (not preferred by this submitter)

    Option2: Loosen the restriction on the description of the return type of getRefined() to the NamedElement[0..*] (preferred by this submitter)

    While Option2 may seem to depart from the initial spirit of the SysML Refines extension within the context of Requirements, it is more consistent with the general UML use of Refines between any (in SysML a pair only) of NamedElements. If this is done, the description also need to be rewritten thus (including typo fixes and fix of plural vs singular):

    The query getRefines() gives all the named elements that are suppliers ("to" end of the concrete syntax) of «Refine» relationships whose clients are the named element in parameter.

    This submitter see no reason why the use of NamedElement[0..*] throughout can't be adopted. Modellers using SysML Refines for Requirement are not impacted, and modellers using Refines for more general purposes would still have access to the useful getRefines().

    The above also implies moving Refines out of the Requirements chapter entirely (into, for example, Model Elements), with a description of the more general use of Refines, but also then describing the typical usage of it for Requirements refinement in the Requirements chapter.

  • Reported: SysML 1.6 — Thu, 23 Jan 2020 01:47 GMT
  • Updated: Thu, 23 Jan 2020 02:05 GMT
  • Attachments:

Parts is too restrictive

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    the standard says
    ""The Sequence diagram describes the flow of control between actors and systems (blocks) or between parts of a system... lifelines into their constituent parts."

    But lifelines can be parts, references, parameters, arguments, variables

    also think one needs to make the distinction between Actors that are parts of the block and Actors that are external to the block because they can be represented as lifelines as well

    also should specify that because an interaction in definition is not tied to a particular block (but the context is derived when executed by a block)... there is no way of telling whether something is a part or a reference at definition time... therefore every head of a lifeline is should as solid and no distinction (like a dotted line for a head) is made in interaction diagrams

  • Reported: SysML 1.6 — Wed, 22 Jan 2020 13:28 GMT
  • Updated: Wed, 22 Jan 2020 13:49 GMT

Missing guard brackets in example activity diagram 11-12

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The guard Brake Pressure > 0 in figure 11-12 on page 148 has no enclosing square brackets.

  • Reported: SysML 1.6 — Tue, 21 Jan 2020 16:44 GMT
  • Updated: Tue, 21 Jan 2020 16:44 GMT

How to interpret non-Navigation

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    An “X” on a single end of an association to indicate that an end is not navigable has similarly been dropped

    Does this statement mean that SysML has no concept of non-Navigation (only unspecified)... or does it mean that if you
    have an association end A has no Navigation shown, end B has Navigation shown... then End A should be interpreted as
    being non-Navigatable...

    The standard would indicate this as it says "has been similarly dropped" which means it is not shown but it is there all the same...

  • Reported: SysML 1.6b1 — Sat, 9 Nov 2019 15:53 GMT
  • Updated: Mon, 11 Nov 2019 19:57 GMT

No changebars in

  • Status: open  
  • Source: Aerospace Corporation ( Mr. Ryan Noguchi)
  • Summary:

    The version of the specification document that is supposed to have changebars does not appear to have any changebars or redlines. This makes it unnecessarily difficult to find out what has changed since the released 1.5 spec.

  • Reported: SysML 1.6b1 — Tue, 8 Oct 2019 18:16 GMT
  • Updated: Thu, 10 Oct 2019 19:18 GMT

Proposal: patent-friendly part/element numbering system with compliant solid line

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    National patent offices require patent drawings in a very specific format. The “parts” of an invention must typically be numbered consistently, and always indicated with a solid line from each part number to the part.

    I have found many applications can be represented well as SysML Parts Property symbols, and with convenient correct propagation of part numbers across diagrams (Single Source of Truth).

    I have been re-appropriating Comment for this using the following diagramming “hack" in the MagicDraw/Cameo tool:

    • Use the Documentation field of a Part Property to hold each unique part number.
    • Use the Retrieve Documentation feature to display that part number in a Comment symbol (which is stereotyped «Documentation»).
    • The HACK: hide the border of the Comment by making it white against white background, and also hide the stereotype.

    But then you have to use an external image editing tool to tediously make the dashed lines all solid to meet the patent office's requirements.

    Note that UML2.5.1 states:

    'The connection to each annotatedElement is shown by a separate dashed line.’

    A refinement of this proposal might involve creating a special new dedicated SysML element to achieve this, with a dedicated attribute for carrying the numbering.

    It is beyond the scope of this initial proposal to specify how the capability might be achieved.

    The proposal is not limited to numbering and indicating SysML Part Properties typed by Blocks, it could be applied to other Element kinds, but Part Properties lend themselves immediately to the purpose.

    This proposal does not yet elaborate on how the numbering sequence might be handled (largely a tool feature matter).

    The section '7 Model Elements' is a candidate for specification of the new proposed element.

    [Diagrams illustrating the required result will be provided via JIRA once the proposal issue ticket is raised]

    Reference: IP Australia: Best Practice Guide: Appendix: Examples of Drawings: https://www.ipaustralia.gov.au/sites/g/files/net856/f/best_practice_guide_appendix_iv.pdf

  • Reported: SysML 1.6b1 — Mon, 23 Sep 2019 17:35 GMT
  • Updated: Tue, 24 Sep 2019 15:56 GMT

Should <> have a capital V?

  • Status: open  
  • Source: Boeing ( Alan Lee)
  • Summary:

    I'm not sure if this is actually an issue (I think it is). There are 2 keywords in Figure E.10: Spring Length Example; <<valueType>> and <<ValueType>>. Wondering if it is the same keyword and the latter should be lowercase v.

  • Reported: SysML 1.6b1 — Wed, 21 Aug 2019 16:29 GMT
  • Updated: Tue, 3 Sep 2019 18:47 GMT

Duplicate Elements in Table

  • Status: open  
  • Source: Boeing ( Alan Lee)
  • Summary:

    Elements starting from Namespace Compartment to InstanceSpecification (9 items Elements total) is listed twice in the 8.2.1 Block Definition Diagram: Table 8.1.

  • Reported: SysML 1.6b1 — Wed, 21 Aug 2019 16:03 GMT
  • Updated: Tue, 3 Sep 2019 18:46 GMT

Refine / Trace relationship operations are too restrictive

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Refine::getRefines(in ref : NamedElement) : AbstractRequirement should return NamedElement according to the definition of the refine stereotype in section 16.1. The body condition of the operation is not consistent with the return type AbstractRequirement.

    There is no constraint that restricts that one end of the refine relationship must be an element of type AbstractRequirement.

    Trace::getTracedFrom(in ref: NamedElement) : AbstractRequirement should return NamedElement according to the definition of the trace stereotype. The body condition should be updated as well from AbstractRequirement to NamedElement.

    The sentence in section 16.1 "A generic trace requirement relationship provides a general-purpose relationship between a requirement and any
    other model element." is too restrictive with regard to the definition of the trace stereotype.

  • Reported: SysML 1.6b1 — Thu, 8 Aug 2019 16:04 GMT
  • Updated: Thu, 8 Aug 2019 16:04 GMT

VerdictKind should also have the literal none

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    As defined in the UTP element Verdict, the SysML VerdictKind should also define an enumeration literal none:

    none The test case has not been executed yet.

    When a test case is not executed yet or just invoked, its verdict is none. None indicates that no communication between
    test components and the SUT has been carried out yet. None is the weakest verdict. It is never set by the tester directly.

  • Reported: SysML 1.6b1 — Thu, 8 Aug 2019 07:58 GMT
  • Updated: Thu, 8 Aug 2019 07:59 GMT

ProxyPort property "matching"

  • Status: open  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    [From email to sysml-rtf@omg.org 7-May-2019, and discussed at the SysML RTF meeting 9-May-2019.]

    The situation of a proxy port's InterfaceBlock having multiple flow properties, and may be also multiple value properties, leads to the vexing question of how they all get paired up with [the] port's owning blocks' features. Putting aside behaviour ports (isBehavior=true), the most straightforward solution would be to use a binding connector between each feature in the proxy port and the actual features in the owning block. However, I find the public draft of SysML 1.6 to still not be completely clear on this matter, despite its improvements to the chapter on ports and flows.

    The section on FlowPorperty (9.3.2.8) refers to property matching (2nd paragraph), but does not contextualise when property matching might occur. Most of what it states makes perfect sense in the context of connected proxy ports, especially when the ports have the same type (i.e. an InterfaceBlock) and one port is conjugated. However, it becomes remarkably unclear what it means when matching is applied to the proxy port and its owning block's flow properties.

    The section on Proxy Ports (9.3.2.13), replaces the later part of the first paragraph with a subsequent paragraph to spell out how a proxy port relates to its owning block, but seems to do this in a weak way by stating "This can be achieved in several ways. For instance by...", which sounds informative, rather than normative. Nevertheless it does state "by binding it to a fully specified internal part or by having all its properties individually bound to internal parts."

    If a proxy port is bound to an internal part, is there a need for the port's type to match that of the bound part? If not, what are the rules for feature matching?

    If a proxy port's "properties [are] individually bound to internal parts", then dose the meaning of "part" extend to the block's value properties and flow properties? (I wouldn't ordinarily consider them to be parts.) If not then where does it state that these properties can be bound?

  • Reported: SysML 1.6 — Thu, 9 May 2019 14:13 GMT
  • Updated: Thu, 9 May 2019 14:13 GMT

cannot model and validate physical connections

  • Status: open  
  • Source: US Navy - Naval Information Warfare Center - Atlantic ( Stuart Pearce)
  • Summary:

    I’d like to model the physical connection from a device to another device. It appears SysML 1.4 does not allow this natively or easily. I’ve discussed this issue with Russell Peak, Georgia Tech and he agrees that it is a short coming of SysML.

    For example:
    I have a computer with a power cord that I would like to model to verify the correct connectors are on it. The wall receptacle is typically a 5-15R for North America, the matching power cord connection is a 5-15P. The computer typically has a C13R power receptacle and the power cord plug would be a C13P. I can add ports to my block in an ibd for the receptacle and plug ends, but I cannot validate that a good connection is 5-15R=5-15P for the wall end or C13R=C13P for the computer end.
    This will apply for all types of physical connections, copper data, fiber data, pipe, tube, etc.

    If there is a working group for this area I will be glad to work with them.

  • Reported: SysML 1.4 — Mon, 22 Apr 2019 10:40 GMT
  • Updated: Wed, 24 Apr 2019 15:50 GMT

Section: Chapter: 7.3.2.4 View

  • Key: UMLR-104
  • Legacy Issue Number: 10411
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Although it is mentioned in the text it isn't 100% clear that a view has only one conforming viewpoint. Define a constraint for a view that only one conform relationship to a viewpoint is allowed.

  • Reported: SysML 1.0 — Fri, 13 Oct 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities

  • Key: UMLR-140
  • Legacy Issue Number: 12434
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Activity regions and their contents should be redefinable

  • Reported: SysML 1.0 — Fri, 9 May 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Callout notation for many clients/suppliers

  • Key: UMLR-141
  • Legacy Issue Number: 12511
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It is allowed that for example a trace relationship has more than one client or supplier. It is unclear how the callout notation looks like for such a relationship.

  • Reported: SysML 1.0 — Tue, 27 May 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT