Constraints appear as parts instead of constraints

[Daniel SBZ]

Hello everyone!

I am trying to assign constraints to a block in a BDD by means of connecting a constraint block to a block through a part association.

However, when I do such relation, the constraints appear in the part comparment as <<constraintProperty>> with the name of the block instead of appearing in the constraints compartment (This is such a mess because it is in the same space as other parts of the block).

Any hint about what could be going on? I am new to Enterprise Architect and there are many options I am not familiar yet.
Thanks in advance
Daniel

P.D. All the constraint-related checkboxes in the comparment visibility window of the block are checked.

[PDC]

Constraints are normally (I think) added to Elements using that Element's 'Properties' window ("Constraints" tab). These are the ones that appear in the Element's 'Constraints' compartment on the BDD.
ConstraintBlocks (or any other Element) will by design be added as Parts when using a Part Association.
If you are married to the idea of using ConstraintBlocks then you could consider using an Allocate to link them to your main Block. I guess maybe it depends on the content of your ConstraintBlock (edit: sorry should elaborate - this is because Constraints and ConstraintBlocks are used for different purposes!).

[Daniel SBZ]

Thank you very much for the reply Phil!

I thought that Constraint Blocks were used to create constraints and then, by Part Association, my Block would inherit those constraints.

Regards.
Daniel

[PDC]

Acording to the SysML spec (section 10.1) "Constraint blocks provide a mechanism for integrating engineering analysis such as performance and reliability models with other SysML models". The example given (10.2.1) suggests a constraint based on a mathematical operation, where the input parameters to that operation will be taken from elsewhere in the model. Another common example is something like Newton's laws. The idea is that you are defining a constraint to be reused/obeyed in various places throughout the model.
Constraints within the 'Properties' of an Element are typically conditions around the behaviours and existance of an instantiation of that Element. E.g. a certain precondition is expected/required prior to execution of an Activity.

There are better summaries of the differences online, as ever Google is your friend.

But coming back to your question. I'm not sure that it would logically make sense for a Block (a classifier) to have Parts that are defined as ConstraintBlocks. It may depend on what your constraints are trying to achieve, and what your Block is actually defining, but Part Association doesn't feel right to me. Although EA will let you do it

[Daniel SBZ]

Thanks again for replying Phil!

Good explanation. I was trying to represent that the mass of a block is the result of the sumation of the masses of other 2 blocks through a constraint block. But now I see that It makes much more sense to represent this sum as a constraint within the properties of the block.

Regards
Daniel

[PDC]

Ah ok, I'm with you now. I guess the 3 masses in your model (the Block's mass and the 2 constituent masses) are represented in your model. As always there are probably multiple ways to do what you want; a ConstraintBlock might actually make sense, or your suggested method of an invariant constraint in the Block properties... but possibly using Parametrics would be the 'purists' way to aggregate the masses and place a constraint on the total. I guess it all depends on what you plan to do with that constraint in your model. Constraints and ConstraintBlocks will give a quick-and-easy, traceable placeholder for that bit of data, but the Parametric approach would probbaly be more powerful in terms of integration with the rest of the model.

In my role I often answer questions by saying 'it depends' and I'm wholly aware of how it's not always the most useful answer!