Figure 2 - uploaded by Laura K. Dillon
Content may be subject to copyright.
Strongly-articulated, yet infeasible model of an error trace.
Source publication
Graduates of computer science degree programs are increasingly being asked to maintain large, multi-threaded software systems; however, the maintenance of such systems is typically not well-covered by software engineering texts or curricula. We conducted a think-aloud study with 15 students in a graduate-level computer science class to discover the...
Contexts in source publication
Context 1
... use the UML 2.0 sequence diagram, with some adornments, to depict these models. Figure 2 depicts an (infeasible) candidate error suffix, as artic- ulated by one of the participants in our study. Here, two han- dler threads (denoted h1 and h2) concurrently attempt to retrieve a request from an empty request queue. ...
Context 2
... is especially true in a maintenance context where the programmer may lack a global view of the program. The model in Figure 2 is not feasible, be- cause the listener thread uses signal rather than broadcast to notify a handler thread of a request in the queue. Thus, only one of the handlers will be awakened during the activation of submit_request, whereas the model depicts both as being awakened. ...
Context 3
... re- ferred to threads only in the abstract, whereas others also identified which thread acted as the listener and which threads acted as han- dlers. Additionally, some participants articulated the interactions that might culminate in an error with sufficient detail that we could construct an error suffix such as is depicted in Figure 2, whereas others did not articulate necessary information for formulating an error suffix. For example, a participant might say that an operation is invoked, but not say which thread invokes the operation; or he might not say when a thread acquires (releases) a lock or when it waits (awakens from a wait). ...
Similar publications
Software testing involves identifying the test cases which discover errors in the program. However, exhaustive testing of software is very time consuming. In this paper, a technique is proposed to prioritize test case scenarios by identifying the critical path clusters using genetic algorithm. The test case scenarios are derived from the UML activi...
We investigate the problem of maintaining a topology with small degree as well as small diameter in a dynamic distributed system such that the system always stays connected and processes that wish to leave the system can do so quickly. Perpetual system connectivity is necessary to solve many important problems in dynamic distributed systems, includ...
Citations
... Each paper was reviewed by an author of this paper, and then double-checked by another author for The COMET method using the UML notation. 66 Evaluating UML extended sequence diagram notation called saUML 67 Assessing of saUML using a controlled experiment 68 Expressing security requirements in UML diagrams 69 Animating sequence diagrams 70 Control flow analysis of UML sequence diagrams 71 Comparing the layout of sequence diagrams of two tools 72 Evaluating user-constructed sequence diagrams 73 Modeling the behavior of mobile applications 74 Modeling the stealthy behavior of Android application 75 Combining different artifacts to get a thorough model 76 Statically generating sequence diagrams from Android source code 77 Reverse engineering of UML sequence diagrams for web applications 78 Modeling event-based interactions of JavaScript 79 Modeling Ajax web applications confirmation. The extracted information are based on a set of 17 defined attributes. ...
... Another study conduced a controlled experiment on a set of students by asking them to manually construct sequence diagrams from execution traces of a system. 72 The aim of that study was to see whether users would be able to diagnose system failures using execution-based tracing information only. The results indicate that, in order to diagnose a failure, one should first localize the fault from the execution trace and then use trace modeling to properly finish the diagnosis. ...
Reverse engineering of sequence diagrams refers to the process of extracting meaningful information about the behavior of software systems in the form of appropriately generated sequence diagrams. This process has become a practical method for retrieving the behavior of software systems, primarily those with inadequate documentation. Various approaches have been proposed in the literature to produce from a given system a series of interactions that can be used for different purposes. The reason for such diversity of approaches is the need to offer sequence diagrams that can cater for the users' specific goals and needs, which can vary widely depending on the users' perception and understandability of visual representations and the target application domains. In this paper, we systematically review existing techniques in this context while focusing on their distinct purposes and potentials of providing more understandable sequence diagrams. In addition, a qualitative evaluation of such techniques is conducted to expose their adequacy and applicability for effective program comprehension. Finally, we list a set of possible extensions to the unified modeling language sequence diagram standard that we anticipate will enhance its versatility and understandability of program control flow, followed by a number of concluding remarks.
... Although previous studies of program comprehension relied on tasks such as fixing bugs as in [15], [16], or explaining a solution aloud as in [15], [17], our experiment only implied reading code and answering questions about the system's feature and execution behavior. For each of the three systems described in III-C, participants were asked to answer a set of questions related to four categories as defined below: ...
Source code comprehension affects software development — especially its maintenance — where code reading is one of the most time-consuming activities. A programming language, together with the programming paradigm it supports, is a strong factor that profoundly impacts how programmers comprehend code. We conducted a human-subject controlled experiment to evaluate comprehension of code written using the Data Context Interaction (DCI) paradigm relative to code written with commonly used Object-Oriented (OO) programming. We used a new research-level language called Trygve which implements DCI concepts, and Java, a pervasive OO language in the industry. DCI revisits lost roots of the OO paradigm to address problems that are inherent to Java and most other contemporary OO languages. We observed correctness, time consumption, and locality of reference during reading comprehension tasks. We present a method which relies on the Eigenvector Centrality metric from Social Network Analysis to study the locality of reference in programmers by inspecting their sequencing of reading language element declarations and their permanence time in the code. Results indicate that DCI code in Trygve supports more comprehensible code regarding correctness and improves the locality of reference, reducing context switching during the software discovery process. Regarding reading time consumption, we found no statistically significant differences between both approaches.
... We use comprehension tasks as described in Section 3.2.2, because this methodology provides objective results and scales well (most controlled studies hardly include more than 15 subjects [19], [20] -we have 127 subjects). Yet, the experiment requires a controlled environment with on-site execution and staff supervision to make sure that developers perform the task without external help. ...
... We briefly discuss the alternatives we evaluated. In the think aloud approach, subjects comment on the actions they are performing [19], [20]. A subsequent interview can clarify the motivations behind each action [21]. ...
Starting from the first investigations with strictly functional languages, reactive programming has been proposed as the programming paradigm for reactive applications. Over the years, researchers have enriched reactive languages with more powerful abstractions, embedded these abstractions into mainstream languages – including object-oriented languages – and applied reactive programming to several domains, like GUIs, animations, Web applications, robotics, and sensor networks. However, an important assumption behind this line of research is that, beside other claimed advantages, reactive programming makes a wide class of otherwise cumbersome applications more comprehensible. This claim has never been evaluated. In this paper, we present the first empirical study that evaluates the effect of reactive programming on comprehension. The study involves 127 subjects and compares reactive programming to the traditional object-oriented style with the Observer design pattern. Our findings show that program comprehension is significantly enhanced by the reactive-programming paradigm – a result that suggests to further develop research in this field.
... Inspecting concurrent traces manually, however, is still tedious and timeconsuming. An empirical study of strategies commonly used for diagnosing and correcting faults in concurrent software shows that the primary concern of the programmer is to produce and analyze a failing trace by reasoning about potential thread interleavings based on some degree of program understanding [9]. In light of the complexity of this task, tool support is highly desirable. ...
We propose an automated mining-based method for explaining concurrency bugs.
We use a data mining technique called sequential pattern mining to identify problematic
sequences of concurrent read and write accesses to the shared memory of a multithreaded
program. Our technique does not rely on any characteristics specific to one type of concurrency
bug, thus providing a general framework for concurrency bug explanation. In our
method, given a set of concurrent execution traces, we first mine sequences that frequently
occur in failing traces and then rank them based on the number of their occurrences in passing
traces. We consider the highly ranked sequences of events that occur frequently only in
failing traces an explanation of the system failure, as they can reveal its causes in the execution
traces. Since the scalability of sequential pattern mining is limited by the length of the
traces,we present an abstraction technique which shortens the traces at the cost of introducing
spurious explanations. Spurious as well as misleading explanations are then eliminated by
a subsequent filtering step, helping the programmer to focus on likely causes of the failure.
We validate our approach using a number of case studies, including synthetic as well as
real-world bugs.
... To ensure that the time required is roughly the same for each task and to avoid that overhead time, e.g., to navigate the application, is significant compared to debugging activity, tasks 1-4, which are shorter, are composed of 2 or 3 subtasks. We adopted the think loudly approach where subjects comment their actions [15,22]. Our goal is not to analyze developers behavior in detail. ...
Reactive programming is a recent programming technique that provides dedicated language abstractions for reactive software. Reactive programming relieves developers from manually updating outputs when the inputs of a computation change, it overcomes a number of well-know issues of the Observer design pattern, and it makes programs more comprehensible. Unfortunately, complementing the new paradigm with proper tools is a vastly unexplored area. Hence, as of now, developers can embrace reactive programming only at the cost of a more challenging development process.
In this paper, we investigate a primary issue in the field: debugging programs in the reactive style. We analyze the problem of debugging reactive programs, show that the reactive style requires a paradigm shift in the concepts needed for debugging, and propose RP Debugging, a methodology for effectively debugging reactive programs. These ideas are implemented in Reactive Inspector, a debugger for reactive programs integrated with the Eclipse Scala IDE. Evaluation based on a controlled experiment shows that RP Debugging outperforms traditional debugging techniques.
... In addition, very little work has been done at the intersection of parallel programming and user evaluation: even less with professional developers [26]. For his thesis, Scott Fleming observed programmers debugging a multithreaded server application that had been seeded with a concurrency bug [10,11]. Interestingly, several participants were able to find and fix the flaw, but were not able to correctly describe the design defect that caused the problem. ...
Developers need help with multithreaded programming. We investigate how two program analysis tools are used by developers at Google: ThreadSafety, an annotation-based static data race analysis, and TSan, a dynamic data race de- tector. The data was collected by interviewing seven veteran industry developers at Google, and provides unique insight into how four different teams use tooling in different ways to help with multithreaded programming. The result is a collection of perceived pros and cons of using ThreadSafety and TSan, as well as general issues with multithreading.
... Principales Elementos de un Diagrama de Secuencias UML. Fuente:Fleming et al. (2008) ...
This article reviews the basic principles of UML sequence diagram (Unified Modeling Language) to model dynamic behavior of software and describes the steps needed to achieve an aspect-oriented modeling using this tool. This with the object of reaching greater autonomy and cleaning during the modeling and implementation of the main tasks of a software application. For these purposes, the object-oriented software development methodology (OOSD) is described remarking the importance of UML for the modeling of structures and behavior of object-oriented software applications. Furthermore, the main characteristics of the aspect-oriented software development methodology (AOSD) are mentioned, considering AOSD as an extension of OOSD. This makes it necessary for reviewing and adapting UML for the support of aspect-oriented modeling. In this context, a classic case study of the AOSD method is modeled.
... The experimenter may still briefly interrupt, but interruptions are focused on brief clarifications rather than extended discussions. Direct observations can be conducted both as field studies (c.f., [21][24][34]), watching developers in the field do their everyday work, or in lab studies which permit choice of the task and comparisons of developers doing the same work (c.f., [24][20][12] [35][1]). Direct observations lead to generalization by analyzing the data afterwards. ...
Designing useful tools for developers requires identifying and understanding an important problem developers face and designing a solution that addresses this problem. This paper describes a design process that uses data to understand problems, design solutions, and evaluate solutions' usefulness.
... Different models and techniques are proposed by researchers in the area of software corrective maintenance [4] [5] [6]. Walia and Jeffrey proposed a catalog C[7] for aid of developers to reduce errors during the requirement inspection process and to improve overall software quality. ...
From the preliminary stage of software engineering, selection of appropriate enforcement of standards remained a challenge for stakeholders during entire cycle of software development, but it can lead to reduce the efforts desired for software maintenance phase. Corrective maintenance is the reactive modification of a software product performed after delivery to correct discovered faults. Studies conducted by different researchers reveal that approximately 50 to 75% of the effort is spent on maintenance, out of which about 17 to 21% is exercised on corrective maintenance. In this paper, authors proposed a RCM (Reduce Corrective Maintenance) model which represents the implementation process of number of checklists to guide the stakeholders of all phases of software development. These check lists will be filled by corresponding stake holder of all phases before its start. More precise usage of the check list in relevant phase ensures successful enforcement of analysis, design, coding and testing standards for reducing errors in operation stage. Moreover authors represent the step by step integration of checklists in software development life cycle through RCM model.
... However, much less is known of issues specific to the maintenance of these systems. Previously, we performed a think-aloud study [16] of programmers engaged in the corrective maintenance of a concurrent program [7]. This study strove to understand what behaviors correlate with success on task. ...
... In addition to the think-aloud data we collected and used for this prior study, the participants took a posttest to assess the extent to which they understood the program. However, at the time of publication [7], we had yet to analyze these data. This paper reports the results of the posttest analysis and attempts to reconcile these results with the predictions of two well-known studies [10,17]. ...
... Our previous study collected data to uncover the activities programmers perform when diagnosing and correcting synchronization-related faults in multi-threaded programs [7]. The raw data from this previous study comprise video and transcripts collected using the think-aloud method [6,16]. ...
While the sources of complexity in the initial design and verification of multi-threaded software systems are well-documented, less is known of the issues specific to the maintenance of these systems. The literature contains a number of observational studies of programmers performing maintenance, conducted in the context of sequential software and designed to investigate the factors and behaviors that lead to success. To help fill the gap in knowledge in the area of concurrent software maintenance, we conducted a study that refines the findings of two prior studies, those of Littman et al. and of Vessey, to address issues and obstacles that arise in the understanding of concurrent software. We validated these refinements by observing programmers performing corrective maintenance on a small but complex multi-threaded server program.
