This paper presents the research line carried out by the author and his collaborators on programming environments. Most of the experiences and case studies summarized below have been carried out in Pharo1 { an object-oriented and dynamically typed programming language. Programming as a modern activity. When I was in college, I learned programming with C and Pascal using a textual and command-line programming environment. At that time, about 15 years ago, Emacs was popular for its sophisticated text editing capacities. The gdb debugger allows one to manipulate the control ow including the step-into, step-over, and restart operations. The gprof code execution pro ler indicates the share of execution time for each function, in addition to the control ow between each method. Nowadays, object-orientation is compulsory in university curricula and mandatory for most software engineering positions. Eclipse is a popular programming environment that greatly simpli es the programming activity in Java. Eclipse supports sophisticated options to search and navigate among textual les. Debugging object-oriented programs is still focused on the step-into, step-over and restart options. Pro ling still focuses on the method call stack: the JPro ler2 and YourKit3 pro lers, the most popular and widely spread pro lers in the Java World, output resource distributions along a tree of methods. Sending messages is a major improvement over executing functions, which is the key to polymorphism. Whereas programming languages have signi cantly evolved over the last two decades, most of the improvements on programming environments do not appear to be a breakthrough. Navigating among software entities often means searching text portions in text les. Pro ling is still based on methods executions, largely discarding the notion of objects. Debugging still comes with its primitive operations based on stack manipulation; again ignoring objects. Naturally, some attempts have been made to improve the situation: Eclipse o ers several navigation options; popular (and expensive) code pro lers may rely on code instrumentation to nd out more about the underlying objects; debuggers are beginning to interact with objects [1,2]. However, these attempts remain largely marginal. Pro ling. Great strides have been made by the software performance community to make pro lers more accurate (i.e., reducing the gap between the actual applica1 http://pharo.org 2 http://www.ej-technologies.com/products/jprofiler/overview.html 3 http://www.yourkit.com
tion execPurtoiofinlinagn.dA tghreeatper↵oortlehrasrbeepeonrmt)a.deAbdyvtahnecsoefdtwtaerechpenrifqorumeasncheacvoemmbueneintyproposed such as vtaormiaabkeleprsoafimlerps lminogre taicmcuerat[e3(]i.aen.,dredpurcoinxgiethsefgoarp tbiemtweeeenxtehceuacttiuoanl a[p4p,l5ic]a.-However, much lestsionatetxeecnuttiioonnahndasthebpereonfilepr areidportto). Athdveanvciesdutaeclhoniuqtupesuhtavoefbaeenpprroopolese.dConsider such as variable sampling time [?] and proxies for time execution [?,?]. However, JPro lermaunchd leYssoautrtKenittio,nthwaos bpeeonppualiadrtocothdeevpisuroal oluetrpsutfoorf athperofiJlae.vCaonpsriodegrramming languageJ:PprroofilelreacnrdaYwoluinrKgiti,stwlaorgpeoplyulasrupcopdoerptreodfilberys ftoerxttheseJaarvcahperso.grWamemaindgdress this limitationlanwguitaghe:Ipnrtoifi.le crawling is largely supported by textual search. We contribution to addressing this limitation with Inti.
Inti is a sunburst-like visualization dedicated to visualize CPU time distribution. Consider the following Java code: class A { public void init() { ... } public void run() { this.utility(); ... } public void utility() { ... } } class C { public void run() {
A a = new A(); a.init(); a.run(); } public static void main(String[] argv) { new C().run(); } } init() main() C.run()
A.run()
Inti is a sunburst -like visualization dedicated to visualizing CPU time distribution. Consider the code and arc-based visualization given in Figure 1. The code indicates a distribution of the computation along ve di erent methods. Each method frame is presenteFdiga. 1s: aEnxaamrpcl.e TofhInetibaseline represents the starting time of the pro le. The angle of each arc represents the time distribution taken by the method. In this example, C.main and C.run have an angle of 360 degrees, meaning thaTthtehceosnetrtivwedo emxaemthpoledgsivceonnasbuomveeis1v0i0su%aliozefdthweithCIPntUiatsimsheow.nMientFhiog-ds A.init ure ??%. Each method of the J(avtahecosdee agriveenilalubosvter aistirveperesented by an arc in consumeFsig6u0re ??a.nMdetAh.odruCn.ma4i0n%by the disk A, C.run by arc B, A.ninuimtbbyerC,s)A..rTunhbey distance between DaanndarAc.utainlidtytbhye Ec.eTnhteebraoseflinteherepvriessuenatlsizthaetisotanrtiinngdtiicmaeteosf tthheeprdoefilpe.th of the frame in Tthhee amngelethoofedacchaallrcsrteapcrkes.enAtsntheestteimdemdiesttrhiboudtiocnaltlakiesnrbeyprtheesemnettehdoda.sIna stacked arc. tmheistheoxdasmcpolen,suC.mmeai1n0a0n%d oCf.rthune hCaPvUeatnimaen.gMle eotfh3o6d0s dAe.girneiets,cmonesaunminegs t6h0e%se atwndo Inti eAx.rpulno4it0s%.tEhaechsumnetbhuodrsftramreepisrepsreesnetnatetdioansainnarwc.hDiicshtanccoelboertsweaenreanaalrloccated to and the center of the visualization (where the A label is located) indicates the particular portion of the sunburst. For example, colors are picked to designate particular classes, methods or packages in the computation: the red color indicate classes belonging to a particular package (e.g., Figure 2).
The bene ts of Inti are numerous. Inti is very compact. Considering the number of physical spaces taken by the visualization, Inti largely outperforms the classical tree representation: Inti shows a larger part of the control ow and CPU time distribution in much less space. Details about each stack frame are accessible via tooltip. Hovering the mouse cursor over an arc triggers a popup window that indicates the CPU time consumption and the method's source code. Delta pro ling. Understanding the root of a performance drop or improvement requires analyzing di erent program executions at a ne grain level. Such an analysis involves dedicated pro ling and representation techniques. JPro ler and YourKit both fail at providing adequate metrics and visual representations, conveying a false sense of the root cause of the performance variation.
C D
A B
E
Δ # executions Δ time
Color A B
A invokes B
We have proposed performance evolution blueprint, a visual tool to precisely compare multiple software executions [6]. The performance evolution blueprint is summarized in Figure 3. A blueprint is obtained after running two executions. Each box is a method. Edges are invocations between methods (a calling method is above the called methods). The height of a method is the di erence of execution time between the two executions. If the di erence is positive (i.e., the method is slower), then the method is shaded in red; if the di erence is negative (i.e., the method is faster), then the method is green. The width of a method is the absolute di erence in the number of executions, thus always positive. Light red / pink color means the method is slower, but its source code has not changed between the two executions. If red, the method is slower and the source code has changed. Light green indicates a faster non-modi ed method. Green indicates a faster modi ed method.
Our blueprint accurately indicates roots of performance improvement or degradation: Figure 3 indicates that method B is likely to be responsible for the slowdown since the method is slower and has been modi ed. We developed Rizel, a code pro ler to e ciently explore performance of a set of benchmarks against multiple software revisions.
Testing. Testing is an essential activity when developing software. It is widely acknowledged that a test coverage above 70% is associated with a decrease in reported failures. After running the unit tests, classical coverage tools output the list of classes and methods that are not executed. Simply tagging a software element as covered may convey an incorrect sense of necessity: executing a long and complex method just once is potentially enough to be reported as 100% test-covered. As a consequence, a developer may receive an incorrect judgement as to where to focus testing e orts.
Coverage: 40.57%
Coverage: 60.60% M
By relating execution and complexity metrics, we have identi ed essential patterns to characterize the test coverage of a group of methods [7]. Each pattern has an associated action to increase the test coverage, and these actions di er in their e ectiveness. We empirically determined the optimal sequence of actions to obtain the highest coverage with a minimum number of tests. We present test blueprint, a visual tool to help practitioners assess and increase test coverage by graphically relating execution and complexity metrics. Figure 4 is an example of a test blueprint, obtained as the result of the test execution. Consider Method M: the de nition of this method is relatively complex, which is indicated by the height of the box representing it. M is shared in red, meaning it has not been covered by the unit test execution. Covering this method and reducing its complexity is therefore a natural action to consider.
Two versions of the same class are represented. Inner small boxes represent methods. The size of a method indicates its cyclomatic complexity. The taller a method is, the more complex it is. Edges are invocations between methods, statically determined. Red color indicates uncovered methods. The gure shows an evolution of a class in which complex uncovered methods have been broken down into simpler methods.
Debugging. During the process of developing and maintaining a complex software system, developers pose detailed questions about the runtime behavior of the system. Source code views o er strictly limited insights, so developers often turn to tools like debuggers to inspect and interact with the running system. Traditional debuggers focus on the runtime stack as the key abstraction to support debugging operations, though the questions developers pose often have more to do with objects and their interactions [8].
We have proposed object-centric debugging as an alternative approach to interacting with a running software system [9]. By focusing on objects as the key abstraction, we show how natural debugging operations can be de ned to answer developer questions related to runtime behavior. We have presented a running prototype of an object-centric debugger, and demonstrated, with the help of a series of examples, how object-centric debugging o ers more e ective support for many typical developer tasks than a traditional stack-oriented debugger. Visual programming environment. Visualizing software-related data is often key in software developments and reengineering activities. As illustrated above in our tools, interactive visualizations play an important intermediary layer between the software engineer and the programming environment. General purpose libraries (e.g., D3, Raphael) are commonly used to address the need for visualization and data analytics related to software. Unfortunately, such libraries o er low-level graphic primitives, making the specialization of a visualization di cult to carry out.
Roassal is a platform for software and data visualization. Roassal o ers facilities to easily build domain-speci c languages to meet speci c requirements. Adaptable and reusable visualizations are then expressed in the Pharo language. Figure 5 illustrates two visualizations of a software system's dependencies. Each class is represented as a circle. On the left side, gray edges are inheritance (the top superclass is at the center) and blue lines are dependencies between classes. Each color indicates a component. On the right side, edges are dependencies between classes, whereas class size and color indicate the size of the class. Roassal has been successfully employed in over a dozen software visualization projects from several research groups and companies.
Future work. Programming is unfortunately lled with repetitive, manual activities. The work summarized above partially alleviates this situation. Our current and future research line is about making our tools not only object-centric, but domain-centric. We foresee that being domain speci c is a way to reduce the cognitive gap between what the tools present to the programmers, and what the programers expect to see from the tools. 4. A. Camesi, J. Hulaas, W. Binder, Continuous bytecode instruction counting for cpu consumption estimation, in: Proceedings of the 3rd international conference on the Quantitative Evaluation of Systems, IEEE Computer Society, Washington, DC, USA, 2006, pp. 19{30. doi:10.1109/QEST.2006.12.
URL http://portal.acm.org/citation.cfm?id=1173695.1173954 5. A. Bergel, Counting messages as a proxy for average execution time in pharo, in: Proceedings of the 25th European Conference on Object-Oriented Programming (ECOOP'11), LNCS, Springer-Verlag, 2011, pp. 533{557.
URL http://bergel.eu/download/papers/Berg11c-compteur.pdf 6. J. P. S. Alcocer, A. Bergel, S. Ducasse, M. Denker, Performance evolution blueprint: Understanding the impact of software evolution on performance, in: A. Telea, A. Kerren, A. Marcus (Eds.), VISSOFT, IEEE, 2013, pp. 1{9. 7. A. Bergel, V. Pen~a, Increasing test coverage with hapao, Science of Computer
Programming 79 (
URL http://people.cs.ubc.ca/~murphy/papers/other/ asking-answering-fse06.pdf 9. J. Ressia, A. Bergel, O. Nierstrasz, Object-centric debugging, in: Proceeding of the 34rd international conference on Software engineering, ICSE '12, 2012. doi:10.1109/ICSE.2012.6227167.
URL http://scg.unibe.ch/archive/papers/Ress12a-ObjectCentricDebugging. pdf