Critique: DPMED
Ramachandran, Shah, Langrana ^*

      It was interesting to read about an earlier use of object oriented software, especially in context of expert systems and design. I was confused at first by the terminology used since many different terms seemed to be used for the same concept. A quick key of the terms used in the paper and terms commonly used today can be found on the right.

      It might be my frame of reference, but the explicit mention of slots in units referring to the location class data members and methods are stored seemed odd. I don't recall any mention of explicit frame based storage of knowledge or objects in the paper. Using a system such as KEE seems to preclude the explanation of the underlying run time data storage paradigm used. While an overview of frame based data structures and their use in facilitating object oriented implementation, inheritance and the like seems beyond the scope of this paper, it would have been better than mentioning slots out of context.

      With all that said, I wish I had an electronic copy of the paper to search thoroughly to limit the probability of being very incorrect. Given the prior work this paper draws from, if that is any indication of the quality of this work, which isn't the general rule, one could reasonably assume I missed something.

      The use of the work done in VEXED was interesting, having just read about REDESIGN which VEXED is based on. I didn't quite understand why they described the approach taken in DPMED as

Design = Refinement - Constraint Propagation + Parameter Selection

My best guess is that the "-" is really a "+" but it didn't show on the copy of the paper I have... at least I hope that's it. The only reason I entertain the idea of "-" is that they could mean that Constraint Propagation reduces the search space of possible designs.

      While the domain of DPMED seems small, it is an extension in domain to the approach taken in VEXED. Circuit design systems of the time didn't take physical constraints into consideration. The addition of parameter selection to the design approach of VEXED seems an elegant solution for moving from working with abstract design models to those which convey physical structure. As is well known now, the physical layout of circuits today is crucial. It seems the reasoning in DPMED, while targeted for mechanical design, would be used when applied back to the problem of circuit design from which it grew.

      The use of hill-climbing is always a reason for caution. Getting stuck in a local maximum that under performs a substantial set of other maximum in the search space is never fun. DPMED uses fairly deterministic methods for setting initial values. It relies on the human expert / user to prevent this situation. The method by which DPMED changes values is also cause for concern, as the authors point out. Allowing only one value to change at a time and depending on heuristics to determine which parameter and the delta value to change by, limits the search space more than they might have intended for certain cases. While they came across none of these cases, it could cause great frustration to a frequent user.

      My most recent experience with a hill-climbing search is with neural networks using back propagation. If DPMED could incorporate its control strategy to influence back propagation it might help prevent some of these problems. DPMED's dependency tables could be used, in part, as initial weights for the network. Constraints could be used in the error calculation. I use the terms "influence" and "in part" to allow the use of random factors, limiting the possibility of starting the search in a place that increases the chance of sub-optimal local maximum again and again. While this doesn't guarantee a global optimal, it seems more reliable.