CS6440 Design Doc

Design.md

Design Document

Author: Team West Coasters Team: Team West Coasters

1 Design Considerations

1.1 Assumptions

• Framework: Android minimum supported SDK version: 6.0 - Marshmallow, API level 23
• Programming Language: Java SDK 12
• Database: SQLite
• Testing: JUnit4, Robolectric, Mockito (unit, integration), Espresso (UI)

1.2 Constraints

• Data should be persisted across multiple application runs and must not be ephemeral. To satisfy this, usage of a database for storage will be required (as opposed to storing data in application memory).
• A relational database will be used as we feel it would be a favorable choice for managing entity relationships.
• We have chosen SQLite will be used for this product because Android comes with a built in SQLite database implementation.

1.3 System Environment

• Hardware: The application may run on Android OS smartphone (note that although the application would function correctly, it is not designed for optimal UX on a tablet).
• Software: The device must run on Android OS. The minimum supported SDK version is 6.0 (Marshmallow), API level 23. The application itself will communicate with local SQLite database storage on the device.

2 Architectural Design

2.1 Component Diagram

The components and their dependencies are described below:

• Patient - This component represents the user of the application. Thie component will be responsible, based on the user's input, for orchestrating the main actions of the applications of the program. These actions include communicating with the MedicationFinder, PatientHistory, and AlertManager to carry out use cases described further in the respective component descriptions below, as well as in the UseCase document.
• MedicationFinder - This component is responsible for carrying out search for the application. Based on the user's search criteria, the MedicationFinder searches for medication results by communicating with the Medication component.
• Medication - This component represents a specific medication. A Medication includes attributes of drug name and dosage, and communicates with the Illness component to maintain a reference to the illness it can be used to treat.
• Illness - This component represents a static collection of illnesses. The Medication component uses the Illness component as a reference to the illness that a medication can be used to treat. The Illness component also has a reference to Symptom component as a means for maintaining reference to the side effects and symptoms that are categorized by the illness itself.
• Symptom - This component is used by the Illness component as a means for maintaining reference to the side effects and symptoms that are categorized by the illness itself.
• PatientHistory - This component communicates with the Medication component for building a history of medications that the patient has ever used, including their dosage and their medication start and stop dates.
• AlertManager - This component is responsible for taking alert registration requests from the Patient, as well as communicating with the Alert component for fetching specific prescription alert details.
• Alert - This component maintains specific alert details such as alert start time, alert end time, and alert frequency. The Alert component also communicates with the Medication component to alert specific medication information to the patient through the AlertManager.

2.2 Deployment Diagram

The deployment diagram above shows the different components involved in the deployment of this application and how they interact with one another. These components are further described below:

• Android - From a birds-eye view, this application is actually deployed on a single high level component: the Android device. Within the device component itself, however, there are 3 main components that drive the deployment of this application: the UserInterface, the ApplicationServer, and the DatabaseServer.
• UserInterface - The UserInterface represents the visual layer that the user directly interacts with by navigating the application and performing operations by driving input through the device screen. For Android applications, activities are used to facilitate direct communication with the user through the UI. These activities interact with the ApplicationServer component to carry out business logic.
• ApplicationServer - The ApplicationServer is comprised of Java classes that expose interfaces for activities in the UserInterface to interact with. The Java classes depicted as components within the ApplicationServer include Patient, MedicationFinder, Medication, Illness, Symptom, PatientHistory, AlertManager, and Alert. The components shown on the right side of the ApplicationServercomponent in the diagram above are the classes that represent database objects, and are responsible for facilitating communication with theDatabaseServer`.
• DatabaseServer - The DatabaseServer serves data stored in the database. This component exposes an interface for the ApplicationServer to access information stored in the database. For our application, the DatabaseServer is a SQLite server embedded directly on the device.

3 Class and Other Diagrams

You should provide and describe class diagrams based on what you have provided in the previous subsections. You also have the option to describe some dynamic aspects of your system using one or more behavioral diagrams, such as sequence and state diagrams, but it is not required.

4 User Interface Design

For GUI-based systems, this section should provide the specific format/layout of the user interface of the system (e.g., in the form of graphical mockups).