MDG CORBA IDL Plugin Question on enum

[davisford]

Hi, when using v1.01 of the MDG CORBA IDL plugin, I get errors when I hit an enum that is initialized.  Example:

enum SomeThing {
   THING1 = 1,
   THING2 = 2,
   THING3 = 3
};

The tool skips the import of the enum when importing the IDL file.  In addition, if there are items that exist in the IDL below the enum (e.g. struct), the tool does not import them.

I can fix this by editing the IDL file to be this:

enum SomeThing {
   THING1,
   THING2,
   THING3
};

In this case the enum is correctly imported.  I can then go into the attributes directly and assign the initial values, but this is undesirable.  Is there a quick-fix or workaround for this?

Thanks in advance,

Davis

[davisford]

Hi, I have a follow on question on IDL string types.

The MDG tool also does not seem to like the < or > characters.  It issues an error when I try to import IDL with a struct like the following:

struct someStructName {
   string<256> someString;
};

I don't claim to be an IDL expert, but I am curious whether the syntax is wrong, or if the tool can be fixed to support this?

Thanks in advance,
Davis

[Eve]

According to the 3.0.3 CORBA spec.

Enumerated types consist of ordered lists of identifiers.

So on that one we're doing the right thing.  No initialized enums.

On the other hand, it looks like there is a problem with the string<> types, and I'll have a look at what is causing that.

The import will stop as soon as an error is found.  At that point anything that has not been parsed completely is also discarded.

Simon

[davisford]

Hi Simon,

The spec seems vague on this (I am looking at OMG IDL Syntax & Semantics, July 2002).

I agree with you on the definition -- that an enum is an ordered list of identifiers.  However, to me, this simply means exactly what it says -- that the identifiers are ordered, but it doesn't seem to preclude one from starting the order at some value, or initializing them to something like 0, 2, 4, 6...

I'm not sure I understand why or why not this means I couldn't initialize the first identifier in the list to some value (e.g. 1) and the rest follow that order.

I'm probably wrong -- searching Google, I seem to find conflicting viewpoints on this topic.

Can you keep me posted on the string<> resolution -- very much appreciate all the great work at Sparx..

Regards,
Davis

[Eve]

The spec that I referred to is March 2004 and includes a grammar. (Section 3.4)

( 78 ) <enum_type>    ::= “enum” <identifier>
                                               “{” <enumerator> { “,” <enumerator> }  “}”
( 79 ) <enumerator>   ::= <identifier>

Also from section 3.2.3

An identifier is an arbitrarily long sequence of ASCII alphabetic, digit, and underscore (“_”) characters.

Simon

[davisford]

Hi Simon,

I agree with that...no problem.  

A further question, however -->  Why doesn't the tool import CORBA constant types?

example:

const unsigned short SOMETHING = 64;

[davisford]

Hmm...sorry to keep pestering you, but it seems the tool incorrectly imports IDL arrays, as well.

Try this simple test IDL:

module someModule {
const unsigned short SOMECONST = 64;

struct someStruct
{

unsigned short someArray[SOMECONST];

};
};

When the import is run, it skips the const, and then creates a class stereotyped as <<CORBAStruct>> with a single attribute called SOMECONST: unsigned short.

In the UML Profile For CORBA specification, an IDL constant is modeled as a UML attribute as stereotype CORBAConstant, with an initial value.  Constants defined within the scope of an IDL interface become attributes of a Class that is stereotyped as <<CORBAObjectType>>.

For constants defined within a CORBA module scope a new stereotype CORBAConstants of UtilityClass is introduced.  The name of the Class must be "Constants".  

The owner of a <<CORBAConstant>> stereotyped attribute must be stereotyped <<CORBAConstant>> or <<CORBAObjectType>>

A <<CORBAConstant>> Attribute has the changeability frozen.

There is an example given that shows the UML for the following IDL:

module Y {
constant short S = 3;
}

It generates a UML package called Y with stereotype <<CORBAModule>>.

Inside the Package exists a class stereotyped <<CORBAConstants>> named Constants.

The class has a single attribute called S, stereotyped as <<CORBAConstant>> with type short and init value of 3.

--------
So a couple of questions arise out of all this:

1) Can there be support for reverse-engineering CORBAConstant?  (refer to section 3.4.11)
2) Can there be support for reverse-engineering CORBAModule into UML packages -- the tool doesn't seem to do this. (refer to section 3.5.4)
3) Can there be support for reverse-engineering CORBAArrays -- the tool doesn't seem to do this (refer to section 3.5.20)

Best regards,
Davis