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.


Topics - Paolo F Cantoni

Pages: [1] 2 3 ... 94
1
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

2
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

3
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

4
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

5
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?)

6
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

7
We have a metatype "Grouping" (which behaves a bit like an Archimate Grouping).  The handcrafted definition has the Apply type="Component".  It also inherits from a higher level abstract metatype whose Apply type="Class".

Should that be an issue?

In any event with that definition, it would not drag from the toolbox any more.  It would "silently fail".

In trying to diagnose the problem, I dragged on another item and tried to reset the stereotype.  I was able to do this, but noticed that the Stereotype assignment dialog said the Apply type for Grouping was "Class" only.  Not "Component" nor even "Component, Class".   Note: the item was a class based metatype - so I suspect that's why.

Anyway, changing the Apply type to Apply type="Class" allowed the item to be dragged from the Toolbox.

Can anyone explain why and what was wrong with the original definition?

As an aside, could I create an abstract metatype WITHOUT an Apply type= section?  So I could pass on the other aspects of the abstract metatype, but not impede the specialized metatype?

TIA,
Paolo

8
We've been investigating supplemental stereotypes to enhance hard-coded EAUML items (such as Tables).  We have managed to get a certain way in successfully.
We have been advised by Sparx that EAUML::table does not use a shapescript.  However, it does seem to hard code some rendering (display of PK, FK etc. and display of the column size and precision etc.).  When we apply the supplemental stereotype, these rendering attributes disappear.  How can we retain them?  We tried to use drawparentshape() but to no avail.  Is it possible?

TIA,
Paolo

9
When trying to apply multiple stereotypes off the toolbox, sometimes the "dialog" has the Convert to function and other times Apply function.  What triggers the difference in the MDG specification?

There are subsidiary questions I want to ask, but they may be sorted by the answer to this question.

TIA,
Paolo

10
In Re: Cross-profile «stereotyped relationship», possibly our favourite Sparxian (shades of Ray Walston in "My Favourite Martian"  ;)), Eve said:
"I'm not going to try to argue the distinction between a bug and behaviour you didn't expect".

I've spent the last couple of days trying to get supplemental stereotypes to work (as suggested by Eve).  I've found a pile of unexpected behaviours! (Surprise, surprise!)  I've also found what appear to be inconsistent behaviours which, as I have often asserted, are, by definition, defects.

Notwithstanding Sparxians may well take a divergent view to we users about whether a specific unexpected behaviour is actually a defect, I feel it would be useful for the user base to come to a common understanding of "the distinction between a defect and unexpected behaviour" (if there is any - which I believe there is).  It would make it better to answer queries from newer users etc.

Anyway, if this is something that would be useful to the user base, I'm prepared to start the ball rolling...

Thoughts?
Paolo

11
As I have moved from engagement to engagement, I (as have most Sparx practitioners) have found a plethora of "models" expressed as Visio diagrams.  this latest has proved no different.

However, I  (as most Sparx practitioners) have found it increasingly more difficult to import these diagrams into EA.  Primarily, I believe, because no effort has been put into upgrading the importer.  I tried to import a large diagram recently (a vsdx file created with the latest version of Visio) and there were 1300 (probably spurious) errors reported by Sparx which stopped the creation of any relationships between the items.

Now, elsewhere, both Geert and I (and probably others, but most recently we two) have commented that there is usually a large amount of work required to convert these diagrams into Sparxian.  However, that's not what I'm complaining about this is about actually being able to read the file in the first place.

I'm also not complaining about trying to import a diagram that is visually (i.e. when printed or displayed) "Correct" but under the covers is not syntactically valid (i.e. the connectors don't join the shapes).

As far as I can ascertain, this is a perfectly valid Visio diagram.  But since the Importer hasn't progressed from v1.8.42 for several years, I tried saving the diagram as a Visio 2003-2010 vsd file.  Also to no avail - the same set of errors.

So my question is:
Does Sparx see this as part of its strategic armoury to help users transition to EA or not?

From the Sparx site "Importing Visio Diagrams into Enterprise Architect"

"If you are not using Enterprise Architect to design your systems, you are giving up opportunities for increased productivity, that result from re-using your data across the whole project, sharing that data across the entire project team and using the model to drive the solution."

The importer needs to be updated to allow the better and easier import of Visio diagrams into EA.

Can we have a definitive statement from Sparx on whether they are serious about helping Visio users move their diagrams to EA?

Thoughts (especially from the user base)?
Paolo

[Note: I take Geert's point (made elsewhere) that in many cases the total amount of work to import the diagram using the importer is less than creating the model from scratch by other means.  That having been said, if the judgment call is that it will be easier to import the diagram and post-process the import, then the import SHOULD work!]

12
Uml Process / v15.2β - Redefining EAUML::FK
« on: June 15, 2020, 04:43:01 pm »
In our MDG, we have a redefinition of EAUML::FK thus:

Code: [Select]
<Stereotype name="DmnsnRfrnc" metatype="Dimension Reference" notes="" cx="200" cy="100" bgcolor="15658671" fontcolor="10061943" bordercolor="10061943" borderwidth="-1" hideicon="0" generalizes="EAUML::FK" baseStereotypes=""EAUML::FKArc" redefines="EAUML::FK">(Arc is our own stereotype)
We create an Association using the Database Modelling profile between two EAUML::table items.  We can then convert the Association to a DmnsnRfrnc stereotype and can even create the Foreign Keys, but we are left with an arc with stereotypes: "FK, DmnsnRfrnc" rather than just DmnsnRfrnc.  Is this because there's a LOT of hard coding in the DB modelling profile?

Paolo

13
In our MDG, we have a redefinition of EAUML::table
Code: [Select]
<Stereotype name="DBTbl" metatype="DB Table (OurMDG)" notes="" cx="151" cy="80" bgcolor="15658671" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0" generalizes="EAUML::Table" baseStereotypes="EAUML::Table ClssVrtx AggrgtVrtx" redefines="EAUML::Table">
(ClssVrtx & AggrgtVrtx are our own stereotypes)
We create an Association using the Database Modelling profile between two DBTbl items.  When we try to activate the Foreign Keys... dialog, we get the message that "Both source and target elements must be Tables"

What are we doing wrong?

TIA,
Paolo

14
I think I may be falling foul of the perspectives issue again.

I can reverse engineer a DB with Database builder and I can create tables with the Data Modelling profile.

When I use the QuickLinker, should I be able to create an Association between the two tables?

TIA,
Paolo

15
There is a character set problem with CSV Import.  The Guillemet characters: «» are not imported correctly! They are imported as a weird character.

Reported,
Paolo

Pages: [1] 2 3 ... 94