ECE 417/617 Elements of Software Engineering

Spring 2009

In this course students will learn to build high-quality, reliable, and extensible software systems that are too large for a single programmer.  Emphasis is placed upon good programming practices (object-oriented design and clean, well-documented code), teamwork skills (planning, communicating, and interacting), and bringing the project to completion (testing and verification).  A semester-long project complements the theory with practice.

Syllabus
 

Schedule

Week	Topic	Assignment
1	introduction / overview	learning report #1 (1/16):  Pollice
2	C++ and Visual Studio IDE
3	More C++, object-oriented programming, and CVS	learning report #2 (1/30):  S/W Chronic Crisis and Bugs
4	Software life cycles
5	Software process and modeling (UML)	learning report #3 (2/13):  Royce
6	Project management
7	Agile methods	learning report #4 (2/27):  Microsoft (Cusumano-Selby and Guth)
8	Requirements
9	System design	learning report #5 (3/13):  Brooks (article and review)
10	[Spring break]
11	Testing
12	Risk analysis	learning report #6 (4/10)
13	User interfaces
14	Formal methods
15	Ergonomics	final system demo (4/24)

Other dates:

• Group milestones / meetings will be conducted in class every Friday, starting 1/16
• Final exam:  4/30, 3:00 - 5:30

Textbook and Resources

Recommended books:

• Bjarne Stroustrup, The C++ Programming Language, Addison-Wesley, 2000.
• Fred Brooks, The Mythical Man Month:  Essays on Software Engineering - Anniversary Edition, 1995.
• Roger S. Pressman, Software Engineering, 6th ed., McGraw-Hill, 2005.

Suggested readings:

• Gary Pollice, Teaching Software Development vs. Software Engineering, 2005
• Software's Chronic Crisis, Sept. 1994
• Bugs in the news:  Rover, MS Server, Mars Climate Orbiter, Mars Spirit, Toyota
• Walter Royce, Successful Software Management Style:  Steering and Balance, IEEE Software, 20(5):40-47, 2005
• Michael Cusumano and Richard Selby, How Microsoft Builds Software (another copy accessible from off campus), Communications of the ACM, 40(6), June 1997
• Robert Guth, Battling Google, Microsoft Changes How it Builds Software, Wall Street Journal, Sept. 23, 2005
• Fred Brooks, The Mythical Man-Month After 20 Years, IEEE Software, 12(5):57-60, Sept. 1995 (review of the book)
• Eric Raymond, The Cathedral and the Bazaar, 1999
• Cliff Jones et al., Verified Software:  A Grand Challenge, IEEE Computer, 39(4), April 2006
• Barry Boehm, Making a Difference in the Software Century, IEEE Computer, 41(3), March 2008
• Articles in
  • International Conference on Software Engineering
  • IEEE Transactions on Software Engineering
  • IEEE Computer Magazine
  • IEEE Software Magazine

Additional software engineering resources

1. Introduction
2. Condensed Crash Course on C++
3. Concurrent Versions System (CVS)
4. The Software Process
5. Modeling
6. Design
7. User Interface Design
8. Testing
9. Project Management
10. Software Practice
11. Formal Methods
12. Repetitive Strain Injury (RSI)

The material of this class is highly non-linear and does not lend itself well to the traditional model of teaching in which the instructor imparts knowledge to the students.  Instead, much of the learning must be self-directed in order to be meaningful.  The purpose of the learning reports is to give you the opportunity to learn material related to the course as your interest and needs dictate.  Take a few hours to study a topic that interests you, or read one of the articles linked from the web page, and write a summary report of what you have learned.  Note that for the first several reports the topic is given, while for the remaining ones the topic is up to the student.  Reports should be the equivalent of 1-2 pages of a traditional report (single-spacing, 12-point font, 1" margins).  A hardcopy of the report should be turned in during class on the day it is due. 

The format of the report should be as follows:

• At the top should be the title of the report (not the title of the article you read), your name, the class and semester (e.g, ECE 417, Spring 2009), and the number of the learning report (e.g., Learning Report #1)
• The body should be written with appropriate indentation, spacing, etc.  Section headings will help to organize the paper.
• At the end, you should list all the references you read in preparing your report.  Be sure to include the author, title, year, pages (if appropriate), volume/number/journal or magazine (if appropriate) or URL, etc.

Grading of the reports will be as follows.  Everyone will start with a baseline grade of 85 points for each report.  Points will be subtracted as follows:

• 2 points for each spelling mistake (maximum two mistakes per word)
• 2 points for each minor grammatical mistake (subject/verb agreement, capitalization, ...)
• 5 points for each major grammatical mistake (not a sentence, ...)
• 2 points each for not following the correct format, as described above
• 3 points for each factually incorrect or questionable statement
• 20 points for not adhering to the minimum page limit (1 page single-spaced, or 2 pages double-spaced)

Points will be added as follows:

• 5 points for each additional reference consulted, analyzed, and documented in the reference section (maximum of two) -- additional 5 points if at least one of these comes from a published source such as a journal or magazine
• up to 5 points for particularly insightful analysis

Recall that the purpose of this class is two-fold: practice, and theory. On the practice side, you are all learning CVS, C++, VC++, etc. Gaining experience with these tools is essential to being a good software engineer. On the theory side, we are exploring concepts such as modeling, design, project management, etc. The milestones and class-wide project focus primarily on the practice, with some theory applied. The purpose of the learning reports is to focus primarily upon the theory, with some practice sprinkled in. Thus, while there is overlap between practice and theory, the aim of the learning reports is to stretch you to consider the theory in more detail. For this reason, you are highly encouraged you to ready and study the 'suggested readings' above, as well as any other relevant material that you come across.

Project organization

Students are divided into groups to develop different components of the application.  Within groups, students are paired (pair programming).  Each group is responsible for dividing up the work among its members, scoping the work to be done, and keeping track of the accomplishments of each member as well as the accuracy of the time estimates.  For each milestone the group should submit the source code itself (via CVS); a summary of the work done including a detailed task list with the responsible individuals, estimation times, and completion dates (hardcopy brought to class); and a list of tasks/goals for the next milestone.  If an individual is not pulling his or her weight, the group has the right to fire that individual from the group; such decisions should be communicated to the instructor as soon as they are made.

Coding conventions

Writing code that compiles and runs is not enough.  An important part of software engineering is writing code that is also easy to read by other programmers, not only those in your team but also those whom you've never met.  Since we will be reading each other's code,  it is important for us to have an agreed-upon set of conventions.  Since the conventions themselves are somewhat arbitrary, the following list has been compiled using some of the more common approaches adopted in the industry.

• Spelling and syntax:
  • class, struct, namespace, function, method:  InterCaps style (first letter of each word capitalized), also known as CamelCaps
  • typedef:  same as class
  • local variables, function parameters: all_lowercase_with_underscore_between_words
  • member variables of a class:  same as local variables, but with 'm_' prefix
  • macros, enums:  ALL_UPPERCASE_WITH_UNDERSCORES_BETWEEN_WORDS
  • global variables (avoid these of course):  same as local variables, but with 'g_' prefix
  • private methods:  iInterCaps (intercaps but with a leading underscore i)
  • filename (if one file per class):  ClassName.[h,cpp]
  • braces { }:  in the same column (C++-style), not opening brace at end of line (Kernigan & Ritchie C-style)
  • number of spaces in a tab:  2 (but insert spaces, not tabs!)
• Comments and parameter passing:
  • Functions that do not modify the member variables of a class are declared const
  • Function parameters that are not modified (except native types) are declared with const&
  • Function parameters that are modified are declared with a pointer (*) and come after all the inputs
  • Functions local to a file are enclosed in an unnamed namespace to keep its linkage internal to the file.  Like private methods, these follow the iInterCaps style.
  • Just before each class declaration, a comment briefly describes the purpose and functionality of the class, any non-obvious peculiarities, and the author's name in JavaDoc / Doxygen format (starts with two asterisks, keywords start with @)
  • Each header file starts with #ifndef #define, and ends with #endif;  double-underlines lead and trail name of file in ALL CAPS WITH UNDERSCORES; Example:
    #ifndef __BLEPO_IMAGE_H__
    #define __BLEPO_IMAGE_H__
    ...
    #endif __BLEPO_IMAGE_H__
• Licensing:
  • At the top of each file that you write or modify (do not worry about automatically generated files that you do not touch), include the GNU GPL license:
    /*
    * Copyright (c) 2008 Clemson University.
    *
    * This program is free software; you can redistribute it and/or modify
    * it under the terms of the GNU General Public License as published by
    * the Free Software Foundation; either version 2 of the License, or (at
    * your option) any later version.
    *
    * This program is distributed in the hope that it will be useful, but
    * WITHOUT ANY WARRANTY; without even the implied warranty of
    * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
    * General Public License for more details.
    *
    * You should have received a copy of the GNU General Public License
    * along with this program; if not, write to the Free Software
    * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
    */

Example:

   /**
    This class keeps track of time.
   
    @author Ima Coder
   */
   
   class TimeManager
   {
   public:
       typedef int SecondType;
       TimeManager();
       double GetTime(int day, const TimeStamp& another_time);
   private:
    double m_day_of_the_week;
   };
 

Among the many standards on the web, Todd's very extensive and helpful C++ coding standard is similar to that above and also contains some insightful points about software engineering in general.  Wallach has a shorter coding convention list.  Lott maintains an extensive list of conventions, some of which are quite extensive :).   Linus Torvald's conventions for the Linux kernel makes a fun read, though it's geared toward C rather than C++.  And, for something completely different, don't forget to check out Microsoft's Hungarian notation.

CVS (concurrent versions system) instructions

CVS is a command-line tool for managing source code revisions using a single repository.  WinCvs is a popular GUI for CVS that makes it much easier to use.  (Other interfaces exist, such as tortoisecvs).  To start using CVS through WinCvs, do the following:

1. Download and install WinCvs/MacCvs/gCvs on your development machine
2. Run WinCvs (wincvs.exe)
   • If you are using version 2.0 of WinCvs,
     1. Click Admin.Login
        1. Under Login settings tab,
           1. Set CVSROOT to :pserver:yourid@cvs.ces.clemson.edu:/pub/cvsprojects/ece417
              (Replace yourid with your student id)
     2. Click Admin.Preferences
        1. Under CVS tab,
           1. Set Home folder to somewhere on your machine
        2. Under WinCvs tab,
           1. Enter path of external diff program, and click checkbox (For Windiff, go to C:\Program Files\Microsoft Visual Studio\Common\Tools\windiff.exe; other diff programs are WinMerge for Win32 or xxdiff for Unix)
     3. Your password will be emailed to you.  If you wish to change it, please email a different password to the grader so we can put it into the CVS passwd file.  Note:  CVS has poor security, so do not use an important password for this project.  Instead, send something that you don't mind having compromised. 
     4. Click Admin.Login, select the CVSROOT (if it is not already chosen), and type your password (this will store your password locally in your Home folder/.cvspass).  You only need to login this one time (unless of course you ever explicitly log out).
     5. Click Remote.Checkout module
        1. Enter module name:  name, where name is defined below
        2. Enter local folder where you would like to store the checked out files
     6. Whenever a command succeeds, you will see  *****CVS exited normally with code 0*****
     7. Ignore the warning that you don't have TCL or Python.
   • Else if you are using version 1.2 of WinCvs,
     1. Click Admin.Preferences
        1. Under General tab,
           1. Set CVSROOT to yourid@cvs.ces.clemson.edu:/pub/cvsprojects/ece417
              (Replace yourid with your student id)
           2. Set Authentication to "passwd" file on the cvs server
        2. Under WinCvs tab,
           1. Enter path of external diff program, and click checkbox (For Windiff, go to C:\Program Files\Microsoft Visual Studio\Common\Tools\windiff.exe)
           2. Set Home folder
     2. Your password will be emailed to you.  If you wish to change it, please email a different password to the grader so we can put it into the CVS passwd file.  Note:  CVS has poor security, so do not use an important password for this project.  Instead, send something that you don't mind having compromised. 
     3. Click Admin.Login and type your password (this will store your password locally in your Home folder/.cvspass).  You only need to login this one time (unless of course you ever explicitly log out).
     4. Click Create.Checkout module
        1. Enter module name:  name, where name is defined below
        2. Enter local folder to checkout to
     5. Whenever a command succeeds, you will see  *****CVS exited normally with code 0*****
3. Now CVS is ready for you to add your own files, modify them, etc.!  For reference, see the on-line CVS Cederqvist manual or Redbean manual

Alternatively, if you would prefer to just use the command-line version (not recommended),

1. Download and install the cvs client on your development machine
2. Use a text editor to create a ~/.cvsrc file that contains a single line that looks like this:
   cvs -d :pserver:yourid@cvs.ces.clemson.edu:/pub/cvsprojects/ece417
   (Replace yourid with your student id)
3. type cvs login at the command prompt, along with your password (this will store your password locally in your ~/.cvspass file)
4. cd to the directory in which you want to copy files from the repository
5. type cvs checkout name, where name is defined below
6. Now CVS is ready!  For reference, see one of the manuals above

Replace name with class/rootfly (Spring 2005, 2007, 2008, or 2009), or class/seebreeze (Spring 2006).

For the grader: 

• To encrypt a password, use
      /usr/local/bin/perl -e 'print crypt("MyPassword","St") . "\n";'
  replacing MyPassword with the password you would like to encrypt.  (You may need to use /usr/bin/perl  if the above does not work.)
• To print a history of all checkouts and updates,  cvs history -x UO -a

VC++ 6.0

• Resources:
  • Microsoft Visual Studio Service Pack 6 download
  • Visual C++ quick guide
  • The MSDN on-line help contains extremely helpful documentation on the Win32 API and MFC.
  • C library reference
  • Another C library reference (including low-level I/O functions)
  • Rename a VC++ project
• To load macros into Visual Studio 6.0:
  • Load macro file
    1. Click Tools.Macros.Options.Loaded Files.Browse
    2. Select cvl-macros.dsm (or your own file).  Be sure checkbox next to file is checked.
  • Set keyboard shortcuts
    1. Click Tool.Customize.Keyboard.Category.Macros
    2. For each macro, select it, press the keystroke combination mentioned in the description into the window entitled, "Press new shortcut key", then press Assign
    3. Exit Visual Studio to save settings

When checking in code, be sure to check in all .cpp, .h, .dsp, .dsw, and .rc files, along with the res directory that contains .ico and .rc2 files.  The .ico file is binary, while all others are text-based.  Do NOT check in all the other files that Visual Studio creates automatically, such as .aps, .clw, .ncb, or .opt.  When in doubt, check out your code to a new temporary directory and verify that it compiles and runs.

Project

Individual Milestones:

• Milestone 1 (individual assignment), due 1/16 (11:59pm)
  • Write a C++ class called File with the following public methods: 
    • empty constructor --- does nothing but initialize private members appropriately
    • constructor taking a const char* --- opens a file for reading using the provided filename
    • void Open(const char*)  --- same as previous, but first closes the current file if there is already one open
    • void Close() --- closes the file if there is one open, otherwise does nothing
    • destructor --- same as previous
    • bool ReadInteger(int*) --- reads the next integer in the file separated by whitespace; returns a bool to indicate whether it was successful (0 indicates EOF, 1 indicates success)
  • Privately, the class should own a FILE* and access the file using C routines.  Alternatively, you can use ifstream and C++ routines, if you prefer..
  • Write a public function int Add(const std::vector<int>& a) that returns the sum of all the numbers in a vector.
  • Write a Visual C++ console-based application that takes a single command-line argument, namely, the name of the file to open. When executed the program should open the file, read all the numbers in the file until the end of the file is reached. The program should print all the integers one after the other on stdout, after which it should print the total of all the numbers, the total being computed by the Add function. 
    • To create a console app, follow these instructions:  File -> New -> Project -> Win32 Console Application. Give it a name (Name the workspace userid_hw1, where userid is your Clemson user id) and keep the checkbox on "Create new workspace". Choose "An application that supports MFC." Now compile and run (Build -> Build ..., and Build -> Execute, or F7 and Ctrl-F5). Under FileView -> Source Files you will find the main cpp file.
  • Email the grader (and cc the instructor) with the subject line "HW1" (without quotes).  The email should have the following files attached:
    • username_hw1_zip (This is a zipped version of your entire workspace -- with extension removed -- with everything needed to compile your code.)
    • all the source files that you actually wrote for the homework, attached as individual text files (there will probably be only one or two of these).
  • Also, add your userid and name to 'student_list.txt' in the 'rootfly/spring2009' directory of the CVS repository.
• Milestone 2 (individual assignment), due 1/23 (11:59pm)
  • Create a dialog-based MFC windows application (MFC AppWizard)
  • Add a button to the dialog; rightclick on the button and change the displayed text to "&Add Polyline"
  • Ctrl+W to bring up ClassWizard, add a callback to the BN_CLICKED message, then choose 'Edit Code'
  • In the ClassWizard, click on the dialog under 'Object IDs' and add a callback to the WM_LBUTTONDOWN message
  • Add to the dialog class:
    • Two member variables:
      • bool m_adding = false;  // indicates whether in 'adding mode'
      • std::vector<CPoint> m_points;  // stores the points that have been clicked
    • A method called 'Redraw' that draws the polyline
      • Hint:  Use CClientDC(this) to create a device context.  Then use dc.MoveTo and dc.LineTo to draw.
  • The behavior should be as follows:
    • When the program starts up, mouse clicks in the window (outside the buttons) do nothing
    • After clicking "Add Polyline", mouse clicks add points to the polyline, which is drawn immediately
    • Clicking 'OK' or 'Cancel' exits the program
  • Create a directory in 'rootfly/spring2009/hw' with your userid.
  • Into this new directory that you created, check in all the files and directories needed to compile your program, but no more (see above).  The grader should be able to do a CVS update, compile your code, and run it.

Class Project:

The semester-long project will be divided into three phases:

• Phase I:  Ramp-up.  (1/26 - 2/13).   Define the problem, organize the members of the team, scope out the work, document the existing system, develop a plan.
• Phase II:  Coding and Testing.  (2/16 - 4/17).  Test the system, find and fix bugs, implement desired functionality.
• Phase II:  Wrap-up.  (4/20 - 4/24).  Update all documentation, complete all activities.

Deliverables:

• Weekly logs -- for individuals and groups.  Due throughout semester.
• Software Project Management Plan (SPMP) -- describes all the managerial aspects of the project, including the work breakdown structure, schedule, client requirements, project goals and organization, work packages, budget, and allocation of resources and responsibilities.  Due 2/13, 11:59pm.
• System design document (SDD) -- provides a precise description of the software architecture (using CRC cards, DFDs, UML, etc.) and is used to define interfaces between teams of developers.  Due 2/13, 11:59pm.
• Requirements analysis document (RAD) -- completely describes the system in terms of functional and nonfunctional requirements (using natural language, use cases, etc.).  Due 2/13, 11:59pm.  Here is the suggested format for SPMP, SDD, and RAD.
• Test plan -- documents the managerial aspects of testing, such as the scope, approach, resources, and schedule, as well as the requirements and components to be tested.  Due: TBD.
• Object design document (ODD) -- describes the software implementation in detail, including design trade-offs made by developers, guidelines they followed, subsystem decomposition, and class interfaces.  Usually embedded in the source code comments and generated automatically (e.g., using Doxygen) to ensure that it's always up to date.  Due 4/17, 11:59pm.
• Final code, help file, and documentation.    Due 4/24, 11:59pm.

For the project, students should:

• submit weekly logs of their work (in CVS)
• keep their group's task list up to date, submitting weekly
• modify 'change_log.txt' (in CVS) whenever a change is made to the code that user may care about
• follow coding conventions (especially indentation)

Rootfly bugs and features can be found at sourceforge

List of desired Rootfly features/bug fixes:

1. Top priority:
   1. bug:  out of memory error
   2. optimize sluggish performance: 
      1. sluggish with 40+ sessions, 33 windows, and 36 tubes
      2. click thumbnail, there is a delay in redrawing
      3. cache for thumbnails to improve redraw speed
   3. Add 'start annotating' button; then autodetect, and autocopy
      1. remove 'autodetect' button and 'done annotating' button
      2. simplify bits for whether autodetect run
      3. make sure that .rfy file reading/writing still works (what bits in file are affected?)
   4. Progress window
      1. Simplify interface for Progress Window by collapsing colors for 'done annotating' and 'root drawn'
      2. progress window needs page button for many tubes
      3. progress window should show all sessions for single tube, rather than all tubes for single session
   5. UI
      1. when zoomed out, should be able to select and edit any root, whether or not its primary window is the center window
      2. replace gaudy pencil icon
      3. hand icon for panning
      4. rephrase dialog box in tools.options:  "Automatically detect roots when image loaded"
      5. MoveAll should move all roots in all windows
      6. when drawing new root, set window of root using centroid of all the points (instead of using the window of the first point)
      7. if user moves root outside image, cannot select point on root (?)
      8. arrow keys shortcut:  when zoomed in, move w/i image; otherwise, navigate to next WS
      9. need prettier pan/zoom buttons; put magnifying glass icon on Zoom in / zoom out buttons
2. High priority:
   1. remember last TWS after exiting program; store in registry or file on disk so that automatically navigates there
   2. new, select directory: need less scary interface for file format; should parse filenames automatically and display interpretation overlaid; then provide 'details' button if user wants to change this.
   3. replace click, move, click with click-n-drag
   4. Copy dialog
      1. copy... should copy to current TWS by default (rather than *from* current TWS)
      2. copy shortcut key
      3. copy... should jump over missing session; i.e., don't allow copy from empty session
      4. if copy to session containing roots, do not lose existing roots
      5. copy session thru ... (empty warning box) -- str empty in uc_copysession::execute
   5. calibration:
      1. average multiple calibrations
      2. calibration:  allow user to adjust endpoints
   6. remove Debug item from main menu
   7. autodetect warning if roots already present (give three options:  copy roots before autodetect, don't copy roots, cancel)
   8. quickjump button jumps to the next window, first session with no data (like typewriter carriage return)
   9. store experiment info (e.g., name of experiment) in resulting .csv file
   10. put 'Zoom:' label just above group of zoom buttons
   11. all images should be the same size (provide warning if loading an image with different size);
       See ApplicationData::ReloadImageBuffers -- question for user:  What should happen if images not all same size?
   12. open old .rfy file => should not ask you to navigate to image directory
   13. (?) copy only data for single root (in case user went back to earlier session and added a root that was missed)
   14. (?) copy only certain data for single root (in case user went back to earlier session and changed state of root from dead to live)
   15. (?) button on each side of thumbnails allows user to quickly jump to first session or last session
3. Bugs:
   1. edit.mm conversion => in debug mode it fails b/c window of color box does not yet exist
4. Internal refactoring:
   1. optimize redraw function
   2. ProgressData has a duplicate copy of whether image has been annotated; really should only be in Tube; see OnCHECKDoneAnnotating
   3. remove old zoom in/out check buttons (but be careful b/c they may be still being used in the code)
   4. develop documentation with Doxygen
   5. rename Tag to TubeName; many Tag methods are not used -- either delete them or justify existence; use Tag / TubeName in Tube
   6. nobody calls ApplicationData::getMainImage
   7. ImageScanned = ImageAnnotated
   8. TubeControl does what?
   9. TestBar is not used
5. Future version:
   1. autosave
   2. wraparound/panoramic camera
   3. (?) toolbar to replace buttons; would require SDI implementation rather than dialog box
   4. (?) copy data backwards to earlier session
   5. slider for setting autodetect sensitivity
6. Completed:
   1. improve results with RootDetect.dll (old version is better)
   2. Make converter .exe to handle versions before 1.8.25 (see "START new file version starting with 1.8.25" in DataStructures.cpp)
   3. non-Bartz format
   4. jpegs and bmps
   5. resize application window
   6. zoom out image; display multiple images simultaneously and allow user to trace root across them; this would take the place of displaying windows in tube as contiguous (able to turn off for researchers who skip windows)
   7. user-defined condition code (allow for up to two of them); 'Custom'
   8. user preferences should be saved (user-defined condition code is specific to experiment)
   9. tube name includes transect (if one)
   10. move entire root
   11. copy... button brings up dialog box to enable different options
       • copy all data from previous session
       • copy only data from previous window (how to handle root that spans multiple windows?)
   12. select all, move roots (this would replace need for register button)
   13. root can span multiple windows
   14. keep thumbnails the same size as window is resized; fit as many as we can
   15. multiple diameters per root
   16. do not allow circle to drag off root
   17. allow user to customize colors for drawing roots
   18. delete individual points in root
   19. display date
   20. bug:  when parsing Bartz format, get session directly from the field for session rather than inferring from the date
   21. (?) auto-copy session when go to next session; auto-copy window when draw
   22. add scrollbar on left and bottom
   23. provide stub for automatic root detection algorithm; need to store bit per window/session indicating whether algorithm has already been run; also need to store set of likely false positives per window.
   24. bug:  rootfly is slow when advancing to the next image (scan directory is the problem?); ok to have all the images in one directory if we can fix this.
   25. file export bug:  should not change filename
   26. copy previous bug, needs to remember alignment
   27. allow user to change id of root (?)
   28. undo

Instructor: Stan Birchfield, 207-A Riggs Hall, 656-5912, email: stb at clemson
Office hours:  3:30-5:00pm Monday, or by appointment
Grader: Prakash Chockalingam, cchocka at clemson
Lectures: 2:30 - 3:20 MWF, 227 Riggs Hall