Introduction

This describes certain aspects of your project development as well as linking to an example I've prepared for you. Further information can be found on the important Assignments page.

The Demo1 project example

As of 3/31/01 I have assembled a simple demonstration project that includes source code, screen shots and javadoc web pages for a small bit of a simple phone system.

The "Evap" project example

As of 4/3/01 I have assembled a another demonstration project that includes source code, screen shots and javadoc web pages for a small bit of a simple phone system. This project shows how the states of objects are maintained over time, with each system responding to a call to its step() function by checking its state, and possibly initiating a call to another object. The important point is this: To keep the linkage between objects limited and to allow them autonomy, when an object is contacted by another it responds simply be changing its internal state. It only invokes functions in other objects when it is stepped.

The working group arrangements, or "phone companies"

The class will be divided into four groups or "phone companies", each responsible for creating a simulation for the complete system. The lists, with email addresses, will be published and made available to everyone the moment the groups are created. [As of 4/3/01, the groups list has been emailed to all. If you didn't get it, email us.]

How your project work will proceed -- Setting up directories

Your group will have to organize itself, especially by setting up some directories on unix to hold sources and javadoc pages shared by all in the group. Each member of the group will need to have directories for their own work and their own web pages. Below is an example of how you might proceed in setting up the correct directory permissions to make all this work. We'll call the sample students here S1 and S2, with S2 designated to keep the common directories for the group (one of the four groups). The overall strategy is this: You set up certain directories are set up so that only users who know the precise names of files and/or directories contained in them can access them. So the names of the "hidden" inner files and directories can be given to other members of the group and/or the Professor and Teaching Assistant for grading purposes. The file names used below are examples only. Some must be given distinct names in order to make it impossible for others to locate them.

• In your home directory, create a directory called, for example, 1204, using the command
  mkdir 1204



• A directory listing of it via
  ls -l 1204
  will reveal that it has read, write, execute permissions resembling the following:
  drwxr-xr-x



• These should be changed to make the directory unreadable by others, using
  chmod go-r 1204
  which, glossed, is "for group (g) and other (o) remove read privileges (-r). The permissions will now be
  drwx--x--x
  indicating that you, the owner, have read, write and execute privileges, but others only have execute privileges. They cannot see what's in the directory.



• You can now change into the directory 1204 and create your "hidden" directory, giving it an impossible to guess name, such as "k8b5rws"
  cd 1204
  mkdir k8b5rws
  You will be able to add and alter files in it and other group members that know the name will be able to read and copy the files; that's because you haven't changed the default permissions for your inner directory, k8b5rws.



• If you are student S1 you are all set, because you can create new files within k8b5rws and tell other people in your group what your hidden directory name is. Say you created files Phone.java and PhoneState.java in your work. You could put copies of them in k8b5rws and simply tell your group members to check the hidden directory contents, using
  ls ~S1/1204/k8b5rws
  (using not S1 but your real login id) which would return, among other things,
  Phone.java PhoneState.java
  They could also copy those files into their spaces to test, for example their User or Ether classes or to try running the entire simulation system.



• For web pages, a similar strategy could be employed. In your .www directory create a 1204 directory with restricted access and a hidden directory with an unguessable name inside it, e.g., w3xs98u. Copy all your javadoc files into the hidden directory. Then a URL of the following form would access the javadoc files
  http://www.ccs.neu.edu/home/S1/1204/w3xs98u/
  (The web server assumes that it's to look for a file index.html inside the w3xs98u directory, which is exactly what javadoc creates as the "homepage" for your API.) And of course, your real login id would replace "S1" here too.



• You can create any number of unguessable subdirectories and share their names with various group members, teachers, etc. Or you may share the name of a directory with no one, so you could look at your documentation on the web, but no one else could.



• By allowing only read permissions, you prevent people from altering files. Whoever owns a directory (and can therefore write to it) can collect readable files from all the other members of the group, copy them to a single place and compile and test them for themselves.

Go to COM1204 home page

Return to Prof. Futrelle's home page