Debugging is considered as a rigorous but important feature of software engineering process. Since more than a decade, the software engineering research community is exploring different techniques for removal of faults from programs but it is quite difficult to overcome all the faults of software programs. Thus, it is still remains as a real challenge for software debugging and maintenance community. In this paper, we briefly introduced software anomalies and faults classification and then explained different fault localization models using theory of diagnosis. Furthermore, we compared and contrasted between value based and dependencies based models in accordance with different real misbehaviours and presented some insight information for the debugging process. Moreover, we discussed the results of both models and manifested the shortcomings as well as advantages of these models in terms of debugging and maintenance.
Software debugging is considered to be one of the salient phases of software engineering. Since this is a common phenomenon that each human being makes some mistakes at different stages of life, man-made software should not be considered as reliable unless it is thoroughly tested and verified. Testing these anomalies thus is an important part of software System. After development phase of software, testing and debugging should be taken from oracle end. Without these steps, we cannot provide better quality software in today's fast track based world.
Any step of a program performing an intended operation or in an unanticipated way is termed to be a fault. More are the number of faults more will be the development cost of the project. There are different types of faults, some them include System faults, Business Logic faults, Functional faults, Graphical User Interface faults, Behavior faults, Security faults etc. Handling such faults in the software testing plays a very vital role.
Debugging, i.e., identifying as well as correcting errors or faults from software or any sort of computer programmes, involves three (3) different phases:
(1) Fault detection: to identify erratic or unforeseen behaviour (2) Fault Localization: to identify the origin(s) of the problem.
(3) Repair: to correct the problem by either replacing or modifying the existing code(s) or part(s) of the programme identified during the Fault Localization phase.
All faults may originate during the software development phase and these faults are then corrected through debugging models at designing level and implementation phase. According to oracle’s point of view, buggy system produces faulty output with some input/output mixtures of circuits in the sense of software languages. From a software engineering viewpoint, software faults can influence overall project cost, which increases cost after detecting bugs or faults of software development phase for software engineers. So primary goal of every software engineer is to detect, locate and localize faults from software system in the early stages of development phase. This effort reduces cost of maintenance and development of software system. This is the exact point where software debugging is involved.
The paper is organized as follows: we discuss software anomalies and faults classifications in Section 2. The Model based diagnosis technique is presented in Section 3. In Section 4, we present both models and discussions. In Section 5, we present related research.
In the IEEE Standard Glossary of Software Engineering [1], the phrase software anomaly describes various issues of software life cycle. The anomalies provide standard method of the classification and appellation. When we discuss about the locating or finding and localizing a bug or an error from a computer program, generally we use both terms an error or a bug.
According to the IEEE standard classification of software anomalies [1], Anomaly can be interpreted as deviations observed either in documentation or in functionality of any software from previously verified ones or from even reference models.
The above definition is not bound where the presumption comes from. Below are some words are presenting impressions of anomalies: System activity explains proper way of organized activity for an anomaly was recognized. Some possible listings are coding, analysis, testing and support.
System life cycle explains to detect the anomaly in phase. Frame work exists that allow to predict the effect of an anomaly with respect to system life cycle phase it was detested in. Some possible categories are implementation, design, testing, maintenance and accuracy but some other subcategories are involved.
Suspected problem provides unmannered ranking of analogies into the main components of a System. This includes final product itself and final outcome, the analysis and test system, and second partial party products.
System describes that how respond the anomaly. Operating system crash, program crash, output problem and input problem are the some specified categories with other subcategories.
Project accuracy defined that accuracy of system within anomaly is exists. A qualitative assessment of correctness, or freedom from error. A quantitative measure of the magnitude of error from whole system. Project must be accurate with testing and verification after implementation of project.
Product status is used to classify how anomaly affect the final product and is dignified between affected, unaffected, usable and drag-gable.
The categories of software anomalies are not limited to software and hardware faults. According to the IEEE standard classification they cover all types of anomalies. In our thesis we are only interested in software anomalies. Which are intentionally connected to the faults of the software system. Here we present some precise definitions according to the IEEE standard Glossary of Software Engineering [1], these are commonly us
This content is AI-processed based on open access ArXiv data.
