Art of Software Testing
Conspectus of software engineering environments
ICSE '81 Proceedings of the 5th international conference on Software engineering
The why and wherefore of the Cornell Program Synthesizer
Proceedings of the ACM SIGPLAN SIGOA symposium on Text manipulation
New assertion concepts for self-metric software validation
Proceedings of the international conference on Reliable software
ACM SIGPLAN Notices
Ada debugging and testing support environments
SIGPLAN '80 Proceedings of the ACM-SIGPLAN symposium on Ada programming language
An analysis of software development environments
ACM SIGSOFT Software Engineering Notes
Validating a Demonstration Tool for Graphics-Assisted Debugging of Ada Concurrent Programs
IEEE Transactions on Software Engineering
Adding debugging support to the Prometheus methodology
Engineering Applications of Artificial Intelligence
| Hi-index | 0.00 |
Programming environments (PEs) support a single programmer developing small- to medium-scale programs, whereas software development support systems and software engineering environments (SE2s) support whole project teams, developing large-scale software. There is no reason to believe that one and only one support system may exist. The usefulness of one or the other depends on the particular situation of software development. Debugging is distinguished from testing and defined not only for removing bugs from programs (dynamic debugging) but also from documents describing the programs (static debugging). The key problem of debugging is understanding the software. Debugging may be supported by static analysis tools and by interactive debugging systems which help both to understand the software better and to estimate the impacts of an intended change. Graphical representations are also very useful for better understanding system structures and for recognizing faults and clashes faster. Tools may furthermore be used to report errors and corrections, and to maintain these reports. In the context of PEs and SE2s the tools supporting debugging are connected. Tools can be based on a uniform internal representation, allowing a uniform user interface. Tasks and corresponding tools can be tailored to each other, avoiding duplication of work. One task knows what the others have already done. One knows if certain types of errors have been prevented or removed, i.e. if static analysis tools prevent data flow errors during runtime. Tools and results of other tasks may be used, i.e. cross reference lists and test path reports. Similarities and differences of debugging in PEs and in SE2s are discussed by some example systems. The discussion is concluded by demonstrating possible influences on future software development by personal computers, knowledge engineering, and predicative programming.