Components and responsibilities

UnSHACLed's design includes a number of components. This page lists these components along with their responsibilities and describes how they communicate.

Model

The model's responsibility is to maintain the local state of the system (client-side). In order to accomplish this, the model allows other components to register themselves as observers of this state, so that they can be notified of any relevant changes to this local state. These other components can push updates to a queue within the model; these updates are then to be processed as the model sees fit.

Concretely, the model exposes

• public registerObserver(observer: ModelObserver): void, a method that allows other components to register observers and

• public readonly tasks: TaskProcessor<ModelData, ModelTaskMetadata>, a task processor sub-component that can be instructed to run one or more tasks in an order that is determined by the model (as opposed to some outside component). A TaskProcessor<TData, TTaskMetadata> exposes the following API:

  /**
   * Schedules a task for execution by this processor.
   */
  public schedule(task: ProcessorTask<TData, TTaskMetadata>): void;
  
  /**
   * Deschedules a task and executes it.
   */
  public processTask(): void;
  
  /**
   * Tells if the model's task schedule is empty.
  */
  public get isScheduleEmpty(): boolean;

Persistence layer

The persistence layer stands in direct communication with the account manager to forward and retrieve changes to and from the CVS repository. As such the persistence layer acts as the bridge between the repository (the shared, persistent representation) and the model (the local representation). In order to accomplish this functionality the persistence layer must modulate between the internal representation, as contained by the model, and the external representation, as stored within the CVS repository or newly loaded files.

The persistence layer exposes the following functionality:

/**
 * Create a new file with the given name.
 */
public insert (uri: string): void;

/**
 * Open a file with the given name.
 */
public find (uri: string): void;

/**
 * Save changes to a file with a given name.
 */
public update (uri: string): void;

Layout system

The layout system responds to changes in the graph as maintained by the model with an update consisting of a transformation to the graph's layout. This transformation is accomplished by interaction with an external API. This change in layout is then observed by the GUI, which proceeds to visualize the change. The graph layout is essentially contained within the internal representation of the graph which is stored inside the model---likely, every node within this representation will have coordinate fields---and is therefore itself an internal representation of the eventual on-screen coordinates.

Conformance system

The conformance system also responds to changes in the graph, again with an update containing a transformation to an aggregate of the model. This transformation adapts the the internal node structure as contained with the internal graph representation. Each node will probably end up containing fields to indicate whether or not these are valid with respect to a certain set of constraints. The conformance system must validate the node structure against all relevant constraints and then indicate for every node whether or not they conform. Again this change then becomes visible to the Graphical User Interface.

Graphical user interface

The GUI responds to user input by queuing updates to the state of the model and responds to notifications from the model by visualizing the changes.

Account manager

The account manager is responsible for managing all user information. An end user can login using the GUI, which will use the account manager for handling the login logic, which actually comprises logging into a CVS (e.g. GitHub). Later, when the end user wants to save or open a file, these credentials can be used to access the CVS repository. That way the account manager hides pushing and pulling from the end user, giving the end user the impression that they are using a regular file open/save mechanism.

The account manager (tentatively) exposes the following functionality (to the GUI):

/**
 * Allows the a user to gain access to his/her GitHub account.
 */
public login(username: string, password: string): void;

and the following (to the Persistence Layer):

/**
 * Commit and push local changes to repository.
 */
public push(data: GitData): void;

/**
 * Pull changes from the remote repository.
 */
public pull(data: GitData): void;

Generator

The generator's main responsibility comprises the inference of SHACL constraints from data. Via the GUI the users indicates that he or she wants to infer constraints from a given selection of nodes or a new loaded file, upon which the generator performs this conversion by queuing an update for the model to process.

The Generator (tentatively) exposes the following functionality:

public generate(): void;