Metamodel for Tracing Concerns across the Life Cycle

Several aspect-oriented approaches have been proposed to specify aspects at different phases in the software life cycle. Aspects can appear within a phase, be refined or mapped to other aspects in later phases, or even disappear.\ud Tracing aspects is necessary to support understandability and maintainability of software systems. Although several approaches have been introduced to address traceability of aspects, two important limitations can be observed. First, tracing is not yet tackled for the entire life cycle. Second, the traceability model that is applied usually refers to elements of specific aspect languages, thereby limiting the reusability of the adopted traceability model.We propose the concern traceability metamodel (CTM) that enables traceability of concerns throughout the life cycle, and which is independent from the aspect languages that are used. CTM can be enhanced to provide additional properties for tracing, and be instantiated to define\ud customized traceability models with respect to the required aspect languages. We have implemented CTM in the tool M-Trace, that uses XML-based representations of the models and XQuery queries to represent tracing information. CTM and M-Trace are illustrated for a Concurrent Versioning System to trace aspects from the requirements level to architecture design level and the implementation

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

Early aspects: aspect-oriented requirements engineering and architecture design

This paper reports on the third Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design Workshop, which has been held in Lancaster, UK, on March 21, 2004. The workshop included a presentation session and working sessions in which the particular topics on early aspects were discussed. The primary goal of the workshop was to focus on challenges to defining methodical software development processes for aspects from early on in the software life cycle and explore the potential of proposed methods and techniques to scale up to industrial applications

Four approaches to teaching programming

Based on a survey of literature, four different approaches to teaching introductory programming are identified and described. Examples of the practice of each approach are identified representing procedural, visual, and object-oriented programming language paradigms. Each approach is then further analysed, identifying advantages and disadvantages for the student and the teacher. The first approach, code analysis, is analogous to reading before writing, that is, recognising the parts and what they mean. It requires learners to analyse and understand existing code prior to producing their own. An alternative is the building blocks approach, analogous to learning vocabulary, nouns and verbs, before constructing sentences. A third approach is identified as simple units in which learners master solutions to small problems before applying the learned logic to more complex problems. The final approach, full systems, is analogous to learning a foreign language by immersion whereby learners design a solution to a non-trivial problem and the programming concepts and language constructs are introduced only when the solution to the problem requires their application. The conclusion asserts that competency in programming cannot be achieved without mastering each of the approaches, at least to some extent. Use of the approaches in combination could provide novice programmers with the opportunities to acquire a full range of knowledge, understanding, and skills. Several orders for presenting the approaches in the classroom are proposed and analysed reflecting the needs of the learners and teachers. Further research is needed to better understand these and other approaches to teaching programming, not in terms of learner outcomes, but in terms of teachers’ actions and techniques employed to facilitate the construction of new knowledge by the learners. Effective classroom teaching practices could be informed by further investigations into the effect on progression of different toolset choices and combinations of teaching approache

Improving NDT with Automatic Test Case Generation

The model-driven development defi nes the software development process as a set of iterations to create models and a set of transformations to obtain new models. From this point of view, this paper presents the enhancement of a model- driven approach, called navigational development techniques (NDT), by means of new models and transformations in order to generate test cases. It also states some conclusions from the research work and practical cases in which this approach was used.Ministerio de Ciencia e Innovación TIN2010-20057-C03-02Ministerio de Ciencia e Innovación TIN 2010-12312-