CompSci 307 Fall 2022 |
Software Design and Implementation |
Knowledge without transformation is not wisdom. — Paulo Coelho
This analysis is your opportunity to demonstrate your own thinking and knowledge of design concepts represented (or not) in the project's code. The course staff can readily identify the good and bad aspects of project's design, so we are looking to see if you can also acknowledge these as well. If it is also an honest and thoughtful retrospective, it can also help you identify specific actions you can do to improve future projects.
In your individual portfolio_NETID
repository in the course's Gitlab group, push
the following:
cellsociety
folder:
week10_cellsociety_analysis.md
, with your reflection on the project's designCreate your own "interesting" example simulation configuration files and record a 40-60 second video showing it and the result of running it in your project (provide a voice over on the video to describe what makes your example interesting). Go beyond a simple test example or starting configuration to show off important features or design elements by focusing on creative or powerful things your project can do.
The easiest way to make a video of your running project is to start a Zoom call, share your screen, start recording, and talk over your demo. There are also many free screen capture tools available or free trials of commercial tools.
Choose part of the code you primarily wrote that you feel demonstrates what you think of as good design, totaling approximately 150-300 lines (including comments). It should represent a feature or component within your larger project that is small enough to be separable, but functionally significant enough to have some interesting design element. The term "component" is used rather than "class" because it may be several classes that work together, e.g., a few classes that work together or a superclass and its sub-classes. Note, if your component is specifically intended to be superclass, it must include enough detail that it is clear how to extend it and at least one example subclass to how it supports an abstraction.
Simply copy only the Java code files you want us to review without renaming them from your project to your portfolio, into a folder named cell_society
, (you do not have to include files they depend on as we will not be compiling these versions, just reviewing on them).
Explain your view of how your program is organized and why it was done that way. This can be an opportunity for you to describe how you might fix a problem, conceptualize something you thought about but could not figure out how to implement, or present an alternate design if you did not agree with the team or did not have time to actually change the code.
If you think something is good, justify your opinion. If you think something is bad, justify your opinion and suggest how to improve it. Use specific code examples and supporting reasons related to design principles discussed in class or in the readings rather than general terms like "clearly/obviously", "good/sucks", "elegant/ugly", or "like/hate". Note, no design is perfect so including both pros and cons of a design (i.e., its trade-offs) or alternate designs you considered is highly encouraged.