1 / 17

Frameworks III

Frameworks III. Practical Issues. 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

virote
Download Presentation

Frameworks III

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

More Related