Tackling Large Projects

Diomidis Spinellis
Department of Management Science and Technology
Athens University of Economics and Business
Athens, Greece

Design and Implementation Techniques

FreeBSD 5.2 Release Policy

Subject: 5.2 is coming!!
Date: Wed, 7 Jan 2004 23:57:22 -0700 (MST)
From: Scott Long <scottl@FreeBSD.org>
To: developers@FreeBSD.org


We've delayed quite bit while install problems and various show-stopper
bugs got fixed.  I think that it's safe to say that we are getting
pretty close to closing the door on 5.2 now.  There are still a few MFC
requests trickling in, so I wanted to publicize the policy that needs
to be followed for the remainder of the 5.2 cycle.

First, there can be no 'instant MFCs'.  All 5.2 MFC candidates must spend
at least 36 hours in HEAD before going into RELENG_5_2.  It's fine to
contact re@ after committing to HEAD to state your desire to also commit
to RELENG_5_2, but don't expect instant approval.  I encourage the 36
hours to be used for as much review, testing, and verification as

Unless another show-stopper arises, I intend to tag the tree late
Friday night or early Saturday morning (MST -0700).  In accordance
with the previous paragraph, this means that there are approximately
12 more hours for bug fixes to go in and be 5.2 candidates.  This is
_not_ intended to be a signal for people to start rushing stuff in,
but rather a reminder that we cannot hold the release up for forever.
MFC approval is still at the discretion of the RE team.  After this
cut-off, only show-stoppers will be considered for approval.

While 5.2 will certainly have bugs, I'm happy to hold the release up for
true show-stoppers.  A show-stopper generally is a bug that causes a panic
[crash] during normal and reasonable operation of the OS or prevents the
OS from being installed in a way that is documented, and has no reasonable
work-around.  These bugs must be confirmed by a third party to ensure
that it is a problem that is likely to be reproduced in the user base. It
also includes security vulnerablilities that are published by mainstream
security outlets and have not already been addressed in some fashion.

Thanks a lot!


Directory Structure

Project Organization

Two approaches: Keep in mind: large structures are often very easy to navigate.
The FreeBSD directory structure

Source Code is Not Only Code

Key Processes

Project-Specific Tools

Building the IBM 3270 terminal emulator
Building the IBM 3270 terminal emulator

Debug Messages


Logging offers a number of advantages over using a debugger:


Example (from regular expression engine)
    if (dp != NULL)
    /* uh-oh... we couldn't find a subexpression-level match */
    assert(g->backrefs);    /* must be back references doing it */
    assert(g->nplus == 0 || m->lastpos != NULL);

Assertions in Java


 * Run With java -ea FindMax

class FindMax {

        /** Return the maximum number in non-empty array v */
        public static int findMax(int v[]) {
                int max = Integer.MIN_VALUE;

                // Precondition: v[] is not empty
                assert v.length > 0 : "v[] is empty";
                // Precondition: max <= v[i] for every i
                for (int i = 0; i < v.length; i++)
                        assert max <= v[i] : "Found value < MIN_VALUE";

                // Locate the real maximum value
                for (int i = 0; i < v.length; i++)
                        if (v[i] > max)
                                max = v[i];

                // Postcondition: max >= v[i] for every i
                for (int i = 0; i < v.length; i++)
                        assert max >= v[i] : "Found value > MIN_VALUE";
                return max;

        // Test harness
        public static void main(String argv[]) {
                int t[] = new int[5];

                t[0] = 4;
                t[1] = -4;
                t[2] = 145;
                t[3] = 0;
                t[4] = Integer.MIN_VALUE;
                System.out.println("Max value is " + findMax(t));

Further Reading

Exercises and Discussion Topics

  1. Propose ways to quickly determine whether a given project follows one of the design or implementation techniques we described. Test your proposal against one of the major projects available in the course's reference source code .
  2. Locate recommended design and implementation practices in a software engineering book. Explain how these are reflected in a project's source code.
  3. How can a standardized directory structure be utilized for automating aspects of the software development process?
  4. Examine and describe the directory structure of an installed version of Microsoft Windows.
  5. Configure a program from the course's reference source code to compile and run in a supported environment. Examine the configuration process output files and manually verify four different configuration options.
  6. Read the source code of a configuration script, explaining how two different configuration options are determined.
  7. How do you track revision histories in your environment? If you are not using a revision control system, consider adopting one.
  8. How is the build process managed in your favorite integrated development environment? Discuss the advantages and shortcomings of the employed approach.
  9. Locate two different test cases in the course's reference source code and explain how their execution is, or could be, automated.
  10. The Perl test cases suggest that

    ``A good test case has most of these attributes: fewest possible number of lines; few dependencies on external commands, modules, or libraries; runs on most platforms unimpeded; and is self-documenting.''

    Locate test cases in the course's reference source code and judge them against the above standard.