I have found the following strategy extremely useful for managing models of real systems. Use a dedicated <<BlockPackage>> (or similarly one can use a <<BlockModel>>) to contain:

• 1 <<Block>> (only), referenced by the BlockPackage by tagged value
• 1 Icon (MagicDraw UML enables the insertion of images into diagrams)
• references to engineering artifacts (such as design manuals, spec sheets)
• real-world test data (or artifacts linked to external test data)
• physics models etc.

A systems engineering block may correspond to a very heavy, expensive, and very real thing. So it often deserves a dedicated <<BlockPackage>>.

Also - since a <<Block>> Class can't own an InstanceSpecification - a <<BlockPackage>> or <<BlockModel>> can be used to group the InstanceSpecifications used in MD SysML to initialise the part Properties managed by a structured <<Block>> Class. (Alternatively, the InstanceSpecifications can be contained in a custom stereotyped sub-package.)

Combining the <<BlockModel>> and <<BlockPackage>>

When developing software simulations of MD SysML systems it makes good sense to perform systems engineering with SysML Blocks in dedicated <<BlockModel>>s and software engineering with Classes and Interfaces in matching <<BlockPackage>>s, as illustrated below. This works well under both forward- and reverse-engineering.

• Proposal: for unified "value slice" system for initialisation, configuration, and animation

Image: