Eval question with code engineering directories

[abierbaum]

I am currently evaluating EA for the needs of our company.  We work on a very large codebase spread across several related projects using C++ and python.

I think I would like to setup a repository on a shared database.  The idea that all developers could share the repository.  With this I am setting up a root "view" for each project.  (ie. proj1, proj2, core, etc).

Now the question, I want to setup code engineering so there are source packages under each project that have the design models and associated code for each project.  I want this code setup to support round-trip style engineering and I want the project to work for every developer no matter how they have their code checked out locally.

- How do I get the packages setup to point at the code using a local environment variable or something similar so the single shared project will work for all developers?
- While I am at it, how can I tell through the EA interface, what directory a package (or sub-tree of packages) is "attached" to for code engineering purposes?

For example How do I know that proj1/design_models/corp maps to the code in c:\Source\proj1\src\corp?

I can't seem to find anywhere in the documentation that talks about it, but it is a very *key* part of what we want to accomplish.  We need a way to keep our code and models in sync and there has to be somewhere that has a link from the model package to the on disk code directory, right??

-Allen

[«Midnight»]

Hi Allen,

Talk about an ambitious evaluation; you've certainly hit the ground running!

Off hand, my opinion is that this should be possible without too much effort. The details are not something we can do over a forum, but that's why they've got you to work on this, isn't it...

So, here's what I can tell you off hand.

First, search this forum for answers. I cannot stress this enough. There is a lot of stuff on almost every issue you've raised. Not only that, but there are posts where several approaches are discusses, with pros and cons that are context-sensitive, and with lessons learned. YABB - the bulletin board software - can be a bit difficult with searches, so be persistent. [Sparx has very recently upgraded to a much newer version of YABB, so I suspect that the search engine will be more helpful.]

Next, you can share a repository. Consider carefully which back end DBMS you will store this in. Several give good performance, though some are configuration (drivers and such) and version sensitive. Performance varies with the DBMS, type of network, and model characteristics. EA can put a fairly heavy load on your network - it can be pretty 'chatty' with the repository - but from the sounds of things that will not likely be a limiting factor for you. It seems like you have a good sized team working on a fairly large project; the resources necessary to carry EA should not be your largest resource issue.

See Simon's post below.
You should make sure that any network paths to the code base - the copy you will be using for code engineering - will be the same for all users (or all within each working group). This will make local paths work well for you. It takes some setup but you can exchange a 'core' configuration by exporting and importing Reference Data. [I'll leave you to look this up.]

Search my posts over the past month or so for "seed project" or "EABase" for some additional information on setting up default projects.

See Simon's clarification below[/u[I do not know whether EA exposes (easily) the locations for package code. It does carry this information in its database though.

Sparxians, users, anyone, is this something visible in the UI anyplace?

EA also tracks the source code files behind some elements. If you move or rename them outside of EA you might have some issues with duplicate code next time you forward or reverse engineer. Search the forum for more information.

Remember that EA has a powerful API - it is based on COM, so it will likely work well for you - that you can use to write some 'helper' tools. This takes a bit of learning, but you should get working stuff up very early. Once you get used to how the API 'likes' to work it is often faster to whip up a tool than to work out an answer to something.

So, I have not solved your problem, but hopefully you now have an idea where to look.

As far as "can it be done" you should have no worries. The size and type of problem you describe is well within EA's capabilities.

Please let us know how the evaluation goes, and what you learn.

David

[Eve]

You should make sure that any network paths to the code base - the copy you will be using for code engineering - will be the same for all users (or all within each working group). This will make local paths work well for you. It takes some setup but you can exchange a 'core' configuration by exporting and importing Reference Data. [I'll leave you to look this up.]

Not quite true.  See http://www.sparxsystems.com.au/EAUserGuide/index.html?localpaths.htm

I do not know whether EA exposes (easily) the locations for package code. It does carry this information in its database though.

Again, the information for path not stored against the package.  Each class stores the path individually.

[«Midnight»]

Thanks for both clarifications Simon.

[EDIT: And I finally got around to updating my earlier post to reflect this...]

As to the latter one, I knew it was in there someplace. I was thinking of the t_package.CodePath field. Is it not used for something related to this?

David

[Eve]

Regarding t_package.CodePath, see http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1204636750/0#0

[«Midnight»]

Oops, I forgot.

BUT: The sly hint still applies...

[abierbaum]

You should make sure that any network paths to the code base - the copy you will be using for code engineering - will be the same for all users (or all within each working group). This will make local paths work well for you. It takes some setup but you can exchange a 'core' configuration by exporting and importing Reference Data. [I'll leave you to look this up.]

Not quite true.  See http://www.sparxsystems.com.au/EAUserGuide/index.html?localpaths.htm

I do not know whether EA exposes (easily) the locations for package code. It does carry this information in its database though.

Again, the information for path not stored against the package.  Each class stores the path individually.

So I guess my question still stands, I understand how the "Local Paths" variables could be used to solve this, but I don't see anywhere in the UI where I can find out the current set path for a given class/package/resource so I can change it or at least verify that it is using a local path correctly.

Where can the source path associated with a Class in EA be viewed and set?

[GeorgeSDI]

"Where can the source (code) path associated with a Class in EA be viewed and set?"
 
I would also like an answer to this question.

I've discovered that if I go to the project browser window, select a class and right click "Properties",  I get a dialog box with information about the class.  Within the Properties dialog box,  there is a tab marked "Files".  However, the file path field on this tab is blank.

Does this mean the information we're looking for is not stored here?  Or is it because I've moved my source code since I last opened this project?

TIA

[thomas.kilian]

Nope. Files is to associate additional docs (source, docu, etc.). The CodePath is in the docked Properties window (View / Properties). Your first step experiencing EAUI. Jimmy Hendrix had another Experience...

[abierbaum]

Thanks for the pointer.  I see it now.

With that answered, does anyone know a way to mass "migrate" a set of classes to a new source location?  For example if I an using round-trip engineering on a project and a decide to restructure the source repository, how can I tell EA that the source code has moved from directory "src/subsystem/original" to "src/subsystem/new"?  I hope I don't have to go through all the classes one by one and move them around do I?  :-/

[Eve]

The following is how you can change the source path using local paths.  If you have local paths already used, you will probably need to expand all your original paths temporarily for it to work.
 
Open the local paths dialog. (Settings | Local Paths) In the path field enter the path that EA currently thinks your files are at, or part of it.
In the ID field enter something like "Source_Path".
In the type field select your source code language.
Click "Apply Path"
This will substitute the path you entered for the ID in all classes containing that path.
Edit the path field to your new path.
EA will now find the files in their new paths.
If you want to you can now click "Expand Path" and then delete that path.
That will remove the relative paths that were created before, setting them back to absolute paths.

[abierbaum]

Simon:

Maybe I am missing something, but how does using local paths allow me to restructure my code tree.  As I understand it, the local path would be used to refer to the base directory of all the source code in the project.  But if there is some subdirectory in that project that moves, how do I update only those paths that moved so that EA can track the code in the new location within the same source tree?

[Eve]

Follow my instructions above, but the essence is that you can use local paths by applying with the old path, changing to the new path and expanding again to make EA recognise the new path for all classes.