Framework Problems and Experiences

1
Framework Problems and Experiences

• Presented by Shirong Yang
• Feb. 29, 2000

2
What is the definition of Framework?

• A framework is a set of classes that embodies an
  abstract design for solutions to a family of
  related problem Johnson-Foote,1988
• A framework is a reusable design expressed as a
  set of abstract classes and the way their
  instances collaborate Ralph Johnson.
• Application frameworks are reusable
  object-oriented designs implemented using a set
  of abstract and concrete classes. A family of
  similar, though not identical, applications can
  be built out of a single framework Gary .

3
What is the most difficult thing when to learn to
use frameworks?

• We have to turn the way you think about
  programming inside out.
• Frameworks follow the Hollywood principle "Don't
  call us, we'll call you".
• The library code is in charge and as an
  application programmer you just provide various
  bits and pieces and is no longer in control.
• It is like programming event driven applications,
  but one step further.

4
What is the relationship between frameworks and
design patterns?

• Frameworks are software whereas patterns are
  knowledge or information about software.
• Patterns can be used to describe frameworks.
• Some part or aspect of a framework can be a
  realization of a pattern.
• Developing a framework is somewhat like
  developing a scientific theory for some area.
• Developing a framework is hard and you should do
  that only for your own special area of
  competence.

5
Terminology of Framework

• Core framework design
• Include both abstract and concrete classes in the
  domain
• The concrete classes is invisible to the
  framework user
• The abstract class is either invisible or a
  subclass to the framework user
• Describes the typical software architecture for
  applications in the domain

6
(cont)

• Framework internal increment
• The core framework design has to be accompanied
  by additional classes
• These additional classes form a number of class
  library
• Capture common implementations of the core
  framework design
• e.g. subclass, collection of subclasses

7
(cont)

• Object Oriented framework
• A core framework design and its associated
  internal increments (if any) with accompanying
  implementations

8
An Example of application frameworks

• Case-Based Reasoners (CBRTool ) framework
• M. Jaczynski, 1998. This project goal is to
  design CBR tools to allow
• An easier development by reusing past designs and
  implementations
• The integration of new components to enhance the
  tools from an application to another
• The extension of existing components and their
  collaborations to meet specific application
  requirements
• Design open software engineering tools (CBR
  tools) which facilitate the design and
  development of case-based reasoners

9
Framework Design Analysis

• The framework is composed of a set of abstract
  classes and defines the way objects collaborates
  as in class library, but a framework is much more
  than a library it allows the reuse of both
  design and code.
• The design process is centered on the
  identification of hot spots. Hot spots are well
  defined features of the framework that can be
  customized for a specific application by
  specialization( white-box hot spot) or
  composition ( black-box hot spots)
• The hot spots are usually created by using design
  patterns which provide typical design solutions
  and improve the framework documentation

10
Framework Design Analysis(cont)

• Design a framework with four axes of variability
  Case representation, case storage, case indexing
  and reasoning steps.
• These four axes represent the main ways
  applications may differ from one to another
• These axes leads to the definition of hot-spots

11
CBRTools Framework DesignDelegation of
reasoning steps
12
Separation of Case Storage and case indexing
13
Designing indexing as reusable components
14
A Library of Adaptation Pattern
15
Whats the problems in Framework

• Framework development
• Related with the initial framework design
• Domain scope
• Framework documentation
• Business investment models for framework domain
• Framework development methods
• Framework testing and releasing

16
Framework Development

• Domain scope
• Determine the right size for the domain
• Too large or too small
• Framework documentation
• Cost of providing suitable framework
  documentation is very high
• A framework documentation standard does not exist
• Business model
• The investments for the framework development may
  be larger than the benefits
• Relate to the business culture issues

17
Framework Development (cont)

• Framework development methods
• Existing development methods do not sufficiently
  support development of frameworks
• Application frameworks should be stable over time
• Business objects and workflow management and
  issue of stability must be considered
• Achieving portability is not a trivial task

18
Framework Development(cont)

• Framework testing
• Developing test applications using the framework
  and then test the resulting application, but the
  versatility of the framework can not be tested by
  only one application
• Testing the framework for errors using
  traditional methods, such as executing parts of
  the code in well-defined cases, will not work for
  the whole framework
• Releasing
• The domain is not stable in itself, but evolves
  constantly
• The domain scope and boundaries

19
Framework Problems(Cont)

• Framework usage
• Related to the instantiation of a framework and
  application development
• Training and learning
• Manage the framework development process
• Applicability of the framework
• Estimation of the increment
• Understand the framework
• Verification of the application-specific
  increment
• Debugging the application

20
Framework Usage

• Training and learning
• Take long time due to the complexity of the
  framework for the learning
• Training approaches
• Mentoring
• Training courses

21
Framework usage(cont)

• Managing the development process
• Current state of framework-based application
  development is still in the ad hoc stage
• It is much difficult to explicitly write a
  specification in the framework case
• Applicability of the framework
• Initial difficulty is to understand the intended
  domain of the framework and its appropriateness
  for the application
• Whether A specific application can be built based
  on a specific framework and what resources are
  needed to implement the application-specific
  increment

22
Framework usage(cont)

• Estimations of the increment
• Most of the time is spent on understanding the
  framework
• Estimate the amount of work required for a
  specific application
• Understanding the framework
• the prerequisite for evaluating the application
  of a framework

23
Framework usage(cont)

• Verification of the application-specific
  increment
• An application based on a complex framework of
  based on several frameworks can prove difficult
  to test
• Functional verification and verification that the
  increment conforms to the architectural style and
  design rules imposed by the framework
• Debugging the application
• The debugger must manually define which part
  should be skipped and which routines should be
  followed through.

24
Framework Problems(cont)

• Framework composition
• Architectural mismatch
• Overlay of framework entities
• Composition of entity functionality
• Hollywood principle
• Integrating legacy components

25
Framework composition

• Architecture mismatch
• For example
• one of framework is based on the blackboard
  architecture.
• The another one is based on the layered
  architecture.
• The composition of two frameworks may cause the
  problem.

26
Framework composition(cont)

• Overlay of framework entities
• Both framework classes represent a state property
  of the real-world entity but represent it in
  different ways
• Both framework classes represent a property of
  the real-world entity, but one class represents
  it as a state and the other class as a method
• The execution of an operation in one framework
  class requires state change in the other
  framework class

27
Framework composition(cont)

• Composition of entity functionality
• e.g. three-tier application architecture of a
  user interface framework, a framework covering
  the application domain concepts, and a framework
  providing database functionality
• Hollywood Principle
• Conflict problem might happen when two framework
  are composed into an application
• The problems of extensibility and composability

28
Framework composition(cont)

• Integrating legacy components
• To integrate a legacy component, the software
  engineer is required to create some form of
  adaptation or bridging

29
Framework Problems(cont)

• Framework evolution and maintenance
• Framework change
• Choice of maintenance strategy
• Business domain change
• Design iterations