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.”;

Product Derivation in Software Product Lines

During application engineering concrete products are built based on the reusable assets. The idea behind the SPLE (Software Product Line Engineering) is that the investments required to develop the reusable artifacts during domain engineering, are outweighed by the benefits in deriving the individual products during application engineering [2].

Product derivation is a key activity in application engineering and addresses the selection and customization of assets from the product line [2]. According to Jhon D.McGregor [3], the Product derivation is the focus of a software product line organization and its exact form contributes heavily to the achievement of targeted goals. However, when isn’t realized through sistematic process, the software product line goal can’t be achieve, diminishing the expected gains.

Beyond the sistematic process, according to Cirilo[1], ideally the product derivation process would be accomplished with the help of instantiation tools to facilitate the selection, composition and configuration of SPL code assets and their respective variabilities.

In the product derivation context, some approaches apply model-driven development techniques; others are merely a collection of guidelines. Yet other approaches provide a high-level methodology or process framework [4]. For instance, PULSE-I process[5], Bosh Framework[6], and COVAMOF process[7].

Unfortunately, in the analysis of existing product derivation approaches showed that great part of the available product derivation approaches do not cover all the steps of application engineering, and neither define activities, sub-activities, roles, inputs and outputs of each step in a systematic way, aspects that should be considered. Moreover, the majority of them doesn't has a tool support.

[1] Cirilo, E., Nunes, I., Kulesza, U., Nunes, C., and Lucena, C. 2009. Automatic product derivation of multi-agent systems product lines. In Proceedings of the 2009 ACM Symposium on Applied Computing (Honolulu, Hawaii). SAC '09. ACM, New York, NY, 731-732.

[2] Deelstra, S., Sinnema, M., and Bosch, J. 2005. Product derivation in software product families: a case study. J. Syst. Softw.74, 2 (Jan. 2005), 173-194.

[3] Deelstra, S., Sinnema, M., Bosch, J., 2003. A Product Derivation Framework for Software Product Families, accepted for the 5th Workshop on Product Family Engineering (PFE-5), November 2003.

[4] John D. Mc Gregor: "Goal-driven Product Derivation", in Journal of Object Technology, vol. 8, no. 5, July-August 2009, pp. 7-19.

[5] J. Bayer, C. Gacek, D. Muthig, T. Widen. PuLSE-I: Deriving Instances from a Product Line Infrastructure. In Proceedings of the 7th IEEE International Conference and Workshop on the Engineering of Computer-Based Systems, pages 237-245, 2000.

[6] Rabiser, R., Grünbacher, P., Dhungana, D.: Requirements for Product Derivation Support: Results from a Systematic Literature Review and an Expert Survey. Information and Software Technology, International Journal. Elsevier, 2009.

[7] Sinnema, M., Deelstra, S., Hoekstra, P., 2006b. The COVAMOF derivation process. In: Proceedings of the Ninth International Conference on Software Reuse.

Looking at Software Product Line Testing Tools

Software testing is a practice often used to determine and sometimes improve software quality. It is also a very labor and resource intensive process that often accounts for more than 50% of the total cost of software development[1]. According to Geppert[2] Software Testing is an area with high potential for reuse and reducing the current testing effort is a high priority topic.

Finding an effective and efficient software testing tool could be a life-saver for a project or a company. Yet there is no single test tool suitable for all possible systems and industry sectors. Deciding what criteria to apply when selecting a specific tool for a project is quite tricky [3].

In 2000, Harrold[4] said that: "We must develop methods and tools that implement the techniques and that can be used to demonstrate their effectiveness. To accomplish this, an important criterion is that these methods and tools be scalable to large systems. An efficient approach for development of methods and tools is to provide ways to automatically create them."

In our study of Software Product Lines Testing Tools we can see a tendency directed to Automatic Test Case Generation Tools and according to Bertolino [5] "The dream would be a powerful integrated test environment which by itself, as a piece of software is completed and deployed, can automatically take care of possibly instrumenting it and generating or recovering the needed scaffolding code (drivers, stubs, simulators), generating the most suitable test cases, executing them and finally issuing a test report".

Product lines exploit the commonalities and variability of reusable assets across different products. Nowadays, the most evident and perhaps most urging question is how to handle and represent variability[6]. Due to the large scale and huge complexity of today’s software-intensive systems, tool support is a key success factor in Software Product Line Engineering[7] and Software Product Line Testing.

[1]Myers, Glenford J., The art of software testing, New York: Wiley, c1979.

[2]Geppert, B., Robler, L. F., Weiss D. M., Towards Generating Acceptance Tests for Product Lines,Software Reuse: Methods, Techniques and Tools: 8th International Conference, ICSR 2004, Lecture Notes in Computer Science, 2004.

[3]Yang, Q., Li J. J., Weiss D., A Survey of Coverage Based Testing Tools, Proceedings of the 2006 International Workshop on Automation of Software Test.

[4]Harrold, M. J., Testing: A Roadmap, International Conference on Software Engineering, Proceedings of the Conference on The Future of Software Engineering, 2000.

[5]Bertolino A., Software Testing Research: Achievements, Challenges, Dreams, International Conference on Software Engineering, Future of Software Engineering, 2007.

[6]Jaring, M., and Bosch, J. Representing Variability in Software Product Lines: A Case Study. In Chastek G. J. (Ed.): Proc. Software Product Lines, 2nd Int. Conf, SPLC 2, San Diego, CA, USA, August 19-22, 2002, LNCS 2379, p.15-36.

[7]Clements, P. and Northrop, L., Software Product Lines: Practices and Patterns: SEI Series in Software Engineering, Addison-Wesley, 2001.