Decomposition strategies

There are many definitions of computational thinking, but nearly every single one includes "decomposition."  At this point, you probably understand that "decomposition" means to break a larger problem into smaller parts.  But that's where most people end it.  In my experience, however, there are multiple ways of breaking down a problem.  Understanding what these are may help you and your students to approach problems in a more productive way from the get-go.

To get a better understanding of decomposition strategies, we looked at how professionals in over a dozen different disciplines approach breaking down the problem.  We were able to boil decomposition down to 3 main steps that, when followed, help create a useful plan for solving problems in a variety of domains.

Part 1:  Break down the problem by its components.

Substantive decomposition is when you start by looking at the substance of what you have and looking for the tangible parts that make up that substance.  For example, you might break down a car engine by its physical parts.  Even within the parts, these might be made up of other parts.  

Substantive decomposition is one of the most common approaches and is readily understood and used by most people, including young children.  This likely has to do with the tangible nature of identifying the substance or composition of a problem's elements.  It is a good place to start, but don't make the mistake of ending here.

One way of starting a substantive decomposition is to identify the different ways in which you might look at a problem's components.  You might break them down by the objects needed, the shape of the objects, the size of the objects, etc.  Choose one of these categories and identify all the parts or "things" that belong to that category.  Then, you'll have some parts you can start working with.

Part 2: Identify relationships

Relational decomposition occurs when you approach a problem by looking at the parts and identifying how they relate to one another (or ought to).

James Spradley, a famous ethnographer identified many different types of relationships between different people and objects.  You may find some of these useful in identifying how your different components relate to each other.  They are:

Part 3: Identify the functions

Once you've identified the parts of a problem and how they relate to each other, it is useful to identify the function.  A common approach within software development is to break problems down by their function.  Functional decomposition takes into account both substantive and relational decomposition and identifies how the parts ought to behave in relation to each other.  

Putting it all together (or taking it all apart?)

Decomposition doesn't need to be a long process, but understanding the different parts can be very useful.  Let's suppose I wanted to create a simple project to remember my students' names.

1. Identify the components I would need: (a) a "picture" sprite for each student's picture, (b) a button to switch the picture, and (c) a title to say the student's name.
2. Identify the relationships: There is a cause -> effect relationship between the button and the other two components.  Clicking on the button should cause the others to change their state.
3. Identify the function: When I click on the button, I would want to broadcast a message.  When the other two components hear this message, I would need an algorithm to randomly pick a new student from a list.  The student image would then show from the corresponding list, and I would do the same with the name (so I could change the title).

This is actually a project I created as a teacher.  If you'd like to see it in action, check out a generic version of the project with U.S. presidents as my "students." Links to an external site. I added a few more objects to it to make it into a game.  Can you identify the extra components?