OOPSLA '07: Software Architecture Tutorial

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:

• Clear architecture vision: This is similar to the metaphor in XP or the ubiquitous language in Domain Driven Design. Essentially it means that the architecture should be driven by a clear idea of what you are trying to achieve. And the architecture should strive to maintain this goal in every aspect possible.
• Iterative Development: This is really important. Developers usually think of architecture as something that must always be done up-front. There is some truth to this since if you get the architecture (vs the design; see this for an explanation on the differences) wrong then there is a heavy price to pay in terms of development efforts. Stal solves this by introducing the concept of the baseline. The baseline is the core of the architecture that needs to be done right and will not change throughout the entire development cycle. The baseline is determined from a set of prioritized requirements from the stakeholders. Only the most important requirements shape the architecture of the baseline; the remaining requirements will be acted on later in an incremental manner. This balance on what to add first and what to add later makes sense: unlike design, software architecture will definitely permeate the entire system so it is essential to at least get the important aspects right the first time.
• Testing: It is necessary to be able to test that your system supports certain requirements. It is usually commonplace now to have automated tests for most of the functional requirements of the system. Stal claims that it is necessary to have tests as well for the system architecture. These tests need not be automated fully of course but they should exist nonetheless. Either doing it through a code review or a formal inspection would reveal missing requirements in the architecture. I talked to Stal about using executable Architectural Description Languages(ADL) to verify the architecture and he says that most of the time that approach is not feasible since it requires a domain expert on the ADL itself reaffirming what I thought about ADLs in the first place.

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:

• Pattern Density
• Symmetry
• Expressiveness
• Simplicity
• Orthogonality
• Emergent behavior

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.