This is an incremental update to the 2024-11 release. It corresponds to Eclipse plugin version 0.47.0.
New FeaturesKerML
Cross subsetting. A cross feature of an end feature is specified using a new cross subsetting relationship between an end feature and its cross feature. The cross multiplicity of an end feature refers to the multiplicity of its cross feature, rather than the multiplicity of the end feature itself, which is always 1..1. The cross ordering and uniqueness of end features similarly refer to those of their cross feature.
Cross subsetting is identified by the crosses keyword or the equivalent symbol =>. For example,
struct LegalEntity {
feature assetsOwned [*] ordered : Asset;
}
struct Asset {
feature owningEntities [1..*] : LegalEntity;
}
assoc AssetOwnership {
end owner : LegalEntity crosses ownedAsset.owningEntities;
end ownedAsset : Asset crosses owner.assetsOwned;
}
With the specified cross subsetting, creating an AssetOwnership link between a LegalEntity and an Asset means that the Asset must be one of the aassetsOwned by the LegalEntity and that the LegalEntity must be one of the owningEntities of the Asset. As shown above, the target of a cross subsetting relationship must be a feature chain in which the first feature is the other association end and the second feature is the cross feature for that end.
Cross feature multiplicity effectively constrains the number of instances of an association. It applies to each set of instances (links) of the association that have the same (single) values for each of the other ends. For a binary association, this is the same as the number of values resulting from "navigating" across the association from an instance of one related type to instances of the other related type. Cross feature uniqueness and ordering apply to the instances navigated to, preventing duplication among them and ordering them to form a sequence.
If an end instead has an owned cross feature, the cross subsetting is implicit. The cross multiplicity, ordering and non-uniqueness can then be declared directly on an end feature, with a notation that makes it clear that these are properties of the cross feature, not the end feature itself:
assoc AssetOwnership {
end [1..*] feature owner : LegalEntity;
end [*] ordered feature ownedAsset : Asset;
}
If no cross feature is given for an end, then its cross multiplicity is effectively 0..* by default.
Connector ends declared in the body of a connector may have cross features, specified using cross subsetting, as for association ends. The cross feature for the connector end further constrains any inherited cross feature(s). In the more common shorthand notation for connectors, the cross multiplicity (but not ordering or non-uniqueness) can be given at the before of the end's related feature (previously this was given after the related feature):
struct WheelAssembly {
composite feature halfAxles[2] : Axle;
composite feature wheels[2] : Wheel;
// Connects each one of the halfAxles to a different one of the wheels.
connector from [1] halfAxles to [1] wheels;
}
[PR #608]
SysML
crosses keyword can also be used in SysML, with the same meaning as in KerML.
part def LegalEntity {
ref part assetsOwned [*] ordered : Asset;
}
part def Asset {
ref part owningEntities [1..*] : LegalEntity;
}
connection def AssetOwnership {
end part owner : LegalEntity crosses ownedAsset.owningEntities;
end part ownedAsset : Asset crosses owner.assetsOwned;
}
connection def AssetOwnership {
end [1..*] part owner : LegalEntity;
end [*] ordered part ownedAsset : Asset;
}
part WheelAssembly {
part halfAxles[2] : Axle;
part wheels[2] : Wheel;
// Connects each one of the halfAxles to a different one of the wheels.
connect [1] halfAxles to [1] wheels;
}
1..1, even for kinds of usages that would otherwise not have that default if they were not ends.part def DistributedSystem {
item def Request;
item def Response;
part client {
port clientPort;
action clientBehavior {
send Request() via clientPort;
then accept Response via clientPort;
}
}
part server {
port serverPort;
action serverBehavior {
accept Request via serverPort;
then send Response() via serverPort;
}
}
// Transfers from the clientPort automatically target the serverPort
// and vice versa.
interface client.clientPort to server.serverPort;
}
crossesownedParts of a Definition or the nestedParts of a Usage. However, they do still appear in the lists of ownedConnections/nestedConnections (since they are still kinds of KerML connectors). Semantically, composite flows are also no longer subparts of a containing Item or Part, but they remain as subactions of a containing Action. The model library elements related to flow connections have been move out of the library package Connections to the new package FlowConnections.1..1 (like participant properties in SysML v1). Giving an end feature a multiplicity other than 1..1 currently results in a warning, but this will become an error in the future. However, multiplicities in the old position on connector or connection ends in the shorthand notation will result in syntax errors. In either case, the multiplicity should be moved to the position of a cross multiplicity (as shown above).IndexExpression metaclass in the abstract syntax. This has no affect on end-user models.This release includes implementation of resolutions to the issues listed below.
KerML
Resolution of the following issue was approved on KerML FTF1 Ballot 3, but its implementation was blocked until the resolution of SYSML2_-173.
Resolutions for the following issues were approved on KerML FTF2 Ballot 4.
SysML
Resolutions for the following issues were approved on SysML v2 FTF2 Ballot 6.
None.
Visualization (PlantUML)None.
Technical UpdatesownedPorts of the part.RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4