Conditional Properties in MDG

[Paolo F Cantoni]

I'm pretty certain I know the current (v15.1) answer to this, but since the last time I asked a "rhetorical" question I actually got a good answer from Sparx Japan, I'll ask anyway.

Now that we have "animal farm" tags ("All tags are tags, but some are properties"), is there any way to specify in the MDG that a tag is conditional (or optional)?

It seems to me that the property tags are mandatory (that is their existence is mandatory, their value may be discretionary).  Ordinary tags, on the other hand, can be optional (by definition).

I believe there is a place for such optional property tag, but there doesn't seem to be a mechanism to handle this.  Am I wrong?

TIA,
Paolo

[Eve]

It seems to me that the property tags are mandatory (that is their existence is mandatory, their value may be discretionary). 

Not quite.

Stereotype properties are always instantiated with the stereotype. You could handle EA_OnPostCreate* to delete one or more tags to change that behavior. The result would be the the UI would no longer show that property. A user could then manually add it back using the add tagged value dialog (selecting the qualified name) and it would go back to its normal location.

On a purely conceptual level the property may still be there, but for any practical definition it's not.

It sounds like you are interested in similar behavior to BPMN, where depending on the value of other properties some may be visible or hidden. (That's not currently possible to implement in your own technology, still hoping we can get there)

[Paolo F Cantoni]

Thanks, Eve,
Most helpful!
I'll reply in-line with some more quesiotns...

It seems to me that the property tags are mandatory (that is their existence is mandatory, their value may be discretionary). 

Not quite.

Stereotype properties are always instantiated with the stereotype.

Confirming that their (notional) existence is mandatory in the Profile.

You could handle EA_OnPostCreate* to delete one or more tags to change that behavior. The result would be the UI would no longer show that property.

I take it there is NO UI method to do this.  Seems reasonable that there shouldn't be.

A user could then manually add it back using the add tagged value dialog (selecting the qualified name) and it would go back to its normal location.

Confirmed...

On a purely conceptual level, the property may still be there, but for any practical definition, it's not.

Not sure I follow here.  See my discussion below.

It sounds like you are interested in similar behavior to BPMN, where depending on the value of other properties some may be visible or hidden. (That's not currently possible to implement in your own technology, still hoping we can get there)

Not quite.  However, that would be a useful mechanism, especially if diagram dependent.

What I'm after is similar.  I'll describe an envisioned process (because it's simpler than a declarative). 

The profile defines the set of tags that will be considered properties of specific metatypes and the remaining "less equal than others" (in the profile and the general set) are just tags. 

If the tag is a property tag and it is missing from the metatype instance, then the tag name can be greyed out (disabled) and the value is either empty or designated extrinsically as "«Missing»".  If the user double clicks the name, they are asking to create the tag and the normal process is invoked.

If the tag is designated as optional in the profile, then if a default value is provided, then it will be instantiated with the default value at the metatype instantiation (or even stereotype synchronisation). If no default value is provided, then it is not instantiated (and thus the name is greyed out etc.).

Hopefully, that's clear.

What do other's think?

Paolo

[Eve]

From my understanding of the UML Specification...

There are no such thing as optional properties. A property with a multiplicity of 0..1 still exists on every instance, the multiplicity corresponds to the number of values that it can hold. (So it's akin to nullable properties in a variety of programming languages)

The UML (and EA) way to implement an optional property with behavior like you are describing is adding an additional stereotype. Then the element doesn't have that property until you want to create it by applying the extra stereotype.

If I remember correctly, you have house rules that prevent using multiple stereotypes. That probably influences the reason why you would like optional properties. My personal opinion is that adding optional properties as you describe to a single stereotype goes against the intention of UML and I wouldn't want to see it happen.

What I would like to see happen that's relevant to this conversation is better handling of multiplicity within UML profiles in general. Allow removing of all values if the lower bound is zero. Allow adding an extra value in an easier way for all types if the current count is less than the upper bound.

[Paolo F Cantoni]

Thanks, Eve,

Most helpful! I can see your points and will investigate the use of multiple stereotypes in our context more deeply (probably via a separate thread).

"What I would like to see happen that's relevant to this conversation is better handling of multiplicity within UML profiles in general. Allow removing of all values if the lower bound is zero. Allow adding an extra value in an easier way for all types if the current count is less than the upper bound." - Agreed!

BTW, as a "Data Dude" NULLS are anathema!

Paolo

[Paolo F Cantoni]

Hi Eve,

As you know we've been playing with supplemental stereotypes and multiple inheritance to good effect.  However, we've concluded that optional properties are still needed.  Can we put in another request for their implementation?

In the interim, we'll use a mechanism to simulate them (in our case via direct background SQL query - since it's easiest), but direct support would be preferable.

Paolo