Table of Contents

  1. Introduction
    1. Purpose
    2. Project Description
    3. Related Documents
  2. Object Design
    1. Back end Object UML Class Diagram
    2. Back end Object Design dictionary
    3. Front end Object UML Class Diagram
    4. Front end Object Design Dictionary
  3. Database Design
    1. Database Entity-Relationship diagram
    2. Database Design dictionary
  4. Human-Computer Interface Design
    1. HCI Flow Diagram
    2. HCI Diagram Dictionary
  5. Bibliography

  1. Introduction
    1. Purpose

      This document is the design specification for Bad Coffee, a project by BeanTree Development. It contains the project's description, designs for its objects and database, and a Human-Computer Interface map. The object design consists of a UML diagram of the project's classes and a dictionary of related terms. The database design consists of an entity-relationship diagram of the access point database and a dictionary of terms. The HCI map is a flow diagram for the different screens of the application, and includes a dictionary summarizing each screen.

    2. Project Description

      BadCoffee is a system which builds off of the proliferation of 802.11 wireless (Wi-Fi) access points. The main features of BadCoffee are the ability to view detailed information for an access point and to leave "air graffiti" by posting messages attatched to a specific wireless access point, which other users of that access point can read and reply to. Also, BadCoffee will allow users to rate the performance and environment of an access point. Other features include tools for storing and parsing log files from Wi-Fi enthusiasts and WAR drivers who wish to keep track of access points they have discovered.

    3. Related Documents

      The design for Bad Coffee is based on the Bad Coffee requirements spec.

  2. back to top
  3. Object Design
    1. Back end Object UML Class Diagram (click image to enlarge) - download UML (Dia file)

      This diagram lays out the basic classes used to generate, store, and pass information between the client and the server. These objects represent tables in our database and are able to pull information from or append information to the database. Elements bordered in blue reside on the remote server, while elements bordered in black reside in our client application.

      Object UML class diagram

    2. Back end Object Design Dictionary
      • Message: Messages left by users are associated with a specific access point. Each message can be either a new post or a reply to a previous post, and will have title, body, and poster visible.
      • AccessPoint: AccessPoints are the basic location unit of the system. Each AccessPoint corresponds with a wireless antenna in the real world, and so has a unique MAC address and other information. AccessPoints need to be part of at least one APGroup. The AccessPoint class can convert itself to a transmittable XML document which the client application can read and display.
      • APGroup: An APGroup is an organizational class containing AccessPoints. Usually, a wireless network will consist of multiple access points operating under a single name so that a large area can be blanketed with wireless access. One will not want to post messages to an individual access point, but to a larger group of access points in a specific area. An example of one of these larger areas with more than one wireless access point is Johnny's or the Fish House at Calvin College.
      • User: The user class will hold information for users, such as username and password. The User class will also be responsible for authenticating a user.
      • ClientHandler: ClientHandler is a class which will be responsible for talking directly to the client application. It will retrieve all information for the client, and take all information from the client. It has methods for manipulating every other class found on the server.
      • ServerInterface: ServerInterface is the only back end class that resides on the portable device. It recieves data from the server and passes it to the front end, properly formatted. It also takes data from the front end, formats it, and sends it to the server.
    3. Front end Object UML Class Diagram (click image to enlarge) - download UML (XCode model file, zipped)

      Our front end is responsible for taking data sent from the server and displaying it on-screen. Data will be displayed in an itemized, easy-to-read format. Each screen will be represented by its own class. It will also have an interface for each operation supported by the server, such as search, update, add, and so on.

      Object UML class diagram

    4. Front end Object Design Dictionary
      • APDetailScreen: This screen displays the details for a specified access point or APGroup. From it, you can navigate to a screen for appending or editing details about the access point or navigate to a screen that lets you view the message board associated with that access point or APGroup.
      • StartScreen: This is the main screen of the program. From it, you can navigate to screens showing APGroup details, a search form for the online database, or a list of favorite APs.
      • SearchScreen: This screen contains fields for building a search query of access points to send to the online database.
      • MessageScreen: This screen displays the messages from the message board associated with a group. From here the user can navigate to a PostMessageScreen.
      • GroupScreen: This screen displays info about a group and commands that can be applied to it.
      • FavScreen: This screen contains a list of the user's favorite groups.
      • SearchResultsScreen: This screen contains the results of the search sent from a SearchScreen.
      • PostMessageScreen: This screen allows the user to add a message about a specified access point.
      • MessageListScreen: This screen contains the messages associated with the current group.
      • BadCoffeeFinal: This is the main class of the program, responsible for keeping track of screens and passing data between them.
      • StaticParserMover: Tells the parser (currently uses KXML) to move to the next token.
      • ResultParserDriver: Acts as a front end for the parser to the rest of the program.
      • Result: An object returned from the parser after an XML string is sent to it.
      • Message: A message object, associated with a group.
      • AccessPoint: An object which corresponds to an individual wireless antenna. Several AccessPoints can be associated with one group.
      • APGroup: An object representing group of access points, resulting in a single wireless network.
      • User: An object for the currently logged in user.
      • ServerConnector: This object, given an XML string, will send it to the server and return the server's response.
      • ScreenInfo: A list of ints acting as labels for screens, be they Forms or TextBoxes.
  4. back to top
  5. Database Design
    1. Database Entity-Relationship Diagram (click image to enlarge) - download ERD (Dia file)

      Users can submit information about access points. Each AccessPoint is a member of one APGroup, which can be a part of another more general APGroup. Message boards consist of messages which users can post or read, and are linked to one APGroup.

      Database Entity-Relationship diagram

    2. Database Design Dictionary
      • User: A table of users.
        • Each user can discover one to many AccessPoints.
        • Fields: unique user ID, full name, username, email address, password
      • Submission: A table of the submissions from users.
        • AccessPoints can be discovered by one user, but seen by many users.
        • Users can discover and submit multiple AccessPoints.
        • Fields: unique submission ID, size of the file being uploaded, checksum, file of access points
      • Access Points: A table of unique AccessPoints.
        • Fields: unique access point ID, hardware data fields, owner info fields, physical info fields, viewings data fields, ratings data fields
      • AP Groups: A table relating AccessPoints to their corresponding group.
        • Access points can be in only one group.
        • Groups can include many access points.
        • Fields: relationship ID, access point ID, group ID
      • Groups: A table of sub-groups and parent groups.
        • Groups can have many messages.
        • Groups can have many access points.
        • Groups can be within other groups.
        • Fields: unique group ID, group name, parent ID
      • Messages: A table holding all messages.
        • A message may only belong to one group.
        • A message may be a reply to another message, in which case the message's parent ID would equal the message ID of the previous message.
        • Fields: unique message ID, parent ID, title, poster ID, message text
  6. back to top
  7. Human-Computer Interface Design
    1. HCI Flow Diagram (click image to enlarge)

      A number of screens allow the user to search for access points in the database, view info on them, and view or add comments. Below is a map of how each screen fits together and a description of each.

      HCI flow diagram

    2. HCI Diagram Dictionary
      • Login: Here a user would enter their username and password for the Bad Coffee system. Users can log in annonymously by leaving both fields blank and clicking 'Login'.
      • Home: From here the user can search for access points, view their favorites list, and access the help screens.
      • Favorites: Listed here are access points in the user's favorites list. There will be no items listed the first time the program is started. Clicking any button in the list will bring up the Group View screen for that access point.
      • Search: This screen contains a field for searching the database for access points by name.
      • Search Results: Listed here are access points from the database matching the search. From here the user can view details for any access point by selecting it and clicking on Select Group.
      • Group View: From here the user can view that group's messages or add the group to their favorites list.
      • Messages: This screen contains a list of messages that other users have left at this access point. From here one can view each message in detail or post a new message.
      • View Message: Here a user can see the full title, body, and poster info for the selected message; and can reply to this message by clicking on 'Reply'.
      • Post message: This screen contains a text field for entering the body of a message. Clicking 'Set Message Title' will switch the screen to a text box for editing the message title. On either screen, clicking 'Submit' will post the message.
      • Help: This dialog contains four buttons at the bottom. Clicking any of them will bring up a screen explaining how to do the associated task.
  8. back to top
  9. Bibliography
    • "Gump Project Design" <http://cs.calvin.edu/curriculum/cs/262/private/hall_of_fame/gump-1998/design.html>,
      The GUMP Group(1998).
    • "eGroup Design Document" <http://cs.calvin.edu/curriculum/cs/262/private/hall_of_fame/egroup-2004/design.html>,
      eGroup(2004).
    • "CS 262: Design Specification" <http://cs.calvin.edu/curriculum/cs/262/private/design.html>,
      Keith Vander Linden(2005).
  10. back to top