Dans cet exercice, il s’agit de reconcevoir un environnement de développement pour y ajouter des fonctionnalité de gestion de l'historique qui dépasse le modèle de pile habituellement utilisé dans les mécanismes de défaire/refaire. En effet, avec ce modèle, toute opération défaite entraine l'annulation de toutes les opérations postérieures à cette opération. Dans cet exercice on vous demande de concevoir un mécanisme de undo-redo qui permette de sélectionner les opérations à défaire et/ou à refaire.

1. Quelles sont les abstractions utiles pour gérer les opérations de undo-redo dans ce contexte: quel est le bon niveau de granularité des oépration à défaire/faire, ce niveau de granularité peut-il être choisi par l'utilisateur? Comment sont gérées les dépendances entre les opérations? Comment assurer une cohérence entre les abstractions liées au undo-redo et les abstractions liées aux outils de gestion de version?
2. Couplé à un outil de sauvegarde, de gestion de version ou de capture d'écran, le undo-redo peut permettre de réaliser rapidement une documentation utile à la compréhension d'un code source. Dans ce contexte, l'environnement de travail est d'abord utilisé par un développeur pour écrire le code, puis dans un deuxième temps, l'environnement de travail peut-être utilisé par le même développeur ou par un autre développeur pour faire apparaitre les grandes étapes d'écriture du code en utilisant le mécanisme de undo-redo allié à d'autres artéfacts. Dans ce cas, il est possible que l'ordre dans lequel les opérations d'édition se sont produites ne soit pas l'ordre pertinent pour produire les explications? Quelles sont les bonnes abstractions à mettre en place pour rendre les interactions avec l'ordre satisfaisantes?