Architecture of BOSS2

Introduction

BOSS2 was designed “from scratch” to be a simplification of the original BOSS1 system, and to be modularised so that as many subsystems as possible could be replaced or rewritten. Three design decisions were taken.

1. BOSS2 would be a web application with no concept of “frontend” or “backend”, so that the only method of using it would be through the web application.
2. The low-level operations would be modularised components specified through a set of interfaces provided by specialist factories. This was primarily to facilitate potential changes of databases, test execution modules, authentication methods, etc.
3. Page redundancy would be allowed. This violates the principle of Object-Oriented Programming, but in order to increase maintainability and readability, each page handler would contain all the code for performing its operation. If this proves to be a problem, refactoring is possible in the future.

Overview

The BOSS2 system is essentially an MVC architecture which contains four components, illustrated in the following diagram.

The Model is a set of interfaces that abstract all low level operations of the system, including (but not limited to) database access, test execution and user authentication. Each component has an abstract factory class that the Model Implementations can subclass and be registered with the model implementation “Registrar”.

The Model Implementations provide concrete implementations of each component of the Model. For example, the Model defines data access operations through Data Access Objects, and the default Model Implementation for Data Access Objects provides this functionality through a MySQL database and accompanying file storage directory.

The Controller is a web application servlet which is the main entry point of the program and is responsible for registering Model Implementation factory classes with the Model on launch. It then provides a framework for displaying page Templates and processing input after displaying these templates. The Controller performs all logic and decision making from this input and uses the Model to actuate its side effects. The Controller registers the Model Implementations with the Model, and displays the Templates.

Templates are the abstract layouts of help pages and web pages, written in the Velocity templating language. The Model and the Templates are independent.