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 - Paolo F Cantoni

Pages: [1] 2 3 ... 484
1
Hi Paolo,
[SNIP]
…Firstly, the concept of "instance" is problematic for me...
The "instance" concept was on my mind for a few days during our discussions, as I challenged what is meant by "instance".
You may care to investigate some views I have on the matter of instances (earlier in the Forum).  Your thoughts would be appreciated.
Quote
…the concepts of having multiple "instances" on the diagram implies multiple "instances" in the model, otherwise, you have broken the one-to-one relationship you assert...
Yes, I realised the term "instance" was not clearly defined, since we both interpreted the word in a different context: my context was in reference to "diagram", your context was in reference to "model".
Isn't it amazing that this discussion demonstrates a real-world example of how often definitions mean different things to different people based on different contexts? How important then is the use of a common business vocabulary between "techies" (say as ourselves) and the "get-paid-a-lot-to-know-nothing" management of a business? This example, to me, shows the importance of context.

How many times do we use words or terms that are not the same as what our target audience think? Because of this difference, we end up teaching business people to speak our tech language.
That's what ontological models are for.  Our repositories use them to create "Controlled Languages".  You get 5 business people you get 7 languages.  The controlled language (not tech language) is the only way out.  As my tag line says...  "There is no such thing as an inconsistently correct system".
Quote
I believe no argument exists for the statements that (1) a model must only EVER contain a single "instance" of an element, and (2) a diagram contains multiple visual "instances"
Now, Michael, I'm afraid you're insisting on calling "a Spade a blo*dy Shovel" (as the colloquial saying goes).  By continuing to use "instance" for "rendering" you "muddy the water".  In my view, it is clearer (and more semantically valid) to say "this diagram contains 3 renderings of item X".  It can become unclear as to which instance you are discussing if you don't consistently qualify "instance" with "model instance" or "visual instance", as appropriate.
Quote
…the (correctly implemented) VCE is the mechanism to consistently achieve this.  So that the diagram and model are still "in synch"...
Absolutely. Problem is that this is difficult to achieve right now.
I believe that ALL options we currently have will yield invalid diagrams and models.  The current (defective - in our joint view) VCE implementation is merely "the best of a bad lot".  I believe we should put our efforts in getting Sparx to fix the VCE,  heaven forbid they should actually ask us what we think might be the desired result.
Quote
...However, it will NOT materialize the relationship if none exists when you visually embed.  This is unfortunate.  We have written scripts to materialize such relationships into the repository...
Interesting... initial reaction is that this is "as-is". Since elements on a diagram should be related to something, then surely this behaviour is correct? I'm intrigued to know more about why you wrote scripts to materialize these relationships... because... I'm thinking... "ArchiMate". (things like, when we embed elements, technically we are 'composing'/'aggregating' those elements, but Sparx won't create the relationships automatically because it's a UML modelling tool, not an ArchiMate tool. And that's why we'd have to script this logic)
In my view, the reason EA doesn't do this has nothing to do with the UML vs ArchiMate tooling.  It's just nobody understood this was necessary to materialize these relationships to create "fully fleshed" models.  Now it may be too late.

EA has a number of relationships between vertices what are NOT found by following arcs between the vertices.  We took the view that if a relationship exists in the model, it should be expressible as an arc.  Incidentally, this is an example of my "same semantics, different syntax" pattern.  Consequently, we materialize many of these relationships as arcs where required.
Quote
[SNIP]
Say hello to ArchiMate and derived relations. Derived relations are exactly what you describe in that they don't "exist" but are inferred based on rules of precedence and type of connector. The derivation is based on mathematics.
Indeed!   I am very familiar with derived relationships and I like the ArchiMate mechanism.  The problem that is faced is that sometimes you want to "render" these derived relationships[1].  They assist in making model diagrams simpler without losing the underlying consistency (as per your example - excised).   However, they represent, potentially, a "combinatorial explosion" of arcs!  We materialize these derived relationships only as required.  They are clearly distinguished from the canonical relationships.
Quote
…My point is that if we break the modelling paradigm (which the VCE - in my view - doesn't) then we aren't modelling any more, just drawing pictures....
Ah! Good question. When you present your pictures to stakeholders, which of the following do they tend to see
  • Pretty pictures of boxes and line "thingies"?
    They look at The Pretty and think "it looks pretty. Colour scheme is good. Wow there's a box that states "CRM" and another that states "SQL". OK. Got it! Let's build this thang!
  • A well-thought out conceptual model?
    They heap praise on us for our chastity and purity in the UML presented before them but haven't got a clue what's going on. So, we have to declare what is a PO-TAY-TOOAH (see historical account above)
I think based on the question and your statement, that modelling and drawing pictures go hand-in-hand. The pictures must look good and be easily digested, while the model must enable us to maintain governance.
We don't present UML.  We have gone beyond UML and ArchiMate.  We are working on a "Digital Twin" form of modelling so they can see shapes that represent REAL items in the real world.  Where we need to display an abstracted placeholder (such as "ERP System" for "SAP R3") we use placeholder items which are distinguishable from the real items that might "fit the bill".

Just as the concept of "Instance" is problematic for me, I've (almost) done away with the concept of "Classifier" for real world (as opposed to Code Generation) modelling.  We have  replaced it with a placeholder with query specification so that we can automagically maintain the set of instances that can "fit the bill".  (Placeholder Actor) "Data Architect" has a specification for which (actual Actor) "Paolo Cantoni" [2] can be "substituted" at query/runtime (analogously to the Liskov substitution principle (LSP)).

Paolo

[1]  Another time (and probably off-line) I can recount an interesting encounter with Jim Rumbaugh (before the three became "amigoes") and derived relationships.
[2]  But hopefully, (actual actor) Julius Caesar won't be substituble!  ;)

2
In the v15.2β (b 1553), if I use the QuickLinker to joint two vertices (in this case DB tables), I get one set of linking options.  If, however, I use the "Link to Element Feature" widget e.g. <[  I get a different set (in this case a superset).

Why? Is it just me?  Is this a defect?  I would have thought so, but Eve may differ.

TIA,
Paolo

Concistency, konsistency, consistensy! TMUffe - after Paolo

3
In the v15.2β (b 1553), if I use the Quicklinker for DB Modelling FK Associations between table, I don't get the option of Association.  I have to use the Association arc in the Toolbox.

Is it just me, or has it always been thus?  Why?

I don't think it's one of those Perspective issues, but what would I know?

TIA,
Paolo

4
Also, good luck with the patterns. They don't work all that great.
Hi Uffe,
As you might guess, we're going to implement "patterns" in our own way.  If you're interested, we can have an online (or offline) discussion on how patterns could/should be implemented in a modelling context.  I'd be keen to understand as much as necessary to enable us to come up with a viable implementation.

Paolo

5
Suggestions and Requests / Re: Specialize: remember pattern settings
« on: August 04, 2020, 11:35:32 pm »
Wot 'e sed!

We're about to get into patterns and this would be required.

Paolo

6
When creating metatypes in the MDG, we can have multiple-inheritance.  When generated by the MDG Generator, the order of the base stereotypes is alphabetic.

However, since there may be multiple paths to the new metatype, what is the precedence order of applying properties, constraints etc?  For example if one path implies _HideUmlLinks=false and another implies _HideUmlLinks=true, which takes precedence?

TIA,
Paolo

7
In a recent post Abstract metatypes won't automagically generate <stereotypedrelationships> for an arc, Sparxian Eve, said "I don't know why EA needs both generalizes and baseStereotypes. What I do know is that prior to it being explicitly alphabetically ordered the order was unstable."

In another post (Re: v15.2β - Redefining EAUML::FK) Eve said (paraphrased): "generalizes always has one stereotype, but baseStereotypes needs to have all"

Given that the Sparx MDG generation process places the first alpha from the baseStereotypes list into the generalizes attribute, do I understand correctly that (so long as the value in the generalizes attribute is in the list for baseStereotypes) the value is essentially irrelevant?

Paolo

8
Easy question first.
1 It actually generates a slightly (but not substantively) different specification!  :o  The baseStereotypes are always in ascending alphabetical order and the generalizes attribute is always the first alpha stereotype!  ::) (who dreamt that one up?)
Connectors (unfortunately) are not an ordered relationship. I don't know why EA needs both generalizes and baseStereotypes. What I do know is that prior to it being explicitly alphabetically ordered the order was unstable. It created a lot of extra work when generating a large technology and reviewing the changes. (Also for tagged value connectors and the three metamodel constraints.

I hope you can agree that any defined order is better than no defined order.

In terms of your actual issue...

Am I correct in my understanding that stereotypes extending EA relationship types aren't inheriting their constraints? Is it just with multiple inheritance or does it fail for all inherited constraints?
(my emphasis)Yes, indeed! A defined order is better than no order.  As I have been wont to say "it's better to be consistently wrong (the current situation) than inconsistently wrong (the previous situation)"  ;)

As to your question about constraints.  I'm not sure if constraints are the issue.  If both ends of the (potential) serving relationship are vertices, the QuickLinker works fine (with only the abstract definitions in play - have I explained it correctly?).  If one end is an arc, it doesn't.  Since I posted the original snippet, I've found that:
Code: [Select]
<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::Srvng" constraint="MyProfile::SrvdItm"/>
</stereotypedrelationships>
also works when added at the arc.
To me, it seems like EA is just ignoring the abstract definition with the multiple inheritance and so I have to materialize it at the concrete arc.

Paolo

9
We've been using supplementary metatypes to automagically generate <stereotypedrelationships> (rather than needing to explicitly specify them at the concrete metatype level).  It's pretty good!  (some "niggles" notwithstanding - see:"With loss of generality" - <stereotypedrelationships>)

An example is:
Code: [Select]
<Stereotype name="SrvdItm" metatype="Served (item)" notes="Can have an inbound Serving relationship" isAbstract="true" generalizes="Root" baseStereotypes="Root">
</Stereotype>
<Stereotype name="CnSrvItm" metatype="Can Serve (item)" notes="Can have an outbound Serving relationship" isAbstract="true" generalizes="Root" baseStereotypes="Root">
<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::Srvng" constraint="MyProfile::SrvdItm"/>
</stereotypedrelationships>
</Stereotype>
Here, two supplemental metatypes are defined that define whether an item (typically a vertex) can generate an outbound or receive an inbound serving relationship.

We have a "root" metatype used to define the "highest level" of common relationships for the QuickLinker:
Code: [Select]
<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::Aggrgtn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Cmpstn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Inhrtnc" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Rstrctn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Spclztn" constraint="source.metatype.both"/>
</stereotypedrelationships>
As you might be able to infer, Aggregation, Composition, Inheritance, Restriction and Specialization.  In this case to "self" (ala ArchiMate).

By assigning the appropriate metatype to the appropriate vertex, EA will automatically create the QuickLinker entries for the serving relationship!   REALLY neat (and tremendously useful)!!!   8) 8)

For example:
Code: [Select]
<Stereotype name="Hrdwr" metatype="Hardware" generalizes="ClssVrtx" baseStereotypes="ClssVrtx CnSrvItm">
and...
<Stereotype name="Systm" metatype="System" generalizes="ClssVrtx" baseStereotypes="ClssVrtx CmpstItm AggrgtItm CnFlwItm FlwblItm AccssblItm SrvdItm">
(As can be seen, "System" is a complex vertex!)
Will generate the QuickLinker entry that Hardware "serves" a System.

However, when we apply the supplemental metatypes to an Arc, the QuickLinker entries are NOT created!   :(
Code: [Select]
<Stereotype name="Flow" metatype="Flow" generalizes="Root" basestereotypes="Root CnSrvItm">
and...
<Stereotype name="ETLJob" metatype="ETL Job" generalizes="ClssVrtx" baseStereotypes="ClssVrtx SrvdItm">
"A flow can serve an ETL job"
      
To get the entries, we have to add an explicit <stereotypedrelationships> to "Flow":
Code: [Select]
<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::Srvng" constraint="MyProfile::ETLJob"/>
</stereotypedrelationships>

This looks like a defect to me, but since I'm still "handcrafting" I may have missed something.

Can anybody shed any light as to whether it's a defect or my bad handcrafting?  (Actually, I checked via a test metamodel and it generates1 this definition)

TIA,
Paolo

1 It actually generates a slightly (but not substantively) different specification!  :o  The baseStereotypes are always in ascending alphabetical order and the generalizes attribute is always the first alpha stereotype!  ::) (who dreamt that one up?)

10
Yes, Enterprise Architect will only generate the latter form and will not accept the former.

There is no "should". If you are hand modifying something it is your responsibility to put it in the correct format.
Well, I know that in this particular case Enterprise Architect will generate this output from my model, but I'm NOT aware that it will always generate the "correct" output from a conceptually equivalent but differently specified model.

But my "defect" is not about generation, it's about acceptance.  As far as I'm aware, there is NO requirement that the MDG be specified using the MDG generation technology, and a number of users, myself included, have generated MDGs by other means.   If that is no longer a valid approach, please say so.

Surely, you will concede that having multiple specifications overwrite each other within the same section is conceptually spurious!  Why on earth would anyone want that?  Would the instances being additive be a more likely use case?  Particularly, in the light of the "correct" answer, where both conceptually and physically we have created an additive specification.

Can you point me to the documentation that says that the "correct" format is indeed so?

Paolo

11
Many of you will have heard me use the phrase "without loss of generality".   It's a mathematical term used in proofs to indicate that an assumption is being made that does not introduce new restrictions to the problem.

Note: this defect was discovered because I was "handcrafting" the MDG, but I believe it may be exposing some underlying issues.

We have a "root" metatype used to define the "highest level" of common relationships for the QuickLinker:
Code: [Select]
<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::Aggrgtn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Cmpstn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Inhrtnc" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Rstrctn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Spclztn" constraint="source.metatype.both"/>
</stereotypedrelationships>
As you might be able to infer, Aggregation, Composition, Inheritance, Restriction and Specialization.  In this case to "self" (ala ArchiMate).

So I wanted to add that a composition relationship also exists between any vertex and a "Composite Vertex" and an aggregation relationship exists to an "Aggregate Vertex."
Naturally, I added:
Code: [Select]
<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::Aggrgtn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Cmpstn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Inhrtnc" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Rstrctn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Spclztn" constraint="source.metatype.both"/>

<stereotypedrelationship stereotype="MyProfile::Aggrgtn" constraint="MyProfile::AggrgtVrtx"/>
<stereotypedrelationship stereotype="MyProfile::Cmpstn" constraint="MyProfile::CmpstVrtx"/>
</stereotypedrelationships>
I tried the new MDG and voila!  I got composition relationships to any CmpstVrtx (Composite Vertex) and aggregation relationships to any AggrgtVrtx (Aggregate Vertex) in the QuickLinker.  Great!
Imagine my surprise when I subsequently discovered that the "self" aggregation and composition relationships had disappeared from the QuickLinker!

Some hours of diagnostic testing over the weekend has revealed that with this syntax, "the last cab off the rank get the guernsey"!  In the example above, the MDG seems to scan the list of inputs and each subsequent definition of the same stereotype will overwrite the previous.  Thus for this version, you get the behaviour reported.  If you switch the order and place the CmpstVrtx and AggrgtVrtx BEFORE the source.metatype.both, you'll get the opposite behaviour.  "Self" works, but the others don't!

The "correct" syntax seems to be:
Code: [Select]
<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::Aggrgtn" constraint="source.metatype.both;MyProfile::AggrgtVrtx"/>
<stereotypedrelationship stereotype="MyProfile::Cmpstn" constraint="source.metatype.both;MyProfile::CmpstVrtx"/>
<stereotypedrelationship stereotype="MyProfile::Inhrtnc" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Rstrctn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Spclztn" constraint="source.metatype.both"/>
</stereotypedrelationships>
Where the additional stereotypes are appended.

However, it seems to me that "without loss of generality", both syntaxes should yield the same results!  So I'm reporting the defect!

Paolo

12
Hi Michael,

Thanks for the considered response!  I DO enjoy a good, and thought-provoking, discussion!  As you suggest, we might have different points of view on this, but actually, I suspect we might be more aligned than you propose.

Firstly, the concept of "instance" is problematic for me.  If you search the forum, you'll see I've pontificated ;) on this a bit (one of my nicknames in the past was "Pope Paul"  ;D).  Also, if you look at my other postings, you'll see I'm quite pedantic ("pedantry is your friend -when modelling" (in my experience)).

For me, the concepts of having multiple "instances" on the diagram implies multiple "instances" in the model, otherwise you have broken the one-to-one relationship you assert.

As I tried to show, I'm NOT against multiple renderings of the same item on a single diagram.  I'm merely saying that the (correctly implemented) VCE is the mechanism to consistently achieve this.  So that the diagram and model are still "in synch".

We already know that visual embedding is a form of rendering of relationships between items.  EA will (somewhat) correctly suppress the relationship arc when visually embedding.  However it will NOT materialize the relationship if none exists when you visually embed.  This is unfortunate.  We have written scripts to materialize such relationships into the repository.

Similarly, if we have multiple rederings of the same item on a diagram we are expressing that the item is related to other items on the diagram in some way; else why place it thereon?  If there is a relationship, then we can create a VCE.  I assert, without any mathematical proof, that every item on a diagram has to be in a (conceptual) relationship with at least one other item on the diagram (which may or may not be materialized in the repository) and consequently can be rendered multiply according to the number of potential VCEs that exist for that item on that diagram.

As you observe, connecting to the highest Instance_ID is not a modelling consequence, it is a defect.

We agree that we need to create diagrams suitable for the audience.  I've thought long about this and we came up with the notion of "presentation mode" where the item shape scripts can respond to the diagram type and become visually simplified automagically.  My point is that if we break the modelling paradigm (which the VCE - in my view - doesn't) then we aren't modelling any more, just drawing pictures.  To me the whole point of this effort is that when we change the model, the diagram chances accordingly (and, if possible, automatically) according to the rendering transformation rules we have previously defined for each diagram.

How far apart are we now?

Paolo

13
Hi Paolo,

...Virtual connectors are (in my view (and definitely that of others)) conceptually the correct way to handle this problem.  However - as you observe - the implementation "sucks"...
Yes agreed, conceptually correct, realistically not feasible.

Given the *visual*/*model* coupling present in the product, the implementation sucks and create odd behaviour when using virtual connectors, making this feature unusable. However, if we duplicate the SAME element in the t_diagramobjects table, viola! Two of the SAME instances appear. And diagram manipulation works... mostly.  However, manual replication is not recommended. Though doing this "works", the Sparx team decided to not make it available? Why? Instead we gotta settle for poorly implemented virtual connectors.
It's not that simple, Michael.  Just placing multiple copies of an item on the diagram "willy nilly" can be done with automation, but that presents its own problems.  If there are relationships to other items on the diagram and the relationships are needed to be visible, which instance of the item is to be connected to?   t_digramlinks (correctly) contains only the object id, not the diagram object id.  So EA can't know which diagram object to connect to.   The use of the VCE is the correct way to handle this as, by definition, each relationship connector now has its own virtual end to be managed.
Quote
...The basic issue, in my view is that the "VCE" is NOT implemented as a special type of t_diagramobject, but some sort of zombie diagram object with very few useful characteristics....
Absolutely. A host of issues are present because the Sparx team has not achieved separation of VISUAL and MODEL concerns. The product is a UML modelling tool. The *visual* IS the *model*. Due to this limitation, it seems the dev. team is forced to hack and add onto what already exists in their C++ codebase rather than unravel the potential complexities in their aging codebase. If "VCE" were implemented as ordinary diagram objects (with a link to the "originator" element), then bingo! Modellers are free to replicate the same element over and over and over and Sparx EA would treat the replications are pure diagram elements complete with all the features we need like embedding within a container.


[SNIP]
I don't agree here.  The visual is a View of the model.  It is also a data entry and output mechanism.  There is only one item in the model.
Having multiple instances of the same item on the same diagram is antithetical to the modelling process.  That's why the concept of a "virtual connector end" is valid.  We are not creating new instances of the item, we are allowing each end of the relationship to be rendered as we desire, but we aren't creating new instances.  As I said earlier, the implementation sucks because the rendered VCE is just another rendering of the original item and deserves it's own t_diagramobject to allow that (with an indication that it is a VCE, and not a "real" instance).  We should then be able to hide the connector (since that also is a rendering, not a modelling issue) and voila, we have a correctly modelled multiple rendering of the same item.

Paolo

14
General Board / Re: XMI export still has DELETED model elements
« on: July 31, 2020, 10:10:26 pm »
In Sparx EA "deleted" is an AMBIGUOUS term which I NEVER use.

If objects have been purged from the repository they physically can't be in the export since they no longer exist in the repository.

If they have merely been removed from one or more diagrams, they then still exist in the repository and SHOULD be exported if they are in the scope of the export.

HTH,
Paolo

15
General Board / Re: Import XPS or Visio into Sparx
« on: July 31, 2020, 10:28:33 am »
Find a converter to convert xps to emf and import those.

You could also get people to export to emf instead.

If you're really lucky you could convince them to use EA instead of Visio.  ;)
(my emphasis - and spelling correction by my grammar checker)

That's SO much harder than it looks!  My experience indicates that it IS a matter of luck, not endeavour on our part!

Paolo

Pages: [1] 2 3 ... 484