Overview
Domain model
Use cases
Quality attributes
Constraints
Controlled unreality

Overview

Google's Notebook data API (now deprecated) provided access to notebooks. Notebooks are named sets of clippings from web pages. The clippings in a notebook are named, and they can be organized into sections. Notebooks belong to Google accounts. By default they are private, accessible only to the user who created them. The owner can make a notebook public, which makes it accessible to anyone. As an example, Don Swartwout created a public notebook that contains clippings about distributed systems.

You will design and implement DiNo (Distributed Notebook), a distributed server-side implementation of a notebook API inspired by Google's, but much simpler, with update and replication features added.

Omitted features include:

• Notebook ownership (all notebooks will be public, and writeable by anyone)
• Notebook authorship
• Authentication and authorization (not needed since notebooks are un-owned and writeable by anyone)
• Note titles
• Sub-dividing notebooks into sections
• Creation and last-update dates for notebooks and notes
• Searching within notebooks
• HTML notes

Back to top

Domain model and rules

Every notebook has one primary server Every notebook has zero or more secondary servers A notebook's primary server cannot be a secondary server for that notebook Notebook titles are unique across the DiNo system Notebook IDs are unique across the DiNo system Every notebook must have a title, which must be a character string that begins with a non-whitespace character. Notebook updates must be done through the primary server The primary server is responsible for propagating updates to secondary servers, if any A notebook can be empty (that is, contain no notes) For every note, the content must be non-empty Note IDs are unique across a notebook The content of a note must be a string The content of a note must not contain any XML tags

Back to top

Use cases

• Create a notebook
  • primary actor: ordinary user (using an ordinary client)
  • main success scenario
    • client requests creation of a notebook and supplies the notebook title
    • system checks that the title is valid and does not already exist
    • system creates the notebook and assigns a notebook id
    • system returns the notebook id to the client
  • major alternative scenarios
    • failure: the title already exists
• List all notebooks
  • primary actor: ordinary user (using an ordinary client)
  • main success scenario
    • client requests the list of all notebooks
    • system returns the list
• Add a secondary server for a notebook
  • primary actor: administrator (using an admin client)
  • main success scenario
    • admin client requests creation of a secondary copy and supplies the notebook id
    • the server that receives the request validates the notebook id
    • the server sets up a secondary copy of the notebook
  • major alternative scenarios
    • failure: there is no notebook with the given id
    • failure: the server already has a secondary copy of the notebook
    • failure: the server is the primary server for the notebook
• Remove a secondary server for a notebook
  • primary actor: administrator (using an admin client)
  • main success scenario
    • admin client requests deletion of a secondary copy and supplies the notebook id
    • the server that receives the request validates the notebook id
    • the server removes its secondary copy of the notebook
  • major alternative scenarios
    • failure: there is no notebook with the given id
    • failure: the server does not have a secondary copy of the notebook
    • failure: the server is the primary server for the notebook
• Delete a notebook
  • primary actor: administrator (using an admin client)
  • main success scenario
    • admin client requests deletion of a notebook and supplies the notebook id
    • system validates the notebook id
    • system removes all copies of the notebook
  • major alternative scenarios
    • failure: there is no notebook with the given id
• Create a note
  • primary actor: ordinary user (using an ordinary client)
  • main success scenario
    • client requests creation of a note and supplies the notebook id and note content
    • system validates notebook id and note content
    • system assigns a new note id
    • system creates a new note in the given notebook with the given content and the newly assigned id
    • system adds the new note to the notebook's secondary copies, if any
    • system returns the new note to the client
  • major alternative scenarios
    • failure: there is no notebook with the given id
• Replace a note's content
  • primary actor: ordinary user (using an ordinary client)
  • main success scenario
    • client requests replacement of a note and supplies the note's URI and revised content
    • system validates note URI and note content
    • system replaces the note's content with the given content
    • system replaces the notes' content in the notebook's secondary copies, if any
  • major alternative scenarios
    • failure: there is no notebook with the given id
    • failure: there is no note in the given notebook with the given note id
• Delete a note
  • primary actor: ordinary user (using an ordinary client)
  • main success scenario
    • client requests deletion of a note and supplies the note's URI
    • system validates note URI
    • system removes the note from all copies of the notebook
  • major alternative scenarios
    • failure: there is no notebook with the given id
    • failure: there is no note in the given notebook with the given note id

Back to top

Quality attributes

Quality attributes are observable aspects of a system that don't directly correspond to functional requirements. For example, a system's quality attributes include capacity, responsiveness, availability, modifiability, and security. Systems usually meet their functional requirements, but they often fail to provide one or more critical qualities. The table below will be populated with values we brainstorm in class. I will pick compromise values among the proposals from different groups. Some qualities that we brainstorm and discuss in class may be impractical to test in the lab (for example, 99.9% availability). I'll leave such qualities out of this table.