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!