Inconsistencies between Help and t_connectorTypes

[Paolo F Cantoni]

There are inconsistencies between what the help says in .../User%20Guide/model_domains/transformingconnectors.html and the t_connectortypes table in the repository.

Connector_Type   Help Document
Abstraction      Abstraction
Aggregation      Aggregation
Assembly         Assembly
Association      Association
Collaboration      Collaboration
CommunicationPath      
Connector      Connector
ControlFlow      ControlFlow
Delegate         Delegate
Dependency      Dependency
Deployment      Deployment
ERLink         ForeignKey
Extension      
Generalization      Generalization
InformationFlow   InformationFlow
Instantiation      Instantiation
            Interface
InterruptFlow      InterruptFlow
Manifest         Manifest
Nesting         Nesting
NoteLink         NoteLink
ObjectFlow      ObjectFlow
Package         Package
ProtocolConformance      
ProtocolTransition      
Realisation      Realization
Sequence         Sequence
StateFlow      
Substitution      Substitution
            TemplateBinding
            Transition
Usage         Usage
UseCase         UseCase
            Uses

Should these be identical or, if not, why not?

Paolo

[qwerty]

I thought the Realisation had been deprecated (make the Z great again).

q.

[Paolo F Cantoni]

I thought the Realisation had been deprecated (make the Z great again).

q.

I may not have the latest list from t_connectortypes.  I got it from the last Jet4 version of the DB from last year.

Paolo

[qwerty]

I wanted to look into the link you provided, but the ... seem too far off to target any page.

FWIW: In my model the table has identical ConType/Descr. pairs, and Realisation.

q.

[Eve]

The value stored in the database should always be Realisation. I don't expect that to be changed for compatibility reasons.  Most places where you specify a type it can be spelled as Realization, and in the English version it should be displayed as Realization.

Having said that, I just checked the code for parsing the transformation output, it only seems to handle Realisation at the moment.

[Paolo F Cantoni]

The value stored in the database should always be Realisation. I don't expect that to be changed for compatibility reasons.  Most places where you specify a type it can be spelled as Realization, and in the English version it should be displayed as Realization.

Having said that, I just checked the code for parsing the transformation output, it only seems to handle Realisation at the moment.

I think I noted this defect over a decade ago - when I was investigating Transformations.

However, to the original question.  How consistent should the two sets be?

@qwerty  I have local help files so my full link is: file:///C:/Program%20Files%20(x86)/Sparx%20Systems/User%20Guide/model_domains/transformingconnectors.html
Path is: Index.Model Domains.Model Transformation.Write Transformations.Connectors
The page is entitied: Connectors

Paolo

[qwerty]

That would give me a hard time hacking into your machine ;-) I only have a V12 .chm and it has only a chapter about element/package transformation, not about connectors. Well, ...

q.

[Geert Bellekens]

Just to be on the safe side, whenever I do a query on the database it includes something like
and c.Connector_Type in ('Realization','Realisation')

I do the same with Generalization/Generalisation.

Geert

[Eve]

I wanted to look into the link you provided, but the ... seem too far off to target any page.

Pro-tip. Just take the filename for the html document and append it to the root of the user guide on the website.

http://sparxsystems.com/enterprise_architect_user_guide/13.0/transform_connectors.html

Just to be on the safe side, whenever I do a query on the database it includes something like
and c.Connector_Type in ('Realization','Realisation')

I do the same with Generalization/Generalisation.

Really shouldn't be necessary. If you ever see Generalisation or Realization in the DB it's bad data inserted either by EA or another tool. (If using EA's sql search, alias the column name to prevent EA being too helpful)

However, to the original question.  How consistent should the two sets be?

In an ideal world, they would probably be the same. Factors like the expressiveness of the transform language or new connector types not being added everywhere (including documentation) mean that that isn't going to be the case.

Is there a problem you're attempting to overcome?

[Paolo F Cantoni]

[SNIP]

In an ideal world, they would probably be the same. Factors like the expressiveness of the transform language or new connector types not being added everywhere (including documentation) mean that that isn't going to be the case.

Is there a problem you're attempting to overcome?

Yes,  We do a LOT of declarative management of our MDG and we need an "Official" list of the types of elements and connectors so that our tables are correctly set up.

I would have expected the t_connectortypes table to hold the current set of "valid" types, but as you can see there are discrepancies between one official documentation and another.

As you suggest, the fact that this set is related to "transformation" would allow for them to be slightly different.  But I couldn't find in the NEW Help system where the equivalent list to the t_conectortypes table is (if any).  If you can publish the list here, that's enough for our needs at the moment.  As I said, our instance of t_connector types is a bit old and that may also explain any differences.  That's why I went to the current Help to try and find the "current" official list.

Paolo

[Eve]

For the purposes of creating a profile, you should be using the list provided by the metatypes dialog in EA. As it happens, that list is filled by t_connectortypes.

Including the actual list in the documentation is redundant, because we expect people to use the tools that are provided.

[Paolo F Cantoni]

For the purposes of creating a profile, you should be using the list provided by the metatypes dialog in EA. As it happens, that list is filled by t_connectortypes.

Including the actual list in the documentation is redundant, because we expect people to use the tools that are provided.

Thanks, Simon,

That's what I was after.  As I mentioned, our t_connectortypes is a bit old.  .Iis it maintained by newer versions on a pre-existing repository or do we need to manually keep it up to date (from later versions of EABase.eap)?

Paolo

[Eve]

EA updates t_connectortypes during load of a model.

[Paolo F Cantoni]

EA updates t_connectortypes during load of a model.

Excellent!  Thanks.

Paolo