As the use of AspectJ grows, it seems appropriate to define refactorings for that language. Most of the already defined aspect-oriented refactorings do not have a formal basis to ensure it preserves behaviour. This paper shows the application of programming laws and derived refactorings to separate a crosscutting concern from a system’s core logic using AspectJ. We used programming laws to incr...

Most of the methods for concern modularity analysis rely on the exploration of crosscutting concerns directly in source code artifacts. However, as both the code size and the number of concerns increase, analyses of concern properties become an even more cumbersome and time-consuming task. In this paper, we propose a visual representation of crosscutting concerns using a software visualization ...

Originally in Proceedings of Workshop Aspektorientierte Softwareentwicklung der GI-Fachgruppe 2.1.9 Objektorientierte Software-Entwicklung (Second Workshop on Aspect-Oriented Software Development). Bonn (Germany), February 21-22, 2002. Also in Pascal Costanza, Günter Kniesel, Katharina Mehner, Elke Pulvermüller and Andreas Speck (eds.), Second Workshop on Aspect-Oriented Software Development, I...

Separation of concerns refers to the ability of identifying, encapsulating and manipulating parts of software that are crucial to a particular purpose (Dijkstra, 1976). Traditional software development methods were developed with this principle in mind. However, certain broadly-scoped properties are difficult to modularize and keep separated during the lifecycle, producing tangled representatio...

Embedded systems have several characteristics, such as application specific needs, real-time constraints and intrinsic embedded concerns (i.e. energy consumption), which hinder the reuse of previously developed components as well as their adaptation to provide variability in a software product line. As more applications require embedded system solutions, it is clear that if each time a new appl...

Much of the complexity of software architecture design is derived from the inadequate modularization of key broadly-scoped concerns, such as exception handling, distribution, and persistence. However, conventional architecture metrics are not sensitive to the driving architectural concerns, thereby leading a number of false positives and false negatives in the design assessment process. Therefo...

This paper presents a high-level, visual Service Creation Environment (SCE) for web services. The SCE introduces two main concepts: services and composition templates. Composition templates are abstract descriptions of reusable compositions containing several placeholders for services. Services are verified to be compatible with the composition template when a service is mapped onto a compositi...

In this paper we argue that the explicit capture of crosscutting concerns in code should be the natural consequence of good and clean modularity in analysis and design, based on fine-grained (multidimensional) functional decomposition, and not the result of a corrective measure due to a tangled implementation. Aspect-Oriented Software Development (AOSD) is an emerging paradigm that builds on th...

ControllerIControllerPhotoController CoreController SMSController Chain of Responsibility Application DomainProperties Figure 2-3: Distribution Map showing the Chain of Responsibility property Based on this representation of the system, four concern metrics were proposed byDucasse, Girba, and Kuhn [41], namely Size, Touch, Spread, and Focus. The Sizemetric counts the number ...

By designing systems as sets of modules that can be composed into larger applications, developers unleash a multitude of advantages. The promise of AOP (Aspect-Oriented Programming) is to enable developers to organize crosscutting concerns into separate units of modularity making it easier to accomplish this vision. However, AOP does not allow unit tests to be untangled, which impairs the devel...