Model Operations Processing System

One of the original aims of MOPS was to avoid implementing a database; primarily because the overhead in installing and maintaining a database could be problematic.  MOPS, instead, was developed using a file-based data system, using Python’s dictionary facility to handle the data.

During some recent testing (with the Flash, or messaging, service in MOPS), it was apparent that MOPS would need to lock the files during read access as well as during updates.  This pushed MOPS into a more complex file handling arrangement.  Instead of implementing this, testing is being carried out using Python’s ‘dbm’ utility, which uses a very basic key-data database arrangement.  If the tests prove satisfactory, then the changes will be applied to all the currently developed modules.  This will mean little progress over the next couple of weeks.  As has been stated before, MOPS is being built to a standard and not a timetable, although at this stage the amount of effort involved in reworking MOPS onto the dbm model is probably not too great.

The flash messaging facility was completed during the week; it highlighted a small issue around file locking which has now been solved, although it also meant retro-fitting a change to modules that had already been completed.  In the process, the Flash messaging routines were also simplified.

Work has now moved onto developing the Car modules.  These will be addressed in two stages; the first will provide basic functionality, with the remaining functions being completed as the industry and train modules are completed.

This last week has seen the development of most of the Locomotive module; this module handles the current state and location of each locomotive.  There’s also been some development on Flash messages: these are messages that are either generated automatically due to an event, or can be created by users.  They are then automatically broadcast to all other users.

Fifty per cent of the reference module functions – the majority of the functions on the system – have now been completed, and work is also progressing on the background and action functions.

The new MOPS timescale is shown below.  Currently there’s no impact on the delivery date; it’s the interim deliverables that have been retimed.   However, there was little progress this week due to the impact of another project in the 1:1 scale world.  That project has now been completed, so MOPS should get right back on track.

Not much progress in percentage terms this week; although the software has been made improved for a number of reasons:

1 – a difficulty on one of the modules caused a rethink to an approach on validation of data; this has now been cascaded down to all the other completed modules.  The revised approach is simpler, more logical and easier to maintain;

2 – work is under way on creating a semi-automatic test bed.  This has already improved the quality of the software, and being re-runnable it means that any later tweaks can be thoroughly tested.

In addition, work has been taking place on the User Guide: this will enable the User Guide to be tested alongside the system when it’s ready for a full test.

Finally, a further ‘helper’ has been added to the system.  Because this is a command-driven system, it’s not always easy to remember what parameters are required on unfamiliar or infrequently used commands.  By entering the command followed by a question mark, MOPS will indicate what data is required; this should make the system a little easier to use.

All of this may mean that the estimated completion date for the Reference Data Processing may be missed; but this software is being built to a standard rather than a deadline…  An updated schedule will be posted next week.