SEG4110 UML Design Assignment and Course project - Fall 2011

The following are the two major deliverable work items for the Fall 2011 version of the SEG4110 course. Please see the course syllabus for additional details of marking. In addition, the TA will give you further guidance. Note that there are additional smaller work items you must submit from the various labs.

First major work item in the course: The UML Design Assignment

To be done individually by each person. No group work or working together. This assignment is worth 11.5% of your final grade.

Deadline: Thursday October 13th, 2011 at 11 a.m.. Handed in electronically, according to the directions from the TA. Note that we will be covering the needed OCL and Umple knowledge as the course progresses, but you can start the other aspects of UML modelling by mid September.

The deadline is well into the course so you can learn RSM and Umple in the labs. However it is suggested you start as soon as possible sketching the diagram by hand. Then you can do additional iterations when you have done the RSM and Umple labs. Remember, you also have a midterm near the deadline date, so it will be important not to leave this assignment until then, otherwise you will end up doing badly on either the midterm or the assignment. This assignment may take you 10 hours of work, so budget your time carefully.

Instructions: Design the infrastructure for an application that can monitor traffic at intersections, and then simulate the effects of changes to intersections. You will create a full UML model with class diagrams, state diagrams, component diagrams and deployment diagrams. You will also create an Umple version and generate code.

The high level requirements for the system are as follows:

Click here to see the requirements

Be as creative as you can. Expand on the requirements somewhat, and then create necessary UML diagrams. You should include a component diagram, class diagrams, state diagrams, a deployment diagram, and a use case diagram. In addition, include an instance diagram showing some sample data.

Add OCL statements to enhance your model as much as possible, both to describe class invariants and method preconditions and postconditions.

Overall, I would expect to see at 10-15 pages of neat diagrams, including 10 or more OCL statements. Add whatever other text you want to better explain your model.

Second major work item in the course: The Project

The following are the components of the SEG4110 course project you will need to work on.

Clearance for the topic and group members.

You should, as soon as possible, form groups of two and request approval of your topic by email to the professor. Remember the topic is first-come-first served. I will not let everybody do 'Ajax' or 'Ruby on Rails', which tend to be the most popular topics. You can propose a topic outside the list of topics given in the syllabus.

Proposal (3%) - Due Fri Sep 30 2011, 11 a.m.

You must write about the technology you are planning to use, and describe a small technology-demonstration project you will do with this. The TA will give you feedback on the feasibility of your work, and grade you on the extent to which you have demonstrated that you understand the technology you will be using. 5-6 single-spaced pages are expected.

You can hand this in earlier to get earlier feedback from the TA.

Note that the deadline is very early, and overlaps with your UML design project. It is expected that you will start work on the project before your UML design assignment is handed in. If you do not do this, then you will not have time to do a good first version before the deadline for your initial report below.

Initial report (5%) - Due Fri Nov 4, 2011, 11 a.m.

Immediately after this deadline, your system will be passed to another group (the 'testing grooup') that will start to test it.

There will be absolutely no lateness allowed. If you miss the deadline you will get zero, so be very careful. The reason for the strictness is that the testing group would otherwise be delayed.

If you can't get your project to work as nicely as you would have liked, then at least do your best given the time available. Cut features and simplify. Focus on quality. Above all, make sure what you have installs and runs for the other team to be able to do testing. Test it yourselves thoroughly before submission.

Here is what is expected: You are going to be providing a version of your work that can be tested by the testing group; the testing group will need to install your work, and figure out how to run it. Their job for the "Testing report of another group's work." (see below) due about a week later will be to try to find as many problems with your work as possible. You therefore need to address the assignment to the other group as well as to the TA. Give the other group as much information as possible about what it does and how to use it.

The material you hand in will include:

• The source code set up in such a way that it can easily be installed. In general it should be possible to simply unzip the material onto a Windows machine or a Linux machine, run an install script and then start testing. However, you may need to specify other aspects of the environment.

  Make installation very easy and obvious or else you will lose marks and the other team will waste time, so they won't have much time to actually test your work. In a few cases very special hardware or computer setups will be required. In this case it is acceptable to give instructions about where to go in the SITE building or in the Internet to run the software in a specific environment (see more on 'specific environments' below).

• A user manual (including how to install it).

• A set of test cases. You should include as many test cases as you can think of. If possible most of the test cases should be automated (i.e. code to run with expected results, e.g. using JUnit and Ant). The testing team will run these test cases, as well as whatever other tests they can think of.

  The space constraint of 7-10 pages is for the user manual and instructions for running the test cases combined (but does not include code for automated test cases).

To hand in your work, put everything into a zip file. The TA will give you further instructions. He will be responsible for sending the work to the testing group.

Your mark will be based on the effort you have put into the project, the quality of the testcases and the quality of the user manual. Only 40% of your mark will be on the quality of the system itelf, since you will be marked again on that later when you submit your final report.

Specific environments:

If the system will only work in a special environment (i.e. a specific set of computers in the SITE building), then the originating group may need to physically go there at times suitable to the testing group. If the originating group doesn't set up the special environment properly to help the testing group they will lose marks from their 'Initial Report' assignment. Regardless of what happens, the testing group needs to be left alone by the originating group so the testing can be done independently.

One solution to the problem of 'special environments' would be for the originating group to set up everything, including code, on the Internet in a hosted environment. The testers do not need to install anything. They just have to go to the URL you specify and use the system -- and use 'show source' to see code. If the originating team does this, they should make sure they start all required servers, and make sure there is a mechanism to re-start them if they crash, hang, or get into some other kind of error state.

For testing web services you can provide special-purpose pages, that allow the testers to enter data to be passed to the web service (i.e. so the service can be tested indepenent of the application as a whole).

Testing report of another group's work (4%), Due Wed Nov 16 2011, 11 a.m.

You will be testing another group's work, and it will be available to you as of Nov 7th.

If any originating group didn't submit their 'Initial Report' (and hence got zero), then one group's work might be sent to multiple groups. Where possible the testing group will receive work from an originating group that did something very different from what the testing group created.

Your job for the testing report is to provide a thorough test of the originating group's work by the deadline. Again you will send your results back to the TA, who will immediately after the Nov 16th deadline re-distribute the results back to the originating group to help improve their system. And again, missing the deadline will result in zero ... no exceptions and no extensions possible.

If you can't get the system you are given to work (e.g. installation doesn't work or it always crashes on almost all testcases) , you are allowed to communicate to the originating group. But do not communicate with them in other cases -- just raise a problem report (see below).

Problem reports

Your report should consist of a series of problem reports. Each problem report should be as follows:

• One-line description of the problem
• Severity (1=critical failure; 2=important; 3=merely a suggestion)
• Description of what you did, or the testcase number.
• Description of what happened, or your suggestion for a fix or improvement.

In addition, include a cover page describing the overall experience doing this testing.

Feel free to suggest any improvements you can think of. Howver, don't suggest enhancements that would obviously require an excessive amount of work.

You will be marked based on the effort you applied into testing and the quality of your recommendations. If you are given a particularly bad project to test, you will be expected to report primarily severity 1 and 2 problems, since you will not have time to get to the severity 3 problems. Overall, I would expect you to spend an hour per person setting up and familiarizing yourself with the system and about 3-4 hours per person on the testing and report writing.

Presentations in class and in lab time slots (8%)

These will be held December 5th and 7th (and possibly other dates a little earlier), with individual group demo times to be announced by the TA or the professor:

Guidelines for the presentations

You should give a presentation about your project and a demonstration of your system at work. Normally the demonstration should be live. However, remember that you will not have much time to set up. You can do the demo on the classroom computer; if so you will have 2 minutes to install anything you need before class (you must come early). Alternatively you may demo using a laptop that you plug in to the overhead projector. If you have special requirements, e.g. complicated setup, multiple computers, special hardware, etc., then you may create a video of your demo that you explain live. However, please email the professor and the TA for personal permission to do this.

The presentation, including the demonstration, should take no more than 30 minutes and should show off interesting aspects of your work.

For the presentation component, you should spend about 13 minutes explaining lessons you learned from your work that you think the class, the professor and the TA would benefit from knowing. Prepare 4-5 powerpoint slides. The presentation should in general come after the demonstration, although you may need to show one slide before the demo to explain the context.,

Any text on your slides should be at least 20 point font; text of code can be 16 point font or larger.

Make sure you do not duplicate material the professor presented in class or the TA presented in the labs (you will lose marks if you do), so please check with the course notes first. Some of the things you might talk about briefly include:

• Aspects of the technology you think should be taught, but which we did not cover (you could show architectural diagrams, or snippets of code that you will explain line by line, but don't show large amounts of code or text).

• An overview of how your application works, so others can learn from your experience building it. I suggest doing this through diagrams that you explain.

• Things that you found particularly difficult about using the technology. These might be things you had trouble understanding, or bugs you had trouble debugging. You could express this as warnings to others, lessons learned or 'war stories'.

• Things you found particularly 'cool' or interesting that make the technology attractive for you.

• You should conclude by saying whether you would choose to use the same technologies again and what you might do differently.

All group members must participate, so perhaps one could give the demo and another the presentation. You could even split the presentation between two people.

You should leave about 2 minutes at the end for questions.

I will be very strict cutting you off if you exceed your time budget for your demo.

Here is the marking scheme.

• 40% demo
  • 10% Does it work well
  • 10% Does it do something interesting /educational for students
  • 10% Does it show you have paid attention to quality
  • 10% Does it make appropriate use of the technology
• 60% presentation on sessons learned
  • 40% Educational value for the other students (duplicating what we learned in class will detract from this)
    • overview of how it works (diagrams)
    • things you found difficult / war stories
    • things you found 'cool' or interesting
    • what you would do differently in future
  • 20% Quality of the slides (large font, short points, etc.).

As a reminder: Come early to set up. It would be best if most groups have everything on a laptop. If you bring materials to class, and expect to install them before class, I strongly suggest you use a 'memory stick'.

Don't panic if your demo crashes. Do your best. I will be lenient, especially for the first group.

Final report (10%)

Due: Wednesday, Dec 7th, at 7 p.m.

Note that this deadline is also in the day of some of the presentation/demos. Essentially, you should have finished the work by the time of the presentation/demo.

Here are the deliverables

• Your code, properly commented. You will be marked on style and general code quality. Embed enough comments to make the code understandable.

• A cover letter explaining the changes you have made since you submitted the original system for testing.

Last update to this page: Wednesday, 03-Aug-2011 15:29:34 EDT