Home » Modeling » UML2 » cmof to emf
| cmof to emf [message #476776] |
Mon, 17 December 2007 13:28  |
Eclipse User |
|
|
|
I am using the latest uml2 I-build to open the SBVR cmof model and generate
and EMF ecore model from it. All seems to work well in my initial testing,
but the cmof class attribute mapping to emf could use some improvement.
In the SBVR metamodel, the attribute names use all lower-case with words
separated by spaces. For example, in the "concept" class, there are
attributes "more general concept" and "necessary characteristic". In the
ecore mapping the spaces are removed, yielding attribute names like
"moregeneralconcept". It would be much better to convert to camel case
while removing spaces. Any reason not to do this?
Thanks,
Dave Carlson
|
|
|
| Re: cmof to emf [message #476777 is a reply to message #476776] |
Mon, 17 December 2007 13:36  |
| Eclipse User |
|
|
|
Also, having just generated the model Java code, all class names start with
lower case, e.g. "concept", as defined in the cmof model. Maybe class names
should be mapped to upper-camel-case in the cmof to ecore mapping?
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message
news:fk6f48$kf5$1@build.eclipse.org...
>I am using the latest uml2 I-build to open the SBVR cmof model and generate
>and EMF ecore model from it. All seems to work well in my initial testing,
>but the cmof class attribute mapping to emf could use some improvement.
>
> In the SBVR metamodel, the attribute names use all lower-case with words
> separated by spaces. For example, in the "concept" class, there are
> attributes "more general concept" and "necessary characteristic". In the
> ecore mapping the spaces are removed, yielding attribute names like
> "moregeneralconcept". It would be much better to convert to camel case
> while removing spaces. Any reason not to do this?
>
> Thanks,
> Dave Carlson
>
>
|
|
|
| Re: cmof to emf [message #476780 is a reply to message #476777] |
Mon, 17 December 2007 14:34 |
| Eclipse User |
|
|
|
Dave,
The current algorithm for processing class names is consistent with what EMF
does, i.e. the bare minimum to ensure that the result is a valid Java
identifier. Unfortunately, we can't make changes to the default behavior,
because this same conversion mechanism is used for profile definition and
such changes might have an adverse effect on clients that expect the
existing behavior. These suggestions are useful though; perhaps you could
open an enhacement request in Bugzilla, and we could consider adding a new
option or two to support simple formatting rules to names during the
conversion process...
Kenn
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message
news:fk6fir$n1s$1@build.eclipse.org...
> Also, having just generated the model Java code, all class names start
> with lower case, e.g. "concept", as defined in the cmof model. Maybe
> class names should be mapped to upper-camel-case in the cmof to ecore
> mapping?
>
> "Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message
> news:fk6f48$kf5$1@build.eclipse.org...
>>I am using the latest uml2 I-build to open the SBVR cmof model and
>>generate and EMF ecore model from it. All seems to work well in my
>>initial testing, but the cmof class attribute mapping to emf could use
>>some improvement.
>>
>> In the SBVR metamodel, the attribute names use all lower-case with words
>> separated by spaces. For example, in the "concept" class, there are
>> attributes "more general concept" and "necessary characteristic". In the
>> ecore mapping the spaces are removed, yielding attribute names like
>> "moregeneralconcept". It would be much better to convert to camel case
>> while removing spaces. Any reason not to do this?
>>
>> Thanks,
>> Dave Carlson
>>
>>
>
>
|
|
|
| Re: cmof to emf [message #476781 is a reply to message #476780] |
Mon, 17 December 2007 14:48 |
| Eclipse User |
|
|
|
Thanks, Kenn. See:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213218
Until then, I'll look into a quick utility that converts names in SBVR model
to camel case before exporting to Ecore.
Dave
"Kenn Hussey" <Kenn.Hussey@embarcadero.com> wrote in message
news:fk6iv3$o2f$1@build.eclipse.org...
> Dave,
>
> The current algorithm for processing class names is consistent with what
> EMF does, i.e. the bare minimum to ensure that the result is a valid Java
> identifier. Unfortunately, we can't make changes to the default behavior,
> because this same conversion mechanism is used for profile definition and
> such changes might have an adverse effect on clients that expect the
> existing behavior. These suggestions are useful though; perhaps you could
> open an enhacement request in Bugzilla, and we could consider adding a new
> option or two to support simple formatting rules to names during the
> conversion process...
|
|
|
| Re: cmof to emf [message #625750 is a reply to message #476776] |
Mon, 17 December 2007 13:36 |
| Eclipse User |
|
|
|
Also, having just generated the model Java code, all class names start with
lower case, e.g. "concept", as defined in the cmof model. Maybe class names
should be mapped to upper-camel-case in the cmof to ecore mapping?
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message
news:fk6f48$kf5$1@build.eclipse.org...
>I am using the latest uml2 I-build to open the SBVR cmof model and generate
>and EMF ecore model from it. All seems to work well in my initial testing,
>but the cmof class attribute mapping to emf could use some improvement.
>
> In the SBVR metamodel, the attribute names use all lower-case with words
> separated by spaces. For example, in the "concept" class, there are
> attributes "more general concept" and "necessary characteristic". In the
> ecore mapping the spaces are removed, yielding attribute names like
> "moregeneralconcept". It would be much better to convert to camel case
> while removing spaces. Any reason not to do this?
>
> Thanks,
> Dave Carlson
>
>
|
|
|
| Re: cmof to emf [message #625753 is a reply to message #476777] |
Mon, 17 December 2007 14:34 |
| Eclipse User |
|
|
|
Dave,
The current algorithm for processing class names is consistent with what EMF
does, i.e. the bare minimum to ensure that the result is a valid Java
identifier. Unfortunately, we can't make changes to the default behavior,
because this same conversion mechanism is used for profile definition and
such changes might have an adverse effect on clients that expect the
existing behavior. These suggestions are useful though; perhaps you could
open an enhacement request in Bugzilla, and we could consider adding a new
option or two to support simple formatting rules to names during the
conversion process...
Kenn
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message
news:fk6fir$n1s$1@build.eclipse.org...
> Also, having just generated the model Java code, all class names start
> with lower case, e.g. "concept", as defined in the cmof model. Maybe
> class names should be mapped to upper-camel-case in the cmof to ecore
> mapping?
>
> "Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message
> news:fk6f48$kf5$1@build.eclipse.org...
>>I am using the latest uml2 I-build to open the SBVR cmof model and
>>generate and EMF ecore model from it. All seems to work well in my
>>initial testing, but the cmof class attribute mapping to emf could use
>>some improvement.
>>
>> In the SBVR metamodel, the attribute names use all lower-case with words
>> separated by spaces. For example, in the "concept" class, there are
>> attributes "more general concept" and "necessary characteristic". In the
>> ecore mapping the spaces are removed, yielding attribute names like
>> "moregeneralconcept". It would be much better to convert to camel case
>> while removing spaces. Any reason not to do this?
>>
>> Thanks,
>> Dave Carlson
>>
>>
>
>
|
|
|
| Re: cmof to emf [message #625754 is a reply to message #476780] |
Mon, 17 December 2007 14:48 |
| Eclipse User |
|
|
|
Thanks, Kenn. See:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213218
Until then, I'll look into a quick utility that converts names in SBVR model
to camel case before exporting to Ecore.
Dave
"Kenn Hussey" <Kenn.Hussey@embarcadero.com> wrote in message
news:fk6iv3$o2f$1@build.eclipse.org...
> Dave,
>
> The current algorithm for processing class names is consistent with what
> EMF does, i.e. the bare minimum to ensure that the result is a valid Java
> identifier. Unfortunately, we can't make changes to the default behavior,
> because this same conversion mechanism is used for profile definition and
> such changes might have an adverse effect on clients that expect the
> existing behavior. These suggestions are useful though; perhaps you could
> open an enhacement request in Bugzilla, and we could consider adding a new
> option or two to support simple formatting rules to names during the
> conversion process...
|
|
|
Goto Forum:
Current Time: Mon Jul 28 13:52:52 EDT 2025
Powered by FUDForum. Page generated in 0.04999 seconds |
Home