The following refers to MagicDraw 16.6 SysML 16.6. Please check out also the MagicDraw SysML e-school.


Note: Everthing you read on this webseite or download from this website you use at or own risk and cost.

There is no warranty for correctness or completness for any item.



Last changed



Q: How do I make a MagicDraw project more navigable?

A: In Magicdraw one can drag and drop a diagram from the browser onto an element in a diagram to make it the default hyperlinked diagram target, a very useful, timesaving feature.

You can also drag and drop a diagram from the browser directly into a diagram, for example

to relate an IBD with a BDD. You can see that on the hyperlinked element there is at the lower left

Corner a little arrow symbol.

It is strongly recommend you drag all IBDs from the browser onto their relevant Blocks and parts typed by those blocks in diagrams to make your project more navigable.

Q: How do I uniquely associate a certain kind of information with a connector?

A: You need conveyed information:


  • Get a predefined type for the information you wish to  convey and drag it from the containment browser  onto a connector, and you will get a typed item flow. (You can choose the direction from the dialog.)
  • OR get a predefined typed property and drag it from  the browser (within a block) and drag it onto a  connector to get a flowing "instance". Try it !

Here is the BDD that corresponds to the situation above:

(You don't have to do a BDD like this, I am just showing

you so you understand what the underlying model is.)

!!! Please DO NOT use the explicit Item Flow menu,

    it is much easier to just drag from browser !!!


Also, please DO NOT use associations between your blocks unless really needed

(mostly they won't be), and please DO NOT convey information on associations (yet).


I want you to learn to do the entire thing using parts within composite blocks

(assemblies) and using only connectors between ports and flowports.

Q: Why are packages automatically relocated in the model when creating a contain relationship?

A: When creating a contain relationship between packages, the packages are automatically relocated accordingly in the package structure. For example, Pkg A exists on the same level as Pkg B and then on a pkg diagram a relation ship is created that A contains B, B is automatically relocated.

Applying containment is effectively performing an operation (you notice it by changes in the model browser). The containment symbol is merely an expression of that action.


Applying containment is (in effect) merely assertion of ownership.


When a package is simply relocated in the explorer the "contain" relationship is not automatically created.

A number of people have requested that it should be possible to display containments throughout the diagrams of a project. It is under consideration. By MagicDraw.


Note that containment symbols DO vanish (are destroyed) correctly when one moves an element from one owner to another.


There exists an OWNERSHIP. As soon as you apply containment to nest packages the nested package is owned by its parent in the model.


The containment relationship compels ownership. Containment and "relocation" are the same.

Q: How can one define icons for properties in a IBD?  (for examples specific symbols for sensors/actuators and actors)?

A: You can extend the stereotypes and set new icons for them. There is an icon filepath chooser in the stereotype spec box.

Q: We realized that when you drag and drop UseCases into a SysML Activity diagram they become a data object ("Central Buffer"). Why is it so?

A: Any classifier dragged onto any activity diagram becomes an Object Node.

The UML2 spec says:


    12.3.38 ObjectNode (from BasicActivities, CompleteActivities)

    An object node is an abstract activity node that is part of defining object flow in an activity.


Because it is abstract it cannot be instantiated directly in the model. So the default for Magicdraw was set to <<centralBuffer>> (for want of another choice). I agree it has a slightly strange side-effect for dragged UseCases.

Q: Why can I not drag and drop a property of a block A in one package (Pa) to a IBD in a different package (Pb)?

A: You can however do it for a block that inherits for another block, if the property is public or protected shared.


You are comparing a property in a Block (the model) with something in a diagram, without saying what block the IBD in the different package is linked to. (When frames are on it acts on behalf of its context-providing block.)


In fact, you can plonk any number of parts of the type of the block A into any IBD and even drag its properties onto the deeply nested parts typed by A with consistency.

Parts were created in a dedicated IBD for 1stBlock:

For completeness a dedicated IBD was created within 2ndBlock.

Part properties from  1stBlock can't be dragged into it (correctly):

Another IBD was created within 1stBlock that was then moved to 2ndBlock.

Note that the context variable is still 1stBlock !

Part properties from 1stBlock can be dragged into the moved IBD. This is because the context variable is still 1stBlock !

(In fact, if you drag yet another block into the diagram a part property is created back in the 1stBlock since it is still the context, even though the IBD is now _owned_ by the 2ndBlock. This is correct and consistent behavior.

Q: How do I show an <<allocation>> relationship (call-out notation)?

A: Attach a regular note (not a comment) to a block with a note handle. Then set "show element properties" on the note. AllocatedTo and AllocatedFrom should appear.

Q: How an I associate an Input/Output Pin of an action to an Activity parameter node?

A: If you create first actions and pins and later on you discover that you

need to refine an action with a call-behavior and then it becomes a bit painful because the binding between parameters and pins is not very tight.


Follow these rules:

1. create Activity Parameters first (open specification dialog of Activity and go to Parameters tab)

2. ActivityParameterNodes are created automatically in the model, so you need just display them. Right click on diagram and select Related Elements->Display Parameter Nodes. Activity parameter node represents some parameter, so own name is not used. If name is empty, parameter name is displayed. We will improve ActivityParameterNode representation, so it will show parameter name in the browser and all dialogs.

3. Simply drag'n'drop existing activity into another diagram and CallBehaviorAction with all pins as parameters will be created.

4. If you need to add new parameter of Activity, add it directly into Activity. After that you may use "display parameter nodes"and "display pins" functionality.


Use the desired Activity as the Behavior of a CallBehaviorAction then choose "display pins" via the context menu. Parameters are mapped to pins. (In the next versions there will be even tighter binding s that added pins become parameters, too.)


Q: When creating values for properties, like allocatedTo, in the part specification dialogue the allocatedFrom of the other part is not updated. Why is it inconsistent?

A: Please, do not set values for "allocatedTo" or "allocatedFrom"  tags, they are "derived" properties.

They will be read-only" in future versions. They must be read-only.

Put the two elements you want to connect on the same diagram and draw an <<allocate>> relationship.

In case you are not able to create Allocate in a diagram, you should open specification dialog, go to Relations tab and create a new Allocate directly in the model as outgoing to incoming relation.


Make sure you have the following settings:


Under Presentation Options (or equally Symbol Properties): Show Tagged Values - > In Compartment.

Under Edit Compartment make sure you have Tagged Values AllocatedTo and allocatedFrom selected.


How do I display in MD the stereotype of allocated properties?

A: Currently there’s no way.

In this case I would suggest to use stereotype icons, so your properties will be displayed with different icons and you will be able to recognize them. Open <<software>> stereotype and set some icon.

Q: Why are the stereotypes <<BlockProperty>> displayed when I drop them on an IBD?

A: In the project you attached MD_customization_for_SysML.mdzip module is not used. I have used this module with "Use Module" functionality and after project save/reload the stereotypes weren't visible.

Q: How are stereotypes of blocks and block-properties (typed by a block) related?

A: <<block>> is treated specially, the translucency feature is switched off for parts typed by a block, i.e.

if you remove stereotype <<block>>and replace it by your own like <<hardware>>you will see the stereotype in the IBD. This is the case for system, subsystem, etc.

A part Property is not the same as a block.

Q: How do I keep stereotypes consistent between blocks and parts, typed by those blocks?

A: MD shows the stereotype of a block only if there is no stereotype applied to its type (a block).

Therefore: stereotype the block and the part will have the same stereotype.

SysML widely uses strange practice to show "secondary stereotypes" - e.g. block stereotype on part, block stereotype on objectNode, parameter stereotype on ActivityParameter node or pin, Behavior stereotype on CallBehaviorAction,  tags of ValueType on parts (units&dimensions) and more.

Most these cases conflict with standard UML notation and semantics.

Now we are showing such "secondary" stereotypes only in case the "main" element has no stereotype applied. It is kind of "transparency" principle.

When some stereotype will be applied, it hides secondary stereotype. In MagicDraw this is called "translucency/transparency" principle.


Create in your custom profile a new stereotype, like <<hardware>>, assign an icon to it and make <<block>> its superclass. Its metaclass must be [Class].

When you create a new block, apply as the new stereotype <<hardware>> and remove <<block>>, then <<hardware>> will appear in BDD and IBD.

Q: How can I present properties with their fully qualified name?

A: Explore the structure of each block by “edit compartment” and displaying its structure.

Or, use "Select Nested Part" button from IBD diagram toolbar to create shorthand notation. Browse structure of properties in a special dedicated properties tree.

Each Block must have a role name on its association that is used in the nested part display.

Q: How to create a flow port within a standard port?

A: Simply choose the FlowPort from the diagram menu and add

a Port to a standard Port in a diagram to watch the magic happen.

(The class/block that types the Standard Port gets a FlowPort.)


Note that wherever a Port appears you can also perform "display ports" on the Port.

More Magic. This is one of the very useful features of MagicDraw UML.

Q: How to create the lollipops?

A: You can't create true "lollipops and forks" in IBDs (and UML composite structure diagrams)

in MD SysML yet, it is a priority feature for future MagicDraw along with validation of connections.

Nerijus and I head that effort.


You can however create classifier-level realizations and usages,

and you can "dependency wire" them in BDDs. Try

"display paths" from Interfaces and/or ports any BDD where

an Interface is provided/required via a Port and/or a Block.


It _is_ a good idea in MD to plan your connections architecturally first anyway.

Dependency wiring shows what _may_ be connected, as opposed to what _is_ connected.

 

Q: How do I draw an interface realization between a port and an interface?

A: You can use:


  •  the interface realization menu item in the diagram toolbar
  •  the "smart manipulator" to draw from the typed Port (a number of relationships appear right of the Port  when you select it, one of them is InterfaceRealization).
  •  the hotkey 'R' for realization. (For usage the hotkey is 'U'.)

Please note that the PORT MUST BE TYPED already, otherwise it makes no sense for it to realise or use anything, because it is in fact the TYPE that realises or uses the interface.


Q: HOWTO easily assign multiple hyperlinks and navigate to a chosen one?

A: You can use the hyperlink icon on the bottom left of the symbol to choose one of many links:

By default a "structured block" in MD SysML gets a "focus" IBD of the same name and

the name of it is synched to the block name: it is also set as the default active hyperlink.

(On MD UML a "structured class" gets a "focus" Composite Structure Diagram.)


You can assign and get to any of the other diagrams easily, too.


Drag any number of diagram icons onto your block to create multiple hyperlink targets.

(The last one dragged will become active, so if you want your original focus diagram as active again, drag it on again.)


Now click on the symbol of your block. At the bottom left of the symbol you will see a tiny hyperlink icon.

Q: What allocation schemes are available to allocate SW blocks to HW in MD?

A: The recommended way (where possible) is to use the <<allocate>> dependency.

Using MD specification is not recommended, however it does works.

There are cases when you can't display a target element in a diagram, and this mechanism makes it possible to still allocate. Preferred way is when the target element is visible.

***To summarize the options: ***.


1) Allocate blocks to other blocks on a BDD

in this case you cannot show the allocation on an IBD.


2) Allocate blocks to part properties through the specification dialogue of the part property.

In this case the SW block does not become a property, but you can display the

tagged value on the IBD and it would appear there as an allocated block with its

block name.

On the BDD you see the allocated indication of the property. However if you drag

out the property of its block on the BDD you cannot show anymore the allocation


3) Create a property from the SW block and draw <<allocate>> on the IBD.

Then one sees the allocation in the tags but with the name of the property and

not its type.


4) Allocate blocks on BDD through the specification dialogue of the block.

The result is the same as 1)


webmaster