Purpose
The purpose of this project is to produce an Object-Oriented Design and demonstration Java program that implements a locker for
holding information like Computer Accounts, Credit Cards, Wireless Access Points, Identity information like SSN, Drivers Licenses,
Passports, etc.
Overview
The goal of this project is to demonstrate your ability to do object-oriented design and then implement a demonstration of the quality of
that design. The following discussion supplies some input necessary to create the object model, but more discovery is likely required.
Discussion
The following is intended to start a thought process about the necessary characteristics and how to proceed. Use the MoSCoW list to
capture the features that need consideration but don’t put too many in the “Must” category. It is valuable to have the “Must” category
represent a working skeleton so that things may be tried and provide valuable guidance. In an industry setting, Must may also have
implications of minimum viable product but we won’t apply that definition here. The complete implementation would have to explore
many issues, including
Access control to the locker
Change control
Feature set
Categories of information (Computer Account with passwords, Credit Cards, Wireless Access Points, Passwords (without
accounts), Software Licenses, SSN, Drivers License, Passport, etc.)
Types of information within an item
Fields that will be in all items
Fields that are in specific categories of items
Types of fields (text, password, numeric, URL, notes)
How to search for a specific item
How to access the fields of an item
How to create an item
How to modify an item
How to persist the locker between executions of the program
How to secure the locker (not in scope for P4–5, do not spend time here)
Integration with other systems requiring information (not in scope for P4–5, do not spend time here)
GUI (not in scope for P4–5, do not spend time here)
The locker stores personal information on a computer for a user. The locker will include many items, each belonging to a category and
representing a self-contained collection of information. For example, a computer account item might contain a name, username,
password, security question/answers, notes, date created, date updated, URLs for sites where the account is used, old passwords, etc.
Looking at this information, some common data types can be discovered. The name and username are single-line text fields. The name
field, at least, is required to have content. The password is a special single-line text field that might have specific behavior such as not
showing the contents except under special situations, helper support to generate a random string subject to some rules. While the first
version might not implement the unique nature, it might make sense to provide structure (like a special class) to allow building it out later
to provide for things like security question/answer might be pairs of single-line text and tracking old passwords that might be a collection
of triples containing the old password, its start usage date, and its end usage date. The notes field is multi-line text (or rich text). Date
created and date updated are obviously dates and might be automatically maintained. The URLs for sites seem to be a collection of text
fields, perhaps with a rule that they be valid URLs.
Note: you are expected to have an object-oriented design and a matching Java implementation with a demonstration of quality.
You may have to reduce scope during the implementation phase but do not eliminate the object-oriented nature of the design nor the
demonstration of quality.
Remember, don’t put specific I/O in (domain) model classes.
Obey Java Documentation Style
Continue to use the class standard for code documentation. Ensure that the Javadoc comments contain
1. class responsibilities
2. class and instance behaviors
P4 Delivery
You shall deliver a completed Mind Map using the supplied format. The mind map includes
1. Initial identification of objects
2. Classes in the solution (and the prototype of their public methods)
3. Components of the design problem and its solution
Goals
Constraints
Standards
MoSCoW list
4. Issues, alternatives, and decisions made (and why - often relating to the goals)
Additionally, supply UML diagrams
1. Class diagram (at least one)
2. State diagram (at least one)
3. Interaction diagram (at least two, each around its own story)