DDL Transformation

[Edward G]

Let we have any class diagram with various classes: entities, controls and boundaries.

Then we want to create database schema and use for it DDL transformation.

There are nothing problems to create this schema but we get all classes into database schema.

However some classes should save in database but the other are not

Realy we want to create schema only by entity classes

I tried to set stereotype - no matter, I tried to set Persistent or Transient property - no matter

Of course during ddl transformation I can choose only needed classes. But it is not very good isn't it

So is there any solution for it in EA?

[«Midnight»]

Hi Edward,

In your transformation, do you test to see if the input classes are stereotyped (or otherwise identified by EA) as «entity» type?

Are you adding a «table» stereotype on output (to the target model) to the classes you want to show up in your DDL? If so, how are you adding this? Is it done by the default EA script behavior, or have you added your own custom code?

David

[Edward G]

Hi David,

In your transformation, do you test to see if the input classes are stereotyped (or otherwise identified by EA) as «entity» type?

yes, you are right. I tested as "entity", as "control", as "boundary"

Are you adding a «table» stereotype on output (to the target model) to the classes you want to show up in your DDL? If so, how are you adding this? Is it done by the default EA script behavior, or have you added your own custom code?

I use the default EA script behavior.
I just make the class model "as is" with and without any stereotypes and then apply the default EA script for DDL transformation.
I get the output database model with tables for each class from the source class diagram.
In class diagram I am not adding a «table» stereotype but each class is converted into table automatically

[«Midnight»]

I believe the default behavior is to transform classes. If you use the default you are likely to get either: all classes, whether they are entities or not, or all classes except entities. [I just don't remember off hand which it is.]

This occurs because entities are just stereotyped classes in EA. Neither of the these behaviors seems to be what you want. I that's the case you will have to write your own version of the transformation. Start by copying the 'stock' EA transformation script and giving it a custom name. You will modify the copy. [EA will not let you edit the original, but that fact is easy to overlook the first time, which could lead to some frustration.]

You'll have to read up on transformation scripts in the EA help, and in resources provided on Sparx Web site. Once you get going you should be fine though. It sounds like you simply need to put in a check for the stereotypes you want to transform, and ignore the other classes.

David

[Edward G]

Thank you for replying, David

Yes I agree with what you say.

It is just limitation of the default templates.

I think any exception will look like that:
%if classStereotype=="enumeration"%
%endTemplate%

Trouble in that it is necessary to study the new language.
However, it is useful  

[«Midnight»]

I agree Edward,

I hope you'll do this stuff - or other customized transformations - enough to make the learning curve worthwhile. This is one area where the payoff can be substantial, but only if you do it often. The curve is fairly steep.

The saving grace here is that this particular problem looks like it will require a very simple solution.

Please let us know how it works.

David

[Edward G]

Hi, David

As the DDL transformation is part of the MDA transformations there is a natural question.

Should the PSM class model contain, initially, only the domain classes, i.e. what will be directly stored in a database?

Then, even if we have full model of classes for our future application, it is necessary to make the private class diagram containing only the enrtity classes. And, of course, to use a default script without any changes?

[«Midnight»]

...
Should the PSM class model contain, initially, only the domain classes, i.e. what will be directly stored in a database?

Then, even if we have full model of classes for our future application, it is necessary to make the private class diagram containing only the enrtity classes. And, of course, to use a default script without any changes?

Edward,

I think the answers to these questions lie in how you - the corporate you - go about this kind of thing. Of course at some point you will have to gather together those classes - whether stereotyped or not - that you want to transform. Obviously this would be at a low enough level of abstraction that the necessary details (columns, data types, etc.) were in the model. EA likes to handle this on a diagram-by-diagram basis, which helps. I have just investigated what happens if the classes are defined in several packages and then referenced (i.e. "simple link") and then generate. The dialog does not allow you to include the 'foreign' tables. What a PITA.  

In any case, take the options that best fit into your development process and paradigm. Adapt as required, based on what works for your needs. You should be OK.

David

[Edward G]

Hi David,

First of all, I am a teacher, an university teacher.
I teach a lot of IT disciplines for students.
So I have more academic interest in using of EA.
I am a licensed user of EA. I have an academic license  

As I understood the EA tool is more than a simple UML tool. I suppose the EA is a constructor too.

So or else I found this discussion is very fruitful!

Thanx again. Good luck

[Edward G]

Hi, David

I have just investigated what happens if the classes are defined in several packages and then referenced (i.e. "simple link") and then generate. The dialog does not allow you to include the 'foreign' tables. What a PITA.  

You know there is not problem with it.
Image yourself. Let you have
package: Class Model and included
     package: Entity Classes
          package: Order Entity Clasess
          package: Goods Catalog
     package: Control Classes
     package: Boundary Classes
and so on
And you have the class diagram in package Class Model
Then you drag'n'drop needed classe on diagram from appropriate package
Then you want to create DDL schema and standing on this diagram select DDL transformation (you must stand on top level package of course). During transformation you should just select include child packages and all classes from child packages will be included in DDL schema automatically  

[«Midnight»]

Absolutely Edward,

This works just fine where you can define a hierarchy. In fact, you can pretty much do the same thing with the class models and data models in two different hierarchies.

But it breaks down (for the data side at least) when the tables are not all under a common package. In some modeling paradigms - or in some projects - this might be the case.

So it would a 'nice to have' feature if we could include referenced externally (to the current package tree) defined tables in our DDL generation. This might be along the lines of report generation options.

I call this nice to have because it is not a necessity to do data modeling, in the sense that not having it does not prevent us from creating a data model. It is also quite possible that opening this up would result in all kinds of complexity. I certainly don't claim to have analyzed this in detail, or even thought it through.

And there is only so far that Sparx can go with data modeling under the current paradigm. The profile they use was not developed by Sparx, and they've made it do things well beyond the original 'envelope' it was designed for. Some time ago the OMG made noises about a more formal profile for such things. They even released (with little fanfare) an RFP for the IMM profile. Since then things have been very quiet on that front. If this thing ever sees the light of day as an approved standard, I suspect (without proof) that Sparx will consider migrating this functional area to the new profile.

David

[Edward G]

David,

sorry for delay. Thank you for your research

So it would a 'nice to have' feature if we could include referenced externally (to the current package tree) defined tables in our DDL generation. This might be along the lines of report generation options.

Yes it would. I think we can suggest it for develepment