CSE143 Summer 2003

Project 4

Hosts and Routers

Due date details Overview

Supplied code

Step 1

Step 2

Rules, advice, guidelines  

Hints, tips, and corrections Please check here occasionally!

Turn-in forms

 

Due dates:  Electronic parts: Tuesday evening, July 29 9:00 PM, printouts and/or written parts due the following day in lecture.  

Overview Network topologies are complex... give the poor network administrator a way to visualize it.   Give him or her a tool which makes it easy to draw network graphs, consisting of Router and Host nodes.  An edge can be drawn between a Router and a Host, or between a Router and another Router, but not between two Hosts.  A Host can only be connected to one Router.  A Router can connect to any number of other nodes.  Make the Host shape circle-ish, and the Router shape rectangular-ish.   You can make the diagram as pretty as you want, but there probably won't be a beauty contest.

Starting CodeWe will eventually do a project which modifies Cay Horstmann's Violet UML diagramming tool.  As a warm up, let's make a graph editor application based on a simpler version of the same program.  Source code can be found in chapter 8 of Horstmann's book, Object-Oriented Design and Patterns (John Wiley & Sons, 2004).  Follow the link to the Student Companion Site, Source Code.  Within Chapter 8, there are several source code directories.  These are not packages, but separate examples from different parts of the chapter.  What we need is graphed2.  All the of the files are in the default (unnamed) package.  They should compile with no changes whatsoever.  The main class is SimpleGraphEditor.java, and it should run as-is.

Basically, to create a type of drawing you have to supply a class for each node type and each edge type which the drawing can have.  Nodes must implement Node and Edges must implement Edge.  The graph as a whole extends Graph.  The working example in graphed2 not only shows you how this is done, but also contains concrete classes which you can use or extend (but not modify!).

Step1, Step 2: There is only one "step" this time, including both analysis and code parts. 

Look at Java files in graphed2.  Draw a UML-style Class Diagram for them.  In case you weren't doing so before, indicate interfaces and abstract classes differently from other classes.  Include a rectangle for each library class used, but without showing any relationships for those classes OR make one big box, listing the name of all library classes used; if this box gets to be too big, you can turn in a separate sheet of paper listing the information.  Omit method names in the class boxes.  You only need to show arrows for "extends" and "implements" relationships, except: show any "uses" or "has a" relationships in which the following classes are involved with one another: SimpleGraphEditor, SimpleGraph, CircleNode, RectangleNode, and LineEdge; indicate such relationships with something other than the extends and implements arrows.  Hand in a hard-copy of your UML diagram.

Don't modify any of the starter code files; you won't be able to turn-in modified versions, and the classes you do turn-in must run our our system, which will have the original unmodified starter files available.  Your files can have any (appropriate) names, with one exception: there must be a class with main named exactly NetworkDiagramEditor.java.  We will test your project by running that class.  Put all files that you create in the original, default (unnamed) package (i.e., don't include a package statement!).

Run your program (i.e., NetworkDiagramEditor, which contains main), create a nice network diagram; then take a screen snapshot, and print that snapshot to turn in.  

Now that you have seen Sun's coding standard, which is reasonable and widely used, please follow it or something close to it.  Include Javadoc comments in your code.  You do not have to run javadoc (but you might find it helpful as a way of understanding the code).

Special note: There will obviously be a bunch of pieces of paper to hand in.  Be sure they are all stapled together, and that all parts have your name and section (in case the parts get separated).  Unstapled and/or unlabeled parts will be considered in poor taste.

To get full credit, it is not necessary to go beyond the requirements, and there is no extra credit if you do.  But impressing your TA is always a good thing anyway!

This project is to be done by pairs of students.  Partners will be assigned by TAs.  Working alone or changing partners is not permitted.  Review the course and departmental guidelines for use of work not your own.  In particular, any scrap of code which your team didn't originate or that isn't CSE143-supplied (e.g. you and some others brainstormed the idea) must be acknowledged.

[7/27] Please turn in everything once per team.  One UML diagram, one electronic turn-in, one this, one that, etc. -- but put both partners' name on everyone.  It does not matter which person does the electronic turn-in.

Please read the turn-in forms carefully when they become available, including the fine print!  After submitting a form, read what comes back, too.   For example, if the form says "Print me", you had better print it, even if these instructions mention nothing at all about printing. Turnin form (now available!)

Hints, Tips, and Corrections.   Check here occasionally for major hints or corrections.  Your best source of help is the Message Board, however, or office hours.

The Violet program for drawing UML class diagrams is not required; however, unless your drawing and lettering skills are very good, you should consider using it or some other type of drawing tool (such as Visio, PowerPoint, etc.).  Violet was written by Cay Horstmann (Martin's favorite Java author), and is a good example of object-oriented design and programming -- the Java source is included in the download.