William F. Opdyke
Bell Laboratories - Innovations for Lucent Technologies
2000 N. Naperville Road
Naperville, IL 60566-7033
Tel: (708) 979-0730
Email:
william.opdyke@bell-labs.com
wopdyke@lucent.com
Legacy constraints can impede reuse efforts in industrial settings. In this position paper, I first describe some of the results of my research into refactoring object-oriented software; refactoring is a means for achieving evolution and reuse in the midst of legacy constraints. Then, I discuss some insights gained from recent efforts to encourage reuse in industrial settings.
Keywords: Reuse, object-oriented software reengineering, addressing reuse barriers.
Workshop Goals: Learning; networking; advance state of theory of software evolution and reuse.
Working Groups: domain engineering/ managing change; validation of reuse economic models; object technology, architectures and domain analysis.
Legacy constraints can impede reuse efforts in industrial settings. Four key issues must be addressed for a reuse "solution" to succeed given these legacy constraints.
In this position paper, I first describe my background related to software reuse, focusing on my research into refactoring object-oriented software. Then I discuss four key issues that should be considered when defining and developing software reuse tools (such as a refactoring tool) or when attempting to facilitate reuse in an industrial setting.
During my years at Bell Laboratories (first part of AT&T, now part of Lucent Technologies) I have been able to view the reuse issue from several different perspectives. For several years during the mid-1980's, I worked in an applied research department at Bell Labs, studying techniques for supporting large-scale, multi-year software development projects. Then, during a four year doctoral research assignment at the University of Illinois, I worked with Ralph Johnson on issues regarding the process of change for object-oriented software. For most of the past two years, I have focused on facilitating reuse of platforms and components across a range of telephony related products.
My doctoral research focused on refactoring object-oriented software, to support evolution and reuse. Refactorings are behavior-preserving program restructurings that can be applied to, for example, separate out parts of a program (design abstractions, reusable components) to make the design of a program clearer and to make it easier to add new features. Refactorings can also be applied in some cases to reduce or eliminate redundant parts of a program.
The need for refactoring grew out of early experiences in reusing object-oriented software, particularly in the Smalltalk community, as discussed by Johnson and Foote in [1]. My research focused on refactoring C++ programs [2,3,4,5,6]. Currently, research is underway at the University of Illinois into refactoring Smalltalk programs [7,9]. Don Roberts and I presented a tutorial on refactoring at the OOPSLA '95 [8] and OOPSLA '96 [10] conferences. Related research includes [12,13,14,15].
For at least some of us, an "ideal world" would consist of only fresh start projects, where we understood the domain, and where our funders would pay us until WE were satisfied with the results. However, in many industrial settings, a more realistic scenario might sound something like this: we are asked to change/ extend an existing piece of software, we have a less than complete understanding of what we are doing, and we are under schedule pressure to produce!
What should we do under such circumstances, given the need to implement a system that is a superset of the current system. Do a complete program re-write? That could be very costly. Do an ad hoc copy and modify? That could compromise the software architecture and leading to bloated programs.
Given the implications of each of those extremes, is there a middle ground where both architectural integrity is maintained AND development costs are contained?
Techniques that support evolution and reuse may at first glance seem to fill the middle ground. Such techniques are often "sold" on the longer range benefits that might be achieved by using them. Then, proponents of such techniques may be surprized (and discouraged) when the world does not beat a path to their door. We have found four key reasons why people are reluctant to apply such approaches even if they appreciate the longer-term benefits:
To address the first two issues, in our refactoring research we characterized our process in a way that achieves both short term and long term benefits. We studied snapshots of evolving systems, interviewed experienced developers, and iterated our approach with reviews by experienced staff.
To address the latter two issues, we defined an approach for automated support. The tool would first determine whether a refactoring could be safely performed and, if so, perform the refactoring. It turned out that our hardest problems were in determining whether a part of a program could be safely changed given the program structure and interdependencies. We defined behavior preservation in terms of a set of invariant program properties, and defined (for each of our refactorings) the necessary preconditions to ensure that these program properties remain invariant. Our automated tool did the checking - the user was spared the complexities of such program analysis - and only if it could be proven that a change was safe would it be applied.
My more recent work has focused on encouraging reuse in an industrial setting. These same set of four issues/ challenges, albeit with a slightly different "spin", have arisen in our recent work:
In [16] Geoffrey Moore describes the technology adoption process in terms of a bell-shaped curve where the front tail includes "innovators" and "early adopters", the large middle hump includes "early majority" and "late majority", and the trailing tail including "laggards". For an idea and product to succeed, it must ultimately be adopted by the early and late majorities. Put another way, many ideas that appeal to the innovators and early adopters ultimately fail because they never make it across the chasm to the early and late majorities. The disconnect mainly lies in the differing motivators of these customer groups. Innovators and early adopters are attracted by new technologies, visions of paradigms shifts and breakthroughs, whereas the early and late majorities are primarily concerned with cost, support, and in seeing if the new idea or product has already been successfully applied by others with needs similar to theirs.
My recent reuse efforts have been targeted at development groups many of whom have the early and late majority mindset with regards to platform and component reuse. In attempting to appeal to these groups, I have focused on areas such as providing consultative support, bringing together projects with similar needs, and publicizing success cases - where an approach has been successfully applied either inside our company or by a competitor. While we are achieving some success in facilitating reuse, there is still much to learn.
In my position paper to WISR 7 I discussed some refactoring related research (such as [12], [13], [14], [15]); some recent refactoring related research was reported on at OOPSLA '96.
With regards to our approach to facilitating reuse, early in my career I tended to often work with "innovators" and "early adopters" without realizing how different their motivators were from those of the larger mainstream. Geoffrey Moore's model [16] has helped me reorient my approach for my current work.
All too often, we software engineering researchers, tools developers and front-end planners position ourselves too far from the "trenches" in which many software developers live. While it is important to sometimes step back, reflect and envision how software developments might be done better, we also need to then be able to relate our solutions to the real and perceived needs of the people we are trying to influence. In this position paper, I have defined four key issues that should be addressed when attempting to "sell" a software reuse "solution".
At the workshop, I hope to discuss these issues with other participants.
[1] Ralph E. Johnson and Brian Foote. "Designing Reusable Classes." Journal of Object-Oriented Programming, 1(2):22-35, 1988.
[2] William F. Opdyke and Ralph E. Johnson. Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems. In Proceedings of 1990 Symposium on Object-Oriented Programming Emphasizing Practical Applications (SOOPPA '90), Poughkeepsie, New York, September 1990.
[3] William F. Opdyke. Refactoring Object-Oriented Frameworks. Ph.D. thesis, University of Illinois at Urbana-Champaign, 1992. Available as Technical Report No. UIUCDCS-R-92-1759. Postscript: /pub/papers/refactoring/opdyke-thesis.ps.Z on st.cs.uiuc.edu.
[4] William F. Opdyke and Ralph E. Johnson. "Creating Abstract Superclasses By Refactoring." In Proceedings of CSC '93: 1993 ACM Computer Science Conference, Indianapolis, Indiana, February 1993. Postscript: /pub/papers/refactoring/refactoring-superclasses.ps on st.cs.uiuc.edu.
[5] Ralph E. Johnson and William F. Opdyke, "Refactoring and Aggregation." In Proceedings of ISOTAS '93: International Symposium on Object Technologies for Advanced Software, Kanazawa, Japan, November, 1993. Postscript: /pub/papers/refactoring/refactor-aggregation.ps on st.cs.uiuc.edu.
[6] Brian Foote and William F. Opdyke, "Life Cycle and Refactoring Patterns that Support Evolution and Reuse." Presented at First Conference on Pattern Languages of Programs (PLOP '94), Monticello, Illinois, August, 1994. In "Pattern Languages of Programs" (James O. Coplien and Douglas C. Schmidt, editors), Addison-Wesley, May, 1995.
[7] Ralph Johnson, John Brant and Don Roberts, "The Design of a Refactoring Tool." Presented at ICSE-17 Workshop on Program Transformation for Software Evolution, Seattle, WA., April, 1995.
[8] William F. Opdyke and Don Roberts, "Refactoring". Tutorial notes - OOPSLA '95: 10th Annual Conference on Object-Oriented Programming Systems, Languages and Applications, Austin, Texas, October, 1995.
[9] Don Roberts, John Brant, Ralph Johnson and William F. Opdyke, "An Automated Refactoring Tool". In Proceedings of ICAST '95: International Conference on Advanced Science and Technology, Chicago, Illinois, April, 1996.
[10] William F. Opdyke and Don Roberts, "Refactoring". Tutorial notes - OOPSLA '95: 10th Annual Conference on Object-Oriented Programming Systems, Languages and Applications, Austin, Texas, October, 1995.
[11] William F. Opdyke, "Refactoring Object-Oriented Software to Support Evolution and Reuse". Position paper - WISR 7: Seventh Annual Workshop on Software Reuse, St. Charles, Illinois, August, 1995.
[12] Eduardo Casais. Managing Evolution in Object Oriented Environments: An Algorithmic Approach. PhD thesis, University of Geneva, 1991.
[13] Kark J. Lieberherr and Ian M. Holland. "Assuring Good Style for Object-Oriented Programs." IEEE Software, pages 38-48, September 1989.
[14] Won Kim. Introduction to Object-Oriented Databases. MIT Press, 1990.
[15] Rebecca Wirfs-Brock, Brian Wilkerson and Lauren Weiner. Designing Object-Oriented Software, Prentice-Hall, 1990.
[16] Geoffrey A. Moore, "Cross the Chasm: Marketing and Selling Technology Products to Mainstream Customers". HaperBusiness, 1991.
Bill Opdyke is a member of technical staff in the Advanced Network Services Architecture organization at Lucent Technologies - Bell Labs Innovations, where he focused on intelligent network and decision support applications of object-oriented technology. He is currently involved in platform planning for telephony applications. He is managing editor of a Bell Labs/ Lucent internal publication ("Multiuse Express") devoted to reuse issues. Bill's doctoral research at the University of Illinois focused on refactoring C++-based object-oriented frameworks, supervised by Ralph iohnson.