search

Systems-Modeling / SysML-v2-Pilot-Implementation

Proof-of-concept pilot implementation of the SysML v2 textual notation and visualization
GNU Lesser General Public License v3.0
128 stars 24 forks source link

ST6RI-598 Library models for standard views #414

Closed hpdekoning closed 2 years ago

hpdekoning commented 2 years ago

Added initial version of StandardViewDefinitions.sysml library package, as designed in the SST Graphical Specification WG, and introduced in release 2022-08 of the SysML Specification, clause 9.2.18.1 Views Overview.

Note: The corresponding code snippet in SysML Specification, clause 9.2.18.1, has been updated as well, so it is identical.

hpdekoning commented 2 years ago

For the definitions that have filters, I think the filters are too restrictive.

Yes, you are right. The filter specs were just a rough first attempt at formalizing what elements would be potentially included / permitted in views of a particular view definition type. At the time of creating these definitions the filter syntax was not well understood.

Should MemberView have any filter at all?

Indeed, the original intent was to specify a filter that permits any owned or non-owned member. We did not think of the consequence of excluding Dependency, Specialization, etc. Presentation of any model element, would imply filter @Element; which is effectively the same as no filter at all.

It seems that AnnotatingElements should be included in all cases.

Quite right. If we regard MemberView as the most general view def should we build a specialization hierarchy descending from MemberView? I guess filter conditions are inherited if no new filter is specified, and implicitly redefined if a filter statement is added in a specialization, correct? Eventually the name MemberView probably needs to be revisited as there are model elements that are not members.

Finally, indeed all view definitions should have a filter (or explicitly have none), we just did not get there.

seidewitz commented 2 years ago

I think it is best just to take all filters off for this release. It is more confusing to have incorrect ones, than to have none at all. But we should have the package in the library for this release, since we included it in the spec document in the last release. We will have more time to refine it before the final submission for the SysML spec.

hpdekoning commented 2 years ago

I think it is best just to take all filters off for this release.

Agreed. So I will remove the immature filter expressions, and add a task on the backlog to complete the library package. See https://openmbee.atlassian.net/browse/ST6RI-611 .