In this group project, you will explore a new pattern and share your pattern with your peers. The primary emphasis in the presentation project is curiosity. Your goal will be to find one interesting, complex advantage of the pattern and make it simple for your peers by looking at this advantage from multiple perspectives.
In the first phase of the project, you will select a pattern, identify a single, key advantage of using the pattern, and identify a project that demonstrates that advantage. This demonstration needs to be a GUI (JavaFX) application written by the team (not found online), and you must be able to show that applying the pattern provided a design advantage. Implementing the project will be the second phase, but in phase you must consider how the project will illustrate your key advantage.
The presentations, including any demonstrations, will generally be done during the final lab session for your section. Typically all teams present in the 120 minutes, so this gives a target time limit. Plan to include the demonstration very early in the presentation because the demonstration typically gives important context about the pattern. Read through the other presentation notes as you construct your draft. The presentation will need to reinforce the key point multiple times from different perspectives such as its use in the demonstrated code, how it is captured in the design, different ways the pattern appears in large, real systems, etc. Note the use of “such as” in the previous sentence! What is appropriate for one presentation may not be appropriate for others. The key is to leave the audience with both a general understanding of the pattern and the key advantage you are highlighting.
In the second phase of the project, you will actually implement your example program that illustrates your one key idea. During this phase, you may make minor changes to your design as you discover new things about your pattern. You will adjust your presentation to reflect these minor changes. You may find it helpful to read the requirements for this implementation as you brainstorm.
You will work in teams of three or four as organized by your instructor. 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.
Your project will be evaluated, in part, according to the Exhibit Curiosity SWE2410 Rubric, which your instructor will provide you.
Do not pick any of the patterns covered in class: Command, Composite, Decorator, Façade, Factory (in any of its variants), MVC, Null Object, Observer, Singleton, Strategy, and Visitor. There are a number of patterns covered in textbooks that can be selected: Builder, Chain of Responsibility, Flyweight/Object Pool, Interpreter (Advanced GoF pattern), Mediator, State, and Twin. But there are many other good choices; see sites like OODesign.com and wikidot for some ideas. You can find more such sites by searching for “catalog of software design patterns”. Cloud patterns, such as those listed at Microsoft, are also possibilities, though do not select Functions as a Service (e.g., AWS Lambda), Pub/Sub, or Step Functions since these are covered in class.
Avoid the following patterns:
Your pattern must be approved by the instructor. Patterns are available on a first-come, first-serve basis.
As you consider the patterns, consider whether there is an interesting, complex advantage of the pattern that you can make simple for your peers. Also consider what “real world” GUI program you could develop to illustrate this advantage. These two ideas will eventually be assessed in the Exhibit Curiosity SWE2410 Rubric under the Exploration and Innovation headings.
The first step is to develop a preliminary version of your presentation. The presentation will explore your “one key advantage” of your design pattern from multiple perspectives. If you are having difficulties with this, consider generalizing your key advantage a bit.
Note that you are developing the presentation before the program that illustrates the pattern. This is to help ensure that the program’s design does illustrate your key advantage. It is likely you will make some changes to the presentation after the program is developed, but it is hoped those changes will be of the form “update this diagram” or “include this code snippet.” If you find you need major changes, talk to your instructor.
As discussed above, the program should be demonstrated fairly early in the presentation. You will not have the program written yet, so include mockups showing what the program will likely look like when it is run. These can be created using simple drawing tools, but you can also simply write on a whiteboard and include pictures in the draft presentation.
Other things to include in the presentation:
The following items are not required, but you should strongly consider including at least some of the following:
All of these perspectives should key into your demo app, showing details from the app rather than abstractions or other example programs that are out there. Sometimes, an additional example beyond your app may also be useful, but should not replace tie-ins to your example application. Write the presentation as if the example program already exists. For example, your class diagrams should use names for classes you plan to write in your example program.
Many of these perspectives – especially the required mockups, UML class diagrams and code snippets – can be enhanced by contrasting them to a solution that does NOT use the design pattern. In some cases, you may wish to even implement the alternative solution, e.g., to show a performance advantage of the design pattern or to work out what the alternative is more clearly in your own mind.
Do NOT attempt to describe your entire demo application’s source code in your presentation. Class diagrams should include only those classes that support the goal of illustrating key elements of how the pattern is applied to your project. In particular, do not include all attributes and methods within each class. Likewise, code snippets should be just long enough to illustrate your point. You will may need to develop multiple diagrams and combine diagrams with different code snippets (which may be on a diagram!) to illustrate different aspects of the pattern and the pattern’s key advantage. This is an art. The whole team should review each perspective to ensure the level of detail is just right.
Your presentation will be evaluated according to the Exhibit Curiosity SWE2410 Rubric. As you look at multiple perspectives, focus on the Perspectives and Intellectual Inquiry dimensions of the rubric.
Submit your draft as directed by your instructor. Where you plan to supplement your presentation with board work, write what you plan to write on the board in a second PDF that you mention from your presentation.