In 8.3.20.2 AssertConstraintUsage, in the OCL for the constraint validateAssertConstraintUsageReference, the invocation referencedFeaure() should be referencedFeature().
In 8.4.1 Semantics Overview, the tables contain the following errors.
In 8.3.17.15 SendActionUsage, in the OCL for the constraint checkSendActionUsageSubactionSpecialization, the reference to Actions::Action::acceptSubactions should be Actions::Action::sendSubactions.
In 8.3.17.5 AssignmentActionUsage, under "Constraints":
The doc descriptions of MergeAction, DecisionAction, JoinAction and ForkAction use "succession connector". This should be replaced with "succession connection" (4 times).
In Table 15 of the Representative Notation Tables, the row labeled Accept and Send Action Flow includes a model fragment that uses a combination of a succession and a binding connection to connect to the input payload parameter of a send action and from the output payload parameter of an accept action. This issue recommends adding another example of a common pattern that replaces the succession and the binding connection with a succession flow.
includes the the keyword
an occurrence isage
should be
usage is
PrefixMetadataMember : OwningMembership =
'#' ownedRelatedEleemnt = PrefixMetadataUsage
Element is not spelled correctly
PrefixMetadataMember : OwningMembership =
'#' ownedRelatedEleemnt = PrefixMetadataUsage
Element is not spelled correctly
PackageMember : OwningMembership
MemberPrefix
( ownedRelatedElement += DefinitionElement
| ownedRelatedElement = UsageElement ) |
there is no equal sign here
The current specification presents two issues with compartment definitions:
• The same elements may appear in multiple compartments, even when a more specific compartment is defined (e.g., action and perform action).
• Because keywords are hidden, compartment element keywords cannot be clearly distinguished (for example, perform action looks the same as action).
To address these issues, the following adjustments are proposed. Specific compartments should explicitly exclude overlapping contents:
actions-compartment-contents (page 227)
• exclude perform-actions-compartment-contents (page 227)
use-cases-compartment-contents (page 255)
• exclude include-use-cases-compartment-contents (page 255)
states-compartment-contents (page 238)
• exclude exhibit-states-compartment-contents (page 239)
constraints-compartment-contents (page 243)
• exclude require-constraints-compartment-contents (page 246)
• exclude assume-constraints-compartment-contents (page 246)
• exclude assert-constraints-compartment-contents (page 244)
requirements-compartment-contents (page 246)
• exclude satisfy-requirements-compartment-contents (page 247)
• exclude verifies-compartment-contents (page 253)
Currently, the usage appearance in the ‘parameters’ compartment is defined in the “8.2.3.17 Actions Graphical Notation” chapter as follows:
parameters-compartment-element = el-prefix? FeatureDirection UsageDeclaration ValueOrFlowPart? DefinitionBodyItem*
This is not consistent with other compartments that represent elements which can declare a direction (it includes only the ‘direction’ modifier but omits others), such as items, parts, and attributes:
items-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
parts-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
attributes-compartment-element = el-prefix? UsagePrefix usage-cp
To ensure consistency, it should be aligned with these definitions, as shown below:
parameters-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
Currently, the usage appearance in end compartment are declared in “8.2.3.14 Interfaces Graphical Notation” chapter like that:
ends-compartment-element = QualifiedName (’:’ QualifiedName)?
It is not consistent with all other compartments, e.g. parts, ports:
parts-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
ports-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
It should be aligned with those with one simple modification that skips the ‘end’ prefix declaration:
ends-compartment-element = el-prefix? BasicUsagePrefix UsageExtensionKeyword* usage-cp
On page 630 and 634 in the table under the section for ScalarQuantityValue Operations on the 3rd row, 1st column, the text is:
fs1+fs2
for the Description:
Addition of a bound and a free scalar quantity returns a bound scalar quantity.
Text should be:
bs1+fs2
In the section for /stakeholderParameter within 8.3.21.8 RequirementsDefinition:
"The parameters of this RequirementDefinition that represent stakeholders for th requirement"
"the" missing the "e" at the end of the sentence.
Standard library `ISQMechanics.sysml` contains a declaration of torque as a scalar quantity to represent torque magnitude, but the related torque vector quantity is missing.
A torque vector quantity and associated coordinate frame should be added using the same pattern as for other vector quantities.
Note: This issue was flagged in "SysML v2 Release" Google Group at https://groups.google.com/g/sysml-v2-release/c/w7ZbFZ9d-e0/m/yTF8oyb6AwAJ .
In the Systems Library model Actions, the action definition AssignmentAction has two parameters, target and replacementValues, in that order. The action usage assignmentActions, which is defined by AssignmentAction, redefines the target parameter, but inherits replacementValues.
The action usage Action::assignments is also defined by AssignmentAction and it subsets assignmentActions. This means that it has two parameters from AssignmentAction and two parameters from assignmentActions as potentially inheritable members. However, assignmentActions::target redefines AssignmentAction::target so the latter is not inherited. And assignmentActions::replacementValues is the same as AssignmentAction::replacementValues, so the former is not inherited again.
The result of this is that the inherited parameters of Action::assignments are AssignmentAction::replacementValues and assignmentActions::target in that order. That is, the parameters of assignments have effectively switched their order relative to how they are defined in AssignmentActions. This is a problem, because an AssignmentActionUsage has an implied specialization of assignments, and it is parsed assuming the parameters inherited from assignments are in the same order as in AssignmentAction.
There are errors in the example model that need to be corrected to align with the latest release.
This includes the following errors on pg 662.
From: variation part transmission:TransmissionChoices;
To: part transmission:TransmissionChoices;
From: variation part sunroof:Sunroof;
To: variation part sunroof:Sunroof [0..1];
It is also recommended to add the subset of the part vehicleFamily to model a specific vehicle configuration.
In the Systems Library model Flows, the flow usage flows explicitly subsets messages. However, messages is also a flow usage, and it has owned end features. So, according to the constraint checkFlowUsageFlowSpecialization, messages is required to subset flows. This means messages and flows subset each other and are, therefore, semantically equivalent. As a result, all message flow usages with implied subsetting of messages end up having the same semantics as non-message flow usages with implied subsetting of flows.
In 8.3.21.7 RequirementConstraintMembership, the constraint validateRequirementConstraintMembershipIsComposite requires that the ownedConstraint of a RequirementConstraintMembership be composite. However, consider the following:
part p {
constraint c;
}
requirement r {
subject :> p;
require p.c;
}
In this case, the constraint c is composite in p, but the required constraint referencing p.c is composite in r. Further, checkConstraintUsageCheckedConstraintSpecialization requires that c subset Part::checkedConstraints, which indirectly specializes Object::ownedPerformances, and, therefore, so does the required constraint referencing p.c. But checkConstraintUsageRequirementConstraintSpecialization requires the required constraint to specialize RequirementCheck::constraints, which (as a composite constraint usage) indirectly specializes Performance::subperformances. Thus, the required constraint inherits from both ownedPerformances and subperformances, which is inconsistent (in particular, this is bound differently in the two features).
The following library models include the declaration of types that have inherited members with the same name, because of diamond inheritance of redefined features.
Systems Library
Analysis Domain Library
Cause and Effect Domain Library
Geometry Domain Library
Metadata Domain Library
Quantities and Units Domain Library
Requirement Derivation Domain Library
The analysis case definition TradeStudy from the Analysis Domain Library model TradeStudies.sysml is intended to be used by redefining the objective tradeStudyObjective to use a concrete specialization of TradeStudyObjective, e.g., MinimizeObjective or MaximizeObjective. For example:
analysis tradeStudy : TradeStudy {
objective minimize :>> tradeStudyObjective : MinimizeObjective;
...
}
However, MinimizeObjective and MaximizeObjective redefine the parameters from TradeStudyObjective, and TradeStudy::tradeStudyObjective also redefines the first three of these parameters (selectedAlternative, alternatives and eval). But this means that both sets of redefinitions are inherited by the objective minimize in the analysis case usage above, which is semantically inconsistent. Currently, the only way to avoid this is for the modeler to include nested redefinitions of selectedAlternative, alternatives and eval when redefining tradeStudyObjective, which is inconvenient and unintended.
There should be a Constants Domain Library that capture all mathematical and CODATA Fundamental Physical Constants as published on https://pml.nist.gov/cuu/Constants/, in particular from the ASCII list of all constants at https://pml.nist.gov/cuu/Constants/Table/allascii.txt. Each constant should include a specification of whether its real number value is exact or not and, if not, what the uncertainty is.
The definition of 'pi' provided in TrigFunctions::pi (KerML) also includes an invariant that specifies PI to 20 significant digits.
However, in SI.sysml where we define 'degree', the conversion factor is listed as:
attribute <'°'> degree : AngularMeasureUnit { :>> unitConversion: ConversionByConvention { :>> referenceUnit = rad; :>> conversionFactor = 1.745329E-02; :>> isExact = false; } } // conversionFactor should become pi/180
It appears that this was intended to be a "TODO" that was never addressed!
Having the conversion factor from degrees to radians only listed to "single precision" will be a severe problem for many engineering applications. We should instead depend on the actual "pi/180" expression as stated in the trailing comment
As part of the Users WG in coordination with Execution WG, we have determined that successions from the "start" of a state or the "entryAction" of the state can cause confusion for many users. As such, we want to "deprecate" this usage in favor of requiring an explicit state transition from "start" to the first subState.
We will need to update all of our relevant graphical and textual examples shown in the spec to demonstrate this preferred approach and remove the previous approach.
Models using successions from "start" or "entryAction" will remain valid but will not be the preferred method. We will want to indicate that support for such may be removed in some future version, subject to a discussion around what the deprecation policy should be.
The textual notation production AnnotatingMember in 8.2.2.4.1 Annotations is used in the special syntax for EnumerationBody to allow the bodies of EnumerationDefinitions included AnnotatingElements as members. However, AnnotatingMember does not include the MemberPrefix that allows for visibility to be specified for a normal DefinitionMember. This means that AnnotatingElements in EnumerationBodies cannot currently have any visibility other than public, even though there is no such restriction in the abstract syntax.
According to the specification, items can own actions and parts can perform actions.
However, the feature "ownedActions" is owned by the library element Part and not Item. The feature "performedActions" is also owned by Part which is correct.
In the following sentence, the word "enumerationDefinition" should be "EnumerationDefinition".
"However, other than when nested in an EnumerationDefinition, an EnumerationUsage is semantically just an AttributeUsage that is required to be typed by exactly one EnumerationDefinition (syntactically enforced by the 1..1 multiplicity of EnumerationUsage::enumerationDefinition, see 8.3.8 )."
It's likely that OrderedContainer is supposed to specialized Container, such that orderedContent can redefine content.
abstract part def Container
{ abstract ref content : Base::Anything; }part def OrderedContainer
{ // By default, the following is a reference usage. orderedContent ordered :>> content; }When discussing verdicts "The result of the validation case is a verdict..." should this be "The result of the verification case is a verdict..."?
Currently the BNF requires a separate flow symbol for every flow that transpires over a connection (or an interface).
It is requested to also support a more compact notation, that each flow symbol can represent multiple flow usages specified in a comma separated list.
In SysML section 7.17.9 (BETA 4) - Assignment Action Usages, the code comment in the textual example is inconsistent with the language in the English.
The English says:
"An AssignmentAction sets a referent feature of a target occurrence to a new assigned value."
But the code comment says:
action def UpdateVehiclePosition {
in part sim : Simulation;
in attribute deltaT : TimeDurationValue;
// The target of the assignment below is "sim".
// The referent feature chain is "vehicle.position".
assign sim.vehicle.position :=
sim.vehicle.position + sim.vehicle.velocity * deltaT;
// After the above assignment "sim.vehicle.position" has the
// value of the result of the assigned value expression,
// evaluated at the time of the assignment.
}
The comment should probably identify "position" as the referent (not "vehicle.position" ! ) and "sim.vehicle" as the target, since "vehicle" features "position" ("sim" does NOT feature "position" and therefore "sim" cannot be the target).
Consistent with the 'var' feature being featured by "vehicle" and not "sim", I would expect "sim.vehicle" to declare the occurrence for the purposes of the assignment. Otherwise, using "sim" as the occurrence would require more complex semantics involving the 'var' behavior of an intermediate occurrence as part of the assignment action, which is unnecessary.
Due to the problem identified in KERML11-72, a state usage that is a substate may end up inheriting two different redefinitions of Occurrence::Occurrence::this, but both with the name this, resulting in a violation of the constraint validateNamespaceDistinguishibility.
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.
The constraint checkActionUsageSubactionSpecialization checks that the operation isSubactionUsage is true before requiring that an ActionUsage specialize Actions::Action::subactions. The operation isSubactionUsage not only checks the ActionUsage is composite and has an owningType that is an ActionDefinition or ActionUsage, but also ensures that the ActionUsage is not an entry or exit action. Various subclasses of ActionUsage have semantic constraints that require more specific specializations of subactions but do not include the condition that the usage is not an entry or exit action:
The semantic constraint checkRequirementUsageObjectiveRedefinition 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.
But this doesn't handle the case in which the owningType may be specialized by a feature chain whose featureTarget is a CaseUsage.
Performed By Compartment is empty needs to be removed or filled
Actions::AcceptAction descriptions differ between Standard and Standard Library
Actions::DecisionAction descriptions are different are different than in their library files
action-def-name-compartment =
'«' DefinitionPrefix 'action' 'def' '»'
definition-name-with-alias<
don't think the ending < should be there
Actions::DecisionTransitionAction has different descriptions
"has a single guard" in standard vs "has a guard" in standard file
Actions::acceptActions descriptions are different between Standard and Standard Library File
acceptActions is the base feature for all SendActionUsages.
vs
acceptActions is the base feature for standalone AcceptActionUsages
Actions::TerminateAction documentation is not coordinated between section 9.2.10.2.24 and the library files
Actions::SendAction descriptions not the same as
in the Library file
Actions::AcceptMessageAction has different descriptions than
is in the library
Actions::MergeAction descriptions are different than in the system library file
Verified
Requirements
Compartment
is empty need to be filled or removed
confirm state-actions-compartment is "states" not "state actions"
viewpointConformance is not defined in the standard library
should be stubbed out...
abstract view def View :> Part {
...
viewpoint viewpointSatisfactions : ViewpointCheck[0..*] :> viewpointChecks, checkedConstraints
satisfy requirement viewpointConformance by that
}
Compartment in Table 13 says "allocated"...
allocations-compartment has the marker called "allocations"
I think one of these need to be changed
in interfaces.sysml
end port source: Port :>> BinaryConnection::source;
end port target: Port :>> BinaryConnection::target;
but 9.2.7.2.1 BinaryInterface has
source : Port [0..*]
{redefines source}target : Port
{redefines target}so one of these sources is wrong
Don't think we need
validateObjectiveMembershipIsComposite
it is composite in the metamodel
Cases can be used "in its own right"... there needs to be a graphical notation for Cases
the standard alludes to
validatePortDefinitionNestedUsagesNotComposite requires that all nestedUsages of the
PortDefinition that are not PortUsages are referential (non-composite).
but no OCL definition of
validatePortDefinitionNestedUsagesNotComposite
is in the standard
the standard alludes to
validatePortDefinitionNestedUsagesNotComposite requires that all nestedUsages of the
PortDefinition that are not PortUsages are referential (non-composite).
but no OCL definition of
validatePortDefinitionNestedUsagesNotComposite
is in the standard
checkPartUsageStakeholderSpecialization
wording should be
If a PartUsage is owned via a StakeholderMembership, then it must directly or indirectly specialize Requirements::RequirementCheck::stakeholders.
i.e. remove the word "either"
/conjugatedPortDefinition : ConjugatedPortDefinition [0..1]
{subsets ownedMember}The that is conjugate to this PortDefinition.
should be
The ConjugatedPortDefinition that is conjugate to this PortDefinition.
checkPartUsageStakeholderSpecialization
wording should be
If a PartUsage is owned via a StakeholderMembership, then it must directly or indirectly specialize Requirements::RequirementCheck::stakeholders.
i.e. remove the word "either"
An item may have attributes (see 7.7 ), states (see 7.18 ), and nested item usages
I agree items should be able to have states (e.g. Document has states "underReview", "Reviewed")...
but
exhibitedStates : StateAction [0..*]
ownedStates : StateAction [0..*]
{subsets ownedActions}are in Parts (not in Item) ... is this wrong??
An item may have attributes (see 7.7 ), states (see 7.18 ), and nested item usages
I agree items should be able to have states (e.g. Document has states "underReview", "Reviewed")...
but
exhibitedStates : StateAction [0..*]
ownedStates : StateAction [0..*]
{subsets ownedActions}are in Parts (not in Item) ... is this wrong??
validateUsageVariationMembership is missing a OCL statement
checkItemUsageSubitemSpecialization should have description
An ItemUsage that is composite and has an owningType that is an ItemDefinition or ItemUsage must specialize the System model Library ItemUsage Items::Item::subitems
should sunroof be multiplicity 0..1? for optional?... or is this another way to show optional (but not stated in the standard)..
sunroof does not have any variants... that simply means model is not yet concrete?
Change ItemUsage is a ItemUsage to ItemUsage is an OccurenceUsage
on a EnumerationDefinition we want isVariation=true and readonly (should not be allowed to be changed
Subclause 7.27 shows a metadata node attached to a usage with a dotted connector. This is not supported by the GBNF. metadata-feature-annotation-node defined in subclause 8.2.3.27 should be included with the annotation-node production in subclause 8.2.3.4.
Graphical BNF does not allow a metadata compartment.
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".
The OCL for the constraint checkDecisionNodeOutgoingSuccessionSpecialization references the library element ControlPerformances::MergePerformance::outgoingHBLink, but the correct qualified name is ControlPerformances::DecisionPerformance::outgoingHBLink
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.
In the description and OCL for the constraint checkViewpointDefinitionSpecialization, Views::Viewpoint should be replaced with Views::ViewpointCheck. In the description and OCL for the constraint checkViewpointUsageSpecialization, Views::viewpoints should be replaced with Views::viewpointChecks.
The namingFeature of a RenderingUsage that is a viewRendering (i.e., owned via a ViewRenderingMembership) should be the referencedRendering of the owning ViewRenderingMembership.
The constraint checkRequirementUsageSubrequirementSpecialization requires that a composite RequirementUsage whose ownedType is a RequirementDefinition or RequirementUsage specialize RequirementCheck::subrequirements. However, RequirementCheck::subrequirements subsets RequirementCheck::constraints, which is the set of required constraints of the requirement. So it doesn't make sense for a RequirementUsage to specialize subrequirements if it is owned as an assumed constraint.
The constraint checkIncludeUseCaseSpecialization should be named checkIncludeUseCaseUsageSpecialization.
In 8.2.2.17.4 Send and Accept Action Usages, the payload parameter of an AcceptActionUsage is parsed as being owned by a ParameterMembership. This requires that the parameter have the direction in (see 8.3.4.6.4). However, the payload parameter of the base library definition Actions::Action has the direction inout. While it is valid to redefine an inout parameter with an in parameter, it is generally the output payload value that is desired from an accept action. Therefore, the payload parameter of an AcceptActionUsage should also have direction inout.
The graphical notation for allocating a flow to a connection, that is consistent with textual notation, is missing.
This should be added.
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".
It is possible to define flow 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. PayloadFeature is created for the first/nice/short case while simple ReferenceUsage is created for the full/complete case.
It seems that PayloadFeature (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.
The second problem could perhaps be solved by e.g. changing the definition of the payloadFeature property in the abstract syntax to be the feature that specializes `Transfer::payload`, whether or not it is owned or inherited, and whether or not it is a PayloadFeature. The derivation would not be as simple as the current one, but it would be a reasonable suggestion.
In current implementation each FlowUsage owned by PartUsage subsets (automatically) 3 features:
This could be optimized for the sake of model size. Maybe it would be better idea to introduce
Part::Part::ownedFlows :> ownedActions, subparts, flows
and define something like CheckFlowConnectionSubFlowSpecialization constraint?
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).
in the graphical notation for states the compartment name is
"exhibit states" ... yet in the example in
table 17
there is exhibits and exhibitedBy
is this a mistake?
1. The perform-actions-swimlanes production does not appear to be used anywhere.
2. The swimlane production only appears to support vertical swimlanes. i.e., with the action flow displayed below the head rather than to the right of it. Horizontal swimlanes should also be supported.
3. There is no production for the <<performer>> keyword in the head of a swimlane. The appropriate production appears to be Usage-name-compartment (which is missing, as was noted in SYSML21-251), but this name should probably be changed to be more specific to this usage, e.g., swimlane-name-compartment or performer-name-compartment to be consistent with the names of other similar productions.
4. The note "Note. All swimlanes are attached to each other on vertical edges and aligned along the top and bottom horizontal edges." in 8.2.3.17 does not appear to be followed by the examples of swimlanes that appear in Table 15.
5. The swimlanes production have squared (right-angled) corners, but rounded corners appear in the examples in Table 15.
There is no rule that maps a property typed by a Signal. It should be mapped to an item usage.
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.
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.
Although deprecated, FlowSpecifications are still part of SysML v1 and there should be a defined mapping for the element.
Although deprecated, FlowPorts are still part of SysML v1 and there should be a defined mapping for the element.
The mapping of a ProfileApplication is not covered by the transformation.
ConnectorProperty is deprecated but still part of SysML v1.7. So, the transformation should provide a mapping for it.
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.
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.
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.
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.
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;
}
}
A ConnectionPointReference is mapped to a StateUsage. In addition, the state usage shoud redefine the corresponding pseudostate.
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.
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.
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.
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.
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.
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.
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
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.
An Operation should not be mapped to perform action, but an owned action.
As mentioned in section "7.7.2.3.7.20 ClearStructuralFeatureAction_Mapping": The details of the mapping are not defined yet.
As mentioned in section "7.7.2.3.7.34 RemoveStructuralFeatureValueAction_Mapping": The details of
the mapping are not defined yet.
The mapping AddStructuralFeatureValueAction ignores the names of the input and output pins and uses the names defined in the SysMLv1Library::AddStructuralFeatureValueAction element.
Both Enumeration and ValueType have main mappings and their specified filters do prevent a double match
In some cases (e.g. MIWG test case #11) it is unable to compute the requested type.
The current specification is not computable in some cases (where the "any" OCL iterator find no value). E.g. : MIWG Test Case#27
As a consequence SysMLv literals generated by the transformation have no value defined
Duplicated operations can be removed by adding a common abstract root class. This will simplify the model and ease the maintenance
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
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
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
The MWIG test case #8 fails because it contains a property that is typed by an Actor while the transformations currently defined do not support it
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
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
The body condition specified for this operation is wrong. It should be an empty set.
Comment_Mapping is missing a default rule locale
GenericToStateUsage_Mapping is missing a default rule for isParallel
GenericToRequirementUsage_Mapping is missing a default rule for reqId
The redefinition of ownedRelationship() is missing the "class" part, i.e. what is defined in its Class aspect
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.
A UML4SysML::ConstraintProperty is currently mapped to a ItemUsage, but should be an AssertConstraintUsage.
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.
The mapping of ObjectFlow in combination with DecisionNodes including the decisionInput is not covered yet by the transformation.
The mapping of a Unit and a QuantityKind is not covered by the transformation yet.
The transformation does not map the Parameter::isStreaming.
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.
The transformation does not specify mapping rules for UML4SysML::FunctionBehavior.
Currently, the transformation supports only AcceptEventActions with one trigger, but it could be many.
The transformation does not specify mapping rules for UML4SysML::DestroyLinkAction.
The transformation does not specify mapping rules for UML4SysML::CreateLinkAction.
The transformation does not specify mapping rules for UML4SysML::ReadLinkAction.
The mapping of a UML4SysML::InterruptibleActivityRegion is not covered by the transformation rules.
The transformation generally maps a PseudoState, but does not distinguish between the different kinds of pseudostates.
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".
The transformation does not specify mapping rules for SysMLv1::NoBuffer.
The transformation does not specify mapping rules for SysMLv1::Overwrite.
The transformation does not specify mapping rules for SysMLv1::AllocateActivityPartition.
The transformation does not specify mapping rules for SysMLv1::PropertySpecificType.
The transformation does not specify mapping rules for SysMLv1::EndPathMultiplicity.
The transformation does not specify mapping rules for SysMLv1::ParticipantProperty.
The transformation does not specify mapping rules for SysMLv1::BoundReference.
The transformation does not specify mapping rules for SysMLv1::DistributedProperty.
The transformation does not specify mapping rules for SysMLv1::Expose.
The transformation does not specify mapping rules for SysMLv1::Conform.
The transformation does not specify mapping rules for SysMLv1::View.
The transformation does not specify mapping rules for SysMLv1::InvocationOnNestedPortAction.
The transformation does not specify mapping rules for SysMLv1::AddFlowPropertyValueOnNestedPortAction.
The transformation does not specify mapping rules for SysMLv1::ChangeStructuralFeatureEvent.
The transformation does not specify mapping rules for SysMLv1::TriggerOnNestedPort.
The transformation does not specify mapping rules for UML4SysML::UnmarshallAction.
The transformation does not specify mapping rules for UML4SysML::LinkEndData.
The transformation does not specify mapping rules for UML4SysML::LinkEndDestructionData.
The transformation does not specify mapping rules for UML4SysML::LinkEndCreationData.
The transformation does not specify mapping rules for UML4SysML::ConditionalNode.
The transformation does not specify mapping rules for UML4SysML::Clause.
The transformation does not specify mapping rules for UML4SysML::ActivityPartition.
The transformation does not specify mapping rules for UML4SysML::InteractionConstraint.
The transformation does not specify mapping rules for UML4SysML::OccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::Gate.
The transformation does not specify mapping rules for UML4SysML::ExecutionOccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::ConsiderIgnoreFragment.
The transformation does not specify mapping rules for UML4SysML::PartDecomposition.
The transformation does not specify mapping rules for UML4SysML::GeneralOrdering.
The transformation does not specify mapping rules for UML4SysML::Continuation.
The transformation does not specify mapping rules for UML4SysML::DestructionOccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::Image.
The transformation does not specify mapping rules for UML4SysML::Interval.
The transformation does not specify mapping rules for UML4SysML::TimeConstraint.
The transformation does not specify mapping rules for UML4SysML::DurationInterval.
The transformation does not specify mapping rules for UML4SysML::StringExpression.
The transformation does not specify mapping rules for UML4SysML::DurationObservation.
The transformation does not specify mapping rules for UML4SysML::IntervalConstraint.
The transformation does not specify mapping rules for UML4SysML::TimeObservation.
The transformation does not specify mapping rules for UML4SysML::Duration.
The transformation does not specify mapping rules for UML4SysML::DurationConstraint.
The transformation does not specify mapping rules for UML4SysML::TimeInterval.
The extend relationship between use cases is not covered by the transformation.
The details of the mapping of UML4SysML::DataStoreNode and UML4SysML::CentralBufferNode are not specified.
The transformation does not include a mapping for UML4SysML::GeneralizationSet.
The transformation does not consider the property UML4SysML::RemoveVariableValueAction::isRemoveDuplicates.
In section 7.3.2.3 of the KerML specification, the statement is made that, "Specializations are relationships between types, identified as specific and general, indicating that all instances of the specific type are instances of the general one...." This statement, or a similar one conveying the same idea, is absent from the SysML v2 specification. Instead, the treatment of specialization in section 7.6.1 of the SysML v2 specification focuses entirely on inheritance of features. The SysML v2 specification should clarify that specialization also conveys the semantics of subtyping, as is described in the KerML specification. This concept is really foundational to object oriented modeling (and ontology), even more essential in modeling than it is in object oriented programming.
The specification also would be strengthened by including explicit examples of the implications of subtyping within a model, e.g.,
1. In 7.12.1, the statement is made that "Two features match if they have conforming definitions and either both have no direction or they have conjugate directions," but there is no explanation in the SysML v2 specification as to what it means to conform. If A specializes B, then would an in port defined by B match with an out port defined by A? It should, since an in port defined by B, which therefore expects to receive payloads having a specification compatible with the specification of B, should be able to accept a payload defined by A.
2. In 7.21.1, the statement is made that, "A requirement usage can only be satisfied by an entity that conforms to the definition of its subject," but there is no explanation in the SysML v2 specification as to what it means to conform. If the requirement usage specifies a subject defined by B, and A specializes B, then would a subject defined by A be sufficient to satisfy that requirement for satisfaction? It should, since any A is also a B.
These are two examples, among many, where such clarifications of the semantics of subtyping and their implications on SysML v2 models should be addressed in Clause 7 of the SysML v2 specification to ensure model users and modeling tool developers have consistent expectations of the semantics of specialization.
In the Systems Library model States, in the body of StateAction, the usages entryAction, doAction and exitAction are respectively declared as entry, do and exit action usages. However, according to constraint validateActionUsageStateActionRedefinition, this means that these usages a required to directly redefine themselves, which doesn't make sense.
Annotations and successions are consistently represented with short dashes in both the graphical examples in Clause 7 and the graphical BNF. However, the specification does not consistently depict the dashed lines that are used in dependencies and related relationships.
DEPENDENCIES:
Table 1 "Dependency" - long dashes
Table 1 "Dependency - nary" - medium dashes
8.2.3.3 binary-dependency - short dashes
8.2.3.3 n-ary-dependency-*-link - short dashes
IMPORTS:
Table 3 "Import (recursive) - short dashes
8.2.3.5 import - long dashes
EXPOSE:
Table 24 "Expose" - long dashes
8.2.3.26 expose_r and *-expose-r - short dashes
Recommend the graphical BNF and graphical examples in the tables be made consistent in showing these relationships as having long dashes. This will help users to distinguish these types of relationships from those having short dashes, e.g., successions and annotations, and would be more familiar to users having experience with UML, SysML v1, etc.
The textual notation of single-line (//) and multiline (/** */) notes does not appear to be documented in either the SysML v2 or KerML specifications. These are described in the Intro to the SysML v2 Language - Textual Notation slide deck, are used extensively in example models throughout both specs, and appear in the BNF in 8.2.2.2 of the KerML Spec Beta 2.4. However, their intended use and semantics are not described anywhere in either spec. It should be important to state in the spec(s) that these notes are intended to not be part of the model, if this is still true.
[From Dr. Charles Manion] Item::iSSolid cannot be specified by redefinition because it is given a bound value. It's common in my applications to specify that an item is solid or not (in that typical terminology) without specifying how many voids are present or not.
The specification does not define how to show filter conditions at an import relationship, and it also does not define a compartment for packages for owned filter conditions.
The Quantities and Units Domain Library model Time.sysml contains attribute definitions for ISO 8601 date/time string encodings and structures. However, the model could be improved by adding additional constraints to ensure these definitions are used properly:
scalarQuantities is defined as nonunique. However some of its subsets are not. They probably should be nonunique.
Examples:
width, height or gaugePressure
Also many don't have multiplicity [*]. As far as I know, this would not be necessary, because it is the default for attributes defined at package level anyway. However, length and scalarQuantities itself do have an explicit multiplicity. I guess it should be consistent.
In 'Table 3. Packages - Representative Notation', there is a 'Package with owned package' graphical example where the owned package is displayed but as text rather than as a node.
Should this example be removed, or should the 'general-view' element be updated to include node representation in text?
The following cosmetic changes are needed for some graphical examples displayed in the tables:
There is an inconsistency between Table 3. Packages - Representative Notation (specifically the Package with imported package (nested notation) element) and the Graphical BNF. In section 8.2.3.5 Namespaces and Packages Graphical Notation, it is specified that the Package shape should not display any keywords above its name when it is imported. However, in the table example, the visibility indicator keyword is visible.
There is an inconsistency in the Table 4. Definition and Usage - Representative Notation table (specifically the Name Compartment - Definition element).
In this example, the abstract keyword is omitted from the symbol keyword («part def»), whereas in other examples, the abstract keyword is displayed when usage/definition is shown as a shape.
Does this imply that additional property keywords are optional for display in the shape?
In the Graphical BNF, the only usages that lack the 'compartment-stack' section are the send and accept action usages. Is this intentional, meaning these actions cannot have compartments?
In section 8.2.3.12 of the Ports Graphical Notation, ports displayed as shapes have only a solid border, whereas ports on the border of another shape may also have a dashed border, as noted:
"Dotted line port productions (references) are only possible for nested ports."
This implies that a nested port can be displayed on another port with a dashed border. However, based on the BNF, the same nested port cannot be displayed with a dashed border when shown as a regular shape.
In section 8.2.3 of the Graphical Notation for packages, it is stated that no keyword should be displayed before the name.
Our concern is that without a keyword, it will not be possible to differentiate a library package from a standard package within the diagram.
There is an inconsistency between the examples in the following tables and the Graphical BNF:
There is an inconsistency between the examples in the following tables and the Graphical BNF:
There are inconsistencies between table examples and the Graphical BNF due to compartments being displayed that are not specified in the BNF:
There is an inconsistency between Table 14. Actions - Representative Notation (specifically the Actions with Control Nodes element) and the Graphical BNF.
In this example, the control nodes (join, fork, decision, and merge nodes) have names displayed in the diagram. However, the Graphical BNF (section 8.2.3.16 Actions Graphical Notation) does not specify that names can be displayed for these nodes.
There is an inconsistency between the table examples and the Graphical BNF (section 8.2.3.13):
There is an inconsistency between Table 19. Requirements - Representative Notation (specifically the 'Requirement' element) and the Graphical BNF (section 8.2.3.4).
In the table example, the 'doc' compartment is labeled as 'documentation,' which is incorrect according to the BNF. The label should be 'doc.'
There is an inconsistency between Table 18. Constraints - Representative Notation (specifically the 'Constraints Compartment' element) and the Graphical BNF (section 8.2.3.19).
In the example, the keywords 'require', 'assume', and 'assert' are displayed before the constraint name. These keywords are only defined under 'AssertConstraintUsage' (for 'assert') and 'RequirementKind' (for 'assume' and 'require'). However, these elements are not included within the 'constraints-usage-compartment-element' specification.
There are inconsistencies between the examples in Table 12. Interfaces - Representative Notation (specifically the 'Interface as Node' and 'Interface as Node (with flow)' elements) and the Graphical BNF (section 8.2.3.14).
In these examples, nested shapes are displayed without a compartment. However, the BNF does not specify that a general view or interconnection view is applicable for interface usage.
There is an inconsistency between Table 14. Actions - Representative Notation (specifically the 'Parameters Compartment' element) and the Graphical BNF.
In the table, the 'return' keyword is displayed before the name of the 'param4' feature. However, the 'return' keyword is specified under the 'ReturnParameterMember' element, which is not included in the 'parameters-compartment-element' specification. As a result, based on the BNF, the 'return' keyword should not appear in the parameters compartment.
There are several examples where the 'doc' keyword is displayed in the 'objective' compartment:
There is an inconsistency between Table 23. Views and Viewpoints - Representative Notation (specifically the 'Frame' element) and the Graphical BNF in section 8.2.3.20.
In the table, the 'frame' relationship connects a viewpoint to concern usages. However, the BNF specification for the 'frame' relationship does not include viewpoint usage as one of the possible relationship ends, as it has 'subject-actors-stakeholders-node' for one end and 'concern' for another.
The 'subject-actors-stakeholders-node' includes:
In the following tables, examples display port/parameter labels on the border as being inside the context:
However, according to the BNF specification, labels for ports and parameters on the border should be positioned outside the context.
In Table 4. Definition and Usage - Representative Notation, the 'Name Compartment - Definition (abstract)' element displays the usage as abstract, with its name in italic font. However, other examples with abstract usages/definitions, such as 'Name Compartment - Definition' and 'Name Compartment - Usage (abstract)', do not display their names in italic font.
Additional properties that are specified under UsagePrefix/OccurrencePrefix element are missing for these usages inside the «» :
In Table 16. States - Representative Notation, the "State with entry, do, and exit actions" element includes an 'actions' compartment, where the entry, do, and exit actions are displayed.
However, in the 8.2.3.17 States Graphical Notation section, it is specified that the only compartment permitted to display the entry, do, and exit keywords is named 'states', creating a discrepancy between the table and the section.
The Swimlane element is described in the specification as containing two elements: Usage-name-compartment and action-flow-node. However, several issues arise with this definition:
The issues regarding the Swimlane:
action-flow-node = start-node | done-node | fork-node | join-node | decision-node | merge-node | send-action-node | accept-action-node | while-loop-action-node | for-loop-action-node | if-else-action-node | assign-action-node
In the Table 25. Metadata - Representative Notation (Chapter 7.26.1 , page 151) table there is an element that specifies the metadata compartment, however, this compartment is not specified in the Graphical BNF.
In the Table 19. Requirements - Representative Notation table in the Satisfy Requirements Compartment element a lot of information is displayed:
satisfy-requirements-compartment-contents = text-block
In the graphical BNF the short usage name notations are not specified as well duplicated usage keywords are possible. For these usages, the issues occurs:
For ports and parameters on border, connectors and transitions name label there is no indication to display an inheritance symbol.
The el-prefix is not indicated in none of these element specifications.
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).
All feature redefinitions specified in the transformation model, whether they affect properties or operations, should appear in the specification document
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.
proxy connection in sequence views should be contextualized on lifelines.
Right now they just float as nodes.
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)?
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;
}
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'
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.
These issues reported by Dovile.ZIAUKIENE from Dassault.
See 2 attachments.
1. Name compartment of a package does not support guilements modifiers
2. Unowned member alias notation
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.
In subclause 7.20.1, Table 19, example "Requirement" the compartment labels "require constraints" and "assume constraints" and their content are misleading and inconsistent.
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.
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
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.
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.
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".
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”
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
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?
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
This seems an odd choice and at least needs more explanation of how the various features of part definitions, like ports, are used
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.
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
}
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.
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.
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.
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.
in SysML v1 a RedefinableElement can have a isLeaf:Boolean... this concept seems to be missing in SysMLv2
a classifier in SysML v1 can have isFinalSpecialization:Boolean ... that concept is missing in SysML v2
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.
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
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).
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.
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.)
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!
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.
State shall be able to have proxy nodes on their boundaries. Currently not covered by the GBNF
The general 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.)
[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;
}
The following cases in the textual notation allow "shorthand" then notations for SuccessionAsUsages:
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.
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.
GenericToElement_Mapping is missing default rules for:
GenericToRelationship_Mapping should provide default rules for
A graphical BNF production should be added that specifies that keywords may optionally be included on edges.
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.
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.
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
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.
To provide guidance for users on common formatting
example:
requirement def SomeRequirement
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
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.
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.
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.
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.
Add feature modifiers (e.g. ordered for [1..*] timestamps) to "Portion Membership" examples in representative notation tables for Occurrences.
Add feature modifiers (e.g. ordered, nonunique) to "Feature Membership" examples in representative notation tables for Definitions and Usage.
Add import qualifier text (* or **) to upper right corner of imported Package
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.
In the param-t production the nesting parameter pdv is missing an optional nested param-t* element.
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.
Clarify that the identifier for the metadata declaration is the metadata definition name.
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.
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.
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.
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.
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.
In 7.15.1 Allocations Overview, Table 17, entry for "Allocation (with sub allocation)", the name acton1 in the graphical notation should be action1.
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.
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.
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.:
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.
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.
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).
There is no Graphical BNF for grid rendering, required by the Grid View Standard View Definition.
This should be added.
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.
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.
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).
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.
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.
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).
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.
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.
How a view/query is performed when using a view as an input mode is unspecified.
This should be clarified and added.
Identify the implications of views on the model organization and how to mitigate circular dependencies.
Approaches to representing 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
Add standardized element icons and standard view definition icons as they should appear in a browser or on diagrams.
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.
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.
in
interfaces.sysml
end port source: Port :>> BinaryConnection::source;
end port target: Port :>> BinaryConnection::target;
but 9.2.7.2.1 BinaryInterface has
source : Port [0..*]
{redefines source}target : Port
{redefines target}so one of these sources is wrong
checkRenderingUsageSpecialization requires that a RenderingUsage specialize the base
RenderingUsage Views::rendering (see 9.2.19.2.7 ).
need Views::renderings (with an "s")
The OCL for thee validateAssignmentActionUsage constraint is
referent <> null implies referent.featureTarget.mayTimeVary
However, referent.featureTarget has the type Feature, not Usage, so mayTimeVary is not defined for it. Instead, isVariable should be used.
Currently flow connections can be connected to control nodes such as decision/merge/fork/join using parameters, and the behavior needs to be explicitly specified like in any action. This is a limitation comparing to UML that allowed flows to be seamlessly connected to control nodes with proper semantics to cover such connections. In SysML V2 the current approach is to specify parameters on control nodes to handle this. There are two main issues here:
The expectation is to provide proper semantics to connect flow connections similar to UML/V1, and keep the graphical symbols "atomic" without having to add compartments or parameters, at least for "default" use cases
The constraint validateAssignmentActionUsageReferent is described as
An AssignmentActionUsage must have an ownedMembership that is not an OwningMembership and whose memberElement is a Feature.
This is intended to support the derivation of AssignmentActionUsage::referent, however, the constraint deriveAssignmentActionUsageReferent is
The referent of an AssignmentActionUsage is the first Feature that is the memberElement of a ownedMembership that is not a FeatureMembership.
Note that the derivation only excludes FeatureMembershps, not all OwningMemberships. Indead, a referent that is a feature chain will be owned by the AssignmentActionUsage using an OwningMembership.
The constraints validateAttributeDefinitionFeatures and validateAttributeUsageFeatures require that all the features of an attribute definition or usage be referential (non-composite). However, there are a number of models in Domain Libraries that declare attribute definitions or usages with composite features.
1. In subclause 7.8.1, Table 6 "Enumerations", first example row "Enumeration Definition", the graphical notation has two mistakes: in both enumeration definition symbols the label within guillemets should read «enum def» instead of «enumeration def», as specified in the Graphical BNF per subclause 8.2.3.8.
2. In subclause 8.2.3.8 three corrections on graphical BNF productions are needed:
Currently, the compartment names for While Loop, For Loop and If-Else actions differ slightly from their corresponding action names:
• Loop Body is used for the body action in While and For loop actions.
• Then Body is used for the thenClause action in If-Else actions.
• Else Body is used for the elseClause action in If-Else actions.
We understand that these names are intended to enhance user-friendliness. However, since body, thenClause, and elseClause actions can also be visible in the feature chain, aligning the compartment names with their exact action names could improve clarity and maintain consistency across the model.
The resolution to SYSML2_-417 was supposed to change all uses of "FlowConnection" in names to "Flow". However some changes were missed.
There are two productions for calc-name-compartment, not labeled as partial.
Also, there is no specific production for the result of a calculation other than in a compartment. Should the result parameter of a calculation be graphically depicted in the same manner as an out parameter on an action would?
Recommend adding an example to Table 18 to clarify the expected notation for in and result parameters.
Currently name compartment keywords are pulled via DefinitionPrefix, which does not include 'variant'. Textual syntax introduces variant via a special VariantUsageMember production.
GBNF needs to explicitly add ability to use 'variant' keyword for all usage nodes
1. The reserved keywords of SysML are the following.
The following keywords (in the Beta 3 document I have downloaded) I believe are missing: constant, effect, feature, locale, meta, and new,
In the constraint deriveSatisfyRequirementUsageSatisfyingFeature, in the if condition, the subexpression
bindings->first().relatedElement->exits(r | r <> subjectParameter)
should be
not bindings->first().relatedElement->exists(r | r <> subjectParameter)
The constraint checkSatisfyRequirementUsageBindingConnector requires that "A SatisfyRequirementUsage must have exactly one ownedMember that is a BindingConnector between its subjectParameter and some Feature other than the subjectParameter." However, in the textual notation for a SatisfyRequirementUsage, a *by* is parsed as a FeatureValue binding from the owned subject of the SatisfyRequirmntUsage to the *by* clause Expression (see 8.2.2.21.2 Requirement Usages). But the implied BindingConnector for a FeatureValue will then be owned by the subject parameter, not by the SatisfyRequirementUsage, so the checkSatisfyRequirementUsageBindingConnector constraint will be violated.
The production for usage-node appears to have a typo: "occurrence-refxfx" should probably be "occurrence-ref"
The resolution to SYSML2_-248 changed the name of the fn parameter of TradeStudies::TradeStudyObjective and its specializations to eval. However, invocations of this parameter in the bodies of MaximizeObjective and MinimizeObjective where not correspondingly updated in the full textual notation in file TradeStudies.sysml.
According to 8.4.16.2 Constraint Usages, "checkConstraintUsageCheckedConstraintSpecialization requires that a composite ConstraintUsage whose owningType is an ItemDefinition or an ItemUsage...specialize the ConstraintUsage Items::Item::checkedConstraints...". However, the definition of checkConstraintUsageCheckedConstraintSpecialization in 8.3.20.4 does not actually test if the ConstraintUsage is composite.
Add to the row names more detail that indicates that one is part def - part feature membership and one is part - part feature membership.
This issue is with v2 Beta 4.
In the following textual notation, vehicle does not have a drives occurrence. Later in the notation, the message sequence references a vehicle.drives feature, which is erroneous.
use case def 'Provide Transportation' {
subject vehicle : Vehicle
actor driver : Person
{ event occurrence entersVehicle [1]; then event occurrence exitsVehicle [1]; }actor environment : Environment
{ event occurrence vehicleDrives [1]; }objective
{ doc /* Transport driver and passengers from starting location * to ending location. */ }message of Enter from driver.entersVehicle to vehicle.driverEnters;
then message of Enter from passengers.entersVehicle to vehicle.passengerEnters;
then message of Drive from vehicle.drives to environment.vehicleDrives;
then message of Exit from passengers.exitsVehicle to vehicle.passengerExits;
then message of Exit from driver.exitsVehicle to vehicle.driverExits;
}
In the Systems Library model Interfaces, the Interface::participant feature is declared as a port usage. However, the semantic constraint checkPortUsageOwnedPortSpecialization then requires that the feature subset ownedPorts. But ownedPorts is unique, will participant has to be non-unique, which violates the constraint validateSubsettingUniquenessConformance.
The feature Interface::participant should thus not subset ownedPorts. Indeed, an Interface is supposed to be a Connection between the ownedPorts of other parts, so its participants shouldn't be considered ownedPorts of the Interface itself, anyway.
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?
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.
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'?
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)
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.
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)
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?
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.
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.
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
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."
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
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.
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.
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
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.
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.
I found a bunch of issues, mostly unresolved references, in the SysML 1.7 XMI files.
1) In SysML.xmi:
2) In QUDV.xmi:
3) In ISO8000.xmi (which should be ISO80000.xmi):
Note: I've been using HTTPS links for URLs, since HTTP links are no longer accessible using the browser and are not the official URLs defined in the UML spec... although they are used in the UML and SysML 1.6 XMI.
Duplicate of SYSML17-222 for which the resolution does not resolve anything!
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.
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.
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.
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.
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.
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
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.
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?
2_specializations_are_constraintblocks in FeatureDirectionKind should belong to 10.3.2.1 ConstraintBlock。
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
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.
The comments in the XMI that specify the documentation of the stereotypes and stereotype attributes do not annotate the elements they document.
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:
If it is not correct:
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.
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
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.
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.
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.
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
There are issues in the referenced sections
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.
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
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.
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
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"
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.
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..*]
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
getKindOfQuantitiesForMeasurementUnit should be renamed getQuantityKindsForMeasurementUnit
inv SoU3_3: getEffectiveSystemOfQuantities() = null or let aqk : Set(QuantityKind) = getEffectiveSystemOfQuantities().allQuantityKinds() in ->allUnits() ->forAll(u | aqk>includesAll (getKindOfQuantitiesForMeasurementUnit(u)))
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
OCL with SpecializedQuantityKind needs to be changed
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)))
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.
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.
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
The operation SystemOfUnits::isCoherent() and the figure E.8 uses a property "primaryQuantityKind" which is not defined in E.5.
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)
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).
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.)
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
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>
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.
Figure E-7: QUDV QuantityKinds has the following issues:
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...
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.
orderedMember in ElementGroup should be
{ordered}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
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.
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
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:
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.
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.'
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"
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.'
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)
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.
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
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 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:
The annotated attachment shows an attempt at improving it (but is not offered as a resolution figure).
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
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
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...
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
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 [*]
now block z specializes block x and I have another property a such that
<<endPathMultiplicity>> a:Part3[*[
but this only works if x has multiplicity * otherwise
<<endPathMultiplicity>> a:Part3 [5..20[
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
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
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
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
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 *
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"
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."
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
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.
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'.
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
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
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 ...
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.
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
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.
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).
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'.
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.
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.
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.
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]
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:
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.
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.
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)
The Stereotype symbols for AbstractRequirement and Requirement show their [metaclass], the others do not.
If the Connectors in the Figure D.24 'Defining Fuel Flow Constraints (Parametric Diagram)' are BindingConnectors suggest explicitly show «equal» keyword or '='.
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'
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.
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.'
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)
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.
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 ...
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).
Figure D.23 has FuelFlow stereotyped by the DEPRECATED «flowSpecification»
Known already to Marlin and Rick
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.
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
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.
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
'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.'
A flow propertys values
Should be:
A flow property's values
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.
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.
Lots of ControlValues that should be ControlValueKinds
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
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"
Figure 4-2 name is "SysML Extension of UMLFigure".
The word "Figure" at the end of the legend is not expected.
Section number 17.2.1.1 is used whereas section 17.2.1 does not exist
The description given for ConstraintBlock makes it implicit that constraint parameter are value properties but there is no formal constraint about it.
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
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
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...
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"
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:
etc.
(There are also considerations when using Ports from readonly libraries.)
Continuous and Discrete need to be on FlowProperties as well as Parameters and ActivityEdge
UML4SysML::CreationEvent
UML4SysML::DestructionEvent
There is no Creation or Destruction Event in the current UML
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.
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."
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
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
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
in Block1 and Block2, compartments need to be Bound References
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.
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.
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.
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.
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):
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.
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
The guard Brake Pressure > 0 in figure 11-12 on page 148 has no enclosing square brackets.
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...
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.
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:
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
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.
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.
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.
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.
[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?
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.
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.
Activity regions and their contents should be redefinable
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.
