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  
15Ergonomics final system (4/27)

Other dates:

 

Textbook and Resources

Recommended books:

Additional software engineering resources
 

Lectures
  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

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 ur client is Dr. Christina Wells and her lab in Horticulture Department.  Our goal is to to rewrite 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 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.

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)
  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: 

VC++ 6.0

To load macros into Visual Studio 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

 
Assignments

Individual assignments:

Group assignments:

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

Administrivia

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