Title: Building Frameworks and Applications Simultanously Author: Andreas Rüping e-mail: rueping@acm.org Address: sd&m software design & management AG Thomas-Dehler-Straße 27 D-81737 München, Germany Phone: ++49-89-63812-408 Abstract: The decision to build a framework is often made after having built a number of similar applications successfully. Maybe a company has been selling similar systems to various customers for many years; building a framework can then reduce the effort and the time needed to build more applications. A framework evolves: ideally, the evolution process starts with the experiences gained with previous applications; the framework starts as a white-box framework and matures into a black-box framework as it is being used. Still, this isn’t always possible. Imagine the following scenario: You’re starting a large project with several teams building various applications. One team has to provide all kinds of shared functionality — modules that many applications will need, but which should be developed only once. Sometimes such modules are rather simple: a module for computing time and date, for instance. But sometimes they aren’t so simple: many applications may need database access, but a general module for database access isn’t trivial. Moreover, the more complicated shared modules often vary slightly from application to application. To this end, the idea of building a framework for the functionality shared across applications springs to mind. This framework should offer functionality that many of the modules can use which will be built in the course of the project. However, you cannot wait with the design of such a framework until you have built a number of applications — the framework would be available too late to be used in the project. The framework must be built in parallel to the applications that are going to use it. Designing a framework in such a context is hard. You cannot draw on the experiences gained with previous applications. If you want to be successful, you have to take care to keep the framework simple, and you have to collaborate closely with the teams who will use the framework. This paper presents a pattern language that helps the framework developer in such a situation. Most of the patterns are specific to building a framework and its applications simultanously. Some patterns are variations of patterns that apply to framework development in general; however, their focus is shifted towards the special context.