The Mighty Seattle

In July the hurricane of my life brought be to the Seattle area, and in addition to visiting FuSE'13, I wandered around, yawned, ate, and took pictures -- an activity very characteristic of the true intellectual "elite" in the 21st century.

Formal Methods: Removing Industrial Adoption Barriers

Recently I had an opportunity to participate in the inaugural FormaliSE workshop. It had some interesting papers, but here I'll focus on the round-table discussion. Basically the problem is, research guys are in pain because code shops don't use their results. Among all the research guys, the formal methods (FM) guys are in most pain because formalisms are "eewwww," according to an average programmer Joe.

Software Engineering as Engineering

Software engineering is engineering by definition. But is this vision still precise and useful enough? [triggered by ICSE'13]

San Francisco, the Home of Harmony

I spent the week of May 20 in San Francisco at ICSE'13. I'll write a bit about the area so that when someone offers me a job there, I could justify adding another dozen grand on top of it.

NSF CPS PI Meeting 2012 [National Harbor, Maryland]

In early October 2012, I had an exclusive opportunity to NSF's Principal Investigator Meeting in Cyber-Physical Systems, which was held in National Harbor, Maryland (10 miles from DC). It's basically a 3-day research-in-progress conference for professors who got funding from National Science Foundation. I was there purely by chance.

Venue

National Harbor is a very fancy waterfront on the Potomac River just a bit south of DC. 

Gaylord Hotel, front.

This area has exorbitant prices. Even a mid-class hotel network like Hampton charges $250/night before taxes and fees.

Hampton Inn, where I stayed.

The conference was held at the Gaylord Hotel and Convention Center, which is a huge dome with a small park with two-story houses inside it. This complex is impressive both in size and the way it's constructed.

Inside Gaylord.

Inside Gayord, towards Woodrow Wilson Bridge.

Besides several hotels, the area had a few shops and nice restaurants. I personally tried the ones with Thai, American, and Italian foods. I approve.

One building at the shoreline.

(In addition to all sorts of money-spending places, there is a medium hill to the west of National Harbor. That's where I did a hill sprints workout, but it's not related to the main topic.)

A beach sculpture.

CPS PI Meeting

 There was an interesting mix of people attending the conference:

• NSF and other government people
• Control engineers
• Mechanical engineers
• Embedded electronics engineers
• Industry people: automotive (GM, Ford, Toyota, Chrysler), energy, medicine.

This mix is especially interesting from the perspective of a software engineer like myself.

The main conference room.

 The list of general topics addressed at the meeting:

• Classic control and adaptation, extensions.
• Robustness, uncertainty, and noise: graceful degradation 
• Timing in sensing and computation; schedulability 
• CPS security (emerging) 
• Model integration and synthesis  
• Verification and validation: compositional, fuzzy approaches 
• Human-in-the-loop: both removing and adding; accommodating humans; trust 
• Educating CPS engineers: how to teach all needed fields, how to train in formalisms.

Left to right: myself, Akshay, and Prashant who's our co-PI from Toyota.

There was a huge poster session. The one from our project, presented by Akshay, was about compositional verification of heterogeneous models. To find out more, you can stop by the CPS Architectures group and check out our research project progress.

View on poster. Akshay's is on the left.

To summarize, the meeting was very informative for me; both in terms of problems and their solutions.

WICSA/ECSA 2012 Conference [Helsinki, Finland]

[Achievement unlocked: live until 23 y.o. without entering the EU]

In late August, I went to the Joint Working IFIP/IEEE Conference on Software Architecture/European Conference on Software Architecture (coupled two of the main events in the field) in Helskinki, Finland. I might as well finish the post saying, "CMU PAYED FOR A GOOD TIME!", but I'll go deeper in the details.

The city of Helsinki

A plaza in Helsinki.

Another view on plaza.

Helsinki happened to become the World Design Capital (in the worse sense of "design").

The central square.

How would I describe the style of Helsinki? I'd say it's like St. Petersburgh redesigned by gays and maintained by hardworking people. It's clean, fancy, and a bit greasy.

A street in the city center.

The city is relatively small: I had a couple of chilly mornings to cross it end-to-end by running.

A long building.

The beer is expensive there (and this the only aspect that CMU didn't cover). 7 euros is no joke. I'd prefer it to be the other way around: CMU'd pay for all alcohol and not cover food. Reasoning: in a good company, one can survive for several days with the beed yet without food, but not otherwise.

Sort of a business center.

All labels in the city are in two languages: Finnish and Swedish. The Finns speak the former - this is kinda obvious. Swedish language is a contract obligation between IKEA and the government of Finland. Having a larger budget than Finland, IKEA managed to enforce a joke restriction on this deal (otherwise the Finns would have to create their own IKEA, right?). And indeed, everything is in two languages -- take a glance at google street view.

A sea fortress. We actually had a dinner there.

Helsinki has a couple of mid-sized parks. Now I have a good example for the concept of overly-civilized. 

A distant relative of Phipps Conservatory.

Pheasants? God knows what.

Trams in Helsinki are like cars on the West Coast: both a symbol and an important means of transport.

Tram 1.

Tram 2.

Long buses also pop up once in a while.

An airport bus.

Two tall cathedrals form a horizon line in Helsinki, as well as do they create a symbolic contraposition between the western and the eastern worlds at the city scale.

One cathedral is a classic Catholic one. Founded by the proud Finns and such.

Finnish Evangelical Lutheran Cathedral.

The other one is a Russian Orthodox cathedral. Founded by the Russians who used to chill out on Finnish lands once in a while in old times (to the great frustration of the modern Finns, haha).

Uspenski Cathedral.

Helsinki stands on water, which is a real tragedy for people who don't like to swim in cold water. Or just cannot swim. But nobody cares.

The first obvious consequence is the presence of seagulls (cute) and their poo (<no judgment here>). 

A Tzar-seagull.

The second consequence is that large cruise ships go here and there, distracting folks from the conference.

A floating town.

Oh yeah, the conference! I almost forgot.

Conference venue

The conference venue was located at a small quasi-peninsula of Katajanokka. Mastering this word's pronunciation occupied me for the whole flight from Moscow. I stayed in Scandic Grand Marina -- a hotel which impressed by with its price. I would've stayed impressed until today, had I not gone to DC last week where they pay $250-300 per night in an economy room.

Grand Marina.

The conference venue was Grand Marina Convention Center - right in front of the hotel.

Grand Marina, again.

Grand Marina, rear exit.

The room was nice, nothing too special...

A real cozy stool for legs!

... except myself, of course.

In a branded uniform.

Conference Contents

Now, the boring part for you, and the interesting one for me.

143 participants, with a huge percentage from industry.

Here's the spectrum of problems discussed:

• Classic architectural design, quality attributes, scenarios. 
• Decision modeling, documentation, and elicitation.
• Architectural knowledge management.
• Architectural formal modeling and analysis.
• Views and viewpoints. 
• Enterprise architectures. 
• Service-oriented architectures. 
• Variability and evolution. Product lines.
• Architecture and requirements. 
• Architecture and process. Agile.

What one of the conference rooms looked like.

Now, a bit on the people involved. They are by far more interesting (for the general public) to see than the papers.

Tomi Mannisto - the general chair.

Kai Koskimies, with a very topical slide for the SHARK workshop.

Olaf Zimmermann: moar on decisions.

A panel on the field of software architecture.
Left to right: Alex Wolf, Len Bass, Richard Taylor, Philippe Kruchten, and Ivica Crnkovic.

Ipek Ozkaya, from SEI, on quantifying technical debt.

Grace Lewis, also from SEI.

My humble self, during a breakout discussion at one of the workshops.

Marcin Nowak and Uwe Zdun.

Varvana and Mary-Ann -- very active and productive organizers.

Myself again, gathering insights from Richard Taylor.

Participants of the conference, out for the social programme.

There were three workshops, several keynotes and panels in the conference. Without going into the details, I learned a lot from them.

Also, the foods were delicious. They served an unbelievable salmon with every meal!

So it was a very good time.

P.S. The next WICSA is in Australia, and the next ECSA is in France.

VARSA Discussion Group: Traceability of Architectural Variability

At 2nd International Workshop on Variability in Software Architecture (VARSA'12), we discussed the current industry and research perspective on capturing variability and ensuring traceability in the software architecture.

Our group's main findings:

• Variability in architectural views may not only be communicated in two main ways:

• Integrated: you specify what variants and relations are there inside the existing views
• Orthogonal (i.e. separate): you set up a separate view with variation points and options. 
• But also in a combination of both. There is a "degree of variability", which you can add into an architectural view. The question of "how much" is answered by the fundamental need of a stakeholder. For example, if a middleware engineer needs to see all component candidates for the authentication mechanism, this variability point should be present in the view. Alternatively, a regular programmer might not be interested in a sequence diagram with components that he is not responsible for. Therefore, this judgment needs to be used when deciding on how much variability awareness to include into each view.

• Traceability in architectural views is a complicated construct. Intuitively, traceability is helps avoid consistency errors and allows technical staff to navigate dependencies between product derivation decisions. The following traceabilities matter with respect to software variability: 

•  Between a separate variability model and a regular architectural view. 
•  Between variability-aware architectural views. 
•  Between architectural views and other artifacts (for instance, source code or tests). 

One needs to clearly understand that traceability is a method -- and it's needed to solve problems.  There is little direct benefit from traceability. Also, this seems to be a buzzword, along with variability, which needs serious work to de-buzzwordize its meaning.

Future research issues, directions, and ideas on the intersection of traceability and variability:

• Resolving the tradeoff between the separation of concerns and integration of relevant information. The first paradigm suggests preserving the concept of a view as it is. The second one insists that views get their metamodels merged with other metamodels to incorporate the needed information. One example of such information is variability points and variants.

• Choosing a variability representation and amount for a software system is not trivial -- there is no silver bullet. An extraneous variability can cause a project failure by a com explosion of variants. In general, variability in software should satisfy some need inside a domain or market, and add as little extra complexity as possible. 

• There is plenty of automation opportunities in variability traceability:

• Checking consistency of variability models; 
• Deriving product designs from variability-aware architectures;
• Creating traceability links between models. 

• Integrating different variability management approaches when different organizations bridge their boundaries. What is an effective way to share designs done in the orthogonal and integrated paradigms? How to work out a compromised way of dealing with variability in software architecture?

• There is an idea to avoid traceability investment by generating views from a single metamodel. That buys us the traceability for free (honestly, during the discussion I never understood why). However, there are reasonable doubts about the practicality of a single metamodel for modern software projects. It is very likely that those systems that have such a model simple enough to operate wouldn't benefit from a first-class variability representation in the first place.

I gave a short summary presentation to communicate the findings to the workshop. You can see it at Slideshare.

Big thanks to the speakers, discussion groups, and the organizers of VARSA'12!

P.S. A personal lesson: there seems to always be a share of people who are (a) ignoring the existing research and its lessons or (b) redoing the existing research. The single and only way to not be in this shameful subset is to read. So go and read!