As you probably know if you’re keeping in touch with the software engineering research community, there has been plenty of research on conceptual modeling in recent years. Most of it focuses on the creation, refinement, and formalization of modeling languages (UML, for instance). But the question of how do software developers truly use diagrams and modeling languages, if at all, is often left unanswered –researchers tend to assume that “if you build it they will come”, and hence (as I’ve complained before) their proposals grow more and more disconnected from the real needs and habits of developers.
This is why fieldwork studies that give us insights into the software development process are so valuable: they help to reconnect the software academia and industry.
A particularly interesting empirical paper on diagramming was presented by Cherubini et al. [1] at the CHI conference this year. It reports how and why software developers at Microsoft use diagrams, and what graphical conventions do they use. From the abstract: “Results show that most of the diagrams had a transient nature because of the high cost of changing whiteboard sketches to electronic renderings. Diagrams that documented design decisions were often externalized in these temporary drawings and then subsequently lost.”
There are several juicy bits in this paper. Here are just some of them:
- A distinction between the use of models for understanding, for designing, and for communicating, andthe differences in formality and effort put into each of them.
- A breakdown of drawing media used when modeling (interestingly, diagrams are almost always drawn in whiteboards).
- Some thoughts into the lack of use of graphical standards (“It is clear that UML does not, in general, reach a sufficient cost-benefit ratio in the minds of developers to warrant its use.”) and the lack of synchronization between models and code (“Visualizations in documentation were often out-of-date and they were rarely used for the core of the development process.”)
- Reports on very subtle design ideas that are elegantly conveyed through diagrams, but that are a real challenge to formalize: “We decided to give it this butterfly shape to emphasize that the contract in the center shouldn’t change and should be small…”.
- A discussion on levels of abstraction allowed by current graphical notations: “…developers need to understand both the microscopic details of the code and the macroscopic conceptual structure. (…) No current [standardized] view conveys both levels of abstraction simultaneously.”
It’s worth a read, but unfortunately you need an ACM subscription to access it. I’m sure you can get a copy if you email the authors, though.
—
[1] Mauro Cherubini, Gina Venolia, Rob DeLine, and Andrew J. Ko, 2007. “Let’s Go to the Whiteboard: How and Why Software Developers Draw Code“. Proceedings of the SIGCHI conference on Human factors in computing systems (CHI 2007).
