Sketches and diagrams play an important role in the daily work of software developers. In this paper, we investigate the use of sketches and diagrams in software engineering practice. To this end, we used both quantitative and qualitative methods. We present the results of an exploratory study in three companies and an online survey with 394 participants. Our participants included software developers, software architects, project managers, consultants, as well as researchers. They worked in different countries and on projects from a wide range of application areas. Most questions in the survey were related to the last sketch or diagram that the participants had created. Contrary to our expectations and previous work, the majority of sketches and diagrams contained at least some UML elements. However, most of them were informal. The most common purposes for creating sketches and diagrams were designing, explaining, and understanding, but analyzing requirements was also named often. More than half of the sketches and diagrams were created on analog media like paper or whiteboards and have been revised after creation. Most of them were used for more than a week and were archived. We found that the majority of participants related their sketches to methods, classes, or packages, but not to source code artifacts with a lower level of abstraction.
@cite_28 interviewed eight software developers at Microsoft, identifying nine scenarios in which developers created and used drawings. They explored these scenarios using a survey with 427 participants, also recruited at Microsoft. We based our list of purposes for sketch creation on their scenarios (see Table ) and found similar results. However, we asked for further purposes and found analyzing requirements to be an important task. state that the use of formal notations like UML was very low. This is consistent with Petre @cite_4 , who reports on a series of semi-structured interviews with 50 professional software developers on their UML use. She states that the majority of interviewed practitioners did not use UML and those using UML, tended to use it informally and selectively. Our study confirms the informal use of UML, but we found that 57
@cite_28 @cite_4
2110957405 2057909950
Software developers are rooted in the written form of their code, yet they often draw diagrams representing their code. Unfortunately, we still know little about how and why they create these diagrams, and so there is little research to inform the design of visual tools to support developers' work. This paper presents findings from semi-structured interviews that have been validated with a structured survey. 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. Current visualization tools and the software development practices that we observed do not solve these issues, but these results suggest several directions for future research. Abstract Designers, during a conceptual design process, do not just synthesize solutions that satisfy initially given requirements, but also invent design issues or requirements that capture important aspects of the given problem. How do they do this? What becomes the impetus for the invention of important issues or requirements? So-called unexpected discoveries', the acts of attending to visuo-spatial features in sketches which were not intended when they were drawn, are believed to contribute to it. The purpose of the present research is to verify this hypothesis. Analysing the cognitive processes of a practising architect in a design session, we found that in about a half of his entire design process there were bi-directional relations between unexpected discoveries and the invention of issues or requirements. Not only did unexpected discoveries become the driving force for the invention of issues or requirements, but also the occurrence of invention, in turn, tended to cause new unexpected discoveries. This has provided empirical evidence for two anecdotal views of designing. First, designing is a situated act; designers invent design issues or requirements in a way situated in the environment in which they design. We call inventions of this sort situated-invention (S-invention). Secondly, a design process progresses in such a way that the problem-space and the solution-space co-evolve. Further, this has brought a pedagogical implication as well as an insight about an important aspect of learning by experience in design.