案例java | CSE 216: Software Engineering Programmi
当前位置:以往案例 > >案例java | CSE 216: Software Engineering Programmi
2020-01-08

案例java Each of the four programmers (web, back end, android, admin) should work in a separate branch, and the project manager will merge each branch into the main branch only after completing a code review (see below).

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

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

All Tasks Due: 9/24/18

案例java
Problem Statement

Your initial experiments went well, and you’ve given your response to management. You’re all in. Now it’s time to forge a team and start designing and building software.
You decide to use an agile process. Along with four like-minded coworkers, you decide to allot two weeks for your first sprint. Remember: time is of the essence, because the company needs a secure place for professional social interaction.
Employees from across the globe want to be able to share ideas, vote on proposals, and make sure NakedMoleRat is a success. At the end of the sprint, you plan to actively engage employees as users of the system, so that you can refine your design and flesh out more details in preparation for future sprints.
The goal is to start small… a cloud-hosted web system, plus an Android app, so that employees can post short messages, and other employees can up-vote and down-vote. But you know this is going to get big… real big… so it would be good to do things right the first time, and anticipate the growing pains that you’re sure to encounter once everyone realizes that you’ve invented the next big thing.
The excitement is palpable. There’s so much energy on the team, it feels like the room is buzzing with excitement. To kick off the project, you suggest a name… “let’s call our new social app ’The Buzz’…”


Deliverables

This project will be collected by checking out your team’s git repository, so be sure to check in your code often, and to follow the rules for the project. In particular, your team should obey the rules about who works on which parts of the project. You should be trying to work as an effective team, not just trying to finish each task.

To that end, there should be a master branch, which is only updated four times during this phase of the project. Each of the four programmers (web, back end, android, admin) should work in a separate branch, and the project manager will merge each branch into the main branch only after completing a code review (see below).



The Project Manager

First and foremost, the project manager must launch the phase 1 backend code onto Heroku. Heroku provides free HTTPS, free database (albeit only a small amount), and up to 700 hours of server time per month for free. Plus, it’s a Platform as a Service, so there’s no server maintenance or security upgrades.
Normally, the program manager wouldn’t be taking on a job like this, but it’s got to get done, and everyone else is going to be racing to get their parts of the project in order.
The project manager will need to figure out how to deploy the server to the Heroku. There’s a lot to the “Ops” side of “DevOps”, and exploring Heroku will help you to gain an appreciation for it. Tutorial 8 [1] only scratches the surface… be sure to document everything you learn, so that your teammates can take on this role in future phases of the project.
Note that this task needs to happen early, because it will affect everything that your teammates do.
You should also submit documentation for the user interface for your app. The UI should be as similar as possible for the web and Android versions.
The project manager, in consultation with the back end and web developers, should devise a strategy for how two programmers can build their components simultaneously, when they depend on each other. Note that it is possible to do most of the development of both components independently. However, some approaches have more redundancy and worse integration costs than others.
The project manager must also perform a code review of each team member’s code. The project manager should sit with the programmer, and review every line, checking for correctness, comments, etc. This cannot be done until after all tests pass, of course. It should end with the programmer’s branch being merged into the main code base, by the project manager.
The project manager is expected to use Trello to track the state of the project at all times, and to document the tasks that comprise this sprint.
The project manager will also be responsible for preparing a document (we will provide a template) that describes the state of the project. This will allow us to assess each team member’s contribution, and to assign grades accordingly.
Lastly, the project manager must ensure that the standards for documentation are being met. This will include, for example, ensuring that the source code results in proper JavaDocs, and that there is a README in the root of the repository that provides all of the necessary information to use “The Buzz”, as well as all information about its APIs.


The Back End

The student who assumes the role of Back-End Developer for this task will use the Java Spark Framework [2] to create a dynamic web server. Based on the design from class, the server will provide several “routes”, through which users can “POST” new messages by sending JSON, and “like” messages, again by sending JSON. The server will return a list of messages, along with a count of “likes”, as JSON. The server must return proper HTTP status codes.
The back-end programmer will be persisting the results of the HTTP requests to a PostgreSQL database. The server must read its configuration (at least the port on which to listen, and the reference to the database) from environment variables. Heroku will give you the variables you need for using  PostgreSQL.
The back end developer must also produce unit tests that are appropriate for ensuring the correctness of the back end. Remember: the back end will change in the next phase: things that shouldn’t break as the back end is extended should have tests that accompany them.
Note: If you have never used JSON before, you will need to learn its role. JSON is a standard used in all sorts of application domains. You should also be sure to understand the conventions in a REST API, and the differences between GET and POST.


The Android App

Once the server is online, the Android app can begin interacting with it. The app must show a list of messages, allow the user to create messages, and allow the user to “like” messages. Your app should be backward compatible to v21 (Android 5.0 Lollipop, SDK level 21). You are allowed to lock the screen in portrait mode. Be sure to use Volley [3] and RecyclerView [4].

The Android developer must also produce Espresso tests for both the logic and the UI of the Android app.


The Web Developer

Your team’s web developer will create a basic web application that performs GET and POST requests to the server, in order to show a list of messages, allow the creation of new messages, and allow a user to “like” messages. Just the Android app, the web app must be “live”, and interact directly with the back end. You should implement your program as a “single-page web app”, where the back end is as uncoupled from the web front end as possible. It is OK to rely on the back end for serving static content, but the only dynamic content it serves should be JSON, never HTML.
The Web Developer should work with the Project Manager to develop a reasonable workflow for building the web source (starting from the ideas behind “deploy.sh” in Phase 0). The process by which team members can deploy the web code must be straightforward and clean. The web front end sources should not be checked into the back-end’s folder hierarchy.
Note: the web front end should also use Handlebars [5] for templating, and Bootstrap [6] for styling. The Android and Web front-ends should be as similar as possible.
The web developer must also produce Jasmine tests for both the logic and the UI of the web front end.
The Admin App

There is not much work to be done on the admin app, but the work is important. You should make sure that a standalone Java program is able to drop tables from the database, recreate tables from the database, and do any other maintenance that needs to be done. And, of course, there should be unit tests.

In addition, the admin app developer should directly assist the other programmers in two ways. First, through peer programming, the admin app developer can sit with another teammate and provide over-the- shoulder advice. Second, while the admin app developer can’t check in code for teammates, the admin app developer can help teammates to develop a good testing strategy.


Tips for Success

There are a lot of steps to help you succeed. Start early. Design a solution together, as a team. Get the back-end onto Heroku as quickly as possible. Write tests before writing code. Communicate with each other.

Note: the project manager and admin app developer are “easier” roles, in terms of programming, but they have much more responsibility and authority. These teammates will be programmers in later phases. If the code is in a poor state, they will have to do more work to catch up. Thus it is in their best interest to help teammates to succeed. You will be graded individually, but if your teammate receives an F for this phase, it means you will have more work some time in the future.


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.



Tutorials

Every student should do tutorials #8, #9, and #10, in order to have the necessary background for



succeeding during the rest of the semester. However, it is especially important that the project manager does tutorial #8 early, and that the web developer does tutorial #10 early.



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 “phase1”.


Acknowledgments

The creation and updates of this project were funded in part by the Kern Entrepreneurial Engineering Network [1]. 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

Michael Lehigh University Software Engineering Tutorial Series, www.cse.lehigh.edu/~spear/cse216_tutorials/.
The Spark Team. Spark Framework – A tiny Java web framework, 2018.http://sparkjava.com/.
Google, Inc. Making a Standard Request, 2018. https://developer.android.com/training/volley/request.html#request-json.
Stack Overflow. Should We Use RecyclerView To Replace ListView, 2015. http://stackoverflow.com/questions/28392554/should-we-use-recyclerview-to-replace-listview.
js. Handlebars.js: Minimal Templating on Steroids, 2018.http://handlebarsjs.com/.
Twitter, Bootstrap – The world’s most popular mobile-first and responsive front-end framework, 2018. http://getbootstrap.com/.

在线提交订单