Section 22.1. THE TOOLS STUDIED


22.1. THE TOOLS STUDIED

22.1.1. AspectBrowser

AspectBrowser assists in the discovery, exploration, and management of crosscutting concerns (aspects). A user identifies a concern by specifying a lexical regular expression that is then matched across the program text. Multiple concern specifications can be built up and visualized simultaneously in a global view [10, 15, 16]. As Figure 22-1 shows, AspectBrowser displays all of the files searched and the concerns found in a Seesoft-like view [8]. The files are displayed in a row of windows, where one row of pixels is equal to one line of source code. Each concern pattern is associated with a color, which is used to highlight each match in the view, visually distinguishing it from other displayed pattern matches. AspectBrowser integrates with the Emacs editor, allowing a developer to navigate to code in an editor: The same color is used to highlight code related to a concern in both AspectBrowser and Emacs. The use of lexical pattern matching permits analysis and visualization independent of programming language.

Figure 22-1. The main view of AspectBrowser. At the left is a hierarchical list of concern patterns. To the right is the concern visualization of one or more directories in the program. Above are operation shortcuts and thumbnail "Atlas tabs" for convenient, visually informed navigation around the system. An Emacs editor is open, showing the highlighting (by color) of the aspects in the text.


To help orient the programmer and to manage scale, AspectBrowser uses a map metaphor. Like symbols on a map, the large-scaled view of multiple files in AspectBrowser shows the dispersal of the highlighted concerns across the program text. The proximity of two different highlighted concerns may indicate a plausible relationship between the two aspects. Similar to an interactive map, AspectBrowser views can be customized; for example, the highlighting of a concern can be selectively disabled, or files with no matches can be folded to reduce clutter. AspectBrowser also provides mechanisms to help a programmer remain oriented while immersed in a complex task, including a "you are here" cursor and traversal through all the matches of a concern.

To use AspectBrowser, a programmer launches the tool and specifies a project to be loaded. The project file may have been saved from a previous session, in which case it would include previously defined concern patterns. Based on the task at hand and any prior knowledge of the system, the programmer identifies a concern in the code by postulating a lexical pattern for it (typed into the window above the concern list). The programmer might then click on one or more of the new highlights to bring up the editor to see the code around the matches and how it relates to any previous concern patterns. If necessary, the concern pattern might be refined, or additional concern patterns might be added. To visit all of the code matched by one or more concern patterns, the programmer chooses concerns to navigate from the drop-down box above the main view and then traverses the matches with the arrow buttons to bring up the editor at each match. Such a traversal might be used to make a change at every match (e.g., a variable rename) or to verify that some property holds for the code at every match (e.g., non-interference with another concern).

22.1.2. AMT

The Aspect Mining Tool (AMT) supports a hybrid approach to concern mining in existing Java or AspectJ [2, 13] software, combining interactive lexical and structural searches over the source code [11, 12]. The lexical searching facility supports pattern and substring matching; the structural searches match type usages in the target code. These two types of searching can be used in combination, such as looking for all creations of a particular object by combining a lexical search for "new" with a type search for the object's type.

Similar to the AspectBrowser, AMT employs a Seesoft-like view, providing the developer with a graphical representation of the code base and the search matches (see Figure 22-2). Each search item can have a different color associated with it. Classes not matching any of the items in a search can be either grayed out or hidden. Since the Seesoft view is a "flat" representation of the system, showing the results only in terms of source files, the tool also offers a tree representation of the class and package hierarchies.

Figure 22-2. The Aspect Mining Tool. The main window (class representations) shows classes in the workspace, highlighting lines that match the searches (defined in the lower left) with the appropriate colors. Browsable class and pattern hierarchies are shown in the lower right.


AMT allows the developer to specify the workspace, the collection of files to consider when searching and displaying results. The workspace enables a developer to concentrate on particular parts of a system. The workspace can be formed in two ways: classes or parts of hierarchies can be added using the hierarchical view, or all classes matching a search can be set as the workspace (e.g., all classes matching the lexical token "@author M. Murphy" or all classes containing some usage of the type EventLogger). In addition, classes can be removed from the workspace via the Seesoft-like view.

When using AMT, a developer typically first tries to find a good approximation of the workspace and then successively refines the workspace to better fit his or her needs. Then the developer finds a starting point for the concern elaboration task at hand with a lexical search, a structural search, or a combination of both. From there, the developer can perform successive searches to identify the concern extent. The developer can investigate the results of a search with a file viewer built into AMT or an external editor.

22.1.3. FEAT

FEAT supports the identification and description of a concern in Java code based on structural queries [22, 23]. Using FEAT, a developer starts with a minimal representation of a concern, or seed, and then explores the dependencies to that seed to determine related concern code. When related concern code is found, the developer can add a representation of the concern code to the concern description.

FEAT displays a tree representation of the code that has been identified as contributing to a concern (see Figure 22-3). At the top level, a concern is a collection of classes. Each class can be considered as either being entirely (e.g., class ChangeAttributeCommand) or partly involved in the concern (e.g., class AttributeFigure). If the latter, FEAT lists which elements of the classfields and methods (either part or whole)are included. For parts of method bodies, FEAT represents each code element of a concern with an <action, target> tuple. The action is one of five items: reads (a field), writes (a field), calls (a method), creates (an object), and checks (the type of an object). The target is the field, method, or class upon which the action is performed. For example, in Figure 22-3, the concern described includes calls to method execute of class ChangeAttributeCommand in method actionPerformed of class CommandMenu.

Figure 22-3. The FEAT tool. The larger window contains the program elements contributing to the Setting figure attributes concern determined to this point. The smaller window shows the result of a query performed on one of the concern program elements. Any of these query results can be added to the concern, a view of the element in the source can be accessed, or further queries can be run.


From this view, a developer can run structural queries to see whether related elements can also be part of the concern under investigation:

  • Get superclass returns the superclass of the selected class.

  • Expand class returns all of the members declared by the selected class.

  • Grab returns the target element in a code abstraction element. For example, in <reads, C.f>, this command would return the field f of class C.

  • Fan-in returns all of the elements in a program that depend upon the class, field, or method node that is selected. This query takes into account potential dynamic bindings for method calls and returns conservative estimates.

  • Fan-out returns all of the different code abstractions for the selected method.

  • Transitive fan-out returns all of the code elements that the selected method transitively depends upon, including fields, methods, and classes.

The result of one of these queries is a set of program elements presented in a tree structure (see the small window in Figure 22-3). From any window in FEAT, a user can view the source code corresponding to an element, choose to move an element to the concern description, compare the elements to the current concern description, or perform another query based on an element. For example, after viewing the source code for method getAttribute of class AttributeFigure (in the result window), a user might decide that this method is relevant to the concern and may move this method to the main concern window. A developer continues the investigation until the developer is satisfied with the concern description formed.



Aspect-Oriented Software Development
Aspect-Oriented Software Development with Use Cases
ISBN: 0321268881
EAN: 2147483647
Year: 2003
Pages: 307

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net