Frameworks III

1. Frameworks III Practical Issues

2. How to use Application Frameworks • Application developed with Framework has 3 parts: • framework • concrete subclasses • everything else: • script that specified which concrete classes will be used and how they will be interconnected • objects that have no relationship to framework • use one or more framework objects, but not called by framework objects

3. “How to’s” for Frameworks • Use • Learn • Evaluate • Develop

4. How to use Application Frameworks • Easiest way: Blackbox (e.g., GUI frameworks) • connect existing components • DOES NOT change framework or make any new concrete subclasses • reuses framework’s interfaces and rules for connecting components • Analogous to: • Building from Legos • Connected integrated circuits for circuit board • Application programmers only need to know: • type A objects can be connected to type B objects • not need to know exact implementation of A and B

5. How to use Application Frameworks • Next easiest way: (Graybox) • Define new concrete subclasses; use them to build application • Subclasses are tightly coupled to superclasses: • Requires more knowledge about abstract classes • Subclasses must meet specification implied by superclasses • Programmer must understand framework’s interfaces in detail

6. How to use Application Frameworks • Most challenging way: (Whitebox) • Change the abstract classes that form core of framework • add new operations or variables to them • Analogous to fleshing out a skeleton of an application. • Usually requires the source code of framework • Most challenging, but most powerful • Changes to abstract classes can break existing concrete classes

7. How to Learn Application Frameworks • Learning a framework is more challenging than learning a class library • not just individual classes • learn a set of classes with specific interconnections • many classes are abstract • Must have concrete examples (easy to challenging) • Documentation should include: • Purpose of framework • How to use framework (e.g., cookbook style) • How the framework works : • interaction between objects • how responsibility is partitioned between objects

8. How to Evaluate Application Frameworks • Most application domains have no commercially available domain-specific frameworks • Criteria: • Run on “right” platform • “right” programming language • “right” standards • “right” tradeoffs between simplicity and power. • Make checklist for objectives of frameworks. • Features that must be supported (e.g., distributed, networking issues, interaction styles, etc.)

9. How to Develop Application Frameworks • Design of framework analogous to design of reusable SW • Domain analysis (collect examples) • First version: should implement examples • Usually whitebox • Then use to build applications • Will point out weak points in frameworks • Parts that are hard to change • Experience leads to improvements in framework • Make it more blackbox • Iteration is important: • Domain analysis will gain more information • Framework makes explicit the parts that will change • Components should implement changeable parts • Frameworks are abstractions • Design of framework depends on original examples

10. Hooks • Hook: Point in framework meant to be adapted • Filling in parameters • Creating subclasses • Hook Description: • Describes problem/requirement that framework builder anticipates application developer will have • Provides guidance as to how to use hook • Focuses on small requirement • Details required changes to design • Constraints to be satisfied • Effects on the framework

11. Hooks (cont’d) • Adaptation: • Enabling/disabling a feature • Replacing a feature • Augmenting a feature • Adding a feature

12. Benefits of Frameworks • Modularity: • Encapsulate volatile implementation details behind stable interfaces • Localize impact of design/implementation changes • Reusability: • Stable interfaces enhance reusability of generic components • Leverages domain knowledge/prior experience • Extensibility: • Hook methods that allow applications to extend its stable interfaces • Hook methods decouple stable interfaces and behaviors of an application domain

13. Benefits of Frameworks (cont’d) • Inversion of Control: • Application processing customized by event handler objects • invoked via framework’s reactive dispatching mechanism • Allow framework (rather than each application) to determine which set of application-specific methods to invoke in response to external events • (e.g., window messages from end users or • packets arriving on communication ports)

14. Classification of Frameworks • System Infrastructure • Middleware Integration • Enterprise application

15. System Infrastructure frameworks • Simplify development of portable and efficient system infrastructure: • Examples: • OS (Campbell-Islam 93) • Communication (Schmidt 97) • UI and language processing tools • Primarily used internally within SW org

16. Middleware Integration Frameworks • Commonly used to integrate distributed applications and components • Designed to enhance ability of SW developers to modularize, reuse, and extend SW infrastructure in distributed environment • Examples: • ORB • Message-oriented MW • Transactional databases

17. Enterprise Application Frameworks • Address broad application domains: • E.g.: telecommunications, avionics, manufacturing, financial eng., • Expensive to develop/purchase • Good investment: • Support development of end-user applications/products directly • System Infrastructure/Middleware Frameworks: • Focus largely on internal SW development concerns • Contribute significantly to rapid creation of high-quality SW • Not contribute to high revenue for large business orgs.