Visualisation-based tool support for the development of aspect-oriented programs

Pfeiffer, Jérôme; Gurd, John R.

doi:10.1145/1119655.1119676

Cited by 12 publications

(11 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Pfeiffer and Gurd [22] propose Asbro, a visualization tool based on Treemaps. A Treemap maps the nodes of a tree to rectangles in a plane, using a space-filling layout.…”

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

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

“…Pfeiffer and Gurd [22] propose Asbro, a visualization tool based on Treemaps. A Treemap maps the nodes of a tree to rectangles in a plane, using a space-filling layout.…”

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

“…For example in listing 1 the pointcut designator target(b) is transformed to two LIAM entities because it plays two roles: It specifies a dynamic condition under which the pointcut matches a join point (represented by the AtomicPredicate in lines 4-13, listing 2), as well as a value that is exposed to associated advice (represented by the Context in lines [14][15][16][17]. The pointcut designator, and thus also the atomic predicate, additionally depends on the declaration of the formal advice parameter Base b: The callee object must be an instance of type Base.…”

Section: Xml-based Liam Modelmentioning

confidence: 99%

“…Pfeiffer and Gurd [17] introduced a treemap-based visualization, called Asbro. Asbro uses colored and nested rectangles to present the hierarchy as well as the crosscutting structure.…”

Section: Debuggers For Aspect-oriented Languagesmentioning

confidence: 99%

See 1 more Smart Citation

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

“…However they use a textual tree-based representation to show the data which limits the overview aspects. Pfeiffer and Gurd [23] propose a tool which provides a tree map visualization of where aspects apply in packages and types. Rectangles representing classes or packages are colored with an aspect color if an aspect applies there.…”

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

Visualisation-based tool support for the development of aspect-oriented programs

Cited by 12 publications

References 18 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