Problem Set 4
Due: 4:30PM, Friday March 15, 2002
Problem 1: Recursion [15%]
The machine languages for many small microprocessors do not have a multiply
instruction. A reasonable algorithm is to multiply by repeated addition, but with some
intelligence. For example, to multiply 17 by 12, first add 17 three times, then add the
result, and then add the result again.
Write a recursive algorithm to quickly multiply one integer number by another without
using a multiply operator. You can arbitrarily choose whether to use the first or
second number as the multiplier, i.e., the number that controls how many additions
are done. (It’s probably a good heuristic to use the smaller number as the multiplier.
Can you see why? Should you do the swap in the calling program or in the recursive
method; how often would the swap be invoked?)
Use JOptionPanes to receive the input numbers. Remember, you cannot use the
multiplication (*) operator anywhere in your program. Your method must be fast; you
cannot just add one of the numbers repeatedly. It should be able to multiply, say,
49,783 by 41,976 using about 25 additions.
(On an actual small microprocessor, you would not leave the implementation in
recursive form; there are mechanical ways of translating recursion to iteration, and
you would, in this case, use an iterative algorithm. It would be based on the recursive
solution that you're writing.)
Testing: Test with negative numbers and zero. You don’t have to consider large
numbers or overflow.
Problem 2: Telecom network management [85%]
Problem description
Telecom network management systems display the status and performance of a set of
telecommunications devices in a network. You are going to write a very simplified
subset of such a system, but it captures the key software ideas upon which these
systems are based. The system will display a common set of status and performance
indicators for each device, but there are also device-specific variables that should be
displayed and managed for each. Also, the network management system must be
extensible so that, as new devices are designed and implemented in the network,
their status and performance can be displayed without rewriting the network
management system.
The devices and their characteristics are listed below. You don’t need to research the
meanings of these; the problem statement provides sufficient information to complete
the program. The failure rates are overstated by several orders of magnitude so that
are likely to see some failures when you run your program with a small number of
devices.
All telecom devices in your system will have four common fields:
Each device has a unique number as its identifier. You should generate the ID number
using a static variable to keep track of the next device number.
Each device has a Status attribute: Active or Failed. These are initialized to ‘Active’ but
become ‘Failed’ when a failure occurs. You must set the status back to ‘Active’
manually through keyboard entry if they are failed, as described below. In an actual
network management system, a console window would be opened to the device so
that tests could be run, settings changed, and any problems resolved. In this
simplified version, you’ll simply type in the device ID and the problem will go away!
Each device has a functional type: it can be:
an access circuit, which connects a business (MIT, for example) to the longhaul telecom network
a switch, which connects access circuits to long-haul circuits
a long-haul circuit, which connects switches to other switches
Each device has a specific type. In our example, we only have two device types: a T1
circuit and a fixed wireless (FW) circuit. Both of these devices are access circuits,
which connect a site (business or research) to the long-haul network. A real system
would have hundreds of device types in each functional type (such as DSL, dialup
modem circuits, ISDN, etc.)
The figure below shows an example of a telecom network connecting labs in 4 universities,
showing the access circuits, switches and long haul circuit.
We will model only access circuits in this homework, but we want to have a general
TelecomDevice class to allow us to extend our network management software to
handle other kinds of devices, such as switches, long-haul circuits and the like. The
logical hierarchy of devices that our network management system must support is
shown in the figure below. The 4 entities we model in this homework are in bold; the
others are shown to illustrate how the system must be extensible and must support
varied devices. (Don't worry about the acronym definitions.)
The two types of access circuit in this homework are:
1. T1 circuit . This has the following attributes:
a. Number of channels: 24
b. Signaling: “CAS” or “PRI”
c. Nominal and actual bandwidth= 1.5Mbps always
d. Error rate: uniform random between 0 and 12 bits per 1010 bits
e. Failed status when error rate > 10 bits per 1010 bits
2. Fixed wireless (FW) circuit. This has the following attributes:
a.
b.
c.
d.
e.
f.
Number of channels: 2
Technology: LMDS, MMDS, NB (not the same as T1 signaling)
Nominal bandwidth: 64kbps
Actual bandwidth: uniform random between 0% and 100% of nominal
Error rate (uniform random between 0 and 100 bits per 106 bits)
Failed status when error rate > 50 bits per 106 bits or when actual bandwidth
< 8 kbps (LMDS) or 16kbps(MMDS) or 32kbps (NB)
Assume that fields in common between T1 and FW would be common across all access
circuits. For example, both T1 and FW have channels, error rates, etc.; you may
assume that all access circuits have channels, error rates, etc. (There is only one
variable specific to T1 and one to FW in this homework.) This is a typical modeling
problem when designing a network management system: the devices you manage are
made by many different vendors and have many different characteristics, and you
must decide which are common and which are device-specific, including your best
guess of devices of this type that are not yet invented! If you guess well, you won’t
have to change your system when they arrive.
You should design the classes in your program to form a hierarchy. The base class
should be called TelecomDevice and the other classes should inherit from it. You must
decide if TelecomDevice is abstract or concrete. (Does it make sense to have a
TelecomDevice object?)
The classes that immediately inherit from TelecomDevice may need to be abstract
also.. (Again, does it make sense to have an AccessDevice object?) While in this
problem set there is only an AccessDevice class, in general there will be
LongHaulDevice, Switch and other classes. You should place each field and method at
the highest class in the hierarchy (TelecomDevice, then AccessDevice, then T1 or FW)
that makes sense.
Finally, the classes that inherit from AccessDevice, T1 and FW, must be defined.
Program
Once you’ve decided on your general approach, and have taken an initial pass at
defining your classes, methods and fields, along with inheritance relationships, there
are some detailed issues that you must address:
TelecomDevice class:
1.
2.
3.
4.
Constructor. Should set the private variables of the TelecomDevice class. These will
be instantiated when a concrete class (T1 or FW) is instantiated, but TelecomDevice
must have a constructor that its derived classes can call. The constructor can set the
ID (a tiny bit of logic is required) and can initialize the status to ‘Active’ if desired; a
computeStatus method in derived classes will reset the status.
You will need several getXXX() and setXXX() methods so derived classes can get and
set the TelecomDevice fields. All fields in all classes in this homework should be
private.
You must have an abstract method called computeStatus. This will require each
derived class to implement a method that determines if the device status is active or
failed. You cannot implement this method in TelecomDevice, obviously.
You will find it convenient to have a PrintData() method that can be called by the
derived classes to output the TelecomDevice fields.
AccessDevice class:
1.
You need to decide which fields go in the AccessDevice class and which go in the
specific devices such as T1 or FW, as noted above. All fields are private.
2. Constructor. As usual, but you must set the functional type field in the
TelecomDevice. Invokes superclass constructor.
3. Write a computeStatus() method, which can be the default for access devices. Most
access devices’ status will depend on error rate and error threshold only.
4. You will probably need one getXXX() method so that derived classes can compute their
status.
5. You will again find it convenient to have a PrintData() method.
T1 and FW classes: These are quite short.
1.
2.
3.
4.
These will have any fields specific to the class (probably one each)
Constructor. Invokes superclass constructor, setting the arguments for bandwidth,
channels, errors, etc. based on the parameters in the problem statement above. For
any arguments that are random numbers, use Math.random(). For example, if
bandwidth in an FW link is uniform random between 0 and 64kbps, the actual
bandwidth argument is 64.0*Math.random(). When you instantiate these objects, you
will draw the random numbers to characterize them at this instant of time. Your
constructor also sets the type and any private variables.
Write a computeStatus() method if necessary to override the default calculation in the
AccessDevice class
A PrintData() method will be convenient.
Last, you’ll need to write a TelecomTest class with a main() method. Your main
method should:
1.
2.
3.
4.
5.
Create a Vector or array (your choice) of 20 TelecomDevices.
Instantiate 12 T1 and 8 FW devices, and compute their status. Note that their
constructors will generate random numbers for bandwidth, and the computeStatus()
method will generate the error rates randomly. You may choose any value of
technology or signaling; the values can be the same for all objects of the same type
(e.g., all “CAS” or all “LMDS”). Note that, in real life, these would be real devices
reporting error rates and status; your network management system would be getting
this data from the distributed devices. In this problem set, we simulate this process
by drawing random numbers.
If a device is failed, list its ID and status (use System.out.println).
Then, in a loop, display a JOptionPane asking the user for the device ID to clear the
failed status. When the user enters the ID, search through the array or Vector to find
the device and set its status to ‘Active’. Do this until all devices with failures have been
cleared. Again, this is much simplified from the real-world system, but it's the same
overall approach. Use a brute-force search; later in 1.00 we'll learn about more
efficient search methods.
When done, print a message saying all network devices are active and end the
program.
Fear not, gentle software person. The solution to all this is about 150 lines of code,
including comments and white space. This is mostly about figuring out how
inheritance works and how your classes can share many methods and fields. The
solution is fairly short if you think it through first. Discuss the design with your
partner. Talk to your TA about it. You’ll spend time in tutorial sections on this as
well.
A couple of additional notes:
You don’t need to display or use the units (Mbps, Gbps, kbps, etc.) or scale factors
(10x) in this homework. (Your users are experienced, and know the units and scale
factors.) You can model the error rates ignoring the 10x terms, since they cancel. In a
real system, you would handle all these things, but they are not necessary in this
homework.
Use Math.random() to generate the uniform random numbers that you need. See
Javadoc or your text for details.
Turnin
Turnin Requirements
Problem 1: Email only. No hardcopy required.
Problems 2 & 3: Hardcopy and electronic copy of ALL source code (all .java files).
Place a comment with your name, username, section, TA's name, assignment number,
and list of people with whom you have discussed the problem set on ALL files you
submit.
DO NOT turn in electronic or hardcopies of compiled byte code (.class files).
Electronic Turnin
To electronically turn in your problem sets, run Netscape
Then go to the 1.00 web page at:
http://command.mit.edu/1.00Spring02
Click on the "Submit Assignment" button. Be sure to set the Selection Bar to Problem
Set 1 or your files may be lost. Finally, go back to the home page and click on the
"View" section and be sure that your files were received. If you submit a file twice, the
latest version will be graded.
Penalties
Missing Hardcopy: -10% off problem score if missing hardcopy.
Missing Electronic Copy: -30% off problem score if missing electronic copy.
Late Turnin: -20% off problem score if 1 day late. More than 1 day late = NO CREDIT