JHU / CS / 600.120: Intermediate Programming

Assignment 7: Simulating Objects

Out on: March 24, 2008
Due by: March 31, 2008, 3:00 pm (before lecture)
Collaboration: None
Grading: Packaging 10%, Design 10%, Style 10%, Performance 10%, Functionality 60%

Overview

The seventh assignment is where you get to play with C++ for the first time. Woohoo! :-) You'll write a small simulation, one of the domains that object-oriented programming was originally developed for. You'll also return to the database assignment (oh the pain!), but only for a very brief exercise.

Problem 1: Network Simulation (80%)

Your first task is to develop a simple network simulation. Networks consist of hosts which are sources and sinks for communications, as well as links which connect hosts for communications. The network you're simulating is described in the following format (to be read from the standard input):

NETWORK
  Example
HOSTS
  Eins
  Zwei
  Drei
  Vier
LINKS
  Eins TO Zwei
  Eins TO Drei
  Drei TO Eins
  Eins TO Vier
  Zwei TO Vier
MESSAGES
  Eins TO Vier
  Drei TO Vier
END

Take a moment to draw this network on a piece of paper: Hosts are nodes of the graph, links are edges of the graph; edges are directed. While the HOSTS and LINKS sections specify the topology of the network, the MESSAGES section tells you what to actually simulate, namely sending a message from the specified source node to the specified sink node.

The process of transmitting a message from a source to a sink is called routing. There are many different algorithms for routing, the one you should simulate for this problem is called random routing: When a host gets a message, it first checks whether it is the recipient for that message; if so, the message has been delivered successfully and the routing process stops. If the host is not the recipient for that message, it randomly picks an outgoing link (each with equal probability) and sends the message to the host on the other end of the link; if there are no outgoing links (as is the case with Vier in the example above) the message cannot be delivered and the routing process fails. Before discussing more details, here is the output we would expect for a simulation run:

Simulating network "Example"
  Sending message from "Eins" to "Vier"
    Picking link "Eins" to "Zwei"
    Picking link "Zwei" to "Vier"
  Message delivered in 2 hops.
  Sending message from "Drei" to "Vier"
    Picking link "Drei" to "Eins"
    Picking link "Eins" to "Drei"
    Picking link "Drei" to "Eins"
    Picking link "Eins" to "Vier"
  Message delivered in 4 hops.
Simulation ending.

Delivered 2 out of 2 messages, success rate 100%.
Delivery required an average of 3.0 hops.

As you can see, you're supposed to simulate the routing process once for each request in the MESSAGES section. You're writing out information about the routing process as it progresses, and you also keep some statistical information around for the final analysis in the last two lines.

You probably want to write several classes for this problem, at least a Host class that knows it's name and knows all the other hosts it has connections to, as well as a Message class that keeps track of the number of hops it had to take. You might want to introduce a Link class as well, at least if you expect that a future version of the simulation could require more detailed modelling of links and, for example, their capacities.

Finally, note that it is possible, although not likely, that you route a message around "forever" without ever getting to the destination, and without getting caught in an obvious trap (no outgoing links). You should consider a delivery "failed" for our purposes if after 512 hops, you still are not at the recipient; this is sometimes called a "time to live" constraint.

Problem 2: Refactoring the SDBM Interface (20%)

Your second task is simple: Refactor the old sdbm.h C-style interface into a C++ class-based interface. In other words, follow the process we followed when refactoring the C-style stack.h interface into a C++ class-based interface. You do not implement anything as part of this problem, you just hand in a new sdbm.h file that contains a C++ class corresponding to the old interface. You should not change the interface by adding new operations! Simply refactor the existing operations as needed.

Hints

For Problem 1, feel free to use the std::string class to simplify handling of strings. Of course you need to use the various iostream classes as well. You are also allowed to use std::vector, but please don't use other STL classes yet, just make do with pointers. :-)
Here are some additional example networks for you to play with for Problem 1; yep, this is good fun, isn't it? :-)
For Problem 2, make sure you understand what you're supposed to do. You are only writing a new interface, not a new implementation. If you want you can take your old implementation and refactor that as well, but that's not required for the problem.

Deliverables

Please turn in a gzip compressed tarball of your assignment; the filename should be cs120-assign-7-login.tar.gz with login replaced by your Unix login name on ugradx.cs.jhu.edu. The tarball should contain no derived files whatsoever (i.e. no executable files), but allow building all derived files. Include a README file that briefly explains what your programs do and contains any other notes you want us to check out before grading. Include a Makefile to build your project.

Grading

For reference, here is a short explanation of the grading criteria. Packaging refers to the proper organization of the stuff you hand in, following the guidelines for Deliverables above. Style refers to C++ programming style, including things like consistent indentation, appropriate identifiers, useful comments, suitable documentation, good use of private and const, etc. Simple, clean, readable code is what you should be aiming for. Performance refers to how fast your program can produce the required results compared to other submissions. Design refers to proper modularization (into files and classes) and the proper choice of algorithms and data structures. Functionality refers to your programs being able to do what they should according to the specification given above; if the specification is ambiguous and you had to make a certain choice, defend that choice in your README file.

If your programs cannot be built you will get no points whatsoever. If your programs cannot be built without warnings using g++ -ansi -pedantic -Wall -Wextra -std=c++98 -O -Wabi -Weffc++ -Wctor-dtor-privacy -Wold-style-cast -Woverloaded-virtual -Wno-pmf-conversions -Wsign-promo we will take off 10% (except if you document a very good reason). If your programs cannot be built using make we will take off 10%. If your programs fail miserably even once, i.e. terminate with an exception of any kind or dump core, we will take off 10%. Finally, make sure to include your name and email address in every file you turn in!