Secure Data Container in Java

Data that knows its owner.

The assignment: a collection that behaves like a small data storage service. Many users keep their objects in it, so the container has to know who they are, keep everyone's data apart, and let each owner decide who else may see what they stored.

• Identity. Users register with an ID and a password; IDs are unique, and every operation on data first checks the pair.
• Isolation. A user sees only their own items and the ones others chose to share with them.
• Control. Whoever inserts an item stays its first owner: if they delete it, every copy they shared disappears too; a recipient can drop a shared item only for themselves.

A contract before the code.

The type is an interface, SecureDataContainer<E>, written before any implementation in the style of Liskov and Guttag: an overview of the abstract type, then for each of its 18 operations what it requires, what it modifies, its effects and what it throws. Domain errors are checked exceptions of its own (ExistingUserException, UserNotFoundException, DataNotFoundException); a null argument is a programming error and throws the unchecked NullPointerException.

E remove(String owner, String passw, E data) throws DataNotFoundException, UserNotFoundException;      /*      REQUIRES: owner != null && passw != null && data != null        THROWS: - NullPointerException if !(owner != null && passw != null)  (UNCHECKED)                                  or if data == null                - UserNotFoundException if user is not found in the container (CHECKED)                - DataNotFoundException if data is not found in the user owned items (CHECKED)      MODIFIES: this       EFFECTS: If user is the firstOwner the method will delete his data and all the same data                that he shared to others, otherwise (if user is not the firstOwner) it will only                delete his data     */

Same abstraction, different data.

The two classes implement the interface on data structures that have little in common. The first keeps a map of users and one list with every item of every user, each labeled with who can access that copy and who inserted it. The second keeps one list per user, and an item only needs to remember its first owner. Here is the same state in both, after alice stores a report and shares it with bob:

Each class documents the bridge between the two levels: an abstraction function, which maps the concrete fields to the value the user sees (each user and the items they can access), and a representation invariant, the conditions every operation must preserve: no null fields, no null elements, no two users with the same ID.

// Implementation 1: every item of every user in one listprivate class Item {    private String owner;       // who has access to this copy    private String firstOwner;  // who inserted the data    private E data;}private Map<String, String> users;   // user ID -> password (a HashMap)private List<Item> container;        // a LinkedList// Implementation 2: one list per userprivate class Dato<E> {    private String firstOwner;    private E data;}private class User<E> {    private String id;    private String passw;    ArrayList<Dato<E>> container;}private ArrayList<User<E>> users;

One label, every rule.

Every access rule follows from the first-owner label. The demo at the top runs exactly these operations:

if (userIsInTheContainer(owner, passw)) {    if (userOwnsTheData(owner, data)) {        int index = indexOfUserOwnsTheData(owner, data);        E copy = container.get(index).data;        if (container.get(index).firstOwner.equals(owner)) {            // I am the first owner            for (int i = 0; i < container.size(); i++) {                if (container.get(i).firstOwner.equals(owner)                        && container.get(i).data.equals(data)                        && !(container.get(i).owner.equals(owner))) {                    container.remove(i);                    i--; //to compensate the removal                }            }            int finalIndex = indexOfUserOwnsTheData(owner, data);            container.remove(finalIndex);        } else {            // I am not the first owner            container.remove(index);        }        return copy;    } else        throw new DataNotFoundException("Element has not been found!");} else    throw new UserNotFoundException("User not found in the container");

One scenario, both implementations.

The test driver declares the container through the interface type, SecureDataContainer<Esame>, with an immutable exam record as test data (esame is Italian for exam), and contains the same scenario for each implementation, printing every user's view after each step:

• three users register and each inserts two records;
• records are shared, then removed by their first owner (every copy goes) and by a recipient (only that access goes);
• a user copies a shared record, another clears all their data, and finally one deletes their account: the copies they had shared disappear with it.

Both implementations print the same data at every step: two very different representations, one behavior, exactly what the specification promises.