Thinking twice about it

We are conducing an interesting exploration project these days.

The product I am working on uses UML models as a primary input. Those models are used for test generation, after setting various coverage criteria on the model elements.

Conceptually, the picture is quite clear: data in, data out. However, the devil is in the details,...

Having the same UML model referenced in 2 different tools leads to pretty complex synchronisation issues between the 2 data repositories:

• when an operation is removed, you have to remove the corresponding configuration
• when an operation is added, you have to set some kind of defaults for it
• when an operation is renamed, well,... you're stucked! You can only treat it as a removal + addition

So working on the third generation of the product, I was challenged pretty hard by the development manager to find anything that would allow us to get rid of those synchronisation mechanisms. I was quite reluctant at first but decided to have a go at it.

Thinking twice about it

I started this exploration and it appears that I may be quite possible:

• using the UML profile capabilities of the UML tool, it is possible to add more semantics to model elements and let user define properties on them
  

• using UML2.0 interactions allow us to represent quite nicely the operations that are targeted for test generation
  

Yes, this could work. But wait! Look at the pay-offs, we wouldn't hope they were so great:

• the configuration is always coherent with the model
  
• there's not a line of code to edit, visualize or store this configuration
• you have a natural way to define initial states for test generation and to deal with UML elements
  
• this approach is reproducible to other UML modeling tools in the category we're targeting
  
• you don't have anymore test generation projects to manage, because all the information is efficiently stored along with the modeling project!

Okay, okay the "No silver bullet" theorem still applies there. There are some obvious drawbacks:

• we are constrained by the UML tool. The properties that are vital for -us- are displayed by -them-

• we are, of course, a lot more dependent on the tool bugs (and of course I spotted some, even if I could find turnarounds)

• there is no easy way to tell the user what to do to configure the test generation. It doesn't come right into his face (that's the biggest drawback to me - a UI is supposed to provide the maximum guidance to the next thing to do)

I don't know where this experiment will lead us but the lesson is nonetheless interesting:

Think about it twice: can you state your software requirements so that the solution is not included in the question?

"We need an application to configure the parameters on the model elements"

Otherwise this may lead to other requirements,...

"Please, synchronize the data for me,..."