[Skip Navigation] [CSUSB] / [CNS] / [CSE] / [R J Botting] / [CSE201] / projects
[Text Version] [Syllabus] [Schedule] [Glossary] [Labs] [Projects] [Resources] [Grading] [Contact] [Search ]
Notes: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
Labs: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10]
Mon Apr 29 14:32:36 PDT 2013

Contents

    Notes on Projects for CS201

      Deliverables

      Print out your code, add a Script, staple it, and hand it in.

      Your code must contain your name and a description of the project your are attempting.

      No folders, cover sheets, plastic containers. Just assemble the pieces of paper and staple them together and put it on the desk at the front of class room before class starts.

      Do not worry about nice fonts, heading, decoration, or dingbats. I'm only interested in the text plus occasional diagrams. More important is identifying who you are and what the work is supposed to do at the start of the code.

      Emergency delivery: use EMail and copy/paste your work into your message.

      No copying -- unless you say where you got it. Even so -- check that it is a good solution to the given problem.

      Style

      Keep it simple. Aim for these properties Note: these qualities spell: CREATE.

      Dead Lines

      The deadline in the [ schedule.html ] and are hard time boxed deadlines. You stop and hand in what ever you have got at the deadline even if you did not achieve every thing you wanted to in the iteration. Late work is worth zero.

      Iteration

      An iteration of a project is an attempt at analysis, design, code and tests that can be less than perfect. For most projects in this class you have two iterations.

      Documentation

      Put documentation in the code as a comment unless a diagram is required.

      You should document who you are, what you are doing, and any help you get. Documentation should be included in the source code as far as you can. At the minimum each program must contain comments that identify who did the work and which project the program is tackling.

      You do not have to hand in perfect work ... but you must document any errors (compilation, run-time, etc) so that I can help you fix them.

      1. Say who you are.
      2. State the number of the programming project in the book.
      3. Includes the book's description of the task.
      4. Describes the algorithm or use case you used.
      5. Names any bugs or compile errors.

      Written work

      In 30 years, I have never seen a hand written and untested program that worked. Your code must be input to a compiler to get any points at all.

      Script

      You can make the computer record what you are doing by using the "script" command. We will demonstrate this. Use it to prove that your work is good enough for a good grade. Or to help us find the error or bug.

      On home systems you can probably print a screen shot. On our systems it is easy to generate a record of your compilation and run. The UNIX/Linux Command 

       	script
      records everything you do and what the computer responds to it. It puts the results in a simple text file. This file is called "typescript". It stops recording when you send a CTRL/D character (Hold down the CTRL key and tap the letter D). In our labs the command 
       	lpr typescript
      will print it out. The command 
       	rm typescript
      will remove it. Here [ typescript ] is a sample of the Hello World program being compiled and run.


      (P1): Pick a Programming Exercise from pages 29-30 and write, debug, etc. it. Make sure you program has a comment at the front stating who you are, which exercise you are doing, and what it should do. Start by downloading [ project.cpp ] a "fill in the blanks" program. Hand in what ever you have got by the start of class -- you can resubmit it with improvements if it is less than perfect.


      (P2): Any programming exercise from chapter 2 except P2.22 (done in lab). You can also resubmit P1, if you did not get an A in it. Note: again the program should start explaining who you are and what it does -- copied from the book. Include a Script or screen shot of the comp[ilation and run.


      (P3): Any programming exercise from Chapter 3 that does not need a loop. Programming projects 3.1 thru to 3.13 are suitable. Include the usual Script or screen shot. You can also resubmit P2, if you did not get an A in it. Note: again the program should start explaining who you are and what it does -- copied from the book.


      (P4): Any Programming exercise from chapter 3 that has a loop. Programming projects 3.14 through to 3.30 are suitable. Include the usual Script or screen shot. You can resubmit P3, if you did not get an A in it. Note: again the program should start explaining who you are and what it does -- copied from the book.


      (P5): A programming exercise from chapter 4. Must declare and define at least one function in addition to the main function. It should test the function in the main program. Note: again the program should start explaining who you are and what the function does -- copied from the book. Include a Script/screen-shot showing a compilation and test run. Resubmit P4, if you did not get an A in it.


      (P6): Programming exercise from chapter 5 -- must have at least one class. The main program should declare at least one object in the class and test to see if it works. You can use <cassert> & assert(...) if you like. Your code should start with a comment saying who you are and what the class does. Include a Script/screen-shot showing a compilation and test run. Resubmit P5, if you did not get an A in it.


      (P7): Resubmit P5 with at least one function in a separately compiled file (function.cpp) and only the header file (function.h) included in the main program. The function's file should be compiled with 

       		g++ -c function.cpp
      into a ".o" file and the whole program compiled like this 
       		g++ -o program program.cpp function.o
      Notice -- each file needs your name and its purpose defined in a comment. Include a Script/screen-shot showing compilations and test runs. You can resubmit P6 if you did not get an A.


      (P8): Resubmit P6 (even if you got an A) with a UML diagram that shows every class in the code. You can resubmit P7 if you did not get an A.


      (P9): Simple programming exercise from chapter 6 -- must have vectors or arrays. P9 may star in a question in the final examination. You may not resubmit P9. As before the program must start with a comment with your name, the number of the project in the book, and a copy of the books specification for the problem. Be very careful to make your code do precisely what the book states. If the book asks for a function that does something to a vector you must make sure that you have the function, with the right header, and it must do the right thing with or to the vector, and test it in the main program. Include a screen-shot or Script with a compilation and test run. All the programming exercises involve thought. If you think you have found a piece of code that solves the problem without you thinking about it you will almost certainly lose points. You can resubmit P8 if you did not get an A.

      How to get a bad grade

      Rushing to print out the work at the last minute and arriving late is likely to cost you all the points. Aim to get the work done the day before class. Stroll in looking cool with your work...

      Deliverables

      Hand in a print out of the source code of the programs. Print, staple the pages, and hand in. No cover sheets or folders. Note: all source code should start with the identifying information. 
       		/* Author: A Student
       		   Programming exercise P6.1
       		   Write a function
       			double scalar_product( vector <double> a, vector <double> b)
       		   that computes the scalar product of two vectors. The scalar product is
       			a0*b0 + a1*b1 + a2*b2 + ... a[n-1]*b[n-1]
       		*/
      In an emergency you could send the code (ASCII/.txt) with a subject like these 
       	cs201/P1
      to my college EMail address. Copy and paste the code. See [Contact] at the top of this page.

      Start Early!

      Look for this file on the CS201 web site: [ project.cpp ] as a starting point. Download and/or save it. Edit in your name. Use it to get started on each project. All the projects in this class can start form this file.

      Grading

      To get full marks you need to submit some code that has been checked by the compiler, run, and tested. Include a Script or screen shot of the compilation and test run. You can get some points for code that is less than perfect.

      There is absolutely no extra credit given for choosing a difficult project. Good programmers do not let their ego make things difficult for themselves: always do the simplest thing that can possibly work.

      Advice for Project Work

        Compiling and running projects

        Compiling project code can be done by hand in a terminal window as shown in the classes or using the techniques demonstrated in the labs. Avoid using any software that costs you money.

        In a terminal window

          Simple programs can be compiled run and tested with a single command on our computers: 
           		Q p1.cpp
          if the code is in file p1.cpp in your current working directory.

          On other systems you may have to do the steps in 'Q' by hand: 

           		g++ -o p1 p1.cpp
          will compile it and 
           		./p1
          will run it. You can repeat the last compilation by typing 
           		!g++
          into a terminal or use the arrow keys.

          Or, for more complex projects with code in many files, you can create a Makefile by using any UNIX editor that contains lines like this 

           test: p1
           	./p1
           p1 : p1.cpp
           	g++ -o p1 p1.cpp
          (be careful to use the <Tab> key to indent the commands. Then the command 
           		make test
          will update p1 and then execute it for you. See [ make.html ] for details.

        Warning -- Do It Yourself

        You can ask the teachers for help. Anything that looks like another student's work or a file downloaded from the Internet is likely to get a score of zero (0) for plagiarism. We have several tools that spot files copied from the Internet.

        Each project is matched with an examination. In the examination you may have to answer questions about your latest project.

        Recently, in CS201, someone desperately downloaded code from the internet that sounded like it might solve the problem. It did not. It got zero.

        Again, in a recent Comp. Sci. course, one student got some code from his brother at another university and then let six friends copy it and make small changes. Six students handed in six variations of the code. It was a solution to a different problem. They all got zero.

        Recently a student looked on Stack Exchange and thought he/she had found a solution to the problem. In fact, the question was different to the programming problem in the book. So he/she lost some points. If they had not told me where they got it I would have given it zero.

        University Policy on Plagiarism

        Please read page 53 of the catalog.

        Do's and Do not's for Projects.


        1. Put your name and the project vision as a comment in the code.
        2. Download this file [ project.cpp ] as the starting point for a project.
        3. Do the simplest thing that can possibly work.
        4. Look out and take note of any productivity and quality tips I mention in class or that are in the book.
        5. Put most of the documentation as comments in the code.
        6. Explain how a user uses the program -- what do they do and what do the get out of it.
        7. For complicated steps: write an algorithm (as a comment) first and then code it.
        8. Use variable and function names that say what their purpose is.
        9. No spelling errors in variable names, outputs, or comments. gedit can check spelling for you.

        10. When you get to functions: use [ function.cpp ] as an outline with comments defining the function.

        11. When you get to classes: use [ class.cpp ] as a model and outline.

        THINK. If you rush into code and patch it until it works you may score less than someone who takes time to think about the problem and possible solutions before writing the code. You can make notes using an editor. Start with: What are inputs and outputs? and/or the givens and goals? and/or the before and after conditions? How are these connected? Make notes on this analysis of the problem. What are some possible ways of solving it (designs or algorithms)? Choose one. Turn your notes into comments at the top of a program.

        Make it Meaningful. It is up to you to use meaningful identifiers and comments that make it clear why the code is going to work. Do not hand in a separate algorithm or structure chart. Instead your file should include comments that show the design. A function definition should start with a comment saying (1) what it assumes and needs, (2) what it produces or guarantees, plus (3) a very brief algorithm. Make it clear and correct before you make it fast. Check all code before I grade it. If you have a bug: Add comments about the symptoms... remove the comments when fixed. If I find uncommented errors you will loose points. If I find things that I ca not understand then you will also loose points.

        Most Errors occur when people (1) misunderstand the problem, (2) think of efficiency before correctness. Real problems are not obvious and are not clearly specified. The descriptions of the programs in the book are like this. There are several different programs that will fit what the book asks you to do. I leave the interpretation of them to you yet: (1) K.I.S.S. (= Keep It Simple!). (2) Demonstrate the features and topics described in the book and course at that time. (3) If in doubt A.S.K. (= Always Seek Knowledge). (4) Document (in comments) how you interpret the problem(Analysis)

        Always Seek Knowledge (ASK)

        I expect you to come and talk to me or other teachers about projects. You should be careful about talking to other students, however. They do not know enough to give you good advice. Also beware searching the Internet -- you'll probably find a solution to a different problem.

        Document It As You Go

        Real problems do not have obvious solutions. Whether you know what the code will look like or not add a comment that says what the program must do. Copy the description in the book. This may give you an idea. If not, think up a special case that you can see how to solve. Use comments to describe the special case and how it is solved. Make it compile! Add a simple output to see if the algorithm will work -- nothing else. It will probably have errors. This is normal. Declare variables and recompile and test. Add initial values. Test until it runs. Add comments describing an algorithm. Write code implementing the algorithm. Test.

        Divide and conquer

        Develop code in small iterations. Tackle one complication at a time. Test and retest. Rerun the previous tests.

        Do not let the sun rise on bad code!

        When the current version passes all tests, look for ways to re-factor code. For example use the DRY ( Do not Repeat Yourself ) rule to spot code that can be put in a loop or functions, etc.

        Stop!

        Stop before you are about to run out of time or when it does every thing that the book asked for.

        How to Fail a Programming Assignment

        Carol Edmondson at the University of Tasmania has documented the following techniques students have used to fail her courses:
        1. Do not submit the assigned work.
        2. Submit the work late.
        3. Submit the same document as your friend.
        4. Submit something you found on the web.
        5. Use Email/News/etc to invite someone else to do the work for you.
        6. Collect random pieces of code and put them in a file.
        7. Submit a program that does not compile without comment.
        8. Submit a program that produces a run-time error without comment.
        9. Submit a program that only works on the given tests.
        10. Submit a program that does not meet the specification without comment.

        Any of the above can loose you points.

      Working at home with SSH access

      You can work at home but do not spend money on a C++ system. (1) We require work to be work with the free and standard Gnu C++ system. (2) The expensive stuff adds complications to your code for no added value. The department and the Computer Science Club can provide you with software if you ask.

      Security -- know your password well

      If you mistype your password three or four times your remote machine will be blocked because it looks like someone is using it to break into your account. If this happens go, in person, to talk to the system administrator.

      Remote Access from Windows. You can access our system by using a Windows program called PuTTY -- it is free and easy to find on the web. It pops up a terminal. Connect the terminal to 

              jbh3-1.cse.csusb.edu
      (Port is 22). and log in normally. Remote access from Macintosh or Linux. Open a terminal and use the ssh user-id@jbh3-1.cse.csusb.edu command.

      Remote compilation. For security reasons you can not compile programs on "JBH3-1". You must access a lab machine from JBH3-1. You then will need to login to a lab computer like this 

       		ssh jb359-10
      or 
       		ssh jb358-10
      (you can use any of these machines from JBH3-1).

      You will not be able to do graphic programs or use the GUI to make things easier. A key rule:

      1. Tap Enter to end each command!
      The following UNIX commands work well:
      Table
      CommandPurpose
      cat >fTo upload or input a file called f. You can type in the code or copy/paste it from your machine. End with Enter and Control/D
      cat fTo display the file f on your screen.
      g++ -o p p.cppTo compile a program called p
      ./pTo execute/run a program called p in this directory(.)
      make tto follow a recipe in Makefile to make t
      cd dto change working directory (folder) to d
      pwdto print working directory
      ls to list the file names in this directory
      file * to display info about the files
      mkdir dto make a directory called d
      more fto display a file f one screen at a time
      rm fto remove a file (dangerous....)
      mv f nto change name to n, or move f to another directory
      cp f nto copy f to file n
      nano fto edit a file called f (easy to use but not powerful)
      vi fto edit a file called f (powerful but not easy to use) [ vi.intro.html ]
      emacs fto edit a file called f (powerful and I can not help with it)
      lynx uView a web page with URL u while on JBH3-1.
      links uView a web page with URL u.
      w3m uView a web page with URL u.

      (Close Table)

      What makes a bad programmer bad

      [ 240001941?cid=DDJ_nl_upd_2012-06-12_h&elq=5405b6c46d5848ab89b744c87c2b80d7 ]

    . . . . . . . . . ( end of section Notes on Projects for CS201) <<Contents | End>>

    Abbreviations

  1. Algorithm::=A precise description of a series of steps to attain a goal, [ Algorithm ] (Wikipedia).
  2. Class::=A description of a type of object that includes the data it knows and the functions it can execute.
  3. Function::programming=A selfcontained and named piece of program that knows how to do something.
  4. Gnu::="Gnu's Not Unix", a long running open source project that supplies a very popular and free C++ compiler.
  5. OOP::="Object-Oriented Programming", Current paradigm for programming.
  6. Semantics::=Rules determining the meaning of correct statements in a language.
  7. SP::="Structured Programming", a previous paradigm for programming.
  8. Syntax::=The rules determining the correctness and structure of statements in a language, grammar.
  9. Q::software="A program I wrote to make software easier to develop",
  10. TBA::="To Be Announced", something I should do.
  11. TBD::="To Be Done", something you have to do.
  12. UML::="Unified Modeling Language", industry standard design and documentation diagrams.
  13. void::C++Keyword="Indicates a function that has no return value".

( End of document ) <<Contents | Top