Renaming an attribute type during transformation

[Code Ferret]

Hello all,
   I'm using EA to model a LabVIEW system.  In LabVIEW, 64-bit floating point numbers are named "DBL." in Java they are named "Double."

   How can I get EA to change attribute types of "DBL" in my model to "Double" when I do a transform?

Thanks!

[Code Ferret]

I should probably point out that in the programming language datatypes, LabVIEW and Java share the "Double" common type.

[Oliver F.]

Hello all,
   I'm using EA to model a LabVIEW system.  In LabVIEW, 64-bit floating point numbers are named "DBL." in Java they are named "Double."

   How can I get EA to change attribute types of "DBL" in my model to "Double" when I do a transform?

Thanks!

I would have proposed the Settings -> Code datatypes facility, however it does not work reliably with custom products.
So you would have to do a mapping on your own in the attribute template like

Code: [Select]

%if type=DBL% type=Double %endIf%
Or similar.

Oliver

[Code Ferret]

Thanks for the advice.  Using conditional branching (if-then-else) does do the trick, but I've discovered that EA is not doing this conversion for any custom type in any language. This means that I'd have to write conditional branches for every single custom type!

In my datatypes definitions, the common type is shared:

labview: datatype=DBL, common type=double
java: datatype=double, common type=double

Yet when transforming from labview to java, the type still appears as "DBL." This is also true when transforming from labview->C#.

Is EA broken, or am I doing something incorrectly?

[Eve]

Assuming you're using the CONVERT_TYPE macro.  Yes, you are doing something wrong.  It takes a common type and converts to a target type.  It doesn't take a type from one language and convert it to common and then to a target type.

If you're not using CONVERT_TYPE, EA is making no attempt at all to change your types.

[Code Ferret]

Thanks for your reply.

> It doesn't take a type from one language and convert it to common and then to a target type.

How are the custom and target types associated, if not through matching common types?

The default template uses this:

type=%qt%%CONVERT_TYPE("Java",attType)%%qt%

But it appears that attType==DBL, not Double as I'd expect.  If I do this:

  %if attType=="DBL"%
    type=%qt%double%qt%
  %else%
    type=%qt%%CONVERT_TYPE("Java",attType)%%qt%
  %endIf%

Then it works, for this particular type ("DBL"), while not changing _all_ types to Double.  So it seems to me that attType is not returning the common type, but the data type - and this behavior comes right out of the default template.

If the supplied template does not transform the model's custom type into the target type, what is the correct method?

[Code Ferret]

Oops.  I've been careless with capitol D and lowercase in my posted examples, but not actually in my templates.  in other words, the common types match exactly.

[Eve]

What I'm saying is that it will convert from the common type to your language.

eg. double -> DBL.

It will not convert from one language to another.

eg. DBL -> double -> double.

[Code Ferret]

Ah.  The light goes on.  We've not been creating a true PIM.  

So, can you go backwards - make a PSM and convert it to a PIM using the common types?

[Eve]

Yes, but usually it's harder because you have to identify what in your psm is platform specific.

[Paolo F Cantoni]

Yes, but usually it's harder because you have to identify what in your PSM is platform specific.

Indeed!  But is sure is easier than starting from scratch...  

Paolo

[Oliver F.]

Yes, but usually it's harder because you have to identify what in your PSM is platform specific.

Indeed!  But is sure is easier than starting from scratch...  

We have been going through this sort of  hell by converting an existing Oracle database PSM to a generic PIM. Especially if the database  expects a certain structure without having to change existing software modules relying on the model it is as hard as it can be.

Oliver