[Uml-devel] Data types and codegenerators

[Luis De la Parra Blum]

On Monday 17 March 2003 17:17, Brian Thomas wrote:
> > I'd say you make a set of classes containing the different primitive
> > types (CppPrimitives, JavaPrimitives, SQLPrimitives and so on ) and when
..
> 	But I dont think this will work well. Consider my earlier argument that
> there may be more than one mapping between a UML type and what is available
> in that language (as I said before.. just the UML "int" type may map to
> "int", "short", "long", "Integer", etc in Java. C++ has many mappings too).

I understand and agree with your argument. 
Of course that having the mapping of UML types to language-specific types 
configured at code-export time ( in the code generators) is really good -- 
after all, you can't export to "UML programming language", so if you want to 
use the code generator at all -- and you use uml types in your diagram--, 
you'll need this mapping and having it as a configure option is always better 
as hard-coding...

but as I wrote the previous coment I was thinking of the case where  you want 
to orientate your design for a specific programming language.. -> if you want 
the attribute of your class to be  of type "int",like in C++ and not of type 
"Integer" like in UML (or whatever it's called there). right now all types 
are nothing but strings (internally), so if I want a "string" I have to type 
"string" then go back and change the "S" to "s". so I thought it'd be nice if 
you could get the list and the auto-completition to suggest types appropiate 
for the language. That's why I said the language only afected the options you 
get in the selection box--> all the classes you have in your model, plus the 
primitives you have in the currently selected "active language". Of course, 
if I select C++ I will get std:string listed as an option, but I can always 
write String or MyString if I want.

Actually... I think it'd be great if the types listed in that box were read 
from a config file.. that way I could have QString and QWidget available as 
select-options without having to put those classes in my model.

This has the (big) disadvantage that your design is "language specific", but 
some people my prefer to see their classes that way.

so...that was just MVHO. 
and anyways.. the two "aproaches" dont conflict at all... you'll always need 
the "mapping" for the UML types, and you can also have the primitive listed 
in the combobox at the same time. so you can mix UML and language specific 
types if you feel like it.

saludos,

luis