Book a Demo

Author Topic: v15.2 – TaggedValueTypes can’t be created in MDG WITHOUT being “LIVE”!  (Read 3039 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
If I could add multiple "Thumbs down" for this one, I would!  Notwithstanding Eve's protestations, this HAS TO BE a defect!  :o  :o

So I'm, finally, getting some time to play with "TRUE" Model-Driven Generation.  The general process is:
  • Create an appropriate profile diagram (for the specific profile)
  • Save the diagram as a profile
  • "Knit" the profiles together via the generation process and the MTS file
This works well, UNTIL you get to Tagged Value Types (TVTs)::) ::)

In line with what, I believe, should be the best practice for Technology-based modelling, we have moved all the appropriate TVTs to the technology.  We have nearly 400 in use across the enterprise (and counting)!  Consequently, there are NO "live" TVTs (under Configure | UML Types | Tagged Value Types)
So I tried looking for the Tagged Value Types definition diagram.  No luck.  So I tried adding Tagged Value Types to the list of things to be generated, only to find that the process requires that:
  • You can ONLY select from the list of "live" TVTs
  • You have to manually select which ones to include
Given the large number involved, this will be problematic.  But, MORE IMPORTANTLY, the UUIDs generated for the "live" TVTs and those of the Technology are NOT the SAME there for as "Boss" would say, "Sol, TVTs ain't TVTs".  [1]

This is NOT acceptable - it is clearly unthought out!  If there is an alternate way to do this which is more in-line with the process described earlier, then I couldn't find it.  (a documentation defect)

FIX IT!

Reported,
Paolo

[1]Becasue we understood this dichotomy in UUIDs, we earlier moved the TVTs to a "special" repository that is only used to manage the set of TVTs we want to use in the technology (the hand-crafted one) - so that things (and especially users) would not get confused by the non-identical "twins".   Well, that was a waste of time...  This worked VERY well until now.
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
For cases like this I usually have three repositories: DEV, TEST and PROD

DEV contains all the MDG models, all tagged value definitions, all scripts, all RTF templates etc, but has none of our own MDG's installed.
TEST is used to deploy the generated MDG file and test if it all works correctly.
Only after we verified the MDG in TEST we deploy to the production repositories.

So the "Live" TVT's would only be defined in my DEV environment.

I try to avoid unattached MDG tagged value types and work as much as possible with Stereotypes and their properties.
In case I can't avoid unattached tagged value types, I usually use refdata export/import instead of including them in the MDG.
I find the MDGName::tagName a bit clunky

But I don't see a defect in the way the TVT's are selected or generated in an MDG.
I even believe the UUID's should be different, as I can export the same tagged value type in different MDG's

Geert

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Hi Geert,
My beef is not that the UUIDs are different, that's accepted.  But as a consequence, we shouldn't be using any "live" things in the MDG generation.  We don't use Live stereotypes, live diagrams or live toolboxes etc. Why live TVTs?  I can't express the metamodel as a series of views from the required viewpoints.  The TVTs are hidden!

Our TVTs are not unattached if I understand you correctly, they are assigned to stereotypes as required.  It is extremely cumbersome to add profile based TVTs so it's not a big issue.  In any event, where the same property is to be used in multiple stereotypes it should be designed once in the TVT list.

Just to clarify.  It just gets at my "consistency" thang!

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!