During the first week of the course, the students are to decide whether they want to do a written report in a group or do an individual oral presentation at the end of the quarter. The students who decide to do a written report must form groups (3 persons each). Each group selects a project, which is documented in the report handed in at the end of the course.

In principle, the same kinds of topic are relevant both for oral presentations and for written reports. Of course, since oral presentations are one-person only and written reports are made in 3-person groups, the oral presentation projects should be more delimited . Typically, the amount of implementation work should be more limited, but less is also expected in terms of e.g. comparisons with other patterns or general considerations regarding the usefulness of the pattern. Some architectural patterns require so much implementation work that only groups of three people should try them (e.g., Blackboard), whereas others can easily be done by a single person (e.g., Model-View-Controller).

Most of the architectual patterns from the POSA-1 book would be excellent topics: try implementing a small system based on one of these patterns. The relevant patterns are:

• Blackboard: distributed, sort of like a multi-agent system
• Broker: like an ORB from CORBA
• Model-View-Controller: you know this one
• Presentation-Abstraction-Control: the big brother of MVC
• Microkernel: factoring out the reusable parts
• Reflection: domain-specific for adaptable applications

As an alternative, there are also many architectural patterns for distributed programming in POSA-2. These patterns are fairly technical in nature, but would nonetheless be good topics as well. Note that the examples in the book are in C++ since Java did not support non-blocking I/O at the time of writing of the book (it does not, with java.nio), so just implementing those examples of the book that realy on non-blocking I/O in Java would be relevant.

Apart from architectural patterns, there is always the option of "implementing something using patterns". This should typically be something where a high degree of adaptability is required or where a high degree of reuse can be obtained using the patterns. If you have implemented programs before in a different course that you can advantageously reimplement using patterns, that is a good basis for a project as well (it allows you to compare the non-pattern version and the pattern version).

An oral presentation is expected to last 20 minutes, followed by 5 minutes of questions. The presentation is given in class, and all students are expected to be there. An oral presentation should cover all aspects of a specific pattern not otherwise covered in the course. To make sure that the pattern which you intend to present is not going to be presented by someone else, let Ulrik know what you intend to present.

The oral presentation will be graded on the 13-scale (grades are of course confidential and will not be revealed publicly). Furthermore, we will do our best to give high-quality feedback on how the presentation could be improved.

Projects should investigate a topic relevant to the course, and document the investigations in a written report. The reports will be peer reviewed before they are handed in.

Topic-wise, there are primarily two kinds of reports: implementation and investigation. Implementation reports document your experiences from implementing a system using appropriate patterns, but preferably more than one (although this does depend on the pattern in question, but usually it's hard to use only one pattern when implementing a system). Investigation reports examine a specific topic within patterns not covered in the course, for example the relation between Alexander's philosphical ideas and the latest trends in the pattern community, or whatever you can think of.

The subject of your report must have been approved by Ulrik, which is done by sending him an email with the text [SP REPORT APPROVAL] included in the subject line and then getting a reply (if he does not reply within a few days, try again). The body of the email should describe who your group members are, and then have a 5-10 line description of what you would like to do.

In greater detail, here is what I expect as a minimum from the report:

• As a guideline, 8-12 pages, but don't try to artifically stretch the material that you have if there isn't enough for 10 pages, and you should have a really good reason for going beyond 12 pages.
• For implementation-type reports, your report should describe the design of what you have implemented, not the implementation itself (for example, we don't care about the algorithm, but we do care about how the algorithm is decomposed into collaborating objects).
• Concentrate on issues relevant to the course, and make absolutely sure to include a discussion of these issues in your report. For example:
  • If you've implemented something using design patterns, then how did design patterns work for you?
  • If you've implemented a framework, then did you run into some of the issues discussed during the course, and what hotspots does your framework have?
  • If you've investigated some theoretical issues, how do they compare to the views presented at class?
  (There are of course many other relevant issues.)
• What are the experiences you've gained working on this project?
• Whatever else one normally puts in a report (if you need more advice, we'll be happy to help).