Architectural Design
Contents
1. jrios 777 Sixto Josue Rios xalicex1 Alice Cheng tadrip Tadrill Perry jli93 Jessica Li cho1993 Michelle Cho jnzhut0 Junhao lan Zhu kkbrandt Kaleo Brandt thaond Thao Nguyen Dang Architectural Design System Architecture Major Modules Classes e Account Abstraction o User account object that represents a single user account of the application It stores all the required optional information of the user Such as name email gender etc e AccountManager Utility Class o Has the methods that will be used to manage user s current accounts editing adding deleting information o Acts between the activity classes that listen to events and the Database that stores all of the data e DatabaseManager Utility Class o Has the methods that will be used to manage the data and information needed for this application Allows other classes to look up edit add information to the database e MealPlan Abstraction o An object that represents a single MealPlan that exists in the application This stores all of the information of the event data time host etc e MealPlanManager Utility Class o Has the methods that will be used to manage the MealPlans This allows MealPlans to be changed or updated or deleted User Interaction Classes e CreateMealPlanActivity o Listens to see if the user wants to create a new MealPlan and notifies the MealPlanManager to carry out the appropriate work to add the meal plan for the user e JoinMealPlanA2. Long hostName String date Date papery mood Sirang d Date taTima geno ea valadateCode code int boolean foodMood String description String y Year List lt MealPLan gt query List lt MealPlan gt updateaccount act Account boolean location string Login id long password String boolean addMealPLan plan MealPLan boolean cancelMeaLPLan pLan MealPlan attendeeID Long boolean parseData values ContentValues List lt MealPlan gt addattendee userID long plan MealPlan boolean getCurrentUser Account a getAttendees plan MealPlan List lt String gt getDescription Strin ge pian g tgetuserInfo userID long Account heera i 9 getAttendingPlans userID long List lt MealPLan gt getLocation String DBManager TABLE_ACCOUNTS String TABLE_PLANS String TABLE_ATTERDING String update table String values ContentValues id int boolean H insert table String values ContentValues boolean remove table String values ContentValues boolean query table String wherekeys String whereArgs String List lt ContentValues gt 7 7 N AWS Cognito Identity Sync Database AWS RDS A second view at our system from an MVC design App Database Update Remove CONTROLLER Database Manager DB action Update Account New Account Validate Accou DB action Update Plan New Plan Cancel
3. Plan Query Plans Meal Plan Manager User Interface Account Manager Account action Login Sign up Manage eal Plan action Create Join Cancel Sees Sequence Diagram for Creating a Meal Plan MyPlansFragment CreatePlanActivity User Requests MealPlan Creation User enters data then saves MealPlanManager MealPlan Datab aseManager lt lt create gt gt addMealPlan insert success code Djsplay success failure Sequence Diagram for Joining a Meal Plan HomeFragment PlaninfoActivity AccountManager MealPlanManager Datab aseManager l l User starts app parseData MealPlans Display results Selects meal plan Clicks join Account Process Risk Assessment The most serious risk is if the integration between the back end and front end components of the system fails The likelinood of this occurring is high since the teams working on the front end and back end are different Therefore the possibility of a bug or problem occurring substantially increases The impact of this risk can range from low to high depending on what part of the system fails If the integration completely fails then the app will not work If there is a very small integration error then the error could go undiscovered In order to minimize this risk we ve assigned the integration team t to facilitate communication Additionally the testing team will carry out
4. black box experiments concerning everything from documentation to app usability in order to detect whether this problem occurs If a problem is detected it will be posted on the bug issue tracker where a team member will be delegated to fix the problem Another major risk is the failing to provide and update information instantaneously The likelinood of this occurring is high because many group members have not worked with networking before Furthermore a bug may occur if the device using the app fails to connect to the Internet in the time between when the user submits their data and the time it reaches the server The impact of this risk may also range from low to high depending on how often the failure occurs We know these estimates are true because in an earlier group meeting we proposed an idea of how to handle the networking but then discovered many possible places where a bug may be introduced within our plan In order to reduce the likelihood of this risk a few group members will be required to read guides on networking and we thoroughly discussed how we plan to approach this problem in our group meeting We have also decided to try to run network operations on a separate thread from the user interface as recommended by the Android development guide In order to discover potential bugs the testing team will develop black box tests that attempt to create and retrieve information when there is no Internet connection or the Internet
5. connection breaks down in the middle of the app To mitigate this risk we plan to test for networking bugs early so that we have time to find a solution for the bug Implementing the software as an Android app is another major risk since most group members have no experience with Android development or SQL Therefore there is a high possibility that the software may fail to work due to lack of knowledge about how to implement the app This would highly impact the project if it occurs For this all members have already done an Android tutorial and will be required to read guides on Android development If this problem occurs it will be very apparent so we should not need to do anything additional to detect the problem To mitigate the impact of this risk we may need to end up simplifying the interface or functionality of our app Most members have also not used the external software and libraries before so there is also a high possibility that the software may fail to work due to not knowing how to use the external software For example we have considered using external software to manage login information to make our database more secure The impact of failing this software is medium because there are many alternative software products that implement this functionality However our database may be at risk to SQL injection or other unsavory practices In order to reduce this risk a few group members will be delegate
6. has extensive knowledge of the system it would help to have someone else chime in on the ease of use of our application These interactions with potential users would need to happen at least once after we come up with a complete GUI To be sure that our testing is adequate we will enforce strict testing protocols for each team to minimize bugs and ensure system reliability such as testing before pushing and adding regression tests Teams will be required to write detailed JavaDoc comments before pushes to ensure ease of testing Finally we will use GitLab s issue tracker to track bugs and delegate fixing responsibilities Documentation Plan When users set up new accounts we will provide a user s guide integrated in the user interface demonstrating how to use the app As for external documents we will write out an online user manual consisting of two sections The beginner section will include basic functionality while the advanced section will include descriptions of additional features Moreover we could also create a promotional video to serve as a user guide and an advertisement if there is remaining time Coding Style Guidelines Since this app will be developed for the Android platform we have decided to use the Android s Code Style for Contributors located at URL http source android com source code style html as the coding style guideline for Java In order to enforce these guidelines members will be re
7. stores user information such as name gender year email and phone account information such as email and password and meal plan information such as all the meal plans created and their hosts food date time location attendees and description For account authentication we ll be using Amazon s Android SDK to connect to Amazon Web Services AWS Cognito Sync service and for the databases storing user and meal plan information we ll be using Java s JDBC library to talk to AWS RDS databases The schema is as follows o Account id name gender year email activated validationCode major o Attending planiD attendeelD o MealPlan planiD hostlD food location dateTime description Alternative Designs One alternative design for displaying the Meal plans feeds homepage user s current meal plans and user s account information was to have separate activities instead of one activity with fragment tabs However we chose to go with tabs to allow the user a more efficient quick way of maneuvering between frequent visited sections of the application o Pros of alternative It can potentially simplify the user interface because there would not be any tabs showing and it is easier to implement o Cons of alternative It usually does not allow the client to switch between different sections in one click o Pros of chosen design It helps the user switch from screen to screen in an efficient manner and gives them the freedom to choose
8. Write Ul Integration tests for creating meal plan joining meal plan amp deleting meal plan Michelle Implement AccountManager methods needed for account validation lan Implement AccountManager methods needed for forgotten password recovery Tad Write tests for forgotten passwords Kaleo Write tests for account verification 5 18 Alice Research and Jessica Design and Michelle Tad Write Feature implement how to implement the Implement the integration tests for Complete use Amazon SNS notification received necessary data push notifications Release services for push in the notification bar abstractions to Stretch notifications Thao Design the facilitate push Kaleo Write a Feature Josue color scheme and notifications system test that Push Setup necessary app icon for the app lan Implement simulates the Notification settings on AWS to any architectural usage of a user Services enable push design changes in during a session notifications order to promote 5 22 due modularity 5 25 Recovery week Fix any issues catch up 6 1 Alice Presentation Jessica Michelle Tad Presentation Prepare for Prep Presentation Prep Presentation Prep Prep Presentation Josue Presentation Thao Presentation lan Presentation Kaleo Prep Prep Prep Presentation Prep Team Structure Josue will be the project manager because he is the only one with Android development experience The roles of all m
9. a Release MealPlan System complete 5 8 due 5 11 Stretch Feature Implement account verification and forgot password validation Alice Implement Account login signup methods in DBManager Josue Setup the AWS instances databases needed Alice Implement insert and remove for DBManager Josue Setup tables in database and implement query Alice Implement DBManager methods needed for verifying accounts and validating forgotten password codes Josue Setup the any necessary tools to complete the back end for the feature Back End Alice and Front End Jessica Josue and Thao Jessica Implement MainActivity amp MyAccountFragment Thao Implement LoginActivity amp SignUpActivity Jessica Implement MyPlansFragment amp HomeFragment Thao Implement CreatePlanActivity amp PlaninfoActivity Jessica Design and implement the user interface for account verification Thao Design and implement the user interface for forgotten password codes Integration lan Testing Kaleo and Michelle and Tad Tad Write black box tests for Account and AccountManager Kaleo Write Ul Integration tests for signing up logging in amp logging out Michelle Implement Account lan Implement core AccountManager methods Michelle Implement MealPlan lan Implement core MealPlanManager methods Tad Write black box tests for MealPlan and MealPlanManager Kaleo
10. ctivity o Listens to see if the user wants to join an exisiting meal plan It notifies the MealPlanManager to carry out the appropriate work to join the meal plan SigninActivity o Listens to see if the user needs to sign in It notifies the AccountManager to verify any information to allow the user to sign in to their account with all their information and MealPlans SignUpActivity Data o Listens to see if the user does not have an existing account and notifies the AccountManager to create a new Account that interacts with the DatabaseManager to add the new information to the application ManageAccountFragment o Listens to see if the user wants to update any of their information and notifies the AccountManager to carry out the respective events HomeFragment o Listens to the interaction of user and the Home Page of the application to allow different views to appear This notifies the UI to switch tabs when necessary and the DatabaseManager to retrieve the appropriate data to be displayed to the user MyMealFragment o Displays all the lists of meal plans that user is hosting or joining o Listens to add meal plan button to start CreateMealPlanActivity SettingsActivity Extra feature o Listens to see if the user decides to change update the settings HelpActivity Extra feature o Listens to see if the user clicks on a help button that will display information about the application to the user Our system
11. d to do related tutorials for the external software The testing team will run black box tests to check whether the functionality of the external software works but we will not be able to detect any internal bugs within the external software If external software fails for login we can attempt to implement our own login database using SQL Another risk which was slightly mentioned in the previous one is the possibility that our database and network will not be secure The likelinood of this occurring is very high because our group members have limited knowledge about security The impact of this is low regarding to the completion of this project since an unsecure app still works but would have an extremely high impact if this software becomes available to the public In order to reduce the likelihood of this occurring a few group members will be required to read guides on security We will not be able to detect whether this problem occurs but we will Know that it is always likely that our database and network are not very secure In order to mitigate this risk we will try use reputable external software for private account information and hope that people who created them have a strong knowledge in security We will also limit user input by preventing them from using symbols that may cause SQL injections Project Schedule Week Group goals 4 27 Zero feature release Login System complete 5 1 due 5 4 Bet
12. embers are to work on their assigned weekly tasks in pairs and collectively contribute to the group assignments The weekly tasks are divided into four teams Front End o Members Jessica and Thao o Responsibility Designing and implementing user interfaces and interaction activities e Back End o Members Alice and Josue o Responsibility Setting up managing and connecting to the AWS Cognito service and RDS database service e ntegration o Members Michelle and lan o Responsibility Providing data abstractions needed to promote modularity and facilitating communication between the front end and back end e Testing o Members Tad and Kaleo o Responsibility Writing black box tests to ensure proper documentation integration U tests to ensure functionality and system tests to ensure system behavior Group meetings will be held every Tuesday 9 30 10 30 and Friday 3 30 4 30 to coordinate efforts and resolve issues The main outline of the weekly status reports will be discussed on Tuesday meetings where one member of the group will be delegated with the responsibility of compiling the report The final report will be uploaded into the GitLab project repository for final inspection before being turned in Our main method of communication outside of the weekly meetings will be through the Telegram app Google docs and Gitlab which allow group discussions issue tracking and status reports Test Plan We will be us
13. ing unit testing to test each class as it s written The authors of each class will write white box tests for that class In addition the testing team will be writing weekly black box unit tests for the classes to ensure that they follow the specs All of our tests will be run with continuous integration to detect integration errors as they appear We will be using Cruise Control to run builds that run as members and parts of the system To test the system and its integration the testing group will come up with black box tests involving multiple classes as they would interact in our system For instance we will need to test that network failures provide a dialogue with a helpful error message We will also need to test that general use cases work as expected such as login logout and creating deleting joining meal plans Some of these tests will need to be simulated programmatically such as network failures The system will also be tested by using the MeetAGenius application on a Genymotion emulator on screens of varying sizes as well as physical mobile devices This makes sure that the UI is integrated correctly and all buttons and interactions seem to do what they are supposed to The system testing will be done every week during meetings and written by the testing team between meetings To test how intuitive our interface is and the simplicity of our program we will ask people to try out our Ul and see what they say Since the team
14. quired to read the guideline and adhere by them Each week we will have everyone briefly look at each other s code to ensure coding style is consistent with the guidelines Before turning in the project there will be a group meeting to review the entire project for proper coding style
15. which screen they want to look at o Cons of chosen design More difficult to implement Another alternative design was to store and query all information from the database when needed from whatever class The design we chose was to store in memory account information and query information providing a refresh action to reload data up to date o Proof alternative this would reduce coupling between classes and whatever the query returns will be up to date o Con of alternative Expensive and slower to receive information Needs to load dynamically from database server Pro of chosen design easy and fast access to information Con of chosen design More dependencies Chance of returning out of date information Assumptions e User has internet connection for application to function properly e User will need to have an account to be able to use the application e User must have UW CSE netID Diagrams UML Class Diagram contains contains HomeFragment N S name String T T MeaRian 4 N X email Strin plan D long id long s hostID long a u AA year String hostName String MealPlanManager AccountManager gender boolean time Date account Gd long pane String anal STING foecteod string pnenlBnstslene string boolean a gender char year int dascription string getHostedBy userID long List lt MealPlan gt z 3 J 5 k EACT T TIT aosan account hostID
Download Pdf Manuals
Related Search