Write a simple Java program that prints "Hello, World!" on the command-line.
No write-up is needed for this orientation lab; the main point is to make
sure you are setup with a Java development environment (editing, compiling,
running). You may find Eclipse intro
useful, or you can use this time to get your own Java development environment
installed and working. But you need to be ready to code for your Lab1!
Java text (Savitch), p.162-164: choose one of #2, #5, or #8.
(#8: also generate or come up with your own cryparithmetic puzzle)
Java text (Savitch), p.247-248: choose one of #2 (Fraction), #3
(Odometer), #4 (BlogEntry), or #6 (StudentGrades).
Java text (Savitch), p.469-472: choose one of #3 (Alien), #6 (Truck),
#7 (Patient), or p.509 #4 (predator-prey).
The last option (p.509 #4) is worth up to 5 pts extra credit (45 total)
if done correctly and completely.
Develop your own GUI program using Java Swing! Here are the requirements:
- In each case, you should have at least two classes: one which is
your solution to the lab, including attributes, constructor, and other
methods (e.g., Fraction), and another class which tests your main class
(e.g., FractionTest). The testbed class can have several methods in it;
you may use this for unit-testing each method in your main class.
- Your class should have at least: attributes, constructors, set/get
methods (including a toString() method), plus whatever other methods are
needed to meet the requirements.
- Provide constructors that take various different arguments to initialize
attributes, plus a constructor that doesn't need any arguments (choose default
values), plus a "copy constructor" that takes another object of the same type.
Suggestions for possible lab ideas:
- It must be a cohesive program with a clear purpose (i.e., not just
a technology demo of Swing widgets).
- It must make extensive use of Java Swing for the GUI: this includes
widgets (buttons, menus, and/or text boxes) and use of a layout manager.
- It must be interactive; you may use ActionListener or another
EventListener interface (e.g., MouseListener, MouseMotionListener).
- The design of the UI should be user-friendly, easy to use, and
not unbearably ugly. An average non-programmer computer user should be
able to figure out the controls even without help text.
- There should be a load/save functionality that makes use of
Serializable to read/write objects to file.
- Have fun and make it cool!
Design a small project of your choosing, using UML diagrams to illustrate.
Your project need not be too complex, but it should be a cohesive system
with a clearly-defined purpose, and you should design sufficient functionality
so that the system is useful.
Your project need not be computer-related -- classes may represent
non-software objects, e.g., Animal class, Truck class, etc.
- "Memory game": click on cards to turn them over; match pairs of cards to
clear them from the board.
- Calculator: either RPN or build an expression.
- Fast food ordering kiosk: select meals, options; get a total bill.
- Church directory: add member, edit entry, search
This lab is not a programming lab (no code required), so instead of the
usual lab write-up, you will hand in a complete design document with
the following sections:
You may format your design document as a single Word document with
tables/figures, or you may include the UML diagrams as separate files and
refer to them in the document. Please ensure the document is neat and
well-organized, written in clear English, easy for someone well-versed in
UML to understand.
- Name of the system
- Short description of its purpose ("30-second summary")
- Target audience / end-users: who would find your program useful?
- Use-case diagram:
- Actors (some may be people, some may be non-human)
- Use cases (remember each use case should be a standalone session
interacting with the system -- e.g., "take picture", not
"press shutter button")
- Multiplicity for each use case with each actor.
- Relationships between use cases (e.g., "includes", "specialization",
etc.), as applicable.
- Detailed descriptions of each use case in the diagram:
- Name of use case
- Actors involved with the use case
- Goals of the use case for each actor
- Pre/post-conditions of the use case (this impacts what alternate
flows you may need to include)
- Basic flow
- Alternate flows: for each, indicate what might go wrong and
detail a flow for how to handle the situation
- Component diagram: draw a CRC diagram or something similar.
- Components may be composed of smaller sub-components: you may want to
draw one high-level overview of the whole system as 3-4 components, then
expand each one into a subsystem of 2-3 sub-components.
- The goal is to make implementation of each component as easy as
possible; spend time thinking this part through!
- Sequence diagram:
- For important interactions with the system, draw sequence diagrams
detailing the sequence of messages passed between components of your
system. You do not need to do this for every use case; pick a few
- Use asynchronous messages when appropriate.
- For each sequence diagram, also write a short paragraph explaining it
and highlighting any important features (dependencies, asynchrony, etc.).
- Class diagram:
- Design a complete set of OO classes to implement your system.
- Include every non-standard class (you don't need to diagram Swing
- If you decomposed your components into smaller sub-components, then
they may map directly to classes; otherwise, you may need several classes
to implement each component.
- Think carefully about the attributes and methods in each class:
- What data (attributes) are stored in each instance?
- What actions (method) can it perform?
- What information does each method require to do its duty (parameters,
relationship with other classes)?
- Build inheritance hierarchies as appropriate.
- Indicate relationships between classes (association, aggregation,
- Indicate multiplicity for each relationship.
You may find the following links helpful for further reading on UML:
Feel free to investigate and use software UML tools such as
IBM Rational Modeler, or drawing/diagramming tools such as
Adobe Illustrator (installed on campus computers), or even Paint.
Some of these can be quite complex to learn (I think Dia is the simplest),
so if you like, you may draw your diagrams (carefully!) by hand and scan
them in. The diagrams must be very neat and easy to read, though!
The design work is complex enough as it is; I suggest that you not spend
too much time learning a complex software UML tool to diagram it.
Choosing a Project
I suggest that you choose a small, easy-to-define system as your project,
as the design document can be very large even for small projects.
At a minimum, have at least 3 actors, 3 use cases, 1-2 alternate flows
for each use case, 3 components, separate sequence diagrams for each of
3 use cases, with 3-4 messages in each sequence diagram, and 4-5 classes, with
relationships. These are guidelines, but don't let them constrain you --
the point is to have a reasonably complete design of a small system.
Some possible ideas:
You may feel free to expand on your Lab4 or future Lab6 idea, too!
- Restaurant reservation system
- Web forum / bulletin board (with logins, etc.)
- Car (driving, maintaining, etc.)
- Microwave oven
- Portable music player (e.g., iPod)
- Choose one of the following two options, either Android or TCP/IP client-server.
- On Wed 14 Apr, you will demonstrate one of your projects in-class, in the senior lab!
You may demonstrate any one of your labs, but you want to choose something cool to show.
If you don't want to use the lab computers, you may demonstrate it on your own laptop.
The presentation counts for the last 10pts of the project.
- Be creative and make it interesting! (That's part of the assignment!)
Write a cool Android application! You may demonstrate it on the software emulator.
When you're ready, you may try it out on my phone (but it's okay if it only works on
We might not have time in-class to get very far on Android, but there are many
resources to help you learn Android on the
Android developer site:
Come up with your own cool client-server network application (e.g., chat/IM,
stock-ticker, sending pictures, web server)!
- Your application should have
(at least) two running programs, one for the server and one for the client.
- Both should have Swing GUIs that use multithreading to keep the GUI
- Your server should use multithreading to handle multiple clients simultaneously (demonstrate this).
- The messages you send over the network may be either plain-text or serialized objects.
- To facilitate running the demo, please make it easy to change the server and port,
on both the client and server (e.g., without recompiling).
- You may try your applications on two different computers in the CSI lab!
Use ports 4410 and/or 4411.