1 / 35

Introduction to Frameworks

Introduction to Frameworks. Johan Larsson Computing Science Department, IT Uppsala University, Sweden Seminar for the Patterns and Frameworks D-level course  jola@csd.uu.se  http://www.csd.uu.se/~jola/. May 12, 1999. © J. Larsson. All rights reserved.

nolcha
Download Presentation

Introduction to Frameworks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction to Frameworks Johan Larsson Computing Science Department, IT Uppsala University, Sweden Seminar for the Patterns and Frameworks D-level course  jola@csd.uu.se http://www.csd.uu.se/~jola/ May 12, 1999 © J. Larsson. All rights reserved. May not be distributed or used without the authors permission in writing.

  2. Contents • Perspectives on Frameworks:definitions • Properties of Frameworks:comparison with function library and class library • Problems • Examples

  3. Motivation “We have experienced a significant increase in software reusability and an overall improvement in software quality due to the application of object-oriented programming concepts in the development and (re)use of semifinished software architectures rather than just single components and the bond between them, that is, their interaction. The term framework is used for these architectures.” Wolfgang Pree [Pree94]

  4. What is a Framework? “A set of classes that embodies an abstract design for solutions to a family of related problems…” [Johnson88a] “A reusable design of all or part of a system that is represented by a set of classes and the way their instances interact.” [Johnson97a] “A set of abstract and concrete classes.” [Pree94a] • What is a framework?

  5. Perspectives • Johnson’s PerspectiveJohnson, Foote, Gamma et al describe application framweorks in terms of abstract classes. • Bosch’s Perspective • Pree’s PerspectiveViews a framweork as a genericfoundation that may contain many concrete classes. • A Business Perspective

  6. Johnson’s Perspective • The Hollywood Principle:Don’t call us - we call you! • Template solution to a class of problems [Johnson88a] • White Box = based on inheritance • Black Box = based on composition

  7. Pree’s Perspective • Framework • A set of abstract and concrete classes [Pree94a]. • Application Framework • A generic software system for an application domain [Pree94a]. • That is: a partial application that needs to be transformed into a specific/complete application.

  8. Bosch’s Perspective • “A framework constitutes of a large structure that can be reused as a whole for the construction of a new system”. [Bosch96a] • White-box framwork relies on subclassing • Black-box framework relies on parametrization • [Bosch96a] identifies several problems with frameworks

  9. Business Perspective:Taligent and IBM • Adaptations must be Simple!It must be less expensive to use the framework than building applications from scratch. Compositions. • Enforcement of ReuseThe user is forced to write reusable components. Important for project-to-project reuse within a business.

  10. Structure of a Framework (1) • Hot-spotsPrepared connection points for subsystems, parameters or adapted classes. • Typically implements manydesign patternsFor example MVC, factory, abstract factory, prototype, singleton and facade. • External and internal interfacesThe internal interface stays the same across reuse [Deutsch89a].

  11. Structure of a Framework (2) • Inversed flow of controlThe framework calls the program: don’t call us - we call you. The Hollywood Principle.

  12. Properties (1) • Frameworks are extendible • Reusable design expressed in terms of stable interfaces • Frameworks are code

  13. Properties (2) • Solves a set of problems • Information hiding • Interactions between classes are predecided • Inversed flow of control

  14. Classification based on Structure • White box = inheritance-based • The framework contains many abstract classes and therefore requires subclassing [Pree96a]. • Black box = composition-based • The framework contains ready-made components for adaptations [Pree96a]. • Qustion: which of them is easiest to use? Which is to be expected after a long evolution of the framework?

  15. A Classification based on Problem Domain • Application Framework • The framework is a partial application.Examples: ET++, InterViews and MacApp • Support Framework = Subsystem • The framework is not a partial application but a partial framework.Examples: Taligent CommonPoint and EFLIB • Foundational Framework • The framework provides a foundational architecture for other frameworks / applications.Examples: component architectures (BlackBox) and object request brokers (CORBA)

  16. Framework versus Design Patterns • More than ideas! • Frameworks are implemented software systems and are therefore more refined than design patterns. • Frameworks may contain many patterns • Many patterns in existing catalogues are harvested from frameworks like ET++, MacApp, NeXTStep and InterViews.

  17. Developing a Framework • Reuse through PatternsPatterns allow us to reuse knowledge harvested from other (framework) projects. • Iteratation and PrototypingWe do not expect a framework to arise immediately. We must perform an iterative development cycle with evaluated prototypes, especially if the problem domain is unexplored. • Simplicity with FlexibilityWe put every effort in hiding complexity from the user without compromising on the flexibility.

  18. Key Design Goals • Flexible Object CreationInstantiation in FACTORY METHODS or ABSTRACT FACTORIES [Gamma95a]. • Provide Abstract ClassesProvide abstract classes for behavior that may need to be adapted. Also provide concrete classes and make them default products in factories. • Has-a before Is-aWhere possible, use composition instead of inheritance. Inheritance builds walls around your class hierarchies but is necessary for subtyping.

  19. Evolution of a Library into a Framework • Function Library • Call-backs and parameters • Class Library • Delta-change using Inheritance • Abstract classes • Application Framework • Inversed control flow • Interaction between classes

  20. Framework versus Library

  21. Function Library

  22. Class Library

  23. Application Framework

  24. Further Evolution • White-Box becomes Black-Box • Concrete components are added.

  25. Framework versus Class Library • ”With class libraries prgorammers reuse only implementation, whereas with frameworks they reuse design.” [Cotter95a]

  26. Benefits with Frameworks (1) • Reduce cost and improve quality! [Fayad97a] • Reduction of the required source code to write an application: up to 90% more [Gamma89a] compared a traditional function library • Standardized application structure • Enforcement of reuse

  27. Benefits with Frameworks (2) • Localize the impact of changes [Fayad97a] • Leverage domain knowledge [Fayad97a] • Rapid application development - reduced time to market!

  28. Problems with Frameworks • Enormous development effort is required [Pree96a] • Learning curve is steep! [Fayad97a] • Complex software is hard to design: we will see examples of problems emerging from the complexity in a framework. • Narrow application domain.Solution: flexiblity, components ...

  29. Still must be adaptable! Requires built-in mechanisms for customizations (factories, facades, persistent storages). Ease of Use Problem • Must be easy to use to ensure cost-benefit over designing from scratch.

  30. Other Problems with Frameworks • Complexity: Frameworks are huge, and are therefore difficult to maintain and expensive toinvestin. • Reliability: Frameworks must be stable and well-tested. Many applications will depend on their quality! • Simplicity: although complex, a framework must still be easy to use!

  31. Micro-kernel allows for flexibility Layers decrease complexity Subsystems allow for extendibility and flexibility Example:EFLIB - Architecture (1) eflib

  32. More than hundred frameworks [Cotter95a] Framework = subsystem Shift in focus to many fine-grained integrated frameworks and away from large monolithic frameworks [Bosch96a]. Example: Taligent CommonPoint

  33. Summary • Architecture reuse • Enforcement of a way of programming: enforcing reuse. • Information Hiding: improves quality and productivity! • Complexity: design and evolution problems! • Expensive Investments • Steep Learning Curve

  34. Further Reading (1) [Bosch96a]Bosch et al, Object-Oriented Frameworks - Problems and Experiences, 1996. [Cotter95a] Cotter, Inside Taligent Technology, 1995. [Deutsch89a] L.Peter Deutch, Design Reuse and Frameworks in the Smalltalk-80 System, 1989. [Fayad97a]Fayad and Schmidt, Object-Oriented Application Frameworks, 1997. [Gamma94a]Gamma, Marty, Weinand, Design and Implementation of ET++ - A Seamless Object-Oriented Application Framework, 1989.

  35. Further Reading (2) [Johnson88a]Johnson et al, Designing Reusable Classes, 1988. [Johnson97a]Johnson, Components, Frameworks, Patterns, 1997. [Pree94a]Wolfgang Pree, Design Patterns for Object-Oriented Software Development, 1994. [Pree96a]Wolfgang Pree, Framework Patterns, 1996.

More Related