## 2 MWDEX: Moodle Workshop Data EXtractor
### Architecture Design  
On the basis of the application design principles outlined in the previous Section, MWDEX ([[https://github.com/TIGE-UPM/MWDEX](https://github.com/TIGE-UPM/MWDEX)]([https://github.com/TIGE-UPM/MWDEX](https://github.com/TIGE-UPM/MWDEX))) is configured following a model-view-controller approach and comprises three different components, a Moodle web service, the application (and application server), and the front-end or user interface (web browser). The web service enables access to the necessary Moodle core web service functions (detailed in Section 2.3) that establish a communication using the REST protocol with the web application (which can be run from a single computer as localhost or from a web server). The web application makes the data request to the LMS; this request is handled by the Moodle web services infrastructure, which gives a response with the necessary data in JSON format. Upon data reception, the web application processes the data and returns an MS Excel or JSON file with information about peer assessments for download; alternatively, the JSON file can also be processed to return an interactive visualization of the information in the web browser.  
The process depicted in Figure 3, which summarizes the operation of MWDEX, can be explained in the following sequential stages:  
1. The user (most likely, a teacher or course administrator) accesses the web application using a web browser (leftmost part of Figure 3), and enters his or her authentication details in Moodle, including the URL of the Moodle instance and the name of the web service. The web service needs to be activated in Moodle. The different functions of the web service are explained in further detail in Section 2.3.
2. The HTTP request is passed from the browser to the web application.
3. The web application requests the user's token.
4. If authentication credentials are correct, Moodle returns the token that the system uses for the following requests; otherwise, MWDEX shows a logon error message.
5. Using the token, the web application requests the list of courses available for that user in Moodle.
6. Moodle returns the list of courses in JSON format. The list could be empty if the user cannot access any course or no course exists in the Moodle LMS.
7. The web application retrieves the list of courses and displays it in the web browser.
8. The user selects a course and sends a request for the workshops available in that course, which is passed to Moodle via the web application.  
Figure 3: Graphic overview of Moodle Workshop Data EXtractor (MWDEX).  
If the user is not enrolled in the course, an error is returned. Otherwise, Moodle returns the list of workshops for that course in JSON format. The list can be empty if no workshops are defined in the course in the Moodle LMS.  
The web application requests the list of users enrolled in the course and the list of course workshops.  
The user selects what type of output he or she wants to receive. Upon user confirmation, the web application requests all the information of assessments for the selected workshop.  
Moodle returns workshop peer assessment information in JSON format.  
For each user, the web application populates a variable listing all the information about each submission assessed. This process is explained in more detail later on in this document.  
After collection of all data, the web application generates the output file (in MS Excel format or JSON).  
Depending on the type of output requested, the browser prompts the user for file download (MS Excel), displays a JSON file for download, or creates an interactive pivot table or graphs for data presentation and analysis using the JSON output.