Download presentation
Presentation is loading. Please wait.
Published byMervyn Sherman Martin Modified over 6 years ago
1
CSE870: Advanced Software Engineering (Frameworks, Part 2)
More Frameworks Acknowledgements: K. Stirewalt R. Johnson, B. Foote Johnson, Fayad, Schmidt CSE870: Advanced Software Engineering (Frameworks, Part 2)
2
CSE870: Advanced Software Engineering (Frameworks, Part 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. CSE870: Advanced Software Engineering (Frameworks, Part 2)
3
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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. CSE870: Advanced Software Engineering (Frameworks, Part 2)
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. CSE870: Advanced Software Engineering (Frameworks, Part 2)
5
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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 protocols 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. CSE870: Advanced Software Engineering (Frameworks, Part 2)
6
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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. CSE870: Advanced Software Engineering (Frameworks, Part 2)
7
Use of Abstract Class to Represent a Protocol
Cheng, CSE870 (Spring 2003) Use of Abstract Class to Represent a Protocol Observe that both Box and Circle implement a similar protocol. By naming both operations Draw, we can create an abstract superclass that denotes the protocol. CSE870: Advanced Software Engineering (Frameworks, Part 2)
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? CSE870: Advanced Software Engineering (Frameworks, Part 2)
9
Example Decoupling using abstract operations
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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(); CSE870: Advanced Software Engineering (Frameworks, Part 2)
11
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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 i=0; i < 3; ++i ) { figures[i].Draw(); } private: Figure* figures[3]; }; CSE870: Advanced Software Engineering (Frameworks, Part 2)
12
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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. CSE870: Advanced Software Engineering (Frameworks, Part 2)
13
CSE870: Advanced Software Engineering (Frameworks, Part 2)
Intro to OO Frameworks CSE870: Advanced Software Engineering (Frameworks, Part 2)
14
CSE870: Advanced Software Engineering (Frameworks, Part 2)
Support reuse of detailed designs An integrated set of components: Collaborate to provide reusable architecture for Family of related applications CSE870: Advanced Software Engineering (Frameworks, Part 2)
15
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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 CSE870: Advanced Software Engineering (Frameworks, Part 2)
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 Invokes ADTs Math Event Loop UI Dbase Class Library Architecture Math Networking UI Invokes Application Specific Logic Call Backs ADTs Event Loop Dbase Framework Architecture CSE870: Advanced Software Engineering (Frameworks, Part 2)
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. CSE870: Advanced Software Engineering (Frameworks, Part 2)
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 messages. 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). CSE870: Advanced Software Engineering (Frameworks, Part 2)
19
Example: Java AWT Framework (abstracted)
Cheng, CSE870 (Spring 2003) Example: Java AWT Framework (abstracted) UI toolkits are the canonical examples of OO frameworks. CSE870: Advanced Software Engineering (Frameworks, Part 2)
20
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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) CSE870: Advanced Software Engineering (Frameworks, Part 2)
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. CSE870: Advanced Software Engineering (Frameworks, Part 2)
22
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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. CSE870: Advanced Software Engineering (Frameworks, Part 2)
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. CSE870: Advanced Software Engineering (Frameworks, Part 2)
24
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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. CSE870: Advanced Software Engineering (Frameworks, Part 2)
25
CSE870: Advanced Software Engineering (Frameworks, Part 2)
AWTEvent hierarchy CSE870: Advanced Software Engineering (Frameworks, Part 2)
26
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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 CSE870: Advanced Software Engineering (Frameworks, Part 2)
27
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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. CSE870: Advanced Software Engineering (Frameworks, Part 2)
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); CSE870: Advanced Software Engineering (Frameworks, Part 2)
29
Example: A mouse-event listener
class ButtonMouseListener implements MouseListener { public void mouseEntered(MouseEvent 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) {} } CSE870: Advanced Software Engineering (Frameworks, Part 2)
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); CSE870: Advanced Software Engineering (Frameworks, Part 2)
31
Animations in the subArctic UI Toolkit
Example OO Framework: Animations in the subArctic UI Toolkit CSE870: Advanced Software Engineering (Frameworks, Part 2)
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. CSE870: Advanced Software Engineering (Frameworks, Part 2)
33
Abstract UML of the framework
CSE870: Advanced Software Engineering (Frameworks, Part 2)
34
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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 CSE870: Advanced Software Engineering (Frameworks, Part 2)
35
CSE870: Advanced Software Engineering (Frameworks, Part 2)
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 CSE870: Advanced Software Engineering (Frameworks, Part 2)
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 CSE870: Advanced Software Engineering (Frameworks, Part 2)
37
Influence of OO Frameworks
CSE870: Advanced Software Engineering (Frameworks, Part 2)
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.