home *** CD-ROM | disk | FTP | other *** search
/ ftp.umcs.maine.edu / 2015-02-07.ftp.umcs.maine.edu.tar / ftp.umcs.maine.edu / pub / WISR / wisr7 / proceedings / txt / johnson.txt < prev    next >
Text File  |  1995-08-12  |  7KB  |  131 lines
  1. Why Doesn't the Reuse Community Talk About Reusable Software?
  2.  
  3. Ralph E. Johnson
  4.  
  5. University of Illinois
  6. Department of Computer Science
  7. Tel: (217)244-0093
  8. Email: johnson@cs.uiuc.edu
  9. WWW: http://st-www.cs.uiuc.edu/users/johnson/
  10.  
  11. Abstract
  12.  
  13. The reuse community spends too much time talking about reusable 
  14. software in general and too little time talking about reusable software in 
  15. particular. We need to study and compare the designs of particular 
  16. reusable systems so that we can improve them (and so make reuse more 
  17. valuable) and so that we can learn the principles of reuse.
  18.  
  19. Workshop Goals: Learning; Finding kindred spirits.
  20.  
  21. Working Groups: Domain analysis/engineering; Reuse and OOmethods 
  22. and technology; Reuse handbook; Reusable architectures for business 
  23. software.
  24.  
  25. 1   Background
  26.  
  27. I've been working with OO technology for 10 years, trying to see how 
  28. objects change the way we develop software, especially how it impacts 
  29. software reuse. I quickly noticed that reuse of code and small 
  30. components was not what was important, but instead reuse of design in 
  31. the form of larger components called frameworks.
  32.  
  33. A framework is a reusable design expressed as a set of abstract classes and 
  34. the way that instances of these classes interact. In one sense, the most 
  35. important thing about a framework is the interfaces that it defines. 
  36. Because a framework is made up of classes that can be represented in 
  37. programming languages, it is reusable code. But it tells you how to 
  38. decompose your program into objects, and in that sense is a design. 
  39. Moreover, most of the code reuse comes not from inheriting from the 
  40. abstract classes but from reusing concrete classes from a class library. 
  41. The concrete classes reuse the standard interfaces defined by the 
  42. framework, so they can be mixed and matched. Most of the reuse comes 
  43. from being able to mix and match components, not from being able to 
  44. define a new component using inheritance.
  45.  
  46. I've worked on a number of frameworks, including the frameworks that 
  47. come with Smalltalk-80 (VisualWorks), a framework for drawing editors 
  48. called HotDraw, a framework for operating systems called Choices, a 
  49. framework for code optimization and code generation, a framework for 
  50. music synthesis,and a framework for accounting. While none of them 
  51. have had large numbers of users (HotDraw probably has the most users, 
  52. and that is probably 50-100), most of them have had a few users outside 
  53. of my research group.
  54.  
  55. Recently I have been working on documenting the software patterns that 
  56. expert designers use. Not surprisingly, I have focused on the patterns that 
  57. OO designers use to make software more reusable.
  58.  
  59. 2   Position
  60.  
  61. One of the distinguishing characteristics of computer people is the 
  62. tendency to go meta at the slightest provocation. Instead of writing 
  63. programs, we want to invent programming languages. Instead of 
  64. inventing programming languages, we want to create systems for 
  65. specifying programming languages. Instead of analyzing domains, we 
  66. want to make methods for domain analysis. And instead of writing 
  67. reusable software, or reusing software, we want to write about the 
  68. principles of software reuse.
  69.  
  70. There are many good reasons for this tendency, since a good theory 
  71. makes it a lot easier to solve particular instances of the problem. But if 
  72. you try to build a theory without having enough experience with the 
  73. problem,you are unlikely to find a good solution. Moreover, most of the 
  74. time spent building reusable software is on issues that are particular to 
  75. the problem that the software is supposed to solve, not on generic 
  76. reusability issues. We are in danger of attacking secondary problems and 
  77. ignoring the most important ones.
  78.  
  79. The software community has developed standard architectures for some 
  80. kinds of software, such as compilers, operating systems, and user 
  81. interfaces. Not surprisingly, these are the kinds of software for which we 
  82. have the best reusable software; parser generators and table-driven code 
  83. generators for compilers, and GUI frameworks and screen painters for 
  84. user interfaces. But there are a lot more people building accounting 
  85. systems or manufacturing systems than building compilers, and we have 
  86. tended to ignore applications software, even though that is the most 
  87. financially important kind. Although there are reuse success stories 
  88. among this kind of software, I believe we are only seeing a fraction of 
  89. what is possible.
  90.  
  91. Whenever a standard architecture has developed in the past, it has been 
  92. developed in a context of a community that can bring many 
  93. perspectives to bear on it. The practitioners are from companies that are 
  94. trying to build commercial software. Researchers are investigating narrow 
  95. problems within the domain of the architecture. Textbook writers are 
  96. trying to organize and systematize the material.
  97.  
  98. Why hasn't this happened with accounting software or manufacturing 
  99. software? One possible reason is that companies are afraid of losing trade 
  100. secrets. But that reason didn't keep the system software venders from 
  101. participating in conferences on compilers or operating systems. I think a 
  102. more important reason is that reseachers have ignored these topics. If 
  103. the researchers were holding exciting conferences on these 
  104. topics,practitioners would come to find out what was going on, and they 
  105. would figure out how to make the researchers want to talk to them. But 
  106. without all the members of the community, it is much harder to make 
  107. progress.
  108.  
  109. What can practitioners do to attract the attention of researchers? One 
  110. obvious technique is to support their research financially.  Another is to 
  111. helpconferences on the domain of interest get off the ground. When 
  112. organizations have their own research department, practitioners can try 
  113. to get some of the researchers interested in their problems. Regardless of 
  114. which methods are used, changing other people's behavior is always 
  115. hard.
  116.  
  117. Is it worth trying to organize groups of people working on particular 
  118. kinds of software? I think this is the only way to make good reusable 
  119. designs. To be reusable,software has to be reused in many contexts, and 
  120. there are very few companies that have the resources to do it. It can be 
  121. difficult breaking though the parochialism that effects so many 
  122. companies, but I think it is important if we are going to achieve our 
  123. goals for reuse.
  124.  
  125. 3   Biography
  126.  
  127. Ralph Johnson is on the faculty of the Department of Computer Science 
  128. at the University of Illinois.  He was program chair of OOPSLA'93, and is a 
  129. coathor of "Design Patterns: Elements of Reusable Object-Oriented 
  130. Software" with Erich Gamma, Richard Helm and John Vlissides.
  131.