Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » State entry/exit/do behavior : reusing existing behavior (How can I select an existing activity for entry behavior)
State entry/exit/do behavior : reusing existing behavior [message #1008214] Mon, 11 February 2013 14:15 Go to next message
Yannick S. is currently offline 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.
Re: State entry/exit/do behavior : reusing existing behavior [message #1008247 is a reply to message #1008214] Mon, 11 February 2013 18:02 Go to previous messageGo to next message
Raphael Faudou is currently offline Raphael Faudou
Messages: 80
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
Re: State entry/exit/do behavior : reusing existing behavior [message #1008616 is a reply to message #1008247] Wed, 13 February 2013 10:16 Go to previous message
Yannick S. is currently offline 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.
Previous Topic:Modelling connectors in component diagram
Next Topic:Showing/hiding "visibility" of parameters in operation
Goto Forum:
  


Current Time: Mon Sep 22 16:14:29 GMT 2014

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

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