Frameworks Home Page

Welcome to the frameworks home page. It gives Ralph Johnson's view of frameworks and points to some related resources on the net.

Contents


What are frameworks/

A framework is a reusable design expressed as a set of abstract classes and the way their instances collaborate. It is a reusable design for all or part of a software system; a user interface framework only provides a design for the user interface of a system, while MacApp, the "Macintosh Application Framework" provides a design for the entire application. By definition, a framework is an object-oriented design. It doesn't have to be implemented in an object-oriented language, though it usually is. Large-scale reuse of object-oriented libraries requires frameworks. The framework provides a context for the components in the library to be reused.


Pointers to other pages

Another frameworks home page.

Joe Yoder's page

Patterns

Taligent has a lot of info on OOT and frameworks. In particular, the papers Building Object-Oriented Frameworks and Object-Oriented Frameworks are pretty well done.

A framework bibliography

A hypermedia framework.

Conduits+, a framework for network protocol handlers.

FinancialObjects


Ralph's frameworks papers

Here are some papers about frameworks.

Mailing Lists

There is only one mailing list about frameworks that I know about, and I don't think it is active. It is FWList, and you can read all the back issues.


Ralph's Ruminations

Comment from someone else:

I have been thinking about ways to reduce the semantic gap between a business model, CASE tools that express it in a formal way, and programming tools that provide a means of executing the model. I hope to come up with a strategy that allows CASE and programming languages to merge and simply provide different views of the same underlying model of computing. I think with some extensions to the Smalltalk meta-data to support formal expression of behavior it may be possible to have text and graphic views of Smalltalk objects and their interactions. This will allow a programmer to develop a business model using which ever view is most appropriate to the task at hand.

I have strong opinions about this. One is that conventional CASE tools are the wrong approach. They try to be general purpose, one-size fits all notations. You wouldn't want to use OMT for designing logic circuits or workflows. Traditional CASE tools are not what you use for making GUIs; you use very specialized tools like the VisualWorks canvas. Providing graphic views of Smalltalk objects will be only an incremental improvement. What you want are carefully crafted graphic views of new kinds of objects, which just happen to be implemented in Smalltalk. These languages will be domain specific. They will usually be developed as a by-product of making a black-box framework. A good example is Accounts which is a framework for Business Transaction Processing. My guess is that there would be 6-15 other frameworks in a complete tool-set for building business information systems.

Conventional CASE tools are still useful, since you can use them to design the specialized CASE tools. But you will also need something like a framework for graphical editors (i.e. HotDraw) so that it is easy to invent new tools for new domains.

Reply:

Sounds a lot like component based development using visual programming tools.

Yes, but most people who talk about that assume a one-size-fits-all visual language like VisualAge. I don't believe that is the solution. Every domain potentially needs a different notation, though in fact there are families of notations so a single notation can often get reused.

I think of frameworks as reusable problem domain models.

Yes, which is why I could have said "every framework potentially needs a different notation". I envision a framework as underlying each visual language.

One example is Accounts. Another example is a framework for implementing run-time systems in a compiler that Alan Durham is building. He eventually developed a visual language that lets you specify a run-time system by drawing pictures of the run-time data structures. I've been working on a framework for network protocol handlers wth some folks in Switzerland. It started out pretty white-box, but as it became more of a black-box frmework it has gotten to the point where we could describe applications graphically. We haven't built a graphical front-end yet, though. I've seen other systems that were like this.


Page managed and maintained by Ralph Johnson Last update September 15, 1997