The design seeks to accurately model the organisation and academic processes, in order to minimise user training requirements and to maximise the number of use-cases the system fulfils. MMS’ design is motivated by the need to reduce costs, and as such prioritises
decisions both to reduce time spent by end-users, and in supporting the system. As a result, its functionality focuses on the administrative aspects of higher education, in contrast to many web-orientated tools which focus on the teaching and learning aspects.
Support costs are managed by preemptively assessing risks and designing components such as the data layer in order to avoid cases which are high risk, expensive to recover from, or both. This approach of preempting problems is continued through to the user interface, where MMS seeks to warn users of potential issues as quickly as possible in order to enable resolution while there is an opportunity to reduce/eliminate negative consequences.
Chapter 5
Software Architecture
Faced with the challenges identified in chapter 3, some solution was needed in order to redefine the development tasks into something which could be achieved with the resources available. To this end the following questions are considered:
• What are the common elements of functionality required for the tools? Of these common elements, which can share code?
• What design patterns are of relevance to this framework? Additionally, where com- mon design patterns are a poor fit, can they advise new work?
• What dependencies exist between tools and how can these be managed such that de- velopers can work in parallel with minimal interaction required between developers working on separate tools?
• How can language features be used to reduce risk of errors?
Suitable common elements in authentication/authorisation, organisational structure inspec- tion and management, error handling and reporting, and security policy enforcement were identified. MVC and REST designs form the basis of much of MMS’ rendering architec- ture. Appropriate isolation of developers is provided through the tool data source interfaces, ensuring those working with tools only need to be aware of the core framework. Leverag- ing of language features focuses on use of highly detailed types and type safety to minimise risk of accidental mixing of data types even where there is a common underlying type (for
example student IDs and staff IDs are incompatible types, although both are string-like data types).
The resulting framework empowers developers, and it would have been infeasible to pro- duce and maintain the tools without its support. Some elements of this architecture (MVC pattern support, RESTful services, content rendering) are now available as common li- braries, however the majority of it is highly tailored to higher education.
The institution model in particular is much more closely mapped to the actual institution and its data structures than is common for other web tools, and drives the authentication and authorisation support which is leveraged to allow accelerated development of tools.
5.1
Overview
The architecture is designed with a number of goals in mind:
• Consistent input processing: Handling of requests from the user should be consistent and clear, following the rule of least surprise1[112]: Accordingly, the architecture encourages and simplifies tool/user interaction in a consistent and predictable man- ner.
• Abstraction of the organisational structure: Tools do not require a detailed under- standing of the institution or its structure, in order to interact with institutional data.
• Rapid diagnosis: Developers are notified by e-mail of any serious problems, and detailed reports used to assist them in locating the cause.
• Security: Enforcing security through the software architecture wherever possible, for example requests go through a standard validation process before they are passed to the embedded tools.
• Separation of concerns[33]: Tools are isolated from each other, such that changes to individual tools do not affect the system as a whole. Abstract interfaces defined in the core framework provide views for tools to implement where they wish to expose data for re-use elsewhere in the system.
Confidence in the system has been critical to adoption, as for the majority of its lifecycle it has been adopted on a voluntary basis by academic schools. A high profile failure such as the one at the University of Southampton[43] could have irrecoverably damaged MMS’ reputation, prematurely halting its adoption. To manage this, a number of different design elements were used:
• Defensive – The APIs provided by MMS’ core are designed such that bugs are ex- posed as early as possible in the development cycle (ideally at compile time or during design).
• Type safety – Language type safety is utilised wherever possibly by encapsulating incompatible data (such as grades on different scales) within data types the compiler will refuse to interchange, even where the contained data type may be compatible (in this case, an integer value).
• Integrated tests – MMS includes its own test infrastructure for executing integrated tests on hosted tools.
• Data confidence – MMS has been designed such that neither it nor its hosted tools actually delete stored data, instead marking obsolete records as such in the database. This ensures confidence that MMS will not (and arguably cannot) lose data.
A high-level overview of MMS’ architecture and interoperation with external systems is shown in figure 5.1. Here lines reflect connectivity between components and systems, and arrows show direction of data flow. Components within the central box are part of MMS itself. Of specific note are the authorisation and routing layer (referred to as “dispatchers”) between the user and the tools, and the institution abstraction layer which manages data transfer to/from external data sources.