SysMLv1.x: Q: Why can't a Package with PackageImports be used as a Parsing Analysis text container? Why is the SysML1.6 ElementGroup (extended and customised as the Webel «snippet») far better suited for text-driven model element elicitation?

Icon class
far fa-sticky-note
far fa-sticky-note
Note kind
Policy level
Specification keywords
UML keywords
SysMLv1.x keywords
This is about SysML1.x only, for discussion of plans for SysMLv2 please visit:
Dr Darren says:
I have been asked this one a lot over the years. Even though formally one can use a Package together with the PackageImport relationship for logical grouping of elements, it is completely unsuited to the task of traceable text-driven elicitation of model elements from text extracts from domain source documents, and it is completely unsuited to the re-use of the quoted text extracts for communication in the model alongside the elicited model elements. Package is not even close to being a contender as a choice for a text parsing container.
If your challenge is:
If all one wants to do is create logical groupings then ...
The answer is:
That is NOT all one needs to do for the  Webel Parsing Analysis recipe for SysML®! There are heaps of other concerns specific to the task of text-driven model element elicitation and communication of the results. The ElementGroup (as extended as a Webel «snippet») meets nearly every one of those needs.

Before addressing this point-by-point, let's recall that in the  Webel Parsing Analysis recipe for SysML® process:

  • A customised Webel extension of the SysML ElementGroup called a Snippet (with keyword «snippet») is used to contain text quoted from a single domain 'source' document. Because the ElementGroup is based on a Comment the symbol for a «snippet» is a very text-friendly Comment!
  • One or more «snippet» elements acting as parsing containers are analysed in dedicated Parsing Analysis Diagrams (keyword «pa») separate from the rest of the model, always with the 'source' and 'member' tagged values showing on each «snippet», and typically with lots of handle/anchor dashed line paths to elicited model elements (so-called annotated elements). These Parsing Analysis Diagrams need not be tidy or shiny, they serve their purpose usually only once, and they are not intended for consumption by anybody but the modeller.
  • As new model elements are elicited they are moved into the main part of the model, and then shown on one more final presentation diagrams. Those final presentation diagrams may also show one or more «snippet» symbols with their commentary text (this is extremely powerful), typically with the 'source' tagged value showing, but almost never with the 'member' tagged value showing. A «snippet» may have lots of annotated elements (collected 'member'), but anchor/handle dashed lines are not always shown to every annotated element in a presentation diagram.

Ok, so why can't one use a Package with PackageImport? A better question might be "Why not use an extended ElementGroup?", but since it is asked so very often:

  • Con: A Package symbol can't appear in every kind of diagram. This completely excludes it already! Game over! The symbol for a Comment-based ElementGroup (extended as a «snippet») can appear in nearly any kind of diagram, as can anchor/handle dashed lines to elicited model elements.
  • Con: In a tool, creating a PackageImport to every kind of model element in a diagram is in not in fact so easy (even if it can be done via a specification dialog). For example, an ElementGroup-based «snippet» can appear in a StateMachine diagram and can thus easily elicit States.
  • Con: Visually the name of a Package symbol is completely unsuited as a text container, even the name header tab part of the symbol is unsuited. Comment-based symbols are primarily used to contain and display text, they are visually far superior, and mentally people associate the Comment symbol with text. This is very important, because the  Webel Parsing Analysis recipe for SysML® is a visually powerful communication aid for non-expert stakeholders too!
  • Con: Having a presentation diagram with Package symbols everywhere just to communicate text is visually awful compared with nice «snippet» Comment-based symbols.
  • Con: The PackageImport «import» relationship symbol is also not well suited, especially in presentation diagrams. Getting rid of all those «import» keywords from the presentation diagrams is not a big drama. But even the arrow on the end of the PackageImport symbol leads to clutter compared with the nice clean anchor/handle dashed line paths from a Comment-based symbol.

There is one short-coming of the SysML1.6 ElementGroup when used as a text parsing container, it is not relatable (although there is a way of achieving something similar using tagged values):

Packages are indeed already relatable. One could easily introduce a new stereotype for a Dependency. But there's no good reason a new SysMLv2 ParsingContainer couldn't support the same! In this case, having the arrow on the end of the relationship symbol is nice, as one can use it for RDF/OWL-like semantic triples with custom stereotypes like «triple:contradicts» if it is determined that one piece of analysed test contradicts another. But in the case of a new SysMLv2 "Comment-like" «snippet» one would then have a nice visual distinction between the dashed line anchors/handle symbols from the parsing container symbols to their elicited model elements and any relationships between parsing containers. This would not be the case for Package used as a parsing container!

Don't forget to visit these fun tutorial trails to see it all in action:

List of Webel Parsing Analysis requirements

Relates to
Related notes
Related notes (backlinks)
Related snippets (extracts)
Visit also
Visit also (backlinks)