When storing a user's medical data, security is paramount. We do not want an attacker to be able to steal sensitive information that could be used to harass or blackmail patients. For this reason, we will be encrypting the MySQL database. To protect our user's passwords from being stolen, we will implement salting and hashing in our user account store. These measures, while not bulletproof, will help keep the users safe in the unlikely event that our server is compromised by attackers online or within the server room.

Since most modules will be depending on retrieving and modifying this data, I will need to work closely with all members of the team. In order to reduce work, we will need to agree on uniform modes of access to the system.

Overview:

Data:

This module works closely with most other modules in this project. Much of the functionality acts as a wrapper to the database for these modules. In this way, we will come in contact with many of the data structures defined in their detailed designs:

• Chat Manager - Message
• Dr. Manager - Pill Schedule, Appointment Schedule
• Event Manager - Event
• Calendar Manager - Calendar format

In addition, this module will incorporate two new data structures: Setting and Account.

In the Setting structure, doctorName corresponds with the username of the user's doctor. This is used to match doctors and users in a one-to-many fashion. A boolean value of true in isDoctor indicates that this account belongs to a doctor.

In the Account structure, salt refers to the random data used in the one way hash algorithm provided by PHP. The hashPassword is the result of that hash algorithm. Both are needed to verify a user's real password.

User Interface Visualization

Visual of HTML page produced by displayLoginUI()

Visual of the HTML page produced by displaySettingsUI()

Operations:

As noted above, one of the main functions is to pass data inbetween modules and the database. This allows other team members to not have to learn SQL queries and the details of how the data is stored. The other duty this module performs is to keep track of user accounts and the process of logging in and out. Many of these other functions will heavily rely on the built-in capabilities of PHP, such as the native password hashing API.

PHP is a great way to interface with our MySQL installation. It inclueds a library of functions dedicated to MySQL operations.

We will make the most of the features available to us through PHP to store and retrieve our user data.

Interfaces

Interfaces are provided for account functionality and for other modules to access the database. Each other module has its own interface to the database. This makes it easier to maintain a low level of dependency between modules. It is also easy to modify the interface to match the needs of each module

• Interface A: Session Mgr - manages logging in and logging out.
• Interface B: Creation Mgr - manages creating a new account.
• Interface C: Settings Mgr - allows users to modify their information in the database
• Interface D: Char DB Mgr - stores and retrieves user messages from the database
• Interface E: Dr. DB Mgr - stores and retrieves data on pill and appointment schedules from the database
• Interface F: Calendar DB Mgr - reads the database to find relevant information for the calendar
• Interface G: Alert DB Mgr - reads the database to find and create new user alerts

Event Sequence Diagrams

The first diagram represents creating an account. The second represents logging in and changing an account setting.

Class Diagram