She conducted an excellent interview-based study of 50 software developers in a wide variety of industries and geographical locations. Her key question was, "Do you use UML".
She found that only 15 out of 50 use it in some way, and none use it wholeheartedly.
A total of 11 use it selectively, adapting it as necessary depending on the audience. Of this group use of diagram types was: Class diagrams: 7, sequence diagrams: 6, activity diagrams: 6, state diagrams: 2 and use case diagrams: 1.
Only 3 used it for code generation; these were generally in the context of product lines and embedded software. Such users, however, tended not to use it for early phases of design, only for generation.
One used it in what she called 'retrofit' mode, i.e. "Not unless the client demands it for some reason".
That leaves the 35 software developers who do not use it (70%). Some reported historical use, and some of these did in fact model using their own notation.
The main complaints were that it is unnecessarily complex, lacks and ability to represent the whole system, and has difficulties when it comes to synchronization of artifacts. There were also comments about certain diagram types, such as state machines being only used as an aid to thinking. In general, diagram types were seen as not working well together.
She did comment on the fact that UML is widely taught in educational programs.
My overall response to this paper is, 'bingo'. The paper backs up research results we have previously published, which served as a motivation for the development of Umple.
Features of Umple that are explicitly designed to help improve UML adoption include:
- Umple can be used to sketch (using UmpleOnline) and the sketch can become the core of high quality generated code later on.
- It is a simplified subset of UML, combatting the complexity complained about in the Petre's research.
- It explicitly addresses synchronization of artifacts by merging code and UML in one textual form: UML, expressed textually is just embedded in code, with the ability to generate diagrams 'on the fly', and edit the code by editing either the code or those diagrams.
- It integrates diagram types: State machines work smoothly with class diagrams, for example.
- Diagrams like state machines finally become useful in a wide variety of systems, not just embedded systems.