Mohsen Vakilian's Blog

January 12, 2009

OOPSLA 2008–Economics-Driven Architecting

Filed under: architecture — mohsenvakilian @ 3:32 pm

As a student volunteer I had to take the responsibility of a tutorial session which turned out to be the CBAM tutorial presented by Rick Kazman and Ipek Ozkaya. CBAM is a quantitative approach to architecture design decision making. CBAM augments ATAM by adding costs and benefits as attributes to be traded off. As an advantage of CBAM, Rick and Ipek mentioned that stakeholders like CBAM as it helps them reach consensus through a rational process.

Having had read the SAIP two years before, I was familiar with CBAM. However, this tutorial refreshed me on the subject of architecture analysis techniques.  Specially, the hands-on approach they took by having the participants use CBAM on an example of city information system was quite effective. They began by introducing several concepts such as quality attribute, value, utility, … . Then, they went through the steps of CBAM on the NASA ECS project.

My comment on CBAM is that this technique looks reasonable once you have reliable data about response measures and effects of architectural strategies on response levels. However, as Rick and Ipek were pointing out throughout the tutorial, uncertainty should be considered in decision making as well. They explained how uncertainty is taken into account in the following iterations of CBAM. But, that looked quite simplistic and insufficient. Uncertainty was not considered as  a central element of architectural decision making. Nevertheless, I think CBAM has already gone too far in trying to quantify costs and benefits and coming up with values for uncertainties requires guidelines, formulas, estimates, voting, … which will make the CBAM quite complicated.


November 17, 2008

OOPSLA 2008–Architecture as Language

Filed under: architecture,dsl — mohsenvakilian @ 1:18 pm

Markus Voelter presented three tutorials on DSL’s at OOPSLA this year. The one I attended was entitled “Architecture as Language“. In this tutorial, he illustrated how textual DSLs can be used as succinct, precise, technology-independent and tool-processable description of a software architecture.

Markus went through building an example DSL and showed how the approach could be applied to product lines. He actually defined the grammar and added some constraints as he discussed the architecture and got a customized editor (using oAW‘s Xtext tool) at the end.

He defined components in his DSL like the following:

component DelayCalculator {

provides IDelayCalculator

requires IInfoScreen


Then he changed the grammar to express instances of components and wired instances together by expressing relationships between them. To describe relationships between instances and cardinalities of these relationships, he introduced the well-known concept of ports. Ports led to role-specific interfaces. Also, he added namespaces and extended the language to describe the publish/subscribe relationship between components. The resulting language looked like the following:

namespace datacenter {

component DelayCalculator {

provides aircraft: IAircraftStatus

provides managementConsole: IManagementConsole

requires screens[0..n]: IInfoScreen

publishes flights { publication = onchange }



namespace mobile {

component InfoScreen {

provides default: IInfoScreen

consumes flights { init = all update = every(60) }



Describing the architecture in a DSL has the benefit of making clear what the architect means. But, it takes time and effort and usually it’s valuable if some analysis or code generation can be done using the formal description. The oAW tool seems to try to exploit both benefits of an architectural DSL’s. But, I have to further play with the tool to see how it works in action. It’s not clear to me how well it can prevent developers from modifying the generated code.

DSL’s seem to be promising techniques to help customers and developers communicate. And, I’m looking for research opportunities in this field.

June 25, 2007

Active Documentation

Filed under: architecture — mohsenvakilian @ 7:48 pm

Documentation can become a risk in a software project!
If you don’t know the real benefit of the document, or if its contents aren’t useful for anybody, then what is the value of that document?
Software Architecture in Practice
I have read more than one third of SAIP. Now, if somebody asks me about the most interesting concept I have got from it, I would say Software Architecture Evaluation!

Assume an active discussion between the architect and stakeholders in ATAM or CBAM methods. Everybody announces his expectations from the software. Then, a list of quality attributes comes out by stakeholders’ votes based on the cost and priorities of quality attributes. Finally, a report of the whole session comes out. This is the result of an active discussion. This is the kind of documentation that will talk lively to its future readers.

June 10, 2007

Grady Booch—The Promise, The limits, The Beauty of Software

Filed under: architecture — mohsenvakilian @ 11:08 am

I’m sure no body needs introducing Grady Booch.

Here is an interesting talk by Grady. I strongly recommend all those interested in software to watch this video.

It’s interesting that he several times mentions the fact that the code doesn’t necessarily reflect some of the design decisions that shaped that code. In fact, it’s one the most important motivations to go through the process of software architecture documentation.

He talks about the declining number of people graduating in computer science and asks how to express an excitement for the people who follow us the beauty and elegance of what we have done. Somehow, he answers this at the end of his talk by saying “What other industry can you think of that has transformed civilization as much as ours has?”

Afterwards, his talk evolves around the contradictions of our software world. The following is the contradiction which attracted me the most:

“Email and other software-intensive mechanisms increase the velocity of communication. But, on the other hand, email and the aging of digital archives threatens the preservation of history”

Then, he explains his fundamental questions from software organizations when he has to get a smell of them:

  1. Do you have a release plan?
  2. How frequent are your releases?
  3. Do you have an architect?
  4. Do you have a culture of patterns?

Grady points out the importance of organization and recommends the book: Organizational Patterns of Agile Development

Organizational Patterns of Agile Development

At last, he mentions the characteristics of hypo productive architectures:

  1. Crafting crisp and resilient abstractions
  2. Maintaining a good separation of concerns
  3. Creating a balance distribution of responsibilities

Create a free website or blog at