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 not relationship to framework
• use one or more framework objects, but not called
  by framework objects

3
How tos 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 frameworks 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 spec 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 spec implied by superclasses
• Programmer must understand frameworks 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/reqt that framework builder
  anticipates application developer will have
• Provides guidance as to how to use hook
• Focuses on smal reqt
• Details required changes to design
• Constraints to be satisfied
• Effects on the framework

11
Hooks (contd)

• 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
• Inversion of Control
• Application processing customized by event
  handler objects invoked via frameworks 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)

13
Classification of Frameworks

• System Infrastructure
• Middleware Integration
• Enterprise application

14
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

15
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 dist env
• Examples
• ORB
• Message-oriented MW
• Transactional databases

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