System to predict bipolar disorder crises analysing massive data

SYSTEM TO PREDICT BIPOLAR DISORDER CRISES ANALYSING MASSIVE DATA Ana María Martínez Gómez DOUBLE DEGREE IN COMPUTER SCIENCE AND MATHEMATICS COMPUTER SCIENCE FACULTY COMPLUTENSE UNIVERSITY OF MADRID BACHELOR THESIS 5 o academic year 16th June 2016 Director: GUADALUPE MIÑANA ROPERO Codirector: MARÍA VICTORIA LÓPEZ LÓPEZ Contents List of gures iii List of tables v Abstract vii Keywords ix 1 Introduction 1 1.1 Objectives .................................. 1 1.2 Antecedents ................................. 1 1.3 Work plan .................................. 2 1.4 State of the art ............................... 2 1.4.1 NoSQL databases .......................... 2 1.4.1.1 Key-value databases ................... 3 1.4.1.2 Document-based databases ............... 4 1.4.1.3 Conclusion ........................ 6 1.4.2 Streaming processing with Spark ................. 6 1.4.3 Neural networks ........................... 13 2 MongoDB database 21 2.1 Features ................................... 21 2.1.1 Queries ............................... 21 2.1.2 Transactions ............................. 22 2.1.3 Availability ............................. 22 2.1.4 Consistency ............................. 22 2.1.5 Scaling ................................ 23 2.2 Learning MongoDB ............................. 23 2.3 Database for the project .......................... 24 2.3.1 Installation and conguration ................... 24 2.3.1.1 Development ....................... 24 2.3.1.2 Production ........................ 25 2.3.1.3 Authentication ...................... 26 2.3.2 Design ................................ 27 2.3.2.1 Colletions ......................... 27 2.3.2.2 Users and roles ...................... 34 2.3.2.3 Indices ........................... 35 2.3.3 Queries ............................... 37 2.4 Integration .................................. 40 i Contents 3 Android 43 3.1 Learning Android .............................. 43 3.2 Application to collect medical data .................... 43 3.2.1 Specication ............................. 43 3.2.1.1 Final specication .................... 44 3.2.2 Design ................................ 46 3.2.2.1 Prototyping ........................ 46 3.2.2.2 Design principles ..................... 48 3.2.3 Implementation ........................... 49 3.2.3.1 Android versions ..................... 50 3.2.3.2 Material design ...................... 50 3.2.3.3 Documentation ...................... 50 3.2.3.4 Classes .......................... 51 3.2.3.5 Manifest .......................... 52 3.2.3.6 Main challenges encountered during the development . 52 3.2.3.7 Final application and testing .............. 54 3.2.4 Usability testing .......................... 54 3.2.4.1 Preparation of the usability testing ........... 56 3.2.4.2 Testing sessions ...................... 58 3.2.4.3 Analysis and recommendations ............. 58 3.2.5 Future changes ........................... 60 4 Contributions 63 4.1 Github .................................... 63 4.2 Stack Overow ............................... 64 5 Conclusion 65 Acronyms 67 Glossary 69 Bibliography 73 Appendix: MongoDB conguration le 75 Appendix: Actigraph data 77 Appendix: Creation of users and roles 81 Appendix: Prototypes images 87 Appendix: Screenshots of the nal application 95 Appendix: Usability testing questionnaire 99 ii List of Figures 1.1 UCM groups: Grasia and G-TeC ..................... 1 1.2 Key-value databases most popular implementations ........... 3 1.3 Document databases most popular implementations ........... 4 1.4 Person schema ................................ 5 1.5 3Vs ...................................... 7 1.6 Data sharing in Hadhoop .......................... 7 1.7 Data sharing in Spark ........................... 8 1.8 Hadhoop vs Spark ............................. 8 1.9 Spark process ................................ 9 1.10 Spark Engine ................................ 10 1.11 Spark ecosystem ............................... 11 1.12 Spark streaming ow ............................ 11 1.13 Spark dynamic load balancing ....................... 12 1.14 Spark process ................................ 13 1.15 Logistic sigmoid ............................... 14 1.16 Neural networks ............................... 15 1.17 Error function as a surface in the weight space .............. 16 3.1 Application problems in some devices ................... 55 3.2 No space after the help text in some old devices ............. 55 4.1 Logos of the communities I contributed to ................ 63 1 Fist prototype ................................ 87 2 Second prototype .............................. 88 3 Third prototype ............................... 88 4 Fourth prototype .............................. 89 5 Fifth prototype ............................... 89 6 Sixth prototype ............................... 90 7 Seventh prototype .............................. 90 8 Eight prototype ............................... 91 9 Ninth prototype ............................... 91 10 Tenth prototype ............................... 92 11 Final prototype ............................... 93 iii List of Tables 1.1 RDDs transformations and actions .................... 10 1.2 DStreams transformations ......................... 12 v Abstract English During the development of this project I learnt about Big Data , Android and MongoDB while helping to develop a bipolar crises-prediction system by analysing massive quantity of data from diverse sources. Concretely, I did a theoretical part about NoSQL database, Streaming Spark and Neural Networks and then I designed and congured a MongoDB database to be used in the bipolar disorder project. I also learnt about Android and designed and developed an Android mobile application to collect data to be used as an input in the crises-prediction system. I did usability testing upon completion of the project too. Spanish Durante el desarrollo del proyecto he aprendido sobre Big Data , Android y MongoDB mientras que ayudaba a desarrollar un sistema para la predicción de las crisis del transtorno bipolar mediante el análisis masivo de información de diversas fuentes. En concreto hice una parte teórica sobre bases de datos NoSQL, Streaming Spark y Redes Neuronales y después diseñé y conguré una base de datos MongoDB para el proyecto del trastorno bipolar. También aprendí sobre Android y diseñé y desarrollé una aplicación de móvil en Android para recoger datos para usarlos como entrada en el sistema de predicción de crisis. Una vez terminado el desarrollo de la aplicación también llevé a cabo una evaluación con usuarios. vii 1 Introduction Redis supports lists, sets and hashes and can do range, dierence, union and intersection operations. It has one of the most robust query mechanisms for a key-value database and it is perfect when working with risk data. As this model is so simple it can perform well in many scenarios but it will generally be unsuitable in the following cases: • If having relationships between dierent sets of data is needed, even though some key-value stores provides traversing links. • When having multioperation transactions and when an operation fails you want to revert the rest of the operations. • If you need to search the keys using data from the value part. • To operate over multiple keys at a time. 1.4.1.2 Document-based databases (a) MongoDB (b) CouchDB Figure 1.3: Document databases most popular implementations Document-oriented databases are a subclass of the key-value databases, which implies that key-value databases are more general. In document-based databases each record is a document, typically XML,JSON or BSON. These documents are self-describing, hierarchical tree data structures. Moreover, documents are independent units which improve performance, as related data is read contiguously and allow us to distribute data across multiple servers while keeping related data together. Documents have dierences in their attributes and any data can be stored in them (there are specic restrictions depending on the type of document database), so that unstructured data can be stored easily. Similar documents belong to the same collection. A collection is analogous to an SQL table, but in relational databases each columns stores the same type of values or null , wasting memory and allowing less exibility. The gure 1.4 shows an example of the dierences between a table with persons in a typical relational database and the collection persons in a document database. Documents are closer to what we have in our programs than relational schemas. Note that documents can be as complex as you choose: nested data can be 4 1.4 State of the art (a) Relational database - Persons table (b) Document database - Persons collection Figure 1.4: Person schema used to provide additional sub-categories of information about an object. You can also use one or more document to represent a real-world object. The strength of a document database's query language is an important dierentiator of these databases. We can query the data inside the document, while in key-value databases we would have to seach the document by its key, get the whole document and then look into the document. Because of that, document stores provides as a balance between exibility and similarity to relational databases, which I am used to work with. We are going to analyse MongoDB (gure 1.3a), as it is a representative implementation of document databases and CouchDB (gure 1.3b) which is used in some medical projects. Both of them are free and open-source, there are some private options such as Azure DocumentDB , Lotus Notes or SimpleDB ) but expense is not worthwhile and we can not aord it. 5 1 Introduction MongoDB uses JSON documents to manage the data, although internally it saves BSON documents, which is a JSON-like format more compact than JSON that improves eciency. Documents are limited to 16MB. MongoDB congures consistency and improves availability by using replica sets. It allows atomic transactions at the single-document level and it can also be scaled easily. All this features of MongoDB are detailed in section 2.1. As we have said above, CouchDB has been used in some medical projects, although things like x-ray images or electroencephalography wave recordings are saved and it is quite doubtful that those kind of projects are similar to ours. Let's mention two interesting examples: [33] discuss the use of CouchDB for Document-based Storage of DICOM Objects and [31] explains why using Document-Based Databases for Medical Information Systems in Unreliable Environments is well-suited. 1.4.1.3 Conclusion Both key-value and document-oriented databases are appropriate for web and real-time analytics and provides us with schema exibility, although document stores query engine is a determinant factor. Moreover, the fact that they are closer to relational databases will makes easier the transition from SQL and understanding the database and its design. Also, the popularity of MongoDB provides us with a large amount of documentation and manuals, which make my learning much easier. All in all, I consider MongoDB to be the best option to this project. 1.4.2 Streaming processing with Spark Volume, Velocity and Variety are the three properties which dene Big data , and that is why we usually talk about the 3Vs (gure 1.5). Streaming processing is the solution when we want not only to process big volumes of varied data but to do it fast too. It processes data in real time and focuses on unlimited and continuous data ow. Although data revolution has just started, stream processing has already demonstrated to have a great future and it will surely become very important for most companies in the close future. We are going to focus interest on streaming analytics, although some of the technologies mentioned can be used for other purposes. There are many dierent frameworks (such as Apache Storm , Apache Spark or Apache Samza ) and products (such as IBM InfoSphere Streams or TIBCO StreamBase ) available on the market. As all of them are very similar we are going to concentrate on Apache Spark , because it is one of the most popular solutions and as it is free software we can use it with no cost. 6 1.4 State of the art Figure 1.5: 3Vs Apache Spark is a fast and general cluster computing framework originally started by Matei Zaharia as part of his thesis at UC Berkeley AMPLab in 2009 and open sourced in 2010. In 2003, it was donated to the Apache Software Foundation where it remains today. Databricks , which is a startup oering commercial support for Spark, was created in 2004. Spark was developed as an alternative to Hadoop 's two-stage disk-based MapReduce paradigm shown in gure 1.6. Hadoop is slow because of replication, serialization and disk I/O, so that it is inecient for iterative algorithms (most of Maching Learning Algorithms are iterative) and interactive data mining. Figure 1.6: Data sharing in Hadhoop 7 1 Introduction Figure 1.7: Data sharing in Spark Spark 's multi-stage in-memory paradigm provides performance up to 100 times faster than Hadoop MapReduce in memory (see gure 1.8), or 10 time faster on disk. That is achieved by allowing to access to the same dataset repeatedly without going to disk. 1.7. Figure 1.8: Hadhoop vs Spark Spark revolves around the concept of Resilient Distributed Datasets (RDD), which is a collection of elements that can be operated on in parallel. They can work with any kind of data, which is another plus point. All necessary transformations are done over the RDDs, which contain not only the data but also the transformation operations that must be done with them. Each RDD is divided in multiple partitions which can be executed in dierent nodes of the cluster (it also stores information about partitions and the node that it should go to). Moreover, they are immutable: once data have been read it is assumed that it is not going to change, so it is not read again. When transformations are applied another RDD is created with the result of these transformations. As a result of being immutable and containing information about transformation ow, partitions and nodes, RDDs are fault-tolerant. 8 1.4 State of the art RDDs are also ecient as they use lazy evaluation: Transformations are dened but they are not executed until an action runs it. That allows to plan and optimize when the operations are done and avoids unnecessary exchange of data between machines. Spark allows a RDD to remain in memory to avoid recalculating it every time it is needed again. Figure 1.9: Spark process To sum up, the process is illustrated in gure 1.9. First a RDD is created, transformations are applied (when necessary according to lazy evaluation) and then actions, obtaining a value. During all the process everything is in RAM memory and at the end data is saved. Another important advantage of Spark is that it oers more operations apart from Map and Reduce and allows more exibility when dening operations. That is why parallel applications can be built using Spark quickly and easily, allowing more complex Big Data problems being solved. Some of the most common transformations and actions can be seen in table 1.1. It also support writting applications in Java, Scala, Python and R. Spark applications run as independent sets of processes on a cluster. There is a driver program, which is a process running the main function of the application and creating the SparkContext. It also declares how RDDs are created and what transformations and actions are done over them. The SparkContext connects to a cluster manager and then Spark acquires executors on nodes. After that, the 9 1 Introduction TRANSFORMATIONS map (func) lter (func) mapPartitions (func) union (otherDataset) intersection (otherDataset) distinct ([numTasks])) groupByKey ([numTasks]) reduceByKey (func, [numTasks]) sortByKey ([ascending], [numTasks]) join (otherDataset, [numTasks]) cogroup (otherDataset, [numTasks]) repartition (numPartitions) . . . ACTIONS reduce (func) collect () count () rst () take (n) takeSample (withReplacement, num, [seed]) takeOrdered (n, [ordering]) saveAsTextFile (path) saveAsSequenceFile (path) saveAsObjectFile (path) countByKey () foreach (func) . . . Table 1.1: RDDs transformations and actions Figure 1.10: Spark Engine application code is sent to the executors and the SparkContext sends tasks to them. Figure 1.10 is diagram of Spark Engine which shows its components and the way they interact. Spark ecosystem is another important advantage. As it can be seen in gure 1.11, it includes Spark SQL, Spark Streaming, Mllib and GraphX. Spark SQL lets you query structured data inside RDD. Spark streaming is the stream processing engine. MLlib is Apache Spark's scalable machine learning library. Lastly, GraphX is Apache Spark's API for graphs and graph-parallel computation. We have already analysed in detail how Spark works and all the advantages that it provides: it is incredibly fast (specially for iterative algorithms), fault-tolerant and 10 1.4 State of the art Figure 1.11: Spark ecosystem ecient and it provides ease of use (oering a wide range of operations and allowing to write in several programming languages) and generality (with its ecosystem). Its only disadvantage is that it a quite new technology and it has not been tested in clusters with a lot of nodes. We are now going to concentrate on how Spark Streaming works. Figure 1.12: Spark streaming ow Spark Streaming discretizes the streaming data into tiny, sub-second micro-batches and with each batch of data is built a RDD. This allows the streaming data to be processed with the Spark engine explined above. This process can be seen in gure 1.12. Dividing the data into small micro-batches allow us to schedule the tasks more eciently, while in the traditional record-at-a-time approach the static scheduling may cause that some nodes become a bottleneck and slow down the pipeline. In Spark Streaming, the tasks are balanced across the nodes, some of them run a few longer tasks while others run more of the shorter tasks. The dierence is illustrated in gure 1.13 Spark Streaming provides a high-level abstraction called DStream, which represents a buer with a sequence of RDDs. Tranformation can also be used with DStream, provinding ease of use. The most common transformations can be seen in table 1.2. The transformation transform is particularly interesting as it allow applying a RDD-to-RDD function to every RDD of the source DStream. Last but not least, we are going to explain why Spark Streaming is fault-tolerant. As all data transformation are based on RDDs operations and we have already explained that they are fault-tolerant, if the input dataset is present, all data can be recomputed. It tolerates the failure of the driver node by saving the state of the DStreams periodically to a HDFS le, which can be used to restart the streaming computation. It also tolerates the failure of a node. When the input source is a HDFS 11 1 Introduction Figure 1.13: Spark dynamic load balancing TRANSFORMATIONS map (func) atMap (func) lter (func) repartition (numPartitions) union (otherStream) count () reduce (func) countByValue () reduceByKey (func, [numTasks]) join (otherStream, [numTasks]) cogroup (otherStream, [numTasks]) transform (func) updateStateByKey (func) . . . Table 1.2: DStreams transformations data can be recomputed. On the other hand, when the input source receives data through a network, data is replicated in memory between nodes of the cluster. The only problem is when the node which fails is the one where the the network receiver was running, as the data that has not been replicated will be lost. Not only does Spark allows to recover from failure, but it also do it faster that the traditional approach. In Spark, there are small tasks that can be run anywhere. That allows that failed tasks can be rerun in parallel on any other nodes, as it is illustrated 12 1.4 State of the art in gure 1.14. Figure 1.14: Spark process The main bibliographic references used for this section are [8], [1] and [3]. The images are also taken from these sources, except the gures 1.8 and 1.6, which I took from [18] and [2] respectively. 1.4.3 Neural networks The aim of this section is to follow part of the chapter 5 of [21], commenting on some details. I have also added information from the the videos I saw at [36]. At the end I will also explain the importance of Neural Networks on Big Data . Articial neural networks are a machine learning technique based on how your neurons in your brain work and they have been particularly successful recently in big and hard problems. It is a supervised method, as we give it inputs and outputs to train it, and it can be used for regression if the outputs are continuous and classication otherwise. They model complex and nonlinear patterns that simpler models may miss. For example, we could predict if a person has a bipolar crisis base on how many hours the person slept the day before and how concentrate he feel he is, by using a classication neural network. Let's start by dening the basic neural network model. Given the input variables x1, . . . , xD , we construct M linear combinations: 13 2 MongoDB database 2.1 Features In this section we are going to comment on the features of MongoDB . I have followed the Document Databases chapter in [34], as it is really complete and the concepts are really well explained. 2.1.1 Queries We have already mentioned that the strength of document databases' query language is an important dierentiator of these databases and MongoDB is not an exception. In MongoDB documents are indexed using a BTree and queried using a JavaScript query engine. It has a query language which is expressed via JSON. All queries address a single collection and indexes allows ecient queries (see 2.3.2.3). Let's give an example of how queries are made in MongoDB in comparison with SQL. Suppose that we want to query for all users whose house is in a Spanish city. In relational databases we would probably have three collections, one for users, another one with houses and the last one with information about cities. Then, the SQL would be: SELECT * FROM users, houses , cities WHERE houses.ownerId = users.id AND houses.citiesId = cities.id AND cities.contryName = "Spain" And the equivalent Mongo query would be: db.orders.find({"users.house.contryName" : "Spain"}) The query for MongoDB is simpler because the objects are embedded inside a single document and the information is usually repeated in several document (the country name for every house in the same city). There are more examples of MongoDB queries in the section 2.3.3. 21 2 MongoDB database 2.1.2 Transactions Transactions in relational databases represent any change in the database. So when a transactions begins, the database can be modied using commands over dierent tables such as insert , update or delete and then it can be decided if the changes are kept ( commit ) or not ( rollback ). This is not generally available in NoSQL databases, a write can only succeed or fail. Transactions in MongoDB are at the single-document level ( atomic transactions ): one or more elds of the document (including sub-documents and elements of an array) are updated and then the document is updated in the database. Transactions involving more than one operation are not possible, although there are other document databases, like RavenDB , that support them. In fact, those multiple operation transaction are not needed in our project. For example, they would be needed if we had duplicated data in several collections, but as it is explained in 2.3.2 it is not the case in the database designed for the project. 2.1.3 Availability MongoDB uses the master-slave set-up and maintains several copies of data called replica sets using native replication. The replica set is used to improve data availability, by increasing the number of nodes and allowing reading from slaves. The nodes elect the master (priorities can be given to favour some nodes) by themselves. The master is who has all the data updated and receive all requests, and then data is replicated to the slave nodes. If the master node goes down, the remaining nodes elect a new master and it will serve all future requests. When the node that failed gets on-line again, it joins in as a slave and get the updated data from the current master. In our case we currently have one server so we do not have the chance to use replica set . Although, that is not an availability problem at the moment as the trac in our server is really low and in the future we could add more nodes easily as it is explained in section scaling. 2.1.4 Consistency Consistency in MongoDB database is also congured by using replica sets (multiple copies of data) and waiting for the writes to be propagated to a given number of slaves before they success. This number can be increased for stronger consistency but it will aect write performance, as the writes will have to be propagated to more nodes. The number of slaves the writes have to be propagated to and if reading from slaves is allowed can be congured in the connection, database, collection or individually for each operation and the specic characteristics of the project need to be taking into account to choose those settings. In our project we have set them when creating users (see Appendix: Creation of users and roles) by setting the w attribute to majority . Currently there is only one node, the server I congured in section 2.3.1.2, so writes 22 2.2 Learning MongoDB will return immediately. If we add more servers in the future, it will wait for the write operation to have propagated to the majority of voting nodes before it returns as successful. Until we add more servers there is no option to read from slaves. 2.1.5 Scaling Scaling is a very important issue in our project as we have a single node at the moment and we plan to add more nodes in the future. MongoDB allows horizontal scale easily with no downtime and without changing your application. To allow heavy-read we can add more read slaves and read directly from them. When a new node is added, the process will be the same as the one explained in the availability section when the master node gets on-line after having gone down: it get the data from the existing nodes, join the replica set as secondary node and it is ready to serve read requests. When we want to horizontally scale for writes, we use sharding . It is a technique similar to partitions in relational databases as the data is also split by a concrete eld, but then it is moved to a dierent node. MongoDB automatically balances the data by dynamically moving it between nodes. So, to scale for writes we just have to add more nodes to the cluster and increase the number of writeable nodes. Moreover, each shard can be a replica set , ensuring better read performance within the shard. 2.2 Learning MongoDB It was the rst time I worked with NoSQL databases and with MongoDB in particular. First of all, I took almost the whole MongoDB for Java Developers course ([10]), although the course didn't start until 24 May 2016, so I saw the videos of previous editions of the course at Youtube . There is also a subject of Systems for management of data and information ( Sistemas de Gestión de Datos y de la Información ) in the Master's of the Computer Science Faculty where MongoDB is studied. I asked some students in this class to send me the slides they were using ([22]), which I found really useful as they have a lot in-depth information and illustrative examples. I also used the complete ocial guide of MongoDB , see [11]. For more specic topics or doubts I used other guides, blogs and forums such as [14]. 23 2 MongoDB database 2.3 Database for the project 2.3.1 Installation and conguration 2.3.1.1 Development I used Windows 7 for testing before moving to the production environment. The last version I used was the 3.2.6, which is the last stable release. But I also worked with other versions as the 3.2.6 was launch on Apr 28, 2016. I download MongoDB 2.3.6 MongoDB Community Edition from http://www.mongodb.org and I followed the installation guide in the section Install MongoDB Community Edition on Windows of [11]. I created the conguration le in my computer in the following route C:\Program Files\MongoDB\mongod.cfg . The conguration le can be seen in the Appendix: MongoDB conguration le. The data is stored in C:\data\db and the log le can be found in C:\data\log\mongod.log in my computer. After the installation I congured a Windows Service for MongoDB Community Edition . I ran this command in the cmd window with admin permissions to install the service: "C:\Program Files\MongoDB\Server\3.2\bin\mongod.exe" --config "C:\Program Files\MongoDB\mongod.cfg" --install The following command can be ran to uninstall the service: "C:\Program Files\MongoDB\Server\3.2\bin\mongod.exe" --remove To start, restart and stop the server I used these commands: net start MongoDB net restart MongoDB net stop MongoDB The Mongo shell JavaScript client can be ran from the cmd window: "C:\Program Files\MongoDB\Server\3.2\bin\mongo.exe" Or, after enabling authentication with the admin user (see 2.3.2.2): "C:\Program Files\MongoDB\Server\3.2\bin\mongo.exe" -u "admin" -p "password5" --authenticationDatabase "bipolarDatabase" 24 2.3 Database for the project 2.3.1.2 Production Debian 7.1 is one of the OS recommended in the Production Notes of [11]. In addition, for MongoDB 3.2 , 32-bit binaries are deprecated and will be unavailable in future releases. So Debian 7.1 64-bit was installed in the Server which is at the Department Seminario ACyA of the Computer Science Faculty, whose static global IP address is 147.96.25.33 . As in development, I installed the version 3.2.6 of MongoDB Community Edition . I followed the installation guide in the section Install MongoDB on Debian of [11] but I had a problem during the installation: E: Unable to locate package mongodb -org-shell I managed to solved it by installing every .deb from [5]. The conguration le is in /etc/mongod.conf . I eliminated the line where the bind IP is declared as it is the loopback address by default and by eliminating it I made the server listen in all IPv4 addresses on the local machine. This include the global IPv4 which is the one the external clients are going to use to communicate with the server. I also modied the conguration le to congure authentication, as it is explained in 2.3.1.3. The log le is save by default in /var/log/mongodb/mongod.log and the database data is storaged in /var/lib/mongodb . To start, restart and stop the server the following commands can be used: sudo service mongod start sudo service mongod restart sudo service mongod stop After installing and conguring the server, it was needed to open the port 27017 ( MongoDB port by default). I used iptables command to do so: sudo iptables -A INPUT -p tcp --dport 27017 -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 27017 -j ACCEPT sudo iptables-save To check that everything is working properly: sudo netstat -lnp grep mongo But surprisingly, after all that, connecting to the server from outside was not possible because the UCM net does not allow connections to some ports and the 25 2 MongoDB database 27017 is one of them. It would have worked in other net but not at UCM one. So, I tried with other ports until I found a port which works, the 8080. So I changed the port in the conguration le (the conguration le can be seen in the Appendix: MongoDB conguration le) and from that moment on I used the 8080 port. In the server, the Mongo shell JavaScript client can be ran from the terminal window: mongo Or, after enabling authentication with the admin user (see 2.3.2.2): mongo -u "admin" -p "password5" --authenticationDatabase "bipolarDatabase" I also managed the server database from my house using Windows cmd , connecting with the admin user to the server global IP and the port 8080. I used the following command (it is necessary to include the port, it won't work otherwise): "C:\Program Files\MongoDB\Server\3.2\bin\mongo.exe" --host 147.96.25.33 --port 8080 -u "admin" -p "password5" --authenticationDatabase "bipolarDatabase" 2.3.1.3 Authentication In both development and production environment I congured authentication that, as we will explain in 2.3.2.2, it is crucial for the veracity and validity of the data stored in our database. Before creating any role I had to change the authentication mechanism to the previous one ( MONGODB-CR ) instead the default new one in releases 3.* ( SCRAM-SHA-1 ). I had to do that because we planned to access the MongoDB database from the Android application and when using SCRAM-SHA-1 from the Java Driver java.nio.channels.AsynchronousSocketChannel is called and it does not exist in Android, so it causes an exception and as a result it does not work. So after installing and starting the server I connected with a client without authentication and I changed the authentication mechanism in MongoDB following the following steps: use admin var schema = db.system.version.findOne({"_id" : "authSchema"}) schema.currentVersion = 3 db.system.version.save(schema) 26 2.3 Database for the project After that we create the roles specied in 2.3.2.2 as it is described in Appendix: Creation of users and roles. Then I modied the conguration le to add authetication ( authorization: enabled ). The nal conguration le can be seen in the apendice Appendix: MongoDB conguration le. Then I restarted the MongoDB server to enable authentication and from that moment on I connected to the database with a specic user. 2.3.2 Design The design of the database includes the design of collections, the creation of roles and users and the creation of indixes. 2.3.2.1 Colletions In document databases there are not rows as there are in relational databases, so we can not restrict what it is saved in the database. However, it is necessary to know what other applications are saving in the database to be able to read the information we need and if some applications are saving the same data all of them should do it in the same way. I have called our database bipolarDatabase and the collections that I have dened for our projects are the followings. The name of the collection and attributes are in bold and the BSON data type of each attribute is also specied. Information about BSON types can be found in the section BSON Types of [11]. collection users : Stores the users data. _id ObjectId unique, compulsory Identier. email String unique, compulsory Email address. name String compulsory Full name. birthDate Date compulsory Birth date. gender Boolean Gender. Values: true (woman) and false (man). pin 32-bit integer 6-digits password to be use in the mobile app. 27 2 MongoDB database cohabitation 32-bit integer Who the user lives with. Values: 0 (alone), 1 (with his/her couple), 2 (with his/her couple and children), 3 (with his/her parents) and 4 (others). diagnosis String ICD-10 diagnosis. diagnosisAge 32-bit integer Age at which the disorder was diagnosed. senLit Boolean Whether the patient is sensible to Lithium or not. senVal Boolean Whether the patient is sensible to Valproate or not. senCar Boolean Whether the patient is sensible to Carbamazepine or not. seasonality Boolean Whether the patient presents seasonality or not. maniaCrises 32-bit integer Frecuency of mania crises. mixedCrises 32-bit integer Frecuency of mixed crises. freePeriod 32-bit integer Number of months where the patient presents no symptoms. psycSymp Boolean Whether the patient presents psychotic symptoms or no. others String Other diagnosis. collection comments : Stores the prescriptions and the notications to be send to the mobile app. _id ObjectId unique, compulsory Identier. user_id ObjectId unique, compulsory User identier. prescription Boolean compulsory 28 2.3 Database for the project Whether the document represents a prescription or a message. dateStart Date compulsory Start date and time. dateEnd Date End date and time. If it is empty the end date is indenite. time 32-bit integer compulsory Time at which the alarm has to be repeated or the medicine taken from the start to the end date. Minutes from 00:00. name String Active ingredient or commercial name. type 32-bit integer Medicine type. Values: 0 (Lithium), 1 (anticonvulsant), 2 (antipsychotic), 3 (anxiolytic/hypnotic), 4 (antidepressant) and 5 (others). title String Ocial text. text String Alarm text. dose 32-bit integer Dose. collection records : Stores the medical records. _id ObjectId unique, compulsory Identier. user_id ObjectId unique, compulsory User identier. date Date compulsory Date and time at which the record was saved. eeag 32-bit integer Rating in the GAF scale (see [7]). hdrs Document The document contains the following keys, which represents the HDRS questions (see [9]), each with a 32-bit integer value associated: deprMood , feelGuilty , suic , insoEarly , insoMiddle , insoLate , workActiv , retard , agitat , anxiPsych , anxiSomat , 29 2 MongoDB database db.users.find({"username":"[email protected]"}).explain(true) To check the indexes we have dened we can use: db.users.getIndexes() And to delete a index: db.users.dropIndex( "email_1" ) We also have to add an index to the user_id attribute of comments , records , analysis , mobileTests and actigraphData collections as it is acting as a foreign key . The shell commands to add them are: db.comments.createIndex({"users_id": 1}) db.records.createIndex({"users_id": 1}) db.analysis.createIndex({"users_id": 1}) db.mobileTests.createIndex({"users_id": 1}) db.actigraphData.createIndex({"users_id": 1}) Text indexes allow us to perform advanced searches over text elds of a document. As we are storing the user's rst and family names in the key name in the web application the doctor may want to search a patient by its family name and a text index would be very useful for that. Also, the doctor may want to search a patient by its email but he does not remember it exactly, so a text index would be useful here to. Consequently I have added a text index over the document users for this two keys (we can only add one text index but it can have multiple keys). As I think that searching by name will be more common than doing it by email, I have given the name a weight of 3 while email has the default weight of 1. I have also given the index a custom name. As, at least at the beginning the project is going to be in Spain we have also specied Spanish as the default language. Although the language should not be really important, as we are only querying names and emails. db.users.createIndex( {name: "text", email: "text" }, { 36 2.3 Database for the project weights: { name: 3 }, name: "TextIndex", default_language: "spanish" } ) 2.3.3 Queries This section illustrates how to query the data in the designed database. The queries are going to be done for the Mongo Shell as the languages to be used in some part of the project are not yet clear. And even if they were clear we may want access the database with other languages in the future. First of all we have to change to the bipolarDatabase database: use bipolarDatabase Let's start querying the users collection, as it is used for most clients and has indexes whose use is worthwhile showing. To insert a new user with all the attributes in the users collection: db.users.insert( {"email" : "[email protected]", "name" : "Lolita Martínez López", "birthDate" : ISODate("1980-02-24"), "gender" : true, "pin" : NumberInt(123456), "cohabitation" : NumberInt(0), "diagnosis" : "F00.0", "diagnosisAge" : NumberInt(21), "senLit" : true, "senVal" : false , "senCar" : false , "seasonality" : true , "maniaCrises" : NumberInt(3), "mixedCrises" : NumberInt(0), "freePeriod" : NumberInt(6), "psycSymp" : false , "others" : "The patient suffers from migraines" 37 2 MongoDB database } ) Note that we do not introduce the _id as it is automatically generated. If there is an attribute that we do not want to insert we can just not include it. By default, the Mongo shell treats all numbers as oating-point values, so we use NumberInt() constructor to explicitly specify 32-bit integers. ISODate() constructor returns a Date object using the ISODate() wrapper. If we want to know all the users that are in the database we can execute: db.users.find().pretty() The pretty function is to display the results in an easy-to-read format. If we want to nd all users that satisfy some conditions, for example all women that are not sensible to Valproate: db.users.find( { "gender" : true , "senVal" : false } ).pretty() If we want to nd an specic user, for example using the already mentioned typical search by email: db.users.find( { "email" : "[email protected]" } ).pretty() We can also nd a user by his id: db.users.find( { "_id" : ObjectId("573ee9d4ae07fbe5b79bd0d0") } ).pretty() For the last two queries we can also use findOne() , as we want only one record. We should take into account that find() returns a cursor and findOne() returns document. I used the rst alternative as the pretty() function can only be used over a cursor, to be able to read it easily, but probably in an application using findOne() would be better. Also, most drivers include a function to search by id which is worthwhile using, but there is not this function in the Mongo shell . The next query illustrate how to work with dates and with comparison operators. 38 2.3 Database for the project It nds all users who were born from 1990 on: db.users.find( { "birthDate" : { $gte :ISODate("1990-01-01T") } } ).pretty() To remove all users: db.users.remove({}) And if we do not want to remove all users we can add conditions. For example, all users whose id is 573ee9d4ae07fbe5b79bd0d0 : db.users.remove( { "_id" : ObjectId("573ee9d4ae07fbe5b79bd0d0") } ) We can also look for users using the text index created in section 2.3.3. For example: db.users.find( { $text: { $search: "Gómez" } } ).pretty() It will nd all users that has Gómez (or gomez as it is case insensitive by default) in their name or email. We can go a little bit further and print the score and order the results by the score given by the weights of the index: db.users.find( {$text: {$search: "Gómez"}}, {score: {$meta: "textScore"}} ).sort({score:{$meta:"textScore"}}).pretty() We could also want to search the users whose last names are Martínez Gómez : db.users.find( { $text: { $search: "\"Martínez Gómez\"" } } ).pretty() Querying others collections it is done in the same way, as the most common functions are insert , update and nd . So we are just going to show some examples that 39 2 MongoDB database could not be illustrated over the users collection. Let's start by the actigraphData collection. First, we are going to introduce a record in this collection, as it has Doubles, Arrays and Dates with times that we do not have in the users collection: db.actigraphData.insert( {"user_id" : ObjectId("57416 ee9494026efedaa7735"), "date" : ISODate("2016-05-22T09:43:18Z"), "position" : [NumberInt(1),NumberInt(2),NumberInt(3)], "lux" : NumberInt(27), "button" : false , "temperature" : 23.2 } ) It also important to illustrate how arrays are queried. For example, to nd all actigraph records in which the y coordinate is 2 we do: db.actigraphData.find( { "position.1" : 2} ) It is important that array indexes start at 0. There are more complex operations over arrays but we do not need them as the client will work with the whole array as the position is not useful without the three coordinates and it is very unlikely that users are found by their position. We are now going to use the records collection to illustrate how to query nested documents. For example, to nd the users whose hostility score is less than 20 in the Positive scale part of the PANSS interview: db.records.find( { "panss.panssPos.hostil" : { $lt : 20 } } ) Lastly, we are going to use the mobileTests and users collection to illustrate how joins can be done. For example, to query all mobile test of an specic users by his/her email: id = db.users.findOne( { "email" : "[email protected]" } )._id 40 2.4 Integration db.mobileTests.find( { user_id: id} ).pretty() 2.4 Integration Lastly, we are going to comment on how to integrate MongoDB with other languages. The available drivers are detailed in the section MongoDB Drivers of [11]. Let's start with the mobile phone application. It is being developed for Android, so the ocial MongoDB Java Driver is being used. You can see the code of the mobile application, which you can nd in Github (see 3.2), to know the details of how this integration is done. For the web application we have thought to use Node.js . If that is the case the ocial MongoDB Node.js Driver could be used. Also, using Mongoose , an ODM for Node.js which allows us to communicate with a MongoDB database simply and easily, would make the integration much more comfortable. We could also consider using Ruby on Rails for the development of the web application. In that case we should use MongoDB Ruby Driver or if we want to include validations, associations, and other high-level data modelling functions, the ODM ocially supported by MongoDB : Mongoid . The actigraph libraries are written in C# , so it makes sense to write the application that sends the actigraph data to the database in the same language. Therefore the ocial MongoDB C# Driver can be used for the communication with the database. Lastly, for the analysis phase R is going to be used. As it is explained in [35], to use R together with MongoDB there are mainly two packages: rmongodb and RMongo . I recommend using rmongodb as it appears to be more popular and it does not require Java , while RMongo uses the MongoDB Java Driver . 41 3 Android The objective of this chapter is to comment on the process followed to learn Android and to design, develop and test an Android mobile app to collect data to be analysed for medical purposes. 3.1 Learning Android I had not have any contact with Android before this project so I spent a considerable amount of time learning about it, although my previous experience with Java made it much easier. Some of my classmates took the iOS and Android programming course in the Complutense Summer School and they send me the projects they did and the slides they used at the course ([27]). I also asked some students that took or are currently taking the subject of development of mobile app ( Programación de aplicaciones para dispositivos móviles ) at the faculty to send me the material they used or are using, that is mainly the slides [26]. So I started with the material of these two courses and then I used the complete ocial guide of Android , see [6]. For more specic topics or doubts I used other guides, blogs and forums, primarily [14]. 3.2 Application to collect medical data The Android mobile application which collects data to be analysed for medical purposes plays a really important role in our project, as it would allow us to know how the bipolar patients feel they are. When working with mental illness, this kind of subjective information is really valuable, not because of its veracity but because of what their changeability can reveal. The code of the app is free software and can be found here, together with the .apk, the nal protoype, screenshots and other relevant information: https://github.com/Ana06/medical-data-android 3.2.1 Specication Since I started working in the project the application specication has changed several times because of dierent reasons: • The necessity to have a rst version of the application than can collect data as soon as possible. Some functionality has been simplied or discarded 43 3 Android as it would have delay the development of the app in excess, altough some improvements are planned to be introduced in future versions (see 3.2.5). As an example, at the beginning some games wanted to be implemented as part of the daily test to collect objective information about concentration, reexes, etc. Instead, the time to introduce the pin is measured as a concentration indicator. • Something we had planned to do is impossible, too dicult or not recommended. For example we wanted to register some information that are not accessible in Android for security and privacy reasons such as the use of other apss and the hours the screen is on. We had also thought about using the phone as an accelerometer, but was quite unlikely that the battery can support it. • Issues that during the design or implementation of the application we realised that had not been considered. For example, if we wanted to register the number of tries and timing all of them or only one/some of them when introducing the pin. • Bad communication. In the mobile application that uses the doctor we where told to ask the birth date and in the mobile application to ask the age. When considering the integration of the two applications, we had to change the birth date by the age in the mobile app. • The necessities of the project changed. As we depended a lot on the client, the hospital and specially the doctor working with us, changes had to be made almost every time I had a meeting with him. As an example, the decision to collect caeine was made towards the end of the development of this project. The way the register is wanted to be done was also changed several times, as it can be seen in the prototyping section. 3.2.1.1 Final specication The Android mobile application is in English and Spanish. The rst time the application is used the user should sign in or sign up. If the user has already been registered by his doctor, he had already received an email with the 6 digits password that, together with his/her email, can be used to sign in, and all the information needed by the app will be get from the server. He would do the same if he had already registered. Otherwise the following information is asked: Name, email, age, gender and a 6 digits pin (it should be introduced twice). The chance to read the terms and conditions, which must be agreed, is given. Then, the user will be inform that the register has been correctly completed. The correctness of the information introduced in both the sign in and the sign up processes will be checked and, if there 44 3.2 Application to collect medical data is any error, it will be indicate appropriately. It will be allow to modify the daily test answers. The reason why we allow that is because if after completing the test something that change signicantly the patient's mood happens, the users should be allow to change his answers. The main page is the one that allow start the daily test or modify it if it has already been lled today. To start or modify the daily test it will be needed to introduce the pin correctly. If an incorrect pin is introduced the pin is cleaned. The number of tries and the time since the rst number is introduced until the start button is clicked having provided the corrected pin is saved. The last try (since the rst number is introduced after cleaning the pin space until the start button is clicked having provided the corrected PIN) time is also saved. The daily test asks the following data, which is what is stored in the mobileTests collection dened in 2.3.2.1: 1. Aective state: 7 points with a center one which is represented accordingly. 2. Motivation: 7 points with a center one which is represented accordingly. 3. Concentration: 5 points. 4. Anxiety: 5 points. 5. Irritability: 5 points. 6. Sleep quality: 5 points. 7. Menstruation: Yes or no. 8. Caeine: Integer 9. Alcohol: Integer 10. Cigarettes: Integer. 11. Other drugs: Yes or no. 12. Time to go to bed: Time. 13. Time to sleep: Time. 14. Time to wake up: Time. For most information about this data, you can see the help texts in the application. Question 1 to 6 use Likert scale , the number of points in these question was greatly discussed and there is information about it at [25]. For these questions the answer of the previous day the test was lled is indicated. We do that to allow users to be more accurate as they can compare with the answer they gave yesterday and value how their mood have change since them. 45 3 Android to restart when the app is closed. This bug also kills BroadcastReceivers , but do not kill alarms, so adding an Alarm we could restart our service to avoid losing data in those versions. For the sign in, sign up and the prole I created the nested classes called DownloadRegistration , SendRegistration and UpdateRegistration respectivily, which are similar to the SendTest class. For helping me to manage the registration I also created the User class, which has methods to create a user with all the information needed and to save him in the SharedSettings . I also needed a the nested class to allow the terms and conditions in the register to be clickable: MyClickableSpan , which inherits from ClickableSpan . I created three classes to manage the custom ratings too. As I wanted to use two dierent custom ratings with a lot of similarities I took advantage of inheritance. So, I created a class called RatingStars with the similar functionality, and two classes ( RatingStars5 and RatingStars7 ) which inherit from the rst class and contains the specic functionality. Lastly, I have a class called Variables which contains static nal variables and methods used around the program. 3.2.3.5 Manifest Every Android application must have a manifest. It contains important information such as the name of the Java package (unique in the device), the components of the app (activities, services, intentions it can manage, etc.) and the permissions. In the application manifest you can nd the name of the Java package, the name, icon and theme of the app, all the activities, the test service explained in the previous section and the following permissions needed to check the connectivity state: INTERNET , ACCESS_WIFI_STATE and ACCESS_NETWORK_STATE . 3.2.3.6 Main challenges encountered during the development Apart from the compatibility in some Android versions already commented, I encountered several challenges. The ones I considered to be more dicult to solve are in the following list: • Finding out why the service was not restarted when the application was closed. It is a bug in Android 4.4.x that by coincidence was the version I 52 3.2 Application to collect medical data was using to test the application. The reason why it was so dicult to discover is that there is not almost information about that. I nally found a detailed article about the problem at [17]. • Finding out why the authentication with MongoDB does not work in Android. When using SCRAM-SHA-1 authentication method from the Java Driver java.nio.channels.AsynchronousSocketChannel is called and it does not exist in Android, so it causes an exception and as a result it does not work. I solved it by changing the authentication mechanism to the previous one ( MONGODB-CR ) instead the default new one in releases 3.* ( SCRAM-SHA-1 ). It was dicult to solve because this problem is only for Android and the Java driver works ne in general, so there is no a lot of information about this error neither. • Managing times. Managing times was a complicated issue during the development of the project because of time changes as UTC is used by default and I needed to manage it in some places in the device local time. The problem more dicult to solved was to manage the day light savings, as it is not something common in most countries an it is not taking into account in most of the solutions I found on the Internet. • Making the title to be present when get a question focused because there is an error. Both in the register and the daily text, we want not only to get focus on the answer when there is an error (what is done by default when calling requestFocus() ) but also to be see its title. In addition, most of the daily text answers can not request focus, as they are not FieldTexts . I did that by using the Rect class and the requestRectangleOnScreen() method. It was dicult to me to understand who these class and method worked at the beginning. • Making the terms and conditions clickable in the register. The terms and conditions are a subtext in a sentence and we do not want the whole sentence to be clickable. I tried to managed it by dening two TextViews in the view, but it did not work. I managed to do it by using the SpannableString and MyClickableSpan classes in the activity associated. • Customizing the NumberPickers in the daily test to add an empty option by default . That is important because we want to force the users to ll in all the question and because of that that the 0 value, which is an acceptable value, can no be the default one. I managed to do that by using the Formatter class and the setMinValue() , setMaxValue() , setWrapSelectorWheel() and setFormatter() methods. 53 3 Android 3.2.3.7 Final application and testing Screenshots of the nal application in two dierent devices with dierent Android versions can be seen in the Appendix: Screenshots of the nal application. Also, a video of how the application looks and how to use it in a Nexus 4 with Android 6.0.1 can be watched in the following link: https://youtu.be/InZCw9WAZzI Regarding the testing, during the development of the project I mainly used my own mobile phone, an Elephone P3000S with Android 4.4.2 to test the application. But I also tested the application in a wide range of phone and tablets. While testing the app I discovered that it was not been displayed properly in some devices with small screen (specially those with older Android versions), as it can be seen in picture 3.1. The problem of the ratings was caused because of being using text inside the circles of the ratings. The solution was to manually set the text size for dierent screen sizes. Also, the scroll was not working properly, although it worked ne in other versions. I solved it by adding a FrameLayout between the RelativeLayout and the ScrollView . The last error I found was that the checkbox did not appear in small devices because of the way padding was set, so it was easy to solve it by changing the way of doing it the RelativeLayout . At the last minute I also discover that there is not space between the last line of the help text and the pink box in old version of Android (gure 3.2). Although it does not seem dicult to solve, I did not have time to do it and in fact it is not a hight priority issue. I could also have used Android Studio emulator, but it is really slow, specially for an old laptop like mine and as it was not dicult to have access to several devices to test the app I did not use it. 3.2.4 Usability testing Usability testing is a technique which consists on allowing users to work with our application directly and observing if they can use it for its intended purpose. The information that we obtain from usability testing is more valuable than using any other technique which does not involve users and it is the only way to know how real users will use our system. The usability testing can be helpful in any part of the project, but it has a high cost, as we need to recruit users, prepare it, doing it and analyse it. Because of the time needed, I only did usability testing at the end, but taken into account that the development of the application is going to continue and some new features are planned to be introduced, the objectives of this testing were the ones of an evaluation 54 3.2 Application to collect medical data (a) Ratings did not x the screen (b) The last part of scroll views was not seen (c) The checkbox did not appear Figure 3.1: Application problems in some devices Figure 3.2: No space after the help text in some old devices test and not the ones of a verication test. In other parts of the project, I evaluated the application by showing it to my directors and other people working in the project and taken their feedback into account. 55 3 Android The aim of a evaluation testing is to check if the users are able to do complex tasks without any help. Although quantitative information is written down the most important information is qualitative. The interaction between the interviewer and the user is minimum and the user has not only to indicate how he would do a task, but to execute it too. The result of this type of test is a list of parts of the application where the users get stuck, make errors or nd inconsistencies. Afterwards, improvements to solve the problems found are proposed. I used the Chapter 5 of [32] for writing this chapter and to help me to do a good and useful usability testing. 3.2.4.1 Preparation of the usability testing First of all, I had to decided what parts of the application I wanted to evaluate. Taken into account the objective of the testing, I decided that the best was asking the users to register in the application and ll in a daily test, as this cover the main purpose of the app (lling daily tests) and the register is indispensable to start using it. I summarized my objectives in the following questions, which I expected to be answered by the usability testing: • ¾Is it easy to complete the register? • ¾Do the users understand the questions of the daily test? • ¾Is it easy to ll in the daily test? • ¾Do the users understand the icons of the application? • ¾Do the users know what elements are touchable? I was especially interested in knowing how many questions of the daily test the user does not understand, how many errors does the user make and the time that takes him to complete the daily test. I was also interested in nding out how comfortable and dicult is using the application. I needed to choose the users too, as they had to be representative of the users of the application. As the app will be used by bipolar and healthy adults, I choose three users of dierent ages and genders, although they medical information can not be revealed because of legacy and privacy reasons. After that I made a description of the environment, the tools that would be used and my tasks as a moderator: The sessions will take place in my living room. The users will use their own Android mobile phone to ensure that the errors they make are not because of being using an unknown device. There will be a camera recording the 56 3.2 Application to collect medical data screen,the interaction with it and the audio. The camera will be on the left side if the user is right-handed or in the right side if the user is left-handed. Ideally, there should be several people participating in the usability testing, but in that case I will be alone. This also has advantages, as the user will fell more comfortable with only one person. First, I will sit down in front the user, give him a short introduction about the application and explain him the task. After that I will move to be able to see the user using the app and ask him to start. I will take notes while he is using the application. At the end, I will allow the user to make comments or explain anything he wants and I will ask him to ll in a questionnaire. I planned to use the think-aloud technique, which consists on asking the users to speak during the testing explaining what they are thinking. We may have to remember the users to keep talking and we can use silences and the phatic function of language in our favour. That technique is really useful as it allows us to understand the user mental model and if what the users expects is what it is happening in the application. It also helps the user to concentrate in the task and reect on the actions he will do. When using this technique it is really important to explain it properly to the users, so I will give them an introduction, which will be something like that (it is in Spanish as it is the language in which will be done the testing): La aplicación que vas a usar ha sido diseñada para recoger datos diariamente sobre el estado de ánimo de los usarios para enviarlos a un servidor y analizados con el objetivo de poder entender mejor enfermedades relacionadas con trastornos afectivos y mejorar su tratamiento. Lo que debes hacer es registrarte en la aplicación y después completar el test diario de hoy. Todo esto debes hacerlo tú solo, así que yo no te puedo ayudar. Durante la prueba es muy importante que expliques en voz alta todo lo que haces, como porque pulsas un botón o las razones por las pones una respuesta en una determinada pregunta. At the end of any usability testing it is recommended to do an interview, a questionnaire or a combination of them. I will only ask them a general question, as I do not want that they get tired and after that I will ask them to ll in a questionnaire. This way I will have quantitative information. I will use a version of the IBM questionnaire, the PSSUQ, with which I will obtain four variables: the general satisfaction (OVERALL), system usefulness (INFOQUAL and the quality of the interface (INTERQUAL). I used this questionnaire because it is simpler than others, such as UTAUT, and it is quite popular. The questionnaire that I prepared for the interview can be seen in the Appendix: Usability testing questionnaire. 57 3 Android 3.2.4.2 Testing sessions In this section I am going to provide links to the records of the usability testing. Remember that the test was done in Spanish. As I have already mentioned, rst I gave a short introduction. The introduction of the usability testing with the third user can be seen in the following link. The introductions with the two other users are very similar, I choose that one because the audio quality is better: https://youtu.be/wuXlG2m4rOg The testing itself with every users can be seen in the three following links. Remember that every user used his own mobile phone. User 1 (LG-440 - Android 4.1.2): https://youtu.be/xSxgU9x7sP4 User 2 (ZTE blade Apex - Android 4.1.2): https://youtu.be/fmGYmMUiBxw User 3 (Aquaris E4 - Android 4.4.2): https://youtu.be/POcuAoa6ni4 The short interview after the testing with the rst user can be seen in the following link. I chose that one because she was the most communicative user of the three users in this part: https://youtu.be/GzMy9bZuF3k The questionnaires the users lled in can be seen in Appendix: Usability testing questionnaire. 3.2.4.3 Analysis and recommendations The rst users was the younger of the three. She did the testing really well and fast with no errors. She was shy and not very talkative, but when she spoke she gave me really valuable information. The second and the third user get stuck trying to sign up, as they were signing in instead. And as the form it is cleared with clicking sing in that takes them too long and they were much slower than the rst user. The three users found lling the birth date very uncomfortable. Also, the second and the third users did not nd the help buttons, event though they said not to understand how to answer the questions. The rst user found it easily, but she only used for the two rst questions. After that, she assumed how the questions works. 58 3.2 Application to collect medical data That made her to misunderstand the question about concentration, where the question is asking for concentration problems, so the 1 is the best value, in contrast to the other questions. The second user also get confused when the application took a little bit to sign up, although there is visual feedback, as the button change its colour. The three users, but specially the second one, said that it was dicult to know the time they get asleep and fell uncomfortable lling this question. Any of the users opened the terms and conditions, although probably that is not an usability problem, as they knew how to open them but they just did not do it. Also the second and the third users did not understand that the main screen after lling the test was to change the answers and that it was not compulsory. So, if we go back to the questions we wanted to answer with the testing: • ¾Is it easy to complete the register? No. It is quite easy to ll the information, but not to nd where to register. • ¾Do the users understand the questions of the daily test? Most of them, except the one of the concentration, the caeine and the alcohol. It is explained in the help texts, but they did not open them. • ¾Is it easy to ll in the daily test? Yes, it is quite easy. • ¾Do the users understand the icons of the application? Most of them, but no the help icon. • ¾Do the users know what elements are touchable? In general they do, but the terms and conditions and the help icon are exceptions. All this is qualitative information, but I also get the following quantitative information: Questions of the daily test the users do not understand: 3 (Concentration, alcohol and caeine). Number of errors does the user make (without counting not understanding the questions): 0, 3 and 2 respectively. Time that takes the user to complete the daily test: 4, 7 and 9 minutes respectively. We can also get quantitative information from the questionnaires (which can be seen in the Appendix: Usability questions questionnaire) too: 59 3 Android OVERALL (average of all questions): 5.8 SYSUSE (average of questions 1 to 8): 5.3 INFOQUAL (average of questions 9 to 15): 6 INTERQUAL (average of questions 16 to 18): 5.3 The usability problems found can be summarized in the following list. The priority is indicated with a number between 1 and 5, being 5 the the highest priority. • The register is not clear . We should change the register. Adding a new screen to make it more clear if you are signing up or signing in. Priority: 4 • The sign in is cleared when there are errors . We should should not clear it to avoid the users lling the data several times. Priority: 2 • Changing the initial date in the birth date question . We could change the initial date in the birth date question. Priority: 1 • Help buttons are not recognizable . We could change their color and add them relief. Priority: 5 • Concentration question is easily misunderstanding . We should rewrite the help text to make the 5 to be the best value, as in the rest of the questions. Priority: 5 • Visual feedback when clicking a button is not clear . For operations that can take a while (the ones that needs to connect with the server), we could add a Toast message to make it clear that the button has been clicked. Priority: 3 • The question about getting asleep is uncomfortable and get users tired . As the doctor was also thinking that this question may be less useful as we expected, we should eliminate it. Priority: 2 • It is not clear that the main screen after lling in the test is to change the answer . We should add a message to make it more clear. Priority: 3 60 3.2 Application to collect medical data 3.2.5 Future changes Obviously, the development of a large application like that has not yet nished and there are some future changes planned. I have included the changes suggested in section 3.2.4.3 after the usability testing. The changes are ordered by priority, being rst the ones with highest priority. This changes have also been added to the Github repository by creating issues. In Github they have tags to classify them, and screenshots and other useful information has been included. • Change the text help of the question about concentration. We should rewrite the help text to make the 5 to be the best value, as in the rest of the questions, to avoid misunderstandings. • Change help buttons colour and add them relief to make them more recognizable. • Change the register. Add an extra screen to make clear if we are signing up or signing in. • Eliminate the email from SharePreferences . The email and the PIN are both stored in the SharePreferences . As these data is the one used to log in that could be a security problem. If we eliminate the email, internet will be needed to see the prole, but the application will be more secure. • Show a Toast message when clicking a button which activate an action that could take few seconds in nishing . Improving visual feedback this way. • Add a message in the main screen after the daily test has been lled in. This will make clear that now we can change the answers. • Eliminate the question about getting asleep. As it is a new recommendation of the doctor and because of what I observed in the usability testing. • Translate help messages , which are only in Spanish. • Stop clearing the sign in when there are errors to avoid the users lling the data several times. • Add link to www.bip4cast.org in the terms and conditions. 61 Acronyms RAM Random Access Memory. 9 RDD Resilient Distributed Datasets. v,7,912 SQL Structured Query Language. 14,6,11,20,65,66 TIBCO The Information Bus Company. 7 UC University of California. 7 UCM Universidad Complutense de Madrid. 1,25 UTAUT Unied theory of acceptance and use of technology. 57 UTC Coordinated Universal Time. 52 XML eXtensible Markup Language. 4 YMRS Young Mania Rating Scale. 29,30 68 Glossary cluster set of connected computers (nodes) that work together so that, in many respects, they can be viewed as a single system. 7,912,22 g-force a measurement of the type of acceleration that causes weight. 32 horizontally scalable vertical scalability is when only one node is improved. In some cases when this is not enough, horizontal scalability is used. It consists on adding more nodes. When adding more nodes is feasible, it is said that it is horizontally scalable. 2 lux (symbol: lx) is the SI unit of illuminance and luminous emittance, measuring luminous ux per unit area. 32 69 Bibliography [1] Apache Spark ocial web page. URL http://spark.apache.org/ . [2] Lightening Fast Big Data Analytics using Apache Spark. URL http://www.slideshare.net/manishgforce/ lightening-fast-big-data-analytics-using-apache-spark . [3] Streaming Big Data: Storm, Spark and Samza - DZone Big Data . URL https: //dzone.com/articles/streaming-big-data-storm-spark . [4] Code style for contributors. URL http://source.android.com/source/ code-style.html . [5] Index of /apt/debian/dists/wheezy/mongodb-org/3.2/main/binary-amd64. URL http://repo.mongodb.org/apt/debian/dists/wheezy/mongodb-org/3.2/ main/binary-amd64/ . [6] Android developers guide. URL http://developer.android.com/intl/es/ guide/index.html . [7] Escala de Evaluación de la Actividad Global - EEAG. URL http: //salpub.uv.es/SALPUB/practicum12/docs/visidom/Escalas+Instrum_ valoracion_atencion_domiciliaria/129_ESCALA_EVALUACION_ACTIVIDAD_ GLOBAL_EEAG.pdf . [8] Slides: Paradigmas del procesamiento en Big-Data . URL https://sites.google. com/site/tecnologiaucmgtec/downloads . [9] The ham-d scale . URL http://serene.me.uk/tests/ham-d.pdf . [10] M101J: MongoDB for Java Developers course . . URL https://university. mongodb.com/courses/M101J/about . [11] Mongodb documentation, . URL https://docs.mongodb.com . [12] Neural Network Learning in Big Data . URL http://www. journals.elsevier.com/neural-networks/call-for-papers/ special-issue-on-neural-network-learning-in-big-data . [13] Contrato lou artículo 83 siguientes: Ref: 4155904 clínica nuestra señora de la paz, título: Predicción de crisis en el trastorno de bipolaridad, dirigido por victoria lópez lópez (ucm) y por diego urgelés (clínica nuestra señora de la paz). 71 Bibliography [14] Stackoverow. URL http://stackoverflow.com . [15] Young Mania Rating Scale. URL psychology-tools.com/ young-mania-rating-scale/ . [16] GENEActiv instruction manual v1.2, March 2012. URL http: //1yn2me1hmr8p1dh4kt426lhe.wpengine.netdna-cdn.com/wp-content/ uploads/2014/03/geneactiv_instruction_manual_v1.2.pdf . [17] [Bug Watch] Stopping Apps On Android 4.4.2 Can Silently Kill Related Background Services, A Fix Is On The Way, March 2014. URL http://www.androidpolice.com/2014/03/07/ bug-watch-stopping-apps-on-android-4-4-2-can-silently-kill-related-background-services-a-fix-is-on-the-way/ . [18] Apache Spark vs Hadoop MapReduce, December 2015. URL http://www. edureka.co/blog/apache-spark-vs-hadoop-mapreduce . [19] GNU General Public License v3.0, May 2016. URL http://choosealicense. com/licenses/gpl-3.0/ . [20] Positive and Negative Syndrome Scale, January 2016. URL https: //en.wikipedia.org/w/index.php?title=Positive_and_Negative_ Syndrome_Scale&oldid=699130814 . Page Version ID: 699130814. [21] Christopher M. Bishop. Pattern Recognition and Machine Learning . 2012. ISBN 978-0387-31073-2. [22] Enrique Martín. Slides: Sistemas de Gestión de Datos y de la Información . 20152016. [23] Fabio Fumarola. Document Oriented Databases. URL http://es.slideshare. net/fabiofumarola1/9-document-oriented-databases . [24] Google. Material design. URL https://www.google.com/design/spec/ material-design . [25] Jan Losby, Anne Wetmore. CDC Coee Break: Using Likert Scales in Evaluation Survey Work. URL http://www.cdc.gov/dhdsp/pubs/docs/cb_february_14_ 2012.pdf . [26] José Luis Sierra Rodríguez y Rubén Fuentes Fernández. Slides: Programación de aplicaciones para dispositivos móviles . 2015-2016. [27] José María Sordo Juanena. Slides: Programación iOS Y Android . 2014. [28] Justinmind. Justinmind support. URL http://www.justinmind.com/support . [29] James R. Lewis. IBM computer usability satisfaction questionnaires: Psychometric evaluation and instructions for use. International Journal of Human-Computer Interaction , 7(1):5778, January 1995. ISSN 1044-7318. doi: 10.1080/ 10447319509526110. URL http://dx.doi.org/10.1080/10447319509526110 . 72 Bibliography [30] MongoDB. Document Databases. URL https://www.mongodb.com/ document-databases . [31] Tim A. Majchrzak Oliver Schmitt. Using Document-Based Databases for Medical Information Systems in Unreliable Environments. 2012. [32] Pablo Moreno Ger, Guillermo Jiménez Díaz, Antonio Sánchez Ruiz-Granados. Apuntes de la asignatura Desarrollo de Sistemas Interactivos . 2015/2016. [33] Simón J. Rascovsky, Jorge A. Delgado, Alexander Sanz, Víctor D. Calvo, and Gabriel Castrillón. Informatics in Radiology: Use of CouchDB for Documentbased Storage of DICOM Objects. RadioGraphics , 32(3):913927, May 2012. ISSN 0271-5333. doi: 10.1148/rg.323115049. URL http://pubs.rsna.org/doi/abs/ 10.1148/rg.323115049 . [34] Pramod J. Sadalage and Martin Fowler. NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence . Addison-Wesley, August 2012. ISBN 978-0-13-303612-1. [35] Raael Vogler. MongoDB  State of the R, November 2014. URL http://www. joyofdata.de/blog/mongodb-state-of-the-r-rmongodb/ . [36] Welch Labs. Neural Networks Demystied. URL https://www.youtube.com/ watch?v=bxe2T-V8XRs . 73 Appendix: MongoDB conguration le Those are the le mongod.cfg used for MongoDB conguration in both Windows and Debian. Be careful to use spaces and not tabs or it will not work. Windows systemLog: destination: file path: c:\data\log\mongod.log storage: dbPath: c:\data\db security: authorization: enabled Debian # mongod.conf # for documentation of all options , see: # http://docs.mongodb.org/manual/reference/configuration -options/ # where to write logging data. systemLog: destination: file logAppend: true path: /var/log/mongodb/mongod.log # Where and how to store data. storage: dbPath: /var/lib/mongo journal: enabled: true 75 Appendix: MongoDB conguration le #processManagement: # network interfaces net: port: 8080 #security: #operationProfiling: #replication: #sharding: ## Enterprise -Only Options #auditLog: #snmp: 76 Appendix: Actigraph data This appendix contain the rst 99 lines of the .bin generated by the GENEActive actigraph which is wearing one of the patients without any processing. Some lines are too long and do not include usefull information for my project and I have shorted them indicating it with [...] . Device Identity Device Unique Serial Code:029874 Device Type:GENEActiv Device Model:1.1 Device Firmware Version:Ver4.08a date14Jul14 Calibration Date:2015-05-27 10:19:14:000 Device Capabilities Accelerometer Range:-8 to 8 Accelerometer Resolution:0.0039 Accelerometer Units:g Light Meter Range:0 to 5000 Light Meter Resolution:5 Light Meter Units:lux Temperature Sensor Range:0 to 70 Temperature Sensor Resolution:0.1 Temperature Sensor Units:deg. C Configuration Info Measurement Frequency:10 Hz Measurement Period:1440 Hours Start Time:2016-03-04 17:14:33:000 Time Zone:GMT +01:00 Trial Info Study Centre:CNSDLP Study Code: Investigator ID: Exercise Type: Config Operator ID:DUP Config Time:2016-03-04 15:55:35:410 Config Notes:Notes 77 Appendix: Creation of users and roles {resource: {db: "bipolarDatabase", collection: "comments" }, actions: [ "find" ] }, {resource: {db: "bipolarDatabase", collection: "records" }, actions: [ "find" ] }, {resource: {db: "bipolarDatabase", collection: "analysis" }, actions: [ "find", "update", "insert" ] } ], roles: [ ] }, { w: "majority" , wtimeout: 3000 } ) To see the roles: db.getRoles() To remove all roles from the database: db.runCommand( { dropAllRolesFromDatabase: 1, writeConcern: { w: "majority" } } ) 84 To create the users: db.createUser( { "user" : "androidUser", "pwd": "password", "roles" : [ "mobile" ] } ) db.createUser( { "user" : "actigraphUser", "pwd": "password2", "roles" : [ "mobile" ] } ) db.createUser( { "user" : "webUser", "pwd": "password3", "roles" : [ "mobile" ] } ) db.createUser( { "user" : "analyst", "pwd": "password4", "roles" : [ "analysis" ] } ) db.createUser( { "user" : "admin", "pwd": "password5", "roles" : [ "dbOwner" ] } ) To see the users: db.getUsers() To eliminate a user (for example androidUser ): db.dropUser( "androidUser" ) To remove all user from the database: db.runCommand( { dropAllUsersFromDatabase: 1, 85 Appendix: Creation of users and roles writeConcern: { w: "majority" } } ) 86 Appendix: Prototypes images The following images of the dierent prototypes (2 or 3 captures of every prototype, except for the last one, for which 6 captures are shown) pretend to underline the main dierence between every prototype and to make easy to understand the process followed to prototype. You can read more about the prototyping in section 3.2.2.1. Figure 1: Fist prototype 87 Appendix: Prototypes images Figure 2: Second prototype Figure 3: Third prototype 88 Figure 4: Fourth prototype Figure 5: Fifth prototype 89 Appendix: Prototypes images Figure 6: Sixth prototype Figure 7: Seventh prototype 90 Figure 8: Eight prototype Figure 9: Ninth prototype 91 Appendix: Prototypes images Figure 10: Tenth prototype 92 Figure 11: Final prototype 93 Appendix: Usability testing questionnaire Comentarios: 8. Creo que podré hacer uso de la aplicación de forma productiva en un corto periodo de tiempo. 1 2 3 4 5 6 7 Comentarios: 9. Los mensajes de error que aparecen en la aplicación me indican de forma clara como solucionar los problemas. 1 2 3 4 5 6 7 Comentarios: 10. Cuando comento un error usando la aplicación, es fácil y rápido recuperarse de él. 1 2 3 4 5 6 7 Comentarios: 11. La información proporcionada en la aplicación es clara. 1 2 3 4 5 6 7 Comentarios: 12. Es fácil encontrar la información que necesito. 1 2 3 4 5 6 7 Comentarios: 13. La información proporcionada en la aplicación es fácil de entender. 1 2 3 4 5 6 7 Comentarios: 14. La información proporcionada me ayuda a proporcionar información sobre mi estado afectivo. 1 2 3 4 5 6 7 Comentarios: 15. La forma de organizar la información en las pantallas de la aplicación es clara. 1 2 3 4 5 6 7 Comentarios: 16. La interfaz de la aplicación es agradable. 1 2 3 4 5 6 7 Comentarios: 100 17. Me gusta utilizar la interfaz de la aplicación. 1 2 3 4 5 6 7 Comentarios: 18. La aplicación tiene todas las caracteristicas y opciones que esperaba que tuviese. 1 2 3 4 5 6 7 Comentarios: 19. En general, estoy satisfecho con la aplicación. 1 2 3 4 5 6 7 Comentarios: Answered questionnaires The users answers were the followings. 101 Appendix: Usability testing questionnaire User 1 102 103 Appendix: Usability testing questionnaire 104 User 2 105 Appendix: Usability testing questionnaire 106 107 Appendix: Usability testing questionnaire User 3 108 109