Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » BehavioredClassifier#implementedInterfaces
BehavioredClassifier#implementedInterfaces [message #477863] Thu, 23 October 2008 07:20 Go to next message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
Hi,

I was trying to understand the rationale for
BehavioredClassifier#implementedInterfaces, given that it does not seem
to appear on the UML spec. Up to now, I was assuming the UML2 API
matched the UML metamodel as colsely as possible.

I don't have a problem with it, it looks convenient, just trying to
understand things.

Cheers,

Rafael
Re: BehavioredClassifier#implementedInterfaces [message #477865 is a reply to message #477863] Thu, 23 October 2008 15:05 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Rafael,

In addition to following the UML spec. (as closely as possible), the UML2
API defines some convenience operations.
There are for example, convenient "create" methods sprinkled around;
uml:Element has some handy getRelationship() methods that use the inverse
cross reference adapter, and there are some extra methods to support
profiles and stereotype application and keywords ... to name a few.
It appears that you have come across one of these convienient methods. I'm
not certain of its history but it may have been requested by someone in the
past.

To make you feel good about the accuracy of the API ...
* The normative reference that the UML2 superstructure spec references is
actually generated from the core .uml models maintained by this project.
* In addition, many of the diagrams that you see in the spec itself are
generated from the .emx files also maintained by this project. Bran Selic,
the previous UML2 chair and editor of the superstructure spec used to
maintain these diagrams with Kenn Hussey. ( The .emx for the UML 2.2 are
out of date currently but will be updated soon. All previous versions are
up to date).
* Kenn was extremely meticulous when it came to accuracy with the API ...
take my word for that one ;)

Cheers,
- James.



"Rafael Chaves" <rafael@abstratt.com> wrote in message
news:gdp8jt$ive$1@build.eclipse.org...
> Hi,
>
> I was trying to understand the rationale for
> BehavioredClassifier#implementedInterfaces, given that it does not seem to
> appear on the UML spec. Up to now, I was assuming the UML2 API matched the
> UML metamodel as colsely as possible.
>
> I don't have a problem with it, it looks convenient, just trying to
> understand things.
>
> Cheers,
>
> Rafael
Re: BehavioredClassifier#implementedInterfaces [message #477866 is a reply to message #477863] Thu, 23 October 2008 15:05 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Rafael,

The UML2 API does not match the specification one to one; in some cases (as
in this case), additions have been made for convenience. These additions are
defined in a separate source model, org.eclipse.uml2.uml/model/UML.uml
(which is merged with the "official" source models to produce the final
API).

Kenn

"Rafael Chaves" <rafael@abstratt.com> wrote in message
news:gdp8jt$ive$1@build.eclipse.org...
> Hi,
>
> I was trying to understand the rationale for
> BehavioredClassifier#implementedInterfaces, given that it does not seem to
> appear on the UML spec. Up to now, I was assuming the UML2 API matched the
> UML metamodel as colsely as possible.
>
> I don't have a problem with it, it looks convenient, just trying to
> understand things.
>
> Cheers,
>
> Rafael
Re: BehavioredClassifier#implementedInterfaces [message #477871 is a reply to message #477865] Thu, 23 October 2008 15:22 Go to previous messageGo to next message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
Thanks James, Kenn.

Is there a simple way of telling convenience and metamodel derived API
apart?

The heuristic I have been using is that since it seems the top-level
javadoc enumerates all metamodel related supported features, and thus if
a relationship navigation method exists and it does not appear as one of
the supported features, it is a convenience method.

Does that make sense?

Cheers,

Rafael

James Bruck wrote:
> Hi Rafael,
>
> In addition to following the UML spec. (as closely as possible), the UML2
> API defines some convenience operations.
> There are for example, convenient "create" methods sprinkled around;
> uml:Element has some handy getRelationship() methods that use the inverse
> cross reference adapter, and there are some extra methods to support
> profiles and stereotype application and keywords ... to name a few.
> It appears that you have come across one of these convienient methods. I'm
> not certain of its history but it may have been requested by someone in the
> past.
>
> To make you feel good about the accuracy of the API ...
> * The normative reference that the UML2 superstructure spec references is
> actually generated from the core .uml models maintained by this project.
> * In addition, many of the diagrams that you see in the spec itself are
> generated from the .emx files also maintained by this project. Bran Selic,
> the previous UML2 chair and editor of the superstructure spec used to
> maintain these diagrams with Kenn Hussey. ( The .emx for the UML 2.2 are
> out of date currently but will be updated soon. All previous versions are
> up to date).
> * Kenn was extremely meticulous when it came to accuracy with the API ...
> take my word for that one ;)
>
> Cheers,
> - James.
>
>
>
> "Rafael Chaves" <rafael@abstratt.com> wrote in message
> news:gdp8jt$ive$1@build.eclipse.org...
>> Hi,
>>
>> I was trying to understand the rationale for
>> BehavioredClassifier#implementedInterfaces, given that it does not seem to
>> appear on the UML spec. Up to now, I was assuming the UML2 API matched the
>> UML metamodel as colsely as possible.
>>
>> I don't have a problem with it, it looks convenient, just trying to
>> understand things.
>>
>> Cheers,
>>
>> Rafael
>
>
Re: BehavioredClassifier#implementedInterfaces [message #477872 is a reply to message #477871] Thu, 23 October 2008 16:28 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Raphael,

I'd say that's true for structural features, i.e., attributes and references
(since none have been added beyond the official ones), but not for
operations. It would probably be worthwhile to indicate which ones do not
come from the specification in some way in the Javadoc (by adding something
to the comment, e.g. "This operation is non-normative."). Feel free to open
an enhancement request and we'll look into it.

Kenn

"Rafael Chaves" <rafael@abstratt.com> wrote in message
news:gdq4rl$qs4$1@build.eclipse.org...
> Thanks James, Kenn.
>
> Is there a simple way of telling convenience and metamodel derived API
> apart?
>
> The heuristic I have been using is that since it seems the top-level
> javadoc enumerates all metamodel related supported features, and thus if a
> relationship navigation method exists and it does not appear as one of the
> supported features, it is a convenience method.
>
> Does that make sense?
>
> Cheers,
>
> Rafael
>
> James Bruck wrote:
>> Hi Rafael,
>>
>> In addition to following the UML spec. (as closely as possible), the UML2
>> API defines some convenience operations.
>> There are for example, convenient "create" methods sprinkled around;
>> uml:Element has some handy getRelationship() methods that use the inverse
>> cross reference adapter, and there are some extra methods to support
>> profiles and stereotype application and keywords ... to name a few.
>> It appears that you have come across one of these convienient methods.
>> I'm not certain of its history but it may have been requested by someone
>> in the past.
>>
>> To make you feel good about the accuracy of the API ...
>> * The normative reference that the UML2 superstructure spec references is
>> actually generated from the core .uml models maintained by this project.
>> * In addition, many of the diagrams that you see in the spec itself are
>> generated from the .emx files also maintained by this project. Bran
>> Selic, the previous UML2 chair and editor of the superstructure spec used
>> to maintain these diagrams with Kenn Hussey. ( The .emx for the UML 2.2
>> are out of date currently but will be updated soon. All previous
>> versions are up to date).
>> * Kenn was extremely meticulous when it came to accuracy with the API ...
>> take my word for that one ;)
>>
>> Cheers,
>> - James.
>>
>>
>>
>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>> news:gdp8jt$ive$1@build.eclipse.org...
>>> Hi,
>>>
>>> I was trying to understand the rationale for
>>> BehavioredClassifier#implementedInterfaces, given that it does not seem
>>> to appear on the UML spec. Up to now, I was assuming the UML2 API
>>> matched the UML metamodel as colsely as possible.
>>>
>>> I don't have a problem with it, it looks convenient, just trying to
>>> understand things.
>>>
>>> Cheers,
>>>
>>> Rafael
>>
Re: BehavioredClassifier#implementedInterfaces [message #477878 is a reply to message #477872] Fri, 24 October 2008 04:03 Go to previous messageGo to next message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
Yeah, something along those lines would be cool. Here is the issue:

https://bugs.eclipse.org/251963

Thanks,

Rafael

Kenn Hussey wrote:
> Raphael,
>
> I'd say that's true for structural features, i.e., attributes and references
> (since none have been added beyond the official ones), but not for
> operations. It would probably be worthwhile to indicate which ones do not
> come from the specification in some way in the Javadoc (by adding something
> to the comment, e.g. "This operation is non-normative."). Feel free to open
> an enhancement request and we'll look into it.
>
> Kenn
>
> "Rafael Chaves" <rafael@abstratt.com> wrote in message
> news:gdq4rl$qs4$1@build.eclipse.org...
>> Thanks James, Kenn.
>>
>> Is there a simple way of telling convenience and metamodel derived API
>> apart?
>>
>> The heuristic I have been using is that since it seems the top-level
>> javadoc enumerates all metamodel related supported features, and thus if a
>> relationship navigation method exists and it does not appear as one of the
>> supported features, it is a convenience method.
>>
>> Does that make sense?
>>
>> Cheers,
>>
>> Rafael
>>
>> James Bruck wrote:
>>> Hi Rafael,
>>>
>>> In addition to following the UML spec. (as closely as possible), the UML2
>>> API defines some convenience operations.
>>> There are for example, convenient "create" methods sprinkled around;
>>> uml:Element has some handy getRelationship() methods that use the inverse
>>> cross reference adapter, and there are some extra methods to support
>>> profiles and stereotype application and keywords ... to name a few.
>>> It appears that you have come across one of these convienient methods.
>>> I'm not certain of its history but it may have been requested by someone
>>> in the past.
>>>
>>> To make you feel good about the accuracy of the API ...
>>> * The normative reference that the UML2 superstructure spec references is
>>> actually generated from the core .uml models maintained by this project.
>>> * In addition, many of the diagrams that you see in the spec itself are
>>> generated from the .emx files also maintained by this project. Bran
>>> Selic, the previous UML2 chair and editor of the superstructure spec used
>>> to maintain these diagrams with Kenn Hussey. ( The .emx for the UML 2.2
>>> are out of date currently but will be updated soon. All previous
>>> versions are up to date).
>>> * Kenn was extremely meticulous when it came to accuracy with the API ...
>>> take my word for that one ;)
>>>
>>> Cheers,
>>> - James.
>>>
>>>
>>>
>>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>>> news:gdp8jt$ive$1@build.eclipse.org...
>>>> Hi,
>>>>
>>>> I was trying to understand the rationale for
>>>> BehavioredClassifier#implementedInterfaces, given that it does not seem
>>>> to appear on the UML spec. Up to now, I was assuming the UML2 API
>>>> matched the UML metamodel as colsely as possible.
>>>>
>>>> I don't have a problem with it, it looks convenient, just trying to
>>>> understand things.
>>>>
>>>> Cheers,
>>>>
>>>> Rafael
>
Re: BehavioredClassifier#implementedInterfaces [message #477886 is a reply to message #477878] Fri, 24 October 2008 15:32 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Thanks, Rafael! Sorry about mispelling your name (how awful is that?!). :(

Kenn

"Rafael Chaves" <rafael@abstratt.com> wrote in message
news:gdrhe7$svn$1@build.eclipse.org...
> Yeah, something along those lines would be cool. Here is the issue:
>
> https://bugs.eclipse.org/251963
>
> Thanks,
>
> Rafael
>
> Kenn Hussey wrote:
>> Raphael,
>>
>> I'd say that's true for structural features, i.e., attributes and
>> references (since none have been added beyond the official ones), but not
>> for operations. It would probably be worthwhile to indicate which ones do
>> not come from the specification in some way in the Javadoc (by adding
>> something to the comment, e.g. "This operation is non-normative."). Feel
>> free to open an enhancement request and we'll look into it.
>>
>> Kenn
>>
>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>> news:gdq4rl$qs4$1@build.eclipse.org...
>>> Thanks James, Kenn.
>>>
>>> Is there a simple way of telling convenience and metamodel derived API
>>> apart?
>>>
>>> The heuristic I have been using is that since it seems the top-level
>>> javadoc enumerates all metamodel related supported features, and thus if
>>> a relationship navigation method exists and it does not appear as one of
>>> the supported features, it is a convenience method.
>>>
>>> Does that make sense?
>>>
>>> Cheers,
>>>
>>> Rafael
>>>
>>> James Bruck wrote:
>>>> Hi Rafael,
>>>>
>>>> In addition to following the UML spec. (as closely as possible), the
>>>> UML2 API defines some convenience operations.
>>>> There are for example, convenient "create" methods sprinkled around;
>>>> uml:Element has some handy getRelationship() methods that use the
>>>> inverse cross reference adapter, and there are some extra methods to
>>>> support profiles and stereotype application and keywords ... to name a
>>>> few.
>>>> It appears that you have come across one of these convienient methods.
>>>> I'm not certain of its history but it may have been requested by
>>>> someone in the past.
>>>>
>>>> To make you feel good about the accuracy of the API ...
>>>> * The normative reference that the UML2 superstructure spec references
>>>> is actually generated from the core .uml models maintained by this
>>>> project.
>>>> * In addition, many of the diagrams that you see in the spec itself are
>>>> generated from the .emx files also maintained by this project. Bran
>>>> Selic, the previous UML2 chair and editor of the superstructure spec
>>>> used to maintain these diagrams with Kenn Hussey. ( The .emx for the
>>>> UML 2.2 are out of date currently but will be updated soon. All
>>>> previous versions are up to date).
>>>> * Kenn was extremely meticulous when it came to accuracy with the API
>>>> ... take my word for that one ;)
>>>>
>>>> Cheers,
>>>> - James.
>>>>
>>>>
>>>>
>>>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>>>> news:gdp8jt$ive$1@build.eclipse.org...
>>>>> Hi,
>>>>>
>>>>> I was trying to understand the rationale for
>>>>> BehavioredClassifier#implementedInterfaces, given that it does not
>>>>> seem to appear on the UML spec. Up to now, I was assuming the UML2 API
>>>>> matched the UML metamodel as colsely as possible.
>>>>>
>>>>> I don't have a problem with it, it looks convenient, just trying to
>>>>> understand things.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Rafael
>>
Re: BehavioredClassifier#implementedInterfaces [message #477888 is a reply to message #477886] Sat, 25 October 2008 01:51 Go to previous messageGo to next message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
No worries, it happens often, I am used to it. It is also common for
people to write 'Chavez' (Spanish) instead of 'Chaves'
(Portuguese/Brazilian).

Kenn Hussey wrote:
> Thanks, Rafael! Sorry about mispelling your name (how awful is that?!). :(
>
> Kenn
>
> "Rafael Chaves" <rafael@abstratt.com> wrote in message
> news:gdrhe7$svn$1@build.eclipse.org...
>> Yeah, something along those lines would be cool. Here is the issue:
>>
>> https://bugs.eclipse.org/251963
>>
>> Thanks,
>>
>> Rafael
>>
>> Kenn Hussey wrote:
>>> Raphael,
>>>
>>> I'd say that's true for structural features, i.e., attributes and
>>> references (since none have been added beyond the official ones), but not
>>> for operations. It would probably be worthwhile to indicate which ones do
>>> not come from the specification in some way in the Javadoc (by adding
>>> something to the comment, e.g. "This operation is non-normative."). Feel
>>> free to open an enhancement request and we'll look into it.
>>>
>>> Kenn
>>>
>>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>>> news:gdq4rl$qs4$1@build.eclipse.org...
>>>> Thanks James, Kenn.
>>>>
>>>> Is there a simple way of telling convenience and metamodel derived API
>>>> apart?
>>>>
>>>> The heuristic I have been using is that since it seems the top-level
>>>> javadoc enumerates all metamodel related supported features, and thus if
>>>> a relationship navigation method exists and it does not appear as one of
>>>> the supported features, it is a convenience method.
>>>>
>>>> Does that make sense?
>>>>
>>>> Cheers,
>>>>
>>>> Rafael
>>>>
>>>> James Bruck wrote:
>>>>> Hi Rafael,
>>>>>
>>>>> In addition to following the UML spec. (as closely as possible), the
>>>>> UML2 API defines some convenience operations.
>>>>> There are for example, convenient "create" methods sprinkled around;
>>>>> uml:Element has some handy getRelationship() methods that use the
>>>>> inverse cross reference adapter, and there are some extra methods to
>>>>> support profiles and stereotype application and keywords ... to name a
>>>>> few.
>>>>> It appears that you have come across one of these convienient methods.
>>>>> I'm not certain of its history but it may have been requested by
>>>>> someone in the past.
>>>>>
>>>>> To make you feel good about the accuracy of the API ...
>>>>> * The normative reference that the UML2 superstructure spec references
>>>>> is actually generated from the core .uml models maintained by this
>>>>> project.
>>>>> * In addition, many of the diagrams that you see in the spec itself are
>>>>> generated from the .emx files also maintained by this project. Bran
>>>>> Selic, the previous UML2 chair and editor of the superstructure spec
>>>>> used to maintain these diagrams with Kenn Hussey. ( The .emx for the
>>>>> UML 2.2 are out of date currently but will be updated soon. All
>>>>> previous versions are up to date).
>>>>> * Kenn was extremely meticulous when it came to accuracy with the API
>>>>> ... take my word for that one ;)
>>>>>
>>>>> Cheers,
>>>>> - James.
>>>>>
>>>>>
>>>>>
>>>>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>>>>> news:gdp8jt$ive$1@build.eclipse.org...
>>>>>> Hi,
>>>>>>
>>>>>> I was trying to understand the rationale for
>>>>>> BehavioredClassifier#implementedInterfaces, given that it does not
>>>>>> seem to appear on the UML spec. Up to now, I was assuming the UML2 API
>>>>>> matched the UML metamodel as colsely as possible.
>>>>>>
>>>>>> I don't have a problem with it, it looks convenient, just trying to
>>>>>> understand things.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Rafael
>
>
Re: BehavioredClassifier#implementedInterfaces [message #477889 is a reply to message #477866] Sat, 25 October 2008 18:04 Go to previous messageGo to next message
Nicolas Rouquette is currently offline Nicolas RouquetteFriend
Messages: 157
Registered: July 2009
Senior Member
Kenn,

If the convenience methods are defined explicitly in a separate merge
increment (i.e., org.eclipse.uml2.uml/model/UML.uml), then it seems to
me that package merge traceability could solve Rafael's problem nicely.
Perhaps the missing link might be converting the package merge
traceability metadata into equivalent Java annotations.

-- Nicolas.

Kenn Hussey wrote:
> Rafael,
>
> The UML2 API does not match the specification one to one; in some cases (as
> in this case), additions have been made for convenience. These additions are
> defined in a separate source model, org.eclipse.uml2.uml/model/UML.uml
> (which is merged with the "official" source models to produce the final
> API).
>
> Kenn
>
> "Rafael Chaves" <rafael@abstratt.com> wrote in message
> news:gdp8jt$ive$1@build.eclipse.org...
>> Hi,
>>
>> I was trying to understand the rationale for
>> BehavioredClassifier#implementedInterfaces, given that it does not seem to
>> appear on the UML spec. Up to now, I was assuming the UML2 API matched the
>> UML metamodel as colsely as possible.
>>
>> I don't have a problem with it, it looks convenient, just trying to
>> understand things.
>>
>> Cheers,
>>
>> Rafael
>
>
Re: BehavioredClassifier#implementedInterfaces [message #477892 is a reply to message #477889] Mon, 27 October 2008 13:33 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Nicolas,

Yes, I agree, although I'm not sure it makes sense for the merged version of
the model to retain references to the merged model. There is a
'capabilities' option in the package merge utility which creates annotations
on model elements based on where they came (were merged) from. We
could/should probably use this mechanism to introduce Javadoc for all model
elements (classes, properties, and operations) to describe their
origin(s)...

Kenn

"Nicolas Rouquette" <nicolas.rouquette@jpl.nasa.gov> wrote in message
news:49035FBD.5010305@jpl.nasa.gov...
> Kenn,
>
> If the convenience methods are defined explicitly in a separate merge
> increment (i.e., org.eclipse.uml2.uml/model/UML.uml), then it seems to me
> that package merge traceability could solve Rafael's problem nicely.
> Perhaps the missing link might be converting the package merge
> traceability metadata into equivalent Java annotations.
>
> -- Nicolas.
>
> Kenn Hussey wrote:
>> Rafael,
>>
>> The UML2 API does not match the specification one to one; in some cases
>> (as in this case), additions have been made for convenience. These
>> additions are defined in a separate source model,
>> org.eclipse.uml2.uml/model/UML.uml (which is merged with the "official"
>> source models to produce the final API).
>>
>> Kenn
>>
>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>> news:gdp8jt$ive$1@build.eclipse.org...
>>> Hi,
>>>
>>> I was trying to understand the rationale for
>>> BehavioredClassifier#implementedInterfaces, given that it does not seem
>>> to appear on the UML spec. Up to now, I was assuming the UML2 API
>>> matched the UML metamodel as colsely as possible.
>>>
>>> I don't have a problem with it, it looks convenient, just trying to
>>> understand things.
>>>
>>> Cheers,
>>>
>>> Rafael
>>
Re: BehavioredClassifier#implementedInterfaces [message #477893 is a reply to message #477892] Mon, 27 October 2008 14:52 Go to previous message
Nicolas Rouquette is currently offline Nicolas RouquetteFriend
Messages: 157
Registered: July 2009
Senior Member
Kenn,

Yes, retaining references can be problematic except when they are
useful. Currently, we have to make this choice prior to performing the
merge operation whereas the need for traceability relationships occurs
later, if at all.

We could decouple the two things. For example, we could add to the
PackageMerge implementation an option to save the traceability
information in a separate merge traceability resource that would own
artifact instances with traceability links relating each imported
resulting merge element to its contributing merged elements.

This strategy would avoid retaining references to the merged model in
the resulting model but would allow the code generator to retrieve the
traceability information to generate analyzable Java annotations.

-- Nicolas.


Kenn Hussey wrote:
> Nicolas,
>
> Yes, I agree, although I'm not sure it makes sense for the merged version of
> the model to retain references to the merged model. There is a
> 'capabilities' option in the package merge utility which creates annotations
> on model elements based on where they came (were merged) from. We
> could/should probably use this mechanism to introduce Javadoc for all model
> elements (classes, properties, and operations) to describe their
> origin(s)...
>
> Kenn
>
> "Nicolas Rouquette" <nicolas.rouquette@jpl.nasa.gov> wrote in message
> news:49035FBD.5010305@jpl.nasa.gov...
>> Kenn,
>>
>> If the convenience methods are defined explicitly in a separate merge
>> increment (i.e., org.eclipse.uml2.uml/model/UML.uml), then it seems to me
>> that package merge traceability could solve Rafael's problem nicely.
>> Perhaps the missing link might be converting the package merge
>> traceability metadata into equivalent Java annotations.
>>
>> -- Nicolas.
>>
>> Kenn Hussey wrote:
>>> Rafael,
>>>
>>> The UML2 API does not match the specification one to one; in some cases
>>> (as in this case), additions have been made for convenience. These
>>> additions are defined in a separate source model,
>>> org.eclipse.uml2.uml/model/UML.uml (which is merged with the "official"
>>> source models to produce the final API).
>>>
>>> Kenn
>>>
>>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>>> news:gdp8jt$ive$1@build.eclipse.org...
>>>> Hi,
>>>>
>>>> I was trying to understand the rationale for
>>>> BehavioredClassifier#implementedInterfaces, given that it does not seem
>>>> to appear on the UML spec. Up to now, I was assuming the UML2 API
>>>> matched the UML metamodel as colsely as possible.
>>>>
>>>> I don't have a problem with it, it looks convenient, just trying to
>>>> understand things.
>>>>
>>>> Cheers,
>>>>
>>>> Rafael
>
Re: BehavioredClassifier#implementedInterfaces [message #627068 is a reply to message #477863] Thu, 23 October 2008 15:05 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Rafael,

In addition to following the UML spec. (as closely as possible), the UML2
API defines some convenience operations.
There are for example, convenient "create" methods sprinkled around;
uml:Element has some handy getRelationship() methods that use the inverse
cross reference adapter, and there are some extra methods to support
profiles and stereotype application and keywords ... to name a few.
It appears that you have come across one of these convienient methods. I'm
not certain of its history but it may have been requested by someone in the
past.

To make you feel good about the accuracy of the API ...
* The normative reference that the UML2 superstructure spec references is
actually generated from the core .uml models maintained by this project.
* In addition, many of the diagrams that you see in the spec itself are
generated from the .emx files also maintained by this project. Bran Selic,
the previous UML2 chair and editor of the superstructure spec used to
maintain these diagrams with Kenn Hussey. ( The .emx for the UML 2.2 are
out of date currently but will be updated soon. All previous versions are
up to date).
* Kenn was extremely meticulous when it came to accuracy with the API ...
take my word for that one ;)

Cheers,
- James.



"Rafael Chaves" <rafael@abstratt.com> wrote in message
news:gdp8jt$ive$1@build.eclipse.org...
> Hi,
>
> I was trying to understand the rationale for
> BehavioredClassifier#implementedInterfaces, given that it does not seem to
> appear on the UML spec. Up to now, I was assuming the UML2 API matched the
> UML metamodel as colsely as possible.
>
> I don't have a problem with it, it looks convenient, just trying to
> understand things.
>
> Cheers,
>
> Rafael
Re: BehavioredClassifier#implementedInterfaces [message #627069 is a reply to message #477863] Thu, 23 October 2008 15:05 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Rafael,

The UML2 API does not match the specification one to one; in some cases (as
in this case), additions have been made for convenience. These additions are
defined in a separate source model, org.eclipse.uml2.uml/model/UML.uml
(which is merged with the "official" source models to produce the final
API).

Kenn

"Rafael Chaves" <rafael@abstratt.com> wrote in message
news:gdp8jt$ive$1@build.eclipse.org...
> Hi,
>
> I was trying to understand the rationale for
> BehavioredClassifier#implementedInterfaces, given that it does not seem to
> appear on the UML spec. Up to now, I was assuming the UML2 API matched the
> UML metamodel as colsely as possible.
>
> I don't have a problem with it, it looks convenient, just trying to
> understand things.
>
> Cheers,
>
> Rafael
Re: BehavioredClassifier#implementedInterfaces [message #627071 is a reply to message #477865] Thu, 23 October 2008 15:22 Go to previous message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
Thanks James, Kenn.

Is there a simple way of telling convenience and metamodel derived API
apart?

The heuristic I have been using is that since it seems the top-level
javadoc enumerates all metamodel related supported features, and thus if
a relationship navigation method exists and it does not appear as one of
the supported features, it is a convenience method.

Does that make sense?

Cheers,

Rafael

James Bruck wrote:
> Hi Rafael,
>
> In addition to following the UML spec. (as closely as possible), the UML2
> API defines some convenience operations.
> There are for example, convenient "create" methods sprinkled around;
> uml:Element has some handy getRelationship() methods that use the inverse
> cross reference adapter, and there are some extra methods to support
> profiles and stereotype application and keywords ... to name a few.
> It appears that you have come across one of these convienient methods. I'm
> not certain of its history but it may have been requested by someone in the
> past.
>
> To make you feel good about the accuracy of the API ...
> * The normative reference that the UML2 superstructure spec references is
> actually generated from the core .uml models maintained by this project.
> * In addition, many of the diagrams that you see in the spec itself are
> generated from the .emx files also maintained by this project. Bran Selic,
> the previous UML2 chair and editor of the superstructure spec used to
> maintain these diagrams with Kenn Hussey. ( The .emx for the UML 2.2 are
> out of date currently but will be updated soon. All previous versions are
> up to date).
> * Kenn was extremely meticulous when it came to accuracy with the API ...
> take my word for that one ;)
>
> Cheers,
> - James.
>
>
>
> "Rafael Chaves" <rafael@abstratt.com> wrote in message
> news:gdp8jt$ive$1@build.eclipse.org...
>> Hi,
>>
>> I was trying to understand the rationale for
>> BehavioredClassifier#implementedInterfaces, given that it does not seem to
>> appear on the UML spec. Up to now, I was assuming the UML2 API matched the
>> UML metamodel as colsely as possible.
>>
>> I don't have a problem with it, it looks convenient, just trying to
>> understand things.
>>
>> Cheers,
>>
>> Rafael
>
>
Re: BehavioredClassifier#implementedInterfaces [message #627072 is a reply to message #477871] Thu, 23 October 2008 16:28 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Raphael,

I'd say that's true for structural features, i.e., attributes and references
(since none have been added beyond the official ones), but not for
operations. It would probably be worthwhile to indicate which ones do not
come from the specification in some way in the Javadoc (by adding something
to the comment, e.g. "This operation is non-normative."). Feel free to open
an enhancement request and we'll look into it.

Kenn

"Rafael Chaves" <rafael@abstratt.com> wrote in message
news:gdq4rl$qs4$1@build.eclipse.org...
> Thanks James, Kenn.
>
> Is there a simple way of telling convenience and metamodel derived API
> apart?
>
> The heuristic I have been using is that since it seems the top-level
> javadoc enumerates all metamodel related supported features, and thus if a
> relationship navigation method exists and it does not appear as one of the
> supported features, it is a convenience method.
>
> Does that make sense?
>
> Cheers,
>
> Rafael
>
> James Bruck wrote:
>> Hi Rafael,
>>
>> In addition to following the UML spec. (as closely as possible), the UML2
>> API defines some convenience operations.
>> There are for example, convenient "create" methods sprinkled around;
>> uml:Element has some handy getRelationship() methods that use the inverse
>> cross reference adapter, and there are some extra methods to support
>> profiles and stereotype application and keywords ... to name a few.
>> It appears that you have come across one of these convienient methods.
>> I'm not certain of its history but it may have been requested by someone
>> in the past.
>>
>> To make you feel good about the accuracy of the API ...
>> * The normative reference that the UML2 superstructure spec references is
>> actually generated from the core .uml models maintained by this project.
>> * In addition, many of the diagrams that you see in the spec itself are
>> generated from the .emx files also maintained by this project. Bran
>> Selic, the previous UML2 chair and editor of the superstructure spec used
>> to maintain these diagrams with Kenn Hussey. ( The .emx for the UML 2.2
>> are out of date currently but will be updated soon. All previous
>> versions are up to date).
>> * Kenn was extremely meticulous when it came to accuracy with the API ...
>> take my word for that one ;)
>>
>> Cheers,
>> - James.
>>
>>
>>
>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>> news:gdp8jt$ive$1@build.eclipse.org...
>>> Hi,
>>>
>>> I was trying to understand the rationale for
>>> BehavioredClassifier#implementedInterfaces, given that it does not seem
>>> to appear on the UML spec. Up to now, I was assuming the UML2 API
>>> matched the UML metamodel as colsely as possible.
>>>
>>> I don't have a problem with it, it looks convenient, just trying to
>>> understand things.
>>>
>>> Cheers,
>>>
>>> Rafael
>>
Re: BehavioredClassifier#implementedInterfaces [message #627078 is a reply to message #477872] Fri, 24 October 2008 04:03 Go to previous message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
Yeah, something along those lines would be cool. Here is the issue:

https://bugs.eclipse.org/251963

Thanks,

Rafael

Kenn Hussey wrote:
> Raphael,
>
> I'd say that's true for structural features, i.e., attributes and references
> (since none have been added beyond the official ones), but not for
> operations. It would probably be worthwhile to indicate which ones do not
> come from the specification in some way in the Javadoc (by adding something
> to the comment, e.g. "This operation is non-normative."). Feel free to open
> an enhancement request and we'll look into it.
>
> Kenn
>
> "Rafael Chaves" <rafael@abstratt.com> wrote in message
> news:gdq4rl$qs4$1@build.eclipse.org...
>> Thanks James, Kenn.
>>
>> Is there a simple way of telling convenience and metamodel derived API
>> apart?
>>
>> The heuristic I have been using is that since it seems the top-level
>> javadoc enumerates all metamodel related supported features, and thus if a
>> relationship navigation method exists and it does not appear as one of the
>> supported features, it is a convenience method.
>>
>> Does that make sense?
>>
>> Cheers,
>>
>> Rafael
>>
>> James Bruck wrote:
>>> Hi Rafael,
>>>
>>> In addition to following the UML spec. (as closely as possible), the UML2
>>> API defines some convenience operations.
>>> There are for example, convenient "create" methods sprinkled around;
>>> uml:Element has some handy getRelationship() methods that use the inverse
>>> cross reference adapter, and there are some extra methods to support
>>> profiles and stereotype application and keywords ... to name a few.
>>> It appears that you have come across one of these convienient methods.
>>> I'm not certain of its history but it may have been requested by someone
>>> in the past.
>>>
>>> To make you feel good about the accuracy of the API ...
>>> * The normative reference that the UML2 superstructure spec references is
>>> actually generated from the core .uml models maintained by this project.
>>> * In addition, many of the diagrams that you see in the spec itself are
>>> generated from the .emx files also maintained by this project. Bran
>>> Selic, the previous UML2 chair and editor of the superstructure spec used
>>> to maintain these diagrams with Kenn Hussey. ( The .emx for the UML 2.2
>>> are out of date currently but will be updated soon. All previous
>>> versions are up to date).
>>> * Kenn was extremely meticulous when it came to accuracy with the API ...
>>> take my word for that one ;)
>>>
>>> Cheers,
>>> - James.
>>>
>>>
>>>
>>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>>> news:gdp8jt$ive$1@build.eclipse.org...
>>>> Hi,
>>>>
>>>> I was trying to understand the rationale for
>>>> BehavioredClassifier#implementedInterfaces, given that it does not seem
>>>> to appear on the UML spec. Up to now, I was assuming the UML2 API
>>>> matched the UML metamodel as colsely as possible.
>>>>
>>>> I don't have a problem with it, it looks convenient, just trying to
>>>> understand things.
>>>>
>>>> Cheers,
>>>>
>>>> Rafael
>
Re: BehavioredClassifier#implementedInterfaces [message #627096 is a reply to message #477878] Fri, 24 October 2008 15:32 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Thanks, Rafael! Sorry about mispelling your name (how awful is that?!). :(

Kenn

"Rafael Chaves" <rafael@abstratt.com> wrote in message
news:gdrhe7$svn$1@build.eclipse.org...
> Yeah, something along those lines would be cool. Here is the issue:
>
> https://bugs.eclipse.org/251963
>
> Thanks,
>
> Rafael
>
> Kenn Hussey wrote:
>> Raphael,
>>
>> I'd say that's true for structural features, i.e., attributes and
>> references (since none have been added beyond the official ones), but not
>> for operations. It would probably be worthwhile to indicate which ones do
>> not come from the specification in some way in the Javadoc (by adding
>> something to the comment, e.g. "This operation is non-normative."). Feel
>> free to open an enhancement request and we'll look into it.
>>
>> Kenn
>>
>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>> news:gdq4rl$qs4$1@build.eclipse.org...
>>> Thanks James, Kenn.
>>>
>>> Is there a simple way of telling convenience and metamodel derived API
>>> apart?
>>>
>>> The heuristic I have been using is that since it seems the top-level
>>> javadoc enumerates all metamodel related supported features, and thus if
>>> a relationship navigation method exists and it does not appear as one of
>>> the supported features, it is a convenience method.
>>>
>>> Does that make sense?
>>>
>>> Cheers,
>>>
>>> Rafael
>>>
>>> James Bruck wrote:
>>>> Hi Rafael,
>>>>
>>>> In addition to following the UML spec. (as closely as possible), the
>>>> UML2 API defines some convenience operations.
>>>> There are for example, convenient "create" methods sprinkled around;
>>>> uml:Element has some handy getRelationship() methods that use the
>>>> inverse cross reference adapter, and there are some extra methods to
>>>> support profiles and stereotype application and keywords ... to name a
>>>> few.
>>>> It appears that you have come across one of these convienient methods.
>>>> I'm not certain of its history but it may have been requested by
>>>> someone in the past.
>>>>
>>>> To make you feel good about the accuracy of the API ...
>>>> * The normative reference that the UML2 superstructure spec references
>>>> is actually generated from the core .uml models maintained by this
>>>> project.
>>>> * In addition, many of the diagrams that you see in the spec itself are
>>>> generated from the .emx files also maintained by this project. Bran
>>>> Selic, the previous UML2 chair and editor of the superstructure spec
>>>> used to maintain these diagrams with Kenn Hussey. ( The .emx for the
>>>> UML 2.2 are out of date currently but will be updated soon. All
>>>> previous versions are up to date).
>>>> * Kenn was extremely meticulous when it came to accuracy with the API
>>>> ... take my word for that one ;)
>>>>
>>>> Cheers,
>>>> - James.
>>>>
>>>>
>>>>
>>>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>>>> news:gdp8jt$ive$1@build.eclipse.org...
>>>>> Hi,
>>>>>
>>>>> I was trying to understand the rationale for
>>>>> BehavioredClassifier#implementedInterfaces, given that it does not
>>>>> seem to appear on the UML spec. Up to now, I was assuming the UML2 API
>>>>> matched the UML metamodel as colsely as possible.
>>>>>
>>>>> I don't have a problem with it, it looks convenient, just trying to
>>>>> understand things.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Rafael
>>
Re: BehavioredClassifier#implementedInterfaces [message #627098 is a reply to message #477886] Sat, 25 October 2008 01:51 Go to previous message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
No worries, it happens often, I am used to it. It is also common for
people to write 'Chavez' (Spanish) instead of 'Chaves'
(Portuguese/Brazilian).

Kenn Hussey wrote:
> Thanks, Rafael! Sorry about mispelling your name (how awful is that?!). :(
>
> Kenn
>
> "Rafael Chaves" <rafael@abstratt.com> wrote in message
> news:gdrhe7$svn$1@build.eclipse.org...
>> Yeah, something along those lines would be cool. Here is the issue:
>>
>> https://bugs.eclipse.org/251963
>>
>> Thanks,
>>
>> Rafael
>>
>> Kenn Hussey wrote:
>>> Raphael,
>>>
>>> I'd say that's true for structural features, i.e., attributes and
>>> references (since none have been added beyond the official ones), but not
>>> for operations. It would probably be worthwhile to indicate which ones do
>>> not come from the specification in some way in the Javadoc (by adding
>>> something to the comment, e.g. "This operation is non-normative."). Feel
>>> free to open an enhancement request and we'll look into it.
>>>
>>> Kenn
>>>
>>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>>> news:gdq4rl$qs4$1@build.eclipse.org...
>>>> Thanks James, Kenn.
>>>>
>>>> Is there a simple way of telling convenience and metamodel derived API
>>>> apart?
>>>>
>>>> The heuristic I have been using is that since it seems the top-level
>>>> javadoc enumerates all metamodel related supported features, and thus if
>>>> a relationship navigation method exists and it does not appear as one of
>>>> the supported features, it is a convenience method.
>>>>
>>>> Does that make sense?
>>>>
>>>> Cheers,
>>>>
>>>> Rafael
>>>>
>>>> James Bruck wrote:
>>>>> Hi Rafael,
>>>>>
>>>>> In addition to following the UML spec. (as closely as possible), the
>>>>> UML2 API defines some convenience operations.
>>>>> There are for example, convenient "create" methods sprinkled around;
>>>>> uml:Element has some handy getRelationship() methods that use the
>>>>> inverse cross reference adapter, and there are some extra methods to
>>>>> support profiles and stereotype application and keywords ... to name a
>>>>> few.
>>>>> It appears that you have come across one of these convienient methods.
>>>>> I'm not certain of its history but it may have been requested by
>>>>> someone in the past.
>>>>>
>>>>> To make you feel good about the accuracy of the API ...
>>>>> * The normative reference that the UML2 superstructure spec references
>>>>> is actually generated from the core .uml models maintained by this
>>>>> project.
>>>>> * In addition, many of the diagrams that you see in the spec itself are
>>>>> generated from the .emx files also maintained by this project. Bran
>>>>> Selic, the previous UML2 chair and editor of the superstructure spec
>>>>> used to maintain these diagrams with Kenn Hussey. ( The .emx for the
>>>>> UML 2.2 are out of date currently but will be updated soon. All
>>>>> previous versions are up to date).
>>>>> * Kenn was extremely meticulous when it came to accuracy with the API
>>>>> ... take my word for that one ;)
>>>>>
>>>>> Cheers,
>>>>> - James.
>>>>>
>>>>>
>>>>>
>>>>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>>>>> news:gdp8jt$ive$1@build.eclipse.org...
>>>>>> Hi,
>>>>>>
>>>>>> I was trying to understand the rationale for
>>>>>> BehavioredClassifier#implementedInterfaces, given that it does not
>>>>>> seem to appear on the UML spec. Up to now, I was assuming the UML2 API
>>>>>> matched the UML metamodel as colsely as possible.
>>>>>>
>>>>>> I don't have a problem with it, it looks convenient, just trying to
>>>>>> understand things.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Rafael
>
>
Re: BehavioredClassifier#implementedInterfaces [message #627099 is a reply to message #477866] Sat, 25 October 2008 18:04 Go to previous message
Nicolas Rouquette is currently offline Nicolas RouquetteFriend
Messages: 157
Registered: July 2009
Senior Member
Kenn,

If the convenience methods are defined explicitly in a separate merge
increment (i.e., org.eclipse.uml2.uml/model/UML.uml), then it seems to
me that package merge traceability could solve Rafael's problem nicely.
Perhaps the missing link might be converting the package merge
traceability metadata into equivalent Java annotations.

-- Nicolas.

Kenn Hussey wrote:
> Rafael,
>
> The UML2 API does not match the specification one to one; in some cases (as
> in this case), additions have been made for convenience. These additions are
> defined in a separate source model, org.eclipse.uml2.uml/model/UML.uml
> (which is merged with the "official" source models to produce the final
> API).
>
> Kenn
>
> "Rafael Chaves" <rafael@abstratt.com> wrote in message
> news:gdp8jt$ive$1@build.eclipse.org...
>> Hi,
>>
>> I was trying to understand the rationale for
>> BehavioredClassifier#implementedInterfaces, given that it does not seem to
>> appear on the UML spec. Up to now, I was assuming the UML2 API matched the
>> UML metamodel as colsely as possible.
>>
>> I don't have a problem with it, it looks convenient, just trying to
>> understand things.
>>
>> Cheers,
>>
>> Rafael
>
>
Re: BehavioredClassifier#implementedInterfaces [message #627101 is a reply to message #477889] Mon, 27 October 2008 13:33 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Nicolas,

Yes, I agree, although I'm not sure it makes sense for the merged version of
the model to retain references to the merged model. There is a
'capabilities' option in the package merge utility which creates annotations
on model elements based on where they came (were merged) from. We
could/should probably use this mechanism to introduce Javadoc for all model
elements (classes, properties, and operations) to describe their
origin(s)...

Kenn

"Nicolas Rouquette" <nicolas.rouquette@jpl.nasa.gov> wrote in message
news:49035FBD.5010305@jpl.nasa.gov...
> Kenn,
>
> If the convenience methods are defined explicitly in a separate merge
> increment (i.e., org.eclipse.uml2.uml/model/UML.uml), then it seems to me
> that package merge traceability could solve Rafael's problem nicely.
> Perhaps the missing link might be converting the package merge
> traceability metadata into equivalent Java annotations.
>
> -- Nicolas.
>
> Kenn Hussey wrote:
>> Rafael,
>>
>> The UML2 API does not match the specification one to one; in some cases
>> (as in this case), additions have been made for convenience. These
>> additions are defined in a separate source model,
>> org.eclipse.uml2.uml/model/UML.uml (which is merged with the "official"
>> source models to produce the final API).
>>
>> Kenn
>>
>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>> news:gdp8jt$ive$1@build.eclipse.org...
>>> Hi,
>>>
>>> I was trying to understand the rationale for
>>> BehavioredClassifier#implementedInterfaces, given that it does not seem
>>> to appear on the UML spec. Up to now, I was assuming the UML2 API
>>> matched the UML metamodel as colsely as possible.
>>>
>>> I don't have a problem with it, it looks convenient, just trying to
>>> understand things.
>>>
>>> Cheers,
>>>
>>> Rafael
>>
Re: BehavioredClassifier#implementedInterfaces [message #627102 is a reply to message #477892] Mon, 27 October 2008 14:52 Go to previous message
Nicolas Rouquette is currently offline Nicolas RouquetteFriend
Messages: 157
Registered: July 2009
Senior Member
Kenn,

Yes, retaining references can be problematic except when they are
useful. Currently, we have to make this choice prior to performing the
merge operation whereas the need for traceability relationships occurs
later, if at all.

We could decouple the two things. For example, we could add to the
PackageMerge implementation an option to save the traceability
information in a separate merge traceability resource that would own
artifact instances with traceability links relating each imported
resulting merge element to its contributing merged elements.

This strategy would avoid retaining references to the merged model in
the resulting model but would allow the code generator to retrieve the
traceability information to generate analyzable Java annotations.

-- Nicolas.


Kenn Hussey wrote:
> Nicolas,
>
> Yes, I agree, although I'm not sure it makes sense for the merged version of
> the model to retain references to the merged model. There is a
> 'capabilities' option in the package merge utility which creates annotations
> on model elements based on where they came (were merged) from. We
> could/should probably use this mechanism to introduce Javadoc for all model
> elements (classes, properties, and operations) to describe their
> origin(s)...
>
> Kenn
>
> "Nicolas Rouquette" <nicolas.rouquette@jpl.nasa.gov> wrote in message
> news:49035FBD.5010305@jpl.nasa.gov...
>> Kenn,
>>
>> If the convenience methods are defined explicitly in a separate merge
>> increment (i.e., org.eclipse.uml2.uml/model/UML.uml), then it seems to me
>> that package merge traceability could solve Rafael's problem nicely.
>> Perhaps the missing link might be converting the package merge
>> traceability metadata into equivalent Java annotations.
>>
>> -- Nicolas.
>>
>> Kenn Hussey wrote:
>>> Rafael,
>>>
>>> The UML2 API does not match the specification one to one; in some cases
>>> (as in this case), additions have been made for convenience. These
>>> additions are defined in a separate source model,
>>> org.eclipse.uml2.uml/model/UML.uml (which is merged with the "official"
>>> source models to produce the final API).
>>>
>>> Kenn
>>>
>>> "Rafael Chaves" <rafael@abstratt.com> wrote in message
>>> news:gdp8jt$ive$1@build.eclipse.org...
>>>> Hi,
>>>>
>>>> I was trying to understand the rationale for
>>>> BehavioredClassifier#implementedInterfaces, given that it does not seem
>>>> to appear on the UML spec. Up to now, I was assuming the UML2 API
>>>> matched the UML metamodel as colsely as possible.
>>>>
>>>> I don't have a problem with it, it looks convenient, just trying to
>>>> understand things.
>>>>
>>>> Cheers,
>>>>
>>>> Rafael
>
Previous Topic:Missing property in UML::Class::Kernel::PackageableElement
Next Topic:Can UML2 profiles/models/instances be manipulated via reflective EMF?
Goto Forum:
  


Current Time: Thu Mar 28 17:50:39 GMT 2024

Powered by FUDForum. Page generated in 0.03543 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top