Software编程代做、代写c/c++，CSS，Python程序设计

日期：2021-05-13 11:04

Full Stack Development/Software Workshop 2

Assignment 2

Marks available: 50% of the module mark

Introduction

For this assignment you will add the final components to the database server that was created for Assignment

1 to create a full stack application. There is a completed version of Assignment 1 available for you

to download from Canvas. It has been enhanced from the version that you completed for Assignment 1 so

you should download the new version rather than using your own. The enhancements are described below,

where they are applicable.

There are two main components that you will build for Assignment 2. Since there are two people to each

group, it makes sense for each student to complete one of the components. This will be discussed in more

detail below.

The two components you must create are the client and the server for the Jabber platform. The client will

have a GUI developed using JavaFX and a controller. The server is a Java application that serves data to

clients from the database. The client and server are connected to each other via sockets on localhost. You

must use the port number that is specified below.

The client and server should be developed as two separate projects. Do not put the client

and server code in the same project. It must be possible to run both the client and the server

independently, i.e. not at the same time. Part of the testing of your submission will involve

connecting a separate client (developed by Ian, not yours) to your server and connecting

your client to a separate server (developed by Ian, not yours).

The next section of this document will specify the requirements for your application. You should try and

ensure that all of the functionality described is present.

There is no specified look or layout required of your GUI. You can design it to look however you want.

However, it must allow the functionality that is described below.

You must use the class JabberMessage and the protocol outlined below exactly as stated, and must use

localhost and port 44444 for the connection. Apart from those, you may name your classes, etc. however

you wish.

Make sure you have watched the final ‘wrap-up’ video before attempting this assignment.

The only person you can share your code with in any way at all is your other team member.

1

Requirements of the Jabber social media application

Your application should have the following functionality. Each GUI element that is referred to below has

been given a code such as T1, B1, etc. Note that as long as your GUI has the required functionality,

you don’t need to use these specific types of GUI controls. You can use any other GUI controls you want

provided they allow for the following functionality. The marks available for each correctly implemented

requirement are also shown.

 RQ1. Users should be able to sign in to the application by entering their username in a text field T1

and by pressing a button B1 marked ‘Sign In’ to send the username to the server. Once the user is

successfully signed in the GUI should somehow indicate this. [4 marks]

 RQ2. If the user enters an invalid username, i.e. a username that does not already exist in the

database, then the GUI should present an error dialog E1 advising the user that the username

is invalid. The error dialog should be closable allowing the user further attempts to enter their

username. [3 marks]

 RQ3. The user should be able to register for the application by entering their new username in the

text field T1 and by pressing a button B2 marked ‘Register’. The GUI should somehow indicate that

the user has successfully registered. The new user should be signed in by the server without the user

having to do this as a separate step. [4 marks]

 RQ4. The user should be able to sign out by pressing button B3 (which could be the same button

as B1). This should disconnect the user from the server and close the client application. [2 marks]

 RQ5. Once the user is signed in, the application should present that user’s timeline in pane P1.

This pane should have a header label saying ‘Timeline’. The format of each jab in the timeline

should be as shown below (it doesn’t need to actually look like this. It just needs to contain this

information). The ‘heart’ image you can see can look differently to that but some kind of image must

be present there. The ‘heart’ here is the ‘like’ button (see RQ6). Note that in the enhanced version

JabberDatabase on Canvas, there is a new method called getTimelineOfUserEx() which retrieves

all of the information you need for each jab, i.e. it returns the username of the user who posted the

jab, the jab text, and the number of likes that jab has in total. This method also returns the jabid

of each jab in the timeline but you should not display that. [7 marks]

Figure 1: This jab has so far received 2 likes.

 RQ6. The user should be able to click a button to ‘like’ a jab that is in their timeline. There is one

button B4a, B4b, ... for each jab. In the image above the button uses a ‘heart’ icon. If a user clicked

the heart button on the jab in figure 1 (and they have not already liked the jab1

), the number shown

next to the heart button should change to 3 because there is now one more ‘like’ of this jab. Users

can’t ‘unlike’ a jab. [4 marks]

1There is no need to check for this. The database will reject a second like by the same user of the same jab.

2

 RQ7. Once the user is signed in, the application should also present a list of registered users who

the signed-in user is not following in pane P2. This pane should have a header label saying ‘Who

to follow’. There is a new method in the JabberDatabase class for this: getUsersNotFollowed().

The format of each user in this list should be as shown below (again, it doesn’t literally need to look

like this). [7 marks]

 RQ8 Each line of the list of ‘who to follow’ in P2 has the username of the user that could be followed

and a button B5a, B5b, ... (shown here with a ‘+’ image), one for each user, that when clicked

makes the signed-in user follow the user listed. Once a user has been followed, their jabs should be

immediately (or very quickly) added to the timeline that is being displayed in P1. [5 marks]

Figure 2: Pressing the ‘+’ image (button) makes the signed-in user follow ‘kim’.

 RQ9. Users should be able to post their own jab. For this there should be a text field T2 in which

they enter the jab text and a button B6 that sends the jab to the server. Once posted the jab should

appear in the user’s timeline2

. [4 marks]

 RQ10. Each of the actions above must be reflected in the client of any affected users. For example,

if users A and B are signed in, and user A follows user B, when user B posts a new jab it must also

appear in the timeline of user A. This applies to all other operations. Where actions affect other

users they must be reflected in the client of those users3

. [10 marks]

Items to download from Canvas

Make sure you download all of the following files from Canvas.

 JabberDatabase.java. For Assignment 1, this file was called JabberServer.java. You should use

this new version. You should not need to change this file. You may do so if you wish but make sure

you don’t break it.

 JabberMessage.java. You must use this class in order to transfer data across the network. Note

that this class is supplied complete and does not need to be changed or added to. This class should

be used in the client and the server. You can simply put copies of this file in each of the two projects.

 The updated Jabber SQL files.

Implementation

The most important point to grasp in the first instance is that you and your partner must create two

separate applications: the client and the server. These two applications must be developed in separate

projects in your chosen IDE (Eclipse, IntelliJ, etc.).

2The SQL data has been updated since Assignment 1 to ensure that every user follows themselves.

3One relatively easy way of achieving this is to set a timer in the client that automatically gets the timeline and user data

every, say, one second.

3

The clients and the server will communicate with each other using sockets. The sockets must use the

address ‘localhost’ and port 44444 for the connection.

You should use the class JabberDatabase as your database class. This has all the methods you need to get

the data you need from the database. You may need to change the postgres password specified in the file for

your own system. It is best to create an instance of JabberDatabase for each separate client that connects.

To exchange messages between client and server, both client and server must use the class JabberMessage

that can be downloaded from Canvas (simply copy it into both projects). JabberMessage has a ‘message’

and ‘data’. The format of the messages required is specified in the section on the Jabber protocol below.

You must use the protocol exactly as stated. No other messages are required. Make sure you have read

and understood the final lecture (‘wrap up’ (under Week 11 on Canvas) before using this class).

You should use the Model-View-Controller pattern to implement your client. This means that your should

have a class for your GUI (which is the view) and another class for a controller. The GUI class should not

itself communicate directly with the server.

The server application should be threaded in such a way as to allow multiple clients to connect at the same

time. Again, make sure you have read and understood the final lecture under Week 11 on Canvas.

The Jabber client/server protocol

Your client and server must adhere to the following protocol. All strings must be used exactly as shown.

Note that once the user is signed in the client does not need to send the username for other requests. The

server will have established a connection to the client so will know which client the message is from.

 P1a. Signing in (successful).

– Client message: signin[space]username (the string ‘username’ should be the username that the

user entered in the GUI.)

– Server reply message: signedin

– Server reply data: NONE.

Example client message: “signin edballs”

Server reply (message): “signedin”

 P1b. Signing in (unsuccessful).

– Client message: signin[space]username (the string ‘username’ should be the username that the

user entered in the GUI.)

– Server reply message: unknown-user

– Server reply data: NONE.

Example client message: “signin blahblah” (a user not previously registered)

Server reply (message): “unknown-user”

 P2. Registering.

4

– Client message: register[space]username (the string ‘username’ should be the username that the

user entered in the GUI4

.)

– Server reply message: signedin

– Server reply data: NONE.

Example client message: “register todd” (a user not previously registered)

Server reply (message): “signedin”

 P3. Signing out.

– Client message: signout

– Server reply: the server does not reply to this request.

 P4. Getting the timeline

– Client message: timeline.

– Server reply message: timeline

– Server reply data: {username, jabtext, jabid, likes-count} (one row for each jab in the timeline)5

.

Example client message: “timeline”

Server reply (message): “timeline”

Example Server reply (data): [{“ted”,“excellent”, “56”, “3”}{“bill”, “dude”, “58”, “2”}]

 P5. Getting the users (who to follow)

– Client message: users

– Server reply message: users

– Server reply data: {username} (one row for each user who is not being followed by the user.)

Example client message: “users”

Server reply (message): “users”

Example Server reply (data): [{“todd”}{“wilma”}]

 P6. Posting a jab.

– Client message: post[space]jabtext (where ‘jabtext’ is the text of the jab.)

– Server reply message: posted

Example client message: “post my first jab”

Server reply (message): “posted”

4You can assume the username is unique. Note that there is no need to get an email address off the user. The server can

(unrealistically) invent one.

5Note that jabid is returned but is not displayed by the client.

5

 P7. Liking a jab.

– Client message: like[space]jabid (where ‘jabid’ is the id of the jab to like.6

)

– Server reply message: posted

Example client message: “like 14”

Server reply (message): “posted”

 P8. Following a user.

– Client message: follow[space]username (where ‘username’ is the user to follow.)

– Server reply message: posted

Example client message: “follow todd”

Server reply (message): “posted”

Working together

Because this project has two distinct parts, that are connected only by a predefined protocol, getting the

code of the two team members to work together should be straightforward. Provided your client and server

both understand the protocol above then they can work together.

One approach would be to work through the requirements in the order they are stated in. Get ‘signing

in’ working on both client and server together, before moving on to the other requirements. This will give

you a model to use for implementing the rest of the protocol. The only difference will be for some of the

requirements is that data must also be returned to the client.

In terms of sharing your code with each other, you should agree a naming system so that you can match

versions together so that you don’t get out of sync with each other. For example, in zip files named

clientRQ1 and serverRQ1 for the versions that both implement signing in (RQ1), and so on.

You will both need both projects in your IDE so that you can test your work as you go along, but you as

an individual will only be working on one of them. Your partner will have to send you their latest versions

of the files (via email) to put into the relevant project.

If you choose to use some sort of version control system, e.g. Github, you must set your repository to

private and grant access only to the two members. Failure to do this will result in a mark of zero for both

members of the group. You will also receive zero if any other public means of communication is used, or

if your files are uploaded to any third-party website that is public.

Submission

Each team member must submit all of the following in a single zip file.

 Your client project (all files including Eclipse/IntelliJ files).

 Your server project (all files including Eclipse/IntelliJ files).

6Remember, the jabid was returned by the server with the timeline.

6

 A text file (.txt format) containing the following information:

– The name and ID of the student who created the server. This is very important. If we don’t

know this, and something doesn’t work, both students will lose marks.

– The name and ID of the student who created the client. This is very important. If we don’t

know this, and something doesn’t work, both students will lose marks.

– The main class name in the server, i.e. the one we need to run.

– The main class name in the client, i.e. the one we need to run.

– Notes about anything we should be aware of when marking, special instructions, etc.

Marking

All students will receive a mark out of 50.

The marks for each fully functioning requirement are shown in the requirements section above. If your

application has the functionality described for a given requirement, and it works fully, both students will

get the marks shown for that requirement.

If your functionality for a given requirement is not correct then you may receive partial marks for that

requirement, depending on how far your functionality deviates from the required functionality.

If your functionality for a given requirement is not correct, we will try and ascertain if the problem is caused

by your client or server or both. If it is caused by only one of those, and we know which student created

each application (and there is no doubt about that) the marks will be awarded to the student whose functionality

is correct. The other student in the pair will get zero marks for that requirement. This is why it

is very important for us to know exactly who did what in each team. If we have any doubt over the authorship

of each application then both students will get the partial marks mentioned in the previous paragraph.

If the functionality for a requirement is missing then both students in the group will receive zero for that

requirement.

If one of your applications does not work at all, e.g. it doesn’t compile or can’t be started, or when started

does not function, then the student who created that application will receive a mark of zero for the whole

assignment. The other application will be tested using either the client or server created by Ian.

If one of your applications does not work but the other does, and we do not know exactly who created

which application, then both students will receive half of the marks that the working application would

have received.

If both of your applications do not work at all, e.g. it don’t compile or can’t be started, or when started

do not function, then both students in the group will get a mark of zero for the whole assignment.

7