Carleton University, Dept. of Systems and Computer Engineering

           94.586 Object-oriented Design of Real-time Systems 
                     Winter 2001.. C. M. Woodside

Assignment 1: StateCharts and Call Processing Behaviour..... Due date Feb 1 2001
================================================================================
1. Using StateCharts and the Rose RT tool, design the behaviour of a POTS Originate object similar to the one considered in class, and two driver objects, one representing the Originating CPE Interface, and one the Network, so they will carry out the following call setup scenario O1:

Scenario O1: Successful call origination, ended by originator going on-hook 1st
===============================================================================
OrigIF			Originate			Network
	localOffhook>
	<setDialTone
	<collectDigits
	digits>				requestPath>
					<pathAvailable
	<setRingTone
					<remoteOffHook
	<endRingTone
----------------------------[connected]-----------------------------------------
	localOnHook>
	<setDialTone			remoteOnHook>

(a) paper design of the three state machines. Use a time delay to control which end goes on-hook first to terminate the call.
(b) Rose RT prototype
(c) run the prototype with sufficient logging to verify the  message sequence and the state sequence.
(d) modify the driver objects so the Receiver goes on-hook first (scenario O2)
(e) modify the driver objects so the Originator goes on-hook immediately after sending the digits (scenario O3)

ALWAYS DISCUSS YOUR RESULT OR WORK... comment on assumptions, 
limitations, difficulties, possible extensions, concerns. Make it a THOUGHTFUL 
document.


2. In the same way, design the behaviour of a POTS Receive object, with driver objects for the Network and a Receiving CPE Interface, for call setup scenario R1:

Scenario R1: Successful call reception, ended by originator going on-hook first
===============================================================================
Network			Receive			RecIF
	callRequest>				checkBusy>
						<notBusy
	<canConnect				setRingTone>
						<localOffHook
	<remoteOffHook			endRingTone>
---------------------------------[connected]--------------------------------
	remoteOnHook>			setDialTone>
						<localOnHook

(a) paper design of the objects for Scenario R1
(b) prototype in Rose RT and (c) demonstrate by running and logging
(d) modify the driver objects to make the Originator go on-hook immediately after sending the callRequest, and repeat (call this Scenario R2).

3. After these tests, put the two half-call objects together with the two interface objects OrigIF and RecIF using Rose RT (the Network object can be left out as it just passes the message through). Run with logging. Adjust the behaviour of the interface objects to give these scenarios:
(a) OR1, a combination of O1 and R1. (Originator hangs up first)
(b) OR2, corresponding to O2. (Receiver hangs up first)
(c) OR3, corresponding to R2 (Originator aborts after giving digits)
(d) one other scenario of your choice

4. On paper only, describe how you could do the following:
(a) add Originating Call Screening, in which a list of numbers is forbidden for calling
(b) handle a feature which substitutes a # key to mean on-hook, then off-hook (to start a new call),
(c) introduce a simplified version of Call Waiting, which 
- gives a CW tone to the busy Receiver, 
- puts the caller on hold, 
- connects the CW caller when the first call ends
- rings the Receiver if he/she hangs up, to connect the CW caller