Comparing Frameworks and Layered Refinement Richard Cardone and Calvin Lin Department of Computer...

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