UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Fluid AOP : task-specific modularity Hon, Terry 2007

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Notice for Google Chrome users:
If you are having trouble viewing or searching the PDF with Google Chrome, please download it here instead.

Item Metadata


831-ubc_2007-0116a.pdf [ 2.7MB ]
JSON: 831-1.0052012.json
JSON-LD: 831-1.0052012-ld.json
RDF/XML (Pretty): 831-1.0052012-rdf.xml
RDF/JSON: 831-1.0052012-rdf.json
Turtle: 831-1.0052012-turtle.txt
N-Triples: 831-1.0052012-rdf-ntriples.txt
Original Record: 831-1.0052012-source.json
Full Text

Full Text

Fluid A O P Task-specific M o d u l a r i t y by Terry Hon B . S c , The University of British Columbia, 2004 A THESIS S U B M I T T E D IN P A R T I A L F U L F I L M E N T O F T H E R E Q U I R E M E N T S F O R T H E D E G R E E O F Master of Science in The Faculty of Graduate Studies (Computer Science) The University Of British Columbia March, 2007 © Terry Hon 2007 Abstract Most aspect-oriented programming technology used today uses a linguistic approache that enables programmers to write modular crosscutting code. Two limitations of these approaches are that there is only one decomposition present for a code-base and that they require developers to adopt a new (or extended) programming language. We propose fluid A O P to modularize crosscutting concerns without these limitations. Fluid A O P provides mechanisms in the IDE for creating constructs that localize a software developer's interaction for a specific task. These con-structs act as fluid aspects of the system. They are editable representations of the subset of the code-base that the developer needs to interact with to perform a task. We present three fluid A O P prototypes and provide comparisons between them; as well as comparisons between the fluid AOP, linguistic AOP, and non A O P approaches. ii Table of Contents Abstract ii Table of Contents i ii List of Figures v Acknowledgements vi 1 Introduction 1 1.1 Motivation 1 1.2 Fluid A O P • . 2 1.3 Thesis Statement 3 1.4 Overview 3 2 Related Work 4 2.1 Code Navigation 4 2.2 Linking Code Clones 5 2.3 Alternate Editor or Decomposition 5 3 Three Prototypes in Fluid AOP 8 3.1 Common Features 9 3.1.1 Aspect Editor 9 3.1.2 Pointcuts 10 3.2 Before/After/ITD 10 3.2.1 Advice • • • 11 3.2.2 I T D 12 3.2.3 Multiple Advice or ITDs . . . . . . . . . 14 3.3 Gather : '. 15 3.41 Overlay 17 3.4.1 Variations in Overlay 18 iii Table of Contents 4 J o i n Po in t M o d e l s 20 4.1 Nature of the Join Points 20 4.2 Means of Identifying the Join Points 20 4.3 Means of Semantic Effect at Join Points 20 4.3.1 Before/After/ITD 21 4.3.2 Gather 21 4.3.3 Overlay 21 5 Implementa t ion 22 5.1 Parser 22 5.2 Name binding and Type Checking 23 5.3 Join Point Matcher 23 5.4 Code Preparation and Linking 23 5.4.1 Before/After/ITD 24 5.4.2 Gather 24 5.4.3 Overlay 24 5.4.4 Overlay Groups 25 5.5 Limitations 26 6 A d d i t i o n a l E x a m p l e 27 6.1 Consistency Enforcement 27 7 C o m p a r i s o n 30 7.1 Fluid A O P 30 7.2 Fluid A O P vs. Linguistic A O P 32 7.3 Fluid A O P vs. O O P • 32 8 C o n t r i b u t i o n 33 9 Fu tu re W o r k 35 9.1 Extending the Fluid A O P Space 35 9.2 Improving Current Implementations 35 9.2.1 Overlay Groups 35 9.2.2 More Overlay Features . . • 36 9.2.3 Graphical Aspect Editor 36 9.3 Improving Scalability 37 B i b l i o g r a p h y 38 iv List of Figures 2.1 Screenshot of fluid document presentation 6 2.2 Screenshot of a fluid source code view 6 3.1 Outline view for aspect with overlay 9 3.2 Before/After/ITD prototype screenshot 11 3.3 Point class with display field introduced 13 3.4 Aspect with ITD and after returning advice 14 3.5 Modified Aspect with ITD with annotation inserted 15 3.6 Gather declaration 16 3.7 Overlay declaration 17 3.8 Overlay declaration with parameter renaming 19 5.1 Implementation stages 22 6.1 Undo methods in JHotDraw 28 6.2 The updated overlayed groups for undo methods 29 v Acknowledgements There are many people that have helped me directly and indirectly to get me to this point. F i r s t and foremost I want to thank my supervisor, Gregor Kiczales , for all his guidance and t ime that he has put in my research. Your advice on and off the research has been invaluable to me. Secondly I would like to thank G a i l M u r p h y for being my second reader and for always being there when I have questions. Thanks also to Andrew Eisenberg who gave me advice throughout my research and for being the first to give comments about my thesis draft. I have to also thank M i k Kersten for helping me get started and for always answering a l l my Ecl ipse questions. Thanks to everyone in S P L , especially Ar jun , Thomas, Rainer , R y a n and Bre t t , for all your input in my research and for listening patiently to my countless complaints. I also have to thank Hermie and H o l l y for a l l the help and support for the past couple years. Thanks also to Baharak and Sara for being the good friends that you are and for always urging me to try new things. F i n a l l y I have to especially thank my family, in part icular my parents and my brother for always taking care of me and pushing me to achieve the best that I can. I would not be here without you! vi Chapter 1 Introduction 1.1 M o t i v a t i o n Programmers perform numerous tasks in the code development phase of the software development cycle. These tasks can fall into the following categories:'code evolution, code comprehension and documentation. Recent work in A O P has shown that different concerns in a code-base can crosscut each other's natural structure. The same is true of software development tasks - while they sometimes align with the primary decom-position of the source code (such as when a single sorting method needs to be refined), they sometimes crosscut that structure (such as reconciling the naming convention of one package with another package). This is be-cause the structure of the concern that the task is addressing crosscuts the structure of the overall system. This crosscutting nature causes many of the actions performed during a task to be performed in multiple locations, making the task harder to perform and more prone to error. Throughout this dissertation, we use the term concern to mean a subset of a program that a software developer is interested in at a certain point in time. This concern might correspond to the implementation of a feature or it could be any other kind of slice of the program that a software developer is interested in. We use the term task to refer to a set of actions to modify or understand a part of a concern. These tasks can involve modification of existing programs, creation of alternative realizations, • modifications of existing interfaces [6] as well as navigation to understand code. Finally two concerns are said to crosscut each other with respect to the dominant de-composition of the system if the implementation of the two concerns directly overlay in the primary decomposition, but neither entirely covers the other. Note that we focus only on artefacts in the development phase. There is ongoing research [1, 7, 13, 20] that looks at modularization of crosscutting concerns at the design or architectural level, but we do not address those levels in this research. Most of the approaches which address crosscutting concerns in the de-velopment phase focus on enabling modular crosscutting code. These ap-1 Chapter 1. Introduction proaches use linguistic techniques [18] to make it possible for the implemen-tation of two concerns to be cleanly separated even when those concerns crosscut (with respect to the dominant decomposition). An example of this is the Aspect J [11] extension to Java. Linguistic approaches like Aspect J provide mechanisms that enable soft-ware developers to write more modular implementations of crosscutting concerns; however these crosscutting concerns are not separated on a task-specific basis. There is only one decomposition that is present for a system at any given time. If another decomposition is desired, the system can be refactored into the new decomposition, but the previous decomposition is lost. Concerns that are the focus of specific tasks can thus still be scattered and tangled if they crosscut the primary decomposition. The second limitation of linguistic A O P is that it requires software de-velopers to adopt a new (or extended) programming language in order to create crosscutting modules. Like any other language adoption, a range of tools needs to be updated to accommodate the new language features. These tools include compilers, editors, IDEs, code formatters, documentation gen-erators, and others. This large set of tool changes can make adopting A O P difficult, especially in an industrial context. 1.2 F l u i d A O P In this research we propose fluid A O P as a solution to the limitations of linguistic A O P described above. Specifically, we suggest that fluid A O P can provide a kind of modularization that can support task-specific work. Fluid A O P provides mechanisms in the IDE for creating constructs that localize a software developer's interaction for a specific task. These con-structs are crosscutting views in that they can gather content that would otherwise be scattered throughout the system; in particular the constructs are not constrained by the file decomposition of the system. These con-structs are effective in that the views they provide are editable. This allows editing tasks to be done locally; they are also modular since there is a single construct for each task. Different constructs can present different slices of the same system; thus multiple decompositions of the same system can be present simultaneously by generating different constructs. These constructs conceptually localize the captured crosscutting concern. In the rest of this document, we refer to them as fluid aspects. Since the mechanism for modularizing crosscutting concerns is a fluid aspect, which is an editable view of the system, the underlying code remains 2 Chapter 1. Introduction the same; no new programming language has to be adopted, possibly making the transition in adopting A O P smoother. 1.3 Thesis Statement This thesis aims to support the following hypothesis: Crosscutting concerns can be modularized for specific tasks by IDE support that localizes scattered code fragments of interest into a single editable representation. 1.4 Overview The remainder of the document is organized as follows. The related work is described in Chapter 2. The three fluid A O P prototypes that we imple-mented are described in Chapter 3; their corresponding join point models are described in Chapter 4. Chapter 5 describes the implementation of the three prototypes. Chapter 6 provides additional examples from a medium-sized code-base. Chapter 7 provides comparison between the three prototypes, as well as comparing fluid A O P with AspectJ and plain Java. Chapter 8 summarizes the contributions of this work. Finally we discuss several future research directions in Chapter 9. 3 Chapter 2 Related Work Approaches to providing task localization of crosscutting concerns through the IDE fall into three categories. The first is to provide a localized way to navigate among the code in question, which we will discuss in section 2.1. The second is for the editor to provide new mechanisms to connect related or duplicated code, discussed in section 2.2. In section 2.3 we look at the final category which is to provide a kind of editor that includes views that do not necessarily correspond to the actual structure of the file that it is displaying. 2.1 Code Navigation J Query [8] provides browsable tree views that are user defined. It lets soft-ware developers select the content of the tree view by specifying a query in a query language called TyRuBa [23]. The ordering of the tree hierarchy can also be modified to match the tasks that they are currently working on. This tool allows a software developer to perform exploration and nav-igation tasks within a single tree view. It also allows them to see.the path in which it get's to the current query, which minimizes chances of getting lost between searches. This tree view can be used to group together parts of the system that correspond to a crosscutting concern, letting software devel-opers navigate between the parts within a single structure without getting lost. However, reasoning between multiple editors is still needed to perform a task. Mylar [10] is a task-focused U l for Eclipse that provides software devel-opers with only the information that is relevant to her current task. It leaves views and editors less cluttered than before which allows software developers to navigate more easily between parts of a crosscutting concern since they now appear to be closer to each other. JQuery, Mylar and related approaches [4, 16] provide an easier way for software developers to navigate between code. Mylar thins out the elements of the primary decomposition, but leaves the structure of that decomposi-tion intact. So a developer might only see one method in a file, and a related 4 Chapter 2. Related Work method in a second file. But there are still two files, and the mechanical and mental overhead of switching between the files to reason about or edit the methods is still there. (Although reduced because of the thinning out.) Wi th JQuery, the structure of the primary decomposition remains the same. The query tool allows user to form a navigator between subsets of the de-composition, but the mental overhead of switching between the files still exists. 2.2 Linking Code Clones Linked editing [22] is an editor-based approach for dealing with duplicated code. The tool (CodeLink) allows software developers to select multiple duplicated code fragments and link them together persistently. From then on the tool will affect the same edit on all the fragments when one is edited. It also provides selective elision of clones where the programmer can hide the redundant common regions between the linked code with ellipses, leaving only the differences visible. The clones in CodeLink are selected manually by the software developer; in particular it does not have a semantic way for software developers to select these code fragments. Once the code clones are located, the link between them is persistent. Simultaneous editing [14] is used in L A P I S (Lightweight Architecture for Processing Information Structure) which automates-repetitive text editing. It allows software developers to specify a set of regions to edit by either describing a pattern of the text in those regions or by manual selection. The system then selects all the regions corresponding to the specification and subsequently all edits done on one of the selected regions will cause equivalent changes to the other selected regions. Simultaneous editing allows selection to be done by using a pattern but this pattern only describes text property of the code, but does not use the semantic information of the system. Also the selection is not persistent so one has to remember the pattern every time one needs to work with the same selection. 2.3 Alternate Editor or Decomposition HyperJ [17] allows simultaneous decompositions of programs that differ from each other. It provides mechanisms for specifying which components to include for a concern. However the specification of join points to be included and how they compose with each other is separate from the code of the join points themselves. 5 Chapter 2. Related Work But soft! What light through yonder window breaks'; It is the East, and Juliet is the sun! Arise, fair sun. and kill the envious moon. Who is already sick and pale with grief That thou her maid art far more fair than she Be not.her maid, since she is envious. Her vestal livery is but sick and green, And none but fools do wear it. Cast it oft". Figure 2 .1 : In F l u i d Documents [2] the margin is used to show supporting materials. (Screenshot taken from [2]) The idea of fluid documents [2] was used in the context of literary doc-uments. The idea is that the primary material is present in the editor, along wi th support ing material when the user requests that information. The support ing material is displayed at different indentation and font. (See F i g . 2.3) W h e n space is l imited, the supporting material can appear while overlapping wi th the existing content. A n example of pr imary material is a literary passage and the supporting material could be an explanation about a specific terminology or alternate meaning to a word. comple'celnit i l i z a t i o n ();; s • . ' / * * ' ' ' * . I n i t i a l i z e : ; * d o c u m e n t : l i s t e n e r s , p o s i t i o n s , a n d ' p o s i t i o n u p d a t e r s . * : H u s t ' b e c a ' l l e d - i n s i d e - t h e c o n s t r u c t o r a f t e r , t h e i m p l e m e n t a t i o n p l u g - i n s " h a v e b e e n s e t . . / • • • . protected void c o m p l e t e l n i t i a l i z a t i o n 0 { f P o s i t i o n s = new H a s h M a p O ; f P o s i t i o n U p d a t e r 3 t n new A r r a y L i s t O ; f D o c u m e n t L i s t e n e r s a new A r r a y L i s t O ; f P r e n o t i f i e d D o c u m e n t L i s t e n e r s 1 3 new A r r a y L i s t O ; f B o c u m e n t P a r t i t i o n i n g L i s t e n e r s = new A r r a y L i s t O ; f D o c u m e n t P , e w r i t e S e s s i o n L i s t e n e r s = new A r r a y L i s t O ; ' addPositionCategory(0£K)jrtr_«TECORy)!; | . addPositionUpdater (new DefaultPositionUpdater (DEFAULT_CATEGORY) ][:_] r init ializeFluidDocument (get Document () i) [;[ \ Figure 2 .2: The screenshot shows an expansion of a method invocation in F l u i d Source Code Views [5] which reveals the target method definition in context. (Screenshot taken from [ 5 ] ) F l u i d source code view [5] applies the concept of fluid documents to 6 Chapter 2. Related Work source code: It reduces navigation by presenting a fluid view that inlines scattered code for "just in-time" comprehension. These fluid views are sim-ilar to our approach in that they are not limited by the actual file decompo-sition. The difference is that fluid source code view always has the same set of information available and software developers can choose to collapse some parts, whereas our approach lets software developers specify what informa-tion to display in the fluid aspect view. Also there is no way of eliminating duplicated changes in fluid source code view since there is no mechanism for representing a crosscutting slice as one entity. In [9] the authors describe the Decal prototype which provides two mu-tually crosscutting and effective source code views. The first view is called the modules view which provides a decomposition of program structure in terms of modular units which crosscut classes. The other view is called the classes view which is similar to the traditional object-oriented view, showing decomposition of the system in terms of classes. These views are effective in that software developers can edit them directly and change the code-base. They are also first-class with clear semantics defined for all possible edit operations between the views, whereas other works such as Masterscope [21] and Stellation [3] have arbitrary grouping as views and the semantics of some editing operations are not well defined. Virtual source files are the source files that the views are displaying where these source files can overlap with each other; Decal internally keeps track of one internal structure of the code-base. This allows software developers to simultaneously have access to two decompositions of the same system. The crosscutting view is prede-fined by the tool designer and cannot be changed by the software developer and since the underlying structure of the code-base is a new representation, existing tools will have to be modified to be used with Decal. In [19] the author describes MView, a source-code editor that provides dynamic crosscutting.views of a Java system. These views are comprised of code fragments, annotations, and a structured presentation framework that shows the relationships between the fragments. View components in the editor refer directly to the Java model of the program, allowing software developers to edit code directly in the editor. It provides a program slice in a single editor, even if the slice is scattered in the code-base. Similar to the fluid source code view, there is no way to eliminate duplicated changes in the MView editor since the editor only groups together the code fragments. 7 Chapter 3 Three Prototypes in Fluid AOP In order to investigate how fluid A O P support can aid in providing task-specific modularity, we implemented three prototypes of fluid A O P tools. These three prototypes address different kinds of development tasks; in this chapter we describe the prototypes using three scenarios where different editable views can localize the interactions required to perform the tasks. In Chapter 4 we will describe the join point models [12] underlying each of the prototypes. We focus on code-base written in Java for our prototypes. The three scenarios that we have chosen are all illustrated using the same small code-base - a simple drawing application that has a display and a set of shapes that can be created and shown on the display. But each scenario should be familiar to developers as a common task in software development. They demonstrate that different tasks can require software developers to interact with different slices of the code-base. Each scenario describes a task that has to be performed on the drawing application. The first one describes a code evolution task where a new display updating concern is added; the second scenario involves a code comprehension task where one tries to understand an existing logging concern, the third scenario involves a code evolution task where the software developer wants to modify the existing logging concern. The difference between the first and the third scenarios is that the first is a feature addition task and the third is a feature modification task. There are numerous common features that exist in all three prototypes and we describe these in Section 3.1. In the following subsections, we de-scribe the features of each prototype. 8 Chapter 3. Three Prototypes in Fluid AOP 3.1 C o m m o n Features 3.1.1 Aspect Editor A l l three prototypes provide an additional editor with which software de-velopers can interact. This editor works with files with extension .fa. These files store textual representations of the fluid aspect. These files include one or more pointcut definitions which are used to identify the code fragments that make up the concern of interest, as well as advice, intertype, gather or overlay declarations which specify the editable representation that the soft-ware developer is interested in. In all three prototypes, the representations are editable because they are linked back to the original files in which the code fragments, appear. ' • • We chose to use an editor as the means of interacting with the software developer because the various representations that we use to display code are also editable, which makes it natural for them to be presented in an editor. Secondly since we have the .fa files which consist of all the information to recreate the view, we can allow users to save these files and reuse them later to recreate the same editable representations. ' ' " ' J • - / ^ 1 o |fjjflt$j|!if| I U n e j a v a j j j~U setPl(Point) j j i 11 ietP2(Point) •B-f P o i n t j a v a j U setX(int) i - ( setY(int) Figure 3.1: The outline shows that an overlay is declared for the pointcut change. Change matches code fragments in Line.java and Pointjava and there are 2 set methods in each of the Java files. As a complementary part of the editor, we modified the outline view of the editor. The outline view provides a way for software developers to navigate between the aspect editor and the files where the matched code fragments belong to. Fig. 3.1.1 shows the outline view for an aspect that contains an overlay declaration. The icons differentiate between files and 9 Chapter 3. Three Prototypes in Fluid AOP methods in the outline view with F and M, as well as differentiating between the different declarations in the aspect, such as 0 for overlay, G for gather and A for advice declarations. 3.1.2 Pointcuts The pointcut language used in all three prototypes is the same. The language we chose resembles the AspectJ pointcut language. The language has the following grammar: pointcut ::= keyword '(' method_or_field_signature ' ) ' keyword ::= declaration I invocation method_or_field_signature ::= method_signature I field_signature method_signature ::= visibility_keyword type i d e n t i f i e r ' ( ' param_list ' ) ' field_signature ::= visibility_keyword type i d e n t i f i e r param_list ::= (type i d e n t i f i e r ) * The visibility keyword matches either public, private or protected. Type and identifier are string patterns that match a type or an identifier. We implemented the wildcard character * to match a string of any length con-sisting of any characters. We also implemented the sub-type pattern where A + matches all subclasses of A as well as the class A itself. For example, the pointcut to identify the code fragments corresponding to the method declarations for set methods in any subclass of Shape would look like: declaration(public void Shape+.set*(*)) 3.2 B e f o r e / A f t e r / I T D Consider the implementation of display updating for a drawing application. • Whenever an attribute of a shape object changes, the display should be up-dated accordingly. In order to implement this, an observer pattern is used. In particular we focus on the change signaling behaviour, where the dis-play object is an observer and the shape objects notify the display whenever there is a change. Therefore, display update invocation has to be inserted at 10 Chapter 3. Three Prototypes in Fluid AOP the end of al l method declarations that change an at tr ibute of a shape ob-ject. The display updat ing method should be invoked before these methods return, which is well suited for using an after returning advice. The first fluid A O P prototype provides a fluid version of the pointcuts and advice model in Aspec t J and other languages. 3.2.1 Advice i}~ ' K c M j a v a i ^pub l i c a s p e c t D i s p l a y U p d a t i n g p o i n t c u t change : d e c l a r a t i o n ( p u b l i c * f i g u c t a . S h a p e + . a e t * ( ' I ) a f t e r c e t u c n i n g : change tu •/ *. Dupia y Updating ,ta .• tu * I > s p a y U p d a i "j j ' a -jntltl.i c! vtrtd gebX'( t t i t x) ( t h i e . x • x; / K r Haf s e c r e t u r i j i i i f f (3 P i s p l a y U p d a t i n g D i s p l a y . u p d a t e ( ) ; p c b l i c v o i d a e t Y ( i n t . y) < : • ^  < y.i l.ti.iM .-y " y; p^-jl ] | / " * fiaf Lei r e t u r n i n g - 3 D lsp layUpt lo ' t l n u -/ ~* Display. j jpc (3 ta ( ) ; Figure 3.2: T h e aspect editor is shown on the left of the arrows and files of the corresponding code fragments are shown on the right. E d i t i n g in the body of the after returning advice also edits the advice blocks in the matched code fragments. In this prototype, declaring an after advice first causes the editor to find al l the code fragments matched by the pointcut. Then , wi th in each of those blocks, it finds the after advice block. The after advice block is the block of code corresponding to the implementation of the after advice body. For each matched code fragment, there should be exactly one after advice block corresponding to each after advice. If such a block does not already exist (if this is the first t ime this advice is specified or the code fragment is a new addit ion to the code-base), then a new block is inserted at the end of the matched fragments; the body of the block is ini t ia l ized to have the same content as the body of the advice. Once all the blocks are located, they are linked back to the original advice body. The resulting effect is that edi t ing one of the blocks w i l l edit all the blocks in unison. F i g . 3.2 shows a combinat ion of the display updat ing aspect as well as some shape classes 11 Chapter 3. Three Prototypes in Fluid AOP with inserted advice blocks. An additional comment is added preceding each block. This comment has two important functions. One is to act as an identifier for the tool to locate the inserted blocks during the linking phase. The second is to make it explicit to the software developers that the inserted blocks belong to a fluid aspect while reading the base code. This is helpful since if a software developer is interacting with the code without the tool, she would still know the inserted blocks are inserted as part of the concern for display updating causing her to be more cautious while changing code inside the blocks. On the other hand if the software developer is currently using the tool, the comments would remind her that editing the code inside the block would affect the other blocks belonging to the same advice. Before advice has a similar effect except that the advice block is inserted at the beginning of the join point instead of at the end. We also implemented after returning advice, where the advice block is inserted just before the return statement of the method declaration. To ensure that the semantics of an after or after returning advice is correctly implemented, sometimes the code fragment has to be refactored before the advice block can be inserted. In after advice, the original method body is surrounded by a try block and a finally block is added. The advice block is inserted into the finally block. This is to ensure that the advice body is executed even if an error or exception has been thrown. For after returning advice, if the method declaration has no return state-ment at the end of the body, then the advice block is inserted at the end of the method body, as seen in Fig. 3.2. If the method declaration has a single return statement that returns nothing or returns a variable or field reference, then the advice body is inserted just before the return statement. If the return statement returns any other values, the prototype splits the return statement into a variable declaration where the variable is initialized to the value that was originally returned, and a return statement that re-turns the variable. The advice block is then inserted in between the variable declaration and the return statement. Finally if there are multiple return statements, then an advice block will be inserted to each return statement at the appropriate location with the corresponding refactoring as specified above. 3.2.2 I T D Consider now what happens if the drawing tool needs to support multiple displays, i.e. each shape could be displayed in a different display object. 12 Chapter 3. Three Prototypes in Fluid AOP Instead of calling a static update method when the display should be up-dated, we want to invoke a non static method which might take the shape that triggers the update as an argument. To perform this implementation within the same aspect editor, we use another feature of the prototype. An intertype declaration (ITD) is used to define a field or a method of a class. An ITD consists of a field or method declaration along with a type pat-tern that specifies which class(es) the method or field should be declared in. The type pattern used is the same as the one used in a pointcut declaration. Declaring an ITD first causes the editor to find all the classes matched by the type pattern. For each matched class, there should be exactly one declaration corresponding to each ITD. If such a declaration does not already exist (if this is the first time that this ITD is specified or if this class is a new addition to the code-base), a new field or method declaration is inserted at the beginning of the class declaration. Once all the method or field declarations are located, they are linked back to the original ITD body. The resulting effect is that editing one of the declarations will edit all the blocks in unison. Fig. 3.3 shows the introduced display field in the Point class, a subclass of Shape. Fig. 3.4 shows the final display updating aspect with the ITD and the modified after returning advice. .flu *!}isp!ayUpdcit[ng.fa iflP^Pf l^PIIS^^S. J\ ' S h a p e J a v a "2 package f igures; Import annotation. publ ic class Point extends Shape ( B . I n t e ' r t y p e D e c i (aspectName= "D isplayUpdating")-pr ivate Display display; pr ivate in t x; pr ivate in t y; .public Point (int >:, int y) { t h i s . x = x; t h i s . y.= y; Figure 3.3: The display field is introduced by the aspect DisplayUpdating. Notice that instead of using a comment before an introduced declaration, an annotation is used. We would have liked to use an annotation for advice blocks as well, since annotations carry more semantic meaning in the code 13 Chapter 3. Three Prototypes in Fluid AOP a : publ ic aspect'. DisplayUpdatlng pointcut change : declaration( public * Ii'g'ures.Shape+.set*(*J )" declare, for'f igures.Shape+ {.private Display display;. } af ter returning. : change Figure 3.4: The pointcut definition, ITD and after returning advice is shown. The body of the advice has been changed to invoke the non-static update method. then a comment and software developers might be less likely to overlook an annotation as compared to a comment. However Java 1.51 does not allow annotations in front of an arbitrary block so we had to use comments instead. The aspect name is included in these annotations, similar to the comments for before or after advice. After the introduced field or method declaration is inserted in the ap-propriate classes, they are linked back to the ITD such that editing the ITD declaration will also change the introduced declarations as a uniform slice. Before and after advice, together with ITD mean this prototype now presents more possible editable representations for localizing concerns by allowing software developers to perform edits for scattered code within the aspect editor. A developer can both see and edit all the advice and ITD by looking at the single fluid aspect. 3.2.3 Multiple Advice or I T D s When there are multiple advice declarations or ITDs inside one fluid aspect, we need to record more than just the aspect name to identify exactly the advice or ITD. A solution for this is to insert an identifier that is unique within a single aspect, which we chose to be a counter of the number of declarations that have been defined in the aspect so far. We will focus on ITD for the remainder of this section but the same change can be applied to advice. Instead of adding the identifier information as an attribute to the annotation, it is added in the comment instead. """Java JSR 308 may allow annotations on blocks display.update() ; 14 Chapter 3. Three Prototypes in Fluid AOP i^lrri^ny^.^jij^v^T gj^  1 1 -Po in t j a va J jJ]iJShape|< pointcut change "public * ' f i i af ter returning change d isp lay: update().*; Figure 3.5: The pointcut definition, ITD and after returning advice is shown. An annotation is inserted preceding the ITD to reflect the id that is assigned to the ITD. The annotation that appears before the inserted method or field declara-tion now contains an attribute for the aspect name as well as the identifier. In order to connect this identifier back to the ITD, we also need to record the identifier in the fluid aspect view. Fig 3.5 shows the fluid aspect with this new annotation. The addition of concerns that do not already exist in the system, like display updating, can be localized by using advice or ITDs. In this section, we look at a task that cannot be localized with the previous prototype, and show that it can be localized by using the gather fluid A O P prototype. Consider a scenario where a software developer is examining a system for which she believes there is a logging concern already implemented. She wants to understand the logging concern better by inspecting logging calls. There is no mechanism in the advice and ITD fluid A O P prototype for presenting all the code fragments within one editor for her to inspect. Thus we created another prototype that provides a gather mechanism. The gather construct collects all the code fragments identified by the pointcut and displays them within a single editor. Each code fragment is displayed in its entirety in the order that they are identified. This view of the code fragments is editable - the user can directly edit any of the code fragments and this has the effect of changing the file that it originally appears in. Linked editing is used to achieve this, similar to the advice body 3 . 3 Ga the r 15 Chapter 3. Three Prototypes in Fluid AOP and ITD linking in the previous prototype. j j j 'L i r ie java 5? J] 'Point. java pointcut change : declaration(publie * figures.Shape+.set*<*)) gather change \DrawihgApp Yf iguresY Line.j ava public void setPl(Point pi)' (.• t h i s . p l =. p i ; Logger. log ("setP !")•:•;•. YDrawingAppYf iguire'sYLine.Java public void setP2(Point p2) { this.p2 = p2> Logger . log ( "se:.??. ")•.; — - \DrauingAppA f i g u r e s \ P o i n t . J a v a public void setX(int >:i ! this.x = x; Lpgger.log("setX"j ; Figure 3.6: Body.of the gather declaration is populated by editable represen-tation of all the matched code fragments. Notice that the last^set methods is missing a log invocation as compared to the other set methods. In Fig. 3.6 a gather construct is shown. The pointcut used is identical to the one used in the after returning advice example. Each matching code fragment is completely shown inside the gather construct. A label containing the file name in which the code fragment originally appears is inserted before each code fragment. Editing the content in the gather construct body has the same effect as editing the actual code fragment. Now the code comprehension task can be performed within a single ed-YDrawingAppYf iguresYPo int.Java public void setY(int y), {, this.y = y;; 16 Chapter 3. Three Prototypes in Fluid AOP itor. Looking at the code in Fig. 3.6 it is easy to see that all but one set method declaration has a log invocation at the end of its body. This makes the inconsistency in this logging concern easy to discover; and fixing this bug can be done locally in the same construct. This bug would have required the developer to compare code in multiple files otherwise. 3.4 O v e r l a y ~?'[//rUrfejci lj 'Point jc i " "1 pointcut. change : , . declaration(p.ublic ? f igutes. Shape+.set^ ( ) over-lay : change-.<•• [ \ DrawmgAppN figures\Line . java \ DrawmgAppY figures\Line .java \ DraraingAppYfiguresVPoint.java YDrawmgAppYf iguresVPoint...java public void s e t g ( f ~ : '•-»!)( , tni=.L : -n; Logger . log ("set;;; ____") ; > 'I __J Figure 3.7: A l l the set methods of shape classes are overlayed and one rep-resentation is inserted into the overlay declaration. Parts that are different among the code fragments are grayed out. The third fluid A O P prototype goes further than gather in terms of bring-ing scattered code fragments together for linked editing. It displays a single view for all identified code fragments. In order to generate this view, we have to calculate a single abstraction of the identified code fragments. It is impossible to show one abstraction that has all the original information that each code fragment possesses, since the code fragments are not guaranteed, and will most likely not be, identical. The idea is that this abstraction shows the similarities among the join points and hides the parts that are different. In our prototype a top-down approach is used to compare the code frag-ments. We first produce the abstract syntax tree (AST) corresponding to 17 Chapter 3. Three Prototypes in Fluid AOP each code fragment. We then do a pair-wise recursive comparison. For two nodes of the same type, if they are leaves, then we use string comparisons to compare the text of the nodes; if they are non leaves, then the children are compared. Nodes of different types are not equal and their children are not visited. After the comparisons are completed and the abstraction is generated, the similar parts are displayed and linked back to the corresponding parts in the original code fragments, and the rest are grayed out. Consider the task of modifying the logging concern from the gather ex-ample. One wants to change the argument being passed to the logger by consistently adding a description before the method name. This task can be performed as multiple edits within one gather construct since all the code fragments are collected into one construct. With the overlay construct, this change can be done as a single edit. The overlay construct is shown in Fig. 3.7. The view shows that all iden-tified code fragments are set method declarations; they each assign a value to a field and end with a log method invocation. To perform the modifica-tion task, one can edit the log invocation directly in the overlay construct and the change will be propagated to all the original code fragments. 3.4.1 Variations in Overlay Simple overlay can be useful when the set of join points is small and the join points are similar to each other. Otherwise, the overlayed structure will show mostly grayed out parts which do not provide enough information. We im-plement a variation in the way simple overlay is displayed. The comparison to generate the overlay remains the same as before, but instead of displaying just a grayed out box for method parameters, we name these boxes with the order in which they are declared, i.e. each grayed out parameter is displayed as $<parameter position>. For example the first parameter of an overlayed method declaration is displayed as $1 and the second is displayed as $2 and so on. Wi th this new way of display, if the parameters are used uniformly between all the overlayed method bodies, despite the parameter names be-ing different, that information is still present in the overlay. Fig. 3.8 shows the new overlay display. A second variation is a combination of using gather and overlay. Since overlay is most effective when the comparisons are done on a set of similar code fragments, this variation tries to guarantee that the groups are simi-lar. Before the comparisons are performed, another step is implemented to group similar code fragments before comparing nested code fragments and 18 Chapter 3. Three Prototypes in Fluid AOP Ju^iS^&ia^^f^ T 3 N . Ji.'.Lme.java • I [)] .'Point.aver pointcut. change : de c.l ar at ion. (pub lie. *'• figures. Shape,+ . set* ( *) •overlay. : change-{ —^ ••.;'.y-Dr,aw-i-ngAp.p\ f iguresVLine .'oava:1--:^-:---------• \DrawingAppVfigures\Line.java YDranrmgAppYf iguresVPoint .java • • VDratjingAppVf iguresV Point .java — : -; .public void set!__ j (•• ' 3.1*) { this.f?7=?.I; Logger, log ("set- • /') ; > Figure 3.8: The set methods are overlayed as before except that the param-eter of the method has been displayed as ?1. constructing the overlay. See Chapter 5 for details on how the groups are formed and Chapter 6 for an example that uses this feature. 19 Chapter 4 Join Point Models In A O P approaches, a join point model (JPM) [12] is used to describe differ-ent A O P mechanisms in general terms. In this chapter we describe the three prototypes in terms of their join point models, using this simple three-part ontology: 1. the nature of the join points 2. the means of identifying the join points 3. the means of semantic effect at the join points 4.1 Na tu re of the J o i n Points For all three prototypes, the join points are static code fragments. These code fragments include method declarations and method invocations. For the before/after/ITD model, code fragments corresponding to field declara-tions are also join points. Since all three prototypes are only concerned with static code fragments (i.e. static join points), the three corresponding join point models are all static join point models. 4.2 Means of Identifying the J o i n Poin ts The means of identifying join points are identical in all three models. They all use the same pointcut language for method signature based identification of method declarations and method invocations. Type patterns are used to identify types in method declarations as well as for identifying the classes that the method or field declaration should be introduced in for ITD. 4.3 Means of Semantic Effect at J o i n Poin ts This is the part that differs the most among the three join point models. The following sections describe the semantic effect of each model. 20 Chapter 4. Join Point Models 4.3.1 Before/After/ITD This join point model supports before, after and after returning advice, as well as intertype declarations; therefore, there are four means of effects. The effect of a before, after or after returning advice is to insert advice body blocks at the appropriate location of the identified join points. These locations are discussed in detail in the prototype description. Linked editing is then enabled between those inserted blocks and the advice body itself. The effect is that editing the advice body edits the inserted advice blocks around all the join points. Similarly the effect of intertype declarations is to insert definitions into the identified classes, and then enable linked editing between the introduced declarations and the intertype declaration itself. The final effect is that editing the intertype declaration edits the introduced declarations in all the identified classes. A l l four constructs have the effect of producing a uniform slice of the code-base where a single edit effects simultaneous changes to the rest of the components in the slice. " . 4.3.2 Gather . In this join point model, the means of semantic effect is a gather construct that groups together views of the identified join points. These copies are linked to the join points where they appear originally in the code-base, so that editing the view edits the actual join points. Instead of producing a uniform slice of the code-base as in advice/ITD, this construct collects the whole slice and produces a single view for it. However, editing a part of the construct only changes the join point that it corresponds to. 4.3.3 Overlay The means of semantic effect for the overlay join point model is an overlay construct that groups together views of the identified join points, but instead of displaying all the views showing the original code fragments, only a single abstraction of the views is displayed. In this abstract view, some parts of the original join points are shown, in particular the similar parts of the join points are shown. It also shows additional information about the join points in that one can find out how the join points compare to each other by inspecting the overlay construct and locating which parts are grayed out and which parts are not. 21 Chapter 5 Implementation We have implemented the three prototypes as Eclipse 2 plug-ins. The fluid aspect editor is an extension of the standard Eclipse text editor. 3 The components of the implementation of the prototypes are presented in Fig. 5. Parser Java parser Aspect parser Name Binder Type Checker Join Point Matcher Code Preparer Advice/IT.D Gather Overlay Code Linker Figure 5.1: Stages of the implementation architecture 5.1 Parser To parse the content of the aspects, we implemented a parser in addition to the existing Java parser. This parser is responsible for parsing the point-cut definitions as well as parsing the advice, intertype, gather or overlay declaration. We used the A N T L R framework4 to generate the parser. We used the Eclipse Java parser5 to parse Java code into abstract syntax trees, which are defined in the D O M package.6 We created additional A S T classes for pointcut and advice, as well as overlayed A S T nodes which we will discuss in more detail in section 5.4.3. 2 U R L : www.eclipse.org 3org.eclipse.ui.editors, text.TextEditor 4 A N T L R - ANother Tool for Language Recognition. URL: www.antlr.org 5org.eclipse.jdt.core.dom.ASTParser 6org.eclipse.jdt.core.dom 22 Chapter 5. Implementation 5.2 N a m e b ind ing and T y p e Check ing Since we require name.binding and type information in the join point match-ing phase, we also implemented a name binder and a type checker. This is implemented with three visitors. The first visitor is responsible for gathering all class declarations as well as recording all the method and field declara-tions of each class: The second visitor performs most of the name binding where all variable references are referred back to their declarations, as well as some of the field references and some of the method invocations. The last visitor ensures type restrictions are met by looking up the type of each expression and determining if there are any type conflicts. The remaining field references and method invocations that are not bound in the previous visitor are also bound once the type information becomes available. After this phase, each reference is connected back to its declaration and there is enough information for the join point matcher to determine if any given A S T in the code-base satisfies a pointcut. 5.3 J o i n Po in t M a t c h e r The A S T corresponding to the whole code-base is traversed once to deter-mine which code fragments are matched by pointcuts appearing in fluid as-pects. Only the ASTs of the right kind are checked against the pointcut. For example if the invocat ion pointcut is used, then only ASTs corresponding to method invocations are checked against the pointcut. A l l the information is present to generate the method or field signature at an A S T for comparison with the method or field pattern specified in a pointcut. The pattern in the pointcut is then converted to a regular expression and the A S T is matched if the regular expression matches the corresponding signature of the A S T . 5.4 Code P repa ra t ion and L i n k i n g This stage of the implementation is responsible for preparing the code both in the code-base and within the fluid aspects so that linked editing can be used to connect the aspect to the rest of the matched code fragments in the code-base. 2 3 Chapter 5. Implementation 5.4.1 Before/After/ITD For advice declarations, first the advice block corresponding to each join point is located. If the block does not already exist, then the text of the advice declaration body is inserted into the appropriate location along with a comment with the information as discussed in the prototype discussion. The location in which the block is inserted into depends on the type of advice. Refactoring of the join point, if necessary, is done before the location can be determined. Once all the blocks are located, their contents are compared. Currently our prototype requires that linked blocks be identical to each other. A n error is thrown if this is not the case. Once all the blocks are found to be identical, they are then linked back together with the advice declaration body by using the J D T linked editing mechanism.7 The linked editing mechanism takes care of keeping the linked blocks consistent; any edit in one block will result in the same change occurring in all other blocks. For intertype declarations, first the tool ensures that an annotation has been inserted for each ITD. If not a new annotation is inserted with the aspect name as its attribute. Then for each identified class that the ITD applies to, the field or method declaration being introduced is inserted at the beginning of the class if it is not introduced already. The declarations are then linked back to the original ITD with the same linking mechanism as advice. Note that a library containing the definition of the annotation has to be included on any project that uses this tool otherwise the annotations that are inserted for an introduced method or field declaration will be undefined. 5.4.2 Gather For ga ther declaration, an editable view of the text of each identified A S T is shown by inserting the code fragment of the A S T inside the ga ther body. The name of the file that the AST appears in precedes the code fragment. To allow for editing of the A S T in the gather body, the code fragment inside the ga ther declaration is linked back to the original code fragment. 5.4.3 Overlay Overlay constructs are generated after a set of code fragments are compared with each other and the similarities and differences are located. The com-parisons are done on the ASTs instead of at the text level since white spaces 7 org.ecl ipse, jface. text . l ink 24 Chapter 5. Implementation and other syntactic formatting components are ignored in the ASTs; we can also easily compare the types of the ASTs and obtain their children without having to reparse the text each time. In the simple overlay, the overlay operation always takes a set of code fragments and generates a single overlayed structure. This structure is gen-erated by OverlayPreparer, which implements something similar to an A S T visitor. Instead of traversing a single A S T structure, it traverses the whole list in parallel. At each A S T level, the node of each A S T at that level is compared to each other to make sure that they are the same kind of A S T node. If the kind of one A S T differs from the others then a grayed-out node is returned. The methods corresponding to the visit methods of the visitor now return A S T nodes instead of boolean values. For non-leaf node, a new node of the same kind is returned with the result of overlaying the children as the new children'. For leaf nodes, either a replicate of the nodes is .re-turned or a grayed-out node is returned depending on the similarity of the nodes. To minimize, the changes to the existing A S T classes, and since there are different restrictions for the kinds the children of some A S T nodes must be, different kinds of grayed-out nodes are added to the A S T package. For example the child representing the condition of an if statement has to be an expression, and the child representing the then clause has to be a statement. Different kinds of grayed-out nodes are added into the A S T package to accommodate the different types. There are grayed-out nodes for expression, modifier, simple name, variable declaration, statement, string literal and type. Once the overlayed structure is created, it is then linked back to the original code fragments. Since the prototype utilizes the linked editing pro-vided by the Eclipse J D T plugin, only identical parts between the original code fragments and the overlayed structure are linked together. In other words, none of the grayed-out nodes are linked back to their corresponding code fragments. White spaces also become a problem when compound A S T nodes are linked together. This is overcome by linking all the children of the nodes first. Then if the regions of two links are adjacent to each other, the two links are combined into a link between the combined regions of the original links of the text. 5 . 4 . 4 Overlay Groups The splitting of a set of code fragments into groups based on similarity is implemented by comparing certain attributes of the code and then dividing 25 Chapter 5. Implementation the code fragments based on the similarities of those attributes. Currently, the attributes that are used to compare the fragments are hard-coded in the implementation. Some of these attributes include number of children, the A S T kind and method names (if the A S T is a method declaration or a method invocation). In simple overlay a single overlay construct is generated for a set of code fragments. When a comparison between two nodes shows that the values of one of the attributes being compared are different, either the comparison will proceed as before and return a grayed-out node if that attribute is not one that is used to separate the groups, or an OverlayException is thrown. The OverlayException is caught where the generation of the overlayed structure is initiated. The A S T that causes the exception to be thrown (i.e., the A S T that differs from the ASTs that have been compared already) is removed from the group and the overlay generation process is restarted- with the new group. This continues until an overlayed structure is successfully generated. Then we perform the same steps for the remaining ASTs until all ASTs have been compared and are represented in one of the overlayed structures. 5.5 Limitations We have identified certain limitations of our approach in the prototypes. Since the linked editing provided by Eclipse requires that all the documents that are linked be opened, our prototypes will not work for a set of join points that are scattered over more than six hundred editors; Eclipse throws an editor handle exception indicating that too many editor handles have been opened. Secondly, since all linked text is changed simultaneously whenever one location is changed, the memory usage becomes very large when running the prototypes with fluid aspects with many join points. Currently when we run the prototypes on a medium-sized system there is a slight but not significant delay when editing constructs that are linked to multiple different files. Most of the delay occurs in the preparation and link creation stage and this delay ranges from 1 to 5 seconds. 26 Chapter 6 Additional Example In the preceding chapters we have looked at scenarios based on the small figure drawing example presented in Chapter 3. In this chapter we present an additional example which uses JHotdraw 8 as the code-base. JHotdraw is an open source drawing tool written in Java that comprises of 57360 lines of source code. 6.1 Consis tency Enforcement The combination of overlay and gather can be used to enforce consistency among related code fragments. We will now describe a process through which we enforce an ordering policy for the undo methods. We start by creating an overlay for the undo methods. When we first do this, with similar fragments grouped together, the identified code fragments are separated into 6 different groups. (See Fig. 6.1) Upon closer inspection, we observed that some groups differ just because of the ordering of statements, in particular the position of the if statements. One group has the following ordering: i f (! <condition>) return fa l se ; <statements> And the other group has the following ordering: i f (<condition>) <statements> return fa l se ; Since the order of the if statement and the return false statement are inconsistent in the two sets, they are separated into two groups. In our 8JHotdraw - URL: www.jhotdraw.org 27 Chapter 6. Additional Example fi>v ^ V . . V . r f V ii Select All Command i SendTo back Command ,J Ur I = YJHotDrawYorgYjhotdrauYf i'guresYFolyLineHandle .java : ijyl $ YJHotDraw\ org\ jhotdrauYfigures\ RadiusHandle.java . 'I| r. YJHotDrawN orgYjhotdraTii\ t igures\TextTool. java • ;i:/f| \ JHotDr:a"w\ o L " g \ jhotdrawYflguresYUngroupCorninand.3&.vt£--—r—.—----.-.--[-.-.• .• >•.•••••.•• • • SHS! % \ JHotDraw\ org\ jhotdraw\ standard\ AlignCornrriand. java ^ - - - \ JHotDraw\org\jhotdrau\standardYBoxHandleKit.java i - — . - \JHotDrawYorg\jhotdrau\standard\ChangeAttrlbuteCommand,java \ \JHotDrawYorgYjhotdraw\standardYChangeConnectionHandl'e.java \ ^ JIIotDrawS orgY-j hotdraw\' standard\ Connect ionToo 1.'jj ava Y JHotDrawN orgYjhotdraTA standard\ DragTracker .java I \ JHotDraw\ org\ 3 hotdratA standard\ PasteCornhiand. Java — 1 ii YJHotDraw\ org\ jhotdratA standard^ SelectAllCdrnrtvand. java '• " \ JHotDrawYorgYjhotdraTiA stahdardYSendToBackCqmm^ public boolean undo"() l • i f { !.super . undo (•) ) {: I return fa lse; { •>• yjHotDraw\orgYjhotdraw\contribYdnd\JHDDragSourceListener.Java \ JHotDraw\ org\ j hot draw\.ut i'lYUnddRedoAct i v i ty . java — public boolean undo(){ i f (is 0) < return false;. . } - — \:JHotDraw\ o'rg\ jhotdraw\.figures> Insert IniageConirtiand. java - -public.boolean undb£) { it (super .-undo (j ) {• getDrawingView (•)•;. clear Select ion () ; getDrawingView (}.:;drawing () . orphan (get ImageF igure () ) ;-return true; }'. return fa lse; y - — \ JHotDrauYorg\ jhotdrawYstandardYCutCommand.'java . . \ JHotDraw\org\jhotdraw\standard\DeleteCorranand.java jf1 Figure 6.1: Part of the overlayed undo methods - the undo method in InsertlmageCommand is inconsistent with the similar undo methods. scenario, we judged that making the code-base more consistent would he lp with understanding of the code. This was done by reordering the if statement and the statements fol-lowing the if statement in one of the groups. This edit itself can be done 28 Chapter 6. Additional Example using the overlay. Fig. 6.2 shows the new overlay group, which keeps the undo method in InsertlmageCommand.java in the same group as other undo methods that test for the condition super.updoQ. jj>i<JQ:Selec»>ICommand<... ; ^ [ - f f -SendToBae tCo im iond j J] UndoRedoAct :'.:[rTT.;-VdHotDr-ttwYorgY.D ho cdEaw.VcoriCcabVPolygunSc a l e Handle . - java- - — - -— - \ J H o t D r a w \ o r g Y j h o t d r a w \ c o n t r i b \ T e x t A r e a T o o l . j a v a \ J H o t D r a u \ o r g \ j h o t d r a w \ c o n t t i b \ T r x a n g l e R o t a t i o n H a n d l e . j a v a \ JHotDraw\ o r g \ . j h o t d r a u \ c o n C c i b \ dnd\ J H D D r o p T a r g e t L i s t e n e r . j a v a \ J H o t D r a w \ o r g \ j h o t d r a u \ tigures\ B o r d e r T o o l . j a v a V J H o t D r a w \ o r g \ j h o t d r a u A t i g u r e s Y C o n n e c t e d T e x t T o o 1 . j a v a \ J H o t D r a w \ o r g \ j h o t d r a w \ f i g u r e s \ C o n n e c t e d T e x t T o o T ; j a y a — \ JHqtDrow\ orgN j h o t d r a w \ f i 'gures \ F o h t S i z e l l a n d l e . j a v a f".mimmi,..,),..mm\,^ .H.l.m,mH ^ C & W^ - ^ U C & 3)' .^ " 3 g ^^J^^^^''^^V. J _ _ _ LyLineHar id ie . j a v a - - - - - - - - - - -\ J H o t D r a u \ o r g \ j h o t d r a u V f i g u r e s Y R a d i u s H a n d l e . . j a v a — YJHotDraw\ orgYjhotdrauVf i g u r e s \ T e x t T o o l . j a v a YJHotDraw\ o r g \ j h o t d r a w \ f iguresYUngroupComroand. J a v a - - \ J H o t D r a w \ o r g \ j hbtdraw\ atandardN A l ignCbmniand . .Java '- r \ J H o t D r a u N o r g \ j h o t d r a w \ s t 'andard\ B o x H a n d l e K i t . j a v a Y J H o t D r a u \ . o r g \ J h o t d r a u Y s t a n d a r d Y C h a r i ^ — -•:— \ J H o t D r a u \ d r g \ . j h o t d r a w \ s tandar'd \ CKangeCdrinect ior iHandie . j a v a — : \ J H o t D r a u \ o r g \ j h o t d r a w \ s t a n d a r d \ C o n n e c t i o n T o o l . j a v a •_ \ JHotDrawNorg\ j h o b d r a u \ s t a n d a r d ^ D r a g T r a c k e r . j a v a .: — YJHotDraw\ o r g \ jhotdraT ,T \ ! s tandard^ PasteCommand.'java \ JHotDrawS o r g \ ' j h o t d r a w \ s t a n d a r d \ Se l e c t AllCortimand. j ava . \ JHotDrawYorgNjhbtdraw\s tandard \SendToBackCorrrmand . java puto 11c b o o l e a n undo () {-i f ( ! super . undo () } {' re'turn fa lse ; >: > YJHofcDrau\ 'orgYjhotdrawYcor i tE ibYdnd\ J H D D r a g S o u E c e L i s t e r i e E . J a v a '\ JHotDraw\orgYjhotdraw\util\UndoRedoActivity.;)ava "' public boolean undo () { i f ( i s * " ' 0 ) < S§I- " 111! I "T^^^^^^^^SZTiZ " * " : 1 " -SE". r e t u r n f a l s e ; \ J H o t D r a u \ o r g \ j h o t d r a w \ s t a n d a r d N CutCommand.Java Figure 6.2: The updated screenshot of the overlayed groups - The first group now includes InsertlmageCommand which has an if statement with similar conditions as the other method declarations. 29 Chapter 7 Comparison In the introduction we denned the problem to be addressed as the two limitations that are currently present in linguistic A O P approaches. These two limitations are A O P requires new programming language adoption and only one decomposition of the software system can be present at any one time. Our hypothesis is that IDE-based support of providing AOP, in partic-ular IDE support for modularizing specific tasks by localizing the editable presentation of the program source, can overcome those two limitations. The discussion in this chapter is intended to evaluate how the differ-ent prototypes we have developed solve those problems, compared to each other, compared to using linguistic A O P and compared to using OOP (plain Java). We also compare additional features that are desirable in IDE sup-port. These features are modularization in editing and viewing of crosscut-ting concerns, as well as modularization in viewing of join points. Another desired property is for the tool to reduce the load of a developer having to perform duplicated editing tasks by replacing them with a single edit task that accomplishes the same. 7.1 F l u i d A O P In before/after/lTD J P M , the editing of a given concern is modularized be-cause a software developer only needs to perform edits in the aspect view inside advice bodies or ITD bodies. There is also a modularized view of the concern in the aspect since one can deduce the join points from the pointcut, as well as deduce the effects of the aspect by inspecting the type of advice and the advice bodies; however, if one needs any information about the join points other than the signature of the method, such as the first statement of each method body, then the aspect view is insufficient. Navigation to scattered code is still needed to find such information about join points. This J P M is best suited .for performing modularization of a concern that ' is uniform across all join points, and where the concern is quite separate from the core decomposition, so that no additional information about the 30 Chapter 7. Comparison join points other than the pointcut that is used to match them is required and no additional navigation of code is required for performing edits in this concern. In the gather J P M , join points, or at least an editable view of the join points, appear in the aspect itself. A l l the information about a join point can be found from the aspect view; therefore the viewing of the join points is modularized. (Although information about the context in which the join points appear still requires navigation to the scattered primary home of those join points.) The editing and viewing of a crosscutting concern is also modularized since it can all be done within one single aspect view. One property this J P M lacks is the ability to eliminate duplicated changes since each change to a different join point has to be done manually. Even though the changes can be done in close proximity to others, one still needs to go and make every change. This J P M appears well suited for an aspect in which only a small set of join points is of interest. Since all the information about each join point is shown inside the gather construct, it is likely useful for code understanding and as a starting point in narrowing subset of code for investigation without losing any information from too much abstractions. Finally in the overlay J P M , duplicated changes are greatly reduced since changes that can be done uniformly for all join points in an equivalence class can be done on the overlay construct. Not all information in a join point is displayed in this J P M ; only the similar parts are displayed. However more information in relation with the other join points can be discovered from looking at the overlay construct; one can find out which parts of the join points are similar and which parts are different. The viewing and editing of crosscutting concern are also modularized, even though the concern is not as structured as the advice/ITD J P M . In overlay, the crosscutting concern can be any subset of the parts that are displayed fully in the overlayed structure, as opposed to in advice, the advice block is the action of the concern. The effectiveness of overlay depends greatly on the similarity of the iden-tified join points. If the join points are drastically different, then all that will be shown for the overlay would be a grayed out box, which provides no additional information to the software developer. As shown in the example section, overlay can be useful after more information about the identified join points is discovered from inspecting the gather construct first, then ei-ther generate a single overlay if all the join points are similar to provide a meaningful abstraction, or then generate several overlays that distinguish the significant differences between the join points. 31 Chapter 7. Comparison 7.2 F l u i d A O P vs. Linguis t ic A O P One of the advantages of linguistic A O P comes from the ability to delay binding till the late stages of the compilation process or even up to run time. This late binding allows for pluggable aspects. In fluid AOP, since binding occurs at the editing phase, it is more difficult to remove aspects once they have been inserted. Another difference between the two A O P approaches is that in linguistic AOP, one code fragment can only be part of one aspect. In Fluid AOP, the same code fragment can appear in multiple aspects, since the aspects are just alternate views of the system. On the other hand, a strength of fluid A O P is that after aspect editing, no special compiler is needed to compile the code. This may ease adoption of A O P since one person on a team can use fluid A O P without causing the rest of the team to use a new compiler. Currently the prototypes we have developed have a less expressive means of identifying join points than AspectJ. The current prototypes only have pointcuts that match declarations of method and field and invocation of method. In Section 9 we discuss more pointcut declarations that we expect will be useful in Fluid A O P but which are not yet implemented. Since the join points in Fluid A O P differ from AspectJ, it is natural that a different set of pointcuts are needed. 7.3 F l u i d A O P vs. O O P Since fluid A O P is a support in an IDE and does not change the language of the code-base, all existing OOP tools work as before on the code; therefore all the advantages that OOP provides are also present with fluid A O P approach. In addition, fluid A O P provides fluid aspects which can modularize code that appears scattered or tangled in the code-base. This makes practical and frequent tasks easier to perform. For example the ability to group together multiple join points and perform a single.uniform edit to these join points make refactoring (for example adding method parameter, or renaming) eas-ier and less error prone. In particular, one feature of renaming that fluid A O P can handle is systematically renaming part of a set of method names. For example one can rename all the set methods from starting with set to starting with mutate. Fluid A O P can also serve as another tool foraiding in code exploration and understanding, as seen in Chapter 3. 32 Chapter 8 Contribution In this research we propose an IDE-based approach to modularizing cross-cutting concerns for specific tasks. We consider modularization of a concern in this context to mean localization of code that a software developer has to view or edit to perform a task. We illustrated the feasibility of fluid A O P by presenting three join point models with corresponding prototype imple-mentations. These three join point models are separate but can be used together as shown in the example in Chapter 6. We have outlined some key components in the implementation of our prototype for each J P M . Fluid A O P provides a novel way of modularizing crosscutting concerns, by providing fluid editable views on demand, hence giving software develop-ers the option of slicing the code-base in multiple ways to help suit current task of interest. We also presented multiple prototypes that show ways to display mul-tiple code fragments inside one editor. The most novel construct in- these prototypes is the overlay construct. An editable code level presents one ab-straction of multiple code fragments. This construct shows a combination of similarities and differences between the code fragments that are not im-mediately evident when browsing between the code with typical OO I D E support. These fluid A O P prototypes show that even though the underlying code-bases are semantically and syntactically identical to OOP modulo the as-pects, additional information is inserted in the code-base that can be helpful. In before/after/ITD, comments or annotations are inserted in the code to signify the existence of an aspect. For developers that are not using fluid A O P tools, it becomes clear that the advice blocks or introduced methods or fields are placed there to implement a crosscutting concern. The fluid aspect files (with extension .fa in our prototypes) can also serve as a way to make aspects explicit in the code-base. Even though these files do not have compile-time effects in the code-base, it provides information for identifying the elements that make up the implementation of the aspect. Through the design for the various prototypes, we have come to learn that simple text comparison in overlay only works for a small set of very simi-33 Chapter 8. Contribution lar code fragments. We also learned that using the linked editing mechanism in Eclipse and extending the text editor in Eclipse are good starting points in building our prototypes but to improve the performance and features of the prototypes, we will have to implement our own linking mechanism and editor. These are discussed further in Chapter 9. 34 Chapter 9 Future Work This is only the beginning of the exploration of fluid A O P . There are many directions which we can take to extend this work. Some are described in this chapter. 9.1 E x t e n d i n g the F l u i d A O P Space We currently have three join point models that form a subpart of the fluid A O P space. One future research direction could be to extend the subpart of fluid A O P by creating more JPMs. By the way we define a join point model, there are three components we can expand to create new JPMs . The first is to expand the set of join points. Currently the join points are only code fragments corresponding to method declarations, method invoca-tions and field declarations. Possible useful join points can include code fragment corresponding to any statement or expression to make the join point granularity smaller. The second is to expand our pointcuts. An example of a possible use-ful pointcut is one that identifies the surrounding method declaration of a method invocation instead of identifying the method invocation itself. Finally we can explore new ways to display matched join points. Cur-rently we have advice, gather and overlay and we tried to combine overlay and gather. Future work can look into new kinds of constructs to display the identified code fragments. 9.2 Improv ing Cur ren t Implementat ions 9.2.1 O v e r l a y G r o u p s The current implementation of grouping into equivalence classes in overlay is implemented by hard coding the various factors in the implementation of the tool. To change those factors requires going in and updating the source code. We will explore different ways to let a software developer control the 35 Chapter 9. Future Work individuation criteria for groups. One solution is to give software develop-ers a knob-like control which controls how many groups will be presented. Instead of using the comparison step to decide how many groups there will be, we can first separate the groups by a clustering algorithm, then use the current overlay (the version that takes a set of code fragments and return exactly one overlayed construct) to generate the overlayed construct. [15] describes algorithms for clustering elements which require that each element be converted to a vector which can then be used to calculate dis-tances between elements. To make use of these algorithms, we can have a vector with length equal to the number of different A S T node types possi-ble. Each code fragment can then be converted into a vector by filling in how many nodes of each type are present as children of the code fragment. Then we could use the clustering algorithm to decide the grouping and then present the overlayed construct of each group. The clustering algorithms enable software developers to specify exactly how many number of groups should be presented. 9.2.2 More Overlay Features We can also improve the display of overlay, for example instead of graying out the different parts completely, we can show a list of the differences. We also plan to design more meaningful overlayed structures and better similarity comparer for creating them. Some possible options are to include more renaming mechanisms or overlaying different structures, such as overlaying method declarations with method invocations. Another part of overlay that can be improved is that currently all the file names that the overlayed code fragments belong to are displayed preceding an overlayed construct to show which files are involved. This list can become too large to be useful if the set of files involved is large. One way to make this list more scalable is to let developers collapse the list and expand it only when they are interested in the files involved. 9.2.3 Graphical Aspect Editor Currently the aspect editors in the three prototypes are all plain text editors. Using a graphical editor, for example we can use the Eclipse Graphical Edit-ing Framework ( G E F ) 9 to implement this editor, will provide more flexible ways to present information for the user. We can utilize different graphics to represent different results in overlay. A gray box Mil can be used to mean 9URL: www.eclipse.org/gef 36 Chapter 9. Future Work that all join points have an element at that location but they have different content; a half gray box I fc^ can be used to mean that some join points have an element at that location with different content, but some join points do not have that element. 9.3 Improving Scalability One limitation to our implementation of the prototypes is that it does not scale for large code-base. One step that has to be taken is to implement our own mechanism for linking code fragments. When the code-base gets larger, simultaneous updating of all join points no longer become feasible. Editing changes should be propagated either when the affected file is brought to view or when user specifies that the changes should be propagated. Another option to minimize the delay in linked editing is to make the granularity of change propagation be larger. Currently it is at the level of a single key stroke. We can instead try to group together key strokes that occur in close proximity to each other and delay refreshing all the affected documents till a group of changes have been made or the user pauses. 37 Bibliography [1] Joao Araujo, Jon Whittle, and Dae-Kyoo K i m . Modeling and compos-ing scenario-based requirements with aspects. In RE '04: Proceedings of the Requirements Engineering Conference, 12th IEEE International (RE'04), pages 58-67, Washington, D C , USA, 2004. I E E E Computer Society. [2] Bay-Wei Chang, Jock D. Mackinlay, Polle T. Zellweger, and Takeo Igarashi. A negotiation architecture for fluid documents. In UIST '98: Proceedings of the 11th annual ACM symposium on User interface soft-ware and technology, pages 123-132, San Francisco, California, United States, 1998. A C M Press. [3] Mark C. Chu-Carroll, James Wright, and David Shields. Supporting aggregation in fine grained software configuration management. In SIG-SOFT '02/FSE-10: Proceedings of the 10th ACM SIGSOFT sympo-sium on Foundations of software engineering, pages 99-108, Charleston, South Carolina, USA, 2002. A C M Press. [4] Robert DeLine, Amir Khella, Mary Czerwinski, and George Robert-son. Towards understanding programs through wear-based filtering. In SoftVis '05: Proceedings of the 2005 ACM symposium on Software visualization, pages 183-192, St. Louis, Missouri, 2005. A C M Press. [5] Michael Desmond, Margaret-Anne Storey, and Chris Exton. Fluid source code views for just in-time comprehension. In Software Engi-neering Properties of Languages and Aspect Technologies Workshop, Bonn, Germany, 2006. [6] A . Nico Habermann and David Notkin. Gandalf: software development environments. IEEE Trans. Softw. Eng., 12(12):1117-1127, 1986. [7] Ivar Jacobson and Pan-Wei Ng. Aspect-Oriented Software Development with Use Cases (Addison-Wesley Object Technology Series). Addison-Wesley Professional, 2004. 38 Bibliography [8] Doug Janzen and Kris De Voider. Navigating and querying code with-out getting lost. In AOSD '03: Proceedings of the 2nd international conference on A sped-oriented software development, "pages 178-187, Boston, Massachusetts, 2003. A C M Press. [9] Doug Janzen and Kris De Voider. Programming with crosscutting effec-tive views. In ECOOP '04: Proceedings of the 18th European Confer-ence on Object-Oriented Programming, pages 197-222, Oslo, Norway, 2004. Springer-Verlag. [10] Mik Kersten and Gail C. Murphy. Using task context to improve programmer productivity. In SIGSOFT '06/FSE-14: Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering, pages 1-11, Portland, Oregon, U S A , 2006. A C M Press. [11] Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, and William G. Griswold. An overview of aspectj. In ECOOP '01: Proceedings of the 15th European Conference on Object-Oriented Programming, pages 327-353, London, U K , 2001. Springer-Verlag. [12] Gregor Kiczales, John Lamping, Anurag Menhdhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin. Aspect-oriented programming. In Mehmet Ak§it and Satoshi Matsuoka, editors, Pro-ceedings European Conference on Object-Oriented Programming, pages 220-242, Berlin, Heidelberg, and New York, 1997. Springer-Verlag. [13] Jacques Klein, Loi'c Helouet, and Jean-Marc Jezequel. Semantic-based weaving of scenarios. In AOSD '06: Proceedings of the 5th interna-tional conference on A sped-oriented software development, pages 27-38, Bonn, Germany, 2006. A C M Press. [14] Robert C. Miller and Brad A. Myers. Interactive simultaneous editing of multiple text regions. In Proceedings of the General Track: 2002 USENIX Annual Technical Conference, pages 161-174, Berkeley, C A , USA, 2001. U S E N I X Association. [15] Lefteris Moussiades and Athena Vakali. Pdetect: A clustering approach for detecting plagiarism in source code datasets. The Computer Journal, 48(6):651-661, 2005. [16].Mikkel R0nne Jakobsen and Kasper Ffornbaek. Evaluating a fisheye view of source code. In CHI '06: Proceedings of the SIGCHI conference 39 Bibliography on Human Factors in computing systems, pages 377-386, Montreal, Quebec, Canada, 2006. A C M Press. [17] Harold Ossher and Peri Tarr. Hyper/j: multi-dimensional separation of concerns for java. In ICSE '00: Proceedings of the 22nd international conference on Software engineering, pages 734-737, Limerick, Ireland, 2000. A C M Press. [18] Andres Diaz Pace and Marcelo Campo. Analyzing the role of aspects in software design. Communications of the ACM, 44(10):66-73, 2001. [19] Philip J . Quitslund. Beyond files: programming with multiple source views. In eclipse 'OS: Proceedings of the 2003 OOPSLA workshop on eclipse technology eXchange, pages 6-9, Anaheim, California, 2003. A C M Press. [20] Awais Rashid, Ana Moreira, and Joao Araujo. Modularisation and com-position of aspectual requirements. In AOSD '03: Proceedings of the 2nd international conference on Aspect-oriented software development, pages 11-20, Boston, Massachusetts, 2003. A C M Press. [21] Warren Teitelman and Larry Masinter. The interlisp programming en-vironment. Computer, 14(4):25-33, April 1981. [22] Michael Toomim, Andrew Begel, and Susan L . Graham. Managing du-plicated code with linked editing. In VLHCC '04: Proceedings of the 2004 IEEE Symposium on Visual Languages - Human Centric Comput-ing (VLHCC'04), pages 173-180, Washington, D C , USA, 2004. I E E E Computer Society. [23] Kris De Voider. Type-Oriented Logic Meta Programming. P h D thesis, Vrije Universiteit Brussel, Programming Technology Laboratory, June 1998. 40 


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items