Choosing an object-oriented domain framework

Object-oriented frameworks [2] enable developers to rapidly produce new applications — provided that the framework is actually suited to the requirements of the new application. Often, previous experience with the framework is used to make this decision, but when application developers are unfamiliar with a new framework they have no experience for deciding whether or not to use it. They may not discover that a framework lacks support for key requirements of an application until well into the development cycle, resulting in substantial redevelopment or discarding of the project altogether. They require a basis for making the initial decision of whether or not to invest time in understanding and using the framework. Our approach is most successful for domain specific object-oriented frameworks. Due to their size and overall generality, this approach may not be as applicable to enterprise frameworks. We have been working with existing frameworks such as HotDraw [6], as well as developing new frameworks in the engineering domain (EAF). Our experience, common to most framework users, is that building up the level of expertise necessary to know in detail what applications a framework can be used for is a time consuming process due to the abstract nature and complexity of most frameworks. How can this expertise be captured and be made available to new users of the framework to help them decide whether or not to use the framework? In other words, how do we describe the applicable domain of the framework? A new application can fall into one of three areas. It can be (1) clearly outside