Webel: SysML/MBSE: Suggest don't fuss about ownership (containment) too much early on. Focus on "logical" modelling, values, flows, relationships between elements. Suggest perform regular separate modelling "housekeeping" sweeps to deal with ownership.
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.
SysML: Naming: You may include Block, ValueType, and Signal names in the names of Behaviors (such as Activities) as long as this does not undermine the principles of functional analysis and allocation.
SysML: Naming: Including Block, ValueType, and Signal names in the names of Behaviors (such as Activities) can sometimes undermine purist functional allocation (because it may presuppose the element of the physical solution that carries out the function).
SysML: Having a Behavior owned by a Block it is allocated to may undermine purist functional allocation (because it presupposes the element of the physical solution that carries out the function)
An optical telescope is a telescope that gathers and focuses light mainly from the visible part of the electromagnetic spectrum Gallery Tutorial TRAIL: Webel SysML Parsing Analysis example: Optical telescopes from Wikipedia: Structure and port-based light flow model Section Slide kind SysML Block Definition Diagram (BDD)
In Package Diagrams and Block Definition Diagrams use the owner indicator display option for Classifier symbol headers to indicate the owner (except where a containment operator suffices). The mode 'Below Element Name' is preferred.
Overview of all diagrams after moving elicited model elements out of the '0-source' zone Gallery Tutorial TRAIL: Webel SysML Parsing Analysis example: Optical telescopes from Wikipedia: Structure and port-based light flow model Section Slide kind hybrid diagram SysML Block Definition Diagram (BDD) SysML Package Diagram
Composite (a.k.a. "compound") Requirements Gallery Tutorial TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo Section 16:01: Requirements engineering in SysML Slide kind SysML Requirement Diagram
An entire specification can be decomposed into children requirements, which can be further decomposed into their children to define the requirements hierarchy. Source OMG Systems Modeling Language (SysML) 1.6
A composite requirement may state that the system shall do A and B and C, which can be decomposed into the child requirements that the system shall do A, the system shall do B, and the system shall do C Source OMG Systems Modeling Language (SysML) 1.6
A composite requirement can contain subrequirements in terms of a requirements hierarchy, specified using the UML namespace containment mechanism. This relationship enables a complex requirement to be decomposed into its containing child requirements. Source OMG Systems Modeling Language (SysML) 1.6
They cannot be behavioral ports, or [be] linked to internal parts by binding connectors, because these constructs imply identity with the owning block or internal parts. Source OMG Systems Modeling Language (SysML) 1.6
SysML-1.6: Figure D.3: Would 'HSUV Interfaces' be better higher up directly under 'HSUV Model' (instead of under 'HSUV Structure')?
ERROR: SysML-1.6: Figure D.3 Automotive Value Types model library does not belong under the HSUV Model, showing it on this diagram without showing the owner suggests it is. Compare with Figure D.2.
Visual containment of the symbol for a UseCase in the rectangular symbol for a subject Classifier does NOT imply ownership! Packaging (ownership) of UseCases is separate from use within subjects, and a single UseCase may be used in more than one subject.
"Trust the Namespace" - DO NOT repeat information in names of owned elements that can be gleaned from the owner or ancestor (and is usually easily shown using display options). It is WET, it breaks the DRY principle!
