More Frameworks

1
More Frameworks

• Acknowledgements
• K. Stirewalt
• R. Johnson, B. Foote
• Johnson, Fayad, Schmidt

2
Overview

• Review of object-oriented programming (OOP)
  principles.
• Intro to OO frameworks
• Key characteristics.
• Uses.
• Black-box vs. white-box frameworks.
• Example study Animations in the subArctic UI
  toolkit.

3
Recap on OOP

• Key features that differentiate OOP from
  traditional block-structured languages
• Polymorphism a late-binding feature, whereby a
  procedure is dynamically bound to a message
  request.
• Inheritance allows operations to be defined in
  one (parent) class and then overridden in another
  (child) class.
• Inheritance and polymorphism together are the
  principle tools of OO frameworks.

4
Inheritance and polymorphism

• Subclasses provide different methods for same
  operation.
• Benefit Enables decoupling of cooperating
  classes.
• Clients need not know how an operation is
  implemented.
• Thus, designs are portable and extensible.
• Code can be reused.
• Two cases
• Superclass provides a method for the operation.
• we say the subclass overrides this method.
• subclass method may explicitly invoke superclass
  method.
• Superclass provides no method for the operation.
  
• we say the operation is abstract in the
  superclass.

5
Protocol

• Operations performed on objects by sending them
  messages''.
• Specification of an object given by its message
  protocol
• Set of messages that can be sent to it
• Includes type of arguments of each message.
• Objects with identical protocol are
  interchangeable.
• Interface between objects defined by protocols
  they expect each other to understand.
• In most languages, protocol is bound to an
  object's class1.

6
Abstract classes

• Defn class that cannot have any instances.
• Only subclasses can have instances.
• How to specify that a class is abstract
• C Implicit abstract class has pure
  virtual functions.
• Java
• Class can be explicitly declared abstract, or
• Abstract operations can be grouped into an
  interface.
• Used to define standard protocols.

7
Use of Abstract Class to Represent a Protocol
8
Abstract Operations and Design Coupling

• Imagine a tool that places figures on a grid.
• Example gridding of program icons in a window
  manager.
• Example placement of button figures in a panel.
• Grid-management code allocates figures to grid
  positions, avoiding collisions and possibly
  implementing a fill policy.
• Code should not be concerned with how to draw a
  figure.
• Question How do you separate grid management
  from the drawing of figures?

9
Example Decoupling using abstract operations
10
Example Use of these classes

•  include "Square.h"
• include "Triangle.h"
• include "Circle.h"
• include "Grid.h"
• ...
• Grid myGrid
• ...
• myGrid.AddFigure( new Square )
• myGrid.AddFigure( new Triangle )
• myGrid.AddFigure( new Circle )
• myGrid.Draw()

11
Example continued

• class Figure public WindowComponent
  public
• virtual void Draw() 0 // pure virtual
  function!
•  
• class Grid public WindowComponent
  public void AddFigure( Figure )
  void Draw() for( int i0 i lt 3 i
  ) figuresi.Draw()
  
• private Figure figures3

12
Plug Compatibility

• If several classes define same protocol, then
  objects in those classes are plug compatible.
• Thus complex objects can be created by plugging
  together a set of compatible components.
• Style of programming called building tool kits.

13
Intro to OO Frameworks
14
Framework

• Support reuse of detailed designs
• An integrated set of components
• Collaborate to provide reusable architecture for
• Family of related applications

15
Frameworks

• Frameworks are semi-complete applications
• Complete applications are developed by inheriting
  from, and
• Instantiating parameterized framework components
• Frameworks provide domain-specific functionality
• Ex. business, telecommunication, dbases,
  distributed, OS kernels
• Frameworks exhibit inversion of control at
  run-time
• Framework determines which objects and methods to
  invoke in response to events

16
Class Libraries vs Frameworks vs Patterns

• Application
• Specific
• Logic

Networking

• Definition
• Class Libraries
• Self-contained,
• Pluggable ADTs
• Frameworks
• Reusable, semi-complete applications
• Patterns
• Problem, solution, context

ADTs
Invokes
Math
Event Loop
Dbase
UI
Class Library Architecture
Math
Networking
UI
Application Specific Logic
Invokes
Call Backs
ADTs
Event Loop
Dbase
Framework Architecture
17
Characteristics of Frameworks

• Often
• User-defined methods invoked by the framework
  code itself.
• Framework plays the role of main program''.
• This inversion of control allows frameworks to
  serve as extensible code skeletons.
• User-supplied methods tailor generic framework
  algorithms for a specific application.

18
Object-Oriented Frameworks

• A.k.a Object-oriented abstract design.
• Consists of
• Abstract class for each major component
• Interfaces between components defined in terms of
  sets of messsages.
• Usually a library of subclasses that can be used
  as components in the design.
• Many well-known examples
• All modern UI toolkits (e.g., Java AWT,
  subArctic, MFC).
• Distributed computing toolkits (e.g., ACE).

19
Example Java AWT Framework (abstracted)
20
Whitebox Frameworks

• Program skeleton
• Subclasses are the additions to skeleton
• Implications
• Framework implementation must be understood to
  use
• Every application requires the creation of many
  new subclasses
• Can be difficult to learn
• Need to need how it was constructed (hierarchical
  structure)
• State of each instance is implicitly available to
  all methods in framework (i.e., similar to global
  vars)

21
Example Event handling in Java AWT 1.02 and
before

• Events are propagated from components to their
  containers until such time as the event is
  serviced.
• Every component has the operation
• public boolean handleEvent( Event event )
• To handle an event, simply override this
  operation with a method.
• Note the return type (boolean) that is used by
  the framework to decide whether or not the event
  was handled by the component.
•  If not handled, then the event is propagated to
  the component's container.

22
Blackbox Frameworks

• Customize framework by supplying with set of
  components that provide application-specific
  behavior
• Implications
• Each component required to understand a
  particular protocol
• All or most components from component library
• Interface between components defined by protocol
• Need to only understand external interface of
  components
• Less flexible
• Info passed to application components must be
  explicitly passed.

23
Example Event handling in Java AWT 1.0 and 1.1

• In the 1.0 version of Java AWT, event handling
  was implemented using inheritance.
• In 1.1, this model was replaced with a
  delegation-based model i.e., one that is built
  around protocols rather than implementation
  sharing.

24
Event handling (AWT 1.1)

• Events are first-class objects.
• There is a class Event.
• Subclasses identify different kinds of events.
• Components fire events.
• Other objects can listen for/act upon these
  events.
• Interested objects register themselves as a
  Listener with the component that fires the event.
  

25
AWTEvent hierarchy
26
Event routing

• Lots of different kinds of events.
• Different events carry different types of
  information.
• E.g., ActionEvent carries a command, TextEvent
  carries a string being edited.
• Components fire these events.
• E.g., Button fires an ActionEvent.
• E.g., TextArea fires a TextEvent.
• All components fire WindowEvents.
• When fired, events are routed to special Listener
  objects

27
Listeners

• A listener is an object to which AWTEvents can be
  routed by components.
• Different types of listeners.
• One for each subclass of AWTEvent.
• E.g., ActionListener, ComponentListener,
  WindowListener.
• A listener class is abstract
• Operation names only no attributes or methods.
• Declared as an interface in Java.

28
Example An action-event listener

• class ButtonListener implements ActionListener
  
• public void actionPerformed(ActionEvent event)
  System.out.println("Button pressed!!!")
• public class ActionExample extends Applet
• public void init()
• Button button new Button("Push me")
  button.addActionListener( new
  ButtonListener())
• add(button)

29
Example A mouse-event listener

• class ButtonMouseListener implements
  MouseListener public void mouseEntered(MouseEven
  t event) System.out.println("Mouse entered
  button!")
• public void mouseExited(MouseEvent event)
  System.out.println("Mouse exited button!")
• public void mousePressed(MouseEvent event)
  public void mouseClicked(MouseEvent event)
  public void mouseReleased(MouseEvent event)

30
Design schema for event routing

• Route events of class E from graphical component
  C to object O
• Design O to be an E-listener.
• Class of O must implement the E-listener
  interface.
• The corresponding methods must service the
  event.
• Add O to C's set of listeners.
• Pseudo-code C.addEListener(O)

31
Example OO Framework

• Animations in the subArctic UI Toolkit

32
SubArctic and animation

• SubArctic is a Java-based UI toolkit developed at
  Georgia Tech and Carnegie Mellon.
• Powerful support for animations
• High-level model for describing time-based events
  in a UI.
• Allows traditional image (i.e., page-flipping)
  animations.
• Also allows objects to smoothly move about
  screen, modify color over time, etc.
• Implemented as an OO framework.

33
Abstract UML of the framework
34
Data Dictionary

• Interactor interface defines the API that all
  objects appearing on the screen and/or accepting
  input must provide. Defines all basic operations
  of interactive objects
• Base_parent_interactor Base class for objects
  that support (arbitrary) children. Provides
  default implementation for all methods defined by
  interactor interface and supports routines
• Animatable Input protocol interface for
  specifying that an object is animatable. Each
  interactor that expects to receive animation
  input must implement animatable input protocol.
• Anim_mover_container A container class to move a
  collection of objects under control of an
  animation transition.
• Callback_object Interface for objects that
  receive callback from interactors .Callbacks are
  entities which are notified when significant user
  actions (such as a button press or a menu
  selection) occur. Implemented as objects in
  subArctic
• Transition primary abstraction for describing
  how animations are to proceed in subArctic. Combo
  of animations logical path, optional pacing
  function assoc. with path (does object move
  uniformly among values of path), animations time
  interval (how long does it take and when does it
  start)
• Time_interval first part of trajectory (absolute
  or relative form)
• Trajectory specifies mapping from time to a set
  of values (e.g., screen space)
• Pacer allow non-linear behavior for mapping

35
SubArctic animations

• Animation complex collaboration among multiple
  objects
• interactor is the object being animated
• Some classes/interfaces support customized
  animations
• For example
• trajectory used for positional path variation
  (straight line, running-start, smooth curve,
  etc.)
• pacer used for non-linear time variation
• Others provide communication hooks.
• Callback_object receives notifications at the
  beginning of the animation

36
Application Construction Environments (Toolkits)

• Defn Collection of high-level tools that allow a
  user to interact with an OO framework to
  configure and construct new applications Johnson
  joop88.
• Key observation Easier to build a tool to
  specialize classes with well-defined interfaces
  than to build a general-purpose code generator

37
Influence of OO Frameworks
38
In-Class Exercises

• 1) Go over the UML diagram that describes how
  subArctic implements animations
• 2) Give them time to look over the code for a
  simple instantiation of the framework.
• 3) Ask them to construct
• (a) a UML class model of the instantiation,
  using different colors for instantiated classes
• (b) a StateChart model of the entire
  collaboration (protocol), assuming that classes
  in the framework diagram denote roles in the
  collaboration.
• 4) Ask them to pair up and take a stand on the
  following question Is the SubArctic animation
  framework an example of a white-box or a
  black-box framework? Why or why not?

39
Exercises

• Instantiate this framework to move an object
  along a sinusoidal trajectory.
• Extend the previous solution to make the object
  rotate as it is moving through time.
• Question Is subArctic an example of a whitebox
  or blackbox framework? Explain.