Quantifying the Encapsulation of Implemented Software Architectures

TL;DR: We studied which static architecture metrics are correlated with a high ratio of local changes (i.e. changes made to only a single component). An analyses of 10 open-source systems shows a positive relationship between the percentage of code only used within a component and local change. We conclude that having small, clearly defined interfaces for your components lead to more local changes, which are easier to implement and test. 
 

---

This week I had the pleasure to present our paper Quantifying the Encapsulation of Implemented Software Architectures at the 30th International Conference on Software Maintenance and Evolution. What follows is the high-level story I have presented (using these slides), if you want all the details you can find the complete paper here.

Inspecting the title of our paper we see that it is about quantifying the encapsulation of implemented architectures. To understand what this paper talks about let's start by examining these concepts more closely.

Implemented software architectures

As a whole, software architecture is defined as:

the organisational structure of a software system including components, connections, constraints, and rationale. 

If we focus on the implementation within the code, we can only observe the components and the connections, stuff like constraints and rationals are normally defined in the documentation. 

As an example, consider the figure on the right, which depicts a hypothetical system. We can clearly see the high-level components which (hopefully) implement a distinct functionality, and the connections that exist between these components. To get such a high-level overview of the system you can normally open up the source-code repository or look for it in the documentation. Should that fail you can always fall back to a whiteboard, a marker, and a software engineer working on the system, I still have to meet the software engineer who cannot draw such a picture of their system.

Quantifying encapsulation

Encapsulation revolves around localizing the design decisions which are likely to change (a process also known as information hiding). If done correctly, we would see that the changes to a system are done to source-code modules which are located near each other, preferably in the same component. This makes it easier to implement the change (since we do not have to jump between components) and easier to test the change (since we have less components to test).

Given a system, a definition of its components, and all changes made in the past years we can easily determine whether the process of encapsulation has been successful by using the concepts of local change and non-local change as introduced by Yu et al. 

As a first step we classify each change-set in the history of a system (e.g. all commits or pull-requests) as either local or non-local. When a change-set contains source-code files from only a single component it is considered to be local, if more than one component is touched the change-set is considered to be non-local. The figure on the left shows an example of each type of change-set, blue for local and brown for non-local.

After this classification we can quantify the success of the encapsulation by simply dividing the number of local change-sets by the number of total change-sets. For example, the figure on the left shows a change-set series containing ten change-sets of which seven are local, leading to a quantification of 0.7 for encapsulation.

As explained above we would like to see as many local change-sets as possible, so we want this number to be as high as possible. However, since we also expect to see some non-local changes for cross-cutting concerns such as logging we would not expect to see a ratio of 1 that often. To get a feel for which numbers are good we can calculate this metric for many systems, thus creating a benchmark which can tell us whether this 0.7 is relatively good or bad compared to other systems.

Up until now we have only seen concepts introduced by others, which makes a rather sub-standard research paper. So what is the problem here?

The timing problem(s)

The main issue with calculating the encapsulation of an implemented architecture using the concepts above is that it can only be done after a project has been finished. Although nice to know at that point in time, it would be nicer if we could calculate a metric on the project which provides some sort of indication of the encapsulation of the system now. Given that the current literature lists over 40 software architecture level metrics (an overview can be found here) we should be able to find something right?

So we designed an experiment to see which software architecture metric we can calculate on a single snapshot of the code (i.e. snapshot-based encapsulation) is correlated with the encapsulation calculated over time (i.e. the historical encapsulation). 

The first set-up was straight-forward, select some systems, calculate the snapshot-based metrics, calculate the historical encapsulation, run the statistics, and bob is your uncle. The figure on the right shows a sketch of the outline of this set-up, using the number of components as an example of a snapshot-based metric. At a glance this set-up seems correct, but after a while we figured out there it contains a (rather serious) flaw, any thoughts?

Notice that we calculated the number of snapshots based on the situation after the last change-set. But this change-set makes a change to the system, and can also change the number of components! 

More graphically, consider the chart on the left which shows the number of components on the x-axis and the change-sets on the y-axis. We see that there is a period where we have 2 components, then a period where there are 5 components, only to drop to 4 components in the last change-set. Trying to correlate the historical encapsulation of 0.7 with a number of four components is clearly incorrect, since most of the time the number of components was either 3 or 5. 

To remedy this problem we adjusted the design of our experiment. Instead of using all of the history to calculate the historical encapsulation based on all of the change-sets we instead calculate the historical encapsulation based on the periods in which the snapshot-based metric is stable. 

In the example above this gives us two pairs of numbers, (2, 0.6) and (5, 0.75), to indicate the number of components and the historical encapsulation for that period. Note that we do not calculate a pair for when there are four components, since we do not consider a single change-set a 'period'.

 

The results

Now that we know how to do the experiment we can execute it. First we selected 10 open-source software systems to investigate, giving us over 60 years of historical data. Secondly, we filtered the snapshot based software architecture metrics available down to a list of twelve metrics. This list includes simple metrics such as the number of cyclic dependencies or the number of binary dependencies, but also more involved software metrics such as the metrics which form the basis for our dependency profiles. 

These last metrics are (unfortunately) not yet widely known, so let me explain them quickly. In a dependency profile we divide the source-code modules within a component into four distinct categories based on the dependencies from and to other components. We can calculate the profile by calculating the percentage of code of the system in each category, thus a profile (50, 20, 25, 5) indicates that 50% of the code is internal to components, while 20% is depended upon from other components, 25% of the code depends on code from other components, leaving 5% in the last category of code which is depended upon and depends upon code from other components. 

After crunching all the numbers the result is that there is a positive correlation between the historical encapsulation and the percentage of internal code. In other words, we observed that systems which contain a higher percentage of internal code also exhibit periods with a higher ratio of local changes.

So what can I do with this result?

Given that more internal code is related with a higher ratio of local changes I would argue that you should strive towards an implementation with as much internal code as possible. 

One way to achieve this is to define clear, small, and specific interfaces for your components. While this is often done correctly for the incoming interface of a component, the outgoing interface is often overlooked, leading to a large outgoing interface with a higher risk of needing change when other components are touched. 

More details ...

Interested in reading more about the design of the experiment? Or do you want to know how well other metrics correlate? (spoiler: they don't) Want to know more about our ideas about how the inspected software architecture metrics can be improved? Download the full paper here!

When do you consider a software metric useful?

Do you use software metrics in your project? Which ones? Why do you use those software metrics?

The answer to question one is probably 'Yes'. The answer to question two may vary, but hopefully the answer to question three is: "because I find them useful".

For me, the usefulness of a software metric is determined by two properties. On the one hand the software metric should be a correct quantification of what I want to measure, while on the other hand the value of the metric should provide enough information to make a decision.

To verify whether a metric measures what you want it to measure you can examine the value of a metric for a small number of cases, or you can conduct a more quantitative experiment to understand the statistical behavior of a the metric on a large group of systems/components/units. The nice thing about such an experiment is that you can conduct it in a relatively safe lab-environment using open-source systems.

Because of its relative easiness this type of evaluation has been done extensively over the past years.  Virtually every scientific paper on software metrics includes at least one or two case studies, but often researchers also examines the statistical relationship between the value of the (newly proposed) metric and other desirable attributes. For example, we did this for our Component Balance and Dependency Profiles metrics.

To understand whether a metric can be effectively used in a decision making process is more complicated. First, you need to ensure that the metric is available for a large number of projects for an extended period of time. Secondly, you need to observe the people involved in the projects and record discussions/decisions involving the metric. Lastly, the gathered data needs to be analyzed to extract usage patterns and identify areas for improvement.

This second type of evaluation requires quite some time, patience, access to a wide range of software projects in various stages of development, and you need to be able to communicate with the people involved in these projects. Basically, you need to find a company which allows you to conduct this type of research, which might be the reason why I did not find any study which evaluates software metrics in this way.

You can probably guess which company allowed me to conduct this research. Indeed, within the environment of the Software Improvement Group me and my co-authors were allowed to study the usefulness of our architectural metrics. The full details of the evaluation design and the results are available in our ICSE 2013 SEIP paper:

Evaluating Usefulness of Software Metrics - an Industrial Experience Report.

which is going to be has been presented at the ICSE conference in San Fransisco! The slides of this presentation can be found by clicking this link.

Naturally, I am very proud of this paper. In particular because it takes the evaluation of the software metrics one step beyond the usual statistical validation. What do you think, should all metrics be validated like this or should we look at other aspects as well?

Detecting Cross-language Dependencies Generically

Most systems I see are not written in just a single technology. Instead, dedicated technologies  are used for the front-end (think JavaScript, HTML, JSP), the server-side business logic (think Java, C#, C, insert-your-favorite-programming-language-here) and the data-storage (think any flavor of SQL or NoSQL). 

To get an initial understanding on how all of these technologies work together in the system it is needed to determine what the dependencies between these technologies are. Where does the JavaScript connect to the server? And how is the stuff we see on the front-end connected to the stuff stored in the database?

For the most common cases there is tool-support available to detect these dependencies (semi)-automatically. However, extending these tools with support for a new language is not trivial because the techniques used requires you to deeply understand the full language of the new technology.  

Until now...

Last year I had the pleasure of co-supervising Theodoros Polychniatis for his internship at the Software Improvement Group on the subject of Detecting dependencies across programming languages. After diving into the available literature and soliciting requirements from consultants he managed to create a prototype tool which implements a relatively simple algorithm to detect dependencies across source-code modules written in different technologies. 

The first evaluations show that the algorithm is capable of producing a relatively good recall (e.g. finding the dependencies that you want) and a reasonable precision (e.g. finding only actual dependencies). As always, the behavior of the algorithm greatly depends on the parameters used, but the initial results are positive enough to continue exploring this idea.

Apart from producing the thesis Theodoros was also the driving force behind the paper:

 'Detecting cross-language dependencies generically'

by  Theodoros Polychniatis, Eric Bouwers, Joost Visser, Jurriaan Hage and Slinger Jansen.

This paper will be presented (and published) at the 17th European Conference on Software Maintenance and Reengineering (CSMR 2013). If you are considering attending CSMR make sure you drop by at the Software Quality and Maintainability (SQM) workshop for a chat and a very interesting key-note!

As a closer, here is the abstract of the paper:

In order to evaluate large, heterogeneous information systems (i.e., comprising modules developed in diverse programming languages) a method to detect dependencies among these modules is needed. Although there is a variety of methods that can detect dependencies within a single programming language, the available cross-language detection methods use extensive language specific information to parse and analyze modules written in different languages.
In this paper, a new method for detecting cross-language dependencies is proposed. This method is generic, yet accurate and can support new languages with minimal effort. To evaluate the method, a tool was created and a series of experiments was conducted on a small case study for which dependencies had been extracted manually. The evaluation shows that the method is effective, extensible and easily explainable.

Tutorial: Software metrics - Pitfalls & Best Practices

The International Conference on Software Engineering (ICSE) is one of the (if not the) largest conference on software engineering in the world. This year, the conference will take place in the Hyatt Regency, San Francisco, U.S.A. 

At this conference, Arie van Deursen, Joost Visser and I will be organizing a three-hour tutorial. To quote our proposal: 

Using software metrics to keep track of the progress and quality of products and processes is a common practice in industry. Additionally, designing, validating and improving metrics is an important research area. Although using software metrics can help in reaching goals, the effects of using metrics incorrectly can be devastating. 

In this tutorial we leverage 10 years of metrics-based risk assessment experience to illustrate the benefits of software metrics, discuss different types of metrics and explain typical usage scenario’s. Additionally, we explore various ways in which metrics can be interpreted using examples solicited from participants and practical assignments based on industry cases. During this process we will discuss four common pitfalls of using software metrics.

In particular, we explain why metrics should be placed in a context in order to maximize their benefits. A methodology based on benchmarking to provide such a context is discussed and illustrated by a model designed to quantify the technical quality of a software system. Examples of applying this model in industry are given and challenges involved in interpreting such a model are discussed. 

This tutorial provides an in-depth overview of the benefits and challenges involved in applying software metrics. At the end you will have all the information you need to use, develop and evaluate metrics constructively.  

It is yet unclear when the tutorial takes place (either before or after the main conference), I will update this post as soon as this information is available. The tutorial has been given on May 21, see the ICSE program for more details. The slides are now available by clicking here.

Meanwhile, please feel free to share your thoughts, remarks or questions on this topic via the comments or any other means of communication!

WICSA 2011

And yet another publication to announce! I am very happy to tell you all that the paper "Quantifying the Analyzability of Software Architectures" by Bouwers, Correia, van Deursen and Visser has been accepted at the 9th Working IEEE/IFIP Conference on Software Architecture!

Abstract:
The decomposition of a software system into components is a major decision in any software architecture, having a strong influence on many of its quality aspects. A system’s analyzability, in particular, is influenced by its decomposition into components. But into how many components should a system be decomposed to achieve optimal analyzability? And how should the elements of the system be distributed over those components?
In this paper, we set out to find answers to these questions with the support of a large repository of industrial and opensource software systems. Based on our findings, we designed a metric which we call Component Balance. In a case study we show that the metric provides pertinent results in various evaluation scenarios. In addition, we report on an empirical study that demonstrates that the metric is strongly correlated with ratings for analyzability as given by experts.

(and yes, maybe twitter is not such a bad idea if I keep on writing these short posts :)

SQM 2011

Yes I know, it is a bit late. However, I am still very pleased that the paper Preparing for a Literature Survey of Software Architecture using Formal Concept Analysis by L. Couto, J.N. Oliveira, M.A. Ferreira and E. Bouwers has been accepted (and presented) at the Fifth International Workshop on Software Quality and Maintainability!

The abstract:

The scientific literature on Software Architecture(SA) is extensive and dense. With no preparation, surveying this literature can be a daunting task for novices in the field. This paper resorts to the technique of Formal Concept Analysis (FCA) in organizing and structuring such a body of knowledge. We start by surveying a set of 38 papers bearing in mind the following questions: “What are the most supported definitions of software architecture?”, “What are the most popular research topics in software architecture?”, “What are the most relevant quality attributes of a software architecture?” and “What are the topics that researchers point out as being more interesting to explore in the future?”. To answer these questions we classify each paper with appropriate keywords and apply FCA to such a classification. FCA allows us to structure our survey in the form of lattices of concepts which give evidence of main relationships involved. We believe our results will help in guiding a more comprehensive, in-depth study of the field, to be carried out in the future.

A 5 star system!

My presentation on JFall 2009 went very well, there was a big audience (they barely fit into the room) and there was lot's of interaction going on during the talk. People where asking critical questions and provided good comments.

The topic seemed to make people pretty enthusiastic. Especially the examples of a really complex method, the biggest method and a method with a lot of parameters.

In the presentation I answered the following two questions: 1) what is a 5-star system, and 2) how can I get one? The answer to the first question is: "a system that receives the highest rating in the TUVit Trusted Product Maintainability Certification". I explained what this certificate entails and how the complete procedure works (something which is also summarized over here).

The second question is answered by the following mantra: "make sure that your code is small, simple and specific".

If you cannot make your code small, simple and specific, take a step back and look at the abstract picture (the overall design) of your project. Why does this design disallow you to make your code small, simple and specific?

Can you model stuff differently? Is there a way to abstract over details that clutter your code? How can this type of functionality be grouped in a better way? Try to determine why the design (or your framework) is restricting you and solve that problem. The result will be a more maintainable system.

Naturally, these answers are just the core of the talk, a more complete overview of the presentation is provided by the Atos Application and Development blog (Dutch). For those interested, the slides can be found here.

All and all a nice experience, on to JSpring 2010!?

A 5 star system?

This week I received notice that my proposal for a presentation at the J-Fall 2009 was accepted. So on the 11th of November I will be discussing what a 5-star system is and how to get it. For those of you who cannot wait to find out what it means to get stars for your system can take a quick look over here.

The full abstract of the presentation can be found here (in Dutch). If you want to attend you should register yourself over here.

Hope to see you in Bussum!

I present, you present ....

Last week I was in Canada for the ICSM 2009 (combined with a very relaxing vacation btw) where I got to present my first paper of my PhD. The room was a filled with about 50 attendees and, even though I was a bit nervous, the presentation went pretty well. There where some interesting questions and comments, and even a small discussion that had to be taken off-line (which is now again on-line).

During the rest of the ICSM I talked to various people about the presentation and the paper and it seems that the topic certainly appeals to several people. Which is good to know since I think I will be spending some more time in researching it.

For those of you that are interested in the slides, please take a look at the slides page of the ICSM, or just follow the direct link.

To be honest, these slides are not exactly the ones I used during the presentation. I cheated a little bit by splitting a slide 22 in two slides, just so that you can actual see the contents of a table. In the original version there was an animation that removes the numbers before showing the crosses, but this behavior is not transferred to the pdf-version of the slides. I can tell you from personal experience that it will increase your blood pressure if you notice this when you are giving your presentation.

Anyhow, at least I learned now to check the pdf-version of my slides before I give I a presentation, just in case the laptop on which I made the presentation does not play nicely with the available beamer :)

SQM and CSMR 2009

Last week, I was in Kaiserslautern to attend the 2009 version of SQM and CSMR. Both the workshop and the main conference were hosted at Fraunhofer IESE, which turned out to be an excellent host.

All of the conferences I have attended up until now lasted only for a day, so I did not really know what to expect of four days of presentations. I was a little bit afraid that I would not be able to pick up any new information on the last day, but everything turned out to be fine. Every day brought at least two interesting presentations, and definitely one interesting conversation about the current research somebody is doing. I have met several interesting people (who might be interested in doing some research together), and picked up quite a few new ideas. Unfortunately, it is too much to write down all at once, but I will try to post updates on this on a more regular basis.

What I found particularly interesting was the fact that several people mentioned the same two things on various occasions. The first one is that PhD students should not start from scratch when they are implementing their ideas. Although some students are using more generic development frameworks (like for example Eclipse), there are still people out there that start everything from scratch. This does tend to take up a lot of time and usually results in tools that "should be publicly available before I finished my thesis, I just want to clean it up a bit first". I am not really sure how this problem can be solved (and neither did the people at the Industry Panel Discussion), but I do hope that my future tools will not suffer the same fate.

The second thing that was repeated a few times is the call for more empirical evidence for the usefulness of ideas and tools. However, the lack of publicly available industrial systems and cost-data makes it hard for the average researcher to provide this evidence. Fortunately, there are ways to overcome this issue. One could, for example, work together with companies that have access to this type of data. Just a matter of sending and e-mail and explain your ideas and needs to the right person I guess... ;)

Another JFall

Today I attended the JFall 2008. Another instance of the conference of the NL-JUG aimed at all the Java programmers in Holland. Since two of my colleagues got the last two tickets I had the pleasure of walking to the location with only one of them, the other one missed his train.

Anyhow, let us see what the day has given us.

Duane Nickull was the first speaker of the day. He shared his view on what web2.0 and SOA was. We saw many slides (with many boxes and arrows) explaining which entities play a role in these types of technologies. Unfortunately, his presentation was a little abstract, because I didn't notice any concrete examples (maybe I missed them though). On the other hand, his anecdotes were nice and interesting. The one that I liked the most was about a company that is trying to apply the open-source software development way of contributions to the making of movies. Deciding what is in a movie sure sounds fun to me, so there should be some kind of business model in there right?

The second talk I attended was given by Allister Smith and was titled "pragmatic Java". Hoping on a presentation full of pragmatic solutions for common problems, I was a bit disappointed when the talk compared Java to languages such as Phyton and PHP. An example program was given in Python and then redone in Java using the spring-framework. Naturally, the Java example was much more bloated. After this, an example of a Java implementation was given in which the typing was essentially stripped away (by using only Objects) and value-passing was done through Maps and Lists. The speaker had a good point in the sense that this can be just as quick and short as a scripting language, but using Java for this just feels wrong. It is an example of using a language because of the language, not because it has the features you need for a project.

The last talk before the lunch was an introduction to the Java Memory Model. Peter Veentjer (who seems to know a lot about these things) gave a nice tour around some of the pitfalls of Java concurrency. Although the talk was a little low level, it was really understandable. I do not have to deal with concurrency at the moment, but some of the pointers are good to keep in the back of your mind during development. Certainly a useful presentation.

Right after the lunch the evangelists of Sun gave the second keynote of the day. Normally I do not really like these kind of talks because they can feel like you are watching a long tv-commercial without seeing something useful. However, I was pleasantly surprised that the demo's showed some really nice stuff (besides being slick of course). It turns out that in the new version of JavaFX it is possible to drag applets from your browser to your desktop and still work! There must be some real-world usage scenario's for that I guess. Also, a demo was given of alternative ways to use your Wii-mote. Definitely a better talk then I had expected.

After the demo I was quick enough to sneak into the presentation of Huub van Thienen about closures in Java. I was lucky to have a seat because the room was really packed with people. Huub gave a really nice introduction into what closures are, and how they could be used in Java. His presentation showed the pros and cons without giving away his own opinion. Actually, he even promised a candy-bar for the person that could guess his opinion about the subject. I still do not know :(. Even though I knew most of the thing already (because of knowing Haskell), I think this was the best presentation of today.

As a last presentation I attended a Hands-on-lab about dealing with legacy code. Since we are usually analyzing legacy code for customers, I thought it would be nice to hear other peoples opinions about the subject. The set-up of the lab was really nice, first some explanation, then some coding, some more explanation and so on. Unfortunately, we ran out of time in the end, but it was still a nice experience. I also relearned one of my pitfalls during the session. When trying to fix a bug I tend to first figure out how to fix a problem, than actually fix it, and later on write a test for it. Usually, I also try to run the test without the fix to see whether it fails, but sometimes I forget. To counter this I should first write a test, and then fix the problem. However, sometimes it is too tempting to just fix the problem :)

All and all it was an interesting day. No real eye-openers, but certainly not a complete waste of time. On to the JSpring I would say!

A Java-Summercamp

It has been a while , but on the 29th of August I have attended the 2008 version of the Java Summercamp. This gathering was organized by profict, a dutch IT-company. They have an office with a great view (picture), now that is what I call a green working environment!

The topic of this day was Domain Specific Languages (DSL's). Since my talk about fluent interfaces at the J-Spring 2008 I became more and more interested in this topic. I hoped to hear more about why you would want to use a DSL, and see some examples of DSL's in practice. Luckily, I got what I wanted.

The first speaker was Neal Ford. His first presentation (slides) gave a general overview of the usefulness of DSL's. He argued that Java can be seen as a framework-oriented language. Nowadays, a Java-programmer uses many frameworks which he ties together with configuration-files written in XML. He proposes to use a DSL to abstract over these large configuration files in order to make it easier to tie frameworks together. He also gave an overview of some techniques to implement (mostly internal) DSL's. Actually, his second presentation mostly consisted of examples of DSL's in various languages. It is always fun to see examples of what you can do in other languages.

Sven Efftinge was the second speaker with his presentation (slides) about XText. I was surprised to see that it actually looked very simple to 1) create a DSL by typing in EBNF 2) generate an eclipse editor for this DSL with the click of a button and 3) generate a generator for your DSL using the same click. Naturally, everything was already set-up so that it looked easier then it actually is. I have tried to make a small example to show at the office, but failed miserably to get the generator to do what I want. Anyhow, if you have a spare afternoon then checking out this project is certainly worth the effort.

The third (and last) speaker was Zef Hemel. His presentation (slides) about WebDsl gave a nice overview of the setup and current status of the project. I was already a bit familiar with the project and it was fun to get an update. Also, I enjoy seeing the face of people that are confronted with Stratego for the first time :)

All and all I can say that it certainly an afternoon well spent.

Attending J-Fall 2007

This Thursday (October 10th) I was lucky enough to get a ticket (and approval) to go the J-Fall conference organized by the NL-jug. My conference day started when I met some colleagues at the train-station to travel to Bussum-zuid. Within this nice-looking town the J-Fall found its home in 't Spant, a professional conference-facility.

The keynote of the conference was given by the "Sun Java Technology Outreach Team", which is basically a group of four engineers that talk about what you can do with Java. The keynote started with a nice overview of the different technologies Sun is working on. After this, a demo of JavaFX was given. Chuck Munn-Lee showed how easy JavaFX makes it to create a circle that morphs into a rectangle when you click on it. I also liked the fact that his editor did not only support code-completion, but also 'Color-completion'. Unfortunately, the other demos were are a bit disappointing because of several technical problems.

The first 'real' talk I attended was called From Java to Ruby … and Back. The speaker provided lots of material on the slides which made them a little bit overwhelming. Fortunately, he assured us that the slides would also be distributed digitally. The contents of the presentation was an introduction to Ruby and a comparison with Java. One of the conclusions was that the speaker would happily code 80 percent of his applications in Ruby instead of Java. Quit a statement on a conference promoting the use of Java :)

The second talk I visited was about JUnit, or actually JUnit 4. I was a little bit disappointed by this presentation because all of the content was already discussed in an article printed in the last issue of the Java magazine. Furthermore, the pace of the presentation was terribly slow, which made it hard to focus. The only interesting bit of information I extracted was that JUnit4 allows you to define parameterized tests, something I might have missed in the article.

After a little bite, a longer walk and a stroll along the companies on display it was time for the second keynote. This keynote was very slick, had nice graphics and a strong story. Three different people talked about what Adobe offered, which activities are done by Adobe for the open source community, and what we can expect from Adobe in the future. They even tried to answer the question why Adobe was sponsoring the J-Fall. The answer was probably not very clear because I cannot reproduce it. The talk basically felt like one long commercial for the Adobe company.

Right after the second keynote I went to the talk of Peter Hendriks about Eclipse Mylyn. I very much enjoyed this presentation. The story was clear without telling to much detail and the demo was well-prepared. Peter even turned on the magnifying glass in Windows to zoom in to the interesting parts of the demo. These are the kind of details that show that this presentation was well-prepared.
On to the contents, the Eclipse Mylyn plug-in has all kind of nice features that can help you focus on your task. For example, the file-list can be filtered to show only those files that you have edited during the current task. Also, I especially liked the fact that you can define a test-target that only runs the tests associated with the current task. If you use Eclipse you should definitely take the time to check this plug-in out!

After getting another cup of coffee I set down in front of the biggest stage to listen to Java-specialist Heinz Kabutz. He explained The Secrets of Concurrency using ten (humorously named) laws. Each of the laws had an explanation of the name, a link to the actual problem and a solution. The talk was relatively straight-forward which made it easy to follow. A perfect talk for the late afternoon!

The last talk I visited was about the new JSR-286 specification for portals and portlets. Although the announcement implicated that the talk was only about the specification we hoped for a dynamic talk. Unfortunately, we got what was announce. An overview of the current version of the spec, a small list of shortcomings and a larger list of new features. Even though I was interested in the topic it was hard to stay focussed during the complete talk. Especially when the volume of the music in the bar next-door was turned up.

As a conclusion I can say that, despite some of the less entertaining talk, I really enjoyed the day. It was interesting to hear about a lot of different topics, and fun to see different companies present themselves. If I get the change I will definitely attend the upcoming J-Spring conference.

SUD 2007 roundup

Warning: rather long story with a lot of my own opinions up ahead!

I attended my first Stratego User Days this week without really knowing what to expect. I had seen the titles of the talks, but some of them still made me wonder about what was going to be presented. So I took the train to Delft with sleepy eyes and a blank mind.

If you think that the SUD is like a conference then you are wrong, it is more of an informal gathering of people that use Stratego. They explain to each other what they do, how they handle problems and what they would like to see in the next release of Stratego. At first this gave me the idea that the room would be filled with _all_ of the users of Stratego, which was probably true for some of the earliest SUD's, but the first presentation of the day already proved that this idea was wrong. Martin Bravenboer started the SUD with a presentation about the current status of Stratego. He did not only explain how hard they worked on the 0.17 release, but also showed a list of papers and projects, including one complete slide about PHP-SAT, that use Stratego. Some of the people on this list use Stratego without any help from 'the core people', Martin and Eelco, so this probably shows that Stratego is catching on. Martin also mentioned that they are several (Phd) positions to fill, so if anybody is interested they should contact him.

Eelco Visser gave a presentation about the new compilation scheme of Stratego.The presentation was a bit too technical for me, but it showed some nice goals and resulted in a (short) discussion. The discussion ended at the moment that Eelco gave the right example by getting himself some coffee.

Martin continued after the break with a presentation about the new library structure of Stratego. He explained why almost all of the functionality is moved to the library in order to target the portability problem. The funny thing is that some of the presentations that where about to come would complain about this problem, which shows that the needs from the community are actually being fulfilled. I liked the fact that Martin gave lot's of examples that used php-front to illustrate the new features, always nice to see your own stuff used.

We had lunch a little late because we already hopelessly behind schedule, but it was still very nice. I have to say that I like the cafeteria in Delft, the money/food ratio is pretty good. The presentation of PHP-SAT started after the lunch and went very well. The people looked interested even after the moment that the laptop shut himself down because the battery was empty. Karl Trygve Kalleberg mentioned that IBM also had a project about static analysis of source code called Wala, but he did not remember whether it supported PHP. So I tried to find the PHP-part, but I could not find it so it is probably not supported.

Benoit Sigoure talked about his project in which he extended PRISM to deal with real life problems. I always enjoy it when somebody talks about projects that are really useful to them. He also mentioned some problems that he encountered and gave a 'wish list' of items he wanted to see in Stratego. I have experienced most of the problems he has and I totally agree with the fact that he wants some more static checking. One of the other wishes was a debugger and I would like to put this on top of the list. Being able to step through my Stratego program is something that would help me a lot, and others as well.

During the coffee break that followed the presentation of Benoit one of the girls in the room next-door asked me what kind of meeting we had. I explained the concepts of the SUD to here and she replayed with the phrase: ..I already thought that it was something with programming, you are all wearing those nerdy-code-t-shirts.., thank you very much indeed.

After I had probably been insulted by the girl, Mikal Ziane and Nicolas Pierron talked about Lutin. They use java-front and dryad to do some kind of code refactoring, but it wasn't completely clear to me. I think I might have understand things better if we weren't interrupted by the fire-alarm. It gave us a change to see some of the campus and the other people in the building, but it didn't help us to keep up with the schedule.

The presentation of Wouter Caarls about embedding Stratego in C showed another thing that can be done with Stratego. The techniques he used where not very complicated, most of them where also covered in program transformation course in Utrecht, but the combination was interesting.

Valentin David his presentation ended the day by giving an overview of the current C++-front-ends. This presentation was not very interesting to me because I (currently) do not use C++, but I can at least find it again when I need to. But during the talk he mentioned semantic designs, which offers support for analysis. They also have a front-end for PHP, so I probably should take the time to take a look at this.

The second day of the SUD started with a presentation about a system that comparable with Stratego, but written in Java. The system is called TOM and it has some very nice properties. They borrowed some features of Stratego and I hope we also will borrow some of their features. The small features, like matching on a sort without specifying the number of children or the not-match, are most likely not difficult to implement but useful additions to Stratego. They also showed an eclipse-plugin for their project and a graphical debugger, great things to have and very useful. Another project that is added to the list of things to checkout.

Another connection between Stratego and Java was presented by Karl Trygve Kalleberg. He showed the Spoofax project, which also holds a plugin for Eclipse. I haven't really thought about looking at this for the syntax highlighter for Context, but it might be a good idea to check how he did this.

Bernd Fischer gave a presentation about what he wanted to get from the Stratego community. Some of the ideas could also be useful for other Stratego developers, but most of his wishes could probably be solved by implementing a separate library for ACI1-terms. Some of the problems that he mentioned are actually handled by MathPert, so he might want to take a look at it.

The talk of Alexandre Borghi about vectorization was a bit to technical for me. I think I understand why you want it, but could not figure out completely how everything worked. I do not have a problem with this, I do not intend to use it in the near future, but other people will certainly find it interesting.

A presentation that was really interesting for myself was the presentation of Bogdan Dumitriu. He did his master thesis on improving support for data-flow transformations for Object-Oriented programs. Many ideas from his thesis and his talk are very useful for me and the PHP-Sat project, so I am definitely going to read the complete thesis. His support for break- and continue-constructs can easily be added to PHP-Sat and his ideas about customized transformations are definitely cool. As soon as a get a copy of the thesis, and some spare time, I will write a blog about these cool subjects.

My own version of the SUD ended with the presentation of Karl Trygve Kalleberg and Valentin David in which they present some ideas for extending Stratego. Some of the extensions, like an attribute grammar system, are already implemented in Transformers and look interesting. Other proposal are still in the 'this-would-be-a-nice-idea'-stage, so we will have to wait and see what the future brings us.

To conclude this roundup I wanted to say that the whole experience was very cool. It was nice to see what other people are doing with Stratego and was a good opportunity to do some feature-requests. I am already looking forward to the SUD of next year.

The SUD also gave raise to a great quote coming from Pierre-Ettienne Moreau which I probably will going to use more often. The quote displays a great sense of a pragmatic attitude which really appeals to me. During the presentation about TOM Pierre-Ettienne explained some side-effect that could occur during the application of a strategy. After someone asked him whether it was pure he replied:

..it is not pure, but it is practical.