Weekly Journal : Cell Society Project Analysis

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.

You might also learn something by looking at someone else's code.

Submission

Complete the following as a team on the master branch of your cellsociety_teamNN repository (no other changes should be made to the code at this point):

• DESIGN Document: complete the project DESIGN.md file (note, any part of this document or submitted lab discussions can also be used within your analysis as appropriate)

In your individual portfolio_NETID repository provided for you in the course's Gitlab group, push the following:

• a Markdown file, named week11_cellsociety_analysis.md, with your reflection on the project's design
• in the masterpiece02 folder, Java file(s) showing an example of well designed code you wrote during the project
• in the masterpiece02 folder, an example simulation and video that shows off something interesting about your project

Specifications

Example

Create 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.

Code Masterpiece

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.

Every line of code in the class(es) you submit will be reviewed, you cannot specify only part of a class or comment out large sections of code. Simply copy only the Java code files you want us to review from the project to your portfolio's 02_masterpiece folder without renaming them (you do not have to include files they depend on as we will not be compiling these versions, just commenting on them).

Design Review

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.

• Overall Design. Reflect on the entire project by reviewing all the code, especially parts you did not write:
  • Describe everything that needs to be done to add a new kind of simulation to the project (including data or resource files, new code files for automata rules written in Java, updated methods or data structures, etc.).
  • Describe the overall design of the program, without referring to specific data structures or actual code (focus on how the classes relate to each other through behavior (methods) rather than their state (instance variables)).
  • Show a code example for each of the following concepts and explain why you feel it embodies that principle or could be improved by applying that principle:
    • Liskov Substitution Principle
    • Dependency Inversion Principle
    • Interface Segregation Principle
  • Describe one feature from the assignment specification that you felt was made easier to implement by the code's design and why.
  • Review two features a teammate implemented in detail — one that you feel is well designed and one whose design could be improved:
    • Describe the code's design for each in detail (what implementation details are encapsulated? what assumptions are made? etc.)
    • Evaluate the design of each (justifying why you feel it is good or explaining how you would improve it)
• Your Design. Reflect on the coding details of your part of the project:
  
• Describe a design challenge you wrestled with:
  • What are the trade-offs of the design choice?
  • What alternate designs did you consider?
  • How did you eventually handle it?
  • Why are you satisfied or not with the final solution?
• Describe two features you implemented in detail —one that you feel is well designed and one whose design could be improved:
  • Describe the code's design for each in detail (what implementation details are encapsulated? what assumptions are made? etc.)
  • Evaluate the design of each (justifying why you feel it is good or explaining how you would improve it)
• Conclusions. Reflect on what you have learned about designing programs through this project:
  
  • What part(s) of the code did you spend the most time on (e.g., debugging, adding to, rewriting, or even just thinking about)?
  • How has your perspective on and practice of coding changed because of this project?
  • What specific steps can you take to become a better designer in the next project?