Thoughts about modularity

The Engineering and Physics departments provide us with a unique set up in which to design a modular system. Engineering has a working module to manage teaching duty allocations (Teaching Office DataBase). This module is being rolled out to the Judge Business School these days. There are some differences between the version rolled out to JBS and the original system, but crucially only one minor change at database level. This allows us to think of the Engineering module as the nucleus of a larger system, and of the JBS roll-out as the most basic extension to this module. Further deployments into other departments in the univeristy will test the suitability of this module and the degree to which its robust, simple design is sufficient to meet their needs. The challenge here is organise the code and the database schema so as to allow other modules to be added to it while maintaining it design. We might add tables to the database but will aim not to change existing ones.

The Physics department's Teaching Information System is larger and more complex, and will be redesigned as a whole. The first module to be written there will be the second deliverable of the eAdmin project, managing student registrations for courses and examinations. The challenge in this case is to incorporate the Engineering TODB within this new system as is, while developing the second module around it. This will serve as a more serious test for the modularity of the emerging system.

If we can demonstrate that the new system lends itself to the above two types of modular extension we will have achieved a lot. Proper documentation will then pave the way for future extensions of the same modular nature.

TODB at the Judge Business School

The Judge Business School (JBS) at the University of Cambridge has been associated with the Engineering TODB for some time, and is one of the cooperating departments in this project. The JBS currently uses an Excel-spreadsheet based teaching allocation system. An interesting challenge has been translating this into something the TODB can handle without fundamental changes. It is with satisfaction that we are able to report that effectively every peice of information stored in the spreadsheet can be stored in the TODB without modification to the database schema, with the one small exception of adding a field for 'points quotas'. User interface code is similar, except where support for using quotas is necessary.

Two new reports were developed and added to the TODB for the JBS:

• A teaching points summary page, which lists point-sums in categories for teaching, supervision, sabbatical and so on by subject division and by course.
  
• An interactive faculty (staff) summary page which displays how many points each member of staff is 'earning' and how this is broken down by teaching activity.
  

These reports replicate almost exactly the function and behaviour of the spreadsheet equivalents on which they are based.

As the JBS version of the TODB has been developed in parallel with the Engineering TODB, it is effectively using TODB v1 code, where Engineering is now using TODB v1.1 code. It is necessary to attempt to converge these as much as possible prior to evaluation and use by the JBS.