ECE 417/617 Elements of Software Engineering

Spring 2007

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	hw #1 (1/19)
2	C++ and Visual Studio IDE
3	More C++, object-oriented programming, and CVS	milestone #1 (2/2)
4	Software life cycles
5	Software process and modeling (UML)	milestone #2 (2/16)
6	Project management
7	Agile methods	milestone #3 (3/2)
8	Requirements
9	System design	milestone #4 (3/16)
10	[Spring break]
11	Testing	milestone #5 (4/4)
12	Risk analysis
13	User interfaces	milestone #6 (4/13)
14	Formal methods
15	Ergonomics	final system (4/27)

Other dates:

• 4/6:  Report due, oral presentations in class
• Quizzes (throughout semester)
• Final exam:  5/3, 8:00 - 11:00

Textbook and Resources

Recommended books:

• Bjarne Stroustrup, The C++ Programming Language, Addison-Wesley, 2000.
• David Gustafson, Schaum's Outline of Software Engineering, McGraw-Hill, 2002.
• Roger S. Pressman, Software Engineering, 6th ed., McGraw-Hill, 2005.

Additional software engineering resources
 

1. Condensed Crash Course on C++
2. An Intro to Concurrent Versions System (CVS)
3. GUI-Based Programming
4. System Design
5. Brief Overview of UML Diagrams with a Simple Example
6. Design Patterns
7. User Interface Design
8. Software Life Cycles
9. The Cathedral and the Bazaar:  A Look at Open-Source
10. Repetitive Strain Injury (RSI)

Project organization

Students are divided into groups to develop different components of the application.  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 compiled executable (via email to both the professor and the grader); a system design document (hardcopy and CVS); and a summary of the work done including a detailed task list with the responsible individuals, estimation times, and completion dates (hardcopy and CVS).  The latter two documents should be named sysdesign?.doc and summary?.doc, respectively, replacing the ? with the milestone number. (The file extension will depend upon which word processor you use; any reasonable choice is acceptable.)  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.

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) 2007 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
   (Or, if you're working on a Clemson DCIT Windows machine and do not have permission to install software, then copy the file wincvs-postinstall.zip (the resulting install directory) to your U: drive and unzip it)
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*****
   • 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 2007), class/seebreeze (Spring 2006), or class/rootfly (Spring 2005).

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

1. 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.
2. 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

Paper / Presentation

Each student will independently investigate some topic of software engineering. Topics may include, but are not limited to, methodologies, case studies, overviews, and/or tools. Students are required to write a short report (ECE 417:  at least one page with one reference; ECE 617:  at least three pages with three references) and give a brief oral presentation in class.  Some suggested resources are

• International Conference on Software Engineering
• IEEE Transactions on Software Engineering
• IEEE Computer Magazine
• Roger Pressman's Software Engineering Resources

Individual assignments:

• HW#1: 
  • 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 function int Add(const std::vector<int>& a) that adds all the numbers in a standard 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_exe (This is the precompiled executable, but with the extension renamed so that it is not blocked by the email system). 
    • 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/spring2007' directory of the CVS respository.

Group assignments:

• Milestone#1
  • As a class we will be producing a software design document.  The purpose of this milestone is to create an initial draft of the document, capturing our understanding of the current system, as well as our plans for the system we will build.  Students are encouraged to provide as much detail as possible regarding their aspect of the system.  To this end, UML diagrams (e.g., sequence diagrams, use case diagrams, class diagrams, statechart diagrams, and/or activity diagrams) and/or scenarios, etc., should be utilized whenever possible.  Each group is responsible for one section of the document, with a view toward integration at a later time.  Sections should be written in Microsoft Word.
    • Section 1:  GUI / user interface (group 1)
    • Section 2:  Root data structures (group 2)
    • Section 3:  File format (group 3)
    • Section 4:  Controller, as in Model/View/Controller (group 4)
  • Please upload your document into the cvs repository under class/rootfly/spring2007/doc/sdd?.doc, with the ? replaced by the section number.   
• Milestone#2
  • GUI group:  basic application that compiles, all the widgets drawn on the dialog with stub handlers; load and display an image.
  • Data structures group:  Basic implementation of all the data structures.
  • File format group:  Specification of file format, and ability to load/save a subset of the data structures.
  • Controller group:  Controller framework in place.
• Milestone#3
  • GUI (group 1):
    1. resize window
    2. store size of thumbnails and size of buttons, etc., in data structure (user preferences)
    3. allow user to navigate tube, window, session with up/down buttons and by typing in the edit box (need to handle return key press -- override OnOk and check using GetFocus)
    4. during navigation, display main image, thumbnails, and all roots in root data structure; also be sure to send current tube, window, and session to the data structure.
    5. add root should allow user to draw polyline, doubleclick specifies diameter, store in data structure
    6. display session date
    7. dialog for selecting between image file formats (Bartz, etc.)
    8. display help file using Help menu
  • Data structures (group 2):
    1. rename rootflydata to something easier to remember
    2. separate user settings from temp data
    3. save settings in registry (be careful here!) -- see help on AfxGetApp, GetProfileString, GetProfileInt, WriteProfileString, and WriteProfileInt
    4. in temp data, provide structure for storing cached images
    5. in temp data, store file info for current image -- everything in Bartz format (e.g., session date, user initials)
    6. data structure for image file format, along with function for producing image filename from format and tube, window, and session
  • File format (group 3):
    1. Load / save new file format
    2. Load old file format, and convert data structure
    3. Develop test routine to compare data structures
    4. If user tries to load future file format, display notice indicate need to update version
  • Controller (group 4):
    1. Provide wrapper functions for changing data structures
    2. Develop complete list of expected notifications (as enums)
    3. Send notifications to observer when changes are made
  • Documentation (group 5):
    1. Write help file (.chm) for program, based upon your understanding of the expected functionality
    2. Police the documentation and coding standards of the source code
• Milestone#4
  • GUI (group 1):
    1. resize window
    2. store size of thumbnails and size of buttons, etc., in data structure (user preferences)
    3. allow user to navigate tube, window, session with up/down buttons and by typing in the edit box
    4. during navigation, send the new current tube, window, and session to the data structure; let the data structure update the images; then display main image, thumbnails, and all roots in root data structure using redraw function.
    5. set the range of the spin buttons to a very large number (e.g., 9999).  We won't be using them in this version.
    6. add root should allow user to draw polyline, doubleclick specifies diameter, store in data structure
    7. display session date
    8. dialog for selecting between image file formats (Bartz, etc.).  Write ImageFileFormat class with a GetImage method that looks on the disk for the image with a given tube, window, and session given the file format specified by the user; either return the image or false, indicating that the image could not be found.  Also write a method that parses a given filename into a structure (e.g., getting the date from the Bartz filename).
    9. file -> new allows the user to specify the directory for the images and to begin annotating them.
  • Data structures (group 2):
    1. store unique id with each root (unique per window in each tube)
    2. add string tag for window, session (?)
    3. rearrange code in .cpp file so that file reading/writing is separate from other code
    4. provide more uniform and descriptive comments
    5. tag iterator
    6. image cache should automatically update itself whenever the current tube, window, session changes.  Should use the ImageFileFormat class.
    7. save settings in registry
    8. implement clear methods for experiment and temp data; also provide a method to clear everything in an experiment except the filename format
  • File format (group 3):
    1. Load / save new file format
    2. Include root id
    3. Load old file format, and convert data structure
    4. Develop test routine to compare data structures
    5. If user tries to load future file format, display notice indicating need to update version
    6. Thoroughly test implementation and document the testing plan.
  • Controller (group 4):
    1. Continue to provide wrapper functions needed by GUI
    2. Clean up any functions added by others out of necessity
  • Documentation (group 5):
    1. Complete help file (.chm) for program
    2. Rearrange help file to make it more user friendly.
    3. Check in source files for help file, along with a readme file explaining how to build it, so that others can make changes in the future.
    4. Continue policing the documentation and coding standards of the source code
• Milestone#5
  • The goal of this milestone is to produce a working, integrated version of the software.  The robustness of the application should be tested and ensured, and the functionality should be advanced in moderate ways.  The application should contain the basic functionality of  version 1.0.3 of the software:
    • The user can start a new experiment (File -> New), load an existing file -- either old or new file format (File -> Open), save the current file (File -> Save), save the file changing the name (File -> Save As), export the data to a .csv file (File -> Export), and exit the program.
    • The user can create a new root (Edit -> New Root), and delete a root (Edit -> Delete Root).  The user can change the image directory (Edit -> Change Image Directory).
    • The user can navigate tube, window, and session, with the image and thumbnails displayed correctly (quickly, with no flickering).
    • The user can select a root, which causes its properties (root id, diameter, length, color, state) to be displayed.  The user can also extend the endpoint of a root (Edit -> Extend Endpoint), move a point in the root (Edit -> Edit Points), and change the diameter.
  • The program should also contain the following extensions to version 1.0.3:
    • The user should be able to change the image file format via the dialog, and the program should work for all the known file formats (see OptionsDlg.cpp).
    • Display the session date.
    • A useful help file should be displayed (Help -> Contents).
    • The navigation should be fast, able to work even when the directory contains thousands of images.
  • The following functionality is not expected in this milestone:
    • Register, copy from previous, copy session, select all, calibrate, resize window, zoom, drawing roots that span multiple windows.
  • Students should work in pairs, implementing the pair programming concept.
  • Groups should be self-organized.  At the end of the milestone, each group should email the instructor and grader a task list with time estimates, actual times, and person-pair responsible for each task.  
• Milestone#6
  • The focus of this milestone is upon implementing all of the remaining features from 1.0.3, thorough testing, and code cleanup / documentation.
  • Tasks:
    • New functionality:
      • display roots from data structures
      • select root
      • delete root, extend endpoint, move points in root, change diameter, register (move all)
      • show/hide diameters/dead roots/ids
      • user-defined condition code
      • copy previous
      • move all roots (i.e., register)
      • calibration tool & mm conversion (GUI properties display, Export)
      • update title bar ( * & filename ) and prompt user upon new, open, or exit
      • give user the ability to select the drawing colors (CColorDialog); store these in registry
      • Zoom (2 states - 33%x3, 100%)
    • Bugs and code cleanup:
      • Write and integrate a class ImageToWindowConverter to handle the conversion from image pixels (.rfy,data structures) to "window" pixels (GUI).
      • fix Tube tags
      • Root IDs should be by window, not by Tube
      • use MemDC for all drawing
      • fix double-drawing
      • remove all code from CRootflyDlg::OnUpdate()
      • fix first use of Save (should invoke Save As)
      • functionality in ReDraw() should be broken down into functions
      • ApplicationData should pass parameters by using 'const CString&'
      • ImageBuffer should be used or replaced by the current functions
    • Testing:
      • test different image filename formats
      • test jpgs and bmps
      • test load, save, export, new root, etc., to ensure that user-entered data is not lost
      • test app to ensure no crashing
    • On-going activities:
      • code documentation needs to be consistent and clear
• Milestone#7
  • The focus of this milestone is upon completing the implementation of all of the remaining features from 1.0.3, more thorough testing, and code cleanup / documentation.
  • Tasks:
    • New functionality:
      • Extend endpoints
      • Move diameter
      • Change diameter using either mouse or edit box (as in previous version)
      • Move point on root should work even if mouse is moved quickly (i.e., set mode)
      • 'Delete root' should actually delete the root
      • Dead roots should be drawn with a different color, and should not be drawn at all if 'show dead roots' is unchecked; set root to dead should affect all future instances
      • User-defined condition code
      • Move all roots (i.e., register)
      • Copy previous should allow user to select two sessions, and should give opportunity to copy all tubes, windows, session (as in previous version)
      • 'Edit root colors' should have a dialog box displaying all the current root colors, with buttons to allow user to change them  (Live root, dead root, selected root, root being edited)
      • 'Edit->Change Image Directory' lets user select image directory and image file format
      • Update the help file
      • Draw roots on all three zoomed out windows (but don't allow roots to span multiple windows, and don't allow user to edit the top or bottom window)
      • Display root color (in diameter)
    • Bugs:
      • 'show diameters', 'dead roots', and 'root ids' should be on by default
      • 'New Root' button should never be grayed out
      • User should be able to select root by clicking on circle
      • Points on root should be drawn as small squares (as in the previous version), not circles
      • 'Edit-Zoom out' should be replaced with a 'Zoom out' toggle button on the main window
      • Copy previous should not be grayed out in Session 1
      • Add second parameter to ReDraw() that says whether to call UpdateThumbnails().  Then no one should have to call UpdateThumbnails() directly.
      • (?) Scrollbar page up/down sometimes does nothing (both scrollbars broken)
      • Root ids should be by window, not by tube
      • Thumbnails sometimes not redrawn
      • 'File-New', then 'exit' => app prompts user whether to save changes (should not do this)
      • 'File-Open', then 'exit' => app prompts user whether to save changes (should not do this)
      • 'ApplicationData' should use 'const CString&' for input parameters and 'CString' for return values
      • 'ImageToWindowConverter' should use 'const RPoint&' for input parameters and 'RPoint' for return values (same for CPoint)
      • In 'ApplicationData', add private enum NTHUMBNAILS=5.  Replace magic number 5 with this number everywhere.
      • When no image exists, just display grayed out rectangle instead of 'Rootfly image'
      • 'File-Open' fails if '.rfy' extension is not given
      • 'File-Open' displays extraneous dialog boxes
      • Pixels per mm is not displayed upon 'File-Open' or 'File-New'
      • 'resource.h' should be cleaned up.  Options dialog box should use prefixes to help distinguish items from those on main dialog.
      • 'zoom out' should not redraw thumbnails
      • Bug:  'File-New', choose directory, choose wrong format, prompts for directory again since no images found.  All this is fine.  The problem comes next:  When the user selects a new directory, it uses the format already selected and then complains that no images were found.  But if user selected the wrong format, then there is no way to change it.  Ok or Cancel leads to an infinite loop.
      • 'EnableDisable' should have one line per dialog item
      • 'ImageFileFormat' dialog should
        • not display max length
        • have a separate list box with an 'Add' button, removing the 'include' check box (like the original design)
        • work even if there is a gap between items that are included and those that are not (should be fixed automatically by the previous item)
        • Would it make sense to display the actual filename of one of the images found in the directory?
      • Need bool SpanMultipleWindows() for a root in the data structure
      • Update title bar with name of file and *
      • change TWS in edit box does nothing
      • negative length being displayed
      • Make sure registry still works
      • Ensure file format documentation is up to date
    • Testing:
      • Continued, thorough testing
    • On-going activities
      • code documentation needs to be consistent and clear

Desired Rootfly features/bug fixes:

1. non-Bartz format
2. jpegs and bmps
3. resize application window
4. 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)
5. user-defined condition code (allow for up to two of them); 'Custom'
6. user preferences should be saved (user-defined condition code is specific to experiment)
7. tube name includes transect (if one)
8. move entire root
9. 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?)
   • copy only data for single root (in case user went back to earlier session and added a root that was missed)
   • copy only certain data for single root (in case user went back to earlier session and changed state of root from dead to live)
   • copy data backwards to earlier session (?)
10. select all, move roots (this would replace need for register button)
11. root can span multiple windows
12. keep thumbnails the same size as window is resized; fit as many as we can
13. multiple diameters per root
14. do not allow circle to drag off root
15. allow user to customize colors for drawing roots
16. delete individual points in root
17. display date
18. bug:  when parsing Bartz format, get session directly from the field for session rather than inferring from the date
19. auto-copy session when go to next session; auto-copy window when draw
20. quickjump buttons jumps to the next window, first session with no data (like typewriter carriage return)
21. add scrollbar on left and bottom
22. calibration:  allow user to adjust endpoints
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. store experiment info (e.g., name of experiment) in resulting .csv file
28. allow user to change id of root (?)
29. button on each side of thumbnails allows user to quickly jump to first session or last session (?)
30. stretch goal:  wraparound/panoramic camera
31. goal for next version:  toolbar to replace buttons; would require SDI implementation rather than dialog box
32. next version:  undo

Which group am I in?  Click here for the list of groups.

Instructor: Stan Birchfield, 207-A Riggs Hall, 656-5912, email: stb at clemson
Grader: Nikhil Rane, 219 Riggs Hall, 650-6726, email:  nrane at clemson
Lectures: 2:30 - 3:20 MWF, 227 Riggs Hall