Incremental UML for Agile development: embedding UML class models in source code

Agile methods favor "working software over comprehensive documentation." The latter presumably includes Unified Modeling Language. UML is expensive to maintain, and it lacks good drill-down mechanisms, however, UML affords very useful visualizations. This paper describes a discipline for incrementally embedding graphical UML class models within source code for continuous agile development. The approach consists of identifying a main function, and having it drive the piece-wise creation of UML by explicitly including in its postconditions the placement of functions corresponding directly to requirements. The approach thus introduces higher order pre-and postconditions. A specific process is provided for carrying this out, together with examples. It enables UML class model visualization in rapid development, especially when tool-supported

Stop-list slicing.

Traditional program slicing requires two parameters: a program location and a variable, or perhaps a set of variables, of interest. Stop-list slicing adds a third parameter to the slicing criterion: those variables that are not of interest. This third parameter is called the stoplist. When a variable in the stop-list is encountered, the data-flow dependence analysis of slicing is terminated for that variable. Stop-list slicing further focuses on the computation of interest, while ignoring computations known or determined to be uninteresting. This has the potential to reduce slice size when compared to traditional forms of slicing. In order to assess the size of the reduction obtained via stop-list slicing, the paper reports the results of three empirical evaluations: a large scale empirical study into the maximum slice size reduction that can be achieved when all program variables are on the stop-list; a study on a real program, to determine the reductions that could be obtained in a typical application; and qualitative case-based studies to illustrate stop-list slicing in the small. The large-scale study concerned a suite of 42 programs of approximately 800KLoc in total. Over 600K slices were computed. Using the maximal stoplist reduced the size of the computed slices by about one third on average. The typical program showed a slice size reduction of about one-quarter. The casebased studies indicate that the comprehension effects are worth further consideration

Application Domain Knowledge in Computer ProgramComprehension and Enhancement

Software development transforms the conceptual models of the application domain into the formal models of the implementation (programming) domain (Blum 1989). The application domain is where the conceptual models, which describe what is to be done and possible approaches for a solution, are generated. These conceptual models account for many of the essential difficulties in software development (Brooks 1987). Research investigating software development, however, has focused on the implementation domain or computing element (Glass and Vessey 1992). Recent thinking indicates that investigations into the problems of software development must begin to consider the application domain (e.g., Guindon 1990). Software maintenance is one task where application domain knowledge may play an important role. Maintenance remains important to organizations because maintenance costs, as a percentage of software expense, are expected to remain relatively constant (Foster 1991). Of maintenance activities, this research investigates enhancement because it accounts for the greatest percentage of person-hours expended on maintenance (Lientz and Soloway 1980, Abran and Nguyenkim 1991). To enhance a computer program, programmers need to comprehend the existing program. It is estimated that maintenance programmers devote 50%-90% of their time to understanding the existing program, with the remaining 10%-50% spent implementing the enhancement (Robson et al. 1991). The present research is an experimental investigation of the role of application domain knowledge in comprehension and enhancement. Establishing the importance of application domain knowledge in comprehension and enhancement may provide insight into why these tasks account for such a high percentage of software related costs

Using Program Slicing to Identify Faults in Software

This study explores the relationship between program slices and faults. The aim is to investigate whether the characteristics of program slices can be used to identify fault-prone software components. Slicing metrics and dependence clusters are used to characterise the slicing profile of a software component, then the relationship between the slicing profile of the component and the faults in that component are then analysed. Faults can increase the likelihood of a system becoming unstable causing problems for the development and evolution of the system. Identifying faultprone components is difficult and reliable predictors of faultproneness not easily identifiable. Program slicing is an established software engineering technique for the detection and correction of specific faults. An investigation is carried out into whether the use of program slicing can be extended as a reliable tool to predict fault-prone software components. Preliminary results are promising suggesting that slicing may offer valuable insights into fault-proneness

ABSTRACT EXECUTION OF PROGRAMS

Compilation time analysis of programs is usually incomplete. One of the basic methods for static determination of the program's dynamic properties is symbolic execution. Symbolic execution still fails to satisfy practical requirements, mainly because of the high execution time and memory requirement, theorem proving and program termination problems. In this paper new methods are presented which can make symbolic execution applicable in everyday work, e.g. in programming microprocessor equipment

Max-CSP Approach for Software Diagnosis

In software development is essential to have tools for the software diagnosis to help the programmers and development engineers to locate the bugs. In this paper, we propose a new approach that identifies the possible bugs and detect why the program does not satisfy the specified result. A typical diagnosis problem is built starting from the structure and semantics of the original source code and the precondition and postcondition formal specifications. When we apply a determined test case to a program and this program fails, then we can use our methodology in order to obtain automatically the sentence or the set of sentences that contains the bug. The originality of our methodology is due to the use of a constraint-based model for software and Max-CSP techniques to obtain the minimal diagnosis and to avoid explicitly to build the functional dependency graph