Sparx Systems Forum
Enterprise Architect => Suggestions and Requests => Topic started by: slangmgh on September 22, 2003, 01:00:06 am
-
EA is a wonderful product, but the undo/redo function need to be enhanced, like together, it can undo/redo everything user operating.
-
yes, i subscribe to this - i am very frustrated from unexpected functionality of undo.
even unexpected saving - if i exit and dont save, then any changes are saved (!), any not.
i am very very disillusioned ... :o
-
no-0ne reply ?
what is the use of this forum ?
pavus
-
Hi Pavus,
Changes to the projectbrowser are immediate, changes on a diagram are saved on loading a new diagram. If you exit, all should be saved.
Could you indicate which changes are saved and which not?
Greetings,
Tjerk
P.s.: I would also expect a more mature Undo(/Redo) functionality, many of the users get frustrated by the lack of it. I also know this is a heavy requirement which could take lotst of time to implement and test.
-
Hi Tjerk,
the undo does not work for deletion of elements. Of course EA asks before really deleting an element. However, a minute later I a bit wiser and know that I should not have deleted it - but: too late. Undo should work in every circumstance - even to undelete element.
BR
Thomas
-
At the risk of just re-iterating what the above posters have noted:
The Undo/Redo functionality of EA needs to be totally re-done. Being unpredictable, it's almost completely useless. And with version 3.60, there is no 'redo', so if something unpredictable *does* happen, there is no recourse.
Undo/Redo is a pretty essential feature in graphics manipulation; it'd be awesome if this could be redone in version 4 :).
-
Yes, I am not happy with unexpected saves.
You delete something and think if you do not save the file it will not be in file but later you see you have been wrong, everything has been applied to database file at the same moment.
These 2 things are among the rare problems I have seen in EA.
Overally I rarely see problems with EA.
Mac
-
I concur - please improve Undo.
Not mentioned above is the impact on the use of the product. With undo, users feel more comfortable experimenting with new functionality. Without undo the user base will mature through the product feature to become advanced users set much slower than competing products - hence it's not good for EA either.
I'm currently evaluating EA and see this as a significant flaw.
-
Just want to warn everybody with this request.
I see a big reason for EA lacking of this feature - it is build on Jet engine that is database and usually what ever was deleted from database it is gone. If you want to have undo/redo feature you should look into file based software like Visio. Just warning - for big (I mean just a little bigger ) projects those programs are slow. I think that performance gain that EA has over other programs, I worked with, is on expense of this feature (undo/redo).I vote for performance.
Of cause if they can manage to get both would be great.
Shimon
-
I agree. Having worked with JET DBs since Access v1.0 I am very well aware of how hard it would be to implement undo throughout EA to the level people here are suggesting.
It is also a core feature - it would cost Sparxs an immense amount of effort and time to rewrite EA to include such free-format undo/redo capability.
Given the functionality and price of EA compared to both the ridiculously overpriced heavyweight commercial offerings (you know who) and the free but functionally impared ARGO based alternatives I reckon exercising a bit of care with the delete key etc is a small negative compared to Geoff and his people's stunning product.
I would much rather see Sparx focus on functional issues rather than this.
(just my 20c worth)
B
-
Bruce,
I guess you are right :'( I revoke my opt for this feature.
Thomas
-
btw. I remeber that Rose also does have very poor undo :P
-
Yes, now that I think it will be very hard to change things because of the Jet DB file.
But isn't it possible to queue some actions in memory and then save them to database at specific times (i.e saving etc.) ? Though I know a big change of architecture will be needed and it would not be possible quickly.
I think this should happen at a time but as I told later I am overally very happy with the product (more more than rational).
And yes , when I work with rational I need to put 30% of my mind on Rational's UI. (To prevent problems happening now or later).
At the time being I'd like to see some more automation like conversion of sequence diagram to collaboration (rational does it for a while) etc.
I also like to see some improvements in code engineering (toward a more professional thing) . It will be great if we can constantly work on code and model and have them in sunc with each other (specifically I am thinking about C# and PHP myself).
Mac
-
I dont think that using a data base or not makes any difference in supporting undo/redo or not.
In fact while EA is the best CASE tool in respect of features (espcialy if you dare to compare it with beasts like Rational Rose) it is absolutely astonishing to me why its undo/redo is simply said: the worst I've ever seen.
I dont know how easy DB migrations are, but the simplest way (with some drawbacks of course) is to have for every item in the DB a flag "deleted".
For all commands changing the DB you create a Command object according to the GoF Command Pattern.
The commands can be written to the DB as well, depending on how long you like to keep them sitting around.
On saving/quitting you delete all items marked as deleted and remove the Commands from the DB.
I guess one mixed up "deleting" a business object from a "diagram" with a "DELETE FROM ..." :D
Regards,
angel'o'sphere
-
Angel'o'sphere,
that would be correct if undo/redo had to work only for deletion of the objects - how about modifying them? This is much more complex a thing than one would realize.
Do not take me wrong, I would much like the undo/redo enhanced!
Bruno
-
I respectfull dissagree,
all other changes are in my experiance easy. (I have written a complex CAD System and a CASE system my own)
You have only 4 kinds of commands:
* creation
* deletion
* attribute change
* linking -- a special case of attribute change
Linking is more complex as it can fall into three subgroupes:
* create new and link (drawing a new connector causes about 4 new links)
* unlink and create new and link (typing a new stereotype over an existing one or relink an end of a connection to a different classifier)
* unlink old and link existing (replacing a type for an attribute or return type of an method with a different one or moving a classifier into a different package)
The more complex ones only change two or more attributes, while the simpler ones change just one, or create/delete something.
The problem you see might come from redoing commands in a unknown or free order. But thats not needed(and likely not wanted).
As long as commands are executed sequencialy by the user, they get stored in a kind of double linked queue, so you can move with a curser forward and backward. Undoing is only possible sequencialy as well, while the cursor is moved backward towards the beginning of the queue. Redoing is only possible forwards by moving the cursor in direction of the end of the queue. There exist no unforseeable side effects between undoing/redoing as they are executed in their order of dependency.
If a command causes cascading effects, usually only happening if you move a class from one package to the other or you delete a classifier and all links need to get deleted as well, affecting other classifiers, you create a composite command and group all commands together.
Now we have only one problem: interaction of several users working simultaniously, maintaning one shared comand queue or seperated queues? That means the DB should probably be cleaned up after the last one loggs off?
A database problem I see: DB generated IDs. Deleting a classifier and removing it from the DB and later redoing its creation might cause it to get a different key/ID. Thats why I mark deleted objects only as deleted and keep them as long as I think they might get revived.
Anyway: if you had the command pattern implemented and the commands persistant, long time persistant not only per session, stuff like versioning and historization would become trivial as well.
Imagine to roll a view of a diagramm one week back.
In our days a complete command log is no memory issue anymore ... and if you fear the memory usage indeed, then start throwing away commands older than a week, or two, or 6 monthes.
A complete command log would be a uique selling point for EA ... as far as I know. (As my CASE system never made it to the market as my company went bancrupt :-/ in 1999 and I never saw another system supporting it)
Oh, yes, in case you consider to go for that: I seperated commands wich only had view effects, like alligning all classes vertically, from commands changing the model. The view history was thrown away after the user switched to an other diagram, only the model changes where kept.
Regards,
angel'o'sphere
-
angel-o-sphere
This really looks like reading from the tea leaves. Probably someone from SPARX could write a comment on how difficult it is to implement a better undo/redo (I guess it IS difficult, since if not they would have implemented it a long time ago ;D).
Thomas
-
angel-o-sphere,
Learned a lot from your post :)
I was thinking about these yeasterday so your post was very interesting. Thank you.
But again it seems we will need to have redesign of some parts. As program is being developed using MFC and VC++ I think it will not be very easy. But as I told later I think Sparx will need to do it at a time.
I wish they can manage to do so in next few versions.
Thank you again.
Mac
-
Thanx for the compliments ::)
I'm sure it is not easy, as the general structure of the tool allready exists since some time.
However the "skin" of the appliation shows that it has an excellent internal quality, the incredible high release frequency support that asumption.
There is a rule of thumb: external quality follows internal quality :D So I would say the obvious high external quality implies high internal quality :D which makes the asumption that Sparx has allready a plan where to put such an improvement in the back hand.
Ooops, do you say "in the back hand" in english?
Regards,
angel'o'sphere
-
Hi angel,
at least in german it is the same :)
I guess you are right with most of your assumptions. But as there is still no response from Sparx here, I'm still some kind of disbeliever. However, I hope you are right in that last assumption too :D
Cheers,
Thomas
-
Oh sh.. you are from Germany too :o
I suspected you to be located in Italy (why?)
-
Yeah,
I'm from Karlsruhe, germany. Visit my web site if you like: www.oomnetor.de :D
Angelo
-
I had visited all pages of your website last week. As I am planning to go for my MSc and perhaps PHD in Germany and I am learning Deutsch very seriously it was very interesting to me.
I will contact you later for advice on chosing the university later if I am not bothering.
Regards,
Mac
-
Hrrrrrump........gently enters the scence. All the above said, and interesting as it is, couldn't we just turn off the auto-saving in EA. I'd like to control when I save.
:)
-
Hi Sean,
I guess there is no difference between the SAVE and UNDO problem since (almost) every operation is executed directly on the database. I'd also like to have both (control save and have undo/redo) but most likely it is simply too difficult for Sparx to implement that (no response so far - guess what I mean). Bruce is most likely right in his assumption above :'(
Cheers,
Thomas
-
Fair comment Thomas. Howwever, given the sort of software Sparx produce, I would have thought it likely that it is tiered and loosely coupled under the hood, making the cacheing of middle-tier changes fairly simple. We'll see!
Cheers
Sean