2.1.3 Thinking procedurally

• Decomposition

  • Breaking down a complex problem into smaller subproblems that are easier to understand.
  • Smaller parts easier to work with in order to develop solutions
  • separating the problems into sections makes it more feasible to manage and can be divided between a group of people
• Flow charts

  
• The solution to a problem can be built from the low-level sub-problems by solving them and combining them into a complete and final solution
• Order of steps needed to solve a problem is important
• Data from one module needs to be available and validated before it can be passed to another one.
• Thinking Procedurally:

  • makes the task of writing a program a lot easier by breaking a problem down into smaller parts which are easier to understand and easier to design
• Stepwise refinement:

  • top-down design
  • approach for very large problems, broken down into levels
  • higher levels provide an overview of a problem
  • lower levels specify in details the components of this problem
• Aim of top-down design:

  • keep splitting problems into subproblems until each subproblem can be represented as a single tasks and ideally a self-contained module or subroutine
  • each task can then be solved and developed as a subroutine by a different person and can also tested separately before being brought together and integrated
• Identifying the Components of a solution:

  • must consider the lowest-level components first
  • identify which tasks can be solved using an already existing module subroutine or library
  • components of solution are combined to form a full working solution
• When we think procedurally,

  • order in which operations are performed becomes important
  • some inputs may need to be validated before they can be passed onto the next subroutines
  • some subroutines will require data from other subroutines before they are able to execute