Modular B.Sc.

Honours Computer Science 3COM0063 Computer Science Project Suggestion

0.

Identifying Code 911-MFW

1.

Project Title A Distributed Diary System

2.

Aim of the Project The aim of the project is to produce a Java client-server application that keeps a working diary for each registered employee of an organization, and that allows such individuals who work on the same site to schedule meetings with each other by inspecting their individual diaries. Organizing meetings between employees can be a tedious and time-consuming process, so this application is intended to automate this process as far as possible. As well as providing a simple individual diary function, this application is able to co-ordinate entries in several individual diaries.

3. 3.1

Background Information and User Requirements Diary Entries All diary entries have a date, a start time and an end time (on the same day). The earliest that an entry can start is 08:00. The latest that an entry can end is 22:00. Although there will be days on which little work is expected (weekends, public holidays, etc.), an employee should be able to create a diary entry between these times on any day. An employee must be able to record absence from the site for whole days because of holidays, sickness or off-site working. Employees are assumed to be available at any time between 09:00 and 17:00 on any weekday (Monday to Friday) unless otherwise indicated by their diary. In addition, an employee can record that they are working on-site at other times (e.g. after 17:00 on a particular day, or on a particular Saturday). In the rest of this specification, the following distinction is used: an "activity" is an entry in a diary that only involves the owner of that diary. An activity has a description in the diary, and is flagged as either moveable or non-moveable. See section 3.3 on the use of this. a "meeting" is an entry in a diary that involves other employees than the diary's owner. A meeting has a description and a record of who the other involved employees are.

3.2

Individual Diary It is assumed that an employee will log onto the diary system when they start work. This will involve entry of a user name and password. The required functions that only affect one diary are: record absence from site for a whole day record on-site availability outside the normal schedule display the diary entries for a day record an activity in a diary

14 - 1

cancel an activity print the diary entries for a day

Diary entries for days before the current date should be read-only, and will be removed from the diary after six months. 3.3 Organising meetings - synchronizing diaries An employee should be able to request a meeting, of a particular duration, with named colleagues, on a particular day or within a particular time period. The system should find a time when all concerned are free, make an entry in each individual diary and then notify each employee concerned. An employee is free over a particular time interval if their diary shows that they are working on-site, and no non-moveable activity overlaps that time interval. Notification takes the form of a message to the employee, drawing attention to the fact that their diary has been changed, which may require them to reschedule a moveable activity. If the employee is not currently logged on, the notification message is queued and forwarded to them when they do log on. If there is no time at which everyone involved is free, this is reported to the initiator of the request (indicating which employees are not free), and no changes are made to the diaries. A meeting can be cancelled by the employee who initiated it, in which case it is removed from the diaries of all involved employees, with a notification sent to each. 3.4 System Design Issues This application can be implemented as a client-server system using Java, with RMI (Remote Method Invocation) used to program the distributed aspects. A suitable approach would involve a central diary server, with information about registered employees and their diaries stored in a database, accessed by a "thin client" running on each registered employee's machine. The client would enable an employee to update their diary (as described in section 3.2), and to request meetings (as described in section 3.3). It must not be possible for a diary entry to be updated by two different clients simultaneously. In addition, the server must know which clients are logged on, and be able to post a message to a logged-on client. 3.5 General Requirements This system is to run on the company's Intranet, so there are no security concerns, apart from authentication of a user when they log on. Both employees and the diary administrator should be able to access the system through a suitable graphical user interface. 3.6 Employee Requirements Diary users' requirements have been largely described in sections 3.2 and 3.3. In order to request a meeting, an employee must have access to a list of registered employees. An employee should be able to change their password. 3.7 Diary Administrator Requirements There will be a password-protected administrator account with special privileges. The diary administrator will need to be able to: add details of an employee to the system (name, user name, initial password)

14 - 2

remove an employee from the system view a list of registered employees cancel a meeting in an emergency (for example, if the initiator is unable to attend due to sickness)

If an employee is removed from the system, any outstanding meetings initiated by that employee are cancelled. Other diary entries are kept for six months. 3.8 Resources There are numerous books and on-line tutorials on database access, graphical user interfaces and distributed systems programming in Java. For example, there are excellent books published by O'Reilly; see the Java Resource Center at http://java.oreilly.com/. On-line tutorials can be found on the Sun web site. The following cover JDBC, RMI and GUI programming using the Swing classes, respectively: http://developer.java.sun.com/developer/onlineTraining/Database/JDBC20Intro/ http://java.sun.com/developer/onlineTraining/rmi/index.html http://java.sun.com/developer/onlineTraining/GUI/Swing1/shortcourse.html Students working on this project will be able to obtain some help with using Java at a technical help forum which will be run by members of the teaching team. The objectives of the forum are twofold. Firstly, to help students already familiar with procedural programming in languages such as Visual Basic, Pascal, C etc. to move to Java. Secondly, to give a very brief introduction to basic object-oriented programming in Java. Details of the forum, including when and where it is to be held, will be posted on the StudyNet site for 3COM0056. 4. Basic Project Tasks In order to be considered for a pass at Third Class Honours standard on this project, a student must give evidence of having adequately attempted to: Define an appropriate data model for storing an individual diary. Implement an individual diary as a standalone application on a single machine, allowing an individual to add an activity, but not providing for booking meetings. Provide a simple graphical representation of an individual diary as a component of the graphical user interface of this implementation.

14 - 3