Thursday, June 30, 2011
RiSE Labs receives International Researchers
During the period of June-Jully, the RiSE Labs is receiving the visit of two important researchers in the Software Product Lines (SPL) area: David Weiss and John McGregor. In this period, they will give tutorials, invited talks, besides having discussion with master and Ph.D. students from the group. Finally, discussions for cooperation projects are also expected.
Thursday, February 24, 2011
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.
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.
Thursday, September 16, 2010
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].
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].
Thursday, June 10, 2010
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.
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.
Saturday, March 27, 2010
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. ;)
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. ;)
Labels:
In vitro,
In vivo,
research,
Software Evolution,
Software Maintenance
Wednesday, January 27, 2010
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?
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?
Tuesday, January 19, 2010
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!
Labels:
poll,
programming languages,
software reuse
Wednesday, December 23, 2009
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.
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;
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]
[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)
Subscribe to:
Posts (Atom)