State Application Using MVC

Transcription

1 State Application Using MVC 1. Getting ed: Stories and GUI Sketch This example illustrates how applications can be thought of as passing through different states. The code given shows a very useful way of decomposing an application into classes which separate the core logic of the main objects from the details of the human computer interface. First we begin with a simple description of what the application should do using the idea of user stories to express the requirements (from Extreme Programming). The initial set of stories is as follows. a. The program should have 4 distinct states., and 2 intermediate states. b. The user may navigate between states by using 2 buttons, Next and Back. c. The interface will visually provide feedback about the current system state. Note that this example is simple and rather abstract. More realistic stories would make sure to clearly show customer value - states might correspond to screens visible to the user. Often state information is held in variables explicitly for that purpose. Clearly tracking the state of an object can clarify design issues and make the software easier to code and understand. Notice that stories are small and lack many details. The idea is that a customer is readily available for the development team to meet with to work out the details. In this example we will assume all the stories should be implemented for this iteration. The first code that should be written (aside from a spike if necessary) are the tests which help to define what your objects should do. A brain storming session with the client helps to fill in some details. Techniques like paper prototyping ( )can help the team communicate and to understand requirements through a hypothetical interface. Figure 1 shows an early design idea for the application s Graphical User Interface (GUI). Figure 1: Sketch of application's proposed graphical user interface (GUI). State 1 State 2 Back Next 2. Establishing the core logic - focus on the Model Sometimes it is hard to think about the basic objects when all you can imagine is the sketch of the GUI. However, it is commonly recognized, that the GUI and the underlying functionality are most often better implemented as separate but cooperating objects. The underlying functionality (often referred to as the model) is independent of the particular GUI used to represent and manipulate it. This follows the Model-View- Controller paradigm (see Figure 2). We can develop the model separate from the interface. This better allows

2 porting to different window systems, development of GUI s by trained GUI designers, clearer coding of business logic, etc. There are two immediate advantages for us: 1. Development can proceed without needing to know GUI programming; 2. Unit tests are much more easily focused and automated if you don t need to worry about the GUI. Thus we focus first on the model component. This object should be able to represent the states required. It should have methods that allow the view and controller to communicate user manipulation requests and to respond to state queries. The model class for our example is StateModel. Development with Extreme Programming would begin by writing tests which will help drive the design of the model. These tests would also act as documentation on how the model is expected to work and confirm that behavior of the model code is correct. The test and code-to-pass-test cycle is very tight, sometimes occurring in just minutes. An example test is given in Figure 3. Figure 2: Application uses MVC paradigm. StateModel created with test driven development. Tests testinitialstate testbasicnavigation... attributes methods{ Model Core objects and business logic/data StateModel curstate: keeps current state getstate: returns current state nextstate: go to next state backstate: go back one state What is the current state? Model Answers User wants to move Next GUI View Presents the model to the user Controller Interprets user requests to interact with model. Makes sure view reflects current model state. public void testbasicnavigation() { StateModel model = new StateModel(); assertequals("next to State1", StateModel.STATE1, model.getstate() ); assertequals("next to State2", StateModel.STATE2, model.getstate() ); assertequals("back to State1", StateModel.STATE1, model.getstate() ); // move to state2 // move to finish assertequals("next to ", StateModel.FINISH, model.getstate() ); assertequals("back to State2", StateModel.STATE2, model.getstate() ); Figure 3: A test for typical navigation behavior using backstate and nextstate methods. Note: Tests should be independent of each other. Do not assume any particular execution order of tests.

3 To be clear, testing and coding goes back and forth very quickly and is done by the same programming pair. Here we have skipped several steps of Test Driven Development to show you some code examples. The code shown does not necessarily represent final code but is a snap-shot of the code at a given time. Code can be continually refactored to improve its design. The source on the next page is an example of how the GUI might be coded in Java. It also shows how the model code is hooked into the GUI. A specialized view class displays the model s state. Recall the draft of interface to the model. Back State 1 State 2 Next The application won't be complete unless it can visualize what the current state is. To respond to user requests, the buttons also need to be hooked up. The GUI code that realizes the following Java Swing interface is given on the next page. Java source to define the StateModel class // StateModel package stateexample; public class StateModel { static final int START = 1; static final int STATE1 = 2; static final int STATE2 = 3; static final int FINISH = 4; private int curstate; // Creates a new instance of StateModel public StateModel() { curstate = START; public int getstate() { return curstate; public void nextstate() { if (isnextok()) curstate++; public void backstate() { if (isbackok()) curstate--; public boolean isnextok() { if (curstate < FINISH) return true; else return false; public boolean isbackok() { if (curstate!= START) return true; else return false;

4 package stateexample; import javax.swing.*; import java.awt.*; import java.awt.event.*; public class StateApp implements ActionListener { JButton nextbut, backbut; StateModel model; StateModelViewer view; public StateApp() { model = new StateModel(); public void actionperformed(actionevent ae) { if ((JButton) ae.getsource() == nextbut) else updategui(); public static void main(string[] args) { javax.swing.swingutilities.invokelater( new Runnable() { public void run() { createandshowgui(); ); private static void createandshowgui() { JFrame frame = new Jframe( "StateApp w/view Class"); frame.setdefaultcloseoperation( JFrame.EXIT_ON_CLOSE); Container cont = frame.getcontentpane(); StateApp app = new StateApp(); app.buildgui(cont); frame.pack(); frame.setvisible(true); package stateexample; import java.awt.*; import javax.swing.*; public class StateModelViewer extends JPanel { static public final String[] statename = {"", "State 1", "State 2",""; static public final int START_ID = StateModel.START; static public final int NUM_OF_STATES = statename.length; protected JLabel[] stateindicator; protected StateModel model; public StateModelViewer(StateModel m) { model = m; buildgui(); updategui(); protected JLabel initindicator(int stateid) { JLabel lab = new JLabel(stateName[stateID]); lab.sethorizontalalignment(jlabel.center); return lab; public void buildgui() { setlayout(new GridLayout(NUM_OF_STATES, 1)); stateindicator = new JLabel[NUM_OF_STATES]; for (int id = 0; id < NUM_OF_STATES; id++) add(stateindicator[id] = initindicator(id)); public void updategui() { int thestate = model.getstate() - START_ID; for (int id = 0; id < NUM_OF_STATES; id++) { stateindicator[id].settext( makestatetext(thestate == id, statename[id])); public String makestatetext(boolean highlight, String name) { return (highlight)? ">>>" + name + "<<<" : name; public void buildgui(container cont) { nextbut = new JButton("Next"); nextbut.addactionlistener(this); backbut = new JButton("Back"); backbut.addactionlistener(this); JPanel buttonpane = new JPanel(new FlowLayout()); buttonpane.add(nextbut); buttonpane.add(backbut); cont.setlayout(new BorderLayout()); cont.add(buttonpane, BorderLayout.SOUTH); view = new StateModelViewer(model); cont.add(view, BorderLayout.CENTER); updategui(); // update GUI display from model public void updategui() { view.updategui(); nextbut.setenabled(model.isnextok()); backbut.setenabled(model.isbackok()); public StateModel getmodel() { return model; Note the convention of buildgui and updategui. The onetime creation of GUI components is done in buildgui while updating the GUI with data from the model is done in updategui. Notice how buttons can be enabled/disabled based upon the state of the model. This can be done to prevent improper actions from being attempted. The model is directly consulted to avoid making assumptions about how the internal logic works

5 For objects with nontrivial behavior, it is often useful to consider the states that it may go through. This behavior can be represented as a state machine. UML (Unified Modeling Language) often used for for designing and specifying software systems, has a graphical notation for state machine diagrams. A state machine diagram for the example program is given below. marks the starting point marks the termination point Arrows show transitions between states. State transitions are triggered by events. Here the events correspond to user pressing on the buttons back and next. For more specificity, transitions can also be restricted by guard conditions and a list of actions which should occur can also be given. Sometimes choice, or transitory, nodes are used to determine conditions on the fly. These states are shown as diamonds. Priorities may also be indicated to make transitions unambiguous. States may also contain substates. A History node can be used to remember and return to the current substate when a node is exited and then re-entered. Below is a diagram for a two player game. White starts first. Transitory states evaluate moves to see if they are legal and/or finish the game. Asking for help during the game goes to the instructions state returning to the current state of the game when the instruction state is exited. Quitting by the close window event is available from any state. In reality, the implementation of this system will likely involve multiple objects. Model handles game states, controller logic handles application states. State1 State2 close window White's turn Black's turn 1: [invalid move] white moves black moves 1: [invalid move] 2: [game over] 2: [game over] H H Game Over Instructions help Okay close window