Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - adepreter

Pages: [1] 2 3 ... 13
2
Is there a way to set the ContextObject to a specific connector in the currently active diagram.
So that Repository.GetContextObject() can then return the connector.

I tried activeDiagram.SelectedConnector = connector;
This selects the connector in the UI. But Repository.GetContextObject() does not return the connector.

3
Thank you Geert  :)

So the trick would be to
- Get the ID of the active MDG. Maybe by getting the prefix of the active diagram... (if any)
- Identify the path/url of the active MDG file (need to figure out in the case where it is not in Program Files)
- Load and parse the xml file

Would that make sense?

4
Hello,

How could I get the list of element types/stereotypes and their properties/tagged values for the active language?

Thank you in advance,
Alain

5
Quote
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.

6
The option to disable the toolbox filter that is restricting the connectors should be available in views.
For now it is only available in diagrams.

The customer problem is:
1) a metamodel is not specific to a view but to an entire system that the model can represent
2) nobody can predict what additional type of element could clarify a specific view, beyond the typical set of constructs used for such viewpoint.

7
Following discussions with a customer...

** MODEL AND METAMODEL ***
A modeling tool is used for modeling systems.
A system can be a software system, an enterprise, a city, a country…, or a vehicle for defining and planning changes to a system.

!! A metamodel is not specific to a view but to an entire system that the model can represent.

!! Therefore, quick linkers and connector validation need to apply to the metamodel of the entire system.


** VIEWS **
!! Views (on a system) address specific stakeholders concerns using a typical **but not limited** set of modeling constructs available in toolboxes and contextual guidance.

Systems visualization vehicles include diagrams, charts, reports, matrices, documents etc.

The scope of visualization includes the as-is , transition and to-be states of a system (any system), along with the description of alternative solutions that can change the state of the system towards defined goals and related target capability roadmaps.


** CONSTRAINTS **
There need to be restrictions on the types of elements contained in specific typed catalog packages.

!! There should be no restrictions on the type of element and connector that can appear on a view and its quick linkers, since nobody can predict what additional type of element could clarify a specific view, beyond the typical set of constructs used for such viewpoint.


THEREFORE
The option to disable the toolbox filter that is restricting the connectors should be available in views.
For now it is only available in diagrams.

8
You could use Low Code Powerscripts:
https://www.labnaf.one/EndUserMaterial/Labnaf_PowerShell/Labnaf%20PowerShell%20-%20Reference%20Guide.pdf

These can be scheduled. You can use environment variables either in the scripts or in the SQL queries used by those scripts.

9
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).

10
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

11
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.

12
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

13
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.

14
There is an API to set an MDG active.
But I could not find any API to get the name of the MDG that is currently active.

Work around could be: Get the prefix from the fully qualified active diagram stereotype.

Anything more direct?

Cheers,
Alain

15
Automation Interface, Add-Ins and Tools / Feedback from MDG specializations
« on: December 24, 2023, 05:38:57 am »
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

Pages: [1] 2 3 ... 13