Enterprise web programming

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

APSW 2013-2014 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 1-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 Monitoring

As the project progresses, students must meet certain milestones. At each milestone, they submit a short written report to their supervisor, who then approves it (or not).

This module must allow the Project Co-ordinator to set up milestones for a group of students.


Project Marking

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.

Source code (in Kenai - see instructions)

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 design and implement a Java web application that is superior to the existing systems. That superiority will be in using the Java EE technologies (at least JSF, EJB, JPA) PLUS one or more of the following:


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

Groups formed

Revised 4 February 2014

Group Registration Ideas Allocation Monitoring Marking Feedback
Z Hardi Saeed Jon Wellings Rui Wei Michael Statham Richard Dennis Lei Yang
Y Martin Luptak Anna Godusova Gerasimos Kourtidis Michal Kimle Cintya Aguirre  
X Cerana Hippolyte Christopher Bugden * Waqar Ahmed Nasser Al-Hadhrami Adeola Oladejo Tao Huang *
W Nirmalan Balasubramaniam Salim Al-Hadhrami Saud Al Ruqaishi Khemraj Thapa Ijem Ofili Rasheed Abubakar Rasheed

* to be confirmed

People as yet unallocated to groups






Deadline Date Deliverable(s) Submission arrangements Marks
Week 5 practical Monday 3rd February
  • First draft of requirements specification
  • Bring printed copy to practical session
Week 7 practical Monday 17th 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 Monday 3rd March
  • Alpha version of the web application (demonstrating some subset of the functionality)
  • Jim will download it from your Java.Net project.
  • Demonstrate it at practical session
  • Ensure your web application is in the specified format
End of week 13 (CAP)


Friday 25th April
  • Demonstrable web application
  • Completed documentation
    • Requirements specification
    • User interaction design specification
  • Source code listings and Javadocs
  • Evidence of use of JIRA and Subversion
  • Jim will download it from your Java.Net project.
  • Allow all other students on the unit auditor rights on your Java.Net project so that they can also view it.
  • Bring a working electronic copy of your web application to the SWS
  • Ensure your web application is in the specified format
  • 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.