Software Design Document SE 4351 – Requirements Engineering, Section 001 Fall 2013 Name UTD Email Keegan Reap jkr093020@utdallas.edu Jeffrey Hertzing jah105020@utdallas.edu Ken Nakano kxn099120@utdallas.edu Rotan Bosson reb101020@utd.edu Josh Murphy jcm052000@utdallas.edu Michael Bond mxb105320@utdallas.edu Branch (Brandt) Jones bwj091020@utdallas.edu Kylie Kniep kbk090020@utdallas.edu Alan Vo adv090020@utdallas.edu Chris Kaufman csk096020@utdallas.edu Kevin Lin kxl099220@utdallas.edu Sami Bouaazzi smb093020@utdallas.edu Tej Gidvani tpg090020@utdallas.edu Temesxgn Gebrehiwet Thg090020@utdallas.edu 1 Table of Contents Revision History……………………………………………………………………………………………………………………………………3 1. Introduction………………………………………………….……………………………………………………………………………………4 1.1 Purpose of the System………………………………………………………………………………………………………4 1.2 Design Goals……………………………………………………………………………………………………………………..4 1.3 Definitions, Acronyms, Abbreviations………………………………………………………………………………5 1.4 References…………………………………………………………………………………………………………………………5 1.5 Overview…………………………………………………………………………………………………………………………….5 2. Current Software Architecture…………………………………………………………………………………………………………6 2.1 Software Architecture…..……………………………………………………………………………………………………6 3. Proposed System…………………………………………………………………………………………………………………………….6 3.1 Overview…………………..………………………………………………………………………………………………………..6 3.2 Subsystem Decomposition………………………………………………………………………………………………6 3.3 Hardware/Software Mapping…………………………………………………………………………………………..6 3.4 Persistent Data Management …………………………………………………………………………………………6 3.5 Access Control and Security……………………………………………………………………………………………6 3.6 Global Software Control……………………………………………………………………………………………………6 3.7 Boundary Conditions…………………………………………………………………………………………………………6 4. Subsystem Services…………………………………………………………………………………………………………………………6 4.1 The User Interface (UI) Subsystem…………………………………………………………………………………6 5. Glossary……………………………………………………………………………………………………………………………………………6 2 Revision History Version 1.0 1.1 Date 09/25/2013 09/30/2013 Comments Template Initial draft 3 Author T. Gebrehiwet T. Gebrehiwet 1. Introduction This document describes the overview of the software architecture and design goals set by the project. This includes subsystem decomposition, data management, control flow, and other services later detailed in the document. 1.1 Purpose of the system Remember MEds is an Android application that tracks medical prescriptions, alerts the user when it is time to take a dose of their medicine, and also make emergency phone calls. This application is meant for people with memory, disabilities, elderly people, and the technology illiterate. Taking prescribed medication on time is crucial for one’s health and safety. Remember MEds allows the users to take their medications on time even when they forget to take them. 1.2 Design goals Design goals represent a set of standards that are desired for the system when making design decisions. 1.2.1 Reliability 1.2.1.1 The application must be 99% correct when processing commands 1.2.1.2 The application must self-reboot if a failure occurs 1.2.2 Response Time 1.2.2.1 The response time to the user should be less than 4 seconds. 1.2.2.2 The application updates should occur when not in use. 1.2.2.3 The application must keep activity logs and prescription logs every hour. 1.2.2.4 The application must recover within 1 minute if a crash occurs. 4 1.2.3 Workload 1.2.3.1 The application will not make any calculations except for the addition and subtraction of the pills. 1.2.4 Platform 1.2.4.1 The application will be available on Android phones. 1.2.5 Security 1.2.5.1 The application will have no sensitive data and not make any internet interactions. 1.3 Definitions, acronyms, and abbreviations Term Definition Cohesion Degree of interaction within a module. Coupling Degree of interaction between two modules UML Unified Modeling Language 1.4 References Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2nd ed., C. Larman Object-Oriented Software Engineering, 1st ed., S. Schach 1.5 Overview This document presents and explains the functionality of the system from the system’s point of view with in-depth UML diagrams for the layers and interactions of the modules. The decomposition of the system into subsystems is to be done that minimizes coupling and maximizes cohesion. 5 2. Current software architecture 2.1 Software Architecture There is no software architecture presently for the application. The system receives input from the user, processes it, and returns a confirmation to the user. When a user presses the new button the screen goes to the add medicine prescription page. The user then enters the necessary information for the medicine and clicks the add button. Once the user presses the add button a label confirming that the medication has been added to the list of subscriptions. The screen goes to the home page after the confirmation label disappears. The process is done in one layer and everything is stored onto the device running the application. The lack of having no software architecture could be the difference between life and death for the patient. The proposed software architecture will address these issues by creating layers for each component. 3. Proposed software architecture 3.1 Overview 3.2 Subsystem decomposition 3.2.1 User Interface Layer *Add more 3.3 Hardware/Software mapping 3.4 Persistent data management 3.5 Access control and security 3.6 Global software control 3.7 Boundary conditions 4. Subsystem services 4.1 User Interface Subsystem * add other subsystems from 3.2 5. Glossary 6 7