As we think about process there are two general ways to solve a software problem: top-down and bottom-up.
Top-down development tries to first define how the user or consumer will utilize the system. To do it well you ask questions about the interactions like:
- What kind of interface will the system have? (ex: web, mobile, hardware, etc)
- Why are they using the system? What "value" are they trying to extract?
- What inputs will we get? What are the format, structure, and size of those inputs? (ex: mouse, keyboard, touch, data files, JSON...)
The first step of top-down design is to map out a complete interaction that demonstrates value to the user. Something like:
As a guest user
When I visit the homepage
And I click the REGISTER link
Then I see a form with the fields Name, Email Address, Password, and Password Confirmation
From there you keep drilling down discovering the details one layer at a time.
Top-down prioritizes the user. Therefore, top-down is a good choice when you think you know what the user wants. The danger of top-down is that we design interactions in such a way that they're unnecessarily burdensome/complex to implement under the hood (since we're not paying much attention to implementation).
Bottom-Up development tries to first understand the nature and structure of data and relationships. To do it well you ask questions about the data like:
- What fundamental elements will the system have? Who are the "actors" in our system? (ex: the key classes or abstractions)
- For those individual actors, what are the rules that govern their behavior?
- How do those "actors" combine to offer more complex functionality? What are the rules of those interactions?
- What "oddities" or "edge cases" can we expect? How will they affect the system?
- What inputs will we get? What are the format, structure, and size of those inputs? (ex: mouse, keyboard, touch, data files, JSON...)
The first steps of bottom-up design are to guess some of the actors we'll need and start building. Something like:
Let's build a USER model which has a NAME, EMAIL ADDRESS, and SALTED PASSWORD.
Make it possible to create new USERs knowing all the attributes.
Make it possible to change the EMAIL or NAME of an existing user.
Make it possible to change the SALTED PASSWORD.
Ensure that the EMAIL ADDRESS is unique among users.
From there you build up and up by composing the actors into interactions.
Bottom-up prioritizes the data. Therefore, bottom-up is a good choice when you don't understand the user or feel stuck/overwhelmed by the complexity of the problem.
Remember: Your goal is to practice your process, not strive for completion.
Let's return to the Game of Life. For today's session, you and your pair should choose to build a solution using either a Bottom-Up or Top-Down process. Pick the one that makes you more uncomfortable.
- Priority 1: Let's make sure that every Mod1 student is paired with someone from a higher mod
- Priority 2: After all M1s are matched, match with someone who is not in your cohort
The full story: https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life
You have a 2-dimensional grid, either a square or rectangle, which will contain a random number of "cells" placed around the grid. The cells live, die, or reproduce, based on the following rules:
- Any live cell with fewer than two live neighbours dies (underpopulation)
- Any live cell with two or three live neighbours lives on to the next generation
- Any live cell with more than three live neighbours dies (overpopulation)
- Any dead cell with exactly three live neighbours becomes a live cell (reproduction)
Your application should not require any user input, and each "round" (generation) may modify the cells in the grid.
Find a way to display your grid with a brief pause in between each generation such that it appears to animate.