PhD Research

There are a number of pages in the internet that list research papers on the topic of Visual Programming Languages. Since these pages are rather out of date I decided to give my two cents to the global effort and add what I have read on the topic. I have decided to include all of the papers that I have deemed relevant to my research into visual languages, which means that some of the papers here may have no direct relation to the primary subject, but I think that research should be more wide than deep – only deepening in specific places where more information is required. Like everything else in life, it is a balance.

1/1/2012 – I decided to change the title of this page to better match its contents.

04/10/2012 – Found the WikiCFP, a wiki for call for papers.

If you have more suggestions please feel free to contact me by adding a comment to this page.

But first, some existing pages on the research subjects which interest me:

• Paul Lyons’ VPL Papers page
• Wikipedia page on Visual Programming Languages
• Margaret M. Burnett’s Visual Language Research Bibliography – A very extensive and up-to-date bibliography (last updated in 2009)

1. Advances in Dataflow Programming Languages
   • Authors: Johnston, W.M., Hanna, JR, Millar, R.J.
   • Year: 2004
   • Link: http://portal.acm.org/citation.cfm?id=1013209
   • Abstract: Many developments have taken place within dataflow programming languages in the past decade. In particular, there has been a great deal of activity and advancement in the field of dataflow visual programming languages. The motivation for this article is to review the content of these recent developments and how they came about. It is supported by an initial review of dataflow programming in the 1970s and 1980s that led to current topics of research. It then discusses how dataflow programming evolved toward a hybrid von Neumann dataflow formulation, and adopted a more coarse-grained approach. Recent trends toward dataflow visual programming languages are then discussed with reference to key graphical dataflow languages and their development environments. Finally, the article details four key open topics in dataflow programming languages.
   • My Notes: While not really a VP paper, I think that dataflow programming may be a very good paradigm for the executable semantics of visual programming languages.
2. Visual Modelling: past, present and future
   • Authors: Watson, A.
   • Year: 2008
   • Link: http://www.omg.org/UML/Visual_Modeling.pdf
   • Abstract:
   • My Notes: Another paper that is not exactly about VP, but graphical modeling, and specifically UML is a graphical modelling language that is widely used and some things can be from the MDA initiative.
3. Sketching and Drawing in the Design of Open Source Software
   • Authors: Chung, E., Jensen, C., Yatani, K., Kuechler, V., Truong, K. N.
   • Year: 2010
   • Link: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5635226
   • Abstract: In co-located software development, diagramming practices, such as sketching ideas out with a pen and paper, support the creative process and allow designers to shape, analyze, and communicate their ideas. This study focuses on the diagramming practices used in the design of Open Source Software (OSS), where the norm is highly distributed group work. In OSS, text-based communication (e.g., mailing lists) dominates, and sketching and drawing diagrams collaboratively remains difficult due to the barriers imposed by distance and technology. Previous studies have examined these practices and barriers in the context of individual projects. To understand how contributors across OSS projects use diagrams in design-related activities, we conducted a survey of 230 contributors from 40 different OSS projects, and interviewed eight participants. Our results show that although contributors understand the advantages of using diagrams for design-related activities, diagrams are infrequently used in OSS. This motivated us to examine how and why diagramming occurs, and the factors that prevent widespread use in OSS. Finally, we propose new ideas for supporting design activities in OSS projects.
   • My Notes: I think that a good VP language should be based on the current and common “drawing” practices of the industry. This paper is an initial investigation on the subject.
4. Mental imagery and software visualization in high-performance software development teams
   • Authors: Petre, Marian
   • Year: 2010
   • Link: http://linkinghub.elsevier.com/retrieve/pii/S1045926X09000755
   • Abstract: This paper considers the relationship between mental imagery and software visualization in professional, high-performance software development. It presents overviews of four empirical studies of professional software developers in high-performing teams: (1) expert programmers’ mental imagery, (2) how experts externalize their mental imagery as part of teamwork, (3) experts’ use of commercially available visualization software, and (4) what tools experts build themselves, how they use the tools they build for themselves, and why they build tools for themselves. Through this series of studies, the paper provides insight into a relationship between how experts reason about and imagine solutions, and their use of and requirements for external representations and software visualization. In particular, it provides insight into how experts use visualization in reasoning about software design, and how their requirements for the support of design tasks differ from those for the support of other software development tasks. The paper draws on theory from other disciplines to explicate issues in this area, and it discusses implications for future work in this field.
   • My Notes: Like the previous paper, it is a research on how software developers visualize the software they are developing. It summarizes four studies done by the research on the subject, giving some implications and conclusions. Reading the summary of the first study could make you think that the study’s subjects where all high on drugs or something when interviewed: “it moves in my head y like dancing symbols… I can see the strings [of symbols]y assemble and transform, like luminous characters suspended behind my eyelids” – but being a programmer I can strongly identify with the descriptions provided in the paper. And not, we are usually not high when we program (at least not the programmers I know).
5. Integrating Textual and Graphical Modelling Languages
   • Authors: Engelen, L., van den Brand, M.
   • Year: 2010
   • Link: http://linkinghub.elsevier.com/retrieve/pii/S1571066110001143
   • Abstract: Graphical diagrams are the main modelling constructs offered by the popular modelling language UML. Because textual representations of models also have their benefits, we investigated the integration of textual and graphical modelling languages, by comparing two approaches. One approach uses grammarware and the other uses modelware. As a case study, we implemented two versions of a textual alternative for Activity Diagrams, which is an example of a surface language. This paper describes our surface language, the two approaches, and the two implementations that follow these approaches.
   • My Notes: Describes the creation of a textual language that is parallel to an already existing visual language. Not very interesting.
6. Structured Flowcharts Outperform Pseudocode: An Experimental Comparison
   • Authors: Scanlan, D.A.
   • Year: 1989
   • Link: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=35587
   • Abstract:
   • My Notes: There is an ongoing war between researchers who say that visual languages are easier to understand than textual languages, and those that say there is either no difference or textual languages are better. And there are a number of papers supporting those views. This is one classic paper on visual languages where the author describes a very controlled experiment he performed on university students, where he found that the students understood better the visual language than the textual one (on the same problem). Personally I don’t like experiments done on students since most of them are not really programmers and in my view the results from these experiments are questionable, but still, this is a classic paper for anyone interested in the cognitive aspects of visual languages in software development.
7. The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering
   • Authors: Moody, D.
   • Year: 2009
   • Link: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5353439
   • Abstract: Visual notations form an integral part of the language of software engineering (SE). Yet historically, SE researchers and notation designers have ignored or undervalued issues of visual representation. In evaluating and comparing notations, details of visual syntax are rarely discussed. In designing notations, the majority of effort is spent on semantics, with graphical conventions largely an afterthought. Typically, no design rationale, scientific or otherwise, is provided for visual representation choices. While SE has developed mature methods for evaluating and designing semantics, it lacks equivalent methods for visual syntax. This paper defines a set of principles for designing cognitively effective visual notations: ones that are optimized for human communication and problem solving. Together these form a design theory, called the Physics of Notations as it focuses on the physical (perceptual) properties of notations rather than their logical (semantic) properties. The principles were synthesized from theory and empirical evidence from a wide range of fields and rest on an explicit theory of how visual notations communicate. They can be used to evaluate, compare, and improve existing visual notations as well as to construct new ones. The paper identifies serious design flaws in some of the leading SE notations, together with practical suggestions for improving them. It also showcases some examples of visual notation design excellence from SE and other fields.
   • My Notes: This is an excellent paper, a must read for any research in visual languages. It lists a number of parameters that can be used to create visual notations that contain more information and can also be interpreted correctly. It shows many anti-patterns that are in use by existing notations (notably UML). I will be re-reading this paper at least one more time and try to apply what it says to the language that I am creating. Furthermore, it has a large number of references that I must now follow and read. Thanks Mr. Moody.
8. Do Visualizations Improve Program Comprehensibility? Experiments with Control Structure Diagrams for Java
   • Authors: Hendrix, T. D., Cross, J. H., Maghsoodloo, S., McKinney, M. L.
   • Year: 2000
   • Link: http://portal.acm.org/citation.cfm?doid=331795.331890
   • Abstract: Recently, the first in a series of planned comprehension experiments was performed to measure the effect of the control structure diagram (CSD) on program comprehensibility. Upper-division computer science students were asked to respond to questions regarding the structure and execution of a source code module written in Java. Statistical analysis of the data collected from this experiment revealed that the CSD was highly significant in enhancing the subjects’ performance in this program comprehension task. The results of this initial experiment along with the planned follow-on experiments promise to shed light on fundamental questions regarding the effect of software visualizations on program comprehensibility.
   • My Notes: Another experiment that tests how visualizations help program comprehension. The researchers added visual notations to the code (like the ones that are now common in IDEs like eclipse, where you can see where loop or if statements start and end) and measured how much these visualizations improved code comprehension. The study was done on 39 students, so the population is relatively large.
9. Visual programming: Limits of Graphic Representation
   • Authors: Nickerson, J.V.
   • Year: 1994
   • Link: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=363624
   • Abstract: The effectiveness of graphic representations of computer programs is analyzed. Existing software metrics are modified for use in analyzing diagrams, and two new metrics are proposed: graphic toke count and diagram class complexity. A graphic design measure, data density, is transformed into a computer science measure, token density. Using these metrics, graphic representations can be compared to each other and to textual representations. Conclusions are drawn about the relative strengths of graphical and textual representation.
   • My Notes: A short and concise paper (2 pages), defines simple metrics to measure information density in visual languages. These metrics can later be used to which problems should be solved visually and which textually. I agree with his conclusions that not all problems should be tackled graphically but that a mixed methodology should be adopted.
10. Problems and Opportunities for Model-Centric Versus Code-Centric Software Development
    • Authors: Forward, A., Lethbridge, T. C.
    • Year: 2008
    • Link: http://portal.acm.org/citation.cfm?doid=1370731.1370738
    • Abstract: We present some results of a survey of 113 software practitioners conducted between April and December 2007. The aim of the survey was to uncover their attitudes and experiences regarding software modeling, and development approaches that avoid modeling. We were motivated by observations that modeling is not widely adopted; many developers continue to take a code-centric approach. Key findings overall include: Modeling tools are primarily used to create documentation and for up-front design with little code generation; and participants believe that model-centric approaches to software engineering are easier but are currently not very popular as most participants currently work in code-centric environments. Key findings from sub-samples include: problems identified with model-centric approaches are similar regardless of a participant’s country. Programmers that model extensively (versus those that do not model much) are more likely to agree that models become out of date and inconsistent with code.
    • My Notes: Summary of a survey of relatively experienced software developers on their thoughts on model-centric and code-centric approaches to software development. The survey shows that most developer value modeling as a tool used to think in a specific moment in time, and not as project artifacts that should be maintained as the product evolves. Most of the participants don’t use formal tools and if they use UML, it is also used informally. And the biggest problem with models is that they become inconsistent with the code (which makes them more harmful than useful – from my personal experience).
11. Reviewing Software Diagrams: A Cognitive Study
    • Authors: Hungerford, B.C., Hevner, A.R., Collins, R.W.
    • Year: 2004
    • Link: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1265814
    • Abstract: Reviews and inspections of software artifacts throughout the development life cycle are effective techniques for identifying defects and improving software quality. While review methods for text-based artifacts (e.g., code) are well understood, very little guidance is available for performing reviews of software diagrams, which are rapidly becoming the dominant form of software specification and design. Drawing upon human cognitive theory, we study how 12 experienced software developers perform individual reviews on a software design containing two types of diagrams: entity-relationship diagrams and data flow diagrams. Verbal protocol methods are employed to describe and analyze defect search patterns among the software artifacts, both text and diagrams, within the design. Results indicate that search patterns that rapidly switch between the two design diagrams are the most effective. These findings support the cognitive theory thesis that how an individual processes information impacts processing success. We conclude with specific recommendations for improving the practice of reviewing software diagrams.
    • My Notes: The results of this research show that both the static and the dynamic models of software artifacts are important in understanding their meaning, since subjects which searched both of this models found more defects than other subjects. I like it because I think that these two models should be united, as is done in OPM. The switching between diagrams costs mental time that can be saved if they are united.

Information on software developer productivity:

http://accelerateddevelopment.ca/blog/no-experience-necessary/

http://www.codinghorror.com/blog/2004/09/skill-disparities-in-programming.html

What We Actually Know About Software Development, and Why We Believe It’s True

Reading Code

http://blog.theincredibleholk.org/blog/2012/12/18/how-do-we-read-code/

http://synesthesiam.com/posts/modeling-how-programmers-read-code.html