Graphical User Interface for Antimicrobial Peptide Database

This thesis describes the design and implementation of Anti-Microbial Peptide Editable Database (“AMPed”), a tool to enable researchers to efficiently search, display, manipulate and store data about antimicrobial peptides. The tool is implemented as a secure website, created primarily using PHP and MySQL. The website exposes the data collected from a wide variety of sources via a set of common rules and nomenclature making it easy and intuitive for researchers to work with it. The website was evaluated on a variety of web browsers, as well as with a variety of users. It solves the need of non-technical users who spend hours searching and correlating relevant peptide data from a variety of sources for their research needs. This thesis primarily focused on creating and normalizing the database, creating modular search queries and building the web interface. This thesis also introduces a new way to document components of complex and interactive webpages.


LIST OF TABLES
The Web has become an increasingly large part of our culture as its availability has increased in the past two decades. Its user base has expanded from the original tech-savvy core group of people to a wide range of people with fewer or no technical skills that read, search and/or share their own content.
Currently, the Anti-Microbial Peptide Editable Database ("AMPed") is being developed at URI for research on antimicrobial proteins up to 100 amino acids in length. AMPed is an annotated collection of antimicrobial peptides that are sourced from online repositories, journals, and the existing large publicly available databases.
It is today very difficult for a non-technical user to access and work with the data in the AMPed database given its variety and complexity. Every day many users (Dr. Lenore Martin"s research team) get frustrated when trying to use AMPed directly.
AMPed has high quality data, but when the users are not able to effectively use it for their tasks and needs, it becomes almost irrelevant to them. In fact, a simple search query to pull out data can take hours, and at times days/weeks. So users try to avoid using it directly if they can or try to find technical experts to help them to access the data, utilizing precious time and resources.
This thesis, using agile iterative design and development techniques, Gestalt principles of human interface designs and newest web development practices, builds a normalized database, efficient SQL queries, web interaction diagram and a secure graphical user interface (GUI) for researchers to efficiently search, display, manipulate and store data about antimicrobial peptides. The Figure1 below shows an overall view of AMPed system. The GUI exposes the data in AMPed collected from a wide variety of sources via a set of common rules and nomenclature. This work significantly enhances the data access, improves the speed & quality of searching, and eliminates the need to manually correlate information gathered from multiple sources, thereby greatly reducing the time researchers have to spend to locate the right data set. AMPed database, developed as part of this thesis and described in detail later, meets the 3NF i.e. its tables are free of insertion, update, and deletion anomalies.

Web Interface Design
There are empirical studies that have identified basic psychological factors that should be considered when designing a good GUI. To design the AMPED GUI, this thesis used the three primary contributing human factors:  In Figure 2, the responsive home page of the AMPed is shown at large screen.
The same page can be fit to a smaller screen without disturbing the principal of Visual Acuity as shown in Figure 3. AMPed GUI (designed as part of this thesis work) limited the size of icons, menus, dialog boxes etc. to ensure they fit into the limited amount of information the human eye can take at any one time as can been seen in Figure 2 and 3.
This AMPed design also groups information to maintain user focus on one section of the screen. This ensures that the user does not have to constantly move his eyes across the screen causing tiring of the eye due to unnecessary movements.

Information Limits
Information limits refer to the amount of data that a person can process at any one time after he/she has fixed a focus point on the user interface. A study done by Miller showed that "absolute identification using one-dimensional criteria was about seven items, plus or minus two. He showed that this limitation also held for memory span." [5] [6] Miller also pointed out "by expanding the identification criteria from one to more dimensions, people could handle more choices and remember more." [5] AMPed GUI has chunked the information presented to the user (e.g. search criteria) into logical groups. This will ensure that screen is not crowded with data. It also optimizes the number of menu options (e.g. number of search criteria as shown in Figure 4) on the page to develop clean and simple intuitive designs.

Gestalt Principle
Gestalt principle or gestalt laws are rules of the organization of perceptual scenes. This project has applied the Gestalt principles to AMPed GUI design and brings together its various elements in a connected, coherent and unified way. For example, it has leveraged the principle of "continuation" via organizing the data in a top-down approach. The summary results page of AMPed, in figure below, shows how the data is grouped and organized top-down. It has deployed the principle of "similarity" using a template driven approach that helps the user to easily find similar items. For example, AMPed top header has AMPed Logo with home link and a menu bar that consistently has log-in, log-out, Search, DB Statistics and About Us links to help user easily navigate through the AMPed website.

Figure 6: AMPed Header
It uses the principle of "proximity" to place similar search criteria close together so they are perceived as a logical group. Refer to Figure 6 for example. In YADAMP search page, the buttons such as search button is labeled "Query YADAMP!" which is confusing and not very intuitive. Further the size of search and reset buttons are very smalleasy to miss leading to a not very user-friendly design.

Website Data:
The main object of all the existing online repositories is to provide information about the antimicrobial peptides. They however, lack consistency and often have multiple versions of the same data making it difficult for the users to get relevant information quickly. Users also have to jump from one site to another or inbetween several journals spending their valuable time just to understand the data presented to them. Our main focus with AMPed is to provide all the valuable information about the antimicrobial peptides at one place. Users don"t have to jump from one site to another or in-between several journals" as the data is all clearly annotated. For example, as can be seen from the table below, most of the online repositories lack data on 3D structures, amino acids and microbes. AMPed on the other hand provides extensive information on 3D structures, amino acids and microbes alongside the other data, thus making it easier for users and not requiring them to jump in-between sites or journals.

Search Feature:
Antimicrobial peptide data is very large in volume and is increasing at a rapid pace. This makes search feature a critical component driving use and adoption of the online repositories. While every site provides varying levels of criterion to search through the data, most sites just provide a basic search wherein a user can enter the sequence and website returns all possible matches. YADAMP is the only one that provides many options and logical operators for custom search.
However, YADAMP does not provide a description of the different data elements provided on its search page making it more complex for first time users. AMPed also has a robust search feature with many criterions including an option to define a start/end pattern or a pattern anywhere in the sequence, but it is all built in a user friendly way addressing the need of first time or repeat users alike. easily readable on any screen size and maintains data integrity. Amongst all the sites compared, AMPed is the only website that provides a secure login to allow its authorized users to directly contribute to the data. All of the other websites are read only. AMPed"s login feature and ability for authorized users to update the data through the website will allow for greater collaboration and easier maintenance of the data by its users.

Methodology
Agile development methodology is a software development technique in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams [11]. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.
This project used the agile development principles. The AMPed GUI was created iteratively, doing small but frequent releases. Change is accepted in agile development. In fact, it is expected. Instead of a fixed scope, the timescale is fixed and requirements emerge and evolve as the product is developed. For large and complex databases like AMPed where the user needs vary widely, and often evolve, as new data is available, this approach of developing iteratively provided a way to get the maximum value out of the project in a given timeframe.
The first part of this project focused on identifying high-level requirements and analyzing problems that users encounter when working with the existing database.
The requirements were broken-down into the following hierarchy:  Capability (is a requirement that a product must possess to ultimately satisfy a user need or objective) This information was compiled into a prioritized requirement document called backlog. The design and style of webpages, functionality, requirements and scenario of the application were described and matched to the user needs. The highest value requirements of the graphical user interface were implemented iteratively. The following diagram depicts project management for agile development that was used in this thesis [11]. Now let us take a look at the agile process, define the various phrases in the diagram above and provide a sample of how we used this methodology to develop the AMPed system.

Product Backlog
The Product Backlog is simply a list of all things that needs to be done within the project. It replaces the traditional requirements specification artifacts customary in software design. These items can have a technical nature or can be user-centric e.g. in the form of user stories. The thesis used Microsoft Excel spreadsheet to capture a list of all the capabilities, features and stories. The sample below shows the login capability (epic) and the associated stories for this epic.

Backlog Prioritization
The backlog was then prioritized based on business value and technology complexity. Each story was rated H (high), M (medium) and L (low). This helped to decide the order of pursuit for the various requirements and ensure the highest value capabilities are delivered first. The screenshot below shows how the "Audit Trail" epic and stories were prioritized.

Backlog Grooming
Backlog grooming is a product backlog refinement process that is used to keep the backlog clean and orderly. The AMPed backlog was an evolving document. As new information was discovered, epics/stories were added, dropped and reprioritized.
Also, more details were added to epics/stories as the work progressed. The following example shows the addition of Captcha feature to the secure login epic as new information was discovered after we realized that AMPed needed to be secure from denial of service (DOS) attacks.

Sprint Backlog
Sprint backlog is simply a list of stories identified by the team (in this case me) to be completed during the sprint or iteration (explained in the next section). At the start of each sprint, I selected a few stories from the product backlog and then identified the tasks necessary to complete each user story. These few selected stories created the sprint backlog. Once the backlog was prioritized, stories were pulled into sprints to create a sprint backlog. Following picture shows a sample backlog of Sprint 1.

Sprints or iterations
Sprint, also known as iteration, is a set period of time during which specific work has to be completed and made ready for review. Sprints contain confined set of work (i.e. sprint backlog as described above) and have a regular, repeatable work cycle. Each sprint for AMPed was one week long. The following picture shows a sample execution of AMPed Sprint 1. The main focus of the sprint was to design an extensible web template for AMPed and connect to the database. The sprint in total had 30 points planned in the backlog. One point was assumed to be roughly equal to three hours of work.

Develop and Test (Sprint Execution)
Sprint execution is like a mini project unto itself wherein all of the work necessary to deliver the stories in the sprint backlog is performed. Stories from the sprint backlog were pulled in one at a time for development in the iteration. Once the development was complete, the testing was done on that story and any bugs were fixed. A story was marked complete once the acceptance criteria were met, i.e. there were no bugs and the functionality matched the desired outcome of the story. Then the next story was picked up for development. As can be seen in the above figure, at the end of Sprint 1, 17 points were achieved, 3 stories were completed and 2 stories were carried forward in Sprint 2.

Review (Sprint Closure)
Sprint review is the last step in this small interment work approach wherein the stakeholders, if available, can see the progress made and review the working code. Now, let"s take an example of one of the capabilities developed as part of this thesis, Secure Log-in, and describe in detail how agile methodology was used to do adaptive planning, incremental development and early delivery all in tandem with a rapid response to change.
As part of the AMPed vision, Secure Log-in was identified as a very important capability. The Secure Log-in capability was first broken down into the following user stories. Each sprint was one-week long and the following section details out the work done for the three stories highlighted above.

Story
First, the user story 1.1 was picked and the following tables in the AMPed database were developed: Then, the tables were loaded with some sample data. After the tables were created, the user interface stories (1.3 and 1.4) for entering user id and password were picked.
We created the UI templates first, then the data entry fields and then the login submit button. The UI was then tested on various browsers. After this, PHP coding was done to connect the UI with the database tables and tests were done to ensure log-in was successful only for the valid users loaded into the table.
Then the completed work (i.e. the three Login stories referenced above) was reviewed in the weekly meeting with major professors. When the story/stories were approved in the review cycle it was added to the Project increment as final product. In this case, all three stories were approved and added into the login capability for AMPEd.
Any change, enhancement or addition requested during review was taken back to the AMPed vision and Product Backlog. Then the feedback was analyzed to create user stories that were then groomed and prioritized. Based on the priority, these feedback stories were pulled into the appropriate future sprint backlog for execution.
The three stories above created the following product increment: This iterative process was used for all the stories for several weeks that in turn guided the completion of AMPed vision. For example, in the next sprint, the following CAPTCHA stories were pulled in for execution.  [5]. For this thesis, we will call earlier work on AMPed "Version 1" and this thesis work "Version 2". The analysis and research done in this thesis discovered that some areas of the Version 1 database needed to be updated and reorganized. There was some duplicity and the database was not fully normalized. Database normalization is the process of organizing the columns (attributes) and tables (relations) of a relational database to minimize data redundancy and prevent anomalies in the data results. The objective is to isolate data so that additions, deletions, and modifications of an attribute can be made in just one table and then propagated without error through the rest of the database using the defined foreign keys used to connect the database tables [5] [6].
The AMPed web interface depends on the data in the AMPed database to provide users an insight into the different aspects of antimicrobial peptides. To improve this capability and to reduce potential inconsistencies in the data, the AMPed database was redesigned and implemented again.
To redesign the AMPed database, I first updated the entity-relationship (ER) model of Version 1. This is conceptual model of the database. We looked at the various user needs and added/deleted entities and relationships to refine the model further. This model was then mapped to a new database schema, AMPed Version 2.
Since the peptide data is very complex and available in bulk, new information to improve the design was discovered on an ongoing basis. Also, different researchers had different needs that were discovered as the thesis progressed. So the database design kept changing as more information and new aspects were discovered and added. We used agile iterative development process to respond to the changes with constant communications and inputs from the thesis major professors; the final design of the database was then completed. Throughout the process the ER diagram was first modified, which in turn guided the database schema or table specification process. [7] The Version 1 of the AMPed database diagram is given in Figure 8 for reference.  7. Cardinality of Relationship: Some relationships earlier identified as 1:1(one to one) or 1:N (one to many) were changed to higher order cardinalities to be consistent with the nature of the data. For example, the number of occurrences in Peptide entity associated to the number of occurrences in Article entity is changed to N: M (many to many) relationship.
The entity relationship diagram in Figure 9 shows the new relationships of entity sets stored in the AMPed database. The ER diagram ( Figure 9) pulled together all the entities and relationships of the constraints. If one of the rows that are part of a reference is changed, all the references to it will be updated immediately. Thus, the 3NF AMPed database minimizes data redundancy, helps to maintain data integrity and supports the construction of robust search queries.
If it is necessary, to add or change the AMPed database design in the future, the ER diagram here can be referenced to assist understanding of the logic structure of the database, saving considerable time and effort.

Database Schema of AMPed
The diagram (Figure10) below shows the current AMPed database with tables, cross-referenced tables, primary keys and constraints applied. It also describes the physical structure of the AMPed database. Figure 10: Tables of Current AMPed Database

Legends for Figure10
No Constraint Not Null

Primary Key
The description of the AMPed database tables with its attributes, data types and details are given in appendix. As we completed the database schema, we were able to design and implement the interface. The interface helps the user to access the data and cannot be implemented until the structure of the data is settled.  Tool-independent: The vocabulary should be designed so that specialized software tools are not required in order to construct diagrams.
The vocabulary should enable developer to work with the tools they are most comfortable using. To develop WIDs, we combined the visual vocabulary principles above with traditional software design techniques. The following section describes the threephased process that can be used to design a WID for any web development project:  Phase 1 -WID Information Gathering: This initial phase of analyzing the sequence and flow of website may not be necessary for every project.
However, many situations require the developer to be focused on goals, and given these goals, work through a strategic and organized approach to the website development. In general, it is important to discuss the purpose and the goals of the website, collect requirements, specify the capacity of the system collecting data, discuss platform. This helps to assemble a big-picture view of the scope of the project based upon this information. When we design the WID, we start with a vision, and then set up rules that everyone else involved in creating content from that point forward could follow. The initial design creates a high-level structure scope of the WID.
High level structure of WID will contain a list of unique website pages and a high level navigational flow. In AMPed, the objective of describing the WID is to emphasize how the user flows through defined tasks, and what the discrete steps are within these tasks. As described earlier, WID displays navigation along with the information about interface.
WID vocabulary is based on a simple conceptual model on interaction design. Based on the above concept the following web interaction diagram (WID) depicts the flow of the AMPed website. The diagram is created using word document tools.

Connectors and Arrows
Navigations between pages are depicted with simple arrows or connectors. But all navigational relationships in the diagram may not be noted.
Here, connectors also need to convey directionality to indicate how the user will move through the site toward completion of a particular task. So, arrows will do the trick nicely.
These arrows are not like indicating a one-way street, but rather indicating the way to move forward. The user is not prohibited from moving in the opposite direction; the arrow merely indicates the direction in which the user is likely to want to go.    Before we dive deeper into the AMPed user interface, we will take a closer look at its architecture. Looking at the architecture will help us to understand the structure of the APMed web system from different perspectives and how we managed the complexity of AMPed in the most efficient and understandable way.

Architecture
AMPed web is based on a two-tier client-server architecture. Client-server architecture is a network architecture in which each computer or process on the network is either a client or a server. Servers are powerful computers or processes dedicated to managing disk drives (file servers), printers (print servers), or network traffic (network servers). Clients are PCs, laptops, tablets or smartphones on which users run applications. Clients rely on servers for resources, such as data files and processing power [1]. In AMPed, researchers primarily use their laptops and PCs to request the peptide data. A webserver receives the incoming requests from the researchers" machines, validates the requests and then does the necessary processing to return the requested services (i.e. data and web pages). The Figure 13 below shows the client-server architecture of the AMPed web.
AMPed"s client-server architecture, as can be seen in the figure above, has three major components: 1. Client Side: Client side is the actual interface for the user of AMPed website.
The application such as web browser (Firefox, Safari, Google Chrome, Internet Explorer etc.) on the client machine sends service request data to APACHE webserver running on a powerful server machine at URI. The webserver then either sends an existing page to the client machine or generates a new page and sends to the client machine accordingly. On the client side, the web browser displays the web page, constructed by using the HTML, CSS and Bootstrap sent by the webserver. Now that we understand how the peptide data is stored, processed and viewed by the researchers, let"s take a deep dive into AMPed user interface design. Let"s start with the webpage layout that explains how AMPed web interface is built and how it looks to the end user.

Webpage Layout
The AMPed user interface has an intuitive design that makes the information easily accessible to researchers and it can be accessed through desktop, laptop or smartphone devices via a web browser. To develop the AMPed GUI, this thesis combined technology, cognitive science, human need and the latest web design practices. The modular components and screens developed here will provide a good model for other similar web based GUI for databases. In addition, the agile development principles used by this project helped the research team to organize and prioritize their requirements and helped to iteratively add features to the GUI as user needs evolved.
The AMPed webpage has a simple and extensible layout. Each page has visible branding, persistent navigation and intuitive content location organized for simple but user empowering functionality. Behind the scenes, each page uses a defined template that has externalized styles and reusable components built for scale and performance. The section below provides insights into few of these layout features.

Reusable Components
To achieve fast and less error prone development for edits and enhancements, this thesis built AMPed webpages using a component driven design. In order to achieve this, each page, capability and feature was analyzed to check its use and reuse on the site. For example, web Footer was identified as content that will be used at multiple pages and may need to be updated every year for copyright information or every time the navigation is enhanced. Thus the footer was built as a standalone web page

Extensible Templates
Each page in AMPed is built on templates using DIV tags. The DIV is a generic block-level element. It doesn"t convey any meaning about its contents. It is easy to customize according to varied design needs. The DIV element is currently the most common method for identifying the structural sections of a document and for laying out a web page using CSS. It is used as an "anything-goes" element. It can contain inline or block-level elements. So, it can contain almost any other element. Also, this element has no compatibility issues. Almost all the devices, browsers and those listed in this thesis document support the DIV element.
The DIV element in AMPed is used to group varied content and functional elements together. The HTML code snippet below shows DIV tags being used to identify different sections of the AMPed web page and in conjunction with html attributes.

Externalized Styles
This thesis used external style sheets to define styles for AMPed web pages, including the design, layout and variations in display for different devices and screen sizes.
These external style sheets were stored in Cascading Style Sheet (CSS) files. CSS is a stylesheet language that describes the presentation of a web page in HTML. CSS describes how elements must be rendered on screen, on device, or in other media.
CSS saves a lot of work as it can control the layout of multiple Web pages all at once.

56
A CSS rule set consists of a selector and a declaration block as in the figure below: Figure 16: CSS Rule Example The selector points to the HTML element that one wants to style. The declaration block contains one or more declarations separated by semicolons. Each declaration includes a property name and a value, separated by a colon.
Here is a small snippet of the AMPed code that illustrates the use of CSS. In the following example, main.css file was included in the AMPed webpage. The code illustrates how a part of this CSS styles with all <h> elements will have font-family Roboto with sans-serif. h1, h2, h3, h4, h5, h6 { font-family: 'Roboto', sans-serif; }

AMPed Web Flow
The following figure of AMPed web flow chart gives a big picture of the pages that the AMPed website contains in a high level site map. Countlog.txt.

Login Page
The login page is used for entering identifier information by a user in order to access the AMPed data. The login function in AMPed requires the user to enter three pieces of information: Number of Visits 1. User Name: referred to as an account name, is a string (i.e., sequence of characters) that uniquely identifies a user. User name in AMPed is a completely arbitrary value assigned by the AMPed administrator.
2. Password: similar to User Name, password is a string, but it differs from a user name in that it is intended to be known only to its user. Passwords do not display in clear text in AMPed GUI.
3. CAPTCHA: is a graphic presented with distorted text used to tell whether the user is a human or a computer. It is described in detail later.

Figure 19: AMPed Log-in Page
These three pieces of information are entered into a login bricklet on the AMPed GUI shown above. When the user attempts to log into the system, a Captcha image is first generated by the system and compared to the text entered by the user. If correct, the user names and passwords entered by the user are compared with data contained in special User tables in the AMPed database. If successful, user is provided access to the AMPed site. The process of logging in creates a session (i.e., a period of use), also referred to as a login session, for the user on the AMPed system. The user is able to access AMPed secure content only while the login session is alive. In addition to restricting access, logins also provide an audit trail in the form of data that is automatically entered into system log files (i.e., automatically updated files that contain records of events that have occurred on a system).

About Us
The About Us page provides an overview of the team behind the AMPed effort. It also provides insights into the research work that the team is doing.

Search Criteria
The search criteria page allows a user to search for specific information in the AMPed database. As can be seen in Figure 22 below, a user can pick and choose one or more items to search for. Based on user selection, AMPed, behind the scenes, formulates the search query and processes the data to display summary results.

Summary Search Results
The summary search results page displays the relevant data to the user in an easy and intuitive way. It is a list of all the records that match a criteria that the user provideds. The results, as shown in the figure below, have a navigation link for each record that can be used to get further details. The results page displays the number of records found and automatically sorts the data on Unique ID.

Detailed Search Results
A detailed search results page is navigated to when a user clicks for detailed data on the summary results page. The detailed search results page displays all the data available for a particular peptide in a single view.

Figure 24: AMPed Search Detail Results Page
Search is one of the most critical user functionality in AMPed. In the next chapter, we will take a deeper look into how the AMPed search capability works.

Search
In this section of the paper, we will dive deeper into AMPed"s search capability that makes heavy use of PHP and structured SQL queries to retrieve data and present relevant results to the researchers. Engineering the AMPed search functionality was a challenging task. The AMPed search needed to be flexible to meet the needs of the range from expert to novice users and be able to process a variety of criterions through tens of thousands of records in the AMPed database tables. The search had to be designed for speed and accuracy. The search also had to manage a variety of data types.
Apart from applying the traditional database search query techniques, there was a technical challenge in designing the AMPed search due to the need to parse the very long text strings of Amino Acid (AA) Sequences to enable full and partial matches on the data. The full and partial search option on AA sequences allows researchers to quickly and accurately find results that might be of interest to them. The example below highlights how a full and partial string search using an amino acid sequence provides different results when searched via AMPed.

Search Design Goals
AMPed is used by a varied set of researchers whose time is very precious. It relies on a huge database with a many different data elements. Further, the data within AMPed is growing at a very rapid pace. Thus the AMPed search capability was designed with the following two primary goals:  Quality: AMPed has a large amount of data and as research continues, it is expected to grow at a very rapid pace. Thus one of the main problems for AMPed search was that the number of documents will be increasing by many orders of magnitude, but the user's ability to look at documents will not. People will still only be able to consume only the first few tens of results page. Further, the results pages were broken into summary and detailed results to limit the data processing needs and provide results faster.

SQL (Structured Query Language) is a special-purpose programming language
designed for managing and accessing data held in a relational database management system (RDBMS). AMPed data, as described earlier, is stored in a RDBMS. AMPed search primarily uses SQL queries, to process and retrieve the results from the AMPed database. Now, let"s take a closer look at a few AMPed search queries. [2]

Fetching Data: SQL SELECT Queries
As part of this thesis, we spent a considerable amount of time developing means to fetch and display peptide data. The main challenge in designing the AMPed search feature was that the user wanted to "slice and dice" data in varied ways. That is, they wanted to look at the data and analyze it in an endless number of different ways, constantly varying the filtering, sorting, and calculation rules on the raw data. AMPed used the SQL SELECT statement to choose the relevant data that users wanted returned from the database [3][4] [2]. The following example shows how AMPed used the SELECT statement to retrieve data that matched a particular peptide name: First, connect to the database: //Connect to the AMPed Database; $hostname='***.*.*.*'; $usrnm='*****'; $pwd='*************'; $dbname='AMPed'; $con = mysql_connect($hostname, $usrnm, $pwd) OR DIE (mysql_error()); mysql_select_db($dbname); Then, run the SQL query to fetch the relevant data.

SECURE ACCESS AND AUDIT TRAIL
In this section of the paper, we will dive deeper into AMPed"s security capability, specifically the log-in function that was designed to provide secure user access and maintain AMPed"s Audit trail capability. Let"s do a deep dive first into AMPed Log-in feature that can be, at a high level, broken down into two parts: In today"s age of spamming, website managers have adopted techniques to prevent automated programs from performing functions that are supposed to be performed by human visitors to the site, such as log-in. AMPed has achieved this through implementation of CAPTCHA. CAPTCHA is a program that can prevent a computer from looking like a human. It is a loosely contrived acronym meaning "completely automated public Turing tests to tell computers and humans apart." [5] CAPTCHAs are graphics presented with distorted text. In AMPed, it is placed within the login form. AMPed websites uses CAPTCHA to specifically prevent abuse from "bots," or automated spamming programs that might try to login to AMPed website.
The computer programs can not read distorted text as well as humans can, so bots are less likely to enter the AMPed site protected by CAPTCHA. The process involves generating letters and numbers that appear in a distorted graphic and a text entry field is provided for users to enter the text of the CAPTCHA image.
The following provides a CAPTCHA script that is designed to thwart bots from logging into the AMPed site. It has been observed that users often confused with few letters and numbers when using features like CAPTCHA as they are hard to recognize. So, to ensure ease of use, we also configured CAPTCHA code to not use, letters -"O", "I", "l" and numbers -"0", "1". These can be confusing for a user to interpret in an image. This was achieved by building a small configuration in the code so that it can be easily edited when needed.
Note: GD library is enabled by default as of PHP 4.3 and was an option before that.
The following describes the CAPTCHA set for the AMPed login page.

Memory allocation for the image is removed
imagedestroy($im); .

Username and Password
Users are required to register as a member of AMPed. They are required to send their details to Professor Lenore M. Martin or the individual/team assigned this job.
Their profile will be screened and checked before the administrator registers them as the member. AMPed is designed to have different levels of access. As part of user creation, administrator creates a user name, password and also puts the user into one of these access levels. This helps maintain appropriate controls for authorized access to read, write, edit, and append access.
The login validation is performed on the server side. Server page programs and algorithms are not visible to the clients, so it will be more secure and better approach to validate input on server side. For Amped, we used the server side script in PHP, MySQL and JavaScript to validate the input directly. As explained in the Log-in page section of this thesis, the user is required to enter the username, password and CAPTCHA letters to log-in. First CAPTCHA letters validation is performed before sending the request to the database for user name/password validation. This helps avoid the unnecessary interaction with the database and helps give more robust security. If CAPTCHA validation is passed, the entered username and password will be cross checked with the AMPed database. The user will be logged-in into the AMPed site only after successful validation of all the criteria.

Audit Trail (Maintaining user access logs)
We can get the Internet Protocol (IP) address of any visitor by using PHP.