The Case for Frame-Based Software Engineering

Q1: Paul, your latest article in IEEE Software, The Case For Frame-Based Software Engineering, is generating buzz. What's its essential message?

A: The evidence, Stephen, is by now fairly conclusive: Object Orientation has been unable to deliver on its key promises, especially those concerning our industry's chronic issues: High quality systems are just too expensive, and take too long to build; they're too hard to maintain, and their components are too hard to reuse.

In a nutshell, OO suffers because classes mirror sets. To have any hope of building and evolving systems with tomorrow's complexity requirements, we must mirror software's infinite malleability. Sets just can't do this; my article explains why, and how frame technology, which is now available as open-source freeware, does fulfill OO's failed promises, a claim backed with plenty of hard evidence.

Q2: Hold on. What's wrong with set theory? It's a foundation for all of mathematics!

A: Yes, of course. Sets can model anything, at least in principle. But in practice, the problem boils down to this: two objects must belong to separate classes if their definitions differ in even the slightest detail. For mathematicians this is no problem - simply define as many classes as you need, even uncountably many! For object orienteers, however, this can become a show stopper:

complexity explodes when domain models evoke thousands of classes;
confusion arises when there are too many similar classes to choose from;
unique and subtle details are fragmented among common properties;
real-world fidelity suffers when objects model components that should be seamlessly integrated, are encapsulated - is your head an autonomous agent, dynamically linked to your torso??
Last but not least, multiple inheritance failed because it cannot tolerate incompatibilities among parent classes. Set intersection is the mathematical analog, and the intersection of incompatible sets is the empty set!

Q3: You're saying our ability to manage complex software gets overwhelmed by too many similar classes, causing too much confusion and additional complexity. So, how does frame technology come to the rescue?

A: The key is to make the notion of "similarity" work for us, not against us. Think about it: every thing is similar to something else, depending, of course, on what you mean by "similar." Two cars may be similar, but is a car similar to a truck? Maybe. Despite its tremendous potential to collapse complexity, similarity's subjective nature makes it hard to harness.

That's where frame technology comes in. It's a rather pure form of manufacturing that exploits similarities. Imagine assembling cars from just a few generic parts. That is, we would use just one standard bumper, one standard chassis, one standard fender, and so on. The assembly line would automatically replicate and adapt each generic part to custom fit each specific car. Too bad we can't actually morph physical parts into similar variants; if we could, inventories, costs, and complexities would collapse.

Well, software is soft, infinitely malleable. Frame technology can, and routinely does build, maintain and evolve custom systems from a few dozen frames, organized into nested subassemblies. Each frame is a component of a generic information model that is open to an infinity of possible variations. Frames can apply specific variations to the generic elements to produce not only files of compileable source, but any text, expressed in any language: Design models, legal documents, bills-of-materials..., anything that is somehow similar to a model in the frame library. Reductions in costs and schedules can be so dramatic that companies have been known to ask for externally audited confirmations.