Eclipse Community Forums: Papyrus » State entry/exit/do behavior : reusing existing behavior

Home » Modeling » Papyrus » State entry/exit/do behavior : reusing existing behavior (How can I select an existing activity for entry behavior)

Show: Today's Messages :: Show Polls :: Message Navigator

State entry/exit/do behavior : reusing existing behavior [message #1008214]

Mon, 11 February 2013 09:15

Yannick S.
Messages: 15
Registered: February 2013

Junior Member

Hello,

using Papyrus 0.9.1a or 0.8.2 (TOPCASED) for SysML modeling, it seems I can only create (for example) a new activity to specify an entry behavior.

I would like to reuse the same activity several times, for several states, possibly with a parameter, but this does not seem to be possible.

So, is there some workaround, or is what I want to do not SysML compliant ?

Thank you for your help.

Report message to a moderator

Re: State entry/exit/do behavior : reusing existing behavior [message #1008247 is a reply to message #1008214]

Mon, 11 February 2013 13:02

Raphael Faudou
Messages: 77
Registered: July 2009

Member

the UML specification precises that OnEntry, DoActivity and onExit state features own their behavior.
So as soon as you associate an activity to one of those features, the activity belongs to the feature. Papyrus moves the activity below the feature which is normal behavior.

If you want to reuse an activity (let us say "A1"), just create some new Activity (let us say "A2" with one CallBehaviorAction that will call "A1". In that case, A1 is not moved below your state and you can reuse it in other states.

Hope it helps
regards
raphaël

Report message to a moderator

Re: State entry/exit/do behavior : reusing existing behavior [message #1008616 is a reply to message #1008247]

Wed, 13 February 2013 05:16

Yannick S.
Messages: 15
Registered: February 2013

Junior Member

Hello, Raphaël,
this is clear, thanks for the fast answer.
Well, I'm just a beginner with SysML (and UML ...) and don't know the specifications in detail.
However, from a systems engineer's point of view, I feel this is not user-friendly, and using calls as you suggest would be a solution, but too cumbersome for the need.
The model should be simple and easy to understand because it's a means of communication.
There are many examples, i. e. in the OMG tutorials (distiller controller), where it seems obvious that you need the same behavior with only a slight change in a parameter.
Also, in a BDD, when a block A "owns" a part typed by block B, it does not mean that another block C could not also include a part typed by B.
After all, reusing blocks is one of the aims here.
So, maybe the UML specification is too restrictive, but some usability improvement would be welcome.
Regards.
Yannick.

Report message to a moderator

Previous Topic:	Modelling connectors in component diagram
Next Topic:	Showing/hiding "visibility" of parameters in operation

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri May 24 16:19:29 EDT 2013