Presenting crosscutting structure with active models

Coelho, Wesley; Murphy, Gail C.

doi:10.1145/1119655.1119677

Cited by 12 publications

(14 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…As .mse is the standard file format for Moose data interchange, there are multiple tools available that produce a .mse file from a Java source directory. One option is inFusion tool by intooitus 5 , a second possibility to generate such files is to use VerveineJ 6 . AspectMaps has support for inFusion (limited to UNIX/MacOSX): it can use this tool to generate the .mse file on the fly when importing, thus streamlining the process.…”

Section: Generating Import Files For Aspectmapsmentioning

confidence: 99%

See 1 more Smart Citation

AspectMaps: Extending Moose to visualize AOP software

Fabry¹,

Kellens²,

Denier³

et al. 2014

Science of Computer Programming

View full text Add to dashboard Cite

When using Aspect-Oriented programming the application implicitly invokes the functionality contained in the aspects. Consequently program comprehension of such software is more intricate. To alleviate this difficulty we developed the AspectMaps visualization and tool. AspectMaps extends the Moose program comprehension and reverse engineering platform with support for aspects, and is implemented using facilities provided by Moose. In this paper we present the AspectMaps tool, and show how it can be used by performing an exploration of a fairly large aspectoriented application. We then show how we extended the FAMIX meta-model family that underpins Moose to also provide support for aspects. This extension is called ASPIX, and thanks to this enhancement Moose can now also treat aspect-oriented software. Lastly, we report on our experiences using some of the tools in Moose; Mondrian to implement the visualization, and Glamour to build the user interface. We discuss how we were able to implement a sizable visualization tool using them and how we were able to deal with some of their limitations.Note: This paper uses colors extensively. Please use a color version to better understand the ideas presented here.

show abstract

Section: Generating Import Files For Aspectmapsmentioning

confidence: 99%

“…Coelho and Murphy have introduced the ActiveAspects tool [6]. This tool uses an extension of UML to represent aspects, method execution advice and method call advice.…”

Section: Related Workmentioning

confidence: 99%

AspectMaps: Extending Moose to visualize AOP software

Fabry¹,

Kellens²,

Denier³

et al. 2014

Science of Computer Programming

View full text Add to dashboard Cite

show abstract

“…Comparison between different AOP debuggers from the perspective of supporting the identified tasks used as auxiliary approaches to understand program behavior or structure during debugging. Common IDE tools for AOP languages, like the AspectJ Development Tools (AJDT) 8 , CaesarJ [2] Development Tools (CJDT) 9 , JAsCo [20] Development Tools (JAsCoDT) 10 etc., require using the Java debugger. Thus, abstractions inspected during debugging are Java abstractions resulting from the weaving compilation.…”

Section: Debuggers For Aspect-oriented Languagesmentioning

confidence: 99%

“…It is especially effective in navigating large-scale AO programs. Coelho and Murphy [9] implemented ActiveAspect which can present a subset of the crosscutting structure at the right time, thus decreasing the complexity of information to be analyzed. These systems aid language users to comprehend programs by simplifying the presentation of the crosscutting structure.…”

Section: Debuggers For Aspect-oriented Languagesmentioning

confidence: 99%

A fine-grained debugger for aspect-oriented programming

Yin

Bockisch

Akşit

2012

Proceedings of the 11th Annual International Conference on Aspect-Oriented Software Development

View full text Add to dashboard Cite

To increase modularity, aspect-oriented programming provides a mechanism based on implicit invocation: An aspect can influence runtime behavior of other modules without the need that these modules refer to the aspect. Recent studies show that a significant part of reported bugs in aspectoriented programs are caused exactly by this implicitness. These bugs are difficult to detect because aspect-oriented source code elements and their locations are transformed or even lost after compilation. We investigate four dedicated fault models and identify ten tasks that a debugger should be able to perform for detecting aspect-orientation-specific faults. We show that existing debuggers are not powerful enough to support all identified tasks because the aspectoriented abstractions are lost after compilation. This paper describes the design and implementation of a debugger for aspect-oriented languages using a dedicated intermediate representation preserving the abstraction level of aspect-oriented source code. We define a debugging model which is aware of aspect-oriented concepts. Based on the model, we implement a user interface with functionalities supporting the identified tasks, like visualizing pointcut evaluation and program composition.

show abstract

“…The authors assess their tool as being beneficial for obtaining a high-level overview of aspect application, and state that it is scalable up to on average 2100 classes. Coelho and Murphy propose ActiveAspect [24], a tool that shows an automatically selected subset of the elements in the code, depending on the current focus of the developer. They extend UML with a representation of aspects, method execution advice and method call advice.…”

Section: Related Workmentioning

confidence: 99%

Visually Supporting Source Code Changes Integration: The Torch Dashboard

Gomez

Ducasse²,

D'Hondt

2010

2010 17th Working Conference on Reverse Engineering

View full text Add to dashboard Cite

Abstract-Automatic and advanced merging algorithms help programmers to merge their modifications in main development repositories. However, there is little support to help release masters (integrators) to take decisions about the integration of published merged changes into the system release. Most of the time, the release master has to read all the changed code, check the diffs to build an idea of a change, and read unchanged code to understand the context of some changes. Such a task can be overwhelming. In this paper we present a dashboard to support integrators getting an overview of proposed changes in the context of object-oriented programming. Our approach named Torch characterizes changes based on structural information, authors and symbolic information. It mixes textbased diff information with visual representation and metrics characterizing the changes. We describe our experiment applying it to Pharo, a large open-source system, and report on the evaluation of our approach by release masters of several opensource projects.This paper makes heavy use of colors. Please read a colored version of this paper to better understand the presented ideas. I. SUPPORTING CHANGE INTEGRATIONIntegrating changes that represent fixes, enhancements or new features are key software development activities. Still there is no adequate support to help integrators. Current state of the art are mostly textual diff tools, and there is one diff tool based on ASTs. In particular, integrators do not get an overview of the changes (how changes are distributed, what groups of entities changed) and at the same time the possibility to understand detailed changes within their specific context. Figure 1 shows the conceptual process of changes integration as it can be found in open-source projects. Here we focus on the groups of developers that support the production of a new release. From this perspective and ignoring issues related to testing (acceptation testing and others), we can identify two roles: committers of changes and integrators of such changes.• committers checkout code from a public released version -but it could be from another alpha or beta version of the current development. They commit their changes (fixes, enhancements) in a conceptual repository 1 .• integrators integrate the code of committers by merging the changes made to previous versions into the current (and future released) version. [11]. Several tools such as Envy [12] take into account the underlying meta-model as a step towards a semantic merge. Still, integrating changes is a difficult task. Indeed, integrating a change requires not only the merging of source code but also an understanding of the changes and their context, and its potential impact on the system. This can be more complex than doing the actual merge and there is a clear lack of support. In this paper, we present Torch, a dashboard displaying object-oriented 2 changes using different visualizations and change summaries. In particular, Torch provides several change overviews based on packages ...

show abstract

Presenting crosscutting structure with active models

Cited by 12 publications

References 20 publications

AspectMaps: Extending Moose to visualize AOP software

AspectMaps: Extending Moose to visualize AOP software

A fine-grained debugger for aspect-oriented programming

Visually Supporting Source Code Changes Integration: The Torch Dashboard

Contact Info

Product

Resources

About