Information Systems Frontiers 4:4, 393–407, 2002 C  2002 Kluwer Academic Publishers. Manufactured in The Netherlands. Towards Specifying Constraints for Object-Oriented Frameworks Daqing Hou ∗ and H. James Hoover Department of Computing Science, 221 Athabasca Hall, University of Alberta, Edmonton, Alberta, Canada T6G 2E8 E-mail: daqing@cs.ualberta.ca E-mail: hoover@cs.ualberta.ca Abstract. Object-oriented frameworks are often hard to learn and use (J. Bosch et al., In: ACM Computing Survey’s Sym- posia on Object Oriented Application Frameworks, 1998; M. Fayad and D.C. Schmidt, Communication of the ACM, Special Is- sue on Object-Oriented Application Frameworks 1997;40(10)). As a result, software cost rises and quality suffers. Thus the capability to automatically detect errors occurring at the bound- ary between frameworks and applications is considered cru- cial to mitigate the problem. This paper introduces the no- tion of framework constraints and a specification language, FCL (Framework Constraints Language), to formally specify them. Framework constraints are rules that frameworks impose on the code of framework-based applications. The semantics of FCL is primarily based on first order predicate logic and set the- ory though the evolving syntax is designed to resemble that of programming languages as much as possible. We take examples from the MFC (Microsoft Foundation Classes) framework (G. Shepherd and S. Wingo, MFC Internals: Inside the Microsoft Foundation Classes Architecture. Reading, MA: Addison Wesley, 1996) demonstrating both the nature of framework constraints and the semantics of FCL. Essentially, framework constraints can be regarded as framework-specific typing rules conveyed by the specification language FCL, and thus can be enforced by techniques analogous to those of conventional type checking. Key Words. object-oriented frameworks, framework constraints, FCL, FCL checker 1. Introduction An object-oriented framework is a reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances inter- act. It is the skeleton of an application or subsystem that can be customized by an application developer (Johnson, 1997). The essence of a framework is the architecture that it provides (Biggerstaff and Perlis, 1989; Johnson, 1997). Usually, designers of application frameworks have some intention as to how their frame- works should be used. Their design rationales imply a set of constraints that framework users have to follow in order to use the frameworks correctly. We call these constraints framework constraints. For instance (Stacy et al., 1992), when subclassing, framework users may be required to – implement methods deferred to subclasses by parent classes, – ensure that overrides do not violate parent classes’ assumptions about them, – respect protocols supported by parent classes, and – initiate notifying actions when the state of a subclass changes. When reusing and composing objects, framework users may be required to – create objects with correct parameters, – compose them correctly and only with compatible objects, – respect sequencing assumptions on operations that may be performed on the object, and – provide appropriate responses to calls initiated by the object. As a simple example of framework constraints, con- sider the class diagram of Fig. 1, which depicts part of the structure of a banking system. The classes Account and ATM belong to the framework whereas BillingATM is created by an application. ∗ To whom correspondence should be addressed. 393