What’s There Instead
“The real grand challenge for software engineering research is relevance.”
I’m not particularly observant at the best of times—it’s one of the reasons I don’t drive—but even so, I’ve been kicking myself for not noticing something about The Architecture of Open Source Applications in time to include a note in the introduction. There are over 100 diagrams in the book, only half a dozen of which use any standard modeling notation like UML. Putting it another way, experienced software architects don’t believe that a standard modeling notation is the best way to communicate their ideas roughly 95% of the time. It’s not ignorance: I’m positive that everyone who helped write a chapter for the book would immediately recognize UML, and could draw a more-or-less legal class diagram or sequence diagram if asked to. And it wasn’t laziness, either, or a side effect of them dumbing down their work for a lay audience.
Of course, that observation raises a question: what do they use instead? What exactly do experienced designers describe when they describe the “architecture” of their software? I think that AOSA is a unprecedented opportunity to find out. A careful analysis of what its contributors do and don’t say (the kind of qualitative study typified by several of the chapters in Making Software) could tell us what modeling notations for software architecture need to include for software architects to find them compelling.
It would be a hell of a paper, but I’m not an academic any more, and other things are more pressing. If you’d like to take a crack at it, please let me know—I’d be happy to introduce you to our contributors.
I think it’s only responsible that I offer myself to write this paper for at least the following reasons:
1) The very first thing that struck me about the book was the variance in diagramming styles.
2) I did my Master’s thesis on ‘Model Driven Architecture’ and spent too much time grappling with the (lack of) semantics of UML.
3) I’m a long-time developer about to start a PhD program, and this falls well within the bounds of potential paper topics.
Let’s talk soon.
Regards,
Pat Morrison
The number might even be higher than 95%. Some of the 5% diagrams may have been produced by people who wouldn’t normally use UML, but felt pressure to do so in this case because it was a more formal situation (published in a book). The opposite bias is unlikely: I find it hard to imagine a person who exclusively uses UML notation in normally live choosing not to use it for a diagram just because it was being published in a book.
Learning UML, much like learning Java, helped me create opinions on things I like and don’t like.
Now I write Python/JS all day and draw freestyle flowchart diagrams with stickfigures in the margins. Who knows where I’d be if I didn’t learn about things I didn’t end up using.