This application imports electronic medical records (stored in text files) from the selected folder and runs each file through the natural language process of:
Removing stop words
Creating an index
For stemming the Porter Stemming Algorithm is implemented to transform a word into its root form and contains six steps:
Get rid of plurals and –ed or –ing endings
Turn terminal y to I when there is another vowel in the stem
Map double suffices to a single one
Deals with –ic-, -full, -ness etc. endings similarly to step 3
Takes off –ant, -ence, etc. in context of <c>vcvc<v>
Removes final –e if the measure of the number of constant sequences between 0 and j is greater than 1, i.e. <c>vcvc<v> gives 2
A trie (prefix tree) is an ordered data structure used to store the index in memory. All descendants of a node have a common prefix under the same branch. The common prefix eliminates the need for storing the same prefix each time which increases memory efficiency. A simple representation containing the words aspirin, ankle, and pain is:
When the user searches for keywords, Figure 1, spaces are seen as an AND condition and commas are seen as an OR condition. A list is displayed to the user showing the file names of the documents which contain there search terms. Double clicking on a particular document will open a new tab displaying the documents contents and highlighting the keywords present in the document, Figure 2 & 3. When mousing over the keywords found the SNOMED and UMLS IDs are displayed. These are determined based on a separate trie data structure built from the SNOMED CT data.
This application consists of three main parts which are the client, server, and the game of SOS. The server ran on an Elastic Cloud 2 (EC2) instance with Amazon Web Services where I configured the Windows server and supporting software. This includes creating a database in MS SQL Server, creating the necessary users and assigning them to the database they can access. Mappings are set for the user which grants the necessary permissions. The firewall also needed to be configured to allow the appropriate ports access so clients could connect to the server (and the server could receive connections). Internet Information Services (IIS) was also configured so that the Java Network Launch Protocol (JNLP) MIME type was recognized by the web server so that the client could be launched using Java WebStart from a webpage.
Client-Server communication uses a server socket that listens for incoming connections. When a connection is accepted a new thread (ClientHandler) is spawned which handles communications with the client through a socket. Java’s ObjectInputStream and ObjectOutputStream are used in order to send and receive Java objects.
Threading is used on the client side to listen for messages from the server. On the server side each client connection is ran in its own thread and handled by a ClientHandler class.
Database access is handled by the server using Java Database Connectivity (JDBC) drivers. Any information retrieved from the database is sent back to the client using a data transfer object (DTO) and packaged as a games room message of the correct type.
The application allows users to chat in a main room or create their own chat rooms which can be public or private. Users are able to join any public room but the only way a user can join a private room is through an invite from an active participant. Files can be sent to users of a room. This is done by reading the file as bytes and sending the byte array along with the filename as a string to users in the room. Java’s FileOutputStream class is used to write the file to the recipient’s local machine if they chose to accept the file and saved it.
Users are able to manage their profile information, Figure 1. Which allows them to change certain information, including updating their password. The application uses a hash implementation using the password-based key derivation function 2 (PBKDF2) algorithm with HMAC and SHA1 (part of RSA public-key cryptography standards) for hashing user passwords and then storing the hash value in the database. When a hash is being created for a password the string is converted to a byte array and a salt is created using java.security.SecureRandom for the specified salt byte size. The PBKDF2 hash of the password is then computed by creating a password based encryption (PBE) key of variable-key-size PBE ciphers utilizing the users’ password, salt, number of iterations, and how many bytes the result should be. Javas secret key factory, part of the javax cryptography package, is then utilized to generate the secret key (hash of the password) for the PBE key specification. All relevant data is then placed into one string which takes the format of ‘iterations:salt:hash’ where the salt and hash is first converted to hexadecimal. The colons are critical as they are utilized for splitting the information when validating passwords.
Users are able to play the game of SOS, Figure 2, when they are in a room they have created. The first two members to join the game can play, as it’s a two player game. The game implements the MVC pattern, using SosController.java as the controller, GameView.java as the view and the ChatClient as the model for how to handle requests from the user to the server and vise versa. DTOs are used to transfer data between the clients through the server as well as for saving game states. The DTOs are Board, Player, PlayerMove, SavedSosComponents, ScoreCard, and Turn.
Users are able to save the contents of a chat session for later viewing and a facility to view and manage any saved chats is provided, Figure 3. Users can also save a games state to be continued at a later date and when loading a saved games both participants must be logged into the application. Game states are converted to XML using XStream to be stored in the database.
Validators are created by implementing my Validate interface and a separate class for each validator (i.e. NewRoomValidator.java) is created. This separates out the process of validating information entered into the GUI from the actual GUI code itself.
This was a group project in which my role was to handle the networking / multiplayer aspect of the game. This application implements the Model-View-Controller (MVC) pattern.
The server runs in a thread and handles all client connections. Each client connection is represented by its own class (Client) which handles sending a message to the individual client and receiving data from a particular client to the server. Each client runs in its own thread. The run function listens for messages from a particular client and handles it by the message type. While the length of the message is less than the message length data is read from the socket and added to a message variable. A check is done as to where the end of message flag is and adds the overflow into the buffer and then passes the message type and packed message to be processed by the server.
The client runs in a thread and handles all communication between the client and the server. Interpreting messages received from the server and packing messages prior to sending them to the server.
The server controller runs server side to handle updates from the client and the client server runs client side to handle events from the user interface to be sent to the server as well as to update the view based on messages received from the server.
Figure 1 and 2 show UML diagrams for the key components of the application I worked on, the server and the client respectively.