EA vs Altova UModel + other CASE tools evaluation

[Paolo F Cantoni]

Didn't compare the tools but isn't the runtime performance (memory & speed) more important than the file access ?

Well, with a database you can do bulk work at DB speeds.  Until Sparx sorted out their roundtrip XMI so that the number of defects was down to a grudgingly acceptable level, we developed a back-end comparator that we used for all sorts of stuff - but principally to compare one repository with another.  Since Sparx obviously couldn't...

The in-built EA comparator took 2.5 hours to compare two models.  Ours took 75secs...  Admittedly, we may not have done everything Sparx's one did, but the amount of "processing" we feel was comparable...  Certainly the bugs were were able to find (and correctly diagnose) was instructive...

As a Data Management Architect, I have a bias that says data isn't real unless I can touch it...  

It isn't the speed of drawing and manually manipulating models that is important in MDA work, it's the time it takes to "crunch" the transformations.  A properly normalized DB design (which EA definitely is NOT) can make transformations a relative breeze.  But at least there's hope with EA - it uses a DB as its main repository (and it IS normalized, to a point).  If you don't even use a DB, you're at the mercy of serialization.

Paolo

[softwaredeveloper]

Hi guys!

@Thomas: As I understand your answer, you basicly do not really need an API but you need a workaround to get a useful documentation output!?

@Paolo: As I understand your answer, you do not need the database because it scales so well, you need it as workaround to faster compare two or more models because the built-in EA comparator is too slow!?

Anyway - with performance & speed I mostly meant i) the forwards and reverse engineering speed (+memory) and ii) the "speed" I can edit, change, extend,.. my diagrams and my model - simply said the time I need for modelling.
As cp, I have also tested several tools (>= 20) and for i) I have recognized differences in the amount of a factor of 100 and more !! ii) cannot really to be measured but the differences reach the same level at a minimum.
Do you see and problems in these directions when using a file-based system ? Or are there still any advantages when using a DB ?

cheers,
just a softwaredeveloper

PS: just want to clarify: as we all know the most important things regarding forward+reverse engineering (of course also regarding editing) the correctness and feature completeness are more important than performance but that's a different story  

[Paolo F Cantoni]

@Paolo: As I understand your answer, you do not need the database because it scales so well, you need it as workaround to faster compare two or more models because the built-in EA comparator is too slow!?

No, I didn't explain myself well enough... (seems to be a bad weekend for that).  The comparator was just an example.  If I want to do any repetitive task for which there is a relatively easy DB analogue then I can do it at DB speeds.  Another is the ability to apply rendering based on stereotypes on a gross scale to lines which wasn't previously possible by UI...  When you load EA from its repository it loads fairly quickly even for quite large models - there is some contention it could load even faster using forms of lazy loading but that's by the by.

Paolo

[thomaskilian]

@Thomas: As I understand your answer, you basicly do not really need an API but you need a workaround to get a useful documentation output!?

No. I use it for documentation, but I do a lot other things with automation too. F.x. I need it to import various sources into EA (latest I did was a set of Excel tables containing interface and component description which I was able to transfer into EA). Also I have quite some add-ins to help formatting diagrams and a lot more. I was used to have automation already with RR and would never go back to a tool without!

[salayande]

The choice of a CASE tool is dependent on the context for use which includes:

1. The purpose of the work at hand - Enterprise Engineering & Modelling, Application Modelling or Code Engineering. Each of these goals has a process that the CASE tool supports.

2. The degree of support for each step in a selected process (example, support for TOGAF, UMM, RUP and other processes).

3. How open the architecture of the CASE tool is that enables incorporation of tools from other suppliers to better support a custom process (Add-Ins).

4. Support for repository object exchange standards (example latest XMI standards)

5. Support for real-time collaborative peer review of models.

6. Support for Profiles to enable non-standard UML for specialist domains (example UML Profile for Data Quality)

7. Ability to support modeling without getting in the way of thinking (Usability)

8. Support for a comprehensive set of target technologies (code platforms and databases).

9. Value (Benefit-Cost ratio).

I have implemented a development environment (end-to-end) based on EA and third party Add-Ins that suits my team's way of working in a corporate environment at the least cost.

If Sparxystems continues to loose momentum on innovation (as version 7.0 betas suggests), then UModel has a great chance in a year or two. Meanwhile a comparison of the two is not fair to UModel as EA has a lead of over 4 years.

[Dave_Bullet]

It depends on whether you want just to give UML savvy people access to the wealth of information in your models... or you want it to become a repository / source of truth for your IT department and business.  Due to the clear text nature of the EA database, we are able to front end it with MS Access and have non-UML people use it to maintain information in tagged values - rather than separate spreadsheets to be imported.

This gives us one point of truth and consistency in our data, which is the starting point for any team that wants to move forward in efficiency and effectiveness.

Cheers,
David.

[Paolo F Cantoni]

This gives us one point of truth and consistency in our data, which is the starting point for any team that wants to move forward in efficiency and effectiveness.

'Onya David!

I would not be true to my tag line if I didn't support you on that one.

Paolo

[markymark]

I also did a big UML/CASE tool evaluation when I started out on my current project to build a giant component model.  I looked at a bunch of tools across every price range (some upwards of $10k!) and EA came out on top for a variety of reasons, a big part of it being the engaged user community and incredibly responsive team at Sparx.  I feel as though they actually listen -- even encourage our participation in their product development.  What a refreshing attitude!

Like Paulo said, this was before I was introduced to EA's "UI - Unique Interface."  But thus far, I've been able to address every modeling, input, output, diagramming and reporting requirement of the team (about 15 smart business analysts located around the country).

I keep everything in a SQL Server repository and each analyst has access to it remotely to view, edit, enter data, pull reports, etc. over the internet.  This has the benefit of all the SQL Server backup, replication, etc. features that keep the server available and up to date.  I've set up the version control a couple of different ways on a development server, but have not yet rolled it out to the production server yet, still tinkering.

I've done a lot of direct operations, SQL queries and stored procedures directly on the EA repository, which has been reasonably straightforward to reverse engineer and understand.  I have built a number of C# .Net applications to bulk-load data directly into the SQL Server database from Excel spreadsheets developed by the analysts.  And there is lot of data!

The Automation and Add-In interface in EA takes a little getting used to, but is also great.  I typically mix and match between the API and direct database operations depending on coding complexity -- sometimes it's just really fast to write a quick sproc and be done with it.  I do realize that the data model may change in the future and I'll need to re-address these things, but it works like a champ for now and it's been much more stable than, say, the Quickbooks data repository!

On the other side of things, getting data out of the SQL Server database is done with either SQL Server reporting features (direct to the database) or via EA's reporting RTF interface.  Again, not the slickest reporting interface I've seen, but it does a good job and the reports can be run by anyone with EA (the templates are also stored in the DB).

My $0.04.

Mark

[Martin Terreni]

I'm the head functional designer of a medium application (about 5 designers,15 developers and 4 testers).
I've tried quite a few tools -MagicDrow,Rose,Tau,Raphsody,Visual Paradigm,Altova and more...
Many of them I've meet for live sessions to try to convince me (in more then one place of work I've been in the last years).
Finally I took EA, do I think it is the best?
I think there is no best. We are a C# team, so VP and RR are not relevant for us, though they are grate tools.
In general - you have to choose th tool that fits your needs best.
I took this decision since our main work is functional design:
- GUI (which almost no tool has option to design inside)
- DB (The same, only it is EXTREMELY inportant in our mode of work)
- Activity diagrams, which are good enough in EA (if you have a formal methodology how to use them)

Also the fact it work on DB is grate, I can easily develop a lot of staff on it this way.
right now the integration with TFS/VS is getting much better and having had the experience of working with EA/Rose/VP on external repositories (ClearCase and SourceSafe) th fact that its native is grate!

We also do extensive use of the forum to communicate changes(I recommend it) and it is very helpful.

EA still has to get better in all the things related to code engineering, but all in all it is a grate tool.

Again remember- take the one that fits you most, ther is no best.  

[mikewhit]

s/grate/great/g

[Martin Terreni]

s/grate/great/g

?

[thomaskilian]

grate = door
great = big

Mike is our Oxford dictionary

[Gary W.]

Mike is our Oxford dictionary

He must also be a *nix person  

I vaguely recall from my vi-editor days that this means "substitute 'great' for 'grate' globally across this file" or basically a "replace all" command.

hth,
gary

[Martin Terreni]

Hooooooo
It looked to me like some unfinished command, though I didn't touch VI for a long time already...
I apologize for my mistake, but I'm disgraphic. As long as two  written words sound the same -for me they are the same.
Orthographic errors are meaningless for me.
But thanks for the fix (and now I know what grate means )

[thomaskilian]

This command is older than any *nix. The substitute was common in the good old EDIT of CMS (Cambridge Monitor System, was it?) of IBM's VM/370. The "g" was a "*" then but now *nixer are used to regular expressions.