Hi Stéphane,
thanks for the explanation. So that probably means we have to maintain
the guards' names and specifications redundantly if we want to have a
guard _expression_ both being displayed in the diagram *and* copied
verbatim to the Java code.
Now that leads me to the question: is it possible to have a guard's
name being displayed in the diagram, instead of its specification? If
that was possible, we'd have to maintain only the guards' names, not
their OCL specifications.
Maybe that's what Volker Stolz' modification to
statemachinediagram.edit:TransitionEditPart.java does?
Regards,
Jörg
Stéphane DUPRAT wrote:
Jörg,
For the moment SMUC just takes the names of the guards and put it in
the source code.
Indeed, you have to express the guard in the native language.
So, it doesn't work with guards expressed in OCL.
There was a new feature defined to traduce OCL guards in native
language, but not quite implemented, and works are now in stand-by.
If you use SMUC, take a moment to see informations à the SMUC project
in the gforge.
regards,
Stéphane
Jörg von Frantzius a écrit :
Hi Benoit,
thanks for your answer. I just realize that I seem to have created my
guards in a wrong way. All I managed to fill in was the guards' name,
not their specification (like in your model). I'll probably have to
apply some profiles before I'll be able to do that?
I don't think you need a profile for that, but perhaps to work in the
outline.
On the other hand, I was able to generate Java code from my statemachine
using Topcased SMUC, and the guards' names were copied verbatim to the
Java code as desired. When I try to run SMUC on your model, it fails
silently without generating anything. This may be due to other
differences in the .uml file, but maybe it is related to the different
way that you specify your guards.
Do you per chance already use SMUC on your statemachines?
Regards,
Jörg
Benoit MAGGI wrote:
Hi,
We manage to show the guard for the simulation, see the attached piece.
Regards,
Benoit MAGGI
Jörg von Frantzius a écrit :
Hi Volker,
I was already afraid that something like this would be necessary :-/
I found this related bug in the topcased issue tracker:
http://gforge.enseeiht.fr/tracker/?group_id=52&atid=109&func=detail&aid=1025
That refers to this feature request:
http://gforge.enseeiht.fr/tracker/index.php?func=detail&aid=676&group_id=52&atid=133
Somebody already contributed code for this feature, which is supposed
to be included in the 1.x stream since 2008-01-23.
Is it possible that the 2.x stream has forked before that date, so
the feature may be implemented in 1.x, but not in 2.x?
Regards,
Jörg
Volker Stolz wrote:
In article <[EMAIL PROTECTED]>,
Jörg von Frantzius <[EMAIL PROTECTED]> wrote:
in my state machine diagram, I have several transitions with guards.
Unfortunately, I cannot find any way of getting them to show up in the
diagram.
You have to modify the source to get them. We added this ourselves
in the source at statemachinediagram.edit:TransitionEditPart.java.
Volker
------------------------------------------------------------------------
_______________________________________________
Topcased-users mailing list
[email protected]
http://lists.gforge.enseeiht.fr/mailman/listinfo/topcased-users
------------------------------------------------------------------------
_______________________________________________
Topcased-users mailing list
[email protected]
http://lists.gforge.enseeiht.fr/mailman/listinfo/topcased-users
_______________________________________________
Topcased-users mailing list
[email protected]
http://lists.gforge.enseeiht.fr/mailman/listinfo/topcased-users
_______________________________________________
Topcased-users mailing list
[email protected]
http://lists.gforge.enseeiht.fr/mailman/listinfo/topcased-users
|
