Software framework

A software framework is a partially complete, or semi-finished software (sub-)system that is intended to be instantiated. It defines the architecture for a family of (sub-)systems and provides the basic building blocks to create them. It also defines the places where adaptations for specific functionality should be made. In an object-oriented environment, a framework consists of abstract and concrete classes. Instantiation of such a framework consists of composing and subclassing the existing classes (Buschmann 1996).

For example, a software framework can be geared toward building graphical editors for different domains like artistic drawing, music composition, and mechanical CAD (Vlissides and Linton 1990; Johnson 1992). Another software framework can help build compilers for different programming languages and target machines (Johnson, McConnell et al. 1992). Yet another might help build financial modeling applications (Birrer and Eggenschwiler 1993) or decision support systems (Gachet 2003).

In short, a software framework is a set of cooperating classes that make up a reusable design for a specific class of software (Johnson and Foote 1988; Deutsch 1989). According to Pree (1994), such a framework consists of frozen spots and hot spots. On the one hand, frozen spots define the overall architecture of a software system, that is to say its basic components and the relationships between them. These remain unchanged (frozen) in any instantiation of the application framework. On the other hand, hot spots represent those parts of the software framework that are specific to individual software systems. Hot spots are designed to be generic. In other words, they can be adapted to the needs of the application under development. When developing a concrete software system with a software framework, the hot spots are specialized according to the specific needs and requirements of the system. Software frameworks rely on the Hollywood Principle: "Don’t call us, we’ll call you." (Larman 2002). This means that the user-defined classes (for example, new subclasses), receive messages from the predefined framework classes. These are usually handled by implementing superclass abstract methods.

See also

• Application framework

References

• Birrer, A. and T. Eggenschwiler (1993). Frameworks in the financial engineering domain: an experience report. in (eds), Springer-Verlag, proceedings of the European conference on object-oriented programming, Kaiserslautern, Germany: 21-35.
• Buschmann, F. (1996). Pattern-oriented software architecture : a system of patterns. Chichester ; New York, Wiley.
• Deutsch, P. L. (1989). Design reuse and frameworks in the Smalltalk-80 system. Software reusability, volume II: applications and experience. T. J. Biggerstaff and A. J. Perlis. Reading, MA, Addison-Wesley: 57-71.
• Gachet, A. (2003) "Software Frameworks for Developing Decision Support Systems - A New Component in the Classification of DSS Development Tools", Journal of Decision Systems 12(3/4): 271-281.
• Johnson, R. E. (1992). Documenting frameworks using patterns. in (eds), ACM Press, proceedings of the Object-oriented programming systems, languages, and applications, Vancouver, British Columbia, Canada: 63-76.
• Johnson, R. E. and B. Foote (1988). “Designing reusable classes.” Journal of object-oriented programming 1(2): 22-35.
• Johnson, R. E., C. McConnell and M. J. Lake (1992). The RTL system: a framework for code optimization. in R. Giegerich and S. L. Graham (eds), Springer-Verlag, proceedings of the International workshop on code generation, Dagstuhl, Germany: 255-274.
• Larman, C. (2002). Applying UML and patterns : an introduction to object-oriented analysis and design and the unified process. Upper Saddle River, NJ, Prentice Hall PTR.
• Pree, W. (1994). Meta patterns - a means for capturing the essentials of reusable object-oriented design. in M. Tokoro and R. Pareschi (eds), Springer-Verlag, proceedings of the ECOOP, Bologna, Italy: 150-162.
• Vlissides, J. M. and M. A. Linton (1990). “Unidraw: a framework for building domain-specific graphical editors.” ACM Transactions of Information Systems 8(3): 237-268.