You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most asserted relationships are created by clicking a handle on one asset, then clicking on the asset with which it should have the new relationship. Where there are multiple possible relationships (in either direction), a drop-down selection is provided. This has some nice properties:
both assets are already selected, so we don't have too many possible relationships to worry about
possible relationships are listed alphabetically, but with relationships from the first asset above relationships going the other way
hovering over each option causes a tooltip to appear describing what the relationship means in that context.
It is also possible to create relationships from the asset properties panel. To do this, one must open the folded list of inbound or outbound relationships, click on the 'add' button, and select the relationship type and the other asset involved (in that order). This has some not so nice properties:
The relationship type must be selected first, before the two assets are known, so lots of relationship types may be chosen.
The possible relationships types are not listed in alphabetic order, so finding the one you want is difficult.
There is no tooltip explaining what each relationship type means.
Some distinct relationship types use the same label, and only that is displayed, so without a tooltip it is impossible to tell them apart.
Once the relationship type is chosen, the asset selection tool is populated, but they are also not listed in alphabetic order.
The whole process is very difficult.
For example, if one wants to create a Process-receives-Data relationship, one can select the Process, but the list of possible relationships to any other asset in the system is huge. If the system model includes a Sensor, two 'receives' relationship types, one of which refers to the Process-receivesFromSensor-Data type (which uses the label 'receives'). Either can be selected, but you only find out which is which when you look for a relatable asset (with one you want you see a list of Data assets, but with the other, a list of Sensors). And you may not even get that far unless you know what each relationship type means.
I propose the following improvements:
Reverse the order so users select the other asset first, rather than the relationship type.
Ensure the options are listed alphanumerically, restricted to those assets that could have a relationship with the selected asset.
Make the selection of relationship type work the same way as the relationship type selector used in the canvas.
This means by the time one is choosing the relationship type:
Both assets are known, so we won't have too many options. Because we have separate 'add' buttons for inbound and outbound relationships, we'll know the direction and can eliminate backward relationships (unlike the situation in the canvas).
Because we know both assets, we'll have all the information used in the canvas relationship type selector, so it should be possible to display them in the same way, and include the tooltip.
This dialog is the only way to create asserted relationships involving inferred assets. At present, that leads to a crash (explained in issue #44), but once that bug is fixed, some users may start wanting to use this feature. In future we may want to use this dialog also as the way to add relationships that are by default hidden in the canvas view, which certainly would help reduce the visual complexity of using system-modeller. In short, although this feature is rarely used, it is likely to become far more important in future.
The text was updated successfully, but these errors were encountered:
Both assets are known, so we won't have too many options. Because we have separate 'add' buttons for inbound and outbound relationships, we'll know the direction and can eliminate backward relationships (unlike the situation in the canvas).
On reflection, that would not be the best idea. The reason we show relationships in both directions in the canvas is because users aren't always aware which way round the relationship is encoded in the domain model. They know which assets are involved, but not necessarily the direction of the relationship they want.
Most asserted relationships are created by clicking a handle on one asset, then clicking on the asset with which it should have the new relationship. Where there are multiple possible relationships (in either direction), a drop-down selection is provided. This has some nice properties:
It is also possible to create relationships from the asset properties panel. To do this, one must open the folded list of inbound or outbound relationships, click on the 'add' button, and select the relationship type and the other asset involved (in that order). This has some not so nice properties:
The whole process is very difficult.
For example, if one wants to create a Process-receives-Data relationship, one can select the Process, but the list of possible relationships to any other asset in the system is huge. If the system model includes a Sensor, two 'receives' relationship types, one of which refers to the Process-receivesFromSensor-Data type (which uses the label 'receives'). Either can be selected, but you only find out which is which when you look for a relatable asset (with one you want you see a list of Data assets, but with the other, a list of Sensors). And you may not even get that far unless you know what each relationship type means.
I propose the following improvements:
This means by the time one is choosing the relationship type:
This dialog is the only way to create asserted relationships involving inferred assets. At present, that leads to a crash (explained in issue #44), but once that bug is fixed, some users may start wanting to use this feature. In future we may want to use this dialog also as the way to add relationships that are by default hidden in the canvas view, which certainly would help reduce the visual complexity of using system-modeller. In short, although this feature is rarely used, it is likely to become far more important in future.
The text was updated successfully, but these errors were encountered: