eric.lemerdy

Last week, we used TDR^[1] to help us understand a problem and the solution finally emerges.

The problem

This is an eclipse RCP application that uses the well known MVC pattern. The data model is hierarchic and several editors can be opened at different levels. The problem is that we have some transversal data that can be viewed along the tree structure. How can a view be always updated against users editions ?
Considering the following structure:

• root
  • node1 - use transverse data X, Y
  • node2 - use transverse data X, Z

Description of the scenario:

1. Editor on node 1 is opened
2. Editor on node 2 is opened
3. Some changes are made in editor 1 on transverse data X
   The editor is "dirty".
4. Some changes are made in editor 2 on transverse data X
   The editor is "dirty".
5. Editor 1 is saved.

How can the changes on transverse data X made in the first editor be reflected in the second one ?

Solving the problem

We shortly came to the fact that an event should be fired when the data model is changed. Editors are registered to listen for those events to make them aware that they should reflect changes. This is not the complicated part of the problem.
The "reconciliation" algorithm that the editor should implement is not trivial.
This was the time to stop trying to code it, step up the team in front of a blank white board and use TDR^[1] to help us specify with some examples.

The white board

After a short discussion, we found a notation to represent data attached to an editor:

Saved

saved data before any edition

Modified

modified data during edition. This is typically a bean that is tied on UI components

Data model

the new data model that is embedded in the event to alert editor that data changed

Output

the output of the algorithm: the reconciliated data

(Our data are indexed list of objects.)
Then we started to scratch on white board. The white board has been "saved" on this sheet:

Then we set up test cases from simple to complex (1.). For each of them, we specify data (2.) as couples: C_A, D_A (Clé (key), Data) and C_A', D_A' for modified data.
The final algorithm emerges in the box (3.). The result is simple:

• if the "Saved data" is the same than "Modified data"
  • "Output" should be set to "Data model"
• otherwise
  • "Output" should be set to "Modified data"

Big letters in output column learns us that algorithm applied for list comparison can be also be applied for list elements themselves when the case become more complex.

Lesson learned

• TDR^[1] is helping emerging conception
• Examples from a TDR^[1] session are capitalized in unit tests (in our case)
• This TDR^[1] session became the technical documentation (because the client want a technical documentation)
• Our examples remains generic because we found it useless to represent real data (a collection of objects
• TDR^[1] is helping to make the implementation of a solution simpler
• The client were intrigued to see programmers out of their usual 'behind-the-screen' position ! It helps our team to show what we were working on.

---

[1]: Test Driven Requirements ou spécifications dirigées par les tests.