The Fundamental Themes of CS

1. Java Power ToolsModel Software for TeachingObject-Oriented DesignRichard RasalaJeff RaabViera Proulx{rasala,jmr,vkp}@ccs.neu.eduhttp://www.ccs.neu.edu/teaching/EdGroup/JPT

2. The Fundamental Themes of CS • Information • Algorithmics • Encapsulation • Interaction • Languages • Formalism • How do we weave these into our teaching?

3. Encapsulation is Critical • Without encapsulation, algorithmics can only be applied in relatively small programs • Without encapsulation, it is impossible to do: • Robust input-output • Graphical user interfaces • Large scale software development • Encapsulation must be a central focus in the computer science curriculum

4. What About Java? • Java is interesting for CS because • Java provides great graphics and image handling which enables visually interesting student assignments • Java Swing provides the raw components for building a graphical user interface • Java works in an event-driven multi-tasking manner and provides access to threads • Java collects garbage • If Java only provided garbage collection but not the rest it would not be as interesting

5. Problems with the Java Libraries • Java Swing is a great improvement over AWT • However Java Swing is still a bucket of tools • Using only what is provided in Java Swing, it takes many lines of code to produce even the simplest interfaces • In effect, Java is the assembly language of GUI building: All the elements are there and some macro capabilities exist but by and large you have to build it yourself

6. Pedagogical Consequences • If students need to code interfaces manually: • they will need to learn many technical issues that are not a priority from the CS viewpoint • they will be inhibited from experimentation with their interface designs because the cost of change is too high • they will usually not create very good interfaces • they will get the message that the principles we preach about abstraction and encapsulation may be good for algorithms but when it comes to GUI building things are just a mess

7. What is the Solution? • Toolkits! • The task of building graphical user interfaces should be examined with the same attention to detail and elegance as the algorithmic and data components of the internal model • Encapsulation should be used to create a set of GUI tools that can be used easily, rapidly, and flexibly • Principle: As close to Java as possible but no closer!

8. Shouldn’t we stick to pure Java? • Why? • Isn’t it the purpose of education not just to teach for today but to push the envelope so students are prepared to think and work in the future? • Isn’t it the purpose of education to provide a vision of how things might be and to show what processes of thought can lead us there? • So: As close to Java as possible but no closer!

9. The Java Power Tools (JPT) • Based on an MVC architecture • Fundamental Principle: Think abstractly and recursively! • Models are constructed in layers and so can be seen as recursive • Views are constructed by nesting and so can be seen as recursive • The communication between models and views should be as automatic as possible

10. The “3 Statements” Ideal for JPT • The use of a view in JPT should “ideally” require just 3 program statements • 1: Construct the view • 2: Place the view somewhere in the interface • 3: Send the user data in the view to the model • Consequently, to use N views in an interface should require approximately 3*N statements

11. OK, Sometimes “6 Statements”... • 1: Construct the view • 1*: Modify some parameters of the view • 2: Place the view somewhere in the interface • 2*: Modify some aspect of the panel layout • 3: Send the user data in the view to the model • 3*: Send the model data to the view • It is actually rare that these “extra” statements are needed so the general estimate of roughly 3*N program statements is still fairly accurate.

12. Leveraging Composite Views • It is often useful to build composite views as new view objects • Time is required to build these composites but that time is amortized by the reduction in effort needed when the composites are used in the program • The most powerful composite built into JPT is the ArrayPanel that automates the building of dynamic arrays of views

13. Strings & Model-View Communication • Tim Berners-Lee comments on his choice of text as the basis for web communication: • “I expected all kinds of data formats to exist on the Web. I also felt there had to be one common lingua franca that any computer would be required to understand.” • The String is the only universal mechanism for communication between computing entities

14. The 4 Fundamental JPT InterfacesFor Model-View Polymorphism • For Models • Stringable • For Views • Displayable • TypedView • GeneralView

15. The Stringable Interface • This interface applies to data models • Data is Stringable if one can encapsulate its state in a String • All data built in layers from the basic types is Stringable • The data in image or sound files is Stringable since one need only capture the file name not the detailed data • Stringable is naturally recursive

16. The Stringable Interface • public void fromStringData(String data) throws ParseException • public String toStringData() • A Stringable object should be able to built its entire state using fromStringData • A Stringable object should be able to capture its entire state using toStringData • Notice that we do not use the Java toString() method since Java uses toString() for different purposes.

17. JPT Support for Stringable • To support extending Stringable from the basic types to complex objects, the JPT provides encoders-decoders to handle the concatenation and extraction operations automatically • To support processing of numeric data, the JPT provides parser classes that include automatic arithmetic expression evaluation

18. The Displayable Interface • This interface applies to views • A view is Displayable if its user input can be encapsulated into a String • All views that use widgets whose user data can be expressed as String’s can recursively be interpreted as Displayable • Note that Displayable captures only the user input state not the full state of the view

19. The Displayable Interface • public void setViewState(String data) • public String getViewState() • public void setDefaultViewState (String data) • public String getDefaultViewState() • public void reset() • public void setEnabled(boolean isEnabled)

20. Designing with JPT • Build a data model out of Stringable objects • Determine what corresponding Displayable views should be used to input these objects • Determine the nested layout desired for the Displayable views • Keep in mind that nesting views is better than using complicated layout managers • Communicate between models and views via Data Model  String  Display View

21. Sample Communication Code • Model M • View V • M.fromStringData(V.getViewState()); • The only difficulty with this code is that the caller must handle the possibility of a ParseException in fromStringData

22. TypedView and GeneralView • TypedView is a Displayable that knows the type of the model object that the view is supposed to represent. • TypedView can therefore build a new model object by a factory method (using reflection) and encapsulate all error checking. There is then no need to deal with a ParseException. • GeneralView is a TypedView that can change its model type. Example: TextFieldView.

23. More JPT Interfaces • TypedView adds: • public Class getDataType() • public Stringable demandObject() • public Stringable requestObject() throws CancelledException • public void setInputProperties (InputProperties properties) • public InputProperties getInputProperties() • GeneralView adds: • public void setDataType(Class dataType)

24. More Sample Communication Code • Model M of a type that extends T • View V • Two options: • M = (T) V.demandObject(); • M = (T) V.requestObject(); • demand... insists that a user supply valid data • request... permits a user to cancel the input • Both options encapsulate error checking of the user data and have a robust error strategy

25. Example: Abstract Class ArrayPanel • The ArrayPanel class is an abstract class that encapsulates a view whose components can be increased or decreased in quantity at runtime by the user • A class that completes the implementation of ArrayPanel need only meet the TypedView interface and provide a factory method that builds the views for individual components

26. Actions and Buttons • Ordinary buttons do not supply inpot data but instead invoke actions ... it is the actions that matter not the buttons. • Actions can be encapsulated using the Action interface built into Java Swing • Create a button by passing an Action object to an ActionsPanel. The panel then creates the button and its listener in such a way that the Action is invoked when the button is pressed. • Moral: Encapsulate and hide event handling!

27. The JPT Console Interface • JPT has a fully featured console interface that supports robust and powerful input/output • None of the fuss of standard Java IO (such as exception handling) is necessary • The console interface can be used early in the freshmen year while basic concepts of objects are being taught • The console interface can prepare for the use of GUI’s and permit debug output if needed

28. The JPT and Dialog Boxes • The JPT provides support of input via dialog boxes • In practice, it is more convenient to use a full GUI or the console interface • It has turned out that in JPT the primary use for dialogs is in implementing automatic error recovery • The other main use for dialogs is in handling file selection

29. Frames, Panels, Graphics • JPT supports a “quick frame” factory method that builds a frame in one step • JPT defines a BufferedPanel that uses a buffer to fully automate graphics refresh for output graphics • Tools are provided to automate the world-to-image transform needed in most graphics applications • Tools are provided for mathematical plots

30. JPT Significance • User interfaces can easily be built with quite modest amounts of code • Because user interfaces are so easy to build a student can experiment with interface design • Students can learn JPT gradually keeping the main focus of a course on computer science • JPT and standard Java can be intermixed • JPT is open source ... there is no black box • Students can use JPT as a design model

31. JPT as a Design Model • JPT takes abstraction and recursion seriously. • The Stringable, Displayable, TypedView, and GeneralView interfaces provide excellent examples of the power of polymorphism. • Actions have a primary focus. Messy details of widgets and events are fully encapsulated. • All basic interface widgets are supported. • JPT uses factories, decorators, and wrappers extensively.

32. Design Solutions in JPT • The JPT represents a coherent solution to a number of recurring problems that occur in GUI design. • Individual classes in the JPT represent “best practice” in Java design as we have learned from our own experience and from the best professional Java texts. • Overall, the JPT shows how a well-planned design can provide enormous leverage in object-oriented GUI development.

33. The JPT Source Code • The JPT currently contains 91 classes with more than 400 pages of source code. • The code is written to highest professional standards for design, encapsulation, layout, naming, and Java docs. • The code has been refactored to maximize design orthogonality. • The code is formatted to be presented in a classroom setting at 16 point font.

34. The JPT as a Design Case Study • From its inception, the JPT has had two goals: • Enable students from the very beginning to create GUI programs with elegant code and minimal hassles • To provide a case study for object-oriented design • For students studying JPT, the question will be “How did they do this ...?”. They will find the answer in some of the best organized example code that is available anywhere.

35. Java Power ToolsModel Software for TeachingObject-Oriented DesignRichard RasalaJeff RaabViera Proulx{rasala,jmr,vkp}@ccs.neu.eduhttp://www.ccs.neu.edu/teaching/EdGroup/JPT