Aspect-Oriented Programming evaluated: A Study on the Impact that Aspect-Oriented Programming can have on Software Development Productivity
:
Sebastian Kleinschmager
:
Aspect-Oriented Programming evaluated: A Study on the Impact that Aspect-Oriented Programming can have on Software Development Productivity
:
Anchor Academic Publishing
:
9783954895397
:
1
:
CHF 31.20
:
:
Datenkommunikation, Netzwerke
:
English
:
95
:
kein Kopierschutz/DRM
:
PC/MAC/eReader/Tablet
:
PDF
Aspect-oriented-programming is a relatively new technique that has evolved on top of the already well-established approach of object-oriented programming. When it is used correctly, it promises to remove many redundant parts of a code that appear repeatedly in an application, essentially untangling the original code. Thus, it can lead to a cleaner, more separated software design, to greater modularity and maintainability. Time-savings in software engineering can also be huge cost-savings, and anything that increases software quality is a welcome sight in an industry that in parts, still suffers from a bad reputation concerning the quality of its products. But, used in the wrong way or with insufficient knowledge, aspect-oriented programming can result in the opposite. Unintended side effects may introduce new bugs into an application, and therefore, it may be just one of the many negative consequences. In any case, there is a huge lack of empirical research on the subject, and in software engineering in general. Due to that fact, the question arises in how far hard facts can be drawn. This book deals with part of that problem by evaluating the aspect-oriented approach in a carefully designed and controlled experiment. On the basis of different tasks that were solved by participants of this study, the aspect-oriented approach (represented by AspectJ) is compared with a plain object-oriented approach (represented by Java). The book starts with an introduction to the topic, and further, it provides on the one hand, the survey's motivation and on the other hand, some background information. A short chapter on aspect-oriented programming and empirical research may help readers who are unfamiliar with any of the subjects. Then, the survey itself is described in detail, i.e. its design, its implementation, and its evaluation, followed by a thorough discussion of the results. And the answer to the question 'Can aspect-orientated programming keep its promise in productivity?' is given.
Sebastian Kleinschmager is a software engineer, trainer and consultant from Germany.
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.
Aspect-Oriented Programming evaluated: A Study on the Impact that Aspect-Oriented Programming can have on Software Development Productivity
1
Abstract
3
Directory of Figures
4
Directory of Tables
6
Directory of Listings
8
Table of Contents
9
1. Introduction
11
2. Motivation and Problem Description
12
3. Experiment Background
15
3.1. A short summary on Empiricism and Experimentation
15
3.1.1. What is meant by Empiricism?
15
3.1.2. Research and Experimentation methods
15
3.1.2.1. Case Studies or Benchmarks
16
3.1.2.2. Field Studies
16
3.1.2.3. Controlled Experiments
16
3.1.2.4. Polls
17
3.1.2.5. Meta-Studies
17
3.1.3. Empirical research in Software Engineering – Specifics and Dangers
17
3.2. Aspect-Oriented Programming
18
3.2.1. Aspect-Orientation in General
18
3.2.2. AspectJ – a short Introduction
19
4. The Experiment
21
4.1. Experiment Buildup
21
4.1.1. The planned Course of the Experiment
21
4.1.2. The Questionnaire
21
4.1.3. The Hard- and Software used in the Experiment
22
4.1.3.1. The Application used for Editing
22
4.1.3.2. The Development Environment and Hardware
23
4.1.4. The Tasks
23
4.1.4.1. Task1: The Logging Task
24
4.1.4.2. Task2: The Parameter Null Task
25
4.1.4.3. Task3: The Synchronization Task
26
4.1.4.4. Task4: The Check Player Argument Task
27
4.1.4.5. Task5: The Notify Observers Task
28
4.1.4.6. Task6: The Observers Null Check Task
29
4.1.4.7. Task7: The Refresh Constraint Task
30
4.1.4.8. Task8: The Label Value Check Task
31
4.1.4.9. Task9: The Current Level Check Task
33
4.2. Implementation of the Experiment
34
5. Experiment Analysis and Results
36
5.1. Data Processing and Preparation
36
5.2. Data analysis and presentation
38
5.2.1. The Logging Task
38
5.2.2. The Parameter Null Task
42
5.2.3. The Synchronization Task
43
5.2.4. The Player Check Task
45
5.2.5. The Notify Observers Task
46
5.2.6. The Observers Null Task
46
5.2.7. The Refresh Constraint Task
48
5.2.8. The Label Value Check Task
49
5.2.9. The Level Check Task
50
5.2.10. Results of the Development Times and Descriptive Statistics
51
5.2.11. Statistical Tests on the Results
57
5.2.12. Doing a Break-Even Analysis
62
5.2.13. Participant Grouping
66
6. Discussion
76
6.1. Thoughts on Validity
76
6.1.1. Internal Validity
76
6.2. General Discussion
78
7. Related Work
81
8. Conclusion
83
9. Appendix
84
9.1. The questionnaire (German)
84
9.2. The aspect-oriented task descriptions (German)
85
10. References
94
