SimpleOpticalTelescope light flow model: staging BDD and context IBD

A "staging" BDD for defining some flows and ports, and a context IBD for a very simple port-based light flow model for a SimpleOpticalTelescope in eyepiece mode:

Click on the image to view it full size

Note these Webel Best Practice conventions:

Webel Best Practice: In most Webel examples, the default is chosen to be 'out' if there is a single FlowProperty, so a Port with the type applied will act as a source. If an InterfaceBlock is used, then a Port typed by the conjugating ~InterfaceBlock will act as a sink.

Webel Best Practice: Webel: For SysML Blocks and InterfaceBlocks used to type Ports with physical flows use 'F_UpperCamelCase' [may be combined with acronymn conventions

Webel Best Practice: Webel: DO NOT name the Type (Block or InterfaceBlock) of a Port with a flow the same as the name of the 'Stuff' that flows through it; use the Webel 'F_Stuff' convention!

Note the use of anonymous FlowProperty naming. And some tips:

[HISTORICAL] HOWTO easily "hack" the SysML-1.6 ~InterfaceBlock conjugation and «~interfaceBlock» keywords in MagicDraw/Cameo. [NOW SUPPORTED 2024x Golden]

Webel Best Practice: A "staging" BDD for defining the flows, ports, and item properties on blocks to be used in an IBD does not have to be a "work of art" if it is not intended as a final presentation diagram.

In this example, regular Ports are used together with InterfaceBlocks (which IS allowed):

It is NOT true in SysML1.6+ that you "should" always use a SysML FullPort or a SysML ProxyPort instead of a "standard" Port, and it's not even always a good idea (and the spec states this very clearly in multiple places)!

SysML: Typing a Port by an InterfaceBlock or ~InterfaceBlock does NOT imply that the Port is a ProxyPort (but ProxyPort must be typed by an InterfaceBlock or ~InterfaceBlock)

The flow of Light out of InterfaceBlock F_Light and into ~InterfaceBlock ~F_Light is defined using flow properties, then these interface blocks are used to type output and input Ports.

Every OpticalElement is given both an oLight:F_Light and iLight:~F_Light Port, so these are available to the objective and inherited by EyePiece.

Block OpticalTelescope (which is still distinct from OpticalElement) is also given both an oLight:F_Light and iLight:~F_Light Port, and these are inherited by SimpleOpticalTelescope.

And any Object can act like a source so is given an oLight:F_Light Port.

As per Webel Best Practice for BDDs:

Webel Best Practice: SysMLv1: Prefer not show Port symbols on the boundary of Block symbols in BDDs, just list them in compartments. One can't connect them in a BDD anyway. Recommend only show Port symbols in IBDs.

These are then "wired up" using Connectors in an IBD for block SimpleOpticalTelescopeContext. For brevity, the types of the Ports are not shown.

In fact, the Connector to the Port ~iLight of the objective and the Connector from the Port ^oLight of the eyepiece are both owned by OpticalTelescope, whereas the Connector between the Port ^oLight of the objective and the port iLight of the eyepiece is owned by SimpleOpticalTelescope, because it may not apply to every telescope (such as reflectors with secondary mirrors).

Concerning naming: when there is only a flow of one kind, names like 'i', 'o', and 'io' are perfectly sufficient for ports with simply flow properties. When, however, there is more than possible flow, names like oLight and iLight help distinguish them from, say, oRadio.

The passage of light is indicated using an ItemFlow on each Connector, always here with the same conveyed Classifier Light, it does not yet show any transformation of the light (which one could do with a specific SysML itemProperty on each Connector).

Although an eye is not responsive to some of the wavelengths included under «optical» Light, the flow into :Eye is not restricted here to VisibleLight, because one may wish, for example, to include an image sensor that is sensitive to infrared. The response of an Eye to Light is solely determined by Eye.

Note how each of the elements in the final IBD corresponds to a physical zone/extent in space. The diagram does not represent a physical geometry or optical layout, but it does represent a light flow topology, with clear boundaries between zones.

We see next how a SysML itemProperty can be assigned to the ItemFlow on each Connector to create a simple port-based image flow model showing transformation of the image of the distant observed object.

Up next

KeplerianRefractor: simple image flow model: staging BDD

Notes

[CONVENTION, STYLE]{RECOMMENDED} In most Webel examples, the default is chosen to be 'out' if there is a single FlowProperty, so a Port with the type applied will act as a source. If an InterfaceBlock is used, then a Port typed by the conjugating ~InterfaceBlock will act as a sink.

[TIP, WORKAROUND]{INFORMATIVE} [HISTORICAL] HOWTO easily "hack" the SysML-1.6 ~InterfaceBlock conjugation and «~interfaceBlock» keywords in MagicDraw/Cameo. [NOW SUPPORTED 2024x Golden]

[NAMING, POLICY]{STRICT} Webel: For SysML Blocks and InterfaceBlocks used to type Ports with physical flows use 'F_UpperCamelCase' [may be combined with acronymn conventions

[CONVENTION, NAMING]{STRICT} Webel: DO NOT name the Type (Block or InterfaceBlock) of a Port with a flow the same as the name of the 'Stuff' that flows through it; use the Webel 'F_Stuff' convention!

[ASSERTION, WARNING] It is NOT true in SysML1.6+ that you "should" always use a SysML FullPort or a SysML ProxyPort instead of a "standard" Port, and it's not even always a good idea (and the spec states this very clearly in multiple places)!

[ASSERTION] SysML: Typing a Port by an InterfaceBlock or ~InterfaceBlock does NOT imply that the Port is a ProxyPort (but ProxyPort must be typed by an InterfaceBlock or ~InterfaceBlock)

[CONVENTION, NAMING, STYLE]{STRONG} FlowProperty naming. Use anonymous or just 'i' for in, 'o' for out, and 'io' for inout. "Trust the Type". For conjugation ~InterfaceBlock use 'o' for in, 'i' for out, and 'oi' for inout.

[POLICY, STYLE]{TIP} A "staging" BDD for defining the flows, ports, and item properties on blocks to be used in an IBD does not have to be a "work of art" if it is not intended as a final presentation diagram.

[MODELLING, STYLE]{RECOMMENDED} SysMLv1: Prefer not show Port symbols on the boundary of Block symbols in BDDs, just list them in compartments. One can't connect them in a BDD anyway. Recommend only show Port symbols in IBDs.