Mini Process Steps

MVC Exercise - Mini Process Steps

A process can greatly help accomplishing something. We use the Mini Process. Here we apply it, with discussion. The steps we use are:

Requirements:

1. Nutshell Vision - Sentence or paragraph capturing the pure essence and goal.

2. Narrative - Describes what the system must do, key features, issues, etc.

3. Use Case List - A list of the Use Case names the system must satisfy.

4. Major Use Cases Stepped Out - List all steps for crucial or fuzzy Use Cases.

Design

5. Modeling - Conceptual Model, Class Diagram or other types.

6. Implementation Plan - A series of steps to implement the model(s).

Implementation Iterations with Concurrent Testing

7. Implementation - Often with elaboration of above steps per iteration.

8. Automatic Regression Test - Or whatever other type of test you prefer.

1. Nutshell Vision

A "Three Door Game" player that allows multiple games to be played simultaneously, by human or automated players, and shows the running score.

Discussion - Note how we capture the essence of the system in one clear sentence. This focuses our work.

2. Narrative

The game player should present two visual "Game Windows", each of which is a complete game. A Game Window has three doors, a button to open each door, and a running score showing the total won, lost and percent won. When a game starts, all three doors are closed. The user then clicks on one door button, and that door is shown as "selected". The host then opens one of the other doors, revealing the goat. The user can then click on the other unopened door to choose it, or they can keep their first choice. The user then clicks on Show Game Result. All unopened doors open and the score is updated. The user can then click on Start New Game, and the whole thing starts over, except for the running score which is maintained.

The better strategy can be determined by using strategy A on one window, and B on the other. The running score will quickly show what strategy is best.

Our company has a high reuse policy. Build this system with only one Controller, one Model and One View class. In the actual system, use one Controller, two Model and two View instances. Hint - One Controller instance requires a way to tell what View was the event source, so that the correct Model instance can be mutated.

Discussion - A good narrative proves the analyst understands what the system should do. Most developers have trouble with this, except in domains they are familiar with. Train yourself to be able to interview a customer and write up a narrative in any domain. After all, from the perspective of the Mini Process all domains are the same, because they can all be produced using the same process steps.

Note how this narrative has missed the "automated" feature mentioned in the Nutshell Vision. The developer will later discover this, and return to modify the Narrative.

3. Use Case List

1. System Startup (All systems have this Use Case, so list it first)

2. Play a game.

3. Stop playing (aka System Shutdown, which all system have)

4. Major Use Cases Stepped Out

There's no one right way to do this. Here's what the JSL Study Group came up with at their 1/6/00 meeting, and slightly revised at their 3/2/00 meeting:

UC1 - StartUp
- On Command line - Main of Mediator - call Mediator.start()
- Create Mediator, which does the following:
.... Create 2 Models
.... Create 2 Views
.... Create 1 Controller
.... Provide configurable data to all parts.
.... Establish relationships
.... Display 2 Views and Start new game in each

UC2 - Play Game
- Start new game
.... Unselect all doors
.... Close all doors
.... Place the car randomly
-. User selects a door. (A)
.... Click on a door button
.... System shows selected door
.... GameshowHost selects unselected goat door
(Note - System needs to track whether this is case A or B)
-. User is given a choice.
.... User optionally selects the other unopened door (B)
.... System shows the newly selected door
-. User clicks on Show Game Results.
.... Update running score (first, to avoid obliterating state needed to determine win)
.... System will open all unopened doors
- Go to Start new game.

UC3 - End Game
.... User indicates he wants to Exit.
.... Question - "Do You really want to Exit ? Yes/No"
.... If Yes - System Exits
.... else do nothing

UC4 - Full Regression Automatic Test
....(later)

Discussion - There were 10 people at this meeting. We divided up into groups of two, to each work on building the system using the Mini Process. Most groups had the classic problem of rushing into design (the Modeling step) before completing the analysis with Use Cases. As a result, they did not deeply understand the system and so there was lots if confusion about what a good (or even an adequate) design was.

Therefore the groups went back to reading the Narrative, doing the Use Case List and stepping out the major Use Cases. As they did this, little light bulbs started popping on as people suddenly understood the requirements enough to visualize the solution.

The technique of closely reading the Narrative and underlining potential Use Cases proved to be the most efficient way to go. It was amazing how may people could not produce any or many Use Cases at first. But once we showed how to read and underline, out popped all the Use Cases. Wow!

Since most were new to Use Cases, we stepped them all out.

5. Modeling

The next step is Modeling. Give it a try on your own. Start with a Candidate Class List. Mine the above for candidates. Start the model. Establish relationships as your go unless not clear. Once you've got your classes and relationships, fill in the methods. You can also fill in the key methods as you go, but be sure to eventually fill in all methods. Validate your model by walking through all Use Cases to ensure they are well supported. Here's the model:

This was done using Visio 5.0c. Here's the Visio zip file for those wanting to start with that for their own further development.

Starting with Use Case 1, System Startup, we added the Model, View and Controller. Then we added the ViewEvent and ModeEvent. Then we added the arrows connecting them all in a circular flow. This was our mini-architecture for the model.

Then we added the fields, methods and interfaces necessary for the Startup Use Case to work. We now had all classes and the most important methods.

Then starting at the beginning of the Play Game Use Case, we added more fields and methods one step at a time. Eventually we discovered that the Model needed a State Machine to allow clear, correct, easy design. So we stopped and drew up the State Transition Table for the Model. Later, at home, Jack drew up a State Transition Diagram (below), but as you can see it's very simple, and the table suffices. This is where we stopped.

For those doing this exercise, the next step is to complete the model. The Model class is the place to start, since it's incomplete due to the discover of the need for a State Machine.

Here's a diagram showing the Game Panel design. This can be very simple. There's one of these per View window.

After the model, do an Implementation Plan. This should list your implementaiton iterations, and what will be done in each iteration. After that, do the implementaiton if you wish, but that's getting ahead of the horse. All you need to do for the next JSL meeting is to have a really good Mini Process all the way up to and including the Implementation Plan. After all, if this is done well, implementaion is trivial. :-)

6. Implementation Plan - A series of steps to implement the model(s).

1. Mediator main() and start(), print "started". (done)

2. Add Controller.processViewEvent() and ViewEvent. Print "Event (eventType) received". (done)

3. Add Model, ModelEvent, ModelListener. Complete Controller for Model. The rest of Controller.processViewEvent() comes later gradually. (done)

4. Add ViewListener, View, (GUI only) unit test. Make View.addViewListener() print "listener added". (done)

5. Have View handle ModelEvent, including showing "goat" or "car", and "selected", and running score. (done)

6. Have View emit ViewEvent. (done)

7. Complete Controller for processViewEvent(). (in progress)

Note - We should have itemized the event types for a trivial implementation.

8. Improvements:

A. Use passed constants for "Car" and "Goat" in View.
B. In View.processViewEvent() use getModelForID() for all cases.
C. Put View.NUMBER_DOORS elsewhere, such as Mediator with setters.
D. Remove business logic from Model, such as startNewGame().

7. Implementation - Done iteratively using the above model and Implementation Plan.

Note - In the interest of time we will do the automatic regression test on our next project.