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 / wisr4 / proceedings / detex / batory.detex next >
Text File  |  1992-04-27  |  10KB  |  242 lines
  1.  
  2. On the Differences Between Very Large Scale Reuse and Large Scale Reuse 
  3.  
  4. Don Batory 
  5. Department of Computer Sciences 
  6. The University of Texas 
  7. Austin, Texas  78712 
  8.  
  9. dsb@cs.utexas.edu 
  10.  
  11.  
  12.                         Abstract 
  13.  
  14.    Very large scale software reuse (VLSR) is an every-day occurrence
  15.    whereas large scale software reuse (LSR) remains an elusive and 
  16.    unrealized goal.  We offer an
  17.    explanation for this apparent contradiction in this paper.
  18.  
  19.    Keywords:   Genesis, realms, software building-blocks.
  20.  
  21.  
  22.  
  23. 1  Introduction 
  24.  
  25.    Very large scale software  are systems of 50K lines of code or greater.
  26. As-is reuse is the reuse of software without modifications.
  27. As-is very large scale software reuse (henceforth called    as-is VLSR )
  28. is an every-day phenomena.  Each time we build an application on top of Unix, 
  29. we are reusing Unix as-is.  Each time we build a graphical 
  30. front-end using Motif or Interviews, we are reusing Motif or 
  31. Interviews as-is.  Since both Motif and Interviews are built 
  32. upon X-windows, X-windows is reused as-is.  Creating pipes 
  33. in Unix, where processes of prewritten file filters are glued 
  34. together, is yet another example.  In general, 
  35. as-is VLSR occurs anytime we build applications upon existing software.
  36.  
  37. There are two general conditions for as-is reuse to occur.  They 
  38. are when users (1) agree to use the abstractions provided by existing 
  39. software and (2) agree to use the existing implementations of 
  40. these abstractions.  Both points are self-evident: if the abstractions 
  41. presented by software components in a library are not relevant to an 
  42. application, they obviously will never be (re)used.  Similarly, 
  43. if performance or special features are critical requirements and 
  44. existing software doesn't provide either, then that 
  45. software cannot be (re)used without modification.
  46.  
  47. There probably is universal agreement that in the ideal case software 
  48. components should be reused as-is.  Since as-is VLSR
  49. is already is a daily occurrence, 
  50. and large scale reuse (LSR) is known to be a fundamentally difficult 
  51. problem, where is the contradition?  Why 
  52. has as-is VLSR been successful while as-is LSR has not?  To
  53. answer this question, we introduce a model of VLSR and LSR.
  54.  
  55.  
  56.  
  57. 2  A Model of As-Is Reuse 
  58.  
  59. From our work on Genesis and Avoca [Bat88, Bat91a, Bat91b, OMa90, Pet90], we 
  60. have shown that large software systems correspond to type expressions.  
  61. Our idea
  62. is simple.  Let R be the function-call interface to a software system.
  63. In principle, we know that there can be many different implementations 
  64. of R.  We define the    realm  of R to be the set of all software systems that
  65. support exactly interface of R.  The members of realm/interface R 
  66. can be listed as an enumerated type.  Two possible realms 
  67. R and S are shown below:
  68.   
  69.   R  =     a, b, c    
  70.  
  71.   S  =     d[ x:R ], e[ x:R ], f[ x:R ]   
  72.  
  73.  
  74. Interface R has three implementations, namely the software components a,
  75. b, and c.  Similarly, interface S is implemented
  76. by the components d, e, and f.  Observe that realms group 
  77. together all components that are    plug-compatible  and
  78.    interchangeable .  For example, because all components
  79. of R implement the    same  interface, one can swap one 
  80. implementation/component of R with another.  The same applies
  81. for components of other realms.
  82.  
  83. Components may have parameters.  All components of S,
  84. for example, have a single parameter of type R.  What this means
  85. is that a component d[ x:R ] of S translates objects and
  86. operations of the interface of S to objects and operations
  87. of the interface of R.  The translation itself    does not
  88. depend  on how R is implemented.  This
  89. means that    any  implementation of R can be `plugged'
  90. into component d to make it work.
  91.  
  92. Software systems correspond to    type expressions .  Two systems
  93. are shown below:
  94.   
  95.   System 1  =  d[ b ]
  96.   
  97.   System 2  =  f[ b ]
  98.  
  99.  
  100. System 1 is a composition of component d with b; System 2 is
  101. a composition of component f with b.  Since both of these systems
  102. present the same interface (i.e., both present the interface of S),
  103. System 1 and System 2 are also interchangeable implementations of S.
  104.  
  105. The way we have modeled software makes as-is reuse easy to
  106. spot.  Consider two systems and their type expressions.  If both
  107. expressions reference the same component, then that component is being
  108. reused.  Note that System 1 and System 2 reuse component b.
  109. More generally, if two systems have a common subexpression, then 
  110. these systems share a common subsystem.
  111.  
  112. Finally, observe that our model of software construction is independent of 
  113. component size.  Components can be very large (i.e., the size of Unix and
  114. X-windows), or they could be substantially smaller [Bat91a, Bat91b, Bat91c].
  115. Thus, our model can be used to explain as-is VLSR as well as as-is LSR.
  116.  
  117.  
  118.  
  119. 3  An Example 
  120.  
  121. Consider the following realms.  Let UNIX denote the realm of systems 
  122. that implement the Unix interface.  Let XW denote the realm of
  123. X-window interface implementations, and MOT be the realm of implementations of
  124. the Motif interface.  Finally, let APPL be the realm of applications
  125. whose interface takes command-line and mouse-click inputs.  Typical
  126. population of these realms are:
  127.   
  128.   UNIX   =     bsd4.3, system5  
  129.   
  130.   XW    =     xwindows[ x:UNIX ]  
  131.   
  132.   MOT   =     motif1.1[ x:XW ]  
  133.   
  134.   APPL  =     myprog[ x:MOT, y:UNIX ], ...  
  135.  
  136.  
  137. We have taken a few liberties in defining the above realms to keep our
  138. example simple.  Note that we have lumped bsd4.3 and system5 together in 
  139. the same realm (UNIX).  Actually, there are significant differences between 
  140. Berkeley Unix and System 5, and in reality each belongs to its own distinct 
  141. realm.  For our purposes, however, both implement a common
  142. subset of interface functions which we define as the 
  143. UNIX realm interface.  Another point worth
  144. mentioning is that we have simplified our model of the motif[ ]
  145. and xwindows[ ] components by omitting parameters (i.e., their calls to the
  146. Unix interface).  We leave it to readers as a straightforward exercise
  147. to eliminate these simplifications.
  148.  
  149. Recall that systems correspond to type expressions.  Suppose `myprog' is 
  150. an application program that makes calls to the Unix and Motif interfaces.  
  151. Motif, in turn, translates its calls into X-window calls, which in turn, 
  152. translates into calls to Berkeley Unix.  The layering of very large scale 
  153. software that defines this system is given by the expression:
  154.  
  155.   My System  =  myprog[ motif1.1[ xwindows[ unix4.3 ] ], unix4.3 ]
  156.  
  157.  
  158. By swapping the unix4.3 component with system5, we have 
  159. ported My System to System 5 Unix.
  160.  
  161. As a step toward understanding the problems of LSR, consider the
  162. membership of contemporary realms.  As a general rule, most realms today 
  163. have very few components.
  164. The members of the UNIX realm, for example, are the current implementation(s)
  165. of Unix plus out-dated versions.  The same for XW (X-windows)
  166. and MOT (motif).  The reason is simple: interfaces to software systems
  167. tend to be ad hoc and unique.  The institution that designed the interface 
  168. of a system also built that system, and maintains only one implementation
  169. of it (modulo version and platform upgrades).  The idea of
  170. building a family of different implementations for an interface is not
  171. yet popular.  Consequently, typical realms have singleton (or very small) 
  172. memberships.  This provides us with a key clue to resolving the contradiction 
  173. we identified earlier.
  174.  
  175.  
  176.  
  177. 4  Explaining the Contradiction 
  178.  
  179. As mentioned earlier, 
  180. as-is VLSR is an every-day occurrence while as-is LSR remains an
  181. unrealized goal.  The techniques that have been proposed
  182. for as-is LSR (e.g., formal methods) have had difficulties scaling-up.
  183. Oddly enough, the simple ideas that have made as-is VLSR work have not 
  184. been successfully    scaled-down  so that large (sub)systems like unix4.3, 
  185. xwindows, motif1.1, etc., can themselves be defined from compositions of 
  186. more primitive components.
  187.  
  188. Recall the two conditions for successful as-is reuse.  Users must (1)
  189. agree to use the interface abstractions of existing software and (2)
  190. agree to use the implementations of these interfaces.  As a community,
  191. we have not been successful in agreeing on the interfaces/abstractions that lie
  192. inbetween the interfaces of major systems (e.g., interfaces/abstractions
  193. in between Motif and X, between X and Unix, etc.).  Nor have we, as
  194. a community, truely realized the importance of families of systems
  195. that share the same interface but have different implementations.
  196.  
  197. Until these two issues are bridged, as-is LSR will continue to remain 
  198. elusive and unrealized.
  199. In [Bat91a] , we explore these issues further, and present a validated
  200. approach for achieving as-is LSR.
  201.  
  202.  
  203.  
  204.   References
  205.   
  206. [Bat88]  D.S. Batory, `Concepts for a Database System Synthesizer', ACM PODS 
  207.      1988, 184-192.
  208.  
  209. [Bat91a] D.S. Batory and S.W. O'Malley, `The Design and Implementation of
  210.          Hierarchical Software Systems Using Reusable Components', submitted 
  211.      for publication.
  212.  
  213. [Bat91b] D.S. Batory and S.W. O'Malley, `Genvoca: Reuse In Layered Domains',
  214.          Proc. 1st International Workshop on Software Reuse, Dortmund, 
  215.      Germany, 1991.
  216.  
  217. [Bat91c] D.S. Batory and S.W. O'Malley, `A Definition of Open Architecture
  218.          Systems with Reusable Components: Preliminary Draft', ICSE Domain 
  219.      Modeling Workshop, 1991.
  220.  
  221. [Pet90]  L. Peterson, N. Hutchinson, H. Rao, and S.W. O'Malley, `The x-kernel: 
  222.          A Platform for Accessing Internet Resources'.  IEEE Computer (Special 
  223.      Issue on Operating Systems), 23,5 (May 1990), 23-33.
  224.  
  225. [OMa90]  S.W. O'Malley and L. Peterson, `A New Methodology for Designing 
  226.      Network Software', University of Arizona TR 90-29 (Sept. 1990). 
  227.      Submitted for publication.
  228.  
  229.  
  230.  
  231.   Biography 
  232.  
  233. Don Batory is an Associate Professor in the Department of Computer
  234. Sciences at The University of Texas, Austin.  He received his 
  235. Ph.D. from the University of Toronto in 1980, he was Associate
  236. Editor of the IEEE Database Engineering Newsletter from 1981-84
  237. and was Associate Editor of ACM Transactions on Database Systems
  238. from 1986-1991.  He is currently a member of the ACM Software 
  239. Systems Award Committee, and his research interests are in 
  240. extensible and object-oriented database management systems 
  241. and large scale reuse.
  242.