Closed himi closed 8 months ago
With COMPMOST
style and in Tree view, after this fix,
package TestStdLibElemInherit {
action a1 {
first start then a11;
action a11;
}
action a2 {
action a21;
}
action a3 :> a2 {
first a21 then a31;
action a31;
}
}
is rendered as:
And with SHOWLIB
style, it is rendered as:
Even with SHOWINHERITED
style (and without SHOWLIB
), we get the same result:
But with SHOWLIB
style, it renders enormous amount of inherited elements:
It takes some time to render it but due to the new limitation mechanism, it won't take so long time, it's finished in a few seconds in my Mac mini M1 environment.
Note that it is related to https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation/pull/537#issuecomment-1974914500
Sorry, I need to check it again. I got confused.
In addition, if the declaration for action a1
is changed to
action a1 {
first a3.a31 then a11;
action a11;
}
then this is rendered as
While a3
acts semantically as if it is featured by Anything
, so it can be used as shown in the succession in a1
, syntactically it is not actually an inherited member of a1
, so showing it as such is not really correct.
It looks the different issue. Again, it's related to a tricky inherit key issue. It can be reproduced with a simpler example:
action a1 {
first a3.a31 then a11;
action a11;
}
action a3 {
action a31;
}
After the investigation so far, both issues you reported are quite tricky, related to VPath
. And I'm now too busy to work on these. I guess I can work on them in April.
If you add these issues to the Jira backlog, then I am OK with approving this PR for the current sprint.
Thanks. I created ST6RI-758 and ST6RI-759.
The standard library elements are rendered even without SHOWLIB and SHOWINHERITED style if they are referred by some connectors. Also this PR limits the maximum number of elements to be processed, which is useful for rendering with
SHOWLIB
style.