Aspect-Oriented Programming evaluated: A Study on the Impact that Aspect-Oriented Programming can have on Software Development Productivity

Text Sample: Chapter 3.1.3, Empirical research in Software Engineering - Specifics and Dangers: As stated above, software development is still a process dominated by human creativity and brains. Its mechanisms therefore do still elude a complete understanding and are very hard to measure and capture through observation and data collection. As Prechelt has written in his book, there are many specifics of empirical research and controlled experiments to be considered in software engineering. He states that for many controlled experiments, the most important variable to control is the variation among all participants' approaches and performance on a problem (which is an especially big variation for programming or modeling tasks). The wide range of experience with modeling, programming, programming languages and development tools between software developers, which is the very nature of software development and still eludes any quantitative way of measuring it, makes the results of empirical experiments generally hard to predict or interpret. Empirical research in software engineering is still at its beginning and researchers are still far from being able to handle and control these variations in a way that would make them able to produce very reliable results in most situations. These are some of the reasons why computer scientists tend to stay away from empirical research (Tichy summarizes 16 excuses used most to avoid experimentation in software engineering in his paper that was already cited above: (Tichy, 1997)). Even the object-oriented approach, which is currently the most used in industry and academics, has not been validated thoroughly. Some even argue that there are still problems in the idea of object-orientation. 3.2, Aspect-Oriented Programming: 3.2.1, Aspect-Orientation in General: Object-oriented Programming has had an amazing triumphal procession in the past years, both in the academic world as well as in the industrial development practice. It still has its drawbacks and is sometimes not sufficient for solving a specific set of problems. In 1997, Kiczales and his colleagues published the paper (Kiczales, et al., 1997) which introduced aspect-oriented programming as a modified approach on solving specific problems in software development. The idea was that certain functional parts of software crosscut an application or at least large parts of it (like logging, which is the most worn example for aspect-orientation, tracing, security, synchronization or other functions). Today, these specific functions are commonly called crosscutting concerns. Using the object-oriented approach, developers had a hard time implementing these crosscutting concerns seamlessly into their programs, because their nature prevented a clean separation of concerns and ultimately lead to tangled and difficult to read code (imagine an example where each method call that had to be logged for debugging purposes needed a separate logging statement which had to be inserted manually into the code). This code was also very tough to maintain and change, as the calls to these functions were scattered across the rest of the code and one central code change to solve the problem (which is usually one of the main benefits of object-orientation, the encapsulation of functionality) was not possible. All these drawbacks lead to the idea of aspect-oriented programming, where the so called aspects replace the tangled and scattered fragments in the old code by one central isolated point, effectively modularizing the crosscutting concern in the code. For the logging example, this aspect could be given the task of calling the logging functionality (which might be a method of a class providing this function) on all occasions the developer wants it to. This makes it easy for the developer to have every single method call in the program be logged without having to insert logging statements into the code to log itself.