OOPSLA '07: Software Architecture Tutorial

The next few posts will be about OOPSLA 2007 and the title of the articles will be appended with "OOPSLA 07". Those articles will be written in a more colloquial manner since they will be mostly based on my personal experiences there.

I was fortunate enough to have the opportunity to go to OOPSLA this year. I say fortunate because I had to apply for a Canadian visa; and based on past experiences it can either be a painless ordeal or one where you are unsure what you have done to not deserve one. Anyway, all went well, and after 15 hours of driving and 12 hours of recuperative sleep -- I was not able to sleep in the van -- I attended the first day of OOPSLA without any problems.

The first day was relatively easy-going since I was not signed up for any of the symposiums and could freely choose which two tutorials (or none) that I wanted to attend. I chose the tutorials on Software Architecture by Michael Stal of Pattern-Oriented Software Architecture fame.

The first tutorial was during the morning session and was entitled High Quality Software Architecture. It was an interesting tutorial and I think I was the youngest person in the room. The tell-tale signs of balding heads indicated that most of the other attendees were professional software architects that were here to learn the secrets of the trade from Stal himself. Anyway, the first part of the talk was essentially a nice review of the material that I had read about a year ago when I took the Advanced Software Engineering class. In fact, I wrote articles on the books and papers that we read for that class here in this blog. Stal was using the same terms an definitions from the Software Architecture in Practice book. It was interesting to actually see how someone else who interpret that book since it was a rather academic book and it was hard to actually find someone else to discuss about it.

Stal emphasized three main issues that was only lightly touched upon in the book. And I agree with him that these three topics will help promote higher quality software architecture:

The afternoon session was on Refactoring Software Architecture. Stal admitted that what he was going to present was based on preliminary work but nonetheless he felt that it was essential enough to warrant a tutorial. I completely agree with him especially since he too mentioned the Grand Unified Theory of Refactoring at the end of his talk and if we have any chance of finding one we had to start thinking of a lot more about software in terms on refactoring and program transformation. Like Fowler, Stal motivated the indicators of architecture refactoring in terms of architecture smells or what he terms the lack of the following qualities:

The list of refactorings that he presented were based in the spirit of the original refactorings by Fowler: he used a pattern language to describe them. When I first saw the first few refactorings that he presented I was confused by the scope of it: were they architecture refactorings or design refactorings? And this is where the distinctions in the paper Architecture, Design and Implementation might be useful. When I asked Stal, he explained that he treats refactorings that could have a percolating impact to be an architectural refactoring. So when you refactor something and it affects things below it then it is probably an architectural refactoring pattern. There is still this nagging feeling inside me that thinks that architectural refactorings might not be behavior preserving -- the quintessential definition of what a refactoring is -- but I just cannot come up with an example of this. So I could be wrong about this.

Stal has a list of roughly 30 refactorings. But the two that most interested me were Aspectize and Integrate DSLs. The former being that you might need to address some cross-cutting concern and use an aspect-oriented approach to solve it. This is actually the few times that I have seen someone promote aspects in an appropriate manner. Usually people are vehemently for or against aspect-oriented programming. Stal however, presented a clear case where aspects can actually be a good approach. The second pattern is all about not being reserved on using a Domain Specific Language for your architecture if you need one. Again, I think that the time for thinking in more than one language has come and this is one way to make good use of that approach. Software architecture can be a complex beast and while it might be usually over-kill to use AOP and DSLs for normal projects, architecture could be the key area where they should both have relevant roles.

Throughout both these presentations Stal mentions the need for iterative design and refactoring. He is clearly a strong supporter of refactoring. He realizes that all future software development can only be successful with decent and continuous refactorings. And he is far-sighted enough to see how refactoring can be applied not only to code but also other artifacts like architecture.

I was talking to Maurice and we both agree how our advisor, Ralph Johnson, could have made one of the greatest contributions to software engineering by introducing the concept of refactoring. Sure he has co-authored the book on Design Patterns but the main concept of refactoring is probably more influential. Thinking of software engineering in terms of refactoring and transformations is definitely how all future software should be developed.

comments powered by Disqus