Custom Table Stereotype

[Thomas Mercer-Hursh]

I am working on defining a Profile for the ABL language from Progress Software and the Progress database.  The purpose is to provide appropriate names, mapping, constraints, and rules of well-formedness corresponding to existing legacy applications so that models can be built from those applications for analysis and transformation.

In EA6.5, if I create a new class using the table stereotype, there is a prompt on the table details tab for Table Space.  In exported XMI I see this in <ExtendedProperties>, but I am not finding any documentation on where this fits in the UML or where that prompt comes from with a table stereotype, but not for a regular class on which table is based.  I want to define a new stereotype for tables in the Progress database because they have their own characteristics.  How do I go about getting this same behavior with a new stereotype and/or causing this prompt to be there based on XMI which gets loaded?

[«Midnight»]

Thomas,

[Spotters' note: there's a hint at the bottom.]

Before you delve too far into the following, make sure you cannot accomplish what you want by defining your own DBMS flavor in EA. This feature is pretty limited, but it just might do enough for you.

You are running into a custom dialog that EA provides for this particular stereotype. That's why there are additional properties.

You can accomplish something along the same lines with some work. First create a metamodel, defining your own metaclasses and stereotypes. You'll need to save this as a profile, which can then be loaded into other EA models.

Now you can write an add-in which brings up your own dialogs when such a stereotyped class is loaded. When this happens, your add-in can signal EA that it has done the necessary work, so that EA does not raise its own dialog.

All of this is covered in the EA documentation, as well as examples and white papers on the Sparx site. However, you'll need to read between the lines a bit to get it working the first time.

Now the hint. Take a look at tagged values. You'll be using them in your metamodel.

David

[Thomas Mercer-Hursh]

I had already connected with tagged values for a number of the properties which didn't map to anything else.  My inquiry was driven by the combination of this property showing up as a part of the regular dialog and the fact that it shows up in an XMI export as an ExtendedProperty rather than some other, more standard tag.

Would I be right in guessing that something tagged as an ExtendedProperty would not be predictably portable to another UML tool ... not that I'd want to use one, you understand, but the tool we will build to generate this XMI from code would be more attractive if it could be used with any sufficiently capable UML modeling tool.  Or, is the answer here a qualified one, i.e., that I could use it with another tool, but I would have to do the same developmental extension in that tool as I had done in EA.

Also, I can see that the ultimate solution here is to do the development which provides custom support for my stereotypes, but is there any way that I can "cheat" in the short term.  I.e., my <<OETable>> stereotype is really an extension of the built-in <<table>> stereotype.  While it might be more elegant to have defined the profile in EA and created custom dialogs and such, I would actually have a reasonably workable solution if I could load via XMI and have EA treat it as if it had been created from a <<table>> stereotype, but have the indicated stereotype be <<OETable>>?  Or, alternatively, would it be reasonably easy to clone the code supporting the <<table>> stereotype so that the same behavior happened for <<OETable>> ... behavior which I might extend at some later date?

I recognize that the ultimate answer will only come when I dig in to the extension mechanism, but I am busy at the moment with the profile itself, so it will be a week or two before I am likely to have a chance to do that.

I will also note that we are going to look at using EA Automation for the load as an alternative to XMI since it might reduce time to market, but the XMI route is appealing because it is tool neutral ... just in case someone likes a different tool.

Thanks for the pointers.

[«Midnight»]

Thomas,

I agree with much of what you have to say, having been down the greater part of this path with EA myself.

The «table» stereotype (and perhaps «column» as well) are a bit of a love-hate thing. EA works really well with them, within the bounds of its (EA's) defined functionality. Beyond that you are in the tall grass.

EA does treat this particular stereotype as something special. At least it does so if EA itself assigns the stereotype when you drag a Table element onto a model.

It is possible that EA will treat it like any other stereotype if you assign it by hand. I have not tried, but you might want to for your own purposes. If this is the case, perhaps your own metamodel could assign a «table» stereotype to trick EA into processing the entity, while assigning an additional (alternate) sterotype to identify your subclass.

In any case it appears that at generation time EA simply checks whether a Class element has the «table» stereotype and reacts if it does.

Now the sad news. Unlike transformations and other generation scenarios, DDL generation is not exposed to we poor sad users. Thus we cannot create custom DDL generation templates. I believe this dates back to the days before EA developed the powerful generation and transformation engines it has now, and that the DDL generation got left out (or was spared from development risk) when these new things came along.

Regardless of the reason, this omission has sparked much lively debate in the user community, or at least in this forum. There have been a correspondingly large number of requests for some relief. To date this has not happened.

I do not know if some flexibility will be provided in version 7.0 when it comes to production, but that does not look likely at this time (beta 1).

The good news it that it is easier to build a DDL generator than a transformation or code generation engine.

Let me know how you approach this one. As someone who has the scars of old battles in this arena I'd be interested.

David

[Thomas Mercer-Hursh]

Hmmm.... definitely sounds like some poking about might be required before I get a very clear handle on this one.  There seems to be a suggestion here that I might be able to achieve different results with Automation than with XMI ... which isn't altogether surprising.  It is a tad uncomfortable, though, because we had previously decided to go the XMI route for the code analysis tool.  Automation might be easier, but it will certainly be tying us to EA ... which I don't mind, but the guy who wants to sell the tool might.

And, I suppose it is possible that there is a different best answer for code versus database.  The code part will mostly use stereotypes which have nothing to do with existing stereotypes so, while one could add value by developing specialized add-ons, there is nothing existing which one would try to emulate ... unhappily, this is partly because most of the code we are likely to try to suck in is non-OO.  So, XMI might work well for the code.

For the database, I had been thinking in terms of writing ABL code to spit out the XMI, which looks like it could be quite easy since the ABL would have easy access to the metaschema and ABL is good at XML.  But, there is also some attraction of working from a .df, the Progress version of DDL, since it also has an incremental change version for keeping things in sync.

Well, like I said, looks like more study required.

[«Midnight»]

Remember that you can always reach into the underlying data behind your EA repository. This might be a valid route for you to take, if only to get you past this hurdle and into prototyping. You can come back later to clean up, after you've proofed your concept end-to-end.

Also, remember that XSLT could be a powerful tool for you, not only with your XMI, but in handling SQL dialects.

EA will allow you to specify a style sheet when you export XMI, but not on import. For the import side you should pre-process at the point where you prepare the stream for EA. [Note that EA will only write XMI to (or read XMI from) a file, not a string or stream.]

With transforms, you can specify that EA send the results directly to another transform, at least in the UI. A transform must (AFAIK) specify a package as its target. Through automation you could probably create target packages for intermediate steps, then chain another step on and clean up the prior target. You could spit out XMI (or DDL for that matter) when you got to the end.

This would likely work for a custom template that read your data model and created DDL. There's nothing preventing you from writing a transform or generation script that outputs DDL instead of programmatic code. It's more work, but you'd have the ability to handle your custom stereotypes. You could also build a metamodel, load it as a profile, and gracefully handle detection and reaction.

I agree there's more study required, but I think you might want to call your best developers together soon and get your hands dirty.

Sounds like fun!

David

[Thomas Mercer-Hursh]

I do plan on looking at the underlying schema, but I am reluctant to work execute against it directly for this purpose since it seems one would be very vulnerable to version changes and it would be very easy to miss important actions which happen when using the provided mechanisms.

XSLT seems to me to be an option mostly if we find that we need different XMI dialects to support different tools.  Of course, at this point, since EA is the preferred tool by Progress developers, it may be that no one ever asks for the second tool.

Step one seems to be to define the initial target and then start both defining the necessary XMI and get digging into automation.

[«Midnight»]

Yep, makes sense to me.

The EA schema has remained pretty stable - very minor changed, primarily in content rather than structure - since around version 3.60.

I had sort of expected (hoped for actually) that Sparx would bite the bullet and update the schema for 7.0. It's been a long time, and (strictly IMHO) the potential benefits of a new, stable platform could easily outweigh the pain of some breaking changes.

It looks like this has not happened, so we're likely safe until at least version 8. Given past trends that's probably sometime in 2009.

Regardless, you're OK for now, and working against 6.5 (whether you go down to the schema or not) should set you up well for the next year at least.

David

[Thomas Mercer-Hursh]

Thanks.  I suppose it is a matter of principle ... if someone defines an API, I think I should use it unless I can't get the job done in other ways, i.e., the API is defective.  Seems like the thing to do.

I have to say that, while I haven't had time to do a lot of digging thus far, I am not finding it easy to come up with what seems like clear guidance on this under-the-surface stuff.

One small example.  If I look at the dialog for defining new stereotypes, there appears to only be an option of defining a stereotype in terms of a standard UML base class.  And yet, in the list of existing stereotypes I see what appear to be stereotypes defined as applying to other stereotypes ... or something.  E.g., in the list in a project I have that I know includes some Progress-specific additions to which I don't have source, there is a stereotype for "temp-table" whose applies to is "table".  A temp-table is just what it sounds like, a table that is created and lives only for the duration of the execution of the compile unit.  I.e., it is a sensible thing, but how did it get there?  And, is is well-formed?  Also, I see FK with an applies to of optable, but nowhere do I see any reference to what an optable might be.