KeplerianRefractor: simple image flow model: staging BDD

This time, instead of modelling the flow of light, the flow of a step-wise transformed OpticalImage is represented. The main aim of this trail is be able to model reflectors, however most reflectors use a secondary mirror in addition to a primary mirror, not just a simple single objective. Before extending OpticalTelescope to include such reflectors, a simpler light flow model of a KeplerianRefractor (which has a single primary lens as objective) is demonstrated.

Care has to be taken here not to build inflexible assumptions into the abstract OpticalTelescope. For example, a Gregorian reflector has the focal plane before a secondary, whereas the secondary of a Cassegrain reflector intercepts the image being focussed by the primary. The final viewed image of a Gregorian reflector is not inverted, whereas the final viewed image of a Keplerian refractor is. Therefore, to capture the transformation of an OpticalImage through an optical system, it must be specialised with appropriately redefined properties, and the optical elements of the system need ports with dedicated FlowProperty types.

The block KeplerianObjectiveImage is a specialisation of OpticalImage with isReal=true and isInverted=true. The block KeplerianViewedImage is a specialisation of OpticalImage with isVirtual=true, isInverted=true, and isMagnified=true, corresponding with these earlier snippets:

Wikipedia: 'The basic scheme is that the primary light-gathering element, the objective (the convex lens or concave mirror used to gather the incoming light), focuses that light from the distant object to a focal plane where it forms a real image.'

Wikipedia: 'This image may be ... viewed through an eyepiece, which acts like a magnifying glass. The eye then sees an inverted magnified virtual image of the object.'

There are specialised blocks KeplerianObjective and KeplerianEyepiece with specialised Ports for handling the above image flows. The specialised KeplerianRefractor has redefined objective to be of type KeplerianObjective and eyepiece to be of type KeplerianEyepiece (and it has also redefined them as 'composite' part properties, not just reference properties, because it is assumed there are no intermediate assemblies).

The specialised KeplerianRefractor also has a redefined image of type KeplerianObjectiveImage, and a redefined viewedImage of type KeplerianViewedImage. These can each be used as the SysML 'itemProperty' on Connectors with ItemFlows.

The context block KeplerianRefractorContext is much as was used for the simple light flow model with a :DistantObject, and an :Eye, but has a :KeplerianRefractor, as well as properties objectImage of type OpticalImage and viewImage of type KeplerianViewedImage for use as the 'itemProperty' of SysML ItemFlows on Connectors.

Block OpticalTelescope has now also been given an additional property objectImage of type OpticalImage, which is inherited by KeplerianRefractor, and may likewise be used as the 'itemProperty' of a SysML ItemFlow on a Connector.

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.

Up next

KeplerianRefractor: simple image flow model: context IBD with itemProperty

Notes

[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.

[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]{STRONG} Webel: For SysML Blocks and InterfaceBlocks used to type Ports with physical flows use 'F_UpperCamelCase' [may be combined with acronymn conventions]. The trailing part (after the underscore '_') may indicate the type that flows.

[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)