ECE 417/617 Elements of
Software Engineering
Spring 2010

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 hw01 and ms1 (see below) due 1/15
2 C++ and Visual Studio IDE hw02 and ms2 (see below) due 1/22
3 More C++, object-oriented programming, and CVS hw03 due 2/5
4 Software life cycles hw04 due 2/12
5 Software process and modeling (UML) hw05 due 2/19
6 Project management hw06 due 2/26
7 Agile methods hw07 due 3/5
8 Requirements hw08 due 3/12
9 System design  
10 [Spring break]  
11 Testing hw09 due 4/2
12 Risk analysis hw10 due 4/9
13 User interfaces hw11 due 4/16
14 Formal methods  
15Ergonomics  

Other dates:

 

Textbook and Resources

Required text:

Recommended books:

Suggested readings:

Additional software engineering resources

Lectures
  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)
Project

A main part of the class is a semester-long project in which the entire class participates. The project is written in C++ using Microsoft's Visual C++ 6.0 integrated development environment (IDE).  The code is checked into a central repository using the concurrent versions system (CVS).  This semester our client is Dr. Christina Wells and her lab in Horticulture Department.  Our goal is to to document, verify, test, and extend our open-source Rootfly application which is being used by horticulture researchers.  The code is released under the GNU General Public License.

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

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) -- assuming version 2.0
    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 given to you in class or 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.
  3. Now CVS is ready for you to add your own files, modify them, etc.! 
    1. To add a file (this means to put an existing file under CVS control),
      1. Create a file on your local machine in a directory under CVS control (or move an existing file there)
      2. In WinCVS, navigate to the directory and click on the file.
      3. Click 'Add selected' (the little button up top with the red plus on it)
        Note:  If the file is binary, then click 'Add selected binary', but you should only rarely do this, since CVS is not really designed for binary files.
      4. Right-Click on the file or folder and select 'Commit...', then type in a brief log message and say 'OK'
    2. To add a folder, do the same thing.  However, note that if you add a folder with no files in it, then most people will never see it.  This is because the default for 'Update...' is to "Prune empty directories" (see the Globals tab of the Update popup dialog)
    3. To remove a file (this will remove the file from CVS control, *and* delete it from your local machine),
      1. In WinCVS, navigate to the directory and click on the file.
      2. Click 'Remove selected' (the little button up top with the black 'X' on it)
      3. Right-Click on the file or folder and select 'Commit...', then type in a brief log message and say 'OK'
      4. Note that CVS never actually deletes anything from the server; it just flags it as deleted.  This is so you can retrieve an earlier version later if you accidentally deleted a file.  So if you accidentally added a humongous file, notify the administrator so the file can be actually deleted rather than hogging up disk space needlessly.
    4. To commit your changes to a file (once you are ready to share your edits with other users of the repository)
      1. In WinCVS, navigate to the directory and click on the file.
      2. Right-Click on the file or folder and select 'Commit...', then type in a brief log message and say 'OK'
    5. To update (this will merge any changes that others have committed with your own local copy),
      1. Right-Click on the file or folder and select 'Update...', Click the middle check box that says, "Create missing directories that exist in the repository", then say 'OK'
      2. If CVS indicates a conflict (via a red 'C' next to the filename in the output window), then you will need to resolve the conflict by hand.  Search in the file for "<<<<<<<".
  4. 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, 2009, or 2010), or class/seebreeze (Spring 2006).

For the grader: 

VC++ 6.0

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:

Class Project:

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

For the project, students should:

Rootfly bugs and features can be found at sourceforge

List of desired Rootfly features/bug fixes (somewhat out of date):

  1. Features:
    1. allow user to set default color, live/dead state for tracing new root.
    2. optimize sluggish performance:  sluggish with 40+ sessions, 33 windows, and 36 tubes.  click thumbnail, there is a delay in redrawing.  cache for thumbnails to improve redraw speed.  ImageManager is incomplete.  Need to implement real cache so that we don't have to keep loading images from disk every time we change the tube/window/session.  Also, the current implementation of the class copies the actual image data several times unnecessarily whenever GetImageByOffset is called.
    3. slow 3x3 drawing on some machines.
    4. File.SaveAs does not display a default filename
    5. remember last TWS after exiting program; store in registry or file on disk so that automatically navigates there
    6. 'move root' is missing from the menu / context menu; same for Add / Delete Point 
    7. context menu:  is it possible to replace status.{live,dead} with a single check box?
    8. more keyboard shortcuts
    9. incorporate SessionCollapser to skip empty sessions (in which no image exists)
    10. replace click, move, click with click-n-drag
    11. display zoom factor
    12. remove Debug item from main menu
    13. store experiment info (e.g., name of experiment) in resulting .csv file
    14. 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?
    15. quickjump button jumps to the next window, first session with no data (like typewriter carriage return)
    16. button on each side of thumbnails allows user to quickly jump to first session or last session
    17. autosave
    18. wraparound/panoramic camera
    19. slider for setting autodetect sensitivity
    20. Use dashed line to indicate the part of a root that is not in the primary window
    21. Give user ability to cancel drawing of a new root.
    22. Pane display does not work properly
    23. Click on diameter to resize; should resize immediately rather than wait for the 'mouse move' event
    24. Help file needs to indicate to user that 'copy single root' is an option
    25. Help file should tell user not to put too many tubes in one experiment, to reduce sluggishness
    26. Copy session should check whether session is empty
    27. File.export may want to show the number of days that a root was a particular color
    28. Display variable number of thumbnails along left / bottom as window is resized
    29. Resize progress window
    30. for new roots, default color and condition code should be customizable
    31. Allow a way to delete all old session information, retaining only latest session.  This would help if the .rfy file grew too large.  I.e., allow user to delete everything except for a particular session.
  2. Bugs:
    1. Open .rfy, image dir not right, user has to select new image dir, * should display in title bar to indicate file change (used to work)
    2. Displays root data not only on image, but also to the right of image.  See C:\stb\cvs-local\class\rootfly\spring2010\developer\double-draw-bug (email from Mary on 8/24/10)
    3. If .rfy file has tube "5", the program will convert it to "005" and get confused.  See C:\stb\cvs-local\class\rootfly\spring2010\developer\mary-newbug-Sep01_2010 (email from Mary on 9/1/10)
    4. Progress window:  scroll far to the right, then back to the left => the axis labels become incorrect
    5. Progress window:  refreshing of axis labels is weird
    6. Progress window:  gray out prev / next buttons
    7. When calibrating, user should not be able to draw outside image when zoomed out
    8. Sometimes drawn roots show up in gray area at top or bottom of image (if image sizes are not all the same)

    9. If a root is moved so that it is partially outside its session, the root ID and diameter may be cut off.  They should be moved so that they are always visible.

    10. In 3x3 display, right-click does not display menu in correct location

    11. In 3x3 display, right-click context menu; need to check whether functionality works correctly

    12. Somehow selected root can become deselected while still showing edit boxes.  (I have made this happen in 1.8.35k? by repeatedly pressing the diameter spin control until an assert showed up because no root was selected.)

    13. CopySession does not skip empty sessions

    14. If you Copy... to a particular session, it should automatically set the annotate flag for that session (or not).  Tricky, b/c the right way to do this is probably to set the flag as soon as any change has been made to any root.

    15. .sln file is out of date (.dsw is more recent)

    16. CString::Format("%ws") causes three asserts to fire.  Only occurs when passing a command line parameter (e.g., testing the code or opening an existing file)

    17. Controller::C_SetFilename has these lines of code; doesn't seem like the right solution:
      // Fixes an error in which the save status of a file whose name has been changed
      // will not update save status until changed
      C_SetModify(true);

  3. 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. ImageScanned = ImageAnnotated
Administrivia

Instructor: Stan Birchfield, 207-A Riggs Hall, 656-5912, email: stb at clemson
Office hours:  MWF afternoons, or by appointment
Grader: Vidya Murali, vmurali at clemson
Lectures: 2:30 - 3:20 MWF, 226 Riggs Hall