Enterprise web programming

Units ENTWA (Level 6) and APSW (Level 7)

APSW 2017-2018 Coursework 2


All students must do a web application development project.

Students are expected to draw on material taught (and material otherwise learned) during all the units on their course in tackling this problem. This assessment thus integrates many of the elements covered during the course.

The coursework is individual, but students are expected to form groups to ensure that their solutions interoperate. Groups can be from 2-6 students in size. Each student in a group must work on a different module.


The School of Computing uses an online system for the management of student projects (both final-year undergraduate and masters). This is called SUMS (Student and Unit Management System).

The aim of this coursework is for each group of students to develop a number of modules of that system. The number of modules developed must be equal to the number of students in the group. While the modules can be developed separately, they must be capable of interoperation. This means they must:

It is recommended that the sharing be achieved by sharing a source code repository and other software engineering tools.

The required modules are:

Project Registration

The existing PUMS system gives an example of how registration for projects is conceived. The primary goal is to allow students to self-register with their course and unit details. This is the first step in the project process.

A previously created requirements specification for this module.

Project Ideas

The School of Computing's MSc project ideas database is currently implemented in a non-MVC style. It also has limited searching functionality. It does not permit people who submit ideas to be able to edit them or withdraw them. This functionality needs to be added.

A previously created requirements specification for this module.

Project Allocation

The aim of the project allocation system is to match up students with ideas and supervisors. Students can select ideas in order of preference; similarly they can select prefered supervisors. The Project Co-ordinator must have a mechanism to allocate ideas and supervisors to students. If this can be automated or semi-automated, all the better.

A previously created requirements specification for this module.

Project Marking (administrator)

Before markers can mark a student's work, someone (usually the project coordinator) needs to set up the marking scheme.

A requirements specification for this module is under preparation.

Sample mark form

Project Marking (marker)

This module implements the phase of a project when the marker marks it according to a pre-defined marking scheme.

The current marking system was developed using Apache Struts and pre-dated the introduction of JPA. It is thus riddled with overlapping entity class definitions and consequent JDBC access code. This needs to be "cleaned up" while retaining the existing functionality (though additional functionality is desirable).

A previously created requirements specification for this module.

Sample mark form

Project Feedback

Once a project has been marked (by two members of staff), the marks and written remarks must be fedback to the student. This is governed by rules concerning how the two sets of marks (and associated comments) are reconciled.

A previously created requirements specification for this module.

In each case, your aim is to make substantial developments to the relevant module(s). Those developments will be in using the Java EE technologies (at least JSF, EJB, JPA) PLUS one or more of the following:

Groups may either start from scratch and build a system of their own, or (after discussion with the unit coordinator) start from his existing codebase. Obviously in the latter case, a more advanced endpoint will be expected, but students will have the advantage of starting with a partially developed system and the framework of existing code that it provides.


The coursework will be carried out in groups of up to 6.

Groups formed

Revised 21 December 2017

Group Approach Registration Ideas Allocation Monitoring Marking Feedback

* to be confirmed

People as yet unallocated to groups

Jamie Barr

Andrew Stanton


Deadline Date Deliverable(s) Submission arrangements Marks
Week 5 practical Tuesday 6th February
  • First draft of requirements specification
  • Bring printed copy to practical session
Week 7 practical Tuesday 20th February
  • First draft of user interaction design (organisation structure diagrams and/or storyboards and/or architecture maps)
  • Bring printed copy to practical session
Week 9 practical Tuesday 6th March
  • Alpha version of the web application (demonstrating some subset of the functionality)
  • Jim will download it from your version control repository.
  • Demonstrate it at practical session
  • Ensure your web application is in the specified format and that your repository is set up correctly.
Week 13 (CAP)


Friday 27th April
  • Demonstrable web application
  • Completed documentation
    • Requirements specification
    • User interaction design specification
  • Source code listings and Javadocs
  • Evidence of use of JIRA and Subversion
  • Report on coursework
  • Submit report via Moodle

Notes on deliverables



Students are encouraged to use whatever resources and facilities are available to them. All material (including programming code) that is copied from elsewhere must be identified and its source cited. The member of staff who set this assessment may be consulted for guidance on your approach, and to a limited extent with technical problems that arise.


Last updated by Prof Jim Briggs of the School of Computing at the University of Portsmouth

The enterprise web programming units include some material that was formerly part of the WEB1P and WEB2P units.