Background

In Group Exercise 1 you tackled the capture, specification and validation of the requirements for a Support System for Group Projects. In Exercise 2 you will design and implement a part of that system. So that everyone starts on an equal footing, we will supply you with the requirements, rather than using the ones you generated in Exercise 1.

Note that some of the details in the specification below do not correspond exactly to the form and conduct of group projects in level 3 in the Computing Science Department. Intentional deviations have been introduced to make the exercise more valuable educationally.

The Brief

Functional Requirements

Students and Supervisors Only

Use Case 1 - View a list of project deliverables.

A user selects a project from a list of projects and views a list of all deliverables for that project. See use case 3 for details of the representation of a project. See use case 4 for details of the representation of a deliverable. The displayed list should include a summary of each project (title, type, description) and, for each project deliverable, the title, type, submission deadline and description.

Use Case 2 View feedback items

A user selects a project deliverable and views a list of feedback items for that deliverable. See use case 8 for details of the representation of a feedback item.

Supervisors Only

Use Case 3 Create a project

Note: A project is represented by a unique title (string), its type (CS, SE, ESE), description and an associated set of deliverables (see use case 4 for details of the representation of a deliverable).

A supervisor enters a unique title , a type and (optionally) a short textual description for the project. The system creates a record for the project with the user supplied information. Also, all project records are initialised with one deliverable each from categories project plan, design, test plan and report. Projects of type SE are also initialised with one deliverable of category requirements.

 

Use Case 4 Create a deliverable

A supervisor selects a project and creates a record for a new deliverable for that project. A deliverable is represented by a unique name, a type (assessable, non-assessable), a category (one of project plan, requirements, design, test plan, report, evaluation, other), a description, a location (a path to a text file containing the deliverable), a deadline date and a state. An assessable deliverable may be in one of the following states: specified, deadline set, awaiting feedback, feedback available, awaiting assessment, cancelled. A non-assessable deliverable can be in all of the states of an assessable deliverable except awaiting assessment. When created, the supervisor specifies the name, type, category and description; the deadline is initialised as null. All deliverables are initialised with the 'specified' state. Note also that projects of type ESE cannot have an evaluation deliverable.

Use Case 5 Set a deliverable deadline

A supervisor selects a deliverable that is in the specified state and enters a deadline date. The deliverable's state will change to deadline set. Note that, once set, a deadline cannot be changed. The deadline must be later than the current date.

Use Case 6 Reject a deliverable

A supervisor selects a deliverable that is in the awaiting feedback state and indicates that it is rejected. The deliverable's state is changed to deadline set. Note that, once rejected, no feedback can be entered until the deliverable has again been submitted for feedback.

Use Case 7 Cancel a deliverable

A supervisor selects a deliverable and indicates that it is cancelled. The deliverable's state is changed to cancelled.

Use Case 8 Add feedback

A supervisor selects a deliverable in the awaiting feedback state. The contents of the deliverable will be displayed (i.e. the contents of the file containing the deliverable) as well as any existing feedback items for this deliverable. The system creates a new feedback item with the current date associated with the selected deliverable. The supervisor enters its textual body and the deliverable’s state changes to feedback available..

Students Only

Use Case 9 Submit a deliverable for feedback

A student selects a deliverable that is in the deadline set state or feedback available state and indicates that the deliverable is submitted for feedback. The deliverable state changes to awaiting feedback.

Use Case 10 Submit a deliverable for assessment

A student selects an assessable deliverable that is in the awaiting feedback state and for which the deadline has not yet passed. The student indicates that the deliverable is submitted for assessment. The deliverable state changes to awaiting assessment.

Non-functional Requirements

1. Data (e.g., about projects, deliverables, feedback) must be stored in files. No database should be used. It is assumed that relevant data is persistent between user sessions and is loaded at the start of a session and saved at the end. For the purposes of this exercise, that repository should be implemented as a set of text files. You may choose to structure those files and implement read/write operations as you wish. You will have to create a set of sample records with which to test your design.
2. Access control need not be handled by the system, apart from simple user role identification. However, it is anticipated that access control at the individual level will be added at some point in the future; therefore, the current system should be designed with this future enhancement in mind.
3. You may have to amend the representations of domain objects listed above in order to support functionality for the use cases. Make sure you document such changes in your design rationale (see below). The system must be implemented using Java without the use of Java enterprise beans.
4. The user interface to the system should emphasise simplicity. It will not involve the use of web-based technology. We envisage an interface based on a set of basic Swing components.

Resources

The maximum resources available for the entire group exercise 2 is the capacity of a PSD3 exercise group during semester 2.

The Clients

Your clients are the PSD3 lecturers: Phil Gray and Ray Welland.

Aims of Group Exercise 2

The main aim of this group exercise is to provide group members with the opportunity to practice object-oriented design and development using UML and Java.

Objectives of Group Exercise 2

At the end of this group exercise, you will be able to:

• produce a UML-based design for a system using class, sequence and package diagrams;

• produce a Java implementation of your design;

• make a change to an existing design;

• carry out black box testing of someone else's system;

• produce a well-argued and coherent report on aspects of the design of your system.

Full Description of Activities

Group Activities and Group Deliverables (what you must turn in as a group)

	Activity	Deliverable	Handout	Deadline	Note
GE2.1	Design the System	Draft System Design (for feedback only)	12 Jan	22 Jan	Consists of an initial class diagram plus a representation (graph and/or table) of a deliverable state lifecycle, one sequence diagram to capture an interesting/difficult design issues and an acceptance test plan. You may also include a set of questions to the clients, asking for specific clarifications of the requirements.
GE2.2	Implement the System	Initial System; Revised System Design	--	23 Feb(for code) 2 March (for everything else)	Must be written in Java. Revised System Design consists of modified deliverables from GE2.1 plus a package diagram and a rReport giving an overview of your design and development process, justifying your design features and decisions.
GE2.3	Black box testing	Test plan and results	23 Feb	2 March	Carry out black box testing of code from another team.
GE2.4	Maintenance	Modified design diagrams; modified system	23 Feb	2 March	Must modify the design and implementation to handle a requirement change supplied by the clients.
GE2.5	Acceptance Test	Demonstration of system to clients	--	TBA	You will demonstrate your system to the clients to ensure that it meets the requirements.

Further Information on Activities

Details of Activities 2.2, 2.3, 2.4, and 2.5 will be given during workshops in the second semester.

Individual Report

All students must submit an individual report on their contribution to Group Exercise 2. Details of this report will be given during the second semester. The Individual Report is due 3pm, Thursday 9 April.

How You Should Submit Your Work

Unless advised otherwise, your submission must be submitted in printed form in the course submission box in Lilybank Gardens. Contact a staff member if you're not sure where to find the box.

Feedback

There will be feedback on Group Exercise 2 deliverables during the course of the term. Basic information about assessment is given in the module description. Further details will be supplied later in term 2.