STAC: Software Tuning Panels For Autonomic Control

Elizabeth Dancy and James R. Cordy

School of Computing,Queen’s University,

Kingston, Ontario, Canada{dancy, cordy}@cs.queensu.ca

Abstract

One aspect of autonomic computing is the abil-ity to identify, separate and automatically tuneparameters related to performance, security,robustness and other properties of a softwaresystem. Often the response to events affectingthese properties consists of adjusting tuneablesystem parameters such as table sizes, time-out limits, restart checks and so on. In manyways these tuneable parameters correspond tothe switches and potentiometers on the controlpanel of many hardware devices. While mod-ern software systems designed for autonomiccontrol may make these parameters easily ac-cessible, in legacy systems they are often scat-tered or deeply hidden in the software source.

In this paper we introduce Software Tun-ing Panels for Autonomic Control (STAC), asystem for automatically re-architecting legacysoftware systems to facilitate autonomic con-trol. STAC works to isolate tuneable sys-tem parameters into one visible area of a sys-tem, producing a resulting architecture thatcan be used in conjunction with an auto-nomic controller for self-maintenance and tun-ing. A proof-of-concept implementation ofSTAC using source transformation is presentedalong with its application to the automatic re-architecting of two open source Java programs.

Copyright c© 2006 Elizabeth Dancy and James R.Cordy. Permission to copy is hereby granted providedthe original copyright notice is reproduced in copiesmade.

Use of the new architecture in monitoring andautonomic control is demonstrated on these ex-amples.

1 Introduction

The time is approaching when the rate ofsoftware development so outweighs human ex-pertise that there may be a software mainte-nance crisis. The domain of autonomic com-puting aims to proactively combat this prob-lem by working towards the production of self-controlling and self-maintaining systems. How-ever, it is futile to attempt to completelyreplace all existing software with autonomicequivalents because this just leaves us in a dif-ferent race against time. It therefore seemspertinent to look at ways to automate the con-version from legacy systems to autonomic sys-tems. Facilitating self-maintenance and self-tuning requires access to numerous tuneablesystem parameters. At present, these parame-ters are often scattered throughout source codeand sometimes hidden, forcing each access toinvolve a costly search through the code.

In order to automate the re-architecture ofprograms so that the tuneable parameters areaccessible without a search, we propose STAC,Software Tuning Panels for Autonomic Con-trol, a system to automatically re-architectlegacy source code with respect to marked-uptuneable parameters. The result is a systemwith identical functionality that provides the

maintainer, autonomic or otherwise, with lo-calized access to these tuneable parameters forinstrumentation, tuning and maintenance pur-poses. In STAC, tuneable parameters are lim-ited to scalar types in order to bound the scopeof the project. However, in practice tuneableparameters could be any system variables.

STAC has two main steps. First, tuneableparameters of interest are identified and ref-erences to them traced throughout the sourcecode. Second, a new program module is gen-erated that encapsulates all actions on the pa-rameters during program execution. In STACthis new module is called the Control Panel.

The remainder of this paper is organized asfollows. Section 2 describes the general ap-proach and implementation of STAC. Section 3provides examples of STAC re-architectures ontwo real world open source applications. Sec-tion 4 demonstrates three applications of theSTAC Control Panels created for these sys-tems. Section 5 provides a synopsis of re-lated work and Section 6 analyzes the resultsof STAC and suggests future work in the area.

2 Approach

The prototype STAC re-architecture processfor Java programs consists of a Java Front Endin combination with a series of source trans-formations written in the TXL programminglangauge [6]. These language choices were de-liberate but not necessary as STAC could beimplemented using other languages.

To begin the STAC implementation, theoriginal source code is normalized for transfor-mation. To do so, the original Java softwarepackage is first sent through a Front End FileFilter, where it is sorted down into only sourcecode files and organized into one contiguoustext file to prepare the input for TXL transfor-mation. Special XML tag delimiters separateeach source file and other tags denote whereeach original source folder begins and ends sothat the package can be re-created followingre-architecture.

The merged source text file is run through aseries of transformations which are responsiblefor the actual re-architecting of the source codeand the generation of the Control Panel mod-

Original Java Files with Markup

Front End JavaFile Merger

Front End JavaFile Splitter

Contiguous Text File of ALL Java Files

ReferenceTransformation

ReferenceIdentificationand Tracing

ReferenceIdentificationand Tracing

ControlPanel

Generation

Contiguous Text File with Control Panel

Modified Java Files plus Control Panel

Figure 1: Overview of the STAC Process

ule housing the tuneable parameters of interest.Finally, the transformed contiguous source fileis passed back into the Front End to be sortedinto its original file and package structure, withthe addition of the Control Panel. Figure 1 out-lines this process graphically.

The most challenging technical parts in Fig-ure 1 are the TXL transformations which iden-tify and transform the tuneable parameter ref-erences, as well as those transformations whichcreate the Control Panel module. Details ofthese two main parts are explained below. Itis pertinent to note that before this stage, aseries of unique renaming transformations areapplied to distinguish different variables withthe same name.

In the STAC prototype the user must man-ually mark up the declaration of each tuneableparameter of interest directly in the source codeusing XML tags. After this step, the remain-der of the transformation process is automatedand hidden from the user.

The main architectural changes to a systemare the addition of a new program module, theControl Panel, and the redirection of tuneableparameter references to the Control Panel. Fig-ure 2 is a conceptual view of how a system isre-architected using STAC. The left-hand sideshows the tuneable parameter references (rep-resented by hollow circles) before the transfor-mation. After the transformation, these ref-erences refer to the newly generated ControlPanel module shown at the bottom.

2

Before After

Figure 2: STAC Re-Architecting

2.1 Control Panel Generation

Creating the Control Panel class requires track-ing of the tuneable parameters by searching forthe XML markup around each tuneable param-eter’s declaration. Each marked up parame-ter is added to the Control Panel, one at atime. Each variable of interest is representedin the Control Panel as its own class, namedfor the tuneable parameter it represents. Theleft-hand side of Figure 3 shows an originalJava class with a variable numUsers which hasbeen marked up. The right-hand side of Fig-ure 3 shows the resulting Control Panel for nu-mUsers.

Not all Control Panel classes are as simple asthat in Figure 3. In a typical program, severaltuneable parameters would be marked up andeach of those may have many references to it.Due to Java inheritance, tuneable parametersthat are created in subclasses of other classescontaining tuneable parameters may have otherobjects that refer to them. The Control Panelmust create a separate reference class for eachcopy of a variable which is explicitly created inthe code to accommodate for this inheritanceproperty.

For example, in the class InteractiveSystemof Figure 3 we have marked up the global vari-able numUsers as a tuneable parameter be-fore the transformation. If more than one in-stantiation of InteractiveSystem were createdin the program, then the Control Panel must

Figure 3: NumUsers Markup and ControlPanel Creation

contain a new copy of numUsers for each in-stance. Other extensions to our Control Panelgeneration handle other Java scenarios whichwould allow another pointer to the same nu-mUsers variable. Figure 4 shows an examplegenerated Control Panel with nesting to han-dle the situation where there is more than onecopy of a tuneable parameter. In this case, aninstance of InteractiveSystem named Interac-tiveSystemInst is created in the Java programand needs to have its own copy of numUsers inthe Control Panel. If a second instance of Inter-activeSystem were created, say InterActiveSec-ondInst, the Control Panel would add anotherclass where InterActiveSecondInst would haveits own numUsers class nested inside of it, andso on.

2.2 Reference Changing

While the above Control Panel serves its pur-pose, thus far the variables in the Control Panelclasses are completely separate from those thatwere originally in the code. They must belinked with the code in order to serve anyreal use. The second major step in the TXLtransformation involves changing all the origi-nal program references to the tuneable param-eter variables to point to the Control Panel.The biggest challenge of this step is ensuringsemantic equivalence.

The TXL transformation must therefore cre-ate a suitable, semantically equivalent refer-ence, which is also syntactically valid, to in-sert in the place of all original references to the

3

Figure 4: Control Panel with Nesting

marked up parameters. For example, a con-structor which is marked up must be replacedwith a call to the constructor method in theControl Panel. Even though references may beof the same kind (such as constructors, assign-ment statements or variable calls), they maytake on several different forms. For example,a constructor in Java can be either a construc-tor with an initialized variable or one withoutan initial value given. These can be furtherbroken down into those which list several vari-able names in the same constructor, and thosewhich declare only one. Each kind of referencemay therefore require several different transfor-mation rules to handle the different cases.

The left-hand side of Figure 5 shows twokinds of constructors marked up for transfor-mation by the STAC tool. The right-handside shows how they have been changed by theSTAC transformation in the source code to re-fer to the Control Panel generated by STAC.

No matter how complex the reference, theTXL transformations must have rules whichcan match and transform all forms of references(within the scope of this project) to point to

Figure 5: Reference Changing

the Control Panel. Furthermore, the transfor-mation must be careful not to add any unnec-essary source code, to ensure that the code re-mains maintainable. The next section exploresthis complicated issue through the use of tworeal-world examples.

3 Examples

Once a system has been transformed by STAC,a user (or autonomic controller) has completecontrol over the tuneable parameters that havebeen marked up. This section details the entirere-architecting process through the use of a tworeal-world open source examples. Each originalarchitecture is first outlined and then a STACtransformation is stepped through.

In addition to the examples detailed be-low, the STAC transformation has been runon other Java programs with varying archi-tectures. Tests were run on STAC through-out the process including regression tests andrule-based functional tests on the TXL codeto ensure that a variety of cases can be han-dled. Tests of functionality were carried outon the Java source code both before and afterthe transformation in order to check semanticspreservation.

Because TXL rules are encoded as a set offormal re-write rules, a more formal validationof semantics preservation could also be carriedout independently using an an inductive proof.However, this would be time-consuming and iswell beyond the scope of the STAC proof ofconcept presented in this paper.

4

3.1 JHotDraw

JHotDraw [4] is an open source graphical userinterface Java application that serves as a toolfor creating graphical editing programs. Onecan also use it as a graphics editor itself. Thesource code for JHotDraw is openly availableand comes packaged in several layers. In to-tal, the JHotDraw version used for STAC con-tains eighteen Java source code packages, in-cluding class files, jar files and required images.It contains approximately 32,500 (total) linesand 16,000 logical lines of code after it has beenfiltered in preparation for the STAC transfor-mation. JHotDraw is chosen as a proof of con-cept system for STAC because it is a widelyused medium-sized Java application which isalso available as open source.

3.1.1 Tuneable Parameters

Once JHotDraw has been selected and ana-lyzed for its main properties, the discovery oftuneable parameters can begin. In the presentprototype this identification is performed man-ually. Once found, the constructor of eachtuneable parameter is marked up by hand. Inthe STAC proof-of-concept prototype, candi-dates for parameters of interest must meet thecondition that they are either stored as a scalartype or in a Vector.

Since the class DrawApplication.java is aclass included in every application in JHot-Draw, we start there. One possible candidateis the int winCount, declared as a static globalvariable, representing the number of open win-dows in the application at one time, and ini-tialized to zero in DrawApplication. This willserve as the first example because winCount iscontained in one class and keeps track of sev-eral different components during runtime. Thedeclaration for winCount is shown in Figure 6and its references are also highlighted.

3.1.2 Transformation

The XML tags in Figure 6 mark winCount asa tuneable parameter. After the transforma-tion, the class DrawApplication.java is changedin the following ways: it imports the ControlPanel (stored in a new package in the samehome directory as the entire source package),

Figure 6: WinCount Declaration and Refer-ences

and all the references to winCount, includingthe constructor, have been changed to referto the Control Panel (Cpanel) class. In addi-tion, the XML markup has been removed. Fig-ure 7 shows this change, while Figure 8 showsthe new Cpanel class. Notice the constructor,accessor and mutator methods for winCountwithin the class Cpanel.winCount. These aregenerated for every tuneable parameter whichis marked up, giving a maintainer the power tomodify and create variables within the ControlPanel.

3.2 Babylon Chat

Babylon Chat [1] is an open source Java in-stant messaging system which can be used forinternet conferences or for group meetings on

5

Figure 7: WinCount References After Trans-formation

Figure 8: Cpanel Class For WinCount

a local host. It boasts special white board ca-pabilities to allow all parties to view an imageduring a group conference. It also allows forpublic and private chat rooms and user authen-tication. Babylon Chat can be run as a Javaapplet within a web page or as a Java applica-tion. It is simple to set up a local host on onecomputer.

3.2.1 Tuneable Parameters

The same features of Babylon Chat which dif-ferentiate its architecture from that of JHot-Draw also lend it to the use of different stylesof tuneable parameters. Because it is not asclearly modularized, Babylon Chat uses manyglobal lists and shared global variables to keeptrack of system parameters. Examples includevariables which keep track of the online traffic

and chat room variables. For instance, the vari-ables representing window height and width foreach application are both stored globally in theBabylon.java class. These can be used in a sim-ilar way to how the winCount variable was usedin the last section.

There are two main complications associatedwith the Babylon Chat code in comparisonwith the more structured JHotDraw code. Thefirst is that the most useful global attributesare stored in Vectors. Because our proof of con-cept of STAC was originally designed to moni-tor only scalar types, Vectors were of little usebut realistically of a lot of interest. Therefore,the STAC transformations (in TXL) were al-tered during the implementation phase to in-clude the ability to mark up a Vector. Inkeeping with the scalar type limitation how-ever, only the attribute Vector.size() is actu-ally monitored within the Control Panel. Thisallows the program to track the number of ele-ments currently inside of a Vector (by using thetrimToSize() and size() methods in the Vectorclass) and watch as it grows and changes. In away this creates a second reference to the Vec-tor which can be thought of as a copy.

The second pertinent complication associ-ated with the source code structure of Baby-lon Chat is that because many variables arestored and passed globally, there are manymore references to tuneable parameters scat-tered throughout the program. This presentsthe opportunity to test STAC’s true capabili-ties at changing all types of references. As aconsequence of the large number of references,there are also many different references to thesame variable name. This requires an addedlayer of transformation by STAC to ensure thateach reference to the Control Panel representsa unique instance and consequently, unique re-naming and updating of these names across thesource code is required. This is a major tech-nical challenge of STAC and is detailed in theexamples later in this section.

3.2.2 Transformation

Consider the variable clientId, declared as aglobal in the class babylonPanel. Initially, thevalue of clientId is set to 0. The purpose ofthis variable is to assign a new clientId to each

6

client thread so that they can be referenced bythis index. ClientId may not seem very usefulfor monitoring or tuning but this example illus-trates how one scalar type can require dozensof reference replacements as well as unique re-naming by the STAC transformation in orderto work properly. It should be noted that ona larger scale this example poses a referencingchallenge because of interface implementationwithin babylonPanel. This is discussed in moredetail in Section 6.2.

To understand the renaming challenge ofthis transformation, consider that many uniqueclasses refer to a clientId. For example, theclass babylonClient declares a mainPanel whichis of type babylonPanel and therefore musthave its own copy of clientId. If the ControlPanel were to create just one copy of main-Panel and within that, one variable for clien-tId, there would be just one copy when in factthere should be one for each mainPanel.

To resolve this conflict, the STAC transfor-mation has a detailed process that checks thenames of all marked up parameters as wellas the Objects which may reference their owncopy of each parameter. In this case, thismeans renaming each mainPanel as a uniquestring called mainPanel# where the numbersign is filled in with a number from 1-9 (Fig-ure 9). Such name changes must be propa-gated throughout each class. This works well inBabylon Chat because the Panel declarationsare local to each class. Thus, it is a matterof finding the unique renaming associated witha class and then changing all other mainPanelreferences within that class to the appropriatemainPanel#. Note that this form of ControlPanel incorporates nested if-statements as away to decipher which Object called a ControlPanel method at runtime. This also requiresadding a parameter representing the callingObject’s name to the methods in the home class(class where the variable is originally declaredand marked up). After the initial method usesthe parameter representing the calling Object’sname, it is replaced with null in the subsequentmethod calls.

Now that a difficult example of scalar typeshas been discussed, it is pertinent to show someVector transformations. Consider the variableuserList, which is declared as a Vector in the

Figure 9: Control Panel with Renaming

class babylonClient.java. This variable storesinformation about the active users online dur-ing any given time. By using STAC to create aControl Panel capable of tuning the size() at-tribute of the userList, it is possible to monitorthe number of active users online at one time.

The first step in this process is to mark upthe tuneable parameter declaration. Becausethis tuneable parameter is a Vector type ratherthan a scalar type, special <vector param>tags are used, to indicate to the transforma-tion rules that the size() attribute of this par-ticular Vector is to be added to the ControlPanel. Figure 10 shows the initial markup inthe babylonClient class. This example is inter-esting because the babylonClient class serves asa very central Object in the Babylon Chat sys-tem. In particular, each babylonPanel has aspecific client associated with it, declared as a

7

Figure 10: Tuneable Parameter Initial Markupof Bablylon Chat Client Class

global variable in the babylonPanel class. Fur-thermore, many of the other classes create theirown Panel to reference when adding attributesto the system. Each of these panels abstractlyhas its own copy of a client, as discussed inthe previous example using clientId. Therefore,this example contains three levels of referenceswhich must be changed to either point to theControl Panel or be renamed to preserve se-mantics.

These necessary reference changes take placeduring the reference tracing and identificationphase of the STAC process. Similar to themainPanel example, each client needs to be re-named and then these renamings must be prop-agated correctly to avoid confusion in otherclasses where the client variable is used. Forexample, if the client variable in class babylon-Chat becomes client1, then every class that ex-tends babylonChat or instantiates a new baby-lonChat Object must propagate this change toits client reference.

4 Applications

Once the STAC tool has been applied, the re-sulting Control Panel provides complete isola-tion of tuneable parameters and acts like theharness under the hood of a car, allowing lo-calized tuning and complete control in a cen-tral location. The uses of the Control Panelare many and include variable monitoring andboth static and dynamic variable tuning.

Monitoring of tuneable parameters can beimplemented as a visualization of parameters

Figure 11: Visualization of JHotDraw Win-Count

at runtime. To demonstrate this for STAC, wehave chosen to use JFreeChart [3], a graphicspackage freely available that has the capabil-ity to create dynamic time-based plots at run-time. With JFreeChart, the Cpanel class canbe instrumented and then visualized dynami-cally. Going back to the JHotDraw example,where the winCount variable was marked upand isolated in the Control Panel, only a fewsimple lines of instrumentation code are neededin the Control Panel to implement dynamicvisualization. The winCount variable simplykeeps track of the various JHotDraw applica-tion windows, because in a drawing editor itmay be necessary to have several windows openat one time. Figure 11 illustrates a screen shotof the dynamic visualization of several JHot-Draw windows running simultaneously. Thefour windows are all separate applications ofJHotDraw. The dynamic plot shows time in-creasing as each new window is opened, result-ing in a stepwise function because they wereopened at corresponding intervals. If severalmore were opened, the value of the winCountvariable would increase accordingly. If any ofthe windows were closed, it would decrease andthis would be visualized in real time.

Figure 12 shows the minimal instrumenta-tion necessary inside the Cpanel class to ex-tract this information. Inside the set() methodfor winCount, all that is needed is the sim-ple writing of values to a buffer which isread by the JFreeChart graphing program asdata. Every time the value of winCount isupdated, this value is written out, and then

8

Figure 12: Control Panel Instrumentation forJHotDraw WinCount Visualization

displayed by the dynamic plot shown above.Note that originally there were four referencesto winCount within the DrawApplication class.Without the STAC re-architecture, the systemwould require four different references everytime it wanted to change the winCount vari-able. Keeping in mind that this is a notablysimple example, scaling this up would providea tremendous increase in control as well as adecrease in necessary maintenance time.

In addition to parameter visualization, theSTAC Control Panel can be used to tune eachparameter of interest either retroactively, aftera visualization, or on-the-fly at runtime. Forvery accurate tuning of specific values, or fortuning which requires some sample data beforeanalysis, static tuning can be applied to theControl Panel after run-time. The isolation oftuneable parameters aids in this process, elimi-nating multiple program accesses, although forco-dependent variables some program manipu-lation may be required.

The dynamic tuning possibilities enabled bySTAC are also intriguing. Through simplevalue comparison, a tuneable parameter can bemonitored until it goes beyond a certain thresh-old and then reset to a more desirable value.This does not apply well to winCount becauseresetting the winCount would not serve a usefulpurpose for system tuning. However, sanity-checking the values in the Control Panel andthen redirecting the program to correct an er-ror is also possible and can be nicely illustratedusing the winCount variable.

Suppose that during program execution,one wanted to minimize overcrowding of the

Figure 13: Adding Threshold Checking in theControl Panel

workspace with respect to JHotDraw applica-tion windows. To do so, one could dynami-cally tune the Control Panel to monitor thewinCount variable and react if the number ofopen JHotDraw Windows becomes larger thana certain threshold size by tiling the rest of theWindows equally and setting the current Win-dow on top. To do so, all that is needed aresome simple additions to the Control Panel.

Within the Control Panel, a simple Robot ob-ject can be created. The Robot class, found inthe AWT package, allows a Robot Object to becreated which can itself create native events inJava at runtime. Therefore, this allows us tomimic a user, in keeping with the autonomicundertone of this experiment. The Robot canthen be instantiated and can perform a specificautonomic action whenever the winCount vari-able goes above its threshold. Figure 13 showsthe Control Panel with a Robot being createdfor a threshold of 4. Figure 14 details the Desk-top view both before,when the number of openwindows is 4 , and Figure 15 shows after, whenthere are five open windows.

As an extension to the above example, theControl Panel can continue in a loop, moni-toring the current value of the winCount vari-able the entire time the application windowsare open. If the number of Windows gets be-yond seven, then the tiling could be consideredtoo crowded and all but the current Windowwill be minimized. Because the loop will con-tinue monitoring the number of Windows, ifthe user closes a JHotDraw application windowlater, the tiling will re-appear. Figure 16 shows

9

Figure 14: Before Dynamic Tuning of Desktop

Figure 15: After Dynamic Tuning of Desktop

the Desktop when the number of open Win-dows has reached seven and all but the currentWindow have been minimized. Figure 17 showslater on in the application, when one windowhas been closed, and the tiling has been reset.

Although there are times when allowing auser to change or create a variable within theControl Panel could be dangerous and poten-tially allow corruption of parameters, a solu-tion to this actually presents itself from withinthe Control Panel. Consider the case where theControl Panel is used to check for and handlecorruption of variables caused by remote ac-cess. To implement this is strikingly simple.Each time a legal set() is called for a tune-able parameter, this value is stored within theControl Panel. Every time a get() is called af-ter this, its return value is compared with thisrecord of the last legal set(). If the two val-ues differ, the value is reset to the last legalcall. This presents a simple, elegant solution

Figure 16: Minimized Windows

Figure 17: After Re-tiling

to the same security threat which is implied byallowing users access to the variables within theControl Panel.

Some of the potential of STAC has been in-vestigated and confirmed in this section us-ing examples of transformations on both JHot-Draw and Babylon Chat. However, there is stillmuch work to be done. Section 6.2 examineswhat limiting assumptions have been made tothis point, and what future projects may evolvefrom the current STAC project.

5 Related Work

The STAC project draws on three main areasof current research in computing. These areautonomic computing, automated refactoring,and source transformation.

Although the domain of autonomic comput-ing is relatively new, there are a few projects

10

Figure 18: Autonomizing Legacy Systems Ap-proach (from [8])

which parallel STAC in their attempts to im-plement self-monitoring and tuning behavioursin existing systems. One of the most closely re-lated projects is Kaiser et. al’s work on Auton-omizing Legacy Systems [8]. In their system,Kaiser et. al develop a protocol for adding aseries of probes to legacy systems which thendeliver instrumentation information to a seriesof gauges that perform monitoring functionsbased upon this information. The implementa-tion is not trivial. It relies upon a layered archi-tecture with the above mentioned probes col-lecting information, the gauges interpreting it,and the effectors performing reconfigurationsand system adaptations as necessary. This sys-tem is shown in Figure 18.

The system is noteworthy for its detailed in-strumentation of a legacy system, transform-ing it into a system which allows for autonomiccontrol. The ideas behind this particular ex-ample draw many parallels with the implemen-tation of STAC. However, the STAC solutionis able to add only one module to any soft-ware system, which encapsulates the idea ofthe probes, gauges and effectors in the workof Kaiser et. al. STAC can be thought of ascombining these layers into one layer, the Con-trol Panel. In a way STAC is working on asubset of the problem tackled by Kaiser et. al.

The reference identification and tracing ofSTAC can be likened to the aspect-orientedstyle of programming, but produces the re-architecture without the separation of code intocut points, thus maintaining the original codestructure and making the maintenance of the

result much simpler. Also, there is no needto recognize underlying scattering or distri-bution of the tuneable parameters in STAC,as one must do to identify the join pointsin aspect-oriented programming, because there-architecture is completely automated basedsolely on the markup of the declaration of vari-ables of interest.

The technical challenges of implementingSTAC can also be compared to those in aspect-oriented programming, which could in princi-ple be used to implement the rearchitecturedone by STAC. However, the problem of lo-cating and tracing every possible reference toa parameter of interest is complex, making itdifficult to identity appropriate syntactic cut-points. Moreover, once rearchitected, STAC’simplementation of the Control Panel as a sep-arately linked module rather than an aspecthas the additional advantage that the ControlPanel can be maintained independently of theprogram itself, with no dependence on source.

Automated refactoring techniques tackletechnical challenges similar to those in STAC,as they work to re-structure code to improveperformance or maintainability and STAC hasan analagous goal of re-architecture. Srini-vasan [10] provides a Modularity Toolkit to au-tomatically re-modularize legacy source code.The system first standardizes the code, elimi-nating discrepancies, much like the automaticrenaming in STAC. After this, the Toolkitbreaks apart the existing modules. Next, itcarefully analyzes the scope and localizationof specific references and variables, using clus-tering to propose and create new, more effec-tive modules. This, again, is followed in STACduring the reference tracing phase. Once thesemodules are put into place, the code is searchedfor dependencies within and between modules,resulting in a re-modularized piece of code.Much of the implementation of the Modular-ity Toolkit relies upon source transformation,particularly with TXL, which leads into the fi-nal domain of related work for this project.

TXL [6] is a programming and rapid pro-totyping language designed to address sourcetransformation problems of a structural na-ture. It uses a hybrid rule-based and func-tional programming style to transform inputdata which must be represented in tree format.

11

TXL has a wide spectrum of possible uses. Keyto the STAC experiment are TXL’s capabil-ities in syntactic manipulation of source code,specifically uses which aim to select and manip-ulate only parts of source code with a particularproperty or of particular interest. Also criticalis TXL’s potential for agility and adaptability.

Many projects involving source restructuringmust be able to focus in on one part of the code,essentially working around the rest to leave thesemantics unscathed. In STAC, it is the tune-able parameters and their references which areof the most importance. It is therefore desir-able to investigate how TXL can be used to cre-ate such a localized focus and ignore the restof the source.

This idea has been explored in the use ofTXL to identify clones in source code [7]. Theterm clone in this sense refers to identical ornear-identical copies of source code dispersedthrough a program or web page. In this case,an island grammar was crafted to detect clones.An extractor written in TXL is then used to“pretty print” the source code islands (contain-ing possible clones) to improve the accuracyof a comparator. Specifically, the transformworks by separating source code features bylines so that the use of the Unix diff commandwill be most effective when comparing code.This promotes the goal of matching clones andnear-miss clones. It is interesting how easily is-lands can be isolated from the rest of the sourcecode.

Another TXL technique of particular interestto our work is agile parsing. In this sense, agilemeans “the ability to use a customized versionof the input grammar for each particular anal-ysis and transformation task” [5]. Specifically,grammar overrides are used to allow for specificcases to be addressed in a transformation. Thearticle also uses an island grammar similar tothat used in [11], again showing how TXL canbe used to focus in on certain aspects of sourcecode while leaving less interesting bits out.

While we have exploited the use of TXL inthe STAC prototype, other source transforma-tion systems such as ASF+SDF [12], Strat-ego/XT [13] or ANTLR [9] could easily serveas well.

6 Summary and FutureWork

The previous several sections have outlined theSTAC transformation tool in detail and fol-lowed several example experiments run withSTAC. In doing so, some key strengths andbenefits of the STAC tool have been high-lighted and important applications have beendiscussed. However, there are limitations andlimiting assumptions which must be adhered toat this time. Such limiting assumptions natu-rally suggest future work in the area.

6.1 Parallel Projects

STAC can be looked at as part of a larger pack-age of projects which, when combined, could beused to automate the entire autonomization ofa system, with respect to tuneable parameters.The first step of this process is the markup oftuneable parameters, which in STAC is doneby hand. However, as a parallel project, theidentification and markup of interesting tune-able system parameters would fit into the pack-age as the first step. In addition, this kind oftool would ensure that STAC receives meaning-ful input to exploit its capabilities and producethe maximum benefit.

Another critical part of the process whichhas only been touched upon in the Examplessection of this paper is the generation and im-plementation of autonomic controllers. Suchcontrollers are currently being implemented forother projects, but generation of controllersbuilt to work specifically with Control Panelscreated by STAC has yet to be explored.

6.2 Current Scope and NaturalExtensions

The scope of STAC presently includes localand global scalar variables which may or maynot extend across classes and which may alsonecessitate several distinct copies at runtime.The first obvious limitation imposed is thatthe variables must be scalar types (with theexception of Vector objects which may be in-strumented for their size attribute). A natu-ral extension of this transformation would beto look at more general objects as tuneable

12

parameters. Although more complicated, thishas actually been started with the addition ofthe Vector markup and isolation in the Con-trol Panel. This would be a very interestingfollow-on research project we hope to be ableto pursue.

A second, less obvious, limitation is thatSTAC can currently miss some kinds of sub-tle references. Section 2.1 uncovered the possi-bility of having many different objects sharingone Control Panel as well as the more simplecase of having just one object using the tune-able parameters at runtime. For the time be-ing, this suffices as a proof of concept as STACworks well to capture most program referencesto tuneable parameters of interest. However,the transformation at present can miss somereferences which change when they are passedas parameters to other objects and methods.At this time, STAC also does not handle alias-ing. This is particularly limiting when a tune-able parameter gets passed into an object con-structor as a reference and then is changedduring the constructor method and reassigned.The handle is effectively lost and this affectsthe usage of this parameter later in the pro-gram. To remedy the loss of these references,it would be necessary to add a pointer to theobject which currently is passing this reference.This has been successfully done in the transfor-mation to solve another problem, namely thatof having multiple objects which share severalcopies of a tuneable parameter, as in the finalBabylon Chat example. Although this is dif-ficult in Java, it may be less cumbersome inother languages.

Java interfaces also presently pose a problemfor STAC whereby the methods which mustbe present in a class when it implements aninterface could be automatically changed bythe transformation when extra parameters areadded to keep track of the calling object’sname. Currently, rules have been added to ex-clude specific methods from having parametersautomatically added to them and this could becontinued on a case by case basis or alterna-tively solved exhaustively with rules to handleall possible interfaces in Java.

Finally, as parallelism is increasingly part ofJava applications, it would be useful for STACto have functionality to handle the case where

multiple threads have access to the same vari-ables and create a race condition. This is con-sidered future work and would require the useof Java synchronization mechanisms to guaran-tee mutual exclusion during tuneable parame-ter access.

As an additional extension, it is future workto integrate the entire STAC transformationinto the Eclipse IDE as a plug-in. Along thesesame lines, it would be interesting to imple-ment the STAC tool for languages such as Cor C++, allowing for more systems to be re-architected and potentially solving some of thecurrent limitations imposed by using Java. Be-cause of the choice of TXL as a transformationlanguage, this should not be too challenging.

6.3 Side Effects on Performance

It is critical to address the question of possibleside effects a STAC transformation may intro-duce to a system. Of paramount importanceis the potential increase in run time caused bythe numerous code changes and TXL transfor-mations involved in STAC. To investigate this,a STAC transformation was run on a simplecommand-line Java interest calculator [2]. Thecompound interest calculator takes in three ar-guments from the command line. The firstis the number of years the money will be in-vested, the second is the monthly investmentamount (in dollars), and the third is the initialamount deposited (in dollars). The programthen calculates the investment growth and to-tal amount at a monthly interest rate of eightpercent with thirty percent deducted for taxes.

A small experiment was run on a time-sharedUnix system, with 8GB of memory, and 4 750Mhz processors in order to investigate the ef-fect of a STAC transformation on system per-formance in terms of run time. The exper-iment compared the run time of the originalcode, to that of the code which had undergonea STAC transformation. The STAC code hadbeen marked up to isolate the variable amount,which is representative of the initial amountdeposited. Each program was then given thesame input arguments, growing progressivelylarger. The results, given in the two tables be-low, show that for small amounts there is vir-tually no difference. However, when very large

13

Input (Years, Monthly, Initial) User Seconds System Seconds1000,1000,1000 2.0 0.05000,5000,5000 6.0 2.0

10,000 , 10,000, 10,000 9.0 4.020,000, 20,000, 20,000 17.0 9.050,000 50,000, 50,000 43.0 24.0

Table 1: Original Source Code Run Times

Input (Years, Monthly, Initial) User Seconds System Seconds1000,1000,1000 2.0 0.05000,5000,5000 6.0 2.0

10,000 , 10,000, 10,000 10.0 5.020,000, 20,000, 20,000 18.0 9.050,000 50,000, 50,000 47.0 23.0

Table 2: Run Times After STAC Transformation

calculations are carried out, there is a signifi-cant difference in the two times, with the STACcode performing at a slower rate. However, onemust consider that this program calculates in-terest every month. Therefore, an input valueof 1000 represents 12,000 calculations. As such,further investigation is needed to determine ex-actly what causes the slowdown introduced bySTAC, and if this is replicated or exaggeratedin programs which involve user interaction.

In addition, there is a lingering sub-problemof variable dependencies. During a STAC re-architecture, a certain parameter may seemto be isolated within the Control Panel butthroughout the program it may be part of achain of variables which are dependent uponone another. Therefore, changing one of theseparameters within the Control Panel, as canbe done in tuning, may inadvertently causechanges or errors in the chain of dependentvariables. A challenging future problem wouldbe to pinpoint this chain of variable dependen-cies and use it to propagate the changes thathappen from within the Control Panel, to thevariables that depend upon the isolated param-eter. This however, is a very complex problemand would have to be done in stages.

6.4 Conclusion

STAC has been shown through proof-of-concept to be capable of isolating tuneableparameters inside an automatically generatedControl Panel specific to the given applica-

tion. In doing so, it preserves semantics andmakes minimal local changes in such a waythat the re-architected code remains maintain-able. The technical challenges of identifyingall of the references to a tuneable parameterare many. They include recognizing the numer-ous different categories of references and replac-ing them with syntactically and semanticallycorrect replacement references to the ControlPanel. These challenges are compounded byhaving multiple objects sharing a tuneable pa-rameter and having to uniquely rename eachObject throughout the source code. The cre-ation of the Control Panel methods is no lesschallenging, requiring a nested class for everyobject instantiation in the source code as wellas a global class where references can be re-directed when necessary.

A number of applications of STAC have beenidentified and illustrated by example. Real-time visualization of the Control Panel activ-ities allows for comprehensive system analysisof a tuning variable which can be used retroac-tively to make appropriate changes. Further-more, dynamic monitoring of variables can beeffectively accomplished by the Control Panelitself, and using simple instrumentation canbe extended to dynamic tuning, mimicking ahuman-user. These examples demonstrate ourgoal of facilitating independent autonomic con-trol through automatic rearchitecture.

14

Acknowledgments

This work is supported by an IBM Faculty In-novation Award and by the Natural Sciencesand Engineering Research Council of Canada.

About the Authors

Elizabeth (Liz) Dancy is a software developerat the IBM Software Laboratory in Markham,Ontario and a former Master’s student work-ing on the STAC project in the Software Tech-nology Laboratory of Queen’s University un-der the supervision of James Cordy. She com-pleted her Bachelor of Computing at Queen’sas well, with a subject of specialization in Soft-ware Design. Her research interests includesource transformation, autonomic computingand software architecture.

James Cordy is the Director of the Schoolof Computing and Professor of Computingand Electrical and Computer Engineering atQueen’s University. From 1995 to 2000 hewas Vice President and Chief Research Scien-tist at Legasys Corporation, a software tech-nology company specializing in legacy softwaresystem analysis and renovation. Dr. Cordyis a founding member of the Software Tech-nology Laboratory at Queen’s University andwinner of the 1994 ITRC Innovation Excellenceaward and the 1995 ITRC Chair’s Award forEntrepreneurship for his work there. He serveson a range of software engineering conferencecommittees and has recently co-chaired severalconferences and workshops including CASCON2005. Dr. Cordy is an IBM Faculty Fellowand has been awarded IBM Faculty InnovationAwards in both 2004 and 2005.

References

[1] BabylonChat.http://visopsys.org/andy/babylon/.

[2] Compound9 Interest Calculator. http://www.ping127001.com/java/Compound9.java.

[3] JFreeChart.http://www.jfree.org/jfreechart/.

[4] JHotDraw 6.0. http://www.jhotdraw.org.

[5] J.R. Cordy. Generalized Selective XMLMarkup of Source Code Using AgileParsing. In International Workshop onProgram Comprehension, pages 144–153,2003.

[6] J.R. Cordy. The TXL Source Transforma-tion Language. Science of Computer Pro-gramming, 61(3):190–210, August 2006.

[7] J.R. Cordy, T.R. Dean, and N. Synyt-skyy. Practical Language-Independent De-tection of Near-Miss Clones. In Proc.CASCON’04: 2004 IBM Centre for Ad-vanced Studies International Conference,pages 1–12, 2004.

[8] G. Kaiser, P. Gross, G. Kc, J. Parekh, andG. Valetto. An Approach to Autonomiz-ing Legacy Systems. In Proc. ACM Work-shop on Self-Healing, Adaptive and self-MANaged Systems(SHAMAN 2002), June2002.

[9] T.J. Parr and R.W. Quong. ANTLR: APredicated LL(k) Parser Generator. Soft-ware, Practice and Experience, 25(7):789–810, 1995.

[10] R. Srinivasan. Automatic Software De-sign Recovery and Re-Modularization Us-ing Source Transformation. Master’s the-sis, School of Computing, Queen’s Univer-sity, 1993.

[11] N. Synytskyy, J.R. Cordy, and T.R. Dean.Robust Multilingual Parsing Using IslandGrammars. In Proc. CASCON ’03: 2003IBM Centre for Advanced Studies Interna-tional Conference, pages 266–278, 2003.

[12] M.G.J. van den Brand, J. Heering,P. Klint, and P.A. Olivier. Compiling Lan-guage Definitions: the ASF+SDF Com-piler. ACM Transactions on Program-ming Languages and Systems, 24(4):334–368, 2002.

[13] E. Visser. Program Transformation withStratego/XT: Rules, Strategies, Tools,and Systems in StrategoXT-0.9. InDomain-Specific Program Generation, vol-ume 3016 of Lecture Notes in ComputerScience. Spinger-Verlag, 2004.

15