|
| Re: Opaque specification of an operation's behaviour [message #477049 is a reply to message #477046] |
Mon, 10 March 2008 21:40   |
 Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
Felix,
Redundancy related to behavioral specifications (operations) and their
behaviors (methods) is actually the subject of recent debate within the UML
community (i.e. the UML 2.2 RTF). I believe this duplication exists to
foster decoupling of a behavior's implementation from its declaration; note
that the signatures could ini fact be different (although the method must
conform to the specification), e.g., the parameter names (but not their
types!) could be different...
Kenn
"Felix Dorner" <felix_do@web.de> wrote in message
news:fr3to5$e6c$1@build.eclipse.org...
> Hey,
>
> I am designing a small Action Language that can be used to specify the
> behaviour of the operations in a class model. I am looking for good ways
> to link the textual specification of an operation to the operation in the
> model.
>
> After some reading, I think the preferred way to do this, is to create an
> OpaqueBehaviour for every operation I'd like to specify in my language.
>
> One thing is however disturbing: Every Parameter of the Operation must be
> created twice. One owned by the Operation, and the other owned by the
> OpaqueBehaviour.
>
> I don't see the point in that. Could't this association be "derived", or
> even completely ommited from the metamodel, or are there any reasons why
> there is the need for this data to be specified with such a redundancy?
>
> Felix
>
>
>
|
|
|
|
|
|
| Re: Opaque specification of an operation's behaviour [message #626169 is a reply to message #477046] |
Mon, 10 March 2008 21:40 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
Felix,
Redundancy related to behavioral specifications (operations) and their
behaviors (methods) is actually the subject of recent debate within the UML
community (i.e. the UML 2.2 RTF). I believe this duplication exists to
foster decoupling of a behavior's implementation from its declaration; note
that the signatures could ini fact be different (although the method must
conform to the specification), e.g., the parameter names (but not their
types!) could be different...
Kenn
"Felix Dorner" <felix_do@web.de> wrote in message
news:fr3to5$e6c$1@build.eclipse.org...
> Hey,
>
> I am designing a small Action Language that can be used to specify the
> behaviour of the operations in a class model. I am looking for good ways
> to link the textual specification of an operation to the operation in the
> model.
>
> After some reading, I think the preferred way to do this, is to create an
> OpaqueBehaviour for every operation I'd like to specify in my language.
>
> One thing is however disturbing: Every Parameter of the Operation must be
> created twice. One owned by the Operation, and the other owned by the
> OpaqueBehaviour.
>
> I don't see the point in that. Could't this association be "derived", or
> even completely ommited from the metamodel, or are there any reasons why
> there is the need for this data to be specified with such a redundancy?
>
> Felix
>
>
>
|
|
|
|
| Re: Opaque specification of an operation's behaviour [message #626173 is a reply to message #477050] |
Mon, 10 March 2008 23:14 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000605050605010501080507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Felix,
Isn't Kenn wonderful?! What would we do without him? I suppose one
place to look for the UML community's opinion on this would be at
EclispeCon:
Eclipse/OMG Symposium <http://www.eclipsecon.org/2008/?page=sub/&id=533>
If I were politically incorrect, I'd suggest looking into the horizon
for the ivory-colored tower. But of course I'm way more politically
correct than that! All joking aside, I think the experience of folks
like you in the community can have a big impact...
Felix Dorner wrote:
> Kenn Hussey wrote:
>> Felix,
>>
>> Redundancy related to behavioral specifications (operations) and
>> their behaviors (methods) is actually the subject of recent debate
>> within the UML community (i.e. the UML 2.2 RTF). I believe this
>> duplication exists to foster decoupling of a behavior's
>> implementation from its declaration; note that the signatures could
>> ini fact be different (although the method must conform to the
>> specification), e.g., the parameter names (but not their types!)
>> could be different...
>
> Thanks Kenn! It
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.03900 seconds
] 
Search
Help
Register
Login
Home
