Description
For this assignment you will build a single-user photo application that allows storage and management of photos in
one or more albums.
All user interaction must be implemented in Java FX, and all UIs–except for standard Java FX dialogs such as
Alert and TextInputDialog–must be designed in FXML.
You may use multiple stages to show complex secondary windows, and switch multiple scenes within a stage.
You will continue working with your partner. Read the DCS Academic Integrity Policy for Programmming
Assignments – you are responsible for this.
Contents
1. Features
2. Model
3. GUI Storyboard
4. Complete Implementation
5. Bitbucket Contents
6. Grading
7. FAQs
Features
Your application must implement the following features:
Date of photo
Since we won’t examine the contents of a photo file to get the date the photo was taken, we will instead use the
last modification date of the photo file (as provided via the Java API to the filesystem) as a proxy. (The user
interface will still refer to this as the date the photo was taken.)
To store and manipulate dates and times, you have two options:
You can use a java.util.Calendar instance.
In which case, when you set a date and time on an instance, also make sure you set milliseconds to zero,
as in cal.set(Calendar.MILLISECOND,0), otherwise your equality checks won’t work correctly.
Alternatively, you may use the classes in the java.time package.
Tags
Photos can be tagged with pretty much any attribute you think is useful to search on, or group by. Examples are
location where photo was taken, and names of people in a photo, so you can search for photos by location and/or
10/29/21, 3:36 PM CS213 Fall 2020: Photos
https://www.cs.rutgers.edu/courses/213/classes/fall_2021_venugopal/photos/photos.html 2/7
names.
From the implementation point of view, it may be useful to think of a tag as a combination of tag name and tag
value, e.g. (“location”,”New Brunswick”), or (“person”,”susan”). A photo may have multiple tags (name+value
pairs), but no two tags for the same photo will have the same name and value combination.
Additional details:
You can set up some tag types beforehand for the user to pick from (e.g. location)
Depending on the tag type, a user can either have a single value for it, or multiple values (e.g. for any photo,
location can only have one value, but if there’s a person tag, that can have multiple values, one per person
that appears in the photo)
A user can define their own tag type and add it to the list (so from that point on, that tag type will show up in
the preset list of types the user can choose from)
Location of Photos – Stock photos and User photos
There are two sets of photos, stock photos that come pre-loaded with the application, and user photos that are
loaded/imported by a user when they run the application.
Stock photos are photos that you will keep in the application’s workspace. You must have no fewer than 5
stock photos, and no more than 10.
Create a special username called “stock” (no password, or password=”stock”) and store the stock photos
under this user, in an album named “stock”.
Leave the photos in the application’s workspace so the graders can test your application starting with your
stock photos, then load other photos from their computer, see “User photos” below.
Try to work with low/medium resolution pictures for the stock photos because they will be on Bitbucket and
downloaded by the graders, and you don’t want to bloat your project size.
User photos are photos that your application can allow a user to load from their computer, so they can be
housed anywhere on the user’s machine. The actual photos must NOT be in your application’s workspace.
Instead, your application should only store the location of the photo on the user’s machine. User photo
information must NOT be in the released project in Bitbucket since each installation of your application on a
machine will have its own set of users.
Login
When the application starts, a user logs in with username. Password implementation is optional. It makes
for a “real” scenario, but is irrelevant to the essence of the project. (There is no credit for the password
feature, if you choose to implement it.)
Admin Subsystem
There must be a special username admin that will put the application in an administration sub-system. The
admin user can then do any of the following:
List users
Create a new user
Delete an existing user
Note: If you elect to implement passwords for users, make “admin” the password for the admin user, so it’s
easier to grade. Otherwise we will need to ask you, or look in some README file, etc, which just turns out to
be a needless hassle.
Non-admin User Subsystem
Once the user logs in successfully, all albums and photo information for this user from a previous session (if
any) are loaded from disk.
Initially, all the albums belonging to the user should be displayed. For each album, its name, the number of
photos in it, and the range of dates (earliest and latest date) on which photos were taken must be displayed.
10/29/21, 3:36 PM CS213 Fall 2020: Photos
https://www.cs.rutgers.edu/courses/213/classes/fall_2021_venugopal/photos/photos.html 3/7
Use your discretion on how to show this additional information.
The user can then do the following:
Create albums
Delete albums
Rename albums
Open an album. Opening an album displays all photos, with their thumbnail images and captions,
inside that album. Once an album is open the user can do the following:
Add a photo
Remove a photo
Caption/recaption a photo
Display a photo in a separate display area. The photo display should also show its caption, its
date-time of capture (see Date of photo below), and all its tags (see Tags below).
Add a tag to a photo
Delete a tag from a photo
Copy a photo from one album to another (multiple albums may have copies of the same photo)
Note: If a photo is in multiple albums, it is the same physical photo, just refereneced/contained
in multiple albums. This means any changes you make to the photo (caption, tags) will be
reflected in all the albums in which the photo appears.
Move a photo from one album (source) to another (the photo will be removed from the source
album)
Go through photos in an album in sequence forward or backward, one at a time, with user
interaction (manual slideshow)
Search for photos (Photos that match the search criteria should be displayed in a similar way to how
photos in an album are displayed). Under this, you should provide the following specific features:
1. Search for photos by a date range.
2. Search for photos by tag type-value pairs. The following types of tag-based searches should be
implemented:
A single tag-value pair, e.g person=sesh
Conjunctive combination of two tag-value pairs, e.g. person=sesh AND location=prague
Disjunctive combination of two tag-value pairs, e.g. person=sesh OR location=prague
For conjunctions and disjunctions, if a tag can have multiple values for a photo, it can
appear on both arms of the conjunction/disjunction, e.g. person=andre OR
person=maya, person=andre AND person=maya
You are NOT required to do conjunctions/disjunctions on more than two tag-values pairs.
In other words, you are not required to do stuff like t1=v1 and t2=v3 and t3=v3
There should be functionality to create an album containing the search results.
As mentioned earlier (under Copy a photo from one album to another), a photo can be in multiple
albums. Creating an album out of search results means copying these photos to a new album, without
deleting them from the current album(s) to which they belong.
Note: A single user may not have duplicate album names, but an album name may be (coincidentally)
duplicated across users.
Logout
The user (whether admin or non-admin) logs out at the end of the session. All updates made by the user are
saved to disk.
After a user logs out, the application is still running, allowing another user to log in.
Quit Application
There should be a way for the user to quit the application safely at any time, bypassing the logout step.
Safely means that all updates that were made in the application in the user’s session are saved on disk.
Unlike logout, the application stops running. The next user that wants to use the application will need to
restart it.
Errors
10/29/21, 3:36 PM CS213 Fall 2020: Photos
https://www.cs.rutgers.edu/courses/213/classes/fall_2021_venugopal/photos/photos.html 4/7
In the application all errors and exceptions should be handled gracefully within the GUI setup. The text
console should NOT be used at all: not to report any error, not to read input, not to print output.
Model
The model should include all data objects, plus code to store and retrieve photos for a user. The collection of
classes that comprise the model should be in its own package, separate from the view and controller.
You are required to use the java.io.Serializable interface, and the
java.io.ObjectOutputStream/java.io.ObjectInputStream classes to store and retrieve data.
See Notes on Serialization and Versioning to know how to implement serialization and deserialization.
Note that your application will need to store content for multiple users, so it would be a good idea to separate
different user’s contents from each other.
You need to think about what objects you want to have in your design, with what attributes and operations. It is
important to plan this out and come up with a good object-oriented design that clearly separates roles and
functions between objects, and can be cleanly extended to add more features for future versions of the application.
GUI Storyboard
Your first task is to design the UI in the form of a storyboard.
The storyboard is a sequence of screen diagrams that shows all paths of flow through the interface. Here’s a
sample storyboard for a calculator application that gives you an idea of what you should do. This is an older
version built with Swing, so ignore the labels of the Swing widgets. Also, this is not a complete storyboard in that it
does not show all possible screens that are in the UI it describes, nor does it necessarily show all possible
transitions between screens. What it does show is how to draw screens, how to label screen components, how to
draw transitions between screens, and how to label transitions.
It is important to have one or more overview diagrams that show all screens and all transitions between them,
without any details of the components within the screens themselves. This is an overview that can give the
complete picture in one shot. The rest of the storyboard will then draw each screen in detail.
Each screen must be drawn using some drawing package. Or, you can even include screenshots off SceneBuilder
rendering of FXML UI layouts. But Screenshots that you take off a Java program WILL NOT be accepted. In other
words, there should be no Java code written at this stage at all.
Each screen will represent one window of your GUI and will contain all the widgets that go into that screen – text
fields, buttons, etc. Be as precise as you can about the selection and layout of the components in a screen. While
it is not necessary that you label each Java FX component you will use (as in the sample storyboard), it will help
you if you do because there is a smaller amount of design issues to worry about when you start coding the
application logic.
Each screen will show transitions to other screens and the events that trigger these transitions. When all is said
and done, you will have effectively drawn up a storyboard of your entire GUI that shows all screens and all interscreen transitions.
Note: The title for each screen should be descriptive of what the screen does. The sample storyboard says
“Calculator” for all titles, but for your storyboard, name every screen with an appropriate title. This can serve as the
title to be displayed in the titlebar when you implement these screens in code.
Grade Credit: Credit for the storyboard will be based on how well it anticipates (and determines) the
implementation of the GUI. This portion of the grade for your storyboard will be given after you finish the
implementation, and we can look at how useful your storyboard has been for your implementation. This means
your storyboard is not set in stone, as in you can make some changes to the UI when you build it because you
thought of some new/different elements. But the final result can’t be too different from the original storyboard,
which if it does, will imply that you didn’t think through the UI well enough to start with.
10/29/21, 3:36 PM CS213 Fall 2020: Photos
https://www.cs.rutgers.edu/courses/213/classes/fall_2021_venugopal/photos/photos.html 5/7
Complete Implementation
Code your application using the standard installation of Java, using for your GUI Java FX and FXML only (No
Swing). No external vendor libraries. We will test with standard Java so if you use any external packages, your
program will not run, and you will not get credit.
Document every class you implement with Javadoc tags, and be sure to include authorship.
Represent the object-oriented design of the entire application using a UML class diagram. This should include both
the classes you have built, as well as the Java FX classes. For the latter, just the class name will suffice–shade
the class box so it’s easy to visually separate the Java FX classes from yours. For each class built by your
application, show all public fields and methods in the UML representation.
Keep in mind that you will need classes that are not visually represented, but perform data-management functions,
as well as broker between the visual classes and the backend. These should be in your UML as well.
Finally, hand-drawn UML diagrams are NOT acceptable. You should use drawing software to do the UML. (Google
Slides is an easy option, but if you find a UML drawing app, feel free..) The end product should be a PDF file.
Bitbucket Contents
Your project should be named PhotosXX, where XX is your 2-digit group number.
The docs and data directories mentioned below should be created directly under the project, NOT under src or
under any of the packages.
By Sunday, Oct 24, 11 PM
GUI Storyboard: The final form of your storyboard should be a PDF file called storyboard.pdf, which should be
placed in the docs directory.
By Wednesday, Nov 17, 11 PM
Complete code: There should be one class called Photos that should have the main method, so it can be
launched as an application.
UML: The complete UML class diagram should be a PDF file called uml.pdf, placed in the docs directory.
Javadocs: The complete Javadoc HTML documentation should be generated and placed in the docs
directory.
Stock Photos: For the stock username. These should be in the data directory.
Grading
Your project will be graded on the following, for 225 points:
Category Points
UI Design – Storyboard (Completeness) 20
Object Design – UML (Separation of functionality,
proper relationships between objects, extensibility) 15
Features 190
Total 225
Penalties (up to 25 points total) will be assessed on the following:
Did not commit storyboard by Oct 24 11 PM.
Not using FXML adequately/appropriately to design the UI
10/29/21, 3:36 PM CS213 Fall 2020: Photos
https://www.cs.rutgers.edu/courses/213/classes/fall_2021_venugopal/photos/photos.html 6/7
Inadequate Javadoc tags/Javadoc HTML documentation not generated
Project structure does not properly separate model, view, control classes with appropriate package
configuration
Lacks scalability i.e. doesn’t display large amounts of data (e.g. many tens of photos or more) in a easily
navigable way
Lateness penalties (separate from penalties above):
10 pts: Every time you ask us and we test another commit version in your repository that is earlier than the
last commit before the deadline.
10 pts: For every 2 hours of lateness, in case there is nothing in the repository for us to test as of the
deadline of Nov 17, 11 PM.
NOTE: This 2 hour block will be applied STRICTLY starting any time after 11 PM (even if it is one second),
in increments of 2 hours. NO EXCEPTIONS.
Frequently Asked Questions
Q: Can we draw the storyboard by hand on paper, then submit a picture?
A: No. It should be drawn on using software – we are aiming for a professional look!
Q: Are search criteria disjoint, user can search photo for EITHER date range or tag type-value pairs or can they
search for a tag type-value pair within a certain date range?
A: Date range and tag-value pairs are disjoint for searches. So either date range or tag-value pairs, but not
together.
Q: What photo formats are allowed?
A: BMP, GIF, JPEG, PNG. See https://www.tutorialspoint.com/how-to-display-an-image-in-javafx
Q: Do we need to show standard dialogs (Alert, TextInputDialog) in our storyboard?
A: You need not show error/confirmation dialogs. But you must show any dialog that is getting user input, whether
it is a standard dialog (boilerplate JavaFX), or a dialog you designed with FXML.
Q: Should we preserve the aspect ratio of the image the user views?
A: Not a requirement (i.e. you won’t lose credit if you don’t), but preserving the aspect ratio is encouraged.
Q: Does admin also have albums and everything else, like non-admin user? Or just edit/create/delete user?
A: No. admin can only create/delete user, and list all users.
Q: If we have two tags like “person”: “Alice” and “person”: “Bob”. Should we store them in two different tags? Or
we should do it in a single tag “person”:”Alice; Bob”? Or both are fine?
A: You should store them in two different tags, one per person.
Q: Do we need to display photos/users/albums in sorted order?
A: No.
Q: Is a user allowed to have duplicates of the same picture in the same album?
A: No.
Q: Can a user edit the date of a photo?
A: No. The date of the photo is basically the date of the photo file, it can’t be modified in the app
Q: If you have already added a photo to one album, can you add it to another album (via importing the photo
again) not copying or moving the photo?
A: Yes. But it is equivalent to copying. And be sure to read the note in the assignment description (in red) on
copying a photo from one album to another since the same rules apply in this situation.
Q: Are we allowed to have duplicate users?
A: No.
Q: Can there be photos that are not in an album?
A: No, every photo must be in at least one album.
10/29/21, 3:36 PM CS213 Fall 2020: Photos
https://www.cs.rutgers.edu/courses/213/classes/fall_2021_venugopal/photos/photos.html 7/7
Q: When we delete an album are we also deleting all references to the photos that were in the now deleted
album?
A: When you delete an album, all the references to photos from that album will be deleted. But if a photo is in a
different album as well, that album will still refer to the photo.
Q: Should the fields for JavaFX components in our classes need to be shown in the UML diagram?
A: No, you don’t need to include FX fields.
Q: Should we include FX controller classes in the UML?
A: Yes, because they contain logic that verifies user input, and to communicate data to the non-UI logic in the app.
Q: Should stock be auto-generated every time the program is run, in case admin deletes the “stock” user?
A: No, you don’t need to have functionality to recreate stock if deleted.
