(11066) Namespace compartment for blocks

MD SysML example supporting suggested resolution "closed no change".

In most tools users are free to compose systems using the SysML IBD (UML2 composite structure) first or a SysML BDD (UML2 class diagram). In the better tools one can move freely between the two, and the composition aspects are mapped bijectively (except owned Connectors and ItemFlows with itemProperty only appear in an IBD).

It is true that in the sample problem the BDDs seem to come first, however that is not in my experience the best way to handle structural composition !

I recommend:

  • create a "focus" BDD for each and every block in the system, independent of its usage context
    • In MD one can also use the structure compartment for a "hybrid" view of the parts, see below
  • build progressively complex assemblies using IBDs and connections
  • AFTERWARDS generate the corresponding associations in the focus BDDs (if you wish)
  • if you really want to, create a BDD with the "associative composition" structure:
    • that BDD is not used to build the system, it is merely a view of what was already built

In MD SysML you can show the structure compartment to create a "hybrid" diagram, which is very useful, if admittedly not standard SysML (yet). One can't show the connectors in a BDD anyway, so "associative composition" really is a very limited view of the composition anyway. UML2 composite structure was a blessing !

Note in the example below:

  • each property has been shown 3 different ways: as an attribute, as the end of an Association, and as a symbol in the structure compartment.
  • the composed structure has been shown in the "hybrid diagram" structure compartment (non-standard)
  • you can't show the Connector between property s:Source and t:Target, and you also can't show the ItemFlow v:Stuff
  • in the structure compartment you can show the "initial values" vectors (a.k.a defaultValue compartment, hopefully to be renamed 'initial values')
    • in the BDD one would have to show the initSource: Source and initTarget:Target instance "vectors" that initialise the corresponding parts as instance to see the values, the values of the Slots can't be seen in Property.defaultValue area of the Property in the attributes box alone
  • The Source block is - just for discussion here - an /ownedElement of (and an /ownedMember) of the Namespace StructuredBlock
    • it is also used as a part of StructuredBlock, however - since public - it could just as well be reused as a part elsewhere
      • the ownership of Source within the Namespace has nothing per se to do with its usage as part Property
    • if Source were not publically owned within the Namespace it would be be used to define a local class referenced only in a local context.
  • The Target block - by contrast - is not an /ownedElement of StructuredBlock, although it is used as a part
    • Target could just as well come from a read-only library of reusable blocks.

    • Blocks are never "owned by composition", they are only used as properties by composition:

    • StructuredBlock above "owns" Source just because I organised the model that way; it then participates In a local usage s:Source
    • Target above is not owned by StructuredBlock, however the usage as Property t:Target is.


    I really do advise against using composition associations extensively:

    • they can't show all the information anyway
    • they are graphically very fragile compared with composite structure using connected property symbols.
    • you can't show the 'initial values' "vectors" for the property-specific initial values (only the name of an assigned InstanceValue)

    I therefore recommend against the suggestion of a BDD-like compartment in a Block.