2,395 research outputs found
Real world evaluation of aspect-oriented software development : a thesis submitted in partial fulfilment of the requirements for the degree of Master of Science in Computer Science at Massey University, Palmerston North, New Zealand
Software development has improved over the past decade with the rise in the popularity of the Object-Oriented (OO) development approach. However, software projects continue to grow in complexity and continue to have alarmingly low rates of success. Aspect-Oriented Programming (AOP) is touted to be one solution to this software development problem. It shows promise of reducing programming complexity, making software more flexible and more amenable to change. The central concept introduced by AOP is the aspect. An aspect is used to modularise crosscutting concerns in a similar fashion to the way classes modularise business concerns. A crosscutting concern cannot be modularised in approaches such as OO because the code to realise the concern must be spread throughout the module (e.g. a tracing concent is implemented by adding code to every method in a system). AOP also introduces join points, pointcuts, and advice which are used with aspects to capture crosscutting concerns so they can be localised in a modular unit. OO took approximately 20 years to become a mainstream development approach. AOP was only invented in 1997. This project considers whether AOP is ready for commercial adoption. This requires analysis of the AOP implementations available, tool support, design processes, testing tools, standards, and support infrastructure. Only when AOP is evaluated across all these criteria can it be established whether it is ready to be used in commercial projects. Moreover, if companies are to invest time and money into adopting AOP, they must be aware of the benefits and risks associated with its adoption. This project attempts to quantify the potential benefits in adopting AOP, as well as identifying areas of risk. SolNet Solutions Ltd, an Information Technology (IT) company in Wellington, New Zealand, is used in this study as a target environment for integration of aspects into a commercial development process. SolNet is in the business of delivering large scale enterprise Java applications. To assist in this process they have developed a Common Services Architecture (CSA) containing components that can be reused to reduce risk and cost to clients. However, the CSA is complicated and SolNet have identified aspects as a potential solution to decrease the complexity. Aspects were found to bring substantial improvement to the Service Layer of SolNet. applications, including substantial reductions in complexity and size. This reduces the cost and time of development, as well as the risk associated with the projects. Moreover, the CSA was used in a more consistent fashion making the system easier to understand and maintain, and several crosscutting concerns were modularised as part of a reusable aspect library which could eventually form part of their CSA. It was found that AOP is approaching commercial readiness. However, more work is needed on defining standards for aspect languages and modelling of design elements. The current solutions in this area are commercially viable, but would greatly benefit from a standardised approach. Aspect systems can be difficult to test and the effect of the weaving process on Java serialisation requires further investigation
Detecting behavioral conflicts among crosscutting concerns
Aspects have been successfully promoted as a means to improve the modularization of software in the presence of crosscutting concerns. Within the Ideals project, aspects have been shown to be valuable for improving the modularization of idioms (see also Chapter 1). The so-called aspect interference problem is considered to be one of the remaining challenges of aspect-oriented software development: aspects may interfere with the behavior of the base code or other aspects. Especially interference among aspects is difficult to prevent, as this may be caused solely by the composition of aspects that behave correctly in isolation. A typical situation where this may occur is when multiple advices are applied at the same, or shared, join point. In this chapter we explain the problem of behavioral conflicts among aspects at shared join points, illustrated by aspects that represent idioms: Parameter checking and Error propagation. We present an approach for the detection of behavioral conflicts that is based on a novel abstraction model for representing the behavior of advice. The approach employs a set of conflict detection rules which can be used to detect both generic conflicts as well as domain or application specific conflicts. One of the benefits of the approach is that it neither requires the application programmers to deal with the conflict models, nor does it require a background in formal methods for the aspect programmers
COBOL to Java and Newspapers Still Get Delivered
This paper is an experience report on migrating an American newspaper
company's business-critical IBM mainframe application to Linux servers by
automatically translating the application's source code from COBOL to Java and
converting the mainframe data store from VSAM KSDS files to an Oracle
relational database. The mainframe application had supported daily home
delivery of the newspaper since 1979. It was in need of modernization in order
to increase interoperability and enable future convergence with newer
enterprise systems as well as to reduce operating costs. Testing the modernized
application proved to be the most vexing area of work. This paper explains the
process that was employed to test functional equivalence between the legacy and
modernized applications, the main testing challenges, and lessons learned after
having operated and maintained the modernized application in production over
the last eight months. The goal of delivering a functionally equivalent system
was achieved, but problems remained to be solved related to new feature
development, business domain knowledge transfer, and recruiting new software
engineers to work on the modernized application.Comment: 4 pages, Accepted to be Published in: Proceedings of the 2018 IEEE
International Conference on Software Maintenance and Evolution (ICSME),
September 23-29, 2018, Madrid, Spai
Software that Learns from its Own Failures
All non-trivial software systems suffer from unanticipated production
failures. However, those systems are passive with respect to failures and do
not take advantage of them in order to improve their future behavior: they
simply wait for them to happen and trigger hard-coded failure recovery
strategies. Instead, I propose a new paradigm in which software systems learn
from their own failures. By using an advanced monitoring system they have a
constant awareness of their own state and health. They are designed in order to
automatically explore alternative recovery strategies inferred from past
successful and failed executions. Their recovery capabilities are assessed by
self-injection of controlled failures; this process produces knowledge in
prevision of future unanticipated failures
Rcpp: Seamless R and C++ Integration
The Rcpp package simplifies integrating C++ code with R. It provides a consistent C++ class hierarchy that maps various types of R objects (vectors, matrices, functions, environments, . . . ) to dedicated C++ classes. Object interchange between R and C++ is managed by simple, flexible and extensible concepts which include broad support for C++ Standard Template Library idioms. C++ code can both be compiled, linked and loaded on the fly, or added via packages. Flexible error and exception code handling is provided. Rcpp substantially lowers the barrier for programmers wanting to combine C++ code with R.
What to Fix? Distinguishing between design and non-design rules in automated tools
Technical debt---design shortcuts taken to optimize for delivery speed---is a
critical part of long-term software costs. Consequently, automatically
detecting technical debt is a high priority for software practitioners.
Software quality tool vendors have responded to this need by positioning their
tools to detect and manage technical debt. While these tools bundle a number of
rules, it is hard for users to understand which rules identify design issues,
as opposed to syntactic quality. This is important, since previous studies have
revealed the most significant technical debt is related to design issues. Other
research has focused on comparing these tools on open source projects, but
these comparisons have not looked at whether the rules were relevant to design.
We conducted an empirical study using a structured categorization approach, and
manually classify 466 software quality rules from three industry tools---CAST,
SonarQube, and NDepend. We found that most of these rules were easily labeled
as either not design (55%) or design (19%). The remainder (26%) resulted in
disagreements among the labelers. Our results are a first step in formalizing a
definition of a design rule, in order to support automatic detection.Comment: Long version of accepted short paper at International Conference on
Software Architecture 2017 (Gothenburg, SE
- …