Messages

1

Bugs and Issues / Re: Compare with Controlled version, added notelin

« on: July 03, 2010, 04:48:48 am »

Hello.  We had a small panic about such a problem also.  We create commonly-used, "library" packages that are shared into many user project models via version control (TFS).  Whenever we get the latest version of a shared library package from version control into a user model, EA adds links to our shared packages.  For example, if a class in our user model B uses a class A in the shared package, it will add a link to A intended to indicate that B uses A.  This seems to be so that EA can show dependendencies in both directions without having to search the model over and over.  At first this was disconcerting.

Our answer to this is that we will never edit and check in shared packages from within user models.  We will always edit them in the models in which they were created, where the library classes are isolated from being polluted with this reverse relationship information.  This makes sense.  In this environment EA has no chance to add this derivative information.  In there it can get checked-in in a state of purity.

One might think it would be nice if show differences ignored this, or we could turn this off, but I don't feel strongly about it at all.  It makes sense that only the source of a shared package should be changing it anyway.

I emailed tech support about this at first and sent another one today describing this scheme here after figuring out what was going on.  If their reply indicates anythign different I'll let you know.

Does this make sense to you?

Jim

p.s. By the way there is a new version of EA 8.0.858.  (It behaves the same way as 8.0.855).  You might want to check it out though they changed and added a lot of features!

2

Bugs and Issues / Re: Reverse Engineering C++ Dependencies

« on: April 24, 2010, 06:33:45 am »

Thank you for posting.  We have been trying today to figure out how to get EA to bring in function bodies when reverse engineering.  It seems like a very essential part of reverse engineering.  I too will be making a feature request.  Thanks again for making this clear.

Jim

3

Bugs and Issues / Re: Max length for Tagged Values

« on: April 23, 2010, 09:18:33 am »

Just ran into this problem today.  Thank you forum people  !

Jim

4

Automation Interface, Add-Ins and Tools / Re: Free TOOL Enterprise Architect Spy

« on: March 12, 2011, 05:32:45 am »

This looks very good and may motivate me to move from using the add-in API to making SQL calls to speed up our very slow model iteration.  Thanks.

Jim

5

Automation Interface, Add-Ins and Tools / Re: Parameterized class information in EA 9

« on: May 27, 2011, 06:01:46 am »

Until I hear back from tech support I am going to move forward with an SQL hack.  Looking at the XMI shows that parameterized class (e.g. C++ template) parameters can be found in table t_xref:

String xmi = r.SQLQuery("select * from t_xref where t_xref.Client = \"" + e.ElementGUID+ "\"");

In other words "give me all t_xref rows that have client GUID equal to my classes GUID".  This gives more than template parameters, but I can get it out of there at least.  In the middle of a resulting XML pile, it looks like:

Name=TOneOfMyClasParameters;Type=ClassifierTemplateParameter;ParameteredElementType=class;Pos=1

I hope the automation interface has a method for getting this information directly, but I just have not been able to find it.

6

Automation Interface, Add-Ins and Tools / Parameterized class information in EA 9

« on: May 26, 2011, 08:59:43 am »

Parameterized class information via the automation infterface appears to have moved from element.get_miscData() to somewhere uknown to me.  Anyone have any ideas?

Thanks!

Jim

7

Automation Interface, Add-Ins and Tools / Re: How to get EA version from add-in?

« on: May 27, 2011, 07:50:24 am »

RTFM: EA.Repository.LibraryVersion

8

Automation Interface, Add-Ins and Tools / How to get EA version from add-in?

« on: May 27, 2011, 07:39:41 am »

Hello.  I have some changes to our add-in code that depend on the EA version (yes I know).  Does anyone know a way to get the EA version from an add-in?  Specifically I'm looking to determine if it is greater than or equal to 9.

Thanks!

Jim

9

Automation Interface, Add-Ins and Tools / Re: New: navigate to calling actions with EA Navig

« on: May 27, 2011, 03:21:11 am »

Very inspirational and so is your blog.  Thank you!

10

Automation Interface, Add-Ins and Tools / Add-in API

« on: March 29, 2011, 05:04:45 am »

I just thought I'd throw this out there on a whim:  It would be nice if Sparx "ate their own dog food" and coded the entire UI for EA using the add-in API that we are all using.  I'm not sure if this is practical, but it might ensure that the interface is fast and complete.  I mentioned it to a fellow there once and he said that this is not a new idea.  Any opinions on this?

11

Automation Interface, Add-Ins and Tools / Re: Is EA.Repository thread-safe?

« on: March 17, 2011, 05:00:11 am »

One more comment.  The fact that you cannot have simultaneous reads seems incredible (I could be naive).  Is there static data being used in the COM interface support?  I know nothing about databases, but I cannot imagine that they are not thread-safe (even reading and writing).  I understand that if we were to change the model underneath readers then that would be our own problem, but simultaneous reads should work.  That is unless something evil is done in the COM interface on top of the database.  I'm not sure I believe the response yet.

12

Automation Interface, Add-Ins and Tools / Re: Is EA.Repository thread-safe?

« on: March 17, 2011, 04:54:38 am »

Answer I got from support was this:

Hello Jim,
Any situation where the repository object is used concurrently is likely to fail.
1) Generally this should be safe, although we have seen issues where the COM object couldn't be called from a different thread.
2) Will fail.
3) If you are operating concurrently with other EA operations it will fail.
4) No, it will still fail.

This is somewhat unfortunate in my opinion.  Most modern interface designs support concurrency.  I understand why it is not this way historically.  We wish that it was thread safe because the COM interface takes quite some time when models are even moderately large (even as low as 50 or so classes to completely get the information from them takes many minutes), and our so our users want to do things in the background while this is going on.

I am starting to look into SQL queries in lieu of using the COM interface per Geert's suggestion a while ago.  Meanwhile I am going with tehcnique number 1 up there and will not try 2 through 4.  My number one complaint about EA, besides the obscure user interface (will be trying beta 9 soon!) is the time it takes to get information from the repository.

It seems like the COM inteface has some really inefficient data structures or something.  (For example I ran a profiler once and getting connections takes around 8 times compared to other operations.)  I don't have any numbers for you, but it seems like exporting a huge model to XMI takes a lot less time than using the COM interface.  Maybe adding interpretting the XMI on top of that will still be quite less than using the COM interface.  This basically amounts to making our own interface.

EA does a lot of things for a little bit of money, but this is tough when you add on top that we don't trust version control or differencing (you should not need a best practices white paper, it should be in the manual and be very clear - Rose RT had a beautiful version control interface.  Artisan studio's is incredible with visual differencing of diagrams).  I do respect the amount of work that has gone into it, but I need some ways around these items if our (huge) company as a whole is going to use this and not just our 5-man group of die hard modeling people.

13

Automation Interface, Add-Ins and Tools / Re: Is EA.Repository thread-safe?

« on: March 12, 2011, 05:18:32 am »

Hi Geert.  Indeed I did, I asked them this:

Hello.  I get a call-back in our add-in that has an EA.Repository object as an input argument.  There are a few scenarios that I have questions about:
 
1.       If I use the EA.Repository object in a different thread, and don’t return from the callback until the thread is done, then this must be ok, right?  (It is as if I use it only in the callback then.)
2.       If I use it in several threads, and still don’t return until they are done, is that ok too?  (Are simultaneous reads a  problem?)
3.       If I return from the callback and still use the EA.Repository object, then I can see that this might cause problems, right?  (Is the object now invalid?)
4.       So far I am only reading using the EA.Repository object, not changing anything.  Do any of the answers change if I am actually writing using it, i.e. changing the repository?  (Are simultaneous reads and writes allowed?)
 
Thanks (presumably Simon)!

When I get a reply, I'll let you guys know!

Jim

14

Automation Interface, Add-Ins and Tools / Is EA.Repository thread-safe?

« on: March 11, 2011, 10:48:55 am »

Hello.  I have recently tried to alleviate some aggravation for our users by doing some rather lengthy READ ONLY model elaboration using EA.Repository in a C# BackgroundWorker thread.  This is merely to allow users to cancel, but soon i will be having several readers of the repository.  There has been an occasional funny behavior, so I'm wondering if the repository is thread safe when reading only.  (My guess is yes, that it is deisgned this way as mostly a database front end, but you never know.)

Thanks!

Jim

15

Automation Interface, Add-Ins and Tools / Re: Optimizing EA interface

« on: October 20, 2010, 10:02:28 am »

Thanks for those detailed answers!  I will be checking this out.

Jim