Schedule Master 2K2

1
Schedule Master 2K2

• Ray Blakney
• Chris Harley
• Greg Lefty
• Josh Napier

2
200 Yard Overview

• A calendar/schedule program with functionality
  similar to MS Outlook
• Operates as a client/server system
• Users can enter appointments and events into
  SM2K2
• Users can view their calendar / events
• Software utilizes a DB for persistent storage
• Users receive a notification prior to the start
  of a scheduled event

3
Implemented Requirements

• Users can view their scheduled events in three
  different views (day, week or month at a time)
• Users can add events to their schedule
• New users can be added to the system
• Logged in users receive notification of scheduled
  events
• User and event information is persistently stored
  on a server machine, and accessed with a client
  machine connected via TCP/IP.

4
Unmet Original Requirements

• Users can modify and delete their events
• Users can schedule events with other users
• A user can view the schedules of others
• Events may be marked as private other users
  cannot see the description of the event
• Users will receive an email notification of an
  event

5
Schedule Master 2K2 Is Not

• Very secure
• Going to notify users of missed events
• Configured for speed or memory
• Designed for large numbers of users and events
  as these increase, the memory usage increases
  linearly
• Winning awards for its UI beauty

6
(No Transcript)
7
(No Transcript)
8
(No Transcript)
9
(No Transcript)
10
State

• The server-side DB maintains persistent state of
  events and users
• Classes have only trivial state changes (created,
  waiting, running)
• No state in our classes means
• No complex state changes, easier to maintain,
  less chance of an unknown state
• Objects have easy to understand lifecycle
  (creation, do work, destruction)
• Easy to port to a stateless protocol system (ie
  HTTP)
• Many objects are created and destroyed while
  running

11
(No Transcript)
12
(No Transcript)
13
(No Transcript)
14
Singleton Pattern

• A class with only one instance and a global
  access point
• CurrentUser
• Contains information about the user on the client
  machine
• Only one user can be logged in from a client
• Essentially a global storage class for the user
• DateToView
• Contains the date used by the views on the client
  machine
• Each view uses this class to get the date to
  display
• Contains helper methods to get information about
  the date
• If not set explicitly, by changing the date in a
  view, defaults to today

15
Broker Pattern

• Provides a connection between classes, for
  various protocols, or for locating a specific
  server
• NotificationBroker class
• Used to maintain connections to clients for
  notification
• Determines which clients (users) are connected
• Spawns Notification objects for pop-up alerts on
  the client
• Would have been responsible for constructing
  email notifications
• Other notification types could use this (cell
  phone, PDA, pager)
• Is also a Singleton

16
Model-View-Controller

• Divides an interactive application into three
  components
• The model contains the core functionality and
  data
• UserEvents
• Contains information about an event, and a user
• DateToView
• Contains the date the view is focused on
• Views display information to the user
• ViewWeek
• Displays events for a particular week in a
  graphical manner
• ViewMonth
• Displays events for a particular month in a
  graphical manner
• Controllers handle user input
• User interaction is simple enough and tightly
  coupled to view, so the views handle this
  responsibility

17
Verification / Testing Plan

• Test Patterns Applied
• Pair Testing
• Scenario Testing
• UI Window Modality Testing

18
Pair Testing

• Importance
• Develop wide understanding
• Avoid tunnel vision
• Avoid testing error
• Avoid overlooking different aspects of test

• Implementation
• Two or more people test the same thing at the
  same time. Various testing techniques can be
  used.

19
Scenario Testing

• Importance
• Create credible test
• Identify situations where faults will be
  important to persuade correction
• Insure intended functionality is delivered

• Implementation
• Create different scenarios end users will likely
  encounter
• Be sure that test is designed so errors are easy
  to detect
• Run through scenarios, searching for errors

20
UI Window Modality Testing

• Importance
• Find UI modality errors (i.e. do modal windows
  close when parent window is closed?)
• Ensure that all paths through UI are followed and
  are functional

• Implementation
• Navigate each task window
• Force subtasks to open
• Can parent tasks be closed without closing the
  subtask?
• Can more than one instance of a task be opened?

21
What We Learned

• Know your limits, and those of your team members
• Tools can be more of a pain than theyre worth
  (Forte)
• Design Patterns and their use (MVC)
• Java (particularly Swing)
• Abstraction and its implementation (abstract
  controller classes)

22
Next time we would

• Allocate more time
• Not set such ambitious goals
• Configure and use source control
• Communicate our progress to each another better
• Try not to assume our original requirements were
  set in stone