52.361 Group Project 2010
Class Material
This page includes the first semester material for the class. For the second semester material see here.
The group project will be based around MIT's Open Courseware Class - 6.170 Laboratory in Software Engineering
On-Line copy of Bruce Eckel's Thinking in Java (Advanced Java Textbook)
Head First Java chapter on Interfaces and Abstract Classes (thanks to Murray Barnes)
Eclipse
For all practical work you will be using the Eclipse Java IDE. Use the practical in week 1 to get to know your
group and to get to know Eclipse. Take one of your practicals from second year, or your Programming Project,
and try to load it into Eclipse and compile and run it. Make some intentional errors and see how Eclipse helps
to identify and correct those errors.
Help on getting going with Eclipse:
Announcements
(10/12/2010) VERY IMPORTANT: The deadline for the Folio Tracker Exercise has been
extended to Wendesday 15 December at 12:00.
(24/11/2010) VERY IMPORTANT: There are no more lectures for the class this semester. The lectures
will start again next semester. Labs continue as normal until the end of the semester.
(4/11/2010) VERY IMPORTANT: There is a Tutorial on Wednesday 10 November at 13:00 in M403.
The tutorial will focus on Method Specifications, Assertions and JUnit Tests in preparation for the the upcoming class
test as well as some code design feedback for the Multi-graph ADT.
(4/11/2010) IMPORTANT: There is no formal lab on Wednesday 10 November. However
you are expected to work on your JUnit Tests.
(4/11/2010) VERY IMPORTANT: The class test will take place on Wednesday 24 November at 13:00.
(25/10/2010) IMPORTANT: There is no formal lab on Wednesday 27 October. However
you are expected to work on your Method Specifications.
(20/10/2010) VERY IMPORTANT: There is a guest lecture on Software Engineering by David Anderson
on Thursday 21 October at 15:00 in R512. You should do your best to attend.
(30/9/2010) VERY IMPORTANT: From Wednesday 6 October the lab for the class will take place in the Kelvin lab (LT 12).
(24/9/2010) VERY IMPORTANT: It is essential that you subscribe to the class forum 52361.
(24/9/2010) VERY IMPORTANT:
- The class assessment is based entirely upon coursework - some of it individual and some group-based.
A constant commitment to the class and your group is essential.
- There is no resit for this class, if you fail it then you have to do an individual project.
- Don't be shy!
Please approach the course lecturer if you feel you require more lecture support for any aspects of this course
(it is assumed that you have some familiarity with the software engineering techniques you will be required to use - if
not, let us know).
Class Test
- The class test will be based on the code provided in Number.java.
- The test itself can found in Class Test.docx.
- Class Test Solutions and Feedback
New Class Test
- The new class test will be based on the code provided in IntSeq.java.
Tutorial
Tutorial, IntSet, IntBag
Lectures
- Decoupling GUIs
- Code Examples
- Listeners:
- Model-View-Controller:
- References: Java Swing Tutorial,
Java Swing Tutorial: Concurrency in Swing.
- Testing
- References: 6-170's Testing lecture.
- Object Equality
- References: 6-170's Equality lecture.
- JUnit
- References: JUnit Test Infected: Programmers Love Writing Tests - essential reading!
- Using JUnit in Eclipse by Christopher Batty.
- JUnit 3.8.1.
- JUnit Project.
- Assertions
- References: 6-170's lecture 11 notes.
- Programming with Assertions on Oracle's Java site.
- Method Specifications, Specification Ordering Example
- References: 6-170's lecture 4 (old) and lecture 4 (new) notes.
- 6-170's Lecture Notes on ADTs old and new. Most of this should be familiar, have a look as a reminder.
- Josh Bloch's advice on checked v. unchecked exceptions
- Decoupling
- References: 6-170's lecture 2 and lecture 3 notes.
- Introduction
- References: 6-170's lecture 1 notes, particularly sections 1.3 and 1.4.
Coursework
-
Self- and Peer-Assessment
Deadline: December 15 at 15:00
This is an individual assessment and it covers all the group tasks of the first semester (i.e.
Multi-Graph ADT, FolioTracker and the three newsgroup postings on Method Specifications, Java Assertions and
JUnit Test Cases).
In this assessment you assess the performance of yourself and all other members of your group.
The assessment is in relative terms (i.e. whether someone has contributed more than, the same or less than
the average for the group).
The assessments are confidential (i.e. they will not be revealed to the other members of the group).
The way it works is that the collected scores for each person are added up and compared to the group average to
determine whether the person's contribution to the group is higher or lower than the average. Then, the group
marks are distributed according to this assessment (i.e. members with higher contribution will receive a higher
mark than the group's mark, and members with lower contribution will receive a lower mark than the group's mark,
an average contribution equates to the group's mark).
However, the impact of the self- and peer-assessment is restricted to approximately 10% of marks available.
Deliverable:
- Each group memeber should fill in the self- and peer-assessment form.
and submit by email to Michael Cashmore (the class demonstrator).
Note: If you do not submit your assessment, then you will be penalised by assuming that you assessed your
own contribution as non-existent!
-
Folio Tracker
Weight: 15% of the class mark
Deliverables:
- Part 1: GUI Design
Deadline: November 29 at 12:00
This part involves the development of a GUI for a FolioTracker application. Please construct
this "by hand" (as opposed to using a GUI builder) to ensure the everyone in the group has a
good understanding of Swing and the principles of building GUIs (you will need to build a far
more complex interface next semester).
A note about stubs.
Stubs are just simple dummy bits of code that enable you to test how
objects interact without having to write the complete system. In this case they will allow you to
test the GUI without having to develop the entire application. You will need to provide stubs for
any method in your application API that the GUI interacts with. For example, if your GUI calls a
method called getSharePrice() which returns the price of a stock item in pence, a stub for this
could look like:
...
public int getSharePrice(){ return 5; }
...
Obviously, this will always return "5" for any stock item. You could vary it to return a random
number, or one more than the previous value or....But don't make it too complex. The aim is to make
the testing easy and predictable and remember that it is code that is going to be thrown away. When
you come to develop the rest of the system the stubs will be replaced with real code. If you've
designed things well that's all you'll have to do!
The FolioTracker is a group exercise. Your submission must be submitted on paper at the departmental
office by 12:00 on Monday, November 29. Your submission should contain:
- Overview [One page or less]. A terse and precise description of what the
application's purpose is; what kinds of functionality it supports; what your GUI
looks like and how it is to be used. Think of this section as a compressed user
manual: the kind of summary of an application often found on marketing flyers.
- Specification of API [Two pages or less]. An overview of the application
programmer's interface (API) through which the GUI will access the components of
the code that obtain stock quotes, maintain a database of values, and so on. Also,
a detailed specification describing each method in the API with the standard
requires/ensures/modifies form.
- Screenshots of the GUI. A set of screenshots of your GUI showing how it is organized
and what functions it offers.
- Part 2: Backend Design and Implementation
Deadline: December 15 at 12:00 (extended)
- You should demonstrate your submission in the lab on week 12 (December 15).
All group members should be present and everyone should be
prepared to talk about and answer questions on your system.
- You should submit a zip including all your code for the FolioTracker, including text files
with instructions on how to run them through Spider.
- Other related material:
For those of you who aren't big players of the stock market, you can find definitions of terms you
may be unfamiliar with in
Campbell R. Harvey's Hypertextual Finance Glossary.
-
JUnit Tests
Weight: 1% of the class mark
Deadline: November 12 at 16:00
Deliverable: A group submission to the class newsgroup of one example of a JUnit test for the Multigraph ADT.
This should be drwan from a set of JUnit tests that you developed. This will involve translating your existing
tests and maybe coming up with some new ones. Your tests should be based on what the program should do -
i.e. it is expected that it will fail some of the tests. These are clearly a better set of tests than those
which demonstrate only what the program does correctly. The main purpose is for you to gain some experience in
testing and become familiar with JUnit - which you should use in all development from now on. In preparation
for the class test it is essential that you try out your tests in Eclipse using JUnit before submitting them to
the newsgroup.
- Your submission to the newsgroup must be noticeably different from any early postings by other groups.
- If another group has already posted the test case you wish to post you can
- Post a different test case
- Constructively criticise an existing posting e.g. point out a significant potential weakness in
an already posted test case (keep it constructive) and post an improved version
- Make sure you start a new thread for each new JUnit Test titled Group X Test
- If you are improving another group's test just reply to their posting, but ensure you identify your group, i.e. Group X Submission at the top of your posting
As before, there are therefore benefits in getting in early, you can contribute any test case, but you are then
making your test case available for other groups to critique.
The result of task would hopefully be a series of useful posting on specifications, assertions and JUnit test cases
that will help you all prepare for the individual class test on these topics later on in the semester (most likely in week 9).
-
Assertions
Weight: 1% of the class mark
Deadline: November 5 at 16:00
Deliverable: A group submission to the class newsgroup of two examples of meaningful Java assertions for the Graph ADT.
These should be drawn for a number of Java assertions that you develop and which include an example of Internal Invariant,
Control-Flow Invariant, Precondition, Postcondition and Class Invariant.
- Your submission to the newsgroup must be noticeably different from any early postings by other groups
- If another group has already posted the assertion you wish to post you can
- Post a different assertion
- Constructively criticise an existing posting e.g. point out a significant potential weakness in an already posted assertion (keep it constructive) and post an improved version
- Make sure you start a new thread for each new assertion titled Group X Assertion
- If you are improving another group's assertion just reply to their posting, but ensure you identify your group, i.e. Group X Submission at the top of your posting
Note that as before, there benefits in making a submission early, you can contribute any assertions, but you are also making the assertions
available for other groups to critique.
The result of task would hopefully be a series of useful posting on specifications, assertions and JUnit test cases
that will help you all prepare for the individual class test on these topics later on in the semester (most likely in week 9).
-
Method Specifications
Weight: 1% of the class mark
Deadline: October 29 at 16:00
Deliverable:A group submission to the class forum of an informal specification of a method of the Graph ADT.
- Your submission to the forum must be noticeably different from any early postings by other groups
- If another group has already posted the specification you wish to post you can
- Post a specification for a different method
- Post a more formal version of an existing specification (NOT less formal)
- Constructively criticise an existing posting e.g. point out a significant potential weakness in an already posted specification (keep it constructive) and post an improved version
- Make sure you start a new thread for each new specification titled Group X Specification
- If you are improving another group's specification just reply to their posting, but ensure you identify your group, i.e. Group X Submission at the top of your posting
Note that there benefits in making a submission early, you can choose the method to specify, but you are also making the specification
available for other groups to critique.
The result of task and the following two would hopefully be a series of useful posting on specifications, assertions and JUnit test cases
that will help you all prepare for the individual class test on these topics later on in the semester.
-
Design an Abstract Data Type, exercise 3 of the MIT assignments
Weight: 15% of the class mark
Deliverables:
- Problem1: Graph Specification
Deadline: October 11 at 12:00
Your should make your submission on paper at the departmental office.
Your submission for Problem 1 should contain the following (rather than what is described at the MIT site):
- A class diagram that shows the interfaces and classes that are visible to the clients (users) of the graph and the relationships between them.
- A brief description of your diagram (approximately two pages) that:
- explains the role of each interface and each class in the design
- explains the relationships between the interfaces and classes that you have identified
- includes a brief description of each method that you have identified in each interface and class
- Problem2: Graph Implementation & Problem3: Using the graph
Deadline: October 19 at 17:00
- You should demonstrate your submission in the lab on week 4 (October 20).
All group members should be present and everyone should be
prepared to talk about and answer questions on your system.
You will be expected to demonstrate it finding routes within the Boston subway using
the text file representation.
- You should submit a zip including all your code for both the Graph Implementation and Using the
Graph problem, including text files with instructions on how to run them through Spider.
Do not include any .class files in your submission!
In addition to the code the zip file should also include:
- A brief overview of the representation you chose for the multi-graph along with a
brief rationale which justifies your choice (maximum 1 side of A4 in total).
- A class diagram which shows the classes, interfaces, associations etc. and methods for your
complete design including classes used to implement the multi-graph. You should include
parameters in the method headings.
As before, you should include a brief description of your diagram that:
- explains the role of each interface and each class in the design
- explains the relationships between the interfaces and classes that you have identified
- includes a brief description of each method that you have identified in each interface and class
You should also highlight any changes to the design, submitted in week 3, that result during implementation.
Other related material:
- A map of the Boston subway
- Don't get confused when it talks about "T directions"; "T" is the local name for the Boston subway.
Your multi-graph implementation will be used to return the route(s) between two stations - but
don't be influenced too strongly by this.
- Don't make life difficult for yourselves by adding over-complicated or unnecessary functionality -
the standard rule of the group project is "If in doubt, whip it out".
- Here is some information about Graphs, Bread-First Search and Directed Graphs
from chapter 6 of Algorithm Design: Foundations, Analysis and Internet Examples by M.T. Goodrich and R. Tamassia.
Last modified: Thuesday, Janaury 25, 2011