R R R 1 Frameworks III Practical Issues

R R R 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

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

R R R 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

R R R 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

R R R 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

R R R 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

R R R 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.)

R R R 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

R R R 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

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

R R R 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

R R R 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)

R R R 14 Classification of Frameworks System Infrastructure Middleware Integration Enterprise application

R R R 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

R R R 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

R R R 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.