4.2 Ivory Tower
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
— C.A.R. Hoare, The 1980 ACM Turing Award Lecture
Hoare's insightful remark points at two ways to build software systems. I feel applications developed for this thesis exists somewhere in a transient stage between these two extremes. Currently they have a lot of identified and as of yet unidentified deficiencies but in some sense they always will be so at one point or another due to the turbulent nature of specifications that tries to account for a constantly evolving academic context. Here I present all the constructs that I have identified towards addressing some of the concerns that current applications address. By virtue of the single responsibility principle, I have tried to extend functionalities of the current apps wherever it seemed to add value. An example would be the modality presented in one of the applications to follow where the sliders enables the student to explore and evaluate their future coursework marks and its impact on the stage and overall averages.
4.2.1 Ivory Tower
As outlined in the theory section, the architecture's central point of contact is the consolidated datastore that I have named as the Ivory Tower. This is an abstraction that sits on top of a database and accumulates data from various dynamic endpoints. It is responsible for serving data to the various components of the universe and also for maintaining a consistent interface for all applications. It does this by providing an API that every app can interface with.
This approach provides some advantages over letting all the applications directly connecting to the database. First of all it decouples the implementation from the interface. This essentially means that any database can be swapped in place of the current concrete representation. This approach has led in my experience to keep the architecture be more flexible and secure.
A student's only point of contact with this system is through the gateway login. This is similar to the Shibboleth interface Newcastle university currently has.
[Image here]
It invokes the metaphor of space mentioned in the theory section with an astronaut helmet in place to give the feel of an exploration. Once the user logs in, they are redirected back to the respective application where the request originated. All the rest of the communication with the application is conducted over the wire with AJAX requests. A popular approach is to use JSON as the data exchange format but development in Clojure enabled me to the use EDN in place of JSON and it made the implementation a bit smoother. One other alternative worth exploring here is the newly introduced data format Transit [Transit 2015]