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 / wisr6 / proceedings / ascii / levine.ascii < prev    next >
Text File  |  1993-10-19  |  11KB  |  251 lines
  1.  
  2.  
  3.  
  4.  
  5.              Integrating  Reuse  Into  A  Software  Curriculum
  6.  
  7.  
  8.  
  9.                                                Trudy  Levine
  10.  
  11.  
  12.  
  13.                                    Fairleigh Dickinson University
  14.  
  15.                                              1000 River Road
  16.  
  17.                                            Teaneck, NJ 07666
  18.  
  19.                                       Tel:  (201) 692-2020 (2261)
  20.  
  21.                                    Email:  levine@sun490.fdu.edu
  22.  
  23.  
  24.  
  25.                                                   Abstract
  26.  
  27.  
  28.     At the 5th International Conference on Software Engineering and Knowledge Engineering
  29. (SEKE'93), a workshop was held on June 18th for the purpose of studying the integration of
  30. reuse into software education.  We noted the dearth of software reuse in software engineering
  31. programs and textbooks.  Topics were established for further discussion and evaluation.
  32.  
  33.  
  34. Keywords: software reuse, software education, reuse education
  35.  
  36.  
  37. Workshop Goals:  Learning; networking; advancing the state of software education and cur-
  38. riculum with software reuse
  39.  
  40.  
  41. Working Groups: reuse education, etc.
  42.  
  43.  
  44.  
  45.                                                   Levine- 1
  46.  
  47.  
  48. 1      Background
  49.  
  50.  
  51.  
  52. 1.1     Integrating Reuse Into A Software Curriculum
  53.  
  54.  
  55.  
  56. Consider the following two major questions:
  57.  
  58.  
  59.  
  60.     fflHow can software reuse improve software education?
  61.  
  62.  
  63.     fflHow can the study of software reuse be carried into industry?
  64.  
  65.  
  66.  
  67. Software reuse promises to aid in the production of reliableand cost efficient systems.  As such, it
  68. should surely be part of a software curriculum. Even more important, perhaps, is the fact that a
  69. standardized and controlled method of studying reuse, similar to the study of expert work in the
  70. social sciences, can be a valuable tool in computer science education.
  71.  
  72.  
  73. For the purpose of softwareeducation, software reuse should include reuse of code, specifications,
  74. and various types of documentation.  In addition, students should be taught and encouraged to
  75. reference previously created systems and to create new software systems at least partially from pre-
  76. viously developed components. This material should be able to be integrated into existing software
  77. engineering and computer science curriculum without major changes. In addition, the construction
  78. of  previously  developed  components  should  be  available  for  study, to  aid  in  the  development  of
  79. techniques and talent.
  80.  
  81.  
  82. As agreed elsewhere in the conference, as software systems grow in size and complexity there are
  83. increasing occurrences of cost overruns, time overruns,and system failures.  Indeed, as more and
  84. more critical functions are controlled by software systems, the dangers of system failures are rather
  85. frightening.
  86.  
  87.  
  88. Software  reuse  can  aid  system  reliability  in  that  integrated  components  will  probably  be  better
  89. understood, crafted, and tested in the process of designing for reuse. There also can be considerable
  90. cost and time savings if components can be easily located and integrated.  That could lead to greater
  91. reliability as well, because it is the time crunch that frequently causes developers to take short cuts
  92. in designing and testing. Of course, we do not think reuse is a software bullet, nor do we think that
  93. it can be achieved easily. We recognize the problems encountered, such as the cost of designing for
  94. reuse and the difficulties (technical, legal, social, etc.) in using components developed outside of
  95. an organization.
  96.  
  97.  
  98. Designing for reuse as well as designing with reuse pose particular problems in academia.  Teachers
  99. do not wish to put their efforts into learning a technology that is not yet mature and indeed that may
  100. not even be successful. Particularly in the field of computer science,there is so much new technology
  101. to  learn  daily  that  teachers  must  ration  their  time  carefully.   Methodologies  and  standardized
  102. taxonomies, templates, and metrics have not yet been developed.  Appropriate textbooks and other
  103. course  materials  have  not  yet  been  produced.  The  allocation  of  course  time  in  academia, via
  104. semesters of a few months,  may not be appropriate for learning reuse material.  And,  of course,
  105. grading  in  academia  has  traditionally  penalized  students  that  "reuse"  others'  work.  Unlike  the
  106. social sciences, where students are expected to research good quality work (evaluated by experts
  107. and maintained in a library) and integrate this work into their own with appropriate footnotes,
  108. computer science courses usually have students write code "from scratch."  There are exceptions
  109. with C and FORTRAN libraries, for example, but the level of reuse is small and lightly documented.
  110.  
  111.  
  112.  
  113.                                                          Levine- 2
  114.  
  115.  
  116. 2      Position
  117.  
  118.  
  119.  
  120. In trying to answer the two proposed questions, our group made the following suggestions:
  121.  
  122.  
  123.  
  124.     1. Each University should establish a component library.  Standards are emerging for libraryin-
  125.        teroperability, and these should be adhered to where possible.(See rig@ballston.paramax.com
  126.        and  ajpo.sei.cmu.edu.)  Components of the librarycan b e code,  documents,  sp ecifications,
  127.        etc., but standards must be defined and maintained in a specified form. For example, module
  128.        headers (that include performance characteristics as well as other information specified by
  129.        RIG)  and  test  suites  of  a  standard  form  must  be  included  with  all  code.  Multiple  imple-
  130.        mentations of the same specification are very valuable, and these should be easy to obtain
  131.        if a course includes assignments of components according to specifications, and the professor
  132.        stores the specification with a few of the best projects (each with possibly different perfor-
  133.        mance charcteristics).
  134.  
  135.        A component that is inserted into the library must be approved by a professor of an appro-
  136.        priate department and also by a librarian, whose job it is to guarantee that all components
  137.        satisfy the prescribed format.  Components can only be accessed for reading (perhaps code
  138.        stored in source form, so that anyone can copy it, compile it, and execute it, but not change
  139.        it  in  the  library).  The  librarian  only  will  control  changes  (possibly  deletion)  if  errors  are
  140.        detected.
  141.  
  142.        Beginner courses in computer science and software engineering should require the use and
  143.        documentation of components from this library into assigned projects.  New systems would
  144.        therefore have modules of others that clearly indicate where, when and by whom they were
  145.        developed.  Later courses should more thoroughly integrate larger and more varied compo-
  146.        nents.
  147.  
  148.        A black box approach [1 ] is very valuable in industry where it is comparable to engineering
  149.        pluggable components.  Program instantiations and transformations have equal importance,
  150.        similar  to  the  customization  of  hardware  components.  Perhaps,  however,  a  white  box  ap-
  151.        proach  is  most  applicable  to  an  educational  curriculum  spread  over  a  few years.   Thus, a
  152.        white box approach allows viewing of portions of code, documentations, etc. that illustrate
  153.        standards and techniques for users to follow and can be incorporated into new systems as long
  154.        as they are appropriately referenced.  This process is similar to the analysis and integration
  155.        of the research of an English major and has some relevance to art and music education.
  156.  
  157.     2. Encourage faculty development in reuse technology.  One of the ways might be to maintain
  158.        among ourselves a list of companies that want this technology, so that we can publicize this
  159.        information to our colleagues.
  160.  
  161.     3. Encourage development and use of methodologies that support reuse.  Object oriented pro-
  162.        gramming does appear to be such a technology, although we recognize that it neither does the
  163.        whole job, nor comes without a cost. Similar comments can be made about Ada programming.
  164.  
  165.     4. Develop appropriate software projects, possibly covering several semesters.
  166.  
  167.     5. Use existing libraries such as ASSET, CARDS, AJPO.
  168.  
  169.     6. Maintain a list of references to support reuse education in particular. Below are references [1,
  170.        2 , 3 , 4 , 5 ] requested by memb ersof the group.  The references where chosen for the specific
  171.        purpose of reuse education, not for reuse information in general.
  172.  
  173.  
  174.  
  175.                                                          Levine- 3
  176.  
  177.  
  178. 2.1     Group Members
  179.  
  180.  
  181. Trudy Levine         - FDU 1000 River Road, Teaneck, NJ 07666, levine@sun490.fdu.edu
  182.  
  183. Zeb Awan         - Bell Northern Research, Canada
  184.  
  185. Armin Beer         - Siemens Vienna, Austria
  186.  
  187. Frank Coyle        - SMU, coyle@seas.smu.edu
  188.  
  189. Jofo Franco        - Telebras Rtd Center, Brazil, franco@cpqd.ansp.br
  190.  
  191. Thomas Hemmann                - GMD,hemmann@gmd.de
  192.  
  193. Masayufi Ishifawa           - Hitachi SoftwareEngineering Co., Ltd.  ishi@eecs.umich.edu
  194.  
  195. Trent Jaeger        - Michigan U., jaegert@eecs.umich.edu
  196.  
  197. Mike Laux        - Michigan State University, laux@cps.msu.edu
  198.  
  199. Toshimi Minoura            - Oregon State University, minoura@cs.orst.edu
  200.  
  201. Jeffrey Poulin        - IBM FSC, poulinj@vnet.ibm.com
  202.  
  203. David Russell         - Penn State Great Valley, rzn@psugv.psu.edu
  204.  
  205. Angi Voss       - GMD, angi.voss@gmd.de
  206.  
  207. David Wan         - National Center for High Performance Computing, c00dcw00@nchc.edu.tw
  208.  
  209.  
  210.  
  211. References
  212.  
  213.  
  214.  
  215. [1]  W.Tracz, ed., Software Reuse: Emerging Technology. IEEE Computer Science Press, 1990. (A
  216.      compilation ofseminal papers).
  217.  
  218.  
  219. [2]  Proceedings of the lst Reuse Education and Training Workshop, June 18th 1993. Available for
  220.      downloading from source.asset.com.
  221.  
  222.  
  223. [3]  G. Sindre,  E.Karlsson,  and T. Stalhane,  "Software reuse in an Educational Perspective,"  in
  224.      Proceedings  of  the  1992  Software  Engineering  Education  Conference, Norwegian  Institute  of
  225.      Technology, Springer-Verlag, 1992.
  226.  
  227.  
  228. [4]  T.  Biggerstaff  and  A.  Perlis,  eds.,  Software Reusability,  vol.  1.  Addison  Wesley, 1989.   (A
  229.      compilation ofseminal papers).
  230.  
  231.  
  232. [5]  T.  Biggerstaff  and  A.  Perlis,  eds.,  Software Reusability,  vol.  2.  Addison  Wesley, 1989.   (A
  233.      compilation ofseminal papers).
  234.  
  235.  
  236.  
  237. 3      Biography
  238.  
  239.  
  240.  
  241. Trudy Levine has been writing a column for Ada Letters called Reusable Software Components
  242. since  1990, which  has  been  reprinted  in  Crosstalk  and  maintained  in  several  electronic  bulletin
  243. boards. She is an Associate Professor of Computer Science at Fairleigh Dickinsonand a correspond-
  244. ing member of RIG. She has been trying to augment reuse material in hersoftware engineering
  245. courses over the last few years and hastaught a special topics seminar course on software reuse.
  246. Her research interests also include conflict control and the Ada programming language.
  247.  
  248.  
  249.  
  250.                                                          Levine- 4
  251.