CIT 594 Assignment 9: Mapping the Building
Spring 2009, David Matuszek

# Purposes of this assignment:

• Introduce you to graphs and graph algorithms
• Give you an interesting final project

# General idea of the assignment:

When I came to the University in 2001, someone told me, "If you know your way around this building, you've been here too long." At that time, Levine did not yet exist, and the two-story Pender building had not yet been torn down and replaced by the much larger (and more confusing) Skirkanich. So I don't think things have gotten any simpler.

Your assignment is to write a program to let the user find the best route from any one location in Moore/Levine/Towne/Skirkanich to any other location in the same building complex.

# A little more detail:

This will be a group project. Each group should consist of three or four people. I'm not going to assign groups, so it will be up to you to find a group, and let me know who is in it.

## Collecting data

Part of the reason for doing group work is that the building complex is large, and there is quite a bit of it to explore. You will have to explore it, in order to collect data for the program. Share this work out among the members of your group. You are also free to contract with other groups, to share information. Everybody should do at least a bit of exploring.

While collecting data, don't go into any locked or restricted areas, but do try to find some of the more out-of-the-way places. Try not to look suspicious; I'd rather not have to talk to the police about your behavior.

Absolute accuracy is not required. You don't need to use a measuring tape. One simple approach is to measure floor tiles, or bricks or concrete blocks, then walk along counting them. For long stretches of rooms, such as in Towne, try not to let errors accumulate.

Stairways, elevators, and ramps require special treatment. Some people avoid stairways, so for them stairways should have higher "cost." A stairway going down "costs less" for many people than a stairway going up; and the same is true for ramps. Some disabled people cannot use stairways at all. Some people prefer, or avoid, elevators (I avoid the ancient one in Moore/GRW). Hence, the "best" path is not fixed, but depends on individual preferences. Your program should allow users to set their preferences (but provide reasonable defaults for typical users).

Some rooms may be referred to in more than one way. For example, Levine Hall, Room 164 is the CETS office. (Why Levine? Isn't it in Moore?) Similarly for computer labs and offices. I don't want to have to remember the room number of an office, or guess what a numbered room holds.

## The program

You should use the MVC pattern, so that the path-finding part of your program is I/O free. It should not access the GUI in any way; it should just do the computations, and make the results available. I think path-finding is likely to be the easiest part of this assignment. This part should, of course, be JUnit tested.

Data should be kept in a file in a known location, and read in when the program is started. The user should not have to explicitly load the data; it should just "be there." You will have to design the data format; my only requirement is that it be a text file, and therefore (at least potentially) human-readable and editable. If someone on your team knows XML, that's a very good way to represent the data; but it does have a fairly steep learning curve.

I expect the GUI design to be quite difficult. It's not that it's difficult to implement a GUI; it's that it's difficult to design a good one. Ideally, a GUI should be (1) intuitive, so it's obvious what to do; (2) easy to use, so that, for example, I shouldn't have to remember names of rooms, or do a lot of typing; and (3) well organized, so that, for example, I don't have to look through a list of a hundred items to find the one I want. The single most important rule to follow in GUI design is: Do user testing!

## Teamwork

You are expected to work together as a team on this project. Make joint decisions. Agree (or disagree) with one another on the design of the various components. You should not split up the work, then each go your separate ways.

I think you will find there are a lot of decisions to be made. Make them. Don't ask me to make them for you. You know what I want: a program that's easy to understand and easy to use. Clean, readable, modifiable code would also be nice. You probably want to get a working program with a minimum of effort. Use these goals as a basis for your decisions, and you'll do fine.

To facilitate working together, the first part--maybe 15 or 20 minutes--of each remaining class will be spent talking with your teammates. It would be a good idea for at least one member of your group to bring a laptop to class. Thumb drives are a good way to share code. (They are also a good way to spread viruses, so please scrub your computers.)

# Due dates (more than one):

Thursday, April 23, before 4:30 pm. Your team should give a ten-minute presentation to the class on your design, and should demonstrate a first-draft working version of your program.

If you get some good ideas from another team's presentation, feel free to incorporate them into your own program. You can't "borrow" code from another team, but you can get ideas.

Turn in the complete program, along with any data files, via Blackboard, before midnight Tuesday, April 28.

Late programs will receive the usual 5 points/day late, up until the time we get around to grading the programs, which will be some unspecified time after April 28. Once we are done grading, however, we will be done, and will not be accepting any additional submissions.