Use MagicDraw's diagram hyperlinking facility to navigate systems engineering models

Before we begin, you need to know the one thing that might save you the most time when modelling with MagicDraw UML and MD SysML.

You can drag n' drop any diagram icon from the browser onto any element's symbol
in an active diagram to hyperlink that element to the "dragged" diagram ! Simply super !

For practical systems engineering this means you can link elements to "focus diagrams" and "open up" elements at will. I recommend that you:

• As soon as you create a new element's symbol, ,ask yourself: "What can I hyperlink it to ?", and drag a diagram icon onto it.
• Hyperlink every single model or package to a SysML Package Diagram (or SysML Block Definition Diagram).
• Hyperlink every assembly Block to its Internal Block Diagram (IBD):
  • if you use MD SysML's StructuredBlock menu that is done automatically for you.
• Place at least one Block Definition Diagram (BDD) diagram icon on every Internal Block Diagram (IBD).
• BIG TIP: drag the Internal Block Diagram (IBD) icon of the Type of a Property onto that Property's symbol in an IBD so that you can open up a part into its matching IBD. Wonderful !
• Use a top-level SysML Package Diagram or (custom MagicDraw Content Diagram) as a «sitemap» and place its icon on every single diagram in your project::
  • however, be aware that this can prevent modularisation.
• Hyperlink your top-level SysML «system» and/or «system context» to their IBD or BDD and place them on every diagram possible throughout your project:
  • however, be aware that this can prevent modularisation.

It takes seconds. And it may save you days or weeks or months !

A SysML Internal Block Diagram (IBD) with frame: AssemblyBlock.ibd

<<terminology>>A SysML Internal Block Diagram (IBD) shows the part Properties (and shared and direct reference Properties) of a structured Block, and Connections between them and/or their Ports. It can also show Ports of the structured Block on the boundary frame (Ports are not handled in this trail). An IBD for Blocks in SysML is like a UML2 Composite Structure Diagram for Classes.  A SysML <<Block>> is a stereotyped UML2 Class, which is a StructuredClassifier.

In MD SysML an assembly is known as a structured Block, and it has a special creation menu, which automatically assigns an IBD as the default hyperlink target for the block's symbol, so that whenever the block's symbol appears in a diagram you can "open it up" into its IBD. Very useful ! 

HOWTO use the SysML ValueType, Unit, Dimension system to model real-world quantities

Physical quantities of real-world systems are described using scientific systems of units and dimensions. SysML1.0 extends the UML Property system to include physical values of quantities measured or stated relative to a chosen Unit, as well as industrial quantities. You can define custom ValueTypes (which may be used to type value properties in SysML).

There are two main uses of ValueTypes (which are illustrated in the following pages of this trail):

1. To indicate and assign a specific Unit (with a Dimension) to a value property that represents a named quantity. The value of the quantity is then stated (or measured) relative to that Unit (see the example default value statements). The ValueType is usually named after the symbol of it's fixed Unit. The examples following have been denoted «unit-like» for illustration only.
2. To define a "kind of quantity" that is not bound to a specific block. The ValueType is named to indicate the kind of quantity (not the Unit chosen). Changes to the chosen Unit will propagate throughout the system, so special care must be taken with statement of values and defaults ! The examples following have been denoted «quantity kind» for illustration only.

You may also define custom "industrial" Units and Dimensions for use by a custom ValueType.

HOWTO define a custom ValueType as a system-wide "kind of quantity" (or after its Dimension)

You may use a ValueType to define a "kind of quantity" that is not bound to a specific block. In the example below, the ClockFrequency ValueType is defined for an entire system. It may then be used to type a specific ValueProperty representing a specific quantity in a block, such as the frequency of a Processor. In this case, the ValueType is named to indicate the kind of quantity (rather than the symbol of the chosen Unit ). The same principle can be used to name a ValueType after its Dimension.

WARNING: Changes to the chosen Unit will propagate throughout the system, so special care must be taken with statement of values and defaults !

---

• The Dependencies in this diagram are for illustration only; they are not needed
  to define the Unit and Dimension of a ValueType. Just use the specification dialog.
• The examples here have been denoted «quantity kind» for illustration only.

---

Visit also:

• Value types defined for the SysML Hybrid SUV sample problem

TIP: use a <<BlockPackage>> or <<BlockModel>> for each Block and its associated engineering data

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

HOWTO progressively configure the initial values of Blocks reused as part Properties

Motto: a system with no values has no value !

We will consider the progressive re-use and re-configuration (or initialisation) of values of blocks used as part properties in various types of vehicles, including inherited configurations. By progressive I mean "one context at a time", as opposed to deep re-configuration of all values of an entire system (which is the subject of another advanced trail).

We will distinguish between the following types of configuration values:

• Static (or class-level) default values: These correspond to the values one would get using a noargs constructor (see the capacity value of the FuelTank block below). If not overridden on instantiation of the block these become the initial values. They are managed by the Block that owns the ValueProperty.
• Property-specific initial values (a.k.a. property-specific default values): these are specific to the usage of a Block in a higher context (by a structured block or "assembly"), and if there are many part properties of the same type, they may have different property specific initial values. They are managed by the higher context structured block that owns the part properties, which initialises or configures their (possibly different) values on instantiation. In our example an abstract Vehicle block will configure/initialise a tank:FuelTank part property with a new capacity value.
• Inherited property-specific initial values: a concrete Car (with 4 wheels) that simply extends Vehicle will inherit the property-specific initial values of the any Vehicle, i.e. when a :Car is instantiated it will initialise its tank:FuelTank to the same new capacity value (overriding the static default value from FuelTank)
• Redefined property-specific initial values: a TouringCar extends Car to add a RoofRack and to specify a larger tank:FuelTank (presumably for long trips). When a :TouringCar is instantiated it will re-initialise its inherited tank:FuelTank with a larger capacity value (overriding the property-specific initial value of tank:FuelTank within Vehicle).

Let us now work through these cases to see how they are assigned and managed in MD SysML

HOWTO deeply configure the initial values of entire complex assemblies of blocks (ADVANCED TOPIC)

We can handle a wide range of systems engineerings configuration tasks by progressively applying the following:

• Static (Class-level) default values
• Property-specific initial values
• Inherited Property-specific initial values
• Redefined Property-specific initial values

However, none of these approaches can handle deep re-configuration of complex assemblies, an advanced topic which is the subject of this mini-trail.

Consider the case of a Truck reusing a complex (yet naive) WheelHubAssembly for 3 pairs of Wheels, each with different characteristics. Although the basic WheelHubAssembly might have been suitable for a range of Vehicles (like a Car, a TouringCar, and a MiniVan), it is not nearly suitable for a large Truck.

Many parts and subparts of the WheelHubAssembly required for a Truck will be larger and will need to be stronger to handle heavy loads:

• the diameter of the Tire, TireBead, and Rim etc. will all need to be larger.
• the inflationPressure value of the WheelAssembly will be higher
• the LugBoltJoint will be subjected to greater torque and boltTension, and the LugBoltThreadedHole will have larger lugBoltSize and threadSize

The progressive configuration strategies fail here because the new configuration requirements "cascade" throughout the entire complex WheelHubAssembly, from the outermost context to the deepest part. We could just start with a completely new TruckWheelHubAssembly that configures a completely new TruckWheelAssembly, etc. right down to a TruckLugBoltJoint, however that gives us no reuse at all, not even of the existing block structures.

Instead we could use the SysML PropertySpecificType strategy, a set of "on-the-fly" extensions (subtypes) of each Block used in a complex assembly hierarchy, to afford a point of redefinition of the part Properties and their value Properties as required. It will be demonstrated that this strategy, while offering the widest range of deep redefinition possibilities - including redefinition of operations and constraints - is mostly inefficient and cumbersome for the purposes of merely assigning values deeply to a system used in a given context. In this trail we will learn what a PropertySpecificType is and investigate some of its pros and cons.