案例java2 The design for this phase (Phase 2) will be an in-class exercise. The class will discuss, and coalesce around, a single design.

CSE 216: Software Engineering Programming project #2
Instructor: Prof. Liang Cheng Assigned: 9/25/18

TA/Project Mentor: Dylan Gray, Connor Deppert, Kelli Frank, Charles Inwald, Alex Schuler

All Tasks Due: 10/12/18


Problem Statement

Well, that escalated quickly. The CTO saw your web app and said “I want that.” He insisted that you launch it immediately, but you managed to buy enough time to go from “prototype” to “barely adequate.”
On the bright side, while he said you only had two weeks before you went live, he accepted your advice to add features incrementally. But at the very least, it’s going to be important to add authentication and a comment system.
It’s going to be important to move quickly. But more importantly, you need to make sure that each step is done right… this project is going to get bigger and bigger, and any technical debt you accrue now is going to cost a lot to pay off later on down the road.




Design

The design for this phase (Phase 2) will be an in-class exercise. The class will discuss, and coalesce around, a single design.



Reminder

Each student should be in a different role than the one during Phase 1. Be careful with how you assign roles: each student should have a turn in each role before the end of the semester.



Deliverables The Back End
In the in-class design, we crafted a policy for secure user names and passwords. This is going to change the entire data model. We will no longer have anonymous browsing of the messages on “The Buzz.” Users must be logged in to view posts, up-vote, down-vote, and have the ability to leave comments. Note that comments won’t be nested.
User account support will be achieved by allowing users to enter their email. Accounts will be authenticated through the administrative interface, which will now have the ability to send an activation email to the user. That email should contain the initial secure password, and users must be able to change their passwords. We will use a hash/salt strategy for passwords, as discussed in class.
Also, as discussed in class, the server must employ a local cache (implemented as a hash table) to store user login state. This can be done using a login token. Each request to the server (other than logging in or registering) should contain this token and the ID of the user performing the request. The login cache will be a simple key/value pair that maps login tokens to user IDs. If the token that maps to a user ID equals the user ID of the request, then the user performing the request is authenticated. In this way, logging in from one device will cause a user to be logged out from all other devices. Remember that Spark is a multithreaded server. Some concurrency control will be necessary.
Regarding votes, we will provide votes as a state machine. Initially, a user has a neutral vote. Clicking up- vote or down-vote will act as expected. However, up-voting a post that the user has already up-voted, or
down-voting a post that the user has already down-voted, will result in no change. Down-voting a previously up-voted post, or up-voting a previously down-voted post, will replace the previous vote. You must think carefully about how to do this in SQL.
Votes must be secure. It should not be possible for a user to dissect the JSON and see who has up-voted or down-voted a post. However, you might choose to allow a user to see which posts she up- or down- voted.


The Admin App

The main addition to the admin app in this phase is the need to have manual activation of accounts. You should use SendGrid [1] to send activation emails. Of course, you will also need to have a way to manage the new tables in your database. It is probably a good idea to use “views” to simplify the back-end developer’s job. Once you have those tasks done, it will be your responsibility to help the project manager to keep everything on track, by pair programming with your teammates.



The Project Manager

The project manager should coordinate among the programmers, so that they all implement the same algorithm for authentication. The project manager should also make sure that the security information related to the email system in the admin app is managed in the same way as all other security information (e.g., Heroku configuration).
In addition, the Project Manager is still responsible for integrating each member’s code into the main branch, performing code reviews, and documentation. Remember: tests are important, and should not be delayed. Finding bugs early is much better than finding them late!
In addition to the database and routes, you should also create documentation for the user interface for your app. The UI should be as similar as possible for the web and Android versions. Be sure to document the flows related to authentication.


The Android App

Your app should support all of the above features of the server, to include displaying comments for messages, handling login/logout, registering, and up/down votes. You should use multiple activities, as appropriate. Note that you will be modifying and adapting code that your team member wrote in a previous phase. If your team member adhered to good standards, you should follow suit. If not, you should refactor the older code to match the quality of the code you write.
You should make sure to design a good flow for handling authentication. In particular, you can expect that the user can be logged out at any time, due to another login attempt from another device. If there is a network error, you should gracefully report it, too. The android developer documentation includes information on requesting JSON from via Volley [2]. It will help.
Note: To keep a user logged in, you should use SharedPreferences to store session state. Also, be sure to continue to use Espresso [3] to test the Android app.




The Web Developer

As with the Android app, the web developer needs to start by getting the web front end caught up with thenew design. You’ll need to have a login page, up-votes, down-votes, and comments, using the new JSON formats and new REST routes. In addition, you are going to add a profile page, which will show the user name, user email, and a comment about the user.

========================================================

The password and comment should be editable (which means more REST routes… be sure to coordinate with the back-end developer). Clicking on the name of a person who posts a message, or who makes a comment, should take you to their profile page. And, of course, you should be able to get to your profile page from the Bootstrap navbar at the top of the page.



Mentorship

Each team will have one TA/PA assigned as a mentor, and that TA/PA will meet with students once per week, both to mentor the team and to assess its performance. Teams should take advantage of this opportunity, especially when it comes to teamwork, priorities, and technical obstacles.



Turn-in Instructions

We will make a copy of your team’s repository at some point on or after the due date. Be sure to commit and push your solution prior to the due date by branching from master into a new branch called “phase2”.


Acknowledgments

The creation and updates of this project were funded in part by the Kern Entrepreneurial Engineering Network [4]. We thank Professor Michael Spear and the Kern Family Foundation for making this project possible, and we encourage our students to emphasize the “Three C’s” in all aspects of this project.



References

Email Delivery Service: SendGrid, 2018.https://sendgrid.com/.
Google, Inc. Making a Standard Request, 2018. https://developer.android.com/training/volley/request.html#request-json.
Google, Inc. Espresso, 2018.https://developer.android.com/training/testing/espresso/.
TheKern Family  KEEN-Engineering Unleashed, 2018. http://engineeringunleashed.com.