Can I give a context-specific value to a SysML constraint parameter on a usage of a ConstraintBlock in a parametrics diagram ?

No, unfortunately not. This is a fundamental problem with the SysML metamodel for constraint parameters.

 

What is the difference between a UML «subsystem» and a SysML «subsystem» ?

A standard UML2 «subsystem» is a "logical" grouping of functional requirements represented as Use Cases. It does NOT (usually) to the "physical" software Classes/Component of a software system that collaborate to provide users with functional services.

A SysML «subsystem» is a non-normative extension of block; it is a "physical" grouping of blocks within a SysML«system».

---

TIP: Although not standard SysML, you MAY sensibly combine the standard UML subsystem and the non-normative SysML "physical" subsystem concepts in one M D SysML model.

---

See also:

• Figure B.5 - Establishing Top Level Use Cases for the Hybrid SUV

• Figure B.6 - Establishing Operational Use Cases for Drive the Vehicle

Why does the classifier-level <<Block>> stereotype show on parts Properties in an IBD ?

MagicDraw UML uses a mechanism called "secondary stereotypes" (a.k.a. translucent stereotypes).

In the absence of an instance-level stereotype the classifier-level stereotype "shows through" the part.

As soon as one introduces an instance-level stereotype the classifier-level stereotype is screened out.

 

Why is the MD SysML <<ConstraintParameter>> implemented as a Port, rather than just a Property ?

A constraint parameter is a property of a constraint block.

When a constraint parameter is displayed in a parametric diagram on a usage of its constraint block it is displayed using a "small box notation" very similar to the existing port notation. Since a Port is a Property anyway it makes sense to leverage the existing port drawing facility. Everywhere a port is used as a constraintg parameter it is clearly named 'parameter'.