Bugs
VisualUL 1.0 has the following known bugs which are difficult to fix
for the moment :
-
when the user opens the instance window, in the instanciated components
the following may happen :
-
when opening directly a component by double click with the middle button,
which has the effect to open the component, but not in a separate window,
the states may miss. They are back if you open a separate window before.
So double click with left button, and then with the middle button.
-
some uncontrolled behaviour with the scroll panel may be seen by some added
border. One could see these extra borders when playing open/close inside/outside.
I am careful with the panel by removing all the components, by java adds
a new border and even if I set a null border there are still problems.
-
when defining objects, or in an instance window, the entries/exits may
not be moved correctly when resizing the corresponding superstate. The
reason of this is totally unknown since this works well when the user defines
for these objects, but sometimes, it does not work properly. A strange
fact is that the same code is always used.
-
when the user changes the instance name before instanciating, the name
may not be updated in the corresponding label in the class hierarchy.
Defects
There are some defects in VisualUL which are :
-
concerning the data members, one can not edit them.
The data members are created or deleted, but not modified.
-
the labels which reflect the guards, synchronization
and assignments do not contain the shadowed names when editing the classes.
They are correct, however, with the instances.
-
the entries/exits on superstates have in their tooltip
the entry/exit definition, i.e. the corresponding state (or whatever) they
are connected to.
-
when we reconstruct the model from a file, it is
a sensible reconstruction, in the sense that two transitions are different
if they have different source, target, guard, synchronization or assignment.
This means that if a user saves a file with two identical transitions,
but with different graphical representations, these representations will
be merged to one after the reconstruction.
-
there is a limit about the flattening process : expressions
are considered integers. This means that one can not flatten correctly
an expression of the form b:=(x<34) with b boolean. Furthermore a translation
of this kind of formula is not possible to a compatible expression for
UPPAAL.
-
the translation for value passing has its limits
: if the sender reaches a commit state just after a synchronization with
value passing, then the model is modified since there is a commit state
which is created at the receiver's side. We have two commit states which
have to be left in two processes at the same time.
Back