Co-leaders

* Ian Chai, University of Illinois at Urbana-Champaign
* Bobby Wolf, Knowledge Systems Corporation

Description

When software development organizations decide to use object-oriented programming, one of the major motivations is usually to increase the productivity of their development teams. They see reuse as the key to increased productivity, and reusable frameworks as a reuse silver bullet. They soon discover that frameworks have many problems, primarily that they're difficult to develop and hard to reuse. This workshop won't help make framework development any easier, but it will discuss how to make them easier to reuse.

The challenge of reusing a framework is that the people who need to reuse the framework often don't know how. They don't understand how the framework works and they don't understand how to use it. The people who wrote the framework know all of this, so the challenge is for the frameworks builders to convey this knowledge to the frameworks users. The focus of this workshop is to help convey that knowledge.

Several people have proposed formal descriptions of frameworks, for example [Helm 90], but formal descriptions are not very effective, so we propose using patterns instead.

Ralph Johnson has demonstrated the feasibility of documenting the HotDraw framework using patterns [Johnson 92]. He and Kent Beck argued that one could use design patterns to derive architectures, once again using the HotDraw framework as an example [Beck 94a]. Beck has argued the productivity gains possible by having abstractors use patterns to document their frameworks so that elaborators may learn those frameworks more efficiently [Beck 94b]. The Peppery Patterns paper from PLoP '97 [Chai 97] also illustrates this with the Habanero framework for multi-user Java applets.

Framework documentation should describe three things:

1. the purpose of the framework
2. how to use the framework
3. the detailed design of the framework [Johnson 92]

We believe there are two major kinds of framework documentation: application programmer documentation and framework internal documentation. Application programmer documentation should encompass (1) and (2) above, while framework internal documentation should encompass (3), but also may encompass some of (1).

REFERENCES

[Beck 94a] Kent Beck and Ralph Johnson, Patterns Generate Architectures, Proceedings of the 8th European Conference, ECOOP '94, Lecture Notes in Computer Science, Volume 821. Postscript version available at ftp://st.cs.uiuc.edu/pub/papers/patterns/patterns-generate-archs.ps

[Beck 94b] Kent Beck, Patterns, Dr. Dobbs, February 1994.

[Chai 97] Peppery Patterns: How to turn Java applets into Habanero hablets, Ian Chai, Pattern Languages of Programming (PLoP '97), Montecello, Illinois, 2-5 September, 1997. [Washington University Tech. Report #wucs-97-34]

[Helm 90] Richard Helm, Ian Holland, Dipayan Gangopadhyay, Contracts: Specifying Behavioral Compositions in Object-Oriented Systems, OOPSLA '90 Proceedings, ACM Press, 1990.

[Johnson 92] Ralph Johnson, Documenting Frameworks Using Patterns, OOPSLA '92 Proceedings, ACM Press, 1992. Postscript version available at ftp://st.cs.uiuc.edu/pub/papers/HotDraw/documenting-frameworks.ps