Code Generation and Stereotypes

[dhestand]

I don't know if I've just missed this or what but it seems that using EA to generate Java code skips stereotype information.  I'm using 3.51.601.  I have a couple of interfaces in my diagram but when I generate the code, I end up with classes and the classes that have a stereotyped <<realizes>> association with the interface simply extend the class not implement.  What am I doing wrong here and where did I miss it in the docs?  Thanks.

[benc]

Hi Dhestand,

Are you using the drag-and-drop of the interface element
from the class toolbox.  (It's directly under the class element)?

If you just create a concrete class and manually set the stereotype to "interface", you'll end up with the behaviour you described...

Hope it helps.

Ben.

[dhestand]

That's exactly what I was doing.  Thanks.  So I guess my next question is why is there a difference as far as the tool is concerned?  I would think the stereotype info when present should override the basic shape type.  Anyway, your recommendation works and all is well.

Dan

[DavidT]

I am having a similar problem with sterotypes in when generating codes using VB.NET.  I defined a structure stereotype but the codes generated used class instead.  Am I missing something or is this a feature not supported in 3.51

Thanks,

---DavidT

[Havyck]

Sorta along those lines, when I create a class diagram for my Array class, I can't set boolean as the return type! Why not? I'm creating the class in c++...

Great interface though!

[benc]

Let me try answer the last few posts...

Dan: We'll look into whether using the "interface" keyword (for the stereotype) is an appropriate way to make an interface out of a concrete class.  I guess the toolbox helps to enforce the difference between interface and class classifiers.  For the moment best use the interface element for interfaces and the class element for classes.

DavidT : As far as I'm aware, EA doesn't support the structure stereotype for VB .NET.  However we are currently doing some work on code Templates, which will fix this limitation.

Havyck:  I'm not exactly sure of your problem here.  Are you forward or reverse engineering a C++ class?  (I take it the class contains a method that returns a boolean value and this return type is not showing up on the subsequent class diagram)  Let us know...

Ben.

[dhestand]

With respect to the interface stereotype and concrete classes, I guess it becomes an issue of whether or not an interface stereotype is appropriate for a concrete class (and I don't have the spec in front of me at the moment).  If not, then the interface modifier should not be allowed on concrete classes, but if so, then it seems that an interface stereotype changes the class from concrete to abstract because of the  lack of implementation detail.  Anyway, I have changed my habit to choose the appropriate model element instead of relying on stereotypes (probably should of done that in the first place)...

[Havyck]

Yes, I'm getting ready to generate code from a class diagram. I'm adding attributes and functions at the moment. I wanted to make some of my set functions return a boolean as is the convention in our current project. However, I wasn't able to choose boolean as a return type. Perhaps I'm missing something but I set all the other return types using the "operations" dialog.

[benc]

Hi Havyck,

To add a datatype to a language:
(From the menu bar) Reference->Language Datatypes->Product Name->C++

The types you add in the Language Datatypes dialogue will then appear in the drop down list of types in the operations dialogue.  Alternatively you could just type "bool" in the type field every time ...

Hope that helps.

Ben

[dknox]

I think the bottom line is the UML specification. If a Class classifier is stereotyped as an interface, the language mapping should be able to understand that. After all, an interface is a Class classifier with a <<interface>> stereotype.

In UML 1.5, the definition is a tad confusing because it defines an interface as "formally equivalent to an abstract class". This implies the conclusion that an interface is a class with modifiers making it abstract (stereotype and isabstract tag set to true).

However, in the same sentence the spec states that an Interface is "a peer of class within the UML metamodel (both are classifiers)". This implies that Class and Interface are peer instances of Classifier.

There is some clarification for tool builders in the Notation section of the definition. "An interface is a classifier.....shown using the full rectangle symbol....and the keyword <<interface>>". And again in the Mapping section: "A class rectangle with stereotype <<interface>>.."

I would lean toward implementing an interface more toward being an abstract Class. Meaning that I would not use two different classifiers to render Classes and Interfaces. An Interface is a Class with the keyword <<interface>> and the isabstract tag set to true.

my 2p
-- dave