ARCHIVAL (2020): This content is now considered historical only!

[HISTORICAL] UML-STYLE: Hybrid SUV example: Ports with required/provided Interfaces (Block Definition Diagram)

Gallery
Tutorial
TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo
Section
09:04: Ports and contracts
UML keywords
Port
InterfaceRealization
Usage
provided Interface
required Interface
ball-and-socket
lollipop
SysML keywords
HSUV sample problem
SysML Block Definition Diagram
Slide kind
SysML Block Definition Diagram (BDD)
Webel Best Practice: In general, the SysML DirectedFeature approach is more powerful and the notation is cleaner than UML provided/required Interfaces. Prefer SysML DirectedFeatures unless you have a really good reason to use Interfaces!
Please consider skipping instead to:
Hybrid SUV example: provided/required DirectedFeatures (Block Definition Diagram)
While the DirectedFeatures capability of SysML is extremely powerful (and indeed the display options of SysML make DirectedFeatures easy to expose on IBDs), some users may still wish to use good ol' UML Interfaces for contracts because:
  • You wish to use Interfaces in combination with model-driven software engineering.
  • You wish to use the so-called Dependency Wiring tool support in MagicDraw/Cameo.
  • You wish to use the active validation support for connections in MagicDraw/Cameo (which is not yet available for SysML DirectedFeatures).

This diagram (adapted from the SysML spec's Hybrid SUV sample problem) shows the definitions of some Blocks with Ports that have types that provide (InterfaceRealization) or require (Usage) Interfaces.

Click on the image to view it full size
A minor matter: the naming convention for the Port types in the spec's Hybrid SUV sample problem does not correspond with Webel Best Practice:
Webel Best Practice: For SysML Blocks and InterfaceBlocks used to type Ports with contracts use the naming convention 'I_UpperCamelCase' [may be combined with acronymn conventions]
It is also not Webel Best Practice to show the Port symbols this way in a BDD:
You can't make connections in BDDs, only in IBDs. A BDD shows where connections may be made, an IBD shows where specific connections have been made in a specific context!
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.

To show that it can be done, the Port labels have been shown inside the port symbols, but this does not always work well with provided/required Interface "lollipop" and "socket" notation.

Up next
[HISTORICAL] UML-STYLE: Hybrid SUV example: Ports with required/provided Interfaces (Internal Definition Diagram)
Notes
[TIP, WORKAROUND]{INFORMATIVE} [HISTORICAL] HOWTO easily "hack" the SysML-1.6 ~InterfaceBlock conjugation and «~interfaceBlock» keywords in MagicDraw/Cameo. [NOW SUPPORTED 2024x Golden]
[ASSERTION, ISSUE] SysML-1.6: Needs a constraint on ~InterfaceBlock making the implied inversion of provided/required Interfaces explicit
[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)
[POLICY] Since SysML-1.6 use of direct UML conjugation of Ports is NOT supported; If you are using InterfaceBlocks use instead a conjugated ~InterfaceBlock type!
[TIP] Place your SysML-1.6 ~InterfaceBlock conjugation under the 'original' InterfaceBlock (i.e. make the original the containment owner).
[CAPABILITY, FEATURE, STYLE, TIP] TIP: MagicDraw/Cameo: Consider showing the Port name and type label inside the Port symbol! CAVEAT: This loses the direction indicators on Ports typed by Blocks with flow properties (but is fine if ItemFlows show the direction, or for "contract ports").
[ASSERTION, TIP] You can't make connections in BDDs, only in IBDs. A BDD shows where connections may be made, an IBD shows where specific connections have been made in a specific context!
[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.
[NAMING, POLICY]{STRICT} For SysML Blocks and InterfaceBlocks used to type Ports with contracts use the naming convention 'I_UpperCamelCase' [may be combined with acronymn conventions]
[DISPLAY, STYLE, WARNING] [HISTORICAL] ISSUE: UML: MagicDraw UML: Showing Port labels (name and type) inside Port rectangle symbols does not always work well with provided/required Interface "lollipop" and "socket" (a.k.a. ball-and-socket) notation
[TIP]{STRONG} In general, the SysML DirectedFeature approach is more powerful and the notation is cleaner than UML provided/required Interfaces. Prefer SysML DirectedFeatures unless you have a really good reason to use Interfaces!
Snippets (quotes/extracts)
  [UML-2.5.1] A provided Interface may be shown using the lollipop notation ... attached to the Port.
  [UML-2.5.1] A required Interface may be shown by the socket notation attached to the Port.
Visit also
Visit also (backlinks)
Related slides (includes other tutorials)
Figure D.18 - Defining Structure of Power Subsystem (PowerSubsystem Breakdown)
Figure D.19 - Internal Structure of the Power Subsystem (Internal Block Diagram)
Figure D.20 - Blocks Typing Ports in the Power Subsystem (ICE Port Type Definitions)
Related slides (backlinks, includes other tutorials)
BehavioredClassifier and provided and required Interfaces
Required/Provided Interface notation: Ball-and-Socket "dependency wiring" [tool specific]
Conjugation in SysML-1.7 is Type-based: InterfaceBlock, ~InterfaceBlock, and DirectedFeature