[an error occurred while processing this directive]
Developing Interfaces with Communication Simulations
After software has been decomposed into modules and the general nature of
their services has been determined, there is still important work to be
done: precisely specifying the interface that each server module provides
for its clients.
For common languages like C and Pascal, this means specifying contracts for
the functions provided by server modules.
Abstract data types are good examples of this need.
A table abstract data type can be defined as a module that provides random
access to a collection of data using keys, but there are many ways of
defining a set of functions for adding, removing, and retrieving data.
For example, for removing a data entry, some designers prefer a single
function that does the removal if possible and returns a boolean value
indicating whether or not the removal was successful.
Other designers prefer two separate functions, one that returns a boolean
that indicates whether or not the remove can be done, the other does the
removal.
For the latter alternative, the removal function has a precondition that
the removal can be done, and the function should not be called when the
removal is impossible.
It is crucial that implementors of both clients and servers understand
the choices made with regard to these issues.
Otherwise, they will produce modules that appear to work correctly when
tested independently, but fail to work when tested together.
Failure to work out all of the details of module communication is one of
the most common causes of incorrect software behavior.
Working out the details correctly, but in a clumsy way, can also lead to
difficulty in implementing modules.
Thus it is important to take care in working out module communication.
However, human nature often gets in the way of doing a good job.
Humans are very skilled at communication.
They notice a lot of details about context that guide them in interpreting
information and knowing what to ask to get more information or to get
things done.
Humans are also good at using subtle context cues to overcome ambiguity.
By the time a person is twenty years old, they have about nineteen years of
learning about communication.
During this time, the more important skills are largely automated.
Therein lies the problem.
Things that we do automatically are easy to overlook.
Communication Simulations Overview
A communication simulation addresses the difficulty of recognizing things
that we do automatically.
A communication simulation is most effective with a team of four or more
people.
The simulation focuses on the communication between a client module and a
server module.
Two of the people play the roles of these modules.
One other person acts as an observer, watching for information passing that
violates the server protocols.
The fourth person makes notes about decisions made and situations where the
protocols fail to provide services needed by the client.
Starting Protocols
Before beginning a communication simulation, there must be protocols to
simulate.
For a starting protocols you can use a list of English questions and
commands that the client can give to the server.
The questions should have simple answers.
The server actions requested by commands should be simple from the client's
point of view.
Keep in mind that client questions and commands will not necessarily make
sense in all contexts.
Sometimes the client needs to ask one question in order to determine if it
is legitimate to ask another question or issue a command.
This indicates that the second question or the command has a precondition
that the client should satisfy.
For example, if the server module provides access to lines from a file,
then it makes sense that the client needs to check if there are more lines
before asking for one.
Communication Simulation Roles
- Client
The client role-player is responsible for asking questions and giving
commands to the server role-player.
This person should have a general sense of the kind of information and
actions that the client needs and a general understanding of where a
particular order is required and where order is not crucial.
The client role-player should not ask questions or give commands that are
not on the protocol list.
- Server
The server role player is responsible for answering questions and doing
bookkeeping involved in executing client commands.
This person should not pass out any information or change any bookkeeping
except in accordance with the protocols.
The server role-player should try to be a computer.
Sometimes the right answer is "That information is not available!" or
"Unable to comply!" or "Does not compute!".
- Observer
Since humans are playing the roles of client and server, it is possible,
even likely, that some information will be passed or commands given in
violation of the protocols.
The observer watches over the proceedings like a hawk, waiting to pounce on
these violations.
- Note taker
The note taker is responsible for writing down any problems that the group
is unable to resolve and to write down changes to protocols that the group
agrees on.
This person can also try to catch violations of protocols, but not at the
expense of taking notes.
Startup Context
Some client-server interactions do not make sense until other modules have
done some work.
For simulating communication between a particular client and server, you
may need to specify startup conditions.
These conditions should be written down - they have implications for other
modules.
Starting Over
Your first several tries at protocols are likely to be inadequate in some
way.
That's ok.
It is better to detect problems now than after you have invested a lot of
time writing code.
But what should you do if you find a problem in the middle of a simulation?
Start over?
Or keep on going?
You will need to use some judgement for answering these questions.
Usually, it is not necessary to start over from the beginning.
You can often just back up up a few steps rather than going back to the
beginning.
If this is done, take a little bit of time to make sure that server
bookkeeping is restored correctly.
If this is too difficult or confusing, then start over.
Evolution of Protocols
To use communication simulations effectively, you should plan on doing them
several times.
For the earlier simulations, use English commands and questions.
When you are comfortable that major problems have been addressed, you can
start thinking about the functions provided by the server and data types
needed for parameters and returned values.
At this point, give some thought to making it easier for the client to
avoid errors and making it easier to isolate client errors.
The time you spend now is likely to pay for itself several times over when
you get to implementation.
Once you have determined server functions and data types for their
parameters and returned values, you can apply communication simulations in
a different direction.
A simulation helps client algorithm developers to work out algorithms.
When this is done after the the protocols are finalized there is greater
benefit in that they know what functions they will be working with.
Benefits of Communication Simulations
Communication simulations have several benefits.
One of the most important is that they uncover aspects of the communication
between client and server that would normally be overlooked.
Without a careful process, it is too easy to miss the details of
communication that humans handle automatically.
While the primary aim of a communication simulation is to develop the
interface for the server, it also helps client developers.
After several rounds of simulations, the participants have a good sense of
what the clients are doing and what functions they will need to call to do
their job.
Finally, by focusing on client-server communication with minimal regard for
client or server algorithms, the simulations give designers an opportunity
to address issues that would otherwise be neglected: designing an interface
that helps clients avoid errors and that makes it easier for them to locate
the errors that slip through.
[an error occurred while processing this directive]