Course Notes
Computer Engineering

Constructing Projects

  1. Before you start writing code:

    1. You need a project concept, specification, and top-level structure. The concept describes what you want the project to do, who the users are and how they will use the resulting program(s), and a list of any issues you need to think about during development and testing.

      The specification, for a small project, may be a single sheet of paper where you've carefully stated each of the obligations the project must satisfy. This should be complete, unambiguous, and brief. Our Project Statements are examples of small project specifications.

      The top-level structure usually comes from enumerating each of the tasks the program(s) must complete. Often each task has one or more packages that focus exclusively on carrying out that activity. There is usually an executive package that directs the execution of each task in a specific order. The executive should not be concerned with how any task is carried out, but simply on commanding its execution. It is also common to have a set of packages that focus on acquiring program inputs, a set that does the computation work of the program, and a set that organizes and displays the results so that the user sees information rather than program data.

      This is a good time to draw a package diagram and often one or more class diagrams that will help organize the code you write into cohesive parts.

      If the project is complex or implemented by more than one developer you should make a small overall plan, e.g., the sequence in which packages are developed and tested, and you may plan the testing in some detail.

  2. Writing Code:

    1. Pick a package that desn't depend on any others - there almost certainly will be at least one of those, and rough in classes, e.g., write a class declaration, deciding on the method names and data members. This gives you a language to implement more code.
    2. Implement methods one-at-a-time, and test each one with code in a test stub before moving on to the next function.
    3. If there is some functionality you don't know how to implement, then:
      1. Do some research, looking at available code from the college server and the web. You may also find what you need in the libraries provided by the Integrated Development Environment (IDE).
      2. Create another project to try out ideas.
      3. If that doesn't lead anywhere, try refactoring the task you are working on into simpler and smaller activities or rethinking your design approach.
    4. When you're done with this package, pick another, create a new project for the new package, including code from the first if this one depends on that code.
    5. Start by just stealing the previous package's test stub and put it into main (the test stub for this new package).
    6. Now, rough in more classes.
    7. Continue until all the packages are done, testing at each step.
    8. Compile often. Build, run, and evaluate, every time you add a few lines of code. Note the word "evaluate". If your code is not easily readable then try to simplify. If its too complex, then refactor by pulling some of the code into functions this code will call or new classes this code will use.

  3. Testing:

    In these course projects your testing will focus on construction. When you move to industry the testing scope is larger:

    1. Construction Tests:

      This is what you do in each package's test stub, e.g., test as you construct by adding and running tests for each few lines of code you add as soon as you have added the code, e.g., continuously.

    2. Unit Tests:

      Each critical package is subjected to a unit test. Unit tests use one or more separate test drivers that are structured into a sequence of tests, one for each of the program's obligations. The purpose of unit testing is to verify correctness, e.g., that a requirement is met. It is usually conducted with a debugger walk-through and attempts to exercise every path using a rich set of inputs.

    3. Regression Tests:

      The purpose of regression tests are to run a large battery of tests against a subsystem that demonstrate that it operates correctly after a change in one of its packages. You will find an example of a regression test of the FileSystem package here. Usually we support regression testing with a light-weight test harness. You will find one of those, e.g., UnitTest.h, by following the previously cited link.

    4. Qualification Tests:

      Qualification tests are a set of legal tests to ensure that a product satisfies its specified obligations. These should be boring, non-technical tests that correlate program inputs and outputs with each requirement in the project's specifications document(s).

    5. Note:

      You won't do qualification and regression testing for class projects, except for the Software Studio class. But you will do them when you begin working in a professional environment. Working out a solid set of regression tests and a flexible test harness to run them will save you a lot of time when you have to maintain code for more than a few weeks.