The Computing Project M450 SPD1

M450

Sample project description 1

Contents
Introduction to Sample project description 1 2
Acknowledgement 2

M450 Sample project description 1 3

1 Project title 3
2 Problem description 3
3 Project scope 3
4 Main sub-tasks of the project 4
5 Project life-cycle 5
6 Resources 6
7 Initial literature 6
8 Practical development work 7
9 Problems 7
10 Feedback 7
Appendix 1: Project Schedule 8
Appendix 2: Code for the ‘ServiceServer’ Communications System 9

You should read this document before starting TMA 01.

Copyright © 2008 The Open University WEB 98701 6

1.1
M450 Sample project description 1 page 2 of 12

Introduction to Sample project description 1

The main aim of this document is to give you a better idea of what an initial
project description might look like. When looking at this sample your primary
goal will be to learn how best to describe your project. However, you should
also aim to identify a number of what we consider to be important features
when first choosing and scoping a project.
 In the sample project, we have incorporated:
o a core task that employs familiar concepts and techniques which are
very clearly connected to earlier course(s), and
o an aspect that is innovative/creative and clearly demonstrates
independent learning by extending the knowledge and skills already
acquired.
(Competently executed projects that include only the familiar will, of
course, pass the course. Projects that go beyond the familiar are more
likely to feature work that attracts higher marks, even if they are not
entirely successful in this more advanced aspect of the work done.)
 Some projects have very clearly distinguishable sub-tasks with a fairly

obvious order in which they might be tackled; others could be

(re-) scheduled in a variety of ways. (The sample provided here contains

two elements that are rather different in this respect.)

The sample project is organised and presented in a way which would make a
plausible submission for TMA 01. Different approaches to presentation have
their own strengths and weaknesses in the light of the chosen project topic. We
want you to think carefully about the best way in which to present your own
project. Making reference to the assessment criteria for TMA 01 will also help.

Acknowledgement
The course team would like to thank Jeff Allen for his contribution.
M450 Sample project description 1 page 3 of 12

M450 Sample project description 1

1 Project title
A system supporting provision of dynamic services by incorporating negotiation
for service charging.

2 Problem description
Portable/mobile devices play an increasing role in new Internet applications.
Many of these devices need to download service related information when they
connect to a network. One model for portable dynamic service provision that is
‘on-demand’ and ‘personalised’ is for a server to charge for service provision
based upon some criteria, such as current demand or other aspects of mobile
context such as place, time, etc. One way to implement this model is for the
user of the portable device to configure their client so that it automatically
negotiates with the server for provision based upon the users’ own criteria,
such as cost, but also possibly including urgency.
This project aims to develop a portable software package that can be used to
download information over the Internet to a remote device where the
downloading is preceded by negotiation over the cost of the connection and
other details of the service.
The package will be developed in such a way that it will contain sub-systems of
reusable components. The package will be implemented in Java and these
sub-systems will be Java classes that can be easily integrated into larger
systems.

3 Project scope
There are a number of different aspects of this problem that could form the
basis of a project. One possibility would be a user-centred study to determine
the criteria people would wish to use when configuring their negotiating client.
A related study could take an information design perspective to develop the
user interface to the negotiation system. The problem of enabling devices to
negotiate automatically is not very well understood and there appear to be a
large number of approaches proposed, so another aspect of the problem is
developing the software that undertakes the negotiation. And, of course, there
is the task of developing the infrastructural software that allows mobile devices
to communicate and exchange information. Undertaking a project that tackles
all of these different aspects of the problem is not feasible for a number of
reasons, mainly time.
I propose to scope the project so that it addresses just two of the elements
above. This project will focus upon:
 developing the software that undertakes the negotiation, and
 developing the infrastructural communications software.
I have chosen these for a couple of main reasons:
It seems to me that the two are linked; in order to implement the first, I need to
have the infrastructure in place.
I am familiar with the task of developing the communications software and so I
can build directly upon my earlier studies. In particular, some of the code I
developed as part of my assignment to implement a simple client–server
system can be reused if I remove the elements that were specific to the
application required for that course.
M450 Sample project description 1 page 4 of 12

Developing the negotiation software is a fairly open-ended task. I can start with
a simple approach to negotiation and, time permitting, can then look at more
sophisticated approaches. As long as I make good initial progress, I’ll always
be able to call a halt, having been through one prototyping cycle.
I decided against the options which would have required me to involve users
as this would have made the project very heavily dependent on the co-
operation of others (without the users, it would be difficult to make any
subsequent progress).
Having decided to scope the project in this way, the final output or deliverable
from the practical work will be software that allows a mobile client to
communicate and exchange information with a server so that they can
automatically negotiate the provision of a mobile service and then initiate that
service.

4 Main sub-tasks of the project

The scoping statement has identified two main sub-tasks. In terms of providing
the working deliverable, the negotiation software depends upon the
communications software, but otherwise, they are distinct sub-tasks. Certainly,
the communications software should not depend in any way on the negotiation
system; it should treat it as any other service and simply exchange units of
information. This means that each of these two main sub-tasks can be
developed separately, each with its own cycle of analysis, design,
implementation and evaluation. There will be a final sub-task which involves
the integration of the two systems.

4.1 Sub-task 1 – Developing the communications software

For this strand of the project the main tasks/phases and their main outputs are:
1 Analysis of the needs of a client–server communications system capable
of supporting mobile services. This will lead to a simple model of the
client–server interaction, which I expect to be expressed in UML.
2 Design for the communication system which will take the form of a
specification of the necessary classes (including methods), and their
relationships.
3 Implementation of the communication system. This is likely to be done in
Java (it supports platform independence, which is important in mobile
applications, and I am familiar with it). The output will be a Java package
containing both the server and the client classes.
4 Evaluation of the communication system, which will require the
specification of a test protocol and the development of a very simple test
harness for passing messages and possibly files between client and
server.

4.2 Sub-task 2 – Developing the negotiation service

At this stage, I am much less clear as to what will be involved. I expect this to
become clearer as I do more reading in this area. Broadly speaking the main
tasks and outputs are likely to be:
M450 Sample project description 1 page 5 of 12

1 Analysis of the needs of a negotiation service. I expect most of this to

come from the relevant literature, rather than having to identify and
interview experts. It may be that there is some sort of general protocol for
negotiation, or this may depend on the approach to negotiation taken (my
reading so far suggests both as possibilities). The output is likely to be
some form of formal expression of the negotiation protocol (initiation,
sequence of messages, format and content of messages, etc.). At this
stage, I don’t know whether UML is the best way to represent the protocol,
but sequence diagrams seem to be good at representing communication
protocols between classes.
2 Design of the negotiation system needs to produce a specification of the
relevant classes. This is going to involve thinking about the format and
content of messages passing between the negotiators. A key part will be
the design of the reasoning/decision-making algorithm that will be used by
the client and server respectively (which may differ between them). This
will be represented as methods for the relevant classes and these can be
represented as pseudo-code.
3 Implementation of the negotiation system will also be done in Java. The
output will be a Java package containing both the server and the client
negotiation classes.
4 There will be some basic evaluation of the negotiation system components
during implementation but the main evaluation will take place as they are
developed. This evaluation of the negotiation proper will follow integration
of the two systems and so is treated as part of the third sub-task.

4.3 Sub-task 3 – Integration and testing

The intention is that the communication system is simply responsible for
passing information between client and server and so the integration of the
systems is not expected to be a complex task. Accordingly, the focus of this
task is the evaluation of the integrated system following a short phase in which
the implementation aspects of the integration are dealt with.
1 The integration will require the development of a straightforward means of
simulating the configuration of negotiation options for both the client and
the server.
2 The evaluation requires the development of a test protocol. This will have
two elements. The first is simply to assess the functionality of the
integrated system. The second, more interesting case is to examine the
performance of the negotiation systems representing the client and server,
respectively. The details of the tests used here will depend upon the form
of negotiation chosen for implementation and this will be decided following
a review of the literature on computer-based negotiation systems. If time
permits, it may be possible to compare the performance of alternative
negotiation strategies.

5 Project life-cycle
The two distinct parts of the project seem to deserve different approaches.
Having developed an application very similar to the client–server
communication system for one of my earlier courses, I know I can reuse much
of what I did there and I have a high degree of confidence that this will be
straightforward. Accordingly, an approach that was more elaborate than the
classic Waterfall model would overly complicate matters. (Of course, there may
be a need to make a few iterations back and forth between stages, but there
seems no need to plan for these.)
M450 Sample project description 1 page 6 of 12

The task of developing a negotiation system is much less clearly defined and it
is largely new territory. That said, on the basis of the small amount of reading
I’ve done at this stage, it feels as though it should be possible to develop a
basic approach to negotiation as a first step and then to look at more complex
negotiation protocols after this. This suggests developing an initial prototype
which is then iteratively developed.
Having scoped the project so that it didn’t focus on users, the user-centred life-
cycles don’t really fit well. The Star model gives prominence to evaluation,
which would fit, but once the basic negotiation protocol is developed, there is
no real need to revisit requirements, task analysis, etc. The ID model seems
better fitted to situations where one is trying to minimise the gap between a
design and what a user wants from a demonstration system, which at this
stage, is not the motivation for iterating over a number of alternative
negotiation protocols (although that might come later when users are involved).
An incremental project life-cycle involves developing and then extending a
basic system, adding features/functionality as one goes. This seems a good
way to consider how the two major sub-systems can be developed: first the
communication system, then the negotiation system. In this instance, the
groundwork for the negotiation system requires finding, reading and
comprehending some research articles or texts on computer-based
negotiation. This can be done at the same time as developing the
communication system. There is probably scope for running more parts of the
two sub-tasks in parallel, but getting the first out of the way at the earliest stage
will give me at least one project deliverable, just in case things go wrong later
on.
In light of the above, I propose to combine two project life-cycles, using a
Waterfall approach for the first task and switching to an iterative prototyping
approach for the second development phase.
A draft schedule has been developed (Appendix 1).

6 Resources
No additional software or hardware is needed beyond the standard course
hardware and software packages supplied by the OU for my previous courses.

7 Initial literature
The following provide support material for the communications software:
Comer, D.E. (2000) Internetworking with TCP/IP Vol.1: Principles, Protocols,
and Architecture, 4th edn, Prentice Hall, ISBN 0130183806.
Hughes, M., Shoffner, M. and Hamner, D. (1999) Java Network Programming,
2nd edn, Manning, ISBN 188477749X.
http://www.omg.org (Accessed 1 December 2007). Website of the Object
Management Group – contains links to UML pages.
http://www.faqs.org/rfcs (Accessed 1 December 2007). A source of RFCs and
other Internet-related documents.
I am using the text Internetworking with TCP/IP Vol.1: Principles, Protocols,
and Architecture as a primary source of information relating to the Internet and
the various standard protocols that are used. This text provides coverage not
only of the protocols themselves but also examples of how these protocols can
be implemented. The advantage of this text is that it covers not only the
standard Internet protocols but also the use of the Java networking and I/O
APIs.
M450 Sample project description 1 page 7 of 12

This text has given me a good understanding of the IP transport protocols TCP
and UDP. I will need this understanding of how the UDP protocol is used for
my project. I will get insights into the techniques that can be used by studying
the protocols such as Finger DNS and HTTP that are discussed in this book.
When I come to the implementation stage of the project I expect the practical
approach adopted here will be very useful in helping me develop a robust
application.
So far, my starting point for looking at negotiation is:
Faratin, P., Sierra, C. and Jennings, N.R. (1997) ‘Negotiation decision
functions for autonomous agents’, Int. J. of Robotics and Autonomous
Systems, 24(3–4): 159–182.
This gives a good introduction to basic agent negotiation. The more advanced
material in this paper is beyond what I expect to be able to incorporate into the
project.

8 Practical development work

I have reviewed the application I developed for my earlier course. As I
suspected, this provides a good basis upon which to develop the
communications software. It implements a simple client–server system. I have
stripped out the application specific aspects of the server code to provide a
starting point for this part of the project (Appendix 2).

9 Problems
I have encountered no specific problems at this stage. My main problem is
likely to be with interpreting some of the mathematics used to describe the
negotiation protocols in the Faratin paper.

10 Feedback
At this stage, I mainly need general feedback about whether the work I’ve
proposed is sufficient to pass the course.
I would appreciate any pointers to specific textbooks or papers that I should be
sure to look at in respect of negotiation.
My job might get in the way of completing TMA 02 on time and so I want to
signal that I may need to request an extension if I haven’t been able to
complete it a week ahead of schedule.
M450 Sample project description 1 page 8 of 12

Appendix 1: Project Schedule

Week
Task No. Task Description 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

1 Read course materials X X

2 Develop 'Communication System' X X X X X X

2.1 Revise earlier application X
2.2 Produce requirements statement X X
2.2 Produce Design X X
2.3 Develop Implementation X X
2.4 Evaluation X X

4 Develop 'Negotiation System' X X X X X X X X X X X X X X

4.1 Access OU electronic library X
4.2 Search for and print relevant articles X X X
4.3 Read articles and select possible approaches X X X X X
4.4 Decide on selected basic approach X

4.5 Produce requirements statement X X

4.6 Produce Design X X
4.7 Develop Implementation X X X X
4.8 Basic evaluation X

6 Integrate and test first prototype X X X

Implement the integrated system X X

Design functional test X X
Perform functional test X
Design negotiation tests X X
Perform negotiation tests X X

3 TMA01 X X
5 TMA02 X X X
7 TMA 03 X X X
8 ECA X X X X X X X X
Draft ECA X X X X
Submit ECA X (Spar

9 Epilogue
9.1 Implement and evaluate addditional negotiation protocols X X X X
M450 Sample project description 1 page 9 of 12

Appendix 2: Code for the ‘ServiceServer’ Communications System

The following is stripped-out server code for the ‘ServiceServer’ Communications System.
Some of the code is a little dated now and could be revised in light of recent
developments in Java.

import java.net.*;

import java.io.*;

import java.util.*;

public class ServiceServer {

private int thePortNumber;

private ServerSocket theServerSocket;

private Socket theSocket;

private InputStream is;

private InputStreamReader isr;

private BufferedReader br;

private OutputStream os;

private PrintWriter pw;

public ServiceServer(int aPortNumber) {

thePortNumber = aPortNumber;

try {

theServerSocket = new ServerSocket(thePortNumber);

}
catch (IOException e) {}
}
M450 Sample project description 1 page 10 of 12

public void start() {

try {
while (true) {
System.out.println("ServiceServer is waiting for a client connection …");
// Sit and wait for a client connection…
theSocket = theServerSocket.accept();
System.out.println("A Client has just connected…");
this.setUpStreams();
this.processTheClient();
this.closeStreams();
}

catch (IOException e) {}

public void processTheClient() {

// Reply to the client with the connection string and ipAddress of the client
String clientAddress = theSocket.getInetAddress().toString();
String connectionStr = "Welcome to the ServiceServer : " + clientAddress;
pw.println(connectionStr);
// Now service the client until the client sends a logoff string
String clientString;
String request = null;
String theString;
do {
try {

clientString = br.readLine(); // wait for a client request…

M450 Sample project description 1 page 11 of 12

//This code section to be modified to handle the negotiation offers from the client
System.out.println("From client : " + clientString);
StringTokenizer st = new StringTokenizer(clientString,"*");
request = st.nextToken();
if (request.equals("MethodRequest")) this.someMethod(clientString.substring(4));
//etc.

catch (IOException e) {}

} while (!request.equals("LOG"));
this.postToClient("GoodBye…");
}
//The following method will formulate server responses
public void someMethod(String s) {
this.postToClient("This is the result of first method…");
}

public void postToClient(String s) {

pw.println(s);

public void setUpStreams() {

try {

// first the input side of things…

is = theSocket.getInputStream();

isr = new InputStreamReader(is);

br = new BufferedReader(isr);

// next the output side of things…

os = theSocket.getOutputStream();

pw = new PrintWriter(os,true);

}
M450 Sample project description 1 page 12 of 12

catch (IOException e) {}

public void closeStreams() {

try {
is.close(); isr.close(); br.close();
os.close(); pw.close();
theSocket.close();
}

catch (IOException e) {}

public static void main(String args[]) {

ServiceServer ss = new ServiceServer(6001);
ss.start();
}

[End of Appendix 2]