We begin by adding a short-term store to our stub model. (Recall that the short-term store was held to be responsible for the Recency effects in free recall.) From the main box-arrow diagram, double click on the "Subject" box to open it. The model needs to contain two boxes representing memory stores, the STS and LTS. These can be implemented as Propositional Buffers. To add the STS box to the diagram, first note the drawing toolbar at the top of the window; it contains a set of buttons representing different box types, and two arrow types. Click once on the leftmost button (the one showing the letter P within a round-cornered rectangle), then click on the diagram canvas. A Buffer box, annotated with a P in the top right corner, will appear on the diagram, highlighted in red. Below it, there will be a text field, into which you should type the name of the box, in this case "STS", as illustrated below:
Clicking outside the text input field or pressing <CR> will close the input field. Next, we need to link the "Input/Output" process to the STS buffer, to allow the "Input/Output" process to store the incoming words in STS. For this we need a Send arrow. Select the appropriate arrow type (by clicking on the leftmost of the two arrow buttons on the drawing toolbar). Now click on the "Input/Output" box, and, without releasing, move the pointer to the "STS" box -- an arrow attached to the "STS" box will follow the mouse pointer -- and release the button. The diagram should now look like this:
We are now ready to add a rule to the "Input/Output" process that will transfer incoming words to STS. Double-click on the "Input/Output" process box to open it, and view the "Initial Contents" pane. Under the "Insert" menu select "Rule"; a new window will open. This is the Rule editor, and we are going to use it to create a rule which will write each incoming word from the Experimenter into the STS buffer.
First, check the "Rule is triggered" checkbox. This indicates that this rule responds to trigger messages such as those sent by the Experimenter. The "Trigger pattern" field, previously greyed out, will become active. You should type the trigger pattern word(X) in it. (Make sure you capitalise the X inside the brackets, but not the word outside.) Next, pull down the "Add Action" menu, and select the "add" item on the menu. A new entry under the Actions part of the window will appear. This entry has two boxes. In the left box, type the letter X (again capitalised -- it refers to the same variable as the one in the trigger pattern). The right box offers a selection of names of other boxes (the ones to which it is possible to add items). From these, select "STS". Finally, in the box at the top labelled "Comment", type a comment to explain what the rule does -- such as "Add incoming words to STS". The rule editor window should now look something like this:
This rule will be triggered when elements of the form word(X) (where X is a variable) are received by the Input/Output process. (Recall that the Experimenter sends a series of such messages when during an experimental trial.) Whenever the rule is triggered, it will add an element (whatever the X happens to correspond to) to STS.
Now you can close the rule editor window. At this point the model is actually able to do something: for each incoming word, it will be copied into the "STS" buffer. To test it, open the "STS" box, and select the "Current contents" view. Now click the "Initialise" and then the "Execute one trial" buttons. A list of words should appear in the window. Initialise again, and single-step for a few cycles. You will see that words are appearing (and accumulating) once per cycle. (Note that nothing will appear until cycle 3. On the first two cycles the words are generated and feed to the subject.)
Now as was mentioned before, in the Modal Model, STS is supposed to be capacity-limited, with a span of about 7 items. Switch to the "Properties" view of the "STS" box -- you will see a list of property names and their associated values. Find the "Limited Capacity" property and set it to "Yes". This works in conjunction with the "Capacity" property, which should be set to 7. At this point, also find the "On Excess" property and set it to "Oldest". Now return to the "Current Contents" view, reinitialise and step through the trial again; you will see that the number of items in the STS buffer grows until it reaches 7, after which point new additions to the buffer over-write existing elements -- in this case the oldest element is always the one to be replaced. Return to the properties view, change the "On excess" property to "Random", and again step through the trial, viewing the current contents. This time, when the capacity limit is reached, a randomly selected item is over-written by each new element.
Now we can add a recall facility to this memory system, allowing the model to perform the memory task. Return to the Subject box-arrow diagram, and add a Read arrow from Input/Output to STS. It should look like this:
To add a rule to respond to recall requests, open Input/Output in "Initial Contents" view, and select "Rule" from the "Insert" menu. The rule editor window will open. This rule will respond to the recall trigger, so you should enable this, as before, by checking the "Rule is Triggered" box and typing recall in the "Trigger Pattern" field. Now, when triggered by the recall message, the rule should read the words it remembers from memory (currently, just STS), and send them to the Experimenter. In the rule editor window, select "match" from the "Add Condition" menu. A new entry will appear in the "Conditions" section. In the left field, type Word and in the right field, select "STS". Now from the "Add Action" menu, select "send", and in the left field, type recalled(Word), then in the right field, select "expter process". Now the rule should look something like this:
Now close the rule editor window, and return to the graph display in the graph package. Click the "Initialise Model" button, then click the "Execute one trial" button. After a few moments you should see a jagged pattern representing recall in a single trial. But we can do better than this -- pull down the "Run" menu, and select "Options". A window will open, showing run options. In the "Trials per block" field, change the value to 20. Now close the window, and return to the graph display. Initialise again, which should clear the screen. Now click the "Execute one block" button. This should run 20 trials in sequence, and every few seconds you will see the graph display updating. After 20 trials, it might look something like this:
This certainly looks quite like a recency effect, but there is of course no primacy effect; the probability of recall just drops as items get older. If you have the time, you might like to experiment with this model some more before going on to the next section. Here are a few suggestions: