Transformation templates using complex datatypes

[Oliver F.]

Let's see, if somebody comes up with a clever solution how to do this in EA. I believe this is a challenge as we have a hard time here.

A business domain model (PIM) is comprised out of classes which have attributes. Each attribute is not of simple but of complex (business) classifier type.

This looks like this in pseudo code:

Code: [Select]

business class A
{
     attribute x: Type_X;
}

class Type_X
{
}

Classifier Type_X holds tagged values which describe the platform specific datatype in the corresponding technology (SQL, JAVA, C#, etc.).
We have to do this as code and databases are existing and we can not choose arbitrary datatypes which do not conform to the current solution.

Now the challenge: Create transformation templates for the platform specific model to fill in the corresponding datatypes.

This means: Read the classifying datatype (Type_X) and use its tagged values (SQLType, DevType, etc.) to fill the correct PSM datatype of the platform class A (to be generated) so that A looks like:

Code: [Select]

class A
{
     attribute x: INT(4);
}

So now a clever solution is sought as all attempts we have tried with the transformation templates revealed no success. It seems impossible to read the tagged value of a classifier of an attribute.

The datatype mapping dialog also did not work properly for custom datatypes (which is a reported but uncared bug, actually).

So ideas are welcome.

Thanks in advance.

Oliver

[Oliver F.]

Some more investigation revealed that  the issue can be reduced to the following: How to read the tagged values of a type classifier in the Attribute section of a transformation template?
Alternatively: How can I access the inherited tagged values of an attribute in the transformation template?

The only thing to get seems to be its GUID via attClassifierGUID but as I do not want to transform it this seems to be useless.

Ideas are still welcome.

Thanks,

Oliver

[Uffe]

Hi Oliver,


Well it's probably not what you want but... Instead of using tags to represent the target PSM, have you tried stereotypes? You could then easily get at the information using the %attStereotype% macro.

Another way might be to use connectors instead of attributes. You could then use the %connectorDestElemTag% macro.

If that doesn't do it for you, here's a thought: you might be trying to do too much in a single step. If I understand you correctly, you've got a PIM class with an attribute whose class contains PSM information. If instead you create a separate Transform for each of your target PSMs you don't need that information in the PIM.

In either case I am unaware of anything along the lines of an %attTypeClassTag% macro, which is what you'd want for this. Since the class* macros exist for connectors, maybe Sparx might consider adding the corresponding for attType?


/Uffe

[Oliver F.]

Thanks for your suggestions.

Well it's probably not what you want but... Instead of using tags to represent the target PSM, have you tried stereotypes? You could then easily get at the information using the %attStereotype% macro.

We have about 750 (propably more) custom data types in the system which are used in the general database model, communication paths, etc. That means the same type can be found in the database, transported via interfaces, be represented in classes, etc.
Each datatype has some description, notes, identity and later on maps to one psm datatype (INT2, INT(4), VARCHAR, etc.) depending on the target platform. Primarily DDL is targeted plus further header file generation for various languages.

A business object thus has attributes referencing such datatypes as classifiers, not simple types.
If we went for stereotypes for the attributes then we'd either have to have 750 stereotypes (in which case we will loose the meta information of the datatypes) or use INT, VARCHAR, etc. as stereotypes in which case we will loose the ability of having system wide representations of data objects of the same type.

A simplified example of a different business: A cargo number is of type cargo_no. The type is defined as having a range between 1-2047, an undef value of 0 and an overflow of 4095. Plus constraints and restrictions.
It maps to Integer in Java, INT(2) in Oracle, etc. which are actually defined as tagged values.
This cargo_no is then used in the communication interface specifications, data objects, logging, reporting, and more.

Another way might be to use connectors instead of attributes. You could then use the %connectorDestElemTag% macro.

Could be an option but is rather unconvenient to model. It is much more comprehensive to open the data type dialog and choose the data type from the corresponding namespace.

If that doesn't do it for you, here's a thought: you might be trying to do too much in a single step. If I understand you correctly, you've got a PIM class with an attribute whose class contains PSM information. If instead you create a separate Transform for each of your target PSMs you don't need that information in the PIM.

This is indeed what I try to accomplish. There still should be several transformations to different target PSMs by considering the tagged value information from the PIM objects for the corresponding target technology.

If I now knew how to access the inherited tagged values of an attribute I'd feel much more comfortable.

Thanks for your suggestions.

Oliver