comparing frameworks and layered refinement
Post on 05-Feb-2016
26 Views
Preview:
DESCRIPTION
TRANSCRIPT
Comparing Frameworks and Layered Refinement
Richard Cardone and Calvin Lin
Department of Computer Sciences
University of Texas at Austin
ICSE 2001
5/17/01 ICSE 2001/Java Layers 2
Problem
Complex
Require customization for different users
Maintenance is also expensive
Code interdependencies make change difficult
Large applications are expensive to build!
5/17/01 ICSE 2001/Java Layers 3
The Reuse Approach
Libraries Code and some design sharing
Families of Applications More design sharing (control flow, subsystems)
Applications are built using prefabricated parts
Conventional technologies limit reuse
Share a common code base
5/17/01 ICSE 2001/Java Layers 4
An OO Problem
Car Box House
Problem: Lockable code replicated 3 times
LockableCar
LockableBox
LockableHouse
lock(), unlock()
5/17/01 ICSE 2001/Java Layers 5
An OO Solution
Use same lockable code for all 3 classes Encapsulate lockable code in a class Subtype Car, Box, House with new class
class Lockable<T> extends T {
lock(){…}
unlock(){…}
}[Bracha & Cook, 1990]
Mixins are types with parameterized supertypes
5/17/01 ICSE 2001/Java Layers 6
Mixed-In Classes
Car Box House
Lockable<Car> Lockable<Box> Lockable<House>
Lockable code reused 3 times
<T>
Lockable<T>
5/17/01 ICSE 2001/Java Layers 7
Today’s Talk
Compare 2 application starter kit technologies
Object-Oriented Frameworks
Mixins
How well does each approach support reuse?
Usability
Flexibility
5/17/01 ICSE 2001/Java Layers 8
Presentation Overview
Background ACE Framework (Doug Schmidt) Java Layers
Experiment 4 Points of Comparison Key Insights
Java Layers Research Goals
5/17/01 ICSE 2001/Java Layers 9
The ACE Framework
Schmidt’s ACE framework
Adaptive Communication Environment (ACE)
C++ client/server application framework
Proven, mature framework technology
Implements design patterns for distributed computing
5/17/01 ICSE 2001/Java Layers 10
ACE Example: Task
Supports asynchronous processing
Task objects encapsulate 1 or more threads
Client requests can be queued
Worker Threads
Message Queue
5/17/01 ICSE 2001/Java Layers 11
OO Framework Starter Kits
Abstract classes provide partially implemented apps
Programmers supply concrete classes to complete apps
ACE_Event_Handler (17) ACE_Shared_Object (3)
ACE_Service_Object (2)
ACE_Task_Base (19)
ACE_Task (15)
User_Class
Framework
Application
5/17/01 ICSE 2001/Java Layers 12
Java Layers (JL)
Java language support for mixins
JL implements Batory’s GenVoca model
Mixins encapsulate feature implementations
Applications are built incrementally in layers
5/17/01 ICSE 2001/Java Layers 13
JL Starter Kits
Set of mixins in an application domain Each mixin implements one application feature
TaskBase
TaskQueue
TaskInterrupt
TaskStream
TaskInterrupt<TaskQueue<TaskBase>>
…
Components Compositions
TaskStream<TaskBase>
TaskStream<TaskBase>
TaskBaseGenerated hierarchy
5/17/01 ICSE 2001/Java Layers 14
Experiment
Idea: Compare programming with mixins to
programming with frameworks
Hypothesis: Usability and flexibility can be
enhanced using mixins
Methodology: Re-engineer a subset of the
ACE framework using mixins Usability: How easy is it to develop applications?
Flexibility: How easy is it to customize code?
5/17/01 ICSE 2001/Java Layers 15
ACE Task Interface
ACE Task interface contains lots of methods Initialization and termination
Thread and queue management
Message I/O
Support for ACE Module design pattern
Interface methods include: open, close, activate, suspend, resume, msg_queue, putq, getq, ungetq, reply, put_next, can_put, name, next, sibling, module, flush, water_marks, …
5/17/01 ICSE 2001/Java Layers 16
Re-Engineering ACE Interfaces
Break ACE ifc into several smaller JL ifc’s
Each JL ifc defines a fine-grain application feature
Each feature is implemented in a mixin
Applications select the interfaces/features they need
5/17/01 ICSE 2001/Java Layers 17
JL Task Interface
JL Task interface contains a few methods TaskIfc: open, close, activate
Auxiliary interfaces support optional features TaskQueueIfc: putq
TaskInterruptIfc: interrupt
TaskStreamIfc: getStream, setStream
…
Single ACE ifc carved up into several JL ifc’s
5/17/01 ICSE 2001/Java Layers 18
Re-Engineered Interfaces
No. of JL Interfaces 10
Avg. JL Interface Width
1.5
1
No. of ACE Interfaces
ACE Interface Width
15
Task
27 3 4
2.4 1.7 1.3
11
5
1
66 5
Reactor Acceptor Connector
13 13
1.5 1.8
11
20 24
Timer Queue
5/17/01 ICSE 2001/Java Layers 19
Comparison
We’ve seen how ACE and JL are structured
Let’s compare the two approaches
I - Usability
II - Starter Kit Flexibility
III - Starter Kit Scalability
IV - Framework Evolution
5/17/01 ICSE 2001/Java Layers 20
I - Usability
ACE’s wide interfaces More complex for programmers Larger, possibly slower, executables Not poor design, but a technology-based tradeoff
JL’s narrow interfaces Complexity introduced only when needed Promote smaller, precisely customized applications
JL’s narrow interfaces reduce complexity
5/17/01 ICSE 2001/Java Layers 21
II - Starter Kit Flexibility
Frameworks segregate code Framework code vs. application code
Tradeoff: overfeaturing vs. code replication
All JL components are part of starter kit Mixin classes are loosely coupled
Extra starter kit classes have no effect if not used
JL avoids overfeaturing
5/17/01 ICSE 2001/Java Layers 22
III - Starter Kit Scalability
Framework interfaces often widen w/new features Tradeoff: number of classes multiply
Class hierarchies defined in advance
JL generates hierarchies on demand Only used feature combinations generate hierarchies
Avoids interface width / multiple class tradeoff
JL scales well as new features are added
5/17/01 ICSE 2001/Java Layers 23
IV - Framework Evolution
Need to change a framework’s core classes But prevented by compatibility constraints
A
B
C D
B’
C’ D’
Original Tree
New SubtreeA
Framework Hierarchies are Fixed
5/17/01 ICSE 2001/Java Layers 24
The Flexibility of Mixins
Adding new mixins is usually non-disruptive
Classes can be substituted, inserted and removed
A
B’
C D
Class substitution
A
B
C D
Mutable parent/child relationships
Mixin Hierarchies are Flexible
5/17/01 ICSE 2001/Java Layers 25
Key Insights
Mixins use feature-specific interfaces to
enhance code usability
Mixins defer parent/child relationships to
enhance code flexibility
5/17/01 ICSE 2001/Java Layers 26
JL Research Goals
Currently, mixins have some drawbacks
Overhead of deep class hierarchies
Initializing superclasses
Compositional correctness
Referencing subtypes from supertypes
JL goal: Enhance mixin programming
See paper for novel JL language support
5/17/01 ICSE 2001/Java Layers 27
Conclusion
JL programming using mixins Promotes flexibility by encapsulating features
Scales with the number of features
Avoids a number of framework pitfalls
Presents some new challenges
Framework programming Requires no new language support
Has a proven track record
5/17/01 ICSE 2001/Java Layers 28
Related Work
Mixin-based inheritance model Bracha & Cook, 1990
Mixins shown to enhance reuse in C++ VanHilst & Notkin, 1996
Layered application construction Batory & colleagues, 1992-present
Mixin Layers simplify mixin composition Batory & Smaragdakis, 1998
5/17/01 ICSE 2001/Java Layers 29
Future Work
Enhance JL compiler with latest language support
Perform more experiments
Explore limits of feature encapsulation
Let more people program with JL
30ICSE 2001/Java Layers5/17/01
THE END
Think Layers
5/17/01 ICSE 2001/Java Layers 31
Example: Constructor Propagation
Initialize all classes in a mixin hierarchy Adjust subclass constructor signatures
class TaskBase implements TaskIfc {
propagate TaskBase(ThreadMgrIfc tm){…} …}
class TaskQueue<T implements TaskIfc> extends T {
propagate TaskQueue(MsgQueueIfc mq){…} …}
TaskQueue<TaskBase> constructor takes ThreadMgrIfc and MsgQueueIfc parameters
top related