Frequency threshold change - wonjoonSeol/ScienceScape GitHub Wiki

The design of our application accommodates for further changes. We made sure our scripts were entirely extensible, by applying the following practice:

If a situation arises where scripts should be able to perform a task, while the user interface should not necessarily accommodate it, prepare the scripts for extensibility and make sure the user interface can be updated easily, without having to face a cascade of code.

An example of this is user-threshold setting. Cited references are being parsed using a threshold, which is set to 1 by default on the user interface. This was a design choice as suggested by Dr. Pissis (our project supervisor) to minimise our requirements on the fourth meeting, whose agenda was as follows:

To discuss: What part of the system architecture is essential in order to develop a minimal viable product for the client? To what extent can the software/system that the team intends to build be scaled down while still enabling the team to produce an application that is useful for the client?

However, should there be a need for changing them, it is possible to update them by one single line change in the config.py file. Our user interface is very modular, to let us address a specific interpretation of the requirements. To ensure this interpretation would not lead to a conflict between the real use cases and the use cases we were communicated, we have centred our whole back-end around the config.py file, which is the only point of entry to the scripts configuration. There, users can define thresholds, time spans, keywords, country codes, header codes and many parameters. The team has also used argparse to ensure a good liaison between front-end and back-end. All a potential future developer has to do is to pass their arguments to the back-end, and make the necessary easy adjustments there.

Moreover, liaising with the front-end required a careful manipulation of the Sigma.js library, upon which our website is based. Using this library, it is possible to freeze the position of the nodes corresponding to the cited references and articles, should this be needed in another iteration of ScienceScapeS. In order to prepare our system for a wide range of new requirements, we have chosen to parse all the available meta-data (countries, locations, conferences, institutions, authors, etc.) in our new and redesigned version of parsers.py. Again, the reason for not implementing this envisioned meta-data clustering is to interlink the complex back-end scripts powered by Bibliotools3.0 and the user-friendly front-end interface as a proof of concept to the client. This was also decided in the fourth tutor meeting.

Designing for changing requirements and other potential improvements

The graph processing scripts could be able to add the nodes corresponding to the selected meta-data spatialising the new nodes which ForceAtlas2, while keeping the position of the reference nodes fixed as in step. Fixing node coordinates is a minimal change. Due to this new requirement change near the end of the project deadline, the team has decided not to implement this feature so to not risk changing many of our code interaction and tests at the final phase of the development.

However, as with setting up the frequency threshold, what we showed is a proof of concept and since our code already deals with changing co-ordinates of multiple nodes on a given graph base, fixing reference node coordinates would require minimal change to our code.