Experiences of a newbie

[R. Schreurs]

Today, I made a new attempt to start working with Enterprise Architect. It is still quite hard to find out what it can do for me.

My background:
Developer of database applications.
.Net, SQL databases.
Client server and web based.
Some knowledge of UML.
10 years of experience in software development.

Expectations
I hope Enterprise Architect is a tool that will help me generate (and update) programming code and DDL. This would make it a lot more useful than some other drawing tools that still need a human to transfer all information to the software being built.

Goal
My first goal is to generate data models for SQL Server 2005 from an Enterprise architect project, rather than designing it in SQL Server.

Experiences
First problem: what models to use?
Supposedly, Data model would be a good one.
What objects to use?
Supposedly, Entity.
Well, let me first Import a DB schema from ODBC.
My tables have become classes in the model!?
Well let's continue that way.
Question: which of the properties are needed to actually generate a useful data model and which are for documentation purposes only? Not a clue from the tool.
Let's add some relations. The relations have been reversed engineered as associations. The stereotype is not specified. Relationship is one option, shouldn't it be that?
The Direction property Source -> Destination. Could it be any other way? Probably these concepts are different from what my intuition tells me.

Etc., etc.

Conclusions
Enterprise Architect cannot be learned by experimenting.
The user interface is intimidating and asks me for many properties I do not understand.
The help does not explain anything in depth. Example help for aggregation property of an association: Select the type of aggregation that this role uses.
Also, it is absolutely not clear what will be the effects of settings on the generation of code and DDL.
I am not blaming Enterprise Architect for all this. I think I might need to spend a lot more time to get anywhere, but it may be useful for you to know how a new user experiences the tool.

Recommendations
Improve help by explaining not only how to fill out property forms, but also why the properties are relevant and what they will do during code generation (if anything at all).
Add some information about the model objects and their code counterparts.
Define the minimal sub set of models, objects and properties, needed to be able to generate code.

[«Midnight»]

Remember that EA is a UML modeling tool. Whatever you do with it you are going to come at from that direction.

UML is itself a big thing to grasp; there is a learning curve involved. Search this forum for several threads dealing with recommendations for UML literature, and browse the Sparx Web site - the Resources page would be a good place to start. [I'm avoiding repeating the recommendations here. There are too many, and I don't want to scatter this all over the forum.]

With just a bit of background some of the perceived complexity will disappear - some is real, and will remain - and you a lot of what you see will make more sense. After that you'll find that you can get good results while you are still on the learning curve.

[Dermot]

Thanks David - just to be a bit more specific on refernces see:
http://www.sparxsystems.com.au/resources/uml_datamodel.html
And:
http://www.sparxsystems.com.au/EAUserGuide/datamodelling2.htm

[Sql Server DBA]

I'm using EA 8.01 to meet similar requirements, and am also relatively new to EA.  Here's what I've found:

If you want to build a very pretty, functional logical diagram of your SQL Server Database that is easy to keep current with database changes. EA is worlds better than MS Visio.

On the other hand, if you want to do true model driven development, where you build the model and generate the database, you need to spend a LOT more money (e.g. Oracle & Rational Rose or ERWin)

You get what you pay for, and EA is a good value for the money.  But it's not a $10,000 a seat model driven design tool -- so don't expect it to act like one  

[Luis J. Lobo]

What limitations did you see in the "model-to-database" generation? I think the DDL generation works fine! Please, can you indicate me what things do you miss?

[Emilio]

Wow, I didn't know version 8.1 was already available :-)

As for the original poster... It is true that the interface can be a bit intimidating but it is exactly this richness that you can exploit. With the proper knowledge of UML and a bit of experimentation (yes) you can go a long way.

I use it for technical designs (class diagrams, message charts, etc.), sometimes for higher level specifications (requirements, use cases) and other times for data modeling.

If you want to use it for code generation you should restrict yourself to generating the skeletons rather than implementing the whole logic in EA. Then again you will probably either need to edit the generated code or adapt the EA templates so that the code conforms to your formatting/corporate standards. It helps avoiding a lot of typing in the initial stage but don't hold your breath, you will need to add a thing here or there.

As for data modeling, the "table" is simply a "class" figure from the toolbox with the "table" stereotype. You can also use the Information Engineering Connectors selection in the diagram properties. However, for generating DDL don't hold your breath there either, you are still better off doing that with the Microsoft Management Studio or as the previous poster pointed out, by spending a GREAT DEAL OF MONEY in a dedicated tool like Erwin (didn't Erwin stopped to exist?).

As you experiment with EA and read the whitepapers and help files you discover much more possibilities. Quite frankly to every company I have worked for in the previous years I recommend the EA tool -if they were not using it already- and I always end up using it.

[Martin Terreni]

I'm using EA 8.01 to meet similar requirements

just happend to stable upon this pioneer user, this is a real erly adapter!