You must give either code or pseudo-code for every part of your design. Thus, you are not required to implement all of the functionality described in your requirements and design (you can give pseudo-code for the parts you don't implement). This gives teams some flexibility to choose between more ambitious requirements and design with less implementation, or less ambitious requirements and design with more implementation. Teams on the former end of the spectrum will need to more time to work on the requirements and design and less time to work on the implementation, so for those teams, no penalty will be imposed if some parts of the requirements and design are completed after the deadlines below for submitting the requirements and design (of course, these teams will still be graded based on what they submit at all three of the deadlines, and everything must be finished by the project completion deadline).
The requirements and design must be written in the UML using a UML-based CASE tool. The easiest option is to use Argo/UML, which is free, open source, and written entirely in Java. There are also several commercial CASE tools that support UML, the best known being Rational Rose; you can request a free evaluation copy of Rational Rose from their web site and give it a try. Of course, if you have the funds, you are welcome to purchase and use any commercial UML-based tool.
Your goal is both to develop good requirements and design and to convince us that you did so! Thus, your submission should discuss significant design decisions, alternative designs, and trade-offs. You may express the alternative designs in the UML or in English, whichever seems clearer.
One limitation of the current version of Argo/UML (version 0.8.1a) is that it does not support sequence diagrams, so (unless a new version comes out in the next few weeks) you will need to draw sequence diagrams with a general-purpose drawing program. (If you have trouble finding one, let me know).
If Argo/UML's running time or memory use is unacceptable on your machine, then turn off Critiques (by clicking on "Toggle Auto-Critique" in the "Critique" menu).
Each student will be given an account in the Transaction Lab. I plan to make Argo/UML available in the Transaction Lab in an ISE440 course account. If you have your own computer with a Java run-time environment and about 3MB of free disk space, you might want to download Argo/UML onto it. Installation of Argo/UML is trivial.
In the implementation phase of your project, you may use any object-oriented programming language available in the Transaction Lab.
Your final submission must include descriptions of the contributions of each team member. This information will be considered when assigning each student a score for the project. I encourage each student to keep track of his or her contributions carefully throughout the semester, to avoid controversy at the end of the semester.
A major goal of modeling languages, such as the UML, is to facilitate communication of requirements and designs. Accordingly, I plan to have homework assignments in which you read and critique requirements and designs written by other teams.
| Deadline | Activity |
| 2 Feb | Team and topics |
| 14 Feb | Goals |
| 4 Mar | Requirements |
| 26 Mar | Design |
| 30 Apr, 5pm | Completed Project |
| 1,3 May | Presentations and Demos |
Team and topics. Projects are done in teams. Each team must have 3 or 4 members. When a team is formed, one member should send a message to stoller AT cs DOT sunysb DOT edu containing: (1) the names and email addresses of the team members; and (2) a list of topics (i.e., kinds of system) on which the team is interested in working. For item 2, you have two options: (2a) give a ranking (in order of decreasing preference) of all the topics listed below, or (2b) give a ranking (in order of decreasing preference) of at least 5 topics, including at least one topic not on the list below.
We will try to assign to each team a topic from its list, subject to the constraint that different teams work on different topics. Students who do not form teams by the deadline will be assigned teams.
Some possible topics appear below. You are welcome to suggest other topics, subject to approval. Be creative! If you suggest a topic not in the list below, describe it in a few sentences. Systems that involve people in several different roles interacting with the software in various prescribed workflows will tend to be more interesting for this project. Systems that mainly perform batch processing of databases (e.g., payroll systems) are less appropriate.
Goals. Submit an English description of what you
will accomplish, including (1) the functionality that will be specified by
the requirements and that will be supported by the design, and (2) the
functionality that will be implemented. We will provide feedback on
whether the size and difficulty of the project are appropriate. Expected
length of this description is 500-1000 words. Writing more is OK.
Writing less is riskier for you, because you will probably get less useful
feedback.
Requirements. Express the requirements for
your system in the UML. The UML allows diagrams to be annotated with
informal notes in English, but as much as possible, use formal structures,
such as pre and post conditions (written in OCL or English) and state
machines.
Design. Express the design of your system in the
UML. As much as possible, use formal structures, as described in the
previous paragraph, and use design patterns. When submitting the design,
you might also want to submit a revised set of implementation goals, to
reflect your improved understanding of the design. If you do this, we
will provide feedback on whether the revised goals are appropriate.
Completed project. Submit the completed project, including
Presentations and Demos. Each team will give a brief
(approximately 20 minutes) in-class presentation about their project.
The presentation should describe the requirements, design, and
implementation. Your presentation should definitely include some UML
diagrams, which are as effective in presentations as in written
documents. Each team will meet with the T.A. to demonstrate their
implementation. The demo proceeds as follows: (1) delete files produced
by compilation and linking (e.g., *.class, *.o, *.exe); (2) compile the
system; (3) run the system on some testcases prepared by the team; (4)
run the system on testcases suggested by the T.A.
Some Possible Topics