Feedback from MDG specializations

[adepreter]

Hello MDG experts,
What is your experience in specializing existing MDGs/UML Profiles/Stereotypes compared to creating these from scratch?
What limitations did you encountered?
Cheers,
Alain

[qwerty]

I would say: it depends. Do you have issues?

q.

[adepreter]

In terms of MDG specialization, I am particularly interested in
- Adding tagged value types
- Adding properties (using these types)
- Adding connection constraints
- Removing all quick linkers and replacing by new ones

What are the limitations compared to recreating an MDG from scratch or patching a MDG XML?

I am also wondering what the impacts/limitations are in Prolaborate.

Documentation about this topic is scattered all over the place.

[qwerty]

Patching XML is possible but that will lead you into a cul-de-sac and you are completely responsible for that file. I usually make a "good choice" of what can go into a profile and steal/re-create a new flavor using thw Profile tools in EA. Makes me responsible too but on a better level than XML-patching.

q.

[Eve]

- Adding tagged value types
- Adding properties (using these types)

Follow Redefine Stereotypes in Another Profile

- Adding connection constraints
- Removing all quick linkers and replacing by new ones

Adding outgoing relationships is easy. Removing them requires creating a constraint for the existing relationship types targeting the metaclass '<none>'.
Define Metamodel Constraints

Incoming relationships can be added in the same way you add references to external stereotypes in your profile.

What are the limitations compared to recreating an MDG from scratch or patching a MDG XML?

Just don't patch an MDG XML.

Documentation about this topic is scattered all over the place.

The links I provided to answer your questions are together within Create Stereotype Profiles

[adepreter]

Thank you Eve.

I need to remove all relationships (and generate new ones).
Creating a constraint for each existing relationship sounds very complex for the purpose.

If I generate quick linkers, will this replace all existing relationships?

What is nice about quick linker definitions, is that they are separate from the stereotype definitions.
That follows the subsequent steps in the language authoring process. We don't care about QL's readability since they are generated.
Also, my users don't want restrictions about the elements that can be created in a diagram. Especially solution architects.

What would be nice is , for the QL format, to have the new user interface when dragging a QL into an empty space in the diagram to create a new element and connector.
1) Getting the list of target or source elements 2) select the connector
That would be really useful.

Thank you in advance,
Alain

[Eve]

I need to remove all relationships (and generate new ones).
Creating a constraint for each existing relationship sounds very complex for the purpose.

Then it sounds like you don't actually want to extend an existing MDG. The functionality is built on the premise that a user may want to replace a subset of the relationships. What you're wanting to do is just the extreme end of that use case, so yes it would result in you doing a little more work.

If I generate quick linkers, will this replace all existing relationships?

Are you referring to the old quicklinker table? No, can't suppress relationships from a base profile.

What is nice about quick linker definitions, is that they are separate from the stereotype definitions.
That follows the subsequent steps in the language authoring process.

Sounds like a drawback.

We don't care about QL's readability since they are generated.

Then you're outside the scope of anything that can be supported.

Also, my users don't want restrictions about the elements that can be created in a diagram. Especially solution architects.

As long as you don't use a view specification EA doesn't restrict elements that can be on a diagram. The quicklinker does show relationships to items currently shown on the toolbox by default, but if your users want to change that behavior for a diagram, they can. You can't change it for them.

What would be nice is , for the QL format, to have the new user interface when dragging a QL into an empty space in the diagram to create a new element and connector.
1) Getting the list of target or source elements 2) select the connector
That would be really useful.

I'm confused. Isn't that what you get already? At least when you've defined the possible relationships via the metamodel you get a list of possible element types followed by the list of valid connectors to that type. It can be swapped around though and I can't remember which is the default.

[adepreter]

Thank you for your quick answer, Eve.

Based on your input I can rephrase the question as follows:

How can we specialize a language by providing a full new set of quicklinkers where the scope is the entire language metamodel i.e. not just a diagram type or viewpoint?

The toolbox should show only what is usually relevant for that type of diagram type/view.
But, when dragging a QL into an empty space in any diagram to create a new element and connector, users should not have to go through an intermediary step to access additional quicklinkers.

[Eve]

The toolbox should show only what is usually relevant for that type of diagram type/view.
But, when dragging a QL into an empty space in any diagram to create a new element and connector, users should not have to go through an intermediary step to access additional quicklinkers.

Two incompatible requests to the way quicklinkers have been designed to work. But you already know this because I've told you that before.

Your first statement demonstrates why. If the toolbox is what is required for a view type (even if only usually) then every connector that doesn't match the toolbox offered by the quicklinker is just noise (most of the time).

[ducatiross]

Adepreter - sounds like you want a Toolbox/diagram type that allows ALL elements from EVERY notation EA has to offer.

Recipe for chaos, me thinks !

Good luck with your solution architects doing anything consistent and standardised there ! Constraints are there for a reason 

[adepreter]

Our experienced users want toolboxes that show elements relevant to each viewpoint.

But they also want to easily create relationships to new elements that are
- not in the toolbox
- available through the quick linkers

[Eve]

Experienced users want toolboxes that show elements relevant to each viewpoint.

But they also want to easily create relationships to new elements that are
- not in the toolbox
- available through the quick linkers

We're mostly in agreement. A viewpoint is about defining what aspects of your model diagrams/views are trying to show.

Toolboxes and quicklinkers are just implementation details. We agree that the toolbox should reflect the types that are needed for that viewpoint. The point of contention is whether the given view should give equal weight to creating the relationships that are part of that viewpoint to those that are not. I don't think I've seen a reason why they should be equal, only the assertion that they should.

If I remember correctly, you used to have no relationships on your toolbox and when we made changes that meant the quicklinker conformed to the current view as defined by the toolbox it broke your workflow. I don't think that rises to an argument for different behavior though. Especially since there was a workaround using the diagram filter column of the quicklinker, which was an early attempt at supporting viewpoints in the quicklinker.

As for your assertions about "experienced" users. Yes, there may be situations where an experienced user may feel that adding a particular element outside of the viewpoint would improve the message of this particular diagram. Just as with adding the non-relationship elements, the fact that a given element is not available by default should be a prompt for them to consider if it actually the most effective way to communicate. It's still possible, but maybe it should be added to another diagram. Experienced users should also remember when they thought they were experienced and as a result broke the rules more often than they should have, and understand why that prompt is necessary.

Ultimately, I don't think the decision to ignore viewpoints for relationships is up to you as a technology author.

[adepreter]

Hi Eve,

Could you kindly take a step back for a moment?
Remember, it's wonderful how we each bring unique knowledge to the table.
Alone we might be individual towers, but together, we form a strong and magnificent castle.

It is not just about tooling. Though I believe you are thinking of another tool.
Why would anyone create a large set of toolboxes without any connectors? EA views never broke our workflow.
Look at this: https://www.labnaf.one/framework-components/content-component/language/dynamic-self-documenting-metamodels-what-are-they/

Our point is:
-- Nobody can predict what additional type of element could clarify a specific view. --
We suggest EA mechanisms to take this into account. For now we rely on the "quick linker format".

Our context is:
-- Enterprise transformations and related framework engineering --
Customers: Expert digital transformation professionals.

* Recommended steps to create a transformation framework (applicable to any other type of framework):
https://www.labnaf.one/videos/Framework/Why-modeling-an-enterprise-like-a-system.html
1) Define the end-to-end transformation process (inspired by standards as needed)
2) Define the viewpoints and catalogs packages used throughout cover the process
3a) Define the single language and metamodel that is used to populate views
3b) Ensure metamodel consistency using systems semantics (an enterprise operating model is a system).

[Eve]

Look at this: https://www.labnaf.one/framework-components/content-component/language/dynamic-self-documenting-metamodels-what-are-they/

Yes, I've seen labnaf. Particularly the way it attempts to describe the metamodel by example. It's not clear to me why that is relevant to what relationships should be offered to the user.

Our point is:
-- Nobody can predict what additional type of element could clarify a specific view. --
We suggest EA mechanisms to take this into account. For now we rely on the "quick linker format".

Then the user can overwrite the view as needed by disable the toolbox filter that is restricting the connectors. The idea of forcing all connectors to show is much too disruptive to the 90% of users where the restricted set of connectors is appropriate 95% of the time. Those numbers are entirely made up, but my assertion is that most of the remaining 10% are less experienced than they think and are making too many exceptions and it's detrimental to their models. The 95% is probably even higher.

Even if I take it the other way though. If 80% of the time the person defining the view has provided the right connectors, and by doing so end users save 5% of the time looking for the connector they need I'd consider that a win.

[adepreter]

the user can overwrite the view as needed by disable the toolbox filter that is restricting the connectors

The point is that the option to "disable the toolbox filter that is restricting the connectors" is currently not available in views.
It is only available in diagrams.