Another Step Towards Comparing Software Retrieval Approaches

As already discussed in a previous post, our community (and various others as well) has recently made a lot of progress in developing interesting and powerful software search and retrieval solutions. However, since most of these approaches have been developed indenpendently of each other it is still hard (if not impossible) to compare them against each other.

Hence, we would like to continue our efforts in this direction and invite submissions for the 1st International Workshop on Comparing Software Retrieval Approaches (CORA 2011, co-located with ICSR). More information can be found on the CORA website.

The Rise and Fall of Product Line Architectures

During the 14 International Software Product Line Conference (SPLC), I was co-organizing a panel with Isabel John and Christa Schwanninger about the The Rise and Fall of Product Line Architectures.

The panel had the goldfish bowl format and had as panelists the main experts in the field: Paul Clements, Charles W. Krueger, John McGregor, Dirk Muthig, and David Weiss.

The panel discussed issues as: How do you think a good product line architecture should look like? How much up-front design do we need for a product line architecture? What are hot research topics in product line architecture?

The mind-map summarizing the panel can be seen here. [thanks to Klaus Schmid].

Towards a Reuse Reference Collection

The idea of software reuse has been around for more than four decades and the technology for searching and retrieving reusable software artefacts has certainly grown out of its infancy (cf. e.g. CodeConjurer). After about 30 years of basic research in which scientists often struggled to get their hands on meaningful numbers of reusable artifacts to evaluate their prototypes, the "open source revolution" has made software reuse a serious practical possibility. Millions of reusable files have become freely available and more sophisticated retrieval tools have emerged providing better ways of searching among them.

However, while the development of such systems has made considerable progress, their evaluation is still largely driven by proprietary approaches which are all too often neither comprehensive nor really comparable to one another. Consequently, it is also hard if not impossible to assess whether existing tools are really beneficial in a practical context.

Driven by these shortcomings, I submitted a paper ("Facilitating the Comparison of Software Retrieval Systems through a Reference Reuse Collection") to the SUITE workshop at ICSE in Cape Town where we discussed this challenge and agreed to start the creation of a reference reuse collection. Meanwhile the Universities of Irvine and Mannheim have started a first initiative and shared reusable material from their Sourcerer and merobase repositories (which comprise far more than 50,000 open source projects) with the scientific community.

Clearly, we appretiate if other researchers would join this initiative and share their data in order to have a broad basis for future comparisons of reuse tools. The next steps required for this undertaking are briefly outlined in the paper mentioned above, but as always: the devil is in the details and hence there are plenty of oportunities to contribute to this project.

RiSE in the 14th European Conference on Software Maintenance and Reegineering (CSMR'2010)

Between March 15 and 18, 2010, it was held on the Universidad Rey Juan Carlos, Madrid/Spain, the 14th European Conference on Software Maintenance and Reegineering (CSMR'2010). CSMR is one of the most important conferences on software maintenance. Although this year there was a reduction in the number of attendees, probably because of the crises, the conference was very exciting and produced nice discussions around the work/research being presented.

In particular, I would like to emphasize the keynote speech of Serge Demeyer about in vitro and in vivo research for Software Evolution. Currently, it is a common sense in the research community that more well done experiment should be performed to evaluate our research. However, in this keynote, there was an special call for more in vivo evaluation for researches. It means that we, researchers, should be more concerned with evaluating our research/proposals in a real context, for example, applying it in real companies with the researcher shipped in it.

The RiSE group participated in the Software Evolution session of CSMR, with the the paper "An Initial Study on the Bug Report Duplication Problem", written by Yguaratã Cavalcanti, Eduardo Almeida, Carlos Cunha, Daniel Lucrédio e Silvio Meira. One interesting point for this paper, was the close relation with the keynote speech of Judith Bishop. In his speech, Bishop talked about how Microsoft has been deal with the large amount of bug reports that are coming daily through their system for bug reports submission.

We had also a good session dedicated to Software Architecture papers, where it was clear that software architecture is still increasingly becoming a fundamental step through the software development life-cycle. I specially noticed some trends to researches on software architecture recovery and reflection. In the session for software evolution, where we presented our paper, it could be noticed that change impact analysis will continue playing an important field of research.

I hope to see you in the next edition of CSMR. I would like also to thank the hospitality of Spanish people. ;)

The Scoping Process in Software Product Lines - Is there any relationship with Design?

I believe that the scoping process is very important to start a product line project. [If you are not familiar with the topic see Isabel John's papers about it and our systematic review].

However, I would like to understand more the relationship between it and the design. Let me explain better: Suppose that I am starting a product line based on a set of products. We collect all the documentation, define a product map with their features, understand and document all the commonality and variability, and that is it!

But in this case, we are defining the SPL scoping based on the existing assets (source code and documentation). From here, we can move, for example, to design the SPL architecture. However, you can observe that we are taking decisions based on the current state of the family, i.e., how it is. What are the implications for the next steps? Are we repeating the same decisions problems when the previous team created the products?

What could be a better solution: define the scope, recovery the SPL design, evaluate this design, reflect it in Scoping and moving forward?

In general sense the point is: for you, what is the relationship between scoping and design? is there any one?

What language for software reuse?

The RiSE community want to know from you if there is a specific programming language, or a type of languages, that is better for software. What do you think about it? Answer the poll on the left sidebar and let us know your opinion. If you prefer, post a comment saying the reasons for your choice(s). Cheers!

Software Architecture Recovery as a Tool to Introduce Reuse in Companies

According to Ducasse and Pollet, software architecture reconstruction is a reverse engineering approach that aims at reconstructing viable architectural views of a software application [1]. The process of software architecture recovery (SAR) may be utilized in many ways, namely redocumentatation, understanding of already existing systems, evolution, conformance between the conceptual and concrete architectures, and some other applications.

In general, the SAR approaches can be classified as Bottom-Up, Top-Down and Hybrid. In the Bottom-Up approach, starts with the low level knowledge, such as source-code, and progressively tries to reach the higher level understanding using reverse engineering. The Top-Down approach is the opposite, as it begins with high-level concepts, such as architectural views and requirements, and tries to build the architecture through hypotheses that are confirmed by the source-code. The Hybrid approach merges the last two approaches, abstracting the low-level knowledge and refining the high-level knowledge ratifying correspondences between both the conceptual and concrete architectures.

In the SAR approaches we can have inputs of architectural nature, like viewpoints and styles, and non-architectural inputs, like souce-code, human knowledge, etc. As output we can have, for example, visual software views, the architectural conformance and the architecture analysis.

Some approaches that aim at the investigation of reuse and software product line (SPL) migration have been identified: ARES[2], ARMIN[3][4], MAP[5] and PULSE[6]. As a goal for these approaches we can highlight the identification of commonalities, variabilities, components that can be extracted of pre-existing systems that, for example, might be turned into services.

Now, our studies focus on identifying if SAR can be used as a tool to support the introduction of reuse in organizations. Our main challenges are:
– What approaches are more complete/ to introduce Reuse?
– What approach can we use?
– Are the companies producing these artifacts?
– Can these processes be agile?
– How much of this processes can be automated?
– How to systematize this approach?

[1] D. Stéphane, P. Damien, "Software Architecture Reconstruction: A Process-Oriented Taxonomy", IEEE Transactions on Software Engineering., Vol 35, No. 4, 2009.

[2] W. Eixelsberger, M. Ogris, H. Gall, and B. Bellay, “Software Architecture Recovery of a Program Family,” Proc. Int’l Conf. Software Eng., pp. 508-511, 1998.

[3] R. Kazman, L. O’Brien, and C. Verhoef, “Architecture Reconstruction Guidelines,” technical report, third ed., Carnegie Mellon Univ., SEI, 2003.

[4] L. O’Brien, D. Smith, and G. Lewis, “Supporting Migration to Services Using Software Architecture Reconstruction,” Proc. Int’l Workshop Software Technology and Eng. Practice, pp. 81-91.

[5] C. Stoermer and L. O’Brien, “Map—Mining Architectures for Product Line Evaluations,” Proc. Working IEEE/IFIP Conf. Software Architecture, pp. 35-41, 2001.

[6] J. Knodel, D. Muthig, M. Naab, and M. Lindvall, “Static Evaluation of Software Architectures,” Proc. Conf. Software Maintenance and Reeng., pp. 279-294, 2006.

Regression Test Selection in SPL

According to Harrold One factor contributing to high cost spent on the maintenance phase it’s a time required to reanalyze and retest the software after it has been changed.

Some regression techniques have been proposed:



One important technique is Regression Test Selection that consist Choose a subset of tests from the old test set, and uses this subset to test the modified program [2];

Some criteria are used for apply test selection [3]:

• Test suite reduction;
• Test execution time;
• Test selection time;
• Total time;

Find and explores efficient test selection criteria for spl can help to reduce more cost involved in spl testing context. The two main key: variability and commonalities must be explored for support the criteria, together traceability between variability and test cases or commonalities and test cases. With goal to support the definition of Test selection criteria for SPL;

In this moment we study e test a mix of possibilities between techniques and criteria with focus in application in SPL testing context… in another day we going to write more about this subject;

[1]Harrold, MJ, and ML Souffa. 1988. "An incremental approach to unit testing during maintenance." Software Maintenance, 1988;
[2]Rothermel, G. and Harrold, M.J. 1993. A safe, efficient algorithm for regression test selection. Software Maintenance ,1993. CSM-93, Proceedings., Conference on. 358-367.
[3]Engstron, Emelie, Per Runeson, and Mats Skoglund Pii. 2009. "A Systematic Review on Regression Test Selection Techniques." English (July).
[4] Gaurav Duggal, Mrs. Bharti Suri.2008.” UNDERSTANDING REGRESSION TESTING TECHNIQUES”;

Inspection in Software Product Line

A software product line consists of a product line architecture, a set of reusable components and a set of products derived from the shared assets [1].

Organizations developing or acquiring systems using the product line approach have enjoyed significant (sometimes order-of magnitude) improvements in time to market, cost, productivity, and quality [2].

Benefits of Software Product Lines [3]:

• Product line development has increasingly received attention in industry as it enables organizations to reduce both cost and time of developing and maintaining increasingly complex systems.
• Successful product line development requires high quality of reusable artifacts in order to achieve the promised benefits.

Moreover, software inspection approaches implements techniques to provide qualities atributes for assets and product of software development processes, such:

• Ensure correct system is built [4]
• Assure Software Quality [3]
• Optimize the software process [5]
• Work product more readable [6]

The key challenge is the adaptation of inspections, reviews, and walkthrough techniques for use in domain and application of Software Product Lines Engineering. For example, the results of inspections, reviews, and walkthroughs, obtained in domain engineering, should be effectively compared and monitored in application engineering. Taking into consideration that the review process for reusable artifacts of product lines need to present efficient (catching faults) and not very dense (time) performance, to enable a better adoption in organizations.

[1] Jan Bosch, "Software Product Lines: Organizational Alternatives," icse,pp.0091, 23rd International Conference on Software Engineering (ICSE'01), 2001

[2] Paul C. Clements: A Competition of Software Product Line Economic Models. SPLC 2005: 136

[3] Christian Denger and Ronny Kolb, Testing and inspecting reusable product line components: first empirical results, ISESE'06 at Rio de Janeiro, Brazil, September 21–22

[4]David L. Parnas, Mark Lawford: The Role of Inspection in Software Quality Assurance. IEEE Trans.Software Eng. (TSE) 29(8):674-676 (2003)

[5] H. Dieter Rombach, Marcus Ciolkowski, D. Ross Jeffery, Oliver Laitenberger, Frank E. McGarry, Forrest Shull: Impact of research on practice in the field of inspections, reviews and walkthroughs: learning from successful industrial uses. ACM SIGSOFT Software Engineering Notes (SIGSOFT) 33(6):26-35 (2008)

[6] Forrest Shull, Ioana Rus, Victor R. Basili: Improving Software Inspections by Using Reading Techniques. ICSE 2001:726-727

Software Product Line in Small and Medium Sized Company

Software development costs and time to deploy a software-intensive system significantly decrease when Software Product Line (SPL) approach is applied [3]. However software product line engineering requires long-term planning, the companies that have used it successfully are large ones that can afford to take the long view [1].

But smaller enterprises must be flexible and fast in reacting to customer requests. Moreover most publicized software product lines come with pedigrees written in large script: Nokia, Motorola, Hewlett Packard, CelsiusTech, Philips, and others. These organizations boast hundreds of developers, with budgets more than ample enough to cover an experiment or two with a new and untried paradigm. And if it fails – well, there’s always a bit of a risk with an R&D project, isn’t there? It’s not as though the company will be in peril [1].

For small companies, R&D is an unaffordable luxury. And experiments are for laboratories, not lean need-it-now production shops where every product has to strike market gold for the company to survive [3]. No wonder the conventional wisdom views software product lines as a game only for the heavyweights. For the record, the conventional wisdom is utterly wrong. In fact, software product lines offer many small companies their last best hope for success.

Today, we have significant examples of application of SPL in SMEs. In most cases SMEs use research groups as Reuse Software Engineering (RiSE) kind of an external research department.

Advantages of a small company over a large one include the following [2]:

· It is much more easy to articulate a vision in a small organization and make it stick. This is true of any vision, but especially true of a product line vision. Product lines are typically sold to management because they hold the promise of lower cost and quicker turnaround. In a large organization, those goals are fairly abstract to the troops grinding out code. But in a small company, the developers are much more tuned in to the company’s economic picture; there is a short distance from economics to developers.

· A corollary to the previous point is that it is much easier to find places where the vision needs reinforcing.

· A small organization can get by with lightweight product line processes, for they are used to lightweight processes anyway.

· A small organization’s developers can more easily acquire useful domain knowledge.

· Managers in a small organization typically apply their hand at many tasks, including development, so they know firsthand where the approach is falling short.

[1] Peter Knauber, Dirk Muthig, Klaus Schmid, Tanya Widen: : “Applying Product Line Concepts in Small and Medium-Sized Companies. ”;

[2] Martin Verlage, Thomas Kiesgen: “Five years of product line engineering in a small company.”

[3] José L. Barros, José M. Marqués: Support to Development-with-Reuse in Very Small Software Developing Companies.”;

[4] David Sellier, Gorka Benguria Elguezabal, Gorka Urchegui: “Introducing Software Product Line Engineering for Metal Processing Lines in a Small to Medium Enterprise.”;