Slicing Functional Programs by Calculation

The Reverse Engineering has started grabbing attention of every user in the process of program evaluation. Program slicing is a technique for understanding a program in terms of data and control dependencies. The main applications of program slicing include various software engineering activities such as program understanding, debugging, testing, program maintenance and complexity measurement. When the slicing technique gathers information on the data and control flow of the program taking into account an actual and specific execution(or set of executions) of it, then it is said to be dynamic, otherwise it is said to be static. The proposed tool presents a novel approach to the static analysis and dynamic analysis of attribute dependence. The notations are introduced with examples.

Given a program, a quotient can be obtained from it by deleting zero or more statements. The field of program slicing is concerned with computing a quotient of a program that preserves part of the behaviour of the original program. All program slicing algorithms take account of the structural properties of a program, such as control dependence and data dependence, rather than the semantics of its functions and predicates, and thus work, in effect, with program schemas. The dynamic slicing criterion of Korel and Laski requires only that program behaviour is preserved in cases where the original program follows a particular path, and that the slice/quotient follows this path. In this paper we formalise Korel and Laski's definition of a dynamic slice as applied to linear schemas, and also formulate a less restrictive definition in which the path through the original program need not be preserved by the slice. The less restrictive definition has the benefit of leading to smaller slices. For both definitions, we compute complexity bounds for the problems of establishing whether a given slice of a linear schema is a dynamic slice and whether a linear schema has a non-trivial dynamic slice, and prove that the latter problem is NP-hard in both cases. We also give an example to prove that minimal dynamic slices (whether or not they preserve the original path) need not be unique.

Program slicing is s method to extract the statements from the program which have an influence on the value of a variable at a paricular point of the program. Program slicing is applied for many applications, such as program degugging, program testing, program integration, parallel program execution, software metrics, reverse engineering, and software maintenance, etc. This paper is the study to create the exact slice in the presence of Object Reference State Graph to generate more exactly static analysis information of objects in the program of the presence of complicated data structure.

Aspect-oriented Programming (AOP) is a recent programming paradigm that focuses on modular implementations of various crosscutting concerns. The typical features of AOP such as join-point, advice, introduction, aspects etc. make it difficult for applying slicing. Program slicing is a method to extort statements that are relevant to a particular variable. Program slicing, as initially defined by Weiser is based on static dataflow examination on the flow graph of the program. Program slicing has been applied in parallel processing, program debugging, program integration,program understanding , software testing and maintenance etc.In this paper, we proposed a technique for dynamic slicing of aspectoriented software based on the UML 2.0 Communication diagram. Here, we can use slicing at the architectural level to find the slicing of communication diagram at an earlier stage of software development. To represent the various unique features of AOP in UML diagrams is very difficult and complex in nature. For this purpose, we first draw the communication diagram for aspect-oriented program considering the classes, pointcuts, advices and aspects. Next, we have generated an intermediate representation from the communication diagram. Then, we proposed an edge marking dynamic slicing algorithm that traverses the intermediate representation and finds the slices for the communication diagram of the given problem scenario. The novelty in our approach is that we present the communication diagram for the aspect-oriented software. Also, we proposed an algorithm to find the slice from it. The advantage of using communication diagram is that it mainly focuses on the interaction between the objects involved in the problem scenario.

Program slices are useful in debugging, testing, maintenance, and understanding of programs. The conventional notion of a program slice, the static slice , is the set of all statements that might affect the value of a given variable occurrence. In this paper, we investigate the concept of the dynamic slice consisting of all statements that actually affect the value of a variable occurrence for a given program input. The sensitivity of dynamic slicing to particular program inputs makes it more useful in program debugging and testing than static slicing. Several approaches for computing dynamic slices are examined. The notion of a Dynamic Dependence Graph and its use in computing dynamic slices is discussed. The Dynamic Dependence Graph may be unbounded in length; therefore, we introduce the economical concept of a Reduced Dynamic Dependence Graph, which is proportional in size to the number of dynamic slices arising during the program execution.

Program slicing is a well-known technique that extracts from a program those statements which are relevant to a particular criterion. While static slicing does not consider any input data, dynamic slices are computed from a particular program execution. Thus, dynamic slicers are usually easier to design and implement.In this work, we present a program specialization technique for lazy functional logic programming which is based on dynamic slicing. Our method exploits the code size reduction capabilities of slicing in order to produce a version of the original program specialized w.r.t. a given criterion. We also introduce some simple, post-processing transformations that allow us to further simplify the specialized program. The kind of specialization performed by our approach cannot be achieved with other related techniques like partial evaluation.

In this paper we have suggested a new method for test data generation using dynamic forward slicing algorithm. Separating the suspicious parts of code from the original program will make the process of test data generation easier. In forward dynamic slicing, the slices produced are much smaller than the original program and the search space for testing is considerably reduced. In this paper, we discuss the forward algorithm and the advantages of using forward dynamic algorithm for test data generation. The test cases are generated by analyzing the constraints present in the slices constructed from forward dynamic slicing algorithm. In the proposed method, the program for which the test data to be generated is analyzed. Forward slicing of the program is done with respect to all the variables whose value is changed during program execution. Slices obtained are then verified for statements which define certain constraints for test data generation. This helps to clearly define the limits of test data and remove the ambiguities about the value of the test data which is to be generated. The test data is then generated based on the constraints. In the proposed method, since forward algorithm is used, the execution traces need not be recorded and analyzing the constraints present in the slices will help in fault localization and debugging. This is one of the most important advantages of our method.

In this paper we argue that the incorporation of experiences on testing activities, in particular mutation testing, in programming courses adds valuable knowledge to the learning process. Mutation testing is centered on the idea of creating test data for uncovering seeded faults in programs that slightly differ from the original program. These faulty programs are called mutants. Through source code analysis and test case execution, testers have to identify the differences between the original program and the mutants. To do so, testers must have a sound understanding of the program's control flow and instructions. This broad understanding of programming represents a key skill for novice students in programming courses. We evaluate the effects of using mutation testing to improve the learning process of novice students in programming courses. We conclude that the introduction of mutation testing in the learning process provides students with learning experiences that go beyond traditional lectures and hands-on programming courses.

Computer software is an important part of computer, whose running security has a direct impact on the computer. In addition, the maintenance and management technology of computer software plays a key role in software running. Therefore, in order to ensure the smooth running of computer software, in this paper, it studies the maintenance and management technology of computer software, and puts forward strategies to improve the maintenance and management technology of computer software, so that to ensure the software runs more reliably.

When software developers want to understand the reason for a program's behavior, they must translate their questions about the behavior into a series of questions about code, speculating about the causes in the process. The Whyline is a new kind of debugging tool that avoids such speculation by instead enabling developers to select a question about program output from a set of “why did and why didn't” questions extracted from the program's code and execution. The tool then finds one or more possible explanations for the output in question. These explanations are derived using a static and dynamic slicing, precise call graphs, reachability analyses, and new algorithms for determining potential sources of values. Evaluations of the tool on two debugging tasks showed that developers with the Whyline were three times more successful and twice as fast at debugging, compared to developers with traditional breakpoint debuggers. The tool has the potential to simplify debugging and program understanding in many software development contexts.

Program slicing is a well-established technique for identifying a reduced subset of a program based on pre-defined criteria, leading to complexity reduction in subsequent activities. Despite extensive study over the past 40 years, slicing techniques for software product lines (SPLs) remain notably scarce. The absence of dedicated SPL slicing approaches hinders their efficient analysis and maintenance, limiting the ability to focus only on relevant parts of the SPL. One reason for this deficiency is the complex nature of a common variability implementation: the use of C preprocessor #ifdef-annotations within C code. A slicing approach for C-based SPLs must address the intricate interplay between the C code and the functionality introduced by the C preprocessor. Effectively handling these intricacies will unleash the full potential of SPL analysis. In this paper, we present a novel syntax-preserving program slicing approach for C-based SPLs. Unlike existing methods, our approach enables the computation of program slices through an integrated analysis of both C and CPP code, while preserving the original program syntax (no element of its syntax is disregarded or changed). This preservation ensures that the resulting program slices remain authentic subsets of the SPL, making them suitable inputs for variability-aware analyses. Additionally, we demonstrate the practical applicability of these slices in the context of software transplantation, showcasing their potential for facilitating functionality transfer between different program versions. In contrast to existing transplantation approaches, our solution works without test cases, removing the need for product configuration and execution. Consequently, the variability implementation (along with all other contained preprocessor code) is preserved during the transplantation. We empirically evaluate our approach on four distinct open-source SPLs, showcasing its effectiveness in generating diverse program slices tailored to different slicing criteria. We asses the accuracy of our code representation, the time required for slicing and transplantation, the size reduction achieved through the slices, and the functionality of our variability-aware transplantation approach.

In Man-At-The-End (MATE) attacks, software apps run on a device under full control of the attackers: they can violate the intellectual property of the app by means of malicious reverse engineering, software piracy, and software tampering. Obfuscation is a technique that is widely adopted by developers to mitigate this problem. Obfuscation increases complexity of software code, by obscuring the structure of code and data in order to thwart the reverse engineering process. However, it is possible to reverse engineer obfuscated code with time, determination and the right tools. In general, there is no accepted methodology to determine the strength of obfuscated code; however resilience is often considered a good metric as it indicates the percentage of obfuscated code that cannot be removed by automated de-obfuscation tools. We introduce a novel approach to measure the resilience of obfuscated C code using program slicing. Given a variable of interest, that might be part of a code region used to manipulate a crypto key or a license number, program slicing can mimic the attacker behaviour by trying to remove the code unrelated to that variable, acting as a new type of de-obfuscator.

Program slicing is a technique for analyzing program by focusing on the statements which have dependence relations with slicing criterion. Slicing has applications in testing and debugging, re-engineering, program comprehension and software maintenance. Program verification is an important method in assuring the correctness and reliability of computer hardware and software. One of the major problems is space-explosion in the application of this method to concurrent software systems: state space grows exponentially in the number of concurrent components. In fact, it is often the case that some of the statements of the program are irrelevant to the verified property and can be deleted. In this paper, we introduce an approach for slicing concurrent object-oriented programs to reduce state space in the process of program verification. Firstly, we define the dependencies between statements in the given program. Then present the method of extracting slicing criterion from linear temporal logic property and propose the steps of computing slicing. We also discussed that the satisfaction of the verified LTL property is guaranteed for both programs before and after slicing, and at the same time the number of states in state transition graph is decreased.

This paper reports on an empirical strategy of software understanding during corrective maintenance of large-scale software with professional maintenance programmers. Hypotheses are key drivers in program understanding and influence the direction program understanding can take. This paper reports on the types of hypotheses programmers make, how they resolve them, and the strategies and comprehension processes they tend to use

Different program slicing methods are used for maintenance, reverse engineering, testing and debugging. Slicing algorithms can be classified as static slicing and dynamic slicing methods. In several applications the computation of dynamic slices is preferable, since it can produce more precise results. In this paper, we introduce a new forward global method for computing backward dynamic slices of C programs. In parallel to the program execution, the algorithm determines the dynamic slices for any program instruction. We also propose a solution for some problems specific to the C language (such as pointers and function calls). The main advantage of our algorithm is that it can be applied to real-size C programs, because its memory requirements are proportional to the number of different memory locations used by the program (which is in most cases far smaller than the size of the execution history which is, in fact, the absolute upper bound of our algorithm).