James D. Mooney
Dept. of Statistics and Computer Science
West Virginia University
PO BOX 6330
MORGANTOWN WV 26506-6330
jdm@cs.wvu.edu
This paper reviews and compares current issues in reuse research and portability research. The analysis of portability is based on the author's experience and on current work at West Virginia University. Although the dominant problems for the two research domains are distinct, the goal is to identify some common areas where both domains may benefit from continuing research.
Several common areas can be identified. These include classification, specification and measurement, validation and verification, software process issues, and management issues. There is a need, for example, to classify applications by their portability attributes; the goal differs from that of reusable component classification, but similar mechanisms could be used. Current relevant work at WVU in this area and several others is briefly summarized.
The organizational problem of integrating portability into the software development process is briefly considered. Benefits may be anticipated from integration of both portability and reuse. It appears, however, that integration of portability may be more easily accomplished, yet harder to justify to management.
Portability is increasingly identified as a desirable attribute for software systems; most software which is intended for broad utility will face the need to be ported to new environments over the course of its lifetime (see, e.g., [Lewis & Oman 90], [Sommerville 92]). Today portability is often cited as a goal even for special software categories which have formerly considered it infeasible or unnecessary. Two examples are real-time software and parallel software.
Despite the acknowledged need for better portability, published research on portability issues has been sparse. A variety of porting experiences have been reported, leading to many types of anecdotal advice (e.g. [Tanenbaum et al 78], [LeCarme et al 89]). A few limited areas, such as parallel software conforming to certain models, have been studied more extensively (e.g. [Skillicorn 90], [Alverson & Notkin 93]). There is, however, no systematic framework to guide developers in maximizing portability in the general software development process.
The Portability Research Group at West Virginia University is exploring a variety of issues related to portability. Examples include classification of applications for portability; specifying portability requirements; enhancing portability in the design process; measuring portability and portability costs; etc. Some members have also done work in the reuse area [Sitaraman 91, Eichmann 92]. This paper seeks to explore the relationship between porting issues and reuse issues, and consider ways in which research that is focused on one of these domains may sometimes yield benefits for both.
This is not a report of reuse or porting experience, although the ideas presented are grounded in past experience. Neither is it a presentation of verified research results. Instead, the goal is to explore the commonality between two related research domains that are not often examined together, in the hope of extending the benefits of existing work, and suggesting fruitful new work, in both domains.
The paper is organized as follows: Section 2 summarizes some basic portability concepts (the audience is assumed to be more familiar with reuse concepts). Section 3 then provides a brief comparison of key issues in each area. Section 4 considers ways in which portability and reuse might be joined through common models that are presently applied to objects or processes in each area. Section 5 discusses several areas in which the two domains face common problems that may benefit from similar research. Section 6 briefly discusses organizational issues. The final section summarizes our main conclusions.
Porting is the act of producing an executable version of a software unit or system in a new environment, based on an existing version. Current discussions focus mainly on application portability. The term software unit will be used here to indicate an application program, a system program, or a component of a program. A software system is a collection of software units. The term environment refers to the complete range of elements in an installation that interact with the ported software. This typically includes a processor and operating system; it may also involve I/O devices, libraries, networks, or a larger human or physical system. Many authors use the term platform with a similar (but possibly more restrictive) meaning.
The term portability refers to the ability of a software unit to be ported (to a given environment). A program is portable if and to the degree that the cost of porting is less than the cost of redevelopment. A software unit would be perfectly portable if it could be ported at zero cost; this is never possible in practice. Instead, a software unit may be characterized by its degree of portability, which is a function of the porting and development costs, with respect to a specific target environment.
The principal types of portability usually considered are binary portability (porting the executable form) and source portability (porting the source language representation). Binary portability is clearly desirable, but is possible only across strongly similar environments. Source portability assumes availability of source code, but provides opportunities to adapt a software unit to a wide range of environments. Most portability research assumes that the goal is source portability.
The porting process has two principal components which may be called transportation and adaptation. Transportation is physical movement; this may not be trivial since compatible media must be used and various types of representation conversion may be required. Adaptation is any modification that must be performed on the original version; we take this to mean both mechanical translation such as by language processors, and manual modification by humans.
Costs may be associated with the use of a portability-based strategy for software development; these could take the form of increased development costs and of possible reductions in some quality measures of the actual software (e.g., performance, or conformance to system-specific user-interface conventions). The corresponding benefits take the form of reduced costs to produce and maintain future implementations, as well as possible quality improvements in factors such as reliability.
2. Given a software unit to be developed, how can its portability be enhanced in the design and implementation process? These issues are not ones that have been emphasized in traditional reuse research. Instead, most reuse studies have concentrated on developing a framework for the ongoing reuse of software components (or comparable artifacts, such as algorithms) in new applications. This viewpoint leads especially to the following types of questions: 1. How can a collection of components be designed which will be effectively reusable over a given class of applications?
2. How can a large and evolving collection of components be maintained and organized so that suitable ones can be easily found when needed? Perhaps the most striking difference between these two orientations is based on the freedom to specify the software artifact(s) to be reused. In the portability viewpoint, the requirements specification (at least) is predetermined, even if it does not exist in concrete form. In the reuse viewpoint, developing specifications is a major part of the problem. Moreover, in the portability case there are no more than a few artifacts, all clearly identified; while in the reuse case locating suitable artifacts is a key problem.
Because the components for a reuse process are developed from initial concept with reuse in mind (or selected, in the case of code scavenging), it is likely that if their abstract specifications are suitable, actual reuse (i.e., adaptation and integration in the new application) will be straightforward. This is an area where porting encounters significant problems.
These major differences of orientation suggest that portability research and reuse research may have little in common. The thesis of this paper is that, despite the differences, there are areas in which work in one area can benefit the other, and there are some untapped opportunities for fruitful research that addresses both areas together.
Krueger [92] has analyzed a variety of strategies for software use in terms of four activities: Abstraction, Selection, Specialization, and Integration. It is illuminating to compare porting and reuse in terms of these activities. Abstraction concerns the manner in which the reusable artifacts are described or represented. In the reuse strategies considered by Krueger this ranges from concrete source code to abstract specifications of various types. A program unit to be ported is almost always concrete. It would be possible, however, to envision generating implementations for various environments directly from a higher-level representation.
Selection refers to the process of choosing artifacts to be reused. This is a major issue in most types of reuse. In porting there is no selection; the artifact is determined at the start.
Specialization refers to adapting an artifact to suit the requirements of a specific use. In many reuse situations it is expected that the artifacts be parameterized to allow developers to make choices both in functionality and in implementation characteristics such as data representation and performance tradeoffs. Specialization is then limited to selecting the appropriate parameters.
In the case of porting, specialization is usually the heart of the problem. Well-designed portable software may also represent some environment dependencies as parameters which can be easily changed. Further, modular design, which is expected of applications (though not most components) can be viewed as a type of paramaterization; specialization is then achieved by choosing an appropriate set of modules. However, in many cases some degree of manual modification is required. Finally, a program ported at the source level must be further specialized by processing with a language processor appropriate for the target environment.
Integration is the process of combining the (possibly modified) artifacts to produce the resulting software product. In traditional reuse this activity is typically straightforward, since the artifacts were both conceived and constructed with integration in mind. In porting, there is typically only one (or a few) separate artifacts. Again, if specialization has been accomplished, integration presents no difficulty.
An important aspect not shown directly in this figure is the evolution of interfaces over time. Many interfaces pass through a series of representations, such as source code, object code, and executable machine instructions. Commonality may be gained (or lost) with each representation.
Reusable components may be represented in this model as segments of the application; their individual portability issues are determined by the interfaces they contact. This view is illustrated in Figure 2. The figure suggests that component A is sensitive to the operating system interface which deals with memory, while component B has no system dependencies. Such a model could aid in designing components with well-defined portability characteristics.
Figure 1 -- Interface Model for Application Portability
Figure 2 -- Interface Model with Reusable Components
There appear to be some important differences in the management issues that may arise when incorporating each of these two techniques in a software development environment: 1. Incorporating portability has substantially less impact than incorporating reuse on the existing software process and organizational structure.
2. The benefits of portable development are anticipated in the future; the benefits of "design-by-reuse" are immediate and concrete. These observations are further discussed in Section 6.
Classification is also an issue for portability. Here, the emphasis is on classifying complete applications according to their environmental interfaces and requirements. This classification can assist in matching applications to environments, and in reusing experience gained from porting other applications with a similar classification.
One proposed classification scheme being studied at West Virginia University uses four major categories (or facets): mechanism, resources, modes, and guarantees. Example classes from each category are given in Table 1. For example, a spreadsheet application might require a display, keyboard and pointing device with certain characteristics; a minimum memory capacity; multitasking for background calculations; interactive mode; a guaranteed floating point accuracy; etc. This classification is intended both to expose inherent limits on portability and to suggest portability techniques.
Although the emphasis of these classification approaches is different, it is reasonable to envision a multifaceted classification which might meet the needs of both areas. Moreover, software units with a similar classification from the reuse perspective may also be related in terms of their portability characteristics. Further research on this problem may benefit both domains.
CATEGORY EXAMPLES
Mechanisms Multitasking; virtual memory; vector processing
Resources PostScript Printer; pointing device; 5 MB storage
space; color graphic display
Modes Batch; Interactive; Real-Time
Guarantees Timing accurate to 3 us; Less than 1 hour downtime
per year
Table 1 -- Portability Classification ExamplePortability issues arise after the functional requirements of a software unit have been identified. In this sense the specifications are already determined. However, when an application is to be developed (or redeveloped), the role of portability considerations in the development process must be determined by the portability requirements of the project. These requirements form a part of the overall requirements specification, and should answer questions such as "how much" portability is required, to "what kinds of environments", and "what costs" can be accepted to achieve it.
Both problems raise the need for new specification techniques focused on non-functional requirements of a software unit. Most specification methods, especially formal methods, concentrate on functional requirements [Roman 85]. Research in specification methods for non-functional requirements can be of value to both areas.
Measurement techniques are also needed for the cost-effectiveness of portability-based approach to software development. These measurements must take into account both the increased costs of initial development and the cost-savings later realized through porting. It is also useful to quantify the intrinsic portability of a software unit. Some of these issues have been examined by the author [Mooney 93].
The reuse objective requires that entities be selected when possible from an existing collection of reusable entities, or perhaps designed so they may be added to such a collection. The portability objective requires that system dependencies be recognized and isolated so they may be easily changed. These objectives are consistent: An application partitioned for portability will be one in which most modules are free of system dependencies, except those whose special purpose is system adaptation. This separation of issues is clearly desired in a collection of reusable components.
Although this type of adaptation arises in the context of porting, it may be viewed as designing a new application, in which substantial parts of a previous one are reused. The adaptation will be most easily accomplished if the existing program has a modular design as described above, such that both system dependencies and culture dependencies are abstracted and isolated from the essence of the application and can be readily changed.
Such an organization would include core components that could be effectively reused in the adapted version. Moreover, components that embody specific cultural dependencies may be reusable in other applications within the same culture. With this view, creating an application modularized for portability may lead to creation of a useful set of reusable components, or vice versa.
Testing and verification activities must be repeated for each new application or implementation. However, it may be possible to demonstrate that some types of correctness and other properties are preserved during porting or reuse. This could lead to a reduction in effort in revalidating the new application or implementation.
At WVU, an investigation of some of these issues is in the planning stages. Results may have benefits for both porting and reuse.
In contrast, portability may be adopted as an objective by individual design projects, even without an overall organizational commitment. The effort expended for the sake of portability may be limited or comprehensive; even limited effort offers some potential for benefit.
The major costs of reuse begin with the organizational commitment and infrastructure. Ongoing costs are generated by the development and maintenance of artifact collections. The benefits of this effort are reaped directly by the application development projects. These benefits take the form of reduced time and effort for the development process.
The cost-benefit situation for portability is quite different. Little organizational investment is needed. However, incorporating portability into specific applications raises costs with no immediate benefits. The benefits come later, when (and if) the program is actually ported.
Because of these differences, it is likely that portability will be easier and less costly to incorporate in the software process, yet harder to justify to management!
The two domains have essential differences. However, some common problems were identified, along with some related areas where research may yield benefits to both domains. The principal observations are: 1. Modularizing an application in a suitable way to enhance portability may lead in a natural way to identification of reusable components. This may be increasingly true where cultural adaptation is required. Thus portability and reuse can have a mutually beneficial effect as elements of the software development process.
2. There are several active areas where the two domains may benefit from common research, including classification, specification, and measurement.
3. A fruitful area for future attention is the development of techniques for validation which can be preserved during porting and reuse.
4. Portability may be incorporated in a single software development project, but its benefits are more future-oriented and uncertain than those of reuse. Therefore, portability may be easier to integrate into the software process, but harder to justify to management. This study has enabled me and our research group to become more aware of reuse issues and of benefits to be gained from reuse research. I hope it may also offer the reuse community some added awareness of portability issues, leading to mutual benefit. I am grateful to Murali Sitaraman for his suggestions on improving this paper; to all the members of our group for providing the foundations, and to West Virginia University, the National Science Foundation, and Japan's TRON association for supporting portions of this study.
Abdel-Hamid, T.K., Modeling The Dynamics of Software Reuse, Proc. 6th Ann. Workshop on Software Reuse, 1993, pp. 1-5.
[Alverson & Notkin 93]
Alverson, G.A., and Notkin, D., Program Structuring for Effective Parallel Portability, IEEE Trans. on Parallel and Distrib. Sys., Vol. 4, No. 9, Sep. 1993, pp. 1041-1059.
[Edwards 90]
Edwards, S., The 3C Model of Reusable Software Components, Proc. 3rd Ann. Workshop: Methods and Tools for Reuse, Syracuse, NY, 1990, pp. ???-???.
[Eichmann 92]
Eichmann, D., Selecting Reusable Components Using Algebraic Specifications, in AMAST 91, Workshops in Computing Series, Springer-Verlag, London, 1992, pp. ???-???
[Krueger 92]
Krueger, C.W., Software Reuse, ACM Computing Surveys, Vol. 24, No. 2, Jun. 1992, pp. 131-184.
[Lecarme et al 89]
Lecarme, O., Pellissier Gart, M., and Gart, M., Software Portability with Microcomputer Issues, Expanded Edition, McGraw-Hill, New York, 1989.
[Lewis & Oman 90]
Lewis, T.G., and Oman, P., The Challenge of Software Development, IEEE Software, Vol. 7, No. 6, Nov. 1990, pp. 9-12.
[Mooney 90]
Mooney, J., Strategies for Supporting Application Portability, IEEE Computer, Vol. 23, No. 11, Nov. 1990, pp. 59-70.
[Mooney 93]
Mooney, J., Issues in the Specification and Measurement of Software Portability. Technical Report TR 93-6, Dept. of Statistics and Comp. Sci., West Virginia Univ., Morgantown WV, 1993. Presented as a poster at the Internat. Conf. on Softw. Eng., Baltimore, Md., May 1993.
[Poulin & Caruso 93]
Poulin, J.S., and Caruso, J.M., Determining the Value of a Corporate Reuse Program, Proc. 1st Intl. Software Metrics Symposium, IEEE Press, 1993, pp. 16-27.
[Prieto-Díaz 91]
Prieto-Díaz, R., Making Software Reuse Work: An Implementation Model, ACM SIGSOFT Software Engr. Notes, Vol. 16, No. 3, Jul 1991, pp. 61-68.
[Prieto-Díaz 93]
Prieto-Díaz, R., Status Report: Software Reusability, IEEE Software, Vol. 10, No. 3, May 1993, pp. 61-66.
[Prieto-Díaz & Freeman 87]
Prieto-Díaz, R., and Freeman, P., Classifying Software for Reusability, IEEE Software, Vol. 4, No. 1, Jan. 1987, pp. 6-16.
[Roman 85]
Roman, G.C., A Taxonomy of Current Issues in Requirements Engineering, IEEE Computer, Vol. 18, No. 4, Apr. 1985, pp. 14-23.
[Sitaraman 92]
Sitaraman, M., Towards a Modular Approach for Real-Time Specification and Verification of Reusable Software Components, Proc. 9th IEEE Workshop on Real-Time Operating Systems and Software, May 1992.
[Skillicorn 90]
Skillicorn, D., Architecture-Independent Parallel Computation. IEEE Computer, Vol. 23, No. 12, Dec. 1990, pp. 38-50.
[Sommerville 92]
Sommerville, I. Software Engineering (4th ed), Addison-Wesley, Reading, Mass., 1992.
[Tracz & Edwards 89]
Tracz, W.J., and Edwards, S., Implementation Working Group Report, Reuse in Practice Workshop, Pittsburgh, PA, 1989.