Assignment 3 Photos

For this assignment you will build a photo application that allows storage and management of photos in one or more
albums.
You will work in pairs on this assignment. Read the DCS Academic Integrity Policy for Programmming Assignments -
you are responsible for this. In paäicular, note that "All Violations of the Academic Integrity Policy will be repoäed by
the instructor to the appropriate Dean".
In this assignment, you will design and implement a single-user photo application, with all user interaction implemented
in Java FX, and all UIs--except for standard Java FX dialogs such as Aleä and TextInputDialog--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 paäner.
Contents
1. Features
2. Model
3. GUI Storyboard
4. Work Split Document
5. Complete Implementation
6. Bitbucket Contents
7. Grading
Features
Your application must implement the following features:
Login
When the application staäs, 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.
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 Ûle, 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. 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 datetime 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)
Move a photo from one album (source) to another (the photo will be removed from the source
album
Go through photos in 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 speciÛc features:
1. Search for photos by a date range.
2. Search for photos by tag type-value pairs.
Note: searching on multiple tag-value pairs should be suppoäed, e.g. search for all photos with
person=sesh and location=london.
There should be functionality to create an album containing the search results.
As mentioned earlier (under Copy a photo from one albim to another), a photo can be in multiple albums.
Creating an album out of search results means adding 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 the name may be 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.
Aßer 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 restaä it.
Errors
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 repoä any error, not to read input, not to print output.
Date of photo
Since we won't examine the contents of a photo Ûle to get the date the photo was taken, we will instead use the last
modiÛcation date of the photo Ûle (as provided via the Java API to the Ûlesystem) as a proxy. (The user inteãace will still
refer to this as the date the photo was taken.)
You may want to use a java.util.Calendar instance for the date and time the photo was taken. Note: When you set a date
and time in a Calendar instance, also make sure you set milliseconds to zero, as in:
cal.set(Calendar.MILLISECOND,0);
Otherwise your equality checks won't work correctly.
Tags
Photos can be tagged with preây much any aâribute you think is useful to search on, or group by. Examples are location
where photo was taken, so you can search for photos by location, and names of people in a photo.
From the implementation point of view, it may be useful to think of a tag is 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 will have the same name and value.
Location of Photos
There are two sets of photos, stock photos that come pre-loaded with the application, and user photos that are
loaded/impoäed by a user when they run the application.
Stock photos are photos that you will keep in the application's workspace. Limit them to 10. Create a special username
called "stock" (no password, or password="stock") and store the stock photos under this user. Leave the photos in the
application's workspace so the graders can test your application staäing with your stock photos, then load other photos
from their computer, see below. You can have all stock photos in a single album, or break them into multiple albums, it's
up to you. 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. Make sure that your application will work
correctly even if there are no stock photos to staä with.
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.
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 inteãace, and the
java.io.ObjectOutputStream/java.io.ObjectInputStream classes to store and retrieve data.
Note that your application will need to store content for multiple users, so it would be a good idea to separate diáerent
user's contents from each other.
You need to think about what objects you want to have in your design, with what aâributes and operations. It is
impoäant 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 Ûrst 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 Üow through the inteãace. 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 impoäant 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 oá SceneBuilder
rendering of FXML UI layouts. But Screenshots that you take oá a Java program WILL NOT be accepted. In other words,
there should be no Java code wriâen 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 Ûelds,
buâons, 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 staä 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 eáectively drawn up a storyboard of your entire GUI that shows all screens and all inter-screen
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 poäion of the grade for your storyboard will be given aßer you Ûnish 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/diáerent elements. But the
Ûnal result can't be too diáerent from the original storyboard, which if it does, will imply that you didn't think through the
UI well enough to staä with.
Work Split Document
When you have Ûnished designing the storyboard, you need to decide how to split the work of implementing all the
windows. Implementing a window will also include all non-visual aspects associated with it, all event handling, the
connections to the other paäs of the GUI, and the connections to the control and model. The work split must be as
equal as you can make it.
Type up the work split documentation (plain text or PDF, no other format will be accepted). Make a table with two
columns: in one column list the name of the window to be implemented, and in the second, the team member who will
implement it.
Complete Implementation
Code your application using the standard installation of Java 8, using for your GUI Java FX 8 and FXML only (No Swing).
No external vendor libraries. We will test with the standard Java 8 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 laâer, just the class name will suÞce--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
Ûelds and methods in the UML representation.
Keep in mind that you will need classes that are not visually represented, but peãorm data-management functions, as
well as broker between the visual classes and the backend. These should be in your UML as well.
Bitbucket Contents
Your project should be named PhotosXX, where XX is your 2-digit group number.
By Sunday, March 12, 11 PM
(The docs and data directories mentioned below should be created directly under the project, NOT under src or under
any of the packages).
GUI Storyboard: The Ûnal form of your storyboard should be a PDF Ûle called storyboard.pdf, which should be
placed in the docs directory. This should be commiâed by ONE paäner ONLY.
Work Split Document: The Ûnal form of this document should be a plain text (.txt) or PDF Ûle, called worksplit.txt
or worksplit.pdf, and must be in the docs directory. This should be commiâed by the OTHER paäner ONLY.
By Wednesday, April 12, 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 Ûle 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.
Grading
Your project will be graded on the following, for 200 points:
Category Points
UI Design ‐ Storyboard (Completeness) 20
Object Design ‐ UML (Separation of functionality, 15
proper relationships between objects, extensibility)
Features (including robustness) 190
Total 225
EXTRA CREDIT:
(Up to 15 points) for exceptional features. We don't have any speciÛc expectation of what these features might
be (if we did, we could have included them in the required set.) So it's entirely up to you. The only thing we can
say is for a feature to deserve extra credit it has to deliver useful additional functionality. In other words, making
the UI fancier is not going to help, because it is a subjective issue - one person's fancy could be another's
distracting.
Penalties (up to 25 points) will be assessed on the following:
Not using FXML adequately/appropriately to design the UI
Inadequate Javadoc tags/Javadoc HTML documentation not generated
Project structure does not properly separate model, view, control classes with appropriate package conÛguration
Needing extra conÛguration on our paä to test your project because you did not follow speciÛcations
Usability is poor such as roundabout ways to get at data, and/or confusing inteãace
Lacks scalability i.e. doesn't display large amounts of data (e.g. many tens of photos or more) in a easily navigable
way