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