t was the final night of the SD West conference in Santa Clara, CA, as attendees wandered the hotel, seeking the locations of the different BOF (bird of a feather) sessions that we were interested in. Scott Meyers, the C++ guru, was leading a large band through the bar towards a multi-threading BOF; the mere size of the group gave me second thoughts on the popularity of Java, VB, or C#.
I, however, was searching for the MDA BOF. I had been to Stephen Mellor's MDA session earlier and looked forward to spending some time finding out more about MDA and, more importantly, to ask how it became associated with the agile movement. I half expected Bob Martin to show up since he and Mellor had had fun trading quips during the morning sessions. Unfortunately, "Uncle Bob" didn't show for this one but that didn't prevent it from being one of those sessions that changes your life.
As I walked around the hotel bar looking for the BOF I kept wondering if I was in the wrong place. Luckily I met up with another attendee who also hailed from Chicago and we sat together looking around for the session. Then, right on cue, Stephen Mellor appeared. After a couple of beers and some "California-style" health food pizza arrived, we were ready to begin.
After we each went around the room, giving pat answers that explained who we were, what we did, and what we expected out of MDA, Steve proceeded to give us the 5-minute version of his earlier MDA lecture. We ordered some spicy wings to go with our pizza. Then we spent some time talking about the role of MDA in our firms. One person had even done some real MDA modeling. Even more beer arrived, so much that we had to give some away. Then I asked the question that was burning in my mind: "How did MDA ever get associated with modeling?"
|Editor's Note: Bob Martin is one of the framers of the Agile Manifesto. He is called "Uncle Bob" because of his relationship with people like the three Amigos (developers of UML).
In 2001, Steve explained, he was approached by some of the soon-to-be-agile folks to attend a meeting in the Wasatch Mountains of Utah. Though he wasn't sure why a modeler like himself was asked but he went anyway. This turned out to be the signing of the Agile Manifesto. You will even see Steve's name as one of the signatories. During this meeting Steve asked the agile crowd why modeling was bad. The answer, of course, was that there should be nothing separating one from developing executable code—that the only way to really know that a system works is through the executable code. After thinking on this a bit Steve asked: 'what if the models were executable? Would that fit the agile bill?' 'Of course it would,' replied "Uncle Bob" and the agile alliance. The answer to this, of course, was MDA.
Steve's was a great story, and at the time I thought that it alone should make the night worthwhile. I could never have been more wrong.
Opening My Eyes to Invariants
During the rest of the conversation the topic turned to modeling. I asked Steve: 'How do we know when a model is good?' Steve answered with another story, this one told how many years ago he was working on a project to help straighten out a mess with a configuration of pipes and valves. A company had been adding to this system of pipes and valves for years and was considering making a change to it. They asked two of the senior engineers to suggest how best to change it. The first engineer suggested moving a couple of pipes around. To the shock of management the other engineer panicked claiming that such a move would blow up the whole configuration. They called Steve and his team to take a stab at it. After a couple of months of modeling efforts they finally came up with a solution. Steve and his team decided to model only the invariantsthose parts of the configuration that had to stay in the same place. After a few versions of modeling these invariants they saw the final solution, which was far simpler than any of the other versions.
The point of the story, of course, was to model to the level of invariants. This shook me to the core. A few hours later the BOF was finished. But I spent the next couple of weeks thinking on this new idea. Though it seemed rather obvious, the ramifications of it proved very interesting.
Modeling to the Level of Invariants
Modeling to the level of invariants is not a new concept in software development. We use it all the time without realizing it. Invariants are those elements that do not change from one iteration of a process to another. Top-down design assumes that as we start to model the next levels we don't modify anything in the higher level. The elements in the higher level are called the invariants. In fact, use cases have invariant conditions that do not change from the beginning of the use case to the end. They are still used in the use case but never changed.
RichMen, Inc., the fictional example from my UML article series here on DevX, is a good example of modeling to the level of invariants. The first article only considered the classes for Brokers, Clients, and Securities. I needed at least those three classes to even begin to attack modeling the application. At this point I didn't know anything else. Because these are core concepts, they will be there throughout the modeling process. This is what is meant by invariants. I did however modify Securities quite a bit, which is not prohibited but should be discouraged. In the convergence section on page 2, I'll show how to discourage the modification of invariants.
The invariants that are modeled become the playground for our design sessions. Napkin drawings, whiteboards, and other semi-permanent methods for modeling are used to capture all the other classes to be coded, refactored, and tested. The invariant model however won't change during this process.
Just as Steve refactored his pipe model we iteratively refactor. When we are confident that we have a solid design we take the results of the previous iteration, add them to the invariants, decide what is still invariant and that becomes our next model. We iterate over and over again until we find a point where we can't add to the invariant elements anymore. This is the idea of convergence.
|Author's Note: Notice that in the previous example (the one from my earlier article), UML was not a significant part of the modeling process. Modeling software doesn't always mean diagramming. It means building a representation of reality. Modeling can be in code in the case of prototyping or UML when diagramming. Each case is valid as long as the end result is to transform the vision into reality. Using a prototype should also not be confused with production code. The act of modeling is to remove all of the extraneous parts until all that is left is the minimal amount needed to solve the design problems. In agile development this is sometimes referred to using the process pattern for finding the simplest solution, but I think it's a misnomer that this minimalist approach can usually work in production. The act of producing production code, no matter how simple, always leads one to add extra elements that are needed for testing and acceptance but may not be needed to demonstrate the worth of the model.