Note: this is a 2 for 1 lecture.
Tests
------------------------------------------------------------------
Open www.mbta.org.
There are two kinds of tests:
- unit tests (in your case, you're testing classes and methods)
- system or client tests
In good cases, you get the client to write the tests for you. Now
you're clients and you are going to design tests.
(1) Describe two test cases for the request to identify each
station with the line that it is on.
Easy. One case for staying on one and the same line. One for
switching.
(2) Describe three test cases for the request to minimize
switching lines for the travel advice.
One case for staying on the same simple line.
One case for the green line.
One case for switching at least twice.
Students present test cases as connections on the map:
from, to, plus lines.
Then have them translate these cases into calls to
search(String, String).
Then have them translate these cases into calls to
search(Node, Node).
Sequence Diagrams
------------------------------------------------------------------
When you describe a story (use case), you often need to discuss
the creation of objects, a sequence of method calls, call backs,
and so on. So far we have used plain English to do that, with
lists when needed.
If you need to discuss such things with customers or
co-developers, you should use a graphical notation, because it is
good for illustrating the sequencing of creations and method
calls.
UML provides several notations for this purpose. Collectively,
they are called Interaction Diagrams. We will use sequence
diagrams.
The Basics of Sequence Diagrams
----------------------------------------
A sequence diagram consists of objects and object life lines:
a View result: JList Controller theGraph
| | | |
| | | |
| | | |
| | | |
The vertical placement (often) indicates when the object comes
about, and the line represents the life span of the object.
A method call is just an arrow with appropriate annotations:
actionPerfomed()
--------------->
a View result: JList Controller theGraph
| | | |
| | | |
| r = notify(from,to)| |
|-------------------------> | search(from,to) |
| | | --------------> |
| | | |
| | | | ---+
| | | | | search(from,to)
| | | | | (Node,Node)
| | | | <--+
| | | |
This picture conveys the (one and only) sequence of actions that
we need to understand how the T program works. Something invokes
the actionPerformed() method on View. It notifies its listener
that something has happened. The controller translates this call
into a call to search(String,String) for theGraph. Finally,
theGraph calls itself, after translating the strings into Nodes.
actionPerfomed()
--------------->
a View result: JList Controller theGraph
| | | |
| | | |
| r = notify(from,to)| |
|-------------------------> | search(from,to) |
| | | --------------> |
| | | |
| | | | ---+
| | | | | search(from,to)
|m = | | | | (Node,Node)
|createModel() | | | <--+
|---> JListModel| | |
| | | | |
| | | | |
| | | | |
| setModel(m) | | |
|-------------> | | |
| | | | |
| | | | |
This extension shows how to create a new object, which is then
handed to a component of the layout.
Exercise: write up the diagram for XController.
An Example from Project 3
----------------------------------------
Let's look at the stories in the "Silly Game":
Story 1: Registering players:
Main creates and then registers players with the server.
player registration:
--------------------
Main Server
| |
| p = new() |
| -------------------------------> Player
| | |
| registerPlayer(p) | |
| ----------------> | |
| | |
Story 2: Playing a turn:
The server plays rounds until there are no more active players.
For each round, the server grants each player a turn. The player
can tell the turn to roll the dice or to skip, but only one of
three actions is valid. If the player object does more with this
turn, it is recorded as a cheater and eliminated from the
tournament.
Here is the plainest scenario: the player just rolls the die.
playing a turn (1)
------------------
Server Player Die
| | |
| t = new() | |
| ------------------------------> Turn |
| | | |
| takeTurn(t) | | |
| ----------------> | | |
| | roll() | |
| | ------------> | |
| | | d = roll() |
| | | ------------> |
| record(d) | |
| <-------------------------------- | |
| | | |
| return | | |
| < - - - - - - - - | --- the turn ceases
| | to matter |
| | |
| | |
This picture shows a callback interaction between a server, a
turn, a die, and a player.