SWE 2410, Presentation Project: Introduction

We cannot cover all patterns in SWE 2410, and continuous self-directed learning is an essential skill for software engineers and computer scientists, so part of your grade will be working in a group to present an additional pattern. You can decide which pattern to cover, but your pattern must be approved by the instructor and should not be one covered in lecture. See your instructor’s directions for details about which will be covered. Also avoid the following patterns because they rarely result in good presentations: Bridge, Extension Objects, Iterator, Prototype, and Template. Please talk to your instructor before considering these patterns.

Working in groups, research a pattern, develop an application illustrating that pattern, and prepare a fifteen to twenty-minute presentation on the pattern. Most groups will have 3 students, but some may be 2 or 4 depending on the number of students in the section. For a group of 4 students, the team must discuss how they will do substantially more work than a team of 3. The presentation can be largely based on how the pattern worked in your implementation, but the viewer must come away with a core understanding of how the pattern works, when it might be applicable, and what the consequences are (both good and bad). The presentations will often result in questions on the final exam. Your presentation should be at least ten minutes long and no more than fifteen. In some cases, it will need to be shorter so all groups can present.

How you divide up the work is up to the team, but all must participate in a meaningful way. In particular, everyone must both present and help write the implementation. A significant part of your grade will be based on a short report in which you describe how you contributed.

Implementation Requirements

• The expectation is that you will write all code for your project. Make good use of standard libraries, of course. If you include sample code from the Internet, you must discuss the source with your instructor and ensure you add sufficient code of your own. The goal is to get significant experience with the pattern, and just building and presenting someone else’s code does not achieve that. In all cases, be sure to properly attribute any code written by someone other than a team member.
• It must be a GUI application based on JavaFX. Be sure all fonts are large enough that students can read text from the back of the classroom. This generally means font sizes that are at least 50% larger than the default. Any output you want your audience to view must be on a JavaFX window. Be sure your output is focused on your intent; do not include unnecessary output.
• Projects need not be extensive; the focus should be on applying the pattern. But it is difficult to see how you can provide a useful implementation with less than two or three hundred lines of code. It is also important that the system contain elements that would be used by (non-programmer) users.

Presentation Requirements

• Be sure to practice the full presentation, checking that you fit within the time limits.
• Ensure the slide deck is focused on your goals. Each slide should present useful information. If two slides have just a few lines of information, consider merging them into one slide. Focus on the narrative, not on maximizing how many details can be included.
• Include UML diagrams of the pattern in the presentation. In most cases, a class diagram and a sequence diagram will do a good job of capturing the necessary detail. You may wish to use a state diagram instead. Keep the clutter on these diagrams to a minimum: the goal is to illustrate the pattern. This is typically best accomplished with minimal solution diagrams. Do not reverse-engineer your code to generate the diagram unless you are willing to heavily revise the result to remove extraneous details.
• Ensure you use large enough fonts in the presentation. In most cases, 22-point font should be considered a minimum. In some cases, however, the minimum is a 30-point font. When the presentations are in a classroom, go to that classroom and check that your full slide deck and any examples are easily read from the back row of desks.
• Unless there is a very good reason, place your demonstration early in your presentation, then refer back to the demonstration code when making points about advantages and disadvantages in using the pattern. Doing the demonstration last is not effective.
• Strongly consider including a slide discussing how the pattern is used in industry or in (professional) AI tools. In some cases this information can be difficult to find. Groups of 4 need to include UML diagrams illustrating these uses.
• Ensure you have a summary slide at the end that reminds the audience which pattern you covered, its primary use, and the key advantages and disadvantages that are illustrated by your implementation. That is, summarize what you want them to take away from your presentation. You might call this a “things to know” slide. This slide should emphasize your central narrative point.
• Do not show text on your screen that you do not want your audience to read. For example, slides with long lists of references have no value during the presentation. If you include these, include them in an appendix that you do not display.
• Before the presentation: run the code on the presentation laptop and make sure it is working, then do not make any changes to it.
  • If you show code from IntelliJ during the presentation, use the View->Appearance menu to Enter Presentation Mode and then Alt-1 or View | Tool Windows | Project to allow navigating between files. Get to the menus by moving the mouse to the top of the screen.

Grading Rubric

You will be evaluated on the effectiveness of your presentation, including defining your terminology, tying concepts to the examples you provide, and staying focused on the presentation goals. The presentation is to be targeted at your peers: students who have studied design patterns but may have no knowledge of the pattern you are presenting.

• Exemplary: the pattern and associated demonstration program are well-described in a way that is understandable by peers, and the presentation reinforces clear goals.
• Accomplished: the pattern and associated demonstration program are well-described in a way that is understandable by peers.
• Proficient: the pattern and associated demonstration program are adequately described in a way that is understandable by peers.
• Developing: the pattern and associated demonstration program are partially described, possibly lacking needed information or being overly technical.
• Beginning: the pattern and associated demonstration program are not sufficiently described to explain their purpose.