Architectural Patterns for Interactive Software

1. Architectural Patterns for Interactive Software Yonglei Tao School of Computing and Info Systems

2. Interactive Software Design • Application data and logic • Relatively stable • Look and feel • Support multiple views • Evolve in response to changes in requirements, user profiles, display and interaction mechanisms, and … • Desirable properties for software design • Data & logic – reusable • Look & feel – extensible, pluggable

3. Model-View-Controller • A common structure for interactive applications • Originally intended for applications with multiple views for the same data • Benefits • De-couple domain objects from user interfaces • Reduce complexity • Support reuse • Allow separate development

4. Model, View, and Controller • Encapsulate fundamental abstractions for interactive applications • the model maintains application data • the view is responsible for its visual presentation • the controller handles events for views

5. An Example • Model – class Counter • int Value • setValue(), getValue(), inc(), and dec() • View • Shows the current value of a Counter • Controller • Determines what the user wants to do

6. Design Issues - Dependencies View Screen 1..* update() getValue() 1 Model 1 1..* inc() Controller Mouse

7. The Observer Pattern • Problem • A subject is observed by several observers • When its state changes, all observers are notified and updated to reflect the change automatically • How to handle such a relationship? • One to many • Two-way dependency

9. A MVC Example

10. // CounterModel.java - an Observable class for a counter import java.util.Observable; public class CounterModel extends Observable { private int value; public CounterModel () { setValue( 0 ); } public int getValue () { return value; } public void setValue (int newValue) { value = newValue; setChanged(); notifyObservers(); } public void inc () { setValue( getValue() + 1 ); } public void dec () { setValue ( getValue() - 1 ); } public void reset () { setValue ( 0 ); } }

11. /** CounterView.java - an Observer class for a counter */ import java.util.*; import java.lang.*; public class CounterView extends JFrame implements Observer { private CounterModel theModel; public CounterView(CounterModel model) throws NullPointerException { initComponents(); theModel = model; theModel.addObserver(this); } private void initComponents() { … } // automatically generated private void incButtonActionPerformed(ActionEvent evt) { theModel.inc(); } private void decButtonActionPerformed(ActionEvent evt) { theModel.dec(); }

12. private void resetButtonActionPerformed(ActionEvent evt) { theModel.reset(); } private void exitButtonActionPerformed(ActionEvent evt) { System.exit(0); } /** update the display with the current value of the counter */ public void update (Observable observable, Object obj) { valueLabel.setText(theModel.getValue() + ""); } public static void main(String args[]) { java.awt.EventQueue.invokeLater(new Runnable() { CounterModel model = new CounterModel(); public void run() { new CounterView(model).setVisible(true); } }); } private JButton decButton, exitButton, incButton, resetButton; private JLabel labelForValue, titleLabel, valueLabel; }

13. Discussion • Any potential flaws? • Alternative solutions? • How to handle this situation given below? • Account is a subclass of an existing class

14. Swing MVC • A special version of MVC • Meant to support pluggable look and feel • Each lightweight component comprises objects • A model • Maintains a component’s data • A UI delegate • Includes a view with event listeners • A component that extends JComponent • Provides an API for programmers

16. Visual C++

17. The MVP Pattern • Model-View-Presenter • model - application data and logic • view - displaying data from the model and routing events to the presenter • presenter - coordinating model and view

18. Dependencies

19. How to Define the Classes class MyModel {   … } class MyView extends JFrame { private MyPresenter presenter; public void setPresenter(MyPresenter presenter) { this.presenter = presenter; } public MyPresenter getPresenter() { return presenter; } void updateViewFromModel() { … } // optional void updateModelFromView() { … } // optional … }

20. class MyPresenter { MyModel model; MyView view; public void setModel(MyModel model) { this.model = model; } public MyModel getModel() { return model; } public void setView(MyView view) { this.view = view; }  public MyView getView() { return view; } … }

21. How to Establish the Dependencies public class MyApplication { public static void main(String args[]) { MyModel model = new MyModel(); MyPresenter presenter = new MyPresenter(); presenter.setModel(model); MyView view = new MyView(); presenter.setView(view); … } }

22. Consequences • What would be the potential benefits of using the MVP pattern? • Facilitate automatic unit testing • Allow separation of concerns • Various implementations • Examples of its use • The .NET environment • Google Web Toolkit • The Biscotti framework for Java SE

23. The PAC Pattern • Presentation-Abstraction-Control • An application consists of several cooperative agents • An agent is responsible for a specific aspect of the application’s functionality • Presentation ≈ View + Controller of MVC • Abstraction ≈ Model of MVC • Control mediates between Presentation and Abstraction and communicates with other agents

24. A Hierarchical Structure • Support for complex interactive applications in form of a hierarchy of cooperating agents

25. Consequences • Complete separation of Presentation and Abstraction to support multi-tasking • Easy to plug-in a new agent or replace an existing one • Increased system complexity and overhead