Problem Solving Reuse: Bridging the gap between concrete problems and mathematical abstractions

Fatma Mili

School of Engineering
Oakland University, Rochester, MI48309-4401
Tel: (810) 370-2246
Fax: (810) 370-4625
Email: mili@oakland.edu

Abstract:

The reuse community has focused extensive research efforts on low level code reuse, and on high level domain analysis reuse. We propose here to add an intermediate level that we call problem solving reuse. Problem solving reuse is the collection, indexing, and use of all information pertaining to the applicability of mathematical models to classes of problems. A reuse base incorporating problem solving information is structured into three layers: 1. The functional layer describing the abstract, domain-independent, functional behavior of software components. 2. The problem solving layer describing applications of abstract models to various classes of problems. 3. The domain analysis layer describing the domain, the problems of interest, and their key attributes.

By dissociating components from the domains to which they are being applied, we make them applicable to a wider range of domains. By dissociating the problem descriptions from potential solutions, we open the door for a wider variety of solutions. Finally, by explicitly documenting how a model (function) applies to a problem, why it applies, and the limitations of its applicability, we promote a better understanding of the components, and provide a systematic way of assessing current and future uses of the same functionality.

Keywords: Domain Analysis and Engineering, Problem solving reuse, Reuse of Program Libraries, Assessment and Validation;

Workshop Goals: Networking; Cross-fertilization of ideas with other researchers

Working Groups: Domain Modeling Representation Strategies; Domain Processes and Engineering.

Background

My primary areas of research are formal systems of program synthesis, and intelligent decision support systems. Both of these areas have led me into reuse, although from different perspectives.

The work in formal systems led us to the identification of key features that unify seemingly diverse specifications, and make them implementable using the same programming constructs. The identification of these features allows us to formalize the concept of functional similarity between specifications. The mapping of these features to the programming constructs that they enable allows us to define analogical transformations to guide the modification of programs to meet similar specifications.

The work in decision support systems led us to be aware of the semantic gap that often exists between mathematical abstract models on the one hand, and the uses that are made of them in specific domains on the other hand. Adequate user support is critical to users to be able to select the proper model, and use it with full understanding of its capabilities and limitations. This support comes in the form of a customized documentation and explanation of the applicability of abstract models to specific domains, including an explanation of how the model applies, why it applies, and the extent to which it applies. This type of support proved to be invaluable not only for the use of the models, but also for their adaptation to new problems and new domains.

Position

Code reuse is the reuse of the encoding of some function, once the function has been defined and fully formalized. For example, using an existing implementation of Linear Programming rather than coding a new one is code reuse.

Domain analysis is the reuse of knowledge specific to the domain at hand. For example, using knowledge of key concepts, definitions, and relationships in the domain of resource management and planning in a factory setting is domain analysis reuse.

Problem solving reuse is the reuse of the modeling knowledge that allows us to model classes of problems using abstract mathematical functions. For example, using the knowledge that, generally, resource allocation problems are reasonably well modeled and solved using Linear Programming is problem solving reuse.

In this position paper, we argue for the inclusion of problem solving knowledge as an important asset to be documented and reused. Furthermore, we contend that information pertaining to problem solving is better dissociated from functionality information, and from the domain analysis information, as is shown in Figure 1.

  figure35
Figure 1:   Functions model Problems

In order to ensure the domain independence of software components, they are indexed by an abstract description of their functionality. This description is limited to the inherent functional characteristics of the components, and independent of the uses made of components.

In order to ensure the domain's solution independence, its documentation describes the problems and phenomena of interest independently of any specific approach used to solve them and model them.

The relationship between problems and functions lies in the set of possible applications of functions to problems. Each such application is documented in terms of its underlying assumptions, rationale, precision, limitations, and so forth. This explicit description of modeling information provides a systematic mechanism for assessing the fit of a model to a specific problem instance, and promotes a better understanding of the capabilities and limitations of the application.

Example

To illustrate our position, we show the example of using Linear Programming to model and solve the resource allocation problem.
The example is given here in a structured yet informal manner. Our goal is to illustrate the nature of the information that belongs in each layer. We focus, in particular, on the problem solving layer.
Functional Description of LP

tabular61


Description of the Resource Allocation Problem

tabular92


Application of LP to the Resource Allocation Problem:

tabular106


Benefits from Explicit Documentation of Problem Solving

As can be seen from the example, the information provided allows users to assess whether or not a model is at all possible for some problem at hand, and gives them some indication on the ``quality'' of the solution for the instance at hand.

Bridging the gap between the mathematical model (viz Linear Programming) and the class of problems that it was found to model, allows software developers to search for reusable components at a higher level of abstraction. Rather than spending effort rediscovering that a resource allocation problem can be modeled by Linear Programming, then specifically searching for an implementation of LP, software developers can input the query ``resource allocation'' (or a more general, or more specific class), and retrieve a set of potential models for resource allocation problems.

The detailed information in the problem solving template allows to discriminate between features that play a role in solving the problem and features that do not. In the above example, the nature of the activities for instance, is not relevant; the continuity of the levels of activities on the other hand is critical. This distinction is useful in two ways: 1. Because the nature of the activity is not relevant, we can change it from problem instance to problem instance without impacting the quality of the model. On the other hand, we must be ware if we decide to switch from continuous to discrete activity levels, since the applicability rests partly on the assumption that the levels are continuous. 2. Because the nature of the activity is not relevant, it does not need to be documented as part of the domain analysis. On the other hand, all features of the domain that are relevant to the applicability of some model must be documented. In other words, this identification of all those features that play a role in the applicability provides us with a gauge for checking the relative completeness of the domain analysis description.

Comparison

We see the main two motivations and contributions of the explicit inclusion of problem solving knowledge as:

Support for understanding what a software component can and cannot do for a specific problem. In this respect, our approach shares the same motivation as the team of Ohio State University and shares its concerns with respect to providing users with high level mental models of software components [1, 2], and with explaining software at different levels of abstraction [3, 4].
Support for assessing the validity of an application. The validity of a model to solve a problem is quite similar to the concept of the correctness of an implementation with respect to a specification. Yet, it differs in the sense that correctness is a binary criterion, whereas validity is a fuzzier criterion. A model is valid to a certain extent. The documentation of the application of a model to a problem specifies the strict conditions as well as the more lenient assessment clauses. Again, this shares common concerns with researchers working on certifying software components[5], although here we are assessing uses of software components.

References

1
S. Edwards, ``Good mental models are necessary for understandable software,'' in WISR7, 1995.

2
S. Edwards, A Formal Model of Software Subsystems. PhD thesis, Ohio State University, 1995.

3
D. Allemang, Understanding Programs as Devices. PhD thesis, Ohio State University, 1990.

4
D. Allemang and B. Liver, ``Functional representation for reusable components,'' in WISR 7, 1995.

5
B. W. Weide, W. Heym, and W. Ogden, ``Procedure calls and local certifiability of component correctness,'' in Proceedings of the sixth annual workshop on software reuse, 1993.

Biography

Fatma Mili is Associate Professor of Computer Science at Oakland University. She is involved in research in the areas of Software Engineering, theoretical aspects of Computer Science; database systems and decision support systems. She is the co-author of two books in Software Specification and Software Design using formal methods, and has authored and co-authored a number of publications, notably a survey in Software Reuse. She received a Doctorate degree in Computer Science from the Université Pierre et Marie Curie, France in 1984.