Issues and perspectives

S , oftware engineers/program- mers are constantly called upon to produce more and

more software, and their productivity continues to be an increasingly press- ing problem. Recent surveys and papers on the reusability of software indicated that software reuse is a major way to boost software engi- neering productivity. One survey indi- cated that 40-60% of all code is reusable from one application to another, 60% of the design and code on all business applications are reusable, and 75% of program func- tions are common to more than one program. The survey also indicated that only 15% of the code found in most programs is unique and novel to each specific application.

The potential payoff from replac- ing expensive development activities with relatively inexpensive reused parts is too attractive to ignore. Over the life cycle of a system, reuse can provide many advantages over a tradi- tional “designing from the ground up.” They include:

1. Shortening development cycles and lowering production costs in future development efforts.

2. Improving system reliability by reusing components that have been (at least operationally) proven correct, and reducing the need for system testing.

3. Reducing life cycle maintenance cost by reducing the “ripple” effect of program changes through design abstraction.

4. Enabling the developing organi- zation to recover its investment in existing software systems when pro- ducing new programs and conducting new design efforts.

The list of the names of organiza- tions that were emphasizing reuse was very short at the end of the eighties. Today most of the major software shops (public and private) consider the development of reusable software, or

reusing existing software, as a top pri- ority. Special multinational projects in Europe have been organized to focus on the development of reusable soft- ware. The Japanese software shops are considered among the leaders in soft- ware factories, which place a heavy emphasis on the reuse technology.

Software reuse could be implement- ed at several levels including the speci- fication level, design level, program/subprogram library level, code level, and object-code level. How- ever, reuse has a distinct definition for each of the above-mentioned levels. Moreover, the techniques applied to organize and manage reuse is different from one level to another. What’s more, the complexity of the reuse methods and techniques increases as it moves from the specification level to the code and object-code levels. On the positive side, the time and space effi- ciency resulting from the application of reuse techniques improves in the same direction.

Specification and design levels are at higher levels of abstraction than the other reuse levels, therefore their potential for accommodating reuse is greater and their adaptation to new applications can be simpler. Howev- er, the reuse process of the specifica- tion and design levels ultimately involves coding (be it system-gener- ated or manual), testing, and debug- ging. On the other hand, reuse at code and object-code levels essential- ly eliminates coding and overall test- ing, hence it is more economical where a large collection of reusable software is organized in a software library.

Reusability is not limited to code and design artifacts. All components and aspects of software, i.e., docu- ments, planning, requirement analysis/specification, contracts, test plans/cases, and so forth, should ideally be designed and prepared to be reused.

The Image BanWJim Deal

Regardless of the level of reuse, the design of a successful reuse environ- ment should address the following:

1. Identification of and providing access to a segment of code or mod- ule of a program based on user requirements (locating);

2. Facilitating program modifica- tion (customization); and

3. Providing facilities to store, retrieve, and integrate the reusable components efficiently (configura- tionlversion management).

The design should also provide answers to the following questions: in an environment where software is reused, what is the unit of reuse and how can these units be put together and maintained as a repository?

\UGUST/SEPTEMBER 1994 0278-6648/941$4.QQ 0 1994 IEEE 15

Historical background Creating a library of scientific rou-

tines was originally proposed by Mau- rice Wilkes (1949), when the f is t set of programs were stored in the EDSAC computer at the University of Cam- bridge. So this is not a new idea. How- ever, McIlroy’s visionary paper on software reuse, presented in the NATO Software Engineering Conference of 1968,was considered by some, includ- ing J. M. Neighbors, as the seminal document on software reuse. As a result, the following year Neighbors presented the idea of program compo- nent factories in a paper. Thus, 1969 is regarded as year zero in the f is t period (1969-1983) of software reuse.

The idea of “software factories” was used in 1977 in the computer division of Toshiba. The key factor for this success- ful undertaking by the Japanese industry was that they were first in justlfying the amortized cost of developing the crucial bulk of reusable software and the cost of the software engineering environment necessary to succeed. The effort of the Japanese computer industry started to pay off in the mid 80s. In the early OS, some US commercial organizations and government agencies (TI and Depart- ment of Defense in particular) engaged in major research and development ini- tiatives on software reuse.

Models and techniques There are six major models of software

reuse. In order to maintain consistency in the comparison of the different reuse models and techniques, the following cri- teria for model evaluation (origmally pro- posed by C. W. Ktueger) is used:

1) Abstraction: the unit of reuse and the level of abstraction.

2) Selection: The method to select the reusable components.

3) Customization (also called spe- cialization): How the components are customized for reuse.

4) Integration: How the components are integrated.

The reuse models considered in this study generally fall into three cate- gories, namely, accidental (ad hoc) reuse, design for reusing existing soft- ware, and design for reusability. The first two models Design and Code Scavenging and Source Code Compo- nents are the main approaches in the accidental reuse or design for reusing existing software. The last three models are designs for reusability.

Many research papers/studies are based on employing ad hoc methodolo- gies (i.e., accidental reuse) in reusing existing source code. Therefore, speci- fication, classification, and verification seem to have very limited application in SCC and DCS. This presumption can lead to ignoring the idea of “designing to reuse existing software” and ignor- ing the potential and actual future value of millions of dollars of software which already exists.

It should be noted that although the models present different categories of reuse models, in reality most of the existing reuse approaches utilize a combination of two or more of these models. Furthermore, currently there is no one model that can be shown to be the best one for software reuse. These models differ in their potential invest- ment requirements and their potential degree of reusability.

Design and Code Scavenging (DCS)

Design and code scavenging is an ad hoc “model” for using the design and fragments of an existing software sys- tem. The goal of this model is to reduce the amount of time and effort expended in the software development life cycle. The efficiency of DCS is based on the experience of and the information available to the designer/developer.

Source Code Components (SCC)

Given the availability of a large number of software components, simi- lar to the Japanese “software factory,” one could ask “does a part exist that performs this function?”. The goal of the off-the-shelf SCC model is to pro- vide an answer to the above-mentioned query. Compared to DCS, this model of reuse is more effective because the components are designed and devel- oped for the purpose of reuse and are organized in a library. Examples of successful SCC are the SPSS statistical libraries and IMSL math library.

Modem languages like Ada, Modu- la-2, and Smalltalk-80 not only provide features for developing reusable com- ponents, but also provide mechanisms to make a distinction between abstrac- tion and implementation. Krueger believes that, although in a few narrow areas this model has been successful,

the applicability of SCC in more broad areas is not yet clear. The specific areas of engineering and mathematics are examples of succesful application of SCC. However, this model could become very effective where an envi- ronment that facilitates the SCC model of reusability exists.

Program Schemes (PS) In this approach, the software com-

ponents are designed to be reusable. The program scheme model emphasizes the reuse of algorithms and data abstractions rather than code. Each scheme consists of a variable part and a fixed part (analo- gous to an abstraction). The variable part describes the range of options for which a scheme can be instantiated. The fixed part formally describes what computa- tion or structure a scheme represents. The library of a PS system is a collection of program schemes. Aside from the specifications, each scheme needs to have other information such as how to instantiate the scheme and assertions about the valid use of various scheme instantiations. The PARIS system is an example of a PS model.

Very High-Level Languages (VHLL)

The goal of VHLLs is to construct an abstract model suitable for reason- ing, and to provide a concise and expressive formal notation for abstrac- tion specification. Execution time opti- mization is not the primary objective of VHLL design, rather it is typically the ability to facilitate software develop- ment. The level of reuse in VHLLs is data and implementation specification. A VHLL employs its compiler to map abstraction specification directly into executable abstraction realization. Meld and MODEL are examples of VHLLs that have been used for reuse.

Transformation Systems (TS) A transformation is a mapping from

programs to programs. In this model, two separate phases are employed for software development. The first phase involves providing the specification of software behavior in a high-level speci- fication language like an executable VHLL. The second phase is transform- ing the specification produced in the first level into an enhanced executable system. The transformation process is mostly an interactive one and requires

16 IEEE POTENTIALS

human-guided compilation. This is due to the lack of efficient automatic algo- rithm and data structure selection facili- ties. PADDLE and Giltter are examples of systems that employ the TS model.

Classification and identification

Component libraries, classification schema, and locating assets have been the three central issues in software reusability. Prieto Diaz and Freeman, and Burton and Argon have used soft- ware classification schemes as a kernel for software reusability system. A col- lection of modules or program compo- nents are organized by attributes that define software structure, environment, function, implementation, and so forth.

According to Prieto Diaz, “classifica- \.ion is grouping like things together.” All members of a group or class produced by classification share at least one char- ateristic that members of other classes do not possess. Classification displays he relationships that exist among things md among classes of things. A classifi- cation scheme is a tool to produce a sys- tematic order based on a controlled and 1;tructured index vocabulary.

Prieto Diaz and Freeman suggest that the characterization of a software component’s functionality (what it does) and its environment (where it does it) suffice for classification. Bur- Ion and Argon use an algorithm’s description, documentation, testing his- tory, and version management plus its functionality and environment, as the classification attributes.

The Prieto Diaz/Freeman classifica- tion method actually employs a con- trolled vocabulary technique for indexing <,oftware. They have used this technique to avoid duplicate and ambiguous descriptors of software components.

Another method of software classifi- cation and identification is abstraction. Abstraction has been used to help man- age the intellectual complexity of soft- ware development. Abstraction con- tributes to simplification by secluding irrelevant attributes from the relevant one. In other words, to transform a problem to a simpler one, certain details within the original problem are overlooked. The most common types of abstraction of <,oftware are abstraction by parameteriza- tion and abstraction by specfication.

Locating reusable components is becoming an activity that is increasing-

ly performed by automated systems such as Gopher and World Wide Web, through bulletin boards, news bulletins, or with information-brokerage applica- tions. Therefore, a new dimension has been added to the problem of locating software components.

Domain analysis Domain analysis is a major factor in

the successful development of reusable software. Domain analysis is a process by which information used in develop- ing software for a specific application problem area is identified, captured, and organized with the goal of making it reusable.

Arango sees reuse as a learning sys- tem. In his proposed model, software development is a self-improving process that draws from a knowledge source, which is named reuse infra- structure, and is integrated with the software development process. Reuse infrastructure consists of reusable resources and their descriptions.

In the reuse environment promoted by Arango, the desired software is implemented (i.e., constructed) using both the reuse infrastructure and the specification of the software to be built. The software produced is compared to the input to the system (i.e., the specifi- cation of the system).

The typical process of an integrated software development and domain analysis procedure is as follows. First, the reusable resources are identified and added to the system. Then the reuse data is gathered and fed back to the domain analysis system for tuning the domain models and updating the resource library. Finally, the newly- developed system, as a member of the existing system, is used to refine the reuse infrastructure.

The lack of a formal and systematic methodology is the primary issue in domain analysis. Typically, domain analysis is recommended for specific applications. Therefore domain analysis is restricted to limited-domain software and not appropriate for general reusability environments. Domain spe- cific kits is an approach that utilizes a set of reusable tools that are designed to facilitate the development of applica- tions in such a limited-domain.

Cognitive distance in reuse Successful reuse faces some chal-

lenging dilemmas that are cognitive in

their natures. One such problem is the notion of cognitive distance. Cognitive distance is defined as “the amount of mental effort that must be expended by the software developers in order to take a system from one stage in the develop- ment life cycle to another.” This con- cept could be used as one of the metria to compare the reuse models. The smaller the intellectual effort required to convert an existing module to a desired module, the more useful the system. Of course, to reduce the cogni- tive distance, other factors such as effi- ciency and practicality of the system cannot and may not be ignored. An intelligent support system, as one part of an integrated software environment, enhances the learning and understand- ing of the software components. Differ- ent approaches and tools can be utilized to reduce the cognitive distance and facilitate the reuse process. These approaches include: tutoring, help facil- ities, and learning on demand.

Direction of research To recommend feasible research

directions one needs to examine the cur- rent state of the reuse technology, the nec- essary tools, and the state of the practice.

Reuse technology. Reuse technology lacks a formal and complete picture of what to reuse and how to reuse it. Research in this area needs to focus on and to ascertain how to enhance the exist- ing capabilities to capture, modify, and reuse a wide range of information in the development process. A rich machine- processable representation and a clear strategy to lead to the optimum approach to reusability is specifically needed.

State of the art. Techniques and methods to facilitate reusable software engineering (i.e., encapsulation, formal- ization, module interconnection lan- guage, organization and retrieval of software components in large reposito- ries, and programming and detailed design techniques) are available or are emerging, but most of them need to be tailored to facilitate productive reuse.

State oj-the practice. Very few orga- nizations produce reusable software or systematically attempt to reuse existing software.The advantages of applying reuse technology could be shown by long term cost analysis. Furthermore management needs to provide policies and incentives to motivate the applica- tion of the reuse technology.

Considering the above-mentioned

AUGUST/SEPTEMBER 1994 17

Evaluating the models according to Krueger‘s criteria DCS

(i) Abstraction: There is no formal abstraction, information on the com- ponents might be stored in a simple library.

(ii) Selection: Selection is either from the library or based on the pro- grmer/designer’s memory.

(iii) Customization: Manual edit- ing of the code fragments. Under- standing the differences between the old and the new systems is a crucial factor in successful customization of this reuse model.

(iv) Integration: Integration and customization are actually merged into one phase in this model, the pro- grammer/designer must have a good knowledge of the semantics of the language and understand the impact of the customization and integration on the modified components of the software system,

sec (i) Abstraction: In a limited

domain with a set of short, well- defied specifications for the compo- nents, abstraction is a trivial task (e.g., with regression analysis and standard deviation as functions of a statistical library, or abstract data types like stack, queue, various types of trees, etc.). For other cases a high- er-level language is required to pro- vide abstraction. For example, the

Anna environment provides abstrac- tion facilities for the formal specifi- cation and abstraction of the Ada programming environment.

(ii) Selection: Facilities like Anna are difficult to understand and use, and are only partially helpful in selecting the components. One solution is the classification of the components and providing a manual or automatic search scheme to help the useddevel- oper in finding the desired compo- nent(s). One example of this approach is the IMSL library. Employing a specification language to describe the components will facilitate the selection also. However, this approach may not be of any significant help in a large system without an appropriate abstrac- tion and classification scheme or with- out the existence of an integrated software reuse environment.

(iii) Customization: Direct editing is the main method to customize the code for new applications. This method has the same basic problems that the DCS model has, i.e., the impact of modifications on other components. Krueger considers “work at a low level of abstraction” another drawback of this model. In fact, this is not a drawback for all cases, we believe in some environ- ments such as ROPCO (Reuse Of Persistent Code and Object code), the low level of work adds to the

capabilities of the environment. Another approach for customization is using parameterized components such as the Ada generic package. The use of parameterized packages relieves the burden of validation of the modified components. The gener- ic parameter(s) of a parameterized package is (are) declared in such a way that the type of element, for which it is instantiated, satisfies the parameter requirements .

(iv) Integration: Module Intercon- nection Languages (MIL) are used for the integration of the reusable components. The main problem with MIL’S is the issue of the name space. An efficient MIL must be able to help by resolving this problem.

PS (i) Abstraction: Formal semantic

specification, like plan calculus, combination of first-order logic and directed graph, temporal logic, and axioms and theories are employed to provide program specification and abstraction in PS.

(ii) Selection: A composition of a hierarchical classification scheme, a multiple abstraction specification exposition and an efficient search scheme, form a good selection scheme. The size of the library is con- sidered one of the major factors in the design of a software library. Large

tacts, the main inhibitors of software reuse could be classified into the fol- lowing categories.

1) Inadequate representation tech- nology.

2) Lack of clear, obvious direction. 3) NIH (not-invented-here) factor.

Software developers tend to use only the software components created in their own shops.

4) High initial capitalization. The cost of developing reusable software is 1.8 to L!S times more than the cost of develop- ing conventional software.

Conclusion A majority of the published work

and experiences focus on the future of <,oftware by designing reuse models and techniques. The problem with this

approach is not a technical one, no one can ignore the contributions made by reuse researchers to the field of soft- ware engineering. The main problem with this approach is that it can result in ignoring the millions of lines of exist- ing code that may be reusable. It is unrealistic to believe that the develop- ment of reusable software will just hap- pen from a certain date in the relatively near future. We cannot wait until prac- tical and capable software environ- ments are available for producing reusable modules/programs. There are a large number of private and public organizations that cannot afford to switch from the old system to the new system not only because of budgetary constraints but also for the attendant operational problems. The proper solu-

tion for these organizations is a combi- nation of both approaches.

Read more about it G. Arango, A brief Introduction to

Domain Analysis, in Proceedings of the ACM Symposium on Applied Com- puting (SAC ’94), pages 42-46, Phoenix, AZ, March 1994.

G. Arango, M. Griss, W. Tracz, M. Zand, Software Reuse - Issues And Prospectives, Panel Abstract, in Pro- ceedings of the ACM Symposium on Applied Computing (SAC ’94), pages 596-598, Phoenix, AZ, March 1994.

M. Griss, Software Reuse: From Library to Factory, IBM System Jour- nal, 32(4), November 1993.

S. Isoda, Experiences of a Software Reuse Project, to be published in the

18 IEEE POTENTIALS

libraries need to use the (object-ori- ented) database technology with the capability of answering fuzzy ques- tions about program schemes, as is the case in the PS model.

(iii) Customization: Customiza- tion is a continuation of selection and is considered as filling in the slots in a scheme structure. This phase could be an insertion, a choosing, or both. In insertion, the variable parts of the scheme are filled by language con- structs, code segments, nested schemes, or specifications. Choosing consists of selecting from the library a high level of abstraction to satisfy the variable part of the scheme.

(iv) Integration: The module Interconnection Language (MIL) of the implementation language could be used for the integration of the PSs. An MIL provides formal grammar constructs required to specify and eventually integrate the reusable components. The more sophisticated MILS provide semantic specifica- tions and limit the components’ interface to only correct syntactic and semantic compositions . VHLL

(i) Abstraction: Mathematical methods are usually used for abstrac- tion. VHLL modules consist of a fixed part (module functional seman- tics) and a variable part (objects specifications) .

(ii) Selection: Selection and cus- tomization can take place at the two

levels of the VHLL and the VHLL language constructs. The highest level consists of selecting the most closely appropriate VHLL for a specific prob- lem and the second level is choosing a suitable language construct for the problem specification. The selection of an appropriate VHLL, applicable to the domain of a specific application, obviously has a strong effect on the development process.

(iii) Customization: The major type of customization consists of recursively substituting the slots in the parameterized VHLL language constructs with the constructs of the appropriate type.

(iv) Integration: The integration of language construct could take place through reasoning and verification. As stated by Cheng and Lock, “data flow and control flow of components are unified and localized to function composition, function arguments, and return values” to make the inte- gration process simpler.

TS (i) Abstraction: VHLLs are used for

the specification abstraction. Accord- ing to Krueger, “transformation abstractions are typically expressed as matcWsubstitution pattern.”

(ii) Selection: The appropriate transformations can be selected from a TS library using the expert system technology. A rule-based transforma- tion-selection system should provide rules such as the transformation goal,

strategies, and selection rationale. (iii) Customization: Transforma-

tion generally doesn’t involve modi- fication unless a complete match doesn’t exist in the library. In the case of a no-match, the customiza- tion is the same as the VHLL model customization. Transformation map- ping (from specification to code) is automatic and hidden from the user.

(iv) Integration: The integration of transformation is in the form of func- tional composition.

Sources R.M. Blazer, Transformation Imple-

mentation: An Example, IEEE Transac- tions on Software Engineering, SE-7( l), Jan. 1981.

T.T. Cheng and E.D. Lock, Use of Very High-Level Languages and Program Generation by Management Professionals, IEEE Transactions on Software Engineer- ing, SE-10(5):552-563, Sept. 1984.

T.E. Cheatham et al., Program Refiie- ment by Transformation, in Proceedings of the 5th International Conf. on Soft. Eng., pages 430-437, Washington, D.C., 1981, IEEE Computer Society Press.

J.A. Gougen, Parameterized Program- ming, Software Reusabiliq, Volume I o f Frontier Series, pages 153-225. ACM Press, 1989, T. Biggerstaff and A. Perlis (Eds).

C. W. Krueger, Models of Reuse in Software Engineering, CMU-CS-89-188, Technical report, Department of Comuter Science, Camegie Mellon University, Pitts- burgh, PA, Dec. 1989.

- M U & MHS

Journal of Systems and Sojhvare, 1995. R. Prieto Diaz, Software Reusabili-

ty, chapter Classification of Reusable ‘Modules, pages 99-123, Frontier Series, ACM Press, 1989. T. Biggerstaff and A. Perlis (Eds).

R. Prieto Diaz, Domain Analysis: An Introduction. Soft. Eng. Notes, ACM Press, 15(2):47-54, April 1990.

S.F. Fickas, Automating the Trans- formational Development of Software, lEEE Trans. on Software Engineering,

C. W. Krueger, Models of Reuse in Software Engineering, CMU-CS-89- 188, Technical report, Department of ‘Comuter Science, Carnegie Mellon University, Pitsburgh, PA, Dec. 1989.

M.D. McIlroy, Mass Produced Software Components, in Software

SE-1 1(11):1268-1277, NOV. 1985.

Engineering, Conference by the NATO Science Committee, pages 138-150, West Germany, Oct. 1968.

W.J. Tracz, Software Reuse Myths, A C M SIGSOFT, Soft. Eng. Notes, pages 17-21, Jan. 1988.

M.K. Zand, M.H. Samadzadeh, K.M. George, and H. Saiedian, ROPCO - An Interconnection Lan- guage for Reuse at the TemplateMod- ule Level, The Journal of Sytems and SofhJare, Oct. 1993.

About the authors Mansour K. Zand is an assistant pro-

fessor of Computer Science at the Department of Math and Computer Sci- ence of the University of Nebraska at Omaha. His research interests include Software Engineering (reuse, reverse

engineering, object-oriented program- ming, and software metrics). He received his M.S. and Ph.D. degrees in Computer Science from Oklahoma State University, in 1984 and 1991. Dr. Zand’s publications in refereed journals and conferences exceeds 30.

M. H. Samadzadeh is an Associate Professor of Computer Science at the Computer Science Department of Okla- homa State University. His research interests include Software Engineering (software metrics, reuse, user-interface design, human factors, and object-ori- ented design). He received his M.S. and Ph.D. degrees from the University of Southwestern Louisiana, in 1982 and 1987. Dr. Samadzadeh has over forty papers in various journals and confer- ences.

AUGUSTEEPTEMBER 1994 19