Using the Map Metaphor to Assist Cross-Cutting Software Changes

OF THE THESIS Using the Map Metaphor to Assist Cross-Cutting Software Changes by Jimmy J. Yuan Master Of S ien e in Computer S ien e University of California, San Diego, 2000 Professor William G. Griswold, Chair Every software program ontains elements that link the modules omprising the system into a fun tional system. These elements are sometimes widely distributed throughout the sour e ode. We say these elements ross ut the system's basi stru ture, and we all them aspe ts. By exploiting textual similarities among aspe t ode, one may use textbased sear hing tools to lo ate relevant ode. However, these tools be ome diÆ ult to use when dealing with multiple aspe ts in a large system. Our resear h produ ed a olle tion of tools that allows aspe ts to be treated as rstlass entities. These tools are designed around the map metaphor, providing strengths familiar in visualizing and reasoning about widely distributed entities. This thesis presents this olle tion of tools, whi h we all Aspe t Browser, and dis usses our ndings in two user studies we ondu ted. x Chapter I Introdu tion Software maintenan e dominates a software proje t's life y le. Features are onstantly added and modi ed to enhan e produ ts to ompete in the everhanging market. In order to make hanges to a software proje t, a developer must understand the system's design. Gaining insight into the design of a software system is a diÆ ult task, even if the system was designed and oded using traditional modularity te hniques. One of the primary reasons for this is the modules of su h systems en apsulate and hide a parti ular design de ision, but there are other program elements that link together these separate design de isions into a fun tional system. Ea h su h program element, whi h we all an aspe t, is diÆ ult to manage be ause it may span many les a ross the software system's sour e. Being able to identify su h aspe ts and understand their intera tions along with how they relate the design de isions they are embedded within is ru ial to orre tly hanging a software system. I.A Modularizing Aspe t Code For Ease of Change Information hiding modules ontain lo alized ode related to a parti ular design de ision. Changing the design de ision is a matter of hanging the ontents of the module. Aspe ts are omprised of unlo alized ode related to a parti ular 1 2 design de ision. Thus, they may be viewed as on eptual modules. How does one view aspe t ode as a olle tion of related ode su h that it is easy to hange? One way is to expli tly lo alize the ode into a module by restru turing. Aspe t-Oriented Programming (AOP) is a new programming te hnique that allows a programmer to expli itly represent fun tions and obje ts with traditional proedural or obje t oriented programming methodologies, but also allows aspe ts to be represented expli itly in an aspe t language [Ki zales et al., 1997℄. Traditional omponents and aspe ts are integrated at ompile time to reate a fun tional system. Although this method has shown promise in several ases, there are drawba ks to this approa h. AOP has urrently only been implemented for Java as Aspe tJ [Aspe tJ, 2000℄ and HyperJ [IBM, 2000℄, thus systems written in other languages annot bene t from it. In addition, older programs written in Java prior to Aspe tJ and HyperJ may not bene t from AOP without being redesigned and rewritten utilizing the aspe t language. Alternatively, a programmer may also view ode omprising an aspe t together as a module by using textual similarities in the ode. For example, an aspe t may be a fun tion's interfa e it's de nition and referen es to it. Changing this interfa e involves orre tly identifying the fun tion's de nition, and all its referen es throughout the program. In a simple ase where fun tion pointers are not used, a \sear h" using the fun tion's name will help identify relevant lines. In ases using fun tion pointers, a series of sear hes on the di erent names that are used for the same item will help identify the relevant ode. Te hniques for exploiting textual or synta ti similarities among ode making up an aspe t are part of information transparen y, a omplement to information hiding modularity, allowing more omplex modules to be examined [Griswold, 1998℄. These te hniques identify aspe ts by their textual signatures, and have several bene ts. They do not require any new language ontru ts, work with older systems written in any programming language, and do not ne essarily require the programmer to hange their programming style, although some programming onventions may enhan e 3 publi lass CursorHistoryItem { publi CursorHistoryItem( int fileID, int lineNum ) { mFileID = fileID; mLineNum = lineNum; mFirstItem = mLastItem = false; } ... private int mFileID = 0; }Figure I.1: As an example of a task that auses hange a ross a system, we wish to remove mFileID from this lass. mFileID is assigned a value passed into the onstru tor, ausing us to look throughout the system for instantiations of this lass. the power of expression of information transparen y. I.A.1 Tool Support For Exploiting Information Transparen y What kinds of tools are available to exploit information transparen y in a software system? In most development environments, there are text pattern sear hing tools su h as grep, egrep, fgrep, sear h, nd, ndstr, et . These tools are all fairly similar in that they output a set of lines that ontain text mat hing the pattern. Some allow the user to sear h for more advan ed patterns using regular expressions. However, these tools have a fundamental limitation when being used to exploit hange through information transparen y. Consider the portion of a lass shown in Figure I.1.1 Suppose we realize the member variable mFileID is no longer needed, and we wish to remove it. We realize it is initialized by being assigned the value of the rst parameter passed into the onstru tor. In order to remove it properly, we must identify all lo ations throughout the ode where an obje t of type CursorHistoryItem is reated and 1This lass is taken from the proje t Nebulous, whi h is des ribed later in this thesis. Nebulous is urrently omprised of 69 Java les. 4 Figure I.2: Output of a text-based sear hing tool for CursorHistoryItem. publi boolean InsertHistoryItem( int fileID, int lineNum ) { boolean hasPreviousItems = false; CursorHistoryItem item = new CursorHistoryItem( fileID, lineNum ); ... }Figure I.3: Tra ing where leID omes from, we realize we need to look for allers of InsertHistoryItem. remove the rst parameter as appropriate. Using text-based sear hing tools, a regular expression sear h on CursorHistoryItem yields the output shown in Figure I.2. In order to modify the rst line found by the sear h, we need to open CursorHistory.java and navigate to line 46. A portion of this ode is shown in Figure I.3. We observe the rst parameter passed to the onstru tor for CursorHistoryItem is passed in as the rst parameter to the fun tion InsertHistoryItem. A sear h on InsertHistoryItem gives us the output seen in Figure I.4. This output indi ates there are several lines in various les we must visit. This pro ess must ontinue until all newly dis overed patterns of our aspe t are visited and modi ed appropriately. The example presented demonstrates the limitations of using text based Figure I.4: Output of a text-based sear hing tool for InsertHistoryItem. 5 sear hing tools for a task su h as this. The output of these tools only has lines that ontain the pattern being sear hed for. For ea h output line, a user would need to manually open the indi ated le in an editor, navigate to the proper line, and then determine whether or not to hange the line and whether there are other patterns un overed from examining the line whi h also need to be sear hed for. If it is not immediately known whether or not the line should be modi ed, the user must navigate to the line and use the surrounding ontext to make a de ision. For a large output set that spans many les, this pro ess involves many steps, is time onsuming, and keeping tra k of what has been done and what remains to be done is diÆ ult. I.B Aspe t Browser Aspe t Browser (AB) is a olle tion of tools we have developed to help a programmer identify, view, and modify aspe ts within a software system, while at the same time addressing the limitationsmentioned above. AB is mainly omprised of two losely integrated tools for viewing aspe ts as modules. These two tools are alled Aspe t Ema s and Nebulous. Aspe t Ema s also uses two helper utilities to dis over aspe ts in a system. In Chapter 3, we des ribe AB in detail and demonstrate how it would be used to aid the user in making the hange presented by the example in this hapter. I.C Hypothesis Our goal during the development of AB was to provide ognitively powerful me hanisms by whi h our users ould work with and reason about widely distributed aspe ts. In the real world, entities that are physi ally distributed may be onveniently viewed and reasoned about by using a map. Thus, we hose to model our toolset on the map metaphor be ause maps provide familiar, ognitively powerful me hanisms for dealing with physi ally distributed, multi-dimensional 6 information. We hypothesize that AB allows the tool user to treat aspe ts as rstlass entities sin e we developed aspe t operations designed around the map metaphor. I.D Overview of the Thesis Chapter 2 will give an overview of maps in order to lay the foundation for understanding how our tools are designed around the map metaphor. Chapter 3 will present Aspe t Browser in detail. Chapter 4 will dis uss the user studies we ondu ted to test our hypothesis and dis usses the results of these studies. Chapters 5 presents on lusions of our urrent resear h. Chapter II Maps A map is a presentation devi e that displays an abstra t view of some portion of the world with an emphasis on sele ted features. The role of maps varies from presenting information for \visual thinking" to presenting informati