How can diagramming tools help support programming activities?

2001

Visual programming languages aim to broaden the use ofdiagrams within the software industry, to the extentthat they are integrated into the programming languageitself.

Programmers spend much of their time investigating the source code of a program, which often involves navigating and understanding delocalized code fragments. This Ph.D. project explores the use of information visualizations that are designed to support programmers in these activities. I use controlled experiments to provide precise measurements of the usability of visualizations and detailed insight into users' interaction with visualizations. Also, case studies are used to understand how professional programmers use visualizations in realistic work activity. Overall, this research will contribute empirically founded insight into the design and use of visualizations in programming.

2018

Developers produce a lot of code and most of them have to merge it to what already exists. The required time to perform this programming task is thus dependent on the access speed to information about existing code. Classic IDEs allow displaying textual representation of information through features like navigation, word searching or code completion. This kind of representation is not effective to represent links between code fragments. Current graphical code representation modules in IDE are suited to apprehend the system from a global point of view. However, the cognitive integration cost of those diagrams is disproportionate related to the elementary coding task.

2017

A classic Integrated Development Environment (IDE) allows displaying information only with a textual representation. This kind of representation is perfect for the linear aspect of the code, but not effective to represent links between code fragments. Current graphical code representation modules in IDE are suited to apprehend the system from a global point of view. However, the cognitive integration cost of those diagrams is disproportionate related to the elementary coding task. Our approach considers graphical representation but only with code elements that are parts of the developer's mental model during his programming task. The corresponding cognitive integration of our graphical representation is then less costly and the information that text struggles to display will be clearly explicit. We use UML for this representation because it is a widespread and well-known formalism. We want to show that dynamic diagrams, whose content is modified and adapted in real-time by monit...

2007

In the software field, this is justified by the increasing research into software visualization. Pictures are increasingly being used to represent software code with many studies establishing that they improve comprehension. This paper discusses results from observing expert programmers use 3 visualization tools. The results show that if tools are developed without user consultation, they may fail to be useful for the users. The necessity for developers of tools to target the needs of the users for whom the tools are aimed is further discussed.

Abstract. Designing notations that business stakeholders can understand is one of the most difficult practical problems and greatest research challenges in the IS field. The success of IS development depends critically on effective communication between developers and end users, yet empirical studies show that business stakeholders understand IS models very poorly. This paper proposes a radical new approach to designing diagramming notations that actively involves end users in the process.

Software: Practice and …, 2008

1977

This paper describes previous research on flowcharts and a series of controlled experiments to test the utility of detailed flowcharts as an aid to program composition, comprehension, debugging, and modification. No statistically significant difference between flowchart and nonflowchart groups has been shown, thereby calling into question the utility of detailed flowcharting. A program of further research is suggested.

Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering - FSE 2014, 2014

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.

Computer Diagrams are the communication mechanism among the different stakeholders of the software development lifecycle. While they are though at school, and promoted to be used by students for current and future projects, we still do not see full adoption in real life context. The literature reviewed points out some reasons related to this issue and propose some solutions, but still the problem persist. In this paper, we present our findings of three years of research at the University while working with senior students on real-life projects. Different methodologies were used as an iterative process, improving the quality of the results year by year. We present the lesson learned including guidelines on how to facilitate novice engineers to adopt diagrams and produce them with high quality standards. The proposal is validated with a real life case study.