Focus PAD for the Snippet 'The quick brown fox jumps over the lazy dog'

At least the following SysML Blocks can be immediately elicited from the nouns (using here a convention that the name of the first letter of a Block must be capital):

- Fox, Dog

Further aspects concerning the described Fox and Dog are then considered, as shown in the PAD in Figure 4, for which a Block Definition Diagram (BDD) has been used.

There are some attributes indicated by adjectives, which in SysML may typically be modelled (amongst other modelling choices) by value properties. It seems that a Fox may be quick (it will be assumed that this is taken from a «valueType» Enumeration SpeedKind), a Fox may be brown (from a «valueType» Enumeration ColorKind) and that a Dog may be lazy (from a «valueType» Enumeration MoodKind):

We are not explicitly told what a 'dog' or 'fox' are, but the modeller may use prior knowledge about the world and the context to conclude that they are types of animal, which is indicated using the «pa:assumed» keyword on a more general abstract block Animal and thoroughly also on Generalizations from Fox and Dog to Animal. (If the application of «pa:assumed» to such Generalizations leads to diagram clutter the stereotypes keywords need not always be shown.)

It is not always clear whether «pa:assumed» or «pa:implied» should be used in such cases, the main thing is that the modeller applies at least one of those stereotypes to indicate that an additional modelling interpretation was required.

This Snippet yields some general value properties:

- Animal::speed:SpeedKind

- Animal::color:ColorKind

- Animal::mood:MoodKind

And more specific redefined value properties with default values:

- Fox::speed:SpeedKind = quick {redefines speed}

- Fox::color:ColorKind = brown {redefines color}

- Dog::mood:MoodKind = lazy {redefines mood}

There are also Behaviors and Operations. It would seem that a Fox can jump. Can any Animal jump? Surely foxes don’t only jump over dogs. For now a more general operation is introduced, where a «pa:implied» jumpee is any animal that another animal jumps over:

- Animal::jumpOver(jumpee:Animal)

There are InstanceSpecifications classified by Fox and Dog with Slot values corresponding to the described scenario:

- quick brown fox:Fox

- lazy dog:Dog

An Association named JumpsOver is used to classify an anonymous link :JumpsOver between the instances.

Webel Parsing Analysis: An anonymous Element may be collected as a /member of a Snippet (it is not important whether collected elements list with a clear name under /member, only that they are traceably elicited).

And in a context block there are corresponding part properties (using a slightly different naming convention) with an anonymous Connector typed by the same Association JumpsOver:

- FoxDogPangramContext::quickBrown:Fox

- FoxDogPangramContext::lazy:Dog

Two States for a StateMachine within the abstract block Animal have also been elicited:

- Jumping, Lazing

As StateMachine Diagrams are always owned by an element that should not eventually remain under the Source Input Zone they should not be used as PADs. Elicit States instead by adding them via the /member section of the ElementGroup specification dialog in MagicDraw.

Now some new model elements have been elicited they MUST be moved out of the Source Input Zone into the main project model area as shown next .

Up next

Focus BDD for block FoxDogPangramContext

Notes

[POLICY]{STRICT} Webel Parsing Analysis: A Snippet (keyword «snippet») MUST always have exactly one domain 'source' Document (keyword «document»).

[TIP]{EDITORIAL} In Webel Parsing Analysis every Package, Model, or Diagram used to perform Parsing Analysis MUST have the stereotype keyword «pa» applied, and MUST live under a top-level Model or Package 'source' separate from the rest of the project model.

[POLICY]{STRICT} Webel Parsing Analysis: Create a top-level 'source' or '0-source' Package/Model SEPARATE from your project model. All source «document» elements and «snippet» extracts and «pa» diagrams MUST be ultimately owned by that top-level Package/Model as ancestor!

[POLICY, STYLE]{STRICT} Webel «pa» Parsing Analysis Diagrams (PADs) are "scratchpads" used to elicit model elements traceably from text Snippets (extracts from source Documents). While BDDs are a good initial choice, most types of SysML diagram can be used as a «pa» diagram.

[MODELLING, NAMING, POLICY]{STRICT} Webel Parsing Analysis: Acronym: PAD = Parsing Analysis Diagram (may be nearly any diagram type, except those types that must be owned by an elicited model element)

[DISPLAY, MODELLING, POLICY]{STRONG} Webel Parsing Analysis: A "focus" Parsing Analysis Diagram (PAD) for one or more Snippets SHOULD always show the /member tagged value of every Snippet.

[MODELLING, NAVIGATION, PATTERN, TIP, TOOL]{STRONG} Webel: UML/SysML: Navigation: ALWAYS offer a way out of a diagram (usually up a hierarchy, but possibly across) using a navigable symbol (linked to a diagram) and/or a diagram symbol. Avoid "cul-de-sacs"! [But beware of shared package cross-dependencies]

[MODELLING, POLICY, TOOL]{STRICT} Webel Parsing Analysis: As StateMachine Diagrams are always owned by an element that is not eventually under the Source Input Zone they should not be used as «pa» diagrams. Elicit States instead via the /member section of the specification dialog.