Tags and keywords
This Parsing Analysis diagram (indicated with the stereotype keyword «pa») is already quite busy, and it has a lot of cobweb-like, dashed-line "anchors" from «snippet» ElementGroup (text extract) symbols to elicited model elements, but that does not matter at all here because:
The main snippet's text 'A telescope is an optical instrument' is not quite accurate, and if we interpret it literally we'll end up excluding other kinds of telescopes. This snippet extracted from the same page helps clear it up:
It is clear that there is an abstraction Telescope that extends a higher level abstraction Instrument. It is also clear that there is a high level abstraction Detector.
The next step, however, is not so obvious. Do we wish to say that a Telescope "has a" Detector or that it "is a" Detector. If you apply a port-based approach (as we'll see later), we can have our cake and eat it here by asserting Telescope extends Detector, which has an input Port; something is going to flow into an input Port of the Telescope and then ultimately also into the Port of some part that does the final detecting.
We are told also that telescopes are 'instruments capable of detecting different regions of the electromagnetic spectrum, and in some cases other types of detectors.' Let's deal with the EM part first. There is block SpectrumEM, and a custom stereotype keyword «detects» that has been applied to a Dependency from a more specific DetectorEM to SpectrumEM. This may remind some readers of an OWL/RDF semantic triple.
Block SpectrumEM has a reference property region:RegionEM[1..*], where the block RegionEM is owned by SpectrumEM (as indicated by the containment operator). It also has the stereotype keyword «pa:term» applied, and carries the tagged value {fullname = "electromagnetic spectrum"} with an optional human-friendly description that helps explain the abbreviated block name.
The next step is a bit tricky (it requires some modelling experience and foresight). An intermediate implied block TelescopeEM has been introduced, which extends DetectorEM (and thus also «detects» SpectrumEM). Further, it declares references to region:RegionEM[1..*]. Then OpticalTelescope is just a special case of TelescopeEM. This will also enable us to represent other kinds of telescopes that are not optical but do deal with EM.
Although it is out of scope for this example, the Block hierarchy as shown is even flexible enough to handle telescopes that don't detect EM, such as neutrino telescopes.
Some elements to do with electromagnetism have had the custom stereotype keyword «em» applied, and some have had the more specific «optical» applied.
Clearly there is a block Lens, and OpticalTelescope references lens:Lens[0..*] (it may not have any, it might have many).
It is not correct that (optical) telescopes only ever use 'curved mirrors' (a Newtonian reflector uses a flat secondary) but just for now we'll go with that.
A CurvedMirror is a specific type of mirror that has the value property isCurved:Boolean redefined to always be true. We can also represent that using a Constraint curvature != 0 on a value property curvature:Curvature, where the value property Curvature could document how it is defined.
A custom stereotype keyword «observes» has been applied to a Dependency from Telescope to DistantObject (because presumably that is the job of any telescope, not just optical ones).
A DistantObject is a special kind of Object with the value property isDistant redefined to be 'true', and it also has isReadonly and isLeaf set 'true', so it can't be further redefined.
How do we know something is distant enough to be considered distant? A ValueType Distance has been introduced, and it is used to type a value property distance:Distance (which could be used to determine isDistant in a given context, such as for a type of telescope). Both have been marked as «pa:implied», because they are not directly mentioned by the target «snippet»; this can be removed later if some other sourced «snippet» mentions these concepts explicitly.
Phew, so much already from 2 tiny snippets! This is typical when starting a project using the Webel Parsing Analysis recipe for SysML®, and it's perfectly good so. We elicit a lot of model elements up front then get a huge amount of accurate reuse the further we proceed.
Before processing any more snippets, let's first move these elicited model elements out and place them in some Packages or Model packages.