Author Topic: EALite dilema (Read 10159 times)

mylesJ · « **on:** February 20, 2006, 03:58:45 am »

Hi. We have integrated our EA project in to source control which is working out very nicely. But we have found that EALite cannot read source controlled XMI packages. It only reads EA project files.

We are now faced with having to maintain a separate project just for EALite users; remembering to always update the project whenever the source controlled XMI packages are updated. Suddenly all the control that we gain from using source control is lost.

At 2mb a pop its not practical to source control the separate EA project as each time it gets updated means another 2mb used up on the source control server.

Its also not practical to generate these projects on demand and email them as they will bomb out email boxes; also we will lose traceability back to the versioned XMI packages the project came from.

Does anyone have some ideas on this?

alexander · « **Reply #1 on:** February 21, 2006, 12:44:33 pm »

That's strange, we usually work with a version controlled repository in a SQL server and many access these projects with a Lite version.
Are you working on a EAP project or a database one?

How are you configuring version control?

Bruno.Cossi · « **Reply #2 on:** February 21, 2006, 02:22:14 pm »

Same here. I don't see why EA Lite should read XMI packages, by using the source control the packages do not disappear from the model...

Bruno

Quote

That's strange, we usually work with a version controlled repository in a SQL server and many access these projects with a Lite version.
Are you working on a EAP project or a database one?

How are you configuring version control?

mylesJ · « **Reply #3 on:** February 21, 2006, 02:53:11 pm »

We are version controlling XMI packages in Visual SourceSafe. EALite users cannot read XMI packages.

Eve · « **Reply #4 on:** February 21, 2006, 04:10:15 pm »

I just want to clarify.

Myles, if my understanding is correct you are wanting EALite to directly open xmi files.

Alexander and Bruno, if my understanding is correct you are both using central repositories with version control. The EALite users then connect to the central repository. The repository already contains the full model so no reading of XMI files is required by EALite.

No version of EA will directly open an XMI file. It must be imported into a model first. There is no way EA could operate without a model so this will probably stay this way indefinately.

Am I correct in my understanding of what each of you is doing? Does this help to clarify things?

Bruno.Cossi · « **Reply #5 on:** February 21, 2006, 04:45:31 pm »

Hi Simon,

yes, that is what we are doing and it seems to work just fine for us.

Bruno

Quote

I just want to clarify.

Myles, if my understanding is correct you are wanting EALite to directly open xmi files.

Alexander and Bruno, if my understanding is correct you are both using central repositories with version control. The EALite users then connect to the central repository. The repository already contains the full model so no reading of XMI files is required by EALite.

No version of EA will directly open an XMI file. It must be imported into a model first. There is no way EA could operate without a model so this will probably stay this way indefinately.

Am I correct in my understanding of what each of you is doing? Does this help to clarify things?

mylesJ · « **Reply #6 on:** February 21, 2006, 11:08:20 pm »

We don't have a shared repository. We are a distributed team. I said we use Visual SourceSafe, I actually meant Source OffSite.

Each of us has our own private EA project which is hooked in to Source Offsite.

The problem is for our developers who use EALite. They have no means to view the XMI packages.

Eve · « **Reply #7 on:** February 22, 2006, 01:29:02 pm »

I thought that your situation was something like that Myles.

Unfortunately, as I said. No version of EA will directly open an XMI file, and I doubt it ever will.

I think that apart from the ideas you've already said you don't like, buying a license for each site to create/maintain the model is probably your only choice. If each site only has one person then EALite probably won't work for you at all.

mylesJ · « **Reply #8 on:** February 22, 2006, 03:12:28 pm »

One of the big advantages i saw for EA was the lite version that was freely available. However that idea has seemingly crashed and burned.

To clarify, when I say "view xmi packages with EALite" i mean import them in to a project for viewing in the same way EA does.

EALite is biased towards centralised teams with access to a centralised model. What about us distributed folks? Discrimination!

Jeff Odell · « **Reply #9 on:** February 27, 2006, 04:20:26 am »

How about maintaining one model for distribution to the read only folks that use EALite? If that model is in an accessible db server then the EALite users can connect. Otherwise, if that model is maintained as an .EAP, it can be made available to or distributed to the read only crowd.

I'd have to look at the details, but creating this database could potentially be scripted - sort of a process of:

1) Get Latest from Source Code COntrol to a local directory.

2a) If you are using an EAP file, just start with a new one; or;
2b) If you are using a database server, delete all existing packages.

3) With EA Automation, load the XMI files you want to distribute to EALite user into the database. I know that is a scriptable action.

Then you would have a database for your EALite users to utilize.

Would that work?

jlo

mylesJ · « **Reply #10 on:** February 27, 2006, 05:29:55 am »

Hi Jeff. Thanks for the suggestions. The scripted idea is a good one, at least it would save some manual steps.

The main problems are really that a) it would still involve some steps on behalf of the architects to prepare the EAP file b) they would have to distribute it to the developers via email or checking it in to source control c) the project would be uncontrolled; that is, it would be difficult to trace the project back to the baseline in source control

Using a shared database is not an option as our only point of collaboration is SourceOffSite (and email, phone, IM etc.).

I hope this doesn't come across as a dig at you Jeff. Just annoying that EALite is so close to being a great asset for us yet still seems a million miles away.

Jeff Odell · « **Reply #11 on:** February 27, 2006, 10:59:16 am »

I have thick skin :> Just trying to help with a workaround. Also, I want to understand the issues as I'm starting a project and will be distributing EALite in some cases.

Sees like a) and b) could be scripted reasonably easily, so I think the issue that remains is c)

Are you saying it is important for your EALite users to see not only the current state of the model but the deltas between the versions of the model? If so, I'm not sure I see a workaround.

Perhaps there is something in the version comparison reporting in EA that could be distributed along with the as is model that would suffice. Not knowing your development process it is hard for me to say if this kind of approach makes any sense.

Otherwise I'm out of ideas, other than to license everyone up. :>

jlo

mylesJ · « **Reply #12 on:** February 28, 2006, 02:38:26 am »

Quote

Are you saying it is important for your EALite users to see not only the current state of the model but the deltas between the versions of the model? If so, I'm not sure I see a workaround.

Its not important for the EALite users to view the deltas but it is important that when they raise a question with the model we know exactly which version of the model they are viewing. Also, at 2mb a pop, the EAP project files are quite large to be emailing around.

Another issue is that EALite users are also entirely dependent upon someone with a fully licensed version to create the EAP project file for them.

I have updated my enhancement request/suggestion on this here:

http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=suggestions;action=display;num=1140426658

mylesJ · « **Reply #13 on:** February 28, 2006, 02:43:48 am »

I do go on don't I? Jeff, to quote you...

Quote

Otherwise I'm out of ideas, other than to license everyone up. :>

But this flies in the face of Sparx own vision statement...

Quote

Sparx software is intended for use by analysts, designers, architects, developers, testers, project managers and maintenance staff - almost everyone involved in a software development project and in business analysis. It is Sparx Systems' belief that highly priced CASE tools severely limit their usefulness in a team, and ultimately to an organization, by narrowing the effective user base and restricting easy access to the model and the development tool. To this end, Sparx Systems are committed to both maintaining an accessible pricing model and to distributing a 'Read Only' (EA Lite) version of EA for use by those who only need to view modeling information.

Jeff Odell · « **Reply #14 on:** February 28, 2006, 03:23:31 am »

Now we are away from looking for solutions and into discussing different customer expectations. In my opinion providing the functionality Sparx does for $200 vs. Rose's $5000+ is a strong argument and Sparx meets their vision statement. It's perfectly reasonable for you to feel differently.

Asking them to add a feature to load the XMI files in the Lite version is also certainly reasonable. Given my past 3 years experience with the product, I would not be surprised if they address it.

If it were me (and it may be soon), I would

automate loading the XMI into an empty .EAP;
automate zipping and putting the file in source code control, and
have my developers get the latest model from source code control.

By doing this, you would save time overall! Why? Because each of your developers would be relieved of the time it takes to load the individual XMI files to rebuild the model locally. They would just get the latest EAP and open it up.

HTH - jlo

Sparx Systems Forum

News: