Position

In trying to answer the two proposed questions, our group made the following suggestions:

  1. Each University should establish a component library. Standards are emerging for library interoperability, and these should be adhered to where possible.(See rig@ballston.paramax.com and ajpo.sei.cmu.edu.) Components of the library can be code, documents, specifications, etc., but standards must be defined and maintained in a specified form. For example, module headers (that include performance characteristics as well as other information specified by RIG) and test suites of a standard form must be included with all code. Multiple implementations of the same specification are very valuable, and these should be easy to obtain if a course includes assignments of components according to specifications, and the professor stores the specification with a few of the best projects (each with possibly different performance charcteristics).

    A component that is inserted into the library must be approved by a professor of an appropriate department and also by a librarian, whose job it is to guarantee that all components satisfy the prescribed format. Components can only be accessed for reading (perhaps code stored in source form, so that anyone can copy it, compile it, and execute it, but not change it in the library). The librarian only will control changes (possibly deletion) if errors are detected.

    Beginner courses in computer science and software engineering should require the use and documentation of components from this library into assigned projects. New systems would therefore have modules of others that clearly indicate where, when and by whom they were developed. Later courses should more thoroughly integrate larger and more varied components.

    A black box approach [#!Tra90!#] is very valuable in industry where it is comparable to engineering pluggable components. Program instantiations and transformations have equal importance, similar to the customization of hardware components. Perhaps, however, a white box approach is most applicable to an educational curriculum spread over a few years. Thus, a white box approach allows viewing of portions of code, documentations, etc. that illustrate standards and techniques for users to follow and can be incorporated into new systems as long as they are appropriately referenced. This process is similar to the analysis and integration of the research of an English major and has some relevance to art and music education.

  2. Encourage faculty development in reuse technology. One of the ways might be to maintain among ourselves a list of companies that want this technology, so that we can publicize this information to our colleagues.

  3. Encourage development and use of methodologies that support reuse. Object oriented programming does appear to be such a technology, although we recognize that it neither does the whole job, nor comes without a cost. Similar comments can be made about Ada programming.

  4. Develop appropriate software projects, possibly covering several semesters.

  5. Use existing libraries such as ASSET, CARDS, AJPO.

  6. Maintain a list of references to support reuse education in particular. Below are references [#!Tra90!#,#!RETW1!#,#!SKS92!#,#!BP89a!#,#!BP89b!#] requested by members of the group. The references where chosen for the specific purpose of reuse education, not for reuse information in general.



Subsections