Webel: SysMLv1: MagicDraw/Cameo: CON: Using anonymous property and/or action names is not ideal for Element Compartment and Note callout displays when Usage level allocation is used. But allocation table and matrix views are better anyway.
The Webel recipe for pragramatic SE with SysML omits many of the concerns addressed by fully-fledged systems engineering frameworks. Many of these can be partially addressed by using custom Stereotypes for extraction using query view tables.
Webel: SysML: SE: The custom stereotype keyword «design» covers elements involved with BOTH design and/or implementation aspects in the 'solution' zone. (In more comprehensive SE methodologies design and implementation are often treated separately.)
Webel: SysML: SE: Naming convention: '0' used for a Package/Model name indicates a zone dedicated to a formal systems engineering breakdown (functional analysis, blackbox, whitebox, logical vs design or implementation etc.)
Webel: SysML: "Really long human friendly element names with spaces make my diagrams easier to read". Dr Darren says "No they don't! Prefer code-like naming (or anonymous for typed elements) wherever possible. Use custom tagged values for other names!"
Webel: SysMLv1: TIP: Use semantically meaningful Association names and/or custom Stereotypes where applicable. They can also often be used as pseudo OWL/RDF semantic triples. But don't use Association names where an ItemFlow can capture an exchange item!
Webel: SysML/UML: Dr Darren explains HOWTO use concise 'i'/'o' (input/output) Pin and Parameter naming conventions to promote a signal processing mindset in Activity Diagrams. And HOWTO get them compact.
Webel: SysMLv1: Dr Darren for LinkedIn: On "Trusting The Type" and avoiding unnecessary verbose repetitive Property names ... unless you really, really need them and really do have reasons to use them, and then only use concise role indicators anyway!
A «pa:implied» Element: Include a tagged value for at least one Snippet that implies it Gallery Tutorial TRAIL: Theory and best practices for the Webel Parsing Analysis recipe for SysMLv1.6+ Section Slide kind SysML Block Definition Diagram (BDD)
«pa:triple»: Pseudo semantic triples (c.f. RDF/S and OWL) Gallery Tutorial TRAIL: Theory and best practices for the Webel Parsing Analysis recipe for SysMLv1.6+ Section Slide kind SysML Block Definition Diagram (BDD)
Webel Parsing Analysis: The name of a Parsing Analysis Diagram (PAD) may be drawn from a focus Snippet OR may simply indicate a topic of interest to the analysis
UML/SysML: In Internal Block Diagrams: If you have a Port with a name that indicates a unique role AND and if there is an ItemFlow on a Connector that implies or suggests the Type of the Port, consider hiding the Type on the Port symbol.
Webel: SysML: DO NOT sacrifice modelling naming conventions for the mere sake of carrying organisation-specific names! Instead use tagged values of custom stereotypes as metadata to carry alternative names in parallel with systematic model element names.
SysML/SysPhS-1.1: Anonymous Property or Action names may not be an option if: You are exporting to Modelica or Simulink; You absolutely need names for generated query reports (such as generated Interface Control Documents).
MagicDraw/Cameo: v19SP3: Property created by dragging onto a Class or Block a symbol of a Classifier named with a single letter capital name 'N' has a poor name 'N:N'
Property is indirectly a kind of RedefinableElement, so Properties may be redefined. The name and visibility of a Property are not required to match those of any Property it redefines. Source Unified Modeling Language 2.5.1
If using "French style" post-adjective naming in English use a trailing underscore after the noun and before the adjective or qualifier: Vin_rouge, Cable_digital. Can be combined with TLA acronyms: Player_DVD.
The name of a «testCase» Behavior may be verbose and may use natural language, but should always start with a Capital letter.
Webel has a proposal for clearly revealing anonymous typed elements in SysML callouts and on derived Properties from operation queries.
SysML: Non-anonymous (concise please) block property names and port names may help a little in tracing participation of properties and ports in requirements relationships and play nicely with current SysML callout style. Short role indicators are best!
A basic Requirement is an AbstractRequirement Gallery Tutorial TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo Section 16:01: Requirements engineering in SysML Slide kind UML Profile Diagram
MagicDraw/Cameo: If you must use the Documentation field in the specification dialog for a Requirement element DO NOT use it to state the Requirement because that is WET not DRY. Instead just use the Requirement 'name' and/or the 'text'.
A most basic Requirement with a 'name', an 'id', and 'text' 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
Webel: If you must name your Ports or Pins, name them simply 'i', 'o', or 'io' (or 'oi') to indicate direction UNLESS you have to indicate a special role like 'iRole', 'oAuxiliary'. DO NOT use Port or Pin names like 'input', 'output', etc.
"Trust the Port or Pin Type!" - Often the name of the Type of an anonymous Port or Pin is completely sufficient to indicate its role, unless a clear indication of its direction or unique role is required.
UML/SysML: In Internal Block Diagrams: Consider hiding the name of a named Port or Property in a Diagram if its Type is sufficient to indicate its role.
MagicDraw/Cameo: You can easily find all elements a Stereotype has been applied to using Edit > Find OR via a Generic Table Diagram with the Stereotype as the 'Element type' (with or without sub-types).
DO NOT use Property names that are identical to the names of the Classifier (Class, DataType, Block, ValueType) that type them!
2_same_name Properties to which AdjunctProperty [is] applied shall have the same name as the principal, if the principal is a NamedElement. Source OMG Systems Modeling Language (SysML) 1.6
Figure 11-3: CallBehaviorAction notation with action name Gallery Tutorial TRAIL: The SysML-1.6 Hybrid SUV sample and specification diagrams in MagicDraw/Cameo (with annotations) [UNDERGOING UPDATE to SysML1.7] Section Section: SysML-1.6 specification diagrams: 11 Activities Slide kind SysML Activity Diagram
CallBehaviorActions in activity diagrams may optionally show the action name with the name of the invoked behavior using the colon notation shown in Figure 11-3. Source OMG Systems Modeling Language (SysML) 1.6
MagicDraw/Cameo: HOWTO redisplay the name and type of a SysML ItemFlow on a Connector if it vanishes (such as when the Connector is redrawn)
Port labels appear in the same format as properties on the end of an association. Port labels can appear inside port rectangles. Source OMG Systems Modeling Language (SysML) 1.6
Webel: "Trust the Metaclass or Stereotype" of an Element to indicate what type of element it is (you don't have to repeat it in the name)
If the property has no name, the property’s type name can be used instead. e.g., car:Engine:Cylinder:Piston.length car.e.c.p.length Source OMG Systems Modeling Language (SysML) 1.6
DO NOT use spaces in Property names or Class/Block names! If you want to communicate familiar names of elements within an organisation use a custom stereotype and tagged values (such as 'aka')!
Webel suggests using a verbose 'name' for leaf (child) Requirements but NO 'text' to prevent Single Source of Truth issues and for improved callout vs relationships (but this might not always work when syncing with external requirements management tools)
Message::signature : NamedElement [0..1] ... The signature of the Message is the specification of its content. It refers either an Operation or a Signal. Source Unified Modeling Language 2.5.1
SysML: Webel: "Trust the Type!" - Often the name of the Type of an anonymous Property or instance-level element is completely sufficient to indicate its role - unless multiple Properties of the same Type have different roles within the same owner context!
"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!
SysML: Naming: Always use either anonymous or first letter lower case for Property, ObjectNode and InstanceSpecification names; no exceptions (unless using names to "quote text")! Valid: 'lowerCamelCase' OR 'tla' vs TLA acronym OR 'uCC' vs UpperCamelCase
