Comparing Frameworks and Layered Refinement

1. Comparing Frameworks and Layered Refinement Richard Cardone and Calvin Lin Department of Computer Sciences University of Texas at Austin ICSE 2001

2. Problem Large applications are expensive to build! • Complex • Require customization for different users • Maintenance is also expensive • Code interdependencies make change difficult ICSE 2001/Java Layers

3. The Reuse Approach Share a common code base • 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 ICSE 2001/Java Layers

4. Car Box House LockableCar LockableBox LockableHouse lock(), unlock() An OO Problem Problem: Lockable code replicated 3 times ICSE 2001/Java Layers

5. Mixins are types with parameterized supertypes class Lockable<T> extends T { lock(){…} unlock(){…} } [Bracha & Cook, 1990] An OO Solution • Use same lockable code for all 3 classes • Encapsulate lockable code in a class • Subtype Car, Box, House with new class ICSE 2001/Java Layers

6. <T> Car Box House Lockable<T> Lockable<Car> Lockable<Box> Lockable<House> Mixed-In Classes Lockable code reused 3 times 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 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 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 ICSE 2001/Java Layers

10. Message Queue Worker Threads ACE Example: Task • Supports asynchronous processing • Task objects encapsulate 1 or more threads • Client requests can be queued ICSE 2001/Java Layers

11. ACE_Event_Handler (17) ACE_Shared_Object (3) ACE_Service_Object (2) ACE_Task_Base (19) Framework ACE_Task (15) Application User_Class OO Framework Starter Kits • Abstract classes provide partially implemented apps • Programmers supply concrete classes to complete apps 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 ICSE 2001/Java Layers

13. TaskBase Generated hierarchy TaskStream<TaskBase> JL Starter Kits • Set of mixins in an application domain • Each mixin implements one application feature Components Compositions TaskBase TaskInterrupt<TaskQueue<TaskBase>> TaskQueue TaskStream<TaskBase> TaskInterrupt TaskStream … 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? 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, … 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 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 ICSE 2001/Java Layers

18. ACE Interface Width 20 24 15 66 5 5 13 13 10 27 3 4 Avg. JL Interface Width 1.5 1.8 2.4 1.7 1.3 No. of ACE Interfaces Timer 1 1 Queue 1 Task Reactor 1 1 Acceptor 1 Connector No. of JL Interfaces 1.5 Re-Engineered Interfaces 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 ICSE 2001/Java Layers

20. I - Usability JL’s narrow interfaces reduce complexity • 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 ICSE 2001/Java Layers

21. II - Starter Kit Flexibility JL avoids overfeaturing • Frameworks segregate code • Framework code vs. application code • Tradeoff: overfeaturingvs. 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 ICSE 2001/Java Layers

22. III - Starter Kit Scalability JL scales well as new features are added • 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 ICSE 2001/Java Layers

23. Original Tree A A New Subtree B’ B C’ D’ C D IV - Framework Evolution • Need to change a framework’s core classes • But prevented by compatibility constraints Framework Hierarchies are Fixed ICSE 2001/Java Layers

24. Mutable parent/child relationships A A Class substitution B’ B C D C D The Flexibility of Mixins • Adding new mixins is usually non-disruptive • Classes can be substituted, inserted and removed Mixin Hierarchies are Flexible 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 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 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 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 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 ICSE 2001/Java Layers

30. THE END Think Layers ICSE 2001/Java Layers

31. class TaskBase implements TaskIfc { propagate TaskBase(ThreadMgrIfc tm){…} …} class TaskQueue<T implements TaskIfc> extends T { propagate TaskQueue(MsgQueueIfc mq){…} …} Example: Constructor Propagation • Initialize all classes in a mixin hierarchy • Adjust subclass constructor signatures TaskQueue<TaskBase> constructor takes ThreadMgrIfc and MsgQueueIfc parameters ICSE 2001/Java Layers