[Uml-devel] Data types and codegenerators
Luis De la Parra Blum
lparrab at gmx.net
Mon Mar 17 12:36:34 UTC 2003
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
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.
More information about the umbrello-devel