How to construct a toolbox from different 'modules'?

[TheAllSparx]

For a project I am looking into the options to construct a toolbox from one 'base profile' different MDG Imports in a modular format.

We have a 'base' profile (and toolbox) called MIM. For different purposes we would like to be able to add specific sets of tagged values to the elements of this MIM toolbox, based on the modeler's needs. These purposes may vary from project to project.

We would not only be able to extent the toolbox with one other profile, but (if needed) with a number of profiles. For example:

• MIM+JSON+Domain-extention,
• MIM+Publishing+Domain extention
• etc.

It would be great if this is possible. And if so, I would like to know how to build this.

[Geert Bellekens]

Are you talking about toolboxes, or UML profiles?
Because tagged values are not related to toolboxes at all.

You can extend existing profiles with new profiles.
I don't think it's going to be as modular as you might like though.
You'll have to create a specific steroetype for a specific combination of base stereotypes.

Geert

[Mauricio Moya (Arquesoft)]

@Geert, I think he is talking about something similar to the behavior of BPMN 2.0 elements that change the behavior of the visible tag values according some other tags (like when you change an Activity type, then other tag values are visible or hidden). So, is this possible to do? or is it just limited to BPMN 2.0 because is a native MDG?

[Geert Bellekens]

@Geert, I think he is talking about something similar to the behavior of BPMN 2.0 elements that change the behavior of the visible tag values according some other tags (like when you change an Activity type, then other tag values are visible or hidden). So, is this possible to do? or is it just limited to BPMN 2.0 because is a native MDG?

No, you can't replicate that behavior using only an MDG. I don't even think you can replicate it using an add-in, unless you re-write your own versio of the properties dialog.

Geert

[Eve]

Since 16.0 you can reproduce it with an add-in. Including a model add-in.

https://www.sparxsystems.com/enterprise_architect_user_guide/16.1/add-ins___scripting/rulesbroadcast_showelementproperty.html

The entire "Technology Rules" section is providing some of the customization points that were previously only available to native MDGs.

[Paolo F Cantoni]

Since 16.0, you can reproduce it with an add-in.  Including a model add-in.

https://www.sparxsystems.com/enterprise_architect_user_guide/16.1/add-ins___scripting/rulesbroadcast_showelementproperty.html

The entire "Technology Rules" section provides some of the customization points that were previously only available to native MDGs.

So, does this mean we can override the default EA behaviour and enable properties that are normally hidden (for example, multiplicity for Dependency arcs)?

Paolo

PS: I note with interest that the field named "Class" will never contain a Class, but only a Metaclass or Stereotype!  "you might well think this naming is inconsistent; I couldn't possibly say that...

[Eve]

PS: I note with interest that the field named "Class" will never contain a Class, but only a Metaclass or Stereotype!  "you might well think this naming is inconsistent; I couldn't possibly say that...

A stereotype is a specialized class and a metaclass is just a class at the metamodel level. Both are a class. Besides, I don't know about you, but I don't want to use something like metaclassOrStereotypeName.

[Paolo F Cantoni]

So, does this mean we can override the default EA behaviour and enable properties that are normally hidden (for example, multiplicity for Dependency arcs)?

So, is there an answer to the substantive question (my emphasis)

Paolo

[Paolo F Cantoni]

PS: I note with interest that the field named "Class" will never contain a Class, but only a Metaclass or Stereotype!  "you might well think this naming is inconsistent; I couldn't possibly say that...

A stereotype is a specialized class, and a metaclass is just a class at the metamodel level. Both are a class. Besides, I don't know about you, but I don't want to use something like metaclassOrStereotypeName.

Well, since you asked...

As you say, they are both specializations of Class, so I would have named it "Type Specialization" (or even just "Specialization") and described it as "Specifies the type specialization this property was defined in. In the UML namespace, that means the metaclass as defined in UML. Otherwise, it will be a stereotype."

Paolo

[Eve]

Well, since you asked...

I don't see any question.

As you say, they are both specializations of Class,

No, one is a specialization of class. The other is just a class.

so I would have named it "Type Specialization" (or even just "Specialization") and described it as "Specifies the type specialization this property was defined in. In the UML namespace, that means the metaclass as defined in UML. Otherwise, it will be a stereotype."

Paolo

By using the word Type you are referring to a specific UML class. (Whether you mean to or not) Class happens to be one of the specializations of Type. Unfortunately, that means you've taken the accurate reference to Class and made it less precise. You're now referring to a lot of other possible classes. The properties that EA will query can be from those classes, but it would be wrong to say that they come from an enumeration or datatype.

More than that, the word specialization is just confusing the issue. A specialization doesn't define any properties, it is a property (called specific) of a Generalization so using that would make the whole description wrong.

So, does this mean we can override the default EA behaviour and enable properties that are normally hidden (for example, multiplicity for Dependency arcs)?

No, it's driven by the metamodel, not the EA datamodel. Both the UML metamodel and the profile metamodel (Yes, a profile is a metamodel just as much as UML is)

[TheAllSparx]

Well, that's a rich discussion! I'm not shure if this really answers my question. I need to have a closer look to determine if it does.