Due: Monday 01/25 10:00am

Description

  • The final project is to be a significant piece of work that illustrates many of the ideas and techniques studied in the class:
    • Allocating memory
    • Working with files
    • Finding information about files (stat and such)
    • Processes (fork, exec etc.)
    • Signals
    • Shared memory
    • Semaphores
    • Pipes (named and unnamed)
    • Sockets
  • Your project should be able to meaningfully use at least 4 of these concepts. Don’t just toss in a topic if there is no need for it in your project. Part of your design process should include considering how to incorporate the class material.
  • You should also focus on creating a program that works well. It is better to have fewer features in a project that compiles & runs smoothly than to have a lot of features that contain a lot of bugs.
  • When designing your project, it is best to be able to generate a base working project early and then add features modularly as time goes on.
  • You may work with one or two partners, all partners should be in the same section.
  • Project Ideas/Suggestions
    • If you are having difficulty coming up with a project idea, look back at some of the bigger assignments we’ve done over the semester and think about how you can add to them. These are just some ideas to get you going, please do not consider theses as superior to any other ideas you might have.
      • The music library could become much more useful by incoperating a music player (fork/exec), saving the library data (maybe even as a binary file), interacting with actual music files etc.
      • The data file/csv assignment could become a more useful data organizing program.
      • Semaphone could be tunred into a pipe or socket based live game.
      • With pipes/sockets, you could write simplified versions of different kinds of servers.
    • If you are going to write a multi-program system with sockets/pipes, start simply. For example, if you’re making a 2 player game, then just have the programs connect directly do each other, instead of wirting a separate server to connnect them.
    • As stated earlier, it’s better to start small and grow than start large and have to cut things out (or live with bugs).

Proposal - due Wednesady 1/12 8am.

Should contain the following.

  • The names of the people in the group.
  • The class period you are in.
  • A statement of the problem you are solving and/or a high level description of the project.
  • A description as to how the project will be used (describe the user interface).
  • A description of your technical design. This should include:
    • How you will be using the topics covered in class in the project.
    • How you are breaking down the project and who is responsible for which parts.
    • What data structures you will be using and how.
    • What algorithms and /or data structures you will be using, and how.
  • A timeline with expected completion dates of parts of the project.

Proposal Stages:

  • Put together an initial proposal with all the parts that are required in a markdown formatted file.
  • Upload it to github as README.md.
  • When I approve a project I will add an issue to your project repo with further instructions.
  • After that point you can go ahead and work on the project.

Documentation Specifications

  • This is for the final result, you do not need all these files at the proposal stage.
  • In addition to your code files, you will have to include the following documents:
  • makefile
    • This should build the project when I type make.
  • README.md
    • This should be the main README.md for your repository
    • Initially, it will contain your project proposal
    • It should have the following information in the following order:
      • Project Name
      • Team Members and class period
      • Broad description of project
      • List of any required libraries
      • Include apt-get instructions on how to install the libraries
      • Instructions on how to use your project
  • DEVLOG
    • This will contain a running list of updates to the project.
    • Each entry should be timestamped and attributed to the student(s) that contributed to the update, along with a brief description of what was done.

Project Notes

  • You can use any external libraries you’d like, for example, gtk for windowing, sdl for games, etc. but you must do the following:
    • Make sure to mention any libraries in the README where you describe compiling instructions.
    • Check with me to make sure we can install them.
    • Make sure your program will run in the cs lab computers.
    • Make sure they don’t trivialize a systems programming aspect of the project.