Properties of 3 logical and implementation view - element catalog

  1. Properties
  2. History
  3. Community
  4. Source

1.2 Element Catalog


In this section, we will explain globally the terminology used in our views. This section is used as a legend to our logical and implementation view, and it explains what each component in the component model of 1.1, in essence, represents.


This section is divided into 4 subsections:

·         Elements and their properties

·         Relations and their properties

·         Element interfaces

·         Element behaviour


Each of these subsections will explain the component model shown in 1.1 in more detail.

1.2.1 Elements and their properties


Our logical and implementation view consists of 3 layers: A data layer, a business logic layer and a representation layer. The data layer is the layer that accommodates the gathering of data from the various project assisting tools used by Previous. The business logic layer contains the transformation of the initially gathered data to a format that is more easily accessible and analysable, which is accomplished by a set of business rules as defined by users. The representation layer contains the way of representing the results of the analysis to the users.


In this section we will describe the definition of each component within each layer in the coming subsections.


Data layer


Tool type:A “tool type” is a type of software development project supporting tool used by Previous. A few examples of tool types we have identified within Previous are: “Versioning tools” (such as: SVN, Mercurial), “Communication tools” (such as: Mail, IRC), “Project management tools” (such as: JIRA, Redmine) and “Bugtracking tools” (such as: Bugzilla).


Extractor: The extractor within the data layer is a component that connects to a tool’s (an instance of a tool type) data source. After successfully establishing a connection, it will extract all of the available data from the tool as long as that data wasn’t included in any previous extraction. This extraction can happen at a scheduled interval, which can either be determined by a learning system or a fixed schedule, or it happens through a push mechanism (whenever data in a tool gets updated, extract the data).


Transformer: The transformer component will make modifications to the data it receives so that it can be mapped for storage in a relational database. The structuring of the data is determined by the tool type information that should be provided.



Business logic layer


Extractor:The extractor in this layer is of a similar concept to the extractor at the data layer, except that this extractor is used to extract data from the relational database, which will then be used by a different transformer. A business rules engine determines which data fields the extractor should extract.


Transformer:The transformer in this layer uses the data from this layer’s extractor, along with business rules set in the business rules engine in order to transform the data from the relational database into a format accepted by the analysis database. This analysis database will most likely be a graph database (as explained later on in this chapter). This means that the transformer has the following 2 jobs: 1) convert the data from the relational database into a format accepted by the graph database and 2) derivations and aggregations must be made on the data.


Business rules engine:The business rule engine contains a set of business rules that are used for decision making and derivation of information from the data in the relational database. These rules can be set by the users via the configurations module. These business rules can contain for example: <If a user has committed more than 10 .java files, user is an expert on Java>. These business rules will influence the transformer and extractor components, as the extractor must derive from the business rules which data fields to extract from the relational database, while the transformer must transform this data accordingly.


Configuration Module (UI):The configuration module is a module for users to give their input on the conversion of data. As architect it’s hard to determine which queries are necessary for the system to be useful. Next to that, it’s also hard to determine how often these queries will change. Therefore, we decided to create a module where users can decide which data gets converted into which format and which significance each piece of data gets. This way, the user is in full control over their data.


Representation layer


API:The API is a web service that allows one to consult the analysis database. This API will contain a few prefixed queries that can be used for reporting purposes and also contains a free-form part, with which users can construct their own queries. This API can then be used in various client-side applications, such as a report generator or a web client.


Various client components:Based on Previous’ wish, it is possible to create multiple front-ends. All of these front-ends (clients) will use the API for their data access. The design of each client is therefore not important for the overall architecture, as Previous has yet to decide the types of front-ends they would like to use and the API is in all cases the central building block to each front-end.


contains knowledge about
3 logical and implementation view - element catalog


Knowledge Bases


  1. Local
  2. OpenID