Architectural Design Document

Transcription

1 Delta July 5, 2018 Architectural Design Document Version 1.0 Project Team D.P. van den Berg R.T. van Bergen D.J.C. Dekker S. van den Eerenbeemt J. Mols B.F. Rongen B.W.M. van Rooijen R.P. Schellekens A.A. Vast G. Walravens S. Wessel Project Managers S.P.O. Oostveen A. Rajaraman Project Supervisor dr. N. Zannone Customer dr. L. Genga

2 Abstract This is the Architectural Design Document (ADD) for the APD extension developed by Delta. The APD extension adds several features to the existing APD tool, such as user management, experiment management and project sharing. The architectural design decisions in this ADD satisfy the software requirements in the SRD [1]. This document complies with the Software Engineering Standard, as specified by the European Space Agengy [2].

3 Contents 1 Introduction Purpose Scope List of definitions and abbreviations List of definitions List of abbreviations List of references Overview System overview Background Context and basic design Design decisions Extending the APD tool Programming language Operating system Model-View-Controller design pattern Client-server model Web interface Access control System context APD tool MySQL Implementation of MySQL SMTP mail server Implementation of the STMP mail server System design Design method Decomposition Back-end decomposition Front-end decomposition File structure Database Design Components 24 6 Feasibility and resource estimates Resource requirements Using the web application Hosting the Delta extension Developing the Delta extension Performance Requirements traceability matrix Software requirements to modules Modules to software requirements Back-end modules Front-end modules

4 Document Status General Title of document Architectural Design Document Document identifier Delta.ADD/1.0 Version 1.0 Authors D.P. van den Berg R.T. van Bergen D.J.C. Dekker S. van den Eerenbeemt J. Mols B.F. Rongen B.W.M. van Rooijen R.P. Schellekens A.A. Vast G. Walravens S. Wessel History Version Date Author(s) Reason D.P. van den Berg S. van den Eerenbeemt J. Mols B.W.M. van Rooijen S. Wessel Inital draft D.P. van den Berg Added section 4 and implemented S. van den Eerenbeemt feedback. J. Mols B.W.M. van Rooijen R.P. Schellekens S. Wessel Delta Architectural Design Document 4

5 Document Change Records Section Reason 4.2 Added component decomposition. Delta Architectural Design Document 5

6 1 Introduction 1.1 Purpose The Architectural Design Document (ADD) describes the fundamental design of the software that will be developed by the Delta team. In this document, an overview of the system is provided. This document also describes the design decisions that were made, and describes the decomposition of the software into several components. It is also specified which software requirements in the SRD [1] each component fulfills. 1.2 Scope The APD tool is designed to extract anomalous patterns together with their correlations. These patterns are extracted from historical logging data from past process executions. Users can upload event logs and process models on which experiments can be run. The results of these experiments can be visualized after they are completed [3]. The purpose of the Delta extension is to extend the currently existing APD tool with several features. First of all, this extension will support multiple users, which means the tool will need to have proper user management controls. The user management system will be created and several improvements have to be made to the user interface in order to realize these goals. Next to this, visualization of the results is important, as well as reporting on the progress of the experiments. The tool is currently able to discover patterns and subgraphs from a business process model and an event log. These patterns and subgraphs give information on the business process and anomalous traces in the event log. In the current version, however, comparing different result types is cumbersome. Delta will provide a more convenient way to manage experiments and their results as well as the projects they belong to. Furthermore, the administrator will be able to manage the users and the projects created by users, as well as monitor the user activity tracking of each individual user. These controls will also be provided by Delta. 1.3 List of definitions and abbreviations List of definitions Administrator Anomalous subgraph discovery APD tool Business process Child subgraph Component A registered user with the highest available access rights who manages both the tool and its users. The extraction of recurrent subgraphs involving one or more deviations from the process model [3]. The APD tool is an extension of the Esub tool designed to extract anomalous patterns together with their correlations. These patterns are extracted from historical logging data from past process executions. Users can upload event logs and process models on which experiments can be run. After the experiments are completed, the tool supports the users in exploring the obtained results [3]. A set of activities performed in an organization and technical environment that are coordinated to a certain product or service [4]. The child S of a subgraph S is a subgraph which involves S in its definition. A part of a phase of an experiment. Delta Architectural Design Document 6

7 Esub tool Experiment Experiment log Experiment phase An online webtool supporting the visualization and exploration of the outcome of the frequent subgraph mining algorithm SUBDUE [5]. Both the anomalous subgraph discovery and partial order discovery together. A file that tracks all activities performed within an experiment. Anomalous subgraph discovery and partial order discovery are the two phases of one experiment. Event log file A file that consists of traces [3]. Final Result Graph.g file Intermediate result Maximal subgraph Minimal subgraph The outcome of an experiment. A file that collects multiple graphs, each involving a set of edges and vertices. The outcome of either a component or an experiment phase. A subgraph s is maximal in a set of subgraphs if there does not exist a subgraph s such that s is a supergraph of s. A subgraph s is minimal in a set of subgraphs if there does not exist a subgraph s such that s is a subgraph of s. Parent subgraph A subgraph S is a parent of another subgraph S if S is a child of S. Partial order discovery Petri net An experiment phase creating patterns from anomalous subgraphs and partially ordering them based on their location in the log traces [3]. A mathematical model used for the specification and the analysis of parallel processes [6]. Process model A representation of the prescribed behavior of a business process [3]. Project Project owner Registered user Responsive Result Subgraph Supergraph Support A combination of an event log, a process model, and a unique project name. The project is stored together with any experiments run under that project name. The user who created the project. A user with a registered account on the APD tool. A website is responsive when dynamic changes are made to the appearance of the site depending on the screen size and orientation of the device being used to view it [7]. Either an intermediate result or final result. A graph whose vertices and edges are subsets of the vertices and edges of another graph [8]. A graph S is a supergraph of graph S if the vertices and edges of S are a subset of the vertices and edges of S. The support of a subgraph/pattern is equal to the fraction of graphs which involve the subgraph/pattern at least once [3]. Delta Architectural Design Document 7

8 Synchronous function Trace Unregistered user User User activity User activity log User tracking Valid A task that have to be completed before a new task can be called. A trace in a business process model is a sequence of events generated during a process execution. A user who does not have an account on the APD tool. A person who is currently using the APD tool or who has previously used the APD tool. Creating a project, viewing a project, viewing or downloading a project s files, deleting project files, sharing a project, starting or stopping an experiment phase, viewing results and status of an experiment phase, logging in, or logging out. A file containing information on the past user activities on the APD tool. The act of tracking the behavior of the user on the APD tool in the form of the user activity log. An address of a registered user is valid when it exists and the user has access to it List of abbreviations AJAX URD SRD ADD MVC Asynchronous JavaScript and XML User Requirements Document Software Requirements Document Architectural Design Document Model-View-Controller 1.4 List of references [1] Delta. Software requirements document, version Technical report, Eindhoven University of Technology, [2] ESA PSS-05-0 Issue 2. Software requirements and architecture engineering process. Technical report, European Space Agency, [3] L. Genga, M. Alizadeh, D. Potena, C. Diamantini, and Nicola Zannone. APD tool: Mining anomalous patterns from event logs. CEUR workshop proceedings [4] Wil MP van der Aalst and Christian Stahl. Modeling business processes: a petri net-oriented approach. MIT press, [5] C. Diamantini, L. Genga, and D. Potena. Esub: Exploration of subgraphs. In Proceedings of the BPM Demo Session, pages 70 74, [6] A. Finkel. The minimal coverability graph for Petri nets. In Proceedings of International Conference on Application and Theory of Petri Nets, pages Springer, [7] A. Schade. Responsive web design (RWD) and user experience. articles/responsive-web-design-definition/, Accessed: [8] P. Black. Subgraph Accessed: Delta Architectural Design Document 8

9 [9] Delta. User requirements document, version Technical report, Eindhoven University of Technology, [10] Domenico Potena Claudia Diamantini, Laura Genga. Esub: Exploration of subgraphs. Technical report, Universitá Politecnica delle Marche, [11] Nikhil S Ketkar, Lawrence B Holder, and Diane J Cook. Subdue: Compression-based frequent pattern discovery in graph data. In Proceedings of the 1st international workshop on open source data mining: frequent pattern mining implementations, pages ACM, [12] Domenico Potena Claudia Diamantini Nicola Zannone Laura Genga, Mahdi Alizadeh. Apd tool: Mining anomalous patterns from event logs. In Proceedings of the BPM Demo Track and BPM Dissertation Award, [13] Glenn E Krasner, Stephen T Pope, et al. A description of the model-view-controller user interface paradigm in the smalltalk-80 system. Journal of object oriented programming, 1(3):26 49, [14] Materialize front-end framework. Accessed: [15] Google material design website. Accessed: [16] Phpmailer. Accessed: [17] Valgrind. Accessed: [18] Massif visualizer. Accessed: Overview The remainder of this document is composed of sections that describe the architectural design of the Delta extension. Section 2 provides an overview of the system, together with all design choices that were made. For every design choice, a detailed description is presented, together with its alternatives and rationale. In Section 3, the system context is described, by outlining the relations of the tool to external systems. Section 4 contains the system design, listing the design methods used as well as a description of the decomposition of the system into individual components. In Section 6, an estimate is provided on the computer resources needed to build, operate, and maintain the software. Finally, in Section 7, a requirements traceability matrix is provided. This matrix shows how the software requirements of the SRD [1] are linked to the components described in Section 4.2. Delta Architectural Design Document 9

10 2 System overview The APD tool and the Delta extension offer users a platform with which they can run experiments on their own process models and event logs. A general description of the APD tool and the Delta extension can be found in the User Requirements Document (URD) [9]. For a more in-depth description of the relevant background of the Delta extension and the environment of the project, Section 2.5 of the URD [9] and Section 2.7 of the SRD [1] are recommended reading. 2.1 Background In 2015, the Esub tool was created by a group of researchers, one of whom is now the product owner [10]. This tool visualizes large sets of subgraphs generated by frequent subgraph mining algorithms such as Subdue [11]. Two years later, the Esub tool was extended with a plugin for performing anomalous subgraph discovery and partial order discovery, which became the APD tool [12]. The Delta team will extend the APD tool with additional functionality and has improved the usability of the tool. The interface of the tool will be reworked to be more user friendly and to be more convenient to work with. This is done by providing a more streamlined workflow and by having clearly sectioned components, both visually and logically. Furthermore, the Delta extension will add functionality such that users are able to register for an account and manage their own projects and experiments. Moreover, functionality will be added such that users are able to share their projects with other users. In this sharing process, users can control the access rights that other users have on their projects. Additionally, the Delta extension will add functionality such that users can see the status of their experiment phases. Users will be able to see the progress of the experiment phase so far, any intermediate results, and whether any errors have occurred. Next to this, the Delta extension will make the running of experiment phases more modular, making it possible to skip several parts of the running if their intermediate reesults have already been uploaded by a user. Finally, the Delta extension will add more extensive possibilities to compare the results of different experiments. 2.2 Context and basic design The APD tool is hosted on a server and users can access the tool via a web page. The web page is loaded on a local browser. This setup results in three main elements: the web interface, the Delta server, and the APD tool. When the web interface makes a request to the Delta server, a back-end interface located on the server will handle the requests instead of them going directly to the APD tool. This interface will send the requested data back to the front-end such that the web interface can update its view. The Delta server makes use of its own database to store users, projects, and experiments. The results of run experiments are separately stored in the databases of the APD tool, because the APD tool gets used by the Delta components as a black box internally. Figure 1 gives an indication of the general system design. 2.3 Design decisions In this section the design decisions by Delta are explained Extending the APD tool The APD tool is already an existing application, and the goal of the Delta team is to introduce additional functionality. Delta will make as few changes as possible to the existing APD tool and use a black box separation model. The main reason for this choice is the complexity of the APD tool. Due to limited resources of Delta and the focus on new functionality, changing the existing software is beyond the scope of Delta. An additional benefit of this clear separation between the APD tool and the extension made by Delta is that both parts can be developed independently. Delta Architectural Design Document 10

11 APD tool Databases User Web interface Network or Internet Delta server Delta database Figure 1: System overview diagram Programming language The APD tool was written in PHP version 5.3, which is a deprecated version of PHP that reached end-of-life in Delta has numerous options in choosing a programming language: 1. Also use PHP 5.3 for the Delta extension. 2. Migrate to a more recent version of PHP 5. This includes updating the APD tool to a different version of PHP Migrate to PHP 7, which is currently the recommended version of PHP. This includes updating the APD tool to PHP Use a different programming language for the Delta extension. This means that we need to find a way to communicate with the old code in another programming language. If at all possible, we want to avoid using PHP 5.3. The fact that this version reached end-of-life and does not receive any more security updates makes it a unfavorable choice. We would prefer upgrading the tool to PHP version 7, as this is the recommended PHP version. It will increase the life span and maintainability of the tool. However, this involves migrating the existing APD tool source code since PHP 7 introduces breaking changes compared to PHP 5.3. The amount of changes that need to be made is of such a scale that it would require too much time to complete this task. In addition, the lack of (unit) tests on the original APD tool makes it hard to verify whether the migration would introduce unwanted behavior. Because of this, migrating to PHP 7 is outside the scope of Delta. Using a programming language different from PHP for the Delta extension is another option. The main advantage is that we have more freedom in choosing the best tools for the tasks that we need to complete. However, part of the functionality the Delta extension needs to include requires making changes to the original APD tool. Therefore, it is required to make changes to PHP code, and is thus easier if the Delta extension and the original APD tool are written in the same language. This leaves PHP 5 as the programming language for the Delta extension as the preferred option. To increase maintainability, we still want to migrate to the most recent version of PHP 5, which is PHP 5.6. Not all libraries that the original APD tool uses in particular the Graphviz library did not function properly with this version of PHP. Since alternatives for these libraries require too many changes to the original APD tool source code, using PHP 5.6 is not feasible for this project. The most recent version for which all dependencies are available is PHP 5.5, which is the version of PHP the Delta extension will use Operating system The server on which the original APD tool is hosted uses CentOS 5 as operating system. This operating system has currently reached end-of-life in 2017 and is not recommended to use for security Delta Architectural Design Document 11

12 reasons. Migrating to a more recent operating system is preferred. Since we have to migrate, we also decided to use Ubuntu, since it is more frequently used. Unfortunately, the operating system still needs to support PHP 5.5. This means that it is not possible to use a more recent version than Ubuntu LTS, as this version of Ubuntu is the most recent version which supports PHP 5.5. Therefore, Delta uses Ubuntu LTS Model-View-Controller design pattern For the architectural design, the Model-View-Controller (MVC) [13] design pattern is used. The MVC pattern distinguishes three interconnected components: Model Deals with the data and the corresponding logic and rules. View Displays the information output of the model. Controller Acts as an interface between input devices and the model and view. It transmits input to commands for the view or model. The main motivation for applying MVC design pattern is the clear separation between data, user interface and user interaction. This separation eases simultaneous development and code reuse. When the user interacts, the controller processes this action and the model will be modified accordingly. When the model changes, the controller is again notified and updates the view. An alternative to the MVC design pattern is the Model-View-Presenter (MVP) pattern. This pattern lets the view and presenter communicate with each other through an interface. This does require the view to have some logic, which we want to avoid in the Delta extension. A complete decoupling between the view and the model is also difficult to achieve. The experiment results are products of the model which the view would have to present almost as-is. With the MVC pattern, this decoupling is not needed. The three components in the MVC pattern are represented by different parts of the Delta extension. The model is the part of the back-end which updates user, experiment, and project data whenever the controllers orders to do so. In other words, all data in the databases and components of the Delta extension which are able to change this data make up the model component. The controller component consists of all our back-end handlers that handle incoming requests made by the view component. For every request there is a handler that makes the right changes to the model. Requests can range from a registration request to a request for interacting with experiment results. The web pages and front-end scripts together form the view component, as these parts show information and an interface to the user. This works efficiently for the Delta extension as the model almost never changes without the input from a user. This way, one functionality from the tool can usually be described by a request made by the view (a script calling to the back-end), a handler working on this request by either retrieving data from, or updating data in, the model Client-server model The extension of the APD tool also makes use of a client-server model. A user uses the web interface (client) to interact with the tool. The Delta server handles all requests and delivers responses. The Delta server uses the standard HTTP protocol, which is why client-server model is inherently used. It is able to handle actions of multiple users at the same time and make collaboration between different users possible. One other alternative could be the peer-to-peer model, which decentralizes the application. Aside from providing more redundancy, the peer-to-peer model also distributes the processing of data among the peers. The Delta extension would not benefit from this, since this introduces unnecessary complexity, and thus this model is not chosen Web interface The web interface uses the Materialize library [14] as front-end framework. Materialize is based on Material Design by Google [15] and aims to have a responsive, user-friendly interface. This framework was chosen because the design corresponds best with our preferences. Two important Delta Architectural Design Document 12

13 factors in this choice are the inherent responsiveness of the framework and the ease of developing with it. The web interface is designed as a single page application. There is one main html file which consists of the navigation menu and the title bar. Within this main file the content of other pages is loaded using Javascript. This type of design was chosen as all pages have the same layout, with a navigation menu and header, thus only loading the content for each page speeds up load times. This makes for a better user experience as a user can navigate the tool more quickly. For every page where information from the back-end is needed the web interface makes use of post requests via AJAX. By using AJAX calls the web interface no longer needs to be refreshed, instead only the updated sections of the page are reloaded. Using AJAX, the traffic payload between client and server will be reduced which will lead to improved performance. Every request via an AJAX call is sent to a specific handler in the back-end. When the requested data is sucessfully returned, the web interface is updated with the retrieved information Access control For access control, we use the role-based model, often referred to as the role-based access control (RBAC). Each role can have zero or more access permissions assigned to it. Roles are hierarchical, meaning that one role can inherit permissions from other roles. Permissions can be categorized into project permissions, experiment permissions and general permissions. Project permissions include downloading files, deleting files, deleting the project, sharing the project and creating experiments within the project. Experiment permissions include running an experiment phase and viewing the results. General permissions include, for example, enabling or disabling user tracking. Roles include the administrator, unregistered user, registered user, project owner, project observer and project member. For example, project observers can only view the results of experiments in the project, while project members can also create and run experiments within this project. Hence, the project member inherits the permissions of the project observer. The project owner inherits the permissions of a project member, while also having additional permissions such as project deletion and project sharing. An alternative to the role-based access control model is using an access control matrix. This model uses a table with a row for each user and a column for each resource (for example an experiment). For every pair of user and resources, the matrix stores which operations are allowed. Although it is easy to use this system, the matrix is very hard to maintain as the hierarchy is not saved. Because user permissions are frequently changed, especially with the sharing of projects, maintainability is an important factor in this decision. Therefore, the access control matrix was not chosen. For more details on the user roles, see Section 2.4 of the URD [9]. Delta Architectural Design Document 13

14 3 System context 3.1 APD tool The Delta extension of the APD tool is isolated, but it does communicate with the original tool. As described in Section 2.3.1, the original tool is used as a black box. This means that Delta uses a facade for all communication with the APD tool. The facade implements an interface, describing all functionality that is needed from the APD tool. It mainly contains functions for starting experiment phases, checking whether they are finished and viewing their results. Expanding subgraphs is also handled with the facade. The following APD tool functionality is implemented in the facade interface: Start the execution of the anomalous subgraph discovery phase of a given experiment. Start the execution of the partial order discovery phase of given experiment with a specified ordering relation threshold and a frequent itemset threshold. This phase can only be started after the anomalous subgraph extraction phase has finished. Check if the anomalous subgraph extraction phase of a given experiment is finished. Check if the partial order discovery phase of a given experiment is finished. Retrieve the result of the anomalous subgraph discovery phase of a given experiment. Retrieve the result of the anomalous subgraph discovery phase of a given experiment, where specified subgraphs are expanded. The result is returned as an SVG graph. Retrieve the result of the anomalous subgraph discovery phase of a given experiment, where only the specified subgraphs are displayed. The result is returned as an SVG graph. Retrieve the result of the partial order discovery phase of a given experiment. The result is filtered on a given support threshold and pattern type (minimal, maximal, or all). The result is returned as an SVG graph. Retrieve the result of the partial order discovery phase of a given experiment, where specified patterns are expanded. The result is filtered on a given support threshold and pattern type (minimal, maximal, or all). The result is returned as an SVG graph. 3.2 MySQL MySQL is a stable, free, and open source relational database management system. Delta uses this database system to store the user and project data. PHP 5.5 has a built in interface for MySQL servers. The Delta extension of the ADP tool uses this interface mysqli to query data from the database and to store new data in the MySQL database Implementation of MySQL By preparing query statements according to the needs of a back-end request, the mysqli interface can be used to prepare queries. These queries are then executed, which can result in selection, insertion, modification, or deletion of entries in the database. When entries from the database need to be retrieved, these entries can also be stored in parameters by using the mysqli interface s functions. 3.3 SMTP mail server Some functionality of the Delta extension depends on being able to send s. For this purpose, access to an SMTP mail server is required. A registered address at the mail server is used via which Delta can send s to the users of the tool. Delta Architectural Design Document 14

15 The PHPMailer library [16] is used as an interface to the SMTP mail server. Using this library, s can be sent using a secure protocol like ssl, while still running on the older PHP 5.5 version Implementation of the STMP mail server To send an with the STMP mail server an is fully prepared before sending, similar to how MySQL queries are prepared before execution. An s properties, such as the sender, receiver, content, and title, are filled in. When the object is complete, a call to the STMP mail server is made to send the created . As previously mentioned, a secure protocol to send the can be selected. Delta Architectural Design Document 15

16 4 System design This section describes the technical aspects of the Delta extension to the APD tool. Subsections contained here will describe the design method, the decomposition of the system, and the individual components of the system. 4.1 Design method Only the design methods and architectural styles that apply to the Delta extension of the APD tool will be described here. In order to be able to use all functionality offered by the APD tool, an interface between the back-end and the APD tool is made. This reduces coupling between the APD tool and the Delta extension, thus allowing the APD tool to be used as a black box. The facade design pattern is used to realize this interface. A modular design method was used to separate the Delta extension into several different modules. In doing so, coupling is reduced and cohesion is increased. Furthermore, the decomposition of the system increases maintainability and verifiability through running automated tests. The following section elaborates upon the different components in the decomposition of the Delta extension. 4.2 Decomposition The decomposition of the Delta extension into individual components is based on the user requirements specified in the URD [9] and the specific requirements specified in the SRD [1]. The back-end of the Delta extension was split into several components, based on the functionality the Delta extension will add to the APD tool. The back-end has modules for the database and the database API, as well as for handling account management, user tracking and authentication. Furthermore, modules handling projects, experiments, experiment phases and components. Lastly, experiment results will be handled in a separate module. All these modules will be detailed in the section below. The front-end of the Delta extension was split based on the different pages the Delta extension web application will consist of. The front-end was split into a module for page navigation, the home page, the project page, the experiment results page and the compare results page. Furthermore, registration and login are handled in a separate module, just like the admin tools page. The request handler module was used as to handle the communication between the front-end and back-end modules. All front-end requests are sent to the request handler, which in turn communicates the request to the appropriate back-end module. Figures are used to describe the dependencies between modules. In each figure an arrow indicates that one module depends on the other, which means that in order for a module to function properly functionality from the other module is required Back-end decomposition All modules of the back-end decomposition will now be described. Figure 2 displays the communication between the back-end modules. Note that all modules of the back-end are connected to the request handler module and the database API. In order to keep the figure readable, we have not included these modules. Keep in mind, however, that they are a part of the back-end. APD module The APD module provides an interface between the Delta extension and the APD tool. The APD module will be used to start the execution of experiment components and provide component and experiment result data. Furthermore, the APD module will be used to retrieve data on expanding subgraphs and patterns in experiment results. This data can be displayed in the user interface of the Delta extension. Delta Architectural Design Document 16

17 Back-end Authentication module User Tracking module Account module Project module Experiment module Experiment result module Experiment Phase module Component module APD module Figure 2: Back-end communication Delta extension APD module APD tool Figure 3: APD module communication Delta Architectural Design Document 17

18 Back-end Database Database API Figure 4: Request module communication Front-end Navigation Registration... Request handler Account module Authentication... Back-end Figure 5: Request module communication Database The database component stores the Delta extension data according to the data model. The database management system is MySQL, which provides an interface to insert, manipulate and remove data. Database API The database API provides interfaces used to retrieve, insert, update and delete the data in the Delta database. This API is used by all back-end components. Note that these connections were not drawn in Figure 2 in order to keep the figure readable, but these connections do exist. Figure 4 displays the communication between the database API and the database. Request handler module The request handler module is responsible for handling data requests from the front-end by means of the database API. It is also responsible for the communication between the front-end requests and the back-end modules. Figure 5 displays the communication between the front-end, the request handler and the back-end modules. The request handler module is thus used by all back-end components. Note that these connections were not drawn in Figure 2 in order to keep the figure readable, but these connections do exist. Account module The account module implements functionality and interfaces related to account management. This includes the creation and deletion of user accounts, retrieving and editing account information of user accounts as well as changing and resetting user passwords. This module handles the consent acceptance of a user. Authentication module The authentication module is responsible for checking the access rights of users. Furthermore, it handles everything with regards to the authentication of users, including logging in and out. The authentication module checks whether a user can create, view, edit, delete or run a given object by Delta Architectural Design Document 18

19 means of authentication and permission checking. The sharing of projects is also handled with this module, in close relation with the project module. User tracking module The user tracking module tracks the activities of all users of the tool. It handles both the retrieval and deletion of user activity logs and handles whether tracking is enabled or disabled for a specific user. Project module The project module implements functionality and interfaces related to project management, including the creation and deletion of projects and project files. It also handles the creation of a batch of experiments within the project. Note that the demo project of the tool is also managed by this module. The calculation of the comparative results of several experiments is also handled by this module, in close relation with the experiment results module. Experiment module The experiment module implements functionality and interfaces related to experiment management. This includes the creation and deletion of experiments as well as the retrieval and deletion of the experiment log. Experiment phases module The experiment phases module implements functionality and interfaces related to experiment phase management. This includes the creation, running, cancelling and deletion of experiment phases, which includes handling the status of the experiment phase, as well as the handling of intermediate results uploaded by a registered user of the tool. The experiment phase log entries are also handled by this module. This module operates in close relation to the component module, when running an experiment phase. Component module The component module implements functionality and interfaces related to components, which includes the creation, running, cancelling and deletion of components. It also handles the status of the component. This module works in close relation with the APD module for the running of components and retrieving their results. It also handles the uploading of a custom component by an administrator of the tool. Experiment results module The experiment results module handles requests with regards to experiment results. This includes the retrieval and deletion of experiment results, as well as the expansion, compression and filtering of provided subgraphs and patterns. Note that this module works in close relation with the APD module in order to achieve this. It handles the retrieval of specific information of subgraphs and patterns, such as the number of occurrences and support value of the subgraph or pattern, in close relation with the component module. Exporting subgraphs to PNG or.g files is also handled by this module. Lastly, it handles the retrieval of parents and children of a given subgraph Front-end decomposition All modules of the front-end decomposition work in close relation with the request handler module of the back-end decomposition. All requests of front-end modules are communicated to the request handler module, which then transfers the request to the appropriate back-end module. All modules of the front-end decomposition will now be described. Figure 6 displays the communication between the front-end modules. Note that the navigation module uses all modules except the registration and login module, because there is one main html file which consists of the navigation menu and the title bar and within this main file the content of other pages is loaded using javascript. Delta Architectural Design Document 19

20 Front-end Registration module Login module Home module Project module Results module Navigation module Compare resuls module User Information module Figure 6: Front-end communication Navigation module The navigation module handles the visualization and form validation of the main html page, the side navigation menu and the breadcrumbs menu. Furthermore, it implements requests and handles requests with regards to the retrieval of the breadcrumbs navigation of a user and page navigation between pages of the Delta extension, such as the home page, project page and experiment results page. Moreover, it handles the logging out of a user. Note that in Figure 6 the navigation module uses all modules except the registration and login module, because there is one main html file which consists of the navigation menu and the title bar and within this main file the content of other pages is loaded using javascript. Registration module The registration module handles the visualization and form validation of the registration page. Furthermore, it implements functionality and handles requests with regards to the registration of user accounts. Login module The login module handles the visualization and form validation of the login page and the forgot password page. Furthermore, it implements functionality and handles requests related to the logging in of a user. This also includes the resetting of a user s password, and transferring requests to view the demo project to the project module of the front-end decomposition. Home module The home module is responsible for the visualization and form validation of the home page, the modal for project creation and the modal for project sharing. Furthermore, it implements functionality and handles requests related to the retrieval, sorting and filtering of the projects list available on the home page. Furthermore, it handles requests with regards to the creation, deletion, searching, sharing and file retrieval of projects. Project module The project module is responsible for the visualization and form validation of a project page and the modals for experiment and experiment phase creation. Furthermore, it implements functionality and handles requests related to the retrieval and filtering of the experiment list available on a project page, as well as handling requests with regards to the creation and deletion of experiments, the running and cancelling of experiment phases. It handles the retrieval and visualization of an experiment phase status. Moreover, it handles the downloading and deletion of the experiment log and other experiment files. Lastly, it communicates requests to view and compare experiment results to the results module and the compare experiments module, respectively. Results module The results module is responsible for the visualization and form validation of a results page. Fur- Delta Architectural Design Document 20

21 thermore, it implements functionality and handles requests related to the selection, deselection, expansion, compression, filtering and searching of subgraphs and patterns. Moreover, it handles the opening of subgraphs in another tab, the downloading of result files, and the indication of parents and children of subgraphs. Compare experiments module The compare experiments module handles the visualization and form validation of the compare experiments page. It is responsible for retrieving the comparative results of several experiments as well as the retrieval and sorting of the experiment list displayed on the experiment page. It communicates requests to view and compare other experiment results to the project module. User information module The user information module is responsible for the visualization and form validation of the user information page. Furthermore, it implements functionality and handles requests related to the retrieval and editing of a user s account information, as well as the retrieval and deletion of the user s activity log and the changing of a user s password. Lastly, it handles requests for user account deletion. Admin tools module The admin tools module is responsible for the visualization and form validation of the admin page. Furthermore, it implements functionality and handles requests related to the retrieval, creation and deletion of users of the tool as well as the uploading of custom components. Moreover, it handles requests with regards to the enabling and disabling of tracking a users activities, the retrieval and deletion of a users activity log and resetting the password of a user. Lastly, it handles the uploading of custom anomalous subgraph discovery algorithms File structure The file structure of the project is given below. Files and code from the existing APD tool are separated as much as possible from the files and code added by Delta. root... Application root folder database... Database structure files Esub... Main project folder delta... Delta extension source apd... APD tool communication esub... APD tool interface implementation files database... Database API exceptions... Custom exceptions files... User-uploaded project files handlers... Request handlers images... Static image resources model... Data model definition pages... Front-end pages requests... View logic of the request handlers scripts... Static front-end JavaScript files session... Session utilities settings... Application-wide settings styles... Static front-end CSS files utils... General utilities execution... Utilities related to system command execution mail... Utilities related to systems validation... Data validation GraphManager... Original APD tool source lib... External libraries fonts... External fonts mail... libraries Delta Architectural Design Document 21

22 node_modules mdi... random_compat... scripts... Material design icon resources Password hashing compatibility library Vendor JavaScript files Vendor CSS files Test files for Delta extension APD tool communication tests Database API tests Demo project files (test resources) Data model definition tests View logic of the request handlers tests Test resources Session utilities tests Application-wide settings tests Test utility files General utilities tests Execution tests system tests Data validation tests styles... test... apd... database... demofiles... model... requests... res... session... settings... testutils... utils... execution... mail... validation Database Design The Delta extension uses a traditional relational database model, implemented with MySQL. We use the following tables: user Basic user account information. user_profile Optional user profile information. user_profile_consent Records when and how the user gave consent for the privacy statement (required for GDPR compliance). consent_text Records the versions of the privacy notice consent text used on the registration page. reset_token Records password reset tokens for users, if a user requested such a token. project Records project information. experiment Records experiment information. experiment_status_history Records status changes for the experiment phases. experiment_status Lists the possible experiment phase status descriptions. experiment_phase Lists the experiment phases. The database schema with indicated primary and foreign keys is depicted in Figure 7. Delta Architectural Design Document 22

23 User Profile id : int(11) User Profile Consent user_id : int(11) first_name : varchar(64) last_name : varchar(64) organization : varchar(255) role : varchar(255) country : varchar(64) city : varchar(64) address : varchar(255) heard_about : varchar(255) id : int(11) user_id : int(11) timestamp : timestamp consented : tinyint(1) consent_text_id : int(11) method : text consent_text_id:id id : int(11) Consent Text text : text creation_date : timestamp user_id:id user_id:id Reset Token token : varchar(32) user_id : int(11) creation_date : timestamp used : tinyint(1) user_id:id id : int(11) User username : varchar(64) password : varchar(256) varchar(64) is_admin : tinyint(1) user_id:id id : int(11) User Tracking user_id : int(11) operation : varchar(255) performed : timestamp creator_id:id owner_id:id user_id:id user_id:id id : int(11) Experiment project_id:id id : int(11) Project Project Observer name : varchar(64) project_id : int(11) creator_id : int(11) creation_date : timestamp name : varchar(64) project_id : int(11) creator_id : int(11) creation_date : timestamp project_id:id project_id : int(11) user_id : int(11) experiment_id:id project_id:id Experiment Status History id : int(11) experiment_id : int(11) status_id : int(11) creation_date : timestamp component_id : int(11) status_id:id Experiment Status id : int(11) description : varchar(256) Project Member project_id : int(11) user_id : int(11) component_id:id Component id : int(11) name : int(11) phase_id : int(11) phase_id:id Experiment Phase id : int(11) name : varchar(256) Figure 7: Database structure Delta Architectural Design Document 23

24 5 Components This section is omitted. Delta Architectural Design Document 24

25 CPU RAM Software 1.3 GHz x86 or equivalent 256 MB Google Chrome version 66 or later Table 1: Estimated minimum resource requirements for using the web application. CPU RAM Storage Operating System Software Dual core 2.0 GHz x86 or equivalent 8 GB 2 TB Ubuntu Server LTS PHP with modules json, mysql, tokenizer, and openssl, Apache 2.4.7, MySQL 14.14, Graphviz , Java Runtime Environment 1.8.0_171, SUBDUE 5.2.2, Autodue, libgv-php Table 2: Estimated minimum resource requirements for hosting the Delta extension. 6 Feasibility and resource estimates This section gives an estimate for the required resources to run the Delta extension to the APD tool. Based on these requirements, an estimate for the performance of the Delta extension under these resources is given. 6.1 Resource requirements In this section, a distinction is made between accessing the Delta extension as a user via the web browser, hosting the Delta extension on a web server, and developing for the Delta extension Using the web application The requirements for accessing the web application as a user are given in Table 1. The estimates are based on the minimum system requirements for the Google Chrome web browser application. Since most of the computational work is done on the server side, little extra memory and processing resources are needed for the actual Delta extension web pages Hosting the Delta extension The requirements for hosting the Delta extension on a web server are given in Table 2. The requirements of the hosting server are based on the estimated requirements of the existing APD tool, as a large part of server-side processing is performed. Therefore, we recommend at least a dual core processor, to allow for concurrent execution of the experiment phases. Since the experiment processing requires the loading of large graph and log files in memory, we also recommend 8 GB of available RAM. See Section 6.2 for more details on memory usage. The Delta extension of the APD tool enables users to upload their own project files, on which no specific size limit is determined. Based on existing experiments on the APD tool, an experiment with both phases executed will not exceed 100 MB in size. Therefore, based on the requirement that the Delta extension supports 200 registered users, we recommend a storage size of 2 TB Developing the Delta extension The requirements for hosting the Delta extension on a web server are given in Table 3. The development environment requirements are similar to the hosting environment requirements. Delta Architectural Design Document 25

26 CPU Dual core 2.0 GHz x86 or equivalent RAM 8 GB Storage 64 GB Operating System Ubuntu Server LTS Software All software required for the hosting environment, including PHP modules dom, phar, xdebug, PHPUnit Table 3: Estimated minimum resource requirements for developing the Delta extension. Figure 8: Massif heap memory profiler visualization. We include a number of extra tools related to running unit tests and a debugger to ease the development process. 6.2 Performance Using the heap memory profiling software Massif, available in the Valgrind framework [17], we analysed the memory usage of processing a single experiment. We used a log file of 49 MB, containing 24 traces and 903 events. The output of Valgrind is visualized using Massif visualizer [18] and depicted in Figure 8. We see a peak heap usage of approximately 100 MB for a single, relatively small experiment. Note that the Delta extension allows processing of multiple experiments (possibly by different users) in parallel. Also, the log files uploaded by users can vary in size and be well over multiple gigabytes. Taking these variables into account, we recommend a sizeable memory capacity for the system processing the experiments. Delta Architectural Design Document 26