Title is Arial Bold 14 centered

Abstract

What has the field of reuse accomplished? Where can we declare success? Where should we take the blame for failure? The invitees to WISR recently met in Austin, Texas to address these questions and to help determine the direction of future reuse research and practice.

Introduction

Thirty-nine researchers and practitioners of software reuse met 7-9 January on the campus of the University of Textas-Austin for the 9^th meeting of WISR. For this meeting, WISR intentionally reduced its size and duration with the goal of increasing individual communication and interaction. The workshop got off to a running start, with one attendee exclaiming after the first session "everyone knew exactly what I meant!" This intense level of understanding permeated the workshop atmosphere, producing a fertile and intensive exchange of ideas.

What's Hot

WISR participants submit position papers to "stake out some turf" and provide starting points for discussion. In practice, many authors present a short abstract of their current interest or work. However, this year the authors really adopted the spirit of the workshop and went out of their way to stir debate through outrageous and controversial positions.

WISR'9 thrived on the question of where we can claim reuse victories and failures. Some felt that we have solved all (Griss) or parts (Bailin, Poulin) of the reuse problem. Others (Davis, Guerrieri, Yglesias) disagreed with as much conviction. Many pondered where we stand (Edwards, Eichman, Guerrieri) or what to work on next (Griss, Zand).

Several authors claimed to have found the key to reuse (but no two found the same key!). According to them, the answer lies in transformation systems (Baxter), product lines (Clements), Java technology (Eichman), domain engineering (Frakes), program generation (Novak), or reuse of analysis (Stuart).

Proponents of component based reuse methods probably outnumbered any other group. Component reuse (Atkinson, Biddle, Tempero, Browne) included use of COTS (Kachmarik), real-time distribution (Lea), visualization of interactions (Milli, Tollis), component understanding (Mittermieir), regression testing (Weide), object-orientation (Smaragdakis), pointer management (Hollingsworth), and software development environments (Biddle, Tempero).

Program generation received the next most attention. Perhaps due to the home court advantage, U.T.-Austin (Cardone, Novak, Porter) stormed the floor with various generative approaches, with other authors presenting related issues such as optimization (Biggerstaff) and formal methods for generation (Penix).

Product lines (Clements, Cohen, Perry, Stuart) continues to get a lot of attention, as well as the related fields of domain analysis (Allemange, Cornwell, Leite, Simos) and domain engineering (Frakes).

On the academic side, several authors addressed reuse education in terms of what to teach (Frakes), how (not) to teach it (Latour), and who to teach it to (Karllson).

On the business side, several authors addressed the pros and cons of reuse investment (Favaro, Leite, Lim).

For the hard-core technologists, a few authors addressed formal methods (Atkinson, Penix) and transformation systems (Baxter, Tokuda). One suggested that it may take more than one approach to solve the reuse problem (Sitaraman).

Authors also took positions ranging from managerial issues (Price) and reuse concepts (Tracz), to the reuse of requirements (Barber, et al.) and the reuse everything (Butler).

Technical Program

Working and discussion groups met for 2-3 hours each to discuss the general areas of interest reflected above. The following paragraphs summarize the discussions in each group.

“Product Line Architectures”

Robert Biddle, Victoria University of Wellington (NZ), moderated the discussion on product lines, an idea that has proven successful in production and marketing in many industries from bicycles to houses, from golf clubs to, well, software.

One focus of the discussions concerned the key technological motivation, and how a product line approach can ease development by allowing leverage of the commonality in software products, while also allowing the variability necessary. It was pointed out how the product line approach ties in well with many detail development strategies, such as object-oriented frameworks. However, some people pointed out that there are still technological challenges because developing a product line from components still depends on difficult detailed steps in connecting components together appropriately.

The other focus of the discussion concerned organizational issues involved in product lines. Communication provides one important advantage of the product line approach because the general ideas are well understood among both developers and customers. However, it was made clear there are still organizational challenges involved in the approach. One implicit reason is that the approach does require a greater initial investment. The other key challenge involves knowledge management, because the approach requires distributed but deep understanding of the details of product line architecture.

“Organizational Issues, Economics, and Metrics”

Jeff Poulin, Lockheed Martin Federal Systems, Owego, moderated an open discussion that started with a disagreement over whether technical or business problems drove reuse. The group decided that organizational issues prevailed, with reuse primarily consisting of a set of recommendations, or production models, on how to best develop software. The group felt equally divided over whether we could claim success in the area of organizational issues. Although we have thoroughly defined reuse processes and approaches that have little dependence on technology, future work should address how new technologies such as the Internet, COTS integration, and distributed computing affects what we have learned. In addition, our substantial base of knowledge seems to come from our (possibly biased) experiences and those reported by large companies in the literature. In practice, that knowledge may not scale down to small, resource-constrained development organizations.

“Compositional Software Development”

Larry Latour, University of Maine, Orono, moderated a discussion motivated by the question "Why does composition fail?". A number of contributing factors were identified by the group, including:

· the lack of good interaction models

· the prevalence of integral system properties

· the poor integration of well-known language features

· the domain specific nature of applications

· the intractable analysis of system correctness

· the inability to test subsystems in isolation

· the inherent "hardness" of programming

Research efforts are addressing these concerns, including the compositional development of performance models, program visualization as direct manipulation, the integration of inheritance and parameterization using C++ templates, composition as an aid in structuring domain specific knowledge base schemas, the use of product lines to make reusing analysis tractable, and modular regression testing.

While the group did not develop a consensus model of the composition problem, discussions on areas for future work led to a number of important insights. Since complex software is multi-dimensional and can be organized only with respect to a subset of these dimensions, the problem of dealing with integral (non-encapsulated) properties will always exist. Even so, there is value in studying integral system properties from a local perspective (e.g., performance, security), and validating compositional models of such properties. There is a need for programming environments tailored to the strengths and weaknesses of human cognition, and for the proper integration of language features to organize and simplify system structure. There is a need to not only reason about but also to test the correctness of individual subsystems. Lastly, it might prove useful to apply compositional techniques to problems in other domains, such as knowledge engineering.

“Reuse of Existing Assets”

Stephen Edwards, Virginia Tech, moderated a discussion that concentrated on two topics: requirements-based reuse and asset-based programming.

Requirements-based reuse, or use of requirements “fragments” has great benefits but carries with it the

problem of traceability from requirements through design to code. The group concluded that planning to drive code reuse with requirements reuse is a sink hole. Future work on requirements-based reuse should include analyzing if it is appropriate to drive reuse from requirements instead of from design. Complicating the issue is the realization that the government and defense sectors (acquisition-oriented) communities use the term “requirement” in a different sense than commercial and industrial practitioners.

Asset-based software engineering often benefits from development environments that have an asset-based focus (instead of a programming-process-based focus).

Some environments do this already, but are not widely recognized for it. Future work in asset-based development should look at: (1) best way to take advantage of exploratory learning/ visualization/ model manipulation so as to help understand programming, and (2) resolving the tension between hacking and systematic development so asset-based ideas can move up to an architectural or domain level and thereby strengthen and enhance design.

“Automated Reuse”

Doug Lea, State University of New York at Oswego, led a session on automating reuse. The session included presentations on several different styles of automation:

· Program generators based on precise specifications (Baxter, Biggerstaff)

· Tools for specializing generic components (Novak)

· Tools for composing existing components (Penix)

· Source-code level tools for refactoring C++ and Java classes (Tokuda)

Among the resulting discussions were suggestions that researchers should make their domain-specific formalisms available to others. Also, Sitaraman voiced a caution about the frequent mismatch between the specifications of common components in the formal methods community versus their typical implementations.

Future work should include the creation of web sites making domain-specific representations more readily available, possibly via use of more standardized knowledge representation formats.

“Emerging Technologies”

Joe Hollingsworth, Indiana University Southeast, moderated a session highlighted by Will Tracz's strong urging that the WISR community of researchers take a more proactive role in "selling" the reuse technologies that we have already developed. It was agreed that we need to do a better job of this because many of the ideas developed by the WISR community over the years are showing up as "new" ideas in other software research communities.

Other areas covered include creating formal reasoning environments "for the common man", i.e., making formal reasoning about the correctness of programs (even ones that make heavy use of pointer types) easier so that it can be applied by the software developer whenever they develop software. Another discussion looked at the correspondences between Aspect Oriented Programming (AOP) and existing software generation paradigms. Finally, one position suggested that software reuse is in great need of advanced visualization techniques and tools, and that the time is ripe to merge the two efforts for mutual benefits.

“The Future of Reuse”

Don Batory, University of Texas at Austin, moderated the concluding plenary session, which attempted to gain a perspective on what we've done and what we should do next.

In looking back, the field has accomplished a tremendous amount and at least partially solved many key issues (although the completeness of the solutions still aroused much debate). We can point to a legacy of papers, conferences, and workshops. A number of recent books and standards activity (i.e., through the IEEE) serves as evidence of the maturity of many of these accomplishments.

However, many attendees expressed concerns over seeing papers repeatedly "re-discovering" the same ideas, many of which appeared in the reuse community a long time ago. The problem seemed especially prevalent in the object-oriented community and in the software engineering community. This brought a call to renew a push of information about reuse successes and discoveries out to these groups. However, we also can only lead the horse to water… in this age of computerized library searches, the group realized the futility in pushing if the horse lacks the motivation or ability to drink.

Looking forward, no one person could claim clairvoyance and declare what the future would hold. The group discussed several propositions for formally steering the field via sustained working groups, industry consortiums, exchanges between academia and industry, or concerted efforts to publicize our accomplishments. No single approach seemed to offer the panacea. On the other hand, the group developed a common understanding and professional bond that, in the end, may prove to serve as the underlying enabler for many of our concerns.

Conclusion

WISR'9 contained an abundance of insightful and meaningful communication amongst the leading experts in the field. In this sense, the workshop completely fulfilled its goals. Attendees came, they talked, and they left a little "wiser."

For further information or a softcopy of the papers, see: http://www.umcs.maine.edu/~ftp/wisr/wisr.html

Acknowledgments

In addition to the WISR Steering Committee (which consists of all past WISR general and program chairs) the following members of the WISR Executive Committee and their organizations made substantial contributions to ensure the success of WISR'9:

· General Chair, Jeffrey Poulin, Lockheed Martin Federal Systems, Owego, NY

· Program Chair, Don Batory, University of Texas at Austin

· Proceedings Chair, Larry Latour, University of Maine, Orono

· Publicity Chair, Stephen Edwards, Virginia Tech

· Local Arrangements Chair, Laurie Alvarez, University of Texas at Austin