This document includes descriptions of what you are to do, comments on the latest posted code, and copies of the state diagrams I handed out in class.

Figure 1. The phone state diagram as of 8/4/98 (handed out in class). In the CodeWarrior project on-line, PS2, I have coded the transitions back and forth between the Quiescent and Picked up states, using random time delays. The programming assignment asks you to do the same for the switch (see below).

Figure 2. The switch state diagram as of 8/4/98 (handed out in class). The programming assignment asks you to code the transitions for the switch between Quiescent and Picked up. This will involve having the phones place pickup and hangup messages in the outgoing lines and the switch monitoring its incoming lines and responding by changing its state. I have done some of the coding. You are to get the two state transitions in the switch working correctly for a collection of phones.

Figure 3. The connector/wire strategy (replacing the earlier links strategy). A connection between two nodes (a phone and a switch or a switch and a switch) is made by placing one Connector object in each node. A Connector object has two slots, in and out, each pointing to a Wire object. Two Wire objects are created and set up as shown. Each Wire object has one slot that holds a Packet (a pointer to a Packet object). This "wiring" is done as part of the constructor for System.

Your Assignment: What you are to do is to add code to the run() method for the switch which is very similar to that for the phone. The switch should scan it's phone states each time it's run (3 of them in the example I did). For each phone it should execute the code corresponding to one of the states Quiescent or Picked up, whichever state it's in. It will be in the quiescent state initially. When looking at a state, e.g., Picked up, it should check the in line for that phone and see what message packet, if any, is there. If there is a hangup packet then the switch should change the state for that phone back to Quiescent. It should delete the packet it just got, because it is not sending it on to any other node, and reset the in packet to NULL. You will not be changing the code for the switches that I've already built. Thus, the phones will pick up and hang up at various times and the switch will notice that activity and change its internal record of the attached phones states. The switch must know each attached phone's state so it will know whether or not it can ring the phone. You are to add cout statements to show that the switch is indeed changing states correctly, in addition to the printouts already installed for the phones.

The result of your work should be a Macintosh Code Warrior project on a Mac floppy plus hardcopy of any files to which you've made significant changes. You must add your name to the Author: field of the file header of any file you change as well as updating other fields such as the Date and Purpose and Modification History and its dates. Hand in your work even if your code does not compile. Paste in the printout from your test(s) at the end of the main.cp file as a long comment, as I have.

Comments -- You must add as many comments as possible to the code that you add or change. Overview comments are the most important, e.g., for an entire function. Line-by-line comments are less crucial and often clutter the code too much.

The basics of everything you need to do are implemented and run in the current version of the code (version frozen 8/8/98, 1:25pm). The system is properly constructed with connector and wires, the phone state array in the switch is in and working, the state changing for the phone between hung up and picked up works, and I have also shown how to place messages in the out lines for the switch and how to change the switch states.

Memory management (notes for later): Packets are the most volatile objects in the system. The nodes and wires are essentially permanent and unchanging in any simulation run. The general philosophy in this project is the notion of source and sink for packets. Thus, when a packet is produced it then moves through the network to some final destination where it is not used further by any object. At this point it can be safely deleted. If an intermediate node wants to retain the information in a packet, e.g., for logging or debugging purposes, it can always create its own copy and copy the information in the packet into its copy. Since we use pointers universally in our implementation, there is only one actual packet object created for transmission and the pointer to it is handed through from node to node to simulate the "movement" of the packet.