Challenges in Preserving Intent Comprehensibility in Software

Abstract

Software is not only difficult to create, but it is also difficult to understand. Even the authors themselves in a relatively short time become unable to readily interpret their own code and to explain what intent they have followed by it. Software is being created with the goal to satisfy the needs of a customer or directly of the end users. Out of these needs comes the intent, which is relatively well understandable to all stakeholders. By using other specialized modeling techniques (typically the UML language) or in the code itself, use cases and other high-level specification and analytical artifacts in common software development almost completely dissolve. Along with dedicated initiatives to improve preserving intent comprehensibility in software, such as literate programming, intentional programming, aspect-oriented programming, or the DCI (Data, Context and Interaction) approach, this issue is a subject of contemporary research in the re-revealed area of engaging end users in software development, which has its roots in Alan Kay's vision of a personal computer programmable by end users. From the perspective of the reality of complex software system development, the existing approaches are solving the problem of losing intent comprehensibility only partially by a simplified and limited perception of the intent and do this only at the code level. This paper explores the challenges in preserving the intent comprehensibility in software. The thorough treatment of this problem requires a number of techniques and approaches to be engaged, including preserving use cases in the code, dynamic code structuring, executable intent representation using domain specific languages, advanced UML modularization, 3D rendering of UML, and representation and animation of organizational patterns.

Supporting Source Code Annotations with Metadata-Aware Development Environment

“…2) Selecting annotatable code fragment: Only valid code selections-those matching some AST elements-are mean- 1 LLAs may take advantage of already existing IDE support like code completion, but some typing is still involved. 2 We use the term code fragment in a sense of one or more consecutive elements selected for annotation. 3 Connotator is available at https://git.kpi.fei.tuke.sk/jan.juhar/connotator.…”

“…Many high-level concerns from the problem domain are either lost or scattered as programmers transform them to code. As argued by LaToza et al [1] and Vranić et al [2], programmers often ask questions about the intent behind particular source code fragments. In this paper, we present and evaluate an approach for helping to preserve the high-level knowledge within source code annotations.…”

Preliminary Report on Empirical Study of Repeated Fragments in Internal Documentation

“…P RESERVING and comprehending developer's concerns (intents) in the source code is still a current challenge in software development [1], [2], [3], [4]. In this paper we analyze the internal documentation (source code comments, JavaDoc, etc.)…”