This question allows you to draw together much of the material that has been covered in M257. It may help you to complete Activities from Units 8 and 9 before beginning and you are strongly advised to complete Activities 9.6, 9.8 and 9.9.
The purpose of this question is to develop a small application driven by a graphical interface that incorporates aspects of collection classes, event handling, and client–server programming, with threading providing the ability for the server to cater for multiple clients concurrently.
The most important feature to implement is the client–server interaction using threading. After you have the client–server interaction working well, you should add a simple graphical interface. You are allowed to use the NetBeans GUI builder for this graphical interface, if you want to. Use of the NetBeans GUI builder is described in the NetBeans Guide.
You are provided with two skeleton projects, TMA03Q3Client and TMA03Q3Server, both based on Activity 9.6.
TMA03Q3Client contains the following classes:
TMA03Q3Server contains the following classes:
First run the server project and then the client project, to see that the client and server establish a connection and that the client receives a single message from the server. At the moment the server message is set to "Hello client. This is the server." After this interaction (the server sending and the client receiving the message) the client and server programs both exit. This interaction is performed by the processHello methods on the client and server sides.
Note that throughout this question we refer to an interaction as a high-level operation that can be represented by methods such as processHello on the client and server sides. In other words, an interaction represents some useful communication between the client and server within a particular scenario.
Your first task is to choose a concrete scenario that interests you for your client and server programs to implement and to describe how the client and server interact in terms of what we will call their protocol.
For example, the NameServer in Activity 9.9 and Section 8.1 of Unit 9 represents a name server scenario and understands two kinds of interactions in its protocol, which we might call quitting and retrieving. Quitting terminates the client and server programs, and retrieving allows the client to retrieve an email address associated with a name.
The client and server interactions are represented using strings. For example, the string referenced by CLIENT_QUITTING represents that the client is ready to perform the quitting interaction. The communications between client and server are themselves also strings.
In the same way, you will need to decide how to represent the different kinds of interactions that can take place between your client and server.
The scenario you choose must not be one that has already been presented as a specific example in M257 itself.
For example you might be interested in:
You may want to develop your own extra classes relating to your specific example, such as an Athlete class or a Password class.
It is possible to have less serious applications – for example a guessing game such as MasterMind – but you are advised to keep the scenario quite simple and to remember that marks are awarded for meeting the requirements.
In terms of the interactions supported by your scenario we are leaving the details up to you, with some conditions:
You are not constrained by the provided skeleton code: you should employ techniques such as creating helper methods, renaming class members, documenting your code and possibly making use of inheritance and composition, if they make sense within your application. However, you must not rename the projects themselves or the classes that start the client and server programs.
We recommend that you encapsulate the sending and receiving behaviour on the client and server sides; for example, it is likely that you would want to write a single method on the client side that retrieves all the output for an arbitrary interaction.
To some extent, the collections that you choose will suggest the kinds of interaction that could occur between the client and the server – and therefore the scenario that you are coding for – so you might like to think about this first. We elaborate on this below:
A Map provides a way of associating one value with another. Possible examples of such mappings include:
A List provides a way of ordering items that belong together for some reason. Possible uses of a list include:
A Set provides a way of maintaining a group of items that are unique according to some criteria. Possible uses include:
For any collection, interactions to add or remove items may be useful.
You are not limited to using one collection type. Remember also that your chosen scenario should be concrete, as specified at the start of part (a).
Your description should allow your tutor to understand the kinds of interactions understood by the client and server and should be detailed enough for your tutor to use it to test-drive your program. Here is an example of a row from a protocol table to show the level of detail required. We have used an imaginary interaction called FlipFlop. You may prefer to have separate columns for client and server method names. See image.
Note that in the example the client and server method names are based on the interaction name, and that the same name is used on the client and server sides. We recommend that you do the same as far as possible, although there need not be a one–to-one correspondence between methods on the client and server sides. You need only mention the top- level method in each case here. (The top-level methods may in turn rely on helper methods.)
Notice also that in describing the server’s action we assumed that the client and server had already determined that doFlipFlop was required. In practice, at a higher level, both sides may need to determine which interaction is required. You should explain how this takes place in part (a)(i).
As part of your protocol, you are strongly advised to have the server send a signal (such as a special string) to the client at the end of every interaction so that the client knows it has received all output expected for that interaction.
Once you have chosen a concrete scenario, start completing parts (a)(i) and (ii). You will probably want to return to these parts to refine your description as you begin developing your code.
You now need to develop your client and server classes in accordance with your chosen scenario and protocol. When you have completed your coding, copy all classes that you wrote or altered to your Solution Document. For classes that you altered, clearly indicate any changes that you made using highlighting or a similar technique. Write down any issues you have with running your code, particularly if you haven’t managed to complete it to your own satisfaction.
In this part you should develop a simple graphical user interface that supports the interactions in your scenario. You should include a screen shot of your interface in your Solution Document under part (a)(i) and in this part briefly explain its functionality and how you went about creating it. It is not important to create a beautiful interface and there are no marks awarded for aesthetics, but the interface should be understandable, readable and usable. You may use NetBeans visual GUI builder if you wish to, or code the interface by hand. You can work from the Activity 9.9 client GUI as a starting point if you wish. You are advised not to spend too much time developing the interface, unless it is for your own pleasure. You need not copy GUI code to your Solution Document, but you should explain to your tutor where to find it in your NetBeans projects.
Summary of required functionality and description of your programs: