Skip to content

System Overview

David Stevens edited this page Feb 28, 2020 · 3 revisions

JabRef - System Overview

Purpose

The purpose of the system is to be a bibliography reference manager, using BibTex as its native file format. Diving a bit more into detail the system is quite extensive with a lot of functionality. Particularly useful features are for example the ability to extract citations from a LaTeX file, updating current citations from sources such as Crossref, and searching for new online sources.

Architecture

The system architecture consists of 5 main packages. Namely: cli, gui, logic, model, and preferences. Following will be descriptions of each package and how they depend on each-other. As explained in the official high-level documentation, the model is the core of the architecture, where the rest of the packages are dependent on it (except preferences).

The text on the nodes are the package names. Arrows mean permitted dependencies. "Everywhere" means any class in any package.

The diagram illustrates that the project follows a hierarchical structure. For instance, an arrow between the gui and logic package means that the gui is allowed to import and depend on classes within the logic package. The arrows are directional, meaning that that same arrow does not imply that logic may depend on gui classes. Any imports "upwards" in the hierarchy are forbidden and a sign that the code should be refactored. The global classes (classes in the org.jabref package, such as org.jabref.Globals) can import anything but only be used in the interface packages.

model

As the core of the architecture, the primary purpose of model is to be the package containing all the main data structures that is needed for the program to function. Looking at the sub-packages the most important ones are probably database and entry. The former containing classes such as BibDatabase which is the representation of a .bib file, and the latter containing classes representing each database entry and its fields.

logic

The logic package is in the words of the developes responsible for all actions when it comes to the model. This means that all reading/writing/manipulation and so on of the model should be done through the logic package. This in turn means that the only thing logic is and should be dependent on is model.

The package is well-structured and program functions are logically split into sub-packages. One example is the sub-package search which contains the classes used when searching through a BibDatabase for example. Or the importer package which contains all classes used to import resources such as Google Scholar entries.

preferences

This package deals with everything related to the preferences the system's user has. The majority of the code that handles the preferences is located in the class JabRefPreferences. The reason for having this package is because of the large amount of preferences, which requires a lot of code to keep track of.

cli

As one can guess from the name of the package, cli handles the execution of the Command Line Interface version of the program. It also passes information to the gui in case the program is started with additional arguments. The core of the cli logic is located in the ArugmentProcessor class, which handles all the inputted arguments to the program. The class is therefore dependent on a lot of classes in the logic and model packages. The other class in this package worthy of mention is the JabRefCLI class which handles the definition of CLI arguments and keeps track of Boolean values representing which arguments are being used.

gui

This package handles everything regarding the Graphical User Interface of the program. All the components of the GUI are split into packages which makes them fairly easy to locate. Generally the structure of the files seems to be that a class containing GUI elements are named [componentName]View and are then supplied with data from a corresponding ViewModel class. Which leads one to believe that some form of a Model-view-viewmodel (MVVM) pattern is used, where the 'model' part is implemented in the model and logic packages. If time permitted it would be interesting to document each sub-package in gui but since there are about 50 of them, it seems a bit out-of-scope.

Clone this wiki locally