PRFC (Pascal Roques Formation & Conseil)

A l'occasion du 10è anniversaire du Manifeste Agile, les 17 auteurs ont fait part de leurs sentiments sur le sujet.

Le témoignage qui m'a le plus intéressé est celui de Steve Mellor, qui prône depuis toujours la modélisation exécutable, et qui était parmi les signataires un peu par hasard ...

I Hoped to Derail Their Evil Plans

Stephen J. Mellor

I was astonished to be invited to what became the meeting that originated the Agile Manifesto because my work had always been based around building models.  The Structured Development for Real-Time Systems trilogy with Paul Ward and the pair of Object-Oriented Analysis books with Sally Shlaer all focused on analysis and design, placing much less emphasis on the coding and testing favored by agile practitioners.

Moreover, I had recently read Kent Beck’s Extreme Programming and I was horrified by the lack of emphasis on up-front thinking, abhorrence of models and the deprecation of documentation. However, it was clear that lightweight, extreme, or agile approaches were gaining traction, so I resolved to attend the meeting. The fact that it was in the Rockies in winter had nothing to do with it.

I introduced myself as a spy who hoped to derail their evil plans. While I found many of the positions taken regarding process to be sound (talking to the customer, for example, or timeboxing), the rejection of models was surely unjustified. Yes, there had been an overemphasis on “big design up front,” but surely models had some value. Yes, writing documents (and models) had come to be seen as an end in itself, but surely the correct response was not to throw the productivity gains from modeling out with the dirty documentation.

So just why were models so bad? Because they don’t execute, I was told. Yet my work over the preceding decade had been all about building executable models. Over the few days of the meeting I had a similar conversation with almost all of the signatories, sometimes more than once.

This intellectual passing-in-the-night came about because we had differing ideas about what the word “model” means. Some signatories viewed models (if they thought about them at all) as sketches, to be drawn on napkins for communication purposes and then thrown away. What drew the most ire was the view of a model as a blueprint to be thrown over the wall to developers who did as they were told. I held neither of those views. I thought models ran.

Though we were executing models in 2001, it was with our own action language. I heard repeatedly at the meeting that you could not write a program to say “Hello World!” in the Unified Modeling Language (UML). And although you could, in fact, say “Hello World!” in UML, it certainly wasn’t easy. In fact, it was an advertisement for writing code. This had to be addressed if modeling was to become widely viewed as executable.

In 1997, when the UML was accepted as a standard, there were but seven actions you could carry out in a model, and one of those was “uninterpreted string.” (You can certainly forgive the signatories for thinking that models couldn’t execute!) I proposed a standard Action Language for UML. Some folk immediately suggested standardizing on Java. Or Smalltalk. Or....

But an existing programming language is insufficient because it works at too low a level of abstraction. It therefore mixes (to some degree) application concepts with their implementation. For example, when we build a particular data structure (a list of Customers, say, with pointers to lists of Accounts), we have made a decision about implementation. In the UML, we would instead express this is as an association, but we would not specify its implementation.

Moreover, when we come to operate on this data in code, we have to take into consideration the implementation we have selected. For example, to sum up all the account balances for a specific customer, we are required to traverse the linked list. It would be simpler to say (somehow) “sum all of the account balances for this customer.”

It’s not so much that we want to be able to execute models in UML—we could just add code to achieve that. It’s that we want the higher productivity that comes from operating at a higher level of abstraction away from the implementation. We also want to be able to change our minds about the implementation without changing the description of the problem. The UML model would have the same application meaning if we put Customers and Accounts into a database implementation.

Over the following twelve years, we (the members of the Object Management Group, the organization that standardized UML, and especially Ed Seidewitz from Model Driven Solutions) have produced a series of standards that define the kinds of actions permissible in UML; defined a subset of UML for execution; defined the semantics of that subset precisely; and (finally!) defined a standard Action Language for UML.

In that language, the example above would be written:

myCustomer.account.balance -> reduce ’+’

where “reduce” is an operation that “reduces” the collection of balances produced by traversing from myCustomer to all their accounts by applying a binary operation, in this case ‘+’ repeatedly until only a single value remains. Of course, that can then be translated into an implementation using linked lists. Or a database. Or anything else. There are no lists in the specification, nor any traversal of them, just a very compact statement of what needs to be done. (By the way, one design requirement for the language was that it be easily accessible to Java programmers, so much of the syntax looks like Java. The example here was chosen not to obfuscate but to illustrate the power of moving away from the implementation.)

The other signatories were kind enough, back in 2001, to write the Manifesto using the word “software” (which can include executable models), not “code” (which is more specific.) So I felt able, in good conscience, to become a signatory to the Manifesto while continuing to promote executable modeling. Ten years on we have a standard action language for agile modeling.

We rarely see the words “agile” and “model” in the same sentence, but they are not at all in conflict. Rather, modelers can learn a lot from the agile folk (building tests for models early, for example) and those following an agile process can benefit from the increased productivity and eased customer communication that come from sharing executable diagrams with their pair-modeling customers. Surely that’s a win for everyone.

For more detailed information, including critical references, look here.