1.2.2 Relations and their properties

The logical and implementation view is based on the concept of a layered architecture. This means that each “layer” in this architecture can communicate with the layer above or below, but not have any gaps of layers in between.

Our logical and implementation view actually contains 5 layers: The data layer, business logic layer and representation layer, as well as 2 data access layers in between. These data access layers are the connection points between each layer. Below, the relations between each layer and their components are sketched.

The relations between the layers are simple: Each layer passes data to the next layer, which either stores or transforms the data before passing it on to the next layer. Communication between layers only exists through the data access layers.

Data layer

Within the data layer, the extractor component communicates with the various data stores of the tools used by previous. The extractor component does not directly communicate with any of these tools, but only accesses the data stored in each tool. We explicitly defined that the extractor should have the least interference with the existing tools as possible, because Previous stated that the “Facebook for software developers” will be used as a supporting tool. Our system must therefore interfere as little as possible with the current (process-critical) tools.

The data layer acts as an independent part of the system, therefore user queries will not affect the process of data gathering from different tools. The extractor component will extract data based on a scheduler, which can either be a learning system in itself (to determine when the best time to collect data is, based on tool usage) or a simple scheduler (gather new data every hour/day/week).

Business logic layer

Communication within the business logic layer is split up into 2 data flows. One of these flows is the configuration of business rules, and the other the actual conversion, as depicted in our component model. The configuration module must connect to the relational database in order to make is visible for the user which data is available. Using this information, the user can determine which data fields are relevant for the queries they want to fire at the system, which is in turn stored and calculated in the business rules engine. The extractor and transformer must, based on the input from the business rules engine, extract and transform data from the relational database into the graph database.

The business logic layer, the conversion of relational data to graph data, can either be based on a scheduling system (same as the data layer, making this an independent component) or based on user input (whenever a user fires a query, update the graph database).

We have chosen to make this layer independent, as this system is not process-critical (therefore, data doesn’t need to be very accurate) and it would safe performance, which is one of the quality aspects the stakeholders are concerned about (they want a fast system, else it will probably not be used).

Representation layer

The representation layer is an API that accesses the graph database. This API contains methods for accessing data based on the business rules set in the business rules engine. Users can query the data using any user interface that implements the API. This way, Previous is free to choose whichever representation they’d like.